传输层是面向通信的最高层，也是用户功能的最底层。
传输层仅存在于主机中，路由器等中间设备只用到下三层（无传输层）。
传输层对上层应用隐藏了底层网络的复杂细节（比如数据怎么路由、网络怎么连接等）。
对应用程序来说，它看到的只是一条虚拟的通信通道，就像两台电脑之间直接连了一根线（但实际上数据可能经过了很多路由器、交换机）。
这条通道的表现取决于传输层协议是TCP还是UDP：像发短信，速度快但不保证一定送达（适合视频通话、在线游戏）。
通俗比喻：
网络层（IP） 负责把包裹（数据）送到正确的城市（主机）。
传输层（TCP/UDP） 负责把包裹送到城市里的具体收件人（应用进程），并决定包裹是“必须签收”（TCP）还是“丢了不管”（UDP）。
1.端口(Port)
| 概念 | 作用 | 示例 |
|---|---|---|
| IP地址 | 定位网络中的主机 | 192.168.1.1 |
| 端口号 | 定位主机内的应用进程 | 80（HTTP）、443（HTTPS） |
| 套接字 | 唯一标识一个通信端点 | (192.168.1.1:80) |
1.1.作用
功能：端口是应用层进程与传输层之间数据交互的桥梁。
端口是SAP。
各层服务访问点SAP对比：
| 层 | 服务访问点 | 示例 |
|---|---|---|
| 数据链路层 | 帧的“类型”字段 | 0x0800（IPv4） |
| 网络层 | IP数据报的“协议”字段 | 6（TCP）、17（UDP） |
| 传输层 | “端口号”字段 | 80（HTTP）、53（DNS） |
| 应用层 | 用户界面 | 浏览器、客户端软件 |
第层的
就是第
层可以访问第
层服务的地方。
软件端口 ≠ 硬件端口
| 软件端口（协议端口） | 硬件端口 |
|---|---|
属于逻辑概念，用于标识应用层进程。 | 物理接口（如路由器、交换机的端口），用于设备间连接。 |
传输层使用软件端口进行进程间通信。 | 与软件端口无关。 |
1.2.端口号
通过“端口号”标识本主机的一个特定进程。
注意：每台主机的端口号是相互独立的。TCP、UDP两种协议的端口号是相互独立的。
🦊例题
端口号长度：
| 类型 | 范围 | 说明 | 常见示例 | |
|---|---|---|---|---|
服务器端 使用的端口号 | 熟知端口号 （背） | 0~1023 | 由IANA分配给TCP/IP重要应用程序 | HTTP:80、FTP:21、SSH:22 |
| 登记端口号 | 1024~49151 | 供未分配熟知端口号的应用程序使用，需在IANA登记以避免冲突。 | MySQL:3306、Redis:6379 | |
客户端 使用的端口号 （短暂端口号） | 49152~65535 | 仅在客户端程序运行时动态分配，通信结束后释放。 | 随机分配（如Chrome连接用49200） | |
1.3.套接字(Socket)
定义：唯一标识网络中的一台主机上的一个应用进程。一个通信端点。格式为Socket = (IP地址 : 端口号)。例如，(192.168.1.1:80) 表示主机192.168.1.1上的Web服务。
通信过程：
源Socket：发送方的IP和端口（如
[ClientIP:49152]）。目的Socket：接收方的IP和端口（如
[ServerIP:80]）。反向通信：服务器回复时，将源/目的端口号互换。
2.功能
2.1.实现端到端的通信
| 数据链路层 | 提供 (链路上)相邻节点之间 的逻辑通信（如交换机到路由器） | 关注“这一段链路怎么传” |
|---|---|---|
| 网络层 | 提供 主机之间 的逻辑通信（如 IP 地址到 IP 地址） | 关注“整个网络怎么找到目标主机” |
| 传输层 | 提供 (运行在不同主机上)进程之间(端之间) 的逻辑通信（如端口到端口） | 关注“主机收到后交给哪个程序” |
| 例如：IP将数据送到主机，传输层确保数据交付给主机内的具体应用（如浏览器、微信） | ||
| 即使网络层不可靠（如丢包、乱序），传输层仍能确保可靠性。 |
逻辑通信：对等层之间的通信好像是沿水平方向传送的，但两个对等层之间并没有一条水平方向的物理连接。
2.2.复用和分用
| 功能 | 复用（发送端） | 分用（接收端） |
|---|---|---|
| 传输层(TCP/UDP) | 多个应用进程（如浏览器、微信）通过同一个传输协议（TCP/UDP）发送数据。 | 接收方传输层根据端口号（如HTTP:80、DNS:53）将数据分发给正确的目标进程。 |
| 网络层(IP) | 不同协议的数据（如TCP、UDP、ICMP）封装成IP数据报统一传输。 | 接收方网络层根据协议号（如TCP=6, UDP=17）将数据交给对应的传输层协议处理。 |
2.3.差错检测
TCP：可靠传输，检测错误后要求重传（如校验和失败）。
UDP：不可靠传输，直接丢弃错误数据报。
网络层局限：IP仅检查首部校验和，不检查数据部分。
2.4.向应用层提供两种服务
| 特性 | 面向连接的可靠服务(TCP) | 无连接的不可靠服务(UDP) |
|---|---|---|
| 连接方式 | 面向连接：需三次握手建立连接，传输结束释放连接 | 无连接：直接发送数据，无需建立连接 |
| 有建立连接的时延 | 没有建立连接的时延 | |
| 有连接状态，需要维护 | 无连接状态，所以能支持更多的活动用户机 | |
面向什么 | 面向字节流 | 面向报文 |
每次传输一个报文段 TCP把应用程序交下来的数据仅视为一连串的无结构的字节流。 | 每次传输一个完整的报文 （UDP 处理的最小单位） | |
支持报文自动拆分、重装，因此可以传输长报文。所以TCP 报文的长度则根据接收方给出的窗口值和当前网络拥塞程度来决定。 | 不支持报文自动拆分、重装，因此只能传输短报文。所以UDP报文的长度由发送应用进程决定。 | |
应用进程传送到TCP缓存的数据块太长 → TCP就把它划分得短一些再传送 应用进程传送到TCP缓存的数据块太短 → TCP也可等到积累足够多的字节后再构成报文段发送出去。 | 报文过长 → IP 层可能分片，降低效率。 报文过短 → IP 数据报首部相对长度过大，同样降低效率。 | |
  |  | |
