大手IT面接ネットワークプロトコル頻出15問：TCP/IP・HTTP・DNSを完全網羅

背景紹介

ネットワークプロトコルについては、正直なところ少し舐めていた。TCPの3ウェイハンドシェイクと4ウェイ切断を暗記すればいいと思っていたが、面接官から「なぜ3回で2回ではないのか」「TIME_WAITが多すぎる場合どうするか」と聞かれて唖然とした。その後、ネットワークプロトコルの高頻出題をすべて整理し、実はパターンが固定されていることを発見した。重要なのは各プロトコル設計の「なぜ」を理解することで、暗記することではない。この15問は私の面接経験で最も頻繁に遭遇したものを共有する。

一、TCP（5問）

1. 3ウェイハンドシェイクと4ウェイ切断の過程？

出題ポイント：TCP接続管理

3ウェイハンドシェイク：クライアントがSYNを送信→サーバーがSYN+ACKで応答→クライアントがACKを送信。なぜ3回か？3回のハンドシェイクで双方が相手の送信・受信能力が正常であることを確認できる。2回ではサーバーの送信能力とクライアントの受信能力を確認できない。4ウェイ切断：能動側がFINを送信→受動側がACKで応答→受動側がFINを送信→能動側がACKで応答。なぜ4回か？TCPは全二重であり、受動側はFIN受信後も送信すべきデータが残っている可能性があるため、ACKとFINを別々に送信する。面接官が最も掘り下げるのはこれらの「なぜ」である。

2. TCP輻輳制御メカニズム？

出題ポイント：フロー調整アルゴリズム

4つの段階：スロースタート（cwndが1から指数関数的に増加）、輻輳回避（cwndが線形増加）、高速再送（3つの重複ACKを受信したらタイムアウトを待たずに即座に再送）、高速リカバリ（cwndを1にするのではなく半減）。重要概念：スロースタート閾値ssthresh、cwndがssthreshを超えると輻輳回避段階に入る。追問：BBRアルゴリズムを知っているか？BBRは帯域幅とRTTに基づく輻輳制御で、従来のパケットロスベースのアルゴリズムと異なり、高速長距離ネットワークでより良い性能を発揮する。

3. TCPフロー制御メカニズム？

出題ポイント：受信側レート制御

フロー制御はスライディングウィンドウで実現され、受信側はACKでウィンドウサイズrwndを送信側に通知し、あとどれだけデータを受信できるかを伝える。ゼロウィンドウ問題：受信側のウィンドウが0の場合、送信側は送信を停止するが、持続タイマーを起動して定期的にゼロウィンドウプローブパケットを送信し、デッドロックを防止する。スリーウィンドウ症候群：受信側のバッファがほぼ満杯の時、毎回わずかな空間しか解放せず、送信側も毎回少量のデータしか送信せず、効率が極めて低い。解決策：Nagleアルゴリズム（送信側は十分なデータを蓄積してから送信）とClarkソリューション（受信側はバッファに十分な空間ができるまで通知しない）。

4. TIME_WAIT状態とは？なぜ必要？多すぎる場合は？

出題ポイント：接続終了の詳細

TIME_WAITは能動的切断側が最後のACKを送信した後に进入する状態で、2MSL（Maximum Segment Lifetime）持続する。存在理由：第一に、最後のACKが受動側に到達することを保証（紛失した場合、受動側はFINを再送し、能動側はACKを再送可能）；第二に、今回の接続のすべてのパケットがネットワーク上から消滅することを保証し、新接続への影響を回避。TIME_WAITが多すぎる場合の解決策：tcp_tw_reuseを有効化（TIME_WAIT接続を新しいTCP接続に再利用可能）；tcp_max_tw_bucketsを調整；ショートコネクションの代わりにロングコネクションを使用。注意：tcp_tw_recycleはNAT環境で問題があり、使用は推奨されない。

5. TCPパケット接着問題？

出題ポイント：アプリケーション層プロトコル設計

厳密に言えば、TCPに「パケット接着」問題は存在しない。TCPはバイトストリーム指向のプロトコルであり、メッセージ境界の概念がないからだ。いわゆるパケット接着はアプリケーション層の問題——送信側が連続して送信したデータを受信側が一度に読み出す。解決策：メッセージ固定長（各メッセージは固定長で、不足分はパディング）；特殊デリミタの使用（HTTPの\r\n\r\nなど）；メッセージヘッダに長さフィールドを含める（最も一般的、TLVフォーマットなど）。追問：UDPにパケット接着問題はあるか？ない。UDPはメッセージ指向で、各UDPパケットに明確な境界がある。

二、HTTP（5問）

6. HTTP/1.1、HTTP/2、HTTP/3の違い？

出題ポイント：HTTPプロトコルの進化

