• HTTP 是如何使用TCP連接的
• TCP連接的時(shí)延澡为，瓶頸以及存在的故障
• HTTP 的優(yōu)化然低，包括并行連接绊序，keep-alive（持續(xù)連接） 和管道化連接
• 管理連接時(shí)應(yīng)該以及不應(yīng)該做的事情

世界上幾乎所有的HTTP通信都是有TCP/IP承載的砂竖，TCP/IP是全世界計(jì)算機(jī)及網(wǎng)絡(luò)設(shè)備都在使用的一種常用的分組交換網(wǎng)絡(luò)分層協(xié)議集床未。客戶端應(yīng)用程序可以打開一條TCP/IP協(xié)議連接，連接到可能運(yùn)行的世界上任何地方的服務(wù)器應(yīng)用程序。一旦連接建立起來检吆，在客戶端和服務(wù)器的計(jì)算機(jī)之間交換的報(bào)文就永久不會(huì)丟失、受損或失序

TCP可靠的數(shù)據(jù)通道

瀏覽器通過TCP鏈接與服務(wù)器進(jìn)行交互

HTTP連接可以理解為TCP連接及其使用規(guī)則程储，首先來看看HTTP是怎么來和服務(wù)器建立連接的蹭沛，以及

• 瀏覽器解析出主機(jī)名
• 瀏覽器通過主機(jī)名查詢IP地址（DNS）
• 瀏覽器獲取端口號(hào)
• 瀏覽器發(fā)起到IP端口的鏈接
• 瀏覽器向服務(wù)器發(fā)起一條HTTP GET報(bào)文
• 瀏覽器從服務(wù)器讀取HTTP 響應(yīng)報(bào)文
• 瀏覽器關(guān)閉鏈接

TCP鏈接

建立一條新的TCP鏈接時(shí)，甚至是在發(fā)送任意數(shù)據(jù)之前章鲤，TCP對(duì)連接的有關(guān)參數(shù)進(jìn)行溝通致板，這就是常見的三次握手，但是在交互過程中會(huì)嚴(yán)重降低HTTP的性能

• 請(qǐng)求新的TCP連接時(shí)咏窿，客戶端要向服務(wù)器發(fā)送一個(gè)小的TCP分組（通常是40 -- 60個(gè)字節(jié)）斟或。這個(gè)分組中設(shè)置了一個(gè)特殊的SYN標(biāo)記，說明這是一個(gè)鏈接請(qǐng)求

• 如果服務(wù)器接受了連接集嵌，就會(huì)對(duì)一些連接參數(shù)進(jìn)行計(jì)算萝挤，并向客戶端返回一個(gè)TCP分組御毅，這個(gè)分組中的SYN和ACK標(biāo)記都被置位，說明連接請(qǐng)求已被接受

• 最后怜珍，客戶端向服務(wù)器再次發(fā)送一條確定信息端蛆，通知它已經(jīng)成功連接，現(xiàn)代的TCP棧都允許客戶端在這個(gè)確定分組中發(fā)送數(shù)據(jù)

PS 現(xiàn)在很多的面試會(huì)問到酥泛，TCP建立安全可靠的鏈接今豆，為什么是三次握手，而不是四次握手柔袁，下面來舉例

在中國(guó)呆躲，我們見面都喜歡打招呼，表示雙方的禮貌捶索，比方說在吃飯時(shí)間段
A：吃飯沒
B：吃了插掂，你呢？
A：我也吃了
這就類似TCP的三次握手腥例，如果是四次握手那么就是下面的對(duì)話
A：吃飯沒辅甥？
B：吃了
B：你呢？
A：我也吃了
很簡(jiǎn)單燎竖，第二種法案的第二次和第三次對(duì)話可以合并璃弄，在TCP建立連接時(shí)是需要耗時(shí)以及資源的，前面已經(jīng)說了 交互過程中會(huì)嚴(yán)重降低HTTP的性能所以构回，從HTTP的性能出發(fā)夏块，三次握手比四次握手更有優(yōu)勢(shì)。但是四次握手可以嗎捐凭？完全沒有問題

TCP性能

協(xié)議分層（左HTTP拨扶，右HTTPS）.png

HTTP緊挨著TCP凳鬓，位于其上層茁肠，所以HTTP事務(wù)的性能在很大程度上取決于底層的TCP通道的性能。

HTTP事務(wù)延時(shí)

