Web安全入門之HTTP協議

閱前必讀:文章有點基礎,是我在看《圖解HTTP》這本書時做的筆記,也補充了一點東西。

網站訪問原理圖

1.TCP/IP協議族

1.TCP/IP協議的分層

TCP/IP協議族是分層管理的，在OSI標准中可以分為7層（應用層、表示層、會話層、傳輸層、網絡層、數據鏈路層、物理層，可記為：應表會傳網數物），本篇博客我們采用的是TCP/IP協議族中的四層（應用層、傳輸層、網絡層、鏈路層）。下方是對四層中每層的簡單介紹：

• 應用層：該層是面向用戶的一層，也就是說用戶可以直接操作該層，該層決定了向用戶提供應用服務時的通信活動。本篇博客要聊的HTTP（HyperText Transfer Protocol：超文本傳輸協議）就位於該層。我們經常使用的FTP(File Transfer Protocol: 文件傳輸協議)和DNS (Domain Name System: 域名系統)都位於該層。FTP簡單的說就是用來文件傳輸的。而DNS則負責域名解析的，通過DNS可以將域名（比如：www.baidu.com）與IP地址（201.33.xx.09）進行相互的轉換。在7層中，又將該層分為：應用層、表示層和會話層。
• 傳輸層：應用層的下方是傳輸層，應用層會將數據交付給傳輸層進行傳輸。TCP(Transmission Control Prococol:傳輸控制協議)和UDP(User Data Protocol: 用戶數據協議)位於該層，當然見名知意，該層是用來提供處於網絡連接中的兩台計算機直接的數據傳輸的。TCP建立連接是需要三次握手來確認連接情況，而UDP則沒有三次握手的過程。稍后會介紹。
• 網絡層：傳輸層的下方是網絡層，網絡層用來處理在網絡上流動的數據包，IP(Internet Protocol: 網際協議)就位於這層。該層負責在眾多網絡線路中選擇一條傳輸線路。當然這個選擇傳輸線路的過程需要IP地址和MAC地址的支持。
• 鏈路層：在7層協議中，將鏈路層分為數據鏈路層和物理層。該部分主要是用來處理網絡的硬件部分，我們常說的NIC（Net Work Card），也就是網卡就位於這一部分，當然光纖也是鏈路層的一部分。
  

2.TCP/IP 通信傳輸流

利用 TCP/IP 協議族進行網絡通信時，會通過分層順序與對方進行通信。發送端從應用層往下走，接收端則往應用層往上走。

我們用 HTTP 舉例來說明:

1.首先作為發送端的客戶端在應用層（HTTP 協議)發出一個想看某個 Web 頁面的 HTTP 請求。

2.在傳輸層（TCP 協議）把從應用層處收到的數據（HTTP 請求報文）進行分割，並在各個報文上打上標記序號及端口號后轉發給網絡層。

3.在網絡層（IP 協議），增加作為通信目的地的 MAC 地址后轉發給鏈路層。這樣一來，發往網絡的通信請求就准備齊全了。

4.接收端的服務器在鏈路層接收到數據，按序往上層發送，一直到應用層。當傳輸到應用層，才能算真正接收到由客戶端發送過來的 HTTP請求。

發送端在層與層之間傳輸數據時，每經過一層時必定會被打上一個該層所屬的首部信息。反之，接收端在層與層傳輸數據時，每經過一層時會把對應的首部消去。這種把數據信息包裝起來的做法稱為封裝（encapsulate）。

3.IP,TCP和DNS

這里我們分別針對與HTTP密不可分的這三種協議,IP,TCP和DNS

1.IP協議的概念與作用

英文為Internet Protocol，翻譯成網際協議,位於網絡層,幾乎所有的網絡都會用到IP協議。

這里可能會有人吧IP和IP地址搞混,其實是一種協議的名稱。

1.IP協議

IP協議的作用是吧各種數據包傳輸給對方.而要保證確實傳送到對方哪里,則需要滿足各類條件。

其他兩個重要的條件是IP地址和MAC地址(Media Access Control Address)

2.IP地址

IP地址指明了節點被分配到的地址,MAC地址是指網卡所屬的固定地址。IP地址可以和MAC地址進行配對。IP地址可變換,但MAC地址基本上不會更換。

3.MAC地址

這里我們簡單介紹下MAC地址

物理地址是一種標識符，用來標記網絡中的每個設備。同現實生活中收發快遞一樣，網絡內傳輸的所有數據包都會包含發送方和接收方的物理地址。

由於網絡設備對物理地址的處理能力有限，物理地址只在當前局域網內有效。所以，接收方的物理地址都必須存在於當前局域網內，否則會導致發送失敗。

