टीसीपी संकुलन नियंत्रण: Difference between revisions

From Vigyanwiki
No edit summary
No edit summary
Line 2: Line 2:




[[ प्रसारण नियंत्रण प्रोटोकॉल ]] (टीसीपी)  [[ भीड़ नियंत्रण ]] एल्गोरिदम का उपयोग करता है जिसमें #धीमी शुरुआत सहित अन्य योजनाओं के साथ-साथ एडिटिव वृद्धि/गुणक कमी (एआईएमडी) योजना के विभिन्न पहलू शामिल हैं।{{sfn|Jacobson|Karels|1988}} और #कंजेशन विंडो (सीडब्ल्यूएनडी), भीड़भाड़ से बचने के लिए। टीसीपी कंजेशन-अवॉइडेंस एल्गोरिदम इंटरनेट में कंजेशन नियंत्रण का प्राथमिक आधार है।<ref name="RFC 2001"/><ref name="RFC 3390">{{cite IETF|title=टीसीपी की आरंभिक विंडो बढ़ाना|rfc=3390|author=M. Allman|author2=S. Floyd|author3=C. Partridge|date=October 2002}}</ref><ref>{{cite web|url=http://www.eventhelix.com/RealtimeMantra/Networking/TCP_Congestion_Avoidance.pdf|title=टीसीपी कंजेशन से बचाव को एक अनुक्रम आरेख के माध्यम से समझाया गया|website=eventhelix.com}}</ref> एंड-टू-एंड सिद्धांत के अनुसार, भीड़भाड़ नियंत्रण काफी हद तक [[[[इंटरनेट]] होस्ट]] का कार्य है, न कि नेटवर्क का। इंटरनेट से कनेक्ट होने वाले कंप्यूटरों के [[ऑपरेटिंग सिस्टम]] के [[प्रोटोकॉल स्टैक]] में लागू एल्गोरिदम के कई रूप और संस्करण हैं।
 
[[ प्रसारण नियंत्रण प्रोटोकॉल |प्रसारण नियंत्रण प्रोटोकॉल]] (टीसीपी)  [[ भीड़ नियंत्रण ]] एल्गोरिदम का उपयोग करता है जिसमें #धीमी शुरुआत सहित अन्य योजनाओं के साथ-साथ एडिटिव वृद्धि/गुणक कमी (एआईएमडी) योजना के विभिन्न पहलू शामिल हैं।{{sfn|Jacobson|Karels|1988}} और #कंजेशन विंडो (सीडब्ल्यूएनडी), भीड़भाड़ से बचने के लिए। टीसीपी कंजेशन-अवॉइडेंस एल्गोरिदम इंटरनेट में कंजेशन नियंत्रण का प्राथमिक आधार है।<ref name="RFC 2001"/><ref name="RFC 3390">{{cite IETF|title=टीसीपी की आरंभिक विंडो बढ़ाना|rfc=3390|author=M. Allman|author2=S. Floyd|author3=C. Partridge|date=October 2002}}</ref><ref>{{cite web|url=http://www.eventhelix.com/RealtimeMantra/Networking/TCP_Congestion_Avoidance.pdf|title=टीसीपी कंजेशन से बचाव को एक अनुक्रम आरेख के माध्यम से समझाया गया|website=eventhelix.com}}</ref> एंड-टू-एंड सिद्धांत के अनुसार, भीड़भाड़ नियंत्रण काफी हद तक [[[[इंटरनेट]] होस्ट]] का कार्य है, न कि नेटवर्क का। इंटरनेट से कनेक्ट होने वाले कंप्यूटरों के [[ऑपरेटिंग सिस्टम]] के [[प्रोटोकॉल स्टैक]] में लागू एल्गोरिदम के कई रूप और संस्करण हैं।


कंजेस्टिव पतन से बचने के लिए, टीसीपी बहुआयामी कंजेशन-नियंत्रण रणनीति का उपयोग करता है। प्रत्येक कनेक्शन के लिए, टीसीपी  सीडब्ल्यूएनडी बनाए रखता है, जो पारगमन में एंड-टू-एंड हो सकने वाले अस्वीकृत पैकेटों की कुल संख्या को सीमित करता है। यह कुछ हद तक ट्रांसमिशन कंट्रोल प्रोटोकॉल#फ्लो नियंत्रण के लिए उपयोग की जाने वाली टीसीपी की [[ स्लाइडिंग खिड़की ]] के समान है।
कंजेस्टिव पतन से बचने के लिए, टीसीपी बहुआयामी कंजेशन-नियंत्रण रणनीति का उपयोग करता है। प्रत्येक कनेक्शन के लिए, टीसीपी  सीडब्ल्यूएनडी बनाए रखता है, जो पारगमन में एंड-टू-एंड हो सकने वाले अस्वीकृत पैकेटों की कुल संख्या को सीमित करता है। यह कुछ हद तक ट्रांसमिशन कंट्रोल प्रोटोकॉल#फ्लो नियंत्रण के लिए उपयोग की जाने वाली टीसीपी की [[ स्लाइडिंग खिड़की ]] के समान है।
Line 10: Line 11:


यह वह एल्गोरिदम है जिसका वर्णन किया गया है {{IETF RFC|5681}} भीड़भाड़ से बचाव की स्थिति के लिए।<ref>{{cite IETF|title=टीसीपी कंजेशन नियंत्रण|rfc=5681|section=3.1|last1=Allman|first1=M.|last2=Paxson|first2=V.|date=September 2009|publisher=[[Internet Engineering Task Force|IETF]]|access-date=March 4, 2021|doi=10.17487/RFC5681}}</ref>
यह वह एल्गोरिदम है जिसका वर्णन किया गया है {{IETF RFC|5681}} भीड़भाड़ से बचाव की स्थिति के लिए।<ref>{{cite IETF|title=टीसीपी कंजेशन नियंत्रण|rfc=5681|section=3.1|last1=Allman|first1=M.|last2=Paxson|first2=V.|date=September 2009|publisher=[[Internet Engineering Task Force|IETF]]|access-date=March 4, 2021|doi=10.17487/RFC5681}}</ref>


== कंजेशन विंडो ==
== कंजेशन विंडो ==
Line 40: Line 40:
: जब कोई हानि होती है, तो पुनः ट्रांसमिट भेजा जाता है, वर्तमान CWND का आधा हिस्सा ssthresh के रूप में सहेजा जाता है और इसके प्रारंभिक CWND से धीमी शुरुआत फिर से शुरू होती है।
: जब कोई हानि होती है, तो पुनः ट्रांसमिट भेजा जाता है, वर्तमान CWND का आधा हिस्सा ssthresh के रूप में सहेजा जाता है और इसके प्रारंभिक CWND से धीमी शुरुआत फिर से शुरू होती है।
; टीसीपी रेनो
; टीसीपी रेनो
: #फास्ट रिट्रांसमिट भेजा जाता है, वर्तमान सीडब्ल्यूएनडी का आधा हिस्सा एसएसथ्रेश और नए सीडब्ल्यूएनडी के रूप में सहेजा जाता है, इस प्रकार धीमी शुरुआत को छोड़ दिया जाता है और सीधे कंजेशन अवॉइडेंस एल्गोरिदम पर चला जाता है। यहां समग्र एल्गोरिदम को 'कहा जाता है{{vanchor|fast recovery}}.
: फास्ट रिट्रांसमिट भेजा जाता है, वर्तमान सीडब्ल्यूएनडी का आधा हिस्सा एसएसथ्रेश और नए सीडब्ल्यूएनडी के रूप में सहेजा जाता है, इस प्रकार धीमी शुरुआत को छोड़ दिया जाता है और सीधे कंजेशन अवॉइडेंस एल्गोरिदम पर चला जाता है। यहां समग्र एल्गोरिदम को 'कहा जाता है{{vanchor|fast recovery}}.


धीमी शुरुआत यह मानती है कि अस्वीकृत खंड नेटवर्क संकुलन के कारण हैं। हालांकि यह कई नेटवर्कों के लिए  स्वीकार्य धारणा है, अन्य कारणों से खंड खो सकते हैं, जैसे खराब [[सूचना श्रंखला तल]] ट्रांसमिशन गुणवत्ता। इस प्रकार, [[वायरलेस लेन]] जैसी खराब रिसेप्शन वाली स्थितियों में धीमी शुरुआत खराब प्रदर्शन कर सकती है।
धीमी शुरुआत यह मानती है कि अस्वीकृत खंड नेटवर्क संकुलन के कारण हैं। हालांकि यह कई नेटवर्कों के लिए  स्वीकार्य धारणा है, अन्य कारणों से खंड खो सकते हैं, जैसे खराब [[सूचना श्रंखला तल]] ट्रांसमिशन गुणवत्ता। इस प्रकार, [[वायरलेस लेन]] जैसी खराब रिसेप्शन वाली स्थितियों में धीमी शुरुआत खराब प्रदर्शन कर सकती है।


धीमी शुरुआत प्रोटोकॉल अल्पकालिक कनेक्शन के लिए भी खराब प्रदर्शन करता है। पुराने [[वेब ब्राउज़र्स]] वेब सर्वर के लिए लगातार कई अल्पकालिक कनेक्शन बनाएंगे, और अनुरोधित प्रत्येक फ़ाइल के लिए कनेक्शन खोलेंगे और बंद करेंगे। इसने अधिकांश कनेक्शनों को धीमी शुरुआत मोड में रखा, जिसके परिणामस्वरूप प्रतिक्रिया समय खराब हो गया। इस समस्या से बचने के लिए, आधुनिक ब्राउज़र या तो  साथ कई कनेक्शन खोलते हैं या किसी विशेष वेब सर्वर से अनुरोधित सभी फ़ाइलों के लिए [[HTTP लगातार कनेक्शन]] खोलते हैं। हालाँकि, [[विज्ञापन नेटवर्क]], [[सामाजिक नेटवर्किंग सेवा]] के [[ बटन की तरह ]] को लागू करने के लिए वेब साइटों द्वारा उपयोग किए जाने वाले कई तृतीय-पक्ष सर्वरों के लिए कनेक्शन का पुन: उपयोग नहीं किया जा सकता है।<ref>Nick O'Neill. "[http://allfacebook.com/whats-making-your-site-go-slow-could-be-the-like-button_b24121 What's Making Your Site Go Slow? Could Be The Like Button]". ''AllFacebook'', 10 November 2010. Retrieved on 12 September 2012.</ref> और वेब एनालिटिक्स#पेज टैगिंग।
धीमी शुरुआत प्रोटोकॉल अल्पकालिक कनेक्शन के लिए भी खराब प्रदर्शन करता है। पुराने [[वेब ब्राउज़र्स]] वेब सर्वर के लिए लगातार कई अल्पकालिक कनेक्शन बनाएंगे, और अनुरोधित प्रत्येक फ़ाइल के लिए कनेक्शन खोलेंगे और बंद करेंगे। इसने अधिकांश कनेक्शनों को धीमी शुरुआत मोड में रखा, जिसके परिणामस्वरूप प्रतिक्रिया समय खराब हो गया। इस समस्या से बचने के लिए, आधुनिक ब्राउज़र या तो  साथ कई कनेक्शन खोलते हैं या किसी विशेष वेब सर्वर से अनुरोधित सभी फ़ाइलों के लिए [[HTTP लगातार कनेक्शन]] खोलते हैं। हालाँकि, [[विज्ञापन नेटवर्क]], [[सामाजिक नेटवर्किंग सेवा]] के [[ बटन की तरह ]] को लागू करने के लिए वेब साइटों द्वारा उपयोग किए जाने वाले कई तृतीय-पक्ष सर्वरों के लिए कनेक्शन का पुन: उपयोग नहीं किया जा सकता है।<ref>Nick O'Neill. "[http://allfacebook.com/whats-making-your-site-go-slow-could-be-the-like-button_b24121 What's Making Your Site Go Slow? Could Be The Like Button]". ''AllFacebook'', 10 November 2010. Retrieved on 12 September 2012.</ref> और वेब एनालिटिक्स पेज टैगिंग।


== तेजी से पुनः प्रेषण ==
== तेजी से पुनः प्रेषण ==
Line 160: Line 160:
|Delay
|Delay
|Sender
|Sender
|BLVC, [[Bufferbloat]]<!-- Not adding F until they publish the fairness comparison. -->
|BLVC, [[Bufferbloat]]
|
|
|-
|-
Line 212: Line 212:
|}
|}


'''टीसीपी ताहो और रेनो'''


