लिनक्स स्लो स्टार्ट: आईपी रूट को बदलने से शुरुआती विंडो पर कोई प्रभाव नहीं पड़ता है


10

मैंने अपनी मशीन में tcp प्रारंभिक विंडो को 10 में बदल दिया जैसा कि नीचे दिखाया गया है

[user@site etc]$ sudo ip route change default via 17.255.209.1 dev eth0  proto static initcwnd 10 

और tcp_slow_start_after_idleजैसा कि नीचे दिखाया गया है

[user@site etc]$ sudo sysctl -a | grep tcp_slow_start_after_idle
net.ipv4.tcp_slow_start_after_idle = 0

एक आईपी रूट शो पुष्टि नीचे दी गई है

[user@site etc]$ ip route show
default via 17.255.209.1 dev eth0  proto static  initcwnd 10
169.254.0.0/16 dev eth0  scope link  metric 1002
17.255.209.0/24 dev eth0  proto kernel  scope link  src 17.255.209.19

अब जब मैं वेबसाइट पर एक tcpdump करता हूं, तो मुझे प्रारंभिक विंडो में WIN / MSS के शेष 4 के रूप में डिफ़ॉल्ट रूप में बदलाव नहीं दिखता है । 5840/1460 = 4

[user@site etc]$ sudo tcpdump -n -i any 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn and port 80'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
11:17:45.048174 IP 21.101.151.198.45873 > 17.255.209.19.http: Flags [S], seq 2008673341, win 5840, options [mss 1460,sackOK,TS val 1724223146 ecr 0,nop,wscale 6], length 0

कर्ल हिट जो मैंने वेबपेज पर किया था, उसमें लगभग 30 KB डेटा का अनुरोध किया गया था ।

[user@machine ~]$ curl http://www.site.com/js/main.js > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 88212  100 88212    0     0   179k      0 --:--:-- --:--:-- --:--:--  272k

मेरे दृष्टिकोण में क्या गलत हो सकता है?

गुठली

[user~]$ uname -r
3.0.4x86_64-linode21

एक अद्यतन के रूप में, यहाँ परिणाम हैं जब मैं google.com की कोशिश करता हूँ

[user@site ~]$ sudo tcpdump -n -i any 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn and host www.google.com'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
17:20:28.033236 IP 17.255.209.19.42799 > 74.125.127.106.http: Flags [S], seq 3148947324, win 14600, options [mss 1460,sackOK,TS val 193695310 ecr 0,nop,wscale 4], length 0

जैसा कि आप देख सकते हैं कि विन / एमएसएस इस मामले में 14600/1460 = 10 है

मैंने सर्वर साइट से कर्ल के माध्यम से अपनी साइट को मारने की कोशिश की और यहां परिणाम है:

[user@site ~]$ sudo tcpdump -n -i any 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn and host www.site.com'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
17:25:14.584338 IP 17.255.209.19.35008 > 17.255.209.19.http: Flags [S], seq 3894567470, win 32792, options [mss 16396,sackOK,TS val 193981861 ecr 0,nop,wscale 4], length 0

इस मामले में विन / एमएसएस 32792/16396 = 2 है


ध्यान रखें, यदि आप इसे एक linux मशीन से मार रहे हैं, तो आपको 3.0 पर भी होना होगा, जो स्रोत / टैग के माध्यम से खोलेगा, जो कि परिवर्तन के लिए तैयार किए गए सटीक 3 संस्करण की पुष्टि करेगा
सैम सैफ्रन

@QuintinPar क्या आप अपने टेस्ट मशीन से कनेक्शन के साथ tcpdump आउटपुट जोड़ सकते हैं?
kupson

@kupson मैंने प्रश्न को अद्यतन किया है
पार

जहां तक ​​मुझे पता है कि आप आने वाले कनेक्शन पर प्रारंभिक विंडो को प्रभावित नहीं कर सकते । Google से आपका कनेक्शन दिखाता है कि आपके पास IW सेट 10 पर है। लूपबैक अवरफेस उस बड़े MTU के साथ काफी खास है, हो सकता है कि कर्नेल स्रोत में इनिशियल विंडो पर कुछ कैप हो।
कुपसन

