1、TCP 状态转换
TCP 状态和“线程状态”是类似的概念，用于描述 TCP 连接过程中正在执行什么操作。
TCP 服务器和客户端都有一定的数据结构来保存连接信息，而这个数据结构中有一个属性叫“状态”，操作系统内核根据状态的不同，决定当前应该执行什么操作。
TCP 状态转换图
1.1、三次握手状态
- LISTEN 状态表示服务器创建好了 serverSocket，并且绑定客户端完成，等待客户端 new Socket 进行三次握手连接。
- ESTABLISHED 状态表示连接已经建立完毕，三次握手完成。图中的两个 ESTABLISHED 状态可以认为是几乎同时进入。
1.2、四次挥手状态
- CLOSE_WAIT 表示收到对方发送过来的 fin，接下来的代码中需要调用 close 来主动返回 fin，由于关闭速度 socket 非常快，该状态不太容易被察觉到。【谁被动断开连接，谁进入 CLOSE_WAIT】
- TIME_WAIT 表示本端给对方发起 fin 之后，对方也给返回了 fin，该状态存在的意义是给最后一个 ack 重传留有一定时间，防止最后一个 ack 丢包，只要该状态还存在，就依然会保存对端的信息，才能为连接提供各种操作（包括返回 ack ）。【谁主动断开连接，谁进入 TIME_WAIT】
需要注意的是：TIME_WAIT 也不会无休止的等待，最多等待 2 MSL（MSL 是系统内核的配置项，表示客户端到服务器之间，允许消耗的最长时间），一旦超过这个时间，就再也不会发送 ack 了。
2、滑动窗口
滑动窗口时是 TCP 中非常有特点的机制。
正常机制下
滑动窗口下
正常的确认应答机制下，每次发送放收到一个 ack 后才会发送下一个数据，导致大量的时间都消耗在等 ack 上。
而滑动窗口就可以在保证可靠性传输的基础上，提高效率（减少损失的速度，而不是增加速度），通过批量传输，把多次请求的等待时间，使用同一份时间来等，减少了总的等待时间。
例如：此时批量4个数据，对应4个 ack，这4个 ack 到达的时间各异，此时不需要等所有 ack 都到达，只要有一个 ack到达，就发送下一个数据，不需要管 ack 的顺序。
当采用滑动窗口的策略时，如果出现丢包，如何进行重传？这里分两种情况讨论：
1、ack 丢了
这种情况下, 部分 ack 丢了并不要紧，对可靠性没有影响，不需要进行重传，因为可以通过后续的 ack 进行确认。
2、数据丢了
数据丢了必然需要重传。 上述重传的过程中，整体的效率是非常高的，因为这里的重传做到了“针对性”重传，不会有重复发送，整体的效率没有额外的损失，这种重传称为“快速重传”。
TCP 有接收缓冲区（生产者消费者模型），发送的数据先放到缓冲区里排队，当发现缓冲区中的数据不连续时证明数据丢失，就会重传对应的数据，待数据补齐后再继续接收后面的数据。
3、流量控制
滑动窗口的窗口大小不能无限大，如果窗口过大导致发送速度大于接收方的处理速度（导致接收缓冲区满了），就会出现丢包问题，进而影响了 TCP 的可靠传输。【任何提升效率的行为都不应该影响到可靠性】
为了让发送速度与处理速度保持步调一致，就需要根据接收方的处理能力反过来影响发送方的发送速率，称为“流量控制”。通过这个字段来给发送方反馈发送速度。该字段在普通报文中无意义，在 ack 报文中才有意义。接收方会按照自身接收缓冲区的剩余空间大小（又称为“接收窗口”）作为 ack 中窗口大小的数值，发送方就能根据该数值调整窗口大小。
当接收窗口逐渐较少，直至到 0 后，此时接收方的接收缓存区已满，发送方将停止发送。然后发送方会周期性发送窗口探测包（不携带载荷），用于查询窗口大小，当查询到窗口大小不为 0 时继续发送。
