2023年7月23日发(作者：)

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是⽤户使⽤的端⼝范围TCP的序号和确认号：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⾸部的序列号(Sequence 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=SIP 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建⽴连接后，客户端发送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.1tcpdump命令解析⼀下：-i : 指定抓包的⽹卡是enp0s3-n: 把域名转成IP显⽰-t: 不显⽰时间-S: 序列号使⽤绝对数值，不指定-S的话，序列号会使⽤相对的数值port: 指定监听端⼝是80host:指定监听的主机名我们看下实战中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端发送完最后的ACK不能直接进⼊CLOSED状态，⽽要保持TIME_WAIT，当再次收到FIN的收，能够保证对⽅收到ACK，最后正确关闭连接。第⼆点：保证这次连接的重复数据段从⽹络中消失如果Client端发送最后的ACK直接进⼊CLOSED状态，然后⼜再向Server端发起⼀个新连接，这时不能保证新连接的与刚关闭的连接的端⼝号是不同的，也就是新连接和⽼连接的端⼝号可能⼀样了，那么就可能出现问题：如果前⼀次的连接某些数据滞留在⽹络中，这些延迟数据在建⽴新连接后到达服务端，由于新⽼连接的端⼝号和IP都⼀样，TCP协议就认为延迟数据是属于新连接的，新连接就会接收到脏数据，这样就会导致数据包混乱。所以TCP连接需要在TIME_WAIT状态等待2倍MSL，才能保证本次连接的所有数据在⽹络中消失。如果已经建⽴了连接，但是客户端突然出现故障了怎么办？

TCP还设有⼀个保活计时器，显然，客户端如果出现故障，服务器不能⼀直等下去，⽩⽩浪费资源。服务器每收到⼀次客户端的请求后都会重新复位这个计时器，时间通常是设置为2⼩时，若两⼩时还没有收到客户端的任何数据，服务器就会发送⼀个探测报⽂段，以后每隔75秒钟发送⼀次。若⼀连发送10个探测报⽂仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。