接上期的
四 TCP 協議如何保證可靠傳輸
- 應用數據被分割成 TCP 認為最適合發送的數據塊。
- TCP 給發送的每一個包進行編號，接收方對數據包進行排序，把有序數據傳送給應用層。
- 校驗和： TCP 將保持它首部和數據的檢驗和。這是一個端到端的檢驗和，目的是檢測數據在傳輸過程中的任何變化。如果收到段的檢驗和有差錯，TCP 將丟棄這個報文段和不確認收到此報文段。
- TCP 的接收端會丟棄重複的數據。
- 流量控制： TCP 連接的每一方都有固定大小的緩衝空間，TCP的接收端只允許發送端發送接收端緩衝區能接納的數據。當接收方來不及處理發送方的數據，能提示發送方降低發送的速率，防止包丟失。TCP 使用的流量控制協議是可變大小的滑動窗口協議。 （TCP 利用滑動窗口實現流量控制）
- 擁塞控制： 當網絡擁塞時，減少數據的發送。
- 停止等待協議 也是為了實現可靠傳輸的，它的基本原理就是每發完一個分組就停止發送，等待對方確認。在收到確認後再發下一個分組。 超時重傳： 當 TCP 發出一個段後，它啟動一個定時器，等待目的端確認收到這個報文段。如果不能及時收到一個確認，將重發這個報文段。
停止等待協議
- 停止等待協議是為了實現可靠傳輸的，它的基本原理就是每發完一個分組就停止發送，等待對方確認。在收到確認後再發下一個分組；
- 在停止等待協議中，若接收方收到重複分組，就丟棄該分組，但同時還要發送確認；
1) 無差錯情況:
發送方發送分組,接收方在規定時間內收到,並且回覆確認.發送方再次發送。
2) 出現差錯情況（超時重傳）:
停止等待協議中超時重傳是指只要超過一段時間仍然沒有收到確認，就重傳前面發送過的分組（認為剛才發送過的分組丟失了）。因此每發送完一個分組需要設置一個超時計時器，其重轉時間應比數據在分組傳輸的平均往返時間更長一些。這種自動重傳方式常稱為 自動重傳請求 ARQ 。另外在停止等待協議中若收到重複分組，就丟棄該分組，但同時還要發送確認。連續 ARQ 協議 可提高信道利用率。發送維持一個發送窗口，凡位於發送窗口內的分組可連續發送出去，而不需要等待對方確認。接收方一般採用累積確認，對按序到達的最後一個分組發送確認，表明到這個分組位置的所有分組都已經正確收到了。
3) 確認丟失和確認遲到
- 確認丟失：確認消息在傳輸過程丟失
- 當A發送M1消息，B收到後，B向A發送了一個M1確認消息，但卻在傳輸過程中丟失。而A並不知道，在超時計時過後，A重傳M1消息，B再次收到該消息後採取以下兩點措施：
- 丟棄這個重複的M1消息，不向上層交付。
- 向A發送確認消息。（不會認為已經發送過了，就不再發送。A能重傳，就證明B的確認消息丟失）。
- 確認遲到 ：確認消息在傳輸過程中遲到
- A發送M1消息，B收到併發送確認。在超時時間內沒有收到確認消息，A重傳M1消息，B仍然收到並繼續發送確認消息（B收到了2份M1）。此時A收到了B第二次發送的確認消息。接著發送其他數據。過了一會，A收到了B第一次發送的對M1的確認消息（A也收到了2份確認消息）。處理如下：
- A收到重複的確認後，直接丟棄。
- B收到重複的M1後，也直接丟棄重複的M1。
自動重傳請求 ARQ 協議
停止等待協議中超時重傳是指只要超過一段時間仍然沒有收到確認，就重傳前面發送過的分組（認為剛才發送過的分組丟失了）。因此每發送完一個分組需要設置一個超時計時器，其重轉時間應比數據在分組傳輸的平均往返時間更長一些。這種自動重傳方式常稱為自動重傳請求ARQ。
優點： 簡單
缺點： 信道利用率低
連續ARQ協議
連續 ARQ 協議可提高信道利用率。發送方維持一個發送窗口，凡位於發送窗口內的分組可以連續發送出去，而不需要等待對方確認。接收方一般採用累計確認，對按序到達的最後一個分組發送確認，表明到這個分組為止的所有分組都已經正確收到了。
優點： 信道利用率高，容易實現，即使確認丟失，也不必重傳。
缺點： 不能向發送方反映出接收方已經正確收到的所有分組的信息。 比如：發送方發送了 5條 消息，中間第三條丟失（3號），這時接收方只能對前兩個發送確認。發送方無法知道後三個分組的下落，而只好把後三個全部重傳一次。這也叫 Go-Back-N（回退 N），表示需要退回來重傳已經發送過的 N 個消息。
滑動窗口
- TCP 利用滑動窗口實現流量控制的機制。
- 滑動窗口（Sliding window）是一種流量控制技術。早期的網絡通信中，通信雙方不會考慮網絡的擁擠情況直接發送數據。由於大家不知道網絡擁塞狀況，同時發送數據，導致中間節點阻塞掉包，誰也發不了數據，所以就有了滑動窗口機制來解決此問題。
- TCP 中採用滑動窗口來進行傳輸控制，滑動窗口的大小意味著接收方還有多大的緩衝區可以用於接收數據。發送方可以通過滑動窗口的大小來確定應該發送多少字節的數據。當滑動窗口為 0 時，發送方一般不能再發送數據報，但有兩種情況除外，一種情況是可以發送緊急數據，例如，允許用戶終止在遠端機上的運行進程。另一種情況是發送方可以發送一個 1 字節的數據報來通知接收方重新聲明它希望接收的下一字節及發送方的滑動窗口大小。
流量控制
- TCP 利用滑動窗口實現流量控制。
- 流量控制是為了控制發送方發送速率，保證接收方來得及接收。
- 接收方發送的確認報文中的窗口字段可以用來控制發送方窗口大小，從而影響發送方的發送速率。將窗口字段設置為 0，則發送方不能發送數據。
擁塞控制
在某段時間，若對網絡中某一資源的需求超過了該資源所能提供的可用部分，網絡的性能就要變壞。這種情況就叫擁塞。擁塞控制就是為了防止過多的數據注入到網絡中，這樣就可以使網絡中的路由器或鏈路不致過載。擁塞控制所要做的都有一個前提，就是網絡能夠承受現有的網絡負荷。擁塞控制是一個全局性的過程，涉及到所有的主機，所有的路由器，以及與降低網絡傳輸性能有關的所有因素。相反，流量控制往往是點對點通信量的控制，是個端到端的問題。流量控制所要做到的就是抑制發送端發送數據的速率，以便使接收端來得及接收。
為了進行擁塞控制，TCP 發送方要維持一個 擁塞窗口(cwnd) 的狀態變量。擁塞控制窗口的大小取決於網絡的擁塞程度，並且動態變化。發送方讓自己的發送窗口取為擁塞窗口和接收方的接受窗口中較小的一個。
TCP的擁塞控制採用了四種算法，即 慢開始 、 擁塞避免 、快重傳 和 快恢復。在網絡層也可以使路由器採用適當的分組丟棄策略（如主動隊列管理 AQM），以減少網絡擁塞的發生。
- 慢開始： 慢開始算法的思路是當主機開始發送數據時，如果立即把大量數據字節注入到網絡，那麼可能會引起網絡阻塞，因為現在還不知道網絡的符合情況。經驗表明，較好的方法是先探測一下，即由小到大逐漸增大發送窗口，也就是由小到大逐漸增大擁塞窗口數值。cwnd初始值為1，每經過一個傳播輪次，cwnd加倍。
- 擁塞避免： 擁塞避免算法的思路是讓擁塞窗口cwnd緩慢增大，即每經過一個往返時間RTT就把發送放的cwnd加1.
- 快重傳與快恢復： 在 TCP/IP 中，快速重傳和恢復（fast retransmit and recovery，FRR）是一種擁塞控制算法，它能快速恢復丟失的數據包。沒有 FRR，如果數據包丟失了，TCP 將會使用定時器來要求傳輸暫停。在暫停的這段時間內，沒有新的或複製的數據包被髮送。有了 FRR，如果接收機接收到一個不按順序的數據段，它會立即給發送機發送一個重複確認。如果發送機接收到三個重複確認，它會假定確認件指出的數據段丟失了，並立即重傳這些丟失的數據段。有了 FRR，就不會因為重傳時要求的暫停被耽誤。 當有單獨的數據包丟失時，快速重傳和恢復（FRR）能最有效地工作。當有多個數據信息包在某一段很短的時間內丟失時，它則不能很有效地工作。
五 在瀏覽器中輸入url地址 ->> 顯示主頁的過程（面試常客）
打開一個網頁，整個過程會使用哪些協議
六 狀態碼
七 各種協議與HTTP協議之間的關係
一般面試官會通過這樣的問題來考察你對計算機網絡知識體系的理解。
八 HTTP長連接、短連接
在HTTP/1.0中默認使用短連接。也就是說，客戶端和服務器每進行一次HTTP操作，就建立一次連接，任務結束就中斷連接。當客戶端瀏覽器訪問的某個HTML或其他類型的Web頁中包含有其他的Web資源（如JavaScript文件、圖像文件、CSS文件等），每遇到這樣一個Web資源，瀏覽器就會重新建立一個HTTP會話。
而從HTTP/1.1起，默認使用長連接，用以保持連接特性。使用長連接的HTTP協議，會在響應頭加入這行代碼：
- Connection:keep-alive
- 複製代碼
在使用長連接的情況下，當一個網頁打開完成後，客戶端和服務器之間用於傳輸HTTP數據的TCP連接不會關閉，客戶端再次訪問這個服務器時，會繼續使用這一條已經建立的連接。Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同的服務器軟件（如Apache）中設定這個時間。實現長連接需要客戶端和服務端都支持長連接。
HTTP協議的長連接和短連接，實質上是TCP協議的長連接和短連接。
—— 《HTTP長連接、短連接究竟是什麼？》
如果對java微服務、分佈式、高併發、高可用、大型互聯網架構技術、面試經驗交流等等感興趣的老鐵們，可以關注我的頭條號。我會在微頭條不定期的發放免費的資料鏈接，這些資料都是從各個技術網站蒐集、整理出來的，如果你有好的學習資料可以私聊發我，我會註明出處之後分享給大家。歡迎分享，歡迎評論，歡迎轉發。需要資料的同學可以關注我的微頭條 獲取資料鏈接。
閱讀更多 架構師交流圈 的文章
