[Network] URI + 웹 브라우저 요청 흐름

해당 포스팅은 김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식 강의를 토대로 작성되었습니다.

 

개요

이번 포스팅에서는 URI가 무엇인지, 그리고 웹 브라우저 요청 흐름이 어떻게 흘러가는지에 대해서 알아보려고 한다. 웹 브라우저 요청 흐름은 대충 어느정도인지 아는데 이번 기회에 한번 쪼꼼 더 자세하게 정리해보려고 한다.

 

URI, URL, URN?

URI는 Uniform Resource Identifier 의 약자이며 Resource를 식별하는 통합된 방법이다.

Uniform은 리소스를 식별하는 통일된 방식, Resource는 자원을 의미하며 URI로 식별할 수 있는 모든 것을 의미한다. dentifier는 다른 항목과 구분하는데 필요한 정보이다.

 

 

URI, URL, URN

 

URI는 Locator(URL)과 Name(URN) 또는 둘다 추가로 분류될 수 있다. URI는 사람들을 주민번호로 식별할 수 있듯이 자원이 어디에 있는지 자원 자체를 식별하는 방법이다.

 

URI는 크게 2가지로 나눌 수 있는데 URL과 URN이다. 예를 들어 필자는 이강욱인데 이강욱이 어디 살고있는지 찾아가는 것은 URL이고, 이강욱 그 자체는 URN 이라고 할 수 있다.

 

 

위의 사진에서 윗줄은 URL, 아랫줄은 URN을 의미하는데 보통 URL을 주로 사용한다.

 

URL (Uniform Resource Locator)

리소스가 있는 위치를 지정하는 것

 

URN (Uniform Resource Name)

리소스에 이름을 부여하는 것

ex) urn:isbn:891029381321

 

위치는 변할 수 있지만, 이름은 변하지 않는다. 그리고 URN 만으로 실제 리소스를 찾을 수 있는 방법이 보편화 되지 않아서 URL을 주로 사용한다. 따라서 앞으로는 URI와 URL과 거의 동일한 개념이라고 생각하면 될 것 같다.

 

URL을 분석해볼까?

 

https://www.google.com/search?q=hello&hl=ko

 

URL의 전체 문법은 다음과 같다.

scheme://[userInfo@]host[:port][/path][?query][#fragment]

 

위의 구글 링크를 분리해보면 이렇게 분리할 수 있을 것 같다.

- 프로토콜: https

- 호스트명: www.google.com

- 포트번호: 443

- path: /search

- query-parameter: q=hello&hl=ko

 

(1) scheme

- 주로 프로토콜을 사용한다.

- 프로토콜: 어떤 방식으로 자원에 접근할 것인가 하는 약속 및 규칙을 의미한다. 대표적으로는 http, https, ftp 등이 있다.

- http는 80번, https는 443번을 주로 사용하고 포트는 생략 가능하다.

- https는 http에 보안을 추가한 것이다.

(2) userInfo

- URL에 사용자 정보를 포함해서 인증하는 것.

- 거의 사용하지 않는다.

(3) host

- 호스트명

- 도메인 명 및 IP주소를 입력할 수 있다.

(4) Port

- 포트 번호

- 접속 포트

- 일반적으로는 생략한다. 생략 시 http는 80번, https는 443번이다.

(5) Path

- 리소스 경로(path), 계층적 구조

- /home/file1.jpg, /members, /members/100 ...

(6) Query

- key=value 형태

- ?로 시작하고, &로 추가할 수 있다.

- query-parameter, query-string으로도 불리고, 웹서버에 제공하는 파라미터라고 할 수 있다.

- 문자 형태로 전달된다. (예를들어 ?userId=10 이라고 해도, 10은 문자열로 애플리케이션에 전달이 된다)

(7) Fragment

- 잘 사용하지는 않음.

- HTML 내부 북마크 등에서 사용한다.

- 서버에 전송하는 정보는 아님.

 

 

웹 브라우저의 요청 흐름

강의의 내용에 덧붙여서 조금 더 깊이 알고 싶다는 생각이 들어서 추가로 공부해보고 정리해보려고 한다.

브라우저에 www.google.com  을 입력한다고 가정해보자.

 

 

아래의 글들은 khy226님의 브라우저에 url을 입력하면 어떤일이 벌어질까? 내용을 참고한 글입니다. 하트도 많이 눌리고 글의 퀄리티가 좋은 것 같아 한번씩 확인해보면 좋겠습니다.

브라우저에 url을 입력하면 어떤일이 벌어질까?

 

(1) 브라우저 주소창에 www.google.com을 입력한다.

 

(2) 브라우저가 www.google.com의 IP주소를 찾기 위해 Cache에서 DNS 기록을 확인한다.

DNS는 이전 포스팅에서 정리했듯이 전화번호부 같은 느낌이다. DNS에 대해서는 설명하지 않도록 하겠다. 참고로, 터미널에서 "nslookup www.google.com" 입력해보면 IP주소를 확인할 수 있다.

 

이전 포스팅의 DNS에서 조금 더 나아가보겠다. DNS Record를 찾기 위해서 브라우저는 4개의 Cache를 확인한다.

 

- DNS 쿼리는 먼저 브라우저 Cache를 확인한다. 브라우저는 내가 이전에 방문한 웹 사이트의 DNS 기록을 일정 기간동안 저장하고 있다.

- 브라우저는 OS캐시를 확인한다. 위의 브라우저 캐시에 원하는 DNS Record가 없으면 브라우저가 내 OS에 System call을 통해 DNS Record를 가져온다. (물론 OS도 DNS 레코드 캐시를 저장하고 있다)

- 브라우저는 Router Cache를 확인한다. 만약 PC에도 원하는 DNS Record가 없다면 브라우저는 Router에서 DNS Record를 저장한 Cache를 확인한다.

- 마지막으로는 ISP Cache를 확인한다. 위 3단계에서 DNS Record를 찾지 못한다면 브라우저는 ISP에서 DNS Record를 찾게 된다. 참고로 ISP는 Internet Service Provider의 약자로 DNS 서버를 가지고 있는데 해당 서버에서 DNS Record Cache를 검색할 수 있다.

 

Caching된 정보는 보안적으로 위험할 수 있다고 생각될 수 있지만 Network Traffic을 규제하고 데이터 전송 시간을 개선하는데 필수적이라고 할 수 있을 것 같다.

 

(3) www.google.com이 Cache에도 없다면 ISP의 DNS 서버가 DNS 쿼리로 www.google.com을 호스팅 하고 있는 서버의 IP주소를 찾아준다.

먼저, 내 PC가 www.google.com을 호스팅하는 서버와 연결하려면 구글의 IP주소가 필요하다. 위에서 언급한 DNS 쿼리의 목적은 웹 사이트의 IP주소를 찾을 때까지 인터넷에서 여러 DNS 서버를 검색하는 것이다. 우리가 필요로 하는 IP주소를 찾거나 찾을 수 없다는 오류 응답을 반환할 때까지 하나의 DNS 서버에서 다른 DNS 서버로 검색이 반복적으로 이루어지기 때문에 이를 재귀적 질의(Recursive Query) 라고도 한다.

 

우리는 ISP의 DNS 서버를 DNS Recursor 라고 부르는데 DNS Recursor는 인터넷의 다른 DNS 서버에 답변을 요청해서 의도된 도메인 이름의 적절한 IP주소를 찾는 일을 담당한다. 다른 DNS 서버는 웹사이트 도메인 이름의 도메인 아키텍처를 기반으로 DNS 검색을 수행하기 때문에 Name Server라고도 한다.

 

국내 도메인 Architecture (그림 출처: https://xn--3e0bx5euxnjje69i70af08bea817g.xn--3e0b707e/jsp/resources/dns/dnsInfo.jsp)

 

 

대부분의 웹사이트 URL은 3차 도메인, 2차 도메인 및 TLD(Top-Level Domain)로 이뤄진다. 각 단계에서는 DNS Lookup 도중에 쿼리되는 고유한 네임서버가 있다. DNS Lookup은 DNS 서버에서 인터넷 도메인 이름을 사용해서 IP주소를 알아내는 과정을 의미한다.

예를 들어 kr 도메인에는 or 영역을 표현하는 or.kr 도메인이 포함되어 있고, or.kr 도메인에는 kisa.or.kr 도메인이 포함되어 있다.

 

이제 구글 주소를 예시로 들어보자. 가장 먼저 DNS Recursor가 Root-Name Server에 연결한다. 그리고 Root-Name Server는 Recorsor를 .com 서버로 Redirection을 하게 된다. 그리고 .com의 서버는 google.com 서버로 Redirection 하게 된다. 마찬가지로 google.com 네임서버는 DNS Record에서 www.google.com 과 일치하는 IP주소를 찾아 DNS Recursor로 반환하게 되고 Recursor는 이것을 다시 브라우저로 보낸다.

 

참고로 위와 같은 요청은 내용 및 IP주소(DNS Recursor의 IP주소)와 같은 정보들을 작은 Packet에 담겨져서 전송된다. Packet은 DNS Server에 도달하기 전에 Client와 Server 사이의 여러 네트워킹 장비를 통해 이동하게 된다. 그리고 네트워크 장비는 Routing-table을 통해 패킷이 목적지에 도달할 수 있는 가장 빠른 방법을 알아내게 된다.

 

먄약 이동 도중에 패킷이 손실되는 상황이 발생된다면 오류가 발생하게 될 것이다. 올바르게 DNS Server에 전송이 되었다면 IP주소를 가져온 후 브라우저로 돌아간다.

 

(4) 브라우저가 해당 서버와 TCP 연결을 한다.

브라우저가 올바른 IP주소를 수신하게 되면 IP주소와 일치하는 서버와 연결해서 정보를 전송한다. 우리가 이전 포스팅에서 알아봤던 IP(인터넷 프로토콜)을 사용해서 연결을 구축한다. 일반적으로 우리는 HTTP 요청을 사용하고 있기 때문에 TCP를 사용한다.

따라서 Client와 Server 간에 Packet을 전송하려면 TCP Connection을 3-way handwhake를 통해 맺어야 한다.

 

(5) 브라우저에서 웹서버에 HTTP 요청을 보낸다.

TCP Connection이 성공적으로 맺어졌다면 데이터 전송이 시작된다. 브라우저에서는 구글의 웹 페이지를 요청하는 HTTP GET 요청을 보내게 된다.

 

(6) 서버가 요청을 처리하고 Response을 보낸다.

보통 서버에는 WS(Web Server)가 포함되어 있다. 웹 서버는 우리가 들어본 Apache가 대표적일 것이다. 이는 브라우저로부터 요청을 수신하고, 해당 내용을 Request-handler에 전달해서 응답을 읽고 생성하는 역할을 한다.

 

Request-handler는 요청, 요청의 헤더 및 쿠키를 읽고 필요한 경우 서버의 정보를 업데이트 하는 프로그램이다. 이후 Response를 특정 Format으로 작성하게 된다. 특정 Format은 JSON, XML 등이 있겠다.

 

(7) 서버에서는 HTTP Response를 보낸다.

서버응답에는 요청한 웹 페이지와 함께 status-code(상태코드), content-encoding(압축 유형), cache-control(페이지 캐싱 방법), 설정할 쿠키, 개인 정보 등이 포함된다.

 

 

위의 status-code가 숫자로 표시되는 것을 볼 수 있다. StatusCode는 Response의 상태를 알려주는 상태 코드이다.

나중에 상태 코드에서도 포스팅을 정리할텐데 간단하게 설명하겠다.

 

- 1XX (Information Response): 정보 메세지를 나타낸다. 서버가 요청을 받았고, 서버에 연결된 클라이언트는 계속해서 작업을 하라는 의미이다.

- 2XX (Success Response): 서버에게 전달한 요청이 성공적으로 처리되었다는 의미이다.

- 3XX (Redirection Response): 요청 완료를 위해서 추가적으로 작업이 필요하다는 것이다.

- 4XX (Client Error Response): 클라이언트의 Request에 에러가 있음을 의미한다.

- 5XX (Server Error Response): 서버 측의 오류로 Request를 수행할 수 없음을 의미한다.

 

(8) 브라우저가 HTML Content를 렌더링한다.

브라우저는 응답받은 HTML을 화면에 표시한다. 먼저, HTML 골격을 렌더링하고 이메일/CSS/JS 등과 같은 웹 페이지의 추가요소에 대한 GET 요청을 보낸다. 또한 정적 파일은 브라우저에서 캐싱이 되기 때문에 다음에 페이지를 방문할 때 다시 가져올 필요는 없다.

 

위의 과정이 끝나고 나면 www.google.com  페이지가 브라우저에 렌더링이 되는 것이다.

 

후기

사실 이번 포스팅에서 작성한 내용들은 어느정도 학부시절에 배웠던 내용이라 머릿속에 조금씩 있었다. 하지만 다시 한번 정리할 필요성이 있어서 정리를 해봤고 웹브라우저 요청 흐름은 간단하게만 알고 있었는데 좋은 블로그 글을 통해 확실하게 인지할 수 있게 되었다.

 

항상 느끼지만 이런 내용들을 배우면 Network에 흥미가 생긴다... 학부 시절에도 Network 수업을 제일 좋아했는데.. ㅎ

 

---

참고자료

- https://velog.io/@khy226/%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%EB%A9%B4-%EC%96%B4%EB%96%A4%EC%9D%BC%EC%9D%B4-%EB%B2%8C%EC%96%B4%EC%A7%88%EA%B9%8C

브라우저에 url을 입력하면 어떤일이 벌어질까?