计算机网络报告Week12

Posted on
Words count in article: 2.4k | Reading time ≈ 9

Week12 TCP协议和IP协议分析

1.实验目的

  • 了解TCP协议的工作原理
  • 学习TCP建立连接三次握手的过程
  • 学习TCP断开连接四次挥手的过程
  • 快速简单了解IP协议，特别是IP数据报
  • 研究IP数据分片方法

2. 实验任务

  • 使用 Wireshark 快速了解TCP协议
  • 使用 Wireshark 快速了解 IP 协议

3. 实验过程

3.1 Wireshark 抓取TCP包

  • TCP 协议

TCP 被称为是面向连接的(connection oriented), 这是因为在一个应用进程可以开始向另一个应用进程发送数据之前，这两个进程必须互相先”握手”, 即它们必须相互发送某些预备报文段，以建立确保数据传输的参数。

  • Wireshark 相关知识详见 Exp6: DNS 报文分析和基于UDP的Socket编程

Task1:

利用Wireshark 抓取一个TCP抓取数据包， 查看其具体数据结构和实际的数据 (要求根据报文结构正确标识每个部分)， 请将实验结果附在实验报告中

这里，注释的部分为该字段的名称以及实际数据

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
Transmission Control Protocol, Src Port: 50177, Dst Port: 443, Seq: 1, Ack: 2, Len: 0
    Source Port: 50177   					# 源端口号   C4	01
    Destination Port: 443					# 目的端口号 01 bb
    [Stream index: 16]					
    [TCP Segment Len: 0]
    Sequence Number: 1    (relative sequence number)		# 序号 	12 2f f1 74
    Sequence Number (raw): 305131892										
    [Next Sequence Number: 1    (relative sequence number)] 
    Acknowledgment Number: 2    (relative ack number) 	# 确认号 60 c2 55 c9
    Acknowledgment number (raw): 1623348681
    0101 .... = Header Length: 20 bytes (5)		# 首部长度 (长8个bit) 50
    Flags: 0x010 (ACK)
        000. .... .... = Reserved: Not set # 保留未用 50 10
        ...0 .... .... = Nonce: Not set
        .... 0... .... = Congestion Window Reduced (CWR): Not set
        .... .0.. .... = ECN-Echo: Not set
        .... ..0. .... = Urgent: Not set
        .... ...1 .... = Acknowledgment: Set # Flag中的ACK已经被标记
        .... .... 0... = Push: Not set			
        .... .... .0.. = Reset: Not set
        .... .... ..0. = Syn: Not set
        .... .... ...0 = Fin: Not set 
        # 其余Flag均未被标记
        [TCP Flags: ·······A····]
    Window: 4096 									# 接收窗口大小 10 00
    [Calculated window size: 4096]
    [Window size scaling factor: -1 (unknown)]
    Checksum: 0x5abf [unverified]	# 因特网检验和 5a bf
    [Checksum Status: Unverified]
    Urgent Pointer: 0							# 紧急数据指针 00 00 (未设置)
    [SEQ/ACK analysis]
    [Timestamps]

3.2 TCP 三次握手

Task2：

根据TCP三次握手的交互图以及TCP报文段结构图逐步分析三次握手过程，请将实验结果附在实验报告中

这就是本地电脑和百度三次握手的过程。 每次握手的过程这里重复了两次，但内容是一样的

第一次握手

首先，是从本地客户端发向百度服务器的一个数据报。在这个数据报中，Seq=0，说明一开始是从序号为0的包好事发送的。我们看到这里SYN 这一位已经被设为1了，因为还没收到来自百度的确认信息，因此这里ACK为设为0

第二次握手

这是百度服务器给本地电脑发送的报文，其中 Seq=0, ACK = 1 ,因为TCP是全双工通信的，因此从百度发送来的第一个报文段也是从 seq=0 开始的。但是这个报文段中包含了对我发给百度的包的确认信息，因此这里ACK被设置了，且值为1，这说明 1 以前的包我全部都收到了，请本地发送1以后的包

第三次握手

第三次握手是本地发送给百度服务器的，此时， Seq=1, 说明这是本地发送的第二个包了(第一个包Seq=0) ； ACK = 1 说明已经收到了来自服务端的 1以前的所有包。

至此，本地和服务端的三次握手已经结束，可以相互传递信息了

3.3 TCP 四次挥手

当通信双方完成数据传输，需要进行TCP连接的释放，由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这个原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍然能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。因为正常关闭过程需要发送4个TCP帧，因此这个过程也叫四次挥手。

Task3:

根据TCP四次挥手的交互图以及TCP报文段结构图逐步分析四次挥手过程，请将实验结果附在实验报告中。

这是四次挥手的过程：

第一次挥手

