网络——》TCP三次握手、四次挥手

推荐：

• 总结——》【网络】
• 总结——》【Java】
• 总结——》【SpringBoot】
  
  

参考：

• TCP 三次握手

序号	描述	具体描述
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个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。