เราเจาะทะลุ Great Chinese Firewall ได้อย่างไร (ตอนที่ 3)

Hi!
เรื่องราวดีๆทั้งหมดก็จบลง และเรื่องราวของเราเกี่ยวกับวิธีที่เราคิดวิธีแก้ปัญหาเพื่อผ่านไฟร์วอลล์จีนอย่างรวดเร็วก็ไม่มีข้อยกเว้น ข้าพเจ้าจึงรีบเล่าถึงข้อสุดท้ายนี้แก่ท่านว่า ส่วนสุดท้าย ในหัวข้อนี้

ในส่วนก่อนหน้านี้ เราได้พูดคุยเกี่ยวกับม้านั่งทดสอบหลายตัวที่เราคิดขึ้นมาและผลลัพธ์ที่ได้ และเราก็ตกลงกันว่าจะเพิ่มอะไรดี ซีดีเอ็น! เพื่อความหนืดในโครงการของเรา

ฉันจะบอกคุณว่าเราทดสอบ Alibaba Cloud CDN, Tencent Cloud CDN และ Akamai อย่างไร และผลลัพธ์ที่ได้เป็นอย่างไร และแน่นอนว่าเรามาสรุปกัน

เราเจาะทะลุ Great Chinese Firewall ได้อย่างไร (ตอนที่ 3)

อาลีบาบา คลาวด์ CDN

เราโฮสต์บน Alibaba Cloud และใช้ IPSEC และ CEN จากพวกเขา คงจะสมเหตุสมผลที่จะลองวิธีแก้ปัญหาก่อน

Alibaba Cloud มีผลิตภัณฑ์สองประเภทที่เหมาะกับเรา: CDN и ดีซีดีเอ็น. ตัวเลือกแรกคือ CDN แบบคลาสสิกสำหรับโดเมนเฉพาะ (โดเมนย่อย) ตัวเลือกที่สองย่อมาจาก เส้นทางแบบไดนามิกสำหรับ CDN (ฉันเรียกว่าไดนามิก CDN) สามารถเปิดใช้งานได้ในโหมดเต็มไซต์ (สำหรับโดเมนไวด์การ์ด) นอกจากนี้ยังแคชเนื้อหาคงที่และเร่งเนื้อหาไดนามิกด้วยตัวมันเองนั่นคือไดนามิกของเพจจะถูกโหลดผ่านผู้ให้บริการ เครือข่ายที่รวดเร็ว นี่เป็นสิ่งสำคัญสำหรับเรา เพราะโดยพื้นฐานแล้วไซต์ของเราเป็นแบบไดนามิก ใช้โดเมนย่อยจำนวนมาก และสะดวกกว่าในการตั้งค่า CDN หนึ่งครั้งสำหรับ "เครื่องหมายดอกจัน" - *.semrushchina.cn

เราได้เห็นผลิตภัณฑ์นี้แล้วในช่วงเริ่มต้นของโครงการในจีนของเรา แต่จากนั้นก็ยังใช้งานไม่ได้ และนักพัฒนาก็สัญญาว่าผลิตภัณฑ์นี้จะเปิดตัวให้กับลูกค้าทุกคนในไม่ช้า และเขาก็ทำ

ใน DCDN คุณสามารถ:

  • กำหนดค่าการยกเลิก SSL ด้วยใบรับรองของคุณ
  • เปิดใช้งานการเร่งความเร็วของเนื้อหาไดนามิก
  • กำหนดค่าแคชของไฟล์คงที่ได้อย่างยืดหยุ่น
  • ล้างแคช
  • ส่งต่อซ็อกเก็ตเว็บ
  • เปิดใช้งานการบีบอัดและแม้แต่ HTML Beautifier

โดยทั่วไปแล้ว ทุกอย่างจะเหมือนกับผู้ใหญ่และผู้ให้บริการ CDN รายใหญ่

หลังจากระบุ Origin (สถานที่ที่เซิร์ฟเวอร์ Edge CDN จะไป) สิ่งที่เหลืออยู่คือการสร้าง CNAME สำหรับเครื่องหมายดอกจันโดยอ้างอิง all.semrushchina.cn.w.kunluncan.com (ได้รับ CNAME นี้ในคอนโซล Alibaba Cloud) และ CDN จะทำงาน

