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

Hi!

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

В ส่วนก่อนหน้า ฉันพูดว่า:

• ปัญหาอะไรเกิดขึ้นหลังการตัดสินใจ “เราจำเป็นต้องให้บริการที่จีน”
• อินเทอร์เน็ตของจีนมีปัญหาอะไรบ้าง?
• ทำไมคุณต้องมีใบอนุญาต ICP?
• เราตัดสินใจทดสอบเตียงทดสอบด้วย Catchpoint อย่างไรและทำไม
• ผลลัพธ์ของโซลูชันแรกของเราที่ใช้ Cloudflare China Network คืออะไร
• เราพบข้อบกพร่องใน Cloudflare DNS ได้อย่างไร

ในความคิดของฉันส่วนนี้น่าสนใจที่สุด เนื่องจากเน้นไปที่การใช้งานทางเทคนิคเฉพาะของการแสดงละคร และเราจะเริ่มต้นหรือดำเนินการต่อด้วย อาลีบาบาเมฆ.

อาลีบาบาเมฆ

อาลีบาบาเมฆ เป็นผู้ให้บริการคลาวด์รายใหญ่ซึ่งมีบริการทั้งหมดที่สามารถเรียกตัวเองว่าเป็นผู้ให้บริการคลาวด์ได้อย่างตรงไปตรงมา เป็นเรื่องดีที่พวกเขามีโอกาสลงทะเบียนสำหรับผู้ใช้ชาวต่างชาติและเว็บไซต์ส่วนใหญ่ได้รับการแปลเป็นภาษาอังกฤษ (สำหรับจีนถือว่าหรูหรา) ในระบบคลาวด์นี้ คุณสามารถทำงานกับหลายภูมิภาคของโลก จีนแผ่นดินใหญ่ รวมถึงเอเชียโอเชียนิก (ฮ่องกง ไต้หวัน ฯลฯ)

สสวท

เราเริ่มต้นด้วยภูมิศาสตร์ เนื่องจากไซต์ทดสอบของเราอยู่บน Google Cloud เราจึงจำเป็นต้อง "เชื่อมโยง" Alibaba Cloud กับ GCP ดังนั้นเราจึงเปิดรายการสถานที่ตั้งที่มี Google อยู่ ในขณะนั้นพวกเขายังไม่มีศูนย์ข้อมูลของตนเองในฮ่องกง
ภูมิภาคที่ใกล้ที่สุดกลายเป็น เอเชียตะวันออก1 (ไต้หวัน). อาลีกลายเป็นภูมิภาคที่ใกล้เคียงที่สุดของจีนแผ่นดินใหญ่กับไต้หวัน cn-เซินเจิ้น (เซินเจิ้น).

ด้วย terraform อธิบายและยกระดับโครงสร้างพื้นฐานทั้งหมดใน GCP และ Ali อุโมงค์ความเร็ว 100 Mbit/s ระหว่างก้อนเมฆเพิ่มขึ้นเกือบจะในทันที ที่ฝั่งเซินเจิ้นและไต้หวัน มีการยกพร็อกซีเครื่องเสมือนขึ้น ในเซินเจิ้น ปริมาณการใช้งานของผู้ใช้จะสิ้นสุดลง โดยพร็อกซีผ่านอุโมงค์ไปยังไต้หวัน และจากนั้นจะตรงไปยัง IP ภายนอกของบริการของเราใน เรา-ตะวันออก (ชายฝั่งตะวันออกของสหรัฐอเมริกา) ปิงระหว่างเครื่องเสมือนผ่านอุโมงค์ 24msซึ่งก็ไม่ได้แย่ขนาดนั้น

ในเวลาเดียวกัน เราก็ได้วางพื้นที่ทดสอบไว้ อาลีบาบาคลาวด์ DNS. หลังจากมอบหมายโซนให้กับ NS Ali แล้ว เวลาในการแก้ไขก็ลดลงจาก 470 ms เป็น ms 50. ก่อนหน้านี้โซนก็อยู่บน Cloudlfare ด้วย

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

เวลาแฝงสำหรับอุโมงค์กลายเป็นดังนี้:
อาลี cn-เซินเจิ้น <—> GCP asia-east1 — 24ms
อาลี cn-เซินเจิ้น <—> GCP us-east4 — 200ms

การทดสอบเบราว์เซอร์ Catchpoint รายงานการปรับปรุงที่ยอดเยี่ยม

