नेटवर्किंग साक्षात्कार: TCP पैकेट हानि (Packet Loss) का पता कैसे लगाता है और उससे कैसे उबरता है?

प्रॉम्प्ट और दायरा

एक प्रेषक अनुक्रम संख्या 1,000 से शुरू होने वाले पांच लगातार 1,000-बाइट के TCP डेटा सेगमेंट प्रसारित करता है। दूसरा सेगमेंट खो जाता है और अगले तीन प्राप्तकर्ता तक पहुंच जाते हैं। ACK, SACK और पुन: प्रेषण अनुक्रम प्राप्त करें, फिर टाइमआउट, फ़ास्ट पुन: प्रेषण और आधुनिक हानि-पहचान सीमाओं की तुलना करें।

मान लें कि कनेक्शन स्थापित है, सभी पांच सेगमेंट डेटा ले जाते हैं, प्राप्ति (receive) और संकुलन विंडो (congestion window) सभी पांचों को इन-फ़्लाइट रहने की अनुमति देते हैं, प्राप्तकर्ता आउट-ऑफ़-ऑर्डर डेटा को बफ़र कर सकता है, और हैंडशेक के दौरान SACK पर सहमति हुई थी। अनुक्रम संख्याएं बाइट्स की गणना करती हैं, और नीचे दी गई सीमाएं अर्ध-खुली (half-open) हैं। SACK के बिना, संचयी ACK और क्लासिक फ़ास्ट-पुन: प्रेषण तर्क अभी भी मान्य हैं; प्रेषक केवल यह जानकारी खो देता है कि कौन से उच्च-अनुक्रम वाले बाइट्स आ चुके हैं।

यह प्रश्न बैकएंड, इन्फ्रास्ट्रक्चर, SRE, क्लाइंट, नेटवर्किंग और सामान्य सॉफ़्टवेयर-इंजीनियरिंग भूमिकाओं के लिए उपयुक्त है। इसकी मुख्य दक्षता ट्रांसपोर्ट-प्रोटोकॉल स्थिति को प्राप्त करना और सत्यापित करना है, इसलिए श्रेणी general है। यह HTTP/3 क्रॉस-स्ट्रीम अलगाव या TCP स्थापना, समाप्ति और TIME_WAIT के बारे में नहीं पूछता है।

साक्षात्कारकर्ता क्या मूल्यांकन करता है

पहला, क्या उम्मीदवार इकाइयों को सही ढंग से बता सकता है? TCP बाइट्स की संख्या तय करता है। एक सेगमेंट की अनुक्रम संख्या उसके पहले डेटा बाइट की पहचान करती है, और एक संचयी ACK उस अगले बाइट का नाम बताता है जिसकी प्राप्तकर्ता अपेक्षा करता है; यह कोई पैकेट काउंटर नहीं है।

दूसरा, क्या उम्मीदवार एक समयरेखा प्राप्त कर सकता है? एक बार जब दूसरा सेगमेंट गायब हो जाता है, तो बाद के आउट-ऑफ़-ऑर्डर सेगमेंट संचयी ACK को आगे नहीं बढ़ाते हैं, लेकिन वे डुप्लिकेट ACK उत्पन्न करते हैं। तीसरा डुप्लिकेट ACK क्लासिक RFC 5681 फ़ास्ट-पुन: प्रेषण संकेत है। सेगमेंट A को पहली बार स्वीकार करने वाले ACK को डुप्लिकेट के रूप में गिनने से एक गलत (off-by-one) उत्तर बनता है।

तीसरा, क्या उम्मीदवार पुनर्प्राप्ति तंत्रों (recovery mechanisms) को अलग कर सकता है? RTO उन हानियों को कवर करता है जो पर्याप्त ACK फीडबैक उत्पन्न नहीं करती हैं। फ़ास्ट पुन: प्रेषण जल्द ठीक होने के लिए बाद के डेटा द्वारा उत्पन्न डुप्लिकेट ACK का उपयोग करता है। SACK प्राप्त गैर-सन्निहित (noncontiguous) बाइट ब्लॉकों का वर्णन करता है ताकि प्रेषक डिलीवर किए गए डेटा को फिर से भेजने से बच सके, लेकिन यह न तो संचयी ACK को प्रतिस्थापित करता है और न ही स्वतंत्र रूप से संकुलन विंडो को नियंत्रित करता है।

