【RFC7323 高性能的TCP扩展】(翻译)

https://datatracker.ietf.org/doc/html/rfc7323 高性能的 TCP 扩展

本文档指定了一组 TCP 扩展,以提高具有大带宽乘以延迟的积的路径的性能,并在非常高速的路径上提供可靠的操作。它定义了 TCP Window Scale (WS) 选项和 TCP Timestamps (TS) 选项及其语义。 Window Scale 选项用于支持更大的接收窗口,而 Timestamps 选项可用于至少两种不同的机制,防止包装序列 (PAWS) 和往返时间测量 (RTTM),这里也有描述。

本文档废弃了 RFC 1323 并描述了它的变化。

目录

   1. 简介

     1.1. TCP性能

     1.2. TCP可靠性

     1.3.使用 TCP 选项

     1.4.术语

   2. TCP 窗口缩放选项

     2.1.介绍

     2.2.窗口缩放选项

     2.3.使用窗口缩放选项

     2.4.解决窗口缩回

   3. TCP 时间戳选项

     3.1.介绍

     3.2.时间戳选项

   4. RTTM 机制

     4.1.介绍

     4.2.更新 RTO 值

     4.3.回显哪个时间戳

   5. PAWS - 防止包装序列

     5.1.介绍

     5.2. PAWS 机制

     5.3.基本 PAWS 算法

     5.4.时间戳时钟

     5.5.过时的时间戳

     5.6.头部预测

     5.7. IP分片

     5.8.早期连接的复制品

   6. 结论和致谢

   7. 安全考虑

     7.1.隐私注意事项

   8. IANA 考虑

   9. 参考文献

     9.1.规范参考

     9.2.参考资料

   附录 A 实施建议

   附录 B. 来自早期连接化身的副本

     B.1.状态丢失导致系统崩溃

     B.2.关闭和重新打开连接

   附录 C. 符号总结

   附录 D. 事件处理总结

   附录 E. 时间戳边缘情况

   附录 F. 窗口收回示例

   附录 G. RTO 计算修改

   附录 H. RFC 1323 的变化

1. 简介

TCP 协议 [RFC0793] 旨在在几乎任何传输介质上可靠运行,而不管传输速率、延迟、损坏、重复或段的重新排序。多年来,网络技术的进步导致传输速度越来越快,最快的路径远远超出了 TCP 最初设计的领域。

本文档定义了一组对 TCP 的适度扩展,以扩展其应用领域以匹配不断增长的网络能力。它是对 [RFC1323] 的更新和废弃,而后者又基于并废弃了 [RFC1072] 和 [RFC1185]。

[RFC1323] 和本文档之间的变化在附录 H 中有详细说明。这些变化部分是由于 [RFC1323] 中的勘误表,部分是由于对所涉及的组件如何交互的理解有所提高。

为简洁起见,省略了对本文档中定义的 TCP 选项背后的优点和历史的全面讨论。应查阅 [RFC1323] 以供参考。建议现代 TCP 堆栈实现并使用本文档中描述的扩展。

1.1. TCP性能

当带宽*延迟积很大时,就会出现TCP性能问题。具有此类路径的网络称为“长胖网络”(LFN)。

LFN 路径上的基本 TCP 存在两个基本性能问题:

(1) 窗口大小限制

TCP 报头使用 16 位字段向发送方报告接收窗口大小。因此,可以使用的最大窗口是 2^16 = 64 KiB。对于带宽 * 延迟乘积超过 64 KiB 的 LFN 路径,接收窗口限制了该路径上 TCP 连接的最大吞吐量,即 TCP 可以发送的未确认数据量,以保持管道充满。

为了规避这个问题,本问的第 2 节定义了一个 TCP 选项,“窗口缩放”,以允许大于 2^16 的窗口。该选项定义了一个隐式比例因子,用于乘以在 TCP 头部中找到的窗口大小值以获得真实的窗口大小。

必须注意,大接收窗口的使用增加了过快包装序列号的机会,如下面的第 1.2 节 (1) 所述。

(2) 从损失中恢复

LFN 中的数据包丢失会对吞吐量产生灾难性的影响。

为了概括快速重传/快速恢复机制来处理每个窗口丢弃的多个数据包,需要选择性确认。与 TCP 的正常累积确认不同,选择性确认让发送方全面了解哪些段在接收方排队,哪些尚未到达。

选择性确认及其使用在单独的文档“TCP 选择性确认选项”[RFC2018]、“TCP 选择性确认 (SACK) 选项的扩展”[RFC2883] 和“基于选择性确认的保守丢失恢复算法”中指定(SACK) for TCP”[RFC6675],本文档不再进一步讨论。

1.2. TCP可靠性

一种特别严重的错误可能是由于数据段中 TCP 序列号的意外重用造成的。 TCP 可靠性取决于段生命周期的界限的存在:“最大段生命周期”或 MSL。

序列号的重复可能以两种方式之一发生:

(1) 当前连接上的序列号环绕

TCP 序列号包含 32 位。在大量数据(同一会话中至少 4 GiB)的足够高的传输速率下,32 位序列空间可能会在段在队列中延迟的时间内“包装”(循环)。

(2) 连接的较早化身

假设连接因正确的关闭顺序或由于主机崩溃而终止,并且相同的连接(即使用相同的端口号对)立即重新打开。来自终止连接的延迟段可能落在新化身的当前窗口内并被接受为有效。

