關於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端口送到網站程序的。而後經過這個端口發送的客戶端瀏覽器。