7，TCP的流量控制

7.1，利用滑动窗口实现流量控制

一般说来，我们总是希望数据传输得更快一些。但如果发送方把数据发送得过快，接收方就可能来不及接收，这就会造成数据的丢失。

流量控制就是让发送方的发送速率不要太快，既要让接收方来得及接收，也不要使网络发生拥塞。

利用滑动窗口机制可以很方便地在 TCP 连接上实现流量控制。

B 向 A 发送了零窗口的报文段后不久，B 的接收缓存又有了一些存储空间。于是 B 向 A 发送了 rwnd = 400 的报文段。但这个报文段在传送过程中丢失了。A一直等待收到 B 发送的非零窗口的通知，而 B 也一直等待 A 发送的数据。

如果没有其他措施，这种互相等待的死锁局面将一直延续下去。为了解决这个问题，TCP 为每一个连接设有一个持续计时器。

持续计时器

• 只要 TCP 连接的一方收到对方的零窗口通知，就启动该持续计时器。
• 若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带 1 字节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。
• 若窗口仍然是零，则收到这个报文段的一方就重新设置持续计时器。
• 若窗口不是零，则死锁的僵局就可以打破了。

7.2，必须考虑传输效率

可以用不同的机制来控制 TCP 报文段的发送时机:

• 第一种机制是 TCP 维持一个变量，它等于最大报文段长度 MSS。只要缓存中存放的数据达到 MSS 字节时，就组装成一个 TCP 报文段发送出去。
• 第二种机制是由发送方的应用进程指明要求发送报文段，即 TCP 支持的推送 (push)操作。
• 第三种机制是发送方的一个计时器期限到了，这时就把当前已有的缓存数据装入报文段（但长度不能超过 MSS）发送出去。

8，TCP的拥塞控制

8.1，拥塞控制的一般原理

拥塞：在某段时间，若对网络中某资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。

若网络中有许多资源同时产生拥塞，网络的性能就要明显变坏，整个网络的吞吐量将随输入负荷的增大而下降。

拥塞原因：对资源的需求>可用资源

【问题】增加资源能解决拥塞吗？

【答案】不能。这是因为网络拥塞是一个非常复杂的问题。简单地采用上述做法，在许多情况下，不但不能解决拥塞问题，而且还可能使网络的性能更坏。

网络拥塞的主要原因：

• 增大缓存，但未提高输出链路的容量和处理机的速度，排队等待时间将会大大增加，引起大量超时重传，解决不了网络拥塞；
• 提高处理机处理的速率会会将瓶颈转移到其他地方；

拥塞控制和流量控制的区别

• 拥塞控制就是防止过多的数据注入到网络中，使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。
• 拥塞控制是一个全局性的过程，涉及到所有的主机、所有的路由器，以及与降低网络传输性能有关的所有因素。
• 流量控制往往指点对点通信量的控制，是个端到端的问题（接收端控制发送端）。
• 流量控制所要做的就是抑制发送端发送数据的速率，以便使接收端来得及接收。

拥塞控制和流量控制之所以常常被弄混，是因为某些拥塞控制算法是向发送端发送控制报文，并告诉发送端，网络已出现麻烦，必须放慢发送速率。这点又和流量控制是很相似的。

拥塞控制的方法

• 开环控制方法就是在设计网络时事先将有关发生拥塞的因素考虑周到，力求网络在工作时不产生拥塞。
• 闭环控制方法是基于反馈环路的概念。属于闭环控制的有以下几种措施： (1) 监测网络系统以便检测到拥塞在何时、何处发生。(2) 将拥塞发生的信息传送到可采取行动的地方。(3) 调整网络系统的运行以解决出现的问题。

监测网络的拥塞的指标：由于缺少缓存空间而被丢弃的分组的百分数；平均队列长度；超时重传的分组数；平均分组时延；分组时延的标准差。

8.2，TCP拥塞控制方法

TCP 采用基于窗口的方法进行拥塞控制。该方法属于闭环控制方法。

TCP发送方维持一个拥塞窗口CWND

拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。
发送端利用拥塞窗口根据网络的拥塞情况调整发送的数据量。
所以，发送窗口大小不仅取决于接收方公告的接收窗口，还取决于网络的拥塞状况，所以真正的发送窗口值为：min(公告窗口值，拥塞窗口值)

控制拥塞窗口的原则

