任何一個(gè)技術(shù)和知識(shí)在了解了大概之后還需要在學(xué)習(xí)和實(shí)踐中不斷總結(jié)纤怒、思考才能真正掌握，變成自己的東西峭状。
用自己的方式分析技術(shù)原理克滴，總結(jié)自己的經(jīng)驗(yàn)，分享他人的見解优床，轉(zhuǎn)述權(quán)威的解讀劝赔。

1 HTTP 協(xié)議簡介

HTTP (HyperText Transfer Protocol, 超文本傳輸協(xié)議)是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議，它是基于 TCP 的應(yīng)用層協(xié)議胆敞，簡單地說就是客戶端和服務(wù)器進(jìn)行通信的一種規(guī)則着帽，它的模式非常簡單杂伟，就是客戶端發(fā)起請求，服務(wù)器響應(yīng)請求仍翰，如下圖所示：

http請求-響應(yīng)模型

HTTP是一個(gè)應(yīng)用層協(xié)議赫粥，由請求和響應(yīng)構(gòu)成，是一個(gè)標(biāo)準(zhǔn)的客戶端服務(wù)器模型予借。HTTP是一個(gè)無狀態(tài)的協(xié)議越平。
在Internet中所有的傳輸都是通過TCP/IP進(jìn)行的。HTTP協(xié)議作為TCP/IP模型中應(yīng)用層的協(xié)議也不例外灵迫。HTTP協(xié)議通常承載于TCP協(xié)議之上喧笔，有時(shí)也承載于TLS或SSL協(xié)議層之上，這個(gè)時(shí)候龟再，就成了我們常說的HTTPS。如下圖所示：

111703047392802.png

HTTP默認(rèn)的端口號(hào)為80尼变，HTTPS的端口號(hào)為443利凑。
瀏覽網(wǎng)頁是HTTP的主要應(yīng)用，但是這并不代表HTTP就只能應(yīng)用于網(wǎng)頁的瀏覽嫌术。HTTP是一種協(xié)議哀澈，只要通信的雙方都遵守這個(gè)協(xié)議，HTTP就能有用武之地度气。比如咱們常用的QQ割按，迅雷這些軟件，都會(huì)使用HTTP協(xié)議(還包括其他的協(xié)議)磷籍。

HTTP 最早于 1991 年發(fā)布适荣，是 0.9 版，不過目前該版本已不再用院领。HTTP 目前在使用的版本主要有：

• HTTP/1.0弛矛，于 1996 年 5 月發(fā)布，引入了多種功能比然，至今仍在使用當(dāng)中丈氓。
• HTTP/1.1，于 1997 年 1 月發(fā)布强法，持久連接被默認(rèn)采用万俗，是目前最流行的版本。
• HTTP/2 饮怯，于 2015 年 5 月發(fā)布闰歪，引入了服務(wù)器推送等多種功能，是目前最新的版本硕淑。
• HTTPS课竣，HTTPS是HTTP協(xié)議的安全版本嘉赎，HTTP協(xié)議的數(shù)據(jù)傳輸是明文的，是不安全的于樟，HTTPS使用了SSL/TLS協(xié)議進(jìn)行了加密處理公条。

2 HTTP工作原理

HTTP協(xié)議定義Web客戶端如何從Web服務(wù)器請求Web頁面，以及服務(wù)器如何把Web頁面?zhèn)魉徒o客戶端迂曲。HTTP協(xié)議采用了請求/響應(yīng)模型靶橱。客戶端向服務(wù)器發(fā)送一個(gè)請求報(bào)文路捧，請求報(bào)文包含請求的方法关霸、URL、協(xié)議版本杰扫、請求頭部和請求數(shù)據(jù)队寇。服務(wù)器以一個(gè)狀態(tài)行作為響應(yīng)，響應(yīng)的內(nèi)容包括協(xié)議的版本章姓、成功或者錯(cuò)誤代碼佳遣、服務(wù)器信息、響應(yīng)頭部和響應(yīng)數(shù)據(jù)凡伊。請求的過程：3次握手零渐，請求，響應(yīng)系忙，斷開連接诵盼。

在TCP協(xié)議中要通過三次握手才能建立可靠連接。

三次握手