MAC 地址是預留的

由於數據包中都會包含發送方和接收方的物理地址，數據包從起始地發送到目的地，為了能夠正確地將數據包發送出去，就必須要求 MAC 地址具有唯一性。因此 MAC 地址都是由生產廠家在生產時固化在網絡硬件中，是硬件預留的地址。

MAC 地址格式

硬件的 MAC 地址是廠家按照一定的規則，進行設置所產生的，因此，MAC 地址擁有自己的格式。

MAC 地址采用十六進制數表示，共 6 個字節（48 位），長度為 48bit（字節）。整個地址可以分為前 24 位和后 24 位，代表不同的含義。

• 前 24 位稱為組織唯一標識符（Organizationally Unique Identifier，OUI），是由 IEEE 的注冊管理機構給不同廠家分配的代碼，區分了不同的廠家。
• 后 24 位是由廠家自己分配的，稱為擴展標識符。同一個廠家生產的網卡中 MAC 地址后 24 位是不同的。

那我們這里簡單介紹下如何查看咱們的電腦的MAC地址

1、在設置→網絡和Internet→WLAN/以太網

我們點開他

下面可以看到MAC地址

4.ARP協議

1.基本概念：ARP協議是地址解析協議（Address Resolution Protocol）是通過解析IP地址得到MAC地址的，是一個在網絡協議包中極其重要的網絡傳輸協議。

2.為什么需要ARP協議：在網絡訪問層中，同一局域網中的一台主機要和另一台主機進行通信，需要通過MAC地址進行定位，然后才能進行數據包的發送。而在網絡層和傳輸層中，計算機之間是通過IP地址定位目標主機，對應的數據報文只包含目標主機的IP地址，而沒有MAC地址。因此，在發送之前需要根據IP地址獲取MAC地址，然后才能將數據包發送到正確的目標主機，而這個獲取過程是通過ARP協議完成的。

所以我們可以看出來 ARP協議是依賴MAC地址。

2.確保可靠性的TCP協議

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

所謂的字節流服務（Byte Stream Service）是指，為了方便傳輸，將大塊數據分割成以報文段（segment）為單位的數據包進行管理。而可靠的傳輸服務是指，能夠把數據准確可靠地傳給對方。一言以蔽之，TCP協議為了更容易傳送大數據才把數據分割，而且TCP協議能夠確認數據最終是否送達到對方。

為了准確無誤地將數據送達目標處，TCP協議采用了三次握手（three-way handshaking）建立連接。用TCP協議把數據包送出去后，TCP不會對傳送后的情況置之不理，它一定會向對方確認是否成功送達。握手過程中使用了TCP的標志（flag）--SYN（synchronize）和ACK（acknowledgement）

發送端首先發送一個帶 SYN 標志的數據包給對方。接收端收到后，回傳一個帶有 SYN / ACK 標志的數據包以示傳達確認信息。最后，發送端再回傳一個帶 ACK 標志的數據包，代表 “握手” 結束。

若在握手過程中某個階段莫名終斷，TCP協議會再次以相同的順序發送相同的數據包。

除了上次三次握手，TCP協議還有其他各種手段來保證通信的可靠性。

1.TCP

1. TCP 是面向連接的傳輸控制協議。

2. TCP 具有高可靠性，確保傳輸數據的正確性，不出現丟失或亂序。

3. TCP 協議可以保證接收端毫無差錯地接收到發送端發出的字節流，為應用程序提供可靠的通信服務。（對可靠性要求高的通信系統往往使用 TCP 傳輸數據。比如 HTTP 運用 TCP 進行數據的傳輸。）

2.UDP

1. UDP 提供了無連接的數據報服務。

2. UDP 在傳輸數據前不建立連接，不對數據報進行檢查與修改，無須等待對方的應答，所以會出現分組丟失、重復、亂序，應用程序需要負責傳輸可靠性方面的所有工作。

3. UDP 具有較好的實時性，工作效率較 TCP 協議高。

4. UDP 段結構比 TCP 的段結構簡單，因此網絡開銷也小。

3.DNS服務

DNS（Domain Name System）服務是和HTTP協議一樣位於應用層的協議。他提供域名到IP地址之間的解析服務。

計算機即可以被賦予IP地址，也可以被賦予主機名和域名。比如：www.baidu.com

用戶通常使用主機名或域名來訪問對方的計算機，而不是直接通過IP地址訪問。因為與IP地址的一組純數字相比，用字母配合數字的表示形式來指定計算機名更符合人類的記憶習慣。

但要讓計算機去理解名稱，相對而言就變得困難了。因為計算機更擅長處理一長串數字。

