參考：SOCKET,TCP,HTTP之間的區(qū)別與聯(lián)系
作者：丶PURSUING
發(fā)布時(shí)間： 2021-03-19 11:54:01
網(wǎng)址：https://blog.csdn.net/weixin_44742824/article/details/114992140?spm=1001.2014.3001.5502

參考：TCP連接、Http連接與Socket連接的區(qū)別
網(wǎng)址：https://blog.csdn.net/mccand1234/article/details/91346202

本文為學(xué)習(xí)筆記，結(jié)合課程內(nèi)容以及摘抄下列文章：

參考博文：原文地址
作者：500萬(wàn)一根油條

目錄

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

一、 Socket

什么是socket

套接字（socket）是通信的基石，是支持TCP/IP協(xié)議的網(wǎng)絡(luò)通信的基本操作單元。

它是網(wǎng)絡(luò)通信過(guò)程中端點(diǎn)的抽象表示，包含進(jìn)行網(wǎng)絡(luò)通信必須的五種信息：連接使用的協(xié)議，本地主機(jī)的IP地址，本地進(jìn)程的協(xié)議端口，遠(yuǎn)地主機(jī)的IP地址，遠(yuǎn)地進(jìn)程的協(xié)議端口。（其實(shí)就是bind綁定）

為什么需要socket

應(yīng)用層通過(guò)傳輸層進(jìn)行數(shù)據(jù)通信時(shí)，TCP會(huì)遇到同時(shí)為多個(gè)應(yīng)用程序進(jìn)程提供并發(fā)服務(wù)的問(wèn)題。多個(gè)TCP連接或多個(gè)應(yīng)用程序進(jìn)程可能需要通過(guò)同一個(gè) TCP協(xié)議端口傳輸數(shù)據(jù)。

為了區(qū)別不同的應(yīng)用程序進(jìn)程和連接，計(jì)算機(jī)操作系統(tǒng)為應(yīng)用程序與TCP／IP協(xié)議交互提供了套接字(Socket)接口。

應(yīng)用層可以和傳輸層通過(guò)Socket接口，區(qū)分來(lái)自不同應(yīng)用程序進(jìn)程或網(wǎng)絡(luò)連接的通信，實(shí)現(xiàn)數(shù)據(jù)傳輸?shù)牟l(fā)服務(wù)。

建立socket連接

前面在學(xué)習(xí)socket網(wǎng)絡(luò)編程的過(guò)程中，我們已經(jīng)對(duì)這一個(gè)過(guò)程有了深刻的認(rèn)識(shí)，由于本文更多了解的是概念性的東西，在這里不做socket編程的展開(kāi)。

（1）建立Socket連接至少需要一對(duì)套接字（socket函數(shù)），其中一個(gè)運(yùn)行于客戶(hù)端，稱(chēng)為ClientSocket ，另一個(gè)運(yùn)行于服務(wù)器端，稱(chēng)為ServerSocket 。

（2）bind做網(wǎng)絡(luò)通信必須的五種信息綁定。

（3）套接字之間的連接過(guò)程分為三個(gè)步驟：服務(wù)器監(jiān)聽(tīng)，客戶(hù)端請(qǐng)求，連接確認(rèn)。

二、HTTP(基于TCP)

HTTP的概念

HTTP協(xié)議即超文本傳送協(xié)議(Hypertext Transfer Protocol )，是Web聯(lián)網(wǎng)的基礎(chǔ)，也是手機(jī)聯(lián)網(wǎng)常用的協(xié)議之一，HTTP協(xié)議是建立在TCP協(xié)議之上的一種應(yīng)用。

HTTP連接的特點(diǎn)

連接請(qǐng)求：一次連接

HTTP連接最顯著的特點(diǎn)是客戶(hù)端發(fā)送的每次請(qǐng)求服務(wù)器都需要回送響應(yīng)，在請(qǐng)求結(jié)束后，會(huì)主動(dòng)釋放連接。從建立連接到關(guān)閉連接的過(guò)程稱(chēng)為“一次連接”。

