2024考研408-计算机网络 第五章-传输层学习笔记_考研 计算机网络 拥塞控制

前言

目前正在备考24考研，现将24计算机王道的408学习整理的知识点进行汇总整理。

博主博客文章目录索引：博客目录索引(持续更新)

---

一、传输层提供的服务

1.1、传输层的功能

传输层只有主机才有的层次。

传输层的功能：

1、传输层提供进行和进程之间的逻辑通信。

• 逻辑通信：表面上是连个主机的进程之间进行通信，实际在通信的时候会首先发送方会从最上层一步步封装到物理层，将比特流放入到链路中传输，接着中间经历多个中间系统，最终到达主机再一步步解封装，最终指定的应用请求得到数据。

• 对于网络层提供主机之间的逻辑通信。

2、复用与分用。

• 例如：微信与QQ发送的数据最终都会使用同一个传输层的协议进行传输（复用），最终目标方手机同时会在传输层将数据报进行拆分来进行分用传给到不同的应用当中（分用）。

3、传输层对收到的报文进行差错检测。

• 在网络层阶段包含一个首部校验，这个是用来校验IP数据报的首部的，没有检错的功能原因是因为其上层传输层中会对传输层报文段进行差错检测。对于传输层+网络层可以实现一个可靠传输的功能。
• 传输层中并不一定能够一个可靠传输，因为包含有一个UDP和TCP，其中TCP是保证可靠传输的。

---

1.2、传输层的两个协议（TCP、UDP）

两个协议为：TCP、UDP。前者可靠，后者不可靠。

TCP与UDP协议的对比：

①TCP：面向连接的传输控制协议。

• 传输数据过程：传输数据之前必须建立连接，数据传送结束后要释放连接。不提供广播或多播服务。
• 由于TCP要提供可靠的面向连接的传输服务，因此不可避免增加了许多开销：确认、流量控制、计时器及连接管理等。
• 是否可靠：可靠，面相连接，时延大。
• 应用场景：适用于大文件。

②UDP：无连接的用户数据报协议UDP。

• 传输数据过程：传输数据之前不需要建立连接，收到UDP报文后也不需要给出任何确认。
• 是否可靠：不可靠，无连接，时延小。
• 应用场景：适用于小文件。

---

1.3、传输层的寻址与端口（常见端口介绍）

复用与分用：

• 复用：应用层所有的应用进程都可以通过传输层再传输到网络层。
• 分用：传输层从网络层收到数据后交付指明的应用进程。

端口：传输层的SAP，用来标识主机中的应用进程，一个应用进程运行都会有端口号。

• 主要分为：逻辑端口/软件端口，指的是应用进程的端口。对于硬件端口则指的是真实物理世界中主板上的一些接口。
• 端口关系：端口号只有本地意义，在因特网当中不同计算机的相同端口是没有联系的。
• 端口号长度：为16bit，可以表示65536个不同的端口。

端口号按照范围分：包含有服务端的端口号、客户端使用的端口号

其中一些常见的固定应用服务的使用端口如下：

在网络中采用发送方和接收方的套接字组合来识别端点。

套接字：唯一标识了网络中的一个主机和它上面的一个进程。

• 套接字Socket = （主机IP地址，端口号），其中主机IP地址能够去标识定位一个网络中的主机，而对于端口号则是用来表示主机上的某个进程。

---

二、UDP协议

2.1、认识UDP功能和特点

UDP功能：只在IP数据报服务之上提供了很少的功能，如复用分用和差错检测功能。

UDP的主要特点：

1、UDP是无连接的，减少开销和发送数据之前的时延。

2、UDP使用最大努力交付，即不保证可靠交付。

• 若是UDP协议不能够保证可靠交付，那么可靠交付就交由传输层的上一层应用层来保证可靠以及顺序的交付。

3、UDP是面向报文的，适合一次性传输少量数据的网络应用。

应用层给UDP多长的报文，UDP也会照常发送，即一次发一个完整报文，由于也是不可靠的交付，容易导致数据丢失，若是传输的数据量不大，这样即使发生丢失的的情况损失也比较小。

• 若是数据太大，那么在网络层就需要分片，因为对于接下来传递给链路层，在链路层中有一个MTU的要求。
• 若是数据太小，小到比首部还少，那么就会降低网络层的效率，希望的是一个数据报当中数据信息尽可能多，首部附加信息尽可能少。

4、UDP无拥塞控制，适合很多实时应用。

