URL(UrI的子集,統一資源定位符)實現的具體方法
URL首先是一種方法，定位到一個網路資源的具體方法。是屬於URI（統一資源識別符號）的一個子集，同時URL 還在不斷的進化，因為資源的移除導致無法找到資源是一個頭疼的問題，現在正在朝著解決這個“問題”的目標前進。
需要注意的是這裡有三個名字需要注意：
URN(統一資源名)
URL(統一資源定位)
URI(統一資源標識)
URI包含了URL,URN2種形式。
區別：
URI、URL和URN
統一資源定位符（Uniform Resource Locator，URL）,統一資源名稱（Uniform Resource Name，URN）是URI的子集。 Web上地址的基本形式是URI,它有兩種形式： 一種是URL，這是目前URI的最普遍形式。 另一種就是URN，這是URL的一種更新形式，URN不依賴於位置，並且有可能減少失效連線的個數。但是其流行還需假以時日，因為它需要更精密軟體的支援。URI與URL
URL是Uniform Resource Locator的縮寫，譯為"統一資源定位符"。URL是一種URI，它標識一個網際網路資源，並指定對其進行操作或獲取該資源的方法。可能通過對主要訪問手段的描述，也可能通過網路“位置”進行標識。例如，http://www.wikipedia.org/這個URL，標識一個特定資源（首頁）並表示該資源的某種形式（例如以編碼字元表示的，首頁的HTML程式碼）是可以通過HTTP協議從www.wikipedia.org這個網路主機獲得的。主要用在各種WWW客戶程式和伺服器程式上，特別是著名的Mosaic。採用URL可以用一種統一的格式來描述各種資訊資源，包括檔案、伺服器的地址和目錄等。 最大的缺點是當資訊資源的存放地點發生變化時，必須對URL作相應的改變。因此人們正在研究新的資訊資源表示方法，例如：URI(Universal Resource Identifier)即"通用資源標識"[2]URI與URN
URI可被視為定位符（URL），名稱（URN）或兩者兼備。統一資源名（URN）如同一個人的名稱，而統一資源定位符（URL）代表一個人的住址。換言之，URN定義某事物的身份，而URL提供查詢該事物的方法。URN僅用於命名，而不指定地址。 用於標識唯一書目的ISBN系統是一個典型的URN使用範例。例如，ISBN 0486275574(urn:isbn:0-486-27557-4)無二義性地標識出莎士比亞的戲劇《羅密歐與朱麗葉》的某一特定版本。為獲得該資源並閱讀該書，人們需要它的位置，也就是一個URL地址。在類Unix作業系統中，一個典型的URL地址可能是一個通俗的方式來講解：url 和 url 的區別（來源知乎某位哥）；
統一資源標誌符URI就是在某一規則下能把一個資源獨一無二地標識出來。
拿人做例子，假設這個世界上所有人的名字都不能重複，那麼名字就是URI的一個例項，通過名字這個字串就可以標識出唯一的一個人。
現實當中名字當然是會重複的，所以身份證號才是URI，通過身份證號能讓我們能且僅能確定一個人。
那統一資源定位符URL是什麼呢。也拿人做例子然後跟HTTP的URL做類比，就可以有：
動物住址協議://地球/中國/浙江省/杭州市/西湖區/某大學/14號宿舍樓/525號寢/張三.人
可以看到，這個字元串同樣標識出了唯一的一個人，起到了URI的作用，所以URL是URI的子集。URL是以描述人的位置來唯一確定一個人的。
在上文我們用身份證號也可以唯一確定一個人。對於這個在杭州的張三，我們也可以用：
身份證號：123456789
來標識他。
所以不論是用定位的方式還是用編號的方式，我們都可以唯一確定一個人，都是URl的一種實現，而URL就是用定位的方式實現的URI。
而URL則通過描述是哪個主機上哪個路徑上的檔案來唯一確定一個資源，也就是定位的方式來實現的URI。
對於現在網址我更傾向於叫它URL，畢竟它提供了資源的位置資訊，如果有一天網址通過號碼來標識變成了http://741236985.html，那感覺叫成URI更為合適，不過這樣子的話還得想辦法找到這個資源咯… 介紹URI的具體表現形式：
1.解析輸入的URL地址
-
傳輸協議（把資訊在客戶端和伺服器端進行傳遞，類似於快遞小哥）
-
http 超文字傳輸協議（傳輸的內容除了文字，還有可能是其它型別：二進位制編碼、BASE64碼、檔案流等等）
-
https 比HTTP更加安全的傳輸協議（傳輸通道設定加密演算法SSL），一般支付類網站都是HTTPS協議
-
ftp 資源上傳協議，一般應用於把本地檔案直接上傳到伺服器端
-
-
域名 zhufengpeixun.cn
-
一級域名www.baidu.cn
-
二級域名 video.baidu.cn
-
三級域名 webG.video.buidu.cn
-
常用域名性質：.com國際 / .cn中國 / .gov政府 / .org官方 / .net系統 / .io部落格 / .vip ...
-
-
埠號 （根據埠號，找到當前伺服器上指定的服務）
-
0~65535之間
-
不同協議有自己預設的埠號（也就是自己不用寫，瀏覽器會幫我們加上）
-
http => 80
-
https => 443
-
ftp => 21
-
除這幾個在書寫的時候可以省略，其餘的不能省
-
-
-
請求資源的路徑和名稱
-
/stu/index.html
-
一般情況下，如果我們訪問的是index.html等，可以省略不寫（因為服務端一般會設定index.html為預設文件，當然可以自定義）
-
-
偽URL
-
資料請求的介面地址 /user/list
-
-
問號傳參部分 ?xxx=xxx
-
客戶端基於GET系列請求，把資訊傳遞會伺服器，一般都會基於問號傳參的模式
-
頁面之間跳轉，資訊的一些通訊也可以基於問號傳參的方式（單頁面中元件和元件跳轉之間的資訊通訊，也可能基於問號傳參）
-
關於傳遞的內容需要進行編碼處理（處理特殊字元和中文）
-
encodeURI / decodeURI
-
encodeURIComponent / decodeURIComponent
-
escape / unescape
-
...
-
-
-
設定雜湊HASH #xxx
2.DNS解析
網站中，每傳送一個TCP請求，都要進行DNS解析（一但當前域名解析過一次，瀏覽器一般會快取解析記錄，快取時間一般在1分鐘左右，後期傳送的請求如果還是這個域名，則跳過解析步驟 =>這是一個性能優化點）
真實專案中，一個大型網站，他要請求的資源是分散到不同的伺服器上的（每一個伺服器都有自己的一個域名解析）
-
WEB伺服器（處理靜態資原始檔，例如：html/css/js等 的請求）
-
資料伺服器（處理資料請求）
-
圖片伺服器 （處理圖片請求）
-
音視訊伺服器
-
......這樣導致，我們需要解析的DNS會有很多次
優化技巧：DNS Prefetch 即 DNS 預獲取
讓頁面載入（尤其是後期資源的載入）更順暢更快一些
<meta http-equiv="x-dns-prefetch-control" content="on">
<link rel="dns-prefetch" href="//static.360buyimg.com">
<link rel="dns-prefetch" href="//misc.360buyimg.com">
<link rel="dns-prefetch" href="//img10.360buyimg.com">
<link rel="dns-prefetch" href="//img11.360buyimg.com">
<link rel="dns-prefetch" href="//img12.360buyimg.com">
.......
3.基於TCP的三次握手，夠建客戶端和伺服器端的連線通道
只有建立好連線通道，才能基於HTTP等傳輸協議，實現客戶端和伺服器端的資訊互動
4.傳送HTTP請求
基於HTTP等傳輸協議，客戶端把一些資訊傳遞給伺服器
-
HTTP請求報文（所有客戶端傳遞給伺服器的內容，統稱為請求報文）
-
谷歌控制檯NetWork中可以看到
-
請求起始行
-
請求首部（請求頭）
-
請求主體
-
-
強快取 和 協商快取（效能優化：減少HTTP請求的次數）
-
強快取 ( Cache-Control 和 Expires )
-
協商快取 ( Last-Modified 和 Etag )
-
5.伺服器接受到請求，並進行處理，最後把資訊返回給客戶端
-
HTTP響應報文（所有伺服器返回給客戶端的內容）
-
響應起始行
-
響應首部（響應頭）
-
date儲存的是伺服器的時間
-
...
-
-
響應主體
-
伺服器返回的時候是：先把響應頭資訊返回，然後繼續返回響應主體中的內容（需要的資訊大部分都是基於響應主體返回的）
-
6.斷開TCP連結通道 （四次揮手）
-
當客戶端把請求資訊傳送給伺服器的時候，就揮第一次手：客戶端告訴伺服器端，我已經把請求報文都給你了，你準備關閉吧
-
第二次揮手：由伺服器發起，告訴瀏覽器，我接收完請求報文，我準備關閉，你也準備吧；
-
第三次揮手：由伺服器發起，告訴瀏覽器，我響應報文傳送完畢，你準備關閉吧；
-
第四次揮手：由瀏覽器發起，告訴伺服器，我響應報文接收完畢，我準備關閉，你也準備吧；
Connection: Keep-Alive 保持TCP不中斷（效能優化點，減少每一次請求還需要重新建立連結通道的時間）