天天看點

TCP是否适用與廣域網環境?

1. 背景情況

突然想起來很久以前聽部門一位同僚說過,http協定适用于廣域網,而tcp協定就不适用于廣域網,因為http協定是短連接配接,而tcp協定是長連接配接,開銷比較大!

其實仔細分析就知道這種說話不成立。http協定本身就是基于tcp協定的,發起一次http請求之前用戶端需要同服務端通過三次握手建立tcp連接配接。

以下幾段内容摘自網絡,最後給出自己總結的結論。

2. 長連接配接與短連接配接

長連接配接與短連接配接的操作過程:

短連接配接的操作步驟是:建立連接配接——資料傳輸——關閉連接配接...建立連接配接——資料傳輸——關閉連接配接;

長連接配接的操作步驟是:建立連接配接——資料傳輸...(保持連接配接)...資料傳輸——關閉連接配接

長連接配接與短連接配接的使用時機:

長連接配接多用于操作頻繁,點對點的通訊,而且連接配接數不能太多的情況。每個tcp連接配接的建立都需要三次握手,每個tcp連接配接的斷開要四次握手。如果每次操作都要建立連接配接然後再操作的話處理速度會降低,是以每次操作下次操作時直接發送資料就可以了,不用再建立tcp連接配接。例如:資料庫的連接配接用長連接配接,如果用短連接配接頻繁的通信會造成socket錯誤,頻繁的socket建立也是對資源的浪費。

短連接配接:web網站的http服務一般都用短連接配接。因為長連接配接對于伺服器來說要耗費一定的資源。像web網站這麼頻繁的成千上萬甚至上億用戶端的連接配接用短連接配接更省一些資源。試想如果都用長連接配接,而且同時用成千上萬的使用者,每個使用者都占有一個連接配接的話,可想而知伺服器的壓力有多大。是以并發量大,但是每個使用者又不需頻繁操作的情況下需要短連接配接。

總之:長連接配接和短連接配接的選擇要視需求而定。

3. http 1.1與http 1.0的比較

一個web站點每天可能要接收到上百萬的使用者請求,為了提高系統的效率,http 1.0規定浏覽器與伺服器隻保持短暫的連接配接,浏覽器的每次請求都需要與伺服器建立一個tcp連接配接,伺服器完成請求處理後立即斷開tcp連接配接,伺服器不跟蹤每個客戶也不記錄過去的請求。但是,這也造成了一些性能上的缺陷,例如,一個包含有許多圖像的網頁檔案中并沒有包含真正的圖像資料内容,而隻是指明了這些圖像的url位址,當web浏覽器通路這個網頁檔案時,浏覽器首先要發出針對該網頁檔案的請求,當浏覽器解析web伺服器傳回的該網頁文檔中的html内容時,發現其中的圖像标簽後,浏覽器将根據标簽中的src屬性所指定的url位址再次向伺服器發出下載下傳圖像資料的請求,如圖3.3所示。

TCP是否适用與廣域網環境?

圖3.3

顯 然,通路一個包含有許多圖像的網頁檔案的整個過程包含了多次請求和響應,每次請求和響應都需要建立一個單獨的連接配接,每次連接配接隻是傳輸一個文檔和圖像,上一次和下一次請求完全分離。即使圖像檔案都很小,但是用戶端和伺服器端每次建立和關閉連接配接卻是一個相對比較費時的過程,并且會嚴重影響客戶機和伺服器的性能。當一個網頁檔案中包含applet,javascript檔案,css檔案等内容時,也會出現類似上述的情況。

為了克服http 1.0的這個缺陷,http 1.1支援持久連接配接,在一個tcp連接配接上可以傳送多個http請求和響應,減少了建立和關閉連接配接的消耗和延遲。一個包含有許多圖像的網頁檔案的多個請求和應答可以在一個連接配接中傳輸,但每個單獨的網頁檔案的請求和應答仍然需要使用各自的連接配接。http 1.1還允許用戶端不用等待上一次請求結果傳回,就可以發出下一次請求,但伺服器端必須按照接收到用戶端請求的先後順序依次回送響應結果,以保證用戶端能夠區分出每次請求的響應内容,這樣也顯著地減少了整個下載下傳過程所需要的時間。基于http 1.1協定的客戶機與伺服器的資訊交換過程,如圖3.4所示。

TCP是否适用與廣域網環境?

圖3.4

可見,http 1.1在繼承了http 1.0優點的基礎上,也克服了http 1.0的性能問題。不僅如此,http 1.1還通過增加更多的請求頭和響應頭來改進和擴充http 1.0的功能。例如,由于http1.0不支援host請求頭字段,web浏覽器無法使用主機頭名來明确表示要通路伺服器上的哪個web站點,這樣就無法使用web伺服器在同一個ip位址和端口号上配置多個虛拟web站點。在http 1.1中增加host請求頭字段後,web浏覽器可以使用主機頭名來明确表示要通路伺服器上的哪個web站點,這才實作了在一台web伺服器上可以在同一個ip位址和端口号上使用不同的主機名來建立多個虛拟web站點。http 1.1的持續連接配接,也需要增加新的請求頭來幫助實作,例如,connection請求頭的值為keep-alive時,用戶端通知伺服器傳回本次請求結果後保持連接配接;connection請求頭的值為close時,用戶端通知伺服器傳回本次請求結果後關閉連接配接。http 1.1還提供了與身份認證、狀态管理和cache緩存等機制相關的請求頭和響應頭。

http 協定老的标準是http/1.0,目前最通用的标準是http/1.1。http/1.1是在http/1.0基礎上的更新,增加了一些功能,全面相容 http/1.0。http/1.0不支援檔案斷點續傳,目前的web伺服器絕大多數都采用了http/1.1。

range:bytes是http/1.1新增内容,http/1.0每次傳送檔案都是從檔案頭開始,即0位元組處開始。range:bytes=xxxx表示要求伺服器從檔案xxxx位元組處開始傳送,這就是我們平時所說的斷點續傳!

4. http 1.1長連接配接與http 1.0短連接配接

1. 背景

keepalive是就是通常所稱的長連接配接。keepalive帶來的好處是可以減少tcp連接配接的開銷,這對于短response body的請求效果更加明顯。同時,可以為采用http協定的互動式應用提供良好的session支援。

2. keepalive的原理

在http1.0和http1.1協定中都有對keepalive的支援。其中http1.0需要在request中增加”connection: keep-alive“ header才能夠支援,而http1.1預設支援。

http1.0 keepalive支援的資料互動流程如下:

a)client發出request,其中該request的http版本号為1.0。同時在request中包含一個header:”connection:keep-alive“。

b)web server收到request中的http協定為1.0及”connection:keep-alive“就認為是一個長連接配接請求,其将在response的header中也增加”connection: keep-alive“。同時不會關閉已建立的tcp連接配接。

c)client收到web server的response中包含”connection: keep-alive“,就認為是一個長連接配接,不close tcp連接配接。并用該tcp連接配接再發送request。(跳轉到a))

http1.1 keepalive支援的資料互動流程如下:

a)client發出request,其中該request的http版本号為1.1。

b)web server收到request中的http協定為1.1就認為是一個長連接配接請求,其将在response的header中也增加”connection: keep-alive“。同是不會關閉已建立的tcp連接配接。

5. 總結

由此可以推斷“tcp或者說長連接配接不适用于廣域網”的說法不成立。

作者:小弟季義欽

來源:51cto