Internet berjalan di atas segelintir protokol inti, dengan TCP dan UDP sebagai tulang punggung yang menangani hampir semua data kita. Tapi apa yang terjadi ketika Anda mencoba menggunakan protokol lain? Sebuah eksperimen menarik mengirimkan paket dengan protokol transport buatan sendiri melintasi internet mengungkapkan batasan tersembunyi dari infrastruktur digital kita dan mengapa inovasi di lapisan transport telah menjadi hampir mustahil.
Osifikasi Protokol: Masalah Tersembunyi Internet
Internet menderita kondisi yang dikenal sebagai osifikasi protokol - di mana penerapan middlebox, firewall, dan perangkat NAT secara luas telah secara efektif mengunci kita untuk hanya menggunakan TCP dan UDP sebagai transport. Meskipun jaringan IP secara teoritis seharusnya dapat meneruskan protokol apa pun, kenyataannya sangat berbeda. Seperti yang dijelaskan oleh seorang komentator, Internet telah terstandardisasi pada TCP dan UDP. Terlalu banyak perangkat di sebagian besar jalur yang tidak akan mampu menangani protokol lain. Osifikasi ini terjadi karena produsen dan operator peralatan jaringan mengoptimalkan untuk protokol yang paling sering mereka lihat, merusak kompatibilitas dengan hal-hal baru atau berbeda.
SCTP (Stream Control Transmission Protocol) menjadi contoh sempurna dari masalah ini. Meskipun secara teknis lebih unggul dari TCP dalam banyak hal, SCTP tetap hampir tidak digunakan di seluruh internet publik.
SCTP sangat menarik karena merupakan salah satu teknologi tulang punggung yang membuat komunikasi dimungkinkan bagi sebagian besar orang di planet ini (karena stack jaringan mobile sangat bergantung padanya), namun secara efektif tidak didukung pada hampir semua perangkat konsumen.
Meskipun SCTP menggerakkan infrastruktur telekomunikasi kritis secara internal, ia tidak dapat melintasi internet publik dengan andal. Paradoks ini menyoroti bagaimana bahkan protokol yang dirancang dengan baik dan terstandardisasi dapat gagal mendapatkan adopsi ketika dihadapkan pada kenyataan bagaimana jaringan sebenarnya dibangun dan dikelola.
Masalah Osifikasi Protokol
- Protokol yang Gagal: SCTP (Stream Control Transmission Protocol) - secara teknis unggul tetapi gagal melewati internet publik
- Masalah NAT: Pengguna rumahan di belakang NAT terbatas hanya pada TCP/UDP
- Strategi Penyelesaian: Membuat terowongan protokol baru di dalam UDP (misalnya, QUIC untuk HTTP/3)
- Kasus Khusus:
- SCTP banyak digunakan dalam infrastruktur jaringan seluler secara internal
- WebRTC menjalankan SCTP melalui DTLS melalui UDP
- Protokol kustom mungkin berfungsi antara server pusat data tetapi gagal melintasi internet publik
Mengapa Protokol Kustom Gagal
- Middlebox menghapus protokol yang tidak dikenal
- Perangkat NAT tidak dapat melacak status koneksi tanpa nomor port
- Alat keamanan perusahaan kehilangan visibilitas
- Firewall memblokir paket yang tidak cocok dengan aliran yang ada
NAT: Hambatan Terbesar Internet
Perangkat Network Address Translation (NAT) merupakan hambatan paling signifikan untuk inovasi protokol. NAT bekerja dengan melacak koneksi menggunakan bidang lapisan transport - khususnya nomor port dalam header TCP dan UDP. Ketika dihadapkan dengan protokol yang tidak dikenal yang tidak memiliki bidang yang familiar ini, sebagian besar perangkat NAT akan mengkonsumsi seluruh alamat IP (dengan cepat menghabiskan alamat yang tersedia) atau hanya menjatuhkan paket.
Batasan ini sangat bermasalah bagi pengguna rumahan. Seperti yang dicatat oleh seorang komentator, Setiap pengguna rumahan berada di belakang NAT. Meskipun Anda dapat mengirim protokol apa pun antara server pusat data, pengguna rumah IPv4 terjebak dengan TCP atau UDP. Bahkan dalam eksperimen yang dijelaskan dalam artikel, paket yang menggunakan protokol kustom terkadang berhasil melewati sekali tetapi dijatuhkan setelahnya, kemungkinan karena firewall tidak dapat mencocokkannya dengan aliran koneksi yang ada.
Masa Depan: Tunneling Protokol dan IPv6
Untuk mengatasi osifikasi, perancang protokol modern telah mengadopsi pendekatan pragmatis: melakukan tunneling protokol baru di dalam UDP. QUIC, yang menggerakkan HTTP/3, mencontohkan strategi ini. Daripada melawan sistem, QUIC merangkul UDP sebagai substrat dan membangun inovasinya di atasnya.
Pendekatan ini menciptakan ketegangan antara inovasi dan keamanan. Administrator jaringan sering menolak perkembangan ini karena mereka merusak alat keamanan yang ada. Seperti yang dijelaskan oleh seorang profesional jaringan, Dari perspektif keamanan perusahaan, ini merusak banyak alat. Anda tidak dapat mendekripsi, tanda tangan IDS/IPS tidak berfungsi, dan Anda kehilangan visibilitas terhadap apa yang terjadi di jaringan Anda.
IPv6 menawarkan beberapa harapan untuk keragaman protokol, karena menghilangkan kebutuhan akan NAT dalam banyak skenario. Namun, bahkan dengan IPv6, firewall dan middlebox mungkin masih memblokir protokol yang tidak dikenal. Transisi ke IPv6 tetap lambat dan membuat frustrasi, dengan banyak jaringan perusahaan masih mengandalkan ruang alamat IPv4.
Eksperimen yang dijelaskan dalam artikel mengkonfirmasi apa yang telah lama dicurigai oleh insinyur jaringan: internet telah menjadi lingkungan yang sangat terspesialisasi yang dioptimalkan untuk serangkaian kecil protokol. Meskipun Anda mungkin beruntung mengirim satu paket dengan protokol eksotis, membangun komunikasi yang andal memerlukan kerja dalam batasan apa yang sebenarnya didukung jaringan, bukan apa yang secara teoritis seharusnya.
Untuk masa yang dapat diperkirakan, TCP dan UDP akan tetap menjadi satu-satunya opsi transport yang layak untuk lalu lintas internet publik, dengan inovasi terjadi terutama melalui tunneling dan pelapisan daripada melalui protokol transport baru.
Referensi: What would happen if we didn't use TCP or UDP?
 |
|---|
| Aturan firewall yang membatasi lalu lintas keluar merepresentasikan kendala jaringan terhadap inovasi protokol |