本篇文章主要介绍了" 通过packetdrill构造的包序列理解TCP快速重传机制"，主要涉及到方面的内容，对于系统运维感兴趣的同学可以参考一下：
TCP的逻辑是极其复杂的，其学习曲线虽然很平缓但其每一步都是异常艰难，好在这些都是体力活，只要肯花时间也就不在话下了。想彻底理解一个TCP的机制，有个四部曲：1...
如果你已经精通TCP的细节了，就会说，爆炸！完全符合预期啊，但对于别人而言，什么是预期，这又是怎么发生的呢？细节是什么呢？如果你只是为了理解TCP快速重传的发生原理，到这里就可以不必接续看下去了，除了TCP快速重传之外，我还附送了关于reordering的更新以及拥塞窗口的变化等细节，已经够丰富了吧。但是如果你想知道Linux协议栈的实现细节方面，或者说你的工作与协议栈的实现相关，请继续往下看。之所以我会写下来这些细节，是因为这也是怕我自己在今后的一段时间过去后忘记这些，毕竟人的记忆系统无非就是一个cache，并非永久存储系统，它无时无刻不在进行替换操作，和计算机，云等系统一样，人本身也必须有一个永久存储系统，以前是纸，现在成了硬盘...
我想还是用图示的办法来展示细节，虽然本人画图能力不是太好，但却一直在提高，图示是一个二维的说明，要比文字高效的多，比图示更高效的是三维模型，但是那目前已经超出了我的能力范围。我们先分析第一次收到多个SACK的情形：
很明了，如果你去仔细比Linux内核协议栈的实现，会更加清晰，那么在同一TCP连接的后面呈现相同的SACK序列时，情况就不同了，没有触发快速重传，下图分析之：
最终呢？我还是发现上面的论述没有一个归纳性的结论，好像一个实例解析一样，这个导致我很失望！不过我还是想归纳一下关于reordering更新的两个细节：
1.SACK导致的reordering更新
if (skb 没有被选择确认 && skb没有被重传过)
{
if (skb的序列号<>
更新reordering为最高被SACK的skb序列号-当前skb的序列号
}2.ACK导致的reordering更新
if (skb 没有被选择确认 && skb没有被重传过)
{
if (skb的序列号<>
更新reordering为最高被SACK的skb序列号-当前skb的序列号
}又复制粘贴了，其实上面两种情况是一样的！不管是选择确认还是ACK确认，只要倒序确认，都有可能证明网络存在乱序，只是是否真的乱序要有一个度，这个度就是由reordering来度量的，爆炸！
总结一下上面的这个packetdrill脚本解释的问题：
1.拥塞窗口的升降机制。初始窗口定为10后的慢启动行为以及降窗行为。
2.标准SACK以及FACK的快速重传触发时机。
3.TCP连接内的reordering的更新机制以及其与FACK的关系。
4.在触发快速重传时的TCP内部维护的各个计数器之间的关系。到此，本文也该结束了，现在时间是2016/07/16 10:32，距离起床已经过了6个小时，本文写的比较慢，原因在于中间给小小做了早饭，然后又修了空调...
最后，如果说你不知道packetdrill的工作机制，也不必慌张，如果你已经懂了packetdrill的工作机制，也不必张狂，这些都是无关紧要的。
以上就介绍了 通过packetdrill构造的包序列理解TCP快速重传机制，包括了方面的内容，希望对系统运维有兴趣的朋友有所帮助。
本文网址链接：http://www.codes51.com/article/detail_2715386_4.html
