TCP简介

TCP，即Transmission Control Protocol，传输控制协议。人如其名，要对数据的传输进行一个详细的控制。

源端口号：表示数据从哪个进程来
目的端口号：表示数据要到哪个进程去
序列号：在建立连接时由计算机生成的随机数作为其初始值，通过SYN包传给接收端主机，每发送一次数据，就累加一次该数据字节数的大小，用来解决网络包乱序的问题。
确认应答号：指下一次期望收到的数据的序列号，发送端收到这个确认应答以后可以认为在这个序号以前的数据都已被正常接收，用来解决不丢包的问题。
6位保留位
6位标志位
- URG：紧急指针是否有效
- ACK：确认号是否有效，该位为1时，确认应答的字段变为有效，TCP规定除了最初建立时的SYN包之外该位必须设置为1。
- PSH：提示接收端应用程序立刻从TCP缓冲区把数据读走
- RST：对方要求重新建立连接，我们把携带RST标识的报文称为复位报文，该位为1时，表示TCP连接中出现异常必须强制断开连接。
- SYN：请求建立连接，我们把携带SYN表示的报文称为同步报文段，该位为1时，表示希望建立连接，并在其序列号的字段进行序列号初始值的设定。
- FIN：通知对方，本端要关闭了，我们称携带FIN标识的报文为结束报文段，该位为1时，表示以后不会再有数据发送，希望断开连接。当通信结束希望断开连接时，通信双方的主机之间就可以相互交换FIN位为1的TCP报文。

字段名称	第一次	第二次	第三次
SeqNo	4070717244	1509144546	4070717245
AckNo	0	4070717245	1509144547
SYN	1	1	0
Ack	0	1	1

确认应答机制

TCP是可靠的传输协议，确认应答机制是TCP保证可靠性的最核心机制！

在确认应答机制中，发送方在发送数据包后会等待接收方发送确认消息。如果发送方在一定的时间内没有收到确认消息，它会认为数据包丢失或发生错误，并会重新发送数据包。接收方通过发送确认消息来告知发送方数据包已成功接受，或者指示需要重发某个数据包。

普通报文：ACK这一位为0
应答报文：ACK这一位为1

特殊情况：如果客户端一次性给服务器发送多条消息，那么浏览器的应答就会产生歧义

在网络上有一种特殊情况，“后发先至”，后发的请求可能先到

因此就会产生上述两种情况。

为了解决上述问题，就可以针对请求和应答报文进行编号！

针对编号就可以很明确的分出是哪个请求的应答。即使出现“后发先至”的情况也没有问题。

而这个编号就对应TCP报文结构中的32位序号和32位确认序号。

32位序号：针对请求数据进行编号
32位确认序号：针对应答（ACK）报文进行编号

注：TCP报文头只能存一个序号，存的是最后一个字节的序号，是根据报文长度来算的

上述数据的传输过程也不是一帆风顺的，可能出现丢包，如果丢包，这就需要TCP的超时重传机制了。

超时重传

超时重传是当发送方发送数据包后，如果在一定的时间内未收到接收方的确认消息（ACK），发送方会认为数据包可能丢失或发生错误，并会重新发送该数据包。

超时重传的工作原理如下：

发送方发送数据包后，等待接收方的确认消息。
如果在设定的时间内，发送方未收到接收方的确认消息，就会认为数据包丢失或发生错误。
发送方会重新发送相同的数据包
接收方收到重复的数据包时，会丢弃重复数据包，并发送之前已接收到的最后一个正确的确认消息
发送方在收到接收方的确认消息后，继续发送下一个数据包。

超时时间如何确定？

一般操作系统中有一个配置项，描述超时时间的阈值。

如果第一次出现丢包，超出时间阈值后，进行重传，第二次的超时时间阈值就会比第一次更长。

如果重传几次依旧无法传输，就会重置TCP连接，如果还是连接不上，就会直接释放连接

超时重传会出现两种情况：

数据包丢了
ACK丢了

对于这两种情况发送方都区分不了这两种情况，对于第二种情况，接收方就会收到重复的数据，但是可以根据序号进行去重

三次握手

