由于 DNS 是查询是 UDP 的明文传输，很容易被中间人截取到你在访问哪些网站
所以我们需要加密 DNS 请求

首先我们了解下什么是 DOT 和 DOH

这两种方法更主流的方法是 DOH,如何在浏览器使用 DOH 呢？

下面我以 Edge 浏览器为例

打开配置界面

edge://settings/privacy

我们使用阿里云 DOH

https://dns.alidns.com/dns-query{?dns}

这里列出几个其他的 DOH
DoH (国密):

https://sm2.doh.pub/dns-query

腾讯云 DOH

https://doh.pub/dns-query

当然我们还需要给电脑的 DNS 配置上 DOH

我们打开设置，搜索 WLAN,里面点击硬件属性，找到 DNS 设置，点击编辑
可以将首选 DNS 设置成阿里云 DNS 223.5.5.5
然后打开 DNS over HTTPS ,开手动模版
模版填入

https://223.5.5.5/dns-query

可以将失败时使用未加密请求打开

下面来了解下 SNI （服务器名称指示）

Server Name Indication（SNI）
SNI (Server Name Indication)是用来改善服务器与客户端 SSL (Secure Socket Layer)和 TLS (Transport Layer Security) 的一个扩展。主要解决一台服务器只能使用一个证书(一个域名)的缺点，随着服务器对虚拟主机的支持，一个服务器上可以为多个域名提供服务，因此 SNI 必须得到支持才能满足需求。

由于 TLS 握手发生在数据的正式传递之前，因此其中的数据都是明文传输的，容易被网络传输中的中间人监听，中间人就可以轻易的知道用户准备访问哪个网站，中间人还可以通过识别 SNI 的信息，阻断一部分 TLS 握手的建立，这种就是 SNI 阻断

解决方法

使用 ESNI 可以解决这个问题

当然 ESNI 只会加密一部分信息，更加全面的有 ECH

我们可以在下面这个网站测试有没有开启 ECH

https://tls-ech.dev

可以看到我这个已经显示，我在使用 ECH
这是因为我们之前已经配置过浏览器 DOH 了，当然有些浏览器会不支持 ECH，需要自己测试下

我们再来了解下 QOS

QoS（Quality of Service）即服务质量。在有限的带宽资源下，QoS 为各种业务分配带宽，为业务提供端到端的服务质量保证。例如，语音、视频和重要的数据应用在网络设备中可以通过配置 QoS 优先得到服务。

QoS 的重要性
在 IP 网络的业务可以分为实时业务和非实时业务。实时业务往往占据固定带宽，对网络质量变化感知明显，对网络质量的稳定性要求高，例如语音业务。非实时业务所占带宽难以预测，经常会出现突发流量。突发流量会导致网络质量下降，会引起网络拥塞，增加转发时延，严重时还会产生丢包，导致业务质量下降甚至不可用。

解决网络拥塞的最好的办法是增加网络的带宽，但从运营、维护的成本考虑，这是不现实的，最有效的解决方案就是应用一个“有保证”的策略对网络流量进行管理。

QoS 一般针对网络中有突发流量时需要保障重要业务质量的场景。如果业务长时间达不到服务质量要求（例如业务流量长时间超过带宽限制），需要考虑对网络扩容或使用专用设备基于上层应用去控制业务。

近几年，视频的应用出现了爆炸式的增长，现在几乎每个人都拥有一部能够随时随地拍摄高分辨率视频的智能手机。同时随着社交网站的涌现，分享和发布视频成了每个人的日常行为，人们不论身在何处都可以将自己制作的视频发布出去与他人分享。对于企业来说，高清视频会议，高清视频监控等应用，也在网络中产生了大量的高清视频流量。与语音流量相比，视频流量占用的带宽更多，也更不稳定，特别是一些交互类视频，对实时性要求非常高。另外，随着无线网络的发展，越来越多的用户和企业都开始使用无线终端，而无线终端会随着用户的移动而不断变化位置，导致网络中的流量更加的不可预测。因此 QoS 方案设计也面临更多的挑战。

对于 QOS 技术，总的来说有如上所示处理流程。

流量分类与标记主要用于接口入方向，可用于后续的进一步数据处理。
监管与整形主要用于限制流量大小，提高网络资源使用效率。
拥塞管理与避免主要用于在发生拥塞之后的报文处理原则以及如何缓解网络拥塞。

QoS 的服务模型

• Best-Effort 服务模型：尽力而为
  Best-Effort 是最简单的 QoS 服务模型，用户可以在任何时候，发出任意数量的报文，而且不需要通知网络。提供 Best-Effort 服务时，网络尽最大的可能来发送报文，但对时延、丢包率等性能不提供任何保证。Best-Effort 服务模型适用于对时延、丢包率等性能要求不高的业务，是现在 Internet 的缺省服务模型，它适用于绝大多数网络应用，如 FTP、E-Mail 等。
