Http協議與TCP協議簡單理解

2021-07-25 20:49:46 字數 2518 閱讀 9386

在c#編寫**,很多時候會遇到http協議或者tcp協議,這裡做乙個簡單的理解。

tcp協議對應於傳輸層,而http協議對應於應用層

,從本質上來說,二者沒有可比性。http協議是建立在tcp協議基礎之上的,當瀏覽器需要從伺服器獲取網頁資料的時候,會發出一次http請求。http會通過tcp建立起乙個到伺服器的連線通道,當本次請求需要的資料完畢後,http會立即將tcp連線斷開,這個過程是很短的。所以http連線是一種短連線,是一種無狀態的連線。

所謂的無狀態,是指瀏覽器每次向伺服器發起請求的時候,不是通過乙個連線,而是每次都建立乙個新的連線。如果是乙個連線的話,伺服器程序中就能保持住這個連線並且在記憶體中記住一些資訊狀態。而每次請求結束後,連線就關閉,相關的內容就釋放了,所以記不住任何狀態,成為無狀態連線。

隨著時間的推移,html頁面變得複雜了,裡面可能嵌入了很多,這時候每次訪問都需要建立一次tcp連線就顯得低效了。因此keep-alive被提出用來解決效率低的問題。從http/1.1起,預設都開啟了keep-alive,保持連線特性,簡單地說,當乙個網頁開啟完成後,客戶端和伺服器之間用於傳輸http資料的tcp連線不會關閉,如果客戶端再次訪問這個伺服器上的網頁,會繼續使用這一條已經建立的連線keep-alive不會永久保持連線,它有乙個保持時間,可以在不同的伺服器軟體(如apache)中設定這個時間。雖然這裡使用tcp連線保持了一段時間,但是這個時間是有限範圍的,到了時間點依然是會關閉的,所以我們還把其看做是每次連線完成後就會關閉。後來,通過session, cookie等相關技術,也能保持一些使用者的狀態。但是還是每次都使用乙個連線,依然是無狀態連線。

以前有個概念很容忍搞不清楚。就是

為什麼http是無狀態的短連線,而tcp是有狀態的長連線?http不是建立在tcp的基礎上嗎,為什麼還能是短連線?

現在明白了,http就是在每次請求完成後就把tcp連線關了,所以是短連線。

而我們直接通過socket程式設計使用tcp協議的時候,因為我們自己可以通過**區控制什麼時候開啟連線什麼時候關閉連線,只要我們不通過**把連線關閉,這個連線就會在客戶端和服務端的程序中一直存在,相關狀態資料會一直儲存著。

在c#中會有socket,實際上socket是對tcp/ip協議的封裝,socket本身並不是協議,而是乙個呼叫介面(api)。socket的出現只是使得程式設計師更方便地使用tcp/ip協議棧而已,是對tcp/ip協議的抽象,從而形成了我們知道的一些最基本的函式介面,比如create、listen、connect、accept、send、read和write等等。

比較形象的描述:http是轎車,提供了封裝或者顯示資料的具體形式;socket是發動機,提供了網路通訊的能力。對於從c#程式設計的角度來講,為了方便,你可以直接選擇已經製造好的轎車http來與伺服器互動。但是有時候往往因為環境因素或者其他的一些定製的請求,必須要使用tcp協議,這時就需要使用socket程式設計,然後自己去處理獲取的資料。就像是你用已有的發動機,自己造了一輛卡車,去從伺服器互動。

http/1.0和http/1.1都把tcp作為底層的傳輸協議。http客戶首先發起建立與伺服器tcp連線。一旦建立連線,瀏覽器程序和伺服器程序就可以通過各自的套接字來訪問tcp。如前所述,客戶端套接字是客戶程序和tcp連線之間的「門」,伺服器端套接字是伺服器程序和同一tcp連線之間的「門」。

客戶往自己的套接字傳送http請求訊息,也從自己的套接字接收http響應訊息。類似地,伺服器從自己的套接字接收http請求訊息,也往自己的套接字傳送http響應訊息。客戶或伺服器一旦把某個訊息送入各自的套接字,這個訊息就完全落入tcp的控制之中。tcp給http提供乙個可靠的資料傳輸服務;這意味著由客戶發出的每個http請求訊息最終將無損地到達伺服器,由伺服器發出的每個http響應訊息最終也將無損地到達客戶。

c#**連線遠端資料庫用的是tcp協議。每次new 乙個connection的時候,connection.open就開啟了這個tcp連線。connection.close的時候就關閉了這個連線。ftp的底層也是tcp, 不過是長連線的。傳輸大檔案比較快。 需要看具體場景。在伺服器端,如果程式是採取的長連線的方式,那麼就能控制同時連線到這個伺服器的連線個數,防止同時有多個連線。但是採取短連線的方式,那麼就不能控制同時連線到這個伺服器上的連線的個數,這也是乙個優點,可以同時處理大量連線請求。但是如果連線請求量太大的話,可能造成伺服器停止工作。

webservice不需要連線,一秒中至少可以支援上萬/十萬的請求,每次請求然後釋放,沒有空餘的記憶體消耗。一般不會限制同時連線的個數,這是優勢。message queue需要建立連線, 支援上千的連線就很吃力了。因為每個連線即使沒有在請求資料,也會在記憶體中占用一定的空間儲存。會限制,比如sql server資料庫伺服器,一般最多同時連線16個。

http協議一定通過指定的埠,80,所以一般計算機上不會限制這個埠,所以http協議能夠順利通過所有機器上的防火牆。而使用socket程式設計的話,就需要自己指定特定的埠,那麼很可能這個埠是在某個環境中禁用的,那麼就無法穿透防火牆。iis使用的是80埠,也就是這個程式一直在監聽著這個埠。一旦發現有人要建立到這個埠的連線,他就會響應,然後建立連線。這裡說的連線都是短連線。所以你對伺服器上的**的請求,都是通過80埠送到**程式的。然後通過這個埠傳送的客戶端瀏覽器。

2016-09-05更新:

Http協議與TCP協議簡單理解

在c 編寫 很多時候會遇到http協議或者tcp協議,這裡做乙個簡單的理解。tcp協議對應於傳輸層,而http協議對應於應用層 從本質上來說,二者沒有可比性。http協議是建立在tcp協議基礎之上的,當瀏覽器需要從伺服器獲取網頁資料的時候,會發出一次http請求。http會通過tcp建立起乙個到伺服...

Http協議與TCP協議簡單理解

在c 編寫 很多時候會遇到http協議或者tcp協議,這裡做乙個簡單的理解。tcp協議對應於傳輸層,而http協議對應於應用層,從本質上來說,二者沒有可比性。http協議是建立在tcp協議基礎之上的,當瀏覽器需要從伺服器獲取網頁資料的時候,會發出一次http請求。http會通過tcp建立起乙個到伺服...

Http協議與TCP協議簡單理解

在c 編寫 很多時候會遇到http協議或者tcp協議,這裡做乙個簡單的理解。tcp協議對應於傳輸層,而http協議對應於應用層,從本質上來說,二者沒有可比性。http協議是建立在tcp協議基礎之上的,當瀏覽器需要從伺服器獲取網頁資料的時候,會發出一次http請求。http會通過tcp建立起乙個到伺服...