# 交换机与VLAN

• 当交换机的数目越来越多的时候，会遭遇环路问题，让网络包迷路，这就需要使用 STP 协议，通过华山论剑比武的方式，将有环路的图变成没有环路的树，从而解决环路问题。交
• 换机数目多会面临隔离问题，可以通过 VLAN 形成虚拟局域网，从而解决广播问题和安全问题。

# Ping协议的格式

• Ping是通过ICMP（Internet Control Message Protocol，互联网控制报文协议）协议工作的
• Ping比起原生的ICMP协议，多了两个字段，一个是标识符，区分用于不同功能，一个是序号，确定返回结果
• ICMP 相当于网络世界的侦察兵。有两种类型的 ICMP 报文，一种是主动探查的查询报文，一种异常报告的差错报文；
• ping 使用查询报文，Traceroute 使用差错报文。

# 静态路由协议

在真实的复杂的网络环境中，除了可以根据目的 ip 地址配置路由外，还可以根据多个参数来配置路由，这就称为策略路由。

可以配置多个路由表，可以根据源 IP 地址、入口设备、TOS 等选择路由表，然后在路由表中查找路由。这样可以使得来自不同来源的包走不同的路由。

# 动态路由算法

使用动态路由路由器，可以根据路由协议算法生成动态路由表，随网络运行状况的变化而变化

路由器之间可以抽象出图，从而将问题转化为如何找到图的最短路劲问题.

# 距离矢量路由算法(distance vector routing)

基于Bellman-Ford算法，每个路由器都保存一个路由表，包含多行，每行对应网络中的一个路由器，每一行包含两部分信息，一个是要到目标路由器，从那条线出去，另一个是到目标路由器的距离。每个路由器根据新收集的信息，计算和其他路由器的距离，比如自己的一个邻居距离目标路由器的距离是 M，而自己距离邻居是 x，则自己距离目标路由器是 x+M。

问题：

• 其中有路由器挂了，挂的消息是没有广播的。当每个路由器发现原来的道路到不了这个路由器的时候，感觉不到它已经挂了，而是试图通过其他的路径访问，直到试过了所有的路径，才发现这个路由器是真的挂了。
• 每次发送广播的时候需要发送整个全局路由表，网络太大会造成拥堵。

# 链路状态路由算法（link state routing）

基于Dijkstra算法，当一个路由器启动的时候，首先是发现邻居，向邻居 say hello，邻居都回复。然后计算和邻居的距离，发送一个 echo，要求马上返回，除以二就是距离。然后将自己和邻居之间的链路状态包广播出去，发送到整个网络的每个路由器。这样每个路由器都能够收到它和邻居之间的关系的信息。因而，每个路由器都能在自己本地构建一个完整的图，然后针对这个图使用 Dijkstra 算法，找到两点之间的最短路径。

# 动态路由协议

# 1. 基于链路状态路由算法的OSPF

OSPF（Open Shortest Path First，开放式最短路径优先）就是这样一个基于链路状态路由协议，广泛应用在数据中心中的协议。由于主要用在数据中心内部，用于路由决策，因而称为内部网关协议（Interior Gateway Protocol，简称 IGP）。

• 内部网关协议重点是找到最短路径。
• 找到多个最短路径叫等价路由，可用于负债均衡

# 2.基于距离矢量路由算法的BGP

