brunch

PC 1대로 구현하는 미니 인터넷! 네트워크 전체 흐름

네트워크 전체 흐름 A to Z 실습

by 위키북스
브라우저에 www.google.com을 입력하면 어떤 일이 벌어질까?

IT 분야에 종사하거나 공부하는 분들이라면 한 번쯤은 들어봤을 면접 질문이자, 네트워크의 핵심을 관통하는 질문입니다. 우리는 머리로는 DHCP, DNS, TCP/IP 같은 용어들을 알고 있지만, 이 기술들이 어떻게 유기적으로 맞물려 동작하는지 실제로 본 경험은 드뭅니다.


이론과 실무 사이의 간극을 느끼는 많은 분들을 위해, 『도커로 구축한 랩에서 혼자 실습하며 배우는 네트워크 프로토콜 입문』 도서의 최종장을 바탕으로 PC 1대 안에 작은 인터넷 환경을 구축하고, 웹사이트 접속 요청이 어떤 여정을 거쳐 우리 눈앞에 나타나는지 A부터 Z까지 추적해보겠습니다.





실습 환경: 내 PC 안의 작은 인터넷

이번 실습은 책에서 제공하는 최종 구성 파일(spec_01.yaml)을 사용하여 구축된 환경을 전제로 합니다. 이 환경은 크게 세 부분으로 나뉩니다.


가정 내 LAN: 우리가 사용하는 PC(cl1)가 위치한 내부 네트워크입니다.

인터넷: 여러 가상 라우터(rt1, rt2, rt3)가 서로 연결되어 패킷을 전달하는 공간입니다.

서버 사이트: 방화벽(fw1), 부하 분산 장치(lb1), 그리고 두 대의 웹 서버(sv1, sv2)가 위치한 서비스 공간입니다.


AD_4nXfQ27av45pItOLbtQbJnLaILFqpD1GuR7qLcBoMhaJSltLU7p2cAYmrbA8UCu_qGnZY4Xp40Ovk5dwuG5SdjieOKDZpUf5kMH2aPEiNlypf-eYblgeu549yvFnd3ijq3Qhh9B1x2g?key=52EUevA9e96nkndoBhk1Ig


이제, cl1 PC에서 https://www.example.com/에 접속하는 과정을 6단계로 나누어 따라가 보겠습니다.





1단계: NIC 설정 (DHCP)

PC의 전원을 켜고 네트워크에 연결하면 가장 먼저 일어나는 일은 IP 주소를 할당받는 것입니다. IP 주소가 없으면 인터넷 세상에서 편지를 보낼 주소도, 받을 주소도 없는 것과 같습니다.


[작동 방식]


1. DHCP Discover: IP 주소가 없는 cl1은 "혹시 IP 주소를 나눠주실 분 계신가요?"라는 요청(DHCP Discover)을 네트워크 전체에 브로드캐스트로 전송합니다.

2. DHCP Offer: 이 요청을 들은 DHCP 서버(가상 광대역 라우터 rt1)가 "이 IP 주소(192.168.11.1)를 사용하세요"라고 제안(DHCP Offer)합니다.

3. DHCP Request: cl1은 "네, 그 주소를 사용하겠습니다"라고 다시 한번 네트워크에 요청(DHCP Request)합니다.

4. DHCP ACK: rt1은 "알겠습니다. 이제 그 주소는 당신 것입니다"라고 최종 확인(DHCP ACK) 메시지를 보냅니다.


이 과정을 통해 cl1은 IP 주소뿐만 아니라 통신에 필요한 기본 게이트웨이와 DNS 서버의 IP 주소 정보까지 자동으로 설정받게 됩니다.

AD_4nXdMh9_FNY2K4id_WmToHeWkqc69hF7kFQRXIibY9WpZtnXXhVFVBN4GNr1d5QJgvb4J9ToO3skT9zsziBKO3_fdiSmxCKTsNDPnwhBasi2Aep6F-5PP9iX6xy9K25KtdHx2ixGXiA?key=52EUevA9e96nkndoBhk1Ig





2단계: 주소 확인 (ARP)