เปรียบเทียบผลการทดสอบสำหรับสองโซลูชัน:

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

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

นี่คือข้อมูลจากโซลูชันที่ใช้ช่องทาง IPSEC ผ่าน เอเชียตะวันออก1. ผ่าน us-east4 ผลลัพธ์แย่ลง และมีข้อผิดพลาดมากขึ้น ดังนั้นฉันจะไม่ให้ผลลัพธ์

จากผลการทดสอบอุโมงค์ทั้งสองนี้ อุโมงค์หนึ่งยุติในภูมิภาคที่ใกล้ที่สุดกับจีน และอีกอุโมงค์หนึ่งอยู่ที่ปลายทางสุดท้าย เห็นได้ชัดว่าการ "โผล่ออกมา" จากใต้ไฟร์วอลล์ของจีนโดยเร็วที่สุดนั้นเป็นสิ่งสำคัญ เป็นไปได้ จากนั้นใช้เครือข่ายที่รวดเร็ว (ผู้ให้บริการ CDN ผู้ให้บริการระบบคลาวด์ ฯลฯ) ไม่จำเป็นต้องพยายามผ่านไฟร์วอลล์และไปยังปลายทางของคุณในคราวเดียว นี่ไม่ใช่วิธีที่เร็วที่สุด

โดยทั่วไปแล้ว ผลลัพธ์ที่ได้ก็ไม่แย่นัก อย่างไรก็ตาม semrush.com มีค่ามัธยฐานที่ 8.8 วินาที และ 75 เปอร์เซ็นต์ไทล์ 9.4 วินาที (ในการทดสอบเดียวกัน)
และก่อนที่จะก้าวต่อไป ฉันอยากจะพูดนอกเรื่องโคลงสั้น ๆ สักหน่อย

การพูดนอกเรื่อง Lyrical

หลังจากที่ผู้ใช้เข้าสู่เว็บไซต์ www.semrushchina.cnซึ่งแก้ไขผ่านเซิร์ฟเวอร์ DNS ของจีนที่ “รวดเร็ว” คำขอ HTTP จะดำเนินการผ่านโซลูชันที่รวดเร็วของเรา การตอบกลับจะถูกส่งกลับในเส้นทางเดียวกัน แต่มีการระบุโดเมนไว้ในสคริปต์ JS, หน้า HTML และองค์ประกอบอื่นๆ ของหน้าเว็บทั้งหมด semrush.com สำหรับแหล่งข้อมูลเพิ่มเติมที่ต้องโหลดเมื่อเพจถูกแสดงผล นั่นคือลูกค้าแก้ไขบันทึก A "หลัก" www.semrushchina.cn และเข้าสู่ช่องทางที่รวดเร็ว ได้รับการตอบกลับอย่างรวดเร็ว - หน้า HTML ที่ระบุว่า:

• ดาวน์โหลดดังกล่าวและ js ดังกล่าวจาก sso.semrush.com
• รับไฟล์ CSS จาก cdn.semrush.com
• และถ่ายรูปจาก dab.semrush.com ด้วย
• เป็นต้น

เบราว์เซอร์เริ่มไปที่อินเทอร์เน็ต "ภายนอก" เพื่อหาทรัพยากรเหล่านี้ โดยแต่ละครั้งจะผ่านไฟร์วอลล์ที่กินเวลาตอบสนอง

แต่การทดสอบก่อนหน้านี้แสดงผลลัพธ์เมื่อไม่มีทรัพยากรบนเพจ semrush.com, เท่านั้น semrushchina.cnและ *.semrushchina.cn แก้ไขที่อยู่ของเครื่องเสมือนในเซินเจิ้นเพื่อเข้าไปในอุโมงค์

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

ตัวกรองย่อย

วิธีแก้ปัญหาเกิดขึ้นเกือบจะในทันทีหลังจากปัญหานี้เกิดขึ้น พวกเราต้องการ PoC (Proof of Concept) ว่าโซลูชั่นการเจาะไฟร์วอลล์ของเราทำงานได้ดีจริงๆ ในการดำเนินการนี้ คุณจะต้องรวมการเข้าชมเว็บไซต์ทั้งหมดไว้ในโซลูชันนี้ให้มากที่สุด และเราก็สมัคร ตัวกรองย่อย ใน nginx