HTTP事務(wù)延時(shí)有一下主要原因

• 客戶端需要根據(jù)URL確定Web服務(wù)器的IP地址和端口號(hào)缩举。如果最近沒有對(duì)URI中的主機(jī)名進(jìn)行訪問垦梆，通過DNS解析系統(tǒng)將URI的主機(jī)名轉(zhuǎn)換成一個(gè)IP地址可能要花費(fèi)數(shù)十秒的時(shí)間

• 接下來，客戶端此昂服務(wù)器發(fā)送一條TCP連接請(qǐng)求仅孩，并等待服務(wù)器回送一個(gè)請(qǐng)求接受回應(yīng)托猩。每條新的TCP鏈接都會(huì)有鏈接建立時(shí)延。這個(gè)值通常最多只有一到兩秒鐘辽慕，但如果有數(shù)百個(gè)HTTP事務(wù)的話京腥，這個(gè)值就會(huì)快速疊加上去

• 一旦連接建立起來，客戶端就會(huì)通過新建立的TCP管道來發(fā)送HTTP請(qǐng)求溅蛉，數(shù)據(jù)到達(dá)時(shí)公浪，Web服務(wù)器會(huì)從TCP連接中讀取請(qǐng)求報(bào)文他宛，并對(duì)秦秋進(jìn)行處理。因特網(wǎng)傳輸請(qǐng)求報(bào)文欠气，以及服務(wù)器處理請(qǐng)求報(bào)文都需要時(shí)間

• Web服務(wù)器回送HTTP響應(yīng)厅各，這也需要花費(fèi)時(shí)間
  這些 TCP 網(wǎng)絡(luò)時(shí)延的大小取決于硬件速度、網(wǎng)絡(luò)和服務(wù)器的負(fù)載预柒，請(qǐng)求和響應(yīng)報(bào)文 的尺寸队塘，以及客戶端和服務(wù)器之間的距離。TCP 協(xié)議的技術(shù)復(fù)雜性也會(huì)對(duì)時(shí)延產(chǎn)生 巨大的影響宜鸯。

性能聚焦區(qū)域

最常見的TCP相關(guān)延時(shí)

• TCP連接建立握手
• TCP慢啟動(dòng)擁塞控制
• 數(shù)據(jù)聚集的Nagle算法
• 用于捎帶確定的TCP延遲確定算法
• TIME_WAIT時(shí)延時(shí)和端口耗盡

TCP連接的握手時(shí)延

TCP 連接握手需要經(jīng)過以下幾個(gè)步驟

• 請(qǐng)求新的 TCP 連接時(shí)憔古，客戶端要向服務(wù)器發(fā)送一個(gè)小的 TCP 分組(通常是 40 ~ 60 個(gè)字節(jié))。這個(gè)分組中設(shè)置了一個(gè)特殊的 SYN 標(biāo)記顾翼，說明這是一個(gè)連接請(qǐng)求投放。

• 如果服務(wù)器接受了連接，就會(huì)對(duì)一些連接參數(shù)進(jìn)行計(jì)算适贸，并向客戶端回送一個(gè) TCP 分組灸芳，這個(gè)分組中的 SYN 和 ACK 標(biāo)記都被置位，說明連接請(qǐng)求已被接受

• 最后拜姿，客戶端向服務(wù)器回送一條確認(rèn)信息烙样，通知它連接已成功建立
  現(xiàn)代的 TCP 棧都允許客戶端在這個(gè)確認(rèn)分組中發(fā)送數(shù)據(jù)

最后的結(jié)果是，小的 HTTP 事務(wù)可能會(huì)在 TCP 建立上花費(fèi) 50%蕊肥，或更多的時(shí)間

延時(shí)確定

• 由于因特網(wǎng)自身無法確壁嘶瘢可靠的分組傳輸(因特網(wǎng)路由器超負(fù)荷的話，可以隨意丟棄分組)壁却，所以 TCP 實(shí)現(xiàn)了自己的確認(rèn)機(jī)制來確保數(shù)據(jù)的成功傳輸批狱。

• 每個(gè) TCP 段都有一個(gè)序列號(hào)和數(shù)據(jù)完整性校驗(yàn)和。每個(gè)段的接收者收到完好的段 時(shí)展东，都會(huì)向發(fā)送者回送小的確認(rèn)分組赔硫。如果發(fā)送者沒有在指定的窗口時(shí)間內(nèi)收到確 認(rèn)信息，發(fā)送者就認(rèn)為分組已被破壞或損毀盐肃，并重發(fā)數(shù)據(jù)爪膊。

