HTTP基礎小結

一 前言

最近開始學習AJAX相關知識，因此正好仔細複習一下HTTP的相關基礎知識。

二 前置知識和規則

1 IP和MAC:

S1 網絡 分紅不少個子網, 就像一個國家分紅不少個省份
S2 寄送物品的時候，只要按省份分類 下發到各省級物流中心便可 (由子網內部解決)
S3 IP地址 是和地域相關的:
    同一個子網上的設備，分配的 IP地址前綴 都是同樣的(相似於各省市的郵政編碼)
    路由器只需記住每一個子網的位置便可，大大減小了路由器所須要的內存
S4 MAC地址 是和設備相關的:
    咱們須要用 MAC地址來區分不一樣的設備;

總之

MAC地址: 相似於 一我的的體貌特徵;
IP地址:  相似於 電話號碼/郵編地址(聯繫地點)

2 網關:

聯繫外網的設備，
具備其餘網關地址的 路由表
具備內網內 IP和MAC對應的 ARP表

3 DHCP服務器: 隨機獲得IP

4 路由: 網關之間的查詢和鏈接的 一系列過程

5 DNS: 域名和IP的對照表

6 客戶端: 能發送（資源）請求 + 接受響應資源的設備，均可以稱爲是客戶端

7 協議: 從發起請求——得到響應資源，這過程當中的 各類約定規則的集合

咱們能夠類比一下平常生活中的例子來形象理解一下：
S1 若是古代人A想獲取一份救濟品，因而他向當地的行政員B寄了一份申請信，這就是發起一個資源請求。
S2 在通過一段路徑傳輸後，行政員B收到了申請(信)，因而返回了某些資源（好比 救濟金 /救濟糧 /拒絕信等），這就叫作 處理請求並響應
S3 在這過程當中，A 和 B 之間不少方面都是有規則約束的（好比 A 申請信的格式 / B返回資源的格式 / 返回資源的多少 /傳輸路線的選擇等等）

全部這些規則的集合，就稱爲`協議`

8 TCP/IP 分層設計
從上面的例子能夠看出，資源的傳輸（發出請求—傳遞請求—接到請求並處理—返回響應—傳輸響應—獲取響應並處理）實際上是一個很複雜的過程，須要考慮到許多不一樣方面因素，咱們能夠大體分爲如下層次：

S1 應用層: 首先要明確 A向B 發起請求的 具體目的是什麼 （多是要獲取救濟品/ 多是要投訴官員C/ ….）
S2 傳輸層: 其次要明確 A和B之間如何高效完整的 傳遞信息/資源;
S3 網絡層: 明確 傳輸路線

最關鍵的是要知道  IP地址和 MAC地址
        核心是 `路由選擇機制`

S4 鏈路層: 實際的物理道路/大橋等實體建築

分層的目的其實相似於分工，都是爲了各司其職，互不干擾，從而提升效率，繼續舉例來講:
S1 應用層——寫信人&信件的內容: 不一樣的目的，信件的內容各不相同。可是隻要負責寫好信件就能夠;
S2 傳輸層——信件/資源 加工處理站: 包括切分信件/資源爲 小塊，以便並行發送 + 內容完整性驗證;
S3 網絡層——信件/資源 傳輸中轉站: 明確 A 和 B 之間的傳輸路線;
S4 鏈路層—— 實際派送人員: 實際派送資源的人員
每過一層都會添上/去除 該層的首部信息(HTTP數據——TCP首部——IP首部——以太網首部)

9 TCP相關:

TCP的三次握手緣由:

三次握手便是在最快最省力的狀況下作出的選擇
好比在紅軍時代，A連和B連分在左右翼，約定在幾時幾分一同發起打擊。這個幾時幾分的信息就須要人工經過通信員來走路傳遞。
因此A連指揮官派出通信員。這是第一次。
在TCP裏，就是 `發送端 首先發送一個帶 SYN標誌的數據包 給對方`
假設通信員到達了B連，而且告知了B連指揮官幾時幾分，B連指揮官必定會讓通信員再回去通知A連指揮官，
可憐的通信員只能冒着危險返回A連，由於A連指揮官看不到通信員返回的話，不知道幾時幾分這個信息到底傳達到了B連沒有。
這是第二次。

在TCP裏，就是 接收端收到後, 回傳一個帶有 SYN/ACK標誌的數據包 以示傳達確認信息

在B連指揮官開始擔憂通信員是否回到了A連，若是沒回到，B連指揮官會設身處地的想想A連指揮官見不到返回的通信員，確定是不敢打的，
因此B連指揮官最盼望的是再次看到通信員出如今B連，因此A連指揮官會讓通信員再回B連一次。
這是第三次。

