令和3年春期試験午後問題 問5

問5 ネットワーク

⇱問題PDF
チャット機能の開発に関する次の記述を読んで,設問1~3に答えよ。
 E社は,旅行商品の企画,運営,販売を行う旅行会社である。E社の旅行商品は,自社の販売店と販売代理会社の販売店を通じて販売している。販売店に顧客が来ると,販売スタッフがE社の旅行販売システムを利用して,顧客の要望に合う旅行商品を検索し,顧客に提案している。また,顧客からの旅行商品に関する質問の回答が分からない場合,E社の販売店向けコールセンタに電話で問い合わせることになっているが,販売店からは"コールセンタに電話が繋がらない"などの苦情が出ている。
 そこでE社は,販売店とコールセンタのスタッフがテキストメッセージで相互にやり取りできるチャット機能を,旅行販売システムに追加することにした。チャット機能の開発は,E社システム部門のF君が担当することになった。

〔ネットワーク構成の調査〕
 F君は,チャット機能を開発するに当たり,現在のネットワーク構成を調査した。図1にF君が調査したネットワーク構成(抜粋)を示す。
pm05_1.gif
 旅行販売システムは,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を利用した通信(抜粋)を示す。
pm05_2.gif
 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)に答えよ。
  • 本文中のacに入れる適切なIPアドレスを図1中の字句を用いて答えよ。
  • E社販売店のPC及び販売代理会社の販売店のPCが旅行販売システムにアクセスするためには,どの機器のDNS設定にE社のDNSサーバのIPアドレスを設定する必要があるか,解答群の中から全て選び,記号で答えよ。
  • 本文中の下線①について,プロキシサーバがPCから送信されたデータをそのまま送信するのはなぜか,30字以内で述べよ。
解答群
  • E社販売店のPC
  • FW#1
  • FW#2
  • FW#3
  • FW#4
  • 店舗接続ルータ
  • 販売代理会社の販売店のPC
  • 負荷分散装置
  • プロキシサーバ

解答例・解答の要点

  • a:10.10.0.10
    b:192.168.0.3
    c:10.1.1.2
  • ア,ケ
  • プロキシサーバはGETメソッドの内容が見えないから (25文字)

解説

  • aについて〕
    旅行販売システムは、負荷分散装置を利用して2台のAPサーバに処理を振り分けることで負荷分散を行う構成になっています。この構成では、APサーバの前段に配置された負荷分散装置がクライアントからの要求を一元的に受け取り、各種情報や負荷分散ポリシーを基に適切なAPサーバに要求を振り分けます。クライアントからの全ての要求を負荷分散装置に集めたいのですから、DNSサーバのAレコード(ドメイン名に対応するIPアドレスを指定するレコード)に登録するIPアドレスは、負荷分散装置のIPアドレスである「10.10.0.10」にする必要があります。

    a=10.10.0.10

    bについて〕
    販売代理会社の販売店のPCから旅行販売システムへアクセスする場合、プロキシサーバを経由することになります。プロキシサーバを経由するWebアクセスでは、クライアントはプロキシサーバに対してHTTP(S)リクエストを送り、プロキシサーバはクライアントから受け取ったHTTP(S)リクエストの内容(GETメソッドのURL)を使って外部の宛先サーバに代理アクセスします。
    pm05_3.gif
    IPはエンドツーエンドの通信を実現するプロトコルなので、宛先IPアドレスには最終的にパケットを届けたい相手を指定します。最終的な宛先というと"旅行販売システム"や"負荷分散装置"のIPアドレスを考えてしまいますが、プロキシサーバを経由する場合は、パケットを届けたい相手がプロキシサーバになるので、宛先IPアドレスにはプロキシサーバのIPアドレスを指定します。経路途中の"FW#4"や"店舗接続ルータ"は最終的な宛先ではないので、宛先IPアドレスとするのは不適切です。

    したがって、販売代理会社の販売店のPCがWebアクセスする際の宛先IPアドレスは、プロキシサーバの販売店側のIPアドレスである「192.168.0.3」になります。

    b=192.168.0.3

    cについて〕
    前述のとおり、販売代理会社の販売店のPCからHTTP(S)リクエストを受け取ったプロキシサーバは、旅行販売システムに代理アクセスをします。このときプロキシサーバから送出されるIPパケットは、宛先IPアドレスが 10.10.0.10、送信元IPアドレスが 192.168.0.2 になっています。

    プロキシサーバが旅行販売システムにアクセスする際には"FW#3"を経由しますが、"FW#3"ではNAPTが動作しています。NAPTでは、送信元IPアドレスについてプライベートIPアドレスとグローバルIPアドレスの変換を行うので、"FW#3"を経由する際に、送信元IPアドレスが"FW#3"の外部側のIPアドレスである「10.1.1.2」に書き換えられます。"代理会社接続ルータ"に届くのはこの書き換えられたIPパケットなので、"代理会社接続ルータ"から"FW#1"に送信されるIPパケットの送信元IPアドレスは「10.1.1.2」になっています。

    c=10.1.1.2

  • 本問では販売店側ネットワークにDNSサーバが配置されていないので、販売店側ネットワークにおいてドメイン名で旅行販売システムにアクセスする機器に、E社のDNSサーバのIPアドレスを設定する必要があります。旅行販売システムの機器と通信する際にIPアドレスが必要になるからです。旅行販売システムにアクセスする、E社販売店のPCと販売代理会社のプロキシサーバがこれに該当します。

    ∴ア,ケ

  • HTTPS通信ではHTTPリクエストの内容がTLSによって暗号化され、復号は受信者である機器(本問だと負荷分散装置)しか行えません。プロキシサーバは、HTTPリクエストのGETメソッドを参照して代理アクセスのリクエストを組み立てますが、暗号化されているのでGETメソッドの内容を見ることができません。

    このためHTTPSでプロキシサーバを利用する場合には「CONNECT」という特殊なメソッドを使って、クライアントはプロキシサーバにTCPコネクションをトンネルするように依頼します。依頼を受けたプロキシサーバは、宛先サーバとのTCPコネクションを確立し、暗号化されたHTTPリクエストをそのまま受け渡します。宛先サーバから返ってくる結果も暗号化されているので、プロキシサーバはそのままクライアントに返します。本文中で、PCから受信したデータをそのまま送信するというのは、この一連の動作を指しています。

    ∴プロキシサーバはGETメソッドの内容が見えないから

