Informasi Keliru tentang TCP yang Dipercaya Programmer

• Seperti NetworkManager yang menilai ketidakstabilan koneksi sesaat sebagai “tidak ada jaringan”, sebagian perangkat lunak lebih memercayai penilaian statusnya sendiri daripada pemulihan TCP, tetapi ini bisa berbahaya di jaringan nyata
• Keyakinan bahwa “data yang dikirim akan tiba”, “kedua pihak pada akhirnya akan sepakat tentang byte yang telah terkirim”, atau “jaminan itu bisa diberikan lewat protokol aplikasi seperti HTTP atau SMTP” dapat runtuh dalam situasi tertentu
• Jika koneksi terputus saat ACK sedang diproses, pengirim tidak dapat mengetahui apakah segmen tersebut diterima, dan batasan ini tidak bisa diselesaikan hanya dengan satu stream TCP dua pihak, mirip Two Generals’ Problem
• SMTP juga membahas masalah ini dalam RFC 1047 dan RFC 2821; pada saat tanggung jawab pengiriman berpindah, ada zona ambigu ketika kegagalan koneksi dapat menyebabkan pengiriman ganda atau pesan hilang
• Jika jaringan aneh dianggap pengecualian, atau detail perilaku seperti algoritme Nagle, congestion control, dan pemblokiran ICMP diabaikan, kegagalan nyata mudah disalahartikan

---

Masalah menyimpulkan status jaringan sebelum TCP

• Pengguna NetworkManager pernah mengalami ketidakstabilan koneksi nirkabel di lingkungan asrama dan roaming kampus, dan mendapati bahwa sedikit saja packet loss membuat pesan “tidak ada jaringan” disebarkan ke seluruh sistem
• Saat itu jaringan mungkin akan segera pulih, dan pemulihan TCP biasa, meski disertai lonjakan latensi, bisa tampak transparan bagi aplikasi
• Contoh ini terkait dengan masalah ketika gangguan sementara yang sebenarnya bisa ditangani TCP terlalu cepat ditafsirkan sebagai kegagalan oleh aplikasi atau komponen sistem

Keyakinan umum yang keliru tentang TCP

• Pernyataan berikut sering muncul saat membahas TCP, tetapi masing-masing salah setidaknya dalam beberapa kasus
  • TCP dapat diandalkan, sehingga semua data yang dikirim akan tiba di pihak lawan
  • TCP pada umumnya dapat diandalkan
  • Meski TCP tidak memberikan keandalan dalam arti penuh, pengirim dan penerima pada akhirnya akan sepakat secara tepat byte mana yang telah ditransmisikan
  • Jika protokol aplikasi berorientasi pesan seperti HTTP atau SMTP dibangun di atas TCP, jaminan semacam itu bisa dibuat
  • Ada yang namanya paket TCP
  • Tidak ada yang namanya paket TCP
  • Jika tidak bisa terhubung ke host jarak jauh yang dikenal, berarti sedang offline
  • Algoritme Nagle itu baik
  • Algoritme Nagle itu buruk
  • Algoritme Nagle tidak perlu dipedulikan
  • TCP cukup dipikirkan seperti Unix pipe dua arah yang melewati jaringan
  • Jika jaringan transparan terhadap TCP, maka ia juga transparan terhadap IP
  • Jika jaringan transparan terhadap HTTP/1.1, maka ia juga transparan terhadap TCP
  • Jaringan aneh yang tidak transparan terhadap protokol standar bersifat pengecualian dan boleh diabaikan
  • TCP diimplementasikan di atas IP

Mengapa sulit mencapai kesepakatan tepat tentang byte yang terkirim

• Masalah 1–4 di atas terkait keandalan TCP berhubungan dengan Two Generals’ Problem
• Jika koneksi terputus saat ACK masih diproses, pengirim tidak punya cara memastikan apakah segmen itu telah diterima
• Batasan ini tidak hilang meski lapisan kompleks ditambahkan di atas TCP
• Jaminan ini tidak bisa dibuat di atas satu stream TCP dua pihak; untuk jaminan semacam itu diperlukan pendekatan yang mirip Paxos atau Raft serta sedikitnya 3 node
• Masalah sejenis berlaku bukan hanya untuk TCP, tetapi juga untuk UDP atau layanan dua pihak berbasis IP

Zona abu-abu tanggung jawab pengiriman yang diperlihatkan SMTP

• SMTP adalah layanan yang membuat masalah ini tampak jelas karena kedua pihak harus secara eksplisit memperhatikan apakah pesan telah diterima
• RFC 1047 membahas masalah ini dari sudut pandang SMTP, dan RFC 2821 menetapkan bahwa implementasi harus mengikuti saran inti RFC 1047
• Dalam contoh SMTP, status-status berikut dibedakan
  • Dapat tercapai titik ketika kedua pihak sepakat bahwa email telah dikirim dari klien ke server
  • Dapat juga tercapai titik ketika kedua pihak sepakat bahwa server telah mengambil tanggung jawab pengiriman email
  • Namun sebelum itu, pasti ada kondisi ambigu tentang siapa yang saat ini bertanggung jawab atas pengiriman email
• Jika koneksi terputus dalam kondisi ambigu ini, email akan menjadi duplikat atau hilang
• Spesifikasi SMTP menentukan pihak yang harus menduplikasi email, tetapi tidak diketahui sejauh mana hal itu telah diuji dalam implementasi nyata
• Tujuan Paxos dan Raft bukan semata-mata mencapai status akhir itu sendiri, melainkan mencegah kondisi ambigu seperti ini

Batas pengetahuan yang tersisa dalam kesepakatan dua pihak

• Sebuah komentar berpendapat bahwa bahkan pada link yang tidak andal tetapi tidak berniat jahat, dua pihak dapat sepakat untuk sebagian himpunan byte bahwa “byte itu telah terkirim dan kedua pihak mengetahui fakta tersebut”
• Dalam diskusi lanjutan, disimpulkan bahwa salah satu pihak bisa mengetahui bahwa himpunan yang disepakati setidaknya mencakup N byte pertama, tetapi tidak bisa mengetahui bahwa himpunan yang disepakati persis N byte pertama
• Karena itu, meski bisa ada himpunan byte yang “pasti terkirim dan diketahui kedua pihak”, setelah itu tetap ada zona abu-abu tempat pengirim dan penerima tidak bisa memastikan kondisi pengetahuan satu sama lain
• Jika perbedaan ini terlewat, kegagalan aneh mudah terjadi dalam sistem terdistribusi

Jebakan jaringan nyata dan lapisan bawah

• Keyakinan bahwa “jaringan aneh yang tidak transparan terhadap protokol standar boleh diabaikan” telah berkali-kali menimbulkan masalah
• Buffer bloat dibahas sebagai contoh router yang merusak mekanisme congestion control
• Jaringan yang memblokir ICMP atau menjatuhkan trafik yang tidak dipahaminya juga bisa menjadi masalah
• Keyakinan bahwa “tidak perlu memahami congestion control” juga dekat dengan contoh kesalahpahaman tentang TCP
  • Sebagai subcontoh, muncul gagasan bahwa “jika kecepatan yang diinginkan tidak tercapai, cukup buka beberapa koneksi TCP”