답변:
"파일 열기"의 한계는 실제로 파일에만 국한된 것이 아닙니다. 단일 프로세스가 한 번에 사용할 수있는 커널 핸들 수의 제한입니다 . 역사적으로 프로그램에서 일반적으로 많은 파일을 열 수있는 유일한 것은 파일이므로 열린 파일 수의 제한으로 알려졌습니다. 프로세스가 많은 파일을 열고 실수로 닫는 것을 잊어 버려 프로세스 전체에 문제가 발생하는 것을 막는 데는 한계가 있습니다.
소켓 연결도 커널 핸들입니다. 따라서 동일한 이유로 동일한 제한이 적용됩니다. 프로세스가 네트워크 연결을 열고 닫는 것을 잊을 수 있습니다.
주석에서 언급했듯이 커널 핸들은 일반적 으로 유닉스 계열 시스템에서 파일 디스크립터 라고 합니다 .
read/ write인터페이스를 통해 바이트 스트림에 대한 액세스를 제공 합니다.
shutdown(2)파일에 대한 시스템 콜을 가지고 있지만 파일을 사용하지 않고 소켓에서 읽을 수 없습니다 . cat그 이유 netcat가 만들어졌습니다. 유닉스와 같은 커널에서 (행운 적으로) 소켓은 I / O 측면에서 파일처럼 작동하지만 유사성은 바로 끝납니다. (솔직히, 나는 계획 9 경험이있는 사람으로부터 전통적인 유니스보다 훨씬 더 많은 것들을 통일했다고 들었습니다.)
이유는 TCP / IP 소켓을 사용하는 파일 기술자 왜 소켓 인터페이스가 처음 설계 (구현 된 때이다가, 1983 년에, BSD 유닉스에서 당신이 할 수있는 -)의 디자이너는 네트워크 연결이 파일과 유사한 것을 느꼈다 read, write그리고 close모두 "모든 것이 파일입니다"라는 유닉스 아이디어와 잘 맞을 것입니다.
다른 TCP / IP 네트워크 스택 구현은 OS의 파일 I / O 하위 시스템과 반드시 통합 할 필요는 없었습니다 (예 : MacTCP) . 그러나 BSD 소켓 인터페이스가 널리 보급 되었기 때문에 이러한 다른 구현에서도 소켓 API를 Unix와 유사한 기능으로 복제하기로 선택 했으므로 "파일 설명자"를 얻었으며 TCP / IP 통신에만 사용되었습니다. 파일 디스크립터가 있습니다.
질문의 다른 부분은 왜 한계가 있습니까? 파일 디스크립터 조회 테이블을 구현하는 가장 빠른 방법은 배열을 사용하기 때문입니다. 역사적으로 한계는 커널에 하드 코딩되었습니다.
다음은 프로세스 당 하드 코드 된 한계 20 파일 디스크립터가있는 Unix 릴리스 7 (1979)의 코드입니다.
이에 비해 Linux는 프로세스의 파일 디스크립터 테이블을위한 공간을 동적으로 할당합니다. 절대 제한의 기본값은 8192이지만 원하는대로 설정할 수 있습니다. 내 시스템은에 191072을 나열합니다 /proc/sys/fs/file-max.
alloc_fdtable()struct fdtable#define NR_FILE 8192리눅스에는 더 이상 절대적인 제한이 없지만 프로그램을 미치게하고 싶지 않기 때문에 관리자 (또는 배포 패키지 관리자)는 일반적으로 리소스 제한을 설정합니다. 를 /etc/security/limits.conf보거나 실행하십시오 ulimit -n.