基于wireshark的TCP和UDP报文分析

1、计算机网络基础课程报告基于Wireshark的TCP和UDP报文分析 院系： 班级： 学号： 姓名： 教师： 2012年11月4日目 录一 TCP连接时的三次握手3二 TCP连接释放时的四次握手5三 UDP报文分析7 3.1 UDP报文结构7 3.2 UDP检验和的计算7四 结束语9一、TCP连接时的三次握手 TCP 协议为终端设备提供了面向连接的、可靠的网络服务。TCP在交换数据报文段之前要在发送方和接收方之间建立连接。客户是连接的发起者，服务器是被动打开和客户进行联系。具体的过程如下所述。第一次握手：客户发送 SYN=1，seq=0的TCP报文给服务器 Ps：客户的TCP向服务器发出连接请

2、求报文段，其首部中的同步位SYN = 1。序号 seq = 0，表明报文中未携带数据。报文如下： 源 端口号:56644(56644) 目的端口号:http(80) Stream index: 0 Sequence number: 0 (relative sequence number) Header length: 32 bytes Flags: 0x02 (SYN) 000. . . = Reserved: Not set .0 . . = Nonce: Not set . 0. . = Congestion Window Reduced (CWR): Not set . .0. . =

3、ECN-Echo: Not set . .0. . = Urgent: Not set . .0 . = Acknowledgement: Not set . . 0. = Push: Not set . . .0. = Reset: Not set . . .1. = Syn: Set . . .0 = Fin: Not set Window size: 8192 Checksum: 0x1030 validation disabled Options: (12 bytes)第二次握手：服务器发送SYN=1，ACK=1，seq=0的TCP报文给客户 Ps：服务器的TCP收到客户发来的连接请求

4、报文段后，如同意，则发回确认。服务器在确认报文段中应使SYN = 1，使 ACK = 1。序号 seq = 0，表明报文中未携带数据。报文如下： 源 端口号:http(80) 目的端口号:56644(56644) Stream index: 0 Sequence number: 0 (relative sequence number) Acknowledgement number: 1 (relative ack number) Header length: 32 bytes Flags: 0x12 (SYN, ACK) 000. . . = Reserved: Not set .0 . .

5、= Nonce: Not set . 0. . = Congestion Window Reduced (CWR): Not set . .0. . = ECN-Echo: Not set . .0. . = Urgent: Not set . .1 . = Acknowledgement: Set . . 0. = Push: Not set . . .0. = Reset: Not set . . .1. = Syn: Set . . .0 = Fin: Not set Window size: 5840 Checksum: 0x54f6 validation disabled Optio

6、ns: (12 bytes)第三次握手：客户发送ACK=1的TCP报文给服务器 Ps：客户收到报文段后向服务器给出确认，其 ACK = 1。客户的 TCP 通知上层应用进程，连接已经建立。服务器的 TCP 收到主机客户的确认后，也通知其上层应用进程，TCP 连接已经建立。报文如下： 源 端口号:56644(56644) 目的端口号:http(80) Stream index: 0 Sequence number: 1 (relative sequence number) Acknowledgement number: 1 (relative ack number) Header length:

7、 20 bytes Flags: 0x10 (ACK) 000. . . = Reserved: Not set .0 . . = Nonce: Not set . 0. . = Congestion Window Reduced (CWR): Not set . .0. . = ECN-Echo: Not set . .0. . = Urgent: Not set . .1 . = Acknowledgement: Set . . 0. = Push: Not set . . .0. = Reset: Not set . . .0. = Syn: Not set . . .0 = Fin:

8、Not set Window size: 65928 (scaled) Checksum: 0x1024 validation disabled二、TCP连接释放时的四次握手 数据传输结束后，通信的双方都可释放连接。客户应用进程先向其TCP发出连接释放报文段，并停止再发送数据，主动关闭TCP连接。接下来服务器半关闭连接，最后等待结束后释放连接资源。具体过程如下所述第一次握手：客户发送FIN=1，seq=u的TCP报文给服务器 Ps：客户把TCP连接释放报文段首部的 FIN = 1，等待服务器的确认。报文如下： 源 端口号:56644(56644) 目的端口号:http(80) Stream i

