Linux splice và vmsplice: Kỹ thuật Zero-Copy đường ống cho cổng chuyển tiếp VPN

Các cổng chuyển tiếp VPN dung lượng lớn, máy chủ ủy quyền xáo trộn lưu lượng và nút mạng biên doanh nghiệp thường xuyên đóng vai trò trung gian luân chuyển dữ liệu giữa các đường hầm máy khách từ xa và cụm dịch vụ nội bộ. Trong kiến trúc phần mềm thông thường, tác vụ chuyển tiếp lưu lượng trung chuyển đòi hỏi tiến trình người dùng thực hiện vòng lặp đọc và ghi liên tục qua các bộ mô tả tệp socket. Khi xử lý băng thông tổng hợp vượt ngưỡng 20 Gbps đến 40 Gbps với hàng chục nghìn phiên kết nối đồng thời, mô hình chuyển tiếp socket cổ điển này nhanh chóng làm bão hòa bus bộ nhớ và gây cạn kiệt tài nguyên CPU.

Mỗi lệnh gọi read(2) truyền thống từ một socket mạng chiều vào buộc nhân Linux phải sao chép toàn bộ khối dữ liệu tải trọng (payload) qua ranh giới đặc quyền từ bộ đệm socket nhân (sk_buff) vào bộ nhớ vùng heap của không gian người dùng. Ngay sau đó, tiến trình ủy quyền thực thi lệnh write(2) hoặc send(2) để đẩy dữ liệu vào socket đường hầm chiều ra, khiến hệ điều hành phải thực hiện thêm một lần sao chép bộ nhớ ngược lại vào không gian nhân. Dưới lưu lượng đa gigabit liên tục, các lõi CPU tiêu tốn tới 40% chu kỳ xử lý chỉ để thực thi các chỉ lệnh sao chép ô nhớ (copy_user_generic_string), đồng thời làm đẩy các khóa mật mã đang hoạt động ra khỏi bộ nhớ đệm L1 và L2 của vi xử lý.

Nhân Linux cung cấp giải pháp kiến trúc mạnh mẽ thông qua bộ đôi lệnh gọi hệ thống nối đường ống: splice(2) và vmsplice(2). Bằng cách luân chuyển dữ liệu gói tin qua một vòng đệm đường ống (pipe buffer ring) nằm hoàn toàn trong nhân mà không cần chạm tới không gian người dùng, các lệnh này cho phép cổng chuyển tiếp VPN đạt hiệu năng Zero-Copy thực thụ.

Gánh nặng sao chép bộ nhớ trong chuyển tiếp proxy thông thường

Để thấy rõ nguyên nhân gây nghẽn cổ chai khi chuyển tiếp lưu lượng ở tốc độ cao, hãy xem xét đường đi của dữ liệu qua đường hầm mã hóa:

Chuyển tiếp truyền thống qua không gian người dùng (2 lần sao chép, 4 lần chuyển ngữ cảnh):
[ NIC chiều vào ] ---> [ sk_buff chiều vào ]
                              |
                       copy_to_user (Lần 1: Từ nhân sang người dùng)
                              v
                 [ Bộ nhớ đệm không gian người dùng ]
                              |
                      copy_from_user (Lần 2: Từ người dùng sang nhân)
                              v
[ NIC chiều ra ] <--- [ sk_buff chiều ra ]

Mô hình chuyển tiếp này tạo ra ba rào cản hệ thống nghiêm trọng:

Băng thông bus bộ nhớ bị nhân đôi: Mỗi byte dữ liệu trung chuyển phải đi qua bus bộ nhớ chính 4 lần: NIC DMA vào RAM, RAM nạp vào thanh ghi CPU, CPU ghi vào RAM người dùng, và RAM người dùng ghi ngược lại bộ đệm socket. Ở tốc độ chuyển tiếp 40 Gbps, bus bộ nhớ phải gánh tới 160 Gbps lưu lượng truyền tải.
Làm xáo trộn bộ nhớ đệm CPU: Việc liên tục đưa hàng megabyte dữ liệu gói tin qua thanh ghi CPU sẽ làm tràn bộ nhớ đệm L1/L2 tốc độ cao, loại bỏ bảng khóa mã hóa của các thuật toán như ChaCha20-Poly1305 hay AES-GCM.
Chi phí chuyển đổi ngữ cảnh: Việc luân phiên giữa read(2) và write(2) gây ra hàng triệu lần chuyển đổi chế độ người dùng và chế độ nhân mỗi giây, làm lãng phí chu kỳ xử lý cho việc nạp lại bảng dịch địa chỉ TLB.

