计算机网络-05 网络传输

第五讲：网络传输

网络层提供端到端连接：无连接、尽最大努力交付的数据报服务

端口：16位整数标识，网络意义是标识主机的一个特定服务，本地意义是区分主机内应用层的各个进程

源/目的地址+源/目的端口号可唯一标识互联网中的TCP或UDP传输

UDP

最简单的传输层协议，根据端口号进行多路复用

不需要建立连接和维护状态，不需要可靠传输，上层可实现更多功能

TCP

使用最广泛的传输层协议，多路复用、连接管理、可靠传输、流控、拥塞控制

协议特征

完全实现在传输的两端之上，符合端到端原则，效率、公平性、收敛效率是TCP的三个设计目标

TCP设计

连接管理、数据传输、拥塞控制

序列号

TCP是面向字节流的传输，每个传输字节都对应一个32位整数序列号，连接建立时用随机数作为初始序列号，传输时将数据分割为不同的数据包，最大大小为1500(MTU)，每个数据包的序列号是其包含的第一个字节对应的序列号

连接和断开

建立连接：双方确定连接所使用的的端口号，被动连接的用固定端口，主动连接的用随机端口，双方确定并通知自己所使用的初始序列号SYN，两个序列号相互独立，双方收到后回复ACK，第一个ACK和第二个SYN通常合并在一个数据包中，所以一共是三次握手

断开连接：连接任意一方都可以主动关闭，发送FIN数据包，表示自己不再发数据了，但另一端还可以发数据，而且自己还要接着回复ACK（全双工传输协议），任何一方都可以发送RST数据包关闭连接，这之后两边都不能再发送数据了，尽量避免用RST

高效数据传输

丢包检测和重传，发送方速率不能超过接收方速率，并且尽可能多利用网络带宽

网络允许的最大传输窗口为BDP（带宽时延积）

BDP=带宽×RTT，同样最大吞吐量=最大win_size/RTT

BDP较大的传输路径称为长肥管道

流控（不同于拥塞控制）

为了防止快发送方给慢接收方发送数据造成接收崩溃

解决方法是两边各自维护一个窗口大小winsize，使得send_winsize<recv_winsize，各自按照自己的winsize发送/接受数据，接收方的数据如果落在窗口外就直接丢掉，落在窗口内，如果连续就交付上层，更新窗口，不连续就先保存在buffer中，不更新窗口

TCP SACK

TCP选择确认包，接收方需要对每个收到的数据进行确认

收到连续数据时回复连续确认ACK，收到不连续数据时还要附加非连续数据的边界SACK

丢包检测和重传

通过超时来判断丢包，timeout设置太大丢包效率低，设置太小导致误重传，至少要大于一个RTT，并且能适应RTT变化，所以要同事反映RTT大小和RTT变化

快速重传：如果一个数据包后面的三个数据包都被确认而该数据包还没被确认就认为它丢了，通常可以在一个RTT内重传数据丢包

网络拥塞

多传输流共享&竞争资源，资源需求超过带宽容量时产生拥塞，后果是丢包率升高、往返时延增大，直至网络崩溃

设计拥塞控制策略需要满足：高效利用、公平性、防止崩溃

两种思路：

一种是端到端的拥塞控制，不需要网络设备的拥塞提醒，通过丢包、延迟变化等等推测拥塞状况，优点是中间设备设计简单，缺点是拥塞推断策略比较差时，资源利用率会很低

一种是网络辅助的拥塞控制，网络设备对端系统拥塞提醒，通过标志位或显示规定发送速率提醒拥塞状况，优点是资源利用率更高，缺点是中间设备设计复杂，每条流都要维护一个状态，可扩展性差

TCP拥塞控制算法基础

网络设备功能简单，FIFO，共享buffer，通过丢包判断拥塞，通过定期增大发送速率向上探测可用带宽，加性增乘性减

TCP拥塞控制策略

隐式拥塞反馈（丢包）+加性增乘性减，兼顾效率和公平，每收到丢包信息，win减半，每个RTT，win增加一个数据包大小

快速重传后的发包停顿现象

快速重传检测到丢包后证明网络拥塞，窗口减半，发送方未确认的包数目>new_winsize，所以不能发送新数据，每收到一个新的ACK，未确认包数目-1，直到减小到<new_winsize才能继续发包，表现是经过快速重传后发送方在<1RTT的时间里不能发送任何数据

快速重传后又丢包咋办

快速恢复阶段：起始于快速重传后，结束于进入快速恢复阶段时发送的最大序列号数据被连续确认

快速恢复阶段如果又遇到其他丢包，不再快速重传，new_winsize不变，并且保证发送方未确认的包数目<=new_winsize，如果小于就发送新的数据包，如果检测到丢包就重传，否则发送新的数据包，直到累计确认ACK>=进入快速恢复阶段时发送的最大序列号

