文章目錄

• • 1.協議格式：
  • 2.協議特性：
  • • 2.1 面向鏈接
    • • 2.1.1三次握手建立連接
      • 2.1.1四次揮手斷開連接
      • 相關問題和知識點：
      • • 1. 握手為啥三次，揮手是四次？
        • 2. 三次握手失敗兩端是如何處理的？
        • 3. SYN泛洪攻擊是怎么回事?
        • 4. 一臺主機上出現了大量CLOSE_WAIT狀態鏈接是什么原因？
        • 5. TIME_WAIT狀態有什么作用？
        • 6. 一臺主機上出現大量TIME_WAIT鏈接，什么原因，怎么解決？
        • 7. TCP的保活機制（心跳探測）
    • 2.2 可靠傳輸
    • • 2.2.1 安全有序傳輸(保證數據可靠到達對端并且有序進行交付)
      • • 1. 確認應答機制
        • 2. 超時重傳機制
        • 3. 協議字段中的序號(th_seq)和確認序號(th_ack)進行包序管理，實現有序交付
        • 4. 協議字段中的校驗和校驗數據一致性。
      • 2.2.2 避免沒必要的丟包
      • • 1. 滑動窗口機制
        • 2. 擁塞窗口機制
      • 2.2.3 提高一些傳輸性能
      • • 1. 確認序號
        • 2. 快速重傳協議
        • 3. 捎帶應答機制：
        • 4. 延遲應答機制
        • 5. 延遲發送機制
    • 2.3 面向字節流傳輸
  • 3 對應用層編程影響
  • • • • 問題:tcp和udp協議的區別？
        • tcp如何實現可靠傳輸
        • udp如何實現可靠傳輸

TCP ：傳輸控制協議

1.協議格式：

16位源端端口-16位對端端口：描述通信兩端

32位序號-32位確認序號：用于實現包序管理。

4位報頭長度：描述tcp報頭長度。4位表示最大數字15；以四字節為單位，所以TCp報頭最小長度20字節，最大為15 * 4 = 60字節。

6位保留

6位標志位:

URG: 緊急指針是否有效ACK: 確認應答PSH: 提示接收端應用程序立刻從TCP緩沖區把數據讀走RST: 對方要求重新建立連接; 我們把攜帶RST標識的稱為復位報文段SYN: 請求建立連接; 我們把攜帶SYN標識的稱為同步報文段FIN: 通知對方, 本端要關閉了, 我們稱攜帶FIN標識的為結束報文段

16位窗口大小：用于實現滑動窗口機制–進行發送數據的流量控制。防止緩沖區溢出丟包。

16為校驗和：校驗數據一致性。

16位緊急指針：發送的帶外數據的位置

0-40字節選項數據：存儲一些可能需要的額外的信息。Mss…

應用數據

2.協議特性：

2.1 面向鏈接

面向鏈接：通信雙方建立連接之后才能進行通信，—>確保通信雙方都據有數據收發能力

TCP的鏈接管理：三次握手建立鏈接，四次揮手斷開鏈接。
主要是為了確認通信雙方都在線有數據收發能力。

2.1.1三次握手建立連接

客戶端向服務端請求建立連接:

2.1.1四次揮手斷開連接

相關問題和知識點：

1. 握手為啥三次，揮手是四次？

三次握收：雙發都需要確定對方是否具有數據收發能力。兩次不安全—只能確定服務端在線，客戶端可能發送完SYN請求后就下線了。四次沒必要—SYN和ACK都是報文中的標志位，分開發送沒太大意義，直接將這兩個標志位都置為1同時發送即可。
四次揮手：雙方上層只有在不會發送數據的情況下才會發送FIN（FIN表示上層不再發送數據，但下層還能ACK確認回復）。收到FIN請求只能表示對方上層不再send發送數據，不代表對方不能再收數據了。因此有可能接收FIN請求的一方還會繼續給對方發送數據，只有在上層調用了close或者shutdown關閉寫才會主動給關閉方發FIN(不再發數據了).所以被動關閉方的FIN和ACK默認不一起發送。

2. 三次握手失敗兩端是如何處理的？

握手失敗情況：
1.SYN請求丟失，客戶端沒得到確認回復，隔一段時間會重新發送SYN請求。多次發送失敗會導致請求超時，連接失敗。
2. 服務端發送的ACK+SYN信息丟失。客戶端沒收到SYN導致服務器沒收到相應的的ACK回復，新建的套接字會重新發送ACK+SYN請求。若服務端發送ACK+SYN請求超時（服務端可能會覺得這是惡意攻擊請求，只發起連接不回復，占用資源），給客戶端發送RST重置連接報文，釋放新建套接字的資源。
3. 客戶端最后發送的ACK丟了。服務端等待超時，服務端發送RST，釋放資源，從新建立連接。

