①停止等待協(xié)議：

“停止等待”就是每發(fā)送完一個(gè)分組就停止發(fā)送，等待對(duì)方確認(rèn)。在收到確認(rèn)后再發(fā)送下一個(gè)分組。

• 無(wú)差錯(cuò)的情況下：一端發(fā)送，另一端等待并接收
• 出現(xiàn)差錯(cuò)的情況：一端在一段時(shí)間（會(huì)設(shè)置有超時(shí)計(jì)時(shí)器）一直沒(méi)有收到確認(rèn)，認(rèn)為自己剛發(fā)送的內(nèi)容丟失，于是重新發(fā)送，這就叫超時(shí)重傳。這里需要注意三點(diǎn)：第一，發(fā)送完自己的分組需暫時(shí)保留自己的副本，以防超時(shí)重傳；第二，分組和確認(rèn)分組要編號(hào)，從而確認(rèn)哪些分組收到確認(rèn)，哪些分組沒(méi)有收到確認(rèn)；第三，超時(shí)計(jì)時(shí)器設(shè)置的重傳時(shí)間應(yīng)當(dāng)比數(shù)據(jù)在分組傳輸?shù)钠骄禃r(shí)間長(zhǎng)一些。
• 確認(rèn)丟失和確認(rèn)遲到：??
• 信道利用率?

等值等待協(xié)議的信道利用情況如下圖：

?

為了提高效率，發(fā)送方可以不使用低效率的停止等待協(xié)議，使用流水線傳輸，流水線傳輸就是發(fā)送方可以連續(xù)發(fā)送多個(gè)分組，不必每發(fā)完一個(gè)分組就停下來(lái)等待對(duì)方的確認(rèn)。

②連續(xù)的ARQ協(xié)議

連續(xù)ARQ協(xié)議規(guī)定：發(fā)送方每收到一個(gè)確認(rèn)，就把發(fā)送窗口向前滑動(dòng)一個(gè)分組的位置。接收方采用累計(jì)確認(rèn)的方式，也就是說(shuō)：接收方不必對(duì)收到分組逐個(gè)發(fā)送確認(rèn)，而是在收到幾個(gè)分組之后，對(duì)按序到達(dá)的最后一個(gè)分組發(fā)送確認(rèn)。

（2）可靠傳輸?shù)膶?shí)現(xiàn)

①超時(shí)重傳時(shí)間的選擇

報(bào)文段的往返時(shí)間RTT：采用自適應(yīng)算法，記錄一個(gè)報(bào)文段發(fā)出的時(shí)間，以及收到相應(yīng)確認(rèn)的時(shí)間。這兩個(gè)時(shí)間之差就是RTT。

平滑的往返事件RTTs：RTT的一個(gè)加權(quán)平均往返時(shí)間

上式的α值在RFC 6298推薦為0.125 。

超時(shí)重傳時(shí)間RTO：報(bào)文每重傳一次，就把超時(shí)重傳時(shí)間RTO增大一些，取新的重傳時(shí)間為舊的重傳時(shí)間的2倍。當(dāng)不再發(fā)生報(bào)文段的重傳時(shí)，才根據(jù)下面的式子計(jì)算超時(shí)重傳時(shí)間。

②選擇確認(rèn)SACK

如果收到的報(bào)文沒(méi)有差錯(cuò)，但是未按序號(hào)，中間還缺少一些數(shù)據(jù)，使用選擇確認(rèn)可以只傳送缺少的數(shù)據(jù)而不重傳已經(jīng)確認(rèn)到達(dá)接收方的數(shù)據(jù)。

要使用選擇確認(rèn)，需在TCP首部的選項(xiàng)中加上“允許SACK”的選項(xiàng)，并且雙方必須事先商定好。

但是首部最長(zhǎng)40字節(jié)，如果要報(bào)告5個(gè)字節(jié)塊的邊界信息，那么5個(gè)邊界需要2*5*4=40個(gè)字節(jié)來(lái)表述，再加上一個(gè)字節(jié)指明SACK選項(xiàng)命令一個(gè)字節(jié)指明SACK占用多少字節(jié)，這就一共需要42字節(jié)，超出首部長(zhǎng)度。因此大多數(shù)的實(shí)現(xiàn)還是需要重傳全部的數(shù)據(jù)塊。

