计算机网络 | 运输层知识点期末汇总【他来了，他来了】

一、运输层协议概述

1、 进程之间的通信【复用和分用】

• 在了解进程之间的通信前，我们先来看看在五层协议的体系结构中各层的通信时如何定义的

• 可以看到，对于我们本文要总结的【运输层】，它可以向它上面的应用层提供通信服务，是属于面向通信部分的最高层，同时也是用户功能中的最低层。当网络边缘部分的两台主机使用网络核心部分的功能进行端到端的通信时，都要使用协议栈中的运输层。
• 因此从上可以看出运输层在五层协议中也是至关重要的

---

接下去我们来说说复用和分用的概念

• 当两台主机进行通信时，真正进行通信的实体并不是两台主机本身，而是主机中的应用进程。因此严格来说：通信双方进行端到端的通信时进行的是应用进程之间的通信
• 那么对于多个进程之间的通信，就要涉及到我们的复用和分用的概念
• 【复用】：在发送方不同的应用进程都可以使用同一个运输层协议传送数据（当然需要加上适当的首部）
• 【分用】：接收方的运输层之间有一个剥去报文的首部后能够把这些数据正确交付目的应用进程

---

然后我们来看看两个应用进程之间是如何通信的

• 不用说了，你可能会觉得比较难理解，对于这张图而言最主要的就是这两句话

网络层为主机之间的通信提供服务

传输层在网络层的基础上，为应用进程之间的通信提供服务

还有一个小知识点需要记忆

• 传输层向高层用户屏蔽了下面网络核心的细节（如网络拓扑、所采用的路由选择协议等），使应用进程看见的就是好像在两个运输层实体之间有一条端到端的逻辑通信信道。

2、 运输层的两个主要协议

→敲黑板！！！重点来了←

• 接下去，我们来说说运输层的两个主要协议，而且也是这一层中我们需要记住的唯一两个协议，而不会像网络层那样需要记忆那么多的协议，脑袋都大了

1. TCP【传输控制协议】

• 提供可靠的、面向连接的运输服务（建立连接—》释放连接）
• 不提供广播或多播服务
• 开销较多（确认、流量控制、计时器以及连接管理）

2. UDP【用户数据包协议】

• 传送数据之前不需要建立连接
• 收到UDP报后，不需要给出任何确认
• 不提供可靠交付，但是确实一种最有效的工作方式

下面是有关TCP和UDP的应用层协议，以及各自的端口。可以适当了解一下

3、 运输层的端口

在端口这一块，我们再来说说复用和分用的概念

• 【复用】：应用进程都可以通过运输层再传送到 IP 层（网络层）向下
• 【分用】：运输层从 IP 层收到发送给应用进程的数据后，必须分别交付给指明的各应用进程 向上

接下去我们来考虑几个问题

• 进程的创建和撤销都是动态的，因此发送方几乎无法识别其他机器上的进程
• 我们往往需要利用目的主机提供的功能来识别终点，而不需要知道具体实现这个功能的进程是哪一个
• 有时我们会改换接收报文的进程，但并不需要通知所有的发送方

对于上述的这些问题，我们应该怎么去解决呢？没错，就是利用【端口】

• 我们可以在应用层和传输层之间的界面上，设置一个特殊抽象的门，有了这个门，应用层中的应用进程就必须通过这个门才能将数据经过运输层发送到互联网；而且别的主机上的应用进程要寻找本主机中的某个某个应用进程，也必须通过这个门（本段提供对于端口这一概念的理解）
• 我们通常将这个门称做【端口】，每一个端口都有它自己的端口号来进行标识。就好像一台服务器要接收客户机发来的消息，那么它就要从这个端口中去获取信息。

---

但是对于端口我们要做这么一个区分

【硬件端口】：协议栈层间的抽象的协议端口，不同硬件设备进行交互的接口

【软件端口】：应用层的各种协议进程与运输实体进行层间交互的地点

• 在后面讲到的TCP和UDP的首部格式中，都有源端口和目的端口这两个重要字段
• TCP/IP的运输层用一个16位端口号来标志一个端口

OK就这些，不往下说了，不然太多了，记重点就行

二、用户数据报协议UDP

1、UDP的主要特点

• UDP是无连接的.，可以减少开销和发送数据之间的时延
• UDP是尽最大努力交付
• UDP是面向报文的。程序必须选择合适大小的报文。
  • 【若报文太长】，UDP就需要分片，这样会降低IP层的效率；
  • 【若报文太短】，就会使IP数据报的首部相对长度太大【因为IP数据报的首部字段是固定的】，也会降低IP层的效率
