[TIL] WEB/HTTP : 브라우저 동작원리

은경·2022년 1월 11일

CS TIL http web

[WEB/HTTP]

목록 보기

3/7

📌 주소 창에 www.google.com 을 검색했을 때 어떤 일이 일어날까 ?

🔍 브라우저에 대해서

브라우저의 기능
- 사용자가 자원(HTML문서, pdf, 이미지 등)을 서버에 요청->브라우저에 표시
- 자원의 주소는 URI에 의해 정해짐.
- 브라우저는 html과 css 명세에 따라 html 파일을 해석해서 표시
- W3C(World wide web Consortium)에서 정한 표준 명세를 따름(호환성 문제 발생 방지)
브라우저의 구조
- 사용자 인터페이스 : 주소표시줄, 북마크,새로고침,이전,다음 버튼,홈 버튼 등등
- 브라우저 엔진 : 인터페이스 <-> 렌더링 엔진 사이 동작 제어
- 렌더링 엔진 : 요청한 콘텐츠를 파싱해서 표시
- 통신 : http 요청과 같은 네트워크 호출에 사용 (플랫폼의 독립적인 인터페이스로 구성되어있음)
- UI 백엔드 : 플랫폼에서 명시하지 않은 일반적 인터페이스 ex)콤보박스
- 자바스크립트 해석기 : 자바스크립트 코드 해석/실행
- 자료 저장소 : 자원을 하드 디스크에 저장하는 계층 ex)쿠키

렌더링 과정

렌더링 : 요청 받은 내용을 브라우저 화면에 표시해줌 (html, xml, 이미지 등을 표시 가능)
크롬/사파리는 웹킷 엔진 사용, 파이어폭스는 게코 엔진 사용

📌
 1. html 문서를 파싱.
 2. 콘텐츠 트리 내부에서 태그를 모두 DOM 노드로 변환.
 3. 외부 css 파일과 함께 포함된 스타일 요소를 파싱.
 4. 이 스타일 정보와 html 표시 규칙은 렌더 트리라고 부르는 또 다른 트리를 생성.
 5. 성된 렌더 트리는 정해진 순서대로 화면에 표시되는데, 
 생성 과정이 끝났을 때 배치가 진행되면서 노드가 화면의 정확한 위치에 표시되는 것을 의미.
 6. UI 백엔드에서 렌더 트리의 각 노드를 가로지으며 형상을 만드는 그리기 과정이 진행됨.
 7. 전송을 받고 기다리는 동시에 받은 내용을 먼저 화면에 보여준다 (순서대로)

돔(DOM)
- Document Object Model(문서 객체 모델)
- <html>, <body> 태그들을 자바스크립트가 활용 할수 있는 객체로 만들면 문서 객체가 됨.
- 웹 브라우저가 html 페이지를 인식하는 방식 - 트리구조

👇웹킷 동작 과정

👇게코 동작 과정

파싱(Parsion)

📌 브라우저가 코드를 이해하고 사용할 수 있는 구조로 변환하는 것
- 문서로 어휘 분석과 구문 분석 과정을 거쳐 파싱 트리를 구축.
  👇 2+3-1을 파싱한 트리 노드
- 파싱은 어휘 분석 / 구문 분석으로 구분됨.
  - 어휘분석 : 자료를 토큰으로 분해하는 과정.(토큰은 사전 같은 용어집이라고 할수있다)
    공백, 줄 바꿈 같은 의미 없는 문자 제거함
  - 구문분석 : 언어의 구문 규칙을 적용하는 과정
    문서 구조를 분석-> 파싱 트리 생성
- 이후 파싱은 보통 문서를 다른 양식으로 변환 (컴파일), 소스 코드를 기계 코드로 만드는 컴파일러가 파싱 트리 생성 후 이를 기계 코드 문서로 변환한다.
- 파서를 생성하는 것은 문법 규칙 등 복잡함 -> 대부분 파서 생성기 활용
- 웹킷은 플렉스,바이슨 이용 (Head 태그를 실수로 빠뜨려도, 파서가 오류를 수정해준다.)
- 파싱 과정을 거쳐서 서버로 부터 받은 문서를 브라우저가 이해하고 사용할 수 있는 DOM 트리 구조로 변환 시켜줌.

