DPTCloud
Quay lại danh sách
Tin tức công nghệ

Tối Ưu Hóa Kernel Linux Chuyên Sâu Cho VPS Chạy Ứng Dụng WebSocket Chịu Tải Hàng Triệu Connection

3 tháng 6, 2026

Giới Thiệu Về Thách Thức Kết Nối WebSocket Quy Mô Lớn

Trong kỷ nguyên của các ứng dụng thời gian thực (Real-time Applications) như ứng dụng chat, bảng điều khiển tài chính, hay trò chơi trực tuyến, WebSocket đã trở thành giao thức cốt lõi nhờ khả năng giao tiếp hai chiều liên tục. Tuy nhiên, không giống như giao thức HTTP truyền thống (vốn ngắt kết nối ngay sau khi hoàn thành phản hồi), WebSocket duy trì một kết nối mở (persistent connection) vô thời hạn giữa client và server.

Khi ứng dụng đạt đến quy mô hàng triệu kết nối đồng thời (Concurrent Connections), rào cản lớn nhất không còn nằm ở tầng ứng dụng (Application Layer) mà dịch chuyển xuống Kernel Linux và hệ thống mạng của hệ điều hành. Một cấu hình mặc định (default) của các bản phân phối Linux như Ubuntu hay CentOS sẽ nhanh chóng bị sập do cạn kiệt tài nguyên mạng, tràn bộ đệm hoặc vượt quá giới hạn file định danh (file descriptors). Bài viết này sẽ hướng dẫn bạn từng bước can thiệp chuyên sâu vào hệ thống để giải phóng toàn bộ sức mạnh của VPS.

1. Nới Rộng Giới Hạn File Descriptors (Tài Nguyên Hệ Thống)

Trong Linux, mọi thứ đều là file (Everything is a file), và mỗi một kết nối mạng (Socket) được hệ điều hành quản lý như một File Descriptor (FD). Theo mặc định, giới hạn này thường rất thấp (khoảng 1024 đến 4096 file), nghĩa là server của bạn không thể chấp nhận nhiều hơn số lượng kết nối đó cho dù phần cứng còn trống rất nhiều.

Tăng giới hạn toàn hệ thống (System-wide Limit)

Để thay đổi cấu hình này, chúng ta cần chỉnh sửa file /etc/sysctl.conf nhằm thiết lập số lượng file tối đa mà toàn bộ kernel có thể mở:

fs.file-max = 2097152

Tăng giới hạn cho từng User và Process

Tiếp theo, bạn cần đảm bảo ứng dụng chạy WebSocket (ví dụ: Node.js, Go, hay Nginx) có quyền sử dụng số lượng FD lớn này bằng cách chỉnh sửa file /etc/security/limits.conf:

  • * soft nofile 1048576
  • * hard nofile 1048576
  • root soft nofile 1048576
  • root hard nofile 1048576
Lưu ý quan trọng: Nếu ứng dụng của bạn được quản lý bởi systemd, giới hạn trong limits.conf có thể bị bỏ qua. Bạn cần thêm dòng LimitNOFILE=1048576 vào phần [Service] trong file cấu hình service của systemd để đảm bảo cấu hình có hiệu lực.

2. Tối Ưu Hóa Subsystem Mạng (TCP/IP Stack) Chuyên Sâu

Để xử lý hàng triệu kết nối, Kernel Linux cần được tái cấu trúc lại cách quản lý hàng đợi kết nối và cơ chế tái sử dụng Socket mạng thông qua các tham số sysctl.

Quản lý hàng đợi kết nối (Connection Backlog)

Khi hàng triệu người dùng kết nối cùng lúc, các hàng đợi kết nối chưa hoàn tất bắt tay ba bước (Three-way Handshake) hoặc đang chờ ứng dụng xử lý sẽ rất dễ bị tràn. Hãy tăng các giá trị này để tránh hiện tượng rớt gói tin (packet drop):

# Tăng số lượng kết nối tối đa đang chờ xử lý trong hàng đợi socket
net.core.somaxconn = 65535

# Tăng số lượng gói tin tối đa trong hàng đợi đầu vào của card mạng
net.core.netdev_max_backlog = 100000

# Tăng số lượng kết nối TCP ở trạng thái SYN_RECV (chưa hoàn tất handshake)
net.ipv4.tcp_max_syn_backlog = 65535

Tối ưu hóa trạng thái TIME_WAIT và Tái sử dụng Port

Khi các kết nối WebSocket bị đóng từ phía server, các socket sẽ rơi vào trạng thái TIME_WAIT trong khoảng 60-120 giây để đảm bảo không có gói tin đi lạc nào bị đọc sai. Ở quy mô lớn, hàng trăm nghìn socket ở trạng thái này sẽ làm cạn kiệt tài nguyên IP/Port. Hãy bật tính năng tái sử dụng nhanh chóng:

# Cho phép tái sử dụng các socket ở trạng thái TIME_WAIT cho kết nối mới
net.ipv4.tcp_tw_reuse = 1

