运输层（传输层）

## 概述

运输层是 TCP/IP 协议栈的第四层（OSI 模型第四层），核心作用是在源主机和目标主机的应用程序之间提供端到端的通信服务，连接上层的应用层和下层的网络层。

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

根据应用需求的不同，因特网的运输层为应用层提供了两种不同的运输层协议，即面向连接的TCP和无连接的UDP。

### TCP

传输控制协议（Transmission Control Protocol，TCP）为其上层提供的是面向连接的可靠的数据传输服务。

每一条TCP连接只能有两个端点EP，只能是一对一通信。

使用TCP通信的双方，在传送数据之前必须首先建立TCP连接（逻辑连接，而非物理连接）。数据传输结束后必须要释放TCP连接。

TCP为了实现可靠传输，就必须使用很多措施，例如TCP连接管理、确认机制、超时重传、流量控制以及拥塞控制等。

TCP的实现复杂，TCP报文段的首部比较大，占用处理机资源比较多。

TCP是面向字节流的。

TCP报文段首部最小20字节，最大60字节。

### UDP

用户数据报协议（User Datagram Protocol，UDP）为其上层提供的是无连接的不可靠的数据传输服务。

支持“一对一”、“一对多”、“多对一”和“多对多”交互通信。

使用UDP通信的双方，在传送数据之前不需要建立连接。

UDP不需要实现可靠传输，因此不需要使用实现可靠传输的各种机制。

UDP的实现简单，UDP用户数据报的首部比较小。

UDP是面向应用报文的。

因特网中的一些典型应用所使用的TCP/IP应用层协议和相应的运输层协议。

