생각했으면 행동한다 GitHub

CS/네트워크

DHCP

현진용 2025. 9. 30. 15:53

무엇?

오늘은 평소에 곧잘 WiFi를 연결하는 과정에서 사용되는 DHCP(Dynamic Host Configuration Protocol)에 대해서 공부한 내용을 정리하고자 한다.

DHCP는 IP만이 아니라 서브넷(prefix), 기본 게이트웨이, DNS 서버까지, 네트워크 통신에 필요한 다른 구성 정보를 함께 자동으로 할당해주는 자동 설정 프로토콜이다.

우리가 컴퓨터나 스마트폰으로 인터넷(네트워크)에 연결할 때마다 매번 IP주소를 할당하지 않아도 되는 이유가 바로 이 DHCP 덕분이다. 

참고로 무선(Wi-Fi)뿐 아니라 유선 LAN도 똑같이 DHCP를 쓴다.

 

왜 필요한가?

일반적으로 가정에서 쓰이는 공유기를 예로 들어보자.

보통 DHCP 서버 역할을 일반 가정집에서는 공유기가 맡고 있다.

만약 우리가 와이파이에 사용하려고 할 때마다 공유기의 신호를 보내서 IP주소를 수동으로 할당(정적 할당)한다고 해보자.

물론 IP 주소뿐만이 아니라 서브넷 마스크, 기본 게이트웨이 주소, DNS 서버 주소 같은 정보도 있지만 이해를 위해 IP주소만 할당해야 한다고 가정한다.

평생 한 번만 사용하면 된다면 그리 번거롭지 않을 테지만 밖에 나가서 돌아올 때 매번 수동으로 처리하면 여간 번거로운 일이 아닐 수 없다. 또 사람이 직접 하다 보니 실수가 발생할 여지가 있다.

DHCP는 이러한 수동 작업을 없애고, 기기가 네트워크에 연결될 수 있는 상태(플러그 앤 플레이)라면 바로 작동할 수 있게 해주는 역할을 수행한다.

로컬 네트워크에 연결되면 IP가 할당된다.

 

이는 영원한 것이 아니라 임대(lease)를 하는 형식이다. 만료 시간 이후에 갱신 작업이 진행된다.

 

DORA

DHCP가 실제로 동작할 때 패킷이 오가는 흐름을 DORA라고 한다.

설명은 위해 다음과 같은 환경을 가정한다.

  • 나(클라이언트) : 방금 네트워크에 합류한 장치, 아직 IP가 없는 상태다.
  • 상대(서버) : 공유기 안의 DHCP서버
  • 전송은 UDP 68(클라이언트) ⇄ 67(서버) 포트를 사용.

D — Discover

내(클라이언트)가 IP를 필요로 한다. DHCP 서버를 찾아야 하므로 브로드캐스트(IP - 255.255.255.255, MAC - ff:ff:ff:ff:ff:ff ) 보낸다.

브로드캐스트로 보낼 때는 클라이언트 MAC 주소와 받고자 하는 옵션(DNS, 게이트웨이 등)을 포함한다.

O — Offer

DHCP 서버가 IP 주소를 추천해주는 OFFER를 보낸다. 여기서는 브로드캐스트로 보내거나 유니캐스트로 보낼 때도 있다.

서버 67 → 클라이언트 68

핵심 옵션들은 다음과 같다.

  • 제안 IP(yiaddr): 예) 192.168.0.23
  • 서브넷 마스크: 예) 255.255.255.0
  • 기본 게이트웨이(router): 예) 192.168.0.1
  • DNS 서버: 예) 1~2개 주소
  • 임대 기간(lease time)
  • 서버 식별자(server identifier): “이 오퍼를 보낸 서버는 나야!” 라는 표식

R — Request

만약 2개의 다른 DHCP 서버에서 동시에(비슷한 시각에) offer를 보내면 클라이언트는 먼저 도착한 offer를 채택한다. 그 offer 안에 담긴 server identifier를 저장해놓고, 그 서버에게 추천받은 IP를 사용한다는 확정 신청을 보낸다.

물론 서버에 DHCPREQUEST를 보내도 브로드캐스트이다. 아직까진 IP주소가 확정되지 않았기 때문이다. 그리고 같은 네트워크에 있는 다른 서버에 이 IP를 사용한다고 알려야 하는 이유도 있다. 내가 이사하고 여기에 사는 사람이라는 것을 이웃이나 주민센터에 알려주는 것과 같다.

A — Ack

선택받은 DHCP 서버가 DHCPACK을 보낸다. 여기서는 서버에 따라 브로드캐스트나 유니캐스트를 보낸다.

최종 IP/서브넷/게이트웨이/DNS/임대기간 확정본을 클라이언트에게 보내는 것이다. 클라이언트는 이걸 받으면 설정을 적용하고 통신을 시작한다.

임대(lease)를 갱신하는 타이머도 설정된다. 보통 T1 = 임대의 50%, T2 = 87.5% 시점에서 갱신을 시도한다.

만약 서버가 거부하면 DHCPNAK를 보내고, 클라이언트는 다시 Discover 단계로 돌아온다.

 

여기서 한 가지 의문이 든다. IP 중복이 발생하진 않을까?

 

동일한 호스트 네트워크에서 DHCP서버에 의해 IP를 부여받는다면 중복은 없을 거라고 보는 게 무방하다. 다만 무엇이든 예외는 있는 법. 특히 회전율이 높은 대규모 카페 공유기를 상상해보자. 하루에 수천 단위의 사람들이 공유기에서 IP를 할당받고 그중 수십 수백 명이 동시에 DHCP 서버에 요청을 보낸다면 예외가 일어날 수 있다.