如第 5.8 节和附录 B 中所述,通过强制执行 TCP 规范的当前固定 MSL 避免了来自早期化身案例 (2) 的重复。此外,临时端口的随机化也有助于在概率上减少重复的机会从早期的连接。然而,情况 (1),避免在同一连接内重复使用序列号,需要 MSL 的上限取决于传输速率,并且在足够高的速率下,需要专用机制。

循环序列空间问题的一个可能解决方法是增加 TCP 序列号字段的大小。例如,序列号字段(以及确认字段)可以扩展到 64 位。这可以通过更改 TCP 头部或通过附加选项来完成。

第 5 节介绍了一种不同的机制,我们称之为 PAWS,将 TCP 可靠性扩展到远远超出可预见的网络带宽上限的传输速率。 PAWS 使用第 3.2 节中定义的 TCP 时间戳选项来防止来自同一连接的旧副本。

1.3.使用 TCP 选项

本文档中定义的扩展都使用 TCP 选项。

当 [RFC1323] 发布时,有人担心一些有缺陷的 TCP 实现可能会在非 <SYN> 段上的选项第一次出现时崩溃。但是,此类错误可能会导致针对 TCP 的拒绝服务 (DoS) 攻击。研究表明,大多数 TCP 实现将正确处理非 <SYN> 段([Medina04]、[Medina05])上的未知选项。但是在发送的内容上仍然是谨慎的,避免错误的 TCP 实现并不是在 <SYN> 段上协商 TCP 选项的唯一原因。 Window Scale 选项协商 TCP 会话的基本参数。因此,它仅在初始握手期间发送。此外,仅当在初始 <SYN> 段中接收到相应选项时,才会在 <SYN,ACK> 段中发送窗口缩放选项。

Timestamps 选项可以出现在任何数据或 <ACK> 段中,向 20 字节的 TCP 头部添加 10 个字节(最多 12 个字节,包括填充)。在 <SYN> 段上的选项交换表明双方都理解此扩展后,要求此 TCP 选项将在所有非 <SYN> 段上发送。

研究表明,使用 Timestamps 选项在每个 RTT 内获取额外的 RTT 样本对最终重传超时值几乎没有影响 [Allman99]。但是,时间戳选项还有其他用途,例如 Eifel 机制([RFC3522]、[RFC4015])和 PAWS(见第 5 节),它们提高了 TCP 的整体安全性和性能。应针对实际部署中的性能和安全性增益评估此选项使用的额外头部带宽。

附录 A 包含 TCP 头部中选项的推荐布局,以实现合理的数据字段对齐。

最后,我们观察到本文档中定义的大多数机制对于 LFN 和/或超高速网络都很重要。对于低速网络,不使用这些机制可能是一种性能优化。关心低速路径上的最佳性能的 TCP 供应商可能会考虑为低速路径关闭这些扩展,或允许用户或安装管理员禁用它们。

2. TCP 窗口缩放选项

2.1.介绍

窗口缩放扩展将 TCP 窗口的定义扩展到 30 位,然后使用隐式缩放因子在 TCP 头部的 16 位窗口字段中携带这个 30 位值([RFC0793] 中的 SEG.WND)。比例因子的指数包含在 TCP 选项 Window Scale 中。此选项仅在 <SYN> 段(带有 SYN 位的段)中发送,因此当打开连接时,窗口比例在每个方向上都是固定的。

最大接收窗口以及比例因子由最大接收缓冲区空间决定。在典型的现代实现中,这个最大缓冲区空间是默认设置的,但可以在打开 TCP 连接之前由用户程序覆盖。这决定了比例因子,因此窗口缩放不需要新的用户界面。

2.2.窗口缩放选项

三字节的窗口缩放选项可以在 <SYN> 段中由 TCP 发送。它有两个目的:(1) 指示 TCP 准备发送和接收窗口缩放࿰

  • 2
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
RFC 5780是一个关于TCP NAT(网络地址转换)检测的标准文档。在网络通信中,TCP NAT检测用于确定通信中是否存在网络地址转换设备,并帮助通信双方适应这种网络环境。 TCP NAT检测是通过比较通信双方的IP地址和端口号来进行的。在正常情况下,TCP连接的两端具有唯一的IP地址和端口号。然而,当存在网络地址转换时,可能会出现多个TCP连接共享相同的公共IP地址,但具有不同的端口号。 RFC 5780定义了两种方法来进行TCP NAT检测:Endpoint-Independent Mapping和Endpoint-Dependent Mapping。 Endpoint-Independent Mapping意味着两端的TCP连接可以使用任意的IP地址和端口号进行通信。这种情况下,可以通过发送特定的TCP报文并检查返回的报文中的IP地址和端口号来判断是否存在网络地址转换。 Endpoint-Dependent Mapping意味着两端的TCP连接必须使用相同的IP地址和端口号进行通信。这种情况下,可以通过在TCP连接中传输特定的数据并观察返回数据中的IP地址和端口号的变化来判断是否存在网络地址转换。 RFC 5780还提供了一种方法来检测TCP NAT的IP映射的生存时间。此方法通过测试数据包传输过程中IP映射的变化频率来确定网络地址转换设备的性能和对连接的影响。 总之,RFC 5780定义了一套方法和机制来帮助检测TCP连接中的网络地址转换,并提供了对现有TCP连接进行适应的指导。这对于确保网络通信的正常运行和可靠性非常重要。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值