參考：SOCKET,TCP,HTTP之間的區別與聯系
作者：丶PURSUING
發布時間： 2021-03-19 11:54:01
網址：https://blog.csdn.net/weixin_44742824/article/details/114992140?spm=1001.2014.3001.5502

參考：TCP連接、Http連接與Socket連接的區別
網址：https://blog.csdn.net/mccand1234/article/details/91346202

本文為學習筆記，結合課程內容以及摘抄下列文章：

參考博文：原文地址
作者：500萬一根油條

目錄

• 一、 Socket
• • 什么是socket
  • 為什么需要socket
  • 建立socket連接
• 二、HTTP(基于TCP)
• • HTTP的概念
  • HTTP連接的特點
  • • 連接請求：一次連接
    • 連接請求：短連接(socket是長連接)
• 三、TCP/IP協議簇
• 聯系
• • （1）SOCKET是操作TCP/IP的編程接口
  • （2）SOCKET與HTTP
  • • 長連接與短連接
    • 保持數據的實時同步
  • （3）TCP/IP和HTTP協議
• HTTP、Socket、TCP的區別
• • Socket（套接字）
  • • Socket長連接
    • 什么時候用長連接，短連接
  • TCP連接和HTTP連接的區別
  • TCP連接與Socket連接的區別
  • HTTP連接與Socket連接的區別
• 常見問題
• • 什么時候該用HTTP，什么時候該用socket ?
  • 瀏覽器在與服務器建立了一個 TCP 連接后是否會在一個 HTTP 請求完成后斷開？什么情況下會斷開？
  • 一個TCP 連接可以發多少個 HTTP 請求?
  • 一個 TCP 連接中 HTTP 請求發送可以一起發送么（比如一起發三個請求，再三個響應一起接收）？
  • 為什么有時候刷新頁面不需要重新建立 SSL 連接？
  • 瀏覽器對同一 Host 建立 TCP 連接到數量有沒有限制？
• 往期文章

一、 Socket

什么是socket

套接字（socket）是通信的基石，是支持TCP/IP協議的網絡通信的基本操作單元。

它是網絡通信過程中端點的抽象表示，包含進行網絡通信必須的五種信息：連接使用的協議，本地主機的IP地址，本地進程的協議端口，遠地主機的IP地址，遠地進程的協議端口。（其實就是bind綁定）

為什么需要socket

應用層通過傳輸層進行數據通信時，TCP會遇到同時為多個應用程序進程提供并發服務的問題。多個TCP連接或多個應用程序進程可能需要通過同一個 TCP協議端口傳輸數據。

為了區別不同的應用程序進程和連接，計算機操作系統為應用程序與TCP／IP協議交互提供了套接字(Socket)接口。

應用層可以和傳輸層通過Socket接口，區分來自不同應用程序進程或網絡連接的通信，實現數據傳輸的并發服務。

建立socket連接

前面在學習socket網絡編程的過程中，我們已經對這一個過程有了深刻的認識，由于本文更多了解的是概念性的東西，在這里不做socket編程的展開。

（1）建立Socket連接至少需要一對套接字（socket函數），其中一個運行于客戶端，稱為ClientSocket ，另一個運行于服務器端，稱為ServerSocket 。

（2）bind做網絡通信必須的五種信息綁定。

（3）套接字之間的連接過程分為三個步驟：服務器監聽，客戶端請求，連接確認。

二、HTTP(基于TCP)

HTTP的概念

HTTP協議即超文本傳送協議(Hypertext Transfer Protocol )，是Web聯網的基礎，也是手機聯網常用的協議之一，HTTP協議是建立在TCP協議之上的一種應用。

HTTP連接的特點

連接請求：一次連接

HTTP連接最顯著的特點是客戶端發送的每次請求服務器都需要回送響應，在請求結束后，會主動釋放連接。從建立連接到關閉連接的過程稱為“一次連接”。

1）在HTTP 1.0中，客戶端的每次請求都要求建立一次單獨的連接，在處理完本次請求后，就自動釋放連接。
2）在HTTP> 1.1中，則可以在一次連接中處理多個請求，并且多個請求可以重疊進行，不需要等待一個請求結束后再發送下一個請求。

