가끔 누군가 다음과 같은 질문을 합니다. "서비스 파일에 우리 애플리케이션 포트를 추가했는데, 이제 다른 애플리케이션이 그 포트를 사용하고 있습니다. 왜 그런가요?" 그 답은 서비스 파일이 포트 번호를 예약하지 않기 때문입니다. 서비스 파일은 애플리케이션이 getservbyname 함수를 호출하여 서비스와 연관된 포트 번호를 찾거나, getservbyport 함수를 호출하여 포트 번호와 연관된 서비스 이름을 찾을 수 있도록 존재합니다. 두 개의 서로 다른 서비스가 동일한 포트 번호에 매핑되는 것을 막을 방법은 없습니다. 다만 getservbyport 함수는 첫 번째 서비스만 반환합니다. 또한 애플리케이션이 사용해야 할 포트를 확인하기 위해 반드시 getservbyname을 호출해야 하는 것도 아닙니다. 애플리케이션 개발자는 포트 번호를 하드코딩하거나 매개변수로 입력하도록 허용할 수 있습니다.
포트 번호를 예약하는 방법은 없습니다. 해당 포트를 사용해야만 가능하며, REUSEADDR 소켓 옵션을 설정하지 않은 경우에만 가능합니다. 따라서 STCP가 시작된 후 가능한 한 빨리 애플리케이션을 시작하십시오. 다른 애플리케이션이 해당 포트를 선점하기 전에 실행해야 합니다.
때로는 문제가 다른 서버 애플리케이션이 아니라 클라이언트 애플리케이션에서 발생하기도 합니다. 대부분의 클라이언트 애플리케이션은 특정 로컬 포트에 바인딩하지 않지만, 로컬 포트가 필요하기 때문에 STCP는 동적 포트 범위(49152–65535)에서 하나를 할당합니다. 해당 애플리케이션이 이 범위 내 포트를 사용 중이라면, 등록된 범위(1024-49151)의 포트로 변경할 것을 권장합니다. 이 포트는 애플리케이션이 명시적으로 바인딩할 때만 사용됩니다.
좋습니다, 다른 애플리케이션이 여러분의 애플리케이션 포트를 사용하고 있다고 가정해 보겠습니다. 어떤 애플리케이션인지, 더 중요한 것은 누가 실행했는지 어떻게 확인할 수 있을까요? 이는 세 단계의 과정입니다:
- 명령어를 실행하십시오
“netstat -numeric -all_sockets -PCB_addr”그리고 침입자를 식별합니다. 이 경우 제가 관심 있는 포트 번호는 13592입니다.
netstat -numeric -all_sockets -PCB_addrActive connections (including servers)PCB Proto Recv-Q Send-Q Local Address Foreign Address(state). . . 8e3aa300 tcp 0 0 *:13592 *:* LISTEN. . .ready 13:50:12- 명령어를 실행하십시오
“analyze_system -request_line 'match dv; dump_onetcb 8e3aa300' -quit”
dump_onetcb 요청에 인터로퍼의 PCB(8e3aa300)를 전달합니다. 이는 소켓과 연관된 STCP 장치를 식별합니다.
OpenVOS Release 17.0.1aj, analyze_system Release 17.0.1ajCurrent process is 664, ptep 8E0EE800, Noah_Davids.CAC sth_dvtx = 121 (stcp.m16_202)- 명령어를 실행하십시오
“who_locked #stcp.m16_202”어떤 프로세스가 해당 장치를 사용하고 있는지 확인하기 위해.
stcp.m16_202: Object is write locked by Barney_Rubble.Dev (login) on module%vs#m1 executing stcp_calls.pm.
자, 이제 다 됐습니다. 이제 여러분이 해야 할 일은 이 바니 러블에게 연락하여 다른 포트 번호를 사용하도록 정중히 제안하는 것뿐입니다.