默認
打賞 發表評論 20
想開發IM:買成品怕坑?租第3方怕貴?找開源自已擼?盡量別走彎路了... 找站長給點建議
[通俗易懂]深入理解TCP協議(上):理論基礎
閱讀(96524) | 評論(20 收藏30 淘帖1 1

前言


TCP是一個巨復雜的協議,因為他要解決很多問題,而這些問題又帶出了很多子問題和陰暗面。所以學習TCP本身是個比較痛苦的過程,但對于學習的過程卻能讓人有很多收獲。關于TCP這個協議的細節,我還是推薦你去看W.Richard Stevens的《TCP/IP 詳解 卷1:協議》(當然,你也可以去讀一下RFC793以及后面N多的RFC)。另外,本文我會使用英文術語,這樣方便你通過這些英文關鍵詞來查找相關的技術文檔。

特別推薦:TCP/IP協議理論經典《TCP/IP詳解 卷1:協議(在線閱讀版)》、《TCP/IP詳解 卷1:協議(CHM版)》。

本文目的


之所以想寫這篇文章,目的有三個:

  • 一個是想鍛煉一下自己是否可以用簡單的篇幅把這么復雜的TCP協議描清楚的能力。
  • 另一個是覺得現在的好多程序員基本上不會認認真真地讀本書,喜歡快餐文化,所以,希望這篇快餐文章可以讓你對TCP這個古典技術有所了解,并能體會到軟件設計中的種種難處。并且你可以從中有一些軟件設計上的收獲。
  • 最重要的希望這些基礎知識可以讓你搞清很多以前一些似是而非的東西,并且你能意識到基礎的重要。

所以,本文不會面面俱到,只是對TCP協議、算法和原理的科普。

系列文章


我本來只想寫一個篇幅的文章的,但是TCP真TMD的復雜,比C++復雜多了,這30多年來,各種優化變種爭論和修改。所以,寫著寫著就發現只有砍成兩篇:


更多參考資料:


基礎知識


廢話少說,首先,我們需要知道TCP在網絡OSI的七層模型中的第四層——Transport層,IP在第三層——Network層,ARP在第二層——Data Link層,在第二層上的數據,我們叫Frame,在第三層上的數據叫Packet,第四層的數據叫Segment。

首先,我們需要知道,我們程序的數據首先會打到TCP的Segment中,然后TCP的Segment會打到IP的Packet中,然后再打到以太網Ethernet的Frame中,傳到對端后,各個層解析自己的協議,然后把數據交給更高層的協議處理。

TCP協議頭的格式


接下來,我們來看一下TCP頭的格式:
[通俗易懂]深入理解TCP協議(上):理論基礎_1.jpg

你需要注意這么幾點:

  • TCP的包是沒有IP地址的,那是IP層上的事,但是有源端口和目標端口。
  • 一個TCP連接需要四個元組來表示是同一個連接(src_ip, src_port, dst_ip, dst_port)準確說是五元組,還有一個是協議。但因為這里只是說TCP協議,所以,這里我只說四元組。

注意上圖中的四個非常重要的東西:

  • Sequence Number:是包的序號,用來解決網絡包亂序(reordering)問題。
  • Acknowledgement Number:就是ACK——用于確認收到,用來解決不丟包的問題。
  • Window:又叫Advertised-Window,也就是著名的滑動窗口(Sliding Window),用于解決流控的。
  • TCP Flag :也就是包的類型,主要是用于操控TCP的狀態機的。

關于其它的東西,可以參看下面的圖示:
[通俗易懂]深入理解TCP協議(上):理論基礎_2.jpg

TCP的狀態機


其實,網絡上的傳輸是沒有連接的,包括TCP也是一樣的。而TCP所謂的“連接”,其實只不過是在通訊的雙方維護一個“連接狀態”,讓它看上去好像有連接一樣。所以,TCP的狀態變換是非常重要的。

下面是:“TCP協議的狀態機”(圖片來源) 和 “TCP建鏈接”、“TCP斷鏈接”、“傳數據” 的對照圖,我把兩個圖并排放在一起,這樣方便在你對照著看。另外,下面這兩個圖非常非常的重要,你一定要記牢。(吐個槽:看到這樣復雜的狀態機,就知道這個協議有多復雜,復雜的東西總是有很多坑爹的事情,所以TCP協議其實也挺坑爹的

[通俗易懂]深入理解TCP協議(上):理論基礎_QQ20160901-0.png

很多人會問,為什么建鏈接要3次握手,斷鏈接需要4次揮手?

  • 對于建鏈接的3次握手:主要是要初始化Sequence Number 的初始值。通信的雙方要互相通知對方自己的初始化的Sequence Number(縮寫為ISN:Inital Sequence Number)——所以叫SYN,全稱Synchronize Sequence Numbers。也就上圖中的 x 和 y。這個號要作為以后的數據通信的序號,以保證應用層接收到的數據不會因為網絡上的傳輸的問題而亂序(TCP會用這個序號來拼接數據)。
  • 對于4次揮手:其實你仔細看是2次,因為TCP是全雙工的,所以,發送方和接收方都需要Fin和Ack。只不過,有一方是被動的,所以看上去就成了所謂的4次揮手。如果兩邊同時斷連接,那就會就進入到CLOSING狀態,然后到達TIME_WAIT狀態。

下圖是雙方同時斷連接的示意圖(你同樣可以對照著TCP狀態機看):
[通俗易懂]深入理解TCP協議(上):理論基礎_5.png

另外,有幾個事情需要注意一下:

  • 關于建連接時SYN超時:
    試想一下,如果server端接到了clien發的SYN后回了SYN-ACK后client掉線了,server端沒有收到client回來的ACK,那么,這個連接處于一個中間狀態,即沒成功,也沒失敗。于是,server端如果在一定時間內沒有收到的TCP會重發SYN-ACK。在Linux下,默認重試次數為5次,重試的間隔時間從1s開始每次都翻售,5次的重試時間間隔為1s, 2s, 4s, 8s, 16s,總共31s,第5次發出后還要等32s都知道第5次也超時了,所以,總共需要 1s + 2s + 4s+ 8s+ 16s + 32s = 2^6 -1 = 63s,TCP才會把斷開這個連接。
  • 關于SYN Flood攻擊:
    一些惡意的人就為此制造了SYN Flood攻擊——給服務器發了一個SYN后,就下線了,于是服務器需要默認等63s才會斷開連接,這樣,攻擊者就可以把服務器的syn連接的隊列耗盡,讓正常的連接請求不能處理。于是,Linux下給了一個叫tcp_syncookies的參數來應對這個事——當SYN隊列滿了后,TCP會通過源地址端口、目標地址端口和時間戳打造出一個特別的Sequence Number發回去(又叫cookie),如果是攻擊者則不會有響應,如果是正常連接,則會把這個 SYN Cookie發回來,然后服務端可以通過cookie建連接(即使你不在SYN隊列中)。請注意,請先千萬別用tcp_syncookies來處理正常的大負載的連接的情況。因為,synccookies是妥協版的TCP協議,并不嚴謹。對于正常的請求,你應該調整三個TCP參數可供你選擇,第一個是:tcp_synack_retries 可以用他來減少重試次數;第二個是:tcp_max_syn_backlog,可以增大SYN連接數;第三個是:tcp_abort_on_overflow 處理不過來干脆就直接拒絕連接了。
  • 關于ISN的初始化:
    ISN是不能hard code的,不然會出問題的——比如:如果連接建好后始終用1來做ISN,如果client發了30個segment過去,但是網絡斷了,于是 client重連,又用了1做ISN,但是之前連接的那些包到了,于是就被當成了新連接的包,此時,client的Sequence Number 可能是3,而Server端認為client端的這個號是30了。全亂了。RFC793中說,ISN會和一個假的時鐘綁在一起,這個時鐘會在每4微秒對ISN做加一操作,直到超過2^32,又從0開始。這樣,一個ISN的周期大約是4.55個小時。因為,我們假設我們的TCP Segment在網絡上的存活時間不會超過Maximum Segment Lifetime(縮寫為MSL – Wikipedia語條),所以,只要MSL的值小于4.55小時,那么,我們就不會重用到ISN。
  • 關于 MSL 和 TIME_WAIT:
    通過上面的ISN的描述,相信你也知道MSL是怎么來的了。我們注意到,在TCP的狀態圖中,從TIME_WAIT狀態到CLOSED狀態,有一個超時設置,這個超時設置是 2*MSL(RFC793定義了MSL為2分鐘,Linux設置成了30s)為什么要這有TIME_WAIT?為什么不直接給轉成CLOSED狀態呢?主要有兩個原因:1)TIME_WAIT確保有足夠的時間讓對端收到了ACK,如果被動關閉的那方沒有收到Ack,就會觸發被動端重發Fin,一來一去正好2個MSL,2)有足夠的時間讓這個連接不會跟后面的連接混在一起(你要知道,有些自做主張的路由器會緩存IP數據包,如果連接被重用了,那么這些延遲收到的包就有可能會跟新連接混在一起)。你可以看看這篇文章《TIME_WAIT and its design implications for protocols and scalable client server systems
  • 關于TIME_WAIT數量太多:
    從上面的描述我們可以知道,TIME_WAIT是個很重要的狀態,但是如果在大并發的短鏈接下,TIME_WAIT 就會太多,這也會消耗很多系統資源。只要搜一下,你就會發現,十有八九的處理方式都是教你設置兩個參數,一個叫tcp_tw_reuse,另一個叫tcp_tw_recycle的參數,這兩個參數默認值都是被關閉的,后者recyle比前者resue更為激進,resue要溫柔一些。另外,如果使用tcp_tw_reuse,必需設置tcp_timestamps=1,否則無效。這里,你一定要注意,打開這兩個參數會有比較大的坑——可能會讓TCP連接出一些詭異的問題(因為如上述一樣,如果不等待超時重用連接的話,新的連接可能會建不上。正如官方文檔上說的一樣“It should not be changed without advice/request of technical experts”)。

