![为什么 TCP MSL 这么长?](https://linux22.com/image/767233/%E4%B8%BA%E4%BB%80%E4%B9%88%20TCP%20MSL%20%E8%BF%99%E4%B9%88%E9%95%BF%EF%BC%9F.png)
1981 年的原始协议规定海平面高度=120秒。
MSL。最大段寿命,即 TCP 段在网络间系统中存在的时间。任意定义为 2 分钟。
Linux 内核将默认的 TIME_WAIT 持续时间设置为 60 秒,这意味着海平面高度=30秒,因为TIME_WAIT=2*MSL。
tcp_fin_timeout - 整数
默认值:60 秒
https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
我的问题是,1)为什么MSL这么长?
2)一个片段在网络中滞留/延迟超过 30 秒真的有可能吗?因为大多数时候 ping 世界上任何服务器都会给你少于 1000 毫秒的 RTT。
答案1
最初的 2 分钟数字很可能是他们认为不可能长的数字。RFC 793(标题为“知道何时保持安静”)明确指出,他们可以更改该时间长度“如果经验表明这样做是可取的”,并将其标记为“工程选择”。
在工程中,当没有明确的最佳解决方案时,您经常会遇到具有多种解决方案的问题。在这些情况下,工程师会根据直觉、经验、熟悉程度、心情甚至随机性选择一个任意解决方案。如果有多个好的选择,但有些选择可能更安全,那么这也可能会影响解决方案。这就是工程选择的含义。(成本不在此列表中,因为如果解决方案的成本较低,那么它显然会更好并且是故意选择的,而不是任意选择的。)一个非常典型的工程选择是,如果参数 X 至少需要为 Y 才能不发生故障,则将 X 设置为 Y+20%。计算机科学家可能会选择 Y+1,两人可能会对对方的选择感到震惊。
您必须意识到,许多早期的互联网协议都是实验性的,不仅存在多种可能的解决方案,而且不清楚哪种方案最好或是否存在最佳方案。在这种情况下,他们选择了一个他们认为“安全”的数字,因为它长得不可能(因此永远不会发生),并且显然打算在未来将该数字调整为更现实的数字。
一个片段有可能卡住那么久吗?他们不知道,但他们无论如何都想确保它能正常工作。怎么会发生这种情况?很久以前的低带宽和高延迟通信路径?300 波特调制解调器?大量缓冲?来自火星的数据包?或者可能是其他一些无法预见的可能性。据推测,这些都没有出现,或者它们的可能性已经被消除,所以我们把数字调低了。