目录
核心特性四：滑动窗口（效率机制）
因为TCP的可靠传输会影响传输的效率（多出了一些等待ack的时间，单位时间内能传输的数据就少了），滑动窗口就是让可靠传输对性能的影响少一些。TCP只要引入了可靠性，传输的效率是不可能超过没有可靠性的UDP的。TCP的效率机制就是为了缩短和UDP之间的差距。
那么TCP是如何提升效率的呢？
窗口大小指的是无需等待确认应答而可以继续发送数据的最大值。上图的窗口大小就是4000个字节（四个段）
发送前四段的时候，不需要等待任何ACK，直接发送
收到第一个ACK后，滑动窗口向后移动，继续发送第五个段的数据，依次类推
操作系统内核为了维护这个滑动窗口，需要开辟发送缓冲区来记录当前还有哪些数据没有应答
只有确认应答过的数据，才能从缓冲区删掉
窗口越大，则网络的吞吐率就越高。
如果是2001的 ack 比1001的先到，窗口直接往后走两个格子就可以了
确认序号的含义：该序号之前的数据，都确认收到了。所以2001的先到，意味着1001之前的数据也收到了
如果传输过程中出现丢包怎么办呢？
如果通信双方传输的数据量比较小，也不频繁，就仍然是普通的确认应答和超时重传，如果通信双方传输的数据量比较大，也比较频繁，此时就会进入滑动窗口模式，按照快速重传的方式处理。
通过滑动窗口的方式传输数据，效率会提升，窗口越大，传输效率越高（一段时间等待的ack多了，总的等待时间就少了）
但是滑动窗口并不是越大越好，如果传输速度太快，接收方就可能会处理不过来，进而接收方就会出现丢包，TCP的前提是可靠传输，在可靠性的基础上再提高传输效率。
核心特性五：流量控制（可靠机制）
接收方处理数据的速度是有限的。如果发送方发的太快导致接收方的缓冲区占满，这个时候如果发送方继续发送，就会造成丢包，继而引起丢包重传等等一系列连锁反应。站在接收方的角度，反向制约发送方的发送速度。（发送方的发送速度不应该超过接收方的处理能力）TCP支持根据接收方的处理能力，来决定发送方的发送速度，这个机制就叫做流量控制。
核心机制六：拥塞控制（可靠机制）
虽然TCP有了滑动窗口这个大杀器，能够高效可靠的发送大量的数据。但是如果在刚开始阶段就发送大量的数据，仍然可能引发问题。因为网络上有很多的计算机，可能当前的网络状态就已经比较拥堵。在不清楚当前网络状态下，贸然发送大量的数据，是很有可能引起雪上加霜的。
TCP引入 慢启动 机制，先发少量的数据，探探路，摸清当前的网络拥堵状态，再决定按照多大的速度传输数据。
流量控制是考虑接收方的处理能力，拥塞控制是考虑通信过程中中间节点（路由器交换机）的情况。
由于中间节点结构复杂难以进行量化，所以我们可以使用 " 实验" 来找到一个合适的值。
比如，先让A按照比较低的速度先发送数据，如果传输顺利没有丢包，就再尝试更大的窗口大小来发送数据，随着窗口的大小增大，达到一定程度，中间节点可能会出现问题，此时这个节点就可能会出现丢包，A发现丢包了，就会重新调整窗口大小，如果发现还是丢包，就会继续缩小窗口大小，如果不丢包就尝试增大窗口大小。在这个过程中，发送方不停的调整窗口大小，逐渐达到"动态平衡" 这种做法，相当于是把中间节点都视为"整体" 通过实验的方式找到中间节点的瓶颈。
少量的丢包，我们仅仅是触发超时重传。大量的丢包，我们就认为网络拥塞。当TCP通信开始后，网络吞吐量会逐渐上升。随着网络发生拥堵，吞吐量会立刻下降。拥塞控制，归根结底是TCP协议想尽可能快的把数据传输给对方，但是又要避免给网络造成太大压力的折中方案。
核心机制七：延时应答（效率机制）
A把数据传输给B，B就会立即返回ACK给A（正常情况）
A把数据传输给B，B不会立即返回ACK给A（延时应答）
延时应答本质上是为了提升传输效率，发送方的窗口大小就是传输效率的关键，流量控制是根据接收缓冲区的剩余空间来决定发送速度的，如果有办法让流量控制的窗口大小更大，发送速度就会更快（前提是接收方能处理的过来），延时返回ack给接收方更多的时间来读取缓冲区的数据，读取缓冲区的数据之后，缓冲区的剩余空间就更大了，返回的窗口大小就更大了，传输效率就提高了。
比如说，初始情况下，接收缓冲区剩余空间是10kb，如果立即返回ack那么返回的窗口大小是10kb，如果延时一段时间返回ack，在这个过程中读取了2kb，那么此时返回的窗口大小就是12kb。
窗口越大，网络吞吐量就越大，传输效率就越高。我们的目标是在保证网络不拥塞的情况下尽量提高传输效率。
延时应答一般有两种方式：
- 数量限制：每隔N个包就应答一次；
不会因为ack少了影响可靠性。确认序号，后一个能够涵盖前一个
- 时间限制：超过最大延迟时间就应答一次；
一般传输的数据密集，按第一个
数据稀疏，就按第二个
具体的数量和超时时间，依操作系统不同也有差异；一般N取2,超时时间取200ms；
核心机制八：捎带应答（效率机制）
捎带应答是在延时应答的基础上又进行了效率提升，在网络通信中往往是 "一问一答" 这样的通信模式。
核心机制九：面向字节流
当同时有多个应用层数据包被传输过去的时候就有可能出现粘包问题
粘包问题：
粘的是"应用层数据包"。通过字节流方式传输，很容易混淆包和包之间的边界，从而接收方无法区分从哪里到哪里是一个完整的应用层数据包
那么我们如何解决粘包问题呢？
核心思路：明确应用层数据包之间的边界，①引入分隔符 ②引入长度
核心特性十：异常处理
进程崩溃
进程没了，程序异常终止，文件描述符表也就释放了，相当于是调用了socket.close()，此时会触发FIN，对方收到之后自然就会返回FIN和ACK（正常的四次挥手断开连接）
TCP的连接可以独立于进程存在（进程没了，但是TCP的连接信息还存在，此时四次挥手还是可以在内核中正常进行的）
主机关机（正常情况）
进行关机的时候，就会先触发强制终止进程操作（相当于进程崩溃）此时就会触发FIN，对方收到之后自然就会返回FIN和ACK
主机关机不仅仅是进程没了，整个系统也可能会关闭，如果在系统关闭之前对端返回的FIN和ACK到了，此时系统还是可以返回ACK的，进行正常的四次挥手，如果系统已经关闭，FIN和ACK没收到，就无法进行后续的ACK响应了，站在对端的角度，对端会以为是自己的FIN丢包了，就会重传FIN，重传几次没有响应就会放弃连接（此时会删除对端的信息）
主机掉电（非正常情况）
主机掉电是一瞬间的事情，来不及杀进程，也来不及发送FIN，主机就直接停机了，对端不一定知道这件事。
①如果对端是在发送数据（接收方掉电），发送的数据就会一直等待ACK，触发超时重传，重传达到一定次数，就会触发TCP的重置连接功能：发起 "复位报文段"（TCP结构中的RST）。 RST 同样也没有收到ACK，对端就只能单方面释放连接了
②如果对端是在接收数据（发送方掉电）对端还在等待数据到达，等了很久没有消息，此时是无法区分对端是没有发送消息还是对方出问题了（挂了）此时接收方也会周期性的给对方发起一个特殊的不携带业务数据的数据包（心跳包，RST），如果对方没有应答，重复了多次后任然没有响应，此时就会视为对方挂了，就会单方面释放连接。
网线断开
网线断开和主机掉电相似：
A 发送数据 到 B
站在 A 的视角，就是和刚才上面 "接收方掉电" 是一样的情况
站在 B 的视角，就和刚才上面 "发送方掉电" 是一样的情况
**URG：**紧急指针位（了解）
TCP正常情况下，是按照序号顺序，发送和接收的。紧急指针，相当于"插队"，跳过前面的数据，直接从某个指定的序号来开始read
**PSH：**催促标志位（了解）
发送方给接收方发的数据中带有这个标志位，接收方就会尽快的把这个数据 read 到应用程序中
适用场景：
TCP：可靠传输（大部分场景下，都会优先使用TCP)
UDP：效率更高（对于性能要求高，可靠性要求不高的场景下，使用 UDP)