http協議 · 學海無涯_究其本質_李東旭

>[danger]什么是HTTP協議? 1. 超文本傳輸協議, 服務器和客戶端的傳送協議 2. HTTP是基于TCP/IP協議來傳輸數據的, 客戶端請求, 服務器響應 >[danger]HTTP協議特點? 1. 簡單快速, 只傳送請求方法和路徑 2. 靈活, 允許傳輸任意類型數據對象, 只需要在請求頭加入Content-Type標記 3. 無長連接, 每次請求和響應結束即會斷開. 4. 無狀態, 代表后面再處理某些參數, 需要進行重新傳輸. 5. 支持客戶端/服務器或者瀏覽器/服務器模式 >[warning]HTTP之URL ---- URL 統一資源定位符 URL: http://www.lidongxu.com:8080/news/index.php?id=5&uid=24618&page=1#name 包含以下幾部分 (1): 協議部分: 有http, https, ftp等 (2): 域名部分: www.lidongxu.com, www代表頂級域名, 也可以使用ip地址作為域名 (3): 端口部分: 作為本服務器提供的一個服務功能(80/8080 web端口, 3306mysql端口等) (4): 目錄部分: 從域名和端口號后每個/都代表一個目錄 (5): 文件名部分: 最后一個/和?之間的即是文件名, 如果沒有說明默認找的是index (6): 參數部分: 從?往后到#之間, 都是傳遞給這個url的參數, 格式是key=value&key=value (7): 錨部分: 一般用于錨點鏈接或者某些路由框架里的路由設置. >[warning]HTTP之Request (請求) ---- 1.請求里包含: (請求行, 請求頭, 空行, 請求數據) ![](https://box.kancloud.cn/631019178b5d94b71456870f012818ee_595x217.png) 2. 例如: (利用抓包工具查看的結果)(或者后臺的日志文件里) ~~~ 1. POST /work/1.php HTTP1.1 2. Host:www.wrox.com 3. 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) 4. Content-Type:application/x-www-form-urlencoded 5. Content-Length:40 6. Connection: Keep-Alive 7. 8. name=Professional%20Ajax&publisher=Wiley ~~~ 3. 看例子和上圖對比看一下, 瀏覽器請求都發送了哪些東西: (1): 1行代碼, 請求方法(POST), URL(/work/1.php), 協議版本HTTP1.1 (2): 2, 3, 4, 5, 6行代碼, 請求頭代碼, 頭部字段名: 對應的值 (3): 7行代碼, 代表空行 (必須有的), 規定 (4): 8行代碼, 請求發送的數據 4. 這就是客戶端/瀏覽器向服務器發送一個請求的東西 >[warning]HTTP之Response (響應) 1. 服務器會向客戶端/瀏覽器作出響應 2. 響應里包括: (狀態行, 消息報頭, 空行, 響應正文) 3. 例如: ``` 1. HTTP/1.1 200 OK 2. Date: Fri, 22 May 2009 06:07:21 GMT 3. Content-Type: text/html; charset=UTF-8 4. 5. <html> <head></head> <body>  </body> </html> ``` 4. 如上例子解釋: (1): 1行代碼, 響應狀態行, 協議, 響應狀態碼, 響應狀態消息 (2): 2, 3行, 消息報頭, 服務端返回給客戶端使用的一些消息 (3): 4行, 空行(規定) (4): 5行, 服務器給客戶端/瀏覽器, 返回的正文數據 >[warning] HTTP之Code (狀態碼) 1. 1xx: 客戶端應當繼續發送請求 2. 2xx: 代表請求已成功被服務器接收、理解、并接受 3. 3xx: 重定向, 要完成請求必須進行更一步的操作 4. 4xx: 客戶端錯誤, 請求錯誤 5. 5xx: 服務端無法正確處理請求, 響應錯誤 6. 常用狀態碼如下: (1): 200: 客戶端請求成功 (2): 400: 語義錯誤, 無法被服務器理解, 請求參數有誤 (3): 401: 請求需要用戶驗證, 包含了 Authorization 證書, 但是被服務器拒絕了 (4): 403: 服務器已經理解請求, 但是拒絕執行它 (5): 404: 請求url不存在 (一般常見于請求路徑拼寫錯誤) (6): 500: 服務器遇到了一個未曾預料的請求, 一般出現在后臺代碼報錯 (7): 502: 網關或者代理服務器請求時, 從服務器接收到了一個無效響應 (8): 503: 服務器過載, 當前無法完成響應, 拒絕客戶端連接 (9): 504: 網關或者代理服務器請求時, 等待響應超時了 >[warning]HTTP之請求方法 ---- HTTP1.0, 三種請求方法： GET POST HEAD HTTP1.1, 新增五種請求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法 ~~~ GET 請求指定頁面, 并返回目標實體上數據 HEAD 類似于GET請求，只不過返回的響應中沒有具體的內容，用于獲取報頭(不常用) POST 向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中 PUT 從客戶端向服務器傳送的數據取代指定的文檔的內容 DELETE 請求服務器刪除指定的頁面 CONNECT HTTP/1.1協議中預留給能夠將連接改為管道方式的代理服務器 OPTIONS 允許客戶端查看服務器的性能 TRACE 回顯服務器收到的請求，主要用于測試或診斷 ~~~ >[danger] HTTP協議缺點 **** 1.通信使用明文不對數據進行加密（內容容易被竊聽） 2.不驗證通信方身份（容易偽裝） 3.無法確定報文完整性（內容易被篡改） >[danger]請求頭和響應頭常用的字段 ---- ![](https://box.kancloud.cn/214477fe799eafa8605f633817650e38_633x407.png) ![](https://box.kancloud.cn/6f69dacfd818db656629117151459783_627x453.png) >[danger]字段總結 --- * Accept：告訴WEB服務器自己接受什么介質類型，/ 表示任何類型，type/* 表示該類型下的所有子類型，type/sub-type。 * Accept-Charset：瀏覽器申明自己接收的字符集 * Accept-Encoding：瀏覽器申明自己接收的編碼方法，通常指定壓縮方法，是否支持壓縮，支持什么壓縮方法（gzip，deflate） * Accept-Language：瀏覽器申明自己接收的語言語言跟字符集的區別：中文是語言，中文有多種字符集，比如big5，gb2312，gbk等等。 * Accept-Ranges：WEB服務器表明自己是否接受獲取其某個實體的一部分（比如文件的一部分）的請求。bytes：表示接受，none：表示不接受。 * Age：當代理服務器用自己緩存的實體去響應請求時，用該頭部表明該實體從產生到現在經過多長時間了。 * Authorization：當客戶端接收到來自WEB服務器的 WWW-Authenticate 響應時，用該頭部來回應自己的身份驗證信息給WEB服務器。 * Cache-Control：請求： * no-cache（不要緩存的實體，要求現在從WEB服務器去取） * max-age：（只接受 Age 值小于 max-age 值，并且沒有過期的對象） * max-stale：（可以接受過去的對象，但是過期時間必須小于 max-stale 值） * min-fresh：（接受其新鮮生命期大于其當前 Age 跟 min-fresh 值之和的緩存對象）下面是響應相關 * public(可以用 Cached 內容回應任何用戶) * private（只能用緩存內容回應先前請求該內容的那個用戶） * no-cache（可以緩存，但是只有在跟WEB服務器驗證了其有效后，才能返回給客戶端） * max-age：（本響應包含的對象的過期時間） * Connection： * close（告訴WEB服務器或者代理服務器，在完成本次請求的響應后，斷開連接，不要等待本次連接的后續請求了） * keepalive（告訴WEB服務器或者代理服務器，在完成本次請求的響應后，保持連接，等待本次連接的后續請求）下面是響應的 * 響應：close（連接已經關閉） * keepalive（連接保持著，在等待本次連接的后續請求） * Keep-Alive：如果瀏覽器請求保持連接，則該頭部表明希望 WEB 服務器保持連接多長時間（秒）例如：Keep-Alive：300 * Content-Encoding：WEB服務器表明自己使用了什么壓縮方法（gzip，deflate）壓縮響應中的對象。例如：Content-Encoding：gzip * Content-Language：WEB 服務器告訴瀏覽器自己響應的對象的語言。 * Content-Length： WEB 服務器告訴瀏覽器自己響應的對象的長度。例如：Content-Length: 26012 * Content-Range： WEB 服務器表明該響應包含的部分對象為整個對象的哪個部分。例如：Content-Range: bytes 21010-47021/47022 * Content-Type： WEB 服務器告訴瀏覽器自己響應的對象的類型。例如：Content-Type：application/xml * ETag：就是一個對象（比如URL）的標志值，就一個對象而言，比如一個 html 文件，如果被修改了，其 Etag 也會別修改，所以ETag 的作用跟 Last-Modified 的作用差不多，主要供 WEB 服務器判斷一個對象是否改變了。比如前一次請求某個 html 文件時，獲得了其 ETag，當這次又請求這個文件時，瀏覽器就會把先前獲得的 ETag 值發送給WEB 服務器，然后 WEB 服務器會把這個 ETag 跟該文件的當前 ETag 進行對比，然后就知道這個文件有沒有改變了。 * Expired：WEB服務器表明該實體將在什么時候過期，對于過期了的對象，只有在跟WEB服務器驗證了其有效性后，才能用來響應客戶請求。是 HTTP/1.0 的頭部。例如：Expires：Sat, 23 May 2009 10:02:12 GMT * Host：客戶端指定自己想訪問的WEB服務器的域名/IP 地址和端口號。例如：Host：rss.sina.com.cn * If-Match：如果對象的 ETag 沒有改變，其實也就意味著對象沒有改變，才執行請求的動作。 * If-None-Match：如果對象的 ETag 改變了，其實也就意味著對象也改變了，才執行請求的動作。 * If-Modified-Since：如果請求的對象在該頭部指定的時間之后修改了，才執行請求的動作（比如返回對象），否則返回代碼304，告訴瀏覽器該對象沒有修改。例如：If-Modified-Since：Thu, 10 Apr 2008 09:14:42 GMT * If-Unmodified-Since：如果請求的對象在該頭部指定的時間之后沒修改過，才執行請求的動作（比如返回對象）。 * If-Range：瀏覽器告訴 WEB 服務器，如果我請求的對象沒有改變，就把我缺少的部分給我，如果對象改變了，就把整個對象給我。瀏覽器通過發送請求對象的 ETag 或者自己所知道的最后修改時間給 WEB 服務器，讓其判斷對象是否改變了。總是跟 Range 頭部一起使用。 * Last-Modified：WEB 服務器認為對象的最后修改時間，比如文件的最后修改時間，動態頁面的最后產生時間等等。例如：Last-Modified：Tue, 06 May 2008 02:42:43 GMT * Location：WEB 服務器告訴瀏覽器，試圖訪問的對象已經被移到別的位置了，到該頭部指定的位置去取。例如：Location：http://i0.sinaimg.cn/dy/deco/2008/0528/sinahome_0803_ws_005_text_0.gif * Pramga：主要使用 Pramga: no-cache，相當于 Cache-Control： no-cache。例如：Pragma：no-cache * Proxy-Authenticate：代理服務器響應瀏覽器，要求其提供代理身份驗證信息。Proxy-Authorization：瀏覽器響應代理服務器的身份驗證請求，提供自己的身份信息。 * Range：瀏覽器（比如 Flashget 多線程下載時）告訴 WEB 服務器自己想取對象的哪部分。例如：Range: bytes=1173546- * Referer：瀏覽器向 WEB 服務器表明自己是從哪個網頁/URL 獲得/點擊當前請求中的網址/URL。例如：Referer：http://www.sina.com/ * Server: WEB 服務器表明自己是什么軟件及版本等信息。例如：Server：Apache/2.0.61 (Unix) * User-Agent: 瀏覽器表明自己的身份（是哪種瀏覽器）。例如：User-Agent：Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.8.1.14) Gecko/20080404 Firefox/2、0、0、14 * Transfer-Encoding: WEB 服務器表明自己對本響應消息體（不是消息體里面的對象）作了怎樣的編碼，比如是否分塊（chunked）。例如：Transfer-Encoding: chunked * Vary: WEB服務器用該頭部的內容告訴 Cache 服務器，在什么條件下才能用本響應所返回的對象響應后續的請求。假如源WEB服務器在接到第一個請求消息時，其響應消息的頭部為：Content- Encoding: gzip; Vary: Content-Encoding那么 Cache 服務器會分析后續請求消息的頭部，檢查其 Accept-Encoding，是否跟先前響應的 Vary 頭部值一致，即是否使用相同的內容編碼方法，這樣就可以防止 Cache 服務器用自己 Cache 里面壓縮后的實體響應給不具備解壓能力的瀏覽器。例如：Vary：Accept-Encoding * Via：列出從客戶端到 OCS 或者相反方向的響應經過了哪些代理服務器，他們用什么協議（和版本）發送的請求。當客戶端請求到達第一個代理服務器時，該服務器會在自己發出的請求里面添加 Via 頭部，并填上自己的相關信息，當下一個代理服務器收到第一個代理服務器的請求時，會在自己發出的請求里面復制前一個代理服務器的請求的Via 頭部，并把自己的相關信息加到后面，以此類推，當 OCS 收到最后一個代理服務器的請求時，檢查 Via 頭部，就知道該請求所經過的路由。例如：Via：1.0 236.D0707195.sina.com.cn:80 (squid/2.6.STABLE13)