Nghịch lý độ trễ: Tại sao hàng đợi phần cứng làm tê liệt thuật toán AQM

Các quản trị viên hệ thống gateway VPN và trạm chuyển tiếp lưu lượng mạng tốc độ cao thường gặp phải một nghịch lý hiệu năng: dù đã kích hoạt các thuật toán Quản lý Hàng đợi Chủ động (AQM) tiên tiến như FQ-CoDel hay CAKE trên giao diện mạng, người dùng vẫn gặp tình trạng độ trễ tăng vọt từ 50 đến 150 mili-giây khi tải nặng. Các luồng thoại VoIP bị giật hạt, trò chơi trực tuyến xuất hiện jitter và băng thông TCP dao động thất thường.

Nguyên nhân gốc rễ không nằm ở tầng thuật toán hàng đợi phần mềm (qdisc) của nhân Linux, mà tích tụ ở tầng sâu hơn: hàng đợi truyền tải (TX ring buffer) của driver và phần cứng card mạng (NIC).

Các card mạng Ethernet hiện đại thường thiết lập kích thước vòng mô tả phần cứng rất lớn (thường là 1024, 2048 hoặc 4096 bộ mô tả) nhằm tránh cạn kiệt gói tin và đạt tốc độ tối đa theo băng thông vật lý. Với các luồng TCP cục bộ, nhân Linux sử dụng cơ chế TCP Small Queues (TSQ) để kiểm soát bộ nhớ socket. Tuy nhiên, các gateway VPN lại xử lý lưu lượng đã được đóng gói:

[ Ứng dụng TCP/UDP người dùng ] ---> [ Động cơ VPN (WireGuard / IPsec / OpenVPN) ]
                                                        |
                                                        v
                                         [ Gói tin UDP đóng gói bên ngoài ]
                                                        |
                                                        v
                                         [ Tầng mạng Egress của Linux ]
                                                        |
                                                        v
                                          [ Hàng đợi phần mềm Qdisc ]
                                                        |
                                                        v
                                         [ Vòng mô tả phần cứng TX của NIC ]
                                         (1024-4096 Bộ mô tả = Bufferbloat!)
                                                        |
                                                        v
                                              [ Cáp mạng vật lý ]

Đối với hệ thống mạng của máy chủ, các gói tin đường hầm bên ngoài chỉ đơn thuần là các gói UDP thông thường. Do đó, TSQ không thể can thiệp vào các luồng dữ liệu lồng ghép bên trong. Khi một người dùng tải tệp tin dung lượng lớn qua VPN, socket UDP bên ngoài sẽ xả hàng loạt cụm gói tin dung lượng nhiều megabyte vào luồng xuất. Hàng đợi phần mềm qdisc lập tức đẩy toàn bộ dữ liệu này xuống vòng mô tả phần cứng. Khi các gói tin đã nằm trong hàng đợi phần cứng của card mạng, thuật toán FQ-CoDel hoàn toàn mất quyền kiểm soát. Chúng bị giữ lại trong hàng đợi phần cứng chờ truyền tải, gây ra hiện tượng bufferbloat nghiêm trọng.

Nhân Linux giải quyết triệt để điểm nghẽn này thông qua cơ chế Byte Queue Limits (BQL), vận hành bởi thuật toán Dynamic Queue Limits (dql).

Thuật toán DQL: Đo lường thời gian xả thực tế theo byte

Được phát triển bởi kỹ sư Tom Herbert và tích hợp trực tiếp vào nhân Linux, cơ chế BQL dựa trên một nguyên lý cốt lõi: độ sâu của hàng đợi phần cứng phải được định lượng bằng số byte thực tế, thay vì đếm số lượng bộ mô tả gói tin.

Một bộ mô tả phần cứng đơn lẻ có thể chứa một siêu gói tin gộp dung lượng tới 64KB (nhờ tính năng Generic Segmentation Offload - GSO), hoặc chỉ chứa một gói TCP ACK nhỏ gọn vỏn vẹn 64 byte. Việc đo lường hàng đợi dựa trên số lượng gói tin tạo ra sự chênh lệch thời gian truyền tải rất lớn:

  • 1024 gói tin kích thước nhỏ trên đường truyền 1 Gbps sẽ thoát hết chỉ trong khoảng 0.5 mili-giây.
  • Nhưng 1024 khung dữ liệu GSO kích thước 64KB trên cùng đường truyền đó tương đương với 65 MB dữ liệu đệm, tiêu tốn hơn 500 mili-giây để đẩy hết ra dây dẫn!

BQL thiết lập vòng lặp phản hồi thời gian thực bên trong tệp nguồn lib/dynamic_queue_limits.c. Thuật toán liên tục đo đạc thời gian card mạng giải phóng một khối lượng byte nhất định từ vòng truyền tải.