③流量控制

流量控制的目的：讓發(fā)送方的發(fā)送速率不要太快，從而讓接收方來(lái)的及接收

• 滑動(dòng)窗口：在 TCP 的報(bào)頭中有一個(gè)字段叫做接收通告窗口，這個(gè)字段由接收端填充，是接收端告訴發(fā)送端自己還有多少緩沖區(qū)可以接收數(shù)據(jù)。于是發(fā)送端就可以根據(jù)這個(gè)接收端的處理能力來(lái)發(fā)送數(shù)據(jù)，而不會(huì)導(dǎo)致接收端處理不過(guò)來(lái)。所以發(fā)送端就會(huì)有一個(gè)發(fā)送窗口，這個(gè)發(fā)送窗 口的大小是由接收端填充的接收通告窗口的大小決定的，并且窗口的位置會(huì)隨著發(fā)送端數(shù)據(jù) 的發(fā)送和接收到接收端對(duì)數(shù)據(jù)的確認(rèn)而不斷的向右滑動(dòng)，將之稱為滑動(dòng)窗口。（TCP的滑動(dòng)窗口以字節(jié)為單位）p3-p1=A的發(fā)送窗口；p2-p1=已發(fā)送但尚未收到確認(rèn)的字節(jié)數(shù)；p3-p2=允許發(fā)送但尚未發(fā)送的字節(jié)數(shù)。此外，需要注意的是，并不是發(fā)送方將數(shù)據(jù)直接發(fā)給接收方，而是發(fā)送方的應(yīng)用進(jìn)程把字節(jié)流寫(xiě)入TCP的發(fā)送緩存，發(fā)送緩存用來(lái)暫時(shí)存放發(fā)送應(yīng)用程序傳送給發(fā)送方TCP準(zhǔn)備發(fā)送的數(shù)據(jù)以及TCP已發(fā)送出但尚未收到確認(rèn)的數(shù)據(jù)。接收方的應(yīng)用進(jìn)程從TCP的接收緩存中讀取字節(jié)流，接收緩存用來(lái)暫時(shí)存放按序到達(dá)但尚未被接收應(yīng)用程序讀取的數(shù)據(jù)以及為按序到達(dá)的數(shù)據(jù)。最后在滑動(dòng)窗口的部分知識(shí)中需要注意三點(diǎn)：第一，同一時(shí)刻，發(fā)送方的發(fā)送端口并不總是和接收方的接收窗口一樣大，其會(huì)根據(jù)網(wǎng)絡(luò)擁塞情況適當(dāng)減少自己的窗口值；第二，不按序到達(dá)的數(shù)據(jù)，先臨時(shí)存放在接收緩存中，等到缺少的字節(jié)收到后，再按序交付給上層的應(yīng)用進(jìn)程；第三，TCP接收方要有累計(jì)確認(rèn)的功能。
• TCP的傳輸效率：TCP報(bào)文段的發(fā)送時(shí)機(jī)有三個(gè)控制機(jī)制：第一種，緩存中存放數(shù)據(jù)達(dá)到MSS（最大報(bào)文段長(zhǎng)度）字節(jié)時(shí)，就組裝成一個(gè)TCP報(bào)文段發(fā)送；第二種，發(fā)送方應(yīng)用進(jìn)程指明要求發(fā)送報(bào)文段；第三種，發(fā)送方的一個(gè)計(jì)時(shí)期限到了，就把當(dāng)前已有 緩存數(shù)據(jù)并且<=MSS裝入報(bào)文段發(fā)送出去。

④擁塞控制

• 滿開(kāi)始：由小到大逐漸增大擁塞窗口數(shù)值。
• 擁塞避免：為了防止擁塞窗口增長(zhǎng)過(guò)大引起網(wǎng)絡(luò)擁塞，設(shè)置慢開(kāi)始門(mén)限。然后擁塞避免的算法思路就是讓擁塞窗口緩慢增大，即每經(jīng)過(guò)一個(gè)往返時(shí)間RTT就把發(fā)送方的擁塞窗口加一。
• 快速重傳：接收方不要等待中積極發(fā)送數(shù)據(jù)的時(shí)候再進(jìn)行對(duì)之前數(shù)據(jù)的捎帶確認(rèn)，而是收到數(shù)據(jù)立即發(fā)送確認(rèn)?？熘貍魉惴ㄒ?guī)定：發(fā)送方一連收到三個(gè)重復(fù)的確認(rèn)，就應(yīng)當(dāng)進(jìn)行快重傳。
• 快速恢復(fù)：當(dāng)出現(xiàn)超時(shí)的時(shí)候，不啟動(dòng)慢開(kāi)始，而是執(zhí)行快恢復(fù)算法。發(fā)送方調(diào)整門(mén)限值=出現(xiàn)超時(shí)的cwnd(擁塞窗口)/2。

