本文已經(jīng)收錄到Github倉庫，該倉庫包含計(jì)算機(jī)基礎(chǔ)、Java基礎(chǔ)、多線程、JVM、數(shù)據(jù)庫、Redis、Spring、Mybatis、SpringMVC、SpringBoot、分布式、微服務(wù)、設(shè)計(jì)模式、架構(gòu)、校招社招分享等核心知識點(diǎn)，歡迎star~

Github地址：https://github.com/Tyson0314/Java-learning

---

為什么需要TCP協(xié)議？

IP 層是「不可靠」的,它不保證網(wǎng)絡(luò)包的交付、不保證網(wǎng)絡(luò)包的按序交付、也不保證網(wǎng)絡(luò)包中的數(shù)據(jù)的完整性。

因?yàn)?TCP 是一個工作在傳輸層的可靠數(shù)據(jù)傳輸?shù)姆?wù),它能確保接收端接收的網(wǎng)絡(luò)包是無損壞、無間隔、非冗余和按序的。

說說TCP的三次握手

假設(shè)發(fā)送端為客戶端，接收端為服務(wù)端。開始時客戶端和服務(wù)端的狀態(tài)都是CLOSED。

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來直接上傳(img-cVTX1UdG-1679012833490)(http://img.topjavaer.cn/img/三次握手圖解.png)]

1. 第一次握手：客戶端向服務(wù)端發(fā)起建立連接請求，客戶端會隨機(jī)生成一個起始序列號x，客戶端向服務(wù)端發(fā)送的字段中包含標(biāo)志位SYN=1，序列號seq=x。第一次握手前客戶端的狀態(tài)為CLOSE，第一次握手后客戶端的狀態(tài)為SYN-SENT。此時服務(wù)端的狀態(tài)為LISTEN。
2. 第二次握手：服務(wù)端在收到客戶端發(fā)來的報文后，會隨機(jī)生成一個服務(wù)端的起始序列號y，然后給客戶端回復(fù)一段報文，其中包括標(biāo)志位SYN=1，ACK=1，序列號seq=y，確認(rèn)號ack=x+1。第二次握手前服務(wù)端的狀態(tài)為LISTEN，第二次握手后服務(wù)端的狀態(tài)為SYN-RCVD，此時客戶端的狀態(tài)為SYN-SENT。（其中SYN=1表示要和客戶端建立一個連接，ACK=1表示確認(rèn)序號有效）
3. 第三次握手：客戶端收到服務(wù)端發(fā)來的報文后，會再向服務(wù)端發(fā)送報文，其中包含標(biāo)志位ACK=1，序列號seq=x+1，確認(rèn)號ack=y+1。第三次握手前客戶端的狀態(tài)為SYN-SENT，第三次握手后客戶端和服務(wù)端的狀態(tài)都為ESTABLISHED。此時連接建立完成。

兩次握手可以嗎？

之所以需要第三次握手，主要為了防止已失效的連接請求報文段突然又傳輸?shù)搅朔?wù)端，導(dǎo)致產(chǎn)生問題。

• 比如客戶端A發(fā)出連接請求，可能因?yàn)榫W(wǎng)絡(luò)阻塞原因，A沒有收到確認(rèn)報文，于是A再重傳一次連接請求。
• 然后連接成功，等待數(shù)據(jù)傳輸完畢后，就釋放了連接。
• 然后A發(fā)出的第一個連接請求等到連接釋放以后的某個時間才到達(dá)服務(wù)端B，此時B誤認(rèn)為A又發(fā)出一次新的連接請求，于是就向A發(fā)出確認(rèn)報文段。
• 如果不采用三次握手，只要B發(fā)出確認(rèn)，就建立新的連接了，此時A不會響應(yīng)B的確認(rèn)且不發(fā)送數(shù)據(jù)，則B一直等待A發(fā)送數(shù)據(jù)，浪費(fèi)資源。

