不詩意的女程序媛不是好廚師~
轉(zhuǎn)載請注明出處，F(xiàn)rom李詩雨---https://blog.csdn.net/cjm2484836553/article/details/103930596

網(wǎng)絡架構(gòu)，可以算得上是面試的寵兒了，我也廢話不多說，直接上重點。

本節(jié)內(nèi)容思維導圖

1.計算機網(wǎng)絡分層▲（面試點）

1.1 OSI七層網(wǎng)絡模型 和 TCP/IP參考模型

• 重點1：OSI七層網(wǎng)絡模型 和 TCP/IP參考模型 ，它可是面試的敲門磚，所以大概的內(nèi)容要記住。

（PS:作為貼心小棉襖的我，已經(jīng)畫了個好看的圖，方便大家背誦~）

image

關于OSI模型 和 TCP/IP模型，大家可以這么理解。

OSI七層模型 偏向于一種 理想化的，就好比學術界定義的。而TCP/IP四層模型，則是工業(yè)界中實際使用的。

• 重點2： 大家要知道 TCP/IP是一組協(xié)議的代名詞，它還包括許多協(xié)議，組成了TCP/IP協(xié)議簇。

  從字面上來看，有人可能會認為 TCP/IP 是指 TCP 和 IP 兩種協(xié)議。實際生活當中，有時也確實就是指這兩種協(xié)議。但是在很多情況下，它只是利用 IP 進行通信時所必須用到的協(xié)議群的統(tǒng)稱。具體來說，IP 或 ICMP、TCP 或 UDP、TELNET 或 FTP、以及 HTTP 等都屬于 TCP/IP 協(xié)議。

  此外我們還要知道，在TCP/IP協(xié)議簇中， IP位于網(wǎng)絡層，TCP位于傳輸層，HTTP位于應用層。

  在這里插入圖片描述
  
  
  在這里插入圖片描述

2.IP地址 和 端口號

這里有2個概念需要我們來解釋一下，因為在面試只也有可能會提到。

2.1 IP地址

在這里插入圖片描述

為了實現(xiàn)網(wǎng)絡中不同終端之間的通信，每個終端必須有一個唯一的表示，它就是IP地址。

• 所以，如果問 兩臺終端是如何通過網(wǎng)絡進行通信的？

  那你要知道答案是 IP地址。

  可不是MAC地址哈，因為mac地址只在局域網(wǎng)有效，不能出局域網(wǎng)。

2.2 端口號?（暗涉一道面試題）

在這里插入圖片描述

我們可以把端口號，理解為門牌號。

通過ip地址，我們可以知道我們要訪問的是哪臺計算機。但是一臺計算機可以同時運行多個程序，我們?nèi)绾沃酪L問哪個應用程序呢？這就要通過端口號了。

端口號用來識別同一臺計算機中進行通信的不同應用程序。因此，它也被稱為程序地址。

在這里插入圖片描述

端口號規(guī)定為16位，即允許一個IP主機有2的16次方65535個不同的端口。其中：

• 0~1023：分配給系統(tǒng)的端口號

  我們不可以亂用!!
  常用協(xié)議使用的端口：HTTP:80，F(xiàn)TP：21，TELNET：23

• 1024~49151：登記端口號，主要是讓第三方應用使用

  但是必須在IANA（互聯(lián)網(wǎng)數(shù)字分配機構(gòu)）按照規(guī)定手續(xù)登記，

• 49152~65535：短暫端口號，是留給客戶進程選擇暫時使用，一個進程使用完就可以供其他進程使用。

在Socket使用時，可以用1024~65535的端口號

?那這里就隱藏了一個面試題：

既然一個ip主機的端口只有65535個，那為什么可以做到有幾百萬的socket鏈接呢？

哈哈，這是因為，我們的通信不是由 端口號 一人決定的呀。我們的通信識別一個通信 是由 5元組 (源IP地址、目標IP地址、源端口號、目標端口 和 協(xié)議號)來一起決定的。

在這里插入圖片描述

如圖：

① 和② 的通信是在兩臺計算機上進行的。它們的目標端口號相同，都是80。這里可以根據(jù)源端口號加以區(qū)分。

