応用情報技術者 2019年 秋期 午後 問05
HTTP/2に関する次の記述を読んで、設問1~4に答えよ。
E社は、地域密着型の写真店であり、小学校の運動会や遠足などの行事にカメラマンを派遣し、子供の写真を撮影して販売している。今までは、写真を販売するために、小学校の廊下などに写真のサンプルを掲示し、保護者に購入する写真を選んでもらっていた。しかし、保護者から“インターネットで写真を選びたい”、“写真の電子データを購入したい”との要望が多く寄せられるようになり、インターネット販売用のシステム(以下、新システムという)を開発することにした。新システムの開発は、SIベンダのF社が担当することになった。
新システムの開発は、要件定義、設計、実装と順調に進み、テスト工程における性能テストをF社のG君が担当することになった。
〔新システムの性能要件〕
G君は新システムの性能テストを行うに当たり、要件定義書に記載の性能要件を確認した。図1に新システムの性能要件(抜粋)を示す。

〔性能テストの結果〕
G君は、多数のWebブラウザ(以下、ブラウザという)からのアクセスをシミュレートする負荷テストツールを用いて、開発した新システムの性能テストを行った。
性能テストの結果、同時アクセス数が、32ユーザを超えるとアクセスエラーが発生した。ただし、エラー発生時のサーバのCPU、メモリ、ネットワーク回線の使用率は全て10%以下、ディスクのI/O負荷率は20%以下であった。また、レスポンスタイムは、写真を一覧表示するページ(以下、一覧ページという)の表示が最も長く3.0秒だったが、一枚の写真を拡大表示するページなどの他のページの表示は1.0秒であった。
〔同時アクセス数改善に向けた調査〕
G君は、同時アクセス数の要件を満たせない原因を確認するために、ブラウザの開発者用ツールを用いて、ブラウザが一覧ページの表示に必要なファイルをどのように受信しているか調査した。G君が調査したファイルの受信状況(抜粋)を図2に示す。なお、ブラウザとサーバはHTTP/1.1 over TLS(HTTPS)で通信していた。

次に、G君がサーバのログを調査したところ、TCPコネクションを確立できないという内容のログが多く残っていた。この結果からG君は、TCP/IPでサーバとブラウザが通信を行うために必要なサーバのaが枯渇し、新たなTCPコネクションを確立できなくなったと考えた。また、サーバのaの最大数は128に設定されていた。
この二つの調査結果から、①ブラウザが採用する複数のファイルを並行して受信するための手法によって、同時アクセス数が制限されてしまっていることが分かった。
〔レスポンスタイム改善に向けた調査〕
G君は、一つのTCPコネクション内における、ブラウザとサーバの間の通信を調査した。HTTP/1.1 over TLSを用いてブラウザとサーバが通信するとき、ブラウザからサーバのb番ポートに対してcを送信し、サーバからdを返信する、最後にブラウザからeを送信することでTCPコネクションが確立する。その後 TLS ハンドシェイクを行い、ブラウザは HTML ファイルや画像ファイルなどをサーバへ要求し、サーバは要求に応じてブラウザへファイルを送信している(図3)。また、G君が利用したブラウザでは、HTTP パイプライン機能はオフになっていた。