1）在HTTP 1.0中，客戶(hù)端的每次請(qǐng)求都要求建立一次單獨(dú)的連接，在處理完本次請(qǐng)求后，就自動(dòng)釋放連接。
2）在HTTP> 1.1中，則可以在一次連接中處理多個(gè)請(qǐng)求，并且多個(gè)請(qǐng)求可以重疊進(jìn)行，不需要等待一個(gè)請(qǐng)求結(jié)束后再發(fā)送下一個(gè)請(qǐng)求。

連接請(qǐng)求：短連接(socket是長(zhǎng)連接)

由于HTTP在每次請(qǐng)求結(jié)束后服務(wù)端都會(huì)主動(dòng)釋放連接，因此HTTP連接是一種“短連接”，要保持客戶(hù)端程序的在線(xiàn)狀態(tài)，客戶(hù)端需要向服務(wù)器不斷地發(fā)起連接請(qǐng)求。

若服務(wù)器長(zhǎng)時(shí)間無(wú)法收到客戶(hù)端的請(qǐng)求，則認(rèn)為客戶(hù)端“下線(xiàn)”，若客戶(hù)端長(zhǎng)時(shí)間無(wú)法收到服務(wù)器的回復(fù)，則認(rèn)為網(wǎng)絡(luò)已經(jīng)斷開(kāi)。

通常的做法是即使不需要獲得任何數(shù)據(jù)，客戶(hù)端也保持每隔一段固定的時(shí)間向服務(wù)器發(fā)送一保持連接的請(qǐng)求，服務(wù)器在收到該請(qǐng)求后對(duì)客戶(hù)端進(jìn)行回復(fù)，表明知道客戶(hù)端“在線(xiàn)”。

三、TCP/IP協(xié)議簇

TCP/IP（Transmission Control Protocol/Internet Protocol，傳輸控制協(xié)議/網(wǎng)際協(xié)議）是指能夠在多個(gè)不同網(wǎng)絡(luò)間實(shí)現(xiàn)信息傳輸?shù)膮f(xié)議簇。

注意：TCP/IP協(xié)議不僅僅指的是TCP 和IP兩個(gè)協(xié)議，而是指一個(gè)由FTP、SMTP、TCP、UDP、IP等協(xié)議構(gòu)成的協(xié)議簇， 只是因?yàn)樵赥CP/IP協(xié)議中TCP協(xié)議和IP協(xié)議最具代表性，所以被稱(chēng)為T(mén)CP/IP協(xié)議。

TCP/IP傳輸協(xié)議對(duì)互聯(lián)網(wǎng)中各部分進(jìn)行通信的標(biāo)準(zhǔn)和方法進(jìn)行了規(guī)定。

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

聯(lián)系

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

創(chuàng)建Socket連接時(shí)，可以指定使用的傳輸層協(xié)議，Socket可以支持不同的傳輸層協(xié)議（TCP或UDP），例如當(dāng)使用TCP協(xié)議進(jìn)行連接時(shí)，該Socket連接就是一個(gè)TCP連接。

從程序員的層面上來(lái)說(shuō)：socket則是對(duì)TCP/IP協(xié)議的封裝和應(yīng)用。

Socket本身并不是協(xié)議，而是一個(gè)調(diào)用接口（API），通過(guò)Socket，我們才能使用TCP/IP協(xié)議。

實(shí)際上，Socket跟TCP/IP協(xié)議沒(méi)有必然的聯(lián)系。Socket編程接口在設(shè)計(jì)的時(shí)候，就希望也能適應(yīng)其他的網(wǎng)絡(luò)協(xié)議。所以說(shuō)，Socket的出現(xiàn) 只是使得程序員更方便地使用TCP/IP協(xié)議棧而已，是對(duì)TCP/IP協(xié)議的抽象，從而形成了我們知道的一些最基本的函數(shù)接口，比如create、 listen、connect、accept、send、read和write等等。