慢启动

拥塞避免+快速重传+快速恢复可以达到稳态

慢启动机制：初始窗口，慢启动门限值ssthresh

当cwnd<ssthresh，每收到一个ACK，cwnd+=1

当cwnd>=ssthresh，每收到一个ACK，cwnd+=1/cwnd

当遇到丢包时，ssthresh设置为当前cwnd大小，cwnd减半

超时重传直接慢启动（拥塞很严重），快速重传win减半

TCP优化

两个角度：丢包重传优化 拥塞控制算法优化

丢包重传优化

为啥需要等3个重复ACK：因为可能会有乱序，防止误重传，现在的假设是网络中乱序长度不大于3个数据包，不然就是丢了

咋识别它是丢了还是乱序：重复ACK，快速重传门限值设置为乱序长度+1个数据包，每次遇到重复ACK时门限值+1，每次超时后恢复为3

快速重传可以恢复所有丢包吗

可以恢复长流中的大部分丢包，但短流基本上都是超时重传恢复的

TLP(tail loss probe)尾部探测丢失

数据包通常以burst形式发送，相邻数据包间隔很短，越靠后越可能被丢弃

发送数据较少时可以降低触发重传的门限值，满足特定条件时显式重传数据包

重传后的丢包

发生重传后发送顺序和序列号不再一致，如果重传数据包丢失，不能再通过快速重传来恢复，如果数据被重传，也不能被当作后续数据包来触发快速重传

也就是同一数据包被丢弃两次后，只能等待超时重传

改进：RACK，记录每个数据包的发送时间（包括重传数据包），给定先后发送的两个数据包P1和P2，如果P2先收到确认，并且P1是在RTT+delta之前发送的但还没收到确认，那就认为P1丢了

拥塞控制优化

TCP NewReno

吞吐率经验公式：$throughput=\frac{C\ast MSS}{RTT\ast \sqrt{loss\_rate}}$

存在的问题：RTT不公平，RTT大的流带宽占用率低；在大带宽、高延迟网络中的资源利用率差，即使很小的丢包率也会导致极低的带宽占用率

TCP Cubic

核心思想：窗口增长与RTT无关，只取决于距离上次快速重传的时间，利用三次函数的特性，高效窗口恢复和探测

Compound TCP（混合TCP）

核心思想：丢包不是拥塞的唯一信号，还有延迟变化，将基于丢包计算的窗口值和基于延迟计算的窗口值之和作为窗口值

BBR（bottleneck bandwidth and RTT）

$throughput=\frac{maxwin\_size}{RTT}$

核心思想是在不降低吞吐率的同时减少网络延迟，每次收到ACK之后更新对max throughput和min RTT的估计，通过控制发送数据量来探测max throughput和min RTT

网络多路径特征

TCP本身不能感知多条路径，多路径分发导致的乱序会降低TCP性能

并且还有移动的特征

网络、连接和应用的抽象：

对于一个应用socket来说，连接绑定到了一个ip地址+一个网络接口上，因为绑定到了ip，一个socket不能使用多个路径/接口，当ip变化时连接只能断开

解决方法：解耦合，分离主机标识和网络地址（和前面的是一个套路）

MPTCP机制(multipath TCP)

控制平面：在多条可用路径之间进行管理

数据平面：进行数据传输

拥塞控制

每条路径上传输的数据包应该看起来像一个正常的TCP流数据包，所以一个MPTCP连接由一个或多个正常的TCP子流构成，端节点维护TCP子流与MPTCP之间的映射关系，每条子流在单条路径传输

问题是：怎么拆分？怎么合并？

怎么合并

在新建TCP子流的时候将已有TCP子流的地址和端口通告给对方

怎么传输

两层序列号结构，标准TCP头部使用子流序列号，让它在单条路径上看起来比较正常，扩展选项中使用全局序列号

丢包恢复

在子流中完成，和传统TCP一样，也可以跨子流恢复，当一条子流异常断开时加速丢包恢复效率

重传条件

快速重传同传统TCP，超时重传评估该数据段是否由其他子流重传，当一条子流异常退出时该子流没确认的所有数据段都由其他子流重传

消息传递

引入了额外的控制消息：数据序列号、数据确认号等等

如果使用传统的TCP扩展选项：优点是和传统TCP兼容，middlebox不支持也可以回退，缺点是扩展空间有限，放不了太多

如果使用TLV机制：将TLV信息放在payload中，长度不受限制，可扩展性好；缺点是会对middlebox产生影响，DPI实现更复杂

拥塞控制

无，记不住

TCP改进方向

是网络环境和网络应用之间的性能适配器

主要在端设备进行，不修改TCP头部、选项，模块化演进

遵循端到端原则、可扩展性、公平性

基于UDP的新型传输协议是新趋势