데이터를 쪼개고 다시 맞추는 TCP와 UDP

왜 IP 주소만으로는 부족할까

이름을 주소로 바꾸는 DNS에서 우리는 web.example.local 같은 이름이 192.168.20.10 같은 IP 주소로 바뀌는 과정을 보았다. 이제 클라이언트는 서버의 위치를 안다. 라우터도 그 IP 주소를 보고 어느 길로 보내야 하는지 판단할 수 있다.

그런데 여기서 한 가지 문제가 남는다.

서버 컴퓨터 한 대 안에는 여러 프로그램이 동시에 실행될 수 있다. 웹 서버도 있고, DNS 서버도 있고, 원격 접속 프로그램도 있을 수 있다. 패킷이 서버 컴퓨터까지 도착했다고 해서 끝이 아니다. 그 안의 어느 프로그램에게 전달해야 하는지 정해야 한다.

이때 사용하는 번호가 포트 번호다. 포트 번호는 건물 안의 방 번호에 가깝다. IP 주소가 건물 주소라면, 포트 번호는 그 건물 안에서 어느 창구로 가야 하는지 알려 주는 번호다.

다만 비유는 여기까지다. 실제 포트는 랜 케이블을 꽂는 물리적인 구멍이 아니다. 컴퓨터 안에서 운영체제가 프로그램을 구분하기 위해 쓰는 논리적인 번호다. 한 방 안의 작은 네트워크를 만들 때 말한 스위치의 포트는 케이블을 꽂는 구멍이고, 이번 장의 포트 번호는 프로그램을 찾는 번호다.

AI 생성 이미지

우리가 관찰할 통신

작은 인터넷에서 이런 장면을 떠올려 보자.

• 클라이언트: 192.168.10.11

• 웹 서버: 192.168.20.10

• DNS 서버: 192.168.20.53

• 웹 이름: web.example.local

클라이언트가 브라우저에 web.example.local을 입력한다. 먼저 DNS 서버에 이름을 묻는다. DNS 서버는 192.168.20.10이라는 주소를 알려 준다. 이제 클라이언트는 웹 서버로 요청을 보낸다.

이때 패킷 안에는 대략 이런 정보가 함께 들어간다.

• 출발지 IP: 192.168.10.11

• 목적지 IP: 192.168.20.10

• 출발지 포트: 클라이언트가 임시로 고른 번호

• 목적지 포트: 웹 서버가 기다리는 번호

• 사용할 방식: TCP 또는 UDP

여기서 출발지 포트는 답장을 받기 위한 임시 창구다. 클라이언트 컴퓨터 안에서도 브라우저 탭, 채팅 앱, 업데이트 프로그램이 동시에 네트워크를 쓸 수 있다. 서버의 응답이 돌아올 때는 이 번호가 응답 패킷의 목적지 포트가 된다. 그러면 클라이언트 운영체제는 "이 응답은 아까 요청한 브라우저에게 돌려주면 되겠구나"라고 판단한다.

목적지 포트는 서버 쪽 프로그램을 찾는 번호다. 웹 서버는 보통 TCP 80번 또는 TCP 443번에서 기다린다. DNS 서버는 보통 53번 포트를 사용한다. 중요한 점은 번호만이 아니라 TCP인지 UDP인지도 함께 맞아야 한다는 것이다. 같은 53번이라도 UDP 53번과 TCP 53번은 서로 다른 입구처럼 다룬다.

IP가 길을 찾는다면, 포트는 도착한 컴퓨터 안에서 받을 프로그램을 찾는다.

TCP: 확인하면서 보내는 배달 방식

인터넷에서 데이터는 한 덩어리로 통째로 이동하지 않는다. 큰 편지를 여러 장으로 나누어 봉투에 담듯이, 데이터도 작은 조각으로 나뉘어 이동한다. 이 조각을 TCP에서는 보통 세그먼트라고 부른다. 세그먼트는 프로그램 데이터에 순서 번호와 확인 정보를 붙인 작은 묶음이다.

TCP는 Transmission Control Protocol의 줄임말이다. 쉽게 말하면 "확인하면서 보내는 배달 방식"이다.

TCP는 데이터를 보내기 전에 먼저 상대가 받을 준비가 되었는지 확인한다. 이 과정을 연결을 맺는다고 말한다. 전화 통화에 비유하면, 말을 시작하기 전에 상대가 전화를 받았는지 확인하는 단계다.

