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状态，这可以阻止服务端接收迟到的重复包。像信用卡或银行应用等一些不能容忍重复事务的应用，在应用层确保幂等性。