http和https

HTTP

http的請求報文和響應報文結構

http請求報文

分爲請求行、請求頭、空行、請求正文（可選項，get沒有）

1. 請求行：包括請求方法、URL以及消息版本，用空格分隔

2. 請求頭：爲請求報文添加了一下附加信息，由「名：值」組成

3. 空行：表示頭部的結束，接下來是正文，必不可少的一行

4. 請求正文：可選部分，如:get就沒有請求正文

http響應報文

主要由狀態行、響應頭、空行、響應正文四部分組成

1. 狀態行

   包括協議版本，狀態碼，狀態碼描述

2. 響應頭

   爲響應報文添加附加信息

3. 空行

4. 響應正文

http狀態碼的含義

1. 200 OK 服務器已成功處理了請求並提供了請求的網頁。

2. 202 Accepted 已經接受請求，但處理還沒有完成。

3. 204 No Content 沒有新文檔，瀏覽器應該繼續顯示原來的文檔。

4. 206 Partial Content 客戶端進行了範圍請求。響應報文中由Content-Range 指定實體

5. 301 Moved Permanently 永久性重定向。請求的網頁已永久移動到新位置。

6. 302（或307） Moved Temporatily 臨時性重定向。請求的網頁臨時移動到新位置。

7. 304 Not Modified 未修改。自從上次請求後，請求的內容未修改過。

8. 401 Unauthorized 客戶試圖未經受權訪問受密碼保護的頁面。應答中會包含一個WWW-Authenticate 頭，瀏覽器據此顯示用戶名字/密碼對話框， 而後在填寫合適的Authorization 頭後再次發出請求。

9. 403 Forbidden 服務器拒絕請求。

10. 403.6- IP address rejected

11. 404 Not Found 服務器上不存在客戶機所請求的資源。

12. 500 Internal Server Error 服務器遇到一個錯誤，使其沒法爲請求提供服務

http1.1新特性

1. 默認持久鏈接和流水線

   HTTP/1.1 默認使用持久鏈接，只要客戶端服務端任意一端沒有明確提出斷開TCP 鏈接，就一直保持鏈接，在同一個TCP 鏈接下，能夠發送屢次HTTP 請求。同時，默認採用流水線的方式發送求，即客戶端每遇到一個對象引用就當即發出一個請求，而沒必要等到收到前一個響應以後才能發出一個請求，但服務器端必須按照接收到客戶端請求的前後順序依次回送響應結果，以保證客戶端可以區分出每次請求的響應內容，這樣也顯著地減小了整個下載過程所須要的時間

2. 分塊傳輸數據

   HTTP/1.1 引入了分塊（chunked）的傳輸方法。該方法使發送方能將消息實體分割爲任意大小的組塊（chunk），並單獨地發送他們。在每一個組塊前面，都加上了該組塊的長度，使接收方可確保本身可以完整地接收到這個組塊。更重要的是，在最末尾的地方，發送方生成了長度爲零的塊，接收方可據此判斷整條消息都已安全地傳輸完畢。這樣也避免了在服務器端佔用大量的緩存。Transfer-Encoding：chunked 向接收方指出：響應將被分組塊，對響應分析時，應採起不一樣於非分組塊的方式。

3. 狀態碼100 Continue

   Continue，用於客戶端在發送POST 數據給服務器前，徵詢服務器的狀況，看服務器是否處理POST 的數據

4. Host 域

經常使用的HTTP 方法

1. GET： 從服務器中獲取一份文檔，即用於請求訪問已經被URI（統一資源標識符）識別的資源，能夠經過URL 傳參給服務器。

2. POST：用於傳輸信息給服務器，主要功能與GET 方法相似，但通常推薦使用POST方式。

3. PUT： 傳輸文件，報文主體中包含文件內容，保存到對應URI 位置。

4. HEAD： 得到報文首部，與GET 方法相似，只是不返回報文主體。

5. DELETE：刪除文件，與PUT 方法相反，刪除對應URI 位置的文件。

6. OPTIONS：查詢相應URL 支持的HTTP 方法。

7. trace：對可能通過代理服務器傳送到服務器上去的報文進行追蹤

HTTP 的特色

1. 支持客戶端/服務器端通訊模式。

2. 簡單方便快速：當客戶端向服務器端發送請求時，只是簡單的填寫請求路徑和請求方法便可，而後就能夠經過瀏覽器或其餘方式將該請求發送就好了。HTTP 協議比較簡單，因此HTTP 服務器的程序規模相對比較小，從而使得

3. 通訊的速度很是快。

4. 靈活：Http 協議容許客戶端和服務器端傳輸任意類型任意格式的數據對象。這些不一樣的類型Content-Type 標記。

5. 無鏈接：無鏈接的含義是每次創建的鏈接只處理一個客戶端請求。當服務器處理完

6. 客戶端的請求以後，而且收到客戶的反饋應答後，服務器端當即斷開鏈接，節省傳輸時間。

7. 無狀態：指協議對於請求的處理沒有記憶功能。無狀態意味着若是要再次處理先前的信息，則這些先前的信息必需要重傳，這就致使了數據量傳輸的增長。可是從另外一方面來講，當先前的信息服務器不在使用的時候，則服務器的響應將會很是的快。

http 的安全問題

1. 通訊使用明文不加密，內容可能被竊聽

2. 不驗證通訊方身份，可能遭到假裝

3. 沒法驗證報文完整性，可能被篡改

HTTPS 就是HTTP 加上加密處理（一般是SSL 安全通訊線路）+認證+完整性保護

HTTPS

做用

1. 內容加密：創建一個信息安全通道，來保證數據傳輸的安全

2. 身份認證：確認網站的真實性

3. 數據完整性：防止內容被第三方冒充或者篡改

基於https請求的數據傳輸中用到的技術

1. 對稱加密算法

2. 非對稱加密算法

3. 散列算法

4. 數字證書

HTTP 協議運行在TCP 之上，HTTPS 是運行在SSL/TLS 之上的HTTP 協議，SSL/TLS 運行在TCP 之上

session 何時被建立

直到某server端程序(如Servlet)調用HttpServletRequest.getSession(true)這樣的語句時纔會被建立。

session 什麼時候被刪除

1. 程序調用HttpSession.invalidate()

2. 距離上一次收到客戶端發送的session id 時間間隔超過了session 的最大有效時間

3. 服務器進程被中止

Cookie 與Session 的區別

1. cookie 數據存放在客戶端，用來記錄用戶信息的，session 數據放在服務器上。

2. 正是因爲Cookie 存儲在客戶端中，對客戶端是可見的，客戶端的一些程序可能會窺探、複製甚至修改Cookie 中的內容。而Session 存儲在服務器上，對客戶端是透明的，不存在敏感信息泄露的危險。

3. Session 是保存在服務器端的，每一個用戶都會產生一個Session。若是併發訪問的用戶很是多，會產生很是多的Session，消耗大量的服務器內存。所以併發訪問量極高的網站，是不太可能使用Session 來追蹤客戶會話的。

4. cookie 的容量和個數都有限制。單個cookie 的容量不能超過4KB，不少瀏覽器都限制一個站點最多保存20 個cookie，而session 沒有此問題。