TCP

アプリケーションが send を2回呼び出しても、受信側は一度にすべて読み取ることもあれば、複数回に分けて読み取ることもあります。TCP が保証するのは順序付きバイトストリームであり、アプリケーションが書き込んだメッセージの境界は保持されません。これを理解するには、1つのデータフローを追跡します。シーケンス番号はバイトを識別し、ACK は受信の進捗を示し、ウィンドウは送信可能な範囲を制約し、パケット損失の検出は回復をトリガーし、輻輳制御はネットワークにどの程度の負荷をかけるかを決定します。

バイトストリーム：信頼性の高い受信＝ビジネス完了ではない

TCP は接続が維持可能な場合に、確認応答、再送、順序付き配信によってデータを回復しますが、永久にネットワークが切断された場合でも最終的な成功を保証するものではありません。send の成功は通常、データがローカルの送信パスに入ったことを示します。TCP ACK は、相手側 TCP が対応するバイトを受信したことを意味しますが、相手側アプリケーションがそれを読み取り、ディスクに書き込み、トランザクションをコミットしたことを証明するものではありません。ビジネスレベルの確認は、依然としてアプリケーションプロトコルによって表現されるべきです。

例えば、abc と def の2回の書き込みに対して、受信側は ab と cdef を読み取る可能性があります。メッセージの境界を定義するのは、長さプレフィックス、固定長、または区切り文字などのフレーミングです。PSH は信頼性の高いメッセージ区切りフラグではありません。また、TCP には暗号化やサーバーの身元認証の機能は組み込まれておらず、TLS などのメカニズムが別の役割を担います。RFC 9293：TCP 基本仕様

ヘッダーフィールドがどのように動作に結びつくか

TCP の長さは、IP レベルの長さと実際のヘッダーチェーンから導き出す必要があり、Data Offset をそのままセグメントの長さとして使用してはいけません。32 bit のシーケンス番号はラップアラウンドしますが、比較はプロトコルのモジュラシーケンス番号ルールとウィンドウ制約に従って処理する必要があり、通常の整数の大小比較ではすべての状態をカバーできません。

オプション：一部は接続確立時のみ交渉される

ウィンドウスケーリングは双方向です。C が通知する shift は、C が今後送信する受信ウィンドウを解釈するために使用され、S から C への送信を制限します。MSS もまた、相手側から自側へのデータ送信を制約し、実際の送信はさらに PMTU、オプション、輻輳、受信ウィンドウの制約を受けます。RFC 7323：スケーリングとタイムスタンプ

ハンドシェイク：シーケンス番号の確認と接続状態

クライアントの SYN はシーケンス番号 1000 を使用し、サーバーは ACK=1001 でそれを確認し、自身の ISN=5000 を提示します。クライアントはさらに 5001 を確認します。3番目のステップにより、サーバーは自身のシーケンス番号が相手側によって確認されたことを知り、古い重複する接続試行を排除するのに役立ちます。ハンドシェイクで確認されるのは当時のプロトコル状態であり、その後のネットワークが常に到達可能であることを保証するものではありません。

SYN と FIN はそれぞれ1つのシーケンス番号を占有し、制御イベントを順序付きの確認と再送に統一して組み込むことができます。これは「シーケンス番号を占有しないメッセージはどのプロトコルでも再送できない」と逆推定してはなりません。純粋な ACK はシーケンス番号を占有せず、また、各 ACK ごとに別途確認応答を行うこともありません。

通常のクライアントは SYN-SENT を経て、サーバーは SYN-RECEIVED を経て、その後 ESTABLISHED に入ります。同時オープン、データを含む拡張、および異常なリセットには別のルールがあります。SYN cookies は、一部の半接続リソース圧力に対する抵抗のための実装メカニズムであり、交渉能力と使用条件があり、通常のキュー計画やすべての保護策を置き換えるものではありません。RFC 9293：接続確立

累積 ACK、SACK、再送範囲

[1001,2001) と [3001,4001) を受信し、中間の [2001,3001) が損失したと仮定します。累積 ACK は 2001 に留まります。SACK は別途 [3001,4001) をレポートします。ギャップを埋めると、連続範囲は 4001 まで伸び、ACK がそこにジャンプできるようになります。

SACK は受信事実を表現しますが、送信側はスコアボードを維持し、損失を判断して再送を手配する必要があります。「SACK を有効にすれば、常に本当に損失した1つのデータのみを再送する」というのは極端な言い方であり、順不同や誤判定が回復に影響を与える可能性があります。受信側にも SACK 済みデータの取り消し境界があるため、送信側は SACK があるからといって、累積確認の前にすべての再送コピーを破棄することはできません。RFC 2018：SACK

損失検出と輻輳制御は関連していますが異なる問題です。前者はどのデータが損失した可能性があるかを決定し、後者は次に許可される負荷を決定します。古典的な高速再送は、重複 ACK などのシグナルを利用します。現代の RACK は、送信時間と後続の確認に基づいて損失を推測し、TLP は末尾のプローブによって一部の末尾損失回復を改善し、3回の重複 ACK を待つ必要はありません。RFC 8985：RACK-TLP