第一次握手：建立連接時(shí)银还，客戶端發(fā)送syn包(syn=j)到服務(wù)器风宁，并進(jìn)入SYN_SEND狀態(tài)，等待服務(wù)器確認(rèn)蛹疯；
第二次握手：服務(wù)器收到syn包杀糯，必須確認(rèn)客戶的SYN（ack=j+1），同時(shí)自己也發(fā)送一個(gè)SYN包（syn=k）苍苞，即SYN+ACK包固翰，此時(shí)服務(wù)器 進(jìn)入SYN_RECV狀態(tài)；
第三次握手：客戶端收到服務(wù)器的SYN＋ACK包羹呵，向服務(wù)器發(fā)送確認(rèn)包ACK(ack=k+1)骂际，此包發(fā)送完畢，客戶端和服務(wù)器進(jìn)入 ESTABLISHED狀態(tài)冈欢，完成三次握手歉铝。

UDP和TCP的區(qū)別
最本質(zhì)的區(qū)別就是TCP是面向連接的，而UDP是非面向連接的凑耻。

• 什么叫面向連接呢太示？事先為所發(fā)送的數(shù)據(jù)開辟出連接好的通道柠贤，然后再進(jìn)行數(shù)據(jù)發(fā)送，像打電話类缤，只能兩人打臼勉，第三人打就顯示占線
• 非面向連接：是指通信雙方不需要事先建立一條通信線路，而是把每個(gè)帶有目的地址的包（報(bào)文分組）送到線路上餐弱，由系統(tǒng)自主選定路線進(jìn)行傳輸宴霸，就像寫信，不管對方有多忙膏蚓，把信放到郵筒崩哩，就與自己無關(guān)系了换帜。

TCP支持的服務(wù)有FTP肤频、SMTP等击喂，而UDP支持的服務(wù)有DNS、SNMP论笔、QQ等

以下是 HTTP 請求/響應(yīng)的步驟：

1. 客戶端連接到Web服務(wù)器
   一個(gè)HTTP客戶端幢尚，通常是瀏覽器，與Web服務(wù)器的HTTP端口（默認(rèn)為80）建立一個(gè)TCP套接字連接翅楼。例如，https://www.baidu.com真慢。

2. 發(fā)送HTTP請求
   通過TCP套接字毅臊，客戶端向Web服務(wù)器發(fā)送一個(gè)文本的請求報(bào)文，一個(gè)請求報(bào)文由請求行黑界、請求頭部管嬉、空行和請求數(shù)據(jù)4部分組成。

3. 服務(wù)器接受請求并返回HTTP響應(yīng)
   Web服務(wù)器解析請求朗鸠，定位請求資源蚯撩。服務(wù)器將資源復(fù)本寫到TCP套接字，由客戶端讀取烛占。一個(gè)響應(yīng)由狀態(tài)行胎挎、響應(yīng)頭部、空行和響應(yīng)數(shù)據(jù)4部分組成忆家。

4. 釋放連接TCP連接
   若connection 模式為close犹菇，則服務(wù)器主動(dòng)關(guān)閉TCP連接，客戶端被動(dòng)關(guān)閉連接芽卿，釋放TCP連接;若connection 模式為keepalive揭芍，則該連接會(huì)保持一段時(shí)間，在該時(shí)間內(nèi)可以繼續(xù)接收請求;

5. 客戶端瀏覽器解析HTML內(nèi)容
   客戶端瀏覽器首先解析狀態(tài)行卸例，查看表明請求是否成功的狀態(tài)代碼称杨。然后解析每一個(gè)響應(yīng)頭肌毅，響應(yīng)頭告知以下為若干字節(jié)的HTML文檔和文檔的字符集」迷客戶端瀏覽器讀取響應(yīng)數(shù)據(jù)HTML悬而，根據(jù)HTML的語法對其進(jìn)行格式化，并在瀏覽器窗口中顯示页衙。

例如：在瀏覽器地址欄鍵入U(xiǎn)RL摊滔，按下回車之后會(huì)經(jīng)歷以下流程：

