🥇हामीले कसरी ग्रेट फायरवाल अफ चाइना तोड्यौं (भाग १)

नमस्कार!

निकिता सम्पर्कमा छ - कम्पनीबाट प्रणाली इन्जिनियर SEMrush। आज म तपाईंलाई चीनमा हाम्रो semrush.com सेवाको स्थिरता सुनिश्चित गर्ने कार्यको सामना कसरी गर्यौं, र यसको कार्यान्वयनको क्रममा हामीले कस्ता समस्याहरू सामना गर्‍यौं (संयुक्त राज्य अमेरिकाको पूर्वी तटमा हाम्रो डाटा सेन्टरको स्थान दिएर) बारे बताउनेछु।

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

चिनियाँ इन्टरनेटको समस्या

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

यस फायरवालको बारेमा धेरै अफवाहहरू छन्। तिनीहरूमध्ये मुख्य र सबैभन्दा रोचकलाई एउटा सूचीमा सङ्कलन गरौं:

गुगल, फेसबुक, ट्विटर र अन्य समान सेवाहरू अवरुद्ध छन् र चीनमा काम गर्दैनन्।
चीन बाहिर र चीन भित्र जाने कुनै पनि ट्राफिकलाई मेसिन लर्निङ (संदिग्ध ट्राफिकको मामलामा) प्रयोग गरेर पार्स गरिएको छ र सीमित छ, जसले यसलाई (ट्राफिक) सीमाबाट गुज्रिरहेको छ।
चिनियाँ गुप्तचर एजेन्सीहरूले आफ्नो फायरवालबाट गुज्रने कुनै पनि इन्क्रिप्टेड ट्राफिक ह्याक गर्नेछन्।
VPN टनेलहरू, IPSEC टनेलहरू अस्थिर छन्, दुर्घटनाग्रस्त छन् र लगातार अवरुद्ध छन्।
इन्क्रिप्सन जति सरल हुन्छ, ट्राफिकलाई प्रमाणीकरण/इन्क्रिप्ट गर्न प्रयोग गरिने पास वाक्यांश जति छिटो हुन्छ, चिनियाँ फायरवाल मार्फत छिटो जान्छ।

यहाँ हामीले यी अफवाहहरूको बारेमा के फेला पार्‍यौं:

Google, Facebook, Twitter र अन्य समान सेवाहरू साँच्चै अवरुद्ध छन् (तपाईंको KO), तर धेरै प्राविधिक Google डोमेनहरू, उदाहरणका लागि, प्रतिबन्धित छैनन् र काम गर्दछ (उही gstatic.com)। यसबाट निष्कर्ष निस्कन्छ: तपाईंले लापरवाहीपूर्वक सबै गुगल र अन्य स्रोतहरू काट्नु हुँदैन जुन अवरुद्ध देखिन्छ।
सीमा पार गर्ने कुनै पनि ट्राफिकले यसको समयमा गम्भीर ढिलाइ थप्छ। दुई नतिजाहरू हेर्नुहोस्। एक साइट, एक पृष्ठ, सरल GET दोब्र्याइएको'ओम। पहिलो मापन चीनबाट नै थियो (शेन्जेनको सुन्दर शहर)। दोस्रो हङकङबाट बाहिरबाट मापन गरिएको थियो (यसको सार्वभौमिकता छ, र यो र संसारको बीचमा कुनै फायरवाल छैन)। सीधा रेखामा शहरहरू बीचको दूरी लगभग 30-40 किलोमिटर छ।

nikita@china-shenzhen:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  381k    0  381k    0     0  71824      0 --:--:--  0:00:05 --:--:-- 82832
time_namelookup:  0.004500
time_connect:  0.169342
time_appconnect:  0.723189
time_pretransfer:  0.723499
time_redirect:  0.000000
time_starttransfer:  1.532912
----------
time_total:  5.443407
----------
size_download:  390968 Bytes
speed_download:  71824.000B/s

nikita@china-hongkong:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  319k    0  319k    0     0  2555k      0 --:--:-- --:--:-- --:--:-- 2573k
time_namelookup:  0.029366
time_connect:  0.030742
time_appconnect:  0.047310
time_pretransfer:  0.047388
time_redirect:  0.000000
time_starttransfer:  0.120793
----------
time_total:  0.124871
----------
size_download:  326755 Bytes
speed_download:  2616740.000B/s

