Pada Kinerja implementasi TCP dari Linux dan Windows

Saya mengerti implementasi TCP stack di windows dan Linux berbeda. Windows menggunakan algoritma kontrol kemacetan yang dikenal sebagai TCP Reno sementara Linux menggunakan Cubic.

Bagaimana 2 protokol dibandingkan ketika mereka hidup berdampingan di jaringan yang sama? Apakah benar mengatakan bahwa Cubic (Linux) lebih agresif dan mungkin mendapatkan bagian bandwidth yang lebih tinggi?

Perhatikan bahwa algoritma kontrol kemacetan hanya memengaruhi lalu lintas hulu dan karenanya hanya bandwidth hulu.

Yang sedang berkata, Cubic sebenarnya lebih agresif, terutama untuk jaringan dengan produk penundaan bandwidth tinggi. Bahkan ada aturan yang dibangun dalam implementasi Linux sehingga tidak pernah menggunakan tingkat pengiriman yang lebih kecil daripada yang dilakukan reno dalam situasi yang sama:

Algoritma Linux Cubic juga mencakup kode yang memastikan bahwa algoritma cubic setidaknya sama agresifnya dengan TCP standar

- Leith, Shorten, McCullagh, Evaluasi eksperimental Cubic-TCP

Jadi, ketika mengunduh pembaruan Windows Anda saat menonton Video Youtube, lalu lintas Youtube Anda mungkin membuat kelaparan lalu lintas microsoft Anda, dan tidak ada yang dapat Anda lakukan untuk itu.

Pertama, apa yang Anda katakan tidak benar secara faktual:

• Linux hingga kernel versi 2.6.18 digunakan BIC secara default.
• Kernel Linux 2.6.19 dan yang lebih baru digunakan CUBIC secara default.
• Mekanisme kontrol kemacetan TCP Linux adalah pluggable , misalnya Anda dapat mengubahnya pada fily.
• Windows XP dan sebelumnya menggunakan TCP Reno (atau New Reno )
• Windows Vista dan yang lebih baru juga memiliki Compound TCP , yang diaktifkan secara default di Server 2008 dan dapat diaktifkan di Vista dan Windows 7 jika diperlukan.

Semua algoritma ini mengatur sendiri sesuai dengan bandwidth jaringan yang tersedia, latensi, memori yang tersedia, dll. Mereka juga memiliki banyak parameter konfigurasi yang memungkinkan Anda menyetelnya sendiri.

Jadi, Anda tidak dapat benar-benar membandingkan satu dengan yang lain, tanpa melihat topologi jaringan spesifik yang tepat, perangkat keras dan perangkat lunak yang digunakan, dll. Ini tidak seperti yang satu lebih baik daripada yang lain, atau akan menggunakan bagian lebih besar dari bandwidth yang tersedia. Memang benar bahwa CUBIC kurang agresif daripada BIC, tetapi dalam praktiknya pertimbangan lain sering lebih penting daripada rasa algoritma kemacetan TCP yang digunakan.

Kecuali Anda mencoba menyesuaikan skenario jaringan yang sangat sempit dan tidak biasa, algoritme ini semuanya bekerja dengan cukup baik dan adil di luar kotak.