브라우저에서 웹 서버로 정적 파일을 요청하는 과정

사용자는 브라우저(Chrome, Edge)를 이용해 인터넷을 서핑한다.

브라우저에 URL을 입력하면 해당 주소와 연결된 웹 서버가 존재한다면, 사용자에게 그 주소에 연결된 데이터를 제공한다.

 

 

강의와 유튜브, 그리고 내가 알고 있던 지식을 종합해서 정리한 클라이언트의 웹 문서 요청 순서도.

위의 기능 중 내가 실제로 인지하고 있던건 그렇게 많지 않았던 것 같다.

이번 기회에 서버와 브라우저의 통신에 대해 조금 더 깊이 이해하고 넘어가야겠다.

 

---

 

1. URL 입력

사용자는 브라우저에 URL을 작성한다.

브라우저는 이 행위를 수행할 때, 검색 결과를 사용자에게 보여줘야 할지, 이것이 웹의 리소스를 요청하는 명령인지 파악해야 한다.

 

2. 브라우저 내부 처리

브라우저는 사용자가 요청한 문서가 캐싱되어 있는지 확인한다. 서비스 워커는 개발자가 작성하는 백그라운드 스크립트이다.

웹 페이지와는 별개의 쓰레드를 제공받는다.

 

3. DNS 질의

브라우저에 DNS 캐시가 있는지 확인한다.

브라우저의 요청에 의해 소켓이 OS DNS 캐시를 조회한다.

캐시가 없다면 네트워크를 이용해 DNS 서버에 질의를 보낸다.

도메인에 맞는 IP 주소를 획득한다.

 

4. TCP 연결

클라이언트의 PC는 서버와 TCP 연결을 시도한다.

(OS에 소켓을 연결하고 URL 질의를 세그먼트 버퍼에 담는다.

세그먼트는 출발지와 목적지를 담은 packet으로 나눠져서 서버로 전송된다.

TCP는 정확도를 보장하는 프로토콜로 3-way handshake 방식을 통해 패킷이 전달된다.)

 

5. TLS Handshake(HTTPS)

서버와 인증 연결을 주고받기 위해서는 서로 hello를 교환해야 한다.

클라이언트와 인증 연결을 주고받으면 서버는 인증에 필요한 정보를 클라이언트에 넘긴다.

클라이언트는 서버가 보낸 인증에 대한 정보를 검토한다.

키 교환이 이루어지고, 보안 연결이 시작된다.

 

6. HTTP 요청 전송(HTTPS)

TCP 연결이 체결되면, 클라이언트는 header를 포함한 질의를 http로 만들어 서버로 전송한다.

서버는 이 HTTP를 수신하고 파싱한다.

 

7. 서버 응답

서버는 HTTP 요청에 있는 정보가 있고, 허용된 사용자라면 해당 정보를 사용자에게 200 코드와 함께 전송한다.

 

8. 브라우저 렌더링

브라우저는 전송받은 html 파일을 돔 구조로 파싱한다.

그 과정에서 필요한 리소스(Script, CSS 등 외부 리소스)를 다시 요청한다.

css 파일이 전송되면 css 파일을 읽어 cssom을 생성한다.

node + css 인 렌더 트리를 구성한다.

렌더 트리를 브라우저에 그리고 css에 맞게 재배치하여 렌더링한다.

 

---

네트워크 강의를 통해 TCP/IP, NIC, DNS, 네트워크 계층, Frame, Packet, Segment, 3-way handshake에 대한 개념을 갖고 있었지만, 실제 내가 만든 웹 서비스가 동작하는 브라우저에 대해 살펴본 적은 없었던 것 같다.

 

 

요약

사용자가 요청한다.
요청에 대해 캐시가 있는지 확인한다.
DNS 요청으로 IP를 확인한다.
IP를 이용하여 TCP 연결을 확인한다.
[보안 연결]이 필요하다면 보안과 관련하여 협의한다.
실제 원하는 자료를 HTTP로 서버에 요청한다.
서버에서 회신한 내용을 브라우저에 그린다.

 

간결하게 잘 정리된 로직인 것 같다.

브라우저의 기능에 대해 생각해볼 수 있는 좋은 계기가 되었다.

브라우저 역시 누군가가 만든 프로그램이고 OS 위에서 자원을 할당받아 돌아가는 프로그램이다.

 

여기서 좀 더 확장해서 생각하고 싶은 내용은 다음과 같다.

 

React로 만든 앱의 가상돔과 렌더트리의 관계

서비스 워커

웹 어셈블리

Web API