第一章、HTTP概述
1、Web瀏覽器、服務器和相關的Web應用程序都是通過HTTP相互通信的，HTTP是現代全球因特網中使用的公共語言。
2、Web服務器回味所有HTTP對象數據附加一個MIME類型，MIME類型時一種文本標記，表示一種主要的對象類型和一個特定的子類型，中間為一條斜杠來分割。（Content-type：image/jpeg）
3、服務器資源名被稱為統(tǒng)一資源標識符（URI），有兩種形式：1、URL統(tǒng)一資源定位符，由三部分組成：方案（http：//），服務器的因特網地址（www.XXXX.com）以及服務器某個資源（/special/test.jpg）；2、URN統(tǒng)一資源名（仍處于試驗階段）
4、一條HTTP事務由一條請求命令和一個響應結果組成。
5、Telnet程序可以很好的模擬HTTP客戶端，但不能作為服務器使用。
6、代理位于客戶端和服務器之間，接收所有客戶端的HTTP請求，并將這些請求轉發(fā)給服務器。
7、Web緩存或代理緩存是一種特殊的HTTP代理服務器，可以將經過代理傳送的常用文檔復制保存起來。下一個請求同一個文檔的客戶端就可以享受緩存的私有副本所提供的服務了。
8、網關是一種特殊的服務器，作為其他服務器的中間實體使用。通常用于將HTTP流量轉換成其他的協議。
9、隧道是建立起來之后，就會在兩條連接之間對原始數據進行盲轉發(fā)的HTTP應用程序。HTTP隧道通常用來在一條或多條HTTP連接上轉發(fā)非HTTP數據，轉發(fā)時不會窺探數據。
10、用戶Agent代理時代表用戶發(fā)起HTTP請求的客戶端程序。所有發(fā)布Web請求的應用程序都是HTTP Agent代理，如：瀏覽器。


第二章、URL與資源
1、URI是一類更通用的資源標識符，URL實際上是它的一個子集.URI是
一個通用的概念，有兩個主要的子集URL和URN構成。
? ? ? ? 2、大多數URL方案的URL語法都建立在這個由9部分構成的通用格式上：
<scheme>：//<user>:<password>@<host>:<port>/<path>;<param>?<query>#<frag>
? ? ? ? 但幾乎沒有哪個URL包含了所有這些組件，最重要的還是3個部分，方案（scheme），主機（host）和路徑（path），至于9部分詳細介紹如下：
? ? ? ? 方案（scheme）：就是使用了什么協議。
? ? ? ? 主機（host）：主機名或者ip地址
端口（port）：標識了服務器正在監(jiān)聽的網絡端口，TCP的HTTP默認80
用戶名(user)和密碼(password)：有一些服務器需要輸入用戶名和密碼才能用戶訪問數據，比如FTP服務器。
路徑（path）:可以用“/”將HTTP的URL路徑劃分為一些路徑段。
參數（param）：為了向應用程序提供它們所需的輸入參數，URL有一個參數組件，就是URL中的名值對列表，有“；”將其與URL的其余部分分隔開，如：http://www.prep.ai.mit.com/pub/gnu;type=d/index.html;sale=false
查詢字符串(query)：很多資源，比如數據庫服務，就是通過提問題或進行查詢來縮小所請求資源類型范圍的。http://www.prep.ai.mit.com/get?item=12
片段(frag):為了引用部分資源或資源的一個片段。（但服務器通常只處理整個對象，所以瀏覽器從服務器獲得了整個資源之后，會根據片段來顯示你感興趣的那部分資源）
第三章、HTTP報文
1、HTTP報文是簡單的格式化數據塊。每條報文包含一條來自客戶端的請求，或者一條來自服務器的響應。它們由三個部分組成：對報文進行描述的起始行、包含屬性的首部塊、以及可選的、包含數據的主體部分。
2、HTTP報文分為：請求報文和響應報文。
請求報文的格式如下：
<method> <request-URL> <version>
<headers>

<entity-body>
響應報文的格式如下：
<version> <status > <reason-phrase>
<headers>

