TCP为什么需要三次握手四次挥手
 
三次握手
 
TCP是通过程序实现的，可靠的，面向连接的协议。而程序是严谨的，每一次建立连接都会进行“三次握手”这样的步骤。
 
建立连接的目的是为了可靠的数据传输。所以需要保证客户端和服务端都能正常的发送或接收数据。
 
如果有一方无法正常发送、接收数据，那么整个数据传输既不可靠也不能成功。
 
所以为什么会需要三次，而不是两次？
 
三次握手流程：
 
1.刚开始客户端和服务端都是关闭状态，服务端会一直处在监听状态，监听是否有建立连接的请求。
 
2.客户端需要建立连接时，会发送确认连接报文，此报文是同步报文SYN=1，同时生产一个随机序列号seq=x,这是第一次握手。
 
第一次握手，客户端发送同步报文到服务端，客户端知道自己有发送数据能力，不知道服务端是否有发送、接受数据能力。
 
3.当服务端接收到连接请求报文时，会发送一个同步报文确认报文，此报文SYN=1，并且ACK=1（大写ACK表示报文为确认报文）,同时服务端也会生成一个随机序列号seq=y，并且将ack设置为x+1(x是客户端发送的同步报文序列号)，确认报文回传给客户端，这是第二次握手。
 
第二次握手，服务端收到同步报文，并回复确认同步报文，此时，服务端知道自己有接收、发送数据能力，并且客服端有发送数据能力，但不知道客户端是否有接收数据能力。
 
4.当客户端收到服务端的ACK报文后，会回复一个ACK确认报文，用于确认确认报文已收到，此报文 ACK = 1，seq = x + 1, ack = y + 1（y是确认报文序列号），这是第三次握手 。
 
第三次握手，当客户端收到确认同步报文后，知道服务端具备发送、接收能力，也知道自己具备，但是服务端只知道客户端具备发送能力，还不知道也有接收能力，所以需要发送确认报文，告诉服务端自己具备接收能力。
 
当三次握手流程结束后，客户端服务端都知道自己和对方具备发送、接收数据能力，建立连接完成，就可以进行数据传输了。
 
所以两次握手是无法满足以上条件的， 因为服务端并不知道客户端是具备接收数据的能力，需要第三次握手，客户端告知服务端自己有接收能力。
 
 
四次挥手
 
三次握手是为了建立可靠的数据传输通道，四次挥手是为了保证等数据传输完再关闭连接，保证双方都达到关闭连接的条件才能断开。
 
四次挥手流程：
 
 
客户端发起 FIN=1 断开连接的报文，携带随机生成的 seq=u，发送给服务端，并且自己处于 FIN-WAIT状态，这是第一次挥手。
 
第一次挥手客户端发起关闭连接的请求给服务端；
 
 
服务端接收到 FIN 报文后，回复一个确认报文，其中 ACK = 1，随机生成一个 seq=v，以及 ack=u+1(u为客户端发送报文的序列号)，这是第二次挥手。
 
第二次挥手：服务端收到关闭请求的时候可能这个时候数据还没发送完，所以服务端会先回复一个确认报文，表示自己知道客户端想要关闭连接了，但需要等待数据传输完；
 
 
当服务端数据发送完了过后，再发送一个 FIN 报文给客户端，通知客户端，服务端准备关闭连接了，此报文 FIN=1，ACK=1，ack=u+1(u为客户端发送报文的序列号)，seq=w，这是第三次挥手。
 
第三次挥手，当数据传输玩，服务端会主动发送FIN报文，告知客户端，标识数据已发送万传给你，服务端准备关闭连接了。
 
 
当客户端收到 FIN 确认报文时再发送一个FIN 的确认报文，其中 ACK = 1，seq = u + 1，ack = w + 1(w为服务端发送报文的序列号)，并进入 TIME-WAIT 状态，当等待 2MSL （ 报文最大生存时间 *2）后关闭连接，这是第四次挥手。
 
第四次挥手，当客户端收到服务端的FIN报文后，会回复ACK报文，告知服务端自己知道了，在等待一会就关闭连接。
 
 
 
疑问：
 
1.为什么握手三次，挥手却要四次？
 
