计算机网络自顶向下方法第三章笔记

前言：适逢期中考。。。。
本文参考自很多文章、课本、PPT等（其实仔细观察你会发现很多文字甚至图片都是一致的），如有雷同，纯属不巧合（抱拳）

---

三、运输层

3.1 概述和运输层服务

3.1.1 运输层和网络层的关系

• 网络层提供了 主机 之间的逻辑通信。而运输层为运行在 不同主机上的进程 提供逻辑通信。
• 运输层协议只工作在端系统上。
• 运输协议能提供的服务受制于底层网络协议的服务模型。
• 网络层协议，即 IP 协议，其服务模型是 尽力而为交付服务 ，但不做任何的保证。是 不可靠服务 。
• 参照书上以东西海岸两个家庭互相写信的经典例子
• 进程 = 堂兄弟姐妹
• 主机 = 家庭
• 运输层协议 = Ann 和 Bill（孩子里收信发信的大哥大姐），分发到兄弟姐妹中，将信从一个人（进程）送到另一个人
• 网络层协议 = 邮政服务，将信从一个家庭（主机）传给另一个家庭
• 运输层协议只工作在主机（端系统）中 = Ann 和 Bill 只在家工作，将信拿到门口的邮箱
• 多种运输层协议，多种服务模型 = Ann 和 Bill 外出，Susan 和 Harvey来收信发信，结果年龄太小，收发邮件次数少，也老丢信
• 运输层服务受制于网络层服务 = 邮政大哥若三天来一次，Ann和Bill就不可能两天收发一次信
• 运输层协议能为应用程序提供可靠数据传输服务 = 若邮政大哥把信弄脏弄丢弄混，Ann 和 Bill 可以清理整理信件，或者让对方下次重新发一次
• 运输层协议能确保应用程序报文不受入侵读取 = 尽管邮政大哥可能被别人骗或者强行看了信件，Ann 和 Bill 也能规定加密方式对信的内容进行加解密，弟弟妹妹们只需要看信的内容
• 多路分解 = Bill 和 Ann从邮递大哥拿到信件，看收信人名字（端口号），然后分别交到他们手上
• 多路复用 = Bill 和 Ann从弟弟妹妹手里拿到信件，帮他们装填信封写上信息
  ###3.1.2 因特网运输层概述
• UDP 提供了一种不可靠、无连接的服务。
• TCP 提供了一种可靠的、面向连接的服务。
• 进程到进程的数据交付和差错检测是两种最低限度的运输层服务，也是 UDP 能提供的仅有的两种服务。

3.2 多路复用与多路分解

• 多路分解： 将运输层报文段中的数据交付到正确的套接字。
• 多路复用： 在源主机从不同的套接字中收集数据块，并为每个数据块封装上首部信息从而生成报文段，然后将报文传递到网络层。
• 运输层多路复用要求：
• 套接字有唯一标识符。
• 每个报文段有特殊字符（端口号）来指示该报文段所要交付到的套接字。
• 端口号：一个 16 比特的数，在 0 ~ 65535 之间。其中 0 ~ 1023 是周知端口号，是受限制的。

3.2.1 无连接的多路复用与多路分解

• 一个 UDP 套接字由（目的IP地址，目的端口号）标识。注意是用来标识，不是只有这两个相关字段，还有源端口号、源IP地址字段。源端口号和目的端口号按传递方向反转
• 通常，应用程序的客户端让运输层自动地分配端口号，而服务器则分配一个特定的端口号。

3.2.2 面向连接的多路复用与多路分解

TCP 套接字是由一个四元组（源 IP 地址，源端口号，目的 IP 地址，目的端口号）来标识的。

3.3 无连接运输：UDP

• 选择 UDP 的原因：
• 关于何时、发送什么数据的应用层控制更为精细。
• 无需连接建立。
• 无连接状态。
• 分组首部开销小。
• 用 UDP 建立可靠数据传输机制可以在应用层中实现。

3.3.1 UDP 报文结构

首部只有 4 个字段，每个字段 2 字节 16 位。其中，长度指示了 UDP 报文段中的首部加数据的字节数。

3.3.2 UDP 检验和

检验和 是 UDP 的差错检测机制。其实现方法是：