“TCP/IP只是一個(gè)協(xié)議棧，就像操作系統(tǒng)的運(yùn)行機(jī)制一樣，必須要具體實(shí)現(xiàn)，同時(shí)還要提供對(duì)外的操作接口。TCP/IP也要提供可供程序員做網(wǎng)絡(luò)開(kāi)發(fā)所用的接口，這就是Socket編程接口?！?/p>

（2）SOCKET與HTTP

長(zhǎng)連接與短連接

Socket是長(zhǎng)連接：由于通常情況下Socket連接就是TCP連接，因此Socket連接一旦建立，通信雙方即可開(kāi)始相互發(fā)送數(shù)據(jù)內(nèi)容，直到雙方連接斷開(kāi)，這稱(chēng)為長(zhǎng)連接(自己理解：前一篇博文講的，socket會(huì)自動(dòng)向服務(wù)端發(fā)送心跳包吧，這樣可一直保持連接)。

HTTP是短連接：HTTP連接使用的是“請(qǐng)求—響應(yīng)”的方式，不僅在請(qǐng)求時(shí)需要先建立連接，而且需要客戶(hù)端向服務(wù)器發(fā)出請(qǐng)求后，服務(wù)器端才能回復(fù)數(shù)據(jù)?！景l(fā)送請(qǐng)求 > 回復(fù) > 斷開(kāi)】，這稱(chēng)為短連接。

保持?jǐn)?shù)據(jù)的實(shí)時(shí)同步

很多情況下，需要服務(wù)器端主動(dòng)向客戶(hù)端推送數(shù)據(jù)，保持客戶(hù)端與服務(wù)器數(shù)據(jù)的實(shí)時(shí)與同步。

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

在實(shí)際網(wǎng)絡(luò)應(yīng)用中，客戶(hù)端到服務(wù)器之間的通信往往需要穿越多個(gè)中間節(jié)點(diǎn)，例如路由器、網(wǎng)關(guān)、防火墻等，大部分防火墻默認(rèn)會(huì)關(guān)閉長(zhǎng)時(shí)間處于非活躍狀態(tài)的連接而導(dǎo)致Socket 連接斷連，因此需要通過(guò)輪詢(xún)告訴網(wǎng)絡(luò)，該連接處于活躍狀態(tài)。

（2）若雙方建立的是HTTP連接，則服務(wù)器需要等到客戶(hù)端發(fā)送一次請(qǐng)求后才能將數(shù)據(jù)傳回給客戶(hù)端。因此，客戶(hù)端定時(shí)向服務(wù)器端發(fā)送連接請(qǐng)求，不僅可以保持在線(xiàn)，同時(shí)也是在“詢(xún)問(wèn)”服務(wù)器是否有新的數(shù)據(jù)，如果有就將數(shù)據(jù)傳給客戶(hù)端。

（3）TCP/IP和HTTP協(xié)議

TPC/IP協(xié)議是傳輸層協(xié)議，主要解決數(shù)據(jù)在網(wǎng)絡(luò)中如何傳輸，而HTTP是應(yīng)用層協(xié)議，主要解決如何包裝數(shù)據(jù)。

“我們?cè)趥鬏敂?shù)據(jù)時(shí)，可以只使用（傳輸層）TCP/IP協(xié)議，但是那樣的話(huà)，如果沒(méi)有應(yīng)用層，便無(wú)法識(shí)別數(shù)據(jù)內(nèi)容，如果想要使傳輸?shù)臄?shù)據(jù)有意義，則必須使用到應(yīng)用層協(xié)議，應(yīng)用層協(xié)議有很多，比如HTTP、FTP、TELNET等。

HTTP、Socket、TCP的區(qū)別

這三個(gè)概念經(jīng)常被談到，也是比較容易被混掉的概念。在回顧之前我們先看一下這三者在TCP/IP協(xié)議族中的位置關(guān)系：
這里寫(xiě)圖片描述

