Programcıların inandığı yanlış TCP bilgileri

 (lwn.net)
3 puan yazan GN⁺ 2024-09-16 | 1 yorum | WhatsApp'ta paylaş

NetworkManager veya networkd

  • NetworkManager veya networkd

    • Kullanıcı, wpa_supplicant tabanlı yönetime geçme nedenini açıklıyor
    • TCP hakkında yanlış inanışların bir listesini sunuyor
    • TCP'nin güvenilirliğiyle ilgili yanlış anlamaları ele alıyor

  • TCP hakkındaki yanlış inanışlar listesi

    • TCP her zaman güvenilirdir
    • TCP çoğu zaman güvenilirdir
    • TCP güvenilir değildir, ancak gönderen ve alıcı sonunda iletilen baytlar konusunda anlaşacaktır
    • TCP üzerinde mesaj odaklı bir protokol kurmak güvenilirliği garanti edebilir
    • TCP paketi diye bir şey vardır
    • TCP paketi diye bir şey yoktur
    • Uzak ana makineye bağlanma başarısız olursa, bu onun çevrimdışı olduğu anlamına gelir
    • Nagle algoritması iyidir
    • Nagle algoritması kötüdür
    • Nagle algoritmasını dert etmeye gerek yoktur
    • TCP ağı şeffaf biçimde ele alır
    • Ağ TCP'ye karşı şeffafsa IP'ye karşı da şeffaftır
    • Ağ HTTP/1.1'e karşı şeffafsa TCP'ye karşı da şeffaftır
    • Standart protokollere karşı şeffaf olmayan ağlar istisnaidir
    • TCP, IP temel alınarak uygulanır

  • Açıklama

    • ACK beklemedeyken bağlantı koparsa, gönderen segmentin alınıp alınmadığını bilemez
    • Paxos veya Raft gibi algoritmalar gerekir ve en az üç düğüm gerekir
    • Bu sorun SMTP gibi protokollerde de ortaya çıkar

  • Ek görüşler

    • İki taraf belirsiz bir bağlantı üzerinden uzlaşmaya varabilir
    • İletilen baytların bir alt kümesi üzerinde anlaşabilirler
    • Üzerinde uzlaşılan bayt kümesi 0 olabilir ve bu küme büyüyebilir
    • Paxos gerekli değildir

  • Ek tartışma

    • Üzerinde uzlaşılan bayt kümesinin tam aralığı bilinemez
    • Ağ şeffaflığına dair yanlış inanışlar sorunlara yol açar
    • ICMP'yi engelleyen veya anlamadığı paketleri düşüren ağlar vardır
    • Tıkanıklık kontrolü hakkında bilgi sahibi olmak gerekir

GN⁺ özeti

  • Bu yazı, TCP'nin güvenilirliği hakkındaki yanlış inanışları ele alıyor ve ağ yönetim araçlarının seçimine dair tartışmayı içeriyor
  • TCP'nin güvenilirlik sorunlarının, Paxos gibi karmaşık algoritmalar gerektirebildiğini açıklıyor
  • Ağ şeffaflığına dair yanlış inanışların gerçek sorunlara yol açabileceğini vurguluyor
  • Ağ yönetim aracı seçerken dikkate alınması gereken çeşitli unsurları sunuyor

İlgili okumalar

1 yorum

 
GN⁺ 2024-09-16
Hacker News görüşleri

  • "falsehoods programmers believe" formatı net olmadığı için kafa karıştırıcı

    • TCP paketlerinin var olup olmadığına dair tartışma anlaşılmıyor
    • Felsefi bir kafa karışıklığı yaratıyor

  • Ethernet kablosunu çıkarıp tekrar taksanız bile bağlantının korunmasına şaşırılıyor

    • TCP, bombalar düşse bile çalışacak şekilde tasarlanmıştır

  • "at most once" veya "at least once" teslimat garantisi mümkündür, ancak "exactly once" teslimat garantisi imkânsızdır

    • Birçok junior geliştirici, "exactly once" teslimat garantisi yoksa bunun bir bug olduğunu düşünüyor

  • ACK beklemedeyken bağlantı koparsa gönderici segmentin alınıp alınmadığını bilemez

    • TCP çift yönlü bir boru sağlar ve kesin teslimat garantisi uygulamanın sorumluluğundadır
    • Bir HTTP isteği yanıt almadan kesilirse, gönderici isteğin sunucuya ulaşmadığını varsayıp yeni bir bağlantı üzerinden yeniden denemelidir

  • Hata düzeltme kodlarını hiç duymamış olmaları tuhaf geliyor

    • TCP veya Ethernet frame'lerinde FEC baytları bulunur
    • TLS üzerinden HTTP, şifrelenmiş veri frame'leri kullanır ve veri kaybı olursa alınamaz hale gelir
    • Modern internetin büyük bir kısmı bu paradigmaya dayanır

  • Veri merkezi içinde kendi donanımınızı kullanırken düşük seviyeli ayrıntıları göz ardı edebilirsiniz

    • Bant genişliği sınırlamaları, paket RPS sınırları ve gecikme hâlâ önemlidir

  • Bu yazı tamamlanmış bir metin değil ve HN gönderi başlığı yanıltıcı olabilir

  • VKontakte'te çalışırken çözmeye uğraştıkları bir sorunu hatırlatıyor

    • Metroda mesaj gönderildiğinde sunucuya ulaşıyor, ancak yanıt gelmeden önce sinyal kesiliyor
    • İstemci bunu mesaj gönderiminin başarısız olduğu şeklinde algılayıp yeniden deniyor
    • Sorun, istemcinin oluşturduğu "random ID" ile çözülmüş
    • Telegram, istemci sunucuya yeniden bağlandığında önceki bağlantı sırasında onaylanmamış tüm yanıtları gönderir

  • Birçok kişi TCP'nin bir fonksiyon çağrısı olmadığını anlamıyor

    • Yakın zamanda yeni bir TCP hız sınırlayıcı çok hatalı bir durumda yayımlandı
    • Muhtemelen çoğu container Bufferbloat sorunları yaşıyordur