人人都该懂点儿TCP

TCP是将你要发送的数据打包的算法,他们的HTTP需要用两个小包发送POST请求。

即使你的工作也许不需要对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算法中表现很糟糕,导致请求在这个地方暂停了,直至超时。

我来总结一下这段话:

TCP是将你要发送的数据打包的算法

他们的HTTP需要用两个小包发送POST请求

整个过程就像下面这样:

application:嗨!给你第一个包
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万岁!

来源:51CTO

0赞

好文章,需要你的鼓励

2016

01/31

22:41

分享

点赞