Hai
Setiap cerita bagus berakhir. Dan kisah kami tentang bagaimana kami menemukan solusi untuk peralihan yang cepat dari Firewall Cina tidak terkecuali. Karena itu, saya cepat-cepat membagikan kepada Anda bagian terakhir dan terakhir tentang topik ini.
Pada bagian sebelumnya, kami berbicara tentang banyak bangku tes yang diciptakan oleh kami, dan hasil apa yang mereka berikan. Dan kami sepakat pada kenyataan bahwa akan menyenangkan untuk menambahkan CDN! untuk viskositas ke sirkuit kami.
Saya akan memberi tahu Anda bagaimana kami menguji Alibaba Cloud CDN, Tencent Cloud CDN dan Akamai, dan apa yang akhirnya saya lakukan. Dan tentu saja, untuk meringkas.
Alibaba Cloud CDN
Kami di-host di Alibaba Cloud, kami menggunakan IPSEC dan CEN dari mereka. Adalah logis untuk mencoba solusi mereka terlebih dahulu.
Alibaba Cloud memiliki dua jenis produk yang sesuai dengan kami: CDN dan DCDN . Opsi pertama adalah CDN klasik untuk domain (subdomain) tertentu. Pilihan kedua adalah Dynamic Route untuk CDN (saya menyebutnya Dynamic CDN), dapat dinyalakan dalam mode Full-site (untuk wildcard domains), itu juga menyimpan statika dan mempercepat konten dinamis pada dirinya sendiri, yaitu dinamika halaman juga akan memuat dengan cepat penyedia jaringan. Ini penting bagi kami, karena pada dasarnya situs kami dinamis, ia menggunakan banyak subdomain, dan lebih mudah untuk mengkonfigurasi CDN satu kali untuk "bintang" - * .semrushchina.cn.
Kami sudah melihat produk ini pada tahap awal proyek China kami, tetapi kemudian tidak berhasil, dan pengembang berjanji bahwa produk tersebut akan tersedia untuk semua pelanggan segera. Dan dia menjadi.
Di DCDN, Anda dapat:
- konfigurasikan terminasi SSL dengan sertifikat Anda,
- aktifkan akselerasi konten dinamis,
- fleksibel mengkonfigurasi cache file statis,
- melakukan pembersihan cache,
- membuang soket web,
- aktifkan kompresi dan bahkan HTML Beautifier.
Secara umum, semuanya seperti orang dewasa dan penyedia CDN besar.
Setelah Asal (tempat di mana server tepi CDN akan pergi) diindikasikan, maka ia tetap membuat CNAME untuk tanda bintang, menautkan ke all.semrushchina.cn.w.kunluncan.com (CNAME ini diperoleh di konsol Cloud Alibaba), dan CDN akan bekerja.
Menurut hasil tes, CDN ini banyak membantu kami. Statistik diberikan di bawah ini.
Ini adalah hasil yang sangat baik, terutama jika kita membandingkannya dengan angka apa yang ada di awal. Tetapi kami tahu bahwa uji peramban versi Amerika untuk situs kami www.semrush.com bekerja dari Amerika Serikat rata-rata sebesar 8,3 (nilai yang sangat perkiraan). Ada banyak hal yang harus diperjuangkan. Selain itu, ada penyedia CDN yang tertarik dalam pengujian.
Jadi kami lancar pindah ke raksasa lain di pasar Cina - Tencent .
Tencent cloud
Tencent hanya mengembangkan cloud-nya - ini terbukti dalam sejumlah kecil produk. Dalam perjalanan penggunaannya, kami ingin menguji tidak hanya CDN mereka, tetapi juga infrastruktur jaringan secara keseluruhan:
- Apakah mereka memiliki sesuatu yang mirip dengan CEN?
- Bagaimana cara kerja IPSEC untuk mereka? Apakah cepat, apa itu waktu aktif?
- Apakah mereka punya siaran?
Kami akan menganalisis pertanyaan-pertanyaan ini secara terpisah.
CEN analog
Tencent memiliki produk Cloud Connect Network ( CCN ) yang memungkinkan Anda untuk menghubungkan VPC dari berbagai wilayah, termasuk wilayah di Cina dan luar. Produk sekarang dalam versi beta internal, dan Anda perlu membuat tiket dengan permintaan untuk terhubung dengannya. Dari dukungan, kami mengetahui bahwa akun global (bukan tentang warga negara Tiongkok dan badan hukum) tidak dapat berpartisipasi dalam program pengujian beta dan umumnya menghubungkan wilayah di dalam Tiongkok dengan wilayah di luar. 1-0 untuk Ali Cloud
IPSEC
Wilayah paling selatan Tencent adalah Guangzhou . Kami membangun sebuah terowongan dan menghubungkannya dengan wilayah Hong Kong di GCP (maka wilayah ini sudah tersedia). Mereka juga mengangkat terowongan kedua ke Ali Cloud dari Shenzhen ke Hong Kong pada saat yang sama. Ternyata melalui jaringan laten Tencent, Hong Kong umumnya lebih baik (10 ms) dari dari Shenzhen ke Hong Kong ke Ali (120 ms - apa?). Tapi ini tidak mempercepat pekerjaan situs, yang bertujuan untuk bekerja melalui Tencent dan terowongan ini, yang dengan sendirinya adalah fakta yang menakjubkan dan sekali lagi membuktikan hal berikut: latensi - untuk Cina ini bukan indikator yang harus Anda perhatikan ketika mengembangkan solusi untuk melewati Cina firewall.
Akselerasi Internet Anycast
Produk lain yang memungkinkan Anda bekerja melalui IP siaran adalah AIA . Tetapi juga tidak dapat diakses ke akun global, jadi saya tidak akan menceritakannya, tetapi untuk mengetahui bahwa produk semacam itu ada mungkin berguna.
Namun tes CDN menunjukkan hasil yang cukup menarik. CDN Tencent tidak dapat diaktifkan di situs lengkap, hanya pada domain tertentu. Kami mendapat domain dan mulai lalu lintas di atasnya:
Ternyata CDN ini memiliki fungsi sebagai berikut: Optimasi Lalu Lintas Lintas Batas . Fitur ini harus mengurangi biaya ketika lalu lintas mengalir melalui firewall Cina. Sebagai Asal , alamat IP Google GLB (GLB anycast) telah ditentukan. Jadi kami ingin menyederhanakan arsitektur proyek.
Hasilnya sangat baik - pada tingkat Ali Cloud CDN, dan di beberapa tempat bahkan lebih baik. Ini mengejutkan, karena jika tes berhasil, Anda dapat meninggalkan bagian penting dari infrastruktur, terowongan, CEN, mesin virtual, dll.
Kami tidak senang lama, karena masalahnya terungkap: tes di Catchpoint dipalsukan untuk penyedia Internet China Mobile. Dari lokasi mana pun, kami mendapat batas waktu melalui Tencent's CDN. Korespondensi dengan dukungan teknis tidak mengarah ke apa pun. Sekitar satu hari kami mencoba menyelesaikan masalah ini, tetapi tidak ada hasilnya.
Saya berada di China pada waktu itu, tetapi tidak dapat menemukan Wi-Fi publik di jaringan penyedia ini untuk memverifikasi masalah secara pribadi. Kalau tidak, semuanya tampak cepat dan bagus.
Namun, karena fakta bahwa China Mobile adalah salah satu dari tiga operator terbesar, kami terpaksa mengembalikan lalu lintas ke Ali CDN.
Tetapi secara umum, ini adalah solusi yang agak menarik, yang layak untuk pengujian dan pemecahan masalah yang lebih lama dari masalah ini.
Akamai
Penyedia CDN terakhir yang kami uji adalah Akamai . Ini adalah penyedia besar yang memiliki jaringan sendiri di Cina. Tentu saja, kami tidak bisa melewatinya.
Sejak awal, kami sepakat dengan Akamai pada masa uji coba sehingga kami dapat mengganti domain dan melihat cara kerjanya di jaringan mereka. Saya akan menjelaskan hasil dari semua pengujian dalam bentuk "Apa yang saya sukai" dan "Apa yang tidak saya sukai", serta hasil tes.
Apa yang kamu suka:
- Orang-orang dari Akamai banyak membantu dalam semua hal dan menemani kami di semua tahap pengujian. Terus berusaha meningkatkan sesuatu di pihak mereka. Mereka memberikan saran teknis yang bagus.
- Akamai berjalan sekitar 10-15% lebih lambat dari solusi kami melalui Ali Cloud CDN. Sangat mengesankan bahwa di Origin kami menentukan alamat IP GLB untuk Akamai, yaitu, lalu lintas tidak melalui solusi kami (Anda berpotensi dapat meninggalkan bagian dari infrastruktur). Tapi tetap saja, hasil tes menunjukkan bahwa solusi ini lebih buruk daripada versi kami saat ini (hasil perbandingan di bawah).
- Telah menguji Origin GLB dan Origin di China. Kedua opsi tersebut hampir sama.
- Ada Rute Pasti (optimasi rute otomatis). Anda dapat meng-host objek pengujian pada Origin, dan Edge server Akamai akan mencoba mengambilnya (GET biasa). Untuk permintaan ini, kecepatan dan metrik lainnya diukur, atas dasar jaringan Akamai mengoptimalkan rute sehingga lalu lintas berjalan lebih cepat untuk situs kami dan dapat dilihat bahwa dimasukkannya fitur ini benar-benar memiliki pengaruh besar pada kecepatan situs.
- Versi konfigurasi di antarmuka web itu keren. Anda dapat melakukan Bandingkan untuk versi, lihat perbedaan. Lihat versi sebelumnya.
- Anda dapat meluncurkan versi baru hanya pada jaringan Akamai Staging - jaringan yang sama dengan produksi, hanya saja cara ini tidak memengaruhi pengguna nyata. Untuk pengujian ini, Anda perlu memalsukan catatan DNS di mesin lokal.
- Kecepatan unduh yang sangat cepat melalui jaringan statika besar mereka, dan, tampaknya, dari file lainnya. File dari cache "dingin" diambil beberapa kali lebih cepat dari file yang sama dari cache CDN Ali "dingin". Dari cache "panas", kecepatan sudah plus atau minus sama.
Tes Ali CDN:
root@shenzhen1:~
Tes Akamai:
root@shenzhen1:~
Kami memperhatikan bahwa situasi dari contoh di atas tergantung pada berbagai faktor. Pada saat penulisan ini, saya menjalankan tes lagi. Hasil untuk kedua platform kurang lebih sama. Ini memberitahu kita bahwa Internet di Cina, bahkan untuk operator besar dan penyedia cloud, berperilaku berbeda dari waktu ke waktu.
Saya akan menambahkan nilai tambah besar untuk Akamai pada paragraf sebelumnya: jika Ali menunjukkan kilasan berkinerja tinggi dan sangat rendah (ini berlaku untuk Ali CDN, dan Ali CEN, dan Ali IPSEC), maka di Akamai setiap saat, tidak peduli bagaimana saya menguji jaringan mereka, semua bekerja dengan stabil.
Akamai benar-benar memiliki banyak jangkauan di Tiongkok dan bekerja melalui banyak penyedia.
Apa yang tidak suka:
- Saya tidak suka antarmuka web dan skema kerja - ini nol. Tetapi pada dasarnya Anda terbiasa (mungkin).
- Hasil tes lebih buruk daripada situs kami.
- Ada lebih banyak kesalahan selama pengujian daripada di situs kami (waktu aktif di bawah).
- Tidak ada server DNS di Cina. Dari sini ada banyak kesalahan dalam pengujian karena DNS menyelesaikan batas waktu.
- Jangan berikan rentang IP mereka -> tidak ada cara untuk mendaftarkan set_real_ip_from yang benar di server kami.
Metrik (~ 3626 berjalan; semua metrik kecuali Uptime dalam ms; statistik untuk satu periode waktu):
Distribusi persentil (dalam ms):
Kesimpulannya adalah ini: opsi dengan Akamai layak, tetapi tidak memberikan stabilitas dan kecepatan indikator yang sama dengan solusi kami sendiri, ditambah dengan Ali CDN.
Catatan kecil
Beberapa poin tidak dimasukkan dalam cerita, tetapi saya juga ingin menulis tentangnya.
Beijing + Tokyo dan Hong Kong
Seperti yang saya katakan di atas, kami menguji terowongan IPSEC ke Hong Kong (HK). Tapi kami juga menguji CEN sebelum HK. Harganya sedikit lebih murah, dan itu menarik bagaimana itu akan bekerja antara kota-kota dengan jarak ~ 100km. Ternyata menarik bahwa latensi antara kota-kota ini adalah 100 ms lebih tinggi daripada versi asli kami (ke Taiwan). Kecepatan, stabilitas juga lebih baik untuk Taiwan. Akibatnya, kami meninggalkan HK sebagai wilayah IPSEC cadangan.
Selain itu, kami mencoba meningkatkan instalasi seperti itu:
- pemutusan pelanggan di Beijing,
- IPSEC dan CEN ke Tokyo,
- di Ali, CDN terdaftar sebagai server asal di Beijing.
Skema ini tidak begitu stabil, meskipun dalam hal kecepatan secara keseluruhan tidak kalah dengan solusi kami. Adapun terowongan, saya melihat tetes berkala bahkan untuk CEN, yang seharusnya stabil. Karena itu, kami kembali ke skema lama dan membongkar panggung ini.
Di bawah ini adalah statistik tentang latensi antara berbagai wilayah di berbagai saluran. Mungkin seseorang akan tertarik.
IPsec
Ali cn-beijing <--> GCP asia-timur laut1 - 193ms
Ali cn-shenzhen <--> GCP asia-east2 - 91ms
Ali cn-shenzhen <--> GCP us-east4 - 200ms
Cen
Ali cn-beijing <---> Ali ap-timur laut 1 - 54ms (!)
Ali cn-shenzhen <---> Ali cn-hongkong - 6ms (!)
Ali cn-shenzhen <---> Ali us-east1 - 216ms
Sebagai tambahan masalah dengan Internet, dijelaskan di bagian paling awal, di bagian pertama artikel.
- Internet di China di dalamnya cukup cepat.
- Kesimpulan dibuat berdasarkan pengujian jaringan Wi-Fi publik di berbagai lokasi di mana jaringan ini digunakan oleh sejumlah besar orang.
- Kecepatan unduh dan unggah ke server di China masing-masing sekitar 20 Mbps dan 5-10 Mbps.
- Kecepatan ke server di luar China hanya menyedihkan, kurang dari 1 Mbps.
- Internet di Cina tidak begitu stabil.
- Terkadang situs dapat dibuka dengan cepat, terkadang lambat (pada waktu yang sama setiap hari pada hari yang berbeda), asalkan konfigurasi tidak berubah. Kami mengamati ini dengan contoh semrushchina.cn. Ini dapat dikaitkan dengan Ali CDN, yang juga bekerja dengan cara ini dan itu, tergantung pada waktu, posisi bintang-bintang, dll.
- Internet seluler hampir di mana-mana 4G atau 4G +. Tangkapan di kereta bawah tanah, lift - singkatnya, di mana-mana.
- Fakta bahwa pengguna China hanya mempercayai domain di zona .cn adalah mitos. Kami mempelajari ini langsung dari pengguna.
- Anda dapat melihat bagaimana http://baidu.cn mengalihkan ke www.baidu.com (di daratan Cina juga).
- Banyak sumber daya benar-benar diblokir. Primitive: google.com, Facebook, Twitter. Tetapi banyak sumber daya Google berfungsi (tentu saja, tidak semua Wi-Fi dan VPN digunakan pada saat yang sama (di sisi router, itu sudah pasti).
- Banyak "teknis" domain perusahaan yang diblokir juga berfungsi. Ini berarti bahwa Anda tidak harus selalu gegabah memotong semua Google dan sumber daya lainnya yang tampaknya diblokir. Anda perlu mencari beberapa daftar domain terlarang.
- Mereka hanya memiliki tiga penyedia Internet utama: China Unicom, China Telecom, China Mobile. Bahkan ada yang lebih kecil, tetapi pangsa pasar mereka tidak signifikan
Bonus: skema keputusan akhir
Ringkasan
Setahun telah berlalu sejak awal proyek. Kami mulai dengan fakta bahwa situs kami pada dasarnya menolak untuk bekerja secara normal dari China, tetapi hanya GET curl memerlukan waktu 5,5 detik.
Kemudian, dengan indikator seperti itu dalam keputusan pertama (Cloudflare):
Akibatnya, kami sampai pada hasil berikut (statistik untuk bulan lalu):
Seperti yang Anda lihat, waktu aktif 100% belum tercapai, tetapi kami akan menghasilkan sesuatu, dan kemudian kami akan memberi tahu Anda tentang hasil di artikel baru :)
Untuk orang yang telah membaca ketiga bagian sampai akhir - hormat. Saya harap Anda semua sama tertariknya dengan saya ketika saya melakukan ini.
PS Bagian Sebelumnya
Bagian 1
Bagian 2