Một máy chủ có thể xử lý bao nhiêu Ổ cắm cùng lúc?

Để hiểu có bao nhiêu kết nối mà một tiến trình máy chủ có thể hỗ trợ đồng thời, trước tiên chúng ta cần làm rõ cách thể hiện một kết nối ổ cắm. Một kết nối bao gồm bốn phần: [LocalIP:LocalPort:RemoteIP:RemotePort]. Đối với quy trình máy chủ, LocalIP và LocalPort được cố định, trong khi RemoteIP và RemotePort có thể thay đổi. Hãy nghĩ xem, RemoteIP có thể có bao nhiêu khả năng? Có bao nhiêu khả năng cho RemotePort? Về mặt lý thuyết có thể hỗ trợ bao nhiêu kết nối bằng cách kết hợp cả hai?

Về mặt lý thuyết, các kết hợp có thể là:

• (RemoteIP) 2^32 * (RemotePort) 2^16 = 2^48

Điều này có nghĩa là về mặt lý thuyết, một quy trình máy chủ có thể hỗ trợ 2^48 kết nối. Tuy nhiên, trên thực tế, số lượng kết nối thường bị giới hạn bởi các tài nguyên hệ thống khác.

Có bị giới hạn bởi số lượng cổng không?

Điều đầu tiên cần làm rõ là khi máy chủ lắng nghe một cổng, nó chỉ chiếm một cổng. Việc thiết lập kết nối với máy khách không chiếm cổng của máy chủ. Số lượng cổng được giới hạn cho máy khách và mỗi máy khách sẽ chiếm một cổng cục bộ khi thiết lập kết nối.

Số lượng kết nối máy chủ không bị ảnh hưởng bởi số lượng cổng.

Nó không bị hạn chế về cổng, vậy nó phải chịu những hạn chế gì?

Số lượng kết nối được máy chủ hỗ trợ chủ yếu bị giới hạn bởi bộ mô tả tệp. Mỗi kết nối ổ cắm cần chiếm một bộ mô tả tệp. Trong hệ thống Linux, số lượng bộ mô tả tệp mặc định cho một quy trình người dùng thường là 1024. Nếu số lượng kết nối vượt quá giá trị này, ứng dụng sẽ báo lỗi, nhắc nhở "Không đủ bộ mô tả tệp".

May mắn thay, số lượng bộ mô tả tệp có thể được điều chỉnh và có thể đặt từ 100.000 trở lên tùy theo nhu cầu, có thể đáp ứng đầy đủ nhu cầu của hầu hết các ứng dụng.

Thay đổi nó thành 100w bên dưới.

// /etc/security/limits.conf

* tệp mềm 1000000 * tệp cứng 1000000

// /etc/sysctl.conf

fs.file-max=1000000

  .

Bộ mô tả tập tin là gì? Nó chiếm những nguồn lực nào?

Bộ mô tả tệp là "mã định danh" được hệ điều hành sử dụng để xác định tệp đang mở hoặc kết nối ổ cắm. Nó không chiếm quá nhiều tài nguyên, nó chỉ là một phương pháp quản lý bên trong hệ điều hành.

Vậy socket chiếm những tài nguyên nào trên máy chủ?

1) Trí nhớ.

Mỗi kết nối socket sẽ phân bổ bộ đệm nhận và gửi trong không gian kernel. Giả sử kích thước mặc định của mỗi bộ đệm là 128KB, nếu máy chủ muốn quản lý 100.000 kết nối thì bộ nhớ cần có là:

• 100.000 * 256KB = bộ nhớ 24,41GB

Nếu máy chủ của bạn có bộ nhớ dưới 24GB nhưng vẫn cần hỗ trợ 100.000 kết nối, bạn có thể giảm bộ nhớ cần thiết cho mỗi kết nối bằng cách điều chỉnh cấu hình bộ đệm của hệ thống.

Ví dụ: các tham số kernel sau có thể được sửa đổi để điều chỉnh kích thước bộ đệm TCP:

#Cấu hình mặc định 
# Kernel sẽ tự động điều chỉnh kích thước bộ đệm theo điều kiện mạng thực tế, nổi giữa giá trị tối thiểu và tối đa.
net.ipv4.tcp_rmem = 4096 131072 6291456

• 4096: giá trị tối thiểu
• 131072: Giá trị mặc định
• 6291456: giá trị tối đa

Bạn có thể thay đổi tất cả thành 4096, tức là 4KB. Bằng cách này, 100.000 kết nối chỉ chiếm 781,25 MB.

2) Chủ đề.

Quá trình máy chủ cần sử dụng các luồng để xử lý dữ liệu đã nhận và gửi. Hầu hết các máy chủ hiện đại đều sử dụng mô hình NIO (I/O không chặn), trong đó một luồng công việc có thể quản lý nhiều kết nối ổ cắm. Thông qua các cơ chế như select hoặc epoll, mô hình NIO có thể chọn các kết nối ổ cắm cần xử lý một cách hiệu quả.

