千里之行，基础积累—— 网络编程
TCP连接的三次握手和四次挥手
握手：TCP连接
挥手：TCP断开
三次握手：
首先，三次握手的本质是确认通信双方（Client端、Server端）收发数据的能力；
三次握手其实就是指：建立一个TCP连接时，需要客户端和服务器总共发送3个包，通过这三个请求包，来确认双方（Client、Server）的接收能力和发送能力是否正常，同时，指定自己的初始化序列号为后面的可靠性传送做准备。实质上就是连接服务器指定端口，建立TCP连接，并同步连接双方的序列号和确认号，交换TCP窗口大小信息。
注：刚开始客户端处于 Closed 的状态，服务端处于 Listen 状态。
三次握手理论流程：
-
第一次握手：
客户端将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给服务器端，客户端进入SYN_SENT状态，等待服务器端确认。
-
第二次握手：
服务器端收到数据包后由标志位SYN=1知道客户端请求建立连接，服务器端将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，并将该数据包发送给客户端以确认连接请求，服务器端进入SYN_RCVD状态。
-
第三次握手：
客户端收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给服务器端，服务器端检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，客户端和服务器端进入ESTABLISHED状态，完成三次握手，随后客户端与服务器端之间可以开始传输数据了。
问题1：为什么建立连接是三次握手，四次不可以吗
第一次握手：
? Client什么都不能确认
? Server确认了对方发送正常
第二次握手：
? Client确认：自己发送/接收正常，对方发送/接收正常
? Server确认：自己接收正常 ，对方发送正常
第三次握手：
? Client确认：自己发送/接收正常， 对方发送/接收正
? Server确认：自己发送/接收正常，对方发送/接收正常
问题2：TCP三次握手，如果两次握手会怎么样
设计上的缺陷
有这样一种情况，当A发送一个消息给B，但是由于网络原因，消息被阻塞在了某个节点，然后阻塞的时间超出设定的时间，A会认为这个消息丢失了，然后重新发送消息。
当A和B通信完成后，这个被A认为失效的消息，到达了B
对于B而言，以为这是一个新的请求链接消息，就向A发送确认，
对于A而言，它认为没有给B再次发送消息（因为上次的通话已经结束）所有A不会理睬B的这个确认，但是B则会一直等待A的消息
这就导致了B的时间被浪费（对于服务器而言，CPU等资源是一种浪费），这样是不可行的，这就是为什么不能两次握手的原因了。
所以有了三次握手的修订
第三次握手看似多余其实不然，这主要是为了防止已失效的请求报文段突然又传送到了服务端而产生连接的误判