說說TCP的四次揮手

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來直接上傳(img-2znDWa1p-1679012833492)(http://img.topjavaer.cn/img/四次揮手0.png)]

1. A的應(yīng)用進(jìn)程先向其TCP發(fā)出連接釋放報文段（FIN=1，seq=u），并停止再發(fā)送數(shù)據(jù)，主動關(guān)閉TCP連接，進(jìn)入FIN-WAIT-1（終止等待1）狀態(tài)，等待B的確認(rèn)。
2. B收到連接釋放報文段后即發(fā)出確認(rèn)報文段（ACK=1，ack=u+1，seq=v），B進(jìn)入CLOSE-WAIT（關(guān)閉等待）狀態(tài)，此時的TCP處于半關(guān)閉狀態(tài)，A到B的連接釋放。
3. A收到B的確認(rèn)后，進(jìn)入FIN-WAIT-2（終止等待2）狀態(tài)，等待B發(fā)出的連接釋放報文段。
4. B發(fā)送完數(shù)據(jù)，就會發(fā)出連接釋放報文段（FIN=1，ACK=1，seq=w，ack=u+1），B進(jìn)入LAST-ACK（最后確認(rèn)）狀態(tài)，等待A的確認(rèn)。
5. A收到B的連接釋放報文段后，對此發(fā)出確認(rèn)報文段（ACK=1，seq=u+1，ack=w+1），A進(jìn)入TIME-WAIT（時間等待）狀態(tài)。此時TCP未釋放掉，需要經(jīng)過時間等待計(jì)時器設(shè)置的時間2MSL（最大報文段生存時間）后，A才進(jìn)入CLOSED狀態(tài)。B收到A發(fā)出的確認(rèn)報文段后關(guān)閉連接，若沒收到A發(fā)出的確認(rèn)報文段，B就會重傳連接釋放報文段。

第四次揮手為什么要等待2MSL？

• 保證A發(fā)送的最后一個ACK報文段能夠到達(dá)B。這個ACK報文段有可能丟失，B收不到這個確認(rèn)報文，就會超時重傳連接釋放報文段，然后A可以在2MSL時間內(nèi)收到這個重傳的連接釋放報文段，接著A重傳一次確認(rèn)，重新啟動2MSL計(jì)時器，最后A和B都進(jìn)入到CLOSED狀態(tài)，若A在TIME-WAIT狀態(tài)不等待一段時間，而是發(fā)送完ACK報文段后立即釋放連接，則無法收到B重傳的連接釋放報文段，所以不會再發(fā)送一次確認(rèn)報文段，B就無法正常進(jìn)入到CLOSED狀態(tài)。
• 防止已失效的連接請求報文段出現(xiàn)在本連接中。A在發(fā)送完最后一個ACK報文段后，再經(jīng)過2MSL，就可以使這個連接所產(chǎn)生的所有報文段都從網(wǎng)絡(luò)中消失，使下一個新的連接中不會出現(xiàn)舊的連接請求報文段。

為什么是四次揮手？

因?yàn)楫?dāng)Server端收到Client端的SYN連接請求報文后，可以直接發(fā)送SYN+ACK報文。但是在關(guān)閉連接時，當(dāng)Server端收到Client端發(fā)出的連接釋放報文時，很可能并不會立即關(guān)閉SOCKET，所以Server端先回復(fù)一個ACK報文，告訴Client端我收到你的連接釋放報文了。只有等到Server端所有的報文都發(fā)送完了，這時Server端才能發(fā)送連接釋放報文，之后兩邊才會真正的斷開連接。故需要四次揮手。

說說TCP報文首部有哪些字段，其作用又分別是什么？

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來直接上傳(img-q1uZP6I9-1679012833493)(http://img.topjavaer.cn/img/tcp報文.png)]

• 16位端口號：源端口號，主機(jī)該報文段是來自哪里；目標(biāo)端口號，要傳給哪個上層協(xié)議或應(yīng)用程序
• 32位序號：一次TCP通信（從TCP連接建立到斷開）過程中某一個傳輸方向上的字節(jié)流的每個字節(jié)的編號。
• 32位確認(rèn)號：用作對另一方發(fā)送的tcp報文段的響應(yīng)。其值是收到的TCP報文段的序號值加1。
• 4位頭部長度：表示tcp頭部有多少個32bit字（4字節(jié)）。因?yàn)?位最大能標(biāo)識15，所以TCP頭部最長是60字節(jié)。
• 6位標(biāo)志位：URG(緊急指針是否有效)，ACk（表示確認(rèn)號是否有效），PSH（緩沖區(qū)尚未填滿），RST（表示要求對方重新建立連接），SYN（建立連接消息標(biāo)志接），FIN（表示告知對方本端要關(guān)閉連接了）
• 16位窗口大小：是TCP流量控制的一個手段。這里說的窗口，指的是接收通告窗口。它告訴對方本端的TCP接收緩沖區(qū)還能容納多少字節(jié)的數(shù)據(jù)，這樣對方就可以控制發(fā)送數(shù)據(jù)的速度。
• 16位校驗(yàn)和：由發(fā)送端填充，接收端對TCP報文段執(zhí)行CRC算法以檢驗(yàn)TCP報文段在傳輸過程中是否損壞。注意，這個校驗(yàn)不僅包括TCP頭部，也包括數(shù)據(jù)部分。這也是TCP可靠傳輸?shù)囊粋€重要保障。
• 16位緊急指針：一個正的偏移量。它和序號字段的值相加表示最后一個緊急數(shù)據(jù)的下一字節(jié)的序號。因此，確切地說，這個字段是緊急指針相對當(dāng)前序號的偏移，不妨稱之為緊急偏移。TCP的緊急指針是發(fā)送端向接收端發(fā)送緊急數(shù)據(jù)的方法。

