TCP协议对于流量控制和拥塞控制

1.HTTP事务时延的原因

1：DNS解析系统将URL中的主机名转换成一个IP地址要花费数十秒时间

2：每条新的TCP连接都会有连接建立时延，同时又数百个http事务的话，这个值快速叠加上去。

3：web服务器读取请求报文并进行处理，因特网传输请求报文都需要时间。

4：web服务器会送http响应也要花费时间

2.TCP连接握手时延

因为要进行三次握手连接，四次握手断开连接，所以耗时很久

3.延迟确认

每个TCP段都有一个序列号和数据完整性校验和，每个段的接收者收到完好的段时，都会向发送者回送小的确认分组，如果发送者没有在指定的窗口时间内收到确认信息，发送者就认为分组已经被损毁，并重发数据。

收方在收到数据后，并不会立即回复ACK,而是延迟一定时间。一般ACK延迟发送的时间为200ms，但这个200ms并非收到数据后需要延迟的时间。系统有一个固定的定时器每隔200ms会来检查是否需要发送ACK包。这样做有两个目的。

1、这样做的目的是ACK是可以合并的，也就是指如果连续收到两个TCP包，并不一定需要ACK两次，只要回复最终的ACK就可以了，可以降低网络流量。delay ack凑够两个也立即ack

2、如果接收方有数据要发送，那么就会在发送数据的TCP数据包里，带上ACK信息。这样做，可以避免大量的ACK以一个单独的TCP包发送，减少了网络流量。

4.TCP慢启动和拥塞避免

一般原理：发生拥塞控制的原因：资源(带宽、交换节点的缓存、处理机)的需求>可用资源。

作用：拥塞控制就是为了防止过多的数据注入到网络中，这样可以使网络中的路由器或者链路不至于过载。拥塞控制要做的都有一个前提：就是网络能够承受现有的网络负荷。

对比流量控制：拥塞控制是一个全局的过程，涉及到所有的主机、路由器、以及降低网络相关的所有因素。流量控制往往指点对点通信量的控制。是端对端的问题。

拥塞窗口 ：发送方为一个动态变化的窗口叫做拥塞窗口，拥塞窗口的大小取决于网络的拥塞程度。发送方让自己的发送窗口=拥塞窗口，但是发送窗口不是一直等于拥塞窗口的，在网络情况好的时候，拥塞窗口不断的增加，发送方的窗口自然也随着增加，但是接受方的接受能力有限，在发送方的窗口达到某个大小时就不在发生变化了。

    发送方如果知道网络拥塞了呢？ 发送方发送一些报文段时，如果发送方没有在时间间隔内收到接收方的确认报文段，则就可以人为网络出现了拥塞。

    慢启动算法的思路 ：主机开发发送数据报时，如果立即将大量的数据注入到网络中，可能会出现网络的拥塞。慢启动算法就是在主机刚开始发送数据报的时候先探测一下网络的状况，如果网络状况良好，发送方每发送一次文段都能正确的接受确认报文段。那么就从小到大的增加拥塞窗口的大小，即增加发送窗口的大小。

    例子： 开始发送方先设置cwnd（拥塞窗口）=1,发送第一个报文段M1，接收方接收到M1后，发送方接收到接收方的确认后，把cwnd增加到2，接着发送方发送M2、M3，发送方接收到接收方发送的确认后cwnd增加到4，慢启动算法每经过一个传输轮次（认为发送方都成功接收接收方的确认），拥塞窗口cwnd就加倍。

拥塞避免： 为了防止cwnd增加过快而导致网络拥塞，所以需要设置一个 慢开始门限 ssthresh状态变量（我也不知道这个到底是什么，就认为他是一个拥塞控制的标识）,它的用法：

                   1. 当cwnd < ssthresh,使用慢启动算法，

                   2. 当cwnd > ssthresh,使用拥塞控制算法，停用慢启动算法。

                   3. 当cwnd = ssthresh，这两个算法都可以。

    拥塞避免的思路 ： 是让cwnd缓慢的增加而不是加倍的增长，每经历过一次往返时间就使cwnd增加1，而不是加倍，这样使cwnd缓慢的增长，比慢启动要慢的多。

无论是慢启动算法还是拥塞避免算法，只要判断网络出现拥塞，就要把慢启动开始门限(ssthresh)设置为设置为 发送窗口 的一半（>=2），cwnd(拥塞窗口)设置为1，然后在使用慢启动算法，这样做的目的能迅速的减少主机向网络中传输数据，使发生拥塞的路由器能够把队列中堆积的分组处理完毕。

5.Nagle算法

