웹 서버는 몇 개의 소켓 연결을 처리 할 수 ​​있습니까?

공유, 가상 또는 전용 호스팅을 얻으려면 서버 / 머신이 한 번에 64,000 개의 TCP 연결 만 처리 할 수있는 곳을 읽었습니다. 이것이 사실입니까? 대역폭에 관계없이 어떤 유형의 호스팅이 처리 할 수 ​​있습니까? HTTP가 TCP를 통해 작동한다고 가정합니다.

64,000 명의 사용자 만 웹 사이트에 연결할 수 있으며 더 많은 서비스를 제공하려면 웹 팜으로 이동해야합니까?

간단히 말해서 , 수백만 개의 동시 활성 TCP 연결과 확장 HTTP 요청 을 달성 할 수 있어야합니다 . 이를 통해 올바른 구성의 올바른 플랫폼에서 기대할 수있는 최대 성능을 알 수 있습니다.

오늘 저는 ASP.NET을 사용하는 IIS가 100 개의 동시 연결을 지원할지 여부가 걱정되었습니다 (내 업데이트를 살펴보면 이전 ASP.Net Mono 버전에서 초당 ~ 10k 응답이 예상 됨). 이 질문 / 답변을 보았을 때 스스로 대답하는 것을 거부 할 수 없었습니다. 여기에있는 질문에 대한 많은 답변은 완전히 틀 렸습니다.

최고의 사례

이 질문에 대한 대답은 다운 스트림에서 가능한 수많은 변수 및 구성에서 분리하기위한 가장 간단한 서버 구성에만 관련되어야합니다.

내 대답에 대해 다음 시나리오를 고려하십시오.

1. 연결 유지 패킷을 제외하고 TCP 세션에 트래픽이 없습니다 (그렇지 않으면 당연히 해당하는 양의 네트워크 대역폭 및 기타 컴퓨터 리소스가 필요합니다).
2. 풀의 요청 당 하드웨어 스레드가 아닌 비동기 소켓 및 프로그래밍을 사용하도록 설계된 소프트웨어입니다. (예 : IIS, Node.js, Nginx ... 비동기로 설계된 응용 프로그램 소프트웨어를 사용하는 웹 서버 [Apache 아님])
3. 좋은 성능 / 달러 CPU / 램. 오늘, 임의로 8GB RAM이 장착 된 i7 (4 코어)을 가정 해 보겠습니다.
4. 일치하는 좋은 방화벽 / 라우터.
5. 가상 제한 / 관리자 없음-즉. 리눅스 somaxconn, IIS web.config ...
6. 다른 느린 하드웨어에 대한 의존성 없음-네트워크 IO가 아닌 가장 낮은 공통 분모 및 병목 현상이 발생하기 때문에 하드 디스크에서 읽지 않습니다.

자세한 답변

동기식 스레드 바운드 설계는 비동기 IO 구현에 비해 성능이 가장 떨어지는 경향이 있습니다.

- 하나의 유닉스에 트래픽 만 얻을 WHATSAPP OS 시스템 맛 https://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2011/을 .

그리고 마지막으로, http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html 은 많은 세부 사항에 대해 설명합니다. , 1 천만 개까지 달성 할 수있는 방법을 탐구합니다. 서버에는 종종 범용 CPU보다 더 효율적으로이 특정 역할을 위해 설계된 ASIC 인 하드웨어 TCP 오프로드 엔진이 있습니다.

좋은 소프트웨어 디자인 선택

비동기 IO 디자인은 운영 체제와 프로그래밍 플랫폼에 따라 다릅니다. Node.js는 비동기 를 염두에두고 설계되었습니다 . 최소한 Promises를 사용해야하며 ECMAScript 7이 나오면 async/ await. C # /. Net에는 이미 node.js와 같은 완전한 비동기 지원이 있습니다. OS와 플랫폼이 무엇이든 비동기식은 매우 잘 수행되어야합니다. 어떤 언어를 선택하든 "비동기"라는 키워드를 찾으십시오. 대부분의 최신 언어는 일종의 추가 기능이더라도 약간의 지원을받습니다.

WebFarm에?

