最近看了《圖解HTTP》，整理一番，僅整理關鍵知識點
計算機與網絡設備通信和人與人通信一樣，也需要有規則，也即協議。協議中存在着各種各樣的內容，從電纜規則到IP地址選定方法，尋找異地用戶的方法，雙方建立通信的順序，以及WEB頁面顯示需要處理的步驟等
TCP/IP協議是與互聯網相關聯的各類協議族的總稱
TCP/IP協議分成四層：應用層、傳輸層、網絡層、數據鏈路層
層次化的好處是如果有地方要改變設計時，只需要把變動的層更改掉，而不必把所有整體更改
同時，層次化之后，每個層級只考慮分派給自己的任務，而不需要搞清楚其他層次的功能，功能分立，各層之間接口規划好，使每層的設計更加簡單和專注，這也是一種設計思想
TCP/IP協議各層的作用如下：
應用層決定了向用戶提供應用服務時通信的活動，比如HTTP協議、FTP（文本傳輸協議）和DNS（域名系統）服務
傳輸層對上層應用層，提供處於網絡連接中的兩台計算機之間的數據傳輸，TCP協議和UDP協議在傳輸層
網絡層用來處理在網絡上流動的數據包，數據包時網絡傳輸的最小單位，該層規定了通過怎樣的路徑到達對方計算機，並把數據包傳給對方，IP協議
鏈路層用來處理連接網絡的硬件部分，包括控制操作系統、網卡、光纖等物流可見部分，硬件的范疇均在鏈路層的作用范圍之內
利用TCP/IP協議進行網絡通信時，會通過分層順序與對方進行通信，發送端從應用層向下走，接收端則從應用端向上走（兩端相對接的是鏈路層）
發送端在層與層之間傳輸數據時，每經過一層時必定會打上一個該層的首部信息
反之接收端在層與層傳輸數據時，每經過一層時會把對應的首部消去
這種把數據信息包裝起來的做法稱為封裝
詳細描述下與HTTP協議關系密切的協議：IP、TCP、DNS
負責傳輸的IP協議：
IP協議位於網絡層，作用是把各種數據包傳給對方，確定傳送成功要滿足兩個重要條件：IP地址和MAC地址
IP地址指明了節點被分配的地址，MC地址是指網卡所屬的固定地址（即物理地址），IP地址可以MAC地址進行配對，IP地址可變換，但是MAC地址基本上不會更改
延申：ARP協議，是一種用於解析地址的協議，根據通信方的IP地址可以反查出對應的MAC地址
確保可靠的TCP協議：
TCP位於傳輸層，提供可靠的字節流服務，可靠是指能夠確認數據是否正常交付，字節流服務是指將大塊數據分割成報文端為單位的數據包進行管理
為了確保數據能到達目標，TCP協議采用了三次握手策略，握手過程中使用了TCP的標志：SYN和ACK
發送端首先發送一個帶有SYN標志的數據包給對方，接收端收到后回傳一個帶有SYN/ACK標志的數據包以標識傳達確認信息，最后發送端再回傳一個帶ACK標志的數據包，代表握手結束。
如果握手過程中中斷，TCP協議會以相同順序再次發送相同的數據包，TCP還有別的手段確保通信可靠性
負責域名解析的DNS協議：
DNS服務和HTTP協議一樣位於應用層，提供域名到IP地址之間的解析服務
主機名或者域名訪問對方計算機對人類來說更具有易讀性，但對於計算機來說更擅長數字，為了解決這一問題，DNS服務出現了
DNS服務提供通過域名查找IP地址，或逆向從IP地址反查域名的服務
那么綜合以上，我們可以了解到IP協議、TCP協議和DNS再使用HTTP協議進行通信中所發揮的作用，引申我們就可以了解
從瀏覽器輸入一個域名后到頁面渲染的整個過程也就是：
1-DNS域名解析
DNS服務將域名解析為IP地址，具體過程是先檢查瀏覽器緩存有無這個域名對應的IP地址，如果沒有，會檢查操作系統的hosts文件、以及路由器緩存，如果還是沒有命中，瀏覽器會請求本地域名服務器去解析，本地服務器一般是接入的網絡服務商提供的
如果本地服務器緩存內沒有，並且也沒辦法解析，會繼續向根服務器發起請求解析，根域名服務器未查到則返回一個頂級域名服務器的地址，本地服務器向頂級域名服務器發起請求，頂級域名服務器返回給本地服務器這個域名的解析服務器地址，本地服務器向域名解析服務器發起請求，這時就能收到域名和IP地址的對應關系，本地域名服務器將結果保存到緩存中，並返回結果給客戶端
客戶端得到目標服務器的IP地址和端口號
2-應用層：瀏覽器生成一個針對目標服務器的HTTP請求報文
3-傳輸層：通過三次握手建立TCP連接，TCP協議將HTTP請求報文分割成報文段
4-網絡層：將報文段打包，通過ARP協議搜索地址后發送
5-鏈路層：根據以太網協議將數據分成幀，進行發送
6-服務端收到數據是逆轉過來解包，重組報文端，從鏈路層到應用層， 獲得HTTP請求，請求結果也是同樣里用TCP/IP協議進行回傳
第六步引申：
假如服務器配置了 HTTP 重定向，就會返回一個 301永久重定向響應，瀏覽器就會根據響應，重新發送 HTTP 請求（重新執行上面的過程）
URI：統一資源標識符
某個協議方案表示的資源的定位標識符，協議方案可以是https、http、ftp等
絕對url的完整格式
http://user:pass@www.example.jp:80/dir/index.htm?uid=1#ch=1
協議方案名：//登錄信息@服務器地址：服務器端口號/帶層次的文件路徑?查詢字符串#片段標識符
登錄信息可選、服務器端口號可選（不寫用默認端口）、查詢字符串和片段標識符都是可選項
HTTP協議和TCP/IP協議族的其他眾多協議一樣，用於客戶端和服務端之間的通信。
請求訪問資源的一端稱為客戶端，提供資源響應的一端為服務端，如果僅對於一條通信線路而言，客戶端和服務端的角色是固定的。
請求報文：請求訪問某個頁面資源，由請求方法、請求URI、協議版本、可選的請求首部字段和內容實體構成
響應報文：服務器講處理結果以響應的的形式返回，由協議版本、狀態碼、用於解釋狀態碼的原因短語、可選的響應首部字段以及實體主題構成
HTTP/1.1中可用的方法
- GET：獲取資源
- POST：傳輸實體的主體
- PUT：傳輸文件，HTTP自身的PUT方法不帶驗證機制，所以一般WEB網站不使用該方法，除非加上驗證機制或者REST標准下
- HEAD：獲取報文首部，和GET方法一樣，但是不返回報文實體
- DELETE：刪除文件，與PUT相反的方法，方法本身無驗證機制，所以一般也不使用，除非加上驗證機制或者REST標准下
- OPTIONS：詢問支持的方法
- TRACE：追蹤路徑，不常用
關於持久連接：
HTTP協議最初的版本，是每進行一次HTTP通信就要斷開一次TCP鏈接，逐漸無法滿足較多資源的情況，會增加通信量的開銷
為解決這一問題，HTTP/1.1 引入了持久連接，即HTTP keep-alive
持久連接的特點是只要任意一端沒有明確提出斷開狀態，則保持TCP連接狀態
持久連接的好處：減少了TCP重復建立和斷開所造成的額外開銷，減輕了服務端的負載，同時減少了開銷的時間后，使HTTP請求和響應能更快結束，頁面顯示速度也更快
HTTP是無狀態協議，HTTP協議自身不保存請求和響應之間的通信狀態，優點是減少服務器的CPU和內存資源的消耗，簡單快速
但是隨着WEB的不斷發展，比如一個用戶登錄到一個網站上，跳轉到其他頁面后也需要保持登錄態，因此網站此時需要掌握是誰發出的請求，保存用戶的狀態。
為了HTTP協議能夠實現保存狀態功能，引入了Cookie技術
Cookie技術通過在請求和響應報文中寫入 Cookie 信息來控制客戶端的狀態
Cookie會根據服務端發出的響應報文的Set-Cookie首部字段信息，通知客戶端保存Cookie，值就是Set-Cookie的內容，當下次客戶端再向服務器發送請求時，會自動在請求報文中加入Cookie值后發出
服務器收到Cookie后，會先去檢查是哪個客戶端發過來的連接請求，然后對比服務器上的記錄，如沒有則保存，如果有就可以得到之前的狀態信息
總結上面就是：客戶端發送請求后，服務端響應報文的Set-Cookie首部字段會帶入一些信息，客戶端保存這些信息，在下次請求時放在請求報文的Cookie首部字段里，服務端收到新請求后對比之前保存的Cookie信息確認狀態
（從這里可以理解我們的jmeter如何去獲取Cookie值的，先首次調用登錄接口，然后用一個提取器去獲取到返回結果的header里Set-Cookie里的字段，用正則表達式去篩選出想要的字段，放到統一cookie管理器中，下次接口請求時就會發出cookie了，從而用jmeter實現了長連接）
（Cookie不一定只有一個字段，可能有很多個字段信息key-value對應）
（注意分清header和body，首部字段都在header里，內容在body里）
用於HTTP協議交互的消息被稱為HTTP報文，分為請求報文（客戶端發出）、響應報文（服務端發出），本身是由多行數據構成的字符串文本
HTTP大致分為報文首部和報文主體，通常並不一定要有報文主體
- 報文首部：內容及屬性，即請求行or狀態行+首部字段 即request headers
- 報文主體：應被發送的數據 即request body
其中報文首部具體又細分為：
- 請求行：請求方法、請求URI、HTTP版本
- 狀態行：表明響應結果的狀態碼，短語和HTTP版本
- 首部字段：表明請求和響應的各種條件和屬性的各類首部，請求/響應請求首部字段=通用首部字段+請求/響應首部字段+實體首部字段
狀態碼告知從服務器返回的請求結果，由三位數字和原因短語組成
- 2XX 請求被正常處理 200 OK請求被正常處理；204 No Content 請求處理成功但無資源可以返回；206 服務端處理了客戶端發起的范圍請求
- 3XX 重定向 301 永久性重定向；302 Found 臨時性重定向；304 Not Modified 服務器資源未改變，可以使用客戶端緩存
- 4XX 客戶端錯誤 400 請求報文存在語法錯誤；401 請求需要被認證或者認證失敗；403 請求資源訪問被服務器拒絕，多見於未獲得授權時
- 5XX 服務器錯誤 500 服務端在執行請求時發生錯誤；503服務器現在無法處理請求，可能處於停機或者超負載狀態
第六章、HTTP首部
綜上所述，HTTP請求報文由方法、URI、HTTP版本、HTTP首部字段(以上報文首部)、報文主體組成
HTTP響應報文由HTTP版本、狀態碼、HTTP首部字段（以上報文首部）、報文主體組成
首部字段是為了給客戶端和服務器提供報文主體大小、所使用的語言、認證信息等內容
常見的一些首部字段列舉：
首部字段名：字段值
通用首部字段：
| 首部字段名 | 說明 | 字段值舉例 |
| Cache-Control [kæʃ] | 控制緩存的行為 | no-cache 不緩存過期內容；no-store 不緩存任何內容 |
| Connection | 連接管理 | keep-alive 長連接 |
| Date | 創建報文日期時間 | Wed, 07 Jul 2021 08:32:27 GMT |
| Pragma | 報文指令 | no-cache 和第一個一起用，保證所有HTTP版本都不返回緩存 |
| Trailer | 報文之后后記錄的首部字段 | Expries 報文主體之后出現了首部字段Expries |
| Transfer-Encoding | 指定報文主體的傳輸編碼方式 | |
| Upgrade | 升級為其他協議 | 比如WebSocket |
| Via | 代理服務器的相關信息 | |
| Warning | 錯誤通知 |
請求首部字段：
| 首部字段名 | 說明 | 字段值舉例 |
| Accept | 可處理的媒體類型 | application/json, text/plain, */* |
| Accept-Charset | 優先字符集 | |
| Accept-Encoding | 優先的內容編碼 | gzip |
| Accept-Language | 優先的語言 | zh-CN,zh;q=0.9 |
| Authorization | Web認證信息 | |
| Expect | 期待服務器特定行為 | |
| From | 用戶的電子郵箱地址 | |
| Host | 請求資源的所在服務器 | |
| Referer | 原始的請求方URI | 一般精確到/path |
| User-Agent | HTTP客戶程序的信息 | |
| Cookie | 開始狀態管理時，客戶端向服務器傳的cookie信息 |
響應首部字段：
| 首部字段名 | 說明 | 字段值舉例 |
| Accept-Ranges | 是否接受字節范圍請求 | |
| Location | 令客戶端重定向制定URI | |
| Server | 當前服務器的安裝信息 | |
| Vary | 代理服務器緩存的管理信息 | |
| Set-Cookie | Cookie 服務器接收到的Cookie信息 |
實體首部字段：
| 首部字段名 | 說明 | 字段值舉例 |
| Allow | 資源可支持的HTTP方法 | |
| Content-Encoding | 實體主體適用的編碼方式 | |
| Content-Language | 實體主體適用的編碼方式 | |
| Content-Length | 實體主體的大小 | |
| Content-Location | 實體主體的大小 | |
| Content-MD5 | 實體主體的報文摘要 | |
| Content-Range | 實體主體的位置范圍 | |
| Content-Type | 實體主體的媒體類型 | application/json; charset=UTF-8 |
| Expires | 實體主體過期的日期時間 | Thu, 01 Jan 1970 00:00:00 GMT |
| Last-Modified | 資源的最后修改日期時間 |
第七章：HTTPS
HTTP的優點：無連接無狀態，簡單快捷靈活
HTTP的缺點：不加密的協議，明文通信，可能會被竊聽；不驗證通信雙方身份，可能會被偽裝；不嚴重報文完整性，有可能被篡改
HTTPS是披着SSL外殼的HTTP，擁有加密、證書和完整性保護功能
使用SSL時，HTTP先和SSL通信，再由SSL和TCP通信
SSL采用公開密鑰加密的加密處理方式，發送方使用對方的公開密鑰進行加密處理，對方收到后使用自己的私有密鑰進行解密
HTTPS的缺點：消耗更多的CPU以及內存資源，所以敏感數據才使用；CA證書購買要付費
第九章、基於HTTP的功能追加協議
為了處理一些HTTP的瓶頸問題，產生的協議，這里單獨說一下webSocket協議
一旦web服務器與客戶端之間建立起WebSocket協議的通信鏈接，之后所有的通信都依賴這個專用協議進行，通信過程中可以互相發送任意格式的數據
第十章、構建Web內容的技術
HTML
HTML（HyperText Markup Language，超文本標記語言）是為了發送 Web 上的超文本（Hypertext）而開發的標記語言。
超文本是一種文檔 系統，可將文檔中任意位置的信息與其他信息（文本或圖片等）建立 關聯，即超鏈接文本。
標記語言是指通過在文檔的某部分穿插特別的字符串標簽，用來修飾文檔的語言。我們把出現在 HTML文檔內的這種特殊字符串叫做 HTML標簽（Tag）。
平時我們瀏覽的 Web 頁面幾乎全是使用 HTML寫成的。由 HTML構 成的文檔經過瀏覽器的解析、渲染后，呈現出來的結果就是 Web 頁面。
CSS（Cascading Style Sheets，層疊樣式表）可以指定如何展現 HTML 內的各種元素，屬於樣式表標准之一。
即使是相同的 HTML文檔， 通過改變應用的 CSS，用瀏覽器看到的頁面外觀也會隨之改變。CSS 的理念就是讓文檔的結構和設計分離，達到解耦的目的。
第十一章、Web攻擊技術
SQL注入攻擊
OS命令注入攻擊
HTTP首部注入攻擊
密碼破解，有以下兩種手段：通過網絡的密碼試錯；對已加密密碼的破解，還有SQL注入攻擊逃避認證，跨站腳本攻擊竊取密碼信息等方法
通過網絡的密碼試錯，主要有兩種方法：窮舉法和字典攻擊。窮舉法從現實角度可能會花費數年時間
字典攻擊時指利用事先收集好的候選密碼，枚舉字典中的密碼，嘗試通過驗證，比如生日做密碼可以把生日數值化保存成字典，進行嘗試；或者利用別處泄露的ID密碼進行攻擊
對已加密密碼的破解，web在保存密碼時一般不會以明文的方式保存，通過散列函數（MD5）做散列處理或者加salt的手段對要保存的密碼本身加密，攻擊者使用某些手段獲取到密碼數據后，要通過解碼等手段，把加密處理的密碼還原成明文形式
后門程序（Backdoor），開發設置的隱藏入口