TCP三次握⼿、四次挥⼿过程及原理
TCP 协议简述
TCP 提供⾯向有连接的通信传输，⾯向有连接是指在传送数据之前必须先建⽴连接，数据传送完成后要释放连接。 ⽆论哪⼀⽅向另⼀⽅发送数据之前，都必须先在双⽅之间建⽴⼀条连接。在TCP/IP协议中，TCP协议提供可靠的连接服务，连接是通过三次握⼿进⾏初始化的。 同时由于TCP协议是⼀种⾯向连接的、可靠的、基于字节流的运输层通信协议，TCP是全双⼯模式，所以需要四次挥⼿关闭连接。
TCP包⾸部
⽹络中传输的数据包由两部分组成：⼀部分是协议所要⽤到的⾸部，另⼀部分是上⼀层传过来的数据。⾸部的结构由协议的具体规范详细定义。在数据包的⾸部，明确标明了协议应该如何读取数据。反过来说，看到⾸部，也就能够了解该协议必要的信息以及所要处理的数据。包⾸部就像协议的脸。
所以我们在学习TCP协议之前，⾸先要知道TCP在⽹络传输中处于哪个位置，以及它的协议的规范，下⾯我们就看看TCP⾸部的⽹络传输起到的作⽤：
下⾯的图是TCP头部的规范定义，它定义了TCP协议如何读取和解析数据：
TCP⾸部承载这TCP协议需要的各项信息，下⾯我们来分析⼀下：
TCP端⼝号
TCP的连接是需要四个要素确定唯⼀⼀个连接：
（源IP，源端⼝号）+ （⽬地IP，⽬的端⼝号）
所以TCP⾸部预留了两个16位作为端⼝号的存储，⽽IP地址由上⼀层IP协议负责传递
源端⼝号和⽬地端⼝各占16位两个字节，也就是端⼝的范围是2^16=65535
另外1024以下是系统保留的，从1024-65535是⽤户使⽤的端⼝范围
32位序号 seq：Sequence number 缩写seq ，TCP通信过程中某⼀个传输⽅向上的字节流的每个字节的序号，通过这个来确认发送的数据有序，⽐如现在序列号为1000，发送了1000，下⼀个序列号就是2000。
32位确认号 ack：Acknowledge number 缩写ack，TCP对上⼀次seq序号做出的确认号，⽤来响应TCP报⽂段，给收到的TCP报⽂段的序号seq加1。
TCP的标志位
每个TCP段都有⼀个⽬的，这是借助于TCP标志位选项来确定的，允许发送⽅或接收⽅指定哪些标志应该被使⽤，以便段被另⼀端正确处理。
⽤的最⼴泛的标志是 SYN，ACK 和 FIN，⽤于建⽴连接，确认成功的段传输，最后终⽌连接。
1. SYN：简写为S，同步标志位，⽤于建⽴会话连接，同步序列号；
2. ACK： 简写为.，确认标志位，对已接收的数据包进⾏确认；
3. FIN： 简写为F，完成标志位，表⽰我已经没有数据要发送了，即将关闭连接；
4. PSH：简写为P，推送标志位，表⽰该数据包被对⽅接收后应⽴即交给上层应⽤，⽽不在缓冲区排队；
5. RST：简写为R，重置标志位，⽤于连接复位、拒绝错误和⾮法的数据包；
6. URG：简写为U，紧急标志位，表⽰数据包的紧急指针域有效，⽤来保证连接不被阻断，并督促中间设备尽快处理；
TCP 三次握⼿建⽴连接
所谓三次握⼿(Three-way Handshake)，是指建⽴⼀个 TCP 连接时，需要客户端和服务器总共发送3个报⽂。
三次握⼿的⽬的是连接服务器指定端⼝，建⽴ TCP 连接，并同步连接双⽅的序列号和确认号，交换 TCP 窗⼝⼤⼩信息。在 socket 编程中，客户端执⾏ connect() 时。将触发三次握⼿。
三次握⼿过程的⽰意图如下：
第⼀次握⼿：
客户端将TCP报⽂标志位SYN置为1，随机产⽣⼀个序号值seq=J，保存在TCP⾸部的序列号(Sequen
ce Number)字段⾥，指明客户端打算连接的服务器的端⼝，并将该数据包发送给服务器端，发送完毕后，客户端进⼊SYN_SENT状态，等待服务器端确认。
第⼆次握⼿：
数据加密网关服务器端收到数据包后由标志位SYN=1知道客户端请求建⽴连接，服务器端将TCP报⽂标志位SYN和ACK都置为1，ack=J+1，随机产⽣⼀个序号值seq=K，并将该数据包发送给客户端以确认连接请求，服务器端进⼊SYN_RCVD状态。
挠性电路板
第三次握⼿：
客户端收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给服务器端，服务器端检查ack是否为K+1，ACK是否为1，如果正确则连接建⽴成功，客户端和服务器端进⼊ESTABLISHED状态，完成三次握⼿，随后客户端与服务器端之间可以开始传输数据了。
注意：我们上⾯写的ack和ACK，不是同⼀个概念：
氢氧化钙生产⼩写的ack代表的是头部的确认号Acknowledge number， 缩写ack，是对上⼀个包的序号进⾏确认的号，ack=seq+1。
⼤写的ACK，则是我们上⾯说的TCP⾸部的标志位，⽤于标志的TCP包是否对上⼀个包进⾏了确认操作，如果确认了，则把ACK标志位设置成1。
下⾯我⾃⼰做实验，开⼀个HTTP服务，监听80端⼝，然后使⽤Tcpdump命令抓包，看⼀下TCP三次握⼿的过程：
sudo tcpdump -n -t -S -i enp0s3 port 80
第⼀次握⼿，标志位Flags=S
IP 10.0.2.2.51323 > 10.0.2.15.80: Flags [S], seq 84689409, win 65535, options [mss 1460], length 0
第⼆次握⼿，标志位Flags=[S.]
IP 10.0.2.15.80 > 10.0.2.2.51323: Flags [S.], seq 1893430205, ack 84689410, win 64240, options [mss 1460], length 0
第三次握⼿，标志位Flags=[.]
IP 10.0.2.2.51323 > 10.0.2.15.80: Flags [.], ack 1893430206, win 65535, length 0
pcb柔性连接器建⽴连接后，客户端发送http请求
IP 10.0.2.2.51321 > 10.0.2.15.80: Flags [P.], seq 1:753, ack 1, win 65535, length 752: HTTP: GET / HTTP/1.1
tcpdump命令解析⼀下：
-i : 指定抓包的⽹卡是enp0s3
-n: 把域名转成IP显⽰
-t: 不显⽰时间
-S: 序列号使⽤绝对数值，不指定-S的话，序列号会使⽤相对的数值
port: 指定监听端⼝是80
host：指定监听的主机名
我们看下实战中TCP的三次握⼿过程：
第⼀次握⼿，客户端51323端⼝号向服务器端80号端⼝发起连接，此时标志位flags=S，即SYN=1标志，表⽰向服务端发起连接的请求，同时⽣成序列号seq=84689409
第⼆次握⼿，服务端标志位flags=[S.]，即SYN+ACK标志位设置为1，表⽰对上⼀个请求连接的报⽂进⾏确认，同时设置
ack=seq+1=184689410，⽣成序列号seq=1893430205
第三次握⼿，客户端对服务端的响应进⾏确认，所以此时标志位是[.]即ACK=1，同时返回对上⼀个报⽂的seq的确认
号，ack=1893430206
⾄此，三次握⼿完成，⼀个TCP连接建⽴完成，接下来就是双端传输数据了
为什么需要三次握⼿？
我们假设client发出的第⼀个连接请求报⽂段并没有丢失，⽽是在某个⽹络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。
本来这是⼀个早已失效的报⽂段。但server收到此失效的连接请求报⽂段后，就误认为是client再次发出的⼀个新的连接请求。于是就向client发出确认报⽂段，同意建⽴连接。
假设不采⽤“三次握⼿”，那么只要server发出确认，新的连接就建⽴了。由于现在client并没有发出建⽴连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建⽴，并⼀直等待client发来数据。这样，server的很多资源就⽩⽩浪费掉了。
电容式触摸屏结构所以，采⽤“三次握⼿”的办法可以防⽌上述现象发⽣。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建⽴连接。
TCP 三次握⼿跟现实⽣活中的⼈与⼈打电话是很类似的：
三次握⼿：
“喂，你听得到吗？”
“我听得到呀，你听得到我吗？”
“我能听到你，今天 balabala……”
开发运维一体化
经过三次的互相确认，⼤家就会认为对⽅对听的到⾃⼰说话，并且愿意下⼀步沟通，否则，对话就不⼀定能正常下去了。
TCP 四次挥⼿关闭连接
四次挥⼿即终⽌TCP连接，就是指断开⼀个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开。在socket编程中，这⼀过程由客户端或服务端任⼀⽅执⾏close来触发。
由于TCP连接是全双⼯的，因此，每个⽅向都必须要单独进⾏关闭，这⼀原则是当⼀⽅完成数据发送任务后，发送⼀个FIN来终⽌这⼀⽅向的连接，收到⼀个FIN只是意味着这⼀⽅向上没有数据流动了，即不会再收到数据了，但是在这个TCP连接上仍然能够发送数据，直到这⼀⽅向也发送了FIN。⾸先进⾏关闭的⼀⽅将执⾏主动关闭，⽽另⼀⽅则执⾏被动关闭。
四次挥⼿过程的⽰意图如下：
挥⼿请求可以是Client端，也可以是Server端发起的，我们假设是Client端发起：
第⼀次挥⼿： Client端发起挥⼿请求，向Server端发送标志位是FIN报⽂段，设置序列号seq(发送的最
后⼀个字节的序号加1)，此时，Client端进⼊FIN_WAIT_1状态，这表⽰Client端没有数据要发送给Server端了。
第⼆次分⼿：Server端收到了Client端发送的FIN报⽂段，向Client端返回⼀个标志位是ACK的报⽂段，ack设为seq加1，Client端进⼊FIN_WAIT_2状态，Server端告诉Client端，我确认并同意你的关闭请求，此时服务端进⼊close-wait状态，这也是半关闭状态，客户端没有数据要发送了，但是服务端给客户端发送数据客户端还会接收。
第三次分⼿： Server端向Client端发送标志位是FIN，序号为最后⼀次发送数据的最后⼀个字节的序号加1的报⽂段，请求关闭连接，同时服务端进⼊LAST_ACK状态。
第四次分⼿ ： Client端收到Server端发送的FIN报⽂段，向Server端发送标志位是ACK的报⽂段，然后Client端进⼊TIME_WAIT状态。Server端收到Client端的ACK报⽂段以后，就关闭连接。此时，Client端等待2MSL的时间后依然没有收到回复，则证明Server端已正常关闭，那好，Client端也可以关闭连接了。
为什么连接的时候是三次握⼿，关闭的时候却是四次握⼿？
建⽴连接时因为当Server端收到Client端的SYN连接请求报⽂后，可以直接发送SYN+ACK报⽂。其中ACK报⽂是⽤来应答的，SYN报⽂是⽤来同步的。所以建⽴连接只需要三次握⼿。
由于TCP协议是⼀种⾯向连接的、可靠的、基于字节流的运输层通信协议，TCP是全双⼯模式。
这就意味着，关闭连接时，当Client端发出FIN报⽂段时，只是表⽰Client端告诉Server端数据已经发送完毕了。当Server端收到FIN报⽂并返回ACK报⽂段，表⽰它已经知道Client端没有数据发送了，但是Server端还是可以发送数据到Client端的，所以Server很可能并不会⽴即关闭SOCKET，直到Server端把数据也发送完毕。
当Server端也发送了FIN报⽂段时，这个时候就表⽰Server端也没有数据要发送了，就会告诉Client端，我也没有数据要发送了，之后彼此就会愉快的中断这次TCP连接。
为什么要time_wait状态等待2MSL才会进⼊closed状态？
MSL：报⽂段最⼤⽣存时间，它是任何报⽂段被丢弃前在⽹络内的最长时间。
有以下两个原因：
第⼀点：保证TCP协议的全双⼯连接能够可靠关闭：
由于IP协议的不可靠性或者是其它⽹络原因，导致了Server端没有收到Client端的ACK报⽂，那么Server端就会在超时之后重新发送FIN，如果此时Client端的连接已经关闭处于CLOESD状态，那么重发的FIN就不到对应的连接了，从⽽导致连接错乱，所以，Client
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议