Apa yang terjadi jika tidak menggunakan TCP atau UDP?

• Infrastruktur jaringan terdiri dari switch, bridge, router, load balancer, firewall, dan lain-lain
• Sistem operasi mengendalikan komunikasi jaringan dengan mengklasifikasikan paket, menempatkannya ke antrean, menerapkan aturan firewall, dan sebagainya
• Lalu, apa yang terjadi jika menggunakan protokol lapisan transport yang tidak ada?
• Apakah OS akan mengizinkannya? Apakah paket benar-benar akan terkirim? Apakah firewall akan memblokirnya?
• Hal ini diverifikasi melalui eksperimen langsung

Gambaran umum protokol internet

• Internet bekerja dengan cara data dikirim melalui beberapa lapisan protokol
• Saat aplikasi mengirim permintaan, OS membungkusnya dengan header dari berbagai lapisan jaringan lalu mengirimkannya
• Lapisan transport (Transport Layer): di sinilah protokol seperti TCP(6) dan UDP(17) berada
• Apa yang akan terjadi jika field Protocol pada header IP diubah untuk memasukkan nomor yang tidak digunakan?

Eksperimen #1: pengujian langsung di PC saya

Metode eksperimen

1. Mendefinisikan HDP (protokol palsu): merancang protokol lapisan transport baru yang sepenuhnya berbeda dari protokol yang ada
2. Mengimplementasikan server dan klien: mengembangkan program untuk mengirim dan menerima paket
3. Uji loopback: mengamati bagaimana OS memproses paket secara internal

Proses eksekusi

$ sudo cargo run --bin server  # menjalankan server  
$ fortune | cowsay | sudo cargo run --bin client 127.0.0.1  # menjalankan klien  

Hasil

• OS memproses paket HDP dengan normal dan paket diterima kembali melalui antarmuka loopback
• Pengujian tambahan dilakukan dengan mengubah nomor protokol IP
  • 1 (ICMP), 2 (IGMP), 6 (TCP) → tidak terdeteksi di server
  • 50, 51 (protokol terkait IPSec) → pengiriman diblokir langsung di sisi klien
  • 256 (melewati rentang nomor protokol IP) → terjadi error pada tahap pemanggilan socket()

Analisis penyebab

• Ada kasus ketika OS memblokir nomor protokol tertentu karena dicadangkan secara sistem
• Di Darwin (macOS berbasis BSD), jika protocol=0 ditetapkan saat memanggil socket(), sebagian paket akan difilter secara otomatis
• Protokol terkait IPSec kemungkinan besar diblokir karena alasan keamanan
• Karena nomor protokol IPv4 adalah 8-bit, hanya nilai 0–255 yang valid

Eksperimen #2: mengirim paket lewat internet

Rencana eksperimen

1. Menyiapkan VPS DigitalOcean: membangun lingkungan eksperimen di server cloud yang berada di Frankfurt, Jerman
2. Mengirim paket HDP: mengirim paket dari PC saya (Arab Saudi) ke server DigitalOcean
3. Menganalisis respons perangkat jaringan: memeriksa apakah paket sampai dan apakah firewall memblokirnya

Hasil yang diperkirakan

• Paket HDP mungkin akan terkirim dengan normal, atau bisa juga diblokir oleh sebagian ISP atau firewall DigitalOcean

Hasil aktual

• Hanya paket pertama yang terkirim, dan paket berikutnya diblokir
• Hasil verifikasi menggunakan tcpdump:
  • Paket terkirim dengan normal dari PC saya
  • Di server DigitalOcean, hanya paket pertama yang terdeteksi
  • Paket-paket berikutnya diblokir di suatu titik (NAT, firewall, ISP, dan lain-lain)

Analisis penyebab

• DigitalOcean tidak mendukung protokol IP nonstandar
• Penyebab utamanya kemungkinan besar adalah kebijakan firewall penyedia cloud
• Mengapa hanya paket pertama yang sampai masih belum jelas

Uji ulang di AWS

• Eksperimen diulang di AWS menggunakan dua instance
• Di dalam data center yang sama, paket HDP dapat dikirim dan diterima dengan normal
• Namun, saat dikirim melalui internet, masalah yang sama seperti di DigitalOcean terjadi: hanya paket pertama yang sampai

Isu utama

• NAT (Network Address Translation): bekerja berdasarkan port TCP/UDP, sehingga tidak punya cara untuk menangani protokol baru seperti HDP
• Firewall/filtering jaringan: sebagian besar ISP dan penyedia cloud memblokir protokol IP yang tidak disetujui
• Masalah optimasi perangkat jaringan: beberapa perangkat jaringan mungkin langsung membuang paket nonstandar

Kesimpulan: menggunakan TCP dan UDP adalah pilihan terbaik

