이번 포스팅에서는 인터넷 브라우저에 www.google.com을 입력하면 어떤 일이 발생하는지 과정을 알아보려고 한다. 즉, 웹의 전반적인 HTTP 통신에 대해 알아보는 것이다. 이와 관련된 포스트들은 다른 블로그에도 충분히 많기 때문에 참고하면서 작성하였다.
- 웹 브라우저에 URL을 입력한다.
- 브라우저와 로컬에서 DNS 기록이 있는지 확인하고 없으면 ISP에서 DNS 쿼리를 통해 IP 주소를 찾는다.
- IP 주소를 찾았으면 라우터를 통해 경로를 설정하고 ARP 패킷을 보내 MAC 주소를 찾아내 통신할 준비를 한다.
- 웹 브라우저와 서버는 TCP 커넥션을 통해 연결을 수립한다.
- 웹 브라우저는 서버에 HTTP 요청을 보내고 서버는 이에 응답 메세지를 작성한다.
- 서버는 클라이언트와 TCP 커넥션을 맺고 응답을 보낸다.
- 커넥션이 닫히면 웹 브라우저는 렌더링을 통해 사용자에게 웹 페이지를 보여준다.
IP주소 응답
먼저 입력받은 URL을 파싱하여 어떤 프로토콜로 어떤 URL을 보낼지 해석하는 단계가 필요하다.
다음 URL보면 포트번호를 입력하지 않았는데 포트번호가 있다는 것을 확인할 수 있다. 명시적으로 표시하지는 않았지만 설정된 기본값으로 요청하게 된다.
URL은 사람들이 기억하기 쉽게 췬숙한 도메인 이름으로 만들어져 있다. 이 도메인 이름을 IP 서버로 변환해서 찾아가야하는데 이전에 이 사이트를 방문한 적이 있을 수도 있다. 그럼 캐시가 있는지 확인을 해야한다.
캐시가 존재한다.
웹 브라우저에 캐싱된 DNS 기록이 존재할 수 있다.
먼저 HSTS(HTTP Strict transport security) 목록을 조회한다. HSTS는 HTTP를 허용하지 않고 HTTPS만을 통신하게 하는 것이다. 해당 브라우저는 URL을 HSTS 캐시에 저장한다. 만약 HSTS 목록에 해당 URL이 있다면 HTTP을 요청해도 HTTPS로 요청하게 된다.
그렇다면 URL을 IP주소로 변환하는 과정을 거쳐야 한다.
- 먼저 브라우저에서 방문한 페이지에 대한 DNS 기록이 있는지 확인한다.
- OS 내에 시스템 호출(`systemcall`)을 통해 저장된 DNS 기록이 있는지 확인한다.
- 브라우저는 라우터 캐시를 확인한다.
캐시가 존재하지 않는다.
만약 라우터를 통해서도 DNS 기록을 캐싱할 수 없다면 ISP 캐시를 확인하게 된다.
ISP(인터넷 공급자)는 DNS 서버를 구축하고 있기 때문에 DNS 기록을 가지고 있는 최후의 수단이다. 만약 존재하지 않으면 에러가 발생한다. ISP(아래 그림에서는 SKT)는 DNS 쿼리를 통해 여러 DNS 서버를 꼬리에 꼬리를 물듯이 검색해 IP 주소를 찾는다(DNS Lookup). 처음에는 Local DNS에 해당하는 IP 주소를 찾고 없으면 .(Root), .com(TLD), google.com 순으로 해당 IP 주소를 찾는다.
해당 URL과 매핑되는 IP 주소를 찾게되면 DNS recursor(ISP의 도메인 서버)로 보내게 된다. 아래 210.220.163.82가 SKT의 서버이다. 이 모든 요청이 작은 패킷을 통해 이루어지는데 DNS 서버에 도달하기까지 라우팅 테이블을 통해 빠른 방법으로 목적지까지 도달할 수 있다. 중간에 패킷을 잃어버리면 요청실패 오류(Request Fail Error)가 발생한다.
DNS(Domain Name Server)는 도메인에 대한 정보를 가지고 있는 서버로 도메인을 IP 주소로 변환하는 역할을 한다.
TCP/IP 이론 - DHCP 서비스, DNS 서비스 그리고 맥 주소 - Seung Joo Choi(POCS)↗
TCP 소켓 연결
DNS 서버로부터 IP 주소를 받게 되면 어떠한 경로를 통해 IP 주소로 가야한다.
경로를 알기 위해 라우터(Router)를 통해 해당 경로까지 지정하여 찾아가게 된다. 라우터는 라우팅 테이블을 통해 경로를 지정할 수 있다.
그리고 통신을 위해 IP 주소를 MAC 주소로 변환해야한다. 이를 위해 ARP(Address Resolution Protocol)요청 패킷을 브로드 캐스트로 전송한다. 목적지의 물리주소를 아는지 모든 시스템에 전송하면 해당 IP와 일치한 물리주소를 갖고 있는 시스템은 물리주소를 포함해 ARP 응답을 보낸다. 응답 땐, 유니캐스트로 보내게 된다.
이제, 경로를 알고 통신할 수 있게 되면 TCP 소켓 연결을 진행하게 된다.
소켓 연결은 3-way-handshake를 통해 이루어지며 클라이언트와 서버는 SYN(synchronize,연결 요청)과 ACK(Axknowledgement, 승인)를 교환하며 연결 여부를 승인한다.
그리고 HTTPS 요청은 암호화 통신이기 때문에 TLS 핸드쉐이킹을 추가해 암호화된 통신을 진행할 수 있다.
- 클라이언트는 인터넷을 통해 서버에 SYN 패킷을 보내 연결 여부를 묻는다.
- 서버가 연결을 시작할 수 있는 포트가 있는 경우 SYN/ACK 패킷으로 승인을 응답한다.
- 클라이언트는 SYN/ACK 패킷을 수신하고 ACK 패킷을 전송해 승인한다.
웹과 인터넷의 차이 그리고 TCP/IP와 HTTPS
인터넷(internet)는 말그대로 Inter(~ 사이에)와 네트워크의 합성어로 네트워크와 네트워크를 연결하는 거대한 통신망을 말한다.
TCP/IP 프로토콜, 신뢰성있는 데이터 전송을 담당하는 프로토콜을 제공한다.
웹(Web)은 인터넷에 연결된 사용자들끼리 정보를 공유하는 공간이다. 즉, 인터넷의 하위 집합이다. 웹은 웹 문서를 보여주는 서비스로 HTTP 프로토콜을 통해 데이터를 공유한다.
HTTPS 프로토콜 요청
이제 클라이언트와 서버 간의 연결이 끝났으면 서버로 페이지 요청을 하게된다.
서버가 해당 요청을 수락하면 응답을 생성해 브라우저에게 전달하게 된다. 서버에서 응답한 내용은 HTML, CSS, Javascript로 이루어져 있는데 브라우저는 해당 파일들을 해석해 그리게 된다.
브라우저의 HTTP 요청
브라우저는 GET 요청을 통해 서버에게 웹 페이지를 요청한다. 만약 Form과 함께 제출하는 경우에는 POST 메서드를 이용해 요청한다.
서버의 요청 처리 및 응답
서버는 요청을 수신하고 Request Handler에게 요청을 전달해 Response를 생성하게 한다.
Request Handler는 요청과 요청의 헤더, 쿠키를 읽어 파악한후 서버에 정보를 업데이트한다.
작업의 결과는 웹 서버로 전달하여 웹 브라우저에게 문서 결과를 상태코드(Status Code)와 함께 응답한다.
브라우저의 웹 페이지 출력
지금까지는 웹의 동작 방식이라면 이번엔 브라우저 렌더링 과정이다.
렌더링(Rendering)은 HTML이나 CSS, javascript와 같은 문서를 브라우저에서 그래픽 형태로 출력하는 것을 말한다. 어떤 브라우저나 렌더링 엔진을 가지고 있다. 예를 들어, 크롬이나 사파리에서는 Webkit 엔진을 사용한다.
HTML 파싱 후, CSS 파싱
먼저 HTML 문서를 파싱(parsing)한다. 코드를 이해할 수 있는 구조로 변환하는 것이다. 파서(Parser)를 통해 토큰 단위로 분리해 상하 관계에 따라 하나의 트리 형태로 만든다. 이것을 DOM(Document Object Model) 트리라고 한다.
그다음, CSS 문서를 파싱해 CSS 구조체(CSSOM) 트리를 만든다.
만약, HTML 문서를 파싱하던 중 CSS가 필요한 태그 (`<style>`, `<link>`)를 만나면 CSS 파일을 파싱하여 트리를 만든다.
트리를 다 만들면, 다시 HTML 문서에서 DOM 트리를 구축한다.
Render 트리 구축 - 배치 - 그리기
DOM 트리와 CSSOM 트리를 이용해 렌더 트리(Render Tree)를 생성하는데 실제 화면에 보여지는 노드들로만 구성해 생성한다. 만약 화면에 보여지지 않는 노드라면 제외시킨다.
이번엔 렌더 트리를 기반으로 해당 HTML 요소의 위치와 크기를 계산해 배치하는 작업을 진행한다. `%, vh, vw`와 같은 상대적인 요소를 `px`로 통일해 변환된다.
`px`라는 절대적인 크기로 통일되었다면 실제로 화면에 그리는 단계이다. 이 단계를 통해 UI 백엔드가 노드를 돌며 화면에 보여지게 된다.
뷰 포트(View Port)
웹 페이지가 브라우저에 실제로 표시되는 부분이다. 기기마다 크기가 상대적으로 다르기 때문에 `%`와 같이 상대적인 크기이면 계산을 다시해야 한다.
☕️ 포스팅이 도움이 되었던 자료
오늘도 저의 포스트를 읽어주셔서 감사합니다.
설명이 부족하거나 이해하기 어렵거나 잘못된 부분이 있으면 부담없이 댓글로 남겨주시면 감사하겠습니다.
'Web > Web 이론' 카테고리의 다른 글
| JWT(Json Web Token)에 대한 이론적 이해 (0) | 2023.12.06 |
|---|---|
| REST(Representational State Transfer) API (0) | 2020.09.21 |