चौथा, क्या उम्मीदवार अनिश्चितता की व्याख्या कर सकता है? पुन: क्रमित करना (reordering) या प्रतिकृति (replication) भी डुप्लिकेट ACK बना सकती है, और एक RTT स्पाइक वास्तविक नुकसान के बिना टाइमआउट का कारण बन सकता है। विश्वसनीय वितरण, हानि पहचान और संकुलन नियंत्रण आपस में क्रिया करते हैं, लेकिन वे अलग-अलग विचार हैं।

पांचवां, क्या उत्तर पाठ्यपुस्तक के नारे से आगे जा सकता है? एक मजबूत उम्मीदवार बताता है कि एक छोटी उड़ान (small flight) या टेल लॉस तीन डुप्लिकेट ACK क्यों नहीं बना सकता है और ध्यान देता है कि कार्यान्वयन एक निश्चित पैकेट-काउंट सीमा और RTO पर निर्भरता को कम करने के लिए प्रेषण समय को SACK फीडबैक के साथ जोड़कर RACK-TLP का उपयोग कर सकते हैं।

स्पष्टीकरण वाले प्रश्न

• क्या अनुक्रम संख्याएं और लंबाई बाइट्स में व्यक्त की जाती हैं? पहले सापेक्ष पैकेट लेबल को बाइट श्रेणियों में बदलें। SYN और FIN भी अनुक्रम स्थान का उपभोग करते हैं, लेकिन इस समस्या में केवल एक स्थापित कनेक्शन पर डेटा शामिल है।
• क्या हैंडशेक के दौरान SACK पर सहमति हुई थी? इसके बिना, पुनर्प्राप्ति संचयी ACK और प्रेषक के चुने हुए एल्गोरिदम पर निर्भर करती है। इसके साथ, डुप्लिकेट ACK प्राप्त आउट-ऑफ़-ऑर्डर ब्लॉकों को ले जा सकते हैं।
• क्या फ़्लाइट इतनी बड़ी है कि तीन डुप्लिकेट ACK उत्पन्न कर सके? क्लासिक सिग्नल की आपूर्ति के लिए अंतराल (gap) के बाद कम से कम तीन नए सेगमेंट आने चाहिए। खोए हुए टेल सेगमेंट में आमतौर पर उन ACK को बनाने के लिए कोई बाद का डेटा नहीं होता है।
• क्या हम RFC 5681 या किसी एक ठोस कर्नेल की व्याख्या कर रहे हैं? क्लासिक सीमा व्युत्पत्ति (derivation) के लिए उपयोगी है। एक वास्तविक स्टैक एक कॉन्फ़िगर करने योग्य सीमा, SACK पुनर्प्राप्ति, RACK-TLP, या किसी अन्य एक्सटेंशन का उपयोग कर सकता है, इसलिए पैकेट-ट्रेस निष्कर्षों के लिए ऑपरेटिंग सिस्टम और संस्करण की आवश्यकता होती है।
• क्या लक्ष्य प्रोटोकॉल शुद्धता या प्रदर्शन निदान है? शुद्धता अंततः क्रमबद्ध वितरण की व्याख्या करती है। निदान के लिए RTT, RTO, संकुलन स्थिति, पुन: क्रमित करने, कैप्चर पॉइंट और NIC ऑफ़लोड व्यवहार की भी आवश्यकता होती है।

30-सेकंड का उत्तर ढांचा

“TCP अनुक्रम संख्याएं बाइट्स की गणना करती हैं, और संचयी ACK अगला अपेक्षित बाइट है। सेगमेंट A 1,000 से 1,999 तक को कवर करता है, इसलिए इसे प्राप्त करने पर ACK 2,000 उत्पन्न होता है। सेगमेंट B, जो 2,000 से 2,999 तक को कवर करता है, खो जाता है। अगले तीन सेगमेंट बफ़र किए जा सकते हैं, लेकिन अंतराल अभी भी 2,000 पर शुरू होता है, इसलिए प्रत्येक एक और ACK 2,000 उत्पन्न करता है। यदि SACK पर बातचीत हुई थी, तो वे ACK 3,000 से 5,999 तक के प्राप्त बाइट्स की भी रिपोर्ट करते हैं।

