Máy chủ web có thể xử lý bao nhiêu kết nối socket?

Giả sử nếu tôi được chia sẻ, lưu trữ ảo hoặc chuyên dụng, tôi đọc ở đâu đó một máy chủ / máy chỉ có thể xử lý 64.000 kết nối TCP cùng một lúc, điều này có đúng không? Có bao nhiêu loại lưu trữ có thể xử lý bất kể băng thông? Tôi giả sử HTTP hoạt động trên TCP.

Điều này có nghĩa là chỉ có 64.000 người dùng có thể kết nối với trang web và nếu tôi muốn phục vụ nhiều hơn, tôi sẽ phải chuyển đến một trang trại web?

Tóm lại: Bạn sẽ có thể đạt được theo thứ tự hàng triệu kết nối TCP đang hoạt động đồng thời và bằng (các) yêu cầu HTTP mở rộng. Điều này cho bạn biết hiệu suất tối đa mà bạn có thể mong đợi với nền tảng phù hợp với cấu hình phù hợp.

Hôm nay, tôi đã lo lắng liệu IIS với ASP.NET có hỗ trợ theo thứ tự 100 kết nối đồng thời hay không (xem bản cập nhật của tôi, mong đợi ~ 10k phản hồi mỗi giây trên các phiên bản ASP.Net Mono cũ hơn). Khi tôi nhìn thấy câu hỏi / câu trả lời này, tôi không thể cưỡng lại việc trả lời chính mình, nhiều câu trả lời cho câu hỏi ở đây là hoàn toàn không chính xác.

Trường hợp tốt nhất

Câu trả lời cho câu hỏi này chỉ liên quan đến cấu hình máy chủ đơn giản nhất để tách khỏi vô số biến và cấu hình có thể có ở hạ lưu.

Vì vậy, hãy xem xét kịch bản sau cho câu trả lời của tôi:

1. Không có lưu lượng truy cập trên các phiên TCP, ngoại trừ các gói còn tồn tại (nếu không, bạn rõ ràng sẽ cần một lượng băng thông mạng tương ứng và các tài nguyên máy tính khác)
2. Phần mềm được thiết kế để sử dụng lập trình và ổ cắm không đồng bộ, thay vì luồng phần cứng cho mỗi yêu cầu từ nhóm. (tức là máy chủ web IIS, Node.js, Nginx ... [nhưng không phải Apache] với phần mềm ứng dụng được thiết kế không đồng bộ)
3. Hiệu suất tốt / CPU / Ram đô la. Ngày nay, tùy ý, giả sử i7 (4 lõi) với 8GB RAM.
4. Tường lửa / bộ định tuyến tốt để phù hợp.
5. Không có giới hạn ảo / thống đốc - tức là. Linux somaxconn, IIS web.config ...
6. Không phụ thuộc vào phần cứng khác chậm hơn - không đọc từ đĩa cứng, bởi vì nó sẽ là mẫu số chung thấp nhất và tắc nghẽn cổ chai, không phải IO mạng.

Câu trả lời chi tiết

Thiết kế ràng buộc luồng đồng bộ có xu hướng hoạt động kém nhất so với triển khai IO không đồng bộ.

WhatsApp nhận được một triệu với lưu lượng truy cập trên một máy hệ điều hành có hương vị Unix - https://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2011/ .

Và cuối cùng, trang này, http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html , đi sâu vào rất nhiều chi tiết , khám phá cách có thể đạt được thậm chí 10 triệu. Máy chủ thường có động cơ giảm tải TCP phần cứng, ASIC được thiết kế cho vai trò cụ thể này hiệu quả hơn so với CPU cho mục đích chung.

Lựa chọn thiết kế phần mềm tốt

Thiết kế IO không đồng bộ sẽ khác nhau giữa các nền tảng Hệ điều hành và Lập trình. Node.js được thiết kế với tâm trí không đồng bộ . Bạn nên sử dụng Promises ít nhất và khi ECMAScript 7 xuất hiện, async/ await. C # /. Net đã có đầy đủ hỗ trợ không đồng bộ như node.js. Bất kể hệ điều hành và nền tảng nào, tính năng không đồng bộ sẽ hoạt động rất tốt. Và bất kể ngôn ngữ nào bạn chọn, hãy tìm từ khóa "không đồng bộ", hầu hết các ngôn ngữ hiện đại sẽ có một số hỗ trợ, ngay cả khi đó là một tiện ích bổ sung của một số loại.

Tới WebFarm?