<entity-body>
注：各部分的簡要描述如下：
Method：客戶端希望服務器對資源執(zhí)行的方法，如GET，POST
request-URL：命名了所請求資源的完整URL
version：報文所使用的HTTO版本
status：描述了請求過程中所發(fā)生的情況，響應報文的數字狀態(tài)碼
reason-phrase：數字狀態(tài)碼的可讀版本。
Headers：首部，可以有0或多個。
entity-body：實體的主體部分包含一個由任意數據組成的數據塊。
3、常用的HTTP方法如下（請求報文）：
GET：從服務器獲取一份文檔，不包含主體。
HEAD：只從服務器獲取文檔的首部，不包含主體
POST：向服務器發(fā)送需要處理的數據，包含主體
PUT：將請求的主體部分存儲在服務器上，包含主體
TRACE:對可能經過代理服務器傳送到服務器上去的報文進行追蹤，不包含主體
OPTIONS：詢問可以在服務器上執(zhí)行哪些方法，不包含主體
DELETE：從服務上刪除一份文檔，不包含主體
4、HEAD方法與GET方法的行為很類似，但服務器在響應中只返回首部。這允許客戶端在未獲取實際資源情況下，對資源的首部進行檢查。可以在以下情況使用：
（1）在不獲取資源的情況下了解資源的情況
（2）通過查看響應中的狀態(tài)碼，看看某個對象是否存在
（3）通過查看首部，測試資源是否被修改了
注意：服務器開發(fā)者必須確保返回的首部與GET請求所返回的首部完全相同。
5、與GET從服務器讀取文檔相反，PUT方法會向服務器寫入文檔。PUT方法的語義就是讓服務器用請求的主體部分來創(chuàng)建一個由所請求的URL命名的新文檔，或者，如果那個URL已經存在的話，就用這個主體來替代它。
6、TRACE方法允許客戶端在最終將請求發(fā)送給服務器時，看看它變成了什么樣子。TRACE請求會在目的服務器端發(fā)起一個“環(huán)回”判斷。行程的最后一站的服務器會彈回一條TRACE響應，并在響應主體中攜帶它收到的原始請求報文。這樣客戶端就可以查看在所有中間應用程序組成的請求/響應鏈上，原始報文是否，以及如何被毀壞或修改過。（TRACE方法主要用于診斷，也就是說用于驗證請求是否如愿穿過了請求/響應鏈。）
7、OPTIONS方法請求Web服務器告知其支持的各種功能，可以詢問服務器通常支持哪些方法，或者對某些特殊資源支持哪些方法。
8、DELETE方法就是請服務器刪除請求URL所指定的資源。
9、狀態(tài)碼：
（1）100~199：信息性狀態(tài)碼
客戶端應用程序只有在避免向服務器發(fā)送一個服務器無法處理或使用的大實體時，才應該使用100Continue（在Expect首部設置）
服務器也永遠不應該向沒有發(fā)送100Continue期望的客戶端發(fā)送100Continue狀態(tài)碼。
（2）200~299：成功狀態(tài)碼
200 OK：成功處理
201 Created，用于創(chuàng)建服務器對象的請求（比如：PUT方法）
202 Accepted，請求你已被接受，但服務器還未對其執(zhí)行任何動作
203 Non-Authoritative Information，請求已處理，但實體首部包含的信息不是來自原始服務器，而是來自資源的副本。
204 No Content：響應報文中包含若干首部和一個狀態(tài)行，沒有主體。
（3）300~399：重定向狀態(tài)碼
300 Multiple Choices：客戶端請求的一個實際指向多個資源的URL時會返回這個狀態(tài)碼（如DNS重定向）
301 Moved Permanently：在請求的URL已被移除，響應的Location包含資源現在所處的新URL
304 Not Modified：資源自上次請求至今，仍未被修改
305 Use Proxy：用來說明必須通過一個代理來訪問資源
(4)400~499：客戶端錯誤狀態(tài)碼
400 Bad Request：告知客戶端它發(fā)送了一個錯誤的請求
401 Unauthorized：需要客戶端認證才能獲取對資源的訪問權
403 ForBidden：說明請求被服務器拒絕了。
404 Not Found：服務器沒有找到所請求的URL
405 Method Not Allowed：發(fā)起的請求帶有服務器不支持的方法。
406 Not Acceptable：服務器沒有與客戶端可接受的URL相匹配的資源
（5）500~599：服務器錯誤狀態(tài)碼
500 Internal Server Error:服務器遇到一個妨礙它為請求提供服務的錯誤
501 Not Implemented：客戶端發(fā)起的請求超出了服務器的能力范圍。
503 Service Unavailable:用來說明服務器現在無法為請求提供服務，但將來可以
504 Gateway Timeout：超時，只是這里的響應來自一個網管或者代理。