• **并不是说没有拥塞控制，那么网络即使再拥塞，UDP也不会让发送方的速度放缓一些，此时就不会控制这个问题。对于这种情况是否会觉得这个协议不好？**实际上不是，正因为UDP没有拥塞控制，也带来了一些优点，如适合很多实时性的应用，如IP电话、视频会议，并且是允许在网络出现拥塞的情况下，丢弃一些数据的，因为这些实时性的应用，不能允许数据有太大的延迟，实际上丢一点也是允许的。
• 对于拥塞情况特别严重，也会有一定的补救措施，例如向前纠错或者重传已经丢失的报文。

5、UDP首部开销小，8B，TCP为20B。

---

2.2、UDP首部格式

首部字段总和固定是8B，其中包含源端口号、目的端口号、UDP长度、UDP检验和都是2B（16位）。

16位UDP长度：指的是数据字段+首部字段，若是数据字段为7B，那么这个UDP长度就是15。

16位UDP检验和

• 情况1：检测整个UDP数据报是否有错，错就丢弃。
• 情况2：分用时（接收端接收到时需要进行分用给不同进程根据端口号），若是找不到对应的目的端口号，那么此时就会丢弃报文，并给发送方发送ICMP "端口不可达"的差错报文。

---

2.3、UDP伪首部字段分析

伪首部只有在计算校验和的时候才出现，不向下传送也不向上递交。伪首部就是模仿的IP数据报的首部。

• 源IP地址：4个字节。
• 目的IP地址：4个字节。
• 0：1个字节，全0也就是为首部的第三个字段固定全0。
• 在伪首部中的17：1个字节，封装UDP报文的IP数据报首部协议字段是17。
• UDP长度：2个字节，UDP长度 = UDP首部8B + 数据部分长度（不包括伪首部）

---

2.4、伪首部校验UDP用户数据报过程

如何使用伪首部来校验UDP用户数据报有没有发生差错？

将它看成有许多16位的字串连接起来的，也就是很多个4个字节的组成部分，如下图中的右半部分，每16位作为一组并排写：

在发送端：

1、填上伪首部。

2、全0填充检验和字段。

3、全0填充数据部分（UDP数据报要看成许多4B的字串接起来）。

4、计算：将伪首部+首部+数据部分采用二进制反码求和。

5、将求和反码填入到首部的检验和字段。

6、去掉伪首部，发送。

在接收端：

1、填上伪首部。

2、伪首部+首部+数据部分采用二进制反码求和。

• 注意：在发送端中的检验和计算求和时是全0，而在接收端的时候此时检验和是之前的求和结果取反，我们这边是加上的检验和。

3、最终得到结果全为1则无差错，否则丢弃数据报 或 应用层 附上出差错的警告。

如下在求和中有区别的就是检验和部分，在接收端时这个检验和为发送端时候的一个检验和，不再是使用全0来计算：

**为什么最终和为1？**可以看到在发送端时最终的结果取得是反码放入到检验端，那么将计算得到的值+反码值，那就是全1，如下两行相加。

---

三、TCP协议

3.1、TCP协议特点与报文格式

3.1.1、TCP协议的特点

1、TCP是面向连接（虚连接）的传输层协议。

• 虚连接：与传输层逻辑通信一样，并不是实际的一个物理连接，物理连接指的是把这个数据报加上各个层次的首部后放入到链路上传输，然后再到接收端进行一步一步的解封装，这个是一个完整的物理连接。TCP协议的使用则好像这两个进程建立了一个点对点的连接，所以说是一种虚连接。

2、每一条TCP连接只能有两个端口，每一条TCP连接只能是点对点的。

3、TCP提供可靠交付的服务，无差错、无丢失、不重复、按序到达。【可靠有序，不丢不重】

4、TCP提供全双工通信。

• 全双工通信两端都可以同时发送、接收数据。
• 对于其特点TCP协议连接的两端都会设置有发送缓存（准备发送的队列）以及接收缓存（准备接收的队列）。
  • 发送缓存：准备发送的数据 & 已发送但尚未收到确认的数据。（对于一些已经发送但是还没有收到确认的数据，不能够直接从缓存中删除，因为一旦出现超时的情况那么就需要进行重发）
  • 接收缓存：按序到达但尚未被接受应用程序读取的数据 & 不按序到达的数据。（对于每按序到达的数据，只有将数据顺序排好了，接收方才能够逐一一个有一个的来从接收缓存当中取出数据交付给对应的进程）。

5、TCP面向字节流

• 指的是TCP把应用程序交下来的数据看出仅仅是一连串的无结构的字节流。
• 流：流入到进程或从进程流出的字节序列。

如下图文件包含多个字节，我们将10个字节放入到缓存中等待发送：