+--------------------------------------------------------------------------+
|                       Đường truyền Egress của Netdevice                  |
+--------------------------------------------------------------------------+
                                     |
               netdev_tx_sent_queue(dev_queue, bytes)
                                     |
                                     v
                 +---------------------------------------+
                 | Kiểm tra: num_queued >= adj_limit ?   |
                 +---------------------------------------+
                        |                         |
                      ĐÚNG                       SAI
                        |                         |
                        v                         v
           netif_tx_stop_queue()          Chuyển gói tin xuống
           (Giữ gói tin ở lại              vòng mô tả phần cứng
            hàng đợi phần mềm Qdisc!)             |
                                                  v
                                      +-----------------------+
                                      | Ngắt phần cứng hoàn tất|
                                      +-----------------------+
                                                  |
                                                  v
                                 netdev_tx_completed_queue(...)
                                 -> Gọi hàm dql_completed()
                                 -> Tự động cập nhật giới hạn byte
                                 -> Kích hoạt netif_tx_wake_queue()

Thuật toán liên tục cập nhật giới hạn sau mỗi khoảng thời gian dql->hold_time (mặc định 100 mili-giây):

  1. Ghi nhận lưu lượng nạp: Khi driver đẩy dữ liệu vào phần cứng, nó gọi hàm dql_queued(&dev_queue->dql, bytes). Biến num_queued tăng lên theo số byte nạp vào.
  2. Ghi nhận lưu lượng giải phóng: Khi phần cứng kích hoạt ngắt hoàn tất truyền tải (hoặc trong chu trình NAPI poll), driver gọi dql_completed(&dev_queue->dql, count).
  3. Điều chỉnh giới hạn động:
    • Nếu hàng đợi phần cứng cạn kiệt hoàn toàn về 0 (num_queued == 0), card mạng đang bị bỏ đói dữ liệu. DQL sẽ tăng adj_limit để duy trì thông lượng tối đa.
    • Nếu dữ liệu liên tục ứ đọng trong hàng đợi suốt khoảng thời gian đo lường mà không có thời điểm cạn, hàng đợi đang quá sâu. DQL sẽ giảm adj_limit về mức vừa đủ cho phần cứng truyền tải liên tục.

Nhờ cơ chế này, BQL duy trì hàng đợi phần cứng chỉ chứa từ 3 đến 12 KB dữ liệu tại mỗi thời điểm. Độ trễ phần cứng được giữ chặt dưới mức 50 đến 100 micro-giây, buộc các gói tin dư thừa phải xếp hàng trên tầng qdisc của hệ điều hành, nơi các thuật toán quản lý luồng phát huy đầy đủ vai trò.

Tích hợp BQL trong luồng truyền tải của Driver mạng

Các driver thiết bị mạng tích hợp BQL bằng cách bao bọc hàm truyền tải và hàm xử lý ngắt bằng các hàm trợ giúp chuẩn của kernel.

1. Hàm truyền tải của Driver (ndo_start_xmit)

Khi nhân Linux chuyển một vùng đệm gói tin (sk_buff) cho driver, driver kiểm tra giới hạn BQL trước khi đưa vào hàng đợi phần cứng:

/* Đoạn mã minh họa tích hợp BQL trong driver mạng Linux */
static netdev_tx_t driver_xmit_frame(struct sk_buff *skb, struct net_device *dev)
{
    struct driver_adapter *adapter = netdev_priv(dev);
    struct netdev_queue *txq = netdev_get_tx_queue(dev, skb_get_queue_mapping(skb));
    unsigned int bytes = skb->len;

    /* Kiểm tra dung lượng còn trống của vòng mô tả phần cứng */
    if (unlikely(!driver_has_tx_space(adapter))) {
        netif_tx_stop_queue(txq);
        return NETDEV_TX_BUSY;
    }

    /* Đăng ký số byte gửi đi với hệ thống BQL */
    netdev_tx_sent_queue(txq, bytes);

    /* Chuyển giao gói tin cho bộ điều khiển DMA của phần cứng */
    driver_submit_to_hardware(adapter, skb);

    return NETDEV_TX_OK;
}

Nếu hàm netdev_tx_sent_queue() nhận thấy lượng bytes nạp vào làm cho num_queued vượt quá adj_limit, nó sẽ gọi netif_tx_stop_queue(txq). Lệnh này báo hiệu cho hệ điều hành tạm dừng nạp dữ liệu xuống card mạng.

2. Hàm xử lý ngắt hoàn tất truyền tải (NAPI Poll Handler)

Khi card mạng truyền tải thành công các khung dữ liệu, driver đọc con trỏ phần cứng và thông báo số byte đã giải phóng cho DQL:

