TCP와 UDP, 전송 방식과 애플리케이션의 책임 이해하기
페이지 정보
본문
TCP는 정확하고 UDP는 빠르다는 문장만 외우면 실제 애플리케이션을 설명할 때 막히기 쉽습니다. 전송 계층이 어떤 단위를 제공하는지와 서비스가 어떤 완료 조건을 요구하는지를 함께 봐야 하기 때문입니다.
파일을 받는 일, 위치 정보를 갱신하는 일, 요청 처리 완료를 확인하는 일은 서로 다른 질문을 포함합니다. 이 글은 TCP의 바이트 스트림과 UDP의 데이터그램을 중심으로 기본 보장과 애플리케이션의 책임을 정리합니다.
두 프로토콜의 성능을 일률적으로 순위 매기기보다 유실과 지연, 메시지 경계, 처리 확인을 어디서 다루는지 이해하는 데 초점을 둡니다.
AI 생성 삽화 · 개념 이해를 위한 AI 연출 이미지이며 실제 시스템 구성도나 측정 결과가 아닙니다.
핵심 정리
TCP는 신뢰성 있는 순서 보장 바이트 스트림을 제공합니다. UDP는 데이터그램을 제공하며 전달 보장이나 재전송을 자체적으로 해결하지 않습니다. 어느 쪽이든 서비스 작업의 완료 조건은 별도로 설계해야 합니다.
1. TCP의 순서는 바이트 스트림의 순서입니다
RFC 9293은 TCP를 애플리케이션에 신뢰성 있고 순서가 보장되는 바이트 스트림 서비스를 제공하는 프로토콜로 설명합니다. 데이터를 보낸 호출 횟수와 받는 호출 횟수가 항상 같다는 뜻은 아닙니다.
설명용으로 송신 측에서 짧은 문장 두 개를 따로 보냈다고 가정해도 수신 측이 언제나 두 번의 읽기로 각각 한 문장을 얻는다고 기대하면 안 됩니다. 애플리케이션은 길이 정보나 구분자 등 자신의 메시지 형식을 정해 스트림에서 경계를 찾아야 합니다.
실제 선택은 사용하는 상위 프로토콜의 규칙에 따릅니다. 처음 네트워크 코드를 읽을 때는 패킷 하나, 읽기 호출 하나, 업무 메시지 하나를 같은 단위로 보지 않는 것이 도움이 됩니다.
TCP가 제공하는 순서와 프로그램이 해석하는 요청 경계를 나누어 설명할 수 있어야 합니다. 이 구분이 없으면 일부만 읽은 내용을 완성된 메시지로 처리하는 실수를 이해하기 어렵습니다.
2. UDP는 개별 데이터그램을 전달합니다
UDP는 데이터그램 단위로 데이터를 전달하는 전송 프로토콜입니다. RFC 768은 전달과 중복 방지가 보장되지 않는다는 점을 명시합니다.
애플리케이션은 데이터그램이 유실되거나 예상한 순서와 다르게 도착하는 상황을 고려해야 합니다. 그렇다고 매번 유실된다는 뜻은 아니며 어떤 환경에서 무엇을 관찰했는지와 프로토콜의 보장을 구분해야 합니다.
설명용 위치 갱신 메시지에 번호와 시각을 넣는다면 수신자는 새 정보인지 오래된 정보인지 판단할 자료를 가질 수 있습니다. 이 예시는 실제 서비스의 완성된 프로토콜 설계가 아니라 요구에 따라 상위 계층이 추가 정보를 다룰 수 있다는 설명입니다.
데이터그램 하나가 반드시 하나의 IP 패킷과 같은 것이라고 단정하지도 않습니다. 크기와 경로 조건에 관한 고려가 별도로 필요합니다.
메시지 경계가 있다는 장점만 보고 모든 통신 요구가 해결됐다고 보지는 않는 것이 좋습니다.
3. 전달 확인과 업무 완료를 나눕니다
전송 계층에서 데이터를 주고받는 일과 상대 애플리케이션이 요청한 업무를 끝내는 일은 다릅니다. 예를 들어 문서 저장 요청의 바이트가 상대에게 도달했다고 해도 서비스가 파일을 검증하고 저장 결과를 확정했다는 의미로 곧바로 읽을 수는 없습니다.
업무 완료를 판단하려면 그 서비스의 응답 규칙과 오류 처리를 확인해야 합니다. 이 예시는 TCP의 기본 전송 보장과 응용 계층의 작업 의미를 구분하기 위한 설명입니다.
클라이언트가 연결 종료만 보고 저장 성공으로 표시한다면 어떤 조건에서 성공으로 간주하는지 검토해야 합니다. 반대로 응답이 늦다는 이유로 같은 요청을 무작정 반복하면 서비스에 따라 중복 처리를 고려해야 할 수도 있습니다.
여기서 중요한 것은 특정 전송 방식을 선택하면 모든 업무 보장이 자동으로 생긴다고 생각하지 않는 것입니다. 요구사항에는 바이트 수신, 요청 해석, 업무 처리, 결과 확인을 별도 단계로 적어 볼 수 있습니다.
4. UDP 위의 설계도 혼잡과 신뢰성을 고려합니다
UDP 자체에는 TCP와 같은 혼잡 제어 기능이 내장돼 있지 않습니다. RFC 8085는 인터넷에서 UDP를 사용하는 애플리케이션도 적절한 혼잡 대응을 설계해야 한다고 안내합니다.
보내는 쪽에서 빠르게 전송할 수 있다는 사실이 경로 전체가 그 속도를 감당한다는 뜻은 아닙니다. 필요 이상으로 보내는 방식은 유용한 처리량과 지연에 오히려 불리할 수 있습니다.
또한 UDP를 사용한다는 이유로 상위 계층에 신뢰성 기능을 추가할 수 없는 것은 아닙니다. QUIC은 UDP 기반으로 신뢰성 있는 전송 등을 구성하는 별도의 프로토콜 사례입니다.
따라서 UDP 기반 서비스라는 설명을 듣고 재전송도 연결 개념도 전혀 없다고 확대해서 말하지 않습니다. 어느 계층의 프로토콜을 설명하는지 구분해야 합니다.
실제 서비스를 비교할 때는 UDP라는 이름만 보는 대신 그 위에서 사용하는 프로토콜이 제공하는 기능을 읽는 편이 정확합니다.
5. 선택 기준을 지연과 유실 허용 조건으로 적습니다
프로토콜을 고르기 전에 어떤 데이터가 늦어져도 필요한지, 오래된 데이터는 버릴 수 있는지, 순서가 업무 의미에 영향을 주는지 질문해 볼 수 있습니다. 설명용 예로 파일의 모든 바이트를 받아야 하는 작업과 매번 최신 위치만 화면에 반영하려는 작업은 완료 조건이 다릅니다.
다만 이 차이만으로 특정 프로토콜을 곧바로 확정하는 것은 성급합니다. 이미 사용하는 상위 프로토콜과 인프라, 구현 복잡도, 보안 요구까지 함께 확인해야 합니다.
학습 단계에서는 요구를 표로 정리하고 각 기능을 어떤 계층에서 처리할지 표시하는 연습이 도움이 됩니다. 지연에 민감하다는 말도 평균 지연인지 드문 큰 지연인지 구체화할 수 있습니다.
데이터 일부가 없어도 된다는 말에는 어느 정도와 어떤 상황인지 조건이 필요합니다. 기술 이름을 먼저 선택한 뒤 요구를 맞추기보다 서비스를 설명하는 문장부터 분명히 하는 편이 좋습니다.
6. 성능 비교는 측정 조건과 완료 기준을 남깁니다
TCP와 UDP의 속도를 비교했다는 결과를 읽을 때는 전송량과 메시지 크기, 경로 상태, 연결 준비 포함 여부를 살펴봅니다. 송신 프로그램이 데이터를 넘긴 시점만 측정한 결과와 상대가 필요한 데이터를 처리한 시점을 측정한 결과는 같은 의미가 아닙니다.
유실된 데이터가 있는지도 확인하지 않고 높은 송신 속도만 비교하면 서비스 관점의 성능을 놓칠 수 있습니다. 설명용 실험 기록에는 보낸 양, 받은 양, 걸린 시간, 실패 조건을 분리해 적을 수 있습니다.
특정 환경의 숫자를 모든 네트워크에 적용되는 우열로 확대하지 않습니다. 공식 규격은 기본 동작을 이해하는 근거이고 실제 성능은 구체적인 구현과 환경에서 확인할 대상입니다.
면접이나 학습 정리에서도 TCP는 느리다, UDP는 빠르다로 끝내기보다 제공하는 단위와 보장, 상위 계층의 책임을 설명하면 더 정확합니다. 그 뒤에 요구에 맞는 선택과 측정 방법을 논의할 수 있습니다.
7. 자주 묻는 질문
Q1. TCP로 두 번 보내면 두 번에 나누어 받나요?
TCP는 바이트 스트림을 제공하므로 호출 경계를 그대로 보장하지 않습니다. 메시지 경계는 상위 프로토콜의 형식에 맞춰 해석해야 합니다.
Q2. UDP는 항상 데이터가 유실되나요?
유실이 반드시 일어난다는 뜻이 아니라 전달을 자체적으로 보장하지 않는다는 뜻입니다. 애플리케이션은 필요한 실패 처리와 순서 판단을 설계합니다.
Q3. TCP를 쓰면 서버 업무 성공도 보장되나요?
바이트 전달과 업무 처리 완료는 다른 단계입니다. 서비스의 응답 규칙과 오류 조건을 별도로 확인해야 합니다.
Q4. UDP 기반이면 신뢰성 기능을 만들 수 없나요?
상위 프로토콜이 필요한 기능을 추가할 수 있습니다. QUIC처럼 UDP 기반으로 별도 전송 기능을 구성하는 사례가 있습니다.
참고 자료
- 이전글층화 분할과 무작위 분할, 클래스 비율과 평가 조건 구분하기 26.09.29
- 다음글기울기 누적과 배치 크기, 여러 번의 계산을 한 번의 갱신으로 묶기 26.09.29
댓글목록
등록된 댓글이 없습니다.