設問2

〔チャット機能の実装方式の検討〕について,(1),(2)に答えよ。
  • 本文中の下線②について,チャット機能をHTTPで実装するのはなぜ困難か,解答群の中から選び,記号で答えよ。
  • 本文中の下線③について,FWやルータへの設定変更を少なくできるのはなぜか,WebSocketとHTTPの共通点に着目して,20字以内で述べよ。
解答群
  • PCはAPサーバ上のファイルを取得することしかできないから
  • PCへのメッセージ送信はAPサーバ側で発生したイベントを契機として行うことができないから
  • TCPコネクションを確立したままにできないから
  • どのPCから送られたメッセージか,APサーバが判別できないから

解答例・解答の要点


  • 同じポートを利用するから (12文字)

解説

  • HTTPは、クライアントがリクエストを送信し、リクエストを受け取ったサーバがレスポンスを返すというシンプルな通信手順です。サーバはクライアントからのリクエストに対してデータを返すことはできますが、任意のタイミングでクライアントに対してデータを送ることができません。このため、サーバ側からもメッセージを送信するチャット機能をHTTPで実現することは困難となります。

    したがって「イ」が適切な理由となります。
    • HTTPで取得できるのはファイルに限られません。インターネット上の任意のデータを取得することができます。
    • 正しい。HTTPは常にクライアントから通信を開始する性質があるので、サーバからもメッセージを送るチャット機能の実現は困難です。
    • HTTPレスポンスにKeep-Aliveヘッダを含めることで、TCPコネクションを維持することができます。
    • クッキーやセッションIDを使えばPCを区別することができます。
    ※WebSocketの登場前にもチャット機能はありましたが、10秒間隔などで定期的にHTTPリクエストを送って、サーバは更新があったら結果を返すというポーリング方式等によって半ば強引にリアルタイム性を実現していました。しかし、遅延があり、無駄な通信が生じるため効率は良くありませんでした。

  • 販売代理会社の"FW#3"では「宛先ポートが53番ポート,80番ポート又は443番ポートで宛先ネットワークアドレスが 10.10.0.0 のIPパケットとその返信IPパケットだけを通信許可する設定となっている」ように、IRC(194/TCP)や新たなプロトコルを利用する場合には、そのポートを使った通信を許可するようにFWやルータの設定を変更する必要があります。E社データセンタの"FW#1"、E社販売店の"FW#2"も同様です。別会社も含めたすべての拠点のFW設定を変えるのは大変でしょう。
    この点、WebSocketはHTTP通信を拡張したものなので、使用するポートがHTTPと同じです。このため、他のプロトコルを利用する場合と比較してFWやルータの設定変更が少なくて済みます。

    ∴同じポートを利用するから

設問3

〔チャット機能の設計レビュー〕について,(1),(2)に答えよ。
  • 本文中の下線④について,どのような負荷分散方式に変更したか,20字以内で答えよ。
  • 本文中のdに入れる適切な機器名を,図1中の字句を用いて全て答えよ。

解答例・解答の要点

  • DNSラウンドロビン方式 (12文字)
  • d:APサーバ#1,APサーバ#2

解説

  • 負荷分散装置を利用せずに、E社データ内にある機器を利用した負荷分散という条件があるので、DNSサーバの機能を使用した「DNSラウンドロビン」が当てはまります。DNSラウンドロビンは、以下のように同じホスト名に対して複数のAレコードを設定することで、アクセスを複数のコンピュータに(単純に順繰りに)振り分けます。負荷分散装置とは異なり単純な振分けしかできませんが、ある程度の負荷分散効果が望めます。
    chat IN A 10.10.0.11
    chat IN A 10.10.0.12
    ∴DNSラウンドロビン方式

  • DNSラウンドロビンは、2台のAPサーバについて設定することになります。これまで旅行販売システムへのアクセスは負荷分散装置に集めていたので、TLS証明書は負荷分散装置だけにインストールしておけば良かったのですが、チャット機能ではHTTPS通信の接続先が2台のAPサーバになります。HTTPS通信を行うには、少なくとも接続先のサーバにTLS証明書(サーバ証明書)をインストールしなければならないので、HTTPSでチャット機能の通信を行うためには、新たに2台のAPサーバにもTLS証明書をインストールする必要があります。

    ∴APサーバ#1,APサーバ#2
解答に当たり関係はありませんが、〔チャット機能設計レビュー〕の2つの指摘について補足しておきます。
指摘1は、WebSocketではTCPコネクションを確立したままにするので、チャット機能の利用が多くなると負荷分散装置の同時接続数が一杯になり、旅行販売システムの既存機能へのアクセスができなくなってしまうという問題です。
指摘2は、WebSocketは比較的新しいプロトコルなので、対応していないプロキシサーバにおいてupgradeヘッダを含むパケットが破棄されてしまい、プロキシサーバ越えができないという問題です。
模範解答

Pagetop