此时开始发送，可能会先取3个字节组成一个TCP的报文段，接着在这个报文段上加入TCP的首部形成一个完整报文段，再放到链路上进行一个传输，对于这个字节传输的个数根据具体情况不定：

所以说TCP协议是面向字节或者说字节流的。

---

3.1.2、TCP报文段首部格式

TCP报文段首部整体描述：

• TCP报文段由TCP首部和TCP数据部分组成。
• TCP首部数据位数要求是4B的整数倍，此时就需要TCP首部填充一些数据，一般是全0。
• 首部包含有固定的20B，对于其他选项、填充字段则是另外计算。

下面是TCP首部的11个个字段详细描述：

①-②源端口、目的端口：各自占用2B也就是16位。

③序号位：占用4B，在一个TCP连接中传送的字节流中的每一个字节都按顺序编号，本字段表示本报文段所发送数据的第一个字节的序号。

• 举例1中可以看到连续发送的是1、2、3字节，那么TCP头部中的序号就是1（传输的第一个字节），表示的是第一个字节。
• 举例2中可以看到连续发送的是4、5、6字节，那么TCP头部中的序号同样也就是4（传输的第一个字节），表示的是第四个字节。

④确认号：期望收到对方下一个报文段的第一个数据字节的序号。若确认号为N，则证明到序号N - 1为止的所有数据都已正确收到。

• 这个确认号是通过目标方主机发来的。当我们第一个报文传输的字节数1、2、3到达时，那么目标方会返回一个确认报文段，此时确认报文段的首部中就包含有一个确认号=4，表示的是当前已经收到了1、2、3字节，我现在希望收到4号字节。

⑤数据偏移（首部长度）：TCP报文段的数据起始处位置J距离TCP报文段的起始处有多远，以4B位单位，即1个数值是4B。

TCP报文段长度指的是如下图：

由于是以4B作为单位，对于数据偏移若是1111，那么就是16 x 4B = 64B，当前TCP首部就是64字节，固定20B，可选+填充就是44B。

⑥6个控制位：

• 紧急位URG：URG = 1时，标明此报文段中有紧急数据，时高优先级的数据，应尽快传送，不用在缓存里排队，配合紧急指针字段使用。（如下，当在缓存中已经拆分多段待发送的报文，那么此时途中处于第4段的报文里由于包含URG=1，那么就表示该数据需要尽快传送，赋予其一个优先级，此时就可以移动到最前面，而不用等地啊排队轮到它。）
  • 
• 确认位ACK：ACK = 1时确认号有效，在连接建立后所有的传送报文段都必须把ACK置为1。
• 推送位PSH：PSH = 1时，接收方尽快交付应用进程，不要再等到缓存填满后再向上交付。（指的是接收方进行的一个紧急处理，如下图中若是缓存区第二个段是PSH=1，那么此时就被赋予了一个报文段的优先级，会赶紧交付给应用层上面的进程。）
  • 
• 复位RST：RST = 1时，表明TCP连接中出现了严重差错，必须释放连接，然后再重新建立传输链接。
• 同步位YSN：SYN = 1时，表明是一个连接请求/链接接受报文。（如下图中发送方发送给出了SYN = 1，那么接收端也会返回一个SYN = 1）。
  • 
• 终止位FIN：FIN = 1时，表明此报文段发送方数据已发完，要求释放连接。

对于推送位、复位考试不考，做一个简单了解。

⑦窗口字段：指的是发送本报文段的一方的接收窗口，即现在允许对方发送的数据量。

• 举例1：此时接收端发送过来的报文段首部有窗口位65536，那么此时发送端A接收到了，那么就会设置自己发送缓冲区窗口大小设置为65536。
  • 
• 举例2：此时接收端B发送过来报文段中确认号=701，窗口字段=1000，此时发送方会设置自己的发送缓冲区为1000，并且将自己的701-1700字节发送给接收方B。
  • 

⑧校验和：检验首部+数据，检验时要加上12B伪首部，第四个字段（相对应协议字段）为6。

⑨紧急指针：URG = 1时才有意义，指出本报文段中紧急数据的字节数。

• 示例：若是紧急指针为50，那么说明这个TCP数据部分从第1个字节到50个字节，这些都是紧急数据。
• 

10选项：最大报文段长度MSS、窗口扩大、时间戳、选择确认…。

11填充字段：若是选项字段不是4B的整数倍，那么此时就需要进行填充其为4B的整数倍。

---

3.2、TCP连接管理

3.2.1、TCP连接传输三个阶段

