[네트워크] 패킷이 이동하는 과정, 포장부터 개봉까지: 브라우저에 깃짱코딩.com을 입력하면 무슨 일이 일어나나요?

브라우저에 깃짱코딩.com을 입력하면 무슨 일이 일어나나요?

 

반응형

 

🌏 송신지에서 일어나는 일

✅ 1. 응용 계층: 사용자의 요청 생성

브라우저 주소창에 깃짱코딩.com을 입력했다고 가정해 봅시다.

1.1 DNS 요청 (= IP 주소 알아내기)

브라우저 주소창에 깃짱코딩.com을 입력하면, 먼저 DNS 캐시를 확인하고, 없는 경우 DNS 서버에 질의를 하는 식으로 흐름이 이어집니다.

1. 캐시 확인: 브라우저의 DNS 캐시, OS 캐시 확인
2. 호스트 파일 확인: /etc/hosts(리눅스/맥) 혹은 hosts 파일(윈도우)
3. 로컬 DNS 리졸버로 요청
   캐시나 hosts 파일 어디에도 없다면, 브라우저는 OS 네트워크 설정에 지정된 DNS 서버(로컬 리졸버)에 질의합니다.
   이 DNS 서버는 보통 인터넷 서비스 제공자(ISP)가 제공하기 때문에 단순히 OS가 알려주는 DNS 서버 주소로 바로 패킷을 내게 됩니다. 사용자가 직접 설정한 경우에는 구글 퍼블릭 DNS(8.8.8.8)나 클라우드플레어 DNS(1.1.1.1) 같은 곳으로 보낼 수도 있습니다.
   이때 실제 패킷 레벨에서는
   
   • 응용 계층: DNS 메시지 생성
   • 전송 계층: UDP 헤더 붙임 (출발지 포트=랜덤, 목적지 포트=53)
     • DNS는 짧고 단순한 요청/응답 구조라서 연결 설정이 필요 없는 UDP가 효율적이라 UDP 사용
   • 네트워크 계층: IP 헤더 붙임 (출발지=내 PC IP, 목적지=DNS 서버 IP)
   • 링크 계층: MAC 주소 붙여서 라우터로 전송
4. DNS 트리 탐색 by 로컬 리졸버
   
   • Root 서버 (맨 꼭대기)
     • “.com 도메인은 어디에 있어요?”
     • Root 서버는 최상위 도메인(TLD) 서버(.com, .net, .org 등)의 IP 주소를 알려줍니다.
   • TLD(Top-Level Domain) 서버
     • TLD 서버 = .com, .net, .org, .kr 같은 최상위 도메인을 담당
     • “깃짱코딩.com은 어디에 있어요?”
     • TLD 서버는 해당 도메인의 권한 있는 네임서버(Authoritative DNS) 주소를 알려줍니다.
   • 권한 있는 네임서버(Authoritative DNS)
     • Authoritative DNS = 특정 도메인에 대한 최종 정보 보관소
       • 깃짱코딩.com → 203.0.113.50 같은 실제 IP 주소를 직접 저장하고 응답
     • “깃짱코딩.com의 실제 IP 주소가 뭐예요?”
     • Authoritative 서버가 최종 IP 주소를 응답합니다.
5. 응답 반환 (= IP 주소 획득!)
   • 로컬 리졸버는 받은 IP 주소를 자기 메모리 캐시에 저장합니다.
     • 보통 DNS 응답에는 TTL이 있어서 이 캐시는 일정 시간 동안만 캐시 유효
   • 로컬 리졸버 → 내 PC로 응답을 전달합니다.
     • 내 PC의 OS DNS 캐시가 이 결과를 저장해, 다음부터는 빠르게 해당 사이트의 IP 주소를 알아낼 수 있습니다.
   • 내 PC의 브라우저는 이 IP 주소를 사용해 TCP 3-way handshake를 시작하고, 실제 HTTP 요청을 보냅니다.

