URL과 리소스

• 책뽀개기 모임  중 http 완벽가이드 1장 뽀개기 진행중입니다. (~8월말) (다음 모임은 2장) (모임 참여를 원하신다면 댓글로 문의 바랍니다.)
• HTTP 완벽가이드  책을 보고 이해한 내용을 저만의 순서로 정리 한 글입니다.

URL의 개념

URL(Uniform Resource Locator)은 인터넷 리소스를 가리키는 표준이름이다.

URL은 전자정보 일부를 가리키고, 그것이 어디에 있고 어떻게 접근할 수 있는지 알려준다.

• URL은 브라우저가 정보를 찾는데 필요한 리소스의 위치를 가리키며,
• URL을 이용해 사람과 어플리케이션이 인터넷 상의 수십억 개의 리소스를 찾고 사용하며 공유할 수 있다.
• URL을 통해 사람이 HTTP 및 다른 프로토콜을 통해 접근할 수 있다.

URL을 사용하면 리소스를 일관된 방식으로 지칭할 수 있다. 대부분의 URL은 동일하게 스킴://서버위치/경로 구조로 이루어져있다.

• 인터넷상의 모든 리소스를 가리키고 가져오기 위해, 모든 사람이 같은 방식으로 이름을 써서 리소스를 찾을 수 있도록, 단일 방식의 작명 규칙을 가진 것이다. === 통합 자원 위치값

URL은 URI의 일부

URL은 통합 자원식별자 혹은 URI라고 불리는 더 일반화된 부류의 부분집합이다. URI는 URL과 URN으로 구성된 종합적인 개념이다.

• URL은 리소스가 어디 있는지 설명해서 리소스를 식별한다.
• URN은 현재 그 리소스가 어디에 존재하든 상관없이 그 이름만으로 리소스를 식별한다.

안전한 통합 자원 위치(URL)값을 위해서

1. URL의 구성

• 모든 리소스들은 다른 스킴을 통해 접근할 수 있으며, URL 문법은 스킴에 따라서 달라진다.
• 대부분의 URL은 일반 URL문법을 따른다.
• 의미있는 URL이라는 개념도 있다. (Clean URLs )
  • 당신이 URL을 조작하기 쉽게 한다.
  • 어디에 있고, 무엇을 하고, 무엇을 읽거나 웹에서 상호작용하는 지에 대해 유저들에게 분명히 알려준다.
  • 몇몇의 검색엔진은 관련 페이지들을 잘 분류하기 위해 이런 의미론을 사용할 수 있다.
• URL은 9개의 컴포넌트로 구성되어있다.

<스킴>://<사용자이름>:<비밀번호>@<호스트>:<포트>/<경로>;<파라미터>?<질의>#<플래그먼트>

1.1 스킴

• 스킴은 주어진 리소스에 어떻게 접근하는지 알려주는 중요한 정보다.
• URL을 해석하는 어플리케이션이 어떤 프로토콜을 사용하여 리소스를 요청해야 하는지 알려준다.
• 첫번째 구분자로 :를 사용한다.
• 스킴명은 대소문자를 가리지 않는다.

1.2 사용자 정보

기본값

• 사용자 이름 : anonymous
• 비밀번호 : IEUser(익스플로러), chrome@example.com(크롬)

• 많은 서버가 자신이 가지고 있는 데이터에 접근을 허용하기 전에 사용자 이름과 비밀번호를 요구한다.
• FTP서버가 주로 그러하다.

ftp://anonymous:my_passwd@ftp.prep.ai.mit.edu/pub/gnu

1.3 호스트

• 어플리케이션이 인터넷에 있는 리소스를 찾으려면 리소스를 호스팅하고 있는 장비와 장비 내에서 리소스에 접근할 수 있는 서버가 어디에 있는지 알아야 한다.

Host

• 접근하려고 하는 리소스를 가지고 있는 인터넷상의 호스트장비(?)를 가리킨다.
• 호스트명이나 IP주소로 제공한다.

Port

• 서버가 열어놓은 네트워크 포트를 가리킨다.
• TCP 프로토콜을 사용하는 HTTP는 기본 포트가 80이다. (https는 443)

1.4 경로

• 리소스가 서버의 어디에 있는지 알려준다.
• 계층적 파일 시스템 경로와 유사한 구조이다.
  • 유닉스 파일 시스템의 파일 경로와 유사하다.
• /를 기준으로 경로조각으로 나누니다.
• 각 경로조각은 자체만으로 파라미터 컴포넌트를 가질 수 있다.

1.5 파라미터 Matrix parameter

• 많은 스킴이 객체에 대한 호스트 및 경로 정보만으로는 리소스를 찾지 못한다.
• URL이 사용하는 어플리케이션이 리소스에 접근하려면 프로토콜 파라미터가 필요하다.
• URL의 파라미터 컴포넌트는 어플리케이션이 서버에 정확한 요청을 하기 위해 필요한 입력 파라미터를 받는데 사용한다.
• 이 컴포넌트는 이름/값 쌍의 리스트로 URL 나머지 부분들로부터 ; 문자로 구분하여 URL에 기술한다.

