源站服务器内部采用tcp fastopen快速回源

背景

各个直播平台主播开播的门槛非常低，存在大量的没有人气的主播，产生优质内容的主播同时也非常少。主要流量都集中在头部5%～10%的直播房间，因此存在大量比例的冷门房间，观看人数非常少。

不少的cdn或者源站，都是多层的，层级之前的数据传输大部分都是采用外网的。为了降低内部数据传输的损耗，在没有观众观看的情况下，边缘和中间层都会停止拉流，只有在中心节点有直播流数据。当有观众过来观看，会逐级向上回源。每一层级都会重新创建新的回源连接。tcp连接建立阶段至少是1+RTT，多级建立连接，累计起来，耗费的时间会比较客观。

解决方案

为了减少回源耗时，建议在tcp连接建立的时候，开启tcp fastopen。

下图是正常连接建立，以及发起http get的请求。在ack的时候，发起http get请求，耗时1RTT+。

下图是开启tcp FastOpen，可以做到0RTT。大大降低了建立连接的时间。

在客户端首次建立连接时的过程：

1、客户端发送 SYN 报文，该报文包含 Fast Open 选项，且该选项的 Cookie 为空，这表明客户端请求 Fast Open Cookie；

2、支持 TCP Fast Open 的服务器生成 Cookie，并将其置于 SYN-ACK 数据包中的 Fast Open 选项以发回客户端；

客户端收到 SYN-ACK 后，本地缓存 Fast Open 选项中的 Cookie。

所以，第一次发起 HTTP GET 请求的时候，还是需要正常的三次握手流程。

之后，如果客户端再次向服务器建立连接时的过程：

1、客户端发送 SYN 报文，该报文包含「数据」（对于非 TFO 的普通 TCP 握手过程，SYN 报文中不包含「数据」）以及此前记录的 Cookie；

2、支持 TCP Fast Open 的服务器会对收到 Cookie 进行校验：如果 Cookie 有效，服务器将在 SYN-ACK 报文中对 SYN 和「数据」进行确认，服务器随后将「数据」递送至相应的应用程序；如果 Cookie 无效，服务器将丢弃 SYN 报文中包含的「数据」，且其随后发出的 SYN-ACK 报文将只确认 SYN 的对应序列号；

3、如果服务器接受了 SYN 报文中的「数据」，服务器可在握手完成之前发送「数据」，这就减少了握手带来的 1 个 RTT 的时间消耗；

4、客户端将发送 ACK 确认服务器发回的 SYN 以及「数据」，但如果客户端在初始的 SYN 报文中发送的「数据」没有被确认，则客户端将重新发送「数据」；

5、此后的 TCP 连接的数据传输过程和非 TFO 的正常情况一致。

所以，之后发起 HTTP GET 请求的时候，可以绕过三次握手，这就减少了握手带来的 1 个 RTT 的时间消耗。

tcp fastopen相对于quic，不需要进行额外的开发和适配，复用现有的架构，就可以实现0RTT。

优化效果

按照3层回源来，服务器之间的RTT约为20ms，冷流的场景下，可以减少约40ms延迟。服务器集群一般都是跨地域的，优化效果会更明显一些。