ध्यान रखें, 2 चीजें आईडब्ल्यू निर्धारित करेगी। ग्राहक अधिकतम प्रारंभिक भीड़ खिड़की और सर्वर IW। छोटी जीत। 2 मशीनों से परीक्षण चलाएं, सर्वर में 3.0 में डिफ़ॉल्ट रूप से IW सेट होना चाहिए ... और XP / Vista / Win7 क्लाइंट IW को प्रतिबंधित नहीं करते हैं इसलिए परीक्षण के लिए अच्छे ग्राहक बनाते हैं। 3.0 लिनक्स क्लाइंट भी काम करते हैं, लेकिन एक अलग मशीन होनी चाहिए।
सैम केसरॉन

जवाबों:


9

मुझे लगता है कि आप गलत समझ रहे हैं कि टीसीपी कैसे काम करता है।

भेजे गए प्रत्येक पैकेट हमेशा एक रिसीवर विंडो (उर्फ आरडब्ल्यूआईएन) और एक वैकल्पिक स्केलिंग कारक का विज्ञापन करेगा, आरएफसी 1323 देखें

प्रेषक को स्वीकार किए बिना RWIN में निर्दिष्ट डेटा की मात्रा से अधिक भेजने की अनुमति नहीं है । भीड़ खिड़की के आधार पर, प्रेषक RWIN को भरने या नहीं करने का निर्णय ले सकता है।

तो, सूचना के दो बिट्स हैं जो टीसीपी पैकेट में सार्वजनिक हैं। सर्वर पर RWIN और क्लाइंट पर RWIN। ये दोनों आंकड़े निर्धारित करते हैं कि दोनों छोर पर भीड़भाड़ खिड़की का अधिकतम आकार क्या हो सकता है।

सर्वर पर RWIN दिलचस्प है जब हम कहते हैं कि फ़ाइल अपलोड के लिए प्रदर्शन का अनुकूलन करने की कोशिश कर रहे हैं।

क्लाइंट पर RWIN दिलचस्प है जब हम डाउनलोड गति निर्धारित करने की कोशिश कर रहे हैं।

इनमें से कोई भी संख्या दूसरे छोर पर भीड़ खिड़की को सार्वजनिक नहीं करती है

अतः अगर मैं 64k के RWIN है, सर्वर पर भीड़ खिड़की हो सकता है किसी भी संख्या 64k से कम है।

यह निर्धारित करने का एकमात्र तरीका है कि पैकेट को गिनने के लिए वास्तविक जमाव खिड़की क्या है।

यदि मुझे पता होता:

  1. मेरी गोल यात्रा का समय (RTT) ~ 200ms है।
  2. मैंने सिर्फ एक संसाधन का अनुरोध किया है जो 100k है।
  3. मेरे पास 64k का RWIN है।

अगर मुझे सर्वर से 2 पैकेट मिलते हैं जो ~ 200ms के भीतर 1452 बाइट्स लंबे होते हैं, तो संभावना है कि सर्वर पर कंजेशन विंडो 4356 से छोटी है, कारण अगर यह बड़ा था तो 3 पैकेट भेजे जाएंगे। अगर IW 10 पर सेट होता है, तो मुझे 200ms के निशान के आसपास 10 पैकेट फटने दिखाई देंगे।

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

ध्यान रखें, आप शायद SYN, SYN-ACK, ACK के बाद सीधे वार्तालाप को देखना चाहते हैं ताकि यह सुनिश्चित हो सके कि आप बातचीत के बीच में नहीं देख रहे हैं (जहाँ भीड़ खिड़की पहले ही बढ़ सकती थी)।


1
टीसीपी / आईपी इलस्ट्रेटेड की भीड़भाड़ खिड़की और टीसीपी विंडो के बीच अंतर 20.6 (धीमी शुरुआत) में कहा गया है: "धीमी शुरुआत प्रेषक के टीसीपी में एक और खिड़की जोड़ता है : भीड़ खिड़की, जिसे cwnd कहा जाता है" (बोल्ड मेरा)। 20.7 में एक अनुक्रम आरेख है जो बल्क ट्रांसफर के दौरान इसे दिखाता है।
काइल ब्रांट

7

विंडो का आकार जो भी छोटा होगा: सर्वर इनिट विंडो आकार या क्लाइंट RWIN। चूंकि लिनक्स 2.6 के लिए 5840 डिफ़ॉल्ट आरडब्ल्यूआईएन है, ऐसा लगता है कि आपका क्लाइंट यहां सीमित कारक है।

