😅 필자가 개인적으로 공부하고 남기는 것이기 때문에 정보가 미흡할 수 있습니다. 잘못된 내용이나 추천해주실 방법이 있을경우 댓글 남겨주신다면 감사히 받겠습니다.
네트워크 동작방식을 다시한번 공부하며 DHCP에 대해 다시 학습해보았다. 예전에는 단순히 DHCP는 IP 주소 할당하기위한 과정이구나.. 하고 넘겼지만 다시 공부해보니 생각할 것도 많고 여러 의문점도 생겼다.
그 중 가장 이해가 되지 않았던 DHCP Offer과정에서 브로드 캐스트 방식을 사용하는 이유에 대해 알아보고자한다.
DHCP 란?
일반적으로 컴퓨터는 외부 네트워크를 사용하기위해 ip와 서브넷마스크와 같은 환경을 설정해야한다.
DHCP는 이러한 네트워크 환경을 컴퓨터가 부팅되는 시점에 외부 네트워크와 통신할 수 있도록 자동으로 설정해주는 프로토콜이다.
DHCP 동작과정
사용자가 ip주소를 할당받기위해서는 DHCP 서버에 요청을 보내야한다. 하지만 컴퓨터는 DHCP 서버의 ip정보도 모르기에 이를 파악하기위한 요청이 필요하다.
1. DHCP Discovery
- 출발지 ip에
0.0.0.0을 할당하고 목적지 ip에255.255.255.255를 할당하여 네트워크 상의 모든 장치에게 요청을 전송하기위한 준비를 한다. - 그리고 출발지 MAC주소에 자신의 MAC주소를 할당하고 목적이 MAC주소에 FF:FF:FF:FF:FF:FF값으로 할당하여 요청이 브로드캐스트임을 알수 있도록 한다. (DHCP 서버의 MAC주소도 모르기에 해당 방법 사용)
- 그리고 이를 브로드캐스트 요청을 보냅니다. 이 과정을 DHCP Discovery라고 한다.
2. DHCP Offer
- 브로드캐스트로 보내진 요청은 DHCP 서버를 제외한 곳에서는 버려지고 DHCP 서버는 요청을 받는다.
- 요청을 받은 DHCP 서버는 컴퓨터에 할당할 ip를 생성하고 컴퓨터에 보낼 요청을 생성한다.
- 그리고 출발지 Mac주소와 ip주소는 DHCP서버의 정보를 넣고, 목적지 Mac주소에는 컴퓨터의 Mac주소, ip는 방금 생성한 ip를 포함하여 네트워크 정보가 담긴 메세지를 생성한다.
- 그리고 이를 브로드캐스트 or 유니캐스트 요청을 보낸다. 이러한 과정을 DHCP Offer이라 부른다.
3. DHCP Request
- 컴퓨터는 DHCP Offer과정으로 전달받은 메세지를 받는다.
- 그리고 이를 사용하겠다는 요청을 다시 DHCP 서버로 보낸다. 이 과정을 DHCP Request라 부른다. (해당 방식은 3 -Way Handshake 처럼 신뢰성을 확보하는 과정이라 생각했다....아닐수도..ㅎ)
4. DHCP ACK
- 최종적으로 DHCP 서버는 요청을 처리했다는 메세지를 컴퓨터에 보낸다.
- ip를 다른 서버에서 사용할 수 없도록 해당 ip를 사용 중이라 기록하고 한다. 이 과정을 DHCP ACK라고 한다. (ip 주소는 기본적으로 임대한 것이다. 때문에 일정 기간 사용하지 않으면 다시 반납되어 새로운 IP를 할당받아야 한다.)
브로드캐스트 vs 유니캐스트
필자가 의문이 들었던 점은 왜 둘다 사용이 가능하지..? 어차피 MAC주소를 알고있는데 유니캐스트만 사용하는게 더 좋지 않을까? 였다...
유니캐스트는 1대1 통신방식으로 목적 노드에 요청을 보내고 랜카드에 존재하는 MAC주소를 비교하여 자신의 MAC주소와 일치할 시 요청을 처리하는 방식이다.
때문에 모든곳에 요청을 보내는 브로드캐스팅 방식보다 성능면에서 뛰어나고 랜카드에서 MAC주소만 비교하기 때문에 CPU 인터럽트를 일으키지않아 리소스 낭비도 줄일 수 있다.
이러한 이유로 당연히 유니캐스트를 사용할거라 생각했지만, 공부를 위해 찾아본 블로그 대부분에는 유니캐스트 방식은 적어놓지않고 브로드캐스트만 사용한다고 정리해놓은 곳이 많았기에 혼란이 왔다...
RFC문서를 보자...
때문에 답을 알기위해서는 그냥 RFC문서를 보면서 답을 찾는 수 밖에 없겠다는 생각을 했고 실제로 답은 간단했다.
유니캐스트 데이터그램을 수락할 수 없는 일부 클라이언트가 존재하기 때문이다.
RFC문서를 확인하면 위와같이 적혀있는 것을 볼 수 있다.
To work around some clients that cannot accept IP unicast datagrams before the TCP/IP software is configured as discussed in the previous paragraph, DHCP uses the 'flags' field
유니캐스트 데이터그램을 수락할 수 없는 일부 클라이언트가 존재하고 이를 해결하기위해 DHCP는 '플래그' 필드를 사용하여 유니캐스트와 브로드캐스트 방식을 선택하는 방법을 사용한다고 한다.
또한 아래와 같은 과정을 거쳐 유니캐스트와 브로드캐스드가 어떻게 선택되는지 알수 있다.
giaddr'인 경우 필드가 0이고 'ciaddr' 필드가 0이 아닌 경우 서버는 DHCPOFFER 및 DHCPACK 메시지를 'ciaddr'의 주소로 유니캐스트합니다. 'giaddr'이 0이고 'ciaddr'이 0이고 브로드캐스트 비트가 설정된 다음 서버는 DHCPOFFER 및 DHCPACK 메시지를 브로드캐스트합니다. 0xffffffff. 브로드캐스트 비트가 설정되지 않고 'giaddr'이 0이고 'ciaddr'이 0인 경우 서버는 DHCPOFFER 및 DHCPACK를 유니캐스트합니다. 클라이언트의 하드웨어 주소와 'yiaddr' 주소로 메시지를 보냅니다. ~ 안에 모든 경우에 'giaddr'이 0이면 서버는 모든 DHCPNAK를 브로드캐스트합니다. 0xffffffff에 메시지를 보냅니다
추가적으로 DHCP OFFER의 flags옵션을 확인해보면 DISCOVER에 설정된 플래그값에 따라 브로드캐스트, 유니캐스트 요청방식이 결정되는 것을 확인할 수 있다. 단말이 보낸 DHCP Discover 메시지 내의 Broadcast Flag의 값에 따라 Flag=1이면 Broadcast로, Flag=0이면 Unicast로 보낸다.
여담 - 진짜인지 확인해보기
사실 RFC문서를 봤지만 확인하기위해 실제로 Wireshark 로 패킷추적해보았다.
필자의 컴퓨터는 Discover, Request는 브로드캐스트 Offer, ACK는 유니캐스트방식을 사용했다.
책이나 블로그의 설명을 보면 가끔 브로드캐스트 방식만 이용한다고 하던데...일단 해당 정보는 아님을 알 수 있었다.
자세히 공부하고싶다면 RFC 문서를 읽어보는걸 추천드립니다.
https://www.rfc-editor.org/rfc/rfc951
https://www.rfc-editor.org/rfc/rfc2131
아래문서가 더 가독성이 좋습니다.
https://datatracker.ietf.org/doc/html/rfc2131