只要网络没有出现拥塞，拥塞窗口就可以再增大一些，以便把更多的分组发送出去，这样就可以提高网络的利用率。
但只要网络出现拥塞或有可能出现拥塞，就必须把拥塞窗口减小一些，以减少注入到网络中的分组数，以便缓解网络出现的拥塞。

拥塞的判断

• 重传定时器超时：现在通信线路的传输质量一般都很好，因传输出差错而丢弃分组的概率是很小的（远小于 1 %）。只要出现了超时，就可以猜想网络可能出现了拥塞。
• 收到三个相同（重复）的ACK：个别报文段会在网络中丢失，预示可能会出现拥塞（实际未发生拥塞），因此可以尽快采取控制措施，避免拥塞。

【慢开始】由小到大逐渐增大拥塞窗口数值。

初始拥塞窗口 cwnd 设置：旧的规定：在刚刚开始发送报文段时，先把初始拥塞窗口cwnd 设置为 1 至 2 个发送方的最大报文段 SMSS的数值。新的 RFC 5681 把初始拥塞窗口 cwnd 设置为不超过2至4个SMSS 的数值。

使用慢开始算法后，每经过一个传输轮次，拥塞窗口 cwnd 就加倍。

慢开始门限 ssthresh（状态变量）：防止拥塞窗口cwnd 增长过大引起网络拥塞。

• 当 cwnd < ssthresh 时，使用慢开始算法。
• 当 cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法。
• 当 cwnd = ssthresh 时，既可使用慢开始算法，也可使用拥塞避免算法。

【拥塞避免】

算法思路：让拥塞窗口 cwnd 缓慢地增大，即每经过一个往返时间 RTT 就把发送方的拥塞窗口 cwnd 加 1，而不是加倍，使拥塞窗口 cwnd 按线性规律缓慢增长。拥塞避免阶段就有“加法增大”的特点。这表明在拥塞避免阶段，拥塞窗口 cwnd 按线性规律缓慢增长，比慢开始算法的拥塞窗口增长速率缓慢得多。

无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（重传定时器超时）：

• ssthresh = max(cwnd/2，2)；cwnd = 1；执行慢开始算法，这样做的目的就是要迅速减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够时间把队列中积压的分组处理完毕。
• “拥塞避免”并非指完全能够避免了拥塞。利用以上的措施要完全避免网络拥塞还是不可能的。
• “拥塞避免”是说在拥塞避免阶段把拥塞窗口控制为按线性规律增长，使网络比较不容易出现拥塞。

【快重传和快恢复算法】

采用快重传FR算法可以让发送方尽早知道发生了个别报文段的丢失。

快重传 算法首先要求接收方不要等待自己发送数据时才进行捎带确认，而是要立即发送确认，即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认。

发送方只要一连收到三个重复确认（3-ACK），就知道接收方确实没有收到报文段，因而应当立即进行重传（即“快重传”），这样就不会出现超时，发送方也不就会误认为出现了网络拥塞。

不难看出，快重传并非取消重传计时器，而是在某些情况下可更早地重传丢失的报文段。

当发送端收到连续三个重复的确认时，由于发送方现在认为网络很可能没有发生拥塞，因此现在不执行慢开始算法，而是执行快恢复算法 FR 算法：

• 慢开始门限 ssthresh = 当前拥塞窗口 cwnd / 2 ；
• 新拥塞窗口 cwnd = 慢开始门限 ssthresh ；
• 开始执行拥塞避免算法，使拥塞窗口缓慢地线性增大。

8.3，主动队列管理AQM

重传会使 TCP 连接的发送端认为在网络中发生了拥塞。于是在 TCP 的发送端就采取了拥塞控制措施，但实际上网络并没有发生拥塞。

网络层的策略对 TCP 拥塞控制影响最大的就是路由器的分组丢弃策略。

先进先出FIFO处理规则

路由器的队列通常都是按照“先进先出”FIFO (First In First Out) 的规则处理到来的分组。

尾部丢弃策略：当队列已满时，以后再到达的所有分组（如果能够继续排队，这些分组都将排在队列的尾部）将都被丢弃。路由器的尾部丢弃往往会导致一连串分组的丢失，这就使发送方出现超时重传，使 TCP 进入拥塞控制的慢开始状态，结果使 TCP 连接的发送方突然把数据的发送速率降低到很小的数值。

