応用情報技術者 2019年 秋期 午後 問05

解答の導き方

1. 問題文から事実を整理します。問題文には「同時アクセス数が、32ユーザを超えるとアクセスエラーが発生した」とあり、同時に「エラー発生時のサーバのCPU、メモリ、ネットワーク回線の使用率は全て10％以下、ディスクのI/O負荷率は20％以下」とあります。これにより、CPUやメモリなどの汎用的な資源の枯渇が原因ではないと判断できます。
2. 図2と本文の記述からブラウザの振る舞いを読み取ります。図2の黒帯が複数の画像で重なっていること、そして本文の「HTTPパイプライン機能はオフになっていた。」という記述から、HTTP/1.1環境ではブラウザがパイプラインを使わずに複数のファイルを並行して取得するために、クライアントごとに複数のTCPコネクションを確立していると考えられます。
3. サーバ側のリソース対応を考えます。TCPコネクションが確立されると、サーバ側ではその接続ごとにソケット（≒ソケット構造体とそれに対応するファイルディスクリプタ）を割り当てます。問題文には「TCPコネクションを確立できないという内容のログが多く残っていた」とあり、さらに「サーバのaの最大数は128に設定されていた。」とあります。複数のクライアントがそれぞれ複数のTCPコネクションを張ると、サーバ上で割り当てるソケット数の総和が増え、設定された上限（128）を超えると新しいTCPコネクションが確立できなくなる、という状況と一致します。例えばブラウザがユーザ当たり4本程度の同時TCPコネクションを張る動作をしているとすれば、32ユーザ×4接続＝128ソケットで上限に達し、32ユーザを超えた時点で接続失敗が出る説明に整合します（図2の並列受信の様子と合わせて考えると自然な説明です）。
4. 選択肢を消去して確定します。

• ア：IPアドレス — サーバが持つIPアドレスは通常1つか少数で、接続ごとに消費される資源ではなく「最大数128に設定」という記述とは合いません。
• ウ：プロセス — 一部のサーバ（preforkモデル）では接続ごとにプロセスを割り当てる設計もあり得ますが、問題文はCPU/メモリ使用率が低いことを示しており、かつ「TCPコネクションを確立できない」というログと「128」という上限の記述からはソケット資源の枯渇を指すと解釈する方が直接的です。
• エ：ポート — サーバは通常1つのリスニングポート（例：443）で多数の接続を受けられるため、「ポート」が接続ごとに消費されて128個で足りなくなるという説明は成り立ちません（エフェメラルポートは主にクライアント側の問題です）。

誤りやすいポイント

• backlog（待ち受けキュー）とソケット（ファイルディスクリプタや確立済みソケット数）を混同する
  • backlogはlisten() に渡す待ち受けキュー長で、接続要求の待ち行列長を制御します。backlogが溢れると接続要求がドロップされたり拒否されたりして「接続できない」外観になるため混同しやすいですが、backlogは「キュー長」であって「既に割り当てられたソケット数」や「プロセス／ファイルディスクリプタ上限」とは別概念です。
• ポート枯渇と誤解する
  • サーバ側のリスニングポートは1つ（あるいはごく少数）であり、接続ごとに新しいサーバポートを消費するわけではありません。クライアント側のエフェメラルポート枯渇とは異なります。
• プロセス数と混同する
  • 一部のサーバ構成では接続ごとにプロセスやスレッドを生成するためプロセス数がボトルネックになることはありますが、問題文の示す低CPU/低メモリの状況や「TCPコネクションに対するログ」からはソケット資源の方が直接の原因であると読み取るほうが妥当です。
• 図の読み取りミス（並列転送＝必ずしも1接続／1ファイルとは限らない点）
  • 図2の黒帯はファイル受信中を示しますが、HTTP/1.1でパイプラインがオフの場合は並行取得のために複数コネクションを張るブラウザが多い、という点を本文の記述と合わせて判断してください。

FAQ

解答の論理構成

