網路篇 - http協議從入門到精通

http協議在我們平時的上網，開發中使用的非常多，是現在最流行的網路協議之一。

 

目錄：

1. 簡介
2. 特點
3. 版本差別
4. URI和URL
5. 請求訊息request
6. 響應訊息response
7. 狀態碼
8. 請求方法
9. session和cookie
10. 一次完整的http請求

 

 

1. 簡介

http協議是Hyper Text Transfer Protocol(超文字傳輸協議)的縮寫，用於從全球資訊網(www)傳輸超文字到本地瀏覽器的傳送協議。它不僅保證計算機正確快速地傳輸超文字文件，還確定傳輸文件中的哪一部分，以及哪部分內容首先顯示(如文字先於圖形)等。

http協議是一個應用層協議，由請求和響應構成，是一個標準的c/s(客戶端/伺服器)模型。

http協議一般承載於傳輸層的tcp協議上，有時也承載於傳輸層的tls/ssl協議之上，這時就是https。

Tips: tls/ssl位於哪一層？

因為tls/ssl增強了tcp服務(更加安全了)，因此tls/ssl應該是運輸層協議。然而實際上，需要使用安全運輸的應用程式(如http)卻把tls/ssl駐留在應用層。tls/ssl協議應該是位於tcp/ip協議與各種應用層協議之間，為資料通訊提供安全支援。

 

 

 

2. 特點

• 簡單快速：客戶端向伺服器發起請求時，只需要傳請求方法和路徑。請求方法包括get、post、put、delete、head，每種方法規定了客戶端與伺服器聯絡的型別。由於http協議簡單，使得http伺服器的程式規模小，因而通訊速度很快。
• 靈活：http允許傳輸任意型別的資料物件，正在傳輸的型別由Content-Type加以標記。
• 無連線：無連線的含義是限制每次連線只處理一個請求。伺服器處理完客戶的請求，並收到客戶的應答後，即斷開連線。採用這種方式可以節省傳輸時間。
• 無狀態：http協議是無狀態協議，無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味著如果後續處理需要前面的資訊，則它必須重傳，這樣可能導致每次連線傳送的資料量增大。另一方面，在伺服器不需要先前資訊時它的應答就較快。
• 支援C/S(Client/Server)模式。

 

 

 

3. 版本差別

第一個http協議誕生於1989年3月，到現在為止總共經歷了3個版本的演化。

 

• 3.1 http 0.9

http 0.9是第一個版本的http協議，已經過時。它的組成極其簡單，只允許客戶端傳送get這一種請求，且不支援請求頭。由於沒有協議頭，造成了http 0.9協議只支援一種內容，即純文字。不過網頁仍然支援用html語言格式化，同時無法插入圖片。

http 0.9具有典型的無狀態性，每個事務獨立進行處理，事務結束時就釋放這個連線。由此可見，http協議的無狀態特點在其第一個版本0.9中已經成型。

 

• 3.2 http 1.0

http協議的第二個版本，第一個在通訊中指定版本號的http協議版本，至今仍被廣泛採用。相對於http 0.9 增加了如下主要特性：

• 請求與響應支援頭域。
• 響應物件以一個響應狀態行開始。
• 響應物件不只限於超文字。
• 開始支援客戶端通過post方法向Web伺服器提交資料，支援get、head、post方法。
• 支援長連線(但預設還是使用短連線)，快取機制，以及身份認證。

 

• 3.3 http 1.1

http協議的第三個版本是http 1.1，是目前使用最廣泛的協議版本。http 1.1引入了許多關鍵效能優化：keepalive連線，chunked編碼傳輸，位元組範圍請求，請求流水線等。

• Persistent Connection（keepalive連線）
  允許http裝置在事務處理結束之後將tcp連線保持在開啟的狀態，以便未來的http請求重用現在的連線，直到客戶端或伺服器端決定將其關閉為止。在http 1.0中使用長連線需要新增請求頭Connection: Keep-Alive，而在http 1.1 所有的連線預設都是長連線，除非特殊宣告不支援(http請求報文首部加上Connection: close)。