ตัวกรองย่อย เป็นโมดูลที่ค่อนข้างง่ายใน nginx ที่ให้คุณเปลี่ยนหนึ่งบรรทัดในเนื้อหาการตอบกลับเป็นอีกบรรทัดหนึ่ง เราจึงเปลี่ยนเหตุการณ์ทั้งหมด semrush.com บน semrushchina.cn ในทุกคำตอบ

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

เป็นผลให้ลูกค้าจะได้รับที่ไหน .semrush.com, เขาได้รับ .semrushchina.cn และปฏิบัติตามการตัดสินใจของเราอย่างเชื่อฟัง

อย่างไรก็ตาม การเปลี่ยนโดเมนด้วยวิธีเดียวนั้นไม่เพียงพอ เนื่องจากแบ็กเอนด์ยังคงคาดหวังให้ semrush.com ในคำขอที่ตามมาจากไคลเอนต์ ดังนั้น บนเซิร์ฟเวอร์เดียวกันกับที่ทำการแทนที่แบบทางเดียว โดยใช้นิพจน์ทั่วไปแบบธรรมดา เราจะรับโดเมนย่อยจากคำขอ จากนั้นเราก็ดำเนินการ proxy_pass ด้วยตัวแปร $โฮสต์,จัดแสดงใน $โดเมนย่อย.semrush.com. อาจดูสับสนแต่ได้ผล และมันก็ทำงานได้ดี สำหรับแต่ละโดเมนที่ต้องการตรรกะที่แตกต่างกัน เพียงสร้างบล็อกเซิร์ฟเวอร์ของคุณเองและทำการกำหนดค่าแยกต่างหาก ด้านล่างนี้คือการกำหนดค่า nginx แบบย่อเพื่อความชัดเจนและการสาธิตโครงร่างนี้

การกำหนดค่าต่อไปนี้จะประมวลผลคำขอทั้งหมดจากจีนถึง .semrushchina.cn:

    listen 80;

    server_name ~^(?<subdomain>[w-]+).semrushchina.cn$;

    sub_filter '.semrush.com' '.semrushchina.cn';
    sub_filter_last_modified on;
    sub_filter_once off;
    sub_filter_types *;

    gzip on;
    gzip_proxied any;
    gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript;

    location / {
        proxy_pass http://127.0.0.1:8083;
        proxy_set_header Accept-Encoding "";
        proxy_set_header Host $subdomain.semrush.com;
        proxy_set_header X-Accept-Encoding $http_accept_encoding;
    }
}

พร็อกซีการกำหนดค่านี้ไปที่ localhost ไปที่พอร์ต 83 และการกำหนดค่าต่อไปนี้กำลังรออยู่ที่นั่น:

    listen 127.0.0.1:8083;

    server_name *.semrush.com;

    location / {
        resolver 8.8.8.8 ipv6=off;
        gunzip on;
        proxy_pass https://$host;
        proxy_set_header Accept-Encoding gzip;
    }
}

ฉันขอย้ำอีกครั้งว่านี่คือการกำหนดค่าแบบครอบตัด

เช่นนั้น. มันอาจจะดูซับซ้อนแต่มันเป็นคำพูด ที่จริงแล้วทุกอย่างง่ายกว่าหัวผักกาดนึ่ง :)

สิ้นสุดการพูดนอกเรื่อง

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

พวกเขาหยิบมันขึ้นมา ทันเนลเริ่มล้มเหลวในเวลาที่ต่างกัน แต่เฟลโอเวอร์ทำงานได้ดีสำหรับเราที่ระดับอัปสตรีมใน nginx แต่แล้วอุโมงค์ก็เริ่มตกพร้อมๆ กัน 🙂 และ 502 และ 504 ก็เริ่มต้นใหม่อีกครั้ง Uptime เริ่มแย่ลง เราจึงเริ่มหาทางเลือกด้วย อาลีบาบา CEN (เครือข่ายคลาวด์เอ็นเตอร์ไพรส์)

CEN

CEN - นี่คือการเชื่อมต่อของ VPC สองตัวจากภูมิภาคต่างๆ ภายใน Alibaba Cloud กล่าวคือ คุณสามารถเชื่อมต่อเครือข่ายส่วนตัวของภูมิภาคใดๆ ภายในคลาวด์เข้าด้วยกันได้ และที่สำคัญช่องนี้มีความเข้มงวดพอสมควร SLA. มีความเสถียรมากทั้งในด้านความเร็วและสถานะการออนไลน์ แต่มันไม่ง่ายเลย:

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

