TCP는 왜 신뢰할 수 있는 통신이라고 하는가

TCP는 왜 신뢰할 수 있는 통신이라고 하는가#

1장 데이터가 도착했다는 것을 어떻게 믿을 수 있을까#

1.1 서버로 데이터를 보냈는데 중간에서 사라진다면#

주차관제 시스템에서 차량이 진입했다고 가정해보겠습니다.

LPR Camera가 차량번호를 인식하고 Gate Controller 또는 Server로 다음 데이터를 전송합니다.

차량번호 : 12가3456
차로     : Entrance-01
시간     : 10:31:24

Application에서는 단순히:

send()

를 호출했을 수 있습니다.

하지만 Network에서는 여러 일이 발생합니다.

장비
↓
Switch
↓
Router
↓
Firewall
↓
Server

이 과정에서 Packet이 손실될 수도 있고, 지연될 수도 있으며, 같은 데이터가 다시 전달될 수도 있습니다.

IP 자체는:

이 Packet이 반드시 도착했는가?

순서대로 도착했는가?

중복되지 않았는가?

를 Application 대신 보장해주는 Protocol이 아닙니다.

TCP는 바로 이 문제를 해결하기 위해 사용됩니다.

1.2 TCP가 제공하려는 것은 신뢰할 수 있는 Byte Stream이다#

TCP는 Transmission Control Protocol의 약자입니다.

TCP의 핵심 역할을 간단히 정리하면:

연결을 만들고
↓
데이터의 순서를 관리하고
↓
수신 여부를 확인하고
↓
손실된 데이터를 다시 보내고
↓
수신자의 처리 능력에 맞추고
↓
Network 혼잡에도 전송량을 조절한다

입니다.

그래서 TCP를 신뢰성 있는 Transport Protocol이라고 부릅니다.

다만 여기서 말하는 신뢰성이 무엇인지 정확하게 이해해야 합니다.

TCP가 보장하려는 것은:

Application이 보낸 Byte Stream을
상대 Application에
순서대로 전달하는 것

입니다.

TCP가:

"차단기가 실제로 열렸다."

까지 보장하는 것은 아닙니다.

2장 TCP와 IP는 역할이 다르다#

2.1 IP는 목적지까지 Packet을 전달한다#

IP의 역할을 단순화하면:

Source IP
↓
Network
↓
Destination IP

입니다.

Router는 Destination IP를 보고 Packet을 다음 Network로 전달합니다.

하지만 IP 자체는 일반적으로:

전달 확인
순서 보장
재전송
중복 제거

같은 기능을 Application에 제공하지 않습니다.

2.2 TCP가 IP 위에 신뢰성 기능을 추가한다#

계층 구조를 보면:

Application
     ↓
    TCP
     ↓
     IP
     ↓
 Ethernet

입니다.

TCP가 만들어낸 Segment는 IP Packet 안에 들어갑니다.

Ethernet Frame
└─ IP Packet
   └─ TCP Segment
      └─ Application Data

따라서 TCP가 아무리 잘 설계되어 있어도 그 아래 Network가 심각하게 불안정하면 성능은 나빠질 수 있습니다.

TCP는 손실을 없애는 Protocol이 아니라 손실이 발생했을 때 복구할 수 있도록 설계된 Protocol이라고 이해하는 편이 정확합니다.

3장 TCP는 먼저 Connection을 만든다#

3.1 UDP와 다른 중요한 특징#

TCP는 일반적으로 데이터를 보내기 전에 두 Endpoint 사이에 Connection 상태를 만듭니다.

예:

Controller
192.168.10.20:53000

        ↕

Server
192.168.10.100:5000

이 연결은 단순히 Cable이 연결됐다는 뜻이 아닙니다.

TCP 양쪽이:

상대방과 통신할 준비가 되었는가?

초기 Sequence Number는 무엇인가?

TCP Option은 무엇을 사용할 것인가?

등을 확인하면서 상태를 만드는 과정입니다.

3.2 TCP Connection은 네 가지 값으로 구분할 수 있다#

하나의 TCP Connection을 구분할 때 기본적으로 다음 정보를 생각할 수 있습니다.

Source IP
Source Port
Destination IP
Destination Port

예:

192.168.10.20:53000
        ↓
192.168.10.100:5000

같은 Server의 같은 Port에 여러 Client가 동시에 연결될 수 있는 이유도 Source IP와 Source Port 등이 서로 다르기 때문입니다.

4장 3-Way Handshake는 어떻게 Connection을 만들까#

4.1 첫 번째 단계 — SYN#

Client가 Server에 연결을 시작합니다.

