Wikipedia

Peluapan penyangga

Revisi sejak 21 Februari 2024 14.47 oleh AABot (bicara | kontrib) (~cite)

Peluapan penyangga adalah penyebab tingginya pendaman dan jitter pada sambungan paket yang disebabkan oleh penyanggaan paket yang berlebihan. Peluapan penyangga juga dapat menyebabkan variasi penundaan paket (juga dikenal sebagai jitter), serta mengurangi aliran lewat jaringan secara keseluruhan. Ketika perute atau pengalih dikonfigurasi untuk menggunakan penyangga yang terlalu besar, bahkan jaringan berkecepatan sangat tinggi pun bisa menjadi tidak dapat digunakan untuk banyak aplikasi interaktif seperti voice over IP (VoIP), penjaliran audio, permainan daring, dan bahkan penelusuran web biasa.

Beberapa produsen peralatan komunikasi merancang penyangga berukuran besar yang tidak perlu pada beberapa produk jaringan mereka. Pada peralatan seperti itu, peluapan penyangga terjadi ketika pranala jaringan menjadi padat, menyebabkan paket-paket menjadi antri dalam jangka waktu lama dalam penyangga yang terlalu besar ini. Dalam sistem antrian masuk pertama keluar pertama, penyangga yang terlalu besar mengakibatkan antrian lebih panjang dan latensi lebih tinggi, serta tidak meningkatkan aliran lewat jaringan. Hal ini juga dapat disebabkan oleh koneksi berkecepatan lambat tertentu yang menghambat pengiriman paket lain secara tepat waktu.

Fenomena peluapan penyangga telah dijelaskan sejak tahun 1985.[1] Ini mendapat perhatian lebih luas mulai tahun 2009. [2]

Menurut beberapa sumber, penyebab paling umum dari sendat yang tinggi dalam permainan video daring adalah peluapan penyangga jaringan rumah lokal. Sendat yang tinggi dapat membuat permainan daring modern menjadi tidak mungkin dilakukan.[3]

Penyanggaan

Aturan praktis yang ditetapkan bagi produsen peralatan jaringan adalah menyediakan penyangga yang cukup besar untuk menampung setidaknya 250 Ms penyanggaan untuk aliran lalu lintas yang melewati perangkat. Misalnya, perute antarmuka Gigabit Ethernet akan memerlukan 32 yang relatif besar penyangga MB . Ukuran penyangga seperti itu dapat menyebabkan kegagalan algoritma kendali kemacetan TCP . Penyangga kemudian membutuhkan waktu beberapa saat untuk terkuras, sebelum kendali kemacetan dimulaiulang dan koneksi TCP kembali naik ke kecepatannya dan mengisi penyangga lagi. Peluapan penyangga kemudian menyebabkan masalah seperti sendat yang tinggi dan bervariasi, serta menghambat kemacetan jaringan untuk semua aliran lainnya karena penyangga menjadi penuh dengan paket dari satu aliran TCP dan paket lainnya kemudian dibuang.

Peluapan penyangga hanya berpengaruh jika penyangga ini benar-benar digunakan. Dengan kata lain, penyangga yang terlalu besar mempunyai efek merusak hanya ketika pranala yang disangga menjadi hambatan. Ukuran penyangga yang melayani kemacetan dapat diukur menggunakan utilitas ping yang disediakan oleh sebagian besar sistem operasi. Pertama, hos lain harus di-ping secara terus menerus; kemudian, pengunduhan berdurasi beberapa detik darinya harus dimulai dan dihentikan beberapa kali. Secara desain, algoritma penghindaran kemacetan TCP akan dengan cepat mengisi kemacetan pada rute. Jika pengunduhan (dan pengunggahan, masing-masing) berkorelasi dengan peningkatan langsung dan penting dari waktu pulang pergi yang dilaporkan oleh ping, maka hal ini menunjukkan bahwa penyangga dari kemacetan saat ini dalam arah pengunduhan (dan pengunggahan, masing-masing) membengkak. Karena peningkatan waktu pulang pergi disebabkan oleh penyangga pada kemacetan, peningkatan maksimum memberikan perkiraan kasar mengenai ukurannya dalam milidetik.

Pada contoh sebelumnya, menggunakan alat pelacak rute (traceroute) tingkat lanjut alih-alih melakukan ping sederhana (misalnya, MTR ) tidak hanya akan menunjukkan keberadaan penyangga yang meluap pada kemacetan, namun juga akan menunjukkan dengan tepat lokasinya di jaringan. Pelacak rute mencapai hal ini dengan menampilkan rute (jalur) dan mengukur penundaan pengalihan paket di seluruh jaringan. Riwayat rute dicatat sebagai waktu pulang pergi dari paket yang diterima dari masing-masing hos berturut-turut (simpul jarak jauh) dalam rute (jalur).[4]

