面试答不上？计网很枯燥? 听说你学习 计网 每次记了都会忘？ 不妨抽时间和我一起多学学它👇 深入浅出，用你的空闲时间来探索计算机网络的硬核知识！
👇博主的上篇连载博客《初识图像处理技术》
图像处理技术：数字图像分割 ------ 图像分割、边界分割（边缘检测）、区域分割 - slowlydance2me - 博客园 (cnblogs.com)
2022-12-04 更新：纪念《漫谈计算机网络》连载博客完结啦！
漫谈计算机网络 连载的所有章节👇：
1.漫谈计算机网络：概述 ------ 从起源开始到分层协议结构，初识究竟什么是计算机网络？ - slowlydance2me - 博客园 (cnblogs.com)
2.漫谈计算机网络：物理层 ----- 双绞线&光纤？，从最底层开始了解计算机网络 - slowlydance2me - 博客园 (cnblogs.com)
3.漫谈计算机网络：数据链路层 ----- 数据链路路在何方? --从点对点数据传输 到 "广泛撒网,重点捕获"的局域网 - slowlydance2me - 博客园 (cnblogs.com)
4.漫谈计算机网络：网络层 ------ 重点：IP协议与互联网路由选择协议 - slowlydance2me - 博客园 (cnblogs.com)
5.漫谈计算机网络: 运输层 ------ 从UDP ->TCP , 从面向通信->面向用户，三次握手/四次挥手? - slowlydance2me - 博客园 (cnblogs.com)
6.漫谈计算机网络：应用层 ----- 从DNS域名解析到WWW万维网再到P2P应用 - slowlydance2me - 博客园 (cnblogs.com)
7.漫谈计算机网络：番外篇 ------网络安全相关知识——>公钥与私钥、防火墙与入侵检测 - slowlydance2me - 博客园 (cnblogs.com)
前言：
2022/11/27
众所周知，计算机网络在程序员的学习以及面试中占据十分重要的位置，同时它也是我们开启互联网世界的钥匙🔑。
因此，从今天（11/27）开始更新《漫谈计算机网络》一文，读者们可以跟着博主一起深入浅出，了解计算机网络知识，学习计算机网络的应用。
博主仍在不断学习进步中，在本文中对于计算机网络的理解与认识尚浅，如有错误之处烦请批评指正。
如有疑问欢迎评论区留言。
正文分割线：
今天更新！11/30
漫谈计算机网络：第五章-运输层
终于我们一步步走过计算机网络的道道难关，如今我们来到了-运输层
先来看看它在层次体系结构中的位置叭
👇
我们可以看到运输层既是面向通信的功能，也是用户功能
重点从这里开始👇
5.1 运输层协议概述
5.1.1 进程之间的通信
运输层的作用
运输层为应用层进程之间的通信提供服务
屏蔽作用
运输层向高层用户屏蔽了下面网络核心的细节（如网络拓扑、所采用的路由选择协议等），使应用进程看见的就是好像在两个运输层实体之间有一条端到端的逻辑通信信道。
可靠信道与不可靠信道
5.1.2 运输层的两个主要协议
互联网的正式标准：
1. 用户数据报协议 UDP (User Datagram Protocol)
2. 传输控制协议 TCP (Transmission Control
运输协议数据单元
两个对等运输实体在通信时传送的数据单位叫作运输协议数据单元 TPDU (Transport Protocol Data Unit)。
TCP 传送的数据单位协议是 TCP 报文段 (segment)。
UDP 传送的数据单位协议是 UDP 报文或用户数据报。
UDP 与 TCP 的区别
使用 UDP 和 TCP 的典型应用和应用层协议
5.1.3 运输层的端口
复用：应用进程都可以通过运输层再传送到 IP 层（网络层）。
分用：运输层从 IP 层收到发送给应用进程的数据后，必须分别交付给指明的各应用进程。
问:如何指明各应用进程？
需要考虑的问题
进程的创建和撤销都是动态的，因此发送方几乎无法识别其他机器上的进程。
我们往往需要利用目的主机提供的功能来识别终点，而不需要知道具体实现这个功能的进程是哪一个。
有时我们会改换接收报文的进程，但并不需要通知所有的发送方。
端口号 (protocol port number)
解决方法：在运输层使用协议端口号 (protocol port number)，或 通常简称为端口 (port)。把端口设为通信的抽象终点。
软件端口与硬件端口
软件端口:
• 协议栈层间的抽象的协议端口。
• 是应用层的各种协议进程与运输实体进行层间交互的地点。
• 不同系统实现端口的方法可以不同。
硬件端口
不同硬件设备进行交互的接口。
TCP/IP 运输层端口的标志
端口用一个 16 位端口号进行标志，允许有 65,535 个不同的端口号。
端口号只具有本地意义，只是为了标志本计算机应用层中的各进程。
在互联网中，不同计算机的相同端口号没有联系。
由此可见，两个计算机中的进程要互相通信，不仅必须知道对方的端口号，而且还要知道对方的
IP 地址
两大类、三种类型的端口
常用的熟知端口
5.2 用户数据报协议 UDP
5.2.1 UDP 概述
UDP 只在 IP 的数据报服务之上增加了一些功能：
1. 复用和分用
2. 差错检测
UDP 的主要特点
1. 无连接。发送数据之前不需要建立连接。
2. 使用尽最大努力交付。即不保证可靠交付。
3. 面向报文。UDP 一次传送和交付一个完整的报文。
4. 没有拥塞控制。网络出现的拥塞不会使源主机的发送速率降低。很适合多媒体通信的要求。
5. 支持一对一、一对多、多对一、多对多等交互通信。
6. 首部开销小，只有 8 个字节，比TCP的20个字节的首部短。UDP 通信的特点：简单方便，但不可靠。
UDP 通信的特点：简单方便，但不可靠。
UDP 是面向报文的
l 发送方 UDP 对应用层交下来的报文，既不合并，也不拆分，按照样发送。
l 接收方 UDP 对 IP 层交上来的 UDP 用户数据报，去除首部后就原封不动地交付上层的应用进程，一次交付一个完整的报文。
应用程序必须选择合适大小的报文。
1. 若报文太长，IP 层在传送时可能要进行分片，降低 IP 层的效率。
2. 若报文太短，会使 IP 数据报的首部的相对长度太大，降低 IP 层的效率。
UDP 通信和端口号的关系（多对一 / 一对多）
如下图👇
复用：将 UDP 用户数据报组装成不同的 IP 数据报，发送到互联网。
分用：根据 UDP 用户数据报首部中的目的端口号，将数据报分别传送到相应的端口，以便应用进程到端口读取数据。
5.2.2 UDP 的首部格式
(1) 源端口：源端口号。在需要对方回信时选用。不需要时可用全 0。
(2) 目的端口：目的端口号。终点交付报文时必须使用。
(3) 长度：UDP 用户数据报的长度，其最小值是 8（仅有首部）。
(4) 检验和：检测 UDP 用户数据报在传输中是否有错。有错就丢弃。
UDP 基于端口的分用
接收方 UDP 根据首部中的目的端口号，把报文通过相应的端口上交给应用进程。
如果接收方 UDP 发现收到的报文中的目的端口号不正确（即不存在对应于该端口号的应用进程），就丢弃该报文，并由 ICMP发送“端口不可达”差错报文给发送方。
计算 UDP 检验和的例子
5.3 传输控制协议 TCP 概述
5.3.1 TCP 最主要的特点
TCP 是面向连接的运输层协议，在无连接的、不可靠的 IP 网络服务基础之上提供可靠交付的服务。为此，在 IP 的数据报服务基础之上，增加了保证可靠性的一系列措施。
TCP 是面向连接的运输层协议。建立连接 -> 释放连接
每一条 TCP 连接只能有两个端点 (endpoint)，每一条 TCP 连接只能是点对点的（一对一）。
TCP 提供可靠交付的服务，数据无差错，不重复，按序到达。
TCP 提供全双工通信。
面向字节流
1. TCP 中的“流”(stream) 指的是流入或流出进程的字节序列。
2. 面向字节流：虽然应用程序和 TCP 的交互是一次一个数据块，但 TCP把应用程序交下来的数据看成仅仅是一连串无结构的字节流。
TCP 面向流的概念
TCP 不保证接收方应用程序所收到的数据块和发送方应用程序所发出的数据块具有对应大小的关系。 但接收方应用程序收到的字节流必须和发送方应用程序发出的字节流完全一样。
5.3.2 TCP 的连接
TCP 把连接作为最基本的抽象。
TCP 连接的端点：套接字 (socket) 或插口。
TCP 连接，IP 地址，套接字之间关系
TCP 连接就是由协议软件所提供的一种抽象。
TCP 连接的端点是抽象的套接字，即（IP 地址：端口号）。
同一个 IP 地址可以有多个不同的 TCP 连接。
同一个端口号也可以出现在多个不同的 TCP 连接中。
5.4 可靠传输的工作原理
IP 网络提供的是不可靠的传输
如图:
理想传输条件的特点
1. 传输信道不产生差错。
2. 不管发送方以多快的速度发送数据，接收方总是来得及处理收到的数据。
在理想传输条件下，不需要采取任何措施就能够实现可靠传输。
但实际网络都不具备理想传输条件。必须使用一些可靠传输协议，在不可靠的传输信道实现可靠传输。
5.4.1 停止等待协议
每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。
全双工通信的双方既是发送方也是接收方。
假设仅考虑 A 发送数据，而 B 接收数据并发送确认。因此 A 叫做发送方，而 B 叫做接收方。
1. 无差错情况
2. 出现差错
l 两种情况：
1. B 接收 M1 时检测出了差错，就丢弃 M1，其他什么也不做（不通知 A 收到有差错的分组）。
2. M1 在传输过程中丢失了，这时 B 当然什么都不知道，也什么都不做。
问题：A 如何知道 B 是否正确收到了 M1 呢？
解决方法：超时重传
1. A 为每一个已发送的分组设置一个超时计时器。
2. A 只要在超时计时器到期之前收到了相应的确认，就撤销该超时计时器，继续发送下一个分组 M2 。
3. 若 A 在超时计时器规定时间内没有收到 B 的确认，就认为分组错误或丢失，就重发该分组。
3. 确认丢失和确认迟到机制
确认丢失
1. 若 B 所发送的对 M1 的确认丢失了，那么 A 在设定的超时重传时间内将不会收到确认，因此 A 在超时计时器到期后重传 M1。
2. 假定 B 正确收到了 A 重传的分组 M1。这时 B 应采取两个行动：
(1) 丢弃这个重复的分组 M1，不向上层交付。
(2) 向 A 发送确认。
确认迟到
1. B 对分组 M1 的确认迟到了，因此 A 在超时计时器到期后重传M1。
2. B 会收到重复的 M1，丢弃重复的 M1，并重传确认分组。
3. A 会收到重复的确认。对重复的确认的处理：丢弃
4. 信道利用率
停止等待协议要点
停止等待。发送方每次只发送一个分组。在收到确认后再发送下一个分组。
暂存：在发送完一个分组后，发送方必须暂存已发送的分组的副本，以备重发。
编号。对发送的每个分组和确认都进行编号。
超时重传。发送方为发送的每个分组设置一个超时计时器。若超时计时器超时位收到确认，发送方会自动超时重传分组。
超时计时器的重传时间应当比数据在分组传输的平均往返时间更长一些，防止不必要的重传。
优点：简单。缺点：信道利用率太低。
提高传输效率：流水线传输
由于信道上一直有数据不间断地传送，流水线传输可获得很高的信道利用率。
连续 ARQ 协议和滑动窗口协议采用流水线传输方式。
5.4.2 连续 ARQ 协议
发送窗口：发送方维持一个发送窗口，位于发送窗口内的分组都可被连续发送出去，而不需要等待对方的确认。
发送窗口滑动：发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。
累积确认：接收方对按序到达的最后一个分组发送确认，表示：到
这个分组为止的所有分组都已正确收到了。
累积确认
优/缺点
5.5 TCP 报文段的首部格式
TCP 虽然是面向字节流的，但 TCP 传送的数据单元却是报文段。
一个 TCP 报文段分为首部和数据两部分，而 TCP 的全部功能都体现在它首部中各字段的作用。
TCP 报文段首部的前 20 个字节是固定的，后面有 4n 字节是根据需要而增加的选项 (n 是整数)。因此 TCP 首部的最小长度是 20字节。
首部中的各个字节:
源端口和目的端口：
序号
举例👇
确认号
记住：若确认号 = N，则表明：到序号 N – 1 为止的所有数据都已正确收到。
数据偏移
保留
紧急 URG
确认 ACK
推送 PSH (PuSH)
复位 RST (ReSeT)
同步 SYN
终止 FIN (FINish)
窗口
记住：窗口字段明确指出了现在允许对方发送的数据量。窗口值经常在动态变化。
检验和
伪首部仅仅是为了计算检验和。
紧急指针
选项
填充
补充：最大报文段长度 MSS
最大报文段长度 MSS (Maximum Segment Size) 是每个 TCP报文段中的数据字段的最大长度。
与接收窗口值没有关系。
MSS长度取值
窗口扩大
TCP 窗口字段长度= 16 位，最大窗口大小 = 64 K 字节。对于传播时延和带宽都很大的网络，为获得高吞吐率较，需要更大的窗口。
窗口扩大选项：占 3 字节，其中一个字节表示移位值 S。
新的窗口值位数从 16 增大到 (16 + S)，相当于把窗口值向左移动 S 位。
移位值允许使用的最大值是 14，窗口最大值增大到 2(16 + 14) – 1 = 230 – 1。
窗口扩大选项可以在双方初始建立 TCP 连接时进行协商。
时间戳
占 10 字节。最主要的 2 个字段：
时间戳值字段（4字节）和时间戳回送回答字段（4字节）。
2 个主要功能：
1. 计算往返时间 RTT
2. 防止序号绕回 PAWS (Protect Against Wrapped Sequence numbers)。
序号重复时，为了使接收方能够把新报文段和迟到很久的旧报文段区分开，可以在报文段中加上时间戳。
5.6 TCP 可靠传输的实现
5.6.1 以字节为单位的滑动窗口
TCP 使用流水线传输和滑动窗口协议实现高效、可靠的传输。
TCP 的滑动窗口是以字节为单位的。
发送方 A 和接收方 B 分别维持一个发送窗口和一个接收窗口。
发送窗口：在没有收到确认的情况下，发送方可以连续把窗口内的数据全部发送出去。凡是已经发送过的数据，在未收到确认之前都必须暂时保留，以便在超时重传时使用。
接收窗口：只允许接收落入窗口内的数据。
发送窗口
接收窗口
窗口的滑动
如图👇
发送缓存与发送窗口
缓存中的字节数 = 发送应用程序最后写入缓存的字节 - 最后被确认的字节
接收缓存与接收窗口
需要强调三点
第一，发送窗口是根据接收窗口设置的，但在同一时刻，发送窗口并不总是和接收窗口一样大（因为有一定的时间滞后）。
第二，TCP 标准没有规定对不按序到达的数据应如何处理。通常是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程。
第三，TCP 要求接收方必须有累积确认的功能，以减小传输开销。接收方可以在合适的时候发送确认，也可以在自己有数据要发送时把确认信息顺便捎带上。但接收方不应过分推迟发送确认，否则会
导致发送方不必要的重传，捎带确认实际上并不经常发生。
5.6.2 超时重传时间的选择
TCP 发送方在规定的时间内没有收到确认就要重传已发送的报文段。
但重传时间的选择是 TCP 最复杂的问题之一。
互联网环境复杂，IP 数据报所选择的路由变化很大，导致运输层的往返时间 (RTT) 的变化也很大。
TCP 超时重传时间设置
不能太短，否则会引起很多报文段的不必要的重传，使网络负荷增大。
不能过长，会使网络的空闲时间增大，降低了传输效率。
TCP 采用了一种自适应算法，它记录一个报文段发出的时间，以及收到相应确认的时间。这两个时间之差就是报文段的往返时间 RTT。
加权平均往返时间 RTTS
加权平均往返时间 RTTS 又称为平滑的往返时间。
超时重传时间 RTO
RTO (Retransmission Time-Out) 应略大于加权平均往返时间 RTTS 。
往返时间 (RTT) 的测量相当复杂
超时重传报文段后，如何判定此确认报文段是对原来的报文段的确认，还是对重传报文段的确认？
Karn 算法
l 在计算平均往返时间 RTT 时，只要报文段重传了，就不采用其往返时间样本。
l 新问题：当报文段的时延突然增大很多时，在原来得出的重传时间内，不会收到确认报文段，于是就重传报文段。但根据 Karn 算法，不考虑重传的报文段的往返时间样本。这样，超时重传时间就无法更新，造成很多不必要的重传。
修正的 Karn 算法
报文段每重传一次，就把 RTO 增大一些：
5.6.3 选择确认 SACK
解决：选择确认 SACK (Selective ACK)
RFC 2018 对 SACK 的规定
如果要使用选择确认，在建立TCP 连接时，要在 TCP 首部的选项中加上允许 SACK 选项，且双方必须事先商定好。
如果使用选择确认，原来首部中的确认号的用法仍然不变（累积确认）。只是在 TCP 首部中都增加了 SACK 选项，以便报告收到的不连续的字节块的边界。
SACK 选项
左边界 = 第一个字节的序号，右边界 = 最后一个字节序号 + 1。
恭喜，以上重点已经被攻克啦👆
5.7 TCP 的流量控制
5.7.1 利用滑动窗口实现流量控制
流量控制 (flow control) ：让发送方的发送速率不要太快，使接收方来得及接收。
利用滑动窗口机制可以很方便地在 TCP 连接上实现对发送方的流量控制。
利用可变窗口进行流量控制举例
可能发生死锁
持续计时器解决死锁
持续计时器 (persistence timer)：只要 TCP 连接的一方收到对方的零窗口通知，就启动该持续计时器。
若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带 1 字节的数据），对方在确认这个探测报文段时给出当前窗口值。
若窗口仍然是零，收到这个报文段的一方就重新设置持续计时器。
若窗口不是零，则死锁的僵局就可以打破了。
5.7.2 TCP 的传输效率
控制TCP发送报文段的时机：三种机制
1. TCP 维持一个变量，它等于最大报文段长度 MSS。只要缓存中存放的数据达到 MSS 字节时，就组装成一个 TCP 报文段发送出去。
2. 由发送方的应用进程指明要求发送报文段，即 TCP 支持的推送 (push)操作。
3. 发送方的一个计时器期限到了，这时就把当前已有的缓存数据装入报文段（但长度不能超过 MSS）发送出去。
如何控制 TCP 发送报文段的时机仍然是一个较为复杂的问题。
糊涂窗口综合症
l 糊涂窗口综合症：每次仅发送一个字节或很少几个字节的数据时，有效数据传输效率变得很低的现象。
发送方糊涂窗口综合症
发送方 TCP 每次接收到一字节的数据后就发送。
发送一个字节需要形成 41 字节长的 IP 数据报。效率很低。
解决方法：使用 Nagle 算法。
接收方糊涂窗口综合症
解决方法：让接收方等待一段时间，使得或者接收缓存已有足够空间容纳一个最长的报文段，或者等到接收缓存已有一半空闲的空间。只要出现这两种情况之一，接收方就发出确认报文，并向发送方通知当前的窗口大小。
上述两种方法可配合使用，使得在发送方不发送很小的报文段的同时，接收方也不要在缓存刚刚有了一点小的空间就急忙把这个很小的窗口大小信息通知给发送方。
5.8 TCP 的拥塞控制
5.8.1 拥塞控制的一般原理
在某段时间，若对网络中某资源的需求超过了该资源所能提供的可用部分，网络的性能就要明显变坏，整个网络的吞吐量将随输入负荷的增大而下降。这种现象称为拥塞 (congestion)。
最坏结果：系统崩溃。
拥塞产生的原因
由许多因素引起。例如：
1. 节点缓存容量太小；
2. 链路容量不足；
3. 处理机处理速率太慢；
4. 拥塞本身会进一步加剧拥塞；
出现网络拥塞的条件：
问:增加资源能解决拥塞吗？
不能，而且还可能使网络的性能更坏。
例如：
1. 增大缓存，但未提高输出链路的容量和处理机的速度，排队等待时间将会大大增加，引起大量超时重传，解决不了网络拥塞；
2. 提高处理机处理的速率会将瓶颈转移到其他地方；
3. 拥塞引起的重传并不会缓解网络的拥塞，反而会加剧网络的拥塞。
拥塞控制与流量控制的区别
拥塞控制所起的作用
拥塞控制的一般原理
拥塞控制的前提：网络能够承受现有的网络负荷。
实践证明，拥塞控制是很难设计的，因为它是一个动态问题。
分组的丢失是网络发生拥塞的征兆，而不是原因。
在许多情况下，甚至正是拥塞控制本身成为引起网络性能恶化、甚至发生死锁的原因
开环控制和闭环控制
闭环控制措施
监测
传送
调整
5.8.2 TCP 的拥塞控制方法
TCP 采用基于滑动窗口的方法进行拥塞控制，属于闭环控制方法。
TCP 发送方维持一个拥塞窗口 cwnd (Congestion Window)
拥塞窗口的大小取决于网络的拥塞程度，并且是动态变化的。
发送端利用拥塞窗口根据网络的拥塞情况调整发送的数据量。
发送窗口大小不仅取决于接收方窗口，还取决于网络的拥塞状况。
真正的发送窗口值：
控制拥塞窗口变化的原则
只要网络没有出现拥塞，拥塞窗口就可以再增大一些，以便把更多的分组发送出去，提高网络的利用率。
但只要网络出现拥塞或有可能出现拥塞，就必须把拥塞窗口减小一些，以减少注入到网络中的分组数，缓解网络出现的拥塞。
发送方判断拥塞的方法：隐式反馈
因传输出差错而丢弃分组的概率很小（远小于1 %）。
因此，发送方在超时重传计时器启动时，就判断网络出现了拥塞。
TCP 拥塞控制算法
四种拥塞控制算法（RFC 5681） ：
慢开始 (slow-start)
目的：探测网络的负载能力或拥塞程度。
算法：由小到大逐渐增大注入到网络中的数据字节，即：由小到大逐渐增大拥塞窗口数值。
2 个控制变量：
拥塞窗口 cwnd 增大：在每收到一个对新的报文段的确认，就把拥塞窗口增加最多一个发送方的最大报文段 SMSS (Sender Maximum Segment Size) 的数值。
其中 N 是原先未被确认的、但现在被刚收到的确认报文段所确认的字节数。
传输轮次（transmission round）
一个传输轮次所经历的时间其实就是往返时间 RTT。
传输轮次强调：把拥塞窗口 cwnd 所允许发送的报文段都连续发送出去，并收到了对已发送的最后一个字节的确认。
例如：拥塞窗口 cwnd = 4，这时的往返时间 RTT 就是发送方连续发送 4 个报文段，并收到这 4 个报文段的确认，总共经历的时间
慢开始门限 ssthresh
防止拥塞窗口 cwnd 增长过大引起网络拥塞。
用法：
1. 当 cwnd < ssthresh 时，使用慢开始算法。
2. 当 cwnd > ssthresh 时，停止使用慢开始算法，改用拥塞避免算法。
3. 当 cwnd = ssthresh 时，既可使用慢开始算法，也可使用拥塞避免算法。
拥塞避免 (congestion avoidance)
目的：让拥塞窗口 cwnd 缓慢地增大，避免出现拥塞。
拥塞窗口 cwnd 增大：每经过一个往返时间 RTT（不管在此期间收到了多少确认），发送方的拥塞窗口 cwnd = cwnd + 1。
具有加法增大 AI (Additive Increase) 特点：使拥塞窗口 cwnd 按线性规律缓慢增长。
注意：
拥塞避免并非完全避免拥塞，而是让拥塞窗口增长得缓慢些，使网络不容易出现拥塞。
当网络出现拥塞时
无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（重传定时器超时）：
1. ssthresh = max (cwnd/2，2)
2. cwnd = 1
3. 执行慢开始算法
目的：迅速减少主机发送到网络中的分组数，使得发生拥塞的路由
器有足够时间把队列中积压的分组处理完毕。
慢开始和拥塞避免算法的实现举例
快重传 (fast retransmit)
目的：让发送方尽早知道发生了个别报文段的丢失。
发送方只要连续收到三个重复的确认，就立即进行重传（即“快重传”），这样就不会出现超时。
使用快重传可以使整个网络的吞吐量提高约 20%。
快重传算法要求接收方立即发送确认，即使收到了失序的报文段，
也要立即发出对已收到的报文段的重复确认。
注意：快重传并非取消重传计时器，而是在某些情况下可以更早地（更快地）重传丢失的报文段。
快重传举例：👇
快恢复 (fast recovery)
当发送端收到连续三个重复的确认时，不执行慢开始算法，而是执行快恢复算法 FR (Fast Recovery) 算法：
1. 慢开始门限 ssthresh = 当前拥塞窗口 cwnd / 2 ；
2. 乘法减小 MD (Multiplicative Decrease) 拥塞窗口。新拥塞窗口 cwnd = 慢开始门限 ssthresh ；
3. 执行拥塞避免算法，使拥塞窗口缓慢地线性增大（加法增大 AI）。
二者合在一起就是所谓的 AI MD 算法，使 TCP 性能有明显改进。
TCP 拥塞控制流程图
发送窗口的上限值
recept wnd vs congestion wnd
当 rwnd < cwnd 时，是接收方的接收能力限制发送窗口的最大值。
当 cwnd < rwnd 时，是网络拥塞限制发送窗口的最大值。
5.8.3 主动队列管理 AQM
TCP 拥塞控制和网络层采取的策略有密切联系。
例如：
若路由器对某些分组的处理时间特别长，就可能引起发送方 TCP超时，对这些报文段进行重传。
重传会使 TCP 连接的发送端认为在网络中发生了拥塞，但实际上网络并没有发生拥塞。
对 TCP 拥塞控制影响最大的就是路由器的分组丢弃策略。
“先进先出”FIFO 处理规则
先进先出FIFO (First In First Out) 处理规则：
尾部丢弃策略 (tail-drop policy)：当队列已满时，以后到达的所有分组（如果能够继续排队，这些分组都将排在队列的尾部）将都被丢弃。
路由器的尾部丢弃往往会导致一连串分组的丢失，这就使发送方出现超时重传，使 TCP 进入拥塞控制的慢开始状态，结果使 TCP 连接的发送方突然把数据的发送速率降低到很小的数值。
先进先出（FIFO）处理规则与尾部丢弃策略
严重问题：全局同步
1998 年提出了主动队列管理 AQM (Active Queue Management)。
主动：不要等到路由器的队列长度已经达到最大值时才不得不丢弃后面到达的分组，而是在队列长度达到某个值得警惕的数值时（即当网络拥塞有了某些拥塞征兆时），就主动丢弃到达的分组。
AQM 可以有不同实现方法，其中曾流行多年的就是随机早期检测 RED (Random Early Detection)。
随机早期检测 RED
路由器队列维持两个参数：
队列长度最小门限 THmin
队列长度最大门限 THmax 。
RED 对每一个到达的分组都先计算平均队列长度 LAV 。
1. 若平均队列长度小于最小门限 THmin，则将新到达的分组放入队列进行排队。
2. 若平均队列长度超过最大门限 THmax ，则将新到达的分组丢弃。
3. 若平均队列长度介于在最小门限 THmin 和最大门限 THax 之间，则按照某一概率 p 将新到达的分组丢弃。
如图👇
多年的实践证明，RED 的使用效果并不太理想。
2015 年公布的 RFC 7567 已经把 RFC 2309 列为“陈旧的” ，并且不再推荐使用 RED。
但对路由器进行主动队列管理 AQM 仍是必要的。
AQM 实际上就是对路由器中的分组排队进行智能管理，而不是简单地把队列的尾部丢弃。
现在已经有几种不同的算法来代替旧的 RED，但都还在实验阶段。
5.9 TCP 的运输连接管理
TCP 是面向连接的协议。
TCP 连接有三个阶段：
1. 连接建立
2. 数据传送
3. 连接释放
TCP 的连接管理就是使 TCP 连接的建立和释放都能正常地进行。
TCP 连接建立过程中要解决的三个问题
1. 要使每一方能够确知对方的存在。
2. 要允许双方协商一些参数（如最大窗口值、是否使用窗口扩大选项和时间戳选项以及服务质量等）。
3. 能够对运输实体资源（如缓存大小、连接表中的项目等）进行分配。
TCP 连接的建立采用客户服务器方式。
主动发起连接建立的应用进程叫做客户 (client)。
被动等待连接建立的应用进程叫做服务器 (server)
5.9.1 TCP 的连接建立（三次握手）
TCP 建立连接的过程叫做握手。
采用三报文握手：在客户和服务器之间交换三个 TCP 报文段，以防止已失效的连接请求报文段突然又传送到了，因而产生 TCP 连接建立错误。
三次握手的过程👇
5.9.2 TCP 的连接释放（四次挥手）
TCP 连接释放过程比较复杂。
数据传输结束后，通信的双方都可释放连接。
TCP 连接释放过程是四报文握手。
5.9.3 TCP 的有限状态机
__EOF__