Client
  │
  │ SYN
  ├──────────────→ Server

SYN은 새로운 TCP Connection을 시작하고 Sequence Number 공간을 동기화하기 위한 중요한 Flag입니다.

4.2 두 번째 단계 — SYN + ACK#

Server가 연결을 받아들일 준비가 되어 있다면 응답합니다.

Client
  │
  │ SYN
  ├──────────────→ Server
  │
  │      SYN + ACK
  │←──────────────

Server도 자신의 Initial Sequence Number를 제시합니다.

4.3 세 번째 단계 — ACK#

Client가 Server의 응답을 확인합니다.

Client                       Server

SYN
──────────────────────────→

                    SYN + ACK
←──────────────────────────

ACK
──────────────────────────→

이것이 TCP 3-Way Handshake입니다.

Handshake가 끝나면 두 TCP Endpoint는 연결 상태를 유지하며 데이터를 주고받을 수 있습니다.

5장 Handshake에서 실제로 확인하는 것은 무엇인가#

5.1 단순히 “서버가 살아 있다”를 확인하는 것만은 아니다#

3-Way Handshake는 단순한 접속 테스트 이상입니다.

양쪽은 자신의 Sequence Number 공간을 시작하고 TCP 통신을 위한 상태를 만듭니다.

개념적으로:

Client ISN
1000

Server ISN
7000

처럼 각 방향의 Sequence Number 기준을 정합니다.

5.2 TCP Option도 협상될 수 있다#

SYN과 SYN-ACK에는 여러 TCP Option이 들어갈 수 있습니다.

대표적으로:

MSS

Window Scale

SACK Permitted

Timestamp

등이 있습니다.

따라서 실제 Packet Capture에서 SYN을 보면 단순히:

SYN이 왔다.

만 볼 것이 아니라 TCP Option도 확인할 수 있습니다.

6장 Sequence Number가 TCP 신뢰성의 핵심이다#

6.1 TCP는 Byte의 위치를 관리한다#

TCP의 Sequence Number는 단순히:

Packet 1
Packet 2
Packet 3

처럼 Packet 번호를 붙이는 것이 아닙니다.

TCP는 Byte Stream의 위치를 기준으로 Sequence Number를 관리합니다.

예를 들어:

Sequence Number 1001

Data Length 500 Byte

인 Segment가 전달되었다고 가정하겠습니다.

이 Segment는 개념적으로:

Byte 1001
~
Byte 1500

범위를 전달합니다.

다음 데이터의 시작은:

이 됩니다.

6.2 Packet의 크기가 달라도 순서를 복구할 수 있다#

예를 들어 송신 측에서 다음과 같이 나뉘었다고 생각해보겠습니다.

Segment A
Seq 1001
Length 500

Segment B
Seq 1501
Length 700

Segment C
Seq 2201
Length 300

Network에서는 도착 순서가 달라질 수도 있습니다.

A
C
B

하지만 Sequence Number가 있기 때문에 TCP는 Byte Stream의 원래 순서를 판단할 수 있습니다.

A
B
C

Application에는 순서가 맞는 Byte Stream으로 전달됩니다.

7장 ACK는 무엇을 의미하는가#

7.1 ACK는 다음에 받고 싶은 Byte를 알려준다#

TCP ACK는 단순한:

받았습니다.

라는 표시보다 조금 더 구체적입니다.

예를 들어 Receiver가:

ACK = 1501

이라고 응답했다면 기본적인 의미는:

1500번 Byte까지 연속적으로 받았으며 다음에는 1501번 Byte부터 기대한다.

라고 이해할 수 있습니다.

7.2 Sequence Number와 ACK를 함께 보면#

예:

Sender

Seq = 1001
Length = 500
──────────────────────────→

Receiver

ACK = 1501
←──────────────────────────

입니다.

송신자는 이 ACK를 통해 해당 범위까지의 데이터가 TCP 계층에서 수신되었다는 사실을 판단할 수 있습니다.

8장 가장 중요한 오해 — TCP ACK는 업무 완료를 의미하지 않는다#

현장에서 반드시 구분해야 합니다.

Gate Controller가 Server에 다음 명령을 보냈다고 가정하겠습니다.

OPEN GATE

Server로부터 TCP ACK가 왔습니다.

그렇다고:

차단기가 실제로 열렸다.

는 뜻은 아닙니다.

TCP ACK가 의미하는 것은 기본적으로 TCP 데이터가 상대 TCP Stack에 정상적으로 수신되었다는 것입니다.

그 이후에는 여전히 다음 과정이 남을 수 있습니다.

