TCP 是因特网协议栈中运输层（传输层）常用的协议，该协议的全称为 Transmission Control Protocol（传输控制协议），它提供了一种可靠的数据传输，而因特网协议栈中运输层的另一种常用的协议则不提供可靠的数据传输，它在网络层提供的服务基础上不提供不必要的服务。本篇我们将从 TCP 的流量控制和拥塞控制两个方面简单介绍 TCP 可靠数据传输的实现原理，顺便简单介绍一下 TCP 的连接管理。

0. TCP 报文段（Segment）结构

源端口：发送方应用程序所在的端口；
目的端口：接收方应用程序所在的端口（可能不存在）；
序号：报文段中的数据部分首个字节的编号；
确认号：标识接收方期望接收的下一个数组分组的最小编号；
检验和：用于差错检验；
接收窗口：用于流量控制，接收方允许发送方发送的数据的最大长度。

1. 流量控制

为了提高信道的利用率，发送方采用的是流水线式的方式一次性向接收方发送 N 个报文段（运输层的 packet 称为报文段）而不必等待接收方的应答。N 就被称为发送窗口的尺寸。N 的大小由接收方上次返回的应答中的接收窗口及发送方的状态决定。接收方接收到的数据会先放在接收缓存中，接收缓存是在连接建立期间创建的，接收窗口的最大值不能超过缓存的大小，RcvBuffer 表示接收缓存的大小，rwnd 表示接收窗口的大小，rwnd = RcvBuffer - 缓存中未处理的数据大小。缓存中未处理的数据大小 = 接收的总字节数 - 读取的总字节数。由此可知窗口的大小是在不断变化的，当接收方读取数据的速度快时，窗口的尺寸就大，发送方可以连续发送的数据包的数量就相对较多，否则就少。在发送端要保证 已发送的数据大小 - 已确认的数据大小 <= rwnd，以此来实现流量的控制，来使得发送方的数据发送速率和接收方的处理速度相匹配。

2. 拥塞控制

流量控制主要是为了达到发送方的数据发送速率和接收方的处理速度相匹配。而发送方也可能因为网络拥塞而被遏制，发送方对这种情况的处理称为拥塞控制。

在了解拥塞控制之前，我们先了解一下发送放是如何推断网络拥塞控制的，对于 TCP 协议而言，主要是通过两种方式，一种是客户端通过超时判断，另一种是根据来自接收端的冗余 ACK 来判断。接收端会在每批发送的数据发送时启动一个定时器，在定时器超时之前如果没有收到应答，则预测链路发生了拥塞（可能是数据分组或应答发生丢包或长时间排队）。接收端每次收到一个来自发送端的分组时，也会启动一个定时器，在定时器超时之前没有收到预期的数据分组，会发送 3 个冗余的 ACK 提示客户端出现网络拥塞。

TCP 的拥塞控制算法主要包括三部分：慢启动，避免拥塞和快速恢复。
TCP 的发送方除了维护接收窗口外，还会维护一个拥塞窗口 cwnd，在任意时刻发送方向接收方连续发送的数据不能超过 min(rwnd, cwnd)，在拥塞控制中还有一个重要变量叫慢启动阈值（ssthresh，初始大小为 64kB），当 cwnd 到达这个阈值时，发送发就由慢启动进入避免拥塞状态。
**慢启动：**当一条 TCP 连接开始时，cwnd 被设置成 1 个 MSS 的大小（Maxium Segment Size，最大报文段尺寸），即一个 RTT（Round-Trip Time，往返时间，从发送端发送报文段到收到接收端的确认之间经历的时间）中只发送一个报文段，每当接收到一个应答，就将 cwnd 增加一个 MSS，因此慢启动阶段发送速率是指数增长的。
**避免拥塞：**当 cwnd 的值增加到慢启动阈值后，就进入避免拥塞状态，该状态下，每经过一个 RTT，cwnd 的大小只会增加一个 MSS，因此这个阶段 cwnd 是线性增长的。
**快速恢复：**慢启动或者是避免拥塞阶段如果根据冗余 ACK 推断出拥塞，会进入快速恢复阶段，快速恢复阶段会等待新的 ACK 的到达，如果在超时之前收到新的 ACK，则切换到避免拥塞阶段，否则切换到慢启动阶段，切换到慢启动状态时会将慢启动阈值降低至拥塞窗口的一半。
TCP 的拥塞控制 FSM 描述如下图：