• chunked編碼傳輸
  該編碼將實體分塊傳送並逐塊標明長度，直到長度為0塊表示傳輸結束,，這在實體長度未知時特別有用(比如由資料庫動態產生的資料)。
• 位元組範圍請求
  http 1.1支援傳送內容的一部分。比方說，當客戶端已經有內容的一部分，為了節省頻寬，可以只向伺服器請求一部分。該功能通過在請求訊息中引入了range頭域來實現，它允許只請求資源的某個部分。在響應訊息中Content-Range頭域宣告瞭返回的這部分物件的偏移值和長度。如果伺服器相應地返回了物件所請求範圍的內容，則響應碼206(Partial Content)。
• Pipelining（請求流水線）
  A client that supports persistent connections MAY "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server MUST send its responses to those requests in the same order that the requests were received.

什麼時候用長連線，短連線？

長連線多用於操作頻繁，點對點的通訊，而且連線數不能太多情況。每個tcp連線都需要三次握手，這需要時間，如果每個操作都是先連線，再操作的話那麼處理速度會降低很多，所以每個操作完後都不斷開，下次處理時直接傳送資料包就OK了，不用建立t tcp連線。例如：資料庫的連線用長連線， 如果用短連線頻繁的通訊會造成socket錯誤，而且頻繁的socket 建立也是對資源的浪費。

而像web網站的http服務一般都用短連結，因為長連線對於服務端來說會耗費一定的資源，而像web網站這麼頻繁的成千上萬甚至上億客戶端的連線用短連線會更省一些資源，如果用長連線，而且同時有成千上萬的使用者，如果每個使用者都佔用一個連線的話，那可想而知吧。所以併發量大，但每個使用者無需頻繁操作情況下需用短連線好。

那麼這邊說的長連線只是一個連線的複用，避免連線和斷開的開銷，其實不算我們平時說的真正意義上的長連線，還是請求-響應的模式。

而像即時通訊那種長連線，才是真正的長連線，即使客戶端沒有主動請求訊息，伺服器也可以向客戶端推送訊息。

 

• 3.4 http 2.0 

http 2.0是下一代http協議，目前應用還非常少，主要特點有：

• 多路複用(二進位制分幀)
  http 2.0最大的特點：不會改動http的語義，http方法、狀態碼、URI及首部欄位等等，這些核心概念上一如往常。卻能致力於突破上一代標準的效能限制，改進傳輸效能，實現低延遲和高吞吐量。而之所以叫2.0，是在於新增的二進位制分幀層。在二進位制分幀層上，http 2.0會將所有傳輸的資訊分割為更小的訊息和幀，並對它們採用二進位制格式的編碼，其中http.x的首部資訊會被封裝到Headers幀，而我們的request body則封裝到Data幀裡面。http 2.0 通訊都在一個連線上完成，這個連線可以承載任意數量的雙向資料流。相應地，每個資料流以訊息的形式傳送，而訊息由一或多個幀組成，這些幀可以亂序傳送，然後再根據每個幀首部的流識別符號重新組裝。
• 頭部壓縮
  當一個客戶端向相同伺服器請求許多資源時，像來自同一個網頁的影象，將會有大量的請求看上去幾乎同樣的，這就需要壓縮技術對付這種幾乎相同的資訊。
• 隨時復位
  http 1.1一個缺點是當http資訊有一定長度大小資料傳輸時，你不能方便地隨時停止它，中斷tcp連線的代價是昂貴的。使用http 2.0的RST_STREAM將能方便停止一個資訊傳輸，啟動新的資訊，在不中斷連線的情況下提高頻寬利用效率。
• 伺服器端推流: Server Push
  客戶端請求一個資源X，伺服器端判斷也許客戶端還需要資源Z，在無需事先詢問客戶端情況下將資源Z推送到客戶端，客戶端接受到後，可以快取起來以備後用。