TCP 수신
↓
Application이 데이터 읽음
↓
Command Parsing
↓
권한 검사
↓
장비 제어
↓
Motor 동작
↓
Limit Sensor 확인
↓
업무 완료

따라서 시스템에서는 다음 상태를 구분하는 것이 좋습니다.

Command Sent

Received

Accepted

Started

Completed

TCP ACK와 Application ACK를 혼동하면 안 됩니다.

9장 TCP는 손실된 데이터를 어떻게 찾을까#

9.1 Network에서 Segment 하나가 사라졌다고 가정하자#

정상적으로는:

Segment A
Segment B
Segment C

가 전달되어야 합니다.

하지만:

Segment A
Segment B  ← 손실
Segment C

가 되었다고 생각해보겠습니다.

Receiver는 연속적으로 받아야 할 Byte가 빠졌다는 것을 Sequence Number를 통해 알 수 있습니다.

9.2 누락된 데이터가 있으면 ACK 패턴이 달라진다#

예를 들어 Receiver가:

ACK 1501

을 기대하는 상태인데 뒤쪽 데이터가 먼저 도착했다면 누락된 범위가 있다는 사실을 알 수 있습니다.

이러한 ACK 패턴은 송신자가 손실을 추정하는 중요한 정보가 됩니다.

10장 TCP는 데이터를 다시 보낸다#

10.1 Retransmission Timeout#

데이터를 보냈는데 일정 시간 동안 적절한 ACK를 받지 못하면 Sender는 손실 가능성을 판단하고 재전송할 수 있습니다.

이를 이해하는 대표 개념이 Retransmission Timeout, RTO입니다.

Data 전송
↓
ACK 기다림
↓
적절한 ACK 없음
↓
RTO 만료
↓
Retransmission

입니다.

RTO는 단순한 고정 숫자가 아니라 TCP Stack이 측정한 Round-Trip Time 등을 바탕으로 조정되는 방식이 일반적입니다.

10.2 Fast Retransmit#

TCP는 항상 Timeout이 끝날 때까지 기다려야 하는 것은 아닙니다.

ACK 패턴을 이용해 중간 Segment가 손실되었다고 판단하면 더 빠르게 재전송할 수도 있습니다.

대표적인 메커니즘이 Fast Retransmit입니다.

세부 동작은 TCP 구현과 사용되는 Algorithm, SACK 여부 등에 영향을 받을 수 있습니다.

10.3 SACK도 손실 복구를 돕는다#

SACK는 Selective Acknowledgment입니다.

단순 누적 ACK만으로는:

여기까지 연속적으로 받았다.

를 주로 표현합니다.

SACK를 사용하면 Receiver가:

이 뒤쪽 범위도 이미 받았다.

는 정보를 Sender에게 추가로 알려줄 수 있습니다.

그러면 송신 측이 이미 받은 데이터를 불필요하게 다시 보내는 일을 줄이고 손실된 범위를 더 효율적으로 재전송할 수 있습니다.

11장 중복 데이터는 어떻게 처리할까#

Network 상황에 따라 같은 TCP 데이터가 다시 도착할 수도 있습니다.

예:

Seq 1001
Length 500

을 이미 받았는데 동일 범위가 다시 도착한 경우입니다.

TCP는 Sequence Number를 이용해 Byte 위치를 관리하기 때문에 중복된 데이터를 Application에 다시 전달하지 않도록 처리할 수 있습니다.

즉 TCP의 Sequence Number는:

순서 관리
+
손실 파악
+
중복 처리

에 중요한 역할을 합니다.

12장 TCP는 Message Protocol이 아니라 Stream Protocol이다#

12.1 개발자가 특히 많이 오해하는 부분#

Application에서 다음처럼 두 번 전송했다고 가정해보겠습니다.

send("OPEN")
send("GATE01")

개발자는 Receiver에서도:

recv() → "OPEN"
recv() → "GATE01"

처럼 정확히 두 번 나누어 들어올 것이라고 생각하기 쉽습니다.

하지만 TCP는 이렇게 Message 경계를 보장하지 않습니다.

12.2 Receiver에서는 다르게 읽힐 수 있다#

예를 들어:

recv()
→ "OPENGATE01"

로 한 번에 들어올 수도 있습니다.

또는:

recv()
→ "OP"

recv()
→ "ENGA"

recv()
→ "TE01"

처럼 나뉠 수도 있습니다.

TCP가 보장하는 것은:

O P E N G A T E 0 1

이라는 Byte 순서입니다.

OPEN과 GATE01이라는 Application Message 경계는 TCP가 알지 못합니다.

12.3 Application Protocol이 Frame 구조를 만들어야 한다#

