Java实现IP协议分析可视化：IP及相关协议仿真探索

1.IP协议概述

1.1 什么是IP协议？

IP（Internet Protocol缩写）中文就是网际协议，这个比较抽象，我们比较熟悉的还是ip地址。

ip地址翻译成中文就是网际协议地址。这个地址与我们之前说过的MAC地址有什么关系呢？

既然物理机器已经有了MAC地址，那么还需要IP地址做什么呢？

1.2 IP地址作用

通过之前对ARP协议的分析，可以发现它是通过MAC地址发送数据的，但是其有一个很大的问题：ARP协议是子网广播协议（在子网中的所有的设备都会收到该ARP协议数据包）。

那么如果两台机器不在一个子网中，通过广播的方式传递不过去，那么应该如何通信呢？如下图所示

ip协议分析可视化java ip及相关协议分析与仿真_网络协议

所有的机器都在一个子网，那是肯定不现实的，如上图，四台机器分布在两个子网中。我们需要通过一种方式来区分哪些机器（MAC）在一个子网。

在一个子网的机器可以通过广播方式进行通信，而不在一个子网的机器就只能通过路由的方式通信。

所以现在迫切需要有一套方式可以作出以上区分，这套方式就是IP地址。

1.3 IP地址的构成

IP地址，我们在实际工作中都比较熟悉，具体的信息笔者就不再详述。

ip地址一般如下所示（笔者通过ipconfig查看本机ip）：

登录后复制

# 笔者本机信息
无线局域网适配器 WLAN:

   连接特定的 DNS 后缀 . . . . . . . :
   本地链接 IPv6 地址. . . . . . . . : fe80::b993:5deb:5cb7:6cf2%9
   IPv4 地址 . . . . . . . . . . . . : 192.168.3.8
   子网掩码  . . . . . . . . . . . . : 255.255.255.0
   默认网关. . . . . . . . . . . . . : 192.168.3.1

192.168.3.8就是我的ipv4地址信息。

ip地址由两个部分组成：网络地址和主机地址。

网络地址：表示设备所连接到的局域网

主机地址：表示当前设备在该网络中的具体地址信息

如上所示：笔者当前机器192.168.3.8与笔者另一台机器192.168.3.18均在同一个网络地址下（网络地址都为192.168.3.0[通过ip地址和子网掩码共同决定当前机器所属网络段]），所以它们两者之间的通讯是可以采用广播通讯的。

以上都是IP的基本知识点，笔者不再多述。

了解完IP地址的作用，那么再来看下，有了IP地址后，处于网络层（OSI七层协议模型）中的IP协议，具体传输的数据包是怎样的呢？我们接着看。

2.IP协议包

IP数据包时一个与硬件无关的虚拟包，由head（头部）和body（数据体）两部分组成。头部主要包括版本、数据体长度、ip地址等信息。数据体主要用来传递其他协议，如TCP、UDP等。

先来感性的看下IP协议所处的位置（图片来自百度安全验证）：

ip协议分析可视化java ip及相关协议分析与仿真_tcp/ip_02

可以看到IP协议处于网络层，承接的数据报文是网络层以上各层协议内容体。

2.1 IP协议包头部格式

任何协议最重要的就是头部格式，这个决定了协议的性质，最关键的字段都在头部。

以下是IP协议头部彩图（来自百度百科）

ip协议分析可视化java ip及相关协议分析与仿真_网络协议_03

网际协议第4版（Internet Protocol version4，IPv4）是TCP/IP协议使用的数据报传输机制。数据报是一个可变长分组，有两部分组成：头部和数据。头部长度可由20~60个字节组成，该部分包含有与路由选择和传输有关的重要信息。

头部各字段意义按顺序如下（来自百度百科）：

登录后复制

1）版本（4位）：该字段定义IP协议版本，负责向处理机所运行的IP软件指明此IP数据报是哪个版本，所有字段都要按照此版本的协议来解释。如果计算机使用其他版本，则丢弃数据报。

2）头部长度（4位）：该字段定义数据报协议头长度，表示协议头部具有32位字长的数量。协议头最小值为5，最大值为15。

3）服务（8位）：该字段定义上层协议对处理当前数据报所期望的服务质量，并对数据报按照重要性级别进行分配。前3位成为优先位，后面4位成为服务类型，最后1位没有定义。这些8位字段用于分配优先级、延迟、吞吐量以及可靠性。

