TCP三次握手四次挥手详解

TCP报文首部每个字段的含义

在分析TCP三次握手四次挥手之前，先了解一下首部中比较重要的字段的含义，这能够加深对TCP三次握手四次挥手的理解。

源端口和目的端口：各占2个字节，分别写入源端口号和目的端口号。标记文本
序号（sequence number）：占4个字节，指的是本报文段所发送的数据的第一个字节的序号(例如：一报文段序号为100，携带的数据为200字节，那么下一次发送的报文段的序号为301)，故该字段也叫做“报文段序号”。序号使用mod运算。TCP是面向字节流的，在一个TCP连接中传送的字节流中的每一个字节都按顺序编号。整个要传送的起始序号必须在建立连接时设置。
确认号（acknowledgement number）：占4个字节，是期望收到对方下一个报文段的第一个数据字节的序号。若确认序号=N,则表明：到序号N-1为止的所有数据都已正确收到。（注意：不要将ack序号和ACK弄混了，ack确认号是用来告诉发送方我已经成功接收到你之前发送的数据，可以发送下一个报文段了，ACK见下面）
紧急URG：当URG=1，表明紧急指针字段有效。这时发送方TCP就把紧急数据插入到本报文段数据的最前面，而在紧急数据后面的数据仍是普通数据。
确认ACK：当ACK=1时，确认字段才有效。当ACK=0时，确认号无效。TCP规定，在连接建立后所有传送的报文段都必须把ACK置1。
推送PSH：接收方TCP收到PSH=1的报文段，就尽快地交付给接收应用进程，而不再等到整个缓存都填满了后再向上交付。
复位RST：当RST=1时，表明TCP连接中出现严重差错，必须释放连接，然后再重新建立运输连接。
同步SYN：在连接建立时用来同步序号。当SYN=1而ACK=0时，表明这是一个连接请求报文段。对方若同意建立连接，则应在响应的报文段中使SYN=1和ACK=1。故SYN置为1，就表示这是一个连接请求和连接接收报文。
终止FIN：用来释放连接。当FIN=1时，表明此报文段的发送方的数据已发送完毕，并要求释放运输连接。
窗口：占2个字节，窗口指的接收窗口，窗口值用来告诉发送方，接收方当前允许他发送的最大数据量。窗口值作为接收方让发送方设置其发送窗口的依据。
检验和：占2字节。检验和字段检验的范围包括首部和数据这两部分。和UDP数据报一样，在计算检验和时，也要在TCP报文段的前面加上12字节的伪首部。伪首部的格式与UDP用户数据报的伪首部一样，但要将伪首部第四个字段中的17 改为6（协议号），把第5字段中的UDP长度改为TCP长度。
紧急指针：占2字节。紧急指针仅在URG=1时才有意义，它指出本报文段中的紧急数据的字节数。

TCP三次握手四次挥手

三次握手

