基石-初見網絡（二）：Web&HTTP&HTTPS

時間 2019-12-16

標籤基石初見網絡 web&http&https web http https 欄目系統網絡简体版

原文原文鏈接

概述

整理第一次學習HTTP的筆記，其中還有大量知識沒有學習以及整理，在下一次循環學習期會將文章更新。算法

文章包含以下部分，以及待完成部分瀏覽器

第一部分 Web基礎安全

簡述WEB基礎
TCP/IP分層管理以及通訊流
IP協議 TCP協議
各類協議之間的關係
UDP和TCP區別
路由選擇、路由協議以及路由選擇算法

第二部分初見HTTPbash

簡述HTTP
持久化通訊技術
Cookie狀態管理
HTTP報文結構
狀態碼
HTTP報文首部
詳解POST和GET的區別

第三部分 HTTP to HTTPS服務器

HTTP to HTTPS網絡
HTTS安全通訊機制post
SSL協議學習

若是你是對HTTP瞭如指掌的大佬就當重溫知識點，而且給孩子找找問題、提提學習建議和學習路線。大數據

或者你是對HTTP還迷迷糊糊的新萌，就和我一塊兒先對HTTP有一個初步認識吧~網站

WEB基礎

Web互聯網與HTTP的關係

Web使用的一種名爲HTTP(超文本傳輸協議)的協議進行規範，完成從客戶端到服務端等一系列運做流程。能夠說Web是創建在HTTP協議上通訊的。

網絡基礎TCP/IP

一般使用的互聯網是在TCP/IP協議族的基礎之上運行的，HTTP屬於他們內部的一個子集。把互聯網相關聯的協議集合起來，總稱爲TCP/IP協議。

TCP/IP分層管理

按層次分爲應用層、傳輸層、網絡層和數據鏈路層。

應用層：決定了向用戶提供應用服務時通訊的活動，例如FTP（文件傳輸協議）、DNS（域名解析協議）以及HTTP。
傳輸層：提供處於網絡鏈接中的兩臺計算機之間的數據傳輸，例如：TCP（傳輸控制協議）和UDP（用戶數據報協議）
網絡層：用來處理在網絡上流動的數據包，該層決定了在衆多線路中選擇一條傳輸路線。例如：IP協議
鏈路層：物理可見部分，硬件上的範疇都屬於鏈路層

TCP/IP通訊傳輸流

通訊傳輸流

以HTTP舉例，首先客戶端經過應用層（HTTP協議）發送一個打開Web頁面的網絡請求。爲了傳輸方便，在傳輸層（TCP協議）把從應用層收到的數據（HTTP請求報文）進行分割，在各個報文上打上標記序號以及端口號後轉發給網絡層。在網絡層（IP協議）增長了做爲通訊目的的MAC地址後轉發給鏈路層。接收端的服務器在鏈路層上收到數據後，按自底向上順序發送，當傳輸到應用層，纔算是有真正接收到右客戶端發送來的請求。

信息封裝

發送端在層與層之間傳輸數據時，每通過一層，一定會被打上一個該層所屬的首部信息。反之在接收端在層與層之間傳輸時，每通過一層，也會把對應的首部消去。

IP協議

按層次分，IP（網際網絡）協議存在於網絡層中。做用是：把各類數據包傳送給對方。

確保可以傳送到對方手中，須要知足各種條件，例如IP地址與MAC地址。 IP地址指明瞭節點被分配到的地址，MAC地址是指網卡所屬的固定地址，IP地址和MAC地址進行配對。一般IP地址能夠更換，但MAC地址基本不變。

使用ARP協議借MAC地址進行通訊 IP間的通訊依賴MAC地址，在網絡上，一般通訊的雙方不在同一局域網下，這時就須要在多臺計算機和網絡設備中進行中轉才能鏈接到對方。在中轉過程當中，會利用下一臺中轉設備的MAC地址來搜索目標，這時會採用ARP協議進行解析地址，根據通訊方的IP地址就能夠反查出來對應的MAC地址。

在到達通訊目標前的中轉過程當中，計算機和路由器等網絡設備只能獲悉很粗略的傳輸線路，這一機制稱爲路由選擇，因此他們沒法全面掌握互聯網中的細節。

TCP協議

按層次分，TCP協議位於傳輸層，它提供可靠的字節流服務。

字節流服務爲了方便傳輸，將大塊數據分割成以報文段爲單位的數據包進行管理。

