हम एक संदेशवाहक बनाते हैं * जो लिफ्ट में भी काम करता है

* वास्तव में, हम केवल प्रोटोकॉल का प्रोटोटाइप लिखेंगे।

शायद आपने भी ऐसी ही स्थिति का सामना किया है - अपने पसंदीदा दूत में बैठे, दोस्तों के साथ बातें करते हुए, लिफ्ट / सुरंग / गाड़ी में जाते हैं, और इंटरनेट अभी भी पकड़ में आता है, लेकिन कुछ भी नहीं भेजा जा सकता है? या कभी-कभी आपके संचार प्रदाता नेटवर्क को गलत तरीके से कॉन्फ़िगर करते हैं और 50% पैकेट गायब हो जाते हैं, और कुछ भी काम नहीं करता है। शायद आप उस पल को सोच रहे थे - ठीक है, आप शायद किसी तरह कुछ कर सकते हैं ताकि खराब कनेक्शन के साथ आप अभी भी उस छोटे से पाठ को भेज सकें जो आप चाहते हैं? आप अकेले नहीं हैं।

चित्र स्रोत

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

टीसीपी / आईपी मुद्दे

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

सभी में, एक खराब कनेक्शन के साथ एक विशिष्ट टीसीपी / आईपी आधारित रीस्ट एपीआई की समस्याएं:

• पैकेट नुकसान की खराब प्रतिक्रिया (तेज गति में कमी, बड़े समय के अंतराल)
• कनेक्शन स्थापित करने के लिए पैकेट एक्सचेंज (+3 पैकेट) की आवश्यकता होती है
• IP सर्वर (+2 पैकेट) का पता लगाने के लिए अक्सर आपको "अतिरिक्त" DNS क्वेरी की आवश्यकता होती है
• अक्सर टीएलएस (न्यूनतम 2 पैकेट) की आवश्यकता होती है

कुल मिलाकर, इसका मतलब है कि केवल सर्वर से कनेक्ट करने के लिए हमें 3-7 पैकेट भेजने की आवश्यकता होती है, और उच्च प्रतिशत नुकसान के साथ, कनेक्शन एक महत्वपूर्ण राशि ले सकता है, और हमने अभी तक कुछ भी नहीं भेजा है।

कार्यान्वयन का विचार

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

उत्पादन-तैयार कार्यान्वयन के लिए संभावित नुकसान

निम्नलिखित चीजें हैं (बिना किसी मतलब के) उन सभी चीज़ों के बारे में जिन्हें आपको "मुकाबला" स्थितियों में इस तरह से उपयोग करने से पहले सोचने की ज़रूरत है:

1. प्रदाता द्वारा यूडीपी को "कट" किया जा सकता है - आपको टीसीपी / आईपी पर काम करने में सक्षम होना चाहिए
2. UDP NAT के साथ दोस्ताना नहीं है - आमतौर पर क्लाइंट अनुरोध का जवाब देने के लिए बहुत कम (~ 30 सेकंड) समय होता है
3. सर्वर को हमले हासिल करने के लिए प्रतिरोधी होना चाहिए - आपको यह सुनिश्चित करने की आवश्यकता है कि प्रतिक्रिया पैकेट अनुरोध पैकेट से अधिक नहीं है
4. एन्क्रिप्शन मुश्किल है, और यदि आप एक सुरक्षा विशेषज्ञ नहीं हैं, तो आपके पास इसे सही तरीके से लागू करने की बहुत कम संभावना है
5. यदि आप गलत तरीके से रिट्रांसमिशन अंतराल सेट करते हैं (उदाहरण के लिए, हर सेकंड दोबारा प्रयास करने के बजाय, फिर से बिना रुके कोशिश करना), तो आप टीसीपी / आईपी से बहुत खराब कर सकते हैं
6. यूडीपी और अंतहीन रिट्रीट में फीडबैक न होने के कारण आपके ट्रैफ़िक में अधिक ट्रैफ़िक आना शुरू हो सकता है
7. सर्वर में कई आईपी पते हो सकते हैं, और वे समय के साथ बदल सकते हैं, इसलिए आपको कैश को अपडेट करने में सक्षम होने की आवश्यकता है (टेलीग्राम अच्छी तरह से काम करता है :))

कार्यान्वयन

हम एक सर्वर लिखेंगे जो यूडीपी के माध्यम से एक प्रतिक्रिया देगा और प्रतिक्रिया में भेजेगा अनुरोध की संख्या जो इसे आई थी (अनुरोध "अनुरोध-पाठ संदेश जैसा दिखता है"), साथ ही प्रतिक्रिया प्राप्त करने का टाइमस्टैम्प भी:

//  Go. //      buf := make([]byte, maxUDPPacketSize) //   UDP addr, _ := net.ResolveUDPAddr("udp", fmt.Sprintf("0.0.0.0:%d", serverPort)) conn, _ := net.ListenUDP("udp", addr) for { //   UDP,      n, uaddr, _ := conn.ReadFromUDP(buf) req := string(buf[0:n]) parts := strings.SplitN(req, " ", 2) //          curTs := time.Now().UnixNano() clientTs, _ := strconv.Atoi(parts[0]) //       -      //   conn.WriteToUDP([]byte(fmt.Sprintf("%d %d", curTs, clientTs)), uaddr) } 

