PR

【応用情報】令和3年度 春季試験 問5:ネットワーク【YouTube解説動画あり】

応用情報技術者
スポンサーリンク

応用情報技術者試験の令和3年度 春季試験 問5:ネットワークについて解説を行っていきます。

出題テーマ:チャット機能開発

出題テーマとしては『チャット機能開発』ですが、出題されている内容としては、『DNS』・『負荷分散装置』・『プロキシサーバ』・『HTTP/HTTPS』・『WebSocket』が出題されています。

それぞれの内容に関して知識がないと解答することが難しく、浅く広くではありますが、幅広い知識が求められますので難易度が高い問題であったと思います。

問5:ネットワークは必須問題ではないので、この出題内容であれば避けるべき問題だったと思います。

設問1 (1)

【a】について考えていきます。

旅行販売システムは、2台のAPサーバと負荷分散装置から構成されている。』とあります。

負荷分散装置はサーバが複数台ある場合に負荷を任意の割合に分散させる装置です。

呼び方は色々とありますがロードバランサー、LB、L7スイッチとも呼ばれる機器です。

通常クライアントはサーバ宛に通信を行いますが、負荷分散装置を利用する場合、クライアントは負荷分散装置宛に通信を行います。

負荷分散装置に到着した通信は設定内容に基づいて各サーバへ振り分けられます。

次に、DNSについて確認していきます。

DNS:Domain Name Systemの略称で、ドメインに対応するIPアドレスを管理する仕組みのことです。

Webサイトやサービスにアクセスする際は、PCのブラウザなどにURLを入力します。

PCはURLの状態ですと通信することができず、宛先IPアドレスがないと通信することができません。

そこでPCはDNSサーバへURLに含まれるドメイン部分に対応するIPアドレスを聞き、IPアドレスを知ることで宛先に対して通信することができるようになります。

問題文中に『DNSサーバのAレコードには、旅行販売システムのIPアドレスとして【a】が登録されている。』とあります。

AレコードとはDNSサーバに設定するドメイン名やホスト名に対応するIPv4アドレスのことです。

まとめると、クライアントからの通信を負荷分散装置宛に行わせるようにしたいので、DNSのAレコードを負荷分散装置のIPアドレスにします。

こうすることにより、DNS問い合わせに対して負荷分散装置のIPアドレスが返答されますので、クライアントは負荷分散装置宛に通信を行うようになります。

よって、【a】には負荷分散装置のIPアドレスである『10.10.0.10』が入ると解答することができます。

なお、DNSに関してはこの年の応用情報の問1:セキュリティでも出題されました。

詳細はこちらで解説を行っていますので、詳しく知りたいというか方は是非ご覧ください。

次に【b】について考えていきましょう。

文章中に『販売代理会社の販売店のPCから旅行販売システムへの通信はFW、ルータ、プロキシサーバを経由している。』と記載があります。

つまり、販売店代理会社の販売店のPCはプロキシサーバを利用していると考えることができます。

そして、プロキシサーバを利用する場合は通信フローに違いがあります。

プロキシサーバを利用しない場合、PCからの通信におけるIPアドレスはサーバ(今回の問題では負荷分散装置)となります。

プロキシサーバを用いる場合、PCからの通信における宛先IPアドレスはプロキシサーバとなります。

よって、【b】にはプロキシサーバのIPアドレスである『192.168.0.3』が入ると解答することができます。

プロキシサーバを利用しない・する場合の通信フローについては別記事にて詳しく紹介していますので、気になる方は是非ご確認ください。

プロキシサーバを利用しない場合のHTTP/HTTPSの通信フロー

プロキシサーバを利用する場合のHTTP/HTTPSの通信フロー

最後に【c】について考えていきます。

FW#3では、NAPTを行い』と記載があります。

NAPTとは送信元IPアドレスと送信元ポート番号を変換する機能です。

よって、【c】に入るべきはFW#3の広域イーサーネット側のIPアドレスである『10.1.1.2』と解答することができます。

設問1 (2)