第四章、連接管理
1、HTTP就是“HTTP over TCP over IP”這個協議棧中的最頂層了，其安全版本HTTPS就是在HTTP和TCP之間插入了一個（稱為TLS或SSL）密碼加密層。
2、TCP就是通過端口號來保持所有連接持續(xù)不斷地運行。
3、TCP數據傳輸的性能還取決于TCP連接的使用期。TCP連接會隨著時間進行自我協調，起初會限制連接的最大速度，如果數據成功傳輸，會隨著時間的推移提高傳輸的速度，這種協調稱為TCP慢啟動，用于防止因特網的突然過載和擁塞。
4、最常見的TCP相關時延，其中包括
（1）TCP連接建立握手
（2）TCP慢啟動擁塞控制
（3）數據聚集的Nagle算法
（4）用于捎帶確認的TCP延遲確認算法
（5）TIME_WAIT時延和端口耗盡
5、在事務處理結束之后仍然保持在打開狀態(tài)的TCP連接被稱為持久連接。重用已對目標服務器打開的空閑持久連接，就可以避開緩慢的連接建立階段。將持久連接和并行連接配合使用可能是最高效的方式。打開少量的并行連接，其中的每一個都是持久連接。
6、為了處理啞代理（無法識別keep-alive首部）導致的問題，可以發(fā)送非標準的Proxy-Connection擴展首部，而不是官方支持的Connectio首部。如果代理時盲中繼，它會將無意義的Proxy-Connection首部轉發(fā)給Web服務器，服務器會忽略該首部，就不建立持久連接。如果代理時識別的了這個首部的，就會用一個Connection首部取代無意義的Proxy-Connection首部，然后將其轉發(fā)給服務器，以達到效果。
7、HTTP1.0只有響應中有Connection:Keep-Alive首部，才會將連接處于打開狀態(tài)，而HTTP1.1則假定所有連接都是持久的，只有Connection：close首部，才會在事務處理結束之后將連接關閉。
8、一個用戶客戶端對任何服務器或代理最多只能維護兩條持久連接，以防服務器過載。
9、關閉連接的正常做法：實現正常關閉的應用程序首先應該關閉他們的輸出信道，然后等待連接另一端的對等實體關閉它的輸出信道。當兩端都告訴對方它們不會再發(fā)送任何數據之后，連接就會被完全關閉，而不會有重置的危險。
第五章、Web服務器
1、實際的Web服務器會做些什么
（1）接收客戶端連接：如果客戶端已經打開了一條持久連接，則直接用這條連接來發(fā)送請求，不然就打開一條新連接。新連接需要先對客戶端主機名進行反向DNS，以用于詳細的訪問控制和日志記錄。而服務器可以通過ident協議找到發(fā)起HTTP連接的用戶名。
（2）接收請求報文：Web服務器會從網絡連接中讀取數據，并將請求報文中的內容解析出來。
（3）處理請求：根據方法、資源、首部和可選的主體部分來對請求進行處理。
（4）對資源的映射及訪問：通過docroot，目錄列表，動態(tài)內容資源的映射，服務器端包含項以及訪問控制
（5）構建響應：構建響應實體和確定MIME類型，以及對需要重定向的資源進行重定向
（6）發(fā)送響應
（7）記錄日志
第六章、代理
1、代理服務器可以是某個客戶端專用的，也可以是很多個客戶端共享的。單個客戶端專用的稱為私有代理，眾多客戶共享的稱為公共代理
2、代理連接的是兩個或多個使用相同協議的應用程序，而網關連接的則是兩個或多個使用不同協議的端點。
3、為什么使用代理？因為代理服務器可以實現各種時髦而有用的功能，他們可以改善安全性，提高性能，節(jié)約費用。如下：
（1）兒童過濾器
（2）文檔訪問控制
（3）安全防火墻
（4）Web緩存
（5）反向代理
（6）內容路由器
（7）轉碼器
4、Via首部字段列出了與報文途徑的每個中間節(jié)點（代理或網關）有關的信息。響應的Via首部基本上總是和請求的Via首部相反。
5、可以用Max-Forwrads首部字段來限制TRACE方法的轉發(fā)跳數，主要Max-Forwrads=0，則無論是否已經到達服務器都應該講Trace報文回送給客戶端。
6、Allow響應實體首部字段列出了請求URI標識的資源所支持的方法列表，如果請求URI為*的話，列出的就是整個服務器所支持的方法列表。

