令和５年春　午後Ⅰ　問１

問1　Webシステムの更改に関する次の記述を読んで、設問に答えよ。

　G社は、一般消費者向け商品を取り扱う流通業者である。インターネットを介して消費者へ商品を販売するECサイトを運営している。G社のECサイトは、G社データセンターにWebシステムとして構築されているが、システム利用者の増加に伴って負荷が高くなってきていることや、機器の老朽化などによって、Webシステムの更改をすることになった。

[現行のシステム構成]

　G社のシステム構成を図1に示す。

•WebシステムはDMZに置かれたWebサーバ、DNSサーバ及びサーバセグメントに置かれたAPサーバから構成される。

•ECサイトのコンテンツは、あらかじめ用意された静的コンテンツと、利用者からの要求を受けてアプリケーションプログラムで生成する動的コンテンツがある。

•WebサーバではHTTPサーバが稼働しており、静的コンテンツはWebサーバから直接配信される。一方、APサーバの動的コンテンツは、Webサーバで中継して配信される。この中継処理の仕組みを（　a　）プロキシと呼ぶ。

•DMZのDNSサーバは、G社のサービス公開用ドメインに対する（　b　）DNSサーバであると同時に、サーバセグメントのサーバがインターネットにアクセスするときの名前解決要求に応答する（　c　）DNSサーバである。

[G社Webシステム構成見直しの方針と実施内容]

　G社は、Webシステムの更改に伴うシステム構成の変更について次の方針を立て、担当者として情報システム部のHさんを任命した。

•Webシステムの一部のサーバをJ社が提供するクラウドサービスに移行する。

•通信の効率化のため、一部にHTTP/2プロトコルを導入する。

　Hさんは、システム構成変更の内容を次のように考えた。

•DMZのWebサーバで行っていた処理をJ社クラウドサービス上の仮想サーバで行うよう構成を変更する。また、この仮想サーバは複数台で負荷分散構成にする。

•重要なデータが格納されているAPサーバは、現構成のままG社データセンターに残す。

•J社の負荷分散サービス(以下、仮想LBという)を導入する。仮想LBは、HTTPリクエストに対する負荷分散機能をもち、HTTP/1.1プロトコルとHTTP/2プロトコルに対応している。

•Webブラウザからのリクエストを受信した仮想LBは、リクエストのURLに応じてAPサーバ又はWebサーバに振り分ける。

•Webブラウザと仮想LBとの間の通信をHTTP/2とし、仮想LBとAPサーバ及びWebサーバとの間の通信をHTTP/1.1とする。

　Hさんが考えたWebブラウザからサーバへのリクエストを図2に示す。

　Hさんは、次にHTTP/2プロトコルについて調査を行った。

[HTTP/2の概要と特徴]

　HTTP/2は、HTTP/1.1との互換性を保ちながら主に通信の効率化を目的とした拡張が行われている。Hさんが注目したHTTP/2の主な特徴を次に示す。

•通信の多重化：HTTP/1.1には、同一のTCPコネクション内で通信を多重化する方式としてHTTPパイプラインがあるが、HTTP/2では、TCPコネクション内で複数のリクエストとレスポンスのやり取りを（　d　）と呼ばれる仮想的な通信路で多重化している。①HTTPパイプラインは、複数のリクエストが送られた場合にサーバが返すべきレスポンスの順序に制約があるが、HTTP/2ではその制約がない。

•ヘッダー圧縮：HPACKと呼ばれるアルゴリズムによって、HTTPヘッダー情報がバイナリフォーマットに圧縮されている。ヘッダーフィールドには、（　e　）、:scheme、:pathといった必須フィールドがある。

•フロー制御：（　d　）ごとのフロー制御によって、一つの（　d　）がリソースを占有してしまうことを防止する。

•互換性：HTTP/2は、HTTP/1.1と互換性が保たれるように設計されている。一般的にHTTP/2は、HTTP/1.1と同じく“https://”のURIスキームが用いられる。そのため、通信開始処理において（　f　）プロトコルの拡張の一つである②ALPN(Application-Layer Protocol Negotiation)を利用する。

