URL(Uniform Resource Locator)이란?

URL은 웹을 뒷받치는 주소체계다.

웹은 수 많은 파일이 연결되어 있는 공간이다. 따라서, 웹에 존재하는 파일을 다른 파일과 구별하는 효과적인 식별자가 필요하다. 웹에서는 파일을 자원 또는 리소스(resource)라고 부르는데 방대한 웹에서 이 자원을 구별하는 식별자가 바로 URL이다. 즉, URL은 웹에서 접근가능한 자원의 주소를 일관되게 표현하는 형식이다.

조금 어려워보이지만 우리가 매일 사용하는 웹은 URL로 구성되어 있다. 웹에서 신문을 읽거나 검색을 하거나 트위터를 사용할 때 모르는 사이에 URL로 만들어진 주소체계를 이용하고 있는 것이다.

URL의 구성

한우에도 부위마다 이름이 있는 것처럼 URL을 구성하는 부분에도 명칭이 있고 각자의 역할이 있다. URL의 구성품도 어느 하나 버릴것이 없다.

• 프로토콜: URL은 자원을 접근하는 방법인 스킴scheme으로 시작한다. 스킴보다는 프로토콜이라고 부르는게 일반적이므로 앞으로는 프로토콜이라고 쓰겠다.
• 사용자정보: 사용자 아이디와 비밀번호를 사용자정보userinfo로 부른다. 잘 사용하지 않기 때문에 따로 설명하지 않겠다. (예: https://username:password@www.example.com/)
• 호스트: 그리고 호스트 주소가 나온다. IP 또는 www.example.com과 같은 도메인명을 쓴다. 호스트명:포트번호 형태로 포트번호를 쓸 수 있는데 선택사항이다.
• 경로: 호스트 주소 다음에 /으로 시작하는 경로가 나온다. 윈도우의 디렉토리나 폴더와 비슷하다고 보면 된다. 루트 디렉토리가 /으로 시작하는 것이 윈도우와 다르다 (예: https://www.example.com/).
• 매개변수: 그 다음은 웹서버에 보내는 추가 매개변수(Query 또는 Parameters)가 온다.
• 부분식별자: 마지막으로 #으로 시작하는 부분 식별자(fragment identifier)가 온다.

프로토콜

프로토콜은 웹에서 서버와 클라이언트간에 어떤 방법으로 자원을 접근할지 알려준다. 웹브라우저에서 가장 많이 사용되는 https/http외에도 mailto: (이메일 주소를 지정하는 프로토콜), ftp: (파일을 주고받는 프로토콜) 등 다양한 프로토콜이 존재한다.

우리가 가장 많이 사용하는 HTTP는 Hyper Text Transfer Protocol이라는 어려운 이름의 약자인데 쉽게 설명하면 웹브라우저와 웹서버 사이에서 웹 문서와 그것을 구성하는 자원을 전송하기 위한 프로토콜이다. 요즘은 HTTPS를 기본 프로토콜로 쓰는데, (https를 지원하지 않는 웹사이트는 여전히 http를 쓴다) HTTP에 보안이 강화된 버전이다.

호스트

URL에서 웹서버의 위치를 지정한다. 도메인 이름(예: www.example.com)이나 IP 주소(예: 127.0.0.1)를 사용할 수 있다.

도메인 이름 뒤에 오는 :80는 포트번호다. 웹서버에서 자원을 접근하기 위해 사용하는 관문(gate)을 가리키는데, 표준 HTTP 포트는 80번 HTTPS는 443이다. 표준 포트를 사용한다면 포트번호는 보통 생략한다.

경로

웹서버에서 자원에 대한 경로다. 실제 물리적 경로가 아니고 웹서버에서 추상화한 경로다(물론 웹서버 설정에서 물리적 경로를 추상화 경로로 사용할 수 있다).

루트 자원을 나타내려면 “/”을 사용한다. 예) https://www.example.com/

루트의 robots.txt를 지정한다면 다음과 같다. 예) https://www.example.com/robots.txt