• 由于確認(rèn)報(bào)文很小，所以 TCP 允許在發(fā)往相同方向的輸出數(shù)據(jù)分組中對(duì)其進(jìn)行“捎 帶”砸王。TCP 將返回的確認(rèn)信息與輸出的數(shù)據(jù)分組結(jié)合在一起推盛，可以更有效地利用網(wǎng) 絡(luò)。為了增加確認(rèn)報(bào)文找到同向傳輸數(shù)據(jù)分組的可能性谦铃，很多 TCP 棧都實(shí)現(xiàn)了一種“延遲確認(rèn)”算法耘成。延遲確認(rèn)算法會(huì)在一個(gè)特定的窗口時(shí)間(通常是 100 ~ 200 毫 秒)內(nèi)將輸出確認(rèn)存放在緩沖區(qū)中，以尋找能夠捎帶它的輸出數(shù)據(jù)分組。如果在那 個(gè)時(shí)間段內(nèi)沒有輸出數(shù)據(jù)分組瘪菌，就將確認(rèn)信息放在單獨(dú)的分組中傳送件豌。

• 但是，HTTP 具有雙峰特征的請(qǐng)求 - 應(yīng)答行為降低了捎帶信息的可能控嗜。當(dāng)希望有相 反方向回傳分組的時(shí)候茧彤，偏偏沒有那么多。通常疆栏，延遲確認(rèn)算法會(huì)引入相當(dāng)大的時(shí) 延曾掂。根據(jù)所使用操作系統(tǒng)的不同，可以調(diào)整或禁止延遲確認(rèn)算法壁顶。

• 在對(duì) TCP 棧的任何參數(shù)進(jìn)行修改之前珠洗，一定要對(duì)自己在做什么有清醒的認(rèn)識(shí)。TCP 中引入這些算法的目的是防止設(shè)計(jì)欠佳的應(yīng)用程序?qū)σ蛱鼐W(wǎng)造成破壞若专。對(duì) TCP 配置 進(jìn)行的任意修改许蓖，都要絕對(duì)確保應(yīng)用程序不會(huì)引發(fā)這些算法所要避免的問題。

TCP啟動(dòng)慢

• TCP 數(shù)據(jù)傳輸?shù)男阅苓€取決于 TCP 連接的使用期(age)调衰。TCP 連接會(huì)隨著時(shí)間進(jìn)行 自我“調(diào)諧”膊爪，起初會(huì)限制連接的最大速度，如果數(shù)據(jù)成功傳輸嚎莉，會(huì)隨著時(shí)間的推移 提高傳輸?shù)乃俣让壮辍＿@種調(diào)諧被稱為 TCP 慢啟動(dòng)(slow start)，用于防止因特網(wǎng)的突 然過載和擁塞趋箩。
• TCP 慢啟動(dòng)限制了一個(gè) TCP 端點(diǎn)在任意時(shí)刻可以傳輸?shù)姆纸M數(shù)赃额。簡(jiǎn)單來說，每成功 接收一個(gè)分組叫确，發(fā)送端就有了發(fā)送另外兩個(gè)分組的權(quán)限跳芳。如果某個(gè) HTTP 事務(wù)有大 量數(shù)據(jù)要發(fā)送，是不能一次將所有分組都發(fā)送出去的竹勉。必須發(fā)送一個(gè)分組飞盆，等待確 認(rèn);然后可以發(fā)送兩個(gè)分組，每個(gè)分組都必須被確認(rèn)饶米，這樣就可以發(fā)送四個(gè)分組了桨啃， 以此類推车胡。這種方式被稱為“打開擁塞窗口”檬输。
• 由于存在這種擁塞控制特性，所以新連接的傳輸速度會(huì)比已經(jīng)交換過一定量數(shù)據(jù)的匈棘、 “已調(diào)諧”連接慢一些丧慈。由于已調(diào)諧連接要更快一些，所以 HTTP 中有一些可以重用現(xiàn)存連接的工具。本章稍后會(huì)介紹這些 HTTP“持久連接”逃默。

Nagle算法與TCP_NODELAY