[HTTP/2における通信開始処理]

　HTTP/2では、通信方法として、h2という識別子で示される方式が定義されている。その方式の特徴を次に示す。

•TLSを用いた暗号化コネクション上でHTTP/2通信を行う方式である。

•TLSのバージョンとして1.2以上が必要である。

•HTTP/2の通信を開始するときに、ALPNを用いて③クライアントとサーバとの間でネゴシエーションを行う。

　Hさんが理解したh2の通信シーケンスを図3に示す。

このシーケンスによって、上位プロトコルがHTTP/2であることが決定される。

[新Webシステム構成]

Hさんは新たなWebシステムの構成を考えた。Hさんが考えた新Webシステム構成を図4に示す。

　図4の新Webシステム構成に関するHさんの考えを次に示す。

•J社クラウドのVPCサービスを用いて、G社用VPCを確保する。G社用VPCセグメントではIPアドレスとして、172.21.10.0/24を用いる。

•G社用VPCセグメントの仮想ルータとG社データセンターのL3SWとの間を、J社が提供する専用線接続サービスを利用して接続する。専用線接続のIPアドレスとして、172.21.11.0/24を用い、L3SWのIPアドレスを172.21.11.1とし、仮想ルータのIPアドレスを172.21.11.2とする。

•G社データセンターとJ社クラウドとの間で通信できるように、L3SW及び仮想ルータに表1の静的経路を設定する。

•G社用VPCセグメント中に、仮想サーバを複数起動し、Webサーバとする。

•G社用VPCセグメントのWebサーバは静的コンテンツを配信する。

•G社データセンターのサーバセグメントのAPサーバは動的コンテンツを配信する。

•Webサーバ及びAPサーバは、これまでと同様にG社データセンターのDMZのDNSサーバを利用して名前解決を行う。

　Hさんは、J社クラウドの仮想LBの仕様について調べたところ、表2に示す動作モードがあることが分かった。

　④Hさんは、今回のシステム構成の変更内容を考慮して仮想LBで設定すべき動作モードを決めた。

　　Hさんは、ここまでの検討内容を情報システム部長へ報告し、承認を得た。

設問１

本⽂中及び図3中の（　a　）〜（　f　）に⼊れる適切な字句を答えよ。

a：リバース（プロキシ）

本文には「APサーバの動的コンテンツは、Webサーバで中継して配信」とあります。

ここでWebサーバはインターネットから最初に受け口としてリクエストを受け取り、裏側のAPサーバへ振り向けて結果を返します。

クライアントの代理で外へ出ていくのはフォワードプロキシですが、今はサーバ側の入口で裏のサーバ群を代表して応答する形なので、仕組みの名称はリバースプロキシになります。

b：権威（DNSサーバ）

DMZのDNSサーバが「G社のサービス公開用ドメインに対する…サーバ」と記されています。

公開ドメインの正答（ゾーン情報の原本）を保持し、外部からそのドメイン名について問われたとき最終回答を返す役割は権威DNSサーバの仕事です。

したがってここは権威が入ります。

c：キャッシュ（DNSサーバ）

同じDNSサーバが「サーバセグメントのサーバがインターネットにアクセスするときの名前解決要求に応答」とも書かれています。

社内から外部名を引くときは再帰問い合わせを行い、得た結果を保持して次回以降の応答を速くします。

これはキャッシュDNS（フルリゾルバ）の役割であり、DMZのDNSが“権威＋キャッシュ”の二役を担っている構成になっています。

d：ストリーム（HTTP/2）

HTTP/2の「同一TCPコネクション内で複数のリクエストとレスポンスを仮想的な通信路で多重化」という説明に対応する語がストリームです。

図3にも “ID:1”“ID:3” とストリーム識別子が描かれ、一本のTCPと一本のTLSセッションの上で、複数のストリームがフレーム単位で並走している様子が示されています。

HTTP/1.1のパイプラインのような“レスポンス順序の制約”はなく、ストリーム単位でフロー制御も行える点が本文の記述と一致します。

e：:method（必須ヘッダー）

