TCP三次握手四次挥手详解
本文介绍一下TCP的三次握手与四次挥手，以及为什么要如此设计。
1. TCP连接过程
TCP实现原理和为什么需要三次握手？两次握手可不可以？四次握手可不可以？带着这些疑问，我们对此进行一个详细的讲解。
这里，在解释原因之前还是先复习一下TCP的基本知识和三次握手协议。
1.1 什么是TCP协议？
TCP即Transmission Control Protocol，翻译过来就是传输控制协议。TCP协议是一个面向连接的、可靠的、基于字节流的传输协议。
RFC793对TCP连接的定义：
Connections:
The reliability and flow control mechanisms described above require that TCPs initialize and maintain certain status information for each data stream.
The combination of this information, including sockets, sequence numbers, and window sizes, is called a connection.
其大致意思是TCP连接是为了用于保证可靠性和流控制机制的，包括sockets、序列号及窗口大小。
其中socket是由IP加端口组成的，序列号是用来解决乱序问题的，而窗口大小则是用来做流量控制的。
1.2 TCP协议的特性
-
面向连接： 是指TCP是通过服务端和客户端进行连接的协议
-
面向字节流： TCP服务端和客户端之间的数据通讯是通过字节流数据传输的
-
可靠的： 是指TCP服务端与客户端之间的数据传输是很稳定的，即使网络很差的情况，TCP都能保证将数据传输到接收方。
TCP传输的可靠性得益于TCP会记录信息的发送状态，哪些数据收到了，哪些数据没收到，TCP都是会记录的，然后哪些丢包的情况，就是发送不成功的情况，TCP会重新发包，所以TCP的可靠性就是这么保证的。
1.3 TCP三次握手执行流程
TCP的三次握手执行过程是面试中的一个很常见的问题，因为这个问题也是计算机的一个很重要的基础。
TCP三次握手执行过程：
1）首先，服务端和客户端都是处于CLOSED状态的，然后服务端启动，监听端口，状态变为LISTEN（监听）状态；
2）客户端为了请求资源，发送连接，发送同步序列号SYN，此时客户端就变成了SYN-SEND状态
3）服务端接收到客户端请求之后，发送SYN和ACK，然后服务端状态就变成SYN-RCVD状态
4) 客户端接收到信息之后，再次发送ACK，然后变成ESTABLISHED(已确认)状态，服务端接收到返回信息后，状态也变成ESTABLISHED(已确认)状态
1.4 TCP协议为什么需要三次握手？
知道了TCP的三次握手的基本工作原理之后，就可以解释为什么TCP需要三次握手？为什么不设计成两次握手就可以？
原因：避免重复链接
其实在RFC 793 Transmission Control Protocol里就有指出为什么要三次握手的原因：
The principle reason for the three-way handshake is to prevent old duplicate connection initiations from causing confusion.
翻译为中文大致意思是主要原因是为了防止旧的重复连接引起连接混乱问题。
比如在网络环境比较复杂的情况，客户端可能会连续发送多次请求。如果只设计成两次握手的情况，服务端只能一直接收请求，然后返回请求信息，也不知道客户端是否请求成功。这些过期请求的话就会造成网络连接的混乱。
所以设计成三次握手的情况，客户端在接收到服务端SEQ+1的返回消息之后，就会知道这个连接是历史连接，所以会发送报文给服务端，告诉服务端。
所以TCP设计成三次握手的目的就是为了避免重复连接。
然后可以设计成四次握手？五次握手？不可以？
答案是也是可以的，不过为了节省资源，三次握手就可以符合实际情况，所以就没必要设计成四次握手、五次握手等等情况。
2. TCP四次挥手
1）客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
2）服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
3）客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
4）服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
5）客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
6）服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。
3. TCP包的seq和ack号计算方法
序号（seq）用来标识从TCP发端向TCP收端发送的数据字节流，它表示在这个报文段中的的第一个数据字节。如果将字节流看作在两个应用程序间的单向流动，则TCP用序号对每个字节进行计数。序号是32bit的无符号数，序号到达2^32－1后又从0开始。
当建立一个新的连接时，SYN标志变1。序号字段包含由这个主机选择的该连接的初始序号ISN（InitialSequenceNumber）。该主机要发送数据的第一个字节序号为这个ISN加1，因为SYN标志消耗了一个序号。既然每个传输的字节都被计数，确认序号包含发送确认的一端所期望收到的下一个序号。因此，确认序号（ack）应当是上次已成功收到数据字节序号加1。只有ACK标志（下面介绍）为1时确认序号字段才有效。
发送ACK无需任何代价，因为32bit的确认序号字段和ACK标志一样，总是TCP首部的一部分。因此，我们看到一旦一个连接建立起来，这个字段总是被设置，ACK标志也总是被设置为1。
TCP为应用层提供全双工服务。这意味数据能在两个方向上独立地进行传输。因此，连接的每一端必须保持每个方向上的传输数据序号。
3.1 三次握手过程中的序列号
TCP连接的建立是通过三次握手来实现的：
序号 方向 seq ack SYN ACK
----------------------------------------------------------
1 A->B 10000(ISN) 0 1 0
2 A<-B 20000(ISN) 10000+1=10001 1 1
3 A->B 10001 20000+1=20001 0 1解释情况如下：
1: (A) –> [SYN] –> (B)
A向B发起连接请求，以一个随机数初始化A的seq,这里假设为10000，此时ACK＝0
2: (A) <– [SYN/ACK] <–(B)
B收到A的连接请求后，也以一个随机数初始化B的seq，这里假设为20000，意思是：你的请求我已收到，我这方的数据流就从这个数开始。B的ACK是A的seq加1，即10000＋1＝10001
3: (A) –> [ACK] –> (B) A收到B的回复后，它的seq是它的上个请求的seq加1，即10000＋1＝10001，意思也是：你的回复我收到了，我这方的数据流就从这个数开始。A此时的ACK是B的seq加1，即20000+1=20001
3.2 数据传输过程
序号 方向 seq ack 数据长度 数据包长度
---------------------------------------------------------------------------
23 A->B 40000 70000 1460 1514
24 A<-B 70000 40000+1514-54=41460 0 54
25 A->B 41460 70000+54-54=70000 1460 1514
26 A<-B 70000 41460+1514-54=42920 0 54解释：
23：B接收到A发来的seq=40000,ack=70000,size=1514的数据包
24：于是B向A也发一个数据包，告诉A，你的上个包我收到了。A的seq就以它收到的数据包的ack填充，ack是它收到的数据包的seq加上数据包的大小(不包括：以太网协议头=14字节，IP头=20字节，TCP头=20字节)，以证实B发过来的数据全收到了。
25：A在收到B发过来的ack为41460的数据包时，一看到41460，正好是它的上个数据包的seq加上包的大小，就明白，上次发送的数据包已安全到达。于是它再发一个数据包给B。
26：B->A这个正在发送的数据包的seq也以它收到的数据包的ack填充，ack 就以它收到的数据包的seq(70000)加上包的size(54)填充,即ack=70000+54-54(全是头长，没数据项)。通过tcpdump发现确认包ack，确认传输过程中最后字节长度。
参考：TCP-IP详解卷-基础知识 IP TCP UPD 协议
减去54的原因 ，以太网封装格式（链路层使用的是Ethernet II 格式，这个格式有14字节以太网首部+4字节以太网尾部）： 应用数据=size-14-20-20=size-54。（假设IP首部和TCP首部都没有可选选项）
为什么不减去以太网尾部的4字节呢？ 因为在物理层上网卡要先去掉前导同步码和帧开始定界符，然后对帧进行CRC检验，如果帧校验和错，就丢弃此帧。如果校验和正确，就判断帧的目的硬件地址是否符合自己的接收条件（目的地址是自己的物理硬件地址、广播地址、可接收的多播硬件地址等），如果符合，就将帧交“设备驱动程>序”做进一步处 理。这时我们的抓包软件才能抓到数据，因此，抓包软件抓到的是去掉前导同步码、帧开始分界符、FCS之外的数据
3.3 四次挥手过程中的序列号
序号 方向 seq ack FIN ACK
--------------------------------------------------------
1 A->B 80000 90000 1 1
2 A<-B 90000 80000+1=80001 0 1
3 A<-B 90000 80001 1 1
4 A->B 80001 90000+1=90001 0 11：(A) –> [FIN/ACK] –> (B)
客户端A没有要发送给服务端B的数据了，想要关闭链接，则发送一个FIN=1，ACK=1的包，告诉B可以关闭连接了，我没有什么数据要给你了。
2：(A) <– [ACK] <– (B)
然后B会发送ACK=1的包给A，告诉A我知道你没有什么想给我的了，但是我还有数据要给你，你先等下，我先不想FINISH呢。
3：(A) <– [FIN/ACK] <– (B)
等B把数据都发送给A之后，B会再次发送一个包，这次FIN=1，表示我这边也想关闭了，咱俩一起关把。在2和3之间，可能还会有很多B->A的传递，ack均为80001。
4：(A) –> [ACK] –> (B)
然后A回应一个ACK，表示我知道了，一起关吧。B收到这个ACK后，就会CLOSE。但是实际上A不会直接CLOSE，还会进入一个等待时间状态TIME_WAIT，持续2倍的MSL（Maximum Segment Lifetime，报文段在网络上能存活的最大时间）。过了这个状态，才会CLOSE。
为什么要由一个TIME_WAIT阶段呢？原因主要有两个：
1) 保证TCP的全双工连接能够可靠关闭
假如A发送的最后一次ACK丢包了，没有被B收到，那B超时之后，会再次发送一个FIN包，然后这个包被处于TIME_WAIT状态的A收到，A会再次发送一个ACK包，并重新开始计时，一直循环这个过程，直到A在TIME_WAIT的整个过程中都没有收到B发过来的FIN包，这说明B已经收到了A的ACK包并CLOSE了，因此A这时候才可以安心CLOSE。如果A没有TIME_WAIT状态而是直接close，那么当ACK丢包之后，B会再次发送一个FIN包，但是这个包不会被A回应，因此B最终会收到RST，误以为是连接错误，不符合可靠连接的要求。因此需要等待ACK报文到达B。
RST是TCP数据报中6个控制位之一，6个控制位的作用如下：
-
URG 紧急:当 URG=1 时，它告诉系统此报文中有紧急数据，应优先传送(比如紧急关闭)，这要与紧急指针字段配合使用。
-
ACK 确认:仅当 ACK=1 时确认号字段才有效。建立 TCP 连接后，所有报文段都必须把 ACK 字段置为 1。
-
PSH 推送:若 TCP 连接的一端希望另一端立即响应，PSH 字段便可以“催促”对方，不再等到缓存区填满才发送。
-
RST复位:若 TCP 连接出现严重差错，RST 置为 1，断开 TCP 连接，再重新建立连接。
-
SYN 同步:用于建立和释放连接，稍后会详细介绍。
-
FIN 终止:用于释放连接，当 FIN=1，表明发送方已经发送完毕，要求释放 TCP 连接。
2）保证这次连接的重复数据段从网络中消失
如果A直接close了，然后向B发起了一个新的TCP连接，可能两个连接的端口号相同。一般不会有什么问题，但是如果旧的连接有一些数据堵塞了，没有达到B呢，新的握手连接就已经到B了，那么这时候，由于区分不同TCP连接是依据套接字，因此B会将这批迟到的数据认为是新的连接的数据，导致数据混乱（源IP地址和目的IP地址以及源端口号和目的端口号的组合称为套接字，新旧连接的套接字很有可能相同）如果我们终止一个客户程序，并立即重新启动这个客户程序，则这个新客户程序将不能重用相同的本地端口。服务端处于被动关闭，不会出现该状态。
4. 附录
1) 为什么建立连接协议是三次握手，而关闭连接却是四次握手呢？
这是因为服务端的listen状态下的socket当收到SYNC报文的连接请求后，它可以把ACK和SYN(ACK起应答作用，而SYNC起同步作用）放在一个报文里发送。但关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了； 但未必你所有的数据都全部发送给了对方了，所以你可能未必会马上关闭socket，也即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。
2) 为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？
虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。
3) 为什么不能用两次握手进行连接？
3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。
现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发 送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分 组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。
4) 如果已经建立了连接，但是客户端突然出现故障了怎么办？
TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。
[参看]