क्लासिक RFC 5681 पथ पर, तीसरा डुप्लिकेट ACK RTO की प्रतीक्षा किए बिना बाइट्स 2,000 से 2,999 के फ़ास्ट पुन: प्रेषण को ट्रिगर करता है। एक बार अंतराल भर जाने के बाद, संचयी ACK सीधे 6,000 तक आगे बढ़ता है। यदि फ़्लाइट बहुत छोटी है, टेल खो जाती है, या ACK फीडबैक रुक जाता है, तो प्रेषक को RTO की आवश्यकता हो सकती है। RTO को स्मूथ किए गए RTT और RTT भिन्नता से प्राप्त किया जाता है, फिर टाइमआउट के बाद अधिक संकुलन-विंडो कमी के साथ तेजी से (exponentially) वापस लाया जाता है। SACK कई अंतरालों के लिए पुनर्प्राप्ति सटीकता में सुधार करता है। आधुनिक RACK-TLP टेल या पुन: प्रेषण हानि का जल्द पता लगाने के लिए प्रेषण समय, SACK फीडबैक और एक जांच (probe) का भी उपयोग कर सकता है। एक ट्रेस में, मैं पुन: क्रमित करने या विश्लेषक लेबल को हानि के प्रमाण के रूप में मानने के बजाय संचयी ACK, SACK ब्लॉक, पुन: प्रेषण समय और वास्तविक TCP स्टैक को सहसंबंधित करूंगा।”

चरण-दर-चरण गहन विश्लेषण

चरण 1: बाइट श्रेणियों और संचयी ACK को तय करें

पांच तार्किक बाइट श्रेणियां हैं:

A: SEQ=1000, LEN=1000 -> [1000, 2000)  delivered
B: SEQ=2000, LEN=1000 -> [2000, 3000)  lost
C: SEQ=3000, LEN=1000 -> [3000, 4000)  delivered
D: SEQ=4000, LEN=1000 -> [4000, 5000)  delivered
E: SEQ=5000, LEN=1000 -> [5000, 6000)  delivered

A के आने के बाद, प्राप्तकर्ता 1,000 से 1,999 तक के बाइट्स को लगातार रखता है, इसलिए यह ACK=2000 भेजता है। यह ACK पहली बार पावती सीमा (acknowledgment boundary) को आगे बढ़ाता है। यह एक नया ACK है, डुप्लिकेट नहीं।

B के खो जाने के बाद, C प्राप्ति विंडो के भीतर स्वीकार्य है लेकिन 2,000 से शुरू होने वाले अंतराल को नहीं भर सकता है। प्राप्तकर्ता C को बफ़र कर सकता है, जबकि इसकी संचयी पावती ACK=2000 बनी रहती है। यही बात D और E पर भी लागू होती है। RFC 9293 ACK फ़ील्ड को प्राप्त करने वाले पीयर द्वारा अपेक्षित अगली अनुक्रम संख्या के रूप में परिभाषित करता है, यही कारण है कि यह प्रत्येक आउट-ऑफ़-ऑर्डर सेगमेंट के अंत तक नहीं कूदता है।

चरण 2: तीन डुप्लिकेट ACK और फ़ास्ट पुन: प्रेषण प्राप्त करें

क्लासिक RFC 5681 पथ पर, C, D और E का प्रत्येक आगमन तत्काल डुप्लिकेट ACK=2000 का कारण बनता है:

Receive A             -> ACK 2000                     new ACK
Receive C; B is absent -> ACK 2000 + SACK [3000,4000) duplicate ACK 1
Receive D; B is absent -> ACK 2000 + SACK [3000,5000) duplicate ACK 2
Receive E; B is absent -> ACK 2000 + SACK [3000,6000) duplicate ACK 3
Sender retransmits B   -> SEQ 2000, LEN 1000
Receiver gets B        -> ACK 6000                     gap closes

जब तीसरा डुप्लिकेट ACK प्रेषक तक पहुंचता है, तो यह अनुमान लगाता है कि B शायद खो गया था और पुन: प्रेषण टाइमर की प्रतीक्षा करने के बजाय [2000,3000) का फ़ास्ट पुन: प्रेषण करता है। C, D और E पहले से ही बफ़र हैं। जब B आता है, तो सन्निहित सीमा तुरंत बाइट 5,999 तक बढ़ जाती है, इसलिए संचयी ACK सीधे 2,000 से 6,000 तक जा सकता है।

