Các nút tập trung lưu lượng VPN, bộ định tuyến mạng lưới và cổng xuất (egress gateway) dung lượng lớn thường xuyên phải xử lý lưu lượng tổng hợp vượt mức 40 Gbps trên các máy chủ đa nhân hiện đại. Trong mô hình lập trình socket Linux tiêu chuẩn, mỗi lệnh gửi dữ liệu khởi tạo qua send(2) hoặc sendmsg(2) đều buộc nhân hệ điều hành phải sao chép dữ liệu từ bộ đệm của ứng dụng người dùng vào các cấu trúc bộ đệm hạt nhân (sk_buff).

Với các tác vụ mạng thông thường, chi phí sao chép này không đáng kể. Tuy nhiên, dưới áp lực truyền tải liên tục nhiều gigabit mỗi giây, việc nhân bản dữ liệu bộ nhớ liên tục trở thành điểm nghẽn nghiêm trọng: các nhân CPU có thể tiêu tốn tới 35% chu kỳ thực thi chỉ để chạy các lệnh sao chép bộ nhớ (copy_user_generic_string), làm bão hòa băng thông bus RAM và đẩy các trạng thái mã hóa nóng ra khỏi bộ đệm cache L1/L2 của bộ vi xử lý.

Nhân Linux giải quyết triệt để rào cản kiến trúc này thông qua cờ truyền dữ liệu MSG_ZEROCOPY (được giới thiệu từ Linux 4.14 và hỗ trợ toàn diện trên các socket TCP, UDP và raw packet). Bằng cách ghim trực tiếp các trang bộ nhớ vật lý của ứng dụng người dùng vào bảng trang và đưa vào danh sách phân tán (scatter-gather list) để card mạng (NIC) truy cập bộ nhớ trực tiếp (DMA), MSG_ZEROCOPY triệt tiêu hoàn toàn thao tác sao chép dữ liệu trên đường truyền ra.

Gánh nặng bão hòa Bus bộ nhớ trong truyền Socket truyền thống

Để hiểu rõ nguyên nhân việc ghi socket truyền thống hạn chế hiệu năng của các cổng VPN tốc độ cao, hãy xem xét đường đi bộ nhớ của một khối dữ liệu đường hầm được mã hóa:

[ Tiến trình VPN không gian người dùng ]
       | (Bộ đệm dữ liệu nằm trong RAM ứng dụng)
       | sendto(fd, buf, len, 0, ...)
       v
[ Tầng Socket nhân: __copy_from_user() ]
       | (Sao chép toàn bộ dữ liệu vào trang nhớ sk_buff)
       v
[ Ngăn xếp mạng nhân: Định tuyến IP, Netfilter, Qdisc ]
       v
[ Hàng đợi vòng của Driver NIC: Ánh xạ DMA ]
       | (Card mạng đọc trực tiếp dữ liệu từ RAM qua PCIe DMA)
       v
[ Card mạng vật lý (NIC) ]

Khi ứng dụng truyền một khối dữ liệu kích thước 16 KB, CPU phải nạp các byte từ bộ nhớ ảo của ứng dụng qua các thanh ghi CPU rồi ghi chúng vào các trang bộ nhớ nhân mới được cấp phát. Ở tốc độ đường truyền 40 Gbps, quy trình sao chép này luân chuyển hơn 5 GB dữ liệu thô mỗi giây qua bus bộ nhớ của máy chủ.

Chi phí này dẫn tới ba tác động tiêu cực:

  1. Cạnh tranh băng thông Bus RAM: Các thuật toán mật mã—chẳng hạn như mã hóa dòng ChaCha20-Poly1305 và hàm băm Blake2s—đã sử dụng rất nhiều băng thông bus bộ nhớ. Việc sao chép dữ liệu socket lặp đi lặp lại chiếm dụng các kênh RAM quý giá, làm giảm hiệu suất của bộ gia tốc mã hóa.
  2. Làm bẩn bộ nhớ đệm Cache CPU: Việc đọc và ghi liên tục các gigabyte bộ đệm gói tin tạm thời sẽ xóa sạch các bảng định tuyến, ngữ cảnh phiên bảo mật và thông tin đường hầm của người dùng khỏi bộ nhớ đệm cache siêu tốc L1 và L2.
  3. Gia tăng độ trễ chuyển đổi ngữ cảnh: Thao tác sao chép đồng bộ giữ luồng ứng dụng nằm trong ngữ cảnh thực thi của nhân cho đến khi toàn bộ khối bộ đệm được sao chép xong.

Phân tích kiến trúc chuyên sâu của cơ chế MSG_ZEROCOPY