จากผลการทดสอบ CDN นี้ช่วยเราได้มาก สถิติแสดงไว้ด้านล่าง

การตัดสิน
uptime
มัธยฐาน
75 เปอร์เซ็นไทล์
95 เปอร์เซ็นไทล์

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

CEN/IPsec + GLB
99.79
13s
16s
25s

อาลี CDN + CEN/IPsec + GLB
99.75
10s
12.8s
17.3s

นี่เป็นผลลัพธ์ที่ดีมาก โดยเฉพาะอย่างยิ่งหากคุณเปรียบเทียบกับตัวเลขที่อยู่ตอนต้น แต่เรารู้ว่าการทดสอบเบราว์เซอร์ของเว็บไซต์ www.semrush.com เวอร์ชันอเมริกาดำเนินการจากสหรัฐอเมริกาโดยเฉลี่ย 8.3 วินาที (เป็นค่าโดยประมาณมาก) มีพื้นที่สำหรับการปรับปรุง นอกจากนี้ยังมีผู้ให้บริการ CDN ที่น่าสนใจให้ทดสอบอีกด้วย

ดังนั้นเราจึงก้าวไปสู่ยักษ์ใหญ่รายอื่นในตลาดจีนอย่างราบรื่น - Tencent.

เมฆ Tencent

Tencent กำลังพัฒนาระบบคลาวด์ ซึ่งสามารถเห็นได้จากผลิตภัณฑ์จำนวนเล็กน้อย ในขณะที่ใช้งาน เราต้องการทดสอบไม่เพียงแต่ CDN เท่านั้น แต่ยังรวมถึงโครงสร้างพื้นฐานเครือข่ายโดยรวมด้วย:

  • พวกเขามีอะไรที่คล้ายกับ CEN บ้างไหม?
  • IPSEC ทำงานอย่างไรสำหรับพวกเขา? มันเร็วไหม เวลาอัพไทม์คืออะไร?
  • พวกเขามี Anycast ไหม?

เราเจาะทะลุ Great Chinese Firewall ได้อย่างไร (ตอนที่ 3)

ลองดูคำถามเหล่านี้แยกกัน

อะนาล็อก CEN

Tencent มีสินค้า เครือข่ายการเชื่อมต่อคลาวด์ (CCN) ช่วยให้คุณสามารถเชื่อมต่อ VPC จากภูมิภาคต่างๆ รวมถึงภูมิภาคภายในและภายนอกประเทศจีน ขณะนี้ผลิตภัณฑ์อยู่ในเวอร์ชันเบต้าภายใน และคุณต้องสร้างตั๋วเพื่อขอเชื่อมต่อ เราเรียนรู้จากการสนับสนุนว่าบัญชีทั่วโลก (เราไม่ได้หมายถึงพลเมืองจีนหรือนิติบุคคล) ไม่สามารถเข้าร่วมในโครงการทดสอบเบต้าได้ และโดยทั่วไปจะเชื่อมโยงภูมิภาคในจีนกับภูมิภาคภายนอก ขึ้นนำ อาลี คลาวด์ 1-0

สสวท

ภูมิภาคทางใต้สุดของ Tencent คือ กว่างโจว. เราประกอบอุโมงค์และเชื่อมต่อกับภูมิภาคฮ่องกงใน GCP (จากนั้น ภูมิภาคนี้ก็พร้อมใช้งานแล้ว) อุโมงค์ที่สองใน Ali Cloud จากเซินเจิ้นไปยังฮ่องกงก็ถูกยกขึ้นในเวลาเดียวกัน ปรากฎว่าผ่านเครือข่าย Tencent โดยทั่วไปเวลาแฝงไปยังฮ่องกงจะดีกว่า (10ms) มากกว่าจากเซินเจิ้นไปยังฮ่องกงถึงอาลี (120ms - อะไร?) แต่สิ่งนี้ไม่ได้เร่งการทำงานของไซต์ที่มุ่งเป้าไปที่การทำงานผ่าน Tencent และอุโมงค์นี้ แต่อย่างใดซึ่งเป็นข้อเท็จจริงที่น่าทึ่งในตัวมันเองและได้พิสูจน์สิ่งต่อไปนี้อีกครั้ง: เวลาแฝง - สำหรับจีนนี่ไม่ใช่ตัวบ่งชี้ที่คุ้มค่าจริงๆ ให้ความสนใจเมื่อพัฒนาโซลูชันสำหรับการผ่านไฟร์วอลล์จีน