• 優先權和依賴
  每個流都有自己的優先順序別，會表明哪個流是最重要的，客戶端會指定哪個流是最重要的，有一些依賴引數，這樣一個流可以依賴另外一個流。優先順序別可以在執行時動態改變，當使用者滾動頁面時，可以告訴瀏覽器哪個影象是最重要的，你也可以在一組流中進行優先篩選，能夠突然抓住重點流。

 

 

 

4. URI和URL

 

• 4.1 簡介

http使用統一資源識別符號(Uniform Resource Identifiers, URI)來傳輸資料和建立連線。URL是一種特殊型別的URI，包含了用於查詢某個資源的足夠的資訊URL，全稱是UniformResourceLocator，中文叫統一資源定位符，是網際網路上用來標識某一處資源的地址。

 

• 4.2 組成

以下面這個URL為例，介紹下普通URL的各部分組成：

https://blog.csdn.net/u014294681/article/details/85333095

從上面的URL可以看出，一個完整的URL包括以下幾部分：

• 1. 協議部分：該URL的協議部分為"https:"，這代表網頁使用的是https協議，在"https"後面的"//"為分隔符。
• 2. 域名部分：該URL的域名部分為"blog.csdn.net"。一個URL中，也可以使用IP地址作為域名使用。
• 3. 埠部分：跟在域名後面的是埠，域名和埠之間使用":"作為分隔符。埠不是一個URL必須的部分，如果省略埠部分，將採用預設埠。預設http的埠號為80，https的埠號為443。
• 4. 虛擬目錄部分：從域名後的第一個"/"開始到最後一個"/"為止，是虛擬目錄部分。虛擬目錄也不是一個URL必須的部分，上述URL的虛擬目錄為"u014294681/article/details/"。
• 5. 檔名部分：從域名後的最後一個"/"開始到"?"為止，是檔名部分，如果沒有"?"，則是從域名後的最後一個"/"開始到"#"為止，是檔案部分，如果沒有"?"和"#"，那麼從域名後的最後一個"/"開始到結束，都是檔名部分。本例中的檔名是"85333095"。檔名部分也不是一個URL必須的部分，如果省略該部分，則使用預設的檔名。
• 6. 錨部分：從"#"開始到最後，都是錨部分，錨部分也不是一個URL必須的部分。
• 7. 引數部分：從"?"開始到"#"為止之間的部分為引數部分，又稱搜尋部分、查詢部分。引數可以允許有多個引數，引數與引數之間用"&"作為分隔符。

 

• 4.3 URI和URL的區別

URI，是uniform resource identifier，統一資源識別符號，用來唯一的標識一個資源。URL是uniform resource locator，統一資源定位器，它是一種具體的URI，即URL可以用來標識一個資源，而且還指明瞭如何locate這個資源。

 

 

 

5. 請求訊息request

 

• 5.1 請求訊息

客戶端傳送一個http請求到伺服器的請求訊息包括以下格式：請求行(request line)、請求頭部(header)、空行和請求資料。

 

看一個例子，手機連線上Charles，不懂的同學可以搜一下Charles教程。

 

看上圖，訪問百度主頁的request：

• 第一部分：請求行，用來說明請求型別，要訪問的資源以及所使用的http版本。get說明請求型別為get，該行的最後一部分說明使用的是http 1.1版本。
• 第二部分：請求頭部，緊接著請求行（即第一行）之後的部分，用來說明伺服器要使用的附加資訊。從第二行起為請求頭部，host將指出請求的目的地。User-Agent，伺服器端和客戶端指令碼都能訪問它，它是客戶端型別檢測邏輯的重要基礎。該資訊由你的客戶端來定義，並且在每個請求中自動傳送等。
• 第三部分：空行，請求頭部後面的空行是必須的。即使第四部分的請求資料為空，也必須有空行。
• 第四部分：請求資料也叫主體，可以新增任意的其他資料，上面的請求資料為空。

 

再來看一個post並帶有請求資料的請求：

可以看到第一行請求行請求方法為post，最後請求頭和空格後是請求資料，上面的請求資料做了加密處理。

 

• 5.2 請求頭部

 

