目录
0窗口（0号窗口通告）：接收方个发送方发送了一个窗口大小为0的数据，称之为0号窗口通告
一、可靠
确认应答机制：保证数据可靠、有序的到达对端
确认应答机制的背后原理： 本质上是对序号的确认，电脑不知道发的内容是什么，他只认识序号
可靠：
有序：
超时重传机制
当发送方发送时候启动超时重传计时器，当即使的时间超过 “超时重传时间” 之后，还没有收到确认应答，则重传该报文
场景：
超时时间：
能够写成固定时间吗？不能， 要依据网络传输情况进行动态变化
RTO = 2RTT
RTO：超时重传时间
RTT：报文往返时间（根据每次发送数据的时间以及确认回来的时间可以计算出来）
二、效率
TCP需要考虑传输效率的问题，需要从三个方面考虑
1、自身发送数据量，换句话说，一次性发哦是那个的数据越多，传输的越多
MSS：决定了一次性传递的数据的上线（这个没办法更改）
确认应答机制，决定了每一个TCP数据包都说需要确认的（这个可以打破）- 后面说的滑动窗口机制
2、对方的接收能力，换句话说，对方的接收缓冲区的大小
3、网络转发能力，换句话说，从A主机到B主机的网络链路上的转发设备的负载大不大
2.1 提高自身发送数据量
滑动窗口机制：
允许窗口大小的数据（不需要等待上次数据的确认）发送到网络当中进行传输，提高数据吞吐量
优点: 在不考虑网络的情况下， 可以提高发送数据量。 因为发送的越多， 传输的越多
缺点: 需要防备数据丢失的情况， 触发超时重传，一旦触发超时重传，则数据就需要重新发送过去。 也就是意味着发送方在没有接收到确认之前， 是需要将数据缓存起来的 (这个就是TCP的发送缓冲区)
滑动窗口的发送缓冲区是环形队列
滑动窗口的大小会变化吗？
动态变化的
谁在影响滑动窗口的大小呢？
结论：接收方的接收缓冲区的大小在影响滑动窗口的大小
滑动窗口的nb之处
如果收到中间某个分组的确认，即使前面的确认没有收到，也直接按收到处理（确认序号的含义）
也就是说滑动窗口一次性可以滑动很多的距离
滑动窗口丢包问题
1、分组ACK丢失：
2、数据丢失
这里的快充穿不是因为超时重传，而是收到3次重复的确认应答
2.2 对方的接受能力
通过对方的接受能力，来限制发送方发送的数据量
图解：
流量控制机制
场景：
发送方发送了大量的窗口数据（滑动窗口当中的分组数据），被接受方接收了之后，是先缓存在tcp维护的接收缓冲区当中的，由于缓存了大量的数据，会导致接收缓冲区当中的空间急剧减少，所以说，接收方就通过应答当中的窗口大小，去控制发送方的发送数据量
0窗口（0号窗口通告）：接收方个发送方发送了一个窗口大小为0的数据，称之为0号窗口通告
引申含义： 接收方 告诉 发送方自己接受不了了，发送方你别发送数据了
那么什么时候恢复呢？
1、接收方主动发送窗口更新通知（本质上就是发送了一个窗口大小部位0的tcp数据包）
2、发送方发送窗口探测数据包
延时应答机制
接收方接收到数据之后，等待一小会儿，再给发送方回复确认
本质上是为了让接收方应用层程序调用recv从tcp的接收缓冲区将数据读走
2.3 网络转发能力
1.TCP通过滑动窗口来做流控，但是TCP觉得这还不够，
因为滑动窗口需要依赖于连接的发送端和接收端，其并不知道网络中间发生了什么。TCP的设计者觉得，一个伟大而牛逼的协议仅仅做到流控并不够，因为流控只是网络模型4层以上的事，TCP的还应该更聪明地知道整个网络上的事
2、TCP不是一个自私的协议，当拥塞发生的时候，要做自我牺牲。就像交通阻塞一样，每个车都应该把路让出来，而不要再去抢路了
拥塞控制机制： 通过网络拥塞程度，控制tcp的发送数据量
tcp发送数据量 = min（发送窗口，拥塞窗口）
拥塞控制机制有三个阶段：
早期tcp拥塞控制机制的图
现在tcp拥塞控制机制的图
和早期的不同也就是网络拥塞的处理办法，因为早期的网络比较差，而现在的网络拥塞很多只是因为网络闪断而已，不需要降低到那么低就可以了
1、慢开始（启动）
2、拥塞避免
3、拥塞发生时的策略
捎带应答机制
TCP的保活计时器（心跳数据包）
TCP一共有三个计时器： 超时重传计时器， TIME_WAIT计时器 ， 保活计时器
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
