【Linux】TCP/UDP/HTTP面試問題

1、UDP和TCP的區別

• TCP
• 有連接
• 可靠的傳輸
• TCP是點對點的兩點間服務，即一條TCP連接只能有兩個端點:
• TCP有流量控制擁塞控制保證數據傳輸的安全性
• TCP報文長度是用接收方的窗口大小和當前的網絡狀況決定的
• TCP首部開銷大，需要20個字節
• UDP
• 無連接
• 不可靠
• UDP支持1對1,1對多，多對多
• UDP沒有擁塞控制，網絡阻塞不會影響發送效率
• UDP是面向報文的，保留從上面傳下來的報文邊界
• UDP首部開銷小，要8個字節（源端口，目的端口，數據長度，校驗和）
• 適用於場景
• 若通訊數據的完整性要讓位於數據的實時性時，就應該使用TCP，例如重要文件的傳輸
• 若實時性更加重要時，則使用UDP，（如視頻通訊，語音通話）
• UDP丟包問題延伸

2、SYN泛洪攻擊的出現和防治

出現：

• 假如在這“握手”的過程中，客戶端程序因爲莫名崩潰等原因，收到SYN+ACK報文後不再回以ACK，服務端將如何處置，這時服務端會“優雅地”再等等，會不會是發送的包丟失了呢？
• 於是重新發送一遍SYN+ACK，再收不到來自客戶端的ACK響應的話，就把這次連接丟棄掉。這個過程大約會“優雅地”持續分鐘級，這個持續時間被稱作SYN timeout時間。大量的握手請求涌向TCP服務端，而它們只發出SYN報文而不以ACK響應結束握手，服務端就要爲這每一個請求都維持約一分多鐘的連接去等待ACK，也就形成所謂的“半連接”。維護這些半連接是需要消耗很多服務器的網絡連接資源的。如果短時間內這些資源幾乎都被半連接佔滿，那麼正常的業務請求在這期間就得不到服務，處於等待狀態。
• 如果這些半連接的握手請求是惡意程序發出，並且持續不斷，那麼就會導致服務端較長時間內喪失服務功能——這就形成了DoS(Denial of Service)拒絕服務攻擊。這種攻擊方式就稱爲SYN泛洪（SYN flood）攻擊。

處理：

• 最常用的一個手段就是優化主機系統設置。比如降低SYN timeout時間，使得主機儘快釋放半連接的佔用或者採用SYN cookie設置，如果短時間內收到了某個IP的重複SYN請求，我們就認爲受到了攻擊。我們合理的採用防火牆設置等外部網絡也可以進行攔截。

3、TCP、UDP報頭

• TCP報頭
  

• 源端口和目的端口：各佔2個字節。

• 序號：佔4字節。序號範圍是0~2^32-1。TCP是面向字節流的，TCP連接中傳送的字節流中的每個字節都按順序編號。整個要傳送的字節流的起始序號必須要在連接建立時設置。首部中的序號字段值指的是本報文段所發送的數據的第一個字節的序號。

• 確認號：4個字節，是期望收到對方下一個報文段的第一個數據字節的序號。
  若確認號=N，則表明：到序號N-1爲止的所有數據都已正確收到。
  4.數據偏移：4位。指出TCP報文段的數據起始處距離報文段的起始處有多遠。這個字段實際上是指出TCP報文段的首部長度。由於首部中還有長度不確定的選項字段，因此數據偏移字段是必要的。單位是32位字，也就是4字節，4位二進制最大表示15，所以數據偏移也就是TCP首部最大60字節

• 保留：6位
  下面有6個控制位說明本報文段的性質

• 緊急URG：1位
  當URG=1時，表明緊急指針字段有效。它告訴系統此報文段中有緊急數據，應儘快傳送（相當於高優先級的數據），而不要按原來的排隊順序來傳送。例如，已經發送了很長的一個程序在遠地的主機上運行。但後來發現了一些問題，需要取消該程序的運行。因此用戶從鍵盤發出中斷命令（Control+c）。如果不使用緊急數據，那麼這兩個字符將存儲在接收TCP的緩存末尾。只有在所有的數據被處理完畢後這兩個字符才被交付接收方的應用進程。這樣做就浪費了許多時間。