ध्यान दिनुहोस् समय_जडान। र सामान्यतया, तपाईंले परिणाम देख्नुहुन्छ: फायरवालले 4 अतिरिक्त सेकेन्ड थप्छ, जुन राक्षसी रूपमा लामो छ।

VPN र IPSEC सुरुङहरू प्रायः असफल हुन्छन्। म यस बारेमा केहि पछि र थप विवरणमा कुरा गर्नेछु। प्रयोगकर्ताहरूद्वारा प्रयोग गरिएका VPN सर्भरहरू समयसँगै अवरुद्ध हुन्छन् (सामान्यतया प्रयोग सुरु भएको एक दिन भित्र)।
ट्राफिकको इन्क्रिप्शन जति सरल हुन्छ, त्यति नै चाँडो सिमानाबाट गुज्रिन्छ, किनभने यसमा गैरकानूनी केही छैन भन्ने बुझ्न सजिलो हुन्छ भन्ने राय चीनमा बसोबास गर्नेहरूबाट प्राप्त भएको छ। र त्यसै गरी, "स्वच्छ" ट्राफिकले अधिक ब्यान्डविथ र मार्गको गति प्राप्त गर्दछ, जबकि "फोहोर" ट्राफिक, जसमा केहि पनि बुझ्न सकिदैन, यसको विपरीत, एक ढिलो मार्ग प्राप्त गर्दछ। उदाहरण को लागी म curl to प्रयोग गर्नेछु ifconfig.co मार्फत HTTPS र HTTP प्रोटोकल मार्फत।

curl -o /dev/null -w@curl_time "https://ifconfig.co/"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    13  100    13    0     0      2      0  0:00:06  0:00:05  0:00:01     3
time_namelookup:  0.004305
time_connect:  0.397465
time_appconnect:  5.149305
time_pretransfer:  5.149393
time_redirect:  0.000000
time_starttransfer:  5.568847
----------
time_total:  5.568893
----------
size_download:  13 Bytes
speed_download:  2.000B/s

curl -o /dev/null -w@curl_time "http://ifconfig.co/"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    13  100    13    0     0     28      0 --:--:-- --:--:-- --:--:--    28
time_namelookup:  0.004282
time_connect:  0.212457
time_appconnect:  0.000000
time_pretransfer:  0.212484
time_redirect:  0.000000
time_starttransfer:  0.450565
----------
time_total:  0.450620
----------
size_download:  13 Bytes
speed_download:  28.000B/s

१३ बाइटको कुल डाउनलोड समयको लागि ५ सेकेन्डको भिन्नता। यसबाहेक, धेरै पटक यस्तो परीक्षण गर्दा, तपाईले देख्न सक्नुहुन्छ कि HTTP मा GET सामान्यतया प्रत्येक पटक एकै समयमा पूरा हुन्छ, जबकि HTTPS मा साइटले कहिलेकाहीँ 5, 13, 3 र 5 सेकेन्डमा पनि प्रतिक्रिया दिन्छ। कहिलेकाहीँ SSL त्रुटिहरू हुन्छन्:

Unknown SSL protocol error in connection to ifconfig.co:443.

त्यसोभए हामीसँग के छ:

चिनियाँ फायरवालद्वारा सिर्जना गरिएका समस्याहरू माथि वर्णन गरिएका छन्।
बाह्य स्रोतहरू र भित्री सुरुङहरूमा पिङहरू आवधिक रूपमा गायब हुन्छन्।
दुई बिन्दुहरू बीचको विलम्बता निरन्तर परिवर्तन हुँदैछ, र प्रायः यो अप्रत्याशित हुन्छ। विभिन्न सहर/क्षेत्रहरू जडान गर्दा, तपाइँ क्षेत्रहरूको भौगोलिक स्थानको आधारमा, ढिलाइ कम हुनेछ भन्ने आशा गर्नुहुन्छ, तर तपाइँ ठ्याक्कै उल्टो स्थिति पाउनुहुन्छ।
इन्टरनेट र सञ्चार च्यानलहरू या त छिटो वा ढिलो छन्। दिन र हप्ताको दिनमा थोरै निर्भरता छ, तर सधैं होइन।
चीनबाट बाहिरी संसारमा DNS अनुरोधहरू कहिलेकाहीँ अनुमति दिइएको समय समाप्ति भन्दा बढी हुन्छन्।

