来聊聊 TCP 协议

什么是 TCP 协议？TCP 协议的历史？为什么会有 TCP 协议？

TCP 三次握手在做什么？

三次握手所做的事情就是建立连接。

TCP 的三次握手

TCP 协议使用三次握手机制来实现客户端和服务端之间的连接建立。

三次握手其实是在验证通信双方是否有收发消息的能力：

客户端	服务端
自己发信 [ ]	自己发信 [ ]
自己收信 [ ]	自己收信 [ ]
对方发信 [ ]	对方发信 [ ]
对方收信 [ ]	对方收信 [ ]

有一张图片很好地展示了三次握手的工作过程：

三次握手的过程如下：

第一次握手：客户端发送一个消息给服务端。服务端可以确认客户端的发信能力以及自己的收信能力是没有问题的。

Q: 消息里有哪些内容？

客户端	服务端
自己发信 [ ]	自己发信 [ ]
自己收信 [ ]	自己收信 [✔]
对方发信 [ ]	对方发信 [✔]
对方收信 [ ]	对方收信 [ ]

第二次握手：服务端发送一个消息给客户端。客户端可以确认自己发信和收信能力没有问题，服务端的发信和收信能力没有问题。

客户端	服务端
自己发信 [✔]	自己发信 [ ]
自己收信 [✔]	自己收信 [✔]
对方发信 [✔]	对方发信 [✔]
对方收信 [✔]	对方收信 [ ]

第三次握手：客户端发送一个确认消息给服务端。服务端可以确认自己的发信能力以及对方的收信能力没有问题。

客户端	服务端
自己发信 [✔]	自己发信 [✔]
自己收信 [✔]	自己收信 [✔]
对方发信 [✔]	对方发信 [✔]
对方收信 [✔]	对方收信 [✔]

于此，客户端和服务端就算是建立连接了。

需要注意的是，客户端和服务端通过三次握手建立连接后，并不会真的在双方之间拉一条连接线。连接的状态是双方各自维持的。也就是说，客户端这边会记录自己正在和某个ip地址的服务器的某个端口建立连接，在服务端也是一样。

但仅仅是这么讲解 TCP 三次握手就太浅了，我觉得，对于这个机制，应该研究到可以写代码实现的细度。为什么呢？为了真正地去理解 TCP 三次握手是如何实现的，以后自己编写相应的工具或者机制时，可以有更丰富的思路。

在更详细地讨论 TCP 三次握手前，我们需要知道一些关于 TCP 的基础知识：

TCP 报文长下面这样：

TCP 报文中有些常见的标识，这些表示在详细讲解三次握手时会用到：

标识	解释
SYN	Synchronization 同步
ACK	Acknowledgment 确认
FIN	Finish 终止

对于三次握手的另一种解释

在Google Groups的TopLanguage中看到一帖讨论TCP“三次握手”觉得很有意思。贴主提出“TCP建立连接为什么是三次握手？”的问题，在众多回复中，有一条回复写道：“这个问题的本质是, 信道不可靠, 但是通信双发需要就某个问题达成一致. 而要解决这个问题, 无论你在消息中包含什么信息, 三次通信是理论上的最小值. 所以三次握手不是TCP本身的要求, 而是为了满足"在不可靠信道上可靠地传输信息"这一需求所导致的. 请注意这里的本质需求,信道不可靠, 数据传输要可靠. 三次达到了, 那后面你想接着握手也好, 发数据也好, 跟进行可靠信息传输的需求就没关系了. 因此,如果信道是可靠的, 即无论什么时候发出消息, 对方一定能收到, 或者你不关心是否要保证对方收到你的消息, 那就能像UDP那样直接发送消息就可以了.”。这可视为对“三次握手”目的的另一种解答思路。

为什么不能是两次握手或者四次握手？

现在明白了什么是 TCP 的三次握手机制，但假如我问你，为什么是三次握手？为什么不能是两次握手或者四次握手？你会如何回答？

首先，为什么不能是两次握手？

假想一下，假如世界爆发丧尸危机，你现在在一个人在某个据点，名叫 A 据点，你手头有一台无线电设备，你想要与外面还存活着的人类取得联系。你发送了一个消息给某个据点（B 据点）的无线电设备，你不确定消息是否能发到 B 据点的无线电设备上。这时，B 点的人收到你的消息，回复了你，但此时 B 据点的人无法确认你是否能够收到消息。你收到消息后，回复了他们。这时候，A 和 B 之间就算是建立了一条连接了，但本质上，你和 B 点的人都知道，自己能够连接到对方，这种连接状态是你们两个各自维持的。

但现在有个问题，也就是客户端是如何定位到服务器的？我们应该是提前知道服务器的 ip 地址和端口号的。比如我要访问某个网站，那么我肯定会知道这个网站的网址，通过这个网址，经过 DNS 解析，可以知道其网站服务器的 ip 地址。那么客户端又是如何确定与服务器的哪个端口号建立连接的呢？在知道了这些信息后，客户端会尝试与服务器进行三次握手建立连接。