第七章、緩存
1、使用緩存的優(yōu)點如下：
（1）緩存減少了冗余的數據傳輸，節(jié)省了你的網絡費用
（2）緩存緩解了網絡瓶頸的問題。不需要更多的帶寬就能夠更快地加載頁面
（3）緩存降低了對原始服務器的要求，服務器可以更快地響應，避免過載的出現
（4）緩存降低了距離時延，因為從較遠的地方加載頁面會更慢一些。
2、專用緩存被稱為私有緩存，是個人的緩存，比如個人電腦的磁盤和內存中。共享的緩存稱為公有緩存，是特殊的共享代理服務器，也是緩存代理服務器，也被稱為代理緩存。
3、緩存的處理步驟如下；
（1）接收：緩存從網絡中讀取抵達的請求報文
（2）解析：緩存對報文進行解析，提取出URL和各種首部
（3）查詢：緩存查看是否有本地副本可用，如果沒有，就獲取一份副本（并將其保存在本地）
（4）新鮮度檢測：緩存查看已緩存副本是否足夠新鮮，如果不是，就詢問服務器是否有任何更新
（5）創(chuàng)建響應：緩存會用新的首部和已緩存的主體來構建一條響應報文
（6）發(fā)送：緩存通過網絡將響應發(fā)回給客戶端
（7）日志：緩存可選的創(chuàng)建一個日志文件條目來描述這個事務
4、檢查文檔的新鮮度
（1）通過Cache-Control首部（用max-age指定生存時間，以秒為單位）和Expires首部（指定過期的日期，需要客戶端與服務器時鐘同步）
（2）緩存并不一定要為每條請求驗證文檔的有效性，只有在文檔過期時才需要與服務器進行再驗證。而且HTTP的條件方法可以高效實現再驗證，HTTP允許緩存向原始服務器發(fā)送一個“條件GET”，請求服務器只有在文檔與緩存中現有的副本不同時，才會送對象主體。
（3）最常見緩存再驗證首部是If-Modified-since。If-Modified-since首部可以與Last-Modified服務器響應首部匹配工作。原始服務器會將最后的修改日期附加到所提供的文檔上去。當緩存要對已緩存文檔進行再驗證時，就會包含一個If-Modified-Since首部，其中攜帶有最后修改已緩存副本的日期。而如果在此期間內容被修改了，最后的修改日期就會有所不同，原始服務器就會回送新的文檔。否則，服務器會注意到緩存的最后修改日期與服務器文檔當前的最后修改日期相符，會返回一個304狀態(tài)碼響應。
（4）If-None-Match實體標簽再驗證（ETag），如果HTTP1.1緩存或服務器收到的請求既帶有If-Modified-Since又帶有實體標簽條件首部，則只有兩個條件都滿足時，才會返回304響應。
5、<Meta http-equiv>標簽并不是控制文檔緩存特性的好方法，通過配置正確的服務器發(fā)出HTTP首部，才是傳送文檔緩存控制請求的唯一可靠方法。因為大多數軟件都會忽略HTTP-EQUIV標簽。

