Today's topic
지난 post에서는 browser 내 rendering engine 작동원리에 중점을 두고 browser를 설명하였다면, 이번 post에서는 실제로 주소창에 google.com을 입력하였을 시 발생하는 전반적인 process에 대해 다루어 보고자 한다.
👉 Process
1️⃣ google.com을 주소창에 입력 후 Enter
2️⃣ Browser는 cashing된 DNS 기록을 통해 google.com에 대응하는 IP주소 여부 확인
3️⃣ 요청한 URL이 cashing 된 DNS에 없으면, ISP의 DNS 서버가 DNS query를 날림 (google.com을 호스팅하고 있는 서버의 IP 주소를 찾기 위해)
4️⃣ Browser가 server와 TCP connection
5️⃣ Browser가 webserver에 HTTP request
6️⃣ WebServer가 request를 처리하고 response 생성
7️⃣ WebServer가 response 보냄
8️⃣ Browser가 HTML content를 화면에 보여줌
1️⃣ google.com을 주소창에 입력 후 Enter
Browser 주소 창에 google.com를 입력
2️⃣ Browser는 cashing된 DNS 기록을 통해 google.com에 대응하는 IP주소 여부 확인
DNS는 Domain Name System의 약자로 URL들의 이름과 IP 주소를 저장하고 있는 DB이다. 또한 DNS는 사람들이 웹사이트 주소에 쉽게 접속할 수 있게 매핑을 해주는 역할을 한다.
Browser는 DNS 기록을 4가지 cash에서 확인한다,
- Browser cash
Browser는 일정기간 동안(유저가 이전에 설정한)의 DNS 기록들을 저장하고 있다. DNS query가 이 곳에서 가장 먼저 실행이 된다.- OS cash
Browser cash에 해당 website의 IP주소가 발견되지 않았다면, browser는 systemcall을 통해 OS가 저장하고 있는 DNS 기록들의 cash에 접근- Router cash
Computer 내에서 DNS 기록을 찾지 못하면, browser는 DNS 기록을 캐싱하고 있는 router와 통신을 해서 찾기 시도- ISP cash
마지막 수단으로 ISP cash 확인함. ISP는 DNS server를 구축하고 있기에 browser가 마지막으로 DNS 기록이 있기를 바라며 접근
❗️ 여러 가지 cash에 저장하는 것이 불편할 수도 있으나, 캐시는 네트워크 트래픽을 조절하고 데이터 전송 시간을 줄이기 위해 매우 중요함.
3️⃣ 요청한 URL이 cashing 된 DNS에 없으면, ISP(Internet Service Provider)의 DNS 서버가 DNS query를 날림 (google.com을 호스팅하고 있는 서버의 IP 주소를 찾기 위해)
해당 url에 접근하기 위해서는 IP주소를 알아야 함. 그러기 위해 DNS에 matching되는 IP 주소가 없으면 다른 DNS 서버에서라도 찾기 위해 DNS query를 날린다.
이 때 ISP의 DNS server를 DNS recursor라고 함
4️⃣ Browser가 server와 TCP connection
- Browser는 올바른 IP 주소를 받게 되면 인터넷 프로토콜을 통해 서버와 연결 된다. HTTP 요청의 경우에는 일반적으로 TCP를 사용함.
- Client와 server간 데이터 패킷들이 오가려면 TCP connection이 되어야 하는데, TCP/IP three-way handshake라는 프로세스를 통해서 client와 server간 connection 됨.
(Client와 server가 SYN과 ACK메세지들을 가지고 3번의 프로세스를 거친 후에 연결됨)
1. 클라이언트 머신이 SYN 패킷을 서버에 보내고 connection을 열어달라고 물어봄
2. 서버가 새로운 connection을 시작할 수 있는 포트가 있다면 SYN/ACK 패킷으로 대답함
3. 클라이언트는 SYN/ACK 패킷을 서버로부터 받으면 서버에게 ACK 패킷을 보냄
5️⃣ Browser가 webserver에 HTTP request
- TCP로 연결이 되었다면, data 전송
- Client의 browser는 GET 요청을 통해 서버에게 google.com 웹페이지를 요구한다. 요청을 할 때 비밀 자료들을 포함하거나 form을 제출하는 상황에서는 POST 요청을 사용할 수도 있다. 이 요청을 할 때 다른 부가적인 정보(헤더, 쿠키 정보)들도 함께 전달됨.
6️⃣ WebServer가 request를 처리하고 response 생성
- 서버는 webserver를 가지고 있음(ex. Apache, IIS, etc.)
- 이들 webserver는 browser로부터 요청을 받고 request handler(ASP.NET, PHP, Ruby 등으로 작성된 프로그램)한테 요청을 전달해서 요청을 읽고 response를 생성함.
- 이 request handler는 요청과 요청의 헤더, 쿠키를 읽어서 요청이 무엇인지 파악하고 필요하다면 서버에 정보를 업데이트함.
- 그 다음에 response를 특정한 포맷(JSON, XML, HTML)으로 작성함.
7️⃣ 서버가 HTTP response를 보냄
- 서버의 response에는 요청한 웹페이지, status code, compression type(Content-Encoding), Cache-Control, 쿠키, 개인정보 등이 포함.
- response의 첫줄은 status code를 나타내는데, status code란 현재 response의 상태를 의미하고 총 5가지의 종류가 있음
1️⃣ 1xx - 정보만 담긴 메세지라는 것을 의미
2️⃣ 2xx - response가 성공적이라는 것을 의미
3️⃣ 3xx - Client를 다른 URL로 리다이렉트함을 의미
4️⃣ 4xx - Client 측에서 에러가 발생했음을 의미
5️⃣ 5xx - 서버 측에서 에러가 발생했음을 의미
8️⃣ Browser가 HTML content를 화면에 보여줌
Browser는 HTML content를 단계적으로 보여줌
1️⃣ HTML의 스켈레톤을 렌더링(❗️지난 포스팅 참조)
2️⃣ HTML tag들을 체크
3️⃣ 추가적으로 필요한 웹페이지 요소들(이미지, CSS 스타일시트, Javascript 파일, 등)을 GET으로 요청
4️⃣ 이 정적인 파일들은 브라우저에 의해 캐싱이 되서 나중에 해당 페이지를 방문할 때 다시 서버로부터 불러와지지 않도록 함
5️⃣ google.com 화면이 보이게 됨
📖 출처
https://devjin-blog.com/what-happen-browser-search/
https://d4-project.org/2020/03/06/analyzer-d4-isn.html
My opinion
지난 번 posting에서는 렌더링에 중점을 두었다면 이번 posting에서는 url 입력 후 전체적으로 이뤄지는 반응에 대해 알아 보았다. 순식간에 이러한 work 들이 이루어 지는게 공부 하면 할 수록 더 놀랍게 된다.
