摘要：和是新加的，是對原狀態碼的細化。規定處理應是重定向為，處理應該是重定向為不一定是非請求即可和的存在，歸根結底是由于方法的非冪等屬性引起的。所以同時存在時，只有生效。超過該數值會有累積與端口耗盡問題。

本文梳理本人閱讀《HTTP權威指南》遇到的相關問題與相關解答。若有錯誤請指正。

應用層，表示層，會話層，傳輸層，網絡層，數據鏈路層，物理層

<方案>://<用戶>:<密碼>@<主機>:<端口>/<路徑>;<參數>?<查詢>#<片段>

如果<標簽>內有保留受限字符（比如密碼有@），這些可通過encodeURIComponent轉義。
DNS解析過程詳解
為什么域名根服務器只能有13臺呢？Avery Lu

HTTP狀態碼

【1】HTTP1.0(RFC1945)和HTTP1.1(RFC2616)對302的定義相同：如果客戶端發出POST請求后，收到服務端的302狀態碼，那么不能自動的向新的URI發送重復請求，必須跟用戶確認是否該重發，因為第二次POST時，環境可能已經發生變化（POST方法不是冪等的），POST操作會不符合用戶預期。

【2】303和307是HTTP1.1新加的，是對原302狀態碼的細化。HTTP1.1規定303處理應是：POST重定向為GET，307處理應該是：POST重定向為POST（不一定是POST,非GET、HEAD請求即可）303和307的存在，歸根結底是由于POST方法的非冪等屬性引起的。

【3】但是瀏覽器實現HTTP1.0的302二次請求POST時未詢問用戶的情況下就變成GET（相當于303）

參考資料 HTTP狀態碼302、303和307的故事

HTTP報文組成(部分)：

- 起始行
 - 請求起始行：方法 URL HTTP版本
 - 響應起始行：HTTP版本 狀態碼 原因短語
