[Network]TCP

写在文章的开头

---

    本文，开始在2017/10/4 10:14，源头是针对网络传输问题的来龙去脉进行理清，问题的描述可能会是彼此关联的。思考该类问题，应该可以彻底理解为什么TCP会这样设计（毕竟我在回答问题的过程中，会有所发现：因为存在这样的问题，而恰好找到这样的设计可以解决）；可惜，哪怕在完美的设计也会进一步造成新的问题。所以，问题的描述可能会彼此关联的原因正是如此。

    但是，我又在想：书籍上已经讲述得非常好了，我干嘛还要归纳这些东西呢？

    我觉得还是按照：根据例程快速学习 的方案比较有效，但网络实在是不一样的东西，你必须要懂网络传输以及出现的问题，才能够解决他们。

    不如，从头部开始讲述，像做个PPT一样，不断地填充头部字段，而不同的头部字段正是为了解决某些问题而设定的，所以也是根据接单各个问题的思路。但这就太过繁琐了。

    所以，我决定在这里书写了自己对TCP的问题思考，但基本不会提供任何的答案，当然，我会提供一些我当时思考的方面，毕竟我功力不够。

技术总结

---

TCP技术及其实现方式

1. 可靠传输：连续ARQ协议（延迟确认）、RTT超时重传、滑动窗口（多分组确认）
2. 连接管理：三次握手、四次挥手、保活机制、TCP有限状态机
3. 流量控制：滑动窗口（发送分组数量调节）、延时确认与Nagle算法、大容量缓冲
4. 拥塞控制：慢开始和拥塞避免、快重传和快恢复

连续ARQ协议

1. ARQ（Automatic Repeat reQuest），纠正通信差错的一种重要方法，构成了许多通信协议的基础
2. 重传的请求是自动进行的，接收方不需要请求发送方重传某个出错的分组

延迟确认——累计确认

1. 对于乱序、重复，甚至丢失的分组ACK信息来说，不会进行重传，因为延时确认使得确认信息依然生效
2. 而延时方面，一定程度上减低网络传输负载
3. 但不可以过分推迟，导致不必要的重传（有专门的算法处理）

滑动窗口的“特别”解析

1. 是TCP协议的精髓所在
2. ”滑动“两字的意义在于：
   1. 窗口在发送/接收端都是可以根据分组状态进行“滑动”
   2. 窗口的大小是可以进行调节的
3. 对于乱序、重复分组、确认分组来说，实现可靠传输；对于可调节大小的窗口来说，实现流量控制和拥塞控制

辨析角度（流量控制and拥塞控制）

1. （端到端角度）流量控制——拥塞控制（网络系统角度）
2. 流量控制：让发送方的发送速率不要太快，要让接收方来得及接收
3. 拥塞控制：防止过多的数据注入网络中，使网络中的路由器或链路不致过载

以上基本就是TCP的一些理解，在展开问题讲述之前，我觉得需要理解 TCP网络应用的基本类型。

1. 交互式应用：数据量小、响应速度要求迅速、少于10%
2. 批量数据传输：数据量大、传输速度尽可能快、多于90%

不同的应用，对传输性能有不同的要求，导致了不同的调节参数，意味着TCP采用了不同的算法实现。

TCP解决问题的来源

    根本在于：IP是尽力交付服务，TCP是可靠传输，所以TCP需要纠正IP无法修复的错误，从而确保可靠传输

正文

---

本质，也是唯一目的：实现可靠传输

但息理论和编码理论，证明了信道传输会出错

最简单的方式：发送/接收发现出错，即可：重新发送

<A>重发分组

1. 接收方是否接收到了？——ACK确认
2. 接收方是否接收到同一个分组？——Sequence序列号（辨别一分组，防止重复）

<B>导致问题

1. 发送方对一个ACK应该等待多长时间？——RTT超时重传
2. ACK丢失怎么办？——发送方直接重传相同分组——导致A2问题
3. 分组被接收，内容出错怎么办？——校验字段（接收方不发送ACK，发送方重发分组）——导致B1问题

到目前为止，已经完成了“可靠”的基本要求。我们称之为：停止等待协议

但这样信道利用率非常低，吞吐量低

然后我们发现，我们可以将多个分组同时注入网络！！！让网络处于繁忙状态

我们称之为：连续ARQ协议

<C>连续ARQ协议——多个分组同时注入网络

1. 发送方
   1. 什么时候发送？一次发送多少个分组？——在滑动窗口内的所有分组都可以同时发送——导致C12和C2所有子问题
   2. 如何维持每个分组的ACK等待时间？——为每个分组建立一个RTT计时器
   3. 如何保留没有确认的分组的副本以便重传？——
      1. 发送端的分组窗口分三部分
         1. <左边>已发送且已确认
         2. <中间>已发送但未收到确认、允许发送但未发送
         3. <右边>不允许发送
      2. 不断舍弃<左边>的副本，<中间>全部保留副本
2. 接收方
   1. 对于每个分组的ACK，如何区分是否确认？——延迟确认——导致C12、C13问题
   2. 如何维护“次序杂乱”的分组？——
      1. 同样建立接收端的分组窗口
         1. <左>已发送确认
         2. <中>未按序收到、允许接收
         3. <右>不允许接收
      2. 不断往<右>移动，增加<左>的数量
   3. 接收速率比发送速率要慢怎么办？——收发双发，协调滑动窗口大小
   4. 中间路由器，网络基础设备处理不了发送与接收想要使用的数据怎么办？——发送端根据网络的拥塞情况，协调发送窗口大小

我们之前通过”停止等待协议“，很好地实现了可靠；

但目前为了提升吞吐量，又面临了这么多问题。

问题总是一个接一个，而且是相互关联的。我理解为：问题的诱因存在相关性。

我们还漏了回答一个重要技术：RTT超时重传

比较特别的一点，超时重传，都是针对发送方而言。

RTT超时重传——实时测量RTT，估算RTO

1. RTO过小，引起报文不必要的重传，增加网络负载（还没到达的ACK就被误认为超时，分组被重传）
2. RTO过大，网络的空闲时间增大，降低传输效率（发送方等待ACK时间变长了，滑动窗口移动变慢，发送速率下降）

到了这里，基本理清了TCP设计的原理和问题来源。