尾音我说的时候没有数据传输，服务端的SYN和ACK报文可以一起发送，但是挥手时有数据传输，ACK和FIN报文不能同时发送，需要分为两步，所以多了一步流程。
 
2.为什么客户端在第四次挥手后还会等待2MSL?
 
等待2MSL是因为保证服务端接收到了ACK报文，因为网络是复杂的，ACk报文可能会丢失，如果服务端没接收到ACK报文的话，会重新发送FIN报文，只有当客户端等待了2MSL都没有收到重新发送的FIN报文时，才表示服务端是正常接收到了ACK报文，这个时候客户端就能关闭了。
 
总结
 
TCP协议是面向连接的可靠的传输层协议，它的拥塞控制，失败重传等机制在互联网数据传输中是不可或缺的。当下互联网行业中，基于TCP实现的程序数不胜数。虽然程序员很少有机会主动编写TCP相关代码，但理解其实现原理，还是有所帮助的。

众所周知，在网络主机数据的交互中普遍使用的是TCP协议进行传输，而tcp最著名的就是三次握手和四次挥手，并分别代表建立连接和断开连接，那为什么却差了一次，今天看博客突然大悟？
 
3次握手
 
一般连接的主动发起者是客户端，当用户访问某个域名后经过DNS解析，拿到目标IP和端口，发起TCP连接（C -> S）
 
C -> S : 客户端向服务端发送报文，表示希望与服务器建立连接
S -> C : 服务器接收到客户端的连接请求，若服务器同意，则向客户端发送同意应答，此时服务器进入等待连接的状态。
C -> S : 客户端收到服务器的同意应答，再次向服务器发送一个数据包，表示客户端已经接收到服务器的同意请求，之后双方建立连接。
 
握手为什么不能两次？
 
防止报文丢失，导致服务器建立多次无效连接。
 假设为2次：若某次客户端发送连接的请求在网络中发送了阻塞，相当于用户点击了某个按钮的功能却没出现效果，一般情况下，绝大部分用户会再次点击该按钮，此时客户端又发送了一次连接请求，服务器收到并同意并建立连接（因为是2次握手，客户端不需要再次确认），此次连接正常进行；但是之前阻塞了那次请求由于网络恢复到达了服务器，服务器认为又来了一个新的请求，于是又建立了一次连接，但是此时的这个连接是无效的。
 
4次挥手
 
假设还是客户端率先请求断开连接，实际上双方都有可能
 
C -> S : 客户端向服务端发送报文，表示希望与服务器断开连接
C -> S : 服务器接收到客户端的断开连接的请求，但是此时服务端极有可能还在传输着数据，服务器对客户端发送报文表示你先别着急，等我数据发送完了我再提醒你。
C -> S : 服务器在某一时间完成的数据交换，再次向客户端发送报文表示你可以断开了
C -> S : 客户端收到服务器的消息，在真正断开前最后向服务器发送报文表示自己收到了服务器同意断开的消息。
 
挥手为什么要4次？
 
所谓三次握手四次挥手最大的不同就是服务器端发送同意 连接/断开 时。
 三次握手用于建立连接，此时双方并未连接；四次挥手用于断开连接，此时双方可能还有正在传输的数据，所以服务端在收到断开请求时并不能第一时间就同意断开，而是等待自己的数据传输完成后再同意。

 
TCP协议三次握手和四次挥手
 
三次握手
如果建立连接只需要2次握手，可能会出现的情况
  
四次挥手
为什么建立连接是三次握手，关闭连接确是四次挥手呢？
TIME_WAIT状态有什么作用，为什么主动关闭方没有直接进入CLOSED状态释放资源？
为什么TIME_WAIT状态需要经过2MSL才能进入CLOSE状态?
 

 
 
三次握手
 
形象比喻
 将小明当作客户端，小红当作服务器端，两人写信告白：
 第一次握手：
 小明告诉小红：我喜欢你。
 第二次握手：
 小红告诉小明：我知道了，我也喜欢你。
 此时小红并不确定小明是否收到了告白信，直到
 第三次握手：
 小明回信：我也知道了，我们在一起吧。此时才真正建立连接。
 
 
