짧은 URL 서비스는 어떻게 작동합니까?

TinyURL 또는 Metamark 와 같은 서비스는 어떻게 작동합니까?
그들은 단순히 원래 URL에 "HTTP 리디렉션"을 제공하는 [가상?] 웹 페이지와 작은 URL 키를 연결합니까? 아니면 더 많은 "마법"이 있습니까?

[원문] 저는 TinyURL, Metamark 등과 같은 URL 단축 서비스를 자주 사용하지만 매번 사용할 때마다 이러한 서비스가 어떻게 작동하는지 궁금합니다. 다른 페이지로 리디렉션되는 새 파일을 만들거나 하위 도메인을 사용합니까?

아니요, 그들은 파일을 사용하지 않습니다. 이와 같은 링크를 클릭하면 http://bit.ly/duSk8wK (이 질문에 대한 링크) 와 같은 전체 URL과 함께 HTTP 요청이 서버로 전송됩니다 . 그들은 duSk8wK데이터베이스에 매핑되는 경로 부분 (여기 )을 읽습니다 . 데이터베이스에서 설명 (때때로), 이름 (때때로) 및 실제 URL을 찾습니다. 그런 다음 HTTP 302 응답 및 헤더의 대상 URL 인 리디렉션을 발행합니다.

이 직접 리디렉션이 중요합니다. 파일을 사용하거나 HTML을 먼저로드 한 다음 리디렉션하면 브라우저가 사용자가 원하지 않는 TinyUrl을 기록에 추가합니다. 또한 리디렉션되는 사이트는 리퍼러 (원래 사이트)가 TinyUrl 링크가있는 사이트 (즉, 링크가있는 곳이면 twitter.com, 귀하의 사이트)로 간주합니다. 이것은 사이트 소유자가 사람들이 어디에서 왔는지 볼 수 있도록 중요합니다. 이 역시 리디렉션되는 페이지가로드되면 작동하지 않습니다.

추신 : 더 많은 유형의 리디렉션이 있습니다. HTTP 301은 영구 리디렉션을 의미합니다. 그럴 경우 브라우저는 더 이상 bit.ly 또는 TinyUrl 사이트를 요청하지 않으며 해당 사이트는 조회수를 계산하려고합니다. 이것이 임시 리디렉션 인 HTTP 302가 사용되는 이유입니다. 브라우저는 매번 TinyUrl.com 또는 bit.ly를 요청하여 조회수를 계산할 수 있습니다 (일부 작은 URL 서비스에서 제공).

다른 사람들은 리디렉션의 작동 방식에 대해 대답했지만 작은 URL을 생성하는 방법도 알아야합니다. 단축 된 URL에 대한 고유 코드를 생성하기 위해 URL의 해시를 생성한다는 실수를 듣게됩니다. 이는 대부분의 경우 올바르지 않으며 해싱 알고리즘을 사용하지 않습니다 (충돌 가능성이있는 경우).

대부분의 인기있는 URL 단축 서비스는 URL 데이터베이스에서 ID를 가져 와서 Base 36 [a-z0-9] (대소 문자 구분 안 함) 또는 Base 62 (대소 문자 구분)로 변환합니다.

TinyURL 데이터베이스 테이블의 간단한 예 :

ID       URL                           VisitCount
 1       www.google.com                        26
 2       www.stackoverflow.com               2048
 3       www.reddit.com                        64
...
 20103   www.digg.com                         201
 20104   www.4chan.com                         20

유연한 라우팅을 허용하는 웹 프레임 워크는 들어오는 URL (Ruby, ASP.NET MVC 등)을 매우 쉽게 처리 할 수 ​​있도록합니다.

따라서 웹 서버에서 다음과 같은 경로 작업이있을 수 있습니다 (의사 코드).

Route: www.mytinyurl.com/{UrlID}
Route Action: RouteURL(UrlID);

도메인 www.mytinyurl.com 뒤에 텍스트가있는 서버로 들어오는 요청을 연결된 메서드 인 RouteURL로 라우팅합니다. URL에서 슬래시 뒤에 전달되는 텍스트를 해당 메서드에 제공합니다.

그래서, 당신이 요청했다고 가정 해 봅시다 : www.mytinyurl.com/fif

그러면 "fif"가 RouteURL (String UrlID) 메소드에 전달됩니다. 그런 다음 RouteURL은 "fif"를 base10에 해당하는 20103으로 변환하고 데이터베이스 요청이 ID 20103 (이 경우 www.digg.com)에 저장된 URL로 리디렉션되도록합니다. 또한 올바른 URL로 리디렉션하기 전에 Digg의 방문 횟수를 1 씩 늘립니다.

이것은 매우 간단한 예이지만 일반적인 아이디어를 얻을 수 있어야합니다.

@A Salcedo 답변에 대한 확장으로 :

일부 URL 단축 서비스 (Tinyarro.ws)는 유니 코드 (UTF-8)를 사용하여 단축 된 URL로 문자를 인코딩함으로써 극도로 발전하여 추가 기호를 추가하기 전에 더 많은 웹 사이트를 허용합니다. 대부분 때문에 UTF-8 사용을 허용한다 ( (IRI) RFC 대부분의 브라우저에 의해 처리 3987 )에서 충돌이 62~에 심볼 당 사이트 1,112,064.

관점에서 말하자면 1.2366863e + 12 사이트를 2 개의 기호 ( 1,112,064*1,112,064)로 인코딩 할 수 있습니다. 2009 년 11 월에 단축 된 링크 bit.ly가 2.1수십억 번 액세스 되었습니다 ( 그 무렵 bit.ly 및 TinyURL이 가장 널리 사용되는 URL 단축 서비스였습니다. ) 이는 2 개의 기호에 들어갈 수있는 것보다 ~ 600 배 적으므로 모든 URL 단축 서비스가 존재하는 동안 세 번째 기호를 추가 할 때까지 최소 20 년 동안 지속되어야합니다.

간단히 말해서 URL 단축기는 임의의 긴 문자 시퀀스 (원래의 긴 엉성한 URL)를 짧고 매끄러운 문자 시퀀스로 매핑합니다. 이것은 Hashing에 불과하며 암호화 목적으로 조회 테이블, HashMap, md5 Hash 등을 만드는 데 가장 일반적으로 사용됩니다.

URL 단축 프로세스를 이해하기 위해 GitHub에 데모 프로젝트와 블로그 게시물을 만들었습니다. 이것을 참조하고 도움이되었는지 알려주십시오.

블로그 게시물 : URL 단축