연결이 만들어지면 TCP는 다음 일을 한다.

1. 데이터를 작은 조각으로 나눈다.

2. 각 조각에 순서 번호를 붙인다.

3. 받은 쪽은 어디까지 잘 받았는지 알려 준다.

4. 빠진 조각이 있으면 보내는 쪽이 다시 보낸다.

5. 순서가 바뀌어 도착하면 받은 쪽에서 다시 맞춘다.

인터넷의 길은 항상 일정하지 않다. 어떤 조각은 빠르게 도착하고, 어떤 조각은 늦게 도착할 수 있다. 중간에서 사라지는 조각도 있을 수 있다. TCP는 이런 상황을 예상하고, 조각마다 번호표를 붙여 둔다. 받은 쪽은 번호표를 보고 원래 순서대로 다시 맞춘다.

택배로 비유하면 TCP는 송장 번호가 붙은 택배다. 받는 쪽이 "1번, 2번, 3번은 받았고 4번이 없습니다"라고 알려 줄 수 있다. 그러면 보내는 쪽은 빠진 부분을 다시 보낸다.

이 방식은 정확하다. 대신 확인 절차가 많다. 연결을 맺고, 받은 사실을 확인하고, 빠진 조각을 다시 보내야 하므로 시간이 조금 더 걸릴 수 있다.

그래서 웹 페이지, 파일 다운로드, 로그인, 결제처럼 데이터가 정확해야 하는 일에는 TCP가 잘 맞는다. HTML 문서의 한 부분이 빠지거나, 파일 조각이 뒤섞이면 결과가 깨질 수 있기 때문이다.

UDP: 빨리 보내는 쪽지 방식

UDP는 User Datagram Protocol의 줄임말이다. 쉽게 말하면 "확인 절차를 줄이고 빨리 보내는 방식"이다.

UDP는 TCP처럼 먼저 연결을 확인하지 않는다. 보내는 쪽은 데이터를 작은 묶음으로 만들어 바로 보낸다. 이 묶음을 데이터그램이라고 부른다. 데이터그램은 하나의 독립된 쪽지처럼 취급된다.

UDP는 기본적으로 이런 것을 보장하지 않는다.

• 상대가 받을 준비가 되었는지

• 데이터가 반드시 도착했는지

• 여러 조각이 보낸 순서대로 도착했는지

• 빠진 조각을 자동으로 다시 보낼지

이렇게 보면 UDP가 부족해 보일 수 있다. 하지만 장점이 있다. 절차가 단순해서 빠르다.

영상 통화를 생각해 보자. 상대의 얼굴 영상은 매 순간 새로 바뀐다. 1초 전 화면 조각이 늦게 도착해도 이제는 쓸모가 없다. 늦은 조각을 굳이 다시 받아서 과거 화면을 보여 주는 것보다, 조금 깨지더라도 최신 화면을 계속 보여 주는 편이 낫다.

실시간 게임도 비슷하다. 캐릭터의 위치는 계속 바뀐다. 아주 오래된 위치 정보가 늦게 도착하면 오히려 방해가 된다. 그래서 많은 실시간 게임은 UDP를 사용하고, 꼭 필요한 정보만 프로그램 안에서 따로 확인한다.

UDP는 아무렇게나 보내는 방식이 아니다. 포트 번호도 있고, 오류를 확인하기 위한 기본 장치도 있다. 다만 TCP처럼 순서 맞추기와 재전송을 운영체제가 자동으로 자세히 해 주지는 않는다. 필요한 경우에는 프로그램이 직접 규칙을 덧붙인다.

웹, 게임, 영상 통화, DNS는 왜 다른 방식을 고를까

TCP와 UDP 중 어느 것이 더 좋다고 말할 수는 없다. 목적이 다르다. 중요한 것은 "정확성이 더 중요한가, 빠른 반응이 더 중요한가"이다.

DNS는 보통 UDP 53번을 사용한다. 이름 하나를 묻고 IP 주소를 받는 일은 짧고 빠르게 끝나는 경우가 많기 때문이다. 다만 응답이 크거나 특별한 DNS 작업이 필요할 때는 TCP 53번을 쓰기도 한다.