RTO がなぜ RTT に直接等しいわけではないのか

RTO は遅延の変動に対する余裕を残す必要があります。RFC 6298 の基本推定は SRTT + max(G, 4×RTTVAR) であり、最小値とバックオフ規則が組み合わされています。最初のサンプル R=100 ms の場合、SRTT=100 ms、RTTVAR=50 ms で、元の計算値は 300 ms です。この RFC で推奨される 1 s の下限により 1 s となり、実際のコアの実装の下限は別途照合する必要があります。

次のサンプルが 120 ms の場合、まず古い SRTT を使用して RTTVAR を更新します：0.75×50 + 0.25×20 = 42.5 ms。次に SRTT を更新します：0.875×100 + 0.125×120 = 102.5 ms。元の RTO は 272.5 ms です。再送後の ACK は、どの送信を確認したのかを特定できない場合があります。Karn ルールとタイムスタンプは、対応するサンプリングの曖昧さを処理するために使用されます。タイムアウトもバックオフをトリガーします。RFC 6298：再送タイマー

ACK 到達点とアプリの読取位置

第三、第一の順に送り、連続部分だけ ACK が進むことを見る。第二を補うと二段分進める。その後に読み、確認と消費を分ける。表示 SACK の隣接区間は統合可能。

フロー制御と輻輳ウィンドウ：在途量をまず差し引く

通常の、回復しない簡易モデルでは、送信側は受信ウィンドウ rwnd と輻輳ウィンドウ cwnd の両方に制限されます。min(rwnd, cwnd) は在途規模の制約であり、毎回これだけを送信できるわけではありません。さらに、送信済みで未確認のデータを差し引き、パシング、アプリケーションの利用可能なデータ、実際の実装を考慮する必要があります。

SND.UNA=1001、SND.NXT=4001 と設定すると、すでに 3000 B が未確認です。rwnd=8000 B、cwnd=5000 B の場合、簡易的な新データの余力は min(8000, 5000) - 3000 = 2000 B です。cwnd を 20000 B に引き上げると、制約は受信ウィンドウになり、新余力は 5000 B になります。

ゼロウィンドウ後、送信側の persist メカニズムはウィンドウが再び開かれたかどうかをプローブし、ウィンドウ更新の損失による長期停止を防ぎます。これはアイドル接続の keepalive やパケット損失再送タイマーとは異なる用途です。Nagle は、未確認データが存在する場合の小セグメント送信を制限し、遅延 ACK と組み合わされると、小規模なインタラクションの待ち時間が長くなる可能性があります。TCP_NODELAY はアプリケーションのメッセージ境界を回復させるものではありません。

帯域幅遅延積（BDP）の再計算

1 Gbit/s、RTT=50 ms の BDP は 10⁹/8 × 0.05 = 6,250,000 B です。スケーリングされていない 65535 B のウィンドウでは、他の制限を無視しても、ウィンドウ/RTT が与える上限は約 10.486 Mbit/s に過ぎません。scale=7 の場合、最大で 8,388,480 B（約 8 MiB）まで表現でき、ようやくこの BDP をカバーできます。これは必要な予算ですが、スループットの保証ではありません。

ウィンドウと残送信量は違う

三つは別の状態量。飛行中量を二つの窓の間に置くと、大きい制約で小さい制約を補えない。窓を飛行中量以下に縮めても既送信量は残り、新規送信が止まる。

$$credit=\max \left(0,\min (rwnd,cwnd)-FlightSize\right)$$

クローズ：両方向が独立して終了する

A が FIN を送信した後、新しいアプリケーションデータは送信しませんが、P のデータは依然として受信できます。P は確認応答後、CLOSE-WAIT に留まる可能性があります。これはアプリケーションが自身の送信方向を終了するまで続きます。その後、P は FIN を送信し、A が確認します。ACK と FIN は結合できるため、クローズは必ずしも正確に4つのパケットで行われるわけではありません。同時クローズも状態遷移パスを変更します。

典型的なアクティブクローズ側は FIN-WAIT-1、FIN-WAIT-2、TIME-WAIT を経ます。パッシブ側は CLOSE-WAIT、LAST-ACK を経ます。大量の CLOSE-WAIT が発生している場合は、TIME_WAIT パラメータで説明しようとするのではなく、アプリケーションがなぜまだ接続を終了していないかを確認する必要があります。

TIME-WAIT は、再送された FIN への応答と、古い接続のパケットが新しい接続に干渉するのを防ぐために時間を確保するもので、最後の ACK が必ず届くことを保証するものではありません。仕様では 2MSL で記述されていますが、Linux 7.2 の TCP_TIMEWAIT_LEN は 60×HZ で、60 s に相当します。仕様のモデルと実装のタイマーは区別します。tcp_fin_timeout は対応する孤児状態の FIN-WAIT-2 に対してのものであり、TIME-WAIT の長さスイッチではありません。