外网的路由协议，即国家之间的，又有所不同。称为`外网路由协议（Border Gateway Protocol，简称 BGP）

• 对于网络包，每个数据中心都设置自己的规则。哪些外部的IP可以让内部知晓，哪些内部的IP可以让外部知晓。
• 网络中出现一个个自治系统AS(Autonomous System),其分为几种类型：
  • Stub AS: 对外只有一个连接。不会传输其它AS的包。
  • Multihomed AS:可能有多个连接连到其他的AS，但是大多拒绝帮其他的AS传输包。
  • Transit AS: 有多个连接连到其它AS，并且可以帮助其它AS传输包。例如主干网
• 每个自治系统有边界路由器，与外界建立联系。
• BGP 又分为两类，eBGP 和 iBGP。自治系统间，边界路由器之间使用 eBGP 广播路由。内部网络也需要访问其他的自治系统。边界路由器如何将 BGP 学习到的路由导入到内部网络呢？就是通过运行 iBGP，使得内部的路由器能够找到到达外网目的地的最好的边界路由器。

# UDP协议

# UDP与TCP区别

• TCP 是面向连接的；UDP 是面向无连接的。
• TCP 提供可靠交付；UDP 继承了 IP 包的特性，不保证不丢失，不保证按顺序到达。
• TCP 面向字节流；UPD基于数据报，一个个地发一个个地收
• TCP 是可以有拥塞控制的；UDP不会

# 包头

• IP头有8位协议，决定使用什么协议
• 源端口号（16位）、目的端口号（16位）、UDP长度（16位）、UDP校验和（16位）、数据

# 特点

• 沟通简单。数据结构、处理逻辑、包头简单。
• 监听的端口谁都可以传输数据给他
• 不会根据网络情况而改变

# 应用场景

• 资源少的内网，对丢包不敏感的应用。如DHCP协议、TFTP
• 不需要一对一沟通，建立连接，而是可以广播的应用。如DHCP、VXLAN
• 需要处理速度快，延时低，可容忍少数丢包。如视频聊天、语音通话

# TCP

# TCP的三次握手

# 为什么是三次？

• 1. 客户端A与服务器B建立连接，B发送应答包后是不能确定A已经收到
• 2. 当网络波动时，A会重复发送请求，B会重复应答
• 3. 三次握手可以确定双方都准备好了资源，避免死锁发生

# 四次挥手

第一次：客户端请求断开FIN,seq=u

第二次：服务器确认客户端的断开请求ACK,ack=u+1,seq=v

第三次：服务器请求断开FIN,seq=w,ACK,ack=u+1

第四次：客户端确认服务器的断开ACK,ack=w+1,seq=u+1

# TCP如何确定请求靠谱

# 每个包设置一个ID，保证每个请求都有应答

# 发送端根据处理情况设置四个部分：

• 1. 发送了并且已经确认的。
• 2. 发送了并且尚未确定的
• 3. 没有发送等待发送的
• 4. 没有发送暂时不会发送（为了流量控制）

# 接收端三种情况：

• 1. 接受并且确认过的
• 2. 还没接收，马上就能接受
• 3. 还没接收，也没法接收

# 确定与重发机制

1. 超时重试

   自适应重传算法:通过采样RTT的时间及RTT的波动范围，进行加权平均，算出一个值。超时间隔加倍，超过两次，说明网络太差，停止发送。

2. Selective Acknowledgment （SACK）

在TCP头里加一个SACK的东西，可以将缓存的地图发送给发送方，发送方看到地图，就知道哪个包丢了。

# 流量控制问题

# 拥塞控制问题

1. 设备缓存会导致延时？

• 假如经过设备的包都不需要进入缓存，那么得到的速度是最快的。进入缓存且等待，等待的时间就是额外的延时。BBR就是为了避免这些问题： 充分利用带宽；降低buffer占用率。

2. 降低发送packet的速度，为何反而提速了？ 标准TCP拥塞算法是遇到丢包的数据时快速下降发送速度，因为算法假设丢包都是因为过程设备缓存满了。快速下降后重新慢启动，整个过程对于带宽来说是浪费的。通过packet速度-时间的图来看，从积分上看，BBR充分利用带宽时发送效率才是最高的。可以说BBR比标准TCP拥塞算法更正确地处理了数据丢包。对于网络上有一定丢包率的公网，BBR会更加智慧一点。 回顾网络发展过程，带宽的是极大地改进的，而最小延迟会受限与介质传播速度，不会明显减少。BBR可以说是应运而生。

3. BBR如何解决延时？

• S1：慢启动开始时，以前期的延迟时间为延迟最小值Tmin。然后监控延迟值是否达到Tmin的n倍，达到这个阀值后，判断带宽已经消耗尽且使用了一定的缓存，进入排空阶段。
• S2：指数降低发送速率，直至延迟不再降低。这个过程的原理同S1
• S3：协议进入稳定运行状态。交替探测带宽和延迟，且大多数时间下都处于带宽探测阶段。

# 应用层，HTTP协议

# 当我们输入url访问网站到网页展示会经历什么

• 域名先通过DNS服务器解析成IP地址
• 建立TCP连接（三次握手）
• 请求构建:请求行、请求首部、正文实体
• 通过二进制流发送
• TCP层将二进制流变成报文
• TCP发送报文段，用得到回应ACK来保证可靠地到达了对方。
• TCP发送每个报文的时候，加上自己的地址和目标地址放到IP头交给IP层传输
• IP层查看是否在同一个局域网，如果是，发送ARP协议来请求目标MAC地址；如果不是，发送ARP协议获取网关MAC地址，并把数据发送到网关
• 网关收到取出目标IP地址，根据路由器协议找到下一跳的路由器，获取下一跳的路由器的MAC地址并发送给下一跳路由器
• 到达目标地址的局域网，于是这个局域网发送ARP协议获取目标地址的MAC地址并发送到该地址
• 目标机器发现了MAC地址符合，接收包，发现是IP协议，于是根据IP头中的协议项知道上层是TCP协议，于是按照TCP协议解析TCP的头，放入缓存中处理并返回一个ACK
• 解析TCP的端口号，HTTP服务器监听此端口号，目标机器将包发送给目标端口，HTTP服务器进程响应到请求，返回找到对应资源
• 服务器构建返回报文：状态吗、返回首部
• 让TCP层将返回的HTML文件分为一个个小的段，加上TCP头交给IP层按来的过程再走一遍
• 客户端发现接收报文，交给TCP层根据序列号处理是否符合，然后发给相应端口
• 浏览器监听端口，取到状态码200，解析正文
• 浏览器根据首部返回格式解析html格式数据，渲染执行

# HTTP 1.0与1.1区别

• 缓存处理，在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。

• 带宽优化及网络连接的使用，HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。

• 错误通知的管理，在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。

• Host头处理，在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。

• 长连接，HTTP 1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP1.1中默认开启Connection： keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。

# HTTP 2.0

对比HTTP1.0优化：

1. 对HTTP的头进行压缩，在两端建立索引表，对相同的头只发生索引表中的索引
2. 多路复用
   • HTTP2.0将TCP连接中，切分成多个流，每个流有自己的ID，它是一个虚拟通道，优先级更高
   • 对传输信息分割为更小的消息和帧，并采用二进制格式编码。传输header内容的帧Header帧,传输正文实体的帧Data帧
   • 比如有三个请求，HTTP2.0会将它们分成三个流，将数据分成帧，乱序发送给TCP处理
3. 服务器推送

# QUIC协议

解决问题：当服务端TCP层没有收到stream2的帧，即使是收到了后面的stream1的帧,stream1的帧也不会被传输到应用层中。基于TCP就突破不了TCP，各个帧虽然没有上下文的关联性，但是TCP强制他们的顺序性。

• QUIC使用UDP进行传输
• QUIC自定义连接机制：通过自行维护连接机制生成一个ID作为标识，不会因为源 IP、源端口、目的 IP、目的端口一个变了就重新握手
• 自定义重传机制：每发送一个包会带上不同序列号，通过offset来确定包是否接收到
• 自定义流量控制

# HTTPS协议加密方式

• 对称加密：加密和解密使用的密钥是相同的
• 非对称加密：公钥加密的信息只能私钥能解密，私钥加密的信息只有公钥能解密
• 数字证书

# DNS服务器

# DNS服务器的树状结构：

• 根 DNS 服务器返回顶级域 DNS 服务器的 IP 地址
• 顶级域 DNS 服务器返回权威 DNS 服务器的 IP 地址
• 权威 DNS 服务器返回相应主机的 IP 地址

# 解析流程

• 客户端发起DNS解析流程，先访问本地DNS缓存（/etc/hosts），无缓存
• 客户端向本地DNS服务器（一般附近运营商的某个机房），无缓存
• 本地DNS服务器访问根域名服务器，根域名服务器会返回顶级DNS服务器的IP地址
• 本地DNS服务器拿到顶级DNS服务器IP地址，访问顶级DNS服务器地址，返回权威域名服务器IP地址
• 本地DNS服务器拿到权威域名服务器IP地址，访问并拿到对应IP地址
• 本地DNS服务器返回IP地址，客户端发起IP协议请求

# 负载均衡

• 内部负载均衡：1.重新映射域名即可更换服务器2.配置策略，可让解析时自动更换IP地址
• 全局负载均衡: 根据配置让DNS服务器自动返回附近的服务器的IP地址

# DNS服务器问题

• 解析慢
• 更新不及时
• 因为缓存、转发、NAT问题导致客户端误会自己梭子啊的位置和运营商，影响流量调度

# 状态码

# 301、302、303、307、308区别

301、308都是永久重定向

• 301会将post请求转给get请求重新发送
• 308会将原来的请求头和请求实体发送到新的地址

302、303、307是临时性重定向

• 302 客户端实现不一致，导致有些情况下会转 get请求再次请求，有些情况下会继续原来请求的方法
• 303 为了解决302的问题，此状态码将会把所有请求方法转为get方法再次请求新请求
• 307 将会原来的请求头请求体发送到新地址