Ciao a tutti!
Nikita è in contatto, un ingegnere di sistema dell'azienda SEMrush. Oggi vi parlerò di come abbiamo affrontato il compito di garantire la stabilità del nostro servizio semrush.com in Cina e di quali problemi abbiamo riscontrato durante la sua implementazione (data la posizione del nostro data center sulla costa orientale degli Stati Uniti).
Questa sarà una grande storia, divisa in diversi articoli. Ti racconterò come è successo tutto per noi: da un servizio completamente non funzionale dalla Cina agli indicatori di prestazione del servizio a livello della sua versione americana per gli americani. Prometto che sarà interessante e utile. Quindi andiamo.
Problemi dell'Internet cinese
Anche la persona più lontana dalle specificità dell'amministrazione di rete ne ha sentito parlare Il grande firewall cinese. Wow, sembra bello, vero? Ma cosa sia e come funzioni effettivamente è una questione piuttosto complicata. Su Internet si possono trovare molti articoli dedicati a questo, ma da un punto di vista tecnico la struttura di questo firewall non è descritta da nessuna parte. Il che, tuttavia, non sorprende. Ammetto subito che sulla base dei risultati di un anno di lavoro non potrò dire esattamente come funziona, ma posso raccontarvi i miei commenti e le mie conclusioni pratiche. E inizieremo con le voci su questo firewall.
Ci sono molte voci su questo stesso firewall. Raccogliamo i principali e più interessanti in un unico elenco:
- Google, Facebook, Twitter e altri servizi simili sono bloccati e non funzionano in Cina.
- Tutto il traffico in direzione FUORI dalla Cina e IN Cina viene analizzato e limitato utilizzando l'apprendimento automatico (in caso di traffico sospetto), che lo rallenta notevolmente (il traffico) che attraversa il confine.
- Le agenzie di intelligence cinesi hackereranno qualsiasi traffico crittografato che passa attraverso il loro firewall.
- I tunnel VPN, i tunnel IPSEC sono instabili, si bloccano e sono costantemente bloccati.
- Più semplice è la crittografia, più semplice è la passphrase utilizzata per autenticare/crittografare il traffico, più velocemente passerà attraverso il firewall cinese.
Ecco cosa abbiamo scoperto su queste voci:
- Google, Facebook, Twitter e altri servizi simili sono infatti bloccati (il tuo KO), ma molti domini tecnici di Google, ad esempio, non sono bannati e funzionano (lo stesso gstatic.com). Da ciò segue la conclusione: non dovresti eliminare incautamente tutte le risorse di Google e altre risorse che sembrano bloccate.
- Qualsiasi traffico che passa il confine aggiunge davvero gravi ritardi al suo tempo. Guarda i due risultati. Un sito, una pagina, semplice GET arricciare'om. La prima misurazione proveniva dalla stessa Cina (la bellissima città di Shenzhen). Il secondo è stato misurato dall’esterno di Hong Kong (ha la sovranità e non esiste alcun muro di protezione tra esso e il mondo). La distanza tra le città in linea retta è di circa 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/sNotare la time_connect. E in generale, vedi il risultato: il firewall aggiunge 4 secondi extra, il che è mostruosamente lungo.
- I tunnel VPN e IPSEC falliscono spesso. Ne parlerò un po 'più tardi e in modo più dettagliato. I server VPN utilizzati dagli utenti vengono bloccati nel tempo (di solito entro un giorno dall'inizio dell'utilizzo).
- C'è un'opinione ricevuta dalle persone che vivono in Cina secondo cui più semplice è la crittografia del traffico, più velocemente attraversa il confine, perché è facile capire che non c'è nulla di illegale in questo. E allo stesso modo, il traffico “pulito” riceve più larghezza di banda e velocità di passaggio, mentre il traffico “sporco”, in cui non si capisce nulla, riceve, al contrario, un passaggio più lento. Ad esempio userò curl to ifconfig.com tramite HTTPS e protocollo 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/sUna differenza di 5 secondi per un tempo di download totale di 13 byte. Inoltre, eseguendo più volte tale test, puoi notare che GET su HTTP viene completato generalmente allo stesso tempo ogni volta, mentre su HTTPS il sito a volte risponde in 3, 5, 10 e persino 17 secondi. A volte si verificano errori SSL:
Unknown SSL protocol error in connection to ifconfig.co:443.
Allora, cosa abbiamo:
- I problemi creati dal firewall cinese sono descritti sopra.
- I ping alle risorse esterne e ai tunnel interni periodicamente scompaiono.
- La latenza tra due punti cambia costantemente e spesso è semplicemente imprevedibile. Quando si collegano diverse città/regioni, ci si aspetta che, in base alla posizione geografica delle regioni, il ritardo sarà inferiore, ma si ottiene esattamente la situazione opposta.
- Internet e i canali di comunicazione sono veloci o lenti. C'è una leggera dipendenza dall'ora del giorno e dal giorno della settimana, ma non sempre.
- Le richieste DNS verso il mondo esterno provenienti dalla Cina a volte superano il timeout consentito.
Il quadro che ne emerge è semplicemente “eccellente”.
Il data center, come ho già detto, si trova nella parte orientale degli Stati Uniti e l'intero SEMrush è costituito da dozzine di prodotti interconnessi, backend, frontend, database e tutto questo nel DC e nel cloud. A noi, come team di amministratori di sistema, è stato affidato il compito di iniziare rapidamente a lavorare in Cina con poco sforzo.
Dovevamo rispondere ad una domanda importante: è possibile risolvere con poca spesa tutti i problemi legati all'internet cinese e ai firewall a livello di rete/cloud/server?
Abbiamo iniziato ricevendo .
Licenza ICP
Per poter ospitare il tuo servizio in Cina (Cina continentale) ed effettuare test, devi prima ottenere una licenza ICP per il dominio.
Se il traffico utente del tuo sito termina all'interno della Cina continentale e se il tuo dominio non dispone di una licenza ICP, il traffico verrà bloccato dal lato ISP/hosting. È interessante notare che la licenza ICP include un fornitore specifico, che si tratti di Cloudflare o Alibaba Cloud. Pertanto, se hai ricevuto una licenza ICP per Cloudflare e hai ospitato il tuo sito web con essa, non sarai in grado di passare “senza problemi” ad Alibaba Cloud. Dovrai aggiungere un altro hosting a questa licenza.
Avendo ottenuto la licenza ICP per il dominio abbiamo potuto ideare e realizzare idee e soluzioni tecniche concrete.
Soluzioni di test
Ma prima di creare direttamente opzioni di staging, girare le manopole, ottimizzare le prestazioni del sito e la sua velocità, è necessario scegliere uno strumento per testarlo per vedere quali delle nostre azioni migliorano o, al contrario, peggiorano le prestazioni del sito.
Il nostro strumento di test doveva soddisfare due requisiti principali:
- dovrebbe essere in grado di eseguire test dalla Cina,
- deve avere test del browser.
Quindi abbiamo trovato ! Hanno un'eccellente copertura dei luoghi di test in tutto il mondo. In Cina, attraverso questo strumento è possibile eseguire test anche in 100500 province. Ognuno ha diversi fornitori diversi + la capacità di farlo Spina dorsale-test (qualcosa come una macchina virtuale in un data center) e Ultimo miglio-test (il più vicino possibile alle condizioni dell'utente, ovvero workstation). Quest'ultimo tipo di test è più costoso.
Avendo concluso un contratto annuale (meno di questo non è possibile), abbiamo iniziato a studiare lo strumento. Francamente, siamo rimasti piacevolmente sorpresi dalla sua funzionalità. Puoi eseguire:
- test DNS,
- Test web (test del browser, semplice GET/POST, emulazione client mobile, ecc.),
- Controlli transazionali (ad esempio, accesso),
- Test API,
- Ping, traceroute, NTP, ecc.
Non puoi elencare tutto. E, cosa più importante, ogni test può essere personalizzato abbastanza bene aggiungendo una serie di intestazioni e altri parametri. L'output è un'enorme quantità di informazioni che descrivono completamente il test. Se parliamo delle cose per noi più interessanti (test del browser), il risultato include:
- Connetti, attendi, carica, SSL, ora DNS,
- TTFB, TTLB, documento completato, tempo di rendering, caricamento DOM,
- Risposta (qualcosa di vicino a Time To First Byte), Risposta della pagina Web (qualcosa di vicino a Time To Last Byte),
- Qualsiasi percentile, media, tempo mediano
- Eccetera
Di conseguenza, tutti questi parametri sono ottimi per vedere i cambiamenti e capire se le cose sono migliorate. Abbiamo principalmente guardato Risposta, Risposta della pagina Web, Mediana, 75 e 95 percentili.
Una domanda importante che era nell’aria fin dall’inizio: Puoi fidarti di Catchpoint?? Questo strumento riflette la reale velocità di caricamento del sito in Cina da diverse città o è solo una sorta di test nel vuoto che non ha nulla a che fare con la reale esperienza dell'utente?
Questo è un grosso problema, perché essendo in Russia è quasi impossibile scoprire in modo affidabile come funziona un sito cinese. Eseguendo un proxy calzini tramite una macchina virtuale, il risultato finale è che il sito si carica entro un paio di minuti, il che è semplicemente inaccettabile per i test, quindi l'unica opzione per i test manuali è l'arricciatura e il semplice GET dalla console con un timer . Questo aiuta perché questo test riflette bene la velocità della soluzione di rete e se ci sono anche test del browser, allora è molto buono.
Più tardi siamo andati noi stessi in Cina e ne eravamo convinti Puoi fidarti di Catchpoint; riflette in modo abbastanza accurato gli indicatori di prestazione reali.
Rete cinese Cloudflare
Poiché utilizziamo con successo Cloudflare per il dominio principale semrush.com, abbiamo deciso di provare immediatamente la loro funzionalità chiamata . Questa opzione è abilitata solo per i siti aziendali su richiesta separata e a un costo aggiuntivo. È inoltre disponibile solo per i siti che dispongono di una licenza ICP appropriata che elenca Cloudflare come fornitore. Dopo averlo abilitato, il "CDN cinese" di Cloudflare diventa disponibile per il sito: il traffico dalle regioni cinesi arriva al CF PoP (Point of Presence) più vicino e poi attraverso le sue reti o le reti di fornitori/partner viene consegnato all'origine .
Lo schema di questo banco prova è presentato di seguito.
Questa è un'ottima opzione per noi. Si scopre che il secondo dominio sarà anche per CF, il che non aumenta il numero di soluzioni utilizzate in azienda e praticamente non complica l'infrastruttura.
Abbiamo eseguito i test del browser e questo è quello che è successo:
I diamanti rossi indicano i fallimenti dei test. I file seguenti sono errori DNS (risolvere timeout). I fallimenti in alto sono timeout.
Tempo di attività: 86.6
Media: 18 secondi
75 percentile: 29.3 s
95 percentile: 60 s
Mediana, dopo la rimozione del carico reCaptcha (Servizio Google bloccato in Cina) diminuito da 28 a 18 secondi. Ma si tratta pur sempre di risultati terribili, considerando che lo stesso test per semrush.com (dagli Stati Uniti) ha dato meno di 10 secondi per il 95% degli utenti (dagli Stati Uniti) sulla stessa pagina (statica + dinamica).
Puoi andare in ogni test e guardare Cascata e altri parametri più dettagliati. Abbiamo iniziato a indagare sulle ragioni degli errori, e se per i timeout tutto è più o meno chiaro: Internet in Cina “si muove dentro e fuori”, per questo la velocità di connessione e di caricamento delle risorse dall'estero è instabile e irregolare, poi gli errori DNS ci hanno sorpreso molto. L'abbiamo trovato Pop Cloudflare in realtà si trova in Cina, l'indirizzo del sito si risolve in un IP anycast, ma i server DNS sono americani, motivo per cui le richieste DNS sono costrette ad oltrepassare il confine, quindi a volte falliscono.
Dopo aver chiarito questa domanda con CF, si è scoperto che Non hanno i propri server DNS in Cina, e quando accadrà non è ancora noto.
Pertanto, abbiamo deciso di testare solo i DNS di Cloudflare e abbiamo modificato il meccanismo operativo di Cloudflare per il nostro sito in "Solo DNS" Questa è una modalità in cui Cloudflare non esegue il proxy del traffico attraverso se stesso, il che significa che non fornisce protezione DDoS, CDN e altre funzionalità e funziona come un normale server DNS.
Questo supporto è mostrato schematicamente nella figura seguente. La cifra tiene conto della conoscenza emergente secondo cui i server DNS di Cloudflare sono dietro un firewall.
Su Catchpoint abbiamo eseguito semplici test GET (non test del browser), che hanno mostrato molti errori. Sono stati causati dagli stessi errori DNS.
Abbiamo iniziato il debug di questi errori utilizzando dig e abbiamo riscontrato che alla prima richiesta l'indirizzo viene determinato correttamente e che, su richiesta ripetuta, riceviamo ogni volta Errore di servizio и non trovato. Perché tutto questo accade all'improvviso?
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)Non si verificano errori di questo tipo quando si eseguono query direttamente sui server NS Cloudflare:
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.192Ciò significa che il problema è dal lato del server DNS “locale” o del server del provider.
Ulteriori indagini lo hanno rivelato Errore di servizio arriviamo alla risoluzione AAAA-record.
Si è scoperto che quando si richiede a Cloudflare AAAA-record che non esiste nel dominio, ha risposto Cloudflare А-una voce che rappresenta un errore e una non conformità con la RFC. Perché il risolutore locale (xxxx) Non mi è piaciuto, e lui ha risposto Errore di servizio. Questo comportamento è chiaramente visibile nel registro seguente:
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
Abbiamo inviato una segnalazione di bug a Cloudflare e dopo un po' di tempo l'hanno risolto. La cosa si è rivelata interessante: al momento non esiste ancora il supporto IPv6 in Cina, quindi Cloudflare non ha potuto rilasciare lì il suo indirizzo IPv6 in risposta a una richiesta AAAA-record. Alla fine, tutto si è risolto in modo tale che Cloudflare ha iniziato a rispondere per la Cina NESSUN DATO a tali richieste.
Pertanto, gli errori DNS nei test Catchpoint sono diminuiti notevolmente, ma non completamente. I timeout sono ancora qui:
E abbiamo iniziato a cercare un'altra soluzione.
Nella prossima parte ti racconterò come abbiamo testato il cloud cinese Alibaba Cloud, come, con l'aiuto di un po' di “magia” di Nginx, siamo riusciti a creare rapidamente soluzioni PoC (Proof of Concept), come abbiamo creato soluzioni Multi-Cloud, una delle quali alla fine ha contribuito notevolmente ad accelerare il lavoro del servizio dalla Cina.
Rimanete sintonizzati!
Parti successive
Fonte: habr.com
