HTTP基礎知識（二）

標籤：記憶體   負載   php   版本   bsp   客戶   version   cache   請求   

接著上一章的內容：HTTP基礎知識（一）  二、簡單的HTTP協議1、用戶端：請求訪問文本或映像等資源的一端稱為用戶端；伺服器端：提供資源響應的一端 2、以百度為例子這是要求標頭：

 

在起始行開頭的HTTP/1.1表示伺服器對應的HTTP版本，GET表示請求的方法，第二行開始的就是內容實體。

 

請求報文詳解 

Header	解釋	樣本
Accept	指定用戶端能夠接收的內容類型	Accept: text/plain, text/html
Accept-Charset	瀏覽器可以接受的字元編碼集。	Accept-Charset: iso-8859-5
Accept-Encoding	指定瀏覽器可以支援的web伺服器返回內容壓縮編碼類別型。	Accept-Encoding: compress, gzip
Accept-Language	瀏覽器可接受的語言	Accept-Language: en,zh
Accept-Ranges	可以請求網頁實體的一個或者多個子範圍欄位	Accept-Ranges: bytes
Authorization	HTTP授權的授權認證	Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Cache-Control	指定請求和響應遵循的緩衝機制	Cache-Control: no-cache
Connection	表示是否需要持久串連。（HTTP 1.1預設進行持久串連）	Connection: close
Cookie	HTTP請求發送時，會把儲存在該請求網域名稱下的所有cookie值一起發送給web伺服器。	Cookie: $Version=1; Skin=new;
Content-Length	請求的內容長度	Content-Length: 348
Content-Type	請求的與實體對應的MIME資訊	Content-Type: application/x-www-form-urlencoded
Date	請求發送的日期和時間	Date: Tue, 15 Nov 2010 08:12:31 GMT
Expect	請求的特定的伺服器行為	Expect: 100-continue
From	發出請求的使用者的Email	From: [email protected]
Host	指定請求的伺服器的網域名稱和連接埠號碼	Host: www.zcmhi.com
If-Match	只有請求內容與實體相匹配才有效	If-Match: “737060cd8c284d8af7ad3082f209582d”
If-Modified-Since	如果請求的部分在指定時間之後被修改則請求成功，未被修改則返回304代碼	If-Modified-Since: Sat, 29 Oct 2010 19:43:31 GMT
If-None-Match	如果內容未改變返回304代碼，參數為伺服器先前發送的Etag，與伺服器回應的Etag比較判斷是否改變	If-None-Match: “737060cd8c284d8af7ad3082f209582d”
If-Range	如果實體未改變，伺服器發送用戶端丟失的部分，否則發送整個實體。參數也為Etag	If-Range: “737060cd8c284d8af7ad3082f209582d”
If-Unmodified-Since	只在實體在指定時間之後未被修改才請求成功	If-Unmodified-Since: Sat, 29 Oct 2010 19:43:31 GMT
Max-Forwards	限制資訊通過代理和網關傳送的時間	Max-Forwards: 10
Pragma	用來包含實現特定的指令	Pragma: no-cache
Proxy-Authorization	串連到代理的授權認證	Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Range	只請求實體的一部分，指定範圍	Range: bytes=500-999
Referer	先前網頁的地址，當前請求網頁緊隨其後,即來路	Referer: http://www.zcmhi.com/archives/71.html
TE	用戶端願意接受的傳輸編碼，並通知伺服器接受接受尾加頭資訊	TE: trailers,deflate;q=0.5
Upgrade	向伺服器指定某種傳輸協議以便伺服器進行轉換（如果支援）	Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
User-Agent	User-Agent的內容包含發出請求的使用者資訊	User-Agent: Mozilla/5.0 (Linux; X11)
Via	通知中間網關或Proxy 伺服器地址，通訊協定	Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
Warning	關於訊息實體的警告資訊	Warn: 199 Miscellaneous warning

 響應報文詳解 

