芯耀
1030
當我們打開瀏覽器，要訪問一個網(wǎng)站或者一個ftp服務器的時候，一定要輸入一串字符串， 比如：
https://blog.csdn.net/
或者：
ftp://192.168.0.111/
這樣我們就可以得到一個html格式的頁面或者一個文件。
那么這個地址是什么意思呢？就必須要從URI、URL、URN講起。
一、URI、URL、URN概念
- URI = Uniform Resource Identifier 統(tǒng)一資源標志符URL = Uniform Resource Locator 統(tǒng)一資源定位符URN = Uniform Resource Name 統(tǒng)一資源名稱
看了這個概念相信大家還是不明白什么意思，簡單來說，就是URI是抽象的定義，不管用什么方法表示，只要能定位一個資源，就叫URI。
本來設想的的使用兩種方法定位：1，URL，用地址定位；2，URN 用名稱定位。
舉個例子：去村子找個具體的人（URI），如果用地址：某村多少號房子第幾間房的主人 就是URL， 如果用身份證號+名字 去找就是URN了。
原來uri包括url和urn，后來urn沒流行起來，導致幾乎目前所有的uri都是url。
三者之間幾何關系如下：
其實一直有個誤解，很多人以為URI是URL的子集，其實應該反過來。URL是URI的子集才對。
URI RFC 3986
URL是什么
URL代表著是統(tǒng)一資源定位符（UniformResourceLocator）。
作用是為了告訴使用者 某個資源在 Web 上的地址。
這個資源可以是一個 HTML 頁面，一個 CSS 文檔，一幅圖像或一個貓片等等。
比如：
用HTTP協(xié)議訪問Web服務器：
用FTP協(xié)議下載和上傳文件時
讀取客戶端計算機本地文件時
這里面細分，又可以分為好幾個部分。
協(xié)議
盡管 URL 有各種不同的寫法， 但它們有一個共同點， 開頭部分的內(nèi)容必須是協(xié)議類型，可以是http、ftp、mailto或者https，這部分文字都表示瀏覽器應當使用的訪問方法。,會用//為分隔符。
決定了后面部分的寫法， 因此并不會造成混亂。
用戶名/密碼
用戶名密碼通常可以省略。
域名
域名是www.gitee.com，在發(fā)送請求前，會向DNS服務器解析IP。如果已經(jīng)知道ip，還可以跳過DNS解析那一步，直接把IP當做域名部分使用。
端口
域名后面有些時候會帶有端口，和域名之間用:分隔，端口不是一個URL的必須的部分。當網(wǎng)址為http://時，默認端口為80， https://時，默認端口是443， ftp://時，默認端口是21。
文件路徑/文件名
從域名的第一個/開始到最后一個/為止，是虛擬目錄的部分。虛擬目錄也不是URL必須的部分，上述實例http協(xié)議url中的虛擬目錄是/yikoulinux/chat/blob/master/
從域名最后一個/開始到?為止，是文件名部分；如果沒有?，則是從域名最后一個/開始到#為止，是文件名部分；如果沒有?和#，那么就從域名的最后一個/從開始到結束，都是文件名部分。
比如前面的http url實例，其中文件chat.h在gitee服務器/yikoulinux/chat/blob/master/下：
文件名也不是一個URL的必須部分。
文件名省略情況如下：
- http://www.gitee.com/dir/
我們可以這樣理解， 以“/” 結尾代表 /dir/ 后面本來應該有的文件名被省略了。根據(jù) URL 的規(guī)則， 文件名可以像前面這樣省略。不過， 沒有文件名， 服務器怎么知道要訪問哪個文件呢？其實， 我們會在服務器上事先設置好文件名省略時要訪問的默認文件名。這個設置根據(jù)服務器不同而不同， 大多數(shù)情況下是 index.html 或者 default.htm 之類的文件名。
因此， 像前面這樣省略文件名時， 服務器就會訪問 /dir/index.html或者 /dir/default.htm[由web服務器配置]。
http://www.gitee.com/ 這個 URL 也是以“/” 結尾的， 也就是說它表示訪問一個名叫“/” 的目錄 。而且， 由于省略了文件名， 所以結果就是訪問 /index.html 或者/default.htm 這樣的文件了。
http://www.gitee.com 這次連結尾的“/” 都省略了。像這樣連目錄名都省略時， 真不知道到底在請求哪個文件了， 實在有些過分。不過， 這種寫法也是允許的。當沒有路徑名時， 就代表訪問根目錄下事先設置的默認文件 ， 也就是 /index.html 或者 /default.htm 這些文件， 這樣就不會發(fā)生混亂了。
http://www.gitee.com/yikoupeng
一般來說， 這種情況會按照下面的慣例進行處理：如果Web 服務器上存在名為 yikoupeng的文件， 則將 yikoupeng作為文件名來處 理；如果存在名為 yikoupeng的目錄， 則將 yikoupeng作為目錄名來處理 。
rfc
關于協(xié)議的說明文檔，可以登錄下面網(wǎng)站查詢：
https://www.rfc-editor.org/
搜索URL協(xié)議的說明，就有25個結果。
我們想查看某個協(xié)議，點擊即可。
可以以任意一種格式查看該文檔：
下面只拷貝第一頁內(nèi)容：
Network Working Group T. Berners-Lee
Request for Comments: 1738 CERN
Category: Standards Track L. Masinter
Xerox Corporation
M. McCahill
University of Minnesota
Editors
December 1994
Uniform Resource Locators (URL)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
This document specifies a Uniform Resource Locator (URL), the syntax
and semantics of formalized information for location and access of
resources via the Internet.
1. Introduction
This document describes the syntax and semantics for a compact string
representation for a resource available via the Internet. These
strings are called "Uniform Resource Locators" (URLs).
The specification is derived from concepts introduced by the World-
Wide Web global information initiative, whose use of such objects
dates from 1990 and is described in "Universal Resource Identifiers
in WWW", RFC 1630. The specification of URLs is designed to meet the
requirements laid out in "Functional Requirements for Internet
Resource Locators" [12].
This document was written by the URI working group of the Internet
Engineering Task Force. Comments may be addressed to the editors, or
to the URI-WG <uri@bunyip.com>. Discussions of the group are archived
at <URL:http://www.acl.lanl.gov/URI/archive/uri-archive.index.html>
end