标记位
解释
SYN
请求号标记位
ACK
确认号标记位
seq
序号，代表请求方将会发送的数据的第一个字节编号
ack
返回的确认号，代表接收方收到收据后（也就是前面说的seq），代表希望对方下一次传输数据的第一个字节编号
 
状态位
解释
CLOSED
client处于关闭状态
LISTEN
server处于监听状态，等待client连接
SYN-RCVD
表示server接受到了SYN报文，当收到client的ACK报文后，它会进入到ESTABLISHED状态
SYN-SENT
表示client已发送SYN报文，等待server的第2次握手
ESTABLISHED
表示连接已经建立
 
第一次握手：客户端第一次发送一条连接请求数据，SYN = 1，ACK = 0就是代表建立连接请求，发送的具体数据第一个字节编号记为x，赋值seq。
 
 
第二次握手：服务端收到请求后，返回 客户端的SYN = 1,加上自己的确认号ACK=1,发送的具体数据第一个字节编号记为y，赋值seq，希望客户端下一次返回编号x + 1个字节为止的数据，记为ack = x + 1。
 
 
客户端得出客户端发送接收能力正常，服务端发送接收能力也都正常，但是此时服务器并不能确认客户端的接收能力是否正常
 
第三次握手：客户端收到服务端返回的请求确认后，再次发送数据，原封不动返回ACK = 1,这里就不需要再发送 SYN=1了，为什么呢？因为此时并不是跟服务端进行连接请求，而是连接确认，所以只需要返回ACK = 1代表确认，同样的，发送的具体数据第一个字节编号记为seq = x + 1，希望服务端下次传输的数据第一个字节编号记为ack = y + 1
 
为什么TCP建立连接时候，要进行3次握手，2次不行吗？
 一句话的答案：主要目的:防止server端一直等待，浪费资源，
 
如果建立连接只需要2次握手，可能会出现的情况
 
假设client发出的第一个连接请求报文段，因为网络延迟，在连接释放以后的某个时间才到达server 。
 本来这是一个早已失效的连接请求，但server收到此失效的请求后，误认为是client再次发出的一个新的连接请求 。
 于是server就向client发出确认报文段，同意建立连接。
 如果不采用“3次握手”，那么只要server发出确认，新的连接就建立了 。
 由于现在client并没有真正想连接服务器的意愿，因此不会理睬server的确认，也不会向server发送数据 。
 但server却以为新的连接已经建立，并一直等待client发来数据，这样，server的很多资源就白白浪费掉了
 采用“三次握手”的办法可以防止上述现象发生 ，例如上述情况，client没有向server的确认发出确认，server由于收不到确认，就知道client并没有要求建立连接。
 
四次挥手
 
形象比喻
 恋爱之后，小明和小红煲电话粥。依旧将小明当作客户端，小红当作服务器端。小明跟小红说话，
 第一次挥手：
 小明说：我说完了。
 第二次挥手：
 小红说：好的，我知道了，我还没说完。
 小红继续吧啦吧啦，说完之后
 第三次挥手：
 小红告诉小明：我说完了。
 第四次挥手：
 小明收到后告诉小红：好的，我知道了。等了2MSL之后小明挂断了。
 如果此时小红说完，等了2MSL，小明一直不出声，这个时候就会重新说一次：我说完了。直到收到小明最后的回复，才挂断电话。
 
 
状态位： FIN = 1：代表要求释放连接
 
第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。
第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。
第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。
第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手
 
为什么建立连接是三次握手，关闭连接确是四次挥手呢？
 
建立连接的时候， 服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。
 而关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次。为了确保正确关闭连接，所以需要四次。
 
TIME_WAIT状态有什么作用，为什么主动关闭方没有直接进入CLOSED状态释放资源？
 
答：防止连接关闭时四次挥手中的最后一次ACK丢失：如果主动关闭方进入CLOSED状态后，被动关闭方发送FIN包后没有得到ACK确认，超时后就会重传一个FIN包。如果客户端没有TIME_WAIT状态而直接进入CLOSED状态释放资源，下次启动新的客户端就可能使用了与之前客户端相同的地址信息，有两个危害，第一种是这个刚启动的新的客户端绑定地址成功时，就会收到了一个重传的FIN包，对新连接就会造成影响。第二种是如果该新客户端向相同的服务端发送SYN连接请求，但是此时服务端处于LAST_ACK状态，要求收到的是ACK而不是SYN，因此就会发送RST重新建立请求。
 