?

1.1.4TCP提供全雙工通信

1.1.5面向字節(jié)流

流式服務(wù)的特點(diǎn)：TCP 字節(jié)流的特點(diǎn)，發(fā)送端執(zhí)行的寫(xiě)操作次數(shù)和接收端執(zhí)行的讀操作次數(shù)之間沒(méi)有任何數(shù)量關(guān)系，應(yīng)用程序?qū)?shù)據(jù)的發(fā)送和接收是沒(méi)有邊界限制的。

1.2與TCP有關(guān)的面試問(wèn)題

（1）為什么時(shí)三次握手，可不可以是兩次握手，為什么？

如果是兩次握手，那么如果出現(xiàn)這種情況：發(fā)送端發(fā)送請(qǐng)求連接報(bào)文，但是由于在網(wǎng)絡(luò)中出現(xiàn)了滯留并沒(méi)有按時(shí)到達(dá)接收端，等到一段時(shí)間發(fā)送端再次發(fā)送連接請(qǐng)求報(bào)文，接收端接收之后并發(fā)送確認(rèn)連接。這樣兩次握手建立連接1。但是之前在網(wǎng)絡(luò)中滯留的連接請(qǐng)求報(bào)文并沒(méi)有丟失，于是發(fā)送給接收端，接收端誤以為建立連接，于是就回復(fù)確認(rèn)建立連接，所以此時(shí)又建立了連接2，但是發(fā)送端并不會(huì)給連接2發(fā)送數(shù)據(jù)，所以接收端一直處于等待，就會(huì)浪費(fèi)接受端許多資源。

三次握手也可以是四次握手：接收端在回復(fù)確認(rèn)建立連接報(bào)文的時(shí)候，將其分成兩個(gè)報(bào)文段，一個(gè)是回復(fù)對(duì)發(fā)送端的連接確認(rèn)，一個(gè)是發(fā)送自己的同步報(bào)文段。

（2）三次握手時(shí)可能出現(xiàn)什么攻擊？

可以參考下面這篇文章：

TCP三次握手有哪些漏洞？https://www.cnblogs.com/HuiH/p/12599048.html可能出現(xiàn)的攻擊有三種：SYN flood的攻擊，TCP全連接攻擊，Land攻擊。

（3）四次揮手的過(guò)程可以用三次完成嗎？

關(guān)閉連接時(shí)，服務(wù)器端收到FIN報(bào)文，并不會(huì)立刻關(guān)閉SOCKET,先回復(fù)ACK報(bào)文，等到服務(wù)器端的所有報(bào)文都發(fā)送完了，才發(fā)送FIN報(bào)文。所以不能三次完成，將ACK和FIN不能放在一起發(fā)送。

（4）對(duì)于三次握手四次揮手的面試題，可以看看這個(gè)文章

面試官，不要再問(wèn)我三次握手和四次揮手https://zhuanlan.zhihu.com/p/86426969

（5）同一個(gè)端口可不可以被一個(gè) TCP 和一個(gè) UDP 的應(yīng)用程序同時(shí)使用？

可以。原因是端口的唯一性標(biāo)識(shí)是：端口號(hào)+協(xié)議名稱。所以TCP和UDP的端口完全沒(méi)有任何關(guān)系，協(xié)議內(nèi)部端口號(hào)唯一。

追問(wèn)：程序在連接到端口時(shí)，怎么知道此時(shí)從該端口進(jìn)來(lái)的數(shù)據(jù)是tcp的還是udp的呢？

操作系統(tǒng)根據(jù)接收的IP數(shù)據(jù)包的首部?jī)?nèi)的8位協(xié)議來(lái)判斷這是什么報(bào)文，從而直接交給相關(guān)的內(nèi)核進(jìn)程或者協(xié)議棧處理。