第八章、集成點：網關，隧道及中繼
略過（由于筆者覺得對于前端來說，學習用處不大，因此跳過）
第九章、Web機器人
略過（內容有些看不懂，暫時跳過）
第十章、HTTP-NG
1、HTTP/1.1現在提供了可以追蹤文檔版本的標記和指紋，提供了一些方法來支持文檔的上傳以及與可編程網關之間的交互，還提供了對多語言內容、安全及認證功能、降低流量的緩存功能、減小時延的管道功能、降低啟動時間提高帶寬使用效率的持久連接，以及用來進行部分更新的訪問范圍功能的支持。但HTTP的發(fā)展至少存在4個方面的問題：
（1）復雜性，相當復雜，特性之間相互依存。
（2）可擴展性，很難實現遞增式擴展
（3）性能，有些部分效率不高
（4）傳輸依賴性
2、HTTP-NG的主題： 模塊化及功能增強，分為三層。
（1）報文傳輸：只關心報文的有效傳輸，不考慮報文的含義和目的。采用WebMUX協議，是個高性能的報文協議，可以對報文進行分段，并在一條復用的TCP連接上交錯地傳輸報文。
（2）遠程調用：HTTP-NG結構的中間層提供了對遠程方法調用的支持。采用二進制連接協議。
（3）Web應用：是執(zhí)行語義和應用程序特定邏輯的地方，描述了一個用于提供應用程序特定服務的系統(tǒng)。
3、雖然現在還沒有什么主導的力量在驅動HTTP-NG的應用，但隨著HTTP應用的不斷增多和無線因特網技術發(fā)展，HTTP-NG中提出的一些技術可能會在HTTP的青少年時期逐漸呈現出其重要性。
第十一章、客戶端識別與cookie機制
1、幾種用戶識別機制
（1）承載用戶身份信息的HTTP首部
（2）客戶端IP地址跟蹤，通過用戶的IP地址對其進行識別
（3）用戶登錄，用認證方式來識別用戶（用WWW-Authenticate首部和Authorization首部）
（4）胖URL，一種在URL中嵌入識別信息的技術
2、cookie分為會話cookie和持久cookie。如果設置了Discard參數，或者沒有設置Expires或Max-Age參數來說明擴展的過期時間，那么這個cookie就是一個會話cookie。
3、cookie中包含了一個由名字=值（name=value）這樣的信息構成的任意列表，并通過Set-Cookie或Set-Cookie2 HTTP響應首部將其貼到用戶身上。
4、產生cookie 的服務器可以向Set-Cookie響應首部添加一個Domain屬性來控制那些站點可以看到那個cookie。比如：
Set-Cookie：user=”mary”;domain=”aritravelbragain.com”
第十二章、基本認證機制
1、HTTP定義了兩個官方的認證協議：基本認證和摘要認證。
2、基本認證步驟：
（1）請求
（2）服務器對用戶進行質詢，會返回一條401響應，并在WWW-Authenticate首部說明如何以及在哪里進行認證。
（3）當客戶端授權服務器繼續(xù)處理時，會重新發(fā)送請求，但會在Authorization首部附上加密的密碼和其他一些認證參數
（4）授權請求成功完成時，服務器會返回一個正常的狀態(tài)碼（如200 OK）
3、基本認證的安全缺陷
（1）基本認證會通過網絡發(fā)送用戶名和密碼，雖然經過Base-64編碼，但其實很容易被解碼，相當于明文傳輸。
（2）即使用更難解碼的編碼進行加密，也很容易被第三方用戶捕獲到用戶名和密碼，同樣可以一次又一次的重放給原始服務器以獲得訪問權。
（3）解碼出密碼后可能用在其他網站上，比如這個用戶的在線銀行網站。
（4）沒有提供任何針對代理和作為中間人的中間節(jié)點的防護措施，他們沒有修改認證首部，但卻修改了報文的其余部分，嚴重改變了事務的本質。（有點沒懂）
（5）假冒服務器很容易騙過基本認證，可以請求用戶輸入密碼，將其存儲以備未來使用，然后捏造一條錯誤信息發(fā)給用戶。
4、將基本認證與加密數據傳輸（比如SSL）配合使用，向惡意用戶隱藏用戶名和密碼，會使基本認證變得更加安全。
第十三章、摘要認證
1、摘要認證是另一種HTTP認證協議，它試圖修復基本認證協議的嚴重缺陷。具體來說，摘要認證進行了如下改進：
（1）永遠不會以明文方式在網絡上發(fā)送密碼
（2）可以防止惡意用戶捕獲并重放認證的握手過程
（3）可以有選擇地防止對報文內容的篡改
（4）防范其他幾種常見的攻擊方式
注：摘要認證并不是最安全的認證，而且現在摘要認證也還沒有被廣泛應用。
2、摘要是一種單向函數，主要用于將無限的輸入值轉換為有限的濃縮輸出值。有時也將摘要函數稱為加密的校驗和、單向散列函數或指紋函數。
3、為了防止摘要被截獲，并且一遍遍地重放給服務器。服務器可以用隨機數防止重放攻擊。服務器可以向客戶端發(fā)送一個稱為隨機數的特殊令牌，這個數會經常發(fā)生變化（可能是每毫秒，或者是每次認證都變化）。客戶端在計算摘要之前要先將這個隨機數令牌附加到密碼上去。而隨機數實在WWW-Authenticate質詢中從服務器傳送給客戶端的。
4、摘要認證的核心就是對公共信息、保密信息和有時限的隨機值這個組合的單向摘要。
5、摘要認證在保留了很多安全特性的同時，還提供了幾種預授權方式，這里列出了三種可選的方式，通過這些方式，客戶端無需等待新的WWW-Authenticate質詢，就可以獲得正確的隨機數。
（1）服務器預先在Authentication-Info成功首部中發(fā)送下一個隨機數
（2）服務器允許一小段時間內使用同一個隨機數
（3）客戶端和服務器使用同步的、可預測的隨機數生成算法
6、RFC 2617擴展了摘要認證機制，允許客戶端對服務器進行認證。這是通過提供客戶端隨機值來實現的，服務器會根據它對共享保密信息的正確了解生成正確的響應摘要。特別是，只要提供了qop指令，就要求執(zhí)行對稱認證，而沒有qop指令時則不要求執(zhí)行對稱認證。
7、重放攻擊：就是有人將從某個事物中竊取的認證證書用于另一個事務。避免重放攻擊的方法就是為每個事務都使用一個唯一的隨機數。
8、詞典攻擊：就是典型的密碼猜測型攻擊。
9、惡意代理攻擊和中間人攻擊：隨著重定向和攔截代理的出現，用戶甚至意識不到他的請求穿過了某個代理，如果這些代理中時惡意的或者容易被入侵，就會使客戶端置于中間人攻擊之下。防止這些攻擊唯一簡便的方式就是使用SSL。
10、選擇明文攻擊：通過惡意或被入侵的代理，為客戶端的響應計算提供隨機數，使用已知密鑰來計算響應可以簡化響應的密碼分析過程。
（1）預先計算的詞典攻擊
（2）批量暴力型攻擊
防止這些攻擊的方法就是配置客戶端使用可選的conoce指令，這樣響應就是基于客戶端的判斷產生的，而不是用服務器提供的隨機數產生的。
第十四章、安全HTTP
1、使用HTTPS時，所有的HTTP請求和響應數據在發(fā)送到網絡之前，都要進行加密。HTTPS在HTTP下面提供了一個傳送級的密碼安全層——可以使用SSL，也可以使用TLS。大部分困難的編碼及解碼工作都是在SSL庫中完成得，所以Web客戶端和服務器在使用安全HTTP時無需過多地修改其協議處理邏輯。在大多數情況下，只需要用SSL的輸入/輸出調用取代TCP的調用，再增加其他幾個調用來配置和管理安全信息就行了。
2、數字加密
（1）密碼：對文本進行編碼，使偷窺者無法識別的算法
（2）密鑰：改變密碼行為的數字化參數
（3）對稱密鑰加密系統(tǒng)：編/解碼使用相同密鑰的算法
（4）不對稱密鑰加密系統(tǒng)：編/解碼使用不同密鑰的算法
（5）公開密鑰加密系統(tǒng)：一種能夠使數百萬計算機便捷的發(fā)送機密報文的系統(tǒng)。
（6）數字簽名：用來驗證報文未被偽造或篡改的校驗和
（7）數字證書：由一個可信的組織驗證和簽發(fā)的識別信息。
3、基本所有的加密算法都會使用密鑰
4、在對稱密鑰加密技術中，發(fā)送端和接收端要共享相同的密鑰才能進行通信，流行的對稱密鑰加密算法有：DES、Triple-DES、RC2和RC4
5、用暴力去嘗試所有的密鑰值稱為枚舉攻擊。
6、通常大家都認為長度與Triple-DES密鑰相當的128位DES密鑰實際上是任何人以任何代價都無法通過暴力攻擊破解的。
7、對稱密鑰加密技術的缺點之一就是發(fā)送者和接收者在互相對話之前，一定要有一個共享的保密密鑰。這樣一來，如果有N個節(jié)點，每個節(jié)點都要和其他N-1個節(jié)點進行安全對話的話，總共大概有N*N個保密密鑰，這將是一個管理噩夢。
8、公開密鑰加密技術沒有為每對主機使用單獨的加密/解密密鑰，而是使用了兩個非對稱密鑰：一個用來對主機報文編碼，另一個用來對主機報文解碼。編碼密鑰是眾所周知的（這也是公開密鑰加密這個名字的由來），但只有主機才知道私有的解密密鑰，因此只有主機才能對報文進行解碼。
9、RSA算法就是一個流行的公開密鑰加密系統(tǒng)。
10、公開密鑰加密算法的計算可能會很慢，實際上它混合使用了對稱和非對稱策略。比如：比較常見的做法是在兩節(jié)點間通過便捷的公開密鑰加密技術建立起安全通信，然后再用那條安全的通道產生并發(fā)送臨時的隨機對稱密鑰，通過更快地對稱加密技術對其余的數據進行加密。
11、用加密系統(tǒng)對報文進行簽名，以說明是誰編寫的報文，同時證明報文未被篡改過，這種技術被稱為數字簽名。數字簽名通常使用非對稱公開密鑰技術產生的。因為只有所有者才知道其私有密鑰，所以可以將作者的私有密鑰當做一種“指紋”使用。
12、通過HTTPS建立了一個安全Web事務之后，現代的瀏覽器都會自動獲取所連接服務器的數字證書，如果服務器沒有證書，安全連接就會失敗。
13、HTTPS的細節(jié)介紹
（1）HTTPS就是在安全的傳輸層上發(fā)送的HTTP。HTTPS在將HTTP報文發(fā)送給TCP之前，先將其發(fā)送給了安全層，對其進行加密。
（2）請求一個客戶端對某Web資源執(zhí)行某事務時，它會去檢查URL的方案，如果URL方案為http，客戶端就會打開一條道服務器端口80的連接；如果方案為https，就會打開一條到服務器端口443的連接，然后與服務器握手，以二進制格式與服務器交換一些SSL安全參數，附上加密的HTTP命令。
（3）建立安全傳輸。在HTTPS中，客戶端首先打開一條到Web服務器端口443的連接。一旦建立TCP連接，客戶端和服務器就會初始化SSL層，對加密參數進行溝通，并交換密鑰。握手完成之后，SSL初始化就完成了，客戶端就可以將請求報文發(fā)送給安全層了。在將這些報文發(fā)送給TCP之前，要先對其進行加密。（SSL握手需要完成交換協議版本號，選擇一個兩端都了解的密碼，對兩端的身份進行認證以及生成臨時的會話密鑰，以便加密信道）
（4）使用服務器證書，并檢查站點證書的有效性。
14、通過代理以隧道形式傳輸安全流量，如果客戶端開始用服務器的公開密鑰對發(fā)往服務器的數據進行加密，代理就再也不能讀取HTTP首部了。一種常用的解決方法使用的技術就是HTTPS SSL隧道協議。使用HTTPS SSL隧道協議，客戶端首先要告知代理，它想要連接的安全主機和端口。這是在開始加密之前，以明文形式告知的，所以代理可以理解這條信息。
第十五章、實體與編碼（只取部分筆者覺得有用的部分）
1、使用Content-Length首部是為了能夠檢測出服務器崩潰而導致的報文截尾，并對共享持久連接的多個報文進行正確分段。如果主體進行了內容編碼，Content-Length首部說明的就是編碼后的主體的字節(jié)長度，而不是未編碼的原始主體的長度。
2、Content-Type首部說明的是原始實體主體的媒體類型。
3、為了避免服務器使用客戶端不支持的編碼方式，客戶端就把自己支持的內容編碼方式列表放在請求的Accept-Encoding首部里發(fā)出去。如果HTTP請求中沒有包含Accept-Encoding首部，服務器就可以假設客戶端能夠接受任何編碼方式?？蛻舳丝梢越o每種編碼附帶Q值參數來說明編碼的優(yōu)先級。1.0表明最希望使用的編碼，0表明不想接受。