1. 브라우저 주소 창에 www.google.com을 검색한다.

2. 브라우저가 google.com의 IP 주소를 찾기 위해서 캐시에서 DNS 기록을 확인.

DNS(Domain Name System) = 인터넷 전화번호부
인터넷의 모든 URL에는 고유 IP주소가 할되어 있음, DNS는 웹사이트의 IP주소와 도메인 주소를 연결시키는 시스템.
해당 IP주소는 웹사이트의 서버를 호스트하는 컴퓨터에 속함.
구글의 IP주소는 142.250.196.110 따라서, https://142.250.196.110 를 입력해도 구글에 접속가능.
📌 도메인 주소로 IP주소를 알고 싶으면 터미널에서 nslookup naver.com
ip주소를 하나하나 외울 수 없기 때문에, 주소를 쉽게 찾을 수 있도록 DNS가 URL과 IP를 매핑해줌.
DNS 기록을 찾기 위해 브라우저는 4개의 캐시를 확인함.
캐시로 보관하는 이유 -> 캐시는 보안성은 떨어지나, 트래픽/데이터 전송시간 개선에 유리하다.
- (1) DNS 쿼리가 브라우저 캐시 확인 : 브라우저는 사용자가 이전에 방문한 웹 사이트의 DNS기록을 일정 기간 동안 저장하고 있다.
- (2) OS 캐시 확인 : 브라우저 캐시에 원하는 DNS 레코드가 없으면, 내컴퓨터 OS에 시스템 호출(예시 - MAC OS에서 gethostname 호출)을 통해 DNS 기록 가져옴.
- (3) 라우터 캐시 확인 : 컴퓨터에도 DNS 레코드가 없을 시 브라우저는 라우터에서 DNS기록을 저장한 캐시를 확인.
- (4) ISP 캐시 확인 : 1~3단계에서도 기록을 찾지 못하면 ISP에서 DNS기록을 확인함. ISP(Internet Service Provider)는 DNS 서버를 가지고 있음
DNS(Domain Name Server) 서버는 할당된 도메인에 대한 정보를 가지고 있는 서버. 도메인을 IP주소로 변환하는 역할.

3. 요청한 URL이 캐시에 없을 시, ISP의 DNS 서버가 DNS 쿼리로 google.com을 호스팅하는 서버의 IP 주소를 찾음.

DNS 쿼리 -> 웹사이트의 IP주소를 찾을 때 까지 인터넷에서 여러 DNS 서버를 검색하는 것이 목적.
원하는 IP주소를 찾거나, 못찾고 오류를 반환할 때 까지 한 DNS서버에서 다른 DNS서버로 검색이 반복적으로 계속되고 이런 유형의 검색을 -> 재귀적 질의(Recursive Query)라고 함.
ISP의 DNS서버를 DNS 리커서(DNS Recursor)라고 하고 인터넷의 다른 DNS서버에 답변을 요청하여 도메인 이름과 매핑되는 IP주소를 찾는 역할.
다른 DNS서버는 웹사이트 도메인 이름의 도메인 아키텍처를 기반으로 검색을 수행 = Name Server 라고함

👇 도메인 아키텍처의 구성

많은 웹 사이트의 URL은 3차 도메인, 2차 도메인, 최상위 도메인 TLD(Top Level Domain) 으로 구성, DNS Lookup(DNS 서버에서 도메인 이름을 사용해 IP를 알아내는 과정을 DNS 룩업 이라고 함.) 도중에 쿼리되는 고유한 네임 서버가 있다.

