url的常用協議
展望美好的未來
明確幾個概念:
- **uri:**uniform resource identifier 統一資源識別符號
- **url:**uniform resource locater 統一資源定位符
- **urn:**uniform resource name 統一資源命名
這仨玩意兒長得差不多,嚴格來說,uri包括兩種,一種是url,一種是urn. 也就是說現在最常用的url是uri的乙個子集.
而url和urn的區別,從名字上就能看出來.
舉個例子,比如我要找某個rfc文件,通過url的話,可以標記為:
而是用urn標識的話就可以寫成,urn:ietf:rfc:rfc2041
urn的技術瓶頸在於,需要一套完善的資源定位伺服器來實現資源名稱的解析. urn是未來發展的乙個趨勢,它可以只考慮檔案的名稱,而不用考慮其物理儲存位置(是不是類似磁力鏈結的乙個玩意兒. )但是urn像ipv6一樣,是乙個美好的未來,但目前來看也僅僅是乙個未來. 所以,目前說到uri暫時就可以理解為url.
可能我們都知道這樣的的url,但是如果url如果僅僅是這樣的話,怎麼體現url的牛逼之處. 下面這個是url的完整語法格式.
://:@:/;?#
url分為絕對url和相對url. 絕對url就是包含所有資訊的乙個url. 而相對url是相對於乙個base url來說的. 相對url是不完整的在解析的時候需要和對應的base url拼接在一起才能找到對應的資源.
要使用相對url的前提是能夠得知其所對應的base url. base url可以來自三個地方:
- 在資源中顯式的指定. 比如使用標籤
- 在乙個沒有顯示指定base的資源中,發現了乙個相對url,那麼就以該資源自身所屬的url作為base. 比如你在乙個html檔案路徑是(/home/www/html/test.html)中指定了乙個那麼在解析時,會使用該檔案所在的路徑作為base即 /home/www/html/(說的有點玄乎,其實就是個相對路徑啦)相對url的解析
超文字傳輸協議方案，除了沒有使用者名稱和密碼之外，與通用的 url 格式相符。如果省略了埠，就預設為 80。
基本格式：
示例：
方案 https 與方案 http 是一對。唯一的區別在於方案 https 使用了網景的 ssl，ssl 為http 連線提供了端到端的加密機制。其語法與 http 的語法相同，預設埠為 443。
基本格式：
示例：
mailto url 指向的是 e-mail 位址。由於 e-mail 的行為與其他方案都有所不同（它並不指向任何可以直接訪問的物件） ，所以 mailto url 的格式與標準 url 的格式也有所不同。網際網路 e-mail 位址的語法記錄在 rfc 822 中。
基本格式：
mailto:
示例：
mailto:[email protected]
ftp://:@:/;
示例：
ftp://anonymous:joe%[email protected]:21/pub/gnu/
rtsp://:@:/
rtspu://:@:/
示例：
rtsp:
方案 file 表示一台指定主機（通過本地磁碟、網路檔案系統或其他一些檔案共享系統）上可直接訪問的檔案。各字段都遵循通用格式。如果省略了主機名，就預設為正在使用url 的本地主機。
基本格式：
file:///
示例：
file://office-fs/policies/casual-fridays.doc
根據 rfc 1036 的定義，方案 news 用來訪問一些特定的文章或新聞組。它有乙個很獨特的性質：news url 自身包含的資訊不足以對資源進行定位。news url 中缺乏到何處獲取資源的資訊——沒有提供主機名或機器名稱。從使用者那裡獲取此類資訊是解釋程式的工作。比如，在網景瀏覽器的「選項」 （options）選單中，就可以指定自己的 nntp（news）伺服器。這樣，瀏覽器有了 news url 的時候就知道應該使用哪個伺服器了。
新聞資源可以從多台伺服器中獲得。它們被稱為位置無關的，因為對它們的訪問不依賴於任何乙個源伺服器。news url 中保留了字元「@」 ，用來區分指向新聞組的 news url 和指向特定新聞文章的news url。
基本格式：
news:
news:
示例：
news:rec.arts.startrek
方案 telnet 用於訪問互動式業務。它表示的並不是物件自身，而是可通過 telnet 協議訪問的互動式應用程式（資源） 。
基本格式：
telnet://:@:/
示例：
telnet:
url可以準確的定位到資源,但是,他是一種不穩定的定位方式. 最簡單的,如果我的檔案換了位置,那麼就必須更新對應的url. 那些活在教科書中被我們瞻仰的學院派的專家大神們,他們一直致力於讓這個世界便的更加完美.於是他們提出了urn的概念. 也就是說,資源只與其名稱相對應,而不需要考慮物理儲存位置. 知道了資源的名稱,也就可以找到對應的資源. (有點像磁力鏈結…)
目前ietf提出了乙個可以向下相容url的方案,purl(persistent uniform resource locators),這個方案在請求url的客戶端和伺服器之間增加乙個中介軟體. 該中間伺服器上記錄著永久rul和資源實際位址的對映. 這樣的話每次客戶端只需要使用固定的url 在中介軟體上請求資源就可以了.
但是從url到urn的過渡是個極其龐大的工程.(貌似ip4to6也是這麼說…)最主要的,url的應用如此廣泛,即使它有著一丟丟的小問題,大家也早就接受了,由於url的使用太廣泛了(ipv4也是)過渡到urn如果沒有完善的相容url方案的話,幾乎是件不可能的事情.
所以展望的未來,或許僅僅是個遙遠的未來吧.
01 url概念及基本使用
url uniform resoure locator 統一資源定位符是對可以從網際網路上得到的資源的位置和訪問方法的一種簡潔的表示，是網際網路上標準資源的位址。網際網路上的每個檔案都有乙個唯一的url，它包含的資訊指出檔案的位置以及瀏覽器應該怎麼處理它。url解釋 schema host port...
HTTP學習筆記01
關於http協議，一篇就夠了 理解http協議 http 協議入門 超文字傳輸協議 維基百科，自由的百科全書 昨天通過讀文件 讀博文 看教程學習了一下http協議，發現真是 天下文章一大抄 這種現象無可厚非，畢竟知識本身也就只有那些內容，並且博文裡也註明了參考鏈結，大家也都見怪不怪了，但是連很明顯的...
《HTTP權威指南》學習筆記 URL和資源
url是網際網路資源的標準化名稱 url是瀏覽器尋找資訊時所需的資源位置 uri是一類更通用的資源識別符號，url是它的子集。uri的兩個子集 url和urn url提供了一種統一的資源命名方式 url方案 例如http，ftp等 伺服器位置 路徑 大部分url方案的url語法都建立在由9部分構成的...