데이터그램 서비스는 IP 위에 포트·길이·체크섬을 붙여 데이터그램을 제공한다. 애플리케이션이 보낸 메시지의 경계가 유지된다는 점에서 의 연속 바이트 스트림과 다르다.
- 그러나 전달·순서·중복 방지·재전송을 가 보장하는 것은 아니다.
- “비연결성”은 연결 준비가 없다는 전송 규칙을 말하며 응용 프로그램이 상대나 세션 정보를 전혀 저장할 수 없다는 뜻은 아니다.
응용의 선택의 handshake나 송신 큐 관리가 없는 것은 특징이지만 모든 서비스가 보다 빠르다고 결론 내릴 수는 없다. 응용의 복구·혼잡 대응 방식, 패킷 크기, 경로 손실과 서버 처리 시간이 결과에 영향을 준다.
- 위의 QUIC는 별도의 연결·신뢰성·암호화 체계를 제공하므로 의 기본 기능과 상위 프로토콜의 기능을 구분해야 한다.

비교 기준
응용에 제공하는 단위	순서 있는 바이트 스트림	경계가 있는 데이터그램
전송 계층의 복구	재전송·순서 복구 제공	자체 재전송·순서 복구 없음
연결 수립	연결 상태를 합의	같은 연결 수립 절차 없음
기밀성	자체로 암호화하지 않음	자체로 암호화하지 않음

02포트와 5-tuple로 통신을 구분한다

포트 범위 출발지·목적지 포트는 각각 16비트이다. IP 주소와 전송 프로토콜, 두 포트로 트래픽을 구분한다.
- 53과 53은 별도 프로토콜 공간이며 는 둘 다 사용할 수 있다.
- 클라이언트는 보통 임시 포트를 선택하고 서버가 응답할 때 요청의 source/destination 역할이 뒤집힌다.
통신 식별예를 들어 192.0.2.10:53000→198.51.100.53:53/ 질의의 응답은 보통 198.51.100.53:53→192.0.2.10:53000이다. 목적지 포트가 53이라는 사실만으로 실제 내용이나 서버의 정당성이 보장되지는 않는다.
- 서버 소켓이 127.0.0.1에만 바인딩되어 있으면 다른 인터페이스로 도착한 패킷을 해당 소켓에서 받지 못하는 등 주소 바인딩도 중요하다.

038바이트 헤더와 Length 계산

8바이트 헤더 헤더는 ··Length·Checksum 각 2바이트로 8바이트이다. Length에는 헤더와 응용 데이터가 포함되고 IP· 헤더는 포함되지 않는다.
- 응용 데이터가 20바이트이면 Length=28, 옵션 없는 Total Length=48이다.
- 헤더에는 의 Sequence·ACK·Window·SYN/FIN 필드가 없다.
Length·IP 길이일반적인 최소 헤더를 사용하면 IP 최대 길이 65535에서 IP 20과 8을 뺀 65507바이트가 이론적인 데이터 상한이 된다. 이것이 경로에서 조각화 없이 보낼 수 있는 크기라는 뜻은 아니다.
- jumbogram과 같은 특수 확장은 기본 길이 예와 별도로 취급한다.

설명과 함께 보는 보조 도식

구조 살펴보기

UDP 헤더와 길이

응용 데이터 20바이트를 담는 예제.

앞쪽 · IPv4 기본 헤더 20 B를 더하면 이 예의 IP Total Length는 48 B다.

뒤쪽 · 응용 데이터 20 B. IP·Ethernet 헤더는 UDP Length에 포함하지 않는다.

출발지 포트 2 B

응답을 받을 통신 끝점 식별

목적지 포트 2 B

수신 서비스 식별

Length 2 B

UDP 헤더와 데이터의 합

28

Checksum 2 B

UDP와 의사 헤더 등을 대상으로 한 오류 검사

각 필드를 누르면 역할과 예시를 확인할 수 있습니다. 칸의 너비는 실제 바이트 비율과 다릅니다.

프로토콜 필드 모식도. 블록 너비는 실제 크기 비율과 다르다.

04체크섬은 오류 검출이며 재전송이 아니다

체크섬 계산 체크섬은 헤더와 데이터뿐 아니라 주소·프로토콜·길이 정보의 의사 헤더도 계산에 넣는다. 잘못된 목적지·프로토콜로 전달되는 일부 오류를 검출하는 데 도움이 된다.
- 홀수 바이트 길이의 마지막은 계산을 위해 0을 덧붙인 것으로 계산하며 그 계산용 패딩을 실제 데이터로 보내는 것은 아니다.
- 계산은 16비트 1의 보수 합을 사용하며 CRC와 다른 알고리즘이다.
· 차이 는 체크섬 필드가 0이면 계산하지 않았음을 표현할 수 있다. 계산 결과가 0인 경우에는 모두 1인 값으로 전송하여 미사용 표기와 구별한다.
- 에서는 원칙적으로 체크섬이 필수이고 제한된 터널 예외를 일반 서비스에 적용하지 않는다.
- 체크섬 오류가 검출되면 수신에서 버릴 수 있지만 자체가 재전송을 요청하지 않으므로 “오류 검사가 없다”와 “복구를 제공하지 않는다”를 구분한다.

