分享两个通信有关的案例

UDP丢包

20多年前，我还在上初中，我们首席架构师那时候是做操作系统的。他负责DNS的IP地址分发。那个年代他做压测时QPS达到400多时能发现明显的丢包现象。最终经过层层追踪发现是由于使用的UDP协议丢包引起的。

为什么会丢包呢？

UDP协议是不可靠的协议，上面的场景中压测时操作系统缓冲池满了，按照UDP协议的规则，满了老数据就丢弃掉没有任何后续处理。看起来的现象就是丢包。

如果换成TCP协议能不能解决问题？

答案是不知道。因为TCP协议是可以定义溢出之后的策略的，可以设置直接丢弃，也可以重发。而使用TCP这样的可靠协议，开销更大。本身这个问题就是资源不足引起的，所以实际效果不好说，需要测试。

逆向工程-微信为什么那么快

大家有没有发现在网络不好的时候，手机上别的应用都跪了，网站都打不开了。但是微信还勉强能用？微信为什么这么牛呢。今天我带大家来分析分析怎样做逆向工程，破解技术奥秘。

首先要了解清楚核心问题：网络不好的情况下响应问题。那第一步就要看网络高的情况下微信做了什么，网络不高的情况下微信做了什么。

可以使用wireshark抓包工具进行分析。wireshark可以延迟转包还可以随机丢弃一部分包来模拟网络不好的场景。

可以看到在网络好时，微信有自己的协议，传输安全上做了很多工作。如果网络不好，协议直接退回最简单的https协议，在安全上也做了一定的妥协。从抓包上可以查看很多协商密钥等安全过程没有了。

还有一个很重要的原因，就是DNS解析。如果网络不好的情况下，要访问一个网站，先要DNS解析。解析完了网络断了，用户看到就是根本访问不了。而微信会在客户端缓存3个IP。所以会直接跳过这一步，直接IP访问。而咱们在网络不好的情况下在百度上，有时候百度能打开，能搜索到东西，但是点击具体要跳转的链接就打不开了，原因大概率是缓存了百度网址，减少了DNS解析的过程。

其实微信除了技术上还有一些用户体验上的小优化：比如网络不好的情况下，用户发一条消息，它会多次重试，重试时会有特别不明显的小转圈。用户不仔细看都以为自己发送成功了。好久之后才会发现有个红色感叹号。

这个小技巧不是微信的专利。很多公司在处理数据慢的时候会做一个进度条。这个进度条的进度其实不是实际进度，是根据时间计算出来的。所以这就是为什么有时候进度到达99%就不走了。用户看到这里，觉得就差那么一点点，还不忍心放弃，继续等。这样来增加用户留存率。