TCP连接传输三个阶段：

TCP连接的建立采用客户/服务器方式，主动发起连接建立的应用进程叫做客户，被动等待连接建立的应用进程叫做服务器。

连接时三次握手：

---

3.2.2、TCP连接建立过程

3.2.2.1、连接三次握手详解

ROUND1：客户端发送连接请求报文段，无应用层数据。

SYN = 1，seq = x（随机）

• SYN = 1：连接请求时即为1。
• seq = x（随机）：序号位，这个序号是随机产生的，可以从一开始任意一个随机数开始。
• 对于确认号，在这里无效，因为客户端并没有收到服务器端发够来的报文段，因此客户端就不知道自己接下来要期待服务端发来的哪个序号报文段，此时确认号无意义。

对于SYN只有两种情况下置为1，一个是连接请求，另一个是连接请求的确认。

ROUND2：服务端为该TCP连接分配缓存和变量，并向客户端返回确认报文段，允许连接，无应用层数据。

SYN=1，ACK=1，seq=y(随机)，ack=x+1

• SYN=1：连接请求的接受依旧为1。
• ACK=1：当ACK=1时，此时小写ack也有效了，这两个需要进行搭配使用。
• ack=x+1：此时确认号应该填期待对方接下来发送的报文段的第一个字节。由于上次客户端请求的这个序号表示段为x，此时服务器端想要收到的下一个字节应该是从x+1开始。
• seq=y(随机)：此时对于确认报文段同样也有一个序号字节，这个序号自己同样也是主机自己随机分配的。

ROUND3： 客户端收到服务端的确认，接下来应该返回一个确认的确认，告诉服务器我们已经建立连接了，接下来就可以给你发送数据，与前两个报文段不同的是，这个第三个报文段可以携带数据了，此时可以将正式要发送的数据放入到报文段。

• 客户端为该TCP连接分配缓存和变量，并向服务端返回确认的确认，可以携带数据。

SYN=0，ACK=1，seq=x+1，ack=y+1

• SYN=0：当前并不连接请求，也不是连接请求的确认，此时就是0。之后所发送的数据SYN都为0。
• ACK = 1：当ACK=1时，此时小写ack也有效了，这两个需要进行搭配使用。
• seq = x + 1：它所发送的这个报文段的第一个字节是x+1。
• ack = y + 1：由于上一个seq序列想要收到的是y，那么此时接下来要期待的这个序号就是y+1。

---

3.2.2.2、三次握手可能出现的问题：泛洪攻击

对于第二步、第三步中，服务器和客户端都围着TCP连接的过程分配了缓存和变量，此时就会导致出现问题：洪泛攻击。

原因：由于三次握手才产生的黑客攻击问题。

攻击描述：SYN洪泛攻击发生在OSI第四层，这种方式利用TCP协议的特性，就是三次握手。攻击者发送TCP SYN，SYN是TCP三次握手的第一个数据包，而当服务器返回ACK后，该攻击者就不对其进行再确认，那么这个TCP连接就处于挂起状态，也就是所谓的半连接状态。服务器收不到再确认的话，就会重复发送给ACK给攻击者，此时就会更加浪费服务器的资源。

• 此时攻击者趁其上面描述进入不断重复发的情况，就继续对服务器发送非常大量的这种TCP连接，由于每一个都没法完成三次握手，此时在服务器上，这些TCP连接会因为挂起状态而消耗CPU和内存，最终服务器可能死机，就无法为正常用户提供服务。

解决syn洪泛攻击的办法：设置的是syn cookie。

---

3.2.3、TCP的连接释放过程（四次挥手）

关闭连接时四次挥手：

参与一条TCP连接的两个进程中的任何一个都能够终止该连接，连接结束后，主机中的"资源"（缓存与变量）将被释放。

ROUND1：客户端发送连接释放报文段，停止发送数据，主动关闭TCP连接。

FIN = 1，seq = u

• FIN = 1：当结束释放连接的时候，此时FIN结束位要设置为1。
• seq = u：指的就是这样一个报文段的第一个字节的序号，由于这个报文段通常其中并没有数据，此时一个序号可以表示这样的一个报文段。

ROUND2：服务器端回送一个确认报文段，客户到服务器这个方向的连接就是释放了。（此时处于半关闭状态）

ACK = 1，seq = v，ack = u+1

• ACK = 1：此时ack生效。
• seq = v：取决于它之前发送到哪里，如这个服务器之前上一个发送的报文段，最后一个字节是v - 1，此时seq标为1。
• ack = u + 1：表示对于上一个报文段的确认，上一个报文seq = u。

