天天看點

《圖解HTTP》學習筆記

為什麼看此書

  如果你想了解網絡知識如HTTP協定、TCP/IP協定,但是又不是專業的網絡工程師,不會花大筆時間研究《TCP/IP詳解》這本聖經,那麼看《圖解HTTP》就對了。

這篇部落格可以說是我在看書時做的筆記吧。

第一章 了解Web及網絡基礎

Web和HTTP的誕生

  在20世紀80年代末時,為了知識共享為規劃的Web,随着Web的誕生,HTTP協定也就誕生了,隻是那時候還不成熟,并且在這之後的很久都不成熟,直到1996年才HTTP才正式作為标準被推出,版本為

HTTP/1.0

TCP/IP協定族

TCP/IP協定族,包括HTTP,DNS,FTP,UDP,PPPoE協定等;

TCP/IP協定族的分4層:應用層(FTP,DNS,HTTP)、傳輸層(TCP,UDP)、網絡層(IP)、資料鍊路層(NIC(Network Interface Card)網卡,光纖等實體裝置)。

TCP/IP資料傳輸流:資料是在用戶端從上層往下層,再從下層往上層傳遞到服務端。

TCP/IP的三次握手四次揮手

URI和URL

Uniform Resource Identifier

Uniform Resource Locator

第二章 簡單HTTP協定

這章介紹的是HTTP/1.1版本,也是目前用的版本。

用于用戶端和服務端通信

1.用戶端發送request請求,服務端回應respons;

2.請求封包和響應封包的格式構成;

3.http不儲存狀态,即,上一次請求和這一次請求是互相獨立的,可以通過傳遞相同的cookie來确認是否是相同的用戶端發送;

4.HTTP用戶端的請求方法,包括:GET,POST,PUT,HEAD,DELETE以及不常用的OPTIONS,TRACE,CONNECT,

5.持久連接配接指的是,為了解決TCP的三次握手和四次揮手耗時問題,即在第一次建立好連接配接後,在沒有斷開參數的情況下,HTTP請求仍在第一次建立的連接配接裡面發送消息;

第三章 HTTP封包内的HTTP資訊

第三章主要講的是,用戶端發送的請求和服務端響應的請求分别長什麼樣子。

  1. 封包的結構:

    封包首部 + 空行(CR+LF) + 封包主體

    ,需要注意的是,請求封包和響應封包雖然結構相同,但具體内容不同。
  2. 封包首部分為以下部分組成:

    請求行 + 狀态行 + 首部字段 + 其他

  3. 編碼能夠提高傳輸速率;

    除此之外,還可以把資料包分為多個部分傳輸,在封包首部中加以區分,以及不同浏覽器,相應不同的傳回封包;

第四章 傳回結果的HTTP狀态碼

狀态 類别 原因短語
1XX Informational(資訊性狀态碼) 接收的請求正在處理
2XX Success(成功狀态碼) 請求正常處理完畢
3XX Redirection(重定向狀态碼) 需要進行附加操作已完成請求
4XX Client Error(用戶端錯誤狀态碼) 伺服器無法處理請求
5XX Server Error(服務端錯誤狀态碼) 伺服器處理請求錯誤

第五章 與HTTP協作的Web伺服器

本章主要介紹Web伺服器,包括搭建Web網站,或者做提高效率的中轉伺服器。

其中,Web伺服器就是搭建常見的,某個網站所部署的機器就是了。

中轉伺服器種類比較多,包括代理,網關,隧道,緩存。

第六章 HTTP首部

在第三章簡單介紹了HTTP的封包資訊,也簡單介紹了HTTP首部,第六章再詳細講HTTP首部結構,以及各種字段的用法。

這章可以當做手冊使用,當遇到需要的時具體查詢吧。

第七章 確定Web安全的HTTPS

HTTP為什麼不安全

通過前面幾章學習,知道了HTTP的優勢,第七章說說HTTP的缺點以及如何解決這些缺點。

  1. 通信使用明文(不加密),内容可能會被竊聽;
  2. 不驗證通信方的身份,是以有可能遭遇僞裝;
  3. 無法證明封包的完整性,是以有可能已遭篡改;

