4. 传输协议 (TRANSPORT PROTOCOLS)
4.1 用户数据报协议 -- UDP (USER DATAGRAM PROTOCOL)
4.1.1 简介 (INTRODUCTION)
用户数据报协议 UDP [UDP:1] 仅提供最小的传输服务 —— 非保证数据报传递 —— 并为应用程序提供对 IP 层数据报服务的直接访问。UDP 被不需要 TCP 服务级别或希望使用 TCP 无法提供的通信服务 (例如组播或广播传递) 的应用程序使用。
UDP 几乎是一个空协议; 它在 IP 之上提供的唯一服务是数据校验和以及按端口号多路复用。因此, 在 UDP 上运行的应用程序必须直接处理面向连接的协议会处理的端到端通信问题 —— 例如, 可靠传递的重传、数据包化和重组、流量控制、拥塞避免等 (当需要这些时)。
4.1.2 协议逐步分析 (PROTOCOL WALK-THROUGH)
UDP 规范中没有已知错误。
4.1.3 具体问题 (SPECIFIC ISSUES)
4.1.3.1 端口 (Ports)
如果数据报到达没有待处理 LISTEN 调用的 UDP 端口, UDP 应该 (SHOULD) 发送 ICMP 端口不可达消息。
4.1.3.2 IP 选项 (IP Options)
UDP 必须 (MUST) 将从 IP 层接收到的任何 IP 选项透明地传递给应用层。
应用程序必须 (MUST) 能够指定要在其 UDP 数据报中发送的 IP 选项, UDP 必须 (MUST) 将这些选项传递给 IP 层。
4.1.3.3 ICMP 消息 (ICMP Messages)
UDP 必须 (MUST) 将从 IP 层接收到的所有 ICMP 错误消息传递给应用层。
4.1.3.4 UDP 校验和 (UDP Checksums)
主机必须 (MUST) 实现生成和验证 UDP 校验和的功能。应用程序可以 (MAY) 选择控制是否生成 UDP 校验和, 但必须 (MUST) 默认启用校验和。
如果收到校验和非零且无效的 UDP 数据报, UDP 必须 (MUST) 静默丢弃该数据报。
实现注意:
UDP 校验和中有一个常见的实现错误。与 TCP 校验和不同, UDP 校验和是可选的; 在 UDP 头部的校验和字段中传输值零表示没有校验和。如果发送方实际计算出 UDP 校验和为零, 它必须将校验和作为全 1 (65535) 传输。接收方不需要特殊处理, 因为在反码算术中零和 65535 是等价的。
4.1.3.5 UDP 多宿主 (UDP Multihoming)
当收到 UDP 数据报时, 其特定目的地址必须 (MUST) 传递给应用层。
应用程序必须 (MUST) 能够指定发送 UDP 数据报时使用的 IP 源地址, 或将其保留为未指定 (在这种情况下, 网络软件将选择适当的源地址)。
4.1.3.6 无效地址 (Invalid Addresses)
收到无效 IP 源地址 (例如广播或组播地址) 的 UDP 数据报必须被 UDP 或 IP 层丢弃。
当主机发送 UDP 数据报时, 源地址必须 (MUST) 是主机的 IP 地址之一。
4.1.4 UDP/应用层接口 (UDP/APPLICATION LAYER INTERFACE)
UDP 的应用接口必须 (MUST) 提供本文档第 3.4 节中描述的 IP/传输接口的完整服务。
应用层程序必须 (MUST) 能够设置 TTL 和 TOS 值以及发送 UDP 数据报时的 IP 选项, 这些值必须透明地传递给 IP 层。
4.1.5 UDP 要求摘要 (UDP REQUIREMENTS SUMMARY)
| 功能 | 章节 | MUST | SHOULD | MAY |
|---|---|---|---|---|
| UDP 发送端口不可达 | 4.1.3.1 | x | ||
| 将接收到的 IP 选项传递给应用层 | 4.1.3.2 | x | ||
| 应用层可指定 IP 选项 | 4.1.3.2 | x | ||
| 将 ICMP 消息传递给应用层 | 4.1.3.3 | x | ||
| 能够生成/检查校验和 | 4.1.3.4 | x | ||
| 静默丢弃错误校验和 | 4.1.3.4 | x | ||
| 发送方可选择不生成校验和 | 4.1.3.4 | x | ||
| 默认启用校验和 | 4.1.3.4 | x | ||
| 将特定目的地址传递给应用程序 | 4.1.3.5 | x | ||
| 应用层可指定本地 IP 地址 | 4.1.3.5 | x | ||
| 无效 IP 源地址被静默丢弃 | 4.1.3.6 | x | ||
| 只发送有效 IP 源地址 | 4.1.3.6 | x |
4.2 传输控制协议 -- TCP (TRANSMISSION CONTROL PROTOCOL)
4.2.1 简介 (INTRODUCTION)
传输控制协议 TCP [TCP:1] 是互联网套件的主要虚拟电路传输协议。TCP 提供可靠的、按序的全双工八位字节 (8 位字节) 流传递。TCP 被那些需要可靠的面向连接传输服务的应用程序使用, 例如邮件 (SMTP)、文件传输 (FTP) 和虚拟终端服务 (Telnet)。
4.2.2 协议逐步分析 (PROTOCOL WALK-THROUGH)
4.2.2.3 窗口大小 (Window Size)
窗口大小必须 (MUST) 被视为无符号数, 否则大窗口大小将显示为负窗口, TCP 将无法工作。建议 (RECOMMENDED) 实现在连接记录中为发送和接收窗口大小保留 32 位字段, 并使用 32 位进行所有窗口计算。
4.2.2.4 紧急指针 (Urgent Pointer)
TCP 必须 (MUST) 支持任意长度的紧急数据序列。
TCP 必须 (MUST) 在每次收到紧急指针且之前没有待处理的紧急数据时, 或每次紧急指针在数据流中前进时, 异步通知应用层。
4.2.2.5 TCP 选项 (TCP Options)
TCP 必须 (MUST) 能够在任何段中接收 TCP 选项。TCP 必须 (MUST) 忽略而不报错任何它不实现的 TCP 选项, 假设该选项有长度字段。TCP 必须 (MUST) 准备好处理非法选项长度 (例如零) 而不崩溃。
4.2.2.6 最大段大小选项 (Maximum Segment Size Option)
TCP 必须 (MUST) 实现发送和接收最大段大小 (Maximum Segment Size, MSS) 选项 [TCP:4]。
TCP 应该 (SHOULD) 在每个 SYN 段中发送 MSS 选项 (当其接收 MSS 与默认值 536 不同时), 并可以 (MAY) 始终发送它。
如果在连接建立时没有收到 MSS 选项, TCP 必须 (MUST) 假设默认发送 MSS 为 536 (576-40) [TCP:4]。
4.2.2.7 TCP 校验和 (TCP Checksum)
与 UDP 校验和不同, TCP 校验和从不是可选的。发送方必须 (MUST) 生成它, 接收方必须 (MUST) 检查它。
4.2.2.9 初始序列号选择 (Initial Sequence Number Selection)
TCP 必须 (MUST) 使用规定的时钟驱动的初始序列号选择。
4.2.2.10 同时打开尝试 (Simultaneous Open Attempts)
TCP 必须 (MUST) 支持同时打开尝试。
4.2.2.13 关闭连接 (Closing a Connection)
当连接被远程站点关闭时, 本地应用程序必须 (MUST) 被告知它是正常关闭还是被中止。
当连接被主动关闭时, 它必须 (MUST) 在 TIME-WAIT 状态中停留 2xMSL (最大段生存期) 的时间。
4.2.3 具体问题 (SPECIFIC ISSUES)
4.2.3.1 重传超时 (Retransmission Timeout)
RFC-793 中建议的计算重传超时的算法现在已知是不充分的。
Jacobson [TCP:7] 关于互联网拥塞和 TCP 重传稳定性的最新工作产生了一种将"慢启动 (slow start)"与"拥塞避免 (congestion avoidance)"相结合的传输算法。TCP 必须 (MUST) 实现此算法。
4.2.3.2 生成确认 (Generating Acknowledgments)
TCP 应该 (SHOULD) 实现延迟确认算法。TCP 不应 (SHOULD NOT) 将确认延迟超过 0.5 秒; 在典型实现中, 延迟应小于 0.2 秒。
4.2.3.3 窗口管理 (Window Management)
TCP 不应 (SHOULD NOT) 收缩窗口, 即不应减少已通告的窗口右边缘。
4.2.3.4 何时发送数据 (When to Send Data)
TCP 应该 (SHOULD) 实现 Nagle 算法 [TCP:9] 以避免发送大量小段。
4.2.3.5 紧急模式 (Urgent Mode)
发送紧急数据的应用程序必须 (MUST) 能够指示紧急数据的结束。
4.2.3.9 重置段 (Reset Segments)
TCP 应该 (SHOULD) 允许接收到的 RST 段包含数据。
4.2.4 TCP/应用层接口 (TCP/APPLICATION LAYER INTERFACE)
4.2.4.1 错误报告 (Error Reporting)
TCP 层必须 (MUST) 向应用层提供一种机制来报告软错误 (例如 ICMP 错误消息)。
4.2.4.2 刷新调用 (Flush Call)
TCP 应该 (SHOULD) 提供一种方法, 允许应用程序清除发送缓冲区中的所有待处理数据。
4.2.4.3 优雅关闭 (Graceful Close)
TCP 应该 (SHOULD) 提供一种方法, 允许应用程序执行优雅关闭, 即在关闭连接之前等待所有待处理数据被确认。
4.2.5 TCP 要求摘要 (TCP REQUIREMENT SUMMARY)
| 功能 | 章节 | MUST | SHOULD | MAY | MUST NOT |
|---|---|---|---|---|---|
| 实现慢启动和拥塞避免 | 4.2.2.15 | x | |||
| 实现 MSS 选项 | 4.2.2.6 | x | |||
| 默认发送 MSS 为 536 (无 MSS 选项时) | 4.2.2.6 | x | |||
| 生成并检查 TCP 校验和 | 4.2.2.7 | x | |||
| 支持同时打开 | 4.2.2.10 | x | |||
| 支持任意长度的紧急数据 | 4.2.2.4 | x | |||
| 实现延迟确认 | 4.2.3.2 | x | |||
| 确认延迟不超过 0.5 秒 | 4.2.3.2 | x | |||
| 实现 Nagle 算法 | 4.2.3.4 | x | |||
| 不收缩窗口 | 4.2.3.3 | x | |||
| TIME-WAIT 持续 2xMSL | 4.2.2.13 | x |