ネットワークスペシャリスト 2010年 午後1 問01

解答の論理構成

1. 問題文の該当箇所を確認
   【問題文引用】
   「HTTP クライアントと HTTP サーバ間の通信では、大量のデータを一方向に転送するバルクデータ転送と、比較的少量のデータを交互に転送する対話型データ転送とが混在している。このうち、ア の応答性能は、ラウンドトリップ時間の影響を受ける。」
   ─ 少量データを“交互”にやり取りする場合、往復遅延が直接効くため ア＝「対話型データ転送」 が妥当です。
2. バルク転送側の説明を確認
   【問題文引用】
   「一方、イ の応答性能は、ラウンドトリップ時間のほかに、ボトルネックとなる中継路の帯域幅と、確認応答を待たずに送信できるデータ量である ウ によっても変化する。」
   ─ 「大量のデータを一方向に転送する」特徴と帯域幅・ウインドウサイズが効く特性は バルクデータ転送 なので イ＝「バルクデータ転送」 となります。
3. ウインドウサイズの位置づけ
   【問題文引用】
   「確認応答を待たずに送信できるデータ量である ウ によっても変化する。」
   ─ TCP で “ACK を待たずに送れる量” は ウィンドウサイズ（Window Size） そのものです。したがって ウ＝「ウィンドウサイズ（Window Size）」 です。
4. まとめ
   • ア：対話型データ転送
   • イ：バルクデータ転送
   • ウ：ウィンドウサイズ（Window Size）

誤りやすいポイント

• 「ラウンドトリップ時間＝RTT」だけで決まるのはどちらか
  ⇒ 大量転送と勘違いしがちですが、少量を行き来させる対話型が RTT の影響をもろに受けます。
• ウインドウサイズを“パケットサイズ”や“MTU”と混同
  ⇒ MTU は 1 パケットの最大長、Window Size は未確認データ全体の上限です。
• バルク転送＝ダウンロードの実効速度は帯域幅だけと考える
  ⇒ RTT と Window Size の比 $\text{Window Size}÷\text{RTT}$ が理論上限である点を見落としやすいです。

FAQ

解答の論理構成

1. 問題文は「GET リクエストを図3中の①〜⑦の中から選べ」と指示しています。
2. 図3の説明に「t4 付近　クライアント→サーバ　（ラベル無し：HTTPリクエスト）」とあります。ここが GET リクエストそのものです。
3. 同じく図3には「丸数字（HTTPクライアントの送信データを示す）」と記載され、t4 の位置に対応する丸数字が「③」です。
4. したがって、GET リクエストは「③」と結論できます。

誤りやすいポイント

• ①や②を選んでしまう
  「SYN」や「ACK」は TCP 三者ハンドシェイクの制御パケットであって HTTP レベルの GET ではありません。
• ⑤を選んでしまう
  ⑤はサーバからクライアントへ返るレスポンスデータ側であり、方向が逆です。
• 「HTTP/1.1 の永続的接続」を思い出し、複数リクエストと混同する
  永続的接続でも最初の GET は必須ですが、本設問は単一通信例なのでシンプルに判定できます。

FAQ

解答の論理構成

• まず本文は「図3 において、利用者から見た HTTP サーバの応答時間（以下、TAT という）は、t1～t9 の総和となる」と定義しています。
• 次に TAT を 3 区間に分割し、それぞれの区間を “t＊” で表すよう空欄を設けています。

• 3ウェイハンドシェイク完了までの時間として「TCP コネクションの確立完了までの時間：t1 + エ」と記載。
• 図3では SYN 送信が t1、SYN, ACK 受信が t2、ACK 送信が t3 です。
• 確立完了はクライアントが ACK を送り終えた時点なので、t1 と t2 が経過すれば完了します。
  ⇒ [エ] = t2

• 「TCP コネクションの確立完了から、ダウンロードの完了までの時間：オ」と記載。
• 確立完了は t3 終了直後、ダウンロード完了はレスポンス受信終了 t5 です。間にある処理は t3（ACK 送信）、t4（HTTP リクエスト送信）、t5（HTTP レスポンス受信）。
  ⇒ [オ] = t3 + t4 + t5

