摘要:傳輸控制協(xié)議概述最主要的特點(diǎn)是面向連接的運(yùn)輸層協(xié)議。應(yīng)用程序在使用協(xié)議之前,必須先建立連接。當(dāng)時(shí),表明此報(bào)文段的發(fā)送發(fā)的數(shù)據(jù)已發(fā)送完畢,并要求釋放運(yùn)輸連接窗口占字節(jié)。
傳輸控制協(xié)議 TCP 概述 TCP 最主要的特點(diǎn)
TCP 是面向連接的運(yùn)輸層協(xié)議。應(yīng)用程序在使用 TCP 協(xié)議之前,必須先建立 TCP 連接。在傳送數(shù)據(jù)完畢后,必須釋放已經(jīng)建立的 TCP 連接
每一條 TCP 連接只能有兩個(gè)端點(diǎn),每一條 TCP 連接只能是點(diǎn)對(duì)點(diǎn)的(一對(duì)一)
TCP 提供可靠交付的服務(wù)。通過(guò) TCP 連接傳送的數(shù)據(jù),無(wú)差錯(cuò)、不丟失、不重復(fù),并且按序到達(dá)
TCP 提供全雙工通信。TCP 允許通信雙方的應(yīng)用進(jìn)程在任何時(shí)候都能發(fā)送數(shù)據(jù)。TCP 連接的兩端都設(shè)有發(fā)送緩存和接受緩存,用來(lái)臨時(shí)存放雙向通信的數(shù)據(jù)
面向字節(jié)流。TCP 中的“流”指的是流入到進(jìn)程或從進(jìn)程流出的字節(jié)序列
面向字節(jié)流“面向字節(jié)流”的含義是:雖然應(yīng)用程序和 TCP 的交互式一次一個(gè)數(shù)據(jù)塊(大小不等),但 TCP 把應(yīng)用程序交下來(lái)的數(shù)據(jù)僅僅看成是一連串的無(wú)結(jié)構(gòu)的字節(jié)流。TCP 并不知道所傳送的字節(jié)流的含義
TCP 不保證接收方應(yīng)用程序所收到的數(shù)據(jù)塊和發(fā)送方應(yīng)用程序所發(fā)出的數(shù)據(jù)塊具有對(duì)應(yīng)大小的關(guān)系
例如,發(fā)送方應(yīng)用程序交給發(fā)送方的 TCP 共10個(gè)數(shù)據(jù)塊,但接收方的 TCP 可能只用了4個(gè)數(shù)據(jù)塊就把收到的字節(jié)流交付上層的應(yīng)用程序
接收方應(yīng)用程序收到的字節(jié)流必須和發(fā)送方應(yīng)用程序發(fā)出的字節(jié)流完全一樣。接收方的應(yīng)用程序必須有能力識(shí)別收到的字節(jié)流,把它還原成有意義的應(yīng)用層數(shù)據(jù)
TCP 和 UDP 在發(fā)送報(bào)文時(shí)采用的方式完全不同。TCP 并不關(guān)心應(yīng)用進(jìn)程一次把多長(zhǎng)的報(bào)文發(fā)送到 TCP 的緩存中,而是根據(jù)對(duì)方給出的窗口值和當(dāng)前網(wǎng)絡(luò)擁塞的程度來(lái)決定一個(gè)報(bào)文段應(yīng)包含多少個(gè)字節(jié)(UDP 發(fā)送的報(bào)文長(zhǎng)度是應(yīng)用進(jìn)程給出的)。如果應(yīng)用進(jìn)程傳送到 TCP 緩存的數(shù)據(jù)塊太長(zhǎng),TCP 就可以把它劃分短一些再傳送。如果應(yīng)用進(jìn)程一次只發(fā)來(lái)一個(gè)字節(jié),TCP 也可以等待積累有足夠多的字節(jié)后再構(gòu)成報(bào)文段發(fā)送出去
《PHP面試問(wèn)答》 https://github.com/colinlet/P...TCP 的連接
結(jié)合實(shí)際 PHP 面試,系統(tǒng)的匯總面試中的各種各樣的問(wèn)題,嘗試提供簡(jiǎn)潔準(zhǔn)確的答案。如果你在 PHP 面試中遇到問(wèn)題,歡迎提 Issues 交流。包含網(wǎng)絡(luò)協(xié)議、數(shù)據(jù)結(jié)構(gòu)與算法、PHP、Web、MySQL、Redis、Linux、安全、設(shè)計(jì)模式、架構(gòu)、自我介紹、離職原因、職業(yè)規(guī)劃、準(zhǔn)備問(wèn)題等部分
如果覺(jué)得不錯(cuò)歡迎 star 關(guān)注,正在不斷持續(xù)更新中~~
TCP 把連接作為最基本的抽象。TCP 的許多特性都與 TCP 是面向連接的這個(gè)基本特性有關(guān)
TCP 連接的端點(diǎn)叫做套接字(socket)或插口,根據(jù) RFC 793 的定義:端口號(hào)拼接到(concatenated with) IP 地址即構(gòu)成了套接字
套接字 socket = (IP 地址:端口號(hào))
每一條 TCP 連接唯一地被通信兩端的兩個(gè)端點(diǎn)(即兩個(gè)套接字)所確定
TCP 連接 ::= {socket1, socket2} = {(IP1: port1), (IP2: port2)}
TCP 連接就是由協(xié)議軟件所提供的一種抽象。TCP 連接的端口是個(gè)很抽象的套接字,即( IP地址: 端口號(hào))。同一個(gè) IP 地址可以有多個(gè)不同的 TCP 連接,而同一個(gè)端口號(hào)也可以出現(xiàn)在多個(gè)不同的 TCP 連接中
易混淆的 socket同一個(gè)名詞 socket 卻可表示多種不同的意思,以下 socket 的意思跟本文中所引用的 RFC 793 定義的 socket(指端口號(hào)拼接到 IP 地址)不同
允許應(yīng)用程序訪問(wèn)連網(wǎng)協(xié)議的應(yīng)用編程接口 API(Application Programming Interface),即運(yùn)輸層和應(yīng)用層之間的接口,稱(chēng)為 socket API,并簡(jiǎn)稱(chēng)為 socket
在 socket API 中使用的一個(gè)函數(shù)名也叫做 socket
調(diào)用 socket 函數(shù)的端點(diǎn)稱(chēng)為 socket,如“創(chuàng)建一個(gè)數(shù)據(jù)報(bào) socket”
調(diào)用 socket 函數(shù)時(shí),其返回值稱(chēng)為 socket 描述符,可簡(jiǎn)稱(chēng)為 socket
在操作系統(tǒng)內(nèi)核中連網(wǎng)協(xié)議的 Berkeley 實(shí)現(xiàn),稱(chēng)為 socket 實(shí)現(xiàn)
可靠傳輸?shù)墓ぷ髟?/b> 理想的傳輸條件理想的傳輸條件有以下兩個(gè)特點(diǎn)
傳輸信道不產(chǎn)生差錯(cuò)
不管發(fā)送方以多快的速度發(fā)送數(shù)據(jù),接收方總是來(lái)得及處理收到的數(shù)據(jù)
實(shí)際的網(wǎng)絡(luò)不具備以上兩個(gè)理想條件。需要使用一些可靠的傳輸協(xié)議,當(dāng)出現(xiàn)差錯(cuò)時(shí)讓發(fā)送方重傳出現(xiàn)差錯(cuò)的數(shù)據(jù),同時(shí)在接收方來(lái)不及處理收到的數(shù)據(jù)時(shí),及時(shí)告訴發(fā)送方適當(dāng)減低發(fā)送數(shù)據(jù)的速度。這樣,不可靠的傳輸信道就能夠?qū)崿F(xiàn)可靠傳輸了
停止等待協(xié)議全雙工通信的雙方既是發(fā)送方也是接收方。把傳送的數(shù)據(jù)單元都稱(chēng)為分組?!巴V沟却本褪敲堪l(fā)完一個(gè)分組就停止發(fā)送,等待對(duì)方的確認(rèn)。在收到確認(rèn)后再發(fā)送下一個(gè)分組
無(wú)差錯(cuò)情況 出現(xiàn)差錯(cuò)只要超過(guò)一段時(shí)間沒(méi)有收到確認(rèn),就認(rèn)為剛才發(fā)送的分組丟失了,因而重傳前面發(fā)送過(guò)的分組。這就叫做超時(shí)重傳。要實(shí)現(xiàn)超時(shí)重傳,就要在每發(fā)送完一個(gè)分組時(shí)設(shè)置一個(gè)超時(shí)計(jì)時(shí)器
發(fā)送完一個(gè)分組后,必須暫時(shí)保留已發(fā)送的分組的副本(在發(fā)生超時(shí)重傳時(shí)使用)。只有在收到相應(yīng)的確認(rèn)后才能清除暫時(shí)保留的分組副本
分組和確認(rèn)分組都必須進(jìn)行編號(hào)。這樣才能明確是哪一個(gè)發(fā)送出去的分組收到了確認(rèn),而哪一個(gè)分組還沒(méi)有收到確認(rèn)
超時(shí)計(jì)時(shí)器的重傳時(shí)間應(yīng)當(dāng)比數(shù)據(jù)在分組傳輸?shù)钠骄禃r(shí)間更長(zhǎng)一些
確認(rèn)丟失和確認(rèn)遲到使用上述的確認(rèn)和重傳機(jī)制,我們就可以在不可靠的傳輸網(wǎng)絡(luò)上實(shí)現(xiàn)可靠的通信
像上述的這種可靠傳輸協(xié)議常稱(chēng)為自動(dòng)重傳請(qǐng)求 ARQ(Automatic Repeat reQuest)。重傳的請(qǐng)求是自動(dòng)進(jìn)行的。接收方不需要請(qǐng)求發(fā)送方重傳某個(gè)出錯(cuò)的分組
信道利用率停止等待協(xié)議的優(yōu)點(diǎn)是簡(jiǎn)單,但缺點(diǎn)是信道利用率太低
為了提高傳輸效率,發(fā)送方可以不使用低效率的停止等待協(xié)議,而是采用流水線傳輸。流水線傳輸就是發(fā)送方可連續(xù)發(fā)送多個(gè)分組,不必每發(fā)完一個(gè)分組就停頓下來(lái)等待對(duì)方的確認(rèn)。這樣可使信道上一直有數(shù)據(jù)不間斷地在傳送。這種傳輸方式可以獲得很高的信道利用率
連續(xù) ARQ 協(xié)議位于發(fā)送窗口內(nèi)的5個(gè)分組都可以連續(xù)發(fā)送出去,而不需要等待對(duì)方的確認(rèn)??梢蕴岣咝诺览寐?/p>
接收方一般都是采用累積確認(rèn)的方式。接收方不需要對(duì)收到的分組逐個(gè)發(fā)送確認(rèn),而是在收到幾個(gè)分組后,對(duì)按序到達(dá)的最后一個(gè)分組發(fā)送確認(rèn)
積累確認(rèn)有優(yōu)點(diǎn)也有缺點(diǎn)。優(yōu)點(diǎn)是:容易實(shí)現(xiàn),即使確認(rèn)丟失也不必重傳。缺點(diǎn)是不能向發(fā)送方反映出接收方已經(jīng)正確收到的所有分組的信息
TCP 報(bào)文段的首部格式TCP 雖然是面向字節(jié)流的,但 TCP 傳送的數(shù)據(jù)單元卻是報(bào)文段。一個(gè) TCP 報(bào)文段分為首部和數(shù)據(jù)兩部分。TCP 報(bào)文段首部的前20個(gè)字節(jié)是固定的,后面有4n字節(jié)是根據(jù)需要而增加的選項(xiàng)(n是整數(shù))。因此 TCP 首部的最小長(zhǎng)度是20字節(jié)
首部字段源端口和目的端口 各占2個(gè)字節(jié),分別寫(xiě)入源端口號(hào)和目的端口號(hào)
序號(hào) 占4字節(jié)。序號(hào)范圍是[0, 232-1],共232(即4 294 967 296)個(gè)序號(hào)。序號(hào)增加到232-1后,下一個(gè)序號(hào)就又回到0。在一個(gè) TCP 連接中傳送的字節(jié)流中的每一個(gè)字節(jié)都按順序編號(hào)
確認(rèn)號(hào) 占4字節(jié),是期望收到對(duì)方下一個(gè)報(bào)文段的第一個(gè)數(shù)據(jù)字節(jié)的序號(hào)
數(shù)據(jù)偏移 占4字節(jié),它指出 TCP 報(bào)文段的數(shù)據(jù)起始處距離 TCP 報(bào)文段的起始處有多遠(yuǎn)。這個(gè)字段實(shí)際上是指出 TCP 報(bào)文段的首部長(zhǎng)度
保留 占6位,保留為今后使用,但目前應(yīng)置為0
下面有6個(gè)控制位,用來(lái)說(shuō)明本報(bào)文段的性質(zhì)
緊急 URG(URGent) 當(dāng) URG=1 時(shí),表明緊急指針字段有效。它告訴系統(tǒng)此報(bào)文段中有緊急數(shù)據(jù),應(yīng)盡快傳送(相當(dāng)于高優(yōu)先級(jí)的數(shù)據(jù)),而不是按原先的排隊(duì)順序來(lái)傳送
確認(rèn) ACK(ACKnowledgment) 僅當(dāng) ACK=1 時(shí)確認(rèn)號(hào)字段才有效。當(dāng) ACK=0 時(shí),確認(rèn)號(hào)無(wú)效。TCP 規(guī)定,在連接建立后所有傳送的報(bào)文段都必須把 ACK 置1
推送 PSH(Push) 當(dāng)兩個(gè)應(yīng)用進(jìn)程進(jìn)行交互式的通信時(shí),有時(shí)在一端的應(yīng)用進(jìn)程希望在鍵入一個(gè)命令后立即就能夠收到對(duì)方的響應(yīng)
復(fù)位 RST(ReSeT) 當(dāng) RST=1 時(shí),表明 TCP 連接中出現(xiàn)嚴(yán)重差錯(cuò)(如由于主機(jī)崩潰或其他原因),必須釋放連接,然后再重新建立運(yùn)輸連接
同步 SYN(SYNnchronization) 在連接建立時(shí)用來(lái)同步序號(hào)。當(dāng) SYN=1 而 ACK=0 時(shí),表明這是一個(gè)連接請(qǐng)求報(bào)文段。對(duì)方若同意建立連接,則應(yīng)在響應(yīng)的報(bào)文段中使 SYN=1 和 ACK=1
終止 FIN(FINis) 用來(lái)釋放一個(gè)連接。當(dāng) FIN=1 時(shí),表明此報(bào)文段的發(fā)送發(fā)的數(shù)據(jù)已發(fā)送完畢,并要求釋放運(yùn)輸連接
窗口 占2字節(jié)。窗口值是[0, 216-1]之間的整數(shù)。窗口值作為接收方讓發(fā)送方設(shè)置其發(fā)送窗口的依舊
檢驗(yàn)和 占2字節(jié)。檢驗(yàn)和字段檢驗(yàn)的范圍包括首部和數(shù)據(jù)這兩部分
緊急指針 占2字節(jié)。緊急指針僅在 URG=1 時(shí)才有意義,它指出本報(bào)文段中的緊急數(shù)據(jù)的字節(jié)數(shù)
選項(xiàng) 長(zhǎng)度可變,最長(zhǎng)可達(dá)40字節(jié)
TCP 可靠傳輸?shù)膶?shí)現(xiàn) 以字節(jié)為單位的滑動(dòng)窗口 發(fā)送窗口構(gòu)造TCP 的滑動(dòng)窗口是以字節(jié)為單位的。假定 A 收到了 B 發(fā)來(lái)的確認(rèn)報(bào)文段,其中窗口是20字節(jié),而確認(rèn)號(hào)是31(這表明 B 期望收到的下一個(gè)序號(hào)是31,而序號(hào)30為止的數(shù)據(jù)已經(jīng)收到了)。根據(jù)這兩個(gè)數(shù)據(jù),A 就構(gòu)造出自己的發(fā)送窗口
發(fā)送窗口標(biāo)識(shí):在沒(méi)有收到 B 的確認(rèn)的情況下,A 可以連續(xù)把窗口內(nèi)的數(shù)據(jù)都發(fā)送出去。凡是已經(jīng)發(fā)送出去的數(shù)據(jù),在未收到確認(rèn)之前都必須暫時(shí)保留,以便在超時(shí)重傳時(shí)使用
發(fā)送窗口變化發(fā)送窗口的位置由窗口前沿和后沿的位置共同確定。發(fā)送窗口后沿的變化情況有兩種,即不動(dòng)(沒(méi)有收到新的確認(rèn))和前移(收到了新的確認(rèn))。發(fā)送窗口后沿不可能向后移動(dòng),因?yàn)椴荒艹蜂N(xiāo)已收到的確認(rèn)
發(fā)送窗口前沿通常是不斷向前移動(dòng),但也有可能不動(dòng)。這對(duì)應(yīng)于兩種情況:
一是沒(méi)有收到信的確認(rèn),對(duì)應(yīng)通知的窗口大小也不變
二是收到了新的窗口單對(duì)方通知的窗口縮小了,使得發(fā)送窗口前沿正好不動(dòng)
發(fā)送窗口前沿也有可能向后收縮。這發(fā)生在對(duì)方通知的窗口縮小了。但 TCP 的標(biāo)準(zhǔn)強(qiáng)烈不贊成這樣做。因?yàn)楹芸赡馨l(fā)送方在收到這個(gè)通知以前已經(jīng)發(fā)生了窗口中的許多數(shù)據(jù),現(xiàn)在又要收縮窗口,不讓發(fā)送這些數(shù)據(jù),這樣就會(huì)產(chǎn)生一些錯(cuò)誤
要描述一個(gè)發(fā)送窗口的狀態(tài)需要三個(gè)指針:P1,P2,P3。指針都指向字節(jié)的序號(hào)。這三個(gè)指針指向的幾個(gè)部分的意義如下:
小于 P1 的是已發(fā)送并已收到確認(rèn)的部分,而大于 P3 的是不允許發(fā)送的部分
P3 - P1 = A 的發(fā)送窗口
P2 - P1 已發(fā)送但尚未收到確認(rèn)的字節(jié)數(shù)
P3 - P2 允許發(fā)送但當(dāng)前尚未發(fā)送的字節(jié)數(shù)(又稱(chēng)為可用窗口或有效窗口)
B 的接收窗口大小是20。在接收窗口外面,到30號(hào)為止的數(shù)據(jù)是已經(jīng)發(fā)送過(guò)確認(rèn),并且已經(jīng)交付主機(jī)了。因此在 B 可以不再保留這些數(shù)據(jù)。接收窗口內(nèi)的序號(hào)(31~50)是允許接收的。在上圖中,B 收到了序號(hào)為32和33的數(shù)據(jù)。這些數(shù)據(jù)沒(méi)有按序到達(dá),因?yàn)樾蛱?hào)為31的數(shù)據(jù)沒(méi)有收到(也許丟失了,也許滯留在網(wǎng)絡(luò)中的某處)。請(qǐng)注意,B 只能對(duì)按序收到的數(shù)據(jù)中的最高序號(hào)給出確認(rèn),因此 B 發(fā)送的確認(rèn)報(bào)文段中的確認(rèn)號(hào)仍然是31(即期望收到的序號(hào)),而不是32或33
現(xiàn)在假定 B 收到了序號(hào)為31的數(shù)據(jù),并把序號(hào)為31~33的數(shù)據(jù)交付主機(jī),然后 B 刪除這些數(shù)據(jù)。接著把接收窗口向前移動(dòng)3個(gè)序號(hào),同時(shí)給 A 發(fā)送確認(rèn),其中窗口值仍為20,但確認(rèn)號(hào)是34.這表明 B 已經(jīng)收到了到序號(hào)33為止的數(shù)據(jù)。B 還收到了序號(hào)為37,38和40的數(shù)據(jù),但這些都沒(méi)有按序到達(dá),只能先暫存在接收窗口中。A 收到 B 的確認(rèn)后,就可以把發(fā)送窗口向前滑動(dòng)3個(gè)序號(hào),但指針 P2 不動(dòng)?,F(xiàn)在 A 的可用窗口增大了,可發(fā)送的序號(hào)范圍是42~53
A 在繼續(xù)發(fā)送完序號(hào)42~53的數(shù)據(jù)后,指針 P2 向前移動(dòng)和 P3 重合。發(fā)送窗口內(nèi)的序號(hào)都已用完,但還沒(méi)有再收到確認(rèn)。由于 A 的發(fā)送窗口已滿,可用窗口已減小到零,因此必須停止發(fā)送。發(fā)送窗口內(nèi)所有的數(shù)據(jù)都已正確到達(dá) B,B 也早已發(fā)出了確認(rèn)。但所有這些確認(rèn)都滯留在網(wǎng)絡(luò)中。在沒(méi)有收到 B 的確認(rèn)時(shí),A 不能猜測(cè):“或許 B 收到了吧!”為了保證可靠傳輸,A 只能認(rèn)為 B 還沒(méi)有收到這些數(shù)據(jù)。于是,A 在經(jīng)過(guò)一段時(shí)間后(由超時(shí)計(jì)時(shí)器控制)就重傳這部分?jǐn)?shù)據(jù),重新設(shè)置超時(shí)計(jì)時(shí)器,知道收到 B 的確認(rèn)為止。如果 A 收到確認(rèn)號(hào)落在發(fā)送窗口內(nèi),那么 A 就可以發(fā)送窗口繼續(xù)向前滑動(dòng),并發(fā)送新的數(shù)據(jù)
緩存和窗口發(fā)送方維持的發(fā)送緩存和發(fā)送窗口,以及接收方維持的接收緩存和接收窗口
發(fā)送緩存用來(lái)暫時(shí)存放:
發(fā)送應(yīng)用程序傳送給對(duì)方 TCP 準(zhǔn)備發(fā)送的數(shù)據(jù)
TCP 已發(fā)送出但尚未收到確認(rèn)的數(shù)據(jù)
已被確認(rèn)的數(shù)據(jù)應(yīng)當(dāng)從發(fā)送緩存中刪除,因此發(fā)送緩存和發(fā)送窗口的后沿是重合的。發(fā)送應(yīng)用程序必須控制寫(xiě)入緩存的速率,不能太快,否則發(fā)送緩存就會(huì)沒(méi)有存放數(shù)據(jù)的空間
接收緩存用來(lái)暫時(shí)存放:
按序到達(dá)的、但尚未被接收應(yīng)用程序讀取的數(shù)據(jù)
未按序到達(dá)的數(shù)據(jù)
收到的分組被檢測(cè)出有差錯(cuò),則丟棄。接收應(yīng)用程序來(lái)不及讀取收到的數(shù)據(jù),接收緩存最終就會(huì)被填滿,使接收窗口減小到零。接收應(yīng)用程序能夠及時(shí)從接收緩存中讀取收到的數(shù)據(jù),接收窗口就可以增大,最大亦不能超過(guò)接收緩存的大小
要點(diǎn)小結(jié):
雖然 A 的發(fā)送窗口是根據(jù) B 的接收窗口設(shè)置的,但在同一時(shí)刻,A 的發(fā)送窗口并不總是和 B 的接收窗口一樣大。通過(guò)網(wǎng)絡(luò)傳送窗口值需要經(jīng)歷一定的時(shí)間滯后,該時(shí)間并不確定的
對(duì)于不按序到達(dá)的數(shù)據(jù),TCP 通常是先臨時(shí)存放在接收窗口,等字節(jié)流中所缺少的字節(jié)收到后,在按序交付上層的應(yīng)用進(jìn)程
TCP 要求接收方必須有累積確認(rèn)的功能,這樣可以減少傳輸開(kāi)銷(xiāo)
超時(shí)重傳時(shí)間的選擇TCP 的發(fā)送方在規(guī)定的時(shí)間內(nèi)沒(méi)有收到確認(rèn)就要重傳已發(fā)送的報(bào)文段。這種重傳的概念是很簡(jiǎn)單的,但重傳時(shí)間的選擇卻是 TCP 最復(fù)雜的問(wèn)題之一
由于 TCP 的下層是互聯(lián)網(wǎng)環(huán)境,發(fā)送的報(bào)文段可能只經(jīng)過(guò)一個(gè)高速率的局域網(wǎng),也可能經(jīng)過(guò)多個(gè)低速率的網(wǎng)絡(luò),并且每個(gè) IP 數(shù)據(jù)報(bào)所選擇的路由還可能不同。如果把超時(shí)重傳時(shí)間設(shè)置得太短,就會(huì)引起很多報(bào)文段的必須要的重傳,使網(wǎng)絡(luò)負(fù)荷增大。但若把超時(shí)重傳時(shí)間設(shè)置的過(guò)長(zhǎng),則又使網(wǎng)絡(luò)的空閑時(shí)間增大,減低了傳輸效率
TCP 采用了一種自適應(yīng)算法,它記錄一個(gè)報(bào)文段發(fā)出的時(shí)間,以及收到相應(yīng)的確認(rèn)的時(shí)間。這兩個(gè)時(shí)間之差就是報(bào)文段的往返時(shí)間 RTT
新的 RTTs = (1 - α) x (舊的 RTTs) + α x (新的 RTT 樣本)
RTT:報(bào)文段往返時(shí)間
RTTs:加權(quán)平均往返時(shí)間
α: 0 ≤ α < 1,RFC 6298 推薦的 α 值為 1/8,即 0.125
RTO = RTTs + 4 x RTTD
RTO:超時(shí)重傳時(shí)間
RTTD:RTT 的偏差的加權(quán)平均值
新的 RTTD = (1 - β) x (舊的 RTTD) + β x |RTTs - 新的 RTT 樣本|
β:小于1的系數(shù),推薦值是 1/4,即 0.25
TCP 流量控制 利用滑動(dòng)窗口實(shí)現(xiàn)流量控制流量控制(flow control):讓發(fā)送方的發(fā)送速率不要太快,要讓接收方來(lái)得及接收
利用滑動(dòng)窗口機(jī)制可以很方便地在 TCP 連接上實(shí)現(xiàn)對(duì)發(fā)送方的流量控制
發(fā)送方的發(fā)送窗口不能超過(guò)接收方給出的接收窗口的數(shù)值。TCP 的窗口單位是字節(jié),不是報(bào)文段
避免死鎖:TCP 為每一個(gè)連接設(shè)有一個(gè)持續(xù)計(jì)時(shí)器(persistence timer)。只要 TCP 連接的一方收到對(duì)方的零窗口通知,就啟動(dòng)持續(xù)計(jì)時(shí)器。若持續(xù)計(jì)時(shí)器設(shè)置的時(shí)間到期,就發(fā)送一個(gè)零窗口探測(cè)報(bào)文段(僅攜帶1字節(jié)的數(shù)據(jù)),而對(duì)方就在確認(rèn)這個(gè)探測(cè)報(bào)文段時(shí)給出了現(xiàn)在的窗口值。如果窗口仍是零,那么收到這個(gè)報(bào)文段的一方就重新設(shè)置持續(xù)計(jì)時(shí)器。如果窗口不是零,那么死鎖的僵局就可以打破了
TCP 的傳輸效率 發(fā)送機(jī)制TCP 維持一個(gè)變量,它等于最大報(bào)文段長(zhǎng)度 MSS。只要緩存中存放的數(shù)據(jù)達(dá)到 MSS 字節(jié)時(shí),就組裝成一個(gè) TCP 報(bào)文段發(fā)送出去
由發(fā)送方的應(yīng)用進(jìn)程指明要求發(fā)送報(bào)文段,即 TCP 支持的推送(push)操作
發(fā)送方的一個(gè)計(jì)時(shí)器期限到了,這時(shí)把當(dāng)前已有的緩存數(shù)據(jù)裝入報(bào)文段(但長(zhǎng)度不能超過(guò) MSS)發(fā)送出去
Nagle 算法在 TCP 的實(shí)現(xiàn)中廣泛使用 Nagle 算法
若發(fā)送應(yīng)用進(jìn)程把要發(fā)送的數(shù)據(jù)逐個(gè)字節(jié)地送到 TCP 的發(fā)送緩存,則發(fā)送方就把第一個(gè)數(shù)據(jù)字節(jié)先發(fā)送出去,把后面到達(dá)的數(shù)據(jù)字節(jié)都緩存起來(lái)。當(dāng)發(fā)送方收到對(duì)第一個(gè)數(shù)據(jù)字符的確認(rèn)后,再把發(fā)送緩存中的所有數(shù)據(jù)組裝成一個(gè)報(bào)文段發(fā)送出去,同時(shí)繼續(xù)對(duì)隨后到達(dá)的數(shù)據(jù)進(jìn)行緩存。只有在收到對(duì)前一個(gè)報(bào)文段的確認(rèn)后才繼續(xù)發(fā)送下一個(gè)報(bào)文段。當(dāng)數(shù)據(jù)達(dá)到較快而網(wǎng)絡(luò)速率較慢時(shí),用這樣的方法可明顯地減少所用的網(wǎng)絡(luò)寬帶。Nagle 算法還規(guī)定,當(dāng)?shù)竭_(dá)的數(shù)據(jù)已達(dá)到發(fā)送窗口大小的一半或已達(dá)到報(bào)文段的最大長(zhǎng)度時(shí),就立即發(fā)送一個(gè)報(bào)文段。這樣可以有效提高網(wǎng)絡(luò)的吞吐量
糊涂窗口綜合征TCP 接收方的緩存已滿,僅剩一個(gè)字節(jié),并還將保持這種狀態(tài)持續(xù)一段時(shí)間。導(dǎo)致發(fā)送方只能發(fā)送一個(gè)字節(jié)。導(dǎo)致網(wǎng)絡(luò)的效率很低
為了解決這個(gè)問(wèn)題,可以讓接收方等待一段時(shí)間,使得或者接受緩存已有足夠空間容納一個(gè)最長(zhǎng)的報(bào)文段,或者等到接受緩存已有一半空閑的空間。只要出現(xiàn)這兩種情況之一,接收方就發(fā)出確認(rèn)報(bào)文,并向發(fā)送方通知當(dāng)前的窗口大小。發(fā)送方也不要發(fā)送大小的報(bào)文段,而是把數(shù)據(jù)積累成足夠大的報(bào)文段,或達(dá)到接收方緩存的空間的一半大小
TCP 的擁塞控制 擁塞控制的一般原理在計(jì)算機(jī)網(wǎng)絡(luò)中的鏈路容量(即寬帶)、交換結(jié)點(diǎn)中的緩存和處理機(jī)等,都是網(wǎng)絡(luò)資源。在某段時(shí)間,若對(duì)網(wǎng)絡(luò)中某一資源的需求超過(guò)了該資源所能提供的可用部分,網(wǎng)絡(luò)的性能就要變壞。這種情況就叫做擁塞(congestion)
擁塞控制就是防止過(guò)多的數(shù)據(jù)注入到網(wǎng)絡(luò)中,這樣可以使網(wǎng)絡(luò)中的路由器或鏈路不致過(guò)載。擁塞控制所要做的都是一個(gè)前提,就是網(wǎng)絡(luò)能夠承受現(xiàn)有的網(wǎng)絡(luò)負(fù)荷
TCP 的擁塞控制方法TCP 進(jìn)行擁塞控制的算法有四種,即慢開(kāi)始(slow-start)、擁塞避免(congestion avoidance)、快重傳(fast retransmit)和快恢復(fù)(fast recovery)
慢開(kāi)始當(dāng)主機(jī)開(kāi)始發(fā)送數(shù)據(jù)時(shí),由于并不清楚網(wǎng)絡(luò)的負(fù)荷情況,如果立即把大量數(shù)據(jù)字節(jié)注入到網(wǎng)絡(luò),就有可能引起網(wǎng)絡(luò)發(fā)生擁塞。經(jīng)驗(yàn)證明,較好的方法是先探測(cè)一下,即由小到大逐漸增大發(fā)送窗口,也就是說(shuō),由小到大逐漸增大擁塞窗口數(shù)值
cwnd:發(fā)送方的擁塞窗口,開(kāi)始發(fā)送方設(shè)置 cwnd = 1
擁塞避免讓擁塞窗口 cwnd 緩慢地增大,即每經(jīng)過(guò)一個(gè)往返時(shí)間 RTT 就把發(fā)送方的擁塞窗口 cwnd 加1,而不是像慢開(kāi)始階段那樣加倍增加。因此在擁塞避免階段就有“加法增大” AI(Additive Increase)的特點(diǎn)。這表明在擁塞避免階段,擁塞窗口 cwnd 按線性規(guī)律緩慢增長(zhǎng),比慢開(kāi)始算法的擁塞窗口增長(zhǎng)速率緩慢得多
“擁塞避免”并非完全能夠避免擁塞,而是把擁塞窗口控制為按線性規(guī)律增長(zhǎng),使網(wǎng)絡(luò)比較不容易出現(xiàn)擁塞
在執(zhí)行慢開(kāi)始算法時(shí),發(fā)送方每收到一個(gè)隊(duì)新報(bào)文段的確認(rèn) ACK,就把擁塞窗口值加1,然后開(kāi)始下一輪的傳輸。因此擁塞窗口 cwnd 隨著傳輸輪次按指數(shù)規(guī)律增長(zhǎng)。當(dāng)擁塞窗口 cwnd 增長(zhǎng)到慢開(kāi)始門(mén)限值 ssthresh 時(shí),就改成執(zhí)行擁塞避免算法,擁塞窗口按線性規(guī)律增長(zhǎng)
ssthresh:慢開(kāi)始門(mén)限,一般的,會(huì)有一個(gè)初始值,下圖中為16個(gè)報(bào)文段
當(dāng)擁塞窗口 cwnd = 24 時(shí),網(wǎng)絡(luò)出現(xiàn)了超時(shí),發(fā)送方判斷為網(wǎng)絡(luò)擁塞。于是調(diào)整門(mén)限值 ssthresh = cwnd / 2 = 12,同時(shí)設(shè)置擁塞窗口 cwnd = 1,進(jìn)入慢開(kāi)始階段
快重傳采用快重傳算法可以讓發(fā)送方盡早知道發(fā)生了個(gè)別報(bào)文段的丟失。快重傳算法首先要求接收方不要等待自己發(fā)送數(shù)據(jù)時(shí)才進(jìn)行捎帶確認(rèn),而是要立即發(fā)送確認(rèn),即使收到了失序的報(bào)文段也要立即發(fā)出對(duì)已收到的報(bào)文段的重復(fù)確認(rèn)
快恢復(fù)發(fā)送發(fā)知道當(dāng)前只是丟失了個(gè)別的報(bào)文段。于是不啟動(dòng)慢開(kāi)始,而是執(zhí)行快恢復(fù)算法。這時(shí),發(fā)送方調(diào)整門(mén)限值 ssthresh = cwnd / 2 = 8,同時(shí)設(shè)置擁塞窗口 cwnd = ssthresh = 8,并開(kāi)始執(zhí)行擁塞避免算法
TCP Reno 版本:區(qū)別于老的 TCP Tahao 版本
TCP 的運(yùn)輸連接管理TCP 是面向連接的協(xié)議。運(yùn)輸連接是用來(lái)傳送 TCP 報(bào)文的。TCP 運(yùn)輸連接的建立和釋放是每一次面向連接的通信中必不可少的過(guò)程。運(yùn)輸連接有三個(gè)階段,連接建立、數(shù)據(jù)傳送和連接釋放。運(yùn)輸?shù)倪B接管理就是使運(yùn)輸連接的建立和釋放都能夠正常地進(jìn)行
在 TCP 連接建立過(guò)程中要解決以下三個(gè)問(wèn)題:
要使每一方能夠確知對(duì)方的存在
要允許雙方協(xié)商一些參數(shù)(最大窗口值、是否使用窗口擴(kuò)大選項(xiàng)和時(shí)間戳選項(xiàng)以及服務(wù)質(zhì)量等)
能夠?qū)\(yùn)輸實(shí)體資源(緩存大小、連接表中的項(xiàng)目等)進(jìn)行分配
TCP 的連接建立TCP 建立連接的過(guò)程叫做握手,握手需要在客戶和服務(wù)器之間交換三個(gè) TCP 報(bào)文段
連接建立過(guò)程最初客戶/服務(wù)器的 TCP 進(jìn)程都處于 CLOSED(關(guān)閉)狀態(tài)。在本實(shí)例中,A 主動(dòng)打開(kāi)連接,而 B 被動(dòng)打開(kāi)連接
B 的 TCP 服務(wù)器進(jìn)程先創(chuàng)建傳輸控制塊 TCB,并處于 LISTEN(收聽(tīng)) 狀態(tài),等待客戶的連接請(qǐng)求
A 的 TCP 客戶進(jìn)程創(chuàng)建傳輸控制模塊 TCB。并向 B 發(fā)出連接請(qǐng)求報(bào)文段,首部中的同部位 SYN = 1,選擇一個(gè)初始序號(hào) seq = x。TCP 客戶端進(jìn)程進(jìn)入 SYN-SENT(同步已發(fā)送) 狀態(tài)。TCP 規(guī)定,SYN 報(bào)文段(即 SYN = 1 的報(bào)文段)不能攜帶數(shù)據(jù),但要消耗一個(gè)序號(hào)
B 收到連接請(qǐng)求報(bào)文段后,如同意建立連接,則向 A 發(fā)送確認(rèn)。在確認(rèn)報(bào)文段中應(yīng)把 SYN 位和 ACK 位都置1,確認(rèn)號(hào)是 ack = x + 1,同時(shí)也為自己選擇一個(gè)初始序號(hào) seq = y。這時(shí) TCP 服務(wù)器進(jìn)程進(jìn)入 SYN-RCVD(同步收到) 狀態(tài)。這個(gè)報(bào)文段也不能攜帶數(shù)據(jù),但同樣要消耗掉一個(gè)序號(hào)
TCP 客戶進(jìn)程收到 B 的確認(rèn)后,還要向 B 給出確認(rèn)。確認(rèn)報(bào)文段的 ACK 置1,確認(rèn)號(hào) ack = y + 1,而自己的序號(hào) seq = x + 1。TCP 的標(biāo)準(zhǔn)規(guī)定,ACK 報(bào)文段可以攜帶數(shù)據(jù)。但如果不攜帶數(shù)據(jù)則不消耗序號(hào),在這種情況下,下一個(gè)數(shù)據(jù)報(bào)文段的序號(hào)仍是 seq = x + 1。這時(shí),TCP 連接已經(jīng)建立,A 進(jìn)入 ESTABLISHED(已建立連接) 狀態(tài)
當(dāng) B 收到 A 的確認(rèn)后,也進(jìn)入 ESTABLISHED 狀態(tài)
傳輸控制塊 TCB(Transmission Control Block)存儲(chǔ)了每一個(gè)連接中的一些重要信息,如:TCP 連接表,指向發(fā)送和接收緩存的指針,指向重傳隊(duì)列的指針,當(dāng)前的發(fā)送和接收序號(hào)等等四報(bào)文握手
B 發(fā)送給 A 的報(bào)文段,可拆成兩個(gè)報(bào)文段。先發(fā)送一個(gè)確認(rèn)報(bào)文段(ACK = 1,ack = x + 1),然后再發(fā)送一個(gè)同步報(bào)文段(SYN = 1,seq = y)。這樣的過(guò)程就變成了四報(bào)文握手,與三報(bào)文握手效果一致
異常情況為什么 A 最后還要發(fā)送一次確認(rèn)呢?這主要是為了防止已失效的連接請(qǐng)求報(bào)文段突然又傳到了 B,因而產(chǎn)生錯(cuò)誤
正常情況:A 發(fā)出連接請(qǐng)求,但因連接請(qǐng)求報(bào)文丟失而未收到確認(rèn)。于是 A 再重傳一次連接請(qǐng)求。后來(lái)收到了確認(rèn),建立了連接。數(shù)據(jù)傳輸完畢后,就釋放了連接。A 共發(fā)送了兩個(gè)連接請(qǐng)求報(bào)文段,其中第一個(gè)丟失,第二個(gè)到達(dá)了 B,沒(méi)有“已失效的連接請(qǐng)求報(bào)文段”
異常情況:A 發(fā)出的第一個(gè)連接請(qǐng)求報(bào)文段并沒(méi)有丟失,而是在某些網(wǎng)絡(luò)結(jié)點(diǎn)長(zhǎng)時(shí)間滯留了,以致延誤到連接釋放以后的某個(gè)時(shí)間才到達(dá) B。本來(lái)這是一個(gè)早已失效的報(bào)文段。但 B 收到此失效的連接請(qǐng)求報(bào)文段后,就誤認(rèn)為是 A 又發(fā)出一次新的連接請(qǐng)求。于是就向 A 發(fā)出確認(rèn)報(bào)文段,同意建立連接。假定不采用報(bào)文握手,那么只要 B 發(fā)出確認(rèn),新的連接就建立了。
現(xiàn)在 A 并沒(méi)有發(fā)出建立連接的請(qǐng)求,因此不會(huì)理睬 B 的確認(rèn),也不會(huì)向 B 發(fā)送數(shù)據(jù)。但 B 卻以為新的運(yùn)輸連接已經(jīng)建立了,并一直等待 A 發(fā)來(lái)數(shù)據(jù)。B 的許多資源就這樣被浪費(fèi)了。TCP 的連接釋放 連接釋放過(guò)程采用三報(bào)文握手的辦法,可以防止上述現(xiàn)象的發(fā)生
A 的應(yīng)用進(jìn)程先向其 TCP 發(fā)出連接釋放報(bào)文段,并停止再發(fā)送數(shù)據(jù),主動(dòng)關(guān)閉 TCP 連接。A 把連接釋放報(bào)文段首部的終止控制位 FIN 置1,其序號(hào) seq = u,它等于前面已傳送過(guò)的數(shù)據(jù)的最后一個(gè)字節(jié)的序號(hào)加1。這時(shí) A 進(jìn)入 FIN-WAIT-1(終止等待1) 狀態(tài),等待 B 的確認(rèn)。TCP 規(guī)定,F(xiàn)IN 報(bào)文段即使不攜帶數(shù)據(jù),也消耗一個(gè)序號(hào)
B 收到連接釋放報(bào)文段后即發(fā)出確認(rèn),確認(rèn)號(hào)是 ack = u + 1,而這個(gè)報(bào)文段自己的序號(hào)是 v,等于 B 前面已傳送過(guò)的數(shù)據(jù)的最后一個(gè)字節(jié)的序號(hào)加1。B隨即進(jìn)入 CLOSE-WAIT(關(guān)閉等待) 狀態(tài)。TCP 服務(wù)器進(jìn)程這時(shí)應(yīng)通知高層應(yīng)用進(jìn)程,因而從 A 到 B 這個(gè)方向的連接就釋放了,這時(shí)的 TCP 連接處于 半關(guān)閉(half-close) 狀態(tài),即 A 已經(jīng)沒(méi)有數(shù)據(jù)要發(fā)送了,但 B 若發(fā)送數(shù)據(jù),A 仍要接收。也就是說(shuō),從 B 到 A 這個(gè)方向的連接并未關(guān)閉,這個(gè)狀態(tài)可能會(huì)持續(xù)一段時(shí)間
A 收到來(lái)自 B 的確認(rèn)后,就進(jìn)入 FIN-WAIT-2(終止等待2) 狀態(tài),等待 B 發(fā)出的連接釋放報(bào)文段
若 B 已經(jīng)沒(méi)有要向 A 發(fā)送的數(shù)據(jù),其應(yīng)用進(jìn)程就通知 TCP 釋放連接。這時(shí) B 發(fā)出的連接釋放報(bào)文段必須使 FIN = 1。現(xiàn)假定 B 的序號(hào)為 w(在半關(guān)閉狀態(tài) B 可能又發(fā)送了一些數(shù)據(jù))。B 還必須重復(fù)上次已發(fā)送過(guò)的確認(rèn)號(hào) ack = u + 1。這時(shí) B 就進(jìn)入 LAST-ACK(最后確認(rèn))狀態(tài),等待 A 的確認(rèn)
A 在收到 B 的連接釋放報(bào)文段后,必須對(duì)此發(fā)出確認(rèn)。在確認(rèn)報(bào)文段中把 ACK 置1,確認(rèn)號(hào) ack = w + 1,而自己的序號(hào)是 seq = u + 1(根據(jù) TCP 標(biāo)準(zhǔn),前面發(fā)送過(guò)的 FIN 報(bào)文段要消耗一個(gè)序號(hào))。然后進(jìn)入到 TIME-WAIT(時(shí)間等待)狀態(tài)。此時(shí) TCP 連接還沒(méi)有釋放掉。必須經(jīng)過(guò)時(shí)間等待計(jì)時(shí)器(TIME-WAIT timer)設(shè)置的時(shí)間2MSL后,A 才進(jìn)入到 CLOSED 狀態(tài)
當(dāng) A 撤銷(xiāo)相應(yīng)的傳輸控制塊 TCB 后,就結(jié)束了這次的 TCP 連接
時(shí)間 MSL 叫做最長(zhǎng)報(bào)文段壽命(Maximum Segment Lifetime),RFC 793建議設(shè)為2分鐘。但這完全是從工程上來(lái)考慮的,對(duì)于現(xiàn)在的網(wǎng)絡(luò),MSL = 2分鐘可能太長(zhǎng)了一些TIME-WAIT 等待時(shí)間
為什么 A 在 TIME-WAIT 狀態(tài)必須等待 2MSL 的時(shí)間呢?
為了保證 A 發(fā)送的最后一個(gè) ACK 報(bào)文段能夠到達(dá) B。這個(gè) ACK 報(bào)文段有可能丟失,因而使處在 LAST-ACK 狀態(tài)的 B 收不到對(duì)已發(fā)送的 FIN + ACK 報(bào)文段的確認(rèn)。B 會(huì)超時(shí) 重傳這個(gè) FIN + ACK 報(bào)文段,而 A 就能在 2MSL 時(shí)間內(nèi)收到這個(gè)重傳的 FIN + ACK 報(bào)文段。接著 A 重傳一次確認(rèn),重新啟動(dòng) 2MSL 計(jì)時(shí)器。最后,A 和 B 都正常進(jìn)入到 CLOSED 狀態(tài)。如果 A 在 TIME-WAIT 狀態(tài)不等待一段時(shí)間,而是在發(fā)完 ACK 報(bào)文段后立即釋放連接,那么就無(wú)法收到 B 重傳的 FIN + ACK 報(bào)文段,因而也不會(huì)再發(fā)送一次確認(rèn)報(bào)文段。這樣,B 就無(wú)法安裝正常步驟進(jìn)入 CLOSED 狀態(tài)
防止前面提到的“已失效的連接請(qǐng)求報(bào)文段”出現(xiàn)在本連接中。A 在發(fā)送完最后一個(gè) ACK 報(bào)文段后,再經(jīng)過(guò)時(shí)間 2MSL,就可以使本連接持續(xù)的時(shí)間內(nèi)所產(chǎn)生的所有報(bào)文段都從網(wǎng)絡(luò)中消失。這樣就可以使下一個(gè)新的連接中不會(huì)出現(xiàn)這種舊的連接請(qǐng)求報(bào)文段
B 只要收到 A 發(fā)出的確認(rèn),就進(jìn)入 CLOSED 狀態(tài)。同樣,B 在撤銷(xiāo)相應(yīng)的傳輸控制 TCB 后,就結(jié)束了這次的 TCP 連接。B 結(jié)束 TCP 連接的時(shí)間要比 A 早一些
?;钣?jì)時(shí)器(keepalive timer):服務(wù)器每收到一次客戶的數(shù)據(jù),就重新設(shè)置?;钣?jì)時(shí)器,時(shí)間的設(shè)置通常是兩小時(shí)。若兩小時(shí)沒(méi)有收到客戶的數(shù)據(jù),服務(wù)器就發(fā)送一個(gè)探測(cè)報(bào)文段,以后則每隔75秒發(fā)送一次。若一連發(fā)送10個(gè)探測(cè)報(bào)文段后仍無(wú)客戶的響應(yīng),服務(wù)器就認(rèn)為客戶端出了故障,接著就關(guān)閉這個(gè)連接
TCP 的有限狀態(tài)機(jī)為了更清晰地看出 TCP 連接的各種狀態(tài)之間的關(guān)系,下圖為 TCP 的有限狀態(tài)機(jī)。圖中每一個(gè)方框即 TCP 可能具有的狀態(tài)。每個(gè)方框中的大寫(xiě)英文字符串是 TCP 標(biāo)準(zhǔn)所使用的 TCP 連接狀態(tài)名。狀態(tài)之間的箭頭表示可能發(fā)生的狀態(tài)變遷。箭頭旁邊的字,表明引起這種變遷的原因,或表明發(fā)生狀態(tài)變遷后又出現(xiàn)什么動(dòng)作。請(qǐng)注意圖中有三種不同的箭頭。粗實(shí)線箭頭表示對(duì)客戶進(jìn)程的正常變遷。粗虛線箭頭表示對(duì)服務(wù)器進(jìn)程的正常變遷。另一種細(xì)線箭頭表示異常變遷
《TCP協(xié)議詳解》原文鏈接:https://blog.maplemark.cn/2019/04/tcp協(xié)議詳解.html?utm=sf
文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址:http://systransis.cn/yun/31362.html
摘要:協(xié)議地址解析協(xié)議,根據(jù)地址獲取地址。確認(rèn)表示確認(rèn)號(hào)字段有效,確認(rèn)號(hào)無(wú)效。終止表示發(fā)送數(shù)據(jù)已發(fā)送完畢,要求釋放連接。 TCP/IP協(xié)議蔟分為4層結(jié)構(gòu),分別是應(yīng)用層、傳輸層、網(wǎng)絡(luò)層和數(shù)據(jù)鏈路層,每一層都由特定的協(xié)議與對(duì)方進(jìn)行通信,在進(jìn)行數(shù)據(jù)通信時(shí),發(fā)送端的數(shù)據(jù)從應(yīng)用層往數(shù)據(jù)鏈路層方向流動(dòng),接收端的數(shù)據(jù)從數(shù)據(jù)鏈路層往應(yīng)用層流動(dòng)。 數(shù)據(jù)鏈路層 數(shù)據(jù)鏈路層的主要工作是對(duì)電信號(hào)進(jìn)行分組并形成具有特...
摘要:面向消息的簡(jiǎn)單文本協(xié)議。為提供了備選方案。但無(wú)論哪種場(chǎng)景,對(duì)于實(shí)際應(yīng)用來(lái)說(shuō),這種通信形式層級(jí)過(guò)低。協(xié)議,來(lái)為瀏覽器和間的通信增加適當(dāng)?shù)南⒄Z(yǔ)義。協(xié)議解決了瀏覽器發(fā)起請(qǐng)求以及服務(wù)器響應(yīng)請(qǐng)求的細(xì)節(jié),假設(shè)協(xié)議并不存在,只能使用套接字來(lái)編寫(xiě)應(yīng)用。 最近有項(xiàng)目需求要用到websocket,剛開(kāi)始以為很簡(jiǎn)單,但是隨著遇到問(wèn)題,深入了解,才知道websocket并不是想象中的那么簡(jiǎn)單,這篇文章主要是...
摘要:面向消息的簡(jiǎn)單文本協(xié)議。為提供了備選方案。但無(wú)論哪種場(chǎng)景,對(duì)于實(shí)際應(yīng)用來(lái)說(shuō),這種通信形式層級(jí)過(guò)低。協(xié)議,來(lái)為瀏覽器和間的通信增加適當(dāng)?shù)南⒄Z(yǔ)義。協(xié)議解決了瀏覽器發(fā)起請(qǐng)求以及服務(wù)器響應(yīng)請(qǐng)求的細(xì)節(jié),假設(shè)協(xié)議并不存在,只能使用套接字來(lái)編寫(xiě)應(yīng)用。 最近有項(xiàng)目需求要用到websocket,剛開(kāi)始以為很簡(jiǎn)單,但是隨著遇到問(wèn)題,深入了解,才知道websocket并不是想象中的那么簡(jiǎn)單,這篇文章主要是...
閱讀 1422·2021-10-11 11:12
閱讀 3256·2021-09-30 09:46
閱讀 1639·2021-07-28 00:14
閱讀 3142·2019-08-30 13:49
閱讀 2590·2019-08-29 11:27
閱讀 3243·2019-08-26 11:52
閱讀 608·2019-08-23 18:14
閱讀 3442·2019-08-23 16:27