LEARN THROUGH PRACTICE

실습: UDP 8888 메시지와 포트 역할 읽기

Ncat 송수신과 캡처를 연결하여 서버 포트·임시 포트·연결 표시를 구별한다.

실습 구성과 전제

서버와 클라이언트 두 대의 격리 연습망이다. 명령의 서버 주소는 문서용 192.0.2.2로 치환했다.
사진의 서버는 Ncat 7.95다. nc의 다른 구현은 옵션 해석이 다르므로 도움말을 확인한다.

UDP 수신 소켓 준비
- -u는 , -l은 수신 모드다. 8888은 로컬 서버 포트이며 같은 번호의 소켓과 별개다.
- 일반 통신은 의 3-way handshake를 만들지 않는다. 이 실습은 문자 송수신이며 쉘 프로그램을 연결하지 않는다.
text
```
ncat -u -l 8888
```
Ncat 문법으로 정리한 동일 목적의 수신 예시
원본 크기로 보기 ↗
- nc -lvup 8888과 Ncat 버전이 보인다.
- Listening on 0.0.0.0:8888 및 상대 포트 57862가 보인다.
확인 기준
수신 주소와 포트를 확인한다.
문자 전송과 결과 확인
- 클라이언트에서 서버 주소· 8888을 지정하고 문자를 입력한다. 서버에 보이는 문자열은 응용 프로그램 수신의 증거다.
- Connection from은 도구가 상대를 식별한 로그이며 연결 수립이나 전달 보장의 증거가 아니다.
text
```
ncat -u 192.0.2.2 8888
```
서버 주소만 치환한 재구성 예시
원본 크기로 보기 ↗
- 클라이언트 명령에 -u와 목적지 포트 8888이 있다.
- 양쪽에서 입력한 UDP 메시지가 나타난다.
확인 기준
양방향 문자열을 확인한다. 한쪽만 보이면 반환 경로와 방화벽을 나누어 본다.
방향별 포트와 길이 대조
- 서버의 응답은 8888→57862다. 요청은 클라이언트 임시 포트에서 서버 포트로 향한다.
- Length 60은 사용자 데이터만의 크기가 아니다. 와 캡처 길이를 구별한다.
text
```
Wireshark 표시 필터: udp.port == 8888
```
실습 흐름을 재구성한 명령 예시. 장치·인터페이스 이름은 구성에 맞춰 사용한다.
원본 크기로 보기 ↗
- Protocol UDP, Info 8888 → 57862가 보인다.
- Length는 60이며 UDP 헤더 상세는 이 화면에서 펼쳐져 있지 않다.
확인 기준
프로토콜·포트·실제 수신 문자를 대조한다. 한 패킷으로 이후 전체 전달을 보장하지 않는다.

실습에서 확인한 동작 원리

에도 소켓과 포트는 있지만 상태·재전송 보장은 없다.
도구 로그 문구보다 실제 프로토콜과 패킷 필드로 판별한다.

설정·출력 추가로 확인하기 3장

아래 화면을 펼쳐 위 실습의 설정값, 명령과 확인 기준을 비교해 보세요. 각 묶음은 별도 실습 기록입니다.

실습 화면 묶음 01 1장

L4 · 실습·개념 참고 화면 2 — 문서 문맥에 삽입된 원본 실습·개념 참고 화면이다. UDP와 포트, 전송 방식의 선택 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.

실습 화면 묶음 02 2장

TFTP 파일 전송 (2) — 수업 원본 자료 · TFTP 서버 옵션과 파일 전송 결과.

TFTP 파일 전송 · 서버 -c 설정: 잘못된 예 / 정상 예 (1) — 수업 원본 자료 · TFTP 서버 옵션과 파일 전송 결과. 원문에서 「서버 -c 설정: 잘못된 예 / 정상 예」에 배치된 그림 또는 화면이다.

동작·명령 참고 문서

Ncat 공식 UDP 사용 안내 ↗RFC 768: UDP ↗

원리 심화

05UDP 체크섬의 의사 헤더와 홀수 길이 처리