連接請求：短連接(socket是長連接)

由于HTTP在每次請求結束后服務端都會主動釋放連接，因此HTTP連接是一種“短連接”，要保持客戶端程序的在線狀態，客戶端需要向服務器不斷地發起連接請求。

若服務器長時間無法收到客戶端的請求，則認為客戶端“下線”，若客戶端長時間無法收到服務器的回復，則認為網絡已經斷開。

通常的做法是即使不需要獲得任何數據，客戶端也保持每隔一段固定的時間向服務器發送一保持連接的請求，服務器在收到該請求后對客戶端進行回復，表明知道客戶端“在線”。

三、TCP/IP協議簇

TCP/IP（Transmission Control Protocol/Internet Protocol，傳輸控制協議/網際協議）是指能夠在多個不同網絡間實現信息傳輸的協議簇。

注意：TCP/IP協議不僅僅指的是TCP 和IP兩個協議，而是指一個由FTP、SMTP、TCP、UDP、IP等協議構成的協議簇， 只是因為在TCP/IP協議中TCP協議和IP協議最具代表性，所以被稱為TCP/IP協議。

TCP/IP傳輸協議對互聯網中各部分進行通信的標準和方法進行了規定。

就像配置串口通信一樣，通信雙方要提前制定好規則，這樣接受信息的過程、接受到的信息才會正確。

聯系

（1）SOCKET是操作TCP/IP的編程接口

創建Socket連接時，可以指定使用的傳輸層協議，Socket可以支持不同的傳輸層協議（TCP或UDP），例如當使用TCP協議進行連接時，該Socket連接就是一個TCP連接。

從程序員的層面上來說：socket則是對TCP/IP協議的封裝和應用。

Socket本身并不是協議，而是一個調用接口（API），通過Socket，我們才能使用TCP/IP協議。

實際上，Socket跟TCP/IP協議沒有必然的聯系。Socket編程接口在設計的時候，就希望也能適應其他的網絡協議。所以說，Socket的出現 只是使得程序員更方便地使用TCP/IP協議棧而已，是對TCP/IP協議的抽象，從而形成了我們知道的一些最基本的函數接口，比如create、 listen、connect、accept、send、read和write等等。

“TCP/IP只是一個協議棧，就像操作系統的運行機制一樣，必須要具體實現，同時還要提供對外的操作接口。TCP/IP也要提供可供程序員做網絡開發所用的接口，這就是Socket編程接口。”

（2）SOCKET與HTTP

長連接與短連接

Socket是長連接：由于通常情況下Socket連接就是TCP連接，因此Socket連接一旦建立，通信雙方即可開始相互發送數據內容，直到雙方連接斷開，這稱為長連接(自己理解：前一篇博文講的，socket會自動向服務端發送心跳包吧，這樣可一直保持連接)。

HTTP是短連接：HTTP連接使用的是“請求—響應”的方式，不僅在請求時需要先建立連接，而且需要客戶端向服務器發出請求后，服務器端才能回復數據。【發送請求 > 回復 > 斷開】，這稱為短連接。

保持數據的實時同步

很多情況下，需要服務器端主動向客戶端推送數據，保持客戶端與服務器數據的實時與同步。

（1）此時若雙方建立的是Socket連接，服務器就可以直接將數據傳送給客戶端；

在實際網絡應用中，客戶端到服務器之間的通信往往需要穿越多個中間節點，例如路由器、網關、防火墻等，大部分防火墻默認會關閉長時間處于非活躍狀態的連接而導致Socket 連接斷連，因此需要通過輪詢告訴網絡，該連接處于活躍狀態。

（2）若雙方建立的是HTTP連接，則服務器需要等到客戶端發送一次請求后才能將數據傳回給客戶端。因此，客戶端定時向服務器端發送連接請求，不僅可以保持在線，同時也是在“詢問”服務器是否有新的數據，如果有就將數據傳給客戶端。

（3）TCP/IP和HTTP協議

