Giới hạn đồng thời: Vì sao select và poll quá tải ở quy mô lớn

Các cụm máy chủ tập trung VPN gateway và trạm trung chuyển lưu lượng quy mô lớn thường phải duy trì hàng chục đến hàng trăm nghìn phiên kết nối khách hàng đồng thời trên một máy chủ vật lý. Mỗi đường hầm hoạt động đều duy trì trạng thái socket UDP hoặc TCP riêng biệt, các khóa phiên mã hóa và các bộ đếm thời gian heartbeat kiểm tra duy trì kết nối.

Trong các phần mềm mạng thời kỳ đầu, việc ghép kênh vào/ra (I/O multiplexing) chủ yếu dựa vào các lời gọi hệ thống BSD truyền thống: select() và poll(). Dù dễ hiểu, cả hai giao diện này đều mang độ phức tạp thuật toán tuyến tính $O(N)$, khiến chúng không thể đáp ứng được các gateway lưu lượng cao:

  1. Chi phí quét tuyến tính ở mỗi vòng lặp sự kiện: Cả select() và poll() đều chuyển toàn bộ mảng bộ mô tả tệp từ không gian người dùng vào nhân ở mỗi lần gọi. Nhân hệ điều hành buộc phải duyệt qua từng bộ mô tả một—ngay cả khi chỉ có 5 socket trong tổng số 50.000 socket có gói tin mã hóa cần đọc. Khi số lượng kết nối tăng vọt, CPU dành phần lớn thời gian chỉ để kiểm tra các kết nối đang rảnh rỗi.
  2. Sao chép bộ nhớ và cấp phát lặp đi lặp lại: Mỗi lời gọi select() hay poll() đều phải cấp phát lại và sao chép cấu trúc dữ liệu qua lại giữa không gian người dùng và không gian nhân. Với một gateway phục vụ 100.000 phiên, việc luân chuyển hàng megabyte dữ liệu mô tả hàng chục lần mỗi giây làm nghẽn bus bộ nhớ và xóa sạch bộ đệm cache CPU.
  3. Giới hạn số lượng bộ mô tả tệp cố định: Tiêu chuẩn POSIX đặt giá trị FD_SETSIZE (thường là 1024 bộ mô tả) cho select(), buộc các phần mềm cũ phải tạo ra nhiều tiến trình cồng kềnh chỉ để chứa đủ lượng người dùng lớn.

Để giải quyết bài toán đồng thời ở quy mô lớn với hiệu suất ổn định $O(1)$, Linux phát triển hệ thống con epoll.

Cấu trúc bên trong của Linux epoll

Được đưa vào từ nhân Linux 2.6, epoll khắc phục triệt để điểm nghẽn hiệu năng bằng cách chia việc giám sát sự kiện thành hai giai đoạn độc lập: đăng ký trạng thái và truy xuất sự kiện. Thay vì truyền toàn bộ danh sách ở mỗi vòng lặp, nhân Linux duy trì một cấu trúc dữ liệu nội bộ ngay trong bộ nhớ nhân.

+-------------------------------------------------------------------------+
|                    Vòng lặp sự kiện VPN (User-Space)                    |
+-------------------------------------------------------------------------+
       |                                                    ^
       | epoll_ctl(EPOLL_CTL_ADD / MOD / DEL)               | epoll_wait()
       v                                                    |
+-------------------------------------------------------------------------+
|                         Ngữ cảnh epoll trong nhân                       |
|                                                                         |
|   +-----------------------------------------------------------------+   |
|   |                  Cây Đỏ-Đen giám sát (rbr Tree)                 |   |
|   |         - Thêm, tìm kiếm, xóa với độ phức tạp O(log N)          |   |
|   |         - Giữ nguyên trạng thái qua các vòng kiểm tra           |   |
|   +-----------------------------------------------------------------+   |
|                                    |                                    |
|                                    v [Ngắt mạng / Đánh thức]            |
|   +-----------------------------------------------------------------+   |
|   |                   Danh sách sẵn sàng (rdllist)                  |   |
|   |         - Trả về tức thời O(1) các socket có dữ liệu đến        |   |
|   +-----------------------------------------------------------------+   |
+-------------------------------------------------------------------------+
       |                                                    |
       v Khung dữ liệu qua DMA                              v Phân phối gói tin
