概念先整清楚

TCP協議和UDP協議與TCP/IP協議的聯絡

  TCP/IP協議是一個協議簇，裡面包括很多協議的，UDP只是其中的一個，之所有命名為TCP/IP協議，因為TCP、IP協議是兩個很重要的協議 ，所以就用他們命名了

TCP/IP協議簇包括應用層、傳輸層、網路層、網路訪問層

• 應用層包括：

  • 超文字傳輸協議 HTTP,全球資訊網的基本協議。
  • 檔案傳輸 TFTP。
  • 遠端登入 Telnet，提供遠端訪問其他主機功能。
  • 網路管理 SNMP 簡單網路管理協議，該協議提供了監控網路裝置的方法，以及配置管理，統計資訊收集，效能管理及安全管理等；
  • 域名系統 DNS , 將域名轉換成IP地址

• 傳輸層包括

  • TCP，面向連線的TCP傳輸控制協議，列舉一些執行在TCP協議上的應用層協議
    • HTTP，主要用於普通瀏覽。
    • HTTPS , 安全超文字傳輸協議，HTTP協議的安全版本
    • FTP,檔案傳輸協議，用於檔案傳輸。
    • POP3，郵局協議，收郵件用。
    • SMTP，簡單郵件傳送協議，用來發送電子郵件
    • TELNET，通過一個終端terminal登入到網路。
    • SSH，用於替代安全性差的TELNET，用於加密安全登入用。
  • UDP，無連線的包傳輸的UDP使用者資料報文協議，列舉一些執行在UDP協議上的應用層協議：
    • BOOTP，啟動協議，應用於無盤裝置
    • NTP，網路時間協議，用於網路同步
    • DHCP，動態主機配置協議，動態配置IP地址
  • DCCP 資料擁塞控制協議
  • SCTP 流控制傳輸協議

• 網路層包括

  • Internet協議，IP協議。
  • Internet控制資訊協議，ICMP。
  • 地址解析協議，ARP。
  • 反向地址解析協議，RARP。

• 網路訪問層（主機到網路層 , host-to-network）

    TCP/IP四層模式裡最後一層對應OSI七層裡的資料鏈路層和物理層，主要功能包括IP地址與實體地址硬體的對映，以及將IP資料報封裝成幀。

TCP和UDP區別 (面試常問)

  關於這個問題，我也被問了好幾次了，每次都答不完整，在這裡好好整理一下，方便查閱。

• TCP，是面向連線；
• UDP，是無連線。

• TCP，點對點全雙工通訊；
• UDP，一對一、一對多（廣播）、多對一、多對多的互動通訊。

• TCP，面向位元組流（把上層即應用層傳下來的報文看出位元組流，然後組織成大小不等資料塊）；
• UDP，面向報文（對報文不合並也不拆分，只新增UDP首部8位元組）。

• TCP，是可靠的（無差錯，不丟失，不重複，概括保證資料正確性，且按序到達）；
• UDP，盡最大可能交付的（是不可靠的）。

• TCP，有擁塞控制、流量控制（下面會說明）；
• UDP，沒有擁塞控制，即如果網路出現擁塞，也不會讓傳送方主機降低傳送速率；視訊傳輸（線上視訊）、實時通訊（QQ聊天）、語言傳輸（電話），對資料準確性和丟包要求比較低，但速度必須快的。

TCP & UDP 特點

• 傳輸控制協議 TCP（Transmission Control Protocol）是面向連線的，提供可靠交付，有流量控制，擁塞控制，提供全雙工通訊，面向位元組流（把應用層傳下來的報文看成位元組流，把位元組流組織成大小不等的資料塊），每一條 TCP 連線只能是點對點的（一對一）。
• 使用者資料報協議 UDP（User Datagram Protocol）是無連線的，盡最大可能交付，沒有擁塞控制，面向報文（對於應用程式傳下來的報文不合並也不拆分，只是新增 UDP 首部），支援一對一、一對多、多對一和多對多的互動通訊。