• UDP没有拥塞控制。在一些实用应用（IP电话、实时视频会议等）要求源主机以恒定的速率发送数据，但不允许数据有太大的时延，UDP刚好合适
• UDP支持一对一、一对多、多对一和多对多的交互通信
• UDP首部开销小，只有8个字节

2、UDP的首部格式

对于UDP的首部格式，你只需要记住一点，它的首部字段有8个字节，由四个字段组成，每个字段的长度都是2字节

三、传输控制协议TCP概述

学好三、四这两个模块可为后面TCP实现可靠传输打下牢固基础

1、TCP的主要特点

• TCP是面向连接（虚连接）的传输层协议
• 每一条TCP连接只能是点对点（一对一）的
• 提供可靠交付的服务[可靠有序，不丢不重]
• 提供全双工通信
  • 【发送缓存】—— 准备发送的数据 & 已发送但尚未收到确认的数据
  • 【接受缓存】—— 按需到达但尚未被接受应用程序读取的数据 & 不按序到达的数据
• 面向字节流

面向字节流这一块可能比较抽象，稍微介绍一下

• 从上图可以看出，TCP在发送报文时不关心应用进程一次把多长的报文发送到 TCP 缓存，而是根据对方给出的窗口值和当前网络拥塞程度来决定一个报文段应包含多少个字节，形成 TCP 报文段【这一块在下面会进行再次介绍】

2、TCP的连接

TCP把连接作为基本的对象

TCP用主机的IP地址加上主机上的端口号作为TCP连接的【端点】。这样的端点就叫作套接字（socket）或插口。套接字用(IP地址：端口号)来表示

例：套接字 socket = (192.168.1.20 : 7777)

注：

• 同一个IP可以有多个不同的TCP连接；
• 同一个端口号也可以出现在多个不同的TCP连接中

---

四、可靠传输的工作原理

通过网络层的学习我们可以知道对于IP网络的传输是不可靠的

• 对于实际网络而言都不具备理想传输条件。因此我们必须使用一些可靠传输协议，在不可靠的传输信道实现可靠传输

1、停止等待协议【三次握手雏形】

【停止等待协议】能够在不可靠传输的网络上实现可靠通信。对于“停止等待”而言就是每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组，也就是我们常说的【阻塞队列】

①无差错情况

• 无差错很明显就是传输的时候没有差错，就如下图所示

②出现差错

出现差错有两种情况，对于这两种情况【B 都不会发送任何信息】

• B 接收 M1 时检测出了差错，就丢弃 M1，其他什么也不做
• M1 在传输过程中丢失了，这时 B 当然什么都不知道，也什么都不做

解决方案：超时重传

• A 为每一个已发送的分组设置一个超时计时器
• A 只要在超时计时器到期之前收到了相应的确认，就撤销该超时计时器，继续发送下一个分组 M2
• 若 A 在超时计时器规定时间内没有收到 B 的确认，就认为分组错误或丢失，就重发该分组

图示如下

③确认丢失和确认迟到

• 确认丢失
• 若 B 所发送的对 M1 的确认丢失了，那么 A 在设定的超时重传时间内将不会收到确认，因此 A 在超时计时器到期后重传 M1
• 假定 B 正确收到了 A 重传的分组 M1。这时 B 应采取【两个行动】：
  • 丢弃这个重复的分组 M1，不向上层交付
  • 向 A 发送确认（不能认为已经发送过确认就不再发送了）
• 确认迟到
• B 对分组 M1 的确认迟到了，因此 A 在超时计时器到期后重传 M1
• B 会收到重复的 M1，并且同样要丢弃重复的 M1，并重传确认分组
• A 也会收到重复的确认。对重复的确认的处理：收下后就丢弃，但什么也不做

下面是它们的原理图

通常A总是可以收到对所有发出的分组的确认，如果A不断重传分组但是收不到确认，就说明通信线路太差，不能进行通信

• 通过上述的确认和重传机制，我们就可以在不可靠的传输网络上实现可靠的通信，对于这种可靠传输协议就称为[自动重传请求ARQ]

④信道利用率

• 这一块只需要记住【停止等待协议】的信道利用率太低，中间会有往返时间RTT·为了提高传输效率，则不使用低效率的停止等待协议，而是采用【流水线传输】

• 对于这个【流水线传输】，就是我们下面要讲的【连续ARQ协议】和【滑动窗口协议】

2、连续ARQ协议【基础要点】

这个协议很重要，【滑动窗口】是后面TCP进行传输原理的重要基石，是TCP协议的精髓所在

然后介绍一下这个协议的基本要点