追問(wèn)：一個(gè)端口是否可以綁定多個(gè)端口號(hào)？

可以。一個(gè)進(jìn)程可以打開(kāi)多個(gè)文件描述符，每個(gè)文件描述符對(duì)應(yīng)一個(gè)端口號(hào)，所以一個(gè)進(jìn)程可以綁定多個(gè)端口號(hào)。Linux會(huì)給每個(gè)socket分配一個(gè)唯一的文件描述符，通過(guò)這個(gè)文件描述符來(lái)區(qū)分對(duì)應(yīng)的套接字。

追問(wèn)：一個(gè)端口號(hào)是否可以被多個(gè)進(jìn)程綁定？

不可以。但是在父子進(jìn)程中可以實(shí)現(xiàn)多進(jìn)程綁定一個(gè)端口號(hào)，因?yàn)樽舆M(jìn)程具有父進(jìn)程的文件描述符副本，可以處理綁定到同樣的端口上的連接

追問(wèn)：一個(gè)端口可以同時(shí)連接多個(gè)TCP和多個(gè)UDP嗎？

一個(gè)端口可以建立多個(gè)TCP連接，所謂的同一個(gè)端口是指服務(wù)器端的ip和port不變，但是只要客戶端的ip和port不同就可以。一個(gè)端口同一時(shí)間只能綁定一個(gè)socket。UDP是面向無(wú)連接的，所以不存在多個(gè)UDP連接，只是服務(wù)端接收UDP數(shù)據(jù)需要綁定一個(gè)端口，一個(gè)socket只能綁定一個(gè)端口而已。

（如果還不是很清楚這方面的問(wèn)題，可以參考下面幾篇文章）

TCP和UDP使用同一端口通信https://blog.csdn.net/szm1234/article/details/116994450一個(gè)端口號(hào)可以同時(shí)被兩個(gè)進(jìn)程綁定嗎？https://zhuanlan.zhihu.com/p/280672302#:~:text= 由上述結(jié)果可知：TCP、UDP可以同時(shí)綁定一個(gè)端口8888，但是一個(gè)端口在同一時(shí)刻不可以被TCP或者UDP綁定2次。,原因如下： TCP和UDP傳輸協(xié)議監(jiān)聽(tīng)同一個(gè)端口后，接收數(shù)據(jù)互不影響，不沖突。快狗二面 一個(gè)端口可以 同時(shí)TCP 又UDP 嗎？https://cloud.tencent.com/developer/article/1813256

（6）同一個(gè)應(yīng)用程序可以創(chuàng)建多個(gè)套接字嗎？

端口是唯一的，系統(tǒng)中任一個(gè)端口只能被一個(gè)程序占用。一個(gè)程序可以創(chuàng)建多個(gè)Socket，但多個(gè)Socket是不能共用端口的。

（7）什么是 TCP 粘包，如何解決？

定義：指的是多個(gè)報(bào)文數(shù)據(jù)內(nèi)容融合在一起被接受

解決方案：

①循環(huán)接收、發(fā)送；即就是一次send,一次recv……

②設(shè)置分割標(biāo)志。

③在頭部加上長(zhǎng)度控制，然后讀取的時(shí)候只讀取頭部信息中指定的長(zhǎng)度。

（8）為什么UDP數(shù)據(jù)包不發(fā)生粘包，而TCP會(huì)出現(xiàn)粘包？

TCP協(xié)議是面向鏈接的，收發(fā)兩端都必須要有成對(duì)的socket,因此發(fā)送端為了將多個(gè)發(fā)往接收端的包更有效的發(fā)送，使用了優(yōu)化的方法nagle算法。

面向流的服務(wù)是沒(méi)有消息保護(hù)邊界的。

UDP協(xié)議是無(wú)連接，面向消息的，支持一對(duì)多的模式，所以接收端的套接字緩沖區(qū)采用鏈?zhǔn)浇Y(jié)構(gòu)記錄每一個(gè)到達(dá)的UDP包。

面向消息的通信是由消息保護(hù)邊界的。

（9）如果接收端填充的接收通告窗口為 0，發(fā)送端接下來(lái)怎么處理？

