一黎比、HTTP 協(xié)議

HTTP 協(xié)議：超文本傳輸協(xié)議

是一種詳細規(guī)定了瀏覽器和萬維網(wǎng)(WWW = World Wide Web)服務(wù)器之間互相通信的規(guī)則蜕猫，通過因特網(wǎng)傳送萬維網(wǎng)文檔的數(shù)據(jù)傳送協(xié)議卖漫。 HTTP 是基于 TCP 的應(yīng)用層協(xié)議 (OSI 網(wǎng)絡(luò)七層協(xié)議從上到下分別是 應(yīng)用層、表示層胧弛、會話層 骂维、傳輸層、網(wǎng)絡(luò)層 、數(shù)據(jù)鏈路層毛萌、物理層）

請求/響應(yīng)報文
連接建立流程
HTTP 的特點

image.png

A苟弛、請求報文和響應(yīng)報文

1、請求報文

請求報文

如下:

分布

Host：指明了該對象所在的主機
Connection：Keep-Alive 首部行用來表明該瀏覽器告訴服務(wù)器使用持續(xù)連接
Content-Type: x-www-form-urlencoded 首部行用來表明 HTTP 會將請求參數(shù)用 key1=val1&key2=val2 的方式進行組織阁将，并放到請求實體里面
User-agent：首部行用來指明用戶代理膏秫，即向服務(wù)器發(fā)送請求的瀏覽器類型
Accept-lauguage：首部行表示用戶想得到該對象的法語版本（如果服務(wù)器中有這樣的對象的話），否則做盅， 服務(wù)器應(yīng)發(fā)送它的默認版本

2缤削、響應(yīng)報文

響應(yīng)報文

具體內(nèi)容

狀態(tài)碼及其相應(yīng)的短語指示了請求的結(jié)果

200 OK：請求成功，信息在返回的響應(yīng)報文中
301 Moved Permanently：請求的對象已經(jīng)被永久轉(zhuǎn)移了吹榴，新的 URL 定義在響應(yīng)報文中的 Location：首部行中亭敢。客戶軟件將自動獲取新的 URL
400 Bad Request：一個通用差錯代碼腊尚，指示該請求不能被服務(wù)器理解
404 Not Found：被請求的文件不在服務(wù)器上
505 HTTP Version Not Supported：服務(wù)器不支持請求報文使用的 HTTP 協(xié)議版本 <4 開頭的狀態(tài)碼通常是客戶端的問題吨拗，5 開頭的則通常是服務(wù)端的問題>

Connection：close 首部行告訴客戶，發(fā)送完報文后將關(guān)閉 TCP 連接婿斥。
Date:指的不是對象創(chuàng)建或最后修改的時間劝篷，而是服務(wù)器從文件系統(tǒng)中檢索到該對象，插入到響應(yīng)報文民宿， 并發(fā)送該響應(yīng)報文的時間娇妓。 
Server: 首部行指示該報文是由一臺 Apache Web 服務(wù)器產(chǎn)生的，類似于 HTTP 請求報文里的User-agent
Content-Length：首部行指示了被發(fā)送對象中的字節(jié)數(shù)Content- 
Type：首部行指示了實體體中的對象是 HTML 文本

二活鹰、HTTP 的請求方式

GET哈恰、POST、PUT志群、DELETE着绷、HEAD、OPTIONS

1锌云、GET 和 POST 方式的區(qū)別

從語法角度來看荠医，最直觀的區(qū)別就是:
GET 的請求參數(shù)一般以?分割拼接到 URL 后面，POST 請求參數(shù)在 Body 里面 GET 參數(shù)長度限制為 2048 個字符桑涎，POST 一般是沒限制的 GET 請求由于參數(shù)裸露在 URL 中彬向， 是不安全的，POST 請求則是相對安全 之所以說是相對安全攻冷，是因為娃胆，如果 POST 雖然參數(shù)非明文，但如果被抓包等曼，GET 和 POST 一樣都 是不安全的里烦。(HTTPS 該用還是得用)

而從語義的角度來看：

GET：獲取資源是 安全的凿蒜，冪等的(只讀的，純粹的)招驴， 可緩存的
POST：獲取資源是 非安全的篙程，非冪等的，不可緩存的

這里的安全是指不應(yīng)引起 Server 端的任何狀態(tài)變化

安全:GET 的語義就是獲取數(shù)據(jù)别厘，是不會引起服務(wù)器的狀態(tài)變化的虱饿，即是安全的。（HEAD触趴，OPTIONS 也 是安全的）
而 POST 語義則是提交數(shù)據(jù)氮发，是可能會引起服務(wù)器狀態(tài)變化的，即是不安全的
冪等:同一個請求方法執(zhí)行多次和執(zhí)行一次的效果完全相同
顯然 GET 請求是冪等而 POST 請求是非冪等的冗懦。 這里用冪等形容 GET 還不夠爽冕，因為 GET 不止是執(zhí)行多次和執(zhí)行一次的效果完全相同，而且是執(zhí)行一 次和執(zhí)行零次的效果也是完全相同的披蕉。
可緩存:請求是否可以被緩存颈畸。 GET 請求會主動進行 Cache

以上特性，并非并列没讲，正是因為 GET 是冪等的只讀的眯娱，即 GET 請求除了返回數(shù)據(jù)不會有其他副作用，所 以 GET 才是安全的爬凑，從而可以直接由 CDN 緩存徙缴，大大減輕服務(wù)器的負擔，也就是可緩存的嘁信。 而 POST 是非冪等的于样，即除了返回數(shù)據(jù)還會有其他副作用，所以 POST 是不安全的潘靖，必須交由 web 服務(wù) 器處理穿剖，即是不可緩存的

GET 和 POST 本質(zhì)上就是 TCP 鏈接，并無差別卦溢。但是由于 HTTP 的規(guī)定和瀏覽器/服務(wù)器的限制糊余，導(dǎo)致他 們在應(yīng)用過程中體現(xiàn)出一些不同。

在響應(yīng)時既绕，GET 產(chǎn)生一個 TCP 數(shù)據(jù)包啄刹；POST 產(chǎn)生兩個 TCP 數(shù)據(jù)包:
對于 GET 方式的請求涮坐，瀏覽器會把 Header 和實體主體一并發(fā)送出去凄贩，服務(wù)器響應(yīng) 200（返回數(shù)據(jù)）； 而對于 POST袱讹，瀏覽器先發(fā)送 Header疲扎，服務(wù)器響應(yīng) 100 Continue昵时，瀏覽器再發(fā)送實體主體，服務(wù)器響應(yīng) 200 OK（返回數(shù)據(jù)）

2椒丧、GET 相對 POST 的優(yōu)勢是什么壹甥？

1、最大的優(yōu)勢就是方便壶熏。GET 的 URL 可以直接手輸句柠，從而 GET 請求中的 URL 可以被存在書簽里，或者歷史記錄里
2棒假、可以被緩存溯职，大大減輕服務(wù)器的負擔 所以大多數(shù)情況下，還是用 GET 比較好帽哑。

三谜酒、HTTP 的特點

無連接、 無狀態(tài)
HTTP 的持久連接妻枕、Cookie/Session

1僻族、HTTP 的無狀態(tài)

即協(xié)議對于事務(wù)處理沒有記憶能力。 每次的請求都是獨立的屡谐，它的執(zhí)行情況和結(jié)果與前面的請求和之后的請求時無直接關(guān)系的述么，它不會受前面 的請求應(yīng)答情況直接影響，也不會直接影響后面的請求應(yīng)答情況 也就是說服務(wù)器中沒有保存客戶端的狀態(tài)康嘉，客戶端必須每次帶上自己的狀態(tài)去請求服務(wù)器

標準的 HTTP 協(xié)議指的是不包括 cookies碉输，session，application 的 HTTP 協(xié)議

2亭珍、HTTP 的持久連接

持久與非持久連接

非持久連接：每個連接處理一個請求-響應(yīng)事務(wù)敷钾。
持久連接：每個連接可以處理多個請求-響應(yīng)事務(wù)。
持久連接情況下肄梨，服務(wù)器發(fā)出響應(yīng)后讓 TCP 連接繼續(xù)打開著阻荒。同一對客戶/服務(wù)器之間的后續(xù)請求和響應(yīng) 可以通過這個連接發(fā)送。 HTTP/1.0 使用非持久連接众羡。HTTP/1.1 默認使用持久連接<keep-alive>侨赡。

非持久連接的每個連接，TCP 得在客戶端和服務(wù)端分配 TCP 緩沖區(qū)粱侣，并維持 TCP 變量羊壹，會嚴重增加服務(wù) 器負擔。而且每個對象都有 2 個 RTT(Round Trip Time齐婴，也就是一個數(shù)據(jù)包從發(fā)出去到回來的時間)的延遲油猫， 由于 TCP 的擁塞控制方案,每個對象都遭受 TCP 緩啟動，因為每個 TCP 連接都起始于緩啟動階段

HTTP 持久連接怎么判斷一個請求是否結(jié)束的柠偶？

Content-length：根據(jù)所接收字節(jié)數(shù)是否達到 Content-length 值
chunked(分塊傳輸):Transfer-Encoding情妖。當選擇分塊傳輸時睬关，響應(yīng)頭中可以不包含 Content-Length，服務(wù)器會先回復(fù)一個不帶數(shù)據(jù)的報文（只有響應(yīng)行和響應(yīng)頭和\r\n）毡证，然后開始 傳輸若干個數(shù)據(jù)塊电爹。當傳輸完若干個數(shù)據(jù)塊后，需要再傳輸一個空的數(shù)據(jù)塊料睛，當客戶端收到空的數(shù)據(jù) 塊時丐箩，則客戶端知道數(shù)據(jù)接收完畢。

四恤煞、HTTPS雏蛮、對稱加密、非對稱加密

1阱州、HTTPS 和 HTTP 的區(qū)別

HTTPS 協(xié)議 = HTTP 協(xié)議 + SSL/TLS 協(xié)議 SSL 的全稱是 Secure Sockets Layer挑秉，即安全套接層協(xié)議，是為網(wǎng)絡(luò)通信提供安全及數(shù)據(jù)完整性的一種安全協(xié) 議苔货。
TLS 的全稱是 Transport Layer Security犀概，即安全傳輸層協(xié)議。 即 HTTPS 是安全的 HTTP夜惭。

2姻灶、HTTPS 的連接建立流程

HTTPS 為了兼顧安全與效率，同時使用了對稱加密和非對稱加密诈茧。在傳輸?shù)倪^程中會涉及到三個密鑰：
服務(wù)器端的公鑰和私鑰产喉，用來進行非對稱加密