• 发送窗口：发送方维持一个发送窗口，位于发送窗口内的分组都可被[连续发送出去]，而不需要等待对方的确认
• 发送窗口滑动：发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置
• 累积确认：接收方对按序到达的最后一个分组发送确认，表示：到这个分组为止的所有分组都已正确收到了

下面是两张原理图

来谈一谈这种【累计确认】

• 优点：容易实现，即使确认丢失也不必重传
• 缺点：不能向发送方反映出接收方已经正确收到的所有分组的信息

五、TCP报文段的首部格式【✔】

接下去我们来说说TCP报文段的首部格式，只有掌握了这些你才能掌握TCP的工作原理⏰

【TCP 首部的最小长度是 20 字节，后面的4N个字节是根据需要而增加的选项】<—— 这点要牢记

• 【源端口】和【目的端口】：运输层的复用和分用功能通过端口实现
• 【序号】：也叫做报文段序号，表示本报文段所发送的数据的第一个字节的序号
• 【确认号】：占4个字节，是期望收到对方下一个报文段的第一个数据字节的序号
  • 若确认号 = N，则表明：到序号N - 1为止的所有数据都已正确收到
• 【数据偏移】：指出TCP报文段的数据起始处距离TCP报文段的起始处有多远

---

以下的这6个字段，在后面有关TCP的三次握手和四次挥手中会频繁使用到

• 【紧急URG】：当 URG = 1 时，表明紧急指针字段有效，告诉系统此报文段中有紧急数据，应尽快传送 (相当于高优先级的数据)
• 【确认ACK】：只有当 ACK = 1 时，确认号字段才有效。当 ACK = 0 时，确认号无效
  • TCP规定，在连接建立后所有传送的报文段都必须把ACK置为1
• 【推送PSH】：当有一段的应用进程希望在键入一个命令后立即就能收到对方的响应，就可以将PSH置为1，并立即创建一个报文段发送出去。当接收方收到这个报文段后，就可以尽快地交付接受应用进程，而不再等到整个缓存填满了之后再向上交付
• 【复位RST】：当 RST = 1 时，表明 TCP 连接中出现严重差错（如主机崩溃或其他原因），必须释放连接，然后再重新建立运输连接
  • 将RST置为1还可以用来拒绝一个非法的报文段或拒接打开一个连接
• 【同步SYN】
  • 当 SYN = 1，ACK = 0 时，表明这是一个连接请求报文段
  • 当 SYN = 1，ACK = 1 时，表明这是一个连接接受报文段
• 【终止FIN】：用来释放一个连接。FIN = 1 表明此报文段的发送端的数据已发送完毕，并要求释放运输连接

虽然是比较多，但是却非常重要，为后面的学习打下坚实的基础

---

• ✔【窗口】：窗口字段明确指出了现在允许对方发送的数据量。窗口值经常在动态变化
  • 一句话 ——>窗口值作为接收方让发送方设置其发送窗口的依据
• 【检验和】：在计算检验和时，要在 TCP 报文段的前面加上 12 字节的伪首部
• 【紧急指针】：仅在URG = 1时才有意义，它指出了本报文段中紧急数据的字节数，因而可以知道紧急数据的末尾在报文段中的位置
  • 即使窗口为0也可以发送紧急数据
• 【选项】：长度可变，最长可达 40 字节；当没有使用选项时，TCP的首部长度为20字节

最后的填充字段仅仅是为了使整个TCP首部长度是4字节的整数倍

六、TCP可靠传输的实现【⭐】

1、以字节为单位的滑动窗口

首先了解一些滑动窗口的概念

1. TCP 使用流水线传输和滑动窗口协议实现高效、可靠的传输
2. TCP 的滑动窗口是以字节为单位的
3. 发送方 A 和接收方 B 分别维持一个发送窗口和一个接收窗口
4. 【发送窗口】：在没有收到确认的情况下，发送方可以连续把窗口内的数据全部发送出去。凡是已经发送过的数据，在未收到确认之前都必须暂时保留，以便在超时重传时使用
5. 【接收窗口】：只允许接收落入窗口内的数据

以下是对于发送窗口而言的要点

• A的发送窗口一定不能超过B的接受窗口的数值
  • 对于发送窗口而言还会受到网络拥塞程度的制约
• 【后沿概念】：已发送且已收到确认 [左边]
• 【前沿概念】：不允许发送，接收方无临时存放的缓存空间 [右边]
• 发送窗口的后沿不能向后移动，因为不能撤销已收到的确认
  • 后沿变化情况1：不动 [表示没有收到新的确认]
  • 后沿变化情况2：前移 [表示收到了新的确认]
• 发送窗口前沿通常是不断向前移动的，但是也有可能不动
  • 前沿不动情况1：对方通知窗口大小不变[没有收到新的确认]
  • 前沿不动情况2：对方通知窗口缩小可 [收到了新的确认]

