秒懂HTTP之URL與資源

【版權申明】非商業目的可自由轉載
博文地址：https://blog.csdn.net/ShuSheng0007/article/details/97617341
出自：shusheng007

概述

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 （RFCsd） 中，即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.shusheng007.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

總結

希望中國把高鐵建設到全世界，全世界都採用中國標準，讓別的國家在建設高鐵的時候考慮如何轉義（符合）成中國標準。