มีโอกาสได้สานต่อ จีนแผ่นดินใหญ่ и ต่างประเทศเราได้สร้าง CEN ระหว่างสองภูมิภาคอาลี: cn-เซินเจิ้น и เรา-ตะวันออก-1 (จุดที่ใกล้ที่สุดคือ us-east4) ในอาลี เรา-ตะวันออก-1 ยกเครื่องเสมือนขึ้นมาอีกเครื่องหนึ่งเพื่อให้มีอีกหนึ่งเครื่อง กระโดด.

มันกลับกลายเป็นเช่นนี้:

ผลการทดสอบเบราว์เซอร์อยู่ด้านล่าง:

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

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

ประสิทธิภาพดีกว่า IPSEC เล็กน้อย แต่ผ่าน IPSEC คุณสามารถดาวน์โหลดได้ที่ความเร็ว 100 Mbit/s และผ่าน CEN ที่ความเร็ว 5 Mbit/s ขึ้นไปเท่านั้น

ฟังดูเหมือนไฮบริดใช่ไหม? รวมความเร็ว IPSEC และความเสถียรของ CEN

นี่คือสิ่งที่เราทำ โดยอนุญาตให้มีการรับส่งข้อมูลผ่านทั้ง IPSEC และ CEN ในกรณีที่อุโมงค์ IPSEC ล้มเหลว เวลาทำงานสูงขึ้นมาก แต่ความเร็วในการโหลดไซต์ยังคงเป็นที่ต้องการอยู่มาก จากนั้นผมจึงวาดวงจรทั้งหมดที่เราใช้และทดสอบมาแล้วแล้วจึงตัดสินใจลองเพิ่ม GCP เข้าไปในวงจรนี้อีกสักหน่อย กล่าวคือ GLB.

GLB

GLB - เป็น โหลดบาลานเซอร์ทั่วโลก (หรือ Google Cloud Load Balancer) มีข้อได้เปรียบที่สำคัญสำหรับเรา: ในบริบทของ CDN ที่มี เอนี่แคสต์ IPซึ่งช่วยให้คุณกำหนดเส้นทางการรับส่งข้อมูลไปยังศูนย์ข้อมูลที่ใกล้กับไคลเอ็นต์มากที่สุด เพื่อให้การรับส่งข้อมูลเข้าสู่เครือข่ายที่รวดเร็วของ Google อย่างรวดเร็ว และผ่านอินเทอร์เน็ต "ปกติ" น้อยลง

เรายกขึ้นโดยไม่ต้องคิดซ้ำสอง HTTP/HTTPS ปอนด์ เราติดตั้งเครื่องเสมือนของเราพร้อมตัวกรองย่อยใน GCP และเป็นแบ็กเอนด์

มีหลายแผนการ:

• ที่จะใช้ เครือข่าย Cloudflare ของจีนแต่คราวนี้ Origin ควรระบุ global ไอพี จีแอลบี.
• ยุติการให้บริการลูกค้าที่ cn-เซินเจิ้นและจากนั้นพร็อกซีการรับส่งข้อมูลโดยตรงไปยัง GLB.
• ตรงจากจีนไป. GLB.
• ยุติการให้บริการลูกค้าที่ cn-เซินเจิ้นจากที่นั่นพรอกซีถึง เอเชียตะวันออก1 ผ่าน IPSEC (นิ้ว เรา-east4 ผ่าน CEN) จากนั้นไปที่ GLB (ใจเย็น ๆ จะมีภาพและคำอธิบายด้านล่าง)

เราได้ทดสอบตัวเลือกเหล่านี้ทั้งหมดและตัวเลือกแบบไฮบริดอีกหลายตัว:

• คลาวด์แฟลร์ + GLB

โครงการนี้ไม่เหมาะกับเราเนื่องจากสถานะการออนไลน์และข้อผิดพลาด DNS แต่การทดสอบได้ดำเนินการก่อนที่จะแก้ไขจุดบกพร่องในฝั่ง CF บางทีตอนนี้อาจจะดีกว่านี้ (อย่างไรก็ตาม นี่ไม่ได้ยกเว้นการหมดเวลา HTTP)

• อาลี + GLB

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

• GLB เท่านั้น