Dù giới hạn đối với tình huống cụ thể của bạn là gì, thì trang trại web là một giải pháp tốt để mở rộng quy mô. Có rất nhiều kiến ​​trúc để đạt được điều này. Một là sử dụng bộ cân bằng tải (các nhà cung cấp dịch vụ lưu trữ có thể cung cấp những thứ này, nhưng ngay cả những thứ này cũng có giới hạn, cùng với mức trần băng thông), nhưng tôi không thích tùy chọn này. Đối với Ứng dụng Trang đơn có kết nối lâu dài, thay vào đó, tôi muốn có một danh sách mở các máy chủ mà ứng dụng khách sẽ chọn ngẫu nhiên khi khởi động và sử dụng lại trong suốt thời gian tồn tại của ứng dụng. Điều này loại bỏ điểm lỗi duy nhất (bộ cân bằng tải) và cho phép mở rộng quy mô qua nhiều trung tâm dữ liệu và do đó băng thông rộng hơn nhiều.

Bạo hành một huyền thoại - 64K cổng

Để giải quyết thành phần câu hỏi liên quan đến "64.000", đây là một quan niệm sai lầm. Một máy chủ có thể kết nối với hơn 65535 máy khách. Xem /networkengineering/48283/is-a-tcp-server-limited-to-65535-clients/48284

Nhân tiện, Http.sys trên Windows cho phép nhiều ứng dụng chia sẻ cùng một cổng máy chủ trong lược đồ URL HTTP. Mỗi chúng đăng ký một ràng buộc miền riêng biệt, nhưng cuối cùng vẫn có một ứng dụng máy chủ duy nhất ủy quyền các yêu cầu đến các ứng dụng chính xác.

Cập nhật 2019-05-30

Dưới đây là so sánh cập nhật các thư viện HTTP nhanh nhất - https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=plaintext

• Ngày kiểm tra: 2018-06-06
• Phần cứng được sử dụng: Dell R440 Xeon Gold + 10 GbE
• Người dẫn đầu có ~ 7 triệu phản hồi văn bản rõ ràng mỗi giây (phản hồi không phải kết nối)
• Fasthttp thứ hai dành cho golang quảng cáo 1,5 triệu kết nối đồng thời - xem https://github.com/valyala/fasthttp
• Các ngôn ngữ hàng đầu là Rust, Go, C ++, Java, C và thậm chí C # xếp hạng 11 (6,9 triệu mỗi giây). Scala và Clojure xếp hạng tiếp tục xuống. Python đứng ở vị trí thứ 29 với tốc độ 2,7M mỗi giây.
• Ở cuối danh sách, tôi lưu ý laravel và cakephp, rails, aspnet-mono-ngx, symfony, zend. Tất cả đều dưới 10k mỗi giây. Lưu ý, hầu hết các khuôn khổ này được xây dựng cho các trang động và khá cũ, có thể có các biến thể mới hơn có tính năng cao hơn trong danh sách.
• Hãy nhớ rằng đây là bản rõ HTTP, không phải dành cho chuyên ngành Websocket: nhiều người đến đây có thể sẽ quan tâm đến các kết nối đồng thời cho websocket.

Câu hỏi này là một câu hỏi khá khó. Không có giới hạn phần mềm thực sự nào về số lượng kết nối đang hoạt động mà một máy có thể có, mặc dù một số hệ điều hành bị hạn chế hơn những hệ điều hành khác. Vấn đề trở thành một trong những nguồn lực. Ví dụ: giả sử một máy duy nhất muốn hỗ trợ 64.000 kết nối đồng thời. Nếu máy chủ sử dụng 1MB RAM cho mỗi kết nối, nó sẽ cần 64GB RAM. Nếu mỗi máy khách cần đọc một tệp, tải trọng truy cập mảng lưu trữ hoặc đĩa sẽ lớn hơn nhiều so với những thiết bị đó có thể xử lý. Nếu một máy chủ cần phân nhánh một quy trình cho mỗi kết nối thì hệ điều hành sẽ dành phần lớn thời gian để chuyển đổi ngữ cảnh hoặc bỏ đói các quy trình cho thời gian của CPU.

Các vấn đề C10K trang có một cuộc thảo luận rất tốt về vấn đề này.

Để thêm hai xu của tôi vào cuộc trò chuyện, một quá trình có thể mở đồng thời một số ổ cắm được kết nối bằng số này (trong hệ điều hành loại Linux) / proc / sys / net / core / somaxconn

cat / proc / sys / net / core / somaxconn

Con số này có thể được sửa đổi nhanh chóng (tất nhiên chỉ bởi người dùng root)

echo 1024> / proc / sys / net / core / somaxconn

Nhưng hoàn toàn phụ thuộc vào quy trình của máy chủ, phần cứng của máy và mạng, số lượng ổ cắm thực có thể kết nối trước khi hệ thống gặp sự cố

Có vẻ như câu trả lời là ít nhất 12 triệu nếu bạn có một máy chủ mạnh mẽ, phần mềm máy chủ của bạn được tối ưu hóa cho nó, bạn có đủ khách hàng. Nếu bạn kiểm tra từ một máy khách đến một máy chủ, số cổng trên máy khách sẽ là một trong những giới hạn tài nguyên rõ ràng (Mỗi kết nối TCP được xác định bởi sự kết hợp duy nhất của IP và số cổng tại nguồn và đích).

