计算机网络-03 网络互连

第三讲：网络互连

直连网络的局限性

本质上是广播网络，可扩展性差；在有环路的拓扑结构中会造成广播风暴

解决方法：网络分割，将直连网络分成不同的段；广播到单播，只向目的地方向传送

交换网络

设计目标：只向目的地方向传送，转发规则自己生成，不需要外界参与

主要包括数据帧转发和节点位置学习两个部分

数据帧转发

交换机存储目的MAC地址到出入端口的映射关系，FDB（forwarding database）

对每个数据帧在FDB中查找目的MAC地址的端口号，如果有，就从该端口转发（单播），如果没有，从所有端口转发（广播）

FDB通过老化机制更新

FDB的生成方法

每收到一个新的数据帧，就把它的MAC地址和入端口号的映射记在FDB中

消除广播风暴

解决方法是给网络中每对节点都分配唯一确定的路径，构成一棵树，成为生成树(Spanning Tree)

生成树：选一个节点作为根节点，其他节点计算确定到根节点的最短路径，要保证是最小生成树

生成树的生成方法：

初始时每个节点都认为自己是根节点，然后向自己的邻居广播（自己的名字，自己认为的根节点的名字，自己到根节点的距离），收到后按照情况更新自己的信息，再广播给邻居节点，直至收敛，整个网络选举出根节点，并且每个节点都知道自己到根节点的最短路径和出端口

以下情况需要更新信息：

有ID更小的根节点；同一根节点但路径更短；同一根节点同一距离但发送方的ID更小

交换网络小结

连接方式：从直连网络的集线器到交换机

数据传输方式：从广播到单播

链路共享机制：每个链路只有两个节点，不需要CSMA/CD

拓扑特征：层次结构数，如果有冗余链路→生成树拓扑

网络互连

不能把交换网络扩充到全球范围，因为FDB表膨胀问题和STP收敛速度问题

全网可达的网络协议：对上层提供统一接口，对下层进行抽象封装

设计思路：向上提供最基本端到端服务，无连接、尽最大努力交互的数据报服务

发送前不需要先建立连接，数据报没有序号，每个数据包单独发送，与其前后分组无关

不提供服务质量承诺，所传输的数据报可能丢失、重复、乱序，也不保证传递的时效

优点：设计简单，适应性强；中间转发设备简单，成本低

IPv4地址

32位地址空间，点分十进制，分成四段

层次化，网络号+主机号，网络号由ICANN分配，表示主机所在网络；主机号由网络管理员分配，表示主机在该网络内的标识

有类别的IP地址划分

A、B、C类，另有D、E类

A类0+7位网络号+24位主机号

B类10+14位网络号16位主机号

C类110+21位网络号+8位主机号

D类1110，组播地址

E类1111，实验性质的地址空间

无类别域间路由（CIDR）

前k位为网络号，后32-k位为主机号

网络号用前缀而不是class确定，如192.168.1.99/28表示前28位为网络号，后4位为主机号

前缀也可以用网络掩码表示，掩码长度与ip地址相同，网络号用1表示，主机号用0表示，比如28位网络号对应的掩码为255.255.255.240

一个网络内可以使用更大的前缀来划分子网

IP地址的特点

层次化地址结构，网络管理员仅分配网络号，方便地址管理

提升了网络系统的扩展性，在做包转发时仅根据目的主机的网络号来转发分组，当网路拓扑发生变化时，更新次数大幅减少

IP报文转发

路由器把转发信息存储在转发表中，存储的是网络号与下一跳的映射关系

IP报文转发规则

收到IP报文后获取目的地址D，按照下面规则转发：

如果路由器和D在同一网络内，直接交付给D；

在转发表中进行最长前缀匹配，匹配到则把IP报文转发给下一跳网关；

如果转发表中有默认路由，转发给默认路由；

以上均不满足，发送ICMP消息，回送报文不可达

IP到MAC的映射

IP层向上层屏蔽了下层MAC地址的细节，需要做IP到MAC的映射

ARP协议：知道下一跳IP，查询MAC地址

每个路由器/主机中有一个ARP缓存，存储局域网内各主机或路由的映射关系

局域网内A向B发送消息时：

如果A的ARP表中有B的MAC地址，则直接向该MAC地址发送帧；

如果没有，则A向局域网中所有路由/主机广播ARP请求，询问节点B的MAC地址，B收到后会告诉A的MAC地址，然后A和B都会把对方的ip和MAC地址映射关系写入自己的ARP表中

ARP协议只作用于局域网，不在同一个局域网内的主机应先转发到路由器

IP分片

最大传输单元MTU：IP在一个报文承载的最大数据量

每个链路的MTU可能不同，而且发送方不知道

解决方法：由路由器做分片，由目的主机做分片重组

缺点：

不能充分利用网络资源：转发代价与数据包数目相关，与大小无关；IP分片不能探测传输路径的MTU大小，报文太大会导致分片，报文太小会导致数据包太多

端到端性能很差，一个分片丢失时，接收端会把所有都扔了

解决方法：使用路径发现MTU机制，在传输过程中发现沿途的最小MTU

ICMP（互联网控制消息协议）

通过发送错误代码、控制信息等来诊断和控制网络，由IP协议封装，与TCP无关，基本不用于数据传输

IP地址带来的问题

早期IP每个主机都有唯一的IP地址，任意主机之间都可以相连，任意主机都可以充当服务器

但安全问题：任意主机都可以攻击其他主机；攻击者可以伪造数据包源地址

IP地址空间不足

NAT

地址转换协议，IP到IP