E社販売店のPCと販売代理会社の販売店のPCとでは、旅行販売システムにアクセスする方法に決定的な違いがあります。

E社販売店のPCはそのまま旅行販売システムにアクセスを行いますが、先程の設問1(1)の【b】で扱いましたが販売代理会社の販売店のPCはプロキシサーバ経由で旅行販売システムへアクセスを行っています。

プロキシサーバを使用しない場合とプロキシを使用する場合には、DNSを問い合わせる機器も異なります。

プロキシサーバを利用しない場合は、PCからDNSの問い合わせを行います。

一方で、プロキシサーバを利用する場合は、PCからではなくプロキシサーバからDNSの問い合わせを行います。

E社販売店のPCはプロキシサーバを用いず、PCがDNSの問い合わせを行いますので、『ア:E社販売店のPC』に設定を行う必要があります。

販売代理会社の販売店のPCはプロキシサーバを経由して、旅行販売システムにアクセスしています。

この場合はプロキシサーバがDNSの問い合わせを行いますので、『ケ:プロキシサーバ』に設定を行う必要があります。

よって解答は『ア:E社販売店のPC、ケ:プロキシサーバ』と解答することができます。

設問1 (3)

HTTP over TLSを利用する場合は、プロキシサーバは旅行販売システムの機器とTCPコネクションを確立し、PCから受信したデータをそのまま送信する』と記載があります。

『HTTP over TLS』とはHTTPSのことを指します。

HTTPSでプロキシサーバを利用する場合の通信フローについて見ていきましょう。

まずはクライアントとプロキシサーバ間、プロキシサーバとサーバ間でそれぞれ3way Handshakeを確立します。

説明が細かくなってしまいますので、簡略化して記載していますが、クライアントとサーバ間でどのような暗号方式で暗号を行うかをやりとりし、暗号方式が決まると以降の通信では暗号化が行われます。

暗号化が行われた後にクライアントがアクセスしたい宛先へGETリクエストが行われます。

このようにクライアントとサーバ間では暗号方式決めから暗号化して通信を行いますが、その際プロキシサーバはただ通信を中継することのみを行います。

というのも暗号化はクライアントとサーバ間で行われますので、通信内容を確認できるのはクライアントとサーバのみとなり、プロキシサーバは通信内容を確認することができないためとなります。

なので解答例としては『暗号化されたクライアントからの通信を確認できないため(26文字)』と解答することができます。

設問2 (1)

チャット機能を実装する場合、旅行販売システムで利用しているHTTPでは実装が困難である。』と記載があります。

HTTP/HTTPSは基本的にクライアントからの通信に対して、サーバがレスポンスを返すという流れで通信が行われます。

なので、サーバからクライアントに対して通信を発信するということは基本的には行なえません。

つまり、こちらからチャットを送信することはできても、相手へはチャットの通知が行われません。

当然相手から返信があった場合もこちらへは通知されず、自分で更新ボタンを押すなどしないと表示されないという非常に不便なものとなってしまいます。

こちらの対策として用いられるのがWebSocketです。

WebSocketを用いることで、常にセッションを確立している状態になり、チャットの返信があった場合でもサーバから通信を行うことができます。

ということで、解答としては『イ:PCへのメッセージ送信はAPサーバ側で発生したイベントを契機として行うことができないから』と解答することができます。

設問2 (2)

図2の通信フローでGETリクエストなどが行われていることからもわかりますが、WebSocketはあくまでHTTP形式で通信が行われます。

通信経路上にはFWがあり、ここではどの通信を許可する・拒否するなどがルールが定義されている状態です。

FWで、許可・拒否する通信を5タプル(5tuple)で設定します。

5タプル

  1. 送信元IPアドレス
  2. 送信元ポート番号
  3. 宛先IPアドレス
  4. 宛先ポート番号
  5. プロトコル番号

の5つの要素のことを指します。

これまでも各PCへのから旅行販売システムへの通信はHTTPで行われていました。

HTTPはTCP:80を用い、WebSocketもHTTP形式を用いることから同様にTCP:80を用います。

