위키원
"URL"의 두 판 사이의 차이
잔글 (→같이 보기) |
잔글 |
||
| 9번째 줄: | 9번째 줄: | ||
== 등장배경 == | == 등장배경 == | ||
| − | 1994년에 [[팀 버너스 리]](Tim Berners-Lee)가 하이퍼텍스트를 제안하면서 하이퍼링크의 대상이 되는 자원을 대표하는 짧은 문자열로 URL의 개념을 도입하였다. 그 당시에 사람들은 이것을 "하이퍼 텍스트 이름"이나 "문서 이름"으로 불렀었다. 향후 3년 반 동안 HTML, HTTP 그리고 웹 브라우저에 대한 웹의 핵심 기술이 개발됨에 따라서 리소스 주소를 제공하는 문자열과 단순 리소스라는 이름의 문자열을 구분해야 했다. URL과 URN 정의에 대한 토론에서 URL과 URN으로 구현된 개념은 단지 자원 식별의 기본적인 개념이라는 측면에 불과하다는 것이 분명해졌다. 1994년 6월 IETF는 URL과 URN의 존재를 인정한 최초의 의견 요청인 팀 버너스 리의 RFC 1630을 출판했다. 또한 | + | 1994년에 [[팀 버너스-리]](Tim Berners-Lee)가 하이퍼텍스트를 제안하면서 하이퍼링크의 대상이 되는 자원을 대표하는 짧은 문자열로 URL의 개념을 도입하였다. 그 당시에 사람들은 이것을 "하이퍼 텍스트 이름"이나 "문서 이름"으로 불렀었다. 향후 3년 반 동안 HTML, HTTP 그리고 웹 브라우저에 대한 웹의 핵심 기술이 개발됨에 따라서 리소스 주소를 제공하는 문자열과 단순 리소스라는 이름의 문자열을 구분해야 했다. URL과 URN 정의에 대한 토론에서 URL과 URN으로 구현된 개념은 단지 자원 식별의 기본적인 개념이라는 측면에 불과하다는 것이 분명해졌다. 1994년 6월 IETF는 URL과 URN의 존재를 인정한 최초의 의견 요청인 팀 버너스-리의 RFC 1630을 출판했다. 또한 [[RFC]]는 당시에 사용 중인 URL 체계의 구문을 요약하려고 시도했다.<ref>Uniform Resource Identifier Wikipedia -https://en.wikipedia.org/wiki/Uniform_Resource_Identifier#History</ref> |
== 특징 == | == 특징 == | ||
2020년 8월 24일 (월) 00:23 판
URL(유알엘)은 "Uniform Resource Locator"의 약자로서, 인터넷에 존재하는 각종 정보들의 유일한 위치를 표시하는 주소 식별자(identifier)이다. URL은 http:// 나 https:// 또는 ftp:// 등 프로토콜 종류를 표시하고, 도메인명과 폴더 및 파일명을 표시한다. URL 중에서 http:// 와 https:// 로 시작하는 것을 흔히 웹주소라고 부른다. 예를 들어, 웹주소는 "http://www.domain.com/folder/file.htm"와 같이 표현한다.
개요
URL은 네트워크상에서 자원이 어디 있는지를 알려주기 위한 규약이자 컴퓨터가 서버와 통신하는 데 사용하는 숫자(IP주소)를 대체하도록 설계된 사람이 읽을 수 있는 텍스트다. 즉, 컴퓨터 네트워크와 검색 메커니즘에서의 위치를 지정하는, 웹 리소스에 대한 참조이다. URL을 통해 웹 페이지를 찾을 수 있으며, 주어진 웹사이트에서 파일 구조를 식별할 수 있다. 흔히 웹 사이트 주소로 알고 있지만, URL은 웹 사이트 주소뿐만 아니라 컴퓨터 네트워크상의 자원을 모두 나타낼 수 있다. 그 주소에 접속하려면 해당 URL에 맞는 프로토콜을 알아야 하고, 그와 동일한 프로토콜로 접속해야 한다. FTP 프로토콜인 경우에는 FTP 클라이언트를 이용해야 하고, HTTP인 경우에는 웹 브라우저를 이용해야 한다. 텔넷의 경우에는 텔넷 프로그램을 이용해서 접속해야 한다.[1]
URL은 프로토콜, 도메인 이름 및 경로 로 구성된다.[2] 포털사이트 홈페이지(http;//www.google.com)를 예로 들어보면, http는 인터넷에서 서로 다른 컴퓨터끼리 데이터를 주고받기 위한 규칙이다. 이 통신 규약 뒤에는 콜론을 붙이고 도메인 네임이나 IP주소를 더 써야 하는 경우에는 슬래시 두 개(//)를 붙여준다. 'www.google.com'은 인터넷 사이트의 도메인 네임으로, 우리가 원하는 정보가 google이라는 이름을 가진 서버 안에 들어있기 때문에 그곳에 접속하겠다는 의미다. 그리고 google에 속한 여러 웹페이지를 들어가게 된다면 도메인 이름 뒤에 슬래시 한 개(/)가 더 붙게 된다. 웹사이트 외에도 네트워크를 사용하는 곳이면 어디서든 URL을 이용하여 필요한 정보나 자원이 어디에 있는지 나타낼 수 있다. 이처럼 URL은 인터넷 도메인 이름이나 IP 주소, 이메일, 파일 전송 등 컴퓨터 네트워크 정보를 이용하는 것들에 적용할 수 있다.[3]
이론적으로 각각의 유일한 URL은 유일한 자원을 가리킨다. 그런 자원은 HTML페이지, CSS문서, 이미지 등이 될 수 있다. 실제로, 여러 예외가 있는데, 가장 흔한 URL은 더 이상 존재하지 않는 자원이나 옮겨진 자원을 가리키는 것이다. URL에 의해 표현된 자원과 URL 자체는 웹서버에 의해 다뤄지기 때문에, 자원과 관련 URL을 주의 깊게 관리하기 위해 웹서버의 소유자에게 달려있다.[4] URL은 일반적으로 웹 브라우저의 상단(주소 표시줄)에 입력·표시 하기 때문에 'URL = 인터넷 주소'라고 인식하는 사람들이 있지만 정확한 표현이라고 할 수 없다. 인터넷을 서핑할 때 주로 입력하는 '주소'는 도메인이름이나 IP주소인데, 이것은 해당 인터넷 서비스를 제공하는 컴퓨터의 위치를 나타내는 것이고, 해당 서비스를 제공하는 컴퓨터의 특정 정보 자원을 지칭하는 것이 아니기 때문이다.[5]
등장배경
1994년에 팀 버너스-리(Tim Berners-Lee)가 하이퍼텍스트를 제안하면서 하이퍼링크의 대상이 되는 자원을 대표하는 짧은 문자열로 URL의 개념을 도입하였다. 그 당시에 사람들은 이것을 "하이퍼 텍스트 이름"이나 "문서 이름"으로 불렀었다. 향후 3년 반 동안 HTML, HTTP 그리고 웹 브라우저에 대한 웹의 핵심 기술이 개발됨에 따라서 리소스 주소를 제공하는 문자열과 단순 리소스라는 이름의 문자열을 구분해야 했다. URL과 URN 정의에 대한 토론에서 URL과 URN으로 구현된 개념은 단지 자원 식별의 기본적인 개념이라는 측면에 불과하다는 것이 분명해졌다. 1994년 6월 IETF는 URL과 URN의 존재를 인정한 최초의 의견 요청인 팀 버너스-리의 RFC 1630을 출판했다. 또한 RFC는 당시에 사용 중인 URL 체계의 구문을 요약하려고 시도했다.[6]
특징
구성
- 프로토콜(protocol) : URL의 맨 앞에 있는 것은 프로토콜이라고 하는데, 이것은 컴퓨터 네트워크상에서 서로 다른 컴퓨터끼리 데이터를 주고받기 위한 통신 규약 중 하나다. URL에서 많이 쓰이는 대표적인 프로토콜인 HTTP와 HTTPS 중에서 HTTP는 인터넷에서 웹 브라우저로 문서나 파일을 표시하기 위한 공통 규약이므로, 이 URL은 일반적인 인터넷 서핑을 위한 것임을 알 수 있다. 프로토콜 뒤에는 콜론(:)을 적고 도메인 이름이나 IP 주소로 이어지는 경우 콜론(:) 뒤에 슬래시 2개(//)를 덧붙여준다. HTTPS는 웹상에서 정보, 주로 html문서를 주고받을 수 있는 프로토콜 이며. 일반적인 웹 사이트에서 가장 많이 쓰인다. 해당 프로토콜을 통해서 클라이언트(사용자의 컴퓨터)와 서버(서비스를 제공하는 컴퓨터) 사이에 이루어지는 요청과 응답을 주고받을 수 있다.[5]
- 정보 자원을 가진 컴퓨터의 위치 : 프로토콜 뒤에 표시된 것은 접속하고자 하는 네트워크상의 컴퓨터 위치다. static.naver.com을 예로 들어보면, 네이버 사이트의 도메인 이름이므로 사용자가 원하는 네트워크 정보 자원이 네이버의 서버 컴퓨터 안에 있다는 것을 알 수 있다.
- 파일 디렉터리 : 컴퓨터 이름 뒤에 표시된 www/u/2010/0611/는 디렉터리를 뜻하는데, 예시의 경우 네이버 서버컴퓨터의 하드디스크에 'WWW'라는 이름의 디렉터리가 있으며 이 안에는 'u/2010/0611/'로 이어지는 하위 디렉터리가 포함되어 있다는 것을 알 수 있다. 파일 디렉터리는 생략할 수 있으며, 이 때는 컴퓨터 관리자가 정한 기본 디렉터리를 뜻하게 된다.
- 정보 자원 이름 : 마지막에 표시되는 것은 사용하는 사람이 얻으려고 하는 정보자원의 이름이다. 'nmms_215646753.gif'를 예로 들어보면, 확장자를 보면 알 수 있듯이 GIF 그림 파일의 일종이다. 따라서 사용자는 네이버의 서버 컴퓨터 안에 저장된 215646753.gif 라는 이름의 그림 파일을 보기 위해 위와 같은 URL을 입력했다는 것을 알 수 있다. 이것 역시 생략하는 경우가 많다. 생략되면 컴퓨터가 관리자가 정해놓은 기본 정보 자원 이름을 뜻하게 되는데, 보통은 index.html과 default.html 등이 있다.
- 다양한 규격의 URL 존재 : 위에서 예로 든 URL은 일반적인 인터넷 서핑 시에 입력하는 형식이다. 만약 http가 아닌 이메일 주소를 위한 통합 자원 식별자(URI) 스킴인 mailto 프로토콜로 시작하는 URL을 입력했다면 이메일을 보낼 수 있으며, FTP 프로토콜로 시작하는 URL을 입력했다면 FTP 서비스를 사용할 수 있다. 그 외에 원격 통신용인 텔넷(telnet), 유즈넷 뉴스용인 뉴스(news), 초창기 인터넷용인 고퍼(gopher) 등도 있지만 이것들은 대중적으로 많이 사용되지는 않는다.
- #·?·& : 인터넷 서핑 중에 사용하는 URL 중에는 '크로스 해치(#)'가 추가되는 경우도 있다. 이는 URL을 입력했을 때 해당 웹 페이지의 특정 참조 지점(앵커: anchor)으로 화면을 이동시키고자 할 때 사용하는 명령어다. 그 외에도 URL 도중에 물음표(?)나 앰퍼샌드(&)가 추가되는 경우도 있다. 이것은 매개변수라고 하며 사용하는 사람이 특정 검색어로 해당 페이지에 접속한 경우에, 또는 로그인한 상태에서 해당 페이지에 접속한 경우에 검색어나 로그인 정보 등의 매개변수가 물음표 뒤에 표시된다. 만약 매개변수가 복수일 때에는 이를 앰퍼샌드로 구분한다. 이 경우 프로그램상의 처리로 이것을 보이지 않게 하는 경우도 많다.[5]
- 슬래시(/) : URL의 끝에 붙이는 슬래시를 트레일링 슬래시(trailing slash)라고 부른다. 트레일링 슬래시를 URL 끝에 붙이는 이유는 해당 URL 리소스가 디렉터리라는 것을 의미한다. 이것을 붙이지 않은 것은 해당 URL 리소스가 파일이라는 것을 의미한다. 트레일링 슬래시가 있을 때와 없을 때에는 서버의 동작에 약간 차이가 있다. 트레일링 슬래시가 없는 URL은 해당 이름의 파일이 존재하는지 확인한 후 없으면 해당 이름의 디렉터리를 확인한다. 디렉터리가 있으면, 그 안의 기본 파일을 확인한다. 트레일링 슬래시가 있는 URL은 해당 이름의 디렉터리를 확인한 후, 디렉터리가 있다면 그 안의 기본파일을 확인한다. 따라서 디렉터리 리소스를 요청할 때에는, 트레일링 슬래시를 명시해주면 파일 확인 동작은 생략할 수있어서 페이지 응답속도에 작은 이득이 있다.[7]
구조
- HTTP : 프로토콜이다. URL의 첫 부분은 브라우저가 사용해야 하는 프로토콜을 나타낸다. 프로토콜은 컴퓨터 네트워크에서 데이터를 교환하거나 전송하기 위한 설정 방법이다. 일반적으로 웹 사이트의 경우 웹에는 HTTP 프로토콜 또는 보안 버전인 HTTPS, 이 두 가지 중 하나가 필요하지만, 브라우저는 mailto(메일 클라이언트 열기)와 FTP와 같은 다른 프로토콜을 처리하는 방법을 알고 있다.
- www.example.com : 도메인 이름이다. 요청 중인 웹서버를 나타낸다. IP 주소를 직접 사용할 수도 있지만 편리하지 않기 때문에 자주 사용되지는 않는다.
- :80 : 포트를 나타낸다. 웹서버가 HTTP 프로토콜의 표준 포트(HTTP의 경우 80, HTTPS의 경우 443)를 사용하여 자원에 대한 액세스 권한을 부여하는 경우에는 일반적으로 생략되지만 그렇지 않다면 포트 번호는 필수다.
- /path/to/myfile.html : 웹서버의 자원에 대한 경로다. 초기의 웹에서는, 웹서버 상에서 물리적 파일 위치를 나타냈지만, 요즘에는 실제 물리적 경로를 나타내지 않고 웹서버에서 추상화하여 보여준다.
- ?key1=value1&key2=value2 : 웹서버에 제공하는 추가 매개변수다. 이 매개변수들은 &기호로 구분된 키값으로 짝을 이룬 리스트다. 웹 서버는 자원을 반환하기 전에 추가적인 작업을 위해 이런 매개변수들을 사용할 수 있다. 각각의 웹서버는 매개변수들을 언급하는 자신의 규칙을 가지고 있다. 그리고 특정한 웹서버가 매개변수를 다루는지 알기 위한 유일한 방법은 웹서버 소유자에게 묻는 것이다.
- #SomewhereInTheDocument : 자원 자체의 다른 부분에 대한 앵커다. 앵커는 일종의 자원 안에서 북마크다. 즉, 북마크 된 지점에 있는 내용을 보여주기 위해 브라우저에 방향을 알려준다. 예를 들어, HTML 문서에서 브라우저는 앵커가 정의한 곳의 점을 스크롤 할 것이다. 비디오나 오디오 문서에서는 브라우저는 앵커가 나타내는 시간을 찾으려 할 것이다. #뒤에 오는 부분은 가치가 없고 부분 식별자(fragment identifier)라고 알려져, 요청이 서버에 보내지지 않는다.[8]
활용
- 간편 URN : 질의어 없이 경로만 가진 간단한 구조의 URL을 말한다. 사용자 친화적 URL, 검색엔진 친화적 URL 또는 간단하게 친화적 URL이라고도 부른다. 간편 URL은 깔끔하지 않은 URL에 비해서 기억하기 쉽고, 입력하기 쉽다는 장점이 있다. 간편 URL은 주로 검색엔진에 최적화하기 위해 사용된다. 그러면서도 사용성과 접근성도 높아진다. 불필요한 부분이 제거되어 URL을 입력하거나 기억하기 쉽게 된다. 다른 이유로는 웹 응용 프로그램의 실체를 드러내지 않기 위한 것도 있다. 예를 들어 URL에는 "example.php"와 "example.asp"와 같이 서버 측 스크립트의 이름이 포함되는 것이 보통이다. 바꿔쓰기 엔진을 활용하면 본래 파일들의 이름을 다른 URL로 바꿔쓸 수 있다.[9]
- URN : URL은 매우 유용하고 널리 사용된다. 그러나 리소스의 위치가 변경되면 URL을 찾을 수 없는 등의 문제가 있다. 이를 위해 URN의 개념이 도입되었지만, URL을 대체하는 것은 어려워 보인다. URL은 초보자가 고통을 받고 있지만, 당분간 계속 사용될 예정이다.[10]
문자
- URL 허용 문자
안전한 전송이란 클라이언트의 요청 URL 문자열이 손실되지 않고 서버 측으로 전송되는 것을 말한다. 안전한 전송을 위해 초기 URL 설계자들은 알파벳(정확하게는 ASCII)만으로 URL을 작성하도록 권장했다. 하지만 웹이 커짐에 따라 세계적으로 웹을 사용하게 되었고, 이에 따라 비영어권 나라에서 URL에 알파벳만을 사용하는 것은 문제가 있다고 판단하게 되었다. 이에 ASCII 외의 문자들을 이스케이프 처리를 하여, ASCII 문자가 아닌(안전하지 않은) 문자를 안전하도록 인코딩하고 있다. 인코딩을 통해 안전하지 않은 문자(ASCII가 아닌)를 % 기호로 시작하고 ASCII 코드로 표현되는 이스케이프 문자로 바꾼다.[11]
- URL에서 안전하지 않은 문자
URL에서 특정 목적으로 사용하는 값과 안전하지 않은 값이 있다. 대부분의 문자는 안전하지 않은 문자로 분류된다. 그 이유는 URL이 메일이나 FTP 등도 포함하는 넓은 개념이기 때문이다. 예를 들어 메일에서 허용하지 않는 값을 URL에서 사용하면 URL은 메일 주소를 올바르게 처리할 수 없다. 메일에서만 문제가 발생한다고 하더라도 이런 값은 장기적으로 문제를 일으킬 수 있다. 이런 값들을 안전하지 않은 값이라고 한다. 서비스의 안정성을 위해서 항상 안전한 값으로 변경해서 처리해야 한다. 안전한 값이라고 한다면 영어랑 몇몇 기호들이라고 생각하면 된다.[12]
- 특수문자 및 메타 문자
특수문자는 인코딩된 값으로 서버에 넘겨줘야 한다.[13] URL 인코딩은 문자나 특수문자를 웹 서버와 브라우저에서 보편적으로 허용되는 형식으로 변화하는 메커니즘이다. URL은 ASCII 문자 집합을 사용하여 인터넷을 통해서만 전송할 수 있고, 종종 ASCII 세트 외부의 문자를 포함하기 때문에 URL은 유효한 ASCII 형식으로 변환되어야 한다. URL 인코딩은 안전하지 않은 ASCII 문자를 % 다음에 두 개의 16진수로 대체한다. URL은 공백을 포함할 수 없다. URL 인코딩은 일반적으로 공백을 더하기(+) 기호 또는 %20으로 바꾼다. 한글, 일본어 등 ASCII 이외의 문자는 다 인코딩 해야 된다.[14]
특수문자처리 문자 URL 인코딩 문자 URL 인코딩 탭 %09 ? %3F 공백 %20 @ %40 ! %21 %3E " %22 { %7B # %23 } %7D % %25 [ %5B & %26 ] %5D ( %28 ' %60 ) %29 I %7C + %2B ~ %7E \ %5C , %2C . %2E / %2F : %3A ; %3B < %3C > %3E = %3D
중요 URL 메타문자는 다음과 같다.[15]
중요 URL 메타문자 종류 URL 코드 특징 ? %3F 인자(피라미터)를 넘겨줄 때 사용 & %26 각각의 인자를 구분할 때 사용 = %3D 인자 전달자로서 인자값을 인자로 전달할 때 사용 % %25 16진수(Hex)값을 표현할 때 사용 + - 공백 문자를 표현할 때 사용 NULL(공백) %00 공백을 표현할 때 사용
각주
- ↑ URL 위키백과 - https://ko.wikipedia.org/wiki/URL
- ↑ URL MOZ - https://moz.com/learn/seo/url
- ↑ URL 네이버 지식백과 - https://terms.naver.com/entry.nhn?docId=3609943&cid=58598&categoryId=59316
- ↑ What is a URL mozilla - https://developer.mozilla.org/ko/docs/Learn/Common_questions/What_is_a_URL
- ↑ 5.0 5.1 5.2 카메라맨, 〈URL이란 무엇인가?〉, 《네이버 블로그》, 2011-07-18
- ↑ Uniform Resource Identifier Wikipedia -https://en.wikipedia.org/wiki/Uniform_Resource_Identifier#History
- ↑ Uno Kim , 〈URL 끝에 '/'는 왜 붙이는 걸까? 〉, 《깃허브》, 2017-07-05
- ↑ What is a URL? moziila - https://developer.mozilla.org/ko/docs/Learn/Common_questions/What_is_a_URL
- ↑ 간편 URL 위키백과 -https://ko.wikipedia.org/wiki/%EA%B0%84%ED%8E%B8_URL
- ↑ 미래학자 , 〈URL과 리소스(HTTP 완벽 가이드) 〉, 《티스토리》, 2019-06-23
- ↑ victolee , 〈[ https://victorydntmd.tistory.com/287 (HTTP) URI, URL 구조]〉, 《티스토리》, 2018-10-03
- ↑ 미래학자 , 〈URL과 리소스(HTTP 완벽 가이드)〉, 《티스토리》, 2019-06-23
- ↑ GeunChoi , 〈[ https://m.blog.naver.com/csgct/220444910779 URL 특수문자처리]〉, 《네이버 블로그》, 2015-08-08
- ↑ 상큼과즙 FreshCrush.Jang , 〈URL 인코딩이란?〉, 《티스토리》, 2019-01-28
- ↑ 홍주 , 〈인코딩(Encoding)이란? 〉, 《티스토리》, 2019-07-03
참고자료
- URL MOZ - https://moz.com/learn/seo/url
- URL 위키백과 - https://ko.wikipedia.org/wiki/URL
- URL 네이버 지식백과 - https://terms.naver.com/entry.nhn?docId=3609943&cid=58598&categoryId=59316
- What is a URL mozilla -https://developer.mozilla.org/ko/docs/Learn/Common_questions/What_is_a_URL
- Uniform Resource Identifier Wikipedia -https://en.wikipedia.org/wiki/Uniform_Resource_Identifier#History</ref>
- Uno Kim , 〈URL 끝에 '/'는 왜 붙이는 걸까? 〉, 《깃허브》, 2017-07-05
- victolee , 〈[ https://victorydntmd.tistory.com/287 (HTTP) URI,URL 구조 ]〉, 《티스토리》, 2018-10-03
- 미래학자 , 〈URL과 리소스(HTTP 완벽가이드)〉, 《티스토리》, 2019-06-23
- GeunChoi , 〈[ https://m.blog.naver.com/csgct/220444910779 URL 특수문자처리 ]〉, 《네이버 블로그》, 2015-08-08
- 상큼과즙 FreshCrush.Jang , 〈URL 인코딩이란? 〉, 《티스토리》, 2019-01-28
- 홍주 , 〈인코딩(Encoding)이란?〉, 《티스토리》, 2019-07-03
같이 보기
