Mengapa Tidak Boleh Menerapkan Pola Pikir TCP pada UDP
Categories:
- Mengapa Tidak Boleh Menerapkan Pola Pikir TCP pada UDP
Mengapa Tidak Boleh Menerapkan Pola Pikir TCP pada UDP?
Perbedaan Struktur
Konsep pada TCP sangat banyak: pembentukan jalur, penggunaan sumber daya, transmisi data, transmisi handal, retransmisi berdasarkan konfirmasi kumulatif berulang, retransmisi timeout, checksum, kontrol aliran, kontrol kemacetan, ukuran segmen maksimum, konfirmasi selektif, opsi penskalaan window TCP, timestamp TCP, pengiriman data paksa, penutupan jalur.
Semua kemampuan di atas, UDP hampir tidak memilikinya, hanya sedikit lebih dari kemampuan layer link dalam membedakan tujuan aplikasi. UDP cukup sederhana berarti cukup fleksibel.
Jika Bisa Terjadi, Maka Akan Terjadi
Hukum Murphy:
Jika ada lebih dari satu cara untuk melakukan sesuatu, dan salah satu cara akan menyebabkan bencana, pasti akan ada seseorang yang memilih cara tersebut.
Biasanya diperkenalkan bahwa UDP cocok untuk aplikasi pada skenario game/suara/video, sedikit paket salah tidak mempengaruhi bisnis. Mengapa UDP cocok untuk skenario ini? UDP bisa digunakan pada skenario ini, bukan berarti itu solusi optimal untuk skenario tersebut, pasti ada masalah yang tidak bisa diselesaikan oleh TCP, yang membuat layanan-layanan ini memilih protokol UDP yang fungsinya sederhana. Paket salah tidak mempengaruhi bisnis, diperluas berarti TCP peduli pada paket salah, UDP tidak peduli pada paket salah, lebih peduli pada real-time/berkelanjutan. Ciri UDP adalah tidak peduli pada faktor-faktor yang peduli oleh TCP, faktor-faktor ini mempengaruhi real-time.
Dalam implementasi kode, UDP hanya perlu membuat sebuah socket, mengikat pada sebuah port, lalu bisa mulai menerima dan mengirim. Biasanya ketika socket selesai digunakan, port juga selesai digunakan.
Karena itu saya bisa menggunakan UDP seperti ini:
- Mengirim paket acak ke port mana saja di IP mana saja, lihat port mana yang merespons
- A mengirim paket permintaan dari port A ke port B milik B; B mengirim paket respons dari port C ke port D milik A
- A mengirim paket permintaan dari port A ke port B milik B; B menugaskan C untuk mengirim paket respons dari port C ke port D milik A
- A mengirim paket permintaan dari port A ke port B milik B, tetapi mengubah IP sumber paket menjadi IP C, B akan mengirim paket respons ke C
- Kedua belah pihak bernegosiasi masing-masing menggunakan 10 port UDP, menerima dan mengirim secara bersamaan
Metode-metode ini tentu tidak akan berhasil pada TCP, tetapi pada protokol UDP, selama bisa dilakukan, pasti akan ada orang yang melakukannya. Jadi ketika menerapkan beberapa pola pikir TCP pada UDP adalah idealisme, kenyataan sebenarnya sering tidak bisa kita enumerasi sepenuhnya.
Paket UDP sangat sederhana, penggunaannya juga sangat fleksibel, awalnya tidak ada konsep koneksi, perlu mendefinisikan koneksi UDP sendiri. Mencoba beberapa metode definisi, tidak bisa sepenuhnya mencapai maksud penilaian arah koneksi secara akurat, saat ini perlu menerima beberapa toleransi, toh awalnya tidak ada definisi koneksi UDP, ketika definisi koneksi UDP antar pihak tidak konsisten, pasti akan menyebabkan perilaku yang tidak sesuai harapan.
Perspektif UDP dari Klien
Bisnis suara/video sering menghasilkan paket hilang, tetapi cara hilangnya paket yang berbeda memiliki dampak berbeda pada bisnis. Misalnya 30% paket hilang terjadi secara merata, atau hilang seluruhnya dalam periode waktu tertentu, memiliki perbedaan jelas pada pengalaman. Jelas, kita mengharapkan hilangnya paket yang lebih merata. Namun UDP tidak memiliki metode pencegahan kontrol aliran, bagaimana paket hilang maka ada beberapa metode. Meskipun komunikasi UDP sering digambarkan sebagai “sebaik mungkin”, tetapi cara-cara “sebaik mungkin” yang berbeda akan mencapai efek yang berbeda.
Perspektif UDP dari Penyedia Layanan
Jika serangan TCP, klien membutuhkan biaya tertentu, membuat koneksi, memelihara koneksi, artinya penyerang perlu membayar harga tertentu. Tetapi pada serangan UDP, penyerang membayar harga jauh lebih kecil, jika penyerang ingin menghabiskan bandwidth layanan, UDP adalah cara yang baik. Misalnya layanan membeli 100GB traffic tanpa batas kecepatan, kemampuan pemrosesan hanya 10MB per detik, tetapi kecepatan penerimaan 1GB per detik, maka 90% traffic permintaan tidak valid, tetapi traffic ini tidak gratis. Pihak layanan harus menghindari terjadinya situasi seperti ini.
Perspektif UDP dari Operator
Menyelesaikan satu komunikasi perlu mencakup beberapa terminal serta saluran komunikasi, yang selalu menjadi perhatian adalah server dan klien, sebenarnya perspektif operator juga penting. Dalam serangan DDoS, kita sering peduli pada konsumsi sumber daya server, sebenarnya sumber daya operator juga terbatas, server hanya tidak merespons permintaan secara sederhana, tetapi menerima traffic sudah mengonsumsi bandwidth, hanya saja sumber daya ini biasanya milik operator. Kita dalam pengujian tekanan sering menggunakan indikator “tingkat paket hilang”, indikator ini mengekspresikan paket hilang dalam rantai komunikasi lengkap, bukan hanya paket hilang server. Operator juga bisa kehilangan paket. Dalam pandangan operator, pihak layanan hanya membeli bandwidth 1MB/s, tetapi klien mengirim dengan kecepatan 1GB/s, kedua belah pihak tidak perlu membayar untuk traffic yang terbuang, operator menanggung biaya bandwidth ini. Oleh karena itu, operator pasti akan mencari cara untuk memblokir traffic semacam ini, yaitu QoS UDP. Dalam TCP ada kontrol kemacetan, tetapi dalam UDP, operator bisa mengontrol traffic dengan kehilangan paket. Dalam kenyataan, operator lebih sederhana dan brutal, langsung memblokir traffic port yang digunakan dalam waktu lama, yaitu pemblokiran port UDP. Dalam pengujian aktual panggilan WeChat ditemukan, setiap panggilan klien akan menggunakan beberapa port, di antaranya ada satu port UDP akan berkomunikasi dengan 6 port UDP server yang sama, diperkirakan untuk menghadapi pemblokiran port operator.
Ringkasan
Fleksibilitas UDP menunjukkan dalam mencapai satu tujuan, ada berbagai cara implementasi, dan semuanya legal, selama akhirnya bisa mencapai komunikasi stabil, tidak peduli bagaimana implementasinya sangat berbeda dengan TCP, semuanya adalah “ada berarti masuk akal”. Oleh karena itu, kita tidak boleh sepenuhnya menerapkan konsep TCP pada UDP, meskipun untuk desain produk, menciptakan definisi koneksi UDP baru, juga harus bisa memperkirakan dan mengizinkan kesalahan, toh “mengizinkan kesalahan” adalah fungsi inti UDP, ini adalah keunggulan UDP, bukan kekurangannya, adalah kemampuan inti protokol yang dipilih secara aktif oleh layanan, bukan kekurangan yang terpaksa diterima.