TCP 首部格式

• 序號 ：用於對位元組流進行編號，例如序號為 301，表示第一個位元組的編號為 301，如果攜帶的資料長度為 100 位元組，那麼下一個報文段的序號應為 401。

• 確認號 ：期望收到的下一個報文段的序號。例如 B 正確收到 A 傳送來的一個報文段，序號為 501，攜帶的資料長度為 200 位元組，因此 B 期望下一個報文段的序號為 701，B 傳送給 A 的確認報文段中確認號就為 701。

• 資料偏移 ：指的是資料部分距離報文段起始處的偏移量，實際上指的是首部的長度。

• 確認 ACK ：當 ACK=1 時確認號欄位有效，否則無效。TCP 規定，在連線建立後所有傳送的報文段都必須把 ACK 置 1。

• 同步 SYN ：在連線建立時用來同步序號。當 SYN=1，ACK=0 時表示這是一個連線請求報文段。若對方同意建立連線，則響應報文中 SYN=1，ACK=1。

• 終止 FIN ：用來釋放一個連線，當 FIN=1 時，表示此報文段的傳送方的資料已傳送完畢，並要求釋放連線。

• 視窗 ：視窗值作為接收方讓傳送方設定其傳送視窗的依據。之所以要有這個限制，是因為接收方的資料快取空間是有限的。

UDP 首部格式

首部欄位只有 8 個位元組，包括源埠、目的埠、長度、檢驗和。12 位元組的偽首部是為了計算檢驗和臨時新增的。

TCP如何保證可靠傳輸的？

• 確認和重傳:接收方收到報文就會確認，傳送方傳送一段時候後沒有收到確認就重傳

• 資料校驗

• 資料合理分片和排序：

  • UDP：IP資料報大於1500位元組,大於MTU.這個時候傳送方IP層就需要分片(fragmentation).把資料報分成若干片,使每一片都小於MTU.而接收方IP層則需要進行資料報的重組.這樣就會多做許多事情,而更嚴重的是,由於UDP的特性,當某一片資料傳送中丟失時,接收方便無法重組資料報.將導致丟棄整個UDP資料報.
  • tcp會按MTU合理分片，接收方會快取未按序到達的資料，重新排序後再交給應用層。

• 流量控制：當接收方來不及處理髮送方的資料，能提示傳送方降低傳送的蘇麗，防止包丟失

• 擁塞控制：當網路擁塞時，降低傳送速率。

TCP流量控制

可以用一句話概括，流量控制是為了控制傳送方傳送速率，保證接收方來得及接收。怎麼實現的呢？↓

  接收方傳送的確認報文中的視窗欄位可以用來控制傳送方視窗大小，從而影響傳送方的傳送速率。將視窗欄位設定為 0，則傳送方不能傳送資料。如果接收方有足夠大的接收快取，就不會發生流量控制；

如何實現流量控制 ?

  TCP中由滑動視窗協議（連續ARQ協議）實現。滑動視窗協議既保證了分組無差錯、有序接收，也實現了流量控制。主要的方式就是接收方返回的 ACK 中會包含自己的接收視窗的大小，並且利用大小來控制傳送方的資料傳送。

流量控制引發的死鎖？

  當傳送者收到了一個視窗為0的應答，傳送者便停止傳送，等待接收者的下一個應答。但是如果這個視窗不為0的應答在傳輸過程丟失，傳送者一直等待下去，而接收者以為傳送者已經收到該應答，等待接收新資料，這樣雙方就相互等待，從而產生死鎖。

怎麼避免死鎖的發生？

  為了避免流量控制引發的死鎖，TCP使用了持續計時器。每當傳送者收到一個0視窗的應答後就啟動該計時器。時間一到便主動傳送報文詢問接收者的視窗大小。若接收者仍然返回零視窗，則重置該計時器繼續等待；若視窗不為0，則表示應答報文丟失了，此時重置傳送視窗後開始傳送，這樣就避免了死鎖的產生。