이제 cl1은 IP 주소를 가졌습니다. 하지만 IP 주소는 논리적인 주소일 뿐, 실제로 같은 네트워크 내에서 데이터를 전달하려면 하드웨어 고유 주소인 MAC 주소를 알아야 합니다. cl1이 인터넷으로 나가기 위한 첫 관문인 기본 게이트웨이(rt1)의 MAC 주소를 알아내는 과정이 바로 ARP입니다.


[작동 방식]


1. ARP Request: cl1은 "192.168.11.254 IP 주소를 가진 분, MAC 주소 좀 알려주세요"라고 ARP 요청을 브로드캐스트합니다.

2. ARP Reply: 요청을 받은 rt1은 "제 MAC 주소는 02:42:ac:01:12:54입니다"라고 응답(ARP Reply)합니다.


이제 cl1은 rt1에게 패킷을 보낼 수 있는 모든 준비를 마쳤습니다.


AD_4nXeysx7ix6lylRYdfVEUbJR3s-1LjjKhuXKBCR0zjC-HB3_aB2XFlcsd8FHMp62JGdeusNi7Yd0SA4FNQ2XBrFQ-NrXDGhAqBdNMiFCjuXMOUwv1EUvp1xGAzplOf9iFS-3zzjoNWA?key=52EUevA9e96nkndoBhk1Ig





3단계: 이름 풀이 (DNS)

사용자는 https://www.example.com/이라는 도메인 주소를 입력했지만, 컴퓨터는 10.1.3.12와 같은 IP 주소로 통신합니다. 이 도메인 이름을 IP 주소로 변환하는 과정이 '이름 풀이'이며, DNS가 이 역할을 담당합니다.



[작동 방식]

1. 재귀 쿼리: cl1은 설정된 DNS 서버(rt1)에게 "www.example.com의 IP 주소가 무엇인가요?"라고 질문(재귀 쿼리)합니다.

2. 전달: rt1은 DNS 포워더 역할을 하여 이 질문을 인터넷상의 DNS 캐시 서버(ns1)에 그대로 전달합니다.

3. 반복 쿼리: ns1은 최종 IP 주소를 알 때까지 계층 구조를 따라 상위 DNS 서버들에게 차례대로 질문(반복 쿼리)을 던집니다. - ns1 -> 루트 서버: ".com을 누가 관리하나요?"

- ns1 -> .com 서버: "example.com을 누가 관리하나요?"

- ns1 -> example.com 서버(lb1): "www.example.com의 IP 주소는 무엇인가요?"

4. 응답: 최종적으로 example.com의 권한 서버(lb1)가 "IP 주소는 10.1.3.12입니다"라고 응답하고, 이 정보가 역순으로 cl1까지 전달됩니다.

AD_4nXf2TJKc5vr9gyYHXvaXU0QEcGHN-6AkXjP03pxGUBgmgKdGsz1HR-kXqx-m3QGKurrCAj3lFneBPxcG_OGGr7stPtadgAFbp7hIqj4gGq6w7X9eLUlq9wJXd6N-pI7DzJKrLEXa6A?key=52EUevA9e96nkndoBhk1Ig





4단계 & 5단계: TCP 및 SSL 핸드셰이크


이제 목적지 IP 주소를 알았으니, 안전하고 신뢰성 있는 통신 채널을 만들어야 합니다. 이 과정은 TCP 3-Way Handshake와 SSL Handshake 두 단계로 이루어집니다.


[작동 방식]


1. TCP 3-Way Handshake: cl1과 최종 목적지인 부하 분산 장치(lb1) 사이에 신뢰성 있는 데이터 전송을 위해 TCP 연결을 설정합니다(SYN → SYN-ACK → ACK).2. SSL Handshake: TCP 연결이 수립된 후, 통신 내용을 암호화하기 위해 SSL 핸드셰이크를 시작합니다. 이 과정에서 서로 어떤 암호화 방식을 사용할지 협상하고, 서버 인증서를 확인하며, 데이터를 암호화하고 복호화하는 데 사용할 공통 키를 안전하게 공유합니다.

이 모든 과정에서 패킷은 rt1에서 NAPT(IP 주소 변환)되고, fw1에서 방화벽 규칙에 따라 허용된 후 정적 NAT를 거쳐 lb1에 도달합니다.