HTTP/1.1：持続的接続（Keep-Alive）、パイプライン化（ただしヘッドオブラインブロッキングあり）、Hostヘッダによるバーチャルホスト対応。HTTP/2：バイナリフレーミング、多重化（1接続で複数リクエストを並列、HTTP層のヘッドオブラインブロッキングを解決）、ヘッダ圧縮（HPACK）、サーバープッシュ。HTTP/3：QUIC（UDP）ベースでTCPを代替、TCP層のヘッドオブラインブロッキングを解決；0-RTT接続確立；接続マイグレーション（4タプルではなくConnection IDベース）。追問：HTTP/2にヘッドオブラインブロッキングはまだあるか？HTTP層にはないが、TCP層にはある——1つのTCPパケットがロスするとすべてのストリームがブロックされる。

7. HTTPSの原理？

出題ポイント：安全通信メカニズム

HTTPS = HTTP + TLS。TLSハンドシェイク：クライアントがClient Hello（対応TLSバージョンと暗号スイート）を送信→サーバーがServer Hello + 証明書で応答→クライアントが証明書を検証（CA署名チェーン）→クライアントがプリマスターシークレットを生成し、サーバーの公開鍵で暗号化して送信→双方がプリマスターシークレットからセッションキーを生成→以降の通信は対称暗号を使用。追問：なぜ非対称暗号だけを使わないのか？非対称暗号は性能が悪いため、鍵交換にのみ使用し、データ伝送には対称暗号を使用する。TLS 1.3はハンドシェイクを簡略化し、1-RTTさらには0-RTTをサポート。

8. よくあるHTTPステータスコード？

出題ポイント：プロトコルセマンティクスの理解

200成功；301恒久リダイレクト（ブラウザがキャッシュ）；302一時リダイレクト；304未変更（キャッシュヒット）；400リクエスト構文エラー；401未認証；403アクセス禁止；404未検出；500サーバー内部エラー；502ゲートウェイエラー；503サービス利用不可；504ゲートウェイタイムアウト。よく聞かれる：301と302の違い？301は恒久リダイレクトで、検索エンジンはインデックスを更新；302は一時リダイレクトで、検索エンジンは元のURLを保持。また：502と504の違い？502は上流サービスが無効なレスポンスを返した、504は上流サービスがタイムアウトでレスポンスなし。

9. HTTPキャッシュ戦略？

出題ポイント：キャッシュメカニズム設計

強キャッシュ：Expires（HTTP/1.0、絶対時間）とCache-Control（HTTP/1.1、max-age相対時間）、ヒットすればサーバーにリクエストしない。交渉キャッシュ：Last-Modified/If-Modified-Since（変更時間ベース）とETag/If-None-Match（コンテンツハッシュベース）、ヒットすれば304を返す。優先度：Cache-Control > Expires > ETag > Last-Modified。追問：ETagとLast-Modifiedの選び方？ETagの方が正確（ファイル内容が変わっていないのに変更時間が変わっても誤判定しない）が、ETag計算にはパフォーマンスオーバーヘッドがある。一般的に静的リソースは強キャッシュ+ファイル名ハッシュ、HTMLは交渉キャッシュを使用。

10. CookieとSessionの違い？

出題ポイント：セッション管理メカニズム

Cookieはクライアントに保存、Sessionはサーバーに保存。SessionはCookie内のSessionIDで関連付け（URLリライトも可能）。Cookieにはサイズ制限（4KB）、Sessionは理論上無制限だがサーバーメモリを消費。セキュリティ：Cookieはクライアント側で改ざん・窃取される可能性、Sessionはより安全だが分散シナリオでの共有問題を考慮する必要がある（通常RedisでSession保存）。Token方式（JWT）も選択肢：ステートレス、分散に適しているが、能動的な無効化ができない。追問：CookieのSameSite属性？Strict（サードパーティCookieを完全にブロック）、Lax（ターゲットサイトへのナビゲーション時に送信）、None（許可するがSecureが必要）。

三、DNS（2問）

11. DNS解決過程？

出題ポイント：ドメイン名解決メカニズム

ブラウザキャッシュ→OSキャッシュ→ローカルDNSサーバー→ルートネームサーバー→トップレベルドメインサーバー→権威ネームサーバー。具体的な流れ：ローカルDNSがまずキャッシュを確認し、なければルートネームサーバーに問い合わせ、ルートは対応するトップレベルドメインサーバーのアドレスを返す；ローカルDNSがトップレベルドメインサーバーに問い合わせ、権威ネームサーバーのアドレスを取得；最後に権威ネームサーバーに問い合わせてIPを取得。この過程は再帰+反復の組み合わせ：クライアントからローカルDNSは再帰、ローカルDNSから各レベルのネームサーバーは反復。追問：DNSはTCPとUDPどちらを使うか？デフォルトはUDP、ただしゾーン転送（マスタスレーブ同期）はTCP。

12. DNSハイジャックとは？防ぐには？