• 當URG置爲1時，發送應用進程就告訴發送方的TCP有緊急數據要傳送。於是發送方TCP就把緊急數據插入到本報文段數據的最前面，而在緊急數據後面的數據仍時普通數據。這時要與首部中緊急指針字段配合使用。

• 確認ACK 僅當ACK=1時確認號字段纔有效。當ACK=0時，確認號無效。TCP規定，在連接建立後所有的傳送的報文段都必須把ACK置1。

• 推送PSH 當兩個應用進程進行交互式的通信時，有時在一端的應用進程希望在鍵入一個命令後立即就能收到對方的響應。在這種情況下，TCP就可以使用推送操作。

• 這時，發送方TCP把PSH置1，並立即創建一個報文段發送出去。接收方TCP收到PSH=1的報文段，就儘快地交付接收應用進程，而不再等到整個緩存都填滿了後向上交付。雖然應用程序可以選擇推送操作，但推送還很少使用。

• 復位RST
  tcp連接出現嚴重差錯時釋放連接，然後重新建立連接。而可以用來拒絕一個非法的報文段或拒絕打開一個連接。
  當RST=1時，表明TCP連接中出現嚴重差錯（如由於主機崩潰或其他原因），必須釋放連接，然後再重新建立運輸連接。RST置1還用來拒絕一個非法的報文段或拒絕打開一個連接。

• 同步SYN
  在連接建立時用來同步序號。當SYN=1而ACK=0時，表明這是一個連接請求報文段。對方若同意建立連接，則應在相應的報文段中使用SYN=1和ACK=1。因此，SYN置爲1就表示這是一個連接請求或連接接受保溫。

• 終止FIN
  用來釋放一個連接。當FIN=1時，表明此報文段的發送方的數據已發送完畢，並要求釋放運輸連接。

• 窗口 佔2字節。窗口值是【0，2^16-1]之間的整數。窗口指的是發送本報文段的一方的接收窗口（而不是自己的發送窗口）。窗口值告訴對方： 從本報文段首部中的確認號算起，接收方目前允許對方發送的數據量。之所以要有這個限制，是因爲接收方的數據緩存空間是有限的。總之，窗口值作爲接收方讓發送方設置其發送窗口的依據。並且窗口值是經常在動態變化着。

• 檢驗和：2字節。檢驗範圍包括首部和數據兩部分。和UDP用戶數據報一樣，在計算校驗和 時，要在TCP報文段加上12字節的僞首部。

• 緊急指針：2字節。緊急指針僅在URG=1時纔有意義，它指出本報文段中的緊急數據的字節數（緊急數據結束後就是普通數據）。因此，緊急指針指出了緊急數據的末尾在報文段中的位置。當所有緊急數據都處理完時，TCP就告訴應用程序恢復到正常操作。值得注意的是，即使窗口爲零時也可發送緊急數據。

• 選項：長度可變，最長可達40字節。當沒有使用“選項”時，TCP的首部長度是20字節。

  1. MSS 最大報文段長度
     MSS最大報文段長度（數據字段的最大長度，默認是536字節）。MSS不宜設的太大也不宜設的太小。若選擇太小，極端情況下，TCP報文段只含有1字節數據，在IP層傳輸的數據報的開銷至少有40字節（包括TCP報文段的首部和IP數據報的首部）。這樣，網絡的利用率就不會超過1/41。若TCP報文段非常長，那麼在IP層傳輸時就有可能要分解成多個短數據報片。在終點要把收到的各個短數據報片裝配成原來的TCP報文段。當傳輸出錯時還要進行重傳，這些也都會使開銷增大。
     因此MSS應儘可能大，只要在IP層傳輸時不需要再分片就行。在連接建立過程中，雙方都把自己能夠支持的MSS接入這一字段，以後就按照這個數值傳送數據。
  2. 窗口擴大
     窗口擴大選項是爲了擴大窗口。TCP首部中窗口字段長度是16位，因此最大窗口大小就是64k字節。對於包含衛星信道的網絡可能是不夠用的。可以在雙方初始建立TCP連接的時候就進行協商。
  3. 時間戳（計算RTT,防止序號繞回）
     A. 用來計算往返時間RTT。發送方在發送報文段時把當前時鐘的時間值放入時間戳字段，接收方在確認該報文段時把時間戳字段值複製到時間戳回送回答字段。因此，發送方在收到確認報文後，可以準確地計算RTT來。
  4. 選擇確認選項

