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

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

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

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

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

HTTP狀態(tài)碼

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

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

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

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

HTTP報(bào)文組成(部分)：

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

HTTP報(bào)文淺析
HTTP 實(shí)體和編碼

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

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

控制強(qiáng)制緩存的字段分別是Expires和Cache-Control。到了HTTP/1.1，Expire已經(jīng)被Cache-Control替代，原因在于Expires控制緩存的原理是使用客戶端的時(shí)間與服務(wù)端返回的時(shí)間做對(duì)比，那么如果客戶端與服務(wù)端的時(shí)間因?yàn)槟承┰颍ɡ鐣r(shí)區(qū)不同；客戶端和服務(wù)端有一方的時(shí)間不準(zhǔn)確）發(fā)生誤差。所以同時(shí)存在時(shí)，只有Cache-Control生效。

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

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

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

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

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

Nagle算法鼓勵(lì)發(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報(bào)文在Internet上最長(zhǎng)生存時(shí)間，每個(gè)具體的TCP實(shí)現(xiàn)都必須選擇一個(gè)確定的MSL值。RFC1122建議是2分鐘。超過該數(shù)值會(huì)有TIME_WAIT累積與端口耗盡問題。

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

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

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

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

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

拒絕爬蟲方法1：域名更目錄放robots.txt，爬蟲會(huì)根據(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

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

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

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

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

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

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

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

HTTP/1 缺點(diǎn)總結(jié)

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

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

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

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

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