1 단계 : 우리가 브라우저 주소창 내용을 입력하면 어떻게 될까?
웹 브라우저는 당신이 원하는 것이 무엇인지 알고 있다.
웹 브라우저는 사용자가 주소 표시줄에 입력한 내용이 URL인지 검색어인지 확인하여 그게 알맞은 인터페이스를 보여준다. 검색어일 경우에는 바로 설정된 검색 엔진으로 검색하는 기능을, 그리고 사이트인 경우에는 해당 사이트로 넘어갈 수 있도록 조치해준다.
이 과정에서, 브라우저는 미리 준비된 DNS 혹은 서버와 통신함으로써 해당 내용이 URL인지 확인해낸다.
(주소창에 입력 된 내용을 준비된 서버로 보내 내용이 URL인지 검색어인지 확인)
2단계 : 사이트의 진짜 주소를 알아낸다.
페이지의 모든 데이터들은 서버에서 오고, 그 서버는 IP주소로 되어있다.
하지만, 18.67.51.57 이런식으로 구성되어있는 IP주소는 인간 친화적이지 않고 외우기가 너무 어렵다. 오른쪽에 있는 사진은 내가 최근에 완료한 프로젝트 42mogle.com에 패킷을 날리는 명령어를 찍은 것이다.
분명히 나는 42mogle.com에 ping을 날렸지만, 돌아오는 대답은 18.67.51.57로부터 온다.
즉, 42mogle.com은 가명이고 진짜 이름은 저 아이피인 것이다! (놀랍지 않은가?)
가명을 쓰면 무엇이 좋을까?
우리가 Google.com을 외우는 것이 쉬울까? 아니면 172.217.161.46를 외우는 것이 쉬울까?
아주 간단한 문제이다. 사용자가 외우기 쉽게 하기 위해서 만들어진 것이다.
그렇다면, 이 사이트 주소들은 어디에 저장되어있는가? 이들은 DNS(Domain Name Server)이라는 곳에 저장되어있다.
이 서버 안에서 각각의 사이트들은 자신의 진짜 주소인 IP주소와 매칭되어있다. (Google.com : 172.217.161.46)
그렇기 때문에, 웹 브라우저는 해당 사이트로 접근하기 전에, DNS에 접근하여 그 사이트의 진짜 주소 알아낼 수 있다.
그리고 이렇게 알아낸 주소는 우리가 해당 사이트에 접근하는 것에 사용된다.
3단계 : 사이트와의 연결을 구축한다(HTTPS)
그렇게 도착한 주소는 과연 안전할까? 해당 아이피까지 가는 길에 나의 패킷은 중간에 강도당하지 않았을까? HTTP로 연결하면 보안을 위한 절차가 생략되어있기 때문에 내 패킷이 제대로 된 곳으로 도착했는지 알 수 없다.
그렇기 때문에, 현재 대부분의 사이트들은 HTTPS라는 프로토콜을 이용, 사이트 - 클라이언트 간 소통을 안전하게 만들어준다.
그렇다면 이 HTTPS는 어떤 것들이 특별할까?
1. HTTPS를 이용하면 개인정보 보호가 가능하다. 즉, 내가 서버로 보내는 내용을 남이 가로채서 읽을 수 없다.
2. 무결성이 보장된다! 내가 서버로 보내는 내용을 가로챌 수 없기 때문에 내가 보낸 내용과 서버가 받는 내용이 동일함을 보장한다.
3. 식별이 가능하다. TLS(옛 이름 : SSL)을 통해 내가 받은 데이터가 내가 생각하는 곳에서 왔음을 보장한다.
이렇게 좋은 것이 있다면, 당연히 해야겠지만 과연 이 장점들은 어떻게 만들어지는 것일까?
그것은 해당 글에서 계속
이렇게 핸드쉐이크 등등 여러 방법을 통해 얻어낸 신뢰는 이 브라우저 탐색의 다음단계로 이어진다.
4단계 : 사이트에서 보낸 응답을 확인한다.
사이트의 진짜 주소도 알았고, 그 녀석과 안전한 통신망도 구축했다.
이제는 그 서버에게 내가 원하는 것을 요구할 차례이다.
내 클라이언트에서 출발한 패킷은 높은 확률로 서버의 80(HTTP) 혹은 443(HTTPS)포트로 향할 것이고 그 포트를 통해 자극받은 서버는 정해진 규칙에 따라 데이터를 클라이언트에게 보내줄 것이다.
이렇게 서버가 내용을 보내주면 클라이언트는 그 내용이 진짜 어떤 내용인지 확인한다.
일반적으로 그쪽에서 보내준 데이터에는 자신이 어떤 데이터라고 표시되어있지만, 브라우저는 이를 확인하기는 하지만 완전히 믿지는 않는다.(정보가 없거나, 잘못된 정보가 있을 가능성을 대비하기 위하여)
그렇게 브라우저는 아래에 있는 내용을 조금 살펴본다.
안에 있는 내용이 렌더링 엔진이 처리할 수 있는 내용이라고 판명되면(HTML,CSS 등) 해당 내용을 렌더러 프로세스에게 전달한다. 하지만, 해당 내용이 PDF이거나 ZIP과 같은 파일일 경우 해당 파일 내용에 맞는 방식을 취한다. PDF일 경우 문서를 바로 표시하고, ZIP일 경우에는 다운로드 매니저를 실행시킨다.
또한, 브라우저는 이 과정에서 CORB 기능도 작동한다 (당신이 자주 보던 CORS의 Cross-Origin Read가 맞다!)
5단계 : 그릴 준비를 완료한다.
인터페이스 프로세스는 우리가 주소창에 엔터를 누르는 순간부터 미리 렌더러 프로세스를 준비시켜놓는다.
분명 사이트를 옮길 것이지만, 네트워크 통신은 (상대적으로) 긴 시간을 요구하기 때문에, 미리미리 렌더러 프로세스를 준비시켜놓음으로써 그 응답이 도착하는 대로 상태에따라 바로 그릴 수 있도록 준비하는 것이다. 이렇게 미리 렌더러 프로세스를 준비해놓지 않으면, 데이터를 받고도 렌더러 프로세스가 준비되기를 기다려야되기 때문에 웹브라우저를 만든 프로그래머들은 미리미리 해놓는 효율적인 최적화를 진행시켜두었다.
마침내, 이렇게 확인이 완료된 데이터는 미리 준비하고 있던 렌더러 프로세스에게 넘겨진다.(이 과정은 IPC를 통해 이루어진다. 둘 다 프로세스니까!)
이 과정에서, 주소 표시줄에 있는 내용도 업데이트가 된다.
보안표시가 업데이트되며(HTTPS면 잠금 표시 아니면 깨진 잠금!) 사이트 주소도 변경된다. 또한, 뒤로가기 버튼이 활성화되며 이전 사이트의 정보를 담고 있으며 해당 세션이 닫히더라도 나중에 다시 킬 수 있도록 세션 기록도 드라이브에 저장된다.
이런 과정을 거치면 드디어 웹브라우저는 렌더러 프로세스를 이용, 화면에 내용을 그리기 시작한다.
드디어 웹 브라우저가 화면을 그리는 내용이 이어진다.
다음 글에서 계속
'개발 공부 > WEB의 심연' 카테고리의 다른 글
| RFC7230 요약(HTTP 아키텍처) (1) | 2023.03.12 |
|---|---|
| 끝까지 파보는 HTTPS (0) | 2022.12.05 |
| 브라우저는 어떻게 작동하는가? (브라우저의 프로세스) (0) | 2022.12.05 |
| 브라우저는 어떻게 작동하는가? (0) | 2022.12.05 |