การเร่งความเร็วอินเทอร์เน็ต Anycast

อีกหนึ่งผลิตภัณฑ์ที่ให้คุณทำงานผ่าน Anycast IP ก็คือ เอไอเอ. แต่บัญชีสากลไม่สามารถใช้ได้ ดังนั้นฉันจะไม่บอกคุณเกี่ยวกับเรื่องนี้ แต่การรู้ว่ามีผลิตภัณฑ์ดังกล่าวอยู่อาจมีประโยชน์

แต่การทดสอบ CDN แสดงให้เห็นผลลัพธ์ที่น่าสนใจทีเดียว CDN ของ Tencent ไม่สามารถเปิดใช้งานบนไซต์แบบเต็มได้เฉพาะในโดเมนที่ระบุเท่านั้น เราสร้างโดเมนและส่งการเข้าชมไปยังพวกเขา:

เราเจาะทะลุ Great Chinese Firewall ได้อย่างไร (ตอนที่ 3)

ปรากฎว่า CDN นี้มีฟังก์ชันดังต่อไปนี้: การเพิ่มประสิทธิภาพการจราจรข้ามพรมแดน. คุณลักษณะนี้ควรลดต้นทุนเมื่อการรับส่งข้อมูลผ่านไฟร์วอลล์จีน เช่น ที่มา ระบุที่อยู่ IP ของ Google GLB (GLB anycast) แล้ว ดังนั้นเราจึงต้องการทำให้สถาปัตยกรรมโครงการง่ายขึ้น

ผลลัพธ์ดีมาก - ในระดับ Ali Cloud CDN และดีกว่าในบางแห่งด้วย นี่เป็นเรื่องที่น่าแปลกใจ เพราะหากการทดสอบประสบความสำเร็จ คุณสามารถละทิ้งส่วนสำคัญของโครงสร้างพื้นฐาน ทันเนล CEN เครื่องเสมือน ฯลฯ ได้

เราไม่ได้ชื่นชมยินดีเป็นเวลานานเมื่อมีการเปิดเผยปัญหา: การทดสอบใน Catchpoint ล้มเหลวสำหรับผู้ให้บริการอินเทอร์เน็ต China Mobile จากสถานที่ใดก็ตาม เราได้รับแจ้งการหมดเวลาผ่าน CDN ของ Tencent การโต้ตอบกับฝ่ายสนับสนุนด้านเทคนิคไม่ได้นำไปสู่สิ่งใด เราพยายามแก้ไขปัญหานี้ประมาณหนึ่งวัน แต่ก็ไม่มีอะไรทำงาน

ตอนนั้นฉันอยู่ในประเทศจีน แต่ไม่พบ Wi-Fi สาธารณะบนเครือข่ายของผู้ให้บริการรายนี้เพื่อตรวจสอบปัญหาเป็นการส่วนตัว ไม่อย่างนั้นทุกอย่างก็ดูรวดเร็วและดี
อย่างไรก็ตาม เนื่องจาก China Mobile เป็นหนึ่งในสามผู้ให้บริการรายใหญ่ที่สุด เราจึงถูกบังคับให้คืนการรับส่งข้อมูลไปยัง Ali CDN
แต่โดยรวมแล้ว นี่เป็นวิธีแก้ปัญหาที่ค่อนข้างน่าสนใจซึ่งสมควรได้รับการทดสอบและแก้ไขปัญหานี้นานขึ้น

Akamai

ผู้ให้บริการ CDN รายสุดท้ายที่เราทดสอบคือ Akamai. นี่คือผู้ให้บริการรายใหญ่ที่มีเครือข่ายในประเทศจีน แน่นอนว่าเราไม่สามารถผ่านมันไปได้

เราเจาะทะลุ Great Chinese Firewall ได้อย่างไร (ตอนที่ 3)

