頭條面試題

TCP連接

一個包丟了怎麼處理

tcp協議關於發送數據包:
慢啓動(slow start)機制,開始時發送較慢,然後根據丟包情況判斷加快還是降低。
默認情況下,接受方每接受到兩個tcp數據包就要發送一個acknowledgement 簡稱 ACK
ACK:
1.期待要收到的下一個數據包的編號
2.接收方的接受窗口剩餘容量

握手過程中使用了 TCP 的標誌(flag) —— SYN(synchronize) 和 ACK(acknowledgement)。 發送端首先發送一個帶 SYN 標誌的數據包給對方。接收端收到後, 回傳一個帶有 SYN/ACK 標誌的數據包以示傳達確認信息。最後,發 送端再回傳一個帶 ACK 標誌的數據包,代表“握手”結束。

丟了包:如果發送方發現受到三個重複的ACK或者超時了還沒有收到任何ACK,就會確認丟包,從而再次發送這個包。
在這裏插入圖片描述

擁塞控制

作用於網絡,防止過多的數據注入到網絡中,避免出現網絡負載過大的情況;常用方法:(1)慢開始,擁塞避免(2)快重傳,快恢復。

慢開始:

開始:cwnd的大小被設置爲最大報文段MSS的數值
發送方發送一個cwnd(congestion window)
收到確認後,cwnd數量加倍(1,2,4,8…)

但是:爲了防止cwnd增長過大引起網絡擁塞,設置一個慢開始門限ssthresh狀態變量 ,用法如下

 當 cwnd < ssthresh 時,使用上述的慢開始算法。

  當 cwnd > ssthresh 時,停止使用慢開始算法而改用擁塞避免算法。

  當 cwnd = ssthresh 時,既可使用慢開始算法,也可使用擁塞控制避免算法。

一個傳輸輪次所經歷的時間其實就是往返時間RTT。不過“傳輸輪次”更加強調:把擁塞窗口cwnd所允許發送的報文段都連續發送出去,並收到了對已發送的最後一個字節的確認。

擁塞避免算法:每經過一個往返時間RTT 就把發送方的cwnd+1而不是加倍。

無論是在慢開始還是擁塞避免,發送方判斷出現擁塞:將ssthresh設置爲出現擁塞時發送方窗口值的一半但不小於2,然後將cwnd重設爲1,執行慢開始算法。
在這裏插入圖片描述

快重傳算法

首先要求接收方每收到一個失序的報文段後就立即發出重複確認(爲的是使發送方及早知道有報文段沒有到達對方)而不要等到自己發送數據時才進行捎帶確認。

快重傳算法的規定,接收方應及時發送對M2的重複確認,這樣做可以讓發送方及早知道報文段M3沒有到達接收方。發送方接着發送了M5和M6。接收方收到這兩個報文後,也還要再次發出對M2的重複確認。

發送方只要一連收到三個重複確認就應當立即重傳對方尚未收到的報文段M3,而不必繼續等待M3設置的重傳計時器到期。由於發送方儘早重傳未被確認的報文段,因此採用快重傳後可以使整個網絡吞吐量提高約20%。

與快重傳配合使用的還有快恢復算法,其過程有以下兩個要點:

(1)當發送方連續收到三個重複確認,就執行“乘法減小”算法,把慢開始門限ssthresh減半。這是爲了預防網絡發生擁塞。
(2)由於發送方現在認爲網絡很可能沒有發生擁塞,因此與慢開始不同之處是現在不執行慢開始算法(即擁塞窗口cwnd現在不設置爲1),而是把cwnd值設置爲慢開始門限ssthresh減半後的數值,然後開始執行擁塞避免算法(“加法增大”),使擁塞窗口緩慢地線性增大。
在這裏插入圖片描述

HTTP緩存? 如果服務端想更新一個強制緩存,有什麼解決方案?

http緩存有:
強緩存:瀏覽器直接從本地緩存中獲取數據,不與服務器進行交互。
協商緩存:瀏覽器發送請求到服務器,服務器判定是否可使用本地緩存。
聯繫與區別:兩種緩存方式最終使用的都是本地緩存;前者無需與服務器交互,後者需要。
在這裏插入圖片描述
強制刷新:
這會使瀏覽器重新去服務器請求資源再加載。

IE強制刷新:CTRL+F5。

FireFox強制刷新:CTRL+F5,CTRL+SHIFT+R

Chrome強制刷新:CTRL+SHIFT+R

websocket是什麼

參考鏈接:http://www.ruanyifeng.com/blog/2017/06/tcp-protocol.html
https://blog.csdn.net/yechaodechuntian/article/details/25429143

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章