http://www.cnblogs.com/skynet/archive/2010/12/11/1903347.html

故事發(fā)生在10月份的一次面試經(jīng)歷中，本來(lái)我不想說(shuō)出來(lái)丟人顯眼撩炊，但是為了警醒自己和告誡后人结耀，我決定寫成博文發(fā)出來(lái)留夜。因?yàn)樵诿嬖囘^(guò)程中，我講在2009年寫過(guò)QQ農(nóng)場(chǎng)助手图甜，在這期間深入學(xué)習(xí)了HTTP協(xié)議碍粥，而且在2010-05-18寫了博文：HTTP協(xié)議及其POST與GET操作差異 & C#中如何使用POST、GET等黑毅。面試官說(shuō)既然我熟悉HTTP協(xié)議嚼摩，就問(wèn)“當(dāng)HTTP采用keepalive模式，當(dāng)客戶端向服務(wù)器發(fā)生請(qǐng)求之后矿瘦，客戶端如何判斷服務(wù)器的數(shù)據(jù)已經(jīng)發(fā)生完成低斋？”
說(shuō)實(shí)話，當(dāng)時(shí)我懵了匪凡，一直沒(méi)有關(guān)注過(guò)keepalive模式膊畴。我只知道：HTTP協(xié)議中客戶端發(fā)送一個(gè)小請(qǐng)求，服務(wù)器響應(yīng)以所期望的信息（例如一個(gè)html文件或一副gif圖像）病游。服務(wù)器通常在發(fā)送回所請(qǐng)求的數(shù)據(jù)之后就關(guān)閉連接唇跨。這樣客戶端讀數(shù)據(jù)時(shí)會(huì)返回EOF（-1），就知道數(shù)據(jù)已經(jīng)接收完全了衬衬。我就這樣被面試官判了死刑Ｂ虿！滋尉！說(shuō)我完全停留在表面玉控，沒(méi)有深入（當(dāng)時(shí)真的很受打擊，一直自認(rèn)為技術(shù)還不錯(cuò)ＪㄏА）高诺。我當(dāng)時(shí)真的很想找各種借口：
之前沒(méi)有用到HTTP的keepalive模式，所以沒(méi)有深入

好久沒(méi)有用HTTP協(xié)議碾篡，細(xì)節(jié)忘了

實(shí)習(xí)的東西跟HTTP協(xié)議沒(méi)有關(guān)系虱而，用得少了就忘了

。开泽。牡拇。。。惠呼。

覺(jué)得各種解釋都是那么蒼白無(wú)力导俘！我再次感嘆書(shū)到用時(shí)方恨少，也感嘆一個(gè)人的時(shí)間是多么的有限（曾一度想成為一個(gè)IT專業(yè)全才）剔蹋，根本沒(méi)有精力面面俱到旅薄，而且當(dāng)沒(méi)有真正使用一個(gè)東西的時(shí)候，往往會(huì)忽略掉很多細(xì)節(jié)滩租。朋友如果你也答不上來(lái)赋秀，請(qǐng)認(rèn)真細(xì)看下文，不要懷著浮躁了的心律想，說(shuō)不定下次就有人問(wèn)你這個(gè)問(wèn)題猎莲。
1、什么是Keep-Alive模式技即？
我們知道HTTP協(xié)議采用“請(qǐng)求-應(yīng)答”模式著洼，當(dāng)使用普通模式，即非KeepAlive模式時(shí)而叼，每個(gè)請(qǐng)求/應(yīng)答客戶和服務(wù)器都要新建一個(gè)連接身笤，完成之后立即斷開(kāi)連接（HTTP協(xié)議為無(wú)連接的協(xié)議）；當(dāng)使用Keep-Alive模式（又稱持久連接葵陵、連接重用）時(shí)液荸，Keep-Alive功能使客戶端到服務(wù)器端的連接持續(xù)有效，當(dāng)出現(xiàn)對(duì)服務(wù)器的后繼請(qǐng)求時(shí)脱篙，Keep-Alive功能避免了建立或者重新建立連接娇钱。