在TCP裏，就是 發送端再 回傳一個帶 ACK標誌的數據包，表明「握手」結束

這就是三次握手
總結圖以下:

10 URI 和 URL
URI: 統一資源標識符

由某個協議方案表示的 資源的定位字符串
 不一樣的協議方案，其獲取資源的語法等規則有區別

URL: 統一資源定位符，是URI的子集。也就是通常咱們輸入瀏覽器中的 網頁地址

絕對URI的格式:

協議類型(協議方案名):// [登陸驗證信息@]服務器地址:端口號 / 服務器上的文件路徑 ?查詢字符串 #片斷標識符
其中，
    服務器地址: 能夠是 IP/域名;
    文件路徑:   相似於 服務器上的文件目錄結構
    查詢字符串: 用於肯定 文件路徑內的某一資源，形如 xx=yy

具體見下示意圖:

三 HTTP 協議

3.1 協議總體內容

1 HTTP協議 規範了 客戶端和服務器端間的通訊流程:

S1 客戶端發起請求 —— S2 服務器接收+處理請求，返回響應內容 —— S3 客戶端接收+處理響應，展現/使用 響應內容;

可參考 MDN的 典型的HTTP會話

2 HTTP 規定了 通訊報文的內容+格式:

S1 請求報文:
            請求行: 請求方法 + 請求的資源內容(請求URL: 相對URL+host首部字段定位) + HTTP協議版本;
            請求首部字段
            \空行（CR+LF）
            請求內容實體
S2 響應報文:  狀態行:HTTP協議版本 + 狀態碼 + 緣由短語;
            響應首部字段
            \空行（CR+LF）
            響應內容實體

可參考 MDN的 HTTP消息

3 HTTP 規定了 自身是一種無狀態協議 + 持久鏈接

S1 爲了實現保持狀態功能 —— `cookie技術`
S2 持久鏈接: HTTP keep-alive, 只要任意一端沒有明確提出斷開鏈接，則保持 TCP鏈接狀態;
            持久鏈接的好處是實現了管線化，從而能夠 同時並行發送多個請求

可參考:
MDN的 HTTP cookies
MDN的 HTTP/1.x 的鏈接管理

3.2 請求方法

1 具體類型參見: MDN的 HTTP請求方法

2 GET和POST請求的區別:

1 根本區別是二者語義上的區別，GET的語義是「獲取數據」，POST的語義是「提交數據」;
2 get參數有長度限制(受限於url長度，具體數值取決於瀏覽器和服務器限制)，而post理論上沒有限制
3 GET冪等+不改變服務器狀態， POST不冪等+改變服務器狀態
4 GET提交的數據會在URL中顯示出來， 而POST 是把提交的數據放在 HTTP包的包體中

可參考

[get和post區別;](https://www.zhihu.com/question/28586791)
[HTTP協議中GET和POST方法的區別](https://sunshinevvv.coding.me/blog/2017/02/09/HttpGETv.s.POST/)

3.3 HTTP狀態碼

1 狀態碼的分類見圖:

2 常見的狀態碼含義
可參考

《圖解HTTP》第4章
[HTTP常見狀態碼;](https://www.cnblogs.com/starof/p/5035119.html)
[MDN的 HTTP響應代碼](https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status)

3.4 HTTP首部

1 做用:

HTTP首部字段 給瀏覽器/服務器 提供了 報文主體大小/所使用的語言/認證信息等額外信息內容

2 語法結構:

首部字段名: 字段值1,字段值2

3 類型:

分類一: 通用首部字段;  請求首部字段;  響應首部字段;  實體首部字段
分類二: 端到端首部;    逐跳首部

4 具體內容及含義
可參考

《圖解HTTP》第5章
 [MDN的 HTTP Headers](https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers)

四 結語

這篇文章只是介紹了HTTP的基本知識，不少具體知識只是提供了參考文檔，緣由是那部分知識偏向於真正用到時的隨手速查
全部記憶性而非理解性的內容，我以爲沒有必要做爲具體內容。

其次，關於HTTPS和安全的部分，本文並未說起，之後會再單獨寫一篇博文。

最後，這篇博文雖然按照我本身的思路整理了相關基本知識，可是參考了不少已有資料，我寫在了文末的參考文檔部分裏。若是給您形成不便，
我會第一時間修改或刪除相應內容。

五 參考文檔

  1 圖解HTTP;
  2 MDN的 HTTP目錄

  3 如何生動的解釋ip地址、子網掩碼、網關等概念;
  4 IP地址和MAC地址的區別和聯繫是什麼;
  5 怎樣生動描述 TCP 的「三次握手」;