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 波特调制解调器？大量缓冲？来自火星的数据包？或者可能是其他一些无法预见的可能性。据推测，这些都没有出现，或者它们的可能性已经被消除，所以我们把数字调低了。