1. 問題文にはブラウザが「HTTP/1.1 over TLS（HTTPS）」で通信しているとあります。HTTP/1.1では1本のコネクション上で順次リクエストを行うのが原則ですが、待ち時間短縮のためにブラウザ側で別の仕組みが導入されています。
2. 図2を見ると、image001.jpgとimage005.jpgなど複数のファイルが“ほぼ同じ時間帯”に受信されています。これはブラウザが 同時並行に複数のデータを取得 している証拠です。
3. 同時並行取得の結果、サーバ側では「TCPコネクションを確立できないという内容のログ」が多数発生し、さらに「サーバのaの最大数は128に設定されていた」と記載されています。つまりブラウザが短時間に多数のコネクションを張るため、サーバで許可されたコネクション上限に早々に到達してしまったわけです。
4. ここから①で問われる“複数のファイルを並行して受信するための手法”とは、HTTP/1.1の世界で一般的に行われる「同時に複数のTCPコネクションを張ってリソースを並列ダウンロードする方法」だと帰着します。
5. 以上により解答は「同時に複数のTCPコネクションを確立する手法」となります。

誤りやすいポイント

• HTTP/1.1の機能と思い込み「HTTPパイプライン」と書いてしまう。本文では「HTTPパイプライン機能はオフ」と明示されており該当しません。
• 「ストリーム」「マルチプレックス」などHTTP/2の用語を挙げる。①はHTTP/1.1の挙動を指しているため不適切です。
• 「ポートを増やす」などサーバ設定側の対策を書いてしまい、手法そのものを答えていないケース。

FAQ

解答の論理構成

1. 【問題文】には
   “ブラウザからサーバのb番ポートに対してcを送信し、サーバからdを返信する、最後にブラウザからeを送信することでTCPコネクションが確立する”
   とあります。ここではTCP 3ウェイハンドシェイクの手順がそのまま説明されています。
2. TCP 3ウェイハンドシェイクは
   ① クライアント → サーバ：SYN
   ② サーバ → クライアント：SYN/ACK
   ③ クライアント → サーバ：ACK
   で確立します。したがって
   ・c＝SYN（キ）
   ・d＝SYN/ACK（ク）
   ・e＝ACK（エ）
   となります。
3. HTTPSのサーバ側待受ポートは標準で “443” です。選択肢で “443” に該当するのは ウ なので
   ・b＝443（ウ）
   となります。
4. 以上より
   b：ウ
   c：キ
   d：ク
   e：エ
   が妥当で、模範解答とも一致します。

誤りやすいポイント

• HTTPとHTTPSのポートを取り違え、「80」を選んでしまう。HTTPSであれば “443” が正解です。
• 3ウェイハンドシェイクの2番目に “ACK” だけを返すと誤認しやすいですが、正しくは “SYN/ACK” です。
• “FIN” 系フラグは切断時に使うもので、接続確立時には出てこない点を見落としがちです。

FAQ

解答の論理構成

1. 問題文は、画像取得の遅延原因を調べた結果として
   「ブラウザは **HTMLファイルや画像ファイルなどをサーバへ要求し、サーバは要求に応じてブラウザへファイルを送信している（図3）。また、G君が利用したブラウザでは、HTTPパイプライン機能はオフになっていた。」
   と述べています。
2. HTTPパイプライン機能 がオフの場合、HTTP/1.1接続内では次の特性が発生します。
   • 1つのリクエストを送信し、そのレスポンスを受信し終えるまで 次のリクエストを送れない。
   • したがって画像を複数枚取得する際は「リクエスト → レスポンス」を ファイルごとに逐次 行う。
3. これにより問題文の下線②が指摘する「TCPコネクション内での画像ファイルの取得に掛かる時間」が伸び、一覧ページ全体の表示が遅くなります。
4. 解答群を照合すると、この状況を直接表すのは
   「ウ：画像ファイルを一つずつ順番にサーバに要求し取得している。」
   となります。他の選択肢は下記の通り原因と合致しません。
   • ア：同じTCPコネクションを再利用しているため該当せず。
   • イ：圧縮の有無は触れられていない。
   • エ：取得をまとめていれば遅延は起こりにくい。