Mekanisme

Kebanyakan algoritma kendali kemacetan TCP mengandalkan pengukuran terjadinya packet drop untuk menentukan lebar pita yang tersedia antara dua ujung koneksi. Algoritmanya mempercepat transfer data hingga paket mulai berkurang, kemudian memperlambat laju pengiriman. Idealnya, mereka terus menyesuaikan laju pengiriman hingga mencapai kecepatan sambungan yang seimbang. Agar algoritma dapat memilih kecepatan pengiriman yang sesuai, umpan balik mengenai penurunan paket harus terjadi pada waktu yang tepat. Dengan besarnya penyangga yang terisi maka paket akan sampai di tujuan, namun dengan sendat yang lebih tinggi. Paket-paketnya tidak dibuang, jadi TCP tidak melambat setelah pranala naik jenuh, yang selanjutnya mengisi penyangga. Paket yang baru tiba akan dibuang hanya ketika penyangga jenuh sudah penuh. Ketika hal ini terjadi, TCP bahkan mungkin memutuskan bahwa jalur koneksi telah berubah, dan sekali lagi melakukan pencarian yang lebih agresif untuk titik operasi baru.[5]

Paket diantri dalam penyangga jaringan sebelum dikirim; dalam situasi bermasalah, paket akan dibuang hanya jika penyangga penuh. Pada penjalur lama, penyangga berukuran cukup kecil sehingga terisi dengan cepat dan oleh karena itu paket mulai turun segera setelah pranala menjadi jenuh, sehingga protokol TCP dapat menyesuaikan dan masalah tidak akan terlihat jelas. Pada penjalur yang lebih baru, penyangga telah menjadi cukup besar untuk menampung data yang disangga selama beberapa detik. Bagi TCP, pranala yang padat dapat terlihat beroperasi secara normal saat penyangga terisi. Algoritma TCP tidak menyadari bahwa link tersebut padat dan tidak mulai mengambil tindakan perbaikan sampai penyangga akhirnya meluap dan paket-paket dibuang.

Semua paket yang melewati penyangga sederhana yang diimplementasikan sebagai antrian tunggal akan mengalami penundaan yang sama, sehingga latensi koneksi apa pun yang melewati penyangga yang terisi akan terpengaruh. Lebar pita saluran yang tersedia juga bisa menjadi tidak terpakai, karena beberapa tujuan cepat mungkin tidak segera tercapai karena penyangga tersumbat dengan data yang menunggu pengiriman ke tujuan lambat. Efek ini mengganggu interaktivitas aplikasi yang menggunakan protokol jaringan lain, termasuk UDP yang digunakan dalam aplikasi sensitif sendat seperti VoIP dan permainan daring.[6]

Dampak pada aplikasi

Terlepas dari kebutuhan lebar pita, semua jenis layanan yang memerlukan pendaman rendah secara konsisten atau transmisi bebas jitter dapat terpengaruh oleh peluapan penyangga. Layanan tersebut mencakup panggilan suara digital (VOIP), permainan daring, obrolan video, dan aplikasi interaktif lainnya seperti penjaliran radio, video on demand, dan catat masuk jarak jauh .

Ketika fenomena peluapan penyangga muncul dan jaringan sedang dimuat, pemuatan halaman web normal pun memerlukan waktu beberapa detik untuk diselesaikan, atau kueri DNS sederhana bisa gagal karena waktu habis. [7] Sebenarnya koneksi TCP apa pun bisa habis dan terputus, dan paket UDP bisa dibuang. Karena kelanjutan aliran unduhan TCP bergantung pada paket pengakuan (ACK) dalam aliran unggahan, masalah peluapan penyangga dalam unggahan dapat menyebabkan kegagalan aplikasi unduhan lain yang tidak terkait, karena paket ACK klien tidak mencapai server internet tepat waktu. Misalnya, Anda mungkin membatasi kecepatan transmisi unggahan sinkronisasi OneDrive agar tidak mengganggu pengguna jaringan rumah lainnya, seperti penjaliran radio internet .

Deteksi

Tes Kecepatan Laporan DSL [8] adalah tes yang mudah digunakan yang mencakup skor untuk peluapan penyangga. ICSI Netalyzr [9] adalah alat daring lainnya yang dapat digunakan untuk memeriksa keberadaan peluapan penyangga di jaringan, bersamaan dengan memeriksa banyak masalah konfigurasi umum lainnya.[10] Layanan ini ditutup pada Maret 2019. Situs web bufferbloat.net mencantumkan alat dan prosedur untuk menentukan apakah suatu koneksi memiliki penyanggaan berlebih yang akan memperlambatnya. [11]

Solusi dan mitigasi

