推荐：
总结——”【互联网】总结——】【Java】总结——】【SpringBoot】参考：
TCP3握手网络——’TCP 3握手、4握手1、3握手2、4握手3、数据传输过程1、超时重传2、高速重传3、流量控制4、拥塞控制4、常见问题1、3握手理由1
序号的描述具体描述了标记seq序号(sequence number )的4字节、32位、数据段的顺序，TCP对连接过程中发送的所有数据字节赋予序号，第一个字节的编号为低为字节指定序列号后，为每个消息段分配序列号。 序列号seq是此消息段第一个字节的数据号。 确认号码(确认号码)为4字节、32位，仅在ACK=1时确认号码字段有效，Ack=Seq 1。 因为期待来自对方的下一个消息段的第一个数据字节的编号，所以当前消息段的最后一个字节的编号1是确认编号。 标记描述具体描述URG紧急指针(urgent pointer )有效。 ACK确认号码是否有效，占1位，ACK=1，确认号码有效。 ACK=0时，确认编号无效。 PSH接收方应该尽快将该消息传递给APP应用层。 RST重置连接SYN开始新连接SYN=1。 这表示连接请求，或者连接接受消息。
表示SYN=1、ACK=0个连接请求消息段。
SYN=1，ACK=1:表示响应消息段，同意连接。
SYN仅在TCP建立生产连接时设置为1，握手完成时SYN标志位设置为0。 FIN (释放连接FIN=1)表示该报文段的发送方的数据已发送，要求释放运输连接1、3次
第一个握手：客户端发送syn标志位和seq num，请求服务器建立连接，客户端状态从关闭更改为syn_send
第二次握手：服务端返回syn和ack标志位、ack num和seq num，确认第一次握手的报文段，返回acknum=seqnum(1 (第一次握手中发送)，同意建立连接，服务器
第三次握手：发送确认消息段，返回ack和acknum=seqnum(2 (第二次握手传输的) 1，客户端状态为) established，服务器返回确认消息段
挥动二、四次手
第一个挥手的：客户端的APP应用程序向服务端发送包含fin标志位的消息，表示要关闭连接，客户端状态从established变为fin-wait-1
第二次挥手，服务器端收到客户端的fin消息，并响应ack消息，通知服务器端的APP应用程序关闭连接。 服务端的状态从established变为关闭等待，客户端收到ack消息后，状态从等待1变为等待2
第三次向：服务器端APP挥手表示可以关闭连接，并向客户端发送fin消息。 服务端的状态从关闭等待变为最后确认
摆动第4次手，客户端接收来自服务端的fin消息，并响应ack消息。 客户端状态从等待时间2更改为等待时间，服务端收到ack消息后关闭直接连接，状态从最后一次访问更改为关闭。 客户端在经过两次最大消息生存时间后关闭连接，并将状态从time-wait更改为closed
三、数据传输过程1、超时重发机制用于保证TCP传输的可靠性。 每次发送数据包时，发送的数据报都有seq编号，接收方接收到数据后，会向ack回复确认收到了某个seq编号的数据。 发送方在发送某个seq分组后，等待一段时间，如果没有对应的ack的回复，则认为信息已经丢失，重新发送该分组。
2、迅速重新发送数据接收方发现数据包不见了。 向发送方发送确认消息，以重新发送丢失的消息。 发送方连续接收相同标签的ack数据包时，会触发客户端的快速重发。
超时重传 VS 快速重传
超时重发(发送方因笨蛋等原因超时后，触发超时进行重发；
高速重发：接收方主动通知发送方未接收到数据，触发发送方重发。
3、流量控制TCP滑动窗口用于流量控制，是提高TCP传输效率的一种机制。
TCP标头包含一个名为窗口和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个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。