運輸層：

11、TCP與UDP的區別及應用場景

TCP和UDP的區別：
TCP是面向連線的傳輸層協議，傳輸資料之前必須先建立連線；UDP是無連線傳輸。
TCP是點對點服務，一條TCP連線只有連個斷點；UDP是多對多連線互動通訊。
TCP是可靠連線：無差錯、無重複、無丟失、按序到達；UDP：盡最大努力交付，不保證可靠性。
TCP由擁塞控制和流量控制保證資料傳輸的安全性；UDP無擁塞控制，網路擁塞不影響傳送速率。
TCP是動態報文。即TCP報文長度是根據接受方視窗大小和當前網路擁塞情況來決定的；UDP是面向報文的，不合並、不拆分，保留上面下來的報文邊界。
TCP首部開銷大，20個位元組；UDP首部僅有8個位元組（源埠、目的埠、資料長度、校驗和）

TCP和UDP的使用場景：
TCP傳輸資料可靠但是速度較慢，UDP傳輸速度快但不可靠。因此在選用具體協議是根據資料通訊要求來決定。
若資料通訊完整性需要讓位與通訊實時性，則選用TCP(傳檔案、重要狀態)；反之選用UDP（視訊、實時通訊）。

12、TCP首部報文格式（SYN、ACK、FIN、RST必須知道）

URG 指示報文段裡存在著被髮送方的上層實體標記為”緊急”資料，當URG=1時，其後的緊急指標指示緊急資料在當前資料段中的位置(相對於當前序列號的位元組偏移量)，TCP接收方必須通知上層實體。
ACK 當ACK=0時，表示該資料段不包含確認資訊，當ACK=1時，表示該報文段包括一個對已被成功接收報文段的確認。
PSH 當PSH=1時，接收方在收到資料後立即將資料交給上層，而不是直到整個緩衝區滿。
RST 用於重置一個已經混亂的連線(如主崩潰)，也可用於拒絕一個無效的資料段或者拒絕一個連線請求。一般而言，如果你得到的資料段被設定了RST位，那說明你這一端有問題了。
SYN 用於建立連線過程，在連線請求中，SYN=1和ACK=0表示該資料段沒有使用捎帶的確認域，而連線應答捎帶一個確認，即SYN=1和ACK=1。注：捎帶是指對客戶機到伺服器資料的確認被裝載在一個承載伺服器到客戶機的資料
FIN 用於釋放一個連線，表示傳送方已經沒有資料要傳輸了。此時，接收方可能繼續接收資料，好在SYN和FIN資料段都有序列號，從而保證了這兩種資料段以正確順序被處理

13、TCP滑動視窗原理

TCP 協議通過採用滑動視窗的方式控制資料流的傳輸。在傳輸層中, 資料按照一定的
　　格式打成大小相同的包。每一個滑動視窗中包含一定數目的資料包, 滑動視窗的大小可以
　　進行調整。每臺網絡上的主機維護一個傳送視窗和一個接收視窗。傳送方一次可傳送相當於滑動視窗大小的資料包數目, 並在每個資料包前新增包頭資訊, 然後等待接收方返回確認資訊。由於TCP 是面向連線的協議, 可以保證資料傳輸的完整性和準確性, 當傳輸過程中發生丟包時, 接收方會要求傳送方從斷點處重傳資料。
　　當TCP 從應用層中接收到資料時, TCP 將一個帶序列號的報頭加入資料包並將其交給
　　IP, 由IP 將它傳送到目標主機。
　　當每一個數據包傳送時, 源主機設定重發計時器, 描述在重新發送資料包前將等待
　　ACK 的時間。在一般情況下, 當第一次傳送失敗後, 重發計時器的重試時間將設定為前一
　　次的兩倍。在傳送視窗中有每一個數據包的備份, 直到收到ACK。
　　當資料包到達目的主機接收視窗, 它們按照序列號放置。當目的主機接收到連續的數
　　據段時, 就向源主機發送一個關於資料的認可( ACK) 的應答報文, 其中帶有當前視窗尺寸。一旦源主機接收到資料包並認可, 傳送視窗將進行滑動。如果在重發計時器設定的時
　　間內, 源主機沒有接收到對現存資料的認可, 資料將重新傳送。重發資料包將加重網路和源主機的負擔。