① 和③ 的目標端口號和源端口號完全相同，但它們各自的源 IP 地址不同。

此外，當 IP 地址和端口號全都一樣時，我們還可以通過協(xié)議號來區(qū)分（TCP 和 UDP）。

3. TCP和UDP

TCP/IP 中有兩個具有代表性的傳輸層協(xié)議，分別是 TCP 和 UDP。

3.1 TCP的定義和特點

• 定義：Transmission Control Protocol，即傳輸控制協(xié)議，是一種傳輸層通信協(xié)議

  基于TCP的應用層協(xié)議有FTP、Telnet、SMTP、HTTP、POP3與DNS。

• 特點：面向連接、面向字節(jié)流、全雙工通信、可靠

  • 面向連接：指的是要使用TCP傳輸數(shù)據(jù)，必須先建立TCP連接，傳輸完成后釋放連接，就像打電話一樣必須先撥號建立一條連接，打完后掛機釋放連接。
  • 全雙工通信：即一旦建立了TCP連接，通信雙方可以在任何時候都能發(fā)送數(shù)據(jù)。
  • 可靠的：指的是通過TCP連接傳送的數(shù)據(jù)，無差錯，不丟失，不重復，并且按序到達。
  • 面向字節(jié)流：流，指的是流入到進程或從進程流出的字符序列。簡單來說，雖然有時候要傳輸?shù)臄?shù)據(jù)流太大，TCP報文長度有限制，不能一次傳輸完，要把它分為好幾個數(shù)據(jù)塊，但是由于可靠性保證，接收方可以按順序接收數(shù)據(jù)塊然后重新組成分塊之前的數(shù)據(jù)流，所以TCP看起來就像直接互相傳輸字節(jié)流一樣，面向字節(jié)流。

3.2 UDP的定義和特點

• 定義：User Datagram Protocol，即用戶數(shù)據(jù)報協(xié)議，是一種傳輸層通信協(xié)議。

  基于UDP的應用層協(xié)議有TFTP、SNMP與DNS。

• 特點：無連接的、不可靠的、面向報文、沒有擁塞控制

  • 無連接的：和TCP要建立連接不同，UDP傳輸數(shù)據(jù)不需要建立連接，就像寫信，在信封寫上收信人名稱、地址就可以交給郵局發(fā)送了，至于能不能送到，就要看郵局的送信能力和送信過程的困難程度了。
  • 不可靠的：因為UDP發(fā)出去的數(shù)據(jù)包發(fā)出去就不管了，不管它會不會到達，所以很可能會出現(xiàn)丟包現(xiàn)象，使傳輸?shù)臄?shù)據(jù)出錯。
  • 面向報文：數(shù)據(jù)報文，就相當于一個數(shù)據(jù)包，應用層交給UDP多大的數(shù)據(jù)包，UDP就照樣發(fā)送，不會像TCP那樣拆分。
  • 沒有擁塞控制：擁塞，是指到達通信子網(wǎng)中某一部分的分組數(shù)量過多，使得該部分網(wǎng)絡來不及處理，以致引起這部分乃至整個網(wǎng)絡性能下降的現(xiàn)象，嚴重時甚至會導致網(wǎng)絡通信業(yè)務陷入停頓，即出現(xiàn)死鎖現(xiàn)象，就像交通堵塞一樣。TCP建立連接后如果發(fā)送的數(shù)據(jù)因為信道質(zhì)量的原因不能到達目的地，它會不斷重發(fā)，有可能導致越來越塞，所以需要一個復雜的原理來控制擁塞。而UDP就沒有這個煩惱，發(fā)出去就不管了。

應用場景
很多的實時應用（如IP電話、實時視頻會議、某些多人同時在線游戲等）要求源主機以很定的速率發(fā)送數(shù)據(jù)，并且允許在網(wǎng)絡發(fā)生擁塞時候丟失一些數(shù)據(jù)，但是要求不能有太大的延時，UDP就剛好適合這種要求。

