TCP/IP & HTTP & Socket

網(wǎng)絡(luò)七層：物理層，數(shù)據(jù)鏈路層，網(wǎng)絡(luò)層，傳輸層，會(huì)話層，表示層，應(yīng)用層。

一.TCP/IP

tcp/ip協(xié)議：是一種傳輸層協(xié)議。主要解決數(shù)據(jù)如何在網(wǎng)絡(luò)中傳輸。

二.HTTP

  • http協(xié)議：超文本協(xié)議，是一種應(yīng)用層協(xié)議，主要是解決如何包裝數(shù)據(jù)。它?；?code>tcp/ip協(xié)議進(jìn)行連接。
  • https協(xié)議：安全超文本協(xié)議，是在http協(xié)議（信息是明文傳輸）的基礎(chǔ)上，使用了SSL進(jìn)行加密，即https=http+SSL。
  • 短連接：連接->數(shù)據(jù)傳輸->關(guān)閉連接任務(wù)結(jié)束就中斷連接。

三.Socket

  • Socket是對(duì)tcp/ip協(xié)議的封裝，是一個(gè)調(diào)用的接口api。通過(guò)該Socket才能使用tcp/ip協(xié)議。
  • 長(zhǎng)連接：連接->傳輸數(shù)據(jù)->保持連接->傳輸數(shù)據(jù)...->關(guān)閉連接，安全性較差。

四.Socket連接與斷開(kāi)

Socket連接是由底層封裝的tcp協(xié)議發(fā)起的，tcp協(xié)議需要經(jīng)過(guò)“三次握手”來(lái)完成：

  • 第一次握手：客戶端發(fā)送一個(gè)syn包給服務(wù)器，然后進(jìn)入SYN_SEND狀態(tài)，等待服務(wù)器確認(rèn)。

解釋?zhuān)?/strong>客戶端發(fā)送的這個(gè)syn包給服務(wù)器，是為了告訴服務(wù)器，客戶端的序列號(hào)為X。

  • 第二次握手：服務(wù)器收到客戶端的syn包，先確認(rèn)客戶端的syn包，發(fā)送一個(gè)syn+ack包給客戶端，然后進(jìn)入SYN_RECV狀態(tài)。

解釋?zhuān)?/strong>服務(wù)器確認(rèn)客戶端的syn包之后，服務(wù)器就知道客戶端的序列號(hào)是X。服務(wù)器發(fā)送給客戶端的syn+ack包，當(dāng)中包含一個(gè)ack包和一個(gè)syn包。其中的ack包是服務(wù)器為了告訴客戶端，服務(wù)器已經(jīng)收到了客戶端的syn包，并且知道客戶端的序列號(hào)是X；其中的syn包是服務(wù)器為了告訴客戶端，服務(wù)器的序列號(hào)為Y。

  • 第三次握手：客戶端收到服務(wù)器的syn+ack包，再向服務(wù)器發(fā)送一個(gè)ack包。發(fā)送完畢，客戶端和服務(wù)器都進(jìn)入ESTABLISHED狀態(tài)，連接建立。

解釋?zhuān)?/strong>客戶端收到服務(wù)器的syn+ack包，通過(guò)其中的syn包知道服務(wù)器的序列號(hào)為Y。然后再向服務(wù)器發(fā)送的ack包是客戶端為了告訴服務(wù)器，客戶端已經(jīng)知道收到了服務(wù)器的syn+ack包，并且知道服務(wù)器的序列號(hào)為Y。

注：三次握手過(guò)程中發(fā)送的這些包不包含數(shù)據(jù)，三次握手完成之后，連接建立，客戶端與服務(wù)器之間才開(kāi)始傳送數(shù)據(jù)。

