我们今天来学习TCP的三次握手：

三次握手

TCP三次握手是TCP协议中建立连接的过程，旨在确保双方准备好进行可靠的通信。这个过程包括三个步骤，每个步骤涉及一个数据包（也称作报文段）的交换。下面是三次握手的详细步骤：

1. 第一次握手（SYN）：

• 客户端发送一个TCP报文段到服务器，标志位中的SYN（同步）置为1，表示希望建立连接。同时还包含一个初始序号（Initial Sequence Number, ISN）Client_ISN。这个报文不携带数据，但是会消耗一个序号。

2. 第二次握手（SYN-ACK）：

• 服务器收到客户端的SYN报文后，如果同意建立连接，则发送一个报文段作为应答。这个报文段中SYN置为1，表示服务器也在进行连接请求；ACK（确认）置为1，表示确认收到了客户端的SYN报文。同时，服务器也会为自己选择一个初始序号Server_ISN，并将确认号（Acknowledgment Number, ACK）设置为Client_ISN + 1，以表明期望从客户端收到的下一个数据包的序号。这个报文同样不携带数据。

3. 第三次握手（ACK）：

• 客户端收到服务器的SYN-ACK报文后，会再发送一个确认报文给服务器。这个报文的ACK置为1，确认号设置为Server_ISN + 1，表示确认收到了服务器的SYN报文。此时，客户端已经知道服务器准备好了，自己的序号则变为Client_ISN + 1。这个报文可以携带数据，也可以不携带。

完成这三次握手之后，客户端和服务器都进入了ESTABLISHED状态，表示连接已经建立，双方可以开始互相发送数据。

三次握手的目的是为了同步序列号、确认双方的接收能力、防止旧的重复连接请求干扰新的连接建立，并且能够初始化滑动窗口等连接参数，为后续的数据传输做准备。

有点懵是不是，我们一步一步来：

第一次握手

第一次握手（SYN）客户端发送一个TCP报文段到服务器，标志位中的SYN（同步）置为1，表示希望建立连接：

一开始，服务器端先建立传输控制块：
然后进入监听状态：

然后，客户端做同样的事：
之后，TCP就会发送TCP连接请求报文段（第一次握手）
同步位SNY设置为1，表明这是一个TCP请求报文段，seq是一开始初始化序号。

注意SYN设置为1时不能携带数据，但会消耗一个序号

第二次握手

这个时候，如果服务器同意连接，服务器会发送一个TCP连接请求确认，然后进入等待状态：

同步位中的ACK和SYN都被设置为了1，序号字段seq被设置成立一个初始值y，确认端字号ack被设置为x+1，这是对TCP客户端所选的seq的确认。
注意SYN设置为1时不能携带数据

第三次握手

收到服务器的确认之后，客户端会再发一个对服务器端的确认的确认：

这次确认，确认位ACK设置为1，seq设置为x+1:
这里注意TCP普通的确认报文段可以携带数据，如果不携带数据，则不会消耗序号。确认字段被设置为y+1,这是对服务器的确认中的seq的确认。

这个时候如果服务器接收到了TCP的连接确认的确认，便会建立连接状态开始链接。
这就是三次握手，我们打个简单的比方：

想象一下两个人隔着一条河想要用一根绳子拉起一座桥来进行稳定的沟通和物资交换，这就是TCP建立连接的“三次握手”过程的形象比喻：

1. 第一次握手： 假设甲方站在河的一边，手里拿着绳子的一端。他先向河对岸的乙方喊了一声：“我要搭桥了！”并轻轻抛出绳子的另一端到河面上，但没有完全扔过去。这里的“喊一声”就像是发送SYN包，告诉对方有建立连接的意图。
2. 第二次握手： 乙方听到后，回应道：“好的，我准备好了，接住绳子！”同时，他伸出自己的手准备抓住绳子，并紧握着自己这边的绳子一端。这一行为就像服务器回复的SYN-ACK包，不仅确认收到了甲方的意图，还表达了自己也有建立连接的意愿，并且做好了准备。
3. 第三次握手： 甲方听到乙方的回应，并看到乙方已经准备好，于是用力把绳子完全甩到了乙方手中，并紧紧握住自己的那一端。这时，他说：“绳子已经交给你了，我们可以开始过桥了！”这个动作如同客户端发送的ACK包，确认连接已经成功建立，双方可以开始稳定地传递信息和物资了。