主机收到了这样的一个确认报文段时，不用予以回复，因为这个主机现在已经结束通话了，只需要等待这个服务器告诉它，它也结束，接着它们俩之间的连接就算是正式关闭。

注意：在这个过程中还会发送完剩余数据。

ROUND3：服务器端发送完数据，就发出连接释放报文段，主动关闭TCP连接。

FIN = 1，ACK = 1，seq = w，ack = u + 1

• FIN = 1：只要是请求关闭连接，都需要发起FIN = 1。
• ack = u + 1：由于这个请求关闭连接时在服务器阶段二之后直接进行发送的，中间客户端并没有再发送过请求，此时ack回复字段依旧是u+1，与ROUND2中一样，都是进行表示确认。
• seq = v：实际也取决于第二步之后回复确认以后，服务端所发送的数据量多少。

ROUND4：客户端回送一个确认报文段，再等到时间等待时间计时器设置的2MSL（最长报文段寿命），此时连接彻底关闭。

• 2MSL指的是最长报文段的寿命。若是确认报文段这没有到达服务器，那么此时服务器没有收到这个会进行重发关闭连接请求，若是在2MSL内收到关闭连接请求，那么会进行重新发起确认。

ACK=1，seq = u + 1，ack = w + 1

---

3.3、TCP可靠传输

四种TCP实现可靠传输的机制

方式一：校验

过程：与UDP校验一样，增加伪首部。

• 与UDP协议的校验方式一样，都是通过在发送方和接收方增加一个首部，接着通过使用二进制反码求和的计算方法来判断有没有发生错误。

---

方式二：序号机制

与UDP的一样，最终发送的报文段可能就是下面TCP缓存中的几个字节，那么序号就表示每个段的第一个字节在整个TCP缓存当中的位置：

---

方式三：确认机制（基于序号机制）

下面我们可以看到当我们TCP缓存中的第一段报文在发送到服务端的时候，TCP缓存里并没有将这个第一段删除掉：

其原因就是要等待服务器端确认之后才进行删除，若是没有收到确认报文那么就可能会出现报文丢失的情况，所以对于发送端如何知道接收方已经正确、完整的接收到了这整个报文，就是靠我们这个确认机制，接收方收到了这个报文段之后，就会返回一个确认报文段。

可以看到当我们服务端返回确认报文时，其中的确认号字段为4，那么就表示4之前的数据已经都完成了接收，那么此时发送端就可以将TCP缓存当中的第一段删除：

那如果说有1、2、3段，此时中间的第二段迟迟不到（可能已经丢失），对于1、3段已经收到了，此时TCP默认会使用累计确认，此时确认号字段依旧是4，也就是服务端告知客户段我下面还是要收到第4字节开始的报文：

• 虽然说是顺序接收到，但对于这种情况中间的2没到，3段是也可以进行接收的。

此时客户端就会发送第2段报文，也就是4、5、6，当第2段报告发送到服务端时，此时服务端已经接收到了第1、2、3段，那么下一次发送确认段中确认号字段为9。

对于顺序、乱序到达服务端的情况说明：

• 报文段按序完整到达：此时接收方会返回这个确认来指导发送方接下来要发送哪一段报文（顺序到达最后一个报文段末尾的后一位）。
• 报文段没有按序到达：那么接收方会返回一个确认报文段，此时这个报文段就可以指示这个发送方应该重传哪一个报文（中间第一个没有到达的报文段的第一位）。

---

方式四：重传（RTTS加权平均往返时间、快速重传机制）

确认、重传机制不分家，TCP的发送方在规定的时间内（重传时间）没有收到确认那么就要重传已发送的报文段。【超时重传】

问题1：何时重传？

• 若是发送方超过了一定的时间，还没有收到接收方的确认时，那么发送方就知道自己所发送的这个报文段应该丢失了，此时他就应该将自己这个报文段从缓存中拿出来进行重传。

问题2：对于这个重传的时间如何进行计算？

• 由于TCP下层是一个互联网环境，发送的报文可能会经过高速路的局域网，也有可能经过低速率网络，那么每一个IP数据报，它所选择的路由也都是各不相同的，取决于当时的一个网络情况，那么就会导致发送方发送的很多报文段所走的路径都不一样，所以我们不能够设置一个固定的时间。
• 原理：TCP采用了一种自适应算法来动态改变重传时间，那么这个重传时间叫做RTTs（加权平均往返时间），也就是当我们发送第一个报文段的时候，这个RTTs指的就是取的第一个报文的RTT（从第一个报文的发送开始知道确认），接着在发送第二段RTT时，那么同样会有一个rtt，接着根据第1、2个rtt就能够算出一个RTTs就作为现在的重传时间。对于之后发送第N段RTT时，都会设置一个加权的平均往返时间，通过一个公式来计算。

