1.認識TCP
tcp協議是傳輸層協議,它的主要的3個特點是面向連接、可靠保證、基于字節流。當應用層把數據給tcp層時,注意如果數據大于MSS是要在tcp層進行分段的。tcp協議為了保證不丟包會給每個包一個序號,接受方成功收到數據包后回回復一個確認,這個過程是在小于傳輸延遲RTT的時間內的。如果發送方在RTT時間內沒有收到確認就會重傳已丟失的數據包。說到要在tcp層進行分段我就想到老師經常提到以太網數據包的長度要小于或等于1518和大于或等于46字節,但我卻還不知道是什么原因。還有一個問題,在tcp層會對數據進行分段,它和分片的區別是什么。
問題一:為什么以太網數據幀大小在64字節和1518字節之間?
可以想象A給B發數據,發送數據這個過程本身是需要時間的,現在已經有部分數據在傳輸鏈路上了,B這時也準備發送數據。那么B這時就會檢測到沖突并將沖突信號返回給A,如果沖突信號返回給A時,A的數據還沒發送完那么A就知道有沖突,這樣數據就會選擇合適的時間重發。如果沖突信號到達A時A已經把數據發送完了,那么A就不會重傳數據了。所以在一個往返時間內,數據不能發送完,因此以太網數據幀小為64字節。如果數據幀太大,一方面其他主機需要長時間等待,一方面可能造成接受方緩沖區溢出,因此數據幀一定要小于一個值,至于為什么是1518那就是數學和其他多方面考慮得出的結果了。
問題二:Tcp層的分片和IP層的分片有什么區別?
我剛開始在TCP百度百科查看到“然后TCP把數據流分區成適當長度的報文段(通常受該計算機連接的網絡的數據鏈路層的大傳輸單元([1] MTU)的限制)”這樣一句話。我覺得很奇怪,tcp層的分段難道還和數據鏈路層的MTU有關系,既然已經有了IP分片,tcp層分段有什么意義呢?查閱資料后發現tcp分段是根據大傳輸單元MSS來進行的,MSS是建立tcp連接后,雙方協商的進行通信時所能承受的大數據長度。當使用IP分片時有一個大的缺點那就是一旦丟失一個分片,就會重新傳輸整個數據報。采用tcp分段的話它的數據長度是要小于MSS的,而MSS是小于MTU的,這樣的話就將重傳機制就交給tcp負責了。
2.TCP連接建立與釋放
昨天參加筆試這個地方就沒有答的很深入,只說了一個大概。所以今天得認真的學習下tcp,確實網絡挺重要的。tcp連接斷開主要是三次握手和四次握手,下面是我總結的一個表格。
| 建立連接 | 參數字段 | 狀態 |
| 客戶端請求服務器 | SYN=1,seq=x,SYN報文段不能攜帶數據。 | 客戶端進入SYN-SENT狀態 |
| 服務器回復客戶端 | SYN=1,ACK=1,seq=y,確認號ack=x+1,仍然不能攜帶數據。 | 服務器進入SYN-RCVD狀態 |
| 客戶端回應服務器 | ACK=1,seq=y+1,確認號ack=x+1。 | 服務器收到后客戶端和服務器同時進入ESTABLISHED狀態 |
| 釋放連接 | 參數字段 | 狀態 |
| A向B發送連接釋放報文 | FIN=1,seq=u。 | A進入FIN-WAIT-1狀態,等待B的確認。 |
| B回復確認 | ACK=1,seq=v,ack=u+1。 | B進入CLOSE-WAIT,這時B的tcp進程通知高層進程去釋放連接,B進入半關閉狀態,這個時候B不會接受數據但是可能發送數據。 |
| A收到確認后 | 不會發送數據包 | A進入FIN-WAIT-2狀態,等待B發出連接釋放數據報 |
| B發送連接釋放數據包 | FIN=1,ACK=1,seq=w,ack=u+1。 | B進入LAST-ACk后確認狀態,等待A的確認。 |
| A收到B的連接釋放包后,返回確認。 | ACK=1,seq=u+1,ack=w+1。 | 發送數據后,A進入到TIME-WAIT狀態,現在TCP連接還沒有釋放掉,必須經過時間等待計時器設置的時間2MSL(時間等待狀態)后A才能進入到CLOSED狀態。B收到數據報后也會進入CLOSED狀態,這樣A和B就斷開連接了。 |
問題三:為什么A在發送確認數據后必須等待2MSL時間呢?
有2個理由,是后一個A發送確認報文后,這個報文有可能丟失。如果B收不到A已發送確認報文那么B會重傳FIN+ACK報文段,A經過2MSL的好處就體現在這了,在2MSL內A還可以收到B重傳的數據包。A收到重傳的數據后會再重傳一次確認,重新啟動2MSL計時器。第二點是就是可以產生一個延遲,在2MSL時間內可保證本連接持續時間內所產生的報文段從網絡中消失,這樣就可以使下一個新的連接中不會出現上一次的數據報文段。
3.TCP的可靠性與擁塞控制
TCP的可靠性主要體現在滑動窗口機制和超時重傳。tcp的滑動窗口是以字節為單位的,當發送方發送數據時,接收方收到數據后會對收到的數據進行確認,發送方只有收到接收方的確認后才會將滑動窗口向前移動。滑動窗口機制可以保證數據被可靠的接受。每當發送方發送一個數據段時,就會啟動一個重傳定時器,如果在重傳超時前收到確認則會停止定時器,否則就會重傳該數據段。另外TCP會保持首部和數據的校驗和,當校驗和有差錯時,TCP將會丟棄這個報文段且不會確認收到此數據包,這樣做還有一個目的就是希望發送端超時重傳。TCP還能提供流量控制,發送方或接受方會相互通信傳遞自己的緩沖區大小,這樣發送方只會給接收方發送接收方可以容納的數據,這可以防止緩沖區溢出。
擁塞控制的目的就是為了防止過多的數據注入到網絡中,這樣可使網絡中的路由器或鏈路不致過度負荷,而且實現擁塞控制的前提是網絡可以承受現有的負荷。擁塞控制常常和流量控制搞混淆,我覺得可以從相同點與不同點去看這個問題。本來擁塞控制算法說到底就是告訴發送端你要減慢發送數據了,網絡現在有麻煩了你必須降低流量的出口,這點和流量控制是很相似的。但是擁塞控制是一個全局的過程,而流量控制往往是點對點通信量的控制,是端到端的關系。流量控制所要做得事情就是需要發送方減慢發送速度時抑制發送方的發送速度讓接收方來得及接受。進行擁塞控制主要是根據一些指標來判斷當前網絡的狀況,比如超時重傳的分組數或丟棄的數據包百分比等等。網絡系統進行控制肯定是很復雜的,我這里主要是總結課本上的4個算法,了解了網絡擁塞控制的基本原理。其中慢開始算法和擁塞控制算法一起結合使用。慢開始、快重傳和快恢復結合使用,但是慢開始僅僅在tcp建立連接時和網絡出現超時時才使用。
| 序號 | 過程描述 | 發送方 | 接收方 | 狀態 |
| 1 | 網絡正常情況 | 維持擁塞窗口的狀態變量,大小取決于網絡的擁塞程度。 | 做好接受數據的準備, | 發送方會讓發送窗口大小等于擁塞窗口大小,這個窗口大小是動態變化的且原則是只要沒出現網絡擁塞,擁塞窗口就會增大一些。 |
| 2 | 發送方開始發送數據 | 探測擁塞窗口并逐漸由小增大擁塞窗口的數值,當開始發送報文段時會將發送窗口增加為MSS的數值。 | 接受方對結果進行回復確認 | 接受方每收到一個新的報文段的確認后就會增加多一個MSS大小的窗口值。這個過程為慢算法,就是每完成一個傳輸過程,擁塞窗口就會增加。 |
| 3 | 是否達到慢開始門限 | 為了防止擁塞窗口過度增加會設置一個慢開始門限ssthresh變量。 | 接受方接受數據 | 如果擁塞窗口小于ssthresh繼續執行慢開始算法,如果是大于則停止使用慢開始算法而改用擁塞避免算法。如果是等于的話兩種算法都可以執行。這里假設要改用擁塞避免算法。 |
| 4 | 發送方開始執行擁塞避免算法 | 發送方的擁塞窗口不會成倍或以較快的速度的增加,而是以一種較小的速率去增加擁塞窗口大小。 | 接受方對結果進行回復確認 | 發送方根據動態改變的發送窗口大小發送數據。 |
| 5 | 發送方發現擁塞 | 發送方沒有收到接收方的確認回復 | 接收方沒有收到數據包或者回復數據包被丟失 | 慢開始門限會直接設置為擁塞時的發送窗口值的一半(它是存在一個小值的),擁塞窗口直接降為初始值開始執行慢開始算法。 |
| 6 | 執行序號2后使用快重傳算法 | 發送方正常發送數據 | 接收方每收到一個失序的報文段就會立即發出重復確認。 | 這樣接收方就能很快的知道有數據段沒有正確的被接收方接受。快重傳規定只要接收方連續收到三個重復確認就會趕快重傳確認數據包里說明的下一個數據段,而不是等待為丟失報文設置的計時器。 |
| 7 | 執行快重傳算法時會同時執行快恢復算法 | 現在發送方收到3個重復確認 | 接收方繼續監聽數據 | 發送方會將慢開始門限ssthresh減半,這是為了預防網絡發送擁塞,因為發送方沒有及時收到正確的數據段序號很有可能是網絡出現擁塞。接著不會執行慢開始算法,即不會將擁塞窗口值降為初始值而是為此時ssthresh的數值。 |
本站文章版權歸原作者及原出處所有 。內容為作者個人觀點, 并不代表本站贊同其觀點和對其真實性負責,本站只提供參考并不構成任何投資及應用建議。本站是一個個人學習交流的平臺,網站上部分文章為轉載,并不用于任何商業目的,我們已經盡可能的對作者和來源進行了通告,但是能力有限或疏忽,造成漏登,請及時聯系我們,我們將根據著作權人的要求,立即更正或者刪除有關內容。本站擁有對此聲明的最終解釋權。