三次握手是在TCP协议中建立一个可靠的连接所使用的一种机制，它由发送方和接收方之间进行的三次通信组成，用于确保双方都愿意建立连接，并同步各自的初始序列号。

三次握手类似于打电话：

三次握手的过程本质上是四次数据的交互，只是中间两条数据可以合并到一起

三次握手的步骤：

第一次握手（SYN）：发送方向接收方发送一个带有SYN标志的数据包（SYN包），请求建立连接。发送方会随机选择一个初始序列号，并将它放在SYN包中的序列号字段中发送给接收方。
第二次握手（SYN+ACK）：接收方收到SYN包后，会向发送方发送一个带有SYN和ACK标志的数据包（SYN+ACK包），表示接受建立连接的请求，并回复确认号（ACK）和自己的初始序列号。接收方还会随机选择一个初始序列号，并将它放在SYN+ACK包中的序列号字段中发送给发送方。
第三次握手（ACK）：发送方收到SYN+ACK包后，回向接收方发送一个带有ACK标志的数据包（ACK包），确认接收方的确认号，并发送自己的确认号。接收方收到ACK包后，会确认发送方的确认号，并完成连接的建立。

为什么要建立连接以及建立连接的意义：

检查一下当前的网络情况是否畅通
三次握手也是在检查通信双方的发送能力和接收能力是正常的
三次握手过程中，也在协商一些重要的参数

两个重要的TCP状态：

LISTEN：表示服务器正在监听来自客户端的连接请求。服务器在LISTEN状态下，等待客户端发起连接请求。
ESTABLISHED：表示TCP连接已经建立，双方可以进行数据的传输。在ESTABLISHED状态下，双方可以互相发送数据包。

为什么两次握手不行？

阻止重复历史连接的初始化（主要原因）
- 当旧的SYN报文先到达服务端，服务端回一个ACK+SYN报文
- 客户端收到后可以根据自身的上下文，判断这是一个历史连接（序列号过期或超时），那么客户端就会发送RST报文给服务端，表示中止这次连接。
两次握手在收到服务端的响应后开始发生数据，不能判断当前连接是否是历史连接。
同步双方的初始序列号

TCP协议的通信双方，必须维护同一个序列号，序列号是可靠传输的一个关键因素
- 接收端可以去除重复数据
- 接收端可以按照序列号顺序接受
- 标识发送的数据包哪些已经被收到
两次握手只保证了一方的初始序列号能被对方成功接受，没办法保证双方的初始序列号都能被确认接受
避免资源浪费
- 两次握手会造成消息滞留情况下，服务器重复接受无用的连接请求SYN报文，而造成重复分配资源
- 只有两次握手时，如果客户端的SYN请求在网络中阻塞，客户端没有收到服务端的ACK报文，会重新发送SYN
- 由于没有第三次握手，服务器不清楚客户端是否收到了自己发送的建立连接的ACK确认信号，所以每收到一个SYN就只能先主动建立一个连接。

四次挥手

四次挥手是在TCP协议中用于终止一个已建立的连接的机制。他是TCP连接的正常关闭流程，由发送方和接收方之间进行的四次通信组成。

以下是四次挥手的步骤：

第一次挥手（FIN）：发送方向接收方发送一个带有FIN标志的数据包（FIN包），表示发送方已经完成数据的发送，希望关闭连接。发送方不再发送数据，但仍然可以接受数据。
第二次挥手（ACK）：接收方收到FIN包后，向发送方发送一个带有确认号（ACK）的数据包，表示已接收到发送方的关闭请求。接收方仍然可以发送数据。
第三次挥手（FIN）：接收方向发送方发送一个带有FIN标志的数据包（FIN包），表示接收方也希望关闭连接。接收方停止发送数据，但仍然可以接受数据。
第四次挥手（ACK）：发送方收到FIN包后，向接收方发送一个带有确认号（ACK）的数据包，表示已接收到接收方的关闭请求。发送方不再发送数据，也不再接收数据。

两个重要的TCP状态：

