DHCP 의 원리 - 인터넷이 저절로 되는 이유

Why

요즘, 어디든 자리를 이동하면 사람들이 꼭 찾는게 있습니다.
바로, WIFI 입니다.

까페에서 WIFI를 잡을 때를 상상해보세요.
잡을 수 있는 WIFI 목록을 보고, 선택하고, 비밀번호를 입력하면

짠- 연결됩니다.

그런데, 이 짧은 과정을 한번만 깊게 생각해봅시다.
이런 의문이 들지 않나요?

• 어떻게 내 장치에 네트워크 셋팅을 해주는거지? (그것도 무선으로)
• IP 주소가 다른 사람과 왜 안 겹치지?
• 누가 나한테 IP를 주는거지?

듣고 보니 의아 하죠?
오늘 글을 보시면, 이 또한 이해 됩니다.

WIFI의 SSID가 있는 이유

WIFI는 선이 없는 무선 입니다.
유선은 그 선이 어느 장치에 물리적으로 연결 되어 있는지 알 수 있기 때문에,
내가 어디에 연결하는지 정확히 알고 있죠.

하지만 무선은요?
눈에 보이지 않기 때문에 어디에 연결하는지, 구분 할 필요가 있습니다.
그래서 SSID (Service Set Identifier) 라는 것이 생겼는데요.

무선이다보니 무선으로 광고하는 것입니다.
스스로 내가 누구라고 말할테니 나를 보고 식별해서 들어오세요. 가 됩니다.

마치 광고판 같죠?
여러분이 오프라인에서 광고를 노출 하는데, 사람을 가려서 보이게 할 수 있나요?

없죠.

SSID는 그래서 광고판 처럼 퍼블릭한 특징을 갖습니다.

물론, 숨길수도 있긴 해요.
그래도, 진짜로 숨겨진건 아닙니다. (숨겨진 SSID 보는 방법 너무 쉬워요)
그리고, 일반적으로는 숨기지 않죠.

아무튼 그렇습니다.

SSID 를 선택하면 일어나는 일

자- SSID를 하나 골랐습니다.

그럼 맞는 비밀번호를 입력하거나,
퍼블릭이라면 비밀번호 없이 바로 연결되고,

몇초가 흐르면
짠- 인터넷이 터집니다.

그런데요.

이 몇초동안 일어나는 일이 눈에 보이지는 않지만
되게 재밌게 진행됩니다.

WIFI에 연결하면 첫 순간, DHCP가 작동 합니다.

DHCP 들어보셨나요?
Dynamic Host Configuration Protocol 의 약자 입니다.

다이나믹 호스트 설정 프로토콜?
오- 뭔가 동적으로 호스트를 설정해주는 것 같은데

맞습니다.

DHCP는 네트워크 라우터 (보통, 공유기죠)에서 지원하는 기능으로
나의 네트워크에 입성하고자 하는 장치들에게,
IP를 동적으로 부여해줄 수 있는 기능 입니다.

그리고 CIDR로 정해진 내 IP 범위 안에서, 겹치지 않게 미사용 IP를 관리하고 나눠주죠.

사실, 네트워크 설정을 할 수 있다면, IP를 내가 직접 지정 할 수도 있어요.
하지만, 카페에 올때마다 IP를 받아 적고 네트워크 설정을 하고 싶진 않죠?
생각만 해도 끔찍합니다.

그런데, DHCP는 어떻게 동작하길래 이 복잡한 일이 가능할까요?

DHCP 의 동작 원리

여기서 TCP/IP 의 재밌는 기능이 사용 됩니다.

여러분 혹시 브로드캐스트 IP (Broadcast IP) 라는 주소를 들어보셨나요?
아니라면, 이런 IP 보신적 있으신가요?
255.255.255.255

위 IP는 주소의 모든 Bit가 1로 채워진, 가용 범위중 가장 마지막 IP 입니다.
이 IP는 특수한 IP로 사용되고 브로드캐스트 IP라고 해요.
(이런식으로 특수목적 IP 들이 몇개 있습니다만, 앞으로 차차 풀어드리겠습니다.)

브로드캐스팅은 방송을 뜻하죠?
그럼 브로드캐스트 IP는 무슨 목적 일까요?

네, 말 그대로 특수하게 설정된, 방송용 IP 라는 뜻이에요.

방송이라니, 누구에게요?
바로, 이 네트워크에 연결된 모두에게 입니다.

쉽게 말해, 네트워크에서 서로 통신 하려면 서로 IP를 알아야만 합니다.
근데, 이 IP로 송신 하잖아요?
그럼 이 네트워크 안에 있는 모두에게 다 보내버립니다.

무언가 메세지를 보내면, 의미가 있는 장치는 듣고, 아닌 장치는 그냥 버리는 식으로 동작합니다. (라디오 처럼)

재밌죠?

그런데, 방송 할때 우리가 아는 HTTP 같은 프로토콜을 쓰지는 않고요.
바로 DHCP를 씁니다. HTTP도 끝에 프로토콜 이에요.

그래서, DHCP가 IP를 받는 방법

정말, 직관적이고 심플 하게 합니다.
이렇게 합니다.

