《圖解 HTTP》 摘要一

  • 學習過程對書本的內容的摘要以及總結,逐步完善,帶有我的理解成分。

Web 及網絡基礎

使用 HTTP 協議訪問 Web

  • 客戶端:經過獲取請求獲取服務資源的 Web 瀏覽器等
  • HTTP 全稱:HtyperText Transfer Protocol
  • WWW 全稱:Wrold Wide Web
  • SGML 標準通用標記語言 全稱:Standard Generalized Markup Language

網絡基礎 TCP/IP

  • TCP/IP 協議族,或指TCP、IP
  • 協議族常見協議:TCP、UDP、IP、PPPoE、DNS、SNMP、ICMP 等

TCP/IP 的分層管理

分爲四層:應用層、傳輸層、網絡層、數據鏈路層html

應用層
  • 決定了向用戶提供應用服務時通訊的活動
  • 預存了各種通用的應用服務。如:DNS、FTP
  • HTTP 協議也在該層
傳輸層
  • 對上層應用層,提供處於網絡鏈接中的兩臺計算機之間的數據傳輸協議
  • TCP、UDP在其中
網絡層(網絡互連層)
  • 處理網絡上的流動數據包。
  • 數據包:網絡傳輸的最小單位。
  • 規定了經過了怎樣的傳輸路徑(傳輸路線)到達對方的計算機,並把數據包給對方。
鏈路層(數據鏈路層、網絡接口層)
  • 處理鏈接網絡的硬件部分。
  • 例如:控制操做系統、硬件的設備驅動、光纖等,硬件範圍。

TCP/IP 通訊傳輸流

  • 發送端:應用層往下走。接受端相反
  • 發送端:層與層之間傳輸數據的時候會把對應的首部信息打上。反之消去首部。
  • 把數據包裝起來的作法叫封裝。

與 HTTP 密切相關的協議:IP、TCP 和 DNS

負責傳輸的 IP 協議

  • IP:Internet Protocol 位於網絡層的網際協議。
  • 把各自數據包傳送給對方。
  • 要保證確實傳輸到對方那裏,須要知足各種條件。其中兩個重要的是:IP 地址和 MAC 地址(Media Access Control Address)。IP 地址指明瞭節點被分配的地址,MAC 地址是指網卡所屬的固定地址。
  • IP 地址可和 MAC 地址相互匹配,IP 地址可變換, MAC 地址基本上不會更改。

使用ARP協議(Address Resolution Protrocol)協議

  • 是一種用以解析地址的協議。
  • 根據通訊方的IP地址就能夠反查出對應的 MAC 地址。

確保可靠性的 TCP 協議

  • 位於傳輸層,提供可靠的字節流服務。web

  • 字節流服務:爲方便傳輸,將大塊的數據分割成報文段(segment)爲單位的數據包進行管理。(爲了傳輸大數據纔將數據進行分割)瀏覽器

  • 可靠的服務:把數據準確的傳輸給對方。安全

  • 確保能到達目標。服務器

    • 採用三次握手策略(three-way handshaking)策略。
    • 使用了 TCP 標誌:(flag)—SYN(synchronize) 和 ACK(ackonwledgement)

負責域名解析的 DNS 服務

  • DNS(Domain Name System)是位於應用層的協議。同 HTTP 同樣。
  • 提供域名到 IP 地址之間的解析服務。可逆向查詢。
  • 計算機可被賦予 IP 地址,也可被賦予 主機名和域名。一般用主機名或域名,由於符合人類記憶習慣。

各類服務與 HTTP 協議的關係

  • 想一想想一想

URI 和 URL

  • URI:Uniform Resource Identifier 統一資源標識符。
    • Uniform 規定統一的格式,方便處理多種不一樣類型的資源。
    • Resource 資源的定義是「可標識的任何東西」。除文檔文件、圖形或服務等可以區別與其餘的,所有可作資源。資源不只可單一,也能夠是多數的集合體。
    • Identifier 表示可標識的對象。也稱標識符。
    • 就是由某個協議方案表示的資源定位符。協議方案是指訪問資源時使用的協議的類型名稱。例如:採用 HTTP 協議的時候,協議方案就是 http。除此以外,還有ftp、file等30多種。

URI 用字符串標識着某一互聯網資源,URL 表示資源的地點。cookie

可見,URL 是 URI 的子集。網絡

  • URL:Uniform Resource Locator 統一資源定位符。

URI 格式

  • 表示指定的 URL ,要使用涵蓋所有必要信息的 絕對 URL 、絕對 URL 以及相對 URL 以及相對 URL 。相對 URL ,是指從瀏覽器中基本 URL 處指定的 URL,形如 /image/logo.gif

絕對 URL 的格式:less

