TCP三次握手、糊涂窗口、粘包问题-创新互联
这是在学习中的总结,若有错误请大家不吝指正(^.^)
创新互联坚持“要么做到,要么别承诺”的工作理念,服务领域包括:成都做网站、成都网站设计、成都外贸网站建设、企业官网、英文网站、手机端网站、网站推广等服务,满足客户于互联网时代的东乡族网站设计、移动媒体设计的需求,帮助企业找到有效的互联网解决方案。努力成为您成熟可靠的网络建设合作伙伴!关于TCP/IP的三次握手:
当服务端的状态为LISTEN,客户端的状态为CLOSED时,客户端发起连接
客户端发送有SYN字段报文,此时状态为SYN_SENT状态
服务端接收该报文时,状态处于SYN_REVD状态,并向客户端发送有SYN与ACK字段的报文
客户端接收到该报文时,状态处于ESTABLISHED(建立)状态,并发送有ACK字段的报文
服务端接收到报文后,状态处于ESTALISHED(建立)状态,并开始数据的交互
关于糊涂窗口:
当在网络数据传输中,大量发送含有少量数据的报文(极端情况一个报文只有一字节数据),因为在协议层中对数据是层层封装的过程,因此对于数据来说有大量的协议头,传输开销过大;或接收端在缓存区接受数据过慢;
解决方法:
发送端使用Nagle算法,当发送包长度小于MSS大小时会等待一会,发送条件是:
直到所有发送的小包都有ACK回复且未设置TCP_CORK时;
直到有FIN字段时;
直到数据长度达到MSS时;
直到等待超时(一般200ms);
设置TCP_NODELAY且没有设置TCP_CORK时;(就是不使用优化算法啦)
(当小包的ACK字段接收较快时算法的作用不大)
发送端使用CORK算法,会将小包拼接成大包,是协议头在协议报文的比重减小,发送条件是:
拼接的报文大于MTU或超时;
没有设置TCP_CORK并设置TCP_NODELAY时;(就是不使用优化算法啦)
(当小包的传输时间间隔不短时影响实时性,因为都要等待超时传输)
接收端使用Clark解决,只要有数据到达就确认,但宣布窗口大小为0,直到缓存空间够容纳一个MSS或缓存空间一半已空;
接收端延迟确认,直到缓存空间足够为止,防止TCP发送端窗口的滑动,可以减少通信量,不必确认每个报文段,但延迟的确认会导致重发。
关于粘包问题:
因为要解决糊涂窗口而使数据积攒发送,或收端不及时接受缓存区数据而同时接收多个包,会导致发送的原数据接收后拼接在一起无法分离。
解决方法:
当数据传输是一次交互后立即断开(多个Client与一个Server)时,数据无结构时(文件传输,一方发另一方收),使用UDP时(有消息边界)不会产生粘包问题;
发送端设置强制数据立即发送,不必等待缓存区满(无处理优化,效率降低);
接收端优化编程方法,精简接收过程,提高接收优先级等使其接收效率提高(不能完全避免);
接收端按结构字段、人为控制多次接收,然后合并(效率低,对实时场合不适用);
在这里问一下,怎么美化呀,之前看别人的博客很酷炫的
另外有需要云服务器可以了解下创新互联scvps.cn,海内外云服务器15元起步,三天无理由+7*72小时售后在线,公司持有idc许可证,提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案,具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势,专为企业上云打造定制,能够满足用户丰富、多元化的应用场景需求。
网页题目:TCP三次握手、糊涂窗口、粘包问题-创新互联
本文URL:http://scyanting.com/article/ddjocp.html