• 네트워크에 연결 하고 싶은 사람이 SSID로 일단 무선 연결을 시도 합니다
  • 이때는 TCP/IP가 아니라 꽤 복잡한 IEEE 802.11 프로토콜 같은걸 써요.
  • 아무튼 아직은 DHCP를 안씁니다.
• 위 과정으로 무선 연결이 설정되면, 이제 DHCP를 사용합니다.
  • 255.255.255.255 로 메세지를 날립니다. 이렇게요.
  • 나) “저한테 IP주소 주실분”
  • 이런 메세지를 DHCP Discover 메세지라고 해요.
• 그러면 이제 네트워크 안에 있는 DHCP 서버가 듣고 호텔 카운터 마냥, 응답을 합니다.
  • DHCP) 오~ 환영합니다 신규고객님
  • DHCP) 192.168.0.101 이 마침 있는데 빌려드릴까요?
• 나) 오, 번호 좋네요 그럼 제가 쓰겠습니다.
  • DHCP) 네 고객님, 그럼 192.168.0.101 사용하시고요…
  • DHCP) 반납 시간은 1시간 후 입니다!
• 나) 넵! 감사합니다. (근데 왜 한시간…)

이렇게 IP주소를 빌려서 인터넷에 입성하게 됩니다.
그런데, 1시간 후에 반납이라니 쫌 그렇죠?

사실, 내가 계속 쓴다고 연장 해야 한답니다.
하지만, 여러분의 OS가 알아서 하고 있기 때문에 신경쓰지 않으셔도 돼요.

에이 설마 이게 진짜 인가?
이게 최선인가? 더 좋은 방법 있지 않을까? (없어요)

아직 긴가민가 하실 분들을 위해서, 실제 사례로 알아보죠.

dhclient

Linux 에는 dhclient 라는 CLI 프로그램이 있습니다.
이 프로그램은 DHCP 요청을 수동으로 하는 기능을 가지고 있어요.
제가 위에 설명한 저 내용을 눈으로 보실수 있죠.
예를 들면 아래처럼요.

$ dhclient -v eth0
dhclient[1234]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5
dhclient[1234]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
dhclient[1234]: DHCPOFFER from 192.168.1.1
dhclient[1234]: DHCPREQUEST on eth0 to 255.255.255.255 port 67
dhclient[1234]: DHCPACK from 192.168.1.1
dhclient[1234]: bound to 192.168.1.100 -- renewal in 3600 seconds.

• v 를 붙이면 verbose 의 약어로, 내부 처리 내용을 콘솔에 로깅해 줍니다.

보시면 제가 설명한 내용 그대로 있을 거예요.

아, 이 명령을 실제 서버에서 하지는 마십시오.
실제 eth0 의 IP를 DHCP로 바꿔 버릴 수 있습니다.

아무튼, 이제 이해가 잘 되셨죠?

마무리

우리는 어디서든 WIFI를 통해 쉽게 인터넷에 연결할 수 있습니다.
DHCP 덕분에 복잡한 네트워크 설정 없이, 간단히 인터넷을 사용할 수 있는 것이죠.

공유기 외에도 여러분이 집에서 이용하시는 통신사의 인터넷 서비스도 DHCP를 사용 하고 있습니다.
(유동 IP 서비스라고 하죠.)

이 경우 브로드캐스팅에 응답하는 DHCP 서버는 아파트 어딘가에 설치된 통신사 장비 안에 있을 거예요.
255.255.255.255 에 빠르게 응답해야 고객 클레임이 없기 때문이죠.

(네트워크에 따라 이 주소는 다를 수 있지만, IPv4에서는 항상 서브넷 브로드캐스트 주소의 끝이 255입니다.)
아참, 유선 LAN 은 어떻게 되냐고요?
유선 LAN도 완전 똑같습니다. 공유기에 LAN 선을 뽑아 내 PC에 꼽는 순간 DHCP가 작동 합니다.

AWS에도 VPC의 서브넷이 이 DHCP 기능을 가지고 있습니다.
그래서 EC2 인스턴스 를 만들면 IP가 자동으로 부여되죠.
또한 도커에서도 bridge 네트워크가 이 역할을 합니다.
(사실, 도커는 DHCP는 아니고 자체 규격을 쓰지만 IP를 동적으로 부여하는 것은 똑같습니다.)

DHCP, 생각보다 많이 쓰이죠?

긴글 읽어주셔서 감사합니다.
다음에도 좋은 글로 찾아올께요.

ps.

간간히, 제게 이런걸 어떻게 아냐고 물으시는 분이 계십니다.

저는 과거 On-Premise 환경에서 수천대 서버의 트러블 슈팅을 꽤 오래 했습니다. (20년차)
현재의 클라우드는 그런 On-Premise 기술이 바탕이 되어 더 고도화 된 것이고, 사실 베이스는 같습니다.
프로그래밍도 마찬가지고요. (전 Dos 시절 부터 개발을 시작했어요)

동작 원리를 이해하지 못하면, 문제도 수정할 수 없었기 때문에
제 글들은 경험으로 체득한 내용들이 주가 됩니다.

앞으로도 나눠 드릴수 있도록 노력할께요.

아임웹 CTO 매튜 드림.