學習HTTP相關知識筆記

HTTP相關知識

1.HTTP的概念

超文本傳輸協議（ HTTP）是用於傳輸諸如 HTML的超媒體文檔的應用層協議。它被設計用於 Web瀏覽器和 Web服務器之間的通訊，但它也能夠用於其餘目的。 HTTP遵循經典的客戶端-服務端模型，客戶端打開一個鏈接以發出請求，而後等待它收到服務器端響應。 HTTP是無狀態協議，意味着服務器不會在兩個請求之間保留任何數據（狀態）。雖然一般基於 TCP / IP層，但能夠在任何可靠的傳輸層上使用

2.URL和URI

• URI：uniform resource identifier 統一資源標識符，一種資源的標識，它是一種抽象的資源標識，便可以是相對的，也能夠是絕對的。
• URL：uniform resource location 統一資源定位符，一用來標識抽象或物理資源的一個緊湊字符串。

3.HTTP報文

HTTP報文由報文首部、空行、報文主體構成：

其中的空行用於區分報文首部和報文主體內容，是由一個回車符和一個換行符組成的。
不管是請求報文仍是響應報文都須要有報文首部，而報文主體有些請求報文是沒有的。而請求報文的通常格式以下：

而響應報文的格式是這樣的：

其中最多見的屬性以下：

1. URL, 即http訪問的地址
2. request method, 報文的請求方式
3. status code, 狀態碼以及狀態短語
4. Accept Encoding, 內容編碼
5. Connection, 鏈接方式
6. Cookie, 添加的cookie內容
7. Host, 目標主機
8. User-Agent, 客戶端瀏覽器的相關信息
9. Set-Cookie, 指定想要在Cookie中保存的內容

請求方式(request method)——常見GET和POST

GET方法能夠用來請求訪問已經被 URL識別的資源。指定的資源通過服務端解析後返回響應的內容。簡單來講，就是請求的資源是文本的話，那麼就保持原樣返回。

POST方法能夠用來傳輸實體的主體。

二者區別：

1.使用目標不一樣

POST與 GET都用於獲取信息，可是 GET方式僅僅是查詢，並不對服務器上的內容產生任何做用結果；每次 GET的內容都是相同的。 POST則經常使用於發送必定的內容進行某些修改操做。

2.大小不一樣

因爲不一樣的瀏覽器對 URL的長度大小有必定的字符限制，所以因爲 GET方式放在 URL的首部中，具體的大小要依瀏覽器而定。 POST方式則是把內容放在報文內容中，所以只要報文的內容沒有限制，它的大小就沒有限制。

3.安全性不一樣

上面也說了 GET是直接添加到 URL後面的，直接就能夠在 URL中看到內容。而 POST是放在報文內部的，用戶沒法直接看到。

總的來講，GET用於獲取某個內容，POST用於提交某種數據請求，從使用場景來看，通常用戶註冊的內容是私密的，應該使用POST方式來保持私密，而當須要查詢某個內容時，須要快速響應，則使用GET。

常見status code狀態碼

200 一般的成功 OK
GET：請求的對應資源會做爲響應返回。響應將包含描述或操做的結果。
POST：返回處理對應請求的結果

204 成功處理請求，沒有返回任何內容 No Content
表示服務器接收到的請求已經處理完畢，可是服務器不須要返回響應。好比，客戶端是瀏覽器的話，那麼瀏覽器顯示的頁面不會發生更新。

206 Partial Content
成功處理了部分GET請求

301 Moved Permanently
請求的網頁已永久移動到新位置，永久性重定向

302 Found
網站臨時性重定向，暫時不能訪問（備案、被查）

303 See Other
該狀態碼錶示因爲請求對應的資源存在另外一個URI，並指定必須使用GET方法定向獲取請求的資源。和302不一樣的是，302是不會改變上次的請求方法

304 Not Modified
訪問不了，並返回和上次同樣的話,表示資源未被修改過，仍是和上次訪問時同樣。

307 Temporary Redirect
臨時重定向，和302、303相似，不一樣的是，不會指定客戶端要用什麼樣的方法請求，

400 Bad Request
表示客戶端中存在語法錯誤，致使服務器沒法理解該請求。客戶端須要修改請求的內容後再次發送請求。

401 Unauthorized
即用戶沒有必要的憑據。該狀態碼錶示當前請求須要用戶驗證。

403 Forbidden
服務器已經理解請求，可是拒絕執行它。

404 Not Found
服務器找不到請求的網頁。

500 Internal Server Error
服務器遇到錯誤，沒法完成請求。

503 Service Unavailable
因爲臨時的服務器維護或者過載，服務器當前沒法處理請求。這個情況是暫時的.

內容編碼 Accept Encoding

因爲有些報文的內容會過大，爲了減小傳輸時間，HTTP會採起一些壓縮的措施，例如上面的報文信息中，Accept-Encoding就定義了內容編碼的格式gzip。

總的來講內容編碼的格式有如下幾種：
gzip:GNU壓縮格式
compress:UNIX系統的標準壓縮格式
deflate:是一種同時使用了LZ77和哈夫曼編碼的無損失壓縮格式
identity:不進行壓縮
持久化connection

正常發送HTTP時，咱們須要創建TCP的鏈接，而後再發送報文：

若是每次都要發送HTTP報文都須要經歷上面的拿過過程，無疑將會耗費不少時間在創建和斷開鏈接的過程當中，所以HTTP使用了connection屬性，用於指定鏈接的方式，噹噹設置成keep-alive時，就會創建一條持久化的鏈接。這樣就不須要每次都創建鏈接在中斷鏈接：