確保數據可以到達目標（可靠的） TCP協議採起三次握手策略，用TCP協議把數據包發送出去後，TCP不會對傳送結果置之不理，他必定會向對方確認是否成功送達。過程當中採用了TCP的標誌---SYN和ACK。首先發送端發送一個帶有SYN標誌的數據包給對方，接收端接受到後，回傳一個帶有SYN/ACK標誌的數據包以表示傳達確認信息，最後，發送端再回傳一個帶有ACK的數據包，表示握手結束。在握手過程當中某個階段莫名中斷，TCP協議會再次以相同的順序發送相同的數據包進行通訊。

TCP協議爲了更容易傳輸大數據才把數據分割，並且TCP協議可以確認數據最終是否送達到對方。

DNS服務

和HTTP協議位於應用層，負責域名到IP地址之間的解析服務，也能夠經過IP地址反查域名服務。

各個協議與HTTP協議之間的關係

URI和URL

URL（統一資源定位符）與URI（統一資源標識符）相比，更熟悉URL，例如purplercode.work/

統一資源標識符

URI是 Uniform Resource Identifier 的縮寫，RFC2396分別對這三個單詞進行以下定義。

Uniform 規定統一的格式可方便處理多種不一樣類型的資源，而不用根據上下文環境來識別資源指定的訪問方式。另外，加入新增的協議方案（如 http: 或 ftp:）也更容易。
Resource 資源的定義是能夠標識的任何東西。

Identifier 可標識的對象，也稱標識符。 URI用字符串標識某一互聯網資源，而URL表示資源的地點，可見URL是URI的子集。 通用語法實例：

ftp://ftp.is.co.za/rfc/rfc1808.txt
http://www.ietf.org/rfc/rfc2396.txt
ldap://[2001:db8::7]/c=GB?objectClass?one
mailto:John.Doe@example.com
news:comp.infosystems.www.servers.unix
tel:+1-816-555-1212
telnet://192.0.2.16:80/
複製代碼

初見HTTP協議

HTTP協議用於客戶端和服務端之間的通訊

應用HTTP協議的時候，一定一方時客戶端角色（發起請求），一方時服務器角色（提供資源）。
雖然客戶端和服務器能夠角色互換，可是在一條通訊線路上，角色是固定的，而且HTTP可以確認出雙方。

經過請求和相應的交換達成通訊

HTTP協議規定，請求從客戶端發出，最後服務器端響應請求並返回。

請求報文是由請求方法，請求URI、協議版本、可選的請求首部字段以及內容實體構成。
響應報文基本上由協議版本，狀態碼和緣由短語，響應首部字段以及響應實體構成。

HTTP是不保存狀態的協議

HTTP是一種不保存狀態，即無狀態協議。HTTP協議自身不對請求和相應之間的通訊狀態（報文）進行保存。
使用HTTP協議，每當有新的請求發送時，就會有對應的新相應產生。協議自己並不保留以前一切的請求或相應報文的信息，目的是可以快速處理大量事務，確保協議的可伸縮性。
爲了實現保持狀態功能引入了Cookie技術。

請求URI定位資源

HTTP協議使用URI定位互聯網上的資源。

當客戶端請求訪問資源而發送請求時，URI須要將做爲請求報文中的請求URI包含在內，指定URI的方式有不少種。

除此以外，若是不是訪問特定資源而是對服務器自己發起請求，能夠用一個 * 來代替請求 URI。OPTIONS * HTTP/1.1

常見HTTP方法

GET:獲取資源

GET 方法用來請求訪問已被 URI 識別的資源。指定的資源經服務器端解析後返回響應內容。

POST：傳輸實體主體

POST方法一般是是用於傳輸實體內容。注意區分和GET方法的不一樣，雖然本質上都能發送網絡請求。

PUT：傳輸文件

PUT 方法用來傳輸文件。就像 FTP 協議的文件上傳同樣，要求在請求報文的主體中包含文件內容

HEAD：得到報文首部

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

DELETE：刪除文件

DELETE 方法用來刪除文件，是與 PUT 相反的方法。DELETE 方法按請求 URI 刪除指定的資源。

OPTIONS：詢問支持的方法

OPTIONS 方法用來查詢針對請求 URI 指定的資源支持的方法。

持久鏈接

之前的通訊方式

在之前每進行一次HTTP通訊就要斷開一次TCP鏈接。

隨着HTTP的普及，文檔中的內容多了起來，致使增長了大量的通訊量開銷。

持久鏈接

爲解決上述問題，HTTP/1.1提出了持久鏈接 HTTP keep-alive,他的特色是隻要任意一段沒有明確的提出斷開鏈接，則保持TCP鏈接狀態。

管線化

持久鏈接使得多數請求以管線化方式發送成爲可能。從前發送請求後須要等待並收到響應，才能發送下一個請求。

