iOS之快速掌握TCP 三次握手、四次分手

一、什么是TCP？

TCP是一种面向连接的、可靠的、基于字节流的传输层通信协议，是专门为了在不可靠的网络中提供一个可靠的端对端字节流而设计的，面向字节流。

二、TCP报文端结构

下看一下下面这张图了解一下TCP结构：

TCP报文段结构.png

1、端口号（源端口号、目的端口号）

• 每个 TCP 报文段都包含源端和目的端的端口号
  • 端口号作用：用于寻找发送端和接收端应用进程，这两个值加上 IP 首部中的源端 IP 地址和目的端 IP 地址就可以确定一个唯一的 TCP 连接。

2、随机序号（seq）

• 随机序号（seq）：这个字段的主要作用是用于将失序的数据重新排列。TCP 会隐式地对字节流中的每个字节进行编号，而 TCP 报文段的序号被设置为其数据部分的第一个字节的编号。序号是 32 bit 的无符号数，取值范围是0到 2^32 - 1。

3、确认序号(ack)

• 确认序号(ack):接收方在接受到数据后，会回复确认报文,其中包含确认序号.
  • 确认序号作用就是告诉发送方自己接收到了哪些数据，下一次数据从哪里开始发。因此，确认序号应当是上次已成功收到数据字节序号加 1，前提是只有 ACK 标志为 1 时确认序号（ack）字段才有效。

