本篇内容介绍了“Node.js高级编程之UDP可靠性源码分析”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！实验前，我们先介绍一下需要用到的工具（Mac 环境，其他环境请自行搜索相关工具）：Network Link Conditioner：模拟丢包场景，可以去苹果开发者网站上下载Wireshark：抓包分析工具云主机：因为实现发现 Network Link Conditioner 对本地回环地址不起作用，如果有更好的方法求大佬指出然后我们准备两段代码，一段作为 UDP Server，一段作为 UDP Client，Client 会向 Server 发送 26 个英文大写字母，Server 会将他们存到文件：接着我们按照下面步骤开始实验：通过 Network Link Conditioner 把丢包率设置为 50%：设置好 Wireshark 的抓包参数：在云主机上启动 Server，在本地启动 Client。接着，我们来看一下实验结果：首先，我们可以看到服务端接收到的字母少了很多，只有 14 个：服务端接收到的字母顺序是乱序的，比如 U 跑到了 T 的前面：为了进行对比，我们可以换成 TCP 试试，代码如下，结果就不贴了：接下我们试试基于 UDP 来实现一个可靠的传输协议，主要解决上面的丢包和乱序问题。首先，需要设计一下我们的协议格式。为了简单起见，我们只在原来 UDP 的数据部分分别新增 4 个字节的 SEQ 和 ACK：其中 SEQ 表示当前包的序号，ACK 表示回复序号。接下来看看，我们如何解决前面的两个问题。接收方需要维护一个变量 expectedSeq 的变量表示期待接收到的包序号。为了简单起见，我们制定如下规则：如果当前接收到的包序号等于 expectedSeq，则把包交给应用层处理，并发送 ACK 给发送方；否则我们都直接丢弃。当然更好的做法是维护一个接收窗口，这样可以批量的提交数据给应用层，也可以用来缓免费云主机域名存大于 expectedSeq 的包。假设现在发送方发送了 1 2 3 两个包，但是到达接收方的顺序是 3 2 1，按照我们的规则接收方会丢弃 3 和 2，接收 1。好家伙，顺序倒是不乱了，但是包没了。所以还得把丢包问题也解决了才行。发送方维护一个发送窗口用来存储已发送但是还未被确认的包：发送方每发送一个包的同时还需要将包放入发送窗口，并设置一个定时器用来重发这个包。当发送方接收到来自接收方的 ACK 时，需要取消掉对应包的定时器，并将发送窗口中小于 ACK 的包都删除。完整代码及使用 Demo 见文末，现在可以正常按顺序输出 26 个字母了，但是离“可靠”协议还差得远。比如第一次输出完 26 个字母后，我们再次启动客户端时发现就没有任何输出了。原因在于此时接收端的 expectedSeq 已经是 20 多了，但是新启动的 client 发送的 SEQ 还是从 1 开始的，结果就是接收端一直丢弃接收到的包，发送端一直重试。要解决这个问题，可以参考 TCP 在传输两端建立“连接”的概念，在开始发送前通过“三次握手”建立连接，也就是确定起始 SEQ，初始化窗口等工作，结束前通过“四次挥手”断开连接，即清理窗口定时器等工作。这个就留到以后再说吧。“Node.js高级编程之UDP可靠性源码分析”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注百云主机网站，小编将为大家输出更多高质量的实用文章！
相关推荐: Redis中HyperLogLog数据类型如何使用
这篇文章主要讲解了“Redis中HyperLogLog数据类型如何使用”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“Redis中HyperLogLog数据类型如何使用”吧！ Redis HyperLogLog…
免责声明：本站发布的图片视频文字，以转载和分享为主，文章观点不代表本站立场，本站不承担相关法律责任；如果涉及侵权请联系邮箱：360163164@qq.com举报，并提供相关证据，经查实将立刻删除涉嫌侵权内容。
微信扫一扫 