? TCP 和 UDP 的優(yōu)缺點無法簡單地、絕對地去做比較：TCP 用于在傳輸層有必要實現(xiàn)可靠傳輸?shù)那闆r；而在一方面，UDP 主要用于那些對高速傳輸和實時性有較高要求的通信或廣播通信。TCP 和 UDP 應該根據(jù)應用的目的按需使用。

在說TCP的三次握手和四次揮手之前，我們還有必要來了解一下TCP的報文結(jié)構(gòu)，因為其中的幾個字段有助于我們更好的理解三次握手和四次揮手的過程。

4. TCP報文結(jié)構(gòu)

在這里插入圖片描述

我屬于那種用到什么才學點什么的懶加載式學習，因為學多了我也記不住

所以這里我就挑幾個重要字段來記錄一下：

• （1）序號：即seq序號（Sequence number），占32位，用來標識從TCP源端向目的端發(fā)送的字節(jié)流，發(fā)起方發(fā)送數(shù)據(jù)時對此進行標記。序號字段的值則指的是本報文段所發(fā)送的數(shù)據(jù)的第一個字節(jié)的序號。

• （2）確認號：即ack序號（Acknowledgment number），占32位，只有 ACK標志位 為1時，確認序號字段才有效，ack=seq+1。是指期望收到對方的下一個報文段的數(shù)據(jù)的第一個字節(jié)的序號。

• （3）標志位：共有6個標志位，即URG、ACK、PSH、RST、SYN、FIN等，具體含 義如下：

  確認ACK： 當ACK = 1時，確認字段有效，當ACK = 0時，確認字段無效。TCP規(guī)定，在連接創(chuàng)建后所有傳送的報文段須將ACK置為1

  同步SYN： 若SYN = 1，則表示這是請求建立連接。

  終止FIN: 釋放連接。當FIN = 1時，表示此報文段的發(fā)送方需要發(fā)送的數(shù)據(jù)已經(jīng)全部發(fā)送完畢，請求斷開連接。

  緊急URG: 當URG = 1，表示緊急指針字段有效。此時發(fā)送方TCP就將緊急數(shù)據(jù)插入到本報文的數(shù)據(jù)的最前面，后面順序不變，保證將緊急需要發(fā)送的最先發(fā)送。與最后的緊急指針配合使用。

  推送PSH： 接受方TCP接收到PSH = 1，表示該報文段高于優(yōu)先級，需要盡快地交付給接受應用程序，不需要等到整個TCP緩存都填滿了后在交付。
  復位 RST： 當RST = 1時，表示TCP連接發(fā)生嚴重錯誤，必須馬上釋放連接，重新建立新連接。

  ?

? 需要注意的是：
? （A）不要將確認序號ack與標志位中的ACK搞混了。
? （B）確認方ack=發(fā)起方seq+1，兩端配對。

那這個序列號（seq）和確認號 (ack) 有什么作用呢？

答：TCP中可以通過序列號與確認應答提高可靠性。

image

好，有了這些基礎，下面我們就來講TCP的三次握手了~

5. TCP中的三次握手▲▲▲（面試點）

5.1 描述一下TCP中三次握手的流程

在這里插入圖片描述

所謂三次握手是指建立一個 TCP 連接時需要客戶端和服務器端總共發(fā)送三個包以確認連接的建立。

【詳細的描述】是這樣的：

• 第一次握手：建立連接?？蛻舳税l(fā)送連接請求報文段，將SYN位置為1，seq(Sequence Number)為 J ；然后，客戶端進入SYN_SEND狀態(tài)，等待服務器的確認。

• 第二次握手：服務器端收到數(shù)據(jù)包后由標志位SYN=1知道客戶端請求建立連接，服務器端將標志位SYN和ACK都置為1，ack=J+1，隨機產(chǎn)生一個值seq=K，并將該數(shù)據(jù)包發(fā)送給客戶端以確認連接請求，服務器端進入SYN_RCVD狀態(tài)。

• 第三次握手：客戶端收到確認后，檢查ack是否為J+1，ACK是否為1，如果正確則將標志位ACK置為1，ack=K+1，并將該數(shù)據(jù)包發(fā)送給服務器端，服務器端檢查ack是否為K+1，ACK是否為1，如果正確則連接建立成功，客戶端和服務器端進入ESTABLISHED狀態(tài)，完成三次握手，隨后客戶端與服務器端之間可以開始傳輸數(shù)據(jù)了。

