当前位置：首页 > news >正文

【计算机网络】5传输层

news 2025/8/2 16:31:56

传输层是面向通信的最高层，也是用户功能的最底层。

传输层仅存在于主机中，路由器等中间设备只用到下三层（无传输层）。

传输层对上层应用隐藏了底层网络的复杂细节（比如数据怎么路由、网络怎么连接等）。

对应用程序来说，它看到的只是一条虚拟的通信通道，就像两台电脑之间直接连了一根线（但实际上数据可能经过了很多路由器、交换机）。
这条通道的表现取决于传输层协议是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。第 $n$ 层的 $SAP$ 就是第 $n+1$ 层可以访问第 $n$ 层服务的地方。

各层服务访问点SAP对比：

层	服务访问点	示例
数据链路层	帧的“类型”字段	0x0800（IPv4）
网络层	IP数据报的“协议”字段	6（TCP）、17（UDP）
传输层	“端口号”字段	80（HTTP）、53（DNS）
应用层	用户界面	浏览器、客户端软件

软件端口 ≠ 硬件端口

软件端口（协议端口）	硬件端口
属于逻辑概念，用于标识应用层进程。	物理接口（如路由器、交换机的端口），用于设备间连接。
传输层使用软件端口进行进程间通信。	与软件端口无关。

1.2.端口号

通过“端口号”标识本主机的一个特定进程。

注意：每台主机的端口号是相互独立的。TCP、UDP两种协议的端口号是相互独立的。

🦊例题

端口号长度： $16bit\left (0\sim 65535 \right ),2^{16}=65536$

类型	范围	说明	常见示例
服务器端使用的端口号	熟知端口号（背）	0~1023	由IANA分配给TCP/IP重要应用程序	HTTP:80、FTP:21、SSH:22
登记端口号	1024~49151	供未分配熟知端口号的应用程序使用，需在IANA登记以避免冲突。	MySQL:3306、Redis:6379
客户端使用的端口号（短暂端口号）	49152~65535	仅在客户端程序运行时动态分配，通信结束后释放。	随机分配（如Chrome连接用49200）

类型

范围

说明

常见示例

服务器端

使用的端口号

熟知端口号

（背）

0~1023

由IANA分配给TCP/IP重要应用程序

HTTP:80、FTP:21、SSH:22

登记端口号

1024~49151

供未分配熟知端口号的应用程序使用，需在IANA登记以避免冲突。

MySQL:3306、Redis:6379

客户端

使用的端口号

（短暂端口号）

49152~65535

仅在客户端程序运行时动态分配，通信结束后释放。

随机分配（如Chrome连接用49200）

互联网应用	TCP/IP 应用层协议	TCP/IP 传输层协议	默认端口号
域名解析	域名系统（DNS）	UDP	53
文件传送（简单）	简单文件传送协议（TFTP）	UDP	69
路由选择	路由信息协议（RIP）	UDP	520
IP 地址分配	动态主机配置协议（DHCP）	UDP	67（服务器） 68（客户端）
网络管理	简单网络管理协议（SNMP）	UDP	161（SNMP） 162（SNMP Trap）
IP 多播	网际组管理协议（IGMP）	UDP	无固定端口（工作在IP层，但依赖UDP）
电子邮件（发送）	简单邮件传送协议（SMTP）	TCP	25（传统） 587（加密）
远程终端接入	远程终端协议（TELNET）	TCP	23
万维网	超文本传送协议（HTTP）	TCP	80
文件传送（完整）	文件传送协议（FTP）	TCP	21（控制） 20（数据）

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 协议）。
传输效率	慢（需确认、重传）	快
数据顺序	保证数据按序到达	不保证顺序
首部开销	$20B$	$8B$
功能	可靠传输	分用复用差错检测（校验和，但出错直接丢弃）
	流量控制（滑动窗口）	分用复用差错检测（校验和，但出错直接丢弃）
	拥塞控制（慢启动、拥塞避免）	没有拥塞控制不影响源主机发送速率，实时性，时延小
适用场景	适用于要求高可靠性的应用（如网页浏览、文件传输、电子邮件）	适用于实时性要求高或容忍少量丢失的应用（如视频流、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数据报前临时添加 $12B$ 的伪首部。伪首部不向下传送或向上递交，只是为了计算检验和。字段内容包括源IP地址（4字节）、目的IP地址（4字节）、全0字段（1字节）、协议字段（1字节，UDP为17）、UDP长度（2字节）。

3.2.2.步骤

1️⃣发送方添加伪首部。把全 $0$ 放入检验和字段。伪首部+首部+数据若不是 $16bit$ 的整数，用 $0$ 填充。

2️⃣发送方计算检验和：将伪首部+首部+数据以 $16bit$ 为一组，进行二进制反码求和(最高位产生的进位需要回卷)，加法运算的最终结果逐位取反，得到 $16bit$ “检验和”。

3️⃣发送方计算完校验和之后，拆除伪首部。将 $16bit$ “检验和”写入检验和字段。（而若检验和的计算结果恰好为 $0$ ，则将检验和字段置为全 $1$ 。

4️⃣发送方将UDP数据报（检验和字段为“检验和”）发送给接收方。

5️⃣接收方在差错检验之前，需要添加伪首部。

6️⃣差错检验：接收方将伪首部+首部+数据（与之前的区别是检验和字段为“检验和”）以 $16bit$ 为一组，进行二进制反码求和(最高位产生的进位需要回卷)。如果加法结果为全 $1$ ，说明没有差错，就接收该UDP数据报。如果加法结果不是全 $1$ ，说明有差错，就丢弃该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		①`SYN=1`不能携带数据 ②`SYN=1`要多消耗一个序号
握手1	正在建立连接	第一次握手，尚未收到对方的任何信息，所以确认号无效。	0	x		①`SYN=1`不能携带数据 ②`SYN=1`要多消耗一个序号
握手2	1	1	0	y	x+1	①`SYN=1`不能携带数据 ②`SYN=1`要多消耗一个序号
握手2	正在建立连接	1	0	y	x+1	①`SYN=1`不能携带数据 ②`SYN=1`要多消耗一个序号
握手3	0	1	0	x+1	y+1	可以携带数据
握手3	连接已建立	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	①一般不携带数据，但是可以 ②`FIN=1`要多消耗一个序号
挥手1	0	1	一方发送完了	x	y	①一般不携带数据，但是可以 ②`FIN=1`要多消耗一个序号
挥手2	0	1	0	y	x+1	可以携带数据
单向传输数据
挥手3	0	1	1(只有这两个)	z	x+1	①一般不携带数据，但是可以 ②`FIN=1`要多消耗一个序号
挥手3	0	1	另一方发送完了	z	x+1	①一般不携带数据，但是可以 ②`FIN=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段中（减少报文数量）。属于立即确认。

专门确认（非术语）

携带确认

只有首部，没有数据

若接收方有数据需发送，可携带在ACK段中（减少报文数量）。

属于立即确认。

推迟确认（默认）

立即确认

1️⃣推迟确认就是ACK等一会再发送，如果又收到了一个报文段，那么可以累计确认。推迟时间最多不能超过0.5秒(TCP标准规定)

2️⃣如果自己也有数据要传送给对方，那么不推迟，立即返回ACK段，并“捎带”自己的数据。

3️⃣若连续收到两个长度为MSS的报文段（就是允许范围内的最大报文段），就应该立即返回ACK段。因为重传代价很大，要让这件事尽快尘埃落定。

每收到一个TCP报文段，就立即返回一个ACK段

即使收到一个失序报文段，也要立即返回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拥塞窗口	慢开始算法和拥塞避免算法