Network

[Network] HTTP에 대해서 알아보자!! (2편 - URI, URL, Resource)

coding-knowjam(코딩노잼) 2022. 1. 6.

728x90

안녕하세요 Coding-Knowjam입니다.

오늘은 URI, URL, Resource에 대해서 알아보겠습니다.

1. URI(Uniform Resource Idntifier)

1.1 Resource

URI에 대해서 알아보기 전에 Resource(리소스)란 무엇일까요??

리소스는 우리가 웹 사이트에 접속하거나 API 호출을 할 때, 서버로부터 제공받는 식별 가능한 자원들을 의미합니다.

텍스트나 이미지, 동영상 등과 같은 것들을 말하는 것이죠

이렇게 설명하면 단순히 뭔가. html 이런 문서나. jpg 이런 사진 파일들만 생각하실 수도 있을 겁니다.

그러나 이런 정적인 파일들 외에 개념적으로 식별할 수 있으면 리소스가 될 수 있습니다.

예를 들어 어떤 식당의 메뉴들을 보여줘!라는 요청이 존재하면 여기서 "메뉴"는 리소스가 되는 겁니다.

아직 URI에 대해서 설명드리진 않았지만, 위의 요청을 API로 설계한다면 "~~/menus" 이렇게 작성할 수 있습니다.

여기서 menus는 정적인 파일들을 의미하는 것이 아니라 메뉴들이라는 자원들을 의미하는 것이고, 이렇게 식별 가능한 자원을 우리는 리소스라고 부릅니다.

클라이언트는 원하는 리소스에 접근하기 위해 URI이나 URL을 사용하고 있는 것입니다.

1.2 URL과 URN

URI는 아래 그림과 같이 URL과 URN을 포함하는 하나의 개념이며, "통합 자원 식별자"라고도 불립니다.

우리는 URI를 통해서 서버 내에 원하는 리소스에 접근할 수 있습니다.

그림출처 : 인프런 - 모든 개발자를 위한 HTTP 웹 기본지식 (김영한 저)

사실 요즘에는 일반적으로 URL과 URI가 혼용돼서 사용되고 있으며, URL을 URI로 보셔도 무방합니다.

즉, URL도 서버에 존재하는 식별 가능한 리소스의 위치를 나타내는 것이며 클라이언트는 URL, URI를 사용하여 리소스에 접근하며 정보를 제공받습니다.

그러면 URN은 무엇일까요??

URN은 리소스가 어디에 있던지 상관없이, 리소스에 이름을 부여하여 접근하는 방식을 의미합니다.

조금 더 이해하기 쉽게 예를 들자면 우리는 DNS를 통해 IP주소가 아닌 이름으로 원하는 사이트에 접속을 할 수 있습니다. (ex: www.naver.com)

URN도 이와 비슷하게 리소스에 이름을 부여해서 그 이름을 통해서 접근한다고 생각하시면 됩니다.

그렇지만 사실 URN은 현재 보편적으로 사용하고 있는 방식은 아니기 때문에 우리는 URL을 집중적으로 알아보겠습니다.

2. URL(Uniform Resource Locator)

앞서 설명한 것처럼 URI와 URL은 같은 의미로 보셔도 됩니다.

우리는 일반적으로 "https://www.naver.com", "https://codingnojam.tistory.com/rss"와 같은 URL을 사용하여 사이트에 접속하거나 또는 json, xml 등과 같은 형태의 데이터를 얻을 수 있습니다.

일상에서 자주 사용해서 당연하게 받아들여지는 저 표현은 사실 URL의 문법에 기준해서 작성된 것입니다.

그러면 URL은 어떤 문법으로 작성되는지 알아보겠습니다.

2.1 URL 문법

기본적으로 URL의 문법은 다음과 같습니다.

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

스키마://[사용자정보@]호스트[:포트번호][/경로][?쿼리파라미터][#프레그먼트]

ex) https://www.google.com:443/search?q=covid19

URL 문법은 위와 같은 항목들로 구성되어 있으며, 대괄호[] 안에 있는 항목들은 필요에 따라서 작성하거나 생략해도 되는 부분입니다.

위의 예시 URL은 구글 사이트에 에서 covid19를 검색할 때의 URL입니다.

이제 각각의 항목들이 어떤 것을 의미하는지 알아보겠습니다.

2.1.1 scheme (스키마)

URL에서 제일 앞부분에 작성해야 하는 스키마는 접근하고자 하는 리소스에 어떤 방식으로 접근할 것인지를 의미합니다.

위의 예시 URL에서는 https 프로토콜을 작성하였습니다. 만약에 SSL이 적용되지 않은 사이트라면 http 프로토콜을 스키마에 적어주면 됩니다.

일반적으로 스키마에는 프로토콜을 작성하며 http 외에 ftp, smtp 등과 같은 프로토콜도 스키마에 작성할 수 있습니다.

2.1.2 userinfo@ (사용자 정보@)

스키마 다음에 작성하는 사용자 정보는 서버에 있는 리소스에 접근할 때, 인증이 필요한 경우 작성하게 됩니다.

사용자 이름과 비밀번호를 작성해야 하며 ':'(콜론) 문자를 구분자로 사용하여 작성합니다.

ex) https://codingknowjam:password@google.com

사용자 정보 뒤에 오는 '@' 문자는 URL에서 사용자 정보를 분리하기 위해 사용하는 구분자입니다.

실제로는 [userinfo@] 항목은 거의 사용되고 있지 않기 때문에 그냥 이런 게 있구나 정도만 알면 될 것 같습니다.

