首页 > 代码库 > TCP Fast Open
TCP Fast Open
We know that Web services use the TCP protocol at the transport layer. Standard TCP protocol to three-way handshake (three-way handshaking), the server can respond to the client‘s request to send data. If the three-way handshake phase, the client can send a request to the server, and the server sends a response, you can reduce the delay of Web services.
1、背景
标准的TCP规范允许客户端在初始化连接中的SYN包中携带应用数据,但是服务端的应用程序要在三路握手完成后才能从内核中得到SYN包携带的数据。如果我们直接移除这个限制,客户端可以在SYN包携带HTTP GET Request,服务端在SYN+ACK包中携带响应数据,虽然这可以满足TFO(TCP Fast Open)的需求,但很容易遭受拒绝服务攻击。攻击者可以使用伪造的IP地址向服务端发送大量的携带HTTP GET request的SYN包,这会导致服务端不能正常工作。TFO需要安全机制让服务端抵御此类攻击。TFO的目标是让TCP连接双方在三路握手过程中安全地交换数据。
2、TFO设计
TFO使用cookie抵御地址伪造攻击。如果客户端希望使用TFO,那么需要打开TCP TFO选项并且在建立TCP连接时向服务端请求cookie。下图说明TFO的使用方法:
整个过程可以分为两个阶段:TFO cookie请求阶段和TFO cookie使用阶段 。上图的红线部分表示cookie请求阶段,过程如下:
(1、客户端打开TCP TFO选项,在SYN包中携带cookie请求
(2、服务端对客户端的IP地址进行加密,生成一个cookie,然后在SYN+ACK包中携带这个cookie给客户端
(3、客户端收到cookie后缓存起来,当下次向服务端发起连接请求时,使用对应的缓存cookie
上图的蓝线部分表示cookie的使用阶段:
(1、客户端发送携带缓存的cookie和应用数据的SYN包给服务端(需要打开TCP TFO选项)
(2、服务端接收到SYN包后,对cookie进行验证。如果cookie有效,那么服务端发送SYN+ACK包对客户端的SYN包和携带的应用数据进行确认,服务端应用程序可以获取应用数据。如果cookie无效,那么服务端丢弃SYN包携带的应用数据,仅仅对SYN包本身进行确认,然后使用常规的三路握手方法建立连接
(3、如果服务端应用程序接收了SYN包中携带的数据,那么服务端可能在客户端的ACK到达之前,向客户端发送响应数据,也就是说,在TCP连接过程中,服务端就可以向客户端发送数据
(4、客户端向服务端发送ACK包进行确认,如果客户端在SYN包中携带的数据没有得到确认,那么会在ACK包中重新传送
(5、客户端与服务端接下来使用正常的TCP处理方式进行数据交换
3、TFO Cookie
TFO cookie是一个加密的数据字符串,服务端负责生成和验证TFO cookie。客户端或者连接的主动打开方缓存cookie,并且用于后续的初始化连接中。服务端加密客户端SYN包里的源IP地址,生成至多16字节的cookie。与正常的SYN包或者SYN+ACK包所需的处理时间相比,cookie的加密和验证是非常快的。没有服务端生成cookie时所使用的密匙,客户端是不能生成有效的cookie的。
4、安全考虑
TFO的目标是在TCP的连接过程中进行数据交换,并且避免任何新的安全问题。
4.1、SYN Flood Attack
如果攻击者提供的TFO cookie无效,那么SYN包中的数据就会被丢弃,接下来使用正常的TCP三路握手建立连接,那么服务端此时可以使用已有的技术如SYN cookies来抵御攻击。如果攻击者提供的cookie有效(任何客户端都可以从服务端得到一个有效的cookie),那么服务端就有资源耗尽的危险。为了解决这个问题,服务端可以为每个端口或者所有端口维护一个挂起的TFO连接计数。挂起的TFO连接表示服务端已经接受客户端的请求并发送SYN+ACK包,但是还没有收到客户端的ACK包。当挂起的TFO连接计数超过某一个阈值,所有的新TFO连接都会直接使用正常的三路握手,从而可以使用已有的抵御洪水攻击的方法保护服务端受到攻击。也就是说,攻击者可能使服务端和客户端暂时不能使用TFO建立连接,但双方仍然可以使用三路握手建立连接,保证服务端能够继续工作。
洪水攻击最初出现在90年代后期,攻击者的目标是让服务端的backlog队列溢出,导致新的SYN包被丢弃,让服务端不能正常工作。攻击者通常都会使用一个得不到响应的伪造地址向服务端发送SYN包,否则服务端向客户端发送SYN+ACK包后会接收一个RST包。服务端接收到RST包后,会释放响应的半连接,导致攻击失效。对于TFO连接来说,此类的RST包会加大攻击者造成的伤害因为服务端接收到RST包后会释放掉对应的挂起的TFO连接,导致新的TFO连接可以使用。为了解决这个问题,服务端在接收到RST波后并不释放挂起的TFO连接,直到超时发生。
4.2、Amplified Reflection Attack
TFO连接允许服务端在SYN+ACK包之后向服务端发送响应数据,如果没有TFO cookies机制,很容易遭受放大反射攻击。在之前提过,服务端的挂起的TFO连接数量是有限制的,这可以保证服务端的资源不会被消耗完。
5、重复的SYN包
当前标准的TCP允许在SYN包中携带应用数据,但是只有在完成三路握手后,服务端应用程序才能从内核中获得数据,这主要为了处理重复的SYN包。尽管TFO连接不会在重传的SYN包中携带数据,在网络中有可能产生重复的带数据的SYN包,这会导致服务端应用程序重新接收数据。假设TFO客户端在发送携带数据的SYN包并在重复的SYN包到达前主动关闭连接,服务端作为被动关闭的一方,将会接收这个重复的SYN包并且处理携带的数据。如果重复包是在2MSL时间内生成的,服务端向客户端发送SYN+ACK包,而客户端此时处于TIME_WAIT状态,会回复一个RST包给服务端,导致服务端终止连接。尽管如此,服务端仍然响应了这个重复的请求。一个探索性的方案是,当服务端接收到客户端的最后ACK包时,让服务端在2MSL时间内继续保持LAST_ACK状态,这可以阻止服务端接收迟到的重复包。像信用卡或银行应用等一些不能容忍重复事务的应用,在应用层确保幂等性。
6、性能分析
性能分析和其他细节可以参考TCP Fast Open这篇论文。
TCP Fast Open