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协议抓包时校验和后也出现了同样的字段，是否又说明是计算机设置的问题。