（HTTP1.1中connection默認開啓keep-alive）
報文首部總結

4.HTTP方法

HTTP支持幾種不一樣的請求命令，這些命令被稱爲 HTTP 方法（ HTTP method）。每 條 HTTP 請求報文都包含一個方法。這個方法會告訴服務器要執行什麼動做（獲取 一個 Web 頁面、運行一個網關程序、刪除一個文件等）。

下表是一些常見的HTTP方法：

PUT傳輸文件

PUT方法用於傳輸文件，就像 FTP協議的上傳同樣，要求在請求報文的主題中包含文件內容，而後保存到請求 URI指定的位置。因爲 PUT方法不帶驗證機制，任何人均可以任何人均可以上傳文件，存在安全性問題，所以通常的 web網站不適用該方法。

DELETE刪除文件

DELETE方法用來刪除文件，是與 put相反的方法， DELETE方法按照請求 url刪除指定的資源。其本質和 PUT方法同樣不帶驗證機制，因此建議少用 DELETE方法。

HEAD獲取報文首部

HEAD和 GET方法同樣，只是不返回報文主體部分，一般用於確認 url的有效性及資源更新的日期時間等。

5.HTTPS的概念

HTTPS（全稱： Hyper Text Transfer Protocol over Secure Socket Layer），是以安全爲目標的 HTTP通道，簡單來講就是是 HTTP的安全版本，即在 HTTP下加入 SSL層， HTTPS的安全基石是 SSL，所以加密的詳細內容就須要 SSL。

因爲HTTP有如下幾個缺點：

傳輸的時候使用明文，這顯然會被不法者截取幹一些見不得人的勾當。
沒有認證機制，這樣咱們就能夠僞造一些 HTTP訪問，這顯然會形成一些困擾。好比 Jmeter就是典型的例子，僞造一大堆的 HTTP URL而後壓力測試，這也就是 DOS攻擊的一種。
沒法驗證報文的完整性，好比一個 HTTP的報文已經被不法者截取而且篡改，而服務器端卻沒法驗證。

HTTP與HTTPS的區別

正是因爲以上這些缺點，HTTPS做出瞭如下一些改變：

• HTTP 是明文傳輸，HTTPS 經過 SSL\TLS 進行了加密；
• HTTP 的端口號是 80，HTTPS 是 443；
• HTTPS 須要到 CA 申請證書，通常免費證書不多，須要交費；
• HTTP 的鏈接很簡單，是無狀態的。而 HTTPS 協議則是由 SSL+HTTP； 協議構建的可進行加密傳輸、身份認證的網絡協議，比 HTTP 協議安全;

HTTPS的缺點：

通訊的速度變慢，因爲須要加密，一個握手就多了好幾個往返；
對用戶的機器負載的增長。

補充：HTTP協議與TCP協議

TCP協議對應於傳輸層，而 HTTP協議對應於應用層，從本質上來講，兩者沒有可比性。 Http協議是創建在 TCP協議基礎之上的，當瀏覽器須要從服務器獲取網頁數據的時候，會發出一次 Http請求。 Http會經過 TCP創建起一個到服務器的鏈接通道，當本次請求須要的數據完畢後， Http會當即將 TCP鏈接斷開，這個過程是很短的。因此 Http鏈接是一種短鏈接，是一種無狀態的鏈接。所謂的無狀態，是指瀏覽器每次向服務器發起請求的時候，不是經過一個鏈接，而是每次都創建一個新的鏈接。若是是一個鏈接的話，服務器進程中就能保持住這個鏈接而且在內存中記住一些信息狀態。而每次請求結束後，鏈接就關閉，相關的內容就釋放了，因此記不住任何狀態，成爲無狀態鏈接。

6.TCP與UDP的區別

1. TCP面向鏈接(如撥打電話要先撥號創建鏈接)；UDP是無鏈接的，即發送數據以前不須要創建鏈接;
2. TCP提供可靠的服務。即經過TCP鏈接傳送的數據，無差錯，不重複，且按序到達；UDP盡最大努力交付，即不保證可靠交付;
3. TCP面向字節流，其實是把TCP數據當作一連串無結構的字節流；UDP是面向報文的，UDP沒有擁塞控制，所以網絡上出現擁塞不會使源主機的發送效率下降（對實時應用頗有用，如IP電話，實時視頻會議等）;
4. 每一條TCP鏈接只能是點到點；UDP支持一對一，一對多，多對一，多對多的交互通訊;
5. TCP的首部開銷２０字節；UDP的首部開銷小，只有８個字節;
6. TCP的邏輯通訊信道是全雙工的可靠信道；UDP則是不可靠信道;

7.流媒體協議：

RTP、RTCP、RTSP、MMS、HLS、HTTP progressive streaming
當前在internet上傳送音頻和視頻等信息主要有兩種方式:
下載，完整下載一個視頻，再去播放
流式傳輸，如優酷、愛奇藝等視頻網址

做用： RTP位於傳輸層（一般是 UDP）之上，應用程序之下，實時語音、視頻數據通過模數轉換和壓縮編碼處理後，先送給 RTP封裝成爲 RTP數據單元， RTP數據單元被封裝爲 UDP數據報，而後再向下遞交給 IP封裝爲 IP數據包。這麼說 RTP是沒有保證傳輸成功的，要保證成功，就要用到 RTCP， RTCP消息含有已發送數據的丟包統計和網絡擁塞等信息，服務器能夠利用這些信息動態的改變傳輸速率，甚至改變淨荷的類型。 RTCP消息也被封裝爲 UDP數據報進行傳輸。

部分參考：
https://juejin.im/post/5afad7...