Kiến trúc splice(2): Vòng đệm trang nhớ trong đường ống

Lệnh gọi hệ thống splice(2) chuyển dữ liệu trực tiếp giữa hai bộ mô tả tệp—trong đó ít nhất một bên phải là một đường ống (pipe)—mà không sao chép byte qua ranh giới nhân-người dùng.

Cơ chế Zero-Copy trong nhân qua vòng đệm đường ống:
[ Socket chiều vào ] ═══════════════════════════════════════╗
         |                                                  ║
  splice(sock_in -> pipe)                                   ║
         v                                                  ║
[ struct pipe_inode_info ]                                  ║  Không sao chép bộ nhớ
  * Vòng đệm struct pipe_buffer (Con trỏ trang & Độ lệch)   ║  (Chỉ tráo đổi con trỏ)
         |                                                  ║
  splice(pipe -> sock_out)                                  ║
         v                                                  ║
[ Socket chiều ra ]  ═══════════════════════════════════════╝

Cơ chế hoạt động của vòng đệm đường ống

Trọng tâm của splice(2) nằm ở cấu trúc đường ống của Linux (fs/pipe.c). Một đường ống không đơn thuần là một luồng byte, mà là một vòng tròn chứa các bộ mô tả struct pipe_buffer trỏ tới các trang bộ nhớ vật lý (struct page *):

Tráo đổi con trỏ trang nhớ: Khi splice(2) kéo dữ liệu từ một socket mạng vào đường ống, nhân không sao chép byte. Thay vào đó, nó trích xuất tham chiếu tới các trang vật lý của bộ đệm socket (skb_frag_t) và gán địa chỉ này vào các vị trí trong vòng đệm đường ống.
Tăng bộ đếm tham chiếu: Nhân tăng số lượng tham chiếu của trang (page_ref_inc). Tải trọng gói tin vẫn được giữ an toàn trên RAM vật lý trong khi cấu trúc quản lý socket ban đầu được giải phóng.
Đẩy ra socket đích: Khi splice(2) đẩy dữ liệu từ đường ống vào socket chiều ra, hệ thống mạng sẽ gắn trực tiếp các con trỏ trang vật lý này vào danh sách phân tán (scatter-gather list) để card mạng gửi đi qua DMA.

Cầu nối Zero-Copy với vmsplice(2)

Trong khi splice(2) xử lý việc luân chuyển thuần túy giữa các mô tả tệp trong nhân, một số tình huống chuyển tiếp VPN yêu cầu tiến trình người dùng gắn thêm tiêu đề giao thức, chèn mã định danh phiên hoặc kiểm tra siêu dữ liệu định tuyến. Đây là lúc vmsplice(2) phát huy tác dụng.

Lệnh gọi vmsplice(2) ánh xạ trực tiếp một mảng các vùng nhớ không gian người dùng (struct iovec) vào một đường ống nhân:

ssize_t vmsplice(int fd, const struct iovec *iov, unsigned long nr_segs, unsigned int flags);

Khi được gọi kèm cờ SPLICE_F_GIFT, không gian người dùng chuyển giao quyền sở hữu các trang bộ nhớ đó cho nhân. Nếu vùng nhớ người dùng đáp ứng tiêu chuẩn căn chỉnh trang (page-aligned), nhân sẽ tích hợp thẳng các trang đó vào vòng đệm đường ống mà không sao chép dữ liệu. Các lệnh splice(2) tiếp theo có thể định tuyến những trang này thẳng ra giao diện mạng vật lý.

Triển khai thực tế: Xây dựng cổng chuyển tiếp Zero-Copy

Một nút chuyển tiếp trung chuyển hiệu năng cao tạo một cặp đường ống hai chiều cho mỗi phiên kết nối đường hầm đang hoạt động. Vòng lặp chuyển tiếp thực thi các lệnh splice(2) không chặn dưới sự điều khiển của epoll(7):

#define _GNU_SOURCE
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
#include <errno.h>

#define RELAY_CHUNK_SIZE 65536

