为什么我们需要三向握手？为什么不只是2路？

Client ------SYN-----> Server
Client <---ACK/SYN---- Server
Client ------ACK-----> Server

Client ------SYN-----> Server
Client <-----ACK------ Server

#1 楼

将握手分解为实际操作。

在TCP中，双方使用序列号来跟踪发送的内容。实际上，它最终是发送的所有内容的运行字节数。接收方可以使用对方讲话者的序列号来确认已收到的内容。

但是序列号不是从0开始。它以ISN（初始序列号）开始。随机选择的值。由于TCP是双向通信，因此双方都可以“讲话”，因此双方都必须随机生成一个ISN作为其起始序列号。反过来，这意味着双方都需要将其开始的ISN通知另一方。

因此，您将以以下事件顺序结束，以开始Alice和Bob之间的TCP对话： >

Alice ---> Bob    SYNchronize with my Initial Sequence Number of X
Alice <--- Bob    I received your syn, I ACKnowledge that I am ready for [X+1]
Alice <--- Bob    SYNchronize with my Initial Sequence Number of Y
Alice ---> Bob    I received your syn, I ACKnowledge that I am ready for [Y+1]

注意，发生了四个事件：


Alice选择一个ISN并将其与Bob同步。
Bob确认了ISN。
Bob选择一个ISN并将其与Alice同步。
Alice确认了ISN。

实际上，中间的两个事件（＃2和＃3）发生在同一数据包中。使数据包成为SYN或ACK的原因仅仅是在每个TCP标头中打开或关闭的二进制标志，因此没有什么可以防止在同一数据包上同时启用这两个标志。因此，三向握手最终变为：

Bob <--- Alice         SYN
Bob ---> Alice     SYN ACK 
Bob <--- Alice     ACK     

注意两个方向上的“ SYN”和“ ACK”两个实例，每个实例之一。
/>

所以回到您的问题，为什么不只使用双向握手呢？简短的答案是因为双向握手只会允许一方建立ISN，而另一方承认它。这意味着只有一方可以发送数据。

但是TCP是双向通信协议，这意味着任何一端都应该能够可靠地发送数据。双方都需要建立一个ISN，并且双方都需要确认对方的ISN。

因此，实际上，您对双向握手的描述完全正确，但是在每个方向上都是如此。因此，发生了四个事件。同样，中间两个标志出现在同一数据包中。因此，三个数据包参与了完整的TCP连接启动过程。

#2 楼

三向握手是必要的，因为双方都需要同步在传输过程中使用的段序列号。为此，它们每个都发送（依次）序列号设置为随机值n的SYN片段，然后对方通过序列号设置为n + 1的ACK片段确认对方。

#3 楼

为了使连接正常工作，每一端都需要验证是否可以将数据包发送到另一端。确保您将数据包发送到另一端的唯一方法是从他们那里获得一个数据包，根据定义，除非您发送的数据包通过，否则该数据包将不会被发送。 TCP本质上为此使用两种消息：SYN（请求证明此数据包已通过）和ACK（仅在SYN通过后才发送，以证明SYN通过了）。实际上有第三种信息，但是我们稍后会谈到。

在开始连接之前，双方都不了解对方。客户端将SYN数据包发送到服务器，以请求证明其消息可以通过。这不会告诉任何人任何信息，但这是握手的第一步。

如果SYN通过，则服务器知道客户端可以向其发送数据包，因为它可以刚发生。但这并不能证明服务器可以将数据包发送回：客户端可以出于多种原因发送SYN。因此，服务器需要向客户端发送两条消息：一个ACK（证明SYN通过了）和一个SYN（请求自己的ACK）。 TCP将这两个消息合并为一个-SYN-ACK消息（如果愿意），以减少网络流量。这是握手的第二步。

由于SYN-ACK是ACK，因此客户端现在确定可以将数据包发送到服务器。并且因为SYN-ACK是SYN，所以它也知道服务器希望证明此消息已通过。因此它发送回一个ACK：这次只是一个普通的ACK，因为它不再需要证明其数据包可以通过的证据。这是握手的最后一步：客户端现在知道数据包可以双向传输，并且服务器即将解决此问题（因为它知道ACK将通过）。

