Ciao a tutti!
In collegamento Nikita - ingegnere di sistema dell'azienda SEMrush. Oggi vi racconterò come ci siamo trovati di fronte alla sfida di garantire la stabilità del nostro servizio semrush.com in Cina e quali problemi abbiamo incontrato durante l'esecuzione (considerando la posizione del nostro data center sulla costa orientale degli Stati Uniti).
Saranno molte le storie, suddivise in diversi articoli. Racconterò come è andata: da un servizio completamente non funzionante in Cina a prestazioni del servizio pari a quelle della versione americana per gli americani. Prometto che sarà interessante e utile. Dunque, iniziamo.
Problemi di internet in Cina
Anche la persona più lontana dalla specializzazione nell'amministrazione di rete ha almeno sentito parlare del Grande Firewall Cinese. Uuu, suona bene, vero? Ma che cos'è, come funziona davvero — la questione è abbastanza complessa. Su internet si possono trovare molti articoli dedicati a questo, ma dal punto di vista tecnico la struttura di questo firewall non è descritta da nessuna parte. Il che, in fondo, non sorprende. Ammetto subito che, al termine dell'anno di lavoro, non sarò in grado di dire esattamente come funziona, ma posso raccontare le mie osservazioni e conclusioni pratiche. Iniziamo con le voci su questo firewall.
Ci sono molte voci su questo firewall. Diamo un'occhiata alle principali e più interessanti e raccogliamole 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 in Cina viene analizzato e limitato tramite machine learning (in caso di traffico sospetto), il che rallenta notevolmente il (traffico) che attraversa il confine.
- I servizi segreti cinesi violeranno qualsiasi traffico crittografato che passa attraverso il loro firewall.
- I tunnel VPN e i tunnel IPSEC sono instabili, cadono e vengono costantemente bloccati.
- Più semplice è la crittografia, più semplice è la passphrase usata per l'autenticazione/crittografia del traffico, più velocemente passa attraverso il firewall cinese.
Ecco cosa siamo riusciti a scoprire su queste voci:
- Google, Facebook, Twitter e altri servizi simili sono davvero bloccati (il vostro KO), ma molti domini tecnici di Google, ad esempio, non sono bloccati e funzionano (lo stesso gstatic.com). Da ciò si deduce che non si dovrebbe eliminare imprudentemente tutte le risorse google e simili che sembrano bloccate.
- Qualsiasi traffico che attraversa il confine aggiunge davvero un ritardo significativo al suo tempo. Guardate i due risultati. Un sito, una pagina, semplice GET curl’om. La prima misurazione è stata effettuata direttamente dalla Cina (la splendida città di Shenzhen). La seconda misurazione dall'esterno a Hong Kong (ha sovranità, e tra essa e il mondo non ci sono firewall). 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 % Transferido Velocità Media Tempo Tempo Tempo Attuale
Dload Upload Totale Trascorso Rimasto Velocità
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"
% Totale % Ricevuto % Transferido Velocità Media Tempo Tempo Tempo Attuale
Dload Upload Totale Trascorso Rimasto Velocità
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/sPrestare attenzione a time_connect. E in generale, vedete il risultato: il firewall aggiunge 4 secondi extra, il che è terribilmente lungo.
- Le VPN e i tunnel IPSEC cadono davvero spesso. Di questo parlerò più avanti e in modo più dettagliato. I server VPN utilizzati dagli utenti vengono bloccati nel tempo (solitamente entro un giorno dall'inizio dell'uso).
- C'è un'opinione, ottenuta da persone che vivono in Cina, secondo cui più semplice è la crittografia del traffico, più velocemente esso attraversa il confine, perché è facile capire che non c'è nulla di illegale. E allo stesso modo, il traffico "pulito" riceve più larghezza di banda e velocità di passaggio, mentre il traffico "sporca", in cui non si riesce a decifrare nulla, ha invece un passaggio più lento. Per esempio, cito curl fino a ifconfig.co tramite il protocollo HTTPS e HTTP.
curl -o /dev/null -w@curl_time "https://ifconfig.co/"
% Totale % Ricevuto % Xferd Velocità Media Tempo Tempo Tempo Corrente
Dload Upload Totale Speso Rimasto Velocità
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/"
% Totale % Ricevuto % Xferd Velocità Media Tempo Tempo Tempo Corrente
Dload Upload Totale Speso Rimasto Velocità
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/sLa differenza è di 5 secondi sul tempo totale di caricamento di 13 byte. Effettuando questo test più volte, si può notare che la richiesta GET su HTTP si completa in media in tempi simili ogni volta, mentre su HTTPS il sito a volte risponde in 3, 5, 10 e anche 17 secondi. A volte ci sono errori SSL:
Unknown SSL protocol error in connection to ifconfig.co:443.
Quindi, cosa abbiamo:
- Problemi causati 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 è del tutto imprevedibile. Collegando diverse città/regioni, ti aspetti che, in base alla posizione geografica delle regioni, la latenza sia inferiore, ma ottieni esattamente l'opposto.
- Internet e i canali di comunicazione funzionano a volte velocemente, a volte lentamente. C'è una piccola dipendenza dall'ora del giorno e dal giorno della settimana, ma non sempre.
- Le richieste DNS verso il mondo esterno dalla Cina a volte superano il timeout consentito.
Il quadro che emerge è semplicemente "ottimo".
Il data center, come ho già detto, si trova nel nostro est degli Stati Uniti, e tutto il SEMrush consiste in decine di prodotti interconnessi, backend, frontend, database, e tutto questo nel data center e nei cloud. Davanti a noi, come squadra di amministratori di sistema, ci è stato dato l'incarico di iniziare a lavorare in Cina con sforzi minimi e in tempi brevi.
Abbiamo dovuto rispondere a una domanda importante: si può gestire tutto il problema legato a Internet e al firewall cinese a livello di rete/cloud/server con il minimo sforzo?
Abbiamo iniziato con l'ottenere .
Licenza ICP
Per poter ospitare il proprio servizio in Cina (Mainland China) e effettuare test, è necessario prima ottenere una licenza ICP per il dominio.
Se il traffico degli utenti del tuo sito termina all'interno della Cina continentale e se il tuo dominio non ha una licenza ICP, il tuo traffico sarà bloccato dal fornitore/hosting. È interessante notare che nella licenza ICP viene specificato un fornitore specifico, sia esso Cloudflare o Alibaba Cloud. Pertanto, se hai ottenuto una licenza ICP per Cloudflare e hai ospitato il tuo sito con loro, successivamente non potrai trasferirti "senza soluzione di continuità" su Alibaba Cloud. Dovrai aggiungere un altro hosting a questa licenza.
Dopo aver ricevuto la licenza ICP per il dominio, siamo stati in grado di ideare e implementare specifiche idee e soluzioni tecniche.
Test delle soluzioni
Ma prima di iniziare a creare direttamente le varianti di staging, regolare le impostazioni, ottimizzare il funzionamento del sito e la sua velocità, è necessario scegliere uno strumento per il suo testing, in modo da vedere quali delle nostre azioni migliorano o, al contrario, peggiorano il funzionamento del sito.
Il nostro strumento di testing doveva soddisfare due requisiti principali:
- deve avere la possibilità di avviare test dalla Cina,
- deve disporre di test browser.
Così abbiamo trovato ! Hanno una copertura eccellente di punti di test in tutto il mondo. In Cina, tramite questo strumento, è possibile eseguire test anche da 100500 province. In ciascuna ci sono diversi fornitori + la possibilità di effettuare Backbone-test (una sorta di virtualizzazione in data center) e Lastmile-test (massimo avvicinamento alle condizioni utente, ovvero stazione di lavoro). L'ultimo tipo di test è più costoso.
Firmando un contratto annuale (non si può fare meno), abbiamo iniziato a esplorare lo strumento. A dire il vero, siamo rimasti piacevolmente colpiti dalle sue funzionalità. È possibile lanciare:
- test DNS,
- test web (browser, semplice GET/POST, emulazione client mobile, ecc.),
- verifiche transazionali (ad esempio, accesso),
- test API,
- Ping, traceroute, NTP, ecc.
Non è possibile elencare tutto. E cosa più importante, ogni test può essere abbastanza personalizzato, aggiungendo una serie di intestazioni e altri parametri. Il risultato è una quantità enorme di informazioni che descrivono completamente il tuo test. Se parliamo delle cose più interessanti per noi (test browser), il risultato comprende:
- Connect, Wait, Load, SSL, DNS time,
- TTFB, TTLB, Document complete, Render time, DOM load,
- Response (qualcosa di simile al Time To First Byte), Webpage Response (qualcosa di simile al Time To Last Byte),
- Qualsiasi percentile, Media, Tempo Mediano
- E così via.
Di conseguenza, tutte queste metriche aiutano a vedere i cambiamenti e a capire se le cose sono migliorate. Abbiamo principalmente esaminato Response, Webpage Response, Mediana, 75 e 95 Percentili.
Una domanda importante che aleggiava fin dall'inizio: ci si può fidare di Catchpoint?? Отражает ли этот инструмент реальную скорость загрузки сайта в Китае из разных городов или же это просто какой-то тест в вакууме, не имеющий ничего общего с real user experience?
È un grosso problema, perché essere in Russia rende praticamente impossibile conoscere in modo veritiero il funzionamento di un sito dalla Cina. Eseguendo un socks-proxy tramite una macchina virtuale, si ottiene un caricamento del sito in pochi minuti, il che è inaccettabile per i test, quindi l'unica opzione per i test manuali rimane curl e semplici GET dalla console con misurazione del tempo. Questo aiuta, perché questo test riflette bene la velocità della soluzione di rete e se ci sono anche test browser, va ancora meglio.
In seguito, siamo andati noi stessi in Cina e ci siamo assicurati che ci si può fidare di Catchpoint, riflette abbastanza accuratamente i parametri reali di velocità operativa.
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 Enterprise su richiesta separata e a pagamento. È disponibile anche solo per siti che dispongono di una licenza ICP corrispondente, in cui Cloudflare è indicato come fornitore. Dopo l'attivazione, il sito ha accesso al "CDN cinese" di Cloudflare: il traffico dalle regioni cinesi viene instradato nei punti di presenza (PoP) più vicini di CF, e poi viene consegnato all'origine tramite le loro reti o quelle dei provider/partner.
Lo schema di questo banco di prova è mostrato di seguito.
Per noi è una soluzione eccellente. Risulta quindi che il secondo dominio sarà anch'esso sotto CF, il che non aumenta il numero di soluzioni utilizzate nell'azienda e non complica praticamente l'infrastruttura.
Abbiamo avviato dei test browser e questo è il risultato:
I rombi rossi indicano i fallimenti nei test. 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
La mediana, dopo aver rimosso il caricamento reCaptcha (servizio di Google, bloccato in Cina), è scesa da 28 a 18 secondi. Ma sono comunque parametri terribili, considerando che lo stesso test per semrush.com (dalla USA) ha dato meno di 10 secondi per il 95% degli utenti (dalla USA) sulla stessa pagina (statica + dinamica).
Puoi accedere a ogni test e vedere Waterfall e altri parametri più dettagliati. Abbiamo iniziato a esplorare le cause degli errori e se per i timeout è tutto più o meno chiaro: internet in Cina "va e viene", perciò la velocità di connessione e il caricamento di risorse dall'estero è instabile e variabile, gli errori DNS ci hanno sorpreso molto. Abbiamo scoperto che PoP i server Cloudflare sono 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, quindi a volte falliscono.
Chiedendo delucidazioni a CF, abbiamo scoperto che non hanno propri server DNS in Cina, e quando ci saranno - al momento non è noto.
Pertanto, abbiamo deciso di testare solo il 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 instrada il traffico attraverso di sé, il che significa che non fornisce protezione da DDoS, CDN e altre funzionalità, e funziona come un normale server DNS.
Questo stand è schematicamente presentato nel disegno seguente. Nel disegno sono state considerate le conoscenze emerse sul fatto che i server DNS di Cloudflare sono dietro un firewall.
In Catchpoint abbiamo avviato semplici test GET (non browser), che hanno mostrato molti fallimenti. La causa era sempre la stessa: errori DNS.
Abbiamo iniziato a debuggare questi errori con l'aiuto di dig e abbiamo scoperto che alla prima richiesta l'indirizzo viene determinato correttamente, ma alla richiesta ripetuta otteniamo ogni volta SERVFAIL e non trovato. Da cosa dipende?
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)Alla richiesta dei server NS di Cloudflare direttamente non ci sono tali errori:
root@iZwz97n2wgbp61qucbfrjsZ:~# for 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 “locale” del server DNS o del server del provider.
Ulteriori indagini hanno mostrato che SERVFAIL riceviamo nella risoluzione recordAAAA.
Si è scoperto che alla richiesta a Cloudflare AAAA-record che non esiste nel dominio, Cloudflare ha risposto A-con un errore che rappresenta un errore e una discrepanza rispetto all'RFC. Questo ha creato problemi al risolutore locale (x.x.x.x) che non gradiva, e così ha risposto SERVFAIL. Nel log qui sotto si vede chiaramente questo comportamento:
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
;; opzioni globali: +cmd
;; Risposta ricevuta:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 55467
;; flags: qr rd ra; QUERY: 1, RISPOSTA: 0, AUTORITÀ: 0, AGGIUNTIVA: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; SEZIONE DOMANDA:
;semrushchina.cn. IN AAAA
;; Tempo della query: 334 msec
;; SERVER: x.x.x.x#53(x.x.x.x)
;; QUANDO: Mar Ago 14 23:38:50 CST 2018
;; DIMENSIONE MSG ricevuta: 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.
;; opzioni globali: +cmd
;; Risposta ricevuta:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63944
;; flags: qr aa rd; QUERY: 1, RISPOSTA: 1, AUTORITÀ: 0, AGGIUNTIVA: 1
;; AVVISO: ricorsione richiesta ma non disponibile
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; SEZIONE DOMANDA:
;semrushchina.cn. IN AAAA
;; SEZIONE RISPOSTA:
semrushchina.cn. 300 IN A 220.170.186.192
;; Tempo della query: 185 msec
;; SERVER: 173.245.58.105#53(173.245.58.105)
;; QUANDO: Mar Ago 14 23:43:03 CST 2018
;; DIMENSIONE MSG ricevuta: 60
Abbiamo inviato un bug report a Cloudflare, e hanno corretto il problema dopo qualche tempo. È emerso un fatto interessante: attualmente in Cina non c'è ancora supporto per l'IPv6, quindi Cloudflare non poteva restituire il proprio indirizzo IPv6 nella risposta alla richiesta AAAA-record. Alla fine, si è risolto che per la Cina Cloudflare ha iniziato a rispondere NODATA a tali richieste.
Così, gli errori DNS nei test di Catchpoint sono diminuiti drasticamente, ma non del tutto. Anche i timeout non sono scomparsi:
E abbiamo iniziato a cercare un'altra soluzione.
Nella prossima parte parlerò di come abbiamo testato il cloud cinese Alibaba Cloud, come grazie a una piccola "magia" di Nginx siamo riusciti a creare rapidamente soluzioni PoC (Proof of Concept), e come abbiamo sviluppato soluzioni Multi-Cloud, una delle quali ha poi molto aiutato ad accelerare il servizio dalla Cina.
Resta sintonizzato!
Le prossime parti
Fonte: habr.com
