Opsi TCP dihapus oleh perangkat perantara Middlebox strips TCP options
ID penyebab rt-sack-stripped · Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Jika sebagian firewall atau perangkat akselerator menghapus atau mengubah opsi TCP, saat beberapa paket hilang, pemulihannya hanya satu paket per round trip, atau window (jumlah yang bisa dikirim sekaligus) mengecil sehingga koneksi melambat.
Mengapa “TCP normalization” di firewall atau perangkat akselerator lama menghapus opsi SACK, timestamp, dan window scaling → Akibatnya Jika beberapa paket hilang, pemulihannya satu paket per round trip, dan window dibatasi 64 KB → Di layar Freeze di setiap packet loss jauh lebih lama (tanpa SACK, RACK-TLP juga tidak bisa dipakai), lalu fast forward setelah pulih. Transfer data besar seperti patch juga lambat
Penanggung jawab utama Infrastruktur jaringan (Tim Infrastruktur) · Turut terlibat Infrastruktur server (Tim Infrastruktur)
Tugas Tim Infrastruktur
Jaringan: matikan pengaturan TCP normalization di perangkat terkait, periksa juga pengacakan nomor urut di firewall, bandingkan opsi di SYN lewat packet capture di kedua ujung. Server/OS: periksa di ss -ti apakah koneksi tanpa tanda sack atau wscale terpusat pada rute tertentu (PC Windows bisa tidak memakai ts tergantung pengaturannya, jadi jika hanya ts yang tidak ada, itu bisa normal), pastikan net.ipv4.tcp_sack di server bernilai 1.
Di grafik
Selalu tinggi sejak awal · Jumlah pemulihan yang dimulai tanpa SACK (TcpExtTCPRenoRecovery)
Yang diperiksa
Periksa di ss -ti apakah setiap koneksi menampilkan sack dan wscale, lalu periksa rasio TcpExtTCPRenoRecovery (pemulihan yang dimulai tanpa SACK) terhadap TcpExtTCPSackRecovery serta TcpExtTCPSACKDiscard (jumlah blok SACK yang dibuang karena tidak konsisten) di nstat. Untuk rute yang dicurigai, capture SYN di kedua ujung lalu bandingkan opsinya (tcp.options.sack_perm di Wireshark dan sejenisnya)
Cocok jika
Hanya koneksi yang melewati rute atau perangkat tertentu yang tidak memiliki sack dan wscale, dan porsi TcpExtTCPRenoRecovery tinggi. Opsi SACK-permitted yang ada di SYN saat dikirim tidak ada lagi di SYN saat diterima. Jika penyebabnya pengacakan nomor urut, opsinya masih ada, tetapi TcpExtTCPSACKDiscard naik
Tidak cocok jika
sack tidak ada di semua koneksi: periksa nilai net.ipv4.tcp_sack di server lebih dulu. Opsi utuh dan TcpExtTCPSACKDiscard juga tidak berubah: pemulihan lambat karena sebab lain (“Pemulihan lambat pada thin stream”)
Sarana pemeriksaan
Tools infrastruktur (tanpa perlu kode game)
Pelajari lebih lanjut
SACK bisa rusak walaupun opsinya masih ada. Jika pengacakan nomor urut (sequence randomization) di firewall hanya mengubah nomor urut di header dan membiarkan nomor di dalam SACK, pengirim membuang SACK yang tidak konsisten itu. Hasilnya sama jika tcp_sack=0 pernah diatur di server saat masalah keamanan SACK tahun 2019 lalu terlupakan.
SNMP counterLinux kernel TcpExtTCPRenoRecovery (pemulihan dimulai tanpa SACK), TcpExtTCPSackRecovery (pemulihan dimulai dengan SACK), TcpExtTCPSACKDiscard (jumlah blok SACK yang tidak valid)