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協議的時候,因為我們自己可以通過代碼區控制什么時候打開連接什么時候關閉連接,只要我們不通過代碼把連接關閉,這個連接就會在客戶端和服務端的進程中一直存在,相關狀態數據會一直保存著。

實際上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.0HTTP/1.1都把TCP作為底層的傳輸協議。HTTP客戶首先發起建立與服務器TCP連接。一旦建立連接,瀏覽器進程和服務器進程就可以通過各自的套接字來訪問TCP。

客戶端套接字是客戶進程和TCP連接之間的“門”,服務器端套接字是服務器進程和同一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端口送到網站程序的。然后通過這個端口發送的客戶端瀏覽器。

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 230,563評論 6 544
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 99,694評論 3 429
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事?!?“怎么了?”我有些...
    開封第一講書人閱讀 178,672評論 0 383
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,965評論 1 318
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 72,690評論 6 413
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 56,019評論 1 329
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 44,013評論 3 449
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 43,188評論 0 290
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 49,718評論 1 336
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 41,438評論 3 360
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 43,667評論 1 374
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 39,149評論 5 365
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,845評論 3 351
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 35,252評論 0 28
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 36,590評論 1 295
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 52,384評論 3 400
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 48,635評論 2 380

推薦閱讀更多精彩內容