• TCP 有一個(gè)數(shù)據(jù)流接口鹃愤，應(yīng)用程序可以通過它將任意尺寸的數(shù)據(jù)放入 TCP 棧中—— 即使一次只放一個(gè)字節(jié)也可以!但是，每個(gè) TCP 段中都至少裝載了 40 個(gè)字節(jié)的標(biāo) 記和首部完域，所以如果 TCP 發(fā)送了大量包含少量數(shù)據(jù)的分組软吐，網(wǎng)絡(luò)的性能就會(huì)嚴(yán)重 下降Nagle 算法(根據(jù)其發(fā)明者 John Nagle 命名)試圖在發(fā)送一個(gè)分組之前，將大量 TCP 數(shù)據(jù)綁定在一起吟税，以提高網(wǎng)絡(luò)效率凹耙。RFC 896“IP/TCP 互連網(wǎng)絡(luò)中的擁塞控 制”對(duì)此算法進(jìn)行了描述。
• Nagle 算法鼓勵(lì)發(fā)送全尺寸(LAN 上最大尺寸的分組大約是 1500 字節(jié)肠仪，在因特網(wǎng) 上是幾百字節(jié))的段肖抱。只有當(dāng)所有其他分組都被確認(rèn)之后，Nagle 算法才允許發(fā)送 非全尺寸的分組异旧。如果其他分組仍然在傳輸過程中意述，就將那部分?jǐn)?shù)據(jù)緩存起來。只 有當(dāng)掛起分組被確認(rèn)吮蛹，或者緩存中積累了足夠發(fā)送一個(gè)全尺寸分組的數(shù)據(jù)時(shí)荤崇，才會(huì) 將緩存的數(shù)據(jù)發(fā)送出去。
• Nagle 算法會(huì)引發(fā)幾種 HTTP 性能問題潮针。首先天试，小的 HTTP 報(bào)文可能無法填滿一個(gè) 分組，可能會(huì)因?yàn)榈却切┯肋h(yuǎn)不會(huì)到來的額外數(shù)據(jù)而產(chǎn)生時(shí)延然低。其次喜每，Nagle 算 法與延遲確認(rèn)之間的交互存在問題——Nagle 算法會(huì)阻止數(shù)據(jù)的發(fā)送，直到有確認(rèn) 分組抵達(dá)為止雳攘，但確認(rèn)分組自身會(huì)被延遲確認(rèn)算法延遲 100 ~ 200 毫秒带兜。
• HTTP 應(yīng)用程序常常會(huì)在自己的棧中設(shè)置參數(shù) TCP_NODELAY，禁用 Nagle 算法吨灭， 提高性能刚照。如果要這么做的話，一定要確保會(huì)向 TCP 寫入大塊的數(shù)據(jù)喧兄，這樣就不會(huì) 產(chǎn)生一堆小分組了无畔。

TIME_WAIT累積與端口耗盡

• TIME_WAIT 端口耗盡是很嚴(yán)重的性能問題，會(huì)影響到性能基準(zhǔn)吠冤，但在現(xiàn)實(shí)中相對(duì) 較少出現(xiàn)浑彰。大多數(shù)遇到性能基準(zhǔn)問題的人最終都會(huì)碰到這個(gè)問題，而且性能都會(huì)變 得出乎意料地差拯辙，所以這個(gè)問題值得特別關(guān)注郭变。
• 當(dāng)某個(gè) TCP 端點(diǎn)關(guān)閉 TCP 連接時(shí)颜价，會(huì)在內(nèi)存中維護(hù)一個(gè)小的控制塊，用來記錄最 近所關(guān)閉連接的 IP 地址和端口號(hào)诉濒。這類信息只會(huì)維持一小段時(shí)間周伦，通常是所估計(jì)的 最大分段使用期的兩倍(稱為 2MSL，通常為 2 分鐘 8)左右未荒，以確保在這段時(shí)間內(nèi) 不會(huì)創(chuàng)建具有相同地址和端口號(hào)的新連接专挪。實(shí)際上，這個(gè)算法可以防止在兩分鐘內(nèi) 創(chuàng)建片排、關(guān)閉并重新創(chuàng)建兩個(gè)具有相同 IP 地址和端口號(hào)的連接狈蚤。
• 現(xiàn)在高速路由器的使用，使得重復(fù)分組幾乎不可能在連接關(guān)閉的幾分鐘之后划纽，出現(xiàn) 在服務(wù)器上脆侮。有些操作系統(tǒng)會(huì)將 2MSL 設(shè)置為一個(gè)較小的值，但超過此值時(shí)要特別小心勇劣。分組確實(shí)會(huì)被復(fù)制靖避，如果來自之前連接的復(fù)制分組插入了具有相同連接值的 新 TCP 流，會(huì)破壞 TCP 數(shù)據(jù)比默。
• 2MSL 的連接關(guān)閉延遲通常不是什么問題幻捏，但在性能基準(zhǔn)環(huán)境下就可能會(huì)成為一個(gè) 問題。進(jìn)行性能基準(zhǔn)測(cè)試時(shí)命咐，通常只有一臺(tái)或幾臺(tái)用來產(chǎn)生流量的計(jì)算機(jī)連接到某 系統(tǒng)中去篡九，這樣就限制了連接到服務(wù)器的客戶端 IP 地址數(shù)。而且醋奠，服務(wù)器通常會(huì)在 HTTP 的默認(rèn) TCP 端口 80 上進(jìn)行監(jiān)聽榛臼。用 TIME_WAIT 防止端口號(hào)重用時(shí)，這些 情況也限制了可用的連接值組合
  在只有一個(gè)客戶端和一臺(tái) Web 服務(wù)器的異常情況下窜司，構(gòu)建一條 TCP 連接的 4 個(gè)值: <source-IP-address, source-port, destination-IP-address, destination-port>
  其中的 3 個(gè)都是固定的——只有源端口號(hào)可以隨意改變: <client-IP, source-port, server-IP, 80>