DNS 트리 탐색

1.2 TCP 3-way handshake (= 연결 시작)

브라우저가 도메인의 IP를 DNS로 알아낸 후, TCP 3-way handshake를 통해 연결을 성립합니다. HTTP 요청을 미리 생성하더라도, 연결이 성립되지 않으면 전송할 수 없습니다.

TCP 3-way handshake도 결국 TCP 패킷(세그먼트)입니다만, 이때는 본격적인 응용 계층 데이터(HTTP 요청, 파일 데이터 등)가 실리지 않고, 헤더의 제어 정보만 채워져 있는 경량 패킷입니다. (페이로드 없음)

• SYN 패킷 (클라이언트 → 서버)
  • TCP 헤더 안에 SYN=1, ACK=0, SEQ=1000
    • SYN=1 의미 = 연결을 새로 시작하고 싶다
    • ACK=0 의미 = 아직 상대방의 ISN을 받은 게 없으니 확인할 게 없음
    • SEQ=1000 의미 = 클라이언트가 이번 연결을 위해 무작위로 정한 시작점으로, 이후 데이터 바이트를 보낼 때 이 숫자부터 하나씩 증가시킴.
    • Payload는 비어 있음
  • 이 패킷을 받은 서버는 TCP 헤더에서 SYN=1을 확인하면 새로운 연결 요청이라는걸 눈치채고 LISTEN 상태에서 SYN-RECEIVED 상태로 전이
• SYN+ACK 패킷 (서버 → 클라이언트)
  • TCP 헤더 안에 SYN=1, ACK=1, SEQ=3000, ACK=1001
    • SYN = 1 의미 = 서버도 이제 연결을 시작하겠다
      • 동시에 내 ISN(Initial Sequence Number)을 시퀀스 번호 필드에 싣는다
    • ACK = 1 의미 = 클라이언트가 보낸 SYN 잘 받았음
      • 이게 켜져 있어야 클라이언트에게 시퀀스 번호를 확인했다는 걸 알린다
    • SEQ = 3000 의미 = 서버가 이번 연결을 위해 새로 정한 자기 ISN(초기 시퀀스 번호)로, 이후 서버가 데이터를 보낼 때는 3000부터 시작해 바이트 단위로 증가함
    • ACK = 1001 의미 = 클라이언트가 보낸 ISN=1000을 받았으니, 이제 다음 번호 1001부터 보내달라
      • 1001은 클라이언트가 보낸 시퀀스 번호 + 1
• ACK 패킷 (클라이언트 → 서버)
  • TCP 헤더 안에 SYN=0, ACK=1, SEQ=1001, ACK=3001
    • SYN=0 의미 = 이제 더 이상 새 연결을 시작하는 건 아님 (데이터 교환 단계로 진입)
    • ACK=1 의미 = 서버가 보낸 SYN을 잘 받았다 (서버 ISN 확인 완료)
    • SEQ=1001 의미 = 클라이언트 ISN(1000)에서 +1
      • 이제부터 1001부터 실제 데이터 전송 시작
    • ACK=3001 의미 = 서버가 보낸 ISN=3000을 잘 받았으니, 이제 다음 번호 3001부터 보내달라
  • 이 패킷을 받은 서버는 TCP 헤더에서 ACK=1을 확인하고, ESTABLISHED 상태로 전이 → 이제 양쪽 모두 연결이 성립되어 데이터 전송 가능

1.3 HTTP 요청 생성

• IP 주소를 알게 되면, 브라우저는 HTTP 요청을 생성합니다.
• 요청 데이터(payload): HTML 페이지 요청

즉, 응용 계층은 우리가 실제로 보내고 싶은 "내용물"을 만들고, 이건 실제 패킷의 Payload가 됩니다.

 

브라우저가 만드는 실제 요청 메시지 = 페이로드

