प्रोग्रामर TCP के बारे में जिन गलत बातों पर भरोसा करते हैं

 (lwn.net)
3 पॉइंट द्वारा GN⁺ 2024-09-16 | 1 टिप्पणियां | WhatsApp पर शेयर करें

NetworkManager या networkd

  • NetworkManager या networkd

    • उपयोगकर्ता बताते हैं कि उन्होंने wpa_supplicant-आधारित प्रबंधन पर स्विच करने का कारण क्या था
    • TCP के बारे में गलत मान्यताओं की सूची पेश की गई है
    • TCP की विश्वसनीयता को लेकर गलतफहमियों पर चर्चा की गई है

  • TCP के बारे में गलत मान्यताओं की सूची

    • TCP हमेशा विश्वसनीय होता है
    • TCP ज़्यादातर विश्वसनीय होता है
    • TCP विश्वसनीय नहीं है, लेकिन प्रेषक और प्राप्तकर्ता अंततः भेजे गए bytes पर सहमत हो जाएंगे
    • TCP के ऊपर message-oriented protocol बनाने से विश्वसनीयता सुनिश्चित की जा सकती है
    • TCP packet जैसी कोई चीज़ होती है
    • TCP packet जैसी कोई चीज़ नहीं होती
    • रिमोट होस्ट से कनेक्शन विफल हो जाए, तो वह offline है
    • Nagle algorithm अच्छा है
    • Nagle algorithm बुरा है
    • Nagle algorithm की चिंता करने की ज़रूरत नहीं है
    • TCP नेटवर्क को पारदर्शी तरीके से संभालता है
    • अगर नेटवर्क TCP के लिए पारदर्शी है, तो वह IP के लिए भी पारदर्शी होगा
    • अगर नेटवर्क HTTP/1.1 के लिए पारदर्शी है, तो वह TCP के लिए भी पारदर्शी होगा
    • जो नेटवर्क standard protocol के लिए पारदर्शी नहीं होते, वे अपवाद हैं
    • TCP, IP के आधार पर implement किया गया है

  • व्याख्या

    • अगर ACK का इंतज़ार करते समय कनेक्शन टूट जाए, तो प्रेषक को पता नहीं चल सकता कि segment प्राप्त हुआ था या नहीं
    • Paxos या Raft जैसे algorithm की ज़रूरत पड़ती है, और कम से कम तीन nodes चाहिए होते हैं
    • SMTP जैसे protocol में भी यह समस्या होती है

  • अतिरिक्त राय

    • दो पक्ष अनिश्चित लिंक के ज़रिए भी सहमति तक पहुँच सकते हैं
    • भेजे गए bytes के किसी subset पर सहमति बन सकती है
    • सहमत bytes का सेट 0 भी हो सकता है, और समय के साथ बढ़ सकता है
    • Paxos की ज़रूरत नहीं है

  • अतिरिक्त चर्चा

    • सहमत bytes के सेट की सटीक सीमा पता नहीं चल सकती
    • नेटवर्क पारदर्शिता को लेकर गलत मान्यताएँ समस्याएँ पैदा करती हैं
    • ऐसे नेटवर्क मौजूद हैं जो ICMP को block करते हैं या जिन packets को समझ नहीं पाते उन्हें drop कर देते हैं
    • congestion control का ज्ञान आवश्यक है

GN⁺ का सारांश

  • यह लेख TCP की विश्वसनीयता को लेकर गलत मान्यताओं पर चर्चा करता है और नेटवर्क प्रबंधन टूल के चयन से जुड़ी बहस को शामिल करता है
  • यह समझाता है कि TCP की विश्वसनीयता से जुड़ी समस्याएँ Paxos जैसे जटिल algorithm की आवश्यकता पैदा कर सकती हैं
  • यह ज़ोर देता है कि नेटवर्क पारदर्शिता को लेकर गलत धारणाएँ वास्तविक समस्याएँ पैदा कर सकती हैं
  • यह नेटवर्क प्रबंधन टूल चुनते समय विचार करने योग्य कई तत्व प्रस्तुत करता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-09-16
Hacker News की राय

  • "falsehoods programmers believe" फ़ॉर्मैट स्पष्ट नहीं है, इसलिए भ्रम पैदा होता है

    • TCP packets के अस्तित्व को लेकर बहस समझ में नहीं आती
    • यह दार्शनिक भ्रम पैदा करने वाली बात है

  • Ethernet cable को निकालकर फिर से जोड़ने पर भी connection बना रहता है, यह चौंकाने वाला है

    • TCP को इस तरह डिज़ाइन किया गया है कि बम गिरने पर भी काम करे

  • "at most once" या "at least once" delivery guarantee संभव है, लेकिन "exactly once" delivery guarantee असंभव है

    • कई junior developers सोचते हैं कि अगर "exactly once" delivery guarantee नहीं है तो वह bug है

  • अगर ACK outstanding स्थिति में हो और connection टूट जाए, तो sender यह नहीं जान सकता कि segment receive हुआ या नहीं

    • TCP एक bidirectional pipe देता है, और सटीक delivery guarantee की जिम्मेदारी application की होती है
    • अगर HTTP request को response मिलने से पहले रोक दिया जाए, तो sender को मान लेना चाहिए कि request server तक नहीं पहुँचा और नए connection पर फिर से कोशिश करनी चाहिए

  • यह हैरानी होती है कि क्या किसी ने error correction code के बारे में सुना भी नहीं है

    • TCP या Ethernet frame में FEC bytes शामिल होते हैं
    • HTTP over TLS encrypted data frames का उपयोग करता है, और data loss होने पर उन्हें receive नहीं किया जा सकता
    • आधुनिक internet का बड़ा हिस्सा इसी paradigm पर आधारित है

  • data center के अंदर अपना hardware इस्तेमाल करते समय low-level details को नज़रअंदाज़ किया जा सकता है

    • bandwidth limits, packet RPS limits, और latency अब भी महत्वपूर्ण हैं

  • यह लेख पूरा हुआ लेख नहीं है, और HN submission title भ्रामक हो सकता है

  • यह VKontakte में काम करते समय हल करने की कोशिश की गई समस्या की याद दिलाता है

    • metro में message भेजने पर वह server तक पहुँच जाता है, लेकिन response आने से पहले signal कट जाता है
    • client इसे message send failure मानता है और फिर से कोशिश करता है
    • client-generated "random ID" का उपयोग करके समस्या हल की गई
    • Telegram में जब client server से दोबारा connect करता है, तो पिछली connection के दौरान unacknowledged रहे सभी responses भेजे जाते हैं

  • बहुत से लोग यह नहीं समझते कि TCP कोई function call नहीं है

    • हाल ही में एक नया TCP rate limiter बहुत ही खराब स्थिति में जारी हुआ
    • ज़्यादातर containers शायद Bufferbloat समस्या से जूझ रहे होंगे