KeepAliveTimeout주어진 시간 내에 새로운 요청이 발행되지 않으면 Apache는 연결 유지 연결을 닫습니다. 사용자가 브라우저 / 탭을 닫지 않으면이 시간 제한 (보통 5-15 초)이 결국 대부분의 연결 유지 연결을 닫고 연결을 무기한 보류하여 서버 리소스가 낭비되는 것을 방지합니다.
이제 MaxKeepAliveRequests지시문은 단일 TCP 연결 (으로 인해 열린 상태로 KeepAlive유지됨)이 제공 할 HTTP 요청 수를 제한 합니다. 이를 설정 0하면 무제한의 요청이 허용됩니다.
왜 이것을 "무제한"이외의 것으로 설정 하시겠습니까? 클라이언트가 여전히 적극적으로 요청하는 경우 동일한 연결 유지 연결에서 요청을 발생시키는 데 어떤 해가 있습니까? 한도에 도달 한 후에도 새 연결에서 요청이 계속 들어옵니다.
내가 보는 방식으로는 이것을 제한하는 데 아무런 의미가 없습니다. 내가 무엇을 놓치고 있습니까?
답변:
아파치는 기본적으로 빌드되지 않았기 때문이다. 문제는 서버 메모리 사용량입니다. 많은 구성에서 컨텐츠 생성은 컨텐츠 전달과 동일한 프로세스에서 수행되므로 각 프로세스는 처리하는 최대 크기로 커집니다. 무거운 PHP 스크립트로 인해 64MB로 확장 된 프로세스를 상상 한 다음 부풀린 프로세스는 정적 파일을 앉아서 제공합니다. 이제 여기에 100을 곱하십시오. 또한, 어디서나 메모리 누수가 발생하면 프로세스는 제한없이 커집니다.
Keepalive 설정은 콘텐츠 유형과 트래픽에 따라 균형을 유지해야합니다. 일반적으로 최적의 구성은 MaxKeepAliveRequests 높음 (100-500) 및 KeepAliveTimeout 낮음 (2-5)으로 빠르게 해제 할 수 있습니다.
나는 이것이 오래된 질문이라는 것을 알고 있지만 디버깅을 해 왔으며 (아파치의 경우에만 해당되는 것은 아닙니다) MaxKeepAliveRequests독립적으로 작동합니다 KeepAliveTimeout.
즉, 제한 시간 지시문은 유휴 지속 연결 (읽기 또는 쓰기 없음)에 대해서만 계산됩니다. 제한 시간 미만으로 요청을 계속하면 사실상 동일한 연결을 통해 무제한의 요청을 수행 할 수 있습니다.
장기 실행 TCP 연결이 무작위로 종료되는 것을 포함하여 어떤 이유로 좋지 않을 수 있습니까? 어쨌든 http 클라이언트는 그다지 어리석지 않으며 "낮음" MaxKeepAliveRequests설정을 꽤 잘 처리 할 수 있습니다. 예를 들어 프로그래밍 언어에서 서버에 의해 tcp 연결이 닫혔는지 다시 감지하는 것이 비교적 쉽습니다. 또한 대부분의 http 클라이언트는 자체적으로 제한이 있습니다 (예 : 브라우저는 300 초 정도 후에 연결 유지 연결을 닫습니다).
한 가지 이유는로드 밸런싱 때문입니다. 연결 유지 또는 http 1.1 영구 연결이 설정되면로드 밸런서는 닫힐 때까지 새 호스트로 이동하지 않습니다. 하나의 클라이언트가 하나의 연결을 통해 많은 수의 요청을하는 경우 서버 간 균형이 맞지 않을 수 있습니다.
부분적으로, 단일 사용자가 모든 연결 슬롯을 호지하지 않도록합니다. 제한없이 악의적이거나 잘못 작성된 한 명의 클라이언트가 사용 가능한 모든 단일 연결을 인계 받아 영원히 유지할 수 있습니다. 그러나 이는 IP 별 연결 제한과 비교할 때 큰 완화는 아닙니다.
대부분의로드 밸런싱, 특히 유지 관리와 관련하여. 서버를 오프라인으로 전환하려면 서버를 0 개의 연결로 삭제하지만 일정 시간 동안 기존 연결이 완료되도록합니다. keepalive 요청 수를 제한한다는 것은 결국 사용자가 정상적으로 새 연결을 만들고 새 백엔드 서버로 이동한다는 의미입니다. 아마도 드레인 프로세스 중에 keepalives의 수락을 중단해야한다는 신호를 서버에 알리는 방법이 더 나을 것입니다. 그러나 그러한 기능이 존재하지 않는 한 알 수 있습니다.