4）总长度（16位）：该字段定义整个IP数据报的字节长度，包括协议头部和数据。其最大值为65535字节。以太网协议对能够封装在一个帧中的数据有最小值和最大值的限制（46~1500个字节）。

5）标识（16位）：该字段包含一个整数，用于识别当前数据报。当数据报分段时，标识字段的值被复制到所有的分段之中。该字段由发送端分配帮助接收端集中数据报分段。

6）标记（3位）：该字段由3位字段构成，其中最低位（MF）控制分段，存在下一个分段置为1，否则置0代表该分段是最后一个分段。中间位（DF）指出数据报是否可进行分段，如果为1则机器不能将该数据报进行分段。第三位即最高位保留不使用，值为0。

7）分段偏移（13位）：该字段指出分段数据在源数据报中的相对位置，支持目标IP适当重建源数据。

8）生存时间（8位）：该字段是一种计数器，在丢弃数据报的每个点值依次减1直至减少为0。这样确保数据报拥有有限的环路过程（即TTL），限制了数据报的寿命。

9）协议（8位）：该字段指出在IP处理过程完成之后，有哪种上层协议接收导入数据报。这个字段的值对接收方的网络层了解数据属于哪个协议很有帮助。

10）头部校验和（16位）：该字段帮助确保IP协议头的完整性。由于某些协议头字段的改变，这就需要对每个点重新计算和检验。计算过程是先将校验和字段置为0，然后将整个头部每16位划分为一部分，将个部分相加，再将计算结果取反码，插入到校验和字段中。

11）源地址（32位）：源主机IP地址，该字段在IPv4数据报从源主机到目的主机传输期间必须保持不变。

12）目的地址（32位）：目标主机IP地址，该字段在IPv4数据报从源主机到目的主机传输期间同样必须保持不变

3 wireshark抓包分析ip数据包

3.1 常规ip数据包抓取

我们先来分析一个最简单的ip数据包，了解下基本结构。

笔者准备两台机器，采用ping的方式来进行通讯，ping之前启动好wireshark来进行相应ip抓包

ip协议分析可视化java ip及相关协议分析与仿真_tcp/ip_04

3.1.1 抓包实战

客户端直接启动cmd命令行，发送ping命令如下：

登录后复制

C:\Users\lucky>ping 192.168.3.18

正在 Ping 192.168.3.18 具有 32 字节的数据:
来自 192.168.3.18 的回复: 字节=32 时间=89ms TTL=64
来自 192.168.3.18 的回复: 字节=32 时间=97ms TTL=64
来自 192.168.3.18 的回复: 字节=32 时间=97ms TTL=64
来自 192.168.3.18 的回复: 字节=32 时间=96ms TTL=64

192.168.3.18 的 Ping 统计信息:
    数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
    最短 = 89ms，最长 = 97ms，平均 = 94ms

发送了4次请求，也收到4次回复。

3.1.2 wireshark抓包分析

在进行3.1.1动作之前，先启动wireshark，准备好抓取相应包信息，抓取信息如下：

ip协议分析可视化java ip及相关协议分析与仿真_IP_05

注意：这里的是ICMP协议，这个本质上最终还是依靠IP协议来发送数据的。所以可以不必纠结ICMP协议本身，我们点进去看下里面的IP协议体

看下第一条（No.380）ip请求体

登录后复制

No.     Time           Source                Destination           Protocol Length Info
    380 2.224698       192.168.3.8           192.168.3.18          ICMP     74     Echo (ping) request  
    id=0x0001, seq=10004/5159, ttl=64 (reply in 390)

