上一篇文章说了在使用HARQ做跨境传输的时候，会有两个难点：
难点1：你怎么知道数据包是丢失了，还是它还在传输中呢？
难点2：难点1中说要马上重传，但如果重传数据过多，又会造成带宽消耗，引起更多数据包的丢失。
对于这两个如同悖论的难点，解决起来的确有些棘手，而且解决这两个难点的方法各有不同。
我大概说说我的做法。
解决这两个难点，最麻烦的一点是我们没有一个考核标准。什么考核标准呢？就是如何判断这个数据包是正在传输状态还是说已经被丢失了。
举个例子：我们从上海邮寄一封信给北京的朋友。我们邮寄之前一定心里会有一个预期，这封信从上海到北京大概需要多久？你的朋友大概多久可以拿到你的信。如果超过了这个时间阀值，我们心里肯定会想——完了，这封信丢了。即便是这封信没丢，还在某个仓库放着，你也会觉得它是丢了的。这时候就应该想其它办法来处理邮件中的信息了。
我的专利中处理重传的机制和这个有点类似。
我会有一个时间阀值，数据包超过这个时间阀值，依然没有对方的确认信息，那么我就认为这个数据包已经丢失了。需要重传了。
这个过程中依靠的重要一点就是这个时间阀值。
这个阀值不能太大，如果太大，这个数据包已经丢失很久了，你才知道，那肯定不行的。谁都不想后知后觉的。
这个阀值也不能太小。
所以这个阀值一定是动态的，每次都会进行测量。为了保证阀值的平稳性，应该要采用一定的均值算法来进行计算。
这个过程在TCP协议中已经有了很好的解决。
RTT时间就是为了这个而存在的，以下是我百度的RTT时间解释：
RTT(Round-Trip Time)往返时间在计算机网络中它是一个重要的性能指标。表示从发送端发送数据开始，到发送端收到来自接收端的确认（接收端收到数据后便立即发送确认，不包含数据传输时间）总共经历的时间。
我们采用RTT时间来作为阀值。计算机计算需要一点时间，所以我添加一些冗余时间，采用的是RTT时间的1.5倍来作为阀值时间。每次数据发送和接收都进行计算。
下来就是求均值了。求出的均值在TCP中叫做RTO时间。下面又是贴算法的时刻了，这个算法用来计算RTO时间，是RFC中的：
Jacobaon/Karels 算法（RFC6298）
第一次RTO计算方法, 假设RTT = R
1. SRTT = R
2. RTTVAR = R/2
3. RTO = SRTT + max(G, K*RTTVAR) , K = 4
后续的RTO计算,假设当前的RTT为R'
RTTVAR = (1 - beta)*RTTVAR + beta*|SRTT - R'| *计算平滑RTT和真实RTT的差距，切记这个地方的SRTT是上一次的SRTT*
SRTT = (1 - alpha)*SRTT + alpha*R' * 计算平滑RTT*
RTO = SRTT + max(G, K*RTTVAR)
alpha = 1/8 beta = 1/4
以上算法看着头大，其实就是求均值的一种而已。
写到这里，关于HARQ的说明就差不多了。
是不是有点好奇：我们说的是跨境传输，为啥花这么大力气说HARQ呢？
在我所参与的跨境项目中，HARQ占据着非常重的角色。
下来我们说说跨境视频传输的架构。
这是跨境传输的一个简单架构图，这个架构图大致说明了采用的方法。
第一步：通过HLS下载模块来对于HLS协议的索引文件、视频文件进行下载。
第二步：将加载的文件（索引文件和视频文件）通知给HARQ客户端，要求它进行跨境传输。
第三步：HARQ服务端将接收到的文件保存到指定的目录下。
剩下的就是北美的Web Service对这个文件提供HTTP的服务了。有了HTTP服务，我们就可以在北美那边为当地的CDN对接厂商提供稳定的直播源了。
看到没有，我们从国内的HLS视频源，通过一系列的方法，将它转到了北美，做成为了北美的视频源。对于用户来说，整个过程是完全的黑盒。
就是这么神奇，哈哈。
回到我在上一篇中卖的关子，通过以上琳琳种种的方法，我们实现了跨境传输，这个实现非常麻烦，为的是控制权在我们自己。但要实现起来，却需要非常深厚的编码功底。
对于不想编程、没有开发能力的怎么做到跨境传输呢？
其实方法也有，而且还挺简单，那就是采用大名鼎鼎的BBR。
什么是BBR，这个大家可以去百度自己查找，文章、口水一大堆一大堆的。
我们的实测结果是开启了BBR以后，观看视频流的确比较稳定。没有开发能力的可以采用BBR来实现跨境传输。
网上搞开源的HARQ的东西不怎么多，知名的有WebRtc 、QUIC等等，最近比较火的SRT是基于UDT的，记得好几年前我推荐朋友使用UDT的时候，他们反馈效果不怎么样，而且好像UDT只是一个ARQ，没有FEC部分。
我们回顾一下，为了将国内的视频节目传输到北美，我们采取了HARQ作为中间传输桥梁，进行直接传输，将数据传输到北美。
但是我们国家有句话叫做——条条大路通罗马。要达到传输数据到北美，有很多的实际路线。
1：国内-》北美
2：国内-》欧洲-》北美
...
估计你还能想去很多其它的路线。
这些线路中有好有坏，有的线路是完全不能使用的。所以为了达到传输到北美，我们完全可以写一个智能线路选择，从中找出一个稳定性、丢包率、延时性都非常好的线路来进行传输。
这是否属于软件定义网络（Software Defined Network，SDN）的一种方式呢？
今天就说到这里了。
很快会有下一篇。