問1 ネットワーク基盤の拡張
ネットワーク基盤の拡張に関する次の記述を読んで，設問1〜4に答えよ。
K 社は，様々な用途の空調設備（以下，設備という）を製造し，保守サービスにも力を入れている。全国の保守センタに配備された保守員が，顧客のオフィスや工場などを訪問して，設備の点検や修理を行っている。今後は，リモート保守などの新サービスを提供する予定である。
〔現在の保守システム〕
現在の保守システムの構成を図1に示す。
- 保守員は，保守端末を携帯して顧客へ出向き，設備の点検，修理を行う。
- 保守員は，無線 LAN を介して保守端末から設備に，HTTP を使ったアクセスを行うことができ，設備の稼働情報を参照したり，設備を操作したりする。
- K 社データセンタには，2 台の Web サーバと 2 台の業務サーバが設置され，両サーバによって保守情報が管理されている。
- 必要に応じて，保守員は保守センタの PC 又は保守端末から Web サーバへアクセスし，保守情報を参照，更新する。アクセスを受けた Web サーバは，一部の処理を業務サーバに依頼する。
K 社データセンタ内のネットワーク構成を，図2に示す。
- リンクアグリゲーションで接続された 3 組の L2SW は，それぞれ単一の異なるセグメントを構成している。
- FW 及び LB は，Active-Standby 方式で冗長化されている。
- L2SW とサーバの接続は，サーバのチーミング機能によって冗長化されている。
- Web サーバと業務サーバのデフォルトゲートウェイは，LB である。
- Web サーバと業務サーバへのアクセスは，LB によって負荷分散されている。
- Web サーバと業務サーバへアクセスするための仮想 IP アドレスが，それぞれに定義されている。LB は，宛先の仮想 IP アドレスを実 IP アドレスに変換し，サーバへのアクセスを振り分ける。Web サーバから業務サーバへのアクセスについては，両サーバが同一セグメント内にあるので，［ あ ］ アドレスも変換する。
通常時のサーバへのアクセスに関するデータの流れを，図3に示す。
〔保守システムの機能強化〕
情報システム部では，新サービスの提供に当たり，保守システムの機能強化プロジェクトを予定している。機能強化では，新業務サーバを K 社データセンタに設置して，全設備の稼働情報を継続的に収集し，それを保守員が参照する。また，保守センタから設備の操作（設定変更，ファームウェア更新）を行ったり，設備の稼働情報（運転実績，維持温度）を参照したりする。ところが，図1に示すように，現在の保守システムでは，ネットワークを介して設備へアクセスすることができない。そこで，情報システム部では，2 種類のネットワーク機器（通信アダプタと中継装置）を導入し，設備へのネットワークアクセスを実現しようとしている。
機能強化に伴う導入機器の設置場所を図4に，機能強化後の通信の概要を図5に，それぞれ示す。
図5中の通信の概要は，次のとおりである。
- ① は，現在の通信であり，通信プロトコルには HTTP を用いている。同様に，新たに追加される ②〜④，④’，④” も HTTP を用いる。
- ② は，保守員が新業務サーバにある，設備の稼働情報を参照するときの通信である。
- ③ は，保守員が設備を操作するときの通信である。その際，保守員は最新の稼働情報を参照するので，④” の通信も発生する。
- ④ は，新業務サーバが設備の稼働情報を自動的に取得するときの通信である。収集周期は，サービス開始時は 1 時間とし，段階的に 5 分間程度に短縮しサービス品質を向上させる。また，設備はいつも通電されているとは限らないので，それを考慮した仕組み（以下，稼働情報取得案という）を用意する。
- ② の通信では，アクセスの際，新業務サーバ上の稼働情報を次の形式で指定する。
http://（新業務サーバの FQDN）/（稼働情報ファイル名）
- ③，④，④’，④” の通信では，アクセスの際，設備の中の稼働情報又は操作対象の機能（以下，リソースという）を，次の形式で指定する。
http://（設備を指定するための FQDN）/（リソース名）
情報システム部では，図5中の ④，④’，④” の通信に関して，通信アダプタと中継装置の HTTP キャッシュ機能を使った次のような稼働情報取得案を構想している。
- 中継装置と通信アダプタは，HTTP レスポンスに含まれる設備の稼働情報を，自装置にキャッシュする。
- 中継装置と通信アダプタは，稼働情報に関する GET リクエストを中継する際に，自装置がキャッシュしている最新の稼働情報よりも新しい稼働情報を取得するように，HTTP ヘッダ［If-Modified-Since：x］を付加する（x は時刻）。そして，新しい稼働情報が得られない場合には，自装置がキャッシュしている最新の稼働情報を利用する。
- ④ の通信では，2 台の新業務サーバに実装された HTTP クライアントが，定期的に配下の設備に GET リクエストをそれぞれ送信し，稼働情報を取得する。(a) 稼働情報取得のトリガは，設備ではなく K 社データセンタ側にあるが，それは運用上の利点となっている。各新業務サーバが取得した稼働情報は，データベースの機能を用いて新業務サーバ間で同期する。
- ④’ の通信では，通信アダプタは単独で，HTTP ヘッダ［If-Modified-Since：x］を付加した GET リクエストを設備へ 1 分間隔で送信し，取得した稼働情報を自装置にキャッシュする。
この稼働情報取得案に従うと，［ う ］ はフォワードプロキシ，［ え ］ は ［ お ］ プロキシとして動作しているとみなすことができる。
稼働情報取得案の通信シーケンス例を，図6に示す。
図6中の時刻（T，Ta〜Tf，T’，Tb’）のうち，Ta，Td はリクエストの開始時刻，Tb，Tb’，Te，Tf はキャッシュされている最新稼働情報のタイムスタンプの時刻である。また，時刻の前後関係は次のとおりである。
Tb ≦ Tb’ ＜ Tc Te ＜ Tf
ここで，x ＜ y は，x が y に先行することを示す。
K 社情報システム部の M 君は，保守システムのネットワーク基盤を担当している。上司の N 氏から指示を受けた M 君は，保守システムの機能強化プロジェクトに先立ち，そこで必要となるネットワーク基盤の拡張について調査を進めてきた。
M 君は，図4〜6を使って，その調査結果を N 氏に説明した。次はそのときの会話である。
- N 氏：図4〜6の内容は分かった。保守システムの機能強化プロジェクトで具体的な検討を行うことにしよう。ただ，その前に二つ確認したいことがある。
- M 君：どのようなことでしょうか。
- N 氏：今，保守システムの機能強化と並行して，次世代設備の企画も進められている。次世代設備では，通信インタフェースとして，低電力でも稼働できる ZigBee を採用する。さらに，HTTP 以外の通信プロトコルも実装できる。一方，サービスの拡充に伴い，通信トラフィックは増加していくだろう。そこで，次世代設備向けにもっと効率が良い通信方式がないか調査して報告してほしい。図4〜6の案が，その新しい通信方式にも拡張可能かどうかも，事前に確認しておきたい。
- M 君：分かりました。調べてみます。
- N 氏：もう一つは，LAN 構成とネットワーク負荷に関する確認だ。今回，初めてブレードサーバを導入する予定だが，LAN 構成をどのように変えるのかを確認してほしい。それから，稼働情報収集では大量の通信が発生するはずだ。現行のネットワーク機器への影響が懸念される。その調査もお願いする。
- M 君：分かりました。それらについても確認します。
〔次世代設備に関する通信方式〕
M 君は早速，新しい通信方式について調査し，RFC 7252 によって標準化が進められている通信プロトコルである CoAP（Constrained Application Protocol）が HTTP の代わりに利用できそうだと考えた。M 君が CoAP について調査した結果を次に示す。
- CoAP は，UDP 上で動作可能な，HTTP に似た通信プロトコルである。
- HTTP リクエストを CoAP リクエストに変換したり，CoAP レスポンスを HTTP レスポンスに変換したりすることもできる。
- CoAP のメッセージ形式を図7に示す。
- CoAP のメッセージは，4 バイトのヘッダと可変長の Token，Options，Payload から構成されている。1 バイトの Code を使い，リクエストの種別やレスポンスの状態コードを指定する。ZigBee に用いられる IEEE 802.15.4 フレームのデータ部は，IEEE 802.3（Ethernet）フレームのデータ部よりもかなり短く，CoAP のメッセージ形式は，それに適したものになっている。
以上の調査から，M 君は，(b) TCP 上の HTTP を UDP 上の CoAP に置き換えることによって，通信アダプタと中継装置を用いた通信の TAT（Turn Around Time）を向上させることができると判断した。また，その際 FW の設定を変更しなくてもよいように，HTTP と CoAP の変換機能は，図5中の ［ か ］ に実装することにした。
M 君は，調査結果を基に，現在の設備に関する通信方式が次世代設備に関しても拡張可能であることを N 氏に説明した。
〔LAN の構成とネットワーク負荷〕
情報システム部は，新機能の開発に先立ち，次のような方針を立てている。
- 2 台のブレードを内蔵したブレードサーバを K 社データセンタに導入する。
- 2 台の新業務サーバと 2 台の中継装置を，ブレード上の仮想サーバに実装する。
- 中継装置は Active-Standby 方式で冗長化させる。
- 図5中の ② の通信は LB を経由させ，2 台の新業務サーバに負荷分散させる。
M 君は，新機能開発の方針を基に，NIC（Network Interface Card）を含む，ブレードサーバに関する LAN 構成について，次のような確認・検討を行った。
- ブレードサーバ内の LAN 構成を，図8に示す。
- 仮想サーバの二つの仮想 NIC は，ブレードの二つの物理 NIC にそれぞれ接続され，仮想サーバのチーミング機能によって冗長化されている。
- ブレードの二つの物理 NIC は，ブレードサーバの二つの内部 L2SW にそれぞれ接続され，ブレードのチーミング機能によって冗長化されている。
- LB 利用の有無を考慮し，新業務サーバと中継装置は別の VLAN に収容する。
- 新業務サーバのデフォルトゲートウェイには ［ き ］ を，中継装置のデフォルトゲートウェイには FW を，それぞれ定義する。
- (c) 図8中の二つの内部 L2SW に，図2中の 2 組の L2SW を接続する。
図5中の ④ の通信では，大量の HTTP リクエストと HTTP レスポンスの対（以下，トランザクションという）が発生し，現行ネットワークの通信帯域に影響を与える可能性がある。また，FW は，TCP コネクションの確立開始から切断完了までの状態（以下，コネクションという）を管理するので，④ の通信の同時コネクション数は FW の性能に影響を与える可能性がある。そこで，M 君は，これらの通信負荷を見積もることにした。図5中の ④ の通信に関する見積りの前提を，表1に示す。
表1を前提にした見積り結果は次のとおりである。
- ④ の通信の起動タイミングは平準化されていると仮定すると，新サービス開始時には，表1中の項番1，6から，毎秒 ［ ア ］ トランザクションが発生する。
- 1 トランザクションは 1 コネクションで処理されると仮定すると，各コネクションの保持時間は，項番3〜5から，平均（2.4 ＋ 0.2 × Tout）秒と推定できる。
- したがって，2 台の新業務サーバの ④ の通信に関する同時コネクション数の合計は，平均（ ［ イ ］ ＋ ［ ウ ］ × Tout）コネクションと推定できる。この値は，将来，収集周期が 5 分間になると，12 倍に増加する。
- 各コネクションにおける通信データ量は，稼働情報が数バイトに過ぎない（図5）ことから，オーバヘッドを考慮しても，図2中の現行ネットワーク機器や閉域網サービスに与える影響は限定的である。
このような検討の結果から，M 君は，通信帯域については当面懸念しなくてもよいと判断した。しかし，同時コネクション数は，FW の性能に大きく影響すると考え，負荷の予測と FW の増強について提言をまとめた。提言には，同時コネクション数を軽減するために，HTTP/1.1 の実装に関する次の三つの提案を含めた。
- TCP コネクション保持時間の短縮案1：(d) 中継装置の Tout の設定方針
- TCP コネクション保持時間の短縮案2：(e) 新業務サーバからのリクエストにおけるクローズ接続オプションの使い方
- 同時コネクション数の削減案：トランザクションをパイプライン化する工夫と，その前提となる，(f) 設備のリソースを指定する際の URL に関する設計方針
M 君は，以上の検討結果をまとめ，N 氏に報告した。
その後，保守システムの機能強化プロジェクトが開始されることになり，M 君はネットワークグループのリーダに任命された。
出題趣旨（IPA）
M2M（Machine to Machine）に関する，情報技術やシステム基盤が整備されつつあり，それらを活用した新しい情報システムの開発が進められている。M2Mには，センサ，制御機器，設備などの多様な機械（Machine）に関して，それらの性能や収容方法を考慮し，情報収集や制御などのユースケースを踏まえた，ネットワーク構築が必要となる。本問では，リモート保守用の情報システム開発の初期検討を題材にしている。現行のTCP/IPネットワークの拡張について，ネットワーク担当の視点から検討する。具体的には，利用形態から追加される通信を導き，その実現方法と，現行ネットワークへの影響を考察する。固有の知識を前提とはせずに，TCP/IPやHTTPに関する基本知識だけで推論できるよう記述を工夫し，ネットワーク基盤の拡張要件に関する，受験者の応用能力を問う。
設問と解答例
本文中の ［ あ ］ に入れる適切な字句を答えよ。
〔あ〕解答例
- 送信元IP
解説
本文の根拠
〔現在の保守システム〕
Web サーバと業務サーバのデフォルトゲートウェイは，LB である。
〔現在の保守システム〕
LB は，宛先の仮想 IP アドレスを実 IP アドレスに変換し，サーバへのアクセスを振り分ける。Web サーバから業務サーバへのアクセスについては，両サーバが同一セグメント内にあるので，［ あ ］ アドレスも変換する。
Web サーバが業務サーバの仮想 IP アドレスへリクエストを送ると，LB は宛先を業務サーバの実 IP アドレスに変換して転送する。宛先だけを変換すると，業務サーバには送信元が Web サーバの実 IP アドレスのまま届く。業務サーバから見て Web サーバは同じセグメントにいるので，レスポンスをデフォルトゲートウェイの LB に渡さず，Web サーバへ直接送ってしまう。Web サーバは自分が送った宛先（業務サーバの仮想 IP アドレス）とは違う送信元からの応答を受け取ることになり，通信が成り立たない。そこで LB は送信元 IP アドレスも自分のアドレスに変換し，レスポンスが必ず LB に戻るようにする。
根拠は「両サーバが同一セグメント内にあるので」の一文である。クライアントからのアクセス（FW 経由）は別セグメントから来るので，デフォルトゲートウェイの LB を通って戻り，宛先の変換だけで済む。
間違えやすい点。「MAC」ではない。LB は IP アドレスを書き換えて振り分けている。空欄の後に「アドレス」と続くので，「送信元 IP」まで書く。
採点講評（IPA）
設問1〜4に正答率の大きな偏りはなく，全体の内容はよく理解されていた。その中で，TCP/IPの基本に関する設問1(1)と設問3(2)と，HTTPに関する設問4(5)，(6)の正答率が比較的低かった。これらは，特別な知識は不要だが，複数の要素を理解し，正答を推論する問題である。日頃の勉強や実務でも，ネットワーク技術者として，複雑な状況から本質を見極め，課題を解決するという行動パターンを心掛けてほしい。設問1は，サーバネットワークに関する理解を問うている。ヘッダ内のアドレスの変化など，基本事項に関する設問だが，誤答が少なからず見受けられた。この種の問題は落ち着いて取り組み着実に答えるようにしてほしい。
図3中の ［ い ］ に入れる適切な機器名を答えよ。
〔い〕解答例
- LB正
解説
本文の根拠
〔現在の保守システム〕
Web サーバと業務サーバへアクセスするための仮想 IP アドレスが，それぞれに定義されている。
〔現在の保守システム〕
FW 及び LB は，Active-Standby 方式で冗長化されている。
図3
左から FW 正，LB 正，Web サーバ1，2，［ い ］（太枠の空欄），業務サーバ1，2 が横に並ぶ。
Web サーバは業務サーバの仮想 IP アドレスへアクセスする。仮想 IP アドレスを実 IP アドレスに変換して振り分けるのは LB なので，Web サーバと業務サーバの間には LB が入る。LB は Active-Standby で冗長化されており，通常時に動いているのは正系なので「LB 正」になる。
図3は通常時の流れで，左端の FW，その次の LB もすでに「FW 正」「LB 正」と正系で書かれている。空欄の機器もこれに合わせる。
間違えやすい点。同じ LB 正が図3に2回出てくることに戸惑うかもしれないが，①②の LB 正と③〜⑥の LB 正は同じ機器である。「LB」だけでは通常時の機器を特定しきれないので，正系まで書く。
採点講評（IPA）
設問1は，サーバネットワークに関する理解を問うている。ヘッダ内のアドレスの変化など，基本事項に関する設問だが，誤答が少なからず見受けられた。この種の問題は落ち着いて取り組み着実に答えるようにしてほしい。
図3中の ①〜⑧ の IP パケットのうち，送信元 IP アドレスが ②と同じになる IP パケットの番号を全て答えよ。
解答例
- ①
解説
本文の根拠
〔現在の保守システム〕
LB は，宛先の仮想 IP アドレスを実 IP アドレスに変換し，サーバへのアクセスを振り分ける。
図3
リクエストのデータの流れは右向きの矢印で，FW 正→LB 正が①，LB 正→Web サーバ1，2 が②，Web サーバ1，2→［ い ］が③，［ い ］→業務サーバ1，2 が④。
②は LB 正が Web サーバへ転送するリクエストで，送信元はクライアント（保守センタの PC 又は保守端末）の IP アドレスである。LB はクライアントからのアクセスでは宛先だけを変換するので，送信元は①と同じになる。ほかの番号の送信元を追うと，③と⑦は Web サーバの実 IP アドレス，④は LB（設問1(1)の送信元変換），⑤は業務サーバの実 IP アドレス，⑥は業務サーバの仮想 IP アドレス，⑧は Web サーバの仮想 IP アドレスである。したがってクライアントの IP アドレスを送信元にもつのは①だけになる。
本文は「宛先の仮想 IP アドレスを実 IP アドレスに変換」と，クライアントからのアクセスで変えるのは宛先であることを書いている。送信元の変換は，Web サーバから業務サーバへのアクセスに限った話である。
間違えやすい点。⑦（Web サーバから LB へのレスポンス）は②の逆向きなので，送信元と宛先が入れ替わる。⑦の送信元は Web サーバの実 IP アドレスであり，②の送信元とは一致しない。
採点講評（IPA）
設問1は，サーバネットワークに関する理解を問うている。ヘッダ内のアドレスの変化など，基本事項に関する設問だが，誤答が少なからず見受けられた。この種の問題は落ち着いて取り組み着実に答えるようにしてほしい。
図3中の ①〜⑧ の IP パケットのうち，宛先 IP アドレスが ②と同じになる IP パケットの番号を全て答えよ。
解答例
- ⑥
解説
本文の根拠
〔現在の保守システム〕
Web サーバから業務サーバへのアクセスについては，両サーバが同一セグメント内にあるので，［ あ ］ アドレスも変換する。
図3
レスポンスのデータの流れは左向きの矢印で，業務サーバ1，2→［ い ］が⑤，［ い ］→Web サーバ1，2 が⑥，Web サーバ1，2→LB 正が⑦，LB 正→FW 正が⑧。
②の宛先は，LB が変換した後の Web サーバの実 IP アドレスである。Web サーバの実 IP アドレスを宛先にもつのは，②のほかに⑥がある。③で Web サーバは自分の実 IP アドレスを送信元にしてリクエストを送り，LB が④で送信元を LB のアドレスに変換する。業務サーバのレスポンス⑤は LB 宛てに返り，LB は変換を元に戻して，⑥を Web サーバの実 IP アドレス宛てに送る。
設問1(1)の送信元変換があるので，⑤の宛先は LB であって Web サーバではない。変換を戻した⑥で初めて Web サーバの実 IP アドレスが宛先になる。
間違えやすい点。⑤を選ばないこと。送信元を変換しなければ⑤の宛先も Web サーバになるが，その場合は業務サーバが LB を通さず直接返してしまい，図3の流れにならない。⑧の宛先はクライアントである。
採点講評（IPA）
設問1は，サーバネットワークに関する理解を問うている。ヘッダ内のアドレスの変化など，基本事項に関する設問だが，誤答が少なからず見受けられた。この種の問題は落ち着いて取り組み着実に答えるようにしてほしい。
本文中の ［ う ］ 〜 ［ お ］ に入れる適切な字句を答えよ。
〔う〕解答例
- 中継装置
〔え〕解答例
- 通信アダプタ
〔お〕解答例
- リバース
解説
本文の根拠
〔保守システムの機能強化〕
中継装置と通信アダプタは，HTTP レスポンスに含まれる設備の稼働情報を，自装置にキャッシュする。
〔保守システムの機能強化〕
この稼働情報取得案に従うと，［ う ］ はフォワードプロキシ，［ え ］ は ［ お ］ プロキシとして動作しているとみなすことができる。
図5
③：PC から FW を通って中継装置に入り，中継装置から FW と通信アダプタを通って設備へ向かう。
フォワードプロキシはクライアントの側に置かれ，クライアントに代わって様々なサーバへリクエストを出す。リバースプロキシはサーバの側に置かれ，サーバに代わってクライアントのリクエストを受ける。この構成で HTTP クライアントは PC と新業務サーバ，HTTP サーバは設備である。中継装置は K 社データセンタにあってクライアントのリクエストを受け，多数の設備へ中継するのでフォワードプロキシ（う）に当たる。通信アダプタは顧客の設備の手前にあり，配下の設備に代わってリクエストを受けてキャッシュから応答することもあるので，リバースプロキシ（え，お）に当たる。
図5で③や④”は PC から中継装置を経て，通信アダプタから設備へ届く。クライアント寄りが中継装置，サーバ（設備）寄りが通信アダプタという位置関係が，二つのプロキシの別を決める。
間違えやすい点。う と え を入れ替えないこと。どちらもキャッシュをもつが，どちらの側の代理をしているかで名前が決まる。お は「逆」ではなく「リバース」と答える。
採点講評（IPA）
設問2は，提案された稼働情報収集の通信方式への理解を問うている。HTTP/1.1の基本知識を前提としたが，多くは提示した通信シーケンス例などから直接読み解く必要があることから，(2)，(5)，(6)は，受験者の経験によって差が出た設問だったようである。
本文中の下線(a)の利点を，25 字以内で述べよ。
解答例
- 稼働情報の収集周期の変更が容易である。
解説
本文の根拠
〔保守システムの機能強化〕
④ の通信では，2 台の新業務サーバに実装された HTTP クライアントが，定期的に配下の設備に GET リクエストをそれぞれ送信し，稼働情報を取得する。(a) 稼働情報取得のトリガは，設備ではなく K 社データセンタ側にあるが，それは運用上の利点となっている。
〔保守システムの機能強化〕
収集周期は，サービス開始時は 1 時間とし，段階的に 5 分間程度に短縮しサービス品質を向上させる。
稼働情報を取りにいく契機が新業務サーバにあるので，収集周期は新業務サーバの設定を変えるだけで変えられる。もし設備の側から送る方式なら，周期を変えるたびに全国の顧客にある多数の設備の設定を変えなければならない。
本文は，収集周期をサービス開始時の 1 時間から段階的に 5 分間程度へ短くすると書いている。周期を何度も変えることが予定されているので，データセンタ側だけで変えられることが運用上の利点になる。
字数の詰め方（25字）。何が容易になるかを具体的に書く。解答例は「稼働情報の収集周期の変更が容易である。」（19字）である。「管理しやすい」だけでは何の利点か伝わらない。
採点講評（IPA）
設問2は，提案された稼働情報収集の通信方式への理解を問うている。HTTP/1.1の基本知識を前提としたが，多くは提示した通信シーケンス例などから直接読み解く必要があることから，(2)，(5)，(6)は，受験者の経験によって差が出た設問だったようである。
図6中の例Ⅱのシーケンスによって，通信アダプタのキャッシュが更新される。更新後の最新稼働情報のタイムスタンプの時刻を答えよ。
解答例
- Tc
解説
本文の根拠
図6
設備が通信アダプタへレスポンス［Last-Modified：Tc］を返し，通信アダプタが中継装置へレスポンス［Last-Modified：Tc］を返し，中継装置が PC，新業務サーバへレスポンスを返す。
〔保守システムの機能強化〕
中継装置と通信アダプタは，HTTP レスポンスに含まれる設備の稼働情報を，自装置にキャッシュする。
例Ⅱでは，通信アダプタが If-Modified-Since：Tb’ を付けて設備へ GET リクエストを送り，設備は Tb’ より新しい稼働情報を Last-Modified：Tc 付きで返している。通信アダプタはこのレスポンスの稼働情報をキャッシュするので，更新後の最新稼働情報のタイムスタンプは Tc になる。Last-Modified はそのリソースが最後に変更された時刻を示すヘッダである（RFC 7232）。
時刻の関係 Tb’ ＜ Tc からも，キャッシュが古い Tb’ から新しい Tc に置き換わることが分かる。
間違えやすい点。リクエストの開始時刻 Ta ではない。キャッシュのタイムスタンプは稼働情報そのものの時刻であり，設備が返した Last-Modified の値になる。
採点講評（IPA）
設問2は，提案された稼働情報収集の通信方式への理解を問うている。HTTP/1.1の基本知識を前提としたが，多くは提示した通信シーケンス例などから直接読み解く必要があることから，(2)，(5)，(6)は，受験者の経験によって差が出た設問だったようである。
図6中の例Ⅱの GET リクエストの中継において，Tb と Tb’ は異なる場合が多いが，それはなぜか。キャッシュに着目して，35 字以内で述べよ。
解答例
- 中継装置より通信アダプタのキャッシュの更新頻度が高く新しいから
解説
本文の根拠
〔保守システムの機能強化〕
④’ の通信では，通信アダプタは単独で，HTTP ヘッダ［If-Modified-Since：x］を付加した GET リクエストを設備へ 1 分間隔で送信し，取得した稼働情報を自装置にキャッシュする。
図5
④：稼働情報の取得，数バイト，定期（5 分間隔〜1 時間間隔）。④’：稼働情報の取得，数バイト，定期（1 分間隔）。
Tb は中継装置が，Tb’ は通信アダプタがそれぞれキャッシュしている最新稼働情報のタイムスタンプである。通信アダプタは④’で 1 分間隔で設備から稼働情報を取り直しているので，キャッシュが頻繁に更新される。中継装置のキャッシュは④や④”のリクエストが通ったときにしか更新されない。このため通信アダプタのキャッシュのほうが新しいことが多く，Tb と Tb’ は異なることが多い。
図5の表で，④は 5 分間隔〜1 時間間隔，④’は 1 分間隔とされている。更新の頻度の差が，キャッシュの新しさの差になる。条件 Tb ≦ Tb’ も，通信アダプタのほうが新しいか同じであることを示している。
字数の詰め方（35字）。二つの装置の比較と，更新頻度の差を書く。解答例は「中継装置より通信アダプタのキャッシュの更新頻度が高く新しいから」（31字）である。
採点講評（IPA）
設問2は，提案された稼働情報収集の通信方式への理解を問うている。HTTP/1.1の基本知識を前提としたが，多くは提示した通信シーケンス例などから直接読み解く必要があることから，(2)，(5)，(6)は，受験者の経験によって差が出た設問だったようである。
図6中の例Ⅲの通信シーケンスになるのは，どのような場合が考えられるか。通信アダプタと設備の間の通信に着目して二つ挙げ，それぞれ 30 字以内で述べよ。
〔①〕解答例
- 設備とTCPコネクションが確立できない場合
〔②〕解答例
- 設備がNot Modifiedを応答した場合
解説
本文の根拠
〔保守システムの機能強化〕
また，設備はいつも通電されているとは限らないので，それを考慮した仕組み（以下，稼働情報取得案という）を用意する。
〔保守システムの機能強化〕
中継装置と通信アダプタは，稼働情報に関する GET リクエストを中継する際に，自装置がキャッシュしている最新の稼働情報よりも新しい稼働情報を取得するように，HTTP ヘッダ［If-Modified-Since：x］を付加する（x は時刻）。そして，新しい稼働情報が得られない場合には，自装置がキャッシュしている最新の稼働情報を利用する。
図6
例Ⅲ：図5中の通信④，④”（設備から更新情報を取得できなかった場合）。
例Ⅲは，通信アダプタが設備から新しい稼働情報を得られず，自分のキャッシュ（タイムスタンプ Tf）で応答した場合である。得られない場合は二つ考えられる。一つは設備の電源が切れているなどで，通信アダプタと設備の間で TCP コネクションが確立できない場合である。もう一つは，設備が If-Modified-Since の時刻より新しい情報をもたず，304 Not Modified を返した場合である（RFC 7232）。どちらでも通信アダプタは本文のとおりキャッシュを使う。
本文は「設備はいつも通電されているとは限らない」と通電していない場合を想定しており，また If-Modified-Since を付けているので「更新されていない」という応答もありうる。
字数の詰め方（各30字）。通信アダプタと設備の間で何が起きたかを書く。解答例は「設備と TCP コネクションが確立できない場合」「設備が Not Modified を応答した場合」である。二つの順序は問わない。
採点講評（IPA）
設問2は，提案された稼働情報収集の通信方式への理解を問うている。HTTP/1.1の基本知識を前提としたが，多くは提示した通信シーケンス例などから直接読み解く必要があることから，(2)，(5)，(6)は，受験者の経験によって差が出た設問だったようである。
図6中の例Ⅰの周期を長くした場合（例えば 1 分間隔から 2 分間隔へ変更），HTTP クライアントが受け取る応答への影響を 40 字以内で述べよ。
解答例
- 電源断などで設備との通信ができない場合の稼働情報が古くなる。
解説
本文の根拠
図6
例Ⅰ：図5中の通信④’（破線内を 1 分間隔で繰り返す）。
〔保守システムの機能強化〕
そして，新しい稼働情報が得られない場合には，自装置がキャッシュしている最新の稼働情報を利用する。
設備と通信できるときは，④や④”のリクエストは通信アダプタから設備まで届き，最新の稼働情報が返る。例Ⅰの周期に左右されるのは，電源断などで設備と通信できず，通信アダプタがキャッシュで応答する場合である。このときの応答は，通信アダプタが最後に取得できた稼働情報になる。例Ⅰの周期を 1 分から 2 分に延ばすと，最後に取得できた時点が設備の停止時刻からより離れうるので，応答される稼働情報が古くなる。
本文は，新しい稼働情報が得られない場合はキャッシュの最新の稼働情報を利用すると書いている。キャッシュの新しさを決めるのが例Ⅰ（④’）の周期である。
字数の詰め方（40字）。どの場合に，何がどうなるかを書く。解答例は「電源断などで設備との通信ができない場合の稼働情報が古くなる。」（30字）である。「常に古くなる」とすると，通信できる場合まで含んでしまい誤りになる。
採点講評（IPA）
設問2は，提案された稼働情報収集の通信方式への理解を問うている。HTTP/1.1の基本知識を前提としたが，多くは提示した通信シーケンス例などから直接読み解く必要があることから，(2)，(5)，(6)は，受験者の経験によって差が出た設問だったようである。
本文中の ［ か ］ に入れる適切な機器名を答えよ。
〔か〕解答例
- 通信アダプタ
解説
本文の根拠
〔次世代設備に関する通信方式〕
HTTP リクエストを CoAP リクエストに変換したり，CoAP レスポンスを HTTP レスポンスに変換したりすることもできる。
〔次世代設備に関する通信方式〕
また，その際 FW の設定を変更しなくてもよいように，HTTP と CoAP の変換機能は，図5中の ［ か ］ に実装することにした。
FW は K 社データセンタと閉域網サービスの間にあり，いまは HTTP（TCP）の通信を通すように設定されている。CoAP は UDP 上で動くので，FW を CoAP が通るなら UDP を許可する設定が要る。変換機能を FW より設備側の通信アダプタに置けば，FW を通るのは従来どおり HTTP のままで，CoAP は通信アダプタと設備の間だけで使われる。
図5で FW の外側（顧客側）にある機器は通信アダプタと設備だけである。中継装置や新業務サーバは FW の内側にあるので，そこで変換すると CoAP が FW を通ってしまう。
間違えやすい点。「中継装置」ではない。空欄は機器名を問うので「通信アダプタ」と答える。
採点講評（IPA）
設問3ではCoAP（Constrained Application Protocol）という比較的新しい通信プロトコルを取り上げた。固有の知識は求めず，通信プロトコルの基本知識だけでも十分解ける問題とした。基本技術の正しい理解や，従来技術から新技術を理解・評価する能力は，実務でも大切である。
図7の CoAP メッセージ以外に，IEEE 802.15.4 フレームのデータ部に含まれるデータを，20 字以内で答えよ。
解答例
- IPヘッダとUDPヘッダ
解説
本文の根拠
〔次世代設備に関する通信方式〕
CoAP は，UDP 上で動作可能な，HTTP に似た通信プロトコルである。
〔次世代設備に関する通信方式〕
ZigBee に用いられる IEEE 802.15.4 フレームのデータ部は，IEEE 802.3（Ethernet）フレームのデータ部よりもかなり短く，CoAP のメッセージ形式は，それに適したものになっている。
CoAP は UDP の上で動き，UDP は IP の上で動く。IEEE 802.15.4 のフレームで CoAP を運ぶと，データ部には CoAP メッセージの前に UDP ヘッダと IP ヘッダが入る。Ethernet のデータ部に IP パケットが入るのと同じ関係である。IEEE 802.15.4 のフレームは最大 127 バイトと小さいので，IPv6 を載せるときはヘッダを圧縮する方式（6LoWPAN，RFC 4944）が使われるが，いずれにしても IP と UDP のヘッダ情報がデータ部に入る。
本文の「UDP 上で動作可能」から，CoAP の下に UDP があることが読み取れる。CoAP は RFC 7252 で規定され，UDP のポート 5683 を使う。
字数の詰め方（20字）。解答例は「IP ヘッダと UDP ヘッダ」である。講評はこの設問の正答率が比較的低かったとしている。CoAP 自身のヘッダ（Token など）は図7の CoAP メッセージに含まれるので答えにならない。
採点講評（IPA）
設問1〜4に正答率の大きな偏りはなく，全体の内容はよく理解されていた。その中で，TCP/IPの基本に関する設問1(1)と設問3(2)と，HTTPに関する設問4(5)，(6)の正答率が比較的低かった。これらは，特別な知識は不要だが，複数の要素を理解し，正答を推論する問題である。日頃の勉強や実務でも，ネットワーク技術者として，複雑な状況から本質を見極め，課題を解決するという行動パターンを心掛けてほしい。設問3ではCoAP（Constrained Application Protocol）という比較的新しい通信プロトコルを取り上げた。固有の知識は求めず，通信プロトコルの基本知識だけでも十分解ける問題とした。基本技術の正しい理解や，従来技術から新技術を理解・評価する能力は，実務でも大切である。
本文中の下線(b)について，TAT の向上に寄与する，CoAP と UDP の特長を二つ挙げ，それぞれ 30 字以内で述べよ。
〔①〕解答例
- TCPコネクションの確立と終了の手順が不要である。
〔②〕解答例
- CoAPはヘッダ長が短いなど，データの格納効率が良い。
解説
本文の根拠
〔次世代設備に関する通信方式〕
以上の調査から，M 君は，(b) TCP 上の HTTP を UDP 上の CoAP に置き換えることによって，通信アダプタと中継装置を用いた通信の TAT（Turn Around Time）を向上させることができると判断した。
〔次世代設備に関する通信方式〕
CoAP のメッセージは，4 バイトのヘッダと可変長の Token，Options，Payload から構成されている。
TAT はリクエストを送ってから応答が返るまでの時間である。一つは UDP の特長で，TCP のようにデータを送る前の 3 ウェイハンドシェークや，終わった後のコネクション切断の手順が要らない。1 回のやり取りが数バイトの稼働情報なので，手順の往復が省ける効果は大きい。もう一つは CoAP の特長で，ヘッダが 4 バイトと短く，テキストで書く HTTP のヘッダに比べて同じ情報を少ないバイト数で運べる。フレームの小さい IEEE 802.15.4 では，送るフレーム数や時間が減る。
本文の「4 バイトのヘッダ」と「CoAP のメッセージ形式は，それに適したものになっている」が CoAP の側の根拠である。UDP の側は下線(b)の「TCP 上の HTTP を UDP 上の CoAP に置き換える」から，TCP の手順が無くなることを読む。
字数の詰め方（各30字）。UDP と CoAP から一つずつ挙げる。解答例は「TCP コネクションの確立と終了の手順が不要である。」「CoAP はヘッダ長が短いなど，データの格納効率が良い。」である。
採点講評（IPA）
設問3ではCoAP（Constrained Application Protocol）という比較的新しい通信プロトコルを取り上げた。固有の知識は求めず，通信プロトコルの基本知識だけでも十分解ける問題とした。基本技術の正しい理解や，従来技術から新技術を理解・評価する能力は，実務でも大切である。
本文中の ［ き ］ に入れる適切な機器名を答えよ。
〔き〕解答例
- LB
解説
本文の根拠
〔LAN の構成とネットワーク負荷〕
図5中の ② の通信は LB を経由させ，2 台の新業務サーバに負荷分散させる。
〔LAN の構成とネットワーク負荷〕
新業務サーバのデフォルトゲートウェイには ［ き ］ を，中継装置のデフォルトゲートウェイには FW を，それぞれ定義する。
②の通信は LB で負荷分散させるので，新業務サーバは既存の Web サーバや業務サーバと同じく LB の配下（LB と L2SW-30，31 のセグメント）に置く。LB の配下のサーバは，レスポンスが LB を通って戻らないと LB の変換が元に戻せない。このため既存のサーバと同じく，デフォルトゲートウェイを LB にする。
本文は既存のサーバについて「Web サーバと業務サーバのデフォルトゲートウェイは，LB である」と書いている。新業務サーバも LB を経由させる方針なので，同じ設定になる。中継装置は LB を使わないので，デフォルトゲートウェイは FW になる。
間違えやすい点。「LB 正」と書く必要はない。デフォルトゲートウェイは Active-Standby で引き継がれる LB のアドレスを指すので，機器名としては「LB」でよい。
採点講評（IPA）
設問4は，“(1)，(2)仮想サーバを含むネットワーク”と，“(3)〜(6)HTTPにおけるTCPコネクション（いわゆるセッション維持）”に関する設問である。どちらも過去に出題したテーマであるが，それらを通じて今回の題材への総合理解を問うた。限られた時間でもよく書けていた解答が多い一方で，“(5)クローズ接続オプションの使い方”や“(6)URLに関する設計指針”については理解不足の解答もやや目立った。本設問では，通常の“TCPコネクション維持によるWebアクセスの応答時間改善”ではなく，“TCPコネクション解放によるファイアウォールの論理資源節約”という，いわば逆の要件になっていることに注意してほしい。
本文中の下線(c)について，内部 L2SW と L2SW との接続を，図9に示す。内部 L2SW と L2SW との接続を追記し，図9を完成させよ。
解答例（図）
解説
本文の根拠
〔LAN の構成とネットワーク負荷〕
LB 利用の有無を考慮し，新業務サーバと中継装置は別の VLAN に収容する。
〔LAN の構成とネットワーク負荷〕
(c) 図8中の二つの内部 L2SW に，図2中の 2 組の L2SW を接続する。
〔現在の保守システム〕
リンクアグリゲーションで接続された 3 組の L2SW は，それぞれ単一の異なるセグメントを構成している。
新業務サーバは LB 経由の通信を受けるので，LB の配下のセグメント（L2SW-30，31）につなぐ。中継装置は LB を使わずデフォルトゲートウェイが FW なので，FW と LB の間のセグメント（L2SW-20，21）につなぐ。二つの内部 L2SW はどちらのブレードにもつながっているので，各内部 L2SW を両方のセグメントに接続し，新業務サーバ用と中継装置用の VLAN を通す。冗長化のために，内部 L2SW-0 は正系の列の L2SW-20 と L2SW-30 に，内部 L2SW-1 は副系の列の L2SW-21 と L2SW-31 に接続する。これで内部 L2SW や外部の L2SW のどれか一つが故障しても，残りの経路で両方のセグメントに届く。
本文の「2 組の L2SW」は，3 組のうち FW の内側にある L2SW-20，21 の組と L2SW-30，31 の組である。L2SW-10，11 は FW の外側（閉域網サービス側）なので，つなぐと FW を迂回してしまう。
間違えやすい点。1 台の内部 L2SW を同じ組の 2 台（L2SW-20 と L2SW-21 など）につなぐと，どちらかの内部 L2SW が止まったときに片方のセグメントに届かなくなる。各内部 L2SW が両方の組に 1 本ずつつながっていることを確かめる。
採点講評（IPA）
設問4は，“(1)，(2)仮想サーバを含むネットワーク”と，“(3)〜(6)HTTPにおけるTCPコネクション（いわゆるセッション維持）”に関する設問である。どちらも過去に出題したテーマであるが，それらを通じて今回の題材への総合理解を問うた。限られた時間でもよく書けていた解答が多い一方で，“(5)クローズ接続オプションの使い方”や“(6)URLに関する設計指針”については理解不足の解答もやや目立った。本設問では，通常の“TCPコネクション維持によるWebアクセスの応答時間改善”ではなく，“TCPコネクション解放によるファイアウォールの論理資源節約”という，いわば逆の要件になっていることに注意してほしい。
本文中の ［ ア ］ 〜 ［ ウ ］ に入れる適切な数値を答えよ。
〔ア〕解答例
- 30
〔イ〕解答例
- 72
〔ウ〕解答例
- 6
解説
本文の根拠
表1
1：稼働情報の収集対象となる設備数，108,000 台。
表1
3：稼働情報収集の成功率，80 ％，備考：通信アダプタの約 20％は，電源断の状態にある。4：トランザクションの通信時間，3 秒。5：TCP の無通信タイムアウト時間，Tout 秒。6：新サービス開始時の収集周期，3,600 秒，備考：将来，5 分間に短縮される。
〔LAN の構成とネットワーク負荷〕
1 トランザクションは 1 コネクションで処理されると仮定すると，各コネクションの保持時間は，項番3〜5から，平均（2.4 ＋ 0.2 × Tout）秒と推定できる。
ア：108,000 台の設備から 3,600 秒に 1 回ずつ取得するので，108,000÷3,600＝30 トランザクション/秒である。イ・ウ：同時コネクション数の平均は，1 秒当たりに発生するコネクション数×1 コネクションの平均保持時間で求まる。30×（2.4＋0.2×Tout）＝72＋6×Tout なので，イは 72，ウは 6 である。
保持時間の式は表1から確かめられる。80％は成功して通信時間 3 秒で終わり，20％は電源断で応答が無く無通信タイムアウト Tout 秒まで残るので，0.8×3＋0.2×Tout＝2.4＋0.2×Tout となる。検算として，収集周期が 5 分間（300 秒）になると毎秒 108,000÷300＝360 トランザクションで，3,600÷300＝12 倍になる。本文の「12 倍に増加する」と一致する。
間違えやすい点。2 台の新業務サーバで割らないこと。問われているのは 2 台の合計で，108,000 台は 2 台が分担する全設備数である。
採点講評（IPA）
設問4は，“(1)，(2)仮想サーバを含むネットワーク”と，“(3)〜(6)HTTPにおけるTCPコネクション（いわゆるセッション維持）”に関する設問である。どちらも過去に出題したテーマであるが，それらを通じて今回の題材への総合理解を問うた。限られた時間でもよく書けていた解答が多い一方で，“(5)クローズ接続オプションの使い方”や“(6)URLに関する設計指針”については理解不足の解答もやや目立った。本設問では，通常の“TCPコネクション維持によるWebアクセスの応答時間改善”ではなく，“TCPコネクション解放によるファイアウォールの論理資源節約”という，いわば逆の要件になっていることに注意してほしい。
本文中の下線(d)の設定方針を，30 字以内で述べよ。
解答例
- 正常な通信に支障がない範囲でなるべく小さくする。
解説
本文の根拠
〔LAN の構成とネットワーク負荷〕
しかし，同時コネクション数は，FW の性能に大きく影響すると考え，負荷の予測と FW の増強について提言をまとめた。
〔LAN の構成とネットワーク負荷〕
TCP コネクション保持時間の短縮案1：(d) 中継装置の Tout の設定方針
同時コネクション数は 72＋6×Tout なので，Tout を小さくすれば減る。Tout が効いてくるのは，電源断の設備に向けたリクエストで応答が返らず，無通信のままコネクションが残る場合である。ただし小さくしすぎると，正常に応答している通信まで途中で切ってしまう。したがって，正常な通信に支障の無い範囲でできるだけ小さくする。
設問4(3)の式で Tout の係数は 6 であり，Tout を 1 秒縮めるごとに同時コネクション数が平均 6 減る。本文はこの短縮を「TCP コネクション保持時間の短縮案」と呼んでいる。
字数の詰め方（30字）。小さくする向きと，その限度の両方を書く。解答例は「正常な通信に支障がない範囲でなるべく小さくする。」（24字）である。「小さくする」だけでは限度が抜ける。
採点講評（IPA）
設問4は，“(1)，(2)仮想サーバを含むネットワーク”と，“(3)〜(6)HTTPにおけるTCPコネクション（いわゆるセッション維持）”に関する設問である。どちらも過去に出題したテーマであるが，それらを通じて今回の題材への総合理解を問うた。限られた時間でもよく書けていた解答が多い一方で，“(5)クローズ接続オプションの使い方”や“(6)URLに関する設計指針”については理解不足の解答もやや目立った。本設問では，通常の“TCPコネクション維持によるWebアクセスの応答時間改善”ではなく，“TCPコネクション解放によるファイアウォールの論理資源節約”という，いわば逆の要件になっていることに注意してほしい。
本文中の下線(e)の使い方を，30 字以内で述べよ。
解答例
- 後続がないリクエストに付与し，コネクションを切断する。
解説
本文の根拠
〔LAN の構成とネットワーク負荷〕
提言には，同時コネクション数を軽減するために，HTTP/1.1 の実装に関する次の三つの提案を含めた。
〔LAN の構成とネットワーク負荷〕
TCP コネクション保持時間の短縮案2：(e) 新業務サーバからのリクエストにおけるクローズ接続オプションの使い方
HTTP/1.1 は既定で持続的接続を使い，レスポンスを返した後もコネクションを開いたまま次のリクエストを待つ。リクエストに Connection: close（クローズ接続オプション）を付けると，そのレスポンスを返した後にコネクションを閉じることになる（RFC 7230）。新業務サーバが同じ宛先に続けて送るリクエストが無いときに，最後のリクエストへ Connection: close を付ければ，無通信のまま Tout まで残る時間が無くなり，コネクションの保持時間が短くなる。
本文は同時コネクション数を減らすための「TCP コネクション保持時間の短縮案」としてこれを挙げている。講評も，この設問は応答時間の改善ではなく，コネクションを解放して FW の資源を節約する「逆の要件」だと注意している。
字数の詰め方（30字）。どのリクエストに付けるかと，その効果を書く。解答例は「後続がないリクエストに付与し，コネクションを切断する。」（27字）である。全てのリクエストに付けると，設問4(6)のパイプライン化が使えなくなる。
採点講評（IPA）
設問1〜4に正答率の大きな偏りはなく，全体の内容はよく理解されていた。その中で，TCP/IPの基本に関する設問1(1)と設問3(2)と，HTTPに関する設問4(5)，(6)の正答率が比較的低かった。これらは，特別な知識は不要だが，複数の要素を理解し，正答を推論する問題である。日頃の勉強や実務でも，ネットワーク技術者として，複雑な状況から本質を見極め，課題を解決するという行動パターンを心掛けてほしい。設問4は，“(1)，(2)仮想サーバを含むネットワーク”と，“(3)〜(6)HTTPにおけるTCPコネクション（いわゆるセッション維持）”に関する設問である。どちらも過去に出題したテーマであるが，それらを通じて今回の題材への総合理解を問うた。限られた時間でもよく書けていた解答が多い一方で，“(5)クローズ接続オプションの使い方”や“(6)URLに関する設計指針”については理解不足の解答もやや目立った。本設問では，通常の“TCPコネクション維持によるWebアクセスの応答時間改善”ではなく，“TCPコネクション解放によるファイアウォールの論理資源節約”という，いわば逆の要件になっていることに注意してほしい。
本文中の下線(f)の設計方針を，50 字以内で述べよ。
解答例
- 通信アダプタにFQDNを付与し，同一コネクションを使って複数の設備から稼働情報を取得する。
解説
本文の根拠
〔保守システムの機能強化〕
③，④，④’，④” の通信では，アクセスの際，設備の中の稼働情報又は操作対象の機能（以下，リソースという）を，次の形式で指定する。
〔保守システムの機能強化〕
http://（設備を指定するための FQDN）/（リソース名）
〔LAN の構成とネットワーク負荷〕
同時コネクション数の削減案：トランザクションをパイプライン化する工夫と，その前提となる，(f) 設備のリソースを指定する際の URL に関する設計方針
表1
2：通信アダプタ 1 台当たりの設備数，1〜100 台，備考：通信アダプタ 1 台に対して，複数の設備が接続される。
HTTP/1.1 のパイプライン化は，一つの TCP コネクションで応答を待たずに複数のリクエストを続けて送る方式である。コネクションは接続先のホストごとに張るので，同じコネクションに載せられるのは同じ FQDN 宛てのリクエストに限られる。今の形式では設備ごとに FQDN が違うので，設備ごとに別のコネクションになる。そこで FQDN を通信アダプタに付け，設備の区別は URL のパスで表すようにすれば，1 台の通信アダプタにつながる最大 100 台の設備の稼働情報を，一つのコネクションでまとめて取得できる。
本文の URL 形式は「設備を指定するための FQDN」になっている。表1は通信アダプタ 1 台に複数の設備がつながると書いているので，FQDN を通信アダプタの単位にすると，コネクションの数を通信アダプタの台数まで減らせる。
字数の詰め方（50字）。FQDN を何に付けるかと，それで何ができるかを書く。解答例は「通信アダプタに FQDN を付与し，同一コネクションを使って複数の設備から稼働情報を取得する。」（45字）である。
採点講評（IPA）
設問1〜4に正答率の大きな偏りはなく，全体の内容はよく理解されていた。その中で，TCP/IPの基本に関する設問1(1)と設問3(2)と，HTTPに関する設問4(5)，(6)の正答率が比較的低かった。これらは，特別な知識は不要だが，複数の要素を理解し，正答を推論する問題である。日頃の勉強や実務でも，ネットワーク技術者として，複雑な状況から本質を見極め，課題を解決するという行動パターンを心掛けてほしい。設問4は，“(1)，(2)仮想サーバを含むネットワーク”と，“(3)〜(6)HTTPにおけるTCPコネクション（いわゆるセッション維持）”に関する設問である。どちらも過去に出題したテーマであるが，それらを通じて今回の題材への総合理解を問うた。限られた時間でもよく書けていた解答が多い一方で，“(5)クローズ接続オプションの使い方”や“(6)URLに関する設計指針”については理解不足の解答もやや目立った。本設問では，通常の“TCPコネクション維持によるWebアクセスの応答時間改善”ではなく，“TCPコネクション解放によるファイアウォールの論理資源節約”という，いわば逆の要件になっていることに注意してほしい。
出典：平成27年度 秋期 ネットワークスペシャリスト試験 午後Ⅱ 問1（表記を一部改変）
