Halo semuanya!
Sentuhan Nikita adalah seorang insinyur sistem dari SEMrush . Hari ini saya akan memberi tahu Anda tentang bagaimana kami menghadapi tugas memastikan stabilitas layanan semrush.com kami di Cina, dan masalah apa yang kami temui selama penerapannya (mengingat lokasi pusat data kami di pantai timur AS).
Ini akan menjadi kisah yang hebat, dibagi menjadi beberapa artikel. Saya akan memberi tahu Anda bagaimana semuanya terjadi pada kami: dari layanan yang sama sekali tidak bekerja dari Tiongkok hingga kinerja layanan di tingkat versi Amerika untuk orang Amerika. Saya berjanji ini akan menarik dan bermanfaat. Jadi ayo pergi.
Masalah internet Cina
Bahkan orang yang paling jauh dari spesifikasi administrasi jaringan setidaknya pernah mendengar tentang Great Chinese Firewall . Eh, kedengarannya keren, ya? Tapi apa itu, bagaimana cara kerjanya sebenarnya adalah pertanyaan yang agak rumit. Di Internet Anda dapat menemukan banyak artikel tentang ini, tetapi dari sudut pandang teknis, perangkat firewall ini tidak dijelaskan di mana pun. Namun, yang tidak mengejutkan. Saya langsung mengakui bahwa, berdasarkan hasil tahun kerja, saya tidak bisa mengatakan dengan tepat bagaimana cara kerjanya, tetapi saya bisa memberi tahu tentang komentar dan kesimpulan praktis saya. Dan kita akan mulai dengan rumor tentang firewall ini.
Ada banyak rumor tentang firewall ini. Mari kita kumpulkan yang utama dan paling menarik dari mereka ke dalam satu daftar:
- Google, Facebook, Twitter, dan layanan serupa lainnya diblokir dan tidak berfungsi di Cina.
- Setiap lalu lintas yang pergi ke luar Cina dan ke China diurai dan dibatasi oleh pembelajaran mesin (dalam hal lalu lintas yang mencurigakan), yang sangat memperlambatnya (lalu lintas) melewati perbatasan.
- Badan intelijen Cina membongkar semua lalu lintas terenkripsi yang melewati firewall mereka.
- Terowongan VPN, terowongan IPSEC tidak stabil, jatuh dan terus-menerus diblokir.
- Semakin sederhana enkripsi, semakin sederhana frasa sandi yang digunakan untuk otentikasi / sandi lalu lintas, semakin cepat ia melewati firewall Cina.
Inilah yang berhasil kami ketahui tentang rumor ini:
- Google, Facebook, Twitter, dan layanan serupa lainnya benar-benar diblokir (KO Anda), tetapi banyak domain teknis Google, misalnya, tidak dilarang dan berfungsi (gstatic.com yang sama). Ini mengarah pada kesimpulan: jangan sembarangan memotong semua Google dan sumber daya lain yang tampaknya diblokir, tampaknya diblokir.
- Setiap lalu lintas yang melewati perbatasan benar-benar menambah waktu yang serius. Lihatlah dua hasil. Satu situs, satu halaman, dapatkan ikal sederhana. Pengukuran pertama dari Cina itu sendiri (kota Shenzhen yang indah). Yang kedua membeku di luar dari Hong Kong (memiliki kedaulatan, dan tidak ada firewall antara itu dan dunia). Jarak antara kota-kota di garis lurus adalah sekitar 30-40 km.
nikita@china-shenzhen:~
Perhatikan time_connect . Dan secara umum, Anda melihat hasilnya: firewall menambahkan 4 detik ekstra, yang sangat panjang.
- Terowongan VPN dan IPSEC sering jatuh. Saya akan membicarakan hal ini nanti dan lebih terinci. Server VPN yang digunakan oleh pengguna diblokir dari waktu ke waktu (biasanya dalam satu hari setelah dimulainya penggunaan).
- Ada pendapat yang diterima dari orang-orang yang tinggal di China bahwa semakin mudah enkripsi lalu lintas, semakin cepat melewati perbatasan, karena mudah dipahami bahwa tidak ada yang ilegal di dalamnya. Dan sama seperti lalu lintas "bersih" mendapat lebih banyak bandwidth dan kecepatan, dan lalu lintas "kotor", yang tidak menghasilkan apa-apa, sebaliknya mendapat umpan lambat. Sebagai contoh, saya akan membawa curl ke ifconfig.co menggunakan protokol HTTPS dan 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
Perbedaannya adalah 5 detik untuk total waktu muat 13 byte. Saat melakukan tes ini beberapa kali, Anda dapat melihat bahwa GET pada HTTP selesai secara umum dalam waktu yang sama setiap waktu, saat menggunakan HTTPS situs terkadang merespons dalam 3, 5, 10, dan bahkan 17 detik. Kesalahan SSL terkadang terjadi:
Unknown SSL protocol error in connection to ifconfig.co:443.
Jadi apa yang kita miliki:
- Masalah yang dibuat oleh firewall Cina yang dijelaskan di atas.
- Ping ke sumber daya eksternal dan terowongan di dalam menghilang secara berkala.
- Latensi antara dua titik terus berubah, dan seringkali tidak dapat diprediksi. Dengan menghubungkan berbagai kota / wilayah, Anda berharap bahwa berdasarkan lokasi geografis dari wilayah tersebut, penundaannya akan berkurang, dan Anda mendapatkan situasi yang sebaliknya.
- Saluran Internet dan komunikasi cepat atau lambat. Ada sedikit ketergantungan pada waktu hari dan hari dalam seminggu, tetapi tidak selalu.
- Permintaan DNS ke dunia luar dari Tiongkok terkadang melebihi batas waktu yang diizinkan.
Gambar tampak "sangat baik".
Pusat data, seperti yang saya katakan, berada di sebelah timur Amerika Serikat, dan seluruh SEMrush terdiri dari lusinan produk yang saling berhubungan, backend, ujung depan, basis data, dan semua ini di pusat data dan di awan. Sebagai tim administrator sistem, kami ditugaskan dengan upaya kecil untuk segera mulai bekerja di Cina.
Kami harus menjawab pertanyaan penting: dapatkah kami bertahan dengan sedikit darah dan menyelesaikan semua masalah yang terkait dengan Internet Cina dan firewall di tingkat jaringan / cloud / server?
Kami mulai dengan mendapatkan lisensi ICP .
Lisensi ICP
Agar dapat menempatkan layanan Anda di China (Daratan China) dan melakukan tes, Anda harus terlebih dahulu mendapatkan lisensi domain ICP.
Jika lalu lintas pengguna situs Anda diakhiri di Daratan China, dan jika domain Anda tidak memiliki lisensi ICP, lalu lintas Anda akan diblokir di sisi penyedia / hosting. Menariknya, penyedia tertentu cocok dengan lisensi ICP, baik itu Cloudflare atau Alibaba Cloud. Oleh karena itu, jika Anda menerima lisensi ICP untuk Cloudflare dan meng-host situs Anda dengan mereka, maka Anda tidak akan dapat "bergerak mulus" ke Alibaba Cloud. Anda harus menambahkan satu hosting lagi ke lisensi ini.
Setelah menerima lisensi domain ICP, kami dapat menemukan dan menerapkan ide dan solusi teknis tertentu.
Solusi Pengujian
Tetapi sebelum Anda secara langsung membuat opsi untuk pementasan, memutar kenop, mengoptimalkan situs dan kecepatannya, Anda perlu memilih alat untuk mengujinya untuk melihat apa yang tindakan kami meningkatkan atau memperburuk pekerjaan situs.
Alat pengujian kami harus memenuhi dua persyaratan utama:
- dia harus bisa menjalankan tes dari China,
- Itu harus memiliki tes browser.
Jadi kami menemukan titik tangkap ! Mereka memiliki jangkauan yang sangat baik dengan titik uji di seluruh dunia. Di Cina, melalui alat ini, Anda juga dapat menjalankan tes dari 100.500 provinsi. Di masing-masing, beberapa penyedia berbeda + kemampuan untuk melakukan tes Backbone (sesuatu seperti mesin virtual di pusat data) dan tes Lastmile (sedekat mungkin dengan kondisi pengguna, alias workstation). Jenis tes yang terakhir lebih mahal.
Setelah menyelesaikan kontrak satu tahun (Anda tidak bisa berbuat lebih sedikit), kami mulai mempelajari alat ini. Terus terang, kami sangat terkejut dengan fungsinya. Anda dapat menjalankan:
- Tes DNS
- Tes web (browser, GET / POST sederhana, emulasi klien seluler, dll.),
- Pemeriksaan transaksional (mis. Login),
- Tes API
- Ping, traceroute, NTP, dll.
Anda tidak bisa mendaftar semuanya. Dan yang paling penting, setiap tes dapat disesuaikan dengan cukup baik dengan menambahkan banyak header dan parameter lainnya. Outputnya adalah sejumlah besar informasi yang sepenuhnya menggambarkan pengujian Anda. Jika kita berbicara tentang yang paling menarik bagi kita (uji peramban), maka hasilnya termasuk:
- Hubungkan, Tunggu, Muat, SSL, waktu DNS,
- TTFB, TTLB, Dokumen lengkap, Waktu render, beban DOM,
- Respons (sesuatu yang dekat dengan Time To First Byte), Respons Webpage (sesuatu yang dekat dengan Time To Last Byte),
- Persentil apa pun, Sedang, Rata-rata waktu
- Dll
Karenanya, semua metrik ini membantu Anda melihat perubahan dan memahami apakah itu telah menjadi lebih baik. Kami terutama melihat Respon, Respons Halaman Web, Median, 75 dan 95 Persentil .
Sebuah pertanyaan penting yang telah mengemuka sejak awal: apakah mungkin untuk mempercayai Catchpoint ? Apakah alat ini mencerminkan kecepatan pemuatan situs nyata di Tiongkok dari kota yang berbeda atau hanya semacam uji dalam ruang hampa yang tidak ada hubungannya dengan pengalaman pengguna nyata?
Ini adalah masalah besar, karena berada di Rusia hampir mustahil untuk menemukan cara kerja situs dari Tiongkok. Dengan melakukan socks-proxy melalui mesin virtual, Anda mendapatkan beban situs web dalam beberapa menit pada akhirnya, yang tidak dapat diterima untuk pengujian, sehingga satu-satunya pilihan untuk pengujian manual adalah curl dan GET sederhana dari konsol dengan pengukuran waktu. Ini membantu, karena tes ini mencerminkan kecepatan solusi jaringan, dan jika ada tes browser, ini sangat bagus.
Kemudian, kami pergi ke China sendiri dan memastikan bahwa Catchpoint dapat dipercaya, cukup akurat mencerminkan indikator kecepatan yang sebenarnya.
Jaringan cloudflare china
Karena kami berhasil menggunakan Cloudflare untuk domain semrush.com utama, kami memutuskan untuk segera mencoba fitur mereka yang disebut China Network . Opsi ini diaktifkan hanya untuk situs Enterprise atas permintaan dan dengan biaya. Ini juga tersedia hanya untuk situs-situs yang memiliki lisensi ICP yang sesuai, di mana Cloudflare ditetapkan sebagai penyedia. Setelah dimasukkan, "CDN Cina" dari Cloudflare menjadi tersedia untuk situs - lalu lintas dari wilayah China mendarat di PoP (Points of Presence) CF berikutnya, dan kemudian dikirim ke asal melalui jaringan atau jaringan penyedia / mitra.
Skema bangku tes ini disajikan di bawah ini.
Ini pilihan yang bagus untuk kita. Ternyata domain kedua juga untuk CF, yang tidak menambah jumlah solusi yang digunakan di perusahaan, dan juga praktis tidak menyulitkan infrastruktur.
Kami menjalankan tes browser, dan inilah yang terjadi:
Berlian merah adalah file uji. File-file di bawah ini adalah kesalahan DNS (mengatasi batas waktu). Yang gagal di atas adalah batas waktu.
Waktu aktif: 86,6
Median: 18-an
75 Persentil: 29,3d
95 Persentil: 60-an
Median, setelah menghapus unduhan reCaptcha (layanan Google diblokir di Cina), menurun dari 28 menjadi 18 detik. Tapi tetap saja, ini adalah indikator yang mengerikan, mengingat bahwa tes yang sama untuk semrush.com (dari AS) memberi kurang dari 10 detik untuk 95% pengguna (dari AS) ke halaman yang sama (statika + dinamika).
Dalam setiap tes, Anda dapat pergi dan melihat Air Terjun dan parameter lainnya yang lebih rinci. Kami mulai menyelidiki penyebab kesalahan, dan jika untuk timeout semuanya kurang atau kurang jelas: Internet di China "bergerak turun, lalu pindah", karena kecepatan koneksi dan pemuatan sumber daya dari luar negeri tidak stabil dan tidak merata, maka kesalahan DNS sangat mengejutkan kami. . Kami menemukan bahwa PoP Cloudflare memang terletak di China, alamat situs memutuskan untuk IP anycast tunggal, tetapi server DNS digunakan oleh AS, itulah sebabnya mengapa permintaan DNS dipaksa untuk melewati perbatasan, jadi kadang-kadang gagal.
Setelah mengklarifikasi pertanyaan ini dengan CF, ternyata mereka tidak memiliki server DNS sendiri di China , dan kapan itu masih belum diketahui.
Oleh karena itu, kami memutuskan untuk menguji hanya Cloudflare DNS dan mengubah mekanisme Cloudflare untuk situs kami ke mode " DNS Only ". Ini adalah mode seperti itu ketika Cloudflare tidak mem-proxy traffic dengan sendirinya, yang berarti itu tidak memberikan perlindungan DDoS, CDN dan fitur-fitur lainnya, dan bekerja dalam mode server DNS biasa.
Stand ini ditunjukkan secara skematis pada gambar berikut. Angka tersebut memperhitungkan pengetahuan yang muncul bahwa server Cloudflare DNS berada di belakang firewall.
Di Catchpoint, kami menjalankan tes GET sederhana (non-browser) yang menunjukkan banyak kegagalan. Alasan mereka adalah semua kesalahan DNS yang sama.
Kami mulai men-debug kesalahan ini menggunakan menggali dan menemukan bahwa alamat ditentukan dengan benar pada permintaan pertama, dan pada permintaan berulang kami mendapatkan SERVFAIL dan tidak ditemukan setiap kali. Tiba-tiba apa itu?
root@iZwz97n2wgbp61qucbfrjsZ:~
Saat meminta server Cloudflare NS secara langsung, tidak ada kesalahan seperti itu:
root@iZwz97n2wgbp61qucbfrjsZ:~
Ini berarti bahwa masalahnya ada di sisi server DNS "lokal" atau server penyedia.
Investigasi lebih lanjut menunjukkan bahwa kami mendapatkan SERVFAIL pada resolusi catatan AAAA .
Ternyata ketika Cloudflare meminta catatan AAAA yang tidak ada dalam domain, Cloudflare merespons dengan catatan A , yang merupakan kesalahan dan ketidakcocokan RFC. Karena itu resolver lokal ( xxxx ) tidak suka ini, dan itu menjawab SERVFAIL . Dalam log di bawah ini perilaku ini terlihat jelas:
root@iZwz97n2wgbp61qucbfrjsZ:~
Kami mengirim laporan bug Cloudflare, dan mereka memperbaikinya setelah beberapa saat. Ternyata menarik: saat ini, masih belum ada dukungan IPv6 di Cina, sehingga Cloudflare tidak bisa memberikan alamat IPv6 sebagai tanggapan atas permintaan untuk catatan AAAA . Pada akhirnya, semuanya diputuskan sehingga untuk China Cloudflare mulai menanggapi NODATA untuk permintaan tersebut.
Jadi, kesalahan DNS dalam tes Catchpoint menurun tajam, tetapi tidak sampai akhir. Timeout juga tidak hilang:
Dan kami mulai mencari solusi lain.
Pada bagian selanjutnya saya akan memberi tahu bagaimana kami menguji Cloud China Alibaba , bagaimana dengan bantuan sedikit "sihir" Nginx kami dapat dengan cepat membuat solusi PoC (Proof of Concept), bagaimana kami menciptakan solusi Multi-Cloud, yang salah satunya akhirnya banyak membantu. mempercepat layanan dari Cina.
Tetap disini!
Semua bagian
Bagian 2
Bagian 3