關于tcp_tw_reuse:
官方文檔上說tcp_tw_reuse 加上tcp_timestamps(又叫PAWS, for Protection Against Wrapped Sequence Numbers)可以保證協議的角度上的安全,但是你需要tcp_timestamps在兩邊都被打開(你可以讀一下tcp_twsk_unique的源碼 )。我個人估計還是有一些場景會有問題。

關于tcp_tw_recycle:
如果是tcp_tw_recycle被打開了話,會假設對端開啟了tcp_timestamps,然后會去比較時間戳,如果時間戳變大了,就可以重用。但是,如果對端是一個NAT網絡的話(如:一個公司只用一個IP出公網)或是對端的IP被另一臺重用了,這個事就復雜了。建鏈接的SYN可能就被直接丟掉了(你可能會看到connection time out的錯誤)(如果你想觀摩一下Linux的內核代碼,請參看源碼 tcp_timewait_state_process)。

關于tcp_max_tw_buckets:
這個是控制并發的TIME_WAIT的數量,默認值是180000,如果超限,那么,系統會把多的給destory掉,然后在日志里打一個警告(如:time wait bucket table overflow),官網文檔說這個參數是用來對抗DDoS攻擊的。也說的默認值180000并不小。這個還是需要根據實際情況考慮。

Again,使用tcp_tw_reuse和tcp_tw_recycle來解決TIME_WAIT的問題是非常非常危險的,因為這兩個參數違反了TCP協議(RFC 1122

其實,TIME_WAIT表示的是你主動斷連接,所以,這就是所謂的“不作死不會死”。試想,如果讓對端斷連接,那么這個破問題就是對方的了,呵呵。另外,如果你的服務器是于HTTP服務器,那么設置一個HTTP的KeepAlive有多重要(瀏覽器會重用一個TCP連接來處理多個HTTP請求),然后讓客戶端去斷鏈接(你要小心,瀏覽器可能會非常貪婪,他們不到萬不得已不會主動斷連接)。

數據傳輸中的Sequence Number


下圖是我從Wireshark中截了個我在訪問coolshell.cn時的有數據傳輸的圖給你看一下,SeqNum是怎么變的。(使用Wireshark菜單中的Statistics ->Flow Graph… )

[通俗易懂]深入理解TCP協議(上):理論基礎_6.jpg

你可以看到,SeqNum的增加是和傳輸的字節數相關的。上圖中,三次握手后,來了兩個Len:1440的包,而第二個包的SeqNum就成了1441。然后第一個ACK回的是1441,表示第一個1440收到了。

注意:如果你用Wireshark抓包程序看3次握手,你會發現SeqNum總是為0,不是這樣的,Wireshark為了顯示更友好,使用了Relative SeqNum——相對序號,你只要在右鍵菜單中的protocol preference 中取消掉就可以看到“Absolute SeqNum”了

TCP重傳機制


TCP要保證所有的數據包都可以到達,所以,必需要有重傳機制。

注意:接收端給發送端的Ack確認只會確認最后一個連續的包,比如,發送端發了1,2,3,4,5一共五份數據,接收端收到了1,2,于是回ack 3,然后收到了4(注意此時3沒收到),此時的TCP會怎么辦?我們要知道,因為正如前面所說的,SeqNum和Ack是以字節數為單位,所以ack的時候,不能跳著確認,只能確認最大的連續收到的包,不然,發送端就以為之前的都收到了。

1超時重傳機制


一種是不回ack,死等3,當發送方發現收不到3的ack超時后,會重傳3。一旦接收方收到3后,會ack 回 4——意味著3和4都收到了。

但是,這種方式會有比較嚴重的問題,那就是因為要死等3,所以會導致4和5即便已經收到了,而發送方也完全不知道發生了什么事,因為沒有收到Ack,所以,發送方可能會悲觀地認為也丟了,所以有可能也會導致4和5的重傳。

對此有兩種選擇:

  • 一種是僅重傳timeout的包。也就是第3份數據。
  • 另一種是重傳timeout后所有的數據,也就是第3,4,5這三份數據。

這兩種方式有好也有不好。第一種會節省帶寬,但是慢,第二種會快一點,但是會浪費帶寬,也可能會有無用功。但總體來說都不好。因為都在等timeout,timeout可能會很長(在下篇會說TCP是怎么動態地計算出timeout的)。

2快速重傳機制


于是,TCP引入了一種叫Fast Retransmit 的算法,不以時間驅動,而以數據驅動重傳。也就是說,如果,包沒有連續到達,就ack最后那個可能被丟了的包,如果發送方連續收到3次相同的ack,就重傳。Fast Retransmit的好處是不用等timeout了再重傳。

比如:如果發送方發出了1,2,3,4,5份數據,第一份先到送了,于是就ack回2,結果2因為某些原因沒收到,3到達了,于是還是ack回2,后面的4和5都到了,但是還是ack回2,因為2還是沒有收到,于是發送端收到了三個ack=2的確認,知道了2還沒有到,于是就馬上重轉2。然后,接收端收到了2,此時因為3,4,5都收到了,于是ack回6。示意圖如下:

[通俗易懂]深入理解TCP協議(上):理論基礎_7.png

Fast Retransmit只解決了一個問題,就是timeout的問題,它依然面臨一個艱難的選擇,就是,是重傳之前的一個還是重傳所有的問題。對于上面的示例來說,是重傳#2呢還是重傳#2,#3,#4,#5呢?因為發送端并不清楚這連續的3個ack(2)是誰傳回來的?也許發送端發了20份數據,是#6,#10,#20傳來的呢。這樣,發送端很有可能要重傳從2到20的這堆數據(這就是某些TCP的實際的實現)。可見,這是一把雙刃劍。

3SACK 方法


另外一種更好的方式叫:Selective Acknowledgment (SACK)(參看RFC 2018),這種方式需要在TCP頭里加一個SACK的東西,ACK還是Fast Retransmit的ACK,SACK則是匯報收到的數據碎版。參看下圖:

[通俗易懂]深入理解TCP協議(上):理論基礎_7.jpg

這樣,在發送端就可以根據回傳的SACK來知道哪些數據到了,哪些沒有到。于是就優化了Fast Retransmit的算法。當然,這個協議需要兩邊都支持。在 Linux下,可以通過tcp_sack參數打開這個功能(Linux 2.4后默認打開)。

這里還需要注意一個問題——接收方Reneging,所謂Reneging的意思就是接收方有權把已經報給發送端SACK里的數據給丟了。這樣干是不被鼓勵的,因為這個事會把問題復雜化了,但是,接收方這么做可能會有些極端情況,比如要把內存給別的更重要的東西。所以,發送方也不能完全依賴SACK,還是要依賴ACK,并維護Time-Out,如果后續的ACK沒有增長,那么還是要把SACK的東西重傳,另外,接收端這邊永遠不能把SACK的包標記為Ack。

注意:SACK會消費發送方的資源,試想,如果一個攻擊者給數據發送方發一堆SACK的選項,這會導致發送方開始要重傳甚至遍歷已經發出的數據,這會消耗很多發送端的資源。(詳細的東西請參看《TCP SACK的性能權衡》)

4Duplicate SACK – 重復收到數據的問題


Duplicate SACK又稱D-SACK,其主要使用了SACK來告訴發送方有哪些數據被重復接收了。RFC-2883 里有詳細描述和示例。下面舉幾個例子(來源于RFC-2883).

D-SACK使用了SACK的第一個段來做標志:

  • 如果SACK的第一個段的范圍被ACK所覆蓋,那么就是D-SACK
  • 如果SACK的第一個段的范圍被SACK的第二個段覆蓋,那么就是D-SACK

示例一:ACK丟包
下面的示例中,丟了兩個ACK,所以,發送端重傳了第一個數據包(3000-3499),于是接收端發現重復收到,于是回了一個SACK=3000-3500,因為ACK都到了4000意味著收到了4000之前的所有數據,所以這個SACK就是D-SACK——旨在告訴發送端我收到了重復的數據,而且我們的發送端還知道,數據包沒有丟,丟的是ACK包。
Transmitted  Received    ACK Sent
Segment      Segment     (Including SACK Blocks)
 
3000-3499    3000-3499   3500 (ACK dropped)
3500-3999    3500-3999   4000 (ACK dropped)
3000-3499    3000-3499   4000, SACK=3000-3500
                                    ---------

示例二:網絡延誤
下面的示例中,網絡包(1000-1499)被網絡給延誤了,導致發送方沒有收到ACK,而后面到達的三個包觸發了“Fast Retransmit算法”,所以重傳,但重傳時,被延誤的包又到了,所以,回了一個SACK=1000-1500,因為ACK已到了3000,所以,這個SACK是D-SACK——標識收到了重復的包。這個案例下,發送端知道之前因為“Fast Retransmit算法”觸發的重傳不是因為發出去的包丟了,也不是因為回應的ACK包丟了,而是因為網絡延時了。
Transmitted    Received    ACK Sent
Segment        Segment     (Including SACK Blocks)
 
500-999        500-999     1000
1000-1499      (delayed)
1500-1999      1500-1999   1000, SACK=1500-2000
2000-2499      2000-2499   1000, SACK=1500-2500
2500-2999      2500-2999   1000, SACK=1500-3000
1000-1499      1000-1499   3000
                       1000-1499   3000, SACK=1000-1500
                                      ---------

可見,引入了D-SACK,有這么幾個好處:

  • 1)可以讓發送方知道,是發出去的包丟了,還是回來的ACK包丟了。
  • 2)是不是自己的timeout太小了,導致重傳。
  • 3)網絡上出現了先發的包后到的情況(又稱reordering)
  • 4)網絡上是不是把我的數據包給復制了。

