HTTP学习笔记01-URL

- URI
- URL语法
- 相对URL和绝对URL
  - 相对URL
- URL的常用协议
  - http
  - https
  - mailto
  - ftp
  - rtsprtspu
  - file
  - news
  - telnet
- 展望美好的未来

1.URI

明确几个概念:
- **URI:**Uniform Resource Identifier 统一资源标识符
- **URL:**Uniform Resource Locater 统一资源定位符
- **URN:**Uniform Resource Name 统一资源命名

这仨玩意儿长得差不多,严格来说,URI包括两种,一种是URL,一种是URN. 也就是说现在最常用的URL是URI的一个子集.
而URL和URN的区别,从名字上就能看出来.

URL是以资源的位置(location)来定位一个资源的.
URN是以资源的名称来定位资源.

举个例子,比如我要找某个RFC文档,通过URL的话,可以标记为:ftp://www.ietf.com/rfc/rfc2041.txt
而是用URN标识的话就可以写成,urn:ietf:rfc:rfc2041

URN的技术瓶颈在于,需要一套完善的资源定位服务器来实现资源名称的解析. URN是未来发展的一个趋势,它可以只考虑文件的名称,而不用考虑其物理存储位置(是不是类似磁力链接的一个玩意儿. )但是URN像IPv6一样,是一个美好的未来,但目前来看也仅仅是一个未来. 所以,目前说到URI暂时就可以理解为URL.

2.URL语法

可能我们都知道http://www.thecatcher.net/index.html这样的的URL,但是如果URL如果仅仅是这样的话,怎么体现URL的牛逼之处. 下面这个是URL的完整语法格式.

<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>

scheme: 方案,可以理解为一个协议名,之名该URL所使用的协议. 大小写无关.
主机和端口
用户名和密码:这一部分是可选的http://joe:joespasswd@www.joes-hardware.com/sales_info.txt 比如像这个样子
路径
参数:提供一些参数比如 ftp://prep.ai.mit.edu/pub/gnu;type=d 提供了一个type参数,其value是d. 路径可以分成若干段,每段都可以有自己的参数. 比如http://www.joes-hardware.com/hammers;sale=false/index.html;graphics=true
查询字符串:通过?标识,提供一些可用于查询的参数.不同的查询字符串之间可以通过&隔开. http://www.joes-hardware.com/inventory-check.cgi?item=12731&color=blue
片段: HTML的锚点就是一个所谓的片段,用于表示一个完整资源中的一部分. 一般情况下,服务端只处理完整的资源,而这个片段的参数是交给客户端来处理的.

相对URL和绝对URL

URL分为绝对URL和相对URL. 绝对URL就是包含所有信息的一个URL. 而相对URL是相对于一个base URL来说的. 相对URL是不完整的在解析的时候需要和对应的base URL拼接在一起才能找到对应的资源.

相对URL

要使用相对URL的前提是能够得知其所对应的base URL. base URL可以来自三个地方:
- 在资源中显式的指定. 比如使用<base>标签
- 在一个没有显示指定base的资源中,发现了一个相对URL,那么就以该资源自身所属的URL作为base. 比如你在一个html文件路径是(/home/www/html/test.html)中指定了一个图片<img src="./hot.jpg" 那么在解析时,会使用该文件所在的路径作为base即 /home/www/html/(说的有点玄乎,其实就是个相对路径啦)

相对URL的解析

URL的常用协议

http

超文本传输协议方案，除了没有用户名和密码之外，与通用的 URL 格式相符。如果省略了端口，就默认为 80。
基本格式：
http://<host>:<port>/<path>?<query>#<frag>
示例：
http://www.joes-hardware.com/index.html
http://www.joes-hardware.com:80/index.html

https

方案 https 与方案 http 是一对。唯一的区别在于方案 https 使用了网景的 SSL，SSL 为HTTP 连接提供了端到端的加密机制。其语法与 HTTP 的语法相同，默认端口为 443。
基本格式：
https://<host>:<port>/<path>?<query>#<frag>
示例：
https://www.joes-hardware.com/secure.html

mailto