ตั้งแต่แรกเริ่ม เราได้ตกลงกับ Akamai เพื่อทดลองใช้งานเพื่อที่เราจะได้สามารถเปลี่ยนโดเมนและดูว่าโดเมนจะทำงานอย่างไรบนเครือข่ายของพวกเขา ฉันจะอธิบายผลการทดสอบทั้งหมดในรูปแบบของ “สิ่งที่ฉันชอบ” และ “สิ่งที่ฉันไม่ชอบ” และฉันจะให้ผลการทดสอบด้วย

สิ่งที่ฉันชอบ:

  • เจ้าหน้าที่จาก Akamai ช่วยเหลือเราได้ดีมากในทุกคำถามและคอยติดตามเราตลอดการทดสอบทุกขั้นตอน เราพยายามปรับปรุงบางอย่างจากฝั่งเราอยู่ตลอดเวลา พวกเขาให้คำแนะนำทางเทคนิคที่ดี
  • Akamai ช้ากว่าโซลูชันของเราผ่าน Ali Cloud CDN ประมาณ 10-15% สิ่งที่น่าประทับใจคือใน Origin สำหรับ Akamai เราได้ระบุที่อยู่ IP ของ GLB ซึ่งหมายความว่าการรับส่งข้อมูลไม่ผ่านโซลูชันของเรา (เราอาจละทิ้งโครงสร้างพื้นฐานบางส่วนได้) แต่ถึงกระนั้นผลการทดสอบก็แสดงให้เห็นว่าโซลูชันนี้แย่กว่าเวอร์ชันปัจจุบันของเรา (ผลการเปรียบเทียบด้านล่าง)
  • ทดสอบทั้ง Origin GLB และ Origin ในประเทศจีน ตัวเลือกทั้งสองมีค่าใกล้เคียงกัน
  • มี เส้นทางแน่นอน (การเพิ่มประสิทธิภาพการกำหนดเส้นทางอัตโนมัติ) คุณสามารถโฮสต์ออบเจ็กต์ทดสอบบน Origin ได้ และเซิร์ฟเวอร์ Akamai Edge จะพยายามรับออบเจ็กต์นั้น (GET ปกติ) สำหรับคำขอเหล่านี้ ความเร็วและตัวชี้วัดอื่นๆ จะถูกวัด โดยขึ้นอยู่กับการที่เครือข่าย Akamai ปรับเส้นทางให้เหมาะสมเพื่อให้การรับส่งข้อมูลเร็วขึ้นสำหรับไซต์ของเรา และเป็นที่ชัดเจนว่าการเปิดใช้งานฟีเจอร์นี้มีผลกระทบอย่างมากต่อความเร็วของไซต์
  • การกำหนดเวอร์ชันในเว็บอินเตอร์เฟสนั้นยอดเยี่ยม คุณสามารถเปรียบเทียบเวอร์ชันต่างๆ ดูที่ความแตกต่างได้ ดูเวอร์ชันก่อนหน้า
  • คุณสามารถเปิดตัวเวอร์ชันใหม่ได้ก่อนเฉพาะบนเครือข่าย Akamai Staging ซึ่งเป็นเครือข่ายเดียวกับการใช้งานจริง ด้วยวิธีนี้เท่านั้นที่จะไม่ส่งผลกระทบต่อผู้ใช้จริง สำหรับการทดสอบนี้ คุณต้องปลอมแปลงระเบียน DNS บนเครื่องของคุณ
  • ความเร็วในการดาวน์โหลดที่รวดเร็วมากผ่านเครือข่ายสำหรับไฟล์คงที่ขนาดใหญ่ และไฟล์อื่นๆ อย่างเห็นได้ชัด ไฟล์จากแคช "เย็น" จะถูกดึงข้อมูลได้เร็วกว่าไฟล์เดียวกันจากแคช "เย็น" ของ Ali CDN หลายเท่า จากแคช "ร้อน" ความเร็วจะเท่ากันอยู่แล้วบวกหรือลบ

การทดสอบอาลี CDN:

root@shenzhen1:~# curl -o /dev/null -w@curl_time https://en.semrushchina.cn/my_reports/build/scripts/simpleInit.js?v=1551879212
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 5757k    0 5757k    0     0   513k      0 --:--:--  0:00:11 --:--:--  526k
time_namelookup:  0.004286
time_connect:  0.030107
time_appconnect:  0.117525
time_pretransfer:  0.117606
time_redirect:  0.000000
time_starttransfer:  0.840348
----------
time_total:  11.208119
----------
size_download:  5895467 Bytes
speed_download:  525999.000B/s

