【実務・中級編】 IPヘッダーのチェックサム計算アルゴリズム – ネットワーク基礎とWebセキュリティ実践ガイド

IPヘッダーの「チェックサム」をナメてはいけない――ルーターがパケットを捨てる瞬間の舞台裏

現場で「通信が断続的に途切れる」「特定のパケットだけがルーターを通過しない」というトラブルに直面したとき、多くのエンジニアはまずファイアウォールやルーティングテーブルを疑います。しかし、ネットワークの深淵を覗き込むと、そこにはOSI参照モデルの第3層（ネットワーク層）で繰り広げられる、極めて地味だが極めて重要な「1の補数和」という計算の世界が広がっています。

今回は、ネットワークの守護神である「IPヘッダーのチェックサム」に焦点を当てます。なぜルーターは律儀に計算し、なぜ計算が合わなければパケットを即座に破棄するのか。その裏側に迫りましょう。

1. なぜ「1の補数和」なのか？

IPヘッダーのチェックサム（Checksumフィールド）は、ヘッダーに誤りがないかを検証するための仕組みです。計算アルゴリズムは、RFC 791で定義された以下の手順に従います。

1. Checksumフィールドを一旦「0」にする。
2. ヘッダー全体を16ビット単位の数値として扱う。
3. 全てを足し合わせ、オーバーフローしたビットを下の桁に加算する。
4. 得られた合計値を「1の補数（ビット反転）」にする。

なぜ単純な加算やCRC（巡回冗長検査）ではなく、1の補数和なのか。これは、「計算負荷の低さ」と「実装の容易さ」が優先された結果です。かつての非力なルーターのCPUにとって、複雑な多項式除算を行うことは、パケットの転送遅延に直結する死活問題でした。1の補数和であれば、CPUのレジスタ操作だけで完結するからです。

2. ルーターの負荷と「パケット破棄」の現場

皆さんが書いたWeb APIが意図せず 408 Request Timeout や 504 Gateway Timeout になる際、実はネットワーク機器のCPUが悲鳴を上げている可能性があります。

ルーターはパケットを受信するたびに、以下の処理を強制されます。

TTL（Time To Live）のデクリメント（値を1減らす）。
チェックサムの再計算。

もし、どこかの装置がTTLを書き換えるたびに、チェックサムを再計算せず、あるいは計算ミスをして転送したらどうなるか？次のルーターは即座に「このパケットは破損している」と判断し、無慈悲にパケットを捨てます。現代のルーターは高速なASIC（専用チップ）で処理していますが、それでも不整合なパケットはトラフィックのボトルネックとなります。

3. 実践：Pythonでチェックサム計算をシミュレートする

理論だけではつまらないので、IPヘッダーのチェックサムを計算するロジックをPythonで書いてみました。実務でパケットキャプチャを解析する際、この仕組みを知っていると「なぜこのパケットが再送されているのか」という勘が鋭くなります。

def calculate_checksum(header_bytes):
    """
    IPヘッダーのチェックサム計算（簡易版）
    """
    # 2バイトずつ加算していく
    if len(header_bytes) % 2 == 1:
        header_bytes += b'\x00'
    
    total = 0
    for i in range(0, len(header_bytes), 2):
        # 16ビット単位で取得
        word = (header_bytes[i] << 8) + header_bytes[i + 1]
        total += word
    
    # オーバーフロー分を足し込む
    while (total >> 16):
        total = (total & 0xFFFF) + (total >> 16)
    
    # 1の補数をとる（ビット反転）
    return ~total & 0xFFFF

# 使用例：ダミーのIPヘッダーデータを想定
# 実際にはここに送信元IP、宛先IPなどのデータが入る
sample_header = b'\x45\x00\x00\x3c\x1c\x46\x40\x00\x40\x06\x00\x00\xac\x10\x0a\x63\xac\x10\x0a\x0c'
checksum = calculate_checksum(sample_header)
print(f"計算されたチェックサム: {hex(checksum)}")

4. 運用エンジニアが知るべき「デバッグTips」

もし皆さんがネットワークのトラブルシューティングを行っているなら、tcpdumpやWiresharkでパケットを確認する際、Checksumフィールドの警告に注目してください。

Checksum Errors: もし多くのパケットで「Checksum incorrect」と出る場合、NICのオフロード機能（Checksum Offload）が疑わしいです。OSが計算をサボり、NICに計算を任せている場合、Wiresharkがそれを読み取れず誤判定することがあります。
MTU不整合: パケットが断片化（フラグメンテーション）されている場合、チェックサムの計算が複雑になります。MTUを適切に設定し、フラグメントを発生させない設計（MSSの最適化）こそが、インフラの安定化への近道です。

まとめ：ネットワークの「誠実さ」を信じすぎない

Web APIの世界では JSON のパースや HTTP ヘッダーのバリデーションに注力しがちですが、その土台にあるIP層は、今この瞬間も絶え間なく「1の補数和」という原始的な計算を繰り返しています。

「なぜかたまに通信が失敗する」という怪奇現象の多くは、こうした下層の泥臭い処理での不整合に起因しています。教科書的な知識を現場のパケット解析に落とし込めたとき、皆さんは真のネットワークエンジニアとして、どんなトラブルも解決できるはずです。

次回の運用時には、ぜひ tcpdump -v を叩いて、流れるパケットの chksum フィールドに思いを馳せてみてください。そこには、インターネットが崩壊しないための、古くから変わらぬ誠実な計算が存在しています。