TPC/IP協議是傳輸層協議，主要解決數據在網絡中如何傳輸，而HTTP是應用層協議，主要解決如何包裝數據。

“我們在傳輸數據時，可以只使用（傳輸層）TCP/IP協議，但是那樣的話，如果沒有應用層，便無法識別數據內容，如果想要使傳輸的數據有意義，則必須使用到應用層協議，應用層協議有很多，比如HTTP、FTP、TELNET等。

HTTP、Socket、TCP的區別

這三個概念經常被談到，也是比較容易被混掉的概念。在回顧之前我們先看一下這三者在TCP/IP協議族中的位置關系：
這里寫圖片描述

HTTP是應用層的協議，更靠近用戶端；TCP是傳輸層的協議；而socket是從傳輸層上抽象出來的一個抽象層，本質是接口。所以本質上三種還是很好區分的。

Socket（套接字）

現在我們了解到TCP/IP只是一個協議棧，就像操作系統的運行機制一樣，必須要具體實現，同時還要提供對外的操作接口。就像操作系統會提供標準的編程接口，比如Win32編程接口一樣，TCP/IP也必須對外提供編程接口，這就是Socket。現在我們知道，Socket跟TCP/IP并沒有必然的聯系。Socket編程接口在設計的時候，就希望也能適應其他的網絡協議。所以，Socket的出現只是可以更方便的使用TCP/IP協議棧而已，其對TCP/IP進行了抽象，形成了幾個最基本的函數接口。比如create，listen，accept，connect，read和write等等，不同語言都有對應的建立Socket服務端和客戶端的庫。

Socket長連接

所謂長連接，指在一個TCP連接上可以連續發送多個數據包，在TCP連接保持期間，如果沒有數據包發送，需要雙方發檢測包以維持此連接(心跳包)，一般需要自己做在線維持。 短連接是指通信雙方有數據交互時，就建立一個TCP連接，數據發送完成后，則斷開此TCP連接。比如Http的，只是連接、請求、關閉，過程時間較短,服務器若是一段時間內沒有收到請求即可關閉連接。其實長連接是相對于通常的短連接而說的，也就是長時間保持客戶端與服務端的連接狀態。
通常的短連接操作步驟是：
連接→數據傳輸→關閉連接；

而長連接通常就是：
連接→數據傳輸→保持連接(心跳)→數據傳輸→保持連接(心跳)→……→關閉連接；

什么時候用長連接，短連接

長連接多用于操作頻繁，點對點的通訊，而且連接數不能太多情況，。每個TCP連接都需要三步握手，這需要時間，如果每個操作都是先連接，再操作的話那么處理 速度會降低很多，所以每個操作完后都不斷開，次處理時直接發送數據包就OK了，不用建立TCP連接。例如：數據庫的連接用長連接， 如果用短連接頻繁的通信會造成Socket錯誤，而且頻繁的Socket創建也是對資源的浪費。

TCP連接和HTTP連接的區別

HTTP是基于TCP的，客戶端往服務端發送一個HTTP請求時第一步就是要建立與服務端的TCP連接，也就是先三次握手，“你好，你好，你好”。從HTTP 1.1開始支持持久連接，也就是一次TCP連接可以發送多次的HTTP請求。
總結：HTTP基于TCP

TCP連接與Socket連接的區別

socket層只是在TCP/UDP傳輸層上做的一個抽象接口層，因此一個socket連接可以基于連接，也有可能基于UDP。基于TCP協議的socket連接同樣需要通過三次握手建立連接，是可靠的；基于UDP協議的socket連接不需要建立連接的過程，不過對方能不能收到都會發送過去，是不可靠的，大多數的即時通訊IM都是后者。

總結：Socket也基于TCP,socket 是實現TCP，UDP的。類似于jedis（redis的java實現）和redis的關系。

HTTP連接與Socket連接的區別

區分這兩個概念是比較有意義的，畢竟TCP看不見摸不著，HTTP與Socket是實實在在能用到的。

HTTP是短連接，Socket(基于TCP協議的)是長連接。盡管HTTP1.1開始支持持久連接，但仍無法保證始終連接。而Socket連接一旦建立TCP三次握手，除非一方主動斷開，否則連接狀態一直保持。