특정 상황에 대한 제한이 무엇이든 웹 팜은 확장에 대한 하나의 좋은 솔루션입니다. 이를 달성하기위한 많은 아키텍처가 있습니다. 하나는로드 밸런서를 사용하는 것입니다 (호스팅 제공 업체가이를 제공 할 수 있지만 대역폭 제한과 함께 제한이 있음).이 옵션을 선호하지 않습니다. 장기 실행 연결이있는 단일 페이지 응용 프로그램의 경우 클라이언트 응용 프로그램이 시작할 때 무작위로 선택하고 응용 프로그램의 수명 동안 재사용 할 서버 목록을 공개하는 것을 선호합니다. 이를 통해 단일 장애 지점 (로드 밸런서)을 제거하고 여러 데이터 센터를 통해 확장 할 수 있으므로 훨씬 더 많은 대역폭을 사용할 수 있습니다.

신화 파열-64K 포트

"64,000"에 관한 질문 구성 요소를 다루기 위해 이것은 오해입니다. 서버는 65535 개 이상의 클라이언트에 연결할 수 있습니다. 참조 /networkengineering/48283/is-a-tcp-server-limited-to-65535-clients/48284를

그런데 Windows의 Http.sys는 여러 응용 프로그램이 HTTP URL 스키마에서 동일한 서버 포트를 공유하도록 허용합니다. 각각 별도의 도메인 바인딩을 등록하지만 궁극적으로 올바른 애플리케이션에 대한 요청을 프록시하는 단일 서버 애플리케이션이 있습니다.

업데이트 2019-05-30

다음은 가장 빠른 HTTP 라이브러리의 최신 비교입니다-https: //www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=plaintext

• 테스트 날짜 : 2018-06-06
• 사용 된 하드웨어 : Dell R440 Xeon Gold + 10GbE
• 리더는 초당 ~ 7M 일반 텍스트 응답을 가지고 있습니다 (연결이 아닌 응답).
• golang 용 두 번째 Fasthttp는 150 만 동시 연결을 알립니다. https://github.com/valyala/fasthttp 참조
• 주요 언어는 Rust, Go, C ++, Java, C이며 심지어 C # 순위는 11 (초당 6.9M)입니다. Scala와 Clojure는 순위가 더 낮습니다. Python은 초당 2.7M로 29 위입니다.
• 목록 맨 아래에 laravel 및 cakephp, rails, aspnet-mono-ngx, symfony, zend가 있습니다. 모두 초당 10k 미만. 이러한 프레임 워크의 대부분은 동적 페이지 용으로 빌드되었으며 꽤 오래되었습니다. 목록에서 상위에있는 새로운 변형이있을 수 있습니다.
• 이것은 Websocket 전문 분야가 아니라 HTTP 일반 텍스트임을 기억하십시오. 여기에 오는 많은 사람들은 websocket의 동시 연결에 관심이있을 것입니다.

이 질문은 상당히 어려운 질문입니다. 컴퓨터가 가질 수있는 활성 연결 수에 대한 실제 소프트웨어 제한은 없지만 일부 OS는 다른 OS보다 더 제한적입니다. 문제는 자원 중 하나가됩니다. 예를 들어 단일 컴퓨터가 64,000 개의 동시 연결을 지원하려고한다고 가정 해 보겠습니다. 서버가 연결 당 1MB의 RAM을 사용하는 경우 64GB의 RAM이 필요합니다. 각 클라이언트가 파일을 읽어야하는 경우 디스크 또는 스토리지 어레이 액세스로드는 해당 장치가 처리 할 수있는 것보다 훨씬 커집니다. 서버가 연결 당 하나의 프로세스를 포크해야하는 경우 OS는 대부분의 시간을 컨텍스트 전환에 소비하거나 CPU 시간 동안 프로세스를 고갈시킵니다.

C10K 문제의 페이지는이 문제의 아주 좋은 토론이있다.

대화에 2 센트를 더하기 위해 프로세스는이 숫자와 동일한 수의 소켓을 동시에 열 수 있습니다 (Linux 유형 시스템에서) / proc / sys / net / core / somaxconn

고양이 / proc / sys / net / core / somaxconn

이 번호는 즉석에서 수정할 수 있습니다 (물론 루트 사용자 만).

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

그러나 전적으로 서버 프로세스, 시스템의 하드웨어 및 네트워크, 시스템 충돌 전에 연결할 수있는 실제 소켓 수에 따라 다릅니다.

서버가 튼튼하고 서버 소프트웨어가 최적화되어 있고 클라이언트가 충분하다면 답은 최소 1,200 만 개입니다. 한 클라이언트에서 한 서버로 테스트하는 경우 클라이언트의 포트 번호 수는 분명한 리소스 제한 중 하나가됩니다 (각 TCP 연결은 소스와 대상에서 IP와 포트 번호의 고유 한 조합으로 정의 됨).