उदीयमान चित्र केवल "उत्कृष्ट" हो।

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

हामीले एउटा महत्त्वपूर्ण प्रश्नको जवाफ दिनुपर्‍यो: के यो थोरै खर्चमा प्राप्त गर्न र सञ्जाल/क्लाउड/सर्भर स्तरमा चिनियाँ इन्टरनेट र फायरवालसँग सम्बन्धित सबै समस्याहरू समाधान गर्न सम्भव छ?

हामीले प्राप्त गरेर सुरु गर्यौं ICP- लाइसेन्स.

ICP लाइसेन्स

चीन (मेनल्याण्ड चीन) भित्र आफ्नो सेवा होस्ट गर्न र परीक्षणहरू सञ्चालन गर्न सक्षम हुनको लागि, तपाईंले पहिले डोमेनको लागि ICP इजाजतपत्र प्राप्त गर्नुपर्छ।

यदि तपाईंको साइटको प्रयोगकर्ता ट्राफिक मेनल्याण्ड चीन भित्र समाप्त भएको छ, र यदि तपाईंको डोमेनसँग ICP इजाजतपत्र छैन भने, तपाईंको ट्राफिक ISP/होस्टिङ साइडमा रोकिनेछ। चाखलाग्दो कुरा के छ भने, ICP इजाजतपत्रमा एक विशिष्ट प्रदायक समावेश छ, यो Cloudflare वा Alibaba Cloud। त्यसकारण, यदि तपाईंले क्लाउडफ्लेयरको लागि ICP इजाजतपत्र प्राप्त गर्नुभयो र तिनीहरूसँग आफ्नो वेबसाइट होस्ट गर्नुभयो भने, तपाईं अलिबाबा क्लाउडमा "सिमलेस" सार्न सक्षम हुनुहुने छैन। तपाईंले यो इजाजतपत्रमा अर्को होस्टिङ थप्नु पर्ने हुन्छ।

डोमेनको लागि ICP लाइसेन्स प्राप्त गरेपछि, हामीले विशिष्ट प्राविधिक विचारहरू र समाधानहरू ल्याउन र कार्यान्वयन गर्न सक्षम भयौं।

परीक्षण समाधानहरू

तर तपाईंले सीधै स्टेजिङ विकल्पहरू सिर्जना गर्नु अघि, घुँडाहरू घुमाउनुहोस्, साइटको कार्यसम्पादन र यसको गतिलाई अनुकूलन गर्नुहोस्, तपाईंले हाम्रो कुन कार्यहरू सुधार गर्न वा यसको विपरित, साइटको कार्यसम्पादनलाई बिग्रन्छ भनेर हेर्नको लागि परीक्षणको लागि एउटा उपकरण छनोट गर्न आवश्यक छ।

हाम्रो परीक्षण उपकरणले दुई मुख्य आवश्यकताहरू पूरा गर्नुपर्ने थियो:

यो चीनबाट परीक्षण चलाउन सक्षम हुनुपर्छ,
यो ब्राउजर परीक्षण हुनुपर्छ।

त्यसैले हामीले फेला पार्यौं CatchPoint! तिनीहरूसँग विश्वभरि परीक्षण स्थानहरूको उत्कृष्ट कभरेज छ। चीनमा यो उपकरण मार्फत एक लाख ५०० प्रान्तबाट पनि परीक्षण गर्न सकिन्छ। प्रत्येकसँग धेरै फरक प्रदायकहरू छन् + गर्ने क्षमता ब्याक बटन-परीक्षणहरू (डेटा केन्द्रमा भर्चुअल मेसिन जस्तै) र लास्टमेल-परीक्षणहरू (प्रयोगकर्ता सर्तहरूमा सकेसम्म नजिक, उर्फ वर्कस्टेशन)। पछिल्लो प्रकारको परीक्षण बढी महँगो छ।

वार्षिक सम्झौता (त्यो भन्दा कम सम्भव छैन) निष्कर्षमा, हामीले उपकरण अध्ययन गर्न थाले। साँच्चै, हामी यसको कार्यक्षमता द्वारा सुखद आश्चर्यचकित भयौं। तपाईं चलाउन सक्नुहुन्छ:

