最近読んだ記事メモ (keywords: RHEL, BPF, IETF, DNS, Linux Distribution, Load Balancing, Internet History)

Bob Kahn on the Birth of “Inter-networking” - IEEE Spectrum

https://spectrum.ieee.org/bob-kahn

Bob Kahnは、最初のノードがパケットスイッチングネットワークに接続された場にいて、Vint Cerfと一緒に働きました。彼は、インターネットの基礎が接続された1960年代と70年代のいくつかの思い出を共有しています。

「パケット」という言葉がまだ導入されていなかったとき、彼らは「discrete addressed message blocks」という言葉を使用していたらしい。 Vint Cerfはホストプロトコルを開発しました - これはコンピュータがお互いに話すために使用されるプロトコルです。 1972年、Bob Kahnは“Communication Principles for Operating Systems.”という内部BBNレポートを書きました。この論文は、ネットワークがパケットを完全に配送すると仮定したホストプロトコルを見直し、ネットワークの損失に対処する新しいプロトコルに置き換えることを主張しました。このレポートは、TCP / IPのはじまりでした。

Load Balancing - SamWho

https://samwho.dev/load-balancing/

イラストを用いたロードバランシングの基本の説明。

ロードバランシングの初心者(私)にとって非常にわかりやすかった。 Round robinはまだnginxのデフォルトのHTTPロードバランシング方法。 "peak exponentially weighted moving average"「ピーク指数加重移動平均」(またはPEWMA)は、レイテンシを最小化するのに非常に適したアルゴリズムです。 このアルゴリズムは、最後のNリクエストからのレイテンシを追跡し、値を合計しますが、古いリクエストよりも最近のリクエストが計算に大きく影響を与えるように、スケールファクターが指数関数的に減少します。その値は取られてサーバーへのオープンコネクションの数に掛けられ、結果が最も少ないサーバーが次のリクエストを送信するサーバーとして選ばれます。 著者によるアドバイスアルゴリズムを選択する際にベンチマークを取ることは非常に重要であるということ。 視覚的に説明を行ったこのページはPixiJSを使って作られた。

Keep Linux Open and Free—We Can’t Afford Not To - Oracle July 10, 2023

https://www.oracle.com/news/announcement/blog/keep-linux-open-and-free-2023-07-10/

6月21日にRedHadが行ったこと:CentOSは非常に人気のある無料のRHEL互換のディストリビューションでした。2020年12月に、IBMはそれをRHELの無料の代替品として事実上殺しました。CentOSの代わりに2つの新しいRHELの代替品が登場しました:AlmaLinuxとRocky Linux。今、RHELソースコードを保留することで、IBMは直接それらを攻撃しました。 このブログでOracleは次の約束をします:OracleLinuxを配布する限り、その配布のバイナリとソースコードを公にして自由に利用できるようにします。さらに、Oracleはあらゆる種類のコミュニティと商用の下流ディストリビューションを歓迎します。

最後けっこう喧嘩腰の文章で面白かった。

Finally, to IBM, here’s a big idea for you. You say that you don’t want to pay all those RHEL developers? Here’s how you can save money: just pull from us. Become a downstream distributor of Oracle Linux. We will happily take on the burden.

At SUSE We Make Choice Happen - SUSE July 11, 2023

https://www.suse.com/c/at-suse-we-make-choice-happen/

SUSEは、RHELをフォークし、それをSUSE Liberty Linuxという互換ディストリビューションとしてリリースすることを発表しました。

BPF:作業をIETFに持ち込む - IETF Blog

https://www.ietf.org/blog/bpf/ David VernetBPF Working Group Co-chair Suresh KrishnanBPF Working Group Co-chair 2023年7月5日

BPFの実装とデプロイの数が増えるにつれて、さらなる採用を支持するためどのような標準化が適切で必要かについての議論がありました。いくつかの選択肢が2021年12月にLinux Foundationの下で設立されたeBPF Foundationによって検討され、最終的に、eBPF Steering Committee は、その開放性、プロセスの相対的な容易さとグローバルな範囲、そしてネットワーキングおよび非ネットワーキングの両方のトピックでのその機関的経験のある、IETFでの標準化を追求することを決定しました。

今に至るまで、BPFとIETFコミュニティのメンバー間で議論がありました。IETF 115のサイドミーティングでBPF標準化を議論し、IETFがその標準化の適切な場所であるかどうかを探求され、IETFメーリングリストでの議論も行われました。そして2023年3月のIETF 116会議での正式なBirds of Featherセッションに続きました。これらの議論は、2023年5月にBPFワーキンググループの正式な憲章へとつながりました。

ほとんどのIETFワーキンググループとは少し異なり、グループの議論はbpf@ietf.orgとbpf@vger.kernel.orgのメーリングリストで同時に行われます。両方のリストのアーカイブは誰でも見ることができます。ワーキンググループの文書に変更を提案するには、bpf-next.gitカーネルツリーにパッチを作成し、そのパッチを議論とレビューのために両リストにメールで送信します。

Measuring NXDOMAIN responses

https://blog.apnic.net/2023/07/12/measuring-nxdomain-responses/ APNIC blog by Geogf Huston

権威サーバは、問い合わせた名前がゾーンで定義されていない場合にNXDOMAINレスポンスを送信します。 NODATAレスポンス、つまりNOERRORレスポンスコード(0)は、名前は定義されているがその名前に対するリソースレコード(RR)が存在しないことを示すため、それとは異なります。 現在、ルートサーバから見たNXDOMAINレスポンスのレートは50-65%の間です。 この数字は、以前はChromeブラウザがランダムなDNSクエリを送信し、ブラウザがNXDOMAIN substitutionを実行するDNS環境にあるかどうかを判断するため、はるかに高かったです。NXDOMAIN substitutionとは、ローカルのDNSがNXDOMAINレスポンスであるべきクエリへの応答を、他のインターネットサービスを指す応答に置き換えて返すことを指します。これにより、ISPは自分たちのDNSサーバからのNXDOMAINレスポンスを非常に少ないコストで収益化できます。Googleはこれを好ましく思っていません。 通常の従来のNOERRORが返るクエリは再帰ゾルバでキャッシュされるためルートサーバに頻繁に問い合わせされることはないが、Chromeから送信されるランダム文字列クエリはキャッシュに残っていないためルートサーバに問い合わせが届くため、ランダムな問い合わせはルートサーバの問い合わせ率に大きく影響を与えます。 ICANによってLルートサーバで行われた分析では、全てのNXDOMAINクエリ名のトップTLDの10%が.local(AppleマルチキャストDNSで使用)であることが示されました。 再帰ゾルバ側からの分析もCloudflare 1.1.1.1によって提供されブログで示されていました。。