+-------------------------------------------------------------------------+
|                    Card mạng vật lý / Thiết bị TUN/TAP                  |
+-------------------------------------------------------------------------+

Ba thành phần cốt lõi của epoll

Cơ chế này hoạt động dựa trên ba lời gọi hệ thống tối giản:

  • epoll_create1(int flags): Khởi tạo một đối tượng epoll trong không gian nhân. Cờ EPOLL_CLOEXEC bảo đảm bộ mô tả này tự động đóng lại khi có tiến trình con được gọi qua execve().
  • epoll_ctl(int epfd, int op, int fd, struct epoll_event *event): Quản lý cây đỏ-đen (rbr) lưu trữ các socket cần theo dõi. Các thao tác thêm (EPOLL_CTL_ADD), sửa (EPOLL_CTL_MOD) và xóa (EPOLL_CTL_DEL) diễn ra trong thời gian $O(\log N)$, loại bỏ hoàn toàn việc sao chép mảng dữ liệu lớn.
  • epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout): Chờ cho đến khi có sự kiện xuất hiện. Hàm chỉ trả về danh sách các socket đang có dữ liệu sẵn sàng, đạt hiệu suất truy xuất $O(1)$ bất kể tổng số kết nối đang theo dõi là bao nhiêu.

Cơ chế kích hoạt: Level-Triggered so với Edge-Triggered (EPOLLET)

Theo mặc định, epoll chạy ở chế độ Level-Triggered (LT). Tuy nhiên, để tối ưu hóa hiệu năng cho các máy chủ VPN thông lượng cao, việc chuyển sang chế độ Edge-Triggered (ET) thông qua cờ EPOLLET là một bước ngoặt lớn.

Chế độ Level-Triggered (LT):
Dữ liệu còn trong hàng đợi socket ─────────────────────────────────────────>
epoll_wait() kích hoạt báo sự kiện    [CÓ]     [CÓ]     [CÓ]     [CÓ]   ...
(Báo liên tục cho đến khi đọc sạch toàn bộ dữ liệu về 0 byte)

Chế độ Edge-Triggered (ET - EPOLLET):
Dữ liệu mới đến (Chuyển trạng thái: Rỗng -> Có dữ liệu) ──────────────────>
epoll_wait() kích hoạt báo sự kiện    [CÓ]    [KHÔNG]  [KHÔNG]  [KHÔNG] ...
(Chỉ báo duy nhất 1 lần khi có gói tin mới; tiến trình phải tự đọc cạn)

Hạn chế của Level-Triggered trong kiến trúc đa luồng

Ở chế độ Level-Triggered, epoll_wait() sẽ liên tục phát tín hiệu đánh thức chừng nào bộ đệm socket vẫn còn dữ liệu. Nếu một luồng chỉ đọc dở dang một phần gói mã hóa, các vòng lặp tiếp theo vẫn tiếp tục báo sự kiện. Trong mô hình nhiều luồng cùng lắng nghe, hiện tượng này gây chuyển đổi ngữ cảnh liên miên và xung đột khóa nghiêm trọng.

Tối ưu hóa với chế độ Edge-Triggered (EPOLLET)

Khi bật cờ EPOLLET, epoll chỉ gửi thông báo duy nhất một lần khi socket có sự thay đổi trạng thái (chẳng hạn từ trạng thái rỗng sang có gói tin đến). Điều này giúp cắt giảm hơn 60% các thông báo sự kiện dư thừa từ nhân.

