TCP通信流程解析

来源：互联网发布：java调用webapi接口编辑：程序博客网时间：2024/05/18 01:57

B/S通信简述

整个计算机网络的实现体现为协议的实现，TCP/IP协议是Internet的核心协议，HTTP协议是比TCP更高层次的应用层协议。

HTTP（HyperText Transfer Protocol，超文本传输协议）是互联网上应用最为广泛的一种网络协议。所有的WWW文件都必须遵守这个标准。设计HTTP的初衷是为了提供一种发布和接收HTML页面的方法。

浏览器（Web Browser）负责与服务器建立连接，下载网页（包括资源文件及JS脚本文件）到本地，并最终渲染出页面。JS脚本文件运行在客户端，负责客户端一些行为响应或预处理，例如提交表单前的数据校验、鼠标事件处理等交互。由此可见，浏览器（Browser）一方面充当了C/S通信架构中C角色，另一方面它是HTML/JavaScript的解析渲染引擎（Analyze Render Engine）。

当在浏览器地址栏敲入“http://www.baidu.com/”并按下回车键时，浏览器中将呈现出百度搜索引擎首页。这样一种情景我们再熟悉不过，本文通过wireshark抓取这一过程的数据包，结合TCP协议分析HTTP通信的基本流程。

MTU和MSS

本文用到的抓包工具为wireshark，它的前身是赫赫有名的Ethereal。wireshark以太网帧的封包格式为：

----------------------------------------------------------------------------------------------------

Frame=Ethernet Header +IP Header +TCP Header +TCP Segment Data

----------------------------------------------------------------------------------------------------

（1）Ethernet Header =14 Byte =Dst Physical Address（6 Byte）+ Src Physical Address（6 Byte）+Type（2 Byte），以太网帧头以下称之为数据帧。
（2）IP Header =20 Byte（without options field），数据在IP层称为Datagram，分片称为Fragment。
（3）TCP Header = 20 Byte（without options field），数据在TCP层称为Stream，分段称为Segment（UDP中称为Message）。
（4）54个字节后为TCP数据负载部分（Data Portion），即应用层用户数据。

Ethernet Header以下的IP数据报最大传输单位为MTU（Maximum Transmission Unit，Effect of short board），对于大多数使用以太网的局域网来说，MTU=1500。

TCP数据包每次能够传输的最大数据分段为MSS，为了达到最佳的传输效能，在建立TCP连接时双方将协商MSS值——双方提供的MSS值中的最小值为这次连接的最大MSS值。MSS往往基于MTU计算出来，通常MSS=MTU-sizeof(IP Header)-sizeof(TCP Header)=1500-20-20=1460。

这样，数据经过本地TCP层分段后，交给本地IP层，在本地IP层就不需要分片了。但是在下一跳路由（Next Hop）的邻居路由器上可能发生IP分片！因为路由器的网卡的MTU可能小于需要转发的IP数据报的大小。这时候，在路由器上可能发生两种情况：

（1）如果源发送端设置了这个IP数据包可以分片（May Fragment，DF=0），路由器将IP数据报分片后转发。
（2）如果源发送端设置了这个IP数据报不可以分片（Don’t Fragment，DF=1），路由器将IP数据报丢弃，并发送ICMP分片错误消息给源发送端。

关于MTU的探测，参考《Path MTU discovery》。我们可以通过基于ICMP协议的ping命令来探测从本机出发到目标机器上路由上的MTU，详见下文。

TCP和UDP

在基于传输层（TCP/UDP）的应用开发中，为了最后的程序优化，应避免端到端的任何一个节点上出现IP分片。TCP的MSS协商机制加上序列号确认机制，基本上能够保证数据的可靠传输。

UDP协议在IP协议的基础上，只增加了传输层的端口（Source Port+Destination Port）、UDP数据包长（Length = Header+Data）以及检验和（Checksum）。因此，基于UDP开发应用程序时，数据包需要结合IP分片情况考虑。对于以太局域网，往往取UDP数据包长Length<=MTU-sizeof(IP Header)=1480，故UDP数据负载量小于或等于1472（Length-UDP Header）；对于公网，ipv4最小MTU为576，UDP数据负载量小于或等于548。

“向外”NAT在内网和公网之间提供了一个“不对称”桥的映射。“向外”NAT在默认情况下只允许向外的session穿越NAT：从外向内的的数据包都会被丢弃掉，除非NAT设备事先已经定义了这些从外向内的数据包是已存在的内网session的一部分。对于一方在LAN，一方在WAN的UDP通信，鉴于UDP通信不事先建立虚拟链路，NAT后面的LAN通信方需先发送消息给WAN通信方以洞穿NAT，然后才可以进行双向通信，这即是常提到的“UDP打洞（Hole Punching）”问题。

