少しマニアックなネットワーク理論 (2)
前回の記事では、マンチェスター符号化によってデータストリームが 0 や 1 ばかりになる状況を効果的に解決できるものの、同じデータ量に対して 2 倍の帯域幅が必要となり、高速伝送においては望ましくないことに触れた。
今回紹介する 4B/5B 符号化は、データストリームが 0 や 1 ばかりになる状況を効果的に解決しつつ、帯域幅をそれほど犠牲にしない手法だ。
4B/5B
4B/5B は、元のデータを 4 ビットごとのグループから、5 ビットごとのグループへと変換するものだ。これにより、0000 や 1111 といったデータストリームであっても、符号化によってすべてが 0 や 1 になるのを防ぎ、クロックを復元できなくなる状況を回避できる。
| 4bit | 5bit |
|---|---|
| 0000 | 11110 |
| 0001 | 01001 |
| 0010 | 10100 |
| 0011 | 10101 |
| 0100 | 01010 |
| 0101 | 01011 |
| 0110 | 01110 |
| 0111 | 01111 |
| 1000 | 10010 |
| 1001 | 10011 |
| 1010 | 10110 |
| 1011 | 10111 |
| 1100 | 11010 |
| 1101 | 11011 |
| 1110 | 11100 |
| 1111 | 11101 |
0000 と 1111 を観察してみると、5 ビットに変換された後は必ず 1 つのトランジション(ハイレベルからローレベル、またはその逆への遷移)が保証されていることがわかる。1 ビット増えるため、同じデータ量を伝送するのに 20% 余分な帯域幅が必要になるが、マンチェスター符号化と比べれば遥かに優れている。1000BASE-X では 8B/10B 符号化が使用されており、概念的には 4B/5B と同じで、一度に 8 ビットを符号化するようになっている。8B/10B は 1000BASE-X 以外にも、PCI 1.0/2.0 や USB3 など、さまざまな高速伝送プロトコルで使われている。
8B1Q4
2023 年を生きる僕たちにとって、有線 LAN の速度は 1Gbps が当たり前で、さらなる帯域幅を求めるなら 10Gbps にもなる。
一般的なイーサネットケーブルの内部は、絶縁されたワイヤがペアになって互いにねじり合わされている。このねじり合わせによってノイズを効果的に低減できる。それでも、周波数が非常に高くなるとノイズの干渉を受けやすくなる。

100BASE-TX 以上の伝送では、8B1Q4(8 binary to 1 quinary 4)で符号化が行われる。主な原理は、同一クロックサイクル内で複数のビットを送信することでデータ量を増大させる点にある。例えば CAT-6 は伝送周波数が 125MHz であるものの、伝送速度は 1Gbps に達する。
8B1Q4 は簡単に言えば、8 ビット + 1 ビット(誤り検出用ビット)を 4 組に分割する。上の画像を見ると合計 4 組のペア線があるのがわかるが、グループ分けした後にそれぞれ異なる電位(電圧レベル)で表現する。
では、実際にどうやって 9 ビットのデータを 4 組に分割するのだろうか?まずチェックサム + データの先頭 2 ビットの計 3 ビットを参照して対応する変換テーブルを探し、残りの 6 ビットはその見つかった変換テーブルに基づいて符号化する。特徴的なのは、各ケーブルの電位が 5 段階あることで、単なるハイレベルとローレベルだけではない点だ。この方法によって、1 サイクル内で 2 ビットを伝送でき、同じ帯域幅で伝送量が 2 倍になる。
これこそが、CAT-6 の伝送周波数が 125MHz でありながら、伝送速度が 1Gbps になる理由だ。
関連記事
- 測定が目標になるとき:窓税から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万件のデータで検証したベンチマークと設計上の意思決定を解説する。