TCP_DEFER_ACCEPT의 실제 사용?

온라인 에서 Apache httpd 매뉴얼 을 숙독하고 이를 활성화하기위한 지시문을 발견했습니다. 매뉴얼 페이지에서 다음에 대한 설명을 찾았습니다 tcp.

   TCP_DEFER_ACCEPT (since Linux 2.4)
          Allow a listener to be awakened only when data arrives on the
          socket.  Takes an integer value (seconds), this can bound the
          maximum number of attempts TCP will make to complete the
          connection.  This option should not be used in code intended
          to be portable.

그런 다음 이 기사를 찾았 지만 여전히 어떤 종류의 워크로드가 유용한 지 확실하지 않습니다. 특별히이 httpd옵션이있는 경우 웹 서버와 관련이 있어야 한다고 가정 합니다. 또한 httpd네트워크 연결 방법뿐만 아니라 원하는 옵션과 원하지 않는 사용 사례가 있다는 것이 옵션이라는 사실을 전제로합니다 .

기사를 읽은 후에도 3 방향 핸드 셰이크가 완료되기를 기다리는 이점이 무엇인지 확실하지 않습니다. httpd핸드 셰이크가 계속 진행되는 동안 연결이 형성된 후 지연을 유발하는 대신 관련 인스턴스 를 교체하지 않아도되는 것이 유리할 것 입니다.

이 기사에서는 TCP_DEFER_ACCEPT소켓 의 상태에 관계없이 여전히 4 개의 패킷 (각각의 핸드 셰이크 및 데이터)이 필요한 것으로 보입니다 . 나는 그들이 어떻게 카운트를 3으로 줄이는 지, 그것이 어떻게 의미있는 향상을 제공하는지 모릅니다.

그래서 내 질문은 기본적으로 : 이것은 오래된 오래된 옵션입니까, 아니면이 옵션의 실제 사용 사례입니까?

(OP에 대한 나의 의견을 요약하기 위해)

그들이 참조하고있는 3 방향 핸드 셰이크는 TCP 연결 설정의 일부이며, 해당 옵션은 특별히 관련이 없습니다. 또한 데이터 교환은 3 방향 핸드 셰이크의 일부가 아니며 열기 / 설정 상태에서 TCP 연결을 생성하기 만합니다.

이 옵션의 존재와 관련하여, 이것은 소켓의 전통적인 동작이 아니며, 일반적으로 소켓 핸들러의 스레드는 연결이 수락 될 때 (여전히 3 방향 핸드 셰이크가 완료된 후) 깨어 났으며, 일부 프로토콜 활동의 경우 여기에서 시작됩니다 ( 예를 들어 SMTP 서버는 220 인사말 라인을 전송하지만 HTTP의 경우 대화의 첫 번째 메시지는 웹 브라우저가 GET / POST / etc 라인을 전송하는 것이며,이 때까지 HTTP 서버는 연결에 관심이 없습니다 (타이밍 제외) 소켓이 완료되면 HTTP 프로세스를 깨우는 것은 프로세스가 즉시 다시 잠 들어 필요한 데이터를 기다리기 때문에 낭비 적 인 활동입니다.

유휴 프로세스를 깨우면 추가 처리를 위해 '준비'될 수 있다는 주장이 있지만 (특히 오래된 컴퓨터에서 로그인 터미널을 깨우고 스왑에서 제거하는 것을 기억합니다) 당신은 또한 스왑 아웃은 프로세스가 이미 리소스를 요구하고 있으며 불필요한 스레드를 추가로 사용하면 개별 스레드의 성능이 향상 되더라도 시스템 성능이 전반적으로 저하 될 수 있습니다. 교체 한 경우 다른 속도를 늦추고, 사용량이 많을 경우 즉시 수면으로 전환 할 수 있습니다. 도박 인 것 같습니다. 궁극적으로 '욕심쟁이'도박은 바쁜 기계에서 돈을 지불하지 않아도됩니다.

이러한 성능 조정 수준에 대한 나의 일반적인 조언은 어쨌든 가장 좋은 것에 대해 프로그래밍 방식으로 결정하는 것이 아니라 시스템 관리자와 운영 체제가 자원 관리 문제를 처리하기 위해 협력하도록하는 것입니다. 전체 시스템의 작업 부하를 이해하는 데 더 적합합니다. 옵션 및 구성 선택 사항을 제공하십시오.

질문에 구체적으로 대답하기 위해이 옵션은 HTTP 트래픽이 극심한 경우를 제외하고는 눈에 띄는 수준이 아니라 모든 구성에서 유리하지만 이론적으로는 "올바른"방법입니다. 모든 유닉스 (모든 리눅스는 아님) 맛이 그 기능을 가지고 있지 않기 때문에 옵션이므로 이식성을 위해 기울어지지 않도록 구성 할 수 있습니다.

3 방향 핸드 셰이크가 완료되기를 기다리는 이점이 무엇인지 확실하지 않습니다.

3 방향 핸드 셰이크는 음성 전화 통신의 일반적인 프로토콜입니다.

1. 서버 : "좋은 오후, Epiphyte Corp."
2. 발신자 : "안녕하세요. 랜디입니다."
3. 서버 : "예, 어떻게 도와 드릴까요?"
4. 발신자 : 통화 본문이 농담을 요청하기 시작 함

채널이 설정되도록 TCP에서 중요합니다. 고객이 듣기 전에 전화를 받기 시작한 경우 (3) 서버가 듣지 않거나 준비가되지 않았을 가능성이 있습니다. 청각 (3)은 서버가 전송 후 즉시 자발적인 연소를 겪는 것을 보장하지는 않지만 서버가 수신 할 준비가되었음을 확신합니다.

핸드 셰이 킹 위키 백과에 언급 된대로 :

1. Alice [Server]는 Bob [Client]이 수신하고 응답 할 필요가없는 수신 확인 번호 y + 1의 수신 확인 메시지 로 응답 합니다.

따라서 서버가 준비되었다는 확신을 조금 더 줄이려면 서버는 3 단계를 건너 뛸 수 있으며 클라이언트는 서버가 준비되었다고 가정합니다. 위의 프로토콜 교환은 다음과 같습니다.

1. 서버 : "좋은 오후, Epiphyte Corp."
2. 발신자 : "안녕하세요. 랜디입니다."
3. 발신자 : "이멜다 마르코스에 대한 농담을 아십니까?"