http通用頭：通用頭域包含請求和響應訊息都支援的頭域，通用頭域包含快取頭部Cache-Control、Pragma及資訊性頭部Connection、Date、Transfer-Encoding、Update、Via。

• 1. Cache-Control
  Cache-Control指定請求和響應遵循的快取機制。在請求訊息或響應訊息中設定Cache-Control並不會修改另一個訊息處理過程中的快取處理過程。請求時的快取指令包括no-cache、no-store、max-age、 max-stale、min-fresh、only-if-cached，響應訊息中的指令包括public、private、no-cache、no- store、no-transform、must-revalidate、proxy-revalidate、max-age。
• 2. Pragma
  Pragma頭域用來包含實現特定的指令，最常用的是Pragma:no-cache。在http 1.1協議中，它的含義和Cache- Control:no-cache相同。
• 3. Connection
  Connection表示是否需要持久連線。如果Servlet看到這裡的值為"Keep-Alive"，或者看到請求使用的是http 1.1(http 1.1預設進行持久連線)，它就可以利用持久連線的優點，當頁面包含多個元素時(例如Applet，圖片)，顯著地減少下載所需要的時間。要實現這一點，Servlet需要在應答中傳送一個Content-Length頭，最簡單的實現方法是：先把內容寫入ByteArrayOutputStream，然後在正式寫出內容之前計算它的大小。Close：告訴WEB伺服器或者代理伺服器，在完成本次請求的響應後，斷開連線，不要等待本次連線的後續請求了。Keepalive：告訴WEB伺服器或者代理伺服器，在完成本次請求的響應後，保持連線，等待本次連線的後續請求。Keep-Alive：如果客戶端請求保持連線，則該頭部表明希望 WEB 伺服器保持連線多長時間(秒)，如Keep-Alive：300。
• 4. Date
  Date頭域表示訊息傳送的時間，伺服器響應中要包含這個頭部，因為快取在評估響應的新鮮度時要用到，其時間的描述格式由RFC822定義。例如，Date:Mon, 31 Dec 2001 04:25:57 GMT。Date描述的時間表示世界標準時，換算成本地時間，需要知道使用者所在的時區。
• 5. Transfer-Encoding
  WEB 伺服器表明自己對本響應訊息體(不是訊息體裡面的物件)作了怎樣的編碼，比如是否分塊(chunked)，例如：Transfer-Encoding: chunked。
• 6. Upgrade
  它可以指定另一種可能完全不同的協議，如http 1.1客戶端可以向伺服器傳送一條http 1.0請求，其中包含值為"HTTP/1.1"的Upgrade頭部，這樣客戶端就可以測試一下伺服器是否也使用http 1.1了。
• 7. Via
  列出從客戶端到OCS 或者相反方向的響應經過了哪些代理伺服器，它們用什麼協議和版本傳送的請求。

 

http請求頭：請求頭用於說明是誰或什麼在傳送請求、請求源於何處，或者客戶端的喜好及能力。伺服器可以根據請求頭部給出的客戶端資訊，試著為客戶端提供更好的響應。請求頭域可能包含下列欄位Accept、Accept-Charset、Accept- Encoding、Accept-Language、Authorization、From、Host、If-Modified-Since、If-Match、If-None-Match、If-Range、If-Range、If-Unmodified-Since、Max-Forwards、Proxy-Authorization、Range、Referer、User-Agent。對請求頭域的擴充套件要求通訊雙方都支援，如果存在不支援的請求頭域，一般將會作為實體頭域處理。

