1. TCP协议段格式

在这里插入图片描述

2. TCP原理

2.1 可靠性机制

2.1.1 确认应答

确认应答是实现可靠性的最核心机制
首先来看一个例子，下面是我和女神的对话~
在这里插入图片描述
所以为了解决上述问题呢，就需要针对消息进行编号！给发送的消息分配一个”序号“，同时应答报文，给出”确认序号“

在真实的TCP数据传输中也引入了序号和确认序号

TCP 将每个字节的数据都进行了编号。即为序列号

同时对TCP来说，自身也承担了这个整队的任务，TCP会有一个接收缓冲区（一个内核中的内存空间），每个 socket 都有一份自己的缓冲区。 TCP就可以按照序号针对收到的消息进行整队了。此时就可以确保应用程序读数据，读到的一定是有序的（和发送顺序一样）。

2.1.2 超时重传

网络中会出现一种非常典型的情况：丢包问题
为什么会丢包呢? 因为数据在传输过程中是受到网络的影响的，传输并不是直达的，而是会通过很多中转设备，而每个中转设备都是承担很多的转发任务，每个设备转发能力有限。如果在某一时刻，某个设备，上面的流量达到峰值，就可能引起部分数据被丢包~

发送方对于丢包的判定，是一定时间内，没有收到 ack 报文，分为两种情况：

数据直接丢了，接收方没有收到，自然不会发 ack
接收方收到数据，返回的 ack 丢了
发送方是区分不了这两种情况的，都只能重传！

TCP针对多个包丢失的情况，是继续超时重传，但是没丢包一次，超时等待时间就会增加（重传的频率降低），如果连续多次重传，都无法得到 ack，此时TCP就会尝试重置连接，如果重置连接也无效，TCP就会关闭连接。

如果一切顺利，使用确认应答保证可靠性；出现丢包，则使用超时重传作为补充~

2.1.3 连接管理

TCP建立连接（三次握手），存在的意义：验证了客户端和服务器，各自的发送能力和接收能力是否正常！
TCP断开连接（四次挥手）

2.2 效率机制

2.2.1 滑动窗口

在这里插入图片描述

但是在批量发送的过程中，如果出现了丢包该怎么办？丢包分为两种情况

情况1：数据报到达，ACK丢了
情况2：数据报直接丢了上述重传过程中，没有任何冗余操作！丢了数据才会重传，不丢是不会重传的，整体比较快，这个重传过程也称为 快速重传

滑动窗口，快速重传，是在批量传输大量数据的时候，会采取的措施~
如果只传输一两条，少量的，低频的操作，就不会按滑动窗口这么搞了
仍然是前面朴素的确认应答和超时重传~

2.2.2 流量控制

滑动窗口，批量发送，窗口越大，相当于批量发送的数据越多，整体的速度就越快~ 但是并不是越快越好！
如果你发的太快，瞬间把接收方缓冲区给打满了，接下来的继续发送，此时数据就会丢包

通过流量控制，本质上就是让接收方来限制下发送方的速度，具体如何控制？

上述过程是把返回的窗口大小，当作实际的窗口，实践中可能会有所出入~
发送窗口大小 = 流量控制 + 拥塞控制

2.2.3 拥塞控制

上述中说到，滑动窗口的大小 = 流量控制 + 拥塞控制

流量控制：衡量了接收方的处理能力
拥塞控制：衡量了传输路径的处理能力
实际发送的窗口大小 = min（拥塞窗口，流量控制窗口）

在这里插入图片描述
拥塞控制做的事情，就是衡量中间节点的传输能力。拥塞控制，要衡量中间路径，中间路径上有多少个节点？每个节点当前的情况？甚至，每次传输，走的路径都不同。
通过实验的方式，找到一个合适的发送速率。 开始的时候按照一个小的速率发送，如果不丢包，可以提高下速率（扩大窗口大小）；如果出现丢包，则立即把速率再调小，反复执行上述过程。