웹은 오랫동안 TCP 위에서 움직였다. HTTP와 HTTPS는 보통 TCP 80번, TCP 443번을 사용한다. 요즘에는 더 빠른 연결을 위해 UDP 위에 별도의 확인 규칙을 얹은 방식도 쓰인다. 하지만 처음 인터넷을 조립하는 단계에서는 "웹은 정확한 전달이 중요하므로 TCP를 주로 쓴다"고 이해하면 충분하다.

패킷 안에서는 어떤 일이 일어날까

클라이언트가 웹 서버에 요청을 보낼 때를 다시 보자.

브라우저는 "웹 페이지를 주세요"라는 데이터를 만든다. 운영체제는 이 데이터를 TCP 조각으로 나눈다. 각 조각에는 출발지 포트와 목적지 포트가 붙는다. 그 아래에는 출발지 IP와 목적지 IP가 붙는다. 더 아래로 내려가면 가까운 네트워크에서 사용할 MAC 주소가 붙어 프레임이 된다.

즉, 한 번의 웹 요청 안에는 여러 층의 주소가 함께 들어간다.

• MAC 주소: 가까운 구간에서 다음 장치를 찾는다.

• IP 주소: 먼 목적지 네트워크와 컴퓨터를 찾는다.

• 포트 번호: 도착한 컴퓨터 안의 프로그램을 찾는다.

• TCP 또는 UDP: 데이터를 어떤 방식으로 배달할지 정한다.

비유하면 이렇다.

• IP 주소는 도시와 건물 주소다.

• 포트 번호는 건물 안의 창구 번호다.

• TCP는 확인 서명을 받는 택배다.

• UDP는 빠르게 던져 넣는 쪽지에 가깝다.

비유가 끝나는 지점도 분명히 하자. 실제 인터넷에서는 사람이 직접 서명하지 않는다. 운영체제와 프로그램이 정해진 숫자와 규칙으로 확인하고, 다시 보내고, 조각을 맞춘다.

고장 나면 어디를 볼까

포트, TCP, UDP를 배우면 "IP는 맞는데 왜 접속이 안 되지?"라는 문제를 더 잘 볼 수 있다.

먼저 목적지 IP까지 길이 있는지 확인해야 한다. 라우터와 게이트웨이가 잘못되어 있으면 포트까지 갈 기회도 없다. DNS 이름을 썼다면 이름이 올바른 IP로 바뀌는지도 확인한다.

그다음은 포트다. 서버에 웹 서버 프로그램이 실행 중이어도, 내가 접속한 포트에서 기다리고 있지 않으면 연결되지 않는다. 예를 들어 웹 서버가 TCP 8080번에서 기다리는데 브라우저가 TCP 80번으로 접속하면 실패할 수 있다.

또 하나는 TCP와 UDP를 혼동하는 경우다. 어떤 프로그램이 UDP 53번에서 기다리는데 TCP 53번으로만 확인하면 다르게 보일 수 있다. 포트 번호뿐 아니라 프로토콜도 함께 봐야 한다.

보안 설정도 자주 막힌다. 방화벽은 특정 포트나 특정 방식의 통신을 막을 수 있다. 서버 프로그램은 켜져 있고 IP 주소도 맞는데 외부에서만 접속이 안 된다면, 중간 라우터나 서버의 방화벽이 해당 포트를 막고 있는지 확인해야 한다.

TCP 연결이 자주 끊기거나 느리다면 중간에서 조각이 사라져 재전송이 많이 일어나는 상황일 수 있다. 반대로 UDP 기반의 영상 통화가 가끔 깨지는 것은 일부 조각이 사라졌지만 다시 기다리지 않고 다음 화면으로 넘어가기 때문에 생기는 현상일 수 있다.

정리하면 이렇다. IP는 목적지까지 가는 길을 찾는다. 포트는 도착한 컴퓨터 안에서 받을 프로그램을 찾는다. TCP는 빠진 조각을 챙겨 정확히 맞춘다. UDP는 확인 절차를 줄여 빠르게 보낸다.

이제 우리는 이름을 주소로 바꾸고, 주소를 따라 길을 찾고, 도착한 데이터가 어느 프로그램으로 들어가는지도 알게 되었다. 다음에는 이 위에서 웹이 실제로 어떻게 요청과 응답을 주고받는지 살펴볼 수 있다.