面試必考:網路問題

高效能架構探索發表於2021-09-03

筆者從事後端技術十餘年,期間也面試別人,也有被別人面試,今天特意將這些面試的知識點總結下,希望能夠在工作或者面試中幫助到大家。

說說OSI模型和TCP/IP模型

OSI(Open System Interconnection,開放式通訊互聯) 是由 ISO(International Organization for Standardization,國際標準化組織) 制定的標準模型。旨在將世界各地的各種計算機互聯。然而,OSI 模型過於龐大、複雜。參照此模型,技術人員開發了 TCP/IP 協議棧,簡化 OSI 七層模型為 TCP/IP 四層模型。獲得了更廣泛的使用。

OSI 模型和 TCP/IP 模型對比: 

什麼是TCP

TCP(Transmission Control Protocol 傳輸控制協議)是一種面向連線(連線導向)的、可靠的、 基於IP的傳輸層協議。

TCP是如何保證資料可靠的

  • 通過資料流的方式傳輸,將資料截成合理的長度;
  • 對每段報文進行編號,保證資料流的順序;
  • 收到資料進行重排序,並且丟棄重複資料;
  • 收到報文後,給出確認響應;
  • 超時重發;
  • 校驗和;
  • 流量控制(針對本程式的接受能力)和擁塞控制(針對整個網路)。

說說TCP和UDP的區別

協議差別

功能TCPUDP
是否連線 面向連線 無連線
傳輸可靠性 可靠 不可靠
應用場合 傳輸少量資料 傳輸大量資料
速度

區別總結:

  • TCP 的面向連線的,在傳送資料之前要建立連線;UDP 是無連線的,即傳送資料之前不需要建立連線;
  • TCP 提供可靠的服務,通過 TCP 連線傳送的資料,不丟失,不重複,且按序到達。UDP 盡最大努力交付,不保證可靠交付;
  • TCP 面向位元組流,把資料看成一連串無結構的位元組流;UDP 是面向報文的,對應用程式的報文既不拆分也不合並;
  • TCP 有流量控制和擁塞控制,UDP 沒有擁塞控制;
  • TCP 連線只能是點到點的,UDP 支援一對一,一對多,多對一和多對多的互動通訊;
  • TCP首部至少開銷 20 位元組,UDP 的首部結構簡單,開銷小,只有8個位元組;
  • 由於 TCP 要維護連線和保證可靠性,所以對系統資源的要求較多, UDP 相對要小得多。

TCP建立連線的過程

TCP建立連線發生在client端呼叫connect系統呼叫的時候。其目的是為了對每次傳送的資料量進行跟蹤與協商(即交換雙方視窗大小),確保資料段的傳送和接收同步,根據所接收到的資料量而確認資料傳送、接收完畢後何時撤消聯絡,並建立虛連線。

TCP建立連線的過程,是一個三次握手的過程。

  • 第一次握手:client端向server傳送連線請求,SYN=1(SYN表示傳送端與接收端要建立連線),seq = x。此時client端進入SYN_SENT階段
  • 第二次握手:server在收到client端的請求後,向client回覆SYN = 1(SYN表示傳送端與接收端要建立連線) 和 ACK = 1(表示對傳送端請求進行應答),seq = y, ack = x + 1。此時server端進入SYN_RCVD階段
  • 第三次握手:client端收到server端的請求和響應之後,同樣需要向server端回覆訊息。向server端傳送ACK = 1(表示對server端的響應),seq = x + 1,ack = y + 1.此時客戶端進入ESTABLISH階段。server端在收到該ACK後,也進入ESTABLISH階段。

通俗理解:

  • A 想要和 B 通訊,首先跟 B 說:“我想和你通訊”;
  • B 收到這條資訊之後,回覆 A 說:“收到。我也想和你通訊”;
  • A 收到之後就知道,原來 B 也想通訊,回覆 B 說:“收到”。

上述三次握手過程,我們用圖表示為。

為什麼建立連線是3次,而不是2次或者4次

按理說,在客戶端收到伺服器發過來的確認報文後(第二次握手後),通訊雙方就可以確定對方的請求建立連線的意圖了,那為什麼客戶端還要再傳送一次 ACK 報文呢?

主要是防止已經失效的連線請求報文又到達伺服器端這種情況。

“已經失效的連線請求報文”是這樣產生的:當網路環境差的時候,客戶端傳送的連線請求報文可能丟失,也有可能滯留在某個節點。當客戶端等待一定時間後,沒有收到伺服器傳送的確認報文,就認為之前傳送的連線請求報文失效了。客戶端會再次傳送連線請求報文。

但是如果滯留在某個節點的報文經過長時間延遲後到達了伺服器端,伺服器並不知道這是一個失效的報文,它以為是客戶端的正常連線請求,就會返回確認報文,同意連線建立。

如果採用2次握手的方法,這時新的連線已經建立了。但是實際上,客戶端並沒有發起請求,它不會對服務端的確認報文做出反應,更不會傳送資料給服務端。而服務端卻以為新的連線已經建立,一直再等待客戶端傳送資料,這樣就造成了資源的浪費。

而如果採用4次握手的情況,就是將第二次SYN和ACK分成兩步來操作,這樣會浪費資源以及效能浪費。

