本篇文章主要介绍了" 通过packetdrill构造的包序列理解TCP快速重传机制"，主要涉及到方面的内容，对于系统运维感兴趣的同学可以参考一下：
TCP的逻辑是极其复杂的，其学习曲线虽然很平缓但其每一步都是异常艰难，好在这些都是体力活，只要肯花时间也就不在话下了。想彻底理解一个TCP的机制，有个四部曲：1...
TCP的逻辑是极其复杂的，其学习曲线虽然很平缓但其每一步都是异常艰难，好在这些都是体力活，只要肯花时间也就不在话下了。想彻底理解一个TCP的机制，有个四部曲：
1.读与其相关的RFC；
2.看Linux协议栈的TCP实现；
3.通过抓包以及其它工具来确认事实就是如此；
4.解决一个与之相关的网络问题。经历了以上四步骤，相信任何人都可以在相关领域内稍微装逼一把了...
本文的内容是TCP快速重传机制，但是与其它文章不同的是，本文并不剖析源码实现，也不翻译RFC，更不是原理性介绍，而是通过一个TCP报文序列来看TCP到底是怎么运作的，在可能的情况下，我会对照Linux协议栈源码。
我们知道，TCP是一个与全世界相关的混沌系统，但是其最终还是要落实到每一个细节，这些细节都是有章可循的，最终就是RFC的规范，在这些微观的细节章法的范围内，TCP在宏观上才得以表现为一个让人琢磨不透的混沌系统。
理解一个机制最好的办法就是实例讲解，那么随便从网上抓一个报文序列来分析就再好不过，但是这只是事情的一个方面，事情的另一个方面就是，一定要可重现！正是由于TCP在宏观上是一个混沌系统，才让现实中无法重现任意一个TCP报文序列。因此我们必须手工构造报文序列。
可以做到构造报文序列的工具有很多，比较了一下，我还是选择了packetdrill，这是google的一个工具，比较好用，其不足在于在不同的内核版本上可能会有不同的怪异的问题，正如其社区所承认的，他们没有时间去维护一个放之四海而皆准的稳定版本，但是这无所谓，小白bug自己修复便是，没有修复过bug的程序员是经理。关于packetdrill的细节我就不再赘述，自行到其github上去了解便是，本文马上开始步入正题。
在行文继续之前，我先说明一个细节。
由于packetdrill是在运行时才打开一个tun(由tun.ko驱动的一个虚拟网卡设备)网卡设备，然后对其配置，为了仅仅论述TCP本身，我需要消除任何offload机制的影响，并且我不知道怎么用参数去掉offload(好像也没有！)，因此我修改了packetdrill的netdev.c的代码：
/* Set the offload flags to be like a typical ethernet device */
static void set_device_offload_flags(struct local_netdev *netdev)
{
#ifdef linux
// const u32 offload =
// TUN_F_CSUM | TUN_F_TSO4 | TUN_F_TSO6 | TUN_F_TSO_ECN | TUN_F_UFO;
// if (ioctl(netdev->tun_fd, TUNSETOFFLOAD, offload) != 0)
// die_perror("TUNSETOFFLOAD");
#endif
}很傻比的一个修改，特此声明。