GET / HTTP/1.1
Host: 깃짱코딩.com
User-Agent: Chrome/128.0
Accept: text/html
Connection: keep-alive

✅ 2. 전송 계층: 포트 번호와 제어 정보 추가

응용 계층에서 만들어진 데이터(예: HTTP 요청, DNS 쿼리)가 바로 네트워크로 흘러가지 않습니다. 전송 계층(Transport Layer) 에서 “이 데이터가 정확히 어떤 프로그램으로 가야 하는지, 어떻게 순서를 보장하고, 오류가 나면 어떻게 복구할지”를 정의해 주어야 합니다.

생성된 데이터(payload)는 전송 계층으로 내려갑니다.

• DNS 요청은 UDP를 사용 (보통 53번 포트)
• HTTP 요청은 TCP를 사용 (보통 80번 HTTP / 443번 HTTPS 포트)

전송 계층은 “어느 애플리케이션으로 가야 하는지”를 구분하기 위해 포트 번호를 붙이고,
신뢰성 보장을 위해 시퀀스 번호, ACK 같은 정보를 넣습니다. (이건 TCP의 경우만)

 

 

TCP를 예시로 보면,

• 출발지 포트(Source Port)
  • 내 PC에서 요청을 보낸 애플리케이션을 식별하기 위해 사용합니다.
  • 브라우저가 HTTP 요청을 보낼 때는 보통 49152~65535 범위의 임시 포트(에페메럴 포트) 를 할당받습니다.
• 목적지 포트(Destination Port)
  • 목적지 서버의 어떤 서비스에 접속할 것인지 지정합니다.
  • 예
    • 80번: HTTP
    • 443번: HTTPS
    • 53번: DNS
• 제어 정보
  • 시퀀스 번호(Sequence Number)
    • 송신 측에서 보낸 데이터 바이트 스트림의 순서를 나타냅니다.
    • 네트워크는 패킷이 순서대로 도착한다는 보장이 없기 때문에, 수신 측은 시퀀스 번호를 보고 원래 순서대로 조립할 수 있습니다.
  • ACK(Acknowledgment Number)
    • 수신 측이 “어디까지 잘 받았는지” 송신 측에 알려주는 번호입니다.
      • 처음 보낼 때는 의미가 없고 연결 절차나 실제 수신 이후부터 유효하게 채워집니다.
    • 예: 시퀀스 번호 1001~1500까지 받았다면, ACK=1501을 보냅니다.
  • TCP Flags
    • SYN: 연결 시작(3-way handshake에서 사용)
    • ACK: 데이터 수신 확인
    • FIN: 연결 종료 요청
    • RST: 비정상 연결 강제 종료
    • PSH: 데이터를 즉시 전달하도록 지시
    • URG: 긴급 데이터 존재
  • TCP는 단순 데이터 전달뿐 아니라, 연결을 관리하는 여러 제어 플래그를 사용합니다.

✅ 3. 인터넷 계층: IP 주소 붙이기

인터넷 계층은 “이 패킷이 어디서 어디로 가야 하는가”를 지정합니다. 전송 계층에서 만들어진 TCP 세그먼트 또는 UDP 데이터그램을 받아, 네트워크 상에서 출발지 → 목적지 까지 정확히 전달하는 것이 목적입니다. 즉, IP 주소 기반의 논리적 주소 지정 + 라우팅을 담당합니다.

이 단계에서는 전송 계층에서 포장된 TCP 세그먼트에 IP 헤더가 추가됩니다.

IPv4 헤더 주요 필드 (20바이트 고정 + 옵션 최대 40바이트)

1. 출발지 IP (Source IP)
   • 패킷을 보낸 내 컴퓨터의 논리적 주소
   • 예: 192.168.0.10 (사설 IP), 203.0.113.50 (공인 IP)
2. 목적지 IP (Destination IP)
   • 패킷을 받아야 하는 상대방의 논리적 주소
   • 예: 203.0.113.50 (깃짱코딩 웹 서버)
