文章目錄
http
HTTP（HyperText Transfer Protocol）是超文本傳輸協議，其定義了客戶端與服務器端之間文本傳輸的規範。
HTTP默認使用80端口
HTTPS的默認端口爲443
第一節、請求方法
| 方法 | 描述 |
|---|---|
| GET | 向特定的資源發出請求。GET方法不應當被用於產生“副作用”的操作中。大小1024字節 |
| POST | 向指定資源提交數據進行處理請求。（例如提交表單或者上傳文件）POST 請求可能會導致新的資源的建立和/或已有資源的修改。 |
| HEAD | HEAD和GET本質是一樣的，區別在於HEAD不含有呈現數據，而僅僅是HTTP頭信息。欲判斷某個資源是否存在 |
| PUT | 將client的資源放在請求URI上。對於服務器到底是創建還是更新，由服務器返回的HTTP Code來區別。從客戶端向服務器傳送的數據取代指定的文檔的內容。PUT通常指定了資源的存放位置，而POST則沒有，POST的數據存放位置由服務器自己決定 |
| DELETE | 請求服務器刪除指定的頁面。 |
| CONNECT | HTTP/1.1 協議中預留給能夠將連接改爲管道方式的代理服務器。 |
| OPTIONS | 允許客戶端查看服務器的性能。 |
| TRACE | 回顯服務器收到的請求，主要用於測試或診斷。 |
| PATCH | 是對 PUT 方法的補充，用來對已知資源進行局部更新 |
PUT
這個方法比較少見。HTML表單也不支持這個。本質上來講， PUT和POST極爲相似，都是向服務器發送數據，但它們之間有一個重要區別，PUT通常指定了資源的存放位置，而POST則沒有，POST的數據存放位置由服務器自己決定。
舉個例子：如一個用於提交博文的URL，/addBlog。如果用PUT，則提交的URL會是像這樣的”/addBlog/abc123”，其中abc123就是這個博文的地址。而如果用POST，則這個地址會在提交後由服務器告知客戶端。目前大部分博客都是這樣的。顯然，PUT和POST用途是不一樣的。具體用哪個還取決於當前的業務場景。
OPTIONS
請求旨在發送一種“探測”請求以確定針對某個目標地址的請求必須具有怎樣的約束（比如應該採用怎樣的HTTP方法以及自定義的請求報頭），然後根據其約束髮送真正的請求。比如針對 “跨域資源” 的預檢（Preflight）請求採用的HTTP方法就是OPTIONS。
該請求方法的響應不能緩存。
1、獲取服務器支持的HTTP請求方法；也是黑客經常使用的方法。
2、用來檢查服務器的性能。例如：AJAX進行跨域請求時的預檢，需要向另外一個域名的資源發送一個HTTP OPTIONS請求頭，用以判斷實際發送的請求是否安全。
CONNECT
http代理，SSL連接
HTTP CONNECT代理服務器是一種能夠允許用戶建立TCP連接到任何端口的代理服務器，這意味着這種代理不僅可用於HTTP，還包括FTP、IRC、RM流服務等，甚至掃描、攻擊。
TRACE
TRACE方法是HTTP（超文本傳輸）協議定義的一種協議調試方法，該方法使得服務器原樣返回任何客戶端請求的內容。
啓用TRACE方法存在如下風險：
1、惡意攻擊者可以通過TRACE方法返回的信息瞭解到網站前端的某些信息，如緩存服務器等，從而爲進一步的攻擊提供便利。
2、惡意攻擊者可以通過TRACE方法進行XSS攻擊。
3、即使網站對關鍵頁面啓用了HttpOnly頭標記和禁止腳本讀取cookie信息，但是通過TRACE 方法惡意攻擊者還是可以繞過這個限制讀取到cookie信息。
第二節、 狀態碼
| 狀態碼 | 描述 |
|---|---|
| 101 | 服務器已經理解了客戶端的請求，並將通過Upgrade消息頭通知客戶端採用不同的協議來完成這個請求。 |
| 204 | 該響應沒有響應內容,只有響應頭,響應頭也可能是有用的. |
| 206 | 當客戶端通過使用range頭字段進行文件分段下載時使用該狀態碼 |
| 301 | 永久移動 |
| 302 | 臨時移動 |
| 303 | 查看其它地址。與301類似。使用GET和POST請求查看 |
| 304 | 未修改。所請求的資源未修改，服務器返回此狀態碼時，不會返回任何資源。 |
| 305 | 使用代理。所請求的資源必須通過代理訪問 |
| 307 | 臨時重定向。與302類似。使用GET請求重定向 |
| 400 | 客戶端請求的語法錯誤，服務器無法理解 |
| 401 | 請求要求用戶的身份認證 |
| 403 | 服務器理解請求客戶端的請求，但是拒絕執行此請求 |
| 404 | 服務器無法根據客戶端的請求找到資源 |
| 405 | 客戶端請求中的方法被禁止 |
| 500 | 服務器內部錯誤，無法完成請求 |
| 502 | 作爲網關或者代理工作的服務器嘗試執行請求時，從遠程服務器接收到了一個無效的響應 |
第三節、 原理TCP
工作過程
- 地址解析
- 封裝HTTP請求數據包
- 封裝成TCP包，建立TCP連接（TCP的三次握手
- 客戶機發送請求命令
- 服務器響應
- 服務器關閉TCP連接
tcp
TCP三次握手/建立連接
TCP四次握手/終止連接
也不知道有什麼用
第四節、 http & http2
[外鏈圖片轉存中…(img-ngk1L8fk-1576045270242)]
性能
影響一個 HTTP 網絡請求的因素主要有兩個：帶寬和延遲
- 帶寬已經有極大的改善
- 延遲（瀏覽器最大連接數限制、DNS 查詢、建立連接三次握手慢啓動）
心路歷程
緩存處理
HTTP1.0：If-Modified-Since,Expires來做爲緩存判斷的標準
HTTP1.1：Entity tag、If-Unmodified-Since、If-Match、 If-None-Match
HTTP1.1特性：
- 引入了range頭域
- 新增了24個錯誤狀態響應碼
- Host頭域
- 長連接，在HTTP1.1中默認開啓Connection： keep-alive
range多線程下載工具
當用戶在聽一首歌的時候，如果聽到一半（網絡下載了一半），網絡斷掉了，用戶需要繼續聽的時候，文件服務器不支持斷點的話，則用戶需要重新下載這個文件。而Range支持的話，客戶端應該記錄了之前已經讀取的文件範圍，網絡恢復之後，則向服務器發送讀取剩餘Range的請求，服務端只需要發送客戶端請求的那部分內容，而不用整個文件發送回客戶端，以此節省網絡帶寬。
Server通過請求頭中的Range: bytes=0-xxx來判斷是否是做Range請求，如果這個值存在而且有效，則只發回請求的那部分文件內容，響應的狀態碼變成206，表示Partial Content，並設置Content-Range。如果無效，則返回416狀態碼，表明Request Range Not
HTTP2特點
- http1.*基於文本，http2.0基於二進制格式
- 多路複用，即連接共享。一個request對應一個id，這樣一個連接上可以有多個request，每個連接的request可以隨機的混雜在一起，接收方可以根據request的 id將request再歸屬到各自不同的服務端請求裏面。
- header壓縮。對前面提到過HTTP1.x的header帶有大量信息，而且每次都要重複發送，HTTP2.0使用encoder來減少需要傳輸的header大小，通訊雙方各自cache一份header fields表，既避免了重複header的傳輸，又減小了需要傳輸的大小。
- 服務端推送
HTTP2 HPACK 頭部壓縮
我暈再看吧HTTP2 HPACK 頭部壓縮
HTTP2 與http1.1 keep-alive
必須等到服務端響應了前一次請求，才能發起第二次請求 -> 阻塞。 按順序發送請求，按順序接收請求，這樣接收端纔不會亂掉。
而 http2 的多路複用可以同時發送多個請求，不一定要按照順序，也不用等上一個請求響應。這些請求都有唯一標識，所以可以無序。
[外鏈圖片轉存中…(img-Pxmve8Ed-1576045270243)]
第五節、 http && https
HTTP和HTTPS協議
HTTPS理論基礎
HTTPS加密（握手）過程
HTTPS協議 = HTTP協議 + SSL/TLS協議，在HTTPS數據傳輸的過程中，需要用SSL/TLS對數據進行加密和解密，需要用HTTP對加密後的數據進行傳輸，由此可以看出HTTPS是由HTTP和SSL/TLS一起合作完成的。
HTTPS爲了兼顧安全與效率，同時使用了對稱加密和非對稱加密。數據是被對稱加密傳輸的，對稱加密過程需要客戶端的一個密鑰，爲了確保能把該密鑰安全傳輸到服務器端，採用非對稱加密對該密鑰進行加密傳輸，總的來說，對數據進行對稱加密，對稱加密所要使用的密鑰通過非對稱加密傳輸。
非對稱加密：RSA(質數)、ECC(橢圓曲線)
對稱加密：AES,DES,3DES
[外鏈圖片轉存中…(img-sUotFJUU-1576045270243)]
HTTP特點:
- 無狀態：協議對客戶端沒有狀態存儲，對事物處理沒有“記憶”能力，比如訪問一個網站需要反覆進行登錄操作
- 無連接：HTTP/1.1之前，由於無狀態特點，每次請求需要通過TCP三次握手四次揮手，和服務器重新建立連接。比如某個客戶機在短時間多次請求同一個資源，服務器並不能區別是否已經響應過用戶的請求，所以每次需要重新響應請求，需要耗費不必要的時間和流量。
- 基於請求和響應：基本的特性，由客戶端發起請求，服務端響應
- 簡單快速、靈活
- 通信使用明文、請求和響應不會對通信方進行確認、無法保護數據的完整性
HTTPS特點:
- 內容加密：採用混合加密技術，中間者無法直接查看明文內容
- 驗證身份：通過證書認證客戶端訪問的是自己的服務器
- 保護數據完整性：防止傳輸的內容被中間人冒充或者篡改
第六節、 http && websocket
長輪詢、短輪詢
WebSocket是HTML5新增的協議，它的目的是在瀏覽器和服務器之間建立一個不受限的雙向通信的通道，比如說，服務器可以在任意時刻發送消息給瀏覽器。
WebSocket並不是全新的協議，而是利用了HTTP協議來建立連接。
WebSocket
請求
首先，WebSocket連接必須由瀏覽器發起，因爲請求協議是一個標準的HTTP請求
GET ws://localhost:3000/ws/chat HTTP/1.1
Host: localhost
Upgrade: websocket
Connection: Upgrade
Origin: http://localhost:3000
Sec-WebSocket-Key: client-random-string
Sec-WebSocket-Version: 13
該請求和普通的HTTP請求有幾點不同：
- 以ws://開頭的地址
- 請求頭Upgrade: websocket和Connection: Upgrade表示這個連接將要被轉換爲WebSocket連接。服務端返回狀態碼101
- Sec-WebSocket-Key是用於標識這個連接，並非用於加密數據；
響應:
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: server-random-string
爲什麼WebSocket連接可以實現全雙工通信而HTTP連接不行呢？實際上HTTP協議是建立在TCP協議之上的，TCP協議本身就實現了全雙工通信，但是HTTP協議的請求－應答機制限制了全雙工通信。WebSocket連接建立以後，其實只是簡單規定了一下：接下來，咱們通信就不使用HTTP協議了，直接互相發數據吧。