การทดสอบ Akamai:

root@shenzhen1:~# curl -o /dev/null -w@curl_time https://www.semrushchina.cn/my_reports/build/scripts/simpleInit.js?v=1551879212
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 5757k    0 5757k    0     0  1824k      0 --:--:--  0:00:03 --:--:-- 1825k
time_namelookup:  0.509005
time_connect:  0.528261
time_appconnect:  0.577235
time_pretransfer:  0.577324
time_redirect:  0.000000
time_starttransfer:  1.327013
----------
time_total:  3.154850
----------
size_download:  5895467 Bytes
speed_download:  1868699.000B/s

เราสังเกตเห็นว่าสถานการณ์ในตัวอย่างข้างต้นขึ้นอยู่กับปัจจัยหลายประการ ในขณะที่เขียนประเด็นนี้ ฉันก็ทำการทดสอบอีกครั้ง ผลลัพธ์สำหรับทั้งสองแพลตฟอร์มใกล้เคียงกัน สิ่งนี้บอกเราว่าอินเทอร์เน็ตในประเทศจีน แม้แต่ผู้ให้บริการรายใหญ่และผู้ให้บริการคลาวด์ ก็มีพฤติกรรมแตกต่างออกไปในบางครั้ง

ในประเด็นก่อนหน้านี้ ฉันจะเพิ่มข้อดีอย่างมากให้กับ Akamai: หาก Ali แสดงแฟลชที่คล้ายกันของประสิทธิภาพสูงและประสิทธิภาพที่ต่ำมาก (ซึ่งใช้กับ Ali CDN, Ali CEN และ Ali IPSEC) จากนั้น Akamai ทุกครั้ง ไม่สำคัญ ฉันจะทดสอบเครือข่ายของพวกเขาได้อย่างไร ทุกอย่างทำงานได้อย่างเสถียร
Akamai มีความครอบคลุมมากมายในประเทศจีนและทำงานผ่านผู้ให้บริการหลายราย

สิ่งที่ฉันไม่ชอบ:

  • ฉันไม่ชอบเว็บอินเตอร์เฟสและวิธีการทำงาน - มันแย่มาก แต่โดยพื้นฐานแล้วคุณจะคุ้นเคยกับมัน (อาจ)
  • ผลการทดสอบแย่กว่าเว็บไซต์ของเรา
  • มีข้อผิดพลาดระหว่างการทดสอบมากกว่าบนเว็บไซต์ของเรา (เวลาทำงานต่ำกว่า)
  • เราไม่มีเซิร์ฟเวอร์ DNS ของเราเองในประเทศจีน ดังนั้นจึงมีข้อผิดพลาดมากมายในการทดสอบเนื่องจากการหมดเวลาการแก้ไข DNS
  • พวกเขาไม่ได้ระบุช่วง IP -> ไม่มีวิธีลงทะเบียนช่วงที่ถูกต้อง set_real_ip_from บนเซิร์ฟเวอร์ของเรา

หน่วยวัด (~ 3626 รัน หน่วยวัดทั้งหมดยกเว้นสถานะการออนไลน์ เป็นมิลลิวินาที สถิติสำหรับช่วงเวลาหนึ่ง):

ผู้ให้บริการ CDN
มัธยฐาน
ลด 75%
ลด 95%
คำตอบ
การตอบกลับหน้าเว็บ
uptime
DNS
เชื่อมต่อ
รอ
โหลด
SSL

อาลีซีดีเอ็น
9195
10749
17489
1,715
10,745
99.531
57
17
927
479
200

Akamai
9783
11887
19888
2,352
11,550
98.980
424
91
1408
381
50

การกระจายตามเปอร์เซ็นไทล์ (เป็นมิลลิวินาที):

เปอร์เซ็น
Akamai
อาลีซีดีเอ็น

10
7,092
6,942

20
7,775
7,583

30
8,446
8,092

40
9,146
8,596

50
9,783
9,195

60
10,497
9,770

70
11,371
10,383

80
12,670
11,255

90
15,882
13,165

100
91,592
91,596

