【実務・中級編】 IEEE 802.3規格の概要と歴史的変遷 – インフラ・物理＆L2/L3ネットワーク基礎実践ガイド

イーサネットの源流と進化：IEEE 802.3が描き続けた「繋ぐ」の歴史

こんにちは。長年、データセンターの片隅でL2スイッチの唸り声を聞きながら、数々のネットワーク障害と向き合ってきたインフラアーキテクトです。

Web APIの設計やモダンなクラウドインフラの構築に日々奔走するエンジニアの皆さんにとって、「物理レイヤーやイーサネット規格の歴史」は、普段のアプリケーション層の仕事からは少し遠い世界に思えるかもしれません。しかし、JSONのペイロードがHTTPに乗せられ、TLSで暗号化され、TCPのセグメントに分解され、最終的にパケットとして物理的な銅線や光ファイバーを駆け抜けるとき、そのすべての土台を支えているのが、今回解説する IEEE 802.3 です。

今回は、ボブ・メトカーフがゼロックスのパロアルト研究所で描いた「エーテル（Ether）」の夢から始まり、現代の100GbE、そしてそれを超える超高速ネットワークへと至るIEEE 802.3の歴史と変遷を、現場の視点を交えながら紐解いていきます。

—

1. イーサネットの原点：共有媒体（Shared Medium）の時代

すべての始まりは1980年代初頭、DEC、インテル、ゼロックスの3社が共同で策定した「DIX仕様（Ethernet Version 1.0 / 2.0）」です。これをベースにIEEE（Institute of Electrical and Electronics Engineers）が標準化したのが、有名な IEEE 802.3 です。

初期のイーサネットは、1本の同軸ケーブル（太い黄色の「粗同軸」こと10BASE5、あるいは細い「細同軸」の10BASE2）を多数の端末でバス型に共有する形をとっていました。ここで使われていたのが、ネットワークエンジニアの基礎教養である CSMA/CD（Carrier Sense Multiple Access with Collision Detection：キャリア感知多元接続／衝突検出） です。

CSMA/CDのリアルな挙動

1. Carrier Sense（キャリア感知）: 送信したい端末は、まずケーブル上に他の信号が流れていないか（電圧の変化がないか）を盗み聞きします。
2. Multiple Access（多元接続）: 誰でも好きなタイミングでアクセスできます。
3. Collision Detection（衝突検出）: もし2台の端末が同時に話し始めると、電位が衝突し、波形が歪みます。これを即座に検知します。
4. Jam信号とバックオフ: 衝突を検知した端末は、全ノードに衝突を知らせる「ジャム信号」を流し、ランダムな時間（バックオフ・タイマー）だけ待ってから再送を試みます。

この仕組み、どこかで聞いたことありませんか？そう、無線LAN（Wi-Fi）のCSMA/CA（Collision Avoidance）や、初期のハブ（Hub）を使ったリピーターネットワークの挙動そのものです。

> 現場のTips: 古き良きリピーターハブ時代、コリジョン（衝突）が多発してスループットが劇的に落ちる現象に悩まされたシニアも多いはずです。現代のスイッチド・ネットワーク（フルデュプレックス）では、ポートごとにコリジョン・ドメインが完全に分離されるため、理論上CSMA/CDが発動する余地はありません。しかし、フレームフォーマットや最小フレームサイズ（64バイト）の制約として、このDNAは今も生き続けています。

—

2. 伝送メディアと速度の爆発的進化

IEEE 802.3は、単一のプロトコル名ではなく、膨大なサブ委員会の成果物の総称です。時代とともに、物理レイヤー（PHY）とメディア（Media）を変えながら、その伝送速度を数メガbpsから数百ギガbpsへと進化させてきました。

なぜツイストペアケーブルと「ツイスト（より対線）」なのか？

電気信号を銅線で送る際、外部からの電磁ノイズ（蛍光灯の安定器や電源ケーブルなど）がノイズとして乗り、データが化けます。ここで「2本の線を撚り合わせる（ツイストする）」という物理的な工夫が光ります。
外部からノイズが入ったとき、撚り合わされた2本の線には「ほぼ同じ大きさのノイズ」が乗ります。受信側でその2本の「差分（差動信号）」を読み取ることで、ノイズが綺麗に打ち消し合うのです。これぞ、物理レイヤーにおける究極のフィルタリング技術です。

—

3. スイッチングの仕組みとMACアドレステーブルの挙動

現代のネットワークを支えるL2スイッチは、IEEE 802.3で規定されたフレームを受け取り、賢く転送先を判断します。ここで重要な役割を果たすのが MACアドレス（Media Access Control Address） と MACアドレステーブル（ブリッジングテーブル） です。

スイッチがフレームを受信したとき、内部で以下のようなアルゴリズムが高速なASIC（専用ハードウェア）上で動作しています。