3. SYN泛洪攻擊是怎么回事?

黑客偽造ip不斷向服務端發送SYN,但是不進行ACK回復，服務端新創建套接字會不斷占用資源，直至枯竭崩潰。所以listen(sockfd,backlog)接口中有backlog參數–新建連接隊列–隊列滿了就不會再新建套接字。處理方法：防火墻–同一ip頻繁發送數據則拉黑名單。

4. 一臺主機上出現了大量CLOSE_WAIT狀態鏈接是什么原因？

CLOSE_WAIT狀態是被動關閉方收到FIN請求并進行ACK回復之后進入到的狀態。一旦自己發送了FIN（close操作后就會發送FIN）則會進入下一個LAST_ACK狀態，因此有大量CLOSE_WAIT,意味著代碼中可能沒有對連接斷開的套接字進行close操作。解決方案就是檢查代碼。

5. TIME_WAIT狀態有什么作用？

TIME_WAIT狀態是主動關閉方在收到對方FIN后，進行最后一次ACK回復后進入的狀態。如果最后一次ACK丟失了，被動關閉方等待沒收到ACK，則會重新發送FIN（只重傳一次），所以TIME_WAIT狀態就是等待這次可能重傳的ACK。
TIME_WAIT實際上是為了保護新建套接字不會使用剛被釋放的套接字的地址和端口，防止原先通信的數據對新連接造成的影響（本來需要發送到原先套接字的重傳FIN發送送到了新套接字的通信會話中）。
TIME_WAIT會等待兩個MSL（最大報文生存周期）時間---->最后重傳FIN和ACK的時間 X 2，確保本次通信的數據都消失在網絡中，不會對新的連接造成影響。
TIME_WAIT實際上更多是為了保護客戶端，客戶端通常不主動綁定地址信息，交給系統分配;而服務端通信通常需要綁定相同的地址信息，重啟之后地址信息不變。

6. 一臺主機上出現大量TIME_WAIT鏈接，什么原因，怎么解決？

TIME_WAIT是主動關閉方最后一次發送ACK產生的。
出現大量TIME_WAIT則是因為大量主動關閉套接字，常見于爬蟲主機。
解決方案：將TIME_WAIT等待時間設置更短一些。
或：設置套接字選項，開啟地址復用,常見于服務端。
int setsockopt(int sockfd, int level, int optname,const void *optval, socklen_t optlen);
level：SOL_SOCKET
optname：SO_REUSEADDR

7. TCP的保活機制（心跳探測）

默認情況：通信雙方7200s沒有通信，則服務端每隔75s會向客戶端發送一個保活探測數據包，要求客戶端進行回復，連續9次沒有進行回復則認為連接斷開。
可以設置保活時間和次數。
連接斷開在后程序在上層的表現：recv返回0;send會觸發SIGPIPE異常—>會導致進程異常退出，可自定義SICPIPE信號的處理方式。

2.2 可靠傳輸

2.2.1 安全有序傳輸(保證數據可靠到達對端并且有序進行交付)

面向鏈接（前提）：首先確保雙方都具有數據收發能力

1. 確認應答機制

實現丟包檢測功能，接收方針對接收的每一條數據都應該進行確認回復。
發送方收到確認回復認為傳輸成功，否則認為數據丟包。

2. 超時重傳機制

發送方等待超時沒有得到確認回復，則會對數據包重新傳輸。超時等待時長會隨著網絡環境的不同, 是有差異的.如果超時時間設的太長, 會影響整體的重傳效率;如果超時時間設的太短, 有可能會頻繁發送重復的包;

3. 協議字段中的序號(th_seq)和確認序號(th_ack)進行包序管理，實現有序交付

利用==協議字段中的序號(th_seq)和確認序號(th_ack)==進行包序管理，實現有序交付。

舉個例子感受一下序號(th_seq)和確認序號(th_ack)的作用，下圖中seq為其實序號，ack表示確認序號。

4. 協議字段中的校驗和校驗數據一致性。

數據不一致則丟棄，丟棄則無針對此數據的確認回復，對方收不到確認回復則重傳此數據；也可直接發送重傳請求。

2.2.2 避免沒必要的丟包

丟包情況：

發送方發送數據過多，接收方來不及處理，緩沖區溢出之后所產生的丟包。
2.>傳輸起始或者過程中網絡突然變差所導致的大量丟包。

1. 滑動窗口機制

依賴于協議字段中的窗口大小字段實現，避免發送方發送數據過多，接收方來不及處理，緩沖區溢出之后所產生的丟包。
原理：接收方接收數據之后就會進行確認應答，這時候會通過窗口大小字段告訴對方最多再給自己發送多少數據。窗口大小不能大于接收緩沖區剩余空間大小。
實現：通信雙方都會維護一個發送窗口和接收窗口。
圖畫不動了，參考文章：網絡 滑動窗口機制，這個里面有比較圖解，過程較詳細。

