MHLEVELFORONEANDONLY?
這篇主要是http協(xié)議的學習筆記，內容總結自極客時間陶輝。有內容不全的章節(jié)會在日后的維護中補齊，歡迎收藏????
1.ABNF(元語言)（擴充巴科斯-瑙爾范式）操作符
-
空白字符：用來分隔定義中的各個元素
- method SP request-target SP HTTP-version CRLF
-
選擇 / ：表示多個規(guī)則都是可供選擇的規(guī)則
- Start-line = request-line / status-line
-
值范圍 %c##-##：
- OCTAL = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7"與 OCTAL = %x30-37 等價
序列組合() : 將規(guī)則組合起來，視為單個元素
-
不定量重復 m*n:
*元素表示零個或更多元素: *（header-field CRLF）
1*元素表示一個或更多元素，2 * 4元素表示兩個至四個元素
-
可選序列[]:
- [message-body]
2.ABNF（擴充巴科斯-瑙爾范式）核心規(guī)則
拓展：詳細了解ABNF規(guī)則
三、OSI概念模型
應用層（應用層解決的是業(yè)務問題）
表示層（負責將網(wǎng)絡中的消息轉換成應用層可以讀取的消息）
會話層（這是完全概念化的一層，幫助理解session這個概念，負責建立連接，握手，會話，關閉。TCP層和表示層都有延伸的會話層）
傳輸層（解決進程與進程之間的通訊，比如說報文到了一個主機上，那么這個報文應該由哪一個進程來處理是由傳輸層來決定。這一層還有TCP協(xié)議，它保證了報文的可達性，流量的控制）
網(wǎng)絡層（他的作用是在廣域網(wǎng)中把報文從一個主機上發(fā)送到另一個主機上，廣域網(wǎng)就是我們所說的因特網(wǎng)）
數(shù)據(jù)鏈路層（它是在局域網(wǎng)中，使用mac地址鏈接到相應的交換機或者路由器就可以把報文轉到另一個主機上，它只可以工作在以太網(wǎng)這樣的局域網(wǎng)上）
-
物理層（可以理解成網(wǎng)線等等這樣的一些設備）
osi概念模型
-
OSI只是概念模型，實際上在因特網(wǎng)中的實現(xiàn)是叫做TCP/IP模型
了解7層模型和5層模型的區(qū)別以及他們的優(yōu)缺點
四、web架構的七大關鍵屬性
HTTP協(xié)議應當在以下屬性中取得可接受的均衡
-
性能：影響高可用的關鍵因素
-
網(wǎng)絡性能
Throughput吞吐量：小于等于帶寬
Overhead開銷：首次開銷，每次開銷
-
用戶感知到的性能
Latency 延遲：發(fā)起請求到接收到響應的時間
Completion 完成時間：完成一個應用動作所花費的時間
-
網(wǎng)絡效率
- 重用緩存，較少交互次數(shù)，數(shù)據(jù)傳輸距離更近，COD
-
可伸縮性：支持部署可以互相交互的大量組件
簡單性：易理解，易實現(xiàn)，易驗證
可見性：對兩個組件的交互進行監(jiān)控或者仲裁的能力，如緩存，分層設計等
可移植性：在不同環(huán)境下運行的能力
可靠性：出現(xiàn)部分故障時，對整體的影響程度
可修改性：對系統(tǒng)作出修改的難易程度，由可進化性，可定制性，可擴展性，可配置性，可重用性構成
五、五種分布式web架構風格（探討REST架構是怎樣從這五類架構風格的具體架構中推演出來的）（REST架構是HTTP協(xié)議設計所遵循的架構）
-
數(shù)據(jù)流風格 Data-flow（例如協(xié)議的分層）
管道與過濾器Pipe And Filter , PF
統(tǒng)一接口的管道與過濾器 , UPF
-
復制風格 Replication
-
復制倉庫 Replicated Repository , RR（例如：MySQL的冷熱備份）
- 多個進程提供相同的服務，通過反向代理對外提供集中服務
-
緩存 $
- RR的變體，通過復制請求的結果，為后續(xù)請求復用
-
-
分層風格Hierarchical
客戶端服務器 , CS
分層系統(tǒng) , LS
分層客戶端服務器 , LCS
無狀態(tài)，客戶端服務器 , CSS
緩存，無狀態(tài)，客戶端服務器 , C$SS
分層，緩存，無狀態(tài)，客戶端服務器 LC$SS
等等...
-
移動代碼風格 Mobile Code
虛擬機
遠程求值
按需代碼
移動代理
點對點風格 Peer-to-Peer
六、http中的請求行
格式
-
常見方法（RFC7231）
GET：主要的獲取信息的方法，大量的性能優(yōu)化都是正對該方法，冪等方法（調用一次和調用多次獲得的結果是完全一致的，冪等方法對于分布式系統(tǒng)中的事務設計是非常有意義的）
HEAD：類似GET方法，但服務器不發(fā)送BODY，用以獲取HEAD元數(shù)據(jù)，冪等方法
POST：常用語提交HTML FORM表單，新增資源等
PUT：更新資源，帶條件時是冪等方法
DELETE：刪除資源，冪等方法
CONNECT：建立tunnel隧道
OPTIONS：顯示服務器對訪問資源支持的方法，冪等方法
TRACE：回顯服務器收到的請求，用于定位問題，有安全風險
-
用于文檔管理的WEBDAV方法
PROPFIND：從web資源中檢索以XML格式存儲的屬性，它也被重載，以允許一個檢索遠程系統(tǒng)的集合構建（也叫目錄層次結構）
PROPPATCH：在單個原子性動作中更改和刪除資源的多個屬性
MKCOL：創(chuàng)建集合和目錄
COPY：將資源從一個URI復制到另一個URI
MOVE：將資源從一個URI移動到另一個URI
LOCK：鎖定一個資源，WebDAV支持共享鎖和互斥鎖
UNLOCK：解除資源的鎖定
七、http響應碼
-
響應碼分類：1XX
請求已接收到，需要進一步處理才能完成，HTTP1.0不支持
-
100 Continue：上傳大文件前使用
- 由客戶端發(fā)起請求中攜帶Expect: 100-Continue 頭部觸發(fā)
-
101 Switch Protocols: 協(xié)議升級使用
- 有客戶端發(fā)起請求中攜帶Upgrade：頭部觸發(fā)，如升級websocket或者http/2.0
102 Processing: WebDAV 請求中可能包含許多設計文件操作的子請求，需要很長時間才能完成請求，該代碼表示服務器已經(jīng)收到并正在處理請求，但無響應可用。這樣可以防止客戶端超時，并假設請求丟失。
- 響應碼分類：2XX
成功處理請求
200 OK：成功返回響應
201 Created：有新資源在服務器端被成功創(chuàng)建
202 Aceept：服務器接受并開始處理請求，但請求未處理完成這樣一個模糊的概念是有意如此設計，可以覆蓋更多的場景，例如異步，需要長時間處理的任務
203 Non-Authoritative Information：當代服務器修改了origin server的原始響應包體時（例如更換了HTML中元素的值），代理服務器可以通過修改200為203的方式告知客戶端這一事實，方便客戶端為這一行為作出相應的處理，203響應可以被緩存
204 No Content：成功執(zhí)行了請求且不攜帶響應包體，同時指明客戶端不需要更新當前的頁面的視圖
205 Reset Content：成功執(zhí)行了請求且不攜帶響應的包體，同志指明了客戶端需要更新當前頁面的視圖
206 Partial Content：使用range協(xié)議時返回部分響應內容時的響應碼
207 Multi-Status：RFC4918，在WEBDAV協(xié)議中以XML返回多個資源的狀態(tài)
208 Already Reported： RFC5842，為避免相同集合下資源在207響應碼下重復上報，使用208可以使用父集合的響應碼
- 響應碼分類：3XX
重定向使用Location指向的資源或者緩存中的資源。在RFC2068中規(guī)定客戶端重定向的次數(shù)不應該超過5次，以防止出現(xiàn)死循環(huán)
300 Multiple Choices： 資源有多種表述，通過300返回給客戶端后其自行選擇訪問哪一種表述。由于缺乏明確的細節(jié)，300很少使用
301 Moved Permanently： 資源永久性的重定向到另一個URI中
302 Found： 資源臨時重定向到另一個URI中
303 See Other： 重定向到其他資源，常用于POST/PUT等方法的響應中
304 Not Modified： 當客戶端擁有可能過期的 緩存是，會攜帶緩存的標識etag，時間等信息詢問服務器緩存是否仍可復用，而304是告訴客戶端可以復用緩存
307 Temporary Redirect： 類似302，明確重定向請求方法，必須與原請求方法相同，不得改變
308 Permanent Redirect：類似301，但明確重定向后請求方法必須與原請求方法相同，不得改變
- 響應碼分類4XX
客戶端出現(xiàn)錯誤
400 Bad Request：服務器認為客戶端出現(xiàn)了錯誤，但不能明確判斷為以下哪種錯誤時使用次錯誤碼，例如HTTP請求格式錯誤
401 Unauthorized：用戶認證信息缺失或者不正確，導致服務器無法正確處理請求
407 Proxy Authentication Required：對需要經(jīng)由代理的請求，認證信息未通過代理服務器的驗證
403 Forbidden： 服務器理解請求的含義，但是沒有權限執(zhí)行次請求
404 Not found： 服務器沒有找到對應的資源
410 Gone：服務器沒有找到對應的資源，且明確的知道該位置永久找不到該資源
405 Method Not Allowed： 服務器不支持請求行中method方法
406 Not Acceptable： 對客戶端指定的資源表述不存在（例如語言或者編碼有要求），服務器返回表述列表供客戶端選擇
408 Request Timeout： 服務器接受請求超時
409 Conflict： 資源沖突，例如上傳文件時目標位置已經(jīng)存在版本更新的資源
411 Length Required： 如果請求含有包體且未攜帶Content-Length頭部，且不屬于chunk類請求時，返回411
412 Precondition Failed：復用緩存時傳遞的if-Unmodified-Since或if-None-Metch頭部不滿足
413 Payload Too Large/Request Entity Too Large：請求的包體超出服務器能處理的最大長度
414 URI Too Long： 請求的URI超出服務器能接收的最大長度
415 Unsupported Media Type： 上傳的文件類型不被服務器支持
416 Range Not Satisfiable：無法提供Range請求中指定的那段包體
417 Expectation Failed：對于Expect請求頭部期待的情況無法滿足時的響應碼
421 Misdirected Requst： 服務器認為這個請求不該發(fā)給他，因為他沒有能力處理
426 Upgrade Required：服務器拒絕基于當前HTTP協(xié)議提供服務，通過Upgrade頭部告知客戶端升級協(xié)議才能繼續(xù)處理
428 Percondition Required：用戶請求中缺失條件類頭部，例如if-Match
429 Too Many Request： 客戶端發(fā)送請求速率過快
431 Requesu Header Fields Too Large： 請求的HEADER頭部大小超過限制
451 Unavailable For Legal Reasons：由于法律原因資源不可訪問
- 響應碼分類5XX
服務器端出現(xiàn)錯誤
500 Internal Server Error：服務器內部錯誤，且不屬于以下錯誤的類型
501 Not Imolemented： 服務器不支持實現(xiàn)請求所需要的功能
502 Bad Gateway： 代理服務器無法獲取到合法響應
503 Service Unavailable： 服務器資源尚未準備好處理當前請求
504 Gateway Timeout： 代理服務器無法及時的從上游獲得響應
505 HTTP Version Not Support：請求使用的HTTP協(xié)議版本不支持
507 Insufficient Storage： 服務器沒有足夠的空間處理請求
508 Loop Detected： 訪問資源時檢測到循環(huán)
511 Network Authentication Required： 代理服務器發(fā)現(xiàn)客戶端需要進行身份驗證才能獲得網(wǎng)絡訪問權限
-
八、HTTP連接的常見流程
在瀏覽器中輸入域名之后會發(fā)生什么
瀏覽器解析出主機名
瀏覽器查詢這個主機名的IP地址（dns）
瀏覽器獲取到端口號（80）
瀏覽器發(fā)起對在步驟2中獲得的ip地址中對應的在步驟3中獲得的對應端口號的連接
瀏覽器想服務器發(fā)送一條HTTP GET報文
瀏覽器從服務器中讀取HTTP響應報文
瀏覽器關閉連接
九、短連接與長連接
-
Connection頭部
Keep-Alive：長鏈接（HTTP/1.1默認支持長鏈接）
Close： 端鏈接
十、請求與響應的上下文
請求和響應中常見的上下文頭部
-
內容協(xié)商：
- 在HTTP協(xié)議中，內容協(xié)商是這樣一種機制，通過為同一URI指向的資源提供不同的展現(xiàn)形式，可以使用hu y
-
內容協(xié)商與資源表述中常見的協(xié)商要素
質量因子：內容的質量，可接受類型的優(yōu)先級
媒體資源的MIME類型及質量因子
十一、HTTP包體：承載的消息內容
-
兩種傳輸HTTP包體的方式
發(fā)送HTTP消息時已能夠確定包體的全部長度
優(yōu)點：接收端處理更簡單
-
發(fā)送HTTP消息時不能確定包體的全部長度
-
使用Trancefer-Encoding頭部指明使用Chunk傳輸方式
- 含有Trancefer-Encoding頭部后 Content-Length頭部應被忽略
-
-
優(yōu)點
基于長連接持續(xù)推送動態(tài)內容
壓縮體積較大的包體時，不必完全壓縮完（計算出頭部）再發(fā)送，可以邊發(fā)送邊壓縮
傳遞必須在包體傳輸完才能計算出的Trailer頭部
十二、斷點續(xù)傳和多線程下載是如何做到的
- Range規(guī)范
十三、Cookie的格式和約束
-
Cookie是保存在客戶端，由服務器生成，瀏覽器維護，表示應用狀態(tài)的HTTP頭部
存放在內存或者磁盤中
服務器生成Cookie在響應中通過Set-Cookie頭部告知客戶端（允許多個Set-Cookie頭部傳遞多個值）
客戶端得到Cookie后，后續(xù)請求都會自動將Cookie頭部攜帶至請求中
-
Cookie與Set-Cookie頭部的定義
Cookie頭部可以存放多個name/value名值對
Set-Cookie頭部一次只能傳遞一個name/value名值對，響應中可以含多個頭部
-
Cookie使用的限制
-
RFC規(guī)范對瀏覽器使用Cookie的要求
每條Cookie的長度（包括name，value以及描述的屬性等總長度）至少要達到4kb
每個域名下至少支持50個Cookie
至少要支持3000個Cookie
代理服務器傳遞Cookie時會有限制
-
十四、瀏覽器的通源策略（這是一種阻止跨域訪問）（另外可以了解ajax跨域請求，及其二者的區(qū)別）
-
為什么使用瀏覽器的通源策略？
- 同一個瀏覽器發(fā)出的請求未必都是用戶自愿發(fā)出的請求
-
沒有同源策略下的Cookie只能保證用戶請求來自統(tǒng)一瀏覽器，不能確保是用戶自愿發(fā)出的
- 站點b的腳本可以隨意修改站點a的DOM結構
同源策略需要在可用性和安全性上尋找一個平衡點
跨站請求偽造攻擊
十五、通過CORS實現(xiàn)跨域訪問
-
瀏覽器通源策略下的跨域訪問解決方案（這種方案能夠保證安全性）
-
如果站點A允許站點B的腳本訪問其資源，必須在HTTP響應中顯示的告知瀏覽器：站點B是允許的
訪問站點A的請求，瀏覽器應告知該請求來自站點B
站點A的響應中，應明確哪些跨域請求是被允許的
-
策略1：何為簡單請求
策略2：簡單請求以外的其他請求
-
簡單請求的跨域訪問
請求中攜帶Origin頭部告知來自那個域
響應中攜帶Access-Control-Allow-Origin頭部表示允許哪些域
瀏覽器放行
-
復雜請求的跨域訪問
-
預檢請求
-
預檢請求頭部
Access-Control-Request-Method
Access-Control-Request-Headers
預檢請求響應
-
-
十六、條件請求的作用
強驗證器與弱驗證器的概念
更新丟失的問題：樂觀鎖
更新丟失的問題：樂觀鎖解決首次上傳
十七、緩存的工作原理
-
HTTP緩存：為當前請求復用前請求的響應
目標：減少時延；降低帶寬消耗
可選而又必要
過期的共享緩存--代理服務器
十八、緩存新鮮度的四種計算方式