9、ndex: 0 Sequence number: 1 (relative sequence number) Acknowledgement number: 1 (relative ack number) Header length: 20 bytes Flags: 0x11 (FIN, ACK) 000. . . = Reserved: Not set .0 . . = Nonce: Not set . 0. . = Congestion Window Reduced (CWR): Not set . .0. . = ECN-Echo: Not set . .0. . = Urgent: No

10、t set . .1 . = Acknowledgement: Set . . 0. = Push: Not set . . .0. = Reset: Not set . . .0. = Syn: Not set . . .1 = Fin: Set Window size: 65928 (scaled) Checksum: 0x1024 validation disabled第二次握手：服务器发送ACK=1，Acknowledgement number=u+1的TCP报文给客户 Ps：服务器发出确认，确认号Acknowledgement number = u +1。TCP 服务器进程通知高层应

11、用进程。从客户到服务器这个方向的连接就释放了，TCP 连接处于半关闭状态。服务器若发送数据，客户仍要接收。第三次握手：服务器发送FIN=1，ACK=1，seq=w，Acknowledgement number=u+1的TCP报文给客户 Ps：若服务器已经没有要向客户发送的数据，其应用进程就通知 TCP 释放连接。 事实上，第二次握手和第三次握手常常整合体现在同一服务器向客户发送的TCP报文中。报文如下： 源 端口号:http(80) 目的端口号:56644(56644) Stream index: 0 Sequence number: 1 (relative sequence number)

12、Acknowledgement number: 2 (relative ack number) Header length: 20 bytes Flags: 0x11 (FIN, ACK) 000. . . = Reserved: Not set .0 . . = Nonce: Not set . 0. . = Congestion Window Reduced (CWR): Not set . .0. . = ECN-Echo: Not set . .0. . = Urgent: Not set . .1 . = Acknowledgement: Set . . 0. = Push: Not

13、 set . . .0. = Reset: Not set . . .0. = Syn: Not set . . .1 = Fin: Set Window size: 6144 (scaled) Checksum: 0xac93 validation disabled SEQ/ACK analysis第四次握手：客户发送ACK=1，seq=u+1，Acknowledgement number=w+1的TCP报文给服务器 Ps：客户收到连接释放报文段后，必须发出确认。在确认报文段中 ACK = 1，确认号Acknowledgement number =w +1。自己的序号 seq = u + 1

14、。 随之服务器TCP关闭，而客户进入timed wait，等时间到后连接关闭。报文如下： 源 端口号:56644(56644) 目的端口号:http(80) Stream index: 0 Sequence number: 2 (relative sequence number) Acknowledgement number: 2 (relative ack number) Header length: 20 bytes Flags: 0x10 (ACK) 000. . . = Reserved: Not set .0 . . = Nonce: Not set . 0. . = Congest

15、ion Window Reduced (CWR): Not set . .0. . = ECN-Echo: Not set . .0. . = Urgent: Not set . .1 . = Acknowledgement: Set . . 0. = Push: Not set . . .0. = Reset: Not set . . .0. = Syn: Not set . . .0 = Fin: Not set Window size: 65928 (scaled) Checksum: 0x1024 validation disabled SEQ/ACK analysis三、UDP报文分

16、析3.1 UDP报文结构 UDP报头定长为8B。按顺序为： 源端口号：关于端口号有一些规定，服务器端通常用熟知端口号，通常在0-1023之间。而客户端用随机的端口号，其范围在49152到65535之间。 目的端口号 长度：包括报头和数据的长度之和。在8，65535区间。 检验和：提供差错检测功能3.2 UDP检验和的计算 3.2.1 UDP的检验和所需信息1 UDP伪首部：源IP + 目的IP + Byte 0 + Byte 17+ UDP长度，其目的是让UDP两次检查数据是否已经正确到达目的地，只是单纯为了做校验用的。2 UDP首部：该长度不是报文的总长度，而只是UDP（包括UDP头和数据部分）的总长度3 UDP的数据部分 3.2.2 检验和的计算步骤：1 把伪首部添加到UDP上；2 计算初始时将检验和字段添零的；3 把所有位划分为16位（2字节）的字4 把所有16位的字相加，如果遇到进位，则将高于16字节的进位部分的值加到最低位上。5 将所有字相加得到的结果应该为一个16位的数，将该数按位取反则可以得到检验和。 3.2.3举例子分析该例子计算的是一个UDP的检验和由上图可知源IP、目的IP、UD