• 客戶端每次連接到服務(wù)器上去時(shí)沛善，都會(huì)獲得一個(gè)新的源端口，以實(shí)現(xiàn)連接的唯一性塞祈。 但由于可用源端口的數(shù)量有限(比如金刁，60 000 個(gè))，而且在 2MSL 秒(比如议薪，120 秒)內(nèi)連接是無法重用的尤蛮，連接率就被限制在了 60 000/120=500 次 / 秒。如果再不 斷進(jìn)行優(yōu)化斯议，并且服務(wù)器的連接率不高于 500 次 / 秒产捞，就可確保不會(huì)遇到 TIME_ WAIT 端口耗盡問題。要修正這個(gè)問題捅位，可以增加客戶端負(fù)載生成機(jī)器的數(shù)量轧葛，或 者確保客戶端和服務(wù)器在循環(huán)使用幾個(gè)虛擬 IP 地址以增加更多的連接組合艇搀。
• 即使沒有遇到端口耗盡問題尿扯，也要特別小心有大量連接處于打開狀態(tài)的情況，或?yàn)?處于等待狀態(tài)的連接分配了大量控制塊的情況焰雕。在有大量打開連接或控制塊的情況 下衷笋，有些操作系統(tǒng)的速度會(huì)嚴(yán)重減緩

持久連接

• Web客戶端經(jīng)常會(huì)打開到同一個(gè)站點(diǎn)的連接。比如矩屁，一個(gè)Web頁(yè)面上的大部分內(nèi)嵌圖片通常來自同一個(gè)Web站點(diǎn)辟宗，而且相當(dāng)一部分指向其他對(duì)象的超鏈接通常都指向同一個(gè)站點(diǎn)。因此吝秕，初始化了某個(gè)服務(wù)器HTTP請(qǐng)求的應(yīng)用程序很有可能會(huì)再不久的將來對(duì)同一臺(tái)服務(wù)器發(fā)起更多的請(qǐng)求泊脐，這種性質(zhì)被稱為站點(diǎn)的局部性
• 因此，HTTP/1.1允許HTTP設(shè)備在事務(wù)處理結(jié)束之后將TCP連接保持在打開的狀態(tài)烁峭，以便為未來的HTTP請(qǐng)求重用現(xiàn)存的連接容客。在事務(wù)處理結(jié)束之后然然保持在打開狀態(tài)的TCP連接被稱之為持久連接。

HTTP/1.0 + Keep-alive連接

大約從1996年開始约郁，很多HTTP/1.0瀏覽器和服務(wù)器都進(jìn)行了擴(kuò)展缩挑，以支持一種被稱為keep-alive連接的早期實(shí)驗(yàn)型久連接。這些早期的持久連接接受到了一些互操作性設(shè)計(jì)方面的困擾鬓梅，這些方面在HTTP/1.1版本中都得到修正供置，但很多的客戶端和服務(wù)器仍然在使用這種早期的keep-alive連接。

