TCP / IP
TCP / IP vs OSI 7 Layer
OSI 7 Layer는 통신 표준이라는 말을 사용하고, TCP/IP는 산업 표준이라는 말을 사용한다. 왜 OSI가 더 정교하게 분류 해 놓았는데 산업에서는 TCP/IP를 사용하는지에 대한 의문이 생긴다. 여기에는 확신할 순 없지만 복합적인 배경이 있었다고 생각한다.
TCP/IP가 1970년대 미국 국방부(DARPA)의 ARPANET 프로젝트로 개발되었다. 반면 OSI는 1980년대 국제표준화기구(ISO) 주도로 이론적이고 이상적인 모듈화를 위해 설계 되었다.
여기서 많은 공학도들은 감을 잡았을 것이다. 이론과 이상을 쫓게되면 실제 구현과 적용에 대해서 복잡도가 올라가고, 결국 이익을 내어야 하는 집단에서의 복잡도 증가는 비용문제로 이어진다. 심지어 이미 TCP/IP가 세상에 먼저 나와서 산전수전 다 겪고 적응해 있는 상황에서 산업 환경에서 무리하게 OSI를 채택할 필요가 없었다.
그럼에도 불구하고 이론적, 분석적으로 OSI가 뛰어난 모델임에는 틀림이 없고 지금까지 교육과 분석의 목적으로 사용하게 되었다. 산업에서의 표준은 성능이나 완벽함이 아니라 결국 실용적 우위와 이에 대한 수요에 의해서 지정됨을 증명하는 사례라고 본다.
그래서 결론은 OSI와 TCP/IP가 어떻게 다른가 이다. 위에서 시대적인 배경을 설명했듯 TCP/IP가 더 먼저 나온 구조이다. 사실상 동일한 구조를 더 세부적으로 나눈 것이 OSI 7 Layer 라고 보아도 무방하다.
Application 계층에서는 OSI에서의 Application, Presentation, Session의 역할을 하나로 본 것이다. 이전에 Upper Layer는 Software적인 레이어라고 설명한 적이 있다. 이런 특성을 하나의 계층으로 통합되어져 있는 형태이다. 때문에 세션관리, 암호호, 데이터 변환이 모두 해당 계층에서 이루어 진다. 예시로 HTTPS는 HTTP에 TLS 암호화를 합친 하나의 프로토콜로 본다. 만약 이를 Application 수준의 HTTP와 Presentation 수준의 TLS를 따로 구분하여 사용했다면 매우 불편했을 것이다.
Transport 계층은 OSI와 거의 동일하게 수행한다. 다른점은 OSI에서는 Transport Layer가 순수하게 전송 기능만 담당하고 세션 관리 및 데이터 표현, 암복호화는 Presentation Layer에서 수행 했다. 하지만 TCP/IP의 Transport 계층에서는 일부 세션 관리 기능도 포함 되어 있으며 TCP 자체에서 연결 설정 및 해제를 진행하는 3-way handshake를 담당한다.
Internet 계층은 IP 프로토콜에 특화된 계층이다. OSI의 Network 계층에서는 IP 프로토콜 뿐만 아니라 다양한 네트워크 프로토콜을 지원했다. 하지만 TCP/IP에서는 이 IP 프로토콜에 집중한 계층 구조이다.
Network Access 계층은 OSI의 Physical 계층과 Data Link 계층을 통합한 계층이다. 실제 동작은 두 모델이 동일하지만, TCP/IP모델에서는 이 두 계층을 하나로 묶어서 표현한다. 초기에는 "네트워크에 접근하는 방법" 정도로 계층을 바라보고 디자인 했었지만, 시간이 흘러 이를 분해해보니 MAC 주소를 찾는 부분과 실제 물리적으로 전송하는 부분을 분리하는게 좋겠다고 생각하여 OSI에 반영되었다고 보면 된다. 즉, OSI 모델이 TCP/IP의 Network Access 계층을 좀 더 세분화 하여 명확히 구분한 것 뿐이다. 사실상 내부적으로 MAC 주소를 사용하고 프레임을 구성하는 작업들은 동일하다.
TCP / IP Protocol Suite
그럼 실제로 TCP/IP에 대한 프로토콜들이 어떤 식으로 분류되어 있는지 확인해볼 필요가 있다.
Application Layer에서는 우리가 일상적으로 사용하는 서비스들이 모여있다. 웹 브라우징을 하는 HTTP, 이메일 관련 작업을 하기위한 SMTP 및 POP3, 도메인 이름을 IP로 변경해주는 DNS, HTTP와 TLS가 결합하여 암호화 프로토콜을 구사하는 HTTPS. OSI 모델처럼 Application, Presentation, Session을 따로 구분하지 않고 하나의 프로토콜 안에서 모든 기능을 처리한다.
Transport Layer는 단순하게도 TCP, UDP가 주로 사용된다. TCP는 신뢰성이 중요한 웹, 이메일과 같은 통신에 사용되고, UDP는 속도가 중요한 게임이나 스트리밍. 특히, 실시간성을 요구하는 통신에서 사용된다. 위에서 언급했듯이 OSI와 다른 점은 TCP에서 연결 설정과 해제까지 담당한다는 점이다.
Internet Layer는 결국 IP가 핵심 프로토콜이다. IPv4나 IPv6가 실제 주소 체계를 담당한다. ICMP나 ARP, RARP와 같은 프로토콜도 있지만, 재미있게도 같은 Internet 계층에서도 이를 더 쪼개서 높고 낮은 계층을 갖게 한다. 그래서 ARP, RARP < IP < ICMP와 같은 내부 계층을 갖고 있다. ICMP는 ping이나 traceroute와 같은 진단 도구에 사용된다. ARP는 IP 주소를 MAC 주소로, RARP는 MAC 주소를 IP주소로 변환시키는 역할을 한다.
Network Access Layer에서는 Ethernet이 가장 많이 사용되고, Wi-Fi와 같은 무선 프로토콜도 해당 계층에 소속된다. 여기서 중요한 점은 위에서 언급했듯 실제 하드웨어 기술들을 하나의 계층으로 묶어서 처리한다는 점이다.
이러한 Protocol Suite을 보면 왜 사람들이 OSI로 갈 수 없었는지 조금 체감이 된다. 추상화로 인해 더 실용적이고 단순하게 설계되어 있으며 실제 인터넷은 해당 프로토콜들로 돌아가고 있다.
TCP vs UDP
TCP
TCP는 연결 지향 프로토콜이다. 데이터 전송 전에 3-way handshake로 연결을 확보하고 데이터를 전송한다. 이후 4-way handshake 혹은 RST(RESET)를 수행하여 연결 종료를 수행한다.
위 그림과 같이 SYN > SYN ACK > ACK로 연결을 유지시킨다. 이후 원하는 정보를 요청하고 응답하여 정보를 주고 받고 FIN > ACK > FIN > ACK를 통해서 연결을 해제한다. 각 handshake 기법에 대해서는 아래에서 다뤄보자.
3-way handshake
SYN은 Synchronize를 의미하며 동기화 하자는 메시지를 의미한다. ACK는 Acknowledgement를 의미하며 받은 데이터를 확인했다고 알리는 메시지이다. 서버는 클라이언트의 SYN을 받기 전까지 LISTEN 상태에 들어가 있는다. 클라이언트가 서버에게 SYN을 요청하게 되고 SYN_SENT 상태로 변경한다. 이때, 서버는 SYN_RCVD 상태에 돌입하게 되고 SYN 요청에 대한 ACK와 자신과 연결하기 위한 정보인 SYN를 동시에 보낸다. SYN를 받은 클라이언트는 ESTAB 상태로 판정하며 서버에게 ACK를 보낸다.
클라이언트 (SYN):
"서버야 연결해줘. 참고로 지금 데이터 순서 시작 번호는 1000, 수신 버퍼는 65535 bytes, 최대 세그먼트 크기는 1460 bytes야"
서버 (SYN-ACK):
"그래 클라이언트야 연결하자. 순서 시작 번호 1000 잘 받았어. 참고로 내 순서 시작 번호는 2000, 수신 버퍼는 32768 bytes, 최대 세그먼트 크기는 1460 bytes야"
클라이언트 (ACK):
"너의 순서 시작 번호 2000 잘 받았어."
+ 궁금증
여기서 왜 순서 시작 번호를 0으로 약속하지 않고 가변적으로 선택하게 되는지 의문이 생긴다. 크게 두 가지 이유가 있었다. 첫번째는 "연결 혼동 문제"이다. 같은 클라이언트가 서버에 연속으로 연결하면 앞에 연결된 패킷이 지연되어 늦게 도착하면 이를 오인하고 잘못 받아들일 수 있다. 두번째는 "보안 취약점"이다. 만약 0부터 시작하게 약속되어 있다면 공격자는 데이터의 조각을 가지고 순서를 너무 쉽게 짐작할 수 있을 것이다. 더 적극적으로는 서버에 0에 가까운 순서번호를 부여해서 지속적으로 보내면 원치않는 정보를 수신하게 만들 수 도 있을 것이다. 그래서 예측할 수 없고 이전과 섞이지 않게 하기 위해 연결때마다 새로운 번호를 사용한다.
+ 궁금증
여기서 같은 연결임을 결정하는 요소가 무엇인지 궁금해진다. TCP 연결은 5-tuple이라고 불리는 5개의 요소로 유일하게 식별한다.
- 출발지 IP 주소 (Source IP)
- 출발지 포트 번호 (Source Port)
- 목적지 IP 주소 (Destination IP)
- 목적지 포트 번호 (Destination Port)
- 프로토콜 (TCP)
4-way handshake
FIN은 FINAL를 의미한다. 연결 유지 상태인 ESTAB(Established) 상태인 클라이언트가 서버에 요청을 중단하고자 FIN을 보낸다. 이 때, 클라이언트는 FIN에 대한 응답을 기다리는 FIN_WAIT_1 상태에 들어간다. FIN 요청을 받은 서버는 CLOSE_WAIT 상태에 들어가고 클라이언트에게 FIN에 대한 ACK를 보낸다. ACK를 받은 클라이언트는 서버의 FIN을 대기하는 상태인 FIN_WAIT_2에 들어가게 된다. 이렇게 다시 한번 서버의 FIN을 기다리는 이유는 서버가 필요한 데이터 전송이 끝나지 않았을 수 있기 때문에 클라이언트는 확실하게 서버의 FIN 요청을 대기하게 된다. 서버는 FIN 요청을 클라이언트에게 보내고 마지막 ACK를 기다리는 LAST_ACK 상태에 들어간다. 서버에게 FIN 요청을 받은 클라이언트는 CLOSED 상태에 돌입하기 위한 타이머를 동작시키고 서버에게 ACK를 보낸다. ACK를 받은 서버는 즉시 CLOSED 상태에 들어가게 된다. 하지만, 클라이언트는 기존에 설정해두었던 타이머가 종료되어야 비로소 CLOSED 상태에 들어가게 된다.
클라이언트 (FIN):
"서버야 나 이제 보낼게 없어. 송신 종료할게"
서버 (ACK):
"확인했어"
클라이언트:
"서버가 더 보낸게 있을 수 있으니까 기다려보자."
FIN (서버):
"클라이언트야 나도 이제 송신 종료할게"
클라이언트:
"혹시 모르니까 몇 분뒤에 종료해야겠다. (타이머 설정)"
ACK (클라이언트):
"확인했어"
+ 궁금증
굳이 ACK를 보내고 바로 종료하지 않고 타이머를 맞춰놓고 ACK를 보내고도 타이머가 끝나야 종료되는지 궁금할 것이다. TCP는 결국 신뢰성이 핵심 설계 철학이다. "마지막 ACK를 서버가 받아서 잘 종료하는 것"까지가 신뢰성인 것이다. 만약 마지막 ACK 이후 바로 종료되게 설계 했다면 아래와 같은 문제 상황이 발생할 것이다.
서버는 클라이언트로부터 ACK가 잘 도착하지 않으면 FIN을 다시보낸다. 이 때 클라이언트는 이미 CLOSED 상태에 돌입했으므로 해당 요청은 허용되지 않은 전송으로 간주하고 RST를 전송한다. 이 때 서버는 RST 응답을 확인하고 연결 유지가 불가능하다고 판정하여 비정상 종료를 하게 된다. 이처럼 비정상 종료가 발생하지 않는 신뢰성 있는 프로토콜을 만들기위해 설계한 것이 TCP이므로 이를 방지하고자 타이머를 통해서 서버가 ACK를 받지 못한 상황에 대해 유예시간을 두는 것이다.
UDP
UDP는 TCP와는 정반대로 신뢰성이 없고 빠른 전송이 목표인 프로토콜이다. 한 번 요청이 오면 계속 응답으로 데이터를 전송한다. 일반적으로 TV를 떠올리면 이미지하기 쉽다. 축구 생중계를 보고있는데 연결이 불안정해서 잠깐 끊겼다. 이 때 TV는 끊기고 나서 끊긴 부분부터 보여주는 것이 아니라 지금 당장 진행되고 있는 부분부터 보여줄 것이다. 이렇듯 실시간성이 중요하고 이전에 발생한 누락된 정보가 크게 중요치 않은 경우 사용하는 프로토콜이다.
IPv4 Addressing
IPv4 기본 구성
Class
Reserved Address
Subnet Mask
Subnetting
Host to Host
Network to Network
'Basic > Network' 카테고리의 다른 글
| 2. OSI 7 Layer (0) | 2025.07.21 |
|---|---|
| 1. Network (0) | 2025.07.21 |