TCP恋爱史：三次握手和四次分手
一个应用占用CPU很高，除了确实是计算密集型应用之外，通常原因都是出现了死循环。
以我们最近出现的
TCP协议非常重要，这里把它的连接和释放整理一下。
首先是三次握手：
1、 客户端发起，像服务器发送的报文SYN=1，ACK=0，然后选择了一个初始序号：seq=x。
SYN是干什么用的？
在链接的时候创建一个同步序号，当SYN=1同时ACK=0的时候，表明这是一个连接请求的报文段。如果对方有意链接，返回的报文里面SYN=1，ACK=1,。从这个意义上来说，SYN=1的时候，就表明这是一个‘请求’或者‘接受请求’的报文。
SYN=1的报文段不能携带数据。但是要消耗掉一个序号，
ACK是干什么用的？
仅当ACK=1的时候，确认字号（期望收到对方下一个报文段的第一个数据字节的编号）才有效。因此，TCP规定，当链接建立之后，所有往来的报文里面的ACK都应该是1（事实上，也只有客户端发起的链接请求报文的ACK没有置1）。
现在的状态：客户端进入SYN-SEND状态；
2、 服务器接收到了SYN=1，ACK=0的请求报文之后，返回一个SYN=1，ACK=1的确认报文。
同时，确认号ack=x 1，同时也为自己选择一个初始序号seq=y
现在的状态：服务器进入SYN-REVD状态；
3、 客户端接收到了服务器的返回信息之后，还要给服务器返回最后一条确认，ACK=1，确认号ack=y 1；
现在的状态：客户端进入ESTABLISHED状态。
下面说一下为什么两次握手不行，非得三次：
首先说明一种正常的情况，就是客户端发送了一条请求链接的报文，但是由于网络原因丢失了，所以，不可能接收到服务器端的确认。这个时候，客户端就就只有再一次发送原来的请求报文，这次服务器收到之后返回确认，客户端再确认一次，链接确立。
然后考虑一种不正常的情况，客户端发了两次请求链接的报文，第二条被服务器捕捉到，返回数据，完成了两次握手。数据传送完成之后，链接关闭。但是这时候，第一条拥塞的请求报文现在到达了服务器端，服务器还以为客户端要又一次建立连接，于是发送确认，然后把自己敞开，等着客户端发送过来数据。于是，很多的网络资源就是这样浪费掉了。
要是实行三次握手，服务器收到了一条过期的请求报文，返回确认信息，客户端接收到了服务器的信息之后感到莫名其妙，心想：我他妈又没要链接，你返回这个是不是疯了。于是不置一词。服务器过一段时间还没有收到第三次握手的数据，知道客户端并没有要求建立链接的请求，含泪离开。
然后是四次分手：
现在双方的状态都是ESTABLISHED状态。
1、 客户端发起请求，请求断开链接。FIN=1，seq=u。u是之前传送过来的最后一个字节的序号 1。
FIN：用来释放一个链接，当FIN=1的时候，表明此报文的发送方已经完成了数据的发送，没有新的数据要传送，并要求释放链接。
客户端进入FIN-WAIT-1状态，等着服务器返回确认；
2、 服务器收到客户端的请求断开链接的报文之后，返回确认信息。ACK=1，seq=v，ack=u 1。
服务器进入CLOSE-WAIT状态。
这个时候，客户端不能给服务器发送信息报文，只能接收。但是服务器要是还有信息要传给服务器，仍然能传送。
3、 当服务器也没有了可以传的信息之后，给客户端发送请求结束的报文。FIN=1，ACK=1，
ack=u 1，seq=w。
这个时候的状态：服务器进入LAST-ACK状态。
4、 客户端接收到FIN=1的报文之后，返回确认报文，ACK=1，seq=u 1，ack=w 1。
发送完毕之后，客户端进入等待状态，等待两个时间周期。关闭。
为什么最后还要等待两个时间周期呢？
1、 客户端的最后一个ACK报文在传输的时候丢失，服务器并没有接收到这个报文。这个候。
服务器就会超时重传这个FIN消息，然后客户端就会重新返回最后一个ACK报文，等待两个时间周期，完成关闭。如果不等待这两个时间周期，服务器重传的那条消息就不会收到。服务器就因为接收不到客户端的信息而无法正常关闭。
2、 预防上一次在三次握手中提到的失效的报文干扰。两个时间周期过去之后，所有的报文都会在网络中消失，保证下一次重新连接的时候有乱七八糟的报文影响。
