整合營銷服務商

          電腦端+手機端+微信端=數據同步管理

          免費咨詢熱線:

          十分鐘能看清-HTTP詳解-請求、響應、緩存

          . HTTP請求格式

          做過Socket編程的人都知道,當我們設計一個通信協議時,“消息頭/消息體”的分割方式是很常用的,消息頭告訴對方這個消息是干什么的,消息體告訴對 方怎么干。HTTP協議傳輸的消息也是這樣規定的,每一個HTTP包都分為HTTP頭和HTTP體兩部分,消息體是可選的,而消息頭是必須的。每當我們打 開一個網頁,在上面點擊右鍵,選擇“查看源文件”,這時看到的HTML代碼就是HTTP的消息體,那么消息頭可以通過瀏覽器的開發工具或者插件可以看到, 如果火狐的Firebug,IE的Httpwatch。

          客戶端通過發送 HTTP 請求向服務器請求對資源的訪問。 它向服務器傳遞了一個數據塊,也就是請求信息,HTTP 請求由三部分組成:請求行、 請求頭和請求正文。

          請求行:請求方法 URI 協議/版本

          請求頭(Request Header)

          請求正文

          下面是一個HTTP請求的數據:

          POST /index.php HTTP/1.1

          Host: localhost

          User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20100101 Firefox/10.0.2

          Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

          Accept-Language: zh-cn,zh;q=0.5

          Accept-Encoding: gzip, deflate

          Connection: keep-alive

          Referer: http://localhost/

          Content-Length:25

          Content-Type:application/x-www-form-urlencoded

          username=aa&password=1234

          1、請求行:請求方法URI協議/版本

          請求的第一行是“方法 URL 協議/版本”,并以 回車換行作為結尾。請求行以空格分隔。格式如下:

          POST /index.php HTTP/1.1

          以上代碼中“GET”代表請求方法,“//ndex.php”表示URI,“HTTP/1.1代表協議和協議的版本。

          根據HTTP標準,HTTP請求可以使用多種請求方法。例如:HTTP1.1支持7種請求方法:GET、POST、HEAD、OPTIONS、PUT、DELETE和TARCE。在Internet應用中,最常用的方法是GET和POST。

          URL完整地指定了要訪問的網絡資源,通常只要給出相對于服務器的根目錄的相對目錄即可,因此總是以“/”開頭,最后,協議版本聲明了通信過程中使用HTTP的版本。

          請求方法

          在 HTTP 協議中,HTTP 請求可以使用多種請求方法,這些方法指明了要以何種方式來訪問 Request-URI 所標識的資源。HTTP1.1 支持的請求方法如下表所示:

          HTTP1.1 中的請求方式:

          方法

          作用

          GET

          請求獲取由 Request-URI 所標識的資源

          POST

          請求服務器接收在請求中封裝的實體,并將其作為由 Request-Line 中的 Request-URI 所標識的資源的一部分

          HEAD

          請求獲取由 Request-URI 所標識的資源的響應消息報頭

          PUT

          請求服務器存儲一個資源,并用 Request-URI 作為其標識符

          DELETE

          請求服務器刪除由 Request-URI 所標識的資源

          TRACE

          請求服務器回送到的請求信息,主要用于測試或診斷

          CONNECT

          保留將來使用

          OPTIONS

          請求查詢服務器的性能,或者查詢與資源相關的選項和需求

          重點介紹 GET、POST 和 HEAD 三個方法:

          (1)GET

          GET 方法用于獲取由 Request-URI 所標識的資源的信息,常見的形式是:

          GET Request-URI HTTP/1.1

          GET方法是默認的HTTP請求方法,例如當我們通過在瀏覽器的地址欄中直接輸入網址的方式去訪問網頁的時候,瀏覽器采用的就是 GET 方法向服務器獲取資源。

          我們可以使用GET方法來提交表單數據,用GET方法提交的表單數據只經過了簡單的編碼,同時它將作為URL的一部分向服務器發送,因此,如果使用GET方法來提交表單數據就存在著安全隱患上。例如:

          Http://localhost/login.php?username=aa&password=1234

          從上面的URL請求中,很容易就可以辯認出表單提交的內容。(?之后的內容)另外由于GET方法提交的數據是作為URL請求的一部分所以提交的數據量不能太大。這是因為瀏覽器對url的長度有限制

          各種瀏覽器也會對url的長度有所限制,下面是幾種常見瀏覽器的url長度限制:(單位:字符)

          IE : 2803

          Firefox:65536

          Chrome:8182

          Safari:80000

          Opera:190000

          (2)POST

          POST方法是GET方法的一個替代方法,它主要是向Web服務器提交表單數據,尤其是大批量的數據。 在請求頭信息結束之后的兩個回車換行之后(實際是空一行),就是表單提交的數據。如上面提到的post表單數據:

          username=aa&password=1234

          POST方法克服了GET方法的一些缺點。通過POST方法提交表單數據時,數據不是作為URL請求的一部分而是作為標準數據傳送給Web服務器,這就克 服了GET方法中的信息無法保密和數據量太小的缺點。因此,出于安全的考慮以及對用戶隱私的尊重,通常表單提交時采用POST方法。

            從編程的角度來講,如果用戶通過GET方法提交數據,則數據存放在QUERY_STRING環境變量中,而POST方法提交的數據則可以從標準輸入流中獲取。

          GET與POST方法有以下區別:

          1、 在客戶端,Get方式在通過URL提交數據,數據在URL中可以看到;POST方式,數據放在HTTP包的body中。

          2、 GET方式提交的數據大小有限制(因為瀏覽器對URL的長度有限制),而POST則沒有此限制。

          3、安全性問題。正如在(1)中提到,使用 Get 的時候,參數會顯示在地址欄上,而 Post 不會。所以,如果這些數據是中文數據而且是非敏感數據,那么使用 get;如果用戶輸入的數據不是中文字符而且包含敏感數據,那么還是使用 post為好。

          4.、服務器取值方式不一樣。GET方式取值,如php可以使用$_GET來取得變量的值,而POST方式通過$_POST來獲取變量的值。

          (3)HEAD

          HEAD 方法與 GET 方法幾乎是相同的,它們的區別在于 HEAD 方法只是請求消息報頭,而不是完整的內容。對于 HEAD 請求的回應部分來說,它的 HTTP 頭部中包含的信息與通過 GET 請求所得到的信息是相同的。利用這個方法,不必傳輸整個資源內容,就可以得到 Request-URI 所標識的資源的信息。這個方法通常被用于測試超鏈接的有效性,是否可以訪問,以及最近是否更新。

          要注意的是,在 HTML 文檔中,書寫 get 和 post,大小寫都可以,但在 HTTP 協議中的 GET 和 POST 只能是大寫形式。

          2. 請求頭

          每個頭域由一個域名,冒號(:)和域值三部分組成。域名是大小寫無關的,域值前可以添加任何數量的空格符,頭域可以被擴展為多行,在每行開始處,使用至少一個空格或制表符。

          HTTP最常見的請求頭如下:

          Transport 頭域

          Connection:

          作用:表示是否需要持久連接。

          如果服務器看到這里的值為“Keep-Alive”,或者看到請求使用的是HTTP 1.1(HTTP 1.1默認進行持久連接),它就可以利用持久連接的優點,當頁面包含多個元素時(例如Applet,圖片),顯著地減少下載所需要的時間。要實現這一點,服務器需要在應答中發送一個Content-Length頭,最簡單的實現方法是:先把內容寫入 ByteArrayOutputStream,然后在正式寫出內容之前計算它的大小;

          例如: Connection: keep-alive 當一個網頁打開完成后,客戶端和服務器之間用于傳輸HTTP數據的TCP連接不會關閉,如果客戶端再次訪問這個服務器上的 網頁,會繼續使用這一條已經建立的連接

          例如: Connection: close 代表一個Request完成后,客戶端和服務器之間用于傳輸HTTP數據的TCP連接會關閉, 當客戶端再次發送Request,需要重新建立TCP連接。

          Host(發送請求時,該報頭域是必需的)

          Host請求報頭域主要用于指定被請求資源的Internet主機和端口號,它通常從HTTP URL中提取出來的。

          eg:http://;localhost/index.html

          瀏覽器發送的請求消息中,就會包含Host請求報頭域,如下:

          Host:localhost

          此處使用缺省端口號80,若指定了端口號8080,則變成:Host:localhost:8080

          Client 頭域

          Accept:

          作用:瀏覽器可以接受的媒體類型(MIME類型),

          例如: Accept: text/html 代表瀏覽器可以接受服務器回發的類型為 text/html 也就是我們常說的html文檔, 如果服務器無法返回text/html類型的數據,服務器應該返回一個406錯誤(non acceptable)。

          通配符 * 代表任意類型。例如 Accept: */* 代表瀏覽器可以處理所有類型,(一般瀏覽器發給服務器都是發這個)

          Accept-Encoding:

          作用: 瀏覽器申明自己接收的編碼方法,通常指定壓縮方法,是否支持壓縮,支持什么壓縮方法(gzip,deflate),(注意:這不是只字符編碼);

          例如: Accept-Encoding: gzip, deflate。Server能夠向支持gzip/deflate的瀏覽器返回經gzip或者deflate編碼的HTML頁面。 許多情形下這可以減少5到10倍的下載時間,也節省帶寬。

          Accept-Language:

          作用: 瀏覽器申明自己接收的語言。

          語言跟字符集的區別:中文是語言,中文有多種字符集,比如big5,gb2312,gbk等等;

          例如: Accept-Language:zh-cn 。如果請求消息中沒有設置這個報頭域,服務器假定客戶端對各種語言都可以接受。

          User-Agent:

          作用:告訴HTTP服務器, 客戶端使用的操作系統和瀏覽器的名稱和版本.

          我們上網登陸論壇的時候,往往會看到一些歡迎信息,其中列出了你的操作系統的名稱和版本,你所使用的瀏覽器的名稱和版本,這往往讓很多人感到很神 奇,實際上, 服務器應用程序就是從User-Agent這個請求報頭域中獲取到這些信息User-Agent請求報頭域允許客戶端將它的操作系統、瀏覽 器和其它屬性告訴服務器。

          例如: User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; CIBA; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; InfoPath.2; .NET4.0E)

          Accept-Charset:

          作用:瀏覽器申明自己接收的字符集,這就是本文前面介紹的各種字符集和字符編碼,如gb2312,utf-8(通常我們說Charset包括了相應的字符編碼方案);

          例如:Accept-Charset:iso-8859-1,gb2312.如果在請求消息中沒有設置這個域,缺省是任何字符集都可以接受。

          Authorization:授權信息,通常出現在對服務器發送的WWW-Authenticate頭的應答中;

          Authorization請求報頭域主要用于證明客戶端有權查看某個資源。當瀏覽器訪問一個頁面時,如果收到服務器的響應代碼為401(未授權),可以發送一個包含Authorization請求報頭域的請求,要求服務器對其進行驗證。

          Cookie/Login 頭域

          Cookie:

          作用: 最重要的header, 將cookie的值發送給HTTP 服務器

          Entity頭域

          Content-Length

          作用:發送給HTTP服務器數據的長度。即請求消息正文的長度;

          例如: Content-Length: 38

          Content-Type:

          作用:

          例如:Content-Type: application/x-www-form-urlencoded

          Miscellaneous 頭域

          Referer:

          作用: 提供了Request的上下文信息的服務器,告訴服務器我是從哪個鏈接過來的,比如從我主頁上鏈接到一個朋友那里, 他的服務器就能夠從HTTP Referer中統計出每天有多少用戶點擊我主頁上的鏈接訪問 他的網站。

          例如: Referer:http://translate.google.cn/?hl=zh-cn&tab=wT

          Cache 頭域

          If-Modified-Since:

          作用: 把瀏覽器端緩存頁面的最后修改時間發送到服務器去,服務器會把這個時間與服務器上實際文件的最后修改時間進行對比。如果時間一致,那么返回304,客戶端 就直接使用本地緩存文件。如果時間不一致,就會返回200和新的文件內容。客戶端接到之后,會丟棄舊文件,把新文件緩存起來,并顯示在瀏覽器中。

          例如:If-Modified-Since: Thu, 09 Feb 2012 09:07:57 GMT。

          If-None-Match:

          作用: If-None-Match和ETag一起工作,工作原理是在HTTP Response中添加ETag信息。 當用戶再次請求該資源時,將在HTTP Request 中加入If-None-Match信息(ETag的值)。如果服務器驗證資源的ETag沒有改變(該資源沒有更新),將返回一個304狀態告訴客戶端使用 本地緩存文件。否則將返回200狀態和新的資源和Etag. 使用這樣的機制將提高網站的性能

          例如: If-None-Match: "03f2b33c0bfcc1:0"

          Pragma:

          作用: 防止頁面被緩存, 在HTTP/1.1版本中,它和Cache-Control:no-cache作用一模一樣

          Pargma只有一個用法, 例如: Pragma: no-cache

          注意: 在HTTP/1.0版本中,只實現了Pragema:no-cache, 沒有實現Cache-Control

          Cache-Control:

          作用: 這個是非常重要的規則。 這個用來指定Response-Request遵循的緩存機制。各個指令含義如下

          Cache-Control:Public 可以被任何緩存所緩存()

          Cache-Control:Private 內容只緩存到私有緩存中

          Cache-Control:no-cache 所有內容都不會被緩存

          2. HTTP響應格式

          在接收和解釋請求消息后,服務器會返回一個 HTTP 響應消息。與 HTTP 請求類似,HTTP 響應也是由三個部分組成,分別是:狀態行、消息報頭和響應正文。如:

          HTTP/1.1 200 OK

          Date: Sun, 17 Mar 2013 08:12:54 GMT

          Server: Apache/2.2.8 (Win32) PHP/5.2.5

          X-Powered-By: PHP/5.2.5

          Set-Cookie: PHPSESSID=c0huq7pdkmm5gg6osoe3mgjmm3; path=/

          Expires: Thu, 19 Nov 1981 08:52:00 GMT

          Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0

          Pragma: no-cache

          Content-Length: 4393

          Keep-Alive: timeout=5, max=100

          Connection: Keep-Alive

          Content-Type: text/html; charset=utf-8

          <html>

          <head>

          <title>HTTP響應示例<title>

          </head>

          <body>

          Hello HTTP!

          </body>

          </html>

          1、狀態行

          狀態行由協議版本、數字形式的狀態代碼,及相應的狀態描述組成,各元素之間以空格分隔,結尾時回車換行符,格式如下:

          HTTP-Version Status-Code Reason-Phrase CRLF

          HTTP-Version 表示服務器 HTTP 協議的版本,Status-Code 表示服務器發回的響應代碼,Reason-Phrase 表示狀態代碼的文本描述,CRLF 表示回車換行。例如:

          HTTP/1.1 200 OK (CRLF)

          狀態代碼與狀態描述

          狀態代碼由 3 位數字組成, 表示請求是否被理解或被滿足,狀態描述給出了關于狀態碼的簡短的文字描述。狀態碼的第一個數字定義了響應類別,后面兩位數字沒有具體分類。第一個數字有 5 種取值,如下所示。

          • 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 //服務器當前不能處理客戶端的請求,一段時間后可能恢復正常

          2、響應正文

          響應正文就是服務器返回的資源的內容,響應頭和正文之間也必須用空行分隔。如:

          1. <html>
          2. <head>
          3. <title>HTTP響應示例<title>
          4. </head>
          5. <body>
          6. Hello HTTP!
          7. </body>
          8. </html>

          3 、響應頭信息

          HTTP最常見的響應頭如下所示:

          Cache頭域

          Date:

          作用:生成消息的具體時間和日期,即當前的GMT時間。

          例如: Date: Sun, 17 Mar 2013 08:12:54 GMT

          Expires:

          作用: 瀏覽器會在指定過期時間內使用本地緩存,指明應該在什么時候認為文檔已經過期,從而不再緩存它。

          例如: Expires: Thu, 19 Nov 1981 08:52:00 GMT  

          Vary

          作用:

          例如: Vary: Accept-Encoding

          Cookie/Login 頭域

          P3P

          作用: 用于跨域設置Cookie, 這樣可以解決iframe跨域訪問cookie的問題

          例如: P3P: CP=CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR

          Set-Cookie

          作用: 非常重要的header, 用于把cookie 發送到客戶端瀏覽器, 每一個寫入cookie都會生成一個Set-Cookie.

          例如: Set-Cookie: PHPSESSID=c0huq7pdkmm5gg6osoe3mgjmm3; path=/

          Entity實體頭域:

          實體內容的屬性,包括實體信息類型,長度,壓縮方法,最后一次修改時間,數據有效性等。

          ETag:

          作用: 和If-None-Match 配合使用。 (實例請看上節中If-None-Match的實例)

          例如: ETag: "03f2b33c0bfcc1:0"

          Last-Modified:

          作用: 用于指示資源的最后修改日期和時間。(實例請看上節的If-Modified-Since的實例)

          例如: Last-Modified: Wed, 21 Dec 2011 09:09:10 GMT

          Content-Type:

          作用:WEB服務器告訴瀏覽器自己響應的對象的類型和字符集,

          例如:

          Content-Type: text/html; charset=utf-8

            Content-Type:text/html;charset=GB2312

            Content-Type: image/jpeg

          Content-Length:

          指明實體正文的長度,以字節方式存儲的十進制數字來表示。在數據下行的過程中,Content-Length的方式要預先在服務器中緩存所有數據,然后所有數據再一股腦兒地發給客戶端。

            例如: Content-Length: 19847

          Content-Encoding:

          作用:文檔的編碼(Encode)方法。一般是壓縮方式。

          WEB服務器表明自己使用了什么壓縮方法(gzip,deflate)壓縮響應中的對象。利用gzip壓縮文檔能夠顯著地減少HTML文檔的下載時間。

          例如:Content-Encoding:gzip

          Content-Language:

          作用: WEB服務器告訴瀏覽器自己響應的對象的語言者

          例如: Content-Language:da

          Miscellaneous 頭域

          Server:

          作用:指明HTTP服務器的軟件信息

          例如:Apache/2.2.8 (Win32) PHP/5.2.5

          X-Powered-By:

          作用:表示網站是用什么技術開發的

          例如: X-Powered-By: PHP/5.2.5

          Transport頭域

          Connection:

          例如: Connection: keep-alive 當一個網頁打開完成后,客戶端和服務器之間用于傳輸HTTP數據的TCP連接不會關閉,如果客戶端再次訪問這個服務器上的網頁,會繼續使用這一條已經建立的連接

          例如: Connection: close 代表一個Request完成后,客戶端和服務器之間用于傳輸HTTP數據的TCP連接會關閉, 當客戶端再次發送Request,需要重新建立TCP連接。

          Location頭域

          Location:

          作用: 用于重定向一個新的位置, 包含新的URL地址

          實例請看304狀態實例

          HTTP協議是無狀態的和Connection: keep-alive的區別

            無狀態是指協議對于事務處理沒有記憶能力,服務器不知道客戶端是什么狀態。從另一方面講,打開一個服務器上的網頁和你之前打開這個服務器上的網頁之間沒有任何聯系。

            HTTP是一個無狀態的面向連接的協議,無狀態不代表HTTP不能保持TCP連接,更不能代表HTTP使用的是UDP協議(無連接)。

            從HTTP/1.1起,默認都開啟了Keep-Alive,保持連接特性,簡單地說,當一個網頁打開完成后,客戶端和服務器之間用于傳輸HTTP數據的TCP連接不會關閉,如果客戶端再次訪問這個服務器上的網頁,會繼續使用這一條已經建立的連接。

            Keep-Alive不會永久保持連接,它有一個保持時間,可以在不同的服務器軟件(如Apache)中設定這個時間。

          3. 瀏覽器緩存

          瀏覽器緩存:包括頁面html緩存和圖片js,css等資源的緩存。如下圖,瀏覽器緩存是基于把頁面信息保存到用戶本地電腦硬盤里。

          1、緩存的優點:

          1)服務器響應更快:因為請求從緩存服務器(離客戶端更近)而不是源服務器被相應,這個過程耗時更少,讓服務器看上去響應更快。

          2)減少網絡帶寬消耗:當副本被重用時會減低客戶端的帶寬消耗;客戶可以節省帶寬費用,控制帶寬的需求的增長并更易于管理。

          2、緩存工作原理

          頁面緩存狀態是由http header決定的,一個瀏覽器請求信息,一個是服務器響應信息。主要包括Pragma: no-cache、Cache-Control、 Expires、 Last-Modified、If-Modified-Since。其中Pragma: no-cache由HTTP/1.0規定,Cache-Control由HTTP/1.1規定。

          工作原理圖:

          從圖中我們可以看到原理主要分三步:

          1. 第一次請求:瀏覽器通過http的header報頭,附帶Expires,Cache-Control,Last-Modified/Etag向服務器請求,此時服務器記錄第一次請求的Last-Modified/Etag
          2. 再次請求:當瀏覽器再次請求的時候,請求頭附帶Expires,Cache-Control,If-Modified-Since/Etag向服務器請求
          3. 服務器根據第一次記錄的Last-Modified/Etag和再次請求的If-Modified-Since/Etag做對比,判斷是否需要更新,服務器通過這兩個頭判斷本地資源未發生變化,客 戶端不需要重新下載,返回304響應。常見流程如下圖所示:

          與緩存相關的HTTP擴展消息頭

          Expires:設置頁面過期時間,格林威治時間GMT

          Cache-Control:更細致的控制緩存的內容

          Last-Modified:請求對象最后一次的修改時間 用來判斷緩存是否過期 通常由文件的時間信息產生

          ETag:響應中資源的校驗值,在服務器上某個時段是唯一標識的。ETag是一個可以 與Web資源關聯的記號(token),和Last-Modified功能才不多,也是一個標識符,一般和Last-Modified一起使用,加強服務器判斷的準確度。

          Date:服務器的時間

          If-Modified-Since:客戶端存取的該資源最后一次修改的時間,用來和服務器端的Last-Modified做比較

          If-None-Match:客戶端存取的該資源的檢驗值,同ETag。

          Cache-Control的主要參數

          Cache-Control: private/public Public 響應會被緩存,并且在多用戶間共享。 Private 響應只能夠作為私有的緩存,不能再用戶間共享。

          Cache-Control: no-cache:不進行緩存

          Cache-Control: max-age=x:緩存時間 以秒為單位

          Cache-Control: must-revalidate:如果頁面是過期的 則去服務器進行獲取。

          2、關于圖片,css,js,flash的緩存

          這個主要通過服務器的配置來實現這個技術,如果使用apache服務器的話,可以使用mod_expires模塊來實現:

          編譯mod_expires模塊:

          Cd /root/httpd-2.2.3/modules/metadata

          /usr/local/apache/bin/apxs -i -a -c mod_expires.c //編譯

          編輯httpd.conf配置:添加下面內容

          <IfModule mod_expires.c>

          ExpiresActive on

          ExpiresDefault "access plus 1 month"

          ExpiresByType text/html "access plus 1 months"

          ExpiresByType text/css "access plus 1 months"

          ExpiresByType image/gif "access plus 1 months"

          ExpiresByType image/jpeg "access plus 1 months"

          ExpiresByType image/jpg "access plus 1 months"

          ExpiresByType image/png "access plus 1 months"

          EXpiresByType application/x-shockwave-flash "access plus 1 months"

          EXpiresByType application/x-javascript "access plus 1 months"

          #ExpiresByType video/x-flv "access plus 1 months"

          </IfModule>

          解釋:第一句--開啟服務

          第二句--默認時間是一個月

          在下面是關于各種類型的資源的緩存時間設置

          我們開發Web應用的時候,會用到大量的js、css、image、html等靜態資源資源。

          靜態資源映射


          默認情況下,我們只需要將靜態資源放在一下幾個目錄中就可以直接通過url在瀏覽器中訪問了。

          • /META-INF/resources/
          • /resources/
          • /static/
          • /public/

          如果這四個目錄中有相同的靜態資源文件,那么優先訪問哪個目錄下面的資源啊?

          靜態資源的默認訪問優先級:/META-INF/resources/>/resources/>/static/>/public/

          在四個目錄中都放一個static.html的文件,每個html文件中都說明自己所在的目錄,訪問結果如下:

          SpringBoot關于靜態資源的訪問涉及到了application.properties中的兩個屬性:

          # 默認值為 /*
          spring.mvc.static-path-pattern= #這里設置靜態資源匹配的url-pattern
          # 默認值為 classpath:/META-INF/resources/,classpath:/resources/,classpath:/static/,classpath:/public/ 
          spring.resources.static-locations= #這里設置要指向的路徑,多個使用英文逗號隔開,在前面的優先級高
          

          此時,我們豁然開朗,知道默認情況下靜態資源為什么放在/META-INF/resources/、/resources/、/static/、/public/這四個目錄了,還有這四個目錄訪問的優先級是怎么來的了。

          修改靜態資源映射的方法:

          • 我們可以修改這兩個屬性來改變靜態資源的映射,比如我們的所有靜態資源都在mystatic目錄中,并且我們希望訪問靜態資源的的url都帶有/mystatic/這個目錄前綴:
          spring.mvc.static-path-pattern=/mystatic/*
          spring.resources.static-locations= classpath:mystatic/
          

          在resources資源目錄中創建一個mystatic目錄,在該目錄下面創建一個static.html文件,訪問結果如下:

          • 繼承WebMvcConfigurerAdapter類,并且重寫addResourceHandlers方法就行,該操作與上面的方法得到的效果是一樣的


          注意:還可以設置外部磁盤目錄,設置方式不變,格式如下:file:d/mystatic/。

          WebJars


          WebJars將前端資源(css,js,image,html等等)打包到jar中,然后使用基于JVM的包管理器(比如 Maven、Gradle 等)管理前端依賴的方案。SpringBoot中也可以通過WebJars來訪問靜態資源。

          SpringBoot默認將/webjars/**映射到 classpath:/META-INF/resources/webjars/。

          • /webjars/**:表示/webjars/目錄下的所有文件,及存在其目錄下的jar包中的所有文件。

          所以默認情況下我們需要訪問WebJars中的資源,需要將其jar包放到classpath:/META-INF/resources/webjars/目錄中。

          我們來使用一下WebJars:

          • 在pom.xml中引入jquery的WebJars,默認會被放在classpath:/META-INF/resources/webjars/目錄中
           <dependency>
           <groupId>org.webjars</groupId>
           <artifactId>jquery</artifactId>
           <version>2.1.1</version>
           </dependency>
          
          • 在前端webjars.html頁面中引入jquery
          <script src="/webjars/jquery/2.1.1/jquery.js"></script>
          
          • 訪問頁面webjars.html,查看源碼,可以鏈接到jquery.js的內容


          版本號統一管理


          如果我們有很多頁面都是用了WebJars中的資源,而我們現在要升級WebJars的版本,豈不是要在每個頁面中都改動一下,這樣很麻煩啊,有沒有簡單的方法啊。此時,我們可以進行版本號統一管理。

          • 在pom.xml中引入jquery的WebJars的基礎上添加:
           <dependency>
           <groupId>org.webjars</groupId>
           <artifactId>webjars-locator</artifactId>
           </dependency>
          
          • 添加版本號統一管理的控制器


          • 在頁面中引入jquery的方式如下:
          <script src="/webjarslocator/jquery/jquery.js"></script>
          

          靜態資源版本管理


          當我們資源內容發生變化時,由于瀏覽器緩存,用戶本地的靜態資源還是舊的資源,為了防止這種情況導致的問題,我們可能會手動在請求url的時候加個版本號或者其他方式。

          <script type="text/javascript" src="/lavor.js?v=1.1"></script>
          

          SpringMVC提供了兩種方式可以幫助我們很容易地解決這類問題。

          MD5方式


          • 修改application.properties配置文件
          spring.resources.chain.strategy.content.enabled=true
          spring.resources.chain.strategy.content.paths=/**
          
          • 添加@ControllerAdvice注解,返回ResourceUrlProvider的對象,這樣所有通過控制器返回的模板頁面(jsp,thymeleaf,freeemarker等)就都可以在頁面中使用該對象了


          • 在控制器返回的模板頁面中,添加以下信息,我們這里的返回頁面時jsp頁面,lavor.js是webapp目錄下面的js腳本文件。
          <script src="${urls.getForLookupPath('/lavor.js') }"></script>
          
          • 通過瀏覽器訪問控制器的請求url,查看頁面源代碼
          <script src="/lavor-fdfa0502716d517c6cad4f2536aa02a1.js"></script>
          

          請求/lavor-fdfa0502716d517c6cad4f2536aa02a1.js,我們MD5配置的paths=/**,所以SpringMVC會嘗試url中是否包含-,如果包含會去掉后面這部分,然后去映射的目錄(如webapp根目錄,上面提到的四大靜態映射目錄)查找/lavor.js文件,如果能找到就返回。

          版本號方式


          • 修改application.properties配置文件,注意MD5方式中的是content,這里是fixed
          spring.resources.chain.strategy.fixed.enabled=true
          #版本號處理的路徑
          spring.resources.chain.strategy.fixed.paths=/**
          # 版本號,可以為所處理路徑中的資源加上/v1.1目錄前綴
          spring.resources.chain.strategy.fixed.version=v1.1
          
          • 添加@ControllerAdvice注解,返回ResourceUrlProvider的對象,這樣所有通過控制器返回的模板頁面(jsp,thymeleaf,freeemarker等)就都可以在頁面中使用該對象了


          • 在控制器返回的模板頁面中,添加以下信息,我們這里的返回頁面時jsp頁面,lavor.js是webapp目錄下面的js腳本文件.
          <script src="${urls.getForLookupPath('/lavor.js') }"></script>
          
          • 通過瀏覽器訪問控制器的請求url,查看頁面源代碼
          <script src="/v1.1/lavor.js"></script>
          

          請求/v1.1/lavor.js,會查看v1.1是不是版本號,如果是就去掉前綴目錄,直接查找/lavor.js。

          注意:我們發現如果添加了webapp目錄,那么該目錄也可以存放靜態資源,并且默認情況下訪問優先級比/META-INF/resources/還要高。

          ndroid高階開發專欄

          Java高級開發進階專欄

          TCP連接的三次握手和四次揮手

          一文搞懂DNS域名解析的詳細流程

          高并發與負載均衡:Nginx的反向代理和負載均衡

          一文搞懂TCP/IP協議及Web基礎知識

          一文搞懂HTTP協議的核心知識點

          一文掌握 HTTP協議報文 包含的信息類型

          一文搞懂HTTP協議 返回結果的HTTP狀態碼

          一文搞懂 HTTP協議的報文首部


          作為網絡專欄的開篇導文,本文概況介紹下經典案例:從輸入一個網址到瀏覽器顯示頁面的全過程。

          步驟概要介紹如下:

          • 1、輸入網址
          • 2、DNS解析獲取域名對應的IP地址
          • 3、建立TCP連接
          • 4、web瀏覽器向web服務器發送HTTP請求
          • 5、服務器的永久重定向響應
          • 6、瀏覽器跟蹤重定向地址
          • 7、web服務器做出應答
          • 8、瀏覽器顯示 HTML
          • 9、瀏覽器發送請求獲取其他嵌入在 HTML 中的資源
          • 10、web服務器關閉TCP連接

          1、輸入網址

          當在瀏覽器中輸入網址時,瀏覽器其實就已在智能匹配 url 了,他會從歷史記錄,書簽等地方,找到已經輸入的字符串可能對應的 url,然后給出智能提示,讓你可以補全url地址。

          對于 google的chrome 的瀏覽器,他甚至會直接從緩存中把網頁展示出來,就是說,你還沒有按下 enter,頁面就出來了。


          2、DNS解析獲取域名對應的IP地址

          請求一旦發起,瀏覽器首先要做的事情就是解析這個域名。

          • 1、一般來說,瀏覽器會首先查看本地硬盤的 hosts 文件,看看其中有沒有和這個域名對應的規則,如果有的話就直接使用 hosts 文件里面的 ip 地址。
          • 2、如果在本地的 hosts 文件沒有能夠找到對應的 ip 地址,瀏覽器會發出一個 DNS請求到本地DNS服務器 。本地DNS服務器一般都是你的網絡接入服務器商提供,比如中國電信,中國移動。
          • 3、查詢你輸入的網址的DNS請求到達本地DNS服務器之后,本地DNS服務器會首先查詢它的緩存記錄,如果緩存中有此條記錄,就可以直接返回結果,此過程是遞歸的方式進行查詢。如果沒有,本地DNS服務器還要向DNS根服務器進行查詢。
          • 4、根DNS服務器沒有記錄具體的域名和IP地址的對應關系,而是告訴本地DNS服務器,你可以到域服務器上去繼續查詢,并給出域服務器的地址。這種過程是迭代的過程。
          • 5、本地DNS服務器繼續向域服務器發出請求,在這個例子中,請求的對象是.com域服務器。.com域服務器收到請求之后,也不會直接返回域名和IP地址的對應關系,而是告訴本地DNS服務器,你的域名的解析服務器的地址。
          • 6、最后,本地DNS服務器向域名的解析服務器發出請求,這時就能收到一個域名和IP地址對應關系,本地DNS服務器不僅要把IP地址返回給用戶電腦,還要把這個對應關系保存在緩存中,以備下次別的用戶查詢時,可以直接返回結果,加快網絡訪問。


          3、建立TCP連接

          在HTTP工作開始之前,web瀏覽器首先要通過網絡與web服務器建立連接,該連接是通過TCP來完成的。

          PS1:為什么要先建立TCP呢?

          因為HTTP是比TCP更高層次的應用層協議,根據規則,只有低層協議建立之后才能進行更高層次協議的連接,因此要先建立TCP連接,一般TCP連接的端口號是80

          PS2:擴展知識點:

          TCP連接的三次握手和斷開的四次揮手 參照站內文章:TCP 三次握手和四次揮手


          4、web瀏覽器向web服務器發送HTTP請求

          建立了TCP連接之后,web瀏覽器就會向web服務器發起一個http請求。

          一個典型的 http request header 一般需要包括請求的方法,例如 GET 或者 POST 等,不常用的還有 PUT 和 DELETE 、HEAD、OPTION以及 TRACE 方法,一般的瀏覽器只能發起 GET 或者 POST 請求。

          客戶端向服務器發起http請求的時候,會有一些請求信息,請求信息包含三個部分:

          • 請求方法URI協議/版本
          • 請求頭(Request Header)
          • 請求正文:

          下面是一個完整的HTTP請求例子:

          GET/sample.jspHTTP/1.1
          Accept:image/gif.image/jpeg,*/*
          Accept-Language:zh-cn
          Connection:Keep-Alive
          Host:localhost
          User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)
          Accept-Encoding:gzip,deflate
          
          username=jinqiao&password=1234

          4.1、請求行

          請求的第一行是“方法URL議/版本”:GET/sample.jsp HTTP/1.1

          4.2、請求頭(Request Header)

          請求頭包含許多有關的客戶端環境和請求正文的有用信息。例如,請求頭可以聲明瀏覽器所用的語言,請求正文的長度等。

          Accept:image/gif.image/jpeg.*/*
          Accept-Language:zh-cn
          Connection:Keep-Alive
          Host:localhost
          User-Agent:Mozila/4.0(compatible:MSIE5.01:Windows NT5.0)
          Accept-Encoding:gzip,deflate.
          

          4.3、請求正文

          請求頭和請求正文之間是一個空行,這個行非常重要,它表示請求頭已經結束,接下來的是請求正文。請求正文中可以包含客戶提交的查詢字符串信息:

          username=jinqiao&password=1234

          5、服務器的永久重定向響應

          服務器給瀏覽器響應一個301永久重定向響應,這樣瀏覽器就會訪問“http://www.google.com/” 而非“http://google.com/”。

          為什么服務器一定要重定向而不是直接發送用戶想看的網頁內容呢?其中一個原因跟搜索引擎排名有關。如果一個頁面有兩個地址,就像http://www.yy.com/和http://yy.com/,搜索引擎會認為它們是兩個網站,結果造成每個搜索鏈接都減少從而降低排名。而搜索引擎知道301永久重定向是什么意思,這樣就會把訪問帶www的和不帶www的地址歸到同一個網站排名下。還有就是用不同的地址會造成緩存友好性變差,當一個頁面有好幾個名字時,它可能會在緩存里出現好幾次。

          重定向原因:

          • 1、網站調整(如改變網頁目錄結構);
          • 2、網頁被移到一個新地址;
          • 3、網頁擴展名改變(如應用需要把.php改成.Html或.shtml)。

          這種情況下,如果不做重定向,則用戶收藏夾或搜索引擎數據庫中舊地址只能讓訪問客戶得到一個404頁面錯誤信息,訪問流量白白喪失;再者某些注冊了多個域名的網站,也需要通過重定向讓訪問這些域名的用戶自動跳轉到主站點等。


          6、瀏覽器跟蹤重定向地址

          現在瀏覽器知道了 "http://www.google.com/"才是要訪問的正確地址,所以它會發送另一個http請求。這里沒有啥好說的


          7、web服務器做出應答

          經過前面的步驟,服務器收到了我們的請求,也處理我們的請求,到這一步,它會把它的處理結果返回,也就是返回一個HTPP響應。

          HTTP響應與HTTP請求相似,HTTP響應也由3個部分構成,分別是:

          • 狀態行
          • 響應頭(Response Header)
          • 響應正文
          HTTP/1.1 200 OK
          Date: Sat, 31 Dec 2005 23:59:59 GMT
          Content-Type: text/html;charset=ISO-8859-1
          Content-Length: 122
          
          <html>
          <head>
          <title>http</title>
          </head>
          <body>
          <!-- body goes here -->
          </body>
          </html>

          7.1、狀態行:

          狀態行由協議版本、數字形式的狀態代碼、及相應的狀態描述,各元素之間以空格分隔。

          格式: HTTP-Version Status-Code Reason-Phrase CRLF

          例如: HTTP/1.1 200 OK \r\n

          -- 協議版本:是用http1.0還是其他版本

          -- 狀態描述:狀態描述給出了關于狀態代碼的簡短的文字描述。比如狀態代碼為200時的描述為 ok

          -- 狀態代碼:狀態代碼由三位數字組成,第一個數字定義了響應的類別,且有五種可能取值。

          狀態代碼具體協議定義如下:

          1xx:信息性狀態碼,表示服務器已接收了客戶端請求,客戶端可繼續發送請求。
          100 Continue
          101 Switching Protocols
          
          2xx:成功狀態碼,表示服務器已成功接收到請求并進行處理。
          200 OK 表示客戶端請求成功
          204 No Content 成功,但不返回任何實體的主體部分
          206 Partial Content 成功執行了一個范圍(Range)請求
          
          3xx:重定向狀態碼,表示服務器要求客戶端重定向。
          301 Moved Permanently 永久性重定向,響應報文的Location首部應該有該資源的新URL
          302 Found 臨時性重定向,響應報文的Location首部給出的URL用來臨時定位資源
          303 See Other 請求的資源存在著另一個URI,客戶端應使用GET方法定向獲取請求的資源
          304 Not Modified 服務器內容沒有更新,可以直接讀取瀏覽器緩存
          307 Temporary Redirect 臨時重定向。與302 Found含義一樣。302禁止POST變換為GET,但實際使用時并不一定,307則更多瀏覽器可能會遵循這一標準,但也依賴于瀏覽器具體實現
          
          4xx:客戶端錯誤狀態碼,表示客戶端的請求有非法內容。
          400 Bad Request 表示客戶端請求有語法錯誤,不能被服務器所理解
          401 Unauthonzed 表示請求未經授權,該狀態代碼必須與 WWW-Authenticate 報頭域一起使用
          403 Forbidden 表示服務器收到請求,但是拒絕提供服務,通常會在響應正文中給出不提供服務的原因
          404 Not Found 請求的資源不存在,例如,輸入了錯誤的URL
          
          5xx:服務器錯誤狀態碼,表示服務器未能正常處理客戶端的請求而出現意外錯誤。
          500 Internel Server Error 表示服務器發生不可預期的錯誤,導致無法完成客戶端的請求
          503 Service Unavailable 表示服務器當前不能夠處理客戶端的請求,在一段時間之后,服務器可能會恢復正常

          7.2、響應頭:

          響應頭部:由關鍵字/值對組成,每行一對,關鍵字和值用英文冒號":"分隔。

          Date: Sat, 31 Dec 2005 23:59:59 GMT
          Content-Type: text/html;charset=ISO-8859-1
          Content-Length: 122

          典型的響應頭字段:

          7.3、響應正文

          包含著我們需要的一些具體信息,比如cookie,html,image,后端返回的請求數據等等。這里需要注意,響應正文和響應頭之間有一行空格,表示響應頭的信息到空格為止。


          8、瀏覽器顯示 HTML

          在瀏覽器沒有完整接受全部HTML文檔時,它就已經開始顯示這個頁面了,瀏覽器是如何把頁面呈現在屏幕上的呢?

          不同瀏覽器可能解析的過程不太一樣,這里我們只介紹webkit的渲染過程。下圖對應的就是WebKit渲染的過程,這個過程包括:

          解析html以構建dom樹 -> 構建render樹 -> 布局render樹 -> 繪制render樹:


          9、瀏覽器發送請求獲取嵌入在 HTML 中的資源(如圖片、音頻、視頻、CSS、JS等等)

          其實這個步驟可以并列在步驟8中,在瀏覽器顯示HTML時,它會注意到需要獲取其他地址內容的標簽。這時,瀏覽器會發送一個獲取請求來重新獲得這些文件。比如我要獲取外圖片,CSS,JS文件等,類似于下面的鏈接:

          圖片:http://static.ak.fbcdn.net/rsrc.php/z12E0/hash/8q2anwu7.gif

          CSS式樣表:http://static.ak.fbcdn.net/rsrc.php/z448Z/hash/2plh8s4n.css

          JavaScript 文件:http://static.ak.fbcdn.net/rsrc.php/zEMOA/hash/c8yzb6ub.js

          這些地址都要經歷一個和HTML讀取類似的過程。所以瀏覽器會在DNS中查找這些域名,發送請求,重定向等等...

          不像動態頁面,靜態文件會允許瀏覽器對其進行緩存。有的文件可能會不需要與服務器通訊,而從緩存中直接讀取,或者可以放到CDN中


          10、web服務器關閉TCP連接

          一般情況下,一旦web服務器向瀏覽器發送了請求數據后,它就要關閉TCP連接,然后如果瀏覽器或者服務器在其頭信息加入這行代碼:

          connection:keep-alive

          這樣TCP連接將依然保持打開狀態,瀏覽器可以繼續通過相同的連接發送請求,保持連接,節省了為每個請求建立新連接所需要的的事件,同時節省了寬帶

          實際上,在HTTP 1.1 版本的新特性中有一點是:默認持久連接節省通信量,只要客戶端、服務端任意一端沒有明確斷開TCP連接,可以發送多次HTTP請求。



          版權說明:摘錄到部分網絡資源,如存在版權問題,請私信聯系處理,謝謝!


          關注頭條號“編程家園”,后續陸續會有更多技術領域(包括并不限于Android進階、Java進階、Kotlin、網絡、Flutter、Python等),以及架構、職業規劃、職業思考等方面資料的免費分享,期待您的關注!


          主站蜘蛛池模板: 亚洲国产老鸭窝一区二区三区 | 99久久精品午夜一区二区| 久久精品一区二区三区不卡| 久久精品无码一区二区三区不卡 | 久久免费精品一区二区| 一区二区三区免费电影| 亚洲AV无码一区二区三区久久精品 | 无码精品人妻一区二区三区中| 精品人妻一区二区三区四区在线 | 久久精品一区二区| 中文字幕精品一区二区三区视频| 精品亚洲福利一区二区| 无码中文字幕乱码一区| 韩国一区二区视频| 中日韩精品无码一区二区三区| 国产激情无码一区二区app| 中文字幕一区二区三| 国产精品毛片一区二区| 亚洲免费视频一区二区三区| 一区二区三区无码高清视频| 日韩A无码AV一区二区三区| 日韩一区二区三区在线精品| 精品不卡一区中文字幕| 一区二区三区在线|日本| 国产韩国精品一区二区三区| 中文字幕一区二区在线播放| 亚洲中文字幕无码一区| 久草新视频一区二区三区| 亚洲av无码不卡一区二区三区| 亚洲熟妇av一区二区三区漫画| 国产午夜精品一区二区三区嫩草| 精品国产免费一区二区三区香蕉 | 久久久国产精品一区二区18禁 | 日本一区高清视频| 一区二区中文字幕在线观看| 国产精品第一区第27页| 一区二区三区观看免费中文视频在线播放| 亚洲制服中文字幕第一区| 亚洲熟女乱色一区二区三区| 国产成人精品一区二三区| 国产一区二区三区在线视頻|