예를들어 사용자가 www.google.com을 입력하면, 브라우저는 HTTP 프로토콜을 사용해 구글 웹 서버와 통신하려고 한다. HTTP는 OSI 7계층 중 애플리케이션 계층에서 동작하는 프로토콜이다. 이때 브라우저는 요청한 도메인 이름(www.google.com)에 대한 IP 주소를 알아야 하기 때문에…

결국 DNS 서버는 해당 도메인에 대한 IP 주소(예를 들어, 142.250.190.78)를 응답한다.
IP 주소를 얻은 후, 브라우저는 구글 서버와 통신을 시작한다. HTTP는 TCP/IP를 기반으로 작동하므로, 데이터를 주고받기 전에 TCP 3-Way Handshake 과정이 필요하다. 이 단계는 전송 계층(4계층) 에서 이루어진다. 만약 HTTPS일 경우, TLS 핸드셰이크가 이어진다. 암호화된 통신을 위해 인증서 교환 등 수행한다.
TCP 연결이 성립된 후, 브라우저는 HTTP Request 메시지를 생성하여 구글 서버에 보낸다. 예를 들어, 브라우저는 GET / HTTP/1.1 이라는 요청을 TCP 프로토콜을 통해 80번 포트로 전송합니다. 이때 데이터는 패킷(Packet) 형태로 네트워크를 통해 전달된다. 네트워크를 통해 데이터를 전송하기 위해서는 네트워크 계층(3계층)에서 IP 주소를 사용하고, 데이터 링크 계층(2계층)에서 MAC 주소를 사용하여 패킷이 전송된다.
웹 서버 혼자 모든 로직 처리와 데이터 관리를 하게 되면 과부화 가능성이 크다. 그렇기 때문에 웹 서버를 돕기 위해 WAS가 필요하다. WAS는 사용자의 컴퓨터나 장치에 웹 어플리케이션을 수행해주는 미들웨어다. 특정 데이터 요청을 브라우저로부터 받게 되면, 웹 서버는 페이지의 로직이나 데이터베이스의 연동을 위해 WAS에게 이들의 처리를 요청한다. WAS는 해당 요청을 통해 동적인 페이지 처리를 담당하고, DB에서 필요한 데이터 정보를 받아 그에 맞는 파일을 생성한다.

이런 식으로, 구글 서버는 클라이언트의 요청을 수신하고 이를 처리한 후, HTTP Response 메시지를 생성하여 응답한다. 서버는 요청이 성공했음을 알리는 200 OK 상태 코드와 함께 웹 페이지 데이터를 전송한다.

웹 브라우저에 출력되는 단계를 Critical Rendering Path 라고 하며 크게 6단계로 나뉜다. 성능을 최적화하기 위해서는 수신받은 HTML, CSS, JS 파일들이 어떤 단계를 거쳐 일어나는지 이해한 후, 해당 과정들을 최소화하는 것이 중요하다.
앞서 받아온 HTML 파일들, 즉 브라우저의 HTML 파싱이 있은 후, DOM 생성을 생성한다.

<html> → <, h, t, m, l, > <html> → StartTag: html , </head> → EndTag: head, Hello → TextStartTag: html → html 노드 생성 , StartTag: head → head 노드 생성 , Hello → 텍스트 노드 "Hello" 생성
그리고 나서, HTML에서 사용했던 객체 모델로 전환하는 작업이 CSS 파일에 똑같이 적용된다. CSSOM 트리 형태를 만들고, 특정 객체에 최종 스타일을 계산할 때 상위 객체의 스타일을 하향식 규칙을 적용하는 방식으로 계산되는 스타일을 재귀적으로 세분화하게 된다.

여기까지 CSSOM 트리를 만들고 나서, 기존에 만들어 놓은 DOM과 결합되어 Render Tree가 생성된다. Render Tree는 렌더링에 필요한 노드만 선택하여 페이지를 렌더링하는데 사용한다.

그리고 Render Tree의 노드들에 대한 위치와 크기를 계산하는 단계인 Layout 단계 로 넘어간다. 페이지 상에 존재하는 객체의 크기를 렌더링 트리의 루트부터 시작하여 모든 객체의 정확한 위치와 크기를 계산한다.

이렇게 계산된 값들을 기반으로 화면에 필요한 요소들을 실제로 그리는 작업을 실행한다. Layout 단계에서 계산된 모든 위치, 크기를 실제 픽셀로 변환하여 화면에 출력한다. 이런 일련의 과정을 거치면 비로소 www.google.com에 해당하는 화면이 웹 브라우저에 출력된다.

<참고 자료>
billy님의 velog
웹의 동작 방식
웹페이지를 표시한다는 것: 브라우저는 어떻게 동작하는가