在理想狀態(tài)下，tcp連接一旦建立，在通信雙方中的任何一方主動(dòng)關(guān)閉連接之前，tcp連接都將被一直保持下去。斷開(kāi)連接時(shí)服務(wù)器和客戶端均可以主動(dòng)發(fā)起斷開(kāi)tcp連接的請(qǐng)求，斷開(kāi)過(guò)程需要經(jīng)過(guò)“四次揮手”來(lái)完成（下面由客戶端發(fā)起關(guān)閉tcp連接）：

  • 第一次揮手：客戶端會(huì)發(fā)送一個(gè)FIN報(bào)文給服務(wù)器，并且停止發(fā)送數(shù)據(jù)，然后進(jìn)入FIN-WAIT-1狀態(tài)（終止等待1狀態(tài),等待服務(wù)器的響應(yīng)）。

解釋?zhuān)?/strong>FIN報(bào)文即連接釋放報(bào)文，客戶端發(fā)送FIN報(bào)文給服務(wù)器，是為了告訴服務(wù)器，客戶端的序列號(hào)是X，客戶端請(qǐng)求關(guān)閉連接。

  • 第二次揮手：服務(wù)器接收到FIN報(bào)文之后, 先確認(rèn)客戶端的FIN報(bào)文, 再發(fā)送一條ack包給客戶端，服務(wù)器進(jìn)入CLOSE_WAIT狀態(tài)（關(guān)閉等待）。

解釋?zhuān)?/strong>服務(wù)器確認(rèn)客戶端的FIN報(bào)文之后，就知道了客戶端的序列號(hào)是X，請(qǐng)求關(guān)閉連接。發(fā)送一條ack包給客戶端，是服務(wù)器為了告訴客戶端，服務(wù)器已經(jīng)收到了客戶端的FIN報(bào)文，并且知道客戶端的序列號(hào)是X。當(dāng)客戶端收到服務(wù)器的ack包之后，客戶端就進(jìn)入FIN-WAIT-2（終止等待2）狀態(tài)。這個(gè)時(shí)候，整個(gè)tcp連接處于一個(gè)半關(guān)閉狀態(tài),即客戶端已經(jīng)沒(méi)有數(shù)據(jù)要發(fā)送了，但是服務(wù)器若發(fā)送數(shù)據(jù)，客戶端依然要接受。

  • 第三次揮手：服務(wù)器發(fā)送一條FIN報(bào)文給客戶端，服務(wù)器進(jìn)入LAST-ACK（最后確認(rèn)）狀態(tài)。

解釋?zhuān)?/strong>服務(wù)器發(fā)送一條FIN報(bào)文給客戶端，是為了告訴客戶端，服務(wù)器的序列號(hào)為Y，服務(wù)器已經(jīng)沒(méi)有數(shù)據(jù)要發(fā)送了，現(xiàn)在可以關(guān)閉tcp連接了。

  • 第四次揮手：客戶端收到服務(wù)器的FIN報(bào)文，先確認(rèn)服務(wù)器的FIN報(bào)文，然后發(fā)送一條ack包給服務(wù)器，客戶端就進(jìn)入了TIME-WAIT（時(shí)間等待）狀態(tài)。

解釋?zhuān)?/strong>客戶端確認(rèn)服務(wù)器的FIN報(bào)文之后，就知道了服務(wù)器的序列號(hào)是Y，并且已經(jīng)沒(méi)有數(shù)據(jù)要傳送了。然后客戶端再發(fā)送一條ack包給服務(wù)器，是為了告訴服務(wù)器，客戶端知道了?？蛻舳诉M(jìn)入了TIME-WAIT（時(shí)間等待）狀態(tài)。
注意，這個(gè)時(shí)候客戶端進(jìn)入時(shí)間等待狀態(tài)，tcp連接還沒(méi)有關(guān)閉，必須等到服務(wù)端收到ack包，進(jìn)入CLOSED狀態(tài)，客戶端也從時(shí)間等待狀態(tài)進(jìn)入CLOSED狀態(tài)之后，tcp連接才關(guān)閉。

五.HTTP連接

