TCP三次握手
有两台机器，A是客户端（主动发起请求的人），B是服务器端（被动接受请求的人），客户端A刚开始没有人和他通讯，所以客户端A的状态是CLOSDE（关闭的），服务器端B刚开始的状态也是CLOSDE，但是总有人去访问他，所以服务器端B开启了LISTEN（收听）状态。
(1)假设A机器想链接B机器了，他就会向B机器发送一个建立链接的请求，这个建立链接请求叫SYN=1，因为要发送一个数据包给B，这个包在A机器里的编号为X，所以seq=x，发送过去之后，A从CLOSED状态转换为SYN-SENT(同步已发送)状态。
(2)A发送过去，B立马就会回应，也会发送一个建立链接的请求，SYN=1（因为B和A以前也没通讯过，要请求和A通讯），B同意了A的建立链接，所以ACK=1，因为B要向A发送一个数据包，这个数据包在B机器里的编号刚好是y，所以seq=y，又因为B确认收到A发送的第X个包，所以B希望收到的下一个包是第x+1个包，所以ack=x+1。发送之后B有LISTEN状态转换为SYN-RCED（同步已收到）状态。
(3)B向A发送了请求，A也会立马回应，同意了B的建立链接，所以ACK=1，A向B发送的是第x+1个包，所以seq=x+1，而A确认收到了B发送的第y个包，希望收到第y+1个包，所以ack=y+1。之后A,B就建立了连接，可以进行数据通讯了，AB的状态也都转换为ESTAB-LISHED(已建立链接)状态。
即使三次握手也有安全隐患，假如A向B发送一个请求，正常来说，B立刻回应，B回应之后并不会马上释放资源，他要等着A回第三次回应，B在等待的过程中会在计算机的内存中记录A发来的请求和自己的回应，假如A发来的是个恶意的请求，一直发第一次请求，而不去发第三次回应，结果造成B把资源都浪费在记录A发送来的第一次请求和自己的回应上面，而迟迟等不来A的第三次回应，导致最终系统所有的资源耗尽，那么B机器对外就不能进行正常访问了。
TCP四次挥手
客户端和服务器端通讯完之后，双方要结束通讯，这就要进行TCP的四次挥手。挥手请求，客户端和服务器端都可以发出。
(1)假如客户端A发出挥手请求（关闭连接），这个挥手请求就是FIN=1,seq=u表示A向B发送一个数据包，这个数据包在A机器里编号为u。A发送完之后就会进入FIN-WAIT1（终止等待）状态。
(2)B接收到A发送的挥手请求之后会立刻回应，确认收到A发送来的挥手请求ACK=1，seq=v表示B向A发送一个数据包，这个数据包在B机器里的编号为v。B确认收到了A发来的第u个包，希望收到的下一个包为第u+1个包，所以ack=u+1。一旦B发送了这个回应之后就马上进入CLOSE-WAIT（关闭等待）状态。而A收到了B的回应之后就会进入TIN-WAIT2（终止等待）状态。
(3)B发出回应只是说明收到了A的挥手请求并不代表同意A挥手请求，有可能B还没传完数据，接着B会传送一些后续的数据包，传送完之后，B也觉得通讯该结束了，就同意了A的挥手请求，接着B也会给A发送一个挥手请求FIN=1,并且同意了A的挥手请求ACK=1，seq=w表示B向A发送一个数据包，这个数据包在B机器里的编号为w。B确认收到了A发来的第u个包，希望收到的下一个包为第u+1个包，所以ack=u+1。B发送挥手请求之后，就会进入LAST-ACK（最后确认）状态。
(4)A收到B发送的挥手请求之后马上回应B，确认收到了B的挥手请求ACK=1，向B发送的数据包编号为u+1，确认收到了B发送的第w个包，希望收到下一个包为第w+1个包。A发送完之后就会进入TIME-WAIT（时间等待）状态，要等待2MSL（最长数据的传输时间），之后就会进入CLOSED状态。而B收到了A的回应之后就会进入CLOSED状态。
有限状态机FSM:Finite State Machine
CLOSED 没有任何连接状态
LISTEN 侦听状态，等待来自远方TCP端口的连接请求
SYN-SENT 在发送连接请求后，等待对方确认
SYN-RECEIVED 在收到和发送一个连接请求后，等待对方确认
ESTABLISHED 代表传输连接建立，双方进入数据传送状态
FIN-WAIT-1 主动关闭,主机已发送关闭连接请求，等待对方确认
FIN-WAIT-2 主动关闭,主机已收到对方关闭传输连接确认，等待对方发送关闭传输连接请求
TIME-WAIT 完成双向传输连接关闭，等待所有分组消失
CLOSE-WAIT 被动关闭,收到对方发来的关闭连接请求，并已确认
LAST-ACK 被动关闭,等待最后一个关闭传输连接确认，并等待所有分组消失
CLOSING 双方同时尝试关闭传输连接，等待对方确认
原创文章，作者：fuming，如若转载，请注明出处：http://www.178linux.com/85723
