wiresharkTcpUdp抓包分析

Wireshark

抓包分析

CONTENTS 5 TCP协议抓包分析

5.1 TCP协议格式及特点

5.2 实例分析

6 UDP协议的抓包分析

6.1 UDP报文格式及特点

6.2 流媒体播放时传输层报文分析

5 TCP协议抓包分析

5.1 TCP协议的格式及特点

图1 TCP协议报头格式

源端口：数据发起者的端口号；目的端口：数据接收方的端口号；32bit 序列号，标识当前数据段的唯一性；32bit的确认号，接收数据方返回给发送方的通知；TCP头部长度为20字节，若TCP头部的Options选项启用，则会增加首部长度，因此TCP是首部变长的传输层协议；Reserved、Reserved、Nonce、CWR、ECN-Echo：共6bit，保留待用。

URG：1bit紧急指针位，取值1代表这个数据是紧急数据需加速传递，取值0代表这是普通数据；

ACK：1bit确认位，取值1代表这是一个确认的TCP包，取值0则不是确认包；PSH：1bit紧急位，取值1代表要求发送方马上发送该分段，而接收方尽快的将报文交给应用层，不做队列处理。取值0阿迪表这是普通数据；

RST：1bit重置位，当TCP收到一个不属于该主机的任何一个连接的数据，则向对方发一个复位包，此时该位取值为1，若取值为0代表这个数据包是传给自己的；

SYN：1bit请求位，取值1代表这是一个TCP三次握手的建立连接的包，取值为0就代表是其他包；

FIN：1bit完成位，取值1代表这是一个TCP断开连接的包，取值为0就代表是其他包；

Window Size：16bit窗口大小，表示准备收到的每个TCP数据的大小；Checksum：16bit的TCP头部校验，计算TCP头部，从而证明数据的有效性；Urgent Pointer：16bit紧急数据点，当功能bit中的URG取值为1时有效；Options：TCP的头部最小20个字节。如果这里有设置其他参数，会导致头部增大；

Padding：当TCP头部小于20字节时会出现，不定长的空白填充字段，填充内容都是0，但是填充长度一定会是32的倍数；

Data：被TCP封装进去的数据，包含应用层协议头部和用户发出的数据。

5.2 请求网页文件时传输层报文分析

下面结合具体的Wireshark的抓包分析TCP报文的特点。如图2所示。

图2 TCP协议中请求建立连接

首先，注意到该报文的SYN字段为1，因此该报文为建立连接的报文。窗口个数为8192。Option字段中指明了最长字段长度为1460字节。

图3 服务器返回请求建立连接的确认

图3表示出了服务器向用户返回请求建立连接报文的确认字段，其中SYN为1，ACK为1。传送的数据序列号为0。窗口大小仍然为8192。图3即为TCP协

议建立连接过程中的三次握手中的第二次握手。

图4 建立连接的“第三次握手”

上图中，图2、图3、图4代表了TCP协议建立连接时的三次握手。同时，从图4中可以看出窗口长度是一个变量。并且首部长度字段为20，没有option 字段。

图5 TCP关闭连接的过程

图6 TCP关闭连接时的第三次握手

图5，图6分别是TCP关闭连接时的三次握手。图5中上半部分是用户发起结束TCP连接的请求报文，同时用户对收到的服务器数据做出响应，并返回服务器的请求内容。图5中下半部分为服务器的结束连接部分，其余响应与用户相同。图6中用户返回最终确认报文，结束连接。

6 UDP协议的抓包分析

6.1 UDP报文格式及特点

图7中给出了UDP报文格式。可以看出，UDP是一种固定包头格式的协议，其头部共64bit，包含4个等长的部分，分别表示原端口号、目的端口号、UDP 报文段长度以及校验和。

图7 UDP协议格式

利用Wireshark抓取流媒体播放时的UDP报文协议如图8所示。协议头部包含4部分，其中目的端口号为13777，源端口号为：13000，校验和为0x989e，整个协议长度为：43字节，从数据部分的长度为35字节也可以看出头部为8字节，刚好是16*4bits。校验和后面[validation disaled]部分意思不明确。

图8 Wireshark UDP抓包结果

根据UDP首部固定长度的特点，其长度字段最大能表示65536字节，那么一个UDP协议最多能够包含的数据长度即为65528字节。

6.2 流媒体播放时传输层报文分析

图9为使用千千静听播放歌曲时Wireshark所抓数据包的UDP部分。

图9 “千千静听”Wireshark抓包结果

观察图10，不难发现一个奇怪现象，在前面几个UDP协议时本地IP地址是变动的。同时SSDP以及不知名协议在传输层均是使用UDP协议。SSDP协议具体内容如图10。

图10 SSDP协议

根据SSDP协议的具体内容，除了看出其应该是应用层协议以外，没有其他的额外信息。但是值得注意的是，UDP长度字段指示为154字节，出去8字节的首部长度还应该有146字节的数据部分，说明HTP部分就是整个数据字段。

同时还有一个值得注意的现象，如图11所示。

图11 奇怪的现象

图11中奇怪之处已用红色椭圆标出。首先上面的报文是接收报文，下面的报文是发送报文。首先，就数据部分而言，上下报文只有一个字符的差异e和f，即1110和1111。同时UDP协议中长度字段之差为8字节刚好为UDP首部长度。不得不使人猜想，用户又将服务器发送来的数据加上头部打包发回给服务器。但是UDP是无确认机制的服务，如果报文错误，将被直接丢弃不会返回错误的响应。上图中的现象还有待进一步确认。

总结

通过抓包分析，加深了对TCP建立连接以及关闭连接时三次握手的认识。但是TCP传输层协议的具体实现过程，由于抓的包太多没有能够具体分析，因此对课本的理解还有待加强。关于UDP协议，其校验和后的[validation disabled]是否能够说明其快速的传输是建立在舍弃最大正确概率的基础上，这一点仍不是很清楚。但是在TCP协议抓包时校验和后也出现了同样的字段，是否又说明是计算机设置的问题。