Thông thường, số lượng thread công nhân là cố định và không cần quá nhiều. Khoảng 20 là đủ. Các luồng công việc này chịu trách nhiệm xử lý các gói dữ liệu đã nhận và sau đó chuyển các gói dữ liệu hoàn chỉnh đến nhóm luồng của lớp ứng dụng, chịu trách nhiệm thực thi logic nghiệp vụ thực tế.

Số lượng kết nối ≠ Đồng thời: Một máy chủ có thể xử lý bao nhiêu giao tiếp socket?

Trong các ứng dụng thực tế, số lượng kết nối không bằng số lượng đồng thời. Đồng thời đề cập đến số lượng kết nối đang trao đổi dữ liệu cùng một lúc và số lượng kết nối đề cập đến tổng số kết nối.

Một quy trình máy chủ có thể quản lý một số lượng lớn kết nối ổ cắm, nhưng nếu tần số liên lạc của mỗi kết nối thấp (ví dụ: báo cáo dữ liệu thường xuyên của thiết bị IoT, gửi hướng dẫn không thường xuyên, v.v.), thì ngay cả khi số lượng kết nối thấp cao thì hệ thống có thể dễ dàng đối phó với nó.

Ví dụ: trong nền tảng Internet of Things, các thiết bị thường xuyên báo cáo dữ liệu và đôi khi gửi báo cáo ngoại lệ hoặc nhận hướng dẫn. Trong kịch bản ứng dụng này, số lượng kết nối và khối lượng liên lạc mà máy chủ có thể quản lý thường không gây nhiều áp lực.

Tuy nhiên, nếu máy khách và máy chủ của ứng dụng giao tiếp thường xuyên và có yêu cầu thời gian thực cao (ví dụ: truyền dữ liệu thời gian thực, xử lý độ trễ thấp, v.v.) thì cần phải xem xét nhiều yếu tố hơn. Tại thời điểm này, liệu mô hình NIO có gây ra sự chậm trễ không? Một nút dịch vụ có thể hỗ trợ các kết nối thường xuyên như vậy không? Bạn có cần phân tán tải và sử dụng nhiều nút dịch vụ để cải thiện khả năng tương tranh không?

Lạc đề: Tại sao có sự chậm trễ trong NIO?

Đặc điểm thiết kế của NIO là một luồng Worker chịu trách nhiệm quản lý việc giao tiếp của nhiều kết nối Ổ cắm. Giả sử rằng một luồng Worker xử lý 10 kết nối Ổ cắm cùng lúc. Khi 10 Ổ cắm này nhận các gói dữ liệu cùng lúc, thứ tự xử lý sẽ phụ thuộc vào thứ tự đến của chúng. Trong trường hợp này, Socket cuối cùng nhận gói tin phải đợi 9 gói tin trước đó được phân tích và phân phối nên sẽ có độ trễ nhất định.

Tuy nhiên, trong hầu hết các tình huống kinh doanh thực tế, việc nhiều Ổ cắm nhận dữ liệu cùng một lúc là điều không bình thường. Và ngay cả khi có độ trễ thì nó thường không có tác động đáng kể đến hoạt động kinh doanh và mức độ trễ thường nằm trong giới hạn có thể chấp nhận được.

Tóm tắt

Số lượng ổ cắm mà quy trình máy chủ có thể kết nối cùng lúc không chỉ phụ thuộc vào số lượng cổng mà còn phụ thuộc vào các tài nguyên như bộ mô tả tệp, bộ nhớ và luồng. Bằng cách điều chỉnh cấu hình hệ thống và tối ưu hóa kiến trúc, máy chủ có thể quản lý hiệu quả số lượng lớn kết nối. Tuy nhiên, trong các tình huống giao tiếp tần số cao, có thể cần xem xét thêm để tối ưu hóa kiến trúc, chẳng hạn như sử dụng NIO để xử lý độ trễ hoặc phân phối tải thông qua kiến trúc phân tán để đảm bảo rằng hệ thống có thể mang các kết nối đồng thời cao.

Cuối cùng, bài viết này nói về [Thảo luận linh tinh] Máy chủ có thể xử lý bao nhiêu kết nối Socket cùng một lúc? Bài viết về phân tích tài nguyên và những hạn chế đằng sau nó kết thúc ở đây Nếu bạn muốn biết thêm về [Thảo luận linh tinh] Máy chủ có thể xử lý bao nhiêu kết nối Ổ cắm cùng một lúc? Để biết nội dung đằng sau phân tích tài nguyên và hạn chế, vui lòng tìm kiếm các bài viết của CFSDN hoặc tiếp tục duyệt các bài viết liên quan. Tôi hy vọng bạn sẽ ủng hộ blog của tôi trong tương lai! .