全局IP：用于互联网公共主机和路由设备

私有IP：用于组织专用网内部，一般是主机

组织内部给每个主机分配一个私有地址

NAT负责私有地址到全局地址的翻译

NAT可作为客户机和服务器之间的代理，也可以让客户机成为服务器（使用端口映射技术将内网主机的端口对外可见）

IPv6

128位，十六进制表示，分8段，中间用:隔开

IPv6=前缀+接口标识，前缀相当于ipv4的网络号，接口标识相当于ipv4的主机号，固定为64位，前缀长度也用/xx表示

128位的好处：有利于层次化编址

地址分层结构

全球路由选择前缀（48+）+子网标识符（16-）+接口表示符（64）

MAC到ipv6

MAC转换为EUI-64，转换方法是低24位不变，高24位的第7位取反，高低24位中间插入1111 1111 1111 1110，构成64位主机号，然后和64位前缀拼接，构成128位ipv6地址

ipv4到ipv6

前缀为::ffff/96是保留的与ipv4兼容的地址，在ipv4和ipv6之间转发时要做地址转换

ipv6数据包报头

简化了，扩展选项放在了next域（不在包头里），对路由器转发性能没有负面影响

ipv6地址自动配置

目的是获得全局网络前缀（因为后64位是和MAC地址相关的），不需要DHCP服务器来做

主机发送请求报文，路由器回应报文，包含自身的网络前缀（获取到了）

ipv6地址解析

取消了ARP协议

通过邻居请求报文NS和邻居通告报文NA来解析三层地址对应的链路层地址

发送主机发送NS到目的ipv6地址对应的组播地址，NS中包含了自己的链路层地址

目标主机收到后获得发送主机的ip地址和链路层地址，并回复NA告知自己的链路层地址

ipv4到ipv6过渡

增量部署

双协议栈技术：同时支持ipv4和ipv6

隧道技术：把ipv6报文封装到ipv4报文中，ipv6网络之间穿越ipv4通信

互通技术：在两个网络相连的地方做地址翻译，修改报头

数据包队列

数据包队列/队列/buffer 都是同一个含义

队列设置大小：经验值buffer_size=RTT*C，RTT是端到端平均延迟，C是瓶颈链路带宽

队列大小决定传输速率，发送窗口大小与队列中数据包成正比

队列过大时：buffer_size>RTT*C，当窗口大小减半时，队列不能及时清空，因此数据包的延迟会增加

队列过小时：buffer_size<RTT*C，当窗口大小减半时，发送方在等待接收方的ACK才能继续发，瓶颈链路空闲

多流环境下队列大小应设置为$\frac{BDP}{\sqrt{(}n)}$

现实中的队列问题

数据中心网络中交换机的总队列长度并不小，但端口多，业务高并发，队列相对过小会造成TCP incast

广域网内的路由转发设备负载大，增大队列会降低丢包率，优化TCP传输速率T=$\frac{MSS}{\sqrt{(loss)}\ast RTT}$，但队列过大会造成BufferBloat

TCP incast

并发传输中，多个主机向一个主机发送数据包，只要有一个丢包了，其他所有的包都得放在队列里等着丢了的重传，这时候链路带宽利用率是0

多见于DCN

主要原因是粗粒度、低效率的TCP丢包恢复机制

增大队列可以解决，但是成本高

Buffer Bloat

数据包在缓冲区中停留时间过长造成的延迟过大

主要原因是设备的队列设置过大，而且TCP传输设计之初的目标是改进吞吐率，优化带宽占用率，拥塞的信号是丢包，只要没丢包就会尝试增加cwnd大小，增加吞吐率，但当cwnd增大到BDP时，再增加不会增大吞吐率，只会增大数据包延迟

多发生在网络负载较重的时间段、边缘路由器、3G/4G网络（移动数据网络中通常发生在第一跳节点）

会影响QoE（很好理解，因为延迟大）

解决方法包括：

减小队列大小，但是对Burst容忍度差

改进传输策略：丢包不是唯一信号，也考虑延迟

主动队列管理：队列满前就主动概率性丢包，以延迟作为队列管理信号

队列丢包策略

【tail drop（尾部丢弃）】

队列满时丢弃新到达的数据包，最简单、应用最广泛，FIFO

【RED（随机早发现）】

高BDP流需要较大队列来适应Burst，但是队列增加时延迟也会增大

设计目标是高吞吐率、低延迟

在队列满之前就开始随机丢包，提醒发送方马上要拥塞了，概率性丢包，概率与队列长度成正比

主要问题是需要设置很多参数（啥时候不丢包、啥时候开始概率丢包、啥时候开始全丢包），而且参数敏感，调优困难，设置不好还不如不设置，现在不用了

【CoDel】解决buffer bloat问题

目标是减少大队列下的延迟，对RTT、速率、负载不敏感

核心思想是控制包在队列中停留的时间（也即延迟）而不是队列长度

停留时间超过target值时就丢包，并计算下次丢包时间，$\frac{interval}{\sqrt{count}}$，直到所有包的停留时间都小于target

移动网络下：

tail drop在队列满前不会丢包，当带宽变小时需要很长时间才能把数据包发出去，延迟会增大

RED可以保证队列中数据包数目较少，但是对带宽变化不敏感

总结

队列大小

过大会引起TCP incast，过小会造成buffer bloat

队列管理

丢包次数：tail drop<RED<codel

延迟：tail drop>RED>codel

队列调度

FIFO：实现简单，吞吐率高

fair queue：提升流之间的公平性

没有一种策略能在所有环境下达到最优