본 문서의 후반부에서 자세히 설명하겠지만 URL은 ASCII 문자세트에 포함된 문자만 허용한다. 뿐만 아니라, ASCII 문자세트에서도 허용되지 않는 문자가 있다. 이 경우 “%”로 시작하는 16진수로 문자코드를 넣는다. 여러 문자가 있지만 공백(space) 문자를 주목할 필요가 있다. 공백 문자는 그냥 쓰면 안되고 플러스 문자(+)나 “%20”로 치환해야 한다.

예)
https://www.example.com/hello world.html (X)
https://www.example.com/hello+world.html (O)

매개변수 (Query 또는 Parameters)

웹서버에 보내는 추가 파라메터다. 파라메터 하나는 키와 값으로 짝을 이룬다. 파라메터가 여러개면 &문자로 구분한다. 키와 값은 =문자로 구분한다. 웹서버에서 어떤 파라메터를 실제로 지원하는지는 웹서버마다 다르다. 웹서버는 지원하지 않는 파라메터는 무시한다.

부분 식별자 (Fragment identifier)

URL이 지정하는 자원의 세부 부분을 지정할때 쓴다. 부분 식별자가 없어도 그 앞에 오는 URL만으로도 웹의 어떤 자원을 정확히 지정할 수 있다. 부분 식별자는 자원 안에서 어떤 부분을 가르키는 역할을 한다. 부분 식별자가 쓰이는 대표적인 사례는 위키피디어 백과사전이다. 부분 식별자를 세부항목에 대한 책갈피bookmark로 쓸 수 있어서 어떤 글에서 특정 항목으로 바로 이동할 수 있다.

예) https://ko.wikipedia.org/wiki/대한민국#문화 : 위키피디어 “대한민국” 문서에서 “문화” 세부주제로 바로 갈 수 있다.

참, URL에는 ASCII 문자외에는 쓸 수 없다고 했는데 어떻게 한글이 쓰였을까? 자연스럽게 다국어 지원에 대한 이야기로 넘어가자.

다국어 지원

URL에 ASCII 문자 집합외에도 유니코드에서 지원하는 모든 문자를 사용할 수 있다. 물론 조금 복잡해지는 것만 참으면.

도메인 이름과 경로 등에서 다국어를 쓰는 법이 다른데. 도메인 이름에서는 퓨니코드라고 부르는 인코딩 방법으로 만들어진 코드를 “xn--” 문자 뒤에 붙여서 쓴다. 예를 들어, “wiki백과.com”은 “xn--wiki-ei4p334e.com”이 된다.

경로 등에서는 % 다음에 Unicode 코드포인트를 쓴다. 예를 들어, https://ko.wikipedia.org/wiki/대한민국 의 실제 주소는 다음과 같다.
https://ko.wikipedia.org/wiki/%EB%8C%80%ED%95%9C%EB%AF%BC%EA%B5%AD

“EB 8C 80”의 UTF-8 3 byte로 된 “대”라는 문자의 코드다. 각 바이트의 16진수에 %을 붙여서 %EB%8C%80이 된 것이다.

그런데 크롬같은 웹브라우저에서는 %로 시작하는 복잡한 코드를 보여주지 않고 사용자가 읽기 쉬운 “대한민국”이라고 표시된다. 이것은 웹브라우저가 사용자에게는 읽기 쉬운 글자로 보여주고 내부적으로는 인코딩된 주소를 사용하기 때문이다.

URL 인코딩 (URL Encoding)

URL을 인코딩해야 하는 경우 https://www.urlencoder.org/ 등의 무료 서비스를 이용하거나 JavaScript에서 encodeURI (반대로 인코딩된 URL을 디코딩하는 경우는 decodeURI) 등을 쓸 수 있다.

JavaScript의 예)
var url = “https://ko.wikipedia.org/wiki/대한민국”;
var encoded = encodeURI(url);
var decoded = decodeURI(encoded);

