【每日八股】复习计算机网络 Day1：TCP 的头部结构 + TCP 确保可靠传输 + TCP 的三次握手

复习计算机网络 Day1

三月份月初根据 csview 的文档系统性地复习了计算机网络当中的八股文，现在已经过去了一个半月，有一些遗忘，但常看常新，今天开始复习一遍相关的知识，先从 TCP 这个传输层协议开始。今天的内容由 csview 当中的 6 条八股组成，顺序是：

1. TCP 的头部结构；
2. TCP 如何保证可靠传输；
3. TCP 的三次握手；
4. TCP 为什么要三次握手；
5. TCP 的三次握手丢了怎么办；
6. TCP 为什么不是两次握手。

TCP 的头部结构

这部分内容参考自《TCP / IP 详解》第 17 章 17.3 TCP 报头。

首先，我们需要知道，一个 TCP 数据是被包装在 IP 数据包当中的，TCP 数据可以进一步拆解为报头部分和数据部分。如下图所示：

下图进一步给出了 TCP 数据头部结构的具体信息：

• 源端口与目的端口：16 位（为什么是 16 位？因为 16 位二进制数转换为十进制最大可以表示的无符号整数为 65535，恰好是一个 IP 地址可用的端口数目的上限）的源端口和目的端口标识了报文的返回地址以及接收方计算机上应用程序的接口。这两个值，再加上 IP 数据包头部信息当中的 IP 地址可以唯一标识一条网络连接。注意，一个 IP 地址和一个端口号合起来就是我们常说的 socket 套接字。
• 序列号（sequence number）：32 位（转为十进制无符号整数，上限大概是 42.9 亿左右），序列号是发送方用来通知对方，当前所发送的数据段的首字节在自己所发送的整个字节流当中所处的位置。需要注意的是，序列号唯一标识数据流当中的一个字节，如果当前发送的报文，序列号为 100，且该报文携带 10 个字节的数据，那么这 10 个字节的序列号范围就是 100 ～ 109，下一个报文的序列号是 110。
  在连接建立时，TCP 报文头部的 SYN 置位，此时 TCP 报文不携带任何数据，仅发送报头与接收方建立连接。此时 SYN 报文会占用一个序列号，作为发送方的起始序列号，假设记为 X，后续发送的报文的序列号就是 X + 1。序列号用于解决网络中包乱序的问题。
  「需要注意的是」：TCP 报头当中的序列号仅标识数据部分的字节，而不会标识 TCP 报文头部当中的字节。只有当 SYN 置位时，这个报文才隐式地占用一个序列号，作为字节流传输的起始序列号。
  TCP 为应用程序双方提供全双工服务，因此双方都需要维护一个序列号字段。
• 确认号（acknowledgement number）：既然双方为所传输的每一个字节都进行了编号，那么确认号这个字段的作用就是接收方用于确认接收到发送方最后一个字节的序列号的信息。确认号同样占用 32 位，只在 ACK 置位时，这个域段才有效，因为 ACK 置位表示当前报文为确认报文。
  假设当前确认号为 Y，那么当发送方接收到接收方回发的 ACK 报文时，就代表其所发送的前 Y - 1 个字节已经成功被接收方所接收了。可以将确认号理解为接收方期望发送方下一次发送的报文的序列号。
• 头部信息长度：4 位。TCP 头部可能含有可选项内容，所以 TCP 报头的长度是不确定的。在不包含任何可选字段时，报头的长度是 20 个字节，4 位首部长度字段所能表示的最大长度为 60 字节。
• 保留：6 位，现在一般置零，为将来新的用途保留。
• 窗口大小：16 位。TCP 流量控制是通过接收方告知自己的窗口大小来确认的。窗口大小是字节数，它标识了接收方从回发的确认号 ack 开始，希望接收的字节数量，由于这个字段占用 16 位，所以当前滑动窗口的最大值是 65535 字节。
• 校验和：16 位。校验和字段由发送方来填写，接收方对校验和执行 CRC 算法来检验 TCP 报文段在传输过程中是否损坏，这个校验不仅包括 TCP 头部，还包括数据部分。校验和字段是 TCP 实现可靠传输的重要保障。
  再重复一次，TCP 报文头部的校验和由发送方填写，由接收方负责校验。校验和字段占据 TCP 报头当中的 16 位，是 TCP 实现可靠传输的重要保障。