HTTP連接服務端無法主動發消息，Socket連接雙方請求的發送先后限制。這點就比較重要了，因為它將決定二者分別適合應用在什么場景下。HTTP采用“請求-響應”機制，在客戶端還沒發送消息給服務端前，服務端無法推送消息給客戶端。必須滿足客戶端發送消息在前，服務端回復在后。Socket連接雙方類似peer2peer的關系，一方隨時可以向另一方喊話。

常見問題

什么時候該用HTTP，什么時候該用socket ?

• 用HTTP的情況：雙方不需要時刻保持連接在線，比如客戶端資源的獲取、文件上傳等。

• 用Socket的情況：大部分即時通訊應用(QQ、微信)、聊天室、蘋果APNs等。

瀏覽器在與服務器建立了一個 TCP 連接后是否會在一個 HTTP 請求完成后斷開？什么情況下會斷開？

在 HTTP/1.0 中，一個服務器在發送完一個 HTTP 響應后，會斷開 TCP 鏈接。但是這樣每次請求都會重新建立和斷開 TCP 連接，代價過大。所以雖然標準中沒有設定，某些服務器對 Connection: keep-alive 的 Header 進行了支持。意思是說，完成這個 HTTP 請求之后，不要斷開 HTTP 請求使用的 TCP 連接。這樣的好處是連接可以被重新使用，之后發送 HTTP 請求的時候不需要重新建立 TCP 連接，以及如果維持連接，那么 SSL 的開銷也可以避免，兩張圖片是我短時間內兩次訪問 https://www.github.com 的時間統計：

頭一次訪問，有初始化連接和 SSL 開銷

初始化連接和 SSL 開銷消失了，說明使用的是同一個 TCP 連接
持久連接：既然維持 TCP 連接好處這么多，HTTP/1.1 就把 Connection 頭寫進標準，并且默認開啟持久連接，除非請求中寫明 Connection: close，那么瀏覽器和服務器之間是會維持一段時間的 TCP 連接，不會一個請求結束就斷掉。

所以結論是：默認情況下建立 TCP 連接不會斷開，只有在請求報頭中聲明 Connection: close 才會在請求完成后關閉連接。

一個TCP 連接可以發多少個 HTTP 請求?

了解了上一個問題之后，其實這個問題已經有了答案，如果維持連接，一個 TCP 連接是可以發送多個 HTTP 請求的。maxKeepAliveRequests: 每個TCP連接接受最大的Http請求數目，當處理一個keep alive請求達到這個最大值，Tomcat關閉這個連接，設置為失效任何keep alive請求.

一個 TCP 連接中 HTTP 請求發送可以一起發送么（比如一起發三個請求，再三個響應一起接收）？

HTTP/1.1 存在一個問題，單個 TCP 連接在同一時刻只能處理一個請求，意思是說：兩個請求的生命周期不能重疊，任意兩個 HTTP 請求從開始到結束的時間在同一個 TCP 連接里不能重疊。

雖然 HTTP/1.1 規范中規定了 Pipelining 來試圖解決這個問題，但是這個功能在瀏覽器中默認是關閉的。

先來看一下 Pipelining 是什么，RFC 2616 中規定了：

A client that supports persistent connections MAY "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server MUST send its responses to those requests in the same order that the requests were received. 一個支持持久連接的客戶端可以在一個連接中發送多個請求（不需要等待任意請求的響應）。收到請求的服務器必須按照請求收到的順序發送響應。

• 1
• 2

至于標準為什么這么設定，我們可以大概推測一個原因：由于 HTTP/1.1 是個文本協議，同時返回的內容也并不能區分對應于哪個發送的請求，所以順序必須維持一致。比如你向服務器發送了兩個請求 GET/query?q=A 和 GET/query?q=B，服務器返回了兩個結果，瀏覽器是沒有辦法根據響應結果來判斷響應對應于哪一個請求的。

Pipelining 這種設想看起來比較美好，但是在實踐中會出現許多問題：

