ややマイナーなネットワーク理論 (1)
ここで言うマイナーとは、僕にとって普段あまり耳にしない技術用語や理論のことだ。
ソフトウェアエンジニアにとって、OSI参照モデルでは普段トランスポート層以上を扱うことが多い。よく使われるTCP/IPやHTTPプロトコルなどは、詳細までは知らなくても、大体どのように動作しているかは知っているだろう。逆に、それより下の層に触れる機会は比較的少ない。
しかし物理層では、ソフトウェアの実装よりも考慮すべき詳細事項が実はかなり多い。特に物理信号の伝送は、比較的不安定でノイズに満ちた環境下で動作するため、設計時にはこれらの要因を考慮に入れる必要がある。
エンコーディング
データはネットワーク内でどのようにエンコードされるのだろうか?ファイルの内容が何であれ、伝送を実現するためには最終的にデータを高電位や低電位といった物理信号に変換する必要がある。データをコンピュータが処理しやすいように異なる形式や構造に変換するプロセスのことを、通常はエンコーディング(Encoding)と呼ぶ。
回路上でも同様で、一般的には高電位を 1、低電位を 0 とみなす。
NRZ(Non-Return-to-Zero)
NRZはデジタル通信における符号化方式の一つで、電圧によってビットの値を表す。
NRZ符号化の特徴は、各単位時間内において信号の電圧が一定に保たれ、次のビット時間が始まるまで変化しないことだ。
ここで非常に重要な点は「単位時間」内ということであり、これは各ビット間の間隔が一定であることを意味する。なぜなら送受信双方にとって、データストリームをどのように読み取るべきかを知るために統一されたクロック信号(周期信号)が必要であり、そうでなければ全く異なる結果を読み取ってしまう可能性があるからだ。

クロックが速すぎたり遅すぎたりすると、データに誤りが生じる可能性がある。しかし、ここで問題が生じる。双方はどうやってクロック周波数を知るのだろうか?クロック信号用にもう1本別のライン(配線)を追加することも可能だが、実用上はできるだけ配線を減らしたい。さらに、データが長時間同じ電位のままだと、同期がずれてしまう可能性が高い。
Clock Recovery
実際の応用では、元のクロック周波数がいくらであるかをソース信号から推測し、受信側で対応する周期波を生成してデコードを行う。このプロセスをクロックリカバリ(Clock Recovery)と呼ぶ。
クロックリカバリはおおよそ以下のいくつかのステップに分けられる:
- トランジション(遷移)の検出。通常は遅延回路を用いて行える
- FFT(高速フーリエ変換)による周期の特定
- 位相同期回路(PLL: Phase-locked loops)による信号の同期
クロックリカバリの詳細な原理はWikipediaなどを参考にしてほしいが、最も主要な目的は、基準信号の周波数に変化が生じた際にフィードバックを通じて位相や周波数を調整し、両者を一致させることだ。
しかしこれにも問題がある。もしデータが高電位または低電位のまま維持されたら、周波数が全くわからなくなってしまうのではないか?この問題を解決するために、他の符号化方式も採用されている。
マンチェスター符号化
データストリームをずっと低電位や高電位のままにしたくないのであれば、電位を常に変化させればいい!マンチェスター符号化は非常に賢い方法で 0 と 1 を判別する。
マンチェスター符号化は、高低電位の変化を 0 と 1 とする。
0:低電位から高電位への変化1:高電位から低電位への変化
こうすれば、元のデータが連続する 0 や 1 であっても、電位が常に変化するため問題なく、効果的にクロックリカバリを行うことができる。IEEE 802.3 もこの符号化方式を採用している。しかし、この方式の最大の欠点は、伝送帯域幅がNRZの2倍必要になることだ。1周期の中で電位の変化を検出する必要があるため、実際には2倍の帯域幅が求められる。
4B/5B
関連記事
- 測定が目標になるとき:窓税からPull Request数まで かつて僕は小さなツールを自作し、四半期で自分がどれだけPRに貢献したか、レビューコメントをどれだけ残したか、チケットをどれだけ消化したかを集計して、上司にアウトプットを証明しようとしたことがある。上司は淡々と、評価はアウトプットだけで見るものではないと言った。数年後、僕はようやく理解した――測定が目標になるとき、それはもはや良い測定ではなくなるのだ。英国の窓税、ハノイのネズミ駆除の報奨金から、現代のPR数による開発者評価に至るまで、そのメカニズムはまったく同じだ。
- Cloudflare Images を画像ストレージ・変換ソリューションとして使う ウェブページに画像を1枚置くのはフロントエンドにとって最も簡単なことだが、リサイズや各種フォーマットの生成、さらにはトラフィックの負荷に耐えることまで完璧にやろうとすると、実際には一つの包括的なソリューションが必要になる。僕はその後、すべて Cloudflare Images に任せるようになり、オリジナル画像1枚だけを渡すようにしている。
- もう AWS Access Key を使うのはやめよう Access Key は AWS において見落とされがちなセキュリティリスクだ。OIDC と IAM Role を組み合わせることで、GitHub Actions にシークレットを一切保持させることなく、安全に AWS リソースを操作できるようにする。
- データベース主キー:AUTO_INCREMENT、UUID、そしてUUIDv7 バックエンド開発で度々直面する主キーの決定。auto incrementを使うべきか、それともUUIDか?衝突への懸念は?UUIDv7とcreated_at + インデックスの性能差はどれほどか?実際に2,000万件のデータで検証したベンチマークと設計上の意思決定を解説する。