Chống DDoS tại máy chủ và lọc phía nhà mạng khác gì?
Firewall tại host xử lý lưu lượng sau khi nó đã đi tới máy chủ. Lọc ở phía mạng trước đó có thể bảo vệ đoạn đường vào, tùy kiến trúc và dịch vụ được cung cấp.
Đọc hướng dẫnKIẾN THỨC PROXYANTI
Hướng dẫn bảo vệ máy chủ game.
308 bài về chống DDoS, proxy TCP/UDP, giám sát và vận hành. Mỗi bài giải quyết một tình huống cụ thể.
Danh sách bài viết · Trang 2/13
Đặt mục tiêu bảo vệ theo trải nghiệm người chơi
Số gói bị chặn dễ nhìn thấy nhưng chưa thể hiện người dùng có chơi được hay không. Mục tiêu vận hành nên bắt đầu từ thao tác có giá trị với người chơi.
Đọc hướng dẫnLập bảng tài sản cần bảo vệ cho server private
Một hệ thống game thường phụ thuộc nhiều thứ ngoài tiến trình game: DNS, máy chủ cập nhật, cơ sở dữ liệu và tài khoản quản trị. Bỏ sót một phụ thuộc có thể làm cả dịch vụ ngừng…
Đọc hướng dẫnĐọc báo cáo thử tải chống DDoS trước khi tin kết quả
Một báo cáo chỉ có lưu lượng phát đi không cho biết lưu lượng đến đích hay người chơi có bị ảnh hưởng. Kết quả có giá trị cần mô tả điều kiện và phép đo ở cả hệ thống nhận.
Đọc hướng dẫnKiểm tra listener TCP trước khi sửa bộ lọc
Một port được mở ở firewall vẫn không trả lời nếu tiến trình chưa lắng nghe đúng địa chỉ. Bước này giúp tránh thay đổi bộ lọc khi lỗi nằm ở dịch vụ.
Đọc hướng dẫnTheo dõi SYN-RECV mà không nhầm với người chơi online
SYN-RECV thuộc giai đoạn thiết lập TCP, không phải số người chơi đã đăng nhập. Một thời điểm có nhiều socket trạng thái này cần được đối chiếu với tốc độ bắt tay.
Đọc hướng dẫnCLOSE-WAIT tăng: kiểm tra ứng dụng đóng socket
CLOSE-WAIT thường cho biết phía bên kia đã đóng nhưng ứng dụng cục bộ chưa hoàn tất đóng socket. Giới hạn gói mới không sửa được vòng đời socket bị bỏ quên.
Đọc hướng dẫnTIME-WAIT nhiều có nhất thiết là lỗi DDoS?
Nhiều phiên ngắn có thể làm TIME-WAIT tăng trong hoạt động bình thường. Cần xác định ai mở kết nối, tần suất và có lỗi cạn tài nguyên thật hay không.
Đọc hướng dẫnPhân biệt connection refused và connection timeout
Refused thường xuất hiện khi có phản hồi từ chối kết nối, còn timeout nghĩa là không hoàn tất trong thời gian chờ. Thông báo cần được kiểm tra tại đúng chặng.
Đọc hướng dẫnChọn connect timeout cho đường proxy đến máy gốc
Thời gian chờ kết nối quá dài giữ tài nguyên khi backend hỏng; quá ngắn gây lỗi trên đường truyền dao động. Giá trị nên dựa vào thời gian bắt tay thực tế.
Đọc hướng dẫnIdle timeout làm người chơi treo máy bị ngắt ra sao?
Một phiên có thể vẫn hợp lệ dù không phát sinh dữ liệu trong thời gian dài. Proxy xóa phiên nhàn rỗi sớm hơn heartbeat sẽ tạo lỗi ngắt kết nối khó tái hiện.
Đọc hướng dẫnTCP keepalive và heartbeat ứng dụng khác gì?
Keepalive của TCP giúp phát hiện một số kết nối không còn đáp ứng, nhưng không chứng minh logic game xử lý được yêu cầu. Heartbeat ứng dụng có thể kiểm tra sâu hơn.
Đọc hướng dẫnĐọc retransmission để tìm chặng TCP có vấn đề
Truyền lại tăng có thể liên quan mất gói hoặc đường truyền không ổn định. Vì proxy tạo hai chặng kết nối, chỉ đo một phía có thể bỏ sót nguyên nhân.
Đọc hướng dẫnMTU khiến TCP mở được nhưng dữ liệu lớn bị treo
Bắt tay nhỏ có thể thành công trong khi gói dữ liệu lớn gặp vấn đề trên đường đi có MTU thấp hơn. Triệu chứng thường rõ khi qua tunnel hoặc thay tuyến.
Đọc hướng dẫnSYN cookies: kiểm tra tính năng trước khi tinh chỉnh
SYN cookies là một cơ chế hỗ trợ xử lý áp lực ở giai đoạn thiết lập TCP. Nó không thay thế việc ứng dụng nhận và xử lý những kết nối đã hoàn tất.
Đọc hướng dẫnChuẩn bị triển khai SYNPROXY trên Linux
SYNPROXY can thiệp vào giai đoạn bắt tay nên cần phù hợp kernel, đường gói và đặc tính listener. Cấu hình thiếu một phần có thể làm kết nối hợp lệ thất bại.
Đọc hướng dẫnMSS và window scale trong kiểm thử SYNPROXY
Một bắt tay được proxy trả lời cần tương thích với đường mạng và backend. Giá trị lấy từ bài hướng dẫn khác có thể không phù hợp listener đang chạy.
Đọc hướng dẫnTăng backlog có giải quyết được mọi lỗi đăng nhập không?
Backlog là hàng chờ, không phải năng lực xử lý. Tăng hàng chờ có thể hấp thụ đột biến ngắn nhưng cũng kéo dài thời gian chờ khi ứng dụng không theo kịp.
Đọc hướng dẫnGiới hạn TCP theo nguồn mà vẫn giữ người chơi đang online
Trong sự cố mở kết nối dồn dập, luật không phân biệt phiên mới và phiên đã được chấp nhận có thể ngắt người chơi đang hoạt động. Phạm vi luật cần được kiểm tra rõ.
Đọc hướng dẫnXử lý làn sóng reconnect sau khi khởi động lại game
Sau bảo trì, nhiều client có thể kết nối lại cùng thời điểm và tạo tải giống đột biến bất thường. Vấn đề nằm ở sự đồng bộ, dù người dùng đều hợp lệ.
Đọc hướng dẫnKiểm tra cạn port tạm ở proxy TCP
Proxy mở kết nối ra backend cần tài nguyên cho từng kết nối. Với nhiều phiên ngắn hoặc tập trung một đích, lỗi cấp kết nối ra có thể xuất hiện trước khi CPU đầy.
Đọc hướng dẫnHalf-close ảnh hưởng chuyển tiếp TCP như thế nào?
Một phía có thể kết thúc chiều gửi trong khi vẫn chờ dữ liệu chiều nhận. Relay đóng cả hai chiều ngay khi gặp EOF có thể cắt mất phản hồi cuối.
Đọc hướng dẫnNhận diện reset TCP do backend hay do proxy
Thông báo connection reset không tự chỉ ra thành phần gây lỗi. Cần ghép sự kiện từ hai chặng và log tiến trình để tìm nơi đóng bất thường.
Đọc hướng dẫnĐặt giới hạn file descriptor cho relay TCP
Mỗi phiên relay thường sử dụng nhiều hơn một socket và còn cần file log, pipe cùng tài nguyên khác. Đếm người chơi bằng giới hạn descriptor sẽ đánh giá sai khả năng phục vụ.
Đọc hướng dẫn