[フレーム受信] 
    │
    ├── 1. 学習 (Learning): 
    │     受信ポートと送信元MACアドレス(SA)をテーブルに記録（エージングタイマー設定）
    │
    └── 2. 転送 (Forwarding / Filtering):
          宛先MACアドレス(DA)がテーブルにあるか？
           ├── Yes ──> 該当するポート「のみ」へ転送 (Unicast)
           └── No  ──> 受信ポート以外の全ポートへフラッディング (Broadcasting/Flooding)

パラメーター：エージングタイマー（Aging Timer）

Cisco Catalystなどの一般的なL2スイッチでは、MACアドレステーブルのエージングタイマーのデフォルト値は通常 300秒（5分） に設定されています。
もし端末がネットワークから取り外されたり、シャットダウンされたりして300秒間トラフィックを送信しなくなると、スイッチはテーブルからそのエントリを自動的に削除します。これにより、レイアウト変更などで端末の接続ポートが変わった際も、ネットワークが正しく追従できるようになっています。

—

4. 実務で役立つ！ネットワークの「現在地」を観測するコードとコマンド

インフラエンジニアやSREとして、システムのパフォーマンス低下やパケットロスに直面したとき、L2/L3の物理・データリンク層の状態を正確に把握するスキルは必須です。

ここでは、Linux環境やPythonを用いて、インターフェースの統計情報やMACアドレスの動きを観測・診断する実用的なスニペットを紹介します。

① Linuxでの物理・リンク層ステータス確認（ip / ethtool）

まずは、カーネルが認識しているインターフェースのリンクアップ状態、速度、デュプレックス（全二重/半二重）を確認します。

# 1. インターフェースの物理状態とMACアドレスを確認
$ ip link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff

# 2. リンクの速度やネゴシエーション状態を詳細に確認（ethtool使用）
$ sudo ethtool eth0
Settings for eth0:
	Supported ports: [ TP ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Supported pause frame use: Symmetric
	Supports auto-negotiation: Yes
	Advertised link modes:  1000baseT/Full 
	Speed: 1000Mb/s              # 現在1Gbpsでリンクアップ中
	Duplex: Full                 # 全二重通信（コリジョンなし）
	Auto-negotiation: on
	Port: Twisted Pair

> 現場のTips: 障害対応時、「Pingは通るが極端に遅い、パケットロスする」という場合、ethtoolで確認すると片方の機器が何らかの理由で 100Mb/s / Half Duplex に落ち込んでいる（Duplexミスマッチ）ケースがあります。古い機器やオートネゴシエーションを無効化したポートとの接続では、今でも起こりうる古典的なトラップです。

—

② PythonによるL2/パケットキャプチャの基本（Scapyライブラリ）

Web APIやアプリケーションのレイヤーからは見えない「イーサネットフレームのヘッダー」を直接触ることで、パケットの構造を深く理解できます。Pythonの強力なパケット操作ライブラリ Scapy を使ったサンプルコードです。

from scapy.all import sniff, Ether, IP

def packet_callback(packet):
    """
    受信したパケットをフックし、イーサネットヘッダーとIPヘッダーの情報を解析するコールバック関数
    """
    # イーサネット層のパケットかチェック
    if packet.haslayer(Ether):
        eth_layer = packet.getlayer(Ether)
        src_mac = eth_layer.src
        dst_mac = eth_layer.dst
        eth_type = hex(eth_layer.type)
        
        print(f"[Ethernet Frame] Src MAC: {src_mac} -> Dst MAC: {dst_mac} | Type: {eth_type}")
        
        # IPレイヤーの情報があれば表示
        if packet.haslayer(IP):
            ip_layer = packet.getlayer(IP)
            print(f"  └─ [IP Packet] {ip_layer.src} -> {ip_layer.dst} (Proto: {ip_layer.proto})")

if __name__ == "__main__":
    print("=== パケットキャプチャを開始します (Ctrl+Cで終了) ===")
    # eth0インターフェースでパケットを10個スニッフする
    # ※ 実行にはroot権限が必要です
    sniff(iface="eth0", prn=packet_callback, count=10)

このコードを実行すると、OSのネットワークカードが受信したイーサネットフレームの宛先・送信元MACアドレス（Ethernet II ヘッダー）がコンソールに流れます。Web APIのリクエストがどのMACアドレス（ルーターのインターフェースなど）を経由して流れているのかが直感的に理解できます。

—

5. まとめ：歴史を知る者が、現代の複雑なネットワークを制す

IEEE 802.3の歴史は、銅線や光ファイバーという物理的な制約のなかで、「いかに速く、いかに遠くへ、いかに確実にデータを運ぶか」というエンジニアたちの知恵の結晶です。

クラウド、コンテナ、マイクロサービス、そしてモダンなAPIアーキテクチャがどれほど抽象化され、レイヤーが高くなろうとも、その足元では必ずIEEE 802.3で規定されたフレームが、厳密なタイミングと物理法則に従ってスイッチのポートを駆け巡っています。

インフラのトラブルシューティングやパフォーマンスチューニングにおいて、「見えないレイヤー」を想像できる力は、プロフェッショナルエンジニアにとって最大の武器になります。ぜひ今日の業務から、ip link や ethtool を叩いて、自分の足元にあるイーサネットの世界を覗いてみてください。