TCP擁塞控制

  如果網路出現擁塞，分組將會丟失，此時傳送方會繼續重傳，從而導致網路擁塞程度更高。因此當出現擁塞時，應當控制傳送方的速率。這一點和流量控制很像，但是出發點不同。流量控制是為了讓接收方能來得及接收，而擁塞控制是為了降低整個網路的擁塞程度。

TCP 主要通過四個演算法來進行擁塞控制：慢開始、擁塞避免、快重傳、快恢復。

慢開始與擁塞避免

先了解一波名詞

• cwnd ，擁塞視窗
• ssthresh ，處理擁塞時參照的一個引數
• 雖然 TCP 的視窗基於位元組，但是這裡設視窗的大小單位為報文段。

傳送的最初執行慢開始，令 cwnd = 1，傳送方只能傳送 1 個報文段；當收到確認後，將 cwnd 加倍，因此之後傳送方能夠傳送的報文段數量為：2、4、8 …

注意到慢開始每個輪次都將 cwnd 加倍，這樣會讓 cwnd 增長速度非常快，從而使得傳送方傳送的速度增長速度過快，網路擁塞的可能性也就更高。設定一個慢開始門限 ssthresh，當 cwnd >= ssthresh 時，進入擁塞避免，每個輪次只將 cwnd 加 1。

如果出現了超時，則令 ssthresh = cwnd / 2，然後重新執行慢開始。

快重傳和快恢復

• 在接收方，要求每次接收到報文段都應該對最後一個已收到的有序報文段進行確認。例如已經接收到 M1 和 M2，此時收到 M4，應當傳送對 M2 的確認。

• 在傳送方，如果收到三個重複確認，那麼可以知道下一個報文段丟失，此時執行快重傳，立即重傳下一個報文段。例如收到三個 M2，則 M3 丟失，立即重傳 M3。

• 在這種情況下，只是丟失個別報文段，而不是網路擁塞。因此執行快恢復，令 ssthresh = cwnd / 2 ，cwnd = ssthresh，注意到此時直接進入擁塞避免。

• 慢開始和快恢復的快慢指的是cwnd的設定值，而不是cwnd 的增長速率。慢開始 cwnd 設定為 1，而快恢復 cwnd 設定為 ssthresh。

TCP 的三次握手

假設 A 為客戶端，B 為伺服器端。

• 首先 B 處於 LISTEN（監聽）狀態，等待客戶的連線請求。

• A 向 B 傳送連線請求報文，SYN = 1,ACK=0，選擇一個初始的序號x

• B 收到連線請求報文，如果同意建立連線，則向A傳送連線確認報文，SYN =1 ,ACK= 1，確認號為x+1

• A 收到B的連線確認報文後，還要向B發出確認，確認號為y+1,序號為x+1

• B收到A 的確認後，連線建立。

為什麼要三次才建立連線？

第三次握手是為了防止失效的連線請求到達伺服器，讓伺服器錯誤開啟連線。

  客戶端傳送的連線請求如果在網路中滯留，那麼就會隔很長一段時間才能收到伺服器端發回的連線確認。客戶端等待一個超時重傳時間之後，就會重新請求連線。但是這個滯留的連線請求最後還是會到達伺服器，如果不進行三次握手，那麼伺服器就會開啟兩個連線。如果有第三次握手，客戶端會忽略伺服器之後傳送的對滯留連線請求的連線確認，不進行第三次握手，因此就不會再次開啟連線。

TCP四次揮手

• A傳送連線釋放報文FIN = 1 ，seq = u
• B收到之後發出確認，此時TCP屬於半關閉狀態，B 能向A傳送資料但是A不能向B傳送資料ACK = 1 ，ack = u + 1，seq = v
• 當B 不再需要連線時，傳送連線釋放報文，FIN =1 ，ACK = 1 ，ack = u + 1 ，seq = w
• A收到後發出確認，進入TIMEE-WAIT狀態，等待2MSL (最大報文存活時間)後釋放連線。ACK= 1，ack = w + 1 ，seq = u + 1
• B收到A的確認後釋放連線。

