우리가 보는 실시간 축구 중계는, 사실 가끔 몇 조각쯤 놓쳐도 그냥 계속 흘러가요.IP 주소와 라우팅 - 패킷은 어떻게 길을 찾을까?에서 우리는 패킷이 IP 주소를 따라 길을 찾아간다는 걸 봤어요. 근데 거기서 또 이런 궁금증이 생겼죠.
“그럼 도착했다는 건 어떻게 알아? 중간에 패킷이 사라지면?”좋은 질문이에요. 인터넷은 이 문제를 해결하려고 성격이 다른 두 방식을 써요. 하나는 연결과 순서, 재전송 같은 신뢰성 기능을 기본으로 제공하고, 다른 하나는 이런 기능을 최소화한 단순한 데이터그램 방식이에요. 바로 TCP 와 UDP 예요. 이름만 들으면 벌써 머리 아플 것 같죠? 근데요, 사실 일상 비유로 보면 그렇게 어렵지 않아요.
중요한 서류를 보낼 때 방식이 갈려요
여러분이 친구한테 중요한 서류를 보낸다고 상상해볼까요? 보내는 방법은 두 가지예요.- 등기 우편으로 보내기
- 확인 없이 그냥 전단지처럼 뿌리기
- 보냈다는 기록이 남아요
- 상대가 받았는지 확인해요
- 중간에 빠지면 다시 보내요
- 순서가 중요하면 순서도 맞춰요
- 일단 빨리 뿌려요
- 누가 몇 장을 못 받았는지는 신경 안 써요
- 대신 절차가 거의 없어서 훨씬 가벼워요
TCP와 UDP는 뭐가 다를까요?
둘 다 데이터를 보내는 방식이긴 해요. 근데 성격이 완전히 달라요.
이 차이를 한 문장으로 줄이면 이거예요.
TCP는 먼저 인사부터 해요
TCP는 그냥 던지고 시작하지 않아요. 먼저 상대가 준비됐는지 확인해요. 다만 여기서는 “TCP는 먼저 확인하고 시작하는 성격이구나” 정도만 잡고 갈게요.SYN, ACK, sequence 번호처럼 그 인사 안에서 실제로 무슨 숫자와 신호가 오가는지는 뒤의 TCP 3-way handshake 글에서 본격적으로 열어볼 거예요.
이런 식으로 보냈다 → 받았다 를 계속 확인하면서 가요. 그래서 믿음직하죠.
UDP는 확인보다 속도를 택해요
UDP는 달라요. “잘 받았어?” 를 일일이 묻지 않아요. 그냥 이렇게 가요.- 데이터 보냄
- 또 보냄
- 또 보냄
- 계속 보냄
아예 끊기는 게 더 답답하잖아요.그래서 이런 경우엔 조금 놓치더라도 계속 앞으로 가는 방식이 더 잘 맞아요. 그게 UDP예요.
근데 왜 굳이 두 가지나 있어요?
하나로 통일하면 편할 것 같죠? 사실은 아니에요. 인터넷에서는 상황마다 중요한 게 다르거든요.1. 어떤 데이터는 신뢰성 있는 전달이 필요해요
여러분이 인터넷 뱅킹에서 송금 버튼을 눌렀다고 해볼게요. 이때 데이터가 하나라도 빠지면 어떨까요? 요청 데이터가 빠지거나 순서가 뒤섞인 채 애플리케이션에 전달되면 곤란하겠죠. TCP는 이런 요청 데이터가 빠지거나 순서가 뒤섞인 채 애플리케이션에 전달되지 않도록 신뢰성 있는 바이트 스트림을 제공해요. 다만 송금 요청이 두 번 처리되지 않게 하는 건 TCP가 아니라 애플리케이션과 데이터베이스가 책임지는 별개의 문제예요.2. 어떤 데이터는 지금 이 순간이 더 중요해요
반대로 영상 통화나 온라인 게임은 어때요? 여기서는 지나간 조각을 뒤늦게 복구하느라 멈추는 것보다, 조금 거칠어도 지금 바로 도착하는 것이 더 중요할 때가 많아요. 목소리가 아주 잠깐 끊기는 건 참을 수 있어도, 3초 뒤에 밀려서 들리면 대화가 안 되잖아요.3. 확인 절차도 공짜는 아니에요
TCP가 꼼꼼한 건 좋은데, 그 꼼꼼함에는 비용이 들어요.- 연결 시작할 때 인사해야 하고
- 받았는지 계속 확인해야 하고
- 빠지면 다시 보내야 하고
- 순서가 꼬이면 다시 정렬해야 해요
그럼 진짜 TCP와 UDP는 어떻게 생겼을까요?
실제로는 둘 다 패킷 앞부분에 자기만의 정보표를 붙여요. 근데 TCP 쪽이 훨씬 더 꼼꼼해서 정보가 많아요. 이걸 보면 왜 TCP가 꼼꼼한지 감이 와요. 순서 번호, 확인 번호, 연결 신호 같은 게 다 들어 있거든요.
만약 “저 SYN / ACK, 순서 번호, 확인 번호가 진짜 TCP 헤더 몇 번째 칸에 들어가는데요?” 가 궁금해졌다면, 심화편 TCP 헤더는 왜 이렇게 칸이 많을까요? 에서 32비트 격자 위로 실제 위치를 바로 펼쳐볼 수 있어요.
반대로 UDP는 “어디서 왔고, 어디로 가고, 길이가 얼마인지” 처럼 전송에 꼭 필요한 정보만 간단하게 담고 지나가요.
더 깊게 보고 싶다면 UDP 헤더는 왜 딱 8바이트일까요?에서Length와Checksum의 실제 위치를 확인할 수 있어요. UDP 위에서 신뢰성과 보안을 다시 설계한 이유가 궁금할 때는 QUIC은 왜 UDP 위에서 돌아갈까요?로 이어가면 돼요.
UDP가 “대충 보내는 방식”이라는 뜻은 아니에요. 일부러 확인 절차를 줄인 방식에 더 가까워요. 그래서 실시간 서비스에서는 오히려 아주 똑똑한 선택일 때가 많아요.
자, 정리해볼까요?
- TCP 는 순서, ACK, 재전송을 기본으로 제공하는 신뢰성 있는 바이트 스트림 방식이에요.
- UDP 는 자체 확인 절차를 줄이고 데이터그램을 그대로 다루는 가벼운 방식이에요.
- 로그인, 결제, 파일 전송처럼 전송 순서와 재전송을 프로토콜이 챙겨야 하면 TCP 가 잘 맞아요.
- 게임, 음성 통화, 생중계처럼 실시간성이 중요하면 UDP 가 잘 맞아요.
- 둘 중 뭐가 더 좋다기보다, 상황에 맞는 도구가 다를 뿐이에요.
다음 글 예고
근데 여기서 또 이런 생각이 들지 않으세요?
“우리는 google.com만 쳤는데, 그걸 어떻게 IP 주소로 바꿔서 찾아가죠?”
다음 글에서는 “DNS” 이야기를 해볼게요. 사람은 이름을 기억하고, 컴퓨터는 숫자를 좋아하잖아요. 그 둘 사이를 누가 통역해주는지 같이 살펴봐요.