static bool driver_clean_tx_irq(struct driver_q_vector *q_vector, int budget)
{
    struct driver_adapter *adapter = q_vector->adapter;
    unsigned int total_bytes = 0, total_packets = 0;

    /* Thu hồi các bộ mô tả đã truyền xong */
    while (driver_reclaim_tx_descriptors(adapter, &total_bytes, &total_packets)) {
        if (total_packets >= budget)
            break;
    }

    /* Báo cho BQL lượng byte đã rời khỏi phần cứng */
    netdev_tx_completed_queue(txq, total_packets, total_bytes);

    return (total_packets < budget);
}

Trong hàm netdev_tx_completed_queue(), nhân tính toán lại giới hạn động và kích hoạt lại hàng đợi qua lệnh netif_tx_wake_queue(txq).

Cơ chế đóng gói UDP: Tại sao WireGuard và IPsec cần BQL

Trong các hệ thống đường hầm VPN, các gói tin được đóng gói tại Tầng 3 hoặc Tầng 4:

  1. Thiết bị người dùng đồng thời khởi tạo nhiều luồng: một phiên SSH, một cuộc gọi thoại, và một luồng tải tệp dung lượng lớn.
  2. Gateway VPN gom nhóm và mã hóa các luồng này vào các gói UDP bên ngoài.
  3. Khi bật tính năng UDP GSO, nhiều gói tin nhỏ sẽ được gộp thành các khung UDP lớn tới 64KB (skb->len = 65535).

Nếu không có BQL, việc đẩy 4 gói UDP gộp 64KB vào vòng mô tả phần cứng sẽ khóa cứng 256KB dữ liệu trong card mạng. Trên một đường truyền tải lên tốc độ 100 Mbps, việc truyền hết 256KB sẽ gây ra độ trễ:

$$\text{Độ trễ} = \frac{256 \times 1024 \times 8 \text{ bits}}{100 \times 10^6 \text{ bps}} \approx 20.97 \text{ ms}$$

Độ trễ 21 mili-giây ngay tại phần cứng này phá vỡ tính liên tục của cuộc gọi thoại và trò chơi trực tuyến. Dù FQ-CoDel ở tầng trên có ưu tiên gói tin thoại đến đâu, gói tin đó vẫn buộc phải xếp hàng chờ sau khối lượng dữ liệu khổng lồ đang nằm sẵn trong phần cứng.

Khi bật BQL, nhân nhận diện đường truyền 100 Mbps chỉ giải phóng được khoảng 4KB mỗi 300 micro-giây. BQL siết chặt adj_limit xuống quanh mức 4096 byte. Các gói UDP tải tệp lớn lập tức bị chặn lại ở ranh giới driver và giữ trong qdisc.

Ngay khi người dùng nói vào micro, gói tin thoại xuất hiện tại FQ-CoDel. Do FQ-CoDel phân loại luồng thông minh, gói tin thoại lập tức được đưa lên đầu hàng đợi phần mềm, vượt qua luồng tải tệp. Khi card mạng truyền xong 1500 byte và phát ngắt, BQL mở khóa hàng đợi, và gói tin thoại được bắn ngay lập tức ra dây cáp mạng.

Giám sát và tinh chỉnh tham số BQL qua hệ thống Sysfs

Quản trị viên có thể theo dõi và tinh chỉnh các giá trị BQL trực tiếp thông qua hệ thống tệp tin ảo /sys của Linux.

1. Kiểm tra trạng thái BQL qua Sysfs

Mỗi hàng đợi truyền tải của thiết bị mạng đều có một thư mục riêng tại /sys/class/net/<giao_dien>/queues/tx-<N>/byte_queue_limits/:

# Xem các thông số BQL trên giao diện eth0, hàng đợi tx-0
cd /sys/class/net/eth0/queues/tx-0/byte_queue_limits

# Xem giới hạn byte động hiện thời do nhân tính toán
cat limit
# Ví dụ kết quả: 3840 (bytes)

# Xem số byte đang xếp hàng trong phần cứng chờ truyền tải
cat queued
# Ví dụ kết quả: 1420 (bytes)

# Xem cận dưới và cận trên cho phép
cat limit_min
# Mặc định: 0

cat limit_max
# Mặc định: 1879048192

2. Tinh chỉnh trên các gateway VPN tốc độ cao

Trên các gateway xử lý đường truyền 10 Gbps hoặc 40 Gbps, các giá trị mặc định đôi khi dao động quá mức trong các đợt bùng nổ lưu lượng GSO. Quản trị viên có thể thu hẹp không gian tìm kiếm:

# Đặt giới hạn tối thiểu 4096 byte trên các cổng 10GbE
# để tránh thiếu hụt dữ liệu tức thời khi truyền cụm GSO
for q in /sys/class/net/eth0/queues/tx-*/byte_queue_limits/limit_min; do
    echo 4096 > "$q"
done

