Unix 시스템에서는 일반적으로 경로 이름에 길이 제한이 없습니다(Linux에서는 4096자). 길이 제한이 있는 소켓 파일 경로는 제외됩니다.약 100자(107자리눅스).
- 첫 번째 질문:한도가 왜 이렇게 낮나요?
확인해 본 결과 현재 작업 디렉터리를 변경하고 각 디렉터리에서 동일한 경로를 사용하여 여러 개의 소켓 파일을 생성하면 이 제한 사항을 해결할 수 있는 것 같습니다 . ./myfile.sock클라이언트 응용 프로그램은 예상된 서버 프로세스에 올바르게 연결되는 것 같습니다. lsof동일한 소켓 파일 경로.
- 이 솔루션은 신뢰할 수 있나요? 아니면 운이 좋은 걸까요?
- 이 동작은 Linux에만 해당됩니까, 아니면 이 해결 방법이 다른 Unix에도 적용됩니까?
답변1
snprintf()및 를 사용할 때 오버플로를 방지하기 위해 다른 플랫폼과의 호환성 또는 이전 버전과의 호환성 strncpy().
마이클 케리스크가 설명하다그의 책존재하다페이지 1165- 57장, 소켓: Unix 도메인:
SUSv3은 sun_path 필드의 크기를 지정하지 않습니다. 초기 BSD 구현에서는 108바이트와 104바이트를 사용했지만 최신 구현(HP-UX 11)에서는 92바이트를 사용했습니다. 이식 가능한 응용 프로그램은 이 낮은 값으로 코딩하고 snprintf() 또는 strncpy()를 사용하여 이 필드에 쓸 때 버퍼 오버플로를 방지해야 합니다.
Docker 사람들은 일부 소켓의 길이가 110자이기 때문에 이를 비웃기도 합니다.
이것이 LINUX가 108개의 문자 소켓을 사용하는 이유입니다. 이것이 바뀔 수 있습니까? 틀림없이. 이것이 바로 이전 운영 체제에서 처음에 이 제한 사항이 만들어진 이유입니다.
답변을 인용하자면:
편리한 커널 데이터 구조에서 사용 가능한 공간을 일치시키려는 의도입니다.
McKusick 등의 "4.4BSD 운영 체제의 설계 및 구현"을 인용하십시오. 외. (페이지 369):
메모리 관리 기능은 mbufs라는 데이터 구조를 중심으로 이루어집니다. Mbuf, 즉 메모리 버퍼의 길이는 128바이트이며, 그 중 100 또는 108바이트는 데이터 저장용으로 예약되어 있습니다.
기타 운영 체제(Unix 도메인 소켓):
- 오픈BSD: 104자
- FreeBSD: 104자
- 맥 OS X 10.9: 104자
답변2
그 이유에 대해 nwildner는 기사를 작성했습니다.좋은 대답.
여기서는 이를 사용하는 방법과 상대 경로의 사용에만 중점을 둡니다.
내부적으로 소켓 파일은 일반적으로 inode로 조회되지만 이름으로 조회할 수도 있습니다. Linux에서 이 조회는 unix_find_socket_byinode()다음에 정의되어 있습니다.넷/유닉스/af_unix.c.
이는 다음과 같이 쉽게 확인할 수 있습니다.
- 두 개의 디렉터리를 생성합니다.ㅏ/그리고두번째/.
- 각 디렉토리 아래에서 동일한 이름을 가진 소켓 파일을 수신 대기하는 프로세스를 갖습니다. 그리고
socat다음 명령을 사용할 수 있습니다.
$ socat UNIX-LISTEN:./my.sock -
- 소켓 파일은 이제 이동하여 교환됩니다.A/my.sock도착하다두번째/그 반대.
- 이제부터 클라이언트 애플리케이션에 연결하면A/my.sock서버에 접속합니다두번째, 다음에 연결된 경우B/my.sock서버에 접속합니다ㅏ(그러나 통신이 끝나면 서버 프로세스는 자체 소켓 파일의 내용으로 간주되는 것을 합법적으로 삭제할 수 있습니다.)
나는 몇몇 Unix 시스템(일부 다양한 경우 Linux Debian, FreeBSD 및 OpenIndiana)에서 이 동작을 확인했습니다. 따라서 표준은 아니지만 이 동작은 적어도 널리 퍼져 있습니다.
절대 경로는 클라이언트 프로세스가 서버와의 초기 통신을 설정하는 방법을 알 수 없기 때문에 클라이언트와 서버 프로세스 간의 규칙으로 자주 사용됩니다.
그러나 이 초기 통신이 문제가 되지 않는다면 상대 경로를 사용하여 소켓 파일을 생성하는 것이 안전한 것으로 보입니다. 따라서 서버 프로세스에서 소켓 파일 위치를 직접 제어하지 않을 때 경로 길이 문제를 피할 수 있습니다.