Frame 380: 74 bytes on wire (592 bits), 74 bytes captured (592 bits) on interface 0
Ethernet II, Src: IntelCor_40:2c:f7 (10:f0:05:40:2c:f7), Dst: bc:d0:74:13:40:02 (bc:d0:74:13:40:02)
Internet Protocol Version 4, Src: 192.168.3.8, Dst: 192.168.3.18
    0100 .... = Version: 4											#IP协议版本				
    .... 0101 = Header Length: 20 bytes (5)							#协议头部长度
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)	#服务标识符
    Total Length: 60												#总长度
    Identification: 0x5b2b (23339)									#标识符
    Flags: 0x0000													#标志位
        0... .... .... .... = Reserved bit: Not set
        .0.. .... .... .... = Don't fragment: Not set				#允许分片
        ..0. .... .... .... = More fragments: Not set
        ...0 0000 0000 0000 = Fragment offset: 0
    Time to live: 64												#生存期
    Protocol: ICMP (1)												#协议
    Header checksum: 0x982b [validation disabled]					#首部校验和
    [Header checksum status: Unverified]							
    Source: 192.168.3.8												#源ip信息
    Destination: 192.168.3.18										#目标ip信息

再来看下第二条（No.390）ip响应体

登录后复制

No.     Time           Source                Destination           Protocol Length Info
    390 2.313655       192.168.3.18          192.168.3.8           ICMP     74     Echo (ping) reply    
    id=0x0001, seq=10004/5159, ttl=64 (request in 380)

Frame 390: 74 bytes on wire (592 bits), 74 bytes captured (592 bits) on interface 0
Ethernet II, Src: bc:d0:74:13:40:02 (bc:d0:74:13:40:02), Dst: IntelCor_40:2c:f7 (10:f0:05:40:2c:f7)
Internet Protocol Version 4, Src: 192.168.3.18, Dst: 192.168.3.8
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 60
    Identification: 0x63f5 (25589)
    Flags: 0x0000
        0... .... .... .... = Reserved bit: Not set
        .0.. .... .... .... = Don't fragment: Not set
        ..0. .... .... .... = More fragments: Not set
        ...0 0000 0000 0000 = Fragment offset: 0
    Time to live: 64
    Protocol: ICMP (1)
    Header checksum: 0x8f61 [validation disabled]
    [Header checksum status: Unverified]
    Source: 192.168.3.18
    Destination: 192.168.3.8

基本与上面一致，不再赘述。

我们先关注下：请求包和响应包的TTL值，都是64。

3.2 ip分片数据抓包

数据包分片时将一个数据流分为更小的片段，是ip协议用来解决跨越不同类型网络时可靠传输的一个特性。

数据包的分片主要是基于链路层所使用的MTU（最大传输单元）的大小以及使用这些二层协议的设备配置情况所决定的。

Windows环境下MTU的值可以通过以下命令来查看：

登录后复制

C:\Users\lucky>netsh interface ipv4 show subinterfaces

   MTU  MediaSenseState   传入字节  传出字节      接口
------  ---------------  ---------  ---------  -------------
  1500                1  8037961370  48818842029  WLAN
4294967295                1          0     908026  Loopback Pseudo-Interface 1
  1500                5          0          0  以太网
  1500                5          0          0  本地连接* 3
  1500                5          0          0  本地连接* 2
  1500                5          0          0  蓝牙网络连接 2

以太网默认为1500字节

当前链路层最大传输为1500字节，如果ip协议传输的包大于1500字节，那么久需要用到分片功能了。

3.2.1 客户端发送大包请求

登录后复制

# -l 代表发送数据包为3000字节
C:\Users\lucky>ping 192.168.3.18 -l 3000

正在 Ping 192.168.3.18 具有 3000 字节的数据:
来自 192.168.3.18 的回复: 字节=3000 时间=5ms TTL=64
来自 192.168.3.18 的回复: 字节=3000 时间=5ms TTL=64
来自 192.168.3.18 的回复: 字节=3000 时间=5ms TTL=64
来自 192.168.3.18 的回复: 字节=3000 时间=19ms TTL=64

192.168.3.18 的 Ping 统计信息:
    数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
    最短 = 5ms，最长 = 19ms，平均 = 8ms

3.2.2 wireshark抓包分析

数据量比较多，我们只展示一次的请求响应即可

ip协议分析可视化java ip及相关协议分析与仿真_网络_06

以上是一次完整的ping包。相对于3.1.2明显多了些，多的几次是IPv4协议的请求包。

一次ping请求Source端（192.168.3.8）向Destination端（192.168.3.18）发送了三次请求包，我们来看下具体内容

1）第一帧数据包展示

登录后复制

