<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Network on 涯余的博客</title><link>https://hangyan.github.io/categories/network/</link><description>Recent content in Network on 涯余的博客</description><generator>Hugo</generator><language>zh</language><managingEditor>hang.yan@hotmail.com (涯余)</managingEditor><webMaster>hang.yan@hotmail.com (涯余)</webMaster><lastBuildDate>Sat, 18 Dec 2021 19:29:35 +0800</lastBuildDate><atom:link href="https://hangyan.github.io/categories/network/index.xml" rel="self" type="application/rss+xml"/><item><title>TC 的一些有趣功能</title><link>https://hangyan.github.io/post/2021-tc-ebpf/</link><pubDate>Sat, 18 Dec 2021 19:29:35 +0800</pubDate><author>hang.yan@hotmail.com (涯余)</author><guid>https://hangyan.github.io/post/2021-tc-ebpf/</guid><description>&lt;p&gt;最近在看 TC 和 eBPF 相关的一些介绍。TC 本身的概念比较复杂，想要理清并不容易。加上 eBPF 的引入就更复杂了。本文用来记录与此相关的一些发现。&lt;/p&gt;
&lt;h2 id="clsact"&gt;clsact&lt;/h2&gt;
&lt;p&gt;&lt;code&gt;clsact&lt;/code&gt; 即是用来给 TC + eBPF 是使用的一个 &lt;code&gt;qdisc&lt;/code&gt;. &lt;code&gt;qdisc&lt;/code&gt; 可以简单理解为使用某种算法(FIFO)的 Queue. &lt;code&gt;clsact&lt;/code&gt; 的特点是:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;不用排队&lt;/li&gt;
&lt;li&gt;主要就是为了 attach ebpf 用的&lt;/li&gt;
&lt;li&gt;在 ingress/egress 都提供了 hook&lt;/li&gt;
&lt;li&gt;lock free&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="ingress-与-egress-的不同"&gt;ingress 与 egress 的不同&lt;/h2&gt;
&lt;p&gt;不太确定直接的原因是啥，目前的 qdisc 只在 egress 方向上有。一般的 rate-limiting 都是在 egress 上实现， ingress上的比较困难。一个原因是难以对源头进行限速。&lt;/p&gt;
&lt;h2 id="multiple-qdisc"&gt;multiple qdisc&lt;/h2&gt;
&lt;p&gt;多个 qdisc 在 egress 上是很常见的。加了 clasact 之后就更常见了。那么 clsact 和他们什么关系？&lt;/p&gt;
&lt;p&gt;&lt;img loading="lazy" src="https://hangyan.github.io/images/2021-tc-ebpf/clsact-qdisc.png"&gt;&lt;/p&gt;
&lt;p&gt;这是我从另一个 Topic 摘过来的图。可以看出来， clsact 是在普通的 qdisc 之前的。&lt;/p&gt;
&lt;h2 id="direct-action-mode"&gt;direct-action mode&lt;/h2&gt;
&lt;p&gt;请参考: &lt;a href="https://qmonnet.github.io/whirl-offload/2020/04/11/tc-bpf-direct-action/"&gt;Understanding tc “direct action” mode for BPF&lt;/a&gt;&lt;/p&gt;</description></item><item><title>LB系列1 - Bandaid</title><link>https://hangyan.github.io/post/2021-lb-1-bandaid/</link><pubDate>Mon, 18 Jan 2021 13:33:12 +0800</pubDate><author>hang.yan@hotmail.com (涯余)</author><guid>https://hangyan.github.io/post/2021-lb-1-bandaid/</guid><description>&lt;p&gt;很多大厂的LB都是自研的，而且设计考量都不相同。本文介绍 Dropbox自研的LB，名字叫 Bandaid.参考链接: &lt;a href="https://dropbox.tech/infrastructure/meet-bandaid-the-dropbox-service-proxy"&gt;Meet Bandaid, the Dropbox service proxy&lt;/a&gt;.&lt;/p&gt;
&lt;h2 id="queue设计"&gt;Queue设计&lt;/h2&gt;
&lt;p&gt;&lt;img loading="lazy" src="https://dropbox.tech/cms/content/dam/dropbox/tech-blog/en-us/2018/03/1st.png"&gt;&lt;/p&gt;
&lt;p&gt;Bandaid 处理 Queue 中的 Request 的思路是后近先出(Last in, First out)。当系统负载不高的时候，Queue中的数据其实不多，那么先进后出或者后进先出其实区别不大。如果负载过高，考虑到先进的排队太久，可能很快就timeout了，还不如优先处理后进来的 request.&lt;/p&gt;
&lt;h2 id="user-space的-read-queue"&gt;User Space的 Read Queue&lt;/h2&gt;
&lt;p&gt;Read Requests 会被放到一个用户态的 Queue 中，而不是 kernel 里的 queue中。这样做的原因是， 可以在用户态提前关闭已经被 client close的 request, 而不是等到真正的request经由 kernel, 然后 application 在处理的时候才发现 request 已经 close 了。尤其是 client 一般还带有重试，很容易把 Kernel queue打满。User Space 的 Queue 能够通过处理只把正常的 request 传给后面。&lt;/p&gt;
&lt;p&gt;&lt;img loading="lazy" src="https://dropbox.tech/cms/content/dam/dropbox/tech-blog/en-us/2018/03/2nd.png"&gt;&lt;/p&gt;
&lt;h2 id="权重以及-route划分"&gt;权重以及 Route划分&lt;/h2&gt;
&lt;p&gt;&lt;img loading="lazy" src="https://dropbox.tech/cms/content/dam/dropbox/tech-blog/en-us/2018/03/4th.png"&gt;&lt;/p&gt;
&lt;p&gt;精细程度可以做到按照 Route 将一个 Service 的重要的 Route 以及不重要的 Route 按权重定向到不同的 Backend上。不同的 Queue 可以有不同的权重，rate limit, 并发度。&lt;/p&gt;</description></item><item><title>更安全的 DNS</title><link>https://hangyan.github.io/post/2019-04-04-more-secure-dns/</link><pubDate>Thu, 04 Apr 2019 20:56:03 +0800</pubDate><author>hang.yan@hotmail.com (涯余)</author><guid>https://hangyan.github.io/post/2019-04-04-more-secure-dns/</guid><description>&lt;!-- toc --&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href="https://hangyan.github.io/post/2019-04-04-more-secure-dns/#%e4%b8%bb%e8%a6%81%e9%97%ae%e9%a2%98"&gt;主要问题&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="https://hangyan.github.io/post/2019-04-04-more-secure-dns/#%e8%a7%a3%e5%86%b3%e6%96%b9%e6%b3%95"&gt;解决方法&lt;/a&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href="https://hangyan.github.io/post/2019-04-04-more-secure-dns/#%e4%bd%bf%e7%94%a8%e5%8f%97%e4%bf%a1%e4%bb%bb%e7%9a%84dns%e8%a7%a3%e6%9e%90%e6%9c%8d%e5%8a%a1%e5%99%a8"&gt;使用受信任的 DNS 解析服务器&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="https://hangyan.github.io/post/2019-04-04-more-secure-dns/#doh"&gt;DoH&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="https://hangyan.github.io/post/2019-04-04-more-secure-dns/#qname-minimization"&gt;QNAME minimization&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;&lt;a href="https://hangyan.github.io/post/2019-04-04-more-secure-dns/#%e5%85%b6%e4%bb%96%e9%97%ae%e9%a2%98"&gt;其他问题&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="https://hangyan.github.io/post/2019-04-04-more-secure-dns/#links"&gt;Links&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;!-- tocstop --&gt;
&lt;p&gt;HTTPS 已经越来越普及了，包括 Github Pages 都可以很方便的集成。浏览器也开始通过各种手段来促进网站都尽量使用 HTTPS。相比来说，
DNS 的安全性受重视的程度就没那么高。Firefox 写了一个一篇非常好的介绍文章(见最后 Links)，系统性地介绍了当前的问题以及解决方案。在这里整理一下。&lt;/p&gt;
&lt;h2 id="主要问题"&gt;主要问题&lt;/h2&gt;
&lt;p&gt;DNS 协议主要交流的信息就两个：ip 和 domain, 这两个东西一般来说，很不起眼，但是漏洞(非安全协议)摆在这，总会有各种不法分子来作恶。目前我能想到的比较明显的两个就是&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;运营商劫持： 一个不靠谱的运营商，在各个网站插入各种恶心的广告, 重定向网址等&lt;/li&gt;
&lt;li&gt;不安全的公共网络: 比如公共场所的 wifi, 可以伪造各种网站，收集用户的上网记录等等&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;火狐也在文章中写出了 dns 查询过程中可能出现的安全漏洞：&lt;/p&gt;
&lt;p&gt;&lt;img loading="lazy" src="https://hacks.mozilla.org/files/2018/05/03_04-768x383.png"&gt;&lt;/p&gt;
&lt;p&gt;主要有三个&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;不可靠的本地 dns 服务器&lt;/li&gt;
&lt;li&gt;中间人攻击&lt;/li&gt;
&lt;li&gt;一些根域名服务器能追踪你的解析记录。&lt;/li&gt;
&lt;/ol&gt;
&lt;h2 id="解决方法"&gt;解决方法&lt;/h2&gt;
&lt;p&gt;这几个问题，火狐都列出了解决方法。&lt;/p&gt;
&lt;h3 id="使用受信任的-dns-解析服务器"&gt;使用受信任的 DNS 解析服务器&lt;/h3&gt;
&lt;p&gt;一般用户，包括互联网从业者，都不太关心本地配置的 dns 服务器是什么,一般都是运营商默认的。一般人也没有精力(能力)在出问题的时候去根运营商协调解决。火狐的思路是在用户使用浏览器的时候（不干涉其他程序），选择火狐信任的 dns 服务器来进行 dns 查询（可配置为失败时 fallback 到机器默认的）。目前火狐是和 cloudflare 合作，由 cloudflare 来提供域名解析服务，未来应该会有更多的提供商。&lt;/p&gt;
&lt;p&gt;目前的 Firefox 66 版本已经支持了此选项（不一定是最早支持版本）,可以在 &lt;code&gt;about:config&lt;/code&gt; 里面搜索 &lt;code&gt;trr&lt;/code&gt; 查询到:&lt;/p&gt;</description></item></channel></rss>