console.log(encoded); // “https://ko.wikipedia.org/wiki/%EB%8C%80%ED%95%9C%EB%AF%BC%EA%B5%AD”
console.log(decoded); // “https://ko.wikipedia.org/wiki/대한민국”

다음의 표는 많이 사용하는 문자에 대한 인코딩 값이다.

문자	인코딩후	문자	인코딩후
공백(space)	%20	!	%21
“	%22	#	%23
$	%24	%	%25
&	%26	‘	%27
(	%28	)	%29

URL 정규화 (URL Normalization)

URL 정규화는 URL을 정형화된 형태로 변환하는 과정이다. 정규화 과정에서 동일한 웹 리소스를 나타내는 여러개의 URL들을 문법적으로 동일한 URL을 표현하는 것이다. 주로 검색 엔진에서 URL 정규화를 통해 중복되는 콘텐츠를 줄이는데 사용한다.

예를 들어, RFC 3986 표준에서는 다음과 같은 정규화를 한다.

• 프로토콜과 도메인명을 소문자로 변환: 예) HTTPS://www.Example.COM/ -> https://www.example.com/
• 지정되지 않는 경로의 경우 루트 경로 추가: 예) https://example.com -> https://example.com/
• 기본 포트 제거: 예) http://example.com:80/ -> http://example.com/
• %-인코딩된 문자열을 대문자로 변환: 예) https://example.com/foo%2a -> https://example.com/foo%2A
• 도트 세그먼트 삭제: 경로상에 . 나 .. 가 있는 경우 삭제. 예) https://example.com/foo/./bar/../baz -> https://example.com/foo/bar/baz
• %-인코딩이 필요없는 문자를 원래 코드로 복원: 알파벳 (%41–%5A and %61–%7A), 숫자 (%30–%39), 하이픈 (%2D), 구두점 (%2E), 밑줄 (%5F), or 물결 (%7E) 문자는 %-인코딩하지 않아도 된다. 따라서 원래 문자로 복원된다. 예) https://example.com/%7Efoo -> https://example.com/~foo

절대 URL, 상대 URL

지금까지 이야기한 URL은 모두 절대 URL이다. URL에서 필수적으로 필요한 프로토콜, 호스트, 경로까지 모두 가지고 있다. 반면 문맥에 의존하는 상대 URL도 있다.

웹브라우저의 주소창에는 문맥이 없기 때문에 절대 URL을 써야한다. 그러나 HTML 페이지 안에서 어떤 리소스를 포함할 때는 호스트 페이지의 문맥안에서 상대 URL을 쓸 수 있다.

예를 들어, 다음의 URL은 절대 URL이다.
https://www.betterweb.or.kr/foo/index.html

위의 index.html 웹페이지의 내용에 다음의 앵커 태그가 있다고 가정하자.

<a href="bar.html">Relative foo</a>

bar.html은 상대 URL이고 절대 URL로 변환하면 https://www.betterweb.or.kr/foo/bar.html 이다. 다른 예를 보자.

<a href="../parent.html">Relative root</a>

../parent.html의 절대 URL은 https://www.betterweb.or.kr/parent.html 이다.

텍스트 부분식별자 (Text Fragment)

