from :3358 www.page fault.info /？ p=282
转载于33558www.Sina.com/pagefault
33558 www.Sina.com/tfo (TCP fast open )简介
这是谷歌几个人提出的rfc，是tcp的强化，简单来说就是三次握手时也用于交换数据。 google内部已经使用了这个，但是关于内核的patch还没有开源，chrome也支持这个(client的内核必须支持).TFO在默认情况下是关闭的因为有特定的适用场景，所以在下面介绍。
相关rfc:
33558 www.IETF.org/id/draft-cheng-tcpm-fast open-00.txt
相关ppt:
33558 www.IETF.org/proceedings/80/slides/tcpm-3.pdf
我简单介绍这个。 如果想知道详细的设计和实现，还是去看上面的rfc。
1 http的keepalive受idle时间限制，但据谷歌统计(chrome浏览器)，尽管chrome打开了http的keepalive(chrome为4分钟)，但依然有35% 因为三次握手会导致RTT延迟，所以TFO的目标是消除此延迟，以便在三次握手之间也能交换数据。
2 RFC793允许在syn数据包中包含数据，但需要三次握手才能传递到APP应用程序。 这样，syn拥有数据可能会引起两个问题，主要是由于两个原因。 第一，这实际上是由三次握手的必要性决定的，因为前面的连接可能是重复的，或者是旧数据的连接(syn data的数据)。 二是最重要的，也就是为了防止安全方面的攻击。
如此在3TFO中解决了这两个问题，第一个问题是TFO选择接受重复的syn，其中一些APP应用可以接受重复的syn数据的“幂等操作”，即交给APP应用本身打开TFO 例如，http的查询操作(幂等)。 但是，例如post这种类型的情况下，不能使用TFO。 因为，有可能会改变server的内容。 因此，缺省情况下TFO处于关闭状态，内核为当前tcp连接提供了打开TFO的接口。 为了解决第二个问题，TFO有Fast Open Cookie。 这是TFO最核心的东西。 也就是说是tag。
4启用tfo的tcp连接也很简单。 首先，客户端请求一个请求(非TFO )，一个Fast Open Cookie )，然后在接下来的三次握手中使用此cookie (该请求将在三次握手时交换数据)。
以下skdbh很好地显示了已启用TFO的tcp连接。