Linux ネットワーク診断クイズ
最終更新日: 2026年9月14日
次の12問を使って、ローカルの HTTP、ソケット、ルーティング、MTU の演習を解釈してください。設問内の値は例示であり、測定結果を記録したものではありません。
選択問題
- シェルではリモート Docker コンテキストが選択されていますが、ルーティング用ヘルパーを実行したいと考えています。ヘルパーの仕様に合った準備はどれですか。
- A) ヘルパーは自動的に、選択中のリモートデーモンを使う。
- B)
/var/run/docker.sockにあるローカル Linux Engine に固定バージョンのイメージを準備し、サブネット重複の事前チェックに合格する。 - C) 特権コンテナを有効にして、ルーターのポートを公開する。
- D) サブネット範囲はランダムなので、複数のコピーを同時に起動する。
答えを表示
答え: B) /var/run/docker.sock にあるローカル Linux Engine に固定バージョンのイメージを準備し、サブネット重複の事前チェックに合格する
解説: このヘルパーはローカルの Unix ソケットを固定で使用し、リモートホスト／コンテキストを選択する環境変数は無視します。ドキュメント用の固定サブネットを使うため、複数の実行範囲を重ねてはいけません。イメージはあらかじめ存在している必要があります。専用ブリッジではマスカレードを無効にし、所有する3つのコンテナだけ IPv4 のデフォルトルートを失います。Docker は引き続きホストブリッジを作成し、ネットワークルールを管理します。
- GET
/lessonは本文b"hello\n"を返します。正しい Content-Length はどれですか。- A) 表示可能な文字だけを数えるため5
- B) 本文の改行はすべて CRLF である必要があるため7
- C) 5つの ASCII 文字と末尾の LF を合わせて6バイト
- D) レスポンスヘッダーと本文を合わせた長さ
答えを表示
答え: C) 5つの ASCII 文字と末尾の LF を合わせて6バイト
解説: 本文は16進数で 68 65 6c 6c 6f 0a です。HTTP/1.1 のヘッダー行で CRLF を使う規則によって、本文の LF が CRLF に変換されることはありません。Content-Length が数えるのは本文のバイト数であり、開始行、ヘッダー、区切りは含みません。echo ヘルパーも、--data-binary で渡されたバイト列をそのまま保持します。
curl --http1.1 -Iは/lessonからContent-Length: 6を受信しますが、本文を表示しません。何が起きていますか。- A) curl は HEAD を送信した。レスポンスに本文はなく、長さは対応する GET 表現のサイズを示す。
- B) curl は GET を送信し、受信した6バイトの本文を破棄した。
- C) サーバーはフレーミング規則に違反し、必須の6バイトを送信しなかった。
- D) HEAD では Content-Length を常に0にする必要がある。
答えを表示
答え: A) curl は HEAD を送信した。レスポンスに本文はなく、長さは対応する GET 表現のサイズを示す
解説:-I は HEAD を選択します。HEAD レスポンスには本文がありませんが、表現の長さを示すことが許されています。ヘッダーを通常の出力に含める -i とは異なります。HEAD のメタデータを本文のフレーミング情報として扱うと、持続接続上でクライアントが次のレスポンスを誤って読み取る可能性があります。
- HTTPS リクエストについて、curl のトレースに読み取り可能な HTTP ヘッダーが表示されました。何が証明されますか。
- A) ヘッダーがネットワーク上を暗号化されずに通過した。
- B) トレースの各行が TCP パケット1つに対応している。
- C) HTTP/2 と HTTP/3 は、ワイヤー上で HTTP/1.1 のテキスト行を使う。
- D) クライアントが処理する HTTP データを表示できた。これは受動的なパケットキャプチャではない。
答えを表示
答え: D) クライアントが処理する HTTP データを表示できた。これは受動的なパケットキャプチャではない
解説: curl のデバッグ出力はクライアント側で生成され、ネットワーク上では TLS によって保護されるデータが表示されることがあります。注釈はワイヤー上のエンコード形式やセグメント境界を表しません。HTTP/2 と HTTP/3 もバイナリフレーミングを使います。キャプチャで見える情報は、観測地点と利用できるセッションシークレットによって異なります。
ssの例示的なスナップショットでは、LISTEN のRecv-Q=3、Send-Q=128、ESTABLISHED のRecv-Q=6と表示されています。正しい解釈はどれですか。- A) リスナーが128バイトの送信バッファーにペイロードを3バイト保持している。
- B) リスナーに未完了の SYN が3つあり、確立済みソケットに接続が6つキューイングされている。
- C) リスナーには accept を待つ接続が3つあり、バックログの最大数は128。確立済みソケットには順序どおりの未読バイトが6つある。
- D) 3つの数字はすべて輻輳ウィンドウのサイズである。
答えを表示
答え: C) リスナーには accept を待つ接続が3つあり、バックログの最大数は128。確立済みソケットには順序どおりの未読バイトが6つある
解説: キュー列の単位はソケットの状態によって異なります。LISTEN の列は accept キューを示すもので、未完了の SYN キューではありません。ESTABLISHED の列はストリームのバイト数を示します。ソケットの Send-Q には、まだ確認応答されていないバイトも含まれます。テスト用ポートで絞り込み、クライアントとサーバーのエンドポイントを区別してください。
- 持続接続のクライアントは正常に動作しており、ストリームキューは多くの場合0ですが、
skmemには0以外のメモリ値が表示されます。何を結論付けるべきですか。- A) キューが空ならソケットメモリも0になるはずなので、接続が壊れている。
- B) メモリの計上や予算はストリームの占有量とは別であり、観測の間に小さなワークロードが処理されることがある。
- C) ストリームキューが0以外の値を保つまで、すべての TCP バッファー sysctl を増やす。
- D)
rbはピアに通知された受信ウィンドウの正確な値である。
答えを表示
答え: B) メモリの計上や予算はストリームの占有量とは別であり、観測の間に小さなワークロードが処理されることがある
解説: クライアントは次のリクエストを送る前に、6バイトのレスポンスをそれぞれ消費します。これは観測の演習であり、バッファーを意図的に飽和させるものではありません。skmem にはカーネルの計上値と予算が含まれますが、受信ウィンドウや輻輳ウィンドウは別の値です。読み取り専用のポリシー値や繰り返しの観測だけでは、汎用的なチューニング設定の根拠になりません。
- クライアントは
192.0.2.2/29であり、198.51.100.3へのルートはゲートウェイ192.0.2.3を使います。予想される ARP の結果はどれですか。- A)
192.0.2.3の MAC アドレスが得られる。クライアントには198.51.100.3の近隣エントリは必要ない。 - B) リモートサーバーの MAC アドレスが、クライアント側の左ネットワークに直接対応付けられる。
- C) ARP によって IP の宛先が
192.0.2.3に変わる。 - D) DNS が Ethernet の宛先を返すため、ARP は不要である。
- A)
答えを表示
答え: A) 192.0.2.3 の MAC アドレスが得られる。クライアントには 198.51.100.3 の近隣エントリは必要ない
解説: 近隣解決より前に、ルート検索によってオンリンクの次ホップが選択されます。Ethernet フレームの宛先はルーターの MAC アドレスですが、IP の宛先はサーバーのままです。右側のネットワークでは、ルーターが独自にルート検索と近隣解決を行います。サーバーにも明示的な戻りルートが必要です。
- TTL が1の ping は失敗して終了しましたが、ルーターのキャプチャには、そのプローブを引用する ICMP Type 11 Code 0 が含まれています。ラボではこれをどう解釈しますか。
- A) 宛先が HTTP リクエストを完了した。
- B) ルーターが TCP MSS の不一致を報告した。
- C) 後続のアプリケーションパケットもすべて、同じルーターで失敗する。
- D) 意図的に短く設定した TTL がルーターで期限切れになり、想定した診断応答が生成された。
答えを表示
答え: D) 意図的に短く設定した TTL がルーターで期限切れになり、想定した診断応答が生成された
解説: 送信された Echo Request と返された Time Exceeded は、異なるメッセージです。キャプチャされたエラーとプローブを照合すれば、想定したイベントが起きたと確認できます。タイムアウトだけでは確認できません。フィルタリング、応答のレート制限、戻り経路の損失でも応答しない場合があります。この確認では、ヘルパーが実際のルーターネットワーク名前空間のキャプチャを使います。
- ルーターの送信 MTU は1280です。IPv4 の DF ping で、一方はデータ長1372バイト、もう一方は1200バイトです。基本の IPv4 ヘッダーと ICMP ヘッダーを考慮すると、どの結果が予想されますか。
- A) MTU の対象となるのは ICMP データだけなので、どちらも収まる。
- B) IP 層では、最初のパケットが1372バイト、2つ目が1200バイトになる。
- C) 1400バイトの IP パケットでは Fragmentation Needed が発生し、1228バイトのパケットは収まる。
- D) 大きい方のプローブによって、TCP MSS が1200までネゴシエーションされる。
答えを表示
答え: C) 1400バイトの IP パケットでは Fragmentation Needed が発生し、1228バイトのパケットは収まる
解説: IPv4 ヘッダーの20バイトと ICMP ヘッダーの8バイトを加えます。DF によってルーターでのフラグメント化が防止されるため、最初のプローブは失敗し、ICMP Type 3 Code 4 が伴うはずです。小さいプローブは成功します。PMTU の通知がキャッシュされると、その後に大きすぎるパケットを送信した際、別のルーターキャプチャが発生せず、ローカルで失敗する場合があります。
- ループバック上の HTTP 接続で
ss -iを実行すると、MSS が1460を超えていると報告されます。妥当な結論はどれですか。
- A) ヘルパーが物理インターフェイスでジャンボ Ethernet フレームを有効にした。
- B) MSS 1460の計算は Ethernet MTU 1500 と基本的な IPv4／TCP ヘッダーを前提としている。ループバックでは条件が異なる。
- C) ICMP プローブのデータサイズが実際の TCP MSS である。
- D) キャプチャで1500を超える値があれば、物理ワイヤーの MTU 違反が証明される。
答えを表示
答え: B) MSS 1460の計算は Ethernet MTU 1500 と基本的な IPv4／TCP ヘッダーを前提としている。ループバックでは条件が異なる
解説: MSS が示すのは TCP データであり、ICMP データやフレーム全体のサイズではありません。インターフェイス MTU、オプション、経路上の動作も関係します。TSO／GSO／GRO によって、ホスト側での観測と物理リンク上のパケットが異なる場合もあります。ループバックの演習から、物理 Ethernet の MTU を判断することはできません。
- Docker DNS ではルーター名を正しく解決できますが、通常のクライアントからサーバーへの ping は失敗します。何を確認できていますか。
- A) 名前解決は動作している。ルート選択、転送、戻り経路は引き続き調べる必要がある。
- B) サーバーアプリケーションは正常である。
- C) 2つの専用ブリッジで、インターネット向けの NAT が動作している。
- D) ホストのループバック HTTP サーバーは、すべてのコンテナで
127.0.0.1経由で到達可能である。
答えを表示
答え: A) 名前解決は動作している。ルート選択、転送、戻り経路は引き続き調べる必要がある
解説: DNS と転送では別の仕組みを確認します。この環境は、マスカレードを無効にした専用ブリッジ間の明示的なルーティングを使い、インターネット NAT をベンチマークするものではありません。各ネットワーク名前空間には独自のループバックがあり、ホストのループバックサーバーはコンテナ内のサービスではありません。各名前解決が行われた名前空間で、観測結果を関連付けてください。
- ルーティング JSON に成功した観測結果が含まれますが、ステータスは failed か、クリーンアップが完了していません。どう対応するのが正しいですか。
- A) ルート検索が動作したため、実行全体を合格とする。
- B) イメージがローカルにキャッシュされていれば、クリーンアップは無視する。
- C) ホストを確実にクリーンな状態にするため、Docker の prune を広範囲に実行する。
- D) 実行結果は失敗のままとし、失敗した段階を調べ、必要なクリーンアップには作成した ID だけを指定する。
答えを表示
答え: D) 実行結果は失敗のままとし、失敗した段階を調べ、必要なクリーンアップには作成した ID だけを指定する
解説: 実行全体を合格とするには、正常に完了し、8つすべてのチェックが true であり、クリーンアップが報告されている必要があります。これには、3つのコンテナすべてで IPv4 のデフォルトルート一覧が空であることも含まれます。ヘルパーは無関係な名前付きリソースを削除せず、作成した ID を追跡します。突然終了すると、クリーンアップできない場合があります。根拠を保持し、後で実行する場合は新しい出力パスを使い、合格させるために共有ネットワーク制御を回避してはいけません。
診断ガイドに戻る · HTTP · TCP バッファー · ルーティングと ICMP · MTU と MSS