14、TCP超時重傳時間選擇

第二次的RTT1要大於第一次的RTT0，於是第一次的RT0的選擇值在這裡就不適合了。針對這一個複雜的問題，我們不能用某次測量的值來計算超時重傳時間RTO。這時就需要借鑑中華名族的優秀傳統-折中。利用每次測量的RTT樣本，然後取一個加權平均值RTTs。
新的加權平均往返時間RTTs = （1 - a）x 舊的RTTs + a x新的RTT樣本。(其中0 < a < 1)
如果 a很小，趨近於0，說明新的RTT樣本作用不大。
如果 a 很大，趨近於1，則說明舊的RTTs對新的RTTs的影響很小。

現在通用的a的取值為1/8，即0.125。
顯然，新的RT0的值應該要略大於RTTs的值。
RTO = RTTs + 4 x RTTd（RTTd為RTT偏差的加權平均）

RTTd1 = RTT1 / 2
新的RTTd = (1-B) x 舊的RTTd+B x |RTTs-新的RTT樣本|。 (其中0< B<1)
B的建議取值為1/4，即0.25

15、TCP流程控制

tcp是利用滑動視窗機制就可以實施流量控制。原理這就是運用TCP報文段中的視窗大小欄位來控制，傳送方的傳送視窗不可以大於接收方發回的視窗大小。

16、TCP擁塞控制（一定要弄清楚與流量控制的區別）

如果把視窗定義的很大，傳送端連續傳送大量的資料，可能會造成網路的擁堵，甚至造成網路的癱瘓。所以TCP為了防止這種情況進行擁塞控制。

慢啟動：定義擁塞視窗，一開始將該視窗大小設為1，之後每次收到確認應答（經過一個RTT），將擁塞視窗大小*2。
擁塞避免：設定慢啟動閾值，一般開始設定為65536。擁塞避免是當擁塞視窗大小達到這個閾值，擁塞視窗的值不在指數上升，而是加法增加。將報文段的超市重傳看作擁塞，則一旦發生擁塞，先將閾值設為當前視窗大小的一般，並且將視窗大小設為1，再次進入慢啟動過程。
快速重傳：在遇到3此重複應答時，代表收到3個報文段，但是之前的1個段丟失了便對它進行立即重傳。然後先將閾值設為當前視窗大小的一般，然後將擁塞視窗大小設為慢啟動閾值+3的大小。
這樣：在TCP通訊是，網路吞吐量呈現逐漸的上升，並且隨著擁堵來減低吞吐量，再進入慢慢上升的過程，網路不會輕易發生癱瘓。

17、TCP三次握手及狀態變化。為啥不是兩次握手？

確保自己訊息已發出和已收到

18、TCP四次揮手及狀態變化。為啥不是三次揮手？

關閉連線可能不在同一時間點

19、TCP連線釋放中TIME_WAIT狀態的作用

原因1：防止連線關閉時四次揮手中的最後一次ACK丟失：

原因2：防止新連線收到舊連結的TCP報文：

21、TCP粘包

TCP粘包就是指傳送方傳送的若干包資料到達接收方時粘成了一包，從接收緩衝區來看，後一包資料的頭緊接著前一包資料的尾，出現粘包的原因是多方面的，可能是來自發送方，也可能是來自接收方。

造成TCP粘包的原因
（1）傳送方原因

TCP預設使用Nagle演算法（主要作用：減少網路中報文段的數量），而Nagle演算法主要做兩件事：

只有上一個分組得到確認，才會傳送下一個分組
收集多個小分組，在一個確認到來時一起傳送
Nagle演算法造成了傳送方可能會出現粘包問題

（2）接收方原因

TCP接收到資料包時，並不會馬上交到應用層進行處理，或者說應用層並不會立即處理。實際上，TCP將接收到的資料包儲存在接收快取裡，然後應用程式主動從快取讀取收到的分組。這樣一來，如果TCP接收資料包到快取的速度大於應用程式從快取中讀取資料包的速度，多個包就會被快取，應用程式就有可能讀取到多個首尾相接粘到一起的包。