為了解決上述的問題，DNS服務因運而生。DNS協議提供通過域名查找IP，或逆向從IP地址反查域名的服務。

4.各種協議與HTTP協議的關系

4.URI和URL

1.URI

1.URI概念

URI，統一資源標志符(Uniform Resource Identifier， URI)，表示的是web上每一種可用的資源，如 HTML文檔、圖像、視頻片段、程序等都由一個URI進行標識的。

2.URI組成部分

URI通常由三部分組成：

①資源的命名機制；

②存放資源的主機名；

③資源自身的名稱。

（注意：這只是一般URI資源的命名方式，只要是可以唯一標識資源的都被稱為URI，上面三條合在一起是URI的充分不必要條件）

3.URI舉例

如：https://www.cnblogs.com/hmhm/p/15440737.html

我們可以這樣解釋它：

①這是一個可以通過https協議訪問的資源，

②位於主機cnblogs.com上，

③通過“/hmhm/p/15440737.html”可以對該資源進行唯一標識（注意，這個不一定是完整的路徑）

絕對URI格式

URI只是一種概念，怎樣實現無所謂，只要它唯一標識一個資源就可以了。

使用http：或https：等協議方案名獲取訪問資源時要指定協議類型。不區分字母大小寫，最后附一個冒號（:）。也可使用data：或javascript：這類指定數據或腳本程序的方案名。

登錄信息（認證）：指定用戶名和密碼作為從服務器端獲取資源時必要的登錄信息（身份認證）。此項是可選項。

服務器地址：使用絕對URI必須指定待訪問的服務器地址。地址可以是類似hackr.jp這種DNS可解析的名稱，或是192.168.1.1這類IPv4地址名，還可以是[0:0:0:0:0:0:0:1]這樣用方括號括起來的IPv6地址名。

服務器端口號：指定服務器連接的網絡端口號。此項也是可選項，若用戶省略則自動使用默認端口號。
帶層次的文件路徑：指定服務器上的文件路徑來定位特指的資源。這與UNIX系統的文件目錄結構相似。

查詢字符串：針對已指定的文件路徑內的資源，可以使用查詢字符串傳入任意參數。此項可選。

片段標識符：使用片段標識符通常可標記出已獲取資源中的子資源（文檔內的某個位置）。但在RFC中並沒有明確規定其使用方法。該項也為可選項。

2.URL

1.URL概念

URL是URI的一個子集。它是Uniform Resource Locator的縮寫，譯為“統一資源定位符”。

通俗地說，URL是Internet上描述信息資源的字符串，主要用在各種WWW客戶程序和服務器程序上。

采用URL可以用一種統一的格式來描述各種信息資源，包括文件、服務器的地址和目錄等。URL是URI概念的一種實現方式。

2.URL格式

URL的一般格式為(帶方括號[]的為可選項)：

protocol 😕/ hostname[:port] / path / [;parameters][?query]#fragment

URL的格式由三部分組成：

①第一部分是協議(或稱為服務方式)。

②第二部分是存有該資源的主機IP地址(有時也包括端口號)。

③第三部分是主機資源的具體地址，如目錄和文件名等。

第一部分和第二部分用“😕/”符號隔開，

第二部分和第三部分用“/”符號隔開。

第一部分和第二部分是不可缺少的，第三部分有時可以省略。

3.URL和URI的區別

URL是URI的子集。

例如：表示一個html

URI標識方式：121212.html，121212是當前html的唯一號碼，另外一個html則是除了121212之外的數字組合，URI就起到了獨一無二地標識html資源的作用。

URL定位方式：https://www.cnblogs.com/hmhm/p/15440737.html，是以更詳細地方式去表示一個資源，看到該html就可以知道它是存放在什么主機中的什么文件夾下

對於網址的話，傾向於采用URL方式，畢竟它提供了資源的位置信息，所以叫成URL。

5.HTTP是一種不保存狀態的協議

HTTP是一種不保存狀態的協議

HTTP是一種無狀態的協議。HTTP協議自身不對請求和響應之間的通信狀態進行保存。也就是說HTTP這個級別，協議對於發送過的請求和響應都不做持久化的處理。

為什么要這么做？

這是為了更快的處理大量的事務，確保協議的可伸縮性。而特意把HTTP設計得這么簡單的。

那么我要保存狀態的話要怎么做？

HTTP/1.1提出了相應的解決方法，雖然HTTP1.1也是無狀態的協議，但是引入了Cookie技術。有了Cookie再使用HTTP通信，就可以管理狀態了。后面我會總結到Cookie。

6.HTTP方法

HTTP方法有哪些？它們又有哪些用途

