TCP協(xié)議對(duì)應(yīng)于傳輸層，而HTTP協(xié)議對(duì)應(yīng)于應(yīng)用層项玛，從本質(zhì)上來(lái)說(shuō)，二者沒(méi)有可比性弱判。

Http協(xié)議是建立在TCP協(xié)議基礎(chǔ)之上的襟沮，當(dāng)瀏覽器需要從服務(wù)器獲取網(wǎng)頁(yè)數(shù)據(jù)的時(shí)候，會(huì)發(fā)出一次Http請(qǐng)求。Http會(huì)通過(guò)TCP建立起一個(gè)到服務(wù)器的連接通道开伏，當(dāng)本次請(qǐng)求需要的數(shù)據(jù)完畢后膀跌，Http會(huì)立即將TCP連接斷開，這個(gè)過(guò)程是很短的固灵。所以Http連接是一種短連接捅伤，是一種無(wú)狀態(tài)的連接。所謂的無(wú)狀態(tài)巫玻，是指瀏覽器每次向服務(wù)器發(fā)起請(qǐng)求的時(shí)候丛忆，不是通過(guò)一個(gè)連接，而是每次都建立一個(gè)新的連接大审。如果是一個(gè)連接的話蘸际，服務(wù)器進(jìn)程中就能保持住這個(gè)連接并且在內(nèi)存中記住一些信息狀態(tài)座哩。而每次請(qǐng)求結(jié)束后徒扶，連接就關(guān)閉，相關(guān)的內(nèi)容就釋放了根穷，所以記不住任何狀態(tài)姜骡，成為無(wú)狀態(tài)連接。

隨著時(shí)間的推移屿良，html頁(yè)面變得復(fù)雜了圈澈，里面可能嵌入了很多圖片，這時(shí)候每次訪問(wèn)圖片都需要建立一次tcp連接就顯得低效了尘惧。因此Keep-Alive被提出用來(lái)解決效率低的問(wèn)題康栈。從HTTP/1.1起，默認(rèn)都開啟了Keep-Alive喷橙，保持連接特性啥么，簡(jiǎn)單地說(shuō)，當(dāng)一個(gè)網(wǎng)頁(yè)打開完成后贰逾，客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接不會(huì)關(guān)閉悬荣，如果客戶端再次訪問(wèn)這個(gè)服務(wù)器上的網(wǎng)頁(yè)，會(huì)繼續(xù)使用這一條已經(jīng)建立的連接Keep-Alive不會(huì)永久保持連接疙剑，它有一個(gè)保持時(shí)間氯迂，可以在不同的服務(wù)器軟件（如Apache）中設(shè)定這個(gè)時(shí)間。雖然這里使用TCP連接保持了一段時(shí)間言缤，但是這個(gè)時(shí)間是有限范圍的嚼蚀，到了時(shí)間點(diǎn)依然是會(huì)關(guān)閉的，所以我們還把其看做是每次連接完成后就會(huì)關(guān)閉管挟。后來(lái)驰坊，通過(guò)Session, Cookie等相關(guān)技術(shù)，也能保持一些用戶的狀態(tài)。但是還是每次都使用一個(gè)連接拳芙，依然是無(wú)狀態(tài)連接察藐。

以前有個(gè)概念很容忍搞不清楚。就是為什么Http是無(wú)狀態(tài)的短連接舟扎，而TCP是有狀態(tài)的長(zhǎng)連接分飞？Http不是建立在TCP的基礎(chǔ)上嗎，為什么還能是短連接睹限？現(xiàn)在明白了譬猫，Http就是在每次請(qǐng)求完成后就把TCP連接關(guān)了，所以是短連接羡疗。而我們直接通過(guò)Socket編程使用TCP協(xié)議的時(shí)候染服，因?yàn)槲覀冏约嚎梢酝ㄟ^(guò)代碼區(qū)控制什么時(shí)候打開連接什么時(shí)候關(guān)閉連接，只要我們不通過(guò)代碼把連接關(guān)閉叨恨，這個(gè)連接就會(huì)在客戶端和服務(wù)端的進(jìn)程中一直存在柳刮，相關(guān)狀態(tài)數(shù)據(jù)會(huì)一直保存著。

Socket痒钝，實(shí)際上socket是對(duì)TCP/IP協(xié)議的封裝秉颗，Socket本身并不是協(xié)議，而是一個(gè)調(diào)用接口(API)送矩。Socket的出現(xiàn)只是使得程序員更方便地使用TCP/IP協(xié)議棧而已蚕甥，是對(duì)TCP/IP協(xié)議的抽象，從而形成了我們知道的一些最基本的函數(shù)接口栋荸，比如create菇怀、listen、connect晌块、accept爱沟、send、read和write等等摸袁。

