Azure Load Balancer를 사용하여 몇 가지 이상한 동작을 디버깅하는 동안 로컬 Debian Stretch TCP 스택이 짝수 포트에만 TCP 연결을 만드는 것을 발견했습니다. 나는 이상한 소스 포트로 단일 TCP 핸드셰이크를 시작하지 않을 것입니다. 의도적인 걸까요?
답변1
이는 connect()와 사이의 경합을 줄이기 위한 것입니다 bind()(Linux 4.2에 나타남; Jessie는 3.16, Stretch는 4.9):
범죄07f4c90062f8fc7c8c26f8f95324cbe8fa3145a5 저자: 에릭 듀마셋 날짜: 2015년 5월 24일 일요일 14:49:35 -0700 tcp/dccp: connect()에서 ip_local_port_range를 소진하지 않도록 노력하세요. 사용량이 많은 서버의 오랜 문제는 사용 가능한 TCP 포트 수가 적다는 것입니다. 범위(/proc/sys/net/ipv4/ip_local_port_range) 및 기본값 connect() 시스템 호출에서 소스 포트를 순차적으로 할당합니다. 호스트에 활성 TCP 세션 수가 많으면 가능합니다. 매우 높음, 모든 포트가 하나 이상의 흐름에서 사용됩니다. 이후의 바인드(0) 시도는 실패하거나 대부분을 스캔해야 합니다. 슬롯을 찾을 수 있는 공간입니다. 이번 패치에서는 __inet_hash_connect()의 시작점을 변경했습니다. 그래서 우리는 짝수[1] 포트를 지원하려고 노력하고, 바인드()에 홀수 포트를 남겨둡니다. 사용자. 아직 순차 검색을 하고 있기 때문에 보장할 수는 없지만, connect() 대상이 매우 다른 경우 최종 결과는 우리가 떠나는 것입니다. 바인드()에 더 많은 포트를 사용할 수 있으므로 범위 전체에 분산시킵니다. 슬롯을 찾는 데 필요한 connect() 및 바인딩() 시간을 줄입니다. 이 정책은 /proc/sys/net/ipv4/ip_local_port_range인 경우에만 유효합니다. 즉, 시작/끝 값의 패리티가 다른 경우입니다. 따라서 기본 /proc/sys/net/ipv4/ip_local_port_range가 다음으로 변경됩니다. 32768 - 60999(32768 - 61000 대신) 여기서는 보안 측면에서 아무것도 변경되지 않았습니다. 단지 일부 잘못된 해시만 있을 뿐입니다. 계획은 결국 이러한 변경으로 인해 영향을 받을 수 있습니다. [1]: 홀수/짝수 속성은 ip_local_port_range 값 패리티에 따라 달라집니다.
후속 조치를 읽어 볼 수도 있습니다.1580ab63fc9a03593072cc5656167a75c4f1d173 제출.