於c#編寫**，很多時候會遇到http協議或tcp合約，這裡做乙個簡單的了解。
tcp對應於該傳送層協議，和http對應於應用層協議，從本質上講，兩者是沒有可比性。http該協議是基於tcp之上的，當瀏覽器須要從server獲取網頁資料的時候，會發出一次http請求。
http會通過tcp建立起乙個到server的連線通道。當本次請求須要的資料完成後，http會馬上將tcp連線斷開，這個過程是非常短的。所以http連線是一種短連線。是一種無狀態的連線。所謂的無狀態，是指瀏覽器每次向server發起請求的時候。不是通過乙個連線。而是每次都建立乙個新的連線。
假設是乙個連線的話，server程序中就能保持住這個連線而且在記憶體中記住一些資訊狀態。而每次請求結束後，連線就關閉。相關的內容就釋放了，所以記不住不論什麼狀態。成為無狀態連線。
隨著時間的推移，html頁面變得複雜了。裡面可能嵌入了非常多，這時候每次訪問都須要建立一次tcp連線就顯得低效了。
因此keep-alive被提出用來解決效率低的問題。從http/1.1起。預設都開啟了keep-alive，保持連線特性，簡單地說，當乙個網頁開啟完畢後。client和server之間用於傳輸http資料的tcp連線不會關閉，假設client再次訪問這個server上的網頁，會繼續使用這一條已經建立的連線keep-alive不會永久保持連線。它有乙個保持時間。能夠在不同的server軟體（如apache）中設定這個時間。
儘管這裡使用tcp連線保持了一段時間。可是這個時間是有限範圍的。到了時間點依舊是會關閉的。所以我們還把其看做是每次連線完畢後就會關閉。後來，通過session, cookie等相關技術，也能保持一些使用者的狀態。可是還是每次都使用乙個連線，依舊是無狀態連線。
曾經有個概念非常容忍搞不清楚。
就是為什麼http是無狀態的短連線。而tcp是有狀態的長連線？http不是建立在tcp的基礎上嗎，為什麼還能是短連線？如今明確了。http就是在每次請求完畢後就把tcp連線關了，所以是短連線。而我們直接通過socket程式設計使用tcp協議的時候，由於我們自己能夠通過**區控制什麼時候開啟連線什麼時候關閉連線。僅僅要我們不通過**把連線關閉，這個連線就會在client和服務端的程序中一直存在，相關狀態資料會一直儲存著。
在c#中會有socket。實際上socket是對tcp/ip協議的封裝，socket本身並非協議。而是乙個呼叫介面(api)。socket的出現僅僅是使得程式猿更方便地使用tcp/ip協議棧而已，是對tcp/ip協議的抽象。從而形成了我們知道的一些最主要的函式介面。比方create、listen、connect、accept、send、read和write等等。
比較形象的描寫敘述：http是轎車。提供了封裝或者顯示資料的詳細形式;socket是發動機，提供了網路通訊的能力。對於從c#程式設計的角度來講。為了方便，你能夠直接選擇已經製造好的轎車http來與server互動。可是有時候往往由於環境因素或者其它的一些定製的請求，必需要使用tcp協議，這時就需要使用socket程式設計，然後自己去處理獲取的資料。
就像是你用已有的發動機，自己造了一輛卡車。去從server互動。
http/1.0和http/1.1都把tcp作為底層的傳輸協議。
http客戶首先發起建立與servertcp連線。
一旦建立連線。瀏覽器程序和server程序就能夠通過各自的套接字來訪問tcp。如前所述，client套接字是客戶程序和tcp連線之間的「門」。server端套接字是server程序和同一tcp連線之間的「門」。
客戶往自己的套接字傳送http請求訊息，也從自己的套接字接收http響應訊息。類似地，server從自己的套接字接收http請求訊息，也往自己的套接字傳送http響應訊息。客戶或server一旦把某個訊息送入各自的套接字。這個訊息就全然落入tcp的控制之中。
tcp給http提供乙個可靠的傳輸資料服務;這意味著由客戶發出的每乙個http請求訊息終於將無損地到達server，由server發出的每乙個http響應訊息終於也將無損地到達客戶。
c#**連線遠端資料庫用的是tcp協議。每次new 乙個connection的時候，connection.open就開啟了這個tcp連線。connection.close的時候就關閉了這個連線。ftp的底層也是tcp， 只是是長連線的。
傳輸大檔案比較快。
須要看詳細場景。在server端。假設程式是採取的長連線的方式，那麼就能控制同一時候連線到這個server的連線個數。防止同一時候有多個連線。
可是採取短連線的方式，那麼就不能控制同一時候連線到這個server上的連線的個數。這也是乙個長處。能夠同一時候處理大量連線請求。可是假設連線請求量太大的話，可能造成server停止工作。
webservice不須要連線，一秒中至少能夠支援上萬/十萬的請求，每次請求然後釋放，沒有空餘的記憶體消耗。一般不會限制同一時候連線的個數，這是優勢。
message queue須要建立連線， 支援上千的連線就非常吃力了。由於每乙個連線即使沒有在請求資料，也會在記憶體中占用一定的空間儲存。會限制。比方sql server資料庫server。一般最多同一時候連線16個。
http協議一定通過指定的port。80，所以一般計算機上不會限制這個port，所以
http協議可以順利通過全部機器上的防火牆。
而使用socket程式設計的話，就須要自己指定特定的port。那麼非常可能這個port是在某個環境中禁用的，那麼就無法穿透防火牆。
iis使用的是80port，也就是這個程式一直在監聽著這個port。一旦發現有人要建立到這個port的連線，他就會響應，然後建立連線。這裡說的連線都是短連線。
所以你對server上的**的請求，都是通直播80port節目現場。那麼這port傳送client瀏覽器。
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建立起乙個到伺服...