UDP 与 TCP

端口与传输服务

一台主机常常同时运行浏览器、邮件客户端和文件服务。网络层把数据送到主机接口后，操作系统还要把数据交给适当的通信端点。传输协议使用端口号区分这些端点，协议类型与源地址、源端口、目的地址、目的端口共同参与识别一条通信流。端口号是协议字段，程序名称和用户身份需要由操作系统及应用进一步管理。

UDP 提供数据报服务，一次发送对应一个有边界的报文。接收程序应为报文准备足够缓冲区，并按所用接口处理截断情况。UDP 首部包括源端口、目的端口、长度和校验和，固定占八字节；协议本身不提供按序重传、流量控制或拥塞控制。需要这些功能的应用协议必须另行设计，或选择提供相应机制的传输方案。

RFC 768: User Datagram Protocol

J. Postel · 1980 · RFC Editor

打开官方来源

RFC 768 给出了 UDP 的报文格式及长度、校验和定义。校验和用于发现部分传输错误，不能代替消息认证；应用还需要定义字段编码、最大报文长度和超时行为。一次发送调用成功通常只说明本机接受了数据，并不说明远端应用已经读取。

TCP 字节流与序号

TCP 向应用提供有序字节流。应用连续执行两次写入后，接收端可能用一次读取取出全部数据，也可能分成多次读取；TCP 不保留应用写调用的边界。因此，应用协议需要长度字段、分隔符或其他明确的消息边界。读取函数返回一部分数据时，程序通常需要继续累计，直到满足应用协议的完整消息条件。

序号标识字节在流中的位置，确认号通常表示接收方下一步希望获得的字节序号。TCP 首部中的序号字段宽三十二位，运算需要考虑回绕；教学例题先在远离回绕点的小范围内计算。接收端缓冲乱序数据、发送累计确认，发送端根据确认与计时器管理尚未确认的数据。连接异常终止时，应用可能已经收到部分数据，需要按自己的事务语义决定后续行为。

乱序到达时的累计确认

客户端初始序号为一千，完成普通三次握手后，首个数据字节的序号为一千零一。它先发送六百字节，再发送四百字节；第二段先到达，第一段后到达。假定接收方保存乱序数据且没有其他缺失字节，求两个到达时刻的累计确认号。

第一段覆盖序号一千零一至一千六百，第二段覆盖一千六百零一至两千。第二段先到时，接收端仍缺少一千零一开始的数据，因此累计确认号保持一千零一。第一段到达后，两段拼成完整的一千字节前缀，下一期待序号为两千零一。

我们用区间长度核对：$1600-1001+1=600$，$2000-1601+1=400$，总计一千字节。初始 SYN 占用一个序号，纯 ACK 不消耗序号；若后面紧接 FIN，则 FIN 也占用一个序号。选择性确认扩展能够提供额外的乱序接收信息，但不会改变累计确认号所表达的连续前缀位置。

连接建立与关闭

普通主动打开过程中，客户端发送 SYN，服务端返回 SYN 与 ACK，客户端再确认服务端的 SYN。双方借此交换初始序号和必要参数，并确认接收方向上的状态。这个描述假定没有 TCP Fast Open、同时打开或握手丢包等附加情形；分析连接时延时，应明确采用哪一种握手过程。

关闭的两个方向可以分别进行。发送方提交 FIN 表示本方向后续不再发送字节，对方仍可能继续发送已有业务数据；复位 RST 则用于异常终止等情况。操作系统中的连接状态和应用消息状态属于不同层次，应用结束一项任务后可以复用连接，连接关闭也不能单独证明服务端已经完成某项持久化操作。

重传定时器处理长时间未确认的数据，重复确认和选择性确认还支持更早地识别缺失。重传可能导致接收端再次看到相同字节区间，TCP 通过序号处理重复，向应用交付有序内容。超时长度随路径测量变化，固定使用一个很短的超时会把正常排队误判为丢失，增加重复流量。

接收窗口与拥塞窗口

接收窗口表示接收方当前愿意接收的数据范围，保护接收端缓冲区；拥塞窗口表示发送端根据网络状况控制的在途数据量，限制注入网络的流量。设两者分别为 $W_{\mathrm{recv}}$ 与 $W_{\mathrm{cong}}$，有效窗口受其较小值约束。应用供应数据的速度和发送端缓存也可能形成额外限制。

在无丢包、往返时间稳定且发送端持续有数据的简化稳态模型中，若窗口以字节计，持续有效速率的上界近似为

