《网络协议》03. 传输层（TCP & UDP）

title: 《网络协议》03. 传输层（TCP & UDP）

date: 2022-09-04 22:37:11

updated: 2023-11-08 15:58:52

categories: 学习记录：网络协议

excerpt: 传输层、UDP、TCP（可靠传输，流量控制，拥塞控制，三次握手，四次挥手）。

comments: false

tags:

top_image: /images/backimg/SunsetClimbing.png

网络协议

1：网络互连模型
- 1.1：请求过程
- 1.2：网络分层
2：传输层
3：UDP
4：TCP
- 4.1：首部
- 4.2：可靠传输
- - [4.2.1：停止等待 & 超时重传](#4.2.1：停止等待 & 超时重传)
  - [4.2.2：连续 ARQ 协议 & 滑动窗口协议](#4.2.2：连续 ARQ 协议 & 滑动窗口协议)
  - [4.2.3：SACK 技术](#4.2.3：SACK 技术)
  - 4.2.4：可靠传输图示
- 4.3：流量控制
- 4.4：拥塞控制
- - 4.4.1：慢开始
  - 4.4.2：拥塞避免
  - 4.4.3：快重传
  - 4.4.4：快恢复
  - [4.4.5：快重传 & 快恢复](#4.4.5：快重传 & 快恢复)
- 4.5：建立连接
- - 4.5.1：三次握手
  - 4.5.1：补充
- 4.6：释放连接
[5：TCP 序号 & 确认号（详细过程）](#5：TCP 序号 & 确认号（详细过程）)
- [5.1：相对序号 & 确认号](#5.1：相对序号 & 确认号)
- [5.2：原生序号 & 确认号](#5.2：原生序号 & 确认号)
[6：TCP 完整流程](#6：TCP 完整流程)
7：相关命令

网络协议从入门到底层原理。

1：网络互连模型

为了更好地促进互联网络的研究和发展，国际标准化组织 ISO 在 1985 年制定了网络互连模型：OSI 参考模型（Open System Interconnect Reference Model）。

国际标准：OSI 参考模型（7层）
实际应用：TCP/IP 协议（4层）
学习研究：（5层）

1.1：请求过程

1.2：网络分层

2：传输层

传输层（Transport），也叫运输层。

传输层有 2 个协议：

TCP（Transmission Control Protocol），传输控制协议
UDP（User Datagram Protocol），用户数据报协议

3：UDP

数据格式：

UDP 是无连接的，减少了建立和释放连接的开销
UDP 尽最大能力交付，不保证可靠交付，因此不需要维护一些复杂的参数，首部只有 8 个字节（TCP 的首部至少有 20 个字节）

UDP 长度 （Length）
- 占 16 位：首部的长度 + 数据的长度
端口号 （Port）
- UDP 首部中端口是占用 2 字节
- 可以推测出端口号的取值范围是：0 ~ 65535
- 客户端的源端口是临时开启的随机端口

防火墙可以设置开启\关闭某些端口来提高安全性。

检验和 （Checksum）
- 检验和的计算内容：伪首部 + 首部 + 数据

伪首部：仅在计算检验和时起作用，并不会传递给网络层。

4：TCP

TCP 的几个要点：

可靠传输
流量控制
拥塞控制
连接管理（建立连接、释放连接）

数据格式：

4.1：首部

4.1.1：序号

序号（Sequence Number）

占 4 字节
首先，在传输过程的每一个字节都会有一个编号
在建立连接后，序号代表：这一次传给对方的 TCP 数据部分的第一个字节的编号

4.1.2：确认号

确认号（Acknowledgment Number）

占 4 字节
在建立连接后，确认号代表：期望对方下一次传过来的 TCP 数据部分的第一个字节的编号

4.1.3：数据偏移

数据偏移

占 4 位，取值范围是 0b0101 ~ 0b1111（5~15）
数据偏移 * 4 = 首部长度（Header Length）
首部长度是 20 ~ 60 字节

4.1.4：保留

保留（Reserved）

占 6 位，目前全为 0

有些资料中，TCP 首部的保留字段占 3 位，标志字段占 9 位（Wireshark 中也是如此）

UDP 的首部中有个 16 位的字段记录了整个 UDP 报文段的长度（首部 + 数据）。

但是，TCP的首部中仅仅有个 4 位的字段记录了 TCP 报文段的首部长度，并没有字段记录 TCP 报文段的数据长度。

分析：

UDP 首部中占 16 位的长度字段是冗余的，纯粹是为了保证首部是 32 位对齐

TCP/UDP 的数据长度，完全可以由 IP 数据包的首部推测出来
传输层数据长度 = 网络层总长度 - 网络层首部长度 - 传输层首部长度

4.1.5：标志位

标志位（Flags）

URG（Urgent）

当 URG = 1 时，紧急指针字段才有效。表明当前报文段中有紧急数据，应优先尽快传送

ACK（Acknowledgment）

当 ACK = 1 时，确认号字段才有效

PSH（Push）

RST（Reset）

当 RST = 1 时，表明连接中出现严重差错，必须释放连接，然后再重新建立连接

SYN（Synchronization）

当 SYN = 1、ACK = 0 时，表明这是一个建立连接的请求
若对方同意建立连接，则回复 SYN = 1、ACK = 1

FIN（Finish）

当 FIN = 1 时，表明数据已经发送完毕，要求释放连接

4.1.6：窗口

窗口（Window）

占 2 字节
这个字段有流量控制功能，用以告知对方下一次允许发送的数据大小（以字节为单位）

4.1.7：检验和

检验和（CheckSum）

跟 UDP 一样，TCP 检验和的计算内容：伪首部 + 首部 + 数据。

伪首部：占用 12 字节，仅在计算检验和时起作用，并不会传递给网络层。

4.2：可靠传输

可靠传输是为了保证包的完整性，当有丢包、受到三次重复确认等情况，就会重新发包。

4.2.1：停止等待 & 超时重传

ARQ（Automatic Repeat--reQuest），自动重传请求。

疑问：若有个包重传了 N 次还是失败，会一直持续重传到成功为止么？

这个取决于系统的设置，比如有些系统，重传 5 次还未成功就会发送 reset 报文（RST）断开 TCP 连接。

4.2.2：连续 ARQ 协议 & 滑动窗口协议

ARQ（Automatic Repeat--reQuest），自动重传请求。

如果接收窗口最多能接收 4 个包，但发送方只发了 2 个包，接收方如何确定后面还有没有 2 个包？

等待一定时间后没有第 3 个包，就会返回确认收到 2 个包给发送方。

在 TCP 通信过程中，如果发送序列中间某个数据包丢失
（比如 1、2、3、4、5 中 3 丢失了）
TCP 会重传最后确认分组后续的分组
（最后确认的是 2，会重传 3、4、5）
这样原先已经正确传输的分组也可能重复发送（比如 4、5），降低了 TCP 性能
为改善上述情况，发展出了 SACK 技术

4.2.3：SACK 技术

SACK（Selective acknowledgment，选择性确认）

告诉发送方哪些数据丢失，哪些数据已经提前收到
使 TCP 只重新发送丢失的包，不用发送后续所有的分组

SACK 信息会放在 TCP 首部的选项部分
Kind：占 1 字节。值为 5 代表这是 SACK 选项
Length：占 1 字节。表明 SACK 选项一共占用多少字节
Left Edge：占 4 字节，左边界
Right Edge：占 4 字节，右边界

一对边界信息需要占用 8 字节，由于 TCP 首部的选项部分最多 40 字节，所以 SACK 选项最多携带 4 组边界信息
SACK 选项的最大占用字节数 = 4 * 8 + 2 = 34

4.2.4：可靠传输图示

假设每一组数据是 100 个字节，代表一个数据段的数据，每一组给一个编号。

思考：

为什么选择在传输层就将数据 " 大卸八块 " 分成多个段，而不是等到网络层再分片传递给数据链路层？

需要明确的是：可靠传输是在传输层进行控制的
如果在传输层不分段，一旦出现数据丢失，整个传输层的数据都得重传
如果在传输层分了段，一旦出现数据丢失，只需要重传丢失的那些段即可

4.3：流量控制

流量控制：让发送方的发送速率不要太快，让接收方来得及接收处理。

流量控制是点对点、端对端，两台设备之间的。

如果接收方的缓存区满了，发送方还在疯狂着发送数据
接收方只能把收到的数据包丢掉，大量的丢包会极大的浪费网络资源
所以要进行流量控制

原理：

通过确认报文中的窗口字段来控制发送方的发送速率
发送方的发送窗口大小不能超过接收方给出窗口大小
当发送方收到接收窗口的大小为 0 时，发送方就会停止发送数据

流量控制的一种特殊情况：

一开始，接收方给发送方发送了 0 窗口的报文段
后面，接收方又有了一些存储空间，但给发送方发送的非 0 窗口的报文段丢失了
发送方的发送窗口一直为 0，双方陷入僵局

解决方案：

当发送方收到 0 窗口通知时，发送方停止发送报文
同时开启一个定时器，隔一段时间就发个测试报文去询问接收方最新的窗口大小
如果接收的窗口大小还是为 0，则发送方再次刷新定时器

流量控制图示：

4.4：拥塞控制

拥塞控制：防止过多的数据注入到网络中，避免网络中的路由器或链路过载。

拥塞控制是一个全局性的过程，涉及到所有的主机、路由器，以及与降低网络传输性能有关的所有因素，是大家共同努力的结果。

相比而言，流量控制是点对点通信的控制。

拥塞控制方法：

慢开始（slow start，慢启动）
拥塞避免（congestion avoidance）
快速重传（fast retransmit）
快速恢复（fast recovery）

相关概念：

MSS （Maximum Segment Size）：每个段最大数据部分的大小（在建立连接时确定），一般是 MTU（1500）- 20 - 20 = 1460。
cwnd（congestion window）：拥塞窗口。
rwnd（receive window）：接收窗口。
swnd （send window）：发送窗口。swnd = min(cwnd, rwnd)

4.4.1：慢开始

慢开始（slow start），cwnd 的初始值比较小，随着数据包被接收方确认（收到一个 ACK），cwnd 就成倍增长（指数级）。

4.4.2：拥塞避免

拥塞避免（congestion avoidance），拥塞窗口 cwnd 缓慢增大，以防止网络过早出现拥塞（加法增大）。

ssthresh（slow start threshold）：慢开始阈值，cwnd 达到阈值后，开始拥塞避免（加法增大）
乘法减小：只要出现网络拥塞，把 ssthresh 减为拥塞峰值的一半，同时执行慢开始算法（cwnd 又恢复到初始值）
当网络出现频繁拥塞时，ssthresh 值就下降的很快

4.4.3：快重传

快重传（fast retransmit）

接收方
- 每收到一个失序的分组后就立即发出重复确认
- 使发送方及时知道有分组没有到达
- 而不要等待自己发送数据时才进行确认
发送方
- 只要连续收到三个重复确认（总共 4 个相同的确认），就应当立即重传对方尚未收到的报文段
- 而不必继续等待重传计时器到期后再重传

4.4.4：快恢复

快恢复（fast recovery）：当发送方连续收到三个重复确认，就执行 " 乘法减小 " 算法，把 ssthresh 减半。

这是为了预防网络发生拥塞

当发送方现在认为网络很可能没有发生拥塞时：

与慢开始不同之处是现在不执行慢开始算法，即 cwnd 现在不恢复到初始值
而是把 cwnd 值设置为 ssthresh 减半后的数值
然后开始执行拥塞避免算法（加法增大），使拥塞窗口缓慢地线性增大

4.4.5：快重传 & 快恢复

发送窗口的最大值 swnd = min(cwnd, rwnd)

当 rwnd < cwnd 时，是接收方的接收能力限制发送窗口的最大值
当 rwnd > cwnd 时，是网络的拥塞限制发送窗口的最大值

4.5：建立连接

4.5.1：三次握手

状态解读：

CLOSED：client 处于关闭状态
LISTEN：server 处于监听状态，等待 client 连接
SYN-RCVD：表示 server 接受到了 SYN 报文，当收到 client 的 ACK 报文后，它会进入到 ESTABLISHED 状态
SYN-SENT：表示 client 已发送 SYN 报文，等待 server 的第 2 次握手
ESTABLISHED：表示连接已经建立

前2次握手的特点：

SYN 都设置为 1
数据部分的长度都为 0
TCP 头部的长度一般是 32 字节
- 固定头部：20 字节
- 选项部分：12 字节
双方会交换确认一些信息
- 比如 MSS、是否支持 SACK、Window scale（窗口缩放系数）等
- 这些数据都放在 TCP 头部的选项部分（12 字节）

4.5.1：补充

为什么建立连接的时候，要进行 3 次握手？2 次不行吗？

主要目的：防止 server 端一直等待，浪费资源。

如果建立连接只需要 2 次握手，可能会出现的情况：

假设 client 发出的第一个连接请求报文段，因为网络延迟，在连接释放以后的某个时间才到达 server
本来这是一个早已失效的连接请求，但 server 收到此失效的请求后，误认为是 client 再次发出的一个新的连接请求
于是 server 就向 client 发出确认报文段，同意建立连接
如果不采用 3 次握手，那么只要 server 发出确认，新的连接就建立了
由于现在 client 并没有真正想连接服务器的意愿，因此不会理睬 server 的确认，也不会向 server 发送数据
但 server 却以为新的连接已经建立，并一直等待 client 发来数据，这样，server 的资源就白白浪费掉了

三次握手可以防止上述现象发生。

例如上述情况，client 没有向 server 的确认发出确认，server 由于收不到确认，就知道 client 并没有要求建立连接。

如果第 3 次握手失败了，会怎么处理？

此时 server 的状态为 SYN-RCVD，若等不到 client 的 ACK，server 会重新发送 SYN+ACK 包。
如果 server 多次重发 SYN+ACK 都等不到 client 的 ACK，就会发送 RST 包，强制关闭连接

4.6：释放连接

4.6.1：四次挥手

状态解读：

FIN-WAIT-1：表示想主动关闭连接
- 向对方发送了 FIN 报文，此时进入到 FIN-WAIT-1 状态
CLOSE-WAIT：表示在等待关闭
- 当对方发送 FIN 给自己，自己会回应一个 ACK 报文给对方，此时则进入到 CLOSE-WAIT 状态
- 在此状态下，需要考虑自己是否还有数据要发送给对方，如果没有，发送 FIN 报文给对方
FIN-WAIT-2：只要对方发送 ACK 确认后，主动方就会处于 FIN-WAIT-2 状态，然后等待对方发送 FIN 报文
CLOSING：一种比较罕见的例外状态
- 表示你发送 FIN 报文后，并没有收到对方的 ACK 报文，反而却也收到了对方的 FIN 报文
- 如果双方几乎在同时准备关闭连接的话，那么就出现了双方同时发送 FIN 报文的情况，也即会出现 CLOSING 状态
- 表示双方都正在关闭连接
LAST-ACK：被动关闭一方在发送 FIN 报文后，最后等待对方的 ACK 报文
- 当收到 ACK 报文后，即可进入 CLOSED 状态了
TIME-WAIT：表示收到了对方的 FIN 报文，并发送出了 ACK 报文，就等 2 MSL 后即可进入 CLOSED 状态
- 如果 FIN-WAIT-1 状态下，收到了对方同时带 FIN 标志和 ACK 标志的报文时，可以直接进入到 TIME-WAIT 状态，而无须经过 FIN-WAIT-2 状态
CLOSED：关闭状态

MSL （Maximum Segment Lifetime，最大分段生存期），是 TCP 报文在 Internet 上的最长生存时间。

每个具体的 TCP 实现都必须选择一个确定的 MSL 值，RFC 1122 建议是 2 分钟。
由于有些状态的时间比较短暂，所以很难用 netstat 命令看到，比如 SYN-RCVD、FIN-WAIT-1 等。

4.6.2：细节

TCP 是全双工模式。
TCP/IP 协议栈在设计上，允许任何一方先发起断开请求。上面演示的是 client 主动要求断开。
client 发送 ACK 后，需要有个 TIME-WAIT 阶段，等待一段时间后，再真正关闭连接。
- 一般是等待 2 倍的 MSL。
- 可以防止本次连接中产生的数据包误传到下一次连接中。
- 因为本次连接中的数据包都会在 2MSL 时间内消失了。
如果 client 发送 ACK 后马上释放了，然后又因为网络原因，server 没有收到 client 的 ACK，server 就会重发 FIN，这时可能出现两种情况：
- client 没有任何响应，服务器那边会干等，甚至多次重发 FIN，浪费资源
- client 有个新的应用程序刚好分配了同一个端口号，新的应用程序收到 FIN 后马上开始执行断开连接的操作，本来它可能是想跟 server 建立连接的
有时候在使用抓包工具的时候，有可能只会看到 " 3 次挥手 "。
- 这其实是将第 2、3 次挥手合并了
- 当 server 接收到 client 的 FIN 时，如果 server 后面也没有数据要发送给 client了
- 这时，server 就可以将第 2、3 次挥手合并。同时告诉 client 两件事：
  1、已经知道 client 没有数据要发
  2、server 已经没有数据要发了

4.6.3：补充

为什么释放连接的时候，要进行 4 次挥手？

第 1 次挥手：当主机 1 发出 FIN 报文段时
- 表示主机 1 告诉主机 2，主机 1 已经没有数据要发送了
- 但是此时主机 1 还是可以接受来自主机 2 的数据
第 2 次挥手：当主机 2 返回 ACK 报文段时
- 表示主机 2 已经知道主机 1 没有数据发送了
- 但是主机 2 还是可以发送数据到主机 1
第 3 次挥手：当主机 2 也发送了 FIN 报文段时
- 表示主机 2 告诉主机 1，主机 2 已经没有数据要发送了
第 4 次挥手：当主机 1 返回 ACK 报文段时
- 表示主机 1 已经知道主机 2 没有数据发送了
- 随后正式断开整个 TCP 连接