65536 +1 시스템 연결

네트워크의 모든 시스템 에는 65536 개의 포트 가 있으며 모든 연결 또는 보내기 / 받기는 그 중 하나를 사용합니다.

내 질문은 : 65536 + 1 연결 이 있으면 어떻게됩니까 ?!

정상적인 방식으로 발생하지는 않지만 운영 체제가 어떻게 처리하는지 알고 싶습니다.

시스템은 각각 별도의 포트를 사용 하지 않아도 되기 때문에 65536 개 이상의 동시 연결을 처리 할 수 ​​있습니다 .

TCP 연결 또는 UDP 흐름은 4 개의 튜플에 의해 정의됩니다.

(source IP address, source port, destination IP address, destination port)

따라서 단일 IP 주소를 가진 웹 서버 시스템과 포트 80에서만 수신하는 단일 HTTP 서버 소프트웨어 패키지가 있더라도 이론적으로는 연결된 IP 주소 당 65536 개의 연결을 처리 할 수 있습니다 . 따라서 클라이언트 IP 주소 1의 64Ki 연결과 클라이언트 IP 주소 2의 64Ki 연결 등

따라서 프로토콜은 첫 번째 근사값까지 단일 IPv4 주소의 단일 TCP 또는 UDP 포트에 대한 2 ^{개의 48 개의} 연결 / 흐름을 지원합니다. TCP와 UDP를 함께 그리고 IPv4의 주소 공간과 IPv6의 우주적으로 / 공식적으로 큰 주소 공간을 모두 고려하면 프로토콜 자체가 호스트의 동시 연결 수에 대한 제한의 원인이 될 수 없음을 알 수 있습니다 처리 할 수 ​​있습니다.

마찬가지로 TCP 또는 UDP 프로토콜에는 클라이언트 시스템이 단일 IP 주소에서 단일 소스 포트를 사용하여 다양한 서버 주소 및 포트에 여러 개의 발신 연결을 만드는 것을 막는 것은 없습니다. 때때로 특정 OS의 네트워킹 API가이를 쉽게 만들지 못할 수도 있지만, 예전의 "[BSD] 소켓"API는 TCP와 UDP에 대한 하나의 API라는 것을 기억하는 것이 중요합니다. TCP 및 UDP에는 기존 소켓 API에 노출되지 않은 기능이있을 수 있습니다.

따라서 주어진 호스트가 처리 할 수있는 동시 TCP 연결 또는 UDP 흐름의 수는 포트 번호가 아니라 RAM 공간 및 CPU 시간과 같은 시스템 리소스에 의해 모든 연결을 추적하고 모두 서비스하는 데 걸리는 시간에 의해 제한됩니다. 또한 OS의 구현 별 세부 정보는 인공적인 제한을 부과 할 수 있습니다. 예를 들어, 유닉스 "모든 것이 파일"이라는 철학에는 모든 TCP 연결 또는 UDP 흐름에 대한 파일 설명자가있을 수 있습니다. 유닉스 커널이 추적 할 수있는 파일 디스크립터 수에 제한이있는 경우 해당 파일 디스크립터 제한은 커널이 처리 할 수있는 동시 TCP 연결 또는 UDP 플로우 수에 대한 인공 제한입니다.