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

【TCP】rfc文档

article 2025/1/20 6:20:55

tcp协议相关rfc有哪些

TCP（传输控制协议）是一个复杂的协议，其设计和实现涉及多个RFC文档。以下是一些与TCP协议密切相关的RFC文档列表，按照时间顺序排列，涵盖了从基础定义到高级特性和优化的各个方面：

RFC 793 - Transmission Control Protocol (1981)
- 最初的TCP标准定义，描述了TCP的基本功能和协议细节。

RFC 813 - Window and Acknowledgment Strategy in TCP (1982)
- 讨论了TCP窗口和确认机制的实现策略，以及使用这些机制时可能遇到的问题和解决方法。

RFC 879 - The TCP Maximum Segment Size Option and Related Topics (1983)
- 讨论了TCP最大分段大小（MSS）选项及其与IP分段大小的关系。

RFC 896 - Congestion Control in IP/TCP Internetworks (1984)
- 探讨了网络拥塞问题以及TCP如何进行拥塞控制。
RFC 2001 - TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms (1996)
- 描述了TCP拥塞控制的四种主要机制：慢启动、拥塞避免、快速重传和快速恢复。
RFC 2581 - TCP Congestion Control (1999)
- 更新了RFC 2001，提供了更详细的拥塞控制算法说明。
RFC 3390 - Increasing TCP’s Initial Window (2002)
- 提出了增加TCP初始窗口大小的方法，以提高短连接的性能。
RFC 5681 - TCP Congestion Control (2009)
- 进一步更新了TCP拥塞控制算法，包括慢启动、拥塞避免、快速重传和快速恢复。

RFC 1323 - TCP Extensions for High Performance (1992)
- 引入了窗口缩放、时间戳选项和选择性确认（SACK）等高性能扩展。
RFC 2018 - TCP Selective Acknowledgment Options (1996)
- 描述了选择性确认（SACK）选项，允许接收方报告哪些数据段已经成功接收，从而减少不必要的重传。
RFC 2883 - An Extension to the Selective Acknowledgement (SACK) Option for TCP (2000)
- 扩展了SACK选项，提高了其效率和可靠性。

RFC 2988 - Computing TCP’s Retransmission Timer (2000)
- 讨论了TCP重传计时器的计算方法，确保数据包在重传前等待合适的时间。

RFC 7413 - TCP Fast Open (2014)
- 引入了TCP Fast Open（TFO）机制，允许在三次握手过程中同时发送数据，减少延迟。

RFC 6247 - Five New TCP Options and Their Use in Scenarios with Multiple Addresses per Endpoint (2011)
- 讨论了TCP协议的扩展性和兼容性问题，特别是支持多个地址的场景。
RFC 7323 - TCP Extensions for High Performance (2014)
- 更新了RFC 1323，进一步优化了TCP的高性能特性。
RFC 8312 - CUBIC for Fast Long-Distance Networks (2018)
- 描述了CUBIC拥塞控制算法，特别适用于长距离网络。

RFC 2525 - Known TCP Implementation Problems (1999)
- 列举了一些已知的TCP实现问题，并提供了相应的解决方案。

RFC 5961 - Improving TCP’s Robustness to Blind In-Window Attacks (2010)
- 提出了增强TCP对盲窗口攻击的鲁棒性的方法。

RFC 792 - Internet Control Message Protocol (1981)
- 定义了ICMP协议，用于在网络中传递控制消息和错误报告。
RFC 1122 - Requirements for Internet Hosts - Communication Layers (1989)
- 规定了互联网主机在通信层的要求，包括TCP/IP协议的实现。
RFC 1123 - Requirements for Internet Hosts - Application and Support (1989)
- 规定了互联网主机在应用层和支持层的要求，包括TCP/IP协议的应用。

这些RFC文档涵盖了TCP协议的各个方面，从基础定义到高级特性和优化，为理解和实现TCP提供了全面的指导。如果你对某个特定方面感兴趣，可以进一步阅读相关RFC文档。

rfc中文文档

https://www.rfc-editor.org/
https://www.ietf.org/rfc/

在TCP协议中，累积确认（Cumulative Acknowledgments）和延迟确认（Delayed Acknowledgments）是两种不同的确认策略，它们各自有着特定的目的和作用。下面详细解释这两种确认方式的区别：

定义：累积确认意味着接收方只确认它已经成功接收到的最高序列号的数据段。换句话说，接收方通过一个单一的确认消息告诉发送方它已连续接收到的所有数据。
工作原理：假设接收方收到了序列号为1到1000的所有数据段，并且这些数据段是连续的，那么接收方将发送一个确认号为1001的ACK，表示它已经接收到所有直到但不包括序列号1001的数据。
优点：
- 减少网络流量：通过一次性确认多个数据段，减少了网络中的确认数量。
- 简化实现：只需要跟踪最高的已接收序列号，简化了接收方的实现。

定义：延迟确认是指接收方不会立即对每个接收到的数据段进行确认，而是等待一段时间后再发送确认消息。这个时间间隔通常不超过500毫秒。
工作原理：如果接收方在一个短暂的时间窗口内（例如200到300毫秒）接收到更多的数据段，它可以将多个数据段的确认合并成一个确认消息来发送。此外，如果在这个时间内有反向的数据需要发送，接收方可以将确认信息附加到该数据段上一起发送，从而避免单独发送确认带来的额外开销。
优点：
- 减少确认消息的数量：通过延迟发送确认，可以减少单独的确认消息，尤其是在双方都有持续的数据交换时。
- 提高效率：结合反向数据传输，可以有效利用网络资源，减少不必要的独立确认消息。
发送延迟确认的条件
rfc813 第五部分5. Improved Acknowledgement Algorithms
这一块是针对delay ack的描述，延迟ack的发送必须满足两个条件。图中横线处

区别：
- 累积确认关注的是确认的内容——确认的是连续接收到的所有数据段的最大序列号。
- 延迟确认关注的是确认的时间——何时发送确认，以优化确认消息的数量和频率。
互补作用：
- 实际应用中，这两种机制通常是互补使用的。接收方使用累积确认来高效地告知发送方哪些数据已经被接收，同时利用延迟确认来进一步优化确认消息的发送时机，从而达到更高的通信效率。