Peluapan penyangga: Perbedaan antara revisi

Konten dihapus Konten ditambahkan
k ~cite
Reno-Sifana (bicara | kontrib)
Memperbaiki artikel
 
(2 revisi perantara oleh satu pengguna lainnya tidak ditampilkan)
Baris 1:
'''Peluapan penyangga''' ({{Lang-en|bufferfloat}}) adalah penyebab tingginya [[Pendaman (rekayasa)|pendaman]] dan jitter pada [[sambungan paket]] yang disebabkan oleh [[Penyangga (telekomunikasi)|penyanggaan]] [[Paket jaringan|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 jaringan|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|''voice over IP'']] (VoIP), [[Media penjaliranpengaliran|penjaliranpengaliran audio]], [[permainan daring]], dan bahkan [[Navigasi web|penelusuran web]] biasa.
 
Beberapa produsen peralatan komunikasi merancang penyangga berukuran besar yang tidak perlu pada beberapa [[Perangkat keras jaringan|produk jaringan]] mereka. Pada peralatan seperti itu, peluapan penyangga terjadi ketika pranala jaringan menjadi [[Kemacetan jaringan|padat]], menyebabkan paket-paket menjadi antri dalam jangka waktu lama dalam penyangga yang terlalu besar ini. Dalam sistem antrian [[FIFO|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.
Baris 8:
 
== 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 [[Bita|MB]] . Ukuran penyangga seperti itu dapat menyebabkan kegagalan [[Algoritma kontrol kemacetan TCP|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 (perangkat lunak)|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).<ref>{{Cite web|title=traceroute(8) – Linux man page|url=http://linux.die.net/man/8/traceroute|website=die.net|access-date=2013-09-27}}</ref>
 
== Mekanisme ==
Baris 22:
 
== 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, [[Videotelefoni|obrolan video]], dan aplikasi interaktif lainnya seperti [[Radio Internet|penjaliranpengaliran radio]], [[Video atas permintaan|''video on demand'']], dan [[Remote login|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. <ref name="acm2">{{Cite journal|last=Gettys|first=Jim|last2=Nichols|first2=Kathleen|date=January 2012|title=Bufferbloat: Dark Buffers in the Internet|journal=Communications of the ACM|publisher=ACM|volume=55|issue=1|pages=57–65|doi=10.1145/2063176.2063196}}</ref> Sebenarnya [[Protokol Kontrol Transmisi|koneksi TCP]] apa pun bisa habis dan terputus, dan [[Protokol Datagram Pengguna|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 mungkinsaat membatasi kecepatan transmisi unggahan sinkronisasi [[OneDrive]] agar tidak mengganggu pengguna [[jaringan rumah]] lainnya, seperti penjaliranaliran [[Radio Internet|radio internet]] .
 
== Deteksi ==
Tes Kecepatan Laporan DSL <ref>{{Cite web|title=Speed test - how fast is your internet?|url=http://dslreports.com/speedtest|website=dslreports.com|access-date=26 October 2017}}</ref> adalah tes yang mudah digunakan yang mencakup skor untuk peluapan penyangga. ICSI Netalyzr <ref>{{Cite web|title=ICSI Netalyzr|url=http://netalyzr.icsi.berkeley.edu/|website=berkeley.edu|archive-url=https://web.archive.org/web/20190407211303/http://netalyzr.icsi.berkeley.edu/|archive-date=April 7, 2019|access-date=30 January 2015|url-status=dead}}</ref> adalah alat daring lainnya yang dapat digunakan untuk memeriksa keberadaan peluapan penyangga di jaringan, bersamaan dengan memeriksa banyak masalah konfigurasi umum lainnya.<ref>{{Cite web|title=Understanding your Netalyzr results|url=https://www.newscientist.com/article/dn18953-understanding-your-netalyzr-results|access-date=26 October 2017}}</ref> 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. <ref>{{Cite web|title=Introduction to Bufferbloat|url=https://www.bufferbloat.net/projects/bloat/wiki/Introduction/|website=bufferbloat.net|access-date=8 May 2023}}</ref>
 
== 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 [[Internet Engineering Task Force|IETF]] . <ref name="ietf-aqm">{{Cite web|title=IETF AQM working group|url=https://datatracker.ietf.org/wg/aqm/about/|website=ietf.org|access-date=26 October 2017}}</ref> Contoh penting meliputi:
 
* Membatasi panjang antrian IP, lihat penyetelan TCP
* Algoritma AQM seperti CoDel dan [[PIE (queue management algorithm)|PIE]] .
* Algoritma hybrid AQM dan penjadwalan paket seperti FQ-CoDel . <ref name="fq-codel">{{Cite IETF|last1=Høiland-Jørgensen|first1=Toke|last2=McKenney|first2=Paul|last3=Taht|first3=Dave|last4=Gettys|first4=Jim|last5=Dumazet|first5=Eric|title=The FlowQueue-CoDel Packet Scheduler and Active Queue Management Algorithm}}</ref>
* Amandemen standar DOCSIS <ref name="docsis">{{Cite web|title=DOCSIS "Upstream Buffer Control" feature|url=http://www.cablelabs.com/specs|publisher=CableLabs|pages=554–556|access-date=2012-08-09}}</ref> untuk mengaktifkan kontrol buffer yang lebih cerdas di [[modem kabel]] . <ref name="acm">{{Cite journal|last=Gettys|first=Jim|last2=Nichols|first2=Kathleen|date=January 2012|title=Bufferbloat: Dark Buffers in the Internet|journal=Communications of the ACM|publisher=ACM|volume=55|issue=1|pages=57–65|doi=10.1145/2063176.2063196}}</ref>
* 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 ==
Baris 44:
 
== Referensi ==
{{reflist}}
 
[[Kategori:Arsitektur internet]]