| 可靠性 | 可靠（确认、重传） | 不可靠（不确认、不重传）→可能丢包 |
| 并不意味着应用对数据的要求是不可靠的，应用层来维护可靠性 | ||
| 几对几 | 仅支持一对一传输(因为通信双方的传输层必须先建立连接) | 支持一对一(封装成单播IP数据报) 一对多传输(封装成广播/多播IP数据报) |
| 全双工通信 | ✔️ 支持 | ✔️ 支持 |
TCP 提供全双工通信，允许通信双方同时发送和接收数据。 TCP 连接的两端都设有发送缓存和接收缓存，用于临时存放双向通信的数据。 发送缓存暂存： ①发送应用程序传送给发送方TCP准备发送的数据 ②TCP 已发送但尚未收到确认的数据 接收缓存暂存： ①按序到达但尚未被接收应用程序读取的数据 ②不按序到达的数据 | UDP 本身是全双工的，但由于无连接和不可靠性，应用层需自行管理数据流的双向传输（如 RTP 协议）。 | |
| 传输效率 | 慢（需确认、重传） | 快 |
| 数据顺序 | 保证数据按序到达 | 不保证顺序 |
| 首部开销 | ||
| 功能 | 可靠传输 | 分用 复用 差错检测（校验和，但出错直接丢弃） |
| 流量控制（滑动窗口） | ||
| 拥塞控制（慢启动、拥塞避免） | 没有拥塞控制 不影响源主机发送速率，实时性，时延小 | |
| 适用场景 | 适用于要求高可靠性的应用 （如网页浏览、文件传输、电子邮件） | 适用于实时性要求高或容忍少量丢失的应用 （如视频流、DNS 查询、实时语音） 常用于一次性传输较少数据的网络应用，节省开销； 常用于多媒体应用，不要求可靠，但要求时延小。 |
| 应用 | HTTP（网页浏览） FTP（文件传输） SMTP（电子邮件） TELNET（远程登录） | DNS（域名解析） SNMP（网络管理） TFTP（简单文件传输） RTP（实时视频/语音） DHCP（动态IP分配） |
3.UDP
3.1.UDP 数据报
 | 当接收方的传输层从IP层收到UDP数据报时，就根据UDP数据报首部中的目的端口，把UDP数据报通过相应的端口，上交最后的终点一一接收方的应用进程。 若接收方UDP发现收到的报文中的目的端口号不正确(不存在对应于端口号的应用进程)，则就丢弃该报文，并由ICMP发送“端口不可达”差错报文给发送方。 |