问题3：若是对于超时重传，若是一直没有到达这个超时时间，那么就会一直进行等待，有没有一种办法能够在超时事件发生之前就能够直到发送方有没有丢失这个报文段，然后尽快的重传呢？

方案：冗余ACK（冗余确认），与确认机制相关。

过程：每当比期望序号大的时序报文段到达时，发送一个冗余ACK，指明下一个期待字节的序号。

对于下面的情况，可以考单由于在1段之后2没有收到，此时不断到来的是3、4、5此时服务器端也就都会接收，当接收完一个报文段时，实际会发送一个确认号，可以看到在1段之后，由于2段迟迟没有到来，确认报文段中确认号一直都是2，可以看到此时这种连续确认号为中间2段，那么就是一个冗余确认。当接收端收到了三个相同序号的报文段（是基于1的确认为序号2之后的连续三个），此时就会就会判断自己发送的这个2号报文段发生了丢失情况，此时就会进行重传（此时就实现了提前重传效果）

• **为什么能够乱序到达呢？**TCP中接收端并不是收到一个确认机制发送一个报文段，它时可以进行连续的发送多个报文段的。

  

这种技术也可以成为：快速重传技术。

---

3.4、TCP流量控制

3.4.1、TCP流量控制产生的原因以及滑动窗口过程

原因：在平时发送数据的时候，通常都会希望这个发送数据的速率可以更快一些，但是如果发送的速率过快，就会使得接收方可能来不及接收，此时就会导致非常严重的丢包现象，此时就需要有流量控制来控制发送方的一个发送速率。

流量控制：让发送方慢点，要放接收方来得及接收。

TCP利用滑动窗口机制来实现流量控制。

滑动窗口过程：在通信过程中，接收方根据自己接收缓存的大小，动态地调整发送方的发送窗口大小，即接收窗口rwnd（接收方确认报文段的窗口字段来将rwnd通知给发送方），发送方的发送窗口取接收窗口rwnd和拥塞窗口cwnd的最小值。

• 资源的拥塞情况：网络阻塞了，说明当时网络当中使用网络嗲款，网络资源的主机太多，所以会导致整个网络出现了一个发送缓慢/转发缓慢、排队时间过程的一个问题。
• 发送方的发送窗口要取决于接收窗口以及拥塞窗口这两个值的最小值。【发送窗口 = Min{接收窗口，拥塞窗口}】

对于发送方的窗口是可以动态变化的，这个取决于接收方所返回的一个报文段，可能是确认报文，也有可能是一个数据报文，如果窗口字段大，说明现在可以让发送方多发一些数据，若是窗口字段比较小，那么就是让发送方少发一点数据：

• 如下图中，接受返回一个了一个确认报文，其中设置了发送窗口为6，此时发送方划分出了6个窗口的来进行一次发出。

---

3.4.2、TCP流量控制详细过程

A向B发送数据，连接建立时，B告诉A：“我的rwnd = 400（字节）”，设每一个报文段100B，报文段序号初始值为1。

详细过程描述：

1、首先A向B进行请求连接建立，接着B返回一个确认报文段，其中设置了字段rwnd = 400（字节）。

2、主机A收到确认报文段，此时读取到rwnd = 400，此时就给自己的发送缓冲区窗口划分了400字节（由于报文段100B，那么就正好是4段）。

接着会根据窗口的大小连续的发出了4个报文段，每个报文段100字节，根据图可以看到前两个报文段主机B成功接收，对于第3段丢失：

3、此时主机B发送了一个确认报文段，其中指明我接下来要接收从201字节开始的一个报文段，此时并指明当前可以接收的窗口为300字节。

主机A的发送窗口是从接收端暂未收到的201字节开始，直到500字节：

4、此时发送端的发送窗口由于有300字节，由于此时201-300字节的报文段还没有收到确认报文，此时就会保持在发送窗口，接下来主机A发送数据，就可以发送这两个格子里面的数据会从301开始，第3段，第4段，此时就无法发出了，已经窗口最大只能够开大500字节。

5、此时对于窗口201-300字节的报文段就一直处于僵持的状态，一直在等待接收方发来的确认，等待对于201-300字节的报文段超时时间过去之后，就会进行一次重传

6、主机B能够成功接收到，此时主机B发送了一个响应报文，在响应报文中指明了现在主机B想要接收的报文段从501开始，发送窗口大小可以限制在100。