• GET方法。獲取資源。用來請求訪問一杯URI識別的資源。指定的資源經過服務器解析后返回的響應內容。
• POST方法。傳輸內容實體。雖然GET方法也可以用來傳輸內容實體，但是我們一般都不怎么做。POST的主要目的並不是獲取響應的主體內容。
• PUT方法。傳輸文件。就想FTP協議中的請求文件上傳一樣，要求在請求報文的實體中包含文件內容，然后保存到請求的URI指定的位置。但是鑒於HTTP1.1的PUT方法自身不帶有驗證機制，任何人都可以上傳文件，存在安全問題，因此一般的網站不選用這種方式。如果配合Web應用程序的驗證機制，或架構設計采用REST標准的同類Web網站，就可能會開放使用PUT方法。
• HEAD方法。獲取報文首部 。HEAD方法和GET方法一樣，只是不返回報文的主體部分。用於確認URI的有效性以及資源更新的日期時間等。
• DELETE方法。刪除文件。與PUT方法相反，按照請求的URI刪除指定的資源。
• OPTIONS方法用來查詢針對請求的URI指定的資源支持的方法。
• TRACE。追蹤路徑。讓web服務器將之前的請求通信環回給客戶端的方法。發送請求的時候，在Max-Forwards首部字段中加入數值，每經過一個服務器端該數字就減一，當數值剛好減到0的時候，就停止傳輸，最后收到請求的服務器返回的200OK的響應。
• 但是TRACE方法本來就不怎么常用，而且它容易引發XST（跨站追蹤），通常就更加不會用到了。
• CONNECT方法。要求隧道協議連接代理
  CONNECT方法要求在與代理服務器通信的時候建立隧道，實現用隧道協議進行TCP通信。主要使用SSL（secure sockets layer，安全套接層）和TLS（Transport Layer Security，傳輸層安全）協議把通信內容加密后經過網絡隧道傳輸。
  CONNECT方法的格式如下：
  CONNECT代理服務器名：端口號 HTTP版本
  

7.持久連接節省流量

在一開始的HTTP協議中，每進行一次HTTP 通信就斷開一次TCP連接。

在請求一個很多資源的HTML頁面的時候，每次連接都會造成無所謂的TCP連接的建立和斷開，增加了通信量的開銷。

1.持久連接

持久連接也被稱為HTTP keep alive或者HTTP connection reuse。它的特點是，只要任意一端沒有明確提出斷開連接，則保持TCP連接狀態。

這樣做的好處：

減少了TCP連接重復建立和斷開的時間開銷

+減輕了服務端的負載

在HTTP/1.1中，所有的連接默認都是持久連接，但是HTTP/1.0內比沒有標准化。雖然有一部分服務端通過一些非標准的手段實現了持久連接，但服務端不一定能夠支持持久連接。

什么是管線化
之前需要發送請求之后必須等待並且接收到回應之后，才能發送下一個請求。管線化技術出現之后，就不用等待就可以發送下一個請求了。

管線化的好處

能夠做到同時並行發送多個請求，而不需要一個接着一個地等待響應。

8.Cookie技術

Cookie的工作原理：Cookie會根據從服務端發送的響應報文中的一個稱set-Cookie的首部字段中，通知客戶端保存Cookie。當客戶端下次再往服務端發送請求的時候，客戶端會自動在請求報文中加入Cookie值發送出去。

服務端接收到Cookie后，會去檢查究竟是從哪一個客戶端發送過來的（主要是通過對比服務端的記錄），最后得到之前的狀態信息。

• 第一次請求的時候（也就是還沒有Cookie）
  
  第二次請求的時候
  
  上面兩次請求的請求和響應報文如下所示：
  

9.HTTP狀態碼

HTTP狀態碼分類

HTTP狀態碼

當瀏覽者訪問一個網頁時，瀏覽者的瀏覽器會向網頁所在服務器發出請求。當瀏覽器接收並顯示網頁前，此網頁所在的服務器會返回一個包含HTTP狀態碼的信息頭（server header）用以響應瀏覽器的請求。

HTTP狀態碼的英文為HTTP Status Code。

下面是常見的HTTP狀態碼：

• 200 - 請求成功
• 301 - 資源（網頁等）被永久轉移到其它URL
• 404 - 請求的資源（網頁等）不存在
• 500 - 內部服務器錯誤

HTTP狀態碼由三個十進制數字組成，第一個十進制數字定義了狀態碼的類型，后兩個數字沒有分類的作用。HTTP狀態碼共分為5種類型：