• 「ダウンロードの完了から、TCP コネクションの切断と情報の表示がともに完了するまでの時間：カ + t9」。
• ダウンロード完了後に行われるクライアントからの FIN 送信が t6、サーバからの ACK が t7、サーバからの FIN が t8。
  ⇒ [カ] = t6 + t7 + t8

• キャッシュが最新で “304 Not Modified” が返るケースで「図3で示されているTATと比べて、キだけ短縮される」と記載。
• この場合、本文は「“304 Not Modified” のレスポンスだけを返す」と説明しており、実データ転送に相当する t4（大きなリクエストボディ送信）と t5（Web ページ全体のレスポンス受信）が不要になります。
  ⇒ [キ] = t4 + t5

誤りやすいポイント

• t3 をハンドシェイク時間に含めるか否かで迷いがちな受験者が多いですが、問題文は「確立完了まで：t1 + [エ]」と示しており、すでに t1 を含めているため残るのは t2 のみです。
• 「304 Not Modified」の短縮量を t5 だけと誤解しがちですが、リクエスト送信に伴う大容量ボディ（t4）が無くなる点も見落とさないようにしましょう。
• 切断処理では t9 が別に加算されるため、[カ] の式に t9 を含めてはいけません。

FAQ

解答の論理構成

1. 課題の背景
   • 既存構成は【問題文】の「図2」で示されるとおり「PC（ブラウザ） → プロキシ1 → プロキシ2 → Webサイト」で、PC 側は「proxy.pac はプロキシ1に格納」され、さらに「プロキシ1には、アクセスするプロキシ2 の IP アドレスが登録」されています。
   • アクセス順序を逆転させるには、プロキシ2を最上流に、プロキシ1を下流に置き換える必要があります。
2. IP アドレス入れ替え後に残る三つの設定課題
   • 【問題文】には「プロキシサーバのIPアドレスを入れ替え、PC側の設定を変えない場合、プロキシサーバのIPアドレスを入れ替える作業のほかに、（I）三つの変更作業が必要」とあります。
   • PC から見た “proxy1 のIPアドレス” は変わらないため、プロキシ2（ウイルスチェック用）がその IP になる ⇒ プロキシ2 に下流サーバ（旧プロキシ1）を設定する必要が生じます。
   • 旧プロキシ1（キャッシュ／URL フィルタリング用）は上流サーバ設定を保持しているとループを生むため、削除が必要です。
   • 「proxy.pac はプロキシ1に格納」とあるため、IP 入れ替え後もブラウザが同じ URL で取得できるよう、proxy.pac を新しい “proxy1 IP” 側（= プロキシ2）へ移設しなければなりません。
3. 以上から導かれる三つの変更作業
   ① 旧プロキシ1の上流プロキシ設定を削除する（ループ防止）。
   ② プロキシ2に下流プロキシとして旧プロキシ1を登録する（新経路を形成）。
   ③ proxy.pac を旧プロキシ1からプロキシ2へ移し、PC が同じ URL で取得できるようにする。
4. 模範解答との一致
   • 模範解答の
     「①：プロキシ1上のプロキシサーバの定義を削除する。」
     「②：プロキシ2のプロキシサーバとしてプロキシ1を定義する。」
     「③：proxy.pac をプロキシ1からプロキシ2に移す。」
     は、上記 ①〜③ と完全に対応しており、要件を満たします。

誤りやすいポイント

• 「proxy.pac の URL は PC 側に静的に登録されている」点を見落とし、ファイル移設を忘れる。
• 旧プロキシ1の上流設定を残したままにしてしまい、プロキシ間で無限ループが発生する。
• 「プロキシサーバの IP アドレスを入れ替える」だけで経路が完成すると誤解し、プロキシ2に下流設定を入れ忘れる。

FAQ

解答の論理構成

1. 原因調査で判明した事実
   • 「プロキシ2が受け付ける TCP コネクション数が、設定の上限値まで増加」したため過負荷が発生していました。
   • 過負荷の主因は「プロキシ1の先読み機能が大量のTCPコネクションを発生させた」と考えられています。
