CC 攻擊和 DDoS 攻擊區別：作用層、流量特徵與防護手段

CC 攻擊和 DDoS 攻擊區別的核心在於打在哪一層：DDoS 是分散式拒絕服務攻擊的統稱，平時說的“DDoS”多指網路層和傳輸層的流量型攻擊，用 UDP 泛洪、反射放大、SYN 泛洪把頻寬或連線表灌滿；CC 攻擊是 DDoS 裡的應用層分支，用真實的 HTTP 請求把網站的 CPU、資料庫和程序池耗光。一個靠“大”，一個靠“多”，防護手段完全不同。

一張表看 CC 與 DDoS 的區別

對比項	流量型 DDoS（四層及以下）	CC 攻擊（七層）
OSI 層次	網路層、傳輸層	應用層
常見形式	UDP 泛洪、ICMP 泛洪、NTP/DNS/memcached 反射放大、SYN 泛洪、ACK 泛洪	HTTP/HTTPS 泛洪、慢速請求（Slowloris）、針對搜尋、登入、下單等介面的高頻請求
流量大小	大，Gbps 到 Tbps 級	小，常常只有幾 Mbps 到幾十 Mbps
是否需要完成 TCP 握手	不需要，一個包就是一次攻擊	需要，必須建立連線後發出完整請求
源 IP 能否偽造	可以，UDP 和 SYN 泛洪幾乎都偽造	不能，源 IP 真實，來自殭屍網路、代理池或撥號 IP
消耗的資源	上聯頻寬、路由器與防火牆的包處理能力、連線表	Web 程序、CPU、資料庫連線、後端 API
伺服器上的表現	入向頻寬打滿，ping 丟包，所有服務同時不通	頻寬正常，網站 502/504 或極慢，其他連接埠（如 SSH）仍然正常
流量清洗能不能解決	能，這正是清洗裝置的設計目標	基本不能，每個請求在網路層都是合法的
主要防護手段	機房清洗、黑洞路由、高防 IP、頻寬冗餘	WAF、按 IP 和介面限速、人機驗證、快取、業務側改造
誰來處理	機房、上游運營商、高防服務商	應用和維運團隊為主，七層高防或 CDN 為輔

CC 攻擊屬於 DDoS 嗎

屬於。DDoS 按作用層可以分成三類：

• 網路層攻擊：ICMP 泛洪、UDP 泛洪、各類反射放大，目標是把鏈路頻寬塞滿；
• 傳輸層攻擊：SYN 泛洪、ACK 泛洪、連線耗盡，目標是把伺服器或防火牆的連線表塞滿；
• 應用層攻擊：HTTP 泛洪、慢速攻擊、DNS 查詢泛洪，目標是把應用的處理能力耗光。

CC 就是應用層攻擊裡針對 Web 的那一種。之所以在國內被單獨拎出來講，是因為它的流量特徵和防護思路與前兩類差別太大，很多人買了“抗 DDoS”的服務卻發現擋不住它。

四層攻擊和七層攻擊的流量差多少

用一個假設的算例感受一下量級差異。

SYN 泛洪：一個 SYN 包線上路上大約 60 位元組，10 Gbps 的攻擊流量相當於每秒約 2000 萬個包。這個規模下，普通伺服器的網路卡和核心在包到達應用之前就已經處理不過來，機房清洗裝置要做的就是識別這種協議特徵並丟棄。

CC 攻擊：一個 HTTP 請求連頭部算上大約 500 位元組。假設攻擊者控制 2000 個代理 IP，每個 IP 每秒只發 1 個請求，合計 2000 QPS，流量只有 2000 × 500 × 8 ≈ 8 Mbps，在任何監控圖上都不起眼。但如果被請求的是一個要查資料庫的動態頁面，每次處理耗時 50 ms，一個 CPU 核每秒只能處理 20 個請求，8 核伺服器滿打滿算 160 QPS，2000 QPS 就是它處理能力的十幾倍，網站在幾秒內就會開始排隊、超時。

這就是“是否需要真實 TCP 連線”這一行的意義：CC 要完成握手、發出合法請求，代價是源 IP 不能偽造，規模上不去；換來的是每個請求都能落到後端最貴的那段邏輯上。

為什麼買了高防頻寬還是被 CC 打掛

這是最常見的疑問，原因有三個：

