TCP 三次握手和四次挥手
三次握手
如图所示，客户端主动打开连接，服务端被动打开连接。连接过程如下：
客户端发送连接请求报文段，同步位
SYN = 1，同时选择一个初始序号seq = x（TCP 协议规定，SYN 报文段，也就是 SYN = 1 的报文段不能携带数据，但是会消耗一个序号），这时客户端进入SYN-SENT（同步已发送）状态。服务端接收到连接请求报文段以后，如果同意连接，则向客户端发送确认。确认报文段中
SYN位和ACK位都置为 1，确认号是ack = x + 1，同时也为自己选择一个初始序号seq = y，服务端进入到SYN-RCVD（同步收到）状态。客户端收到服务端的确认号以后，还要向服务端发送确认。确认报文段的
ACK置 1，确认号ack = y + 1，自己的序号seq = x + 1（TCP 协议规定，ACK 报文段可以携带数据，但是如果不携带数据就不消耗序号，下一个数据报文段的序号仍然是seq = x + 1），这时 TCP 连接已经建立，客户端进入到ESTABLISHED（已建立连接）状态，服务端接收到确认报文后也进入到ESTABLISHED状态。
为什么需要第三次握手？
因为要防止已失效的连接请求报文突然又传送到了服务端，因而产生错误。
如果是两次握手，当客户端发送请求给服务端，但是可能因为网络原因请求没有到达，客户端再次发送请求，然后收到了确认，建立了连接。当数据传输完成后客户端和服务端连接关闭，此时之前那个失效的连接到达了服务端，服务端以为是客户端又发送了一次请求，因此给客户端返回了确认报文，如果是两次握手，那么客户端收到确认报文以后连接就建立了。
如果采用三次连接，服务端发送了响应报文，但是客户端不认识，就拒绝连接，这样连接就不会建立。
四次挥手
如图所示，客户端主动关闭连接，服务端被动关闭：
客户端发送断开连接请求，报文段首部
FIN = 1，序号seq = u（等于前面已经传输过的数据的最后一个字节的序号 +1），这时客户端进入FIN-WAIT-1（终止等待 1）状态，等待服务端的确认。服务端收到连接释放报文段以后发出确认，确认号为
ack = u + 1，这个报文段自己的序号为v（服务端前面已经传送过的数据的最后一个字节的序号 +1），然后服务端进入到CLOSE-WAIT（关闭等待）状态，服务端进程通知上层应用进程，然后客户端到服务端这个方向的连接就释放了，这时 TCP 连接处于半关闭（half-close）状态，即客户端已经没有数据要发送了，服务端如果还有数据要发送，客户端仍然可以接收到。客户端收到服务端的确认后，进入到FIN-WAIT-2（终止等待 2）状态，等待服务端发送释放连接报文段。当服务端没有要发给客户端的数据以后，向客户端发送连接释放报文段，报文段首部
FIN = 1，假定当前服务端的序号为w（在半关闭期间服务端可能又发送有数据），报文还需要加上上次已经发送过的确认号ack = u + 1，这时服务端进入到LAST-ACK（最后确认状态），等待客户端的确认。客户端收到服务端的连接释放报文段以后需要发出确认，在确认报文段中将
ACK置为 1，确认号ack = w + 1，自己的序号seq = u + 1，然后进入到TIME-WAIT（时间等待）状态，此时连接还没有释放，必须经过时间等待计时器设置的时间 2MSL 后（这个时间可能有不同的长度），客户端才进去到CLOSED状态。
为什么客户端在 TIME-WAIT 状态必须等待 2MSL 时间？
为了保证客户端发送的最后一个 ACK 报文段能够到达服务端，处在
LAST-ACK状态的服务端如果一定时间内收不到确认报文，就会超时重传连接释放报文段，如果客户端不等待，那么服务端就无法正常关闭。防止已失效的连接请求报文段，客户端发送完最后一个 ACK 报文段以后，经过时间 2MSL，就可以使本次连接内所有的报文段都从网络中消失，下一次连接就不会出现旧的连接请求报文段。