2. 提案された対策
   • B君は「対策として、プロキシサーバのアクセス順序を変更したい」と報告し、変更後の接続イメージを「図4」に示しました。
   • 変更後は PC → プロキシ2 → プロキシ1 → インターネットという流れになり、先読みで生成される大量の TCP コネクションはプロキシ1と外部 Web サイト間で直接張られます。
3. 下線部（II）の主旨
   • 本文には「プロキシ2のボトルネックは解消しても、(II)別のボトルネックが発生する可能性がある」とあります。
   • アクセス順序変更により、プロキシ1から外部への同時接続数が増大し、その手前でパケットを中継・検査する装置が新たな負荷ポイントになります。
4. 具体的にどこがボトルネックになり得るか
   • 変更後の経路では、全ての外向き通信が「ファイアウォール」を経由します。
   • プロキシ1の先読みで発生する多数の TCP コネクションも全てファイアウォールを通過するため、
     「ファイアウォールの同時接続処理やパケットフィルタリング動作」が性能限界に近付き、新たなボトルネック候補となります。
5. 以上より、下線部（II）の解答は
   ファイアウォールの処理能力
   となります。

誤りやすいポイント

• 変更後は「プロキシ1の性能」や「インターネット回線帯域」が真っ先に問題になると誤解しやすいですが、接続数そのものを直に捌くのはファイアウォールです。
• 「プロキシ2が外部向けに開かなくなるので負荷は下がる」と短絡的に考え、ネットワーク全体の流量分布を見落とすミスが多発します。
• 図4の矢印を PC から外部サイトへの直接通信と読み違え、ファイアウォールを経由しないと誤読するケースがあります。

FAQ

解答の論理構成

1. 現状のアクセス順序は【問題文】「PC 上のブラウザはプロキシ1へアクセスし、プロキシ1はプロキシ2へアクセスする」で示すように
   　PC（ブラウザ） → プロキシ1 → プロキシ2 → Webサイト
   です。この構成だと、先読み機能をもつ「プロキシ1」が大量の TCP コネクションを下流の「プロキシ2」に投げるため、【問題文】「プロキシ2が受け付ける TCP コネクション数が、設定の上限値まで増加」し、ボトルネックになります。
2. 対策方針として B 君は【問題文】「対策として、プロキシサーバのアクセス順序を変更したい」と報告しています。先読みを行うサーバを“より出口側”に置き、先読みで発生するコネクションをプロキシ2に流さないようにするのが狙いです。
3. したがって、対策後の装置配置は
   　PC（ブラウザ） → プロキシ2 → プロキシ1 → ファイアウォール → Cサイト
   となります。先読みで作られるコネクションは「プロキシ1」が直接「ファイアウォール」に張るため、プロキシ2を通りません。
4. 図4の凡例より
   　・「⇔　CサイトアクセスによるTCPコネクション」は PC⇔プロキシ2⇔プロキシ1⇔ファイアウォール⇔Cサイト
   　・「←→　先読みによるTCPコネクション」は プロキシ1←→ファイアウォール（およびファイアウォール←→ほかのWebサイト）
   であることが分かります。
5. 以上より、解答欄には
   　(装置名) 「PC（ブラウザ）」「プロキシ2」「プロキシ1」「ファイアウォール」「Cサイト」
   　(太い矢印) PC ⇔ プロキシ2 ⇔ プロキシ1 ⇔ ファイアウォール ⇔ Cサイト
   　(細い矢印) プロキシ1 ←→ ファイアウォール（複数）
   　を記入するのが正答となります。

誤りやすいポイント

• 「プロキシ1」と「プロキシ2」の位置を入れ替えるだけで満足し、先読みコネクションの終端を誤って「プロキシ2」に書いてしまう。
• 図2の元構成をそのまま写してしまい、対策後の順序を反映しない。
• 「Cサイト」への太い矢印と先読みの細い矢印を混同し、両方とも太線で描いてしまう。
• 「ファイアウォール」を忘れる、または順序を間違えて「プロキシ1」と「Cサイト」の間に描かない。

FAQ