그래서 TCP 기반 Protocol에서는 Application 자체가 Message 경계를 정의합니다.

대표적인 방법은:

Length Prefix

Delimiter

고정 길이

Header + Payload

등입니다.

예:

[Length 6][OPEN01]

또는:

OPEN01\r\n

같은 구조입니다.

이 부분을 잘못 설계하면 TCP는 정상인데 Application에서 Packet이 붙거나 잘리는 것처럼 보이는 문제가 발생합니다.

13장 TCP Flow Control은 수신자를 보호한다#

13.1 Receiver도 무한정 데이터를 받을 수 없다#

Server가 데이터를 매우 빠르게 보내고 있는데 Embedded Controller의 Memory가 작다고 가정해보겠습니다.

Server
고속 전송
      ↓
Controller
작은 Receive Buffer

Controller의 Buffer가 넘치면 문제가 발생합니다.

TCP는 이를 방지하기 위해 Flow Control을 제공합니다.

13.2 Receive Window#

Receiver는 Sender에게 자신이 추가로 받을 수 있는 Buffer 여유를 알려줍니다.

이를 Receive Window 또는 Advertised Window라고 부릅니다.

개념적으로:

Receiver

"현재 이 정도까지 받을 수 있습니다."

        ↓

Sender

전송량 조절

입니다.

TCP Header의 Window 정보가 이 과정에 사용됩니다.

13.3 Zero Window#

Receiver Buffer가 가득 차면 Receiver가:

Window = 0

을 광고할 수도 있습니다.

그러면 Sender는 일반 데이터 전송을 멈추고 Receiver가 다시 공간을 확보하기를 기다립니다.

Packet Capture에서:

TCP ZeroWindow

같은 현상을 지속적으로 본다면 Network가 느린 것이 아니라 수신 Application이 데이터를 충분히 빨리 소비하지 못하는 상황도 의심할 수 있습니다.

14장 Flow Control과 Congestion Control은 다르다#

두 개념은 매우 자주 혼동됩니다.

14.1 Flow Control#

목적:

Receiver를 보호한다.

입니다.

수신자의 Buffer 상황을 기준으로 합니다.

Receive Window

가 중요한 역할을 합니다.

14.2 Congestion Control#

목적은:

Network를 과도한 Traffic으로부터 보호한다.

입니다.

Network에서 Packet Loss나 지연이 증가하는 상황을 고려해 송신량을 조절합니다.

Sender는 Congestion Window 같은 내부 상태를 이용해 전송량을 조절할 수 있습니다.

14.3 두 제한을 동시에 고려한다#

개념적으로 실제 Sender가 한 번에 보낼 수 있는 양은:

Receiver가 받을 수 있는 양
+
Network가 감당할 수 있다고 판단한 양

두 조건의 영향을 받습니다.

간단히 비교하면:

구분	Flow Control	Congestion Control
보호 대상	Receiver	Network
주요 문제	수신 Buffer 부족	Network 혼잡
대표 개념	Receive Window	Congestion Window
판단 주체	Receiver 정보 활용	Sender Algorithm 중심

15장 TCP Connection은 어떻게 종료되는가#

15.1 정상적인 종료#

TCP는 양방향 통신이므로 각 방향을 독립적으로 종료할 수 있습니다.

일반적인 정상 종료 과정에서는 FIN과 ACK가 사용됩니다.

개념적으로:

Client                       Server

FIN
──────────────────────────→

                         ACK
←──────────────────────────

                         FIN
←──────────────────────────

ACK
──────────────────────────→

실제 Packet 순서는 구현과 상황에 따라 달라질 수 있습니다.

15.2 FIN은 정상적인 종료를 의미한다#

FIN은:

이 방향으로 더 이상 보낼 데이터가 없다.

는 의미와 연결됩니다.

따라서 Packet Capture에서 FIN을 본다고 무조건 장애는 아닙니다.

정상적인 Connection 종료일 수 있습니다.

16장 RST는 무엇인가#

16.1 Connection을 즉시 중단할 때 사용된다#

TCP에서 RST는 Reset입니다.

예를 들어:

Client
→ Server TCP 5000 연결 시도

Server
→ 해당 Port에 Service 없음

상황에서는 RST가 반환될 수 있습니다.

16.2 RST가 보인다면 누가 보냈는지 확인한다#

현장에서:

Connection Reset

이라는 오류가 발생했다면 단순히:

Network가 끊겼다.

라고 판단하면 안 됩니다.

Packet Capture에서:

누가 RST를 보냈는가?

가 중요합니다.

가능한 원인은:

Server Application 종료
Service 재시작
존재하지 않는 Port
Application이 Connection 강제 종료
중간 Firewall 또는 Network 장비의 개입

등 다양합니다.

17장 TCP Timeout은 하나의 원인만 의미하지 않는다#

Application에 다음과 같은 오류가 있다고 가정합니다.

Connection Timeout

가능한 원인은 매우 다양합니다.

Server Down

Routing 문제

Firewall Drop

잘못된 IP

TCP Port 차단

Packet Loss

Server 과부하

따라서 Timeout 하나만 보고 TCP Stack 문제라고 판단하면 안 됩니다.

18장 Connection Refused와 Timeout은 다르다#

18.1 Connection Refused#

예를 들어 Server까지 Network Packet은 정상적으로 도착하지만 해당 TCP Port에 Service가 없다면 Connection이 즉시 거부될 수 있습니다.

개념적으로:

Client
↓
Server까지 도착
↓
TCP Port 5000
Service 없음
↓
RST
↓
Connection Refused

입니다.

18.2 Timeout#

반대로:

SYN
↓
아무 응답 없음
↓
재시도
↓
Timeout

이라면 상황이 다릅니다.

중간 Firewall이 Packet을 Drop하거나, 경로가 없거나, Server 자체가 응답하지 않는 등의 원인이 있을 수 있습니다.

따라서:

Refused

와:

Timeout

은 장애 분석에서 매우 다른 단서입니다.

19장 주차관제 시스템에서 TCP를 어떻게 볼까#

19.1 Gate Controller가 Server에 연결한다#

예:

Gate Controller
192.168.20.30:51024

        ↓ TCP

Parking Server
192.168.100.20:5000

먼저 Connection을 만듭니다.

SYN
↓
SYN + ACK
↓
ACK

그다음 Controller가 차량 이벤트를 전송합니다.

ENTRY
12가3456
Entrance-01
10:31:24

TCP는 이 Byte Stream이 Server TCP Stack에 순서대로 전달되도록 관리합니다.

19.2 서버가 ACK했다고 차량 처리가 끝난 것은 아니다#

전체 시스템은 다음과 같이 볼 수 있습니다.

Controller
↓
TCP 전송
↓
Server TCP Stack
↓
Application
↓
Database
↓
요금 정책 판단
↓
Gate OPEN 명령
↓
Controller
↓
Barrier 동작

첫 번째 TCP ACK는 이 전체 업무 흐름의 완료를 의미하지 않습니다.

따라서 업무적으로 중요한 시스템에서는 Application Protocol에서 별도의 응답을 설계하는 것이 좋습니다.

예:

{
  "eventId": "E202609240001",
  "status": "processed"
}

처럼 실제 처리 상태를 알려줄 수 있습니다.

20장 TCP가 순서를 보장해도 업무 순서는 뒤바뀔 수 있다#

20.1 TCP 순서와 Application 처리 순서는 다르다#

Server가 다음 이벤트를 순서대로 받았다고 가정합니다.

Event A
10:31:01

Event B
10:31:02

TCP는 Byte 순서를 보장합니다.

하지만 Server 내부에서:

Worker 1
Event A 처리

Worker 2
Event B 처리

를 동시에 실행할 수 있습니다.

Event B 처리가 더 빨리 끝난다면 Database에는:

Event B
Event A

순서로 반영될 수도 있습니다.

20.2 TCP를 업무 순서 보장 장치로 사용하면 안 된다#

따라서 중요한 이벤트에는 다음과 같은 Application 정보가 필요할 수 있습니다.

Event ID

Sequence ID

발생 시각

Device ID

처리 상태

즉:

TCP 순서 보장
≠
업무 처리 순서 보장

입니다.

이 차이는 서버 개발에서 매우 중요합니다.

21장 Wireshark에서 3-Way Handshake 확인하기#

정상적인 연결 시작은 다음처럼 볼 수 있습니다.

Client → Server
SYN

Server → Client
SYN, ACK

Client → Server
ACK

Wireshark에서는 Filter를:

tcp

로 설정할 수 있습니다.

특정 Port만 보고 싶다면:

tcp.port == 5000

같은 Display Filter를 사용할 수 있습니다.

22장 tcpdump로 TCP Connection을 확인하기#

Linux에서는 시험망이나 허가된 환경에서 다음과 같이 확인할 수 있습니다.

tcpdump -n -i eth0 'tcp port 5000'

파일로 저장하려면:

tcpdump -n -i eth0 'tcp port 5000' -w tcp_trace.pcap

이후 Wireshark에서 분석할 수 있습니다.

22.1 간단한 시험용 Server#