1. 清洗裝置靠流量特徵識別攻擊。它看的是協議是否異常、速率是否突變、源分佈是否集中。CC 請求是完整的 TCP 握手加合法的 HTTP 報文，與真實使用者的請求在網路層沒有區別，清洗裝置放行是正確的行為。
2. 高防頻寬只是“管道大”。300 Gbps 的防護頻寬說明鏈路灌不滿，但後端還是那台 8 核伺服器，處理能力沒有變。
3. 四層高防看不到 HTTP 內容。用連接埠轉發方式接入的高防 IP 只做 TCP 層轉發；HTTPS 站點如果沒有把證書放到高防上做七層接入，防護方連 URL 都看不見，更談不上按請求特徵過濾。

所以防 CC 的前提是讓防護裝置能讀到請求內容：要麼在高防或 CDN 上做七層接入並上傳證書，要麼在自己的閘道器或 Nginx 前部署 WAF。

防護手段對比：清洗 vs WAF 與人機驗證

手段	針對	原理	侷限
流量清洗、黑洞路由	流量型 DDoS	在機房或上游按協議特徵丟棄異常流量，超閾值時丟棄整個 IP 的流量	對合法 HTTP 請求無效
高防 IP（四層轉發）	流量型 DDoS	把流量引到清洗中心再回源	看不到 HTTP 內容，防不了 CC
高防 CDN、七層高防	CC 與流量型	在邊緣節點終結 TLS，按 URL、頻率、指紋過濾，靜態內容直接命中快取	需要上傳證書，動態請求仍要回源
WAF	CC	規則匹配、按 IP/URL 的頻率控制、UA 與 Referer 校驗、瀏覽器指紋	規則太嚴會誤傷正常使用者
人機驗證	CC	對可疑來源下發 JavaScript 挑戰或驗證碼，指令碼無法透過	影響使用者體驗，API 類介面不能用
伺服器限速	CC	Nginx 按 IP 限制請求速率與併發	對分佈極廣的代理池效果有限
業務側改造	CC	登入、搜尋、簡訊等介面加驗證碼或簽名，熱點頁面快取化	需要開發投入

實際部署一般是組合：外面掛七層高防或 CDN 吸掉大頭，Nginx 上對高消耗介面單獨限速，業務上把最容易被打的介面改成非同步或加驗證。

怎麼判斷自己遇到的是哪一種

先看頻寬，再看日誌。頻寬打滿是流量型，頻寬正常而網站不可用就往 CC 方向查。Nginx 存取日誌能直接給出答案：

# 最近 20 萬行請求裡，請求量前 20 的來源 IP
tail -n 200000 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20
# 被請求次數前 20 的 URL：CC 通常集中打少數幾個動態頁面
tail -n 200000 /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20
# 每秒請求數的變化：找出攻擊開始的時間點
tail -n 200000 /var/log/nginx/access.log | awk '{print substr($4,2,20)}' | uniq -c | sort -rn | head

典型的 CC 特徵是：大量 IP 請求同一個或少數幾個動態 URL、User-Agent 為空或高度一致、沒有載入頁面配套的 CSS 和圖片、請求間隔機械地均勻。確認之後，可以先對被打的介面單獨限速並攔掉明顯異常的請求：

http {
    # User-Agent 為空的請求直接標記
    map $http_user_agent $bad_ua {
        default 0;
        ""      1;
    }
    limit_req_zone $binary_remote_addr zone=login:10m rate=2r/s;

    server {
        if ($bad_ua) { return 444; }

        # 只對高消耗介面限速，靜態資源不受影響
        location = /api/login {
            limit_req zone=login burst=5 nodelay;
            proxy_pass http://backend;   # backend 為你已定義的 upstream
        }
    }
}

return 444 是 Nginx 特有的寫法，直接關閉連線、不返回任何回應，比返回 403 更省資源。

在機房管理系統裡能做什麼

CC 攻擊主要由業務方處理，機房側能做的是讓資訊透明、讓影響可控。Toplink DCIM 的客戶自助端可以檢視伺服器的流量使用和被攻擊事件記錄，客戶看到入向頻寬平穩而網站不可用，就能直接朝應用層排查，而不是先懷疑機房線路；如果被打的伺服器反過來向外噴出異常流量，頻寬自動限速會按平均頻寬自動把連接埠限到設定速率，避免波及同一交換器上的其他客戶。