带你10分钟理解TCP的三次握手和四次挥手

有图有‘真相’：（更好的理解三次握手）
在这里插入图片描述

一、TCP的三次握手

首先来通俗的解释一下TCP的三次握手：

假设A和B是通过短信进行联系的
在这里插入图片描述
第一次(握手)对话：
中午12点，A给B发短信说：“走，去食堂吃饭”。如果此时B没带手机没有接受到短信，那肯定是对话失败的，A等了一会B没回他的短信，他就会自己去吃饭，肯定不会一直等到下午吧。
这说明B没有接受到A的消息时沟通是肯定失败的。
如果B看到A发的消息则说明第一次对话成功。接下来进行第二次对话。
第二次(握手)对话：
B收到并且看到了A发来的消息，但是B是个外国人，他的中文不太好不能理解A所发短信的意思，于是随便回了一句学会的中文：”我爱你“。
A收到之后菊花一紧，心想我只是想和你一起吃饭，你却。。。。这该死的基佬。告辞。于是沟通失败。因为B无法根据A的消息做出正确的应答。
如果B的中文足够好，他看懂了A的消息，并回了一句：”好，那我去老地方等你“，那么第二次握手成功。
通过前两次对话证明了B能够听懂说的话，并且能做出正确的应答。接下来进行第三次对话。
第三次( 握手)对话：
A看到B发的消息：“好，那我去老地方等你”，但是A的妈妈喊他现在立刻马上回家吃饭，A是个听妈妈话的孩子，于是立马回家吃饭了。然后B就等一大半天没看到A回消息就想：怎么还不回我消息，到底去不起啊？不去算鸟。
于是沟通失败，这是因为A无法对B的消息做出正确的应答。
但是如果A看到B发的消息后回复到：“好的，我马上过来”。那么第三次对话成功，两个人就可以开心的一起去吃饭了，并继续聊天啥的进行后续活动。
通过第二次和第三次的对话证明了甲能够听懂乙说的话，并且能做出正确的应答。
可见，两个人进行有效的语言沟通，这三次对话的过程是必须的。
为了保证服务端能收接受到客户端的信息并能做出正确的应答而进行前两次(第一次和第二次)握手，为了保证客户端能够接收到服务端的信息并能做出正确的应答而进行后两次(第二次和第三次)握手。

TCP连接的建立采用客户服务器方式。主动发起连接建立的应用进程叫做客户，而被动等待连接建立的应用进程叫做服务器。

在这个例子中A是客户，B是服务器。
再来看一个问题：为什么要进行三次握手而不是两次呢？
在这里插入图片描述
然后看一个我觉得比较好的解释：

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

然后说一下我自己的理解

因为TCP是面向连接的运输层协议，在应用程序使用TCP协议之前，必须先建立TCP连接。在传输数据完毕后，必须释放已经建立的TCP连接。并且TCP提供的是可靠交付的服务。且TCP提供全双工通信。
所以要进行三次握手来确保在不可靠信道上可靠的传输信息。
至于为什么进行三次握手前面已经给出了一个解释的角度。

再结合上面的例子解释一下：

首先从这个角度理解：三次通信是理论上在不可靠信道上进行可靠通信的最小值.

如果只进行两次握手，即A和B说：“走，去食堂吃饭”。B回复到：“好，那我去老地方等你”。如果这两次就算成功沟通了，那么如果A读不懂B的意思，或者A发生紧急事件（妈妈喊他回家吃饭），那就只剩B一个人去老地方等A等一大半天A都不来，然而B是一个守信用的人，心想：说好和A一起到老地方吃饭的A不来我就不吃。。。。于是这就浪费了B大把的时间。

在从另一个角度理解：这主要是为了防止已经失效的连接请求报文突然又传送到了B，因而产生了错误。