• 實(shí)現(xiàn)HTTP/1.0 keep-alive 連接的客戶端可以通過包含Connection:Keep-alive首部請(qǐng)求將一條連接保持在打開狀態(tài)
• 如果服務(wù)器愿意為下一條請(qǐng)求將連接保持在打開狀態(tài)绽快，就在響應(yīng)中包含相同的首部芥丧。如果響應(yīng)中沒有Connection:keep-alive首部，客戶端就認(rèn)為服務(wù)器不支持keep-alive坊罢，會(huì)再發(fā)回響應(yīng)報(bào)文之后關(guān)閉連接

Keep-alive連接的限制和規(guī)則

• HTTP/1.0中娄柳，Keep-Alive不是默認(rèn)使用的，客戶端必須發(fā)送一個(gè)Connection: Keep-Alive請(qǐng)求來激活Keep-Alive連接

• Connection: Keep-Alive必須隨所有希望持久連接的報(bào)文一起發(fā)送艘绍，客戶端沒有發(fā)送Connection: Keep-Alive首部赤拒，則服務(wù)器會(huì)在發(fā)出響應(yīng)后關(guān)閉持久連接；

• 通過檢測(cè)響應(yīng)中是否包含Connection: Keep-Alive響應(yīng)首部诱鞠，客戶端可以判斷服務(wù)器是否毀在發(fā)出響應(yīng)之后關(guān)閉連接

• 只有在無需檢測(cè)到連接的關(guān)閉即可確定報(bào)文實(shí)體主體部分長(zhǎng)度的情況下挎挖，才能將連接保持在打開狀態(tài)實(shí)體部分必須有正確的Content-Length，否則無法精確一條報(bào)文的結(jié)束和另一條報(bào)文的開始航夺，不能持久連接蕉朵；

• 代理或網(wǎng)關(guān)必須在將報(bào)文轉(zhuǎn)發(fā)出去或?qū)⑵涓咚倬彺嬷埃瑒h除Connection首部中命名的所有首部字段以及Connection首部阳掐；

• 不應(yīng)該與無法確定是否支持Connection首部的代理服務(wù)器建立Keep-Alive連接始衅。

• 從技術(shù)上來講冷蚂，應(yīng)該忽略所有來源HTTP/1.0設(shè)備的Connection首部字段，因?yàn)樗鼈兛赡苁怯杀容^老的代理服務(wù)器誤轉(zhuǎn)發(fā)的

• 除非重復(fù)發(fā)送請(qǐng)求會(huì)產(chǎn)生其他的一些副作用汛闸，否則如果在客戶端收到完整的響應(yīng)之前連接就關(guān)閉了蝙茶，客戶端就一定要做好重試請(qǐng)求的準(zhǔn)備

HTTP/1.1持久連接

• HTTP/1.1用了持久連接（persistent connection）取代了Keep-Alive，目的與Keep-Alive一樣;

• HTTP/1.1默認(rèn)情況下激活持久連接诸老，要在事務(wù)處理結(jié)束之后關(guān)閉連接隆夯，要在響應(yīng)報(bào)文包含Connection: close

• 響應(yīng)報(bào)文不包含Connection: close，并不意味著服務(wù)器承諾永遠(yuǎn)將連接保持打開别伏，客戶端和服務(wù)器仍然可以隨時(shí)關(guān)閉空閑的連接蹄衷。

持久連接的限制和規(guī)則

• 發(fā)送了 Connection: Keep-Alive請(qǐng)求首部之后，客戶端就無法在那條連接上發(fā)送更多的請(qǐng)求了

• 如果客戶端不想在連接上發(fā)送其他的請(qǐng)求了厘肮，就應(yīng)該在最后一條請(qǐng)求中發(fā)送一個(gè)Connection: close

• 實(shí)體主體部分的長(zhǎng)度都和相應(yīng)的Content-Length一致愧口，或者是用分塊傳輸編碼方式編碼的--連接餐能持久保持

• HTTP/1.1的代理必須能夠分別管理與客戶端和服務(wù)器的持久連接--每個(gè)持久連接都只適用于一跳傳輸

• HTTP/1.1的代理服務(wù)器不應(yīng)該與HTTP/1.0客戶端建立長(zhǎng)久連接，除非他們了解客戶端的處理能力

• 不管Connection首部取了什么值类茂，HTTP/1.1S設(shè)備都可以在任意時(shí)刻關(guān)閉連接