Tuy nhiên, chế độ Edge-Triggered đòi hỏi hai quy tắc bắt buộc:

  1. Bắt buộc dùng socket Non-Blocking: Tất cả các socket được theo dõi phải bật cờ O_NONBLOCK thông qua lệnh fcntl(). Nếu luồng xử lý bị chặn ở một lệnh đọc đồng bộ thông thường, toàn bộ chu trình xử lý sự kiện sẽ bị ngưng trệ.
  2. Vòng lặp đọc cạn dữ liệu đến EAGAIN: Vì epoll sẽ không báo lại cho đến khi có đợt gói tin mới, luồng làm việc phải thực hiện vòng lặp read() hoặc recvmsg() liên tục cho đến khi hàm trả về mã lỗi EAGAIN hoặc EWOULDBLOCK, xác nhận bộ đệm đã được đọc sạch.
// Mô hình đọc cạn dữ liệu chuẩn trong chế độ Edge-Triggered
while (1) {
    ssize_t count = recv(client_fd, buffer, sizeof(buffer), 0);
    if (count == -1) {
        if (errno == EAGAIN || errno == EWOULDBLOCK) {
            // Đã đọc cạn bộ đệm; có thể quay lại epoll_wait an toàn
            break;
        }
        // Xử lý lỗi kết nối bất thường
        close(client_fd);
        break;
    } else if (count == 0) {
        // Khách hàng chủ động ngắt kết nối
        close(client_fd);
        break;
    }
    // Chuyển dữ liệu sang khâu giải mã gói tin VPN
    process_vpn_packet(buffer, count);
}

Kiểm soát an toàn đa luồng với cờ EPOLLONESHOT

Khi xây dựng các gateway VPN hiệu năng cao, kiến trúc hiện đại thường sử dụng một nhóm luồng làm việc (thread pool) cùng chia sẻ một bộ mô tả epoll hoặc cùng xử lý tập socket chung. Mô hình này rất dễ vấp phải hai lỗi kinh điển: hiệu ứng Thundering Herd (đàn gia súc sấm sét) và Xung đột đa luồng (Race Condition).

Nguy cơ xung đột đa luồng khi xử lý gói tin

Giả sử Luồng A và Luồng B cùng gọi epoll_wait() trên một bảng epoll chung. Một loạt gói UDP đổ về Socket 4. Luồng A thức dậy và bắt đầu đọc dữ liệu. Trong lúc Luồng A đang bận giải mã các gói đầu tiên, một gói tin tiếp theo lại bay đến Socket 4. Nếu không có cơ chế bảo vệ, epoll_wait() sẽ đánh thức tiếp Luồng B cho chính Socket 4 đó.

Hậu quả là Luồng A và Luồng B cùng đọc dữ liệu trên Socket 4 song song, dẫn đến việc giải mã bị xáo trộn thứ tự gói, phá vỡ cơ chế cửa sổ chống phát lại (anti-replay window) và làm hỏng trạng thái phiên làm việc.

Giải pháp loại trừ xung đột: EPOLLONESHOT

Để loại bỏ triệt để nguy cơ này mà không cần dùng các khóa mutex phần mềm nặng nề, Linux cung cấp cờ EPOLLONESHOT.

1. epoll_ctl(epfd, EPOLL_CTL_ADD, sock_fd, EPOLLIN | EPOLLET | EPOLLONESHOT)
   - Đăng ký socket kèm cờ bảo vệ oneshot.

2. Gói tin đến -> Luồng A thức dậy qua epoll_wait().
   - Nhân tự động vô hiệu hóa toàn bộ thông báo sau đó trên sock_fd.

3. Gói tin mới tiếp tục đến trong khi Luồng A đang bận xử lý.
   - Luồng B vẫn ngủ yên; sock_fd KHÔNG bao giờ kích hoạt luồng khác.

4. Luồng A xử lý xong và đọc cạn dữ liệu trên socket.
   - Luồng A gọi: epoll_ctl(epfd, EPOLL_CTL_MOD, sock_fd, ... | EPOLLONESHOT)
   - Socket được kích hoạt lại an toàn cho các đợt dữ liệu tiếp theo.

