实验四 TCP/UDP协议分析

一、TCP连接建立过程分析

二、TCP关闭连接过程分析

三、6号报文分析

四、A方TCP报文序列号分析

五、计算

六、UDP协议分析

一、TCP连接建立过程分析

图 1 第一次握手

第一次握手：客户端将标志位 SYN 置为 1 ，随机产生一个值SEQ = X = 0，并将该数据包发送给服务器，等待服务器确认；

图 2 第二次握手

第二次握手：服务器收到数据包后由标志位SYN = 1，直到客户端请求建立连接，服务器将标志位 SYN 和 ACK 都置为 1 ，ACK = X + 1 = 1，随机产生一个值SEQ = Y = 0，并将该数据包发送给客户端以确认连接请求；

图 3第三次握手

第三次握手：客户端收到确认后，检查 ACK 是否为X + 1= 1，如果正确则将标志位 ACK 置为 1 ，SEQ = 1,ACK = Y + 1 = 1，并将该数据包发送给服务器，服务器检查 ACK 是否为1 ，如果正确则连接建立成功,后续开始传输数据。

二、TCP关闭连接过程分析

图 4第一次挥手

第一次挥手：主动关闭方发送一个 FIN = 1 ，用来关闭主动方到被动关闭方的数据传送，也就是主动关闭方告诉被动关闭方：不会再给对方发送数据了；

图 5第二次挥手

第二次挥手：被动关闭方收到 FIN = 1包后，发送一个 ACK = 1 给对方，确认序号为:收到报文序号Seq +收到报文所携带数据长度len+ 1=1 。上一个报文可能“捎带”了主动关闭方发送的最后一块数据,其长度用字段len来表示。

图 6第三次挥手

第三次挥手：被动关闭方发送一个 FIN = 1 ，同时ACK=1，用来关闭被动关闭方到主动关闭方的数据传送，也就是告诉主动关闭方，我的数据也发送完了，不会再给你发送数据了；

图 7第四次挥手

第四次挥手：主动关闭方收到 FIN 后，发送一个 ACK 给被动关闭方，确认序号为：收到报文的序号Seq + 收到报文所携带数据长度len+ 1 ，至此，完成四次挥手，双向连接关闭。

`三、6``号报文分析`

图 8 6号报文

Source Port: 2000 //请求端端口：2000

Destination Port: 21098 //服务器端端口：21098

[Stream index: 0] //tcp流序号：0（wireshark中对源于同一tcp流的包的标记）

[TCP Segment Len: 0] //tcp报文长度：0

Sequence Number: 1(relative sequence number) //报文序列号：1（相对序号）

Sequence Number (raw): 1959254470 //报文序列号：1959254470（绝对序号）

[Next Sequence Number: 1(relative sequence number)] //下一序列号：1

Acknowledgment Number: 1717(relative ack number) //确认号：1717（相对序号）

Acknowledgment number (raw): 1749145722 //确认号：1749145722（绝对序号）

0101 … = Header Length: 20 bytes (5) //报文头部长度（数据偏移）：20bytes

Flags : 0x010 (ACK) //报文类型：ACK

000… = Reserved: Not set //保留字段

…0… = Nonce: Not set//随机数：无效（随机数(Nonce)是任意的或非重复的值，它包括在经过一个协议的数据交换中，通常为保证活跃度以及避免受重复攻击）

…0… = Congestion window Reduced (CWR): Not set

//拥塞窗口减少戳：无标记（TCP拥塞控制）

…0… =ECN-Echo: Not set //显式拥塞戳:无效（ECN-Echo与TCP拥塞控制）

…0… = Urgent: Not set //紧急指针戳：无效

…1… = Acknowledgment: Set //确认号戳：有效

…0… = Push: Not set //推送戳:无效

…0… = Reset: Not set //复位戳：无效

…0. = Syn: Not set //同步戳:无效

…0 = Fin: Not set //结束戳:无效

[TCP Flags …… A……]

window: 256 //窗口大小：256（TCP接收者缓冲的字节大小）

[ Calculated window size: 65536] //计算出的窗口大小（窗口大小单位*窗口大小）

[window size scaling factor: 256] //窗口大小换算系数

Checksum: Oxd6a1 [unverified] //校验和

[Checksum Status : Unverified] //校验状态

Urgent Pointer: 0（如果设置了URG位，这个域将被检查作为额外的指令，告诉CPU从数据包的哪里开始读取数据）

[SEQ/ACK analysis]//序列号及确认号的分析结果，当且仅当数据中含有ACK时，才有此项！

[This is an ACK to the segment in frame: 5]//这是对5号报文的回应

[ The RTT to ACK the segment was: 0.00050900e seconds]//往返时延

[iRTT: 8.000343000 seconds]//互联网往返时延

[Timestamps]//时间戳

[Time since first frame in this TCP stream: 0.012839000 seconds]// 从此TCP流中的第一帧开始的时间：0.012839000秒

[ Time since previous frame in this TCP stream: 0.000509000 seconds]// 从此TCP流中的上一帧开始的时间：0.000509000秒

`四、A方TCP报文序列号分析`

A方第1个报文的序列号（相对值）是0

因为在TCP建立连接的第二次握手中的确认号为ack=X+1=1，A方第2个报文作为TCP建立连接的第三次握手，其序列号seq=X+1=1

下一个报文序列号 = 其前一报文序列号 + 其前一报文所携带数据长度

在最后的TCP连接关闭时（第四次挥手），主动关闭方收到 FIN 后，会额外发送一个 ACK 给被动关闭方(这就是该26号报文的产生原因)，此时26号报文（A方最后一个报文的序号）+1即10568+1得到最终的报文序列号为10569.

10567字节

五、计算

1. 如图，双方通信所用时间：0.085306s

2.A方发送的所有的帧的长度之和为过滤后lengh的数值总和，A方发送的所有的帧的长度之和:11497字节

3.A->B连接的通信吞吐率:

A方发送的所有的帧的长度之和*8/10^6)Mb/双方通信所用的时间s
A->B连接的通信吞吐率:1.078Mbps

六、UDP协议分析

UDP报文分析

User Datagram Protocol, Src Port: 41831,Dst Port: 8080//UDP协议

Source Port: 41831 //请求方端口：41831

Destination Port: 8080 //服务器端口：8080

Length: 20 //长度：20

Checksum: 0x46c2 [unverified] //校验和

[checksum Status: Unverified] //校验状态

[Stream index: 0] //流序号：0

2. 分析TCP、UDP协议主要特点

填写下表：

`序号`	`特性`	`TCP协议的特点`	`UDP协议的特点`
`1`	`连接`	`面向连接`	`面向无连接`
`2`	`可靠性`	`高可靠`	`较可靠`
`3`	`实时性`	`一般`	`较好`
`4`	`网络开销`	`较大`	`较小`
`5`	`数据负载边界`	面向字节流，以整个待传输的数据为边界，保证数据正确性	基于数据报，以每段报文为边界，不保证传输的数据顺序