ネットワークスペシャリスト 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. 実装上はTLSのClientHelloのALPN拡張に、クライアントがサポートするアプリケーション層プロトコルの一覧を入れて送信し、サーバがその中から一つを選びます。
3. 以上より、ネゴシエーションでクライアントから送られる情報は「クライアントが利用可能なアプリケーション層のプロトコル」です。

誤りやすいポイント

• ALPNはTLSの暗号方式や証明書情報を交渉する拡張だと誤解する。暗号スイートは別のTLSフィールドで交渉され、ALPNはアプリケーション層プロトコルの選択に使われます。
• SNI（Server Name Indication）と混同して「サーバ名」を送ると答える。SNIは別のTLS拡張であり、用途が異なります。
• 「プロトコル」とだけ書いて曖昧にする。設問の趣旨はアプリケーション層のプロトコルである点を明示する必要があります。
• ALPNでサーバが必ずHTTP/2を選ぶ・ALPN不一致でTLSが必ず失敗すると考える。サーバの実装によってはフォールバックしたり接続を切断したりします（ただしこれは設問の直接解答ではありません）。

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