HTTPS是什麼

HTTPS = HTTP + 加密 + 認證 + 完整性保護

HTTPS如何保證安全

  1. 服務端在數字證書認證機構把自己的公鑰通過認證機構的私鑰加密獲得伺服器自己的公鑰證書;
  2. 用戶端拿到第1步伺服器的公鑰證書後,使用認證機構提供的公鑰,向認證機構驗證公鑰證書上的數字簽名,以确認伺服器的公開密鑰的真實性;
  3. 用戶端使用服務端的公開密鑰對封包加密發送;
  4. 服務端用私有密鑰對封包解密;

第八章 确認通路使用者身份的認證

當網頁需要特定人浏覽時,就需要加入權限認證功能。本章介紹了4種認證方法。

BASIC認證

  1. 用戶端請求;
  2. 服務端傳回401狀态碼;
  3. 用戶端用Base64編碼發送使用者ID和密碼;
  4. 服務端認證成功傳回200;

DIGEST認證

  1. 服務端傳回401+質詢碼(通常為随機數,實際依賴服務端實作)
  2. 用戶端在請求首部Authorization資訊中加入使用者名密碼等資訊,以及通過質詢碼計算出的響應碼(計算方法比較複雜,具體詳見RFC2617)

SSL用戶端認證

結合第七章HTTPS的安全性來講,SSL需要購買證書。

SSL的認證是保證通訊過程的安全,防止通過form表單送出的密碼等資訊被監聽。

基于表單認證

這是我們最常用的,就是使用者名密碼登入認證;

  1. 用戶端發送使用者名密碼;
  2. 服務端驗證通過,在服務端儲存的sessionID,用于表示是哪個用戶端,并将sessionID發送給用戶端;
  3. 用戶端收到sessionID儲存到cookie中,下次請求直接發送cookie中的sessionID,而不用在輸入密碼了。(如果别人知道你的sessionID,也就可以通過該sessionID擷取你的資訊了,是以,sessionID大多都有過期時間)。

第九章 基于HTTP的功能追加協定

HTTP協定自

HTTP/1.1

之後,這麼多年一直都在用1.1版本,第九章主要講在HTTP協定基礎之上的改進。

SPDY

Google在2010年釋出,旨在解決HTTP的性能問題,縮短Web頁面的加載時間(50%)。

HTTP的瓶頸在于每次請求,頁面都要整體重新整理一遍,有時僅僅在于隻改動一點點。基于此,有了Ajax技術。

Ajax(Asynchronous JavaScript and XML,異步JS和XML),本質值用戶端局部請求服務端,進而局部重新整理頁面,提高使用體驗。

Comet,與Ajax相反,Comet是服務端向用戶端發送變化的資料。

SPDY是在會話層的網絡協定,HTTP是在應用層。具體對協定做了一些改動進而提高性能。

使用浏覽器進行全雙工通信的WebSocket

WebSocket主要能夠實作Web浏覽器和Web伺服器之間的全雙通通信,支援推送功能,減少通信量。

HTTP/2.0

HTTP/2.0的目标改善使用者在使用Web時的速度體驗。

在HTTP/1.1的基礎上,新添加或修改了一些網絡協定。

第十章 建構Web内容的技術

HTML,CSS,JavaScript渲染頁面,Java Servlet或者PHP做Web背景應用。

第十一章 Web的攻擊技術

第十一章簡單介紹了攻擊Web伺服器的技術手段,以及攻擊造成的影響。

  1. 攻擊伺服器,通過SQL注入,或者OS指令注入,擷取伺服器資料。
  2. 攻擊用戶端,給使用者發送誘導陷阱的郵件或者網頁,進而擷取使用者的cookie(結合第八章,基于表單的驗證,就知道cookie被别人知道有多可怕)。

具體的攻擊方法檢視書吧。

繼續閱讀