// Chuyển tiếp gói tin giữa socket vào và socket ra bằng splice
int relay_socket_pair(int fd_in, int fd_out, int pipefd[2]) {
    // Giai đoạn 1: Kéo dữ liệu từ socket vào sang đường ống nhân trung gian
    ssize_t spliced_in = splice(fd_in, NULL, pipefd[1], NULL,
                                RELAY_CHUNK_SIZE,
                                SPLICE_F_MOVE | SPLICE_F_NONBLOCK);
    
    if (spliced_in <= 0) {
        if (errno == EAGAIN || errno == EWOULDBLOCK) return 0;
        return -1; // Socket đóng hoặc lỗi kết nối
    }

    // Giai đoạn 2: Đẩy dữ liệu từ đường ống nhân sang socket ra
    ssize_t spliced_out = 0;
    while (spliced_out < spliced_in) {
        ssize_t written = splice(pipefd[0], NULL, fd_out, NULL,
                                 spliced_in - spliced_out,
                                 SPLICE_F_MOVE | SPLICE_F_NONBLOCK);
        
        if (written <= 0) {
            if (errno == EAGAIN || errno == EWOULDBLOCK) {
                // Dữ liệu còn trong ống; epoll sẽ báo khi fd_out sẵn sàng ghi tiếp
                break;
            }
            return -1;
        }
        spliced_out += written;
    }

    return spliced_out;
}

Tối ưu hóa kích thước đường ống

Theo mặc định, Linux cấp phát 16 trang (64 KB) cho mỗi đường ống. Trên các cổng VPN gánh tải nhiều gigabit, dung lượng này có thể gây hiện tượng tắc nghẽn ngược. Quản trị viên nên mở rộng kích thước đường ống bằng hàm fcntl với F_SETPIPE_SZ:

// Mở rộng dung lượng ống lên 1 MB (256 trang) cho luồng dữ liệu lớn
fcntl(pipefd[0], F_SETPIPE_SZ, 1048576);

Giới hạn đường ống toàn hệ thống có thể được tinh chỉnh qua sysctl:

# Thiết lập giới hạn kích thước ống tối đa lên 4 MB mỗi ống
sysctl -w fs.pipe-max-size = 4194304

Ứng dụng trong kiến trúc RiceGuard VPN

RiceGuard, công nghệ định tuyến tầng mạng của VPNRice, ứng dụng kỹ thuật nối đường ống trong nhân trên toàn bộ cụm chuyển tiếp:

Gắn tiêu đề với vmsplice: Khi các luồng trung chuyển cần đóng gói động hoặc đánh nhãn đường hầm, RiceGuard tạo khung giao thức ở không gian người dùng và đẩy vào qua vmsplice(2) kèm cờ SPLICE_F_GIFT, loại bỏ hoàn toàn việc nhân đôi bộ đệm.
Tách biệt luồng trung chuyển: Với các tuyến kết nối liên trung tâm dữ liệu nơi các khối dữ liệu mã hóa được luân chuyển giữa các điểm hiện diện (PoP), các luồng xử lý của RiceGuard kết nối đường hầm máy khách thẳng tới đường truyền trục thông qua splice(2).
Hiệu quả phần cứng vượt trội: Trong các thử nghiệm tải thực tế với 40 Gbps lưu lượng trên 12.000 luồng đồng thời, việc thay thế vòng lặp recv(2)/send(2) bằng splice(2) đã giảm mức chiếm dụng CPU từ 68% xuống còn 22%, đồng thời hạ độ trễ trung chuyển thêm 32%.

Câu hỏi thường gặp

Lệnh splice(2) có thể chuyển dữ liệu trực tiếp giữa hai socket mà không cần ống không?

Không. Trong kiến trúc nhân Linux, ít nhất một trong hai bộ mô tả tệp trong lệnh splice(2) phải là đường ống. Tuy nhiên, chi phí tạo một cặp ống (pipe2(2)) là không đáng kể và vòng đệm đường ống đóng vai trò như một hàng đợi trong nhân rất tối ưu.

splice(2) có hoạt động được với các giao thức mã hóa như TLS hay WireGuard không?

Có. Khi việc mã hóa hoặc giải mã diễn ra ở tầng nhân (chẳng hạn như kTLS hoặc các đường hầm WireGuard tầng nhân), splice(2) vận hành trực tiếp trên các luồng dữ liệu socket mà không cần đưa dữ liệu lên không gian người dùng.

Điều gì xảy ra nếu gói tin mạng bị phân mảnh trong bộ đệm socket?

Linux splice(2) xử lý các bộ đệm socket phân mảnh một cách trong suốt. Nhân duyệt qua từng mảnh trong danh sách scatter-gather và điền vào các ô kế tiếp trong vòng đệm pipe_buffer, bảo toàn nguyên vẹn tính toàn vẹn của dữ liệu qua nút chuyển tiếp.