http:// user:pass @ www. exanple.jp: 80 / dir/index.htm ? uid=1 # ch1jsp

  • http:// 協議方案名。不區分大小寫。
  • user:pass 登陸信息(認證)。可選信息。
  • www. exanple.jp: 服務器地址。
    • 使用絕對的URL必須指定待訪問的服務器地址。
    • 地址能夠是相似 hackr.jp 這種DNS 可解析的名稱,也能夠是 192.168.1.1 這種相似 IPv4 地址名,還能夠是 [0:0:0:0:0:0:0:1]這種方括號括起來的 IPv6 地址名。
  • 80 服務器端口號。可選項。省略則使用默認的端口號。
  • dir/index.htm 帶層次的文件路徑。與 UNIX 系統的文件目錄結構相似。
  • uid=1 查詢字符串。針對已指定的文件路徑內的資源。可選。
  • ch1 片斷標識符。一般可標記出已獲取資源的子資源。可選。 RFC 中沒有規定其使用方法。

RFC(Request for COmments)徵求修正意見書tcp

制定 HTTP 協議技術標準的文檔。

簡單的 HTTP 協議

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

  • 一定是一端擔任客戶端角色,另外一端擔任服務器角色。

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

  • 請求一定由客戶端發出,服務端回覆

實例:

客戶端發給某個服務器的請求報文中的內容。


GET /index.htm HTTP/1.1

Host : hacker.jp


  • GET 請求訪問服務器的類型,稱爲方法(method)。
  • /index.htm 指明瞭訪問的資源對象。稱爲 請求URI(request-URI)。
  • HTTP/1.1 是 HTTP 的版本號。

意思是:請求訪問某臺 HTTP 服務器上的 /index/htm 頁面資源


// 服務器
HTTP/1.1 200 OK
Date: Tue, 1 Jan 2020 08:00:01 GMT
Content-Length: 362
Content-Type: text/html

...

請求報文是由請求方法、請求URL、協議版本、可選的請求首部字段和內容實體構成。

  • HTTP/1.1 表示服務對應的 HTTP 版本。
  • 200 OK 表示請求的處理結果的狀態碼(status code)和緣由短語(reason-phrase)。
  • 下一行顯示響應的時間,是首部字段(header field)內的一個屬性。
  • 接下來,空一行 分隔,以後的內容稱爲資源實體的主體(enntity field)
  • GMT 是響應首部字段。

HTTP 是不保存狀態的協議

  • 無狀態協議(stateless)
  • HTTP 這個級別,協議對於發送請求或響應都不作持久化處理。
  • 每當有新的請求,即產生新的響應,不保存以前的響應報文信息。
  • 爲了保持狀態,引入 Cookie 技術。

請求 URL 定位資源

  • 類型不少種。。。

若是不是訪問特定的資源,而是對服務器自己發起請求,能夠用一個 * 來代替請求URI。例如:

OPTIONS * HTTP/1.1

告知服務器意圖的 HTTP 方法

GET :獲取資源

  • GET 方法用來請求訪問已被 URI 識別的資源。
  • 指定的資源經服務端解析後返回響應內容。若是請求資源是文本,那就保持原樣返回;若是是像 CGI(Common Gateway Interface) 通用網關接口那樣的程序,則返回通過執行後的輸出結果。

例子:

請求 Get /index.html http/1.1
響應 返回 index.html 的頁面資源

請求 Get /index.html http/1.1
Host: www.hackr. jp
if-modified-since: thu, 1 jan 2020 08:20:01 gmt
響應 僅返回2020年1月1日8點20分之後更新過的index頁面資源。

POST:傳輸實體主體

  • 用來傳輸實體的主體。

例子:

請求 post /submit.cgi http/1.1
Host: www.hackr. jp
content-length:1560(1560字節的數據)
響應 返回 submit.cgi 接收數據的處理結果

PUT:傳輸文件

  • 傳輸文件,像 FTP 同樣。
  • 要求在請求報文主體中包含文件內容,而後保存到請求 URI 制定的位置。
  • HTTP/1.1 自身不帶驗證機制。存在安全問題,通常不用。
  • 若配合 Web 應用程序的驗證機制,或採用 REST(REpresentational State Transfer,表徵狀態轉移) 標準的同類 Web 網站,可能會使用。

例子:

請求 put /example.html http/1.1
host: www.hackr .jp
content-type: text/html
content-length: 1560 (1560字節的數據)
響應 響應返回狀態碼 204 Not Content (好比:該 html 已存在於服務器上)

HEAD:得到報文首部

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

例子:

請求 head /index.html http/1.1
host: www.hackr .jsp
響應 返回 index.html有關的響應首部

