☰

TCP_DEFER_ACCEPT의 실제 사용?

tag-icon • tag-icon linux networking tcp webserver
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으로 줄였는지, 그리고 그것이 어떻게 의미 있는 향상을 제공하는지 모르겠습니다.

그래서 제 질문은 기본적으로 이렇습니다. 이것은 단지 오래되고 쓸모없는 옵션인가요, 아니면 이 옵션에 대한 실제 사용 사례가 있습니까?

답변1

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

그들이 언급하는 3방향 핸드셰이크는 TCP 연결 설정의 일부이며, 문제의 옵션은 이와 특별히 관련이 없습니다. 또한 데이터 교환은 3방향 핸드셰이크의 일부가 아니며 단지 개방/확립 상태에서 TCP 연결을 생성한다는 점에 유의하십시오.

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

유휴 프로세스를 깨우면 추가 처리를 위해 '준비'가 될 수 있다는 주장이 확실히 있지만(특히 아주 오래된 컴퓨터에서 로그인 터미널을 깨우고 스왑에서 인입되도록 한 것을 기억합니다), 교체된 해당 프로세스는 이미 리소스를 요구하고 있으며 더 이상 불필요한 요구를 하면 전체 시스템 성능이 저하될 수 있습니다. 개별 스레드의 명백한 성능이 향상되더라도(그렇지 않을 수도 있고 매우 바쁜 시스템은 디스크 IO에 병목 현상이 발생하여 디스크 IO에 병목 현상이 발생함) 교체한 경우 다른 작업의 속도를 늦추고, 바쁜 경우 즉시 절전 모드로 전환하여 다시 교체할 수 있습니다. 그것은 도박인 것처럼 보이며 궁극적으로 '탐욕스러운' 도박은 바쁜 컴퓨터에서 반드시 성과를 거두지는 않으며 이미 프로세스가 교체된 컴퓨터에서 추가 불필요한 작업을 발생시킵니다. 귀하의 접근 방식은 다음과 같은 컴퓨터에 최적화되어 있습니다. 대부분 휴면 상태인 프로세스의 대용량 메모리 세트와 휴면 상태를 다른 프로세스로 바꾸는 것은 별 문제가 되지 않습니다. 그러나 활성 프로세스의 대용량 메모리 세트가 있는 머신은 추가 IO로 인해 어려움을 겪게 되며 메모리가 제한되지 않은 머신은 어려움을 겪게 됩니다. CPU에 바인딩된 모든 시스템은 더 나빠질 것입니다.

성능 조정 수준에 대한 나의 일반적인 조언은 어쨌든 무엇이 최선인지에 대해 프로그래밍 방식으로 결정을 내리는 것이 아니라 시스템 관리자와 운영 체제가 함께 협력하여 리소스 관리 문제를 처리하도록 허용하는 것입니다. 전체 시스템과 그 이상의 작업 부하를 이해하는 데 더 적합합니다. 옵션과 구성 선택 사항을 제공합니다.

질문에 구체적으로 답하자면, 이 옵션은 극단적인 HTTP 트래픽 로드를 제외하고는 알 수 있는 수준이 아니라 모든 구성에서 유용하지만 이론적으로는 이를 수행하는 "올바른" 방법입니다. 모든 Unix(모든 Linux는 아님) 버전에 해당 기능이 있는 것은 아니므로 이식성을 위해 포함되지 않도록 구성할 수 있기 때문에 이는 옵션입니다.

답변2

3방향 핸드셰이크가 완료될 때까지 기다리는 것이 어떤 이점이 있는지 잘 모르겠습니다.

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

  1. 섬기는 사람: "안녕하세요, Epiphyte Corp."
  2. 방문객: "안녕하세요. 랜디입니다."
  3. 섬기는 사람: "네, 무엇을 도와드릴까요?"
  4. 방문객:통화 내용이 농담을 요청하기 시작합니다.

채널이 설정되었는지 확인하기 위해 TCP에서 중요합니다. 클라이언트가 전송을 시작한 경우통화 본문(3)을 듣기 전에 서버가 듣고 있지 않거나 준비되지 않았을 가능성이 있습니다. 듣기(3)는 서버가 전송 후 즉시 자연 발화를 겪지 않았다는 것을 보장하지는 않지만 서버가 수신할 준비가 되었다는 신뢰도를 높입니다.

에 언급된 바와 같이핸드쉐이킹에 관한 위키피디아:

  1. Alice [서버]는 승인 번호 y + 1이 포함된 승인 메시지로 응답합니다. Bob [클라이언트]는 이를 수신하고그 사람은 대답할 필요가 없어.

따라서 서버가 준비되었다는 약간의 확신을 포기하려는 경우 서버는 (3) 단계를 건너뛸 수 있으며 클라이언트는 서버가 준비되었다고 가정합니다. 이는 위의 프로토콜 교환을 다음과 같이 바꿉니다.

  1. 섬기는 사람: "안녕하세요, Epiphyte Corp."
  2. 방문객: "안녕하세요. 랜디입니다."
  3. 방문객: "이멜다 마르코스에 대한 농담을 아시나요?"

관련 정보