为什么TIME_WAIT状态需要经过2MSL才能进入CLOSE状态?
 
答：MSL指的是报文在网络中最大生存时间。在客户端发送对服务端的FIN确认包ACK后，这个ACK包有可能到达不了，服务器端如果接收不到ACK包就会重新发送FIN包。所以客户端发送ACK后需要留出2MSL时间（ACK到达服务器器+服务器发送FIN重传包，一来一回）等待确认服务器端缺失收到了ACK包。也就是说客户端如果等待2MSL时间也没收到服务器端重传的FIN包，则就可以确认服务器已经收到客户端发送的ACK包

 
 
推荐：
 
 
总结——》【网络】
总结——》【Java】
总结——》【SpringBoot】
 
 
 
参考：
 
 
TCP 三次握手
 
 


 
网络——》TCP三次握手、四次挥手
 
一、三次握手
二、四次挥手
三、数据传输过程
1、超时重传
2、快速重传
3、流量控制
4、拥塞控制
  
四、常见问题
1、三次握手原因
1）假设只有二次握手
   
2、四次挥手原因
1）假设只有二次挥手
2）假设只有三次挥手
   
3、为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？
4、如果已经建立了连接，但是客户端突然出现故障了怎么办？
 

 
序号
描述
具体描述
seq
序列号（sequence number）
4个字节，32位，标记数据段的顺序，TCP把连接中发送的所有数据字节都编上一个序号，第一个字节的编号由本地随机产生；给字节编上序号后，就给每一个报文段指派一个序号；序列号seq就是这个报文段中的第一个字节的数据编号。
ack
确认号（acknowledgement number）
4个字节，32位，只有ACK = 1时，确认序号字段才有效，Ack=Seq+1。期待收到对方下一个报文段的第一个数据字节的序号，因此当前报文段最后一个字节的编号+1即为确认号。
 
标志位
描述
具体描述
URG
紧急指针（urgent pointer）有效。
ACK
确认序号是否有效
占1位，ACK=1，确认号有效。ACK=0时，确认号无效。
PSH
接收方应该尽快将这个报文交给应用层。
RST
重置连接
SYN
发起一个新连接
SYN=1：表示这是一个连接请求，或连接接受报文。
SYN=1 , ACK=0：表示一个连接请求报文段。
SYN=1，ACK=1：表示一个响应报文段，并且同意连接。
SYN只有在TCP建产连接时才会被置1，握手完成后SYN标志位被置0。
FIN
释放一个连接
FIN=1：表示此报文段的发送方的数据已经发送完毕，并要求释放运输连接
一、三次握手
 
 
 
第一次握手: 客户端发送syn标志位和seq num，向服务器申请建立连接，客户端状态由closed变为syn_send
 
 
第二次握手: 服务端返回 syn和ack标志位，ack num以及seq num，确认第一次握手的报文段，返回ack num=seq num(第一次握手发送的)+1，同意建立连接，服务器状态由listen变为syn_received
 
 
第三次握手: 发送确认报文段，返回ack以及ack num=seq num(第二次握手发送的)+1，客户端状态变为：established(完成连接)， 服务器收到确认报文段，服务器状态由syn_received变为established(完成连接)
 
 
二、四次挥手
 
 
 
第一次挥手: 客户端的应用说要关闭连接，给服务端发送一个含fin标志位的报文，客户端状态由established变为fin-wait-1
 
 
第二次挥手: 服务端收到客户端发来的fin报文，回复ack报文，告知服务端的应用要关闭连接，服务端状态由established变为close-wait，而客户端收到ack报文后，状态由fin-wait-1变为fin-wait-2
 
 
第三次挥手: 服务端应用说可以关闭连接了，给客户端发送fin报文，服务端状态由close-wait变为last-ack
 
 
第四次挥手: 客户端收到服务端发来的fin报文，回复ack报文，客户端状态由fin-wait-2变为time-wait，服务端收到ack报文后，直接关闭连接，状态由last-ack变为closed。客户端经过两次最大的报文存活时间后，关闭连接，状态由time-wait变为closed
 
 
三、数据传输过程
 