1. 瀏覽器向 DNS 服務(wù)器請求解析該 URL 中的域名所對應(yīng)的 IP 地址;
2. 解析出 IP 地址后，根據(jù)該 IP 地址和默認(rèn)端口 80店乐，和服務(wù)器建立TCP連接;
3. 瀏覽器發(fā)出讀取文件(URL 中域名后面部分對應(yīng)的文件)的HTTP 請求艰躺，該請求報(bào)文作為 TCP 三次握手的第三個(gè)報(bào)文的數(shù)據(jù)發(fā)送給服務(wù)器;
4. 服務(wù)器對瀏覽器請求作出響應(yīng)，并把對應(yīng)的 html 文本發(fā)送給瀏覽器;
5. 釋放 TCP連接;
6. 瀏覽器將該 html 文本并顯示內(nèi)容;

HTTP協(xié)議是基于請求/響應(yīng)模式的眨八，因此只要服務(wù)端給了響應(yīng)腺兴，本次HTTP連接就結(jié)束了，或者更準(zhǔn)確的說廉侧，是本次HTTP請求就結(jié)束了页响，根本沒有長連接這一說。那么自然也就沒有短連接這一說了段誊。
　　之所以網(wǎng)絡(luò)上說HTTP分為長連接和短連接闰蚕，其實(shí)本質(zhì)上是說的TCP連接。TCP連接是一個(gè)雙向的通道连舍，它是可以保持一段時(shí)間不關(guān)閉的没陡，因此TCP連接才有真正的長連接和短連接這一說。
　　其實(shí)知道了以后索赏，會(huì)覺得這很好理解盼玄。HTTP協(xié)議說到底是應(yīng)用層的協(xié)議，而TCP才是真正的傳輸層協(xié)議潜腻，只有負(fù)責(zé)傳輸?shù)倪@一層才需要建立連接埃儿。

一個(gè)形象的例子就是，拿你在網(wǎng)上購物來說融涣，HTTP協(xié)議是指的那個(gè)快遞單童番，你寄件的時(shí)候填的單子就像是發(fā)了一個(gè)HTTP請求，等貨物運(yùn)到地方了威鹿，快遞員會(huì)根據(jù)你發(fā)的請求把貨物送給相應(yīng)的收貨人妓盲。而TCP協(xié)議就是中間運(yùn)貨的那個(gè)大貨車，也可能是火車或者飛機(jī)专普，但不管是什么悯衬，它是負(fù)責(zé)運(yùn)輸?shù)模虼吮仨氁新罚还苁堑厣线€是天上筋粗。那么這個(gè)路就是所謂的TCP連接策橘，也就是一個(gè)雙向的數(shù)據(jù)通道。

因此娜亿，LZ現(xiàn)在甚至覺得丽已，“HTTP連接”這個(gè)詞就不應(yīng)該出現(xiàn)，它只是一個(gè)應(yīng)用層的協(xié)議买决，根本就沒有所謂的連接這一說沛婴，就像FTP也是應(yīng)用層的協(xié)議，但是你有聽說過FTP連接嗎督赤？（恩嘁灯，好像是聽過，-_-躲舌，但你現(xiàn)在知道了丑婿，其實(shí)所謂的FTP連接，嚴(yán)格來說没卸，依舊是TCP連接）
　　實(shí)際上羹奉，說HTTP請求和HTTP響應(yīng)會(huì)更準(zhǔn)確一些，而HTTP請求和HTTP響應(yīng)约计，都是通過TCP連接這個(gè)通道來回傳輸?shù)摹?br> 　　不管怎么說诀拭，一定要?jiǎng)?wù)必記住，長連接是指的TCP連接煤蚌，而不是HTTP連接耕挨。

3 HTTPS傳輸協(xié)議原理

HTTPS（全稱：Hypertext Transfer Protocol over Secure Socket Layer），是以安全為目標(biāo)的HTTP通道铺然，簡單講是HTTP的安全版。即HTTP下加入SSL層酒甸，HTTPS的安全基礎(chǔ)是SSL魄健，因此加密的詳細(xì)內(nèi)容請看SSL。

3.1 兩種基本的加解密算法類型

• 對稱加密：密鑰只有一個(gè)插勤，加密解密為同一個(gè)密碼沽瘦，且加解密速度快，典型的對稱加密算法有DES农尖、AES等析恋。
• 非對稱加密：密鑰成對出現(xiàn)（且根據(jù)公鑰無法推知私鑰，根據(jù)私鑰也無法推知公鑰）盛卡，加密解密使用不同密鑰（公鑰加密需要私鑰解密助隧，私鑰加密需要公鑰解密），相對對稱加密速度較慢滑沧，典型的非對稱加密算法有RSA并村、DSA等巍实。