एक विंडो बॉक्स से प्रयास करें। विंडोज एक्सपी में 64k का RWIN, नया संस्करण 8k है।

स्रोत: http://www.cdnplanet.com/blog/tune-tcp-initcwnd-for-optimum-performance/ (दिलचस्प हिस्सा वीडियो के नीचे है)

संपादित करें: इसे स्पष्ट करने के लिए उत्तर का विस्तार:

  • टीसीपी हैंडशेक में, क्लाइंट अपने अधिकतम अनुमत विंडो आकार को भेजने वाले सर्वर को एक SYN पैकेट भेजता है। (जैसा कि आपके tcpdump आउटपुट से पता चलता है, ये 5840 बाइट्स हैं)
  • सर्वर अब SYN ACK और उस विंडो के आकार के साथ प्रतिक्रिया करता है जिस पर वह सहमत होना चाहता है। इस विंडो का आकार केवल उस ग्राहक की तुलना में छोटा हो सकता है जो प्रस्तावित है, बड़ा नहीं है। कोई फर्क नहीं पड़ता कि सर्वर कैसे कॉन्फ़िगर किया गया है, इसमें उस क्लाइंट के साथ 5840 बाइट्स की तुलना में बड़े विंडो आकार कभी नहीं हो सकते।
  • ग्राहक ACK देता है और वे खुशी-खुशी डेटा का आदान-प्रदान करते हैं।

Edit2: सवाल में जोड़ा गया tcpdumps सर्वर को Google से कनेक्शन खोलने के लिए दिखाता है और CLIENT के रूप में कार्य करता है।


प्रारंभिक विंडो (SYN पैकेट में प्रस्तावित) 5840 है। यह एक पहला पैकेट और भेजने वाली मशीन है जो इस समय रिसीवर के बारे में कुछ नहीं जानती है (मैंने इसे "आईपी मार्ग फ्लश कैश" के साथ परीक्षण किया है)।
कूपसन

उह, 17.255.209.0 आपका सर्वर सबनेट है, है ना? जो पैकेट आप देख रहे हैं, वह 21.101.151.198.45873 से 17.255.209.19.http का है। मैं tcpdump आउटपुट का कोई विशेषज्ञ नहीं हूं, लेकिन मेरे लिए यह पढ़ता है: हैलो सर्वर, मैं आपका ग्राहक हूं, मुझे 5840 बाइट विंडो पसंद हैं। :) अगला पैकेट ACK के साथ प्रतिक्रिया करने वाला सर्वर होगा, 5840 बढ़िया है, चीयर्स। :)
किसी ने

बस जोर देने के लिए, मुझे लगता है कि आपको यह गलत तरीका मिल गया है: पहली भेजने वाली मशीन क्लाइंट है क्योंकि यह कनेक्शन खोलता है, न कि आपका सर्वर। यह 5840 बाइट विंडो की पेशकश करने वाला क्लाइंट है। सर्वर एक बड़े विंडो आकार का प्रस्ताव नहीं कर सकता, केवल एक छोटा।
किसी ने

1
मैं इस प्रश्न का मूल लेखक नहीं हूँ। मैंने इसे अपने परीक्षण वातावरण पर (समान परिणामों के साथ) परीक्षण किया और इसे बदल भी नहीं सकता। प्रारंभिक कंजेशन विंडो आकार (initcwnd) का कनेक्शन के अन्य पक्ष से कोई लेना-देना नहीं है।
कूपसन

मुझे आपका सेटअप नहीं पता। मूल पोस्टर ने पूछा कि सर्वर पर प्रारंभिक विंडो आकार को बढ़ाने के बावजूद उसके परीक्षण कनेक्शन में केवल 5840 बाइट्स का विंडो आकार है। इसका उत्तर है: क्योंकि जिस ग्राहक के साथ उसने परीक्षण किया है, वह बड़े आकार के विंडो की अनुमति नहीं देता है। मैं सामान्य रूप से अवधारणा के साथ अन्य सेटअपों या संभवतः अन्य समस्याओं / बगों पर टिप्पणी नहीं कर सकता।
किसी
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.