Header	解釋	樣本
Accept-Ranges	表明伺服器是否支援指定範圍請求及哪種類型的分段請求	Accept-Ranges: bytes
Age	從原始伺服器到代理緩衝形成的估算時間（以秒計，非負）	Age: 12
Allow	對某網路資源的有效請求行為，不允許則返回405	Allow: GET, HEAD
Cache-Control	告訴所有的緩衝機制是否可以緩衝及哪種類型	Cache-Control: no-cache
Content-Encoding	web伺服器支援的返回內容壓縮編碼類別型。	Content-Encoding: gzip
Content-Language	響應體的語言	Content-Language: en,zh
Content-Length	響應體的長度	Content-Length: 348
Content-Location	請求資源可替代的備用的另一地址	Content-Location: /index.htm
Content-MD5	返回資源的MD5校正值	Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==
Content-Range	在整個返回體中本部分的位元組位置	Content-Range: bytes 21010-47021/47022
Content-Type	返回內容的MIME類型	Content-Type: text/html; charset=utf-8
Date	原始伺服器訊息發出的時間	Date: Tue, 15 Nov 2010 08:12:31 GMT
ETag	請求變數的實體標籤的當前值	ETag: “737060cd8c284d8af7ad3082f209582d”
Expires	響應到期的日期和時間	Expires: Thu, 01 Dec 2010 16:00:00 GMT
Last-Modified	請求資源的最後修改時間	Last-Modified: Tue, 15 Nov 2010 12:45:26 GMT
Location	用來重新導向接收方到非請求URL的位置來完成請求或標識新的資源	Location: http://www.zcmhi.com/archives/94.html
Pragma	包括實現特定的指令，它可應用到響應鏈上的任何接收方	Pragma: no-cache
Proxy-Authenticate	它指出認證方案和可應用到代理的該URL上的參數	Proxy-Authenticate: Basic
refresh	應用於重新導向或一個新的資源被創造，在5秒之後重新導向（由網景提出，被大部分瀏覽器支援）	Refresh: 5; url=http://www.atool.org/httptest.php
Retry-After	如果實體暫時不可取，通知用戶端在指定時間之後再次嘗試	Retry-After: 120
Server	web伺服器軟體名稱	Server: Apache/1.3.27 (Unix) (Red-Hat/Linux)
Set-Cookie	設定Http Cookie	Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1
Trailer	指出頭域在分塊傳輸編碼的尾部存在	Trailer: Max-Forwards
Transfer-Encoding	檔案傳輸編碼	Transfer-Encoding:chunked
Vary	告訴下遊代理是使用緩衝響應還是從原始伺服器請求	Vary: *
Via	告知代理用戶端響應是通過哪裡發送的	Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
Warning	警告實體可能存在的問題	Warning: 199 Miscellaneous warning
WWW-Authenticate	表明用戶端請求實體應該使用的授權方案	WWW-Authenticate: Basic

  3、HTTP是一種無狀態(stateless)協議。HTTP協議自身不對請求和響應之間的通訊狀態進行儲存。也就是說在HTTP這個層級，協議對於發送過的請求或響應都不做持久化處理。作用：這是為了更好地處理大量事務，確保協議的延展性。缺點：使用者登入到一家購物網站，跳轉到該站的其他頁面也需要能繼續保持登入狀態，但是HTTP無法實現。解決方案：Cookie技術 4、HTTP/1.1中可使用的方法　　（1）GET方法：擷取資源　　GET方法用來請求訪問已被URI識別的資源。指定的資源經伺服器端解析後返迴響應內容。　　

 

　　以百度為例，訪問百度時使用的GET方法的請求，而返回的是一個頁面資源

 

　　（2）POST方法：傳輸實體主體　　雖然GET方法也可以傳輸實體的主體，但一般不用GET方法進行傳輸。 　　

