Bufferbloat, Internet, dan Cara Memperbaikinya

Ada penyakit menakutkan yang menjangkiti Penyedia Layanan Internet selama bertahun-tahun. Oke, mungkin ada beberapa penyakit, tapi hari ini kita berbicara tentang bufferbloat. Apa itu, bagaimana mengujinya, dan akhirnya apa yang dapat Anda lakukan. Oh, dan teriakan besar untuk semua orang yang menangani masalah ini. Banyak programmer dan insinyur, seperti Vint Cerf, Dave Taht, Jim Gettys, dan banyak lagi telah memecahkan masalah ini untuk keuntungan kita bersama.

Ketika komputer Anda mengirim paket TCP/IP ke host lain di Internet, paket itu merutekan melalui komputer Anda, melalui kartu jaringan, melalui sakelar, melalui router Anda, melalui modem ISP, melalui beberapa router ISP, dan akhirnya melalui beberapa router yang sangat besar dalam perjalanannya ke pusat data. Atau mungkin melalui rangkaian perangkat yang berbelit-belit itu secara terbalik, untuk tiba di desktop lain. Sungguh menakjubkan bahwa semuanya bekerja sama sekali, sungguh. Masing-masing hop tersebut mewakili tempat lain untuk hal-hal yang tidak beres. Dan jika sesuatu benar-benar salah, Anda langsung mengetahuinya. Halaman tiba-tiba tidak bisa dimuat. Panggilan VoIP Anda terputus, atau terputus. Sangat mudah untuk menemukan koneksi yang rusak, bahkan jika menemukan dan memperbaikinya tidak begitu sepele.

Itu masalah yang jelas. Bagaimana jika Anda memiliki masalah yang tidak jelas? Situs dimuat, tetapi hanya sedikit lebih lambat dari biasanya. Anda tahu cara menggunakan baris perintah, jadi Anda mencoba tes ping. Huh, 15,0 mdtk ke Google.com. Biarkan berjalan selama seratus paket, dan pada dasarnya tidak ada paket yang hilang. Tapi ada yang tidak beres. Ketika orang lain sedang streaming film, atau mesin mendorong cadangan ke server jauh, semuanya berantakan. Itu bufferbloat, dan sebenarnya sangat mudah untuk melakukan tes sederhana untuk mendeteksinya. Jalankan tes kecepatan, dan jalankan tes ping saat koneksi Anda sedang jenuh. Jika latensi Anda di bawah beban melewati atap, Anda mungkin mengalami bufferbloat. Bahkan ada beberapa situs tes kecepatan besar yang sekarang menawarkan tes bufferbloat. Tapi pertama-tama, beberapa sejarah.

Sejarah Runtuh

Internet pada 1980-an adalah tempat yang sangat berbeda. Sistem Nama Domain menggantikan host.txt sebagai cara nama host ke resolusi IP dilakukan pada tahun 1982. 1 Januari 1983, ARPANET mengadopsi TCP/IP — hari lahir Internet. Pada tahun 1984, ada masalah yang muncul, dan pada tahun 1986 Internet mengalami serangan jantung dalam bentuk kemacetan kemacetan.

Pada masa itu, jaringan lokal mutakhir berjalan pada 10 megabit per detik, tetapi tautan situs-ke-situs hanya mentransfer paling baik 56 kilobyte per detik. Akhir 1986, link tiba-tiba mengalami penurunan yang ekstrim, seperti link 400 yard antara Lawrence Berkeley Laboratory dan University of California di Berkeley. Alih-alih 56 Kbps, tautan ini tiba-tiba mentransfer pada 40 bit per detik yang efektif. Masalahnya adalah kemacetan. Ini adalah model yang sangat mirip dengan apa yang terjadi ketika terlalu banyak mobil berada di jalan raya yang sama — lalu lintas melambat hingga merangkak.

Rilis 4.3 BSD memiliki implementasi TCP yang melakukan beberapa hal menarik. Pertama, itu akan mulai mengirim paket dengan kecepatan kabel penuh segera. Dan kedua, jika sebuah paket dijatuhkan di tengah jalan, paket itu akan dikirim ulang sesegera mungkin. Pada Jaringan Area Lokal, di mana ada kecepatan jaringan yang seragam, ini berfungsi dengan baik. Di internet awal, khususnya tautan Berkeley ini, koneksi LAN 10 Mb/s disalurkan ke 32 kbps atau 56 kbps.