TCP 的这种拥塞控制算法被称为加性增乘性减的拥塞控制方式，这种方式在实现了拥塞控制的同时，也给网络带宽中的 TCP 连接提供了相对的公平性，同时也提升了在空闲带宽的利用率，当大家发现网络拥塞时，会试图降低其发送速率来降低拥塞，发现网络畅通时就适当增加发送速率。

通过对拥塞控制的了解，我们不难发现，当发送端需要向一个距离较远的主机发送一个数据量较大的应用报文时，可能需要等待若干个 RTT 的时间在能收到响应。TCP 分岔可以很好的解决这个问题。简单来说，TCP 分岔就是服务提供方将请求通过 CDN 定向的距离用户比较近的一台机器，这台机器将数据分组全部接收完毕后再转发给数据中心处理（只需要一个 RTT 的时间），然后再将响应转发给用户。

3. 连接管理

3.1 连接创建

连接建立之前需要服务端在某个端口运行一个进程来监听来自客户的请求。
第一步，客户端的 TCP 首先向服务端的 TCP 发送一个特殊的报文段，报文段中不包含应用层数据。报文段的首部中 SYN 被置为 1，并且会选择一个随机的序号作为初始序号，记为 seq = client_isn。
第二步，当服务端收到来自客户端的报文段后，提取出 TCP SYN 标识，为该连接分配变量和缓存后，向客户端返回允许连接的报文段，报文段中也不包含应用层数据，报文段中的 SYN 也被置为 1，确认号 ack = client_isn + 1，同时服务端也会生成一个自己的初始序号，记为 seq = server_isn。
第三步，客户端收到来自服务端的确认后，也要为服务端分配变量和缓存，并向服务方发送应答报文段，这个报文段中可以捎带应用层数据，这时 SYN 被置为 0，因为是对服务端报文段的确认，因此确认号 ack = server_isn + 1，报文段的序号为 seq = client_isn + 1。

3.2 连接关闭

连接的关闭可以由客户端发起，也可以由服务端发起，我们假设是由客户端发起的关闭连接。
第一步，客户端发送关闭连接的特殊报文段，报文段中的首部 FIN 位被置为 1。
第二步，服务端收到报文段后，会返回一个确认报文段，服务端准备好之后才会进入下一步。
第三步，服务端发送关闭连接的特殊报文段，报文段中的首部 FIN 位被置为 1，服务端收到该报文段的确认之后会关闭连接。
第四步，客户端收到报文段后，会返回一个确认报文，发送确认之后会等待 2MSL（最大段生命周期）的时间来等待由于丢包或差错导致的服务端的重发，之后客户端关闭连接。

3.3 连接的生命周期

3.3 SYN 洪范攻击

前面在介绍 TCP 连接的建立时，当服务端收到客户端的 SYN 报文段后，会为连接分配变量和接收缓存，处于此种状态的连接我们称为半连接，如果某台恶意的机器虚拟大量的 IP 地址作为源地址，向某台服务器发送 SYN 报文，这时就会导致服务端由于资源被大量半连接占用二导致正常的请求无法建立，这种 DoS 攻击被称为 SYN 洪范攻击。
针对这种类型的攻击，SYN cookie 是一种很好的防御措施。
SYN cookie 的工作过程如下：
当服务端收到来自客户端的 SYN 报文段后，并不建立半开的连接（不分配变量和缓存）。同时，在确认报文段中使用的初始序号经特殊的算法生成，该算法使用源地址和端口号以及目的地址和端口号作为入参（得到的值被称为 cookie），而且服务端并不保存该值得状态。当服务端收到客户端 ACK 后，会根据源地址和端口号以及目的地址和端口号，生成序列号，将该序列号加一得到的结果与 ACK 中的确认号比较，如果相等再为连接分配变量和缓存。