1、超时重传
 
超时重传机制用来保证TCP传输的可靠性。每次发送数据包时，发送的数据报都有seq号，接收端收到数据后，会回复ack进行确认，表示某一seq 号数据已经收到。发送方在发送了某个seq包后，等待一段时间，如果没有收到对应的ack回复，就会认为报文丢失，会重传这个数据包。
 
2、快速重传
 
接受数据一方发现有数据包丢掉了。就会发送ack报文告诉发送端重传丢失的报文。如果发送端连续收到标号相同的ack包，则会触发客户端的快速重传。
 
 
 
超时重传 VS 快速重传：
 超时重传：发送端在傻等超时，然后触发超时重传;
 快速重传：接收端主动告诉发送端数据没收到，然后触发发送端重传。
 
 
3、流量控制
 
 
 
TCP滑动窗，用来做流量控制，是提高TCP传输效率的一种机制。
 
 
TCP头里有一个字段叫Window，又叫Advertised-Window，这个字段是接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据，而不会导致接收端处理不过来。
 
4、拥塞控制
 
 
 
流量控制 VS 拥塞控制
 流量控制：只关注发送端和接受端自身的状况，而没有考虑整个网络的通信情况
 拥塞控制：基于整个网络来考虑的
 
 
场景：某一时刻网络上的延时突然增加，那么，TCP对这个事做出的应对只有重传数据，但是，重传会导致网络的负担更重，于是会导致更大的延迟以及更多 的丢包，于是，这个情况就会进入恶性循环被不断地放大。试想一下，如果一个网络内有成千上万的TCP连接都这么行事，那么马上就会形成“网络风 暴”，TCP这个协议就会拖垮整个网络。为此，TCP引入了拥塞控制策略。
 
拥塞策略算法主要包括：慢启动，拥塞避免，拥塞发生，快速恢复。
 
四、常见问题
 
1、三次握手原因
 
(1) TCP连接的特性决定，一次RT(往返)完成一次TCP的动作。
 
客户端一次请求携带的seq num必须得到服务端的ack num才会完成。如果没有返回确认报文段，由于重发机制，定时器经过了一次RTO，客户端就会重发报文。那为什么客户端最后一次发送之后，没有等待服务端发回ack报文段？ 这是因为服务端第二次发送的报文段里 包含ack以及请求syc报文，相当于把确认报文和请求报文合并了，所以最后客户端回复一个ack报文即可。
 
(2) 防止失效的报文创建连接。
 
因为互联网链路是非常复杂的，发送的报文可能会被互联中的网络设备阻塞，经过了一段时间才到达服务器，时间大于了RTO(Retransmission TimeOut)时间，导致客户端重发syc报文(重新创建新的连接，并丢失超时的连接)。如果只有两次握手，那么服务器每接收到syc报文(包括重发的syc报文)，就会创建多余的连接，造成服务器的资源浪费。如果有第三次握手，那么客户端就能够识别出服务端发出的syc和ack报文对应的请求连接在客户端是否存活，如果存活则发送第三次握手ack报文，确认建立连接。
 
1）假设只有二次握手
 
可能发生死锁。例如，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发 送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分 组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。
 
2、四次挥手原因
 
1）假设只有二次挥手
 
客户端发送fin报文，服务端接收fin后，返回ack报文。客户端接收到ack报文后，断开连接。然而服务器还有没有发送完成的报文，当发送数据报文给客户端，发现客户端已经断开连接。比如说你在浏览器输入一个地址后会跟服务端建立连接，服务端会根据TCP把数据分成很多的报文段一一地发送给客户端，在没有全部发送完成之前，客户端在完成二次挥手就断开连接，服务端还没发送完的报文段就会抛客户端失去连接的异常。
 
2）假设只有三次挥手
 
服务端就不能及时地关闭连接，导致连接空闲一段时间，浪费资源。
 
3、为什么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连接。
 
4、如果已经建立了连接，但是客户端突然出现故障了怎么办？
 
TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。