브라우저에 www.naver.com을 입력하면 어떤 방식으로 동작해서 사용자가 naver의 메인 페이지를 볼 수 있게 되는걸까요??
브라우저 구조
사용자 인터페이스 - 주소창 입력, 뒤로 가기 버튼 등 절대 바뀌지 않는 요소 (요청한 페이지를 보여주는 창을 제외한 나머지 부분)
렌더링 엔진 - 사용자에게 보이는 웹사이트를 그리는 엔진
브라우저 엔진 - 사용자 인터페이스와 렌더링 엔진 사이의 동작 제어 (사용자가 뒤로 가기 버튼을 누르면 이 행동을 인식해서 렌더링 엔진에게 알려주는 역할)
통신 - 웹사이트 호출 등을 담당하는 네트워크 엔진 (개발자 도구에서 네트워크가 해당)
자바스크립트 해석기 - 자바스크립트 코드를 해석하고 실행 (크롬에서는 v8엔진 사용)
UI 백엔드 - 사용자 입력, 마우스 움직임 등을 핸들링
자료 저장소 - 로컬 스토리지, 세션 스토리지, 쿠키 등 브라우저가 필요로 하는 자료를 저장
URL은 입력했을 때의 동작 방식과 원리
1. 주소창에 www.naver.com 을 입력
브라우저는 www.naver.com을 인식하는데 이때 naver.com을 이해하지 못하고 ip주소를 이해합니다.
따라서 브라우저는 naver.com에 해당하는 ip 주소를 찾기 위해 URL을 분석합니다.
- url은 크게 프로토콜 | 도메인 | 경로 | 쿼리 스트링 으로 구성되어 있습니다.
2. URL을 기반으로 ip 주소 찾기
2-1. 처음에는 브라우저, 운영체제 캐시에서 dns 기록을 확인합니다. (브라우저 캐시 ⇒ OS DNS 캐시 ⇒ host 파일)
2-2. 만약 캐시가 존재하지 않는다면, DNS Resolver에게 물어봅니다.
2-3. Resolver는 단계적으로 DNS 계층에게 물어봅니다.
- 루트 네임 서버에 질문 (.com 도메인에 대한 정보를 알고 있는 서버 어디야?)
- .com 네임서버에 질문 (naver.com 도메인을 관리하는 네임서버는 어디야?)
- naver.com에 권한이 있는 네임서버에게 질문(naver.com에 해당하는 ip 주소 뭐야?)
3. 얻은 ip 주소를 기반으로 해당 서버와 tcp 연결 시작 (3way-handskake)
3-1. client 가 server로 syn패킷을 보냅니다.
3-2. server가 client로 syn-ack 패킷을 보내 응답합니다.
3-3. client가 server로 ack 패킷으로 응답하여 연결을 확립합니다.
3way-handskake
정확한 전송을 보장하기 위해 1) 서버가 실제로 연결 가능한지 확인, 2) 데이터의 순서를 보장하기 위한 준비, 3) 혼잡/흐름 제어 준비를 위한 목적으로 수행
그렇다면 왜 udp 연결이 아닌 tcp 기반으로 연결을 할까요? ⇒ tcp와 udp의 차이점을 보면 알 수 있습니다.
| tcp | udp | |
|---|---|---|
| 연결 방식 | 연결형 서비스 | 비연결형 서비스 |
| 전송 순서 | 전송 순서 보장 | 전송 순서가 바뀔 수 있음 |
| 수신 여부 확인 | 확인함 | 확인하지 않음 |
| 통신 방식 | 1:1 통신 | 1:1 or 1:n or n:n |
| 속도 | 느리다 | 빠르다 |
| 신롸성 | 높다 | 낮다 |
- 신뢰성 보장 - 전송한 데이터가 손실되지 않도록 보장하기 때문에 만약 “로그인” 요청을 보냈는데 응답이 없으면 추후 로직을 처리하는 처리기를 달아줄 수 있음
- 데이터 순서 보장 - HTTP는 문서, 이미지, HTML 등이 정해진 순서대로 로드됨 ⇒ 웹페이지가 엉망으로 로딩되는 것을 방지
- 혼잡 제어, 흐름 제어 - 네트워크 상태를 감지해서 속도를 조절하기 때문에 network 붕괴를 방지
4. https 의 경우 통신 내용 암호화를 위해 ssl/tls 핸드쉐이크를 통해 보안 연결을 설정
4-1. client hello : client가 server에 연결을 시도하며 전달하는 패킷입니다. 자신이 사용 가능한 Cipher Suite 목록, Session ID, SSL 프로토콜 버전, Random Byte 등을 전달합니다.
- Cipher Suite는 SSL 프로토콜 버전, 인증서 검정, 데이터 암호화 프로토콜, Hash 방식 등의 정보를 담고 있는 존재로, 선택된 Cipher Suite의 알고리즘에 따라 데이터를 암호화하게 된다.
4-2. server hello : Client hello 패킷을 받아 Cipher Suite 중 하나를 선택한 뒤, 클라이언트에게 알리는 방식 + server의 ssl 인증서도 같이 보냅니다.
4-3. certificate : ssl 인증서 내부는 서버의 공개키와 함께, CA가 발급했다는 서명이 포함된 구조입니다. 따라서 클라이언트는 CA의 이름을 보고 본인이 신뢰하는 CA인지 확인한 후, 브라우저에 내장된 CA 공개키로 서명을 검증하고, 검증이 성공하면 인증서를 신뢰할 수 있다고 판단합니다.
4-4. Client Key Exchange : client는 데이터 암호화에 사용할 대칭 키를 생성한 후 SSL 인증서 내부에서 추출한 서버의 공개 키를 이용해 암호화한 후 서버에게 전달합니다. 이때 전달된 대칭 키가 ssl handshake의 목적이며 서로 메세지를 교환할 때 데이터를 암호화합니다.
4-5. 4-2단계에서 서버가 클라이언트 인증서를 함께 요구했다면, 클라이언트의 인증서와 클라이언트의 개인키로 암호화된 임의의 바이트 문자열을 함께 보내줍니다.
4-6. 서버는 클라이언트의 인증서를 확인 후, 난수 바이트를 자신의 개인키로 복호화 후 대칭 마스터 키 생성에 활용합니다.
4-7. 클라이언트는 handshake 과정이 완료되었다는 finished 메시지를 서버에 보내면서, 지금까지 보낸 교환 내역들을 해싱 후 그 값을 대칭키로 암호화하여 같이 담아 보내줍니다.
4-8. 서버도 동일하게 교환 내용들을 해싱한 뒤 클라이언트에서 보내준 값과 일치하는 지 확인합니다. 일치하면 서버도 마찬가지로 finished 메시지를 이번에 만든 대칭키로 암호화하여 보내줍니다.
5. 연결 확립, 보안 설정까지 끝냈으니 client에서 server 로 http request요청을 보냄
6. Server 에서 요청을 받으면 정적 문서를 생성하여 Client로 http response를 보내줌
6-1. 웹서버가 요청을 수신합니다.
6-2. 웹서버가 동적 요청을 WAS로 전달해줍니다.
6-3. WAS가 DB에 요청합니다.
6-4. DB 결과 데이터를 WAS로 반환하고, WAS 는 이 데이터를 바탕으로 응답 데이터를 생성합니다.
6-5. WAS가 완성된 HTML 또는 JSON 등 결과 응답 객체를 웹서버에 전달합니다.
6-6. 웹서버가 받은 결과를 HTTP 응답 바이트 스트림으로 만들어 http response를 브라우저로 보내줍니다.
7. 브라우저가 렌더링 과정을 통해 응답 받는 html을 렌더링하고, html 컨텐츠를 보여줍니다.
7-1. 웹 엔진의 HTML파서가 문서를 파싱해 DOM tree로, CSS 파서가 CSSOM 트리를 생성합니다.
7-2. 생성된 DOM과 CSSOM으로 렌더링 트리를 생성합니다. (렌더링 트리 : 렌더링하는데 필요한 노드만 선택해 페이지를 렌더링 하는데 사용)
7-3. 레이아웃 단계를 거칩니다. 레이아웃 단계란 렌더링 트리에서 위치나 크기를 알 수 없기 때문에 객체들에게 위치, 크기 등을 정해주는 과정입니다.
7-4. 페인팅 단계를 거칩니다. 렌더링 트리의 각 노드를 실제 픽셀로 변환하고 실제로 그리는 작업입니다.
참고 자료