진행 과정
- DNS 리커서가 루트 네임 서버(Root Name Server)에 연결.
- 루트 네임 서버는 리커서를 .com 도메인 네임 서버로 리디렉션.
- .com 네임 서버는 google.com 네임 서버로 리디렉션.
- google.com 네임 서버는 DNS기록에서 google.com과 매핑되는 IP주소를 찾아 DNS리커서로 반환, 리커서는 브라우저로 다시 보냄.
위와 같은 request는 내용, 주소와 같은 정보들을 작은 데이터 패킷에 담아 전송.
패킷은 DNS서버에 도달 전 클라이언트와 서버 사이의 네트워킹 장비를 통해 이동.
장비들은 라우팅 테이블을 사용->패킷이 목적지에 도달할 수 있는 가장 빠른 방법을 알아냄.
- 이동 중 패킷이 손실되면 요청 실패 오류 발생.
- 손실되지 않으면 올바른 DNS 서버에 도달하여 IP주소를 가지고 브라우저로 돌아감.

4. 브라우저가 해당 서버와 TCP 연결을 시작.

전송 제어 프로토콜 : TCP(Transmission Control Protocol)
브라우저가 IP주소 수신 -> 해당 IP주소의 서버와 인터넷 프로토콜을 사용해 연결해서 정보전송
HTTP 요청에서는 주로 TCP를 사용함
클라이언트<->서버간의 데이터 패킷을 전송하려면 TCP 연결이 필요,
TCP/IP 3-way handshake : 클라이언트와 서버가 SYN(synchronize: 연결 요청) 및 ACK(acknowledgement: 승인) 메시지를 교환하여 연결을 설정하는 3단계 프로세스를 통해 TCP연결이 이루어진다.
- 클라이언트가 인터넷을 통해 서버에 SYN패킷을 보내 새 연결이 가능한지 물어봄
- 서버에 열린 포트가 있는 경우 SYN/ACK 패킷사용, SYN패킷의 ACK으로 응답. (연결요청-승인)
- 클라이언트는 서버에서 SYN/ACK 패킷을 수신, ACK패킷을 전송하여 승인.

5. 브라우저가 서버에 HTTP 요청(Request)을 보냄.

TCP 연결 후 데이터 전송시작 -> 브라우저가 google.com 을 요청함 (GET 메소드, 입력하거나 하는 경우는 POST 요청 등등 )
해당 요청(request)에는 브라우저 식별(user-agent헤더), 수락할 요청 유형(accept헤더), TCP 연결 유지를 위한 연결 헤더 같은 정보들이 포함.
해당 도메인의 쿠키 정보도 전달.

6. 서버가 요청 처리후 응답(Response)을 보냄.

웹 서버(ex-아파치 HTTP 서버)가 요청 수신 후 Request handler에 전달->응답 생성
Request handler는 요청, 헤더, 쿠키를 읽고 서버의 정보를 업데이트 하는 프로그램 - HET,PHP,Ruby,ASP 등의 포맷
응답(Response)를 JSON,XML,HTML 등의 포맷으로 작성

7. 서버가 HTTP 응답을 보냄.

해당 Response에는 요청 웹페이지, 상태 코드(status code), 압축 유형(Content-Encoding), 페이지 캐싱 방법(Cache-Control), 쿠키, 개인 정보 등이 포함됨.

📌 
  status code 유형
 - 100번대 (Information Response): 정보 메시지. 요청을 받았으며 작업을 계속한다는 뜻.
 - 200번대 (Successful Response): 요청이 성공해서 응답받음.
 - 300번대 (Redirection Message) : 리다이렉션 완료, 요청 완료를 위해 추가 작업 조치가 필요함.
 - 400번대 (Client Error Response) : 요청 오류, 클라이언트에 오류가 있음. 
 - 500번대 (Server Error) : 서버 오류, 유효한 요청을 수행 하지 못했음.

8. 브라우저가 HTML 컨텐츠를 보여줌.

브라우저는 응답 받은 HTML을 화면에 표시
- (1) HTML 골격 렌더링.
- (2) HTML 태그 확인 -> 이미지, CSS, JS파일 등 웹 페이지의 추가 요소에 대한 GET 요청을 보냄. (정적 파일들은 캐싱되고 이후 방문시 추가로 요청하지 않음)
- (3) www.google.com 페이지가 브라우저에 보여짐.