• 从上图可以看出要描述一个发送窗口的状态需要三个指针：P1、P2 和 P3。下面是三个指针的几个重要意义

P1 = 后沿，P2 = 当前，P3 = 前沿

P1之前的数据 ===》已发送并已收到确认的部分
P3 之后的数据 ===》不允许发送的部分
P3 - P1 ===》A 的发送窗口（又称为通知窗口）
P2 – P1 ===》已发送但尚未收到确认的字节数
P3 – P2 ===》允许发送但尚未发送的字节数（又称为可用窗口）

• 对于接收窗口而言这里便不做细讲，可自行翻阅书本

有关窗口滑动的原理方面可以可以看看这个视频，讲解得还不错

大厂面试必备：TCP滑动窗口是干什么的？TCP的可靠性体现在哪里？

然后再来谈谈有关发送缓存与发送窗口

发送缓存用来暂时存放

• 发送应用程序传送给发送方TCP准备发送的数据
• TCP已发送出但尚未收到确认的数据

接收缓存用来暂时存放

• 按序到达的、但尚未被接收应用程序读取的数据
• 未按序到达的数据

接下来说说需要强调的三点Ⅲ

1. A的发送窗口并不总是和B的接受窗口一样大[因为有一定的时间滞后]
2. TCP 标准没有规定对不按序到达的数据应如何处理。通常是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程
3. TCP 要求接收方必须有累积确认的功能，以减小传输开销。强调两点：
   • ① 接收方不应过分推迟发送确认否则会导致发送方不必要的重传；
   • ② 捎带确认实际上并不经常发生；

最后强调一点，TCP的通信是全双工通信。通信中每一方都在发送和接收报文段，因此每一方都有自己的发送窗口和接收窗口。在谈到窗口的时候，一定要弄清是哪一方的窗口

2、超时重传的选择

TCP 超时重传时间设置

• 不能太短，否则会引起很多报文段的不必要的重传，使网络负荷增大
• 不能过长，会使网络的空闲时间增大，降低了传输效率

对上，TCP便采用了一种【自适应算法】，它记录一个报文段发出的时间，以及收到相应确认的时间
这两个时间之差就是报文段的往返时间 RTT

其他考试不会涉及，有兴趣可以看看

3、选择确认SACK

问题：若收到的报文段无差错，只是未按序号，中间还缺少一些序号的数据，那么能否设法只传送缺少的数据而不重传已经正确到达接收方的数据？

• 解决：选择确认 SACK (Selective ACK)
• 实现：在建立 TCP 连接时，要在 TCP 首部的选项中加上允许 【SACK 选项】，不过原来首部中的确认号的用法仍然不变（累积确认）

七、TCP的流量控制

利用滑动窗口实现流量控制【⭐⭐⭐】

对于滑动窗口，在上面也提到过了，在流量控制这一块，就要利用到这个滑动窗口的机制去实现两个主机之间的通信

[流量控制的目的]：让发送方的发送速率不要太快，要让接收方来得及接收

然后来说一下很重要的例子，要注意理解，与后面的三次握手紧密度非常之大

• 首先在建立连接的时候B就告诉了A：“我的接收窗口rwnd = 400”。表示主机B的接受窗口最多可以接收400B的大小，然后设置了一个100字节长的报文段，即DATA = 100，数据报文段序号的初始值设置为1，即seq = 1
• 然后一开始主机A就向B发送了100B的大小，第一个字节序号为1

• 然后再发100B，第一个字节序号为为101

• 但是在接下来的数据接收中，A主机继续向B主机发送了从[201]开始的数据，但在途中丢失了。此时主机B发现主机A没有再发送数据过来了，因此向它发送过去一个确认报文段
• 【ACK】是一个确认字段，我们在TCP的首部格式中有说到过，只有当ACK = 1 时ack才有效
• 【ack】是表示当前主机希望收到的下一个数据的首字节号，即确认字段的值
• 【rwnd】表示接收窗口，接收方主机B将此窗口设置为300，表示它只能接收300大小的数据字节，而且是从201开始到500的这段范围，也就限定了主机A的发送窗口从400->300

---

• 因为前200个字节的数据主机B已经完全接收了，所以主机A将其发送窗口向前滑动200字节⛸，将首字节号设置为201B，窗口大小设置为300B。
• 但是因为主机A没有接收到主机B从201~300字节的数据的回应，便开始启动这一块的超时计时器

• 接下去主机A就向主机B分别发送了301B - 400B以及401B - 500B的数据，此时接收窗口就满了。