- 首部
 - 通用首部： Date:Tue, 3 Oct 1974 02:16:00 GMT
   通用緩存首部：  Cache-Control
 - 請求首部： Accept:*/*
            From
            Host
            Referer
            User-Agent
   條件請求首部： If-Modified-Since
                If-Match
   安全請求首部: Cookie
               Authorization
            ...
 - 響應首部: Server:cloudflare-nginx
 - 實體首部: Content-Type:text/html;charset-iso-latin-1
    內容首部： Content-Length
    實體緩存首部：ETag
                Expires：Fri, 01 Mar 2019 13:37:39 GMT
                Cache-Control:max-age=600
                Last-Modified：在服務器最后被修改的時間
 - 擴展首部
- 主體

HTTP報文淺析
HTTP 實體和編碼

根據是否需要向服務器重新發起HTTP請求將緩存過程分為兩個部分，分別是強制緩存和協商緩存 。

有3種：
1.不存在該緩存結果和緩存標識，強制緩存失效，則直接向服務器發起請求
2.存在該緩存結果和緩存標識，但該結果已失效，強制緩存失效，則使用協商緩存
3.存在該緩存結果和緩存標識，且該結果尚未失效，強制緩存生效，直接返回該結果

控制強制緩存的字段分別是Expires和Cache-Control。到了HTTP/1.1，Expire已經被Cache-Control替代，原因在于Expires控制緩存的原理是使用客戶端的時間與服務端返回的時間做對比，那么如果客戶端與服務端的時間因為某些原因（例如時區不同；客戶端和服務端有一方的時間不準確）發生誤差。所以同時存在時，只有Cache-Control生效。

瀏覽器的緩存存放在哪:
內存緩存(from memory cache)：js和圖片等
硬盤緩存(from disk cache)：css文件

有2種：
1.協商緩存生效，返回304
2.協商緩存失效，返回200和請求結果
控制協商緩存的字段分別有：
Last-Modified / If-Modified-Since
服務端返回last-modified即最后修改時間，客戶端下次發送if-modified-since(時間)后服務器比對。
Etag / If-None-Match
服務端返回Etag即唯一標識，客戶段下次發送If-None-Match(標識)后服務器比對。

其中Etag / If-None-Match的優先級比Last-Modified / If-Modified-Since高。

no-store;(禁止保存臨時文件，保護機密信息)
no-cache;(1.0的鍵名是Pragma，1.1是Cache-Control；在釋放緩存之前，強制高速緩存將請求原始服務器驗證。)
must-revalidate;(緩存必須在使用之前驗證舊資源的狀態，并且不可使用過期資源。)
max-age;(相對秒)
expries;(絕對日期時間)
參考：Cache-Control-MDN

TCP收到HTTP報文數據流后分段成IP分組，IP分組包括：
IP分組首部(20B)+TCP段首部(20B)+TCP數據塊(0+B)

Nagle算法鼓勵發送最大傳輸單元(MTU：1500B)，但確認分組延遲確認要等100-200ms。(為什么MTU值普遍都是1500？)
TCP_NODELAY方法即可禁用Nagle(nodejs默認開啟)

socket.setNoDelay([noDelay])
request.setNoDelay([noDelay])

MSL(最大分段生存期)指明TCP報文在Internet上最長生存時間，每個具體的TCP實現都必須選擇一個確定的MSL值。RFC1122建議是2分鐘。超過該數值會有TIME_WAIT累積與端口耗盡問題。

HTTP/1.0+"Connection:keep-alive"節省了打開鏈接和關閉鏈接的開銷。
HTTP/1.1持久鏈接默認激活（前提：主體部分長度與Content-Length一致或分塊傳輸編碼），除非客戶端發送報文有Connection:close。
HTTP/1.1允許在持久鏈接上使用請求管道，在響應到達之前可將多條請求放入隊列，降低網絡環回時間。（客戶端不應在管道上發送POST這樣非冪等請求，因為出錯無法安全重試）

協議網關負責將一個協議轉成另一個協議，常見的有HTTP/FTP、HTTP/HTTPS、HTTPS/HTTP。

資源網關負責HTTP請求與服務端應用轉換，最流行的協議是CGI（輸入請求，轉交，響應），為避免每條CGI請求新開進程，出現了FastCGI作為持久守護進程。

隧道負責讓HTTP應用訪問非HTTP協議的程序。通過CONNECT方法請求隧道網關創建一條到達任意目的服務器端口的TCP鏈接，并對客戶端和服務器之間的后續中繼數據進行盲轉發。

中繼負責處理HTTP中建立連接的部分，然后對字節進行盲轉發。

拒絕爬蟲方法1：域名更目錄放robots.txt，爬蟲會根據它做選擇。

# this robots.txt allows Slurp & Webcrawler to crawl

User-Agent: slurp
User-Agent: webcrawler
Disallow: /private
Allow: /public

User-Agent: *
Disallow:

拒絕爬蟲方法2：robot-control標簽
index|follow|noarchive|all|none

對稱秘鑰加密即編解碼使用相同秘鑰，如DES,3-DES,RC2,RC-4。缺點是發送者和接收者對話前要存有該秘鑰。

公開秘鑰加密使用非對稱秘鑰：客戶端持公開秘鑰，服務端持私有秘鑰。避免了上述對稱秘鑰的缺點。如RSA。

對報文使用非對稱秘鑰數字簽名，可以證明作者和防止篡改。

數字證書結構：版本號，序列號，簽名算法，頒發者，有效期，對象名稱，公開秘鑰，其他擴展信息，數字簽名。

OpenSSL是SSL和TLS協議以及一個全功能通用加密庫的開源實現。

SSL握手需要做的工作：
交換協議版本號；選擇一個兩端都了解的密碼；對兩端的身份進行認證；生成臨時會話秘鑰，以便加密信道。

SSL握手過程：
1.客戶端發送可選擇的密碼并請求證書
2.服務器發送選中的密碼和證書
3.客戶端發送保密信息，客戶端和服務器生成秘鑰。
4.客戶端和服務器互相告知，開始加密過程。

HTTP/1 缺點總結

二進制：HTTP1.x的解析是基于文本。文本的表現形式有多樣性，而二進制實現方便且健壯。

多路復用：即連接共享，即每一個request都是是用作連接共享機制的。一個request對應一個id，這樣一個連接上可以有多個request，每個連接的request可以隨機的混雜在一起，接收方可以根據request的 id將request再歸屬到各自不同的服務端請求里面。

header壓縮：HTTP2.0使用encoder來減少需要傳輸的header大小，通訊雙方各自cache一份header fields表，既避免了重復header的傳輸，又減小了需要傳輸的大小。

服務端推送：例如客戶端收到sytle.css數據的同時，服務端會將sytle.js的文件推送給客戶端，當客戶端再次嘗試獲取sytle.js時就可以直接從緩存中獲取到。

瀏覽器輸入 URL 后發生了什么？
HTTPS加密協議詳解(四)：TLS/SSL握手過程