HTTP是應(yīng)用層的協(xié)議，更靠近用戶(hù)端；TCP是傳輸層的協(xié)議；而socket是從傳輸層上抽象出來(lái)的一個(gè)抽象層，本質(zhì)是接口。所以本質(zhì)上三種還是很好區(qū)分的。

Socket（套接字）

現(xiàn)在我們了解到TCP/IP只是一個(gè)協(xié)議棧，就像操作系統(tǒng)的運(yùn)行機(jī)制一樣，必須要具體實(shí)現(xiàn)，同時(shí)還要提供對(duì)外的操作接口。就像操作系統(tǒng)會(huì)提供標(biāo)準(zhǔn)的編程接口，比如Win32編程接口一樣，TCP/IP也必須對(duì)外提供編程接口，這就是Socket。現(xiàn)在我們知道，Socket跟TCP/IP并沒(méi)有必然的聯(lián)系。Socket編程接口在設(shè)計(jì)的時(shí)候，就希望也能適應(yīng)其他的網(wǎng)絡(luò)協(xié)議。所以，Socket的出現(xiàn)只是可以更方便的使用TCP/IP協(xié)議棧而已，其對(duì)TCP/IP進(jìn)行了抽象，形成了幾個(gè)最基本的函數(shù)接口。比如create，listen，accept，connect，read和write等等，不同語(yǔ)言都有對(duì)應(yīng)的建立Socket服務(wù)端和客戶(hù)端的庫(kù)。

Socket長(zhǎng)連接

所謂長(zhǎng)連接，指在一個(gè)TCP連接上可以連續(xù)發(fā)送多個(gè)數(shù)據(jù)包，在TCP連接保持期間，如果沒(méi)有數(shù)據(jù)包發(fā)送，需要雙方發(fā)檢測(cè)包以維持此連接(心跳包)，一般需要自己做在線(xiàn)維持。 短連接是指通信雙方有數(shù)據(jù)交互時(shí)，就建立一個(gè)TCP連接，數(shù)據(jù)發(fā)送完成后，則斷開(kāi)此TCP連接。比如Http的，只是連接、請(qǐng)求、關(guān)閉，過(guò)程時(shí)間較短,服務(wù)器若是一段時(shí)間內(nèi)沒(méi)有收到請(qǐng)求即可關(guān)閉連接。其實(shí)長(zhǎng)連接是相對(duì)于通常的短連接而說(shuō)的，也就是長(zhǎng)時(shí)間保持客戶(hù)端與服務(wù)端的連接狀態(tài)。
通常的短連接操作步驟是：
連接→數(shù)據(jù)傳輸→關(guān)閉連接；

而長(zhǎng)連接通常就是：
連接→數(shù)據(jù)傳輸→保持連接(心跳)→數(shù)據(jù)傳輸→保持連接(心跳)→……→關(guān)閉連接；

什么時(shí)候用長(zhǎng)連接，短連接

長(zhǎng)連接多用于操作頻繁，點(diǎn)對(duì)點(diǎn)的通訊，而且連接數(shù)不能太多情況，。每個(gè)TCP連接都需要三步握手，這需要時(shí)間，如果每個(gè)操作都是先連接，再操作的話(huà)那么處理 速度會(huì)降低很多，所以每個(gè)操作完后都不斷開(kāi)，次處理時(shí)直接發(fā)送數(shù)據(jù)包就OK了，不用建立TCP連接。例如：數(shù)據(jù)庫(kù)的連接用長(zhǎng)連接， 如果用短連接頻繁的通信會(huì)造成Socket錯(cuò)誤，而且頻繁的Socket創(chuàng)建也是對(duì)資源的浪費(fèi)。

TCP連接和HTTP連接的區(qū)別

HTTP是基于TCP的，客戶(hù)端往服務(wù)端發(fā)送一個(gè)HTTP請(qǐng)求時(shí)第一步就是要建立與服務(wù)端的TCP連接，也就是先三次握手，“你好，你好，你好”。從HTTP 1.1開(kāi)始支持持久連接，也就是一次TCP連接可以發(fā)送多次的HTTP請(qǐng)求。
總結(jié)：HTTP基于TCP

