☰

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 서버는 이 때까지 연결에 관심이 없습니다. (타이밍 제외)) 소켓 승인이 완료되었을 때 HTTP 프로세스를 깨우는 것은 낭비적인 활동입니다. 프로세스가 필요한 데이터를 기다리면서 즉시 다시 절전 모드로 전환되기 때문입니다.

유휴 프로세스를 깨우면 추가 처리를 위해 "준비"가 된다고 주장할 수도 있지만(특히 아주 오래된 시스템에서 로그인 터미널을 깨우고 스왑에서 인입하도록 했던 기억이 납니다), A 프로세스가 다음과 같다고 주장할 수도 있습니다. 교체로 인해 이미 리소스가 요구되고 불필요한 추가 요구가 발생하면 전체 시스템 성능이 저하될 수 있습니다. 개별 스레드에서 성능이 눈에 띄게 향상되더라도(아주 바쁜 시스템에서는 그렇지 않을 것임) 병목 현상이 발생합니다. 교체하면 다른 작업 속도가 느려지는 디스크 IO입니다. 너무 바쁜 경우 절전 모드로 인해 즉시 다시 교체될 수 있습니다. 이것은 도박처럼 보이며 결국 "탐욕스러운" 도박은 바쁜 컴퓨터에서 반드시 성과를 거두지는 않으며 이미 프로세스를 바꾼 컴퓨터에서 불필요한 추가 작업을 발생시킬 것입니다. 귀하의 접근 방식은 The machine을 사용하는 컴퓨터를 대상으로 합니다. 대부분 절전 모드인 대규모 인메모리 프로세스 세트에 최적화되어 있으며 하나의 절전 상태를 다른 절전 상태로 바꾸는 것은 큰 문제가 아니지만 대량의 메모리 활성 프로세스 세트가 있는 머신은 추가적인 IO 영향을 받게 됩니다. 그렇지 않은 모든 것 메모리 바인딩된 시스템은 영향을 받으며 CPU 바인딩된 시스템은 더욱 악화됩니다.

이 수준의 성능 조정에 대한 일반적인 조언은 무엇이 최선인지에 대해 프로그래밍 방식으로 결정을 내리는 것이 아니라 시스템 관리자와 운영 체제가 함께 작업하여 리소스 관리 문제를 처리할 수 있도록 하는 것입니다. 이것이 그들의 임무이고 책임은 많습니다. 전체 시스템 및 기타 시스템의 작업 부하를 이해하는 데 더 적합합니다. 옵션 및 구성 선택 사항을 제공합니다.

질문에 구체적으로 대답하자면, 이 옵션은 HTTP 트래픽의 극심한 부하를 제외하고는 모든 구성에 적합하며, 눈에 띄는 수준으로 이동하지는 않지만 이론상으로는 "올바른" 방법입니다. 모든 Unix 버전(또는 모든 Linux)에 이 기능이 있는 것은 아니므로 이는 옵션입니다. 따라서 이식성을 위해 이를 포함하지 않도록 구성할 수 있습니다.

답변2

3방향 핸드셰이크가 완료될 때까지 기다리는 것의 이점이 무엇인지 명확하지 않습니다.

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

  1. 섬기는 사람: "안녕하세요, Epiphyte Corp."
  2. 방문객: "안녕하세요, 저는 랜디입니다."
  3. 섬기는 사람: "네, 도움이 필요하신가요?"
  4. 방문객:전화 문자 메시지가 농담을 요청하기 시작합니다.

이는 채널 설정을 보장하기 위해 TCP에서 매우 중요합니다. 클라이언트가 전송을 시작하면문자 통화서버는 듣기 전에 듣고 있지 않거나 준비되지 않았을 수 있습니다(3). Hearing(3)은 서버가 전송 직후에 자연적으로 연소되지 않는다는 것을 보장하지는 않지만 서버가 수신할 준비가 되었다는 신뢰도를 높입니다.

에서 언급했듯이악수에 관한 위키피디아:

  1. Alice [서버]는 확인 번호 y + 1의 확인 메시지로 응답하고 Bob [클라이언트]는 메시지를 받아 다음으로 보냅니다.그 사람은 답장할 필요 없어.

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

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

관련 정보