(해석 또는 이해가 잘못된 부분이 있다면 댓글로 편하게 알려주세요.)
Think of the Internet as a giant, expanding city, full of places to see and things to do. You and the other residents and tourists of this booming community would use standard naming conventions for the city’s vast attractions and services. You’d use street addresses for museums, restaurants, and people’s homes. You’d use phone numbers for the fire department, the boss’s secretary, and your mother, who says you don’t call enough.
인터넷을 볼 거리와 놀 거리로 가득한 거대한 도시라고 생각해봅시다.
여러분을 비롯한 이 북적이는 도시의 주민들과 여행객들은 이 도시의 방대한 명소와 서비스에 대하여 표준 명명 규칙을 사용할지도 모릅니다.
박물관, 식당, 집을 나타내기 위해 도로명 주소를 사용할 것입니다.
소방서와 직장 상사의 비서, 전화를 많이 안 건다고 불평하시는 여러분의 어머니께 사용할 핸드폰 번호가 있을 것입니다.
Everything has a standardized name, to help sort out the city’s resources. Books have ISBN numbers, buses have route numbers, bank accounts have account numbers, and people have social security numbers. Tomorrow you will meet your business partners at gate 31 of the airport. Every morning you take a Red-line train and exit at Kendall Square station.
모든 것은 표준화된 이름을 가지고 있습니다. 이 도시의 리소스를 정렬하고 분류하기 위함입니다.
도서마다 ISBN 번호를 가지고 있고, 버스마다 노선 번호를 가지고 있고, 계좌마다 계좌번호를 가지고 있고, 사람마다 사회 보장 번호(한국의 주민등록번호 정도로 이해하면 될 듯하다)를 가지고 있습니다.
내일 여러분은 공항의 31번 게이트 앞에서 사업 파트너를 만날 것입니다.
매일 아침 Red-line 기차를 탑승하고 Kendall Square 역에서 나옵니다.
And because everyone agreed on standards for these different names, we can easily share the city’s treasures with each other. You can tell the cab driver to take you to 246 McAllister Street, and he’ll know what you mean (even if he takes the long way).
그리고 모두가 이렇게 서로 다른 이름에 관한 표준에 동의했기 때문에 우리는 이 도시의 자원들을 쉽게 공유할 수 있습니다.
여러분은 여러분을 246 McAllister Street로 데려다줄 것을 택시 운전기사에게 이야기할 수 있고, 그 운전기사는 당신이 말한 장소가 어디인지 알고 있을 것입니다. 그게 먼 곳이라고 하더라도 말입니다.
Uniform resource locators (URLs) are the standardized names for the Internet’s resources. URLs point to pieces of electronic information, telling you where they are located and how to interact with them.
Uniform Resource Locators(URLs)는 인터넷 리소스의 표준화된 이름입니다.
URL은 전자 정보의 한 부분을 가리키고 여러분에게 그 리소스가 어디에 위치해 있고 어떻게 상호작용할 수 있는지 알려줍니다.
In this chapter, we’ll cover:
• URL syntax and what the various URL components mean and do
• URL shortcuts that many web clients support, including relative URLs and expandomatic URLs
• URL encoding and character rules
• Common URL schemes that support a variety of Internet information systems
• The future of URLs, including uniform resource names (URNs)—a framework to support objects that move from place to place while retaining stable names
-> 이번 챕터에서 우리는 아래의 내용들을 다룹니다.
URLs are the resource locations that your browser needs to find information. They let people and applications find, use, and share the billions of data resources on the Internet. URLs are the usual human access point to HTTP and other protocols: a person points a browser at a URL and, behind the scenes, the browser sends the appropriate protocol messages to get the resource that the person wants.
URL은 브라우저가 정보를 찾고자 하는 특정 리소스의 위치입니다. 사람과 애플리케이션이 인터넷에 있는 수십 억개의 데이터를 찾고, 사용하고, 공유할 수 있게 합니다.
URL은 HTTP와 다른 프로토콜에서 일반적인 사용자 액세스 포인트입니다. 사용자가 URL로 브라우저를 가리키면, 브라우저는 사용자가 원하는 리소스를 얻기 위해 내부에서 적절한 프로토콜 메시지를 전송합니다.
URLs actually are a subset of a more general class of resource identifier called a uniform resource identifier, or URI. URIs are a general concept comprised of two main subsets, URLs and URNs. URLs identify resources by describing where resources are located, whereas URNs (which we’ll cover later in this chapter) identify resources by name, regardless of where they currently reside.
실제로 URL은 보다 일반적인 분류인 Uniform Resource Identifier(URI, 리소스 식별자)의 부분집합입니다.
URI는 두 가지 커다란 부분집합 URL과 URN을 포함한 일반적인 개념입니다.
URL은 리소스를 리소스의 위치를 통해 설명하는 한편 (이번 챕터의 후반부에서 다룰) URN은 리소스의 현재 위치와 관계없이 이름만으로 리소스를 식별합니다.
The HTTP specification uses the more general concept of URIs as its resource identifiers; in practice, however, HTTP applications deal only with the URL subset of URIs. Throughout this book, we’ll sometimes refer to URIs and URLs interchange- ably, but we’re almost always talking about URLs.
-> HTTP의 명세에서는 리소스 식별자로써 URI의 더 일반적인 개념을 사용합니다.
-> 그러나 실제로는 HTTP 애플리케이션이 오직 URI의 부분집합인 URL만을 다루고 있습니다.
-> 이 책에서도 내내 URI와 URL을 혼용하여 언급하겠지만, 우리는 거의 항상 URL에 대해 이야기할 것입니다.
Say you want to fetch the URL http://www.joes-hardware.com/seasonal/index-fall.html:
• The first part of the URL (http) is the URL scheme. The scheme tells a web client how to access the resource. In this case, the URL says to use the HTTP protocol.
• The second part of the URL (www.joes-hardware.com) is the server location. This tells the web client where the resource is hosted.
• The third part of the URL (/seasonal/index-fall.html) is the resource path. The path tells what particular local resource on the server is being requested.See Figure 2-1 for an illustration.
-> 여러분이 http://www.joes-hardware.com/seasonal/index-fall.html 이라는 URL을 가져온다고 가정합니다.
URL의 첫 번째 부분(http)은 URL Scheme입니다. Scheme은 웹 클라이언트가 리소스에 접근하는 방식을 이야기합니다. 이 경우에는, URL이 HTTP 프로토콜을 사용한다는 것을 알려줍니다.
URL의 두 번째 부분(www.joes-hardware.com)은 서버의 위치입니다. 이 부분은 리소스가 존재하는 위치를 웹 클라이언트에게 알려줍니다.
URL의 세 번째 부분(/seasonal/index-fall.html)은 리소스 경로입니다. 해당 경로는 요청된 서버의 특정 로컬 리소스가 무엇인지 알려줍니다.
-> Figure 2-1을 살펴봅시다.
URLs can direct you to resources available through protocols other than HTTP. They can point you to any resource on the Internet, from a person’s email account:
mailto:president@whitehouse.gov
to files that are available through other protocols, such as the File Transfer Protocol (FTP):
ftp://ftp.lots-o-books.com/pub/complete-price-list.xls
to movies hosted off of streaming video servers:
rtsp://www.joes-hardware.com:554/interview/cto_video
URL은 HTTP 외의 다른 프로토콜을 통해 사용 가능한 리소스를 가리킬 수 있습니다. 개인의 이메일 계정으로부터 인터넷에 있는 임의의 리소스를 가리킬 수 있습니다.
File Transfer Protocol(FTP) 등 다른 프로토콜을 통해 사용 가능한 파일을 가리킬 수 있습니다.
스트리밍 비디오 서버에서 호스팅되는 영화를 가리킬 수 있습니다.
URLs provide a way to uniformly name resources. Most URLs have the same “scheme://server location/path” structure. So, for every resource out there and every way to get those resources, you have a single way to name each resource so that anyone can use that name to find it. However, this wasn’t always the case.
URL은 리소스를 유일무이하게 명명하는 방법을 제공합니다.
대부분의 URL이 "scheme://server location/path" 구조를 가지고 있습니다.
따라서 모든 리소스와 이 리소스들에 접근하는 방법에 관하여 각각의 리소스를 명명하는 하나의 방법을 가집니다. 누구나 그 리소스를 찾기 위해 정해진 이름을 사용할 수 있습니다.
그러나, 항상 그러한 것은 아닙니다.
Before the Web and URLs, people relied on a rag-tag assortment of applications to access data distributed throughout the Net. Most people were not lucky enough to have all the right applications or were not savvy and patient enough to use them.
웹과 URL을 사용하기 이전에 사람들은 넷상에 퍼진 데이터에 접근하기 위해 각종 애플리케이션에 의존하였습니다.
대부분의 사람들은 제대로 된 애플리케이션을 보유할 만큼 운이 좋지도 않았고, 그것들을 사용할 만큼 정통하거나 끈기 있지 않았습니다.
Before URLs came along, if you wanted to share the complete-catalog.xls file with a friend, you would have had to say something like this: “Use FTP to connect to ftp. joes-hardware.com. Log in as anonymous. Then type your username as the password. Change to the pub directory. Switch to binary mode. Now download the file named complete-catalog.xls to your local filesystem and view it there.”
URL이 나오기 전에는 여러분이 complete-catalog.xls 파일을 친구에게 공유하고 싶다면 이런 식으로 이야기해야 했습니다.
"FTP를 사용해서 ftp. joes-hardware.com에 연결합니다. 익명으로 로그인합니다. 사용자 이름과 패스워드를 입력합니다. pub 디렉토리를 수정합니다. 이진 모드로 전환합니다. 이제 당신의 로컬 파일 시스템에서 complete-catalog.xls라는 이름의 파일을 다운로드하고 그 파일을 열람합니다."
Today, browsers such as Netscape Navigator and Microsoft Internet Explorer bundle much of this functionality into one convenient package. Using URLs, these applications are able to access many resources in a uniform way, through one interface. Instead of the complicated instructions above, you could just say “Point your browser at ftp://ftp.lots-o-books.com/pub/complete-catalog.xls.”
오늘날에는 Netscape Navigator, Microsoft Internet Explorer 같은 브라우저가 하나의 편리한 패키지 안에 이러한 대부분의 기능들을 포함하고 있습니다.
URL을 사용하면 이 애플리케이션들이 하나의 인터페이스를 통해 단일한 방법으로 많은 리소스에 접근하게 할 수 있습니다.
위의 복잡한 명령어 대신, 여러분은 그저 브라우저가 ftp://ftp.lots-o-books:com/pub/complete-catalog.xls를 가리키게 하면 됩니다.
URLs have provided a means for applications to be aware of how to access a resource. In fact, many users are probably unaware of the protocols and access methods their browsers use to get the resources they are requesting.
URL은 애플리케이션이 리소스에 접근하는 방식을 인식할 수 있는 수단을 제공합니다.
실제로, 많은 사용자들은 브라우저가 요청한 리소스를 얻기 위해 사용하는 프로토콜과 접근 메소드에 대해 무지할 것입니다.
With web browsers, you no longer need a news reader to read Internet news or an FTP client to access files on FTP servers. You don’t need an electronic mail program to send and receive email messages. URLs have helped to simplify the online world, by allowing the browser to be smart about how to access and handle resources.* Applications can use URLs to simplify access to information.
웹 브라우저가 있으면 별도의 인터넷 뉴스를 읽기 위한 별도의 뉴스 리더나 FTP 서버에서 파일에 접근하기 위한 FTP 클라이언트는 필요하지 않습니다.
이메일을 보내기 위한 전자메일 프로그램도 필요하지 않습니다.
URL은 브라우저가 영리하게 리소스를 접근하고 핸들링할 수 있게 하여 온라인 세상을 단순화하는 데 기여하였습니다.
애플리케이션은 정보 접근을 간소호하기 위해 URL을 사용할 수 있습니다.
URLs give you and your browser all you need to find a piece of information. They define the particular resource you want, where it is located, and how to get it.
URL은 정보의 조각을 찾기 위해 여러분과 여러분의 브라우저에게 필요한 모든 것을 제공합니다.
URL은 여러분이 원하는 특정 리소스가 어디에 위치해 있고 어떻게 얻을 수 있는지 정의합니다.
드디어 챕터 2에 들어왔다. 아직 챕터가 20개나 남았지만(???) 매일 부지런히 마음의 양식을 쌓으며 반드시 완독할 수 있도록 노력해야겠다.
URL이 존재하기 전에는 간단한 파일 하나 주고받는 게 그렇게나 어려웠다는 게 믿기지 않는다. URL이 없던 시대가 마치 역사책에나 나올 법한 조선시대 이야기처럼 느껴졌다. 지금은 별 거 아닌 것처럼 보이는 짦은 문장 하나가 세상을 이렇게나 편리하게 만들었다는 것이 놀라울 따름이다.