• 紧急指针：16 位。当 URG 置位时，这个字段才有效。紧急指针是一个正的偏移量，与序列号相加得到的值表示紧急数据最后一个字节的序列号。使用紧急指针是发送端向接受端发送紧急数据的一种方式。
• 选项和填充：TCP 头部的选项字段是可变长的。这部分最多包含 40 个字节，因为根据报头的“头部信息长度”字段，TCP 报文头部的最大长度为 60 个字节。最常见的可选字段是“最长报文大小”MSS，发送方通常在通信的第一个报文段指出这个选项，它表示本端所能接受的最大报文段的长度。
• 数据部分：TCP 报文段中的数据部分是可选的。在连接建立与终止时，双方交换的报文仅包含头部。

TCP 报文头部当中还包含六个控制位，它们分别是：

• URG：紧急指针标识，置位时该报文应该优先发送；
• ACK：确认标识，置位时报头当中的确认号才有效；
• RST：重置连接标识，用于重置由于主机崩溃或其他原因而出现错误的连接。RST 置位的报文段称为复位报文段；
• SYN：表示请求建立一个连接。称 SYN 置位的报文段为同步报文段；
• FIN：结束标识，用于释放连接。置位时表示发送方没有数据要发送了，关闭本方数据流。称携带 FIN 标识的报文为结束报文段；
• PSH：push 标识，置位表示带有 push 标志的数据。接收方在接收这个报文段时，应该优先将这个报文当中的数据发送给应用程序，而不是在缓冲区等待。

TCP 如何保证可靠传输？

1. 数据完整性保障

(1) 序列号与确认应答
通过序列号与确认应答确保可靠传输：基于 TCP 协议的通信过程当中，TCP 报文会为其传输的每一个字节进行唯一的序列号标识，接收方通过 ACK 报文明确告知自己已经成功接收的字节范围。

(2) 超时重传
超时重传：根据网络延迟动态调整重传的等待时间；当接收方连续发送三个重复的 ACK 报文时，无需等待，发送方快速充传。

2. 顺序与去重控制

(1) 滑动窗口协议
滑动窗口：接收方通过指定报头当中的窗口大小字段，告知发送方其可用的缓冲区大小，发送方可动态调整字节发送频率；接收方可以在缓冲区缓存乱序到达的数据，排序后再发送给应用层。

(2) 数据去重
数据去重：通过序列号识别重复报文，丢弃冗余数据。

3. 流量与拥塞控制

(1) 流量控制

• 背压控制：接收方通过 TCP 头部的窗口大小字段动态控制发送频率。
• 零窗口探测：发送方定期发送探测报文，避免接收方窗口更新导致死锁。

(2) 拥塞控制

• 慢启动：初始窗口指数增长，快速探测可用带宽；
• 拥塞避免：达到阈值后线性增长，发生丢包时窗口大小减半；
• 快速恢复：结合快速重传，避免过度降速。

4. 连接控制

三次握手确保连接的可靠性，四次挥手确保双向连接可靠关闭，并处理残留的报文。

5. 其他辅助机制

• 校验和：TCP 头部和数据部分计算校验和，丢弃损坏的报文。
• 选择性确认：扩展选项，允许接收方明确告知损坏的数据块，减少重传量。

TCP 可靠传输的保障手段总结

上面总结了五条 TCP 可靠传输的保障手段。我个人认为比较好理解、方便记忆的包括以下几条：

