|
이 표에서는 소켓A가 테이블의 해당 주소에 성공적으로 바인딩된 다음, 소켓B가 초기화되고, SO_REUSEADDR 설정이 표의 첫 번째 열에 표시된 대로 이루어진 다음, 소켓B가 테이블의 해당 주소에 바인딩을 시도한다고 가정합니다. 결과 열은 바인딩의 결과입니다. 첫 번째 열의 값이 ON/OFF인 경우 SO_REUSEADDR 설정 여부는 결과와 관련이 없습니다.
와일드카드 IP 주소에 대한 SO_REUSEADDR의 역할은 위에서 논의되었지만 이 역할만 있는 것은 아닙니다. 또 다른 역할은 서버 측 프로그래밍을 수행할 때 모든 사람이 SO_REUSEADDR 옵션을 사용하는 이유입니다. 다른 역할과 중요한 응용 프로그램을 이해하려면 먼저 TCP 프로토콜이 어떻게 작동하는지 더 깊이 논의해야 합니다.
각 소켓에는 해당 전송 버퍼가 있습니다. send() 메소드가 성공적으로 호출되면 실제로 보내야 하는 데이터가 반드시 즉시 전송될 필요는 없지만 전송 버퍼에 추가됩니다. UDP 소켓의 경우 즉시 전송되지 않더라도 일반적으로 데이터가 빠르게 전송됩니다. 그러나 TCP 소켓의 경우 송신 버퍼에 데이터를 추가한 후 실제로 데이터가 전송되기까지 비교적 오랜 시간이 걸릴 수 있습니다. 따라서 TCP 소켓을 닫을 때 실제로 송신 버퍼에 전송 대기 중인 데이터가 여전히 있을 수 있습니다. 하지만 이때 send()는 성공을 반환하기 때문에 우리 코드에서는 데이터가 실제로 성공적으로 전송되었다고 생각합니다. close()를 호출한 직후에 TCP 소켓이 닫히면 이 모든 데이터가 손실되고 우리 코드는 이에 대해 전혀 알 수 없습니다. 그러나 TCP는 신뢰할 수 있는 전송 계층 프로토콜이므로 전송할 데이터를 직접 삭제하는 것은 분명히 바람직하지 않습니다. 실제로 송신 버퍼에 전송할 데이터가 남아 있는 동안 소켓의 close() 메서드를 호출하면 소위 TIME_WAIT 상태에 진입하게 됩니다. 이 상태에서 소켓은 모든 데이터가 성공적으로 전송되거나 시간 초과가 발생할 때까지 버퍼에 있는 데이터 전송을 계속 시도합니다.
소켓을 강제로 닫기 전 운영 체제 커널의 최대 대기 시간을 링거 시간이라고 합니다. 지연 시간은 대부분의 시스템에서 전체적으로 설정되며 비교적 길다(대부분의 시스템은 2분으로 설정). 소켓을 초기화할 때 SO_LINGER 옵션을 사용하여 각 소켓의 지연 시간을 구체적으로 설정할 수도 있습니다. 지연된 대기를 완전히 끌 수도 있습니다. 그러나 지연 시간을 0으로 설정하는 것(지연 대기를 완전히 끄는 것)은 좋은 프로그래밍 방식이 아니라는 점에 유의해야 합니다. TCP 소켓을 정상적으로 닫는 것은 원격 호스트와 여러 데이터 패킷을 교환(패킷 손실 시 손실 재전송 포함)하는 등 비교적 복잡한 프로세스이고, 이 데이터 패킷 교환 프로세스에 필요한 시간도 지연 시간에 포함되기 때문입니다. . 지연 대기를 비활성화하면 소켓은 닫힐 때 전송할 모든 데이터를 삭제할 뿐만 아니라 항상 강제로 닫힙니다(TCP는 연결 지향 프로토콜이므로 원격 포트와 닫는 패킷을 교환하지 않으면 다음과 같은 결과가 발생합니다). 원격 포트가 오랫동안 대기 중인 상태입니다.) 따라서 일반적으로 실제 프로그래밍에서는 이 작업을 수행하지 않는 것이 좋습니다. TCP 연결 해제 프로세스는 이 기사의 범위를 벗어납니다. 관심이 있는 경우 이 페이지를 참조할 수 있습니다. 그리고 실제로 지연 대기를 비활성화하고 소켓을 명시적으로 닫지 않고 프로그램이 종료되면 BSD(및 다른 시스템)는 우리 설정을 무시하고 지연 대기를 수행합니다. 예를 들어 프로그램이 exit() 메소드를 호출하거나 신호를 사용하여 해당 프로세스가 종료되는 경우(불법적인 메모리 액세스 등으로 인해 프로세스가 중단되는 경우 포함). 따라서 모든 상황에서 지연 대기 시간에 관계없이 소켓이 종료된다고 100% 보장할 수는 없습니다.
여기서 문제는 운영 체제가 TIME_WAIT 단계에서 소켓을 처리하는 방식입니다. SO_REUSEADDR 옵션이 설정되지 않은 경우 TIME_WAIT 단계의 소켓은 여전히 원래 주소 및 포트에 바인딩된 것으로 간주됩니다. 소켓이 완전히 닫힐 때까지(TIME_WAIT 단계 종료) 새 소켓을 이 주소 및 포트 쌍에 바인딩하려는 다른 시도는 성공하지 못합니다. 이 대기 시간은 지연된 대기 시간만큼 길 수 있습니다. 따라서 방금 닫힌 소켓에 해당하는 주소 및 포트 쌍에 새 소켓을 즉시 바인딩할 수 없습니다. 이 작업은 대부분의 경우 실패합니다.
그러나 새 소켓에 SO_REUSEADDR 옵션을 설정하면 현재 주소 포트 쌍에 바인딩된 다른 소켓이 있고 TIME_WAIT 단계에 있으면 이 기존 바인딩 관계는 무시됩니다. 실제로 TIME_WAIT 단계의 소켓은 이미 semi-closed 상태이므로 이 주소와 포트 쌍에 새 소켓을 바인딩하는 데 문제가 없습니다. 이 경우 이 포트에 바인딩된 원래 소켓은 일반적으로 새 소켓에 영향을 주지 않습니다. 그러나 어떤 시점에서는 TIME_WAIT 단계에 있지만 여전히 작동 중인 소켓에 해당하는 주소 포트 쌍에 새 소켓을 바인딩하면 의도하지 않고 예측할 수 없는 부정적인 영향을 미칠 수 있다는 점에 유의해야 합니다. 그러나 이 문제는 이 기사의 범위를 벗어납니다. 다행스럽게도 이러한 부정적인 영향은 실제로 거의 나타나지 않습니다.
마지막으로 SO_REUSEADDR에 대해 주목해야 할 한 가지는 새 소켓에 대해 SO_REUSEADDR을 설정하는 한 위의 모든 내용이 적용된다는 것입니다. 현재 주소와 포트 쌍에 바인딩된 원래 소켓의 경우 TIME_WAIT 단계의 소켓에 SO_REUSEADDR이 설정되어 있는지 여부는 영향을 미치지 않습니다. 바인드 작업의 성공 여부를 결정하는 코드는 단순히 바인드() 메서드에 전달된 새 소켓의 SO_REUSEADDR 옵션을 확인합니다. 관련된 다른 소켓의 SO_REUSEADDR 옵션은 확인되지 않습니다.
SO_REUSEPORT
많은 사람들이 SO_REUSEADDR을 SO_REUSEPORT로 착각합니다. 기본적으로 SO_REUSEPORT를 사용하면 이전에 바인딩된 모든 소켓에 SO_REUSEPORT 옵션이 설정되어 있는 한 원하는 수의 소켓을 정확히 동일한 소스 주소 및 포트 쌍에 바인딩할 수 있습니다. 주소 및 포트 쌍에 바인딩된 첫 번째 소켓에 SO_REUSEPORT가 설정되지 않은 경우 후속 소켓이 SO_REUSEPORT를 설정했는지 여부에 관계없이 이 주소 포트와 정확히 동일한 주소에 바인딩될 수 없습니다. 이 주소와 포트 쌍에 바인딩된 첫 번째 소켓이 바인딩 관계를 해제하지 않는 한. SO_REUSEADDR과 달리 SO_REUSEPORT를 처리하는 코드는 현재 바인딩을 시도하는 소켓의 SO_REUSEPORT를 검사할 뿐만 아니라 현재 바인딩을 시도하는 주소 포트 쌍에 이전에 바인딩된 소켓의 SO_REUSEPORT 옵션도 검사합니다.
SO_REUSEPORT는 SO_REUSEADDR과 동일하지 않습니다. 이것이 의미하는 바는 이미 바인딩된 주소가 있는 소켓에 SO_REUSEPORT가 설정되어 있지 않고 다른 새 소켓에 SO_REUSEPORT가 설정되어 있으며 현재 소켓과 정확히 동일한 포트 주소 쌍에 바인딩하려고 시도하는 경우 바인딩 시도가 실패한다는 것입니다. 동시에 현재 소켓이 이미 TIME_WAIT 단계에 있고 SO_REUSEPORT 옵션이 설정된 새 소켓이 현재 주소에 바인딩을 시도하면 바인딩 작업도 실패합니다. 현재 TIME_WAIT 단계에 있는 소켓에 해당하는 주소 포트 쌍에 새 소켓을 바인딩하려면 바인딩하기 전에 새 소켓의 SO_REUSEADDR 옵션을 설정하거나 바인딩하기 전에 두 소켓 모두에 대해 이를 설정해야 합니다. 옵션. 물론 소켓에 대해 SO_REUSEADDR 및 SO_REUSEPORT 옵션을 동시에 설정하는 것도 가능합니다.
SO_REUSEPORT는 SO_REUSEADDR 이후 BSD 시스템에 추가되었습니다. 이것이 현재 일부 시스템의 소켓 구현에 SO_REUSEPORT 옵션이 없는 이유입니다. 이 옵션이 BSD 시스템에 추가되기 전에 BSD 소켓 구현을 참조했기 때문입니다. 이 옵션이 추가되기 전에는 BSD 시스템에서 두 개의 소켓을 정확히 동일한 주소 및 포트 쌍에 바인딩할 수 있는 방법이 없었습니다.
Connect()는 EADDRINUSE를 반환합니까?
때때로 바인딩() 작업이 EADDRINUSE 오류를 반환합니다. 그러나 이상한 점은 connect() 작업을 호출할 때 EADDRINUSE 오류가 발생할 수도 있다는 것입니다. 왜 이런가요? 현재 포트에서 연결을 설정하려는 원격 주소도 사용되는 이유는 무엇입니까? 동일한 원격 주소에 여러 소켓을 연결할 때 문제가 있습니까?
이 글에서 앞서 언급했듯이 연결 관계는 5배로 결정됩니다. 모든 연결 관계에서 이 5중은 고유해야 합니다. 그렇지 않으면 시스템이 두 연결을 구별할 수 없습니다. 이제 주소 재사용을 사용하면 동일한 프로토콜을 사용하는 두 개의 소켓을 동일한 주소 포트 쌍에 바인딩할 수 있습니다. 이는 이 두 소켓의 경우 5-튜플 {, , }가 이미 동일하다는 것을 의미합니다. 이 경우 두 연결을 모두 동일한 원격 주소 포트에 연결하려고 하면 두 연결 관계의 5튜플은 정확히 동일합니다. 즉, 두 개의 동일한 연결이 생성됩니다. 이는 TCP 프로토콜에서는 허용되지 않습니다(UDP는 연결이 없음). 두 개의 동일한 연결 중 하나가 데이터를 수신하면 시스템은 해당 데이터가 어느 연결에 속하는지 알 수 없습니다. 따라서 이 경우 최소한 두 소켓이 연결하려는 원격 호스트의 주소와 포트는 동일할 수 없습니다. 이러한 방식으로만 시스템이 이 두 연결 관계를 계속해서 구별할 수 있습니다.
따라서 동일한 프로토콜을 사용하여 두 개의 소켓을 동일한 로컬 주소 및 포트 쌍에 바인딩할 때 두 소켓을 동일한 대상 주소 및 포트 쌍에 연결하려고 하면 두 번째 소켓은 connect() 메서드를 호출하려고 시도합니다. 정확히 동일한 5튜플을 가진 소켓이 이미 존재함을 나타내는 EADDRINUSE 오류를 보고합니다.
멀티캐스트 주소
일대일 통신에 사용되는 유니캐스트 주소에 비해 일대다 통신에는 멀티캐스트 주소가 사용됩니다. IPv4와 IPv6 모두 멀티캐스트 주소를 가지고 있습니다. 그러나 IPv4의 멀티캐스트는 공용 네트워크에서 거의 사용되지 않습니다.
멀티캐스트 주소의 경우 SO_REUSEADDR의 의미가 이전과 달라집니다. 이 경우 SO_REUSEADDR을 사용하면 여러 소켓을 정확히 동일한 소스 브로드캐스트 주소 및 포트 쌍에 바인딩할 수 있습니다. 즉, 멀티캐스트 주소의 경우 SO_REUSEADDR은 유니캐스트 통신의 SO_REUSEPORT와 동일합니다. 실제로 멀티캐스트의 경우 SO_REUSEADDR과 SO_REUSEPORT는 정확히 동일한 효과를 갖습니다.
FreeBSD/OpenBSD/NetBSD
이 모든 시스템은 최신 기본 BSD 시스템 코드를 참조합니다. 따라서 이 세 가지 시스템은 BSD와 정확히 동일한 소켓 옵션을 제공하며 이러한 옵션의 의미는 기본 BSD와 정확히 동일합니다.
MacOS X
MacOS의 핵심 코드 구현도 동일합니다.
iOS
iOS는 실제로 약간 수정된 MacOS X이므로 MacOS X에서 작동하는 것은 iOS에서도 작동합니다.
Linux
Linux3.9 이전에는 SO_REUSEADDR 옵션만 존재했습니다. 이 옵션의 기능은 기본적으로 BSD 시스템과 동일합니다. 그러나 여전히 두 가지 중요한 차이점이 있습니다.
첫 번째 차이점은 수신(서버) 상태의 TCP 소켓이 와일드카드 IP 주소와 특정 포트에 바인딩된 경우 이 두 소켓에 SO_REUSEADDR 옵션이 설정되어 있는지 여부에 관계없이 다른 TCP 소켓이 가능하다는 것입니다. 더 이상 동일한 포트에 바인딩되지 않습니다. 이는 다른 소켓이 특정 IP 주소(BSD 시스템에서 허용되는 대로)를 사용하는 경우에도 작동하지 않습니다. 비수신(클라이언트) TCP 소켓에는 이러한 제한이 없습니다.
두 번째 차이점은 UDP 소켓의 경우 SO_REUSEADDR이 BSD의 SO_REUSEPORT와 동일한 기능을 갖는다는 것입니다. 따라서 두 개의 UDP 소켓에 SO_REUSEADDR이 설정되어 있으면 정확히 동일한 주소 및 포트 쌍 집합에 바인딩될 수 있습니다.
Linux3.9에는 SO_REUSEPORT 옵션이 추가되었습니다. 두 개 이상의 TCP 또는 UDP, 수신(서버) 또는 비수신(클라이언트) 소켓은 포트에서 주소를 바인딩하기 전에 모든 소켓(첫 번째 소켓 포함)에 이 옵션이 설정되어 있는 한 정확히 동일한 주소에 바인딩될 수 있습니다. 콤비네이션. 동시에, 포트 하이재킹을 방지하기 위해 특별한 제한 사항이 있습니다. 동일한 주소 및 포트 조합에 바인딩하려는 모든 소켓은 동일한 사용자 ID를 가진 프로세스에 속해야 합니다. 따라서 한 사용자는 다른 사용자의 포트를 "훔칠" 수 없습니다.
또한 SO_REUSEPORT 옵션이 설정된 소켓의 경우 Linux 커널은 다른 시스템에는 없는 몇 가지 특수 작업도 수행합니다. 동일한 주소 및 포트 조합에 바인딩된 UDP 소켓의 경우 커널은 이들 소켓 간에 연결을 시도합니다. 수신된 데이터 패킷, 동일한 주소 및 포트 조합에 바인딩된 TCP 수신 소켓의 경우 커널은 수신된 연결 요청(accept() 메서드를 호출하여 얻은 요청)을 두 패킷 간에 균등하게 분배하려고 시도합니다. 이는 주소 재사용을 허용하지만 수신된 패킷이나 연결 요청을 동일한 주소 및 포트 조합에 연결된 소켓에 무작위로 할당하는 다른 시스템과 비교하여 Linux는 트래픽 분산을 최적화하려고 시도한다는 것을 의미합니다. 예를 들어, 간단한 서버 프로세스의 여러 다른 인스턴스는 SO_REUSEPORT를 사용하여 간단한 로드 밸런싱을 쉽게 구현할 수 있으며, 커널은 이 로드 밸런싱을 담당하며 이는 프로그램에 완전히 무료입니다!
Android
Android의 핵심 부분은 약간 수정된 Linux 커널이므로 Linux에서 작동하는 모든 것이 Android에서도 작동합니다.
Windows
Windows에는 SO_REUSEADDR 옵션만 있습니다. Windows에서 소켓에 SO_REUSEADDR을 설정하는 것은 BSD에서 동시에 소켓에 SO_REUSEPORT 및 SO_REUSEADDR을 설정하는 것과 동일한 효과를 갖습니다. 그러나 차이점은 바인딩된 주소가 있는 다른 소켓에 SO_REUSEADDR이 설정되지 않은 경우에도 SO_REUSEADDR이 설정된 소켓은 항상 다른 바인딩된 소켓과 정확히 동일한 주소 및 포트 조합에 바인딩될 수 있다는 것입니다. 이런 행동은 다소 위험하다고 할 수 있습니다. 하나의 애플리케이션이 연결된 포트에 대한 다른 참조의 데이터를 훔칠 수 있기 때문입니다. Microsoft는 이 문제를 인식하고 SO_EXCLUSIVEADDRUSE라는 또 다른 소켓 옵션을 추가했습니다. 소켓에 SO_EXCLUSIVEADDRUSE를 설정하면 소켓이 주소 및 포트 조합에 바인딩되면 SO_REUSEADDR 설정 여부에 관계없이 다른 모든 소켓이 더 이상 현재 주소 및 포트 조합에 바인딩될 수 없습니다.
Solaris
Solaris는 SunOS의 후속 제품입니다. SunOS는 어느 정도 이전 버전의 BSD에서 파생된 것이기도 합니다. 따라서 Solaris에서는 SO_REUSEADDR만 제공하며 성능은 기본적으로 BSD 시스템과 동일합니다. 내가 아는 한, SO_REUSEPORT와 동일한 기능은 Solaris 시스템에서 구현할 수 없습니다. 이는 Solaris에서는 두 개의 소켓을 정확히 동일한 주소 및 포트 조합에 바인딩할 수 없음을 의미합니다.
Windows와 마찬가지로 Solaris도 소켓에 대한 독점 바인딩 옵션인 SO_EXCLBIND를 제공합니다. 소켓이 주소를 바인딩하기 전에 이 옵션을 설정하면 다른 소켓은 SO_REUSEADDR이 설정되어 있어도 동일한 주소에 바인딩할 수 없습니다. 예를 들어, 소켓A가 와일드카드 IP 주소에 바인딩되고, 소켓B가 SO_REUSEADDR로 설정되고, 특정 IP 주소와 소켓A와 동일한 포트의 조합에 바인딩된 경우, 소켓A가 SO_EXCLBIND로 설정되지 않으면 이 작업이 성공하고, 그렇지 않으면 성공합니다. 실패하다.
참조:
http://stackoverflow.com/a/14388707/6037083
|
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