服务端的TCP进程先创建传输控制块TCB，准备接受客户端进程的连接请求，然后服务端进程处于LISTEN状态，等待客户端的连接请求，如有，则作出响应。
（1）第一次握手（客户端请求和服务端建立连接）：客户端向服务器发送报文段，此时首部中SYN=1，ACK=0和seq=x（x为随机数），此时报文段没有携带数据，但是要消耗一个序号，并且TCP客户进程进入SYN-SENT(同步已发送)状态
（2）第二次握手（服务端告诉客户端：我收到了你连接的请求）：服务器在收到客户端发送的请求报文段后，如果同意建立连接，则向客户端发送报文段，首部中SYN=1，ACK=1，seq=y（y为随机数），ack=x+1，这时报文段也不能携带数据，但是要消耗一个序号。这时服务端TCP进程进入SYN-RCVD(同步收到）状态。表示我接收到了你的请求。
（3）第三次握手（客户端告诉服务端：我知道了你同意建立连接）：客户端向服务器发送报文段，首部中确认号ACK=1，序号seq=x+1，确认序号ack=y+1，（客户端在发送报文段后，认为连接已经建立了，当服务端接收到客户端发来的报文段首部中ACK=1后，服务端认为连接已经建立）。
注意：只有当服务端接收到第三次握手的确认号ACK=1时，此时连接才正式的建立。如果第三次握手中客户端发送的ACK包丢了，那么Server 端该TCP连接的状态为SYN-RECV,并且会根据 TCP的超时重传机制，会等待3秒、6秒、12秒后重新发送SYN+ACK包，以便Client重新发送ACK包。 而Server重发SYN+ACK包的次数，可以通过设置/proc/sys/net/ipv4/tcp_synack_retries修改，默认值为5。如果重发指定次数之后，仍然未收到 client 的ACK应答，那么一段时间后，Server自动关闭这个连接。

为什么要进行第三次握手而不是两次？：这主要是为了防止已失效的请求报文段突然又传送到了服务端而产生连接的误判。比 如：客户端发送了一个连接请求报文段A到服务端，但是在某些网络节点上长时间滞留了，而后客户端又超时重发了一个连接请求报文段B该服务端，而后 正常建立连接，数据传输完毕，并释放了连接。但是请求报文段A延迟了一段时间后，又到了服务端，这本是一个早已失效的报文段，但是服务端收到后会误以为客 户端又发出了一次连接请求，于是向客户端发出确认报文段，并同意建立连接。那么问题来了，假如这里没有三次握手，这时服务端只要发送了确认，新的 连接就建立了，但由于客户端没有发出建立连接的请求，因此不会理会服务端的确认，也不会向服务端发送数据，而服务端却认为新的连接已经建立了，并在 一直等待客户端发送数据，这样服务端就会一直等待下去，直到超出保活计数器的设定值，而将客户端判定为出了问题，才会关闭这个连接。这样就浪费了很多服务 器的资源。而如果采用三次握手，客户端就不会向服务端发出确认，服务端由于收不到确认，就知道客户端没有要求建立连接，从而不建立该连接。

为什么客户端和服务器需要随机生成自己的初始序列号？：采用随机产生的初始化序列号进行请求，这样做主要是出于网络安全的因素着想。如果不是随机产生初始序列号，黑客将会以很容易的方式获取到你与其他主机之间通信的初始化序列号，并且伪造序列号进行攻击

四次挥手

数据传输结束后，双方都可以发起释放连接请求，如果是服务器向客户端发起断开连接请求，那么上面的过程要反过来
第一次挥手：客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号+1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
第二次挥手：服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v（等于B前面已经发送的数据的最后一个字节的序号+1），此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
第三次挥手：服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w（在半关闭状态B可能又发送了一次数据)，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
第四次挥手：客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

.为什么“握手”是三次，“挥手”却要四次？

TCP建立连接时之所以只需要"三次握手"，是因为在第二次"握手"过程中，服务器端发送给客户端的TCP报文是以SYN与ACK作为标志位的。SYN是请求连接标志，表示服务器端同意建立连接；ACK是确认报文，表示告诉客户端，服务器端收到了它的请求报文。

即SYN建立连接报文与ACK确认接收报文是在同一次"握手"当中传输的，所以"三次握手"不多也不少，正好让双方明确彼此信息互通。

TCP释放连接时之所以需要“四次挥手”,是因为FIN释放连接报文与ACK确认接收报文是分别由第二次和第三次"握手"传输的。为何建立连接时一起传输，释放连接时却要分开传输？

建立连接时，被动方服务器端结束CLOSED阶段进入“握手”阶段并不需要任何准备，可以直接返回SYN和ACK报文，开始建立连接。释放连接时，被动方服务器，突然收到主动方客户端释放连接的请求时并不能立即释放连接，因为还有必要的数据需要处理，所以服务器先返回ACK确认收到报文，经过CLOSE-WAIT阶段准备好释放连接之后，才能返回FIN释放连接报文。

所以是“三次握手”，“四次挥手”。

为什么最后挥手要等2MSL？

所谓的2MSL是两倍的MSL(Maximum Segment Lifetime最大 报文段存活时间（往返时间）)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。

在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。

1、为了保证可靠的断开TCP的双向连接，确保足够的时间让对方收到ACK包。若客户端回复的ACK丢失，server会在超时时间到来时，重传最后一个fin包，处于TIME_WAIT状态的client可以继续回复Fin包，发送ACK。
2、保证让迟来的TCP报文段有足够的时间被识别和丢弃，避免新旧连接混淆。有些路由器会缓存没有收到的数据包，如果新的连接开启，这些数据包可能就会和新的连接中的数据包混在一起。连接结束了，网络中的延迟报文也应该被丢弃掉，以免影响立刻建立的新连接。