http 1.0中默認(rèn)是關(guān)閉的，需要在http頭加入"Connection: Keep-Alive"绊困，才能啟用Keep-Alive文搂；http 1.1中默認(rèn)啟用Keep-Alive，如果加入"Connection: close "秤朗，才關(guān)閉煤蹭。目前大部分瀏覽器都是用http1.1協(xié)議，也就是說(shuō)默認(rèn)都會(huì)發(fā)起Keep-Alive的連接請(qǐng)求了取视，所以是否能完成一個(gè)完整的Keep-Alive連接就看服務(wù)器設(shè)置情況硝皂。
2、啟用Keep-Alive的優(yōu)點(diǎn)
從上面的分析來(lái)看贫途，啟用Keep-Alive模式肯定更高效吧彪，性能更高。因?yàn)楸苊饬私?釋放連接的開(kāi)銷丢早。下面是RFC 2616上的總結(jié)：
By opening and closing fewer TCP connections, CPU time is saved in routers and hosts (clients, servers, proxies, gateways, tunnels, or caches), and memory used for TCP protocol control blocks can be saved in hosts.

HTTP requests and responses can be pipelined on a connection. Pipelining allows a client to make multiple requests without waiting for each response, allowing a single TCP connection to be used much more efficiently, with much lower elapsed time.

Network congestion is reduced by reducing the number of packets caused by TCP opens, and by allowing TCP sufficient time to determine the congestion state of the network.

Latency on subsequent requests is reduced since there is no time spent in TCP's connection opening handshake.

HTTP can evolve more gracefully, since errors can be reported without the penalty of closing the TCP connection. Clients using future versions of HTTP might optimistically try a new feature, but if communicating with an older server, retry with old semantics after an error is reported.

