इंटरनेट की मूल शक्ति, TCP

 (cefboud.com)
19 पॉइंट द्वारा GN⁺ 2025-11-16 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • TCP(Transmission Control Protocol) इंटरनेट का एक मूल प्रोटोकॉल है, जो अस्थिर नेटवर्क वातावरण में भी विश्वसनीय और क्रमबद्ध डेटा ट्रांसफर संभव बनाता है
  • जहाँ IP केवल होस्ट्स के बीच डेटा डिलीवरी संभालता है, वहीं TCP port-आधारित process-to-process communication और error recovery, retransmission, order control करता है
  • flow control और congestion control के जरिए यह सुनिश्चित करता है कि रिसीव बफ़र या नेटवर्क bandwidth की सीमाएँ पार न हों
  • C भाषा में बनाए गए सरल TCP server और HTTP server उदाहरणों के माध्यम से socket बनाना, bind, listen, connection accept करना, और send/receive प्रक्रिया को विस्तार से समझाया गया है
  • TCP की sequence/ACK numbers, window, checksum, flags(SYN/ACK/FIN/RST) जैसी आंतरिक संरचनाएँ आज के इंटरनेट के स्थिर संचालन की मूल नींव हैं

TCP की आवश्यकता और भूमिका

  • IP केवल hosts के बीच packets की डिलीवरी संभालता है; process-to-process communication के लिए TCP/UDP जैसे transport layer की आवश्यकता होती है
    • IP address की तुलना ‘building’ से और port की तुलना ‘apartment’ से की जाती है, इसलिए हर application किसी port पर bind होकर communication करता है
  • TCP packet loss, duplication, out-of-order delivery जैसी नेटवर्क अस्थिरताओं को छिपाता है और retransmission, checksum आदि से reliability सुनिश्चित करता है
  • routers को सरल रखा जाता है, और reliability communication के दोनों endpoints पर संभाली जाती है, जिससे नेटवर्क infrastructure की जटिलता कम होती है
  • इसी संरचना की वजह से HTTP, SMTP, SSH जैसी प्रमुख इंटरनेट सेवाएँ स्थिर रूप से काम करती हैं

flow control और congestion control

  • receiving side डेटा को अस्थायी रूप से kernel के receive buffer में रखती है, और buffer size net.ipv4.tcp_rmem से सेट होती है
  • sending side को receiving side द्वारा अनुमत डेटा की मात्रा window field के रूप में मिलती है, और उसी के अनुसार transmission की मात्रा नियंत्रित होती है
  • पूरे नेटवर्क में bandwidth के अंतर से होने वाले congestion को रोकने के लिए TCP congestion control algorithms अपनाता है
    • 1986 में हुई congestion collapse घटना के बाद ‘back-off’ mechanism जोड़ा गया

TCP server और HTTP server उदाहरण

  • C भाषा में लिखा गया मूल TCP echo server client input लेकर उसके आगे “you sent:” जोड़कर वापस भेजता है
    • socket(), bind(), listen(), accept(), send(), recv() जैसे Berkeley socket API का उपयोग होता है
    • जब server sleep() में होता है, तब client का डेटा receive buffer में प्रतीक्षा करता है और बाद में क्रम से प्रोसेस होता है
  • एक सरल HTTP/1.1 server उदाहरण में TCP connection के जरिए request स्वीकार की जाती है, और HTTP/1.1 200 OK header तथा body भेजी जाती है
    • request count को i से गिना जाता है, और curl localhost:8080 request पर “[1] Yo, I am a legit web server” जैसे response का आउटपुट मिलता है

TCP segment संरचना और मुख्य fields

  • TCP segment source/destination port, sequence number, ACK number, window size, checksum, flags आदि से बना होता है
    • ports को 16-bit के रूप में allocate किया जाता है, इसलिए अधिकतम 64K ports का उपयोग संभव है
    • connection की पहचान (प्रोटोकॉल, source IP, source port, destination IP, destination port) के 5-tuple से होती है
  • sequence number भेजे गए bytes की range दर्शाता है, और ACK number प्राप्त हो चुके bytes को दर्शाता है
    • यदि कुछ डेटा गायब हो, तो ACK उसी बिंदु पर रुक जाता है, और retransmission के बाद cumulative ACK के रूप में अपडेट होता है
  • flag bits connection state को नियंत्रित करते हैं
    • SYN/ACK के जरिए 3-way handshake से connection स्थापित होता है
    • FIN के जरिए 4-way handshake से connection समाप्त होता है
    • RST असामान्य termination या error की स्थिति में connection को तुरंत बंद कर देता है
  • window field रिसीव की जा सकने वाली डेटा मात्रा दिखाता है, और ss command से buffer status(rb131072, tb16384) देखा जा सकता है
  • checksum segment के भीतर 16-bit इकाइयों के योग के आधार पर error detection करता है

