आईपी ​​हेडर में पिंग का "राउंड-ट्रिप टाइम" कहाँ संग्रहीत है?


9

यदि हम ICMP का उपयोग करते हैं ping, तो हम TTL को जानते round-trip timeहैं और IP हेडर में संग्रहीत हैं। नीचे दिए गए आईपी हेडर मैप में हम टीटीएल का स्थान जानते हैं, लेकिन राउंड-ट्रिप का समय कहां है?

यहां छवि विवरण दर्ज करें

क्या इसमें संग्रहित है Options?

जवाबों:


23

राउंड ट्रिप का समय वास्तव में कहीं भी संग्रहीत नहीं है। भेजने वाला होस्ट उस समय को याद करता है जब वह ICMP के 16-बिट आइडेंटिफ़ायर और सीक्वेंस फ़ील्ड का उपयोग करते हुए प्रत्येक ICMP इको रिक्वेस्ट मैसेज भेजता है। जब यह ICMP इको रिप्लाई हो जाता है, तो यह वर्तमान समय को नोट करता है, यह उस समय को खोजता है, जब उसने मिलान किए गए रिक्वेस्ट पैकेट को रिप्लाई द्वारा पहचाना जाता है, अंतर की गणना करता है, और उसे रिपोर्ट करता है।

आमतौर पर पिंग ICMP के पहचान क्षेत्र का उपयोग एक साथ कई पिंग्स को अलग करने के लिए करता है, और अलग-अलग पैकेट को अलग करने के लिए अनुक्रम क्षेत्र को।

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

dataआईपी ​​पैकेट के हिस्से के अंदर का प्रारूप ICMP इको रिक्वेस्ट / रिप्लाई संदेश है, जिसे RFC 792 "इंटरनेट कंट्रोल मैसेज फॉर्मेट" (p14) से कॉपी किया गया है ।

Typeअनुरोध के लिए 8, उत्तर के लिए 0 है; Code0 है।

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Identifier          |        Sequence Number        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Data ...
   +-+-+-+-+-

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

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

अंत में, हालांकि यहां सब कुछ मूल प्रश्न के अनुसार एक आईपीवी 4 परिप्रेक्ष्य से लिखा गया था; लेकिन IPv6 में पिंग बेहद समान है, ICMPv6 RFC 4443 देखें ।


3
एआईयूआई "पहचान" फ़ील्ड का उपयोग टुकड़े के पुन: अंश के लिए पैकेट की पहचान करने के लिए किया जाता है। इको अनुरोधों को ICMP हेडर में id और seq फील्ड्स के इको रिप्लाई से मिलान किया जाता है।
पीटर ग्रीन

इसे इंगित करने के लिए धन्यवाद: मैंने स्पष्ट किया कि यह आईसीएमपी नहीं है आईपी आईडी (और seq, जैसा कि आप कहते हैं)।
जोनाथनजो

मुझे पूरा यकीन है कि pingलिनक्स पर कम से कम एक कार्यान्वयन है जो Dataआईसीएमपी पेलोड के अनुभाग में टाइमस्टैम्प को संग्रहीत करता है । उस समय कुछ काफी दिलचस्प त्रुटि संदेश होता है, जब प्रतिध्वनि एक इंटरनेट एक्सचेंज का जवाब देती है जो हर पैकेट में उस स्थान पर थोड़ा सा दूषित कर रहा था।
कैसपर्ड

आप निश्चित रूप से सही हैं, और मैंने यह कहने के लिए उत्तर को अपडेट किया; हालांकि स्वाभाविक रूप से यह प्रेषक की घड़ी के अनुसार पूर्ण समय भेज रहा है जो आरटीटी ही नहीं है।
जोनाथनजो

3

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

यह उपयोगिता के लिए मैन पेजping में वर्णित है ("आईसीएमपी पैकेट विवरण" के तहत):

यदि डेटा स्थान struct timevalपिंग के आकार का कम से कम है, तो एक टाइमस्टैम्प को शामिल करने के लिए इस स्थान के शुरुआती बाइट्स का उपयोग करता है जो इसे गोल यात्रा समय की गणना में उपयोग करता है। यदि डेटा स्थान छोटा है, तो कोई गोल यात्रा समय नहीं दिया जाता है।

मेरी मशीन sizeof(struct timeval)16 पर है, इसलिए पैकेट डेटा का आकार 15 तक सेट करने pingसे राउंड-ट्रिप समय दिखाने से रोकता है:

$ ping -s 15 8.8.8.8 
PING 8.8.8.8 (8.8.8.8) 15(43) bytes of data.
23 bytes from 8.8.8.8: icmp_seq=1 ttl=121

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


1
ऐसा महसूस होता है कि यह एक प्रोग्राम बग है जिसे आप डेटा आकार 16 से कम होने पर आरटीटी प्रदर्शित नहीं कर सकते। लेकिन अच्छे अंक।
कनाडाई

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

@ilkachach मुझे याद दिलाने के लिए धन्यवाद जहाँ समय अक्सर संग्रहीत होता है; मैंने अपना उत्तर अपडेट कर दिया। छोटे पैकेट पुन: कई नेटवर्क समस्याओं को पैकेट आकार पर विभेदित किया जाता है।
जोनाथनो

@ikkachu मैंने सिस्को के पिंग पैकेटों पर एक नज़र डाली: उनके पास भी समय है, मिलीसेकंड की 64-बिट गिनती के रूप में।
जोनाथनजो
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.