ns 3 project
1.0.0
% Alfred Tso Chun Fai 20012065g % Proyek COMP5311: Analisis Kinerja TCP dan UDP
lembaran baru
Bahkan bertanya-tanya mengapa browser Chrome terasa jauh lebih cepat dibandingkan Firefox saat menonton video Youtube? Saya melakukannya dan sebagai siswa yang penasaran, saya menjalankan Wireshark dan menangkap beberapa lalu lintas dan apa yang saya temukan adalah ini.
Menurut wiki 1 , QUIC digunakan oleh lebih dari separuh koneksi dari browser web Chrome ke server Google.
QUIC adalah protokol yang bertujuan untuk meningkatkan aplikasi web yang saat ini menggunakan TCP 2 dengan membuat sejumlah UDP multipleks bahkan ada yang menyebutnya "TCP/2". HTTP/3 yang akan datang (Draf Internet per Februari 2021) konon juga menggunakan QUIC.
Tunggu... Kami menggunakan UDP untuk menggantikan TCP? Kami diberitahu bahwa UDP tidak dapat diandalkan, kok bisa bertujuan untuk "usang" TCP. Perbandingan kedua protokol (TCP dan UDP) mirip dengan membandingkan Kereta dengan Pesawat daripada Boeing dengan Airbus (Keduanya transportasi ). Namun, kami masih dapat membandingkannya dengan beberapa metrik utama untuk melihat sekilas apa yang ingin ditingkatkan oleh UDP yang dipilih oleh QUIC ini.
lembaran baru
lembaran baru
Membandingkan protokol lapisan transport bukanlah tugas yang mudah, karena ada banyak faktor yang dapat mempengaruhi hasilnya:
Beberapa parameter dalam protokol (TCP misalnya) diserahkan kepada implementasi (yang menimbulkan Sidik Jari TCP/IP, yang memungkinkan aktor jahat untuk mengidentifikasi, antara lain, OS dari host) yang berarti bahwa perbedaan ini dapat berdampak halus pada pengukuran kinerja
Rute langsung yang diambil oleh paket-paket pasti akan mempengaruhi hasilnya sehingga router langsung, link kemacetan di antara paket-paket tersebut dan lalu lintas lainnya juga dapat mempengaruhi hasilnya.
Seperti disebutkan di atas, kita sering kali tidak yakin tentang bandwidth tautan langsung tersebut atau sekadar tautan antara klien dan server. Salah satu makalah yang disebutkan membuat asumsi bahwa tautan tersebut tidak akan mengalami tabrakan.
Kita telah melihat bahwa buffer dapat berdampak pada kinerja protokol-protokol ini dan tidak hanya sisi perangkat lunaknya saja yang relevan, bagian perangkat kerasnya juga penting dan sering kali kita tidak dapat mengontrol detail level yang lebih rendah ini.
Dalam sebagian besar karya sebelumnya, penulis sering mengimplementasikan program khusus untuk melakukan percobaan, kita juga perlu mempertimbangkan pengaruh bagaimana implementasi perangkat lunak ini dapat mempengaruhi hasil, misalnya interval pengiriman paket UDP, dan apakah ada batasan dalam hal ini. bahasa yang digunakan, untuk tujuan kita saat ini, interval pengiriman.
Mengingat semua pertimbangan ini, kami akan menggunakan topologi jaringan sederhana dengan pengaturan sedekat mungkin dengan kenyataan. Jika detail mendasarnya seperti ukuran antrian buffer atau protokol, kami akan menggunakan hal yang sama untuk kedua protokol. Oleh karena itu, kami akan membandingkan TCP dan UDP melalui IPv4 dalam host satu-ke-satu berkabel menggunakan throughput, penundaan rata-rata, dan jitter rata-rata sebagai indikator kinerja kami.
Kami akan mengirimkan paket 10, 100 dan range(1e4, 1e5, 1e4) , masing-masing 1472 Byte dalam aplikasi UDP dan jumlah Byte yang setara dalam aplikasi TCP untuk mengamati aliran aplikasi TCP dan UDP.
JitterSum berisi jumlah semua nilai jitter penundaan ujung ke ujung (variasi penundaan) untuk semua paket aliran yang diterima. Di sini kita mendefinisikan jitter suatu paket sebagai variasi penundaan relatif terhadap paket terakhir dari aliran, yaitu
lembaran baru
Pertanyaan pertama dalam merancang eksperimen tersebut adalah untuk mensimulasikan atau tidak. Simulasi mungkin lebih baik dalam penelitian kami karena kami dapat memiliki kontrol lebih besar atas pertimbangan yang kami sebutkan. Kelemahan terbesarnya adalah bagaimana kita bisa yakin bahwa hasilnya "nyata"? Jawabannya adalah selama kita memiliki cakupan eksperimen yang jelas dan sering memeriksa kewarasan pada cakupan tersebut, kita dapat memiliki gagasan tentang seberapa "nyata" hasilnya.
ns-3 adalah simulator jaringan peristiwa diskrit sumber terbuka yang digunakan terutama untuk tujuan penelitian atau pendidikan yang ditulis dalam C++. Simulator itu sendiri memiliki dokumentasi lengkap yang tersedia online.
Untuk tujuan kita saat ini, kita hanya perlu memahami abstraksi utama ns-3
{ lebar=75% }
Ini seperti proses di komputer kita, ia menggunakan "soket" untuk mengirim data ke lapisan bawah. Kami akan menginstal BulkSendApplication siap pakai di ns-3 menggunakan soket TCP dan UDPClient serta UDPServer untuk mengirim paket UDP dan FlowMonitor untuk kedua kasus guna memantau paket.
Kami akan mengirimkan paket dengan interval 2 mikrodetik yang merupakan penundaan saluran dasar yang ditentukan di bawah
Ini mengacu pada payload. Karena MTU adalah 1500, tentu saja kita ingin menggunakan 1500 Bytes. Namun Header IP dan Header UDP memerlukan 20 + 8 byte, jadi kita harus menggunakan 1472 sebagai gantinya 5 . Hal ini dikonfirmasi dalam simulasi; penggunaan paket 1500 byte dapat membahayakan kinerja throughput.
BulkSendApplication"Generator lalu lintas ini hanya mengirimkan data secepat mungkin hingga MaxBytes atau hingga aplikasi dihentikan (jika MaxBytes nol). Setelah buffer pengiriman lapisan bawah terisi, ia menunggu hingga ruang kosong untuk mengirim lebih banyak data, yang pada dasarnya menjaga a aliran data yang konstan.".
Kami menetapkan MaxBytes ke Total Bytes (PacketCount * PacketSize) dari UDP untuk membandingkan kinerja dan SendSize tidak menjadi masalah pada beberapa eksperimen
Disebut juga InternetStackHelper yang biasanya mencakup UDP, Socket TCP, IPv4, dan untuk tujuan kita saat ini TrafficControlLayer , yang mencakup antrian dan bila sudah penuh maka akan memberitahukan lapisan atas
Ini berhubungan dengan perangkat keras (Kartu Antarmuka Jaringan, NIC) dan driver perangkat lunaknya dan juga termasuk antrian untuk paket, jadi ada dua tingkat antrian di ns-3
Ini adalah host akhir tempat kita dapat menginstal Application , InternetStack , dan NetDevice , mirip dengan komputer kita. Kami akan membuat dua Node dan menghubungkannya dengan sesuatu yang mirip dengan kabel ethernet.
Menyediakan saluran komunikasi ke Node dan kami akan menggunakan saluran CSMA (seperti Ethernet). Detail penting di sini adalah pilihan atribut yang tersedia untuk penyesuaian: MTU, DataRate, dan Delay. Kami akan menggunakan MTU standar (tanpa frame Jumbo, terkadang tersedia untuk jaringan tertentu), gigabit dan penundaan 2 mikrodetik. Alasan mengapa 2 mikrodetik adalah cahaya menempuh jarak 600m, dibandingkan dengan penelitian lain yang menggunakan penundaan 0.
lembaran baru
Hasilnya adalah sebagai berikut:
Kami mengamati bahwa throughput untuk UDP untuk 14720, 147200 Bytes yang dikirim melebihi 1000Mbps (Bandwidth kami adalah 1Gbps). Kami kemudian melihat hilangnya paket
Kita dapat melihat bahwa dalam 147200 Byte, 97 dari 100 paket hilang. Dapat dikatakan bahwa kita harus menghentikan kedua hal ini dan menyelidikinya lebih lanjut
Kita juga dapat melihat bahwa throughput TCP meningkat secara bertahap dan mendatar di sekitar 400Mbps.
Karena kurangnya kontrol lalu lintas, paket UDP dapat "terjebak" di antrian lapisan bawah. Hal ini mungkin juga disebabkan oleh pengiriman paket yang selalu cepat dan menyebabkan kemacetan. Investigasi lebih lanjut perlu dilakukan untuk memastikannya, seperti menurunkan buffer untuk melihat apakah penundaan benar-benar meningkat.
Penundaan rata-rata menunjukkan penurunan tepat setelah "puncak" dan kemudian meningkat lagi secara bertahap. Hal ini mungkin disebabkan oleh penyesuaian cwnd dalam menghindari kemacetan. Penyelidikan lebih lanjut diperlukan karena kita perlu memastikan algoritma untuk pengendalian kemacetan benar-benar menghasilkan pola seperti itu karena ada banyak pilihan di ns-3 (Veno, Cubic... dll)
Jitter rata-rata diperkirakan akan menurun seiring dengan stabilnya sistem dan variasi penundaan akan berkurang.
Tidak adanya kontrol lalu lintas di UDP berarti bahwa paket-paket akan terus-menerus ditekan ke bawah tumpukan dan dikirim tanpa gangguan, variasi penundaan harus minimal sementara penundaan paket-paket berturut-turut bisa besar karena kontrol lalu lintas tersebut.
lembaran baru
BulkSendApplication memastikan bahwa setelah buffer pengiriman lapisan bawah terisi, ia akan menunggu. Jadi satu-satunya tempat kita bisa menjatuhkan paket adalah di saluran dimana kita perlu memasukkan kesalahan ke dalamnya.
UDPClient tidak memiliki kontrol lalu lintas sehingga kami dapat mengamati hilangnya paket.
Mungkin saja throughput (throughput lebih besar) dan jitter (variasi penundaan lebih sedikit). Penundaan rata-rata yang lebih besar terutama disebabkan oleh kurangnya kontrol lalu lintas yang mana QUIC bertujuan untuk memindahkan “algoritma kontrol kemacetan ke dalam ruang pengguna … daripada ruang kernel” 1 .
https://github.com/alfredtso/ns-3-project
lembaran baru
ns-3 sumber pelatihan
Draf HTTP/3
CEPAT ↩ ↩ 2
GoogleDoc QUIC ↩
Yuan-Cheng Lai, Ahsan Ali, Md. Shohrab Hossain, Ying-Dar Lin, Pemodelan kinerja dan analisis aliran TCP dan UDP melalui jaringan yang ditentukan perangkat lunak, Jurnal Jaringan dan Aplikasi Komputer, Volume 130, 2019, Halaman 76-88, ISSN 1084-8045 ↩
Jingyi He, S.-H.Gary Chan, Kinerja TCP dan UDP untuk Internet melalui jaringan packet-switched optik, Jaringan Komputer, Volume 45, Edisi 4, 2004, Halaman 505-521, ISSN 1389-1286 ↩
Eric Gamess, Rina Surós, Model batas atas untuk throughput TCP dan UDP di IPv4 dan IPv6, Jurnal Aplikasi Jaringan dan Komputer,Volume 31, Edisi 4, 2008, Halaman 585-602, ISSN 1084-8045 ↩ ↩ 2
Shahrudin Awang Nor, Raaid Alubady, Wisam Abduladeem Kamil, Simulasi kinerja protokol TCP, SCTP, DCCP dan UDP melalui jaringan 4G, Procedia Computer Science, Volume 111, 2017, Halaman 2-7, ISSN 1877-0509 ↩
