URI (Uniform Resource Identifier)

그림 한 장으로 본다면 다음과 같다.

URI, URL, URN의 차이

URI란?

RFC 스펙에 다르면 URI는 다음와 같다.

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

• https://www.ietf.org/rfc/rfc3986.txt - 1.1.3. URI, URL, and URN

RFC(Request for Comments)는 미국의 국제 인터넷 표준화기구인 IETF(Internet Engineering Task Force)에서 제공하고 관리하는 문서이다.

인터넷 개발에 있어 필요한 기술, 연구 결과, 절차 등을 기술한 것으로 거의 모든 인터넷 표준이 문서화 되어 있다.

• 인터넷 개발에 관련된 기술을 연구하거나 알고 있는 사람은 누구나 RFC 문서를 작성할 수 있다.

소위 논란 거리가 있을 때 열어보는 표준 스펙으로, 위 인용의 출처는 URI에 대해서 정의된 스펙이다.

URI는 Uniform Resource Ideneifier의 약어로, 각 단어는 각각 다음과 같은 의미를 가진다.

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

💡 Resource란?
자원(리소스)은 URI로 식별할 수 있는 모든 것을 말한다. 웹 브라우저의 html 파일, 실시간 교통 정보, 이미지 파일 등이 자원이다.

즉, 사람을 주민번호로 식별하듯이 자원 자체를 식별하는 방법이다. 그리고 이 식별하는 방법에는 크게 두 가지가 있다.

• 리소스의 위치: URL
• 리소스 그 자체: URN

URL란?

Uniform Resource Locator의 약어로, 리소스가 어디(위치)에 있는지를 말한다.

• Locator: 리소스가 있는 위치를 지정
• 위치는 변할 수 있다.

보통 다른 분류인 URN은 거의 사용되지 않기 때문에, URI를 URL과 같은 의미로 이야기한다.

URN란?

Uniform Resource Name의 약어로, 리소스 그 자체를 말한다.

• Name: 리소스에 이름을 부여
• 이름은 변하지 않는다.

자원과 이름이 매핑되어 있어야 하기 때문에, 이름으로 부여하면 거의 찾을 수가 없다.

따라서, URN은 거의 사용하지 않는다.

• URN 이름만으로 실제 리소스를 찾을 수 있는 방법은 보편화되지 않았다.

URN의 예로는 어떤 책의 ISBN을 들 수 있다. 책의 ISBN이 1234567890이라면, URN은 다음과 같다.

urn:isbn:1234567890

URL 문법

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

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

출처: 인프런 강의 - 모든 개발자를 위한 HTTP 웹 기본 지식

scheme

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

💡 프로토콜이란?
어떤 방식으로 자원에 접근할 것인가 하는 클라이언트와 서버 간의 약속과 규칙을 말한다.
HTTP, HTTPS, FTP 등이 프로토콜이다.

• Https는 HTTP Secure로, Http에 강력한 보안을 추가한 것이다.
• 지금은 대부분의 웹 사이트들이 Https로 동작한다.

userinfo

• URL에 사용자 정보를 포함해서 인증해야 할 때 사용된다.
• 거의 사용하지 않는다.

host

• 호스트명
• 도메인명 또는 IP 주소를 직접 사용할 수 있다.

port

• 접속 포트
• 일반적으로 생략한다.
  • 생략할 경우 HTTP는 80포트, HTTPS는 443 포트를 사용한다.

path

• 리소스가 있는 경로(path)
• 계층적 구조로 되어 있다.
  • /home/file.jpg
  • /members/100

query

• key=value 형태
• ?로 시작하며, &로 추가 가능하다.
  • ?q=keyword&hl=ko
  • q가 구글에서 정한 key이고, value는 keyword가 된다.
• query parameter, query string 등으로 불린다.
  • 웹 서버에 제공하는 파라미터 정보이기 때문에 쿼리 파라미터로 부른다.
  • 값이 모두 문자 형태로 넘어가기 때문에 쿼리 스트링이라고 부르기도 한다.

