三次握手

三次握手建立连接：SYN建立连接请求

第一次握手：
Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Client进入SYN_SENT状态，等待Server确认。
第二次握手：
Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，并将该数据包发送给Client以确认连接请求，Server进入SYN_RCVD状态。
第三次握手：
Client收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入ESTABLISHED状态，完成三次握手，随后Client与Server之间可以开始传输数据了。
目的：确定通路是否畅通

为什么需要三次握手，两次不行吗？

其实这是由TCP的自身特点可靠传输决定的。客户端和服务端要进行可靠传输，那么就需要确认双方的接收和发送能力,不然容易出现丢包的现象

第一次握手: 可以确认客服端的发送能力
第二次握手: 可以确认服务端的接收能力 和 发送能力
第三次握手: 可以确认客户端的接收能力。

1.问题：为什么连接的时候是三次握手，关闭的时候却是四次握手？
答：因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，”你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。

2.为什么不能用两次握手进行连接？
把三次握手改成仅需要两次握手，可能发生死锁。作为例子，考虑计算机Client端和Server端之间的通信，假定Client端给Server端发送一个连接请求分组，Server端收到了这个分组，并发 送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，Client端在Server端的应答分组在传输中被丢失的情况下，将不知道Server端是否已准备好，不知道Server端建立什么样的序列号，Client端甚至怀疑Server端是否收到自己的连接请求分组。在这种情况下，Client端认为连接还未建立成功，将忽略服务器端发来的任何数据分组，只等待连接确认应答分组。而服务器端在发出的分组超时后，重复发送同样的分组，这样就形成了死锁。