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

解答の論理構成

• 【問題文】では「Webサーバ…この中継処理の仕組みを a プロキシと呼ぶ」と記載されています。
  フロントの Web サーバがクライアントの代わりにバックエンドの AP サーバへ要求を転送する形態は “逆向き” のプロキシであるため、a＝「リバース」と判断できます。
• DMZ の DNS サーバについて【問題文】は「G 社のサービス公開用ドメインに対する b DNS サーバ」と述べています。公開ドメインを正式に回答する DNS は「権威 DNS サーバ」であるため、b＝「権威」となります。
• 同じ DNS サーバが「サーバセグメントのサーバがインターネットにアクセスするときの名前解決要求に応答するcDNS サーバ」とも明示されています。内部からの問い合わせ結果を保存して再利用する役割は「キャッシュ DNS サーバ」であり、c＝「キャッシュ」です。
• HTTP/2 の多重化について【問題文】は「…複数のリクエストとレスポンスのやり取りを d と呼ばれる仮想的な通信路で多重化している」と説明しています。HTTP/2 仕様（RFC 9113）でこの仮想通信路は「ストリーム」と定義されているので、d＝「ストリーム」です。
• ヘッダーフィールド名の例として【問題文】に「e 、:scheme, :path といった必須フィールド」とあり、HTTP/2 の擬似ヘッダーで :scheme や :path と同列の必須項目は「:method」です。従って e＝「:method」となります。
• 最後に「通信開始処理において f プロトコルの拡張の一つである…ALPN」とあり、ALPN は TLS 拡張の一種であることが IETF RFC 7301 に示されています。よって f＝「TLS」です。

誤りやすいポイント

• a を「フォワード」と誤記する例が頻発しますが、フォワードプロキシはクライアント側ネットワークに設置される点が異なります。
• b を「公開」DNS と表現すると減点対象です。DNS の正式な役割名を求めているため「権威」が必要です。
• c を「フルサービス」DNS と答えるケースがありますが、問題文はキャッシュ機能に触れているので適切ではありません。
• d を「セッション」や「チャンネル」と混同しやすいですが、HTTP/2 用語での公式名称は「ストリーム」です。
• e を単に「method」や「GET」と誤答しやすいですが、コロン付きの擬似ヘッダー「:method」が必須です。
• f を「SSL」とすると TLS1.2 以上という条件と矛盾します。

FAQ

解答の論理構成

• 【問題文】には「① HTTP パイプラインは、複数のリクエストが送られた場合にサーバが返すべきレスポンスの順序に制約がある」とあります。
• ここでいう“制約”とは、HTTP/1.1 のパイプライン機能において パケットが到着した順番どおりにレスポンスを返す 必要があるという仕様を指します。
• したがって、サーバは「リクエストを受信した順序」と「レスポンスを送信する順序」を一致させねばならず、この一点を端的に述べれば模範解答となります。

誤りやすいポイント

• 「先に処理が終わったものから返してよい」と誤解し、HTTP/2 の特性と混同してしまう。
• “順序”ではなく“同時”や“まとめて”など、粒度の異なる表現を書いてしまう。
• パイプライン制約を TCP の並び順保証と混同し、レイヤをまたいだ説明にしてしまう。

FAQ

解答の論理構成

1. 問題文は、HTTP/2 通信開始時に「②ALPN (Application-Layer Protocol Negotiation) を利用」と明記しています。
2. さらに、「③クライアントとサーバとの間でネゴシエーションを行う」とあるため、ALPN の役割は“ネゴシエーション”であることが分かります。
3. 何をネゴシエートするかについては、HTTP/2 の特徴として「HTTP/1.1 との互換性」を挙げ、「一般的に HTTP/2 は、HTTP/1.1 と同じく “https://”の URI スキームが用いられる」と説明しています。つまり TLS ハンドシェイク時点では上位アプリケーションプロトコルが確定していません。
4. そこで ALPN を使い、クライアントとサーバが TCP コネクション確立後、TLS ハンドシェイク中に“HTTP/2（h2）なのか、HTTP/1.1 なのか”を合意し、以後の通信を適切なプロトコルで行います。
5. 以上から、ALPN を必要とする目的は「通信開始時に TCP の上位のプロトコルを決定するため」となります。

誤りやすいポイント

• ALPN を“暗号方式”や“TLS のバージョン判定”と誤解する。ALPN はあくまでアプリケーション層プロトコルの選択に用いる拡張です。
• HTTP/2 導入＝必ず ALPN と短絡し、h2c（平文 HTTP/2）など ALPN を用いないパターンを忘れる。
• HTTP/1.1 と HTTP/2 の切替を「ポート番号」で行うと誤認する。実際にはどちらも 443 で、TLS 拡張により区別します。

FAQ

解答の論理構成

1. 問題文は、HTTP/2 の開始時に「ALPN (Application-Layer Protocol Negotiation) を利用して、③クライアントとサーバとの間でネゴシエーションを行う」と述べています。この “ネゴシエーション” の対象は上位プロトコル（今回なら h2）を決定する処理です。
   引用：「HTTP/2 の通信を開始するときに、ALPN を用いて③クライアントとサーバとの間でネゴシエーションを行う。」
2. ALPN は TLS ハンドシェイクの一部として動作する仕様です。したがって、ネゴシエーションが含まれるシーケンスは TLS ハンドシェイク区間であり、TCP 3ウェイハンドシェイクや実データ（HTTP/2 フレーム）の区間には含まれません。
3. 図3中で TLS ハンドシェイクに対応する記号は (d) と (e) です。
   ・(d) は ClientHello：クライアントが “h2” などの ALPN 候補を提示するタイミング
   ・(e) は ServerHello：サーバが “h2” を選択して応答するタイミング
   これら2つのメッセージに ALPN 情報が格納されるため、ネゴシエーションはこの区間で完結します。
