TCP协议的相关特性(续)

关于 确认应答 超时重传, 连接管理
请参考: 点击这里

滑动窗口

上图展示了一个固定大小为4个格子的窗口
不断的向前滑动, 每次向前滑动1个格子, 窗口的大小保持不变

---

按数据包进行确认应答

采用逐条发送数据的方式传输数据
这种方式花费了大量时间等待ACK

按滑动窗口方式并行处理

采用批量发送数据的方式传输数据(固定窗口大小)
每次收到一条ACK 就继续发送下一条数据(保持窗口的大小不变, 向前滑动)

通过滑动窗口的方式进行传输数据, 可以提高数据的传输效率

滑动窗口是在批量传输大量数据时, 才会采取的措施
如果数据量较少, 还是会采用逐条发送的方式传输数据

流量控制

滑动窗口的窗口越大, 意味着批量发送的数据越多, 整体的传输速度也就越快

但如果发送的太快, 超出了接收方的接收能力(接收方的接收缓冲区满了)
此时继续发送, 数据就会丢包
这种情况就难免有些得不偿失, 还不如发送的慢些(流量控制)

流量控制的本质就是通过接收方来限制发送方的发送速度

当ACK 为1时(有效状态), 此时的窗口大小(16)位就会生效
窗口大小的值就是接收方建议发送方发送的窗口大小
(接收方将接收缓冲区的剩余空间作为窗口大小)

举个栗子

当发送方发现接收方的接收缓冲区满了之后, 就会暂停发送
但是仍然会每隔一段时间发出一个窗口探测报文
如果探测一会发现接收方的接收缓冲区腾出空间了, 就会继续发送

拥塞控制

如果说流量控制表示的是接收方的处理能力
那么拥塞控制表示的则是传输路径的处理能力

传输路径上任何一个设备的处理能力遇到瓶颈, 都会对整体的传输效率产生影响
而拥塞控制做的就是衡量中间节点的传输处理能力(找出木桶效应中那块最短的木板)

图片来自网络

拥塞控制, 衡量中间节点的传输能力
但每次传输的传输路径不同, 导致了中间路径上的节点个数不同, 每个节点的情况也有可能不同
而且网络的拥堵情况不是一成不变的(可以理解为一天之中不可能所有时间都会出现早高峰)
所以每次通过实验的方式, 找到合适的发送速率

根据上图所示进行实验
●拥塞窗口: 按照多大的速率发送数据(暂时不考虑流量控制的情况)
●传输轮次: 第几次发送(第一次发送, 第二次发送, 第三次发送…)
●慢开始: 刚开始传输, 会给一个非常小的窗口(传输速度较慢)
●指数规律增长: 每次增长的速度翻倍, 增长速度非常快(2 --> 4 --> 8 --> 16 --> 32…)
●ssthresh的初始值: 当指数增长达到阈值时, 就会变成线性增长(避免一下超过上限很多, 采用逐渐达到上限的方式)
●网络拥塞: 当线性增长增长到一定程度(出现丢包), 认为当前的窗口大小达到了上限, 就会在下一轮传输时开启新的慢开始

实验流程描述
(1)先以较低的传输速度开始传输(慢开始)
(2)然后以指数级的增长速度传输
(3)当传输速度达到阈值时, 传输速度就会转变为线性增长(为了避免一下超过上限很多)
(4)当线性增长到一定程度, 会出现丢包的现象(认为当前窗口, 达到当前路径的传输上限)
(5)继续新一轮的慢开始
注意: 下一轮的阈值为上一轮的上限的一半(第二轮慢开始的阈值为第一轮慢开始的上限值的一半)

拥塞窗口(拥塞控制实验出来的窗口)
流控窗口(流量控制产生的窗口)
滑动窗口的大小 = Math.min(拥塞窗口, 流控窗口)

延时应答

读取到数据立即返回ACK, 此时ACK 里面带有的窗口大小设为N
当等待片刻, 再去返回ACK, 此时ACK 里面带有的窗口大小, 大概率＞N
(等待过程中, 应用程序消费接收缓冲区中的数据)

延时应答的效果
就是通过延时, 让接收方的应用程序利用延时的这段时间多读取一些数据
这样返回的ACK 携带的窗口就会大一些, 这样发送方的发送效率就会快一些(仍然满足流量控制)

捎带应答

捎带应答是基于延时应答的一种模式

基于延时应答
此时的 I am fine, thank you(ACK)会稍等一会再发送
就可能会把 And you捎带着一起发送(捎带应答)

面向字节流(粘包问题)

当A 给B 连续发了多个应用层数据报之后
这些数据就累积到B 的接收缓冲区, 紧紧的挨在一起
此时B 的应用程序读取数据时, 就难以区分从哪到哪是一个完整的应用层数据报

举个栗子

同学B
有可能将您看看我是那人吗
理解为(1)您看看我 (2)是那人吗

此时同学B 的接收缓冲区就难以区分从哪到哪是一个完整的应用层数据报

解决方法
(1)定义分隔符(类似于我们将每句话的结尾加上个句号, 代表一句话的结束)
(2)约定长度(类似于约定一句话的最长范围, 超过这个范围, 就不是这句话了)

异常情况

(1)进程关闭 / 进程崩溃

进程虽然没了, 但是连接还在, 仍然可以四次挥手(断开连接)

(2)主机关闭(正常流程关机)

主机关闭会先关闭所有的用户进程
(可能进行完整的四次挥手, 也可能无法进行完整的四次挥手)

a. 进行完整的四次挥手
正常断开连接

b. 未进行完整的四次挥手
比如当对方发送fin, 还未来得及ACK 就关机了
此时对方就会超时重传fin, 重传几次之后, 发现都没有ACK, 就会尝试重置连接
如果还不行, 就会断开连接

(3)主机断电(非正常流程关机)

机器瞬间关闭, 来不及挥手
有两种可能: a. 对方是发送方 b. 对方是接收方

a. 对方是发送方
对方发送fin, 收不到ACK
超时重传fin, 重传几次之后, 发现都没有ACK, 尝试重置连接
如果还不行, 就会断开连接

b. 对方是接收方
对方无法知道发送方是直接没了还是没来的及发送新的数据
于是引出了“心跳包”

心跳包的属性: (1)周期性的 (2)没有心跳了, 表示挂了
于是接收方通过定期给发送方发送心跳包判断接收方是否还存在
如果存在, 等待发送方发送数据
如果不存在, 断开连接

(4)网线断开

这种情况与(3)主机断电相同

总结