Hello!
ติดต่อ Nikita - วิศวกรระบบจากบริษัท SEMrush- วันนี้ฉันจะบอกคุณเกี่ยวกับวิธีที่เราเผชิญกับงานในการรับรองเสถียรภาพของบริการ semrush.com ของเราในประเทศจีน และปัญหาใดบ้างที่เราพบระหว่างการใช้งาน (พิจารณาจากที่ตั้งของศูนย์ข้อมูลของเราบนชายฝั่งตะวันออกของสหรัฐอเมริกา)
นี่จะเป็นเรื่องใหญ่แบ่งออกเป็นหลายบทความ ฉันจะบอกคุณว่ามันเกิดขึ้นได้อย่างไรสำหรับเรา: จากบริการที่ไม่สามารถใช้งานได้อย่างสมบูรณ์จากประเทศจีนไปจนถึงตัวบ่งชี้ประสิทธิภาพของบริการในระดับเวอร์ชันอเมริกันสำหรับชาวอเมริกัน ฉันสัญญาว่ามันจะน่าสนใจและมีประโยชน์ งั้นไปกัน.
ปัญหาอินเตอร์เน็ตของจีน
แม้แต่บุคคลที่อยู่ไกลจากลักษณะเฉพาะของการบริหารเครือข่ายที่สุดก็ยังเคยได้ยินมา ไฟร์วอลล์ที่ยิ่งใหญ่ของจีน- ว้าว ฟังดูเท่ใช่ไหมล่ะ? แต่มันคืออะไรและมันทำงานอย่างไรจริง ๆ นั้นเป็นคำถามที่ค่อนข้างซับซ้อน คุณสามารถค้นหาบทความมากมายบนอินเทอร์เน็ตเกี่ยวกับเรื่องนี้ แต่จากมุมมองทางเทคนิค โครงสร้างของไฟร์วอลล์นี้ไม่ได้อธิบายไว้ที่ใดเลย ซึ่งอย่างไรก็ตามก็ไม่น่าแปลกใจเลย ฉันจะยอมรับทันทีว่าจากผลงานในหนึ่งปี ฉันจะไม่สามารถบอกได้อย่างแน่ชัดว่ามันทำงานอย่างไร แต่ฉันสามารถบอกคุณเกี่ยวกับความคิดเห็นและข้อสรุปเชิงปฏิบัติของฉันได้ และเราจะเริ่มต้นด้วยข่าวลือเกี่ยวกับไฟร์วอลล์นี้
มีข่าวลือมากมายเกี่ยวกับไฟร์วอลล์ตัวนี้ รวบรวมหลักและน่าสนใจที่สุดไว้ในรายการเดียว:
- Google, Facebook, Twitter และบริการอื่นที่คล้ายคลึงกันถูกบล็อกและใช้งานไม่ได้ในประเทศจีน
- การรับส่งข้อมูลใด ๆ ที่ออกไปนอกประเทศจีนและเข้าสู่ประเทศจีนจะถูกแยกวิเคราะห์และจำกัดโดยใช้การเรียนรู้ของเครื่อง (ในกรณีของการรับส่งข้อมูลที่น่าสงสัย) ซึ่งจะทำให้การรับส่งข้อมูลช้าลงอย่างมาก (การรับส่งข้อมูล) ที่ผ่านชายแดน
- หน่วยข่าวกรองจีนจะแฮ็กการรับส่งข้อมูลที่เข้ารหัสผ่านไฟร์วอลล์ของตน
- อุโมงค์ VPN, อุโมงค์ IPSEC ไม่เสถียร ขัดข้อง และถูกบล็อกอยู่ตลอดเวลา
- ยิ่งการเข้ารหัสง่ายขึ้น วลีรหัสผ่านที่ใช้ในการตรวจสอบสิทธิ์/เข้ารหัสการรับส่งข้อมูลก็จะยิ่งผ่านไฟร์วอลล์จีนได้เร็วยิ่งขึ้น
นี่คือสิ่งที่เราพบเกี่ยวกับข่าวลือเหล่านี้:
- Google, Facebook, Twitter และบริการอื่นที่คล้ายคลึงกันถูกบล็อกจริงๆ (KO ของคุณ) แต่โดเมนทางเทคนิคของ Google จำนวนมากไม่ได้ถูกแบนและใช้งานได้ (gstatic.com เดียวกัน) ข้อสรุปตามมาจากนี้: คุณไม่ควรตัด Google และทรัพยากรอื่น ๆ ที่ดูเหมือนจะถูกบล็อกโดยประมาท
- การจราจรใดๆ ที่ผ่านชายแดนจะทำให้เวลาล่าช้าอย่างมาก ดูผลลัพธ์ทั้งสอง หนึ่งไซต์ หนึ่งหน้า 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ความแตกต่าง 5 วินาทีสำหรับเวลาในการดาวน์โหลดทั้งหมด 13 ไบต์ ยิ่งไปกว่านั้น เมื่อทำการทดสอบหลายครั้ง คุณจะสังเกตเห็นว่า GET บน HTTP โดยทั่วไปแล้วเสร็จในเวลาเดียวกันในแต่ละครั้ง ในขณะที่บน HTTPS บางครั้งไซต์จะตอบสนองใน 3, 5, 10 และแม้กระทั่ง 17 วินาที บางครั้งข้อผิดพลาด SSL เกิดขึ้น:
Unknown SSL protocol error in connection to ifconfig.co:443.
แล้วสิ่งที่เรามี:
- ปัญหาที่สร้างโดยไฟร์วอลล์จีนมีอธิบายไว้ข้างต้น
- การ Ping ไปยังทรัพยากรภายนอกและภายในอุโมงค์จะหายไปเป็นระยะ
- เวลาแฝงระหว่างสองจุดเปลี่ยนแปลงอยู่ตลอดเวลา และบ่อยครั้งเป็นสิ่งที่คาดเดาไม่ได้ เมื่อเชื่อมต่อเมือง/ภูมิภาคต่างๆ คุณคาดหวังว่า เมื่อพิจารณาจากที่ตั้งทางภูมิศาสตร์ของภูมิภาค ความล่าช้าจะน้อยลง แต่คุณจะได้รับสถานการณ์ตรงกันข้าม
- ช่องทางอินเทอร์เน็ตและการสื่อสารมีทั้งเร็วหรือช้า มีการขึ้นอยู่กับเวลาของวันและวันในสัปดาห์เล็กน้อย แต่ก็ไม่เสมอไป
- คำขอ DNS ไปยังโลกภายนอกจากประเทศจีนบางครั้งเกินระยะหมดเวลาที่อนุญาต
ภาพที่ปรากฏก็ “ยอดเยี่ยม”
ตามที่ฉันได้กล่าวไปแล้ว ศูนย์ข้อมูลอยู่ในภาคตะวันออกของสหรัฐอเมริกา และ SEMrush ทั้งหมดประกอบด้วยผลิตภัณฑ์ที่เชื่อมต่อถึงกัน แบ็กเอนด์ ส่วนหน้า ฐานข้อมูล และทั้งหมดนี้ใน DC และคลาวด์ เราในฐานะทีมผู้ดูแลระบบ ได้รับมอบหมายให้เริ่มทำงานอย่างรวดเร็วในประเทศจีนโดยใช้ความพยายามเพียงเล็กน้อย
เราต้องตอบคำถามสำคัญ: เป็นไปได้ไหมที่จะดำเนินการโดยเสียค่าใช้จ่ายเพียงเล็กน้อยและแก้ไขปัญหาทั้งหมดที่เกี่ยวข้องกับอินเทอร์เน็ตและไฟร์วอลล์ของจีนในระดับเครือข่าย/คลาวด์/เซิร์ฟเวอร์?
เราเริ่มต้นด้วยการรับ .
ใบอนุญาตไอซีพี
เพื่อให้สามารถโฮสต์บริการของคุณภายในจีน (จีนแผ่นดินใหญ่) และดำเนินการทดสอบได้ คุณต้องได้รับใบอนุญาต ICP สำหรับโดเมนก่อน
หากการรับส่งข้อมูลผู้ใช้เว็บไซต์ของคุณถูกยกเลิกภายในจีนแผ่นดินใหญ่ และหากโดเมนของคุณไม่มีใบอนุญาต ICP การรับส่งข้อมูลของคุณจะถูกบล็อกในฝั่ง ISP/โฮสติ้ง สิ่งที่น่าสนใจคือใบอนุญาต ICP มีผู้ให้บริการเฉพาะราย ไม่ว่าจะเป็น Cloudflare หรือ Alibaba Cloud ดังนั้น หากคุณได้รับใบอนุญาต ICP สำหรับ Cloudflare และโฮสต์เว็บไซต์ของคุณด้วย คุณจะไม่สามารถย้ายไปยัง Alibaba Cloud “ได้อย่างราบรื่น” คุณจะต้องเพิ่มโฮสติ้งอื่นให้กับใบอนุญาตนี้
หลังจากได้รับใบอนุญาต ICP สำหรับโดเมนแล้ว เราก็สามารถคิดและนำแนวคิดและโซลูชันทางเทคนิคที่เฉพาะเจาะจงไปใช้ได้
โซลูชั่นการทดสอบ
แต่ก่อนที่คุณจะสร้างตัวเลือกการแสดงละครโดยตรง ให้หมุนปุ่ม ปรับประสิทธิภาพของไซต์และความเร็วของไซต์ให้เหมาะสม คุณต้องเลือกเครื่องมือสำหรับการทดสอบเพื่อดูว่าการดำเนินการใดของเราปรับปรุง หรือในทางกลับกัน ทำให้ประสิทธิภาพของไซต์แย่ลง
เครื่องมือทดสอบของเราต้องเป็นไปตามข้อกำหนดหลักสองประการ:
- มันควรจะสามารถทำการทดสอบจากประเทศจีนได้
- จะต้องมีการทดสอบเบราว์เซอร์
เราก็เลยพบว่า - พวกเขามีความครอบคลุมที่ยอดเยี่ยมของสถานที่ทดสอบทั่วโลก ในประเทศจีน การทดสอบสามารถทำได้จาก 100500 จังหวัดผ่านเครื่องมือนี้ แต่ละแห่งมีผู้ให้บริการที่แตกต่างกันหลายราย + ความสามารถที่จะทำ กระดูกสันหลัง-tests (บางอย่างเช่นเครื่องเสมือนในศูนย์ข้อมูล) และ ลาสต์ไมล์- การทดสอบ (ใกล้เคียงกับเงื่อนไขของผู้ใช้มากที่สุด หรือที่เรียกว่าเวิร์กสเตชัน) การทดสอบประเภทหลังมีราคาแพงกว่า
หลังจากสรุปสัญญารายปีแล้ว (น้อยกว่านั้นเป็นไปไม่ได้) เราจึงเริ่มศึกษาเครื่องมือนี้ จริงๆ แล้วเรารู้สึกประหลาดใจกับฟังก์ชันการทำงานของมันมาก คุณสามารถเรียกใช้:
- การทดสอบ DNS
- การทดสอบเว็บ (การทดสอบเบราว์เซอร์, GET/POST แบบง่าย, การจำลองไคลเอนต์มือถือ ฯลฯ )
- การตรวจสอบธุรกรรม (เช่น การเข้าสู่ระบบ)
- การทดสอบ API
- ปิง, Traceroute, NTP ฯลฯ
คุณไม่สามารถแสดงรายการทุกอย่างได้ และที่สำคัญที่สุด การทดสอบแต่ละครั้งสามารถปรับแต่งได้ค่อนข้างดีโดยการเพิ่มส่วนหัวและพารามิเตอร์อื่นๆ มากมาย ผลลัพธ์คือข้อมูลจำนวนมหาศาลที่อธิบายการทดสอบของคุณได้อย่างครบถ้วน หากเราพูดถึงสิ่งที่น่าสนใจที่สุดสำหรับเรา (การทดสอบเบราว์เซอร์) ผลลัพธ์จะรวมถึง:
- เชื่อมต่อ, รอ, โหลด, SSL, เวลา DNS,
- TTFB, TTLB, เอกสารเสร็จสมบูรณ์, เวลาเรนเดอร์, โหลด DOM,
- การตอบสนอง (บางอย่างใกล้เคียงกับ Time To First Byte), การตอบสนองของหน้าเว็บ (บางอย่างใกล้กับ Time To Last Byte)
- เวลาเปอร์เซ็นไทล์ เฉลี่ย ค่ามัธยฐานใดๆ
- เป็นต้น
ด้วยเหตุนี้ เมตริกทั้งหมดนี้จึงเหมาะอย่างยิ่งสำหรับการดูการเปลี่ยนแปลงและทำความเข้าใจว่าสิ่งต่างๆ ดีขึ้นหรือไม่ เราดูเป็นหลัก การตอบสนอง, การตอบสนองของหน้าเว็บ, ค่ามัธยฐาน, เปอร์เซ็นไทล์ 75 และ 95.
คำถามสำคัญที่ออกอากาศมาตั้งแต่ต้น: คุณสามารถไว้วางใจ Catchpoint ได้หรือไม่?- เครื่องมือนี้สะท้อนถึงความเร็วในการโหลดเว็บไซต์จริงในจีนจากเมืองต่างๆ หรือเป็นเพียงการทดสอบบางอย่างในสุญญากาศที่ไม่เกี่ยวข้องกับประสบการณ์ผู้ใช้จริงหรือไม่
นี่เป็นปัญหาใหญ่เนื่องจากการอยู่ในรัสเซียแทบจะเป็นไปไม่ได้เลยที่จะทราบว่าไซต์จากจีนทำงานอย่างไรได้อย่างน่าเชื่อถือ ด้วยการทำถุงเท้าพร็อกซีผ่านเครื่องเสมือน ผลลัพธ์ที่ได้คือไซต์จะโหลดภายในไม่กี่นาที ซึ่งเป็นที่ยอมรับไม่ได้สำหรับการทดสอบ ดังนั้นตัวเลือกเดียวสำหรับการทดสอบด้วยตนเองคือ curl และ GET แบบง่ายจากคอนโซลพร้อมตัวจับเวลา . ซึ่งช่วยได้เนื่องจากการทดสอบนี้สะท้อนถึงความเร็วของโซลูชันเครือข่ายได้ดี และหากมีการทดสอบเบราว์เซอร์ด้วยก็ถือว่าดีมาก
ต่อมาพวกเราเองก็ไปประเทศจีนและมั่นใจเช่นนั้น คุณสามารถไว้วางใจ Catchpoint ได้ ซึ่งสะท้อนถึงตัวบ่งชี้ประสิทธิภาพที่แท้จริงได้ค่อนข้างแม่นยำ
เครือข่าย Cloudflare ของจีน
เนื่องจากเราใช้ Cloudflare สำหรับโดเมนหลัก semrush.com ได้สำเร็จ เราจึงตัดสินใจลองใช้ฟีเจอร์ที่เรียกว่าทันที - ตัวเลือกนี้จะเปิดใช้งานเฉพาะสำหรับไซต์องค์กรเมื่อมีการร้องขอแยกต่างหากและมีค่าธรรมเนียมเพิ่มเติม นอกจากนี้ยังมีให้บริการเฉพาะไซต์ที่มีใบอนุญาต ICP ที่เหมาะสมซึ่งระบุว่า Cloudflare เป็นผู้ให้บริการ หลังจากเปิดใช้งานแล้ว "CDN จีน" จาก Cloudflare จะพร้อมใช้งานสำหรับไซต์ - การรับส่งข้อมูลจากภูมิภาคจีนมาถึงที่ CF PoP (จุดแสดงตน) ที่ใกล้ที่สุด จากนั้นผ่านเครือข่ายหรือเครือข่ายของผู้ให้บริการ/พันธมิตรที่ส่งข้อมูลไปยังต้นทาง .
แผนภาพของม้านั่งทดสอบนี้แสดงไว้ด้านล่าง
นี่เป็นตัวเลือกที่ดีสำหรับเรา ปรากฎว่าโดเมนที่สองจะเป็นโดเมนสำหรับ CF ซึ่งไม่ได้เพิ่มจำนวนโซลูชันที่ใช้ในบริษัท และในทางปฏิบัติแล้วจะไม่ทำให้โครงสร้างพื้นฐานซับซ้อนอีกด้วย
เราทำการทดสอบเบราว์เซอร์ และนี่คือสิ่งที่เกิดขึ้น:
เพชรสีแดงคือความล้มเหลวในการทดสอบ ไฟล์ด้านล่างนี้เป็นข้อผิดพลาด DNS (แก้ไขการหมดเวลา) ความล้มเหลวที่ด้านบนคือการหมดเวลา
เวลาทำงาน: 86.6
มัธยฐาน: 18s
75 เปอร์เซ็นต์ไทล์: 29.3 วินาที
95 เปอร์เซ็นต์ไทล์: 60 วินาที
ค่ามัธยฐาน หลังจากโหลดถูกลบออก reCaptcha (บริการของ Google ถูกบล็อกในจีน) ลดลงจาก 28 เป็น 18 วินาที แต่สิ่งเหล่านี้ยังคงเป็นผลลัพธ์ที่แย่มาก เมื่อพิจารณาว่าการทดสอบเดียวกันสำหรับ semrush.com (จากสหรัฐอเมริกา) ให้เวลาน้อยกว่า 10 วินาทีสำหรับผู้ใช้ 95% (จากสหรัฐอเมริกา) ในหน้าเดียวกัน (คงที่ + ไดนามิก)
คุณสามารถเข้าไปทดสอบแต่ละครั้งและดูได้ น้ำตก และพารามิเตอร์รายละเอียดอื่น ๆ เพิ่มเติม เราเริ่มตรวจสอบสาเหตุของข้อผิดพลาดและหากทุกอย่างชัดเจนไม่มากก็น้อยสำหรับการหมดเวลา: อินเทอร์เน็ตในประเทศจีน "เข้าและออก" ด้วยเหตุนี้ความเร็วของการเชื่อมต่อและการโหลดทรัพยากรจากต่างประเทศจึงไม่เสถียรและไม่สม่ำเสมอ ข้อผิดพลาด DNS ทำให้เราประหลาดใจอย่างมาก เราพบว่า PoP Cloudflare จริงๆ แล้วตั้งอยู่ในประเทศจีน ที่อยู่ไซต์แก้ไขเป็น IP ใด ๆ ก็ได้ แต่เซิร์ฟเวอร์ DNS เป็นแบบอเมริกัน ซึ่งเป็นสาเหตุที่คำขอ DNS ถูกบังคับให้ข้ามพรมแดน ดังนั้นบางครั้งจึงล้มเหลว
เมื่อชี้แจงคำถามนี้กับ CF แล้วปรากฎว่า พวกเขาไม่มีเซิร์ฟเวอร์ DNS ของตัวเองในประเทศจีนและจะเป็นเมื่อไรยังไม่ทราบ
ดังนั้นเราจึงตัดสินใจทดสอบเฉพาะ Cloudflare DNS และเปลี่ยนกลไกการทำงานของ Cloudflare สำหรับเว็บไซต์ของเราเป็น “ดีเอ็นเอสเท่านั้น- นี่คือโหมดที่ Cloudflare ไม่รับส่งข้อมูลพร็อกซีผ่านตัวมันเอง ซึ่งหมายความว่าไม่มีการป้องกัน DDoS, CDN และคุณสมบัติอื่นๆ และทำงานในโหมดของเซิร์ฟเวอร์ DNS ปกติ
ขาตั้งนี้แสดงไว้ในแผนภาพต่อไปนี้ ตัวเลขดังกล่าวคำนึงถึงความรู้ที่เกิดขึ้นใหม่ว่าเซิร์ฟเวอร์ DNS ของ Cloudflare อยู่หลังไฟร์วอลล์
ที่ Catchpoint เราทำการทดสอบ 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)ไม่มีข้อผิดพลาดดังกล่าวเมื่อสืบค้นเซิร์ฟเวอร์ Cloudflare NS โดยตรง:
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- บันทึกที่ไม่มีอยู่ในโดเมน Cloudflare ตอบกลับ А-รายการที่เป็นข้อผิดพลาดและไม่สอดคล้องกับ 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
เราได้ส่งรายงานข้อผิดพลาดไปยัง Cloudflare และพวกเขาก็แก้ไขได้หลังจากนั้นระยะหนึ่ง มันกลายเป็นสิ่งที่น่าสนใจ: ในขณะนี้ยังไม่มีการรองรับ IPv6 ในประเทศจีน ดังนั้น Cloudflare จึงไม่สามารถออกที่อยู่ IPv6 ของตนที่นั่นเพื่อตอบสนองต่อคำขอ AAAA-บันทึก ในท้ายที่สุดแล้ว ทุกอย่างก็คลี่คลายในลักษณะที่ Cloudflare เริ่มตอบโจทย์ประเทศจีน ไม่มีข้อมูล ต่อการร้องขอดังกล่าว
ดังนั้นข้อผิดพลาด DNS ในการทดสอบ Catchpoint จึงลดลงอย่างรวดเร็วแต่ไม่สมบูรณ์ การหมดเวลายังคงอยู่ที่นี่:
และเราเริ่มมองหาวิธีแก้ปัญหาอื่น
ในส่วนถัดไป ผมจะเล่าให้คุณฟังว่าเราทดสอบระบบคลาวด์ของจีนอย่างไร อาลีบาบาเมฆด้วยความช่วยเหลือจาก "เวทมนตร์" เล็กๆ น้อยๆ ของ Nginx เราจึงสามารถสร้างโซลูชัน PoC (Proof of Concept) ได้อย่างรวดเร็ว วิธีที่เราสร้างโซลูชัน Multi-Cloud ซึ่งหนึ่งในนั้นช่วยเร่งการทำงานของบริการได้อย่างมากในท้ายที่สุด จากประเทศจีน.
คอยติดตาม!
ส่วนถัดไป
ที่มา: will.com
