第一章、HTTP概述
1、Web瀏覽器、服務(wù)器和相關(guān)的Web應(yīng)用程序都是通過HTTP相互通信的，HTTP是現(xiàn)代全球因特網(wǎng)中使用的公共語言。
2、Web服務(wù)器回味所有HTTP對(duì)象數(shù)據(jù)附加一個(gè)MIME類型，MIME類型時(shí)一種文本標(biāo)記，表示一種主要的對(duì)象類型和一個(gè)特定的子類型，中間為一條斜杠來分割。（Content-type：image/jpeg）
3、服務(wù)器資源名被稱為統(tǒng)一資源標(biāo)識(shí)符（URI），有兩種形式：1、URL統(tǒng)一資源定位符，由三部分組成：方案（http：//），服務(wù)器的因特網(wǎng)地址（www.XXXX.com）以及服務(wù)器某個(gè)資源（/special/test.jpg）；2、URN統(tǒng)一資源名（仍處于試驗(yàn)階段）
4、一條HTTP事務(wù)由一條請(qǐng)求命令和一個(gè)響應(yīng)結(jié)果組成。
5、Telnet程序可以很好的模擬HTTP客戶端，但不能作為服務(wù)器使用。
6、代理位于客戶端和服務(wù)器之間，接收所有客戶端的HTTP請(qǐng)求，并將這些請(qǐng)求轉(zhuǎn)發(fā)給服務(wù)器。
7、Web緩存或代理緩存是一種特殊的HTTP代理服務(wù)器，可以將經(jīng)過代理傳送的常用文檔復(fù)制保存起來。下一個(gè)請(qǐng)求同一個(gè)文檔的客戶端就可以享受緩存的私有副本所提供的服務(wù)了。
8、網(wǎng)關(guān)是一種特殊的服務(wù)器，作為其他服務(wù)器的中間實(shí)體使用。通常用于將HTTP流量轉(zhuǎn)換成其他的協(xié)議。
9、隧道是建立起來之后，就會(huì)在兩條連接之間對(duì)原始數(shù)據(jù)進(jìn)行盲轉(zhuǎn)發(fā)的HTTP應(yīng)用程序。HTTP隧道通常用來在一條或多條HTTP連接上轉(zhuǎn)發(fā)非HTTP數(shù)據(jù)，轉(zhuǎn)發(fā)時(shí)不會(huì)窺探數(shù)據(jù)。
10、用戶Agent代理時(shí)代表用戶發(fā)起HTTP請(qǐng)求的客戶端程序。所有發(fā)布Web請(qǐng)求的應(yīng)用程序都是HTTP Agent代理，如：瀏覽器。
第二章、URL與資源
1、URI是一類更通用的資源標(biāo)識(shí)符，URL實(shí)際上是它的一個(gè)子集.URI是
一個(gè)通用的概念，有兩個(gè)主要的子集URL和URN構(gòu)成。
? ? ? ? 2、大多數(shù)URL方案的URL語法都建立在這個(gè)由9部分構(gòu)成的通用格式上：
<scheme>：//<user>:<password>@<host>:<port>/<path>;<param>?<query>#<frag>
? ? ? ? 但幾乎沒有哪個(gè)URL包含了所有這些組件，最重要的還是3個(gè)部分，方案（scheme），主機(jī)（host）和路徑（path），至于9部分詳細(xì)介紹如下：
? ? ? ? 方案（scheme）：就是使用了什么協(xié)議。
? ? ? ? 主機(jī)（host）：主機(jī)名或者ip地址
端口（port）：標(biāo)識(shí)了服務(wù)器正在監(jiān)聽的網(wǎng)絡(luò)端口，TCP的HTTP默認(rèn)80
用戶名(user)和密碼(password)：有一些服務(wù)器需要輸入用戶名和密碼才能用戶訪問數(shù)據(jù)，比如FTP服務(wù)器。
路徑（path）:可以用“/”將HTTP的URL路徑劃分為一些路徑段。
參數(shù)（param）：為了向應(yīng)用程序提供它們所需的輸入?yún)?shù)，URL有一個(gè)參數(shù)組件，就是URL中的名值對(duì)列表，有“；”將其與URL的其余部分分隔開，如：http://www.prep.ai.mit.com/pub/gnu;type=d/index.html;sale=false
查詢字符串(query)：很多資源，比如數(shù)據(jù)庫服務(wù)，就是通過提問題或進(jìn)行查詢來縮小所請(qǐng)求資源類型范圍的。http://www.prep.ai.mit.com/get?item=12
片段(frag):為了引用部分資源或資源的一個(gè)片段。（但服務(wù)器通常只處理整個(gè)對(duì)象，所以瀏覽器從服務(wù)器獲得了整個(gè)資源之后，會(huì)根據(jù)片段來顯示你感興趣的那部分資源）
第三章、HTTP報(bào)文
1、HTTP報(bào)文是簡單的格式化數(shù)據(jù)塊。每條報(bào)文包含一條來自客戶端的請(qǐng)求，或者一條來自服務(wù)器的響應(yīng)。它們由三個(gè)部分組成：對(duì)報(bào)文進(jìn)行描述的起始行、包含屬性的首部塊、以及可選的、包含數(shù)據(jù)的主體部分。
2、HTTP報(bào)文分為：請(qǐng)求報(bào)文和響應(yīng)報(bào)文。
請(qǐng)求報(bào)文的格式如下：
<method> <request-URL> <version>
<headers>
<entity-body>
響應(yīng)報(bào)文的格式如下：
<version> <status > <reason-phrase>
<headers>
<entity-body>
注：各部分的簡要描述如下：
Method：客戶端希望服務(wù)器對(duì)資源執(zhí)行的方法，如GET，POST
request-URL：命名了所請(qǐng)求資源的完整URL
version：報(bào)文所使用的HTTO版本
status：描述了請(qǐng)求過程中所發(fā)生的情況，響應(yīng)報(bào)文的數(shù)字狀態(tài)碼
reason-phrase：數(shù)字狀態(tài)碼的可讀版本。
Headers：首部，可以有0或多個(gè)。
entity-body：實(shí)體的主體部分包含一個(gè)由任意數(shù)據(jù)組成的數(shù)據(jù)塊。
3、常用的HTTP方法如下（請(qǐng)求報(bào)文）：
GET：從服務(wù)器獲取一份文檔，不包含主體。
HEAD：只從服務(wù)器獲取文檔的首部，不包含主體
POST：向服務(wù)器發(fā)送需要處理的數(shù)據(jù)，包含主體
PUT：將請(qǐng)求的主體部分存儲(chǔ)在服務(wù)器上，包含主體
TRACE:對(duì)可能經(jīng)過代理服務(wù)器傳送到服務(wù)器上去的報(bào)文進(jìn)行追蹤，不包含主體
OPTIONS：詢問可以在服務(wù)器上執(zhí)行哪些方法，不包含主體
DELETE：從服務(wù)上刪除一份文檔，不包含主體
4、HEAD方法與GET方法的行為很類似，但服務(wù)器在響應(yīng)中只返回首部。這允許客戶端在未獲取實(shí)際資源情況下，對(duì)資源的首部進(jìn)行檢查?？梢栽谝韵虑闆r使用：
（1）在不獲取資源的情況下了解資源的情況
（2）通過查看響應(yīng)中的狀態(tài)碼，看看某個(gè)對(duì)象是否存在
（3）通過查看首部，測試資源是否被修改了
注意：服務(wù)器開發(fā)者必須確保返回的首部與GET請(qǐng)求所返回的首部完全相同。
5、與GET從服務(wù)器讀取文檔相反，PUT方法會(huì)向服務(wù)器寫入文檔。PUT方法的語義就是讓服務(wù)器用請(qǐng)求的主體部分來創(chuàng)建一個(gè)由所請(qǐng)求的URL命名的新文檔，或者，如果那個(gè)URL已經(jīng)存在的話，就用這個(gè)主體來替代它。
6、TRACE方法允許客戶端在最終將請(qǐng)求發(fā)送給服務(wù)器時(shí)，看看它變成了什么樣子。TRACE請(qǐng)求會(huì)在目的服務(wù)器端發(fā)起一個(gè)“環(huán)回”判斷。行程的最后一站的服務(wù)器會(huì)彈回一條TRACE響應(yīng)，并在響應(yīng)主體中攜帶它收到的原始請(qǐng)求報(bào)文。這樣客戶端就可以查看在所有中間應(yīng)用程序組成的請(qǐng)求/響應(yīng)鏈上，原始報(bào)文是否，以及如何被毀壞或修改過。（TRACE方法主要用于診斷，也就是說用于驗(yàn)證請(qǐng)求是否如愿穿過了請(qǐng)求/響應(yīng)鏈。）
7、OPTIONS方法請(qǐng)求Web服務(wù)器告知其支持的各種功能，可以詢問服務(wù)器通常支持哪些方法，或者對(duì)某些特殊資源支持哪些方法。
8、DELETE方法就是請(qǐng)服務(wù)器刪除請(qǐng)求URL所指定的資源。
9、狀態(tài)碼：
（1）100~199：信息性狀態(tài)碼
客戶端應(yīng)用程序只有在避免向服務(wù)器發(fā)送一個(gè)服務(wù)器無法處理或使用的大實(shí)體時(shí)，才應(yīng)該使用100Continue（在Expect首部設(shè)置）
服務(wù)器也永遠(yuǎn)不應(yīng)該向沒有發(fā)送100Continue期望的客戶端發(fā)送100Continue狀態(tài)碼。
（2）200~299：成功狀態(tài)碼
200 OK：成功處理
201 Created，用于創(chuàng)建服務(wù)器對(duì)象的請(qǐng)求（比如：PUT方法）
202 Accepted，請(qǐng)求你已被接受，但服務(wù)器還未對(duì)其執(zhí)行任何動(dòng)作
203 Non-Authoritative Information，請(qǐng)求已處理，但實(shí)體首部包含的信息不是來自原始服務(wù)器，而是來自資源的副本。
204 No Content：響應(yīng)報(bào)文中包含若干首部和一個(gè)狀態(tài)行，沒有主體。
（3）300~399：重定向狀態(tài)碼
300 Multiple Choices：客戶端請(qǐng)求的一個(gè)實(shí)際指向多個(gè)資源的URL時(shí)會(huì)返回這個(gè)狀態(tài)碼（如DNS重定向）
301 Moved Permanently：在請(qǐng)求的URL已被移除，響應(yīng)的Location包含資源現(xiàn)在所處的新URL
304 Not Modified：資源自上次請(qǐng)求至今，仍未被修改
305 Use Proxy：用來說明必須通過一個(gè)代理來訪問資源
(4)400~499：客戶端錯(cuò)誤狀態(tài)碼
400 Bad Request：告知客戶端它發(fā)送了一個(gè)錯(cuò)誤的請(qǐng)求
401 Unauthorized：需要客戶端認(rèn)證才能獲取對(duì)資源的訪問權(quán)
403 ForBidden：說明請(qǐng)求被服務(wù)器拒絕了。
404 Not Found：服務(wù)器沒有找到所請(qǐng)求的URL
405 Method Not Allowed：發(fā)起的請(qǐng)求帶有服務(wù)器不支持的方法。
406 Not Acceptable：服務(wù)器沒有與客戶端可接受的URL相匹配的資源
（5）500~599：服務(wù)器錯(cuò)誤狀態(tài)碼
500 Internal Server Error:服務(wù)器遇到一個(gè)妨礙它為請(qǐng)求提供服務(wù)的錯(cuò)誤
501 Not Implemented：客戶端發(fā)起的請(qǐng)求超出了服務(wù)器的能力范圍。
503 Service Unavailable:用來說明服務(wù)器現(xiàn)在無法為請(qǐng)求提供服務(wù)，但將來可以
504 Gateway Timeout：超時(shí)，只是這里的響應(yīng)來自一個(gè)網(wǎng)管或者代理。
第四章、連接管理
1、HTTP就是“HTTP over TCP over IP”這個(gè)協(xié)議棧中的最頂層了，其安全版本HTTPS就是在HTTP和TCP之間插入了一個(gè)（稱為TLS或SSL）密碼加密層。
2、TCP就是通過端口號(hào)來保持所有連接持續(xù)不斷地運(yùn)行。
3、TCP數(shù)據(jù)傳輸?shù)男阅苓€取決于TCP連接的使用期。TCP連接會(huì)隨著時(shí)間進(jìn)行自我協(xié)調(diào)，起初會(huì)限制連接的最大速度，如果數(shù)據(jù)成功傳輸，會(huì)隨著時(shí)間的推移提高傳輸?shù)乃俣?，這種協(xié)調(diào)稱為TCP慢啟動(dòng)，用于防止因特網(wǎng)的突然過載和擁塞。
4、最常見的TCP相關(guān)時(shí)延，其中包括
（1）TCP連接建立握手
（2）TCP慢啟動(dòng)擁塞控制
（3）數(shù)據(jù)聚集的Nagle算法
（4）用于捎帶確認(rèn)的TCP延遲確認(rèn)算法
（5）TIME_WAIT時(shí)延和端口耗盡
5、在事務(wù)處理結(jié)束之后仍然保持在打開狀態(tài)的TCP連接被稱為持久連接。重用已對(duì)目標(biāo)服務(wù)器打開的空閑持久連接，就可以避開緩慢的連接建立階段。將持久連接和并行連接配合使用可能是最高效的方式。打開少量的并行連接，其中的每一個(gè)都是持久連接。
6、為了處理啞代理（無法識(shí)別keep-alive首部）導(dǎo)致的問題，可以發(fā)送非標(biāo)準(zhǔn)的Proxy-Connection擴(kuò)展首部，而不是官方支持的Connectio首部。如果代理時(shí)盲中繼，它會(huì)將無意義的Proxy-Connection首部轉(zhuǎn)發(fā)給Web服務(wù)器，服務(wù)器會(huì)忽略該首部，就不建立持久連接。如果代理時(shí)識(shí)別的了這個(gè)首部的，就會(huì)用一個(gè)Connection首部取代無意義的Proxy-Connection首部，然后將其轉(zhuǎn)發(fā)給服務(wù)器，以達(dá)到效果。
7、HTTP1.0只有響應(yīng)中有Connection:Keep-Alive首部，才會(huì)將連接處于打開狀態(tài)，而HTTP1.1則假定所有連接都是持久的，只有Connection：close首部，才會(huì)在事務(wù)處理結(jié)束之后將連接關(guān)閉。
8、一個(gè)用戶客戶端對(duì)任何服務(wù)器或代理最多只能維護(hù)兩條持久連接，以防服務(wù)器過載。
9、關(guān)閉連接的正常做法：實(shí)現(xiàn)正常關(guān)閉的應(yīng)用程序首先應(yīng)該關(guān)閉他們的輸出信道，然后等待連接另一端的對(duì)等實(shí)體關(guān)閉它的輸出信道。當(dāng)兩端都告訴對(duì)方它們不會(huì)再發(fā)送任何數(shù)據(jù)之后，連接就會(huì)被完全關(guān)閉，而不會(huì)有重置的危險(xiǎn)。
第五章、Web服務(wù)器
1、實(shí)際的Web服務(wù)器會(huì)做些什么
（1）接收客戶端連接：如果客戶端已經(jīng)打開了一條持久連接，則直接用這條連接來發(fā)送請(qǐng)求，不然就打開一條新連接。新連接需要先對(duì)客戶端主機(jī)名進(jìn)行反向DNS，以用于詳細(xì)的訪問控制和日志記錄。而服務(wù)器可以通過ident協(xié)議找到發(fā)起HTTP連接的用戶名。
（2）接收請(qǐng)求報(bào)文：Web服務(wù)器會(huì)從網(wǎng)絡(luò)連接中讀取數(shù)據(jù)，并將請(qǐng)求報(bào)文中的內(nèi)容解析出來。
（3）處理請(qǐng)求：根據(jù)方法、資源、首部和可選的主體部分來對(duì)請(qǐng)求進(jìn)行處理。
（4）對(duì)資源的映射及訪問：通過docroot，目錄列表，動(dòng)態(tài)內(nèi)容資源的映射，服務(wù)器端包含項(xiàng)以及訪問控制
（5）構(gòu)建響應(yīng)：構(gòu)建響應(yīng)實(shí)體和確定MIME類型，以及對(duì)需要重定向的資源進(jìn)行重定向
（6）發(fā)送響應(yīng)
（7）記錄日志
第六章、代理
1、代理服務(wù)器可以是某個(gè)客戶端專用的，也可以是很多個(gè)客戶端共享的。單個(gè)客戶端專用的稱為私有代理，眾多客戶共享的稱為公共代理
2、代理連接的是兩個(gè)或多個(gè)使用相同協(xié)議的應(yīng)用程序，而網(wǎng)關(guān)連接的則是兩個(gè)或多個(gè)使用不同協(xié)議的端點(diǎn)。
3、為什么使用代理？因?yàn)榇矸?wù)器可以實(shí)現(xiàn)各種時(shí)髦而有用的功能，他們可以改善安全性，提高性能，節(jié)約費(fèi)用。如下：
（1）兒童過濾器
（2）文檔訪問控制
（3）安全防火墻
（4）Web緩存
（5）反向代理
（6）內(nèi)容路由器
（7）轉(zhuǎn)碼器
4、Via首部字段列出了與報(bào)文途徑的每個(gè)中間節(jié)點(diǎn)（代理或網(wǎng)關(guān)）有關(guān)的信息。響應(yīng)的Via首部基本上總是和請(qǐng)求的Via首部相反。
5、可以用Max-Forwrads首部字段來限制TRACE方法的轉(zhuǎn)發(fā)跳數(shù)，主要Max-Forwrads=0，則無論是否已經(jīng)到達(dá)服務(wù)器都應(yīng)該講Trace報(bào)文回送給客戶端。
6、Allow響應(yīng)實(shí)體首部字段列出了請(qǐng)求URI標(biāo)識(shí)的資源所支持的方法列表，如果請(qǐng)求URI為*的話，列出的就是整個(gè)服務(wù)器所支持的方法列表。
第七章、緩存
1、使用緩存的優(yōu)點(diǎn)如下：
（1）緩存減少了冗余的數(shù)據(jù)傳輸，節(jié)省了你的網(wǎng)絡(luò)費(fèi)用
（2）緩存緩解了網(wǎng)絡(luò)瓶頸的問題。不需要更多的帶寬就能夠更快地加載頁面
（3）緩存降低了對(duì)原始服務(wù)器的要求，服務(wù)器可以更快地響應(yīng)，避免過載的出現(xiàn)
（4）緩存降低了距離時(shí)延，因?yàn)閺妮^遠(yuǎn)的地方加載頁面會(huì)更慢一些。
2、專用緩存被稱為私有緩存，是個(gè)人的緩存，比如個(gè)人電腦的磁盤和內(nèi)存中。共享的緩存稱為公有緩存，是特殊的共享代理服務(wù)器，也是緩存代理服務(wù)器，也被稱為代理緩存。
3、緩存的處理步驟如下；
（1）接收：緩存從網(wǎng)絡(luò)中讀取抵達(dá)的請(qǐng)求報(bào)文
（2）解析：緩存對(duì)報(bào)文進(jìn)行解析，提取出URL和各種首部
（3）查詢：緩存查看是否有本地副本可用，如果沒有，就獲取一份副本（并將其保存在本地）
（4）新鮮度檢測：緩存查看已緩存副本是否足夠新鮮，如果不是，就詢問服務(wù)器是否有任何更新
（5）創(chuàng)建響應(yīng)：緩存會(huì)用新的首部和已緩存的主體來構(gòu)建一條響應(yīng)報(bào)文
（6）發(fā)送：緩存通過網(wǎng)絡(luò)將響應(yīng)發(fā)回給客戶端
（7）日志：緩存可選的創(chuàng)建一個(gè)日志文件條目來描述這個(gè)事務(wù)
4、檢查文檔的新鮮度
（1）通過Cache-Control首部（用max-age指定生存時(shí)間，以秒為單位）和Expires首部（指定過期的日期，需要客戶端與服務(wù)器時(shí)鐘同步）
（2）緩存并不一定要為每條請(qǐng)求驗(yàn)證文檔的有效性，只有在文檔過期時(shí)才需要與服務(wù)器進(jìn)行再驗(yàn)證。而且HTTP的條件方法可以高效實(shí)現(xiàn)再驗(yàn)證，HTTP允許緩存向原始服務(wù)器發(fā)送一個(gè)“條件GET”，請(qǐng)求服務(wù)器只有在文檔與緩存中現(xiàn)有的副本不同時(shí)，才會(huì)送對(duì)象主體。
（3）最常見緩存再驗(yàn)證首部是If-Modified-since。If-Modified-since首部可以與Last-Modified服務(wù)器響應(yīng)首部匹配工作。原始服務(wù)器會(huì)將最后的修改日期附加到所提供的文檔上去。當(dāng)緩存要對(duì)已緩存文檔進(jìn)行再驗(yàn)證時(shí)，就會(huì)包含一個(gè)If-Modified-Since首部，其中攜帶有最后修改已緩存副本的日期。而如果在此期間內(nèi)容被修改了，最后的修改日期就會(huì)有所不同，原始服務(wù)器就會(huì)回送新的文檔。否則，服務(wù)器會(huì)注意到緩存的最后修改日期與服務(wù)器文檔當(dāng)前的最后修改日期相符，會(huì)返回一個(gè)304狀態(tài)碼響應(yīng)。
（4）If-None-Match實(shí)體標(biāo)簽再驗(yàn)證（ETag），如果HTTP1.1緩存或服務(wù)器收到的請(qǐng)求既帶有If-Modified-Since又帶有實(shí)體標(biāo)簽條件首部，則只有兩個(gè)條件都滿足時(shí)，才會(huì)返回304響應(yīng)。
5、<Meta http-equiv>標(biāo)簽并不是控制文檔緩存特性的好方法，通過配置正確的服務(wù)器發(fā)出HTTP首部，才是傳送文檔緩存控制請(qǐng)求的唯一可靠方法。因?yàn)榇蠖鄶?shù)軟件都會(huì)忽略HTTP-EQUIV標(biāo)簽。
第八章、集成點(diǎn)：網(wǎng)關(guān)，隧道及中繼
略過（由于筆者覺得對(duì)于前端來說，學(xué)習(xí)用處不大，因此跳過）
第九章、Web機(jī)器人
略過（內(nèi)容有些看不懂，暫時(shí)跳過）
第十章、HTTP-NG
1、HTTP/1.1現(xiàn)在提供了可以追蹤文檔版本的標(biāo)記和指紋，提供了一些方法來支持文檔的上傳以及與可編程網(wǎng)關(guān)之間的交互，還提供了對(duì)多語言內(nèi)容、安全及認(rèn)證功能、降低流量的緩存功能、減小時(shí)延的管道功能、降低啟動(dòng)時(shí)間提高帶寬使用效率的持久連接，以及用來進(jìn)行部分更新的訪問范圍功能的支持。但HTTP的發(fā)展至少存在4個(gè)方面的問題：
（1）復(fù)雜性，相當(dāng)復(fù)雜，特性之間相互依存。
（2）可擴(kuò)展性，很難實(shí)現(xiàn)遞增式擴(kuò)展
（3）性能，有些部分效率不高
（4）傳輸依賴性
2、HTTP-NG的主題： 模塊化及功能增強(qiáng)，分為三層。
（1）報(bào)文傳輸：只關(guān)心報(bào)文的有效傳輸，不考慮報(bào)文的含義和目的。采用WebMUX協(xié)議，是個(gè)高性能的報(bào)文協(xié)議，可以對(duì)報(bào)文進(jìn)行分段，并在一條復(fù)用的TCP連接上交錯(cuò)地傳輸報(bào)文。
（2）遠(yuǎn)程調(diào)用：HTTP-NG結(jié)構(gòu)的中間層提供了對(duì)遠(yuǎn)程方法調(diào)用的支持。采用二進(jìn)制連接協(xié)議。
（3）Web應(yīng)用：是執(zhí)行語義和應(yīng)用程序特定邏輯的地方，描述了一個(gè)用于提供應(yīng)用程序特定服務(wù)的系統(tǒng)。
3、雖然現(xiàn)在還沒有什么主導(dǎo)的力量在驅(qū)動(dòng)HTTP-NG的應(yīng)用，但隨著HTTP應(yīng)用的不斷增多和無線因特網(wǎng)技術(shù)發(fā)展，HTTP-NG中提出的一些技術(shù)可能會(huì)在HTTP的青少年時(shí)期逐漸呈現(xiàn)出其重要性。
第十一章、客戶端識(shí)別與cookie機(jī)制
1、幾種用戶識(shí)別機(jī)制
（1）承載用戶身份信息的HTTP首部
（2）客戶端IP地址跟蹤，通過用戶的IP地址對(duì)其進(jìn)行識(shí)別
（3）用戶登錄，用認(rèn)證方式來識(shí)別用戶（用WWW-Authenticate首部和Authorization首部）
（4）胖URL，一種在URL中嵌入識(shí)別信息的技術(shù)
2、cookie分為會(huì)話cookie和持久cookie。如果設(shè)置了Discard參數(shù)，或者沒有設(shè)置Expires或Max-Age參數(shù)來說明擴(kuò)展的過期時(shí)間，那么這個(gè)cookie就是一個(gè)會(huì)話cookie。
3、cookie中包含了一個(gè)由名字=值（name=value）這樣的信息構(gòu)成的任意列表，并通過Set-Cookie或Set-Cookie2 HTTP響應(yīng)首部將其貼到用戶身上。
4、產(chǎn)生cookie 的服務(wù)器可以向Set-Cookie響應(yīng)首部添加一個(gè)Domain屬性來控制那些站點(diǎn)可以看到那個(gè)cookie。比如：
Set-Cookie：user=”mary”;domain=”aritravelbragain.com”
第十二章、基本認(rèn)證機(jī)制
1、HTTP定義了兩個(gè)官方的認(rèn)證協(xié)議：基本認(rèn)證和摘要認(rèn)證。
2、基本認(rèn)證步驟：
（1）請(qǐng)求
（2）服務(wù)器對(duì)用戶進(jìn)行質(zhì)詢，會(huì)返回一條401響應(yīng)，并在WWW-Authenticate首部說明如何以及在哪里進(jìn)行認(rèn)證。
（3）當(dāng)客戶端授權(quán)服務(wù)器繼續(xù)處理時(shí)，會(huì)重新發(fā)送請(qǐng)求，但會(huì)在Authorization首部附上加密的密碼和其他一些認(rèn)證參數(shù)
（4）授權(quán)請(qǐng)求成功完成時(shí)，服務(wù)器會(huì)返回一個(gè)正常的狀態(tài)碼（如200 OK）
3、基本認(rèn)證的安全缺陷
（1）基本認(rèn)證會(huì)通過網(wǎng)絡(luò)發(fā)送用戶名和密碼，雖然經(jīng)過Base-64編碼，但其實(shí)很容易被解碼，相當(dāng)于明文傳輸。
（2）即使用更難解碼的編碼進(jìn)行加密，也很容易被第三方用戶捕獲到用戶名和密碼，同樣可以一次又一次的重放給原始服務(wù)器以獲得訪問權(quán)。
（3）解碼出密碼后可能用在其他網(wǎng)站上，比如這個(gè)用戶的在線銀行網(wǎng)站。
（4）沒有提供任何針對(duì)代理和作為中間人的中間節(jié)點(diǎn)的防護(hù)措施，他們沒有修改認(rèn)證首部，但卻修改了報(bào)文的其余部分，嚴(yán)重改變了事務(wù)的本質(zhì)。（有點(diǎn)沒懂）
（5）假冒服務(wù)器很容易騙過基本認(rèn)證，可以請(qǐng)求用戶輸入密碼，將其存儲(chǔ)以備未來使用，然后捏造一條錯(cuò)誤信息發(fā)給用戶。
4、將基本認(rèn)證與加密數(shù)據(jù)傳輸（比如SSL）配合使用，向惡意用戶隱藏用戶名和密碼，會(huì)使基本認(rèn)證變得更加安全。
第十三章、摘要認(rèn)證
1、摘要認(rèn)證是另一種HTTP認(rèn)證協(xié)議，它試圖修復(fù)基本認(rèn)證協(xié)議的嚴(yán)重缺陷。具體來說，摘要認(rèn)證進(jìn)行了如下改進(jìn)：
（1）永遠(yuǎn)不會(huì)以明文方式在網(wǎng)絡(luò)上發(fā)送密碼
（2）可以防止惡意用戶捕獲并重放認(rèn)證的握手過程
（3）可以有選擇地防止對(duì)報(bào)文內(nèi)容的篡改
（4）防范其他幾種常見的攻擊方式
注：摘要認(rèn)證并不是最安全的認(rèn)證，而且現(xiàn)在摘要認(rèn)證也還沒有被廣泛應(yīng)用。
2、摘要是一種單向函數(shù)，主要用于將無限的輸入值轉(zhuǎn)換為有限的濃縮輸出值。有時(shí)也將摘要函數(shù)稱為加密的校驗(yàn)和、單向散列函數(shù)或指紋函數(shù)。
3、為了防止摘要被截獲，并且一遍遍地重放給服務(wù)器。服務(wù)器可以用隨機(jī)數(shù)防止重放攻擊。服務(wù)器可以向客戶端發(fā)送一個(gè)稱為隨機(jī)數(shù)的特殊令牌，這個(gè)數(shù)會(huì)經(jīng)常發(fā)生變化（可能是每毫秒，或者是每次認(rèn)證都變化）?？蛻舳嗽谟?jì)算摘要之前要先將這個(gè)隨機(jī)數(shù)令牌附加到密碼上去。而隨機(jī)數(shù)實(shí)在WWW-Authenticate質(zhì)詢中從服務(wù)器傳送給客戶端的。
4、摘要認(rèn)證的核心就是對(duì)公共信息、保密信息和有時(shí)限的隨機(jī)值這個(gè)組合的單向摘要。
5、摘要認(rèn)證在保留了很多安全特性的同時(shí)，還提供了幾種預(yù)授權(quán)方式，這里列出了三種可選的方式，通過這些方式，客戶端無需等待新的WWW-Authenticate質(zhì)詢，就可以獲得正確的隨機(jī)數(shù)。
（1）服務(wù)器預(yù)先在Authentication-Info成功首部中發(fā)送下一個(gè)隨機(jī)數(shù)
（2）服務(wù)器允許一小段時(shí)間內(nèi)使用同一個(gè)隨機(jī)數(shù)
（3）客戶端和服務(wù)器使用同步的、可預(yù)測的隨機(jī)數(shù)生成算法
6、RFC 2617擴(kuò)展了摘要認(rèn)證機(jī)制，允許客戶端對(duì)服務(wù)器進(jìn)行認(rèn)證。這是通過提供客戶端隨機(jī)值來實(shí)現(xiàn)的，服務(wù)器會(huì)根據(jù)它對(duì)共享保密信息的正確了解生成正確的響應(yīng)摘要。特別是，只要提供了qop指令，就要求執(zhí)行對(duì)稱認(rèn)證，而沒有qop指令時(shí)則不要求執(zhí)行對(duì)稱認(rèn)證。
7、重放攻擊：就是有人將從某個(gè)事物中竊取的認(rèn)證證書用于另一個(gè)事務(wù)。避免重放攻擊的方法就是為每個(gè)事務(wù)都使用一個(gè)唯一的隨機(jī)數(shù)。
8、詞典攻擊：就是典型的密碼猜測型攻擊。
9、惡意代理攻擊和中間人攻擊：隨著重定向和攔截代理的出現(xiàn)，用戶甚至意識(shí)不到他的請(qǐng)求穿過了某個(gè)代理，如果這些代理中時(shí)惡意的或者容易被入侵，就會(huì)使客戶端置于中間人攻擊之下。防止這些攻擊唯一簡便的方式就是使用SSL。
10、選擇明文攻擊：通過惡意或被入侵的代理，為客戶端的響應(yīng)計(jì)算提供隨機(jī)數(shù)，使用已知密鑰來計(jì)算響應(yīng)可以簡化響應(yīng)的密碼分析過程。
（1）預(yù)先計(jì)算的詞典攻擊
（2）批量暴力型攻擊
防止這些攻擊的方法就是配置客戶端使用可選的conoce指令，這樣響應(yīng)就是基于客戶端的判斷產(chǎn)生的，而不是用服務(wù)器提供的隨機(jī)數(shù)產(chǎn)生的。
第十四章、安全HTTP
1、使用HTTPS時(shí)，所有的HTTP請(qǐng)求和響應(yīng)數(shù)據(jù)在發(fā)送到網(wǎng)絡(luò)之前，都要進(jìn)行加密。HTTPS在HTTP下面提供了一個(gè)傳送級(jí)的密碼安全層——可以使用SSL，也可以使用TLS。大部分困難的編碼及解碼工作都是在SSL庫中完成得，所以Web客戶端和服務(wù)器在使用安全HTTP時(shí)無需過多地修改其協(xié)議處理邏輯。在大多數(shù)情況下，只需要用SSL的輸入/輸出調(diào)用取代TCP的調(diào)用，再增加其他幾個(gè)調(diào)用來配置和管理安全信息就行了。
2、數(shù)字加密
（1）密碼：對(duì)文本進(jìn)行編碼，使偷窺者無法識(shí)別的算法
（2）密鑰：改變密碼行為的數(shù)字化參數(shù)
（3）對(duì)稱密鑰加密系統(tǒng)：編/解碼使用相同密鑰的算法
（4）不對(duì)稱密鑰加密系統(tǒng)：編/解碼使用不同密鑰的算法
（5）公開密鑰加密系統(tǒng)：一種能夠使數(shù)百萬計(jì)算機(jī)便捷的發(fā)送機(jī)密報(bào)文的系統(tǒng)。
（6）數(shù)字簽名：用來驗(yàn)證報(bào)文未被偽造或篡改的校驗(yàn)和
（7）數(shù)字證書：由一個(gè)可信的組織驗(yàn)證和簽發(fā)的識(shí)別信息。
3、基本所有的加密算法都會(huì)使用密鑰
4、在對(duì)稱密鑰加密技術(shù)中，發(fā)送端和接收端要共享相同的密鑰才能進(jìn)行通信，流行的對(duì)稱密鑰加密算法有：DES、Triple-DES、RC2和RC4
5、用暴力去嘗試所有的密鑰值稱為枚舉攻擊。
6、通常大家都認(rèn)為長度與Triple-DES密鑰相當(dāng)?shù)?28位DES密鑰實(shí)際上是任何人以任何代價(jià)都無法通過暴力攻擊破解的。
7、對(duì)稱密鑰加密技術(shù)的缺點(diǎn)之一就是發(fā)送者和接收者在互相對(duì)話之前，一定要有一個(gè)共享的保密密鑰。這樣一來，如果有N個(gè)節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)都要和其他N-1個(gè)節(jié)點(diǎn)進(jìn)行安全對(duì)話的話，總共大概有N*N個(gè)保密密鑰，這將是一個(gè)管理噩夢。
8、公開密鑰加密技術(shù)沒有為每對(duì)主機(jī)使用單獨(dú)的加密/解密密鑰，而是使用了兩個(gè)非對(duì)稱密鑰：一個(gè)用來對(duì)主機(jī)報(bào)文編碼，另一個(gè)用來對(duì)主機(jī)報(bào)文解碼。編碼密鑰是眾所周知的（這也是公開密鑰加密這個(gè)名字的由來），但只有主機(jī)才知道私有的解密密鑰，因此只有主機(jī)才能對(duì)報(bào)文進(jìn)行解碼。
9、RSA算法就是一個(gè)流行的公開密鑰加密系統(tǒng)。
10、公開密鑰加密算法的計(jì)算可能會(huì)很慢，實(shí)際上它混合使用了對(duì)稱和非對(duì)稱策略。比如：比較常見的做法是在兩節(jié)點(diǎn)間通過便捷的公開密鑰加密技術(shù)建立起安全通信，然后再用那條安全的通道產(chǎn)生并發(fā)送臨時(shí)的隨機(jī)對(duì)稱密鑰，通過更快地對(duì)稱加密技術(shù)對(duì)其余的數(shù)據(jù)進(jìn)行加密。
11、用加密系統(tǒng)對(duì)報(bào)文進(jìn)行簽名，以說明是誰編寫的報(bào)文，同時(shí)證明報(bào)文未被篡改過，這種技術(shù)被稱為數(shù)字簽名。數(shù)字簽名通常使用非對(duì)稱公開密鑰技術(shù)產(chǎn)生的。因?yàn)橹挥兴姓卟胖榔渌接忻荑€，所以可以將作者的私有密鑰當(dāng)做一種“指紋”使用。
12、通過HTTPS建立了一個(gè)安全Web事務(wù)之后，現(xiàn)代的瀏覽器都會(huì)自動(dòng)獲取所連接服務(wù)器的數(shù)字證書，如果服務(wù)器沒有證書，安全連接就會(huì)失敗。
13、HTTPS的細(xì)節(jié)介紹
（1）HTTPS就是在安全的傳輸層上發(fā)送的HTTP。HTTPS在將HTTP報(bào)文發(fā)送給TCP之前，先將其發(fā)送給了安全層，對(duì)其進(jìn)行加密。
（2）請(qǐng)求一個(gè)客戶端對(duì)某Web資源執(zhí)行某事務(wù)時(shí)，它會(huì)去檢查URL的方案，如果URL方案為http，客戶端就會(huì)打開一條道服務(wù)器端口80的連接；如果方案為https，就會(huì)打開一條到服務(wù)器端口443的連接，然后與服務(wù)器握手，以二進(jìn)制格式與服務(wù)器交換一些SSL安全參數(shù)，附上加密的HTTP命令。
（3）建立安全傳輸。在HTTPS中，客戶端首先打開一條到Web服務(wù)器端口443的連接。一旦建立TCP連接，客戶端和服務(wù)器就會(huì)初始化SSL層，對(duì)加密參數(shù)進(jìn)行溝通，并交換密鑰。握手完成之后，SSL初始化就完成了，客戶端就可以將請(qǐng)求報(bào)文發(fā)送給安全層了。在將這些報(bào)文發(fā)送給TCP之前，要先對(duì)其進(jìn)行加密。（SSL握手需要完成交換協(xié)議版本號(hào)，選擇一個(gè)兩端都了解的密碼，對(duì)兩端的身份進(jìn)行認(rèn)證以及生成臨時(shí)的會(huì)話密鑰，以便加密信道）
（4）使用服務(wù)器證書，并檢查站點(diǎn)證書的有效性。
14、通過代理以隧道形式傳輸安全流量，如果客戶端開始用服務(wù)器的公開密鑰對(duì)發(fā)往服務(wù)器的數(shù)據(jù)進(jìn)行加密，代理就再也不能讀取HTTP首部了。一種常用的解決方法使用的技術(shù)就是HTTPS SSL隧道協(xié)議。使用HTTPS SSL隧道協(xié)議，客戶端首先要告知代理，它想要連接的安全主機(jī)和端口。這是在開始加密之前，以明文形式告知的，所以代理可以理解這條信息。
第十五章、實(shí)體與編碼（只取部分筆者覺得有用的部分）
1、使用Content-Length首部是為了能夠檢測出服務(wù)器崩潰而導(dǎo)致的報(bào)文截尾，并對(duì)共享持久連接的多個(gè)報(bào)文進(jìn)行正確分段。如果主體進(jìn)行了內(nèi)容編碼，Content-Length首部說明的就是編碼后的主體的字節(jié)長度，而不是未編碼的原始主體的長度。
2、Content-Type首部說明的是原始實(shí)體主體的媒體類型。
3、為了避免服務(wù)器使用客戶端不支持的編碼方式，客戶端就把自己支持的內(nèi)容編碼方式列表放在請(qǐng)求的Accept-Encoding首部里發(fā)出去。如果HTTP請(qǐng)求中沒有包含Accept-Encoding首部，服務(wù)器就可以假設(shè)客戶端能夠接受任何編碼方式?？蛻舳丝梢越o每種編碼附帶Q值參數(shù)來說明編碼的優(yōu)先級(jí)。1.0表明最希望使用的編碼，0表明不想接受。
更多資料免費(fèi)分享加群? 120342833??? 驗(yàn)證回答? ZZ
第十六章、國際化（只取部分筆者覺得有用的部分）
1、字符集是把字符轉(zhuǎn)換為二進(jìn)制碼的編碼，而charset參數(shù)告知客戶端如何把內(nèi)容中的二進(jìn)制碼轉(zhuǎn)換為字符。
2、Web服務(wù)器通過在Content-Type首部中使用charset參數(shù)把MIME字符集標(biāo)記發(fā)送給客戶端：
Content-Type:text/html;charset=iso-2022-jp
? ? ? ? 對(duì)于HTML內(nèi)容來說，可以在描述charset的<META HTTP-EQUIV=”Ccontent-Type”>標(biāo)記中找到字符集。如:
<META HTTP-EQUIV=”Ccontent-Type” CONTENT=“text/html；charset=iso-2022-jp”>
? ? ? ? 如果客戶端無法推斷出字符編碼，就假定使用的是iso-8859-1
3、HTTP客戶端可以使用Accept-Charset請(qǐng)求首部來明確高墜服務(wù)器它支持哪些字符系統(tǒng)。
第十七章、內(nèi)容協(xié)商與轉(zhuǎn)碼
略過（由于筆者覺得對(duì)于前端來說，學(xué)習(xí)用處不大，因此跳過）
第十八章、Web主機(jī)托管
1、主機(jī)托管分為專用托管和虛擬主機(jī)托管。
2、許多Web托管者通過讓一些顧客共享一臺(tái)計(jì)算機(jī)來提供便宜的Web主機(jī)托管服務(wù)，這稱為共享主機(jī)托管或虛擬主機(jī)托管
3、有以下4種技術(shù)可以實(shí)現(xiàn)虛擬主機(jī)
（1）通過URL路徑進(jìn)行虛擬主機(jī)托管（導(dǎo)致前綴很多余）
（2）通過端口號(hào)進(jìn)行主機(jī)托管（同上，端口號(hào)多余）
（3）通過IP地址進(jìn)行主機(jī)托管（存在消耗IP地址資源問題，但仍然得到了廣泛的運(yùn)用）
（4）通過Host首部進(jìn)行主機(jī)托管（有一些客戶端和服務(wù)器不支持）
4、Host首部描述了所請(qǐng)求的資源所在的因特網(wǎng)主機(jī)和端口號(hào)，和原始的URL中得到的一樣。
5、為了讓網(wǎng)站更可靠，有以下方法：
（1）使用鏡像的服務(wù)器集群，鏡像服務(wù)器可以在不同的地點(diǎn)包含同樣內(nèi)容的副本，可以使用HTTP重定向或DNS重定向?qū)⒖蛻舳说恼?qǐng)求導(dǎo)向特定的服務(wù)器。
（2）內(nèi)容分發(fā)網(wǎng)絡(luò)
（3）CND中的反向代理緩存。反向代理和鏡像服務(wù)器之間的區(qū)別在于反向代理通常是需求驅(qū)動(dòng)的。它們不會(huì)保存原始服務(wù)器的全部內(nèi)容副本，它們只保存客戶端請(qǐng)求的那部分內(nèi)容。
（4）CDN的代理緩存。
第十九章、發(fā)布系統(tǒng)
略過（內(nèi)容有些看不懂，暫時(shí)跳過）
第二十章、重定向和負(fù)載均衡
1、為什么HTTP應(yīng)用程序要重定向？
? ? ? ? （1）可靠的執(zhí)行HTTP事務(wù)
? ? ? ? （2）最小化時(shí)延
? ? ? ? （3）節(jié)約網(wǎng)絡(luò)帶寬
? ? ? ? 大多數(shù)重定向部署都包含了某些形式的負(fù)載均衡。也就是說，它們可以將輸入報(bào)文的負(fù)載分?jǐn)偟揭唤M服務(wù)器中去。而且重定向的目標(biāo)是盡快地將HTTP報(bào)文發(fā)送到可用的Web服務(wù)器上去。
? ? ? ? 2、通用的重定向方法
? ? ? ? （1）HTTP重定向，有些Web站點(diǎn)會(huì)將HTTP重定向作為一種簡單的負(fù)載均衡形式來使用。HTTP重定向的優(yōu)點(diǎn)之一就是重定向服務(wù)器知道客戶端的IP地址。
? ? ? ? （2）DNS重定向，適用于一個(gè)主機(jī)名對(duì)應(yīng)多個(gè)IP地址，需要DNS解析程序來返回可變，可用的IP。解析方式有：DNS輪轉(zhuǎn)，多個(gè)地址及輪轉(zhuǎn)地址的循環(huán)，用于平衡負(fù)載的DNS輪轉(zhuǎn)。
? ? ? ? （3）任播尋址，幾個(gè)地理上分散的Web服務(wù)器擁有完全相同的IP地址，而且會(huì)通過骨干路由器的“最短路徑”路由功能將客戶端的請(qǐng)求發(fā)送給離它最近的服務(wù)器。（該技術(shù)仍然是實(shí)驗(yàn)性技術(shù)）
? ? ? ? 3、代理的重定向方法，有3種方法：顯式的瀏覽器配置，動(dòng)態(tài)自動(dòng)配置以及透明攔截。
? ? ? ? 4、因特網(wǎng)緩存協(xié)議（ICP）允許緩存再其兄弟緩存中查找命中內(nèi)容。如果某個(gè)緩存中沒有HTTP報(bào)文所請(qǐng)求的內(nèi)容，它可以表明內(nèi)容是否在附近的兄弟緩存中，如果在就從那里獲取內(nèi)容，以避免查詢?cè)挤?wù)器而帶來的更多開銷?？梢园袸CP當(dāng)做一個(gè)緩存集群協(xié)議。HTTP請(qǐng)求報(bào)文的最終目的地可以通過一系列的ICP查詢確定，從這個(gè)角度來說，它就是一個(gè)重定向協(xié)議。
第二十一章、日志記錄與使用情況跟蹤
略過（由于筆者覺得對(duì)于前端來說，學(xué)習(xí)用處不大，因此跳過）