Untuk mengatasi ketidakcocokan ini, gateway di kedua sisi tautan memiliki buffer kecil, kira-kira senilai 30 paket. Dalam skenario kemacetan, lebih dari 30 paket dicadangkan di gateway, dan paket tambahan baru saja dijatuhkan. Ketika paket dijatuhkan, atau kemacetan mendorong waktu perjalanan pulang pergi melampaui ambang batas waktu, pengirim segera mengirim ulang — menghasilkan lebih banyak lalu lintas. Beberapa host yang mencoba mengirim terlalu banyak data melalui koneksi yang terlalu sempit menyebabkan kemacetan, loop umpan balik lalu lintas. Internet awal tidak sengaja DDoS sendiri.

Solusinya adalah serangkaian algoritma yang ditambahkan ke implementasi TCP BSD, yang sekarang telah diadopsi sebagai bagian dari standar. Sederhananya, untuk mengirim secepat mungkin, lalu lintas perlu diperlambat secara cerdas. Teknik pertama yang diperkenalkan adalah slow start. Anda dapat melihat ini masih digunakan saat Anda menjalankan tes kecepatan, dan koneksi dimulai dengan kecepatan yang sangat lambat, lalu meningkat dengan cepat. Secara khusus, hanya satu paket yang dikirim pada awal transmisi. Untuk setiap paket yang diterima, paket pengakuan (ack) dikembalikan. Setelah menerima ack, dua paket lagi dikirim melalui kabel. Ini menghasilkan peningkatan cepat hingga dua kali kecepatan maksimum dari tautan paling lambat dalam rantai koneksi. Jumlah paket “keluar” pada suatu waktu disebut ukuran jendela kemacetan. Jadi cara lain untuk melihat masalah ini adalah bahwa setiap keberhasilan perjalanan pulang pergi meningkatkan jendela kemacetan satu per satu.

Setelah slow-start melakukan tugasnya, dan paket pertama dijatuhkan atau habis, aliran TCP beralih menggunakan algoritma penghindaran kemacetan. Yang satu ini memiliki penekanan pada mempertahankan kecepatan data yang stabil. Jika sebuah paket dijatuhkan, jendela terpotong menjadi dua, dan setiap kali paket senilai jendela penuh diterima, jendela bertambah satu. Hasilnya adalah grafik gigi gergaji yang terus-menerus memantul di sekitar throughput maksimum dari seluruh jalur data. Ini sedikit penyederhanaan yang berlebihan, dan algoritme telah dikembangkan lebih jauh dari waktu ke waktu, tetapi intinya adalah meluncurkan ekstensi ini ke TCP/IP menyelamatkan internet. Dalam beberapa kasus, pembaruan dikirim dalam bentuk kaset, melalui surat, semacam reboot yang sulit dari seluruh jaringan.

Maju cepat ke 2009

Internet sedikit berkembang sejak 1986. Salah satu hal yang berubah adalah harga perangkat keras telah turun, dan kemampuan telah naik secara dramatis. Sebuah gateway dari 1986 akan mengukur buffer dalam kilobyte, dan kurang dari 100 pada saat itu. Saat ini, cukup sepele untuk membuang megabyte dan gigabyte memori pada masalah, dan buffer router tidak terkecuali. Apa yang terjadi ketika algoritme yang ditulis untuk ukuran buffer 50 kB bertemu dengan buffer 50 MB di perangkat modern? Bisa ditebak, ada yang salah.

Ketika buffer First In First Out (FIFO) besar berada di kemacetan, buffer itu harus terisi sepenuhnya sebelum paket dijatuhkan. Aliran TCP dimaksudkan untuk memperlambat hingga 2x bandwidth yang tersedia, dengan sangat cepat mulai menjatuhkan paket, dan memangkas penggunaan bandwidth menjadi dua. Bufferbloat adalah apa yang terjadi ketika aliran itu menghabiskan terlalu banyak waktu untuk mencoba mengirim dua kali kecepatan yang tersedia, menunggu buffer terisi. Dan begitu koneksi beralih ke mode penghindaran kemacetan yang stabil, algoritme itu bergantung pada paket yang dijatuhkan atau batas waktu, di mana ambang batas waktu berasal dari waktu perjalanan pulang pergi yang diamati. Hasilnya adalah bahwa untuk koneksi apa pun, latensi bolak-balik meningkat dengan jumlah paket buffer di jalur. Dan untuk koneksi di bawah beban, teknik penghindaran kemacetan TCP dirancang untuk mengisi buffer tersebut sebelum mengurangi jendela kemacetan.

