tcp_tw_recycle / reuse를 1로 설정 한 결과는 무엇입니까?

구성 파일에서 tcp_tw_recycle / reuse를 모두 1로 설정했습니다.

이 일의 결과는 무엇입니까?

tcp 소켓을 재사용하면 보안 위험이 있습니까? 즉, 2 개의 서로 다른 연결이 잠재적으로 데이터를 전송할 수 있습니까?

적은 재 연결 가능성이있는 단기 연결에 적합합니까?

기본적으로 할 때 모두 tcp_tw_reuse와 tcp_tw_recycle비활성화, 커널은 소켓 있는지 확인합니다 TIME_WAIT충분히 미래의 연결에 속하는 패킷이 이전 연결의 말 패킷으로 오인되지 않습니다 있는지로 - 상태가 오랫동안 그 상태를 유지합니다.

활성화 tcp_tw_reuse하면 소켓이 TIME_WAIT만료되기 전에 소켓을 사용할 수 있으며 커널은 TCP 시퀀스 번호와 관련하여 충돌이 없는지 확인합니다. tcp_timestamps랩핑 된 시퀀스 번호에 대한 보호를 위해 PAWS (일명 PAWS)를 활성화 하면 이러한 충돌이 발생하지 않습니다. 그러나 양쪽 끝 에서 TCP 타임 스탬프를 활성화해야합니다 (적어도 내 이해입니다). gory 세부 사항 은 tcp_twsk_unique 의 정의를 참조 하십시오.

을 활성화 tcp_tw_recycle하면 커널이 훨씬 더 공격적이되고 원격 호스트가 사용하는 타임 스탬프를 가정합니다. 연결 TIME_WAIT상태에 있는 각 원격 호스트가 사용한 마지막 타임 스탬프를 추적하고 타임 스탬프가 올바르게 증가한 경우 소켓을 재사용 할 수 있습니다. 그러나 호스트가 사용하는 타임 스탬프가 변경되면 (즉, 뒤틀림) SYN패킷이 자동으로 삭제되고 연결이 설정되지 않습니다 ( "connect timeout"과 유사한 오류가 표시됨). 커널 코드로 들어가려면 tcp_timewait_state_process 의 정의가 좋은 출발점이 될 수 있습니다.

이제 타임 스탬프는 제 시간에 되돌아 가지 않아야합니다. 그렇지 않으면 :

• 호스트가 재부팅됩니다 (그러나 다시 부팅 될 때 TIME_WAIT소켓이 만료되어 문제가되지 않습니다).
• IP 주소는 다른 것에 의해 신속하게 재사용됩니다 ( TIME_WAIT연결은 약간 유지되지만 다른 연결에 영향을 미쳐 TCP RST공간이 확보 될 수 있습니다).
• 네트워크 주소 변환 (또는 smarty-pants 방화벽)이 연결 중간에 포함됩니다.

후자의 경우 동일한 IP 주소 뒤에 여러 개의 호스트가있을 수 있으므로 서로 다른 타임 스탬프 시퀀스 (또는 해당 타임 스탬프는 각 연결에서 방화벽에 의해 무작위 화됨)가 될 수 있습니다. 이 경우 TIME_WAIT서버 의 버킷에 새로운 타임 스탬프가있는 포트에 매핑되기 때문에 일부 호스트는 임의로 연결할 수 없습니다 . 그래서 문서에서 "NAT 장치 또는로드 밸런서가 설정으로 인해 드롭 프레임을 시작할 수 있습니다"라고 말합니다.

어떤 사람들 은 tcp_tw_recycle혼자 떠나는tcp_tw_reusetcp_timewait_len 것이 좋지만 가능하게 하고 낮추는 것이 좋습니다 . 나는 동의한다 :-)

나는 단지 이것을 물린 적이 있었으므로 아마도 누군가가 내 고통과 고통으로부터 이익을 얻을 수 있습니다. 첫째, 많은 정보가 포함 된 관련 링크 : http://vincent.bernat.im/en/blog/2014-tcp-time-wait-state-linux.html

특히:

이러한 부족한 문서의 결과는 TIME-WAIT 상태의 항목 수를 줄이기 위해 이러한 설정을 모두 1로 설정하도록 조언하는 수많은 조정 안내서를 발견 한 것입니다. 그러나 tcp (7) 매뉴얼 페이지에서 알 수 있듯이 net.ipv4.tcp_tw_recycle 옵션은 동일한 NAT 장치 뒤에있는 두 대의 다른 컴퓨터에서 연결을 처리하지 않으므로 공용 서버에 매우 문제가됩니다. 감지하고 당신을 물기 위해 기다리고 :

클라이언트에서 MySql NDB 클러스터로의 가능한 짧은 대기 시간, haproxy 연결을 제공하기 위해이를 성공적으로 활성화하는 데 사용했습니다. 이것은 프라이빗 클라우드에 있었으며, 어떤 종류의 NAT 와도 연결되어 있지 않았습니다. 유스 케이스는 이해하기 쉬우 며 인간이 할 수있는 한 haproxy를 통해 NDB에 충돌하는 반경 클라이언트의 대기 시간을 줄입니다. 그렇게했습니다.

나는 대중을 향한 haproxy 시스템에서 다시 영향을 미쳤으며 웹 트래픽의로드 밸런싱에 영향을 미쳤습니다 (벙어리, 맞습니까?!).

• NAT를 통해 연결하는 클라이언트를 위해 문제가 발생할 수 있습니다.
• 완전히 무작위적이고 간헐적이므로 증상을 식별하는 것은 거의 불가능하며 증상은 고객 B와 완전히 다른 (또는 그렇지 않은) 시간에 고객 A에 충돌합니다.

고객 측에서는 더 이상 SYN 패킷에 대한 응답을 얻지 못하는 시간, 때때로 여기 저기, 때로는 오랜 시간이 표시됩니다. 다시, 무작위.

최근의 고통스럽고 경험에 대한 짧은 이야기 는 역할에 관계없이 공개 서버에 단독으로 / 비활성화 된 채로 둡니다!

'man 7 tcp'에서 다음을 볼 수 있습니다.

   tcp_tw_recycle (Boolean; default: disabled; since Linux 2.4)
          Enable fast recycling of TIME_WAIT sockets.  Enabling this option is not recommended since this causes problems when working with NAT
          (Network Address Translation).

   tcp_tw_reuse (Boolean; default: disabled; since Linux 2.4.19/2.6)
          Allow  to  reuse  TIME_WAIT  sockets  for  new connections when it is safe from protocol viewpoint.  It should not be changed without
          advice/request of technical experts.

별로 도움이되지 않습니다. 이 사용에는 좋은 통찰력이 있습니다.

/programming/6426253/tcp-tw-reuse-vs-tcp-tw-recycle-which-to-use-or-both

그러나 재사용이 재활용보다 안전한 이유에 대한 구체적인 정보는 없습니다. 기본 대답은 tcp_tw_reuse는 동일한 TCP 매개 변수를 가진 TIME_WAIT에 소켓이 이미 있고 더 이상 트래픽이 예상되지 않는 상태 인 경우 동일한 소켓을 사용할 수 있도록 허용한다는 것입니다 (FIN이 전송 된 시점을 믿습니다) ). 반면에 tcp_tw_recycle은 상태에 관계없이 동일한 매개 변수로 TIME_WAIT에있는 소켓을 재사용하므로 다른 패킷을 예상 할 수있는 상태 저장 방화벽을 혼동 할 수 있습니다.

tcp_tw_reuse는 SO_REUSEADDR 소켓 옵션 man 7 socket을 다음과 같이 문서화하여 코드에서 선택적으로 수행 할 수 있습니다 .

   SO_REUSEADDR
          Indicates that the rules used in validating addresses supplied in a bind(2) call should allow reuse of local addresses.  For  AF_INET
          sockets  this means that a socket may bind, except when there is an active listening socket bound to the address.  When the listening
          socket is bound to INADDR_ANY with a specific port then it is not possible to bind to this port for any local address.   Argument  is
          an integer boolean flag.