3. TTL (Time To Live)
   • 패킷이 네트워크에서 무한 루프에 빠지지 않도록 최대 홉 수를 제한
   • TTL 값은 라우터를 지날 때마다 1씩 줄어들고, 0이 되면 목적지에 도달하지 못했더라도 해당 패킷은 폐기됩니다.
   • 기본값: 64, 128, 255 등 운영체제별로 다름
4. 프로토콜 번호 (Protocol)
   • IP 패킷 안에 어떤 상위 계층 데이터가 들어있는지 알려줌
   • 예: 6 = TCP, 17 = UDP, 1 = ICMP
5. 버전 (Version)
   • IPv4인지 IPv6인지 표시 (IPv4 = 4, IPv6 = 6)
6. 헤더 길이 (IHL, Internet Header Length)
   • IP 헤더가 몇 바이트인지 지정 (IPv4 기본값 = 20바이트)
7. 전체 길이 (Total Length)
   • 헤더 + 데이터(payload) 전체 크기 (최대 65,535바이트)
8. 식별자, 플래그, 프래그먼트 오프셋
   • 패킷이 너무 크면 쪼개서(fragmentation) 보낼 수 있는데, 이때 조각들을 재조립하기 위해 사용
9. 헤더 체크섬 (Header Checksum)
   • IP 헤더 자체의 오류 검출용 값

✅ 4. 링크 계층: 물리 네트워크에 맞는 주소 붙이기

IP 계층까지 끝나면, 패킷은 "출발지/목적지 IP"라는 논리적 주소를 가지게 됩니다. 하지만 네트워크 카드(NIC)는 물리적인 주소(MAC 주소) 를 기반으로 동작합니다. 따라서 실제 전송 직전, MAC 주소를 담은 링크 계층 헤더가 추가되어야 합니다. 이 과정을 흔히 “프레임(Frame)으로 캡슐화한다”라고 부릅니다.

• MAC 주소란?
  • NIC(Network Interface Card, 네트워크 카드)가 출고될 때 제조사에서 박아 넣은 48비트 고유 식별자
  • 예: 00:1A:2B:3C:4D:5E
  • 이더넷, 와이파이 모두 기본 단위는 MAC 주소 기반 통신

링크 계층 헤더 주요 필드

1. 출발지 MAC 주소 (Source MAC)
   • 내 PC의 NIC 고유 주소
   • "이 프레임은 내가 보낸 거다"라는 표시
2. 목적지 MAC 주소 (Destination MAC)
   • 보통은 내 PC가 직접 붙은 게이트웨이(라우터)의 MAC 주소
   • 왜냐면 목적지가 인터넷 어딘가라면, 일단 라우터를 통해야 하니까
   • 만약 목적지가 같은 LAN 안에 있는 경우라면 상대방 기기의 MAC 주소
3. 타입 (EtherType)
   • 이 프레임 안에 들어있는 상위 계층 프로토콜이 뭔지 표시
   • 예: 0x0800 = IPv4, 0x86DD = IPv6, 0x0806 = ARP

✅ 5. 네트워크를 통한 전달

이제 완성된 프레임이 네트워크를 타고 흘러갑니다. 이때 패킷의 IP 주소는 유지되지만, MAC 주소는 라우터를 지나갈 때마다 새롭게 바뀝니다.

내 PC ⇒ 공유기/라우터

내 PC 에서 출발합니다.

• 출발지 MAC = 내 PC NIC
• 목적지 MAC = 공유기(게이트웨이) MAC
• 출발지 IP = 내 PC IP
• 목적지 IP = 깃짱코딩 서버 IP

공유기가 받으면 링크 계층 헤더(MAC 주소)만 벗기고, IP 헤더부터는 그대로 두게 됩니다.

공유기 ⇒ ISP 라우터