HTTP/2ではヘッダーがHPACKで圧縮され、さらにコロン始まりの“擬似ヘッダー”でリクエスト行の情報を表します。

本文に例として :scheme と :path が挙がっており、同列の必須項目が :method（GET/POST など）です。

実運用では :authority も使われますが、設問の空欄はここに並べる代表的な必須フィールドとして :method を問う意図になります。

f：TLS（ALPNの属するプロトコル）

HTTP/2 は一般に “https://” で用いられ、TLS1.2以上が前提と本文にあります。

ALPNはTLSの拡張で、ClientHello/ServerHello の中で上位アプリケーションを合意する仕組みです。

図3のシーケンスも TCP三者間ハンドシェイクの後にTLSハンドシェイクが入り、その段階で“h2”が選ばれてHTTP/2通信に移ります。

ALPNはHTTPやTCPの拡張ではないため、ここに入る語はTLSになります。

設問２

[HTTP/2の概要と特徴]について答えよ。

本文中の下線①について、複数のリクエストを受けたサーバは、それぞれのリクエストに対するレスポンスをどのような順序で返さなければならないか。35字以内で答えよ。

クライアントは同じ接続上で GET を立て続けに送れますが、プロトコル側には“このレスポンスはこのリクエストに対応”というストリームIDのような識別子がありません。

対応づけは到着順＝送信順でしか判別できないため、サーバは受け取った順番どおりにレスポンスを返さなければなりません。

この制約が生むのがアプリ層のHead-of-Line（HOL）ブロッキングです。

先頭の /hero.jpg の送出が完了するまで、後続のレスポンスは待たされます。

仮に後続の処理が内部的に先に終わっても、送信は前のレスポンスの完了を待つ必要があるわけです。

結果として、パイプラインは理屈のうえでは往復遅延の隙間を埋めて効率化できる一方、大きい／遅いレスポンスが列の先頭に来ると全体が詰まるという欠点を抱えます。

ブラウザがかつて同時に複数のTCP接続を張ってしのいでいたのは、まさにこのボトルネックを避けるためでした。

1本のTLSセッション上にストリームという仮想の通信路を複数束ね、各フレームにストリームIDを付けることで、レスポンスの並走や優先制御、ストリーム単位のフロー制御が可能になります。

つまり「後から来た軽い応答が、先頭の重い応答を追い越して届く」ことができ、HTTP/1.1パイプラインの順序制約によるHOLブロッキングを避けられる、という流れです。

本文中の下線②について、ALPNを必要とする目的は何か。30字以内で答えよ。

ALPN は TLS の拡張仕様の一つで、TLS ハンドシェイクの途中（ClientHello / ServerHello のやり取り）で、クライアントとサーバが 「この暗号化通信の上でどのアプリケーションプロトコルを使うか」 を合意するために使われます。

HTTP/2 の場合、ブラウザ（クライアント）は TLS セッションを張るときに ALPN 拡張を使い、「h2（HTTP/2）」や「http/1.1」など対応可能なプロトコルの候補を送信します。

サーバはその中から自分が対応可能なものを選び、ServerHello で返します。

これにより、同じポート番号・同じ URI スキーム（https://）を使っていても、通信開始時点で確実に上位プロトコルを切り替えられるわけです。

もし ALPN がなければ、クライアントとサーバは暗号化が始まった後に別の手段でバージョン交渉をしなければならず、接続確立に余計なやり取りが必要になります。

したがって、解答例の

通信開始時にTCPの上位のプロトコルを決定するため

は正しく、もう少し具体的に言うなら「暗号化通信の確立時に、利用するアプリケーションプロトコル（HTTP/2やHTTP/1.1など）を事前に合意するため」ということになります。

設問３

[HTTP/2における通信開始処理]について答えよ。

本文中の下線③について、h2のネゴシエーションが含まれるシーケンス部分を、図3中の(a)〜(i)の記号で全て答えよ。

HTTP/2（TLS上で動くバージョン、識別子 h2）は、TCPやTLSのような下位プロトコルの上に載るアプリケーション層プロトコルです。

問題は、「このTLS接続の上でHTTP/2を使うのか、それともHTTP/1.1を使うのか」を、接続確立の早い段階でクライアントとサーバが一致させる必要があるということ。

