在進行UDP編程的時候,一次發(fā)送多少bytes好?
79、TCP四大擁塞控制算法總結?(極其重要)
四大算法
擁塞控制主要是四個算法:1)慢啟動,2)擁塞避免,3)擁塞發(fā)生,4)快速恢復。這四個算法不是一天都搞出來的,這個四算法的發(fā)展經歷了很多時間,到今天都還在優(yōu)化中。
慢熱啟動算法 – Slow Start
所謂慢啟動,也就是TCP連接剛建立,一點一點地提速,試探一下網絡的承受能力,以免直接擾亂了網絡通道的秩序。
慢啟動算法:
連接建好的開始先初始化擁塞窗口cwnd大小為1,表明可以傳一個MSS大小的數據。每當收到一個ACK,cwnd大小加一,呈線性上升。每當過了一個往返延遲時間RTT(Round-Trip Time),cwnd大小直接翻倍,乘以2,呈指數讓升。還有一個ssthresh(slow start threshold),是一個上限,當cwnd >= ssthresh時,就會進入“擁塞避免算法”(后面會說這個算法)擁塞避免算法 – Congestion Avoidance
如同前邊說的,當擁塞窗口大小cwnd大于等于慢啟動閾值ssthresh后,就進入擁塞避免算法。算法如下:
收到一個ACK,則cwnd = cwnd + 1 / cwnd每當過了一個往返延遲時間RTT,cwnd大小加一。
過了慢啟動閾值后,擁塞避免算法可以避免窗口增長過快導致窗口擁塞,而是緩慢的增加調整到網絡的最佳值。
擁塞發(fā)生狀態(tài)時的算法
一般來說,TCP擁塞控制默認認為網絡丟包是由于網絡擁塞導致的,所以一般的TCP擁塞控制算法以丟包為網絡進入擁塞狀態(tài)的信號。對于丟包有兩種判定方式,一種是超時重傳RTO[Retransmission Timeout]超時,另一個是收到三個重復確認ACK。
超時重傳是TCP協議保證數據可靠性的一個重要機制,其原理是在發(fā)送一個數據以后就開啟一個計時器,在一定時間內如果沒有得到發(fā)送數據報的ACK報文,那么就重新發(fā)送數據,直到發(fā)送成功為止。
但是如果發(fā)送端接收到3個以上的重復ACK,TCP就意識到數據發(fā)生丟失,需要重傳。這個機制不需要等到重傳定時器超時,所以叫做快速重傳,而快速重傳后沒有使用慢啟動算法,而是擁塞避免算法,所以這又叫做快速恢復算法。
超時重傳RTO[Retransmission Timeout]超時,TCP會重傳數據包。TCP認為這種情況比較糟糕,反應也比較強烈:
由于發(fā)生丟包,將慢啟動閾值ssthresh設置為當前cwnd的一半,即ssthresh = cwnd / 2.cwnd重置為1進入慢啟動過程
最為早期的TCP Tahoe算法就只使用上述處理辦法,但是由于一丟包就一切重來,導致cwnd又重置為1,十分不利于網絡數據的穩(wěn)定傳遞。
所以,TCP Reno算法進行了優(yōu)化。當收到三個重復確認ACK時,TCP開啟快速重傳Fast Retransmit算法,而不用等到RTO超時再進行重傳:
cwnd大小縮小為當前的一半ssthresh設置為縮小后的cwnd大小然后進入快速恢復算法Fast Recovery。
快速恢復算法 – Fast Recovery
TCP Tahoe是早期的算法,所以沒有快速恢復算法,而Reno算法有。在進入快速恢復之前,cwnd和ssthresh已經被更改為原有cwnd的一半?焖倩謴退惴ǖ倪壿嬋缦拢
cwnd = cwnd + 3 MSS,加3 MSS的原因是因為收到3個重復的ACK。
重傳DACKs指定的數據包。
如果再收到DACKs,那么cwnd大小增加一。
如果收到新的ACK,表明重傳的包成功了,那么退出快速恢復算法。將cwnd設置為ssthresh,然后進入擁塞避免算法。
如圖所示,第五個包發(fā)生了丟失,所以導致接收方接收到三次重復ACK,也就是ACK5。所以將ssthresh設置當當時cwnd的一半,也就是6/2 = 3,cwnd設置為3 + 3 = 6。然后重傳第五個包。當收到新的ACK時,也就是ACK11,則退出快速恢復階段,將cwnd重新設置為當前的ssthresh,也就是3,然后進入擁塞避免算法階段。
80、為何快速重傳是選擇3次ACK?
主要的考慮還是要區(qū)分包的丟失是由于鏈路故障還是亂序等其他因素引發(fā)。
兩次duplicated ACK時很可能是亂序造成的!三次duplicated ACK時很可能是丟包造成的!四次duplicated ACK更更更可能是丟包造成的,但是這樣的響應策略太慢。丟包肯定會造成三次duplicated ACK!綜上是選擇收到三個重復確認時窗口減半效果最好,這是實踐經驗。
在沒有fast retransmit / recovery 算法之前,重傳依靠發(fā)送方的retransmit timeout,就是在timeout內如果沒有接收到對方的ACK,默認包丟了,發(fā)送方就重傳,包的丟失原因
1)包checksum 出錯
2)網絡擁塞
3)網絡斷,包括路由重收斂,但是發(fā)送方無法判斷是哪一種情況,于是采用最笨的辦法,就是將自己的發(fā)送速率減半,即CWND 減為1/2,這樣的方法對2是有效的,可以緩解網絡擁塞,3則無所謂,反正網絡斷了,無論發(fā)快發(fā)慢都會被丟;但對于1來說,丟包是因為偶爾的出錯引起,一丟包就對半減速不合理。
于是有了fast retransmit 算法,基于在反向還可以接收到ACK,可以認為網絡并沒有斷,否則也接收不到ACK,如果在timeout 時間內沒有接收到> 2 的duplicated ACK,則概率大事件為亂序,亂序無需重傳,接收方會進行排序工作;
而如果接收到三個或三個以上的duplicated ACK,則大概率是丟包,可以邏輯推理,發(fā)送方可以接收ACK,則網絡是通的,可能是1、2造成的,先不降速,重傳一次,如果接收到正確的ACK,則一切OK,流速依然(包出錯被丟)。
而如果依然接收到duplicated ACK,則認為是網絡擁塞造成的,此時降速則比較合理。
81、對于FIN_WAIT_2,CLOSE_WAIT狀態(tài)和TIME_WAIT狀態(tài)?你知道多少?
FIN_WAIT_2:
半關閉狀態(tài)。
發(fā)送斷開請求一方還有接收數據能力,但已經沒有發(fā)送數據能力。
CLOSE_WAIT狀態(tài):
被動關閉連接一方接收到FIN包會立即回應ACK包表示已接收到斷開請求。
被動關閉連接一方如果還有剩余數據要發(fā)送就會進入CLOSED_WAIT狀態(tài)。
TIME_WAIT狀態(tài):
又叫2MSL等待狀態(tài)。
如果客戶端直接進入CLOSED狀態(tài),如果服務端沒有接收到最后一次ACK包會在超時之后重新再發(fā)FIN包,此時因為客戶端已經CLOSED,所以服務端就不會收到ACK而是收到RST。所以TIME_WAIT狀態(tài)目的是防止最后一次握手數據沒有到達對方而觸發(fā)重傳FIN準備的。
在2MSL時間內,同一個socket不能再被使用,否則有可能會和舊連接數據混淆(如果新連接和舊連接的socket相同的話)。
82、你了解流量控制原理嗎?
目的是接收方通過TCP頭窗口字段告知發(fā)送方本方可接收的最大數據量,用以解決發(fā)送速率過快導致接收方不能接收的問題。所以流量控制是點對點控制。
TCP是雙工協議,雙方可以同時通信,所以發(fā)送方接收方各自維護一個發(fā)送窗和接收窗。
發(fā)送窗:用來限制發(fā)送方可以發(fā)送的數據大小,其中發(fā)送窗口的大小由接收端返回的TCP報文段中窗口字段來控制,接收方通過此字段告知發(fā)送方自己的緩沖(受系統、硬件等限制)大小。
接收窗:用來標記可以接收的數據大小。
TCP是流數據,發(fā)送出去的數據流可以被分為以下四部分:已發(fā)送且被確認部分 | 已發(fā)送未被確認部分 | 未發(fā)送但可發(fā)送部分 | 不可發(fā)送部分,其中發(fā)送窗 = 已發(fā)送未確認部分 + 未發(fā)但可發(fā)送部分。接收到的數據流可分為:已接收 | 未接收但準備接收 | 未接收不準備接收。接收窗 = 未接收但準備接收部分。
發(fā)送窗內數據只有當接收到接收端某段發(fā)送數據的ACK響應時才移動發(fā)送窗,左邊緣緊貼剛被確認的數據。接收窗也只有接收到數據且最左側連續(xù)時才移動接收窗口。
83、建立TCP服務器的各個系統調用過程是怎樣的?
請輸入評論內容...
請輸入評論/評論長度6~500個字
最新活動更多
-
即日-11.13立即報名>>> 【在線會議】多物理場仿真助跑新能源汽車
-
11月20日火熱報名中>> 2024 智能家居出海論壇
-
11月28日立即報名>>> 2024工程師系列—工業(yè)電子技術在線會議
-
12月19日立即報名>> 【線下會議】OFweek 2024(第九屆)物聯網產業(yè)大會
-
即日-12.26火熱報名中>> OFweek2024中國智造CIO在線峰會
-
即日-2025.8.1立即下載>> 《2024智能制造產業(yè)高端化、智能化、綠色化發(fā)展藍皮書》
推薦專題
- 高級軟件工程師 廣東省/深圳市
- 自動化高級工程師 廣東省/深圳市
- 光器件研發(fā)工程師 福建省/福州市
- 銷售總監(jiān)(光器件) 北京市/海淀區(qū)
- 激光器高級銷售經理 上海市/虹口區(qū)
- 光器件物理工程師 北京市/海淀區(qū)
- 激光研發(fā)工程師 北京市/昌平區(qū)
- 技術專家 廣東省/江門市
- 封裝工程師 北京市/海淀區(qū)
- 結構工程師 廣東省/深圳市