採用3次握手就可以避免這樣情況。上述的情形下,伺服器沒有收到客戶端對自己傳送過去的確認報文的 ACK 報文,就知道客戶端沒有請求建立連線。

TCP斷開連線的過程

當client端和server端的資料傳輸完成之後,就需要斷開連線,以節省資源。斷開連線的過程,我們一般稱之為四次揮手(與建立連線的三次握手相對應)。

  • 第一次揮手:client端向server端傳送斷開連線的請求,告訴server端,我這邊不再需要跟你傳輸資料。傳送FIN=1(表示傳送斷開連線請求),seq=x,此時client端處於FIN_WAIT_1階段
  • 第二次揮手:server端在收到client端的斷開請求後,需要告訴客戶端已經收到請求。因此向client端回覆ACK=1,seq=y,ack=x+1(表示對client傳送的seq=x進行確認)。此時client端處於FIN_WAIT_2階段,server端處於CLOSE_WAIT階段。
  • 第三次揮手:當server端不再需要與client端傳輸資料,就向client端傳送斷開連線的請求。FIN=1(表示傳送斷開連線請求),ACK=1(表示對client端的上一次斷開連線應答)。seq=z,ack=x+1(上一次斷開連線請求時候seq=x)。此時server端處於LAST_ACK階段。
  • 第四次揮手:client端收到server端斷開連線的請求後,需作出應答,因此ACK=1.seq=x+1,ack=w+1(表示對上一次請求的應答)

通俗理解:

  • A 沒有資料傳送,就和 B 說:“我沒有資料給你了,但是如果你還有資料沒傳送完,則不必急著斷開,還可以繼續傳送資料”;
  • B 收到後,會告訴 A說:“收到。”,然後繼續傳送資料給 A;
  • 當 B 端確定資料已傳送完成,則告訴 A:“好了,我這邊資料發完了,準備好關閉連線了”;
  • A 聽到後,和 B 說:“好的,你斷開吧。”,然後在等待 2MSL 時間後斷開。

至此,斷開連線的過程講解完畢,用圖的方式如下:

為什麼client要等待 2MSL 後才斷開連線?

網路的狀態是不確定的,最後 Client 傳送的確認報文可能丟失。 如果確認報文丟失並且 Client 不等待,直接斷開連線。此時 Server 端在傳送 FIN 報文後,不會收到任何響應。等待一段時間後,會重發 FIN 報文,但此時 Client 端已經關閉。Server 就會一直重發 FIN 報文。而如果 Client 端處於等待狀態時,就會回覆確認報文給 Server,讓 Server 關閉。同時,在 2MSL 內沒有收到 FIN 報文,說明 Server 端收到了確認報文,已經關閉,這樣自己也可以關閉了。 2MSL 是從 Client 到 Server 時間的2倍,也就是傳送確認報文和接受 FIN 報文的時間。

為什麼TCP斷開連線是4次

因為TCP是全雙工,在一端斷開連線之後,另外一端在需要的時候,也需要斷開連線。每一端的斷開需要兩次,即FIN和ACK,所以整個過程就是四次。

TCP是怎樣進行流量控制

TCP必需要解決的可靠傳輸以及包亂序的問題,所以,TCP必需要知道網路實際的資料處理頻寬或是資料處理速度,這樣才不會引起網路擁塞,導致丟包。這就引入了滑動視窗和擁塞視窗。

在傳送端通過擁塞視窗,在接收端通過滑動視窗。

滑動視窗協議是傳輸層進行流控的一種措施,接收方通過通告傳送方自己的可以接受緩衝區大小(這個欄位越大說明網路吞吐量越高),從而控制傳送方的傳送速度,不過如果接收端的緩衝區一旦面臨資料溢位,視窗大小值也會隨之被設定一個更小的值通知給傳送端,從而控制資料傳送量(傳送端會根據接收端指示,進行流量控制)。

防止過多的資料注入到網路中,這樣可以使網路中的路由器或鏈路不致過載。擁塞控制所要做的都有一個前提:網路能夠承受現有的網路負荷。擁塞控制是一個全域性性的過程,涉及到所有的主機、路由器,以及與降低網路傳輸效能有關的所有因素。 

在瀏覽器中輸入一個url後,瀏覽器的行為

瀏覽器本身是一個客戶端,當你輸入URL的時候,首先瀏覽器會去請求DNS伺服器,通過DNS獲取相應的域名對應的IP,然後通過IP地址找到IP對應的伺服器後,要求建立TCP連線,等瀏覽器傳送完HTTP Request(請求)包後,伺服器接收到請求包之後才開始處理請求包,如果請求的資源包含有動態語言的內容,那麼伺服器會呼叫動態語言的解釋引擎負責處理“動態內容”,並將處理得到的資料裝在HTTP Response(響應)包返回給客戶端;客戶端收到來自伺服器的響應後開始渲染這個Response包裡的主體(body),等收到全部的內容隨後斷開與該伺服器之間的TCP連線。

 

 

關注公眾號【蟲爸說說】,回覆【資料】,免費領取

 

歡迎訪問個人主頁http://www.studyinfo.top

相關文章