# Đặt cận trên tối đa 64KB (ngăn chặn bufferbloat mất kiểm soát)
for q in /sys/class/net/eth0/queues/tx-*/byte_queue_limits/limit_max; do
    echo 65536 > "$q"
done

3. Theo dõi BQL bằng công cụ eBPF / Bpftrace

Kỹ sư mạng có thể kiểm chứng hoạt động của BQL trên máy chủ VPN bằng lệnh bpftrace:

# Theo dõi số byte hoàn tất và gửi qua BQL
bpftrace -e '
kprobe:dql_completed {
    @completed_bytes = hist(arg1);
}
kprobe:netdev_tx_sent_queue {
    @sent_bytes = hist(arg1);
}
'

Nếu biểu đồ phân bố cho thấy các giá trị tập trung gọn gàng trong khoảng 1500 đến 8000 byte, hệ thống BQL đang kiểm soát hàng đợi phần cứng rất hiệu quả.

So sánh kiến trúc truyền thống và hàng đợi điều tiết BQL

Bảng so sánh sau làm rõ sự khác biệt giữa hàng đợi card mạng truyền thống và mô hình có sự tham gia của BQL:

Tiêu chí kỹ thuật Vòng mô tả phần cứng truyền thống Hệ thống điều tiết qua BQL
Đơn vị đo lường Số lượng bộ mô tả cố định (vd: 2048) Giới hạn số byte động (adj_limit)
Ảnh hưởng của GSO 2048 x 64KB = đệm dữ liệu tới 130MB Luôn bị chặn sau khoảng 4KB đến 16KB
Vị trí của bufferbloat Nằm sâu trong thanh ghi phần cứng Được đưa về hàng đợi phần mềm qdisc
Hiệu quả của AQM Bị vô hiệu hóa vì dữ liệu trôi xuống phần cứng Tối ưu: FQ-CoDel drop/mark gói chính xác
Độ trễ khi tải nặng Tăng vọt lên 50ms - 500ms Giữ ổn định dưới 1ms trong mọi tình huống

Khi lựa chọn phần cứng card mạng cho hạ tầng VPN (như Intel ixgbe, i40e, Mellanox mlx5 hay Broadcom bnxt_en), việc đảm bảo driver hỗ trợ đầy đủ BQL là điều kiện tiên quyết để đạt độ trễ thấp.

Kiến trúc RiceGuard: Kết hợp BQL với FQ-CoDel cho độ trễ dưới 1 mili-giây

VPNRice ứng dụng công nghệ điều tiết hàng đợi cấp driver làm nền tảng trong mạng lưới gateway hiệu năng cao. Trong luồng xử lý dữ liệu của giao thức RiceGuard, các trạm trung chuyển đồng bộ chặt chẽ giữa pacing của nhân, giới hạn phần cứng và lập lịch gói tin:

[ Lưu lượng người dùng: Thoại, Game, Web, Tải tệp ]
                         |
                         v
          [ Động cơ Mã hóa RiceGuard ]
  (Tạo các khung UDP ChaCha20-Poly1305 đa luồng)
                         |
                         v
        [ Hàng đợi phần mềm FQ-CoDel ]
  (Cách ly luồng, ưu tiên gói tương tác, đánh dấu ECN)
                         |
                         v
      [ Cơ chế Linux BQL (Động cơ dql) ]
  (Điều tiết luồng byte khớp chính xác với tốc độ xả phần cứng)
                         |
                         v
      [ Hàng đợi TX Ring phần cứng của NIC ]
  (Duy trì hàng đợi cực mỏng: chỉ 1-2 gói tin đang truyền)
                         |
                         v
               [ Cáp quang vật lý ]
  1. Chống đói dữ liệu phần cứng: Các gateway RiceGuard cấu hình ngưỡng BQL tối thiểu tối ưu trên các giao diện mạng 25GbE đa hàng đợi, ngăn ngừa hiện tượng nghẽn tuần tự mà vẫn loại trừ hoàn toàn bufferbloat.
  2. Ưu tiên luồng tương tác thực thụ: Vì BQL giữ các khung dữ liệu lớn bên ngoài phần cứng, FQ-CoDel duy trì quyền kiểm soát tuyệt đối đối với việc phân phối gói tin. Dữ liệu âm thanh và trò chơi lướt qua gateway mà không bị gián đoạn.
  3. Triệt tiêu hoàn toàn bufferbloat: Việc kết hợp giới hạn hàng đợi động với tính năng gộp gói UDP GRO/GSO giúp hạ tầng RiceGuard duy trì độ trễ đệm phần cứng dưới 1 mili-giây ngay cả khi đường truyền hoạt động hết công suất.

Việc ứng dụng triệt để cơ chế Byte Queue Limits của nhân Linux giúp VPNRice duy trì tốc độ truyền tải mã hóa vượt trội song hành cùng độ trễ cực thấp và ổn định.