客戶端生成的隨機密鑰，用來進行對稱加密

SSL/TSL

傳輸八大步驟解釋如下

1敢会、客戶端訪問 HTTPS 連接曾沈。

客戶端會把安全協(xié)議版本號、客戶端支持的加密算法列表鸥昏、隨機數(shù) C 發(fā)給服務(wù)端塞俱。

2、服務(wù)端發(fā)送證書給客戶端

服務(wù)端接收密鑰算法配件后吏垮，會和自己支持的加密算法列表進行比對障涯，如果不符合，則斷開連接膳汪。否則唯蝶， 服務(wù)端會在該算法列表中，選擇一種對稱算法（如 AES）遗嗽、一種公鑰算法（如具有特定秘鑰長度的 RSA） 和一種 MAC 算法發(fā)給客戶端粘我。 服務(wù)器端有一個密鑰對，即公鑰和私鑰媳谁，是用來進行非對稱加密使用的涂滴，服務(wù)器端保存著私鑰，不能將其 泄露晴音，公鑰可以發(fā)送給任何人柔纵。 在發(fā)送加密算法的同時還會把數(shù)字證書和隨機數(shù) S 發(fā)送給客戶端

3、客戶端驗證 server 證書

會對 server 公鑰進行檢查锤躁，驗證其合法性搁料，如果發(fā)現(xiàn)發(fā)現(xiàn)公鑰有問題，那么 HTTPS 傳輸就無法繼續(xù)系羞。