fragment

• 잘 사용하지는 않는다.
• html 내부 북마크 등에 사용한다.
  • html 문서에서 특정 위치로 이동하고 싶을 때 사용
• 서버로 전송하는 정보는 아니다.

예를 들어, 다음과 같이 사용할 수 있다.

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

URI의 문법 예제

구글에 ‘keyword’를 입력하면 다음과 같이 변하는 것을 볼 수 있다. 길이가 길어서 앞부분만 일부 가져왔다.

https://www.google.com/search?q=keyword&sca_esv=598129589&hl=ko

이 URI를 문법에 따라 아래 그림과 같이 구분할 수 있다.

웹 브라우저 요청 흐름

전체 흐름

구글에서 키워드를 검색해서 다음과 같은 URI가 만들어졌다고 하자.

https://www.google.com/search?q=keyword&sca_esv=598129589&hl=ko

이 URI를 입력하면 먼저 DNS에서 도메인 명으로 IP 주소를 찾는다.

• 도메인 명: www.google.com
• 이때, HTTPS 프로토콜을 사용했으므로 생략된 포트 번호는 443이 된다.
• 구글의 IP 주소는 임의로 $200.200.200.2$ 라 하자.
• DNS에서 IP주소를 획득하는 과정은 3-way handshake가 발생하지 않는다. (UDP 이용)

그러면 클라이언트($100.100.100.1$)에서 다음과 같이 패킷을 만든다.

• HTTP 요청 메시지 생성
  • 요청 메시지에는 URI의 path 이후부터 query 정보가 들어간다.
  • HTTP 버전 정보와 host 정보도 들어있다.
  • 몇 가지 부가 정보가 더 있지만 여기서는 생략되었다.
• 메시지를 소켓 라이브러리를 통해 TCP/IP 계층에 전달한다.
  • 메시지를 전송하기 전, 3-way handshake로 구글 서버와의 연결을 체크해야 한다.
  • 소켓 라이브러리가 커넥션을 TCP/IP로 맺으세요. 라고 요청하면, 그 하부에서 3way를 실행하고 연결이 된다.
• TCP/IP 패킷을 생성한다.
  • HTTP 요청 메시지에 출발지 IP와 포트, 목적지 IP와 포트를 추가한다.
  • 출발지 IP는 $100.100.100.1$이며, 포트는 여분의 랜덤 포드를 할당한다.
  • 목적지 IP와 포트는 $200.200.200.2:443$이다.

생성된 패킷을 인터넷을 통해 구글 서버($200.200.200.2$)에게 전송한다.

• 구글 서버는 TCP/IP 패킷에서 HTTP 메시지를 꺼낸 후, 해석한다.
  • q: 검색어는 keywords
  • hl: 한국어로 검색

구글 서버는 요청대로 검색 엔진에서 ‘keywords’를 검색 후, HTTP 응답 메시지를 생성해 반환한다.

• HTTP 요청 메시지를 만드는 것과 똑같이 메시지 생성 후, TCP/IP 패킷을 생성한다.
• 그리고 인터넷을 통해 클라이언트에게 반환한다.
• 이때, 클라이언트와 연결이 되어있으므로 3-way handshake는 하지 않는다.
  • 3-way handshake를 하면 클라이언트와 서버 모두 서로 IP, PORT를 알고 있다.

마지막으로, 클라이언트는 응답을 받은 후 HTML 렌더링을 한다. 이렇게 데이터를 주고 받는 과정이 끝나면 연결을 끊는다.

• 이때까지 소켓 라이브러리는 살아 있다고 한다.

요약

앞선 내용을 모두 요약하여 그림 한 장에 정리하면 아래와 같다.

Reference

인프런 강의

모든 개발자를 위한 HTTP 웹 기본 지식 강의 - 인프런

참고 사이트

RFC (Request for Comments)란? - RFC의 역사, RFC 종류, RFC 표준화 절차