쿼리스트링과 차이점

개인적으로 지금까지 이런 형식의 URL을 본적이 없어서, 검색해보니 이런 형식을 Matrix parameter라고 불리며, 쿼리스트링과의 차이점은 아래와 같다고 나왔다. ( 관련링크 Query vs. Matrix Params  )

• urls with query params won’t have their response cached by intermediaries/proxies (at present) 쿼리 파라미터가있는 URL은 현재 중개자/프록시에 의한 응답이 캐시되지 않습니다.
• matrix parameters may appear anywhere in path 매트릭스 파라미터는는 path의 어느 곳이든 표현될 수 있다.
• calculating the relative uri is different 상대 URI를 계산하는 것이 다르다.
• query params are generally abused to add new verbs instead of using existing methods on resources 쿼리 파라미터는 일반적으로 리소스에 기존 방법을 사용하는 대신 새 동사를 추가하는데에 남용된다.
• matrix parameters are not resources, they are aspects that help reference a resource in an information space that is difficult to represent within a hierarchy 매트릭스 파라미터는 자원이 아니며, 정보 공간에서 계층 구조 내에서 표현하기 어려운 자원을 참조하는 데 도움이되는 측면입니다.

아직 proposal state에 존재하며, 웹 표준이 아니라고 한다. (관련 링크 w3-MatrixURIs  )

1.6 쿼리파라미터 (질의 문자열)..

• 데이터베이스 같은 서비스들은 요청을 받을 리소스 형식의 범위를 좁히기 위해 질문이나 질의를 받을 수 있다.

• URL의 쿼리스트링 컴포넌트는 게이트웨이를 가리키는 정보를 URL의 경로 컴포넌트와 함께 전달하고 있다.

  • 보통 게이트웨이는 다른 어플리케이션에 접근하려고 할 때 거치는 통로라고 할 수 있다.

• 쿼리스트링은 포맷에 제약사항은 없다. (URL에 금지된 문자제외하고)

• 편의상 많은 게이트웨이가 &로 나뉜 이름=값 쌍 형식의 쿼리스트링을 원한다

1.7 플래그먼트 fragment

• HTML과 같은 리소스 형식들은 본래의 수준보다 더 작게 나뉠 수 있다.
• 문단으로 나뉠 수 있는 경우 리소스 안에 있는 특정 문단을 가리킬 수 있다.
• 리소스의 특정 부분을 가리킬 수 있도록 리소스 내 조각을 가리킬 수 있는 fragment 컴포넌트를 제공한다.
• 보통은 서버에는 fragment를 전달하진 않고, 프론트에서 특정 문단을 보여주고 싶을 때 사용한다.

2. 안전한 URL을 위해 고민한 설계자들

URL 설계자들은 이런 고민을 했다.

1. 모든 인터넷 프로토콜로 URL이 안전하게 전송될 수 있기를 바랬고

• 안전한 전송이란, 정보가 유실될 위험 없이 URL을 전송할 수 있다는 것을 의미한다. 문자가 제거되는 일을 피하고자 URL은 상대적으로 작고 일반적으로 안전한 알파벳 문자만 포함하도록 허락한다.

2. 가독성도 있기를 바랬다.

URL 설계자들은 이런 결론을 내렸다.

1. 특정 문자 사용 금지.

• 따라서 출력이 되지 않거나 보이지 않는 문자를 이메일 프로그램에서 사용할 수 있다고 해서, 그리고 그 문자들이 변환될 수 있다 하더라도, URL에서 그런 문자들을 사용하는 것은 금지되었다.

2. 알파벳 이외의 문자도 포함될 수 있도록 이스케이프 기능 추가

• 사람들이 알파벳 이외의 문자도 포함하려고 할 때가 있다는 것을 알게 되어 이스케이프라는 기능을 추가하여 안전하지 않은 문자를 안전한 문자로 인코딩할 수 있게 하였다.

2.1 URL문자 집합

1. 역사적으로 많은 컴포터 어플리케이션이 US-ASCII 문자 집합을 사용해 왔다.
2. US-ASCII는 문자를 서식화하고 하드웨어상에서 신호를 주고받기 위해, 7비트를 사용하여 영문 자판에 있는 키 대부분과 몇몇 출력되지 않는 제어 문자를 표현한다.
3. 미국인들에게는 편리하지만, 유럽언어나 수백가지 비 라틴계 언어들에 존재한는 변형된 문자들까지 US-ASCII가 지원하지 않는다.
4. URL이 특정 이진데이터를 포함해야하는 경우도 있다.