의사 헤더의 목적 체크섬은 출발지·목적지 IP, 0, Protocol=17, 길이를 계산에 포함한다. 이 의사 헤더는 앞에 실제로 별도 전송되는 헤더가 아니라 잘못된 주소 전달을 검출하기 위한 입력이다.
16비트 합산 헤더의 Checksum을 0으로 놓고 데이터까지 16비트 단위의 1의 보수 합을 구한다. 캐리는 다시 하위 16비트에 더하고 최종 합을 반전한다.
홀수 데이터 길이데이터가 홀수 바이트면 계산할 때 마지막 바이트 뒤에 0을 붙여 16비트로 맞춘다. 계산용 0은 에 포함하지 않으며 추가 응용 데이터로 보내지 않는다.
0의 두 의미에서 전송 Checksum=0은 체크섬을 사용하지 않았음을 뜻한다. 계산 결과가 0이 된 정상 체크섬은 0xffff로 전송해 미사용 표시와 구분한다.
주소 변경의 영향포트나 데이터가 그대로여도 가 IP 주소를 바꾸면 의사 헤더 입력이 변한다. 적용되는 체크섬을 새 주소에 맞게 조정하지 않으면 수신측 검증이 실패한다.

예제로 추적

063바이트 데이터 ABC의 체크섬 계산

가상 데이터그램192.0.2.1:10000에서 198.51.100.2:20000으로 ASCII ABC를 보낸다. 데이터는 41 42 43이고 =8+3=11, 즉 0x000b다.
의사 헤더 분할계산 워드는 c000 0201 c633 6402 0011 000b다. 주소는 네트워크 바이트 순서로 분할하고 0011은 0 바이트와 Protocol=17을 합친 값이다.
와 데이터 추가 헤더는 2710 4e20 000b 0000이다. 데이터는 4142 4300으로 합산하며 마지막 00은 홀수 길이를 맞추는 계산용 값이다.
합산과 반전모든 워드를 더하고 캐리를 접으면 0xe5d1이다. 비트 반전한 0x1a2e가 Checksum에 들어가며, 이를 포함해 다시 더하면 0xffff가 된다.
길이 판독이 예의 IP 헤더가 옵션 없는 20바이트이면 IP Total Length는 31바이트다. 계산용 패딩을 포함해 =12나 IP 길이=32로 적으면 잘못된 헤더가 된다.

07UDP 소켓에서 데이터그램이 전달되는 순서

메시지 경계충분한 버퍼로 수신하면 데이터그램 경계가 유지된다. 작은 버퍼에서는 잘림·잔여 데이터 폐기 등 API 규칙이 적용되므로 다음 read가 나머지를 보장하지 않는다.
연결된 connected 소켓은 기본 상대 지정·수신 상대 제한·오류 연결 같은 로컬 API 상태다. 식 handshake가 네트워크에 추가되는 것은 아니다.
큐와 손실수신 프로그램이 늦으면 커널 큐가 가득 차 드롭될 수 있다. 선로 손실과 서버 처리 지연을 구분한다.

응용의 송신 요청응용이 목적지 주소·포트와 한 데이터그램을 소켓에 넘긴다.
·IP 헤더 구성송신 커널이 헤더와 IP 전달 정보를 구성해 출력 경로로 보낸다. 자체는 수신 확인을 기다리는 연결 상태를 만들지 않는다.
수신 소켓 선택수신 커널이 프로토콜·주소·포트 조건에 맞는 소켓을 찾고 데이터그램을 수신 큐에 넣는다.
응용의 수신응용이 큐에서 데이터그램을 읽는다. 버퍼 크기와 API 동작에 따라 전체 메시지를 받을 수 있는지 달라진다.

08응용이 신뢰성을 필요로 할 때

거래 번호·재시도처럼 질의·응답을 사용하는 응용은 거래 식별자와 주소·포트 조건을 이용하여 어떤 요청의 응답인지 판단하고 타임아웃 뒤 다시 질의할 수 있다. 응답 순서가 바뀌거나 같은 응답이 중복 도착할 수 있으므로 위의 응용 규칙이 이를 처리해야 한다.
- 재시도가 곧 원래 데이터그램의 전송 계층 재전송이라는 뜻은 아니다.
중복 수행작업 수행 요청을 재시도할 때는 응답이 유실되었을 뿐 서버가 이미 작업을 했을 가능성이 있다. 따라서 거래 ID나 중복 억제, 멱등 동작을 설계해야 한다.
- 실시간 음성은 늦은 데이터의 복구보다 다음 데이터의 지연을 줄이는 선택을 할 수 있다.
- 어떤 응용은 신뢰성을 더하고 어떤 응용은 지연 제한을 택한다는 점이 선택의 구체적인 이유이다.

09MTU와 단편화가 데이터그램 전체에 미치는 영향