4郭计、客戶端組裝會話秘鑰

如果公鑰合格，那么客戶端會用服務(wù)器公鑰來生成一個前主秘鑰(Pre-Master Secret椒振，PMS)昭伸，并通過該前主秘鑰和隨機數(shù) C、S 來組裝成會話秘鑰

5澎迎、客戶端將前主秘鑰加密發(fā)送給服務(wù)端

是通過服務(wù)端的公鑰來對前主秘鑰進行非對稱加密庐杨，發(fā)送給服務(wù)端

6、服務(wù)端通過私鑰解密得到前主秘鑰

服務(wù)端接收到加密信息后夹供，用私鑰解密得到主秘鑰灵份。

7、服務(wù)端組裝會話秘鑰

服務(wù)端通過前主秘鑰和隨機數(shù) C哮洽、S 來組裝會話秘鑰填渠。 至此，服務(wù)端和客戶端都已經(jīng)知道了用于此次會話的主秘鑰鸟辅。

8氛什、數(shù)據(jù)傳輸

客戶端收到服務(wù)器發(fā)送來的密文，用客戶端密鑰對其進行對稱解密匪凉，得到服務(wù)器發(fā)送的數(shù)據(jù)屉更。 同理，服務(wù)端收到客戶端發(fā)送來的密文洒缀，用服務(wù)端密鑰對其進行對稱解密瑰谜，得到客戶端發(fā)送的數(shù)據(jù)。

總結(jié)：

會話秘鑰 = random S + random C + 前主秘鑰
HTTPS 連接建立過程使用非對稱加密树绩，而非對稱加密是很耗時的一種加密方式
后續(xù)通信過程使用對稱加密萨脑，減少耗時所帶來的性能損耗 其中，對稱加密加密的是實際的數(shù)據(jù)饺饭，非對稱加密加密的是對稱加密所需要的客戶端的密鑰渤早。

未完待續(xù)