TCP與UDP的區別
TCP的三次握手和四次揮手
[TCP三次握手 四次揮手](https://o-fawkes.blog.csdn.net/article/details/77413870)
TCP流量控制
TCP擁塞控制
慢開始：乘法增加
擁塞避免：加法增大
快重傳
快恢復
騰訊面試十分注重網絡基礎知識，問的幾乎都是一些細節知識，所以你如果想進入騰訊的話，網絡知識一定要紮實，文章是我總結的一些騰訊面試經常問到的一些細節知識，希望對你有幫助，覺得不錯的，可以點贊收藏
TCP與UDP的區別
TCP面向連接的, 傳輸數據時，需先進行三次握手,建立連接，UDP是無連接的，發送數據之前不需要建立連接
TCP通過確認和重傳機制，提供可靠的服務。即通過TCP連接傳送的數據，無差錯，不丟失，不重複，且按序到達，而UDP不保證可靠傳輸,只是儘可能得交付
TCP面向字節流，即將數據看成一連串無結構的字節流。UDP是面向報文的,UDP沒有擁塞控制，因此網絡出現擁塞不會使源主機的發送速率降低（對實時應用很有用，如IP電話，實時視頻會議等）
每一條TCP連接只能是點到點的;UDP支持一對一，一對多，多對一和多對多的交互通信
TCP的邏輯通信信道是全雙工的可靠信道，UDP則是不可靠信道
TCP的三次握手和四次揮手
TCP是面向連接的字節流協議，是全雙工的。
三次握手
例圖：
第一次握手：客戶端發送一個連接請求,測試服務端是否可以正常通信(SYN位置爲1)
第二次握手：服務端確認客戶端的連接請求，並且同時發送一個請求,測試客戶端是否可以正常通信(SYN位置爲1, ACK位置爲1)
第三次握手：客戶端接受到服務端的確認(瞭解到服務器可以正常通信)，之後發送一個ACK,告訴服務器我可以正常通信(ACK位置爲1)
如果服務器沒有收到客服端的ACK，會超時重傳自己的SYN請求，一直到收到服務端的ACK爲止
爲什麼一定是三次握手呢？
考慮兩次握手：客戶端發送一個連接請求，服務端接受到連接請求，發送一個確認,此時服務端已經確認自己有接受報文的能力，認爲連接已經建立，所以開始爲已建立的連接分配資源，如果服務端發送的確認丟失，客戶端就無從知道連接已經建立。如果存在大量這種情況，就有可能會造成服務器崩潰。
爲什麼不是四次呢？三次都已經夠了，爲什麼還要多加一次
四次揮手
例圖：
第一次揮手：客戶端的數據到達尾部，向服務端發送請求斷開(FIN位置1)
相當於我這邊數據傳送完了，準備斷開連接了
第二次揮手：TCP的連接是全雙工的雙向連接，關閉必須從兩邊關閉，服務端收到FIN標誌位後，並不會立即向客服端發送FIN標誌位，而是發送一個ACK的應答信息
相當於：你請求關閉的請求我已經收到，但我可能還有數據沒有接受完(數據傳送需要時間)，你再等下，等我數據傳輸完成了我就告訴你
第三次揮手：服務端接受數據完成，向服務端發送一個FIN=1
第四次揮手：客戶端接收到服務端發送來的斷開連接請求，發送一個確認。並把自己設置成TIME_WAIT狀態，並啓動計時器
如果服務端沒有收到ACK, 服務端的TCP的定時器到達後，會要求客戶端重新發送ACK, 服務端收到ACK就斷開連接，當客戶端等待2MSL(2倍報文最大生存時間)後，沒有收到服務端的重傳請求後，就知道服務端已經接收到ACK,此時關閉自己的連接
TCP流量控制
很多人會將流量控制和擁塞控制搞混，所以單獨拎出來，考究細節
流量控制：如果發送者發送數據過快，接收者來不及接收，那麼就會有分組丟失。流量控制策略就是控制發送者的發送速度，使得接收者來得及接收,達到不丟失分組的目的。流量控制是構成TCP可靠性的一方面。
流量控制主要使用滑動窗口機制實現。下面以上圖講解滑動窗口(也叫接受窗口rwnd)的細節
主機A向主機B發送數據，開始雙方確定的窗口值爲400字節,這兩個是前提條件。開始A發送了200字節，之後發生了分組丟失現象，B調整接受窗口大小爲300字節。之後A又連續發送了300字節。此時A已經不能發送數據，需等待B的窗口信號。之後B調整窗口爲100字節。接收到100字節數據後，調整窗口值爲0，表示暫時不想接受數據。總共B調整了三次窗口大小，進行了三次流量控制
假如，B向A發送了零窗口的報文段後不久，B的接收緩存又有了一些存儲空間。於是B向A發送了rwind=400的報文段，然而這個報文段在傳送中丟失 了。A一直等待收到B發送的非零窗口的通知，而B也一直等待A發送的數據。這樣就死鎖了。爲了解決這種死鎖狀態，TCP爲每個連接設有一個持續計時器。只 要TCP連接的一方收到對方的零窗口通知，就啓動持續計時器，若持續計時器設置的時間到期，就發送一個零窗口探測報文段（僅攜帶1字節的數據），而對方就在確認這個探測報文段時給出了現在的窗口值。
TCP擁塞控制
擁塞控制，大家都能背出來，什麼慢開始、擁塞避免、快重傳、快恢復，大家都耳熟能詳，但是有些細節問題，可以大家沒有留意，比如快重傳階段後，爲什麼不直接進入慢開始階段，而是進入擁塞避免階段？
擁塞的概念：在某段時間，對網絡中的某一資源的需求超過了該資源所能提供的可用部分，網絡的性能就要變化，這種情況叫擁塞。網絡擁塞往往是由許多因素引起的，簡單的提高節點處理機的速度或者擴大結點緩存的存儲空間並不能解決擁塞問題。擁塞問題的是指往往是整個系統的各個部分不匹配，只有各個部分平衡了，問題纔會得到解決。
擁塞控制：防止過多的數據注入到網絡，導致網絡中的路由器或鏈路過載。
流量控制和擁塞控制的區別：可以看出流量控制是一個端到端的問題，而擁塞控制是一個全局性問題，設計到所有的主機、所有的路由器。
慢開始：乘法增加
發送方維持一個擁塞窗口cwnd，大小取決於網絡的擁塞程度，動態地在變化。發送窗口小於等於擁塞窗口，而發送窗口一定不能超過接收窗口。發送方控制擁塞窗口的原則是：只要網絡沒有出現擁塞，擁塞窗口就增大一些，以便把更多的分組發送出去。但是隻要網絡出現擁塞，擁塞窗口就減小一些，以減少注入到網絡的分組數。
開始時，如果發送大量數據包，容易導致網絡中路由器緩衝空間耗盡，從而發生擁塞。所以新建連接時，cwnd初始化爲1個最大報文段(MSS)大小，每經過一個迭代，擁塞窗口就乘以2，所以也稱爲乘法增加階段。擁塞窗口不可能一直增大，所以一般會設置一個慢開始門限ssthresh.
當cwnd<ssthresh時，使用慢開始算法。
當cwnd>ssthresh時，改用擁塞避免算法。
擁塞避免：加法增大
一旦達到慢開始的初始門限ssthresh,就進入了擁塞避免階段。每一個迭代，擁塞窗口加1，而不是加一倍
快重傳
快重傳算法規定，發送方只要一連收到三個重複確認就應當立即重傳對方尚未收到的報文段，而不必繼續等待設置的重傳計時器時間到期。快重傳策略是爲了防止TCP連接因等待重傳計時器超時而空閒較長的時間。
快恢復
快重傳和快恢復是搭配使用的，快重傳完成後，立即執行快恢復算法。將ssthresh門限設置爲當前擁塞窗口的一般，之後將擁塞窗口設置爲新的ssthresh門限(即減半), 進入擁塞避免階段。
這裏可能會有人有疑問，爲什麼不直接進入慢開始階段，更徹底得避免擁塞。主要的原因是考慮到如果網絡出現擁塞得話，就不會收到多次重複確認，所以發送方認爲網絡可能沒有出現擁塞，所以不執行慢開始算法，而是將cwnd設置爲新得ssthresh門限，執行擁塞避免算法
————————————————
版權聲明：本文爲CSDN博主「zycxnanwang」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/zycxnanwang/article/details/105911876