1. 将 UDP 报文按 16 比特进行分组。
2. 先取前面两个16比特数字进行加运算，有溢出记得回卷，即溢出位加到最低位再进行加运算
3. 2中得到的数再跟下一个16比特数字进行加运算，直到报文末端
4. 将最终得到的 16 比特的数按位取反即为检验和。

• 注：计算之前的检验和为 0
• 如果传输没有出错，则在接收方处计算的的检验和将是 11111111111111。若不是，则数据有错。

3.4 可靠数据传输原理

3.4.1 构造可靠数据传输协议

• 经完全可靠信道的可靠数据传输 rdt1.0
• 有限状态机
• 有完全可靠的信道，接收方就不需要提供任何反馈信息给发送方
• 经具有比特差错信道的可靠数据传输 rdt2.0
• 自动重传请求协议（ARQ，又叫停等协议）
• 处理比特差错还需三种协议功能：
  • 差错检测。需要利用额外的比特（组原中海明码、奇偶校验码之类）
  • 接收方反馈。肯定确认ACK（收到了），否定确认NAK（请再传一遍），接收方没收到确认就不能发送（停等协议）
    • 考虑ACK、NAK分组受损的可能性，在数据分组中添加新字段，分组序号0和1（向前取模）
  • 重传。接收方收到有差错分组时，发送方重传该分组。
• 经具有比特差错的丢包信道的可靠数据传输 rdt3.0（ 比特交替协议）
• 发送方负责检测和回复丢包工作，对每一个分组维护一个定时器。如果在一个时间段内没收到ACK，则判定为丢包，重传分组，这也引入了冗余数据分组的可能性（时延很大的情况）
• 

3.4.2 流水线可靠数据传输

• rdt 3.0 是一个功能正确的协议，但是由于它是一个停等协议，大部分的时间都浪费在等待确认上面，所以性能不好。
• 解决这种特殊性能问题的一个简单的方法是：不使用停等方式运行，允许发送方发送多个分组而无需等待确认。这种技术被称为 流水线。
• 要使用流水线技术，则须：
• 增加序号范围。因为要传送多个分组，而每个传输中的分组必须有一个单独的序号。
• 协议的发送方和接收方两端必须能缓存多个分组。发送方至少得能缓存那些已发送但未确认的分组，而接收方或许也需要缓存那些已经正确接收的分组。
• 所需序号的范围和对缓冲的要求取决于数据传输协议如何处理丢失、损坏及延时过大的分组。
• 流水线的差错恢复有两种基本方法：
  • 回退 N 步
  • 选择重传
• 

3.4.3 回退 N 步（GBN，又叫滑动窗口协议）