![image-20250922001831875](https://oss.maolin101.com/image-20250922001831875.png-101.webp)

### 相应的运输层协议

| 因特网应用     | TCP/IP应用层协议     | TCP/IP运输层协议 |
| -------------- | -------------------- | ---------------- |
| 域名解析       | 域名系统DNS          | UDP              |
| 文件传送       | 简单文件传送协议TFTP | UDP              |
| 路由选择       | 路由信息协议RIP      | UDP              |
| 网络参数配置   | 动态主机配置协议DHCP | UDP              |
| 网络管理       | 简单网络管理协议SNMP | UDP              |
| 远程文件服务器 | 网络文件系统NFS      | UDP              |
| IP电话         | 专用协议             | UDP              |
| 流媒体通信     | 专用协议             | UDP              |
| IP多播         | 网际组管理协议IGMP   | UDP              |
| 电子邮件       | 简单邮件传送协议SMTP | TCP              |
| 远程终端接入   | 电传机网络TELNET     | TCP              |
| 万维网         | 超文本传送协议HTTP   | TCP              |
| 文件传送       | 文件传送协议FTP      | TCP              |

### 端口号

运输层端口号是运行在计算机上的进程是使用进程标识符（Process Identification，PID）来标识的。

因特网上的计算机并不是使用统一的操作系统，而不同操作系统（Windows、Linux、MacOS）又使用不同格式的进程标识符。

为了使运行不同操作系统的计算机的应用进程之间能够基于网络进行通信，就必须使用统一的方法对TCP/IP体系的应用进程进行标识。

TCP/IP体系结构的运输层使用端口号来标识和区分应用层的不同应用进程，端口号的长度为16比特，取值范围是0~65535。

服务端使用端口：

- 熟知端口号（由IANA分配给TCP/IP体系结构应用层中最重要的一些应用协议）0~1023；
- 登记端口号（为没有熟知端口号的应用程序使用。要使用这类端口号，必须在IANA进行登记，以防止重复。例如，Microsoft RDP微软远程桌面应用程序使用的端口号是3389）1024~49151。

| FTP   | SMTP | DNS  | DHCP  | HTTP | BGP  | HTTPS | RIP  |
| ----- | ---- | ---- | ----- | ---- | ---- | ----- | ---- |
| 21/20 | 25   | 53   | 67/68 | 80   | 179  | 443   | 520  |

客户端使用端口号（仅在客户端使用，由客户进程在运行时动态选择，通信结束后会被系统收回，以便给其他客户进程使用）：短暂端口号49152~65535

端口号只具有本地意义，即端口号只是为了标识本计算机网络协议栈应用层中的各应用进程。

在因特网中，不同计算机中的相同端口号是没有关系的，即相互独立。另外，TCP和UDP端口号之间也是没有关系的。

## TCP

TCP 是 **TCP/IP 协议栈运输层**的核心协议，全称为 Transmission Control Protocol，其核心定位是为应用程序提供**面向连接、可靠、有序**的端到端数据传输服务，是绝大多数需要稳定性的网络应用（如网页、文件传输）的基础。

### 特性

**面向连接**：数据传输前必须通过 “三次握手” 建立连接，传输结束后通过 “四次挥手” 断开连接，确保通信双方状态同步。

可靠传输：通过多重机制保证数据不丢失、无差错、按序到达：

- **确认机制（ACK）**：接收方收到数据后，会向发送方返回确认报文，告知 “已收到”。
- **重传机制**：若发送方超时未收到确认，会自动重传未被确认的数据。
- **排序机制**：给每个数据段分配序号，接收方按序号重组数据，避免乱序。
- **校验和**：对数据进行校验，丢弃损坏的数据包并触发重传。

**流量控制**：通过 “滑动窗口” 机制，让接收方根据自身缓冲区大小，动态告知发送方 “最多能接收多少数据”，避免发送过快导致接收方溢出。

**拥塞控制**：监测网络状态，若发现网络拥堵（如丢包），会主动减少数据发送速率，避免加剧网络负担（如慢启动、拥塞避免算法）。

### 首部格式

![image-20250921234335480](https://oss.maolin101.com/image-20250921234335480.png-101.webp)

序号：占32比特，取值范围0~2^32-1。当序号增加到最后一个时，下一个序号又回到0。用来指出本TCP报文段数据载荷的第一个字节的序号。

确认号：占32比特，取值范围0~2^32-1。当确认号增加到最后一个时，下一个确认号又回到0。用来指出期望收到对方下一个TCP报文段的数据载荷的第一个字节的序号，同时也是对之前收到的所有数据的确认。

数据偏移：占4比特，该字段的取值以4字节为单位。指出TCP报文段的数据载荷部分的起始处距离TCP报文段的起始处有多远，这实际上指出了TCP报文段的首部长度。

保留：占6比，保留为后使用，目前应置为0。

紧急标志位URG：当URG=1时，紧急指针字段有效。当URG=0时，紧急指针字段无效。

确认标志位ACK：只有当ACK取值为1时，确认号字段才有效。ACK取值为0时，确认号字段无效。TCP规定：在TCP连接建立后，所有传送的TCP报文段都必须把ACK置1。

推送标志位PSH：发送方TCP把PSH置1，并立即创建一个TCP报文段发送出去，而不需要积累到足够多的数据再发送。接收方TCP收到PSH为1的TCP报文段，就尽快地交付给应用进程，而不再等到接收到足够多的数据才向上交付。

复位标志位RST：用于复位TCP连接。当RST=1时，表明TCP连接中出现严重差错，必须释放连接，然后再重新建立连接。RST置1还用来拒绝一个非法的TCP报文段或拒绝打开一个TCP连接。

同步标志位SYN：用于TCP“三报文握手”建立连接。当SYN=1且ACK=0时，表明这是一个TCP连接请求报文段。对方若同意建立连接，则应在响应的TCP报文段的首部中使SYN=1且ACK=1。综上所述，SYN为1的TCP报文段要么是一个连接请求报文段，要么是一个连接响应报文段。

终止标志位FIN：用于TCP“四报文挥手”释放连接。当FIN=1时，表明此TCP报文段的发送方已经将全部数据发送完毕，现在要求释放TCP连接。

窗口：占16比特，该字段的取值以字节为单位。指出发送本报文段的一方的接收窗口的大小，即接收缓存的可用空间大小，这用来表征接收方的接收能力。在计算机网络中，经常用接收方的接收能力的大小来控制发送方的数据发送量，这就是所谓的流量控制。

检验和：占16比特，用来检查整个TCP报文段在传输过程中是否出现了误码。

紧急指针：占16比特，以字节为单位，用来指明紧急数据的长度。当发送方有紧急数据时，可将紧急数据“插队”到发送缓存的最前面，并立刻封装到一个TCP报文段中进行发送。紧急指针会指出本报文段数据载荷部分包含了多长的紧急数据，紧急数据之后是普通数据。接收方收到紧急标志位为1的TCP报文段，会按照紧急指针字段的值从报文段数据载荷中取出紧急数据并直接上交应用进程，而不必在接收缓存中排队。

选项（长度可变，最大40字节）：最大报文段长度MSS选项：指出TCP报文段数据载荷部分的最大长度，而不是整个TCP报文段的长度。窗口扩大选项：用来扩大窗口，提高吞吐率。时间戳选项：用于计算往返时间RTT，用于处理序号超范围的情况，又称为防止序号绕回PAWS。选择确认选项：用来实现选择确认功能。

### 三次握手（建立连接）

目的：确保客户端和服务器双方的 “发送” 和 “接收” 能力均正常，避免无效连接。

TCP是面向连接的协议，它基于运输连接来传送TCP报文段。

TCP运输连接的建立和释放，是每一次面向连接的通信中必不可少的过程。

TCP运输连接有以下三个阶段：

- 通过“三报文握手”来建立TCP连接。
- 基于已建立的TCP连接进行可靠的数据传输。
- 在数据传输结束后，还要通过“四报文挥手”来释放TCP连接。

三次握手的目的是：

- 使TCP双方能够确知对方的存在。
- 使TCP双方能够协商一些参数（例如最大报文段长度、最大窗口大小、时间戳选项等）。
- 使TCP双方能够对运输实体资源进行分配和初始化。运输实体资源包括缓存大小、各状态变量、连接表中的项目等。

**第一次握手：** 客户端发送给服务器端SYN=1和seq=x（序号seq字段被设置了一个初始值x，作为TCP客户进程所选择的初始序号。）

注意：

TCP规定同步标志位SYN被设置为1的报文段（例如TCP连接请求报文段和TCP连接请求确认报文段）不能携带数据，但要消耗掉一个序号。

TCP连接请求报文段不能携带数据（即没有数据载荷），但是会消耗掉序号x。因此，TCP客户进程下一次发送的TCP报文段的数据载荷的第一个字节的序号为x+1。

**第二次握手：** 服务器端响应客户端SYN=1  ACK=1、seq=y、ack=x+1。

注意：

TCP连接请求确认报文段首部中的同步标志位SYN和确认标志位ACK的值都设置为1。

序号seq字段被设置了一个初始值y，作为TCP服务器进程所选择的初始序号。

确认号ack字段的值被设置为x+1，这是对TCP客户进程所选择的初始序号x的确认。

**第三次握手：** 客户端发送给服务器端ACK=1、seq=x+1、ack=y+1。

注意：
确认标志位ACK的值被设置为1，表明这是一个普通的TCP确认报文段。

因为TCP客户进程之前发送的TCP连接请求报文段的序号为x，该报文段虽然不能携带数据，但要消耗掉一个序号。因此TCP客户进程发送的第二个报文段的序号为x+1。

TCP规定普通的TCP确认报文段可以携带数据，但如果不携带数据，则不消耗序号。

如果该报文段不携带数据，则TCP客户进程要发送的下一个数据报文段的序号仍为x+1。

确认号ack字段的值被设置为y+1，这是对TCP服务器进程所选择的初始序号y的确认。

三次握手完成，就可以基于已建立好的TCP连接进行可靠数据传输。

采用“三报文握手”而不是“两报文握手”来建立TCP连接，是为了防止已失效的TCP连接请求报文段突然又传送到了TCP服务器进程，因而导致错误。

### 四次挥手（断开连接）

**第一次挥手：** 客户端向服务器端发送FIN=1、ACK=1、seq=u、ack=v。

注意：

TCP连接释放报文段首部中的终止标志位FIN和确认标志位ACK的值都被设置为1。表明这是一个TCP连接释放报文段，同时也对之前收到的TCP报文段进行确认。

序号seq字段的值设置为u，它等于TCP客户进程之前已经传送过的数据的最后一个字节的序号加1。

确认号ack字段的值设置为v，它等于TCP客户进程之前已收到的数据的最后一个字节的序号加1。

**第二次挥手：** 服务器端向客户端响应ACK=1、seq=v、ack=u+1。

注意：

确认标志位ACK的值被设置为1，表明这是一个TCP普通确认报文段。

序号seq字段的值设置为v，它等于TCP服务器进程之前已传送过的数据的最后一个字节的序号加1。这也与之前收到的TCP连接释放报文段中的确认号v匹配。

确认号ack字段的值设置为u+1，这是对TCP连接释放报文段的确认。

从TCP客户进程到TCP服务器进程这个方向的连接就释放了，此时的TCP连接属于半关闭状态（TCP客户进程已经没有数据要发送了。但TCP服务器进程如果还有数据要发送，TCP客户进程仍要接收，也就是从TCP服务器进程到TCP客户进程这个方向的连接并未关闭。）。

**第三次挥手：** 服务器端向客户端发送FIN=1、ACK=1、seq=w、ack=u+1。

注意：
TCP连接释放报文段首部中的终止标志位FIN和确认标志位ACK的值都被设置为1。表明这是一个TCP连接释放报文段，同时也对之前收到的TCP报文段进行确认。

序号seq字段的值假定被设置为w，这是因为在半关闭状态下TCP服务器进程可能又发送了一些数据。

确认号ack字段的值被设置为u+1，这是对之前收到的TCP连接释放报文段的重复确认。

**第四次挥手：** 客户端向服务器端响应ACK=1、seq=u+1、ack=w+1。

注意：

确认标志位ACK的值设置为1，表明这是一个TCP普通确认报文段。

序号seq字段的值设置为u+1，这是因为TCP客户进程之前发送的TCP连接释放报文段虽然不携带数据，但要消耗掉一个序号。

确认号ack字段的值设置为w+1，这是对所收到的TCP连接释放报文段的确认。

MSL是最长报文段寿命（Maximum Segment Lifetime）的英文缩写词，[RFC793]建议为2分钟。也就是说，TCP客户进程进入时间等待（TIME-WAIT）状态后，还要经过4分钟才能进入关闭（CLOSED）状态。

### 流量控制

TCP为应用程序提供了流量控制（Flow Control）机制，以解决因发送方发送数据太快而导致接收方来不及接收，造成接收方的接收缓存溢出的问题。

流量控制的基本方法：接收方根据自己的接收能力（接收缓存的可用空间大小）控制发送方的发送速率。

窗口（rwnd）滑动。

![image-20250922001229561](https://oss.maolin101.com/image-20250922001229561.png-101.webp)

### 拥塞控制

在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能就要变坏，这种情况就叫作拥塞（congestion）。

计算机网络中的链路容量（带宽）、交换节点中的缓存和处理机等都是网络的资源。

若出现拥塞而不进行控制，整个网络的吞吐量将随输入负荷的增大而下降。

![image-20250922001316220](https://oss.maolin101.com/image-20250922001316220.png-101.webp)

拥塞控制的基本方法：

- 流量控制：接收方根据接收缓存的可用空间大小控制发送方的发送速率。
- 拥塞控制：防止过多的数据注入到网络中，使网络能够承受现有的网络负荷。

经典的 TCP 拥塞控制包含以下四种核心方法，通常按 “连接初期→稳定传输→丢包应对” 的流程协同工作：

### 1. 慢启动（Slow Start）

**核心作用**：连接建立初期，快速探测网络的最大承载能力（“慢启动” 名不副实，实际是 “快速试探”）。

工作逻辑：

1. 初始时，拥塞窗口（cwnd）设为较小值（通常为 1~2 个 MSS，即最大分段大小）。
2. 每收到一个来自接收方的**确认报文（ACK）**，cwnd 就翻倍（指数级增长）。
3. 当 cwnd 增长到**慢启动阈值（ssthresh，初始由系统预设）** 时，切换到 “拥塞避免” 阶段。

**关键细节**：不直接发送大量数据，而是通过指数增长快速逼近网络容量，避免初期就引发拥堵。

### 2. 拥塞避免（Congestion Avoidance）

**核心作用**：当接近网络容量时，平稳增加发送量，避免突然超出网络承载能力。

工作逻辑：

1. 进入该阶段后，cwnd 不再指数增长，而是**每经过一个 RTT（往返时间），cwnd 仅增加 1 个 MSS（线性增长）**。

2. 持续监测网络状态：若未出现丢包，继续线性扩大 cwnd；若出现超时丢包（判断为严重拥堵），则：

将 ssthresh 重置为当前 cwnd 的一半；

将 cwnd 重新设为初始值（1~2 个 MSS），回到 “慢启动” 阶段重新试探。

**关键细节**：通过 “线性增长” 缓慢探测网络上限，平衡 “传输效率” 和 “避免拥堵”。

### 3. 快速重传（Fast Retransmit）

**核心作用**：无需等待 “超时”，快速检测并重传丢失的数据包，减少丢包后的延迟。

工作逻辑：

1. 当接收方收到**乱序数据包**（如期望收到序号 3，却先收到 4、5、6）时，会连续向发送方返回**3 个重复的 ACK**（均确认 “已收到序号 2”，暗示 “序号 3 丢失”）。
2. 发送方收到 “3 个连续重复 ACK” 后，立即判断 “对应序号的数据包已丢失”，**不等待超时**，直接重传丢失的数据包。

**关键细节**：用 “重复 ACK” 替代 “超时” 作为丢包信号，大幅缩短重传延迟（尤其适合高带宽、长延迟的网络）。

### 4. 快速恢复（Fast Recovery）

**核心作用**：配合 “快速重传” 使用，丢包后避免回到低效的 “慢启动”，快速恢复到稳定传输状态。

工作逻辑：

1. 发送方触发 “快速重传” 后，立即进入 “快速恢复” 阶段：
   - 将 ssthresh 重置为当前 cwnd 的一半；
   - 将 cwnd 设为新的 ssthresh（而非初始值），直接进入 “拥塞避免” 的线性增长阶段。
2. 后续每收到一个 ACK，cwnd 线性增加 1 个 MSS，直至恢复到之前的传输速率。

**关键细节**：仅在 “3 个重复 ACK 触发的丢包”（判断为轻度拥堵）时使用；若为 “超时丢包”（判断为严重拥堵），仍需回到 “慢启动”。