つまり、FW上にはHTTP(TCP:80)のルールがすでに設定されていますので、新たにルールを追加しなくてもよいので設定変更を少なくできるとなります。

よって解答例としては、『同じポート番号を使用するため(14文字)』と解答することができます。

設問3 (1)

指摘事項にTCPコネクションを張ったままにすることに問題があるとの記載があります。

負荷分散装置における負荷分散方法にはいくつか方法があります。

負荷分散装置には様々な分散方法がありますが、多く用いられているのがコネクション数に応じて振り分け先を変えるという分散方法です。

コネクション数が多いサーバとコネクション数が少ないサーバがあれば、新たにきた通信はコネクション数の少ない方のサーバへ振り分けをします。

今回の場合、WebSocketを用いるチャット機能では記載があるようにコネクションを確立したままにします。

従来の旅行販売システムとチャット機能それぞれHTTPを使用しますので、チャット機能がコネクションを確立したままにすることで、どちらかのサーバにはチャット機能が集中したりするというアクセス先に偏りが生じることが予想されます。

適切に振り分けが行われない場合は、どちらかのサーバの負荷が高まってしまうということにつながってしまいます。

では、TCPコネクション数に依存しないような負荷分散を行えばよいのですが、どのように行えるか考えていきましょう。

E社販売店のPCおよび、販売代理会社の販売店のPCから旅行販売システム宛の通信経路上で共通しているのは『FW#1』、およびDNSの問い合わせを行う『DNSサーバ』です。

FWでは基本的に負荷分散を行うことができません。(※:現実としてはメーカーによっては行うことができるFW製品もあります。)

残ったDNSサーバで行える負荷分散は『DNSラウンドロビン方式』です。

『DNSラウンドロビン方式』は設問1 (1)で登場したDNSの『Aレコード』に2つ分散を行いたいサーバのIPアドレスを登録します。

そうするとDNSサーバは1回目の問い合わせには1つ目のサーバのIPアドレスを返答します。

2回目の問い合わせには2つ目のサーバのIPアドレスを返答します。

3回目の問い合わせには1つ目のサーバのIPアドレスを返答するというように順番に解答をしていきます。

この場合Aレコードに登録をするのは、『APサーバ#1』と『APサーバ#2』のIPアドレスとなりますので、DNSの返答を受けたPCはどちらかにアクセスしますのでTCPコネクションに依存せずに負荷分散が行われます。

よって解答としては『DNSラウンドロビン方式(12文字)』となります。

設問3 (2)

設問1 (3)でHTTPSの通信フローを簡易的にご紹介しましたが、TLS証明書を必ず提示する必要があるのはサーバ側です。

クライアント側も証明書を求められることはありますが、必ず必要というわけではありません。

よって、【d】に入れる機器名は『APサーバ#1』と『APサーバ#2』となります。

サーバは2つありますので、解答も2つになることに注意しましょう。

公式解答例との比較・予想配点

全体的に知識がないと解答することが難しかったと感じます。

問題にさらっと目を通して、知らない単語が並んでいるなと感じたら得意分野であっても避けた方がよいかと思います。

問題には登場していませんが、実際の案件でインターネットブレークアウトなどを採用する機会が増えているかと思いますので、『HTTP/HTTPS』と『プロキシサーバ』を抑えておくと実務にも役立つかなと思います。

設問
解答例
公式解答例
予想
配点
設問1 (1) 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
各2点
設問1 (2) ア、ケ ア、ケ 2点
設問1 (3) 暗号化されたクライアントからの通信を確認できないため(26文字) プロキシサーバはGETメソッドの内容が見えないから 3点
設問2 (1) 2点
設問2 (2) 同じポート番号を使用するため(14文字) 同じポートを利用するから 3点
設問3 (1) DNSラウンドロビン方式 DNSラウンドロビン方式 2点
設問3 (2) APサーバ#1、APサーバ#2 APサーバ#1、APサーバ#2 2点

引用元

問題および解答例に関しては、独立行政法人 情報処理推進機構(IPA)より引用しています。

YouTube解説動画

タイトルとURLをコピーしました