Mengapa Sebaiknya Tidak Menyesuaikan Pemikiran TCP dengan UDP

Tags:
Categories:
  • Mengapa Sebaiknya Tidak Menyesuaikan Pemikiran TCP dengan UDP

Mengapa Sebaiknya Tidak Menyesuaikan Pemikiran TCP dengan UDP?

Perbedaan Struktur

TCP Header
UDP Header

TCP memiliki banyak konsep: setup koneksi, penggunaan sumber daya, pengiriman data, pengiriman yang andal, pengiriman ulang berdasarkan konfirmasi ulang kumulatif, pengiriman ulang timeout, checksum, kontrol aliran, kontrol congestion, ukuran segmen maksimum, konfirmasi selektif, opsi skala jendela TCP, timestamp TCP, pengiriman data paksa, mengakhiri koneksi.

Kemampuan di atas, UDP pada dasarnya tidak memiliki apa pun. Ia hanya sedikit lebih memiliki kemampuan untuk membedakan tujuan pada lapisan aplikasi di lapisan di atas. UDP yang cukup sederhana berarti cukup fleksibel.

Jika Memungkinkan, Pasti Akan Terjadi

Hukum Murphy:

Jika ada lebih dari satu cara untuk melakukan sesuatu, dan salah satu dari cara tersebut akan menyebabkan bencana, maka pasti ada orang yang memilihnya.

Biasanya, UDP disebut cocok untuk aplikasi seperti game, suara, video, dan seterusnya. Sedikit paket hilang tidak mempengaruhi bisnis. Mengapa UDP cocok untuk skenario ini? Faktanya, UDP bisa digunakan di skenario ini, tetapi itu tidak berarti itu adalah solusi terbaik. Tentu saja, ada masalah yang tidak dapat diselesaikan TCP, sehingga layanan memilih protokol UDP yang sederhana. Jika diperluas ke bisnis, paket hilang tidak mempengaruhi TCP, sedangkan UDP tidak mempedulikan paket hilang. Lebih mempedulikan real-time/kontinuitas. Karakteristik UDP adalah ia tidak peduli pada faktor yang diperhatai TCP, karena faktor tersebut mempengaruhi real-time.

Dalam implementasi kode, UDP hanya perlu membuat socket, mengikatnya ke port tertentu, maka dapat mulai mengirim dan menerima. Biasanya, saat socket selesai digunakan, port juga selesai digunakan.

Jadi saya dapat menggunakannya dengan cara ini:

  1. Kirim paket acak ke port mana pun pada IP apa pun, lihat port mana yang memiliki respons
  2. A melalui port A, mengirim paket permintaan ke port B milik B; B mengirim paket respons ke port D milik A menggunakan port C
  3. A melalui port A, mengirim paket permintaan ke port B milik B; B mendelegasikan C untuk mengirim paket respons ke port D milik A menggunakan port C
  4. A melalui port A, mengirim paket permintaan ke port B milik B, tetapi mengubah IP sumber paket yang dikirim menjadi IP milik C, maka B akan mengirim paket respons ke C
  5. Keduanya berunding untuk masing-masing menggunakan 10 port UDP, secara bersamaan melakukan penerimaan dan pengiriman

Metode ini pada TCP tentu tidak akan berhasil, tetapi dalam protokol UDP, asalkan memungkinkannya, pasti ada orang yang melakukannya. Jadi, memasukkan pemikiran dari beberapa konsep TCP ke UDP adalah idealisme. Realita sering kali tidak dapat kita enumerasikan.

Paket UDP sangat sederhana, dan penggunaannya sangat fleksibel. Pada awalnya tidak ada konsep koneksi, sehingga perlu mendefinisikan koneksi UDP sendiri. Sudah mencoba beberapa metode definisi, semuanya tidak dapat sepenuhnya secara akurat mencapai niat deteksi arah. Saat itu perlu menerima beberapa ketidaksempurnaan. Karena pada dasarnya tidak ada definisi koneksi UDP, ketika pihak-pihak memiliki definisi koneksi UDP yang berbeda, perilaku tidak akan sesuai harapan.