तीन डुप्लिकेट ACK एक हानि अनुमान (loss heuristic) हैं, गणितीय प्रमाण नहीं। नेटवर्क पुन: क्रमित करना पहले उच्च-अनुक्रम डेटा वितरित कर सकता है और समान ACK पैटर्न उत्पन्न कर सकता है। प्रतिकृति डेटा सेगमेंट या ACK भी इसे बना सकते हैं। सीमा गलत वर्गीकरण के खिलाफ तेजी से मरम्मत का व्यापार करती है, और वास्तविक स्टैक अन्य एल्गोरिदम जोड़ सकते हैं।

चरण 3: बताएं कि SACK क्या जोड़ता है और क्या नहीं

एक संचयी ACK केवल यह कहता है कि 2,000 से नीचे सब कुछ लगातार आ गया। एक SACK विकल्प अतिरिक्त रूप से प्राप्ति बफ़र में रखे गैर-सन्निहित ब्लॉकों की रिपोर्ट कर सकता है, जैसे कि [3000,6000)। यह एक सूचना अंतराल को बंद करता है: प्रेषक जानता है कि उच्च-अनुक्रम डेटा आ गया है और कई छेदों की मरम्मत करते समय उन ब्लॉकों को छोड़ सकता है।

SACK की तीन महत्वपूर्ण सीमाएं हैं:

1. प्राप्तकर्ता द्वारा बाद के ACKs में SACK ब्लॉक ले जाने से पहले SYN एक्सचेंज में SACK-Permitted पर सहमति होनी चाहिए।
2. एक SACK ब्लॉक संचयी ACK को 2,000 से 6,000 तक आगे नहीं बढ़ाता है। केवल [2000,3000) को भरने से सन्निहित सीमा आगे बढ़ती है।
3. SACK सलाहकार प्राप्तकर्ता जानकारी है। यह प्रेषक को एक पुनर्प्राप्ति स्कोरबोर्ड बनाए रखने में मदद करता है; प्रेषक का एल्गोरिदम अभी भी पुन: प्रेषण क्रम और संकुलन प्रतिक्रिया चुनता है।

यदि B और D दोनों खो जाते हैं, तो एक फ़ास्ट पुन: प्रेषण शुरू में केवल B की मरम्मत करता है। SACK के बिना क्लासिक पुनर्प्राप्ति के पास इस बारे में कम जानकारी होती है कि क्या D आया है। SACK अलग-अलग C और E ब्लॉकों की रिपोर्ट कर सकता है, जिससे प्रेषक दोनों अंतरालों को अधिक सटीक रूप से पहचान सकता है और बफ़र किए गए C और E को फिर से भेजने से बच सकता है।

चरण 4: समझाएं कि RTO क्यों आवश्यक बना हुआ है

फ़ास्ट पुन: प्रेषण ACK फीडबैक पर निर्भर करता है। यदि प्रेषक केवल A और B प्रसारित करता है और टेल सेगमेंट B खो देता है, तो डुप्लिकेट ACK बनाने के लिए कोई C, D, या E नहीं आता है। यदि रिवर्स ACK पथ भी विफल हो जाता है, तो प्रेषक इसी तरह तीन डुप्लिकेट एकत्र नहीं कर सकता है। पुन: प्रेषण टाइमर अंतिम सुरक्षा जाल है।

RFC 6298 स्मूथ किए गए राउंड-ट्रिप समय SRTT, राउंड-ट्रिप भिन्नता RTTVAR, और क्लॉक ग्रैन्युलैरिटी G को बनाए रखता है:

For the first RTT sample R:
SRTT   = R
RTTVAR = R / 2
RTO    = SRTT + max(G, 4 * RTTVAR)