अब मुश्किल हिस्सा ग्राहक है। हम एक बार में एक संदेश भेजेंगे और अगले भेजने से पहले सर्वर के जवाब की प्रतीक्षा करेंगे। हम वर्तमान टाइमस्टैम्प और पाठ का एक टुकड़ा भेजेंगे - टाइमस्टैम्प अनुरोध पहचानकर्ता के रूप में काम करेगा।

 //   addr, _ := net.ResolveUDPAddr("udp", fmt.Sprintf("%s:%d", serverIP, serverPort)) conn, _ := net.DialUDP("udp", nil, addr) //  UDP      ,     . resCh := make(chan udpResult, 10) go readResponse(conn, resCh) for i := 0; i < numMessages; i++ { requestID := time.Now().UnixNano() send(conn, requestID, resCh) } 

फ़ीचर कोड:

 func send(conn *net.UDPConn, requestID int64, resCh chan udpResult) { for { //     ,       . conn.Write([]byte(fmt.Sprintf("%d %s", requestID, testMessageText))) if waitReply(requestID, time.After(time.Second), resCh) { return } } } //   ,  . //      ,   ,   // ,        , //   . func waitReply(requestID int64, timeout <-chan time.Time, resCh chan udpResult) (ok bool) { for { select { case res := <-resCh: if res.requestTs == requestID { return true } case <-timeout: return false } } } //    type udpResult struct { serverTs int64 requestTs int64 } //           . func readResp(conn *net.UDPConn, resCh chan udpResult) { buf := make([]byte, maxUDPPacketSize) for { n, _, _ := conn.ReadFromUDP(buf) respStr := string(buf[0:n]) parts := strings.SplitN(respStr, " ", 2) var res udpResult res.serverTs, _ = strconv.ParseInt(parts[0], 10, 64) res.requestTs, _ = strconv.ParseInt(parts[1], 10, 64) resCh <- res } } 

मैंने (कमोबेश) मानक REST के आधार पर भी यही बात लागू की: HTTP POST का उपयोग करते हुए हम एक ही रिक्वेस्ट और मैसेज टेक्स्ट भेजते हैं और प्रतिक्रिया की प्रतीक्षा करते हैं, फिर अगले एक पर जाते हैं। डोमेन नाम से अपील की गई थी, सिस्टम में DNS कैशिंग निषिद्ध नहीं था। तुलना को अधिक ईमानदार बनाने के लिए HTTPS का उपयोग नहीं किया गया था (प्रोटोटाइप में कोई एन्क्रिप्शन नहीं है)। टाइमआउट 15 सेकंड पर सेट किया गया था: टीसीपी / आईपी में पहले से ही खोए हुए पैकेटों को अग्रेषित किया गया है, और उपयोगकर्ता को संभवतः 15 सेकंड से ज्यादा इंतजार नहीं करना होगा।

परीक्षण, परिणाम

प्रोटोटाइप का परीक्षण करते समय, निम्नलिखित चीजों को मापा गया (सभी मिलीसेकंड में ):

1. पहली प्रतिक्रिया समय (पहले)
2. औसत प्रतिक्रिया समय (औसत)
3. अधिकतम प्रतिक्रिया समय (अधिकतम)
4. एचडी / यू - अनुपात "एचटीटीपी समय" / "यूडीपी समय" - यूडीपी का उपयोग करते समय कितनी बार कम देरी

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

संचार के परीक्षण के प्रकार:

1. प्रोफ़ाइल "बहुत बुरा नेटवर्क" (10% हानि, 500 एमएस विलंबता, 1 एमबीपीएस) नेटवर्क लिंक कंडीशनर में - "बहुत खराब"
2. EDGE, फ्रिज में टेलीफोन ("एलेवेटर") - फ्रिज
3. एज
4. 3 जी
5. एलटीई
6. वाई-फाई

परिणाम (मिलीसेकंड में समय):

( सीएसवी प्रारूप में भी )

निष्कर्ष

यहां नतीजे दिए जा सकते हैं।

1. एलटीई विसंगति के अलावा, पहला संदेश भेजने में अंतर अधिक से अधिक है, खराब कनेक्शन (औसतन, 2-3 बार तेजी से)
2. इसके बाद HTTP में संदेश भेजना ज्यादा धीमा नहीं है - औसतन 1.3 गुना धीमा, लेकिन स्थिर वाई-फाई पर कोई अंतर नहीं है
3. UDP- आधारित प्रतिक्रिया समय बहुत अधिक स्थिर है, जो अप्रत्यक्ष रूप से अधिकतम विलंबता द्वारा देखा जाता है - यह भी 1.4-1.8 गुना कम है

दूसरे शब्दों में, उचित ("खराब") स्थितियों के तहत, हमारा प्रोटोकॉल बहुत बेहतर काम करेगा, खासकर जब पहला संदेश भेज रहा हो (अक्सर यह सब भेजा जाना चाहिए)।

प्रोटोटाइप कार्यान्वयन

प्रोटोटाइप गितुब पर पोस्ट किया गया है । उत्पादन में इसका उपयोग न करें!

फोन या कंप्यूटर पर क्लाइंट शुरू करने की आज्ञा:

 instant-im -client -num 10 

। सर्वर अभी भी चल रहा है :)। पहले उत्तर के समय, साथ ही अधिकतम देरी पर सबसे पहले देखना आवश्यक है। यह सारा डेटा आखिर में छपा है।