【実務・中級編】カットスルー（Cut-Through）方式およびフラグメントフリー方式の高速転送メカニズム – インフラ・物理＆L2/L3ネットワーク基礎実践ガイド

0.1マイクロ秒の攻防：カットスルー・スイッチングがもたらす「速さ」と「代償」

ネットワークエンジニアとして現場に立っていると、「低遅延（Low Latency）」という言葉が魔法のように響く瞬間がある。HFT（高頻度取引）のような極限の世界はもちろん、現代のマイクロサービスアーキテクチャにおいても、API間の通信遅延を削ることはUXに直結する。

今日は、スイッチングの深淵、特に「カットスルー（Cut-Through）」方式について語ろう。教科書には「宛先MACを見てすぐ転送する」と一行で書かれているが、その裏側には、物理層からMAC層にかけての冷徹なトレードオフが存在している。

—

1. ストア＆フォワード vs カットスルー：哲学の対立

一般的なスイッチは「ストア＆フォワード（Store-and-Forward）」を採用している。これは、一度フレーム全体を受信し、FCS（Frame Check Sequence）を計算してエラーがないことを確認してから送出する方式だ。いわば「検品してから出荷する」丁寧な仕事だ。

一方で、カットスルーは「見てすぐ投げる」。
イーサネットフレームの先頭、宛先MACアドレス（Destination MAC）である6バイトを読み取った瞬間、スイッチは出力ポートを決定し、フレームの後続が到着するのを待たずに転送を開始する。

なぜこれが危険なのか？

ストア＆フォワードなら弾けたはずの「壊れたフレーム（RuntsやFCSエラー）」が、そのまま下流へ流れ込んでしまう。インフラ運用において、これは「エラーの伝播」という厄介な爆弾を抱えることを意味する。

—

2. 第3の選択肢：フラグメントフリー（Fragment-Free）

カットスルーの欠点を補うために生まれたのがフラグメントフリー方式だ。
イーサネットの衝突（Collision）の多くは、64バイト目までに発生するという統計がある。そこで、フレームの先頭から64バイト目までを受信した時点で転送を開始する。これにより、極端に短い不正フレーム（コリジョンによるフラグメント）を排除しつつ、遅延を最小限に抑えることができる。

現代のデータセンター向けスイッチ（Cisco NexusやAristaなど）は、このあたりを動的に制御するアルゴリズムを積んでいることが多い。

—

3. 実務的な確認手法：パケットロスをどう追うか

カットスルー環境で問題が発生した場合、エラーフレームがどこで発生しているかの特定が極めて困難になる。「スイッチが壊れた！」と疑う前に、まずはCLIで物理ポートの統計を確認する習慣をつけよう。

例えば、Cisco Nexusスイッチであれば、以下のコマンドでエラーの増分を監視する。

# 特定ポートのCRCエラーやRunts（64バイト未満のフレーム）を監視
show interface ethernet 1/1 counters errors

# 出力例で見るべきポイント
# FCS-Err: 転送中のフレームが破損している（カットスルーではここで検知される）
# Runts: フラグメントフリーで弾けなかったゴミが流れている可能性がある

—

4. API設計と遅延：ネットワーク層の視点

インフラエンジニアがAPI開発者に伝えたいのは、「物理層の遅延は、アプリケーション層のタイムアウト値に跳ね返る」という事実だ。

例えば、PythonでAPIの応答時間を計測する場合、低遅延スイッチを通る環境とそうでない環境では、100回程度のハンドシェイクを繰り返すと明確な差が出る。

import requests
import time

def measure_api_latency(url):
    # 接続にかかる時間を詳細に計測
    start_time = time.perf_counter()
    try:
        response = requests.get(url, timeout=2)
        end_time = time.perf_counter()
        # ネットワーク遅延の揺らぎをキャッチするロジック
        return end_time - start_time
    except requests.exceptions.RequestException as e:
        print(f"ネットワークエラー: {e}")

# 低遅延なネットワーク環境下でのAPI疎通テスト
print(f"Latency: {measure_api_latency('http://internal-api.local/data'):.4f} seconds")

もし、カットスルー・スイッチの設定ミスやケーブルの品質劣化によりFCSエラーが頻発していると、TCPの再送処理が走り、measure_api_latency の値は劇的に悪化する。ネットワーク側で「なんとなく遅い」と感じたら、まずは ifconfig や ethtool -S でNIC側のエラーカウンタを確認してほしい。

# Linuxホスト側での確認コマンド
ethtool -S eth0 | grep -E "crc|frame|drop"
# ここでcrc_errorsがインクリメントされていたら、
# スイッチ側かケーブルの問題を疑うべきサインだ

—

5. 最後に：エンジニアとしての心得

カットスルー方式は、現代の高速ネットワークにおける「諸刃の剣」だ。

メリット: マイクロ秒単位の低遅延。高頻度な小パケット通信には最適。
デメリット: エラーフレームまで高速に転送し、トラブルシューティングを困難にする。

もし君がデータセンターの設計を任されたなら、まずは「ストア＆フォワード」で安定性を確保し、どうしても遅延がボトルネックになるアプリケーション（金融系やリアルタイム制御など）がある箇所だけ、カットスルーを検討する。この「慎重な適用」こそが、真のインフラアーキテクトの矜持だ。

ネットワークは生き物だ。パケットの流れる先を想像し、エラーカウンターという「鼓動」を読み解けるようになれば、君はもう一段階上のステージへ進めるはずだ。