前言
UDP 协议是我们平时较少接触到的知识,不同于 TCP,它是“不可靠”的,今天我们就来实战一下看下它到底怎么个不可靠法?
不可靠的 UDP
实验前,我们先介绍一下需要用到的工具(Mac 环境,其他环境请自行搜索相关工具):
- Network Link Conditioner:模拟丢包场景,可以去苹果开发者网站上下载
- Wireshark:抓包分析工具
- 云主机:因为实现发现 Network Link Conditioner 对本地回环地址不起作用,如果有更好的方法求大佬指出
然后我们准备两段代码,一段作为 UDP Server,一段作为 UDP Client,Client 会向 Server 发送 26 个英文大写字母,Server 会将他们存到文件:
1 | // udp-server.js |
接着我们按照下面步骤开始实验:
- 通过 Network Link Conditioner 把丢包率设置为 50%:
- 设置好 Wireshark 的抓包参数:
- 在云主机上启动 Server,在本地启动 Client。
接着,我们来看一下实验结果:
- 首先,我们可以看到服务端接收到的字母少了很多,只有 14 个:
- 服务端接收到的字母顺序是乱序的,比如 U 跑到了 T 的前面:
为了进行对比,我们可以换成 TCP 试试,代码如下,结果就不贴了:
1 | // tcp-server.js |
接下我们试试基于 UDP 来实现一个可靠的传输协议,主要解决上面的丢包和乱序问题。
基于 UDP 的简单可靠传输协议
首先,需要设计一下我们的协议格式。为了简单起见,我们只在原来 UDP 的数据部分分别新增 4 个字节的 SEQ 和 ACK:
1 | +-------------------------------+ |
其中 SEQ 表示当前包的序号,ACK 表示回复序号。
接下来看看,我们如何解决前面的两个问题。
乱序问题
接收方需要维护一个变量 expectedSeq
的变量表示期待接收到的包序号。为了简单起见,我们制定如下规则:如果当前接收到的包序号等于 expectedSeq
,则把包交给应用层处理,并发送 ACK 给发送方;否则我们都直接丢弃。当然更好的做法是维护一个接收窗口,这样可以批量的提交数据给应用层,也可以用来缓存大于 expectedSeq
的包。
假设现在发送方发送了 1 2 3 两个包,但是到达接收方的顺序是 3 2 1,按照我们的规则接收方会丢弃 3 和 2,接收 1。好家伙,顺序倒是不乱了,但是包没了。
所以还得把丢包问题也解决了才行。
丢包问题
发送方维护一个发送窗口用来存储已发送但是还未被确认的包:
1 | +---+---+---+---+ |
发送方每发送一个包的同时还需要将包放入发送窗口,并设置一个定时器用来重发这个包。当发送方接收到来自接收方的 ACK 时,需要取消掉对应包的定时器,并将发送窗口中小于 ACK 的包都删除。
1 | +---+---+---+---+ |
完整代码及使用 Demo 见文末,现在可以正常按顺序输出 26 个字母了,但是离“可靠”协议还差得远。比如第一次输出完 26 个字母后,我们再次启动客户端时发现就没有任何输出了。原因在于此时接收端的 expectedSeq
已经是 20 多了,但是新启动的 client 发送的 SEQ 还是从 1 开始的,结果就是接收端一直丢弃接收到的包,发送端一直重试。
要解决这个问题,可以参考 TCP 在传输两端建立“连接”的概念,在开始发送前通过“三次握手”建立连接,也就是确定起始 SEQ,初始化窗口等工作,结束前通过“四次挥手”断开连接,即清理窗口定时器等工作。这个就留到以后再说吧。
代码
1 | // packet.js |