做新传输协议，必须忘掉TCP。要是总记得TCP，就会潜意识中往TCP靠，TCP那些不合时宜的东西会影响认知和判断。
曾经我将TCP通告窗口标量化做隧道协议，效果不错，所以我想将TCP本身的通告窗口也标量化。标量化就是通告窗口不再和序列号相关，仅代表允许发送的配额。
要理解TCP滑动窗口为何不合时宜，要从最初开始。
TCP最初是纯粹的GBN(Go-back-N)协议，没有SACK，没有ofoq，为支持GBN，滑动窗口是端到端流控的唯一选择，若UNA丢失，在它之后发送的数据均不会被接收。
引入SACK后，接收端支持了ofoq，端到端流控就可以基于配额而非序列号了，基于配额的窗口就是标量窗口，基于序列号的窗口则可以理解为矢量窗口。
互联网一直是够用和极简，SACK仅作为TCP性能增强被引入，它是一个协商项，矢量滑动窗口必须保留。但实际上，你要知道自己在做什么，比如你在做一个双边隧道协议，就没必要考虑兼容。
有了SACK和ofoq，矢量滑动窗口是不必要的，为理解将窗口标量化的收益，得看一下矢量窗口的问题：
待解决的细节很多：
- ofoq能容忍多少乱序，或者容忍多久乱序。
- renege机制是否有必要，若无必要如何容错。
- …
重点是标量化通告窗口之后，乱序传输成了可能。倒不是说发送端故意乱序，而是接收端会更宽容。这样做的意义在于：
- 转发节点无需迁就TCP而必须串行保序传输。
结果是并行传输吞吐更高。但容忍乱序对发送端判定丢包提出了高要求，否则按TCP现有逻辑，乱序将会触发大量不必要重传挤兑带宽。
试着调大reordering，确实可容忍乱序，但无法快速触发重传真丢的包，这又是交易吗？其实快速重传本身也是应该忘掉的。
快速重传是怕窗口憋住，标量化通告窗口可容忍乱序，窗口自然就憋不住了，快速重传就再无必要。结论是：
- 没有必要及时精确判定丢包并重传，无需快速重传。
取而代之的是：
- 重传队列积压到固定数量或BDP固定比例后触发重传。
- 重传队列积压到一定时间或RTT固定比例后触发重传。
- 就算TCP短头不够用，可用带内新type用来做NAK。
- 重新审视超时重传必要性。
如果和TCP对照，怎么都不行，比如接收端ofoq会破坏应用程序的流式体验，但TCP滑动窗口憋住不也如此吗？问题在于TCP那种精准丢包判定和重传只是企图，从来不准。
对容忍乱序的传输，只需保证在N(比如3～4)个RTT内补足空洞，应用程序只要N个RTT的buffer就可达到相当不错的流式体验。若是标准TCP，绝不敢如此保证。
要是空洞补不足怎么办？这是一个重要的问题。回答也不啰嗦：
- 补不足就多补几次，还补不足就柔性降级，或try again。简单粗暴管用，比煞有介事的指数退避更高效稳妥。
网络质量是客观度量，不以算法为转移，网络质量很差的场景，任何规避的企图都是徒劳，硬怼或应对困境，还是改变目标适应困境，需要斟酌。
编程者们能接受JPEG这种主动有损压缩，却死活不能接受数据在不受控的网络上被动有损传输，也是有趣。
链路画像是多流竞争合作的博弈结果，链路状态不能维持，网络丢包原因不明，这是链路画像测不准的根源，端到端协议要接受这个事实。
个人心情，社会事件，天气变化均会影响到链路画像。这并不是一个在实验室拼几条流测出一个炸天数据的算法就能搞定的，所以那么多论文没一个能真打的。
柔性降级和有损传输不多说了，前面说过很多。确实需要应用程序配合改造，改就改呗，干嘛非要和TCP较劲。
周末企图将之前做的隧道协议的标量通告窗口移植到TCP，但没有成功，困难之处在于重新编译内核太麻烦了，所以这件事需要至少一个小长假来做。其实QUIC的思路大致也差不多如此。先记下来，后面有时间继续。
浙江温州皮鞋湿，下雨进水不会胖。