3.2 HTTPS通信過程

HTTPS通信過程

3.3 HTTPS通信的優(yōu)點(diǎn)

客戶端產(chǎn)生的密鑰只有客戶端和服務(wù)器端能得到；
加密的數(shù)據(jù)只有客戶端和服務(wù)器端才能得到明文哩牍；
客戶端到服務(wù)端的通信是安全的棚潦。

4 HTTP 請求

請求報(bào)文

HTTP 請求由三部分組成：

• 請求行：包含請求方法、請求地址和 HTTP 協(xié)議版本
• 消息報(bào)頭：包含一系列的鍵值對
• 請求正文（可選）：注意和消息報(bào)頭之間有一個(gè)空行
  如圖所示：
  
  HTTP請求

下面是一個(gè) HTTP GET 請求的例子：

GET / HTTP/1.1
Host: httpbin.org
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.98 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate, sdch, br
Accept-Language: zh-CN,zh;q=0.8,en;q=0.6,zh-TW;q=0.4
Cookie: _ga=GA1.2.475070272.1480418329; _gat=1

上面的第一行就是一個(gè)請求行：

GET / HTTP/1.1

其中膝昆，GET 是請求方法丸边，表示從服務(wù)器獲取資源；/ 是一個(gè)請求地址荚孵；HTTP/1.1 表明 HTTP 的版本是 1.1妹窖。

請求行后面的一系列鍵值對就是消息報(bào)頭：

Host: httpbin.org
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.98 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate, sdch, br
Accept-Language: zh-CN,zh;q=0.8,en;q=0.6,zh-TW;q=0.4
Cookie: _ga=GA1.2.475034215.1480418329; _gat=1

其中：

• Host 是請求報(bào)頭域，用于指定被請求資源的 Internet 主機(jī)和端口號(hào)处窥，它通常從 HTTP URL 中提取出來嘱吗；
• Connection 表示連接狀態(tài)，keep-alive 表示該連接是持久連接（persistent connection）滔驾，即 TCP 連接默認(rèn)不關(guān)閉谒麦，可以被多個(gè)請求復(fù)用，如果客戶端和服務(wù)器發(fā)現(xiàn)對方有一段時(shí)間沒有活動(dòng)哆致，就可以主動(dòng)關(guān)閉連接绕德；
• Cache-Control 用于指定緩存指令，它的值有 no-cache, no-store, max-age 等摊阀，max-age=秒表示資源在本地緩存多少秒耻蛇；
• User-Agent 用于標(biāo)識(shí)請求者的一些信息，比如瀏覽器類型和版本胞此，操作系統(tǒng)等臣咖；
• Accept 用于指定客戶端希望接受哪些類型的信息，比如 text/html, image/gif 等漱牵；
• Accept-Encoding 用于指定可接受的內(nèi)容編碼夺蛇；
• Accept-Language 用于指定可接受的自然語言；
• Cookie 用于維護(hù)狀態(tài)酣胀，可做用戶認(rèn)證刁赦，服務(wù)器檢驗(yàn)等，它是瀏覽器儲(chǔ)存在用戶電腦上的文本片段闻镶；

5 HTTP 請求方法

HTTP請求方法

HTTP 通過不同的請求方法以多種方式來操作指定的資源甚脉，常用的請求方法如下表：

6 再議 POST 和 PUT

注意到么抗，POST 和 PUT 都可用于創(chuàng)建或更新資源，然而亚铁，它們之間還是有比較大的區(qū)別：

• POST 所對應(yīng)的 URI 并非創(chuàng)建的資源本身蝇刀，而是資源的接收者，資源本身的存放位置由服務(wù)器決定徘溢；而 PUT 所對應(yīng)的 URI 是要?jiǎng)?chuàng)建或更新的資源本身吞琐，它指明了具體的存放位置

比如，往某個(gè)站點(diǎn)添加一篇文章然爆，如果使用 POST 來創(chuàng)建資源站粟，可類似這樣：

POST /articles HTTP/1.1

{
    "author": "ethan",
    "title": "hello world",
    "content": "hello world"
}

在上面，POST 對應(yīng)的 URI 是 /articles曾雕，它是資源的接收者奴烙，而非資源的標(biāo)識(shí)，如果資源被成功創(chuàng)建翻默，服務(wù)器可以返回 201 Created 狀態(tài)以及新建資源的位置缸沃，比如：