UDP dari Perspektif Klien

Layanan suara, video, dan lainnya sering mengalami paket hilang, tetapi pola hilang yang berbeda memiliki dampak yang berbeda. Misalnya, kehilangan 30% yang tersebar rata, atau seluruhnya terjadi di periode tertentu, dampaknya terhadap pengalaman jelas berbeda. Dengan jelas, kami mengharapkan kehilangan yang lebih rata. Namun UDP tidak memiliki metode pencegahan kontrol aliran, bagaimana cara mengelakkan kehilangan? Ada beberapa metode. Meskipun komunikasi UDP sering disebut “berusaha terbaik”, upaya yang berbeda menghasilkan efek yang berbeda.

UDP dari Perspektif Penyedia Layanan

Jika terjadi serangan TCP, klien membutuhkan biaya overhead, membuat dan memelihara koneksi, artinya attacker harus mengeluarkan biaya tertentu. Sedangkan dalam serangan UDP, biaya yang dikeluarkan attacker jauh lebih kecil. Jika attacker ingin menguras bandwidth server, UDP adalah cara yang baik. Misalnya, layanan membeli 100 GB bandwidth tanpa batas, kapasitas 10 MB per detik, tetapi kecepatan penerimaan 1 GB per detik, maka 90% trafik permintaan tidak valid, tetapi tidak gratis. Layanan seharusnya menghindari hal ini.

UDP dari Perspektif Operator

Sebuah komunikasi mencakup beberapa terminal dan saluran komunikasi. Yang sering dipertimbangkan adalah server dan klien, tetapi perspektif operator juga sama penting. Dalam serangan DDoS, kami sering khawatir tentang konsumsi sumber daya server, sebenarnya sumber daya operator juga terbatas. Jika server hanya tidak merespons dengan sederhana, tetapi trafik yang diterima sudah menguras bandwidth, sumber daya ini biasanya milik operator. Dalam pengujian tekanan, kami sering menggunakan metrik “tingkat kehilangan paket”, yang mewakili kehilangan dalam seluruh rantai komunikasi, bukan hanya kehilangan server. Operator juga kehilangan paket. Dari perspektif operator, layanan hanya membeli bandwidth 1 MB/s, tetapi klien mengirim dengan kecepatan 1 GB/s, keduanya tidak perlu membayar untuk trafik yang tidak berguna, operator yang menanggung biaya bandwidth tersebut. Oleh karena itu, operator pasti akan mencari cara menahan trafik seperti itu, yaitu UDP QoS. Dalam TCP ada kontrol congestion, tetapi dalam UDP, operator dapat mengontrol trafik melalui kehilangan paket. Dalam kasus nyata, operator lebih sederhana dan agresif, langsung menahan trafik port yang lama digunakan, yaitu UDP port blocking. Dalam pengujian panggilan sebenarnya WeChat, ditemukan bahwa setiap panggilan klien menggunakan beberapa port, di mana satu port UDP berkomunikasi dengan 6 port UDP server yang sama, dugaan adalah untuk menghadapi penahanan port operator.

Kesimpulan

Representasi fleksibel UDP dalam implementasi suatu tujuan memiliki beberapa cara implementasi, dan semuanya sah, asalkan akhirnya dapat mencapai komunikasi yang stabil, apa pun cara implementasinya dan betapa jauh berbeda dengan TCP, itu dianggap “ada berarti wajar”. Oleh karena itu, kami tidak dapat secara sepenuhnya menerapkan konsep TCP ke UDP, bahkan untuk desain produk, menciptakan definisi koneksi UDP baru, juga seharusnya dapat memperkirakan dan mengizinkan kesalahan, karena “menerima kesalahan” adalah fungsi inti UDP, ini adalah keunggulan UDP, bukan kelemahannya. Ini adalah kemampuan inti protokol yang dipilih secara aktif oleh layanan, bukan kelemahan yang harus diterima.

Baca Lebih Lanjut