轉 http://blog.csdn.net/sundacheng1989/article/details/28239711
在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響應消息最終也將無損地到達客戶。（自己的理解Tcp其實就是一個管子 一面連接着客戶進程，另一面連接着服務器端的進程 從而進行信息的傳輸）
C#代碼連接遠程數據庫用的是TCP協議。每次new 一個connection的時候，connection.open就打開了這個TCP連接。connection.Close的時候就關閉了這個連接。 FTP的底層也是TCP， 不過是長連接的。傳輸大文件比較快。 需要看具體場景。在服務器端，如果程序是采取的長連接的方式，那么就能控制同時連接到這個服務器的連接個數，防止同時有多個連接。但是采取短連接的方式， 那么就不能控制同時連接到這個服務器上的連接的個數，這也是一個優點，可以同時處理大量連接請求。但是如果連接請求量太大的話，可能造成服務器停止工作。
WebService不需要連接，一秒中至少可以支持上萬/十萬的請求，每次請求然后釋放，沒有空余的內存消耗。一般不會限制同時連接的個數，這是 優勢。Message Queue需要建立連接， 支持上千的連接就很吃力了。因為每個連接即使沒有在請求數據，也會在內存中占用一定的空間存儲。會限制，比如SQL Server數據庫服務器，一般最多同時連接16個。
Http協議一定通過指定的端口，80，所以一般計算機上不會限制這個端口，所以Http協議能夠順利通過所有機器上的防火牆。而使用Socket編程的話，就需要自己指定特定的端口，那么很可能這個端口是在某個環境中禁用的，那么就無法穿透防火牆。IIS使用的是80端口，也就是這個程序一直在監聽着這個端口。一旦發現有人要建立到這個端口的連接，他就會響應，然后建立連接。這里說的連接都是短連接。所以你對服務器上的網址的請求，都是通過80端口送到網站程序的。然后通過這個端口發送的客戶端瀏覽器。
（把防火牆想象成一張紙端口就是一個洞 短連接就是一束束的電子 可以知道大部分電腦的http端口是指定好的也就是一個固定的洞口，所以一束束的大小正好的的電子帶着信息通過會暢通無阻，而使用Socket編程的話那么洞口的大小就不確定需要自己開鑿，那么許多不一般大小的粒子通過洞口會有阻礙，從而導致粒子無法正常通過防火牆洞口那么最終的的結果是啥呢？ 我還沒有深究自己理解的 希望大神們指點）