टीसीपी पैकेट का न्यूनतम आकार क्या है

Question

यहाँ एक पोस्ट:

http://blogs.adobe.com/dreamweaver/2011/02/optimal-css-tiled-background-image-size.html

staes कि "सबसे छोटा डाउनलोड जो ब्राउज़र कर सकता है वह है 1K बाइट्स।"

क्या यह पूरे नेटवर्क में एक पैकेट के न्यूनतम आकार के कारण है? यदि नहीं, तो इसका क्या कारण है (यदि यह वास्तव में सच है)?

Comments

यदि आप भ्रम से बचना चाहते हैं तो मानक शब्दों से चिपके रहें। "पैकेट" एक आईपी-स्तरीय शब्द है। आप कहते हैं "आईपी पैकेट", न "टीसीपी पैकेट", न ही "ईथरनेट पैकेट"।

— vtest 12

आप जिस वाक्य को उद्धृत करते हैं ("ब्राउज़र जो सबसे छोटा डाउनलोड कर सकता है वह है 1K बाइट्स।") सबसे निश्चित रूप से सच नहीं है - कोई न्यूनतम डाउनलोड आकार नहीं है; और जब तक वहाँ है एक न्यूनतम टीसीपी / आईपी पैकेट आकार (के रूप में @ DMA57361 द्वारा समझाया गया है), यह निश्चित रूप से नहीं 1KB है।

— पिस्कोर ने

Answer 1

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

---

आप डेटा के 1 बाइट भेज रहे हैं मान देता है ¹ इंटरनेट पर, पर टीसीपी / आईपी मॉडल ।

डेटा अनुप्रयोग स्तर और जरूरतों पर शुरू होता है निचले स्तर इतना है कि यह चारों ओर पारित किया जा सकता के लिए हेडर में ऊपर लपेट किया जाना है।

पहले वह डेटा एक टीसीपी सेगमेंट में लिपटा हुआ है , जिसमें 20 बाइट्स का हेडर (मिनट का आकार अब 21 बाइट्स) जोड़ा गया है।
यह हमें परिवहन स्तर पर रखता है।

इसके बाद आईपी ​​पैकेट में लपेटा जाता है , जो 20 बाइट्स का एक और हेडर जोड़ता है (न्यूनतम आकार अब 41 बाइट्स)।
अब हम इंटरनेट के स्तर पर हैं।
ध्यान दें कि यह रैपिंग हर बार एक नया राउटर आपके डेटा को एक नए सबनेट में फॉरवर्ड करता है।

यह कुछ प्रकार के लिंक फ्रेम में लपेटा जाता है - जिनमें से हेडर और फुटर का आकार उपयोग किए गए फ्रेम के प्रकार के आधार पर भिन्न होता है, जो उपयोग किए जा रहे लिंक के प्रकार पर निर्भर करता है।
यह लिंक स्तर पर है।
यदि दो इकाइयों के बीच संचार होता है तो यह रैपिंग हर बार यूनिट बदल जाती है।

अंत में भौतिक संचरण है (उदाहरण के लिए, एक केबल, रेडियो तरंगों आदि के नीचे विद्युत संकेत)।

यहाँ विकिपीडिया टीसीपी / आईपी मॉडल पेज से कुछ जानकारीपूर्ण छवियां उपलब्ध हैं, जो स्पष्ट रूप से बताती हैं कि क्या हो रहा है:

---

---

---

^{1. मुझे लगता है कि आप 0 बाइट भेजने में सक्षम हो सकते हैं ... लेकिन यह जाँच नहीं की है। वास्तव में मैंने चेक नहीं किया है यदि 1 बाइट की अनुमति है, लेकिन हे।}

Answer 2

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

एक मानक ईथरनेट पैकेट का न्यूनतम आकार 64 बाइट्स है।

Answer 3

इसके मुख पर, आपके द्वारा उद्धृत ब्लॉग पोस्ट गलत है। HTTP के लिए कोई "न्यूनतम डाउनलोड आकार" नहीं है। (और न्यूनतम पैकेट आकार के बारे में आपका सिद्धांत भी गलत है।)