• IntServ 服务模型：预留资源
  IntServ 模型是指用户在发送报文前，需要通过信令（Signaling）向网络描述自己的流量参数，申请特定的 QoS 服务。网络根据流量参数，预留资源以承诺满足该请求。在收到确认信息，确定网络已经为这个应用程序的报文预留了资源后，用户才开始发送报文。用户发送的报文应该控制在流量参数描述的范围内。网络节点需要为每个流维护一个状态，并基于这个状态执行相应的 QoS 动作，来满足对用户的承诺。
• IntServ 模型使用了 RSVP（Resource Reservation Protocol）协议作为信令，在一条已知路径的网络拓扑上预留带宽、优先级等资源，路径沿途的各网元必须为每个要求服务质量保证的数据流预留想要的资源，通过 RSVP 信息的预留，各网元可以判断是否有足够的资源可以使用。只有所有的网元都给 RSVP 提供了足够的资源，“路径”方可建立。
• DiffServ 服务模型：差分服务
  DiffServ 模型的基本原理是将网络中的流量分成多个类，每个类享受不同的处理，尤其是网络出现拥塞时不同的类会享受不同级别的处理，从而得到不同的丢包率、时延以及时延抖动。同一类的业务在网络中会被聚合起来统一发送，保证相同的时延、抖动、丢包率等 QoS 指标。

什么是 QUIC

我们知道 TCP 协议在创建连接之前需要进行三次握手（如下图 1，更详细原理请见《理论经典：TCP 协议的 3 次握手与 4 次挥手过程详解》），如果需要提高数据交互的安全性，既增加传输层安全协议（TLS），还会增加更多的更多握手次数（如下图 2）。

▲ 图 1 - TCP 的三次握手原理图

▲ 图 2 - TLS 的初始化握手原理图

和 TCP 相反，UDP 协议是无连接协议。客户端发出 UDP 数据包后，只能“假设”这个数据包已经被服务端接收。这样的好处是在网络传输层无需对数据包进行确认，但存在的问题就是为了确保数据传输的可靠性，应用层协议需要自己完成包传输情况的确认。

此时，QUIC 协议就登场了。

QUIC 是 Quick UDP Internet Connections 的缩写，谷歌发明的新传输协议。

与 TCP 相比，QUIC 可以减少延迟。

QUIC 协议可以在 1 到 2 个数据包（取决于连接的服务器是新的还是已知的）内，完成连接的创建（包括 TLS）（如下图 3 所示）。

▲ 图 3 - QUIC 协议握手原理图

从表面上看：QUIC 非常类似于在 UDP 上实现的 TCP + TLS + HTTP/2。由于 TCP 是在操作系统内核和中间件固件中实现的，因此对 TCP 进行重大更改几乎是不可能的（TCP 协议栈通常由操作系统实现，如 Linux、Windows 内核或者其他移动设备操作系统。修改 TCP 协议是一项浩大的工程，因为每种设备、系统的实现都需要更新）。但是，由于 QUIC 建立在 UDP 之上，因此没有这种限制。QUIC 可以实现可靠传输，而且相比于 TCP，它的流控功能在用户空间而不在内核空间，那么使用者就不受限于 CUBIC 或是 BBR，而是可以自由选择，甚至根据应用场景自由调整优化。

QUIC 与现有 TCP + TLS + HTTP/2 方案相比，有以下几点主要特征：

1）利用缓存，显著减少连接建立时间；

2）改善拥塞控制，拥塞控制从内核空间到用户空间；

3）没有 head of line 阻塞的多路复用；

4）前向纠错，减少重传；

5）连接平滑迁移，网络状态的变更不会影响连接断线。

从图上可以看出，QUIC 底层通过 UDP 协议替代了 TCP，上层只需要一层用于和远程服务器交互的 HTTP/2 API。这是因为 QUIC 协议已经包含了多路复用和连接管理，HTTP API 只需要完成 HTTP 协议的解析即可。

QUIC 协议这么好，可以大规模切换为 QUIC 吗？

理想和现实总是有一定的差距：虽然经过多年的推广的应用，但 QUIC 协议目前仍未达到大量普及的阶段，在 IETF 上的 QUIC 依然还是草稿，并且还存在 Google QUIC 与 IETF QUIC 两类不稳定的协定。

而且，QUIC 还面临以下挑战：

1）小地方，路由封杀 UDP 443 端口（ 这正是 QUIC 部署的端口）

2）UDP 包过多，由于 QS 限定，会被服务商误认为是攻击，UDP 包被丢弃

3）无论是路由器还是防火墙目前对 QUIC 都还没有做好准备