三次握手，顾名思义就是客户端与服务端进行三次通信。
刚开始客户端处于关闭(Closed)状态，服务器处于监听(Listen)状态。
第一次握手 : 客户端给服务器发送SYN报文，初始的序列号为x，并且需要消耗一个序号。此时客户端进入SYN_SENT状态。
当SYN=而ACK=时，表明这是一个连接请求报文。
注意SYN=1时的报文段是不能携带数据的，因此第一次握手和第二次握手客户端和服务端都不能携带数据。 这是因为如果可以携带数据的话，假如有人想要攻击服务器，只需要每次在第一次握手时在注意SYN=1时的报文段是不能携带数据的，因此第一次握手和第二次握手客户端和服务端都不能携带数据。 这是因为如果可以携带数据的话，假如有人想要攻击服务器，只需要每次在第一次握手时在
第一次握手服务端可以看出 ：客户端的发送能力，和自己的接收能力处于正常状态
第二次握手:服务端收到来自客户端的SYN报文后，对这个SYN报文确认后，会把自己的SYN报文响应给客户端，此时ACK=1表示确认序列号有效，SYN=1也不能携带数据，并且确认号(ack)的值为传来的seq 1，即为x 1，此时初始序号为y。此时服务器进入SYN_RECV状态
第二次握手客户端可以看出：服务端的发送和接收能力都正常，客户端的发送和接收能力也都正常，但重要的一点是服务端不知道客户端的接收能力是否正常。
第三次握手:客户端收到了服务器SYN ACK的包，此时客户端处于ESTABLISHED状态并且客户端和服务端均表示同意连接，因此会发送一个ACK报文，确认号ack的值仍为序列号 1，即y 1，初始seq值为x，所以第二个报文段seq 1，即x 1。
第三次握手可携带数据，不携带数据则不消耗数据
第三次握手可以看出： 客户端的发送接收，服务端的发送接收能力均正常。
两次握手为什么行不通首先举一个生活中常见的例子:
此时你和你的对象拨通了电话(没对象就自己new一个):
你 ：“喂，能听到我说话吗?”
你对象 ：“亲爱的，我可以听到!”
此时你突然不说话了…
试想一下，你(new 的)对象现在肯定怀疑是不是自己的麦克风有问题或者自己的网有问题，导致你听不见…
因此在这里也是如此，仅两次握手，服务端不知道客户端是否能接收到自己给它的通信，所有三次握手是可行的。
另外，三次握手是安全的，并且节约资源
如果客户端发送请求时出现了丢包情况，因为自己没发送，又重新传了一遍，然而等数据传输完成后客户端和服务端都释放了连接，第二次传输的数据在释放连接前给服务器传了过去，但第一次传输的数据假如由于网络原因滞留的时间长了，在释放连接后到达了服务端，这个时候服务端就会误以为客户端又发出了一次新的请求，服务端确认了客户端第一次发出的报文段并同意建立了新的连接，发送报文给客户端，此时服务端会一直等待客户端的答复，而客户端此时正处于释放连接状态，所以导致白白浪费了资源。
半连接队列和全连接队列半连接队列(syn queue)
客户端发送SYN包，服务端收到后回复SYN ACK后，服务端进入SYN_RCVD状态，此时双方还没有完全建立连接，这个时候的socket会放到半连接队列。
全连接队列(accept queue)
当服务端收到客户端的ACK后，socket会从半连接队列移出到全连接队列。当调用accpet函数的时候，会从全连接队列的头部返回可用socket给用户进程。全连接队列中存放的是已完成TCP三次握手的过程，等待被处理的连接，在客户端及服务端的状态均为 ESTABLISHED