一旦该ACK通过，现在服务器便知道可以将数据包发送到客户端。它还知道客户端知道这一点，因此它可以立即开始发送数据。握手完成。我们有一个好的频道。

好吧，严格来说，我们不能确定我们有一个好的频道。仅因为此顺序的数据包通过并不能严格保证其他人会通过。我们无法证明，如果不发送无限数量的SYN和ACK，那么将一事无成，因此这不是一个实际的选择。但是实际上，三个步骤对于大多数目的来说已经足够了。

#4 楼

实际上，三向握手并不是建立TCP连接的唯一方法。也允许同时进行SYN交换：http://www.tcpipguide.com/free/t_TCPConnection EstablishmentmentProcessTheThreeWayHandsh-4.htm

这可以看作是两次双向双向握手。

#5 楼

TCP连接是双向的。这意味着它实际上是一对单向连接。发起方发送SYN，响应方发送ACK：一个单纯形连接开始。 “然后”响应者发送SYN，发起者发送ACK：另一个单纯形连接开始。两个单工连接形成一个双工TCP会话，同意吗？因此，从逻辑上讲，涉及四个步骤；但是由于SYN和ACK标志是TCP报头的不同“字段”，因此可以同时设置它们-第二步和第三步（四个步骤）被组合在一起，因此从技术上讲，存在三个数据包交换。根据您的建议，每个单工（半）连接都使用2路交换。

#6 楼

如果服务器和客户端要创建连接，则需要确认四件事：


服务器需要确认他可以从客户端接收数据包
客户端需要确认他可以接收数据包从服务器
客户端需要确认的东西：服务器可以从客户端接收数据包
服务器需要确认的东西：客户端可以从服务器接收数据包

Client ------SYN-----> Server之后，规则1为

在Client <---ACK/SYN---- Server之后，规则2和3被确认。

因此，需要第三个数据包来确认规则4。

#7 楼

完全没有必要。很明显，一条短消息只需要向服务器发送一个包含开始+消息的数据包，并向后一个确认它的数据包。

前面的答案仅描述了系统，而没有讨论对随机性的需求。序列号等。最初的问题是关于TCP本身的设计的-显然，如果您使用TCP协议，则需要三个消息，因为这是该协议。但是，为什么TCP首先要采用这种方式设计？

我相信最初的想法是客户端和服务器之间没有区别。双方都以双向方式知道对方的端口，并且双方都可以开始通话。而这需要Syns等。

但是，这当然不是今天的用法。服务器在一个众所周知的端口上侦听并“接受”，客户端端口号是临时的。我什至认为在正常操作系统中，等待“接受”的服务器不可能将请求发送到同一客户端端口号上的另一个请求。

（请注意，这与双向启动有关连接，直到今天为止都还没有完成。这与建立连接后通过双向发送双向消息完全不同。）

要解决TCP效率低下的问题，我们使用了HTTP 1.1之类的协议，可以重用多个请求使用相同的连接，因此避免了TCP握手，该握手首先不需要。

但是Http 1.1相对较新。由于PKI算法的成本，SSL / TLS从一开始就需要一种重用会话的方法。因此该协议包括其自己的会话重用机制，该机制在Http 1.1的基础上运行，而HTTP 1.1在TCP的基础上运行。

软件就是这样。混合在一起时产生的效果软糖。

#8 楼

在阅读了Eddie的答案（被接受为正确的答案）之后，仍然存在一个问题，为什么第一个主机不能同时为两个ISN分配随机数，而第二个主机只能接受它。使用三向握手的真正原因是为了避免半连接。两向握手的半连接情况：
1）客户端--- SYN->服务器
2）客户端改变了主意，不再想要连接
3）客户端< -X-ACK--服务器// ACK丢失
服务器没有看到重新发送的SYN，因此他认为客户端得到了他的ACK并建立了连接。因此，服务器具有永远不会关闭的连接

#9 楼

简单答案：

客户端和服务器都需要知道它们可以连接。

对于客户端：实际上，双向握手就足够了，因为它发送到服务器和服务器发送回。

对于服务器：需要三向握手，因为服务器需要知道它发送回客户端的消息（第二条消息）是否成功。来自客户端的第三条消息证明服务器的消息（第二条消息）成功，因此需要第三条消息。