निष्कर्ष

  • TCP reliability, order, integrity सुनिश्चित करता है और अस्थिर इंटरनेट वातावरण में भी applications को सामान्य रूप से काम करने में मदद करता है
  • दशकों पहले कुछ KB ट्रांसफर करना भी कठिन था, लेकिन आज 4K streaming रोज़मर्रा की बात बन चुकी है
  • इस स्थिर communication को संभव बनाने वाली TCP design और implementation की परिष्कृतता ही इंटरनेट की निरंतर वृद्धि की बुनियाद है

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

1 टिप्पणियां

 
GN⁺ 2025-11-16
Hacker News राय

  • अगर आप अविश्वसनीय datagram layer के ऊपर विश्वसनीय data stream बनाने की कोशिश करते हैं, तो नतीजा लगभग TCP जैसा ही निकलता है
    TCP की शुरुआती सीमाएँ छोटी window size, packet loss को ठीक से संभाल न पाना, और सिर्फ एक ही stream को मैनेज करना थीं
    इन्हीं समस्याओं को हल करने के लिए SCTP और QUIC आए
    congestion control algorithm प्रोटोकॉल का हिस्सा नहीं, बल्कि हर connection के दोनों सिरों पर चलने वाला code है
    शुरुआती algorithm (Reno, Vegas आदि) सरल थे, लेकिन काफ़ी प्रभावी थे, और बाद में बड़े buffers, लंबे RTT, fairness आदि से निपटने पर शोध जारी रहा

    • मुझे लगता है कि web developers की भी ज़िम्मेदारी है कि उन्होंने multi-streaming का अच्छा उपयोग नहीं किया
      मैंने पहले JavaScript में एक library बनाई थी जो कई downloads को एक stream पर priority और cancel functionality के साथ कंट्रोल कर सकती थी
      मैंने GreaseMonkey script से dating site के thumbnails को background में पहले से fetch करवाया, और scroll position के हिसाब से preload कराया
      नतीजतन server load कम हुआ और user experience बेहतर हुआ
      मज़ेदार बात यह है कि मैंने वह script एक match के साथ share की थी, और आज तक हम साथ हैं — यानी वह लगभग Tinder से पहले का Tinder था
    • जब TCP बनाया गया था, तब टेलीफोन नेटवर्क-केंद्रित circuit switching सोच हावी थी
      TCP packet-switched network के ऊपर virtual circuit देने वाली संरचना है, और reliability को retransmission से लागू करने का विचार फ्रांस के Cylades network से आया था
    • TCP की बुनियादी खामियों में से एक है कि इसे secure नहीं बनाया जा सकता
      कोई attacker नेटवर्क में कहीं से भी data inject कर सकता है या RST packet से connection तोड़ सकता है
      firewall से RST को block करने पर stability बढ़ती है, लेकिन forged sequence numbers से होने वाला desynchronization attack फिर भी संभव रहता है
      इसलिए हर application को अलग connection पर resume functionality लागू करनी पड़ती है, और TCP के slow start की समस्या भी साथ झेलनी पड़ती है
      साथ ही, address और port को अलग अवधारणाओं की तरह रखना भी मुझे अक्षम लगता है
    • कुछ applications एक ही TCP connection पर भी काफ़ी अच्छे से काम करती हैं
      उदाहरण के लिए DNS over TLS(DoT) में एक TCP connection पर कई queries एक साथ भेजी जा सकती हैं और responses बिना क्रम की परवाह किए मिल सकते हैं
      यह कई connections खोलने से ज़्यादा efficient और शालीन तरीका है
      QUIC तेज़ होगा या नहीं, यह पता नहीं, लेकिन server support अभी भी सीमित है
      HTTP/1.1 pipelining से भी ऐसा कुछ किया जा सकता है, लेकिन responses क्रम से आते हैं
    • TCP के congestion control algorithm का protocol के बाहर होना उस समय के हिसाब से बहुत innovative था
      लेकिन कई university courses में इस बात पर ज़ोर नहीं दिया जाता, इसलिए लोग अक्सर यह समझ लेते हैं कि TCP में सिर्फ एक ही algorithm होता है

  • मैं पूछना चाहता हूँ कि क्या किसी को SCTP से लगाव है
    SCTP ऐसा protocol है जो UDP की message-oriented प्रकृति और TCP की reliability को जोड़ता है, और multistreaming व multihoming को support करता है
    कई स्वतंत्र streams को parallel में भेजा जा सकता है, इसलिए web page का text और images एक साथ भेजे जा सकते हैं
    अधिक जानकारी के लिए Wikipedia: Stream Control Transmission Protocol देखें

    • SCTP समस्या का सिर्फ आधा हिस्सा हल करता है, और कई नई खामियाँ भी ले आता है
      आख़िरकार सबसे अच्छा जवाब है UDP के ऊपर reliability layer, यानी QUIC
    • BSD का शौक़ीन और Erlang के साथ काम करने वाले व्यक्ति के रूप में, मुझे SCTP बहुत पसंद है

  • मुझे जिज्ञासा थी कि क्या सिर्फ IP के साथ सीधे packets भेजे जा सकते हैं
    लगा था कि बीच के routers TCP या UDP के अलावा दूसरे packets को reject कर देंगे

    • आप सीधे IP packets को manipulate करके transmit कर सकते हैं
      IPv4 में IANA protocol number list से 0~255 में से कोई एक चुनना होता है
      core routers इस field को नहीं देखते, लेकिन NAT या ISP उपकरण देख सकते हैं
      दो Linux servers के बीच experimental numbers (253, 254) से भी communication संभव है
    • ICMP को भी नहीं भूलना चाहिए। IPv6 में यह और भी महत्वपूर्ण है
      IPsec, GRE, L2TP जैसे protocols भी TCP/UDP नहीं हैं
      enterprise network के firewall या NAT environment में मनमाने protocols block हो सकते हैं
      NAT ने end-to-end principle को तोड़ दिया, और आख़िरकार लोगों ने सब कुछ TCP या UDP के ऊपर, या फिर HTTP के ऊपर रखना शुरू कर दिया
    • अगर NAT या load balancer न हो तो कोई समस्या नहीं, लेकिन आजकल ये आम हैं, इसलिए IPv6 बेहतर हो सकता है
    • router layer 3 device होते हैं, इसलिए वे TCP/UDP होने या न होने की परवाह नहीं करते
      हाँ, ECMP hash की entropy कम होने जैसा थोड़ा असर हो सकता है
      आख़िरकार असली सवाल यह है कि सामने वाला उस protocol को समझता है या नहीं
    • TCP और UDP सिर्फ IP payload हैं, और routers इन्हें parse नहीं करते
      port number सिर्फ node के अंदर service identifier होते हैं

  • RUDP(Plan9) TCP और UDP के बीच एक शानदार समझौता था
    Reliable User Datagram Protocol देखें

  • TCP default बन गया, इसलिए reliability या ordering की ज़रूरत न होने पर भी लोग उसी का उपयोग करते रहे
    अब HTTP/3(QUIC आधारित) के फैलने से स्थिति बेहतर हो सकती है
    हालांकि QUIC कहीं ज़्यादा जटिल है, और उसकी ताकत सिर्फ कुछ लोगों के लिए ही उपयोगी है
    UDP + WireGuard style की सरल encryption layer शायद बेहतर विकल्प हो सकती है

  • TCP मानवता के महान आविष्कारों में से एक है, लेकिन इसने semi-connected network (NAT-आधारित) के प्रभुत्व की कल्पना नहीं की थी

    • किसी ने पूछा, “क्या तुम NAT की बात कर रहे हो?”
    • अगर 1981 में लौटकर आप कहते कि “दुनिया-भर के addresses की जगह सीमित range के addresses इस्तेमाल करें, और कुछ nodes को inaccessible बना दें,”
      तो उस समय के engineers पूछते कि इसे बेवजह इतना जटिल क्यों बनाया जाए
      आख़िरकार आज की asymmetric link structure और client-server विभाजन जैसी चीज़ें इसी सोच से निकलीं

  • TCP के congestion control algorithm का एक दिलचस्प असर है, जिसके बारे में developers अक्सर नहीं जानते
    नए connection पर data भेजने से शुरुआती transmission धीमा होता है, और speed का बढ़ना latency पर निर्भर करता है
    data center में RTT को कुछ microseconds कम करने भर से भी speed में बड़ा सुधार हो सकता है
    ज़्यादातर TCP stacks speed increase को bytes में नहीं बल्कि segment units में गिनते हैं, इसलिए jumbo frames इस्तेमाल करने पर यह 6 गुना तेज़ बढ़ सकता है
    AWS इसी वजह से low switching latency और jumbo frame support पर बहुत मेहनत करता है
    experts ऐसे tuning करते हैं, लेकिन ज़्यादातर लोग हैरान रहते हैं कि 10Gbps link पर 10Gbps क्यों नहीं मिल रहा

  • IP के ऊपर अपना protocol बनाना बहुत आसान काम हुआ करता था
    सिर्फ 15 साल पहले तक भी Python से सीधे packets assemble करके प्रयोग किए जा सकते थे