HTTP/1.1 201 Created
Location: /articles/abcdef123

我們?nèi)绻佬陆ㄙY源的標(biāo)識(shí)符恰起，可以使用PUT 來創(chuàng)建資源修械，比如：

PUT /articles/abcdef234 HTTP/1.1

{
    "author": "peter",
    "title": "hello world",
    "content": "hello world"
}

在上面，PUT 對應(yīng)的 URI 是/articles/abcdef234检盼，它指明了資源的存放位置肯污，如果資源被成功創(chuàng)建，服務(wù)器可以返回 201 Created 狀態(tài)以及新建資源的位置，比如：

HTTP/1.1 201 Created
Location: /articles/abcdef234

• 使用 PUT 更新某一資源蹦渣，需要更新資源的全部屬性哄芜；而使用 POST，可以更新全部或一部分值

比如使用 PUT 更新地址為 /articles/abcdef234 的文章的標(biāo)題柬唯，我們需要發(fā)送所有值：

PUT /articles/abcdef234 HTTP/1.1

{
    "author": "peter",
    "title": "hello python",
    "content": "hello world"
}

而使用 POST认臊，可以更新某個(gè)域的值：

POST /articles/abcdef234 HTTP/1.1

{
    "title": "hello python"
}

• POST 是不冪等的，PUT 是冪等的锄奢，這是一個(gè)很重要的區(qū)別

HTTP 方法的冪等性是指一次和多次請求某一個(gè)資源應(yīng)該具有同樣的副作用失晴，注意這里是副作用，而不是返回結(jié)果拘央。

GET 方法用于獲取資源涂屁，不會(huì)改變資源的狀態(tài)，不論調(diào)用一次還是多次都沒有副作用灰伟，因此它是冪等的拆又；DELETE 方法用于刪除資源，有副作用栏账，但調(diào)用一次或多次都是刪除同個(gè)資源帖族，產(chǎn)生的副作用是相同的，因此也是冪等的发笔；POST 是不冪等的盟萨，因?yàn)閮纱蜗嗤?POST 請求會(huì)在服務(wù)器創(chuàng)建兩份資源，它們具有不同的 URI了讨；PUT 是冪等的捻激，對同一 URI 進(jìn)行多次 PUT 的副作用和一次 PUT 是相同的。

7 HTTP 響應(yīng)

響應(yīng)報(bào)文

HTTP 響應(yīng)與 HTTP 請求相似前计，由三部分組成：

• 狀態(tài)行：包含 HTTP 協(xié)議版本胞谭、狀態(tài)碼和狀態(tài)描述，以空格分隔
• 響應(yīng)頭：即消息報(bào)頭男杈，包含一系列的鍵值對

• 響應(yīng)正文：返回內(nèi)容丈屹，注意和響應(yīng)頭之間有一個(gè)空行
  如圖所示：

  
  
  HTTP響應(yīng)

下面是一個(gè) HTTP GET 請求的響應(yīng)結(jié)果：

HTTP/1.1 200 OK
Server: nginx
Date: Tue, 29 Nov 2016 13:08:38 GMT
Content-Type: application/json
Content-Length: 203
Connection: close
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

{
  "args": {}, 
  "headers": {
    "Host": "httpbin.org", 
    "User-Agent": "Paw/2.3.1 (Macintosh; OS X/10.11.3) GCDHTTPRequest"
  }, 
  "origin": "13.75.42.240", 
  "url": "https://httpbin.org/get"
}

上面的第一行就是一個(gè)狀態(tài)行：

HTTP/1.1 200 OK

其中，200 是狀態(tài)碼伶棒，表示客戶端請求成功旺垒，OK 是相應(yīng)的狀態(tài)描述。

狀態(tài)碼是一個(gè)三位的數(shù)字肤无，常見的狀態(tài)碼有以下幾類：

HTTP的響應(yīng)狀態(tài)碼

