こんにちは！国内外の最新ネットワーク技術やセキュリティの動向を追いかけている、技術メディア主筆ライターのサイバー・スペシャリストです。
普段、私たちが何気なくスマートフォンでウェブサイトを見たり、動画を楽しんだりしている裏側では、何十万、何百万という小さなデータの塊（パケット）が、目にも留まらぬ速さでインターネットを行き来しています。
しかし、ネットワークはいつも万全な状態とは限りません。時には、通り道が混雑してパケットが途中で消えてしまう「パケットロス」が発生することもあります。そんな時、私たちのコンピュータは裏側でどうやってデータを守り、届けているのでしょうか？
今回は、インターネット通信の主役である 「TCP（Transmission Control Protocol）」 が持つ、最も美しく、そして人間味あふれる思いやりに満ちた仕組み「再送制御アルゴリズム（RTO算出と指数バックオフ）」について、難しい専門用語をできる限り身近な例え話に置き換えて、一歩ずつ丁寧に紐解いていきましょう！
—
1. パケットが届かない！そのときTCPはどうする？
インターネットの通信規格であるTCPは、「送ったデータが相手に確実に届いたか」を常に確認し、もし届いていなければ送り直す、とても過保護で責任感の強いプロトコルです。
まずは、この「確認」と「送り直し」の基本を、現実世界の「書留郵便」に例えてみてみましょう。
「届いたよ」の返事（ACK）を待つ
あなたが友達に大切な書類を書留で送ったとします。友達の家に書類が無事に届くと、郵便局からあなたのもとに「お届け完了」のはがきが戻ってきますよね。
ネットワークの世界でも全く同じことが行われています。
1. 送信元（あなた）が、受信先（友達）にパケットを送る。
2. 受信先は、パケットを受け取ったら「無事に届いたよ！」という返事のパケットを送り返す。
この「届いたよ」という返事のことを、専門用語で ACK（アック：Acknowledgement） と呼びます。
[送信元] ------------------- (データ送信) ------------------> [受信先]
[送信元] <------------------ (届いたよ！: ACK) -------------- [受信先]いつまで待てばいい？（RTOの登場）
もし、送ったパケットが途中で迷子になって消えてしまったらどうなるでしょうか？
受信先には何も届かないので、当然「届いたよ（ACK）」の返事も戻ってきません。
送信元であるあなたは、返事が来ないことを察知して、もう一度同じデータを送り直す（再送する）必要があります。しかし、ここで大きな疑問が生まれます。
「一体、何秒待ってから送り直せばいいのでしょうか？」
あまりに早く送り直すと、単に遠い国からの返事が遅れているだけなのに、同じデータを何重にも送ってしまうことになり、無駄が発生します。
逆に、いつまでも待ちすぎると、通信が途切れてフリーズしたように見え、ユーザーをイライラさせてしまいます。
この「再送するまでに待つ限界の時間」のことを、RTO（Retransmission Timeout：再送タイムアウト） と呼びます。
—
2. RTO（再送タイマー）はどうやって決まる？「動的算出」の魔法
では、この RTO（待ち時間）は、あらかじめ「3秒」とか「5秒」のように決まった値がセットされているのでしょうか？
答えは 「ノー」 です。ネットワークの状況は、生き物のように刻一刻と変化しているからです。
往復時間（RTT）を測る
近所のコンビニに手紙を送るのと、地球の反対側のブラジルに手紙を送るのとでは、返事が戻ってくるまでの時間が全く違いますよね。
そこでTCPは、通信をしながら常に「パケットを出してから、返事（ACK）が返ってくるまでの時間」をストップウォッチで計測しています。この実測時間のことを RTT（Round Trip Time：往復時間） と言います。
- 近所のサーバーと通信している時：
RTTは数ミリ秒（とても速い！） - 海外のサーバーや電波の悪いWi-Fiの時：
RTTは数百ミリ秒（ちょっと遅い）
天気の変化を予測するように計算する
TCPは、この計測した RTT を使って、次に待つべき時間（RTO）を計算します。
「さっきは 0.1秒 で返ってきたから、次は 0.12秒 くらい待って返ってこなければ、迷子になったと判断しよう」という具合です。
ただ、ネットワークの速度は突発的に遅くなることもあります。1回だけ偶然遅かったからといって、すぐにタイムアウト時間を極端に変えてしまうと、通信が不安定になってしまいます。
そこで、TCPは「これまでの平均的な往復時間」と「どれくらいバラつき（ブレ）があるか」を高度な数式（代表的なものに Jacobsons/Karels アルゴリズムなどがあります）を使って計算し、最適な RTO を動的に弾き出しているのです。
専門的な数式は覚える必要はありませんが、イメージとしては「最近の気温の平均値と、日々の気温の激しい変化（ブレ）を考慮して、明日着る服（待ち時間）を決める」ような、とても賢い予測が行われていると理解してくださいね。
—
3. 大渋滞を救う「指数バックオフ」という思いやり
さて、ここからが今回のハイライトです。
もし、ネットワークのルーターが故障したり、アクセスが集中して「大渋滞（輻輳：ふくそう）」が起きていたらどうなるでしょうか？
パケットが全く届かなくなり、送信元にはいくら待っても ACK が返ってきません。
火に油を注いではいけない
パケットが届かないからといって、送信元が「届かない！」「これでもか！」と、短い間隔で同じパケットを大量に再送し続けたらどうなるでしょう？
ただでさえ大渋滞で苦しんでいるネットワークの道路に、さらに大量の車を送り込むようなものです。道路は完全にマヒして、通信は完全にクラッシュしてしまいます。
そこで登場するのが、「指数バックオフ（Exponential Backoff）」 というアルゴリズムです。
「少し頭を冷やして、待つ時間を2倍にしていこう」
指数バックオフの考え方は、人間関係のスマートな気遣いに似ています。
忙しくて電話に出られない相手に対して、1分おきに何度も電話をかけまくったら嫌われますよね。普通は、
- 「出ないな。じゃあ次は 2分後 にかけよう」
- 「まだ出ないな。次は 4分後 にしよう」
- 「うーん、本当に忙しそうだ。次は 8分後 にしよう」
というように、相手を気遣って次に電話をかけるまでの間隔をどんどん延ばしていきますよね。
TCPもこれと全く同じことを行います。パケットを再送しても返事がない場合、再送タイマー（RTO）の値を、2倍、4倍、8倍、16倍… と、指数関数的に引き伸ばしていくのです。
【指数バックオフの流れ】
1回目の送信 ────× (届かない！)
↓ [RTO：1秒待つ]
2回目の再送 ────× (まだ届かない！)
↓ [RTO：2秒待つ (2倍！)]
3回目の再送 ────× (やっぱり届かない！)
↓ [RTO：4秒待つ (さらに2倍！)]
4回目の再送 ────× (完全に沈黙...)
↓ [RTO：8秒待つ (さらに2倍！)]このように、送信側が自主的に「一歩引いて、待つ時間を延ばす」ことで、ネットワークの混雑が自然に解消するのを優しく待つのです。この賢い思いやりのおかげで、インターネットは崩壊せずに動き続けることができています。
—
4. 実務に活かす！OSの設定とプログラムでの応用
この素晴らしいTCPの仕組みは、私たちが普段使っているLinuxサーバーなどのOS（オペレーティングシステム）に標準で組み込まれています。
インフラエンジニアやWeb開発者が、実務でこの挙動を調整したり、アプリケーションに組み込んだりする方法をのぞいてみましょう。
① Linuxカーネルパラメータでの設定（インフラエンジニア向け）
Linuxサーバーでは、TCPが「何回まで再送を試みるか」を設定することができます。
例えば、Webサーバーやデータベースサーバーの設定を調整する際、以下のパラメータが関係してきます。
代表的な設定を確認・変更するコマンドを見てみましょう。
# 現在のTCP再送回数の設定を確認する
# tcp_retries2 は、接続が確立している状態での最大再送回数（デフォルトは15回が多いです）
sysctl net.ipv4.tcp_retries2
# 一時的に再送回数を「8回」に減らして、障害時のあきらめ（タイムアウト）を早くする設定
sudo sysctl -w net.ipv4.tcp_retries2=8設定を永続化させるためには、/etc/sysctl.conf ファイルに以下のように記述します。
# /etc/sysctl.conf の中に追記する内容
# ネットワークが不安定な時に、いつまでも未練がましく再送し続けず、
# 早めにエラーを検知してフェイルオーバー（切り替え）させたい場合に調整します。
net.ipv4.tcp_retries2 = 8② プログラムで「指数バックオフ」を実装する（開発者向け）
この「指数バックオフ」の考え方は、TCPだけでなく、私たちが書くWebアプリケーションの中で「外部のAPIを呼び出す処理」などにも非常によく応用されます。
APIサーバーが一時的に落ちている時、プログラムから連続で猛アタックするのを防ぐために、Pythonを使って「指数バックオフ付きリトライ処理」を実装してみましょう。
import time
import random
def call_external_api():
"""
外部APIを呼び出す模擬関数。
今回はデモのため、常に失敗（例外）を発生させます。
"""
raise ConnectionError("APIサーバーへの接続に失敗しました。")
def call_api_with_backoff(max_retries=5, base_delay=1.0):
"""
指数バックオフを取り入れたリトライ機能付きAPI呼び出し関数
:param max_retries: 最大リトライ回数
:param base_delay: 初回の待ち時間（秒）
"""
for attempt in range(max_retries):
try:
print(f"[試行 {attempt + 1}] APIを呼び出します...")
# 本番ではここで本物の通信を行います
call_external_api()
print("API呼び出しに成功しました！")
return True
except ConnectionError as e:
print(f"エラー発生: {e}")
# 最後の試行だった場合は、諦めてエラーを発生させる
if attempt == max_retries - 1:
print("最大リトライ回数に達しました。処理を諦めます。")
raise
# 指数バックオフの計算： base_delay * (2 ^ attempt)
# 例：1秒 -> 2秒 -> 4秒 -> 8秒 と増えていきます
delay = base_delay * (2 ** attempt)
# 【プロの知恵】「ジッター（揺らぎ）」を加える
# 複数のクライアントが同時に一斉に再送するのを防ぐため、少しだけランダムな時間を足し引きします
jitter = random.uniform(0, 0.5)
total_delay = delay + jitter
print(f"--> {total_delay:.2f} 秒間待機してから再試行します...\n")
time.sleep(total_delay)
# 実際にプログラムを実行してみる
if __name__ == "__main__":
try:
call_api_with_backoff()
except Exception as e:
print(f"\n最終結果: 処理は失敗しました。({e})")このコードを実行すると、リトライするたびに待ち時間が倍増していく様子がコンソールに表示されます。
このように、TCPの知恵は現代のクラウド開発や分散システムの設計（マイクロサービスなど）でも、非常に重要な設計パターンとして受け継がれているのです。
—
5. まとめ：パケットに込められた「思いやり」を感じてみよう
私たちが毎日使っているインターネット。その裏側では、何万マイルもの距離を旅するパケットたちが迷子にならないよう、TCPというプロトコルが常にストップウォッチを片手に、以下のような涙ぐましい努力を重ねています。
1. RTT（往復時間） を常に測り、ネットワークの調子をいつも見守っている。
2. 状況に合わせて、最適な限界待ち時間 RTO（再送タイムアウト値） を計算している。
3. 渋滞が起きたら、「指数バックオフ」 でお互いに譲り合い、一歩引いて通信の回復を待つ。
普段は目に見えないネットワークのパケット。でも、その一つ一つに「確実に届けたい」という設計者たちの情熱と、ネットワークを壊さないための「譲り合いの精神」がアルゴリズムとして刻み込まれています。
次にウェブサイトの表示がほんの一瞬遅いなと感じたときは、ぜひ「今、私のTCPパケットたちが指数バックオフで頑張って道を譲り合っているんだな」と、温かい目で見守ってあげてくださいね。
一歩ずつ、ネットワークの楽しさを一緒に理解していきましょう！それでは、次回の記事でお会いしましょう！
コメント