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:网络互连模型
-
- 2:传输层
- 3:UDP
- 4:TCP
-
- 4.1:首部
-
- 4.1.1:序号
- 4.1.2:确认号
- 4.1.3:数据偏移
- 4.1.4:保留
- 4.1.5:标志位
- 4.1.6:窗口
- 4.1.7:检验和
- 4.2:可靠传输
-
- 4.2.1:停止等待 & 超时重传
- 4.2.2:连续 ARQ 协议 & 滑动窗口协议
- 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.5:建立连接
-
- 4.6:释放连接
-
- 4.6.1:四次挥手
- 4.6.2:细节
- 4.6.3:补充
- 5:TCP 序号 & 确认号(详细过程)
-
- 5.1:相对序号 & 确认号
- 5.2:原生序号 & 确认号
- 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)
- 端口号(Port)
- UDP 首部中端口是占用 2 字节
- 可以推测出端口号的取值范围是:0 ~ 65535
- 客户端的源端口是临时开启的随机端口
防火墙可以设置开启\关闭某些端口来提高安全性。
伪首部:仅在计算检验和时起作用,并不会传递给网络层。
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)
有些资料中,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)
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 字节
- 双方会交换确认一些信息
- 比如 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 连接
长连接、短连接的概念:
- 如果建立连接后不需要进行数据交互就会关闭,那就是短连接。
- 如果建立连接后需要进行数据交互以后再关闭,那就是长连接。
5:TCP 序号 & 确认号(详细过程)
5.1:相对序号 & 确认号
5.2:原生序号 & 确认号
6:TCP 完整流程
示例一:
示例二:
7:相关命令
Windows 下的一些相关命令。
查看被占用的端口:
netstat –an
查看被占用的端口、占用端口的应用程序:
netstat –anb
查看是否可以访问主机的某个端口:
telnet <主机> <端口>
终古闲情归落照,一春幽梦逐游丝。
——《浣溪沙》(清)纳兰性德