【入門編】 TCPチェックサムの計算アルゴリズムと擬似ヘッダー(Pseudo Header)の役割 – ネットワーク基礎とWebセキュリティ実践ガイド

なぜTCPは「宛先IP」まで気にするのか？擬似ヘッダーの秘密を解き明かす

こんにちは！ネットワークの深淵を覗き込み、日夜パケットたちと対話しているセキュリティスペシャリストです。

さて、皆さんはOSI参照モデルを学んだとき、こんな疑問を抱いたことはありませんか？
「TCPはトランスポート層（第4層）なのに、なぜわざわざ下の階層であるIP（第3層）の情報をチェックサムに混ぜるのか？」

教科書には「擬似ヘッダー（Pseudo Header）を使用して整合性を検証する」とサラッと書かれていますが、これ、実はネットワークの生存戦略において極めて重要な「泥臭い防衛術」なんです。今回は、この少し不思議な仕組みを、郵便配達に例えて紐解いていきましょう。

郵便配達で例える「チェックサム」の役割

まず、TCPチェックサムを「手紙の検印」だと考えてください。手紙（データ）が届いたとき、それが途中で破られたり、内容が書き換えられていないかを確認するためのスタンプです。

普通、手紙の検印は「手紙の中身」だけで計算すれば良さそうですよね？でも、TCPはそれだけじゃ納得しません。「どこの住所から届いたか（送信元IP）」と「どこへ届くはずだったか（宛先IP）」も一緒に計算式に混ぜるのです。

これが「擬似ヘッダー」の正体です。なぜそんな面倒なことをするのでしょうか？

理由：配送ミスを絶対に許さないため

もし、ルーターが設定ミスやバグで、あろうことか「Aさん宛の荷物」を「Bさんの家のポスト」に入れてしまったらどうなるでしょう？

もしTCPが「手紙の中身」だけをチェックしていたら、Bさんは「お、正しいスタンプが押されているな」と勘違いして、本来自分宛ではない情報を受け取ってしまいます。これはセキュリティ的に致命的です。

そこでTCPは、「この宛先（IPアドレス）に向けて出した手紙である」という証明を計算に含めることで、万が一IP層で配送ミスが起きても、「あれ？宛先のIPアドレスが計算結果と合わないぞ？このパケットは偽物だ！」と即座に検知できるようにしているのです。

擬似ヘッダーが計算される仕組み

擬似ヘッダーは、実体としてネットワークを流れるわけではありません。計算のためだけに、IPヘッダーから以下の情報を「拝借」してきて、TCPヘッダーの先頭にくっつけて計算します。

送信元IPアドレス
宛先IPアドレス
ゼロパディング（0埋め）
プロトコル番号（TCPなら6）
TCPセグメント長

これらを合計してから、TCPヘッダーとデータ部分を足し合わせ、計算を行います。まさに「自分を送り出した親（IP層）の素性もろとも検査する」という、非常に慎重な仕組みですね。

実践：Pythonで擬似ヘッダーのイメージを掴む

実際にどう計算されるのか、Pythonで非常に単純化したイメージを見てみましょう。チェックサムは実際には「1の補数和」という少し特殊な計算をしますが、ここでは概念として「情報を混ぜる」ことに注目します。

import struct

def calculate_pseudo_header_sum(src_ip, dst_ip, tcp_length):
    # IPアドレスを4バイトの数値に変換
    src_addr = sum(int(x) for x in src_ip.split('.'))
    dst_addr = sum(int(x) for x in dst_ip.split('.'))
    
    # プロトコル番号(TCP=6)と長さを加える
    protocol = 6
    
    # これが擬似ヘッダーの要素（概念的な合計）
    pseudo_sum = src_addr + dst_addr + protocol + tcp_length
    
    print(f"擬似ヘッダーによる検証値: {pseudo_sum}")
    return pseudo_sum

# サンプル実行
# 送信元: 192.168.1.1, 宛先: 192.168.1.100, TCPの長さ: 20バイト
calculate_pseudo_header_sum("192.168.1.1", "192.168.1.100", 20)

このコードのように、IPアドレスが変われば計算結果（チェックサム）はガラリと変わります。もしパケットのIPアドレスが途中で書き換えられたら、受信側の計算結果は一致せず、パケットは即座に破棄されるというわけです。

エンジニアとして知っておくべきこと

現場でトラブルシューティングをしていると、「なぜか特定の通信だけがパケットロスする」という現象に出くわすことがあります。

もし、ロードバランサーやNAT機器がIPヘッダーを書き換えているのに、TCPのチェックサムを正しく再計算（Recalculate）していない場合、受信側のサーバーは「あ、これチェックサム壊れてるから捨てちゃえ！」と判断してしまいます。

チェックサムエラーが出ている場合: 単なる回線品質の問題だけでなく、途中のNW機器がパケットを加工した際の「再計算漏れ」を疑う必要があります。
Wiresharkで見るとき: [Checksum: 0xXXXX [incorrect]] と出ていたら、それは機器がパケットを横取りして計算をサボっている証拠かもしれません（※最近のNICはハードウェアオフロードで計算するため、キャプチャ時点では誤検知されることもあります）。

まとめ：ネットワークは「疑うこと」から始まる

TCPのチェックサムに擬似ヘッダーが含まれているのは、「下の階層（IP）を信用しすぎない」というゼロトラストの精神に近いものがあります。「IPヘッダーが正しいと言っているからといって、鵜呑みにしてはいけない。自分でも確認しなければ」というTCPの慎重さが、現代の安定したインターネット通信を支えています。

難しい専門用語の裏側には、常に「いかに通信を正しく届けるか」という設計者の情熱が隠れています。皆さんもパケットを見るときは、ぜひ「このパケットは、自分の宛先を正しく証明できているかな？」と想像してみてくださいね。

それでは、また次回の深掘りでお会いしましょう！