많은 차단 VS 단일 비 차단 근로자

이 연결을 받아들이는 HTTP 서버 인 후는 한 가정 어떻게 든 헤더가 완전히 전송 될 때까지 기다립니다. 나는 그것을 구현하는 가장 일반적인 방법이 무엇인지 궁금하고 나머지의 장점과 단점은 무엇인가. 나는 이것들 만 생각할 수 있습니다.

다음과 같은 이유로 많은 차단 작업자가 좋습니다.

• 더 반응이 좋습니다.
• 새로운 연결을보다 쉽게 ​​도입 할 수 있습니다 (작업자는 동기화 된 목록에 추가 될 때까지 외부인이 아니라 스스로 연결합니다).
• 연결 수가 증가하고 감소함에 따라 CPU 사용은 추가 노력없이 자동으로 균형을 맞 춥니 다.
• CPU 사용량 감소 (차단 된 스레드는 실행 루프에서 제거되며 클라이언트간에 점프하기위한 논리가 필요하지 않습니다).

다음과 같은 이유로 단일 비 차단 작업자가 좋습니다.

• 적은 메모리를 사용합니다.
• 게으른 클라이언트에 덜 취약합니다 (서버에 연결하여 헤더를 느리게 보내거나 전혀 보내지 않음).

보시다시피, 다중 작업자 스레드는 전반적으로 조금 더 나은 솔루션으로 보입니다. 그것의 유일한 문제는 그러한 서버를 공격하기가 쉽다는 것입니다.

편집 (추가 연구) : 웹에서 찾은 일부 리소스 ( 수천 개의 스레드 및 차단 I / O-Java 서버를 작성하는 오래된 방법은 Paul Tyma의 새로운 방법이며 더 좋습니다) 는 접근 방식을 차단하는 것이 일반적으로 더 좋지만 나는 여전히 가짜 연결을 다루는 방법을 모른다.

PS 작업에 일부 라이브러리 또는 응용 프로그램을 사용하지 않는 것이 좋습니다. 나는 그것이 실제로 작동하는 것보다 실제로 작동하거나 작동하는 방법을 알고 싶습니다.

PSS 논리를 여러 부분으로 나누었으며 HTTP 헤더 수락 만 처리합니다. 처리하지 않습니다.

은 총알이 없습니다

실제로 그것은 달려있다 ...

tl; dr-쉬운 해결책, nginx 사용 ...

블로킹:

예를 들어, Apache는 기본적으로 모든 연결에 대해 프로세스가 분기되는 차단 체계를 사용합니다. 즉, 모든 연결에는 자체 메모리 공간이 필요하며 연결 ​​수가 증가함에 따라 컨텍스트 전환 오버 헤드의 양이 증가합니다. 그러나 일단 연결이 닫히면 컨텍스트를 삭제하고 모든 / 모든 메모리를 쉽게 검색 할 수 있다는 이점이 있습니다.

멀티 스레드 방식은 연결 수에 따라 컨텍스트 전환의 오버 헤드가 증가하지만 공유 컨텍스트에서 메모리 효율성이 더 높다는 점에서 비슷합니다. 이러한 접근 방식의 문제점은 안전한 방식으로 공유 메모리를 관리하기 어렵다는 것입니다. 메모리 동기화 문제를 극복하기위한 접근 방식에는 종종 자체 오버 헤드가 포함됩니다. 예를 들어 잠금은 CPU를 많이 사용하는로드에서 기본 스레드를 정지시킬 수 있으며 변경 불가능한 유형을 사용하면 불필요한 불필요한 데이터 복사가 추가됩니다.

AFAIK는 블로킹 HTTP 서버에서 다중 프로세스 접근 방식을 사용하는 것이 일반적으로 안전합니다. 안전한 방식으로 메모리를 관리 / 복구하는 것이 더 안전하고 간단합니다. 메모리 복구가 프로세스 중지만큼 간단 할 때 가비지 콜렉션은 문제가되지 않습니다. 장기 실행 프로세스 (예 : 데몬)의 경우이 특성이 특히 중요합니다.

