引子
1. TCP报文段
在进入建立TCP连接，即三次握手之前，我们要先了解TCP报文段的首部格式，其中一些字段是必备的知识
不要背着一张图片给吓到，要了解三次握手的过程，我们只需要知道序号，确认号，ACK，SYN即可
-
序号：表示本TCP报文段所发送的数据的第一个字节的序号
-
确认号：表示期望收到对方发送的报文段的数据的第一个序号
-
ACK：确认控制位，这是6个控制位其中一个，通俗来讲，就是当A像B发送报文时，B在接到报文后需要和A说我数据确认到达了，因此ACK=1时确认号字段才有效，注意是确认号字段而不是确认控制位
-
SYN：同步控制位，也是6个控制位中的一个，在建立TCP连接时用来同步序号，当A发给B的报文中SYN=1,ACK=0时，表示这是一个连接请求报文；当B传送给A的报文中SYN=1，ACK=1时，表示这是一个连接接受报文，即B接受了A的连接请求
2. TCP连接建立（三次握手）
TCP是面向连接的协议，因此在传送数据之前需要先建立连接，我们来了解最简单的：连接是如何建立的
-
一开始，A和B都处于关闭状态，A主动打开连接，B被动打开连接，B的TCP服器务进程创建传输控制块TCB，这样B的服务器进程就进入LISTEN（监听）状态，等待客户的请求
-
（第一次握手）A像B发起连接请求，此时A发送的报文首部中的SYN=1，ACK=0，即我们在前面讲过的这是一个连接请求报文，seq就是我们之前介绍的序号，TCP规定SYN报文段不能携带数据，但是要消耗掉一个序号，我们设置为x。这时A进入SYN-SENT（同步已发送）状态
-
（第二次握手）B收到连接请求报文后，如果同意连接，就像A发送连接接收报文段（向A确认），这时发送的报文段首部中SYN=1，ACK=1，表示这是一个连接接收报文段，seq=y，同上面一样，也要消耗一个序号，我们设置为y，ack=x+1，因为上一次收到的是来自A的序号为x的报文，且A的发来报文中没有数据，因此B期望对方发来的下一个报文的序号为x+1。此时B进入SYN-RCVD（同步收到）状态
-
（第三次握手）当A收到B的连接接收报文后，连接理应建立了，可是还存在第三次握手，这个问题我们后面来解答，先看看第三次握手。A向B发送ACK=1，seq=x+1，ack=y+1，经过前面的叙述，这里就很容易理解了，其实就是A向B再发送了一次确认，确认A收到B发出的确认，发出后A进入ESTABLISHED（已建立连接）状态，B收到确认后也进入ESTABLISHED状态
至此，TCP连接的三次握手完成了，其中的关键在于理解我们在前面介绍的几个字段的含义，连接的过程无非就是发送请求与确认请求罢了。
3. 为什么进行第三次握手
在前面我们讲到，我们认为的连接只需要进行一次确认就可以了。但是在TCP连接中却进行了第二次的确认，这是为什么呢？
这里先给出结论，以便大家理解和思考：第三次握手的原因是为了防止已失效的连接请求报文突然传送到了B，而发生错误。
我们先假定我们只进行一次就能完成连接的结论是正确的，即A向B发送连接请求，B向A确认请求，连接建立完成。此时就有可能出现这么一种情况：A向B发送了一个连接请求报文，但是这个请求报文滞留在某一个网络结点处并没有到达B，此时根据重传的机制，A会等待B的确认，超时之后就重传连接请求报文，我们假设重传之后连接建立成功了，并且A，B完成了数据传送最后关闭了连接，这时，之前那个滞留的请求报文突然到达了B，B就会认为A又发起了一次新的连接请求，因此发送确认给A，但是A实际并没有发送请求，因此并不理会B，若我们的假设成立的话，此时连接就已经建立了，B就会一直等待A的数据，B的资源就浪费了。因此我们的假设是不合理的
这种滞留在网络某个结点，隔了很久才到达B的报文就是已失效的连接请求报文
第三次挥手正是为了防止这种情况的发生，当已失效的连接请求报文突然到达B时，并不马上建立连接，而是等待A的确认，若A说：是的我需要建立连接，那么就建立连接，若A啥都不说，B就知道了：噢，这是一个失效的连接请求报文，不需要建立连接