TCP와 UDP, Port와 Socket, TCP 3-Way Handshake의 실제 패킷 구조
시스템 엔지니어를 위한 네트워크 9편
TCP와 UDP, Port와 Socket, TCP 3-Way Handshake의 실제 패킷 구조
서버 엔지니어가 네트워크 장애를 분석하다 보면 다음과 같은 상황을 자주 만나게 된다.
Ping은 정상이다. 그런데 SSH 접속이 안 된다. Ping은 정상이다. 그런데 8080 포트 접속이 안 된다. Port는 LISTEN 상태다. 그런데 외부에서 접속이 안 된다. TCP 연결이 간헐적으로 끊긴다. SYN 패킷은 들어오는데 연결이 성립되지 않는다.
이런 문제를 정확하게 분석하려면 단순히 ping이나 nc 명령어를 사용하는 것만으로는 부족하다.
이번에는 네트워크의 핵심인 TCP와 UDP, Port와 Socket, 그리고 TCP 3-Way Handshake를 실제 패킷 구조까지 내려가서 살펴본다.
1. TCP와 UDP는 왜 존재하는가?
IP는 기본적으로 목적지까지 패킷을 전달하는 역할을 한다.
하지만 IP만으로는 다음과 같은 기능을 제공하지 않는다.
- 데이터가 제대로 도착했는가?
- 순서가 뒤바뀌지는 않았는가?
- 데이터가 손실되지는 않았는가?
- 상대방이 데이터를 받을 준비가 되었는가?
- 어떤 서버 프로그램으로 데이터를 전달해야 하는가?
그래서 IP 위에 전송 계층 프로토콜이 필요하다.
대표적인 것이 다음 두 가지다.
TCP UDP
둘 다 IP 위에서 동작하지만 설계 목적이 상당히 다르다.
2. TCP와 UDP의 가장 큰 차이
간단하게 표현하면 다음과 같다.
TCP 연결을 만들고 상대방과 상태를 유지하면서 데이터 전달을 확인하고 필요하면 재전송한다. UDP 연결을 만들지 않고 데이터를 바로 보낸다.
이를 비교하면 다음과 같다.
항목TCPUDP연결 방식Connection-orientedConnectionless연결 설정필요없음3-Way Handshake사용사용하지 않음데이터 순서 보장OX재전송OXACKOX흐름 제어OX혼잡 제어OX상대적으로 오버헤드큼작음대표적인 용도HTTP/HTTPS, SSH, DBDNS, DHCP, 실시간 스트리밍 등
중요한 것은 UDP가 무조건 빠르고 TCP가 무조건 느리다는 의미가 아니라는 것이다.
TCP는 신뢰성 있는 통신을 위해 많은 기능을 제공하기 때문에 프로토콜 동작이 복잡하다.
UDP는 이러한 기능을 최소화하고 애플리케이션이 필요한 제어를 직접 수행할 수 있도록 한다.
3. TCP는 연결을 어떻게 관리하는가?
TCP는 단순히 데이터를 보내는 프로토콜이 아니다.
TCP는 연결 상태를 관리한다.
대표적인 상태가 다음과 같다.
LISTEN SYN-SENT SYN-RECEIVED ESTABLISHED FIN-WAIT-1 FIN-WAIT-2 TIME-WAIT CLOSE-WAIT LAST-ACK CLOSED
시스템 엔지니어가 특히 자주 보는 상태는 다음이다.
LISTEN SYN-SENT SYN-RECV ESTABLISHED TIME-WAIT CLOSE-WAIT
Linux에서는 ss 명령으로 확인할 수 있다.
ss -ant
예를 들어:
State Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 0 128 0.0.0.0:22 0.0.0.0:* ESTAB 0 0 192.168.10.10:22 192.168.10.50:53124 TIME-WAIT 0 0 192.168.10.10:8080 192.168.10.50:53210
이것을 이해하려면 먼저 Port와 Socket을 알아야 한다.
4. TCP Port란 무엇인가?
IP 주소는 어떤 서버인가를 식별하는 데 사용된다.
Port는 그 서버 안에서 어떤 서비스를 사용할 것인가를 식별한다.
예를 들어:
192.168.10.100:22
라고 하면
192.168.10.100
↓
어떤 서버인가?
22
↓
어떤 서비스인가?
라는 의미가 된다.
대표적인 Port는 다음과 같다.
Port서비스22SSH25SMTP53DNS80HTTP123NTP443HTTPS5432PostgreSQL3306MySQL/MariaDB6379Redis
단, Port 번호 자체가 서비스를 결정하는 것은 아니다.
예를 들어 웹 서버가 반드시 80번을 사용해야 하는 것은 아니다.
FastAPI 8080 Nginx 80 HTTPS 443
처럼 얼마든지 다른 Port를 사용할 수 있다.
5. Client Port는 왜 필요한가?
서버만 Port가 필요한 것이 아니다.
클라이언트도 통신할 때 Port를 사용한다.
예를 들어 PC에서 웹 서버에 접속한다고 가정하자.
Client
192.168.10.50:53124
↓ TCP
Server
192.168.10.100:443
여기서
192.168.10.50
은 클라이언트 IP이고,
53124
는 클라이언트의 임시 Port(Ephemeral Port)다.
서버는
443
Port를 사용한다.
따라서 하나의 TCP 연결은 기본적으로 다음 4개의 값으로 구분할 수 있다.
Source IP Source Port Destination IP Destination Port
예:
192.168.10.50:53124
↓
192.168.10.100:443
6. Socket이란 무엇인가?
Port와 Socket을 같은 것으로 생각하면 안 된다.
Port는 TCP/UDP에서 사용하는 논리적인 번호다.
Socket은 통신 Endpoint를 나타내는 개념이다.
실제 TCP 연결을 생각하면 다음과 같다.
Client Socket
192.168.10.50:53124
│
│ TCP Connection
│
▼
Server Socket
192.168.10.100:443
TCP 연결을 식별하는 핵심은 흔히 다음과 같은 4-Tuple로 설명한다.
Source IP Source Port Destination IP Destination Port
예:
192.168.10.50 53124 192.168.10.100 443
이 값들이 다르면 서로 다른 TCP 연결이 될 수 있다.
7. 하나의 서버 Port에 여러 사용자가 접속할 수 있는 이유
실무에서 매우 중요한 부분이다.
서버가 443 Port를 사용한다고 해보자.
Server 192.168.10.100:443
여러 클라이언트가 동시에 접속할 수 있다.
192.168.10.50:50001 → 192.168.10.100:443 192.168.10.51:50002 → 192.168.10.100:443 192.168.10.52:50003 → 192.168.10.100:443
Destination Port는 모두 443이다.
하지만 Source IP와 Source Port가 다르다.
따라서 TCP는 각각을 서로 다른 연결로 관리할 수 있다.
Client A
10.0.0.10:50001
│
├─────────────┐
│ │
▼ ▼
Server
10.0.0.100:443
▲ ▲
│ │
├─────────────┘
│
Client B
10.0.0.20:50002
이 구조는 웹 서버, API 서버, 데이터베이스 서버 등 거의 모든 TCP 기반 서버에서 매우 중요하다.
8. TCP 3-Way Handshake란?
TCP는 데이터를 보내기 전에 연결을 먼저 만든다.
이 과정을 3-Way Handshake라고 한다.
Client Server │ │ │────── SYN ──────────────────>│ │ │ │<───── SYN + ACK ─────────────│ │ │ │────── ACK ──────────────────>│ │ │ │ ESTABLISHED │
3개의 패킷이 핵심이다.
1. SYN 2. SYN + ACK 3. ACK
9. 첫 번째 패킷 — SYN
클라이언트가 서버에 TCP 연결을 요청한다.
예:
Client 192.168.10.50:53124 Server 192.168.10.100:443
클라이언트는 다음과 같은 TCP 패킷을 전송한다.
Source IP : 192.168.10.50 Source Port : 53124 Destination IP : 192.168.10.100 Destination Port: 443 TCP Flag : SYN Sequence Number: 1000
개념적으로 보면:
Client Server
SEQ=1000
SYN=1
───────────────────────────────>
여기서 SYN은
"TCP 연결을 시작하고 싶습니다."
라는 의미다.
10. Sequence Number는 왜 필요한가?
TCP는 데이터를 순서대로 전달해야 한다.
예를 들어 데이터가 다음과 같다고 하자.
Packet 1 Packet 2 Packet 3 Packet 4
네트워크에서는 패킷이 항상 순서대로 도착한다고 보장할 수 없다.
1 → 도착 3 → 도착 2 → 도착 4 → 도착
따라서 TCP는 Sequence Number를 사용해서 데이터의 순서를 관리한다.
SEQ 1000 SEQ 1100 SEQ 1200 SEQ 1300
처럼 데이터의 위치를 식별한다.
11. 두 번째 패킷 — SYN + ACK
서버가 SYN을 받으면 서버는 연결 요청을 받아들일 수 있는지 판단한다.
정상적으로 연결을 처리할 수 있다면 SYN과 ACK를 함께 전송한다.
Client Server
SEQ=1000
SYN=1
───────────────────────────────>
SEQ=5000
ACK=1001
SYN=1
<───────────────────────────────
여기서 중요한 부분이 있다.
클라이언트가
SEQ=1000
을 보냈다.
서버는 다음과 같이 응답한다.
ACK=1001
즉,
1000번 SYN을 받았고 다음 Sequence Number를 1001로 기대한다.
라는 의미로 이해할 수 있다.
동시에 서버도 자신의 Sequence Number를 제공한다.
Server SEQ = 5000
12. 세 번째 패킷 — ACK
클라이언트는 서버의 SYN + ACK를 받고 ACK를 전송한다.
Client Server
SEQ=1000
SYN=1
───────────────────────────────>
SEQ=5000
ACK=1001
SYN=1
<───────────────────────────────
SEQ=1001
ACK=5001
───────────────────────────────>
이제 TCP 연결이 성립한다.
ESTABLISHED
상태가 된다.
13. TCP 패킷에는 어떤 정보가 들어가는가?
실제 패킷을 이해하려면 TCP Header를 볼 필요가 있다.
TCP Header의 주요 항목은 다음과 같다.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | |C|E|U|A|P|R|S|F| | |Offset | Res. |W|C|R|C|S|S|Y|I| Window Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Urgent Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
실무에서 특히 중요한 것은 다음이다.
Source Port Destination Port Sequence Number Acknowledgment Number Flags Window Size Checksum
14. TCP Flag를 이해해야 한다
TCP Header에는 여러 Flag가 있다.
대표적으로:
SYN ACK FIN RST PSH URG
서버 장애 분석에서 특히 중요한 것은 다음 4개다.
SYN ACK FIN RST
SYN
연결을 시작할 때 사용한다.
SYN = 1
ACK
상대방 데이터를 정상적으로 받았음을 나타낸다.
ACK = 1
FIN
정상적인 TCP 연결 종료에 사용한다.
FIN = 1
RST
TCP 연결을 강제로 초기화할 때 사용한다.
RST = 1
15. SYN, SYN-ACK, ACK를 실제 tcpdump에서 확인하기
서버에서 다음 명령을 실행할 수 있다.
tcpdump -nn -i ens160 tcp port 443
예를 들어 다음과 비슷한 패킷이 나타날 수 있다.
192.168.10.50.53124 > 192.168.10.100.443: Flags [S], seq 1000 192.168.10.100.443 > 192.168.10.50.53124: Flags [S.], seq 5000, ack 1001 192.168.10.50.53124 > 192.168.10.100.443: Flags [.], ack 5001
이를 해석하면:
[S] SYN [S.] SYN + ACK [.] ACK
이다.
즉:
Client Server
[S] SYN
───────────────────────>
[S.] SYN-ACK
<───────────────────────
[.] ACK
───────────────────────>
ESTABLISHED
16. tcpdump에서 Sequence Number를 자세히 보는 방법
다음과 같이 실행할 수 있다.
tcpdump -nn -i ens160 -S tcp port 443
-S 옵션을 사용하면 상대적인 Sequence Number가 아닌 절대 Sequence Number를 확인하는 데 도움이 된다.
예:
10.0.0.10.50000 > 10.0.0.100.443: Flags [S], seq 284731921 10.0.0.100.443 > 10.0.0.10.50000: Flags [S.], seq 912734821, ack 284731922 10.0.0.10.50000 > 10.0.0.100.443: Flags [.], ack 912734822
이것을 직접 계산해 보면 TCP가 어떻게 Sequence와 ACK를 관리하는지 이해하기 쉽다.
17. TCP 연결 장애를 SYN 단계에서 분석하기
실제 장애에서는 3-Way Handshake가 정상적으로 완료되지 않는 경우가 많다.
예를 들어:
Client Server SYN ──────────────────────────────> SYN ──────────────────────────────> SYN ──────────────────────────────>
서버의 SYN-ACK가 없다.
이 경우에는 다음을 의심할 수 있다.
1. 패킷이 서버까지 도착하지 않음 2. 방화벽에서 DROP 3. 서버 서비스가 해당 Port에서 LISTEN하지 않음 4. 서버 TCP/IP Stack 문제 5. 네트워크 ACL 문제 6. 잘못된 Routing 7. 중간 보안장비에서 차단
따라서 서버에서 다음을 확인한다.
ss -lntp
그리고:
tcpdump -nn -i ens160 tcp port 443
18. SYN은 들어오는데 SYN-ACK가 없는 경우
이 상황은 상당히 중요하다.
tcpdump에서:
Client → Server [S] SYN [S] SYN [S] SYN
만 보인다.
서버에서 SYN을 받고 있다는 것은 확인된다.
그런데:
Server → Client [S.] SYN-ACK
가 보이지 않는다.
이 경우 서버 측에서 다음을 확인한다.
ss -lntp
예:
LISTEN 0 128 0.0.0.0:443
정상적으로 Port가 LISTEN 중이라면 다음 단계로 방화벽을 확인한다.
firewall-cmd --list-all
또는:
nft list ruleset
19. SYN-ACK까지 나가는데 연결이 안 되는 경우
이번에는 반대 상황이다.
Client Server
[S] SYN
──────────────────────────────>
[S.] SYN-ACK
<──────────────────────────────
ACK가 보이지 않음
이 경우 서버는 연결 요청에 정상적으로 응답하고 있다.
그런데 클라이언트의 ACK가 돌아오지 않는다.
이 경우 다음을 의심할 수 있다.
Client → Server 경로는 정상 Server → Client 경로 문제
즉 Return Path 문제가 있을 수 있다.
대표적인 원인:
잘못된 Routing 비대칭 Routing 방화벽 ACL NAT 보안장비 잘못된 Gateway
서버에서:
ip route
를 확인한다.
그리고:
ip route get 192.168.10.50
을 사용하면 특정 목적지로 갈 때 어떤 인터페이스와 Gateway를 사용하는지 확인할 수 있다.
20. SYN-ACK와 RST를 구분해야 한다
다음과 같은 상황도 매우 중요하다.
Client Server SYN ──────────────────────────────> RST <──────────────────────────────
tcpdump에서는:
Flags [R.]
처럼 보일 수 있다.
이는 연결이 정상적으로 수립되지 않고 TCP Reset이 발생했다는 의미다.
대표적으로:
Port에 서비스가 없음 잘못된 Port 애플리케이션이 연결을 거부 방화벽/보안정책에 의한 Reset
등을 확인해야 한다.
따라서 nc에서 다음과 같이 나오는 경우:
Connection refused
단순히 네트워크가 끊겼다고 판단하면 안 된다.
서버까지 패킷이 도착했고 TCP 수준에서 거부 응답을 받았을 가능성이 있기 때문이다.
21. Ping은 되는데 TCP 접속이 안 되는 이유
이제 앞서 배운 내용을 연결해 보자.
ping 192.168.10.100
이 성공했다고 하자.
그러면 최소한 ICMP 기반의 IP 통신이 가능하다는 의미다.
하지만:
nc -zv 192.168.10.100 443
가 실패할 수 있다.
왜일까?
Ping은:
ICMP
를 사용한다.
HTTPS는:
TCP ↓ 443 ↓ TLS ↓ HTTP
를 사용한다.
따라서:
ICMP 허용 TCP/443 차단
이라는 정책이 충분히 가능하다.
22. ss + nc + tcpdump를 같이 사용해야 하는 이유
세 명령어는 서로 다른 정보를 제공한다.
ss
ss -lntp
서버 내부의 Socket 상태를 확인한다.
질문:
서버가 Port를 열고 있는가?
nc
nc -zv 192.168.10.100 443
실제 TCP 연결 가능 여부를 확인한다.
질문:
이 Port까지 TCP 연결이 가능한가?
tcpdump
tcpdump -nn -i ens160 tcp port 443
실제 패킷을 확인한다.
질문:
실제로 SYN이 들어오는가? SYN-ACK가 나가는가? ACK가 돌아오는가? RST가 발생하는가?
따라서 다음과 같이 생각하면 된다.
ss ↓ 서버 Socket 상태 nc ↓ TCP Port 연결 상태 tcpdump ↓ 실제 네트워크 패킷
23. 실제 장애 사례 1 — 서비스가 내려간 경우
상황:
Ping 정상 SSH 접속 실패
확인:
ping 192.168.10.100
정상.
다음:
nc -zv 192.168.10.100 22
결과:
Connection refused
서버에서:
ss -lntp | grep :22
결과 없음.
원인은:
sshd가 LISTEN하지 않음
서비스 상태 확인:
systemctl status sshd
이처럼 Ping이 정상이어도 애플리케이션 서비스는 내려가 있을 수 있다.
24. 실제 장애 사례 2 — 127.0.0.1에만 서비스가 바인딩된 경우
서버에서:
ss -lntp | grep 8080
결과:
LISTEN 0 128 127.0.0.1:8080
이것은 매우 중요한 상태다.
서비스가:
127.0.0.1
에만 바인딩되어 있다.
따라서 서버 내부에서는:
curl http://127.0.0.1:8080
정상이다.
하지만 외부 서버에서:
nc -zv 192.168.10.100 8080
실패할 수 있다.
해결 방법은 애플리케이션이 외부에서 접근 가능한 주소에 Listen하도록 설정하는 것이다.
예:
127.0.0.1:8080
대신 필요에 따라:
0.0.0.0:8080
또는 특정 서버 IP:
192.168.10.100:8080
으로 Listen하도록 구성한다.
단, 0.0.0.0으로 변경한다고 해서 반드시 외부 접속이 가능한 것은 아니다.
방화벽과 네트워크 ACL도 별도로 확인해야 한다.
25. 실제 장애 사례 3 — SYN은 서버에 도착하지만 SYN-ACK가 없다
tcpdump:
tcpdump -nn -i ens160 tcp port 8080
결과:
192.168.10.50.52000 > 192.168.10.100.8080: Flags [S] 192.168.10.50.52000 > 192.168.10.100.8080: Flags [S] 192.168.10.50.52000 > 192.168.10.100.8080: Flags [S]
클라이언트가 SYN을 계속 재전송한다.
서버에서 SYN-ACK가 없다.
이때 다음 순서로 확인한다.
ss -lntp | grep :8080 firewall-cmd --list-all nft list ruleset ip route
이 과정을 통해:
Port 미개방 방화벽 DROP Routing 문제 서비스 문제
등을 좁혀갈 수 있다.
26. 실제 장애 사례 4 — SYN-ACK가 나가지만 ACK가 없다
tcpdump:
Client → Server [S] SYN Server → Client [S.] SYN-ACK Client → Server ACK 없음
이 경우 서버의 Listen 문제보다는 Return Path를 의심해야 한다.
서버에서:
ip route get <Client-IP>
을 확인한다.
예:
ip route get 192.168.10.50
결과:
192.168.10.50 via 192.168.10.1 dev ens160
예상한 Gateway와 인터페이스가 맞는지 확인한다.
특히 서버에 NIC가 여러 개 있는 경우 매우 중요하다.
ens160 192.168.10.100 ens192 10.10.10.100
처럼 여러 네트워크가 존재하면 잘못된 Routing 때문에 비대칭 통신이 발생할 수 있다.
27. TCP와 UDP를 장애 관점에서 비교하기
시스템 엔지니어 입장에서 TCP와 UDP의 차이는 다음과 같이 이해하는 것이 좋다.
TCP Client │ │ SYN ▼ Server │ │ SYN-ACK ▼ Client │ │ ACK ▼ ESTABLISHED
UDP는 다르다.
Client │ │ UDP Data ▼ Server
연결을 만들기 위한 3-Way Handshake가 없다.
따라서 UDP에서는 TCP처럼:
SYN SYN-ACK ACK
를 tcpdump에서 찾을 수 없다.
UDP 장애를 분석할 때는 다음을 중심으로 확인해야 한다.
Source IP Destination IP Source Port Destination Port UDP packet Firewall Routing Application response
예를 들어 DNS라면:
Client
192.168.10.50:53000
│
│ UDP/53
▼
DNS Server
192.168.10.53:53
28. TCP 패킷을 보는 시스템 엔지니어의 핵심 관점
tcpdump 결과를 단순히 읽는 것이 아니라 상태 변화를 봐야 한다.
예를 들어:
SYN ↓ SYN-ACK ↓ ACK ↓ ESTABLISHED
정상적인 연결이다.
반면:
SYN ↓ SYN ↓ SYN
이면 서버 응답이 없다는 의미다.
또:
SYN ↓ SYN-ACK ↓ ACK
까지 정상인데 애플리케이션이 응답하지 않는다면 TCP 연결 이후의 문제일 수 있다.
즉:
Network Layer
↓
TCP Connection
↓
Application Protocol
순서대로 범위를 좁혀야 한다.
29. 시스템 엔지니어가 반드시 기억해야 할 TCP 장애 분석 구조
TCP 연결 장애가 발생하면 다음 순서로 접근한다.
1. IP 통신 확인
↓
ping
2. Port 접근 확인
↓
nc
3. Server Socket 확인
↓
ss
4. Firewall 확인
↓
firewall-cmd
nft
5. 실제 패킷 확인
↓
tcpdump
6. TCP Handshake 확인
↓
SYN
SYN-ACK
ACK
7. Application 확인
↓
curl
ssh
application log
이 순서를 습관화하면 장애 분석 시간이 크게 줄어든다.
30. TCP 3-Way Handshake 전체 흐름
전체 과정을 하나의 그림으로 정리하면 다음과 같다.
Client Server
192.168.10.50 192.168.10.100
53124 443
│ │
│ SYN │
│ SEQ=1000 │
│ SYN=1 │
│──────────────────────────────────────────>│
│ │
│ │
│ SYN + ACK │
│ SEQ=5000 │
│ ACK=1001 │
│<──────────────────────────────────────────│
│ │
│ │
│ ACK │
│ SEQ=1001 │
│ ACK=5001 │
│──────────────────────────────────────────>│
│ │
│ │
│ ESTABLISHED │
│<═════════════════════════════════════════>│
│ │
│ DATA │
│<═════════════════════════════════════════>│
여기서 중요한 것은 단순히 "3개의 패킷을 주고받는다"가 아니다.
TCP는 이 과정에서:
상대방의 존재 확인 + 연결 요청 + Sequence Number 동기화 + Acknowledgment Number 확인 + TCP 연결 상태 생성
을 수행한다.
31. 이번 편의 핵심 명령어 정리
TCP LISTEN 확인
ss -lntp
특정 Port:
ss -lntp | grep :443
전체 TCP 연결
ss -ant
SYN-SENT 상태
ss -ant state syn-sent
SYN-RECV 상태
ss -ant state syn-recv
Port 연결 테스트
nc -zv 192.168.10.100 443
TCP 443 패킷 확인
tcpdump -nn -i ens160 tcp port 443
SYN 패킷만 확인
tcpdump -nn -i ens160 'tcp[tcpflags] & tcp-syn != 0'
TCP Flag를 포함한 상세 분석
tcpdump -nn -i ens160 -S tcp port 443
특정 Client 확인
tcpdump -nn -i ens160 host 192.168.10.50
32. 반드시 기억해야 할 핵심 개념
이번 내용을 다음 구조로 기억하면 된다.
IP ↓ 어떤 서버인가? Port ↓ 어떤 서비스인가? Socket ↓ 통신 Endpoint TCP ↓ 신뢰성 있는 연결 관리 3-Way Handshake ↓ SYN ↓ SYN-ACK ↓ ACK ↓ ESTABLISHED
그리고 장애 분석에서는:
ping ↓ IP 통신 nc ↓ TCP Port ss ↓ Server Socket tcpdump ↓ 실제 Packet SYN SYN-ACK ACK ↓ TCP Connection
이라는 관계를 기억하면 된다.
마무리
TCP를 제대로 이해하면 네트워크 장애를 단순히 "통신이 안 된다"라고 판단하지 않게 된다.
예를 들어 다음 두 상황은 완전히 다르다.
SYN 자체가 서버에 도착하지 않는다.
와
SYN은 서버에 도착하지만 SYN-ACK가 나오지 않는다.
또한:
SYN SYN-ACK ACK
까지 정상인데 HTTP 응답이 없다면 TCP 연결 자체의 문제가 아니라 애플리케이션 계층으로 분석 범위를 이동해야 한다.
즉 시스템 엔지니어의 네트워크 장애 분석은 패킷이 어느 단계까지 정상적으로 진행되었는지를 증명하는 과정이다.
특히 다음 세 가지를 직접 확인할 수 있어야 한다.
ss → 서버가 어떤 Port를 LISTEN하고 있는가? nc → 실제 TCP 연결이 가능한가? tcpdump → SYN → SYN-ACK → ACK가 실제로 오가는가?
이 세 가지를 이해하면 단순한 네트워크 입문 수준을 넘어 실제 서버 장애 분석에 필요한 TCP 분석의 기초가 완성된다.
다음 단계에서는 여기서 더 깊게 들어가 TCP Sequence Number, ACK Number, Window Size, Flow Control, Retransmission, TCP Connection 종료 과정과 TIME_WAIT/CLOSE_WAIT까지 이해해야 한다.
특히 실무에서는 다음과 같은 장애가 매우 자주 발생한다.
TIME_WAIT가 왜 이렇게 많은가? CLOSE_WAIT가 계속 증가하는 이유는? SYN-RECV가 폭증하는 이유는? TCP Retransmission은 왜 발생하는가? Window Size가 작아지는 이유는? TCP Connection이 갑자기 RST 되는 이유는?
이제부터는 단순한 TCP 연결 과정을 넘어 TCP 패킷 하나하나를 보고 실제 장애 원인을 찾아내는 단계로 들어갈 수 있다.
TCP와 UDP 차이를 표로 보강해줘중복된 설명과 사례를 줄여줘TCP 상태 전이를 하나로 정리해줘
댓글
아직 댓글이 없습니다.
로그인 후 댓글을 남길 수 있습니다.