応用情報技術者 2021年 春期 午後 問05
チャット機能の開発に関する次の記述を読んで、設問1〜3に答えよ。
E社は、旅行商品の企画、運営、販売を行う旅行会社である。E社の旅行商品は、自社の販売店と販売代理会社の販売店を通じて販売している。販売店に顧客が来ると、販売スタッフがE社の旅行販売システムを利用して、顧客の要望に合う旅行商品を検索し、顧客に提案している。また、顧客からの旅行商品に関する質問の回答が分からない場合、E社の販売店向けコールセンタに電話で問い合わせることになっているが、販売店からは“コールセンタに電話が繋がらない”などの苦情が出ている。
そこでE社は、販売店とコールセンタのスタッフがテキストメッセージで相互にやり取りできるチャット機能を、旅行販売システムに追加することにした。チャット機能の開発は、E社システム部門のF君が担当することになった。
〔ネットワーク構成の調査〕
F君は、チャット機能を開発するに当たり、現在のネットワーク構成を調査した。図1にF君が調査したネットワーク構成（抜粋）を示す。
旅行販売システムは、2台のAPサーバと負荷分散装置から構成されている。負荷分散装置はAPサーバの負荷を分散させるために利用される。DNSサーバのAレコードには、旅行販売システムのIPアドレスとして a が登録されている。
販売代理会社の販売店のPCから旅行販売システムへの通信は、FW、ルータ、プロキシサーバを経由している。FW#3では、NAPTを行い、宛先ポートが53番ポート、80番ポート又は443番ポートで宛先ネットワークアドレスが10.10.0.0のIPパケットとその返信IPパケットだけを通信許可する設定となっている。
販売代理会社の販売店のPCがHTTPを利用して旅行販売システムにアクセスする場合、プロキシサーバはPCから受信したGETメソッドを参照して、APサーバへHTTPリクエストを送信する。一方、HTTP Over TLSを利用する場合、プロキシサーバは旅行販売システムの機器とTCPコネクションを確立し、①PCから受信したデータをそのまま送信する。
また、販売代理会社の販売店のPCから旅行販売システムへアクセスする場合、PCからFW#4に送信されるIPパケットの宛先IPアドレスは b となり、代理会社接続ルータからFW#1に送信されるIPパケットの送信元IPアドレスは c となる。
〔チャット機能の実装方式の検討〕
次にF君は、チャット機能の実装方式を検討した。チャット機能を実装する場合、旅行販売システムで利用している②HTTPでは実装が困難である。そこでF君は、チャット機能の実装のためにWebSocketについて調査を行った。図2にF君が調査したWebSocketを利用した通信（抜粋）を示す。
WebSocketを利用すると、PCとAPサーバの間のHTTPを用いた通信を拡張し、任意フォーマットのデータの双方向通信ができる。WebSocketを利用するためには、PCからAPサーバにHTTPと同様のGETメソッドを送信する。このGETメソッドのHTTPヘッダに“Upgrade: websocket”と“Connection: Upgrade”を含めることで、PCとAPサーバの間でWebSocketの接続が確立する。接続が確立したら、PCとAPサーバのどちらからでも、テキストメッセージを送信できる。
この調査結果からF君は、IRC（Internet Relay Chat）プロトコルや新たにチャット機能専用のプロトコルを利用する場合と比較し、③WebSocketを利用することで販売代理会社のFWやルータの設定変更を少なくできると考えた。
〔チャット機能の設計レビュー〕
F君は、APサーバにチャット機能を追加するための設計を行い、上司のG課長のレビューを受けた。レビューの結果、G課長から次の2点の指摘があった。
指摘1. WebSocketはTCPコネクションを確立したままにするので、負荷分散装置を経由してチャット機能へアクセスすると、旅行販売システムの既存機能へのアクセスに影響がある。
指摘2. チャット機能をWebSocket Over TLSに対応させないと、販売代理会社からプロキシサーバを経由してチャット機能にアクセスできない。
F君は指摘1について、チャット機能では負荷分散装置を使わないことにし、E社データセンタ内にある機器を利用した④ほかの負荷分散方式に変更した。
次に指摘2について、WebSocketを利用した通信ではTCPコネクションを確立したままにする必要があるので、プロキシサーバのHTTP Over TLSのデータをそのまま送信する機能を利用することで、プロキシサーバ経由でチャット機能が利用できる。そこで、F君はTLS証明書を d にインストールし、チャット機能の通信をHTTP Over TLSに対応させた。
その後F君が、チャット機能を旅行販売システムに追加したことで、販売店でのチャット機能の利用が開始された。
設問1：〔ネットワーク構成の調査〕について、(1)～(3)に答えよ。
問題文を見る模範解答
a：10.10.0.10
b：192.168.0.3
c：10.1.1.2
解説
解答の導き方
まず設問は図1の記述・表示されたIPアドレスを元に、PCやルータを流れるIPパケットのヘッダに入る「宛先／送信元アドレス」を特定する問題です。以下、a,b,cそれぞれについて図1のどの記述を根拠にして答えを導くかを段階的に示します。
a）10.10.0.10
- 問いの意味：DNSのAレコードに登録される「旅行販売システムのIPアドレス」を問うています。つまり外部（販売店など）から名前でアクセスしたときに到達する入口のIPです。
- 根拠と考え方：本文に「旅行販売システムは、2台のAPサーバと負荷分散装置から構成されている」とあり、図1には「負荷分散装置 10.10.0.10」と記載されています。外部からの入口は負荷分散装置（ロードバランサ）になるため、Aレコードに登録されるIPは負荷分散装置のIPであると判断できます。
- よってa＝10.10.0.10。
b）192.168.0.3
- 問いの意味：販売代理会社の販売店のPCがFW#4に送るIPパケット（PC→FW#4）のIPヘッダの宛先IPを問うています。ここで注意するのは「PCが送るパケットのIP宛先」であって、L2の送信先（FW#4のMAC）とは別である点です。
- 根拠と考え方：本文に「販売代理会社の販売店のPCがHTTPを利用して旅行販売システムにアクセスする場合、プロキシサーバはPCから受信したGETメソッドを参照して、APサーバへHTTPリクエストを送信する」とあり、PCは明示的プロキシを利用している構成です。図1には本社側の「プロキシサーバ192.168.0.1 192.168.0.2 192.168.0.3 192.168.0.4」と並記されています（図示の販売店PCのプロキシ設定は192.168.0.3を指しています）。
- 結論として、PCがFW#4に送るIPパケットのIPヘッダの宛先は「プロキシサーバのIP」であり、図示の設定に従って192.168.0.3となります。補足として技術的に正確に言えば、PCは宛先IP 192.168.0.3を含むパケットを作り、そのパケットはL2でFW#4に届けられますがIPヘッダの宛先は変わりません。
- よってb＝192.168.0.3。
c）10.1.1.2
- 問いの意味：代理会社接続ルータからFW#1へ送られるパケットの送信元IP（＝その時点での送信元アドレス）を問うています。これは、代理会社側の出口でどのアドレスに変換されているかを問うているということです。
- 根拠と考え方：本文に「FW#3では、NAPTを行い…」とあり、図1に「FW#3 10.1.1.2」と記載されています。NAPTは内部プライベートな送信元IP:ポートを外部で共有するアドレス（ここではFW#3の外向きIP）へ書き換えます。プロキシや販売店PCから出たパケットがFW#3を越えて代理会社接続ルータへ向かう際、送信元IPはNAPTによりFW#3のアドレスである10.1.1.2になります。
- よってc＝10.1.1.2。
まとめ（解答）
a：10.10.0.10
b：192.168.0.3
c：10.1.1.2
a：10.10.0.10
b：192.168.0.3
c：10.1.1.2
誤りやすいポイント
- DNSのAレコード（a）をAPサーバ個々のIP（10.10.0.11/10.10.0.12）と混同する。図にロードバランサ（負荷分散装置）があり、外部の入口はそこなのでAレコードはロードバランサのIPになる点を忘れないこと。
- PCが送るパケットの宛先（b）を最終的なサーバ（10.10.0.10など）と誤解する。明示的プロキシを使う構成では、PC→ゲートウェイへ送るIPパケットの宛先は「プロキシのIP」である点が重要。複数のプロキシが図示されている場合は図中でPCに割り当てられているプロキシIP（本問では192.168.0.3）を選ぶ。
- NAPTの位置を誤認して送信元IP（c）を代理会社接続ルータのIP（10.1.1.1）と答える。FW#3がNAPTを実施し、その外向きアドレス10.1.1.2が送信元になる点に注意する。
- HTTPS/HTTP Over TLSの挙動を誤解して、PCの送信先IPが直接旅行販売システムになると考える誤り。問題文にある通り、HTTP Over TLSでもプロキシ経由ではプロキシとのTCPコネクションを張る（PCから見ると送先はプロキシ）ため、宛先IPはプロキシのままです。
FAQ
Q: プロキシが複数並んでいる場合、どれを選べばよいですか？
A: 問題文／図で「どのプロキシがその販売店PCに使われているか」が示されています。設問は図1中の字句を使う指定なので、図で販売店PCのプロキシ設定を指すIP（本問では「192.168.0.3」）を選びます。実務ではクライアントのプロキシ設定やロードバランスの方式を確認します。
A: 問題文／図で「どのプロキシがその販売店PCに使われているか」が示されています。設問は図1中の字句を使う指定なので、図で販売店PCのプロキシ設定を指すIP（本問では「192.168.0.3」）を選びます。実務ではクライアントのプロキシ設定やロードバランスの方式を確認します。
Q: なぜ代理会社接続ルータからの送信元が10.1.1.2になるのですか？
A: 図と本文に「FW#3では、NAPTを行い…」とあり、FW#3の外向きIPが10.1.1.2と示されています。NAPTにより内部の複数IPはFW#3の外向きIPに変換されるため、E社側へ届くパケットの送信元は10.1.1.2になります。
A: 図と本文に「FW#3では、NAPTを行い…」とあり、FW#3の外向きIPが10.1.1.2と示されています。NAPTにより内部の複数IPはFW#3の外向きIPに変換されるため、E社側へ届くパケットの送信元は10.1.1.2になります。
Q: PC→FW#4のパケットでL2の送信先はFW#4のMACになるのに、宛先IPがプロキシである理由は？
A: IPルーティングの基本動作です。ローカルからデフォルトゲートウェイへ送る際、L2（イーサネット）フレームの宛先はゲートウェイのMACになりますが、IPヘッダの宛先フィールドは到達させたい最終のIP（ここではプロキシ）を保持します。プロキシを使う構成ではこれが通常の振る舞いです。
A: IPルーティングの基本動作です。ローカルからデフォルトゲートウェイへ送る際、L2（イーサネット）フレームの宛先はゲートウェイのMACになりますが、IPヘッダの宛先フィールドは到達させたい最終のIP（ここではプロキシ）を保持します。プロキシを使う構成ではこれが通常の振る舞いです。
関連キーワード: WebSocket、NAPT、プロキシサーバ、TLS、負荷分散
設問1：〔ネットワーク構成の調査〕について、(1)～(3)に答えよ。
問題文を見る（2）E社販売店のPC及び販売代理会社の販売店のPCが旅行販売システムにアクセスするためには、どの機器のDNS設定にE社のDNSサーバのIPアドレスを設定する必要があるか、解答群の中から全て選び、記号で答えよ。
解答群
ア：E社販売店のPC
イ：FW#1
ウ：FW#2
エ：FW#3
オ：FW#4
カ：店舗接続ルータ
キ：販売代理会社の販売店のPC
ク：負荷分散装置
ケ：プロキシサーバ
模範解答
ア、ケ
解説
解答の論理構成
-
DNS問い合わせが必要となるタイミング
- 旅行販売システムへTCPコネクションを張る直前に、ホスト名をIPアドレスへ変換する機器だけがDNSを利用します。
- 【問題文】には「DNSサーバのAレコードには、旅行販売システムのIPアドレスとして a が登録されている。」とあり、このAレコードを参照できる機器を特定します。
-
E社販売店側の経路
- 図1よりE社販売店のPCは直接FW#2 → FW#1 → 負荷分散装置へと通信します。途中にプロキシは存在しません。
- 従って、旅行販売システムのホスト名をIPアドレスへ変換するのは「ア：E社販売店のPC」です。
-
販売代理会社側の経路
- 【問題文】「販売代理会社の販売店のPCがHTTPを利用して旅行販売システムにアクセスする場合、プロキシサーバはPCから受信したGETメソッドを参照して、APサーバへHTTPリクエストを送信する。」
- さらに「HTTP Over TLSを利用する場合、プロキシサーバは旅行販売システムの機器とTCPコネクションを確立し、①PCから受信したデータをそのまま送信する。」
- いずれの場合も実際に旅行販売システムとTCPコネクションを張るのはプロキシサーバです。したがってDNSで名前解決を行うのは「ケ：プロキシサーバ」になります。
- 販売代理会社のPC（キ）やFW#4は、プロキシサーバのIPアドレスさえ分かればよく、旅行販売システムのDNS情報を直接参照する必要はありません。
-
以上からDNSサーバのIPアドレスを設定すべき機器は
ア：E社販売店のPC
ケ：プロキシサーバ
誤りやすいポイント
- 「PCは必ずDNSを使う」と思い込み、販売代理会社のPC（キ）まで選んでしまう。実際にはプロキシ指定の場合、PCはホスト名変換を行わない。
- FWやルータも“名前解決するのでは”と考え、FW#3やFW#4を選択してしまう。FWはIPアドレスベースでフィルタリングするだけでDNSは不要。
- 旅行販売システム側の負荷分散装置（ク）は外部からのアクセスを受ける装置ですが、自身が名前解決を行うわけではない。
FAQ
Q: 販売代理会社のPCがproxyをドメイン名で設定している場合、そのPCもDNSが必要では？
A: 問題の焦点は「旅行販売システムへアクセスする際にE社DNSサーバを参照するか」です。代理会社内部のDNS解決は設問の対象外なので、解答には影響しません。
A: 問題の焦点は「旅行販売システムへアクセスする際にE社DNSサーバを参照するか」です。代理会社内部のDNS解決は設問の対象外なので、解答には影響しません。
Q: HTTPS (HTTP Over TLS) でもプロキシがDNSを行うのはなぜ？
A: 【問題文】で示されている通り、プロキシサーバが「旅行販売システムの機器とTCPコネクションを確立」するため、ドメイン名をIPアドレスに変換する必要があります。PCはCONNECTメソッドでトンネルを要求するだけです。
A: 【問題文】で示されている通り、プロキシサーバが「旅行販売システムの機器とTCPコネクションを確立」するため、ドメイン名をIPアドレスに変換する必要があります。PCはCONNECTメソッドでトンネルを要求するだけです。
Q: FW#1やFW#3がDNSを使う可能性は？
A: 両FWはパケットを通過させる役割であり、フィルタ条件も「宛先ポートが53番ポート、80番ポート又は443番ポート」で定義されています。自身がDNSクライアントとして動作する場面は想定されていません。
A: 両FWはパケットを通過させる役割であり、フィルタ条件も「宛先ポートが53番ポート、80番ポート又は443番ポート」で定義されています。自身がDNSクライアントとして動作する場面は想定されていません。
関連キーワード: DNS, プロキシ, 名前解決, Aレコード, HTTP Over TLS
設問1：〔ネットワーク構成の調査〕について、(1)～(3)に答えよ。
問題文を見る（3）本文中の下線①について、プロキシサーバがPCから送信されたデータをそのまま送信するのはなぜか、30字以内で述べよ。
模範解答
プロキシサーバはGETメソッドの内容が見えないから
解説
解答の論理構成
-
【問題文】には、HTTPの場合とHTTP Over TLSの場合でプロキシサーバの動作が対比されています。
- 「販売代理会社の販売店のPCが HTTP を利用して旅行販売システムにアクセスする場合、プロキシサーバはPCから受信したGETメソッドを参照して、APサーバへHTTPリクエストを送信する。」
- 一方で、HTTP Over TLSでは「プロキシサーバは旅行販売システムの機器とTCPコネクションを確立し、①PCから受信したデータをそのまま送信する。」
-
HTTP Over TLSでは、PCとAPサーバ間のアプリケーション層データ（GETメソッドやヘッダ部、ボディ部）はTLSによって暗号化されます。この暗号化の結果、
- プロキシサーバはパケットのペイロード内に含まれるGETメソッドやURL、ヘッダを復号できない
- 従ってHTTPのときのように内容を参照・加工することが不可能
-
以上より、プロキシサーバはデータ内容を理解できない状態で「PCから受信したデータをそのまま送信」せざるを得ません。
誤りやすいポイント
- 「TLSを終端しているのはプロキシサーバ」と思い込み、復号できると誤解するケース。実際はPCとAPサーバ間でエンドツーエンド暗号化が確立しているためプロキシは暗号文しか扱えません。
- GETメソッドが常に平文で流れると考え、HTTPとHTTP Over TLSの違いを見落とすケース。
- NAPTやFWの設定制限が理由と早合点し、暗号化による可視性低下という本質を外してしまうケース。
FAQ
Q: プロキシサーバがTLS通信内容を解析したい場合はどうしますか？
A: 組織内プロキシがTLSインスペクション（中間者証明書）を導入し、通信を一度復号する方式があります。ただし販売代理会社のプロキシはその設定を行っていない前提です。
A: 組織内プロキシがTLSインスペクション（中間者証明書）を導入し、通信を一度復号する方式があります。ただし販売代理会社のプロキシはその設定を行っていない前提です。
Q: HTTP Over TLSでCONNECTメソッドを使う形ではないのですか？
A: 問題文は直接CONNECTを明示していませんが、一般にトンネリング型プロキシではCONNECTメソッドで443番ポートへのTCPコネクションを張り、後続の暗号化データをそのまま中継します。本問も同じ仕組みと読み取れます。
A: 問題文は直接CONNECTを明示していませんが、一般にトンネリング型プロキシではCONNECTメソッドで443番ポートへのTCPコネクションを張り、後続の暗号化データをそのまま中継します。本問も同じ仕組みと読み取れます。
Q: WebSocketを利用するときも同じ理由で「そのまま送信」となるのですか？
A: はい。WebSocket Over TLSではハンドシェイク以降のフレームがTLSで暗号化されるため、プロキシは中身を解釈できず単純中継になります。
A: はい。WebSocket Over TLSではハンドシェイク以降のフレームがTLSで暗号化されるため、プロキシは中身を解釈できず単純中継になります。
関連キーワード: TLS, プロキシサーバ, 暗号化, HTTPS, GETメソッド
設問2：〔チャット機能の実装方式の検討〕について、(1)、(2)に答えよ。
問題文を見る（1）本文中の下線②について、チャット機能をHTTPで実装するのはなぜ困難か、解答群の中から選び、記号で答えよ。
解答群
ア：PCはAPサーバ上のファイルを取得することしかできないから
イ：PCへのメッセージ送信はAPサーバ側で発生したイベントを契機として行うことができないから
ウ：TCPコネクションを確立したままにできないから
エ：どのPCから送られたメッセージか、APサーバが判別できないから
模範解答
イ
解説
解答の論理構成
- 問題文には「チャット機能を実装する場合、旅行販売システムで利用している②HTTPでは実装が困難である。」とあります。
- チャット機能では “PCとAPサーバのどちらからでも、テキストメッセージを送信できる”（WebSocket説明部）ことが必須です。
- ところがHTTPはリクエスト／レスポンス型プロトコルであり、通信の主導権は常にクライアント（ここでは「PC」）側にあります。サーバ側（ここでは「APサーバ」）からクライアントへ能動的にメッセージを送るしくみが標準では用意されていません。
- 解答群を照合すると、「イ：PCへのメッセージ送信はAPサーバ側で発生したイベントを契機として行うことができないから」が上記3. を正確に述べています。
- よって解答は「イ」となります。
誤りやすいポイント
- 「ウ：TCPコネクションを確立したままにできないから」を選びがちですが、HTTP/1.1にはConnection: keep-aliveによりコネクションを維持する仕組みがあるため誤りです。
- 「ア」「エ」はファイル取得や送信元判別の話で、チャットの双方向性課題とは無関係です。
- HTTP長輪接続とサーバからの“プッシュ”を混同しやすい点に注意が必要です。
FAQ
Q: HTTPのロングポーリングを使えばサーバからの通知も可能では？
A: ロングポーリングはクライアントが定期的にリクエストを再送する擬似的手法です。サーバが自由に送信する真の双方向通信に比べオーバーヘッドが大きく、リアルタイム性も劣ります。
A: ロングポーリングはクライアントが定期的にリクエストを再送する擬似的手法です。サーバが自由に送信する真の双方向通信に比べオーバーヘッドが大きく、リアルタイム性も劣ります。
Q: HTTP/2のServer Pushでは解決できないのですか？
A: HTTP/2のServer Pushは主にリソース先送りが目的で、任意タイミングで任意データを双方向に送り合うチャット用途には適しません。
A: HTTP/2のServer Pushは主にリソース先送りが目的で、任意タイミングで任意データを双方向に送り合うチャット用途には適しません。
Q: WebSocketを採用すると既存HTTPポート（80, 443）をそのまま使えるのですか？
A: はい。初回は通常のGETで始まり、「Upgrade: websocket」により同一ポート上でプロトコルを切り替えます。既存ファイアウォール設定をほとんど変更せず利用できます。
A: はい。初回は通常のGETで始まり、「Upgrade: websocket」により同一ポート上でプロトコルを切り替えます。既存ファイアウォール設定をほとんど変更せず利用できます。
関連キーワード: HTTP, WebSocket, サーバプッシュ, 双方向通信, TCPコネクション
設問2：〔チャット機能の実装方式の検討〕について、(1)、(2)に答えよ。
問題文を見る（2）本文中の下線③について、FWやルータへの設定変更を少なくできるのはなぜか、WebSocketとHTTPの共通点に着目して、20字以内で述べよ。
模範解答
同じポートを利用するから
解説
解答の論理構成
- 目的
下線③では「販売代理会社のFWやルータの設定変更を少なくできる」理由を問われています。 - WebSocketとHTTPの関係
本文に「WebSocketを利用すると、PCとAPサーバの間のHTTPを用いた通信を拡張し、任意フォーマットのデータの双方向通信ができる。」とあります。すなわちWebSocketはHTTPを“拡張”して利用します。 - 接続確立方法
WebSocketは「PCからAPサーバにHTTPと同様のGETメソッドを送信」し、ヘッダに“Upgrade: websocket”“Connection: Upgrade”を付与してHTTPからプロトコルを切り替えます。 - ポート番号が変わらない
HTTPの標準ポートは80、HTTP Over TLSの標準ポートは443です。WebSocketもws:// は80、wss:// は443をそのまま使用します。 - 結論
既にFWやルータで許可されている80／443をそのまま流用できるため、新たなポート開放が不要で設定変更が最小限に抑えられます。
→ 解答：「同じポートを利用するから」
誤りやすいポイント
- WebSocket専用のポート（例：8080など）を開ける必要があると誤解する。
- WebSocket＝新しいプロトコルなのでHTTPとは別物と決めつけ、HTTPハンドシェイクを見落とす。
- wss:// の443利用を忘れ、TLS化すると別ポートが必要と考えてしまう。
FAQ
Q: WebSocketは必ず80／443でしか動きませんか？
A: 任意ポートでも動作しますが、既存機器設定を変えずに済むよう標準ポートを使うのが一般的です。
A: 任意ポートでも動作しますが、既存機器設定を変えずに済むよう標準ポートを使うのが一般的です。
Q: HTTPとWebSocketの違いは何ですか？
A: HTTPはリクエスト／レスポンス型、WebSocketはUpgrade後に同一TCPコネクションで双方向通信ができます。
A: HTTPはリクエスト／レスポンス型、WebSocketはUpgrade後に同一TCPコネクションで双方向通信ができます。
Q: wss:// を採用すると何が変わりますか？
A: HTTP Over TLSと同じく暗号化され、ポート番号443を利用できるためプロキシの「PCから受信したデータをそのまま送信する機能」を活用できます。
A: HTTP Over TLSと同じく暗号化され、ポート番号443を利用できるためプロキシの「PCから受信したデータをそのまま送信する機能」を活用できます。
関連キーワード: WebSocket, HTTP, TCPポート, TLS, Firewall
設問3：〔チャット機能の設計レビュー〕について、(1)、(2)に答えよ。
問題文を見る（1）本文中の下線④について、どのような負荷分散方式に変更したか、20字以内で答えよ。
模範解答
DNSラウンドロビン方式
解説
解答の導き方
- まず問題文の指摘内容を確認します。G課長の指摘1に「WebSocketはTCPコネクションを確立したままにするので、負荷分散装置を経由してチャット機能へアクセスすると、旅行販売システムの既存機能へのアクセスに影響がある。」とあります。WebSocketは長時間のTCP接続を維持するため、経路上でコネクションの状態を持つ装置に負担や影響を与えやすい点が問題です。
- F君の対応として「チャット機能では負荷分散装置を使わないことにし、E社データセンタ内にある機器を利用したほかの負荷分散方式に変更した。」とあり、データセンタ内の別の仕組みで負荷分散することが求められています。
- 本文はまた「DNSサーバのAレコードには、旅行販売システムのIPアドレスとして a が登録されている。」と述べており、データセンタ側にDNSで名前解決を制御できることを示しています（図1にはDNSサーバ 10.10.0.2とAPサーバ#1 10.10.0.11、APサーバ#2 10.10.0.12が記載されています）。
- これらを組み合わせると、データセンタのDNSを用いて名前解決時に複数のAレコードを返すことで、新規接続をAPサーバ群に振り分けでき、TCP接続の維持（WebSocketのコネクション）は各APサーバと直接の間で行われます。つまり、経路上でコネクション状態を長時間保持する専用の負荷分散装置に依存しない方式が適合します。
- 上記の方式は一般にDNSラウンドロビン方式と呼ばれるため、空欄④の答えは
DNSラウンドロビン方式
です。
誤りやすいポイント
- 「負荷分散装置を使わない＝負荷分散を止める」と誤解する。本文は「ほかの負荷分散方式へ変更する」とあるため、別の分散手段を選ぶ必要があります。
- L7型や既存のロードバランサを単に置き換えると、WebSocketの長時間接続により同様の問題（接続状態の保持による影響）が残る場合があると見落とす。
- 図1にDNSサーバや複数のAPサーバが存在する事実を見落とし、DNSを使った方式に気づかない。
- DNSラウンドロビンの欠点（ヘルスチェック非対応、クライアント側キャッシュやTTLによる偏り）がある点を無視すると運用上の問題を招く。
FAQ
Q: なぜDNSで振り分けると問題が解消するのですか？
A: DNSで複数のAレコードを返すと、クライアントの名前解決で接続先が分散されます。TCPコネクションはクライアントと各APサーバ間で直接確立されるため、経路上の負荷分散装置に長時間のコネクション状態を任せる必要がなくなり、G課長の懸念を回避できます。
A: DNSで複数のAレコードを返すと、クライアントの名前解決で接続先が分散されます。TCPコネクションはクライアントと各APサーバ間で直接確立されるため、経路上の負荷分散装置に長時間のコネクション状態を任せる必要がなくなり、G課長の懸念を回避できます。
Q: DNSラウンドロビンの欠点は何ですか？
A: 主な欠点はサーバ障害時の自動除外が標準では行われないこと、クライアントのDNSキャッシュやTTLで負荷分散が偏ることです。運用では短いTTLや外部のヘルスチェック機構を併用する等の対策が必要です。
A: 主な欠点はサーバ障害時の自動除外が標準では行われないこと、クライアントのDNSキャッシュやTTLで負荷分散が偏ることです。運用では短いTTLや外部のヘルスチェック機構を併用する等の対策が必要です。
Q: 欠点が許容できない場合の代替は？
A: WebSocketに対応したL4/L7ロードバランサでセッションアフィニティ（スティッキー）やヘルスチェックを使う方法や、プロキシ層と組み合わせた専用の接続管理方式などが考えられます。ただしこれらは「負荷分散装置を使わない」という要件との整合を確認する必要があります。
A: WebSocketに対応したL4/L7ロードバランサでセッションアフィニティ（スティッキー）やヘルスチェックを使う方法や、プロキシ層と組み合わせた専用の接続管理方式などが考えられます。ただしこれらは「負荷分散装置を使わない」という要件との整合を確認する必要があります。
関連キーワード: DNSラウンドロビン、Aレコード、WebSocket、TCPコネクション維持、負荷分散
設問3：〔チャット機能の設計レビュー〕について、(1)、(2)に答えよ。
問題文を見る（2）本文中のdに入れる適切な機器名を、図1中の字句を用いて全て答えよ。
模範解答
d：APサーバ#1, APサーバ#2
解説
解答の論理構成
- まず設問の直前で、TLS証明書をどこに置くかという場面設定が提示されています。
引用：「そこで、F君はTLS証明書を d にインストールし、チャット機能の通信をHTTP Over TLSに対応させた。」 - TLS（HTTPS／WebSocket Over TLS）では暗号化通信を終端する機器が証明書を保持します。既存の負荷分散装置は「指摘1」で排除されています。
引用：「WebSocketはTCPコネクションを確立したままにするので、負荷分散装置を経由してチャット機能へアクセスすると、旅行販売システムの既存機能へのアクセスに影響がある。」
引用：「チャット機能では負荷分散装置を使わないことにし、E社データセンタ内にある機器を利用したほかの負荷分散方式に変更した。」 - 負荷分散装置を通さない以上、販売店側から直接アクセスを受けるのはAPサーバ自身です。図1に載る該当機器は「APサーバ#1」「APサーバ#2」の2台のみです。
引用（図1）：
・「APサーバ#1 10.10.0.11」
・「APサーバ#2 10.10.0.12」 - 以上より、暗号化通信を終端しWebSocket Over TLSを提供するために証明書を格納すべき [d] は「APサーバ#1, APサーバ#2」となります。
誤りやすいポイント
- 「証明書は公開IPを持つ最前段に置く」と考え、排除済みの「負荷分散装置」を選んでしまう。
- 「TLS終端＝通信を中継するプロキシ／ルータ」と早合点し、「代理会社接続ルータ」や「FW#1」を選択してしまう。
- 「2台のAPサーバどちらか1台だけ」と記載し、複数台構成であることを見落とす。
FAQ
Q: 負荷分散装置を外すと、APサーバが直接インターネットにさらされて危険では？
A: 本文では「E社データセンタ内にある機器を利用したほかの負荷分散方式」へ変更しています。DNSでのラウンドロビンなどL4/L3レベルの分散に切り替えた可能性があり、APサーバは引き続きFW#1の内側で保護されています。
A: 本文では「E社データセンタ内にある機器を利用したほかの負荷分散方式」へ変更しています。DNSでのラウンドロビンなどL4/L3レベルの分散に切り替えた可能性があり、APサーバは引き続きFW#1の内側で保護されています。
Q: なぜプロキシサーバ経由にするとTLSが必須なのですか？
A: 本文にあるとおり、プロキシサーバはHTTP Over TLSの場合「PCから受信したデータをそのまま送信」します。平文HTTPのままではプロキシが中身を解析してしまいWebSocketの長時間接続が維持できません。TLSで暗号化すればプロキシはパケットを透過的に転送できます。
A: 本文にあるとおり、プロキシサーバはHTTP Over TLSの場合「PCから受信したデータをそのまま送信」します。平文HTTPのままではプロキシが中身を解析してしまいWebSocketの長時間接続が維持できません。TLSで暗号化すればプロキシはパケットを透過的に転送できます。
Q: APサーバに証明書を2枚インストールするのですか？
A: 同一ドメイン名であれば共通証明書をコピーして両サーバに配置します。個別の名前で運用する場合はそれぞれのFQDN用証明書を用意しますが、本問ではサーバ役割が同一なので共通証明書で問題ありません。
A: 同一ドメイン名であれば共通証明書をコピーして両サーバに配置します。個別の名前で運用する場合はそれぞれのFQDN用証明書を用意しますが、本問ではサーバ役割が同一なので共通証明書で問題ありません。
関連キーワード: WebSocket, TLS証明書, 負荷分散, HTTP Over TLS, TCPコネクション