更多資料免費分享加群? 120342833??? 驗證回答? ZZ

第十六章、國際化（只取部分筆者覺得有用的部分）
1、字符集是把字符轉換為二進制碼的編碼，而charset參數告知客戶端如何把內容中的二進制碼轉換為字符。
2、Web服務器通過在Content-Type首部中使用charset參數把MIME字符集標記發(fā)送給客戶端：
Content-Type:text/html;charset=iso-2022-jp
? ? ? ? 對于HTML內容來說，可以在描述charset的<META HTTP-EQUIV=”Ccontent-Type”>標記中找到字符集。如:
<META HTTP-EQUIV=”Ccontent-Type” CONTENT=“text/html；charset=iso-2022-jp”>
? ? ? ? 如果客戶端無法推斷出字符編碼，就假定使用的是iso-8859-1
3、HTTP客戶端可以使用Accept-Charset請求首部來明確高墜服務器它支持哪些字符系統(tǒng)。
第十七章、內容協商與轉碼
略過（由于筆者覺得對于前端來說，學習用處不大，因此跳過）
第十八章、Web主機托管
1、主機托管分為專用托管和虛擬主機托管。
2、許多Web托管者通過讓一些顧客共享一臺計算機來提供便宜的Web主機托管服務，這稱為共享主機托管或虛擬主機托管
3、有以下4種技術可以實現虛擬主機
（1）通過URL路徑進行虛擬主機托管（導致前綴很多余）
（2）通過端口號進行主機托管（同上，端口號多余）
（3）通過IP地址進行主機托管（存在消耗IP地址資源問題，但仍然得到了廣泛的運用）
（4）通過Host首部進行主機托管（有一些客戶端和服務器不支持）
4、Host首部描述了所請求的資源所在的因特網主機和端口號，和原始的URL中得到的一樣。
5、為了讓網站更可靠，有以下方法：
（1）使用鏡像的服務器集群，鏡像服務器可以在不同的地點包含同樣內容的副本，可以使用HTTP重定向或DNS重定向將客戶端的請求導向特定的服務器。
（2）內容分發(fā)網絡
（3）CND中的反向代理緩存。反向代理和鏡像服務器之間的區(qū)別在于反向代理通常是需求驅動的。它們不會保存原始服務器的全部內容副本，它們只保存客戶端請求的那部分內容。
（4）CDN的代理緩存。
第十九章、發(fā)布系統(tǒng)
略過（內容有些看不懂，暫時跳過）
第二十章、重定向和負載均衡
1、為什么HTTP應用程序要重定向？
? ? ? ? （1）可靠的執(zhí)行HTTP事務
? ? ? ? （2）最小化時延
? ? ? ? （3）節(jié)約網絡帶寬
? ? ? ? 大多數重定向部署都包含了某些形式的負載均衡。也就是說，它們可以將輸入報文的負載分攤到一組服務器中去。而且重定向的目標是盡快地將HTTP報文發(fā)送到可用的Web服務器上去。
? ? ? ? 2、通用的重定向方法
? ? ? ? （1）HTTP重定向，有些Web站點會將HTTP重定向作為一種簡單的負載均衡形式來使用。HTTP重定向的優(yōu)點之一就是重定向服務器知道客戶端的IP地址。
? ? ? ? （2）DNS重定向，適用于一個主機名對應多個IP地址，需要DNS解析程序來返回可變，可用的IP。解析方式有：DNS輪轉，多個地址及輪轉地址的循環(huán)，用于平衡負載的DNS輪轉。
? ? ? ? （3）任播尋址，幾個地理上分散的Web服務器擁有完全相同的IP地址，而且會通過骨干路由器的“最短路徑”路由功能將客戶端的請求發(fā)送給離它最近的服務器。（該技術仍然是實驗性技術）
? ? ? ? 3、代理的重定向方法，有3種方法：顯式的瀏覽器配置，動態(tài)自動配置以及透明攔截。
? ? ? ? 4、因特網緩存協議（ICP）允許緩存再其兄弟緩存中查找命中內容。如果某個緩存中沒有HTTP報文所請求的內容，它可以表明內容是否在附近的兄弟緩存中，如果在就從那里獲取內容，以避免查詢原始服務器而帶來的更多開銷。可以把ICP當做一個緩存集群協議。HTTP請求報文的最終目的地可以通過一系列的ICP查詢確定，從這個角度來說，它就是一個重定向協議。
第二十一章、日志記錄與使用情況跟蹤
略過（由于筆者覺得對于前端來說，學習用處不大，因此跳過）