TCP有哪些特點(diǎn)？

• TCP是面向連接的運(yùn)輸層協(xié)議。
• 點(diǎn)對點(diǎn)，每一條TCP連接只能有兩個端點(diǎn)。
• TCP提供可靠交付的服務(wù)。
• TCP提供全雙工通信。
• 面向字節(jié)流。

TCP和UDP的區(qū)別？

1. TCP面向連接；UDP是無連接的，即發(fā)送數(shù)據(jù)之前不需要建立連接。
2. TCP提供可靠的服務(wù)；UDP不保證可靠交付。
3. TCP面向字節(jié)流，把數(shù)據(jù)看成一連串無結(jié)構(gòu)的字節(jié)流；UDP是面向報文的。
4. TCP有擁塞控制；UDP沒有擁塞控制，因此網(wǎng)絡(luò)出現(xiàn)擁塞不會使源主機(jī)的發(fā)送速率降低（對實(shí)時應(yīng)用很有用，如實(shí)時視頻會議等）。
5. 每一條TCP連接只能是點(diǎn)到點(diǎn)的；UDP支持一對一、一對多、多對一和多對多的通信方式。
6. TCP首部開銷20字節(jié)；UDP的首部開銷小，只有8個字節(jié)。

TCP 和 UDP 分別對應(yīng)的常見應(yīng)用層協(xié)議有哪些？

基于TCP的應(yīng)用層協(xié)議有：HTTP、FTP、SMTP、TELNET、SSH

• HTTP：HyperText Transfer Protocol（超文本傳輸協(xié)議），默認(rèn)端口80
• FTP: File Transfer Protocol (文件傳輸協(xié)議), 默認(rèn)端口(20用于傳輸數(shù)據(jù)，21用于傳輸控制信息)
• SMTP: Simple Mail Transfer Protocol (簡單郵件傳輸協(xié)議) ,默認(rèn)端口25
• TELNET: Teletype over the Network (網(wǎng)絡(luò)電傳), 默認(rèn)端口23
• SSH：Secure Shell（安全外殼協(xié)議），默認(rèn)端口 22

基于UDP的應(yīng)用層協(xié)議：DNS、TFTP、SNMP

• DNS : Domain Name Service (域名服務(wù)),默認(rèn)端口 53
• TFTP: Trivial File Transfer Protocol (簡單文件傳輸協(xié)議)，默認(rèn)端口69
• SNMP：Simple Network Management Protocol（簡單網(wǎng)絡(luò)管理協(xié)議），通過UDP端口161接收，只有Trap信息采用UDP端口162。

TCP的粘包和拆包

TCP是面向流，沒有界限的一串?dāng)?shù)據(jù)。TCP底層并不了解上層業(yè)務(wù)數(shù)據(jù)的具體含義，它會根據(jù)TCP緩沖區(qū)的實(shí)際情況進(jìn)行包的劃分，所以在業(yè)務(wù)上認(rèn)為，一個完整的包可能會被TCP拆分成多個包進(jìn)行發(fā)送，也有可能把多個小的包封裝成一個大的數(shù)據(jù)包發(fā)送，這就是所謂的TCP粘包和拆包問題。

為什么會產(chǎn)生粘包和拆包呢?