For a later sample R':
RTTVAR = (1 - 1/4) * RTTVAR + 1/4 * abs(SRTT - R')
SRTT   = (1 - 1/8) * SRTT   + 1/8 * R'
RTO    = SRTT + max(G, 4 * RTTVAR)

उदाहरण के लिए, R=120 ms के पहले नमूने और 240 ms से अधिक नहीं G के साथ, SRTT=120 ms, RTTVAR=60 ms, और कच्चा सूत्र 360 ms देता है। RFC 6298 एक सेकंड से नीचे के RTO को एक सेकंड तक पूर्णांक (round up) करने की सिफारिश करता है, और RTT नमूना मौजूद होने से पहले प्रारंभिक एक-सेकंड के RTO की सिफारिश करता है। वास्तविक कर्नेल नए एल्गोरिदम और कार्यान्वयन विवरणों का उपयोग कर सकते हैं, इसलिए एक अंतराल जो बिल्कुल एक सेकंड नहीं है, वह अपने आप में टाइमआउट पुनर्प्राप्ति को गलत साबित नहीं करता है।

जब टाइमर समाप्त हो जाता है, तो प्रेषक सबसे पुराने अस्वीकृत डेटा को फिर से प्रसारित करता है और टाइमर को पुनरारंभ करने से पहले RTO को दोगुना कर देता है। तेजी से पीछे हटना (exponential backoff) लगातार संकुलित या टूटे हुए पथ में बार-बार डेटा डालने से बचाता है। पुन: प्रेषित सेगमेंट से सीधे RTT को मापने से अस्पष्टता पैदा होती है: क्या ACK ने मूल या पुन: प्रेषण को कवर किया था? उस अस्पष्टता को हल करने वाले टाइमस्टैम्प के बिना, Karn का एल्गोरिदम उस नमूने को RTT अपडेट से बाहर कर देता है।

चरण 5: संकुलन प्रतिक्रिया से विश्वसनीयता पुनर्प्राप्ति को अलग करें

पुन: प्रेषण उत्तर देता है "हम लापता बाइट्स को कैसे बदलते हैं?" संकुलन नियंत्रण उत्तर देता है "बाद में कितना डेटा इन-फ़्लाइट रह सकता है?" एक हानि संकेत दोनों को प्रभावित करता है, लेकिन दोनों कार्य अलग-अलग हैं।

क्लासिक RFC 5681 RTO को मजबूत संकेत मानता है। धीमे प्रारंभ (slow start) को फिर से शुरू करने से पहले ssthresh max(FlightSize/2, 2*SMSS) से अधिक नहीं है, और cwnd अधिकतम एक पूर्ण आकार के सेगमेंट तक गिर जाता है। तीन डुप्लिकेट ACK दिखाते हैं कि बाद के सेगमेंट अभी भी आ रहे हैं और ACK क्लॉक जीवित है, इसलिए प्रेषक उसी RTO रीसेट को लागू किए बिना विंडो को कम करते हुए, फ़ास्ट पुन: प्रेषण और फ़ास्ट पुनर्प्राप्ति में प्रवेश करता है।

फ्लो नियंत्रण (flow control) एक और अलग सीमा है। प्राप्तकर्ता द्वारा विज्ञापित rwnd प्राप्ति-बफ़र क्षमता की सुरक्षा करता है, जबकि प्रेषक का cwnd नेटवर्क की सुरक्षा करता है। दोनों वास्तविक भेजने को बाधित करते हैं। SACK प्राप्ति स्थिति का वर्णन करता है; यह न तो rwnd और न ही cwnd को बढ़ाता है।

चरण 6: आधुनिक RACK-TLP सीमा जोड़ें

एक निश्चित तीन-डुप्लिकेट-ACK नियम छोटी उड़ानों, टेल लॉस, खोए हुए पुन: प्रेषण और पर्याप्त पुन: क्रमित करने के लिए खराब प्रदर्शन करता है। RFC 8985 पारंपरिक डुप्लिकेट-ACK गणना के विकल्प के रूप में RACK-TLP की सिफारिश करता है। RACK यह अनुमान लगाने के लिए कि क्या पहले का प्रेषण खो गया है, प्रत्येक सेगमेंट के नवीनतम प्रेषण समय, RTT और SACK फीडबैक को जोड़ता है। TLP तब एक जांच (probe) भेजता है जब टेल के पास ACK फीडबैक विरल होता है, RTO से पहले ACK क्लॉक को पुनर्स्थापित करने का प्रयास करता है।

साक्षात्कार के उत्तर में पहले क्लासिक तंत्र को प्राप्त करना चाहिए और फिर कार्यान्वयन सीमा को बताना चाहिए। एक वास्तविक ट्रेस तीन से कम डुप्लिकेट ACK या एक टेल जांच के साथ पुनर्प्राप्ति दिखा सकता है। स्टैक के एल्गोरिदम और संस्करण की जाँच करें। यह कहना कि प्रत्येक कार्यान्वयन "सटीक रूप से तीन डुप्लिकेट की प्रतीक्षा करता है या हमेशा RTO की प्रतीक्षा करता है" शिक्षण मॉडल को पूर्ण वर्तमान व्यवहार समझने की गलती करता है।

चरण 7: पुन: प्रेषण गणना से नहीं, पैकेट साक्ष्य से सत्यापित करें

एक ऐसी समयरेखा बनाएं जिसे अवलोकनों के बीच सुसंगत किया जा सके:

1. एक दृष्टिकोण पर भरोसा करने के बजाय मूल सेगमेंट कहां गायब होता है, इसका पता लगाने के लिए प्रेषक और प्राप्तकर्ता पर कैप्चर करें।
2. यह साबित करने के लिए कि एक बाइट अंतराल मौजूद है, SEQ, LEN, संचयी ACK, और SACK ब्लॉकों को संरेखित करें।
3. पिछले नए ACK के बाद ही डुप्लिकेट की गणना करें; बेसलाइन ACK को स्वयं न गिनें।
4. तीसरे डुप्लिकेट ACK या अपेक्षित RTO के साथ पुन: प्रेषण समय की तुलना करें, फिर संकुलन स्थिति, RTT और स्टैक के पुनर्प्राप्ति एल्गोरिदम की जांच करें।
5. एक Wireshark लेबल से मूल कारण तय करने के बजाय इंटरफ़ेस हानि, पुन: क्रमित करने और कतार संकेतों के साथ एप्लिकेशन विलंब को सहसंबंधित करें।

Wireshark के tcp.analysis.fast_retransmission, tcp.analysis.retransmission, और tcp.analysis.duplicate_ack मान उपलब्ध कैप्चर से विश्लेषक के निष्कर्ष हैं, TCP हेडर में ले जाए जाने वाले फ़्लैग नहीं हैं। TSO और GRO होस्ट-कैप्चर सेगमेंट सीमाओं को वायर पर मौजूद पैकेटों से भिन्न भी बना सकते हैं। महत्वपूर्ण निष्कर्षों के लिए दोनों एंडपॉइंट के अनुक्रम स्थानों और समय के साथ क्रॉस-जांच की आवश्यकता होती है।

उच्च गुणवत्ता वाला नमूना उत्तर

“मैं इसे बाइट अनुक्रम स्थान में प्राप्त करूंगा। A का SEQ=1000 और लंबाई 1,000 है, इसलिए A प्राप्त करने के बाद प्राप्तकर्ता अगले बाइट 2,000 की अपेक्षा करता है और एक नया ACK 2,000 भेजता है। B बाइट्स 2,000 से 2,999 को कवर करता है और खो जाता है। C, D, और E बाइट्स 3,000 से 5,999 को कवर करते हैं और पहुंचते हैं, लेकिन कोई भी 2,000 पर अंतराल को नहीं भरता है। इसलिए संचयी ACK 2,000 पर रहता है। प्रत्येक आउट-ऑफ़-ऑर्डर सेगमेंट एक डुप्लिकेट ACK उत्पन्न करता है। यदि SACK पर बातचीत हुई थी, तो प्राप्तकर्ता उत्तरोत्तर यह भी रिपोर्ट करता है कि बाइट्स 3,000 से 5,999 बफ़र किए गए हैं।

क्लासिक RFC 5681 व्यवहार के तहत, C, D, और E 2,000 के लिए तीन डुप्लिकेट ACK उत्पन्न करते हैं। तीसरा प्रेषक को RTO की प्रतीक्षा किए बिना B को फ़ास्ट-पुन: प्रेषित करने का कारण बनता है। जब B आता है, तो प्राप्ति बफ़र सन्निहित हो जाता है और संचयी ACK सीधे 6,000 पर चला जाता है। सामान्य ऑफ-बाय-वन त्रुटि A के बाद पहले ACK 2,000 को डुप्लिकेट के रूप में गिनना है; यह नया ACK है जो सीमा को आगे बढ़ाता है।

यदि हानि टेल पर है या फ़्लाइट बहुत छोटी है, तो बाद के तीन सेगमेंट मौजूद नहीं होते हैं, इसलिए RTO अंतिम सुरक्षा जाल है। RTO का अनुमान स्मूथ किए गए RTT प्लस चार गुना RTT भिन्नता से लगाया जाता है, और RFC 6298 टाइमआउट के बाद तेजी से बैकऑफ़ लागू करता है। RTO आमतौर पर फ़ास्ट रिकवरी की तुलना में अधिक संकुलन-विंडो कमी का कारण बनता है क्योंकि ACK क्लॉक रुक गई हो सकती है। SACK प्रेषक को बताता है कि कौन से गैर-सन्निहित उच्च बाइट्स पहुंचे हैं, जो विशेष रूप से कई अंतरालों के लिए उपयोगी है। यह अपने आप में संचयी ACK को आगे नहीं बढ़ाता है और यह कोई संकुलन-नियंत्रण एल्गोरिदम नहीं है।

वास्तविक स्टैक प्रेषण समय और SACK फीडबैक से हानि का अनुमान लगाने और टेल लॉस की जांच करने के लिए RACK-TLP का भी उपयोग कर सकते हैं। तीन डुप्लिकेट ACK आवश्यक क्लासिक व्युत्पत्ति हैं, हर ट्रेस में एकमात्र संभावित ट्रिगर नहीं। निदान में, मैं दोनों एंडपॉइंट पर अनुक्रम संख्याओं, लंबाई, संचयी ACK, SACK ब्लॉक और पुन: प्रेषण समय को संरेखित करूंगा, स्टैक और ऑफ़लोड सेटिंग्स की जांच करूंगा, और फिर वास्तविक हानि को पुन: क्रमित करने, ACK-पथ हानि, या विश्लेषक अनुमान से अलग करूंगा।”

सामान्य गलतियाँ

• ACK को पैकेट संख्या मानना → TCP सन्निहित बाइट स्थान को स्वीकार करता है → SEQ + LEN के साथ अगले अपेक्षित बाइट को प्राप्त करें।
• A के बाद ACK 2,000 को डुप्लिकेट 1 के रूप में गिनना → यह पहली बार संचयी सीमा को आगे बढ़ाता है → समान संख्या वाले बाद के ACK की गणना शुरू करें जो इसे आगे नहीं बढ़ाते हैं।
• यह दावा करना कि C ACK 4,000 उत्पन्न करता है → B पर बाइट अंतराल बना रहता है → संचयी ACK को 2,000 पर रखें और SACK के साथ C की रिपोर्ट करें।
• यह दावा करना कि SACK संचयी ACK को प्रतिस्थापित करता है → TCP अभी भी एक सन्निहित सीमा को संचयी रूप से आगे बढ़ाता है → SACK को अतिरिक्त गैर-सन्निहित-ब्लॉक जानकारी के रूप में मानें।
• यह दावा करना कि तीन डुप्लिकेट हानि साबित करते हैं → पुन: क्रमित करना और प्रतिकृति समान संकेत बना सकते हैं → इसे क्लासिक हानि अनुमान कहें और समयरेखा को सत्यापित करें।
• यह दावा करना कि प्रत्येक हानि का फ़ास्ट पुन: प्रेषण हो जाता है → टेल लॉस या छोटी उड़ान पर्याप्त डुप्लिकेट ACK नहीं बना सकती है → RTO को बनाए रखें और RACK-TLP के सुधार की व्याख्या करें।
• पुन: प्रेषण और संकुलन नियंत्रण को संयोजित करना → डेटा की मरम्मत करना और भेजने की दर को सीमित करना विभिन्न समस्याओं को हल करता है → पुनर्प्राप्ति कार्रवाई, cwnd, और rwnd को अलग से बताएं।
• एक Wireshark लेबल को ऑन-वायर प्रोटोकॉल बिट मानना → लेबल का अनुमान कैप्चर संदर्भ से लगाया जाता है और यह ऑफ़लोड द्वारा विकृत हो सकता है → दोनों एंडपॉइंट के अनुक्रम स्थानों और समय की क्रॉस-जांच करें।

अनुवर्ती प्रश्न

अनुवर्ती 1: यदि केवल दो सेगमेंट भेजे जाते हैं और दूसरा खो जाता है, तो क्या फ़ास्ट पुन: प्रेषण होता है?

क्लासिक पथ पर नहीं। कोई उच्च-अनुक्रम डेटा प्राप्तकर्ता तक नहीं पहुंचता है, इसलिए यह तीन डुप्लिकेट ACK उत्पन्न नहीं कर सकता है। प्रेषक आमतौर पर RTO की प्रतीक्षा करता है। एक RACK-TLP स्टैक फीडबैक प्राप्त करने के लिए एक टेल-लॉस जांच भेज सकता है, लेकिन यदि जांच विफल हो जाती है तो RTO अभी भी फ़ॉलबैक प्रदान करता है।

अनुवर्ती 2: क्या होगा यदि C केवल पुन: क्रमित किया गया है और B अपने मूल प्रेषण पर बाद में आता है?

C प्राप्त करने से डुप्लिकेट ACK 2,000 और एक संबंधित SACK ब्लॉक उत्पन्न होता है। यदि B हानि सीमा तक पहुंचने से पहले आता है, तो संचयी ACK आगे बढ़ता है और पुन: प्रेषण से बचा जाता है। यदि पुन: क्रमित करना पहले तीन डुप्लिकेट को ट्रिगर करने के लिए पर्याप्त गहरा है, तो क्लासिक फ़ास्ट पुन: प्रेषण नकली (spurious) हो सकता है। RACK इस निश्चित पैकेट-सीमा विफलता मोड को कम करने के लिए समय-आधारित पुन: क्रमित करने वाली विंडो का उपयोग करता है।

अनुवर्ती 3: जब B और D दोनों खो जाते हैं तो SACK अधिक मूल्यवान क्यों होता है?

प्राप्तकर्ता डिलीवर किए गए C और E ब्लॉकों की रिपोर्ट कर सकता है। प्रेषक उस जानकारी का उपयोग अंतराल स्कोरबोर्ड में करता है, SACK किए गए रेंजों को छोड़ देता है, और B और D की मरम्मत करता है। SACK के बिना, संचयी ACK केवल सबसे बाएं अंतराल को उजागर करता है। क्लासिक Reno के पास एक विंडो में कई हानियों के बारे में कम जानकारी होती है और उसे आंशिक ACK या अंततः RTO की आवश्यकता हो सकती है।

अनुवर्ती 4: यदि पहला RTT नमूना 120 ms है, तो RTO को 120 ms पर क्यों सेट न करें?

कतारों और पथ परिवर्तनों के साथ RTT भिन्न होता है। RFC 6298 RTTVAR को R/2 पर आरंभ करता है; जब G 4 × RTTVAR से अधिक नहीं होता है, तो कच्चा RTO R + 4 × R/2 = 3R होता है। यह यहाँ 360 ms है, और RFC इसे कम से कम एक सेकंड तक पूर्णांक करने की सिफारिश करता है। सीधे एक RTT का उपयोग करने से छोटे बदलाव नकली टाइमआउट और अनावश्यक पुन: प्रेषण का कारण बनेंगे।

अनुवर्ती 5: एक कैप्चर पुन: प्रेषण दिखाता है लेकिन तीन डुप्लिकेट ACK नहीं दिखाता है। क्या यह RTO को साबित करता है?

नहीं। कैप्चर रिवर्स-पाथ ACK को मिस कर सकता है, दृष्टिकोण ऑफ़लोड से पहले या बाद में हो सकता है, और स्टैक RACK-TLP या किसी अन्य पुनर्प्राप्ति एल्गोरिदम का उपयोग कर सकता है। पिछले ACK समय के साथ पुन: प्रेषण की तुलना करें, SACK और टेल जांच का निरीक्षण करें, प्रेषक-पक्ष कर्नेल स्थिति की जांच करें, और प्राप्तकर्ता-पक्ष कैप्चर के साथ साक्ष्य को पूरा करें।

अनुवर्ती 6: टाइमआउट के बाद संकुलन प्रतिक्रिया सामान्य रूप से फ़ास्ट रिकवरी के बाद की तुलना में अधिक मजबूत क्यों होती है?

तीन डुप्लिकेट ACK दिखाते हैं कि बाद के सेगमेंट नेटवर्क छोड़ रहे हैं और प्राप्तकर्ता तक पहुंच रहे हैं, इसलिए ACK क्लॉक अभी भी चल रही है। RTO का मतलब यह हो सकता है कि पूरी उड़ान या फीडबैक पथ ने कोई प्रगति नहीं की। क्लासिक RFC 5681 इसलिए cwnd को अधिकतम एक पूर्ण आकार के सेगमेंट तक घटा देता है और टाइमआउट के बाद धीमी शुरुआत को पुनरारंभ करता है, जबकि फ़ास्ट रिकवरी एक कम भेजने वाली विंडो को बनाए रखती है।