一．Proxies既可以表現得透明，又可以不透明（看請求是否通過它們），主要表現在這幾個功能上：
a.緩存（可以是公開的或是私有的，像瀏覽器的緩存）
b.過濾（像反病毒掃描，家長監護）
c.負載均衡，讓多個服務器服務不同的請求
d.對不同資源的權限控制
e.登陸，允許存儲歷史信息
二．HTTP可以控制的常見特性
1.緩存
文檔怎麼緩存能夠通過HTTP來控制。服務端能告訴代理和客戶端什麼需要被緩存，
緩存多久，而客戶端能夠命令中間緩存代理來忽略存儲的文檔。
2.開放同源限制
爲了防止網絡窺聽和其它的隱私泄漏，瀏覽器強制對Web網站做了分割限制。只
有來自於相同來源的網頁才能夠獲取網站的全部信息。這樣的限制有時反而成了負
擔，HTTP可以通過修改頭部來開放這樣的限制，因此web文檔可以是由不同域下
的信息拼接成的（在某些情況下，這樣做還有安全因素考慮在裏面）。
3.認證
一些頁面能夠被保護起來，僅讓特定的用戶進行訪問。基本的認證功能可以直接通
過HTTP提供，使用Authenticate相似的頭部就可以，或者用HTTP cookies來設定
指定的會話。
4.代理
服務端和客戶端通常都處在內部網上，彼此的真實地址都是不可見隱藏的。HTTP
請求就要通過代理穿過網絡障礙。不是所有的代理都是HTTP代理的，像一些用 SOCKS協議的代理就運作在更底層（一些其它的協議，像ftp也能夠被它們處理）
5.會話
Cookies用一個服務端的狀態連接起了每一個請求。這就創建了會話，雖然基本的 HTTP是無狀態協議。這很有用，不僅是因爲能用到購物車這樣的電商業務上，更
是因爲，它使得任何網站都能夠配置頁面展現的東西了。
http緩存
1、種類：
私有與共享緩存。
共享緩存存儲的響應能夠被多個用戶使用。
私有緩存只能用於單獨用戶。本文將主要介紹瀏覽器與代理緩存，除此之外還有網關緩 存、CDN、反向代理緩存 和負載均衡器等部署在服務器上，爲站點和 web 應用提供 更好的穩定性、性能和擴展性。
緩存控制 Cache-control
（1）完全不支持緩存
緩存中不得存儲任何關於客戶端請求和服務端響應的內容。每次由客戶端發起的請求 都會下載完整的響應內容。
（2）不緩存內容
（3）私有緩存和公共緩存
（4）緩存過期（max-age標誌來判斷）
（5）緩存驗證（must-revalidate），在使用一些老的資源前強制驗證狀態判斷其是否 過期。詳情看下文關於緩存校驗的內容。
（6）Pragma 頭
3.緩存有效性
（1）當發起一個針對舊緩存資源的請求時，會在請求頭裏帶上If-None-Match用來判 斷緩存是否還有效。如果有效，服務端返回304(Not Modified)和空的body以 節省一部分帶寬。
（2）如果max-age和expires屬性都沒有，找找頭裏的Last-Modified信息。如果有， 緩存的壽命就等於頭裏面Date的值減去Last-Modified的值除以10
（3）緩存時長計算公式：緩存時長 ＝ 響應時間 ＋ 緩存壽命 － 當前時間
HTTP cookies
1.Cookie主要用在以下三個方面:
(1)會話狀態管理（如用戶登錄狀態、購物車）
(2)個性化設置（如用戶自定義設置）
(3)瀏覽器行爲跟蹤（如跟蹤分析用戶行爲）
2.Cookie的作用域
Domain和Path指令定義了Cookie的作用域，即需要發送Cookie的URL集合。
Domain指令規定了需要發送Cookie的主機名。如果沒有指定，默認爲當前的文檔地址 上的主機名（但是不包含子域名）。如果指定了Domain，則一般包含子域名。
如果設置了Domain=mozilla.org，則Cookie包含在子域名中（如developer.mozilla.org）。
Path指令表明需要發送Cookie的URL路徑。字符%x2F (即"/")用做文件夾分隔符，子文 件夾也會被匹配到。
如設置Path=/docs，則下面這些地址都將匹配到:
"/docs",
"/docs/Web/",
"/docs/Web/HTTP"
3.avaScript通過Document.cookies訪問Cookie
通過Document.cookie屬性可以來創建新的Cookie，也能夠通過該屬性來訪問未被指定 HttpOnly標誌的Cookie。
document.cookie = "yummy_cookie=choco";
document.cookie = "tasty_cookie=strawberry";
console.log(document.cookie); // logs "yummy_cookie=choco; tasty_cookie=strawberry"
4.殭屍Cookie和刪不掉的Cookie
Cookie的一個極端使用例子是殭屍Cookie（或稱之爲“刪不掉的Cookie”），這類Cookie 較難以刪除，甚至刪除之後會自動重建。它們一般是使使用Web storage API、Flash本 地共享對象或者其他技術手段來達到目的的
五、訪問控制
（當一個資源從與該資源本身所在的服務器的域或端口不同的域或不同的端口請求一個資源時，資源會發起一個跨域 HTTP 請求。）
1.同源策略（服務器、域名、端口）
3.Fetch 規範定義了對 CORS 安全的首部字段集合
Content-Type （需要注意額外的限制）
4. Content-Type 的值屬於下列之一：
application/x-www-form-urlencoded
multipart/form-data
text/plain
六、請求方式
1.GET
GET方法請求一個指定資源的表示形式. 使用GET的請求應該只被用於獲取數據.
HEAD方法請求一個與GET請求的響應相同的響應，但沒有響應體.
POST方法用於將實體提交到指定的資源，通常導致狀態或服務器上的副作用的更改.
PUT方法用請求有效載荷替換目標資源的所有當前表示。
DELETE方法刪除指定的資源。
CONNECT方法建立一個到由目標資源標識的服務器的隧道。
OPTIONS方法用於描述目標資源的通信選項。
TRACE方法沿着到目標資源的路徑執行一個消息環回測試。
PATCH方法用於對資源應用部分修改。
七、狀態碼
狀態碼主要分爲五大類：消息，成功，重定向，客戶端錯誤，服務器端錯誤。
304表示no-modify、403 Forbidden，404Not Found，405Method Not Allowed，503Service Unavailable