DNS परीक्षण,
वेब परीक्षणहरू (ब्राउजर परीक्षणहरू, साधारण GET/POST, मोबाइल ग्राहक इमुलेशन, आदि),
लेनदेन जाँचहरू (उदाहरणका लागि, लगइन),
API परीक्षणहरू,
पिंग, ट्रेसराउट, NTP, आदि।

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

जडान गर्नुहोस्, पर्खनुहोस्, लोड गर्नुहोस्, SSL, DNS समय,
TTFB, TTLB, कागजात पूरा, रेन्डर समय, DOM लोड,
प्रतिक्रिया (पहिलो बाइटको लागि समयको नजिक केही), वेबपेज प्रतिक्रिया (केही समय अन्तिम बाइटको नजिक),
कुनै पनि प्रतिशत, औसत, माध्य समय
आदि।

तदनुसार, यी सबै मेट्रिकहरू परिवर्तनहरू हेर्न र चीजहरू राम्रो भएका छन् कि भनेर बुझ्नको लागि उत्कृष्ट छन्। हामीले मुख्यतया हेर्यौं प्रतिक्रिया, वेबपेज प्रतिक्रिया, माध्य, 75 र 95 प्रतिशत.

सुरुदेखि नै हावामा रहेको एउटा महत्त्वपूर्ण प्रश्नः तपाईं क्याचपोइन्टमा भरोसा गर्न सक्नुहुन्छ?? के यो उपकरणले चीनमा विभिन्न शहरहरूबाट वास्तविक साइट लोडिङ गतिलाई प्रतिबिम्बित गर्दछ, वा यो भ्याकुममा केही प्रकारको परीक्षण मात्र हो जुन वास्तविक प्रयोगकर्ता अनुभवसँग कुनै सरोकार छैन?
यो एउटा ठूलो समस्या हो, किनकि रूसमा भएकोले चीनबाट आएको साइटले कसरी काम गर्छ भनी पत्ता लगाउन लगभग असम्भव छ। भर्चुअल मेसिन मार्फत मोजा-प्रोक्सी गरेर, अन्तिम नतिजा यो हो कि साइट केहि मिनेट भित्र लोड हुन्छ, जुन केवल परीक्षणको लागि अस्वीकार्य छ, त्यसैले म्यानुअल परीक्षणको लागि एकमात्र विकल्प कर्ल र टाइमरको साथ कन्सोलबाट साधारण GET हो। । यसले मद्दत गर्दछ किनभने यो परीक्षणले नेटवर्क समाधानको गतिलाई राम्रोसँग प्रतिबिम्बित गर्दछ, र यदि त्यहाँ ब्राउजर परीक्षणहरू पनि छन् भने, यो धेरै राम्रो छ।

पछि हामी आफै चीन गएर त्यसमा विश्वस्त भयौं तपाईं क्याचपोइन्टमा विश्वास गर्न सक्नुहुन्छ; यसले वास्तविक कार्यसम्पादन सूचकहरूलाई सही रूपमा प्रतिबिम्बित गर्दछ।

Cloudflare चीन नेटवर्क

हामीले मुख्य डोमेन semrush.com को लागि Cloudflare सफलतापूर्वक प्रयोग गरेको हुनाले, हामीले तुरुन्तै तिनीहरूको सुविधा प्रयोग गर्ने निर्णय गर्यौं। चीन नेटवर्क। यो विकल्प इन्टरप्राइज साइटहरूको लागि मात्र अलग अनुरोधमा र अतिरिक्त शुल्कको लागि सक्षम गरिएको छ। यो Cloudflare लाई प्रदायकको रूपमा सूचीबद्ध गर्ने उपयुक्त ICP इजाजतपत्र भएका साइटहरूमा मात्र उपलब्ध छ। यसलाई सक्षम गरेपछि, क्लाउडफ्लेयरबाट "चिनियाँ CDN" साइटको लागि उपलब्ध हुन्छ - चिनियाँ क्षेत्रहरूबाट ट्राफिक निकटतम PoP (पोइन्ट अफ प्रेजेन्स) CF मा अवतरण हुन्छ, र त्यसपछि यसको नेटवर्कहरू वा प्रदायकहरू/साझेदारहरूको नेटवर्कहरू मार्फत यो उत्पत्तिमा डेलिभर गरिन्छ। ।

यस परीक्षण बेन्चको रेखाचित्र तल प्रस्तुत गरिएको छ।