Cơ chế MSG_ZEROCOPY thay đổi căn bản cách xử lý bộ đệm bằng cách ủy thác việc đọc dữ liệu trực tiếp cho phần cứng mạng:

[ Tiến trình VPN: Bộ đệm buf ]
       |
       | 1. send(fd, buf, len, MSG_ZEROCOPY)
       |    (Nhân ghim trang nhớ qua get_user_pages_fast)
       |
       +======================+ (Tham chiếu phân tán, KHÔNG sao chép byte)
       |                      |
       v                      v
[ Cấu trúc skb nhân: frags[] ] -> [ Phần cứng NIC: Đọc DMA trực tiếp từ RAM ]
       |
       | 2. Gói tin được truyền ra đường truyền vật lý
       | 3. NIC phát tín hiệu ngắt hoàn tất truyền DMA
       v
[ Hàng đợi lỗi Socket: SO_EE_ORIGIN_ZEROCOPY ]
       |
       | 4. Tiến trình thu hồi buf qua recvmsg(MSG_ERRQUEUE)
       v
[ Tái sử dụng an toàn bộ đệm cho chu kỳ mã hóa tiếp theo ]

1. Kỹ thuật ghim trang nhớ với get_user_pages_fast()

Khi ứng dụng truyền cờ MSG_ZEROCOPY vào lệnh gọi send(2) hoặc sendmsg(2), nhân Linux không cấp phát bộ nhớ chứa dữ liệu gói tin. Thay vào đó, nhân gọi hàm get_user_pages_fast() để ghim các trang bộ nhớ vật lý đang lưu trữ con trỏ của ứng dụng. Nhân chỉ ghi lại tham chiếu trang vào cấu trúc thông tin dùng chung của bộ đệm socket (skb_shinfo(skb)->frags[]).

Vì dữ liệu không bị sao chép, CPU chỉ cần xử lý phần tiêu đề gói tin (header UDP và IP). Phần cứng card mạng đọc trực tiếp dữ liệu gói tin từ RAM người dùng qua bus PCIe thông qua cơ chế scatter-gather DMA.

2. Hàng đợi lỗi Socket và thông báo hoàn tất bất đồng bộ

Do card mạng đọc từ bộ nhớ ứng dụng theo phương thức bất đồng bộ, tiến trình không gian người dùng không được phép ghi đè hoặc giải phóng bộ đệm ngay lập tức để tránh làm sai lệch dữ liệu đang truyền trên đường dây vật lý. Nhân điều phối việc giải phóng bộ đệm thông qua hàng đợi lỗi của socket (MSG_ERRQUEUE):

#define _GNU_SOURCE
#include <sys/socket.h>
#include <linux/errqueue.h>
#include <netinet/in.h>
#include <stdio.h>
#include <unistd.h>

/* Kích hoạt tính năng Zero-copy trên bộ mô tả socket */
int enable_zerocopy(int sock_fd) {
    int one = 1;
    if (setsockopt(sock_fd, SOL_SOCKET, SO_ZEROCOPY, &one, sizeof(one)) < 0) {
        perror("Lỗi thiết lập setsockopt SO_ZEROCOPY");
        return -1;
    }
    return 0;
}

/* Thu hồi bộ đệm đã ghim sau khi DMA hoàn tất truyền vật lý */
void reap_zerocopy_completions(int sock_fd) {
    char control[1024];
    struct msghdr msg = {0};
    struct cmsghdr *cmsg;
    struct sock_extended_err *serr;

    msg.msg_control = control;
    msg.msg_controllen = sizeof(control);

    /* Đọc thông báo bất đồng bộ từ hàng đợi lỗi */
    while (recvmsg(sock_fd, &msg, MSG_ERRQUEUE | MSG_DONTWAIT) > 0) {
        for (cmsg = CMSG_FIRSTHDR(&msg); cmsg; cmsg = CMSG_NXTHDR(&msg, cmsg)) {
            if (cmsg->cmsg_level == SOL_IP && cmsg->cmsg_type == IP_RECVERR) {
                serr = (struct sock_extended_err *)CMSG_DATA(cmsg);
                if (serr->ee_origin == SO_EE_ORIGIN_ZEROCOPY) {
                    uint32_t lo = serr->ee_info;  /* ID chuỗi đầu tiên hoàn tất */
                    uint32_t hi = serr->ee_data;  /* ID chuỗi cuối cùng hoàn tất */
                    /* Các bộ đệm trong dải [lo, hi] đã an toàn để tái sử dụng */
                }
            }
        }
    }
}

Nhân Linux gán một số thứ tự 32-bit tăng dần cho mỗi lần gửi dữ liệu zero-copy. Khi driver NIC xử lý xong bộ mô tả truyền và giải phóng sk_buff, nhân sẽ đẩy một thông báo vào hàng đợi lỗi của socket chứa dải số thứ tự đã hoàn tất (ee_info đến ee_data).