管線化技術出現後，不須要等到響應能夠直接發送下一個請求。管線化技術比持久鏈接還要快，數據越多時候差距越明顯。

使用Cookie的狀態管理

由於HTTP是無狀態協議，不對以前發生過的請求和響應狀態進行管理。無狀態協議有他本身的優勢，因爲沒必要保存狀態，能夠減小服務器的CPU以及內存資源消耗。

正由於HTTP協議自己很是簡單，因此應用的也較爲普遍。

保留無狀態協議這個特徵的同時又要解決相似的矛盾問題，因而引入了 Cookie 技術。

引入Cookie技術

Cookie技術經過在請求和響應報文中寫入Cookie信息來控制客戶端的狀態。

沒有Cookie信息狀態下的請求
第二次存有Cookie信息狀態的請求

HTTP報文

瞭解HTTP報文

用於HTTP協議交互的信息稱爲HTTP報文，分爲請求報文和響應報文。

一般報文分爲報文首部（必須）和報文主體（可選）兩塊。

報文結構

請求報文和響應報文結構

請求報文（上）響應報文（下）的實例

請求行：

請求的方法、URI和HTTP版本

狀態行：

HTTP版本、響應結果狀態碼以及緣由短語

首部字段

包括表示請求和響應的各類條件和屬性

一般首部字段分爲：通用首部、請求首部、響應首部。

HTTP狀態碼

1XX	信息性狀態碼	接受的請求正在處理
2XX	成功狀態碼	請求正常處理
3XX	重定向狀態碼	須要進行附加操做
4XX	客戶端錯誤狀態碼	服務器沒法處理請求
5XX	服務器錯誤狀態碼	服務器處理請求出錯

2XX 成功

表示請求被正常處理

200 OK

23237)

表示從客戶端發來的請求服務器正常處理

204 No Content

![](user-gold-cdn.xitu.io/2019/12/14/…

請求處理成功，可是沒有資源能夠返回

206 Partial Content

該狀態碼錶示服務器成功執行了客戶端的範圍請求。

3XX重定向

3XX 響應結果代表瀏覽器須要執行某些特殊的處理以正確處理請求。

301 Moved Permanently

永久性重定向。該狀態碼錶示請求的資源已被分配了新的 URI，之後應使用資源如今所指的 URI。

302 Found

臨時性重定向。該狀態碼錶示請求的資源已被分配了新的 URI，但願用戶（本次）能使用新的 URI 訪問。注意是臨時。

303 See Other

該狀態碼錶示因爲請求對應的資源存在着另外一個 URI，應使用 GET 方法定向獲取請求的資源。

4XX客戶端錯誤

4XX 的響應結果代表客戶端是發生錯誤的緣由所在

400 Bad Request

該狀態碼錶示請求報文中存在語法錯誤。當錯誤發生時，需修改請求的內容後再次發送請求。

401 Unauthorized

該狀態碼錶示發送的請求須要有經過 HTTP 認證（BASIC 認證、DIGEST 認證）的認證信息。另外若以前已進行過 1 次請求，則表示用戶認證失敗。

403 Forbidden

該狀態碼代表對請求資源的訪問被服務器拒絕

404 Not Found

5XX服務器錯誤

5XX的響應結果表示服務器自己發生錯誤

500 Internal Server Error

狀態碼代表服務器端在執行請求時發生了錯誤。也有多是 Web 應用存在的 bug 或某些臨時的故障。

503 Service Unavailable

該狀態碼代表服務器暫時處於超負載或正在進行停機維護，如今沒法處理請求。

HTTP報文首部

HTTP首部字段是構成HTTP報文的要素之一。在客戶端與服務器之間以 HTTP 協議進行通訊的過程當中，不管是請求仍是響應都會使用首部字段，它能起到傳遞額外重要信息的做用。

使用首部字段是爲了給瀏覽器和服務器提供報文主體大小、所使用的語言、認證信息等內容。

4 種 HTTP 首部字段類型

通用首部字段（General Header Fields）

請求報文和響應報文兩方都會使用的首部。
請求首部字段（Request Header Fields）

從客戶端向服務器端發送請求報文時使用的首部。補充了請求的附加內容、客戶端信息、響應內容相關優先級等信息。
響應首部字段（Response Header Fields）

從服務器端向客戶端返回響應報文時使用的首部。補充了響應的附加內容，也會要求客戶端附加額外的內容信息。
實體首部字段（Entity Header Fields）

針對請求報文和響應報文的實體部分使用的首部。補充了資源內容更新時間等與實體有關的信息。

詳細內容請參考：MDN：HTTP Headers

HTTP to HTTPS

HTTP的缺點

通訊使用明文協議容易被竊聽