Hello!
Nikita berhubungan - seorang insinyur sistem dari perusahaan SEMrush. Hari ini saya akan memberi tahu Anda tentang bagaimana kami menghadapi tugas untuk memastikan stabilitas layanan semrush.com kami di Tiongkok, dan masalah apa yang kami temui selama penerapannya (mengingat lokasi pusat data kami di pantai timur Amerika Serikat).
Ini akan menjadi cerita besar, dibagi menjadi beberapa artikel. Saya akan memberi tahu Anda bagaimana hal itu terjadi pada kami: dari layanan yang sepenuhnya tidak berfungsi dari Tiongkok, hingga indikator kinerja layanan pada tingkat versi Amerika untuk orang Amerika. Saya berjanji itu akan menarik dan bermanfaat. Jadi, ayo pergi.
Masalah Internet Cina
Bahkan orang yang paling paham tentang administrasi jaringan pun pernah mendengarnya Firewall Besar Tiongkok. Wah, kedengarannya keren ya? Tapi apa itu dan bagaimana cara kerjanya adalah pertanyaan yang agak rumit. Anda dapat menemukan banyak artikel di Internet yang membahas hal ini, tetapi dari sudut pandang teknis, struktur firewall ini tidak dijelaskan di mana pun. Namun, hal ini tidak mengejutkan. Saya harus segera mengakui bahwa berdasarkan hasil kerja selama satu tahun, saya tidak dapat mengatakan secara pasti cara kerjanya, tetapi saya dapat memberi tahu Anda tentang komentar dan kesimpulan praktis saya. Dan kita akan mulai dengan rumor tentang firewall ini.
Ada banyak rumor tentang firewall ini. Mari kumpulkan yang utama dan paling menarik ke dalam satu daftar:
- Google, Facebook, Twitter, dan layanan serupa lainnya diblokir dan tidak berfungsi di Tiongkok.
- Setiap lalu lintas yang menuju LUAR Tiongkok dan KE Tiongkok diurai dan dibatasi menggunakan pembelajaran mesin (dalam kasus lalu lintas yang mencurigakan), yang sangat memperlambat (lalu lintas) yang melewati perbatasan.
- Badan intelijen Tiongkok akan meretas lalu lintas terenkripsi yang melewati firewall mereka.
- Terowongan VPN, terowongan IPSEC tidak stabil, macet, dan terus-menerus diblokir.
- Semakin sederhana enkripsinya, semakin sederhana frasa sandi yang digunakan untuk mengautentikasi/mengenkripsi lalu lintas, semakin cepat lalu lintas melewati firewall Tiongkok.
Inilah yang kami temukan tentang rumor tersebut:
- Google, Facebook, Twitter, dan layanan serupa lainnya memang diblokir (KO Anda), tetapi banyak domain teknis Google, misalnya, tidak dilarang dan berfungsi (gstatic.com yang sama). Kesimpulannya adalah: Anda tidak boleh sembarangan menghapus semua Google dan sumber daya lain yang tampaknya diblokir.
- Setiap lalu lintas yang melewati perbatasan benar-benar menambah penundaan waktu yang serius. Lihatlah kedua hasilnya. Satu situs, satu halaman, GET sederhana keriting'ya ampun. Pengukuran pertama dilakukan dari China sendiri (kota indahnya Shenzhen). Yang kedua diukur dari luar Hong Kong (negara ini mempunyai kedaulatan, dan tidak ada tembok pemisah antara negara tersebut dan dunia). Jarak antar kota dalam satu garis lurus kurang lebih 30-40 km.
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/sPerhatikan waktu_koneksi. Dan secara umum, Anda melihat hasilnya: firewall menambahkan 4 detik ekstra, yang sangat lama.
- Terowongan VPN dan IPSEC sering gagal. Saya akan membicarakan ini nanti dan lebih terinci. Server VPN yang digunakan oleh pengguna diblokir seiring waktu (biasanya dalam satu hari setelah mulai digunakan).
- Ada pendapat yang diterima dari masyarakat yang tinggal di Tiongkok bahwa semakin sederhana enkripsi lalu lintas, semakin cepat melewati perbatasan, karena mudah dipahami bahwa tidak ada yang ilegal di dalamnya. Dan dengan cara yang sama, lalu lintas “bersih” menerima lebih banyak bandwidth dan kecepatan perjalanan, sedangkan lalu lintas “kotor”, di mana tidak ada yang dapat dipahami, sebaliknya, menerima jalur yang lebih lambat. Misalnya saya akan menggunakan curl untuk ifconfig.co melalui HTTPS dan protokol 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/sSelisih 5 detik dengan total waktu pengunduhan 13 byte. Selain itu, saat melakukan pengujian seperti itu beberapa kali, Anda akan melihat bahwa GET di HTTP umumnya diselesaikan dalam waktu yang sama setiap kali, sedangkan di HTTPS situs terkadang merespons dalam 3, 5, 10, dan bahkan 17 detik. Terkadang kesalahan SSL terjadi:
Unknown SSL protocol error in connection to ifconfig.co:443.
Jadi apa yang kita punya:
- Masalah yang disebabkan oleh firewall Tiongkok dijelaskan di atas.
- Ping ke sumber daya eksternal dan di dalam terowongan menghilang secara berkala.
- Latensi antara dua titik terus berubah dan sering kali tidak dapat diprediksi. Saat menghubungkan kota/wilayah yang berbeda, Anda berharap, berdasarkan lokasi geografis wilayah tersebut, penundaannya akan lebih sedikit, namun yang Anda dapatkan justru situasi sebaliknya.
- Internet dan saluran komunikasi cepat atau lambat. Ada sedikit ketergantungan pada waktu dan hari dalam seminggu, tetapi tidak selalu.
- Permintaan DNS ke dunia luar dari Tiongkok terkadang melebihi batas waktu yang diizinkan.
Gambaran yang muncul sungguh “luar biasa.”
Pusat datanya, seperti yang sudah saya katakan, berada di Amerika Serikat bagian timur, dan seluruh SEMrush terdiri dari lusinan produk, backend, frontend, database yang saling berhubungan, dan semua ini di DC dan cloud. Kami, sebagai tim administrator sistem, diberi tugas untuk segera mulai bekerja di Tiongkok dengan sedikit usaha.
Kami harus menjawab pertanyaan penting: apakah mungkin bertahan dengan sedikit biaya dan menyelesaikan semua masalah yang terkait dengan Internet Tiongkok dan firewall di tingkat jaringan/cloud/server?
Kami mulai dengan menerima .
lisensi ICP
Agar dapat menghosting layanan Anda di Tiongkok (Tiongkok Daratan) dan melakukan pengujian, Anda harus terlebih dahulu mendapatkan lisensi ICP untuk domain tersebut.
Jika lalu lintas pengguna situs Anda dihentikan di Tiongkok Daratan, dan jika domain Anda tidak memiliki lisensi ICP, lalu lintas Anda akan diblokir di sisi ISP/hosting. Menariknya, lisensi ICP mencakup penyedia tertentu, baik itu Cloudflare atau Alibaba Cloud. Oleh karena itu, jika Anda menerima lisensi ICP untuk Cloudflare dan menghosting situs web Anda dengan lisensi tersebut, Anda tidak akan dapat berpindah secara “mulus” ke Alibaba Cloud. Anda perlu menambahkan hosting lain ke lisensi ini.
Setelah menerima lisensi ICP untuk domain tersebut, kami dapat menghasilkan dan menerapkan ide dan solusi teknis tertentu.
Solusi pengujian
Namun sebelum Anda langsung membuat opsi pementasan, memutar kenop, mengoptimalkan kinerja situs dan kecepatannya, Anda perlu memilih alat untuk mengujinya guna melihat tindakan kami yang mana yang meningkatkan atau, sebaliknya, memperburuk kinerja situs.
Alat pengujian kami harus memenuhi dua persyaratan utama:
- mereka harus bisa menjalankan tes dari Tiongkok,
- itu harus memiliki tes browser.
Jadi kami menemukan ! Mereka memiliki cakupan lokasi pengujian yang sangat baik di seluruh dunia. Di Tiongkok, tes juga dapat dilakukan di 100500 provinsi melalui alat ini. Masing-masing memiliki beberapa penyedia berbeda + kemampuan untuk melakukannya Tulang punggung-tests (sesuatu seperti mesin virtual di pusat data) dan mil terakhir-tests (sedekat mungkin dengan kondisi pengguna alias workstation). Jenis tes yang terakhir ini lebih mahal.
Setelah menyelesaikan kontrak tahunan (kurang dari itu tidak mungkin), kami mulai mempelajari instrumen tersebut. Sejujurnya, kami sangat terkejut dengan fungsinya. Anda dapat menjalankan:
- Tes DNS,
- Tes web (tes browser, GET/POST sederhana, emulasi klien seluler, dll.),
- Pemeriksaan transaksional (misalnya login),
- tes API,
- Ping, traceroute, NTP, dll.
Anda tidak dapat mencantumkan semuanya. Dan yang paling penting, setiap pengujian dapat dikustomisasi dengan baik dengan menambahkan banyak header dan parameter lainnya. Outputnya adalah sejumlah besar informasi yang sepenuhnya menggambarkan pengujian Anda. Jika kita berbicara tentang hal yang paling menarik bagi kami (tes browser), hasilnya meliputi:
- Hubungkan, Tunggu, Muat, SSL, waktu DNS,
- TTFB, TTLB, Dokumen selesai, Waktu render, Pemuatan DOM,
- Respons (mendekati Time To First Byte), Respons Halaman Web (mendekati Time To Last Byte),
- Persentil mana pun, Rata-rata, Waktu median
- Dll.
Oleh karena itu, semua metrik ini bagus untuk melihat perubahan dan memahami apakah segala sesuatunya menjadi lebih baik. Kami terutama melihat Respon, Respon Halaman Web, Median, Persentil 75 dan 95.
Sebuah pertanyaan penting yang sudah mengudara sejak awal: Bisakah Anda mempercayai Catchpoint?? Apakah alat ini mencerminkan kecepatan pemuatan situs sebenarnya di Tiongkok dari berbagai kota, atau hanya semacam pengujian dalam ruang hampa yang tidak ada hubungannya dengan pengalaman pengguna sebenarnya?
Ini adalah masalah besar, karena berada di Rusia hampir tidak mungkin untuk mengetahui cara kerja situs dari Tiongkok secara andal. Dengan melakukan proxy kaus kaki melalui mesin virtual, hasil akhirnya adalah situs dimuat dalam beberapa menit, yang tidak dapat diterima untuk pengujian, jadi satu-satunya pilihan untuk pengujian manual adalah curl dan GET sederhana dari konsol dengan pengatur waktu . Ini membantu karena tes ini mencerminkan dengan baik kecepatan solusi jaringan, dan jika ada juga tes browser, maka itu sangat bagus.
Kemudian kami sendiri pergi ke China dan yakin akan hal itu Anda dapat mempercayai Catchpoint; ini mencerminkan indikator kinerja sebenarnya dengan cukup akurat.
Jaringan Cloudflare Cina
Karena kami berhasil menggunakan Cloudflare untuk domain utama semrush.com, kami memutuskan untuk segera mencoba fitur mereka yang bernama . Opsi ini hanya diaktifkan untuk situs Perusahaan berdasarkan permintaan terpisah dan dengan biaya tambahan. Ini juga hanya tersedia untuk situs yang memiliki lisensi ICP sesuai yang mencantumkan Cloudflare sebagai penyedianya. Setelah mengaktifkannya, “CDN Tiongkok” dari Cloudflare akan tersedia untuk situs tersebut - lalu lintas dari wilayah Tiongkok mendarat di PoP (Points of Presence) CF terdekat, dan kemudian melalui jaringannya atau jaringan penyedia/mitra, lalu lintas dikirimkan ke asal .
Diagram bangku tes ini disajikan di bawah ini.
Ini adalah pilihan bagus bagi kami. Ternyata domain kedua juga untuk CF, yang tidak menambah jumlah solusi yang digunakan di perusahaan, dan juga praktis tidak mempersulit infrastruktur.
Kami menjalankan pengujian browser dan inilah yang terjadi:
Berlian merah adalah kegagalan ujian. File di bawah ini adalah kesalahan DNS (resolve timeout). Kegagalan di atas adalah batas waktu.
Waktu aktif: 86.6
Median: 18 detik
Persentil 75: 29.3 detik
Persentil 95: 60 detik
Median, setelah memuat telah dihapus reCAPTCHA (Layanan Google diblokir di Tiongkok) berkurang dari 28 menjadi 18 detik. Namun hasil ini masih buruk, mengingat pengujian yang sama untuk semrush.com (dari AS) memberikan waktu kurang dari 10 detik untuk 95% pengguna (dari AS) di halaman yang sama (statis + dinamis).
Anda dapat mengikuti setiap tes dan melihatnya Air terjun dan parameter lain yang lebih detail. Kami mulai menyelidiki alasan kesalahan tersebut, dan jika untuk batas waktu semuanya kurang lebih jelas: Internet di Tiongkok “bergerak masuk dan keluar”, karena itu kecepatan koneksi dan pemuatan sumber daya dari luar negeri tidak stabil dan tidak merata, kemudian kesalahan DNS sangat mengejutkan kami. Kami menemukan itu PoP Cloudflare sebenarnya berlokasi di Cina, alamat situsnya ditetapkan menjadi satu IP anycast, tetapi server DNSnya adalah Amerika, itulah sebabnya permintaan DNS terpaksa melintasi perbatasan, sehingga terkadang gagal.
Setelah mengklarifikasi pertanyaan ini dengan CF, ternyata demikian Mereka tidak memiliki server DNS sendiri di Tiongkok, dan kapan itu akan terjadi masih belum diketahui.
Oleh karena itu, kami memutuskan untuk hanya menguji Cloudflare DNS dan mengubah mekanisme operasi Cloudflare untuk situs kami menjadi “Hanya DNS" Ini adalah mode ketika Cloudflare tidak mem-proxy lalu lintas melalui dirinya sendiri, yang berarti Cloudflare tidak memberikan perlindungan DDoS, CDN, dan fitur lainnya, dan beroperasi dalam mode server DNS biasa.
Stand ini ditunjukkan secara skematis pada gambar berikut. Angka tersebut memperhitungkan pengetahuan yang muncul bahwa server DNS Cloudflare berada di balik firewall.
Di Catchpoint kami menjalankan pengujian GET sederhana (bukan pengujian browser), yang menunjukkan banyak kegagalan. Hal ini disebabkan oleh kesalahan DNS yang sama.
Kami mulai men-debug kesalahan ini menggunakan menggali dan menemukan bahwa atas permintaan pertama alamat ditentukan dengan benar, dan atas permintaan berulang kami menerima setiap kali SERVFAIL и tidak ditemukan. Mengapa ini terjadi secara tiba-tiba?
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)Saat menanyakan server Cloudflare NS secara langsung, tidak ada kesalahan seperti itu:
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.192Artinya masalahnya ada di sisi server DNS “lokal” atau server penyedia.
Penyelidikan lebih lanjut menunjukkan bahwa SERVFAIL kita bertekad AAAA-catatan.
Ternyata saat request ke Cloudflare AAAA-catatan yang tidak ada di domain, jawab Cloudflare А-entri yang merupakan kesalahan dan ketidakpatuhan terhadap RFC. Mengapa penyelesai lokal (xxx) Saya tidak menyukainya, dan dia menjawab SERVFAIL. Perilaku ini terlihat jelas pada log di bawah ini:
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
Kami mengirimkan laporan bug ke Cloudflare, dan mereka memperbaikinya setelah beberapa waktu. Ternyata menarik: saat ini masih belum ada dukungan IPv6 di China, sehingga Cloudflare tidak dapat mengeluarkan alamat IPv6-nya di sana sebagai tanggapan atas permintaan tersebut. AAAA-catatan. Pada akhirnya, semuanya terselesaikan sedemikian rupa sehingga Cloudflare mulai menjawab Tiongkok TIDAK ADA DATA untuk permintaan seperti itu.
Dengan demikian, kesalahan DNS dalam pengujian Catchpoint menurun tajam, namun tidak sepenuhnya. Batas waktu masih ada:
Dan kami mulai mencari solusi lain.
Di bagian selanjutnya saya akan memberi tahu Anda bagaimana kami menguji cloud Tiongkok Alibaba Cloud, bagaimana dengan bantuan sedikit “keajaiban” Nginx kita bisa dengan cepat menciptakan solusi PoC (Proof of Concept), bagaimana kita menciptakan solusi Multi-Cloud yang salah satunya pada akhirnya sangat membantu mempercepat kerja layanan tersebut dari Tiongkok.
Tetap disini!
Bagian selanjutnya
Sumber: www.habr.com
