@babydragon
2015-11-25T14:32:55.000000Z
字数 1123
阅读 3053
原创
网络
大部分开发者可能不会直接使用TCP协议进行网络开发,但是在分布式系统中,无可避免的需要接触到应用层协议,或是排查网络导致的问题。因此,对于TCP协议,不是每个开发者都需要熟读《TCP/IP详解》[1][2][3],但还是建议能够了解一些TCP协议有关的知识。
有了一些基础知识,可以帮助我们更快的排查网络问题,例如,在《性能探索——我们如何将每个POST请求削减200ms》这篇博客中,作者介绍了他们对POST请求延迟问题的排查,为什么每个POST请求会多消耗200ms,这里摘录一些最终排查到的核心原因:
Ruby的Net::HTTP库,会将HTTP的POST请求拆分成两个TCP数据包:POST请求头一个数据包,请求体一个数据包。而curl命令却相反,它会尽可能的将请求头和请求体塞入一个数据包中。更糟糕的是,Net::HTTP在打开TCP套接字的时候,没有设置TCP_NODELAY选项,因此该套接字会等待第一个数据包的确认包(ack)之后,才会发送第二个数据包。该行为是Nagle算法的结果。
到连接的另一端,HAProxy需要选择如何应答这两个包。在版本1.4.15(我们曾经使用的版本)中,它选择使用TCP延迟应答。延迟应答和Nagle算法相互影响,引起了请求中断,直到服务端触发了延迟应答超时。
这时连接双方(Ruby Net::HTTP和HAProxy)的数据交互是这样的:
双方都在等待对方发送数据包,应用端等待HAProxy发送应答包(Nagle算法),HAProxy在等待应用端后续的数据包(延迟应答)。这就导致了中间的200ms延迟。
找到问题之后,解决就非常方便,在应用端设置TCP_NODELAY参数或者服务端取消延迟应答(TCP_QUICKACK参数)。另一个问题又来了,设置了这两个参数之后,对于应用和服务端有什么影响呢?
应用端套接字设置了TCP_NODELAY参数之后,TCP包将不会使用缓冲区而直接发送。如果应用端会发送大量小数据,可能会遇到缓冲区刷新的瓶颈,同时可能会有大量带宽浪费在了TCP头上。
服务端使用了TCP_QUICKACK,将不会合并发送应答包,同样会增加数据包数量。但是相对来说,应答包的损耗相对于延迟应答来说可能更小。
上面这个示例说明了,虽然大部分情况下,开发者不需要了解TCP协议,但是如果遇到了诸如延迟应答/TCP_NODELAY的问题,了解一些TCP协议相关知识是非常有用的。如今,分布式计算、分布式存储、微服务等架构的兴起,越来越多的系统需要和外部系统交互,其中大部分最终是基于TCP协议,没事了解一些TCP协议,在遇到性能调优、问题诊断时,可能会有意想不到的收获。