ABOUT ME

    -

    Today
    -
    Yesterday
    -
    Total
    -
    • [웹 통신 과정 해부하기] 네트워크 접속부터 브라우저 렌더링까지
      NetWork 2024. 3. 31. 16:50

       

      들어가며

       클라이언트가 네트워크에 연결된 후 브라우저에서 특정 도메인을 검색하고, 그 결과 렌더링된 페이지가 보여지기까지의 과정을 자세히 살펴보겠습니다. 이 글에서는 '클라이언트의 관점'에서 웹 서버에 접속하기 위해 필요한 핵심 요소들에 집중합니다. 따라서 클라이언트의 웹 서버 최초 접속 이후 서버가 클라이언트의 상태를 유지하거나 식별하기 위해 사용하는 세션, 쿠키, 토큰과 같은 기술에 대해서는 다루지 않습니다. 목차는 아래와 같습니다.

       

       

      목차

      1. ISP 네트워크에 접속

      2. IP 할당

      3. 서버 IP 변환

      4. 서버와의 연결 구축

      5. HTTP(S) Request 메세지 생성 및 송신

      6. HTTP(S) Response 메세지 수신

      7. 브라우저 렌더링

      8. 마무리

      9. Reference

       

       

      1. ISP 네트워크에 접속

      'NIC'를 통해 외부 네트워크와 연결되다..★

       서버와 통신하기 위한 첫 번째 단계로 ISP 네트워크에 접속해야합니다. ISP(Internet Service Provider)는 인터넷을 이용할 수 있는 서비스를 제공합니다. 우리가 잘 알고 있는 KT, SK 브로드밴드, LG 유플러스 등이 바로 ISP입니다. ISP 네트워크는 인터넷에 접속하기 위한 관문이며, 컴퓨터의 입장에서 ISP 네트워크로 접속하기 위한 첫 번째 진입점은 NIC(Network Interface Card)입니다. Network Interface라는 명칭에서도 알 수 있듯이, NIC는 컴퓨터와 외부 네트워크를 연결해주는 인터페이스 역할을 합니다.

       

       데스크탑 등의 유선 기기는 figure 1-1과 같이 NIC와 연결된 이더넷 케이블을 통해 스위치, 라우터, 모뎀을 거쳐 ISP 네트워크에 접속합니다. 노트북 등의 무선 기기의 경우 figure 1-2와 같이 NIC와 연결된 AP(Access Point)를 통해 라우터, 모뎀을 거쳐 ISP 네트워크에 접속합니다. AP는 와이파이 표준(IEEE 802.11)을 기반으로 무선 장치를 유선 네트워크에 연결시켜주는 중계장치인데, 요즘에는 공유기가 다양한 기능을 제공하고 있어 AP, 스위치, 라우터의 역할을 포함하기도 합니다.

       

      figure 1-1. 유선 기기의 네트워크 연결
      figure 1-2. 무선 기기의 네트워크 연결

       노트북과 같은 무선 장치가 AP를 탐색하는 방법에는 패시브 스캐닝(Passive Scanning), 액티브 스캐닝(Active Scanning) 두 가지 방식이 있습니다. 패시브 스캐닝 방식을 사용한다면, 무선 장치는 figure 1-3과 같이 AP들이 비콘(Beacon)으로 브로드캐스트한 신호를 포착하여 AP 목록을 구성하고 그 중 원하는 AP를 선택해 접속을 요청합니다. 브로드캐스트된 신호에는 네트워크 주소(SSID), MAC 주소, 보안 설정 등의 정보가 포함되어 있습니다.

       

       액티브 스캐닝 방식을 사용한다면 무선 장치가 직접 AP들에게 프로브 요청(Probe Request)을 보내고, AP들로부터 프로브 응답(Probe Response)을 받습니다. 무선 장치는 응답받은 AP들의 네트워크 정보를 확인 후 원하는 AP에게 접속을 요청합니다. 이렇게 패시브 스캐닝 또는 액티브 스캐닝을 통해 AP 탐색 후 원하는 AP에 접속 요청을 하면 해당 AP가 연결 요청을 수신하고 보안 인증 절차를 거친 후 연결을 승인함으로써 무선 연결이 완료됩니다.

      figure 1-3. Passive Scanning으로 수집한 AP 목록 및 각 AP의 정보들

       

       

      2. IP 할당

      네트워킹의 필수 조건: IP 주소

       인터넷 기반의 웹 통신을 하기 위해서는 반드시 IP 주소가 필요합니다. IP는 Internet Protocol의 약자로 인터넷 통신 규약을 의미합니다. 즉, IP 주소는 인터넷 상에서 특정 장치를 식별하기 위한 주소로, 데이터 패킷을 원하는 목적지로 라우팅하기 위해 사용됩니다. IP 주소를 할당받기 위한 방법에는 고정 할당 방식과 동적 할당 방식이 있습니다.

       

      IP 고정 할당

       고정 할당은 말 그대로 고정된 IP를 사용할 수 있는 방식인데 figure 2-1과 같이 직접 IP 주소, 서브넷 마스크, 기본 게이트웨이, DNS 서버 주소를 지정해줘야 합니다. 예시에서 사용된 DNS 서버 주소 8.8.8.8은 구글이 제공하는 공개 DNS 서버 주소입니다. DNS는 후술하겠지만 도메인 이름을 IP로 변환해주는 응용 계층 프로토콜입니다. 가정집에서는 보통 ISP가 제공하는 DNS 서버를 사용하는데, 해외에 서버를 둔 서비스를 주로 이용한다면 클라우드플레어나 구글의 DNS를 이용하는 것이 훨씬 응답속도가 빠릅니다.

       

      figure 2-1. Windows에서 고정 IP 설정하기

       아래는 주요 서비스 제공자별 DNS 서버 특징을 정리한 표입니다. 보안과 속도, 자주 이용하는 서비스를 고려해서 가장 적합한 DNS서버를 선택하면 됩니다. 또는 웹 브라우징 히스토리 등을 분석해 최적화된 DNS 서버를 추천해주는 DNSPerf, DNS Jumper, Cloudflare ESNI Checker와 같은 서비스를 이용하는 방법도 있습니다. 

       

      Service Provider DNS Address Features
      Cloudflare & APNIC 기본 1.1.1.1 
      보조 1.0.0.1      		 - 가장 빠른 속도의 서비스 제공
      - 개인 정보 보호를 위해 24시간 내 DNS 쿼리 로그 삭제
      - 비 상업성
      Google 기본 8.8.8.8
      보조 8.8.4.4      		 - 서비스 고가용성 및 우수한 속도
      - 구글의 서비스 사용 시 가장 빠름
      IBM Quad9  기본 9.9.9.9 - 악성 도메인 차단 등 보안 우수
      - 개인 정보 보호를 위해 DNS 쿼리 정보 미수집
      OpenDNS 기본 208.67.222.222
      보조 208.67.220.220      		 - 보안을 위해 부적절한 콘텐츠 차단을 위한 필터링 옵션 제공
      KT 기본 168.126.63.1
      보조 168.126.63.2      		 - 국내 네트워크 최적화 및 고가용성 서비스
      - 우수한 속도

       

      IP 동적 할당

       한편, 동적 할당은 DCHP(Dynamic Host Configuration Protocol)를 통해서 이루어집니다. DHCP 서버는 다음과 같은 과정을 통해 클라이언트가 사용할 IP 주소, DNS 서버 주소, 서브넷 마스크, 기본 게이트웨이 정보를 할당합니다. 이 과정은 UDP 프로토콜을 기반으로 합니다.

       

       제일 먼저 클라이언트는 DHCP 서버를 찾기 위해 DISCOVER 메세지를 담은 프레임을 브로드캐스트합니다. 이 프레임의 발신지(src, source)는 아직 할당받지 못 한 IP와 DHCP 클라이언트 포트를 의미하는 0.0.0.0:68이며, yiadd(Your(Client) IP Address) 역시 0.0.0.0입니다. 목적지(dest, destination)는 브로드캐스트 주소와 DHCP 서버 포트를 의미하는 255.255.255.255:67입니다.

       

       DISCOVER를 받은 DHCP 서버는 IP 주소를 할당해서 클라이언트에게 OFFER 메세지를 담은 프레임을 보냅니다. 이 프레임에는 IP 주소, 서브넷 마스크, 리스 시간, 게이트웨이 IP 주소, DNS 서버 주소 등이 포함되어있습니다. 할당한 클라이언트의 IP는 yiadd 필드에 있습니다. 클라이언트는 이 제안을 받아들이거나 거절할 수 있습니다.

       

       클라이언트가 할당받은 IP를 사용하기로 선택한다면 해당 주소 할당을 정식으로 요청한다는 의미에서 REQUEST 메세지를 담은 프레임을 보냅니다. 이 때 IP 할당이 아직 완료되지 않은 상태이므로 src의 IP는 0.0.0.0입니다.

       

       DHCP 서버가 REQUEST를 받고 최종적으로 이를 수락한다면 클라이언트에게 ACK 메세지를 담은 프레임을 보냄으로써 IP 할당이 완료됩니다. 클라이언트는 해당 프레임에서 ACK 메세지를 추출하고 할당받은 자신의 IP와 DNS 서버 주소, 서브넷 마스크, 기본 게이트웨이 정보 등을 저장합니다. 만약 지정된 리스 시간이 만료되면 재갱신을 요청하거나 새로운 IP 주소를 요청해야 합니다.

       

      figure 2-2. DHCP를 통한 IP 동적 할당 과정

       

       

      3. 서버 IP 변환

      DNS 曰: "넌 도메인 이름만 기억해. IP는 내가 변환해줄게 🤗"

       이제 브라우저(클라이언트)에서 www.google.com과 같이 사이트(서버)의 도메인 이름을 입력합니다. 그런데 앞서 웹 통신을 하려면 IP 주소가 필요하다고 했습니다. 하지만 우리는 사이트의 도메인 이름만 알고 있어도 괜찮습니다. 기억하기 어려운 IP 주소 대신 도메인 이름을 입력하기만 하면 DNS(Domain Name Service)가 IP 주소를 매핑해줄 것이기 때문입니다. 사이트가 도메인을 구입하면 인터넷의 다양한 DNS 서버에 등록되고, 브라우저의 도메인 → IP 변환 요청이 있을 때 DNS 서버가 해당 도메인 이름을 IP 주소로 해석해주는 구조입니다.

       

       하지만 실제로 브라우저에서 도메인 이름을 IP로 해석하는 과정은 바로 DNS 서버에서 일어나지 않습니다. 'hosts 파일 참조' → 'LDNS(Local DNS) 캐시 참조' → 'DNS 서버에 질의'하는 순서로 최적화되어 있습니다. 즉, 네트워크 트래픽과 DNS 서버의 부하를 줄이기 위해 로컬 컴퓨터 OS 내부 hosts 파일을 제일 먼저 조회하고, hosts 파일에 정보가 없다면 LDNS 캐시를 조회합니다. 클라이언트의 로컬 네트워크 또는 ISP에 위치한 LDNS 서버는 DNS 쿼리 결과를 일정 기간 동안 캐싱합니다. 만약 LDNS 캐시도 없다면 LDNS가 다른 DNS 서버들에 쿼리를 하게 됩니다.

       

       LDNS 캐시가 없는 경우 LDNS는 먼저 Root DNS에게 도메인에 대한 IP 주소를 요청합니다. Root DNS 서버는 ICANN(Internet Corporation for Assigned Names and Numbers)에서 관리하는 메인 서버로, 변환 요청이 들어온 도메인에 따라 적합한 TLD DNS 서버들을 안내해줍니다. TLD는 Top Level Domain의 약자로 최상위 도메인을 의미하며, www.google.com에서 .com에 해당됩니다. 이 경우 Root DNS는 com TLD를 반환합니다. LDNS는 Root DNS 서버가 알려준 com TLD 서버에 DNS 쿼리를 합니다.

       

       com TLD 서버는 2차 도메인(Second-Level Domain)인 google을 보고 해당 도메인의 권한을 가진 네임 서버(Authoritative Name Server)를 리턴해줍니다. LDNS는 TLD 서버가 알려준 구글의 네임 서버에 구체적인 DNS 레코드 정보(A 레코드, CNAME 레코드 등)에 대한 쿼리를 합니다. 구글의 네임 서버는 최하위 도메인(Sub Domain) 또는 호스트를 의미하는 www.를 보고 해당 서비스에 대응하는 웹 서버 IP 주소를 LDNS에게 전달해줍니다. 

       

       LDNS가 DNS 쿼리를 하는 과정을 일반화하여 정리해보면 다음과 같습니다. 우선, 도메인 이름은 figure 3-1과 같이 '최하위 도메인(호스트명)', '2차 도메인', '최상위 도메인'의 조합입니다. LDNS가 Root DNS 서버에 쿼리를 하면 Root DNS는 TLD DNS 서버를 반환해주고, LDNS 서버는 TLD DNS 서버에게 다시 쿼리를 합니다. TLD DNS 서버는 2차 도메인을 보고 Authoritative 네임 서버를 반환해주고, LDNS 서버가 다시 Authoritative 네임 서버에 쿼리를 하면 Authoritative 네임 서버는 최하위 도메인이 의미하는 서비스에 대한 IP 주소를 LDNS에게 전달합니다. DNS 레코드 정보에 대한 내용은 추후 포스팅할 예정입니다. 

       

      figure 3-1. 도메인 이름의 구성

       

       

       

      4. 서버와의 연결 구축

      서버와 본격적으로 데이터를 주고받기 전, Handshake 먼저

       이 글에서는 TCP 기반의 HTTP/2 이하 버전을 기준으로 설명하겠습니다. 웹에서 서버와 HTTP 통신을 하려면 TCP 소켓을 생성하고 TCP 3-way Handshake 과정을 거쳐 서버와의 연결을 구축해야 합니다. 참고로 HTTP/3는 HTTPS를 보완하기 위해 개발되어, TLS 1.3으로 모든 데이터를 암호화해서 송수신하기 때문에 기본적으로 HTTPS입니다. 또, UDP 기반 'QUIC' 프로토콜 위에서 작동하기 때문에 서버와의 연결 수립에 대한 메커니즘이 HTTP/2 이하 버전과 상이합니다. QUIC은 TCP의 신뢰성과 연결지향적 특성을 유지하되, UDP의 간결함과 효율성을 활용합니다.

      figure 4-1. HTTP/2와 HTTP/3 비교(좌: https://aws.amazon.com/ko/blogs/aws/new-http-3-support-for-amazon-cloudfront/, 우: https://web.eecs.umich.edu/~xumiao/docs/imc23-quic-poster.pdf)

       

       한편, HTTP/3는 보안과 속도 측면의 이점으로 인해 점유율이 폭발적으로 증가하고 있습니다. 웹 성능 및 사용량에 대한 대규모 데이터를 수집·분석하는 HTTP Archive가 조사한 바에 따르면 HTTP/3을 지원하는 서비스가 figure4-2와 같이 2024년 1월 기준 웹 25.5%, 모바일 27.1%를 차지합니다. 이는 2020년 4월 기준 웹, 모바일 각각 25,400%,  3,771.4% 상승한 수치입니다. HTTP/3과 QUIC 프로토콜에 대해서는 이정도로만 정리하고 추후 자세히 포스팅하겠습니다.

       

      figure 4-2. HTTP/3 지원 서비스 추이(출처: https://httparchive.org/reports/state-of-the-web#h3)

       

      HTTP 통신을 위한 연결 수립: 3-way Handshake

       HTTP 통신 시 TCP 3-way Handshake는 클라이언트가 서버로 커넥션 요청을 할 때 시작됩니다. HTTP 서버는 80 포트를 사용합니다. 첫 번째로 클라이언트가 서버로 SYN 패킷을 보내 연결을 요청합니다(1-way). 서버에서 클라이언트의 요청을 받고 연결에 동의한다면 클라이언트에게 SYN+ACK 세그먼트를 보냅니다(2-way). SYN+ACK를 받은 클라이언트는 ESTABLISHED 상태가 되고 이에 대한 알림으로 서버에게 ACK 세그먼트를 보냅니다(3-way). ACK를 받은 서버 역시 ESTABLISHED 상태가 되면서 TCP 연결이 수립됩니다. 드디어 서버와 클라이언트 사이에 데이터를 주고받을 준비가 된 것입니다.

      figure 4-3. TCP 3-way Handshake

       

      HTTPS 통신을 위한 연결 수립: 3-way Handshake + SSL/TLS Handshake

       만약 보안이 적용된 HTTPS 통신을 하고싶다면 SSL/TLS Handshake 과정을 추가로 거쳐야 합니다. HTTPS 서버는 443 포트를 사용합니다. SSL/TLS Handshake을 함축적으로 정의하자면 '서버가 믿을만한 대상인지 판별 후 데이터를 암호화하기 위한 사전 준비 과정'입니다. figure 4-4의 (b) Encrypted HTTPS transaction을 보시면 ① TCP 3-way Handshake 이후 ② SSL/TLS Handshake를 거쳐 서버와 암호화된 데이터를 주고받습니다. SSL/TLS Handshake 과정에 관한 자세한 정보는 [HTTPS] SSL/TLS Handshake란?을 참고해주세요!

       

      figure 4-4. HTTP와 HTTPS 비교(출처: HTTP The Definitive Guide)

      💡 'SSL/TLS'라는 명칭에 대해서
       참고로 HTTPS는 figure 4-5와 같이 SSL/TLS Record Layer 위에서 동작하는 HTTP라고 할 수 있습니다. SSL(Secure Sockets Layer)과 TLS(Transport Layer Security)란 인터넷 보안 프로토콜로서, SSL 3.0의 후속 버전이 TLS 1.0입니다. 현재로서는 TLS가 표준이지만 업계에서는 TLS 인증서를 가리킬 때에도 SSL이라는 용어를 지속적으로 사용하고 있으며, 암호화 프로토콜(Cryptographic Protocol) 자체를 "SSL/TLS"라고 지칭하기도 합니다(SSL과 TLS에 대한 더 자세한 내용).

       

      figure 4-5. Application Layer 상세( TCP/IP Updated model 기준)
      figure 4-6. OSI 7 Layer vs TCP/IP Original vs TCP/IP Updated

       

       

       

      5. HTTP(S) Request 메세지 생성 및 송신

       HTTP 요청을 위해 HTTP 메세지를 생성합니다. 지금은 단순히 사이트의 웹 페이지를 요청하고 있으므로 HTTP Method는 GET입니다. HTTP GET 메세지는 Request Line, Headers로 구성됩니다. POST나 PUT 요청의 경우에는 Body도 포함됩니다. Headers의 'Accept' 필드에는 브라우저가 수용 가능한 Body 데이터의 MIME(Multipurpose Internet Mail Extentions) 타입을 지정합니다. 이는 서버가 응답해주어야할 Body의 컨텐츠 유형을 미리 알려주는 역할을 합니다. 즉, Response Headers의 'Content-Type' 필드에 대해 명시할 수 있는 값을 말합니다. 

       

      figure 5-1. HTTP GET Request Headers

       

       예를 들어 Accept 필드 값이 'text/html'라면 브라우저는 HTML 문서만, 'application/json'라면 JSON 형식의 데이터만, 'image/png'라면 PNG 형식의 이미지 파일만 수용할 것임을 나타냅니다. figure 5-1과 같이 '*/*'라면 모든 컨텐츠 타입을 수용한다는 의미입니다. 'text/html; charset=UTF-8'과 같이 ';'를 구분자로 인코딩 타입 정보를 추가하기도 합니다. Accept 외에도 많은 필드가 있지만 생략하겠습니다. HTTPS 통신을 한다면 여기에 메세지를 암호화하는 과정이 추가됩니다. 

       

       브라우저가 속한 Application 계층에서 HTTP GET 요청을 통해 생성된 데이터는 Transport 계층, Network 계층, Data Link 계층을 거치며 캡슐화되어 Physical 계층에 도착합니다(TCP/IP Updated 모델 기준, figure 4-6 참고). Application 계층에서 Physical 계층까지 이동하는 과정은 데이터를 받아 자신의 헤더를 추가하고 인코딩하여 하위 계층으로 데이터를 전달하는 과정의 반복입니다.

       

       조금 더 자세히 설명하자면 Application 계층의 데이터는 OS 네트워크 스택에 의해 Transport 계층에서 TCP 헤더(HTTP/3인 경우 UDP 헤더)가 추가되어 세그먼트화 됩니다. 세그먼트(HTTP/3인 경우 데이터그램) 역시 OS에 의해 Network 계층에서 IP 헤더가 추가되어 패킷화 됩니다. IP 헤더에는 출발지와 목적지 IP 주소 등의 정보가 포함되어 패킷이 목적지까지 라우팅될 수 있도록 합니다. Data Link 계층이 LAN을 사용하는 경우 패킷은 이더넷 헤더가 추가되어 프레임화 됩니다. 이더넷 헤더에는 MAC 주소와 에러 체크를 위한 정보가 포함됩니다. 

       

       마지막 Physial 계층에서는 PHY(Physical Layer Transceiver)칩이 바이너리로 구성된 프레임을 전기 신호로 변환하여 LAN을 통해 전송합니다. 반면, WLAN 환경에서는 데이터를 무선 전자기파로 변환하여 공간을 통해 전송하고, 광섬유 네트워크 환경에서는 데이터를 빛의 신호로 변환하여 광섬유 케이블을 통해 전달합니다.

       

       

       

      6. HTTP(S) Response 메세지 수신

       서버가 보내온 Response 메세지는 요청 시와 반대로 Physical 계층, Data Link 계층, Network 계층, Transport 계층을 거치면서 디캡슐화되어 Application 계층에 도착합니다. 수신한 데이터를 디코딩 후 헤더를 제거하여 페이로드만 상위계층으로 올려보냅니다. Physical 계층은 전기 신호, 무선 신호, 빛 등의 형태의 데이터를 받아 원래의 바이너리 데이터로 복원하여 Data Link 계층으로 전달합니다.

       

       Data Link 계층은 이더넷 헤더를 분석하여 목적지 MAC 주소가 현재 장치의 MAC 주소와 일치하는지 확인합니다. 일치할 경우 프레임에서 패킷을 추출하며 전송 중 오류 등의 에러 검출을 수행하여 Network 계층으로 올려보냅니다. Network 계층은 패킷의 IP 헤더를 분석하여 정확한 목적지 IP 주소로 라우팅합니다. 패킷이 목적지 IP에 도착하면 패킷 내의 세그먼트(cf. UDP 기반일 경우 데이터그램)를 추출하여 Transport 계층으로 올려보냅니다.

       

       Transport 계층에서는 TCP 또는 UDP 헤더를 분석하여 해당 데이터가 어떤 Application 프로토콜에 의해 처리되어야하는지 port번호를 보고 결정합니다. 또한 데이터 종단 간 전송을 책임지며, 세션 관리와 오류 검사 및 흐름 제어 등을 수행합니다. Application 계층에서는 Transport 계층으로부터 전달받은 데이터를 처리합니다.

       

       서버의 Response 데이터는 Status Line, Headers, Body로 구성됩니다. figure 6-1를 보시면 'Status Code'값은 200입니다. 200은 서버가 브라우저의 Request를 정상 처리했음을 의미합니다. Headers의 'Content-Type'값은 'application/json charset=UTF-8'이므로 Body의 컨텐츠가  UTF-8로 인코딩된 JSON 형태임을 알 수 있습니다. 저의 브라우저는 모든 컨텐츠 타입을 수용할 수 있으므로  5. HTTP(S) Request에서 Headers의 'Accept' 값을 '*/*'로 보낸 바 있습니다. 따라서 Body에서 JSON 데이터를 정상적으로 추출하게 됩니다. 

       

      figure 6-1. HTTP GET Response Headers

       추가적으로 Status Code에 대해서 조금 더 자세히 살펴보겠습니다. 100번대는 정보 제공, 200번대는 성공, 300번대는 리다이렉션, 400번대는 클라이언트 에러, 500번대는 서버 에러입니다. 아래 표는 자주 사용되는 상태코드들입니다. 

       

      Status Code Status Text Meaning
      200 OK 서버가 요청을 성공적으로 처리
      201 Created 요청이 처리되어 새로운 리소스 생성
      (Response 헤더의 Location 필드에서 새로운 리소스의 절대 URI 참조)
      202 Accepted 요청은 받았지만 처리 미완료
      (Response 헤더의 Retry-After 필드에서 대기 필요 시간 참조)
      301 Moved Permanently 요청한 리소스가 새로운 URI로 이동
      (Response 헤더의 Location 필드에서 새로운 URI 참조)
      303 See Other 다른 위치로 요청 필요
      (Response 헤더의 Location 필드에서 다시 요청할 URI 참조)
      304 Not Modified 마지막 요청 이후 페이지 미갱신
      (If-Modified-Since 등의 조건부 GET 요청일 때)
      307 Temporary Redirect 임시 리다이렉션 요청 필요
      (Resonse 헤더의 Location 필드에서 재요청할 URI 참조, 향후 요청시에는 기존 URI 사용)
      400 Bad Request 요청의 구문이 잘못됨
      (클라이언트가 모르는 4xx 에러 포함)
      401 Unauthorized 요청한 리소스에 대한 권한 없음
      (Response 헤더의 WWW-Authenticate에서 필요한 인증 방식 참조)
      403 Forbidden 요청한 리소스에 대한 접근 금지
      (서버가 리소스 존재 자체를 은폐할 의도를 가지고 있을 경우에는 404가 오기도 함)
      404 Not Found 요청한 리소스를 찾을 수 없음
      500 Internal Server Error 서버에 에러 발생
      (클라이언트가 모르는 5xx 에러 포함)
      501 Not Implemented 요청한 URI의 메소드에 대해 구현되지 않음
      502 Bad Gateway 게이트웨이 또는 프록시 서버가 업스트림 서버로부터 잘못된 응답을 받음

       

       

       

      7.  브라우저 렌더링

       브라우저는 사이트로부터 받은 HTML, CSS, JavaScript 파일을 파싱하고 렌더링하여 클라이언트에게 최종적인 웹페이지를 보여줍니다. 렌더링 과정에 대해서는 HTML 렌더링을 위주로 설명하겠습니다. 이 과정에는 DOM(Document Object Model) 트리 구축, CSSOM(CSS Object Model) 트리 구축, 렌더 트리 생성, 레이아웃 계산, 페인팅 등이 포함됩니다.

       

       브라우저는 서버로부터 받은 HTML 파일을 파싱하여 태그들을 노드로 변환하고 이 노드들의 관계를 이용해 DOM 트리를 구성합니다. DOM 트리는 문서의 구조를 나타내며, HTML 문서 내 각 태그에 해당하는 노드로 구성됩니다. 이 트리는 자바스크립트를 통해 동적으로 변경될 수 있습니다. CSSOM 트리는 브라우저가 CSS 파일을 분석해서 생성한 트리입니다. CSSOM은 스타일 정보를 포함하고 있으며 DOM 트리의 각 노드에 적용되어야 할 스타일을 결정합니다. 

       

       렌더 트리는 DOM 트리와 CSSOM 트리를 결합하여 생성됩니다. 이 트리는 화면에 실제로 표시되어야 할 요소들을 포함하며, 각 요소의 스타일 정보도 포함합니다. 렌더 트리는 display: none 속성을 가진 요소 등 화면에 보이지 않는 요소를 제외한 요소들로 구성됩니다. 렌더트리가 완성되면 브라우저는 각 요소가 화면의 어떤 위치에 표시되어야 하는지 계산하는 레이아웃 단계를 수행합니다. 레이아웃 계산 후 실제로 화면에 요소들을 그리는 페인팅 단계가 이루어집니다. 이 단계를 통해 결과적으로 브라우저 화면에 텍스트, 이미지 등이 나타나게 됩니다. 

       

       

       

      8. 마무리

      웹 통신은 클라이언트와 서버가 '불확실성'을 넘어서 대화하는 과정이다! (feat. 레이어드 아키텍쳐)

       웹 통신 과정을 간략하게 요약하면 다음과 같습니다. 네트워크 접속 후 고정 IP 사용 또는 DHCP를 통해 동적 IP 할당을 받은 후 브라우저에서 특정 도메인 이름을 입력하면 DNS가 해당 서버의 IP를 알아냅니다. 인터넷 통신의 조건인 출발지, 목적지 IP 주소를 알았으니 서버와의 연결을 구축합니다. HTTPS 통신을 하기 위해서는 SSL/TLS Handshake를 추가로 거쳐 안전한 연결을 구축합니다.

       

       이후 클라이언트가 Application 계층에서 HTTP Method를 사용하여 데이터를 Request하면 데이터를 전달받은 하위 계층은 데이터에 헤더를 추가하고 인코딩하는 캡슐화 과정을 거칩니다. HTTPS 통신을 한다면 여기에 데이터 암호화 과정이 추가되겠죠. 데이터 캡슐화 및 하위 계층으로의 전달이 반복되어, 1층 Physical 계층에 다다른 바이너리 데이터는 PHY 칩에 의해 네트워크 환경에 적합한 전자기파로 변환되고, NIC에 의해 목적지로 출발합니다. 해당 데이터는 다수의 라우터를 거쳐 목적지에 도달합니다.

       

       수신측은 데이터를 받으면 송신측에서 일어나는 과정과 반대로 데이터가 디캡슐화되어 상위 계층으로 전달되며, 마지막 Appliation 계층에서 송신측의 순수한 Application 데이터를 확인하게 됩니다. 이렇게 브라우저의 Request 메세지를 수신한 서버는 이에 대한 응답으로 Response 메세지를 송신하며, 이 때의 수신측은 브라우저가 됩니다. 최종적으로 렌더링을 통해 브라우저에 웹 페이지의 형태가 표시됩니다. 하지만 지금까지의 얘기는 너무나 이상적인 시나리오입니다. 실제로는 송신자가 보낸 데이터를 수신자가 받게 되기까지 네트워크 지연, 데이터 손실, 보안 위협 등으로 인해 빈번히 통신 실패가 일어나곤 합니다.

       

       방대한 양이었지만 웹 통신의 전체 과정을 추상화해보면 레이어드 아키텍쳐의 한 예시입니다. 웹 통신의 상위 개념인 네트워크 통신을 설명하기 위해 사용하는 OSI 7 Layer, TCP/IP 모델은 네트워크 시스템을 계층화함으로써 각 계층이 수행해야 할 책임과 역할을 구분해 추상화한 것이며, 각 계층은 일종의 모듈이라고 할 수 있습니다.

       

       TCP/IP Updated 모델 기준으로 Data Link 계층은 LAN, WLAN 등의 네트워크와 상호작용하는 NIC, 스위치 등의 네트워크 하드웨어 장비들을 포함하므로 Physical 계층과 함께 하드웨어로 분류할 수 있고, Network 계층과 Transport 계층은 OS의 네트워크 스택에 의해 동작하므로 OS로 분류할 수 있습니다. 결국 웹 통신 과정은 불확실성 너머에 존재하는 클라이언트와 서버가 하드웨어 위에, 운영체제 위에, 웹 어플리케이션이 동작하는 계층화된 구조를 기반으로 대화하는 과정이라고 생각합니다.

       

       이상 인터넷 동작 과정에 대해서 톺아보았습니다. 글이 생각보다 길어졌는데 DNS 레코드, HTTP/3, 암호화 등 아직도 자세히 다룰 이야기들이 많아 시리즈로 작성해보려고 합니다. 긴 글 읽어주셔서 감사드리며, 혹시 틀린 부분이 있을 경우 지적부탁드립니다!

       

      figure 8-1. Layered 아키텍쳐를 따르는 웹 통신과정에 대한 추상화(TCP/IP Updated 모델 기준)

       

       

       

      9. Reference

       

       

      • HTTPS 
        • HTTP The Definitive Guide

       

       

      'NetWork' 카테고리의 다른 글

      [HTTPS] SSL/TLS Handshake란?  (0) 2024.04.04
      [I/O multiplexing] select vs kqueue  (1) 2024.01.07

      관련글 관련글 더보기

      댓글

    Designed by Tistory.

    티스토리툴바