• 在 回退 N 步协议 中，允许发送方发送多个分组而不需等待确认，但它也受限于在流水线中未确认的分组数不能超过某个最大允许数 N。
  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JtSEc0m4-1606406886001)(http://ooe7llkit.bkt.clouddn.com/%E7%BD%91%E7%BB%9C_C3_10.PNG)]
• 基序号（base）为最早的未确认分组的序号。
• 下一个序号（nextseqnum）为下一个待发分组的的序号。
• N 常被称为 窗口长度，GBN 协议也常被称为 滑动窗口协议。
• GBN 的发送方必须响应三种类型的事件：
• 上层的调用：若窗口未满，则产生一个分组将其发送。
• 收到一个 ACK：对序号为 n 的分组的确认采取 累积确认，表明接收方已正确接收到包括 n 的序号在内的 n 的以前的所有分组。
• 超时事件：只使用一个定时器，即最早的已发送但未被确认的分组所使用的定时器。如果出现超时，则发送方重传所有已发送但还未被确认的分组。如果收到一个 ACK，但仍有已发送但未被确认的分组，则重启定时器。如果没有已发送但未确认的分组，该定时器被终止。
• GBN正常传输时
• 
• GBN丢失帧时
• 

3.4.4 选择重传（SR）

• GBN 也存在一些性能问题，单个分组的错误会引起大量分组的重传。
• 选择重传 通过让发送方仅重传那些它怀疑在接收方出错的分组而避免了不必要的重传。
• 下图是选择重传发送方和接收方的序号空间：
• [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-GBgAUrBr-1606406886006)(http://ooe7llkit.bkt.clouddn.com/%E7%BD%91%E7%BB%9C_C3_13.PNG)]
• SR 发送方的事件和动作：
• 从上层接收数据： 检查下一个可用于该分组的序号，若在发送方的窗口内，则将数据打包发送。
• 超时： 定时器再次用来防止丢失分组。但是现在每个分组必须得有单独的定时器。
• 收到 ACK：倘若该分组序号在窗口内，则 SR 发送方将那个被确认的分组标记为已接收。如果该分组的序号等于send_base，则窗口基序号向前移动到具有最小序号的未确认分组处。如果窗口移动了并且该序号落在窗口内的未发送分组，则发送这些分组。
• SR 接收方将确认一个正确接收的分组而不管其是否按序。
• SR 接收方的事件和动作：
• 序号在 [rcv_base, rcv_base + N -1] 内的分组被正确接收：在此情况下，收到的分组落在接收方的窗口内，一个选择 ACK 被回送给发送方。如果该分组以前没收到过，则缓存该分组。如果该分组的序号等于接收窗口的基序号，则该分组及以前缓存的序号连续的分组交付给上层。
• 序号在 [rcv_base - N, rcv_base - 1] 内的分组被正确接收： 产生一个 ACK，即使该分组是接收方以前已确认过的分组。
• 其他情况：忽略该分组。
• 窗口长度必须小于或等于序号空间大小的一半。
• 
• 问题
• 
• 接收方：在(a)和(b)两种情况下接收方没有发现差别!
• 在 (a)中不正确地将新的冗余的当为新的，而在(b)中不正确地将新的当作冗余的

3.5 面向连接的运输：TCP

3.5.1 TCP 连接

特点

• TCP是面向连接的
  通信前需要建立连接，通信结束需要释放连接。
• TCP提供可靠交付服务
  所谓『可靠』指的是：TCP发送的数据无重复、无丢失、无错误、与发送端顺序一致。
• TCP是面向字节流的
  所谓『面向字节流』指的是：TCP以字节为单位。虽然传输的过程中数据被划分成一个个数据报，但这只是为了方便传输，接收端最终接受到的数据将与发送端的数据一模一样。
• TCP提供全双工通信
  所谓『全双工通信』指的是：TCP的两端既可以作为发送端，也可以作为接收端。
• 一条TCP连接的两端只能有两个端点
  TCP只能提供点到点的通信，而UDP可以任意方式的通信。
  ####TCP连接与套接字
• 什么是『TCP连接』？
  TCP连接是一种抽象的概念，表示一条可以通信的链路。
  每条TCP连接有且仅有两个端点，表示通信的双方。且双发在任意时刻都可以作为发送者和接收者。
• 什么是『套接字』？
  一条TCP连接的两端就是两个套接字。
  套接字=IP地址:端口号。
  因此，TCP连接=（套接字1，套接字2）=（IP1:端口号1，IP2:端口号2）

TCP三次握手

PS：TCP协议中，主动发起请求的一端称为『客户端』，被动连接的一端称为『服务端』。不管是客户端还是服务端，TCP连接建立完后都能发送和接收数据。

起初，服务器和客户端都为CLOSED状态。在通信开始前，双方都得创建各自的传输控制块（TCB）。
服务器创建完TCB后遍进入LISTEN状态，此时准备接收客户端发来的连接请求。

第一次握手

客户端向服务端发送连接请求报文段。该报文段的头部中SYN=1，ACK=0，seq=x。请求发送后，客户端便进入SYN-SENT状态。

• PS1：SYN=1，ACK=0表示该报文段为连接请求报文。
• PS2：x为本次TCP通信的字节流的初始序号。
  TCP规定：SYN=1的报文段不能有数据部分，但要消耗掉一个序号。

第二次握手

服务端收到连接请求报文段后，如果同意连接，则会发送一个应答：SYN=1，ACK=1，seq=y，ack=x+1。
该应答发送完成后便进入SYN-RCVD状态。

• PS1：SYN=1，ACK=1表示该报文段为连接同意的应答报文。
• PS2：seq=y表示服务端作为发送者时，发送字节流的初始序号。
• PS3：ack=x+1表示服务端希望下一个数据报发送序号从x+1开始的字节。

第三次握手

当客户端收到连接同意的应答后，还要向服务端发送一个确认报文段，表示：服务端发来的连接同意应答已经成功收到。
该报文段的头部为：ACK=1，seq=x+1，ack=y+1。
客户端发完这个报文段后便进入ESTABLISHED状态，服务端收到这个应答后也进入ESTABLISHED状态，此时连接的建立完成！

为什么连接建立需要三次握手，而不是两次握手？

防止失效的连接请求报文段被服务端接收，从而产生错误。

PS：失效的连接请求：若客户端向服务端发送的连接请求丢失，客户端等待应答超时后就会再次发送连接请求，此时，上一个连接请求就是『失效的』。

若建立连接只需两次握手，客户端并没有太大的变化，仍然需要获得服务端的应答后才进入ESTABLISHED状态，而服务端在收到连接请求后就进入ESTABLISHED状态。此时如果网络拥塞，客户端发送的连接请求迟迟到不了服务端，客户端便超时重发请求，如果服务端正确接收并确认应答，双方便开始通信，通信结束后释放连接。此时，如果那个失效的连接请求抵达了服务端，由于只有两次握手，服务端收到请求就会进入ESTABLISHED状态，等待发送数据或主动发送数据。但此时的客户端早已进入CLOSED状态，服务端将会一直等待下去，这样浪费服务端连接资源。

三次握手后

发送方通过套接字向TCP的发送缓存中传输数据，当数据达到最大报文段长（MSS）时TCP就将缓存加上一个TCP首部形成报文段发送给接收方的TCP接收缓存。

TCP四次挥手

TCP连接的释放一共需要四步，因此称为『四次挥手』。
我们知道，TCP连接是双向的，因此在四次挥手中，前两次挥手用于断开一个方向的连接，后两次挥手用于断开另一方向的连接。

第一次挥手

若A认为数据发送完成，则它需要向B发送连接释放请求。该请求只有报文头，头中携带的主要参数为：
FIN=1，seq=u。此时，A将进入FIN-WAIT-1状态。

• PS1：FIN=1表示该报文段是一个连接释放请求。
• PS2：seq=u，u-1是A向B发送的最后一个字节的序号。

第二次挥手

B收到连接释放请求后，会通知相应的应用程序，告诉它A向B这个方向的连接已经释放。此时B进入CLOSE-WAIT状态，并向A发送连接释放的应答，其报文头包含：
ACK=1，seq=v，ack=u+1。

• PS1：ACK=1：除TCP连接请求报文段以外，TCP通信过程中所有数据报的ACK都为1，表示应答。
• PS2：seq=v，v-1是B向A发送的最后一个字节的序号。
• PS3：ack=u+1表示希望收到从第u+1个字节开始的报文段，并且已经成功接收了前u个字节。
  A收到该应答，进入FIN-WAIT-2状态，等待B发送连接释放请求。

第二次挥手完成后，A到B方向的连接已经释放，B不会再接收数据，A也不会再发送数据。但B到A方向的连接仍然存在，B可以继续向A发送数据。

第三次挥手

当B向A发完所有数据后，向A发送连接释放请求，请求头：FIN=1，ACK=1，seq=w，ack=u+1。B便进入LAST-ACK状态。

第四次挥手

A收到释放请求后，向B发送确认应答，此时A进入TIME-WAIT状态。该状态会持续2MSL时间，若该时间段内没有B的重发请求的话，就进入CLOSED状态，撤销TCB。当B收到确认应答后，也便进入CLOSED状态，撤销TCB。

为什么A要先进入TIME-WAIT状态，等待2MSL时间后才进入CLOSED状态？

为了保证B能收到A的确认应答。
若A发完确认应答后直接进入CLOSED状态，那么如果该应答丢失，B等待超时后就会重新发送连接释放请求，但此时A已经关闭了，不会作出任何响应，因此B永远无法正常关闭。

TCP连接概括

客户机端TCP发送一个特殊报文段，不包含应用层数据，但首部的SYN置1，并选择一个起始序号client_isn放置到该报文序号字段中。服务器接收后为该TCP建立分配TCP缓存和变量，并发送允许报文段，SYN置1，确认号为client_isn+1，序号段中则是自己的初始序号server_isn，客户端收到这个报文后也会分配缓存和变量。并发送第三个报文，SYN置0，确认字段为server_isn+1，目的是确认信息。这个过程被称作三次握手。连接终止时客户端发出FIN置1的报文，服务器也发挥FIN置1报文，客户端确认后双方释放资源。

3.5.2 TCP 报文段结构

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Vd6LzUh4-1606406886012)(https://leanote.com/api/file/getImage?fileId=589ed2daab644113b3000658)]

• 16 比特的 源端口号 和 16 比特的目的 端口号。用于多路分解和多路复用。
• 32 比特的 **序号（sequence number）**字段。一个报文段的序号 是该报文段数据字段首字节的序号。
• 32 比特的 确认号（Acknowledgement number）字段。主机 A　填充进报文段的确认号是主机 A 期望从主机 B 收到的下一字节的序号
• 16 比特的 **接收窗口（Receive window）**字段。用于指示接收方愿意接收的字节数量。
• 4 比特的 **首部长度（header length）**字段。指示了以 32 比特的字为单位的 TCP 首部长度。
• 可变与变长的 **选项（options）**字段。用于发送方与接收方协商最大报文段长度时，或在高速网络环境下作用窗口调节因子时使用。
• 6 比特的 **标志（flag）**字段。
• ACK 是对成功接收一个报文段的确认。
• RST、SYN 和 FIN 用于连接的建立和拆除。
• PSH 被设置时，指示接收方应立即将数据交给上层。
• URG 比特用来指示报文段里存在着被发送端上层实体置为“紧急”的数据。紧急的最后一个字节由 16 比特的 紧急数据指针（Urgent data pointer）字段 指出。
• 注：在实践中，PSH 、URG 和 紧急数据指针 并不 使用。

3.5.3 往返时间的估计与超时

• 如何设置TCP 超时值
• 应大于RTT：但RTT是变化的
• 太短: 过早超时，不必要的重传
• 太长: 对报文段的丢失响应太慢
• TCP采用超时/重传机制处理报文段丢失
• 估计往返时间
• 报文段的样本RTT：SampleRTT
• SampleRTT 均值：EstimatedRTT
• EstimatedRTT=0.875∗EstimeatedRTT+0.125∗SampleRTT
• 设置和管理超时重传时间
• TimeoutInterval=EstimatedRTT+4∗DevRTT
• 超时间隔 = 估计RTT + 4*偏差RTT

3.5.4 可靠数据传输

PS：网络层传输的数据单元为『数据报』，传输层的数据单元为『报文段』，为了方便起见可以统称为『分组』。

• 三种情况
• A向B发送一个报文段，序号92，包含8字节，交给IP后开始等待一个来自B的确认号为100的报文段。然而确认报文段丢失，超时，A又重发相同报文段。B收到后对比序号发现已经收到过该报文段的一些字节，于是B的TCP确认后，将报文段重复的字节丢弃
• 
• A连续发了两个报文段，92，8和100，20（序号和字节）。B收到两个报文段并发送确认100和200。超时前没有一个确认到达A，超时后A重传92，8的报文，重启定时器。只要第二个报文的ACK在新的超时以前发生到达，第二个报文就不会重传。
• 
• 和上面一种一样，A发送两个报文段，第一个报文段的确认在网络丢失，但是超时之前收到了第二个报文段的确认报文。因为累积确认机制，A知道B已经收到第二个以及之前的报文，不会重传了
• 
• 超时间隔加倍
• 实际大多数情况下，每次TCP重传时会将下次超时间隔设为先前的两倍
• 当定时器在另外两个事件（收到上层应用数据，收到ACK）中的任意一个启动时，超时间隔又从估计RTT和偏差RTT推算得到。比如一个报文段第一次超时1s，重发，第二次超时就是2s，第三次4s…但是当收到该报文确认时，超时间隔又重置，算是一种拥塞控制
• 快速重传
• 发送方挨个发送大量报文段，如果一个丢失，很可能引起一个接一个冗余ACK（即重复的ACK，上面说过，A连续发了序号为1，2，3，4，5的报文，若B没收到2，却收到了3，4，5，则对2之后的报文都发送确认号为2的ACK）。如果TCP发送方接收到对相同数据的3个冗余ACK，它把这当做一种指示，说明这个重复确认报文段后面的报文都丢失了。一旦收到3个冗余ACK，TCP执行快速重传，即在该报文段的定时器过期之前重传丢失的报文段
• 
• 回退N步 or 选择重传
• TCP确认是累积式的，正确接收但失序的报文段是不会被接收方逐个确认的，像GBN风格
• 但是TCP和GBN有显著区别
  • 许多TCP实现会将正确接收但失序的报文段缓存起来
  • GBN不仅重传未确认分组，还会重传之后所有分组，TCP只传一个或不传（若其后面的ACK超时前到来）
• 选择确认，允许接收方有选择地确认失序报文段，而不是累积确认最后一个正确接收的有序报文段。该机制与选择重传机制结合（跳过重传已确认报文段），TCP看起来像SR
• TCP的差错恢复机制是GBN协议和SR协议的混合体

3.5.5 流量控制

• 什么是流量控制？
  如果发送者发送过快，接收者来不及接收，那么就会有分组丢失。为了避免分组丢失，控制发送者的发送速度，使得接收者来得及接收，这就是流量控制。
  流量控制是一个速度匹配服务，发送方发送速率与接收方程序读取速率相匹配
• 流量控制的目的？
  流量控制根本目的是防止分组丢失，它是构成TCP可靠性的一方面。
• 如何实现流量控制？
  由滑动窗口协议（连续ARQ协议，如GBN和SR）实现，TCP让发送方维护一个称为接收窗口rwnd的变量，用于给发送方指示接收方还有多少可用缓存。因为是全双工通信，双方都维护接收窗口变量。B把rwnd值放入给A的报文段接收窗口字段中，通知A自己还有多少缓存空间，A控制未确认的数据量小于rwnd，即发送方的发送窗口不可以大于接收方发回的窗口大小。
  滑动窗口协议既保证了分组无差错、有序接收，也实现了流量控制。
• 流量控制引发的死锁
  考虑一种特殊的情况，就是接收方若没有缓存足够使用，就会发送零窗口大小的报文，此时发送放将发送窗口设置为0，停止发送数据。之后接收方有足够的缓存，发送了非零窗口大小的报文，但是这个报文在中途丢失的，发送者一直等待下去，而接收者以为发送者已经收到该应答，等待接收新数据，这样双方就相互等待，从而产生死锁。
• 持续计时器
  为了避免流量控制引发的死锁，TCP使用了持续计时器。每当发送者收到一个零窗口的应答后就启动该计时器。时间一到便主动发送报文询问接收者的窗口大小。若接收者仍然返回零窗口，则重置该计时器继续等待；若窗口不为0，则表示应答报文丢失了，此时重置发送窗口后开始发送，这样就避免了死锁的产生。
• 一条TCP连接每一侧主机都设置了缓存，当TCP连接收到正确有序的字节后，将数据放入缓存，应用从缓存中读取。若应用较忙，发送方发送太快太多，可能会造成缓存溢出
• TCP发送方因为IP网络的拥塞而降速（超时间隔加倍），属于拥塞控制，不属于流量控制，虽然都是降速
• UDP无流量控制，缓存溢出就溢出了

3.6 拥塞控制

3.6.1 拥塞原因与代价

• 丢包一般是当前网络拥塞时由于路由器缓存溢出引起，因此分组重传能作为网络拥塞的征兆，但分组重传无法解决网络拥塞
• 拥塞原因与代价
• 情况一：两个发送方和一台无穷大缓存的路由器
  • 容量为R的共享式输出链路上传输
  • 当发送速率超过R/2时，路由器的排队分组就会无限增加，源和目的平均时延变成无穷大
• 情况二：两个发送方和一台有限缓存的路由器
  • 分组到达一个已满的缓存时会被丢弃，发送方必须执行重传以补偿因为缓存溢出丢弃的分组
  • 发送方遇到高时延时，进行的不必要重传引起路由器转发不必要的分组副本
• 情况三：4个发送方和具有优先缓存的多台路由器及多条路径
  • 当一个分组沿一条路径被丢弃时，每个上游路由器用于转发该分组到丢弃该分组使用的传输容量被浪费
• 拥塞控制 和 流量控制 的区别？

1. 拥塞控制：拥塞控制是作用于网络的，它是防止过多的数据注入到网络中，避免出现网络负载过大的情况；
2. 流量控制：流量控制是作用于接收者的，它是控制发送者的发送速度从而使接收者来得及接收。

• 拥塞控制的目的？

1. 缓解网络压力
2. 保证分组按时到达

3.6.2 拥塞控制方法

• 拥塞控制可以分为端到端的和网络辅助两种，对应网络层是否为运输层拥塞机制提供显式帮助。TCP是端到端的拥塞机制，因为其网络下层IP协议并不提供拥塞机制。按照前面说的，首先TCP可以通过控制拥塞窗口的值控制发送方流量，通过超时和连收3个冗余ACK判断网络拥塞，如果出现就缩小窗口，否则就趁机放大窗口利用空闲带宽。

3.7 TCP拥塞控制

• TCP必须用端到端拥塞控制，因为IP层不向端系统提供显式网络拥塞反馈
• TCP让每一个发送方根据感知到的拥塞程度限制其发送速率
• 如何限制其发送速率？
  • 维护拥塞窗口cwnd值（注意流量控制使用接收窗口rwnd值）
  • 发送方未确认数据量 <= min { cwnd , rwnd }
• 如何感知它到目的地路径存在拥塞？
  • 丢包：超时或收到3个冗余ACK
• TCP是自计时的，使用确认来触发增大它的拥塞窗口长度（及其传输速率）
• TCP发送方如何确定发送速率？
• 一个丢失的报文意味着拥塞，当丢失报文段时应当降低速率（当前速度不能正常交付，得慢点）
• 先前未确认报文段的确认到达时，增加发送方速率（当前速度能够正常交付，说明可以再快点）
• 带宽探测（试探）：TCP发送方增加速率，丢包，从该速率后退，再往前探测…（因为拥塞情况是波动的，得尽力保持在最高速率）

TCP拥塞控制算法

• 慢启动算法 和 拥塞避免算法
• 发送方维护一个发送窗口，发送窗口的大小取决于网络的拥塞情况和接收窗口的大小，发送窗口是动态变化的。
• 发送方还维护一个慢启动门限
  发送窗口 < 慢启动门限：使用慢启动算法
  发送窗口 > 慢启动门限：使用拥塞避免算法
  发送窗口 = 慢启动门限：使用慢启动算法或拥塞避免算法
• 算法的具体过程：

1. 慢启动

• 一开始cwnd只设为一个MSS的较小值（这就是『慢』，不过瞬间指数级加速）
• 收到一个确认，cwnd增加一个MSS ——> 每过一个RTT，cwnd翻番，发送速率翻倍（1，2，4…每次发的也多一个）
• 丢包（拥塞）结束慢启动
  - 将ssthresh（慢启动阈值）设置为cwnd/2，cwnd置为1重新开始慢启动
  - 当cwnd=ssthresh时，结束慢启动，TCP转移到拥塞避免模式
  - 收到3个冗余ACK，执行快速重传，进入快速恢复模式

2. 拥塞避免

• 进入拥塞避免状态，cwnd值是上次遇到拥塞时的一半
• 每个RTT只将cwnd值增加一个MSS/cwnd字节
• 丢包，结束拥塞避免
  - 超时：ssthresh更新为cwnd的一半，cwnd置为1个MSS，返回慢启动状态
  - 冗余ACK：ssthresh更新为cwnd的一半，cwnd值减半，进入快速恢复状态

3. 快速恢复

• 快速恢复中，每个冗余ACK，cwnd 增加一个MSS，当丢失报文的ACK到达时，TCP降低cwnd，进入拥塞避免状态
• 超时：同慢启动和拥塞避免
• 总体上来说，如果没有拥塞，TCP每收到一个正常的确认报文，就将窗口扩大一个MSS（最大报文段），也就是多发一个报文，如果出现拥塞就将窗口大小缩小一半。该算法称作加性增，乘性减。
  首先，因为在开始阶段窗口初值一般仅为一个MSS，这样在很长一段时间内速率会很低，而可用带宽可能很大，为了尽快探明最大可用带宽，启动阶段每经过一个RTT，窗口值就增大一倍，直到出现一个报文丢失，这个特殊过程才结束。该过程称作慢启动。其次，遇到一个超时事件的时候，TCP将窗口值设成1个MSS，并慢启动到丢失报文前窗口值的一半。但是收到3个冗余ACK的时候并不慢启动而是直接减半，这种行为叫快速恢复。