接收端通告的窗口大小變成0，發(fā)送端會(huì)發(fā)一個(gè)1字節(jié)的段，這一個(gè)字節(jié)段可以是下一字節(jié)的數(shù)據(jù)，如果沒(méi)有新的數(shù)據(jù)段發(fā)送的時(shí)候，就發(fā)一個(gè)ack，強(qiáng)制接收端重新宣告下一個(gè)期望的字節(jié)和窗口大小。如果接收方回復(fù)窗口大小仍然為零，則發(fā)送方的探測(cè)定時(shí)器加倍。沒(méi)有收到ACK時(shí)，發(fā)送探測(cè)包的最大次數(shù)之后連接超時(shí)。

（10）什么叫糊涂窗口綜合征？

糊涂窗口綜合癥是指當(dāng)發(fā)送端應(yīng)用進(jìn)程產(chǎn)生數(shù)據(jù)很慢、或接收端應(yīng)用進(jìn)程處理接收緩沖區(qū)數(shù)據(jù)很慢，或二者兼而有之；就會(huì)使應(yīng)用進(jìn)程間傳送的報(bào)文段很小，特別是有效載荷很小； 極端情況下，有效載荷可能只有1個(gè)字節(jié)；傳輸開(kāi)銷(xiāo)有40字節(jié)(20字節(jié)的IP頭+20字節(jié)的TCP頭) 這種現(xiàn)象。

要解決這個(gè)問(wèn)題，發(fā)送方要把數(shù)據(jù)累計(jì)成足夠大的報(bào)文段，等到其到達(dá)接收方緩存區(qū)的一半大小，再發(fā)送報(bào)文。接收方等待一段時(shí)間，使得自己的接收緩存區(qū)中能夠容納一個(gè)最長(zhǎng)的報(bào)文段或緩存區(qū)有一半空閑，然后再去發(fā)送確認(rèn)報(bào)文。

（11）在 TCP 的實(shí)現(xiàn)中廣泛使用的 Nagle 算法是什么？

若發(fā)送應(yīng)用進(jìn)程，把要發(fā)送的數(shù)據(jù)逐個(gè)字節(jié)的送到TCP的發(fā)送緩存，則發(fā)送方就把第一個(gè)數(shù)據(jù)字節(jié)先發(fā)送出去，把后面的數(shù)據(jù)字節(jié)都緩存起來(lái)。當(dāng)發(fā)送方收到對(duì)第一個(gè)數(shù)據(jù)字符的確認(rèn)后，再把發(fā)送緩存中的所有數(shù)據(jù)組裝成一個(gè)發(fā)送報(bào)文段發(fā)送出去。

（12）TIME_WAIT 狀態(tài)存在的原因？

①保證發(fā)送端發(fā)送的最后一個(gè)ACK報(bào)文段能夠到達(dá)接收端，從而避免接收端因?yàn)槭詹坏紸CK報(bào)文段而不按照正常步驟進(jìn)入CLOSED狀態(tài)。

②使本鏈接持續(xù)的時(shí)間內(nèi)所產(chǎn)生的所有報(bào)文都從網(wǎng)絡(luò)中消失，避免下一個(gè)新連接中出現(xiàn)舊的連接請(qǐng)求報(bào)文段。

2.用戶數(shù)據(jù)報(bào)協(xié)議UDP

2.1UDP協(xié)議的主要特點(diǎn)：

（1）UDP是無(wú)連接的，可以減少開(kāi)銷(xiāo)和發(fā)送數(shù)據(jù)之前的時(shí)延。

（2）UDP使用盡最大努力交付，不保證可靠交付，主機(jī)不需要維持復(fù)雜的連接狀態(tài)表。

（3）UDP是面向報(bào)文的，一次交付一個(gè)完整的報(bào)文。

（4）UDP沒(méi)有擁塞控制，因此網(wǎng)絡(luò)出現(xiàn)的擁塞不會(huì)使得源主機(jī)的發(fā)送速率降低。

（5）UDP支持一對(duì)一、一對(duì)多、多對(duì)一、多對(duì)多的交互通信。

（6）UDP的首部開(kāi)銷(xiāo)小，只有八字節(jié)。

?

?

?

總結(jié)

以上是生活随笔為你收集整理的TCP协议和UDP协议的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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