写在文章的开头
本文,开始在2017/10/4 10:14,源头是针对网络传输问题的来龙去脉进行理清,问题的描述可能会是彼此关联的。思考该类问题,应该可以彻底理解为什么TCP会这样设计(毕竟我在回答问题的过程中,会有所发现:因为存在这样的问题,而恰好找到这样的设计可以解决);可惜,哪怕在完美的设计也会进一步造成新的问题。所以,问题的描述可能会彼此关联的原因正是如此。
但是,我又在想:书籍上已经讲述得非常好了,我干嘛还要归纳这些东西呢?
我觉得还是按照:根据例程快速学习
的方案比较有效,但网络实在是不一样的东西,你必须要懂网络传输以及出现的问题,才能够解决他们。
不如,从头部开始讲述,像做个PPT一样,不断地填充头部字段,而不同的头部字段正是为了解决某些问题而设定的,所以也是根据接单各个问题的思路。但这就太过繁琐了。
所以,我决定在这里书写了自己对TCP的问题思考,但基本不会提供任何的答案,当然,我会提供一些我当时思考的方面,毕竟我功力不够。
技术总结
TCP技术及其实现方式
- 可靠传输:连续ARQ协议(延迟确认)、RTT超时重传、滑动窗口(多分组确认)
- 连接管理:三次握手、四次挥手、保活机制、TCP有限状态机
- 流量控制:滑动窗口(发送分组数量调节)、延时确认与Nagle算法、大容量缓冲
- 拥塞控制:慢开始和拥塞避免、快重传和快恢复
连续ARQ协议
- ARQ(Automatic Repeat reQuest),纠正通信差错的一种重要方法,构成了许多通信协议的基础
- 重传的请求是自动进行的,接收方不需要请求发送方重传某个出错的分组
延迟确认——累计确认
- 对于乱序、重复,甚至丢失的分组ACK信息来说,不会进行重传,因为延时确认使得确认信息依然生效
- 而延时方面,一定程度上减低网络传输负载
- 但不可以过分推迟,导致不必要的重传(有专门的算法处理)
滑动窗口的“特别”解析
- 是TCP协议的精髓所在
- ”滑动“两字的意义在于:
- 窗口在发送/接收端都是可以根据分组状态进行“滑动”
- 窗口的大小是可以进行调节的
- 对于乱序、重复分组、确认分组来说,实现可靠传输;对于可调节大小的窗口来说,实现流量控制和拥塞控制
辨析角度(流量控制and拥塞控制)
- (端到端角度)流量控制——拥塞控制(网络系统角度)
- 流量控制:让发送方的发送速率不要太快,要让接收方来得及接收
- 拥塞控制:防止过多的数据注入网络中,使网络中的路由器或链路不致过载
以上基本就是TCP的一些理解,在展开问题讲述之前,我觉得需要理解
TCP网络应用的基本类型。
- 交互式应用:数据量小、响应速度要求迅速、少于10%
- 批量数据传输:数据量大、传输速度尽可能快、多于90%
不同的应用,对传输性能有不同的要求,导致了不同的调节参数,意味着TCP采用了不同的算法实现。
TCP解决问题的来源
根本在于:IP是尽力交付服务,TCP是可靠传输,所以TCP需要纠正IP无法修复的错误,从而确保可靠传输
正文
本质,也是唯一目的:实现可靠传输
但息理论和编码理论,证明了信道传输会出错
最简单的方式:发送/接收发现出错,即可:重新发送
<A>重发分组
- 接收方是否接收到了?——ACK确认
- 接收方是否接收到同一个分组?——Sequence序列号(辨别一分组,防止重复)
<B>导致问题
- 发送方对一个ACK应该等待多长时间?——RTT超时重传
- ACK丢失怎么办?——发送方直接重传相同分组——导致A2问题
- 分组被接收,内容出错怎么办?——校验字段(接收方不发送ACK,发送方重发分组)——导致B1问题
到目前为止,已经完成了“可靠”的基本要求。我们称之为:停止等待协议
但这样信道利用率非常低,吞吐量低
然后我们发现,我们可以将多个分组同时注入网络!!!让网络处于繁忙状态
我们称之为:连续ARQ协议
<C>连续ARQ协议——多个分组同时注入网络
- 发送方
- 什么时候发送?一次发送多少个分组?——在滑动窗口内的所有分组都可以同时发送——导致C12和C2所有子问题
- 如何维持每个分组的ACK等待时间?——为每个分组建立一个RTT计时器
- 如何保留没有确认的分组的副本以便重传?——
- 发送端的分组窗口分三部分
- <左边>已发送且已确认
- <中间>已发送但未收到确认、允许发送但未发送
- <右边>不允许发送
- 不断舍弃<左边>的副本,<中间>全部保留副本
- 发送端的分组窗口分三部分
- 接收方
- 对于每个分组的ACK,如何区分是否确认?——延迟确认——导致C12、C13问题
- 如何维护“次序杂乱”的分组?——
- 同样建立接收端的分组窗口
- <左>已发送确认
- <中>未按序收到、允许接收
- <右>不允许接收
- 不断往<右>移动,增加<左>的数量
- 同样建立接收端的分组窗口
- 接收速率比发送速率要慢怎么办?——收发双发,协调滑动窗口大小
- 中间路由器,网络基础设备处理不了发送与接收想要使用的数据怎么办?——发送端根据网络的拥塞情况,协调发送窗口大小
我们之前通过”停止等待协议“,很好地实现了可靠;
但目前为了提升吞吐量,又面临了这么多问题。
问题总是一个接一个,而且是相互关联的。我理解为:问题的诱因存在相关性。
我们还漏了回答一个重要技术:RTT超时重传
比较特别的一点,超时重传,都是针对发送方而言。
RTT超时重传——实时测量RTT,估算RTO
- RTO过小,引起报文不必要的重传,增加网络负载(还没到达的ACK就被误认为超时,分组被重传)
- RTO过大,网络的空闲时间增大,降低传输效率(发送方等待ACK时间变长了,滑动窗口移动变慢,发送速率下降)
到了这里,基本理清了TCP设计的原理和问题来源。