개발자들이라면 OSI 7계층에 관하여 지겹도록 들었을 것이다. 그 중에서도 전송계층에 속하는 TCP/UDP 는 면접 질문에서도 빠지지 않는 단골손님인데 그 특징에 대해 정리해 보려고 한다.
OSI 7계층
1계층은 물리 계층(Physical Layer) 이다. 이름에서부터 보이다시피 소프트웨어보다는 하드웨어에 가까운 계층이다. 전기 신호를 물리적으로 전송하는 기술에 대해 다루기 때문에, 전자공학이나 전기공학에 더 가깝다.
2계층은 데이터 링크 계층(Data Link Layer) 이다. 물리적으로 인접한 노드 간(node-to-node) 의 전송 기술을 다루는데, 이더넷(Ethernet) 이 대표적인 예이다. 노드 하면 그래프가 생각나겠지만, 이 때 노드는 근거리 통신망(LAN) 에서 연결된 다양한 컴퓨팅 장비들을 뜻한다. 통신망에서는 각 노드를 구별하기 위해 식별자가 필요한데, 이 때 MAC 주소를 사용한다. MAC 주소는 공장에서 하드웨어를 생산할 때 각인처럼 박히기 때문에 통상적으로 고유하고 수정할 수 없는 정보이다.
즉 1, 2계층까지는 대부분 하드웨어 영역에 속한다고 생각하면 된다.
3계층은 네트워크 레이어(Network Layer) 로, 우리가 잘 알고 있는 IP 주소가 이 계층에 속한다. 이 계층에서는 호스트 간(host-to-host) 전송 기술을 다루는데, 호스트 간 연결이라는 것은 2계층(데이터 링크 계층)을 통해 물리적으로 도착한 데이터를 식별해 네트워크에 연결된 내 컴퓨터와 상대방 컴퓨터 사이를 고유하게 구별하고 연결하는 것을 의미한다.
TCP 와 UDP 는 4계층인 전송 계층(Transport Layer) 에서 동작하는 프로토콜이다. 4계층은 프로세스 간(process-to-process) 의 전송 기술을 다룬다. 2계층에서는 노드, 3계층에서는 호스트(컴퓨터) 를 구분한 것에 비해 구별하는 범위가 상당히 좁아졌는데, 호스트보다 더 좁은 범위인 프로세스를 식별 가능하다는 것은 내가 실행 중인 프로그램이 전 세계에서 유일하게 식별 가능하다는 점에서 꽤 큰 의미를 지닌다.
하지만 호스트 내에서도 다양한 프로세스가 동시에 실행중일 수 있기 때문에 프로세스를 고유하게 식별하기 위해서 포트(Port) 번호가 필요하다. 이 중에서도 사전에 약속을 통해 특별하게 예약된 번호들(Well-known) 이 있다. (HTTP는 80번, HTTPS는 443번이 그 예이다.)
비유하자면 IP 주소는 아파트 주소와 같고 포트 번호는 집 호수와 같다. 그리고 일반적으로 둘을 합쳐서 소켓 주소(Socker Address)라는 이름으로 부른다.
이렇게 프로세스를 식별할 수 있는 주소를 이용하면 프로세스 간 통신이 가능하다. 이 때 두가지 방식을 이용해 통신이 가능한데, 연결 지향(Connection-Oriented) 방식과 비연결(Connectionless Protocol) 방식이 있다.
연결 지향 방식은 송신자와 수신자가 1:1로 연결 상태를 유지하면서 통신하는 것을 의미한다. 이 방식은 데이터를 보내기 전에는 연결 설정(Connection Establish) 단계를, 보낸 후에는 연결 종료(Connection Close) 단계를 거쳐야 한다. 데이터를 교환하는데 있어 좀 더 안전하고 믿을 수 있는 환경을 제공하지면, 교환 전후로 과정이 좀 더 복잡하다. 이 방식의 대표적인 예가 바로 TCP 이다.
한편, 비연결 방식은 송신자와 수신자가 연결 상태를 유지하지 않고 통신하는 것을 의미한다. 데이터 송신자는 수신자의 수신 여부와 상관없이 일방적으로 데이터를 뿌리고 끝낸다. 송신자 입장에선 간단한 방법이지만, 수신자의 입장에선 데이터가 정확한지도 알 수 없고, 데이터의 순서도 보장할 수 없으며, 심지어 못 받을 수도 있다. 이 방식의 대표적인 예가 바로 UDP 이다.
TCP
TCP 는 전송 제어 프로토콜(Transmission Control Protocol) 의 약자로, 연결 지향 방식임과 동시에 스트림 기반 방식으로도 불리운다. 이는 TCP 통신이 마치 가상의 연결선을 이용해 두 컴퓨터가 연속적으로 데이터 교환이 가능하게 하는 것처럼 보이기 때문이다.
위의 헤더 사진에서 볼 수 있듯이, 헤더에 담긴 데이터의 양이 상당히 무거운 편에 속하는 것을 알 수 있다. 좀 더 자세히 살펴보면 헤더에는 목적지 정보를 포함해 시퀀스 넘버, 승인 넘버(Acknowledgement Number), 제어 필드(Control Fields) 등 많은 데이터들이 담겨 있다.
▷ TCP 3가지 특징
1. 핸드쉐이크
TCP 는 연결 지향 방식이기 때문에 데이터 교환 전후로 연결 설정/해제 과정을 거치는데, 이를 핸드쉐이크(Handshake) 과정이라고 부른다. 연결 설정 단계에서는 3단계로 핸드쉐이크 과정을 진행하고, 연결 종료 단계에서는 4단계의 핸드쉐이크 과정을 거친다.
2. 신뢰성과 흐름 제어
TCP 의 중요한 특징이 바로 신뢰성과 흐름 제어 기능이다. 이는 TCP 의 최초 개발 동기가 군사적인 목적이었기 때문이다. TCP 는 데이터를 교환함과 동시에 헤더에 기록된 정보를 이용해 데이터의 신뢰성 제어와 흐름 제어를 동시에 진행한다.
3. 혼잡도 제어
만약 A라는 프로세스가 통신을 진행 중인데, 다른 프로세스가 또 통신을 시도하려고 한다면 어떻게 해야 할까? 하나의 TCP 에서 처리하고 수용할 수 있는 리소스의 양은 정해져있으니, 아마 A가 쓰고 있는 리소스를 절반 정도 떼어서 B가 쓸 수 있게 주어야 할 것이다. 이것이 어떻게 가능할까?
이는 TCP 가 각 네트워크에 할당되는 리소스를 늘려나가는데, 이 과정에서 오류가 발생하면 리소스를 초기화하는 과정을 거치게 됨으로써 가능한 것이다.
UDP
UDP 는 사용자 데이터그램 프로토콜(User Datagram Protocol) 의 약자이다. 데이터그램은 쉽게 말해 사용자가 전달하고자 하는 데이터를 네트워크로 전송하기 위해, 통신 정보 등을 담은 헤더를 씌운 독립적인 패킷(Packet) 이라고 생각하면 된다.
위의 헤더 사진을 보면 알 수 있듯이, 프로세스 간 통신을 위한 정보를 제외하고는 아무런 정보도 더하지 않는다. 왜 포트 번호만 붙어 있는지 의아하게 생각할 수도 있는데, IP 주소는 4계층이 아닌 3계층에서 다루기 때문에 3계층에 도달해서야 IP 헤더가 붙게 된다. (이는 TCP 에서도 마찬가지이다.)
체크섬 정도의 오류 검출 기능은 있지만, 이것만으로는 복잡한 데이터를 검증하기가 대단히 어렵기 때문에 통신에서 발생할 수 있는 예외 처리 기능들을 직접 구현해야 하는 어려움이 있다.
그리고 데이터들이 독립적인 패킷으로 전송되는데다가 헤더 자체에는 순서와 관련된 정보가 없기 때문에 수신 측에서 알아서 순서를 재조립해야 한다. 만약 중간에 패킷이 손실되어도 프로토콜 자체적으로 손실을 알아낼 방법이 없다.
따라서 UDP 는 실시간성이 중요하거나 데이터의 신뢰성이 굳이 보장되지 않아도 되는 곳에 사용한다.
헤더만큼이나 동작 과정 역시 간단하다.
각 프로세스가 시작되면 운영체제로부터 포트 번호를 부여받게 된다. 이때 UDP 는 해당 프로세스를 식별할 수 있는 포트와 통신하기 위해 버퍼 역할을 하는 두 개의 큐(Queue) 를 만들고 연결하게 된다. 큐는 송신용 목적인 송신 큐(Outgoing Queue), 수신용 목적인 수신 큐(Incoming Queue) 로 구분된다.
프로세스에서 만약 데이터를 외부로 전송하기 위해 송신 큐에 데이터를 밀어넣으면, UDP 는 프로세스에서 보낸 데이터를 하나씩 읽고 헤더를 붙여서 3계층(IP) 으로 넘겨준 후 송신 큐에서 제거한다.
그렇다고 해서 프로세스가 무작정 송신 큐에 막대한 데이터를 집어넣다간 자칫 오버플로우가 발생할 수 있다. 그래서 보통 운영체제에서는 송신 큐에 오버플로우가 발생하지 않게 따로 관리를 해준다.
수신 큐 역시 비슷하게 동작한다. 3계층(IP) 에서 수신된 패킷이 있다면, 이를 분석하여 통신하고자 하는 프로세스의 포트 번호와 연결을 시도한다. 만약 현재 컴퓨터에 해당 포트 번호를 가진 프로세스가 있다면 패킷에서 통신 과정에 필요했던 헤더 정보를 벗겨낸 후 이를 프로세스로 보내게 된다.
HTTP/3 부터는 더 이상 TCP가 아니라 UDP 위에서 동작한다는 사실은 모두들 잘 알고 있는 사실일 것이다. 그렇기 때문에 두 프로토콜 사이의 차이점을 인지하고 있는 것이 중요하다고 생각한다.
(참조: https://wormwlrm.github.io/2021/09/23/Overview-of-TCP-and-UDP.html)