TCP는 안전하고 UDP는 빠르다? 전송 방식부터 구분하기

Об этом предложении

네트워크를 공부하면 “TCP는 안전하고 UDP는 빠르다”는 말을 자주 만납니다. 그런데 안전이 암호화를 뜻하는지, 전송 순서를 뜻하는지부터 모호합니다. 이번에는 프로그램이 받는 데이터의 형태와 전송 계층이 제공하는 성질 을 나눠보겠습니다. 바이트 흐름과 데이터그램 TCP는 애플리케이션에 신뢰성 있는 순서 있는 바이트 스트림을 제공합니다. UDP는 데이터그램 방식이며 전달, 중복 방지, 순서 보장을 기본으로 제공하지 않습니다. TCP RFC 9293 §2.2 , UDP RFC 768 그림의 “메시지 경계”는 프로그램이 정한 구분입니다. IP 패킷 크기나 실제 캡처 결과를 나타내지 않습니다. 확인할 것 TCP UDP 애플리케이션이 보는 기본 형태 바이트 스트림 데이터그램 보낸 메시지 단위의 유지 별도 프레이밍 필요 데이터그램 단위 누락·중복·순서 처리 TCP의 신뢰성 메커니즘 필요한 기능을 상위 계층에서 설계 두 번 보냈으면 두 번 받을까? TCP에 HELLO 와 WORLD 를 각각 보냈다고 가정하겠습니다. 수신 프로그램은 HELLOWORLD 를 한 번에 읽거나, 여러 조각으로 읽을 수 있습니다. 한 번의 send 와 한 번의 read 가 같은 업무 메시지라는 가정을 버려야 합니다. 줄바꿈을 메시지 구분자로 정한 단순 모형은 다음처럼 나눌 수 있습니다. const chunks = ["HEL", "LO\nWOR", "LD\n"]; const messages = chunks.join("").split("\n"); messages.pop(); console.log(messages.join(" / ")); 출력은 HELLO / WORLD 입니다. 합성 조각으로 경계 복원을 검증한 코드이며 실제 소켓 테스트는 아닙니다. 지속 연결에서는 남은 조각을 보관하고, 최대 길이와 문자 인코딩, 종료 상황도 처리해야 합니다. 신뢰성은 암호화와 다르다 TCP를 사용했다는 사실만으로 내용이 암호화되거나 상대를 인증하는 것은 아닙니다. TLS 같은 별도 계층을 확인해야 합니다. 또 UDP 위에 신뢰성 기능을 만들 수도 있으므로, UDP를 쓴다는 사실만으로 서비스 전체에 재전송이 없다고 단정할 수 없습니다. “항상 빠르다”는 결론도 실제 메시지 크기, 손실, 구현과 요구 조건 없이 내릴 수 없습니다. 확인 문제 TCP에서 읽은 한 조각이 항상 한 메시지일까요? TCP를 선택하면 자동으로 암호화될까요? UDP를 쓰는 서비스가 재전송을 구현할 수 있을까요? 답과 해설 아닙니다. 길이 헤더나 구분자 등 업무 메시지를 나누는 규칙이 필요합니다. 아닙니다. 전송 신뢰성과 암호화·인증은 다른 기능입니다. 가능합니다. 상위 프로토콜이나 애플리케이션이 기능을 추가할 수 있습니다. 오늘은 임의의 위치에서 문자열을 잘라 다시 합쳐보겠습니다. 내일은 구분자를 포함한 본문을 어떻게 처리할지 생각하고, 일주일 뒤에는 길이 헤더 방식과 비교해보면 좋겠습니다. 다음은 주소를 찾는 DNS입니다. 자료 확인 기준: RFC 9293의 핵심 TCP 성질, RFC 768의 기본 UDP 정의, 2026-10-04. 최신 확장 전체를 다루는 글은 아닙니다. 예제 검증 환경: Node.js v24.13.1.

Детали предложения

Провайдер

velog

Источник

velog-rss

Балл

54.39

Уверенность

49%