【簡單點描述】也就是：

• 第一次握手 → 客戶端請求建立連接。

• 第二次握手 → 服務端應答客戶端，并請求建立連接。

• 第三次握手 → 客戶端針對服務端請求確認應答。

這樣就完成TCP三次握手 = 一條TCP連接建立完成 = 可以開始發(fā)送數(shù)據(jù)

注意 1.三次握手期間任何一次未收到對面回復都要重發(fā)。

? 2.最后一個確認報文段發(fā)送完畢以后，客戶端和服務器端都進入ESTABLISHED狀態(tài)。

5.2 為什么TCP建立連接需要三次握手？

為了防止服務器端因為接收了早已失效的連接請求報文從而一直等待客戶端請求，從而浪費資源。

再分析具體一點就是：

• “已失效的連接請求報文段”的產(chǎn)生在這樣一種情況下：Client發(fā)出的第一個連接請求報文段并沒有丟失，而是在某個網(wǎng)絡結(jié)點長時間的滯留了，以致延誤到連接釋放以后的某個時間才到達server。
• 這是一個早已失效的報文段。但Server收到此失效的連接請求報文段后，就誤認為是Client再次發(fā)出的一個新的連接請求。
• 于是就向Client發(fā)出確認報文段，同意建立連接。
• 假設不采用“三次握手”：只要Server發(fā)出確認，新的連接就建立了。
• 由于現(xiàn)在Client并沒有發(fā)出建立連接的請求，因此不會向Server發(fā)送數(shù)據(jù)。
• 但Server卻以為新的運輸連接已經(jīng)建立，并一直等待Client發(fā)來數(shù)據(jù)。>- 這樣，Server的資源就白白浪費掉了。

而采用了三次握手之后，上述問題就不會發(fā)生。一切都會按照下面的正確腳步進行：

• Client不會向Server的確認發(fā)出確認
• Server由于收不到確認，就知道Client并沒有要求建立連接
• 所以Server不會等待Client發(fā)送數(shù)據(jù)，資源就沒有被浪費

5.3 TCP三次握手有什么漏洞嗎（知道即可）

漏洞：? SYN洪泛攻擊

? 定義：

通過網(wǎng)絡服務所在的端口發(fā)送大量偽造原地址的攻擊報文，發(fā)送到服務端，造成服務端上的半開連接隊列被占滿，從而阻止其他用戶進行訪問。

? 原理：

攻擊者客戶端利用偽造的IP地址向服務端發(fā)出請求(第一次握手)，而服務端的響應(第二次握手)的報文將永遠發(fā)送不到真實的客戶端，服務端在等待客戶端的第三次握手(永遠都不會有的)，服務端在等待這種半開的連接過程中消耗了資源，如果有成千上萬的這種連接，主機資源將被耗盡，從而達到攻擊的目的。

? 解決方案：

無效連接監(jiān)控釋放

延緩TCB分配方法

防火墻

6.TCP中的四次揮手（面試點▲）

6.1 描述一下TCP中四次揮手的流程

在這里插入圖片描述

四次揮手即終止TCP連接，就是指斷開一個TCP連接時，需要客戶端和服務端總共發(fā)送4個包以確認連接的斷開。

注意：可以是客戶端先發(fā)出中斷，也可以是服務器端先發(fā)出中斷。甚至是兩方同時發(fā)出中斷的情況也是有的！

【詳細的描述】是這樣的：

• 第一次揮手：客戶端發(fā)送一個FIN=M，用來關閉客戶端到服務器端的數(shù)據(jù)傳送，客戶端進入FIN_WAIT_1狀態(tài)。意思是說"我客戶端沒有數(shù)據(jù)要發(fā)給你了"，但是如果你服務器端還有數(shù)據(jù)沒有發(fā)送完成，則不必急著關閉連接，可以繼續(xù)發(fā)送數(shù)據(jù)。