该问题的具体描述是：如果我们的应用程序一次产生1个字节的数据，而这个1个字节数据又以网络数据包的形式发送到远端服务器，那么就很容易导致网络由于太多的数据包而过载。比如，当用户使用Telnet连接到远程服务器时，每一次击键操作就会产生1个字节数据，进而发送出去一个数据包，所以，在典型情况下，传送一个只拥有1个字节有效数据的数据包，却要发费40个字节长包头（即ip头20字节+tcp头20字节）的额外开销，这种有效载荷（payload）利用率极其低下的情况被统称之为愚蠢窗口症候群。可以看到，这种情况对于轻负载的网络来说，可能还可以接受，但是对于重负载的网络而言，就极有可能承载不了而轻易的发生拥塞瘫痪。

针对上面提到的这个状况，Nagle算法的改进在于：如果发送端欲多次发送包含少量字符的数据包（一般情况下，后面统一称长度小于MSS的数据包为小包，与此相对，称长度等于MSS的数据包为大包，为了某些对比说明，还有中包，即长度比小包长，但又不足一个MSS的包），则发送端会先将第一个小包发送出去，而将后面到达的少量字符数据都缓存起来而不立即发送，直到收到接收端对前一个数据包报文段的ACK确认、或当前字符属于紧急数据，或者积攒到了一定数量的数据（比如缓存的字符数据已经达到数据包报文段的最大长度）等多种情况才将其组成一个较大的数据包发送出去

1. 对于MSS的片段直接发送

2. 如果有没有被确认的data在缓冲区内，先将待发送的数据放到buffer中直到被发送的数据被确认【 最多只能有一个未被确认的小分组 】

Delay ACK and Nagle 

Nagle指出Nagle算法与Delay ACK机制有共存的情况下会有一些非常糟糕的状况，比如举一个场景：PC1和PC2进行通信，PC1发数据给PC2，PC1使用Nagle算法，PC2有delay ACK机制

1. PC1发送一个数据包给PC2，PC2会先不回应，delay ACK

2. PC1再次调用send函数发送小于MSS的数据，这些数据会被保存到Buffer中，等待ACK，才能再次被发送

从上面的描述看，显然已经死锁了，PC1在等待ACK，PC2在delay ACK，那么 解锁的代价就是Delay ACK的Timer到期 ，至少40ms[40ms~500ms不等]，也就是2种算法在通信的时候，会产生不必要的延时！

如何来解决这种问题？

其实Nagle算法本身的立意是好的，避免网络充斥着过多的小包，提高网络传输的效率，同时Delay ACK也是为了提高TCP的性能，不过二者遇到了，就比较悲剧了。其实在RFC中已经提供了一个用户级别的解决方案，即避免 write--write--read的这种写法，write--read--write--read 以及write--write--write都是OK的。或者禁止掉Nagle算法，这也是一种办法，不过这种办法同时也会让网络充斥小包，降低效率。

悲剧发生在这种情况，假设一端发送数据并等待另一端应答，协议上分为头部和数据，发送的时候不幸地选择了write-write，然后再read，也就是先发送头部，再发送数据，最后等待应答。

这里假设head和body都比较小，当默认启用nagle算法，并且是第一次发送的时候，根据nagle算法，第一个段head可以立即发送，因为没有 等待确认的段；接收端收到head，但是包不完整，继续等待body达到并延迟ACK；发送端继续写入body，这时候nagle算法起作用了，因为 head还没有被ACK，所以body要延迟发送。这就造成了发送端和接收端都在等待对方发送数据的现象，发送端等待接收端ACK head以便继续发送body，而接收端在等待发送方发送body并延迟ACK，悲剧的无以言语。这种时候只有等待一端超时并发送数据才能继续往下走。

   正因为nagle算法和delayed ack的影响，再加上这种write-write-read的编程方式造成了很多网贴在讨论为什么自己写的网络程序性能那么差。然后很多人会在帖子里建议 禁用Nagle算法吧，设置TCP_NODELAY为true即可禁用nagle算法。但是这真的是解决问题的唯一办法和最好办法吗？

   其实问题不是出在nagle算法身上的，问题是出在write-write-read这种应用编程上。禁用nagle算法可以暂时解决问题，但是禁用 nagle算法也带来很大坏处，网络中充塞着小封包，网络的利用率上不去，在极端情况下，大量小封包导致网络拥塞甚至崩溃。因此，能不禁止还是不禁止的 好，后面我们会说下什么情况下才需要禁用nagle算法。对大多数应用来说，一般都是连续的请求——应答模型，有请求同时有应答，那么请求包的ACK其实 可以延迟到跟响应一起发送，在这种情况下，其实你只要避免write-write-read形式的调用就可以避免延迟现象，利用writev做聚集写或者 将head和body一起写，然后再read，变成write-read-write-read的形式来调用，就无需禁用nagle算法也可以做到不延 迟。

最后一个问题，什么情况下才应该禁用nagle算法？当你的应用不是这种连续的请求——应答模型，而是需要实时地单向发送很多小数据的时候或者请求是有间 隔的，则应该禁用nagle算法来提高响应性。一个最明显是例子是telnet应用，你总是希望敲入一行数据后能立即发送给服务器，然后马上看到应答，而 不是说我要连续敲入很多命令或者等待200ms才能看到应答。