TCP连接百度过程解析

1．wireshark抓包

下文对百度的完整抓包建立在不使用缓存的基础上。如若主机存有百度站点的cookie和脱机缓存（Offline Cache），则不会再请求地址栏图标favicon.ico；请求/js/bdsug.js?v=1.0.3.0可能回应“HTTP/1.1 304 Not Modified”。可在浏览器打开百度首页后，Ctrl+F5强制刷新，不使用缓存，也可参考《浏览器清除缓存方法》。

以下为访问百度过程，wireshark抓包数据。对于直接通过Ethernet联网的机器，Wireshark Capture Filter为"host www.baidu.com"；对于通过PPP over Ethernet（PPPoE）联网的机器，Wireshark Capture Filter为"pppoes and host www.baidu.com"。以下抓包示例直接通过Ethernet联网访问百度的过程。可点击下面的图片超链接下载pcap文件，使用wireshark软件打开查看。

为方便起见，以下将客户端（浏览器）简称为C，将服务器（百度后台）简称为S。

2．TCP三次握手建立连接

“http://”标识WWW访问协议为HTTP，根据规则，只有底层协议建立连接之后才能进行更高层协议的连接。在浏览器地址栏输入地址后按下回车键的瞬间，C建立与S（机器名为www.baidu.com，DNS解析出来的IP为220.181.6.175）的TCP 80连接（HTTP默认使用TCP 80端口）。

以下为三次握手建立TCP连接的数据包（Packet1-Packet3）。

/****************************************************************************************************

1 192.168.89.125:5672→220.181.6.175:80 TCP(协议) 62(以太网帧长)
amqp > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 SACK_PERM=1

2 220.181.6.175:80→192.168.89.125:5672 TCP 62
http > amqp [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460 SACK_PERM=1

3 192.168.89.125:5672→220.181.6.175:80 TCP 54
amqp > http [ACK] Seq=1 Ack=1 Win=65535 Len=0
****************************************************************************************************/

三次握手建立TCP连接的流程如下：

    C(Browser)                                    S(www.baidu.com)
1. CLOSED                                             LISTEN
2. SYN-SENT    →<SEQ=0><CTL=SYN>              → SYN-RECEIVED
3. ESTABLISHED← <SEQ=0><ACK=1><CTL=SYN,ACK> ← SYN-RECEIVED
4. ESTABLISHED→ <SEQ=1><ACK=1><CTL=ACK>      → ESTABLISHED
3-Way Handshake for Connection Synchronization

2.1 三次握手的socket层执行逻辑

S调用socket的listen函数进入监听状态；C调用connect函数连接S：[SYN]，S调用accept函数接受C的连接并发起与C方向上的连接：[SYN,ACK]。C发送[ACK]完成三次握手，connect函数返回；S收到C发送的[ACK]后，accept函数返回。

2.2 关于Seq和Ack

Seq即Sequence Number，为源端（source）的发送序列号；Ack即Acknowledgment Number，为目的端（destination）的接收确认序列号。在Wireshark Display Filter中，可使用tcp.seq或tcp.ack过滤。

在Packet1中，C:5672向S:80发送SYN握手包，Seq=0(relative sequence number)；在Packet2中，S:80向C:5672发送ACK握手回应包，Ack=1(relativesequence number)，同时发送SYN握手包，Seq=0(relative sequence number)；在Packet3中，C:5672向S:80发送ACK握手回应包，Seq=1，Ack=1。

至此，Seq=1为C的ISN（Initial Sequence Number），后期某一时刻的Seq=ISN+累计发送量(cumulative sent)；Ack=1为C的IAN（Initial Acknowledge Number），后期某一时刻的Ack=IAN+累计接收量(cumulative received)。对于S而言，Seq和Ack情同此理。

参考：《TCP Analyze Sequence Numbers》、《Understanding TCP Sequence and Acknowledgement Numbers》

3．TCP获取网站数据流程

连接建立后，下一步发送（“GET / HTTP/1.1”）请求（Request）HTML页面，这里“/”表示S的默认首页，“GET”为HTTP Request Method；“/”为Request-URI，这里为相对地址；HTTP/1.1表示使用的HTTP协议版本号为1.1。

以下为HTTP GET请求数据包（Packet4）。

/****************************************************************************************************

4 192.168.89.125:5672→220.181.6.175:80 HTTP 417

GET / HTTP/1.1

****************************************************************************************************/

