TCP通信丢包原因总结

                             TCP通信丢包原因总结

 

TCP在不可靠的网络上实现可靠的传输，必然会有丢包。TCP是一个“流”协议，一个详细的包将会被TCP拆分为好几个包上传，也是将会把小的封裝成大的上传，这就是说TCP粘包和拆包难题。

 

但是许多人有不同的理解。TCP协议本身确保传输的数据不会丢失完整性。如果在传输过程中发现数据丢失或数据包丢失，最大的可能性是在发送或接收程序的过程中出现问题。

例如，服务器向客户端发送大量数据，并且发送频率非常高，因此发送链接中很可能会出现错误

（1、程序处理逻辑错误；2、多线程同步问题；3、缓冲区溢出等）

如果发送失败得不到处理，那么客户端收到得数据将少于理论数据，这将导致数据丢失与数据包丢失。这种现象，其实本质上来说不是丢包，也不是丢数据，只是因为程序处理有错误，导致有些数据没有成功地被socket发送出去。
 

关于send函数的问题：

TCP协议只是在传输层履行义务，send函数只是应用层起到向TCP层传递数据的作用，除此之外与TCP层没有任何关系。

 

常见的解决方案包括拆包、添加包头和发送组合包。如果服务器或客户端断开连接，一般会使用心跳测试。

 

心跳测试：每隔一段时间向服务器发送数据包。为了节省资源，通常会发送空数据包。如果发送失败表明套接字已断开，此时需要根据特定条件释放资源并重新连接。

TCP传输可以保证数据交换的可靠性，这意味着一台主机将数据正确地传输到目标计算机，目标计算机的协议栈有一定的限制，如果不及时处理在目标计算机上接收到的数据，堆栈就会溢出。

这种溢出不是由TCP协议本身引起的，而是由系统的IP协议栈的缓冲区溢出引起的！

 

粘包、拆包问题说明

tcp是一个“流”的协议，一个完整的包可能会被TCP拆分成多个包进行发送，也可能把小的封装成一个大的数据包发送，这就是所谓的TCP粘包和拆包问题。

 

假设客户端分别发送数据包D1和D2给服务端，由于服务端一次性读取到的字节数是不确定的，所以可能存在以下4种情况。

• 1.服务端分2次读取到了两个独立的包，分别是D1,D2,没有粘包和拆包；
• 2.服务端一次性接收了两个包，D1和D2粘在一起了，被成为TCP粘包;
• 3.服务端分2次读取到了两个数据包，第一次读取到了完整的D1和D2包的部分内容,第二次读取到了D2包的剩余内容，这被称为拆包；
• 4.服务端分2次读取到了两个数据包，第一次读取到了部分D1，第二次读取D1剩余的部分和完整的D2包；

如果此时服务端TCP接收滑动窗非常小,而数据包D1和D2都很大，很有可能发送第五种可能，即服务端多次才能把D1和D2接收完全，期间多次发生拆包情况。（TCP接收滑动窗：是接收端的大小，随着流量大小而变化，如果我的解释还不明确，请读者自行百度，或者查阅《计算机网络》、《TCP/IP》中TCP的内容）

粘包问题的解决策略

由于底层的TCP无法理解上层的业务逻辑，所以在底层是无法确保数据包不被拆分和重组的，这个问题只能通过上层的应用协议栈设计来解决，根据业界的主流协议的解决方案，归纳如下：

• 1.消息定长，例如每个报文的大小为固定长度200字节,如果不够，空位补空格；
• 2.在包尾增加回车换行符进行分割，例如FTP协议；
• 3.将消息分为消息头和消息体，消息头中包含表示消息总长度（或者消息体长度）的字段，通常设计思路是消息头的第一个字段用int来表示消息的总长度；（我之前linux C开发，就用的这种）。
• 4.更复杂的应用层协议；