1XX 消息 -- 請求已被服務(wù)接收先蒋，繼續(xù)處理
2XX 成功 -- 請求已成功被服務(wù)器接收、理解宛渐、并接受
200 OK
201 Created 已創(chuàng)建
202 Accepted 接收
203 Non-Authoritative Information 非認(rèn)證信息
204 No Content 無內(nèi)容
3XX 重定向 -- 需要后續(xù)操作才能完成這一請求
301 Moved Permanently 請求永久重定向
302 Moved Temporarily 請求臨時(shí)重定向
304 Not Modified 文件未修改竞漾，可以直接使用緩存的文件
305 Use Proxy 使用代理
4XX 請求錯(cuò)誤 -- 請求含有詞法錯(cuò)誤或者無法被執(zhí)行
400 Bad Request 由于客戶端請求有語法錯(cuò)誤眯搭，不能被服務(wù)器所理解
401 Unauthorized 請求未經(jīng)授權(quán)。這個(gè)狀態(tài)代碼必須和WWW-Authenticate報(bào)頭域一起使用
403 Forbidden 服務(wù)器收到請求业岁，但是拒絕提供服務(wù)鳞仙。服務(wù)器通常會(huì)在響應(yīng)正文中給出不提供服務(wù)的原因
404 Not Found 請求的資源不存在，例如笔时，輸入了錯(cuò)誤的URL
5XX 服務(wù)器錯(cuò)誤 -- 服務(wù)器在處理某個(gè)正確請求時(shí)發(fā)生錯(cuò)誤
500 Internal Server Error 服務(wù)器發(fā)生不可預(yù)期的錯(cuò)誤棍好，導(dǎo)致無法完成客戶端的請求
503 Service Unavailable 服務(wù)器當(dāng)前不能夠處理客戶端的請求，在一段時(shí)間之后允耿，服務(wù)器可能會(huì)恢復(fù)正常
504 Gateway Time-out 網(wǎng)關(guān)超時(shí)

狀態(tài)行后面的一系列鍵值對就是消息報(bào)頭梳玫，即響應(yīng)頭：

Server: nginx
Date: Tue, 29 Nov 2016 13:08:38 GMT
Content-Type: application/json
Content-Length: 203
Connection: close
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

其中：

• Server 包含了服務(wù)器用來處理請求的軟件信息，跟請求報(bào)頭域 User-Agent 相對應(yīng)右犹；
• Content-Type 用于指定發(fā)送給接收者（比如瀏覽器）的響應(yīng)正文的媒體類型提澎，比如 text/html, text/css, image/png, image/jpeg, video/mp4, application/pdf, application/json 等；
• Content-Length 指明本次回應(yīng)的數(shù)據(jù)長度念链；

8 HTTP 特點(diǎn)

• 客戶端/服務(wù)器模式
• 簡單快速：客戶端向服務(wù)器請求服務(wù)時(shí)盼忌，通過傳送請求方法、請求地址和數(shù)據(jù)體（可選）即可
• 靈活：允許傳輸任意類型的數(shù)據(jù)對象掂墓，通過 Content-Type 標(biāo)識(shí)
• 無狀態(tài)：對事物處理沒記憶能力谦纱，HTTP協(xié)議是無狀態(tài)的，就是說每次HTTP請求都是獨(dú)立的君编，任何兩個(gè)請求之間沒有什么必然的聯(lián)系跨嘉。但是在實(shí)際應(yīng)用當(dāng)中并不是完全這樣的，引入了Cookie和Session機(jī)制來關(guān)聯(lián)請求吃嘿。
• 多次HTTP請求祠乃，在客戶端請求網(wǎng)頁時(shí)多數(shù)情況下并不是一次請求就能成功的，服務(wù)端首先是響應(yīng)HTML頁面兑燥，然后瀏覽器收到響應(yīng)之后發(fā)現(xiàn)HTML頁面還引用了其他的資源亮瓷，例如，CSS降瞳，JS文件嘱支，圖片等等，還會(huì)自動(dòng)發(fā)送HTTP請求這些需要的資源≌跫ⅲ現(xiàn)在的HTTP版本支持管道機(jī)制除师，可以同時(shí)請求和響應(yīng)多個(gè)請求，大大提高了效率扔枫。
• 基于TCP協(xié)議汛聚，HTTP協(xié)議目的是規(guī)定客戶端和服務(wù)端數(shù)據(jù)傳輸?shù)母袷胶蛿?shù)據(jù)交互行為，并不負(fù)責(zé)數(shù)據(jù)傳輸?shù)募?xì)節(jié)茧吊。底層是基于TCP實(shí)現(xiàn)的≌炅耄現(xiàn)在使用的版本當(dāng)中是默認(rèn)持久連接的，也就是多次HTTP請求使用一個(gè)TCP連接搓侄。

