TCP的核心特性精讲（上篇）

TCP/IP是⽹络编程的 理论基础，是⼀个服务器开发程序员的 重要基本功，是整个⽹络课程中的 重点和难点，也是各⼤公司笔试⾯试的 核⼼考点，本章从 基础核心到 十大特性的详细讲解，梳理TCP的重点内容

由于十大特性内容比较多，这边将内容分为上下两篇，上篇主要讲解TCP最核心得两个机制：确认应答和超时重传 加上连接管理，下篇讲解剩下七个机制

一、TCP 的基础核心要素

1. TCP 的协议定位：在哪一层？

在TCP/IP 四层模型中，TCP 位于传输层，上接应用层（如 HTTP、FTP、SSH 等应用协议），下连网络层（IP 协议）

2. TCP 的基本特点

TCP 的基本特点是：有连接、可靠传输、面向字节流、全双工，是底层核心原则，而十大特性（后续详细解析）是这些原则的具体落地设计。

3. TCP协议段格式

这里先讲解容易理解的部分，剩余部分在下文会有详解

二、十大核心特性机制解析

TCP的“可靠性”

TCP的 “可靠性” 通过一系列特性机制，让TCP能够在复杂的网络环境中确保数据的完整性、有序性和准确性。

此处的可靠性，不是说A发消息给B，让B百分百能收到消息，而是让A的消息尽可能让B收到

1. 确认应答

保证可靠性的一个关键前提，是发送方知道自己的数据对方是否能收到，发送方发送数据后，无法确定接收方是否收到，ACK 就是接收方给的 “收据”，告诉发送方 “数据已收到，可继续发下一批”，从而避免数据丢失

举个老师讲过的典型的例子

TCP的处理方案，就是给进行传输的数据进行编号，即为序列号：

一个TCP载荷是由多个字节构成的，序号字段填写载荷部分的第一个字节的序号，
序号在32位序号中是连续的

确认序号把收到的载荷的最后一个字节序号加上1，表示确认应答

在确认应答的机制下，接收方就可以根据序号对数据进行排序，老师先得到1答复后，再得到2的答复，结果是老师理所应当的将要收到好人卡一张

注意：
这里的应答和业务中的响应不是同一个东西
对方“没主动发数据”时，ACK为确认类报文，不会平白无故发ACK—但有个关键场景：ACK本质是“对接收数据的反馈”，只要你给对方发了数据，对方即使没要回传的业务数据，也会发ACK 来确认“收到了你发的内容”。ACK的触发条件是“接收了对方的数据包”，和“自己有没有要发的东西”无关。

2. 超时重传

发送方发完数据后 “计时”，如果超时了还没收到接收方的确认应答（ACK），就默认数据丢了，自动重新发送这部分数据，简而言之就是对丢包的做出处理

因此针对上述的ACK和数据丢失都会进行重传

重传不是无限制的

TCP特性的超时重传，来判断是否丢包，TCP中判断超时的时间阈值，不是固定固定数值，而是动态改变的：

假设当前 A ->B 发送数据,丢包的超时时间阈值为 T当 A 给 B 传输发生超时之后就会延长这个时间阈值
会继续延长这个时间不是无休止的.超时次数达到一定程度/等待时间达到一定程度就认为网络出现严重故障,放弃这一次传输~~

为什么延长这个时间不是无休止的：
假设当前网络丢包概率是 10%,90% 的概率能够到达对方，连续发两个包都丢的概率 1%，至少有一个到达对方的概率 99%，那随着连续发包的次数增多，即使概率加到了很高，还是不能发送成功，那说明网络已经出现了很严重的事故，在怎么传都已经没有什么意义了

针对重复数据问题
TCP协议能够识别出那些包是重复的包,并且把重复的丢弃掉.

3. 连接管理

连接管理由断开连接和建立连接组成，在正常情况下,TCP要经过三次握⼿建⽴连接,四次挥⼿断开连接

1. 三次握手

建立连接是TCP通过“三次握手”的方式来建立的

生活中的握手,打招呼握手操作,没有实际的业务,只是"打个招呼"我发送一个不携带业务的数据,通过这个数据和对方"打个招呼"
三次握手也是一样，三次握手传递的是TCP 协议自身的控制信息，目的是建立可靠连接，是不含有业务数据

“三次握手”是如何建立的

三次握手的全部详细流程

三次握手的目的

1. 三次握手,相当于"投石问路”先初步的探一探网络的通信链路是否通畅.(网络通畅是可靠传输的前提条件)
2. 验证通信双方的发送能力和接收能力是否也正常
3. 三次握手过程中,可以协商一些关键信息

• TCP 要协商的一个非常关键的信息, 通信过程中,序号从几开始初始序号, 一般不是从 0 开始的.并且,两次连接初始序号都是不同的(往往会差别较大),比如第一次连接协商好我们的初始序号为8000，第二次连接，协商好初始序号为10000

2. 四次挥手

TCP 通过四次交互（“挥手”）完成连接断开
本质是双方分别确认 “不再发数据”，确保双向数据都传输完毕

“四次挥手”是如何断开连接

四次挥手的全部详细流程

在四次挥手，谁都可以先FIN，但是实践角度来看,还是客户端断开连接的可能性更大

CLOSE WAIT 正常开发中,应该是看不到的，原则上来说,感知到对方断开之后,就应该尽快的执行 close ,如果你发现服务器这边存在大量的 CLOSE WAIT,持续的还很久,此时意味着你代码大概率有 bug,(检查是否执行到 close 了).

状态等待机制

网络传输中，随时都可能丢包，四次挥手同样也会会存在丢包的情况

为了解决处理B重传问题，A这边必须得等待一段时间，却仍对方是否重传FIN之后再释放，但是具体等待多少时间呢？一般来说等待时间为2 * MSL(网络上任何两个节点传输过程中最大得时间)，MSL通长这个时间被设置为60秒，也就是说TIME-WAIT等待2 * 60秒，但是这个时间不同系统可能不一样，大概认识一下就可以了