傳輸層(TCP/UDP)
TCP
1. 傳輸層：（段或數據報）
-
傳輸層負責將上層數據分段並提供端到端的、可靠的或不可靠的傳輸以及端到端的差錯控制和流量控制；
-
包含的主要協議：TCP協議（Transmission Control Protocol，傳輸控制協議）、UDP協議（User Datagram Protocol，用戶數據報協議）；
-
重要設備：。
2. 描述TCP頭部？
-
至少20個字節（20字節的固定首部）
-
序號（32bit）：傳輸方向上字節流的字節編號。初始時序號會被設置一個隨機的初始值（ISN），之後每次發送數據時，序號值 = ISN + 數據在整個字節流中的偏移。假設A -> B且ISN = 1024，第一段數據512字節已經到B，則第二段數據發送時序號爲1024 + 512。用於解決網絡包亂序問題。
-
確認號（32bit）：接收方對發送方TCP報文段的響應，其值是收到的序號值 + 1。
-
首部長（4bit）：標識首部有多少個4字節 * 首部長，最大爲15，即60字節。
-
標誌位（6bit）：
-
URG：標誌緊急指針是否有效。
-
ACK：標誌確認號是否有效（確認報文段）。用於解決丟包問題。
-
PSH：提示接收端立即從緩衝讀走數據。
-
RST：表示要求對方重新建立連接（復位報文段）。
-
SYN：表示請求建立一個連接（連接報文段、請求同步標誌）。
-
FIN：表示關閉連接（斷開報文段）。
-
窗口（16bit）：接收窗口。用於告知對方（發送方）本方的緩衝還能接收多少字節數據。用於解決流控。
-
校驗和（16bit）：接收端用CRC檢驗整個報文段有無損壞。
-
3. 三次握手過程？
-
第一次：客戶端發含SYN位，SEQ_NUM = S的包到服務器。（客 -> SYN_SEND）
-
第二次：服務器發含ACK，SYN位且ACK_NUM = S + 1，SEQ_NUM = P的包到客戶機。（服 -> SYN_RECV）
-
第三次：客戶機發送含ACK位，ACK_NUM = P + 1的包到服務器。（客 -> ESTABLISH，服 -> ESTABLISH）
4. 四次揮手過程？
-
第一次：客戶機發含FIN位，SEQ = Q的包到服務器。（客 -> FIN_WAIT_1）
-
第二次：服務器發送含ACK且ACK_NUM = Q + 1的包到服務器。（服 -> CLOSE_WAIT，客 -> FIN_WAIT_2）
- 此處有等待
-
第三次：服務器發送含FIN且SEQ_NUM = R的包到客戶機。（服 -> LAST_ACK，客 -> TIME_WAIT）
- 此處有等待
-
第四次：客戶機發送最後一個含有ACK位且ACK_NUM = R + 1的包到客戶機。（服 -> CLOSED）
5. 爲什麼握手是三次，揮手是四次？
-
對於握手：握手只需要確認雙方通信時的初始化序號，保證通信不會亂序。
（第三次握手必要性：假設服務端的確認丟失，連接並未斷開，客戶機超時重發連接請求，這樣服務器會對同一個客戶機保持多個連接，造成資源浪費。） -
對於揮手：TCP是雙工的，所以發送方和接收方都需要FIN和ACK。只不過有一方是被動的，所以看上去就成了4次揮手。
6. TCP連接狀態？
-
CLOSED：連接斷開狀態。
-
LISTEN：服務器處於監聽狀態。
-
SYN_SEND：客戶端socket執行CONNECT連接，發送SYN包，進入此狀態。
-
SYN_RECV：服務端收到SYN包併發送服務端SYN包，進入此狀態。
-
ESTABLISH：表示連接建立。客戶端發送了最後一個ACK包後進入此狀態，服務端接收到ACK包後進入此狀態。
-
FIN_WAIT_1：終止連接的一方（通常是客戶機）發送了FIN報文後進入。等待對方FIN。
-
CLOSE_WAIT：（假設服務器）接收到客戶機FIN包之後等待關閉的階段。在接收到對方的FIN包之後，自然是需要立即回覆ACK包的，表示已經知道斷開請求。
但是本方是否立即斷開連接（發送FIN包）取決於是否還有數據需要發送給客戶端，若有，則在發送FIN包之前均爲此狀態。 -
FIN_WAIT_2：此時是半連接狀態，即有一方要求關閉連接，等待另一方關閉。客戶端接收到服務器的ACK包，但並沒有立即接收到服務端的FIN包，進入FIN_WAIT_2狀態。
-
LAST_ACK：服務端發動最後的FIN包，等待最後的客戶端ACK響應，進入此狀態。
-
TIME_WAIT：客戶端收到服務端的FIN包，並立即發出ACK包做最後的確認，在此之後的2MSL時間稱爲TIME_WAIT狀態。
7. 解釋FIN_WAIT_2，CLOSE_WAIT狀態和TIME_WAIT狀態？
-
FIN_WAIT_2：
-
半關閉狀態。
-
發送斷開請求一方還有接收數據能力，但已經沒有發送數據能力。
-
-
CLOSE_WAIT狀態：
-
被動關閉連接一方接收到FIN包會立即迴應ACK包表示已接收到斷開請求。
-
被動關閉連接一方如果還有剩餘數據要發送就會進入CLOSED_WAIT狀態。
-
-
TIME_WAIT狀態：
-
又叫2MSL等待狀態。
-
如果客戶端直接進入CLOSED狀態，如果服務端沒有接收到最後一次ACK包會在超時之後重新再發FIN包，此時因爲客戶端已經CLOSED，所以服務端就不會收到ACK而是收到RST。
所以TIME_WAIT狀態目的是防止最後一次握手數據沒有到達對方而觸發重傳FIN準備的。 -
在2MSL時間內，同一個socket不能再被使用，否則有可能會和舊連接數據混淆（如果新連接和舊連接的socket相同的話）。
-
8. 解釋RTO，RTT和超時重傳？
-
超時重傳：發送端發送報文後若長時間未收到確認的報文則需要重發該報文。可能有以下幾種情況：
-
發送的數據沒能到達接收端，所以對方沒有響應。
-
接收端接收到數據，但是ACK報文在返回過程中丟失。
-
接收端拒絕或丟棄數據。
-
-
RTO：從上一次發送數據，因爲長期沒有收到ACK響應，到下一次重發之間的時間。就是重傳間隔。
-
通常每次重傳RTO是前一次重傳間隔的兩倍，計量單位通常是RTT。例：1RTT，2RTT，4RTT，8RTT…
-
重傳次數到達上限之後停止重傳。
-
-
RTT：數據從發送到接收到對方響應之間的時間間隔，即數據報在網絡中一個往返用時。大小不穩定。
9. 流量控制原理？
-
目的是接收方通過TCP頭窗口字段告知發送方本方可接收的最大數據量，用以解決發送速率過快導致接收方不能接收的問題。所以流量控制是點對點控制。
-
TCP是雙工協議，雙方可以同時通信，所以發送方接收方各自維護一個發送窗和接收窗。
-
發送窗：用來限制發送方可以發送的數據大小，其中發送窗口的大小由接收端返回的TCP報文段中窗口字段來控制，接收方通過此字段告知發送方自己的緩衝（受系統、硬件等限制）大小。
-
接收窗：用來標記可以接收的數據大小。
-
-
TCP是流數據，發送出去的數據流可以被分爲以下四部分：已發送且被確認部分 | 已發送未被確認部分 | 未發送但可發送部分 | 不可發送部分，其中發送窗 = 已發送未確認部分 + 未發但可發送部分。
接收到的數據流可分爲：已接收 | 未接收但準備接收 | 未接收不準備接收。接收窗 = 未接收但準備接收部分。 -
發送窗內數據只有當接收到接收端某段發送數據的ACK響應時才移動發送窗，左邊緣緊貼剛被確認的數據。接收窗也只有接收到數據且最左側連續時才移動接收窗口。
10. 擁塞控制原理？
-
擁塞控制目的是防止數據被過多注網絡中導致網絡資源（路由器、交換機等）過載。因爲擁塞控制涉及網絡鏈路全局，所以屬於全局控制。控制擁塞使用擁塞窗口。
-
TCP擁塞控制算法：
-
慢開始 & 擁塞避免：先試探網絡擁塞程度再逐漸增大擁塞窗口。每次收到確認後擁塞窗口翻倍，直到達到閥值ssthresh，這部分是慢開始過程。達到閥值後每次以一個MSS爲單位增長擁塞窗口大小，當發生擁塞（超時未收到確認），將閥值減爲原先一半，繼續執行線性增加，這個過程爲擁塞避免。
-
爲了防止cwnd增長過大引起網絡擁塞，還需設置一個慢開始門限ssthresh狀態變量。ssthresh的用法如下：
當cwnd<ssthresh時，使用慢開始算法。 當cwnd>ssthresh時，改用擁塞避免算法。 當cwnd=ssthresh時，慢開始與擁塞避免算法任意。 -
擁塞避免算法讓擁塞窗口緩慢增長，即每經過一個往返時間RTT就把發送方的擁塞窗口cwnd加1，而不是加倍。這樣擁塞窗口按線性規律緩慢增長。
-
無論是在慢開始階段還是在擁塞避免階段，只要發送方判斷網絡出現擁塞（其根據就是沒有收到確認，雖然沒有收到確認可能是其他原因的分組丟失，但是因爲無法判定，所以都當做擁塞來處理），就把慢開始門限設置爲出現擁塞時的發送窗口大小的一半。然後把擁塞窗口設置爲1，執行慢開始算法。
-
-
快速重傳 & 快速恢復：
- 快重傳要求接收方在收到一個失序的報文段後就立即發出重複確認（爲的是使發送方及早知道有報文段沒有到達對方）而不要等到自己發送數據時捎帶確認。快重傳算法規定，發送方只要一連收到三個重複確認就應當立即重傳對方尚未收到的報文段，而不必繼續等待設置的重傳計時器時間到期。
-
最終擁塞窗口會收斂於穩定值。
-
11. 如何區分流量控制和擁塞控制？
-
流量控制屬於通信雙方協商；擁塞控制涉及通信鏈路全局。
-
流量控制需要通信雙方各維護一個發送窗、一個接收窗，對任意一方，接收窗大小由自身決定，發送窗大小由接收方響應的TCP報文段中窗口值確定；
擁塞控制的擁塞窗口大小變化由試探性發送一定數據量數據探查網絡狀況後而自適應調整。 -
實際最終發送窗口 = min{流控發送窗口，擁塞窗口}。
12. TCP如何提供可靠數據傳輸的？
-
建立連接（標誌位）：通信前確認通信實體存在。
-
序號機制（序號、確認號）：確保了數據是按序、完整到達。
-
數據校驗（校驗和）：CRC校驗全部數據。
-
超時重傳（定時器）：保證因鏈路故障未能到達數據能夠被多次重發。
-
窗口機制（窗口）：提供流量控制，避免過量發送。
-
擁塞控制：同上。
13. 爲什麼要三次揮手？
- 在只有兩次"握手"的情形下，假設Client想跟Server建立連接，但是卻因爲中途連接請求的數據報丟失了，故Client端不得不重新發送一遍；這個時候Server端僅收到一個連接請求，因此可以正常的建立連接。但是，有時候Client端重新發送請求不是因爲數據報丟失了，而是有可能數據傳輸過程因爲網絡併發量很大在某結點被阻塞了，這種情形下Server端將先後收到2次請求，並持續等待兩個Client請求向他發送數據…問題就在這裏，Cient端實際上只有一次請求，而Server端卻有2個響應，極端的情況可能由於Client端多次重新發送請求數據而導致Server端最後建立了N多個響應在等待，因而造成極大的資源浪費！所以，"三次握手"很有必要！
14. 爲什麼要四次揮手？
- 試想一下，假如現在你是客戶端你想斷開跟Server的所有連接該怎麼做？第一步，你自己先停止向Server端發送數據，並等待Server的回覆。但事情還沒有完，雖然你自身不往Server發送數據了，但是因爲你們之前已經建立好平等的連接了，所以此時他也有主動權向你發送數據；故Server端還得終止主動向你發送數據，並等待你的確認。其實，說白了就是保證雙方的一個合約的完整執行！
15. 使用TCP的協議：FTP（文件傳輸協議）、Telnet（遠程登錄協議）、SMTP（簡單郵件傳輸協議）、POP3（和SMTP相對，用於接收郵件）、HTTP協議等。
UDP
16. UDP用戶數據報協議，是面向無連接的通訊協議，UDP數據包括目的端口號和源端口號信息，由於通訊不需要連接，所以可以實現廣播發送。
17. UDP的應用？
- UDP通訊時不需要接收方確認，屬於不可靠的傳輸，可能會出現丟包現象，實際應用中要求程序員編程驗證。UDP與TCP位於同一層，但它不管數據包的順序、錯誤或重發。
因此，UDP不被應用於那些使用虛電路的面向連接的服務，UDP主要用於那些面向查詢—應答的服務，例如NFS。相對於FTP或Telnet，這些服務需要交換的信息量較小。
18. UDP頭部？
-
每個UDP報文分UDP報頭和UDP數據區兩部分。報頭由四個16位長（2字節）字段組成，分別說明該報文的源端口、目的端口、報文長度以及校驗值。UDP報頭由4個域組成，其中每個域各佔用2個字節，具體如下：
（1）源端口號；
（2）目標端口號；
（3）數據報長度；
（4）校驗值。