HTTP協議

URI結構

格式: [scheme:][//host:port][path][?query][#fragment]

例子：http://www.java2s.com:8080/yourpath/fileName.htm?stove=10&path=32&id=4#harvic

對應：

scheme：http ​ scheme-specific-part：//www.java2s.com:8080/yourpath/fileName.htm?stove=10&path=32&id=4 ​ fragment：harvic ​ authority：www.java2s.com:8080 ​ query：stove=10&path=32&id=4 ​ path：/yourpath/fileName.htm ​ host：www.java2s.com ​ port：8080

Request

HTTP的請求包括：請求行(request line)、請求頭部(header)、空行 和 請求數據 四個部分組成。

舉例：

Host: www.cnblogs.com 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; zh-CN; rv:1.8.1) Gecko/20061010 Firefox/2.0  
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5  
Accept-Language: en-us,zh-cn;q=0.7,zh;q=0.3  
Accept-Encoding: gzip,deflate  
Accept-Charset: gb2312,utf-8;q=0.7,*;q=0.7  
Keep-Alive: 300  
Proxy-Connection: keep-alive  
Cookie: ASP.NET_SessionId=ey5drq45lsomio55hoydzc45
Cache-Control: max-age=0

1. 請求行以一個方法符號開頭，以空格分開，後面跟着請求的URL和協議的版本。

2. 請求頭部，緊接着請求行（即第一行）之後的部分，用來說明服務器要使用的附加信息

3. 空行，請求頭部後面的空行是必須的。即使第四部分的請求數據爲空，也必須有空行。

4. 請求數據也叫主體，可以添加任意的其他數據。

HTTP請求方法

首部字段

1. 通用首部字段（General Header Fields）

　　代表請求報文和響應報文都會使用的字段

1. 請求首部字段（Request Header Fields）

　　是客戶端向服務端發送請求時使用的首部字段。包含請求的附加內容、客戶端信息、響應內容相關優先級等信息。

1. 響應首部字段（Response Header Fields）

　　是服務端向客戶端返回響應時使用的首部字段，包含響應的附加內容，可能也會要求客戶端附加額外的內容信息。

1. 實體首部字段（Entity Header Fields）

　　是針對請求報文和響應報文的實體部分使用的首部。包含資源內容更新時間等和實體有關的信息。

1. 其他首部字段

   Cookie、Set-Cookie、Content-Disposition、Connection、Keep-Alive、Proxy-Authenticate、Proxy-Authorization、Trailer、TE、Transfer-Encoding、Upgrade etc...

    

Response

HTTP響應也由四個部分組成，分別是：狀態行、消息報頭、空行和響應正文。

1. 狀態行，由HTTP協議版本號， 狀態碼， 狀態消息 三部分組成。

2. 消息報頭，用來說明客戶端要使用的一些附加信息

3. 空行，消息報頭後面的空行是必須的

4. 響應正文，服務器返回給客戶端的文本信息。

HTTP之狀態碼

狀態代碼有三位數字組成，第一個數字定義了響應的類別，共分五種類別:

1xx：指示信息--表示請求已接收，繼續處理

2xx：成功--表示請求已被成功接收、理解、接受

3xx：重定向--要完成請求必須進行更進一步的操作

4xx：客戶端錯誤--請求有語法錯誤或請求無法實現

5xx：服務器端錯誤--服務器未能實現合法的請求

常見狀態碼：

200：請求被正常處理
204：請求被受理但沒有資源可以返回
206：客戶端只是請求資源的一部分，服務器只對請求的部分資源執行GET方法，相應報文中通過Content-Range指定範圍的資源。
301：永久性重定向
302：臨時重定向
303：與302狀態碼有相似功能，只是它希望客戶端在請求一個URI的時候，能通過GET方法重定向到另一個URI上
304：發送附帶條件的請求時，條件不滿足時返回，與重定向無關
307：臨時重定向，與302類似，只是強制要求使用POST方法
400：請求報文語法有誤，服務器無法識別
401：請求需要認證
403：請求的對應資源禁止被訪問
404：服務器無法找到對應資源
500：服務器內部錯誤
503：服務器正忙

HTTPS

HTTP的server端口號爲80，HTTPS的爲443

HTTPS工作原理

1、首先HTTP請求服務端生成證書，客戶端對證書的有效期、合法性、域名是否與請求的域名一致、證書的公鑰（RSA加密）等進行校驗；

2、客戶端如果校驗通過後，就根據證書的公鑰的有效， 生成隨機數，隨機數使用公鑰進行加密（RSA加密）；

3、消息體產生的後，對它的摘要進行MD5（或者SHA1）算法加密，此時就得到了RSA簽名；

4、發送給服務端，此時只有服務端（RSA私鑰）能解密。

5、解密得到的隨機數，再用AES加密，作爲密鑰（此時的密鑰只有客戶端和服務端知道）。

具體的參考: 鏈接

常見問題

Cookie和Session的區別和聯繫

　　Cookie和Session都是爲了保存客戶端和服務端之間的交互狀態，實現機制不同，各有優缺點。首先一個最大的區別就是Cookie是保存在客戶端而Session就保存在服務端的。Cookie是客戶端請求服務端時服務器會將一些信息以鍵值對的形式返回給客戶端，保存在瀏覽器中，交互的時候可以加上這些Cookie值。用Cookie就可以方便的做一些緩存。Cookie的缺點是大小和數量都有限制；Cookie是存在客戶端的可能被禁用、刪除、篡改，是不安全的；Cookie如果很大，每次要請求都要帶上，這樣就影響了傳輸效率。Session是基於Cookie來實現的，不同的是Session本身存在於服務端，但是每次傳輸的時候不會傳輸數據，只是把代表一個客戶端的唯一ID（通常是JSESSIONID）寫在客戶端的Cookie中，這樣每次傳輸這個ID就可以了。Session的優勢就是傳輸數據量小，比較安全。但是Session也有缺點，就是如果Session不做特殊的處理容易失效、過期、丟失或者Session過多導致服務器內存溢出，並且要實現一個穩定可用安全的分佈式Session框架也是有一定複雜度的。在實際使用中就要結合Cookie和Session的優缺點針對不同的問題來設計解決方案。

GET和POST的區別

　　A. 從字面意思和HTTP的規範來看，GET用於獲取資源信息而POST是用來更新資源信息。

　　B. GET提交請求的數據實體會放在URL的後面，用?來分割，參數用&連接，舉個栗子：/index.html?name=wang&login=1。POST方法是把提交的數據放在HTTP包的Body中.

　　C. GET提交的數據長度是有限制的，因爲URL長度有限制，具體的長度限制視瀏覽器而定。而POST沒有。

　　D. GET提交的數據不安全，因爲參數都會暴露在URL上。