DELETE:刪除文件

  • 用來刪除文件,是與 PUT 相反的方法。
  • 可是和 HTTP/1.1 同樣,不帶驗證機制,因此通常的 Web 網站也不使用 DELETE 方法。
  • 當配合 Web 應用程序的驗證機制,或遵循 REST 標準時仍是有可能會開放使用。

例子:

請求 DELETE /example.html HTTP/1.1
響應 響應返回狀態碼 204 No Content (好比:該 html 已從該服務器上刪除)

OPTIONS:詢問支持的方法

例子:

請求 OPTIONS * HTTP/1.1
Host:www.hackr .jp
響應 HTTP/1.1 200 OK
Allow: GET, POST, HEAD, OPTIONS(返回服務器支持的方法)

TRACE:追蹤路徑

  • 讓 Web 服務器端將以前的請求經過通訊迴環給客戶端的方法。
  • 在 Max-Forwards 首部字段中填入數值,每通過一個服務器就將該數字減1,當數字減到 0 時,就返回狀態碼 200 OK 的響應。
  • 客戶端經過 TRACE 方法查詢發送出去的請求是怎樣被加工修改/篡改的。由於請求鏈接到源目標服務器可能會經過代理中轉,TRACE 方法就是用來確認鏈接過程當中發生的一系列操做。
  • 不經常使用。易引起 XST(Cross-Site Tracing,跨站追蹤)攻擊。

例子:

請求 TRACE / HTTP/1.1
Host: hackr.jp
Max-Forwards:2
響應 HTTP/1.1 200 OK
Content-Type: message/http

TRACE / HTTP/1.1
Host: hackr.jp
Max-Forwards:2 (返回響應包含的請求內容)

CONNECT:要求要用隧道協議鏈接代理

  • 要求在與代理服務器通訊時創建隧道,實現用隧道協議進行 TCP 通訊。
  • 主要使用 SSL (Secure Sockets Layer,安全套接層) 和 TLS(Transport Layer Security,傳輸層安全)協議把通訊內容加密後經網絡隧道傳輸。
  • 語法格式:CONNECT 代理服務名:端口號 HTTP版本

例子:

請求 CONNECT proxy.hackr.jp:8080 HTTP/1.1
Host: proxy.hackr.jp
響應 HTTP/1.1 200 OK(以後進入網絡隧道)

使用方法下達命令

  • 向請求 URI 制定的資源發送請求報文時,採用成爲方法的命令。
  • 方法的做用在於,能夠指定請求的資源定期望產生某種行爲。方法中有 GET、POST 和 HEAD 等。

支持的方法

方法 說明 支持的 HTTP 協議版本
GET 獲取資源 1.0、1.1
POST 傳輸實體主體 1.0、1.1
PUT 傳輸文件 1.0、1.1
HEAD 獲取報文首部 1.0、1.1
DELETE 刪除文件 1.0、1.1
OPTIONS 詢問支持的方法 1.1
TRACE 追蹤路徑 1.1
CONNECT 要求用隧道協議鏈接代理 1.1
LINK 創建和資源之間的聯繫 1.0
UNLINE 斷開鏈接關係 1.0

持久鏈接節省通訊量

  • 以前的狀況:每進行一次 HTTP 通訊就要斷開一次 TCP 鏈接。

持久鏈接

  • 持久鏈接(HTTP Persistent Connections),也稱爲 HTTP keep-alive 或 HTTP connection reuse。
  • 特色:只要任意一端沒有明確提出斷開鏈接,則保持 TCP 鏈接狀態。
  • 在 HTTP/1.1 中全部的鏈接默認都是持久鏈接。

管線化

  • 使用管線化技術,不用等待響應便可直接發送下一個請求
  • HTTP 協議,無協議也有好處,簡單纔會被更多的應用。

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

Cookie 會根據從服務器端發送的響應報文內的一個叫 Set-Cookie 的首部字段信息,通知客戶端保存 Cookie。

下次再客戶端再往該服務器發送請求時,客戶端會自動再請求報文中加入 Cookie 值後發送出去。

  • HTTP 請求報文和響應報文內容以下:

1.請求報文(沒有 Cookie 信息的狀態)


GET /reader/ HTTP/1.1

Host: hackr.jp

  • 首部字段內沒有 Cookie 的相關信息

2.響應報文(服務器端生成 Cookie 信息)


HTTP /1.1 200 OK

Date: Tue, 1 Jan 2020 08:10:01 GMT

Sever: Apache

<Set-Cookie:sid=13420770140226734; pa+10-jan-11 08:10:01 GMT>

content-Type: text/plain; charaset=UTF-8


3.請求報文


GET /image/ HTTP/1.1

Host: hackr.jp

Cookie: sid=1342077140226724

相關文章
相關標籤/搜索