(Bạn cần chạy nhiều ứng dụng khách, nếu không, trước tiên bạn đạt đến giới hạn 64K đối với số cổng)

Khi nói về nó, đây là một ví dụ kinh điển của chủ nghĩa dí dỏm rằng "sự khác biệt giữa lý thuyết và thực hành lớn hơn nhiều so với thực tế so với lý thuyết" - trong thực tế đạt được những con số cao hơn dường như là một chu kỳ của a. đề xuất các thay đổi cấu hình / kiến ​​trúc / mã cụ thể, b. kiểm tra nó cho đến khi bạn đạt đến một giới hạn, c. Tôi đã hoàn thành chưa? Nếu không thì d. tìm ra yếu tố giới hạn là gì, e. quay lại bước a (rửa sạch và lặp lại).

Đây là một ví dụ với 2 triệu kết nối TCP trên một hộp mạnh mẽ (RAM 128GB và 40 lõi) chạy Phoenix http://www.phoenixframework.org/blog/the-road-to-2-million-websocket-connections - chúng đã kết thúc cần 50 máy chủ quan trọng hoặc tương đối hợp lý chỉ để cung cấp tải cho máy khách (các máy khách nhỏ hơn ban đầu của họ đã đạt tối đa sớm, ví dụ: "đã tối đa 4core / hộp 15gb của chúng tôi @ 450k máy khách").

Đây là một tài liệu tham khảo khác cho lượt đi lần này với giá 10 triệu: http://goroutines.com/10m .

Điều này dường như dựa trên java và 12 triệu kết nối: https://mrotaru.wordpress.com/2013/06/20/12-million-concurrent-connections-with-migratorydata-websocket-server/

Lưu ý rằng HTTP thường không giữ cho các kết nối TCP mở lâu hơn thời gian cần thiết để truyền trang đến máy khách; và người dùng thường mất nhiều thời gian hơn để đọc một trang web so với thời gian tải trang xuống ... trong khi người dùng đang xem trang, anh ta không thêm tải vào máy chủ chút nào.

Vì vậy, số lượng người có thể đồng thời xem trang web của bạn lớn hơn nhiều so với số lượng kết nối TCP mà nó có thể đồng thời phục vụ.

trong trường hợp của giao thức IPv4, máy chủ có một địa chỉ IP chỉ lắng nghe trên một cổng có thể xử lý 2 ^ 32 địa chỉ IP x 2 ^ 16 cổng nên 2 ^ 48 ổ cắm duy nhất. Nếu bạn nói về máy chủ như một máy vật lý và bạn có thể sử dụng tất cả 2 ^ 16 cổng, thì có thể có tối đa 2 ^ 48 x 2 ^ 16 = 2 ^ 64 ổ cắm TCP / IP duy nhất cho một địa chỉ IP. Xin lưu ý rằng một số cổng được dành riêng cho hệ điều hành, vì vậy con số này sẽ thấp hơn. Tóm lại:

1 IP và 1 cổng -> 2 ^ 48 ổ cắm

1 IP và tất cả các cổng -> 2 ^ 64 ổ cắm

tất cả các ổ cắm IPv4 duy nhất trong vũ trụ -> 2 ^ 96 ổ cắm

Có hai cuộc thảo luận khác nhau ở đây: Một là có bao nhiêu người có thể kết nối với máy chủ của bạn. Điều này đã được trả lời đầy đủ bởi những người khác, vì vậy tôi sẽ không đi sâu vào vấn đề đó.

Khác là máy chủ của bạn có thể nghe bao nhiêu cổng? Tôi tin rằng đây là nguồn gốc của con số 64K. Trên thực tế, giao thức TCP sử dụng số nhận dạng 16 bit cho một cổng, giá trị này có nghĩa là 65536 (hơn 64K một chút). Điều này có nghĩa là bạn có thể có nhiều "người nghe" khác nhau trên máy chủ trên mỗi Địa chỉ IP.

Tôi nghĩ rằng số lượng kết nối socket đồng thời mà một máy chủ web có thể xử lý phần lớn phụ thuộc vào lượng tài nguyên mà mỗi kết nối sử dụng và tổng tài nguyên có sẵn trên máy chủ ngăn chặn bất kỳ cấu hình giới hạn tài nguyên máy chủ web nào khác.

Để minh họa, nếu mỗi kết nối socket tiêu thụ 1MB tài nguyên máy chủ và máy chủ có sẵn 16GB RAM (về mặt lý thuyết) thì điều này có nghĩa là nó sẽ chỉ có thể xử lý (16GB / 1MB) các kết nối đồng thời. Tôi nghĩ nó đơn giản như vậy ... THỰC SỰ!

Vì vậy, bất kể máy chủ web xử lý kết nối như thế nào, mọi kết nối cuối cùng sẽ tiêu tốn một số tài nguyên.