9 Cookie和Session的區(qū)別和聯(lián)系

Cookie和Session都是為了保存客戶端和服務(wù)端之間的交互狀態(tài)瞄桨，實(shí)現(xiàn)機(jī)制不同，各有優(yōu)缺點(diǎn)讶踪。首先一個(gè)最大的區(qū)別就是Cookie是保存在客戶端而Session就保存在服務(wù)端的芯侥。Cookie是客戶端請求服務(wù)端時(shí)服務(wù)器會(huì)將一些信息以鍵值對的形式返回給客戶端，保存在瀏覽器中乳讥，交互的時(shí)候可以加上這些Cookie值柱查。用Cookie就可以方便的做一些緩存。Cookie的缺點(diǎn)是大小和數(shù)量都有限制云石；Cookie是存在客戶端的可能被禁用唉工、刪除、篡改汹忠，是不安全的淋硝；Cookie如果很大，每次要請求都要帶上宽菜，這樣就影響了傳輸效率谣膳。Session是基于Cookie來實(shí)現(xiàn)的，不同的是Session本身存在于服務(wù)端铅乡，但是每次傳輸?shù)臅r(shí)候不會(huì)傳輸數(shù)據(jù)继谚，只是把代表一個(gè)客戶端的唯一ID（通常是JSESSIONID）寫在客戶端的Cookie中，這樣每次傳輸這個(gè)ID就可以了阵幸。Session的優(yōu)勢就是傳輸數(shù)據(jù)量小花履，比較安全。但是Session也有缺點(diǎn)挚赊，就是如果Session不做特殊的處理容易失效臭挽、過期、丟失或者Session過多導(dǎo)致服務(wù)器內(nèi)存溢出咬腕，并且要實(shí)現(xiàn)一個(gè)穩(wěn)定可用安全的分布式Session框架也是有一定復(fù)雜度的欢峰。在實(shí)際使用中就要結(jié)合Cookie和Session的優(yōu)缺點(diǎn)針對不同的問題來設(shè)計(jì)解決方案。

10 小結(jié)

• HTTP 是在網(wǎng)絡(luò)上傳輸 HTML 的協(xié)議涨共，用于瀏覽器和服務(wù)器的通信纽帖，默認(rèn)使用 80 端口。
• URL 地址用于定位資源举反，HTTP 中的 GET, POST, PUT, DELETE 用于操作資源懊直，比如查詢，增加火鼻，更新等室囊。
• GET, PUT, DELETE 是冪等的雕崩，POST 是不冪等的。
• POST VS PUT

1. 使用 PUT 創(chuàng)建資源需要提供資源的唯一標(biāo)識(shí)（具體存放位置）融撞，POST 不需要盼铁，POST 的數(shù)據(jù)存放位置由服務(wù)器自己決定
2. 使用 PUT 更新某一資源，需要更新資源的全部屬性尝偎；而使用 POST饶火，可以更新全部或一部分值
3. POST 是不冪等的，PUT 是冪等的致扯，這是一個(gè)很重要的區(qū)別

• GET 可提交的數(shù)據(jù)量受到URL 長度的限制肤寝，HTTP 協(xié)議規(guī)范沒有對 URL 長度進(jìn)行限制，這個(gè)限制是特定的瀏覽器及服務(wù)器對它的限制抖僵。

每種瀏覽器也會(huì)對url的長度有所限制鲤看，下面是幾種常見瀏覽器的url長度限制:(單位:字符)

　　IE　　:　　2803ASCII字符
　　Firefox　　:　　65536ASCII字符　
　　Chrome　　:　　8182ASCII字符
　　Safari　　:　　80000ASCII字符
　　Opera　　:　　190000ASCII字符

對于get請求，在url的長度限制范圍之內(nèi)耍群，請求的參數(shù)個(gè)數(shù)沒有限制刨摩。

• 理論上講，POST 是沒有大小限制的世吨，HTTP 協(xié)議規(guī)范也沒有進(jìn)行大小限制澡刹，出于安全考慮，服務(wù)器軟件在實(shí)現(xiàn)時(shí)會(huì)做一定限制耘婚。

編程并沒有捷徑罢浇，真正的成長都是來源于實(shí)踐、思考和總結(jié)沐祷。