本文接上期內容。
TCP 協議如何保證可靠傳輸
1、應用資料被分割成 TCP 認為最適合傳送的資料塊。
2、TCP 給傳送的每一個包進行編號，接收方對資料包進行排序，把有序資料傳送給應用層。
3、校驗和： TCP 將保持它首部和資料的檢驗和，這是一個端到端的檢驗和，目的是檢測資料在傳輸過程中的任何變化。如果收到段的檢驗和有差錯，TCP 將丟棄這個報文段和不確認收到此報文段。
4、TCP 的接收端會丟棄重複的資料。
5、流量控制： TCP 連線的每一方都有固定大小的緩衝空間，TCP的接收端只允許傳送端傳送接收端緩衝區能接納的資料。當接收方來不及處理髮送方的資料，能提示傳送方降低傳送的速率，防止包丟失。TCP 使用的流量控制協議是可變大小的滑動視窗協議（TCP 利用滑動視窗實現流量控制）。
6、擁塞控制： 當網路擁塞時，減少資料的傳送。
7、停止等待協議：為了實現可靠傳輸，它的基本原理是每發完一個分組就停止傳送，等待對方確認，在收到確認後再發下一個分組。
8、超時重傳： 當 TCP 發出一個段後，它啟動一個定時器，等待目的端確認收到這個報文段；如果不能及時收到一個確認，將重發這個報文段。
停止等待協議
停止等待協議是為了實現可靠傳輸，它的基本原理是每發完一個分組就停止傳送，等待對方確認，在收到確認後再發下一個分組；在停止等待協議中，若接收方收到重複分組，就丟棄該分組，但同時還要傳送確認。
1、無差錯情況:
傳送方傳送分組，接收方在規定時間內收到，並且回覆確認，傳送方再次傳送。
2、出現差錯情況（超時重傳）:
停止等待協議中超時重傳是指只要超過一段時間仍然沒有收到確認，就重傳前面傳送過的分組（認為剛才傳送過的分組丟失了）。因此，每傳送完一個分組需要設定一個超時計時器，其重轉時間應比資料在分組傳輸的平均往返時間更長一些，這種自動重傳方式常稱為自動重傳請求ARQ 。另外，在停止等待協議中若收到重複分組，就丟棄該分組，但還要傳送確認，連續ARQ 協議可提高通道利用率。傳送維持一個傳送視窗，凡位於傳送視窗內的分組可連續傳送出去，而不需要等待對方確認；接收方一般採用累積確認，對按序到達的最後一個分組傳送確認，表明到這個分組位置的所有分組都已經正確收到了。
3、確認丟失和確認遲到
確認丟失：確認訊息在傳輸過程丟失
當A傳送M1訊息，B收到後，B向A傳送了一個M1確認訊息，但卻在傳輸過程中丟失。而A並不知道，在超時計時過後，A重傳M1訊息，B再次收到該訊息後採取以下兩點措施：
1、丟棄這個重複的M1訊息，不向上層交付。
2、向A傳送確認訊息。（不會認為已經傳送過了，就不再傳送。A能重傳，就證明B的確認訊息丟失）。
確認遲到 ：確認訊息在傳輸過程中遲到
A傳送M1訊息，B收到併傳送確認。在超時時間內沒有收到確認訊息，A重傳M1訊息，B仍然收到並繼續傳送確認訊息（B收到了2份M1）。此時，A收到了B第二次傳送的確認訊息，接著傳送其他資料。過了一會，A收到了B第一次傳送的對M1的確認訊息（A也收到了2份確認訊息）。處理如下：
1、A收到重複的確認後，直接丟棄。
2、收到重複的M1後，也直接丟棄重複的M1。
自動重傳請求 ARQ 協議
停止等待協議中超時重傳是指只要超過一段時間仍然沒有收到確認，就重傳前面傳送過的分組（認為剛才傳送過的分組丟失了）。因此每傳送完一個分組需要設定一個超時計時器，其重轉時間應比資料在分組傳輸的平均往返時間更長一些。這種自動重傳方式常稱為自動重傳請求ARQ。
優點： 簡單
缺點： 通道利用率低
連續ARQ協議
連續 ARQ 協議可提高通道利用率。傳送方維持一個傳送視窗，凡位於傳送視窗內的分組可以連續傳送出去，而不需要等待對方確認。接收方一般採用累計確認，對按序到達的最後一個分組傳送確認，表明到這個分組為止的所有分組都已經正確收到了。
優點： 通道利用率高，容易實現，即使確認丟失，也不必重傳。
**缺點：**不能向傳送方反映出接收方已經正確收到的所有分組的資訊。 比如：傳送方傳送了 5條 訊息，中間第三條丟失（3號），這時接收方只能對前兩個傳送確認；傳送方無法知道後三個分組的下落，而只好把後三個全部重傳一次。這也叫 Go-Back-N（回退 N），表示需要退回來重傳已經傳送過的 N 個訊息。
滑動視窗
1、TCP 利用滑動視窗實現流量控制的機制。
2、滑動視窗是一種流量控制技術。早期的網路通訊中，通訊雙方不會考慮網路的擁擠情況直接傳送資料。由於大家不知道網路擁塞狀況，同時傳送資料，導致中間節點阻塞掉包，誰也發不了資料，所以就有了滑動視窗機制來解決此問題。
3、TCP 中採用滑動視窗來進行傳輸控制，滑動視窗的大小意味著接收方還有多大的緩衝區可以用於接收資料。傳送方可以通過滑動視窗的大小來確定應該傳送多少位元組的資料，當滑動視窗為0時，傳送方一般不能再傳送資料包。但有兩種情況除外，一種情況是可以傳送緊急資料，例如，允許使用者終止在遠端機上的執行程式；另一種情況是傳送方可以傳送一個1位元組的資料包來通知接收方重新宣告它希望接收的下一位元組及傳送方的滑動視窗大小。
流量控制
1、TCP 利用滑動視窗實現流量控制。
2、流量控制是為了控制傳送方傳送速率，保證接收方來得及接收。
3、接收方傳送的確認報文中的視窗欄位可以用來控制傳送方視窗大小，從而影響傳送方的傳送速率。將視窗欄位設定為 0，則傳送方不能傳送資料。
擁塞控制
在某段時間，若對網路中某一資源的需求超過了該資源所能提供的可用部分，網路的效能就要變壞，這種情況就叫擁塞。擁塞控制是為了防止過多的資料注入到網路中，這樣可以使網路中的路由器或鏈路不致過載。擁塞控制所要做的有一個前提，就是網路能夠承受現有的網路負荷。擁塞控制是一個全域性性的過程，涉及到所有的主機、所有的路由器、以及與降低網路傳輸效能有關的所有因素。相反，流量控制往往是點對點通訊量的控制，是端到端的問題，流量控制所要做到的是抑制傳送端傳送資料的速率，以便使接收端來得及接收。
為了進行擁塞控制，TCP 傳送方要維持一個擁塞視窗的狀態變數，擁塞控制視窗的大小取決於網路的擁塞程度，並且動態變化，傳送方讓自己的傳送視窗取為擁塞視窗和接收方的接受視窗中較小的一個。
TCP的擁塞控制採用了四種演算法，即 慢開始 、 擁塞避免 、快重傳 和 快恢復。在網路層也可以使路由器採用適當的分組丟棄策略（如主動佇列管理 AQM），以減少網路擁塞的發生。
1、慢開始：慢開始演算法的思路是當主機開始傳送資料時，如果立即把大量資料位元組注入到網路，那麼可能會引起網路阻塞，因為現在還不知道網路的符合情況。經驗表明，較好的方法是先探測一下，即由小到大逐漸增大傳送視窗，也就是由小到大逐漸增大擁塞視窗數值。cwnd初始值為1，每經過一個傳播輪次，cwnd加倍。
2、擁塞避免：擁塞避免演算法的思路是讓擁塞視窗cwnd緩慢增大，即每經過一個往返時間RTT就把傳送放的cwnd加1。
3、快重傳與快恢復：在 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協議，會在響應頭加入這行程式碼：
（1）Connection:keep-alive
（2）複製程式碼
在使用長連線的情況下，當一個網頁開啟完成後，客戶端和伺服器之間用於傳輸HTTP資料的TCP連線不會關閉，客戶端再次訪問這個伺服器時，會繼續使用這一條已經建立的連線。Keep-Alive不會永久保持連線，它有一個保持時間，可以在不同的伺服器軟體（如Apache）中設定這個時間。實現長連線需要客戶端和服務端都支援長連線。
HTTP協議的長連線和短連線，實質上是TCP協議的長連線和短連線。
如果對java微服務、分散式、高併發、高可用、大型網際網路架構技術、面試經驗交流等等感興趣的同學，可以關注我，我會不定期免費發放資料連結，如果你有好的學習資料可以私聊發我，我會註明出處之後分享給大家。歡迎分享，歡迎評論，歡迎轉發，需要資料的同學Java後端技術群：819940388，或關注微信公眾號：Java資訊庫，回覆“架構”，免費的大型網際網路Java技術視訊分享給大家。