• 要發(fā)送的數(shù)據(jù)小于TCP發(fā)送緩沖區(qū)的大小，TCP將多次寫入緩沖區(qū)的數(shù)據(jù)一次發(fā)送出去，將會發(fā)生粘包；
• 接收數(shù)據(jù)端的應(yīng)用層沒有及時讀取接收緩沖區(qū)中的數(shù)據(jù)，將發(fā)生粘包；
• 要發(fā)送的數(shù)據(jù)大于TCP發(fā)送緩沖區(qū)剩余空間大小，將會發(fā)生拆包；
• 待發(fā)送數(shù)據(jù)大于MSS（最大報文長度），TCP在傳輸前將進(jìn)行拆包。即TCP報文長度-TCP頭部長度>MSS。

解決方案：

• 發(fā)送端將每個數(shù)據(jù)包封裝為固定長度
• 在數(shù)據(jù)尾部增加特殊字符進(jìn)行分割
• 將數(shù)據(jù)分為兩部分，一部分是頭部，一部分是內(nèi)容體；其中頭部結(jié)構(gòu)大小固定，且有一個字段聲明內(nèi)容體的大小。

說說TCP是如何確?？煽啃缘哪?#xff1f;

• 首先，TCP的連接是基于三次握手，而斷開則是基于四次揮手。確保連接和斷開的可靠性。
• 其次，TCP的可靠性，還體現(xiàn)在有狀態(tài);TCP會記錄哪些數(shù)據(jù)發(fā)送了，哪些數(shù)據(jù)被接收了，哪些沒有被接受，并且保證數(shù)據(jù)包按序到達(dá)，保證數(shù)據(jù)傳輸不出差錯。
• 再次，TCP的可靠性，還體現(xiàn)在可控制。它有數(shù)據(jù)包校驗(yàn)、ACK應(yīng)答、超時重傳(發(fā)送方)、失序數(shù)據(jù)重傳（接收方）、丟棄重復(fù)數(shù)據(jù)、流量控制（滑動窗口）和擁塞控制等機(jī)制。

說下TCP的滑動窗口機(jī)制

TCP 利用滑動窗口實(shí)現(xiàn)流量控制。流量控制是為了控制發(fā)送方發(fā)送速率，保證接收方來得及接收。 TCP會話的雙方都各自維護(hù)一個發(fā)送窗口和一個接收窗口。接收窗口大小取決于應(yīng)用、系統(tǒng)、硬件的限制。發(fā)送窗口則取決于對端通告的接收窗口。接收方發(fā)送的確認(rèn)報文中的window字段可以用來控制發(fā)送方窗口大小，從而影響發(fā)送方的發(fā)送速率。將接收方的確認(rèn)報文window字段設(shè)置為 0，則發(fā)送方不能發(fā)送數(shù)據(jù)。

TCP頭包含window字段，16bit位，它代表的是窗口的字節(jié)容量，最大為65535。這個字段是接收端告訴發(fā)送端自己還有多少緩沖區(qū)可以接收數(shù)據(jù)。于是發(fā)送端就可以根據(jù)這個接收端的處理能力來發(fā)送數(shù)據(jù)，而不會導(dǎo)致接收端處理不過來。接收窗口的大小是約等于發(fā)送窗口的大小。

詳細(xì)講一下?lián)砣刂?#xff1f;