相關概念：

MSS:最大數據段大小，表示一個TCP報文中數據的最大大小。

相關協議：

停等協議：發送數據之后，收到確認回復才會發送下一條。適合網絡環境差的場景。 回退n步協議：那一條數據丟失，則從丟失的數據包開始整體重傳。 選擇重傳協議：哪條丟失重傳哪條。適用于網絡環境較好的場景。

2. 擁塞窗口機制

擁塞窗口機制：解決網絡突然變差產生大量丟包的問題。
原理：發送方維護了一個擁塞窗口，用于限制當前所能發送的數據量。擁塞窗口大小是一種慢啟動快增長（指數上漲，閾值為窗口大小）的形式進行傳輸控制。防止突然網絡變差，導致大量丟包。每次丟包都會進行一次網絡狀況探測的過程。

2.2.3 提高一些傳輸性能

tcp為了實現可靠傳輸，犧牲了傳輸性能，而在傳輸過程中，有些性能上的損失是沒有必要的。

1. 確認序號

確認序號標識序號之前的數據都已經收到了，為了避免因為確認應答丟失導致的重傳。

2. 快速重傳協議

在傳輸過程中，若接收方接收到的數據并非是接收窗口后沿數據，則有理由認為前邊發送的數據丟失了，這時候每收到一條數據就會發送一條后沿數據的重傳請求，一旦發送方連續收到三條（三條是為了避免數據延遲到達的情況）相同重傳請求，則直接對這條數據（確認序號的數據）進行重傳。丟包后不用完全等待超時重傳，節省時間。

3. 捎帶應答機制：

接收方對接收到的每一條數據都需要進行確認回復，然而確認回復最主要的信息就是確認序號，因此每一條確認回復都是一個tcp傳輸，至少是一個空報頭（沒有實際數據）的傳輸。如果收到數據后剛好要給對方發送數據，則將及即將要發送的數據和確認回復放到一起進行發送（在要發送的數據報頭中加入確認序號）。

4. 延遲應答機制

接收方對接收到的每一條數據都需要進行確認回復，其中包含有當前窗口大小字段，如果立即進行回復，窗口大概率是不斷減小的，因此延遲進行確認回復，有可能上層將數據取出，維持窗口大小。通過這種方式保證傳輸吞吐量不會降低。

5. 延遲發送機制

tcp傳輸過程中，如果對每次send的數據直接封裝報頭進行發送，若發送的數據比較小，但是次數較多，則io次數比較多，效率低。因此延遲發送，將數據在發送緩沖區中先堆積起來，再合適的時候一次性發送，減少了io次數，提高效率。
nagle算法–通過套接字選項設置(默認是開啟的)

2.3 面向字節流傳輸

面向字節流傳輸：可靠的，有序的，雙向的，基于連接的，以字節為單位的傳輸方式。傳輸時，并不限制上層（send \ recv）發送或者接收的數據大小。tcp延遲發送數據在緩沖區中積攢，基于mss取出合適大小數據進行發送。
優勢：相對于面向數據報來說，傳輸更加靈活。
缺陷：產生粘包問題—將多條數據當作一條數據處理。
產生粘包的原因：tcp不會對數據進行邊界處理。
解決方案：程序員需要在應用層進行數據的邊界管理。可用特殊字符作為間隔(需要考慮特殊字符轉譯)；使用TLV格式數據（在應用層頭部加入數據長度）；數據定長----提前約定會定長的數據，但是數據太短需要進行補全；

3 對應用層編程影響

連接斷開：recv返回0，send觸發異常。
recv一旦返回0，就要考慮文件描述符的回收關閉
Send因為會觸發一次導致進程退出，若不想退出進程需要自定義信號處理。

tcp傳輸存在粘包問題，需要在應用層進行數據邊界管理。udp整條交付，無粘包問題。

問題:tcp和udp協議的區別？

實現上的區別：協議格式，協議字段不一樣。
特性上的區別：TCp是面向連接的可靠的字節流傳輸方式。udp是無連接不可靠面向數據報的傳輸方式。udp支持廣播,tcp不支持。
應用場景上的區別：UDP適用于實時性高于安全性的場景，tcp用于傳輸安全性高于實時性的場景。

tcp如何實現可靠傳輸

確認應答機制

超時重傳機制

協議字段中的序號(th_seq)和確認序號(th_ack)進行包序管理，實現有序交付

協議字段中的校驗和校驗數據一致性。

udp如何實現可靠傳輸

ud協議本身沒有實現可靠傳輸，需要在應用層手動實現類似tcp的可靠傳輸機制：確認應答機制，超時重傳機制，包序管理。

總結

以上是生活随笔為你收集整理的TCP协议格式和特点的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。