• 在连接建立时，双方通过三次握手确保连接可靠建立；在断开连接时，通过四次挥手可靠关闭；
• 接收方可以通过发送 ACK 置位的报文，通过确认号告知发送方当前接收方已经收到了哪些数据；
• TCP 报文当中的校验和字段由发送方负责填写，接收方对 TCP 报头和数据部分进行校验和的计算并与接收到的校验和进行比对，如果数据出错，则丢弃；
• 接收方会通过 TCP 报文告知发送方当前自己可用的缓冲区大小，发送方可据此动态调整数据的发送频率。接收到的数据会首先在缓冲区进行排序，再发送给应用层；
• 发送方在发送数据时，会进行拥塞控制。具体来说，刚开始发送时，发送数据的窗口大小会指数增长，快速探测可用带宽，发生丢包时会将窗口大小减半，结合快速重传避免过度降速（不过我个人认为拥塞控制与可靠传输的关系没有那么强）。

TCP 的三次握手？

第一次握手
客户端发起连接请求，将 TCP 报文头部的 SYN 置位，SYN 置位时，将隐式占用一个序列号，此时初始的序列号为x，发送给服务器，客户端进入 SYN_SENT 状态，等待服务器回发 ACK 报文确认。

第二次握手
服务器接收到 SYN 报文后，准备回发确认报文，将该报文的 SYN 和 ACK 置位，确认号为 x + 1，以告知发送方我已经接受到了前 x 个字节，同时初始化自己的序列号 y，发送给客户端。服务器进入 SYN_RECV 状态。

第三次握手
客户端接收到来自服务器的 ACK 与 SYN 置位的报文后，向服务器发送 ACK 置位的确认包，这个包当中的确认号为 y + 1，并且序列号为 x + 1。这个包发送完毕后，客户端和服务器进入 ESTABLISHED 状态，表示 TCP 连接建立成功。

TCP 为什么要三次握手？

只有三次握手才能证明客户端和服务器的收发能力都是正常的。

• 第一次握手：客户端发送数据，服务端接收数据，服务端可以知道客户端发送数据以及服务端接收数据的能力是正常的。
• 第二次握手：服务端发送数据，客户端接收数据，客户端可以知道服务端的发送能力和自己的发送与接收能力是正常的。
• 第三次握手：客户端发送数据，服务端接收数据，服务端可以知道自己的发送数据能力以及客户端的接收能力是正常的。

TCP 三次握手出现报文丢失的情况会发生什么？

第一次握手丢失
第一次握手时，客户端发送 SYN 置位的连接请求报文，由于得不到服务器 ACK && SYN 报文的响应，客户端会触发超时重传。重传的序列号与之前一致，并且尝试重传的次数有上限，超限之后断开连接。

第二次握手丢失
第二次握手时，服务器发送 SYN 与 ACK 置位的确认报文给客户端。如果这个报文丢失，那么客户端迟迟得不到服务器 ACK && SYN 响应，仍然触发超时重传，与第一次握手丢失的处理方式相同。此外，服务器由于接收不到确认其刚刚发送的 SYN && ACK 报文的 ACK 报文，也会触发超时重传。

第三次握手丢失
第三次握手时，客户端发送 ACK 报文来确认服务端方才发送的 SYN && ACK 报文。此时客户端进入 ESTABLISHED 状态，如果客户端的 ACK 报文丢失，服务端接收不到 ACK 报文则会重发 SYN && ACK 报文，直到收到 ACK 报文或达到重传次数上限。

TCP 为什么不是两次握手？

避免历史连接
如果采用两次握手，客户端发送 SYN 连接请求报文之后，假设此时网络较为拥堵，这个报文在网络当中滞留，客户端触发超时重传，并选取另一个通常的链路发送到了服务端，服务端通过二次握手回发确认报文与客户端建立连接，并完成了数据传输与连接断开。此时滞留在网络当中的第一个连接请求到达服务端，服务端通过二次握手再次与已经传输完数据的客户端建立连接，会导致不必要的错误与资源占用。

如果采取三次握手，那么滞留的 ACK 报文到达服务端后，服务端回发 ACK && SYN 报文，此时客户端接收到这个报文后，由于它已经与服务端传输完了数据，不会再回发第三次握手与服务端建立连接。

同步双方初始序列号
三次握手可以使得通信双方互相知晓各自的初始序列号。如果是两次握手，那么客户端发送 SYN 报文后，服务端发送 SYN && ACK 报文确认了 SYN 报文的序列号，但是服务端自身的初始序列号没有得到确认。