防止過多的數(shù)據(jù)注入到網(wǎng)絡(luò)中。 幾種擁塞控制方法：慢開始( slow-start )、擁塞避免( congestion avoidance )、快重傳( fast retransmit )和快恢復(fù)( fast recovery )。

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來直接上傳(img-KsKniVg2-1679012833497)(http://img.topjavaer.cn/img/擁塞控制.jpg)]

慢開始

把擁塞窗口 cwnd 設(shè)置為一個最大報文段MSS的數(shù)值。而在每收到一個對新的報文段的確認(rèn)后，把擁塞窗口增加至多一個MSS的數(shù)值。每經(jīng)過一個傳輸輪次，擁塞窗口 cwnd 就加倍。 為了防止擁塞窗口cwnd增長過大引起網(wǎng)絡(luò)擁塞，還需要設(shè)置一個慢開始門限ssthresh狀態(tài)變量。

當(dāng) cwnd < ssthresh 時，使用慢開始算法。

當(dāng) cwnd > ssthresh 時，停止使用慢開始算法而改用擁塞避免算法。

當(dāng) cwnd = ssthresh 時，既可使用慢開始算法，也可使用擁塞控制避免算法。

擁塞避免

讓擁塞窗口cwnd緩慢地增大，每經(jīng)過一個往返時間RTT就把發(fā)送方的擁塞窗口cwnd加1，而不是加倍。這樣擁塞窗口cwnd按線性規(guī)律緩慢增長。

無論在慢開始階段還是在擁塞避免階段，只要發(fā)送方判斷網(wǎng)絡(luò)出現(xiàn)擁塞（其根據(jù)就是沒有收到確認(rèn)），就要把慢開始門限ssthresh設(shè)置為出現(xiàn)擁塞時的發(fā)送 方窗口值的一半（但不能小于2）。然后把擁塞窗口cwnd重新設(shè)置為1，執(zhí)行慢開始算法。這樣做的目的就是要迅速減少主機(jī)發(fā)送到網(wǎng)絡(luò)中的分組數(shù)，使得發(fā)生 擁塞的路由器有足夠時間把隊(duì)列中積壓的分組處理完畢。

快重傳

有時個別報文段會在網(wǎng)絡(luò)中丟失，但實(shí)際上網(wǎng)絡(luò)并未發(fā)生擁塞。如果發(fā)送方遲遲收不到確認(rèn)，就會產(chǎn)生超時，就會誤認(rèn)為網(wǎng)絡(luò)發(fā)生了擁塞。這就導(dǎo)致發(fā)送方錯誤地啟動慢開始，把擁塞窗口cwnd又設(shè)置為1，因而降低了傳輸效率。

快重傳算法可以避免這個問題?？熘貍魉惴ㄊ紫纫蠼邮辗矫渴盏揭粋€失序的報文段后就立即發(fā)出重復(fù)確認(rèn)，使發(fā)送方及早知道有報文段沒有到達(dá)對方。

發(fā)送方只要一連收到三個重復(fù)確認(rèn)就應(yīng)當(dāng)立即重傳對方尚未收到的報文段，而不必繼續(xù)等待重傳計(jì)時器到期。由于發(fā)送方盡早重傳未被確認(rèn)的報文段，因此采用快重傳后可以使整個網(wǎng)絡(luò)吞吐量提高約20%。

快恢復(fù)

當(dāng)發(fā)送方連續(xù)收到三個重復(fù)確認(rèn)，就會把慢開始門限ssthresh減半，接著把cwnd值設(shè)置為慢開始門限ssthresh減半后的數(shù)值，然后開始執(zhí)行擁塞避免算法，使擁塞窗口緩慢地線性增大。

在采用快恢復(fù)算法時，慢開始算法只是在TCP連接建立時和網(wǎng)絡(luò)出現(xiàn)超時時才使用。 采用這樣的擁塞控制方法使得TCP的性能有明顯的改進(jìn)。

什么是 SYN 攻擊?

我們都知道 TCP 連接建立是需要三次握手,假設(shè)攻擊者短時間偽造不同 IP 地址的 SYN 報文,服務(wù)端每接收到 一個 SYN 報文,就進(jìn)入 SYN_RCVD 狀態(tài),但服務(wù)端發(fā)送出去的 ACK + SYN 報文,無法得到未知 IP 主機(jī)的ACK 應(yīng)答,久而久之就會占滿服務(wù)端的 SYN 接收隊(duì)列(未連接隊(duì)列),使得服務(wù)器不能為正常用戶服務(wù)。

如何唯一確定一個TCP連接呢？

TCP 四元組可以唯一的確定一個連接,四元組包括如下: 源地址 源端口 目的地址 目的端口。

源地址和目的地址的字段(32位)是在 IP 頭部中,作用是通過 IP 協(xié)議發(fā)送報文給對方主機(jī)。

源端口和目的端口的字段(16位)是在 TCP 頭部中,作用是告訴 TCP 協(xié)議應(yīng)該把報文發(fā)給哪個進(jìn)程。

---

最后給大家分享一個Github倉庫，上面有大彬整理的300多本經(jīng)典的計(jì)算機(jī)書籍PDF，包括C語言、C++、Java、Python、前端、數(shù)據(jù)庫、操作系統(tǒng)、計(jì)算機(jī)網(wǎng)絡(luò)、數(shù)據(jù)結(jié)構(gòu)和算法、機(jī)器學(xué)習(xí)、編程人生等，可以star一下，下次找書直接在上面搜索，倉庫持續(xù)更新中~

Github地址：https://github.com/Tyson0314/java-books