5. よって模範解答「ウ」が妥当です。

誤りやすいポイント

• 「HTTP/1.1 ＝同時並列取得可能」と思い込み、HTTPパイプライン機能の設定を見落とす。
• 図3の矢印列だけを見て「複数ファイルをまとめて送っている」と早合点する。
• 接続数の枯渇問題（a）と、1コネクション内の逐次転送問題（下線②）を混同する。

FAQ

解答の論理構成

1. 【問題文】には、HTTP/1.1通信の様子として
   「ブラウザはHTMLファイルや画像ファイルなどをサーバへ要求し、サーバは要求に応じてブラウザへファイルを送信している（図3）。また、G君が利用したブラウザでは、HTTPパイプライン機能はオフ」
   とあります。図3のシーケンスも
   「get image001.jpg」→「image001.jpg」→「get image002.jpg」→「image002.jpg」
   という“1ファイルずつ”の繰返しを示しています。
2. このため、次の画像を要求する前に「前の画像の受信が完了するまで待つ」必要があり、【問題文】はこれを
   「②TCPコネクション内での画像ファイルの取得に掛かる時間が長くなり、多くの画像データを含む一覧ページではレスポンスタイムが長くなる」
   と説明しています。
3. 下線③は
   「③一つのTCPコネクションを用いて、複数のファイルを並行して受信するストリーム」
   と述べ、HTTP/2で“並行受信”が可能になる点を強調しています。
4. 並行受信が可能になれば、画像を 順番に 処理していたHTTP/1.1の制約――すなわち「前の画像の受信が終わるのを待つ」時間――が消滅します。
5. 以上より、設問が尋ねる「ブラウザのどのような待ち時間がなくなるか」は
   「前の画像ファイルの受信完了待ち」
   となります。

誤りやすいポイント

• “TCPコネクション確立待ち”や“TLSハンドシェイク待ち”と答えてしまう
  → HTTP/2でも最初の1コネクションを張る工程は残るため誤答です。
• 「キュー待ち」「リクエスト待ち」など抽象的な表現にすると採点基準に届かない恐れがあります。
• パイプライン機能をオンにすれば同じ効果が得られると誤解しがちですが、【問題文】は「HTTPパイプライン機能はオフ」と明示しており、HTTP/2のストリーム機構が根本解決策である点を押さえる必要があります。

FAQ

解答の論理構成

1. サーバ側資源の上限を確認
   問題文に「サーバのaの最大数は128に設定されていた。」と明記されています。
   ここで a はTCPコネクション確立に必要なサーバ側の資源であり、上限値 128 が同時に保持できるTCPコネクション数の物理的限界となります。
2. HTTP/1.1時の制限要因
   ブラウザは「①ブラウザが採用する複数のファイルを並行して受信するための手法」として、1ユーザあたり複数のTCPコネクションを張ります。
   そのため1ユーザ＝1コネクション ではなく、32ユーザ程度で上限128に達しエラーが発生したわけです。
3. HTTP/2導入後の接続方式
   HTTP/2では 「③一つのTCPコネクションを用いて、複数のファイルを並行して受信するストリーム」 を採用します。
   問題文の前提でも「一つのTCPコネクションを用いてアクセスする」と指定されています。
   したがって1ユーザあたり必要なTCPコネクションは 1 本になります。
4. 同時アクセス数の算出
   サーバが同時に保持できるTCPコネクション総数が 128、1ユーザが占有するコネクションが 1 本なので
   $$\text{許容最大同時ユーザ数}=\frac{128}{1}=128$$
   よって、HTTP/2採用後に新システムが許容できる最大の同時アクセス数は 128 ユーザとなります。

誤りやすいポイント

• HTTP/2でもブラウザが複数コネクションを張ると誤解し、128をさらに割り算してしまう。
• a を「ポート番号の総数」と読み違え、65,535などの値で計算を始めてしまう。
• ストリーム＝コネクションと混同し、ストリーム数の理論上限をそのままユーザ数と思い込む。

FAQ