# Tăng dải port cục bộ có thể sử dụng (Local Port Range)
net.ipv4.ip_local_port_range = 1024 65535

# Giảm thời gian giữ kết nối mồ côi (orphaned connections)
net.ipv4.tcp_fin_timeout = 15

3. Quản Lý Bộ Nhớ Đệm TCP (TCP Buffer Tuning) Để Tiết Kiệm RAM

Mỗi kết nối TCP đều yêu cầu một lượng bộ nhớ đệm nhất định cho việc gửi (Send Buffer - wmem) và nhận (Receive Buffer - rmem) dữ liệu. Với cấu hình mặc định, mỗi socket có thể ngốn từ 128KB đến 4MB RAM. Nếu có 1 triệu kết nối, hệ thống sẽ cần từ 128GB đến 4TB RAM — một con số không tưởng đối với hầu hết các VPS thông thường.

Bí quyết ở đây là giảm kích thước bộ đệm tối thiểu xuống mức vừa đủ và cho phép kernel tự động co giãn dựa trên lưu lượng thực tế:

# Cấu hình bộ đệm nhận (rmem): [min, default, max] tính bằng bytes
net.ipv4.tcp_rmem = 4096 8192 16777216

# Cấu hình bộ đệm gửi (wmem): [min, default, max] tính bằng bytes
net.ipv4.tcp_wmem = 4096 8192 16777216

# Tăng không gian bộ đệm cốt lõi của hệ thống
net.core.rmem_max = 16777216

et.core.wmem_max = 16777216

Bằng cách đặt giá trị tối thiểu (min) và mặc định (default) ở mức thấp (4KB và 8KB), một kết nối WebSocket nhàn rỗi (idle connection) chỉ tốn khoảng dưới 16KB RAM. Nhờ đó, bạn hoàn toàn có thể duy trì 1 triệu kết nối chỉ với khoảng 16GB đến 24GB RAM trên VPS.

4. Cơ Chế TCP Keepalive Và Tránh Hiện Tượng "Kết Nối Ma"

Trong môi trường mạng thực tế, nhiều thiết bị di động hoặc máy tính của client có thể bị mất mạng đột ngột (đi vào vùng mất sóng, tắt máy ngang) mà không kịp gửi gói tin đóng kết nối (FIN packet). Server lúc này vẫn nghĩ kết nối đang mở và giữ lại tài nguyên, tạo nên các "Kết nối ma" (Ghost Connections).

Để giải quyết vấn đề này, cần cấu hình TCP Keepalive để kernel chủ động kiểm tra trạng thái của kết nối một cách thường xuyên hơn:

# Bắt đầu gửi gói tin keepalive sau khi kết nối nhàn rỗi 300 giây (5 phút)
net.ipv4.tcp_keepalive_time = 300

# Khoảng cách giữa các gói tin kiểm tra lại nếu không nhận được phản hồi
net.ipv4.tcp_keepalive_intvl = 15

# Số lần thử thất bại tối đa trước khi hủy kết nối
net.ipv4.tcp_keepalive_probes = 5

5. Áp Dụng Cấu Hình Và Giám Sát Hiệu Năng Thực Tế

Sau khi đã thêm tất cả các tham số trên vào file /etc/sysctl.conf, bạn cần chạy lệnh sau với quyền root để các thay đổi có hiệu lực ngay lập tức mà không cần khởi động lại VPS:

sysctl -p

Công cụ kiểm tra và giám sát

Để đảm bảo hệ thống hoạt động đúng như kỳ vọng và không bị nghẽn, các kỹ sư hệ thống cần thường xuyên sử dụng các công cụ sau:

  • ss -s: Xem tổng quan số lượng socket đang ở trạng thái ESTABLISHED, TIME_WAIT, SYN_RECV.
  • htop hoặc top: Giám sát mức độ tiêu thụ CPU và RAM của ứng dụng WebSocket.
  • cat /proc/sys/fs/file-nr: Kiểm tra số lượng file descriptor hiện tại đang được sử dụng thực tế so với giới hạn tối đa.

Kết Luận

Tối ưu hóa Kernel Linux cho ứng dụng WebSocket chịu tải lớn là một nghệ thuật cân bằng giữa khả năng phục vụ kết nối tối đa và mức độ tiêu thụ tài nguyên phần cứng. Bằng việc nới rộng giới hạn File Descriptors, tinh chỉnh các hàng đợi TCP, co giãn bộ đệm thông minh và dọn dẹp các kết nối ma, một chiếc VPS cấu hình tầm trung hoàn toàn có thể gánh vác được lượng traffic khổng lồ lên tới hàng triệu kết nối. Hãy bắt tay vào thử nghiệm, đo lường các chỉ số và liên tục điều chỉnh để tìm ra cấu hình tối ưu nhất cho kiến trúc ứng dụng đặc thù của doanh nghiệp bạn.