URL
scheme://호스트/리소스의 위치
http://www.server.com/resource/abcd.gif
브라우저(클라이언트)가 필요로 하는 리소스를 찾을 수 있게 리소스의 위치를 가리키는 식별자로
이를 통해 HTTP 및 다른 프로토콜을 통해 접근할 수 있다.
URL 문법
스킴(HTTP, FTP, SMTP 등)에 따라 문법이 조금씩 달라지긴 하지만
대부분의 문법은 일반적으로 아래와 같이 9개의 컴포넌트로 나뉜다.
<스킴>://<사용자명>:<비밀번호>@<호스트>:<포트>/<경로>;<파라미터>?<질의>#<프래그먼트>
이 모두를 사용하는 URL은 거의 없고, 핵심 컴포넌트는 스킴, 호스트, 경로다.
스킴
스킴은 URL을 사용하는 애플리케이션에게 어떤 프로토콜을 사용해 리소스를 요청할지 알려준다.
주로 http, ftp, rtsp, smtp 같은 프로토콜이 있고 알파벳으로 시작해야 하며
대소문자를 구분하지 않고 URL의 다른 컴포넌트와 : 로 구분한다.
호스트와 포트
www.host.com:80
호스트는 리소스를 호스팅 하고 있는 장비와 리소스에 접근할 수 있는 장비를 나타내는 컴포넌트로
호스트를 통해 장비에 접근하고 포트를 통해 접근한 장비에서 실행 중인 서버에 접근할 수 있다.
사용자 이름과 비밀번호
ftp://name:password@ftp.abc.def/ghj
서버가 가지고 있는 데이터에 접근을 허용하기 위해 요구하는 컴포넌트로 주로 FTP에서 사용되며
사용자 이름과 비밀번호를 요구하지 않는다면 굳이 사용할 필요는 없다.
경로
리소스가 서버의 어떤 경로에 있는지 알려주는 컴포넌트로 계층적 파일 시스템 경로와 유사한 구조를 가지며
'/' 문자를 기준으로 경로 조각으로 나뉘고, 각 경로 조각은 파라미터 컴포넌트를 가질 수 있다.
파라미터
ftp://exam.ex/e;type:d
ftp://exam.ex/e;type:d/test;type:b
애플리케이션이 서버에 정확한 요청을 하기 위해 필요한 입력 파라미터를 받는 데 사용하는 컴포넌트로
이름/값 쌍의 리스트로 URL의 다른 컴포넌트와 ';' 문자로 구분한다
질의 문자열
http://www.server.com/data/check?id=1234&name=test
데이터베이스 같은 서비스들이 요청받을 리로스 형식의 범위를 효율적으로 좁히기 위해 사용하는 컴포넌트로
URL에서 물음표(?)와 물음표의 우측에 오는 질의 컴포넌트로 구성된다.
질의 컴포넌트는 이름=값 쌍 형태를 가지고 있고 각각의 질의 컴포넌트는 '&'로 구분한다.
프래그먼트
http://www.server.com/index.html#test
리소스의 특정 부분을 가리킬 수 있는 컴포넌트로 용량이 큰 텍스트의 특정 절을 가리키거나
HTML 문서의 특정 이미지나 일부분을 가리킬 수 있고 URL의 오른쪽에 # 문자에 이어서 온다.
일반적으로 HTTP 서버는 일부가 아닌 전체를 다루기 때문에 클라이언트가 서버에 프래그먼트를 전달하는 것이 아닌
클라이언트가 서버에게 전체 리소소를 받아 프래그먼트를 사용해 일부분을 보여준다.
단축 URL
리소스 안에 있는 리소스를 간결하게 기술하는 데 사용할 수 있는 방식의 URL
상대 URL
기저 URL : http://www.server.com/index.html
상대 URL : ./test.html
사용 예시 : <a href = "./test.html">
새로운 절대 URL :http://www.server.com/test.html
이전까지 살펴본 URL은 절대 URL로 리소스에 접근하기 위해 필요한 모든 정보를 갖고 있다면
상대 URL은 모든 정보를 담고 있지 않기 때문에 기저(base)라는 다른 URL을 사용해 필요한 정보를 얻어야 한다.
상대 URL만으로는 리소스에 접근할 수 있는 온전한 URL을 알 수 없지만
기저 URL에 스킴과 호스트 등의 컴포넌트가 모두 포함되어 있어 이를 참고해 온전한 URL을 얻을 수 있다.
위와 같은 과정으로 기저 URL을 얻어 절대 URL이 만들어진다.
URL 확장
브라우저가 사용자가 URL을 빠르게 입력할 수 있게 지원하는 자동완성 기능이다.
naver를 입력하면 호스트명에 자동으로 'www.'과 '.com'을 붙여서 'www.naver.com'을 만들어주는
단순한 휴리스틱만 사용하는 호스트 명 확장 방식과
과거에 사용자가 방문했던 URL 기록을 저장해 두고 이를 사용해 입력에 따른 선택 목록을 보여주는
히스토리 확장 방식이 있다.
미래
URL은 주소이지 실제 이름이 아니기 때문에 리소스가 특정 시점에 어떤 곳에 위치하고 있다는 것을 알려줄 뿐이라
리소스가 옮겨지면 더 이상 사용할 수 없는 URL이 되어버리고 기존 URL이 가리키고 있던 객체를 찾을 수 없다.
이런 문제를 예방하기 위해서는 객체의 위치와 상관없이 그 객체를 가리키는 고유한 실제 이름을 사용하는 것으로
그러한 방법이 바로 이전에 간단하게 살펴봤던 URN이다. (PURL)
하지만 주소 체계를 바꾸는 표준화 작업은 매우 큰 작업이기 때문에 많은 시간이 필요하고
이러한 작업이 긴급하진 않기 때문에 앞으로 당분간은 URL이 계속 사용될 것이다.
'Book' 카테고리의 다른 글
[친절한 SQL 튜닝] SQL 처리 과정과 I/O (0) | 2025.03.02 |
---|---|
[HTTP 완벽 가이드] HTTP: 웹의 기초 - 개관 (1) | 2024.03.06 |