你可能没有细究过的TCP/IP

时间 2019-11-16

标签可能没有细究 tcp 栏目系统网络繁體版

原文原文链接

概述

做为互联网时代伟大发明的TCP/IP技术能够说对当今时代产生了深入的影响。通过近一个月的学习摸索，基本清楚了TCP/IP的面貌。因为TCP/IP在OS中位于内核态，不少细节其实用户没法感知，因此本身对于TCP/IP会有一些疑惑。关于其中几个点通过查阅一些书籍、博客并结合本身的一些理解，在此整理精炼成帖。linux

注：本文首发于 My 公众号 CodeSheep ，可长按或扫描下面的 当心心 来订阅 ↓ ↓ ↓算法

疑惑1 — 关于拥塞

**疑惑一：**不管是满启动仍是拥塞避免阶段，拥塞窗口都在增长，理论上必定会碰到拥塞点，为何平时感受不到拥塞呢？windows

看了不少书和文献之后可能的解答以下：网络

一、OS中对接收窗口的最大设定多年未动，如windows在不启用“TCP Window Option”状况下，最大接收窗口仅64KB。然而网络进步，不少环境的拥塞点远在64kb以上，即发送窗口永远触碰不到拥塞点性能
二、不少应用场景是交互式小数据交换，如聊天等，不会有拥塞的可能学习
三、有些应用在传输数据时采用同步方式，可能须要的窗口很是小（如采用了同步方式的NFS写操做，每发一个写请求就停下来等回复，而一个写请求可能仅有4kb）图片
四、即使偶尔拥塞，持续时间也不足以长到能感觉出来，除非抓包看包交换细节get

疑惑2 — 关于超时重传

疑惑二： 关于超时重传后的ssthresh设置问题的争议同步

一、Richard Stevens在《TCP/IP详解》中把临界窗口值定为上次发生拥塞时的发送窗口的一半博客
二、RFC5681则认为应是发生拥塞时未被确认的数据量的1/2（又称FlightSize），且不小于2MSS
三、Westwood/Westwood+算法则这样认为：先推算出有多少包已被送达到接收方（可根据收方回应的ACK来推算），从而精确地估算发生拥塞时的带宽，最后再依据带宽来确认新的拥塞窗口
四、Vegas算法则这样认为：引入全新的概念，摒弃以前的在丢包后才调节拥塞窗口的作法。其经过监控网络状态来调整发包速度，实现“真正的拥塞避免”。当网络良好时，RTT较稳定，此时能够增长拥塞窗口；当网络繁忙时，RTT增长，此时减少拥塞窗口
五、Compound算法这样认为：同时维持两个拥塞窗口，一个相似于Vegas，另外一个相似于RFC5681，真正起做用的是二者之和（Win7上其默认关闭）
六、BIC算法/CUBIC算法分别是linux2.6.18和linux 2.6.19所采用，目前还没有研究

关于TCP/IP的几点精炼总结：

（1）当无拥塞时，发送窗口越大，性能越好。∴在带宽没有限制的状况下，应尽可能增长接受窗口，好比启用Scale Option
（2）若常常发生拥塞，则限制发送窗口反而能够提升性能，∵即使万分之一的重传对性能的影响都很是大。不少OS上可经过限制接收窗口的方法来↓发送窗口
（3）超时重传对于性能影响最大，∵RTO时间内未传输任何数据，而Cwnd会被设成1MSS，应尽可能避免
（4）快速重传对性能影响小一些，∵无等待时间，且Cwnd减幅不大
（5）SACK和NewReno有利于增长重传效率，增长传输性能
（6）丢包对极小文件的影响比打文件严重。深层缘由是由于读写一个小文件须要的包数不多，∴丢包时每每凑不满三个Dup ACK，只能等待超时重传；而大文件有较大可能触发快速重传

后记

做者更多的原创文章在此