시험 환경에서:

nc -l 5000

으로 TCP Port를 열 수 있습니다.

Client에서는:

nc 192.0.2.10 5000

처럼 연결할 수 있습니다.

이때 Packet Capture를 하면:

Handshake
↓
Data
↓
ACK
↓
Connection 종료

과정을 직접 확인할 수 있습니다.

23장 Packet Capture에서 무엇을 봐야 할까#

TCP 장애를 분석할 때 무작정 Packet 전체를 읽기보다 다음 순서로 보면 좋습니다.

23.1 Connection이 만들어졌는가#

SYN
SYN-ACK
ACK

를 확인합니다.

23.2 데이터가 실제로 전송됐는가#

Sequence Number
TCP Payload Length

을 확인합니다.

23.3 ACK가 돌아오는가#

ACK Number의 증가를 확인합니다.

23.4 Retransmission이 발생하는가#

반복되는:

TCP Retransmission

이 있는지 확인합니다.

23.5 Window 문제가 있는가#

다음과 같은 현상을 확인할 수 있습니다.

Zero Window
Window Full
Window Update

23.6 누가 Connection을 종료했는가#

FIN
RST

를 확인합니다.

이 순서만 익혀도 TCP 장애 분석이 훨씬 쉬워집니다.

24장 Retransmission이 많으면 어디를 확인해야 할까#

재전송은 원인이 아니라 손실 또는 지연이 있다는 단서입니다.

가능한 원인은 여러 계층에 있습니다.

24.1 물리 계층#

Cable 불량
Connector 불량
EMI
FCS Error

24.2 Network 계층#

혼잡
Queue Drop
Routing 변화
불안정한 WAN

24.3 장비 문제#

Server 과부하
NIC 문제
Embedded Device 성능 부족

24.4 Capture 위치 문제#

Packet Capture에서 Retransmission처럼 보이는 현상이 항상 실제 Network Loss를 의미하는 것도 아닙니다.

NIC Offloading이나 Capture 위치 등의 영향으로 분석 화면이 실제 Wire상의 동작과 다르게 보일 수도 있습니다.

따라서 중요한 장애는 여러 지점의 자료를 함께 비교하는 것이 좋습니다.

25장 TCP가 느리다고 Network Bandwidth만 의심하면 안 된다#

전송 속도는 여러 요소의 영향을 받습니다.

Bandwidth
RTT
Packet Loss
Receive Window
Congestion Control
Server 처리 속도
Application 처리 속도

예를 들어 1Gbps Ethernet이라고 해서 Application이 항상 1Gbps로 데이터를 주고받는 것은 아닙니다.

특히 지연이 크고 손실이 있는 WAN에서는 TCP의 Congestion Control과 Window가 실제 Throughput에 큰 영향을 줄 수 있습니다.

26장 Embedded Device에서는 TCP 특성을 더 주의해서 본다#

Gate Controller나 Sensor Gateway 같은 Embedded Device는 PC나 Server보다 자원이 제한적일 수 있습니다.

예:

작은 RAM

작은 Receive Buffer

제한적인 동시 Connection 수

낮은 CPU 성능

등입니다.

따라서:

Server에서는 정상
↓
특정 Controller만 느림

이라면 Controller의 TCP Stack과 Application 처리 능력도 확인할 필요가 있습니다.

27장 TCP Keepalive와 Application Heartbeat는 다르다#

27.1 TCP Keepalive#

오랫동안 데이터가 없는 Connection이 실제로 살아 있는지 확인하기 위해 TCP Keepalive 기능을 사용할 수 있습니다.

다만 기본 활성 여부와 Interval은 운영체제 및 Application 설정에 따라 달라집니다.

27.2 Application Heartbeat#

Application 자체에서:

PING

PONG

또는:

{
  "type": "heartbeat",
  "device": "GATE01"
}

같은 메시지를 주기적으로 주고받을 수도 있습니다.

Application Heartbeat는 TCP 연결 상태뿐 아니라 실제 Application이 정상적으로 응답하는가까지 확인하도록 설계할 수 있다는 장점이 있습니다.

27.3 연결됨과 정상 동작은 다르다#

예를 들어:

TCP ESTABLISHED

상태이지만 Server Application Thread가 멈춰 있을 수도 있습니다.

따라서:

TCP Connection 정상
=
업무 시스템 정상

이라고 단정해서는 안 됩니다.

28장 TCP는 보안을 제공하지 않는다#

TCP가 제공하는 신뢰성과 보안은 다른 개념입니다.

TCP는:

순서
전달 확인
재전송
Flow Control
Congestion Control

등을 제공합니다.