Jadi seberapa buruk itu bisa? Di jaringan lokal, waktu perjalanan pulang pergi Anda diukur dalam mikrodetik. Waktu Anda ke host Internet harus diukur dalam milidetik. Bufferbloat mendorongnya menjadi beberapa detik, dan puluhan detik dalam beberapa kasus terburuk. Dimana yang benar-benar menimbulkan masalah adalah ketika menyebabkan traffic time out pada layer aplikasi. Bufferbloat menunda semua lalu lintas, sehingga dapat menyebabkan waktu tunggu DNS habis, membuat panggilan VoIP menjadi kacau balau, dan membuat Internet menjadi pengalaman yang menyakitkan.

Solusinya adalah Manajemen Antrian Cerdas. Ada banyak pekerjaan yang telah dilakukan pada konsep ini sejak 1986. Antrian yang adil adalah salah satu solusi pertama, membuat buffer perantara cerdas, dan membagi arus lalu lintas individu menjadi antrian individu. Ketika tautan macet, setiap antrian akan melepaskan satu paket pada satu waktu, jadi mengunduh ISO melalui Bittorrent tidak akan sepenuhnya membuat lalu lintas VoIP Anda menjadi padat. Setelah banyak iterasi, algoritma CAKE telah dikembangkan dan digunakan secara luas. Semua solusi ini pada dasarnya menukar sedikit throughput maksimum untuk memastikan latensi berkurang secara signifikan.

Apakah Anda FLENT di Bufferbloat?

Saya ingin memberi tahu Anda bahwa bufferbloat adalah masalah yang terpecahkan, dan Anda pasti tidak memiliki masalah dengan itu di jaringan Anda. Sayangnya, tidak demikian halnya. Untuk penanganan kasar apakah Anda memiliki masalah, gunakan tes kecepatan di dslreports, fast.com, atau speedtest.net. Masing-masing dari ketiganya, dan mungkin yang lain, memberikan semacam latensi di bawah pengukuran beban. Ada tes khusus Bufferbloat yang dihosting oleh bentuk gelombang, dan tampaknya yang terbaik untuk dijalankan di browser. Jaringan yang ideal akan tetap menunjukkan latency rendah ketika terjadi kemacetan. Jika latensi Anda meningkat secara signifikan selama pengujian, Anda mungkin memiliki kasus bufferbloat.

Untuk kutu buku dari kita, ada alat baris perintah, flent, yang melakukan tes bufferbloat mendalam. Saya menggunakan perintah, flent rrul -p all_scaled -H flent-fremont.bufferbloat.net untuk menghasilkan bagan ini, dan Anda melihat penskalaan latensi dengan cepat lebih dari 100 ms di bawah beban. Ini menjalankan Respons Waktu Nyata di bawah uji Beban, dan dengan jelas menunjukkan bahwa saya memiliki sedikit masalah bufferbloat di jaringan saya. Masalah diidentifikasi, apa yang bisa saya lakukan?

Anda Dapat Memiliki Kue Anda

Karena kita semua menjalankan router OpenWRT di jaringan kita… Anda menjalankan router open source, bukan? Atau ada beberapa router komersial yang memiliki semacam SQM built-in, tapi kami jelas tidak puas dengan itu di Hackaday. Solusi FOSS di sini adalah CAKE, sistem manajemen antrian, dan sudah tersedia di repositori OpenWRT. Paket yang Anda cari adalah luci-app-sqm. Menginstal yang memberi Anda halaman baru di antarmuka web — di bawah Jaringan -> SQM QoS.

Di halaman itu, pilih antarmuka WAN Anda sebagai nama Antarmuka. Selanjutnya, ubah hasil tes kecepatan Anda menjadi Kilobit/detik, kurangi sekitar 5%, dan masukkan ke dalam kecepatan unggah dan unduh. Balik ke tab Antrian Disiplin, di mana kami idealnya ingin menggunakan Cake dan piece_of_cake.qos sebagai opsi. Tab terakhir itu membutuhkan sedikit pekerjaan rumah untuk menentukan nilai terbaik, tetapi Ethernet dengan overhead dan 22 tampaknya merupakan nilai yang waras untuk memulai. Aktifkan instans SQM, lalu simpan dan terapkan.

Dan sekarang kami menyetel dan menguji. Pada instalasi pertama, router mungkin benar-benar perlu di-boot ulang untuk memuat modul kernel. Tetapi Anda akan melihat perbedaan langsung pada salah satu tes bufferbloat. Jika unggah atau unduh bufferbloat Anda masih berlebihan, sesuaikan kecepatan arah itu sedikit lebih rendah beberapa persen. Jika bufferbloat Anda turun ke 0, coba naikkan kecepatannya sedikit. Anda mencari efek minimal pada kecepatan maksimum, dan efek maksimum pada bufferbloat. Dan itu saja! Anda telah membunuh Bufferbloat Beast!

“Thompson Router” oleh Simeon W dilisensikan di bawah CC BY 2.0 .