关于怎么做网站,石家庄最新新闻事件,西部数码网站管理助手 3.0,深圳网站公司好转自#xff1a;http://www.cnblogs.com/orange1438/p/4693470.html今天在公司问老大#xff0c;公司的项目底层#xff0c;是使用的TCP#xff0c;因为可靠#xff0c;自动断线重连#xff0c;在底层都实现了#xff0c;但是我记得TCP也会有掉包的问题#xff0c;所以…转自http://www.cnblogs.com/orange1438/p/4693470.html今天在公司问老大公司的项目底层是使用的TCP因为可靠自动断线重连在底层都实现了但是我记得TCP也会有掉包的问题所以这文章就诞生了——关于TCP掉包的问题TCP是基于不可靠的网络实现可靠的传输肯定也会存在掉包的情况。如果通信中发现缺少数据或者丢包那么最大的可能在于程序发送的过程或者接收的过程出现问题。例如服务器给客户端发大量数据Send的频率很高那么就有可能在Send时发生错误原因可能是又多种可能是程序处理逻辑问题多线程同步问题缓冲区溢出问题等等如果没有对Send失败做处理重发数据那么客户端收到的数据就会比理论应该收到的少就会造成丢数据丢包的现象。这种现象其实本质上来说不是丢包也不是丢数据只是因为程序处理有错误导致有些数据没有成功地被socket发送出去。常用的解决方法如下拆包、加包头、发送组合包如果客户端、服务端掉线常采用心跳测试。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.更复杂的应用层协议总结自定义协议