하지만 TCP 자체가 Application Data를 자동으로 암호화하지는 않습니다.

예:

TCP
+
평문 Protocol

이라면 Packet Capture에서 데이터가 노출될 수 있습니다.

28.1 TLS와 함께 사용하는 이유#

HTTPS 같은 Protocol은:

HTTP
↓
TLS
↓
TCP
↓
IP

구조를 사용합니다.

TLS는 상황에 따라:

암호화
무결성 보호
상대 인증

등을 제공합니다.

따라서:

TCP가 Reliable하다
=
TCP가 Secure하다

는 아닙니다.

29장 TCP 장애와 보안 장애를 구분한다#

Connection이 많이 만들어진다고 해서 모두 정상 사용자는 아닙니다.

예를 들어 SYN만 대량으로 발생하는 비정상 Traffic은 Server의 Connection 자원을 소모시키는 공격과 관련될 수도 있습니다.

반대로 정상 Client가 수천 대인 시스템에서도 비슷한 Traffic 양이 발생할 수 있습니다.

따라서 단순 Packet 개수만 보고 공격이라고 판단해서는 안 됩니다.

다음 정보를 함께 봅니다.

Source 분포
Connection Rate
Handshake 완료율
Server Resource
Firewall Log
Application Log
평소 Baseline

30장 TCP 장애를 현장에서 진단하는 순서#

TCP 연결이 되지 않는다면 아래에서 위로 확인하는 것이 좋습니다.

30.1 물리 계층#

전원
Cable
Link
FCS Error

30.2 Layer 2#

VLAN
MAC Address Table

30.3 Layer 3#

IP Address
Subnet Mask
ARP / NDP
Gateway
Routing

30.4 TCP Connection#

SYN이 나가는가?
↓
SYN-ACK가 돌아오는가?
↓
ACK가 완료되는가?

30.5 Application#

Server Process가 실행 중인가?
↓
올바른 Port를 Listen하는가?
↓
Application Protocol은 정상인가?

전체로 연결하면:

Link
↓
VLAN
↓
IP
↓
Routing
↓
TCP Handshake
↓
TCP Data
↓
Application

입니다.

31장 증상으로 TCP 장애 범위를 좁혀보자#

증상	우선 확인
SYN 자체가 안 나감	Application·Routing
SYN은 나가고 응답 없음	Routing·Firewall·Server
SYN 후 RST	Service Port·Firewall·Application
Handshake 정상, 데이터 없음	Application
Retransmission 증가	Packet Loss·지연·혼잡
Zero Window 반복	Receiver·Application 처리
RST 반복	Connection 강제 종료 원인
짧은 연결 반복	Application·Keepalive·Network 불안정
TCP 정상인데 업무 실패	Application Protocol·DB·장비 상태

32장 현장에서 반드시 구분해야 하는 네 가지 완료 상태#

주차관제 같은 제어 시스템에서는 특히 중요합니다.

1. Sent
2. TCP Received
3. Application Accepted
4. Physical Completed

예를 들어 차단기 OPEN이라면:

Server가 Command 전송
        ↓
TCP ACK 수신
        ↓
Controller가 Command Parsing
        ↓
OPEN 동작 시작
        ↓
Barrier 상승
        ↓
Open Sensor 확인

입니다.

따라서 시스템 로그도 가능하다면:

OPEN_SENT

OPEN_RECEIVED

OPEN_STARTED

OPEN_COMPLETED

처럼 구분하는 것이 장애 분석에 훨씬 유리합니다.

33장 TCP의 핵심 개념 한눈에 정리하기#

개념	역할
Connection	양 Endpoint 사이의 TCP 상태
3-Way Handshake	Connection 시작과 Sequence 동기화
Sequence Number	Byte Stream의 위치 관리
ACK	연속적으로 수신한 Byte 범위 확인
Retransmission	손실된 것으로 판단한 데이터 재전송
RTO	재전송 판단에 사용하는 Timeout
SACK	수신된 특정 Byte 범위를 추가로 알림
Receive Window	Receiver가 받을 수 있는 데이터 범위
Flow Control	Receiver Buffer 보호
Congestion Control	Network 혼잡에 따라 전송량 조절
FIN	정상적인 방향별 종료
RST	Connection 즉시 Reset
Keepalive	유휴 Connection 상태 확인 보조
TLS	TCP 위에서 암호화·인증 등을 제공

34장 TCP에서 자주 발생하는 오해#

34.1 TCP ACK가 오면 업무가 완료된 것이다?#

아닙니다.

TCP Stack이 데이터를 정상 수신했다는 의미와 Application 업무 완료는 구분해야 합니다.