Khi nào cơ chế Zero-Copy mang lại hiệu quả thực tế?

Công nghệ Zero-copy không phải giải pháp áp dụng cho mọi kích thước gói tin. Việc ghim trang nhớ qua get_user_pages_fast() và xử lý thông báo sự kiện từ hàng đợi lỗi tiêu tốn một lượng tính toán cố định. Các kỹ sư hệ thống cần dựa trên ngưỡng kích thước dữ liệu (payload threshold):

Kích thước khối dữ liệu Lệnh sendmsg() truyền thống Truyền với MSG_ZEROCOPY Khuyến nghị kỹ thuật
Nhỏ (< 1,500 bytes) Xử lý nhanh (dữ liệu nằm sẵn trong cache) Tải ghim trang nhớ chiếm ưu thế Dùng sendmsg() thông thường
Trung bình (1,500 – 4,000 bytes) Hiệu năng tương đương Hiệu năng tương đương Cân bằng
Lớn (4,000 – 16,000 bytes) Tải bus bộ nhớ bắt đầu tăng cao Giảm 30% chu kỳ xử lý của CPU Khuyến khích sử dụng
Siêu lớn (> 16,000 bytes / GSO) Gây nghẽn CPU nghiêm trọng Giảm 55% chu kỳ xử lý của CPU Bắt buộc để tối ưu

Đối với các cổng VPN áp dụng cơ chế gộp gói tin Generic Segmentation Offload (UDP GSO) gom các gói thành khối lớn từ 16 KB đến 64 KB, MSG_ZEROCOPY tạo ra sự bứt phá vượt bậc về thông lượng truyền dẫn.

Ứng dụng thực tiễn trong hệ sinh thái VPNRice và RiceGuard

Trong kiến trúc mạng của VPNRice, các nút cổng Anycast và máy chủ biên tích hợp trực tiếp MSG_ZEROCOPY vào đường truyền xuất của giao thức RiceGuard:

[ Động cơ mã hóa RiceGuard ]
       | (Mã hóa gói gộp vào bộ đệm vòng cố định 64 KB)
       |
       | 1. sendto(udp_fd, ring_slot, 64KB, MSG_ZEROCOPY, ...)
       v
[ Tầng Socket nhân Linux ]
       | (Ghim bộ nhớ ring_slot, không sao chép dữ liệu)
       v
[ Card mạng 100 GbE Mellanox / Intel ]
       | (Truyền tải dữ liệu qua PCIe DMA)
       |
       | 2. Thông báo Error Queue trả lại ring_slot về kho đệm
       v
[ Thu hồi và tái cấp phát bộ đệm RiceGuard ]
  1. Quản lý bộ đệm vòng cố định: RiceGuard cấp phát sẵn một vùng nhớ đệm dạng vòng được ghim trước. Các khung đường hầm mã hóa được ghi trực tiếp vào các ô nhớ này, loại bỏ hoàn toàn việc cấp phát bộ nhớ động.
  2. Kết hợp hiệp đồng UDP GSO và Zero-Copy: RiceGuard gộp tối đa 45 gói tin đường hầm đơn lẻ vào một đoạn GSO duy nhất 64 KB và truyền đi bằng MSG_ZEROCOPY. Thiết kế này kết hợp ưu thế một lời gọi hệ thống duy nhất với việc không nhân bản dữ liệu trong bộ nhớ.
  3. Bảo toàn băng thông RAM cho mã hóa: Bằng cách giảm tải công việc chuyển dữ liệu cho bộ điều khiển DMA của card mạng, các kênh RAM được dành trọn vẹn cho thuật toán mã hóa ChaCha20-Poly1305, giúp các máy chủ biên duy trì thông lượng mã hóa 40 Gbps mà không rớt gói.

Kiểm tra vận hành và chẩn đoán trên Linux

Để theo dõi hoạt động truyền zero-copy và giám sát trạng thái hàng đợi trên cổng gateway Linux, quản trị viên sử dụng các công cụ chẩn đoán mạng chuẩn:

# Kiểm tra số lượng phân bổ và hoàn tất socket zero-copy
cat /proc/net/snmp | grep -E "Udp:|Ip:"

# Giám sát độ sâu hàng đợi socket và hàng đợi lỗi
ss -u -m -i

Bằng cách tách rời việc truyền dữ liệu khỏi chi phí sao chép bộ nhớ CPU, Linux MSG_ZEROCOPY mang lại cho các cổng VPN hiện đại khả năng khai thác tối đa tốc độ phần cứng, đồng thời bảo vệ tài nguyên tính toán và bộ nhớ đệm quý giá của máy chủ.