텍스트 부분식별자는 URL 부분식별자에 텍스트 스니펫을 지정하는 기능이다. 웹브라우저가 텍스트 부분식별자가 포함된 URL로 이동할 경우 문서의 해당 텍스트로 자동으로 이동하고 강조하는 기능이다. 텍스트 부분식별자는 W3C의 WCIG그룹에서 제안(https://wicg.github.io/scroll-to-text-fragment/)하였고 Chrome은 버전 80부터 기능을 지원한다.

사용방법은 간단하다. URL의 # 문자(부분식별자 영역) 다음에 :~:text= 을 추가하고 강조할 문자열을 지정하면 된다.

#:~:text=문자열

예를 들어, 다음은 BTS 위키피디어 URL에 “most tweeted-about celebrities”를 텍스트 부분식별자로 추가한 것이다. 링크를 클릭하면 웹브라우저는 해당 부분으로 스크롤하고 매칭되는문자열을 강조하여 보여줄 것이다.

https://en.wikipedia.org/wiki/BTS#:~:text=most%20tweeted-about%20celebrities

쉼표를 이용하여 영역을 지정할 수도 있다.

#:~:text=시작문자열,종료문자열

https://en.wikipedia.org/wiki/BTS#:~:text=stands%20for,scouts

URL 사용시 주의할 점

타이포스쿼팅Typosquatting

인터넷 사용자들이 웹사이트 주소를 잘못 입력하는 실수를 예상하여 원본주소와 유사한 도메인을 미리 등록하는 행위. URL 하이재킹(hijacking)이라고도 한다.

예를 들어, google.com 대신 gooogle.com (‘o’가 세개다)을 입력할 것을 예상하여 gooogle.com 도메인을 선점하고 마치 원본 사이트인것처럼 조작하여 멀웨어를 심거나 사용자 정보를 요구하여 가로채기도 한다. 물론, 구글은 타이포스쿼팅을 예방하기 위해 gooogle.com을 포함하여 비슷한 도메인을 모두 소유하고 있다.

비슷한 도메인을 선점하는 것 외에도 SSL을 적용하여 사용자에게 실제 사이트라는 신호를 줄 수도 있다. SSL이 적용되지 않은 사이트(https)는 웹브라우저에서 위험하다고 경고를 해준다.

클린 URL (Clean URL)

클린 URL은 일반 사용자들도 쉽게 의미를 파악할 수 있고 검색 엔진에 친화적인 URL이다. 웹서버에서 정보를 관리하는 내부 구현방식과 분리되어 있고 웹사이트에서 제공하는 정보의 개념적 구조를 잘 반영한다. 따라서, 사용자가 URL이 지정하는 리소스가 무엇인지 쉽게 파악할 수 있다. 또, 논리적으로 정리된 구조를 따르므로 검색 엔진 최적화에도 좋다.

클린 URL은 example.php, example.asp 처럼 내부 구현 방식, 사용자에게 의미없는 내부 데이터베이스 식별자, 세션 ID 등을 포함하지 않는 등 서버 구현 및 사용자 환경에 따라 바뀌지 않는 URL이다.

예를 들면 (O)표한 URL이 클린 URL이다.
https://betterweb.or.kr/index.php?page=name (X)
https://betterweb.or.kr/name (O)
https://betterweb.or.kr/cgi-bin/feed.cgi?feed=news&frm=rss (X)
https://betterweb.or.kr/news.rss (O)
https://betterweb.or.kr/index.php?mod=profiles&id=193 (X)
https://betterweb.or.kr/profiles/193 (O)
https://betterweb.or.kr/blog?article_id=10023 (X)
https://betterweb.or.kr/blog/서치_콘솔 (O)

URL 단축 서비스 (TinyURL, Bitly)

이메일이나 트위터에 URL을 추가할때 긴 문자열 때문에 불편했던 적이 있는가? URL 단축 서비스는 긴 URL을 짧게 만들어주는 서비스이다. 케빈 길벗슨이라는 웹개발자가 2002년에 뉴스그룹에 글을 올릴 때 URL을 단축시키려고 TinyURL이라는 서비스를 만들면서 시작되었다. 이후 비슷한 서비스가 100여개 이상 나왔고 Bitly와 트위터 서비스인 t.co 등이 많이 쓰이고 있다.

TinyURL은 tinyurl.com에서 Bitly는 bit.ly에서 URL을 단축할 수 있다. 트위터는 긴 URL을 자동 단축해주며 단축된 URL은 t.co 도메인을 사용한다.

 

 

출처:https://www.betterweb.or.kr/blog/url%EC%9D%B4%EB%9E%80/