四次揮手的原因

簡單來說，就是為了，讓伺服器傳送完所有資料後，再關閉連線。

  客戶端傳送了FIN連線資料報文之後，伺服器收到這個報文，就進入了CLOSE-WAIT狀態。這個狀態是為了讓伺服器傳送還未傳送完畢的資料，傳送完畢之後，伺服器會發送FIN連線釋放報文。

TIME_WAIT（面試問過）

該詞是，客戶端收到伺服器端FIN報文（連線釋放報文）進入該狀態，下一個階段就是CLOSE階段，就是真正上的關閉連線了。但是不能關閉，必須等待2MSL時間。這麼做有兩個原因：

• 確保最後一個確認報文能夠到達，如果B沒收到A的確認報文，就會超時重發（連線釋放報文），TIME_WAIT狀態就是為了處理這種情況發生。
• 根據上面原因可知，為了保證在新的連線請求中不會出現上一次的請求報文。

補充

• MSL : Maximum Segment Lifetime,譯為“報文最大生存時間”，他是任何報文在網路上存在的最長時間，超過這個時間報文將被丟棄。因為TCP報文段以IP資料報在網路內傳輸，而IP資料報則有限制其生存時間的TTL欄位。

• 在TIME_WAIT狀態時兩端的埠不能使用，要等到2MSL時間結束才可繼續使用。

• 當連線處於2MSL等待階段時任何遲到的報文段都將被丟棄。不過在實際應用中可以通過設定SO_REUSEADDR選項達到不必等待2MSL時間結束再使用此埠。

• RFC 793中規定MSL為2分鐘，實際應用中常用的是30秒，1分鐘和2分鐘等

滑動視窗（TCP可靠傳輸的具體實現）

• 為什麼要使用滑動視窗？
• 視窗是什麼？
• 怎麼確認？（累計確認）
• 傳送方收到確認時怎麼處理？
• 什麼時候重傳？ ↓↓↓↓↓↓

  視窗是快取的一部分，用來暫時存放位元組流。傳送方和接收方各有一個視窗，接收方通過 TCP 報文段中的視窗欄位告訴傳送方自己的視窗大小，傳送方根據這個值和其它資訊設定自己的視窗大小（傳送視窗的大小swnd=min（rwnd，cwnd）。rwnd是接收視窗，cwnd用於擁塞控制）。

• 傳送視窗內的位元組都允許被髮送，接收視窗內的位元組都允許被接收。
• 如果傳送視窗左部的位元組已經發送並且收到了確認，那麼就將傳送視窗向右滑動一定距離，直到左部第一個位元組不是已傳送並且已確認的狀態；
• 接收視窗的滑動類似，接收視窗左部位元組已經發送確認並交付主機，就向右滑動接收視窗。

  如圖，接收視窗只會對視窗內最後一個按序到達的位元組進行確認（傳送確認），例如接收視窗已經收到的位元組為 {31, 34, 35}，其中 {31} 按序到達，而 {34, 35} 就不是，因此只對位元組 31 進行確認。傳送方得到一個位元組的確認之後，就知道這個位元組之前的所有位元組都已經被接收。

TCP的超時重傳

超時重傳：如果一個已經發送的報文段在超時時間內沒有收到確認，那麼就重傳這個報文段

一個報文段從傳送再到接收到確認所經過的時間稱為往返時間 RTT，加權平均往返時間 RTTs計算如下：

$RTT_s = ( 1 - a ) * RTT_s + a * RTT$

超時時間 RTO 應該略大於 RTTs，TCP 使用的超時時間計算如下：

$RTO = RTT_s + 4 * RTT_d$

RTT_d 為偏差

整理目前比較欠缺的知識。