이런 경우를 지원하기 위해서 이스케이프 문자열을 쓸 수 있게 설계하였다.

• 이스케이프 문자열은 URL에서 사용이 금지된 문자들로, 특정 문자나 데이터를 인코딩할 수 있게 함으로써 이동성과 완성도를 높였다.

2.2 인코딩 체계

URL에 있는 안전하지 않은 문자들을 표현할 수 있는 인코딩 방식이 고안되었다. 인코딩은 이스케이프 문자로 바꿔준다.

• 이스케이프 문자 (퍼센트 문자 ): %로 시작해 ASCII 코드로 표현되는 두개의 16진수 숫자로 이루어져있다.

예시

• ~ → 126 (0x7E) → %7E
• → 32 (0x20) → %20
• % → 37 (0x25) → %25

2.3 문자 제한

1. 몇몇 문자는 URL에서 특별한 의미로 예약되어있다.
2. 어떤 문자는 US-ASCII의 출력 가능한 문자 집합에 포함되어있지 않다.
3. 몇몇 인터넷 게이트웨이와 프로토콜에서 혼동되는 것으로 알려져 있어 사용을 지양하고 있다.

URL 예약어

• % : 인코딩 이스케이프 토큰
• / : 경로 컴포넌트 세그먼트를 나누는 용도
• . : 경로 컴포넌트에서 사용
• .. : 경로 컴포넌트에서 사용
• # : fragment 컴포넌트에서 사용
• ? : 쿼리파라미터 컴포넌트에서 사용
• ; : 매트릭스 파라미터 컴포넌트에서 사용
• : : 스킴, 사용자 이름/비밀번호, 호스트/포트의 구획문자로 사용
• $ : 미리 선점되었다.
• + : 미리 선점되었다.

게이트웨이에서 불안하게 다루기 때문에 제한

• { } | \ ~ [ ] ・
  • 게이트웨이와 같은 여러 전송 에이전트에서 불안하게 다루기 때문에 제한됨
• < > "
  • 안전하지 않음.
  • 웹 문서에서 URL을 구분지어 표시s하듯이 URL 범위 밖에서 역할이 있는 문자이기 때문에 반드시 인코딩해야한다.

US-ASCII 관련

• 0x00-0x1F 0x7F
  • 제한됨.
  • 이 16진수 범위에 속하는 문자들은 인쇄되지 않는 US-ASCII 문자다.
• > 0x7F
  • 제한됨.
  • 이 16진수 범위에 속하는 문자들은 7비트 US-ASCII 문자가 아니다.

3. 편리한 URL 사용을 위한 상황별 단축 URL

웹 클라이언트는 몇몇 단축 URL을 인식하고 사용한다.

1. 상대URL은 리소스 안에 있는 리소스를 간결하게 기술하는데 사용
2. URL확장은 사용자가 기억하고 있는 URL 일부를 입력하면 나머지 부분을 자동으로 입력해준다.

3.1 상대 URL

URL은 2가지로 나뉜다.

• 상대 URL : 모든 정보를 담고 있지 않다. 기저(base)URL을 사용해야한다.

• 절대 URL : 리소스에 접근하는데 필요한 모든 정보를 가지고 있다.

• 문서의 URL을 기준으로 상대경로로 해석될 수 있다.

• 상대URL은

  • fragment이거나
  • URL 일부다.

브라우저 같은 어플리케이션은 상대URL과 절대URL 간에 상호 변환을 할 수 있어야 한다.

기저 URL

기저 URL 찾는 방법

1. 리소스에서 명시적으로 제공 <base> HTML 태그를 기술할 수 있다. (base )
2. 리소스를 포함하고 있는 기저 URL 해당 리소스의 URL을 기저 URL로 쓸 수 있다.
3. 기저URL이 없는 경우 불안전하거나 깨진 URL일 수도 있다.

상대 참조 해석하기

상대 URL과 기저을 각각의 컴포넌트 조각으로 나누는 것이다. URL분해하기 = URL 파싱하기 변환을 위해서 특정 알고리즘을 사용한다. 이 알고리즘은 상대URL을 절대URL 형태로 변환한다.

3.2 URL 확장

1. 호스트명 확장

• yahoo.com ⇒ www.yahoo.com 을 만든다.
• 사용자의 시간을 절약하고 혼란을 막아준다.
• 호스트명에 대한 확장 기능은 프락시와 다른 HTTP 어플리케이션에 문제를 발생시킬 수도 있다.

2. 히스토리 확장

• 과거에 사용자가 방문했던 URL의 기록을 저장해놓는다.

4. 접근하는 방법의 종류(스킴의 종류)

참고자료

• 2. HTTPs://developer.mozilla.org/en-US/docs/Learn/Common_questions/What_is_a_domain_name
• 2. HTTPs://developer.mozilla.org/ko/docs/Learn/Common_questions/What_is_a_URL

Related