조회수: 0
리눅스에서 네트워크 문제를 분석하다 보면 가장 먼저 묻게 되는 질문은 두 가지다. 특정 포트에 실제로 서비스가 떠 있는지, 그리고 그 포트를 잡고 있는 프로세스가 무엇인지다. 예전에는 netstat가 이런 작업의 표준 도구였지만, 최근 배포판에서는 ss가 더 빠르고 자세한 정보를 제공하는 기본 도구로 자리를 잡았다.
ss 명령은 커널의 소켓 정보를 직접 읽어오기 때문에 많은 연결이 존재하는 서버에서도 비교적 빠르게 결과를 돌려준다. 단순히 포트가 열렸는지 확인하는 수준을 넘어, 연결 상태와 프로세스, 바인딩 주소를 조합해 포트 바인딩 상황을 정밀하게 추적할 수 있다.
목차
ss 명령이 필요한 이유
네트워크 분석 도구는 이미 여러 가지가 있는데 굳이 ss를 써야 하는 이유는 무엇일까. 크게 세 가지 정도로 정리해 볼 수 있다.
- 속도
- 수천 개 이상 연결이 열린 서버에서도 비교적 빠르게 결과를 출력한다
- 정보량
- 프로세스 정보, 큐 크기, 상태 등 다양한 필드를 한 번에 확인할 수 있다
- 유지 관리
- 많은 배포판에서 netstat보다 ss 사용을 권장하며 패키지 기본 설치에 포함한다
실제 운영 서버를 다루다 보면 단순하게 열린 포트를 보여주는 도구만으로는 부족하다. 연결 상태별 통계, 포트별 접속 수, 특정 프로세스가 쓰는 포트 목록처럼 조금만 깊게 들어가도 ss가 훨씬 유용하다.
기본 옵션으로 전체 구조 이해하기
ss 명령의 기본 문법은 매우 간단하다.
ss 옵션
자주 사용하는 옵션을 먼저 정리해 두면 이후 응용이 훨씬 수월하다.
- l 리스닝 소켓만 표시
- t TCP 소켓만 표시
- u UDP 소켓만 표시
- n 이름 해석을 생략하고 숫자 그대로 출력
- p 포트를 점유한 프로세스 정보 표시
- a 리스닝 소켓과 비리스닝 소켓을 모두 표시
- s 소켓 통계를 요약해서 표시
보통은 여러 옵션을 조합해 사용한다. 예를 들어 TCP 리스닝 소켓 전체를 보고 싶다면 다음처럼 입력한다.
ss -ltn
이 명령 하나만으로 현재 시스템에서 열려 있는 모든 TCP 리스닝 포트 목록을 빠르게 얻을 수 있다.
특정 포트를 누가 쓰는지 확인하기
실무에서 가장 자주 쓰는 패턴은 특정 포트를 잡고 있는 프로세스가 무엇인지 확인하는 작업이다. 예를 들어 웹 서버 포트를 누가 점유하고 있는지 확인해 보자.
ss -ltnp
위 명령은 다음 정보를 한 번에 보여준다.
- 리스닝 상태인 TCP 소켓만
- 숫자 형태의 포트 번호
- 해당 소켓을 연 프로세스와 PID
여기서 필요하다면 간단히 grep을 조합해 특정 포트만 골라볼 수 있다.
ss -ltnp | grep 80
이렇게 하면 포트 80을 리스닝 중인 소켓과 관련 프로세스 정보만 추려볼 수 있다. 만약 이미 그 포트에 다른 프로세스가 바인딩되어 있다면 웹 서버가 기동되지 않는 이유를 바로 파악할 수 있다.
포트 바인딩 충돌 문제 해결 흐름
새로운 서비스나 컨테이너를 띄울 때 포트 이미 사용 중이라는 오류를 만나는 일은 흔하다. 이때 ss를 이용한 기본적인 문제 해결 흐름은 다음과 같다.
- 포트 리스닝 여부 확인
ss -ltn | grep 8080 - 포트를 사용하는 프로세스 확인
ss -ltnp | grep 8080 - 해당 프로세스의 역할 파악
- ps 명령이나 서비스 관리 도구를 이용해 실제 서비스 이름과 설정 위치 확인
- 포트 재설정 또는 프로세스 중지 결정
- 기존 서비스를 다른 포트로 옮길지
- 새로 띄우려는 서비스를 다른 포트로 구성할지 선택
이 간단한 흐름만 익혀도 포트 충돌로 인한 장애 원인 파악 시간이 크게 줄어든다.
로컬 바인딩과 원격 바인딩 구분하기
포트가 열려 있는 것과 외부에서 접속 가능한 것은 다른 문제다. 예를 들어 서비스가 루프백 주소에만 바인딩되어 있다면 같은 서버 내부에서만 접속이 가능하고 외부에서는 연결할 수 없다.
ss는 포트뿐 아니라 바인딩된 로컬 주소도 보여주기 때문에 이 부분을 함께 확인해야 한다.
- 특정 인터페이스에만 바인딩된 경우
- 루프백만 허용하고 외부는 막아 둔 경우
- 모든 주소에 바인딩된 경우
예를 들어 다음과 같은 방식으로 특정 포트를 사용하는 모든 소켓을 출력해 보면 바인딩 주소를 한 눈에 확인할 수 있다.
ss -ltn
출력 결과에서 로컬 주소 부분을 보면 해당 서비스가 전체 인터페이스에 열려 있는지, 특정 주소에만 제한되어 있는지 구분할 수 있다. 외부에서 접속이 안 되는 문제를 만났을 때 방화벽을 보기 전에 먼저 바인딩 주소부터 확인해 보는 습관이 중요하다.
UDP 포트 바인딩 확인하기
TCP와 달리 UDP는 연결 상태 개념이 없지만, 바인딩된 포트 목록은 그대로 확인할 수 있다. DNS 서버나 각종 에이전트가 UDP를 많이 사용한다.
UDP 리스닝 소켓만 보고 싶다면 다음처럼 입력한다.
ss -lun
여기서도 p 옵션을 함께 사용하면 어떤 프로세스가 해당 UDP 포트를 사용하는지 확인할 수 있다.
ss -lunp
UDP 기반 서비스가 포트 충돌을 일으키는 경우도 있기 때문에, TCP와 함께 UDP 포트도 주기적으로 점검해 두면 좋다.
연결 상태별로 포트 바인딩 분석하기
리스닝 소켓만 보는 것에서 한 걸음 더 나아가, 실제 연결 상태별로 바인딩 상황을 분석할 수도 있다. 특히 대규모 접속을 처리하는 웹 서버나 프록시 서버에서는 연결 수가 포화 상태에 가까운지 확인하는 것이 중요하다.
현재 모든 TCP 연결을 상태와 함께 보고 싶다면 다음처럼 입력한다.
ss -tan
이 결과를 기반으로 다음과 같은 분석을 할 수 있다.
- ESTAB 상태가 과도하게 많은지
- SYN RECV가 많아 반개방 연결이 누적되고 있는지
- TIME WAIT가 많아 포트 재사용에 영향을 주는지
포트 바인딩 자체뿐 아니라 연결 수와 상태까지 함께 살펴보면 단순 포트 점유 문제인지, 서버 자체가 과부하 상태인지 구분하는 데 도움이 된다.
통계 모드로 전체적인 감각 잡기
상세한 목록만 보면서 문제를 파악하는 데에는 한계가 있다. 이럴 때 ss의 통계 모드가 유용하다.
ss -s
이 명령을 실행하면 프로토콜별 소켓 수와 상태별 통계가 간단히 요약되어 나온다. 예를 들어 TCP 소켓이 전체적으로 몇 개나 열려 있는지, 그중 리스닝과 비리스닝이 각각 얼마나 되는지 한 번에 파악할 수 있다.
장애 대응 상황에서는 먼저 ss -s로 전체적인 규모와 상태를 확인하고, 그다음 특정 포트와 프로세스를 집중적으로 보는 방식으로 접근하면 시간을 절약할 수 있다.
실무에서 자주 쓰는 ss 명령 조합
정리 차원에서 실제 서버 운영 중 자주 쓰이는 조합을 몇 가지 모아 보자.
현재 열려 있는 TCP 리스닝 포트 전체 확인
ss -ltn
특정 포트를 사용하는 프로세스 확인
ss -ltnp | grep 443
모든 TCP 연결 목록 확인
ss -tan
현재 연결 통계 요약 확인
ss -s
UDP 리스닝 포트와 프로세스 확인
ss -lunp
이 정도만 손에 익어도 포트 바인딩 문제의 대부분은 몇 번의 명령으로 윤곽을 잡을 수 있다.
마무리 정리
ss 명령은 리눅스에서 포트 바인딩과 네트워크 연결 상태를 분석하는 데 사실상 표준 도구로 자리 잡았다. 단순히 포트가 열려 있는지 여부를 넘어서 어떤 프로세스가 어느 주소에 바인딩되어 있는지, 연결 상태가 어떤 분포를 보이는지까지 한 번에 확인할 수 있다.
포트 충돌로 신규 서비스가 뜨지 않는 문제, 외부에서는 접속이 안 되는 문제, 연결 수가 누적되어 성능이 떨어지는 문제까지 대부분의 네트워크 초기 분석은 ss 몇 줄이면 충분하다.
운영 환경에서 자주 사용하는 옵션 조합을 익혀 두고, 문제 상황이 아닐 때도 가볍게 ss 출력 결과를 들여다보는 습관을 들이면 포트 바인딩과 네트워크 상태를 읽는 눈이 빠르게 늘어난다.