Informasi TCP Keliru yang Dipercaya Para Programmer

 (lwn.net)
3 poin oleh GN⁺ 2024-09-16 | 1 komentar | Bagikan ke WhatsApp

NetworkManager atau networkd

  • NetworkManager atau networkd

    • Penulis menjelaskan alasan beralih ke pengelolaan berbasis wpa_supplicant
    • Menyajikan daftar keyakinan keliru tentang TCP
    • Membahas kesalahpahaman tentang keandalan TCP

  • Daftar keyakinan keliru tentang TCP

    • TCP selalu dapat diandalkan
    • TCP sebagian besar dapat diandalkan
    • TCP tidak dapat diandalkan, tetapi pengirim dan penerima pada akhirnya akan mencapai kesepakatan tentang byte yang telah ditransmisikan
    • Membangun protokol berorientasi pesan di atas TCP dapat menjamin keandalan
    • Ada yang disebut paket TCP
    • Tidak ada yang disebut paket TCP
    • Jika gagal terhubung ke host jarak jauh, berarti sedang offline
    • Algoritme Nagle itu baik
    • Algoritme Nagle itu buruk
    • Tidak perlu memedulikan algoritme Nagle
    • TCP menangani jaringan secara transparan
    • Jika jaringan transparan bagi TCP, maka juga transparan bagi IP
    • Jika jaringan transparan bagi HTTP/1.1, maka juga transparan bagi TCP
    • Jaringan yang tidak transparan terhadap protokol standar adalah pengecualian
    • TCP diimplementasikan di atas IP

  • Penjelasan

    • Jika koneksi terputus saat ACK masih tertunda, pengirim tidak dapat mengetahui apakah segmen telah diterima
    • Diperlukan algoritme seperti Paxos atau Raft, serta minimal tiga node
    • Masalah ini juga terjadi pada protokol seperti SMTP

  • Pendapat tambahan

    • Dua pihak dapat mencapai kesepakatan melalui tautan yang tidak pasti
    • Mereka dapat mencapai kesepakatan atas subset dari byte yang ditransmisikan
    • Himpunan byte yang disepakati bisa bernilai 0, dan dapat bertambah
    • Paxos tidak diperlukan

  • Diskusi tambahan

    • Tidak mungkin mengetahui rentang tepat dari himpunan byte yang telah disepakati
    • Keyakinan keliru tentang transparansi jaringan menyebabkan masalah
    • Ada jaringan yang memblokir ICMP atau membuang paket yang tidak dipahami
    • Pengetahuan tentang kontrol kemacetan diperlukan

Ringkasan GN⁺

  • Artikel ini membahas keyakinan keliru tentang keandalan TCP, serta mencakup diskusi tentang pemilihan alat manajemen jaringan
  • Masalah keandalan TCP dijelaskan sebagai sesuatu yang memerlukan algoritme kompleks seperti Paxos
  • Ditekankan bahwa keyakinan keliru tentang transparansi jaringan dapat menimbulkan masalah nyata
  • Disajikan berbagai faktor yang perlu dipertimbangkan saat memilih alat manajemen jaringan

Bacaan terkait

1 komentar

 
GN⁺ 2024-09-16
Komentar Hacker News

  • Format "falsehoods programmers believe" terasa tidak jelas sehingga membingungkan

    • Tidak paham perdebatan tentang ada atau tidaknya paket TCP
    • Isinya menimbulkan kebingungan filosofis

  • Terkejut bahwa koneksi tetap bertahan meski kabel Ethernet dicabut lalu disambungkan lagi

    • TCP dirancang agar tetap berfungsi bahkan jika bom jatuh

  • Jaminan pengiriman "at most once" atau "at least once" dimungkinkan, tetapi jaminan pengiriman "exactly once" tidak mungkin

    • Banyak developer junior menganggap tidak adanya jaminan pengiriman "exactly once" sebagai bug

  • Jika koneksi terputus saat ACK masih outstanding, pengirim tidak bisa mengetahui apakah segmen sudah diterima

    • TCP menyediakan pipa dua arah, dan jaminan pengiriman yang akurat adalah tanggung jawab aplikasi
    • Jika permintaan HTTP terputus sebelum menerima respons, pengirim harus mengasumsikan permintaan belum mencapai server dan mencoba lagi lewat koneksi baru

  • Bertanya-tanya apakah penulis belum pernah mendengar tentang error-correcting code

    • Frame TCP atau Ethernet menyertakan byte FEC
    • HTTP over TLS menggunakan frame data terenkripsi, dan jika terjadi kehilangan data maka data tidak bisa diterima
    • Banyak internet modern dibangun di atas paradigma ini

  • Saat menggunakan hardware sendiri di dalam data center, detail tingkat rendah bisa diabaikan

    • Pembatasan bandwidth, batas RPS paket, dan latensi tetap penting

  • Artikel ini bukan tulisan yang sudah selesai, dan judul kiriman HN bisa menimbulkan salah paham

  • Mengingatkan pada masalah yang coba diselesaikan saat bekerja di VKontakte

    • Mengirim pesan di kereta bawah tanah membuat pesan sampai ke server, tetapi sinyal putus sebelum respons tiba
    • Klien menganggap pengiriman pesan gagal lalu mencoba lagi
    • Masalah diselesaikan dengan memakai "ID acak" yang dibuat klien
    • Telegram mengirim semua respons yang belum dikonfirmasi selama koneksi sebelumnya saat klien tersambung kembali ke server

  • Banyak orang tidak memahami bahwa TCP bukan pemanggilan fungsi

    • Baru-baru ini ada pembatas laju TCP baru yang dirilis dalam kondisi sangat buruk
    • Sebagian besar container kemungkinan mengalami masalah Bufferbloat