DDoS-Guard 網路上的合法流量最近超過每秒一百吉比特。 目前，我們 50% 的流量是由客戶端 Web 服務產生的。 這些領域有數以萬計，各不相同，並且在大多數情況下需要單獨的方法。
以下是我們如何管理前端節點並為數十萬個網站頒發 SSL 憑證。
為一個站點（即使是非常大的站點）設置前台很容易。 我們採用 nginx、haproxy 或 lighttpd，依照指南進行配置，然後就不用管它了。 如果我們需要更改某些內容，我們會重新載入並再次忘記。
當您動態處理大量流量、評估請求的合法性、壓縮和快取使用者內容並同時每秒多次更改參數時，一切都會改變。 使用者希望在更改個人帳戶中的設定後立即在所有外部節點上看到結果。 使用者還可以透過 API 下載數千個（有時是數萬個）具有單獨流量處理參數的網域。 所有這一切也應該立即在美國、歐洲和亞洲發揮作用——考慮到僅在莫斯科就有幾個物理上分離的過濾節點，這項任務並不是最微不足道的。
為什麼全球有很多大型可靠節點？
-
客戶端流量的服務品質 - 來自美國的請求需要在美國處理（包括攻擊、解析和其他異常情況），而不是拉到莫斯科或歐洲，從而意外地增加處理延遲。
-
攻擊流量必須本地化——交通運營商在攻擊期間可能會降級，其流量通常超過 1Tbps。 透過跨大西洋或跨亞洲鏈路傳輸攻擊流量並不是一個好主意。 我們有真實的案例，一級運營商說：“你們收到的攻擊量對我們來說是危險的。” 這就是為什麼我們接受盡可能接近其來源的傳入流。
-
對服務連續性的嚴格要求 - 在我們瞬息萬變的世界中，清潔中心不應相互依賴或依賴當地事件。 您是否已將 MMTS-11 全部 9 層的電源切斷一週？ - 沒問題。 在此特定位置沒有實體連線的任何用戶端都不會受到影響，且 Web 服務在任何情況下都不會受到影響。
如何管理這一切？
服務配置應盡快（最好是立即）分發到所有前端節點。 你不能只獲取並重建文字配置並在每次更改時重新啟動守護進程 - 相同的 nginx 會使進程關閉（工作進程關閉）幾分鐘（如果有很長的 websocket 會話，則可能需要幾個小時）。
重新載入nginx配置時，出現下圖是很正常的：
關於記憶體利用率：
老工人會吃掉內存，包括不線性依賴連接數的內存——這是正常的。 當客戶端連線關閉時，該記憶體將被釋放。
為什麼nginx剛起步的時候這不是問題？ 沒有 HTTP/2，沒有 WebSocket，沒有大量的長保持活動連線。 我們 70% 的網路流量是 HTTP/2，這意味著非常長的連線。
解決方案很簡單 - 不要使用 nginx，不要基於文字檔案管理前端，當然也不要透過跨太平洋通道發送壓縮文字配置。 當然，這些管道是有保證和保留的，但這並沒有降低它們的跨大陸性。
我們有自己的前端伺服器平衡器，我將在下面的文章中討論其內部結構。 它能做的主要事情是每秒動態應用數千次配置更改，而無需重新啟動、重新加載、內存消耗突然增加等等。 這與熱代碼重載非常相似，例如在 Erlang 中。 資料儲存在地理分散式鍵值資料庫中，並由前端執行器立即讀取。 那些。 您透過莫斯科的 Web 介面或 API 上傳 SSL 證書，幾秒鐘後即可準備好前往我們位於洛杉磯的清潔中心。 如果突然發生世界大戰，互聯網在全世界消失，我們的節點將繼續自主工作，並在專用通道之一洛杉磯-阿姆斯特丹-莫斯科、莫斯科-阿姆斯特丹-香港-第一時間修復裂腦- Los-Los 變為可用。洛杉磯或至少其中一個GRE 備份覆蓋。
同樣的機制使我們能夠立即頒發和續訂 Let's Encrypt 憑證。 非常簡單，它的工作原理如下：
-
一旦我們看到至少一個針對客戶端網域的 HTTPS 請求沒有憑證（或憑證過期），接受該要求的外部節點就會將此情況報告給內部憑證授權單位。
-
如果使用者沒有禁止Let's Encrypt的發行，認證機構會產生一個CSR，從LE接收一個確認令牌，並透過加密通道將其傳送到所有前端。 現在任何節點都可以確認來自 LE 的驗證請求。
-
稍後，我們將收到正確的憑證和私鑰，並以相同的方式將其發送到前端。 再次，無須重新啟動守護程序
-
過期前7天，啟動重新領取證書的程序
目前我們正在實時輪換 350k 證書，對用戶完全透明。
在該系列的以下文章中，我將討論實時處理大型 Web 流量的其他功能 - 例如，使用不完整的數據分析 RTT 以提高中轉客戶的服務質量，以及一般情況下保護中轉流量免受影響太比特攻擊，關於流量資訊的交付和聚合，關於WAF，幾乎無限的CDN以及許多用於優化內容交付的機制。
只有註冊用戶才能參與調查。 ， 請。
您想先了解什麼？
-
企業排放佔全球 14,3%用於聚類和分析網路流量品質的演算法<3
-
企業排放佔全球 33,3%DDoS-Guard7 平衡器的內部結構
-
企業排放佔全球 9,5%保護傳輸 L3/L4 流量2
-
企業排放佔全球 0,0%保護網站的中轉流量0
-
企業排放佔全球 14,3%Web 應用程式防火牆3
-
企業排放佔全球 28,6%防止解析和點擊6
21 位用戶投票。 6 名用戶棄權。
來源： www.habr.com