• UDP報頭

• UDP協議分爲首部字段和數據字段，其中首部字段只佔用8個字節，分別是個佔用兩個字節的源端口、目的端口、長度和檢驗和。

3、爲什麼TCP不是兩次？爲什麼不是四次？

• 三次握手是爲了防止，客戶端的請求報文在網絡滯留，客戶端超時重傳了請求報文，服務端建立連接，傳輸數據，釋放連接之後，服務器又收到了客戶端滯留的請求報文，建立連接一直等待客戶端發送數據。
  服務器對客戶端的請求進行迴應(第二次握手)後，就會理所當然的認爲連接已建立，而如果客戶端並沒有收到服務器的迴應呢？此時，客戶端仍認爲連接未建立，服務器會對已建立的連接保存必要的資源，如果大量的這種情況，服務器會崩潰。

4、三次握手分別失敗

5、四次揮手

• 四次揮手首先由客戶端K發起，
• 客戶端向服務端發送FIN報文，並停止發送數據，客戶端進入FIN_WAIT_1狀態
• 服務端收到FIN報文後，發送ACK到客戶端確認，服務端自己進入CLOSE_WAIT，
• 當客戶端收到ACK時切換爲FIN_WAIT2狀態
• 當服務器端數據傳輸完畢之後，發送FIN到客戶端，自己進入LAST_ACK狀態
• 客戶端收到FIN後，發送ACK到服務端，自己進入TIME_WAIT狀態
• 服務端收到ACK後進入CLOSE狀態

6、MSL時間

• MSL是Maximum Segment Lifetime英文的縮寫，中文可以譯爲“報文最大生存時間”，他是任何報文在網絡上存在的最長時間，超過這個時間報文將被丟棄。因爲tcp報文（segment）是ip數據報（datagram）的數據部分
• 2MSL即兩倍的MSL，TCP的TIME_WAIT狀態也稱爲2MSL等待狀態，當TCP的一端發起主動關閉，在發出最後一個ACK包後，即第3次握手完成後發送了第四次握手的ACK包後就進入了TIME_WAIT狀態，必須在此狀態上停留兩倍的MSL時間，等待2MSL時間主要目的是怕最後一個 ACK包對方沒收到，那麼對方在超時後將重發第三次握手的FIN包，主動關閉端接到重發的FIN包後可以再發一個ACK應答包。在TIME_WAIT狀態 時兩端的端口不能使用，要等到2MSL時間結束纔可繼續使用。當連接處於2MSL等待階段時任何遲到的報文段都將被丟棄。不過在實際應用中可以通過設置 SO_REUSEADDR選項達到不必等待2MSL時間結束再使用此端口。

7、http和https的區別

1. HTTP協議是以明文的方式在網絡中傳輸數據，而HTTPS協議傳輸的數據則是經過TLS加
   密後的，HTTPS具有更高的安全性
2. HTTPS 在TCP三次握手階段之後，還需要進行SSL的handshake,協商加密使用的對稱
   加密密鑰
3. HTTPS 協議需要服務端申請證書，瀏覽器端安裝對應的根證書
4. HTTP協議端口是80, HTTPS協議端口是443