F-Lab
멘토링 중 포스팅 제목의 질문을 받았다.
과거 면접 준비 당시 일련의 과정을 이해없이 암기하였지만 해당 포스팅을 통해 이해를 기반으로 내용을 정리한다.
단순 데이터 통신에서 그치지 않고 프론트엔드 개발자의 관점에서 데이터를 받아온 후 사용자의 화면에 렌더링 되기까지의 과정을 자세하게 알아본다.
텍스트
가 검색어
인지 URL
인지 확인한다.검색어
이면 검색 엔진의 URL
에 검색어
를 포함하여 이동시킨다.URL
이면 DNS서버
에 naver.com
의 주소를 요청할 준비를 한다.DNS server
에 요청을 보낸다.DNS 기록을 캐싱하는 이유
만약 새로운 웹사이트 요청이 들어올때마다
DNS서버
에 요청을 보낸다면 웹브라우저는 매번resolver
에게 요청을 보내고,resolver
에서root server
,root server
에서TLD server
에 요청을 보내는 과정이 필요하다.
따라서 웹사이트 요청마다 매번DNS서버
와의 통신 과정을 반복한다면 속도는 당연히 더 느려질 것이고DNS서버
에 병목현상이 발생할 수 있다.
병목 현상을 방지하고 반복을 막기위해OS
와웹브라우저
는 검색된적 있는 DNS 기록을 캐싱한다.
OS
에 저장된 DNS Cache
목록은 cmd
에서 ipconfig/displaydns
를 입력하면 조회할 수 있다.
브라우저
에 저장된 DNS Cache
목록은 chrome://net-internals/?#dns
를 검색하면 조회할 수 있다.
DNS Cache
는 영구적으로 저장되지 않으며, TTL
은 DNS Query
를 저장하는 기간을 의미한다.
DNS Caching
은 OS
와 브라우저
단계에서만 일어나지 않는다.
새로운 웹사이트 요청이 들어오면 DNS
가 조회되는 동안 resolver
, root server
, TLD server
를 거치고 각 단계에서 정보가 수집되고 캐시된다.
따라서 local DNS cache
가 비어있더라도 resolver
는 모든 DNS
조회 과정을 거칠 필요가 없을 수 있다.
resolver
란?
resolver
는 웹 브라우저와 같이DNS 클라이언트
의 요청을네임 서버
로 전달하고네임 서버
로부터 정보를 받아클라이언트
에 제공하는 기능을 수행한다.
일반적으로 모든 기능을PC
와 같은 클라이언트 호스트에 구현하는 것은 제약이 있기 때문에resolver
의 대부분의 기능은local DNS server
에 구현한다.
참고자료
DNS cache
https://www.keycdn.com/support/dns-cache
IP
주소를 요청한다.ISP(인터넷 서비스 제공자)
를 통해 DNS query
를 전달한다.local DNS
에 문의한 www.naver.com
의 IP
주소를 문의한다.local DNS
에 www.naver.com
의 IP
주소가 없다면 root DNS
를 시작으로 원하는 IP
주소를 찾을때까지 도메인의 뒤에서부터 재귀적 탐색을 반복한다.Recursive Query
라고 부른다.탐색순서
. (root DNS) => com (TLD DNS) => naver.com (SLD DNS)
ISP란?
KT, SK브로드밴드, LG유플러스 등과 같이 인터넷 서비스를 제공하는 업체를 ISP라 한다.
DNS 계층 예시
참고자료
Recursive Query
https://www.netmanias.com/ko/post/blog/5353/dns/dns-basic-operation
DNS 계층
https://peemangit.tistory.com/52
IP
주소를 이용하여 HTML
문서 요청www.naver.com
의 IP
주소를 사용하여 네이버 서버에 HTML
파일을 요청하는 HTTP Request
를 보낸다.
HTTP Request
란?
HTTP Method(GET, PUT, POST 등)
을 사용하여 클라이언트에서 서버로 전송하는 메시지이다.
TCP/IP
프로토콜이란?
TCP/IP
프로토콜은Transmission Control Protocol
와Internet Protoco
의 조합으로 이루어져있다.
TCP
프로토콜은 연결 지향적 프로토콜로 데이터 전송 과정에서 데이터의 무손실 전송을 보장하고, 패킷의 순서를 보장하며 오류가 발생하면 재전송을 시도함으로써 신뢰성 있는 데이터 전송을 보장한다.
IP
프로토콜은 비연결형 프로토콜로, 데이터 전송 과정에서 패킷의 라우팅을 담당한다.
신뢰성과 연결성을 위해 대부분의 인터넷 서비스는TCP/IP
프로토콜을 사용한다.
3-way handshake
를 사용해 연결하며4-way handshake
를 사용하여 연결을 종료한다.
DNS
서버와 통신할때는 어떤 프로토콜을 사용할까?
DNS
서버와 통싱할때에는TCP/IP
프로토콜을 사용하지 않고UDP
프로토콜을 사용한다.
UDP
는TCP
보다 빠르며 대부분의DNS
요청은 크기가 매우 작다. (UDP 제한 : 512bit 이하)
또한,UDP
는 연결을 유지하지 않으므로DNS
서버의 부하를 줄일 수 있기때문에UDP
를 사용한다.
WAS(웹 어플링케이션 서버)
는 동적 컨텐츠(ex. 페이지 생성, 비즈니스 로직 처리, DB 접근 등)을 처리하는 서버이다.WAS
만으로도 웹 서버의 기능을 구현할 수 있지만 트래픽 분산 및 보안 등의 이유로 웹 서버와 WAS
를 함께 사용한다.WAS
라고 볼 수 있다.BFF
하지만, 프론트엔드 개발자가 Web Server만 다루는 것은 아니며, BFF(Backend for Frontend)등을 다루는 경우 Web Server뿐만 아니라 WAS를 함께 관리하고 다룬다.
BFF는 주로 MSA와 함께 사용되는 개념으로 프론트엔드를 요구사항에 맞게 구현하기 위한 도움을 주는 보조 서버의 의미를 갖는다.
HTTP Response
를 보낸다.HTTP Response
는 status code
를 포함한다.주요 HTTP 상태 코드
1xx(정보) : 추가 정보가 있음을 전달합니다.
2xx(성공) : 서버가 요청을 처리했음을 전달합니다.
3xx(리다이렉트) : 다른 URI로 다시 리퀘스트하도록 요청합니다.
4xx(클라이언트 오류) : 요청에 문제가 있어 처리할 수 없음을 전달합니다.
5xx(서버 오류) : 서버 쪽에 문제가 있어 처리할 수 없음을 전달합니다.
참고자료
그림으로 배우는 네트워크 원리 p.105
(critical rendering path)
에 대해 간략하게 표현한 것이다.참고자료
브라우저 동작 원리
https://poiemaweb.com/js-browser
CSS
를 로드하는 link
태그나 style
태그를 만나면 CSS
를 파싱하고 CSSOM
생성을 시작한다.DOM
생성과 CSSOM
생성은 병렬적으로 실행된다.<script>
태그를 만나면 DOM
생성이 중단되고 자바스크립트를 파싱하고 실행한다.노드의 종류
노드 객체는 총 12개의 종류가 있다.
그 중문서 노드
,요소 노드
,어트리뷰트 노드
,텍스트 노드
를 주의깊게 보자.
렌더링 엔진이 아래 코드를 파싱하는 과정은 다음과 같다.
<html> <body> Hello world </body> </html>
html 토큰
생성 ->HTMLHtmlElement
노드 생성 ->DOM
트리에HTMLHtmlElement
노드 추가 ->HTMLHeadElement
노드 생성 ->DOM
트리에HTMLHeadElement
노드 추가 ->body토큰
생성 ->HTMLBodyElement
노드 생성 ->DOM
트리에HTMLBodyElement
노드 추가 ->Hello world
토큰 생성 ->텍스트 노드
생성 ->DOM
트리에body 노드
의 자식으로텍스트 노드
삽입 -> 종료
DOM
생성과 같은 과정을 반복하여 CSSOM
을 생성한다.CSSOM
은 CSS
의 상속을 반영하여 생성한다.아래 코드에서 렌더링 엔진이
link
태그를 만나면 브라우저는 웹 서버에CSS
파일을 요청하고 이후CSS
코드를 파싱하여CSSOM
을 생성한다.
이떄 브라우저의 렌더링 엔진은CSSOM
의 생성을 다른 스레드에 올려DOM
과CSSOM
의 생성을 병렬적으로 실행한다.<!DOCTYPE html> <html> <head> <meta charset="UTF-8"> <link rel="stylesheet" href="style.css"> </head> <body> <ul> <li id="apple">Apple</li> <li id="banana">Banana</li> <li id="orange">Orange</li> </ul> <script src="app.js"></script> </body> </html>
<script>
태그를 만나면 HTML 파싱을 중단하고 자바스크립트를 파싱 및 실행한다.AST(추상적 구문 트리)
를 생성한다.
<script>
태그의 위치렌더링 엔진이
<script>
태그를 만나면HTML
파싱이 중단된다.
<script>
태그의 위치에 따라 사용자가 보는 화면의 렌더링 시간이 달라질 수 있으며,DOM
이 완성되지 않은 상태에서DOM
을 직접 조작하는 경우 에러가 발생할 수 있다.
따라서 이러한 에러를 방지하고 페이지 로딩 시간을 단축시키기 위해서는<script>
태그를<body>
태그의 가장 아래에 위치시키는 것이 좋다.
또는async
와defer
키워드를 사용하여 비동기 처리를 할 수 있다.
단,async
와defer
키워드는 외부 자바스크립트 파일을 로드하는 경우에만 사용가능하다.
참고자료
async, defer
https://www.growingwiththeweb.com/2014/02/async-vs-defer-attributes.html
(Render Tree)
를 생성한다DOM
과 CSSOM
가 완성되면 이 둘을 결합하여 렌더 트리를 생성한다.display : none
으로 설정된 노드들은 포함하지 않는다.
display : none
vsvisibility : hidden
display : none
으로 설정된 노드는 렌더트리에서 제외되고 화면에 보이지 않는다.
visibility : hidden
으로 설정된 노드는 렌더트리에는 포함되어 공간을 차지하지만 보이지 않는다.
display : none
으로 설정한 경우display : block
등으로 변경하면Reflow
와Repaint
가 모두 발생한다.
visibility : hidden
으로 설정한 경우에는Repaint
만 발생한다.
따라서 렌더링이 불필요한 노드는display : none
으로 설정하여 성능을 올릴 수 있다.
display : none
과visibility : hidden
모두 스크린 리더가 읽지 않는다.
(Layout)
을 계산한다.(Painting)
한다CSS
요소를 확인할 수 있다.