TCP連接與Socket連接的區(qū)別

socket層只是在TCP/UDP傳輸層上做的一個(gè)抽象接口層，因此一個(gè)socket連接可以基于連接，也有可能基于UDP?；赥CP協(xié)議的socket連接同樣需要通過(guò)三次握手建立連接，是可靠的；基于UDP協(xié)議的socket連接不需要建立連接的過(guò)程，不過(guò)對(duì)方能不能收到都會(huì)發(fā)送過(guò)去，是不可靠的，大多數(shù)的即時(shí)通訊IM都是后者。

總結(jié)：Socket也基于TCP,socket 是實(shí)現(xiàn)TCP，UDP的。類(lèi)似于jedis（redis的java實(shí)現(xiàn)）和redis的關(guān)系。

HTTP連接與Socket連接的區(qū)別

區(qū)分這兩個(gè)概念是比較有意義的，畢竟TCP看不見(jiàn)摸不著，HTTP與Socket是實(shí)實(shí)在在能用到的。

HTTP是短連接，Socket(基于TCP協(xié)議的)是長(zhǎng)連接。盡管HTTP1.1開(kāi)始支持持久連接，但仍無(wú)法保證始終連接。而Socket連接一旦建立TCP三次握手，除非一方主動(dòng)斷開(kāi)，否則連接狀態(tài)一直保持。

HTTP連接服務(wù)端無(wú)法主動(dòng)發(fā)消息，Socket連接雙方請(qǐng)求的發(fā)送先后限制。這點(diǎn)就比較重要了，因?yàn)樗鼘Q定二者分別適合應(yīng)用在什么場(chǎng)景下。HTTP采用“請(qǐng)求-響應(yīng)”機(jī)制，在客戶(hù)端還沒(méi)發(fā)送消息給服務(wù)端前，服務(wù)端無(wú)法推送消息給客戶(hù)端。必須滿(mǎn)足客戶(hù)端發(fā)送消息在前，服務(wù)端回復(fù)在后。Socket連接雙方類(lèi)似peer2peer的關(guān)系，一方隨時(shí)可以向另一方喊話(huà)。

常見(jiàn)問(wèn)題

什么時(shí)候該用HTTP，什么時(shí)候該用socket ?

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

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

瀏覽器在與服務(wù)器建立了一個(gè) TCP 連接后是否會(huì)在一個(gè) HTTP 請(qǐng)求完成后斷開(kāi)？什么情況下會(huì)斷開(kāi)？

在 HTTP/1.0 中，一個(gè)服務(wù)器在發(fā)送完一個(gè) HTTP 響應(yīng)后，會(huì)斷開(kāi) TCP 鏈接。但是這樣每次請(qǐng)求都會(huì)重新建立和斷開(kāi) TCP 連接，代價(jià)過(guò)大。所以雖然標(biāo)準(zhǔn)中沒(méi)有設(shè)定，某些服務(wù)器對(duì) Connection: keep-alive 的 Header 進(jìn)行了支持。意思是說(shuō)，完成這個(gè) HTTP 請(qǐng)求之后，不要斷開(kāi) HTTP 請(qǐng)求使用的 TCP 連接。這樣的好處是連接可以被重新使用，之后發(fā)送 HTTP 請(qǐng)求的時(shí)候不需要重新建立 TCP 連接，以及如果維持連接，那么 SSL 的開(kāi)銷(xiāo)也可以避免，兩張圖片是我短時(shí)間內(nèi)兩次訪(fǎng)問(wèn) https://www.github.com 的時(shí)間統(tǒng)計(jì)：

頭一次訪(fǎng)問(wèn)，有初始化連接和 SSL 開(kāi)銷(xiāo)

