基本情報 2022 サンプル問題 問15：テクノロジ系に関する問題

答えは d「L ≧ (S − R) × T」 です。

バッファは 「水を貯めるバケツ」、送信は蛇口、受信はバケツの底にある排水口だと考えます。

• 送信(S): 蛇口から1秒あたりSリットル入ってくる
• 受信(R): 排水口から1秒あたりRリットル抜けていく
• 時間T秒間、蛇口を出しっぱなしにする

送信の方が速い(S > R)ので、毎秒 「S − R」リットル ずつ水が貯まっていく。

T秒たつと (S − R) × T リットル 貯まる。

バケツがあふれない(オーバーフローしない)ためには、バケツの容量Lがこの貯まる量以上必要:

L ≧ (S − R) × T

👉 覚え方: 「速さの差 × 時間 = 貯まる量」。バケツはそれ以上の大きさが必要!

ほかの選択肢: a・bは「<」を使ってる(あふれる条件)、cは順序が逆(R−Sだと負の数)で誤り。

なぜこれが正解か

正解は d「L ≧ (S − R) × T」。

バッファの蓄積量を計算する:

• 単位時間あたりの送受信差: S − R(送信が速いので正の値)
• T 秒間の累積バッファ蓄積量: (S − R) × T

オーバーフローしない条件は バッファサイズが累積蓄積量以上:

L ≧ (S − R) × T

等号を含むのは「ちょうど一杯までは許容」を意味する。

各選択肢の解説

• a「L < (R − S) × T」: R<S なので右辺は負の値、L < 負の値 は実現不能。
• b「L < (S − R) × T」: 不等号が逆。L が累積量より小さければオーバーフローする条件であり、防止条件ではない。
• c「L ≧ (R − S) × T」: R−S は負の値なので、L ≧ 負の値 は常に成立し意味を持たない条件式。

覚え方・ひっかけ注意

「速い方 − 遅い方」の順を守る: 送信の方が速いので必ず S − R(正の値)。R − S と書くと負の値になり論理破綻。

不等号の向き: 「あふれない条件」= 「バッファ容量が蓄積量以上」 → L ≧ ○○。問題文が「あふれる条件」と「あふれない条件」のどちらを問うているかを正確に読む。

「次の転送開始までの時間間隔は十分にある」 という条件は、T秒経過後に受信が追いつくまでバッファに余裕がある状態で次転送が始まることを保証している。これにより問題が「T秒間連続送信」の一回のみで完結する。

バッファリングとフロー制御の理論

本問は 生産者-消費者問題 の単純化版。送信速度が受信速度を超える非対称環境で速度差を吸収する キュー/リングバッファ のサイジング問題。

キュー理論との関係

• 利用率 ρ = λ/μ(λ=到着率、μ=サービス率)
• ρ ≥ 1 で無限バッファでも発散(本問は有限時間Tに限定されるため有限Lで吸収可能)
• M/M/1 平均キュー長: L_q = ρ²/(1−ρ)

本問は ρ=S/R>1 の状態で T 秒運用するため、`(S−R)×T` という決定論的近似で必要バッファが決まる。

通信プロトコルでの実装

• TCP スライディングウィンドウ: 受信側が受信ウィンドウサイズを広告し、送信側がそれを超えないことでオーバーフロー防止。
• TCP 輻輳制御: Reno/Cubic/BBR 等が網全体の混雑を検知して送信速度調整。
• PAUSE フレーム(802.3x): 受信側がリンクパートナーに送信停止要求。
• USB NAK: 受信バッファ満杯時に NAK を返してリトライ要求。

OS/アプリ階層

• ソケットバッファ: SO_SNDBUF / SO_RCVBUF。Linux 既定 64〜128KB。
• リングバッファ: head/tail ポインタで管理。組込みで多用。
• バックプレッシャ: 受信側が処理しきれない時に送信側へ調整要求。RxJava/Akka Stream/Reactor で標準サポート。

動画ストリーミングへの応用

本問の構造は ストリーミング初期バッファリング と本質的に同じ。YouTube/Netflix の再生開始前バッファは、ネットワーク変動による瞬時帯域低下を吸収する「マージン量×時間」。HLS/DASH の Adaptive Bitrate Streaming は状況に応じてビットレート動的切替でバッファ枯渇を防ぐ。

試験での位置づけ

システム構成・性能領域の頻出単元。基本情報技術者試験では式選択+数値計算が定番。応用情報以降では M/M/1, M/M/c の平均応答時間計算、ジッタバッファ設計まで踏み込む。

選択肢の発展補足

• ゼロコピー: Linux sendfile()/splice() でバッファコピー回避、CPU 負荷削減。
• ダブルバッファリング: Vulkan/DirectX スワップチェーン、組込みLCD で必須。
• High/Low Watermark: Kafka/Redis Streams 等で送受信制御に2閾値を使い、遅延と性能を両立。