http連接是客戶端發(fā)送的每個(gè)請(qǐng)求都需要服務(wù)器那邊響應(yīng)回送，當(dāng)請(qǐng)求結(jié)束的時(shí)候，就自動(dòng)關(guān)閉http連接，因此被稱為短連接。因此要保持客戶端程序的在線狀態(tài)，就需要不斷的向服務(wù)器發(fā)送連接請(qǐng)求。

  • 即使不需要獲得任何數(shù)據(jù)，客戶端也保持每隔一段固定的時(shí)間向服務(wù)器發(fā)送一次保持連接的請(qǐng)求。
  • 服務(wù)器如果收到客戶端的連接請(qǐng)求進(jìn)行回復(fù)，服務(wù)器就知道客戶端在線狀態(tài)。如果長(zhǎng)時(shí)間無(wú)法收到客戶的的連接請(qǐng)求，服務(wù)器就認(rèn)為客戶端下線狀態(tài)。
  • 如果客戶端發(fā)送了連接請(qǐng)求但是收不到服務(wù)器的回復(fù)，客戶端則認(rèn)為網(wǎng)絡(luò)斷開(kāi)。

六.UDP與TCP對(duì)比

UDP與TCP一樣，也是一種傳輸層的協(xié)議。不過(guò)udp協(xié)議不需要像tcp協(xié)議那樣建立連接（即tcp協(xié)議的三次握手），所以：

  • tcp：面向連接（傳輸數(shù)據(jù)前需要先建立tcp連接 三次握手），傳輸可靠，一般不會(huì)出現(xiàn)數(shù)據(jù)丟包現(xiàn)象（建立連接可以保證數(shù)據(jù)的安全）。但是傳輸速度比較慢，會(huì)出現(xiàn)延遲現(xiàn)象（建立連接需要時(shí)間和系統(tǒng)資源的消耗）。適合用于傳輸數(shù)據(jù)量級(jí)大的數(shù)據(jù)，由于客戶端和服務(wù)器的連接要長(zhǎng)時(shí)間保持著，對(duì)服務(wù)器的消耗相對(duì)來(lái)說(shuō)比較大。

例如：公司內(nèi)部的局域網(wǎng)。

  • udp：面向非連接，傳輸不可靠，經(jīng)常會(huì)出現(xiàn)數(shù)據(jù)丟包現(xiàn)象。但是傳輸速度比較快，不會(huì)出現(xiàn)延遲現(xiàn)象。適合用于傳輸數(shù)據(jù)量級(jí)小的數(shù)據(jù)（數(shù)據(jù)量級(jí)越大越容易出現(xiàn)數(shù)據(jù)丟包現(xiàn)象），對(duì)服務(wù)器的消耗相對(duì)來(lái)說(shuō)比較小。

例如：大規(guī)模即時(shí)通訊軟件（微信，QQ）。

  • 使用tcp協(xié)議與客戶端進(jìn)行短命連接，這樣既能確保數(shù)據(jù)的安全性，又能減少對(duì)服務(wù)器的消耗。這種情況適用于客戶端與服務(wù)器數(shù)據(jù)交互不是很頻繁的業(yè)務(wù)。

例如：客戶端向服務(wù)器請(qǐng)求好友列表的數(shù)據(jù)，先建立tcp連接，然后傳輸數(shù)據(jù)，數(shù)據(jù)傳輸完成，關(guān)閉連接。等到下次需要請(qǐng)求還有列表數(shù)據(jù)時(shí)再重新建立連接。

七.選擇哪種協(xié)議的問(wèn)題

  • 如果是只由客戶端發(fā)起的間隔性的連接請(qǐng)求，可以發(fā)生延遲現(xiàn)象，那么使用http/https。
  • 如果是由客戶端或服務(wù)端發(fā)起的連接請(qǐng)求，可以發(fā)生延遲現(xiàn)象，那么使用tcp。
  • 如果是由客戶端或服務(wù)端發(fā)起的連接請(qǐng)求，不可以發(fā)生延遲現(xiàn)象，那么使用udp。
最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡(jiǎn)書(shū)系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容