比如说，A中午12点给B发消息：“走，去食堂吃饭”。但是消息滞后了6个小时（现实情况基本不会发生，这里假设发生了这种情况），A第一次发的消息滞后了所以A没有收到回复就又重新发了一条，此时B收到了第二条消息建立正确连接一起去吃中饭了。然后到了下午，A中午发的滞后了6个小时的第一条消息（相当于已失效的请求报文段）传到B的手机里（已经是下午6点），如果只进行两次握手的话，B回复了：“好，那我去老地方等你”。这时A收到这条消息心想我没有约你吃饭啊，就没有理他。。B就去食堂等A吃晚饭了。于是又留B在食堂苦等。。浪费时间。。B真可怜。。。

事情大概就是这么个事情，可能不太合理，不过是我理解的比较好的故事了叭。。。

故事终于讲完了，然后再来看看TCP的连接时如何建立的
在这里插入图片描述要想理解这个图首先。。首先得理解那几个字母叭。。SYN,seq,ACK,ack是啥子东西啊？。。。

于是咱们就得看看TCP报文段的首部格式了

在这里插入图片描述 暂时需要的信息有：
把图再放一遍免得上下翻:

最初两端的TCP进程都处于CLOSE(关闭)状态。上图中A主动打开连接，B被动打开连接。
B打开连接后处于LISTEN(监听状态)，- 等待客户的连接请求。
A向B发送请求报文，SYN=1,ACK=0,选择一个初始序号seq=x。
B 收到连接请求报文，如果同意建立连接，则向 A 发送连接确认报文，SYN=1，ACK=1，确认号为ack= x+1，同时也选择一个初始的序号 seq=y。
A 收到 B 的连接确认报文后，还要向 B 发出确认，确认号为ack= y+1，序号为 seq=x+1。
B 收到 A 的确认后，连接建立。

二、TCP的四次挥手

在这里插入图片描述

数据传输结束后，通信的双方都可释放连接。
此处为A的应用进程先向其TCP发出连接释放报文段，但是A结束TCP连接的时间要比B晚一些。

以下描述不讨论序号和确认号，因为序号和确认号的规则比较简单。并且不讨论 ACK，因为 ACK 在连接建立之后都为 1。

A 发送连接释放报文，FIN=1。
B 收到之后发出确认，此时 TCP 属于半关闭状态，B 能向 A 发送数据但是 A 不能向 B 发送数据。
当 B 不再需要连接时，发送连接释放报文，FIN=1。
A 收到后发出确认，进入 TIME-WAIT 状态，等待 2 MSL（最大报文存活时间）后释放连接。
B 收到 A 的确认后释放连接。

四次挥手的原因

CLOSE-WAIT
客户端发送了 FIN 连接释放报文之后，服务器收到了这个报文，就进入了 CLOSE-WAIT 状态。这个状态是为了让服务器端发送还未传送完毕的数据，传送完毕之后，服务器会发送 FIN 连接释放报文。

TIME-WAIT

客户端接收到服务器端的 FIN 报文后进入此状态，此时并不是直接进入 CLOSED 状态，还需要等待一个时间计时器设置的时间 2MSL。
为什么A在TIME-WAIT状态必须等待2MSL的时间呢？
这么做有两个理由：

为了保证A发送的最后一个ACK报文段能够到达B。
A发送的这个ACK报文段有可能丢失，如果 B 没收到 A 发送来的确认报文，那么A就会重新发送连接释放请求报文，A 等待一段时间就是为了处理这种情况的发生。
防止“已经失效的连接请求报文段”出现在本链接中。A在发送完最后一个ACK报文段后，再经过时间2MSL，就可以使本连接的时间内所产生的所有报文段都从网络中消失。这样下一个新的连接中就不会出现这种旧的连接请求报文段。

为什么建立连接协议是三次握手，而关闭连接却是四次握手呢？
这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的连接请求后，它可以把ACK和SYN(ACK起应答作用，而SYN起同步作用)放在一个报文里来发送。但关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据都全部发送给对方了，所以你可能未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。