RFC 2616（P47）還指出：?jiǎn)斡脩艨蛻舳伺c任何服務(wù)器或代理之間的連接數(shù)不應(yīng)該超過(guò)2個(gè)。一個(gè)代理與其它服務(wù)器或代碼之間應(yīng)該使用超過(guò)2 * N的活躍并發(fā)連接。這是為了提高HTTP響應(yīng)時(shí)間怨酝，避免擁塞（冗余的連接并不能代碼執(zhí)行性能的提升）傀缩。
3、回到我們的問(wèn)題（即如何判斷消息內(nèi)容/長(zhǎng)度的大信┾赡艰？）
Keep-Alive模式，客戶端如何判斷請(qǐng)求所得到的響應(yīng)數(shù)據(jù)已經(jīng)接收完成（或者說(shuō)如何知道服務(wù)器已經(jīng)發(fā)生完了數(shù)據(jù)）斤葱？我們已經(jīng)知道了慷垮，Keep-Alive模式發(fā)送玩數(shù)據(jù)HTTP服務(wù)器不會(huì)自動(dòng)斷開(kāi)連接，所有不能再使用返回EOF（-1）來(lái)判斷（當(dāng)然你一定要這樣使用也沒(méi)有辦法揍堕，可以想象那效率是何等的低）料身！下面我介紹兩種來(lái)判斷方法。
3.1衩茸、使用消息首部字段Conent-Length
故名思意芹血，Conent-Length表示實(shí)體內(nèi)容長(zhǎng)度，客戶端（服務(wù)器）可以根據(jù)這個(gè)值來(lái)判斷數(shù)據(jù)是否接收完成楞慈。但是如果消息中沒(méi)有Conent-Length幔烛，那該如何來(lái)判斷呢？又在什么情況下會(huì)沒(méi)有Conent-Length呢囊蓝？請(qǐng)繼續(xù)往下看……
3.2饿悬、使用消息首部字段Transfer-Encoding
當(dāng)客戶端向服務(wù)器請(qǐng)求一個(gè)靜態(tài)頁(yè)面或者一張圖片時(shí)，服務(wù)器可以很清楚的知道內(nèi)容大小聚霜，然后通過(guò)Content-length消息首部字段告訴客戶端需要接收多少數(shù)據(jù)狡恬。但是如果是動(dòng)態(tài)頁(yè)面等時(shí)，服務(wù)器是不可能預(yù)先知道內(nèi)容大小俯萎，這時(shí)就可以使用Transfer-Encoding：chunk模式來(lái)傳輸數(shù)據(jù)了傲宜。即如果要一邊產(chǎn)生數(shù)據(jù)，一邊發(fā)給客戶端夫啊，服務(wù)器就需要使用"Transfer-Encoding: chunked"這樣的方式來(lái)代替Content-Length函卒。
chunk編碼將數(shù)據(jù)分成一塊一塊的發(fā)生。Chunked編碼將使用若干個(gè)Chunk串連而成撇眯，由一個(gè)標(biāo)明長(zhǎng)度為0的chunk標(biāo)示結(jié)束报嵌。每個(gè)Chunk分為頭部和正文兩部分，頭部?jī)?nèi)容指定正文的字符總數(shù)（十六進(jìn)制的數(shù)字）和數(shù)量單位（一般不寫）熊榛，正文部分就是指定長(zhǎng)度的實(shí)際內(nèi)容锚国，兩部分之間用回車換行(CRLF)隔開(kāi)。在最后一個(gè)長(zhǎng)度為0的Chunk中的內(nèi)容是稱為footer的內(nèi)容玄坦，是一些附加的Header信息（通逞可以直接忽略）绘沉。
Chunk編碼的格式如下：
Chunked-Body = chunk "0" CRLF footer CRLF chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF
hex-no-zero = <HEX excluding "0">
chunk-size = hex-no-zero HEX chunk-ext = ( ";" chunk-ext-name [ "=" chunk-ext-value ] ) chunk-ext-name = token chunk-ext-val = token | quoted-string chunk-data = chunk-size(OCTET)
footer = entity-header
即Chunk編碼由四部分組成：1、0至多個(gè)chunk塊豺总，2车伞、"0" CRLF，3喻喳、footer另玖，4、CRLF****.而每個(gè)chunk塊由：chunk-size表伦、chunk-ext（可選）谦去、CRLF、chunk-data蹦哼、CRLF組成鳄哭。

4、消息長(zhǎng)度的總結(jié)
其實(shí)翔怎，上面2中方法都可以歸納為是如何判斷http消息的大小窃诉、消息的數(shù)量。RFC 2616對(duì)消息的長(zhǎng)度總結(jié)如下：一個(gè)消息的transfer-length（傳輸長(zhǎng)度）是指消息中的message-body（消息體）的長(zhǎng)度赤套。當(dāng)應(yīng)用了transfer-coding（傳輸編碼）飘痛，每個(gè)消息中的message-body（消息體）的長(zhǎng)度（transfer-length）由以下幾種情況決定（優(yōu)先級(jí)由高到低）：
任何不含有消息體的消息（如1XXX、204容握、304等響應(yīng)消息和任何頭(HEAD宣脉，首部)請(qǐng)求的響應(yīng)消息），總是由一個(gè)空行（CLRF）結(jié)束剔氏。
如果出現(xiàn)了Transfer-Encoding頭字段 并且值為非“identity”塑猖，那么transfer-length由“chunked” 傳輸編碼定義，除非消息由于關(guān)閉連接而終止谈跛。
如果出現(xiàn)了Content-Length頭字段羊苟，它的值表示entity-length（實(shí)體長(zhǎng)度）和transfer-length（傳輸長(zhǎng)度）。如果這兩個(gè)長(zhǎng)度的大小不一樣（i.e.設(shè)置了Transfer-Encoding頭字段）感憾，那么將不能發(fā)送Content-Length頭字段蜡励。并且如果同時(shí)收到了Transfer-Encoding字段和Content-Length頭字段，那么必須忽略Content-Length字段阻桅。
如果消息使用媒體類型“multipart/byteranges”凉倚，并且transfer-length 沒(méi)有另外指定，那么這種自定界（self-delimiting）媒體類型定義transfer-length 嫂沉。除非發(fā)送者知道接收者能夠解析該類型稽寒，否則不能使用該類型。
由服務(wù)器關(guān)閉連接確定消息長(zhǎng)度趟章。（注意：關(guān)閉連接不能用于確定請(qǐng)求消息的結(jié)束杏糙，因?yàn)榉?wù)器不能再發(fā)響應(yīng)消息給客戶端了慎王。）