知道這些東西可以很好得幫助TCP了解網絡情況,從而可以更好的做網絡上的流控。Linux下的tcp_dsack參數用于開啟這個功能(Linux 2.4后默認打開)

好了,上篇就到這里結束了。如果你覺得我寫得還比較淺顯易懂,那么,歡迎移步看下篇《[通俗易懂]深入理解TCP協議(下)》。

(原文鏈接:http://coolshell.cn/articles/11564.html

附錄:更多網絡編程資料


TCP/IP詳解 - 第11章·UDP:用戶數據報協議
TCP/IP詳解 - 第17章·TCP:傳輸控制協議
TCP/IP詳解 - 第18章·TCP連接的建立與終止
TCP/IP詳解 - 第21章·TCP的超時與重傳
技術往事:改變世界的TCP/IP協議(珍貴多圖、手機慎點)
理論經典:TCP協議的3次握手與4次揮手過程詳解
理論聯系實際:Wireshark抓包分析TCP 3次握手、4次揮手過程
計算機網絡通訊協議關系圖(中文珍藏版)
UDP中一個包的大小最大能多大?
P2P技術詳解(一):NAT詳解——詳細原理、P2P簡介
P2P技術詳解(二):P2P中的NAT穿越(打洞)方案詳解
P2P技術詳解(三):P2P技術之STUN、TURN、ICE詳解
通俗易懂:快速理解P2P技術中的NAT穿透原理
技術掃盲:新一代基于UDP的低延時網絡傳輸層協議——QUIC詳解
讓互聯網更快:新一代QUIC協議在騰訊的技術實踐分享
現代移動端網絡短連接的優化手段總結:請求速度、弱網適應、安全保障
聊聊iOS中網絡編程長連接的那些事
移動端IM開發者必讀(一):通俗易懂,理解移動網絡的“弱”和“慢”
移動端IM開發者必讀(二):史上最全移動弱網絡優化方法總結
IPv6技術詳解:基本概念、應用現狀、技術實踐(上篇)
IPv6技術詳解:基本概念、應用現狀、技術實踐(下篇)
從HTTP/0.9到HTTP/2:一文讀懂HTTP協議的歷史演變和設計思路
>> 更多同類文章 ……

即時通訊網 - 即時通訊開發者社區! 來源: - 即時通訊開發者社區!

上一篇:如何使用日志跟蹤Android端mina的內部細節下一篇:[通俗易懂]深入理解TCP協議(下):RTT、滑動窗口、擁塞處理

本帖已收錄至以下技術專輯

推薦方案
評論 20
快餐 !吃不下!自己慢慢煮又等不及.....一個失敗人的煎熬
引用:emsd1104 發表于 2016-09-01 19:33
快餐 !吃不下!自己慢慢煮又等不及.....一個失敗人的煎熬

貌似好有哲理的樣紙。。
簽名: 《主流移動端賬號登錄方式的原理及設計思路》http://www.uktmgv.tw/thread-2863-1-1.html
講的真詳細
簽名: 遇見
講的真詳細
贊,清晰易懂
簽名: Linux Driver
為什么需要4次揮手可以這么理解一下:
第二次和第三次揮手為什么不能合成一次揮手呢,是因為右側的主機回復(ACK x+3)的時候可能還有數據要發送,所以不能同時發送(FIN seq=y+1)給左側方主機。
所以第二次和第三次揮手不能合并,第二次揮手和第三次揮手之間可能右側房還有數據未發送完成
引用:x931609201 發表于 2017-11-18 15:09
為什么需要4次揮手可以這么理解一下:
第二次和第三次揮手為什么不能合成一次揮手呢,是因為右側的主機回 ...

看的認真啊
簽名: 《主流移動端賬號登錄方式的原理及設計思路》http://www.uktmgv.tw/thread-2863-1-1.html
引用:JackJiang 發表于 2017-11-18 16:12
看的認真啊

必須的,文章寫的認真才看的認真
通俗易懂,受益匪淺
老哥出品,必屬精品
醍醐灌頂,寫的真棒,謝謝你
簽名: 下雨了,今天不熱,心情涼快
“ARP在第二層——Data Link層”, ARP不是應該在 網絡層嗎?
"Fast Retransmit只解決了一個問題,就是timeout的問題,它依然面臨一個艱難的選擇,就是,是重傳之前的一個還是重傳所有的問題。對于上面的示例來說,是重傳#2呢還是重傳#2,#3,#4,#5呢?因為發送端并不清楚這連續的3個ack(2)是誰傳回來的?也許發送端發了20份數據,是#6,#10,#20傳來的呢。這樣,發送端很有可能要重傳從2到20的這堆數據(這就是某些TCP的實際的實現)。"
這個快速重傳為什么說不知重傳哪個包的問題? 正如文中所說的,#1包收到了,回#2ack,結果沒收到,持續發超過3次的#2ack,發送端發送#2的包,#2ack的編號不就是接受端下次的想要收到包的seq么?所以發送#2ack已經告訴發送端想要哪個包了
我蹲在廁所里看,等完事的時候,雙腿已經麻的站不起來
引用:Jonphy 發表于 2019-07-24 14:14
我蹲在廁所里看,等完事的時候,雙腿已經麻的站不起來

下次文章我弄短點,不然長此以往,不說屁股,馬桶都受不了
簽名: 《主流移動端賬號登錄方式的原理及設計思路》http://www.uktmgv.tw/thread-2863-1-1.html
引用:JackJiang 發表于 2019-07-24 16:18
下次文章我弄短點,不然長此以往,不說屁股,馬桶都受不了

別別,文章過短就難以明了于閱讀者,我還是臥床閱讀好了
引用:Jonphy 發表于 2019-07-24 17:06
別別,文章過短就難以明了于閱讀者,我還是臥床閱讀好了

嗯嗯 希望床受的了
簽名: 《主流移動端賬號登錄方式的原理及設計思路》http://www.uktmgv.tw/thread-2863-1-1.html
圖文并茂,很贊
簽名: 金幣很重要,知識更重要
不是很明白,有很多問題沒有寫清楚。
隨便舉個例子吧:
快速重傳機制,這里:
“”比如:如果發送方發出了1,2,3,4,5份數據,第一份先到送了,于是就ack回2“
1, 為什么第1份數據到了是回2,不是回1,明顯有問題,應該是寫錯
2,上面的例子只寫了5份數據的情況,如果只發一份數據呢?怎么保證連續收到3次相同的包,表示需要重傳
3,為啥沒有解決“”是重傳之前的一個還是重傳所有的問題”?不是收到3次,就只傳一個包就行了,不需要重傳所有啊。比如收到3次#2,其他都收到了,只重傳#2不就可以了。

不知道我理解的正確與否?麻煩博主回答一下
打賞樓主 ×
使用微信打賞! 使用支付寶打賞!

返回頂部
曾氏料二肖中特