7、主机A开始发送501字节开始的一段报文段，由于窗口大小只有100字节，所以发送完该段就无法继续发送。

8、此时接收端主机B返回了一个确认报文段，其中表明说想要从601字节开始，发送窗口大小为0。

由于窗口设置为0，那么此时发送端就不能在发送数据了。

额外问题1：若是主机A一直在等待主机B发送一个非零窗口的通知，而主机B发送了一个新的报文段（允许窗口大小为400）在传输过程中丢失，此时若是没有措施的话，那么主机A、主机B就会一直相互等待，对于这种相互等待的情况，类似于死锁，那么如何解决呢？

解决方案：TCP为每一个连接设置有一个持续的计时器，只要TCP连接的一方收到对方的零窗口通知，就会启动这一个持续计时器。若是计时器到时间，那么主机A就会发送一个探测报文段，那么主机B会重传这一个通知报文。

• 若是重传的这个通知报文依旧窗口是0，那么主机A会重新再设置一个持续计时器，此时若是在计时器结束之前还是没有通知确认报文的话，那么主机A会再发送一个探测报文段，让主机B再重传一次。

---

3.5、TCP拥塞控制

3.5.2、认识拥塞控制以及与流量控制的区别

什么叫做拥塞控制？

• 在网络当中状况不好，网络发生了阻塞，导致接收数据以及发送数据，整个速度全部降下来了。

出现拥塞的条件：对资源需求的总和>可用资源

• 其中的资源指的是：网络当中的一些链路容量，如带宽，一条链路中50M带宽，很多人在这条链路上发送数据导致这个链路上的带宽不够这些人使用，那么此时就会导致这个网络出现了拥塞，同时对于交换结点当中的缓存以及交换节点当中的处理机，如路由器当中的处理机等，这些都属于资源。

若是某段时间对于网络当中某一个资源的需求总和超过了这个资源，它可以提供的可用部分，那么网络的性能自然就会变换。此时就会有许多资源同时呈现一个供应不足的情况，从而导致以下的情况发生：

• 网络用有许多资源同时呈现供应不足 —> 网络性能变坏 —> 网络吞吐量将随输入负荷增大而下降。

拥塞控制作用：防止过多的数据注入到网络当中。

• 通过协调使用这个网络资源的所有主机之间的协调就能够防止过多的数据注入到网络当中，此时就可以减轻网络的堵塞情况。

拥塞控制与流量控制的区别：

拥塞控制：假如说下图的上边为接收方，图下边式发送方，都需要给接收方发送数据，那么由于它们同时使用这个网络上的资源，同一个交换结点，那么这个路由器就会使得这个网络非常的繁忙，甚至会出现一个拥塞的情况，对于接收方而言并不知道这种拥塞情况具体是哪一个主机或者是哪几台主机发送速率过快造成的。

流量控制：是一种点对点之间的通信量控制，是一个端到端的问题，如果和这个接收方它手来的这个数据来不及接收了，那么此时就会直到应该照这个发送方。

小结：流量控制这是点到点之间的一个问题，是这个发送方的速率过快导致接收方缓存不够；拥塞控制是一个全局性的问题，主要是因为这个网络发生了阻塞。

---

3.5.3、拥塞控制的四种算法

3.5.3.1、认识拥塞控制的四种算法

四种算法：慢开始、拥塞避免、快重传、快恢复。

上面的四种是每两个进行搭配使用在一种情形当中，一个是慢开始+拥塞避免，另一个组合是快重传+快恢复：

在学习上面算法之前先进行几个假定：

1、数据单方向传送，而另一个方向只传送确认报文段（并不是传输有效数据进行一个捎带确认）。

• 实际中捎带确认也是比较常见的。

2、接收方总是有足够大的缓存空间，因而发送窗口大小取决于拥塞程度。

发送窗口 = Min(接受窗口rwnd，拥塞窗口cwnd)

• 接收窗口：接收方根据接受缓存设置的值，并告知给对方，反应接收方容量。
• 拥塞窗口：发送方根据自己估算的网络拥塞程度而设置的窗口值，反应网络当前容量。

---

3.5.3.2、组合一：慢开始和拥塞避免

理解拥塞窗口、传输轮次含义

• 考研中要清楚算法阿德应用过程，对于四种算法的具体细节并不考察。

纵坐标指的是拥塞窗口cwnd，初始值为1，代表的是一个报文段，一个最大的报文段长度MSS（此时图中的4指的是4个MSS，8指的是8个MSS），随着传输轮次的增加，拥塞窗口会发生变化。