接続の再利用は、接続確立/クローズの頻度を削減できます。SO_REUSEADDR は条件を満たすバインディングに影響しますが、すべての4元組の競合を解消するものではありません。tcp_tw_reuse にもセキュリティ条件とバージョン設定の意味があり、パラメータを議論する前に、まず状態とリソースのボトルネックを区別する必要があります。RFC 9293：クローズ、Linux TCP sysctl

CUBIC：保持率と成長曲線の関係

ネットワークは、パケット損失や ECN などのシグナルによって輻輳を反映させることができます。輻輳制御が「推測」のみで、ネットワークが能動的にフィードバックしないとは言えません。CUBIC の中核的な目標カーブは以下の通りです。

W(t) = C×(t−K)³ + Wmax

β が輻輳後の保持比率を表すとき、K = ∛(Wmax×(1−β)/C) です。β=0.7、C=0.4、Wmax=100 セグメントを取ると、K≈4.22 s になります。W(0)=70 セグメント、W(K)=100 セグメントです。古い公式は、保持比率 0.7 を K の分子に直接入れるため、W(0) が 30 セグメントと誤算されます。RFC 9438：CUBIC

カーブは古い Wmax に近づくと成長が鈍化し、それを越えると探査を続けます。時間はこの関数の独立変数ですが、実際の TCP は依然として ACK、RTT、Reno 友好領域、回復ルールに依存しており、「スループットが RTT の影響を全く受けない」と要約することはできません。起動時の近似指数成長も、ACK の動作と制限条件の影響を受けるため、すべての接続で毎 RTT 正確に2倍になるとは限りません。

CUBIC の輻輳応答は、個別のパケット損失ごとに独立して 0.7 倍になることを意味しません。イベントのマージ、高速回復、タイムアウトには異なる処理があります。キューサイズ、AQM、ECN、ランダムなパケット損失、競合フローは、最終的なレイテンシとスループットに影響を与えます。

変曲点前後で増加が遅くなり再加速する理由

K を通ると窓は増え続け、傾きはゼロまで下がって再上昇する。β 変更で初期窓と K が動いても W(K) は旧 Wmax に戻る。平行移動項の役割を確かめる。

$$W_{cubic}(t)=C(t-K{)}^3+W_{max},K=\sqrt[3]{W_{max}(1-\beta )/C}$$

BBR：帯域幅と遅延モデルの検証も必要

BBR は、配信レートや RTT などの観測値を使用してパス容量を推定し、パシングと在途制約を組み合わせて送信を制御します。典型的なプロセスには、容量の高速探査、起動時に形成されたキューの排空、帯域幅の周期的な探査、最小遅延推定の更新が含まれます。観測値は ACK の集約、アプリケーションによる制限、パスの変化、他のフローの影響を受けるため、モデルは実際の物理的なボトルネックを直接読み取るものではありません。

Linux 7.2 の tcp_bbr.c には、古典的な4つのモード、約 2.885 の起動時パシングゲイン、および 1.25/0.75 などの定常状態ゲインが含まれています。これらはすべての BBR バージョンにおける統一定数として一般化することはできません。帯域幅推定、cwnd ゲイン、パシングゲインは異なり、在途量を常に正確に1つの BDP に固定することはできません。

Google の BBR プロジェクトには、継続的に進化している実装と資料が含まれており、比較するバージョンを明確にする必要があります。RFC 9438 は CUBIC を定義します。BBR のアルゴリズムとバージョンは対応するプロジェクト資料で確認します。「BBR はパケット損失によって決して減速しない」「必ずキューがない」「限定のないデプロイメント割合」などの実験条件を代替しないでください。Google BBR プロジェクト

ローカル推論：バイト範囲、ウィンドウ、カーブ

import math

received = [(1001,2001),(3001,4001)]
def cumulative(intervals, start=1001):
    ack = start
    for left,right in sorted(intervals):
        if left>ack:
            break
        ack = max(ack,right)
    return ack
assert cumulative(received) == 2001
assert cumulative(received+[(2001,3001)]) == 4001
assert min(8000,5000)-(4001-1001) == 2000
assert 1_000_000_000/8*.05 == 6_250_000
assert 65535<<7 == 8_388_480
assert math.isclose(65535*8/.05/1e6,10.4856)

srtt,variation = .1,.05
sample = .12
variation = .75*variation+.25*abs(srtt-sample)
srtt = .875*srtt+.125*sample
assert math.isclose(srtt+4*variation,.2725)

beta,C,Wmax = .7,.4,100
K = (Wmax*(1-beta)/C)**(1/3)
def target(t):
    return C*(t-K)**3+Wmax
assert math.isclose(target(0),70)
assert math.isclose(target(K),100)
assert target(K+1)>100
print('ACK ギャップ、送信余力、BDP、RTO、CUBIC 境界チェック通過')

これは局所的な数学モデルであり、実際の再送タイマー、コアの輻輳状態、またはネットワークの公平性をシミュレートするものではありません。輻輳制御と接続パラメータは変更されていません。

さらに調べる

• UDP と QUIC 転送層：メッセージ境界、マルチストリーム、回復メカニズム。
• ICMP と PMTUD：パスのパケット長制約。
• ネットワークパフォーマンスとチューニング：観測証拠からボトルネックを特定。