一.URL/URI
我們經(jīng)常會(huì)用到 URL，全稱統(tǒng)一資源定位符（Uniform Resource Locator），還有一種是 URI，統(tǒng)一資源標(biāo)識(shí)符（Uniform Resource Identifier），他們的單詞有著某種意義，以 URI 為例
Uniform
規(guī)定統(tǒng)一格式來(lái)便于處理不同資源，識(shí)別資源指定的訪問形式，加入新方案會(huì)更容易，比如 https：
Resource
資源，可以標(biāo)識(shí)的任何東西
Identifier
表示可標(biāo)識(shí)的對(duì)象
所以，URI 是由某個(gè)協(xié)議方案來(lái)表示資源的定位標(biāo)識(shí)符，舉個(gè)例子，我們采用 http 協(xié)議或者 ftp 協(xié)議，協(xié)議方案就是 http 和 ftp
而 URL 則是資源地點(diǎn)，可以說 URL 是 URI 的子集
二.簡(jiǎn)單的 HTTP 請(qǐng)求報(bào)文
HTTP 有不同的版本，我們針對(duì) 1.1 來(lái)學(xué)習(xí)
HTTP 協(xié)議的作用其實(shí)就是用于客戶端和服務(wù)端之間的通信，也就是說使用 HTTP 協(xié)議進(jìn)行必須一方是客戶端（也就是請(qǐng)求方）和一方是服務(wù)端（提供資源的一方）
HTTP 是一種不保存狀態(tài)的協(xié)議，也就是無(wú)狀態(tài)協(xié)議，我們可以理解為在使用 HTTP 通信后，HTTP 本身并不會(huì)對(duì)我們產(chǎn)生的信息進(jìn)行保存
使用 HTTP 會(huì)用到請(qǐng)求報(bào)文，請(qǐng)求報(bào)文是由請(qǐng)求方法，請(qǐng)求 URL， 協(xié)議版本和可選的的請(qǐng)求首部字段和內(nèi)容實(shí)體構(gòu)成，下面我們來(lái)看一下 HTTP 報(bào)文的內(nèi)容
GET /index.html HTTP/1.1
Host: jianshu.com
其中 GET 就是請(qǐng)求方法，訪問服務(wù)器的類型， /index.html 表示請(qǐng)求的資源，請(qǐng)求 URL，最后的 HTTP/1.1 就是請(qǐng)求的版本號(hào)了
而服務(wù)端會(huì)返回什么樣的怎么樣的響應(yīng)報(bào)文
HTTP/1.1 200 OK
Date: Fri, 19 May 2018 08:00:34 GMT
Content-Length: 279
Content-Type: text/html
<html>
HTTP/1.1 肯定代表的協(xié)議版本我們已經(jīng)知道，而 200 是狀態(tài)碼，熟悉的還有 404 等，OK 是原因短語(yǔ)，Date 則代表的創(chuàng)建響應(yīng)的日期時(shí)間，含 Content-Length 之后的內(nèi)容代表資源主體
所以我們可以得知，響應(yīng)報(bào)文主要由協(xié)議版本，狀態(tài)碼，用于解釋狀態(tài)碼的原因短語(yǔ)，可選的響應(yīng)首部字段以及實(shí)體主體構(gòu)成
三.GET/POST
HTTP 請(qǐng)求報(bào)文里提到了請(qǐng)求方法，HTTP 中的請(qǐng)求方法就是 GET 和 POST，還有不常用的 PUT，HEAD， DELETE，OPTION，TRACE，CONNECT等
我們主要是介紹常用的 GET 和 POST
GET
顧名思義，就是獲取，用來(lái)獲取指定的資源
請(qǐng)求內(nèi)容放在 url 中
請(qǐng)求參數(shù)有大小限制，參數(shù)直接暴露在 url 中，不適合含密傳輸
POST
GET 是獲取，自然 POST 就是傳輸，GET 也可以傳輸，但是由諸多限制，我們之后會(huì)說到，POST 更多的是上傳
請(qǐng)求內(nèi)容放在報(bào)文中
參數(shù)大小沒有限制，支持多種格式，適合傳遞密碼，用于表單登陸，比較安全
四.Cookie
我們上面說到其實(shí) HTTP 是一種無(wú)狀態(tài)的協(xié)議，但是我們有時(shí)在登陸 QQ 郵箱時(shí)發(fā)現(xiàn)我們的郵箱名已經(jīng)被記住了，這又是怎么回事呢？
是這樣的，隨著我們 WEB 技術(shù)的不斷發(fā)展，一個(gè)網(wǎng)站可能對(duì)應(yīng)多個(gè)網(wǎng)頁(yè)，你總不能每個(gè)網(wǎng)頁(yè)都重新去登陸一次，對(duì)用戶體驗(yàn)是不好的，既然由這方面的需求，技術(shù)也會(huì)得到改善，那當(dāng)時(shí)解決這個(gè)引入了什么呢？
對(duì)，那就是 cookie
Cookie 是通過在請(qǐng)求和響應(yīng)報(bào)文中寫入 Cookie 信息來(lái)控制客戶端的狀態(tài)
具體是通過服務(wù)器端發(fā)送的響應(yīng)報(bào)文里有一個(gè)名為 Set-Cookie 的首部字段信息來(lái)通知客戶端保存 Cookie，當(dāng)下次客戶端再次發(fā)送請(qǐng)求時(shí)，客戶端就會(huì)在請(qǐng)求報(bào)文里加入 Cookie 值然后發(fā)出去
五.HTTP 長(zhǎng)連接
以前進(jìn)行的 HTTP 通信其實(shí)都是一些小文本的通信，所以說當(dāng)時(shí)每進(jìn)行一次 HTTP 通信就要斷開一次 HTTP 連接其實(shí)不會(huì)有比較感覺遲緩
但是隨著互聯(lián)網(wǎng)的發(fā)展，我們現(xiàn)在每打開一個(gè)網(wǎng)頁(yè)，伴隨大量的圖片和文字，訪問一個(gè) HTML 文件也會(huì)訪問其他的圖片資源，就會(huì)產(chǎn)生很多 HTTP 請(qǐng)求，頻繁的連接和斷開，就會(huì)導(dǎo)致網(wǎng)頁(yè)打開的很慢，圖片半天加載不出來(lái)
為了解決這個(gè)問題，在 HTTP 1.1 就提出了持久連接，也被稱做 keep-alive，其特點(diǎn)是，只要任意一端沒有明確提出斷開連接，就保持 TCP 連接狀態(tài)
這樣省去了每發(fā)起一次 HTTP 服務(wù)就要建立一次 TCP 連接的時(shí)間，在網(wǎng)頁(yè)加載中是非常有效的，所以在 HTTP 1.1 中默認(rèn)所有的連接都是長(zhǎng)連接