3.2.UDP检验
3.2.1.概念
定义：数据的发送方给数据的接收方发送一个UDP数据报后，接收方如何去检验出UDP数据报当中是否有比特错误。
计算IP数据报首部检验和的方法和UDP计算检验和的方法基本相同。不同的是：IP数据报检验和只检验首部；UDP的检验和要将首部和数据部分一起检验。
伪首部：在计算检验和时，UDP数据报前临时添加的伪首部。伪首部不向下传送或向上递交，只是为了计算检验和。 字段内容包括源IP地址（4字节）、目的IP地址（4字节）、全0字段（1字节）、协议字段（1字节，UDP为17）、UDP长度（2字节）。
3.2.2.步骤
1️⃣发送方添加伪首部。把全放入检验和字段。伪首部+首部+数据若不是
的整数，用
填充。
2️⃣发送方计算检验和：将伪首部+首部+数据以为一组，进行二进制反码求和(最高位产生的进位需要回卷)，加法运算的最终结果逐位取反，得到
“检验和”。
3️⃣发送方计算完校验和之后，拆除伪首部。将“检验和”写入检验和字段。（而若检验和的计算结果恰好为
，则将检验和字段置为全
。
4️⃣发送方将UDP数据报（检验和字段为“检验和”）发送给接收方。
5️⃣接收方在差错检验之前，需要添加伪首部。
6️⃣差错检验：接收方将伪首部+首部+数据（与之前的区别是检验和字段为“检验和”）以为一组，进行二进制反码求和(最高位产生的进位需要回卷)。如果加法结果为全
，说明没有差错，就接收该UDP数据报。如果加法结果不是全
，说明有差错，就丢弃该UDP数据报或交付给上层并附上错误报告。
7️⃣检验完之后，拆除伪首部。
🦄例题
4.TCP🦊
4.1.TCP报文段/TCP段
4.2.TCP连接管理
TCP连接的端点：套接字（IP地址+端口号）
即使IP或端口重复，通过套接字对（源IP+源端口+目标IP+目标端口）仍能唯一标识一条TCP连接。
TCP连接的建立模式：客户/服务器模式（C/S模式）
客户（Client）：主动发起连接建立的应用进程。
服务器（Server）：被动等待连接建立的应用进程。
TCP协议的三大阶段：1️⃣建立连接(三次握手)2️⃣数据传输3️⃣释放连接(四次挥手)
| 阶段\字段 | SYN | ACK | FIN |  |
|---|---|---|---|---|
| 握手1 | 1 | 0 | 0 | |
| 握手2 | 1 | 1 | 0 | |
| 握手3 | 0 | 1 | 0 | |
| 挥手1 | 0 | 1 | 1 | |
| 挥手2 | 0 | 1 | 0 | |
| 挥手3 | 0 | 1 | 1 | |
| 挥手4 | 0 | 1 | 0 |
4.2.1. 建立连接（三次握手）
4.2.1.1.字段值
TCP连接建立需要解决的三个核心问题：①确认对方的存在②参数协商③资源分配
TCP通过“三次握手”机制解决上述三个问题。
| 阶段\字段 | SYN | ACK | FIN | seq | ack | 特点 |
|---|---|---|---|---|---|---|
| 握手1 | 1 | 0(唯一的0) | 0 | x | ① ② | |
| 正在建立连接 | 第一次握手，尚未收到对方的任何信息，所以确认号无效。 | |||||
| 握手2 | 1 | 1 | 0 | y | x+1 | ① ② |
| 正在建立连接 | ||||||
| 握手3 | 0 | 1 | 0 | x+1 | y+1 | 可以携带数据 |
| 连接已建立 | ||||||
| 双向传输数据 | ||||||
4.2.1.2.状态转换
4.2.1.3.耗时分析
4.2.2. 释放连接（四次挥手）
4.2.2.1.字段值
| 阶段\字段 | SYN | ACK | FIN | seq | ack | 特点 |
|---|---|---|---|---|---|---|
| 挥手1 | 0 | 1 | 1(只有这两个) | x | y | ①一般不携带数据，但是可以 ② |
| 一方发送完了 | ||||||
| 挥手2 | 0 | 1 | 0 | y | x+1 | 可以携带数据 |
| 单向传输数据 | ||||||
| 挥手3 | 0 | 1 | 1(只有这两个) | z | x+1 | ①一般不携带数据，但是可以 ② |
| 另一方发送完了 | ||||||
| 挥手4 | 0 | 1 | 0 | x+1 | z+1 | 不可以携带数据 |
4.2.2.2.状态转换
注意：客户机和服务器都可以先发出挥手。
4.2.2.3.耗时分析
4.3.TCP可靠传输(接收方反馈,端到端,局部)
4.3.1.检验
和UDP检验一样
4.3.2.序号seq
每个字节分配唯一序号，起始序号在建立连接时确定。
作用：标识数据位置，确保有序传输。
示例：客户端初始序号=599，服务器初始序号=199。
4.3.3.确认seq_ack
累积确认规则：接收方返回确认号ack=n，表示序号n-1及之前的所有数据已正确接收。
| 专门确认（非术语） | 携带确认 |
|---|---|
| 只有首部，没有数据 | 若接收方有数据需发送，可携带在ACK段中（减少报文数量）。 属于立即确认。 |
 |  |
