What happens when you type a URL into your browser?

URL을 브라우저에 입력했을 때 일어나는 과정을 딥하게 알아보자!

 

1. URL 파싱

브라우저는 입력된 URL을 해석하여 

프로토콜 / 도메인 네임 / 경로 / 쿼리 매개변수 등으로 분리한다.

브라우저는 URL에서 example.com 이라는 도메인 네임을 추출하고 이를 통해 DNS 쿼리가 시작된다.

 

 

2. DNS (Domain Name System) 조회

Domain Name은 사람이 이해하기 쉬운 주소지만, 컴퓨터는 IP 주소를 통해 통신한다.

DNS는 도메인 네임을 IP로 변환하기 위해 존재한다.

 

웹 브라우저는 DNS 서버에 검색하기 전에 캐싱된 DNS 기록을 먼저 확인한다.

캐시에 해당 정보가 없다면, 브라우저는 도메인을 IP 주소로 변환하기 위해 DNS 서버에 요청을 보낸다.

 

이 요청은 사용자의 ISP(Internet Service Provider)나 지정된 DNS 서버를 통해 이루어진다.

일반적으로는 ISP(ex. KT, SK 브로드밴드..) 를 통해 DNS 요청을 처리하지만,

인터넷에 직접 연결된 네트워크 환경(ex. 사설 네트워크, 기업 네트워크)에서는 ISP를 거치지 않고 지정된 DNS 서버에 직접 요청을 보낼 수 있다.

 

 

3. DNS Query와 계층적 탐색

도메인 이름을 IP 주소로 변환하기 위해 DNS 서버에 보내는 요청을 DNS query라고 한다.

DNS query는 현재 DNS 서버에 원하는 IP 주소가 존재하지 않으면 다른 DNS 서버를 방문하게 되고, 원하는 IP 주소를 찾을 때까지 반복한다.

 

URL은 계층화가 되어있는데, 역순으로 완벽한 주소를 찾아 이 주소에 해당하는 IP 주소를 매핑하게 된다.

역순으로 해당 도메인 이름에 맞는 지역 DNS를 탐색하며, root DNS 서버가 나올 때까지 거꾸로 탐색한다.

이와 같이 Local DNS가 여러 서버를 차례대로 물어봐서 답을 찾는 과정을 Recursive Query라고 부른다.

 

브라우저가 example.com의 IP 주소를 요청하면, 루트 DNS 서버로 쿼리를 보낸다.

루트 DNS 서버는 최상위에 있는 서버로, 모든 도메인의 최상위 계층인 TLD(.com, .net 등)에 대한 정보를 가지고 있다.

루트 서버는 '.com' TLD 서버의 위치를 알려준다.

이제 브라우저는 .com DNS 서버로 쿼리를 보낸다. .com DNS 서버는 .com 도메인에 속한 하위 도메인에 대한 정보를 가지고 있다.

이제 .com 서버는 example.com 도메인에 대한 네임 서버 위치를 반환한다.

이 네임 서버는 example.com의 IP 주소를 반환하게 된다.

[Root DNS] -> [.com DNS] -> [.example DNS] 

이를 통해 IP 주소가 바뀌어도 사용자들에게 똑같은 도메인 주소로 서비스 할 수 있다.

 

왜 역순으로 탐색하는가?

DNS 시스템은 계층적으로 나누어 관리함으로써 하나의 서버가 모든 도메인의 정보를 가지고 있을 필요가 없고, 
이를 통해 전 세계의 도메인 정보를 효율적으로 분산관리할 수 있다.

 

 

4. TCP 연결 및 HTTP 요청 전송

IP 주소를 얻은 브라우저는 웹 서버에 HTTP요청을 보낸다. HTTP 요청은 주로 HTML 문서를 요청한다.

TCP는 신뢰성을 확보하고 연결할 때 3-way handshake 작업을 진행하며, 4-way handshake 과정을 통해 연결을 해제한다.

참고로 TCP는 3-way handsahke 과정이 있기 때문에 신뢰성 있는 계층이라고 하며,
UDP는 이 과정이 없기 때문에 신뢰성이 없는 계층이라고 한다.

 

handshake는 여러 번의 네트워크 왕복을 요구하는데,

모던 브라우저는 keep-alive connection을 사용하여 가능한 한 많이 설정된 TCP 연결을 재사용하여 로딩 속도를 빠르게 유지하려고 한다.

 

 

4-1. 만약 프로토콜이 HTTPS 라면? -> SSL/TLS

