三次握手的过程：
第一次握手
客户端向服务器端发送请求报文：SYN=1,ACK=0,seq=x，发送完毕后，客户端进入SYN-SENT状态；
- SYN=1,ACK=0表示为连接请求报文；
- x为客户端字节流的初始序列号；
- SYN=1的报文不能带有数据部分，但需要消耗一个序列号。
第二次握手
服务器端收到客户端的连接请求报文，服务器端向客户端发送应答：SYN=1,ACK=1,seq=y,ack=x+1，发送完服务器进入SYN-REVD状态；
- SYN=1,ACK=1表示该报文为同意连接的报文；
- seq=y表示发送者发送字节流的初始序列号；
- ack=x+1表示希望对方下一个数据包发送从序号x+1开始的字节流。
第三次握手
客户端在收到同意连接的报文之后，还要向服务器端发送一个确认报文，表示我已近收到了服务器同意连接的报文：SYN=0,ACK=1,seq=x+1,ack=y+1，发送完客户端进入ESTABLISHED状态。
第三次握手已经可以携带数据
同时打开(simultaneous open)
服务器端和客户端同时对双发的端口发起连接，几乎同时发起SYN报文进入SYN-SENT，双方在收到SYN报文，回复ACK报文进入SYN_REVD，双方在收到ACK报文后进入ESTABLISHED。
四次挥手
客户端和服务器端需要发4个包以确定连接的断开，客户端和服务器端均可发起，一个方向连接的断开需要2次，因此总共需要4次
第一次挥手
客户认为数据已经传送完毕，需要释放连接，因此向服务器发送连接释放请求：FIN=1,seq=u，发送完毕后进入FIN-WAIT-1.
- FIN=1表示该报文是一个连接释放报文；
- seq=u-1是数据最后一个字节的序号。
第二次挥手
服务器收到客户端发送的释放报文，会通知响应的程序表示客户端已无数据发送，需要关闭客户端->服务器的连接，并想客户端发送连接释放的应答：ACK=1,ack=u+1,seq=v，发送完毕后进入CLOSE-WAIT状态，此时，服务器仍可以往客户端发送数据。
- ACK=1，表示这是一个应答报文；
- ack=u+1，表示前u字节的数据已经收到；
- seq=v，表示服务器端该次发送数据的起始字节为v。
客户端收到连接释放确认报文后，进入FIN-WAIT2状态，等待服务器的连接释放请求。
第三次挥手
服务器发发完数据并打算断开请求，向客户端发送连接释放请求：FIN=1, ack=u+1,seq=w，发送完毕后，服务器进入LAST-ACK状态。
第四次挥手
客户端收到服务器端的连接释放请求后，向服务器发送应答：ACK=1,seq=u+1,seq=w+1，发送完毕后，客户端进入TIME-WAIT，并等待2MSL时间，若此时间段内没有再次收到服务器端的重发请求的话，进入CLOSED状态。
服务器在收到客户端发送的应答报文，直接进入CLOSED状态。
由上图看到，TIME-WAIT有3中情况会进入：
①上面讲述的由FIN-WAIT-2进入；
②由CLOSING状态进入：客户端再发送FIN报文后等待服务器的ACK应答报文，此时服务器也正好发起了FIN报文，客户端再收到ACK之前先收到了该FIN报文，客户端再回复ACK报文后进入CLOSING状态，继续等待服务器的ACK报文；（这种情况又称为同时断开(simultaneous close)）
③由TIME_WAIT_1直接进入：服务器端在收到客户端的FIN报文时，同时发送FIN+ACK给客户端，客户端再收到这个FIN+ACK后回复ACK报文，然后直接进入TIME-WAIT状态。
为什么需要三次握手
在不可靠信道上可靠地传输信息
①A向B发起通信，如果B再收到SYN信号之后向A发起SYN+ACK包，如果A不向B响应ACK包，B无法确认A是否收到自己的SYN序列号，也就无法和A就己方的SYN序列号达成一致，因此三次握手其实可以理解成为2次单向通讯。
②为了避免网络中失效的请求连接，还是A->B，如果第一次请求报文在某个节点滞留了很久才到B，此时A和B已经完成了通讯。B会误以为A又发起了一次连接，会回复SYN+ACK，如果没有第三次握手，B在发送完SYN+ACK之后会进入Establish状态，一直等待A端数据；有了第三次握手，A在说到无效的SYN+ACK会丢弃，B由于没有收到最后一个ACK报文，在一段时间内就会认为A无意建立连接，故放弃该连接。
为什么要经过2MSL才进入CLOSED状态
MSL(Maximum Segment Lifetime)，即报文最大生存时间，他是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。RFC 793中规定MSL为2分钟，实际应用中常用的是30秒，1分钟和2分钟等。（IP报文头有一个TTL(Time To Live)，这个值由源端设定但不是指定具体时间，每经过一个节点值减1，当值为0，该报文会被丢弃被节点丢弃，并发送一个ICMP报文给源端。 TTL与MSL是有关系的但不是简单的相等的关系，MSL一定要大于等于TTL）
原因有2：①保证TCP连接能够有效关闭；②保证这次连接的重复报文在网络中消失。
如果A发完应答请求后直接进入CLOSED状态，该应答丢失，B等待超时就会进行重发，此时A已经关闭，会发送RST报文，B收到RST回通知上层，虽然数据没有丢失，但连接却不是正常关闭，这叫异常关闭。
如果A直接CLOSED，此时B又发起了一个新连接，无法保证两方的端口不是和上次一样，如果连接在相同的端口上建立，此时延时的某些数据在新连接建立之后达到目的端，此时新数据和旧数据可能会混淆，造成错误，因此让其等待在2MSL后才进入CLOSED，可以保证本次连接的所有数据都已经到达目的端。（实际应用中，可以设置socket的SO_REUSEADDR选项，使端口无需等待2MSL即可使用，SO_REUSEADDR用于对TCP套接字处于TIME_WAIT状态下的socket，才可以重复绑定使用。）
为什么连接是3次握手，而断开是四次挥手
因为连接的时候，可以将SYN和ACK放在同一个报文发送；而FIN报文仅仅表示对方已经发送完所有数据，我方未必发送完，因此让我方可以后面再发送FIN报文来表示关闭连接。
SYN攻击
通常，服务器会维护一个半连接队列，每一个服务器端收到客户端的SYN包，在回复SYN+ACK之后都会放进这个队列，该队列的每一项都在等待服务器的ACK包，都处于SYN-REVD状态，当服务器收到客户端的ACK包只有，都会从队列中将该连接删除。
SYN攻击就是利用了TCP/IP的这一个特性，客户端伪造大量不存在的IP，想服务器端发送大量的SYN连接请求包，服务器回复SYN+ACK回应包，并等待客户端的确认，由于原地址不存在，服务器会一直重发并超时，这些伪造的连接请求会长时间占满半连接队列，正常的SYN请求会被丢弃，从而引起服务不可用。
TCP Fast Open(TFO)了解一下
它通过握手开始时的SYN包中的TFO cookie来验证一个之前连接过的客户端。如果验证成功，它可以在三次握手最终的ACK包收到之前就开始发送数据，这样便跳过了一个绕路的行为，更在传输开始时就降低了延迟。这个加密的Cookie被存储在客户端，在一开始的连接时被设定好。然后每当客户端连接时，这个Cookie被重复返回。(参考：维基百科)
Linux3.7开始支持打开TFO
Reference
关于作者
限于本人的水平，可能某些地方表达的不太准确，敬请指教。