横坐标指的是传输轮次，一个传输轮次就是一个单位，指的是发送一批报文段并收到他们的确认时间。

• 一个传输轮次：发送了一批报文段收到了它们的确认时间，一个往返时延RTT。开始发送一批拥塞窗口内的报文段到开始发送下一批拥塞窗口的内的报文段的时间。

传输轮次的理解：

如下：主机A给主机B发送了一个报文段，此时主机B向主机A响应了一个报文段，此时就算作一个轮次

由于网络情况很好，此时会多发送几个报文段m2、m3，此时主机B收到两个报文段之后依次返回两个确认，对于这一种情况，到M3确认为止，这样的一段就是第二个传输轮次。

此时发送窗口再次进行调大，此时窗口为4，那么此时可以连续发送4个报文段，接着依次收到第4个报文段的时候此时就算作第三个传输轮次：

---

慢开始和拥塞避免的详细过程

慢开始指的是一个指数规律增长，一个爆炸式增长的过程。

• 慢的原因主要是一开始注入的仅仅只是一个报文，这对于初始注入很多报文段来说，会慢很多。

过程：首先对这个网络进行一个探查，看一下这个网络的拥塞情况，若是比较好，那么此时就增加我的拥塞窗口发送方，增加拥塞窗口，这个倍数是2倍，分为四个阶段。

①一开始是进行**【慢开始】，在第一个传输轮次是1个MSS，第二个传输轮次是2个MSS，第三个传输轮次是4个MSS，第四个传输轮次是16个MSS，此时可以看到已经到达了ssthresh的初始值16，其指的是一个慢开始门限**。

②此时就会由慢开始进入到**【拥塞避免】**，因为目前现在注入的报文段比较多，此时会担心之后很快会发生拥塞情况，此时就把速度稍微降一降。此时会在之前的拥塞窗口基础上，每次增加一个拥塞窗口，可以看到在5个轮次到12个轮次每次都是+1，此时一直到了24个MSS。

• 慢开始门限：一旦到了这个慢开始门限初始值时，速度就要稍微减一点，会由慢开始进入到拥塞避免。
• 拥塞避免过程：是线性增长的过程，在慢开始门限基础上每次+1。

③由于到达了24MSS时，此时网络出现了拥塞，发生了丢包情况，此时会重新进入到**【慢开始状态】**，拥塞窗口重新回到了1，瞬间从24个报文段缩减为1个报文段，之后的过程就是继续开始执行慢开始，1、2、4、8，接着在第17个轮次时，注意此时的门限值变为了12。

• **新的门限值如何确定？**根据当前出现了网络拥塞的情况下出现的，一旦出现网络拥塞，就会立即将拥塞窗口/2，由于之前出现网络拥塞的拥塞窗口为24，那么此时24/2 = 12，那么此时新的门限值就是12。

④当进入到**【拥塞避免】**状态时，还是会进行线性增长，每次+1，之后的过程都是一样一旦出现网络拥塞，那么会设置新的门限值，并重新回到慢开始进行。

---

3.5.3.3、组合二：快重传和快恢复

快重传出现的原因主要是解决对于等待超时时间过长而实现的一种机制，机制过程如下：

• 此时连续发送了M1、2、3、4、5这五个报文段，当M1发送到B后，此时会返回一个确认号，其中ack=2，表示要收到第2个报文，报文2丢失，紧接着B又收到了M3、4、5的确认报文段其中ack=2，那么此时就是累计有四个ack=2的确认报文段了，基于对于最后三个相同ack=2的那么就被成为冗余ack，此时主机A会进行重新发送M2报文。
• 

**快恢复是如何体现的呢？**可以看到下图中在12抡次时拥塞窗口为24时，由于收到了3个重复的确认后执行了【快重传】，紧接着就会进入到【快恢复状态】，此时并不用降低拥塞窗口为1MSS情况，此时就会降到新的一个门限值，此时在这个12的门限值阶段我们进行【拥塞避免】进行线性加法增大。

• **门限值如何确定？**此时就是将出现重复确认的时候，将此时这个拥塞窗口24/2=12，紧接着我们就进行快恢复。

**什么是快恢复？**不用降到1，直接降到新的门限值（出现快重传的拥塞窗口/2），接着使用拥塞避免的算法。

对于图中的TCP-Tahoe版本已经废弃，该版本应该就是在出现快重传的时候，此时拥塞窗口直接变为了慢开始的初始阶段1，之后就执行相应的策略。

---

整理者：长路 时间：2023.8.7-8