Appearance
TCP 与 UDP 对比
2026 大纲 五（一）1 传输层的功能、五（一）2 传输层寻址与端口、五（一）3 无连接服务与面向连接服务，三条子项全部由本篇承载。
一、分界线只有一句话
网络层已经把分组从一台主机送到了另一台主机，为什么还要再加一层？
因为网络层为主机之间的通信提供服务，传输层为应用进程之间的通信提供服务。
分界就在这一句上。IP 首部里只有源 IP 和目的 IP，没有任何字段能说明"这一份该交给哪个进程"——一台机器上同时开着浏览器、邮件客户端、下载工具，网络层把数据送到网卡就交差了，剩下的"该给谁"它答不上来。
这句话还带出一个推论：路由器只有下三层，传输层只存在于端系统。中间设备根本不需要知道进程的事。
传输层提供的是逻辑通信——这个词教材解释得很到位："好像是这样通信，但事实上并非真的这样通信"。数据实际上是竖着走完整个协议栈的，"两个进程水平直连"只是给应用层看的假象。
两条虚线说明分层的递进：网络层制造的假象是"主机之间直连"，传输层在它之上再造一层"进程之间直连"。
传输层比网络层多做的四件事
| 功能 | 网络层做不到的原因 |
|---|---|
| 复用与分用 | IP 首部里没有能标识进程的字段 |
| 对整个报文做差错检测 | IP 首部的检验和只检验首部、不检查数据部分 |
| 可选的可靠传输（仅 TCP） | IP 只承诺尽最大努力交付，不做确认与重传 |
| 可选的流量控制与拥塞控制（仅 TCP） | IP 无状态，不知道对端缓存有多满、网络有多堵 |
前两条必做（UDP 也做），后两条可选——这就是 TCP 与 UDP 分道扬镳的位置。
传输层还向高层屏蔽了网络核心的细节（拓扑、路由协议）：用 TCP 时这条端到端逻辑信道相当于一条全双工的可靠信道，用 UDP 时仍然是一条不可靠信道。
二、端口为什么取代进程标识符
既然要标识进程，为什么不直接用操作系统的进程号？三条理由：
进程标识符的格式与操作系统绑定，而互联网上什么系统都有，必须用一种与操作系统无关的统一方法。进程是动态创建和撤销的，对方无从知道此刻的编号——服务器重启一次进程号就变了，没办法让全世界的客户端跟着更新。要找的是"功能"而不是"某个进程"，用进程号寻址等于强迫调用方关心实现细节。
三条合起来指向同一个解法：在应用层与传输层的界面上设一个抽象的"门"，用与操作系统无关的编号标志它——这就是协议端口。服务器端口必须固定且人人都知道（否则客户端无从找起），客户端端口只需在本机唯一（为了让回信找得回来，用完即弃），三段划分即由此而来：
16 位共 65536 个：熟知端口 0~1023（IANA 指派）／登记端口 1024~49151（须登记防重复）／短暂端口 49152~65535（客户端动态选、用完由系统收回）。三段铺满、无空隙。
两处措辞要按住。端口号只有本地意义——A 机的 5000 与 B 机的 5000 毫无关联，所以单靠端口号标识不了一条连接。软件端口不是硬件端口——软件端口是同一台机器上两层之间的交互地点，硬件端口是两台设备之间的接口，除了共用一个中文词，两者没有任何关系。
三、复用与分用：两种规则的差异是推论
复用是发送方不同的应用进程都可以使用同一个传输层协议传送数据（各自加上适当的首部）；分用是接收方的传输层剥去报文首部后，把数据正确交付目的应用进程。
但 TCP 和 UDP 的分用依据不一样。 UDP 按目的二元组（目的 IP + 目的端口），谁发来的都交给同一个套接字；TCP 按四元组（源 IP、源端口、目的 IP、目的端口），不同来源就是不同的连接。
追问一层就明白这不是另外规定的一条：UDP 无连接，接收方没有为任何对端保存过状态，手里只有"哪个端口上有进程在等"这一条信息，自然只能按目的端口分；TCP 为每条连接维护的状态是"对某一个特定对端"的，必须靠四元组把不同对端区分开。分用规则的差异，是"有没有连接状态"的直接推论。
同一个 80 端口凭什么同时服务上万个客户（想把四元组分用与二元组分用手动比一遍时展开）
Web 服务器 198.51.100.7 的 80 端口上到达三个 TCP 报文段，源套接字分别是 ① (203.0.113.9, 49230) ② (203.0.113.9, 49231) ③ (203.0.113.20, 49230)。
第 1 步：写出三条的四元组。 TCP 的分用判据只看这四个数，列齐了才能逐位比较，凭"看上去差不多"最容易漏掉只差一位的那个字段。
| 报文段 | 源 IP | 源端口 | 目的 IP | 目的端口 |
|---|---|---|---|---|
| ① | 203.0.113.9 | 49230 | 198.51.100.7 | 80 |
| ② | 203.0.113.9 | 49231 | 198.51.100.7 | 80 |
| ③ | 203.0.113.20 | 49230 | 198.51.100.7 | 80 |
第 2 步：两两比较。 ①②只有源端口不同、①③只有源 IP 不同、②③源 IP 与源端口都不同——三条互不相同。
第 3 步：结论。 交给 3 条独立的 TCP 连接，服务器为它们各维护一份状态。
第 4 步：换成 UDP。 UDP 只看目的二元组 (198.51.100.7, 80)，三条完全相同 → 全部交给同一个套接字、同一个进程，进程要靠 recvfrom() 返回的源地址自己区分是谁发来的。
所以"同一个 80 端口能同时服务上万个客户"是 TCP 四元组分用的结果，不是端口本身的能力。UDP 用同一个端口也能收所有人的数据，只是它不替你区分。
四、连接到底是什么
"面向连接"最容易造成的误解，是以为网络里真开辟了一条专用通路。并没有。
TCP 连接是逻辑连接：三次握手在两端各自的内存里建立起一份状态（初始序号、窗口、缓存、计时器），此后所有报文段照样是一个个独立的 IP 数据报、走各自的路由，中间路由器完全不知道存在这条连接；所谓"释放连接"，释放的也只是这两份状态。
连接建立要解决的三件事，正好对应"状态里存了什么"：① 使每一方能够确知对方的存在；② 允许双方协商一些参数（最大窗口值、是否使用窗口扩大选项和时间戳选项、服务质量等）；③ 对传输实体资源（缓存大小、连接表中的项目等）进行分配。
连接的端点是套接字，这一条要说准：不是主机、不是 IP 地址、不是应用进程、也不是协议端口。socket = (IP 地址 : 端口号)，而一条连接 = 一对套接字。所以同一个 IP 可以有多条连接、同一个端口也可以出现在多条连接中。
| 维度 | 无连接（UDP） | 面向连接（TCP） |
|---|---|---|
| 两端是否保存对端状态 | 不保存 | 保存（连接表、缓存、序号、窗口） |
| 发送前的开销 | 想发就发 | 先握手，付出至少 1 个 RTT |
| 分用依据 | 二元组 | 四元组 |
| 能否可靠 | 协议层不做，可由应用层自己做 | 协议层做（序号 + 确认 + 重传） |
| 能否一对多 | 能（广播、多播） | 不能（连接只有两个端点） |
| 对端异常时能否察觉 | 不能 | 能（超时、RST） |
第一行是根，其余五行都是它的推论。 存了状态就能编序号、能重传、能开窗口、能区分对端，也就必须先建立后释放；而状态是成对的，没法一份状态对一万个人，所以连接必然点对点。
由此还能纠正一处误解：面向连接不等于可靠。 面向连接说的是"两端各存一份对端状态"，可靠说的是"序号 + 确认 + 重传"。TFTP、QUIC 建在 UDP 之上，照样做到了可靠。
顺带纠正另一处：MSS 不是协商出来的。 连接建立时并不存在任何协商，只是一方把 MSS 设定好后通知另一方，两个方向可以不同。
五、全面对比
| 对比项 | TCP | UDP |
|---|---|---|
| 是否面向连接 | 面向连接 | 无连接 |
| 两端是否维护对端状态 | 维护 | 不维护 |
| 可靠性 | 无差错、不丢失、不重复、按序到达 | 尽最大努力交付 |
| 传输方式 | 面向字节流 | 面向报文 |
| 通信模式 | 只能一对一 | 一对一、一对多、多对一、多对多 |
| 首部开销 | 最少 20 字节，最多 60 字节 | 固定 8 字节 |
| 分用依据 | 四元组 | 目的二元组 |
| 流量控制 / 拥塞控制 | 有（rwnd / cwnd） | 都没有 |
| 校验和 | 强制 | 可选（不算时填 0） |
| 端口不存在时的响应 | 自己回 RST 报文段 | 借 ICMP 回"端口不可达" |
表里"面向字节流 vs 面向报文"这一行值得单独说，它是"有没有序号"的推论：TCP 每个字节都编号，怎么切都能拼回，所以它可以任意合并或拆分应用交下来的数据块——但接收方收到的字节流必须与发送方发出的完全一样，消息边界要由应用层自己维护；UDP 没有序号，拆了拼不回，只能不拆。
六、适用场景与端口号
选协议的三条判据：重传是否还有意义 / 建连接的开销是否超过数据本身 / 是否需要广播多播，任一成立即倾向 UDP。
| 走 TCP | 端口 | 走 UDP | 端口 |
|---|---|---|---|
| FTP 数据 / 控制 | 20 / 21 | DNS（一问一答、报文短） | 53 |
| SSH | 22 | DHCP 服务器 / 客户端（客户端尚无 IP，必须广播） | 67 / 68 |
| TELNET | 23 | TFTP（可靠性交给应用层自己做） | 69 |
| SMTP | 25 | SNMP / SNMP trap（报文简短，丢了重查） | 161 / 162 |
| HTTP / HTTPS | 80 / 443 | RIP（周期性广播，下一周期自然更新） | 520 |
| POP3 / IMAP | 110 / 143 | 实时音视频 RTP（重传回来的帧已过期） | — |
DNS 是两边都用的典型，别记成"只用 UDP"：普通短查询走 UDP，一旦变成"大块数据且必须完整"——响应超 512 字节（截断标志置位）、或主辅域名服务器之间做区域传送——就切 TCP。
本节小结
- 分界线只有一句：网络层为主机之间的通信提供服务，传输层为应用进程之间的通信提供服务。 传输层在网络层"主机直连"的假象上再造一层"进程直连"的假象；它比网络层多做四件事，前两件（复用分用、对整个报文检错）必做，后两件（可靠传输、流量与拥塞控制）可选，TCP 与 UDP 就在这里分道扬镳。
- 端口是与操作系统无关的抽象终点，16 位、只有本地意义，分熟知 0~1023 / 登记 1024~49151 / 短暂 49152~65535 三段。连接的端点不是主机、IP、进程或端口，而是套接字（IP : 端口），连接 = 套接字对。
- "两端有没有各存一份对端状态"是无连接与面向连接的唯一分界：分用用二元组还是四元组、能不能重传、能不能一对多、能不能察觉对端异常，全是它的推论。面向连接不等于可靠，无连接也不等于做不出可靠。
考点速记
本篇在真题里被考过的形式只有一种：给三条关于 UDP 的叙述，挑出对的。
UDP 的哪几条叙述正确（cn-2014-39）。三个候选是"提供无连接服务""提供复用/分用服务""通过差错校验，保障可靠数据传输"，答 B：仅 Ⅰ、Ⅱ。
Ⅰ 和 Ⅱ 都对，而且 Ⅱ 正是第一节那张表里的"必做项"——复用与分用是传输层的立身之本，UDP 再简单也一定要做，否则数据交不到进程手里。
要判掉的是 Ⅲ，而它错在后半句。 前半句"通过差错校验"是对的，UDP 确实有校验和；但校验和只能"检错"，不能"纠错"——检出错误后 UDP 的动作是直接丢弃，既不通知发送方，也不要求重传。检错 ≠ 可靠。 可靠传输要的是"序号 + 确认 + 重传"这一整套，UDP 一样都没有。
这道题的价值在于它卡的正是本篇第一节那条分界：传输层的四件事里，前两件（复用分用、对整个报文检错）UDP 也做，后两件（可靠传输、流量与拥塞控制）它不做。把 Ⅲ 判对的人，多半是把"有校验和"直接等同于"可靠"了。
本篇练习区里还会出现一道 cn-2018-39，问 UDP 实现分用时依据的首部字段（答"目的端口号"），它落在 UDP 首部的字段职责上，讲在 TCP 协议基础与 UDP 协议。
其余内容——逻辑通信、端口三段划分、套接字、面向连接与可靠的区分——在真题里不单独成题，但它们是后面几篇所有计算题的地基：不知道"连接的端点是套接字对"，就理解不了为什么四元组能区分连接；不知道"面向字节流是有序号的推论"，序号计算题就只能靠背公式。
易错：检错不等于可靠。 UDP 有校验和，但检出错误就丢弃，不通知也不重传。
易错：复用与分用是传输层的必做项，UDP 也做；可靠传输与流量拥塞控制才是可选项。
易错：面向连接不等于可靠。 面向连接说的是"两端各存状态"，可靠说的是"序号+确认+重传"。
易错：UDP 按目的二元组分用，TCP 按四元组分用。 这是"有没有连接状态"的推论，不是另定的规则。
易错：连接的端点是套接字（IP : 端口），不是主机、不是 IP、不是进程、也不是端口。
易错：MSS 不是协商出来的，是一方设定好通知另一方，两个方向可以不同。
易错：端口号只有本地意义，两台机器上相同的端口号毫无关联。
易错：DNS 不是只用 UDP。 响应超 512 字节或做区域传送时改用 TCP。
教材出处
- 谢希仁《计算机网络》（第 8 版）p212（5.1.1 进程之间的通信）："从这里可以看出网络层和运输层有明显的区别。网络层为主机之间的通信提供服务，而运输层则在网络层的基础上，为应用进程之间的通信提供服务。" 本篇第一节的分界线即出自此句。同页还给出"逻辑通信"的定义——"'逻辑通信'的意思是'好像是这样通信，但事实上并非真的这样通信'"；以及"运输层还要对收到的报文进行差错检测……在网络层，IP 数据报首部中的检验和字段，只检验首部是否出现差错而不检查数据部分"。
- 同书 p212：复用与分用的定义——"这里的'复用'是指在发送方不同的应用进程都可以使用同一个运输层协议传送数据（当然需要加上适当的首部），而'分用'是指接收方的运输层在剥去报文的首部后能够把这些数据正确交付目的应用进程"。
- 同书 p212–p213：传输层"向高层用户屏蔽了下面网络核心的细节（如网络拓扑、所采用的路由选择协议等）……当运输层采用面向连接的 TCP 协议时……这种逻辑通信信道就相当于一条全双工的可靠信道。但当运输层采用无连接的 UDP 协议时，这种逻辑通信信道仍然是一条不可靠信道"。
- 同书 p214（5.1.3 运输层的端口）：否掉进程标识符的三条理由（操作系统种类多、进程创建与撤销是动态的、需要按功能而非按进程识别终点），以及"这种在协议栈层间的抽象的协议端口是软件端口，和路由器或交换机上的硬件端口是完全不同的概念"、"端口号只具有本地意义……在互联网不同计算机中，相同的端口号是没有关联的"。收发室的比喻亦出自此页。
- 同书 p215：端口号三类划分的原文——熟知端口号 0~1023、登记端口号 1024~49151、客户端使用的短暂端口号 49152~65535；表 5-2 给出 FTP 21、TELNET 23、SMTP 25、DNS 53、TFTP 69、HTTP 80、SNMP 161、SNMP(trap) 162、HTTPS 443。
- 同书 p220（5.3.2 TCP 的连接）："TCP 连接的端点是什么呢？不是主机，不是主机的 IP 地址，不是应用进程，也不是运输层的协议端口。TCP 连接的端点叫作套接字（socket）……端口号拼接到 IP 地址即构成了套接字"，以及"同一个 IP 地址可以有多个不同的 TCP 连接，而同一个端口号也可以出现在多个不同的 TCP 连接中"。
- 同书 p219（5.3.1 TCP 最主要的特点）：面向字节流的定义与那条关键推论——"TCP 不保证接收方应用程序所收到的数据块和发送方应用程序所发出的数据块具有对应大小的关系……但接收方应用程序收到的字节流必须和发送方应用程序发出的字节流完全一样"。
- 同书 p228 脚注："流行的一种说法，在 TCP 连接建立阶段'双方协商 MSS 值'，但这是错误的，因为这里并不存在任何的协商，而只是一方把 MSS 值设定好以后再通知另一方而已。"
- 同书 p247（5.9 TCP 的运输连接管理）：连接建立要解决的三个问题——"要使每一方能够确知对方的存在"、"要允许双方协商一些参数"、"能够对运输实体资源（如缓存大小、连接表中的项目等）进行分配"。
- 同书 p216（5.2.1 UDP 概述）：UDP 检错后的动作——"UDP 无须建立连接……UDP 是面向报文的"，以及校验和检出差错后的处理是丢弃而不是重传，这一点在 p218 首部格式一节给出。
相关知识
体系结构与参考模型｜UDP 协议｜TCP 协议基础｜网络层功能