3.3HTTP・Web・メールプロトコル

Webとメールは企業ネットワークで最も利用頻度の高いアプリケーション層サービスです。ネットワークスペシャリストには、単にプロトコルの仕様を知るだけでなく、「ページの表示が遅い」「なりすましメールが届く」といった課題に対して、HTTPバージョンの選択や送信ドメイン認証の導入といった具体的な設計・対策で応える力が求められます。この節ではその両輪を扱います。

3.3.1HTTP/HTTPSとHTTP/2・HTTP/3（QUIC）

• HTTPはテキストベースのリクエスト/レスポンス型プロトコル。HTTPSはHTTPをTLSで暗号化した通信で、盗聴・改ざん・なりすましへの耐性を確保する。HTTP/1.1は1本のTCPコネクションでリクエストが直列化しやすく（HOLブロッキング、Head-of-Line blocking）、多数の小さなリソース取得で性能劣化しやすい。
• HTTP/2＝1本のTCPコネクション上で複数のストリームを多重化（多重化）し、リクエスト/レスポンスの並行処理でHOLブロッキングを緩和。ヘッダ圧縮（HPACK）も性能向上に寄与するが、TCP自体のパケットロス時にはコネクション全体が待たされる（トランスポート層でのHOLブロッキングは残る）。
• HTTP/3＝トランスポート層にQUIC（UDPベース）を使うことでHTTP/2に残るTCP層のHOLブロッキングを解消。QUICはストリームごとに独立した再送制御を行うため、1つのストリームでパケットロスが起きても他のストリームは影響を受けない。またTLSをQUICに統合しているため、コネクション確立と暗号化ハンドシェイクを同時に行い接続開始を高速化する。

3.3.2cookieとセッション管理

• HTTPは本来ステートレス（状態を保持しない）だが、ログイン状態などを維持するためにcookie（サーバがレスポンスヘッダで発行し、以後のリクエストにクライアントが自動添付する小さなデータ）でセッションIDを保持する。
• cookieにはSecure（HTTPS接続でのみ送信）・HttpOnly（JavaScriptからアクセス不可、XSS対策）・SameSite（クロスサイトでの送信制御、CSRF対策）等の属性があり、セキュリティ強化に用いられる。

3.3.3メールプロトコルと送信ドメイン認証

• SMTP＝メールの送信・中継を担うプロトコル（クライアント→送信サーバ、サーバ間中継の両方）。POP3＝メールをサーバから端末へダウンロードして削除する方式（1台の端末での利用が前提）。IMAP＝メールをサーバ上に保持したまま複数端末で同期的に閲覧・管理する方式。
• MIME（Multipurpose Internet Mail Extensions）＝本来テキストのみのSMTPで、画像・添付ファイルや日本語等の非ASCII文字を扱えるようにする拡張規格。Content-Typeでデータ種別を、Content-Transfer-Encodingで符号化方式（Base64等）を指定する。
• SPF（Sender Policy Framework）＝送信元ドメインのDNS TXTレコードに「正規の送信元IPアドレス一覧」を公開し、受信側がそれと照合してなりすましを検知する仕組み。DKIM（DomainKeys Identified Mail）＝メールに電子署名を付与し、公開鍵（DNSで公開）で検証することで改ざん検知と送信元認証を行う。
• DMARC（Domain-based Message Authentication, Reporting & Conformance）＝SPFとDKIMの検証結果を踏まえ、失敗したメールを「何もしない／隔離／拒否」のどのポリシーで扱うかをドメイン所有者がDNSで宣言する仕組み。検証結果のレポートを受け取れる点も特長。

ある企業のWeb担当者が「モバイル回線でパケットロスが多いユーザーからページ表示が遅いという苦情が増えている」という相談を受けたとします。現行はHTTP/2で配信しており、1本のTCPコネクション上で多重化はできているものの、パケットロスが発生するとTCPの再送待ちでコネクション全体が停止する（トランスポート層のHOLブロッキング）ことが原因と推測されます。この場合、HTTP/3（QUIC）への移行が有効な対策です。QUICはストリームごとに独立した再送制御を行うため、1つの画像リクエストでパケットロスが起きても他のテキストやスクリプトの読み込みは止まりません。加えてQUICはTLSハンドシェイクを統合しているため接続確立も高速化され、モバイル回線のような不安定な環境でより体感速度が改善します。一方、同じ会社のメール担当者からは「取引先を装った偽メールで請求書の振込先変更を指示する詐欺（ビジネスメール詐欺）が増えている」という相談も受けています。この対策として、まず自社ドメインのSPFレコードを整備して正規の送信元IPを宣言し、DKIMで全送信メールに署名を付与し、最後にDMARCポリシーをnone（監視のみ）から段階的にquarantine（隔離）・reject（拒否）へ強化していく、という順序が実務では推奨されます。いきなりrejectにすると正規メールの誤検知で業務メールが届かなくなるリスクがあるため、監視期間を設けて段階的に強化するのが適切な設計判断です。

3.3.4この節のまとめ

• HTTP/2はTCP上での多重化、HTTP/3はQUIC（UDP）でトランスポート層のHOLブロッキングも解消
• SPF=送信元IP検証、DKIM=署名による改ざん検知、DMARC=両者の失敗時ポリシーとレポート
• DMARCポリシーはnone→quarantine→rejectと段階的に強化するのが実務上の適切な設計