為了兼容HTTP/1.0應(yīng)用程序，HTTP/1.1的請(qǐng)求消息體中必須包含一個(gè)合法的Content-Length頭字段搔啊，除非知道服務(wù)器兼容HTTP/1.1柬祠。一個(gè)請(qǐng)求包含消息體北戏，并且Content-Length字段沒(méi)有給定负芋，如果不能判斷消息的長(zhǎng)度，服務(wù)器應(yīng)該用用400 (bad request) 來(lái)響應(yīng)嗜愈；或者服務(wù)器堅(jiān)持希望收到一個(gè)合法的Content-Length字段旧蛾，用 411 (length required)來(lái)響應(yīng)。
所有HTTP/1.1的接收者應(yīng)用程序必須接受“chunked” transfer-coding (傳輸編碼)蠕嫁，因此當(dāng)不能事先知道消息的長(zhǎng)度锨天，允許使用這種機(jī)制來(lái)傳輸消息。消息不應(yīng)該夠同時(shí)包含 Content-Length頭字段和non-identity transfer-coding剃毒。如果一個(gè)消息同時(shí)包含non-identity transfer-coding和Content-Length 病袄，必須忽略Content-Length 悠瞬。
5丽已、HTTP頭字段總結(jié)
最后我總結(jié)下HTTP協(xié)議的頭部字段垮兑。
1岂丘、 Accept：告訴WEB服務(wù)器自己接受什么介質(zhì)類型摄欲，/ 表示任何類型琴庵，type/* 表示該類型下的所有子類型骗随，type/sub-type聘裁。
2轰豆、 Accept-Charset： 瀏覽器申明自己接收的字符集 Accept-Encoding： 瀏覽器申明自己接收的編碼方法胰伍，通常指定壓縮方法，是否支持壓縮酸休，支持什么壓縮方法（gzip骂租，deflate） Accept-Language：瀏覽器申明自己接收的語(yǔ)言 語(yǔ)言跟字符集的區(qū)別：中文是語(yǔ)言，中文有多種字符集斑司，比如big5渗饮，gb2312，gbk等等陡厘。
3抽米、 Accept-Ranges：WEB服務(wù)器表明自己是否接受獲取其某個(gè)實(shí)體的一部分（比如文件的一部分）的請(qǐng)求。bytes：表示接受糙置，none：表示不接受云茸。
4、 Age：當(dāng)代理服務(wù)器用自己緩存的實(shí)體去響應(yīng)請(qǐng)求時(shí)谤饭，用該頭部表明該實(shí)體從產(chǎn)生到現(xiàn)在經(jīng)過(guò)多長(zhǎng)時(shí)間了标捺。
5懊纳、 Authorization：當(dāng)客戶端接收到來(lái)自WEB服務(wù)器的 WWW-Authenticate 響應(yīng)時(shí)，用該頭部來(lái)回應(yīng)自己的身份驗(yàn)證信息給WEB服務(wù)器亡容。
6嗤疯、 Cache-Control：請(qǐng)求：no-cache（不要緩存的實(shí)體，要求現(xiàn)在從WEB服務(wù)器去裙刖ぁ） max-age：（只接受 Age 值小于 max-age 值茂缚，并且沒(méi)有過(guò)期的對(duì)象） max-stale：（可以接受過(guò)去的對(duì)象，但是過(guò)期時(shí)間必須小于 max-stale 值） min-fresh：（接受其新鮮生命期大于其當(dāng)前 Age 跟 min-fresh 值之和的緩存對(duì)象） 響應(yīng)：public(可以用 Cached 內(nèi)容回應(yīng)任何用戶) private（只能用緩存內(nèi)容回應(yīng)先前請(qǐng)求該內(nèi)容的那個(gè)用戶） no-cache（可以緩存屋谭，但是只有在跟WEB服務(wù)器驗(yàn)證了其有效后脚囊，才能返回給客戶端） max-age：（本響應(yīng)包含的對(duì)象的過(guò)期時(shí)間） ALL: no-store（不允許緩存）
7、 Connection：請(qǐng)求：close（告訴WEB服務(wù)器或者代理服務(wù)器桐磁，在完成本次請(qǐng)求的響應(yīng)后悔耘，斷開(kāi)連接，不要等待本次連接的后續(xù)請(qǐng)求了）我擂。 keepalive（告訴WEB服務(wù)器或者代理服務(wù)器衬以，在完成本次請(qǐng)求的響應(yīng)后，保持連接校摩，等待本次連接的后續(xù)請(qǐng)求）看峻。 響應(yīng)：close（連接已經(jīng)關(guān)閉）。 keepalive（連接保持著秧耗，在等待本次連接的后續(xù)請(qǐng)求）备籽。 Keep-Alive：如果瀏覽器請(qǐng)求保持連接，則該頭部表明希望 WEB 服務(wù)器保持連接多長(zhǎng)時(shí)間（秒）分井。例如：Keep-Alive：300
8车猬、 Content-Encoding：WEB服務(wù)器表明自己使用了什么壓縮方法（gzip，deflate）壓縮響應(yīng)中的對(duì)象尺锚。例如：Content-Encoding：gzip
9珠闰、Content-Language：WEB 服務(wù)器告訴瀏覽器自己響應(yīng)的對(duì)象的語(yǔ)言。
10瘫辩、Content-Length： WEB 服務(wù)器告訴瀏覽器自己響應(yīng)的對(duì)象的長(zhǎng)度伏嗜。例如：Content-Length: 26012
11、Content-Range： WEB 服務(wù)器表明該響應(yīng)包含的部分對(duì)象為整個(gè)對(duì)象的哪個(gè)部分伐厌。例如：Content-Range: bytes 21010-47021/47022
12承绸、Content-Type： WEB 服務(wù)器告訴瀏覽器自己響應(yīng)的對(duì)象的類型。例如：Content-Type：application/xml
13挣轨、ETag：就是一個(gè)對(duì)象（比如URL）的標(biāo)志值军熏，就一個(gè)對(duì)象而言，比如一個(gè) html 文件卷扮，如果被修改了荡澎，其 Etag 也會(huì)別修改均践，所以ETag 的作用跟 Last-Modified 的作用差不多，主要供 WEB 服務(wù)器判斷一個(gè)對(duì)象是否改變了摩幔。比如前一次請(qǐng)求某個(gè) html 文件時(shí)彤委，獲得了其 ETag，當(dāng)這次又請(qǐng)求這個(gè)文件時(shí)或衡，瀏覽器就會(huì)把先前獲得的 ETag 值發(fā)送給WEB 服務(wù)器焦影，然后 WEB 服務(wù)器會(huì)把這個(gè) ETag 跟該文件的當(dāng)前 ETag 進(jìn)行對(duì)比，然后就知道這個(gè)文件有沒(méi)有改變了薇宠。
14偷办、 Expired：WEB服務(wù)器表明該實(shí)體將在什么時(shí)候過(guò)期，對(duì)于過(guò)期了的對(duì)象澄港，只有在跟WEB服務(wù)器驗(yàn)證了其有效性后，才能用來(lái)響應(yīng)客戶請(qǐng)求柄沮。是 HTTP/1.0 的頭部回梧。例如：Expires：Sat, 23 May 2009 10:02:12 GMT
15、 Host：客戶端指定自己想訪問(wèn)的WEB服務(wù)器的域名/IP 地址和端口號(hào)祖搓。例如：Host：rss.sina.com.cn
16狱意、 If-Match：如果對(duì)象的 ETag 沒(méi)有改變，其實(shí)也就意味著對(duì)象沒(méi)有改變拯欧，才執(zhí)行請(qǐng)求的動(dòng)作详囤。
17、 If-None-Match：如果對(duì)象的 ETag 改變了镐作，其實(shí)也就意味著對(duì)象也改變了藏姐，才執(zhí)行請(qǐng)求的動(dòng)作。
18该贾、 If-Modified-Since：如果請(qǐng)求的對(duì)象在該頭部指定的時(shí)間之后修改了羔杨，才執(zhí)行請(qǐng)求的動(dòng)作（比如返回對(duì)象），否則返回代碼304杨蛋，告訴瀏覽器該對(duì)象沒(méi)有修改兜材。例如：If-Modified-Since：Thu, 10 Apr 2008 09:14:42 GMT
19、 If-Unmodified-Since：如果請(qǐng)求的對(duì)象在該頭部指定的時(shí)間之后沒(méi)修改過(guò)逞力，才執(zhí)行請(qǐng)求的動(dòng)作（比如返回對(duì)象）曙寡。
20、 If-Range：瀏覽器告訴 WEB 服務(wù)器寇荧，如果我請(qǐng)求的對(duì)象沒(méi)有改變举庶，就把我缺少的部分給我，如果對(duì)象改變了砚亭，就把整個(gè)對(duì)象給我灯变。瀏覽器通過(guò)發(fā)送請(qǐng)求對(duì)象的 ETag 或者 自己所知道的最后修改時(shí)間給 WEB 服務(wù)器殴玛，讓其判斷對(duì)象是否改變了√砘觯總是跟 Range 頭部一起使用滚粟。
21、 Last-Modified：WEB 服務(wù)器認(rèn)為對(duì)象的最后修改時(shí)間刃泌，比如文件的最后修改時(shí)間凡壤，動(dòng)態(tài)頁(yè)面的最后產(chǎn)生時(shí)間等等。例如：Last-Modified：Tue, 06 May 2008 02:42:43 GMT
22耙替、 Location：WEB 服務(wù)器告訴瀏覽器亚侠，試圖訪問(wèn)的對(duì)象已經(jīng)被移到別的位置了，到該頭部指定的位置去取俗扇。例如：Location：http://i0.sinaimg.cn/dy/deco/2008/0528/sinahome_0803_ws_005_text_0.gif
23硝烂、 Pramga：主要使用 Pramga: no-cache，相當(dāng)于 Cache-Control： no-cache铜幽。例如：Pragma：no-cache
24滞谢、 Proxy-Authenticate： 代理服務(wù)器響應(yīng)瀏覽器，要求其提供代理身份驗(yàn)證信息除抛。Proxy-Authorization：瀏覽器響應(yīng)代理服務(wù)器的身份驗(yàn)證請(qǐng)求狮杨，提供自己的身份信息。
25到忽、 Range：瀏覽器（比如 Flashget 多線程下載時(shí)）告訴 WEB 服務(wù)器自己想取對(duì)象的哪部分橄教。例如：Range: bytes=1173546-
26、 Referer：瀏覽器向 WEB 服務(wù)器表明自己是從哪個(gè) 網(wǎng)頁(yè)/URL 獲得/點(diǎn)擊 當(dāng)前請(qǐng)求中的網(wǎng)址/URL喘漏。例如：Referer：http://www.sina.com/
27护蝶、 Server: WEB 服務(wù)器表明自己是什么軟件及版本等信息。例如：Server：Apache/2.0.61 (Unix)
28陷遮、 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
29、 Transfer-Encoding: WEB 服務(wù)器表明自己對(duì)本響應(yīng)消息體（不是消息體里面的對(duì)象）作了怎樣的編碼绽族，比如是否分塊（chunked）姨涡。例如：Transfer-Encoding: chunked
30、 Vary: WEB服務(wù)器用該頭部的內(nèi)容告訴 Cache 服務(wù)器吧慢，在什么條件下才能用本響應(yīng)所返回的對(duì)象響應(yīng)后續(xù)的請(qǐng)求涛漂。假如源WEB服務(wù)器在接到第一個(gè)請(qǐng)求消息時(shí)，其響應(yīng)消息的頭部為：Content-Encoding: gzip; Vary: Content-Encoding那么 Cache 服務(wù)器會(huì)分析后續(xù)請(qǐng)求消息的頭部，檢查其 Accept-Encoding匈仗，是否跟先前響應(yīng)的 Vary 頭部值一致瓢剿，即是否使用相同的內(nèi)容編碼方法，這樣就可以防止 Cache 服務(wù)器用自己 Cache 里面壓縮后的實(shí)體響應(yīng)給不具備解壓能力的瀏覽器悠轩。例如：Vary：Accept-Encoding
31间狂、 Via： 列出從客戶端到 OCS 或者相反方向的響應(yīng)經(jīng)過(guò)了哪些代理服務(wù)器，他們用什么協(xié)議（和版本）發(fā)送的請(qǐng)求火架。當(dāng)客戶端請(qǐng)求到達(dá)第一個(gè)代理服務(wù)器時(shí)鉴象，該服務(wù)器會(huì)在自己發(fā)出的請(qǐng)求里面添加 Via 頭部，并填上自己的相關(guān)信息何鸡，當(dāng)下一個(gè)代理服務(wù)器收到第一個(gè)代理服務(wù)器的請(qǐng)求時(shí)纺弊，會(huì)在自己發(fā)出的請(qǐng)求里面復(fù)制前一個(gè)代理服務(wù)器的請(qǐng)求的Via 頭部，并把自己的相關(guān)信息加到后面骡男，以此類推淆游，當(dāng) OCS 收到最后一個(gè)代理服務(wù)器的請(qǐng)求時(shí)，檢查 Via 頭部洞翩，就知道該請(qǐng)求所經(jīng)過(guò)的路由稽犁。例如：Via：1.0 236.D0707195.sina.com.cn:80 (squid/2.6.STABLE13)

=============================================================================== HTTP 請(qǐng)求消息頭部實(shí)例： Host：rss.sina.com.cn 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 Accept：text/xml,application/xml,application/xhtml+xml,text/html;q=0、9,text/plain;q=0传趾、8,image/png,/;q=0迎膜、5 Accept-Language：zh-cn,zh;q=0、5 Accept-Encoding：gzip,deflate Accept-Charset：gb2312,utf-8;q=0浆兰、7,*;q=0磕仅、7 Keep-Alive：300 Connection：keep-alive Cookie：userId=C5bYpXrimdmsiQmsBPnE1Vn8ZQmdWSm3WRlEB3vRwTnRtW <-- Cookie If-Modified-Since：Sun, 01 Jun 2008 12:05:30 GMT Cache-Control：max-age=0 HTTP 響應(yīng)消息頭部實(shí)例： Status：OK - 200 <-- 響應(yīng)狀態(tài)碼，表示 web 服務(wù)器處理的結(jié)果簸呈。 Date：Sun, 01 Jun 2008 12:35:47 GMT Server：Apache/2榕订、0、61 (Unix) Last-Modified：Sun, 01 Jun 2008 12:35:30 GMT Accept-Ranges：bytes Content-Length：18616 Cache-Control：max-age=120 Expires：Sun, 01 Jun 2008 12:37:47 GMT Content-Type：application/xml Age：2 X-Cache：HIT from 236-41蜕便、D07071951劫恒、sina、com、cn <-- 反向代理服務(wù)器使用的 HTTP 頭部 Via：1.0 236-41.D07071951.sina.com.cn:80 (squid/2.6.STABLE13) Connection：close
本節(jié)摘自：http://ynhu33.blog.51cto.com/412835/408801