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

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

應(yīng)用層，表示層，會話層，傳輸層，網(wǎng)絡(luò)層，數(shù)據(jù)鏈路層，物理層

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

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

HTTP狀態(tài)碼

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

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

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

參考資料 HTTP狀態(tài)碼302、303和307的故事

HTTP報文組成(部分)：

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

HTTP報文淺析
HTTP 實體和編碼

根據(jù)是否需要向服務(wù)器重新發(fā)起HTTP請求將緩存過程分為兩個部分，分別是強制緩存和協(xié)商緩存 。

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

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

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

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

其中Etag / If-None-Match的優(yōu)先級比Last-Modified / If-Modified-Since高。

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

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

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

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

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

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

協(xié)議網(wǎng)關(guān)負(fù)責(zé)將一個協(xié)議轉(zhuǎn)成另一個協(xié)議，常見的有HTTP/FTP、HTTP/HTTPS、HTTPS/HTTP。

資源網(wǎng)關(guān)負(fù)責(zé)HTTP請求與服務(wù)端應(yīng)用轉(zhuǎn)換，最流行的協(xié)議是CGI（輸入請求，轉(zhuǎn)交，響應(yīng)），為避免每條CGI請求新開進(jìn)程，出現(xiàn)了FastCGI作為持久守護(hù)進(jìn)程。

隧道負(fù)責(zé)讓HTTP應(yīng)用訪問非HTTP協(xié)議的程序。通過CONNECT方法請求隧道網(wǎng)關(guān)創(chuàng)建一條到達(dá)任意目的服務(wù)器端口的TCP鏈接，并對客戶端和服務(wù)器之間的后續(xù)中繼數(shù)據(jù)進(jìn)行盲轉(zhuǎn)發(fā)。

中繼負(fù)責(zé)處理HTTP中建立連接的部分，然后對字節(jié)進(jìn)行盲轉(zhuǎn)發(fā)。

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

# this robots.txt allows Slurp & Webcrawler to crawl

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

User-Agent: *
Disallow:

拒絕爬蟲方法2：robot-control標(biāo)簽
index|follow|noarchive|all|none

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

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

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

數(shù)字證書結(jié)構(gòu)：版本號，序列號，簽名算法，頒發(fā)者，有效期，對象名稱，公開秘鑰，其他擴展信息，數(shù)字簽名。

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

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

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

HTTP/1 缺點總結(jié)

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

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

header壓縮：HTTP2.0使用encoder來減少需要傳輸?shù)膆eader大小，通訊雙方各自cache一份header fields表，既避免了重復(fù)header的傳輸，又減小了需要傳輸?shù)拇笮　?/p>

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

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