ตัวเลือกที่คล้ายกับตัวเลือกก่อนหน้านี้ เพียงแต่ไม่ได้ใช้เซิร์ฟเวอร์ในประเทศจีนเท่านั้น: การรับส่งข้อมูลไปที่ GLB โดยตรง (บันทึก DNS มีการเปลี่ยนแปลง) ดังนั้นผลลัพธ์ที่ได้จึงไม่เป็นที่น่าพอใจ เนื่องจากลูกค้าชาวจีนทั่วไปที่ใช้บริการของผู้ให้บริการอินเทอร์เน็ตทั่วไปมีสถานการณ์ที่เลวร้ายกว่ามากในการผ่านไฟร์วอลล์มากกว่า Ali Cloud

• เซินเจิ้น -> (CEN/IPSEC) -> หนังสือมอบฉันทะ -> GLB

ที่นี่เราตัดสินใจใช้โซลูชันที่ดีที่สุดทั้งหมด:

• ความมั่นคงและรับประกัน SLA จาก CEN
• ความเร็วสูงจาก IPSEC
• เครือข่าย "รวดเร็ว" ของ Google และ Anycast

รูปแบบมีลักษณะดังนี้: การรับส่งข้อมูลผู้ใช้ถูกยกเลิกบนเครื่องเสมือนใน ช-เซินเจิ้น. อัปสตรีม Nginx ได้รับการกำหนดค่าที่นั่น บางส่วนชี้ไปที่เซิร์ฟเวอร์ IP ส่วนตัวซึ่งอยู่ที่ปลายอีกด้านของอุโมงค์ IPSEC และอัปสตรีมบางส่วนชี้ไปยังที่อยู่ส่วนตัวของเซิร์ฟเวอร์อีกด้านหนึ่งของ CEN IPSEC กำหนดค่าเป็นภูมิภาค เอเชียตะวันออก1 ใน GCP (เป็นภูมิภาคที่ใกล้ที่สุดกับจีน ณ เวลาที่สร้างโซลูชัน ปัจจุบัน GCP มีการดำเนินงานในฮ่องกงด้วย) CEN - ไปยังภูมิภาค เรา-east1 ในอาลีคลาวด์

จากนั้นการจราจรจากปลายทั้งสองก็มุ่งตรงไปที่ เอนี่คาสท์ IP GLBนั่นคือไปยังจุดที่ใกล้ที่สุดของ Google และผ่านเครือข่ายไปยังภูมิภาค เรา-east4 ใน GCP ซึ่งมีเครื่องเสมือนทดแทน (พร้อมตัวกรองย่อยใน nginx)

ตามที่เราคาดไว้ โซลูชันไฮบริดนี้ใช้ประโยชน์จากข้อดีของแต่ละเทคโนโลยี โดยทั่วไป การรับส่งข้อมูลจะดำเนินการผ่าน IPSEC ที่รวดเร็ว แต่หากปัญหาเริ่มต้น เราจะเตะเซิร์ฟเวอร์เหล่านี้ออกจากอัปสตรีมอย่างรวดเร็วและไม่กี่นาที และส่งการรับส่งข้อมูลผ่าน CEN เท่านั้น จนกว่าอุโมงค์จะเสถียร

การนำโซลูชันที่ 4 จากรายการด้านบนไปใช้ทำให้เราบรรลุสิ่งที่เราต้องการและสิ่งที่ธุรกิจต้องการจากเรา ณ เวลานั้น

ผลการทดสอบเบราว์เซอร์สำหรับโซลูชันใหม่เมื่อเปรียบเทียบกับเวอร์ชันก่อนหน้า:

การตัดสิน
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

ทุกอย่างดีในโซลูชันที่เรานำไปใช้ แต่ไม่มี CDN ที่สามารถเร่งการรับส่งข้อมูลในระดับภูมิภาคและระดับเมืองได้ ตามทฤษฎีแล้ว สิ่งนี้ควรเพิ่มความเร็วให้กับไซต์สำหรับผู้ใช้ปลายทางโดยใช้ช่องทางการสื่อสารที่รวดเร็วของผู้ให้บริการ CDN และเราก็คิดเกี่ยวกับมันตลอดเวลา และตอนนี้ก็ถึงเวลาสำหรับการทำซ้ำโครงการครั้งต่อไป: ค้นหาและทดสอบผู้ให้บริการ CDN ในประเทศจีน

และฉันจะเล่าให้คุณฟังในเรื่องนี้ในตอนหน้าตอนสุดท้าย :)

ที่มา: will.com