공유기는 IP 헤더를 보고 이 패킷은 깃짱코딩 서버로 가야 한다고 판단하고, 다음 홉(Next Hop, ISP 라우터)의 MAC 주소를 ARP로 알아냅니다. (이건 다른 포스팅에서 자세히 다루겠습니다)

패킷은 이제 새 Ethernet 헤더를 입혀서 다시 보내집니다. (IP 헤더는 그대로 유지)

• 출발지 MAC = 공유기 MAC
• 목적지 MAC = ISP 라우터 MAC
• 출발지 IP = 내 PC IP
• 목적지 IP = 깃짱코딩 서버 IP

*여기서 ISP 라우터는 사실 하나의 장비가 아니라, 통신사(Internet Service Provider)가 운영하는 여러 라우터들로, ‘공유기 다음부터 만나는 통신사 네트워크 장비들’을 모두 포함합니다.

ISP Backbone을 통과 (여러 라우터 경유)

각 라우터는 IP 헤더는 건드리지 않고, 자신과 다음 홉 사이의 링크 계층 헤더만 다시 씌웁니다. 즉, 라우터마다 "MAC 주소 쌍"만 계속 바뀌는 구조로 IP 주소는 출발지/목적지 그대로 유지됩니다.

목적지 서버에 도착

마지막 라우터가 서버 네트워크 카드(NIC)까지 전달합니다. 목적지 서버에 도달하기 직전의 패킷 상태입니다.

• 출발지 MAC = 마지막 라우터 MAC
• 목적지 MAC = 깃짱코딩 서버 NIC MAC
• 출발지 IP = 내 PC IP
• 목적지 IP = 깃짱코딩 서버 IP

이 과정에서 라우팅 테이블과 ARP(Address Resolution Protocol)가 사용됩니다.

• ARP: IP 주소에 대응하는 MAC 주소를 찾음
• 라우팅: 최적 경로를 따라 목적지로 전달

🌏 수신지에서 일어나는 일

✅ 1. 포장 해체 (역캡슐화)

목적지 서버(깃짱코딩 서버)에 도착하면, 역순으로 헤더를 벗깁니다.

1. 링크 계층
   • MAC 주소 확인 (내 서버 맞는지 확인)
   • Ethernet 헤더 제거 후 IP 계층으로 전달
2. 인터넷 계층 (IP)
   • 목적지 IP 확인 (내 서버 맞는지 확인)
   • TTL 감소 및 유효성 체크
   • IP 헤더 제거 후 TCP 계층으로 전달
3. 전송 계층 (TCP)
   • 목적지 포트 확인
   • 시퀀스 번호/ACK 확인 (데이터 순서와 신뢰성 보장)
   • TCP 헤더 제거 후 응용 계층으로 전달
4. 응용 계층 (HTTP 서버)
   • 웹 서버(Nginx, Apache, Spring Boot 등)가 요청을 해석
   • GET / HTTP/1.1 요청에 대해 HTML 페이지를 응답

✅ 2. 응답 생성

깃짱코딩 서버는 HTML 데이터를 다시 포장합니다.

• 응용 계층: HTML 페이지
• 전송 계층: TCP 헤더 붙임 (포트 80 → 출발지, 50000번대 → 목적지)
• 인터넷 계층: 서버 IP → 출발지 IP
• 링크 계층: 서버 MAC → 라우터 MAC

그리고 역방향으로 클라이언트에게 전달됩니다. 그러면 이제까지 길게 설명한 부분을 역방향으로 똑같이 진행하게 됩니다.

클라이언트 브라우저는 응답을 받으면 다시 헤더를 하나씩 벗기고, 최종적으로 HTML 내용을 화면에 렌더링합니다.

 

 

 

 

도움이 되었다면, 공감/댓글을 달아주면 깃짱에게 큰 힘이 됩니다!🌟
비밀댓글과 메일을 통해 오는 개인적인 질문은 받지 않고 있습니다. 꼭 공개댓글로 남겨주세요!