出題ポイント：セキュリティ意識

DNSハイジャックは攻撃者がDNSレスポンスを改ざんし、ドメイン名を悪意のあるIPに解決させること。よくあるシナリオ：ISPハイジャック（広告挿入）、中間者攻撃、DNSサーバー侵害。防止策：HTTPDNSを使用（従来のDNSをバイパスし、HTTPインターフェースに直接IPをリクエスト）；DNS over HTTPS（DoH）またはDNS over TLS（DoT）でDNSクエリを暗号化；DNSSECでレスポンスの真正性を検証；信頼できるDNSサーバーを使用（8.8.8.8、1.1.1.1など）。プロジェクトでHTTPDNSを使用したことがあり、モバイルでは特に効果的で、ISPハイジャックの問題を回避できた。

四、その他（3問）

13. CDNの原理？

出題ポイント：コンテンツデリバリーネットワーク

CDNは世界中にエッジノードを展開し、オリジンコンテンツをユーザーに最も近いノードにキャッシュする。ユーザーリクエスト時、DNSはドメイン名を最も近いCDNノードに解決（AnycastまたはDNSスマート解決に基づく）；CDNノードにキャッシュがあれば直接返却、なければオリジンから取得してキャッシュ。重要概念：オリジン取得率（CDNキャッシュヒット率が低いほどオリジン取得が増加）、キャッシュ戦略（リソースごとに異なるTTLを設定）、プリヒート（コンテンツをCDNノードに能動的にプッシュ）。追問：CDNとリバースプロキシの違い？CDNは世界各地に分散展開されたキャッシュネットワーク、リバースプロキシは通常一箇所に集中展開。CDNは「最寄りアクセス」をより重視。

14. WebSocketの原理？

出題ポイント：全二重通信

WebSocketはHTTPアップグレードハンドシェイクで接続を確立：クライアントがUpgrade: websocketリクエストを送信、サーバーが101 Switching Protocolsで応答、その後WebSocketプロトコルに切り替えて全二重通信を行う。HTTPポーリングと比較して、WebSocketは1回のハンドシェイクのみで、以降の通信オーバーヘッドは極めて小さい（フレームヘッダ2-10バイト）。適用シナリオ：インスタントメッセージング、リアルタイムデータプッシュ、オンラインコラボレーション。追問：WebSocketとSSEの違い？SSEはサーバーからクライアントへの一方向プッシュでHTTPベース、よりシンプル；WebSocketは双方向通信で機能は強力だが実装はより複雑。

15. クロスオリジンソリューション？

出題ポイント：ブラウザセキュリティポリシー

同一オリジンポリシー：プロトコル+ドメイン+ポートが同じ場合のみ同一オリジンとみなす。クロスオリジンソリューション：CORS（最も標準的、サーバーがAccess-Control-Allow-Origin等のレスポンスヘッダを設定）；JSONP（GETのみサポート、scriptタグが同一オリジン制限を受けないことを利用）；プロキシサーバー（開発環境でwebpack-dev-serverやnginxプロキシを使用）；postMessage（クロスウィンドウ通信）。CORSはシンプルリクエストと非シンプルリクエストに分かれ、非シンプルリクエストは先にOPTIONSプリフライトリクエストを送信する。追問：Cookieのクロスオリジン処理は？withCredentialsを設定 + サーバー側Access-Control-Allow-Credentials + Allow-Originを*にできない。

心得とアドバイス

ネットワークプロトコル面接の核心は「なぜこのように設計されているか」を理解することであり、プロセスを暗記することではない。3ウェイハンドシェイクがなぜ3回なのか、TIME_WAITがなぜ存在するのか、HTTP/2がなぜ多重化が必要なのか——これらの設計の背後には明確な問題駆動がある。パケットキャプチャツール（Wireshark）で実際にTCPハンドシェイク/切断やHTTPリクエスト/レスポンスを観察することをお勧めする。直感的な理解があれば、理論もずっと理解しやすくなる。また、ネットワークプロトコルは実際のシナリオと組み合わせてよく出題される。例えば「ショートコネクションでTIME_WAITが多すぎる場合の対処」「プッシュシステムの設計方法」など、こうした問題は複数の知識点を繋ぎ合わせる必要がある。

FAQ

Q：ネットワークプロトコル面接にRFCの読解は必要？
RFCを通読する必要はないが、主要なRFCの要点（RFC 2616/7540/9000など）を理解していると大きくプラスになる。

Q：TCPとUDPの選び方は？
信頼性の高い伝送が必要な場合はTCP、低遅延やブロードキャストが必要な場合はUDP。現代的なソリューションとしてはQUIC（UDP上の信頼性伝送）も使用可能。

Q：HTTPS面接の重点は？
TLSハンドシェイク過程、証明書検証チェーン、対称/非対称暗号の連携使用、TLS 1.3の改善点。