Http協議與TCP協議簡單理解

標籤：queue   網站程式   art   lan   就會   close   響應   基礎上   理解   

在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提供一個可靠的Data Transmission Service;這意味著由客戶發出的每個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更新：

最近讀了讀《TCP/IP協議卷》，又寫了一篇後續文章，文章連結。

Http協議與TCP協議簡單理解