即使你的工作也许不需要对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的问题。” 于是我将 所有的40ms延迟统统消失了,这个世界完美了。我真是个天才! ACK延迟应该完全关闭吗提一个小插曲,我在HN上看到了这条评论:
他在评论中讨论了ACK是成本很低的,这中做法所导致的问题比它解决的问题要严重的多。 如果你不懂TCP,就搞不定这个问题以前我总认为TCP是相当底层的东西,我永远不需要去了解它。虽然差不多是这样,但是实际生活中,你依然可能遇见和TCP算法相关的Bug,这时候懂一些TCP的知识就至关重要了。(本文也可以引申为,系统调用,操作系统这些都很重要,这个道理适用于很多东西。) ACK延时/TCP_NODELAY很糟糕——它可能对任何写HTTP请求代码的人造成影响。但是你不必成为系统编程方面的天才,懂一点TCP就帮我搞定了这个问题,也让我意识到,出现这个问题我也有责任。我也在用strace,strace万岁! |
|