4. 以上から、h2 のネゴシエーションが含まれるシーケンス部分は (d)、(e) の2箇所が該当し、模範解答「(d)、(e)」が成立します。

誤りやすいポイント

• ALPN が TLS ハンドシェイク内の拡張 であることを忘れ、HTTP/2 の実データ転送区間 (f)〜(i) を選んでしまう。
• 「TCP3ウェイハンドシェイクでも何か交渉しているはず」と誤認し、(a)〜(c) を含めてしまう。
• 「ClientHello だけで十分」と早合点して (d) しか答えず、(e) を落としてしまう。
• HTTP/2 の「通信の多重化」をd（ストリーム）で覚えている流れで、ストリーム生成区間と勘違いする。

FAQ

解答の論理構成

1. 本問は、下線部③「クライアントとサーバとの間でネゴシエーションを行う」際に、クライアントが送信する“情報の内容”を問うています。
2. 【問題文】には、HTTP/2 の互換性説明として
   「通信開始処理において f プロトコルの拡張の一つである②ALPN (Application-Layer Protocol Negotiation) を利用」
   とあります。
3. ALPN は TLS 拡張であり、クライアントが“自身が利用可能なアプリケーション層プロトコルの一覧”を送信し、サーバがその中から一つを選択する仕組みです。
4. したがって、ネゴシエーションでクライアントから送られる情報は
   「クライアントが利用可能なアプリケーション層のプロトコル」
   となります。

誤りやすいポイント

• ALPN を「サーバが送る情報」と誤解しやすい
  → サーバは選択結果を返すだけで、候補リストはクライアントが提示します。
• SNI（Server Name Indication）と混同しやすい
  → SNI はホスト名の提示、ALPN はプロトコル候補の提示です。
• 「HTTP/2 固有のメッセージ」と考えてしまう
  → ALPN 自体は TLS 拡張であり、HTTP/2 以外のプロトコル選択にも利用されます。

FAQ

解答の論理構成

1. 宛先ネットワークの把握
   問題文には「G社用VPCセグメントではIPアドレスとして、172.21.10.0/24 を用いる。」と記載されています。したがって、L3SWから見てクラウド側（VPC）へ通信する場合の宛先ネットワークは 172.21.10.0/24 です。
2. ネクストホップの決定
   同じく「専用線接続のIPアドレスとして、172.21.11.0/24 を用い、L3SWのIPアドレスを 172.21.11.1 とし、仮想ルータのIPアドレスを 172.21.11.2 とする。」とあります。
   • L3SWからVPCへは専用線の対向である仮想ルータ（172.21.11.2）がネクストホップになります。
   • 仮想ルータから社内向けおよびインターネット向けのデフォルトゲートウェイはL3SW（172.21.11.1）です。
3. 表1の方向性
   表1では、
   ・L3SWの静的経路は「宛先ネットワーク → VPC、ネクストホップ → 仮想ルータ」
   ・仮想ルータの静的経路は「宛先ネットワーク → 0.0.0.0/0、ネクストホップ → L3SW」
   という役割分担が求められています。
4. 以上より表1の空欄に入る値
   ア：172.21.10.0/24
   イ：172.21.11.2
   ウ：172.21.11.1

誤りやすいポイント

• 専用線側ネットワーク（172.21.11.0/24）とVPC側ネットワーク（172.21.10.0/24）を取り違える。
• 「ネクストホップ＝相手機器のIP」という原則を忘れ、自分自身のIPを設定してしまう。
• 仮想ルータのデフォルトルートをクラウド側インターネットゲートウェイへ向けると想定し、172.21.11.1 を誤って除外する。

FAQ

解答の論理構成

• 仮想 LB が担う通信内容
  【問題文】では
  「Webブラウザと仮想 LB との間の通信を HTTP/2 とし、仮想 LB と AP サーバ及び Webサーバとの間の通信を HTTP/1.1 とする。」
  と明記されています。仮想 LB は異なるバージョンの HTTP を“理解して変換”しつつ振り分ける必要があります。
• どの階層で処理すれば変換できるか
  表2で示された動作モードのうち、
  「アプリケーションモード：レイヤー7で動作して負荷分散処理を行う。」
  「ネットワークモード：レイヤー4で動作して負荷分散処理を行う。」
  とあります。HTTP/2 と HTTP/1.1 はいずれもアプリケーション層のプロトコルなので、バージョン変換にはレイヤー7処理が必須です。
• 結論
  以上より、H さんが選ぶべきは「アプリケーションモード」であり、理由は「HTTP/2 → HTTP/1.1 の変換を伴う負荷分散」を実現できるからです。

誤りやすいポイント

• 高速化目的で「ネットワークモード」を選択してしまう
  レイヤー4処理ではパケット転送は高速ですが、HTTP バージョンを解釈できないため変換不可です。
• 「HTTP/2 は下位互換性があるから変換不要」と誤認する
  バージョンネゴシエーションは端点間でのみ成立します。サーバ側が HTTP/1.1 の場合、LB で変換しなければ通信できません。
• 「HTTP/2 を通すだけなら L4 で十分」と考える
  本設問は“HTTP/2 リクエストを HTTP/1.1 に変換”という処理を明示している点が要注意です。

FAQ