Ciao a tutti!
In contatto, Nikita — ingegnere di sistema di SEMrush. Oggi vi racconterò come abbiamo affrontato il compito di garantire la stabilità del nostro servizio semrush.com in Cina e quali problemi abbiamo incontrato nel corso della sua realizzazione (considerando la posizione del nostro data center sulla costa orientale degli Stati Uniti).
Questa sarà una grande storia, suddivisa in più articoli. Vi racconterò come è andata: da un servizio completamente non funzionante dalla Cina, a prestazioni comparabili a quelle della sua versione americana per gli Stati Uniti. Prometto, sarà interessante e utile. Quindi, iniziamo.
Problemi di internet in Cina
Anche la persona più lontana dalla specificità dell'amministrazione di rete ha sentito parlare almeno una volta di Grande Firewall Cinese. Uhm, sembra interessante, vero? Ma cos'è esattamente e come funziona realmente — la questione è piuttosto complessa. Su internet si possono trovare molti articoli su questo argomento, ma dal punto di vista tecnico il funzionamento di questo firewall non viene descritto da nessuna parte. Non sorprende, in effetti. Devo ammettere che, dopo un anno di utilizzo, non posso dire esattamente come funziona, ma posso condividere le mie osservazioni e conclusioni pratiche. Cominceremo con i rumor su questo firewall.
Ci sono molti rumor su questo firewall. Raccogliamo i principali e più interessanti in un'unica lista:
- Google, Facebook, Twitter e altri servizi simili sono bloccati e non funzionano in Cina.
- Qualsiasi traffico che va Oltre i confini della Cina e Viene in Cina viene analizzato e limitato tramite machine learning (in caso di traffico sospetto), il che ne rallenta notevolmente il passaggio attraverso la frontiera.
- I servizi segreti cinesi possono hackerare qualsiasi traffico crittografato che passa attraverso il loro firewall.
- I tunnel VPN e i tunnel IPSEC sono instabili, cadono e vengono continuamente bloccati.
- Più è semplice la crittografia, più semplice è la pass phrase utilizzata per l'autenticazione/cifratura del traffico, più velocemente supera il firewall cinese.
Ecco cosa siamo riusciti a scoprire su queste voci:
- Google, Facebook, Twitter e altri servizi simili sono effettivamente bloccati (il tuo K.O.), ma molti domini tecnici di Google, ad esempio, non sono vietati e funzionano (come gstatic.com). Da ciò ne deriva che non è saggio eliminare indiscriminatamente tutte le risorse di Google e simili che sembrano bloccate.
- Qualsiasi traffico che attraversa il confine aggiunge davvero un notevole ritardo al suo tempo. Guarda i due risultati. Un sito, una pagina, semplice GET curlIl primo rilevamento proviene dalla Cina stessa (bellissima città di Shenzhen). Il secondo ricordo dall'esterno da Hong Kong (ha sovranità e non c'è firewall tra lui 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"
% Totale % Ricevuto % Trasferito Velocità Media Tempo Tempo Tempo Corrente
Scarica Carica Totale Trascorso Rimanente Velocità
100 381k 0 381k 0 0 71824 0 --:--:-- 0:00:05 --:--:-- 82832
tempo_namelookup: 0.004500
tempo_connect: 0.169342
tempo_appconnect: 0.723189
tempo_pretransfer: 0.723499
tempo_redirect: 0.000000
tempo_starttransfer: 1.532912
----------
tempo_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"
% Totale % Ricevuto % Trasferito Velocità Media Tempo Tempo Tempo Corrente
Scarica Carica Totale Trascorso Rimanente Velocità
100 319k 0 319k 0 0 2555k 0 --:--:-- --:--:-- --:--:-- 2573k
tempo_namelookup: 0.029366
tempo_connect: 0.030742
tempo_appconnect: 0.047310
tempo_pretransfer: 0.047388
tempo_redirect: 0.000000
tempo_starttransfer: 0.120793
----------
tempo_total: 0.124871
----------
size_download: 326755 Bytes
speed_download: 2616740.000B/sFai attenzione a tempo_connect. In generale, puoi vedere il risultato: il firewall aggiunge 4 secondi extra, il che è incredibilmente lungo.
- VPN e tunnel IPSEC spesso subiscono interruzioni. Ne parlerò più in dettaglio più avanti.
- C'è un'opinione, proveniente da persone che vivono in Cina, secondo cui più semplice è la crittografia del traffico, più velocemente esso passa il confine, perché è facile capire che non contiene nulla di illegale. Allo stesso modo, il traffico "pulito" riceve più banda e velocità di transito, mentre il traffico "sporco", in cui nulla è comprensibile, ha al contrario un passaggio più lento. Come esempio, presenterò curl fino a ifconfig.co tramite i protocolli HTTPS e HTTP.
curl -o /dev/null -w@curl_time "https://ifconfig.co/"
% Totale % Ricevuto % Trasferito Velocità Media Tempo Tempo Tempo Corrente
Scaricati Caricati Totale Speso Rimasto Velocità
100 13 100 13 0 0 2 0 0:00:06 0:00:05 0:00:01 3
tempo_namelookup: 0.004305
tempo_connect: 0.397465
tempo_appconnect: 5.149305
tempo_pretransfer: 5.149393
tempo_redirect: 0.000000
tempo_starttransfer: 5.568847
----------
tempo_totale: 5.568893
----------
size_download: 13 Bytes
speed_download: 2.000B/s
curl -o /dev/null -w@curl_time "http://ifconfig.co/"
% Totale % Ricevuto % Trasferito Velocità Media Tempo Tempo Tempo Corrente
Scaricati Caricati Totale Speso Rimasto Velocità
100 13 100 13 0 0 28 0 --:--:-- --:--:-- --:--:-- 28
tempo_namelookup: 0.004282
tempo_connect: 0.212457
tempo_appconnect: 0.000000
tempo_pretransfer: 0.212484
tempo_redirect: 0.000000
tempo_starttransfer: 0.450565
----------
tempo_totale: 0.450620
----------
size_download: 13 Bytes
speed_download: 28.000B/sLa differenza di 5 secondi sul tempo totale di caricamento di 13 byte. Facendo questo test più volte, si può notare che una richiesta GET su HTTP si completa generalmente in un tempo simile ogni volta, mentre su HTTPS il sito risponde talvolta in 3, 5, 10 e persino 17 secondi. A volte si verificano errori SSL:
Errore sconosciuto del protocollo SSL nella connessione a ifconfig.co:443.
Quindi, cosa abbiamo:
- Problemi creati dal firewall cinese, come descritto sopra.
- I ping verso risorse esterne e all'interno dei tunnel scompaiono periodicamente.
- La latenza tra due punti cambia costantemente, e spesso è semplicemente imprevedibile. Collegando diverse città/regioni, ti aspetti che, in base alla posizione geografica dei regioni, la latenza sia minore, ma ottieni esattamente il contrario.
- Internet e le linee di comunicazione funzionano a volte rapidamente, a volte lentamente. C'è una leggera dipendenza dall'ora del giorno e dal giorno della settimana, ma non sempre.
- Le richieste DNS verso l'esterno dalla Cina a volte superano il timeout consentito.
Il quadro si delinea semplicemente "ottimo".
Il nostro data center, come ho già detto, si trova nell'est degli Stati Uniti, e SEMrush è composto da decine di prodotti interconnessi, backend, frontend, database, e tutto questo è presente nei data center e nel cloud. Il nostro compito, come team di amministratori di sistema, era quello di avviare rapidamente le operazioni in Cina con sforzi minimi.
Ci siamo posti una domanda importante: è possibile affrontare le problematiche legate a Internet e al firewall cinese con un approccio a basso impatto, a livello di rete/cloud/server?
Abbiamo iniziato a ottenere .
licenza ICP
Per poter ospitare il proprio servizio in Cina continentale e condurre test, è necessario prima ottenere una licenza ICP per il dominio.
Se il traffico degli utenti del tuo sito viene terminato all'interno della Cina continentale e se il tuo dominio non possiede una licenza ICP, il tuo traffico verrà bloccato dal provider/hosting. È interessante notare che nella licenza ICP è registrato un provider specifico, sia esso Cloudflare o Alibaba Cloud. Pertanto, se hai ottenuto una licenza ICP per Cloudflare e hai ospitato il tuo sito presso di loro, successivamente non sarà possibile trasferirlo "senza soluzione di continuità" su Alibaba Cloud. Sarà necessario aggiungere un altro hosting a questa licenza.
Ottenendo una licenza ICP per il dominio, siamo stati in grado di pensare e realizzare idee e soluzioni tecniche specifiche.
Test delle soluzioni
Ma prima di creare direttamente le opzioni di staging, regolare le impostazioni e ottimizzare il funzionamento del sito e la sua velocità, è necessario scegliere uno strumento per il test, per vedere quali delle nostre azioni migliorano o al contrario peggiorano le performance del sito.
Il nostro strumento di test doveva soddisfare due requisiti principali:
- doveva essere in grado di eseguire test dalla Cina,
- doveva avere test basati su browser.
Così abbiamo trovato ! Hanno una copertura eccellente dei punti di test in tutto il mondo. In Cina, con questo strumento è possibile eseguire test anche da 100500 province. In ognuna ci sono diversi fornitori + possibilità di fare Backbone-test (qualcosa come una macchina virtuale in un data center) e Lastmile-test (il più vicino possibile alle condizioni degli utenti, aka workstation). L'ultimo tipo di test è più costoso.
Firmando un contratto annuale (non si può fare di meno), abbiamo iniziato a esplorare lo strumento. Devo ammettere che siamo stati piacevolmente sorpresi dalle sue funzionalità. È possibile eseguire:
- test DNS,
- test web (browser, semplice GET/POST, emulazione di un client mobile, ecc.),
- verifiche transazionali (ad esempio, il login),
- test API,
- Ping, traceroute, NTP, ecc.
Non si può elencare tutto. E la cosa più importante è che ogni test può essere personalizzato in modo piuttosto buono, aggiungendo un insieme di intestazioni e altri parametri. Alla fine si ottiene un'enorme quantità di informazioni che descrivono completamente il tuo test. Parlando dei più interessanti per noi (test browser), il risultato include:
- Connect, Wait, Load, SSL, tempo DNS,
- TTFB, TTLB, Document complete, Render time, DOM load,
- Risposta (qualcosa vicino a Time To First Byte), Risposta della pagina web (qualcosa vicino a Time To Last Byte),
- Qualsiasi percentile, Tempo medio, Mediana
- E simili.
Di conseguenza, tutte queste metriche aiutano a vedere i cambiamenti e a capire se le cose siano migliorate. Abbiamo principalmente esaminato Risposta, Risposta della pagina web, Mediana, 75° e 95° Percentili.
Una domanda importante che aleggiava fin dall'inizio: si può fidare di Catchpoint?? Отражает ли этот инструмент реальную скорость загрузки сайта в Китае из разных городов или же это просто какой-то тест в вакууме, не имеющий ничего общего с real user experience?
Questo è un grande problema, perché essere in Russia rende praticamente impossibile sapere con certezza come funziona un sito dalla Cina. Utilizzando un socks-proxy tramite una macchina virtuale, ci si ritrova a caricare il sito per un paio di minuti, il che è inaccettabile per i test; quindi, l'unica opzione di test manuale rimane curl e semplici GET dalla console misurando il tempo. Questo aiuta, perché il test riflette bene la velocità della soluzione di rete, e se ci sono anche test browser, è ancora meglio.
In seguito, siamo andati in Cina e abbiamo riscontrato che ci si può fidare di Catchpoint, che riflette abbastanza accuratamente i reali indicatori di velocità.
Cloudflare China Network
Poiché per il dominio principale semrush.com utilizziamo con successo Cloudflare, abbiamo deciso di provare subito la loro funzionalità chiamata . Questa opzione è attivabile solo per siti web Enterprise su richiesta separata e a pagamento. È inoltre disponibile solo per siti con una licenza ICP valida, in cui Cloudflare è indicato come fornitore. Una volta attivata, il sito avrà accesso al “CDN cinese” di Cloudflare — il traffico proveniente dalle regioni cinesi raggiunge i PoP (Points of Presence) più vicini di CF, e da lì viene inoltrato attraverso le proprie reti o quelle dei fornitori/partner fino all'origine.
Lo schema di questo banco di prova è mostrato di seguito.
Per noi è un'ottima soluzione. Si scopre che il secondo dominio sarà anch'esso sotto CF, il che non aumenta il numero di soluzioni utilizzate in azienda e praticamente non complica l'infrastruttura.
Abbiamo lanciato i test del browser, ecco i risultati:
I rombi rossi indicano i test falliti. I fallimenti in basso sono errori DNS (timeout di risoluzione). I fallimenti in alto sono timeout.
Uptime: 86,6
Mediana: 18s
75° Percentile: 29,3s
95° Percentile: 60s
Mediana, dopo aver rimosso il carico reCaptcha (servizio di Google, bloccato in Cina), è diminuito da 28 a 18 secondi. Tuttavia, questi sono punteggi terribili, considerando che lo stesso test su semrush.com (degli USA) ha dato meno di 10 secondi per il 95% degli utenti (degli USA) sulla stessa pagina (statica + dinamica).
Puoi accedere a ogni test e visualizzarlo. Waterfall e altri parametri più dettagliati. Abbiamo iniziato a indagare sulle cause degli errori e se per i timeout è tutto più o meno chiaro: internet in Cina “si interrompe e riprende”, a causa di ciò la velocità di connessione e il caricamento delle risorse dall'estero sono instabili e variabili, invece gli errori DNS ci hanno sorpreso molto. Abbiamo scoperto che PoP di Cloudflare si trovano effettivamente in Cina, l'indirizzo del sito viene risolto in un IP anycast, ma i server DNS utilizzati sono americani, il che costringe le richieste DNS a passare attraverso il confine, motivo per cui a volte falliscono.
Chiedendo chiarimenti a CF, abbiamo scoperto che non hanno server DNS propri in Cina, e non si sa ancora quando ci saranno.
Pertanto, abbiamo deciso di testare solo DNS di Cloudflare e abbiamo cambiato il meccanismo di funzionamento di Cloudflare per il nostro sito nella modalità “Solo DNS”. Questa è una modalità in cui Cloudflare non proxy il traffico, il che significa che non fornisce protezione DDoS, CDN e altre funzionalità, e funziona come un normale server DNS.
Questo stand è schematicamente rappresentato nel disegno seguente. Nel disegno sono considerate le nuove conoscenze che indicano che i server DNS di Cloudflare si trovano dietro un firewall.
In Catchpoint abbiamo avviato semplici test GET (non da browser), che hanno mostrato molti fallimenti. La causa erano gli stessi errori DNS.
Abbiamo iniziato a debuggare questi errori con dig e abbiamo scoperto che alla prima richiesta l'indirizzo viene determinato correttamente, mentre alla richiesta successiva riceviamo ogni volta SERVFAIL e not found. Perché mai?
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn ha indirizzo 220.170.186.192
Host semrushchina.cn non trovato: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn ha indirizzo 220.170.186.192
Host semrushchina.cn non trovato: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn ha indirizzo 220.170.186.192
Host semrushchina.cn non trovato: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn ha indirizzo 220.170.186.192
Host semrushchina.cn non trovato: 2(SERVFAIL)Non ci sono errori di questo tipo quando si richiedono direttamente i server NS di Cloudflare:
root@iZwz97n2wgbp61qucbfrjsZ:~# per i in `seq 1 2`; do host semrushchina.cn ray.ns.cloudflare.com.; done
Utilizzando il server di dominio:
Nome: ray.ns.cloudflare.com.
Indirizzo: 173.245.59.138#53
Alias:
semrushchina.cn ha indirizzo 220.170.186.192
semrushchina.cn ha indirizzo 220.170.186.192
Utilizzando il server di dominio:
Nome: ray.ns.cloudflare.com.
Indirizzo: 173.245.59.138#53
Alias:
semrushchina.cn ha indirizzo 220.170.186.192
semrushchina.cn ha indirizzo 220.170.186.192Quindi, il problema è lato server DNS “locale” o del provider.
Un'indagine più approfondita ha mostrato che SERVFAIL riceviamo dal risolutore AAAA-record.
È emerso che, quando si richiedeva a Cloudflare AAAA-record che non esiste nel dominio, Cloudflare rispondeva Econ un record che è un errore e non conforme all'RFC. Questo ha causato che il risolutore locale (x.x.x.x) non fosse contento, e rispondeva SERVFAIL. Questo comportamento è chiaramente visibile nei log sottostanti:
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 un bug report a Cloudflare, e lo hanno risolto dopo un po'. È stato interessante: attualmente in Cina non c'è ancora supporto per IPv6, quindi Cloudflare non poteva fornire il suo indirizzo IPv6 nella risposta alla richiesta. AAAA-record. Alla fine, tutto si è risolto in modo che per la Cina Cloudflare ha iniziato a rispondere NODATA a tali richieste.
Tuttavia, gli errori DNS nei test di Catchpoint sono diminuiti drasticamente, ma non del tutto. Anche i timeout persistono:
E abbiamo iniziato a cercare un'altra soluzione.
Nella prossima parte vi racconterò come abbiamo testato il cloud cinese Alibaba Cloud, come con un po' di "magia" di Nginx siamo riusciti a creare rapidamente PoC (Proof of Concept) di soluzioni, come abbiamo sviluppato soluzioni Multi-Cloud, una delle quali ha notevolmente contribuito a velocizzare il servizio dalla Cina.
Rimanete sintonizzati!
Prossime parti
Fonte: habr.com