(그렇지 않으면 먼저 포트 번호에 대한 64K 제한에 도달하므로 여러 클라이언트를 실행해야합니다.)

결론적으로, 이것은 "이론과 실제의 차이가 이론보다 실제로 훨씬 크다"는 재치주의의 고전적인 예입니다. 실제로 더 높은 숫자를 달성하는 것은 a의 순환처럼 보입니다. 특정 구성 / 아키텍처 / 코드 변경 제안, b. 한계에 도달 할 때까지 테스트하십시오. c. 끝났습니까? 그렇지 않다면 d. 제한 요인이 무엇인지 알아 내십시오. e. a 단계로 돌아가십시오 (헹구고 반복하십시오).

여기에 피닉스 실행하는 우둔한 상자 위에 200 만 개 TCP 연결 (1백28기가바이트 RAM 및 40 개 코어)와 예입니다 http://www.phoenixframework.org/blog/the-road-to-2-million-websocket-connections은 - 그들이 종료 클라이언트로드를 제공하기 위해 50 대 정도의 상당히 중요한 서버가 필요합니다 (초기의 소규모 클라이언트가 초기에 최대치, 예 : "450k 클라이언트에서 최대 4 코어 / 15GB 박스").

이번에는 1 천만 개에 대한 또 다른 참조 자료가 있습니다. http://goroutines.com/10m .

이것은 자바 기반이고 1200 만 개의 연결 인 것으로 보입니다 : https://mrotaru.wordpress.com/2013/06/20/12-million-concurrent-connections-with-migratorydata-websocket-server/

HTTP는 일반적으로 페이지를 클라이언트로 전송하는 데 걸리는 시간보다 오래 TCP 연결을 열어 두지 않습니다. 그리고 일반적으로 사용자가 페이지를 다운로드하는 것보다 웹 페이지를 읽는 데 훨씬 더 많은 시간이 걸립니다. 사용자가 페이지를 보는 동안 그는 서버에 부하를 전혀 추가하지 않습니다.

따라서 웹 사이트를 동시에 볼 수있는 사람의 수는 동시에 제공 할 수있는 TCP 연결의 수보다 훨씬 많습니다.

IPv4 프로토콜의 경우 하나의 포트에서 수신하는 하나의 IP 주소를 가진 서버는 2 ^ 32 개의 IP 주소 x 2 ^ 16 개의 포트만 처리 할 수 ​​있으므로 2 ^ 48 개의 고유 소켓이 있습니다. 서버를 물리적 시스템으로 말하고 모든 2 ^ 16 포트를 사용할 수 있다면 하나의 IP 주소에 대해 최대 2 ^ 48 x 2 ^ 16 = 2 ^ 64 개의 고유 한 TCP / IP 소켓이있을 수 있습니다. 일부 포트는 OS 용으로 예약되어 있으므로이 숫자는 더 낮습니다. 요약하자면 :

1 개의 IP 및 1 개의 포트-> 2 ^ 48 소켓

1 개의 IP 및 모든 포트-> 2 ^ 64 소켓

유니버스의 모든 고유 IPv4 소켓-> 2 ^ 96 소켓

여기에는 두 가지 다른 논의가 있습니다. 하나는 서버에 연결할 수있는 사람의 수입니다. 이것은 다른 사람들이 적절하게 대답 했으므로 그것에 대해서는 다루지 않겠습니다.

다른 서버는 몇 개의 포트를 수신 할 수 있습니까? 나는 이것이 64K 번호가 나온 곳이라고 생각합니다. 실제로 TCP 프로토콜은 포트에 대해 16 비트 식별자를 사용하며 이는 65536 (64K보다 약간 더 큼)으로 변환됩니다. 즉, IP 주소별로 서버에 다양한 "수신자"를 가질 수 있습니다.

한 웹 서버가 처리 할 수있는 동시 소켓 연결 수는 각 연결이 소비하는 리소스의 양과 다른 웹 서버 리소스 제한 구성을 제외하고 서버에서 사용할 수있는 총 리소스의 양에 따라 크게 달라진다고 생각합니다.

예를 들어, 모든 소켓 연결이 1MB의 서버 리소스를 사용하고 서버에 16GB의 사용 가능한 RAM이있는 경우 (이론상) 이는 동시 연결 (16GB / 1MB) 만 처리 할 수 ​​있음을 의미합니다. 그렇게 간단하다고 생각합니다 ... 정말!

따라서 웹 서버가 연결을 처리하는 방법에 관계없이 모든 연결은 궁극적으로 일부 리소스를 소비합니다.