소수의 작업자에게는 컨텍스트 전환 오버 헤드가 미미한 것처럼 보일 수 있지만, 부하가 수백에서 수천에 이르는 동시 연결로 확장됨에 따라 단점이 더욱 중요해집니다. 기껏해야 상황 전환은 O (n)을 현재 존재하는 작업자 수로 확장하지만 실제로는 그보다 더 나쁩니다.

차단을 사용하는 서버가 IO로드가 많은 경우에 이상적인 선택이 아닌 경우 CPU를 많이 사용하는 작업에 이상적이며 메시지 전달은 최소한으로 유지됩니다.

비 차단 :

비 차단은 Node.js 또는 nginx와 같은 것입니다. 이는 특히 IO 집약적로드에서 노드 당 훨씬 더 많은 연결로 확장하는 것으로 알려져 있습니다. 기본적으로 사람들이 처리 할 수있는 스레드 / 프로세스 기반 서버의 상한선에 도달하면 대체 옵션을 찾기 시작했습니다. 이를 C10K 문제 (예 : 10,000 개의 동시 연결 처리 기능) 라고도합니다 .

비 차단 비동기 서버는 일반적으로 메인 스레드를 오버로드하지 않기 때문에 CPU 집약적로드를 피해야한다는 점에서 멀티 스레드 잠금 방식과 많은 특성을 공유합니다. 컨텍스트 전환으로 인해 발생하는 오버 헤드가 본질적으로 제거되고 하나의 컨텍스트 메시지 만 전달하면 문제가되지 않습니다.

많은 네트워킹 프로토콜에서 작동하지 않을 수 있지만 HTTP 비 상태 유지 특성은 특히 비 블로킹 아키텍처에서 잘 작동합니다. 리버스 프록시와 여러 비 차단 HTTP 서버의 조합을 사용하면로드가 많은 노드를 식별하고 라우팅 할 수 있습니다.

노드가 하나 뿐인 서버에서도 처리량을 최대화하기 위해 프로세서 코어 당 하나의 서버를 설정하는 것이 일반적입니다.

양자 모두:

'이상적인'사용 사례는이 둘의 조합입니다. 전면의 역방향 프록시는 상단의 라우팅 요청을 전담 한 다음 차단 및 비 차단 서버를 혼합 한 것입니다. 정적 컨텐츠, 캐시 컨텐츠, html 컨텐츠 제공과 같은 IO 작업에 대한 비 차단. 이미지 / 비디오 인코딩, 콘텐츠 스트리밍, 번호 크 런칭, 데이터베이스 쓰기 등과 같은 CPU가 많은 작업을 차단합니다.

귀하의 경우 :

헤더를 확인하고 실제로 요청을 처리하지 않는 경우 본질적으로 설명하는 것은 리버스 프록시입니다. 그런 경우에는 분명히 비동기 방식으로 갈 것입니다.

nginx 내장 리버스 프록시 문서를 확인하는 것이 좋습니다 .

곁에:

제공 한 링크에서 글을 읽었으며 비동기가 특정 구현에 적합하지 않은 것으로 이해됩니다. 이 문제는 한 문장으로 요약 될 수 있습니다.

클라이언트 간 전환시 값 / 상태 저장 및 복원을위한 코드가 어렵다는 것을 발견했습니다.

그들은 상태 기반 플랫폼을 구축하고있었습니다. 이 경우 비동기 방식은 컨텍스트가 전환 될 때마다 (예 : 이벤트가 발생할 때) 상태를 지속적으로 저장 /로드해야한다는 것을 의미합니다. 또한 SMTP 측면에서 많은 CPU 집약적 인 작업을 수행하고 있습니다.

그들은 비동기에 대한 이해력이 상당히 좋지 않은 것처럼 들리고 결과적으로 많은 나쁜 가정을 만들었습니다.