初始化連接和 SSL 開(kāi)銷(xiāo)消失了，說(shuō)明使用的是同一個(gè) TCP 連接
持久連接：既然維持 TCP 連接好處這么多，HTTP/1.1 就把 Connection 頭寫(xiě)進(jìn)標(biāo)準(zhǔn)，并且默認(rèn)開(kāi)啟持久連接，除非請(qǐng)求中寫(xiě)明 Connection: close，那么瀏覽器和服務(wù)器之間是會(huì)維持一段時(shí)間的 TCP 連接，不會(huì)一個(gè)請(qǐng)求結(jié)束就斷掉。

所以結(jié)論是：默認(rèn)情況下建立 TCP 連接不會(huì)斷開(kāi)，只有在請(qǐng)求報(bào)頭中聲明 Connection: close 才會(huì)在請(qǐng)求完成后關(guān)閉連接。

一個(gè)TCP 連接可以發(fā)多少個(gè) HTTP 請(qǐng)求?

了解了上一個(gè)問(wèn)題之后，其實(shí)這個(gè)問(wèn)題已經(jīng)有了答案，如果維持連接，一個(gè) TCP 連接是可以發(fā)送多個(gè) HTTP 請(qǐng)求的。maxKeepAliveRequests: 每個(gè)TCP連接接受最大的Http請(qǐng)求數(shù)目，當(dāng)處理一個(gè)keep alive請(qǐng)求達(dá)到這個(gè)最大值，Tomcat關(guān)閉這個(gè)連接，設(shè)置為失效任何keep alive請(qǐng)求.

一個(gè) TCP 連接中 HTTP 請(qǐng)求發(fā)送可以一起發(fā)送么（比如一起發(fā)三個(gè)請(qǐng)求，再三個(gè)響應(yīng)一起接收）？

HTTP/1.1 存在一個(gè)問(wèn)題，單個(gè) TCP 連接在同一時(shí)刻只能處理一個(gè)請(qǐng)求，意思是說(shuō)：兩個(gè)請(qǐng)求的生命周期不能重疊，任意兩個(gè) HTTP 請(qǐng)求從開(kāi)始到結(jié)束的時(shí)間在同一個(gè) TCP 連接里不能重疊。

雖然 HTTP/1.1 規(guī)范中規(guī)定了 Pipelining 來(lái)試圖解決這個(gè)問(wèn)題，但是這個(gè)功能在瀏覽器中默認(rèn)是關(guān)閉的。

先來(lái)看一下 Pipelining 是什么，RFC 2616 中規(guī)定了：

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. 一個(gè)支持持久連接的客戶(hù)端可以在一個(gè)連接中發(fā)送多個(gè)請(qǐng)求（不需要等待任意請(qǐng)求的響應(yīng)）。收到請(qǐng)求的服務(wù)器必須按照請(qǐng)求收到的順序發(fā)送響應(yīng)。

• 1
• 2

至于標(biāo)準(zhǔn)為什么這么設(shè)定，我們可以大概推測(cè)一個(gè)原因：由于 HTTP/1.1 是個(gè)文本協(xié)議，同時(shí)返回的內(nèi)容也并不能區(qū)分對(duì)應(yīng)于哪個(gè)發(fā)送的請(qǐng)求，所以順序必須維持一致。比如你向服務(wù)器發(fā)送了兩個(gè)請(qǐng)求 GET/query?q=A 和 GET/query?q=B，服務(wù)器返回了兩個(gè)結(jié)果，瀏覽器是沒(méi)有辦法根據(jù)響應(yīng)結(jié)果來(lái)判斷響應(yīng)對(duì)應(yīng)于哪一個(gè)請(qǐng)求的。

Pipelining 這種設(shè)想看起來(lái)比較美好，但是在實(shí)踐中會(huì)出現(xiàn)許多問(wèn)題：