HTTP GET报文长=417-54=363个字节，其中Next sequence number: 364(relative sequence number)表示，若在规定的时间内收到S响应Ack=364，表明该报文发送成功，可以发送下一个报文（Seq=364）；否则重传（TCP Retransmitssion）。序列号确认机制是TCP可靠性传输的保障。

S（http）收到HTTP GET报文（共363个字节），向C（amqp）发送TCP确认报文（Packet5）。

/****************************************************************************************************

5 220.181.6.175:80→ 192.168.89.125:5672 TCP 60

http > amqp [ACK] Seq=1 Ack=364 Win=6432 Len=0

****************************************************************************************************/

这里Seq=1,为S的ISN，意为已发送过SYN。Packet2中，Ack=1为S的IAN。这里的Ack-IAN=364-1=363表示S已经从C接收到363个字节，即HTTP GET报文。同时，Ack=364也是S期待C发送的下一个TCP报文序列号（上面分析的Next sequence number）。

接下来，S向C发送Http Response，根据HTTP协议，先发响应头（Response Header），再发百度首页HTML文件。

Http Response Header报文（Packet6）如下。

/****************************************************************************************************

6 220.181.6.175:80→ 192.168.89.125:5672 TCP 465

[TCP segment of a reassembled PDU]

****************************************************************************************************/

其部分内容如下：

======================================

HTTP/1.1 200 OK

……

Content-Length: 2139

Content-Type: text/html;charset=gb2312

Content-Encoding: gzip

======================================

S响应C的“GET / HTTP/1.1”请求，先发送带[PSH]标识的411个字节的Http Response Header（Packet 6）。

TCP头部[PSH]标识置位，敦促C将缓存的数据推送给应用程序，即先处理Http Response Header，实际上是一种“截流”通知。相应C的socket调用send时在IPPROTO_TCP选项级别设置TCP_NODELAY为TRUE禁用Nagle算法可以“保留发送边界”，以防粘连。

尽管握手协商的MSS为1460，但服务器或者代理平衡服务器，每次发送过来的TCP数据最多只有1420个字节。可以使用ping -f -l size target_name命令向指定目标target_name发送指定字节量的ICMP报文，其中-l size指定发送缓冲区的大小；-f则表示在IP数据报中设置不分片DF（Don’t Fragment），这样便可探测出到目标路径上的MTU。

执行“ping -f -l 1452 www.baidu.com”的结果如下：

220.181.6.18的 Ping统计信息:

数据包:已发送 = 4，已接收 = 4，丢失 = 0 (0%丢失)

执行“ping -f -l 1453 www.baidu.com”的结果如下：

需要拆分数据包但是设置 DF。

220.181.6.18的 Ping统计信息:

数据包:已发送 = 4，已接收 = 0，丢失 = 4 (100%丢失)

从以上ping结果可知，在不分片时，从本机出发到百度的路由上能通过的最大数据量为1452，由此推算出MTU{local,baidu}=sizeof(IP Header)+ sizeof(ICMP Header)+sizeof(ICMP Data Portion)=20+8+1452=1480。

S调用socket的send函数发送2139个字节的Http Response Content（Packet 7、Packet 9），在TCP层将分解为两段（segment）后再发出去。

/****************************************************************************************************

7 220.181.6.175:80→ 192.168.89.125:5672 TCP 1474

[TCP segment of a reassembled PDU]

----------------------------------------------------------------------------------------------------

由“Content-Length: 2139”可知，HTML文件还有2139-(1474-54)=719个字节。但此时，C已经发送了确认报文（Packet8）。

/****************************************************************************************************

8 192.168.89.125:5672→ 220.181.6.175:80 TCP 54

amqp > http [ACK] Seq=364 Ack=1832 Win=65535 Len=0

****************************************************************************************************/

Seq-ISN=364-1=363，表示C已经发出了363个字节，上边已经收到了S的确认。Ack-IAN=1832-1=(465-54)+(1474-54)，表示C至此已经接收到S发来的1831个字节。

接下来，C收到HTML文件剩余的719个字节，报文（Packet9）如下。

/****************************************************************************************************

9 220.181.6.175:80→ 192.168.89.125:5672 HTTP 773

HTTP/1.1 200 OK

****************************************************************************************************/

至此，C收到S发送过来的全部HTTP响应报文，即百度首页HTML内容(text/html)。

Packet6、Packet7和Packet9的ACK都是364，这是因为这三个segment都是针对Packet4的TCP响应。S将百度首页HTML文件（一个完整的HTTP报文）按照MSS分段提交给TCP层。在Wireshark中可以看到Packet9的报文中有以下reassemble信息：