No.     Time           Source                Destination           Protocol Length Info
     53 4.781308       192.168.3.8           192.168.3.18          IPv4     1514   
     Fragmented IP protocol (proto=ICMP 1, off=0, ID=5b64) [Reassembled in #55]

Frame 53: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits) on interface 0
Ethernet II, Src: IntelCor_40:2c:f7 (10:f0:05:40:2c:f7), Dst: bc:d0:74:13:40:02 (bc:d0:74:13:40:02)
Internet Protocol Version 4, Src: 192.168.3.8, Dst: 192.168.3.18
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 1500											#总长度1500
    Identification: 0x5b64 (23396)
    Flags: 0x2000, More fragments
        0... .... .... .... = Reserved bit: Not set
        .0.. .... .... .... = Don't fragment: Not set			#可以分片
        ..1. .... .... .... = More fragments: Set				#还有更多分片
        ...0 0000 0000 0000 = Fragment offset: 0				#分片偏移
    Time to live: 64
    Protocol: ICMP (1)
    Header checksum: 0x7252 [validation disabled]
    [Header checksum status: Unverified]
    Source: 192.168.3.8
    Destination: 192.168.3.18
    Reassembled IPv4 in frame: 55
Data (1480 bytes)												#数据长度1480

2）第二帧数据包展示

登录后复制

No.     Time           Source                Destination           Protocol Length Info
     54 4.781308       192.168.3.8           192.168.3.18          IPv4     1514   
     Fragmented IP protocol (proto=ICMP 1, off=1480, ID=5b64) [Reassembled in #55]

Frame 54: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits) on interface 0
Ethernet II, Src: IntelCor_40:2c:f7 (10:f0:05:40:2c:f7), Dst: bc:d0:74:13:40:02 (bc:d0:74:13:40:02)
Internet Protocol Version 4, Src: 192.168.3.8, Dst: 192.168.3.18
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 1500
    Identification: 0x5b64 (23396)
    Flags: 0x20b9, More fragments
        0... .... .... .... = Reserved bit: Not set
        .0.. .... .... .... = Don't fragment: Not set			#可以分片
        ..1. .... .... .... = More fragments: Set				#还有更多分片
        ...0 0000 1011 1001 = Fragment offset: 185				#分片偏移
    Time to live: 64
    Protocol: ICMP (1)
    Header checksum: 0x7199 [validation disabled]
    [Header checksum status: Unverified]
    Source: 192.168.3.8
    Destination: 192.168.3.18
    Reassembled IPv4 in frame: 55
Data (1480 bytes)												#数据长度1480

3）第三帧数据包展示

登录后复制

No.     Time           Source                Destination           Protocol Length Info
     55 4.781308       192.168.3.8           192.168.3.18          ICMP     82     
     Echo (ping) request  id=0x0001, seq=11185/45355, ttl=64 (reply in 58)

