http協議與https

Http

客戶端發送一個HTTP請求到服務器的請求消息包括以下格式：

**請求行（request line）、請求頭部（header）、空行

和請求數據四個部分組成。**

Get請求例子，使用Charles抓取的request：

GET /562f25980001b1b106000338.jpg HTTP/1.1 
Host img.mukewang.com 
User-Agent Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36 
Accept image/webp,image/*,*/*;q=0.8 Referer http://www.imooc.com/ Accept-Encoding gzip, deflate, sdch 
Accept-Language zh-CN,zh;q=0.8
空行---------------------------------

第一部分：請求行，用來說明請求類型,要訪問的資源以及所使用的HTTP版本.
GET說明請求類型為GET,[/562f25980001b1b106000338.jpg]為要訪問的資源，該行的最后一部分說明使用的是HTTP1.1版本。
第二部分：請求頭部，緊接著請求行（即第一行）之后的部分，用來說明服務器要使用的附加信息
從第二行起為請求頭部，HOST將指出請求的目的地.User-Agent,服務器端和客戶端腳本都能訪問它,它是瀏覽器類型檢測邏輯的重要基礎.該信息由你的瀏覽器來定義,并且在每個請求中自動發送等等
第三部分：空行，請求頭部后面的空行是必須的
即使第四部分的請求數據為空，也必須有空行。
第四部分：請求數據也叫主體，可以添加任意的其他數據。
這個例子的請求數據為空。

POST請求例子，使用Charles抓取的request：

POST / HTTP1.1 
Host：www.wrox.com
User-Agent:Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022) 
Content-Type:application/x-www-form-urlencoded 
Content-Length:40 
Connection: Keep-Alive name=Professional%20Ajax&publisher=Wiley

第一部分：請求行，第一行明了是post請求，以及http1.1版本。
第二部分：請求頭部，第二行至第六行。
第三部分：空行，第七行的空行。
第四部分：請求數據，第八行。

HTTP之請求消息response

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

例子

HTTP/1.1 200 OK 
Date: Fri, 22 May 2009 06:07:21 GMT 
Content-Type: text/html; 
charset=UTF-8 <html> <head></head> <body> <!--body goes here--> </body> </html>

第一部分：狀態行，由HTTP協議版本號，狀態碼，狀態消息三部分組成。
第一行為狀態行，（HTTP/1.1）表明HTTP版本為1.1版本，狀態碼為200，狀態消息為（ok）
第二部分：消息報頭，用來說明客戶端要使用的一些附加信息
第二行和第三行為消息報頭，
Date:生成響應的日期和時間；Content-Type:指定了MIME類型的HTML(text/html),編碼類型是UTF-8
第三部分：空行，消息報頭后面的空行是必須的
第四部分：響應正文，服務器返回給客戶端的文本信息。
空行后面的html部分為響應正文。

Date: Fri, 22 May 2009 06:07:21 GMT Content-Type: text/html; charset=UTF-8

HTTP之狀態碼

狀態代碼有三位數字組成，第一個數字定義了響應的類別，共分五種類別:
1xx：指示信息--表示請求已接收，繼續處理
2xx：成功--表示請求已被成功接收、理解、接受
3xx：重定向--要完成請求必須進行更進一步的操作
4xx：客戶端錯誤--請求有語法錯誤或請求無法實現
5xx：服務器端錯誤--服務器未能實現合法的請求

常見狀態碼：

200 OK 客戶端請求成功。
301 Moved Permanently 請求永久重定向。
302 Moved Temporarily 請求臨時重定向。
304 Not Modified 文件未修改，可以直接使用緩存的文件。
400 Bad Request 由于客戶端請求有語法錯誤，不能被服務器所理解。
401 Unauthorized 請求未經授權，無法訪問。
403 Forbidden 服務器收到請求，但是拒絕提供服務。服務器通常會在響應正文中給出不提供服務的原因。
404 Not Found 請求的資源不存在，比如輸入了錯誤的URL。
500 Internal Server Error 服務器發生不可預期的錯誤，導致無法完成客戶端的請求。
503 Service Unavailable 服務器當前不能夠處理客戶端的請求，在一段時間之后，服務器可能會恢復正常。

會話追蹤：

