TFO(Tcp Fast Open)的简单解析:

今天简单看了些TFO相关的内容,下面作为记录:

TFO出现的背景:

    相信TCP三次握手的细节知识大家应该都很了解了.在说这个之前先说一下RTT的概念:     
即一个数据包从发送到收到确认的这个时间就是一个RTT(即网络传输延时).            

    当我们在发送http请求的时候就会先进行TCP的三次握手所以无法避免RTT.         

    TFO说直白了就是在三次握手的过程中发送数据(在发送SYN包的时候携带应用层数据). 

    虽然在http层面上有http keepalive,但是也会有35%的请求是重新发起一条连接[来自网络数据].    
所以TFO在某些场景下还是很有必要的(如RTT很大的情况下)．         

　　有个疑问为啥在http keepalive的情况下，还是会有请求重新进行发起连接,不知原因，希望各位解说．      

TFO的实现原理:

　　TFO是在建立三次握手的过程中进行数据的发送，那是如何做的恩？其实是这样的：

• １ 客户端发送SYN包，并在包的尾部加一个FOC请求，只有4个字节．

• ２ 服务端受到FOC请求，验证后根据来源ip地址声称cookie(8个字节)，将这个COOKIE加载SYN+ACK包的末尾发送回去．

• ３ 客户端缓存住获取到的Cookie 可以给下一次使用。

• ４下一次请求开始，客户端发送SYN包，这时候后面带上缓存的COOKIE，然后就是正式发送的数据。

• ５ 服务器端验证COOKIE正确，将数据交给上层应用处理得到相应结果，然后在发送SYN+ACK时，不再等待客户端的ACK确认，即开始发送相应数据

TFO带来的好处:

　　　TFO带来的好处是不容置疑的：首先就是减少了RTT,尤其是在RTT比较大的场景下带来的性能提高是很大的．

TFO的不足之什么场景下使用:

TFO的就是在三次握手过程中就在syn包中携带数据进行数据的传输．那么就会有个问题：

• 1.可能会收到client重复的syn+data包（当server端未及时回复ack给clinet或者网络问题client就没有收到ack情况下）． 那么问题就来了，竟然会收到重复的SYN那么重复的数据包也是肯定会收到的，所以某些场景下TFO还是不适应的．

Communite

在使用中有任何问题，欢迎反馈给我，可以用以下联系方式跟我交流

• 邮件(1031379296#qq.com, 把#换成@)
• QQ: 1031379296
• weibo: @王发康

Thx

• chunshengsterATgmail.com

Author

• Linux\nginx\golang\c\c++爱好者
• 欢迎一起交流 一起学习#
• Others say good and Others good