Frame 55: 82 bytes on wire (656 bits), 82 bytes captured (656 bits) on interface 0
Ethernet II, Src: IntelCor_40:2c:f7 (10:f0:05:40:2c:f7), Dst: bc:d0:74:13:40:02 (bc:d0:74:13:40:02)
Internet Protocol Version 4, Src: 192.168.3.8, Dst: 192.168.3.18
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 68
    Identification: 0x5b64 (23396)
    Flags: 0x0172
        0... .... .... .... = Reserved bit: Not set					
        .0.. .... .... .... = Don't fragment: Not set				#可以分片
        ..0. .... .... .... = More fragments: Not set				#当前为最后一个分片
        ...0 0001 0111 0010 = Fragment offset: 370					#分片偏移
    Time to live: 64
    Protocol: ICMP (1)
    Header checksum: 0x9678 [validation disabled]
    [Header checksum status: Unverified]
    Source: 192.168.3.8
    Destination: 192.168.3.18
    [3 IPv4 Fragments (3008 bytes): #53(1480), #54(1480), #55(48)]	#3个ip分片，
    分别是No.53(1480byte)、No.54(1480byte)、No.55(48byte)
Internet Control Message Protocol

分片总结：ip数据包在大于MTU时，会进行分片传输，分片时主要关注Flags字段（这里会设置可以分片、是否有更多分片、分片偏移量）

3.3 IP协议之TTL

TTL（Time to live）包生存周期，该值定义了在数据包被丢弃之前，所经历的时间，或者说所经历的最大路由数目。

TTL在数据包被创建时就会被定义，而且在经过一个路由器时会减一。

我们通过一个示例来验证下TTL的变化。

3.3.1 客户端发送请求

为了验证TTL，我们不能再对同一子网下的其他机器发送ping命令，可以考虑其他网段的。

最简单的，我们可以直接ping一下常用的一些网站，笔者测试如下：

登录后复制

C:\Users\lucky>ping baike.baidu.com

正在 Ping bk.n.shifen.com [36.152.44.118] 具有 32 字节的数据:
来自 36.152.44.118 的回复: 字节=32 时间=13ms TTL=55
来自 36.152.44.118 的回复: 字节=32 时间=15ms TTL=55
来自 36.152.44.118 的回复: 字节=32 时间=14ms TTL=55
来自 36.152.44.118 的回复: 字节=32 时间=15ms TTL=55

36.152.44.118 的 Ping 统计信息:
    数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
    最短 = 13ms，最长 = 15ms，平均 = 14ms

3.3.2 wireshark抓包分析

我们只展示一次的请求响应即可，其他的数据都是类似的。

ip协议分析可视化java ip及相关协议分析与仿真_tcp/ip_07

1）请求包体

只看其中的ip协议内容

登录后复制

No.     Time           Source                Destination           Protocol Length Info
     18 2.659808       192.168.3.8           36.152.44.118         ICMP     74     
     Echo (ping) request  id=0x0001, seq=11600/20525, ttl=64 (reply in 19)

Frame 18: 74 bytes on wire (592 bits), 74 bytes captured (592 bits) on interface 0
Ethernet II, Src: IntelCor_40:2c:f7 (10:f0:05:40:2c:f7), Dst: 48:4c:86:16:50:f5 (48:4c:86:16:50:f5)
Internet Protocol Version 4, Src: 192.168.3.8, Dst: 36.152.44.118
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 60
    Identification: 0xabeb (44011)
    Flags: 0x0000
        0... .... .... .... = Reserved bit: Not set
        .0.. .... .... .... = Don't fragment: Not set
        ..0. .... .... .... = More fragments: Not set
        ...0 0000 0000 0000 = Fragment offset: 0
    Time to live: 64									#重点关注这里
    Protocol: ICMP (1)
    Header checksum: 0xba17 [validation disabled]
    [Header checksum status: Unverified]
    Source: 192.168.3.8
    Destination: 36.152.44.118

2）响应包体

登录后复制

No.     Time           Source                Destination           Protocol Length Info
     19 2.672765       36.152.44.118         192.168.3.8           ICMP     74     
     Echo (ping) reply    id=0x0001, seq=11600/20525, ttl=55 (request in 18)

Frame 19: 74 bytes on wire (592 bits), 74 bytes captured (592 bits) on interface 0
Ethernet II, Src: 48:4c:86:16:50:f5 (48:4c:86:16:50:f5), Dst: IntelCor_40:2c:f7 (10:f0:05:40:2c:f7)
Internet Protocol Version 4, Src: 36.152.44.118, Dst: 192.168.3.8
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x64 (DSCP: Unknown, ECN: Not-ECT)
    Total Length: 60
    Identification: 0xabeb (44011)
    Flags: 0x0000
        0... .... .... .... = Reserved bit: Not set
        .0.. .... .... .... = Don't fragment: Not set
        ..0. .... .... .... = More fragments: Not set
        ...0 0000 0000 0000 = Fragment offset: 0
    Time to live: 55									#响应TTL为55，不再是64
    Protocol: ICMP (1)
    Header checksum: 0xc2b3 [validation disabled]
    [Header checksum status: Unverified]
    Source: 36.152.44.118
    Destination: 192.168.3.8

从这里可以看出很明显的差别了，请求体的TTL为64，而响应的TTL为55（之前3.1.2中请求和响应的TTL都是64）。

这中间的差值就是笔者当前主机与baike.baidu.com所在主机中经过的路由器数。

免责声明：本文系网络转载或改编，未找到原创作者，版权归原作者所有。如涉及版权，请联系删

返回上级列表

请

联系我们

，获取更多内容

< 上一篇: 分布式MIMO性能仿真：基于Matlab的能量与频谱效率分析

下一篇: RSoft BPM算法在光波导器件仿真中的应用 >