會話：客戶端向服務器端發起請求到服務端響應客戶端請求的全過程。
會話跟蹤：會話追蹤指的是服務器對用戶響應的監視。

會話跟蹤常用方法：

URL 重寫：URL 重寫技術就是在 URL 結尾添加一個附加數據以標識該會話，把會話 ID 通過 URL 的信息傳遞過去，以便在服務器進行識別不同的用戶。
隱藏表單域：將會話ID添加到HTML表單元素中提交到服務器，此表單元素并不在客戶端顯示。
Cookie：Cookie 是 Web 服務器發送給客戶端的一小段信息，客戶端請求時可以讀取該信息發送給服務器端，進而進行用戶的識別，對于客戶端的每次請求，服務器都會將 Cookie 發送到客戶端，客戶端保存下來，以便下次使用。
Session：在服務器端會創建一個 session 對象，產生一個 sessionID 來標識這個 session 對象，然后將這個 sessionID 放入到 Cookie 中發送到客戶端，下一次訪問時，sessionID 會發送到服務器，在服務器端進行識別不同的用戶。

持久連接：

我們知道 HTTP 協議采用“請求-應答”模式，當使用普通模式，即非 Keep-Alive 模式時，每個請求/應答客戶和服務器都要新建一個連接，完成之后立即斷開連接（HTTP協議為無連接的協議）；當使用 Keep-Alive 模式（又稱持久連接、連接重用）時，Keep-Alive 功能使客戶端到服務器端的連接持續有效，當出現對服務器的后繼請求時，Keep-Alive 功能避免了建立或者重新建立連接。

在 HTTP 1.0 版本中，并沒有官方的標準來規定 Keep-Alive 如何工作，因此實際上它是被附加到 HTTP 1.0協議上，如果客戶端瀏覽器支持 Keep-Alive ，那么就在HTTP請求頭中添加一個字段 Connection: Keep-Alive，當服務器收到附帶有 Connection: Keep-Alive 的請求時，它也會在響應頭中添加一個同樣的字段來使用 Keep-Alive 。這樣一來，客戶端和服務器之間的HTTP連接就會被保持，不會斷開（超過 Keep-Alive 規定的時間，意外斷電等情況除外），當客戶端發送另外一個請求時，就使用這條已經建立的連接。

在 HTTP 1.1 版本中，默認情況下所有連接都被保持，如果加入 "Connection: close" 才關閉。目前大部分瀏覽器都使用 HTTP 1.1 協議，也就是說默認都會發起 Keep-Alive 的連接請求了，所以是否能完成一個完整的 Keep-Alive 連接就看服務器設置情況。

由于 HTTP 1.0 沒有官方的 Keep-Alive 規范，并且也已經基本被淘汰。

HTTP Keep-Alive 簡單說就是保持當前的TCP連接，避免了重新建立連接。HTTP 是一個無狀態無連接的協議，那么這是不是與 Keep-Alive 沖突？

Keep-Alive 與無連接的特性沖突，而對于無狀態的特性兩者并無矛盾，HTTP 無狀態無連接是在 1.0 版本中就規定的，而 Keep-Alive 則是在 1.1 版本中才被添加入規范。
無連接的意思是限制每個連接只有一個請求的意思，在服務器處理完客戶的請求，并收到客戶的反應，即斷開。通過這種方式可以節省傳輸時間。
Keep-Alive 確實破壞了這一特性，而無狀態協議則意味著每個請求都是獨立的，互不干擾的，互相沒有記憶的。所以才需要有會話跟蹤這種機制來識別用戶。

緩存機制：

HTTP 條件 GET 是 HTTP 協議為了減少不必要的帶寬浪費，提出的一種方案：

HTTP 條件 GET 使用時機：客戶端之前已經訪問過某網站，并打算再次訪問該站點。
HTTP 條件 GET 使用的方法：客戶端向服務器發送一個包詢問是否在上一次訪問網站的時間后是否更改了頁面，如果服務器沒有更新，顯然不需要把整個網頁傳給客戶端，客戶端只要使用本地緩存即可，如果服務器對照客戶端給出的時間已經更新了客戶端請求的網頁，則發送這個更新了的網頁給用戶。

下面是一個具體的發送接受報文示例：