Komuniti rangkaian sedang membahaskan sama ada sudah tiba masanya untuk meningkatkan tetingkap kesesakan awal TCP sekali lagi, berikutan kejayaan Google menolak daripada 1 kepada 10 paket pada tahun 2011. Memandangkan halaman web telah berkembang secara mendadak dari segi saiz sepanjang dekad yang lalu, piawaian semasa mungkin tidak lagi mencukupi untuk prestasi yang optimum.
Evolusi Tetingkap Kesesakan Awal TCP
- Sebelum 2010: 1-3 paket (1.5-4.5 KB)
- 2011-kini: 10 paket (~15 KB)
- Dicadangkan: 20-40 paket (30-60 KB)
- Liputan pada 10 paket: ~85% aset dalam satu perjalanan pulang pergi (data 2011)
Cabaran Teknikal dengan Pelaksanaan Semasa
Cadangan untuk meningkatkan tetingkap kesesakan awal daripada 10 kepada antara 20 hingga 40 paket menghadapi halangan teknikal yang ketara. Jurutera rangkaian menunjukkan bahawa hanya meningkatkan nilai ini boleh memberi kesan buruk yang teruk. Kebimbangan utama berkisar tentang kehilangan ekor - apabila paket di hujung penghantaran digugurkan, memaksa keseluruhan sambungan untuk memperlahankan dan memulih.
Kehilangan ekor: Apabila paket terakhir dalam penghantaran hilang, menyebabkan jenis kemerosotan prestasi yang paling teruk untuk protokol tetingkap gelongsor seperti TCP.
Pakar komuniti menekankan bahawa tetingkap kesesakan awal beroperasi sebelum mana-mana algoritma kawalan kesesakan mempunyai masa untuk mempelajari tentang keadaan rangkaian. Ini menjadikan keputusan itu amat berisiko, kerana tiada mekanisme maklum balas untuk membimbing pilihan semasa saat-saat genting pertama sambungan.
Had Algoritma BBR
Walaupun artikel asal mencadangkan penggunaan algoritma kawalan kesesakan BBR Google bersama-sama dengan tetingkap awal yang lebih tinggi, profesional rangkaian menyatakan keraguan tentang pendekatan ini. BBR mengambil masa yang agak lama untuk melalui fasa-fasa pembelajarannya, bermakna ia menawarkan sedikit kelebihan semasa peringkat awal sambungan apabila tetingkap awal paling penting.
Fokus algoritma pada pemantauan variasi masa perjalanan pulang-pergi untuk mengesan kesesakan, dan bukannya bergantung semata-mata pada kehilangan paket, tidak menangani cabaran asas memilih titik permulaan yang sesuai tanpa sebarang pengetahuan rangkaian.
Algoritma Kawalan Kesesakan yang Disebut
- TCP New Reno: Algoritma berasaskan kehilangan tradisional
- CUBIC: Lalai semasa dalam kebanyakan sistem
- BBR: Algoritma berasaskan kelewatan Google yang memfokuskan pada anggaran lebar jalur
- TCP Vegas, Reno, TCTP: Pelbagai alternatif dengan pendekatan yang berbeza
Salah Faham Protokol QUIC
Pembetulan teknikal yang ketara muncul berkenaan tingkah laku protokol QUIC . Bertentangan dengan dakwaan bahawa QUIC menghapuskan tetingkap kesesakan sepenuhnya, protokol ini sebenarnya melaksanakan algoritma kawalan kesesakan yang sama seperti TCP , termasuk kedua-dua CUBIC dan BBR . QUIC tidak secara ajaib menyelesaikan pengurusan lebar jalur - ia masih mesti menghormati had kapasiti rangkaian.
Pelaksanaan QUIC biasanya menggunakan algoritma kawalan kesesakan yang sama, termasuk kedua-dua CUBIC dan BBR , sekurang-kurangnya secara nominal.
Ini bermakna walaupun Google dan pemain utama lain berhijrah ke arah QUIC , cabaran kawalan kesesakan asas kekal relevan untuk kedua-dua protokol.
Bufferbloat Kekal sebagai Masalah Sebenar
Perbincangan mendedahkan perselisihan pendapat yang berterusan tentang kesan semasa bufferbloat terhadap prestasi internet. Walaupun sesetengah pihak berhujah ia adalah isu yang terlalu digembar-gemburkan dari tahun 2010-an, yang lain memberikan contoh konkrit kesan berterusannya. Rangkaian mudah alih, terutamanya perkhidmatan internet rumah 5G , masih menunjukkan masalah bufferbloat yang ketara di mana masa ping melonjak secara mendadak semasa pemindahan data.
Pengendali rangkaian melaporkan kejayaan menggunakan teknik pengurusan baris gilir aktif seperti fq_codel dan CAKE untuk menangani isu-isu ini, menunjukkan masalah itu tidak hilang tetapi memerlukan perhatian berterusan.
Bufferbloat: Apabila peranti rangkaian menggunakan penimbal bersaiz berlebihan, menyebabkan paket menunggu terlalu lama dalam baris gilir dan bukannya digugurkan, membawa kepada peningkatan kependaman.
Penyelesaian Pengurusan Barisan Aktif
- fq_codel: Barisan adil dengan kelewatan terkawal
- CAKE: Common Applications Kept Enhanced
- L4S: Low Latency, Low Loss, Scalable Throughput
- Digunakan untuk memerangi bufferbloat dalam peralatan rangkaian moden
Cabaran Penggunaan Perusahaan
Realiti pengurusan rangkaian perusahaan menambah satu lagi lapisan kerumitan. Banyak organisasi melumpuhkan QUIC sepenuhnya, memaksa pengunduran kepada sambungan TCP . Ini berlaku kerana kebanyakan vendor firewall tidak dapat memeriksa trafik QUIC , mewujudkan kebimbangan keselamatan untuk pentadbir rangkaian.
Tingkah laku perusahaan yang meluas ini bermakna pengoptimuman TCP kekal penting untuk sebahagian besar trafik internet, walaupun protokol yang lebih baharu mendapat penggunaan dalam persekitaran pengguna.
Komuniti rangkaian terus menimbang potensi faedah tetingkap kesesakan awal yang lebih tinggi berbanding risiko peningkatan kesesakan rangkaian. Walaupun aplikasi web moden akan mendapat manfaat daripada penghantaran data awal yang lebih pantas, penyelesaian memerlukan pertimbangan teliti terhadap kestabilan rangkaian dan keadilan merentas semua pengguna.
Rujukan: An Argument for Increasing TCP's Initial Congestion Window... Again