AD_4nXfRaRdXeCBS4BjelMPiOG0Xgkr_pKyj8G_ERzT1O9g9C35QKiCRnW0bRsAApPoST34LAEtQ8SzURWOyPFcj9F6jWhJ1sYXycFQF6gsLgnIXLQusn-KvQkhFZaZC1QWp4NVJdnV1ig?key=52EUevA9e96nkndoBhk1Ig




AD_4nXfxCqME3QEAwGZbv6ywB420RX1n4lJTeETVomnxhWMdze0aPmgMHvjIDhqXqZsHGBM5fVFilw5zSjNV0aj0RAsJp7dP4BKAayRf_mcVH0uQvAarPN0sMzSSmua3I1e-YlKzFwdRkw?key=52EUevA9e96nkndoBhk1Ig





6단계: SSL 오프로드와 부하 분산

마침내 모든 사전 준비가 끝나고, cl1은 암호화된 HTTP 요청 메시지를 lb1으로 전송합니다. 여기서부터 서버 사이트의 핵심 기술인 SSL 오프로드와 부하 분산이 동작합니다.


[실전 사례 및 작동 방식]


실제 대규모 서비스에서는 웹 서버가 암호화/복호화라는 무거운 작업까지 처리하면 성능이 저하됩니다. 그래서 보통 앞단의 부하 분산 장치가 이 작업을 대신 처리하는데, 이를 SSL 오프로드라고 합니다.


1. SSL 오프로드: lb1은 cl1로부터 받은 암호화된 HTTPS 요청을 SSL 핸드셰이크 때 공유한 공통 키로 복호화하여 평범한 HTTP 요청으로 만듭니다.

2. 부하 분산: 이제 평문이 된 HTTP 요청을 lb1은 설정된 규칙(예: 라운드로빈)에 따라 뒤쪽에 있는 여러 웹 서버(sv1 또는 sv2) 중 한 곳으로 전달합니다. 이렇게 함으로써 한 서버에 트래픽이 몰리는 것을 방지하고 서비스의 안정성을 높입니다.

3. 응답: 요청을 받은 웹 서버(sv1이라 가정)는 처리 결과를 평범한 HTTP 응답으로 lb1에게 보냅니다.4. 재암호화 및 전송: lb1은 sv1으로부터 받은 HTTP 응답을 다시 공통 키로 암호화하여 HTTPS 응답으로 만들어 cl1에게 최종적으로 전달합니다

unnamed.png?type=w966





마치며


지금까지 우리가 무심코 웹사이트에 접속할 때 일어나는 복잡하고 정교한 과정을 단계별로 추적해 보았습니다. 이 모든 과정은 눈 깜짝할 사이에 일어나지만, 그 이면에는 수많은 네트워크 프로토콜과 기술들이 톱니바퀴처럼 맞물려 돌아가고 있습니다.


이론으로만 접하던 이 과정을 직접 내 PC에서 구축하고, Wireshark로 패킷 하나하나를 뜯어보며 눈으로 확인하는 경험은 네트워크에 대한 이해도를 완전히 다른 차원으로 끌어올려 줄 것입니다. 만약 이 글을 읽고 네트워크의 실제 동작 원리에 대한 흥미가 생기셨다면, 『도커로 구축한 랩에서 혼자 실습하며 배우는 네트워크 프로토콜 입문』을 통해 여러분만의 작은 인터넷을 직접 만들어 보시길 강력히 추천합니다.





이 책은 단순히 지식을 읽고 배우는 것이 아니라, 설정부터 패킷 분석까지 전 과정을 실제로 체험할 수 있는 네트워크 기술서입니다. 한 대의 PC 안에 스위치, 라우터, 방화벽, 로드 밸런서를 갖춘 가상 네트워크 환경을 구축하고, 각 장비에 로그인해 VLAN, 라우팅, 방화벽의 통신 제어, HTTPS 암호화, 로드 밸런싱 등을 모두 실제로 설정하고 동작을 확인할 수 있습니다. 이 책을 통해 네트워크 장비를 설정하고 패킷을 분석하면서 네트워크 검증 환경을 구축하다 보면 실제 구축 현장이나 운영 현장과 유사한 경험을 자연스럽게 쌓고 체험할 수 있을 것입니다.





keyword
작가의 이전글막막한 신입 엔지니어를 한 Docker 실습 가이드