그러므로 IP 중복에 의한 충돌을 방지하기 위해서 클라이언트는 마지막 ACK 단계에서 Gratuitous ARP(그라튜이투스라고 읽는다)를 보낸다.

Gratuitous ARP?

ARP는 로컬 네트워크에서 IP주소를 MAC 주소로 변경하는 프로토콜이다. 그렇다면 그라튜이투스 ARP는 뭘까?

먼저 내 IP <-> MAC 주소를 알리기 위한 ARP이다.

보통 브로드캐스트 ARP로 요청을 보낸다. 그렇다면 왜 내 정보를 알려야 하는 걸까?

  1. 혹시 이 IP 쓰는 사람 있나요?
    • 위에서도 언급했지만 IP 중복으로 인한 충돌을 방지 하기 위함이다. 응답이 오면 충돌로 인식하여 해당 IP는 폐기한다.
  2. ARP 테이블 갱신하자
    • 이는 캐시 메모리다. ARP 요청을 지속적으로 보내면 비효율적이기 때문에 자주 요청하거나 인접한 장치와 통신할 때 사용한다.
  3. 나 여기 살아요
    • 주소 공표의 목적으로도 사용된다. 이 IP는 이 MAC 주소라는 것을 알린다.

 

DORA 순서

 

패킷 캡쳐로 DORA 확인

실습해볼 겸 패킷을 캡쳐해서 DORA 과정을 확인해보았다. 환경은 다음과 같다.

OS : 윈도우 11
캡쳐 도구 : WireShark(npcap)

다음 명령어로 IP 초기화 및 갱신
ipconfig /release -> ipconfig /renew
# 초기화
무선 LAN 어댑터 Wi-Fi:

   연결별 DNS 접미사. . . . :
   링크-로컬 IPv6 주소 . . . . : fxxx::dxxx:ebc1:212a:9xxxx
   기본 게이트웨이 . . . . . . :
# 갱신
무선 LAN 어댑터 Wi-Fi:

   연결별 DNS 접미사. . . . :
   링크-로컬 IPv6 주소 . . . . : fxxx::dxxx:ebc1:2xxx:9xxxx
   IPv4 주소 . . . . . . . . . : 172.29.8.140
   서브넷 마스크 . . . . . . . : 255.240.0.0
   기본 게이트웨이 . . . . . . : 172.30.1.254

 

캡쳐본(트랜잭션 ID는 일부러 제외했다)

자 이제 캡쳐본을 보자. 초기화 이후에 DORA가 순서대로 잘 진행됐다는 걸 알 수 있다.

Offer 단계에서는 브로드캐스트로 보낼 줄 알았는데 유니캐스트였다는 게 의외였다. 구현 방식에 따른 차이지 않을까 싶은데 이 부분은 나중에 더 알아봐야겠다.

 

또한 의아했던 점은 Request 단계가 2번이나 발생했다는 것이다.

확인해보니 클라이언트(나, 172.29.8.140)가 DHCP 서버(172.30.1.254)에 임대 기간(lease time)을 연장해달라는 요청이었다.

그런데 시간을 보면 IP를 할당받은 직후 2초 뒤에 연장 요청이 발생했다. 임대 기간 갱신 타이밍을 보통 T1=50%로 잡았을 때 적어도 2~4초라는 것인데 임대 기간이 이 정도로 짧다는 게 납득이 되지 않는다.

아마 내가 IP를 초기화하고 갱신하는 과정에서 동일한 IP를 할당받았기 때문에 임대 기간도 기존 것을 그대로 쓰인 것으로 추정된다.

그렇지 않다면 2~4초라는 시간은 시스템 성능 측면에서 용인될 게 아니다.100명이 무선랜을 1분 간 사용했을 때 4초마다 갱신된다면 1분간 약 1500번의 요청이 발생한다는 것이다.. 이 정도면 사람도 과로로 쓰러질 것이다.

 

생각

DHCP와 그 동작 과정에 대해 배웠다. 확실히 이를 구현할 때는 OSI 7계층이나 TCP/IP와 같이 참조될 뿐이지 그대로 되진 않는다. 특히 Offer 단계에서 유니캐스트 통신은 배웠던 내용과는 다르다. 표준만 정해놓고 목적과 상황에 따라 세세한 부분에서 차이가 있는 것 같다.

문득 궁금해서 공부했지만 당장은 현업에 투입되어도 DHCP 서버를 다룰 일이 없을 것 같다. 이미 산업 전반적으로 잘 구축되어있기 때문이다. AWS 환경에서 새로운 인스턴스를 생성하면 금방 Public하게 쓸 수 있는 것처럼 말이다. 다만 안정적인 운영을 해야 한다는 입장에 놓이면 이런 지식은 언젠가 쓰일 것이라 생각한다. 직접 다루지 않더라도 내가 마주한 문제를 저수준에서 해결해야 할 때 그 실마리가 될 수도 있다. 그러니 잘 배워간다.

반응형

'CS > 네트워크' 카테고리의 다른 글

HyperText Transfer Protocol  (1) 2025.10.24
네트워크 - 소켓, 리눅스 네트워크 관리  (0) 2025.03.13
네트워크  (1) 2025.03.11
네트워크 프로그래밍  (1) 2023.08.31
네트워크(11) - 전송층  (0) 2023.06.14

'CS/네트워크'의 다른글

  • 현재글DHCP

관련글

티스토리툴바