人人都该懂点儿TCP
程序员文章站
2022-03-12 10:05:13
...
作者：Julia Evans
原文链接：Why you should understand (a little) about TCP
即使你的工作也许不需要对TCP了如指掌，也不需要去了解具体的TCP/IP实例。你也应该懂一些基本的TCP知识，本文会告诉你为什么。
我以前在Recurse Center工作的时候，曾经用Python写过一个TCP栈（还写了一篇博文用Python实现TCP栈可以学到什么）。这是很有意思的一课，也基本上是我对TCP的所有了解了。
一年之后，工作上遇到了困难。有同事在Slack上问到：“嘿，我向NSQ推消息总是会有40ms的延迟，不知道为什么。”这个问题我思来想去，过了一个周，还是毫无头绪。
这里解释一下： NSQ是一个用来发消息的队列。发送方式是向localhost发出一个HTTP请求，这个动作不可能花费40ms，一定是出了错。但是NSQ不具备很高的CPU优先级，也没有占用大量内存，所以问题不是出在垃圾回收那边。
后来，我想起来一周之前读过的一篇文章——我们是如何在每一个POST请求上省出200ms的（In search of performance - how we shaved 200ms off every POST request）。这篇文章讨论了一开始每一个POST都会多花200ms的原因，多少有些诡异。下面是这篇文章中的内容。
ACK延迟和TCP_NODELAY
我来总结一下这段话：
整个过程就像下面这样：
这段时间内，HAProxy和application都在消极地等待，直到超过200ms。application等待是因为Nagle算法，HAProxy等待是因为延迟ACK。
据我所知，延迟的ACK在所有Linux系统都是默认打开的。所以这不是特例，只要你发送的数据多于一个TCP包，你也会碰上这种事。
终于搞定了问题
读了这篇文章之后，觉得没什么了不起的。但是在我们的神秘40ms挣扎了许久，我想起来这篇文章。
我想：这可能是我的问题吗？可能吗？？可能吗？！我给团队发了一封邮件说“可能是我疯了，不过，有可能是TCP的问题。”
于是我将TCP_NODELAY打开，然后——BOOM！
所有的40ms延迟统统消失了，这个世界完美了。我真是个天才！
ACK延迟应该完全关闭吗
提一个小插曲，我在HN上看到了这条评论：
他在评论中讨论了ACK是成本很低的，这中做法所导致的问题比它解决的问题要严重的多。
如果你不懂TCP，就搞不定这个问题
以前我总认为TCP是相当底层的东西，我永远不需要去了解它。虽然差不多是这样，但是实际生活中，你依然可能遇见和TCP算法相关的Bug，这时候懂一些TCP的知识就至关重要了。（本文也可以引申为，系统调用，操作系统这些都很重要，这个道理适用于很多东西。）
ACK延时/TCP_NODELAY很糟糕——它可能对任何写HTTP请求代码的人造成影响。但是你不必成为系统编程方面的天才，懂一点TCP就帮我搞定了这个问题，也让我意识到，出现这个问题我也有责任。我也在用strace，strace万岁！
译者：赖信涛，关注Python，喜欢编程和电子游戏，个人博客：http://www.kawabangga.com/
原文链接：Why you should understand (a little) about TCP
即使你的工作也许不需要对TCP了如指掌，也不需要去了解具体的TCP/IP实例。你也应该懂一些基本的TCP知识，本文会告诉你为什么。
我以前在Recurse Center工作的时候，曾经用Python写过一个TCP栈（还写了一篇博文用Python实现TCP栈可以学到什么）。这是很有意思的一课，也基本上是我对TCP的所有了解了。
一年之后，工作上遇到了困难。有同事在Slack上问到：“嘿，我向NSQ推消息总是会有40ms的延迟，不知道为什么。”这个问题我思来想去，过了一个周，还是毫无头绪。
这里解释一下： NSQ是一个用来发消息的队列。发送方式是向localhost发出一个HTTP请求，这个动作不可能花费40ms，一定是出了错。但是NSQ不具备很高的CPU优先级，也没有占用大量内存，所以问题不是出在垃圾回收那边。
后来，我想起来一周之前读过的一篇文章——我们是如何在每一个POST请求上省出200ms的（In search of performance - how we shaved 200ms off every POST request）。这篇文章讨论了一开始每一个POST都会多花200ms的原因，多少有些诡异。下面是这篇文章中的内容。
ACK延迟和TCP_NODELAY
引用
Ruby的Bet::HTTP将POST请求分成两个TCP包——一个header，一个body.curl，相比之下，将它们组合成一个倒是更加合适。不过更糟的是，Net:HTTP没有给它打开的TCP socket设置TCP_NODELAY，所以发送第一个包之后，要等到确认才会发送第二个。归根结底，这是Nagle算法导致的。
连接的另一端，HAProxy要选择用何种方式确认这两个包。在1.4.18（正式我们使用的版本），它使用的是TCP延时确认，延时确认在Nagle算法中表现很糟糕，导致请求在这个地方暂停了，直至超时。
连接的另一端，HAProxy要选择用何种方式确认这两个包。在1.4.18（正式我们使用的版本），它使用的是TCP延时确认，延时确认在Nagle算法中表现很糟糕，导致请求在这个地方暂停了，直至超时。
我来总结一下这段话：
- TCP是将你要发送的数据打包的算法
- 他们的HTTP需要用两个小包发送POST请求
整个过程就像下面这样：
引用
application：嗨！给你第一个包
HAProxy：嘘……我们要等第二个包
HAProxy：对了，我们要给他个确认，不过没什么大不了的，等会再说
application：嘘……我们等到第一个包的确认再发第二个，也许网络堵车了，再等一会
HAProxy：烦死了，我们发第一个包的确认吧
application：收到确认，发第二个包！！！！
HAProxy：搞定！
HAProxy：嘘……我们要等第二个包
HAProxy：对了，我们要给他个确认，不过没什么大不了的，等会再说
application：嘘……我们等到第一个包的确认再发第二个，也许网络堵车了，再等一会
HAProxy：烦死了，我们发第一个包的确认吧
application：收到确认，发第二个包！！！！
HAProxy：搞定！
这段时间内，HAProxy和application都在消极地等待，直到超过200ms。application等待是因为Nagle算法，HAProxy等待是因为延迟ACK。
据我所知，延迟的ACK在所有Linux系统都是默认打开的。所以这不是特例，只要你发送的数据多于一个TCP包，你也会碰上这种事。
终于搞定了问题
读了这篇文章之后，觉得没什么了不起的。但是在我们的神秘40ms挣扎了许久，我想起来这篇文章。
我想：这可能是我的问题吗？可能吗？？可能吗？！我给团队发了一封邮件说“可能是我疯了，不过，有可能是TCP的问题。”
于是我将TCP_NODELAY打开，然后——BOOM！
所有的40ms延迟统统消失了，这个世界完美了。我真是个天才！
ACK延迟应该完全关闭吗
提一个小插曲，我在HN上看到了这条评论：
引用
真正的问题处在ACK延迟上。200ms延时设定是糟糕的主意，1985年在伯克利搞BSD的那帮人，根本不理解这个问题。ACK延迟是赌应用层一定会在200ms之内收到回复。虽然几乎每次都输，但是ACK延迟依然在用。
他在评论中讨论了ACK是成本很低的，这中做法所导致的问题比它解决的问题要严重的多。
如果你不懂TCP，就搞不定这个问题
以前我总认为TCP是相当底层的东西，我永远不需要去了解它。虽然差不多是这样，但是实际生活中，你依然可能遇见和TCP算法相关的Bug，这时候懂一些TCP的知识就至关重要了。（本文也可以引申为，系统调用，操作系统这些都很重要，这个道理适用于很多东西。）
ACK延时/TCP_NODELAY很糟糕——它可能对任何写HTTP请求代码的人造成影响。但是你不必成为系统编程方面的天才，懂一点TCP就帮我搞定了这个问题，也让我意识到，出现这个问题我也有责任。我也在用strace，strace万岁！
译者：赖信涛，关注Python，喜欢编程和电子游戏，个人博客：http://www.kawabangga.com/