ネットワークスペシャリスト 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

解答の導き方

• t1：クライアント→サーバ 「SYN」
• t2：サーバ→クライアント 「SYN, ACK」
• t3：クライアント→サーバ 「ACK」
• t4：クライアント→サーバHTTPリクエスト
• t5：サーバ→クライアントHTTPレスポンス（データ転送）
• t6〜t9：TCP切断（FIN/ACKのやりとり）および最終 ACK

• TCPコネクションの確立完了までの時間：t1 + エ
• TCPコネクションの確立完了から、ダウンロードの完了までの時間：オ
• ダウンロードの完了から、TCPコネクションの切断と情報の表示がともに完了するまでの時間：カ + t9

1. [エ]（確立完了までの追加時間）
   TCPの三者間ハンドシェイクはSYN（t1）→ SYN,ACK（t2）→ ACK（t3）で行われます。ここで本問の時間区分に合わせると、クライアント側が「コネクション確立完了と見なせる瞬間」はサーバからのSYN,ACKを受け取った時点、つまりt2終了時点と解釈します。なぜなら図3ではその直後にクライアント側のACK（t3）とHTTPリクエスト（t4）が続き、問題文の分割はt3を「確立完了以降（ダウンロードに含む）」としているからです。したがって エ：$t2$。
2. [オ]（確立完了からダウンロード完了まで）
   確立完了をt2終了時点とすると、その直後からダウンロード完了（サーバのレスポンス送信完了、t5終了）までに含まれるのは、クライアントのACK（t3）、クライアントのHTTPリクエスト送信時間（t4）、およびサーバのレスポンス送信時間（t5）です。したがって オ：$t3+t4+t5$。
3. [カ]（ダウンロード完了から切断・表示完了までの先行分）
   ダウンロード完了はt5終了時点で、その後のTCP切断のやりとりはt6（クライアントのFIN）、t7（サーバのACK）、t8（サーバのFIN）、t9（クライアントの最終ACK）です。問題文は「…までの時間：カ + t9」としてt9を別扱いにしているので、[カ] に入るのはt6 + t7 + t8です。したがって カ：$t6+t7+t8$。
4. [キ]（キャッシュが最新であった場合の短縮量）
   問題文ではクライアントがキャッシュを持ち、条件付きGET（最終更新時刻付きGET）を送るとあります。キャッシュが最新であればサーバは304 Not Modifiedを返し、フルデータのダウンロードが不要になります。図3の通常取得と比較して短縮されるのは、図3中でウェブページ取得に相当するリクエスト送信とレスポンス（ダウンロード）に要する時間、すなわちt4とt5の合計です。したがって キ：$t4+t5$。

誤りやすいポイント

• 「TCP接続の確立完了 = クライアントがACKを送った時点（t3）」と誤解する点。問題文の時間分割では、クライアントがサーバのSYN,ACKを受け取った時点（t2終了）を基準にしており、t3は確立後の処理に含まれます。定義を問題文に合わせて取ることが重要です。
• t3（クライアントのACK）を無視してしまう点。t3は短い区間でも、問題の区分ではダウンロード開始側に含まれるため、オ の計算に含める必要があります。
• キャッシュによる短縮量（キ）を「t5だけ」と考えてしまう点。問題は「図3と比べて短縮される量」を問うており、図3での取得にかかるリクエスト＋レスポンスの時間（t4 + t5）を基準にするのが正解です。

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. 過負荷を起こしていた装置の特定
   • ログ調査の結果、問題発生時には「プロキシ2が受け付けるTCPコネクション数が、設定の上限値まで増加している」一方で「プロキシ1が受け付けるTCPコネクション数は上限値の半数以下」であることが判明しました。
   • したがって、プロキシ2がボトルネックになっていると分かります。
2. コネクション増加の原因
   • 「Cサイトは、ほかのWebサイトへのリンク情報が多いので、プロキシ1の先読み機能が大量のTCPコネクションを発生させた」とあります。
   • 先読み通信はプロキシ1→プロキシ2の方向に流れるため、プロキシ2が先読みトラフィックまで処理してしまい輻輳が発生していました。
3. 解決策の方針
   • B君は「対策として、プロキシサーバのアクセス順序を変更したい」と報告しています。
   • 目的は「先読み機能を有効にしたまま、プロキシ2のボトルネックを回避する」ことです。
4. 新しいアクセス順序の決定
   • 先読みはウイルスチェック（プロキシ2）を通す必要がありません。
   • そこで、PCから見て先にプロキシ2（ウイルスチェック）を置き、後段にプロキシ1（キャッシュ・URLフィルタリング）を置けば、
     • Cサイトへの本流データは　PC → プロキシ2 → プロキシ1 → ファイアウォール → Cサイト
     • 先読みデータは　プロキシ1 → ファイアウォール → ほかのWebサイト
     となり、プロキシ2は先読みトラフィックを処理せずに済みます。
5. 解答図（装置名とTCPコネクション）
   • 左から「PC（ブラウザ）」「プロキシ2」「プロキシ1」「ファイアウォール」「Cサイト」
   • 太線（⇔）で示すCサイト用TCPコネクション：PC ⇔ プロキシ2 ⇔ プロキシ1 ⇔ ファイアウォール ⇔ Cサイト
   • 細線（←→）で示す先読み用 TCP コネクション：プロキシ1 ←→ ファイアウォール ←→ ほかのWebサイト

誤りやすいポイント

• 「プロキシ1が先読みを行う＝プロキシ1だけが大量接続を持つ」と短絡し、プロキシ2の接続数増加を見落とす。
• 先読み通信もウイルスチェック対象と考え、プロキシ2を前段に置く意図を逆に解釈してしまう。
• 図4の細線と太線を区別せず、すべてのTCPコネクションをプロキシ2経由と描いてしまう。
• 「プロキシサーバのIPアドレスを入れ替え」作業を行わずにPACファイルだけ修正すれば済むと思い込み、(I) で指摘されている「三つの変更作業」を軽視する。

FAQ