도입
많은 사람이 TCP/IP를 하나의 단일 프로토콜처럼 부르지만, 실제로는 인터넷 통신을 구성하는 계층형 프로토콜 모음을 가리키는 표현에 가깝습니다.
이 구조에서 IP는 패킷을 어느 주소로, 어떤 경로를 거쳐 보낼지를 담당하고, TCP는 그 위에서 순서 번호, 확인 응답, 재전송, 윈도우 제어를 통해 데이터를 더 믿을 수 있게 만듭니다. 결국 TCP/IP를 이해한다는 것은 “패킷이 어디로 가는가”와 “그 패킷이 어떻게 올바른 바이트 스트림으로 복원되는가”를 동시에 이해하는 일입니다.
필요성
실무에서 발생하는 네트워크 문제는 생각보다 다양한 층에 걸쳐 있습니다. 어떤 문제는 IP 주소나 라우팅의 문제이고, 어떤 문제는 TCP 연결 수립이 안 되는 문제이며, 어떤 문제는 연결은 됐지만 손실 때문에 재전송이 반복되는 문제입니다.
그래서 TCP/IP는 시험용 이론이 아니라, 백엔드 타임아웃, API 지연, 대용량 전송, 데이터베이스 연결, 프록시 환경, 방화벽 정책, 성능 튜닝을 읽는 기본 언어에 가깝습니다. 이 구조를 모르면 증상은 보이는데 원인을 계층별로 나누지 못하게 됩니다.
- 서버는 살아 있는데 클라이언트 연결이 성립하지 않는 경우
- 연결은 되지만 데이터 전송이 매우 느리거나 끊기는 경우
- 패킷 손실과 재전송 때문에 응답 시간이 흔들리는 경우
- 포트 오픈 여부와 실제 애플리케이션 가용성을 구분해야 하는 경우
- 방화벽, 프록시, 로드밸런서, NAT 환경에서 병목을 나눠 봐야 하는 경우
정의
정확히 말하면 TCP/IP는 TCP와 IP 두 개만의 묶음이 아닙니다. 인터넷 통신을 위해 호스트가 구현해야 하는 계층형 프로토콜 집합 전체를 가리키며, 일반적으로 application layer, transport layer, internet layer, link layer로 설명합니다.
이 안에서 TCP는 전송 계층의 대표 프로토콜이고, IP는 인터넷 계층의 대표 프로토콜입니다. 즉, 둘은 서로 같은 층의 경쟁자가 아니라 서로 다른 층에서 협력하는 관계입니다.
핵심 원리
인터넷 아키텍처에서는 라우터가 개별 IP 데이터그램을 독립적으로 전달하는 쪽에 가깝고, 종단 간 신뢰성·흐름 제어·연결 상태 같은 정보는 주로 호스트의 transport layer 또는 application이 담당합니다.
이 구조 덕분에 네트워크 중간 장비는 상대적으로 단순한 전달 역할에 집중하고, 연결의 의미와 상태는 양 끝점이 관리합니다. TCP/IP를 깊게 이해하려면 단순한 계층 암기보다 이 종단 중심 설계를 먼저 잡는 것이 중요합니다.
TCP/IP 계층 구조
| 계층 | 주요 역할 | 대표 포인트 |
|---|---|---|
| Application | 애플리케이션 데이터의 의미와 규칙 정의 | 요청/응답, 이름 해석, 파일 전송 같은 상위 규칙 |
| Transport | 종단 간 통신 서비스 제공 | TCP, UDP 같은 전송 프로토콜 |
| Internet | 네트워크를 가로지르는 데이터그램 전달 | IP 주소, 라우팅, 데이터그램 전달 |
| Link | 직접 연결된 네트워크 링크에서 프레임 전송 | 실제 매체와 맞닿는 가장 아래 통신 영역 |
여기서 자주 헷갈리는 부분은 TCP/IP 모델과 OSI 모델을 완전히 같은 것으로 보는 시선입니다. TCP/IP의 application layer는 흔히 OSI의 상위 여러 층을 넓게 포함하는 쪽에 가깝고, link layer 역시 OSI와 정확히 1:1 대응시키기보다 직접 연결된 링크에서 필요한 통신 책임으로 보는 편이 더 자연스럽습니다.
IP의 역할
IP의 기본 단위는 데이터그램입니다. IP는 소스와 목적지 주소를 보고 패킷을 전달하며, 필요하면 라우터를 여러 번 거쳐 다른 네트워크로 이동시킵니다.
중요한 점은 IP가 종단 간 신뢰성을 약속하지 않는다는 것입니다. 데이터그램은 손상될 수도 있고, 중복될 수도 있고, 순서가 바뀔 수도 있으며, 아예 도착하지 않을 수도 있습니다. 이 때문에 신뢰성과 순서 보장은 IP 위의 transport layer, 특히 TCP가 맡게 됩니다.
- 한다 : 주소 지정, 데이터그램 전달, 경로 선택의 기반 제공, 네트워크 간 전달
- 하지 않는다 : end-to-end ACK, 순서 보장, 재전송, 흐름 제어
TCP의 역할
TCP는 전송 계층 프로토콜로, 애플리케이션 입장에서는 “상대와 바이트 스트림을 주고받는 연결”처럼 보이게 만듭니다. 여기서 중요한 표현이 byte-stream입니다. 즉, TCP는 메시지 경계를 보존하는 프로토콜이 아니라, 바이트들의 순서를 보존하는 프로토콜입니다.
이 신뢰성은 자동으로 생기지 않습니다. TCP는 sequence number로 데이터의 위치를 식별하고, acknowledgment로 어디까지 받았는지 알리고, 손실이 감지되면 retransmission으로 다시 보내고, window로 동시에 흘릴 수 있는 양을 조절합니다.
| TCP 메커니즘 | 의미 | 실전 해석 |
|---|---|---|
| Source / Destination Port | 어떤 서비스와 흐름인지 구분 | 같은 호스트 안에서도 여러 애플리케이션을 구분 |
| Sequence Number | 이 세그먼트 데이터의 위치 표시 | 손실 감지와 순서 재조립의 기준 |
| Acknowledgment Number | 다음에 받고 싶은 바이트 위치 표시 | 어디까지 정상 수신했는지 표현 |
| Window | 지금 받아 줄 수 있는 데이터 양 | 수신자 과부하를 막는 흐름 제어 |
| Checksum | 세그먼트 무결성 검증 | 오염된 세그먼트 검출 |
| SYN / ACK / FIN / RST | 연결 상태와 제어 신호 | 연결 수립, 확인, 종료, 비정상 리셋에 사용 |
패턴 1. 캡슐화와 디캡슐화
송신 측에서는 애플리케이션 데이터가 바로 네트워크에 던져지는 것이 아닙니다. 각 계층이 자기 책임에 맞는 정보를 붙이면서 내려갑니다. 이를 보통 캡슐화라고 부릅니다.
송신 측
애플리케이션 데이터
→ TCP가 포트 / 순서 / ACK / 윈도우 / 체크섬을 붙여 세그먼트 생성
→ IP가 소스 / 목적지 주소 기반 전달 정보를 붙여 데이터그램 생성
→ Link 계층이 실제 전송용 프레임으로 내보냄
수신 측
프레임 수신
→ IP 헤더 처리
→ TCP 세그먼트 재조립 / ACK / 순서 확인
→ 애플리케이션에 바이트 스트림 전달이 과정을 이해하면 “왜 애플리케이션은 MAC 주소를 모르는데도 통신하는가”, “왜 포트와 IP 주소가 동시에 필요한가”, “왜 패킷은 도착했는데 애플리케이션 데이터는 아직 완성되지 않았는가” 같은 질문이 한꺼번에 정리됩니다.
패턴 2. TCP 연결 수립
TCP는 연결 지향형 프로토콜이기 때문에, 데이터 전송 전에 양쪽이 서로 준비 상태를 맞추는 절차가 필요합니다. 이것이 유명한 3-way handshake입니다.
1) Client → Server : SYN
2) Server → Client : SYN + ACK
3) Client → Server : ACK
이후 ESTABLISHED 상태에서 데이터 전송 시작이 절차는 단순히 “서버가 살아 있는지 확인”하는 수준이 아닙니다. 양쪽의 초기 sequence number를 맞추고, 과거에 네트워크 어딘가에 남아 있던 오래된 중복 SYN 때문에 새 연결이 잘못 열리는 일을 줄이기 위한 설계입니다.
그래서 패킷 캡처에서 SYN만 보이고 SYN+ACK가 돌아오지 않으면 네트워크 경로, 방화벽, 서버 리스닝 상태를 먼저 의심하고, SYN+ACK까지 왔는데 최종 ACK가 완성되지 않으면 클라이언트 측 응답 경로나 정책 문제를 분리해 볼 수 있습니다.
패턴 3. 흐름 제어와 혼잡 제어
둘 다 “얼마나 많이 보내도 되는가”를 다루지만, 보호 대상이 다릅니다. 이 차이를 모르면 네트워크가 막혔는지, 수신 프로세스가 느린지, 송신자가 너무 공격적인지 판단이 엉킵니다.
| 구분 | 무엇을 보호하나 | 핵심 변수 | 설명 |
|---|---|---|---|
| Flow Control | 수신자 | rwnd (advertised window) |
수신자가 지금 받아 줄 수 있는 양을 광고해 과부하를 막음 |
| Congestion Control | 네트워크 | cwnd (congestion window) |
네트워크 상황을 보며 송신자가 투입량을 조절함 |
혼잡 제어 쪽에서는 보통 slow start, congestion avoidance, fast retransmit, fast recovery 같은 용어가 나옵니다. 반면 흐름 제어는 수신자의 advertised window를 중심으로 봅니다.
포트 번호
TCP는 포트 번호를 사용해 애플리케이션 서비스를 식별하고 여러 흐름을 다중화합니다. 즉, 같은 IP 주소라도 포트가 다르면 서로 다른 서비스로 분리할 수 있습니다.
| 범위 | 분류 | 의미 |
|---|---|---|
| 0 - 1023 | System Ports | 잘 알려진 시스템 서비스에 주로 사용 |
| 1024 - 49151 | User / Registered Ports | 등록된 사용자 서비스 범위 |
| 49152 - 65535 | Dynamic / Private Ports | 임시 포트, 에페멀 포트 용도로 자주 사용 |
다만 포트 번호가 등록되어 있다고 해서 그 트래픽이 자동으로 정상이라는 뜻은 아닙니다. 운영에서는 “포트 번호가 무엇인가”보다 “실제로 어떤 프로세스가 어떤 의미의 데이터를 흘리고 있는가”를 함께 봐야 합니다.
한계와 주의점
IP는 원래 손실, 지연, 재정렬, MTU 차이 같은 다양한 네트워크 조건을 견디도록 설계된 계층입니다. 그래서 “패킷이 항상 완벽하게 순서대로 도착한다”는 가정은 맞지 않습니다.
TCP는 이 불완전한 기반 위에서 신뢰성을 만듭니다. 그 대가로 연결 상태, handshake, 재전송, 윈도우 제어, 혼잡 제어 같은 추가 비용이 들어갑니다. 따라서 TCP는 강력하지만 공짜는 아니며, 모든 전송이 자동으로 최저 지연을 보장하는 것도 아닙니다.
- TCP/IP는 TCP와 IP만의 묶음이 아니라 계층형 인터넷 프로토콜 스위트다
- IP는 best-effort 전달 계층이지 신뢰성 계층이 아니다
- TCP는 메시지 프로토콜이 아니라 byte-stream 프로토콜이다
- 인터넷 계층의 IP는 오늘날 IPv4와 IPv6라는 두 주요 버전으로 존재한다
- 모든 transport가 TCP인 것은 아니며 UDP도 중요한 transport 프로토콜이다
자주 하는 실수
- TCP/IP를 하나의 단일 프로토콜로 오해함
- IP가 신뢰성과 순서를 보장한다고 착각함
- TCP가 메시지 경계를 그대로 보존한다고 생각함
- 3-way handshake를 단순 생존 확인 정도로만 이해함
- flow control과 congestion control을 같은 것으로 봄
- 포트 번호 = 애플리케이션 정상 동작이라고 단순화함
디버깅
SYN → SYN+ACK → ACK가 완성되는지 확인해 handshake 구간을 먼저 점검한다.요약
- ✅ TCP/IP는 하나의 프로토콜이 아니라 계층형 인터넷 프로토콜 스위트다.
- ✅ TCP/IP 모델은 보통 application, transport, internet, link 계층으로 설명한다.
- ✅ IP는 주소와 데이터그램 전달을 담당하지만 end-to-end 신뢰성은 보장하지 않는다.
- ✅ TCP는 sequence number, ACK, retransmission, window, checksum으로 신뢰성과 순서를 만든다.
- ✅ 3-way handshake는 초기 sequence number 동기화와 오래된 중복 연결 요청 방지에 핵심적이다.
- ✅ flow control은 수신자를, congestion control은 네트워크를 보호한다.
- ✅ 포트 번호는 호스트 안에서 어떤 서비스와 통신하는지를 구분한다.
- ✅ TCP/IP 문제는 IP 계층 문제와 TCP 계층 문제를 분리해 봐야 빨리 해결된다.