• Implementasi network stack berbeda antar-OS
  • Cara kerja socket() di Linux, macOS, dan Windows berbeda-beda
• Firewall dan perangkat NAT memblokir protokol nonstandar
  • Meskipun bisa bekerja di jaringan pribadi, di internet hal ini hampir mustahil
• Tidak ada peningkatan performa
  • Sudah ada alternatif yang terbukti seperti QUIC yang dibangun di atas UDP
• Gunakan TCP/UDP
  • Dengan memakai protokol standar, NAT berbasis port, firewall, routing, dan sebagainya akan didukung secara otomatis

Materi tambahan

• Spesifikasi protokol UDP
• Daftar nomor protokol IP
• Perbedaan raw socket antar platform

[junhochoi]

Membaca https://www.saturnsoft.net/network/2019/03/21/quic-http3-1/ juga sepertinya akan membantu.

[secret3056]

Saya ingat saat bermain multiplayer StarCraft lama lewat Hamachi, ada IPX, dan waktu itu saya benar-benar penasaran apa sebenarnya itu.

[secret3056]

Kalau dipikir-pikir, NAT akan memblokir semuanya... Jika IPv6 benar-benar sudah mapan dan NAT hilang sepenuhnya (meski sepertinya itu tidak akan terjadi), mungkin saja komunikasi dengan protokol buatan sendiri juga bisa dilakukan.

[tujuc]

Oh, ini percobaan yang bagus...
Upaya yang mengguncang fondasi jaringan memang bagus, tetapi semua perangkat jaringan di dunia ini hanya memiliki perangkat yang dioptimalkan untuk TCP/UDP...

Saat belum tahu bahwa perangkat jaringan itu diproduksi seperti cetakan... mungkin terasa bisa dilakukan... tetapi begitu mengetahuinya, jadi paham bahwa kecuali saya sukses besar lalu membuat semua orang memakai protokol saya, hal seperti itu tidak akan bisa dilakukan...

[GN⁺]

Komentar Hacker News

• Ada SCTP, protokol lama yang lebih unggul daripada TCP tetapi tidak diadopsi
  • Karena perangkat keras jaringan memblokir semua selain TCP dan UDP
• Sebagai orang yang telah mengimplementasikan berbagai protokol transport, hambatan terbesar untuk menambahkan lapisan di atas IP bukanlah router WAN melainkan perangkat NAT konsumen
  • Pada router Netgear tertentu, lalu lintas tetap bertahan sampai ujung, tetapi terjadi kerusakan spesifik di mana 4 byte pertama berubah menjadi 0
  • Diduga ini diperlakukan sebagai TCP/UDP tetapi jalur translasi sebenarnya tidak diikuti
• Jika tidak menggunakan TCP atau UDP, komunikasi akan sulit
  • Internet menjadikan TCP dan UDP sebagai standar
  • Banyak perangkat tidak bisa menangani protokol lain
  • Mengganti seluruh perangkat keras internet akan memakan waktu lebih lama daripada menghentikan IPv4
  • Harus ada keuntungan besar dari protokol baru agar semua perusahaan dan pemerintah mau mengeluarkan biaya besar untuk mengimplementasikan dukungannya
• Akhir artikelnya terasa seperti cliffhanger
  • Penasaran mengapa hanya satu paket dari protokol kustom yang lolos dan sisanya dibuang
• Saya kira paket TCP/UDP hanya diteruskan oleh network stack OS ke proses yang mendengarkan port tertentu
  • Ini mungkin fitur keamanan, dan proses tanpa izin tidak bisa mendengarkan beberapa port
  • Saya tidak menyangka proses lain bisa menangkap semua lalu lintas
  • Saya tidak tahu apakah lalu lintas dari beberapa protokol lapisan transport bisa ditangkap
  • Mungkin system call terkait memang memerlukan hak akses tinggi
• Saya penasaran seperti apa jadinya jika protokol internet dan perangkat routing dirancang dari awal hari ini
  • Paket yang jauh lebih besar dan protokol dasar bergaya UDP akan menggantikan HTTP
  • Protokol streaming sederhana akan menggantikan TCP dan mendukung pemutaran video
  • Kedua protokol ini akan menangani sebagian besar lalu lintas dengan lebih efisien
• Ini adalah asumsi "bagaimana kalau kita menemukan kembali roda?"
• Diperlukan packet socket
  • Jaringan IP seharusnya meneruskan semuanya, tetapi NAT adalah masalah utama
  • Akan menarik untuk mencobanya dengan IPv6
• Kita mungkin akan menggunakan protokol lain dari masa sebelum TCP/UDP/IP menguasai segalanya
• Semua orang akan memakai UUCP
  • Ia melakukan pekerjaan serupa sebelum TCP/UDP