| 推迟确认（默认） | 立即确认 |
|---|---|
1️⃣推迟确认就是ACK等一会再发送，如果又收到了一个报文段，那么可以累计确认。推迟时间最多不能超过0.5秒(TCP标准规定) 2️⃣如果自己也有数据要传送给对方，那么不推迟，立即返回ACK段，并“捎带”自己的数据。 3️⃣若连续收到两个长度为MSS的报文段（就是允许范围内的最大报文段），就应该立即返回ACK段。因为重传代价很大，要让这件事尽快尘埃落定。 | 每收到一个TCP报文段，就立即返回一个ACK段 即使收到一个失序报文段，也要立即返回ACK段 |
4.3.4.重传
| 超时重传（默认） | 快重传 |
|---|---|
每发出一个报文段，就设置一个计时器。 若计时器到期还没收到确认，就重传这一报文段，并重置计时器。
| 配套机制：立即确认 作用：让可能出错的报文段尽早重传，而不是非要等到超时再重传。 当发送方连续收到三个确认号相同的冗余ACK（1+3个确认号相同的ACK）时，就立即重传该确认号对应的报文段 |
4.4.TCP流量控制(接收方反馈,端到端,局部)
接收缓冲区的数据交给应用层后要保证有序（比如说应用层的数组有1~17的字节，要交上去18~20的字节可以，20~22的字节不行）
4.5.TCP拥塞控制(控制发送方,整个网络,全局)
发送窗口的上限值=min[rwnd接收窗口(流量控制)，cwnd拥塞窗口(拥塞控制)]
每台主机都有自己的发送窗口、接收窗口、拥塞窗口。
| 现象 | 网络是否拥塞? | 怎么办? | 算法 |
|---|---|---|---|
| 发出的每个报文段，都能顺利地收到ACK确认 | 不拥塞 | 小心翼翼调大cwnd拥塞窗口 | |
| 收到冗余ACK，引发快重传 | 有点拥塞 | 迅速减少发送的数据量 适当缩小cwnd拥塞窗口 | 快重传算法和快恢复算法 |
| 发出的报文段未能按时收到ACK，引发超时重传 | 严重拥塞 | 迅速减少发送的数据量 迅速缩小cwnd拥塞窗口 | 慢开始算法和拥塞避免算法 |
4.5.1.慢开始算法和拥塞避免算法
4.5.2.快重传算法和快恢复算法
框架)