これを行うのが ALPN（Application-Layer Protocol Negotiation） で、TLS1.2以上の拡張機能です。

図3では、(a)〜(c)がTCPの3ウェイハンドシェイクに対応しています。

その後に始まるのがTLSハンドシェイクで、(d)と(e)がクライアント・サーバの最初のやり取りです。

• (d) ClientHello
  クライアントがTLSセッション開始のメッセージを送信します。この中に、利用可能な暗号スイートやTLS拡張の情報が入ります。ALPNもこの拡張の一つで、クライアントは “h2”, “http/1.1” など自分が対応できる上位プロトコルをリストとして送ります。
• (e) ServerHello
  サーバがClientHelloに応答します。暗号スイートやセッションIDなどを確定すると同時に、ALPNで受け取ったリストの中から対応可能かつ優先度の高いプロトコル（このケースでは “h2″）を選び、選択結果を通知します。

この (d)→(e) のやり取りで、TLS暗号化が完了する前に「この接続はHTTP/2でいく」という合意ができるのです。

ALPNによる交渉はTLSハンドシェイクの初期メッセージの交換段階で終わるため、その後の（f）以降のやり取り（証明書送信や鍵交換など）は、すでに上位プロトコルが確定した状態で行われます。

したがって、h2ネゴシエーションが含まれるシーケンス部分は（d）ClientHelloと（e）ServerHelloのみということになります。

本文中の下線③について、ネゴシエーションでクライアントから送られる情報は何か。35字以内で答えよ。

TLS ハンドシェイクの最初で、クライアントは ClientHello を送ります。

この中に ALPN（application_layer_protocol_negotiation）拡張を付け、”h2″, “http/1.1” など自分が話せる上位プロトコル名を優先順で並べたリストを入れます（形式上は ProtocolName の配列で、各要素は最大255バイトの文字列）。

この“複数提示＋順序で希望を示す”のがミソで、サーバは受け取った候補の中から自分も対応できる一つを選び、ServerHello の ALPN 拡張で選択結果だけを返します。

補足すると、ALPN は TLS の拡張であって、SNI（どのホスト名向けか）とは役割が別物です。

HTTP/2 の“h2”は TLS 上で使う識別子で、平文 HTTP/2 の識別子 “h2c” は TLS では提示しません。

万一、候補に重なりが無ければ、サーバ実装次第で HTTP/1.1 にフォールバックするか、ハンドシェイクを中止します（HTTP/2 を厳格に要求する設定もあります）。

以上を踏まえると設問の答えは、解答例どおり「クライアントが利用可能なアプリケーション層のプロトコル」――すなわち ClientHello の ALPN 拡張に載せる “h2”, “http/1.1” などの候補一覧、となります。

設問４

[新Webシステム構成]について答えよ。

表1中の（　ア　）〜（　ウ　）に入れる適切なIPアドレスを答えよ。

これは専用線の向こう側、J社クラウド内のG社用VPCセグメントに属するアドレスで、Webサーバ群が配置されている場所です。

専用線そのもののネットワーク（172.21.11.0/24）はL3SWに直結しているため自動で認識されますが、その先のVPCセグメントは静的経路で明示的に指定しなければ到達できません。

これは専用線でL3SWと直結している仮想ルータのアドレスであり、この仮想ルータを経由することでクラウド内部のネットワークにアクセスできます。

静的経路の次ホップは必ず自分と同じサブネット上の機器を指定するため、このアドレスになるわけです。

これは専用線で仮想ルータと直結しているL3SWのIPアドレスです。

仮想ルータはこのアドレスを次ホップとして設定することで、データセンター内の各ネットワークに到達できます。

もしこの復路の経路設定を省略すると、行きは到達できても戻りの通信が迷子になる片方向到達の状態になり、実質的に通信が成立しません。

本文中の下線④について、Hさんが決めた動作モードを答えよ。また、その理由を“HTTP/2”という字句を用いて35字以内で答えよ。

この設問は、J社クラウドの仮想LBの「動作モード」選択に関するものです。

