URI 와 웹 브라우저 요청 흐름

CHOI·2022년 6월 3일

URI URN url 웹 브라우저 요청 흐름

HTTP

목록 보기

2/3

URI

Uniform Resource Identifier

URI, URL, URN 에 대해서 들어본 적이 있을 수 있다. 먼저 이거에 대해서 구분을 해보자.

https://www.ietf.org/rfc/rfc3986.txt

URI

URI 는 로케이터(locator), 이름(name) 또는 둘 다 추가로 분류될 수 있다.

그러면 로케이터는 뭐고 이름은 뭘까?

URI 라는 가장 큰 개념이 있다. URI 는 리소스를 식별한다.

리소스를 식별하는 것은 쉽게 예를 들면 주민번호를 생각하면 된다. 사람들을 주민번호를 식별하듯이 무언가 자원자체를 식별하는 방법이다.

거기에 크게 2가지가 있다.

URL (Resource Locator)
- 리소스의 위치라는 뜻
URN (Resource Name)
- 리소스의 이름

이 두가지는 위와 같이 생겼다.

우리가 웹 브라우저에 적는 https://naver.com/path=... 이런식으로 적는게 URL 이고

URN 는 위 사진과 같이 example:animal:ferret:now 이런것 처럼 진짜 이름을 부여한 것이다. 문제는 이름을 집어 넣으면 무언가 결과가 나오도록 Mapping 되어 있어야 하는데 그런게 어렵다.

그래서 거의 URL 을 사용한다. 그냥 URN 같은게 있다. 이정도면 이해하면 된다.

URI 단어 뜻

Uniform : 리소스를 식별하는 통일된 방식
Resource : 자원, URI 로 식별할 수 있는 모든 것(제한 없음)
Idenifier : 다른 항목과 구분하는데 필요한 정보

URL, URN 단어 뜻

URL - Locator : 리소스가 있는 위치를 지정
URN - Name : 리소스에 이름 부여
위치는 변할 수 있지만, 이름이 변하지 않는다.
urn:isbn:8960777331 (어떤 책의 isbn URN)
URN 이름만으로 실제 리소스를 찾을 수 있는 방법이 보편화 되지 않음
앞으로 URI를 URL과 같은 의미로 이야기 하겠음

URL 분석

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

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

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

위 구글 URL 을 분석해보자

scheme

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

스키마 라고 한다.

주로 프로토콜 사용
- 프로토콜 : 어떠한 방식으로 자원에 접근할 것인가에 대한 클라이언트와 서버간의 규칙
- 예: http, https, ftp 등
http 는 80 포트, https 는 443 포트를 주로 사용, 생략 가능
https 는 http + 보안 (HTTP Secure)

userinfo

URL 에 사용자 정보를 포함해서 인증
거의 사용하지 않음

host

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

호스트명
도메인 명 또는 IP 주소를 직접 사용

port

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

포트
접속 포트
일반적으로 생략, 생략시 https 는 443, http 는 80

path

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

리소스 경로(path), 계층적 구조
예
- /home/file1.jpg
- /members
- /members/100, /items/iphone13

query

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

key=value 형태
? 로 시작, & 로 추가 가능 ?keyA=valueA&keyB-valueB
query parameter, query string 등으로 불림, 웹서버에서 제공하는 파라미터, 문자 형태

fragment

https://docs.spring.io/spring-boot/docs/current/reference/html/getting-started.html**#getting-started-introducing-spring-boot**

fragment
html 내부 북마크 등에 사용
서버에 전송되는 정보는 아님

웹 브라우저 요청 흐름

그러면 이제 웹 브라우저 요청이 왔을 때의 흐름에 대해서 알아보자.

우리가 https://www.google.com:443/search?q=hello&hl=ko 이렇게 보내면 먼저 웹 브라우저가

DNS 를 조회해서 먼저 구글 서버의 IP와 포트 정보를 찾는다. 그리고 HTTP 요청 메시지를 생성한다.

HTTP 요청 메시지는 위와 같이 생겼다.

뭔지 모르겠지만 앞에 GET 이 있으니까 달라는 의미일 것 이다. 그리고 뒤로는 path 부터 쿼리 정보가 들어간다. 그리고 뒤에 HTTP 버전 정보가 들어가고 호스트 정보가 들어간다.(이 외에 몇 가지 부가 정보가 더 들어있긴함)

**HTTP 메시지 전송**

어플리케이션에서 웹 브라우저가 HTTP 메시지를 생성한다(앞서 설명한 과정)
SOCKET 라이브러리를 통해서 TCP/IP 로 HTTP 메시지를 전달
1. SYN ACK 과정을 통해서 구글 서버와 연결을 한다.
2. 데이터 전달
TCP/IP 패킷 생성 (여기에는 IP 정보와 포트 정보 + HTTP 메시지가 포함되어 있을 것이다.)

패킷 생성

TCP/IP 패킷을 생성하면 위와 같이 IP 와 PORT 정보를 가지고 있고 전송 데이터를 포함할 것이다.

이 전송 데이터에는 웹 브라우저가 만든 HTTP 메시지가 들어 있다.

이렇게 생성된 패킷을 인터넷 망에 던진다. 그러면 수많은 노드들을 거쳐서 200.200.200.2 로 패킷이 전송될 것이다.

이렇게 패킷이 구글 서버에 도착하면 TCP/IP 패킷들을 다 까서 버린다. 그리고 HTTP 메시지만을 가지고 본인이 해석한다.

쿼리를 보니까 search 네? 아 뭔가 검색을 하겠다는 것이구나
q=hello 를 보니까 검색해볼게 hello 이고 hl=ko 니가 결과는 한국어네
그러면 검색을 통해서 hello 를 검색하고 결과는 한국어로 받겠다는 거네? 하고 데이터를 찾는다.

그런 다음에 구글 서버에서 HTTP 응답 메시지를 만든다.
HTTP 응답 메시지는 뒤에서 더 자세히 설명하겠다.
- HTTP/1.1 200 OK : 뭔가 정상적으로 작동했다는 의미일 것이다.
- Content-Type : 이 부분이 중요한데 위 메시지는 데이터가 html 형식이고 UTF-8 형식으로 되어 있다는 의미이다.
- Contetn-Length: 실제 html 데이터의 길이가 3423 라고 알려준다.