秒懂HTTP之URL与资源

【版权申明】非商业目的可自由转载
博文地址：https://blog.csdn.net/ShuSheng0007/article/details/97617341
出自：shusheng007

系列文章
秒懂HTTP之基本认证(Basic Authentication)

概述

HTTP（Hypertext Transfer Protocol）是当今互联网的基石，熟练掌握HTTP也是一个互联网从业者的基本要求，今天我们就来总结一下HTTP的基础知识。

发展历史

现在普遍认为Tim Berners-Lee 和他在CERN的团队于1989年发明了最初的HTTP以及最初的HTML语言，Berners-Lee 于1989年首先发起了 “WorldWideWeb” 项目，就是现在著名的万维网（ World Wide Web）。第一版HTTP非常简单，只有一个GET方法，而且服务器返回的数据永远是一个HTML网页。

之所以说普遍认为，是因为每一项牛逼技术的提出均是基于当时此领域已经存在的研究成果的，无一例外，所以就会有很多人同时在那个领域做各种研究，谁先谁后真的是说不清，谁先发表出来让大众知晓就算谁的。

后来在 Internet Engineering Task Force (IETF) 和 World Wide Web Consortium (W3C) 的努力下形成了标准，被写入了 Requests for Comments （RFCs） 中，即HTTP0.9。

目前HTTP2.0已经于2015年形成标准，HTTP3.0也于2018年提出，但是当前使用最为广泛的还是于1997年形成标准的HTTP1.1，从1.1到2.0 整整用了18年，不知道是应该惊叹HTTP1.1设计者的高瞻远瞩呢，还是唏嘘此领域技术迭代缓慢呢！

HTTP2.0基于Google公司的 SPDY 项目，至今各大浏览器均已支持。根据 W3Techs的调查截止2019年7月全世界千万级别访问量的网站已经有27.8%支持了HTTP2.0.

基础

前面我们已经提到了，未来的技术均是基于当下的技术发展的，是为了解决当下技术存在的缺陷而出现的，其实归根结底还是由于人类的欲望驱动的！那么短时间内基础的东西就不会发生剧烈的变动，这些就是收益最高的知识,例如我们今天要谈的URL。

URI vs URL

当我们使用浏览器从网上获取信息或者完成某些功能的时候，其实我们是在获取网络中的资源，这个资源是一个广义的资源，例如你查看微信上的图片，观看YouTube上的视频 ，在淘宝购买商品等。那么总的有一种方式使得浏览器可以获取到那个资源吧，主角登场了。

HTTP的规范中使用URI来定义资源，但是实际上我们几乎总是在使用URL。

URI : Uniform Resource Identifier, 翻译过来叫统一资源标识符。这是一个比较大的概念，意思就是通过这个标识就可以获取到互联网上的某个资源，以何种方式获取它不管。

URL: Uniform Resource Locator, 翻译过来叫统一资源定位符。 它是URI的一个子集，意思就是一个URL 一定是一个URI, 但反过来就不一定了。它可以向使用者提供资源的位置及以何种方式获取这个资源的信息，这是我们重点介绍的，后面详解。

URN: Uniform Resource Name，翻译过来叫统一资源命名符。它也是URI的一个子集，它是以资源的名称来标识资源，与位置无关。例如网上有一张图片名字命名为：image52girl。这张图片原来在阿里的服务器上，后来被挪到了腾讯的服务器上，但是访问者都可以通过image52girl这个名字找的到，再也不用担心404了。但是要达到这么理想的效果，那可不容易，需要强大的基础架构，主要还是因为当前的URL技术可以基本满足需求，所以估计没个30年就别想了。

URL 语法

前面嘚嘚了半天，这货终于出来了，在现如今的web世界，我们几乎总是在使用URL.一个URL会告知使用者这个资源的位置在哪里，以及需要以何种方式去获取。

之所以叫统一资源定位符，就是因为我们可以通过不同的方式去访问资源，例如 HTTP, FTP,SMTP等等协议。不同的访问协议格式略有不同，但是都是基于通用格式的。

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

其中scheme 是必须的，因为一个URL首先需要告知使用者使用何种方式来获取这个资源，不同的scheme URL的格式会有变化，其实就是有些scheme不需要通用格式上的某几个部分。我们挑几个常用的scheme来看一下，根据二八定律，这几个已经覆盖了我们日常开发的大部分需求了。

HTTP

此方式不需要URL的用户名和密码部分，如下所示

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

host：主机名称，表现为域名或者IP地址

port：端口号，默认为80

path：资源在服务器上的路径

