大家好！
Nikita 正在聯絡 - 公司的系統工程師 SEMrush。今天我跟大家講講我們是如何面對保障semrush.com服務在中國穩定的任務的，以及我們在實施過程中遇到了哪些問題（考慮到我們的資料中心位於美國東海岸）。
這將是一個大故事，分成幾篇文章。我將告訴你這一切是如何發生在我們身上的：從來自中國的完全不起作用的服務，到為美國人提供的服務性能指標達到美國版本的水平。我保證這會很有趣而且很有用。那麼，我們走吧。
中國互聯網的問題
即使是距離網路管理細節最遠的人也聽說過 中國防火牆。哇，聽起來很酷，對吧？但它是什麼以及它實際上如何運作是一個相當複雜的問題。您可以在互聯網上找到許多專門討論此問題的文章，但從技術角度來看，沒有任何地方描述此防火牆的結構。然而，這並不奇怪。我馬上承認，根據一年的工作結果，我無法確切地說出它是如何運作的，但我可以告訴你我的評論和實際結論。我們將從有關此防火牆的謠言開始。
關於這個防火牆有很多謠言。讓我們將其中主要和最有趣的內容收集到一個清單中：
- Google、Facebook、Twitter 和其他類似服務在中國被封鎖且無法使用。
- 任何進入中國境外和進入中國的流量都會使用機器學習進行解析和限制（在可疑流量的情況下），這大大減慢了通過邊境的流量（流量）。
- 中國情報機構將破解任何通過其防火牆的加密流量。
- VPN隧道、IPSEC隧道不穩定、崩潰、經常被阻塞。
- 加密越簡單，用於驗證/加密流量的密碼短語越簡單，通過中國防火牆的速度就越快。
以下是我們對這些謠言的發現：
- Google、Facebook、Twitter 和其他類似的服務確實被屏蔽了（你的 KO），但許多技術性的谷歌域名，例如，沒有被禁止並且可以工作（同樣的 gstatic.com）。結論由此而來：你不應該魯莽地刪除所有似乎被封鎖的Google和其他資源。
- 任何經過邊境的交通都會嚴重延誤時間。看看這兩個結果。一個站點，一頁，簡單的GET 捲曲嗯。第一個測量是在中國本土（美麗的深圳）進行的。第二個是從香港外部衡量的（香港擁有主權，與世界之間沒有防火牆）。城市之間的直線距離約為30-40公里。
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/s注意 時間連接。一般來說，您會看到結果：防火牆多增加了 4 秒，這是非常長的。
- VPN 和 IPSEC 隧道確實經常失敗。我稍後會更詳細地討論這個問題。使用者使用的 VPN 伺服器會隨著時間的推移（通常在開始使用後的一天內）被封鎖。
- 居住在中國的人們認為，流量加密越簡單，通過邊境的速度就越快，因為很容易理解，這並不違法。同樣，「乾淨」的流量會獲得更多的頻寬和通行速度，而「髒」的流量則無法理解任何內容，相反，會獲得較慢的通行速度。例如我會使用curl來 ifconfig.co 透過 HTTPS 和 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總下載時間為 5 個字節，相差 13 秒。而且，當您多次進行這樣的測試時，您可以注意到，HTTP 上的GET 每次基本上都是在相同的時間內完成的，而在HTTPS 上，站點有時會在3、5、10 甚至17秒內響應。有時會發生 SSL 錯誤：
Unknown SSL protocol error in connection to ifconfig.co:443.
那我們有什麼：
- 上面描述了中國防火牆造成的問題。
- 對外部資源和隧道內部的 ping 操作會定期消失。
- 兩點之間的延遲不斷變化，而且通常是不可預測的。當連接不同的城市/地區時，您期望根據地區的地理位置，延遲會更少，但您得到的情況恰恰相反。
- 網路和通訊管道或快或慢。對一天中的時間和一周中的某一天有輕微的依賴性，但並非總是如此。
- 從中國向外界發出的 DNS 請求有時會超出允許的逾時時間。
出現的畫面簡直就是「太棒了」。
正如我已經說過的，資料中心位於美國東部，整個 SEMrush 由數十個互連的產品、後端、前端、資料庫組成，所有這些都在 DC 和雲端。我們作為一個系統管理員團隊，被賦予了不費吹灰之力快速開始在中國工作的任務。
我們必須回答一個重要的問題：是否有可能以很少的花費，在網路/雲端/伺服器層面解決與中國互聯網和防火牆相關的所有問題？
我們從接收開始 .
ICP許可證
為了能夠在中國（中國大陸）託管您的服務並進行測試，您必須先獲得該網域的ICP許可證。
如果您網站的用戶流量在中國大陸境內被終止，且您的網域沒有ICP許可證，那麼您的流量將在ISP/託管端被封鎖。有趣的是，ICP許可證包括特定的供應商，無論是Cloudflare還是阿里雲。因此，如果您獲得了Cloudflare的ICP許可證並用其託管您的網站，您將無法「無縫」遷移到阿里雲。您將需要向此許可證添加另一個託管。
在獲得該領域的 ICP 許可證後，我們能夠提出並實施具體的技術想法和解決方案。
測試解決方案
但在您直接建立暫存選項、轉動旋鈕、優化網站的效能及其速度之前，您需要選擇一個工具來測試它，以便了解我們的哪些操作可以提高網站的效能，或者相反，會降低網站的效能。
我們的測試工具必須滿足兩個主要要求：
- 它應該能夠從中國進行測試，
- 它必須有瀏覽器測試。
所以我們發現 ！他們對世界各地的測試地點都有很好的覆蓋。在中國，還可以透過該工具在100500個省份進行測試。每個都有幾個不同的提供者+做的能力 骨幹-測試（類似資料中心中的虛擬機器）和 最後一英里-測試（盡可能接近使用者條件，又稱為工作站）。後一種類型的測試更昂貴。
簽訂年度合約後（不可能少於此合約），我們開始研究該儀器。坦白說，我們對其功能感到驚訝。你可以運行：
- DNS 測試，
- Web 測試（瀏覽器測試、簡單的 GET/POST、行動用戶端模擬等），
- 事務檢查（例如登入），
- API測試，
- Ping、traceroute、NTP 等
你無法列出所有內容。最重要的是，每個測試都可以透過添加一堆標頭和其他參數來很好地自訂。輸出是大量訊息，完整描述了您的測試。如果我們談論對我們來說最有趣的事情（瀏覽器測試），結果包括：
- 連線、等待、載入、SSL、DNS 時間、
- TTFB、TTLB、文件完成、渲染時間、DOM 載入、
- 回應（接近第一個位元組的時間）、網頁回應（接近最後一個位元組的時間）、
- 任意百分位數、平均時間、中位數時間
- 等等。
因此，所有這些指標都非常適合查看變化並了解情況是否有所改善。我們主要看了 回應、網頁回應、中位數、75 和 95 個百分位數.
從一開始就存在著一個重要的問題： 你能相信 Catchpoint 嗎？？這個工具是否反映了中國不同城市的真實網站載入速度，或者只是某種與真實用戶體驗無關的真空測試？
這是一個大問題，因為在俄羅斯幾乎不可能可靠地了解中國網站的運作方式。透過虛擬機進行襪子代理，最終結果是網站在幾分鐘內加載，這對於測試來說根本不可接受，因此手動測試的唯一選擇是curl和帶有計時器的從控制台的簡單GET 。這很有幫助，因為這個測試很好地反映了網路解決方案的速度，如果還有瀏覽器測試，那就非常好。
後來我們自己去了中國並確信 您可以相信 Catchpoint；它非常準確地反映了真實的績效指標。
Cloudflare中國網
由於我們成功地將 Cloudflare 用於主網域 semrush.com，我們決定立即嘗試他們的功能，稱為 。此選項僅在企業網站單獨請求並支付額外費用時啟用。它也僅適用於擁有相應 ICP 許可證且將 Cloudflare 列為提供者的網站。啟用後，Cloudflare 的「中國 CDN」即可用於該網站 - 來自中國地區的流量到達最近的 PoP（存在點）CF，然後透過其網路或供應商/合作夥伴的網路傳送到來源站。
此測試台的示意圖如下所示。
這對我們來說是一個很好的選擇。事實證明，第二個域也將用於 CF，這不會增加公司使用的解決方案的數量，而且實際上不會使基礎設施變得複雜。
我們運行了瀏覽器測試，結果是這樣的：
紅色鑽石是測試失敗。以下檔案是 DNS 錯誤（解決逾時）。頂部的失敗是超時。
正常運轉時間：86.6
中位數：18秒
75 百分位數：29.3 秒
95 百分位數：60 秒
移除負載後的中位數 驗證碼 （Google服務在中國被屏蔽）從28秒減少到18秒。但考慮到對 semrush.com（來自美國）的相同測試，10% 的用戶（來自美國）在同一頁上（靜態 + 動態）的時間不到 95 秒，這些結果仍然很糟糕。
您可以進入每個測試並查看 瀑布 以及其他更詳細的參數。我們開始調查錯誤的原因，如果超時的話，一切都或多或少清楚了：中國的互聯網“進進出出”，因此從國外連接和加載資源的速度不穩定且不均勻，然後DNS錯誤讓我們大吃一驚。我們發現 的PoP Cloudflare實際上位於中國，網站位址解析為任播IP，但DNS伺服器是美國的，這就是為什麼DNS請求被迫跨境，所以有時會失敗。
跟CF澄清了這個問題，結果是 他們在中國沒有自己的DNS伺服器，而何時到來仍是未知數。
因此，我們決定僅測試 Cloudflare DNS，並將我們網站的 Cloudflare 運行機制變更為「僅 DNS」這是Cloudflare不通過自身代理流量的模式，這意味著它不提供DDoS防護、CDN等功能，並以常規DNS伺服器的模式運作。
下圖示意性地顯示了該支架。該圖考慮了 Cloudflare 的 DNS 伺服器位於防火牆後面的新知識。
在 Catchpoint，我們執行了簡單的 GET 測試（不是瀏覽器測試），結果顯示了許多失敗。它們是由相同的 DNS 錯誤引起的。
我們開始使用以下方法來偵錯這些錯誤 挖 並發現在第一次請求時地址被正確確定，並且在重複請求後我們每次都會收到 服務失敗 и 未找到。為什麼突然會發生這種事？
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)直接查詢Cloudflare NS伺服器沒有這樣的錯誤：
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.192這意味著問題出在「本地」DNS 伺服器或提供者的伺服器一側。
進一步調查發現 服務失敗 我們下定決心 AAAA-記錄。
事實證明，當向Cloudflare請求時 AAAA- 在網域中不存在的記錄，Cloudflare 回應 А- 錯誤且不符合 RFC 的條目。為什麼本地解析器（xxxx）我不喜歡，他回答說 服務失敗。此行為在下面的日誌中清晰可見：
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
我們向 Cloudflare 提交了錯誤報告，他們在一段時間後修復了這個問題。有趣的是：目前中國仍然不支援 IPv6，因此 Cloudflare 無法根據請求在中國發布其 IPv6 位址 AAAA-記錄。最後一切都以這樣的方式解決，Cloudflare開始為中國負責 沒有數據 對於這樣的要求。
因此，Catchpoint 測試中的 DNS 錯誤急劇減少，但並未完全減少。超時仍然在這裡：
我們開始尋找另一種解決方案。
下一部分我會告訴你我們是如何測試中國雲的 阿里巴巴雲，如何借助 Nginx 的一點“魔力”，我們能夠快速創建 PoC（概念驗證）解決方案，我們如何創建多雲解決方案，其中之一最終極大地幫助加快了服務的工作速度來自中國。
敬請關注！
下一部分
來源： www.habr.com