• 但此时主机A发现前面201~300B的超时计时器时间到了，但是主机B还是没有发来相关的响应，于是重新发送了一次从201开始的这100个数据报文段，这也就是我们在上面讲到过的【超时重传】

---

• 然后接下去主机B就发送了一条确认说“前面的500B我已经全部收到，现在我的接受窗口大小变为100，下一次希望收到501B为初始字节的数据”那此时主机A就可以确认主机B已经全部收到了500B之前的所有数据，于是便会将自己的发送窗口后移300个B，到501B的位置

• 接下去主机A又发送过来符合的100B数据，于是主机B的接受窗口就满了。此时主机B就发送回一个确认报文说“前面的600B我已经全部收到，现在把你的发送窗口变为0，不要再发送数据了”

从上面就可以看出主机B实现了三次流量控制，第一次将主机A的发送窗口大小从400->300，第二次从300->100，第三次就是从100->0，通过【rwnd】这个接收窗口的控制，就使得主机A的发送窗口呈现出一个动态变化的趋势，也就是我们前面在讲到窗口值是在动态变化的

• 但是主机A要何时才能继续向主机B发送数据呢❓也就是当主机B重新发出一个新的窗口值为止。B主机会在它的接收缓存中腾出一些地方，把缓存当中的数据[主机A发送过来的600B]上交给了应用层后，它的接收缓存中就又可以有一些存储空间了
• 于是这个时候主机B就又会向主机A发送一个rwnd = 400的报文段，告诉它你现在可以将自己的发送窗口设置为400，并且开始发送数据了。但是这个报文段呢若是在传输的过程中丢失了(〃＞目＜)，主机A就收不到，此时主机B一直在等待主机A发送新的数据过来，主机A呢也等待主机B发送一个报文段过来告诉自己可以发数据了，于是它们就开始了一段漫长的等待．<{=．．．．
• 以上这个局面叫做【死锁】，是双方在数据传输过程中很可能会出现的一个现象

那要怎么去解决这个局面呢？

• TCP为每一个连接都设有一个【持续计时器】，当连接的一方收到对方的零窗口通知后，就会启动这个计时器。也就是当前的主机A，接下去呢它会发送一个【探测报文段】，这个报文段中会有1B的数据，发送过去之后若是接收方给出的窗口值依旧是0，那么主机A就会重新设置持续计时器。
• 在这个时候呢主机B可能已经收到了应用层的通告，可以继续接收数据了；如果不是零，那么死锁的僵局就可以打破了。

---

• 从上述流量控制就可以看出TCP真的是非常的严谨，很好得控制了每一次数据的传输o((>ω< ))o

八、TCP的拥塞控制

1、拥塞控制的一般原理

首先来看看什么叫做【拥塞】

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

① 解决网络拥塞的误区

很多人就认为解决网络拥塞的问题只需要增加一些资源即可

1. 把节点缓存的存储空间扩大❌
2. 把链路更换为更高速率的链路 ❌
3. 把节点处理机的运算速度提高 ❌

• 其实对于上面的这几种做法，都是不可行的，网络拥塞并没有想象中的那么简单，可能你单纯地解决了某个表现的问题，但是会引发出一些其他层次的问题。
  • 例如说丢弃一些路由器分组时，这一分组的源点就会重传这一分组，但是这又会间接导致更多的分组流入网络和被网络中的路由器丢弃
• 那其实我们可以看到，若只是采用一些简单的做法，在许多情况下，非但不能解决网络的拥塞问题，而且还可能使网络的性能更坏，所以我们要采取更加有效的方法

② 拥塞控制与流量控制的关系【重点理解✔】

在上一模块，我们讲到了流量控制，现在又说到了拥塞控制，那你可能会想它们之间会不会存在着什么关系呢？一起来看看

• 对于【拥塞控制】而言， 其实就是要防止过多的数据注入到网络，使得网络中的路由器或链路不至于过载，而且它是一个全局性的过程，会接收到不同主机、路由器所发送过来的数据，那么这个中心的交换节点就会同时被使用，从而到导致繁忙进而造成拥塞，可是呢接收方在这么繁忙的情况下又很难去知道、去查询是哪个主机出了问题
• 对于【流量控制】而言，要做的就是抑制发送端发送数据的速率，以使接收端来得及接收。它是一个点对点通信量的控制，是个端到端的问题

---

可能在看了上面的叙述后依旧有点模糊，没关系，我通过一个生活中的小场景来叙述一下

• 其实对于它们二者可以看作为一个水龙头通过管道向水桶放水。对图a来说，它只有一个很小的桶，因为来不及接收从水管中注入的水，因此就告知水龙头那边的人【将水龙头拧得小一些，以此来减缓放水的速率】，这种两端之间的通信就叫做流量控制
• 相反，对图b来说，它拥有一个很大的桶，完全可以接得下从水管中流过来的水，但是呢水管中间可能因为一些内部的各种污垢造成了拥塞，然后可以看到水管的上方已经积蓄了很多的水，因此就需要和管水龙头一方的人说【将水龙头拧得小一些，以此来减少流入水管内部的水量】，这种内部的缓解就相当于是拥塞控制

对于同样的请求，都是将水龙头拧得小一些，但是目的却不一样。对照它们的原理之后，若是读者能明白，那也就懂了它们之间的区别

2、TCP的拥塞控制方法

了解了拥塞控制的一半原理，接下去我们来聊聊TCP面对这样的拥塞状况是如何应付的

为了集中讨论拥塞控制，假定：

1. 数据是单方向传送的，对方只传送确认报文
2. 接收方总是有足够大的缓存空间，因为发送窗口的大小由网络的拥塞程度来决定

① 接收窗口【rwnd】与拥塞窗口【cwnd】

• 在流量控制中，我们提到了rwnd接收窗口，是由接收方维护的。表示接收方示意发送方自己可以接受的数据大小，以此来控制发送方发送数据的大小，
• 在拥塞控制中我们再来聊聊一种窗口叫做cwnd拥塞窗口，它呢是由发送方维护的。它的大小取决于网络的拥塞程度，并且是动态变化着的。因为上面我们假定接收方的接收窗口足够大，因为发送方只需要考虑拥塞窗口的大小即可

【发送方控制拥塞窗口的原则】：

1. 只要网络没有出现拥塞，拥塞窗口就可以增大一些，将更多的数据发送出去，以此来提高网络利用率
2. 当网络出现拥塞或可能要出现拥塞时，就把拥塞窗口减小一点，减少注入到网络的分组数，以便缓解网络出现的拥塞

发送方如何知道网络出现了堵塞？

• 没有按时收到对方的确认报文，超时重传计时器启动，便判断出网络出现了拥塞

---

来总结一下这两个窗口
【接受窗口 rwnd】：由接收方维护，会根据接收缓存设置的值，并告知给发送方，反映接收方容量

【拥塞窗口 cwnd】：由发送方维护，会根据自己估算的网络拥塞程度而设置的窗口值，反映网络当前容量

② 慢开始和拥塞避免算法

接下去我们来介绍一下拥塞控制中的算法，首先是慢开始和拥塞避免算法这两种，它们是配合使用的

【慢开始算法原理】：由小到大逐渐将数据字节注入到网络中，即逐渐增加拥塞窗口的数值

• 接着你要知道一个东西叫做最大报文段SMSS，因为慢开始规定，每收到一个新的报文段后，可以把拥塞窗口增加最多一个SMSS的值。然后通过下面这个例子来介绍一下慢开始算法

• 从上图可以看出，对于发送方它首先设置【cwnd = 1】，发送出第一个报文段，然后接收方确认了这个报文段再发送回一个确认报文段，这一点我们在前面TCP流量控制中也有说到过，这么一趟来回就叫做一个轮次，也可以叫做往返时延RTT
• 经过了一个往返时延后，发送方便扩大拥塞窗口，令【cwnd = 2】，连续发出了两个报文段，然后接收方那个接收到之后就进行了返回确认，这是第二轮的RTT
• 那发送方收到这两个确认报文段之后，便继续扩大自己的拥塞窗口，令【cwnd = 4】，一样，接收方接收到之后又会返回确认，这是第三轮的RTT
• 依此类推。。。发送方若是试探到本网络的拥塞状况良好，就会不断地增加自己的拥塞窗口，尽快地将数据发送出去。这种慢开始的策略可以使得网络拥塞的概率减小↓

---

从上可以知道拥塞窗口在慢开始算法下会不断地增大，但是若是太大也不好，也会造成过多的数据涌入导致网络拥塞，因此便有了[慢开始门限ssthresh]这么一个状态变量，它的用法如下

1. 当【cwnd < ssthresh】时，使用上述的慢开始算法
2. 当【cwnd > ssthresh】时，停止使用慢开始算法而改用拥塞避免算法
3. 当【cwnd = ssthresh】时，即可使用慢开始算法，也可使用拥塞避免算法

【拥塞避免算法原理】：让拥塞窗口cwnd按线性规律缓慢增长，每个轮次RTT只加1

• 然后我们便可以通过下面这张曲线图来看出TCP的拥塞窗口cwnd是如何变化的
  

这一块可以听一听王道这个小姐姐讲的，还是蛮不错的

5.3.5 TCP拥塞控制

③ 快重传和快恢复算法

然后再来简单介绍一下快重传和快恢复这两个算法

【快重传算法原理】：让发送方尽早知道发生了个别报文段丢失的情况，若发送发一连收到三个重复确认，便会立即重传接收方需要的报文段

• 对于这三次报文的重复确认，就是我们前面介绍过的冗余ack

【快恢复算法原理】：当发送端收到连续三个重复的确认时，不执行慢开始算法，而是执行快恢复算法算法

• 对于慢开始算法而言，会使拥塞窗口降到1后再使用拥塞避免算法慢慢升回到调整后的慢开始门限值
• 对于快恢复算法而言，不会使拥塞窗口降到最小值1，而是降到门限值ssthresh / 2的位置，然后再次执行拥塞避免算法，使拥塞窗口缓慢地线性增大

---

以下是【TCP拥塞控制】的整个流程图，可以再对照回顾一下

3、主动队列管理AQM

上一节我们在讨论TCP拥塞控制时并没有和【网络层】采取的策略联系起来，其实它们之间有着密切的联系本小节考试不会涉及，可以有兴趣可以了解一下

• 网络层的策略对TCP拥塞控制影响最大的就是——> 路由器的分组丢弃策略
• 在数据结构中我们有学习过队列，直到它的原理是FIFO 先进先出，因此当队列满了的时候，后面再到达的所有分组就都会被丢弃，这种就叫做[尾部丢弃策略]
• 对于这种策略其实容错率很高，因为随着尾部的一连串分组的丢弃，会影响到很多条TCP的连接，这就使得许多TCP连接在同一时间突然都进入慢开始状态，这在TCP的术语中就叫做【全局同步】(global synchronization)
• 要解决这种全局同步的问题，就要使用到AQM主动队列管理这种措施，不要等到路由器的队列长度已经达到最大值时才不得不丢弃后面的分组，而是预感到会出现拥塞后做到主动丢弃，这样便可以使得网络拥塞程度减轻甚至不会出现网络拥塞问题

九、TCP的传输连接管理【三次握手，四次挥手】

铺垫了这么多，有关TCP最最最重要的内容到了，你必须有很扎实的基础才能理解这些

• 因为这个在考试中不会过多深入的涉及，但是在校招面试中是网络部分是必考的知识点，因此后面会专门出一个它的讲解

有网上找了许多关于TCP三次握手和四次挥手的视频和文章，筛选了一些，可供复习参考

这个蛋老师讲得很生动

TCP三次握手和四次挥手

楠哥则是解说得很详细

【深度讲解+面试回答】tcp/ip协议三次握手、四次挥手，通俗易懂，亲自解答

这篇是文章——> 博文参考

如果觉得难理解也没关系，了解一下即可，可以的话记住三次握手和四次挥手中客户端与服务端之间发送的报文字段

十、中英互译【背背就能拿分】

十一、终极押题密卷

1. 传输层主要作用：完成进程到进程之间的数据传送。
2. 运输层两种不同些协议：TCP、UDP；他们传输特点：P213

TCP【传输控制协议】

• 提供可靠的、面向连接的运输服务（建立连接—》释放连接）
• 不提供广播或多播服务
• 开销较多（确认、流量控制、计时器以及连接管理）

UDP【用户数据包协议】

• 传送数据之前不需要建立连接
• 收到UDP报后，不需要给出任何确认
• 不提供可靠交付，但是确实一种最有效的工作方式

3. UDP和TCP的应用层协议。P213表5-1

4. 端口号的含义和作用，服务器端使用端口号和客户端使用端口号；P214~215
   • 【含义】：在应用层和传输层之间的界面上，设置一个特殊抽象的门，有了这个门，应用层中的应用进程就必须通过这个门才能将数据经过运输层发送到互联网；而且别的主机上的应用进程要寻找本主机中的某个某个应用进程，也必须通过这个门
   • 【作用】：只具有本地意义，为了标识计算机应用层中各个进程在和运输层交互时的层间接口
   • 【服务器端口号】
     • 熟知端口号：0 ~ 1023
     • 登记端口号：1024 ~ 49151
   • 【客户端端口号】：4915
5. UDP主要特点：P216
   • 无连接、尽最大努力交付、面向报文、没有拥塞控制、支持一对一、一对多、多对一和多对多的交互通信、首部开销小
6. TCP主要特点：P219
   • 面向连接、点对点、可靠交付、全双工通信、面向字节流
7. TCP报文段首部格式。P226
   • 记住一些重要的字段
8. TCP可靠传输的实现。P230
   • 对滑动窗口要重点理解掌握
9. TCP连接建立。三次握手信号；
   • 第一次连接是由客户端发起，客户端会向服务端发送一个报文，在这个TCP报文里，SYN位这个标志位是置1的
   • 当服务段收到这个报文之后就知道客户端要和我发生一个连接，于是服务端就向客户端发送一个确认消息报文，这个消息报文里ACK位是置1的
   • 第三次握手，此时当客户端收到服务端发过来的确认消息的报文之后，还要继续给服务端进行一个回应，所以它也会向服务端发过去一个ACK位是置1的消息报文
10. TCP连接的释放过程，四报文握手，二个2次握手，了解
    • 四次握手是由客户端发起的，在这个报文里面FIN位标志位置1
    • 当服务端收到这个报文之后我就知道了客户端想要和我断开连接，但是此时服务端不一定能做好准备，因为当客户端要发其断开连接的这个消息以后，服务端可能还有没发完的消息要继续发送。以此时服务端只能进行一个消息确认，发送给客户端一个消息确认报文
    • 在发送完这个消息确认报文报文之后，稍过片刻就会继续给客户端发送一个断开连接的一个报文，也是一个FIN位置1的报文【由服务端发送给客户端】，这个报文表示服务端已经做好了断开连接的准备
    • 那么当这个报文发送给客户端后，客户端还要继续给服务端发送一个消息确认的报文ACK位是置1的

日常练习题讲解 —— 考试高频题型

1. 试说明运输层在协议栈中的地位和作用，运输层的通信和网络层的通信有什么重要区别？
   • 【地位和作用】：运输层既属于面向通信部分的最高层，同时也是用户功能中的最低层。当网络边缘部分的两台主机使用网络核心部分的功能进行端到端的通信时，都要使用到协议栈中的运输层
   • 【区别】：网络层为主机之间的通信提供服务；传输层则是在网络层的基础上，为应用进程之间的通信提供服务

---

2. 一个UDP用户数据报的数据字段为8192字节。在链路层要使用以太网来传送。试问应当划分为几个IP数据报片？说明每一个IP数据报片的数据字段长度和片偏移字段的值
   • 加上UDP的8字节首部。IP层的数据字段为8200字节。以太网的MTU为1500B。假设IP层采用默认首部，即20字节。那么应划分为8200/（1500-20），为6片。前5片是1480字节。第6片是800字节。片偏移字段分别是：0，185[1480 / 8]，370[2960/ 8]，555[4440/ 8]，740[5920/ 8]，925[7400/ 8]

---

2. 主机A向主机B连续发送了两个TCP报文段，其序号分别是70和100。试问：
   （1）第一个报文段携带了多少字节的数据？
   （2）主机B收到第一个报文段后发回的确认中的确认号应当是多少？
   （3）如果B收到第二个报文段后发回的确认中的确认号是180，试问A发送的第二个报文段中的数据有多少字节？
   （4）如果A发送的第一个报文段丢失了，但第二个报文段到达了B。B在第二个报文段到达后向A发送确认。试问这个确认号应为多少？

   • ① 由题可得，两个TCP报文的序号分别为70和100，因为第二个报文段的序号为100，所以可以看出第一个报文段携带了30B的有效数据，即70~99
   • ② 因为第一个报文段的最后一个字节为99B，所以主机B发回的确认号ack为99 + 1 = 100
   • ③ 因为主机B收到第二个报文段后发回的确认号ack为180，又因为它在上次发回给主机A说希望收到从100B开始的数据，所以可以看出主机A发送的第二个报文段中的数据有80B
   • ④ 因为第一个报文段中的数据范围是70~99，此时主机B想要收到这些数据，那就可以和主机A说希望收到70字节之后的数据，那主机A就可以知道在这个70字节之后的第一个报文段是丢失了，因此会重复第一个报文段，所以主机B的这个确认号ack应该要为70

---

4. TCP在进行拥塞控制时是以分组的丢失作为产生拥塞的标志。有没有不是因拥塞而引起的分组丢失的情况?如有，请举出一种情况
   • 不是因为拥塞引起的分组丢失，那么分组就不会收到拥塞的影响，也就是说这个IP数据报可以到达它想要去的地方，但是呢由于这个IP报文过长，UDP将其转交给IP层后，IP层在传送时可能要进行分片，这就降低了IP层的效率，使得不同分片的报文到达终点的时间不一样，此时就会有数据报片无法及时到达终点，而早早到达终点的数据报片已经超时，所以会被丢弃，那此时就会导致这个【分组丢失】的现象

---

以上便是对于《计算机网路》中运输层这部分知识点的期末汇总，期盼正在阅读的你可以取得一个好成绩❤️