查看队列深度_不为人知的网络编程(十一)：从底层入手，深度分析TCP连接耗时的秘密...

“  本文作者张彦飞，原题“聊聊TCP连接耗时的那些事儿”，本次收录已征得作者同意，转载请联系作者。即时通讯网收录时有少许改动。本文已同步发布于52im社区： http://www.52im.net/thread-3265-1-1.html(

1、引言

对于基于互联网的通信应用(包括IM聊天、推送系统在内)，数据传递时使用TCP协议相对较多。这是因为在TCP/IP协议簇的传输层协议中，TCP协议具备可靠的连接、错误重传、拥塞控制等优点，所以目前在应用场景上比UDP更广泛一些。相信你也一定听闻过TCP也存在一些缺点，能常都是老生常谈的开销要略大。但是各路技术博客里都在单单说开销大、或者开销小，而少见不给出具体的量化分析。不客气的讲，类似论述都是没什么营养的废话。经过日常工作的思考之后，我更想弄明白的是，TCP的开销到底有多大，能否进行量化。一条TCP连接的建立需要耗时延迟多少，是多少毫秒，还是多少微秒？能不能有一个哪怕是粗略的量化估计？当然影响TCP耗时的因素有很多，比如网络丢包等等。我今天只分享我在工作实践中遇到的比较高发的各种情况。写在前面：得益于Linux内核的开源，本文中所提及的底层以及具体的内核级代码例子，都是以Linux系统为例。本文已同步发布于“即时通讯技术圈”公众号，欢迎关注。公众号上的链接是：点此进入。

2、系列文章

本文是系列文章中的第11篇，本系列文章的大纲如下：

• 《不为人知的网络编程(一)：浅析TCP协议中的疑难杂症(上篇)》

• 《不为人知的网络编程(二)：浅析TCP协议中的疑难杂症(下篇)》

• 《不为人知的网络编程(三)：关闭TCP连接时为什么会TIME_WAIT、CLOSE_WAIT》

• 《不为人知的网络编程(四)：深入研究分析TCP的异常关闭》

• 《不为人知的网络编程(五)：UDP的连接性和负载均衡》

• 《不为人知的网络编程(六)：深入地理解UDP协议并用好它》

• 《不为人知的网络编程(七)：如何让不可靠的UDP变的可靠？》

• 《不为人知的网络编程(八)：从数据传输层深度解密HTTP》

• 《不为人知的网络编程(九)：理论联系实际，全方位深入理解DNS》

• 《不为人知的网络编程(十)：深入操作系统，从内核理解网络包的接收过程(Linux篇)》

• 《不为人知的网络编程(十一)：从底层入手，深度分析TCP连接耗时的秘密》(本文)

3、理想情况下的TCP连接耗时分析

要想搞清楚TCP连接的耗时，我们需要详细了解连接的建立过程。在前文《深入操作系统，从内核理解网络包的接收过程(Linux篇)》中我们介绍了数据包在接收端是怎么被接收的：数据包从发送方出来，经过网络到达接收方的网卡；在接收方网卡将数据包DMA到RingBuffer后，内核经过硬中断、软中断等机制来处理(如果发送的是用户数据的话，最后会发送到socket的接收队列中，并唤醒用户进程)。在软中断中，当一个包被内核从RingBuffer中摘下来的时候，在内核中是用struct sk_buff结构体来表示的(参见内核代码include/linux/skbuff.h)。其中的data成员是接收到的数据，在协议栈逐层被处理的时候，通过修改指针指向data的不同位置，来找到每一层协议关心的数据。对于TCP协议包来说，它的Header中有一个重要的字段-flags。如下图：