其中 $R$ 为路径允许的比特速率。这个式子没有描述连接启动、具体拥塞控制算法或重传开销；它适合检查窗口大小是否足以维持目标速率，不能直接预测任意网络中的下载速度。

窗口与路径速率的共同限制

路径速率上界为 $80\,\mathrm{Mbit/s}$，往返时间为 $40\,\mathrm{ms}$，接收窗口为 $96000\,\mathrm{B}$，拥塞窗口为 $64000\,\mathrm{B}$。假定窗口保持不变，忽略首部、丢包和启动过程，求稳态速率上界。

有效窗口为 $64000\,\mathrm{B}$，换为比特是 $512000\,\mathrm{bit}$。每个往返周期最多推进这段窗口，所以窗口限制为 $\frac{512000\,\mathrm{bit}}{0.04\,\mathrm{s}}=12.8\,\mathrm{Mbit/s}$，小于路径的八十兆比特每秒，最终上界为 $12.8\,\mathrm{Mbit/s}$。

若要在该模型中达到路径上界，窗口至少应为 $80\times10^6\times0.04/8=400000\,\mathrm{B}$。单独把接收窗口增大到该值仍不足够，因为拥塞窗口也要允许相应数量的在途字节；改变网络负载后，往返时间还可能随排队变化。

报文边界与应用错误处理

给 TCP 字节流定义消息格式时，常用做法是在消息前写固定宽度的长度字段。接收方先读齐该字段、检查长度上限，再循环读取载荷；长度检查应在内存分配前进行。使用文本分隔符时，还要明确转义方式和最大行长，以免载荷中的分隔符被误当成消息结束位置。

UDP 应用则需要考虑丢失、重复和乱序是否影响结果。例如，周期状态更新允许舍弃过时数据，但一项需要确认的文件写入操作通常需要请求编号与明确响应。若应用在超时后重试，服务器可能已经处理了第一次请求，因而协议要说明同一请求重复到达时的行为。端到端业务正确性涉及应用状态，传输层机制只是其中一部分。

RFC 9293: Transmission Control Protocol (TCP)

W. Eddy · 2022 · RFC Editor

打开官方来源

RFC 9293 汇总 TCP 的基本状态机、序号空间、接收处理和可靠交付规则。阅读时可把上述算例中的每段字节区间对应到发送和接收状态变量，再查看连接状态变化；拥塞控制的具体算法还需结合该规范引用的配套文档。

传输协议练习

以下练习分别涉及协议开销、数据边界、序号与流量限制。计算结果应标明字节或比特，协议行为则应说明由哪一层负责；把本机发送成功和对端业务成功分开记录，能避免在超时与重试处理中作出错误假设。

练习标记完成

所属知识

UDP 长度

难度

1/5

一个 UDP 应用发送四十字节数据，使用无选项 IPv4 首部。分别求 UDP 长度字段对应的大小和 IP 数据报总大小，不计以太网开销。

查看解答

UDP 首部为 8 B，加上 40 B 应用数据得到 48 B UDP 报文；再加 20 B 无选项 IPv4 首部，IP 数据报总长为 68 B。

练习标记完成

所属知识

字节流边界

难度

2/5

发送者分别写入十字节和二十字节，接收者第一次只读到七字节。程序是否应立即判定传输错误？给出接收完整消息的设计方法。

查看解答

一次 read 的返回大小由接收缓存、接口和调度决定，可能是部分数据。接收者应按长度字段循环累计，或者按明确分隔符解析；发送者两次 write 的边界不构成 TCP 消息边界。

练习标记完成

所属知识

FIN 序号

难度

2/5

某方向首个数据字节序号为五千零一，发送一百二十字节后立即发送 FIN。数据占用哪些序号，确认 FIN 后的确认号是多少？

查看解答

数据覆盖 5001 至 5120，下一数据序号为 5121。FIN 使用序号 5121，因此确认全部数据及 FIN 的确认号为 5122。

练习标记完成

所属知识

接收窗口

难度

2/5

往返时间为二十毫秒，接收窗口为三万两千字节，拥塞窗口为六万四千字节，路径容量充分。求窗口限制下的速率，并判断增大拥塞窗口是否立刻有效。

查看解答

有效窗口为较小的 32000 B，窗口限制为 $\frac{32000\times8\,\mathrm{bit}}{0.02\,\mathrm{s}}=12.8\,\mathrm{Mbit/s}$。只增加拥塞窗口无法超过接收窗口给出的这个上界。