关闭

TCP通信流程解析

981人阅读 评论(0) 收藏 举报
分类:

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 FragmentDF=0),路由器将IP数据报分片后转发。

(2)如果源发送端设置了这个IP数据报不可以分片(Don’t FragmentDF=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:5672220.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_NODELAYTRUE禁用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脚本

<img src="http://www.baidu.com/img/baidu_logo.gif" width="270" height="129" usemap="#mp">

{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协议不
     2. TCP协议可靠;UDP协议不可靠
     3. TCP协议是面向连接;UDP协议采用无连接
     4. TCP协议负载较高,采用虚电路;UDP采用无连接
     5. TCP协议的发送方要确认接收方是否收到数据段(3次握手协议)
     6. TCP协议采用窗口技术和流控制


0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:226237次
    • 积分:3190
    • 等级:
    • 排名:第10747名
    • 原创:73篇
    • 转载:154篇
    • 译文:0篇
    • 评论:34条
    博客专栏
    最新评论