http相關(guān)內(nèi)容
http基礎(chǔ)概念和依賴協(xié)議
http，超文本傳輸協(xié)議衷笋，一種無狀態(tài)連接協(xié)議苟鸯，處于TCP/IP協(xié)議族中的應(yīng)用層，和Http同處于一層的協(xié)議有DNS協(xié)議（主要負(fù)責(zé)域名解析的協(xié)議）闪湾，http協(xié)議還依賴TCP（傳輸層），依賴IP協(xié)議（網(wǎng)絡(luò)層）和物理設(shè)備和驅(qū)動（鏈路層）绩卤。
一個(gè)常見http請求的執(zhí)行流程途样，比如瀏覽器輸入 www.baidu.com 整個(gè)執(zhí)行流程
- 首先通過DNS協(xié)議查詢 www.baidu.com 地址的IP地址
- 瀏覽器根據(jù) www.baidu.com ，IP地址濒憋，GET請求方式何暇，還有一些請求頭信息
- 將http封裝的請求數(shù)據(jù)包，通過TCP協(xié)議發(fā)送數(shù)據(jù)包凛驮，TCP通過三次握手獲取客戶端-服務(wù)器連接裆站，整個(gè)數(shù)據(jù)包有可能不是一次性發(fā)送到服務(wù)器端，可能切分成很多合適的大小的數(shù)據(jù)包進(jìn)行發(fā)送，每發(fā)送一個(gè)數(shù)據(jù)包宏胯，發(fā)送方都需要接收方返回一個(gè)確認(rèn)碼來確保這個(gè)數(shù)據(jù)包是到達(dá)接收方的羽嫡，如果在發(fā)送某一個(gè)數(shù)據(jù)包沒有接收到確認(rèn)碼的話，會進(jìn)行重發(fā)肩袍，直到斷開超時(shí)斷開
- 每一個(gè)TCP切分好數(shù)據(jù)包杭棵，在通過IP協(xié)議，在進(jìn)行包裝了牛；主要作用是確保數(shù)據(jù)包到達(dá)目標(biāo)服務(wù)器
- 服務(wù)器接收到所有IP數(shù)據(jù)包颜屠，然后拆包成TCP數(shù)據(jù)包，然后根據(jù)TCP數(shù)據(jù)包拆包解析成http數(shù)據(jù)包鹰祸，然后發(fā)現(xiàn)客戶端GET請求甫窟，獲取 www.baidu.com 資源，然后將該url對應(yīng)的資源進(jìn)行封裝成數(shù)據(jù)包蛙婴，再通過TCP協(xié)議粗井，IP協(xié)議封裝然后到達(dá)客戶端
- 最后客戶端獲取到http請求返回?cái)?shù)據(jù)包解析成指定的文件，然后對這些文件進(jìn)行渲染樣式之后就變成請求的頁面了
http兩個(gè)重要特性
無狀態(tài)
無狀態(tài)指的是http每一個(gè)請求都是獨(dú)立的街图，沒有任何關(guān)聯(lián)浇衬，也是因?yàn)檫@個(gè)特性所以http協(xié)議推出了cookie的技術(shù)來進(jìn)行會話管理的實(shí)現(xiàn)
單向性
單向性是指的是，請求只能是客戶端主動發(fā)起請求餐济，然后服務(wù)器端進(jìn)行響應(yīng)耘擂，http請求無法從服務(wù)器端直接發(fā)起，客戶端進(jìn)行響應(yīng)絮姆，也是因?yàn)檫@個(gè)原因所以后來才有的WebSocket的技術(shù)來補(bǔ)充http協(xié)議的不足
http請求方式
| 請求方式 | 描述 |
|---|---|
| GET | 請求指定的頁面信息醉冤，并返回實(shí)體主體 |
| HEAD | 類似于get請求，只不過返回的響應(yīng)中沒有具體的內(nèi)容篙悯，用于獲取報(bào)頭 |
| POST | 向指定資源提交數(shù)據(jù)進(jìn)行處理請求（例如提交表單或者上傳文件）蚁阳。數(shù)據(jù)被包含在請求體中。POST請求可能會導(dǎo)致新的資源的建立和/或已有資源的修改 |
| PUT | 從客戶端向服務(wù)器傳送的數(shù)據(jù)取代指定的文檔的內(nèi)容 |
| DELETE | 請求服務(wù)器刪除指定的頁面 |
| CONNECT | HTTP/1.1協(xié)議中預(yù)留給能夠?qū)⑦B接改為管道方式的代理服務(wù)器 |
| OPTIONS | 允許客戶端查看服務(wù)器的性能 |
| TRACE | 回顯服務(wù)器收到的請求鸽照，主要用于測試或診斷 |
http常見請求頭標(biāo)簽
| 請求頭 | 描述 |
|---|---|
| Accept | 通知服務(wù)器螺捐，目前客戶端可以接受的數(shù)據(jù)類型 |
| Accept-Language | 客戶端，目前可以接受的字符集類型 |
| Accept-Encoding | 客戶端矮燎，可以接受的壓縮方式 |
| host | 用來區(qū)分同一IP下的定血，不同應(yīng)用 |
| Upgrade-Insecure-Requests | 指的是瀏覽器可以支持，http 相關(guān)的請求自動升級成 https |
| Connection | http1.1之后漏峰，這個(gè)標(biāo)簽的值通過是keep-alive糠悼，意思多個(gè)http請求，公用一個(gè)TCP連接通道 |
| Cache-Control | 緩存控制浅乔，max-age=0的時(shí)候，意思就是不緩存 |
| Cookie | 服務(wù)器提供用來記錄會話，或者存儲一下簡單數(shù)據(jù)的鍵值對 |
| User-Agent | 客戶端目前所處環(huán)境信息靖苇，比如系統(tǒng)信息席噩，瀏覽器信息等等之類 |
| Referer | 查看請求發(fā)起源 |
http常見響應(yīng)頭標(biāo)簽
| 響應(yīng)頭 | 描述 |
|---|---|
| Cache-Control | 控制緩存 |
| Connection | 和請求頭里是一樣的 |
| Content-Encoding | 響應(yīng)報(bào)文壓縮方式 |
| Content-Type | 響應(yīng)文件類型 |
| Date | 響應(yīng)報(bào)文創(chuàng)建時(shí)間 |
| Server | 服務(wù)器類型 |
| Transfer-Encoding: chunked | 分塊傳輸標(biāo)識 |
常見響應(yīng)碼
| 響應(yīng)碼 | 描述 |
|---|---|
| 2xx | 成功 |
| 3xx | 重定向 |
| 4xx | 客戶端錯誤 |
| 5xx | 服務(wù)器錯誤 |
有一個(gè)比較特殊的響應(yīng)碼304響應(yīng)碼，該狀態(tài)碼表示客戶端發(fā)送附帶條件的請求時(shí)贤壁，服務(wù)器端允許請求訪問資源悼枢，但未滿足條件的情況；附帶條件就比如說脾拆，GET請求的時(shí)候馒索，請求中包含了If-Match, If-Modified-Since, If-None-Match等等是If開頭的請求體的時(shí)候，然后服務(wù)器又不滿足條件的時(shí)候名船，就返回304
Cookie與會話管理
cookie指的是服務(wù)器發(fā)送給客戶端的一個(gè)鍵值對的數(shù)據(jù)绰上；cookie主要有以下幾個(gè)屬性，有一點(diǎn)必須說明一下渠驼，一旦cookie被服務(wù)器發(fā)送給客戶端蜈块，那么只能是客戶端進(jìn)行管理，服務(wù)器端是服務(wù)管理客戶端的cookie內(nèi)容的迷扇，唯一的辦法就是通過發(fā)送相同的cookie來進(jìn)行原來的cookie進(jìn)行替換百揭，來達(dá)到刪除的效果
- key-value，cookie主要內(nèi)容
- expires屬性蜓席，設(shè)置cookie有效期時(shí)間器一，如果不設(shè)置的話，那么默認(rèn)一般來說厨内，就是最大生命周期是關(guān)閉瀏覽器的時(shí)間
- path屬性祈秕，用來限制cookie發(fā)送的文件目錄
- domain屬性，通常來說隘庄，可以不用設(shè)置踢步，默認(rèn)就是當(dāng)前域名；但是如果要達(dá)到多域名共享會話的時(shí)候丑掺，那可能需要手動設(shè)置了获印，比如deal.isuwang.com和personal.isuwang.com需要共享會話的，那么cookie的domain就需要設(shè)置成 .isuwang.com
- secure屬性街州，用來限制cookie只在是https安全連接下才發(fā)送cookie兼丰，這樣做的好處，就是防止cookie劫持的情況出現(xiàn)
- HttpOnly屬性唆缴，用來限制客戶端惡意修改cookie的內(nèi)容鳍征，有這個(gè)屬性的cookie，就無法在js中修改面徽，只能由服務(wù)器重新進(jìn)行設(shè)置值艳丛；但是實(shí)際上這樣的cookie還是可以修改的匣掸，chrome的客戶端有一些cookie相關(guān)的插件也是可以修改這樣的cookie
會話管理指的是，記錄客戶端-服務(wù)器之間的通信的狀態(tài)氮双，但是由于http是一種沒有沒有連接狀態(tài)的一種通信協(xié)議碰酝，每一次http請求都是一個(gè)全新的請求，所以兩次http請求無法共享一個(gè)上下文來記錄會話戴差，但是大部分服務(wù)器都是通過cookie來進(jìn)行會話管理的送爸，比如說Tomcat是采用一個(gè)JSESSIONID的cookie來進(jìn)行會話控制的，每一個(gè)瀏覽器在訪問是Tomcat的時(shí)候暖释，Tomcat都會給客戶端提供一個(gè)JESSIONID的cookie袭厂，這個(gè)cookie每一個(gè)客戶端是不會重復(fù)的，那么服務(wù)器端球匕，可以根據(jù)JESSIONID來創(chuàng)建一塊單屬于特定客戶端的內(nèi)存區(qū)域纹磺，來存放客戶端-服務(wù)器之間會話內(nèi)容
http與https
由于http，明文傳輸谐丢，通信通道沒有加密爽航，等等因素，導(dǎo)致http是一個(gè)不安全的協(xié)議乾忱，于是就有了https
https = http + 加密通道（SSL）+ 不對稱加密/解密方式 + 證書
SSL加密通道
SSL：介于http協(xié)議和TCP協(xié)議之間一個(gè)協(xié)議讥珍，是一個(gè)安全的傳輸協(xié)議
不對稱加密/加密方式
在Https中不對稱加密的做法是，通過證書中的公鑰進(jìn)行加密窄瘟，私鑰只有服務(wù)器端才有持有衷佃，也就說只有服務(wù)器端才能解密客戶端的請求
證書
證書的主要內(nèi)容包括三部分：1. 服務(wù)器公鑰； 2. 服務(wù)器的相關(guān)信息（比如IP地址蹄葱，比如認(rèn)證信息等等）氏义； 3. 證書頒發(fā)機(jī)構(gòu)數(shù)字簽名
公鑰的作用：用來加密請求信息
服務(wù)器相關(guān)信息作用：用來驗(yàn)證服務(wù)器信息
數(shù)字簽名作用：用來驗(yàn)證證書的有效期
總的來說，證書的作用就是图云，用來建立SSL加密通道惯悠，驗(yàn)證服務(wù)器相關(guān)信息，加密客戶端的請求
https請求流程
https主要是http中http請求竣况，和建立TCP連接通道之間額外加上了SSL通道克婶；主要是多了一下幾個(gè)步驟
- 從服務(wù)器獲取上證書
- 通過證書上的數(shù)字簽名找到第三方認(rèn)證機(jī)構(gòu)校驗(yàn)證書的真實(shí)性
- 校驗(yàn)通過后，通過借助證書建立SSL連接通道丹泉，對需要發(fā)送的http請求進(jìn)行加密
Http2.0
作為http2.0的時(shí)代情萤，首先第一點(diǎn)需要說明，http2.0不兼容http1.x版本摹恨；改版之后的新特性有
- http2.0首部壓縮筋岛；比如說訪問 www.baidu.com 需要加載大量的資源，比如目標(biāo)頁面晒哄，頁面樣式睁宰，頁面js等等肪获，還有一些的圖片；在http2.0下這些資源的加載可以復(fù)用請求頭勋陪，從而達(dá)到請求頭壓縮的效果贪磺，減少頭部數(shù)據(jù)的傳輸
- 所有http2.0請求都在一個(gè)TCP鏈接上硫兰，這樣做的好處诅愚，減少服務(wù)器創(chuàng)建連接開銷；TCP鏈接使用效率提高
- http2.0請求優(yōu)先級設(shè)定劫映，可以讓客戶端首先加載重要的資源
- http2.0服務(wù)器主動推送违孝，由于是http1.x時(shí)代，所有的請求只能是由客戶端發(fā)起泳赋，然后服務(wù)器再進(jìn)行響應(yīng)雌桑，這樣導(dǎo)致在協(xié)議層面就限制了http1.x無法實(shí)現(xiàn)服務(wù)器主動推送數(shù)據(jù)的動作
- 等等新特性。祖今。校坑。
