IITP Google Learning Program '컴퓨터 네트워킹의 모든 것' 강의 중
DNS가 UDP를 사용하는 이유 & TCP와의 비교
DNS는 전송 계층에서 TCP 대신 UDP를 사용하는 대표적인 애플리케이션 계층 서비스이다.
이는 몇 가지 이유로 간단히 분석할 수 있다.
1. UDP는 비연결 프로토콜이다
UDP는 연결을 설정하거나 해제할 필요가 없는 비연결 프로토콜이다. 이로 인해 TCP보다 훨씬 적은 트래픽으로 데이터를 전송할 수 있다. DNS 요청과 응답은 일반적으로 단일 UDP 데이터그램에 담을 수 있기 때문에 UDP를 사용하는 것이 적합하다.
2. DNS 트래픽의 특성
DNS는 로컬 시스템과 캐싱 네임서버를 활용해 캐시된 항목을 저장하지만, 전체를 확인해야 할 경우 트래픽이 증가한다. 이 경우에도 UDP는 간단한 프로토콜 특성 덕분에 효율적인 트래픽 처리가 가능하다.
1) TCP로 DNS 요청을 처리하는 경우 - 오버헤드
TCP를 통해 DNS 요청을 처리할 경우 연결 설정과 종료에 필요한 추가 작업이 발생한다. 이를 간단히 시나리오로 설명하면 다음과 같다.
Step 1. 3-way 핸드셰이크
- 클라이언트가 로컬 네임서버에 SYN 패킷 전송
- 네임서버가 SYN-ACK 응답
- 클라이언트가 ACK로 응답
총 3개의 패킷이 소모된다.
Step 2. DNS 요청 및 응답
- 클라이언트가 요청 전송 (“food.com의 IP 주소를 알려주세요”)
- 네임서버가 요청을 수락했다는 ACK 전송
- 이후 재귀적으로 루트 서버, TLD 서버, 권한 네임서버로 요청을 반복
- 각 단계마다 다음 과정이 필요하다.
- 연결: 3-way 핸드셰이크 ▶ 패킷 3개
- 요청 및 응답: 요청을 보내면 응답을 보냄 ▶ 패킷 2개
- 패킷 전달 상태 확인: 요청 패킷에 대한 ACK와 응답 패킷에 대한 ACK ▶ 패킷 2개
- 연결 닫기: 4-way 핸드셰이크 ▶ 패킷 4개
각 네임 서버와 통신 시 11개의 패킷이 소모된다.
Step 3. 4-way 핸드셰이크로 연결 종료
로컬 네임서버가 food.com의 IP 주소를 확인한 후, 클라이언트에 응답을 전달한다.
- 클라이언트가 응답을 확인하기 위해 ACK를 보냄.
- 마지막으로 4방향 핸드셰이크를 통해 연결을 종료.
연결 종료에는 FIN, ACK 패킷을 포함해 4개의 패킷이 추가로 사용된다.
총 패킷 수
약 44개의 패킷이 소모된다.
- 3방향 핸드셰이크: 3개
- 루트 네임서버 요청 및 응답: 11개
- TLD 네임서버 요청 및 응답: 11개
- 권한 네임서버 요청 및 응답: 11개
- 클라이언트 응답 및 연결 종료: 8개
총 패킷 수는 44개 이상으로, 이는 간단한 DNS 요청을 처리하기에는 비효율적이다.
2) UDP로 DNS 요청을 처리하는 경우 - 효율적
UDP를 사용할 경우 TCP와 비교해 훨씬 적은 패킷으로 처리할 수 있다.
DNS 요청과 응답
- 클라이언트가 로컬 네임서버에 UDP 요청 전송 (패킷 1개)
- 로컬 네임서버가 루트 서버, TLD 서버, 권한 네임서버와 재귀적으로 통신 (패킷 6개)
- 마지막으로 로컬 네임서버가 클라이언트에 응답 (패킷 1개)
총 패킷 수는 8개로, TCP와 비교해 훨씬 효율적이다.
3) UDP의 단점과 TCP의 보완
UDP는 비연결 프로토콜로 오류 복구 기능이 없다. 그러나 DNS는 애플리케이션 계층에서 이를 보완한다.
DNS 리졸버가 응답을 받지 못할 경우 단순히 다시 요청하면 된다.
즉, DNS는 UDP의 간소함과 TCP의 기능 일부를 애플리케이션 계층에서 구현한 셈이다.
4) DNS에서 TCP가 필요한 경우
UDP 데이터그램 크기를 초과하는 DNS 응답이 필요한 경우 TCP가 사용된다.
DNS 네임서버는 응답이 너무 크다는 메시지를 보내고, 클라이언트는 TCP 연결을 설정해 요청을 처리한다.
UDP와 TCP를 적절히 사용하는 DNS는 간단하면서도 유연한 프로토콜의 좋은 사례이다.