ข้อสรุปคือ: ตัวเลือก Akamai ใช้งานได้ แต่ไม่ได้ให้ความเสถียรและความเร็วเหมือนกับโซลูชันของเราเองควบคู่ไปกับ Ali CDN

บันทึกย่อขนาดเล็ก

บางช่วงเวลาไม่รวมอยู่ในเรื่องราว แต่ฉันอยากจะเขียนเกี่ยวกับช่วงเวลาเหล่านั้นด้วย

ปักกิ่ง + โตเกียว และฮ่องกง

ดังที่กล่าวข้างต้น เราได้ทดสอบอุโมงค์ IPSEC ไปยังฮ่องกง (HK) แต่เรายังทดสอบ CEN ถึง HK ด้วย มันถูกกว่านิดหน่อย และฉันสงสัยว่ามันจะทำงานอย่างไรระหว่างเมืองต่างๆ ที่มีระยะทางประมาณ 100 กม. เป็นเรื่องที่น่าสนใจที่เวลาแฝงระหว่างเมืองเหล่านี้สูงกว่าเวอร์ชันดั้งเดิมของเราถึง 100 มิลลิวินาที (ไปยังไต้หวัน) ความเร็ว ความเสถียรก็ดีกว่าสำหรับไต้หวันด้วย ด้วยเหตุนี้ เราจึงออกจากฮ่องกงเป็นภูมิภาคสำรองของ IPSEC

นอกจากนี้เรายังพยายามติดตั้งการติดตั้งต่อไปนี้:

  • การยกเลิกลูกค้าในกรุงปักกิ่ง
  • IPSEC และ CEN ถึงโตเกียว
  • ใน Ali CDN เซิร์ฟเวอร์ในปักกิ่งถูกระบุว่าเป็นแหล่งกำเนิด

รูปแบบนี้ไม่เสถียรนัก แม้ว่าโดยทั่วไปแล้วในแง่ของความเร็วแล้วก็ไม่ได้ด้อยกว่าโซลูชันของเราก็ตาม เกี่ยวกับอุโมงค์ ฉันได้เห็นการลดลงเป็นระยะๆ แม้กระทั่งสำหรับ CEN ซึ่งควรจะมีเสถียรภาพ ดังนั้นเราจึงกลับไปสู่รูปแบบเก่าและรื้อถอนการแสดงละครนี้

ด้านล่างนี้คือสถิติเกี่ยวกับเวลาในการตอบสนองระหว่างภูมิภาคต่างๆ สำหรับช่องต่างๆ บางทีอาจมีคนสนใจมัน

IPsec
อาลี cn-ปักกิ่ง <—> GCP asia-northeast1 — 193ms
อาลี cn-เซินเจิ้น <—> GCP asia-east2 — 91ms
อาลี cn-เซินเจิ้น <—> GCP us-east4 — 200ms

CEN
อาลี cn-ปักกิ่ง <—> อาลี ap-northeast-1 — 54ms (!)
อาลี cn-เซินเจิ้น <—> อาลี cn-ฮ่องกง — 6ms (!)
อาลี cn-เซินเจิ้น <—> อาลี us-east1 — 216ms

ข้อมูลทั่วไปเกี่ยวกับอินเทอร์เน็ตในประเทศจีน