• 一些代理服務(wù)器不能正確的處理 HTTP Pipelining。
• 正確的流水線(xiàn)實(shí)現(xiàn)是復(fù)雜的。
• Head-of-line Blocking 連接頭阻塞：在建立起一個(gè) TCP 連接之后，假設(shè)客戶(hù)端在這個(gè)連接連續(xù)向服務(wù)器發(fā)送了幾個(gè)請(qǐng)求。按照標(biāo)準(zhǔn)，服務(wù)器應(yīng)該按照收到請(qǐng)求的順序返回結(jié)果，假設(shè)服務(wù)器在處理首個(gè)請(qǐng)求時(shí)花費(fèi)了大量時(shí)間，那么后面所有的請(qǐng)求都需要等著首個(gè)請(qǐng)求結(jié)束才能響應(yīng)。

所以現(xiàn)代瀏覽器默認(rèn)是不開(kāi)啟 HTTP Pipelining 的。

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

綠色是發(fā)起請(qǐng)求到請(qǐng)求返回的等待時(shí)間，藍(lán)色是響應(yīng)的下載時(shí)間，可以看到都是在同一個(gè) Connection，并行完成的

所以這個(gè)問(wèn)題也有了答案：在 HTTP/1.1 存在 Pipelining 技術(shù)可以完成這個(gè)多個(gè)請(qǐng)求同時(shí)發(fā)送，但是由于瀏覽器默認(rèn)關(guān)閉，所以可以認(rèn)為這是不可行的。在 HTTP2 中由于 Multiplexing 特點(diǎn)的存在，多個(gè) HTTP 請(qǐng)求可以在同一個(gè) TCP 連接中并行進(jìn)行。

那么在 HTTP/1.1 時(shí)代，瀏覽器是如何提高頁(yè)面加載效率的呢？主要有下面兩點(diǎn)：

• 維持和服務(wù)器已經(jīng)建立的 TCP 連接，在同一連接上順序處理多個(gè)請(qǐng)求。
• 和服務(wù)器建立多個(gè) TCP 連接。

為什么有時(shí)候刷新頁(yè)面不需要重新建立 SSL 連接？

在上面問(wèn)題的討論中已經(jīng)有答案了，TCP 連接有的時(shí)候會(huì)被瀏覽器和服務(wù)端維持一段時(shí)間。TCP 不需要重新建立，SSL 自然也會(huì)用之前的。

瀏覽器對(duì)同一 Host 建立 TCP 連接到數(shù)量有沒(méi)有限制？

假設(shè)我們還處在 HTTP/1.1 時(shí)代，那個(gè)時(shí)候沒(méi)有多路傳輸，當(dāng)瀏覽器拿到一個(gè)有幾十張圖片的網(wǎng)頁(yè)該怎么辦呢？肯定不能只開(kāi)一個(gè) TCP 連接順序下載，那樣用戶(hù)肯定等的很難受，但是如果每個(gè)圖片都開(kāi)一個(gè) TCP 連接發(fā) HTTP 請(qǐng)求，那電腦或者服務(wù)器都可能受不了，要是有 1000 張圖片的話(huà)總不能開(kāi) 1000 個(gè)TCP 連接吧，你的電腦同意 NAT 也不一定會(huì)同意。

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

收到的 HTML 如果包含幾十個(gè)圖片標(biāo)簽，這些圖片是以什么方式、什么順序、建立了多少連接、使用什么協(xié)議被下載下來(lái)的呢？

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

往期文章

網(wǎng)絡(luò)編程知識(shí)預(yù)備(1) ——了解OSI網(wǎng)絡(luò)模型
網(wǎng)絡(luò)編程知識(shí)預(yù)備(2) ——淺顯易懂的三次握手與四次揮手
網(wǎng)絡(luò)編程知識(shí)預(yù)備(3) ——SOCKET、TCP、HTTP之間的區(qū)別與聯(lián)系
網(wǎng)絡(luò)編程知識(shí)預(yù)備(4) ——了解HTTP協(xié)議與HTTPS協(xié)議
網(wǎng)絡(luò)編程知識(shí)預(yù)備(5) ——libcurl庫(kù)簡(jiǎn)介及其編程訪(fǎng)問(wèn)百度首頁(yè)

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。