3月18日 周一 HTTP概述
·HTTP是一種能夠獲取如HTML這樣的網(wǎng)絡資源的通訊協(xié)議，是Web上進行數(shù)據(jù)交換的基礎，是一個CS協(xié)議。請求通常是由像瀏覽器這樣的接受方發(fā)起。
·web文檔——>網(wǎng)絡——>服務器
·客戶端：如瀏覽器，發(fā)出requests? 服務端：響應responses。
·HTTP是應用層協(xié)議，通過TCP或者TLS（Transport Layer Security 加密的TCP）來發(fā)送。理論上任何可靠的傳輸協(xié)議都可以使用、具備良好的拓展性。
·代理Proxies：在瀏覽器和服務器之間，有許多計算機和其他設備轉發(fā)了HTTP消息，大多在傳輸層、網(wǎng)絡層和物理層，而有一部分是表現(xiàn)在應用層上，即代理。有如下作用：緩存、過濾、負載均衡（讓多個服務器服務不同的請求）、認證（對不同資源進行權限管理）、日志記錄
3月19日 周二 HTTP概述
·HTTP基本性質：
簡單：HTTP報文能夠被人讀懂，允許簡單測試，雖然HTTP/2協(xié)議將HTTP消息封裝到了幀
可拓展：HTTP/1.0中出現(xiàn)的HTTP headers。只要服務端和客戶端就新headers達成語義一致就能加入新功能
無狀態(tài)、有會話：在同一個連接中兩個執(zhí)行成功的請求之間沒有關系，使用HTTP的頭部拓展，HTTP Cookies可以解決這個問題。把Cookies添加到頭部中創(chuàng)建一個會話讓每個請求都能共享相同的上下文信息，達成相同的狀態(tài)。HTTP本質是無狀態(tài)的，使用Cookies可以創(chuàng)建有狀態(tài)的會話。
HTTP和連接：
一個連接是由傳輸層來控制的（HTTP是應用層協(xié)議），不屬于HTTP范圍。HTTP并不需要其底層的傳輸層協(xié)議是面向連接的，只需要它的可靠或不丟失消息（至少返回錯誤）。兩個常用的傳輸層協(xié)議：TCP可靠，UDP不是。因此，HTTP依賴于面向連接的TCP進行消息傳遞，但連接并不是必須的。
HTTP/1.0為每一個請求/響應都打開一個TCP連接，導致2個缺點：打開一個TCP連接需要多次往返消息傳遞，因此速度慢。但當多個消息周期性發(fā)送時，這樣就變得更加高效：暖連接比冷連接更高效。
為減輕以上缺陷，HTTP/1.1引入了流水線（被證明難以實現(xiàn)）和持久連接的概念：底層的TCP連接可以通過Connection頭部來被部分控制。HTTP/2則通過在一個連接復用消息的方式來讓這個連接始終保持為暖連接。
設計一種更好傳輸協(xié)議的進程一直在進行，Google研發(fā)了一種以UDP為基礎，能提供·更可靠更高效的傳輸協(xié)議QUIC。
3月20日 周三 HTTP概述
·被HTTP控制的常見特性：
緩存：
服務端能告訴代理和客戶端哪些文檔需要被緩存，緩存多久，客戶端也能命令中間的緩存代理來忽略儲存的文檔。
開放同源限制：
為了防止網(wǎng)絡窺聽和其他隱私泄漏，瀏覽器強制對Web網(wǎng)絡做了分割限制，只有來自于相同來源的網(wǎng)頁才能夠獲取網(wǎng)站的全部信息。這樣的限制有時反而成了負擔，HTTP可以通過修改頭部來開放這種限制，因此Web文檔可以由不同域下的信息拼接成的（某些情況下，這樣做還有安全因素考慮）
認證：
一些頁面能夠被保護起來，僅讓特定的用戶進行訪問。基本的認證功能可以通過HTTP提供，使用Authenticate相似的頭部即可或用HTTP Cookies來設置指定的會話。
代理和隧道：
通常情況下，服務器或客戶端處于內網(wǎng)，對外網(wǎng)隱藏真實IP地址，HTTP請求就要通過代理越過這個網(wǎng)絡屏障。但并非所有的代理都是HTTP代理，比如SOCKS協(xié)議的代理就運作在更底層，一些像FTP這樣的協(xié)議也能夠被它們處理。
會話：
使用HTTP Cookies可以用一個服務端的狀態(tài)發(fā)起請求，創(chuàng)建會話。雖然HTTP是無狀態(tài)協(xié)議，但這使得任何網(wǎng)站都能輕松為用戶定制展示內容。
3月21日 周四 HTTP概述
·HTTP流
當客戶端想要和服務端（指最終服務器或者一個中間代理）進行信息交互時，過程如下：
1.打開一個TCP連接：TCP連接被用來發(fā)送一條或多條請求以及接受響應消息?？蛻舳四艽蜷_一條連接/重用一個已經(jīng)存在的連接/開幾個新的TCP連接連向服務端。
2.發(fā)送一個HTTP報文：HTTP/2之前HTTP報文語義可讀，HTTP/2中這些簡單的消息被封裝在了幀中不能被直接讀取。
3.讀取服務端返回的報文信息
4.關閉連接或者為后續(xù)請求重用連接
HTTP流水線：后續(xù)請求都可以不用等待第一個請求的成功響應就被發(fā)送。很難實現(xiàn)，因為現(xiàn)有網(wǎng)絡中有很多老舊的軟件與現(xiàn)代版本的軟件共存。因此，HTTP流水線已被在有多請求下表現(xiàn)的更穩(wěn)健的HTTP/2的幀所取代。
·HTTP報文
HTTP/2中HTTP報文被嵌入到了一個新的二進制結構——幀。幀允許實現(xiàn)很多優(yōu)化，比如報文頭部的壓縮和復用。即使只有原始HTTP報文的一部分以HTTP/2發(fā)送出來，每條報文的語義依舊不變，客戶端會重組原始HTTP/1.1請求，因此用HTTP/1.1格式來理解HTTP/2報文依舊OK。
HTTP報文有兩種類型：
1.請求
a.Method: GET/POST/OPTIONS/HEAD定義客戶端動作行為。通常客戶端的操作都是GET獲取資源，POST發(fā)送HTML form表單值。
b.Path：要獲取的資源路徑，通常是上下文中就很明顯的元素資源的URL，沒有protocol（http：//），domain（XXX.org），或者TCP的port（HTTP一般在80端口）。
c.HTTP協(xié)議版本號
d.為服務端表達其他信息的可選頭部headers
2.響應
a.HTTP協(xié)議版本號
b.一個狀態(tài)碼：來告知對應請求執(zhí)行成功或失敗，以及失敗的原因
c.一個狀態(tài)信息：非權威的狀態(tài)碼描述信息，可以由服務端自行設定
d.headers:與請求頭部類似
e.可選項，比起請求報文，響應報文中更常見地包含獲取的資源body
3月22日 周五 HTTP緩存
·緩存：一種保存資源副本并在下次請求時直接使用該副本的技術。當web緩存發(fā)現(xiàn)請求的資源已經(jīng)被存儲，它會攔截請求，返回該資源的拷貝，而不會去源服務器重新下載。緩存是達到高性能的重要組成部分，需要合理配置，重要的是對一個資源的緩存應截止到其下一次發(fā)生改變（即不能緩存過期的資源）。
·緩存的分類（還有網(wǎng)關緩存、CDN、反向代理緩存和負載均衡器等部署在服務器上）
瀏覽器緩存：私有緩存，只能用于單獨用戶。瀏覽器緩存擁有用戶通過HTTP下載的所有文
檔。
代理緩存：共享緩存，可以被多個用戶使用。
·緩存操作的目標：
常見的HTTP緩存只能存儲GET響應。緩存的關鍵主要包括request method和目標URI；
普通緩存案例：
a.一個檢索請求的成功響應：對于GET，響應狀態(tài)碼為200表示成功，響應包含例如HTML文檔、圖片或者文件
b.永久重定向：301，是一條對網(wǎng)站瀏覽器的指令來顯示瀏覽器被要求顯示的不同的URL，當一個網(wǎng)頁經(jīng)歷過其URL的最后一次變化以后時使用。
c.錯誤響應：404
d.不完全的響應：206,只返回局部的信息
e.除了GET，如果匹配到作為一個已被定義的cache鍵名的響應
3月23日 周六 HTTP緩存
·緩存控制 Cache-Control頭
HTTP/1.1定義Cache-Control頭來區(qū)分對緩存機制的支持情況，請求頭和響應頭都支持這個屬性，通過它提供的不同的值來定義緩存策略。
a.禁止進行緩存
Cache-Control: no-store
Cache-Control: no-cache, no-store
b.強制確認緩存
Cache-Control: must-revalidate
每次有請求發(fā)出時，緩存會將此請求發(fā)到服務器（該請求應該會帶有與本地緩存相關的驗證字段），服務器端會驗證請求中的所描述的緩存是否過期，若未過期（304），則緩存才開始本地緩存副本。
c.私有緩存和公共緩存
默認私有
Cache-Control: public
該響應可以被任何中間人（比如中間代理、內容分發(fā)網(wǎng)絡CDN）緩存，緩存內容比如帶有HTTP驗證信息的頁面或某些特定影響狀態(tài)碼的頁面
Cache-Control: private
該響應專門于單個用戶，只能應用于瀏覽器私有緩存中
d.緩存過期機制
Cache-Control: max-age=<seconds>
max-age是距離請求發(fā)起的時間的秒數(shù)。針對應用中那些不會改變的文件，通?？梢允謩釉O置一定的時長以保證緩存有效，例如圖片、css、js等靜態(tài)資源
e.緩存驗證確認
Cache-Control: must-revalidate
緩存在考慮使用一個陳舊的資源時，必須先驗證它的狀態(tài)，已過期的緩存將不被使用
Pragma：HTTP/1.0標準中定義的一個header屬性，請求中包含Pragma的效果跟在頭信息中定義Cache-Control：no cache相同，但是HTTP的響應頭不支持這個屬性，所以不能完全替代Cache-control。通常定義Pragma以向后兼容于HTTP/1.0的客戶端。
3月24日 周日 HTTP緩存
·新鮮度
理論上，當一個資源被緩存存儲后，該資源應該可以被永久地存儲在緩存中。由于緩存只有有限的空間用于存儲資源副本，所以緩存會定期地將一些副本刪除，這個過程叫做緩存驅逐。另一方面，當服務器上面的資源進行了更新，緩存中的對應資源也應該被更新，由于HTTP是C/S模式的協(xié)議，服務器更新一個資源時，不可能直接通知客戶端及其緩存，所以雙方必須為該資源約定一個過期時間，在該過期時間之前，該資源（緩存副本）就是新鮮的，當過了過期時間，該資源則變?yōu)殛惻f的。
驅逐算法用于將陳舊的資源替換為新鮮的，?一個陳舊的資源是不會被直接清楚或忽略的，當客戶端發(fā)情一個請求，緩存檢索到已有一個對應的陳舊資源，則緩存會將此請求附加一個If-None-Match頭，然后發(fā)給目標服務器，以此來檢查該資源副本是否是依然還是算新鮮的，若服務器返回304（Not Modified）（該響應不會有帶有實體信息），則表示此資源副本是新鮮的。這樣，可以節(jié)省一些帶寬。若服務器通過If-None-Match或If-Modified-Since判斷后發(fā)現(xiàn)已過期，那么會帶有該資源的實體內容返回。
對于含有特定頭信息的請求，會去計算緩存壽命：
Cache-control: max-age=N? -------緩存壽命
若不含以上屬性就去查看是否包含Expires屬性，通過比較Expires的值和頭里面Date屬性的值來判斷是否緩存還有效。
若以上兩者都沒有，找頭里的Last-Modified信息。緩存的壽命就等于頭里面Date的值減去Last-Modified的值除以10
expirationTime = responseTime(瀏覽器接收到此響應的時間點）+freshnessLIfetime-currentage
?
? ?
