한국어 English 日本語简体中文繁體中文 Deutsch ไทย Tiếng Việt Русский Português (Brasil)Español Bahasa Indonesia

ACKの遅れ・消失（上り回線の飽和） ACK path congestion on asymmetric links

原因ID rt-ack-path · 主担当 外部・外部 · 副担当ゲーム開発チーム・クライアント開発

データは問題なく届いているのに、「受け取った」というACKが満杯の上りキューで遅れたり消えたりすると、送信側はパケットロスと判断して再送します。

なぜ家で動画のアップロード・クラウドバックアップにより上り回線が満杯 → すると ACKがルーターのキューで数百ms遅れるか、あふれて破棄される → 画面では サーバーが送るゲームパケットはおおむね時間どおりに届く。同じ上りキューにたまった自分の入力が遅れて入力遅延・引き戻し、ときどき不要な再送

症状: 入力遅延, 引き戻し
要因: 遅延, パケットロス
誰に起きるか: 同じ家
いつ: ときどきランダムに, 夜のピーク時間帯
担当: 主担当 外部・外部 · 副担当ゲーム開発チーム・クライアント開発
ゲーム開発チームの対応: Pingが急上昇したら画面にネットワーク状態を表示、「アップロード中のプログラムを確認」という案内を表示。
外部の対応: ユーザーに、ルーターのSQMで上りキューを短くする、小さなパケット（ACK）を優先処理する、アップロード速度を制限する（動画のアップロード・クラウドバックアップ）ことを案内。
数値の目安: ACKは後のACKが前のものの分まで確認してくれるため、いくつか消えるのはたいてい問題ありません。問題になるのは、キューで遅れるほうです。
グラフでは: 一部だけ高い · 接続ごとのRTT（Ping）
確認箇所: ユーザーのPCで、アップロード（動画のアップロード・クラウドバックアップ）を実行した状態と止めた状態で、ゲームサーバーへのpingを比較。サーバーではss -tiでそのユーザーの接続のrttを確認
該当する場合: アップロード中にだけpingが数百msに上がって入力遅延・引き戻しが起き、アップロードを止めるとすぐに戻る。サーバーから見ると、そのときその接続のrttもそろって上がる
該当しない場合: アップロードと関係なくパケットロスと遅延が起きるなら「無線区間のパケットロス」か経路側の原因。サーバーからユーザーへの方向だけが遅く、アップロードと関係ないなら「ボトルネックでのキューあふれ」
確認手段: ユーザー側の環境で確認

出典

RFC 3449: TCP Performance Implications of Network Path Asymmetry IETF
上りが細い非対称回線でACKが遅れたり消えたりするとTCPの性能が落ちる、ACKは累積確認なので一部が消えても後のACKが代わりを果たす、ACKの優先スケジューリングのような対策
Smart Queue Management Bufferbloat.net
ルーターでキュー管理とシェーピングを行い、キューを短く保つ
tc-cake(8) — Linux manual page iproute2
CAKEはフローを分け、まばらに送るフロー（sparse flow）の遅延を最小化
ss(8) — Linux manual page iproute2
ss -iのrtt（平均往復時間）とrttvar（偏差）

あわせて読みたい原因

同じ層：TCP再送の根本原因

同じ症状（入力遅延）を起こすほかの層の原因

大人数の描画負荷 L1 クライアントのゲームプロセス
メインスレッドのパケット処理ボトルネック L1 クライアントのゲームプロセス
V-Syncとレンダーキュー L1 クライアントのゲームプロセス
省電力モード・サーマルスロットリング L2 クライアントのOS・端末
同じ端末の他のアプリによる帯域幅の占有 L2 クライアントのOS・端末
ディスプレイ・入力デバイス・フレーム生成による遅延 L2 クライアントのOS・端末
Wi-Fiチャンネルの混雑 L3 家庭内ネットワーク
バッファブロート（ルーターのキュー） L3 家庭内ネットワーク

図と実験のあるメインページでこのカードを見る