(点击上方公号,可快速关注)
这不是指要明白 TCP 的所有东西,也不是说要通读 《TCP/IP 详解》。不过懂一点 TCP 知识是很有必要的。理由如下: 当我还在 Recurse Center 的时候,我用 Python 写过 TCP 协议栈(还写过一篇文章:如果你用 Python 写 TCP 协议栈会遇到什么?)。这是一次有趣的学习经历,但是也仅此而已。 一年以后,工作中有人在 Slack 上提到:“嘿,我在向 NSQ 发布消息时,每次要耗费 40 毫秒”。我已经断断续续思考了一个星期,但是没有任何结果。 一点背景知识:NSQ 是一个消息队列,你通过本地的一个 HTTP 请求向其发布消息。发送本地的一个 HTTP 请求确实不应该花费 40 毫秒,有时候会更差。NSQ 守护进程的负载不高,也没有使用过多的内存,也看不到 GC 停顿。这究竟是为什么呢?神呐,救救我吧! 突然我记起我一周以前看过的一篇叫做“性能研究(In search of performance)”的文章——我们如何为每个 POST 请求节省 200ms。在这篇文章中,他们说到为什么每个 POST 请求会花费额外的 200 毫秒。就是这个原因。这是该文章中的关键段落: 延迟确认(ACK) 与 TCP_NODELAY
现在我们解释这个段落说的内容。
接下来,TCP 采用类似如下的步骤进行交互:
这个过程是不是应用程序和 HAProxy 都在消极等待另一方发送信息?这就是那额外的 200ms。应用程序这么做的是因为 Nagle 算法,而 HAProxy 消息等待的原因是延迟确认。 据我所知,延迟确认是所有 Linux 系统的默认行为。所以这不是一个偶然或者异常情况,如果发送 TCP 数据包多一个 1 个,你就会遇到这种情况。 现在,我们成为专家了 读过这篇文章之后我很快就忘了。不过当我被额外的 40 毫秒难住的时候,我又记起来了。 所以我认为——这不可能是我的问题,可能吗?可能吗??然后我发了一封邮件给我团队说:“我想我快要疯了,但是这可能是 TCP 的问题”。 所以我提交了一次修订,将我的应该调整为 TCP_NODELAY,然后问题就“嘣”的一声解决了。 40 毫秒的延迟立马就消失了。所有的事情都解决了,我就是个天才。 我们是否应该完全停止使用延迟确认? 我刚好在 Hacker News 看到 John Nagle (Nagle 算法的创始人)对 @alicemazzy 提到这个问题的评论。
他继续说到,确认本身是很小并且消耗很低的,延迟确认引起的问题可能比它解决的问题还要多。 不懂得 TCP 你就无法解决 TCP 问题 我曾经也认为,TCP 是一个相当底层的问题,我不需要明白。大多数时候你的确不需要明白。但是有的时候,当你在实践中遇到由于 TCP 算法引起的 bug 时,懂点 TCP 知识就变得非常重要了。(正如我们经常在博客中讨论的,许多事情都是这样,比如系统调用和操作系统:) ) 延迟确认及 TCP_NODELAY 的交互非常不好——这对任何语言实现的 HTTP 请求都有影响。你不需要很深入的去了解,成为系统程序专家。但是了解一点 TCP 是如何运作的,对我的工作的确大有裨益。通过对 TCP 的学习,我才意识到这篇博客所描述的问题也许正好是我所熟悉的领域。我也一直在使用 strace,并且会一直使用下去。 【今日微信公号推荐↓】
|
|