Network

最近在看 TC 和 eBPF 相关的一些介绍。TC 本身的概念比较复杂，想要理清并不容易。加上 eBPF 的引入就更复杂了。本文用来记录与此相关的一些发现。 clsact clsact 即是用来给 TC + eBPF 是使用的一个 qdisc. qdisc 可以简单理解为使用某种算法(FIFO)的 Queue. clsact 的特点是: 不用排队 主要就是为了 attach ebpf 用的 在 ingress/egress 都提供了 hook lock free ingress 与 egress 的不同 不太确定直接的原因是啥，目前的 qdisc 只在 egress 方向上有。一般的 rate-limiting 都是在 egress 上实现， ingress上的比较困难。一个原因是难以对源头进行限速。 multiple qdisc 多个 qdisc 在 egress 上是很常见的。加了 clasact 之后就更常见了。那么 clsact 和他们什么关系？ 这是我从另一个 Topic 摘过来的图。可以看出来， clsact 是在普通的 qdisc 之前的。 direct-action mode 请参考: Understanding tc “direct action” mode for BPF ...

很多大厂的LB都是自研的，而且设计考量都不相同。本文介绍 Dropbox自研的LB，名字叫 Bandaid.参考链接: Meet Bandaid, the Dropbox service proxy. Queue设计 Bandaid 处理 Queue 中的 Request 的思路是后近先出(Last in, First out)。当系统负载不高的时候，Queue中的数据其实不多，那么先进后出或者后进先出其实区别不大。如果负载过高，考虑到先进的排队太久，可能很快就timeout了，还不如优先处理后进来的 request. User Space的 Read Queue Read Requests 会被放到一个用户态的 Queue 中，而不是 kernel 里的 queue中。这样做的原因是， 可以在用户态提前关闭已经被 client close的 request, 而不是等到真正的request经由 kernel, 然后 application 在处理的时候才发现 request 已经 close 了。尤其是 client 一般还带有重试，很容易把 Kernel queue打满。User Space 的 Queue 能够通过处理只把正常的 request 传给后面。 权重以及 Route划分 精细程度可以做到按照 Route 将一个 Service 的重要的 Route 以及不重要的 Route 按权重定向到不同的 Backend上。不同的 Queue 可以有不同的权重，rate limit, 并发度。

主要问题 解决方法 使用受信任的 DNS 解析服务器 DoH QNAME minimization 其他问题 Links HTTPS 已经越来越普及了，包括 Github Pages 都可以很方便的集成。浏览器也开始通过各种手段来促进网站都尽量使用 HTTPS。相比来说， DNS 的安全性受重视的程度就没那么高。Firefox 写了一个一篇非常好的介绍文章(见最后 Links)，系统性地介绍了当前的问题以及解决方案。在这里整理一下。 主要问题 DNS 协议主要交流的信息就两个：ip 和 domain, 这两个东西一般来说，很不起眼，但是漏洞(非安全协议)摆在这，总会有各种不法分子来作恶。目前我能想到的比较明显的两个就是 运营商劫持： 一个不靠谱的运营商，在各个网站插入各种恶心的广告, 重定向网址等 不安全的公共网络: 比如公共场所的 wifi, 可以伪造各种网站，收集用户的上网记录等等 火狐也在文章中写出了 dns 查询过程中可能出现的安全漏洞： 主要有三个 不可靠的本地 dns 服务器 中间人攻击 一些根域名服务器能追踪你的解析记录。 解决方法 这几个问题，火狐都列出了解决方法。 使用受信任的 DNS 解析服务器 一般用户，包括互联网从业者，都不太关心本地配置的 dns 服务器是什么,一般都是运营商默认的。一般人也没有精力(能力)在出问题的时候去根运营商协调解决。火狐的思路是在用户使用浏览器的时候（不干涉其他程序），选择火狐信任的 dns 服务器来进行 dns 查询（可配置为失败时 fallback 到机器默认的）。目前火狐是和 cloudflare 合作，由 cloudflare 来提供域名解析服务，未来应该会有更多的提供商。 目前的 Firefox 66 版本已经支持了此选项（不一定是最早支持版本）,可以在 about:config 里面搜索 trr 查询到: ...