Julia Evans的博客 很受欢迎,网页简单漂亮,行文流畅清晰。最近 lispython 推荐了一篇文章,我翻译了一下,讲的是TCP中的一个坑。也推荐关注一下Julia的博客。
即使你的工作也许不需要对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的原因,多少有些诡异。下面是这篇文章中的内容。
Ruby的 Bet::HTTP 将POST请求分成两个TCP包——一个header,一个body.curl,相比之下,将它们组合成一个倒是更加合适。不过更糟的是,Net:HTTP没有给它打开的TCP socket设置TCP_NODELAY,所以发送第一个包之后,要等到确认才会发送第二个。归根结底,这是Nagle算法导致的。
连接的另一端,HAProxy要选择用何种方式确认这两个包。在1.4.18(正式我们使用的版本),它使用的是TCP延时确认,延时确认在Nagle算法中表现很糟糕,导致请求在这个地方暂停了,直至超时。
我来总结一下这段话:
整个过程就像下面这样:
这段时间内,HAProxy和application都在消极地等待,直到超过200ms。application等待是因为Nagle算法,HAProxy等待是因为延迟ACK。
据我所知,延迟的ACK在所有Linux系统都是默认打开的。所以这不是特例,只要你发送的数据多于一个TCP包,你也会碰上这种事。
读了这篇文章之后,觉得没什么了不起的。但是在我们的神秘40ms挣扎了许久,我想起来这篇文章。
我想:这可能是我的问题吗?可能吗??可能吗?!我给团队发了一封邮件说“可能是我疯了,不过,有可能是TCP的问题。”
于是我将 TCP_NODELAY
打开,然后——BOOM!
所有的40ms延迟统统消失了,这个世界完美了。我真TM是个天才!
提一个小插曲,我在HN上看到了 这条评论 :
真正的问题处在ACK延迟上。200ms延时设定是糟糕的主意,1985年在伯克利搞BSD的那帮人,根本不理解这个问题。ACK延迟是赌应用层一定会在200ms之内收到回复。虽然几乎每次都输,但是ACK延迟依然在用。
他在评论中讨论了ACK是成本很低的,这中做法所导致的问题比它解决的问题要严重的多。
以前我总认为TCP是相当底层的东西,我永远不需要去了解它。虽然差不多是这样,但是实际生活中,你依然可能遇见和TCP算法相关的bug,这时候懂一些TCP的知识就至关重要了。(本文也可以引申为,系统调用,操作系统这些都很重要,这个道理适用于很多东西)
ACK延时/TCP_NODELAY很糟糕——它可能对任何写HTTP 请求代码的人造成影响。但是你不必成为系统编程方面的天才,懂一点TCP就帮我搞定了这个问题,也让我意识到,出现这个问题我也有责任。我也在用strace,strace万岁!