全局同步：若发生了路由器中的尾部丢弃，就可能会同时影响到很多条 TCP 连接，结果使这许多 TCP 连接在同一时间突然都进入到慢开始状态。全局同步使得全网的通信量突然下降了很多，而在网络恢复正常后，其通信量又突然增大很多。

主动队列管理AQM——随机早期检测RED

所谓“主动”就是不要等到路由器的队列长度已经达到最大值时才不得不丢弃后面到达的分组。这样就太被动了。应当在队列长度达到某个值得警惕的数值时（即当网络拥塞有了某些拥塞征兆时），就主动丢弃到达的分组。使路由器的队列维持两个参数：队列长度最小门限 THmin 和最大门限 Thmax 。RED 对每一个到达的分组都先计算平均队列长度 LAV 。

（1）若平均队列长度小于最小门限 THmin，则将新到达的分组放入队列进行排队。

（2）若平均队列长度超过最大门限 THmax，则将新到达的分组丢弃。

（3）若平均队列长度在最小门限 THmin 和最大门限THmax 之间，则按照某一概率 p 将新到达的分组丢弃。

9，TCP的运输连接管理

运输连接有三个阶段：连接建立，数据传送，连接释放。

问题：(1) 要使每一方能够确知对方的存在。(2) 要允许双方协商一些参数（如最大窗口值、是否使用窗口扩大选项和时间戳选项以及服务质量等）。(3) 能够对运输实体资源（如缓存大小、连接表中的项目等）进行分配。

连接方式：采用客户（主动发起连接建立的应用进程）服务器（被动等待连接建立的应用进程）方式

9.1，TCP的连接建立

TCP的三次握手过程：

• 客户端发送 SYN 报文段，其中 SYN 标志位被置为 1，表示请求建立连接。
• 服务端收到客户端的 SYN 报文段后，向客户端发送 SYN-ACK 报文段，其中 SYN 和 ACK 标志位都被置为 1，表示确认客户端的 SYN 报文段，同时请求建立连接。
• 客户端收到服务端的 SYN-ACK 报文段后，向服务端发送 ACK 报文段，其中 ACK 标志位被置为 1，表示确认服务端的 SYN-ACK 报文段，建立连接。

【问题】为啥不是两次握手？

【答案】防止网络中延迟的数据报文段长时间滞留，占用网络资源。如果只进行两次握手，服务端收到连接请求后发送了确认报文，但是这个确认报文由于某些原因在网络上滞留，服务端会以为连接已经建立，如果此时客户端又发送了连接请求，服务端就会认为这是一个新的连接请求，而对其进行确认，这样就会导致服务端与多个客户端建立了连接，从而引发了错误。

【问题】为啥不是四次握手？

【答案】四次握手的过程会增加连接建立的时间和复杂度，同时也会增加网络传输的开销和资源占用。A，B两人打电话，A：你能听到我声音吗？B：我能听到，你能听到我声音吗？A： 我可以听到！

9.2，TCP的连接释放

TCP四次挥手过程：由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能 发送一个FIN来终止这个方向的连接。收到一个FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。

• TCP客户端发送一个FIN，用来关闭客户到服务器的数据传送。
• 服务器收到这个FIN，它发回一个ACK，确认序号为收到的序号加1。和SYN一样，一个FIN将占用一个 序号。
• 服务器关闭客户端的连接，发送一个FIN给客户端。
• 客户端发回ACK报文确认，并将确认序号设置为收到序号加1。

【问题】为啥不是三次挥手？ 

【答案】（1）在数据传输完成后，通信双方需要通过四次挥手来确保数据的完整性。如果只进行三次挥手，则可能会导致通信双方收到不完整的数据。（2）在四次挥手中，第二次挥手和第三次挥手之间存在一个时间间隔，以等待确认消息的到达。如果只进行三次挥手，则可能会在等待确认消息的过程中导致数据包的延迟。

【问题】为啥不是五次挥手？

【答案】完全资源浪费，简单的举个例子。A，B两人打电话，A：我话说完了，挂掉吧！B：好的，等我说完***！B： 我说完了，可以挂了！A：我挂了！

A必须等待2MSL的时间：第一，为了保证 A 发送的最后一个 ACK 报文段能够到达 B。第二，防止 “已失效的连接请求报文段”出现在本连接中。A 在发送完最后一个 ACK 报文段后，再经过时间 2MSL，就可以使本连接持续的时间内所产生的所有报文段，都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。