프로토콜이 HTTPS 라면 새 연결을 설정하는 과정이 더욱 복잡해진다.

HTTP/2는 HTTPS 위에서 동작한다. HTTPS는 애플리케이션 계층과 전송 계층 사이에
신뢰 계층인 SSL/TLS 계층을 넣은 신뢰할 수 있는 HTTP 요청을 말한다.
이를 통해 '통신을 암호화'한다.

SSL(Secure Socket Layer) , TLS(Transprot Layer Security Protocol)

SSL/TLS은 전송 계층에서 보안을 제공하는 프로토콜이다. 

클라이언트와 서버가 통신할 때 SSL/TLS를 통해 제3자가 메시지를 도청하거나 변조하지 못하도록 한다.

 

프로토콜이 HTTPS라면 SSL/TLS 핸드쉐이크 과정이 필요하다.

이 핸드 쉐이크 과정은 비용이 많이 들어, 브라우저는 SSL 세션 재개 (SSL session resumption)와 같은 방법을 사용하여 비용을 줄이려 한다.

 

 

4-2. 서버의 리다이렉트 응답 처리 (필요 시)

서버가 클라이언트의 요청을 처리한 경우, 특정 상황에 따라 HTTP 상태 코드 3xx와 함께 리다이렉트 응답을 보낼 수 있다.

예를 들어 301 Moved Permanently, 또는 302 Found와 함께 새 URL이 Location 헤더에 포함된다.

브라우저는 이 리다이렉트 응답을 받으면 Location 헤더에 명시된 새 URL로 자동으로 다시 요청을 보낸다.

 

대표적인 상황으로는, HTTP에서 HTTPS로 강제 이동, URL 변경, 인증이 필요한 페이지일 시 로그인 페이지로 이동시키는 상황이 있다.

 

 

5. WAS (Web Application Server) 의 역할

웹 서버 혼자서 모든 로직 처리 및 데이터 관리를 하면 서버에 과부하가 일어날 수 있으므로, WAS가 이를 분담하여 동적 요청을 처리한다.

WAS는 미들웨어로서 웹 서버와 데이터베이스 사이에서 동적 콘텐츠 요청을 처리한다.

웹 서버는 정적인 콘텐츠(html, css, 이미지 등)를 직접 제공하지만, 동적 콘텐츠가 필요할 때는 WAS에게 처리를 요청한다.

 

 

6. HTTP 응답과 상태 코드

WAS의 처리 결과가 웹 서버에 전달되면,

웹 서버는 브라우저에게 최종 HTML 문서와 요청한 데이터를 반환한다.

이때 HTTP 응답에는 status code가 포함되어 서버 요청에 따른 결과 및 상태를 전달한다.

종종 자바스크립트 번들 및 이미지와 같이 로드할 추가 리소스가 있는 경우가 있다.
브라우저는 앞서 언급한 DNS 조회, TCP 연결 설정, HTTP 요청 과정을 다시 수행하여 리소스를 가져온다.

 

 

7. 브라우저 렌더링

브라우저는 서버에서 받은 HTML 문서를 렌더링하며, CSS 및 JavaScript 파일 등을 추가로 불러와 웹 페이지를 완성한다.

자세한 브라우저 렌더링 과정은 따로 정리할 예정이다.

 

 

ref

https://www.youtube.com/watch?v=AlkDbnbv7dk

https://www.youtube.com/watch?v=YahjHM9UNCA

https://velog.io/@tnehd1998/%EC%A3%BC%EC%86%8C%EC%B0%BD%EC%97%90-www.google.com%EC%9D%84-%EC%9E%85%EB%A0%A5%ED%96%88%EC%9D%84-%EB%95%8C-%EC%9D%BC%EC%96%B4%EB%82%98%EB%8A%94-%EA%B3%BC%EC%A0%95#1-wwwgooglecom-%EC%9E%85%EB%A0%A5%ED%95%98%EB%A9%B4-%EC%9E%85%EB%A0%A5%ED%95%9C-url-%EC%A3%BC%EC%86%8C-%EC%A4%91-%EB%8F%84%EB%A9%94%EC%9D%B8-%EC%9D%B4%EB%A6%84%EC%97%90-%ED%95%B4%EB%8B%B9%ED%95%98%EB%8A%94-googlecom%EB%A5%BC-dns-%EC%84%9C%EB%B2%84%EC%97%90%EC%84%9C-%EA%B2%80%EC%83%89%EC%9D%84-%ED%95%A9%EB%8B%88%EB%8B%A4

면접을 위한 CS 전공지식 노트 - 네트워크 파트