यो हाम्रो लागि उत्कृष्ट विकल्प हो। यो बाहिर जान्छ कि दोस्रो डोमेन पनि CF को लागी हुनेछ, जसले कम्पनीमा प्रयोग गरिएका समाधानहरूको संख्यामा थप्दैन, र व्यावहारिक रूपमा पूर्वाधारलाई जटिल बनाउँदैन।

हामीले ब्राउजर परीक्षणहरू चलायौं र यो के भयो:

रातो हीराहरू परीक्षण असफल हुन्छन्। तलका फाइलहरू DNS त्रुटिहरू हुन् (समाप्ति समाधान गर्नुहोस्)। शीर्षमा असफलताहरू टाइमआउटहरू हुन्।

अपटाइम: ०.९९९९
माध्य: 18s
७५ प्रतिशत: २९.३ सेकेन्ड
७५ प्रतिशत: २९.३ सेकेन्ड

मध्यम, लोड गरिसकेपछि हटाइयो reCAPTCHA (चीनमा गुगल सेवा अवरुद्ध) २८ बाट १८ सेकेन्डमा घट्यो। तर यी अझै पनि भयानक नतिजाहरू छन्, विचार गर्दै कि semrush.com (US बाट) को लागि समान परीक्षणले 28% प्रयोगकर्ताहरू (US बाट) उही पृष्ठमा (स्थिर + गतिशील) को लागि 18 सेकेन्ड भन्दा कम समय दिए।

तपाईं प्रत्येक परीक्षणमा जान सक्नुहुन्छ र हेर्न सक्नुहुन्छ झरना र अन्य थप विस्तृत प्यारामिटरहरू। हामीले त्रुटिहरूको कारणहरू खोज्न थाल्यौं, र यदि टाइमआउटको लागि सबै कुरा कम वा कम स्पष्ट छ: चीनमा इन्टरनेट "इन र बाहिर जान्छ", यस कारणले गर्दा विदेशबाट जडानको गति र स्रोतहरू लोड गर्ने गति अस्थिर र असमान छ, त्यसपछि DNS त्रुटिहरूले हामीलाई धेरै छक्क पार्यो। हामीले त्यो भेट्टायौं पी पी क्लाउडफ्लेयर वास्तवमा चीनमा अवस्थित छन्, साइट ठेगानाले कुनै पनि कास्ट आईपीमा समाधान गर्दछ, तर DNS सर्भरहरू अमेरिकी हुन्, त्यसैले DNS अनुरोधहरू सीमा पार गर्न बाध्य हुन्छन्, त्यसैले कहिलेकाहीँ तिनीहरू असफल हुन्छन्।

CF सँग यो प्रश्न स्पष्ट गरेपछि, यो बाहिरियो तिनीहरूसँग चीनमा आफ्नै DNS सर्भरहरू छैनन्, र यो कहिले हुनेछ अझै अज्ञात छ।

त्यसकारण, हामीले क्लाउडफ्लेयर DNS मात्र परीक्षण गर्ने निर्णय गर्यौं र हाम्रो साइटको लागि क्लाउडफ्लेयर अपरेटिङ मेकानिजमलाई "DNS मात्र" यो एक मोड हो जब क्लाउडफ्लेयर आफैं मार्फत ट्राफिक प्रोक्सी गर्दैन, जसको मतलब यसले DDoS सुरक्षा, CDN र अन्य सुविधाहरू प्रदान गर्दैन, र नियमित DNS सर्भरको मोडमा सञ्चालन गर्दछ।

यो स्ट्यान्डलाई निम्न चित्रमा योजनाबद्ध रूपमा देखाइएको छ। फिगरले क्लाउडफ्लेयरको DNS सर्भरहरू फायरवाल पछाडि रहेको उभरिरहेको ज्ञानलाई ध्यानमा राख्छ।

क्याचपोइन्टमा हामीले साधारण GET परीक्षणहरू दौड्यौं (ब्राउजर परीक्षणहरू होइन), जसले धेरै असफलताहरू देखायो। तिनीहरू समान DNS त्रुटिहरूको कारणले गर्दा भएको थियो।

हामीले यी त्रुटिहरू प्रयोग गरेर डिबग गर्न थाल्यौं खोल्नुहोस् र पहिलो अनुरोधमा ठेगाना सही रूपमा निर्धारण गरिएको छ, र दोहोर्याइएको अनुरोधमा हामी प्रत्येक पटक प्राप्त गर्छौं सर्भफेल и फेला परेन। यो अचानक किन भइरहेको छ?

