计算机网络学习笔记 | 传输层核心知识点总结（DAY03,匠心制作）
计算机网络学习笔记 | 传输层核心知识点总结（DAY03）
大家好！今天是计算机网络学习的第三天，重点攻克了传输层的内容。作为OSI模型和TCP/IP模型中的第四层，传输层是连接应用层与网络层的关键纽带，直接影响数据传输的效率与可靠性。这篇博客会从我的学习视角出发，梳理传输层的核心知识点，尤其聚焦TCP与UDP两大协议的差异及TCP的连接管理机制，适合和我一样刚入门计算机网络的同学参考~
一、传输层：定位与核心目标
在开始具体协议学习前，我先理清了传输层的“角色定位”——它不像网络层那样关注“主机到主机”的通信，而是聚焦“应用进程到应用进程”的数据传输，简单说就是给应用层的进程们提供“专属通信通道”。
1. 核心目标
传输层的核心任务是向应用层进程提供高效、可靠、性价比合理的数据传输服务。这里的“可靠”并非强制（比如UDP就不保证可靠），而是根据应用场景灵活选择。
2. 传输层在不同参考模型中的位置
为了理解传输层的层级关系，我对比了三种常见参考模型，表格整理如下（一目了然）：
| 参考模型 | 各层结构（从上到下） |
|---|---|
| OSI参考模型 | 应用层 → 表示层 → 会话层 → 传输层 → 网络层 → 数据链路层 → 物理层 |
| TCP/IP参考模型 | 应用层 → （表示层、会话层功能融合）→ 传输层 → 网络层 → 链路层 → （物理层功能融合） |
| 五层参考模型 | 应用层 → 传输层 → 网络层 → 链路层 → 物理层 |
可以看到，无论哪种模型，传输层都始终处于“应用层下方、网络层上方”，承担着“承上启下”的作用。
二、传输层的基础能力：逻辑通信与多路复用/分用
这两个概念是理解传输层工作原理的基础，刚开始有点绕，后来结合示意图终于想通了~
1. 逻辑通信
传输层通过协议（TCP/UDP）为不同主机的应用进程“模拟”了一条直接的通信链路，这就是逻辑通信。它的核心作用是屏蔽底层网络层的传输细节——比如IP层的路由转发、丢包重传等，让应用进程感觉自己在“直接和对方进程通信”，不用关心数据在物理网络中怎么传。
2. 多路复用与多路分用
这是传输层“一对多”和“多对一”通信的关键机制，举个例子就能理解：
- 多路复用（发送端）：一台主机上的多个应用进程（比如浏览器、QQ、微信），会将数据通过不同的“端口号”交给传输层，传输层再将这些数据封装成统一格式的报文（TCP段或UDP数据报），通过同一条网络链路发送出去。
- 多路分用（接收端）：接收端传输层收到报文后，会根据报文中的“目的端口号”，将数据准确分发给对应的应用进程（比如80端口分给浏览器，443端口分给HTTPS服务）。
而实现这一切的核心标识，就是下面要讲的端口号。
三、端口号：应用进程的“身份证”
端口号是传输层给应用进程分配的“唯一标识”，没有它，传输层就不知道该把数据交给哪个进程。
1. 端口号基本属性
- 长度：16位二进制数，因此取值范围是 0~65535（共65536个端口）。
- 本质：端口号是“软件层面”的标识，不属于硬件（和网卡MAC地址、IP地址不同）。
2. 端口号分类及用途
根据用途，端口号分为三类，我用表格整理了关键信息：
| 分类 | 子分类 | 取值范围 | 用途说明 |
|---|---|---|---|
| 服务端端口号 | 知名端口号 | 0~1023 | 固定分配给常见网络服务，比如HTTP用80端口、FTP用21端口、DNS用53端口。 |
| 注册端口号 | 1024~49151 | 供已注册的应用程序使用（需向IANA申请），避免端口冲突，比如MySQL用3306端口。 | |
| 客户端端口号 | - | 49152~65535 | 由客户端进程临时申请使用，通信结束后立即释放，也叫“临时端口号”。 |
四、传输层两大核心协议：TCP vs UDP
这是今天学习的重点！TCP和UDP是传输层的“两大支柱”，但设计理念完全不同，适用场景也天差地别。
1. TCP与UDP核心差异对比
为了清晰区分，我整理了一张对比表，涵盖连接特性、可靠性、通信方式等关键维度：
| 特性维度 | 用户数据报协议（UDP） | 传输控制协议（TCP） |
|---|---|---|
| 连接特性 | 无连接、不可靠传输 | 面向连接、可靠传输 |
| 连接流程 | 无需建立/释放连接，直接发送数据 | 需“三次握手”建立连接，“四次挥手”释放连接 |
| 数据交付保障 | 仅“尽力而为”，不保证顺序和完整性 | 通过序号、确认号、重传等保障可靠交付 |
| 通信方式支持 | 支持一对一、一对多、多对多（广播/多播） | 仅支持一对一通信 |
| 首部开销 | 小（固定8字节） | 大（最小20字节，含选项可达60字节） |
2. 适用场景
- UDP适用场景：对
实时性要求高、可容忍少量丢包的场景，比如：- 视频直播/语音通话（卡顿比延迟更影响体验）；
- DNS解析（请求/响应数据量小，追求快）；
- 游戏数据传输（实时操作比个别丢包重要）。
- TCP适用场景：对数据
可靠性要求高、不允许丢包的场景，比如：- 网页浏览（HTTP/HTTPS基于TCP，不能漏传代码）；
- 文件传输（FTP，丢包会导致文件损坏）；
- 电子邮件（SMTP，不能少发/错发邮件）。
五、UDP协议详解：简单高效的“轻量级”协议
UDP的设计非常简单，核心是“封装数据+发送”，没有复杂的控制机制。我重点学习了它的数据报结构和校验和。
1. UDP数据报结构
UDP数据报由“首部”和“数据”两部分组成，首部固定8字节，结构如下：
| 字段 | 长度（bit） | 说明 |
|---|---|---|
| 源端口 | 16 | 发送方应用进程的端口号 |
| 目的端口 | 16 | 接收方应用进程的端口号 |
| UDP长度 | 16 | 整个UDP报文的长度（首部+数据） |
| UDP校验和 | 16 | 校验数据报的完整性 |
| 数据 | 可变 | 应用层传递的具体数据 |
2. 关键字段解析
- UDP长度：单位是字节，最小值为8（
只有首部，无数据），最大值为65535（受16位字段限制）。如果数据超过65535-8=65527字节，需要应用层自己分片。 - UDP校验和：这是UDP唯一的“可靠性保障”，计算范围包括三部分：
- 伪首部：包含源IP、目的IP、协议号（UDP为17）、UDP长度，用于确认“数据是发给当前主机的正确进程”；
- UDP首部；
- UDP数据。
计算方法：将这三部分按16位分组累加，对结果取反，得到校验和。接收端会重新计算，如果结果不一致，说明数据传输中损坏，直接丢弃报文。
六、TCP协议详解：可靠传输的“重量级”协议
TCP比UDP复杂得多，核心是通过各种机制实现“可靠传输”。我从报文结构、核心字段、连接管理三个方面展开学习。
1. TCP报文结构
TCP报文（也叫TCP段）由“首部”和“数据”组成，首部最小20字节，含选项字段时最大60字节。关键字段如下（只列重点）：
| 字段 | 长度（bit） | 功能说明 |
|---|---|---|
| 源端口/目的端口 | 16/16 | 标识发送方/接收方进程（和UDP一致） |
| 序号（Seq） | 32 | 本报文数据第一个字节的序号，保障数据有序 |
| 确认号（Ack） | 32 | 期望收到的下一个字节序号（仅ACK=1时有效），保障可靠确认 |
| 头部长度 | 4 | TCP首部长度（以4字节为单位），区分首部和数据 |
| 控制位 | 8 | 含SYN、ACK、FIN等8个标志位，控制连接建立/关闭、数据传输 |
| 窗口大小 | 16 | 接收方告知发送方的“可接收数据量”，实现流量控制 |
| 校验和 | 16 | 校验TCP报文完整性（含伪首部） |
| 选项 | 0~40字节 | 常见MSS（最大段大小）、窗口扩大因子等 |
2. TCP核心字段详解
这几个字段是TCP可靠传输的关键，必须吃透：
（1）序号（Seq）
- 定义：32位字段，标识本报文数据第一个字节的“全局序号”。
- 生成规则：三次握手时，双方会随机生成一个“初始序号（ISN）”；后续每发送1字节数据，序号+1。
- 示例：如果发送方要传3000字节数据，初始序号为0，会分成3个报文段，序号分别为0（0999字节）、1000（10001999字节）、2000（2000~2999字节）。
（2）确认号（Ack）
- 有效性：只有当控制位中的ACK=1时，确认号才有效。
- 定义：表示“接收方期望收到的下一个字节序号”，即“已正确收到ack-1之前的所有数据”。
- 示例：接收方收到序号为1000、长度为500字节的报文，说明已收到1000~1499字节，下次期望收到1500字节，因此确认号填1500。
（3）控制位（8个标志位）
控制位是TCP的“操作指令”，每个位对应不同功能，重点记4个核心位：
- SYN：同步序号，用于建立连接（三次握手时发送）；
- ACK：确认标识，用于确认收到数据（除了第一次握手，其他报文都带ACK=1）；
- FIN：结束标识，用于释放连接（四次挥手时发送）；
- RST：重置连接，用于处理异常（比如连接超时，强制断开）。
（4）选项：MSS（最大段大小）
MSS是TCP连接建立时双方协商的“最大数据段长度”，即TCP报文数据部分的最大长度，计算逻辑如下（以以太网为例）：
- 以太网MTU（最大传输单元）为1500字节（IP层最大报文长度）；
- 需扣除IP首部（20字节）和TCP首部（20字节）；
- 因此，MSS = 1500 - 20 - 20 = 1460字节。
MSS的作用是避免IP分片，减少重组开销，提升传输效率。
3. TCP连接管理：三次握手与四次挥手
这是TCP最核心的机制，也是面试高频考点，我结合状态变化图反复梳理了流程。
（1）三次握手：建立可靠连接
三次握手的目标是“双方确认彼此的发送和接收能力正常”，流程如下：
| 步骤 | 发起方 | 报文内容 | 状态变化 | 说明 |
|---|---|---|---|---|
| 1 | 客户端 | SYN=1，seq=X（随机ISN） | ESTABLISHED → SYN-SENT | 客户端请求建立连接，发送同步报文，告知自己的初始序号X |
| 2 | 服务端 | SYN=1，ACK=1，seq=Y，ack=X+1 | LISTEN → SYN-RECEIVED | 服务端确认收到客户端报文（ack=X+1），同时发送自己的同步报文（seq=Y） |
| 3 | 客户端 | ACK=1，seq=X+1，ack=Y+1 | SYN-SENT → ESTABLISHED | 客户端确认收到服务端报文（ack=Y+1），连接建立完成，双方可传数据 |
为什么需要三次？ 两次握手无法确认客户端的接收能力（比如服务端的ACK报文丢了，服务端以为连接已建立，客户端却不知道），三次握手能确保双方收发能力都正常。
（2）四次挥手：释放连接
四次挥手的目标是“双方确认数据已传输完毕，安全释放连接”，流程如下：
| 步骤 | 发起方 | 报文内容 | 状态变化 | 说明 |
|---|---|---|---|---|
| 1 | 客户端 | FIN=1，seq=u | ESTABLISHED → FIN-WAIT-1 | 客户端请求关闭连接，告知自己的最后序号u（数据已发完） |
| 2 | 服务端 | ACK=1，seq=v，ack=u+1 | ESTABLISHED → CLOSE-WAIT | 服务端确认收到FIN，此时服务端可继续发送未完成的数据 |
| 3 | 服务端 | FIN=1，ACK=1，seq=v+d，ack=u+1 | CLOSE-WAIT → LAST-ACK | 服务端数据发完，请求关闭连接，告知自己的最后序号v+d |
| 4 | 客户端 | ACK=1，seq=u+1，ack=v+d+1 | FIN-WAIT-2 → TIME-WAIT | 客户端确认收到FIN，进入TIME-WAIT状态（等待2MSL后关闭） |
为什么需要四次？ 因为TCP是“全双工”通信，双方都需要单独发送FIN报文表示自己的数据流已结束，因此需要四次交互（服务端的ACK和FIN不能合并，因为可能还有数据要传）。
（3）TIME-WAIT状态与MSL
客户端在第四次挥手后会进入TIME-WAIT状态，持续时间为2MSL（MSL：Maximum Segment Lifetime，最大报文生存时间，一般为30秒或2分钟）。
- 作用1：确保服务端能收到客户端的最后一个ACK（如果ACK丢了，服务端会重发FIN，客户端在TIME-WAIT内可以再次回复）；
- 作用2：避免旧连接的报文干扰新连接（2MSL内，网络中所有旧报文都会过期丢弃）。
七、学习总结
今天的传输层学习内容很多，从“定位→端口→协议→连接管理”层层递进，最大的收获是理解了TCP和UDP的设计取舍：UDP以“简单高效”换“实时性”，TCP以“复杂机制”换“可靠性”。
尤其TCP的三次握手、四次挥手和TIME-WAIT状态，刚开始觉得绕，画了几遍状态图后终于理清了逻辑。后续计划结合实际案例（比如Wireshark抓包）进一步验证这些机制，加深理解~
如果这篇笔记对你有帮助，欢迎点赞收藏！有疑问也可以在评论区交流，一起进步~