标签：style 使用 sp strong 文件 数据 on 问题 bs
一。通信协议TCP/UDP：
因此，发送端为了将多个发往接收端的包，更有效的发到对方，使用了优化方法（Nagle算法），将多次间隔较小且数据量小的数据，合并成一个大的数据
块，然后进行封包。这样接收端就难于分辨出来了，必须提供科学的拆包机制。 即面向流的通信是无消息保护边界的。
的是一对多的模式，所以接收端的skbuff(套接字缓冲区）采用了链式结构来记录每一个到达的UDP包，在每个UDP包中就有了消息头（消息来源地址，端
口等信息），这样对于接收端来说就容易进行区分处理了。 即面向消息的通信是有消息保护边界的。
二 。什么时候需要考虑粘包问题
1.利用tcp每次发送数据，与对方建立连接，然后双方发送完一段数据后，就关闭连接，不会出现粘包问题（因为只有一种包结构）。
2.如果发送的数据无结构，如文件传输，这样发送方只管发送，接收方只管接收存储就ok，也不用考虑粘包
3.如果双方建立连接，需要在连接后一段时间内发送不同结构数据，如连接后，有好几种结构：
1)"hello give me sth abour yourself"
2)"Don‘t give me sth abour yourself"
那这样的话，如果发送方连续发送这个两个包出去，接收方一次接收可能会是"hello give me sth abour yourselfDon‘t give me sth abour
yourself" 这样接收方就傻了，到底是要干嘛？因为协议没有规定这么诡异的字符串，所以要处理把它分包，怎么分也需要双方组织一个比较好的
包结构，所以一般可能会在头加一个数据长度之类的包，以确保接收。
三。粘包出现原因
1 发送端需要等缓冲区满才发送出去，造成粘包
2 接收方不及时接收缓冲区的包，造成多个包接收
解决办法：
一是对于发送方引起的粘包现象，用户可通过编程设置来避免，TCP提供了强制数据立即传送的操作指令push，TCP软件收到该操作指令后，就立即
将本段数据发送出去，而不必等待发送缓冲区满；
二是对于接收方引起的粘包，则可通过优化程序设计、精简接收进程工作量、提高接收进程优先级等措施，使其及时接收数据，从而尽量避免出现粘
包现象；
三是由接收方控制，将一包数据按结构字段，人为控制分多次接收，然后合并，通过这种手段来避免粘包。
以上提到的三种措施，都有其不足之处。第一种编程设置方法虽然可以避免发送方引起的粘包，但它关闭了优化算法，降低了网络发送效率，影响
应用程序的性能，一般不建议使用。第二种方法只能减少出现粘包的可能性，但并不能完全避免粘包，当发送频率较高时，或由于网络突发可能使某个
时间段数据包到达接收方较快，接收方还是有可能来不及接收，从而导致粘包。第三种方法虽然避免了粘包，但应用程序的效率较低，对实时应用的场合
不适合。
标签：style 使用 sp strong 文件 数据 on 问题 bs
原文地址：http://www.cnblogs.com/yuyutianxia/p/4084346.html