=== टीसीपी ताहो और रेनो ===
टीसीपी ताहो और रेनो एल्गोरिदम को पूर्वव्यापी रूप से 4.3बीएसडी ऑपरेटिंग सिस्टम के संस्करणों या स्वादों के नाम पर रखा गया था, जिनमें से प्रत्येक पहली बार दिखाई दिया था (जो स्वयं [[ताहो झील]] और पास के शहर रेनो, नेवादा के नाम पर थे)। ताहो एल्गोरिथ्म पहली बार 4.3बीएसडी-ताहो में दिखाई दिया (जो कंप्यूटर कंसोल इंक. # पावर 5 और पावर 6 कंप्यूटर | सीसीआई पावर 6/32 ताहो मिनी कंप्यूटर का समर्थन करने के लिए बनाया गया था), और बाद में इसे गैर-एटी एंड टी लाइसेंसधारियों के लिए उपलब्ध कराया गया था। 4.3बीएसडी नेटवर्किंग रिलीज़ 1 का; इससे इसका व्यापक वितरण और कार्यान्वयन सुनिश्चित हुआ। 4.3BSD-रेनो में सुधार किए गए और बाद में इसे नेटवर्किंग रिलीज़ 2 और बाद में 4.4BSD-लाइट के रूप में जनता के लिए जारी किया गया।
टीसीपी ताहो और रेनो एल्गोरिदम को पूर्वव्यापी रूप से 4.3बीएसडी ऑपरेटिंग सिस्टम के संस्करणों या स्वादों के नाम पर रखा गया था, जिनमें से प्रत्येक पहली बार दिखाई दिया था (जो स्वयं [[ताहो झील]] और पास के शहर रेनो, नेवादा के नाम पर थे)। ताहो एल्गोरिथ्म पहली बार 4.3बीएसडी-ताहो में दिखाई दिया (जो कंप्यूटर कंसोल इंक. # पावर 5 और पावर 6 कंप्यूटर | सीसीआई पावर 6/32 ताहो मिनी कंप्यूटर का समर्थन करने के लिए बनाया गया था), और बाद में इसे गैर-एटी एंड टी लाइसेंसधारियों के लिए उपलब्ध कराया गया था। 4.3बीएसडी नेटवर्किंग रिलीज़ 1 का; इससे इसका व्यापक वितरण और कार्यान्वयन सुनिश्चित हुआ। 4.3BSD-रेनो में सुधार किए गए और बाद में इसे नेटवर्किंग रिलीज़ 2 और बाद में 4.4BSD-लाइट के रूप में जनता के लिए जारी किया गया।


Line 221: Line 221:
* रेनो: यदि तीन डुप्लिकेट ACK प्राप्त होते हैं, तो रेनो तेजी से पुन: ट्रांसमिट करेगा और कंजेशन विंडो को आधा करके (ताहो की तरह 1 MSS पर सेट करने के बजाय), ssthresh को नई कंजेशन विंडो के बराबर सेट करके धीमी शुरुआत चरण को छोड़ देगा। और तेज़ पुनर्प्राप्ति नामक चरण में प्रवेश करें।{{sfn|Kurose|Ross|2012|p=277}}
* रेनो: यदि तीन डुप्लिकेट ACK प्राप्त होते हैं, तो रेनो तेजी से पुन: ट्रांसमिट करेगा और कंजेशन विंडो को आधा करके (ताहो की तरह 1 MSS पर सेट करने के बजाय), ssthresh को नई कंजेशन विंडो के बराबर सेट करके धीमी शुरुआत चरण को छोड़ देगा। और तेज़ पुनर्प्राप्ति नामक चरण में प्रवेश करें।{{sfn|Kurose|Ross|2012|p=277}}


ताहो और रेनो दोनों में, यदि एसीके टाइम आउट (आरटीओ टाइमआउट) होता है, तो धीमी शुरुआत का उपयोग किया जाता है, और दोनों एल्गोरिदम कंजेशन विंडो को 1 एमएसएस तक कम कर देते हैं।{{Citation needed|date=October 2021}}
ताहो और रेनो दोनों में, यदि एसीके टाइम आउट (आरटीओ टाइमआउट) होता है, तो धीमी शुरुआत का उपयोग किया जाता है, और दोनों एल्गोरिदम कंजेशन विंडो को 1 एमएसएस तक कम कर देते हैं।


=== टीसीपी न्यू रेनो ===
=== टीसीपी न्यू रेनो ===
Line 241: Line 241:
नई रेनो कम पैकेट त्रुटि दर पर SACK के समान ही प्रदर्शन करती है और उच्च त्रुटि दर पर रेनो से काफी बेहतर प्रदर्शन करती है।<ref>{{cite journal|last1=VasanthiN.|first1=V.|last2=SinghM.|first2=Ajith|last3=Kumar|first3=Romen|last4=Hemalatha|first4=M.|date=2011|editor1-last=Das|editor1-first=Vinu V|editor2-last=Thankachan|editor2-first=Nessy|title=Evaluation of Protocols and Algorithms for Improving the Performance of TCP over Wireless/Wired Network|journal=International Conference on Computational Intelligence and Information Technology|series=Communications in Computer and Information Science|publisher=Springer|volume=250|pages=693–697|doi=10.1007/978-3-642-25734-6_120|isbn=978-3-642-25733-9}}</ref>
नई रेनो कम पैकेट त्रुटि दर पर SACK के समान ही प्रदर्शन करती है और उच्च त्रुटि दर पर रेनो से काफी बेहतर प्रदर्शन करती है।<ref>{{cite journal|last1=VasanthiN.|first1=V.|last2=SinghM.|first2=Ajith|last3=Kumar|first3=Romen|last4=Hemalatha|first4=M.|date=2011|editor1-last=Das|editor1-first=Vinu V|editor2-last=Thankachan|editor2-first=Nessy|title=Evaluation of Protocols and Algorithms for Improving the Performance of TCP over Wireless/Wired Network|journal=International Conference on Computational Intelligence and Information Technology|series=Communications in Computer and Information Science|publisher=Springer|volume=250|pages=693–697|doi=10.1007/978-3-642-25734-6_120|isbn=978-3-642-25733-9}}</ref>


 
'''टीसीपी वेगास'''
=== टीसीपी वेगास ===
{{main|TCP Vegas}}
{{main|TCP Vegas}}


Line 248: Line 247:
टीसीपी वेगास को पीटरसन की प्रयोगशाला के बाहर व्यापक रूप से तैनात नहीं किया गया था, लेकिन [[डीडी-WRT]] फर्मवेयर v24 SP2 के लिए डिफ़ॉल्ट भीड़ नियंत्रण विधि के रूप में चुना गया था।<ref>{{cite web|title=डीडी-डब्ल्यूआरटी चेंजलॉग|url=http://www.dd-wrt.com/wiki/index.php/Changelog|access-date=2 January 2012}}</ref>
टीसीपी वेगास को पीटरसन की प्रयोगशाला के बाहर व्यापक रूप से तैनात नहीं किया गया था, लेकिन [[डीडी-WRT]] फर्मवेयर v24 SP2 के लिए डिफ़ॉल्ट भीड़ नियंत्रण विधि के रूप में चुना गया था।<ref>{{cite web|title=डीडी-डब्ल्यूआरटी चेंजलॉग|url=http://www.dd-wrt.com/wiki/index.php/Changelog|access-date=2 January 2012}}</ref>


'''टीसीपी हाइब्ला'''


=== टीसीपी हाइब्ला ===
टीसीपी हाइब्ला<ref>{{cite web |url=http://hybla.deis.unibo.it/ |title=हाइब्ला होम पेज|access-date=2007-03-04 |archive-url=https://web.archive.org/web/20071011095352/http://hybla.deis.unibo.it/ |archive-date=11 October 2007 |df=dmy-all }}</ref><ref>{{Cite journal |last1=Caini |first1=Carlo |last2=Firrincieli |first2=Rosario |date=2004 |title=TCP Hybla: a TCP enhancement for heterogeneous networks |url=https://onlinelibrary.wiley.com/doi/10.1002/sat.799 |journal=International Journal of Satellite Communications and Networking |language=en |volume=22 |issue=5 |pages=547–566 |doi=10.1002/sat.799 |s2cid=2360535 |issn=1542-0973}}</ref> इसका उद्देश्य उच्च-विलंबता स्थलीय या उपग्रह रेडियो लिंक का उपयोग करने वाले टीसीपी कनेक्शनों पर दंड को समाप्त करना है। हाइब्ला सुधार कंजेशन विंडो गतिशीलता के विश्लेषणात्मक मूल्यांकन पर आधारित हैं।<ref>{{Cite book |last1=Caini |first1=C. |last2=Firrincieli |first2=R. |last3=Lacamera |first3=D. |title=2009 IEEE International Conference on Communications |chapter=Comparative Performance Evaluation of TCP Variants on Satellite Environments |date=2009 |chapter-url=https://ieeexplore.ieee.org/document/5198834 |pages=1–5 |doi=10.1109/ICC.2009.5198834|s2cid=8352762 }}</ref>
टीसीपी हाइब्ला<ref>{{cite web |url=http://hybla.deis.unibo.it/ |title=हाइब्ला होम पेज|access-date=2007-03-04 |archive-url=https://web.archive.org/web/20071011095352/http://hybla.deis.unibo.it/ |archive-date=11 October 2007 |df=dmy-all }}</ref><ref>{{Cite journal |last1=Caini |first1=Carlo |last2=Firrincieli |first2=Rosario |date=2004 |title=TCP Hybla: a TCP enhancement for heterogeneous networks |url=https://onlinelibrary.wiley.com/doi/10.1002/sat.799 |journal=International Journal of Satellite Communications and Networking |language=en |volume=22 |issue=5 |pages=547–566 |doi=10.1002/sat.799 |s2cid=2360535 |issn=1542-0973}}</ref> इसका उद्देश्य उच्च-विलंबता स्थलीय या उपग्रह रेडियो लिंक का उपयोग करने वाले टीसीपी कनेक्शनों पर दंड को समाप्त करना है। हाइब्ला सुधार कंजेशन विंडो गतिशीलता के विश्लेषणात्मक मूल्यांकन पर आधारित हैं।<ref>{{Cite book |last1=Caini |first1=C. |last2=Firrincieli |first2=R. |last3=Lacamera |first3=D. |title=2009 IEEE International Conference on Communications |chapter=Comparative Performance Evaluation of TCP Variants on Satellite Environments |date=2009 |chapter-url=https://ieeexplore.ieee.org/document/5198834 |pages=1–5 |doi=10.1109/ICC.2009.5198834|s2cid=8352762 }}</ref>


 
'''टीसीपी बीआईसी'''
=== टीसीपी बीआईसी ===
{{main|BIC TCP}}
{{main|BIC TCP}}
बाइनरी इनक्रीस कंजेशन कंट्रोल (बीआईसी) उच्च विलंबता वाले हाई-स्पीड नेटवर्क के लिए अनुकूलित सीसीए के साथ  टीसीपी कार्यान्वयन है, जिसे लंबे वसा नेटवर्क (एलएफएन) के रूप में जाना जाता है।<ref>{{cite IETF |title=लंबी-विलंबित पथों के लिए टीसीपी एक्सटेंशन|first1=Jacobson |last1=V. |first2=Braden |last2=R.T. |rfc=1072}}</ref> [[लिनक्स कर्नेल]] 2.6.8 से 2.6.18 तक डिफ़ॉल्ट रूप से बीआईसी का उपयोग किया जाता है।{{citation needed|date=March 2020}}
बाइनरी इनक्रीस कंजेशन कंट्रोल (बीआईसी) उच्च विलंबता वाले हाई-स्पीड नेटवर्क के लिए अनुकूलित सीसीए के साथ  टीसीपी कार्यान्वयन है, जिसे लंबे वसा नेटवर्क (एलएफएन) के रूप में जाना जाता है।<ref>{{cite IETF |title=लंबी-विलंबित पथों के लिए टीसीपी एक्सटेंशन|first1=Jacobson |last1=V. |first2=Braden |last2=R.T. |rfc=1072}}</ref> [[लिनक्स कर्नेल]] 2.6.8 से 2.6.18 तक डिफ़ॉल्ट रूप से बीआईसी का उपयोग किया जाता है।{{citation needed|date=March 2020}}
Line 266: Line 264:
=== टीसीपी वेस्टवुड+ ===
=== टीसीपी वेस्टवुड+ ===
{{main|TCP Westwood plus}}
{{main|TCP Westwood plus}}
वेस्टवुड+ टीसीपी रेनो का केवल-प्रेषक संशोधन है जो वायर्ड और [[ बेतार तंत्र ]] दोनों पर टीसीपी कंजेशन नियंत्रण के प्रदर्शन को अनुकूलित करता है। टीसीपी वेस्टवुड+ कंजेशन एपिसोड के बाद, यानी तीन डुप्लिकेट पावती या टाइमआउट के बाद कंजेशन विंडो और धीमी शुरुआत सीमा निर्धारित करने के लिए एंड-टू-एंड [[बैंडविड्थ (कंप्यूटिंग)]] अनुमान पर आधारित है। पावती पैकेट लौटाने की दर के औसत से बैंडविड्थ का अनुमान लगाया जाता है। टीसीपी रेनो के विपरीत, जो तीन डुप्लिकेट एसीके के बाद कंजेशन विंडो को आँख बंद करके आधा कर देता है, टीसीपी वेस्टवुड+ अनुकूल रूप से  धीमी शुरुआत सीमा और  कंजेशन विंडो सेट करता है जो कंजेशन के अनुभव के समय उपलब्ध बैंडविड्थ के अनुमान को ध्यान में रखता है। रेनो और न्यू रेनो की तुलना में, वेस्टवुड+ वायरलेस लिंक पर थ्रूपुट को महत्वपूर्ण रूप से बढ़ाता है और वायर्ड नेटवर्क में निष्पक्षता में सुधार करता है।{{citation needed|date=August 2020}}
वेस्टवुड+ टीसीपी रेनो का केवल-प्रेषक संशोधन है जो वायर्ड और [[ बेतार तंत्र ]] दोनों पर टीसीपी कंजेशन नियंत्रण के प्रदर्शन को अनुकूलित करता है। टीसीपी वेस्टवुड+ कंजेशन एपिसोड के बाद, यानी तीन डुप्लिकेट पावती या टाइमआउट के बाद कंजेशन विंडो और धीमी शुरुआत सीमा निर्धारित करने के लिए एंड-टू-एंड [[बैंडविड्थ (कंप्यूटिंग)]] अनुमान पर आधारित है। पावती पैकेट लौटाने की दर के औसत से बैंडविड्थ का अनुमान लगाया जाता है। टीसीपी रेनो के विपरीत, जो तीन डुप्लिकेट एसीके के बाद कंजेशन विंडो को आँख बंद करके आधा कर देता है, टीसीपी वेस्टवुड+ अनुकूल रूप से  धीमी शुरुआत सीमा और  कंजेशन विंडो सेट करता है जो कंजेशन के अनुभव के समय उपलब्ध बैंडविड्थ के अनुमान को ध्यान में रखता है। रेनो और न्यू रेनो की तुलना में, वेस्टवुड+ वायरलेस लिंक पर थ्रूपुट को महत्वपूर्ण रूप से बढ़ाता है और वायर्ड नेटवर्क में निष्पक्षता में सुधार करता है।


=== कंपाउंड टीसीपी ===
=== कंपाउंड टीसीपी ===
Line 275: Line 273:
टीसीपी आनुपातिक दर में कमी (पीआरआर)<ref>{{cite IETF |rfc=6937 |title=टीसीपी के लिए आनुपातिक दर में कमी|year=2013 |doi=10.17487/RFC6937 |last1=Mathis |first1=M. |last2=Dukkipati |first2=N. |last3=Cheng |first3=Y. |doi-access=free}}</ref> पुनर्प्राप्ति के दौरान भेजे गए डेटा की सटीकता में सुधार करने के लिए डिज़ाइन किया गया  एल्गोरिदम है। एल्गोरिदम यह सुनिश्चित करता है कि पुनर्प्राप्ति के बाद विंडो का आकार धीमी शुरुआत सीमा के जितना संभव हो उतना करीब हो। [[Google]] द्वारा किए गए परीक्षणों में, PRR के परिणामस्वरूप औसत विलंबता में 3-10% की कमी आई और पुनर्प्राप्ति समयबाह्य में 5% की कमी आई।<ref>{{cite web|last1=Corbet|first1=Jonathan|title=LPC: Making the net go faster|url=https://lwn.net/Articles/458610/|access-date=6 June 2014}}</ref> पीआरआर संस्करण 3.2 से लिनक्स कर्नेल में उपलब्ध है।<ref>{{cite web|title=Linux 3.2 - Linux Kernel Newbies|url=http://kernelnewbies.org/Linux_3.2#head-1c3e71416a9fdc2f59c1c251a97963f165302b6e|access-date=6 June 2014}}</ref>
टीसीपी आनुपातिक दर में कमी (पीआरआर)<ref>{{cite IETF |rfc=6937 |title=टीसीपी के लिए आनुपातिक दर में कमी|year=2013 |doi=10.17487/RFC6937 |last1=Mathis |first1=M. |last2=Dukkipati |first2=N. |last3=Cheng |first3=Y. |doi-access=free}}</ref> पुनर्प्राप्ति के दौरान भेजे गए डेटा की सटीकता में सुधार करने के लिए डिज़ाइन किया गया  एल्गोरिदम है। एल्गोरिदम यह सुनिश्चित करता है कि पुनर्प्राप्ति के बाद विंडो का आकार धीमी शुरुआत सीमा के जितना संभव हो उतना करीब हो। [[Google]] द्वारा किए गए परीक्षणों में, PRR के परिणामस्वरूप औसत विलंबता में 3-10% की कमी आई और पुनर्प्राप्ति समयबाह्य में 5% की कमी आई।<ref>{{cite web|last1=Corbet|first1=Jonathan|title=LPC: Making the net go faster|url=https://lwn.net/Articles/458610/|access-date=6 June 2014}}</ref> पीआरआर संस्करण 3.2 से लिनक्स कर्नेल में उपलब्ध है।<ref>{{cite web|title=Linux 3.2 - Linux Kernel Newbies|url=http://kernelnewbies.org/Linux_3.2#head-1c3e71416a9fdc2f59c1c251a97963f165302b6e|access-date=6 June 2014}}</ref>


'''टीसीपी बीबीआर'''


=== टीसीपी बीबीआर ===
बॉटलनेक बैंडविड्थ और राउंड-ट्रिप प्रसार समय (बीबीआर) 2016 में Google द्वारा विकसित  CCA है।<ref name=GOOGBBR>{{cite web|title=BBR: Congestion-Based Congestion Control|url=https://research.google.com/pubs/pub45646.html|access-date=25 August 2017}}</ref> जबकि अधिकांश सीसीए हानि-आधारित हैं, इसमें वे भीड़भाड़ और ट्रांसमिशन की कम दरों का पता लगाने के लिए पैकेट हानि पर भरोसा करते हैं, बीबीआर, टीसीपी वेगास की तरह, मॉडल-आधारित है। एल्गोरिदम अधिकतम बैंडविड्थ और राउंड-ट्रिप समय का उपयोग करता है जिस पर नेटवर्क ने नेटवर्क का  मॉडल बनाने के लिए आउटबाउंड डेटा पैकेट की सबसे हालिया उड़ान वितरित की। पैकेट डिलीवरी की प्रत्येक संचयी या चयनात्मक पावती  दर नमूना उत्पन्न करती है जो डेटा पैकेट के प्रसारण और उस पैकेट की पावती के बीच समय अंतराल पर वितरित डेटा की मात्रा को रिकॉर्ड करती है।<ref>{{cite journal |title=डिलिवरी दर अनुमान|url=https://tools.ietf.org/html/draft-cheng-iccrg-delivery-rate-estimation-00#section-2.2|access-date=25 August 2017|last1=Cheng|first1=Yuchung|last2=Cardwell|first2=Neal|last3=Yeganeh|first3=Soheil Hassas|last4=Jacobson|first4=Van|website=IETF}}</ref>
बॉटलनेक बैंडविड्थ और राउंड-ट्रिप प्रसार समय (बीबीआर) 2016 में Google द्वारा विकसित  CCA है।<ref name=GOOGBBR>{{cite web|title=BBR: Congestion-Based Congestion Control|url=https://research.google.com/pubs/pub45646.html|access-date=25 August 2017}}</ref> जबकि अधिकांश सीसीए हानि-आधारित हैं, इसमें वे भीड़भाड़ और ट्रांसमिशन की कम दरों का पता लगाने के लिए पैकेट हानि पर भरोसा करते हैं, बीबीआर, #टीसीपी वेगास की तरह, मॉडल-आधारित है। एल्गोरिदम अधिकतम बैंडविड्थ और राउंड-ट्रिप समय का उपयोग करता है जिस पर नेटवर्क ने नेटवर्क का  मॉडल बनाने के लिए आउटबाउंड डेटा पैकेट की सबसे हालिया उड़ान वितरित की। पैकेट डिलीवरी की प्रत्येक संचयी या चयनात्मक पावती  दर नमूना उत्पन्न करती है जो डेटा पैकेट के प्रसारण और उस पैकेट की पावती के बीच समय अंतराल पर वितरित डेटा की मात्रा को रिकॉर्ड करती है।<ref>{{cite journal |title=डिलिवरी दर अनुमान|url=https://tools.ietf.org/html/draft-cheng-iccrg-delivery-rate-estimation-00#section-2.2|access-date=25 August 2017|last1=Cheng|first1=Yuchung|last2=Cardwell|first2=Neal|last3=Yeganeh|first3=Soheil Hassas|last4=Jacobson|first4=Van|website=IETF}}</ref>
जब [[YouTube]] पर लागू किया गया, तो BBRv1 ने औसतन 4% अधिक नेटवर्क थ्रूपुट और कुछ देशों में 14% तक का उत्पादन किया।<ref>{{cite web|title=TCP BBR congestion control comes to GCP – your Internet just got faster|url=https://cloudplatform.googleblog.com/2017/07/TCP-BBR-congestion-control-comes-to-GCP-your-Internet-just-got-faster.html|access-date=25 August 2017}}</ref> लिनक्स 4.9 से बीबीआर लिनक्स टीसीपी के लिए उपलब्ध है।<ref>{{cite web|url=https://lwn.net/Articles/701165/|title=BBR congestion control [LWN.net]|website=lwn.net}}</ref> यह [[QUIC]] के लिए भी उपलब्ध है।<ref>{{cite web |url=https://datatracker.ietf.org/meeting/100/materials/slides-100-iccrg-a-quick-bbr-update-bbr-in-shallow-buffers |title=बीबीआर अद्यतन|website=IETF}}</ref>
जब [[YouTube]] पर लागू किया गया, तो BBRv1 ने औसतन 4% अधिक नेटवर्क थ्रूपुट और कुछ देशों में 14% तक का उत्पादन किया।<ref>{{cite web|title=TCP BBR congestion control comes to GCP – your Internet just got faster|url=https://cloudplatform.googleblog.com/2017/07/TCP-BBR-congestion-control-comes-to-GCP-your-Internet-just-got-faster.html|access-date=25 August 2017}}</ref> लिनक्स 4.9 से बीबीआर लिनक्स टीसीपी के लिए उपलब्ध है।<ref>{{cite web|url=https://lwn.net/Articles/701165/|title=BBR congestion control [LWN.net]|website=lwn.net}}</ref> यह [[QUIC]] के लिए भी उपलब्ध है।<ref>{{cite web |url=https://datatracker.ietf.org/meeting/100/materials/slides-100-iccrg-a-quick-bbr-update-bbr-in-shallow-buffers |title=बीबीआर अद्यतन|website=IETF}}</ref>
बीबीआर संस्करण 1 (बीबीआरवी1) की गैर-बीबीआर धाराओं के प्रति निष्पक्षता विवादित है। जबकि Google की प्रस्तुति BBRv1 को CUBIC के साथ अच्छी तरह से सह-अस्तित्व में दिखाती है,<ref name=GOOGBBR/>ज्योफ हस्टन और हॉक, ब्लेस और ज़िटरबार्ट जैसे शोधकर्ताओं ने इसे अन्य धाराओं के लिए अनुचित और स्केलेबल नहीं पाया।<ref>{{cite web|title=टीसीपी और बीबीआर|url=https://ripe76.ripe.net/presentations/10-2018-05-15-bbr.pdf|access-date=27 May 2018}}</ref> हॉक एट अल. लिनक्स 4.9 के बीबीआर कार्यान्वयन में कतार में बढ़ती देरी, अनुचितता और बड़े पैमाने पर पैकेट हानि जैसे कुछ गंभीर अंतर्निहित मुद्दे भी पाए गए।<ref>{{cite web|title=बीबीआर कंजेशन नियंत्रण का प्रायोगिक मूल्यांकन|url=https://doc.tm.uka.de/2017-kit-icnp-bbr-authors-copy.pdf|access-date=27 May 2018}}</ref> सोहेल अब्बासलू एट अल। (C2TCP के लेखक) बताते हैं कि BBRv1 सेलुलर नेटवर्क जैसे गतिशील वातावरण में अच्छा प्रदर्शन नहीं करता है।<ref name="C2TCP-JSAC"/><ref name="C2TCP"/>उन्होंने यह भी दिखाया है कि बीबीआर में अनुचितता का मुद्दा है। उदाहरण के लिए, जब  [[CUBIC TCP]] प्रवाह (जो Linux, Android और MacOS में डिफ़ॉल्ट ट्रांसमिशन कंट्रोल प्रोटोकॉल कार्यान्वयन है) नेटवर्क में BBR प्रवाह के साथ सह-अस्तित्व में होता है, तो BBR प्रवाह CUBIC प्रवाह पर हावी हो सकता है और इससे संपूर्ण लिंक बैंडविड्थ प्राप्त कर सकता है। (चित्र 16 देखें <ref name="C2TCP-JSAC"/>).
बीबीआर संस्करण 1 (बीबीआरवी1) की गैर-बीबीआर धाराओं के प्रति निष्पक्षता विवादित है। जबकि Google की प्रस्तुति BBRv1 को CUBIC के साथ अच्छी तरह से सह-अस्तित्व में दिखाती है,<ref name=GOOGBBR/>ज्योफ हस्टन और हॉक, ब्लेस और ज़िटरबार्ट जैसे शोधकर्ताओं ने इसे अन्य धाराओं के लिए अनुचित और स्केलेबल नहीं पाया।<ref>{{cite web|title=टीसीपी और बीबीआर|url=https://ripe76.ripe.net/presentations/10-2018-05-15-bbr.pdf|access-date=27 May 2018}}</ref> हॉक एट अल. लिनक्स 4.9 के बीबीआर कार्यान्वयन में कतार में बढ़ती देरी, अनुचितता और बड़े पैमाने पर पैकेट हानि जैसे कुछ गंभीर अंतर्निहित मुद्दे भी पाए गए।<ref>{{cite web|title=बीबीआर कंजेशन नियंत्रण का प्रायोगिक मूल्यांकन|url=https://doc.tm.uka.de/2017-kit-icnp-bbr-authors-copy.pdf|access-date=27 May 2018}}</ref> सोहेल अब्बासलू एट अल। (C2TCP के लेखक) बताते हैं कि BBRv1 सेलुलर नेटवर्क जैसे गतिशील वातावरण में अच्छा प्रदर्शन नहीं करता है।<ref name="C2TCP-JSAC"/><ref name="C2TCP"/>उन्होंने यह भी दिखाया है कि बीबीआर में अनुचितता का मुद्दा है। उदाहरण के लिए, जब  [[CUBIC TCP]] प्रवाह (जो Linux, Android और MacOS में डिफ़ॉल्ट ट्रांसमिशन कंट्रोल प्रोटोकॉल कार्यान्वयन है) नेटवर्क में BBR प्रवाह के साथ सह-अस्तित्व में होता है, तो BBR प्रवाह CUBIC प्रवाह पर हावी हो सकता है और इससे संपूर्ण लिंक बैंडविड्थ प्राप्त कर सकता है। (चित्र 16 देखें <ref name="C2TCP-JSAC"/>).


संस्करण 2 CUBIC जैसे हानि-आधारित भीड़ प्रबंधन के साथ संचालन करते समय अनुचितता के मुद्दे से निपटने का प्रयास करता है।<ref>{{cite web|title=A Performance Evaluation of TCP BBRv2|url=https://www.researchgate.net/publication/341781089|access-date=12 January 2021}}</ref> BBRv2 में BBRv1 द्वारा उपयोग किए गए मॉडल को पैकेट हानि के बारे में जानकारी और स्पष्ट भीड़ अधिसूचना (ECN) से जानकारी शामिल करने के लिए संवर्धित किया गया है।<ref name=bbr3>{{cite conference|conference=IETF 117: San Francisco |author1=Google TCP BBR team |author2=Google QUIC BBR team |title=BBRv3: Algorithm Bug Fixes and Public Internet Deployment |url=https://datatracker.ietf.org/meeting/117/materials/slides-117-ccwg-bbrv3-algorithm-bug-fixes-and-public-internet-deployment-00 |date=Jul 26, 2023}}</ref> हालाँकि BBRv2 में कई बार BBRv1 की तुलना में कम थ्रूपुट हो सकता है, लेकिन आमतौर पर इसे बेहतर [[गुडपुट]] माना जाता है।{{cn|date=June 2023}}
संस्करण 2 CUBIC जैसे हानि-आधारित भीड़ प्रबंधन के साथ संचालन करते समय अनुचितता के मुद्दे से निपटने का प्रयास करता है।<ref>{{cite web|title=A Performance Evaluation of TCP BBRv2|url=https://www.researchgate.net/publication/341781089|access-date=12 January 2021}}</ref> BBRv2 में BBRv1 द्वारा उपयोग किए गए मॉडल को पैकेट हानि के बारे में जानकारी और स्पष्ट भीड़ अधिसूचना (ECN) से जानकारी शामिल करने के लिए संवर्धित किया गया है।<ref name=bbr3>{{cite conference|conference=IETF 117: San Francisco |author1=Google TCP BBR team |author2=Google QUIC BBR team |title=BBRv3: Algorithm Bug Fixes and Public Internet Deployment |url=https://datatracker.ietf.org/meeting/117/materials/slides-117-ccwg-bbrv3-algorithm-bug-fixes-and-public-internet-deployment-00 |date=Jul 26, 2023}}</ref> हालाँकि BBRv2 में कई बार BBRv1 की तुलना में कम थ्रूपुट हो सकता है, लेकिन आमतौर पर इसे बेहतर [[गुडपुट]] माना जाता है।


संस्करण 3 (बीबीआरवी3) बीबीआरवी2 में दो बग को ठीक करता है (बैंडविड्थ जांच का समय से पहले समाप्त होना, बैंडविड्थ अभिसरण) और कुछ प्रदर्शन ट्यूनिंग करता है।  वैरिएंट भी है, जिसे BBR.Swift कहा जाता है, जो डेटासेंटर-आंतरिक लिंक के लिए अनुकूलित है: यह मुख्य भीड़ नियंत्रण सिग्नल के रूप में नेटवर्क_आरटीटी (रिसीवर देरी को छोड़कर) का उपयोग करता है।<ref name=bbr3/>
संस्करण 3 (बीबीआरवी3) बीबीआरवी2 में दो बग को ठीक करता है (बैंडविड्थ जांच का समय से पहले समाप्त होना, बैंडविड्थ अभिसरण) और कुछ प्रदर्शन ट्यूनिंग करता है।  वैरिएंट भी है, जिसे BBR.Swift कहा जाता है, जो डेटासेंटर-आंतरिक लिंक के लिए अनुकूलित है: यह मुख्य भीड़ नियंत्रण सिग्नल के रूप में नेटवर्क_आरटीटी (रिसीवर देरी को छोड़कर) का उपयोग करता है।<ref name=bbr3/>


'''C2TCP'''


=== C2TCP ===
सेलुलर नियंत्रित विलंब टीसीपी (C2TCP)<ref name="C2TCP-JSAC"/><ref name="C2TCP"/> लचीले एंड-टू-एंड टीसीपी दृष्टिकोण की कमी से प्रेरित था जो नेटवर्क उपकरणों में किसी भी बदलाव की आवश्यकता के बिना विभिन्न अनुप्रयोगों के लिए सेवा की विभिन्न गुणवत्ता आवश्यकताओं को पूरा कर सकता है। C2TCP का लक्ष्य वर्तमान LTE (दूरसंचार) और भविष्य के [[5G]] जैसे अत्यधिक गतिशील वातावरण में [[ आभासी वास्तविकता ]], [[वीडियो कॉन्फ्रेंसिंग]], [[ऑनलाइन गेम]], [[वाहन संचार प्रणाली]] आदि जैसे अनुप्रयोगों की अल्ट्रा-लो [[ विलंबता (इंजीनियरिंग) ]] और उच्च-बैंडविड्थ आवश्यकताओं को पूरा करना है। [[सेल्युलर नेटवर्क]] C2TCP हानि-आधारित टीसीपी (जैसे रेनो, न्यूरेनो, क्यूबिक टीसीपी, [[बीआईसी टीसीपी]], ...) के शीर्ष पर  [[प्लग-इन (कंप्यूटिंग)]] | ऐड-ऑन के रूप में काम करता है, इसे केवल सर्वर-साइड पर स्थापित करना आवश्यक है और पैकेटों के औसत विलंब को अनुप्रयोगों द्वारा निर्धारित वांछित विलंबों तक सीमित कर देता है।
सेलुलर नियंत्रित विलंब टीसीपी (C2TCP)<ref name="C2TCP-JSAC"/><ref name="C2TCP"/> लचीले एंड-टू-एंड टीसीपी दृष्टिकोण की कमी से प्रेरित था जो नेटवर्क उपकरणों में किसी भी बदलाव की आवश्यकता के बिना विभिन्न अनुप्रयोगों के लिए सेवा की विभिन्न गुणवत्ता आवश्यकताओं को पूरा कर सकता है। C2TCP का लक्ष्य वर्तमान LTE (दूरसंचार) और भविष्य के [[5G]] जैसे अत्यधिक गतिशील वातावरण में [[ आभासी वास्तविकता ]], [[वीडियो कॉन्फ्रेंसिंग]], [[ऑनलाइन गेम]], [[वाहन संचार प्रणाली]] आदि जैसे अनुप्रयोगों की अल्ट्रा-लो [[ विलंबता (इंजीनियरिंग) ]] और उच्च-बैंडविड्थ आवश्यकताओं को पूरा करना है। [[सेल्युलर नेटवर्क]]. C2TCP हानि-आधारित टीसीपी (जैसे रेनो, न्यूरेनो, क्यूबिक टीसीपी, [[बीआईसी टीसीपी]], ...) के शीर्ष पर  [[प्लग-इन (कंप्यूटिंग)]] | ऐड-ऑन के रूप में काम करता है, इसे केवल सर्वर-साइड पर स्थापित करना आवश्यक है और पैकेटों के औसत विलंब को अनुप्रयोगों द्वारा निर्धारित वांछित विलंबों तक सीमित कर देता है।


[[न्यूयॉर्क विश्वविद्यालय]] के शोधकर्ता<ref>{{Cite web|url=https://wp.nyu.edu/c2tcp/|title=Cellular Controlled Delay TCP (C2TCP)|website=wp.nyu.edu|access-date=2019-04-27}}</ref> दिखाया गया कि C2TCP विभिन्न अत्याधुनिक टीसीपी योजनाओं के विलंब और विलंब-भिन्नता प्रदर्शन से बेहतर प्रदर्शन करता है। उदाहरण के लिए, उन्होंने दिखाया कि BBR, CUBIC और वेस्टवुड की तुलना में, C2TCP विभिन्न सेलुलर नेटवर्क वातावरणों पर पैकेट की औसत देरी को क्रमशः 250%, 900% और 700% कम कर देता है।<ref name="C2TCP-JSAC" />
[[न्यूयॉर्क विश्वविद्यालय]] के शोधकर्ता<ref>{{Cite web|url=https://wp.nyu.edu/c2tcp/|title=Cellular Controlled Delay TCP (C2TCP)|website=wp.nyu.edu|access-date=2019-04-27}}</ref> दिखाया गया कि C2TCP विभिन्न अत्याधुनिक टीसीपी योजनाओं के विलंब और विलंब-भिन्नता प्रदर्शन से बेहतर प्रदर्शन करता है। उदाहरण के लिए, उन्होंने दिखाया कि BBR, CUBIC और वेस्टवुड की तुलना में, C2TCP विभिन्न सेलुलर नेटवर्क वातावरणों पर पैकेट की औसत देरी को क्रमशः 250%, 900% और 700% कम कर देता है।<ref name="C2TCP-JSAC" />


'''इलास्टिक-टीसीपी'''


=== इलास्टिक-टीसीपी ===
क्लाउड कंप्यूटिंग के समर्थन में उच्च-बीडीपी नेटवर्क पर बैंडविड्थ उपयोग को बढ़ाने के लिए फरवरी 2019 में इलास्टिक-टीसीपी का प्रस्ताव दिया गया था। यह  Linux-आधारित CCA है जिसे Linux कर्नेल के लिए डिज़ाइन किया गया है। यह  रिसीवर-साइड एल्गोरिदम है जो विंडो-सहसंबंधित वेटिंग फ़ंक्शन (डब्ल्यूडब्ल्यूएफ) नामक  उपन्यास तंत्र का उपयोग करके हानि-विलंब-आधारित दृष्टिकोण को नियोजित करता है। इसमें मानव ट्यूनिंग की आवश्यकता के बिना विभिन्न नेटवर्क विशेषताओं से निपटने के लिए उच्च स्तर की लोच है। एनएस-2 सिम्युलेटर और टेस्टबेड का उपयोग करके इसके प्रदर्शन की तुलना कंपाउंड टीसीपी (एमएस विंडोज में डिफ़ॉल्ट सीसीए), क्यूबिक (लिनक्स के लिए डिफ़ॉल्ट) और टीसीपी-बीबीआर (Google द्वारा उपयोग किए जाने वाले लिनक्स 4.9 का डिफ़ॉल्ट) से तुलना करके की गई है। इलास्टिक-टीसीपी औसत थ्रूपुट, हानि अनुपात और देरी के मामले में कुल प्रदर्शन में उल्लेखनीय सुधार करता है।<ref name="elastictcp" />
क्लाउड कंप्यूटिंग के समर्थन में उच्च-बीडीपी नेटवर्क पर बैंडविड्थ उपयोग को बढ़ाने के लिए फरवरी 2019 में इलास्टिक-टीसीपी का प्रस्ताव दिया गया था। यह  Linux-आधारित CCA है जिसे Linux कर्नेल के लिए डिज़ाइन किया गया है। यह  रिसीवर-साइड एल्गोरिदम है जो विंडो-सहसंबंधित वेटिंग फ़ंक्शन (डब्ल्यूडब्ल्यूएफ) नामक  उपन्यास तंत्र का उपयोग करके हानि-विलंब-आधारित दृष्टिकोण को नियोजित करता है। इसमें मानव ट्यूनिंग की आवश्यकता के बिना विभिन्न नेटवर्क विशेषताओं से निपटने के लिए उच्च स्तर की लोच है। एनएस-2 सिम्युलेटर और टेस्टबेड का उपयोग करके इसके प्रदर्शन की तुलना कंपाउंड टीसीपी (एमएस विंडोज में डिफ़ॉल्ट सीसीए), क्यूबिक (लिनक्स के लिए डिफ़ॉल्ट) और टीसीपी-बीबीआर (Google द्वारा उपयोग किए जाने वाले लिनक्स 4.9 का डिफ़ॉल्ट) से तुलना करके की गई है। इलास्टिक-टीसीपी औसत थ्रूपुट, हानि अनुपात और देरी के मामले में कुल प्रदर्शन में उल्लेखनीय सुधार करता है।<ref name="elastictcp" />


'''एनएटीसीपी'''


=== एनएटीसीपी ===
सोहेल अब्बासलू एट अल। प्रस्तावित NATCP (नेटवर्क-असिस्टेड टीसीपी){{sfn|Abbasloo|Xu|Chao|Shi|2019}} ए {{According to whom|controversial|date=October 2021}} टीसीपी डिज़ाइन [[मल्टी-एक्सेस एज कंप्यूटिंग|मल्टी-्सेस एज कंप्यूटिंग]] (एमईसी) को लक्षित करता है। NATCP का मुख्य विचार यह है कि यदि नेटवर्क की विशेषताओं के बारे में पहले से पता होता, तो TCP को अलग तरह से डिज़ाइन किया गया होता। इसलिए, NATCP टीसीपी के प्रदर्शन को इष्टतम प्रदर्शन के करीब पहुंचाने के लिए वर्तमान एमईसी-आधारित सेलुलर आर्किटेक्चर में उपलब्ध सुविधाओं और गुणों को नियोजित करता है। NATCP नेटवर्क से पास में स्थित सर्वर पर आउट-ऑफ-बैंड फीडबैक का उपयोग करता है। नेटवर्क से फीडबैक, जिसमें सेलुलर ्सेस लिंक की क्षमता और नेटवर्क का न्यूनतम आरटीटी शामिल है, सर्वर को उनकी भेजने की दरों को समायोजित करने के लिए मार्गदर्शन करता है। जैसा कि प्रारंभिक परिणाम दिखाते हैं, NATCP अत्याधुनिक टीसीपी योजनाओं से बेहतर प्रदर्शन करता है।{{sfn|Abbasloo|Xu|Chao|Shi|2019}}<ref>{{Citation|last=Abbasloo|first=Soheil|title=GitHub - Soheil-ab/natcp|date=2019-06-03|url=https://github.com/Soheil-ab/natcp|access-date=2019-08-05}}</ref>
सोहेल अब्बासलू एट अल। प्रस्तावित NATCP (नेटवर्क-असिस्टेड टीसीपी){{sfn|Abbasloo|Xu|Chao|Shi|2019}} ए {{According to whom|controversial|date=October 2021}} टीसीपी डिज़ाइन [[मल्टी-एक्सेस एज कंप्यूटिंग|मल्टी-्सेस एज कंप्यूटिंग]] (एमईसी) को लक्षित करता है। NATCP का मुख्य विचार यह है कि यदि नेटवर्क की विशेषताओं के बारे में पहले से पता होता, तो TCP को अलग तरह से डिज़ाइन किया गया होता। इसलिए, NATCP टीसीपी के प्रदर्शन को इष्टतम प्रदर्शन के करीब पहुंचाने के लिए वर्तमान एमईसी-आधारित सेलुलर आर्किटेक्चर में उपलब्ध सुविधाओं और गुणों को नियोजित करता है। NATCP नेटवर्क से पास में स्थित सर्वर पर आउट-ऑफ-बैंड फीडबैक का उपयोग करता है। नेटवर्क से फीडबैक, जिसमें सेलुलर ्सेस लिंक की क्षमता और नेटवर्क का न्यूनतम आरटीटी शामिल है, सर्वर को उनकी भेजने की दरों को समायोजित करने के लिए मार्गदर्शन करता है। जैसा कि प्रारंभिक परिणाम दिखाते हैं, NATCP अत्याधुनिक टीसीपी योजनाओं से बेहतर प्रदर्शन करता है।{{sfn|Abbasloo|Xu|Chao|Shi|2019}}<ref>{{Citation|last=Abbasloo|first=Soheil|title=GitHub - Soheil-ab/natcp|date=2019-06-03|url=https://github.com/Soheil-ab/natcp|access-date=2019-08-05}}</ref>


 
'''अन्य टीसीपी भीड़ से बचाव एल्गोरिदम'''
=== अन्य टीसीपी भीड़ से बचाव एल्गोरिदम ===
* [[तेज़ टीसीपी]]
* [[तेज़ टीसीपी]]
* सामान्यीकृत फास्ट टीसीपी<ref>{{Cite journal|last1=Yuan|first1=Cao|last2=Tan|first2=Liansheng|last3=Andrew|first3=Lachlan L. H.|last4=Zhang|first4=Wei|last5=Zukerman|first5=Moshe|date=6 June 2008 |title=एक सामान्यीकृत फास्ट टीसीपी योजना|journal=Computer Communications|volume=31|issue=14|pages=3242–3249|doi=10.1016/j.comcom.2008.05.028|hdl=1959.3/44051|s2cid=17988768 |url=https://resolver.caltech.edu/CaltechAUTHORS:YUAcc08|hdl-access=free}}</ref>
* सामान्यीकृत फास्ट टीसीपी<ref>{{Cite journal|last1=Yuan|first1=Cao|last2=Tan|first2=Liansheng|last3=Andrew|first3=Lachlan L. H.|last4=Zhang|first4=Wei|last5=Zukerman|first5=Moshe|date=6 June 2008 |title=एक सामान्यीकृत फास्ट टीसीपी योजना|journal=Computer Communications|volume=31|issue=14|pages=3242–3249|doi=10.1016/j.comcom.2008.05.028|hdl=1959.3/44051|s2cid=17988768 |url=https://resolver.caltech.edu/CaltechAUTHORS:YUAcc08|hdl-access=free}}</ref>
Line 320: Line 317:
*नेक्सजेन डी-टीसीपी<ref>{{Cite journal|last1=Kanagarathinam|first1=Madhan Raj|last2=Singh|first2=Sukhdeep|last3=Sandeep|first3=Irlanki|last4=Kim|first4=Hanseok|last5=Maheshwari|first5=Mukesh Kumar|last6=Hwang|first6=Jaehyun|last7=Roy|first7=Abhishek|last8=Saxena|first8=Navrati|date=2020|title=NexGen D-TCP: Next Generation Dynamic TCP Congestion Control Algorithm|journal=IEEE Access|volume=8|pages=164482–164496|doi=10.1109/ACCESS.2020.3022284|s2cid=221846931 |issn=2169-3536|doi-access=free}}</ref>
*नेक्सजेन डी-टीसीपी<ref>{{Cite journal|last1=Kanagarathinam|first1=Madhan Raj|last2=Singh|first2=Sukhdeep|last3=Sandeep|first3=Irlanki|last4=Kim|first4=Hanseok|last5=Maheshwari|first5=Mukesh Kumar|last6=Hwang|first6=Jaehyun|last7=Roy|first7=Abhishek|last8=Saxena|first8=Navrati|date=2020|title=NexGen D-TCP: Next Generation Dynamic TCP Congestion Control Algorithm|journal=IEEE Access|volume=8|pages=164482–164496|doi=10.1109/ACCESS.2020.3022284|s2cid=221846931 |issn=2169-3536|doi-access=free}}</ref>
* कप <ref>{{Cite journal|last1=Arun|first1=Venkat|last2=Balakrishnan|first2=Hari|date=2018|title=Copa: Practical Delay-Based Congestion Control for the Internet|url=https://www.usenix.org/conference/nsdi18/presentation/arun|journal=15th USENIX Symposium on Networked Systems Design and Implementation (NSDI 18)|pages=329–342|isbn=978-1-939133-01-4}}</ref>
* कप <ref>{{Cite journal|last1=Arun|first1=Venkat|last2=Balakrishnan|first2=Hari|date=2018|title=Copa: Practical Delay-Based Congestion Control for the Internet|url=https://www.usenix.org/conference/nsdi18/presentation/arun|journal=15th USENIX Symposium on Networked Systems Design and Implementation (NSDI 18)|pages=329–342|isbn=978-1-939133-01-4}}</ref>
#टीसीपी न्यू रेनो सबसे आम तौर पर लागू किया जाने वाला एल्गोरिदम था,{{citation needed|date=September 2021}} सैक समर्थन बहुत आम है{{citation needed|date=September 2021}} और रेनो/न्यू रेनो का विस्तार है। अधिकांश अन्य प्रतिस्पर्धी प्रस्ताव हैं जिन्हें अभी भी मूल्यांकन की आवश्यकता है। 2.6.8 से शुरू होकर लिनक्स कर्नेल ने डिफ़ॉल्ट कार्यान्वयन को न्यू रेनो से बीआईसी टीसीपी में बदल दिया। 2.6.19 संस्करण में डिफ़ॉल्ट कार्यान्वयन को फिर से CUBIC में बदल दिया गया। फ्रीबीएसडी न्यू रेनो को डिफ़ॉल्ट एल्गोरिदम के रूप में उपयोग करता है। हालाँकि, यह कई अन्य विकल्पों का समर्थन करता है।<ref>{{cite web|url=http://forums.freebsd.org/showthread.php?t=22396|title=पांच नए टीसीपी कंजेशन नियंत्रण एल्गोरिदम परियोजना का सारांश|date=8 March 2011 }}</ref>
#टीसीपी न्यू रेनो सबसे आम तौर पर लागू किया जाने वाला एल्गोरिदम था, सैक समर्थन बहुत आम है और रेनो/न्यू रेनो का विस्तार है। अधिकांश अन्य प्रतिस्पर्धी प्रस्ताव हैं जिन्हें अभी भी मूल्यांकन की आवश्यकता है। 2.6.8 से शुरू होकर लिनक्स कर्नेल ने डिफ़ॉल्ट कार्यान्वयन को न्यू रेनो से बीआईसी टीसीपी में बदल दिया। 2.6.19 संस्करण में डिफ़ॉल्ट कार्यान्वयन को फिर से CUBIC में बदल दिया गया। फ्रीबीएसडी न्यू रेनो को डिफ़ॉल्ट एल्गोरिदम के रूप में उपयोग करता है। हालाँकि, यह कई अन्य विकल्पों का समर्थन करता है।<ref>{{cite web|url=http://forums.freebsd.org/showthread.php?t=22396|title=पांच नए टीसीपी कंजेशन नियंत्रण एल्गोरिदम परियोजना का सारांश|date=8 March 2011 }}</ref>
जब कतार योजना की परवाह किए बिना बैंडविड्थ और विलंबता का प्रति-प्रवाह उत्पाद बढ़ता है, तो टीसीपी अक्षम हो जाता है और अस्थिरता का खतरा होता है। यह और भी महत्वपूर्ण हो जाता है क्योंकि इंटरनेट बहुत उच्च-बैंडविड्थ ऑप्टिकल लिंक को शामिल करने के लिए विकसित हो रहा है।
जब कतार योजना की परवाह किए बिना बैंडविड्थ और विलंबता का प्रति-प्रवाह उत्पाद बढ़ता है, तो टीसीपी अक्षम हो जाता है और अस्थिरता का खतरा होता है। यह और भी महत्वपूर्ण हो जाता है क्योंकि इंटरनेट बहुत उच्च-बैंडविड्थ ऑप्टिकल लिंक को शामिल करने के लिए विकसित हो रहा है।


Line 326: Line 323:


[[ज़ेटा-टीसीपी]] विलंबता और हानि दर दोनों उपायों से भीड़ का पता लगाता है। गुडपुट ज़ेटा-टीसीपी को अधिकतम करने के लिए और भीड़भाड़ की संभावना के आधार पर अलग-अलग कंजेशन विंडो बैकऑफ़ रणनीतियों को लागू करता है। इसमें पैकेट के नुकसान का सटीक पता लगाने के लिए अन्य सुधार भी हैं, जिससे रिट्रांसमिशन टाइमआउट रिट्रांसमिशन से बचा जा सके; और इनबाउंड (डाउनलोड) ट्रैफ़िक को तेज़ और नियंत्रित करें।<ref name="Zeta-TCP">{{cite web |url=http://www.appexnetworks.com/Assets/PDF/ZetaTCP.pdf |title=Whitepaper: Zeta-TCP - Intelligent, Adaptive, Asymmetric TCP Acceleration|access-date=2019-12-06}}</ref>
[[ज़ेटा-टीसीपी]] विलंबता और हानि दर दोनों उपायों से भीड़ का पता लगाता है। गुडपुट ज़ेटा-टीसीपी को अधिकतम करने के लिए और भीड़भाड़ की संभावना के आधार पर अलग-अलग कंजेशन विंडो बैकऑफ़ रणनीतियों को लागू करता है। इसमें पैकेट के नुकसान का सटीक पता लगाने के लिए अन्य सुधार भी हैं, जिससे रिट्रांसमिशन टाइमआउट रिट्रांसमिशन से बचा जा सके; और इनबाउंड (डाउनलोड) ट्रैफ़िक को तेज़ और नियंत्रित करें।<ref name="Zeta-TCP">{{cite web |url=http://www.appexnetworks.com/Assets/PDF/ZetaTCP.pdf |title=Whitepaper: Zeta-TCP - Intelligent, Adaptive, Asymmetric TCP Acceleration|access-date=2019-12-06}}</ref>


== नेटवर्क जागरूकता द्वारा वर्गीकरण ==
== नेटवर्क जागरूकता द्वारा वर्गीकरण ==
Line 361: Line 357:
* नेटवर्क-सहायता प्राप्त भीड़ नियंत्रण
* नेटवर्क-सहायता प्राप्त भीड़ नियंत्रण
** एनएटीसीपी{{sfn|Abbasloo|Xu|Chao|Shi|2019}} - नेटवर्क-असिस्टेड टीसीपी नेटवर्क के न्यूनतम आरटीटी और सेल्युलर ्सेस लिंक की क्षमता को इंगित करने वाले आउट-ऑफ-बैंड स्पष्ट फीडबैक का उपयोग करता है।
** एनएटीसीपी{{sfn|Abbasloo|Xu|Chao|Shi|2019}} - नेटवर्क-असिस्टेड टीसीपी नेटवर्क के न्यूनतम आरटीटी और सेल्युलर ्सेस लिंक की क्षमता को इंगित करने वाले आउट-ऑफ-बैंड स्पष्ट फीडबैक का उपयोग करता है।
**वैरिएबल-स्ट्रक्चर कंजेशन कंट्रोल प्रोटोकॉल (वीसीपी) कंजेशन की नेटवर्क स्थिति पर स्पष्ट रूप से प्रतिक्रिया देने के लिए दो ईसीएन बिट्स का उपयोग करता है। इसमें एंड होस्ट साइड एल्गोरिदम भी शामिल है।{{citation needed|date=February 2022}}
**वैरिएबल-स्ट्रक्चर कंजेशन कंट्रोल प्रोटोकॉल (वीसीपी) कंजेशन की नेटवर्क स्थिति पर स्पष्ट रूप से प्रतिक्रिया देने के लिए दो ईसीएन बिट्स का उपयोग करता है। इसमें एंड होस्ट साइड एल्गोरिदम भी शामिल है।


निम्नलिखित एल्गोरिदम को टीसीपी पैकेट संरचना में कस्टम फ़ील्ड जोड़ने की आवश्यकता होती है:
निम्नलिखित एल्गोरिदम को टीसीपी पैकेट संरचना में कस्टम फ़ील्ड जोड़ने की आवश्यकता होती है:
Line 369: Line 365:


== लिनक्स उपयोग ==
== लिनक्स उपयोग ==
{{Unreferenced section|date=July 2022}}
* बीआईसी का उपयोग लिनक्स कर्नेल 2.6.8 से 2.6.18 तक डिफ़ॉल्ट रूप से किया जाता है। (अगस्त 2004 - सितम्बर 2006)
* बीआईसी का उपयोग लिनक्स कर्नेल 2.6.8 से 2.6.18 तक डिफ़ॉल्ट रूप से किया जाता है। (अगस्त 2004 - सितम्बर 2006)
* संस्करण 2.6.19 से लिनक्स कर्नेल में डिफ़ॉल्ट रूप से CUBIC का उपयोग किया जाता है। (नवंबर 2006)
* संस्करण 2.6.19 से लिनक्स कर्नेल में डिफ़ॉल्ट रूप से CUBIC का उपयोग किया जाता है। (नवंबर 2006)
Line 382: Line 377:
== टिप्पणियाँ ==
== टिप्पणियाँ ==
{{notelist}}
{{notelist}}


== संदर्भ ==
== संदर्भ ==
Line 393: Line 387:
}}
}}


 
'''स्रोत'''
 
 
=== स्रोत ===
* {{cite book |title=कंप्यूटर नेटवर्किंग: एक ऊपर से नीचे का दृष्टिकोण|last1=Kurose |first1=James |last2=Ross |first2=Keith |author-link=Jim Kurose |year=2008 |edition=4th |publisher=Addison Wesley |isbn=978-0-13-607967-5 }}
* {{cite book |title=कंप्यूटर नेटवर्किंग: एक ऊपर से नीचे का दृष्टिकोण|last1=Kurose |first1=James |last2=Ross |first2=Keith |author-link=Jim Kurose |year=2008 |edition=4th |publisher=Addison Wesley |isbn=978-0-13-607967-5 }}
* {{cite book |title=कंप्यूटर नेटवर्किंग: एक ऊपर से नीचे का दृष्टिकोण|last1=Kurose |first1=James |last2=Ross |first2=Keith |author-link=Jim Kurose |date=2012 |edition=6th |publisher=Pearson |isbn=978-0-13-285620-1}}
* {{cite book |title=कंप्यूटर नेटवर्किंग: एक ऊपर से नीचे का दृष्टिकोण|last1=Kurose |first1=James |last2=Ross |first2=Keith |author-link=Jim Kurose |date=2012 |edition=6th |publisher=Pearson |isbn=978-0-13-285620-1}}

Revision as of 18:35, 5 October 2023


प्रसारण नियंत्रण प्रोटोकॉल (टीसीपी) भीड़ नियंत्रण एल्गोरिदम का उपयोग करता है जिसमें #धीमी शुरुआत सहित अन्य योजनाओं के साथ-साथ एडिटिव वृद्धि/गुणक कमी (एआईएमडी) योजना के विभिन्न पहलू शामिल हैं।[1] और #कंजेशन विंडो (सीडब्ल्यूएनडी), भीड़भाड़ से बचने के लिए। टीसीपी कंजेशन-अवॉइडेंस एल्गोरिदम इंटरनेट में कंजेशन नियंत्रण का प्राथमिक आधार है।[2][3][4] एंड-टू-एंड सिद्धांत के अनुसार, भीड़भाड़ नियंत्रण काफी हद तक [[इंटरनेट होस्ट]] का कार्य है, न कि नेटवर्क का। इंटरनेट से कनेक्ट होने वाले कंप्यूटरों के ऑपरेटिंग सिस्टम के प्रोटोकॉल स्टैक में लागू एल्गोरिदम के कई रूप और संस्करण हैं।

कंजेस्टिव पतन से बचने के लिए, टीसीपी बहुआयामी कंजेशन-नियंत्रण रणनीति का उपयोग करता है। प्रत्येक कनेक्शन के लिए, टीसीपी सीडब्ल्यूएनडी बनाए रखता है, जो पारगमन में एंड-टू-एंड हो सकने वाले अस्वीकृत पैकेटों की कुल संख्या को सीमित करता है। यह कुछ हद तक ट्रांसमिशन कंट्रोल प्रोटोकॉल#फ्लो नियंत्रण के लिए उपयोग की जाने वाली टीसीपी की स्लाइडिंग खिड़की के समान है।

योगात्मक वृद्धि/गुणात्मक कमी

योगात्मक वृद्धि/गुणक कमी (एआईएमडी) एल्गोरिदम नियंत्रण प्रणाली | बंद-लूप नियंत्रण एल्गोरिदम है। एआईएमडी भीड़भाड़ होने पर भीड़भाड़ खिड़की की रैखिक वृद्धि को तेजी से कमी के साथ जोड़ती है। एआईएमडी कंजेशन नियंत्रण का उपयोग करने वाले ाधिक प्रवाह अंततः विवादित लिंक की समान मात्रा का उपयोग करने के लिए त्रित होंगे।[5]

यह वह एल्गोरिदम है जिसका वर्णन किया गया है RFC 5681 भीड़भाड़ से बचाव की स्थिति के लिए।[6]

कंजेशन विंडो

टीसीपी में, कंजेशन विंडो (सीडब्ल्यूएनडी) उन कारकों में से है जो किसी भी समय भेजे जा सकने वाले बाइट्स की संख्या निर्धारित करती है। कंजेशन विंडो को प्रेषक द्वारा बनाए रखा जाता है और यह प्रेषक और प्राप्तकर्ता के बीच लिंक को बहुत अधिक ट्रैफ़िक से ओवरलोड होने से रोकने का साधन है। इसे प्रेषक द्वारा बनाए गए स्लाइडिंग विंडो के साथ भ्रमित नहीं किया जाना चाहिए जो रिसीवर को अतिभारित होने से रोकने के लिए मौजूद है। कंजेशन विंडो की गणना यह अनुमान लगाकर की जाती है कि लिंक पर कितनी भीड़ है।

जब कोई कनेक्शन स्थापित किया जाता है, तो कंजेशन विंडो, प्रत्येक होस्ट पर स्वतंत्र रूप से बनाए रखा गया मान, उस कनेक्शन पर अनुमत अधिकतम सेगमेंट आकार (एमएसएस) के छोटे गुणक पर सेट किया जाता है। कंजेशन विंडो में और अधिक भिन्नता योगात्मक वृद्धि/गुणक कमी (एआईएमडी) दृष्टिकोण द्वारा निर्धारित होती है। इसका मतलब यह है कि यदि सभी खंड प्राप्त हो जाते हैं और पावती प्रेषक तक समय पर पहुंच जाती है, तो विंडो आकार में कुछ स्थिरांक जोड़ दिया जाता है। यह अलग-अलग एल्गोरिदम का पालन करेगा।

सिस्टम प्रशासक टीसीपी ट्यूनिंग के हिस्से के रूप में अधिकतम विंडो आकार सीमा को समायोजित कर सकता है, या एडिटिव वृद्धि के दौरान जोड़े गए स्थिरांक को समायोजित कर सकता है।

टीसीपी कनेक्शन पर डेटा का प्रवाह रिसीवर द्वारा विज्ञापित ट्रांसमिशन कंट्रोल प्रोटोकॉल#फ्लो कंट्रोल के उपयोग से भी नियंत्रित होता है। प्रेषक अपनी स्वयं की कंजेशन विंडो और प्राप्त विंडो से कम डेटा भेज सकता है।

धीमी शुरुआत

धीमी शुरुआत, द्वारा परिभाषित RFC 5681.[7] टीसीपी द्वारा अन्य कलन विधि के साथ मिलकर उपयोग की जाने वाली भीड़ नियंत्रण रणनीति का हिस्सा है ताकि नेटवर्क अग्रेषित करने में सक्षम से अधिक डेटा भेजने से बचा जा सके, यानी नेटवर्क भीड़भाड़ से बचने के लिए।

धीमी शुरुआत प्रारंभ में 1, 2, 4 या 10 एमएसएस के कंजेशन विंडो आकार (सीडब्ल्यूएनडी) के साथ शुरू होती है।[8][3]: 1  प्रत्येक पावती (डेटा नेटवर्क) (एसीके) प्राप्त होने पर कंजेशन विंडो आकार के मूल्य को 1 एमएसएस तक बढ़ाया जा सकता है, जिससे प्रभावी रूप से प्रत्येक राउंड-ट्रिप में देरी से विंडो का आकार दोगुना हो जाता है।[lower-alpha 1]

ट्रांसमिशन दर धीमी-प्रारंभ एल्गोरिथ्म द्वारा तब तक बढ़ाई जाएगी जब तक कि पैकेट हानि का पता नहीं चल जाता है, या रिसीवर की विज्ञापित विंडो (आरडब्ल्यूएनडी) सीमित कारक नहीं है।

या धीमी शुरुआत थ्रेशोल्ड (ssthresh) तक पहुंच गया है, जिसका उपयोग यह निर्धारित करने के लिए किया जाता है कि धीमी शुरुआत या भीड़ से बचाव एल्गोरिदम का उपयोग किया जाता है, जो धीमी शुरुआत को सीमित करने के लिए निर्धारित मान है

यदि CWND ssthresh तक पहुँच जाता है, तो TCP कंजेशन अवॉइडेंस एल्गोरिदम में बदल जाता है। इसे प्रत्येक आरटीटी के लिए 1 एमएसएस तक बढ़ाया जाना चाहिए।

सामान्य सूत्र यह है कि प्रत्येक नया ACK MSS द्वारा CWND बढ़ाता है *MSS / CWND. यह लगभग रैखिक रूप से बढ़ता है और स्वीकार्य सन्निकटन प्रदान करता है।

यदि कोई हानि की घटना होती है, तो टीसीपी मानता है कि यह नेटवर्क की भीड़ के कारण है और नेटवर्क पर प्रस्तावित लोड को कम करने के लिए कदम उठाता है। ये माप उपयोग किए गए सटीक टीसीपी कंजेशन अवॉइडेंस एल्गोरिदम पर निर्भर करते हैं।

जब टीसीपी प्रेषक रीट्रांसमिशन टाइमर का उपयोग करके सेगमेंट हानि का पता लगाता है और दिए गए सेगमेंट को रीट्रांसमिशन टाइमर के माध्यम से अभी तक दोबारा नहीं भेजा गया है, तो ssthresh का मान भेजे गए डेटा की मात्रा के आधे से अधिक पर सेट नहीं किया जाना चाहिए, लेकिन नहीं फिर भी संचयी रूप से स्वीकार किया गया। या 2 * एमएसएस

टीसीपी ताहो
जब कोई हानि होती है, तो पुनः ट्रांसमिट भेजा जाता है, वर्तमान CWND का आधा हिस्सा ssthresh के रूप में सहेजा जाता है और इसके प्रारंभिक CWND से धीमी शुरुआत फिर से शुरू होती है।
टीसीपी रेनो
फास्ट रिट्रांसमिट भेजा जाता है, वर्तमान सीडब्ल्यूएनडी का आधा हिस्सा एसएसथ्रेश और नए सीडब्ल्यूएनडी के रूप में सहेजा जाता है, इस प्रकार धीमी शुरुआत को छोड़ दिया जाता है और सीधे कंजेशन अवॉइडेंस एल्गोरिदम पर चला जाता है। यहां समग्र एल्गोरिदम को 'कहा जाता हैfast recovery.

धीमी शुरुआत यह मानती है कि अस्वीकृत खंड नेटवर्क संकुलन के कारण हैं। हालांकि यह कई नेटवर्कों के लिए स्वीकार्य धारणा है, अन्य कारणों से खंड खो सकते हैं, जैसे खराब सूचना श्रंखला तल ट्रांसमिशन गुणवत्ता। इस प्रकार, वायरलेस लेन जैसी खराब रिसेप्शन वाली स्थितियों में धीमी शुरुआत खराब प्रदर्शन कर सकती है।

धीमी शुरुआत प्रोटोकॉल अल्पकालिक कनेक्शन के लिए भी खराब प्रदर्शन करता है। पुराने वेब ब्राउज़र्स वेब सर्वर के लिए लगातार कई अल्पकालिक कनेक्शन बनाएंगे, और अनुरोधित प्रत्येक फ़ाइल के लिए कनेक्शन खोलेंगे और बंद करेंगे। इसने अधिकांश कनेक्शनों को धीमी शुरुआत मोड में रखा, जिसके परिणामस्वरूप प्रतिक्रिया समय खराब हो गया। इस समस्या से बचने के लिए, आधुनिक ब्राउज़र या तो साथ कई कनेक्शन खोलते हैं या किसी विशेष वेब सर्वर से अनुरोधित सभी फ़ाइलों के लिए HTTP लगातार कनेक्शन खोलते हैं। हालाँकि, विज्ञापन नेटवर्क, सामाजिक नेटवर्किंग सेवा के बटन की तरह को लागू करने के लिए वेब साइटों द्वारा उपयोग किए जाने वाले कई तृतीय-पक्ष सर्वरों के लिए कनेक्शन का पुन: उपयोग नहीं किया जा सकता है।[9] और वेब एनालिटिक्स पेज टैगिंग।

तेजी से पुनः प्रेषण

फास्ट रीट्रांसमिट ट्रांसमिशन कंट्रोल प्रोटोकॉल का संवर्द्धन है जो किसी खोए हुए सेगमेंट को दोबारा ट्रांसमिट करने से पहले प्रेषक के इंतजार के समय को कम कर देता है। टीसीपी प्रेषक आम तौर पर खोए हुए खंडों को पहचानने के लिए साधारण टाइमर का उपयोग करता है। यदि किसी निर्दिष्ट समय (अनुमानित राउंड-ट्रिप में देरी का समय का फ़ंक्शन) के भीतर किसी विशेष खंड के लिए पावती प्राप्त नहीं होती है, तो प्रेषक मान लेगा कि खंड नेटवर्क में खो गया है और खंड को पुनः प्रेषित करेगा।

डुप्लिकेट पावती तेजी से पुन: प्रेषण तंत्र का आधार है। पैकेट प्राप्त करने के बाद प्राप्त डेटा के अंतिम इन-ऑर्डर बाइट के लिए पावती भेजी जाती है। इन-ऑर्डर पैकेट के लिए, यह प्रभावी रूप से अंतिम पैकेट की अनुक्रम संख्या और वर्तमान पैकेट की पेलोड लंबाई है। यदि अनुक्रम में अगला पैकेट खो जाता है लेकिन अनुक्रम में तीसरा पैकेट प्राप्त होता है, तो रिसीवर केवल डेटा के अंतिम इन-ऑर्डर बाइट को स्वीकार कर सकता है, जो कि वही मान है जो पहले पैकेट के लिए स्वीकार किया गया था। दूसरा पैकेट खो गया है और तीसरा पैकेट क्रम में नहीं है, इसलिए डेटा का अंतिम इन-ऑर्डर बाइट पहले जैसा ही रहता है। इस प्रकार डुप्लिकेट पावती होती है। प्रेषक पैकेट भेजना जारी रखता है, और चौथा और पांचवां पैकेट रिसीवर को प्राप्त होता है। फिर, दूसरा पैकेट अनुक्रम से गायब है, इसलिए अंतिम इन-ऑर्डर बाइट नहीं बदला है। इन दोनों पैकेटों के लिए डुप्लिकेट पावती भेजी जाती है।

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

एल्गोरिदम

कंजेशन कंट्रोल एल्गोरिदम (सीसीए) के लिए नामकरण परंपरा की शुरुआत केविन फॉल और सैली फ्लॉयड के 1996 के पेपर में हुई होगी।[10][failed verification]

निम्नलिखित गुणों के अनुसार निम्नलिखित संभावित वर्गीकरण है:

  1. नेटवर्क से प्राप्त फीडबैक का प्रकार और मात्रा
  2. वर्तमान इंटरनेट पर वृद्धिशील तैनाती
  3. प्रदर्शन का वह पहलू जिसे सुधारना है: उच्च बैंडविड्थ-विलंब उत्पाद नेटवर्क (बी); हानिपूर्ण लिंक (एल); निष्पक्षता (एफ); लघु प्रवाह का लाभ (एस); परिवर्तनीय-दर लिंक (वी); अभिसरण की गति (सी)
  4. यह निष्पक्षता मानदंड का उपयोग करता है

कुछ प्रसिद्ध भीड़-भाड़ से बचाव तंत्रों को इस योजना द्वारा निम्नानुसार वर्गीकृत किया गया है:

Variant Feedback Required changes Benefits Fairness
(New) Reno Loss — — Delay
Vegas Delay Sender Less loss Proportional
High Speed Loss Sender High bandwidth
BIC Loss Sender High bandwidth
CUBIC Loss Sender High bandwidth
C2TCP[11][12] Loss/Delay Sender Ultra-low latency and high bandwidth
NATCP[13] Multi-bit signal Sender Near Optimal Performance
Elastic-TCP Loss/Delay Sender High bandwidth/short & long-distance
Agile-TCP Loss Sender High bandwidth/short-distance
H-TCP Loss Sender High bandwidth
FAST Delay Sender High bandwidth Proportional
Compound TCP Loss/Delay Sender High bandwidth Proportional
Westwood Loss/Delay Sender Lossy links
Jersey Loss/Delay Sender Lossy links
BBR[14] Delay Sender BLVC, Bufferbloat
CLAMP Multi-bit signal Receiver, Router Variable-rate links Max-min
TFRC Loss Sender, Receiver No Retransmission Minimum delay
XCP Multi-bit signal Sender, Receiver, Router BLFC Max-min
VCP 2-bit signal Sender, Receiver, Router BLF Proportional
MaxNet Multi-bit signal Sender, Receiver, Router BLFSC Max-min
JetMax Multi-bit signal Sender, Receiver, Router High bandwidth Max-min
RED Loss Router Reduced delay
ECN Single-bit signal Sender, Receiver, Router Reduced loss

टीसीपी ताहो और रेनो

टीसीपी ताहो और रेनो एल्गोरिदम को पूर्वव्यापी रूप से 4.3बीएसडी ऑपरेटिंग सिस्टम के संस्करणों या स्वादों के नाम पर रखा गया था, जिनमें से प्रत्येक पहली बार दिखाई दिया था (जो स्वयं ताहो झील और पास के शहर रेनो, नेवादा के नाम पर थे)। ताहो एल्गोरिथ्म पहली बार 4.3बीएसडी-ताहो में दिखाई दिया (जो कंप्यूटर कंसोल इंक. # पावर 5 और पावर 6 कंप्यूटर | सीसीआई पावर 6/32 ताहो मिनी कंप्यूटर का समर्थन करने के लिए बनाया गया था), और बाद में इसे गैर-एटी एंड टी लाइसेंसधारियों के लिए उपलब्ध कराया गया था। 4.3बीएसडी नेटवर्किंग रिलीज़ 1 का; इससे इसका व्यापक वितरण और कार्यान्वयन सुनिश्चित हुआ। 4.3BSD-रेनो में सुधार किए गए और बाद में इसे नेटवर्किंग रिलीज़ 2 और बाद में 4.4BSD-लाइट के रूप में जनता के लिए जारी किया गया।

जबकि दोनों रीट्रांसमिशन टाइमआउट (आरटीओ) और डुप्लिकेट एसीके को पैकेट हानि की घटनाओं के रूप में मानते हैं, ताहो और रेनो का व्यवहार मुख्य रूप से इस बात में भिन्न होता है कि वे डुप्लिकेट एसीके पर कैसे प्रतिक्रिया करते हैं:

  • ताहो: यदि तीन डुप्लिकेट एसीके प्राप्त होते हैं (अर्थात ही पैकेट को स्वीकार करने वाले चार एसीके, जो डेटा पर पिग्गीबैक नहीं होते हैं और रिसीवर की विज्ञापित विंडो को नहीं बदलते हैं), ताहो तेज़ रिट्रांसमिट करता है, धीमी शुरुआत सीमा को वर्तमान के आधे पर सेट करता है कंजेशन विंडो, कंजेशन विंडो को 1 एमएसएस तक कम कर देता है, और धीमी शुरुआत स्थिति पर रीसेट कर देता है।[15]
  • रेनो: यदि तीन डुप्लिकेट ACK प्राप्त होते हैं, तो रेनो तेजी से पुन: ट्रांसमिट करेगा और कंजेशन विंडो को आधा करके (ताहो की तरह 1 MSS पर सेट करने के बजाय), ssthresh को नई कंजेशन विंडो के बराबर सेट करके धीमी शुरुआत चरण को छोड़ देगा। और तेज़ पुनर्प्राप्ति नामक चरण में प्रवेश करें।[16]

ताहो और रेनो दोनों में, यदि एसीके टाइम आउट (आरटीओ टाइमआउट) होता है, तो धीमी शुरुआत का उपयोग किया जाता है, और दोनों एल्गोरिदम कंजेशन विंडो को 1 एमएसएस तक कम कर देते हैं।

टीसीपी न्यू रेनो

टीसीपी न्यू रेनो, द्वारा परिभाषित RFC 6582 (जो पिछली परिभाषाओं को अप्रचलित करता है RFC 3782 और RFC 2582), टीसीपी रेनो के तेजी से पुनर्प्राप्ति चरण के दौरान पुनः प्रसारण में सुधार करता है।

तेजी से पुनर्प्राप्ति के दौरान, ट्रांसमिट विंडो को भरा रखने के लिए, लौटाए जाने वाले प्रत्येक डुप्लिकेट ACK के लिए, कंजेशन विंडो के अंत से नया असंतुलित पैकेट भेजा जाता है।

रेनो से अंतर यह है कि नई रेनो ssthresh को तुरंत आधा नहीं करती है, जिससे ाधिक पैकेट हानि होने पर विंडो बहुत कम हो सकती है। यह तेजी से पुनर्प्राप्ति से बाहर नहीं निकलता है और ssthresh को रीसेट नहीं करता है जब तक कि यह सभी डेटा को स्वीकार नहीं करता है।

पुनः प्रसारण के बाद, नए स्वीकृत डेटा के दो मामले हैं:

  • पूर्ण स्वीकृतियाँ: ACK भेजे गए सभी मध्यवर्ती खंडों को स्वीकार करता है, ssthresh को बदला नहीं जा सकता है, cwnd को ssthresh पर सेट किया जा सकता है
  • आंशिक स्वीकृतियाँ: ACK सभी डेटा को स्वीकार नहीं करता है। इसका मतलब है कि और हानि हो सकती है, यदि अनुमति हो तो पहले अज्ञात खंड को दोबारा प्रसारित करें

यह रिकॉर्ड करने के लिए पुनर्प्राप्ति नामक चर का उपयोग करता है कि कितना डेटा पुनर्प्राप्त करने की आवश्यकता है। रीट्रांसमिट टाइमआउट के बाद, यह पुनर्प्राप्ति चर में प्रेषित उच्चतम अनुक्रम संख्या को रिकॉर्ड करता है और तेजी से पुनर्प्राप्ति प्रक्रिया से बाहर निकलता है। यदि इस अनुक्रम संख्या को स्वीकार किया जाता है, तो टीसीपी भीड़भाड़ से बचाव की स्थिति में वापस आ जाती है।

न्यू रेनो के साथ समस्या तब उत्पन्न होती है जब कोई पैकेट हानि नहीं होती है, बल्कि पैकेट को 3 से अधिक पैकेट अनुक्रम संख्याओं द्वारा पुन: व्यवस्थित किया जाता है। इस मामले में, नई रेनो गलती से तेजी से रिकवरी में प्रवेश करती है। जब पुन: ऑर्डर किया गया पैकेट वितरित किया जाता है, तो डुप्लिकेट और अनावश्यक पुन: प्रसारण तुरंत भेज दिए जाते हैं।

नई रेनो कम पैकेट त्रुटि दर पर SACK के समान ही प्रदर्शन करती है और उच्च त्रुटि दर पर रेनो से काफी बेहतर प्रदर्शन करती है।[17]

टीसीपी वेगास

Main article: TCP Vegas

1990 के दशक के मध्य तक, टीसीपी के सभी निर्धारित टाइमआउट और मापी गई राउंड-ट्रिप देरी केवल ट्रांसमिट बफर में अंतिम प्रेषित पैकेट पर आधारित थी। एरिज़ोना विश्वविद्यालय के शोधकर्ता लैरी पीटरसन और लॉरेंस ब्रैक्मो ने टीसीपी वेगास की शुरुआत की जिसमें टाइमआउट सेट किए गए थे और ट्रांसमिट बफर में प्रत्येक पैकेट के लिए राउंड-ट्रिप देरी को मापा गया था। इसके अलावा, टीसीपी वेगास कंजेशन विंडो में एडिटिव बढ़ोतरी का उपयोग करता है। विभिन्न टीसीपी के तुलनात्मक अध्ययन में CCAएस, टीसीपी क्यूबिक के बाद टीसीपी वेगास सबसे सहज दिखाई दिया।[18] टीसीपी वेगास को पीटरसन की प्रयोगशाला के बाहर व्यापक रूप से तैनात नहीं किया गया था, लेकिन डीडी-WRT फर्मवेयर v24 SP2 के लिए डिफ़ॉल्ट भीड़ नियंत्रण विधि के रूप में चुना गया था।[19]

टीसीपी हाइब्ला

टीसीपी हाइब्ला[20][21] इसका उद्देश्य उच्च-विलंबता स्थलीय या उपग्रह रेडियो लिंक का उपयोग करने वाले टीसीपी कनेक्शनों पर दंड को समाप्त करना है। हाइब्ला सुधार कंजेशन विंडो गतिशीलता के विश्लेषणात्मक मूल्यांकन पर आधारित हैं।[22]

टीसीपी बीआईसी

Main article: BIC TCP

बाइनरी इनक्रीस कंजेशन कंट्रोल (बीआईसी) उच्च विलंबता वाले हाई-स्पीड नेटवर्क के लिए अनुकूलित सीसीए के साथ टीसीपी कार्यान्वयन है, जिसे लंबे वसा नेटवर्क (एलएफएन) के रूप में जाना जाता है।[23] लिनक्स कर्नेल 2.6.8 से 2.6.18 तक डिफ़ॉल्ट रूप से बीआईसी का उपयोग किया जाता है।[citation needed]

टीसीपी घन

Main article: CUBIC TCP

CUBIC, BIC का कम आक्रामक और अधिक व्यवस्थित व्युत्पन्न है, जिसमें विंडो अंतिम कंजेशन इवेंट के बाद से समय का क्यूबिक फ़ंक्शन है, जिसमें इवेंट से पहले विंडो पर विभक्ति बिंदु सेट होता है। संस्करण 2.6.19 से लिनक्स कर्नेल में डिफ़ॉल्ट रूप से CUBIC का उपयोग किया जाता है।

एजाइल-एसडी टीसीपी

एजाइल-एसडी लिनक्स-आधारित सीसीए है जिसे वास्तविक लिनक्स कर्नेल के लिए डिज़ाइन किया गया है। यह रिसीवर-साइड एल्गोरिदम है जो चपलता कारक (एएफ) नामक उपन्यास तंत्र का उपयोग करके हानि-आधारित दृष्टिकोण को नियोजित करता है। उच्च गति और कम दूरी के नेटवर्क (कम-बीडीपी नेटवर्क) जैसे स्थानीय क्षेत्र नेटवर्क या फाइबर-ऑप्टिक नेटवर्क पर बैंडविड्थ उपयोग को बढ़ाने के लिए, खासकर जब लागू बफर आकार छोटा होता है।[24]NS-2 सिम्युलेटर का उपयोग करके इसके प्रदर्शन की तुलना कंपाउंड टीसीपी (एमएस विंडोज में डिफ़ॉल्ट सीसीए) और क्यूबिक (लिनक्स का डिफ़ॉल्ट) से करके इसका मूल्यांकन किया गया है। यह औसत थ्रूपुट की अवधि में कुल प्रदर्शन को 55% तक सुधारता है।

टीसीपी वेस्टवुड+

Main article: TCP Westwood plus

वेस्टवुड+ टीसीपी रेनो का केवल-प्रेषक संशोधन है जो वायर्ड और बेतार तंत्र दोनों पर टीसीपी कंजेशन नियंत्रण के प्रदर्शन को अनुकूलित करता है। टीसीपी वेस्टवुड+ कंजेशन एपिसोड के बाद, यानी तीन डुप्लिकेट पावती या टाइमआउट के बाद कंजेशन विंडो और धीमी शुरुआत सीमा निर्धारित करने के लिए एंड-टू-एंड बैंडविड्थ (कंप्यूटिंग) अनुमान पर आधारित है। पावती पैकेट लौटाने की दर के औसत से बैंडविड्थ का अनुमान लगाया जाता है। टीसीपी रेनो के विपरीत, जो तीन डुप्लिकेट एसीके के बाद कंजेशन विंडो को आँख बंद करके आधा कर देता है, टीसीपी वेस्टवुड+ अनुकूल रूप से धीमी शुरुआत सीमा और कंजेशन विंडो सेट करता है जो कंजेशन के अनुभव के समय उपलब्ध बैंडविड्थ के अनुमान को ध्यान में रखता है। रेनो और न्यू रेनो की तुलना में, वेस्टवुड+ वायरलेस लिंक पर थ्रूपुट को महत्वपूर्ण रूप से बढ़ाता है और वायर्ड नेटवर्क में निष्पक्षता में सुधार करता है।

कंपाउंड टीसीपी

Main article: Compound TCP

कंपाउंड टीसीपी, टीसीपी का माइक्रोसॉफ्ट कार्यान्वयन है जो निष्पक्षता माप को ख़राब किए बिना एलएफएन पर अच्छा प्रदर्शन प्राप्त करने के लक्ष्य के साथ, दो अलग-अलग कंजेशन विंडो को साथ बनाए रखता है। इसे Microsoft Windows Vista और Windows Server 2008 के बाद से Windows संस्करणों में व्यापक रूप से तैनात किया गया है और इसे पुराने Microsoft Windows संस्करणों के साथ-साथ Linux में भी पोर्ट किया गया है।

टीसीपी आनुपातिक दर में कमी

टीसीपी आनुपातिक दर में कमी (पीआरआर)[25] पुनर्प्राप्ति के दौरान भेजे गए डेटा की सटीकता में सुधार करने के लिए डिज़ाइन किया गया एल्गोरिदम है। एल्गोरिदम यह सुनिश्चित करता है कि पुनर्प्राप्ति के बाद विंडो का आकार धीमी शुरुआत सीमा के जितना संभव हो उतना करीब हो। Google द्वारा किए गए परीक्षणों में, PRR के परिणामस्वरूप औसत विलंबता में 3-10% की कमी आई और पुनर्प्राप्ति समयबाह्य में 5% की कमी आई।[26] पीआरआर संस्करण 3.2 से लिनक्स कर्नेल में उपलब्ध है।[27]

टीसीपी बीबीआर

बॉटलनेक बैंडविड्थ और राउंड-ट्रिप प्रसार समय (बीबीआर) 2016 में Google द्वारा विकसित CCA है।[28] जबकि अधिकांश सीसीए हानि-आधारित हैं, इसमें वे भीड़भाड़ और ट्रांसमिशन की कम दरों का पता लगाने के लिए पैकेट हानि पर भरोसा करते हैं, बीबीआर, टीसीपी वेगास की तरह, मॉडल-आधारित है। एल्गोरिदम अधिकतम बैंडविड्थ और राउंड-ट्रिप समय का उपयोग करता है जिस पर नेटवर्क ने नेटवर्क का मॉडल बनाने के लिए आउटबाउंड डेटा पैकेट की सबसे हालिया उड़ान वितरित की। पैकेट डिलीवरी की प्रत्येक संचयी या चयनात्मक पावती दर नमूना उत्पन्न करती है जो डेटा पैकेट के प्रसारण और उस पैकेट की पावती के बीच समय अंतराल पर वितरित डेटा की मात्रा को रिकॉर्ड करती है।[29] जब YouTube पर लागू किया गया, तो BBRv1 ने औसतन 4% अधिक नेटवर्क थ्रूपुट और कुछ देशों में 14% तक का उत्पादन किया।[30] लिनक्स 4.9 से बीबीआर लिनक्स टीसीपी के लिए उपलब्ध है।[31] यह QUIC के लिए भी उपलब्ध है।[32] बीबीआर संस्करण 1 (बीबीआरवी1) की गैर-बीबीआर धाराओं के प्रति निष्पक्षता विवादित है। जबकि Google की प्रस्तुति BBRv1 को CUBIC के साथ अच्छी तरह से सह-अस्तित्व में दिखाती है,[28]ज्योफ हस्टन और हॉक, ब्लेस और ज़िटरबार्ट जैसे शोधकर्ताओं ने इसे अन्य धाराओं के लिए अनुचित और स्केलेबल नहीं पाया।[33] हॉक एट अल. लिनक्स 4.9 के बीबीआर कार्यान्वयन में कतार में बढ़ती देरी, अनुचितता और बड़े पैमाने पर पैकेट हानि जैसे कुछ गंभीर अंतर्निहित मुद्दे भी पाए गए।[34] सोहेल अब्बासलू एट अल। (C2TCP के लेखक) बताते हैं कि BBRv1 सेलुलर नेटवर्क जैसे गतिशील वातावरण में अच्छा प्रदर्शन नहीं करता है।[11][12]उन्होंने यह भी दिखाया है कि बीबीआर में अनुचितता का मुद्दा है। उदाहरण के लिए, जब CUBIC TCP प्रवाह (जो Linux, Android और MacOS में डिफ़ॉल्ट ट्रांसमिशन कंट्रोल प्रोटोकॉल कार्यान्वयन है) नेटवर्क में BBR प्रवाह के साथ सह-अस्तित्व में होता है, तो BBR प्रवाह CUBIC प्रवाह पर हावी हो सकता है और इससे संपूर्ण लिंक बैंडविड्थ प्राप्त कर सकता है। (चित्र 16 देखें [11]).

संस्करण 2 CUBIC जैसे हानि-आधारित भीड़ प्रबंधन के साथ संचालन करते समय अनुचितता के मुद्दे से निपटने का प्रयास करता है।[35] BBRv2 में BBRv1 द्वारा उपयोग किए गए मॉडल को पैकेट हानि के बारे में जानकारी और स्पष्ट भीड़ अधिसूचना (ECN) से जानकारी शामिल करने के लिए संवर्धित किया गया है।[36] हालाँकि BBRv2 में कई बार BBRv1 की तुलना में कम थ्रूपुट हो सकता है, लेकिन आमतौर पर इसे बेहतर गुडपुट माना जाता है।

संस्करण 3 (बीबीआरवी3) बीबीआरवी2 में दो बग को ठीक करता है (बैंडविड्थ जांच का समय से पहले समाप्त होना, बैंडविड्थ अभिसरण) और कुछ प्रदर्शन ट्यूनिंग करता है। वैरिएंट भी है, जिसे BBR.Swift कहा जाता है, जो डेटासेंटर-आंतरिक लिंक के लिए अनुकूलित है: यह मुख्य भीड़ नियंत्रण सिग्नल के रूप में नेटवर्क_आरटीटी (रिसीवर देरी को छोड़कर) का उपयोग करता है।[36]

C2TCP

सेलुलर नियंत्रित विलंब टीसीपी (C2TCP)[11][12] लचीले एंड-टू-एंड टीसीपी दृष्टिकोण की कमी से प्रेरित था जो नेटवर्क उपकरणों में किसी भी बदलाव की आवश्यकता के बिना विभिन्न अनुप्रयोगों के लिए सेवा की विभिन्न गुणवत्ता आवश्यकताओं को पूरा कर सकता है। C2TCP का लक्ष्य वर्तमान LTE (दूरसंचार) और भविष्य के 5G जैसे अत्यधिक गतिशील वातावरण में आभासी वास्तविकता , वीडियो कॉन्फ्रेंसिंग, ऑनलाइन गेम, वाहन संचार प्रणाली आदि जैसे अनुप्रयोगों की अल्ट्रा-लो विलंबता (इंजीनियरिंग) और उच्च-बैंडविड्थ आवश्यकताओं को पूरा करना है। सेल्युलर नेटवर्क C2TCP हानि-आधारित टीसीपी (जैसे रेनो, न्यूरेनो, क्यूबिक टीसीपी, बीआईसी टीसीपी, ...) के शीर्ष पर प्लग-इन (कंप्यूटिंग) | ऐड-ऑन के रूप में काम करता है, इसे केवल सर्वर-साइड पर स्थापित करना आवश्यक है और पैकेटों के औसत विलंब को अनुप्रयोगों द्वारा निर्धारित वांछित विलंबों तक सीमित कर देता है।

न्यूयॉर्क विश्वविद्यालय के शोधकर्ता[37] दिखाया गया कि C2TCP विभिन्न अत्याधुनिक टीसीपी योजनाओं के विलंब और विलंब-भिन्नता प्रदर्शन से बेहतर प्रदर्शन करता है। उदाहरण के लिए, उन्होंने दिखाया कि BBR, CUBIC और वेस्टवुड की तुलना में, C2TCP विभिन्न सेलुलर नेटवर्क वातावरणों पर पैकेट की औसत देरी को क्रमशः 250%, 900% और 700% कम कर देता है।[11]

इलास्टिक-टीसीपी

क्लाउड कंप्यूटिंग के समर्थन में उच्च-बीडीपी नेटवर्क पर बैंडविड्थ उपयोग को बढ़ाने के लिए फरवरी 2019 में इलास्टिक-टीसीपी का प्रस्ताव दिया गया था। यह Linux-आधारित CCA है जिसे Linux कर्नेल के लिए डिज़ाइन किया गया है। यह रिसीवर-साइड एल्गोरिदम है जो विंडो-सहसंबंधित वेटिंग फ़ंक्शन (डब्ल्यूडब्ल्यूएफ) नामक उपन्यास तंत्र का उपयोग करके हानि-विलंब-आधारित दृष्टिकोण को नियोजित करता है। इसमें मानव ट्यूनिंग की आवश्यकता के बिना विभिन्न नेटवर्क विशेषताओं से निपटने के लिए उच्च स्तर की लोच है। एनएस-2 सिम्युलेटर और टेस्टबेड का उपयोग करके इसके प्रदर्शन की तुलना कंपाउंड टीसीपी (एमएस विंडोज में डिफ़ॉल्ट सीसीए), क्यूबिक (लिनक्स के लिए डिफ़ॉल्ट) और टीसीपी-बीबीआर (Google द्वारा उपयोग किए जाने वाले लिनक्स 4.9 का डिफ़ॉल्ट) से तुलना करके की गई है। इलास्टिक-टीसीपी औसत थ्रूपुट, हानि अनुपात और देरी के मामले में कुल प्रदर्शन में उल्लेखनीय सुधार करता है।[38]

एनएटीसीपी

सोहेल अब्बासलू एट अल। प्रस्तावित NATCP (नेटवर्क-असिस्टेड टीसीपी)[13] ए controversial[according to whom?] टीसीपी डिज़ाइन मल्टी-्सेस एज कंप्यूटिंग (एमईसी) को लक्षित करता है। NATCP का मुख्य विचार यह है कि यदि नेटवर्क की विशेषताओं के बारे में पहले से पता होता, तो TCP को अलग तरह से डिज़ाइन किया गया होता। इसलिए, NATCP टीसीपी के प्रदर्शन को इष्टतम प्रदर्शन के करीब पहुंचाने के लिए वर्तमान एमईसी-आधारित सेलुलर आर्किटेक्चर में उपलब्ध सुविधाओं और गुणों को नियोजित करता है। NATCP नेटवर्क से पास में स्थित सर्वर पर आउट-ऑफ-बैंड फीडबैक का उपयोग करता है। नेटवर्क से फीडबैक, जिसमें सेलुलर ्सेस लिंक की क्षमता और नेटवर्क का न्यूनतम आरटीटी शामिल है, सर्वर को उनकी भेजने की दरों को समायोजित करने के लिए मार्गदर्शन करता है। जैसा कि प्रारंभिक परिणाम दिखाते हैं, NATCP अत्याधुनिक टीसीपी योजनाओं से बेहतर प्रदर्शन करता है।[13][39]

अन्य टीसीपी भीड़ से बचाव एल्गोरिदम

  1. टीसीपी न्यू रेनो सबसे आम तौर पर लागू किया जाने वाला एल्गोरिदम था, सैक समर्थन बहुत आम है और रेनो/न्यू रेनो का विस्तार है। अधिकांश अन्य प्रतिस्पर्धी प्रस्ताव हैं जिन्हें अभी भी मूल्यांकन की आवश्यकता है। 2.6.8 से शुरू होकर लिनक्स कर्नेल ने डिफ़ॉल्ट कार्यान्वयन को न्यू रेनो से बीआईसी टीसीपी में बदल दिया। 2.6.19 संस्करण में डिफ़ॉल्ट कार्यान्वयन को फिर से CUBIC में बदल दिया गया। फ्रीबीएसडी न्यू रेनो को डिफ़ॉल्ट एल्गोरिदम के रूप में उपयोग करता है। हालाँकि, यह कई अन्य विकल्पों का समर्थन करता है।[51]

जब कतार योजना की परवाह किए बिना बैंडविड्थ और विलंबता का प्रति-प्रवाह उत्पाद बढ़ता है, तो टीसीपी अक्षम हो जाता है और अस्थिरता का खतरा होता है। यह और भी महत्वपूर्ण हो जाता है क्योंकि इंटरनेट बहुत उच्च-बैंडविड्थ ऑप्टिकल लिंक को शामिल करने के लिए विकसित हो रहा है।

टीसीपी इंटरैक्टिव (आईटीसीपी)[52] एप्लिकेशन को टीसीपी ईवेंट की सदस्यता लेने और तदनुसार प्रतिक्रिया देने की अनुमति देता है, जिससे टीसीपी परत के बाहर से टीसीपी में विभिन्न कार्यात्मक ्सटेंशन सक्षम होते हैं। अधिकांश टीसीपी कंजेशन योजनाएं आंतरिक रूप से काम करती हैं। आईटीसीपी अतिरिक्त रूप से उन्नत अनुप्रयोगों को सीधे भीड़ नियंत्रण में भाग लेने में सक्षम बनाता है जैसे कि स्रोत उत्पादन दर को नियंत्रित करना।

ज़ेटा-टीसीपी विलंबता और हानि दर दोनों उपायों से भीड़ का पता लगाता है। गुडपुट ज़ेटा-टीसीपी को अधिकतम करने के लिए और भीड़भाड़ की संभावना के आधार पर अलग-अलग कंजेशन विंडो बैकऑफ़ रणनीतियों को लागू करता है। इसमें पैकेट के नुकसान का सटीक पता लगाने के लिए अन्य सुधार भी हैं, जिससे रिट्रांसमिशन टाइमआउट रिट्रांसमिशन से बचा जा सके; और इनबाउंड (डाउनलोड) ट्रैफ़िक को तेज़ और नियंत्रित करें।[53]

नेटवर्क जागरूकता द्वारा वर्गीकरण

सीसीए को नेटवर्क जागरूकता के संबंध में वर्गीकृत किया जा सकता है, जिसका अर्थ है कि ये एल्गोरिदम नेटवर्क की स्थिति के बारे में किस हद तक जागरूक हैं। इसमें तीन प्राथमिक श्रेणियां शामिल हैं: ब्लैक बॉक्स, ग्रे बॉक्स और ग्रीन बॉक्स।[54] ब्लैक बॉक्स एल्गोरिदम भीड़ नियंत्रण के अंधी तरीकों की पेशकश करते हैं। वे केवल कंजेशन पर प्राप्त बाइनरी फीडबैक पर काम करते हैं और जिस नेटवर्क को वे प्रबंधित करते हैं उसकी स्थिति के बारे में कोई जानकारी नहीं रखते हैं।

ग्रे बॉक्स एल्गोरिदम का उपयोग करें time-instances[clarification needed] बैंडविड्थ, प्रवाह विवाद और नेटवर्क स्थितियों के अन्य ज्ञान के माप और अनुमान प्राप्त करने के लिए।

ग्रीन बॉक्स एल्गोरिदम भीड़ नियंत्रण के द्विमोडल तरीकों की पेशकश करते हैं जो कुल बैंडविड्थ के उचित हिस्से को मापते हैं जिसे सिस्टम के निष्पादन के दौरान किसी भी बिंदु पर प्रत्येक प्रवाह के लिए आवंटित किया जाना चाहिए।

ब्लैक बॉक्स

  • हाईस्पीड-टीसीपी[55]
  • बीआईसी टीसीपी (बाइनरी इनक्रीस कंजेशन कंट्रोल प्रोटोकॉल) प्रत्येक कंजेशन इवेंट के बाद स्रोत दर में अवतल वृद्धि का उपयोग करता है जब तक कि विंडो इवेंट से पहले विंडो के बराबर न हो जाए, ताकि नेटवर्क के पूरी तरह से उपयोग किए जाने वाले समय को अधिकतम किया जा सके। इसके बाद वह आक्रामक तरीके से जांच करती है.
  • क्यूबिक टीसीपी - बीआईसी का कम आक्रामक और अधिक व्यवस्थित व्युत्पन्न, जिसमें विंडो अंतिम कंजेशन इवेंट के बाद से समय का क्यूबिक फ़ंक्शन है, जिसमें इवेंट से पहले विंडो पर विभक्ति बिंदु सेट होता है।
  • एआईएमडी-एफसी (तेजी से अभिसरण के साथ योगात्मक वृद्धि गुणात्मक कमी), एआईएमडी का सुधार।[56]
  • द्विपद तंत्र
  • SIMD प्रोटोकॉल
  • GAIMD

ग्रे बॉक्स

  • टीसीपी वेगास - कतार में देरी का अनुमान लगाता है, और विंडो को रैखिक रूप से बढ़ाता या घटाता है ताकि नेटवर्क में प्रति प्रवाह पैकेट की स्थिर संख्या कतार में रहे। वेगास आनुपातिक निष्पक्षता लागू करता है।
  • फास्ट टीसीपी - वेगास के समान संतुलन प्राप्त करता है, लेकिन रैखिक वृद्धि के बजाय आनुपातिक नियंत्रण का उपयोग करता है, और स्थिरता सुनिश्चित करने के उद्देश्य से बैंडविड्थ बढ़ने पर जानबूझकर लाभ को कम कर देता है।
  • टीसीपी बीबीआर - कतार में देरी का अनुमान लगाता है लेकिन तेजी से वृद्धि का उपयोग करता है। निष्पक्षता और विलंब को कम करने के लिए जानबूझकर समय-समय पर इसे धीमा किया जाता है।
  • टीसीपी-वेस्टवुड (टीसीपीडब्ल्यू) - नुकसान के कारण विंडो बैंडविड्थ-विलंब उत्पाद के प्रेषक के अनुमान पर रीसेट हो जाती है (एसीके प्राप्त करने की देखी गई दर से गुणा किया गया सबसे छोटा आरटीटी)।[57]
  • सी2टीसीपी[12][11]* टीसीपी अनुकूल दर नियंत्रण[58]
  • टीसीपी-रियल
  • टीसीपी-जर्सी

हरा डिब्बा

  • बिमोडल तंत्र - बिमोडल कंजेशन बचाव और नियंत्रण तंत्र।
  • राउटर्स द्वारा कार्यान्वित सिग्नलिंग विधियाँ
    • रैंडम अर्ली डिटेक्शन (RED) राउटर की कतार के आकार के अनुपात में पैकेट को बेतरतीब ढंग से गिराता है, जिससे कुछ प्रवाह में गुणक कमी आती है।
    • स्पष्ट भीड़ अधिसूचना (ईसीएन)
  • नेटवर्क-सहायता प्राप्त भीड़ नियंत्रण
    • एनएटीसीपी[13] - नेटवर्क-असिस्टेड टीसीपी नेटवर्क के न्यूनतम आरटीटी और सेल्युलर ्सेस लिंक की क्षमता को इंगित करने वाले आउट-ऑफ-बैंड स्पष्ट फीडबैक का उपयोग करता है।
    • वैरिएबल-स्ट्रक्चर कंजेशन कंट्रोल प्रोटोकॉल (वीसीपी) कंजेशन की नेटवर्क स्थिति पर स्पष्ट रूप से प्रतिक्रिया देने के लिए दो ईसीएन बिट्स का उपयोग करता है। इसमें एंड होस्ट साइड एल्गोरिदम भी शामिल है।

निम्नलिखित एल्गोरिदम को टीसीपी पैकेट संरचना में कस्टम फ़ील्ड जोड़ने की आवश्यकता होती है:

  • स्पष्ट नियंत्रण प्रोटोकॉल (्ससीपी) - ्ससीपी पैकेट में फीडबैक फ़ील्ड के साथ कंजेशन हेडर होता है, जो प्रेषक की कंजेशन विंडो में वृद्धि या कमी का संकेत देता है। XCP राउटर दक्षता और निष्पक्षता के लिए फीडबैक मान को स्पष्ट रूप से निर्धारित करते हैं।[59]
  • मैक्सनेट - ल हेडर फ़ील्ड का उपयोग करता है, जो प्रवाह के पथ पर किसी भी राउटर के अधिकतम भीड़ स्तर को वहन करता है। दर इस अधिकतम भीड़ के फ़ंक्शन के रूप में निर्धारित की जाती है, जिसके परिणामस्वरूप अधिकतम-न्यूनतम निष्पक्षता होती है।[60]
  • जेटमैक्स, मैक्सनेट की तरह, केवल अधिकतम कंजेशन सिग्नल पर प्रतिक्रिया करता है, लेकिन अन्य ओवरहेड फ़ील्ड भी वहन करता है।

लिनक्स उपयोग

  • बीआईसी का उपयोग लिनक्स कर्नेल 2.6.8 से 2.6.18 तक डिफ़ॉल्ट रूप से किया जाता है। (अगस्त 2004 - सितम्बर 2006)
  • संस्करण 2.6.19 से लिनक्स कर्नेल में डिफ़ॉल्ट रूप से CUBIC का उपयोग किया जाता है। (नवंबर 2006)
  • पीआरआर को संस्करण 3.2 के बाद से हानि पुनर्प्राप्ति में सुधार के लिए लिनक्स कर्नेल में शामिल किया गया है। (जनवरी 2012)
  • BBRv1 को संस्करण 4.9 के बाद से मॉडल-आधारित कंजेशन नियंत्रण को सक्षम करने के लिए लिनक्स कर्नेल में शामिल किया गया है। (दिसंबर 2016)

यह भी देखें

टिप्पणियाँ

  1. ↑ Even if, actually, the receiver may delay its ACKs, typically sending one ACK for every two segments that it receives[2]

संदर्भ

  1. ↑ Jacobson & Karels 1988.
  2. ↑ 2.0 2.1 W. Stevens (January 1997). TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms. doi:10.17487/RFC2001. RFC 2001.
  3. ↑ 3.0 3.1 M. Allman; S. Floyd; C. Partridge (October 2002). टीसीपी की आरंभिक विंडो बढ़ाना. doi:10.17487/RFC3390. RFC 3390.
  4. ↑ "टीसीपी कंजेशन से बचाव को एक अनुक्रम आरेख के माध्यम से समझाया गया" (PDF). eventhelix.com.
  5. ↑ Chiu, Dah-Ming; Raj Jain (1989). "Analysis of increase and decrease algorithms for congestion avoidance in computer networks". Computer Networks and ISDN Systems. 17: 1–14. CiteSeerX 10.1.1.136.8108. doi:10.1016/0169-7552(89)90019-6.
  6. ↑ Allman, M.; Paxson, V. (September 2009). टीसीपी कंजेशन नियंत्रण. IETF. sec. 3.1. doi:10.17487/RFC5681. RFC 5681. Retrieved March 4, 2021.
  7. ↑ Blanton, Ethan; Paxson, Vern; Allman, Mark (September 2009). "टीसीपी कंजेशन नियंत्रण". IETF.
  8. ↑ Corbet, Jonathan. "टीसीपी प्रारंभिक कंजेशन विंडो को बढ़ाना". LWN. Retrieved 10 October 2012.
  9. ↑ Nick O'Neill. "What's Making Your Site Go Slow? Could Be The Like Button". AllFacebook, 10 November 2010. Retrieved on 12 September 2012.
  10. ↑ Fall, Kevin; Sally Floyd (July 1996). "ताहो, रेनो और सैक टीसीपी की सिमुलेशन-आधारित तुलना" (PDF). Computer Communications Review. 26 (3): 5–21. CiteSeerX 10.1.1.586.2403. doi:10.1145/235160.235162. S2CID 7459148.
  11. ↑ 11.0 11.1 11.2 11.3 11.4 11.5 Abbasloo, S.; Xu, Y.; Chao, H. J. (2019). "C2TCP: A Flexible Cellular TCP to Meet Stringent Delay Requirements". IEEE Journal on Selected Areas in Communications. 37 (4): 918–932. arXiv:1810.13241. doi:10.1109/JSAC.2019.2898758. ISSN 0733-8716. S2CID 53107038.
  12. ↑ 12.0 12.1 12.2 12.3 Abbasloo, S.; Li, T.; Xu, Y.; Chao, H. J. (May 2018). "Cellular Controlled Delay TCP (C2TCP)". 2018 IFIP Networking Conference and Workshops: 118–126. arXiv:1807.02689. Bibcode:2018arXiv180702689A. doi:10.23919/IFIPNetworking.2018.8696844. ISBN 978-3-903176-08-9. S2CID 49650788.
  13. ↑ 13.0 13.1 13.2 13.3 Abbasloo et al. 2019.
  14. ↑ Cardwell, Neal; Cheng, Yuchung; Gunn, C. Stephen; Yeganeh, Soheil Hassas; Jacobson, Van (2016). "BBR: Congestion-Based Congestion Control". Queue. 14 (5): 20–53. doi:10.1145/3012426.3022184.
  15. ↑ Kurose & Ross 2008, p. 284.
  16. ↑ Kurose & Ross 2012, p. 277.
  17. ↑ VasanthiN., V.; SinghM., Ajith; Kumar, Romen; Hemalatha, M. (2011). Das, Vinu V; Thankachan, Nessy (eds.). "Evaluation of Protocols and Algorithms for Improving the Performance of TCP over Wireless/Wired Network". International Conference on Computational Intelligence and Information Technology. Communications in Computer and Information Science. Springer. 250: 693–697. doi:10.1007/978-3-642-25734-6_120. ISBN 978-3-642-25733-9.
  18. ↑ "टीसीपी कंजेशन नियंत्रण एल्गोरिदम का प्रदर्शन विश्लेषण" (PDF). Retrieved 26 March 2012.
  19. ↑ "डीडी-डब्ल्यूआरटी चेंजलॉग". Retrieved 2 January 2012.
  20. ↑ "हाइब्ला होम पेज". Archived from the original on 11 October 2007. Retrieved 4 March 2007.
  21. ↑ Caini, Carlo; Firrincieli, Rosario (2004). "TCP Hybla: a TCP enhancement for heterogeneous networks". International Journal of Satellite Communications and Networking (in English). 22 (5): 547–566. doi:10.1002/sat.799. ISSN 1542-0973. S2CID 2360535.
  22. ↑ Caini, C.; Firrincieli, R.; Lacamera, D. (2009). "Comparative Performance Evaluation of TCP Variants on Satellite Environments". 2009 IEEE International Conference on Communications. pp. 1–5. doi:10.1109/ICC.2009.5198834. S2CID 8352762.
  23. ↑ V., Jacobson; R.T., Braden. लंबी-विलंबित पथों के लिए टीसीपी एक्सटेंशन. doi:10.17487/RFC1072. RFC 1072.
  24. ↑ Alrshah, M.A.; Othman, M.; Ali, B.; Hanapi, Z.M. (September 2015). "Agile-SD: A Linux-based TCP congestion control algorithm for supporting high-speed and short-distance networks". Journal of Network and Computer Applications. 55: 181–190. doi:10.1016/j.jnca.2015.05.011. S2CID 2645016.
  25. ↑ Mathis, M.; Dukkipati, N.; Cheng, Y. (2013). टीसीपी के लिए आनुपातिक दर में कमी. doi:10.17487/RFC6937. RFC 6937.
  26. ↑ Corbet, Jonathan. "LPC: Making the net go faster". Retrieved 6 June 2014.
  27. ↑ "Linux 3.2 - Linux Kernel Newbies". Retrieved 6 June 2014.
  28. ↑ 28.0 28.1 "BBR: Congestion-Based Congestion Control". Retrieved 25 August 2017.
  29. ↑ Cheng, Yuchung; Cardwell, Neal; Yeganeh, Soheil Hassas; Jacobson, Van. "डिलिवरी दर अनुमान". IETF. Retrieved 25 August 2017.
  30. ↑ "TCP BBR congestion control comes to GCP – your Internet just got faster". Retrieved 25 August 2017.
  31. ↑ "BBR congestion control [LWN.net]". lwn.net.
  32. ↑ "बीबीआर अद्यतन". IETF.
  33. ↑ "टीसीपी और बीबीआर" (PDF). Retrieved 27 May 2018.
  34. ↑ "बीबीआर कंजेशन नियंत्रण का प्रायोगिक मूल्यांकन" (PDF). Retrieved 27 May 2018.
  35. ↑ "A Performance Evaluation of TCP BBRv2". Retrieved 12 January 2021.
  36. ↑ 36.0 36.1 Google TCP BBR team; Google QUIC BBR team (Jul 26, 2023). BBRv3: Algorithm Bug Fixes and Public Internet Deployment. IETF 117: San Francisco. {{cite conference}}: |author1= has generic name (help)
  37. ↑ "Cellular Controlled Delay TCP (C2TCP)". wp.nyu.edu. Retrieved 2019-04-27.
  38. ↑ Alrshah, M.A.; Al-Maqri, M.A.; Othman, M. (June 2019). "Elastic-TCP: Flexible Congestion Control Algorithm to Adapt for High-BDP Networks". IEEE Systems Journal. 13 (2): 1336–1346. arXiv:1904.13105. Bibcode:2019ISysJ..13.1336A. doi:10.1109/JSYST.2019.2896195.
  39. ↑ Abbasloo, Soheil (2019-06-03), GitHub - Soheil-ab/natcp, retrieved 2019-08-05
  40. ↑ Yuan, Cao; Tan, Liansheng; Andrew, Lachlan L. H.; Zhang, Wei; Zukerman, Moshe (6 June 2008). "एक सामान्यीकृत फास्ट टीसीपी योजना". Computer Communications. 31 (14): 3242–3249. doi:10.1016/j.comcom.2008.05.028. hdl:1959.3/44051. S2CID 17988768.
  41. ↑ 41.0 41.1 "Rice Networks Group".
  42. ↑ "TCP Veno: TCP Enhancement for Transmission over Wireless Access Networks" (PDF). IEEE Journal on Selected Areas in Communication.
  43. ↑ "XCP @ ISI".
  44. ↑ "हाई स्पीड टीपीसी" (PDF). www.csc.lsu.edu.
  45. ↑ "संग्रहीत प्रति". Archived from the original on 3 April 2011. Retrieved 5 March 2011.
  46. ↑ Benaboud, H.; Berqia, A.; Mikou, N. (2002). "टीसीपी प्रोटोकॉल में CANIT एल्गोरिदम का एक विश्लेषणात्मक अध्ययन". ACM SIGMETRICS Performance Evaluation Review. 30 (3): 20. doi:10.1145/605521.605530. S2CID 6637174.
  47. ↑ Rouhani, Modjtaba (2010). "Nonlinear Neural Network Congestion Control Based on Genetic Algorithm for TCP/IP Networks". 2010 2nd International Conference on Computational Intelligence, Communication Systems and Networks. pp. 1–6. doi:10.1109/CICSyN.2010.21. ISBN 978-1-4244-7837-8. S2CID 15126416.
  48. ↑ Kanagarathinam, Madhan Raj; Singh, Sukhdeep; Sandeep, Irlanki; Roy, Abhishek; Saxena, Navrati (January 2018). "D-TCP: Dynamic TCP congestion control algorithm for next generation mobile networks". 2018 15th IEEE Annual Consumer Communications & Networking Conference (CCNC). pp. 1–6. doi:10.1109/CCNC.2018.8319185. ISBN 978-1-5386-4790-5. S2CID 3991163.
  49. ↑ Kanagarathinam, Madhan Raj; Singh, Sukhdeep; Sandeep, Irlanki; Kim, Hanseok; Maheshwari, Mukesh Kumar; Hwang, Jaehyun; Roy, Abhishek; Saxena, Navrati (2020). "NexGen D-TCP: Next Generation Dynamic TCP Congestion Control Algorithm". IEEE Access. 8: 164482–164496. doi:10.1109/ACCESS.2020.3022284. ISSN 2169-3536. S2CID 221846931.
  50. ↑ Arun, Venkat; Balakrishnan, Hari (2018). "Copa: Practical Delay-Based Congestion Control for the Internet". 15th USENIX Symposium on Networked Systems Design and Implementation (NSDI 18): 329–342. ISBN 978-1-939133-01-4.
  51. ↑ "पांच नए टीसीपी कंजेशन नियंत्रण एल्गोरिदम परियोजना का सारांश". 8 March 2011.
  52. ↑ "iTCP - Interactive Transport Protocol - Medianet Lab, Kent State University".
  53. ↑ "Whitepaper: Zeta-TCP - Intelligent, Adaptive, Asymmetric TCP Acceleration" (PDF). Retrieved 2019-12-06.
  54. ↑ Lefteris Mamatas; Tobias Harks; Vassilis Tsaoussidis (January 2007). "पैकेट नेटवर्क में भीड़ नियंत्रण के दृष्टिकोण" (PDF). Journal of Internet Engineering. 1 (1). Archived from the original (PDF) on 2014-02-21.
  55. ↑ "हाईस्पीड टीसीपी". www.icir.org.
  56. ↑ "एआईएमडी-एफसी होमपेज". neu.edu. Archived from the original on 13 January 2009. Retrieved 13 March 2016.
  57. ↑ "नेटवर्क रिसर्च लैब में आपका स्वागत है". www.cs.ucla.edu.
  58. ↑ "यूनिकैस्ट अनुप्रयोगों के लिए समीकरण-आधारित भीड़ नियंत्रण". www.icir.org.
  59. ↑ Katabi, Dina; Handley, Mark; Rohrs, Charlie (2002). "Congestion control for high bandwidth-delay product networks". Proceedings of the 2002 conference on Applications, technologies, architectures, and protocols for computer communications. New York, New York, USA: ACM Press. p. 89. doi:10.1145/633025.633035. ISBN 1-58113-570-X.
  60. ↑ "मैक्सनेट--मैक्स-मिन फेयर, स्थिर स्पष्ट सिग्नलिंग कंजेशन नियंत्रण". netlab.caltech.edu.

स्रोत

बाहरी संबंध

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=टीसीपी_संकुलन_नियंत्रण&oldid=266763’