通过这样的三次互动，双方不仅确认了对方的存在和沟通的意愿，还确保了连接的稳定性和安全性，从而开始了可靠的“桥梁”交流。

两次握手行不行？

如果TCP连接建立的过程简化为两次握手，理论上似乎可以更快地建立起连接，但实际上会引入一些问题，影响网络通信的可靠性和安全性：

1. 无法确认客户端的接收能力：在标准的三次握手过程中，第二次握手包含了服务器的SYN和ACK，这既是对客户端SYN的确认，也是服务器发出的连接请求。如果省略掉客户端对这个SYN的确认（即第三次握手），服务器无法确定客户端是否成功接收到了其发送的SYN+ACK报文。这样，服务器可能会误以为连接已建立，但实际上客户端可能并未准备好，或者根本没有收到服务器的响应。

2. 老的连接请求问题：网络中可能存在延迟的分组（即“幽灵”分组），如果仅进行两次握手，当客户端发送了一个连接请求后因某种原因未收到服务器的响应，然后又发送了第二个连接请求并成功建立了连接。这时，如果第一个请求的响应延迟到达，根据两次握手的规则，服务器可能会错误地认为这是客户端的一个新连接请求，从而导致资源的无效占用或混乱。

3. 安全性降低：缺少了第三次握手的确认步骤，可能会让恶意用户更容易发起伪造的连接请求（例如SYN泛洪攻击），因为建立连接所需的交互减少，使得恶意攻击的成本降低，防护起来更加困难。

假设我们是两次握手，有这么一个场景我发送了SYN包，但是因为网络的原因，我一直没收到服务器的确认连接，然后我重新发了一次，第二次的SYN包成功到达：
连接完毕之后，之前哪个延误的SYN到了，服务器以为又要连接，所以发送确认给客户端，但是客户端早就关闭连接，不会接收，这会导致服务器资源浪费：
打个比方：

想象你是一位住在山脚下的农夫（客户端），想要和山顶的朋友（服务器）建立固定的货物交换通道。这个过程如果简化为两次握手，情况会是这样的：

1. 第一次尝试：你站在山脚下大喊：“嘿，山顶的朋友，我想明天开始每天给你送新鲜蔬菜，你准备好接收了吗？”（发送SYN请求）
2. 山顶的回应：山顶的朋友听到了你的喊声，高兴地回应：“太好了，我已经准备了一个仓库，明天开始接收你的蔬菜！”同时，他开始清理通往山脚的路径，确保你能顺利上山。（发送SYN-ACK，既确认了你的请求，也表明自己已做好准备）
   按照两次握手的逻辑，到此你们的“协议”似乎达成了。但这里的问题是：

• 不确定性：你虽然听到了山顶朋友的答应，但你并没有再次确认说：“好的，我知道你准备好了，明天见！”如果这时你的喊话因风声干扰没被听见，山顶的朋友可能会疑惑你是否真的听到了他的回应，或者是否准备好按计划行事。
• 潜在的误解：如果在第一次尝试后不久，山里起了大雾，你的声音再次传来：“我明天开始送蔬菜…”，但这次是个回音（类似于网络中的延迟数据包）。山顶的朋友可能会误以为这是你新的询问，于是又做了一遍准备，造成了不必要的劳动。
  因此，缺少了第三次握手的明确确认，就如同农夫和山顶朋友之间少了最终的“成交确认”，可能导致误解、资源浪费，甚至整个交换计划的失败。三次握手就像是在说：“我准备好了，你呢？”，“我也准备好了，我们现在可以开始了！”这样确保了双方都明确了意图，准备工作到位，可以放心开始合作。

因此，三次握手虽然牺牲了一定的连接建立速度，但它确保了连接的可靠性和安全性，是目前TCP协议中不可或缺的一部分。

我们来看一道题：