UDP重传，似牛非马。。。

问，为什么要udp重传？？？

答：不为什么，只有不断的需求，没有写完的代码？只要有需求，ta就会存在。可能会有各种ADP，BDP，RUDP（这个真有，已经写好了git地址）,QUIC(Google，快速传输协议，2016发布出来，在一次无意的抓包的时候，看到了这个协议。总结就是很牛批。脑瓜子不好的，尽量不要看。)

为了，看这个协议， 我又重新翻看了《TCP/IP卷一》。看看有什么落下的。。。看了一圈结果就是没有。TCP的强悍之处，远远超出了UDP。现在在UDP基础上做重传，相当于给UDP实现重传机制。TCP对应抗丢包，所对应的算法，已经实现的相当好了。从慢启动，拥塞避免，快速重传，快速恢复，都是用来保证网络传输质量的。而现在要做到就是，对UDP实现一个弱一致重传。git上已经有了很多类似的实现， 可圈可点。

应用：帧同步，游戏服务框架，大地图世界构建。

实现：真正应用的实现， 要远复杂那么点。可能多了那么点封装，面向对象思想。

看看我会怎么实现。（预计一周）

解决要点：1，超时重传  2，序列号，给协议加上一个序列号。

1. 下面，继续写关于重传上的东西。这两天主要去面试了，有关面试的内容和奇葩事儿。都写另一篇文章里了。

先看下TCP是怎么做到的，TCP在滑动窗口基础上约定了一系列对应网络丢包上的解决策略。这里，有一个滑动窗口。很多人不懂这个。说什么是滑动窗口？？机制是什么？？所以把这个图拿过来解释一下，这样就比较简单明了 ：

当发送网络数据包的时候，TCP约定每个字节流，会有对应的序号。那么在接收的时候，tcp会按照这个序号确认接收。所以确认一个ACK，那么窗口就会往后移动一个。这就是滑动窗口了。看图4~9就是这个窗口的整体大小了。前1~3 个包是不是已经确认了，所以滑到了4的位置。后面的10，11更多包，窗口还没过来是不是就不能发送了。 那么，如果这当中，假如滑到4的位置，4丢了会怎么样呢？是不是就触发Time_Wait了。触发Time_Wait就该干啥了？？超时重传啊！所以就是我们这里讲的内容了。

RTT 这个 协议包往返计算公式。其中RTT就是一个比较重要的一项约定 RTT（全称：Round Trip Time）RTT由来：说的是个什么意思呢？其实就是打包快递上车，然后，再下车送回你手里的一段时间值。没有计算你上车的那段时间，和下车的时间。就是走了多长时间。那么真正计算超时的，还是要用下面这一个公式RTO（Retransmission Time Out）

 这里可能有人会说，你说ta凭什么写4？？ 这里就是一个经验值了。解释一下，这个4的由来：经过人不断的测试得出来的结论，写4就是好。

 

把RTT 解决，我们就剩一个序列号了。

2.序列号：先等等后面继续写。。。

是不是这么一个东西，在这里。静态结构：这样去约定协议的序列号。

 那么这些都有了。就可以差不多，写一个自己的超时重传列子了。下面有一个我单独整理出来的一个Unix的UDP重传实列，放git上了。所以。。。怎么实现就看你了。

注：2021.12.08

写到这里，我不仅想了。这东西具备可扩展性么，安全么。怎么去和其ta协议搭配呢。多线程下的资源竞争的问题呢？ta具备简单的，可易用性吗？让人一点就用。

我想了一下，不能。所以真的要用，只能是自己独有。单独对应自己的一套协议解析。

嗯。。是这样的。 开源可能还远远达不到要求。只能是一个单独的示例。

《王者荣耀》技术总监复盘回炉历程：没跨过这三座大山，就是另一款MOBA霸占市场了

云风的 BLOG: 可靠 UDP 传输

GitHub - Lixiaolonghh/udp_example: 《unix 卷一 》udp重传示例 
 

注：2021.11.29日 0：51分，每次写文章都是深夜！怪胎^