[Reassembled TCP segments (2555 bytes): #6(411),#7(1420),#9(719)]

[Frame: 6, payload: 0-410(411 bytes)]

[Frame: 7, payload: 411-1830(1420 bytes)]

[Frame: 9, payload: 1831-2549(719 bytes)]

C（amqp）接收到百度首页的HTML文件后，开始解析渲染。在解析过程中，发现页面中含有百度的logo资源baidu_logo.gif，并且需要bdsug.js脚本。

{d.write('<script src=http://www.baidu.com/js/bdsug.js?v=1.0.3.0><//script>')}

于是上面那个连接（C:5672）继续向S请求logo图标资源，报文（Packet10）如下。

/****************************************************************************************************

10 192.168.89.125:5672→ 220.181.6.175:80 HTTP 492

GET /img/baidu_logo.gif HTTP/1.1

****************************************************************************************************/

与此同时，C（jms）新建一个连接（TCP 5673）向S请求js脚本文件。报文（Packet11）如下。

/****************************************************************************************************

11 192.168.89.125:5673→ 220.181.6.175:80 TCP 62

jms > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 SACK_PERM=1

****************************************************************************************************/

（Packet12）Packet13、Packet14、Packet16和Packet17为对Packet10的TCP响应（它们的Ack=802），在逻辑上它们是一个完整的TCP报文。其Http Response Content为图片文件baidu_logo.gif。我们在Wireshark中可以看到Packet17的报文中有以下reassemble信息：

[Reassembled TCP segments (1801 bytes): #13(312),#14(1420),#16(28) ,#17(41)]

[Frame: 13, payload: 0-311(312 bytes)]

[Frame: 14, payload: 312-1731(1420 bytes)]

[Frame: 16, payload: 1732-1759(28 bytes)]

[Frame: 17, payload: 1760-1800(41 bytes)]

Packet11-Packet19-Packet20完成新连接的三次握手。然后，C（jms）发送“GET /js/bdsug.js?v=1.0.3.0 HTTP/1.1”报文（Packet21），以获取bdsug.js脚本文件。

/****************************************************************************************************

21 192.168.89.125:5673→ 220.181.6.175:80 HTTP 465

GET /js/bdsug.js?v=1.0.3.0 HTTP/1.1

****************************************************************************************************/

（Packet22）Packet23、Packet24、Packet26和Packet27为对Packet21的TCP响应（它们的Ack=412），在逻辑上它们是一个完整的TCP报文。其Http Response Content为脚本文件bdsug.js。我们在Wireshark中可以看到Packet27的报文中有以下reassemble信息：

[Reassembled TCP segments (3897 bytes): #23(310),#24(1420),#26(1420) ,#27(747)]

[Frame: 23, payload: 0-309(310 bytes)]

[Frame: 24, payload: 310-1729(1420 bytes)]

[Frame: 26, payload: 1730-3149(1420 bytes)]

[Frame: 27, payload: 3150-3896(747 bytes)]

通常，浏览器会自动的搜索网站的根目录，只要它发现了favicon.ico这个文件，就把它下载下来作为网站地址栏图标。于是，C（amqp）还将发起“GET /favicon.ico HTTP/1.1”请求网站地址栏图标，见报文Packet29。

4．TCP四次挥手关闭连接

经Packet28确认收到了完整的japplication/JavaScript文件后，链路1（本地端口5673）使命结束，S关闭该链路，进入四次挥手关闭双向连接。

（Packet30）Packet31和Packet32为对Packet29的TCP响应（它们的Ack=1201）。经Packet33确认收到了完整的image/x-icon文件后，链路2（本地端口5672）使命结束，S关闭该链路，进入四次挥手关闭双向连接。

为什么握手是三次，而挥手是四次呢？这是因为握手时，服务器往往在答应建立连接时，也建立与客户端的连接，即所谓的双向连接。所以，在Packet2中，服务器将ACK和SYN打包发出。挥手，即关闭连接，往往只是表明挥手方不再发送数据（无数据可发），而接收通道依然有效（依然可以接受数据）。当对方也挥手时，则表明对方也无数据可发了，此时双向连接真正关闭。

TCP（Transmission Control Protocol，传输控制协议）是面向连接的协议，也就是说，在收发数据前，必须和对方建立可靠的连接。一个TCP连接必须要经过三次“对话”才能建立起来，其中的过程非常复杂，只简单的描述下这三次对话的简单过程：主机A向主机B发出连接请求数据包：“我想给你发数据，可以吗？”，这是第一次对话；主机B向主机A发送同意连接和要求同步（同步就是两台主机一个在发送，一个在接收，协调工作）的数据包：“可以，你什么时候发？”，这是第二次对话；主机A再发出一个数据包确认主机B的要求同步：“我现在就发，你接着吧！”，这是第三次对话。三次“对话”的目的是使数据包的发送和接收同步，经过三次“对话”之后，主机A才向主机B正式发送数据。

详细点说就是：

TCP三次握手过程
1 主机A通过向主机B 发送一个含有同步序列号的标志位的数据段给主机B ,向主机B 请求建立连接,通过这个数据段,
主机A告诉主机B 两件事:我想要和你通信;你可以用哪个序列号作为起始数据段来回应我.
2 主机B 收到主机A的请求后,用一个带有确认应答(ACK)和同步序列号(SYN)标志位的数据段响应主机A,也告诉主机A两件事:
我已经收到你的请求了,你可以传输数据了;你要用哪佧序列号作为起始数据段来回应我
3 主机A收到这个数据段后,再发送一个确认应答,确认已收到主机B 的数据段:"我已收到回复,我现在要开始传输实际数据了

这样3次握手就完成了,主机A和主机B 就可以传输数据了.
3次握手的特点
没有应用层的数据
SYN这个标志位只有在TCP建产连接时才会被置1
握手完成后SYN标志位被置0

TCP建立连接要进行3次握手,而断开连接要进行4次

1 当主机A完成数据传输后,将控制位FIN置1,提出停止TCP连接的请求
2 主机B收到FIN后对其作出响应,确认这一方向上的TCP连接将关闭,将ACK置1
3 由B 端再提出反方向的关闭请求,将FIN置1
4 主机A对主机B的请求进行确认,将ACK置1,双方向的关闭结束.
由TCP的三次握手和四次断开可以看出,TCP使用面向连接的通信方式,大大提高了数据通信的可靠性,使发送数据端
和接收端在数据正式传输前就有了交互,为数据正式传输打下了可靠的基础
名词解释
ACK TCP报头的控制位之一,对数据进行确认.确认由目的端发出,用它来告诉发送端这个序列号之前的数据段
都收到了.比如,确认号为X,则表示前X-1个数据段都收到了,只有当ACK=1时,确认号才有效,当ACK=0时,确认号无效,这时会要求重传数据,保证数据的完整性.
SYN 同步序列号,TCP建立连接时将这个位置1
FIN 发送端完成发送任务位,当TCP完成数据传输需要断开时,提出断开连接的一方将这位置1

TCP的包头结构：
源端口 16位
目标端口 16位
序列号 32位
回应序号 32位
TCP头长度 4位
reserved 6位
控制代码 6位
窗口大小 16位
偏移量 16位
校验和 16位
选项 32位(可选)
这样我们得出了TCP包头的最小长度，为20字节。

UDP（User Data Protocol，用户数据报协议）

（1） UDP是一个非连接的协议，传输数据之前源端和终端不建立连接，当它想传送时就简单地去抓取来自应用程序的数据，并尽可能快地把它扔到网络上。在发送端，UDP传送数据的速度仅仅是受应用程序生成数据的速度、计算机的能力和传输带宽的限制；在接收端，UDP把每个消息段放在队列中，应用程序每次从队列中读一个消息段。

（2）由于传输数据不建立连接，因此也就不需要维护连接状态，包括收发状态等，因此一台服务机可同时向多个客户机传输相同的消息。

（3） UDP信息包的标题很短，只有8个字节，相对于TCP的20个字节信息包的额外开销很小。

（4）吞吐量不受拥挤控制算法的调节，只受应用软件生成数据的速率、传输带宽、源端和终端主机性能的限制。

（5）UDP使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的链接状态表（这里面有许多参数）。

（6）UDP是面向报文的。发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付给IP层。既不拆分，也不合并，而是保留这些报文的边界，因此，应用程序需要选择合适的报文大小。

我们经常使用“ping”命令来测试两台主机之间TCP/IP通信是否正常，其实“ping”命令的原理就是向对方主机发送UDP数据包，然后对方主机确认收到数据包，如果数据包是否到达的消息及时反馈回来，那么网络就是通的。

UDP的包头结构：
源端口 16位
目的端口 16位
长度 16位
校验和 16位

小结TCP与UDP的区别：

1.基于连接与无连接；
2.对系统资源的要求（TCP较多，UDP少）；
3.UDP程序结构较简单；
4.流模式与数据报模式；

5.TCP保证数据正确性，UDP可能丢包，TCP保证数据顺序，UDP不保证。

TCP协议和UDP协议特性区别总结：

1. TCP协议在传送数据段的时候要给段标号；UDP协议不