　　用POST方法會把url隱藏在表單中，而用GET方法時url會暴露在使用者面前，有可能會遭到sql注入等非法攻擊，所以在用 get請求時需要在後台對sql進行處理。

　　經過了一番的搜尋，我發現百度裡的請求都是GET請求，於是在網上求解，原來，用POST請求的話訊息體（網頁表單內 容）和訊息頭都會傳送到伺服器，這樣會導致傳送時的資料量大；而GET請求只傳送訊息頭，所以用GET請求會比POST快。（百 度那麼多大神，小小的sql注入，他們一早就有對策了- -） 　　（3）PUT方法：傳輸檔案　　PUT方法用來傳輸檔案。就像FTP協議的檔案上傳一樣，要求在請求報文的主體中包含檔案內容，然後儲存到請求URI指定的位置。　　但是HTTP/1.1的PUT方法自身不帶驗證機制，任何人都可以上傳檔案，存在安全性問題，所以一般的網站不適用該方法。　　本質上來講， PUT和POST極為相似，都是向伺服器發送資料，但它們之間有一個重要區別，PUT通常指定了資源的存放位置，而POST則沒有，POST的資料存放位置由伺服器自己決定。 　　（4）HEAD方法：獲得報文首部　　HEAD方法和GET方法一樣，只是不返回報文主體部分。用於確認URI的有效性及資源更新的日期時間等。 　　（5）DELETE方法：刪除檔案　　此方法與PUT相反，是按請求URI刪除指定的資源。不過因為不帶驗證機制一般的網站也是不會用DELETE方法。 　　（6）OPTIONS方法：詢問支援的方法　　此方法用於查詢針對請求URI指定的資源支援的方法。 　　（7）TRACE方法：追蹤路徑　　TRACE方法是讓web伺服器端將之前的請求通訊環回給用戶端的方法，能夠確認串連過程中發生的一系列操作。　　但是此方法容易引發跨站追蹤（XST）攻擊，不常被用到。 　　（8）CONNECT方法：要求用隧道協議串連代理　　　　此方法要求在與Proxy 伺服器通訊時建立隧道，實現用隧道協議進行TCP通訊。主要使用SSL(Secure Sockets Layer，安全套接層)和TLS(Transport Layer Security， 傳輸層安全)協議把通訊內容加密後經網路隧道傳輸。　　有了隧道協議，才會有VPN的安全性和私人性。 　　（9）HTTP/1.0和HTTP/1.1支援的方法表　　

5、在HTTP協議的初始版本中，每進行一次HTTP通訊就要斷開一次TCP連結。這種情況對當時的小容量文本傳輸來說沒有多大問題，但是現在每一個頁面都包含各種圖片、視頻等，在發送請求訪問HTML頁面資源的同時，也會請求該頁麵包含的其他資源，如果每次請求都發生TCP斷開，會增加通訊量的開銷

到了HTTP/1.1使用了持久串連方法來保持TCP串連狀態。這樣能減少了TCP串連的重複建立和斷開所造成的額外開銷，減輕了伺服器端的負載。 6、管線化(pipelining)方式：能夠做到同事並行發送多個請求，而不需要一個接一個地等待響應。 7、Cookie應用情境：HTTP的無狀態協議，若伺服器要記住每一個用戶端的狀態會加重CPU及記憶體的消耗。而Cookie技術是通過在請求和響應報文中寫入Cookie資訊來控制用戶端的狀態。Cookie原理：（1）根據從伺服器端發送的響應報文內的一個叫做Set-Cookie的首部欄位資訊，通知用戶端儲存Cookie。當下次用戶端再往該伺服器發送請求時，用戶端會自動在請求報文中加入Cookie值後發送出去。（2）伺服器端發現用戶端發送過來的Cookie後，會去檢查究竟是從哪一個用戶端發來的串連請求，然後對比伺服器上的記錄，最後得到之前的狀態資訊。

HTTP基礎知識（二）