2.1.3 host (호스트), :port (:포트번호)

호스트는 실제 리소스가 있는 호스팅 서버를 의미합니다.

우리가 특정 리소스에 접근하기 위해서는 그 리소스가 어느 서버에 있는지 알아야 하며, 호스트는 해당 리소스를 가지고 있는 서버의 정보입니다.

일반적으로 이름을 사용하는데 IP주소로도 사용이 가능합니다.

ex) https://www.google.com 또는 https://127.0.0.1

이름을 사용해도 결국 DNS 서버에서 IP주소로 변환되기 때문에, IP주소를 작성하는 것과 동일한 의미입니다.

포트번호는 서버 내에서 해당 리소스를 가지고 있는 애플리케이션에 할당된 포트번호를 의미합니다.

우리가 지금 살펴보고 있는 HTTP는 TCP위에서 동작하고 있습니다.

TCP 계층에서는 애플리케이션을 구분하기 위해 포트번호를 할당하며, 이때 할당된 포트번호를 작성해주면 됩니다.

기본적으로 http는 80 포트, https는 443 포트가 할당되기 때문에, 해당 애플리케이션이 기본 포트를 사용한다면 포트번호를 생략할 수도 있습니다.

포트번호 앞에 붙는 ':' (콜론)은 URL에서 포트번호를 구분하기 위한 구분자입니다.

2.1.4 /path (경로)

URL에서 경로는 리소스가 서버의 어디에 존재하는지 알려주기 위해 작성합니다.

경로는 '/' (슬래시) 구분자를 통해서 계층적인 구조로 표현할 수 있습니다.

일반적으로 사람이 볼 때도 계층적인 구조가 인식하기 쉽기 때문에 대부분의 경로는 계층적인 구조로 작성됩니다.

ex) https://www.google.com/robots.txt, https://host/products/1

2.1.5 ?query (쿼리 파라미터)

query는 서버에 질의를 하기 위해 작성됩니다.

예를 들어 "https://www.google.com:443/search?q=covid19" URL에서 '?' 뒤에 붙은 q=covid19가 쿼리 파라미터이며 이를 통해 구글에 covid19를 검색한 결과를 얻을 수 있습니다.

쿼리 파라미터 또는 쿼리 스트링이라고도 부르며, 서버에서 query를 받을 때 모두 문자열로 받는다는 특징이 있습니다.

쿼리 파라미터는 기본적으로 key=value 구조로 작성이 되며, 여러 개의 쿼리 파라미터를 작성할 때는 '&' 를 통해서 구분해 줄 수 있습니다

ex) https://host:443/members?name=codingknowjam&age=20

2.1.6 #fragment (프레그먼트)

프레그먼트는 리소스의 특정 부분을 가리키기 위해 작성됩니다.

예를 들어 블로그나 다른 사이트를 보시면 위로가기나 어떤 특정 위치로 이동할 수 있는 버튼이 존재하는데, 이때 프레그먼트를 사용할 수 있습니다.

ex) https://docs.spring.io/spring-boot/docs/current/reference/html/getting-started.html#getting-started.whats-next

프레그먼트는 URL에서 '#' 구분자를 통해서 구분되며, 서버에 전송되는 정보는 아닙니다.

서버는 '#' 이전까지의 URL을 통해서 전체 리소스를 응답해주고, 이후 브라우저는 프레그먼트 정보를 통해 리소스 내에 특정 부분을 보여주는 형태로 동작을 하기 때문에, 단순히 내부 북마크 용도로 사용됩니다.

2.2 상대 URL

지금까지 저희가 예시로 살펴보았던 URL들은 모두 절대 경로로 작성된 URL이며, 상대적인 경로로 작성되는 URL도 있습니다.

개발을 하시다 보면 html태그 중에 다음과 같이 작성된 것들을 볼 수 있습니다.

<a href="./test.html"/>

"./test.html" URL을 보면 앞에서 살펴보았던 스키마나 호스트 같은 정보들이 작성되어 있지 않아서 잘못된 URL 같지만, 이는 해당 태그가 있는 html문서를 기준으로 작성된 올바른 상대 URL입니다.

상대 URL은 스스로의 정보가 포함되어 있는 URL을 기저 URL로 사용하며, 이를 통해 스키마나 호스트 같은 정보를 알아낼 수 있습니다.

예를 들어 "https://www.codingknowjam.com/main.html" 해당 URL로 접근한 문서 안에 위의 <a> 태그가 존재한다면 "https://www.codingknowjam.com/"를 기저 URL로 사용하여 스키마와 호스트, 포트번호 등의 정보를 얻어 올 수 있습니다. ("https://www.codingknowjam.com/main.html" -> "https://www.codingknowjam.com/test.hml")

그래서 우리가 개발을 할 때 './' , '/' 같은 경로 구분자를 통해서 상대 URL을 작성해도 절대 경로 URL로 변환이 되어 리소스에 접근이 가능했던 것입니다.

상대 URL을 절대 경로 URL로 변환하기 위해 사용되는 알고리즘이 있는데 이에 대한 내용은 RFC 2396에 있으니 궁금하신 분은 문서를 살펴보시면 될 것 같습니다.

해당 포스팅은 인프런 - 모든 개발자를 위한 HTTP 웹 기본 지식을 참고하여 작성하였습니다.

다음에는 HTTP에서 요청과 응답에 사용되는 메시지에 대해서 알아보겠습니다.