Nhờ có EPOLLONESHOT, nhân hệ điều hành bảo đảm tại một thời điểm nhất định chỉ có đúng một luồng xử lý dữ liệu của một socket cụ thể, triệt tiêu hoàn toàn xung đột đa luồng mà vẫn duy trì khả năng xử lý song song trên nhiều nhân CPU.

Tối ưu hóa kiến trúc đa luồng trong RiceGuard

Trong hệ thống hạ tầng phân tán của VPNRice, động cơ RiceGuard kết hợp hài hòa giữa EPOLLET, EPOLLONESHOT và các cơ chế tăng tốc nhân nhằm đạt khả năng mở rộng không khóa (lock-free) trên các cụm máy chủ mật độ cao.

+-------------------------------------------------------------------+
|                    Máy chủ sản xuất VPNRice                       |
|                                                                   |
|   +-----------------------------------------------------------+   |
|   |         Hơn 100.000 phiên kết nối đồng thời (UDP / TCP)   |   |
|   +-----------------------------------------------------------+   |
|                                 |                                 |
|                                 v                                 |
|   +-----------------------------------------------------------+   |
|   |         Bộ điều phối epoll trung tâm (Cây Đỏ-Đen rbr)     |   |
|   |         Cấu hình chế độ EPOLLET kết hợp EPOLLONESHOT      |   |
|   +-----------------------------------------------------------+   |
|         |                      |                      |           |
|         v                      v                      v           |
|  +-------------+        +-------------+        +-------------+    |
|  | Luồng 0     |        | Luồng 1     |        | Luồng 2     |    |
|  | Gắn Core 0  |        | Gắn Core 1  |        | Gắn Core 2  |    |
|  | Giải mã     |        | Giải mã     |        | Giải mã     |    |
|  | ChaCha20    |        | ChaCha20    |        | ChaCha20    |    |
|  +-------------+        +-------------+        +-------------+    |
|         |                      |                      |           |
|         v Kích hoạt lại        v Kích hoạt lại        v Kích hoạt |
|   epoll_ctl(MOD)         epoll_ctl(MOD)         epoll_ctl(MOD)    |
+-------------------------------------------------------------------+

1. Phân phối phiên làm việc không khóa

RiceGuard phân bổ các dòng dữ liệu khách hàng vào các luồng xử lý gắn chặt với từng nhân CPU (CPU pinning). Bằng cách quản lý các tập socket độc lập hoặc dùng EPOLLONESHOT, các luồng mật mã xử lý giải mã mà không cần tranh chấp khóa quay (spinlocks). Các quá trình đàm phán bắt tay, kiểm tra kết nối và giải mã dữ liệu đều đạt độ trễ điều phối dưới 1 mili-giây.

2. Thu gom gói hàng loạt với recvmmsg

Để giảm thiểu chi phí chuyển đổi ngữ cảnh khi lưu lượng tăng đột biến, RiceGuard kết hợp thông báo sự kiện edge-triggered với lời gọi hệ thống recvmmsg(). Khi epoll_wait() báo sẵn sàng, luồng xử lý có thể nhận tới 64 gói dữ liệu chỉ trong một lần gọi hệ thống duy nhất, chuyển thẳng các mảng dữ liệu này vào các lệnh SIMD véc-tơ hóa (AVX-512 / NEON) để giải mã ChaCha20-Poly1305 tức thì.

3. Phân tách không gian mạng và chống rò rỉ dữ liệu

Mỗi nhóm khách hàng trong hệ thống RiceGuard được cô lập chặt chẽ bên trong các không gian mạng Linux (netns) độc lập. Bộ điều phối epoll kiểm soát việc luân chuyển dữ liệu chính xác trong ranh giới phân quyền, ngăn chặn triệt để nguy cơ dữ liệu thô chưa mã hóa thoát ra các cổng mạng vật lý bên ngoài. Cùng với hệ thống phân giải DNS mã hóa nội bộ, cấu trúc I/O hướng sự kiện này mang lại sự an tâm về quyền riêng tư, khả năng chịu tải và độ ổn định lâu dài cho các dịch vụ mạng doanh nghiệp.