34.2 TCP는 Packet의 순서를 보장한다?#

보다 정확하게는 Application에 순서가 맞는 Byte Stream을 제공합니다.

Application Message 단위 자체를 보장하는 것은 아닙니다.

34.3 send 한 번은 recv 한 번과 대응한다?#

아닙니다.

TCP는 Stream Protocol이므로 데이터가 합쳐지거나 나뉘어 읽힐 수 있습니다.

34.4 Retransmission이 보이면 TCP가 문제다?#

반드시 그렇지 않습니다.

Cable, Packet Loss, Congestion, Routing, Server 부하 등 다양한 원인이 TCP Retransmission으로 나타날 수 있습니다.

34.5 TCP를 사용하면 암호화도 된다?#

아닙니다.

TCP의 신뢰성과 TLS 같은 보안 기능은 서로 다른 문제입니다.

35장 자기 점검#

35.1 TCP를 신뢰성 있는 Protocol이라고 하는 가장 중요한 이유는 무엇인가#

Sequence Number, ACK, 재전송 등을 이용해 Byte Stream의 손실과 순서를 관리하고 Application에 순서가 맞는 데이터 전달을 제공하기 때문입니다.

35.2 3-Way Handshake의 역할은 무엇인가#

두 Endpoint가 TCP Connection 상태를 만들고 서로의 초기 Sequence Number 및 TCP 통신에 필요한 정보를 교환하기 위한 과정입니다.

35.3 ACK 번호는 무엇을 의미하는가#

일반적으로 Receiver가 연속적으로 받은 Byte 이후 다음에 기대하는 Sequence Number를 나타냅니다.

35.4 Flow Control과 Congestion Control의 차이는 무엇인가#

Flow Control은 Receiver의 처리 능력과 Buffer를 보호하기 위한 기능이고, Congestion Control은 Network 혼잡에 맞춰 Sender의 전송량을 조절하기 위한 기능입니다.

35.5 TCP ACK를 받았다면 차단기가 열렸다고 판단해도 되는가#

안 됩니다.

TCP ACK는 TCP 계층에서 데이터가 수신된 것을 의미할 뿐 실제 명령 처리나 물리 장비 동작 완료를 의미하지 않습니다.

업무 완료 여부는 별도의 Application 응답이나 장비 상태 확인이 필요합니다.

36장 이 글을 마치며#

TCP가 신뢰할 수 있는 통신이라고 불리는 이유는 단순히:

ACK를 사용하기 때문

만은 아닙니다.

여러 기능이 함께 작동합니다.

Connection
      ↓
Sequence Number
      ↓
ACK
      ↓
손실 감지
      ↓
Retransmission
      ↓
순서 복원
      ↓
중복 처리
      ↓
Flow Control
      ↓
Congestion Control

이 과정을 통해 TCP는 Application에 순서가 맞는 신뢰성 있는 Byte Stream을 제공합니다.

하지만 현장에서는 그 신뢰성이 어디까지인지를 정확하게 이해해야 합니다.

TCP ACK
↓
데이터가 TCP 계층에 도착

Application ACK
↓
Application이 명령을 인식하거나 수락

Device Status
↓
실제 장비 상태 변화

Physical Sensor
↓
실제 물리 동작 완료 확인

이 네 단계는 서로 같지 않습니다.

따라서 주차관제 시스템에서:

TCP 연결됨

이라는 사실만으로:

차단기 정상

결제 완료

차량정보 저장 완료

를 의미한다고 판단해서는 안 됩니다.

TCP 장애를 만났을 때도 마찬가지입니다.

Cable
↓
Ethernet
↓
IP
↓
Routing
↓
TCP Handshake
↓
Sequence / ACK
↓
Application
↓
실제 업무 처리

순서로 어느 단계에서 처음 문제가 발생했는지를 찾아야 합니다.

특히 다음 네 가지를 기억하면 TCP의 핵심을 제대로 이해한 것입니다.

TCP는 Packet이 아니라 순서가 있는 Byte Stream을 Application에 제공합니다.

Sequence Number와 ACK를 통해 손실·순서·중복을 관리합니다.

TCP ACK는 Application 처리 완료나 실제 장비 동작 완료를 의미하지 않습니다.

TCP의 신뢰성과 암호화·인증 같은 보안은 별개의 문제입니다.

이 개념이 잡히면 이후 TCP 3-Way Handshake 분석, Retransmission, Window, Timeout, Keepalive, Connection Reset과 같은 실제 Packet Capture도 단순한 용어 암기가 아니라 하나의 연결된 흐름으로 이해할 수 있습니다.