root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn has address 220.170.186.192
Host semrushchina.cn not found: 2(SERVFAIL)

क्लाउडफ्लेयर एनएस सर्भरहरू सीधा क्वेरी गर्दा, त्यहाँ कुनै त्रुटिहरू छैनन्:

root@iZwz97n2wgbp61qucbfrjsZ:~# for i in `seq 1 2`; do host semrushchina.cn ray.ns.cloudflare.com.; done
Using domain server:
Name: ray.ns.cloudflare.com.
Address: 173.245.59.138#53
Aliases: 

semrushchina.cn has address 220.170.186.192
semrushchina.cn has address 220.170.186.192
Using domain server:
Name: ray.ns.cloudflare.com.
Address: 173.245.59.138#53
Aliases: 

semrushchina.cn has address 220.170.186.192
semrushchina.cn has address 220.170.186.192

यसको मतलब यो समस्या "स्थानीय" DNS सर्भर वा प्रदायकको सर्भरको छेउमा छ।
थप अनुसन्धानले यस्तो खुलासा गरेको हो सर्भफेल हामी संकल्पमा जान्छौं AAAA- रेकर्डहरू।

Cloudflare बाट अनुरोध गर्दा यो बाहिर भयो AAAA-रेकर्ड जुन डोमेनमा अवस्थित छैन, क्लाउडफ्लेयरले प्रतिक्रिया दियो А- एक प्रविष्टि जुन त्रुटि र RFC संग गैर-अनुपालन हो। किन स्थानीय समाधानकर्ता (xxxx) मलाई यो मन परेन, र उसले जवाफ दियो सर्भफेल। यो व्यवहार तल लग मा स्पष्ट देखिने छ:

root@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @x.x.x.x

; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t AAAA semrushchina.cn @x.x.x.x
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 55467
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;semrushchina.cn.               IN      AAAA

;; Query time: 334 msec
;; SERVER: x.x.x.x#53(x.x.x.x)
;; WHEN: Tue Aug 14 23:38:50 CST 2018
;; MSG SIZE  rcvd: 44

root@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @dana.ns.cloudflare.com.

; <<>> DiG 9.10.3-P4-Ubuntu <<>> -t AAAA semrushchina.cn @dana.ns.cloudflare.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63944
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;semrushchina.cn.               IN      AAAA

;; ANSWER SECTION:
semrushchina.cn.        300     IN      A       220.170.186.192

;; Query time: 185 msec
;; SERVER: 173.245.58.105#53(173.245.58.105)
;; WHEN: Tue Aug 14 23:43:03 CST 2018
;; MSG SIZE  rcvd: 60

हामीले क्लाउडफ्लेयरमा बग रिपोर्ट पेश गर्यौं, र तिनीहरूले केही समय पछि यसलाई ठीक गरे। यो चाखलाग्दो भयो: यस समयमा चीनमा अझै पनि IPv6 समर्थन छैन, त्यसैले क्लाउडफ्लेयरले अनुरोधको जवाफमा त्यहाँ आफ्नो IPv6 ठेगाना जारी गर्न सकेन। AAAA- रेकर्डहरू। अन्तमा, सबै कुरा यसरी हल भयो कि क्लाउडफ्लेयरले चीनको लागि जवाफ दिन थाल्यो डाटा छैन त्यस्ता अनुरोधहरूमा।

यसरी, क्याचपोइन्ट परीक्षणहरूमा DNS त्रुटिहरू तीव्र रूपमा घट्यो, तर पूर्ण रूपमा होइन। टाइमआउटहरू अझै यहाँ छन्:

अनि हामीले अर्को समाधान खोज्न थाल्यौं।

अर्को भागमा म तपाईलाई बताउनेछु कि हामीले कसरी चिनियाँ क्लाउडको परीक्षण गर्यौं अल्बाबा क्लाउड, कसरी, Nginx को सानो "जादू" को मद्दतले, हामी चाँडै PoC (प्रूफ अफ कन्सेप्ट) समाधानहरू सिर्जना गर्न सक्षम भयौं, हामीले कसरी बहु-क्लाउड समाधानहरू सिर्जना गर्यौं, जसमध्ये एउटाले अन्ततः सेवाको कामको गति बढाउन मद्दत गर्‍यो। चीनबाट।

रहनुहोस्!