• 一些代理服務器不能正確的處理 HTTP Pipelining。
• 正確的流水線實現是復雜的。
• Head-of-line Blocking 連接頭阻塞：在建立起一個 TCP 連接之后，假設客戶端在這個連接連續向服務器發送了幾個請求。按照標準，服務器應該按照收到請求的順序返回結果，假設服務器在處理首個請求時花費了大量時間，那么后面所有的請求都需要等著首個請求結束才能響應。

所以現代瀏覽器默認是不開啟 HTTP Pipelining 的。

但是，HTTP2 提供了 Multiplexing 多路傳輸特性，可以在一個 TCP 連接中同時完成多個 HTTP 請求。至于 Multiplexing 具體怎么實現的就是另一個問題了。我們可以看一下使用 HTTP2 的效果。

綠色是發起請求到請求返回的等待時間，藍色是響應的下載時間，可以看到都是在同一個 Connection，并行完成的

所以這個問題也有了答案：在 HTTP/1.1 存在 Pipelining 技術可以完成這個多個請求同時發送，但是由于瀏覽器默認關閉，所以可以認為這是不可行的。在 HTTP2 中由于 Multiplexing 特點的存在，多個 HTTP 請求可以在同一個 TCP 連接中并行進行。

那么在 HTTP/1.1 時代，瀏覽器是如何提高頁面加載效率的呢？主要有下面兩點：

• 維持和服務器已經建立的 TCP 連接，在同一連接上順序處理多個請求。
• 和服務器建立多個 TCP 連接。

為什么有時候刷新頁面不需要重新建立 SSL 連接？

在上面問題的討論中已經有答案了，TCP 連接有的時候會被瀏覽器和服務端維持一段時間。TCP 不需要重新建立，SSL 自然也會用之前的。

瀏覽器對同一 Host 建立 TCP 連接到數量有沒有限制？

假設我們還處在 HTTP/1.1 時代，那個時候沒有多路傳輸，當瀏覽器拿到一個有幾十張圖片的網頁該怎么辦呢？肯定不能只開一個 TCP 連接順序下載，那樣用戶肯定等的很難受，但是如果每個圖片都開一個 TCP 連接發 HTTP 請求，那電腦或者服務器都可能受不了，要是有 1000 張圖片的話總不能開 1000 個TCP 連接吧，你的電腦同意 NAT 也不一定會同意。

所以答案是：有。Chrome最多允許對同一個 Host 建立六個 TCP 連接。不同的瀏覽器有一些區別。

收到的 HTML 如果包含幾十個圖片標簽，這些圖片是以什么方式、什么順序、建立了多少連接、使用什么協議被下載下來的呢？

如果圖片都是 HTTPS 連接并且在同一個域名下，那么瀏覽器在 SSL 握手之后會和服務器商量能不能用 HTTP2，如果能的話就使用Multiplexing 功能在這個連接上進行多路傳輸。不過也未必會所有掛在這個域名的資源都會使用一個 TCP 連接去獲取，但是可以確定的是 Multiplexing 很可能會被用到。
如果發現用不了 HTTP2 呢？或者用不了 HTTPS（現實中的 HTTP2 都是在 HTTPS 上實現的，所以也就是只能使用 HTTP/1.1）。那瀏覽器就會在一個 HOST 上建立多個 TCP 連接，連接數量的最大限制取決于瀏覽器設置，這些連接會在空閑的時候被瀏覽器用來發送新的請求，如果所有的連接都正在發送請求呢？那其他的請求就只能等等了。

往期文章

網絡編程知識預備(1) ——了解OSI網絡模型
網絡編程知識預備(2) ——淺顯易懂的三次握手與四次揮手
網絡編程知識預備(3) ——SOCKET、TCP、HTTP之間的區別與聯系
網絡編程知識預備(4) ——了解HTTP協議與HTTPS協議
網絡編程知識預備(5) ——libcurl庫簡介及其編程訪問百度首頁

總結

以上是生活随笔為你收集整理的网络编程知识预备(3) ——SOCKET、TCP、HTTP之间的区别与联系的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。