Port와 Socket 완벽 이해
Port와 Socket 완벽 이해
1. 들어가며: 서버에 접속할 때 포트는 왜 필요할까?
서버의 IP 주소를 알고 있다고 해서 모든 서비스에 접속할 수 있는 것은 아닙니다.
예를 들어 한 대의 Linux 서버에서 다음과 같은 서비스를 운영한다고 가정해 보겠습니다.
- 웹 서비스: TCP 80번 포트
- HTTPS 서비스: TCP 443번 포트
- SSH 원격 접속: TCP 22번 포트
- PostgreSQL 데이터베이스: TCP 5432번 포트
- Redis: TCP 6379번 포트
이 서비스들은 동일한 서버 IP 주소를 사용하더라도 서로 다른 포트를 통해 통신할 수 있습니다.
Client
192.168.10.100
|
|
Network / TCP
|
v
Linux Server
192.168.10.50
|
+-----------+-----------+
| | |
TCP 22 TCP 80 TCP 443
| | |
SSH HTTP HTTPS
|
+-------+-------+
| |
TCP 5432 TCP 6379
| |
PostgreSQL Redis
IP 주소가 서버를 구분하는 데 사용된다면, 포트는 해당 서버에서 어떤 통신 서비스로 데이터를 전달해야 하는지 구분하는 데 사용됩니다.
하지만 실제 네트워크 장애를 분석할 때는 포트 번호만 알아서는 부족합니다. 운영체제가 포트를 어떻게 관리하는지, 소켓이 무엇인지, 연결 상태가 어떤 의미인지까지 이해해야 합니다.
이번 글에서는 다음 내용을 살펴보겠습니다.
- Port와 Socket의 차이
- TCP·UDP 포트 번호의 범위
- 소켓 연결을 식별하는 방법
- Linux의 LISTEN, ESTABLISHED, TIME_WAIT, CLOSE_WAIT 상태
ss,lsof,fuser,tcpdump를 이용한 장애 분석- 포트 충돌과 연결 자원 고갈 문제
2. Port란 무엇인가?
Port는 TCP 또는 UDP 통신에서 애플리케이션과 통신을 구분하기 위해 사용하는 번호입니다.
TCP와 UDP의 포트 번호는 각각 16비트로 표현되므로 0부터 65535까지 사용할 수 있습니다.
[
2^{16}=65536
]
따라서 포트 번호의 전체 범위는 다음과 같습니다.
0 ~ 65535
다만 포트 번호를 사용할 때는 예약된 범위와 일반적인 운영 관례를 이해해야 합니다.
2.1 포트 번호의 주요 범위
범위명칭설명0~1023Well-known portsHTTP, HTTPS, SSH 등 대표적인 서비스1024~49151Registered ports등록된 서비스에서 사용하는 포트 범위49152~65535Dynamic/Private ports일반적으로 클라이언트의 임시 포트로 사용되는 범위
이 구분은 IANA의 포트 분류를 이해하기 위한 기준입니다. 실제 운영체제의 임시 포트 범위는 별도 설정에 따라 다를 수 있습니다.
예를 들어 Linux에서는 다음 명령어로 현재 임시 포트 범위를 확인할 수 있습니다.
sysctl net.ipv4.ip_local_port_range
출력 예시:
net.ipv4.ip_local_port_range = 32768 60999
이 경우 Linux는 일반적인 클라이언트 연결에서 로컬 임시 포트를 선택할 때 해당 범위를 활용할 수 있습니다.
중요한 점은 서버가 서비스하는 포트와 클라이언트가 임시로 사용하는 포트는 역할이 다르다는 것입니다.
2.2 서버 포트와 클라이언트 포트의 차이
클라이언트가 웹 서버에 접속한다고 가정하겠습니다.
Client Server
192.168.10.100 192.168.10.50
192.168.10.100:53124 -----> 192.168.10.50:443
임시 포트 HTTPS 포트
클라이언트의 53124는 연결을 위해 선택된 임시 포트이고, 서버의 443은 HTTPS 서비스가 사용하는 포트입니다.
서버가 응답할 때는 반대 방향으로 패킷이 전달됩니다.
192.168.10.50:443 -----> 192.168.10.100:53124
따라서 패킷을 분석할 때 출발지 포트와 목적지 포트를 혼동하면 안 됩니다.
예를 들어 다음 명령어는 서버의 TCP 443번 포트로 향하는 패킷을 확인합니다.
tcpdump -nn -i any 'tcp dst port 443'
반대로 서버의 TCP 443번 포트에서 출발하는 패킷은 다음과 같이 확인할 수 있습니다.
tcpdump -nn -i any 'tcp src port 443'
여기서 dst는 목적지, src는 출발지를 의미합니다.
3. Socket이란 무엇인가?
Port가 통신 서비스를 구분하는 번호라면, Socket은 운영체제가 네트워크 통신의 한쪽 끝점을 관리하기 위해 사용하는 개념입니다.
소켓은 단순히 포트 번호 하나를 의미하지 않습니다. 애플리케이션이 네트워크 데이터를 송수신할 수 있도록 운영체제가 제공하는 통신 인터페이스이며, 실제 연결에는 프로토콜과 주소 정보 등이 함께 사용됩니다.
일반적으로 TCP 연결을 식별할 때는 다음 네 가지 정보를 사용합니다.
- 출발지 IP 주소
- 출발지 포트 번호
- 목적지 IP 주소
- 목적지 포트 번호
여기에 TCP 또는 UDP 같은 프로토콜 정보가 결합됩니다.
Protocol : TCP Source IP: 192.168.10.100 Source Port: 53124 Destination IP: 192.168.10.50 Destination Port: 443
이 정보를 흔히 5-tuple이라고 부릅니다.
TCP
192.168.10.100:53124
|
v
192.168.10.50:443
3.1 같은 서버 포트로 여러 사용자가 접속할 수 있는 이유
웹 서버가 TCP 443번 포트에서 서비스를 제공한다고 가정하겠습니다.
Client A: 192.168.10.100:53124
Client B: 192.168.10.101:53125
Client C: 192.168.10.102:53126
|
v
Server:443
세 클라이언트는 모두 동일한 서버의 443번 포트로 접속합니다.
하지만 출발지 IP 주소와 포트가 서로 다르므로 각 TCP 연결을 구분할 수 있습니다.
따라서 서버의 443번 포트가 하나라고 해서 동시 접속자도 한 명으로 제한되는 것은 아닙니다.
다만 실제 동시 접속 처리량은 애플리케이션의 구현, 파일 디스크립터 한도, 메모리, CPU, 커널 설정 등에 영향을 받습니다.
3.2 LISTEN 소켓과 연결 소켓
TCP 서버는 일반적으로 다음 과정을 거칩니다.
- 소켓을 생성합니다.
- IP 주소와 포트에 소켓을 연결합니다.
- 연결 요청을 받을 수 있도록 대기합니다.
- 클라이언트의 연결 요청을 수락합니다.
- 연결된 클라이언트와 데이터를 송수신합니다.
이를 개념적으로 표현하면 다음과 같습니다.
TCP Server
|
v
Socket 생성
|
v
bind(IP, Port)
|
v
listen()
|
v
LISTEN 소켓
|
| 클라이언트 연결 요청
v
accept()
|
v
연결된 소켓
|
v
데이터 송수신
여기서 LISTEN 소켓과 연결된 소켓은 역할이 다릅니다.
- LISTEN 소켓: 새로운 연결 요청을 기다립니다.
- 연결된 소켓: 특정 클라이언트와 실제 데이터를 주고받습니다.
따라서 ss 명령어에서 LISTEN과 ESTABLISHED가 함께 표시되는 것은 정상적인 상황입니다.
4. Linux에서 포트와 소켓 확인하기
시스템 엔지니어가 가장 자주 사용하는 명령어 중 하나는 ss입니다.
4.1 LISTEN 중인 TCP·UDP 포트 확인
ss -lntup
주요 옵션은 다음과 같습니다.
옵션의미-l대기 중인 소켓-n이름 대신 숫자로 표시-tTCP-uUDP-p관련 프로세스 표시
출력 예시:
Netid State Local Address:Port Peer Address:Port Process
tcp LISTEN 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=1200,fd=3))
tcp LISTEN 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=1500,fd=6))
tcp LISTEN 0.0.0.0:443 0.0.0.0:* users:(("nginx",pid=1500,fd=7))
tcp LISTEN 127.0.0.1:5432 0.0.0.0:* users:(("postgres",pid=1700,fd=5))
이 결과를 보면 다음과 같이 해석할 수 있습니다.
- SSH는 모든 IPv4 인터페이스에서 대기하고 있습니다.
- Nginx는 모든 IPv4 인터페이스에서 HTTP와 HTTPS 요청을 받을 수 있도록 대기하고 있습니다.
- PostgreSQL은
127.0.0.1에서만 대기하고 있습니다.
마지막 항목은 특히 중요합니다. PostgreSQL이 실행 중이어도 외부 서버에서는 직접 접속할 수 없는 설정일 수 있습니다.
단, 실제 외부 접속 가능 여부는 방화벽, 라우팅, 보안 정책, 서비스 설정 등을 함께 확인해야 합니다.
4.2 현재 TCP 연결 확인
ss -ant
프로세스 정보까지 확인하려면 다음 명령어를 사용합니다.
ss -antp
특정 포트만 확인할 수도 있습니다.
ss -lntp '( sport = :443 )'
443번 포트를 사용하는 연결을 확인하려면 다음과 같이 실행합니다.
ss -ant '( sport = :443 or dport = :443 )'
ss의 필터 표현식은 소켓 상태와 주소 정보를 조건으로 좁혀 볼 때 유용합니다.
4.3 특정 포트를 사용하는 프로세스 확인
lsof가 설치되어 있다면 다음 명령어를 사용할 수 있습니다.
lsof -nP -iTCP:8080 -sTCP:LISTEN
fuser로 TCP 8080번 포트를 사용하는 프로세스도 확인할 수 있습니다.
fuser -v -n tcp 8080
다만 lsof와 fuser는 시스템에 설치되어 있지 않을 수 있습니다. 권한에 따라서 프로세스 정보가 일부 표시되지 않을 수도 있습니다.
5. TCP 소켓 상태 이해하기
네트워크 장애를 분석하려면 TCP 연결 상태를 이해해야 합니다.
5.1 LISTEN
서버가 클라이언트의 연결 요청을 기다리는 상태입니다.
tcp LISTEN 0 4096 0.0.0.0:8080 0.0.0.0:*
서비스가 정상적으로 대기 중인지 확인하려면 다음 명령어를 사용합니다.
ss -lntp | grep ':8080'
출력이 없다면 다음 가능성을 검토해야 합니다.
- 서비스가 실행되지 않았습니다.
- 서비스가 다른 포트를 사용합니다.
- 서비스가 다른 IP 주소에만 바인딩되어 있습니다.
- 권한 부족이나 설정 오류로 포트 개설에 실패했습니다.
5.2 ESTABLISHED
TCP 연결이 수립되어 데이터 송수신이 가능한 상태입니다.
tcp ESTAB 0 0 192.168.10.50:443 192.168.10.100:53124
이 상태가 보인다고 해서 애플리케이션까지 정상이라는 뜻은 아닙니다. TCP 연결이 성립했더라도 애플리케이션이 응답하지 않거나 데이터 처리에서 지연이 발생할 수 있습니다.
5.3 SYN-SENT
클라이언트가 연결 요청인 SYN 패킷을 전송한 후 응답을 기다리는 상태입니다.
Client Server | | | -------- SYN --------------> | | | | 응답 대기 중 |
SYN-SENT가 오래 유지된다면 다음을 확인해야 합니다.
- 목적지 IP와 포트가 정확한가?
- 서버가 실행 중인가?
- 중간 방화벽에서 SYN 또는 응답 패킷을 차단하는가?
- 서버의 응답이 클라이언트로 돌아오는 경로가 정상인가?
ss -ant state syn-sent
5.4 SYN-RECV
서버가 SYN을 받고 SYN-ACK를 전송한 뒤 마지막 ACK를 기다리는 상태입니다.
Client Server | | | -------- SYN --------------> | | <------ SYN-ACK ------------ | | | | 마지막 ACK 대기 |
다음 명령어로 확인할 수 있습니다.
ss -ant state syn-recv
이 상태가 비정상적으로 많이 누적된다면 클라이언트의 마지막 ACK가 도달하지 못하는 상황, 네트워크 문제 또는 SYN 관련 공격 가능성 등을 검토할 수 있습니다. 다만 상태가 많다는 사실만으로 공격이라고 단정해서는 안 됩니다.
5.5 TIME_WAIT
TCP 연결 종료 과정에서 나타나는 상태입니다.
Client Server | | | -------- FIN --------------> | | <------- ACK --------------- | | <------- FIN --------------- | | -------- ACK --------------> | | | | TIME_WAIT |
TIME_WAIT는 TCP 연결 종료 후 지연된 패킷이 새로운 연결에 혼동을 일으키지 않도록 하는 데 중요한 역할을 합니다.
따라서 TIME_WAIT가 많다고 해서 무조건 장애는 아닙니다.
짧은 시간에 연결을 많이 생성하고 종료하는 애플리케이션에서는 TIME_WAIT가 많이 보일 수 있습니다.
ss -ant state time-wait
TIME_WAIT가 많다면 우선 다음을 확인합니다.
- 애플리케이션이 연결을 지나치게 자주 생성하는가?
- HTTP Keep-Alive 또는 연결 풀을 적절히 활용하는가?
- 특정 클라이언트나 목적지로 연결이 집중되는가?
- 임시 포트 범위와 연결 생성량이 적절한가?
TIME_WAIT를 줄이기 위해 커널 값을 무작정 변경하는 것은 권장하지 않습니다. 원인과 부작용을 검토한 뒤 조정해야 합니다.
5.6 CLOSE_WAIT
상대방이 연결 종료를 요청했지만, 로컬 애플리케이션이 소켓을 닫지 않은 상태입니다.
Remote Client Local Server
| |
| -------- FIN ------------> |
| <------- ACK ------------- |
| |
| CLOSE_WAIT
| |
| 애플리케이션이
| 소켓을 닫아야 함
확인 명령어:
ss -ant state close-wait
CLOSE_WAIT가 계속 증가하고 사라지지 않는다면 애플리케이션이 소켓을 적절하게 닫지 않는 문제를 의심할 수 있습니다.
특히 특정 프로세스에서 CLOSE_WAIT가 지속적으로 누적되는지 확인하는 것이 중요합니다.
ss -antp state close-wait
TIME_WAIT와 CLOSE_WAIT는 다릅니다.
항목TIME_WAITCLOSE_WAIT의미종료 후 일정 시간 유지상대방의 종료 요청을 받았으나 로컬 종료 미완료일반적인 발생정상적인 TCP 종료 과정애플리케이션의 소켓 종료 지연 가능대응연결 생성 패턴과 자원 사용 확인프로세스와 애플리케이션의 종료 처리 확인
6. UDP 소켓은 TCP와 어떻게 다를까?
UDP는 TCP처럼 연결 수립을 위한 3-Way Handshake를 수행하지 않습니다.
따라서 UDP 소켓은 일반적으로 TCP의 LISTEN, ESTABLISHED와 같은 상태 모델로 해석하지 않습니다.
예를 들어 DNS 서비스가 UDP 53번 포트를 사용한다면 다음 명령어로 확인할 수 있습니다.
ss -lunp
UDP 포트가 표시되어도 상대방과 실제 데이터가 정상적으로 오간다는 뜻은 아닙니다. 패킷이 도달하는지, 서비스가 응답하는지 별도로 확인해야 합니다.
패킷 확인 예시:
tcpdump -nn -i any 'udp port 53'
DNS 질의가 서버에 도착하는데 응답이 없다면 방화벽, DNS 서비스 설정, 애플리케이션 로그 등을 추가로 확인해야 합니다.
7. 서비스가 실행 중인데 외부에서 접속되지 않는 이유
실무에서 자주 발생하는 문제입니다.
예를 들어 FastAPI 서비스가 TCP 8000번 포트에서 실행되고 있다고 가정하겠습니다.
ss -lntp | grep ':8000'
결과:
tcp LISTEN 0 2048 127.0.0.1:8000 0.0.0.0:*
이 경우 서비스는 로컬 루프백 주소에서만 대기합니다.
서버 내부에서는 다음 요청이 성공할 수 있습니다.
curl http://127.0.0.1:8000/
하지만 다른 PC에서 서버의 실제 IP 주소로 접속하면 실패할 수 있습니다.
curl http://192.168.10.50:8000/
외부 인터페이스에서 접속을 받아야 하는 서비스라면 애플리케이션이 적절한 주소에 바인딩되어 있는지 확인해야 합니다.
예를 들어 Uvicorn을 실행할 때는 다음과 같이 설정할 수 있습니다.
uvicorn main:app --host 0.0.0.0 --port 8000
여기서 0.0.0.0은 IPv4의 모든 로컬 인터페이스를 의미합니다. 이는 외부 접속을 자동으로 보장하는 설정이 아닙니다. 방화벽과 라우팅, 보안 정책도 함께 확인해야 합니다.
7.1 바인딩 주소의 의미
주소의미127.0.0.1IPv4 루프백 인터페이스192.168.10.50해당 로컬 IP 주소0.0.0.0모든 로컬 IPv4 인터페이스::1IPv6 루프백 주소::IPv6 와일드카드 주소. IPv4 매핑 연결 처리는 시스템 설정에 따라 다를 수 있음
보안상 데이터베이스나 관리자 전용 서비스는 꼭 필요한 인터페이스에만 바인딩하는 것이 좋습니다.
8. 포트 충돌: Address already in use
새로운 서비스를 기동할 때 다음과 같은 오류가 발생할 수 있습니다.
OSError: [Errno 98] Address already in use
이는 요청한 주소와 포트를 현재 소켓이 사용 중이거나, 해당 바인딩을 허용하지 않는 소켓 설정이 존재할 때 발생할 수 있습니다.
예를 들어 TCP 8080번 포트를 이미 사용하는 서비스가 있다면 다른 애플리케이션이 같은 주소와 포트 조합으로 대기하려 할 때 충돌할 수 있습니다.
8.1 점검 순서
먼저 포트를 사용하는 프로세스를 확인합니다.
ss -lntp '( sport = :8080 )'
필요하면 lsof로도 확인합니다.
lsof -nP -iTCP:8080 -sTCP:LISTEN
프로세스가 확인되면 다음을 판단합니다.
- 기존 서비스가 정상적으로 운영 중인가?
- 동일 서비스를 중복 기동하려고 하는가?
- 설정 파일에서 포트가 잘못 지정되었는가?
- 기존 서비스를 종료해도 업무 영향이 없는가?
서비스 관리자가 운영하는 프로세스라면 무작정 kill -9를 실행하지 마십시오.
먼저 서비스 관리 명령으로 정상 종료를 시도하고, 서비스 의존성과 업무 영향을 확인해야 합니다.
예를 들어 systemd 서비스라면 다음과 같습니다.
systemctl status myapp systemctl stop myapp
서비스 이름과 종료 방법은 실제 환경에 맞게 사용해야 합니다.
9. 연결이 많아질 때 발생하는 자원 문제
포트와 소켓 문제는 단순한 포트 충돌에서 끝나지 않습니다. 연결이 급격하게 증가하면 운영체제와 애플리케이션의 자원이 부족해질 수 있습니다.
9.1 임시 포트 고갈
클라이언트가 원격 서버에 연결할 때 로컬 임시 포트를 사용합니다.
Client: 임시 포트 -> Server: 서비스 포트
같은 출발지 IP와 목적지 IP·포트, 프로토콜 조합에서 사용 가능한 임시 포트가 부족하면 새로운 연결 생성에 문제가 생길 수 있습니다.
현재 임시 포트 범위는 다음과 같이 확인합니다.
sysctl net.ipv4.ip_local_port_range
하지만 포트 범위만 넓히는 것이 정답은 아닙니다. 연결 생성량, 연결 재사용, 목적지별 연결 집중, NAT 사용 여부 등을 함께 살펴야 합니다.
9.2 파일 디스크립터 한도
Linux에서 소켓은 프로세스가 사용하는 파일 디스크립터와 연결됩니다.
프로세스가 허용된 파일 디스크립터 한도에 도달하면 새 연결을 처리하지 못할 수 있습니다.
현재 셸의 한도를 확인합니다.
ulimit -n
특정 프로세스의 한도는 다음과 같이 확인할 수 있습니다.
cat /proc/<PID>/limits
여기서 <PID>는 실제 프로세스 ID로 바꿔야 합니다.
서비스가 연결을 수용하지 못한다면 다음 항목을 함께 점검합니다.
- 프로세스의 파일 디스크립터 한도
- 실제 열린 파일과 소켓 수
- 애플리케이션의 연결 풀 설정
- 데이터베이스의 최대 연결 수
- CPU와 메모리 사용량
- 커널 및 애플리케이션 로그
9.3 소켓 상태 통계 확인
ss -s
이 명령어는 소켓 상태별 통계를 간략하게 보여 줍니다.
특정 상태가 증가했다는 사실만으로 원인을 확정할 수는 없습니다. 정상적인 트래픽 증가인지, 애플리케이션 오류인지, 네트워크 문제인지 시간대별 변화와 프로세스 정보를 함께 비교해야 합니다.
10. 실전 장애 분석: 접속은 실패하지만 서버는 정상으로 보이는 상황
다음과 같은 상황을 가정하겠습니다.
- 서버 IP:
192.168.10.50 - 서비스 포트: TCP 8080
- 클라이언트 IP:
192.168.10.100 - 서버에서 서비스 프로세스는 실행 중
1단계: 서버에서 포트 확인
ss -lntp '( sport = :8080 )'
LISTEN 상태가 없다면 서비스 기동 상태와 설정을 확인합니다.
2단계: 서버 내부에서 접속 확인
curl -v --connect-timeout 3 http://127.0.0.1:8080/
이 요청이 실패하면 서비스 자체, 바인딩 주소 또는 로컬 통신 문제를 확인합니다.
3단계: 서버의 실제 IP로 접속 확인
curl -v --connect-timeout 3 http://192.168.10.50:8080/
루프백 주소로는 성공하지만 실제 IP로는 실패한다면 바인딩 주소와 인터페이스 구성을 확인합니다.
4단계: 클라이언트에서 포트 연결 확인
클라이언트에서 실행합니다.
nc -zv -w 3 192.168.10.50 8080
연결 실패 시 서비스 바인딩, 방화벽, 네트워크 경로를 점검합니다.
5단계: 서버에서 패킷 확인
tcpdump -nn -i any 'tcp port 8080'
클라이언트에서 다시 연결을 시도하면서 패킷 흐름을 관찰합니다.
패킷 관찰 결과우선 확인할 항목서버에 SYN이 도착하지 않음클라이언트 경로, 중간 방화벽, 목적지 IPSYN은 도착하지만 SYN-ACK가 없음서비스 LISTEN, 로컬 방화벽, 커널 상태SYN-ACK가 나가지만 클라이언트 응답이 없음리턴 경로, 중간 장비, 클라이언트 방화벽3-Way Handshake 성공 후 응답이 없음애플리케이션 처리, 프록시, 백엔드 로그연결 후 RST가 발생함연결 종료 주체, 서비스 동작, 프로토콜 불일치
이 표는 원인을 확정하는 규칙이 아니라 다음 점검 지점을 좁히는 기준입니다. 실제 패킷 방향과 양쪽 호스트의 캡처를 비교하면 원인을 더 정확하게 찾을 수 있습니다.
11. 시스템 엔지니어를 위한 Port·Socket 점검 체크리스트
서버 접속 장애가 발생하면 다음 순서로 확인하는 습관을 들이는 것이 좋습니다.
1. 대상 IP와 포트가 정확한가?
|
v
2. 서비스 프로세스가 실행 중인가?
|
v
3. 해당 포트에서 LISTEN 중인가?
|
v
4. 올바른 IP 주소에 바인딩되어 있는가?
|
v
5. 로컬에서 curl 또는 nc로 접속 가능한가?
|
v
6. 방화벽과 네트워크 경로는 정상인가?
|
v
7. tcpdump에서 SYN/SYN-ACK/ACK가 보이는가?
|
v
8. TCP 연결 이후 애플리케이션이 응답하는가?
자주 사용하는 명령어를 정리하면 다음과 같습니다.
목적명령어TCP·UDP LISTEN 확인ss -lntupTCP 연결 확인ss -antpTIME_WAIT 확인ss -ant state time-waitCLOSE_WAIT 확인ss -ant state close-waitSYN-SENT 확인ss -ant state syn-sent포트 사용 프로세스 확인lsof -nP -iTCP:8080 -sTCP:LISTEN포트 연결 테스트nc -zv -w 3 서버IP 포트HTTP 응답 확인curl -v URL패킷 흐름 확인tcpdump -nn -i any 'tcp port 8080'임시 포트 범위 확인sysctl net.ipv4.ip_local_port_range소켓 통계 확인ss -s
명령어를 실행할 때는 운영 서버에 불필요한 부하를 주지 않도록 주의하고, 프로세스 종료나 커널 파라미터 변경은 원인을 확인한 뒤 수행해야 합니다.
12. 마무리
이번 편에서는 Port와 Socket의 차이, TCP·UDP 포트 번호, 소켓 연결 식별 방식, Linux TCP 상태, 포트 충돌 및 연결 자원 문제를 살펴봤습니다.
핵심은 다음과 같습니다.
- Port는 통신 서비스와 연결을 구분하는 번호입니다.
- Socket은 애플리케이션의 네트워크 통신을 위한 인터페이스이자 통신 끝점입니다.
- TCP 연결은 일반적으로 프로토콜과 출발지·목적지 IP 및 포트의 조합으로 식별됩니다.
- LISTEN은 연결 대기, ESTABLISHED는 연결 수립, TIME_WAIT는 종료 후 대기, CLOSE_WAIT는 상대방 종료 요청 후 로컬 종료를 기다리는 상태입니다.
- 포트가 열려 있어도 바인딩 주소, 방화벽, 라우팅, 애플리케이션 상태에 따라 외부 접속이 실패할 수 있습니다.
- TIME_WAIT가 많다고 무조건 장애는 아니며, CLOSE_WAIT가 지속적으로 누적된다면 애플리케이션의 소켓 종료 처리를 확인해야 합니다.
시스템 엔지니어는 단순히 포트가 열려 있는지만 확인하는 데서 멈추면 안 됩니다. 연결 상태와 패킷 흐름, 프로세스 상태를 함께 확인해야 실제 장애 원인을 좁힐 수 있습니다.
다음 편에서는 Linux 방화벽과 iptables/nftables를 다룹니다. 서버에서 서비스가 정상적으로 LISTEN 중인데도 외부 접속이 실패하는 상황을 중심으로, 방화벽 규칙과 패킷 필터링이 통신에 어떤 영향을 주는지 살펴보겠습니다.
다음 편에서는 firewall-cmd, nft, iptables의 차이와 규칙 확인·추가·삭제, 포트 차단 장애 분석, 운영 서버에서 방화벽 규칙을 안전하게 변경하는 방법을 이어서 다루면 됩니다.
댓글
아직 댓글이 없습니다.
로그인 후 댓글을 남길 수 있습니다.