第一次挥手是百度向本地发送的一个包， Seq=80634 Ack =6224. 同时，设定了Fin位，表示服务器单方面想和本地断开联系。

第二次挥手

第二次挥手是本地收到了百度想要结束的Fin之后，返回了一个带有ACK的包。同时告诉服务器，ACK=80635,说明80635以前的数据段都已经收到了。

第三次挥手

前两次挥手是主动关闭方断开连接，但是只是单方面关闭连接。现在要被动关闭方来断开连接，才能实现真正的断连。

我们看到这个是 本地向百度发送的包，设置了Fin和ACK，注意到这个包的ACK和第二次挥手发送的ACk的值是一模一样的，因为在这两次挥手之间没有收到新的来自百度的包

第四次挥手

第四次挥手，是百度收到了本地发送的带有FIN 标志的包后，返回的确认报文。

这个报文比较特殊，因为返回的报文只设置了RST位，没有设置 Seq，Ack。 RST位被设置以后，接收端收到之后不必发送ACK包。

3.4 IP分片

  • IP报文格式

  • 根据上课学习知道IP报文要交给数据链路层封装后才能发送，理想状况下，每个IP报文正好能放在同一个物理帧中发送。如果一个数据包超过1500字节(以太网的帧中最多可容纳1500字节的数据). 就需要将该包进行分片发送，这个上限被称为物理网络的最大传输单元(MTU. Maxium Transfer Unit)
  • TCP/IP 协议在发送IP数据报文时，一般选择一个合适的初始长度。当这个报文要从一个MTU大的子网发送一个MTU 小的网络时，IP协议就把这个报文的数据部分分割成能被目的子网锁容纳的较小的数据分片，组成较小的报文发送。每个较小的报文被称为一个分片。 每个分片都有一个IP 报文头，分片后的数据包的IP报头和原式IP报头分片偏移、MF标志位和校验字段不同外，其他都一样。
  • 下面通过使用ICMP 包，来产生IP分片数据包。使用ICMP包进行测试时，如果不指定包的大小，可能无法查看被分片的数据报。由于IP首部占用20个字节，ICMP首部占8个字节，所以捕获ICMP包大小最大为1472字节。但是在一般情况下，ping 命令默认的大小都不会唱过1472。 这样，发送的ICMP包就可以顺利通过，不需要经过分片再传输，如果想捕获到IP分片的包，需要指定发送的ICMP包必须大于1472 字节。
  • 可通过下方命令指定发送包的大小，如： ping -s 3005 www.ecnu.edu.cn

Task4

任取一个有IP协议的ICMP数据报并根据该报文分析IP协议的报文格式(正确标注每一个部分)， 请将实验结果附在实验报告中

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Internet Protocol Version 4, Src: 192.168.31.15, Dst: 180.101.49.11 # 源地址和目标地址
    0100 .... = Version: 4	# 版本号，一般是4   
    .... 0101 = Header Length: 20 bytes (5) # 头部长度，为20 bytes
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 84 #总长度 16进制值为 00 54
    Identification: 0xe6a0 (59040) # 标志 
    Flags: 0x00					# 标识
    Fragment Offset: 0 # 片偏移 和flag合起来是 0000
    Time to Live: 64	 # 生存时间 40
    Protocol: ICMP (1) # 协议 01
    Header Checksum: 0xcee0 [validation disabled] # 首部检验和 ce e0
    [Header checksum status: Unverified]
    Source Address: 192.168.31.15		# 源地址 ce a8 1f 0f 
    Destination Address: 180.101.49.11 # 目标地址 b4 65 31 0b

Task5

对截获的报文进行分析，将属于同一个ICMP报文的分片找出来，并分析其字节长度特点(如，每个分片的大小，片偏移等)，请将实验结果附在报告中

我想 www.ecnu.edu.cn ping 了一段长1500的报文，发现被分割成了两段。其中一段长 1514，一段长62

点开第一段报文和第二段报文：

我们发现他们的 Identification 都是一样的，为 0x0bcd. 由此我们可以断定这两个分片属于同一个ICMP报文。

第一段报文是只有IP层，没有ICMP层的。总长度为1500，即一个MTU。但是因为IP层头长度为20，所以data的总长度只有1480。 因为这是第一个报文，因此并没有数据偏移量，因此这时 Fragment Offset : 0 ，同时在Flags中也有注明，说有其他分片。

第二段报文报文的总长度为48，头长度为20，data是28，那么为什么不是20而是28呢？因为ICMP的头部占了8个字节。因为这是最后一段报文，因此Flag为0，前面只有一个满的报文，因此 Fragment Offset为1480.

因为说不管ping的字节有多长，一定都是填满一个报文之后再分出来，所以其Offset 一定都是1480的整数倍。

-------------本文结束，感谢您的阅读-------------