分類	分類描述
1**	信息，服務器收到請求，需要請求者繼續執行操作
2**	成功，操作被成功接收並處理
3**	重定向，需要進一步的操作以完成請求
4**	客戶端錯誤，請求包含語法錯誤或無法完成請求
5**	服務器錯誤，服務器在處理請求的過程中發生了錯誤·++

HTTP狀態碼列表

狀態碼	狀態碼英文名稱	中文描述
100	Continue	繼續。[客戶端]應繼續其請求
101	Switching Protocols	切換協議。服務器根據客戶端的請求切換協議。只能切換到更高級的協議，例如，切換到HTTP的新版本協議
200	OK	請求成功。一般用於GET與POST請求
201	Created	已創建。成功請求並創建了新的資源
202	Accepted	已接受。已經接受請求，但未處理完成
203	Non-Authoritative Information	非授權信息。請求成功。但返回的meta信息不在原始的服務器，而是一個副本
204	No Content	無內容。服務器成功處理，但未返回內容。在未更新網頁的情況下，可確保瀏覽器繼續顯示當前文檔
205	Reset Content	重置內容。服務器處理成功，用戶終端（例如：瀏覽器）應重置文檔視圖。可通過此返回碼清除瀏覽器的表單域
206	Partial Content	部分內容。服務器成功處理了部分GET請求
300	Multiple Choices	多種選擇。請求的資源可包括多個位置，相應可返回一個資源特征與地址的列表用於用戶終端（例如：瀏覽器）選擇
301	Moved Permanently	永久移動。請求的資源已被永久的移動到新URI，返回信息會包括新的URI，瀏覽器會自動定向到新URI。今后任何新的請求都應使用新的URI代替
302	Found	臨時移動。與301類似。但資源只是臨時被移動。客戶端應繼續使用原有URI
303	See Other	查看其它地址。與301類似。使用GET和POST請求查看
304	Not Modified	未修改。所請求的資源未修改，服務器返回此狀態碼時，不會返回任何資源。客戶端通常會緩存訪問過的資源，通過提供一個頭信息指出客戶端希望只返回在指定日期之后修改的資源
305	Use Proxy	使用代理。所請求的資源必須通過代理訪問
306	Unused	已經被廢棄的HTTP狀態碼
307	Temporary Redirect	臨時重定向。與302類似。使用GET請求重定向
400	Bad Request	客戶端請求的語法錯誤，服務器無法理解
401	Unauthorized	請求要求用戶的身份認證
402	Payment Required	保留，將來使用
403	Forbidden	服務器理解請求客戶端的請求，但是拒絕執行此請求
404	Not Found	服務器無法根據客戶端的請求找到資源（網頁）。通過此代碼，網站設計人員可設置"您所請求的資源無法找到"的個性頁面
405	Method Not Allowed	客戶端請求中的方法被禁止
406	Not Acceptable	服務器無法根據客戶端請求的內容特性完成請求
407	Proxy Authentication Required	請求要求代理的身份認證，與401類似，但請求者應當使用代理進行授權
408	Request Time-out	服務器等待客戶端發送的請求時間過長，超時
409	Conflict	服務器完成客戶端的 PUT 請求時可能返回此代碼，服務器處理請求時發生了沖突
410	Gone	客戶端請求的資源已經不存在。410不同於404，如果資源以前有現在被永久刪除了可使用410代碼，網站設計人員可通過301代碼指定資源的新位置
411	Length Required	服務器無法處理客戶端發送的不帶Content-Length的請求信息
412	Precondition Failed	客戶端請求信息的先決條件錯誤
413	Request Entity Too Large	由於請求的實體過大，服務器無法處理，因此拒絕請求。為防止客戶端的連續請求，服務器可能會關閉連接。如果只是服務器暫時無法處理，則會包含一個Retry-After的響應信息
414	Request-URI Too Large	請求的URI過長（URI通常為網址），服務器無法處理
415	Unsupported Media Type	服務器無法處理請求附帶的媒體格式
416	Requested range not satisfiable	客戶端請求的范圍無效
417	Expectation Failed	服務器無法滿足Expect的請求頭信息
500	Internal Server Error	服務器內部錯誤，無法完成請求
501	Not Implemented	服務器不支持請求的功能，無法完成請求
502	Bad Gateway	作為網關或者代理工作的服務器嘗試執行請求時，從遠程服務器接收到了一個無效的響應
503	Service Unavailable	由於超載或系統維護，服務器暫時的無法處理客戶端的請求。延時的長度可包含在服務器的Retry-After頭信息中
504	Gateway Time-out	充當網關或代理的服務器，未及時從遠端服務器獲取請求
505	HTTP Version not supported	服務器不支持請求的HTTP協議的版本，無法完成處理