比較形象的描述：HTTP是轎車钥顽，提供了封裝或者顯示數(shù)據(jù)的具體形式;Socket是發(fā)動(dòng)機(jī)，提供了網(wǎng)絡(luò)通信的能力靠汁。對(duì)于從C#編程的角度來(lái)講蜂大，為了方便，你可以直接選擇已經(jīng)制造好的轎車Http來(lái)與服務(wù)器交互蝶怔。但是有時(shí)候往往因?yàn)榄h(huán)境因素或者其他的一些定制的請(qǐng)求奶浦，必須要使用TCP協(xié)議，這時(shí)就需要使用Socket編程踢星，然后自己去處理獲取的數(shù)據(jù)澳叉。就像是你用已有的發(fā)動(dòng)機(jī)，自己造了一輛卡車，去從服務(wù)器交互成洗。

HTTP/1.0和HTTP/1.1都把TCP作為底層的傳輸協(xié)議五督。HTTP客戶首先發(fā)起建立與服務(wù)器TCP連接。一旦建立連接瓶殃，瀏覽器進(jìn)程和服務(wù)器進(jìn)程就可以通過(guò)各自的套接字來(lái)訪問(wèn)TCP充包。如前所述，客戶端套接字是客戶進(jìn)程和TCP連接之間的“門”遥椿，服務(wù)器端套接字是服務(wù)器進(jìn)程和同一TCP連接之間的“門”基矮。客戶往自己的套接字發(fā)送HTTP請(qǐng)求消息冠场，也從自己的套接字接收HTTP響應(yīng)消息家浇。類似地，服務(wù)器從自己的套接字接收HTTP請(qǐng)求消息碴裙，也往自己的套接字發(fā)送HTTP響應(yīng)消息钢悲。客戶或服務(wù)器一旦把某個(gè)消息送入各自的套接字青团，這個(gè)消息就完全落入TCP的控制之中譬巫。TCP給HTTP提供一個(gè)可靠的數(shù)據(jù)傳輸服務(wù);這意味著由客戶發(fā)出的每個(gè)HTTP請(qǐng)求消息最終將無(wú)損地到達(dá)服務(wù)器咖楣，由服務(wù)器發(fā)出的每個(gè)HTTP響應(yīng)消息最終也將無(wú)損地到達(dá)客戶督笆。

C#代碼連接遠(yuǎn)程數(shù)據(jù)庫(kù)用的是TCP協(xié)議。每次new 一個(gè)connection的時(shí)候诱贿，connection.open就打開了這個(gè)TCP連接娃肿。connection.Close的時(shí)候就關(guān)閉了這個(gè)連接。FTP的底層也是TCP珠十， 不過(guò)是長(zhǎng)連接的料扰。傳輸大文件比較快。 需要看具體場(chǎng)景焙蹭。在服務(wù)器端晒杈，如果程序是采取的長(zhǎng)連接的方式，那么就能控制同時(shí)連接到這個(gè)服務(wù)器的連接個(gè)數(shù)孔厉，防止同時(shí)有多個(gè)連接拯钻。但是采取短連接的方式，那么就不能控制同時(shí)連接到這個(gè)服務(wù)器上的連接的個(gè)數(shù)撰豺，這也是一個(gè)優(yōu)點(diǎn)粪般，可以同時(shí)處理大量連接請(qǐng)求。但是如果連接請(qǐng)求量太大的話污桦，可能造成服務(wù)器停止工作亩歹。

WebService不需要連接，一秒中至少可以支持上萬(wàn)/十萬(wàn)的請(qǐng)求，每次請(qǐng)求然后釋放小作，沒(méi)有空余的內(nèi)存消耗亭姥。一般不會(huì)限制同時(shí)連接的個(gè)數(shù)，這是優(yōu)勢(shì)顾稀。Message Queue需要建立連接致份， 支持上千的連接就很吃力了。因?yàn)槊總€(gè)連接即使沒(méi)有在請(qǐng)求數(shù)據(jù)础拨，也會(huì)在內(nèi)存中占用一定的空間存儲(chǔ)氮块。會(huì)限制，比如SQL Server數(shù)據(jù)庫(kù)服務(wù)器诡宗，一般最多同時(shí)連接16個(gè)滔蝉。

Http協(xié)議一定通過(guò)指定的端口，80塔沃，所以一般計(jì)算機(jī)上不會(huì)限制這個(gè)端口蝠引，所以Http協(xié)議能夠順利通過(guò)所有機(jī)器上的防火墻。而使用Socket編程的話蛀柴，就需要自己指定特定的端口螃概，那么很可能這個(gè)端口是在某個(gè)環(huán)境中禁用的，那么就無(wú)法穿透防火墻鸽疾。IIS使用的是80端口吊洼，也就是這個(gè)程序一直在監(jiān)聽(tīng)著這個(gè)端口。一旦發(fā)現(xiàn)有人要建立到這個(gè)端口的連接制肮，他就會(huì)響應(yīng)冒窍，然后建立連接。這里說(shuō)的連接都是短連接豺鼻。所以你對(duì)服務(wù)器上的網(wǎng)址的請(qǐng)求综液，都是通過(guò)80端口送到網(wǎng)站程序的。然后通過(guò)這個(gè)端口發(fā)送的客戶端瀏覽器儒飒。