假如socket客户端的每次read一些数据后处理个一定时间，假如1秒后 ，在循环的read数据 在处理 。服务端的程序一直在大量的往客户端发数据 。这样的话会不会造成丢包呢？
想问一下 java socket建立的输入输出流 内部发送的机制是什么呢？
如果客户端 连上来以后 服务端就不停的往客户端发数据 客户端处理不过来 ，先缓存在接收端的缓存里面 ，，，
接收端的缓存如果慢了 发送端会继续发送 数据 缓存在发送端缓存里面。 然后发送端缓存也满了，就停止发送。等待缓存释放。如果经常这样的话 ，会不会造成发送端丢数据 （在还没走tcp传输的过程中就丢了。所以不能重发）
是这样的吗？？请指点。
想问一下 java socket建立的输入输出流 内部发送的机制是什么呢？
如果客户端 连上来以后 服务端就不停的往客户端发数据 客户端处理不过来 ，先缓存在接收端的缓存里面 ，，，
接收端的缓存如果慢了 发送端会继续发送 数据 缓存在发送端缓存里面。 然后发送端缓存也满了，就停止发送。等待缓存释放。如果经常这样的话 ，会不会造成发送端丢数据 （在还没走tcp传输的过程中就丢了。所以不能重发）
是这样的吗？？请指点。
TCP协议我了解了一点 ，虽然不是很深刻。但是也应该是有点了解。 谢谢。
这里面主要请高手指点 ，socket发送时 如果缓存被填满的情况tcp协议在这个时候还不起作用。以上情况 c语言 在发送端缓存 满了后 ，如果是非堵塞 发送 ，会出现丢包的情况java里面好像是堵塞 的发送。
你可以用将许多小包组成一个大包，去减少包的数目，因为当今网卡一般bps字节处理非常强大，但是pps包流量却不行。所以传输时，最好采用大包的形式。
“假如socket客户端的每次read一些数据后处理个一定时间，假如1秒后 ，在循环的read数据 在处理 ”
为什么要等处理完再读呢？ 程序中用一个线程专门处理收到的数据，这个1s的等待就没有了，一定程度上也可以减少丢包现象。
非组赛就是你先干，我现看看有其他事没有，完了告诉我一声我们拿最常用的send和recv两个函数来说吧...
比如你调用send函数发送一定的Byte,在系统内部send做的工作其实只是把数据传输(Copy)到TCP/IP协议栈的输出缓冲区,它执行成功并不代表数据已经成功的发送出去了,如果TCP/IP协议栈没有足够的可用缓冲区来保存你Copy过来的数据的话...这时候就体现出阻塞和非阻塞的不同之处了:对于阻塞模式的socket send函数将不返回直到系统缓冲区有足够的空间把你要发送的数据Copy过去以后才返回,而对于非阻塞的socket来说send会立即返回 WSAEWOULDDBLOCK告诉调用者说:"发送操作被阻塞了!!!你想办法处理吧..."
对于recv函数,同样道理,该函数的内部工作机制其实是在等待TCP/IP协议栈的接收缓冲区通知它说:嗨,你的数据来了.对于阻塞模式的socket 来说如果TCP/IP协议栈的接收缓冲区没有通知一个结果给它它就一直不返回:耗费着系统资源....对于非阻塞模式的socket该函数会马上返回,然后告诉你:WSAEWOULDDBLOCK---"现在没有数据,回头在来看看"文章出处：飞诺网(www.firnow.com):http://dev.firnow.com/course/3_program/java/javajs/20100719/454206.html