Mailto URL 指向的是 E-mail 地址。由于 E-mail 的行为与其他方案都有所不同（它并不指向任何可以直接访问的对象），所以 mailto URL 的格式与标准 URL 的格式也有所不同。因特网 E-mail 地址的语法记录在 RFC 822 中。
基本格式：
mailto:<RFC-822-addr-spec>
示例：
mailto:joe@joes-hardware.com

ftp

文件传输协议 URL 可以用来从 FTP 服务器上下载或向其上载文件，并获取 FTP 服务器上的目录结构内容的列表。在 Web 和 URL 出现之前 FTP 就已经存在了。Web 应用程序将 FTP 作为一种数据访问方案使用。URL 语法遵循下列通用格式。
基本格式：
ftp://<user>:<password>@<host>:<port>/<path>;<params>
示例：
ftp://anonymous:joe%40joes-hardware.com@prep.ai.mit.edu:21/pub/gnu/

rtsp，rtspu

RTSP URL 是可以通过实时流传输协议（Real Time Streaming Protocol）解析的音 / 视频媒体资源的标识符。方案 rtspu 中的 u 表示它是使用 UDP 协议来获取资源的。
基本格式：
rtsp://<user>:<password>@<host>:<port>/<path>
rtspu://<user>:<password>@<host>:<port>/<path>
示例：
rtsp://www.joes-hardware.com:554/interview/cto_video38

file

方案 file 表示一台指定主机（通过本地磁盘、网络文件系统或其他一些文件共享系统）上可直接访问的文件。各字段都遵循通用格式。如果省略了主机名，就默认为正在使用URL 的本地主机。
基本格式：
file://<host>/<path>
示例：
file://OFFICE-FS/policies/casual-fridays.doc

news

根据 RFC 1036 的定义，方案 news 用来访问一些特定的文章或新闻组。它有一个很独特的性质：news URL 自身包含的信息不足以对资源进行定位。news URL 中缺乏到何处获取资源的信息——没有提供主机名或机器名称。从用户那里获取此类信息是解释程序的工作。比如，在网景浏览器的“选项” （Options）菜单中，就可以指定自己的 NNTP（news）服务器。这样，浏览器有了 news URL 的时候就知道应该使用哪个服务器了。
新闻资源可以从多台服务器中获得。它们被称为位置无关的，因为对它们的访问不依赖于任何一个源服务器。news URL 中保留了字符“@” ，用来区分指向新闻组的 news URL 和指向特定新闻文章的news URL。
基本格式：
news:<newsgroup>
news:<news-article-id>
示例：
news:rec.arts.startrek

telnet

方案 telnet 用于访问交互式业务。它表示的并不是对象自身，而是可通过 telnet 协议访问的交互式应用程序（资源）。
基本格式：
telnet://<user>:<password>@<host>:<port>/
示例：
telnet://slurp:webhound@joes-hardware.com:23/

展望美好的未来…

URL可以准确的定位到资源,但是,他是一种不稳定的定位方式. 最简单的,如果我的文件换了位置,那么就必须更新对应的url. 那些活在教科书中被我们瞻仰的学院派的专家大神们,他们一直致力于让这个世界便的更加完美.于是他们提出了URN的概念. 也就是说,资源只与其名称相对应,而不需要考虑物理存储位置. 知道了资源的名称,也就可以找到对应的资源. (有点像磁力链接…)

目前IETF提出了一个可以向下兼容URL的方案,PURL(persistent uniform resource locators),这个方案在请求URL的客户端和服务器之间增加一个中间件. 该中间服务器上记录着永久RUL和资源实际地址的映射. 这样的话每次客户端只需要使用固定的URL 在中间件上请求资源就可以了.

但是从URL到URN的过渡是个极其庞大的工程.(貌似IP4to6也是这么说…)最主要的,URL的应用如此广泛,即使它有着一丢丢的小问题,大家也早就接受了,由于URL的使用太广泛了(IPv4也是)过渡到URN如果没有完善的兼容URL方案的话,几乎是件不可能的事情.

所以展望的未来,或许仅仅是个遥远的未来吧.