브라우저에 url을 입력하고 Enter를 치면 벌어지는 일

예전에 봤던 프론트엔드 직군의 단골질문이다. 
"대충 url잘 뒤져서 서버찾아서 가서 받아오겠지" 말고 좀 더 구체적으로 무슨 일이 일어나는지를 하나하나 따라가보자.

1. 주소창에 주소를 입력

 

 

2. 주소형식인지 아닌지 판단해 검색 or 이동 

url 구조를 파악해 어떤 프로토콜로 어떤 도메인에 어떤 path로 접근하는지 파악한다.

url 구조에 맞지 않는다면 해당 브라우저의 검색엔진으로 input값을 검색한다.

 

 

 

3. Https 를 위한 HTST Preload List 탐색 

http로 접속 요청을 하면 보통 서버에서 https로 리다이렉트된다. 안전한 접속을 위해 요새는 거의 https를 쓴다.

근데 처음 저 http 접속 과정에서 man in the middle해킹이 가능하다고 한다. 이를 방지하기 위해 HTST(Http Strict Transport Security) 헤더를 사용한다. 이 서버는 https로만 접속할 수 있다고 알려주는 응답헤더이며 이 헤더가 있으면 첫 접속 이후 정해진 기간동안은 브라우저가 무조건 해당 서버를 https로만 접속한다.

 

 근데 또 첫 접속은 http일 수 있다는 것이 문제가 된다. 그래서 정해진 가이드를 준수하는 사이트에 한하여 브라우저가 자체적으로 HTST Preload List를 운영한다. 한번도 방문한 적 없는 사이트라도, 이 리스트에 등록된 곳은 https로만 접속할 수 있다. 

 

*man in the middle  *HSTS 등 따로 공부해볼 항목이 많다.

 

 

 

 

4. 도메인을 이용해 ip 찾기 (DNS)

DNS(도메인 네임을 ip 주소로 변환해주는 프로토콜) 을 이용해 ip를 찾는다.

 

먼저 재귀 DNS서버에서 DNS 캐시를 먼저 확인한다. 캐시가 있으면 바로 그 ip주소를 반환한다.

없다면 재귀 DNS는 순차적으로 다음에 쿼리를 날려 ip를 알아낸다.

쿼리 전송과 응답은 모두 기본적으로 UDP를 사용하고 DNS 전용 포트인 53를 사용한다. 용량이 크다면 TCP를 사용하기도 한다.

 

1. Root name server

2. Top Level Domain (kr, com..)

3. 이후 여러 Authoritative name server

 

 

* 알아낸 ip는 리스폰스 메시지에 있는 TTL만큼 캐시된다

* 공부하다 보니 아래에 서술한 ARP는 이 단계에서 DNS쿼리를 보낼 때도 사용된다. 쿼리는 아마 다른 subnet에 전송되어야 할 것이므로 처음 송신자가 자기 subnet의 Gateway 라우터의 mac주소를 찾아내려고도 사용할 수 밖에 없다.

(컴퓨터 네트워킹 하향식접근 462p 참고)

 

 

 

 

5. ip를 이용해 mac주소 찾기 (ARP)

먼저 찾으려는 곳의 subnet을 확인해서 같은 subnet 안에 있는지 확인한다. 

* 다른 subnet 에 있다면 포워딩을 이용해 목적지로 더 이동해서 ARP를 해야 최종 목적지의 mac 주소를 알아낼 수 있다.

 

같은 subnet에 있다면 ARP(ip 주소 값으로 mac주소 값을 찾아주는 프로토콜)로 물리주소를 찾는다. ARP 과정은 다음과 같다.

송신자가 같은 subnet상의 모든 호스트에게 ARP Request를 브로드캐스트 (Destination MAC = FF:FF:FF:FF:FF:FF)한다.

Request안에 있는 ip를 사용하고있는 호스트나 라우터가 자신의 mac주소를 ARP Reply에 담아 송신자에게 유니캐스트로 보낸다.

 

 

 

 

6. HTTP GET메시지 전송을 위한 TCP 소켓 연결을 위한 3way handshaking

 

 

 

 

7.  HTTPS 통신을 위한 SSL handshaking

대칭키는 간단하지만 키 탈취의 위험이 있고, 공개키는 보다 안전한 대신 암호와 복호에 시간이 많이 소요된다.

그래서 공개키를 이용해 대칭키만 암호화 해서 안전하게 공유하고, 이후는 대칭키로 정보를 주고받는다.

추가로 서버가 믿을만한지를 위해 제3자인 CA의 도움으로 SSL인증서를 통해 더 안전하게 통신할 수 있다.

 

 

출처: https://minix.tistory.com/397

 

 

 

8. http 요청 및 응답

드디어 https 통신을 위한 기반이 모두 마련이 되었다.

이제 정말로 서버에 HTTP GET 메소드로 해당 주소에 대한 요청을 한다. 처음에는 헤더에 path 없이 Get요청을 하면, 기본 요청으로 index.html 이 응답으로 넘어오게 된다. 그 다음 해당 html을 파싱하면서 외부 리소스를 추가적으로 요청한다. 

 

 

 

 

9. 렌더링

html을 파싱하면서 DOM을 구성하고 CSSOM을 구성하고 최종적으로 렌더트리를 그린다.

이 부분은 따로 자세히 정리하는 편이 좋을 것 같아 다음 포스팅거리로 남겨두겠다.

 

 

 

 

참고한 포스팅

https://velog.io/@directorhwan59/%EC%9B%B9-%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A0%80%EC%97%90-URL%EC%9D%84-%EC%9E%85%EB%A0%A5%ED%95%98%EA%B3%A0-%EC%B2%AB-%ED%99%94%EB%A9%B4%EC%9D%B4-%EC%B6%9C%EB%A0%A5%EB%90%98%EA%B8%B0%EA%B9%8C%EC%A7%80

웹 브라우저에 URL을 입력하고 첫 화면이 출력되기까지

https://minix.tistory.com/397

[웹툰04] SSL이란 무엇인가? 2/2

https://wonjaetech.tistory.com/entry/%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A0%80%EC%9D%98-%EB%A0%8C%EB%8D%94%EB%A7%81-%EA%B3%BC%EC%A0%95

브라우저의 렌더링 과정