• 第二次揮手：服務器端收到FIN后，先發(fā)送ack=M+1，告訴客戶端，你的請求我收到了，但是我還沒準備好，請繼續(xù)你等我的消息。這個時候客戶端就進入FIN_WAIT_2 狀態(tài)，繼續(xù)等待服務器端的FIN報文。

• 第三次揮手：當服務器端確定數(shù)據(jù)已發(fā)送完成，則向客戶端發(fā)送FIN=N報文，告訴客戶端，好了，我這邊數(shù)據(jù)發(fā)完了，準備好關閉連接了。服務器端進入LAST_ACK狀態(tài)。

• 第四次揮手：客戶端收到FIN=N報文后，就知道可以關閉連接了，但是他還是不相信網(wǎng)絡，怕服務器端不知道要關閉，所以發(fā)送ack=N+1后進入TIME_WAIT狀態(tài)，如果Server端沒有收到ACK則可以重傳。服務器端收到ACK后，就知道可以斷開連接了?？蛻舳说却?MSL后依然沒有收到回復，則證明服務器端已正常關閉，那好，我客戶端也可以關閉連接了。最終完成了四次握手。

【簡單點描述】也就是：

• 第一次揮手：客戶端發(fā)送關閉請求

• 第二次揮手：服務端響應客戶端關閉請求

• 第三次揮手：服務端發(fā)送關閉請求

• 第四次揮手：客戶端發(fā)送關閉確認請求

6.2 為什么TCP釋放連接需要四次揮手？

為了保證雙方都能通知對方“需要釋放連接”，即在釋放連接后都無法接收或發(fā)送消息給對方

• 需要明確的是：TCP是全雙工模式，這意味著是雙向都可以發(fā)送、接收的

• 釋放連接的定義是：雙方都無法接收或發(fā)送消息給對方，是雙向的

• 當主機1發(fā)出“釋放連接請求”（FIN報文段）時，只是表示主機1已經(jīng)沒有數(shù)據(jù)要發(fā)送 / 數(shù)據(jù)已經(jīng)全部發(fā)送完畢；

  但是，這個時候主機1還是可以接受來自主機2的數(shù)據(jù)。

• 當主機2返回“確認釋放連接”信息（ACK報文段）時，表示它已經(jīng)知道主機1沒有數(shù)據(jù)發(fā)送了
  但此時主機2還是可以發(fā)送數(shù)據(jù)給主機1

• 當主機2也發(fā)送了FIN報文段時，即告訴主機1我也沒有數(shù)據(jù)要發(fā)送了
  此時，主機1和2已經(jīng)無法進行通信：主機1無法發(fā)送數(shù)據(jù)給主機2，主機2也無法發(fā)送數(shù)據(jù)給主機1，此時，TCP的連接才算釋放

6.3 為什么建立連接是三次握手，而關閉連接卻是四次揮手呢，為什么2、3兩次不能合并呢？

這是因為服務端在LISTEN狀態(tài)下，收到建立連接請求的SYN報文后，把ACK和SYN放在一個報文里發(fā)送給客戶端。而關閉連接時，當收到對方的FIN報文時，僅僅表示對方不再發(fā)送數(shù)據(jù)了但是還能接收數(shù)據(jù)，己方也未必全部數(shù)據(jù)都發(fā)送給對方了，所以己方可以立即close，也可以發(fā)送一些數(shù)據(jù)給對方后，再發(fā)送FIN報文給對方來表示同意現(xiàn)在關閉連接，因此，己方ACK和FIN一般都會分開發(fā)送。

7.TCP協(xié)議中的窗口機制（拓展，了解一下即可）

在這里插入圖片描述

滑動窗口

發(fā)送方和接收方都會維護一個數(shù)據(jù)幀的序列，這個序列被稱作窗口。

發(fā)送方的窗口大小由接收方確認。

目的：

1.確保數(shù)據(jù)不丟失

? 如果發(fā)送的數(shù)據(jù)丟失了可以重新發(fā)。

2.控制發(fā)送速度

? 控制發(fā)送速度，以免接收方的緩存不夠大導致溢出，同時控制流量也可以避免網(wǎng)絡擁塞。

嗯吶，學習中，如有不正確的地方，希望可以一起討論呀~