UDP Protocol ( defined by RFC 768 )
“no frills”, “bare bones” internet transport protocol
“no frills”
: 아무 장식이 없음을 의미한다.“bare bones”
: 직역하면 벌거벗은 뼈라는 뜻에서, 그야말로 기본적인 뼈대만이 있다는 것을 의미한다.
UDP Protocol - 특징
- multiplexing / demultiplexing + 간단한 error check
- lost, out-of-order 인 채로 전달 → 순서 보장도 안된다는 뜻
- connectionless (no handshaking)
UDP Protocol - 사용성
loss tolerant, rate sensitive, streaming multimedia app
- no connection state (망의 상태 등)
- no congestion control
- 적은 header overhead
- error control, 재조립 등을 수행하게 되면 시간이 더 걸릴 것 → 이는 time sensitive한 app들의 경우 원치 않은 결과일 수도 있다.
- TSN(time sensitive network), real-time transmission
- 즉, UDP는 가벼워서 시간에 영향을 덜 미침
DNS application
- DNS application이 DNS query를 만들기를 원함
- DNS query message를 만들어서 UDP로 message를 내려보낸다.
- UDP protocol을 사용하므로, 아무런 end system과의 handshaking 없이 encapsulation 후에 network layer로 해당 segment를 내려보낸다.
- network layer에선 encapsulation을 통해 datagram을 구성한 후 name server로 보낸다.
- 만약 reply를 받지 못한다면?
➡ 다시 query를 보내거나
➡ 다른 name server로 query를 보내거나
➡ 혹은 application에게 reply를 받을 수 없다고 알리는 방식으로 동작하게 된다.
SNMP(simple network management protocol) application
SNMP
: 간단한 네트워크 관리 프로토콜이다. 복잡해지는 네트워크 망을ping
이라는 ICMP 프로토콜을 사용하는 프로그램으로 관리하기에 힘들어져서 나온 것이 SNMP 프로토콜이다.- 이 SNMP를 사용하는 application들은 UDP protocol을 사용해서 속도를 높이고 있다.
응용 레벨에서 더 치밀한 control이 필요할 경우 이를 사용
- 이 app이 더 안전하게, 더 빠르게 하기 위한 control을 자신의 application에 맞춰 넣으려고 한다.
- 이 때 하얀 도화지에 새로 그려넣는 것이 더 specific할 것 → 즉, TCP는 custom하기 어렵다는 뜻
UDP를 reliable transfer로 ?
- reliability를 만족하게 하는 기능을 application layer에 추가해야 함
- 즉, application에 specific한 error recovery를 가지는 방식으로 UDP를 통해 reliable transfer를 수행할 수 있음
- 구글 크롬 :
QUIC
프로토콜을 쓴다.
QUIC : Quick UDP Internet Connection
- UDP를 사용하면서 chrome 자체의 reliability를 제공하고 있음
- 왜 TCP를 안쓰고 이렇게 UDP 위에 application layer에서 reliability 매커니즘을 구현하고 있는 걸까?
- TCP congestion-control 매커니즘에 의해 발생되는 transmission-rate constraints(전송 속도 제약)을 받지 않고 reliable하게 통신할 수 있으므로.
by chatGPT - what is quic protocolQUIC
1. UDP 기반: QUIC는 UDP 프로토콜 위에서 구현되어 있습니다. 이를 통해 TCP보다 낮은 지연 시간을 제공하며, 빠른 연결 설정을 가능하게 합니다.
2. 내장된 보안 기능: QUIC에는 TLS(Transport Layer Security)와 유사한 암호화 및 보안 기능이 내장되어 있습니다. 이를 통해 별도의 TLS/SSL 핸드셰이크 과정이 필요 없으므로 지연 시간이 줄어듭니다.
3. 스트림 다중화: QUIC는 여러 개의 독립적인 스트림을 하나의 연결에서 동시에 처리할 수 있습니다. 이를 통해 TCP의 "head-of-line blocking" 문제를 해결하며, 효율적인 네트워크 리소스 사용이 가능합니다.
4. 손실 복구 및 혼잡 제어: QUIC는 자체적인 혼잡 제어 알고리즘을 가지고 있으며, 패킷 손실 시 더 빠르고 효과적인 복구가 가능합니다.
5. 연결 마이그레이션: QUIC는 클라이언트의 IP 주소가 변경되더라도 연결을 유지할 수 있는 기능을 제공합니다. 이를 통해 무선 네트워크 간의 전환 시 연결이 끊기지 않습니다.QUIC는 이러한 특징을 통해 기존의 TCP 및 TLS/SSL 프로토콜의 단점을 극복하고 웹 트래픽 성능을 개선하려는 목표를 가지고 있습니다. 이러한 이유로, 많은 인터넷 서비스 및 웹 브라우저에서 QUIC를 지원하고 도입하고 있습니다.
QUIC(Quick UDP Internet Connections)는 구글이 개발한 전송 계층 프로토콜입니다. QUIC는 기존의 TCP 및 TLS/SSL을 대체하려는 목적으로 개발되었으며, 주요 목표는 웹 트래픽의 성능 개선과 지연 시간 감소입니다. QUIC는 HTTP/3에서 기본 전송 프로토콜로 사용되며, 현재는 IETF(Internet Engineering Task Force)에 의해 표준화되고 있습니다.
이후 QUIC에 대해서는 Transport Layer 마지막 장에 조금 더 살펴볼 예정이다.
UDP Protocol - Segment Structure
- 32bit의 source & dest port
- length: 전체 UDP segment의 byte 크기(header 포함)
- checksum : error(flipped bits 등)를 detect하기 위함
- payload : application data
UDP Protocol - checksum
sender | receiver |
---|---|
각 field들을 16-bit 정수로 나타낼 수 있다. 이들에 대해 전부 더해준다. 이 때, 1의 보수법으로 더해준다. 이 더해진 결과값을 checksum으로 한다. | 똑같이 checksum을 계산해본다. sender가 보낸 segment에 들어 있는 checksum 값과 동일한지를 check한다. |
UDP Protocol - checksum : Why Error check?
- link layer 프로토콜에서도 error check를 해준다.
- 하지만, src와 dest 사이의 모든 link layer의 장치들에서, 하나도 빠짐없이 error check를 해준다고는 보장할 수 없다.
- 따라서 개런티 차원에서 transport layer에서 error checking을 제공해주어야 한다.
- transport layer의 end to end principle 때문에 UDP에서 error checking 정도는 제공한다.
- 단, error recovery는 제공하지 않음 - re-transmission 등
UDP Protocol - checksum : 방법
1의 보수 덧셈
- 16-bit field들에 대해서 덧셈을 수행한다. 각 field들의 덧셈마다 carry bit가 발생할 수 있다.
- carry bit을 sum의 결과의 맨 LSB에 더해준다. (wraparound)
- sum에 대해 반전을 수행한다.
이렇게 checksum을 계산할 수 있다.
receiver 쪽에서 확인하는 방법
- sender쪽에서와 마찬가지로 위 2번까지 수행한다.
- 결과를 반전하는 대신, sender쪽에서 계산한 checksum과 OR bit-wise 연산을 수행한다.
- 만약 모든 bit가 1이라면 Error가 없다는 뜻이다.
이것이 UDP에서 수행하는 error check 방식이다.
요약
- UDP 프로토콜이 가지는 특징과 사용성에 대해서 알아봤다.
- UDP의 segment 구조를 파악했고, 그 중 checksum field를 다루는 방식도 알아봤다.
더 알아보기
출처
Computer Networking: a Top Down Approach 中 3.3