フロント（利用者のブラウザ）から仮想LBまではHTTP/2で受けたい。一方でバックエンドのWebサーバ／APサーバは従来通りHTTP/1.1で動かし、かつURLに応じて「静的はWebサーバ、動的はAPサーバ」に振り分ける――この三つを同時に満たすには、仮想LBがアプリケーション層でプロトコルを“理解して変換”できなければなりません。

アプリケーションモードなら、LBがTLSを終端してALPNでHTTP/2を確定し、HPACKヘッダーやフレーム化・多重化されたストリームを解釈したうえで、選んだバックエンドへHTTP/1.1の新規リクエストとして組み直して送出できます。

さらに、URLベースのルーティングやヘッダー書き換え、接続プール化（バックエンド側のコネクション再利用）もL7の機能として自然に扱えます。

パケットをそのまま転送するだけなので、フロントで受けたHTTP/2をHTTP/1.1へダウングレードすることはできませんし、URLを見てWeb/APを振り分けるといった“中身を理解する”処理もできません。

仮にトランスポートモードを選ぶなら、バックエンド側がHTTP/2とTLSを自前で終端・処理できることが前提になりますが、本件は「バックエンドはHTTP/1.1で運用」の方針なので要件不一致です。

以上から、Hさんが選ぶべき動作モードはアプリケーションモードになります。理由は解答例の通り「HTTP/2リクエストをHTTP/1.1に変換して負荷分散するから」となります。

アプリケーションモードの処理の流れ（L7ロードバランシング）

1. TLS終端・ALPNによるプロトコル確定
   仮想LBがフロント側（ブラウザ）とのTLSセッションを確立し、ALPNで「h2（HTTP/2）」を選択。暗号化通信をここで解除（終端）します。
2. HTTP/2フレームの解析と多重化の解消
   HTTP/2はストリームIDごとに分割されたフレームでやり取りされます。LBはこれを復元し、個々のリクエスト単位に処理します。HPACK圧縮されたヘッダーも解凍します。
3. ルーティング判定（URL・ヘッダー・パラメータなど）
   復元されたリクエストの内容を参照し、例えば /static/ はWebサーバ、/api/ はAPサーバへ……といった振り分けを行います。
4. HTTP/1.1への変換・送出
   バックエンドがHTTP/1.1しか話せない場合、LBがリクエストをHTTP/1.1形式に組み直し、新たに（必要ならTLSなしで）送出します。ここで接続プールやKeep-Aliveの最適化も可能です。
5. レスポンスの受信・必要に応じた再変換
   バックエンドからHTTP/1.1レスポンスを受け取り、フロント向けに必要ならHTTP/2へ再変換して返却します。

トランスポートモードの処理の流れ（L4ロードバランシング）

1. TCP接続の受け入れ
   仮想LBはTLSやHTTPの中身を見ずに、単なるTCP接続として受けます。
2. 宛先サーバの選択（IP・ポート単位）
   負荷分散アルゴリズム（ラウンドロビンなど）で接続先サーバを選びます。
3. パケットの中継
   TCPセッションを中継するだけで、プロトコルの変換や中身の書き換えは一切行いません。HTTP/2ならそのままHTTP/2としてバックエンドへ流れます。
4. レスポンスの返送
   バックエンドから受け取ったパケットをそのままクライアントへ返します。

項目	アプリケーションモード（L7）	トランスポートモード（L4）
プロトコル解析	HTTPの中身まで理解	中身は見ない（TCPのみ）
プロトコル変換	可能（HTTP/2⇔HTTP/1.1など）	不可
振り分け条件	URLパス・HTTPヘッダー・Cookieなど柔軟	IPアドレス・ポートのみ
TLS終端	LBで可能	バックエンドで実施
負荷	高い（アプリ層処理あり）	低い（中継のみ）

今回の要件は「フロントはHTTP/2、バックエンドはHTTP/1.1、さらにURLで振り分け」なので、L7でプロトコルを理解・変換できるアプリケーションモードしか適合しません。

トランスポートモードではHTTP/2⇔HTTP/1.1変換ができず、要件を満たせないのです。