हालाँकि, इस के लिए सच्चाई का एक दाना है। और वह यह है कि यदि आपके द्वारा डाउनलोड की जा रही फ़ाइल का आकार काफी छोटा है, तो HTTP प्रतिक्रिया संदेश (फ़ाइल और HTTP प्रतिक्रिया हेडर से मिलकर) एकल नेटवर्क पैकेट में फिट होगा। यदि ऐसा होता है, तो ब्राउज़र को फ़ाइल को तेज़ी से प्राप्त करने की संभावना है, अगर उसने प्रतिक्रिया भेजने के लिए दो या अधिक पैकेट ले लिए।

(प्रतिक्रिया में एक पैकेट के साथ, इस बात की संभावना कम है कि एक पैकेट को गिरा दिया जाए और नाराजगी की जरूरत हो, और एक बड़ा मौका कि टीसीपी / आईपी फ्लो-कंट्रोल विंडो पैकेट पावती के लिए अतिरिक्त राउंड-ट्रिप देरी नहीं जोड़ेगी। )

भेजे गए / प्राप्त (MTU) पैकेट के विशिष्ट अधिकतम आकार में ईथरनेट के लिए 1500 बाइट्स हैं। जब आप IP और TCP ओवरहेड्स में फैक्टर करते हैं, और एक विशिष्ट HTTP प्रतिक्रिया हेडर का आकार, जो आपको प्रतिक्रिया के पहले पैकेट में फ़ाइल डेटा के लिए अच्छी तरह से ~ 1K छोड़ सकता है। इसलिए ब्लॉगर की टिप्पणी में सत्य का अनाज।

Comments

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

— पिस्कोर ने इमारत को

Answer 4

यह आपके विचार से भी बदतर है।

धीमा पृष्ठ लोड हो रहा है क्योंकि ब्राउज़र में 1x1 पिक्सेल 800000 बार (उदाहरण के लिए 1000x800 पर सेट ब्राउज़र विंडो के लिए) रेंडर करने वाले मुद्दे हैं। कई साल पहले, शायद १ ९९९ में, मैंने कहीं एक लेख पढ़ा जिसमें १६x१६ को टाइलिंग के लिए, सबसे तेज ’x सबसे छोटा बताया गया था। बेशक, प्रतिपादन अब अलग हो सकता है।

यदि आप ब्लॉग पोस्ट पढ़ते हैं, तो शिकायत वास्तव में धीमी पृष्ठ लोडिंग के बारे में है। डाउनलोडिंग धीमी नहीं। इसका पैकेट से कोई लेना-देना नहीं है, हालांकि इसकी दिलचस्प चर्चा रही है।

तो शायद प्रश्न को फिर से शब्द दिया जाना चाहिए।

Comments

उस स्थिति में, मैंने पूरी तरह से ब्लॉग पोस्ट को गलत समझा हो सकता है - मैंने सोचा है कि कोर इस वाक्य में है: "सबसे छोटा डाउनलोड जो ब्राउज़र कर सकता है वह है 1K बाइट्स [और इसलिए, अपनी छवि का आकार 1K] में समायोजित करें", जो मैंने "के रूप में पढ़ा है ... क्योंकि आप वैसे भी 1K बाइट्स प्रसारित कर रहे हैं, इससे कोई फर्क नहीं पड़ता कि आपकी छवि केवल 50 बाइट्स है" (जो कि एक स्पष्ट बकवास है)। यहाँ समस्या sizeपिक्सेल आयामों और बाइट गणना के लिए " " और उन्हें स्वीकार करने के लिए दोनों का उपयोग कर रही हो सकती है। आपका स्पष्टीकरण समझ में आता है, लेकिन छवि की गिनती के लिए अप्रासंगिक है (ब्लॉग क्या कहता है इसके विपरीत)।

— पिस्कोर ने

ब्लॉग पोस्ट को फिर से पढ़ने के बाद, वह कोर्स को बंद करना चाहता है क्योंकि तीसरा पैराग्राफ असंगत है।

— मॉकमैन

आपकी टिप्पणी को फिर से पढ़ने के बाद ... उसका इरादा बिंदु प्रारंभिक पैराग्राफ में उठाई गई समस्या का समाधान करना है। हालाँकि, वह गलती से पैकेट के आकार के लिए इस समस्या को बताता है और उस पर बाकी पोस्ट खर्च करता है। मेरे उत्तर ने धीमे पृष्ठ लोड होने का कारण बताया। जैसा कि दूसरों ने बताया है, पैकेट विशेषताओं का कारण नहीं है।

— मॉकमैन