4、首部长度 (Header Length）

• 首部中的选项部分的长度是可变的，因此首部的长度也是可变的，所以需要这个字段来明确表示首部的长度，这个字段占 4 bit，4 位的二进制数最大可以表示 15，而首部长度是以 4 个字节为一个单位的，因此首部最大长度是 15 * 4 = 60 字节。

5、保留字段 (Reserved)

• 保留字段 (Reserved)：占 6 位，未来可能有具体用途，目前默认值为0

6、控制位 (Control Bits)

在三次握手和四次挥手中会经常看到 SYN、ACK 和 FIN 的身影，一共有 6 个标志位，它们表示的意义如下：

• URG (Urgent Bit)：值为 1 时，紧急指针生效

• ACK (Acknowledgment Bit)：值为 1 时，确认序号生效

• PSH (Push Bit)：接收方应尽快将这个报文段交给应用层

• RST (Reset Bit)：发送端遇到问题，想要重建连接

• SYN (Synchronize Bit)：同步序号，用于发起一个连接

• FIN (Finish Bit)：发送端要求关闭连接

7、窗口大小 (Window)

• TCP的流量控制由连接的每一端通过声明的窗口大小来提供。窗口大小为字节数，起始于确认序号字段指明的值，这个值是接收端正期望接收的字节。窗口大小是一个 16 bit 字段，单位是字节， 因而窗口大小最大为 65535（2^16-1） 字节。

8、检验和 (Checksum)

• 检验和 (Checksum)：功能类似于数字签名，用于验证数据完整性，也就是确保数据未被修改。检验和覆盖了整个 TCP 报文段，包括 TCP 首部和 TCP 数据，发送端根据特定算法对整个报文段计算出一个检验和，接收端会进行计算并验证。

9、紧急指针 (Urgent Pointer)

• 紧急指针 (Urgent Pointer)：当 URG 控制位值为 1 时，此字段生效，紧急指针是一个正的偏移量，和序号字段中的值相加表示紧急数据最后一个字节的序号。 TCP 的紧急方式是发送端向另一端发送紧急数据的一种方式。

10、选项 (Options)

选项 (Options)：这一部分是可选字段，也就是非必须字段，最常见的可选字段是“最长报文大小 (MSS，Maximum Segment Size)”。

11、选项 (Options)

有效数据部分 (Data)：这部分也不是必须的，比如在建立和关闭 TCP 连接的阶段，双方交换的报文段就只包含 TCP 首部。

三、TCP 的连接控制

三次握手和四次挥手是各个公司常见的考点，也具有一定的水平区分度，也被一些面试官作为热身题。

1、三次握手

先看一下下面三次握手的图：

三次握手.png

第一次握手：

• 客户端向服务器发送报文段1

  • 其中的 SYN 标志位的值为 1表示这是一个用于请求发起连接的报文段

  • 序号字段（seq）被设置为初始序号x（(Initial Sequence Number，ISN)， TCP 连接双方均可随机选择初始序号

  • 发送完报文段1之后，客户端进入 SYN-SENT 状态，等待服务器的确认。

第二次握手：

• 服务端在收到客户端的连接请求后，像客户端发送报文段2作为应答

  • 其中的ACK 标志位设置为 1，表示对客户端做出应答

  • 其ack(确认序号) 生效,该字段的值为x+1(也就是从客户端收到的报文段的序号加1),代表服务器期望下次收到客户端的数据的序号

  • 其也有SYN标志位为1，代表这同时也是一个用于发起连接的报文段，序号 seq 设置为服务器初始序号y。发送完报文段2后，服务器进入 SYN-RECEIVED 状态。

第三次握手

• 客户端在收到报文段2后，向服务器发送报文段3

  • 其 ACK 标志位为1，代表对服务器做出应答

  • 确认序号字段 ack 为 y + 1，序号字段 seq 为 x + 1。

  • 此报文段发送完毕后，双方都进入 ESTABLISHED 状态，表示连接已建立。

2、三次握手相关面试题：

TCP 建立连接为什么要三次握手而不是两次？

• 防止已过期的连接请求报文突然又传送到服务器，因而产生错误

在双方两次握手即可建立连接的情况下，假设客户端发送 A 报文段请求建立连接，由于网络原因造成 A 暂时无法到达服务器，服务器接收不到请求报文段就不会返回确认报文段.

由于客户端在长时间得不到应答的情况下重新发送请求报文段 B，这次 B 顺利到达服务器，服务器随即返回确认报文并进入 ESTABLISHED 状态,客户端在收到 确认报文后也进入 ESTABLISHED 状态,双方建立连接并传输数据

如果之后客户端正常断开连接，然而此时姗姗来迟的 A 报文段才到达服务器，服务器随即返回确认报文并进入 ESTABLISHED 状态，但是已经进入 CLOSED 状态的客户端无法再接受确认报文段，更无法进入 ESTABLISHED 状态，这将导致服务器长时间单方面等待，造成资源浪费。

• 三次握手才能让双方均确认自己和对方的发送和接收能力都正常

第一次握手：客户端只是发送处请求报文段，什么都无法确认，而服务器可以确认自己的接收能力和对方的发送能力正常.

第二次握手：客户端可以确定自己的发送和接受能力都正常，而服务端可以确认自己的接收能力还是无法确定自己的发送能力是否正常.

服务器可以确认自己发送能力和接收能力正常，对方发送能力和接收能力正常；

• 告知对方自己的初始序号值，并确认收到对方的初始序号值.

CP 实现了可靠的数据传输，原因之一就是 TCP 报文段中维护了序号字段和确认序号字段，也就是图中的 seq 和 ack，通过这两个字段双方都可以知道在自己发出的数据中，哪些是已经被对方确认接收的。

这两个字段的值会在初始序号值得基础递增，如果是两次握手，只有发起方的初始序号可以得到确认，而另一方的初始序号则得不到确认。

TCP 建立连接为什么要三次握手而不是四次？

• 相比上个问题而言，这个问题就简单多了。因为三次握手已经可以确认双方的发送接收能力正常，双方都知道彼此已经准备好，而且也可以完成对双方初始序号值得确认，也就无需再第四次握手了。

有一种网络攻击是利用了 TCP 建立连接机制的漏洞，你了解吗？这个问题怎么解决？

• 在三次握手过程中，服务器在收到了客户端的 SYN 报文段后，会分配并初始化连接变量和缓存，并向客户端发送 SYN + ACK 报文段，这相当于是打开了一个“半开连接 (half-open connection)”，会消耗服务器资源。如果客户端正常返回了 ACK 报文段，那么双方可以正常建立连接，否则，服务器在等待一分钟后会终止这个“半开连接”并回收资源。这样的机制为 SYN洪泛攻击 (SYN flood attack)提供了机会，这是一种经典的 DoS攻击 (Denial of Service，拒绝服务攻击)，所谓的拒绝服务攻击就是通过进行攻击，使受害主机或网络不能提供良好的服务，从而间接达到攻击的目的。在 SYN 洪泛攻击中，攻击者发送大量的 SYN 报文段到服务器请求建立连接，但是却不进行第三次握手，这会导致服务器打开大量的半开连接，消耗大量的资源，最终无法进行正常的服务。

解决方案：

• SYN Cookies，现在大多数主流操作系统都有这种防御系统。SYN Cookies 是对 TCP 服务器端的三次握手做一些修改，专门用来防范 SYN 洪泛攻击的一种手段。它的原理是，在服务器接收到 SYN 报文段并返回 SYN + ACK 报文段时，不再打开一个半开连接，也不分配资源，而是根据这个 SYN 报文段的重要信息 (包括源和目的 IP 地址，端口号可一个秘密数)，利用特定散列函数计算出一个 cookie 值。这个 cookie 作为将要返回的SYN + ACK 报文段的初始序列号(ISN)。当客户端返回一个 ACK 报文段时，服务器根据首部字段信息计算 cookie，与返回的确认序号(初始序列号 + 1)进行对比，如果相同，则是一个正常连接，然后分配资源并建立连接，否则拒绝建立连接。

3、四次挥手

建立一个连接需要三次握手，而终止一个连接要经过 4次握手。
原因：这由 TCP 的半关闭( half-close) 造成的。既然一个 TCP 连接是全双工 (即数据在两个方向上能同时传递)，因此每个方向必须单独地进行关闭。

这原则就是当一方完成它的数据发送任务后就能发送一个 FIN 来终止这个方向连接。

当一端收到一个 FIN，它必须通知应用层另一端已经终止了数据传送。理论上客户端和服务器都可以发起主动关闭，但是更多的情况下是客户端主动发起。

下图表示四次分手的流程图：

TCP4次挥手.png

四次挥手详细过程如下：

第一次挥手：

• 客户端发送关闭连接的报文段，FIN 标志位1，请求关闭连接，并停止发送数据。

• 序号字段 seq = x (等于之前发送的所有数据的最后一个字节的序号加1)，然后客户端会进入 FIN-WAIT-1 状态，等待来自服务器的确认报文。

第二次挥手：

• 服务器收到 FIN 报文后，发回确认报文，ACK = 1， ack = x + 1，并带上自己的序号 seq = y

• 然后服务器就进入 CLOSE-WAIT 状态。服务器还会通知上层的应用程序对方已经释放连接。

此时 TCP 处于半关闭状态，也就是说客户端已经没有数据要发送了，但是服务器还可以发送数据，客户端也还能够接收。

• 客户端收到服务器的 ACK 报文段后随即进入 FIN-WAIT-2 状态，此时还能收到来自服务器的数据，直到收到 FIN 报文段。

第三次挥手：

• 服务器发送完所有数据后，会向客户端发送 FIN 报文段，FIN=1,ACK=1,ack=x+1,seq=z，随后服务器进入 LAST-ACK 状态，等待来自客户端的确认报文段。

第四次挥手：

• 客户端收到来自服务器的 FIN 报文段后，向服务器发送ACK=1,ack=z+1,seq=x+1,，随后进入 TIME-WAIT 状态。

• 等待 2MSL(2 * Maximum Segment Lifetime，两倍的报文段最大存活时间) ，这是任何报文段在被丢弃前能在网络中存在的最长时间，常用值有30秒、1分钟和2分钟。如无特殊情况，客户端会进入 CLOSED 状态。

• 服务器在接收到客户端的报文段ACK=1后会随即进入 CLOSED 状态，由于没有等待时间，一般而言，服务器比客户端更早进入 CLOSED 状态。

3、四次挥手面试题？

为什么 TCP 关闭连接为什么要四次而不是三次？

• 服务器在收到客户端的 FIN 报文段后，可能还有一些数据要传输，所以不能马上关闭连接。

• 但是会做出应答，返回 ACK 报文段，接下来可能会继续发送数据。

• 在数据发送完后，服务器会向客户单发送 FIN 报文，表示数据已经发送完毕，请求关闭连接

• 然后客户端再做出应答，因此一共需要四次挥手。

客户端为什么需要在 TIME-WAIT 状态等待 2MSL 时间才能进入 CLOSED 状态？

按照常理，在网络正常的情况下，四个报文段发送完后，双方就可以关闭连接进入 CLOSED 状态了.

但是网络并不总是可靠的，如果客户端发送的 ACK 报文段丢失，服务器在接收不到 ACK 的情况下会一直重发 FIN 报文段，这显然不是我们想要的.

• 所以客户端为了确保服务器收到了 ACK，会设置一个定时器，并在 TIME-WAIT 状态等待 2MSL 的时间。

• 如果在此期间又收到了来自服务器的 FIN 报文段，那么客户端会重新设置计时器并再次等待 2MSL 的时间。

• 如果在这段时间内没有收到来自服务器的 FIN 报文，那就说明服务器已经成功收到了 ACK 报文，此时客户端就可以进入 CLOSED 状态了。