22、TCP心跳包

客戶端連線上服務端以後，服務端維護一個線上使用者字典，客戶端每隔一段時間，向伺服器傳送一個心跳包，伺服器接收到包以後，字典資料的值都會更新為0；一旦服務端超過規定時間沒有接收到客戶端發來的包，字典資料將會遞增加一，當字典資料的值累計大於等於三，則視為掉線。使用者掉線檢測功能。今天我們就通過使用自定義的HeartBeat方式來檢測使用者的掉線情況

23、路由器與交換機的區別

路由器：定址，轉發（依靠 IP 地址）
交換機：過濾，轉發（依靠 MAC 地址）

我們可以看出這兩者的主要工作就是轉發資料，但是不同之處是，依靠的地址不同，這是一個根本區別！

路由器內有一份路由表，裡面有它的定址資訊（就像是一張地圖），它收到網路層的資料報後，會根據路由表和選路演算法將資料報轉發到下一站（可能是路由器、交換機、目的主機）

交換機內有一張MAC表，裡面存放著和它相連的所有裝置的MAC地址，它會根據收到的資料幀的首部資訊內的目的MAC地址在自己的表中查詢，如果有就轉發，如果沒有就放棄

24、UDP如何實現可靠傳輸

只能通過應用層來實現了。實現的方式可以參照tcp可靠性傳輸的方式，只是實現不在傳輸層，實現轉移到了應用層。

實現確認機制、重傳機制、視窗確認機制。

如果你不利用linux協議棧以及上層socket機制，自己通過抓包和發包的方式去實現可靠性傳輸，那麼必須實現如下功能：

傳送：包的分片、包確認、包的重發

接收：包的調序、包的序號確認

目前有如下開源程式利用udp實現了可靠的資料傳輸。分別為RUDP、RTP、UDT。

3.1RUDP
RUDP 提供一組資料服務質量增強機制，如擁塞控制的改進、重發機制及淡化伺服器演算法等，從而在包丟失和網路擁塞的情況下， RTP 客戶機（實時位置）面前呈現的就是一個高質量的 RTP 流。在不干擾協議的實時特性的同時，可靠 UDP 的擁塞控制機制允許 TCP 方式下的流控制行為。

3.2RTP
實時傳輸協議（RTP）為資料提供了具有實時特徵的端對端傳送服務，如在組播或單播網路服務下的互動式視訊音訊或模擬資料。應用程式通常在 UDP 上執行 RTP 以便使用其多路結點和校驗服務；這兩種協議都提供了傳輸層協議的功能。但是 RTP 可以與其它適合的底層網路或傳輸協議一起使用。如果底層網路提供組播方式，那麼 RTP 可以使用該組播表傳輸資料到多個目的地。

RTP 本身並沒有提供按時傳送機制或其它服務質量（QoS）保證，它依賴於底層服務去實現這一過程。 RTP 並不保證傳送或防止無序傳送，也不確定底層網路的可靠性。 RTP 實行有序傳送， RTP 中的序列號允許接收方重組傳送方的包序列，同時序列號也能用於決定適當的包位置，例如：在視訊解碼中，就不需要順序解碼。

3.3UDT
基於UDP的資料傳輸協議（UDP-basedData Transfer Protocol，簡稱UDT）是一種網際網路資料傳輸協議。UDT的主要目的是支援高速廣域網上的海量資料傳輸，而網際網路上的標準資料傳輸協議TCP在高頻寬長距離網路上效能很差。顧名思義，UDT建於UDP之上，並引入新的擁塞控制和資料可靠性控制機制。UDT是面向連線的雙向的應用層協議。它同時支援可靠的資料流傳輸和部分可靠的資料報傳輸。由於UDT完全在UDP上實現，它也可以應用在除了高速資料傳輸之外的其它應用領域，例如點到點技術（P2P），防火牆穿透，多媒體資料傳輸等等。