Solusi 1:
ACK TCP dasar mengatakan "Saya menerima semua byte hingga X." ACK selektif memungkinkan Anda mengatakan "Saya menerima byte X-Y, dan V-Z."
Jadi, misalnya, jika host mengirimi Anda 10.000 byte dan 3.000-5.000 byte hilang saat transit, ACK akan mengatakan "Saya mendapatkan semuanya hingga 3.000." Ujung lainnya harus mengirim byte 3001-10000 lagi. SACK dapat mengatakan "Saya mendapat 1000-2999, dan 5001-10000" dan tuan rumah hanya akan mengirimkan 3000-5000.
Ini bagus untuk link bandwidth tinggi, lossy (atau delay tinggi). Masalahnya adalah hal itu dapat menyebabkan masalah kinerja yang parah dalam keadaan tertentu. ACK TCP normal akan membuat server menangani bandwidth tinggi, koneksi lossy dengan sarung tangan anak (kirim 500 byte, tunggu, kirim 500 byte, tunggu, dll). SACK memungkinkannya beradaptasi dengan penundaan yang tinggi karena ia tahu persis berapa banyak paket yang sebenarnya hilang.
Di sinilah hal buruk bisa terjadi. Penyerang dapat memaksa server Anda untuk menyimpan antrean pengiriman ulang besar-besaran untuk waktu yang lama, lalu memproses semuanya itu berulang kali. Ini dapat mematok CPU, memakan RAM, dan menghabiskan lebih banyak bandwidth dari yang seharusnya. Singkatnya, sistem yang ringan dapat memulai DoS terhadap server yang lebih tangguh.
Jika server Anda kuat dan tidak melayani file besar, Anda cukup terlindungi dari ini.
Jika Anda sebagian besar melayani intranet atau grup pengguna latensi rendah lainnya, SACK tidak membeli apa pun untuk Anda dan dapat dimatikan untuk alasan keamanan tanpa kehilangan kinerja.
Jika Anda menggunakan link bandwidth rendah (misalnya 1Mbps atau kurang sebagai aturan praktis yang sepenuhnya arbitrer), SACK dapat menyebabkan masalah dalam operasi normal dengan memenuhi koneksi Anda dan harus dimatikan.
Pada akhirnya, terserah Anda. Pertimbangkan apa yang Anda layani, kepada siapa, dari apa, dan pertimbangkan tingkat risiko Anda terhadap efek performa SACK.
Ada ikhtisar bagus tentang SACK dan kerentanannya di sini.
Solusi 2:
Alasan lain mengapa TCP SACK sering dinonaktifkan adalah karena ada banyak peralatan jaringan di luar sana yang gagal menangani opsi ini dengan benar. Kami melihat ini sepanjang waktu dengan produk transfer file berkecepatan tinggi yang kami sediakan yang menggunakan TCP. Masalah yang paling umum adalah perangkat gateway yang melakukan hal-hal seperti mengacak nomor urut untuk paket TCP yang transit melalui perangkat dari jaringan internal ke eksternal, tetapi itu tidak "membatalkan pengacakan" opsi TCP SACK yang mungkin dikirim dari jarak jauh. akhir. Jika nilai SACK yang sebenarnya tidak diterjemahkan kembali ke nilai yang tepat oleh perangkat ini, maka sesi TCP tidak akan pernah selesai dalam menghadapi kehilangan paket saat ujung jarak jauh mencoba menggunakan SACK untuk mendapatkan manfaat ACK selektif.
Mungkin ini tidak akan menjadi masalah jika orang lebih agresif menerapkan pemeliharaan perangkat lunak preventif untuk perlengkapan ini, tetapi mereka cenderung tidak melakukannya.
Solusi 3:
Saya dapat mengonfirmasi dari pengalaman pahit bahwa tcp_sack =1 menyebabkan transfer data terhenti melalui sftp/rsync/scp dll dengan file lebih dari sekitar 12mb saat menggunakan peralatan firewall Cisco ASA tertentu.
SETIAP Waktu itu akan terhenti.
Kami mentransfer melalui link 100mbps khusus antara host A dan host B di dua pusat data yang berbeda, keduanya menggunakan firewall cisco dan mengganti perangkat keras dengan centos.
Ini dapat dikurangi dengan memodifikasi ukuran buffer - mis. Saya tidak dapat mentransfer file 1 GB melalui sftp dari host A ke host B kecuali saya menyetel buffer sftp ke 2048, tetapi saya dapat terlepas dari apakah host B menarik file dari A.
Eksperimen dengan file yang sama menggunakan penyetelan rsync dan mengirim/menerima buffer memungkinkan saya untuk mendapatkan sekitar 70mb dari file 1GB yang didorong dari A ke B.
Namun, jawaban akhirnya adalah menonaktifkan tcp_sack pada host A. Awalnya dengan menyetel tcp_sack =0 di kernel on-the-fly - tetapi akhirnya - saya menambahkannya ke /etc/sysctl.conf