params：参数，用来向服务器提供额外的信息，用 ；与前面的路径分开，这个用的应该不算太多。

query：查询语句，以？与前面部分分开，例如 “item=100&color=red”

frag：这参数个比较特殊，它不会被传给服务器，而是给浏览器使用的，使用#与其他部分分开。
例如使用浏览器通过URL查看网页的时候，服务器只会返回整个HTML页面给你，而你只关心其中名叫girl的部分，如果没有这个参数，你就要自己滚动鼠标去页面中去寻找了。如果你以girl作为frag那么浏览器就会自动帮你滚动到那个地方。

下面看一个具体的实例

某天王二狗公司为了和客户搞好关系，就请客户到天上人间夜总会娱乐，二狗一合计怎么也得找找几个姑娘给助助兴啊，因为现在的夜总会也在搞互联网+娱乐战略，所以这些服务都可以网上预约了，于是二狗打开了天上人间的网站…。

http://www.heaven.top:80/service;gender=女?age=18&face=瓜子i#才艺

上面就是按照王二狗他们的喜好挑出的姑娘们的网页的URL
协议：http
夜总会服务器域名为：www.heaven.top
端口：80
路径：service
参数类型：只需要女性表演者，不需要男性
查询条件为：只要芳龄18岁，瓜子脸的姑娘
片段： 直接滚动到才艺部分，看姑娘们有什么才艺

HTTPS

其URL与http完全一致，只是默认端口为443.

FTP

FTP 为文件传输协议，通过它可以从FTP服务器下载文件或者上传文件到FTP服务器。这可是个古老的协议，甚至早于URL的存在。

<scheme>://<user>:<password>@<host>:<port>/<path>;<params>

可以看出，以FTP方式访问的URL没有query 和frag部分，但却需要用户名和密码。

URL编码

每次说到这个编码问题就比较恶心人，主要是因为咱和西方使用的不是一个语系，我们使用的是多字节语言，而西方是单字节语系，但很遗憾的是计算机的发展多年来均由西方主导，所以计算机世界的字符基本上是以英语为中心，很多应用的字符集均为US-ASCII码。那老美自然用的舒坦了，但是其他非罗马语系的人民怎么办呢？
两种选择：
第一：美国绝对主导，强大到所有标准都不用考虑其他人，其他人想用就按照老美的规矩来，不然就别用。URL 里的字符全他妈给我写ASCII,敢写其他的，对不起，报错！
第二：定一套大家都接受的规则，每个国家的语言都可以直接用。

其实严格意义上来讲，现行的方式采用了将二者折中的办法。你可以在URL中使用中文，但是浏览器一般会将其转义为ASCII码中的可见字符的十六进制，说白了就是会把其他语言字符转义为ASCII码，这样背后的服务器就可以给出正确的资源，大家都很happy。这种机制除了可以编码非罗马语系的字符外，还可以解决ASCII码中的限制字符问题，限制字符包括不安全字符和保留字符。

不安全字符
不安全字符是指那些在URL中没有特殊含义，但在URL所在的上下文中可能具有特殊意义的字符。例如双引号(“”)。此外一些不可打印的字符也算作不安全字符，需要转义，例如空格

保留字符
所谓保留字符就是那些在URL中具有特定意义的字符，例如/、&、？、；等等

这些限制字符会被转义为%加上表示ASCII码的16进制数，例如

http://www.shusheng007.top/blog/%25url.html

上面的URL中的%25 其实是一个%号，由于%是不安全字符，而其ASCII (37)对应的十六进制为0x25,所以被转义未%25。

下表为部分保留字符和不安全字符及其URL编码

字符	描述	用法	编码
;	分号	保留	%3B
/	斜线	保留	%2F
?	问号	保留	%3F
:	冒号	保留	%3A
@	“at”符号	保留	%4O
=	等号	保留	%3D
&	“和”符号	保留	%26
<	小于号	不安全	%3C
>	大于号	不安全	%3E
"	双引号	不安全	%22
#	井号	不安全	%23
%	百分号	不安全	%25
{	左大括号	不安全	%7B
}	右大括号	不安全	%7D
|	竖线	不安全	%7C
\	反斜线	不安全	%5C
^	加字号	不安全	%5E
~	波浪	不安全	%7E
[	左中括号	不安全	%5B
]	右中括号	不安全	%5D
`	反单引号	不安全	%60
	空格	不安全	%20

总结

希望中国把高铁建设到全世界，全世界都采用中国标准，让别的国家在建设高铁的时候考虑如何转义（符合）成中国标准。