크기 계산 1500에서 옵션 없는 와 를 사용하면 조각화 없는 응용 데이터의 예시 한계는 1472바이트이다. 터널·IP 옵션·확장 헤더가 있으면 더 줄어든다.
- 송신한 데이터그램이 에서 여러 조각으로 나뉘면 목적지가 이를 모두 재조립해야 에 전달할 수 있다.
- 한 조각만 잃어도 원래 데이터그램 전체가 완성되지 않는다.
·재조립 비용 라우터는 통과 패킷을 조각내지 않는다. Packet Too Big 정보와 송신 측의 크기 조절이 중요하다.
- 에는 MSS 협상이 없으므로 MSS clamp가 모든 크기 문제를 해결하지 않는다.
- 응용은 경로와 목적에 맞는 데이터 크기, 피드백·손실 복구와 혼잡 대응을 갖춰야 한다.
- 데이터그램 경계가 보존된다고 임의의 큰 메시지가 효율적으로 전달되는 것은 아니다.

10응답 없음과 ICMP 오류를 구별하기

무응답·포트 오류수신 호스트에서 해당 포트를 처리할 소켓이 없으면 Port Unreachable을 돌려줄 수 있다. 하지만 방화벽의 묵시적 드롭, 오류 응답 제한, 브로드캐스트 조건, 응용이 잘못된 요청을 조용히 무시하는 동작도 있다.
- 따라서 응답이 없다는 관찰만으로 포트가 열렸는지 닫혔는지 단정할 수 없다.
방화벽·반환 경로요청이 서버에 도착했지만 응답이 없으면 응용 로그와 수신 큐를 보고, 응답이 서버에서 나갔으면 귀환 경로··를 살핀다. PAT의 상태는 일정 시간 후 만료될 수 있어 아주 늦은 응답이나 장시간 유휴 후의 inbound 데이터가 전달되지 않을 수 있다.
- 한쪽 캡처의 침묵과 양끝에서 확인한 패킷 손실은 증거의 범위가 다르다.

11짧은 출력으로 프로토콜·포트·거래를 연결하기

소켓·패킷 관찰서버에서는 소켓의 Local Address와 Port를 먼저 읽는다. UNCONN 같은 표시는 소켓의 상태 표현이지 서버 고장을 뜻하지 않는다.
- 캡처에서는 IP protocol, 양쪽 포트, , checksum 상태와 응용의 거래 번호를 이어서 읽는다.
- 송신 측 checksum offload 때문에 호스트 캡처에서 미완성 체크섬이 보일 수 있으므로 외부 수신 캡처와 구분한다.
전송 방식 비교·를 비교할 때 흐름 제어·오류 대응·혼잡 제어를 구분한다. 최종 보고서에는 사용한 응용 메시지, 전송 크기, 거래 응답, 유실·재시도 여부를 함께 제시해야 “라서 안 된다” 같은 설명을 피할 수 있다.

text

ss -lun
# Local Address:Port가 실제 수신 인터페이스인지 읽는다.

Wireshark display filter:
udp.port == 53

192.0.2.10:53000 -> 198.51.100.53:53
UDP Length: 28 (8-byte header + 20-byte data)
IPv4 Total Length: 48 (20-byte header + 28-byte UDP)

읽기 전용 관찰 및 합성 출력 예.

검증·예외

12UDP 무응답에서 구별해야 하는 실패 분기

소켓 미존재목적지에서 해당 포트를 받는 소켓이 없으면 Port Unreachable이 돌아올 수 있다. 가 정책상 차단되거나 제한되면 같은 상태가 단순 시간 초과로 보일 수 있다.
소켓은 있으나 수신 실패수신 버퍼가 가득 차면 도착한 데이터그램이 응용에 전달되지 못할 수 있다. 링크 수신량과 응용 수신 수의 차이를 시스템 드롭 통계와 연결한다.
응용 요청 식별는 요청 ID를 정의하지 않는다. 등의 상위 프로토콜은 ID·질문·상대 주소를 이용해 응답을 짝짓고, 재시도·중복 처리·유효 기간을 자체적으로 관리한다.
잘린 수신 버퍼응용이 제공한 수신 버퍼가 데이터그램보다 작으면 API에 따라 초과 부분이 버려지거나 잘림이 표시된다. 처럼 다음 읽기에서 나머지가 자동으로 이어진다고 가정하지 않는다.
원본 인용 대조 오류 안의 원본 IP와 헤더에서 주소·포트를 읽어 어떤 요청이 실패했는지 연결한다. 가 있으면 외부 포트와 내부 소켓 사이의 변환도 함께 추적한다.

학습 확인

이해했는지 확인하기

동일 포트 숫자의 TCP와 UDP 규칙을 구분했는가?
응답 없음이 서비스 중단이라는 근거가 충분한가?
신뢰성·혼잡 대응을 어느 계층이 담당하는가?

개념부터 찾아보기

이 노트에서 설명할 수 있게 되는 것

01UDP가 제공하는 단위와 제공하지 않는 기능