网络实验:观察UDP协议通信过程

为更好地理解 UDP 协议的工作原理,本节我们安排一次实验,来观察 UDP 应用的通信过程。

Client-Server 模型

开始之前,我们先来讨论 客户端-服务端模型 ( client-server model ),简称 CS模型

网络应用一般可以分为两种角色,一种角色负责提供服务或资源,称为 服务端 ( server );另一种角色则是服务和资源的访问者,一般称为 客户端 ( client )。

如下图,这是一个典型的例子:右边是一台 服务器 ,它负责提供数据服务;左边的手机、PC等设备则是 客户端 ,它们可以通过互联网访问服务器提供的数据:

像这样由客户端和服务端组成的通信模型就叫做 CS模型 ,这种架构在分布式系统中非常常见。

典型应用

我们提供了一个简单的网络时间查询应用,它分为服务端和客户端两部分:

  • 服务端 udp-time-server 监听某个端口上的 UDP 请求报文,并提供时间查询服务;
  • 客户端 udp-time-client 负责向服务端发起时间查询请求,并输出结果;

客户端和服务端之间采用 UDP 作为通信协议:

  1. udp-time-client 先发出一个时间查询请求,该请求被封装成 UDP 数据报发给服务端;
  2. udp-time-server 对请求进行处理,应答数据同样被封装成 UDP 数据报发给客户端;

客户端和服务端双方使用 UDP 协议进行通信,它们必须对 UDP 数据的格式达成一致:

这个应用非常简单,通信数据只分为 请求 ( request )和 应答 ( reply )两种。

其中,请求由客户端发起,它需要提供时间格式化字符串,将期望的时间格式告诉服务端。请求数据分为两个字段:

  • 时间格式化字符串长度
  • 时间格式化字符串

应答由服务端发出,它需要将时间按照期望的格式,发给客户端。应答数据也分为两个字段:

  • 时间字符串长度
  • 时间字符串

请求数据和应答数据,都要符合这样的格式才能被通信双方所接受。关于这部分数据格式的约定,其实就构成了 应用层 协议。理论上,我们定的这个数据格式,就构成了一个应用层协议,虽然它还非常简陋。

最后,我们回过头来看:怎么将时间查询应用跑起来。

服务端

在 Linux 终端中执行 udp-time-server 命令,即可启动时间查询应用的服务端:

1
udp-time-server -p [服务端端口]
  • -p 选项指定监听端口。

客户端

同理,在 Linux 终端中执行 udp-time-client 命令,即可运行时间查询客户端:

1
udp-time-client -i [服务端IP] -p [服务端端口] -f [时间格式化字符串]
  • -i 选项指定服务端的 IP 地址;
  • -p 选项指定服务端的端口;
  • -f 选项指定期望的时间格式,可使用形如 %Y-%m-%d %H:%M:%S 的时间格式化串;

实验步骤

我们需要准备一台服务器和一台客户端主机,之前介绍 traceroute 的演示环境,就是一个不错的选择:

实验环境同样由 Docker 提供,只需执行这个 docker 命令即可一键启动:

1
docker run --name udp-time-service-lab --rm -it --privileged --cap-add=NET_ADMIN --cap-add=SYS_ADMIN -v /data -h switch fasionchan/netbox:0.6 bash /script/udp-time-service-lab.sh

实验环境启动后,我们将看到 3 个窗口。其中,有两个窗口属于主机 ant ,另一个窗口属于主机 apple 。

如何在不同窗口间进行切换呢? 我们来复习一下 tmux 窗口切换操作:

  1. 按下 tmux 功能键 Ctrl-B
  2. 再按下 Q ,这时每个窗口会出现一个数字;
  3. 按下窗口上的数字,即可切到对应的窗口;

我们在主机 apple 上运行服务端 udp-time-server ,-p 选项指定监听端口为 12345 :

1
root@apple [ ~ ]  ➜ udp-time-server -p 12345

运行客户端之前,我们先使用 tcpdump 命令进行抓包,以便观察双方的通信过程:

1
2
3
root@ant [ ~ ]  ➜ tcpdump -nXi eth0 udp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

请注意,tcpdump 命令最后的参数是过滤规则,规则 udp 表示只抓 UDP 协议报文。

准备完毕后,我们在主机 ant 上执行客户端 udp-time-client ,向位于主机 apple 的服务端请求时间:

1
2
3
root@ant [ ~ ]  ➜ udp-time-client -i 10.0.2.2 -p 12345 -f '%Y-%m-%d %H:%M:%S'
Receive 20 bytes
2021-03-16 20:30:52
  • -i 指定服务端的地址,即 10.0.2.2 ;
  • -p 指定服务端监听的端口,即 12345 ;
  • -f 指定想要的时间格式;

udp-time-client 命令的输出表明,它收到了服务端回复的应答,当前时间是 2021-03-16 20:30:52

服务端 udp-time-server 的输出表明,它收到了来自 10.0.1.2 ,也就是 ant 的请求:

1
2
root@apple [ ~ ]  ➜ udp-time-server -p 12345
10.0.1.2:53018 request with format: %Y-%m-%d %H:%M:%S

主机 ant 上的 tcpdump 程序输出也表明,它向 10.0.2.2( apple )发出了一个 UDP 数据报,报文中带着时间查询请求;随后收到 10.0.2.2 回复的 UDP 数据报,报文中是一个时间查询应答。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
root@ant [ ~ ]  ➜ tcpdump -nXi eth0 udp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
20:30:52.034026 IP 10.0.1.2.53018 > 10.0.2.2.12345: UDP, length 22
        0x0000:  4500 0032 e63a 4000 4011 3d7d 0a00 0102  E..2.:@.@.=}....
        0x0010:  0a00 0202 cf1a 3039 001e 1733 0000 0012  ......09...3....
        0x0020:  2559 2d25 6d2d 2564 2025 483a 254d 3a25  %Y-%m-%d.%H:%M:%
        0x0030:  5300                                     S.
20:30:52.034250 IP 10.0.2.2.12345 > 10.0.1.2.53018: UDP, length 24
        0x0000:  4500 0034 f809 4000 3d11 2eac 0a00 0202  E..4..@.=.......
        0x0010:  0a00 0102 3039 cf1a 0020 1735 0000 0014  ....09.....5....
        0x0020:  3230 3231 2d30 332d 3136 2032 303a 3330  2021-03-16.20:30
        0x0030:  3a35 3200                                :52.

tcpdump 输出看着有点费劲,但我们可以用 Wireshark 来解读,pcap 文件同样可以从 Github 上获取。

WireShark 显示了两个 UDP 报文,其中一个是时间查询请求,另一个是时间查询应答。点击 UDP 协议部分,可以查看 UDP 报文的头部信息;点击 Data ,可以查看 UDP 报文中的数据。

图中高亮的部分就是 UDP 报文中的数据,也就是时间查询请求:前四个字节 00000012 就是时间格式化字符串的长度,十六进制 12 换算成十进制是 18 。后面紧跟着时间格式化字符串%Y-%m-%d %H:%M:%S\0 ,包含 \0 在内,正好就是 18 字节。

小菜学网络】系列文章首发于公众号【小菜学编程】,敬请关注:

【小菜学网络】系列文章首发于公众号【小菜学编程】,敬请关注: