URI(Uniform Resourse Identify)
URI 란 리소스를 식별하는 방법을 말합니다. 인터넷 상의 어떤 자원이나 정보를 고유하게 식별하는 방법을 제공하는 것입니다.
URI를 단어 그대로 파헤쳐보자면,
- Uniform : 리소스를 식별하는 통일된 방식
- Resource : 자원, URI로 식별할 수 있는 모든 것
- Identifier : 다른 항목과 구분하는데 필요한 정보
즉 리소스를 식별하는 통일된 방식으로 볼 수 있습니다.
그런데 URI 외에도, URL과 URN이라는 단어도 많이 들어보셨을 겁니다. URI과의 차이가 무엇일까요?
(1) URL과 URN
결론부터 말하자면, URI 안에 URL과 URN이 포함되는 개념입니다. URI는 Resource Identifier로 리소스를 식별합니다. 자원을 식별하기 위해 로케이터(Locator), 이름(name)의 두 가지 방법을 사용할 수 있습니다.
URL은 Uniform Resource Locator의 약자로, 단어 그대로 리소스의 위치를 나타내는 것입니다. 즉 특정 자원이 어디에 위치하는지를 지정하는 것입니다.
URN은 Uniform Resource Name의 약자로, 리소스의 이름을 통해 식별하는 것입니다. 즉 특정 자원을 고유하게 식별하기 위해 이름을 제공하는 것입니다.
즉, URL은 Locator로 리소스가 있는 위치를 지정하는 것이고 URN은 리소스에 이름을 부여하는 것입니다.
URL과 URN의 예시는 위와 같습니다.
보통의 웹브라우저에서 많이 보이는 "http://www.example.com/" 과 같은 형태가 URL입니다. URL은 리소스가 위치하는 곳이 변할 수 있기 때문에, 해당 리소스의 위치를 식별하는 데 사용됩니다.
반면 URN은 "urn:isbn:0451450523"의 형태로 리소스의 위치와는 독립적으로 사용될 수 있습니다. 리소스의 위치가 변할 수 있더라도 자원에 대한 고유한 이름으로 식별이 가능합니다. 실제 리소스를 찾을 수 있는 방법이 보편화되지 않았기 때문에 매핑하기가 어려워 거의 쓰이지 않는 방법입니다.
URN 방식이 많이 쓰이지 않기 때문에, 단어를 사용할 때 보통 URI와 URL을 크게 구분지어 얘기하지는 않습니다.
(2) URL 문법
만약 아래와 같은 URL이 주어졌을 때 URL에 담긴 정보가 무엇인지 파악할 수 있어야 합니다.
위 URL를 문법으로 구분한 것은 아래와 같습니다. 이것을 통해 URL에 담긴 정보를 살펴보겠습니다.
scheme
우선 앞의 Scheme는 주로 프로토콜이 사용됩니다. 프로토콜이란 어떤 방식으로 자원에 접근할 것인가 하는 약속 규칙을 말합니다. http, https, ftp 등이 이에 속합니다.
userinfo
URL에 사용자 정보를 포함해서 인증해야할 때 사용하는 것입니다, 거의 사용하지 않습니다.
PORT
http는 80 포트, https는 433 포트를 주로 사용하는데, 포트 번호는 생략이 가능합니다. 생략하면 http는 80 포트, https는 443 포트로 자동으로 들어가게 됩니다.
path
리소스가 있는 경로입니다.
" /home/file1.jpg ", " /members/100 ", " /items/iphone12 " 과 같이 보통 계층적 구조로 되어있습니다
query
key와 value 형태로 구성됩니다. 물음표(?) 로 시작하고 &로 추가로 파라미터를 붙일 수 있습니다.
보통 웹서버에 제공하는 파라미터 정보기 때문에 쿼리 파라미터라고 부르고, 여기 담긴 정보들은 전부 문자열로 넘어가기 때문에 쿼리 스트링으로도 부릅니다.
fragment
html 내부 북마크 등에 사용되는 값이고 거의 사용되지 않습니다. 서버에 전송하는 정보는 아닙니다.
웹 브라우저 요청 흐름
위 내용을 바탕으로 웹 브라우저에서 요청이 어떻게 이루어지는지 살펴보겠습니다.
위와 같은 URI가 실행되면, 우선 DNS 서버에서 google 도메인에 대응하는 서버를 찾아야 합니다. " www.google.com "도메인에 대응하는 주소를 DNS 서버에서 조회해서 IP가 200.200.200.2, 포트 번호가 433인 주소를 찾아냅니다.
그리고 HTTP 요청 메시지를 생성합니다.
HTTP 요청 메시지에는 웹 서버에 전달할 데이터와 요청하는 리소스 정보 등이 포함됩니다.
HTTP 요청 메시지에 대한 내용은 추후 포스팅에서 다루겠습니다. 여기서는 그냥 이렇게 생겼다 정도로 생각하시면 될 것 같습니다.
웹 브라우저가 HTTP 메시지를 생성하면, SOCKET 라이브러리를 통해 OS의 TCP/IP 계층에 전달됩니다. TCP/IP 정보를 통해 IP 주소와 포트 번호로 구글 서버와의 연결합니다. 이때 TCP의 3-way handshake 과정을 통해 클라이언트(웹 브라우저)와 서버(구글) 사이의 가상 연결이 설정됩니다.
그리고 HTTP 요청 메시지를 구글 서버로 전송합니다. 이 과정에서 TCP/IP 프로토콜을 사용하여 데이터를 주고받기 위한 패킷이 생성되며, 이 패킷이 인터넷을 통해 흘러가게 됩니다.
패킷에는 출발지의 IP와 PORT 번호, 목적지의 IP와 PORT 번호가 있고 HTTP 요청 메시지도 함께 포함합니다 이 요청 패킷이 구글 서버에 도착하면 구글 서버에서는 해당 요청을 처리하고 HTTP 응답 메시지를 만들어냅니다.
Http 응답 메시지를 간략히 나타낸 것입니다. 세부적인 것은 이후 포스팅에서 다루도록 하겠습니다.
참고자료
[인프런 김영한 - 모든 개발자를 위한 HTTP 웹 기본 지식]
https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard
'Backend > HTTP' 카테고리의 다른 글
[HTTP] HTTP 상태코드 (모든 개발자를 위한 HTTP 웹 기본 지식 - 섹션 6) (0) | 2023.04.25 |
---|---|
[HTTP] HTTP 메서드 활용 (모든 개발자를 위한 HTTP 웹 기본 지식 - 섹션 5) (0) | 2023.04.25 |
[HTTP] HTTP 메서드 (모든 개발자를 위한 HTTP 웹 기본 지식 - 섹션 4) (0) | 2023.04.21 |
[HTTP] HTTP 기본 (모든 개발자를 위한 HTTP 웹 기본 지식 - 섹션 3) (0) | 2023.04.20 |
[HTTP] 인터넷 네트워크 (모든 개발자를 위한 HTTP 웹 기본 지식 - 섹션 1) (0) | 2023.04.17 |