आप RTO को विशेष रूप से बदल नहीं सकते इसका कारण यह है कि यह एक स्थिर मूल्य नहीं है। इसके बजाय (प्रारंभिक SYN को छोड़कर, स्वाभाविक रूप से) यह प्रत्येक कनेक्शन के लिए RTT (राउंड ट्रिप टाइम) पर आधारित है। दरअसल, यह आरटीटी के स्मूथ वर्जन और आरटीटी वेरिएंट पर आधारित है, जिसमें कुछ कांस्टेंट मिश्रण में डाले जाते हैं। इसलिए, यह प्रत्येक टीसीपी कनेक्शन के लिए एक गतिशील, गणना मूल्य है, और मैं इस लेख की अत्यधिक अनुशंसा करता हूं जो सामान्य रूप से गणना और आरटीओ पर अधिक विवरण में जाता है।
इसके अलावा प्रासंगिक RFC 6298 है जिसमें कहा गया है (बहुत सी अन्य चीजों के बीच):
जब भी RTO की गणना की जाती है, अगर यह 1 सेकंड से कम है, तो RTO SHOULD को 1 सेकंड तक राउंड किया जाए।
क्या कर्नेल हमेशा आरटीओ को 1 सेकंड के लिए सेट करता है? ठीक है, लिनक्स के साथ आप ss -iकमांड चलाकर अपने खुले कनेक्शन के लिए वर्तमान RTO मान दिखा सकते हैं :
State Recv-Q Send-Q Local Address:Port Peer Address:Port
ESTAB 0 0 10.0.2.15:52861 216.58.219.46:http
cubic rto:204 rtt:4/2 cwnd:10 send 29.2Mbps rcv_space:14600
ESTAB 0 0 10.0.2.15:ssh 10.0.2.2:52586
cubic rto:201 rtt:1.5/0.75 ato:40 cwnd:10 send 77.9Mbps rcv_space:14600
ESTAB 0 0 10.0.2.15:52864 216.58.219.46:http
cubic rto:204 rtt:4.5/4.5 cwnd:10 send 26.0Mbps rcv_space:14600
उपरोक्त एक VM से आउटपुट है जिसे मैं SSH के साथ लॉग इन कर रहा हूं और इसके कुछ कनेक्शन google.com पर खुले हैं। जैसा कि आप देख सकते हैं, आरटीओ वास्तव में 200-ईश (मिलीसेकंड) के लिए निर्धारित है। आप ध्यान दें कि RFC से 1 सेकंड के मूल्य के लिए गोल नहीं है, और आप यह भी सोच सकते हैं कि यह थोड़ा अधिक है। ऐसा इसलिए है क्योंकि लिनक्स के लिए RTO में मिन (200 मिलीसेकंड) और अधिकतम (120 सेकंड) की सीमा होती है, (ऊपर मैंने जो लेख जोड़ा है, उसमें इसका एक बड़ा विवरण है)।
इसलिए, आप सीधे RTO मान को बदल नहीं सकते हैं, लेकिन हानिपूर्ण नेटवर्क (वायरलेस जैसे) के लिए आप F-RTO को ट्विक करने का प्रयास कर सकते हैं (यह पहले से ही आपके डिस्ट्रो के आधार पर सक्षम हो सकता है)। एफ-आरटीओ से संबंधित वास्तव में दो संबंधित विकल्प हैं जिन्हें आप ट्वीक कर सकते हैं (अच्छा सारांश यहां ):
net.ipv4.tcp_frto
net.ipv4.tcp_frto_response
आप जिस चीज के लिए अनुकूलन करना चाह रहे हैं, उसके आधार पर ये उपयोगी हो सकते हैं या नहीं भी।
संपादित करें: टिप्पणियों से टीसीपी के लिए rto_min / अधिकतम मूल्यों को ट्विक करने की क्षमता का अनुसरण करना।
आप टीसीपी के लिए वैश्विक न्यूनतम आरटीओ को नहीं बदल सकते हैं (एक तरफ के रूप में, आप इसे एससीटीपी के लिए कर सकते हैं - जो कि एससीएसटीएल में उजागर होते हैं), लेकिन अच्छी खबर यह है कि आप आरटीओ के न्यूनतम मूल्य को प्रति-मार्ग पर ट्विक कर सकते हैं आधार। यहाँ मेरे CentOS VM पर मेरी राउटिंग टेबल है:
ip route
10.0.2.0/24 dev eth0 proto kernel scope link src 10.0.2.15
169.254.0.0/16 dev eth0 scope link metric 1002
default via 10.0.2.2 dev eth0
मैं डिफ़ॉल्ट मार्ग पर rto_min मान को निम्नानुसार बदल सकता हूं:
ip route change default via 10.0.2.2 dev eth0 rto_min 5ms
और अब, मेरी रूटिंग टेबल इस तरह दिखती है:
ip route
10.0.2.0/24 dev eth0 proto kernel scope link src 10.0.2.15
169.254.0.0/16 dev eth0 scope link metric 1002
default via 10.0.2.2 dev eth0 rto_min lock 5ms
अंत में, आइए एक कनेक्शन शुरू करें और ss -iदेखें कि क्या यह सम्मान किया गया है:
ss -i
State Recv-Q Send-Q Local Address:Port Peer Address:Port
ESTAB 0 0 10.0.2.15:ssh 10.0.2.2:50714
cubic rto:201 rtt:1.5/0.75 ato:40 cwnd:10 send 77.9Mbps rcv_space:14600
ESTAB 0 0 10.0.2.15:39042 216.58.216.14:http
cubic rto:15 rtt:5/2.5 cwnd:10 send 23.4Mbps rcv_space:14600
सफलता! HTTP कनेक्शन (परिवर्तन के बाद) पर rto 15ms है, जबकि SSH कनेक्शन (परिवर्तन से पहले) 200+ पहले की तरह है।
मैं वास्तव में इस दृष्टिकोण को पसंद करता हूं - यह आपको विश्व स्तर पर बजाय उचित मार्गों पर कम मूल्य निर्धारित करने की अनुमति देता है जहां यह अन्य यातायात को खराब कर सकता है। इसी तरह ( आईपी मैन पेज देखें ) आप मार्ग के लिए प्रारंभिक आरटीटी अनुमान और प्रारंभिक आरटीएवीआर को घुमा सकते हैं (गतिशील आरटीओ की गणना करते समय उपयोग किया जाता है)। जबकि यह ट्वीकिंग के संदर्भ में एक पूर्ण समाधान नहीं है, मुझे लगता है कि अधिकांश महत्वपूर्ण टुकड़े हैं। आप अधिकतम सेटिंग को ट्विक नहीं कर सकते, लेकिन मुझे लगता है कि यह किसी भी मामले में आम तौर पर उपयोगी नहीं होगा।