我是技術搬運工,好東西當然要和大家分享啦.原文地址
基礎概念
Web基礎
HTTP（HyperText Transfer Protocol，超爲本傳輸協議）。
WWW（Word Wide Web）的三種技術：HTML、HTTP、URL。
RFC（Request for Comments，徵求修正意見書），互聯網的設計文檔。
URL
URI（Uniform Resource Indentifier，統一資源標識符），URL（Uniform Resource Locator，統一資源定位符），URN（Uniform Resource Name，統一資源名稱），例如 urn:isbn:0-486-27557-4 。URI 包含 URL 和 URN，目前 WEB 只有 URL 比較流行，所以見到的基本都是 URL。
URL格式：
請求和響應報文
請求報文
響應報文
HTTP 方法
客戶端發送的請求報文第一行爲請求行，包含了方法字段。
GET：獲取資源
POST：傳輸實體主體
POST 主要目的不是獲取資源，而是傳輸實體主體數據。
GET 和 POST 的請求都能使用額外的參數，但是 GET 的參數是以查詢字符串出現在 URL中，而 POST 的參數存儲在實體主體部分。
GET /test/demo_form.asp?name1=value1&name2=value2 HTTP/1.1
POST /test/demo_form.asp HTTP/1.1
Host: w3schools.com
name1=value1&name2=value2
GET 的傳參方式相比於 POST 安全性較差，因爲 GET 傳的參數在 URL 是可見的，可能會泄露私密信息。並且 GET 只支持 ASCII 字符，如果參數爲中文則可能會出現亂碼，而 POST 支持標準字符集。
HEAD：獲取報文首部
和 GET 方法一樣，但是不返回報文實體主體部分。
主要用於確認 URL 的有效性以及資源更新的日期時間等。
PUT：上傳文件
由於自身不帶驗證機制，任何人都可以上傳文件，因此存在安全性問題，一般 WEB 網站不使用該方法。
DELETE：刪除文件
與 PUT 功能相反，並且同樣不帶驗證機制。
OPTIONS：查詢支持的方法
查詢指定的 URL 能夠支持的方法。
會返回 Allow: GET, POST, HEAD, OPTIONS 這樣的內容。
TRACE：追蹤路徑
服務器會將通信路徑返回給客戶端。
發送請求時，在 Max-Forwards 首部字段中填入數值，每經過一個服務器就會減 1，當數值爲 0 時就停止傳輸。
TRACE 一般不會使用，並且它容易受到 XST 攻擊（Cross-Site Tracing，跨站追蹤），因此更不會去使用它。
CONNECT：要求用隧道協議連接代理
用隧道協議進行 TCP 通信。
主要使用 SSL（Secure Sokets Layer，安全套接字）和 TLS（Transport Layer Security，傳輸層安全）協議把通信內容加密後經網絡隧道傳輸。
HTTP 狀態碼
服務器返回的響應報文中第一行爲狀態行，包含了狀態碼以及原因短語，來告知客戶端請求的結果。
| 狀態碼 | 類別 | 原因短語 |
|---|---|---|
| 1XX | Informational（信息性狀態碼） | 接收的請求正在處理 |
| 2XX | Success（成功狀態碼） | 請求正常處理完畢 |
| 3XX | Redirection（重定向狀態碼） | 需要進行附加操作以完成請求 |
| 4XX | Client Error（客戶端錯誤狀態碼） | 服務器無法處理請求 |
| 5XX | Server Error（服務器錯誤狀態碼） | 服務器處理請求出錯 |
2XX 成功
200 OK
204 No Content：請求已經成功處理，但是返回的響應報文不包含實體的主體部分。一般在只需要從客戶端往服務器發送信息，而不需要返回數據時使用。
206 Partial Content
3XX 重定向
301 Moved Permanently：永久性重定向
302 Found：臨時性重定向
303 See Other
注：雖然 HTTP 協議規定 301、302 狀態下重定向時不允許把 POST 方法改成 GET 方法，但是大多數瀏覽器都會把 301、302 和 303 狀態下的重定向把 POST 方法改成 GET 方法。
304 Not Modified：如果請求報文首部包含一些條件，例如：If-Match，If-ModifiedSince，If-None-Match，If-Range，If-Unmodified-Since，但是不滿足條件，則服務器會返回 304 狀態碼。
307 Temporary Redirect：臨時重定向，與 302 的含義類似，但是 307 要求瀏覽器不會把重定向請求的 POST 方法改成 GET 方法。
4XX 客戶端錯誤
400 Bad Request：請求報文中存在語法錯誤
401 Unauthorized：該狀態碼錶示發送的請求需要有通過 HTTP 認證（BASIC 認證、DIGEST 認證）的認證信息。如果之前已進行過一次請求，則表示用戶認證失敗。
403 Forbidden：請求被拒絕，服務器端沒有必要給出拒絕的詳細理由。
404 Not Found
5XX 服務器錯誤
500 Internal Server Error：服務器正在執行請求時發生錯誤
503 Service Unavilable：該狀態碼錶明服務器暫時處於超負載或正在進行停機維護，現在無法處理請求。
HTTP首部
HTTP 報文包含了首部和主體兩部分。有 4 種類型的首部字段：通用首部字段、請求首部字段、響應首部字段和實體首部字段。各種首部字段及其含義如下（不需要全記，僅供查閱）：
通用首部字段
| 首部字段名 | 說明 |
|---|---|
| Cache-Control | 控制緩存的行爲 |
| Connection | 逐跳首部、 連接的管理 |
| Date | 創建報文的日期時間 |
| Pragma | 報文指令 |
| Trailer | 報文末端的首部一覽 |
| Transfer-Encoding | 指定報文主體的傳輸編碼方式 |
| Upgrade | 升級爲其他協議 |
| Via | 代理服務器的相關信息 |
| Warning | 錯誤通知 |
請求首部字段
| 首部字段名 | 說明 |
|---|---|
| Accept | 用戶代理可處理的媒體類型 |
| Accept-Charset | 優先的字符集 |
| Accept-Encoding | 優先的內容編碼 |
| Accept-Language | 優先的語言（自然語言） |
| Authorization | Web認證信息 |
| Expect | 期待服務器的特定行爲 |
| From | 用戶的電子郵箱地址 |
| Host | 請求資源所在服務器 |
| If-Match | 比較實體標記（ETag） |
| If-Modified-Since | 比較資源的更新時間 |
| If-None-Match | 比較實體標記（與 If-Match 相反） |
| If-Range | 資源未更新時發送實體 Byte 的範圍請求 |
| If-Unmodified-Since | 比較資源的更新時間（與If-Modified-Since相反） |
| Max-Forwards | 最大傳輸逐跳數 |
| Proxy-Authorization | 代理服務器要求客戶端的認證信息 |
| Range | 實體的字節範圍請求 |
| Referer | 對請求中 URI 的原始獲取方 |
| TE | 傳輸編碼的優先級 |
| User-Agent | HTTP 客戶端程序的信息 |
響應首部字段
| 首部字段名 | 說明 |
|---|---|
| Accept-Ranges | 是否接受字節範圍請求 |
| Age | 推算資源創建經過時間 |
| ETag | 資源的匹配信息 |
| Location | 令客戶端重定向至指定URI |
| Proxy-Authenticate | 代理服務器對客戶端的認證信息 |
| Retry-After | 對再次發起請求的時機要求 |
| Server | HTTP服務器的安裝信息 |
| Vary | 代理服務器緩存的管理信息 |
| WWW-Authenticate | 服務器對客戶端的認證信息 |
實體首部字段
| 首部字段名 | 說明 |
|---|---|
| Allow | 資源可支持的HTTP方法 |
| Content-Encoding | 實體主體適用的編碼方式 |
| Content-Language | 實體主體的自然語言 |
| Content-Length | 實體主體的大小（單位： 字節） |
| Content-Location | 替代對應資源的URI |
| Content-MD5 | 實體主體的報文摘要 |
| Content-Range | 實體主體的位置範圍 |
| Content-Type | 實體主體的媒體類型 |
| Expires | 實體主體過期的日期時間 |
| Last-Modified | 資源的最後修改日期時間 |
具體應用
Cookie
HTTP 協議是無狀態的，主要是爲了讓 HTTP 協議儘可能簡單，使得它能夠處理大量事務。HTTP/1.1 引入 Cookie 來保存狀態信息。
服務器會發送的響應報文包含 Set-Cookie 字段，客戶端得到該相應後把 Cookie 內容保存到瀏覽器中。下次再發送請求時，從瀏覽器中讀出 Cookie 值，在請求報文中包含 Cookie 字段，這樣服務器就知道客戶端的狀態信息了。Cookie 狀態信息保存在客戶端瀏覽器中，而不是服務器上。
Set-Cookie 字段有以下屬性：
| 屬性 | 說明 |
|---|---|
| NAME=VALUE | 賦予 Cookie 的名稱和其值（必需項） |
| expires=DATE | Cookie 的有效期（若不明確指定則默認爲瀏覽器關閉前爲止） |
| path=PATH | 將服務器上的文件目錄作爲 Cookie 的適用對象（若不指定則默認爲文檔所在的文件目錄） |
| domain=域名 | 作爲 Cookie 適用對象的域名（若不指定則默認爲創建 Cookie 的服務器的域名） |
| Secure | 僅在 HTTPS 安全通信時纔會發送 Cookie |
| HttpOnly | 加以限制，使 Cookie 不能被 JavaScript 腳本訪問 |
Session 和 Cookie 區別
Session 是服務器用來跟蹤用戶的一種手段，每個 Session 都有一個唯一標識：Session ID。當服務器創建了一個 Session 時，給客戶端發送的響應報文就包含了 Set-Cookie 字段，其中有一個名爲 sid 的鍵值對，這個鍵值對就是 Session ID。客戶端收到後就把 Cookie 保存在瀏覽器中，並且之後發送的請求報文都包含 Session ID。HTTP 就是 Session 和 Cookie 這兩種方式一起合作來實現跟蹤用戶狀態的，而 Session 用於服務器端，Cookie 用於客戶端。
瀏覽器禁用 Cookie 的情況
會使用 URL 重寫技術，在 URL 後面加上 sid=xxx 。
使用 Cookie 實現用戶名和密碼的自動填寫
網站腳本會自動從 Cookie 中讀取用戶名和密碼，從而實現自動填寫。
緩存
有兩種緩存方法：讓代理服務器進行緩存和讓客戶端瀏覽器進行緩存。
Cache-Control 用於控制緩存的行爲。
Cache-Control: no-cache 有兩種含義，如果是客戶端向緩存服務器發送的請求報文中含有該指令，表示客戶端不想要緩存的資源；如果是源服務器向緩存服務器發送的響應報文中含有該指令，表示緩存服務器不能對資源進行緩存。
Expires 字段可以用於告知緩存服務器該資源什麼時候會過期。當首部字段 Cache-Control 有指定 max-age 指令時，比起首部字段 Expires，會優先處理 max-age 指令。
持久連接
當瀏覽器訪問一個包含多張圖片的 HTML 頁面時，除了請求訪問 HTML 頁面資源，還會請求圖片資源，如果每進行一次 HTTP 通信就要斷開一次 TCP 連接，連接建立和斷開的開銷會很大。持久連接 只需要進行一次 TCP 連接就能進行多次 HTTP 通信。HTTP/1.1開始，所有的連接默認都是持久連接。
持久連接需要使用 Connection 首部字段進行管理。HTTP/1.1 開始HTTP 默認是持久化連接的，如果要斷開 TCP 連接，需要由客戶端或者服務器端提出斷開，使用 Connection: close ；而在HTTP/1.1之前默認是非持久化連接的，如果要維持持續連接，需要使用 Keep-Alive。
管線化方式可以同時發送多個請求和響應，而不需要發送一個請求然後等待響應之後再發下一個請求。
編碼
編碼（Encoding）主要是爲了對實體進行壓縮。常用的編碼有：gzip、compress、deflate、identity，其中 identity 表示不執行壓縮的編碼格式。
分塊傳輸
分塊傳輸（Chunked Transfer Coding）可以把數據分割成多塊，讓瀏覽器逐步顯示頁面。
多部分對象集合
一份報文主體內可含有多類型的實體同時發送，每個部分之間用 boundary 字段定義的分隔符進行分隔；每個部分都可以有首部字段。
例如，上傳多個表單時可以使用如下方式：
範圍請求
如果網絡出現中斷，服務器只發送了一部分數據，範圍請求使得客戶端能夠只請求未發送的那部分數據，從而避免服務器端重新發送所有數據。
在請求報文首部中添加 Range 字段，然後指定請求的範圍，例如 Range : bytes = 5001-10000。請求成功的話服務器發送 206 Partial Content 狀態。
內容協商
通過內容協商返回最合適的內容，例如根據瀏覽器的默認語言選擇返回中文界面還是英文界面。
涉及以下首部字段：Accept、Accept-Charset、Accept-Encoding、Accept-Language、Content-Language。
虛擬主機
使用虛擬主機技術，使得一臺服務器擁有多個域名，並且在邏輯上可以看成多個服務器。
通信數據轉發
代理
代理服務器接受客戶端的請求，並且轉發給其它服務器。代理服務器一般是透明的，不會改變 URL。
使用代理的主要目的是：緩存、網絡訪問控制以及記錄訪問日誌。
網關
與代理服務器不同的是，網關服務器會將 HTTP 轉化爲其它協議進行通信，從而其它非 HTTP 服務器的服務。
隧道
使用 SSL 等加密手段，爲客戶端和服務器之間建立一條安全的通信線路。
HTTPs
HTTP 有以下安全性問題：
- 通信使用明文，內容可能會被竊聽；
- 不驗證通信方的身份，因此有可能遭遇僞裝；
- 無法證明報文的完整性，所以有可能已遭篡改。
HTTPs 並不是新協議，而是 HTTP 先和 SSL（Secure Socket Layer）通信，再由 SSL 和 TCP 通信。通過使用 SSL，HTTPs 提供了加密、認證和完整性保護。
加密
有兩種加密方式：對稱密鑰加密和公開密鑰加密。對稱密鑰加密的加密和解密使用同一密鑰，而公開密鑰加密使用一對密鑰用於加密和解密，分別爲公開密鑰和私有密鑰。公開密鑰所有人都可以獲得，通信發送方獲得接收方的公開密鑰之後，就可以使用公開密鑰進行加密，接收方收到通信內容後使用私有密鑰解密。
對稱密鑰加密的缺點：無法安全傳輸密鑰；公開密鑰加密的缺點：相對來說更耗時。
HTTPs 採用 混合的加密機制，使用公開密鑰加密用於傳輸對稱密鑰，之後使用對稱密鑰加密進行通信。（下圖中，共享密鑰即對稱密鑰）
認證
通過使用 證書 來對通信方進行認證。證書中有公開密鑰數據，如果可以驗證公開密鑰的確屬於通信方的，那麼就可以確定通信方是可靠的。
數字證書認證機構（CA，CertificateAuthority）頒發的公開密鑰證書，可以通過 CA 對其進行驗證。
進行 HTTPs 通信時，服務器會把證書發送給客戶端，客戶端取得其中的公開密鑰之後，就可以開始加密過程。
使用 OpenSSL 這套開源程序，每個人都可以構建一套屬於自己的認證機構，從而自己給自己頒發服務器證書。瀏覽器在訪問該服務器時，會顯示“無法確認連接安全性”或“該網站的安全證書存在問題”等警告消息。
客戶端證書需要用戶自行安裝，只有在業務需要非常高安全性時才使用客戶端證書，例如網上銀行。
完整性
SSL 提供摘要功能來驗證完整性。