CLOSE_WAIT：表示TCP连接的一方已经收到了对方的连接终止请求（FIN包），并发送了确认（ACK）包。在CLOSE_WAIT状态下，接收方等待应用层处理完数据后的连接关闭。
TIME_WAIT：表示TCP连接的一方已经发送了连接终止请求（FIN包），并收到了对方的确认（ACK）包。在TIME_WAIT状态下，发送方等待一段时间后，保持连接状态清理（ACK包没有丢包），并释放资源。

滑动窗口

TCP能保证可靠传输，但失去了效率，为了在保证可靠性的前提下，尽可能的提高效率，就有了滑动窗口机制

滑动窗口是在数据传输中用于流量控制和可靠传输的一种机制。它允许发送方在不等待接收方确认的情况下连续发送多个数据包，提高了传输效率。

在不引入滑动窗口的情况下：

发送方和接收方一应一答，可靠性确实能得到保证，但其实大部分时间都消耗在了等待ACK上了。

因此滑动窗口就是每次批量发送一波消息，然后再等一波ACK，再发一波消息：

如下图所示：

上图中窗口大小是3000，主机A发送了3000字节的数据，主机B需要确认应答，如果第一个ACK成功返回主机A，说明1~1000的数据发送成功，滑动窗口就会向后移动，并发送下一条数据，保证窗口中的数据都是需要确认应答的，或者是没发出去的。

上述过程都是正常情况下，但也发生丢包或者乱序的情况

情况1：数据包到了，但是ACK丢了

如上图第二个ACK丢了，不用做任何处理也没关系，对于可靠传输没有任何影响，右边ack的数字，1001表示1001之前的数据都收到了，2001表示2001之前的数据都收到了，3001表示3001之前的数据都收到了（后者包括前者）。
情况2：数据包丢了

假设1000的数据包丢了，在1000的数据开始丢的时候，主机A并不知道丢了数据，会继续往下发送数据。

主机B会在收到0~~1000的数据前的应答中返回1001，主机A在接收到重复的几次确认后，会重新发送0~~1000的数据，当主机B收到1~~1000的数据后，会把应答数据变成最新的，例如在主机A重发0~~1000的数据前有发了3000~~6000的数据，并没有丢包，在收到0~~1000的数据后，下一次应答的数字就是6001。

流量控制

对于滑动窗口的大小，也不是随意设置的，如果超出接收方的处理速度，就可能会丢失一些数据，那就还得重传这些数据，效率还得不到提升。因此又有了流量控制机制

流量控制是在数据通信中的一种机制，用于控制发送方的数据发送速率，以适应接收方的处理能力，避免数据的丢失或拥塞。

接收方使用接受缓冲区的剩余空间大小来作为发送方速率（滑动窗口大小）的参考数值

例如一个水桶，发送方就是往桶里放水，接收方就是出水。进水和出水的速度，就决定了水位的高低

接收方会在收到发送方的数据后，会在返回的ACK报文中把当前的缓冲区的剩余空间大小反馈给发送方，对应着TCP报文结构中的16位窗口大小。

在TCP报文结构的选项中，有一个用于调整窗口大小的扩展因子，用于跳转滑动窗口的大小，并不是说窗口的大小只能是16位（64KB）

拥塞控制

拥塞控制是用于控制在网络中发生拥塞时的数据传输速率。当网络中的流量过大，导致网络拥塞时，TCP拥塞控制机制会自动减少发送方的数据传输速率，以避免进一步加剧网络拥塞。

流量控制只是考虑接收方的处理速率，但数据的传输还要经过很多的交换机和路由器。因此我们也要考虑这些中间节点的速率。

拥塞控制机制主要包括四个算法：慢启动，拥塞避免、快重传、快恢复
- 慢启动
  
  慢启动算法是在TCP连接建立时，发送方初始的数据传输速率较低，然后逐渐增加发送方的数据传输速率，直到网络出现拥塞为止。
- 拥塞避免
  
  拥塞避免算法是在慢启动阶段结束后，发送方以线性增加的方式增加数据传输速率，以避免过快地增加网络流量。
- 快重传
  
  快重传算法是当接收方收到重复的数据包时，会立即发送一个重复确认，以通知发送方有数据包丢失，从而使发送方能够更快地重传丢失的数据包。