G君は、この結果から、②TCP コネクション内での画像ファイルの取得に掛かる時間が長くなり、多くの画像データを含む一覧ページではレスポンスタイムが長くなると考えた。
〔HTTP/2 を用いた新システムの開発〕
G君が調査結果を上司の H 課長に報告したところ “HTTP/2 の利用を検討すること” とのアドバイスを得た。HTTP/2 では、③一つのTCPコネクションを用いて、複数のファイルを並行して受信するストリームという仕組みなど、多くの新しい仕組みが追加されていることが分かった。
そこで、G君は新システムのWebサーバに HTTP/2 の設定を行い、再度性能テストを実施した。その結果、新システムが図1の性能要件を満たしていることが確認できた。
その後、新システムの開発は完了し、E社は写真のインターネット販売を開始した。
設問1:〔同時アクセス数改善に向けた調査〕について(1)、(2)に答えよ。
(1)本文中のaに入れる適切な字句を解答群の中から選び、記号で答えよ。
解答群
ア:IPアドレス
イ:ソケット
ウ:プロセス
エ:ポート
模範解答
a:イ
解説
解答の論理構成
- 【問題文】には
“TCP/IPでサーバとブラウザが通信を行うために必要なサーバのaが枯渇し、新たなTCPコネクションを確立できなくなった”
とあります。 - TCP コネクション確立時には、OS が “IPアドレス+ポート番号” の組を一意に識別する ソケット を生成します。コネクションごとにソケット資源(ファイルディスクリプタなど)が消費されるため、上限を超えると新規接続を受け付けられません。
- 【問題文】に “サーバのaの最大数は128に設定” とある上限値は、/proc/sys/net/core/somaxconn などで代表される ソケット待ち受けキュー(backlog) の典型的な既定値と一致します。
- 他の選択肢との比較
- “IPアドレス” は 1 つのサーバが複数保有できても枯渇まで 128 という桁は非現実的です。
- “ポート” は 0~65535 と多く、しかも HTTPS は “443” を共用するため上限 128 とは対応しません。
- “プロセス” は Web サーバの設定次第で増減しますが、TCP コネクション確立自体の必須要素ではありません。
- 以上より、a には “ソケット” が最適であり、解答群の “イ” が正解になります。
誤りやすいポイント
- “同じ 443 番ポートなのに上限 128 で接続拒否=ポート不足” と早合点する。実際はポートではなく ソケット資源 が足りない現象です。
- “プロセス/スレッド数の上限” と混同する。プロセスはアプリケーション実装依存、ソケットは OS が TCP で必ず確保する点が異なります。
- “HTTP/1.1 の同時接続数制限” と “ソケット上限” を同一視する。前者はブラウザ側の実装制限、後者はサーバ OS のリソース制限です。
FAQ
Q: ソケットの上限を超えると具体的にどんなログが残りますか?
A: Linux 系なら tcp: drop open request や connection reset by peer、Web サーバ側なら “cannot accept connection: Too many open files” などのエラーが記録されます。
A: Linux 系なら tcp: drop open request や connection reset by peer、Web サーバ側なら “cannot accept connection: Too many open files” などのエラーが記録されます。
Q: backlog 値を 128 から増やすだけで性能要件を満たせますか?
A: 単純に上限を引き上げても、CPU コンテキストスイッチや TLS ハンドシェイクがボトルネックになる場合があります。HTTP/2 のように 単一コネクションの多重化 を併用する方が効果的です。
A: 単純に上限を引き上げても、CPU コンテキストスイッチや TLS ハンドシェイクがボトルネックになる場合があります。HTTP/2 のように 単一コネクションの多重化 を併用する方が効果的です。
Q: Windows など他の OS でも “ソケット上限 128” という値は共通ですか?
A: 既定値は OS ごとに異なりますが “百数十件” がデフォルトという点はおおむね共通です。必要に応じてレジストリやカーネルパラメータで調整できます。
A: 既定値は OS ごとに異なりますが “百数十件” がデフォルトという点はおおむね共通です。必要に応じてレジストリやカーネルパラメータで調整できます。
関連キーワード: ソケット、backlog, TCPコネクション、リソース枯渇、HTTPS
設問1:〔同時アクセス数改善に向けた調査〕について(1)、(2)に答えよ。
(2)本文中の下線①について、図2の調査で分かった、複数のファイルを並行して受信するための手法とは、どのような手法か。25字以内で述べよ。
模範解答
同時に複数のTCPコネクションを確立する手法
解説
解答の論理構成
- 問題文にはブラウザが「HTTP/1.1 over TLS(HTTPS)」で通信しているとあります。HTTP/1.1 では 1 本のコネクション上で順次リクエストを行うのが原則ですが、待ち時間短縮のためにブラウザ側で別の仕組みが導入されています。
- 図2を見ると、image001.jpg と image005.jpg など複数のファイルが“ほぼ同じ時間帯”に受信されています。これはブラウザが 同時並行に複数のデータを取得 している証拠です。
- 同時並行取得の結果、サーバ側では「TCPコネクションを確立できないという内容のログ」が多数発生し、さらに「サーバのaの最大数は128に設定されていた」と記載されています。つまりブラウザが短時間に多数のコネクションを張るため、サーバで許可されたコネクション上限に早々に到達してしまったわけです。
- ここから①で問われる“複数のファイルを並行して受信するための手法”とは、HTTP/1.1 の世界で一般的に行われる「同時に複数のTCPコネクションを張ってリソースを並列ダウンロードする方法」だと帰着します。
- 以上により解答は「同時に複数のTCPコネクションを確立する手法」となります。
誤りやすいポイント
- HTTP/1.1 の機能と思い込み「HTTPパイプライン」と書いてしまう。本文では「HTTP パイプライン機能はオフ」と明示されており該当しません。
- 「ストリーム」「マルチプレックス」など HTTP/2 の用語を挙げる。①は HTTP/1.1 の挙動を指しているため不適切です。
- 「ポートを増やす」などサーバ設定側の対策を書いてしまい、手法そのものを答えていないケース。
FAQ
Q: ブラウザは具体的に何本くらいの TCP コネクションを張るのですか?
A: 多くのブラウザは同一ドメインにつき 6〜8 本程度を上限に並列接続します(実装依存)。
A: 多くのブラウザは同一ドメインにつき 6〜8 本程度を上限に並列接続します(実装依存)。
Q: HTTP/2 を導入するとコネクションは 1 本で済むのですか?
A: 基本的に「一つの TCP コネクション」で多数のリソースを多重化して送受信します。ただし HTTP/1.1 との並存時などに備えて複数張るケースもあります。
A: 基本的に「一つの TCP コネクション」で多数のリソースを多重化して送受信します。ただし HTTP/1.1 との並存時などに備えて複数張るケースもあります。
Q: サーバ側の a を増やせば HTTP/1.1 のままでもよいのでは?
A: コネクション上限を増やすとメモリ負荷や OS の同時ハンドル数上限に達する懸念があり、本質的な解決はプロトコル面(HTTP/2 など)での多重化が推奨されます。
A: コネクション上限を増やすとメモリ負荷や OS の同時ハンドル数上限に達する懸念があり、本質的な解決はプロトコル面(HTTP/2 など)での多重化が推奨されます。
関連キーワード: HTTP/1.1, TCPコネクション、並列ダウンロード、コネクション制御、TLSハンドシェイク
設問2:本文及び図3中のb中から選び、記号で答えよ。
b〜eに入れる適切な字句を解答群の中から選び、記号で答えよ。
解答群
ア:25
イ:110
ウ:443
エ:ACK
オ:ACK/FIN
カ:FIN
キ:SYN
ク:SYN/ACK
ケ:TCP
模範解答
b:ウ
c:キ
d:ク
e:エ
解説
解答の論理構成
- 【問題文】には
“ブラウザからサーバのb番ポートに対してcを送信し、サーバからdを返信する、最後にブラウザからeを送信することで TCP コネクションが確立する”
とあります。ここでは TCP 3 ウェイハンドシェイクの手順がそのまま説明されています。 - TCP 3 ウェイハンドシェイクは
① クライアント → サーバ:SYN
② サーバ → クライアント:SYN/ACK
③ クライアント → サーバ:ACK
で確立します。したがって
・c=SYN(キ)
・d=SYN/ACK(ク)
・e=ACK(エ)
となります。 - HTTPS のサーバ側待受ポートは標準で “443” です。選択肢で “443” に該当するのは ウ なので
・b=443(ウ)
となります。 - 以上より
b:ウ
c:キ
d:ク
e:エ
が妥当で、模範解答とも一致します。
誤りやすいポイント
- HTTP と HTTPS のポートを取り違え、「80」を選んでしまう。HTTPS であれば “443” が正解です。
- 3 ウェイハンドシェイクの 2 番目に “ACK” だけを返すと誤認しやすいですが、正しくは “SYN/ACK” です。
- “FIN” 系フラグは切断時に使うもので、接続確立時には出てこない点を見落としがちです。
FAQ
Q: 図3 に “get index.html” があるのに c が SYN なのはなぜですか?
A: “get index.html” は TCP コネクション確立後の HTTP 要求です。まず SYN → SYN/ACK → ACK で TCP を確立し、その後に HTTP メッセージが流れます。
A: “get index.html” は TCP コネクション確立後の HTTP 要求です。まず SYN → SYN/ACK → ACK で TCP を確立し、その後に HTTP メッセージが流れます。
Q: なぜ HTTP/2 にすると同時アクセス数やレスポンスタイムが改善するのですか?
A: HTTP/2 は “一つの TCP コネクションを用いて、複数のファイルを並行して受信するストリーム” を利用できるため、TCP コネクション数の増加や待ち行列が発生しにくくなります。
A: HTTP/2 は “一つの TCP コネクションを用いて、複数のファイルを並行して受信するストリーム” を利用できるため、TCP コネクション数の増加や待ち行列が発生しにくくなります。
Q: FIN と ACK/FIN の違いは?
A: “FIN” は送信側がこれ以上データを送らない意思を表す単独フラグ、“ACK/FIN” は FIN と同時に相手からのデータ受領確認(ACK)も兼ねる複合フラグです。接続終了時の方向によって使い分けます。
A: “FIN” は送信側がこれ以上データを送らない意思を表す単独フラグ、“ACK/FIN” は FIN と同時に相手からのデータ受領確認(ACK)も兼ねる複合フラグです。接続終了時の方向によって使い分けます。
関連キーワード: TCP三者ハンドシェイク、HTTPS, ポート番号、SYNフラグ、ACKフラグ
設問3:
本文中の下線②について、TCPコネクション内での画像ファイルの取得に時間が掛かる要因は何か。解答群の中から選び、記号で答えよ。
解答群
ア:画像ファイルの取得ごとにTCPコネクションを確立している。
イ:画像ファイルを圧縮せずに取得している。
ウ:画像ファイルを一つずつ順番にサーバに要求し取得している。
エ:複数の画像ファイルをまとめて取得している。
模範解答
ウ
解説
解答の論理構成
- 問題文は、画像取得の遅延原因を調べた結果として
「ブラウザは **HTML ファイルや画像ファイルなどをサーバへ要求し、サーバは要求に応じてブラウザへファイルを送信している(図3)。また、G 君が利用したブラウザでは、HTTP パイプライン機能はオフになっていた。」
と述べています。 - HTTP パイプライン機能 がオフの場合、HTTP/1.1 接続内では次の特性が発生します。
- 1つのリクエストを送信し、そのレスポンスを受信し終えるまで 次のリクエストを送れない。
- したがって画像を複数枚取得する際は「リクエスト → レスポンス」を ファイルごとに逐次 行う。
- これにより問題文の下線②が指摘する「TCP コネクション内での画像ファイルの取得に掛かる時間」が伸び、一覧ページ全体の表示が遅くなります。
- 解答群を照合すると、この状況を直接表すのは
「ウ:画像ファイルを一つずつ順番にサーバに要求し取得している。」
となります。他の選択肢は下記の通り原因と合致しません。- ア:同じ TCP コネクションを再利用しているため該当せず。
- イ:圧縮の有無は触れられていない。
- エ:取得をまとめていれば遅延は起こりにくい。
- よって模範解答「ウ」が妥当です。
誤りやすいポイント
- 「HTTP/1.1 =同時並列取得可能」と思い込み、HTTP パイプライン機能の設定を見落とす。
- 図3の矢印列だけを見て「複数ファイルをまとめて送っている」と早合点する。
- 接続数の枯渇問題(a)と、1コネクション内の逐次転送問題(下線②)を混同する。
FAQ
Q: HTTP/1.1 でもパイプラインをオンにすれば並列になるのですか?
A: パイプラインをオンにするとリクエストは送信側で連続して送れますが、レスポンスは順序保証のため結局“到着順は1本ずつ”です。本質的な並列化には HTTP/2 のストリームが有効です。
A: パイプラインをオンにするとリクエストは送信側で連続して送れますが、レスポンスは順序保証のため結局“到着順は1本ずつ”です。本質的な並列化には HTTP/2 のストリームが有効です。
Q: 画像をまとめて取得できる「スプライト」技法でも解決できますか?
A: 可能ですが、画像編集やキャッシュ制御の手間が増えます。HTTP/2 ならプロトコル側で並列化できるため運用が容易です。
A: 可能ですが、画像編集やキャッシュ制御の手間が増えます。HTTP/2 ならプロトコル側で並列化できるため運用が容易です。
Q: HTTP/3 を導入すれば接続枯渇と遅延は一気に解決しますか?
A: QUIC を利用するため接続確立は高速化しますが、サーバとブラウザ双方の対応状況やファイアウォール設定など追加検討事項があります。
A: QUIC を利用するため接続確立は高速化しますが、サーバとブラウザ双方の対応状況やファイアウォール設定など追加検討事項があります。
関連キーワード: HTTP/1.1, パイプライン、TCPハンドシェイク、ストリーム、レスポンスタイム
設問4:本文中の下線③について、(1)、(2)に答えよ。
(1)複数のファイルを並行して受信可能となることで、ブラウザのどのような待ち時間がなくなるか。20字以内で答えよ。
模範解答
前の画像ファイルの受信完了待ち
解説
解答の論理構成
- 【問題文】には、HTTP/1.1 通信の様子として
「ブラウザは HTML ファイルや画像ファイルなどをサーバへ要求し、サーバは要求に応じてブラウザへファイルを送信している(図3)。また、G君が利用したブラウザでは、HTTP パイプライン機能はオフ」
とあります。図3のシーケンスも
「get image001.jpg」→「image001.jpg」→「get image002.jpg」→「image002.jpg」
という“1 ファイルずつ”の繰返しを示しています。 - このため、次の画像を要求する前に「前の画像の受信が完了するまで待つ」必要があり、【問題文】はこれを
「②TCP コネクション内での画像ファイルの取得に掛かる時間が長くなり、多くの画像データを含む一覧ページではレスポンスタイムが長くなる」
と説明しています。 - 下線③は
「③一つの TCP コネクションを用いて、複数のファイルを並行して受信するストリーム」
と述べ、HTTP/2 で“並行受信”が可能になる点を強調しています。 - 並行受信が可能になれば、画像を 順番に 処理していた HTTP/1.1 の制約――すなわち「前の画像の受信が終わるのを待つ」時間――が消滅します。
- 以上より、設問が尋ねる「ブラウザのどのような待ち時間がなくなるか」は
「前の画像ファイルの受信完了待ち」
となります。
誤りやすいポイント
- “TCP コネクション確立待ち”や“TLS ハンドシェイク待ち”と答えてしまう
→ HTTP/2 でも最初の 1 コネクションを張る工程は残るため誤答です。 - 「キュー待ち」「リクエスト待ち」など抽象的な表現にすると採点基準に届かない恐れがあります。
- パイプライン機能をオンにすれば同じ効果が得られると誤解しがちですが、【問題文】は「HTTP パイプライン機能はオフ」と明示しており、HTTP/2 のストリーム機構が根本解決策である点を押さえる必要があります。
FAQ
Q: HTTP/2 にするとコネクション数は必ず1本になりますか?
A: ブラウザ実装やサーバ設定によっては複数コネクションを張る場合もありますが、基本設計は「1コネクションで多重化」です。
A: ブラウザ実装やサーバ設定によっては複数コネクションを張る場合もありますが、基本設計は「1コネクションで多重化」です。
Q: 画像以外の CSS や JavaScript でも同じ待ち時間が発生しますか?
A: はい。HTTP/1.1 ではリクエストを直列発行するため、サイズの大きいリソースは同様のボトルネックになります。
A: はい。HTTP/1.1 ではリクエストを直列発行するため、サイズの大きいリソースは同様のボトルネックになります。
Q: HTTP/2 以外で待ち時間を減らす方法はありますか?
A: 画像のスプライト化・バンドルなどリクエスト数自体を削減する手法が従来からありますが、ファイル結合が難しい場合は HTTP/2 が効果的です。
A: 画像のスプライト化・バンドルなどリクエスト数自体を削減する手法が従来からありますが、ファイル結合が難しい場合は HTTP/2 が効果的です。
関連キーワード: HTTP/1.1, HTTP/2, TLS, TCPコネクション、多重化
設問4:本文中の下線③について、(1)、(2)に答えよ。
(2)HTTP/2の採用によって、新システムが許容できる最大の同時アクセス数は幾つになるか答えよ。ここで、新システムにアクセスする全てのブラウザがHTTP/2を利用し、一つのTCPコネクションを用いてアクセスするものとする。
模範解答
128
解説
解答の論理構成
-
サーバ側資源の上限を確認
問題文に「サーバのaの最大数は128に設定されていた。」と明記されています。
ここで a は TCP コネクション確立に必要なサーバ側の資源であり、上限値 128 が同時に保持できる TCP コネクション数の物理的限界となります。 -
HTTP/1.1 時の制限要因
ブラウザは「①ブラウザが採用する複数のファイルを並行して受信するための手法」として、1 ユーザあたり複数の TCP コネクションを張ります。
そのため 1 ユーザ=1 コネクション ではなく、32 ユーザ程度で上限 128 に達しエラーが発生したわけです。 -
HTTP/2 導入後の接続方式
HTTP/2 では 「③一つの TCP コネクションを用いて、複数のファイルを並行して受信するストリーム」 を採用します。
問題文の前提でも「一つのTCPコネクションを用いてアクセスする」と指定されています。
したがって 1 ユーザあたり必要な TCP コネクションは 1 本になります。 -
同時アクセス数の算出
サーバが同時に保持できる TCP コネクション総数が 128、1 ユーザが占有するコネクションが 1 本なのでよって、HTTP/2 採用後に新システムが許容できる最大の同時アクセス数は 128 ユーザとなります。
誤りやすいポイント
- HTTP/2 でもブラウザが複数コネクションを張ると誤解し、128 をさらに割り算してしまう。
- a を「ポート番号の総数」と読み違え、65,535 などの値で計算を始めてしまう。
- ストリーム=コネクションと混同し、ストリーム数の理論上限をそのままユーザ数と思い込む。
FAQ
Q: HTTP/2 では 1 ユーザが必ず 1 本の TCP コネクションしか使わないのですか?
A: 仕様上は 1 本で十分ですが、ブラウザ実装によっては複数コネクションを開く場合もあります。本問では「一つのTCPコネクションを用いてアクセスする」と条件が与えられているため 1 本として計算します。
A: 仕様上は 1 本で十分ですが、ブラウザ実装によっては複数コネクションを開く場合もあります。本問では「一つのTCPコネクションを用いてアクセスする」と条件が与えられているため 1 本として計算します。
Q: サーバのaを 256 に変更すれば同時アクセス数も 256 になりますか?
A: 問題文の前提を変えれば理論上は可能です。ただし CPU・メモリ・帯域など他のボトルネックが顕在化する可能性があるため、単純にリミット値を上げればよいとは限りません。
A: 問題文の前提を変えれば理論上は可能です。ただし CPU・メモリ・帯域など他のボトルネックが顕在化する可能性があるため、単純にリミット値を上げればよいとは限りません。
Q: HTTP/2 のストリーム数に上限はありますか?
A: プロトコルとしては設定可能な上限値(デフォルトは 100 前後)があり、設定次第で増減できます。ただし本問はストリーム数ではなく TCP コネクション数制限がテーマです。
A: プロトコルとしては設定可能な上限値(デフォルトは 100 前後)があり、設定次第で増減できます。ただし本問はストリーム数ではなく TCP コネクション数制限がテーマです。
関連キーワード: HTTP/2, TCPコネクション、マルチプレックス、ストリーム、ソケット資源


