Pemulihan lambat pada thin stream Thin streams fall back to RTO
ID penyebab rt-thin · Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Pengembangan klien (Tim Pengembang Game)
Jika game mengirim paket kecil secara jarang-jarang, RTO datang lebih dulu sebelum “3 paket susulan” terkumpul. Untuk packet loss yang sama, game berhenti jauh lebih lama daripada transfer data besar.
Mengapa Interval paket sekitar 100 ms sehingga hanya ada sedikit paket yang belum mendapat ACK (in-flight) → Akibatnya Butuh lebih dari 300 ms untuk mengumpulkan 3 duplicate ACK sehingga RTO (ping + 200 ms) terpicu lebih dulu, dan berlipat dua jika packet loss terjadi berturut-turut → Di layar Satu kali packet loss membuat freeze sekitar 0,3 detik; jika paket yang dikirim ulang juga hilang, freeze hampir 1 detik lalu fast forward
Penanggung jawab utama Pengembangan server (Tim Pengembang Game) · Turut terlibat Infrastruktur server (Tim Infrastruktur), Pengembangan klien (Tim Pengembang Game)
Tugas Tim Pengembang Game
Server: aktifkan TCP_NODELAY (jika Nagle aktif, RACK tidak punya paket susulan sebagai dasar penilaian), kirim paket real-time lewat UDP dengan retransmisi buatan sendiri. Klien: aktifkan TCP_NODELAY, kirim paket real-time dengan cara yang sama seperti server (UDP).
Tugas Tim Infrastruktur
Pakai RACK-TLP (default di Linux terbaru), aktifkan tcp_thin_linear_timeouts agar RTO berturut-turut tidak berlipat dua.
Kisaran angka
Dengan interval paket 100 ms dan ping 60 ms, fast retransmit butuh sekitar 360 ms (sampai 3 paket berikutnya tiba dan konfirmasinya kembali), sedangkan RTO sekitar 260 ms. Dengan RACK, paket langsung dikirim ulang di sekitar 160 ms, saat konfirmasi paket berikutnya kembali. Jika interval paket lebih dari 200 ms, RACK pun tidak lebih cepat daripada RTO.
Di grafik
Kosong lalu datang sekaligus · Volume terima per koneksi, jumlah RTO habis
Yang diperiksa
Bandingkan kenaikan TcpExtTCPTimeouts (RTO habis), TcpExtTCPFastRetrans (fast retransmit), serta TcpExtTCPLossProbes dan TcpExtTCPLossProbeRecovery (TLP) di nstat, lalu periksa rto dan backoff koneksi game dengan ss -ti. Periksa juga nilai net.ipv4.tcp_recovery, tcp_early_retrans, dan tcp_sack di server
Cocok jika
Di antara retransmisi, RTO habis lebih banyak daripada fast retransmit, dan koneksi game sering menunjukkan backoff lebih dari 0 (sedang mengalami RTO). Volume terima 0 selama koneksi berhenti, lalu datang sekaligus saat pulih
Tidak cocok jika
Transfer data besar di server yang sama juga berhenti sama lamanya: masalah packet loss yang tidak terkait pola trafik koneksi. Terpusat pada koneksi tanpa SACK atau timestamp: lebih mungkin “Opsi TCP dihapus oleh perangkat perantara”
Sarana pemeriksaan
Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut
Linux dulu juga punya opsi retransmisi pada 1 duplicate ACK untuk thin stream (tcp_thin_dupack), tetapi opsi ini dihapus pada 2017, dan sekarang perannya digantikan oleh RACK. Jika Nagle aktif (TCP_NODELAY nonaktif), pengirim tidak mengirim paket baru selama menunggu konfirmasi paket yang hilang, sehingga RACK tidak punya paket susulan sebagai dasar penilaian dan koneksi harus menunggu sampai RTO.
Sumber
Thin-streams and TCPLinux kernel Thin stream yang mengirim secara jarang-jarang seperti game tidak memicu fast retransmit dengan baik sehingga bergantung pada timeout yang panjang; batasnya adalah kurang dari 4 paket yang belum mendapat ACK (in-flight)
RFC 8985: The RACK-TLP Loss Detection Algorithm for TCPIETF RACK menilai packet loss dari terkirimnya paket yang dikirim belakangan; waktu tunggu TLP adalah 2·SRTT (ditambah kelonggaran delayed ACK jika hanya ada satu paket yang belum dikonfirmasi)
include/net/tcp.hLinux kernel TCP_RTO_MIN 200 ms, penentuan thin stream (kurang dari 4 paket in-flight), dan 6 kali percobaan ulang linear
tcp: remove thin_dupack featureLinux kernel thin_dupack dihapus pada Januari 2017 (Linux 4.11), disertai penjelasan bahwa perannya digantikan oleh RACK
IP SysctlLinux kernel tcp_thin_linear_timeouts: pada thin stream, RTO tidak digandakan hingga maksimal 6 kali percobaan (default nonaktif)
net/ipv4/proc.cLinux kernel Nama counter yang ditampilkan nstat: TCPTimeouts, TCPFastRetrans, TCPLossProbes, TCPLossProbeRecovery
net/ipv4/tcp_timer.cLinux kernel TCPTimeouts naik saat timer retransmisi (RTO) habis
SNMP counterLinux kernel TcpExtTCPFastRetrans (retransmisi di luar state Loss), TcpExtTCPLossProbes (TLP dikirim), TcpExtTCPLossProbeRecovery (packet loss dipulihkan oleh TLP)