Ada beberapa solusi teknis yang secara garis besar dapat dikelompokkan menjadi dua kategori: solusi yang menargetkan jaringan dan solusi yang menargetkan titik akhir. Kedua jenis solusi ini seringkali saling melengkapi. Masalahnya terkadang muncul dengan kombinasi jalur jaringan yang cepat dan lambat.

Solusi jaringan umumnya berbentuk algoritma manajemen antrian. Solusi seperti ini telah menjadi fokus kelompok kerja AQM IETF . [12] Contoh penting meliputi:

  • Membatasi panjang antrian IP, lihat penyetelan TCP
  • Algoritma AQM seperti CoDel dan PIE .
  • Algoritma hybrid AQM dan penjadwalan paket seperti FQ-CoDel . [13]
  • Amandemen standar DOCSIS [14] untuk mengaktifkan kontrol buffer yang lebih cerdas di modem kabel . [15]
  • Integrasi manajemen antrian ( FQ-CoDel ) ke dalam subsistem Wi-Fi dari sistem operasi Linux karena Linux umumnya digunakan pada titik akses nirkabel .

Ukuran buffer optimal

Agar koneksi TCP dengan penundaan terlama tetap mendapatkan bagian lebar pita yang adil, ukuran penyangga setidaknya harus berupa produk penundaan lebar pita yang dibagi dengan akar kuadrat dari jumlah aliran simultan.[16] [17] Aturan umumnya adalah 50 ms data laju saluran, [18] namun beberapa pengalih kelas konsumen yang populer hanya memiliki 1 ms, [19] yang dapat mengakibatkan kehilangan lebar pita ekstra pada koneksi penundaan yang lebih lama jika terjadi perselisihan lokal dengan yang lain.

Referensi

  1. ^ "On Packet Switches with Infinite Storage". 1985-12-31. 
  2. ^ van Beijnum, Iljitsch (2011-01-07). "Understanding Bufferbloat and the Network Buffer Arms Race". Ars Technica. Diakses tanggal 2011-11-12. 
  3. ^ "Bufferbloat: Dark Buffers in the Internet: Networks without effective AQM may again be vulnerable to congestion collapse". Queue. doi:10.1145/2063166.2071893. 
  4. ^ "traceroute(8) – Linux man page". die.net. Diakses tanggal 2013-09-27. 
  5. ^ Jacobson, Van; Karels, MJ (1988). "Congestion avoidance and control" (PDF). ACM SIGCOMM Computer Communication Review. 18 (4): 314–329. doi:10.1145/52325.52356. Diarsipkan dari versi asli (PDF) tanggal 2004-06-22. 
  6. ^ "Technical Introduction to Bufferbloat". Bufferbloat.net. Diakses tanggal 2013-09-27. 
  7. ^ Gettys, Jim; Nichols, Kathleen (January 2012). "Bufferbloat: Dark Buffers in the Internet". Communications of the ACM. ACM. 55 (1): 57–65. doi:10.1145/2063176.2063196. 
  8. ^ "Speed test - how fast is your internet?". dslreports.com. Diakses tanggal 26 October 2017. 
  9. ^ "ICSI Netalyzr". berkeley.edu. Diarsipkan dari versi asli tanggal April 7, 2019. Diakses tanggal 30 January 2015. 
  10. ^ "Understanding your Netalyzr results". Diakses tanggal 26 October 2017. 
  11. ^ "Introduction to Bufferbloat". bufferbloat.net. Diakses tanggal 8 May 2023. 
  12. ^ "IETF AQM working group". ietf.org. Diakses tanggal 26 October 2017. 
  13. ^ Høiland-Jørgensen, Toke; McKenney, Paul; Taht, Dave; Gettys, Jim; Dumazet, Eric. The FlowQueue-CoDel Packet Scheduler and Active Queue Management Algorithm. 
  14. ^ "DOCSIS "Upstream Buffer Control" feature". CableLabs. hlm. 554–556. Diakses tanggal 2012-08-09. 
  15. ^ Gettys, Jim; Nichols, Kathleen (January 2012). "Bufferbloat: Dark Buffers in the Internet". Communications of the ACM. ACM. 55 (1): 57–65. doi:10.1145/2063176.2063196. 
  16. ^ Huston, Geoff (2019-12-12). "Sizing the buffer". APNIC Blog (dalam bahasa Inggris). Diakses tanggal 2022-10-16. 
  17. ^ Guido Appenzeller; Isaac Keslassy; Nick McKeown (2004). "Sizing Router Buffers" (PDF). ACM SIGCOMM. ACM. Diakses tanggal 2013-10-15. 
  18. ^ "Router/Switch Buffer Size Issues". fasterdata.es.net. Diakses tanggal 2022-10-16. 
  19. ^ "BCM53115". www.broadcom.com (dalam bahasa Inggris). Diakses tanggal 2022-10-16. 
Diperoleh dari "https://wiki-indonesia.club/w/index.php?title=Peluapan_penyangga&oldid=25341601"