นอกเหนือจากปัญหาเกี่ยวกับอินเทอร์เน็ตที่อธิบายไว้ตอนเริ่มต้นในส่วนแรกของบทความ

  • อินเทอร์เน็ตในประเทศจีนค่อนข้างเร็วภายใน
    • ข้อสรุปนี้จัดทำขึ้นจากการทดสอบเครือข่าย Wi-Fi สาธารณะในสถานที่ต่างๆ ที่มีผู้คนจำนวนมากใช้เครือข่ายเหล่านี้
    • ความเร็วในการดาวน์โหลดและอัพโหลดไปยังเซิร์ฟเวอร์ในประเทศจีนอยู่ที่ประมาณ 20 Mbit/s และ 5-10 Mbit/s ตามลำดับ
    • ความเร็วไปยังเซิร์ฟเวอร์นอกประเทศจีนนั้นน้อยมาก น้อยกว่า 1 Mbit/s
  • อินเตอร์เน็ตในจีนไม่ค่อยเสถียร
    • บางครั้งไซต์สามารถเปิดได้อย่างรวดเร็ว บางครั้งก็เปิดช้า (ในเวลาเดียวกันของวันในแต่ละวัน) โดยมีเงื่อนไขว่าการกำหนดค่าจะไม่เปลี่ยนแปลง เราสังเกตสิ่งนี้ด้วยตัวอย่างของ semrushchina.cn สิ่งนี้สามารถนำมาประกอบกับ Ali CDN ซึ่งทำงานในลักษณะนี้เช่นกันและขึ้นอยู่กับช่วงเวลาของวัน ตำแหน่งของดวงดาว ฯลฯ
  • อินเทอร์เน็ตบนมือถือมีอยู่เกือบทุกที่ 4G หรือ 4G+ จับมันขึ้นรถไฟใต้ดิน ลิฟต์ - พูดง่ายๆ ทุกที่
  • เป็นเรื่องเข้าใจผิดที่ผู้ใช้ชาวจีนเชื่อถือโดเมนในโซน .cn เท่านั้น เราเรียนรู้สิ่งนี้โดยตรงจากผู้ใช้
    • คุณสามารถดูวิธีการ http://baidu.cn เปลี่ยนเส้นทางไปที่ www.baidu.com (ในจีนแผ่นดินใหญ่เช่นกัน)
  • ทรัพยากรจำนวนมากถูกบล็อกจริงๆ ดั้งเดิม: google.com, Facebook, Twitter แต่ทรัพยากรของ Google จำนวนมากใช้งานได้ (แน่นอนว่าไม่ได้ใช้กับ Wi-Fi และ VPN ทั้งหมด (แน่นอนว่าบนฝั่งเราเตอร์ด้วย)
  • โดเมน "ทางเทคนิค" จำนวนมากของบริษัทที่ถูกบล็อกก็ใช้งานได้เช่นกัน ซึ่งหมายความว่าคุณไม่ควรตัด Google และทรัพยากรอื่นๆ ที่ดูเหมือนถูกบล็อกโดยประมาทเสมอไป คุณต้องค้นหารายการโดเมนที่ไม่ได้รับอนุญาต
  • พวกเขามีผู้ให้บริการอินเทอร์เน็ตหลักเพียงสามราย ได้แก่ China Unicom, China Telecom, China Mobile แม้จะมีขนาดเล็กกว่า แต่ส่วนแบ่งการตลาดไม่มีนัยสำคัญ

โบนัส: แผนภาพวิธีแก้ปัญหาขั้นสุดท้าย

เราเจาะทะลุ Great Chinese Firewall ได้อย่างไร (ตอนที่ 3)

ทั้งหมด

หนึ่งปีผ่านไปนับตั้งแต่เริ่มโครงการ เราเริ่มต้นด้วยความจริงที่ว่าโดยทั่วไปแล้วไซต์ของเราปฏิเสธที่จะทำงานตามปกติจากประเทศจีน และ GET curl ใช้เวลาเพียง 5.5 วินาที

จากนั้น ด้วยตัวบ่งชี้เหล่านี้ในโซลูชันแรก (Cloudflare):

การตัดสิน
uptime
มัธยฐาน
75 เปอร์เซ็นไทล์
95 เปอร์เซ็นไทล์

Cloudflare
86.6
18s
30s
60s

ในที่สุดเราก็ได้ผลลัพธ์ดังต่อไปนี้ (สถิติสำหรับเดือนที่แล้ว):

การตัดสิน
uptime
มัธยฐาน
75 เปอร์เซ็นไทล์
95 เปอร์เซ็นไทล์

อาลี CDN + CEN/IPsec + GLB
99.86
8.8s
9.5s
13.7s

อย่างที่คุณเห็นเรายังไม่สามารถบรรลุสถานะการออนไลน์ได้ 100% แต่เราจะทำอะไรบางอย่างแล้วเราจะบอกคุณเกี่ยวกับผลลัพธ์ในบทความใหม่ :)

ขอแสดงความนับถือผู้ที่อ่านทั้งสามตอนจนจบ ฉันหวังว่าคุณจะพบว่าทั้งหมดนี้น่าสนใจเหมือนตอนที่ฉันทำ

ปล.ภาคก่อนๆ

Часть 1
Часть 2

ที่มา: will.com

เพิ่มความคิดเห็น