- 快恢复
  
  快恢复算法是在接收到重复确认后，发送方将拥塞窗口减半，然后继续进行拥塞避免算法，以减少网络拥塞的影响
对于流量控制和拥塞控制，本质上都是在控制窗口的大小，在实际中较小的那个作为窗口的大小

 延时应答

延时应答是指在TCP通信中，当一方发送数据给另一方时，接收方需要向发送方发送一个确认应答，表示已经成功接收到数据。延时应答是指接收方在接收到数据后，不立即发送确认应答，而是等待一段时间后再发送确认应答

接收方在收到发送方的数据后，不会立即返回应答，而是接收方先进行一部分数据的处理然后再返回应答给发送方

延时应答的主要作用是为了优化网络传输性能。TCP协议使用了滑动窗口机制，发送方会根据接收方发送的确认应答来确定下一次发送的数据量。如果接收方立即发送确认应答，那么发送方会立即发送下一批数据，造成网络拥塞。而延时应答可以让发送方在一定时间内累积多个数据包，然后一次性发送确认应答，有效减少了网络流量。

捎带应答

捎带应答是指在TCP通信中，接收方发送确认应答时，可以同时携带自己发送的数据。也就是说，在发送确认应答的同时，可以将自己需要发送的数据一起发送出去。

在网络通信中，典型的通信模型是一发一收

在TCP中，只要把数据发送过去，就会立即由内核返回一个ACK报文，响应数据则是由应用程序里进行负责传输

由于上述两个操作是不同时机传输的，原本是不能把这两个操作合并的，但是因为”延时应答“的存在，会等一会儿，因此就把上述两操作合并了

捎带应答的主要目的是为了减少网络传输的延迟和减少网络负载。在TCP通信中，接收方发送确认应答时会占用网络资源，而且会增加延迟。通过捎带应答，接收方可以在发送确认应答的同时，将自己需要发送的数据一起发送给发送方，减少了网络传输的次数和延迟。

面向字节流

面向字节流是指TCP协议在传输数据时将数据视为连续的字节流进行处理，而不是将数据分割成固定大小的块进行传输。

在TCP通信中，发送方将待发送的数据按照字节流的方式发送给接收方，接收方按照相同的字节流方式接受数据，并将数据重新组装成原始的数据块。

在面向字节流中，有一个问题，叫做”粘包问题“

粘包问题是指在TCP通信中，发送方将多个小的数据包连续发送给接收方时，接收方可能会将这些数据包合并成一个大的数据包，导致数据的粘连，造成数据解析错误。

就比如我们看一篇没有标点符号的文章，对于那些字是一句话是有很多看法的，TCP也是如此，无法确定哪些是一个完整的应用层数据包

要想解决”粘包问题“，有两种办法：

通过分隔符，约定某个符号作为包的结束标记
通过指定包的长度，比如在数据包的开头位置声明长度

上述方法在自定义的应用层协议，就有典型的实现：

xml：分隔符就是结束标签
json：分隔符就是 }
protobuf：通过声明长度来确定边界
http：分隔符+长度

TCP的连接异常处理

TCP协议在连接异常处理方面主要涉及以下几个方法：

程序崩溃
正常关机
主机突然关机
网线断开

程序崩溃就是进程异常退出,操作系统会回收进程的资源,包括释放文件的描述符表,相当于调用了socket里的close方法,进而触发FIN报文进行四次挥手

正常关机,系统会强制结束所有进程,那么就和程序崩溃的情况是一样的,进行四次挥手

主机突然关机：

如果是接收方突然关机,发送方并不知道,就会继续发送数据,但发送方收不到ack报文,就会触发超时重传,如果重传几次后,依旧没有应答,就会重置连接,最后放弃连接
如果是发送方突然关机,接收方就只能等着,等一阵之后,就会发送一个”心跳包”,确认连接是否正常

心跳包通常是一个小的数据包，由发送方定期发送给接收方。接收方在收到心跳包后，会立即发送一个确认应答给发送方，表示连接仍然活跃。如果发送方在一定时间内没有收到接收方的确认应答，就可以认为连接已经失效，可以进行相应的处理，如关闭连接或重新建立连接。

网线断开与主机突然关机的处理方式相同,分两种情况处理.