• 1. Accept
  告訴WEB伺服器自己接受什麼介質型別，*/* 表示任何型別，type/* 表示該型別下的所有子型別，type/sub-type。
• 2. Accept-Charset
  客戶端告訴伺服器自己能接收的字符集。
• 3. Accept-Encoding
  客戶端宣告自己接收的編碼方法，通常指定壓縮方法，是否支援壓縮，支援什麼壓縮方法(gzip，deflate)。
• 4. Accept-Language
  客戶端宣告自己接收的語言。語言跟字符集的區別：中文是語言，中文有多種字符集，比如big5，gb2312，gbk等等。
• 5. Authorization
  當客戶端接收到來自WEB伺服器的 WWW-Authenticate響應時，用該頭部來回應自己的身份驗證資訊給WEB伺服器。
• 6. If-Match
  如果物件的ETag沒有改變，其實也就意味著物件沒有改變，才執行請求的動作，獲取文件。
• 7. If-None-Match
  如果物件的ETag改變了，其實也就意味著物件也改變了，才執行請求的動作，獲取文件。
• 8. If-Modified-Since
  如果請求的物件在該頭部指定的時間之後修改了，才執行請求的動作(比如返回物件)，否則返回程式碼304，告訴客戶端該物件沒有修改。例如：If-Modified-Since：Thu, 10 Apr 2008 09:14:42 GMT。
• 9. If-Unmodified-Since
  如果請求的物件在該頭部指定的時間之後沒修改過，才執行請求的動作(比如返回物件)。
• 10. If-Range
  客戶端告訴WE 伺服器，如果我請求的物件沒有改變，就把我缺少的部分給我，如果物件改變了，就把整個物件給我。客戶端通過傳送請求物件的ETag或者自己所知道的最後修改時間給WEB伺服器，讓其判斷物件是否改變了。總是跟Range頭部一起使用。
• 11. Range
  客戶端(比如 Flashget 多執行緒下載時)告訴WEB伺服器自己想取物件的哪部分。例如：Range: bytes=1173546。
• 12. Proxy-Authenticate
  代理伺服器響應客戶端，要求其提供代理身份驗證資訊。
• 13. Proxy-Authorization
  客戶端響應代理伺服器的身份驗證請求，提供自己的身份資訊。
• 21. Host
  客戶端指定自己想訪問的WEB伺服器的域名/IP 地址和埠號。
• 22. Referer
  客戶端向WEB伺服器表明自己是從哪個網頁URL獲得點選當前請求中的網址/URL。
• 23. User-Agent
  客戶端表明自己的身份。例如：Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.143 Safari/537.36。

 

 

 

6. 響應訊息response

 

• 6.1 響應訊息

一般情況下，伺服器接收並處理客戶端發過來的請求後會返回一個http的響應訊息。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版本號為http/1.1，狀態碼為200，狀態訊息為"OK"。
• 第二部分：訊息報頭，用來說明客戶端要使用的一些附加資訊。Date：生成響應的日期和時間；Content-Type：指定了MIME型別的html(text/html)，編碼型別是UTF-8。
• 第三部分：空行，訊息報頭後面的空行是必須的。
• 第四部分：響應正文，伺服器返回給客戶端的文字資訊，空行後面的html部分為響應正文。

 

• 6.2 響應頭部

上面說了第二部分為訊息報頭，那麼訊息報頭有哪些呢？

http響應頭：響應頭向客戶端提供一些額外資訊，比如誰在傳送響應、響應者的功能，甚至與響應相關的一些特殊指令。這些頭部有助於客戶端處理響應，並在將來發起更好的請求。響應頭域包含Age、Location、Proxy-Authenticate、Public、Retry- After、Server、Vary、Warning、WWW-Authenticate。對響應頭域的擴充套件要求通訊雙方都支援，如果存在不支援的響應頭域，一般將會作為實體頭域處理。

• 1. Age
  當代理伺服器用自己快取的實體去響應請求時，用該頭部表明該實體從產生到現在經過多長時間了。
• 2. Server
  web伺服器表明自己是什麼軟體及版本等資訊。例如：Server：Apache/2.0.61 (Unix)。
• 3. Accept-Ranges
  web伺服器表明自己是否接受獲取其某個實體的一部分(比如檔案的一部分)的請求。bytes：表示接受，none：表示不接受。
• 4. Vary
  web伺服器用該頭部的內容告Cache伺服器，在什麼條件下才能用本響應所返回的物件響應後續的請求。假如源web伺服器在接到第一個請求訊息時，其響應訊息的頭部為：Content-Encoding: gzip; Vary: Content-Encoding，那麼Cache伺服器會分析後續請求訊息的頭部，檢查其Accept-Encoding，是否跟先前響應的Vary頭部值一致，即是否使用相同的內容編碼方法，這樣就可以防止Cache伺服器用自己Cache 裡面壓縮後的實體響應給不具備解壓能力的瀏覽器。例如：Vary：Accept-Encoding。

 

HTTP實體頭：實體頭部提供了有關實體及其內容的大量資訊，從有關物件型別的資訊，到能夠對資源使用的各種有效的請求方法。總之，實體頭部可以告知接收者它在對什麼進行處理。請求訊息和響應訊息都可以包含實體資訊，實體資訊一般由實體頭域和實體組成。實體頭域包含關於實體的原資訊，實體頭包括資訊性頭部Allow、Location，內容頭部Content-Base、Content-Encoding、Content-Language、Content-Length、Content-Location、Content-MD5、Content-Range、Content-Type，快取頭部Etag、Expires、Last-Modified、extension-header。

• 1. Allow
  伺服器支援哪些請求方法(如get、post等)。
• 2. Location
  表示客戶應當到哪裡去提取文件，用於將接收端定位到資源的位置(URL)上。Location通常不是直接設定的，而是通過HttpServletResponse的sendRedirect方法，該方法同時設定狀態程式碼為302。
• 3. Content-Base
  解析主體中的相對URL時使用的基礎URL。
• 4. Content-Encoding
  web伺服器表明自己使用了什麼壓縮方法(gzip，deflate)壓縮響應中的物件。例如：Content-Encoding：gzip。
• 5. Content-Language
  web伺服器告訴瀏覽器理解主體時最適宜使用的自然語言。
• 6. Content-Length
  web伺服器告訴瀏覽器自己響應的物件的長度或尺寸，例如：Content-Length: 26012。
• 7. Content-Location
  資源實際所處的位置。
• 8. Content-MD5
  主體的MD5校驗。
• 9. Content-Range
  實體頭用於指定整個實體中的一部分的插入位置，它也指示了整個實體的長度。在伺服器向客戶返回一個部分響應，它必須描述響應覆蓋的範圍和整個實體長度。一般格式： Content-Range:bytes-unitSPfirst-byte-pos-last-byte-pos/entity-legth。例如，傳送頭500個位元組次欄位的形式：Content-Range:bytes0- 499/1234如果一個http訊息包含此節(例如，對範圍請求的響應或對一系列範圍的重疊請求)，Content-Range表示傳送的範圍，Content-Length表示實際傳送的位元組數。
• 10. Content-Type
  web伺服器告訴瀏覽器自己響應的物件的型別。例如：Content-Type：application/xml。
• 11. Etag
  就是一個物件(比如URL)的標誌值，就一個物件而言，比如一個html檔案，如果被修改了，其Etag也會別修改，所以，ETag的作用跟Last-Modified的作用差不多，主要供WEB伺服器判斷一個物件是否改變了。比如前一次請求某個html檔案時，獲得了其 ETag，當這次又請求這個檔案時，瀏覽器就會把先前獲得ETag值傳送給WEB伺服器，然後WEB伺服器會把這個ETag跟該檔案的當前ETag進行對比，然後就知道這個檔案有沒有改變了。
• 12. Expires
  web伺服器表明該實體將在什麼時候過期，對於過期了的物件，只有在跟web伺服器驗證了其有效性後，才能用來響應客戶請求。是 http 1.0 的頭部。例如：Expires：Sat, 23 May 2009 10:02:12 GMT。
• 13. Last-Modified
  web伺服器認為物件的最後修改時間，比如檔案的最後修改時間，動態頁面的最後產生時間等等。例如：Last-Modified：Tue, 06 May 2008 02:42:43 GMT。

 

 

 

7. 狀態碼

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

• 1xx：指示資訊 - 表示請求已接收，繼續處理。
• 2xx：成功 - 表示請求已被成功接收、理解、接受。
• 3xx：重定向 - 要完成請求必須進行更進一步的操作。
• 4xx：客戶端錯誤 - 請求有語法錯誤或請求無法實現。
• 5xx：伺服器端錯誤 - 伺服器未能實現合法的請求。

常見狀態碼：

200 OK                        //客戶端請求成功
400 Bad Request               //客戶端請求有語法錯誤，不能被伺服器所理解
401 Unauthorized              //請求未經授權，這個狀態程式碼必須和WWW-Authenticate報頭域一起使用 
403 Forbidden                 //伺服器收到請求，但是拒絕提供服務
404 Not Found                 //請求資源不存在，eg：輸入了錯誤的URL
500 Internal Server Error     //伺服器發生不可預期的錯誤
503 Server Unavailable        //伺服器當前不能處理客戶端的請求，一段時間後可能恢復正常

更多狀態碼 http://www.runoob.com/http/http-status-codes.html

 

 

 

8. 請求方法

 

• 8.1 請求方法

根據http標準，http請求可以使用多種請求方法。
http 1.0定義了三種請求方法： get, post 和head方法。
http 1.1 新增了五種請求方法：options, put, delete, trace 和 connect 方法。

get           請求指定的頁面資訊，並返回實體主體。
head          類似於get請求，只不過返回的響應中沒有具體的內容，用於獲取報頭
post          向指定資源提交資料進行處理請求（例如提交表單或者上傳檔案）。資料被包含在請求體中。POST請求可能會導致新的資源的建立和/或已有資源的修改。
put           從客戶端向伺服器傳送的資料取代指定的文件的內容。
delete        請求伺服器刪除指定的頁面。
connect       HTTP/1.1協議中預留給能夠將連線改為管道方式的代理伺服器。
options       允許客戶端檢視伺服器的效能。
trace         回顯伺服器收到的請求，主要用於測試或診斷。

 

• 8.2 get和post的區別：

 

• 1. get是從伺服器上獲取資料，post是向伺服器傳送資料。get和 post只是一種傳遞資料的方式，get也可以把資料傳到伺服器，它們的本質都是傳送請求和接收結果。只是組織格式和資料量上面有差別，http協議裡面有介紹。
• 2. get是把引數資料佇列加到提交表單的ACTION屬性所指的URL中，值和表單內各個欄位一一對應，在URL中可以看到。post是通過http post機制，將表單內各個欄位與其內容放置在HTML HEADER內一起傳送到ACTION屬性所指的URL地址。使用者看不到這個過程。 因為get設計成傳輸小資料，而且最好是不修改伺服器的資料，所以瀏覽器一般都在位址列裡面可以看到，但post一般都用來傳遞大資料，或比較隱私的資料，所以在位址列看不到，能不能看到不是協議規定，是瀏覽器規定的。
• 3. get傳送的資料量較小，不能大於2KB。post傳送的資料量較大，一般被預設為不受限制。但理論上，IIS4中最大量為80KB，IIS5中為100KB。 post基本沒有限制，我想大家都上傳過檔案，都是用post方式的，但是需要修改form裡面的那個type引數。
• 4. get安全性非常低，post安全性稍微高點。但是如果沒有加密的話，它們安全級別都是一樣的，隨便一個監聽器都可以把所有的資料監聽到。

 

 

 

9. session和cookie

 

• 9.1 session

session在計算機中，尤其是在網路應用中，稱為"會話控制"，session物件儲存特定使用者會話所需的屬性及配置資訊。這樣當使用者在應用程式的web頁之間跳轉時，儲存在session物件中的變數將不會丟失，而是在整個使用者會話中一直存在下去。當使用者請求來自應用程式的web頁時，如果該使用者還沒有會話，則web伺服器將自動建立一個session物件。當會話過期或被放棄後，伺服器將終止該會話。session物件最常見的一個用法就是儲存使用者的首選項，例如，如果使用者指明不喜歡檢視圖形，就可以將該資訊儲存在session物件中。實際上session和cookie是類似的一種維持客戶端和服務會話狀態的技術，不過session安全性要比cookie高，這是因為session的資料是存放在服務端上的，所以相對的也會增加伺服器的壓力，因此session被應用於儲存一些比較隱私的資料，例如使用者名稱密碼和使用者的資料等。

 

• 9.2 cookie

cookie與session最大的區別就是一個是將資料存放在客戶端，一個是將資料存放在服務端。cookie是將資訊都存放在客戶端的瀏覽器記憶體或磁碟中，所以不是很安全，別人可以分析存放在本地的cookie資料來進行使用者資訊的盜竊或進行cookie欺騙。 所以在安全性上session要好一些，session通訊的一般實現形式是通過cookie來實現，與cookie不同的是，session只會儲存一個sessionID在客戶端，不會像cookie那樣將具體的資料儲存在客戶端，session具體的資料只會儲存在服務端上，在Servlet中session資料是被封裝在一個物件裡，而這個物件會被儲存在物件池中，客戶端發生請求時會帶上它的sessionID，服務端就會根據這個sessionID，來從物件池中獲得相應的session物件，從物件中獲得session的具體資料，服務端通過這個session資料來保持或改變與客戶端會話的狀態。

 

• 9.3 session和cookie的區別

 

• cookie資料存放在客戶端上，session資料放在伺服器上。
• cookie不是很安全，別人可以分析存放在本地的cookie並進行cookie欺騙，考慮到安全應當使用session。
• session會在一定時間內儲存在伺服器上。當訪問增多，會比較佔用你伺服器的效能考慮到減輕伺服器效能方面，應當使用cookie。
• 單個cookie儲存的資料不能超過4K，很多瀏覽器都限制一個站點最多儲存20個cookie。

所以建議：
   將登陸資訊等重要資訊存放為session。
   其他資訊如果需要保留，可以放在cookie中。

 

 

 

10. 一次完整的http請求

 

在一次完整的HTTP通訊過程中, Web瀏覽器與Web伺服器之間將完成下列7個步驟：

 

• 10.1 建立TCP連線

在http工作開始之前，客戶端首先要通過網路與伺服器建立連線，該連線是通過tcp來完成的，該協議與ip協議共同構建Internet，即著名的tcp/ip協議族，因此Internet又被稱作是tcp/ip網路。
http是比tcp更高層次的應用層協議，根據規則，只有低層協議建立之後才能進行更高層協議的連線，因此首先要建立tcp連線, 一般tcp連線的埠號是80，tcp連線中我們比較熟悉的就是三次握手。

一旦建立了tcp連線, 客戶端就會向伺服器傳送請求命令：
例如：GET/sample/hello.jsp HTTP/1.1

 

• 10.2 客戶端傳送請求頭資訊

客戶端傳送其請求命令之後，還要以頭資訊的形式向伺服器傳送一些別的資訊，這些資訊用來描述自己。之後客戶端傳送了一空白行來通知伺服器，表示它已經結束了該頭資訊的傳送。若是post請求，還會在傳送完請求頭資訊之後傳送請求體。

 

• 10.3 伺服器應答

客戶端向伺服器發出請求後, 伺服器會向客戶機回送應答。
HTTP/1.1 200 OK
應答的第一部分是協議的版本號和應答狀態碼。

 

• 10.4 伺服器傳送應答頭資訊

正如客戶端會隨同請求傳送關於自身的資訊一樣，伺服器也會隨同應答向使用者傳送關於它自己的資料及被請求的文件，最後以一個空白行來表示頭資訊傳送到此結束。

 

• 10.5 伺服器向客戶端傳送資料

伺服器向瀏覽器傳送頭資訊後，它就以Content-Type應答頭資訊所描述的格式傳送使用者所請求的實際資料。

 

• 10.6 伺服器關閉tcp連線

一般情況下，一旦伺服器向瀏覽器傳送了請求資料，它就要關閉tcp連線。如果請求頭資訊加入了這行程式碼
Connection:keep-alive，tcp連線在傳送後將仍然保持開啟狀態。客戶端可以繼續通過相同的連線傳送請求，保持連線節省了為每個請求建立新連線所需的時間，還節約了網路頻寬。