応用情報技術者 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)に答えよ。
(1)本文中のa~cに入れる適切なIPアドレスを図1中の字句を用いて答えよ。
模範解答
a:10.10.0.10
b:192.168.0.3
c:10.1.1.2
解説
解答の論理構成
-
【問題文】では「DNSサーバのAレコードには、旅行販売システムの IP アドレスとして a が登録されている。」とあります。図1で旅行販売システムの代表アドレス(負荷分散装置の仮想 IP)として示されているのは 「10.10.0.10」 です。利用者が名前解決したときに負荷分散装置へ到達させる必要があるため、A レコードにはこのアドレスが入ります。よって
a:10.10.0.10 -
「販売代理会社の販売店の PCから…PCから FW#4 に送信される IP パケットの宛先 IP アドレスは b となり」とあります。
- 本文には「販売代理会社の販売店の PCから旅行販売システムへの通信は…プロキシサーバを経由」と書かれています。
- PC はまずプロキシサーバへ HTTP/HTTP Over TLS のリクエストを送る設定ですから、PC が生成する最初の IP パケットの宛先はプロキシサーバのアドレスになります。
- 図1のプロキシサーバには 「192.168.0.1」「192.168.0.2」「192.168.0.3」「192.168.0.4」 が掲載されています。複数アドレスのうち、試験では 「192.168.0.3」 を指定させています。
よって
b:192.168.0.3
-
「代理会社接続ルータから FW#1 に送信される IP パケットの送信元 IP アドレスは c となる。」
- PC → プロキシサーバ → FW#3 → 代理会社接続ルータ → FW#1 という経路上で、FW#3 には「NAPT を行い…」という説明があります。
- NAPT では内部から外部へ出るパケットの送信元 IP を FW#3 の外部側アドレスに変換します。図1で FW#3 の外部(10.1.1.0/24)側アドレスは 「10.1.1.2」 です。
よって
c:10.1.1.2
誤りやすいポイント
- A レコード=公開用アドレスと理解し、AP サーバ個別の「10.10.0.11」「10.10.0.12」を書いてしまう。DNS は負荷分散装置の VIP を返すのが一般的です。
- 「PC は直接 AP サーバへアクセスする」と思い込み、[b] に「10.10.0.10」を書くミス。本文に“プロキシサーバを経由”と明言されています。
- [c] でプロキシサーバのアドレスや 192.168 系を答えるミス。NAPT 後の送信元は FW#3 の外部側アドレスになる点に注意が必要です。
FAQ
Q: なぜプロキシサーバのアドレスが複数あるのですか?
A: 負荷分散や冗長化、もしくはネットワーク分離のために仮想 IP を複数持たせるケースがあります。本問ではその中の「192.168.0.3」を販売店 PC が利用している想定です。
A: 負荷分散や冗長化、もしくはネットワーク分離のために仮想 IP を複数持たせるケースがあります。本問ではその中の「192.168.0.3」を販売店 PC が利用している想定です。
Q: NAPT と NAT の違いは何ですか?
A: NAT がアドレスだけを変換するのに対し、NAPT はアドレスとポート番号をセットで変換します。多数の内部端末が 1 つの外部アドレスで同時通信できる点が特徴です。
A: NAT がアドレスだけを変換するのに対し、NAPT はアドレスとポート番号をセットで変換します。多数の内部端末が 1 つの外部アドレスで同時通信できる点が特徴です。
Q: DNS の A レコードを AP サーバ#1 と #2 の両方に登録してはいけませんか?
A: 可能ですが、本システムでは専用の負荷分散装置を用意しているため、A レコードは装置の仮想 IP(10.10.0.10)に統一する設計になっています。
A: 可能ですが、本システムでは専用の負荷分散装置を用意しているため、A レコードは装置の仮想 IP(10.10.0.10)に統一する設計になっています。
関連キーワード: DNS, NAPT, プロキシサーバ, 負荷分散装置, GETメソッド
設問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ラウンドロビン方式
解説
解答の論理構成
-
現状確認
本文には「旅行販売システムは、2台のAPサーバと負荷分散装置から構成されている」とあります。既存機能は負荷分散装置が前提です。 -
問題点の把握
指摘1として「WebSocketはTCPコネクションを確立したままにするので、負荷分散装置を経由してチャット機能へアクセスすると、旅行販売システムの既存機能へのアクセスに影響がある」と記載されています。長時間張り付いたコネクションが負荷分散装置のセッション表を圧迫し、既存トラフィックに悪影響を及ぼす恐れがあるためです。 -
方針転換
そこで本文は「チャット機能では負荷分散装置を使わないことにし、E社データセンタ内にある機器を利用した④ほかの負荷分散方式へ変更した」と述べています。負荷分散装置以外でデータセンタ内に存在する機器は「DNSサーバ」です。 -
DNSを用いる負荷分散
DNSサーバで同一ホスト名に複数の IP アドレスを登録して応答させれば、名前解決の段階で接続先が分散します。これは一般に「DNSラウンドロビン方式」と呼ばれる負荷分散手法です。 -
結論
以上より、④に当てはまる方式は
「DNSラウンドロビン方式」
誤りやすいポイント
- 負荷分散装置を外す=「ロードバランサ無し」と早合点し、答えを書かずに終わるケース
- 「ソースIPハッシュ」「リバースプロキシ」などアプリ層での分散と混同するケース
- DNSサーバを使う事実は示唆されているが、用語として「DNSラウンドロビン」が想起できないケース
FAQ
Q: なぜWebSocketでは既存の負荷分散装置が問題になるのですか?
A: WebSocketは接続確立後も長時間同じTCPコネクションを維持します。負荷分散装置は多数のセッションを記憶し続ける必要があり、既存HTTPよりセッション数が増加して装置のリソースを専有する恐れがあります。
A: WebSocketは接続確立後も長時間同じTCPコネクションを維持します。負荷分散装置は多数のセッションを記憶し続ける必要があり、既存HTTPよりセッション数が増加して装置のリソースを専有する恐れがあります。
Q: DNSラウンドロビン方式にするとセッション維持はどうなりますか?
A: 接続先は名前解決時に決まるため、1回の名前解決後はAPサーバへ直接接続し続けます。途中で別サーバへ切り替わることはなく、WebSocketの長時間接続と相性が良好です。
A: 接続先は名前解決時に決まるため、1回の名前解決後はAPサーバへ直接接続し続けます。途中で別サーバへ切り替わることはなく、WebSocketの長時間接続と相性が良好です。
Q: DNSラウンドロビンの欠点はありませんか?
A: クライアント側キャッシュの影響で負荷が完全に均等化されない、サーバ障害時に死活監視と連動して自動除外できないといった課題があります。監視とTTL調整が重要です。
A: クライアント側キャッシュの影響で負荷が完全に均等化されない、サーバ障害時に死活監視と連動して自動除外できないといった課題があります。監視とTTL調整が重要です。
関連キーワード: WebSocket, DNSラウンドロビン, TCPコネクション, 負荷分散, Aレコード
設問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コネクション


