可以使用左側的目錄進行跳轉哦~

如有問題，歡迎指出~

如果你也是一名熱愛編程" />

国产成人精品无码青草_亚洲国产美女精品久久久久∴_欧美人与鲁交大毛片免费_国产果冻豆传媒麻婆精东

15158846557 或 在線咨詢 在線咨詢
15158846557 或 在線咨詢
所在位置： 首頁 > 營銷資訊 > 網(wǎng)站運營 > 互聯(lián)網(wǎng)公司最常見的面試題總結（計算機網(wǎng)絡）

互聯(lián)網(wǎng)公司最常見的面試題總結（計算機網(wǎng)絡）

時間：2023-06-17 10:12:02 | 來源：網(wǎng)站運營

時間：2023-06-17 10:12:02 來源：網(wǎng)站運營

互聯(lián)網(wǎng)公司最常見的面試題總結（計算機網(wǎng)絡）：

寫在前面

本文總結的面試題僅僅是自己當時準備實習以及秋招時的一些總結，希望能給大家一些幫助~

可以使用左側的目錄進行跳轉哦~

如有問題，歡迎指出~

如果你也是一名熱愛編程的程序猿or程序媛，就關注我吧~

我將會分享身邊不同專業(yè)、不同工作崗位的小伙伴們的相關專業(yè)選擇以及求職經(jīng)驗，希望能給你人生中一些重要的決定，一些啟發(fā)～

（微信號：我是一名程序媛，b站號：我是一名程序媛）




概述

OSI七層協(xié)議模型及其協(xié)議？

法律上的國際標準

1）物理層：在物理介質(zhì)上進行比特流的傳輸，協(xié)議：IEEE802協(xié)議簇

2）數(shù)據(jù)鏈路層：將上層數(shù)據(jù)封裝成幀，基于MAC地址進行傳輸，協(xié)議：CSMA/CD（載波監(jiān)聽多點接入/碰撞檢測）協(xié)議、PPP點對點協(xié)議、ARP協(xié)議、RARP協(xié)議

3）網(wǎng)絡層：根據(jù)IP地址確定數(shù)據(jù)包的轉發(fā)地址，協(xié)議：IP協(xié)議、ICMP協(xié)議

4）傳輸層：建立端到端的通信，協(xié)議：TCP、UDP協(xié)議

5）會話層：不同用戶之間建立以及管理會話，協(xié)議：RPL協(xié)議

6）表示層：信息的語法語義及其關聯(lián)，協(xié)議：GIF、JPEG協(xié)議

7）應用層：應用進程之間的通信與交互，協(xié)議：HTTP、DNS、FTP協(xié)議




TCP/IP的四層網(wǎng)絡模型？

事實上的國際標準

1）網(wǎng)絡接口層

2）網(wǎng)際層

3）傳輸層

4）應用層

其中網(wǎng)絡接口層沒有規(guī)定什么具體的內(nèi)容，其目的是為了互連世界上不同的網(wǎng)絡接口







各個層的網(wǎng)絡設備？

1）物理層：集線器、中繼器

2）數(shù)據(jù)鏈路層：交換機、網(wǎng)橋

3）網(wǎng)絡層：路由器

計算機網(wǎng)絡體系結構為什么要進行分層？

1）可以將龐大復雜的問題，轉化為若干較小的局部問題

2）每一層解決不同的問題，方便開發(fā)

分層設計的好處是每個層次只負責自己的那部分事情，一層套一層，自己那層的任務完成了就交給下一層處理，各司其職，每層都遵守自己的規(guī)則，配合起來完成網(wǎng)絡通信的工作，不至于大家都攪在一起，職責不明，看起來混亂。

數(shù)據(jù)交換的三種方式？

1）電路交換

線路的利用率相對而言比較低

2）分組交換

將較長的報文劃分為更小的等長數(shù)據(jù)段，并在數(shù)據(jù)段前面加上一些必要的控制信息，就構成了一個個的分組，也叫做包，

3）報文交換

每次發(fā)送完整的報文，需要有較大的緩存。

三種不同的數(shù)據(jù)交換方式可參考：

計算機網(wǎng)絡微課堂（有字幕無背景音樂版）（陸續(xù)更新中......）_嗶哩嗶哩_bilibili

物理層

物理層的主要功能？

解決在各種傳輸媒體上傳輸比特0和1的問題，進而為數(shù)據(jù)鏈路層提供透明傳輸比特流的服務；

物理層協(xié)議的主要任務：

1）機械特性

2）電氣特性

3）功能特性

4）過程特性




物理層的傳輸媒體？

傳輸媒體不屬于計算機網(wǎng)絡體系結構中的任何一層?？煞譃?br>
1）導引型傳輸媒體

2）非導引型傳輸媒體

數(shù)據(jù)鏈路層

數(shù)據(jù)鏈路層的主要功能？

主要解決數(shù)據(jù)在鏈路上以幀為單位傳輸和處理數(shù)據(jù)。更加關注的是如何在局域網(wǎng)內(nèi)傳輸數(shù)據(jù)。

數(shù)據(jù)鏈路層的三個問題？

1）封裝成幀

2）差錯檢測

3）可靠傳輸

封裝成幀？

給上層交付的協(xié)議數(shù)據(jù)單元添加幀頭和幀尾使之成為幀。

幀頭和幀尾的作用之一就是幀定界，進而可以從物理層中的比特流中提取出幀，但是不是所有的幀頭和幀尾都有幀定界。

透明傳輸？

數(shù)據(jù)鏈路層對上層交付的傳輸數(shù)據(jù)沒有任何限制，什么數(shù)據(jù)都可以進行傳輸，你感受不到數(shù)據(jù)鏈路層的存在。

透明傳輸其實就是指無論是什么報文都可以傳輸，非透明傳輸就是指某些特殊字符不能傳輸，在計算機網(wǎng)絡中，透明傳輸在數(shù)據(jù)鏈路層提到過，在數(shù)據(jù)鏈路層將網(wǎng)絡層協(xié)議封裝成幀時，會在首部和尾部分別添加SOH以及EOT這兩個特殊字符，接收方是根據(jù)這兩個字符來確定幀首和幀尾的，如果上層協(xié)議發(fā)送過來的數(shù)據(jù)(即鏈路層的數(shù)據(jù)部分)包含EOT，那么接收方在解析這個幀的時候就會誤以為數(shù)據(jù)已經(jīng)結束，所以，如果鏈路層對這種情況沒有特殊處理，那么就可以理解鏈路層為非透明傳輸(因為無法傳輸EOT這個字符)，但是數(shù)據(jù)鏈路層通過對這個字符添加轉移符(如果網(wǎng)絡層數(shù)據(jù)中還存在轉移符，就再添加一個轉移符)的辦法來使數(shù)據(jù)部分可以傳輸EOT字符，就實現(xiàn)了透明傳輸。

差錯檢測？

比特在傳輸?shù)倪^程中可能會出現(xiàn)差錯，1可能會變成0，0可能變成1，這叫做比特差錯。

可以使用差錯檢測碼來檢測數(shù)據(jù)在傳輸過程中是否產(chǎn)生了比特差錯。

檢測碼只能檢測是否出現(xiàn)了差錯，但無法定位錯誤，即無法糾正錯誤。

可靠傳輸？

數(shù)據(jù)鏈路層通常使用差錯檢測技術檢測幀在傳輸過程中是否產(chǎn)生了誤碼。此時根據(jù)數(shù)據(jù)鏈路層向上層提供的服務類型決定處理的方式：

1）不可靠傳輸服務：僅僅丟棄有誤碼的幀。

2）可靠傳輸服務：想辦法實現(xiàn)發(fā)送端發(fā)送什么，接收端就收到什么













可靠傳輸?shù)膶崿F(xiàn)方式？

1）停止等待協(xié)議SW







確認和應答、超時重傳







發(fā)送方分組編號來避免分組重復，

接收方分組編號來避免發(fā)送方收到的確認分組重復

2）回退N幀協(xié)議GBN

接收窗口大小為1，一個數(shù)據(jù)分組的誤碼會導致其后續(xù)多個數(shù)據(jù)分組不能被接收方按序接收而丟棄。

3）選擇重傳協(xié)議SR

接收窗口大小大于1，接收方先收下失序到達但無誤碼并且序號落在接收窗口內(nèi)的那些數(shù)據(jù)分組。

數(shù)據(jù)鏈路層可靠嗎？

數(shù)據(jù)鏈路層協(xié)議只是針對網(wǎng)絡內(nèi)部的數(shù)據(jù)鏈路如何通信，只能保證某個網(wǎng)絡或某段鏈路可靠，對于互聯(lián)各式網(wǎng)絡的互聯(lián)網(wǎng)來說，數(shù)據(jù)鏈路層肯定是不可靠的。

數(shù)據(jù)鏈路層可以提供可靠傳輸，為什么還說UDP是不可靠的？

數(shù)據(jù)鏈路層可以實現(xiàn)無差錯的數(shù)據(jù)幀的交付，但是并不一定一定要實現(xiàn)，這個實現(xiàn)是需要有代價的，比如HDLC協(xié)議等等，HDLC采用CRC校驗，并且對所有的幀進行編號，通過序和確認機制，可以防止漏發(fā)和重發(fā)。事實上，HDLC是互聯(lián)網(wǎng)初期的時候較常使用的數(shù)據(jù)鏈路層的協(xié)議，因為那個時候數(shù)據(jù)鏈路層的傳輸不是非常可靠。

現(xiàn)在使用的大部分是PPP協(xié)議，ppp協(xié)議只提供差錯檢測但不提供糾錯，他同樣使用的也是CRC校驗，只能夠保證無差錯接收，但是由于不適用序列號和確認機制，所以無法檢測重發(fā)和漏發(fā)。

如果對于所有的數(shù)據(jù)幀都使用可靠的數(shù)據(jù)鏈路層協(xié)議來保證數(shù)據(jù)鏈路層的可靠傳輸?shù)脑?，那么無疑會極大地增加網(wǎng)絡的負擔。事實上，網(wǎng)絡中許多的數(shù)據(jù)并不一定都需要保證可靠傳輸，因此隨著網(wǎng)絡的發(fā)展，數(shù)據(jù)鏈路層將保證數(shù)據(jù)可靠傳輸交由上層的傳輸層來控制（UDP和TCP等等）。而數(shù)據(jù)鏈路層大部分使用不一定可靠的PPP協(xié)議等等。

最最重要的是：傳輸層是端到端的，數(shù)據(jù)鏈路層是點到點的，想要保證端到端的可靠傳輸就必須在傳輸層做文章，僅僅在保證數(shù)據(jù)鏈路層各個點之間的可靠傳輸也不能保證上層數(shù)據(jù)的可靠性，依然會出現(xiàn)丟包等情況的出現(xiàn)。即數(shù)據(jù)鏈路層只能保證在某個鏈路上傳輸是可靠的

PPP協(xié)議？

PPP協(xié)議是數(shù)據(jù)鏈路層的點對點的協(xié)議。

接收方每收到一個PPP幀，就進行CRC檢驗，若檢驗正確，則收下，反之則丟棄。使用PPP的數(shù)據(jù)鏈路層向上提供面向連接的不可靠的傳輸服務。

CSMA/CD？

多點接入 載波監(jiān)聽 碰撞檢測

MAC地址？







MAC地址也叫做物理地址或者硬件地址，其屬于數(shù)據(jù)鏈路層。

嚴格來說，MAC地址是對網(wǎng)絡上各接口的唯一標識，而不是各設備的唯一標識。

IP地址？

IP地址是因特網(wǎng)上的主機和路由器所使用的地址，用于標識兩部分信息：

如果只是一個單獨的網(wǎng)絡，不接入因特網(wǎng)，可以只用MAC地址

如果主機所在的網(wǎng)絡需要接入因特網(wǎng)，則IP地址和MAC地址均需要使用

數(shù)據(jù)包轉發(fā)過程中源IP地址和目的IP地址保持不變；

數(shù)據(jù)包轉發(fā)過程中源MAC地址和目的MAC地址逐個鏈路（或逐個網(wǎng)絡）改變。

ARP地址解析協(xié)議？

ARP協(xié)議的目的是將IP地址轉化為對應的MAC地址，且ARP協(xié)議只能在一個鏈路或一個網(wǎng)絡上使用，不能跨網(wǎng)絡使用

1）查看主機的ARP高速緩存表

2）若未找到，則以廣播的形式發(fā)送ARP請求報文，其格式為我的IP為，我的MAC為，我想知道IP為xxx的MAC地址

3）收到后先將其保存在自己的ARP高速緩存表中，同時給其發(fā)送ARP響應報文，其為單播幀

4）收到后保存至自己的ARP高速緩存表中

網(wǎng)絡層

網(wǎng)絡層的主要功能？

網(wǎng)絡層的主要任務是實現(xiàn)網(wǎng)絡的互連，進而實現(xiàn)數(shù)據(jù)包在各網(wǎng)絡之間的傳輸。

廣播數(shù)據(jù)報是隔離路由器的，即路由器收到后并不會進行轉發(fā)。

網(wǎng)絡層的相關協(xié)議？

1）IP協(xié)議

2）ARP協(xié)議

3）ICMP協(xié)議：主機或者路由器使用其來發(fā)送差錯報告報文和詢問報文。

4）IGMP協(xié)議

網(wǎng)絡層的三個問題？

1）向上提供何種服務

2）網(wǎng)絡層的尋址問題

3）路由選擇問題

路由選擇協(xié)議？

1）內(nèi)部網(wǎng)關協(xié)議IGP

2）外部網(wǎng)關協(xié)議EGP

OSPF算法？

1）“開放”表明其不是受某一家廠商控制，而是公開發(fā)表的

2）“最短路徑優(yōu)先”是因為使用了Dijkstra提出的最短路徑算法

IP協(xié)議的特點？

IP協(xié)議為上層協(xié)議提供無狀態(tài)、無連接、不可靠的服務。



















IP包頭部結構？



















這里的報頭長度為IP報文首部的長度，總長度為頭部和數(shù)據(jù)加起來的長度。

傳輸層

傳輸層的主要功能？

實現(xiàn)應用進程之間的通信，也叫做端到端之間的通信。

TCP和UDP的區(qū)別？

TCP（Transmission Control Protocol，傳輸控制協(xié)議）和UDP（User Datagram Protocol，用戶數(shù)據(jù)報協(xié)議）是傳輸層中兩個重要的協(xié)議。

1）TCP是面向連接的，UDP是無連接的

2）TCP是可靠的傳輸，通過消息確認以及超時重傳等機制保證數(shù)據(jù)傳輸?shù)目煽啃?，UDP是盡最大努力交付，是不可靠的

3）TCP是面向字節(jié)流的，會將大塊數(shù)據(jù)分割成以報文為單位的數(shù)據(jù)包進行傳輸，適合發(fā)送數(shù)據(jù)比較多的場景，UDP是面向應用報文的，一個數(shù)據(jù)包會發(fā)送全部內(nèi)容，適合數(shù)據(jù)量少的

4）TCP建立連接時需要三次握手，斷開連接時需要四次揮手，并且在傳輸過程中需要消息確認以及重傳機制來確保可靠性，因而比較慢，UDP比較快，效率高

5）UDP無擁塞控制，網(wǎng)絡出現(xiàn)擁塞時不會對數(shù)據(jù)傳輸產(chǎn)生影響，而TCP不然

6）TCP是一對一的，UDP支持一對一、一對多、多對一、多對多的場景

TCP和UDP的適用場景？

1）TCP

2）UDP

TCP包頭部結構？

TCP報文長度是可變的，因為其有可選項&填充項。













其中報頭長度為整個TCP報文頭部的長度，最小是20字節(jié)，即可選項&填充項為空，最長為60字節(jié)。

當確認號增加到最后一個后，下一個確認號就又回到0。













UDP包頭部結構？

TCP報文長度是固定的。













長度固定，所以沒有報文長度這個字段，只有報文總長度的字段。

其中校驗和字段只能檢測出是否存在誤碼，但無法進行糾正或其它處理。

TCP的首部中沒有長度字段，那怎么知道報文該到哪里結束？

TCP的報文封裝在IP內(nèi)部，在IP頭部中，有兩個字段，分別是IP頭部長和IP總長，因此，總長減去頭部長就可以得到數(shù)據(jù)部分的長度，也就是傳輸層封裝的數(shù)據(jù)的長度，TCP的首部中包含有頭部的長度，因此可以得到TCP報文的數(shù)據(jù)的部分的長度。

TCP三次握手的過程？

TCP是面向連接的，安全可靠的傳輸層協(xié)議，三次握手是為了建立一個安全可靠的連接。

1）客戶端向服務器發(fā)起連接請求，其會發(fā)送一個請求連接的報文，將SYN設置為1（表明是請求建立連接），同時發(fā)送一個sequence number

2）服務器收到后向客戶端發(fā)送消息確認報文，ACK置為1，SYN為1，同時發(fā)送一個ack number以及sequence number，此時客戶端知道我能夠給服務器發(fā)送消息并且服務器也可以收到

3）客戶端給服務器做出回應，ACK置為1，同時發(fā)送一個ack number，此時服務器知道我能夠給客戶端發(fā)送消息并且客戶端也可以收到

TCP為什么是三次握手？

1）首先描述一下三次握手的過程，其確保通信雙方都能發(fā)送且對方能夠收到該數(shù)據(jù)

2）為了實現(xiàn)可靠的傳輸，TCP協(xié)議的通信雙方都必須維護一個序列號，用以標識發(fā)送出去的數(shù)據(jù)中哪些是對方已經(jīng)接收到的。三次握手是通信雙方相互告知序列起始值，并確認對方收到該值的過程。

3）兩次不夠，四次則過多。

4）如果是兩次的話，可能會導致已經(jīng)失效的TCP連接請求報文段突然又傳送到了TCP服務器，因而導致錯誤。







TCP四次揮手的過程？

1）客戶端向服務器發(fā)送斷開連接請求，在請求報文中將FIN置為1

2）服務器收到后知道客戶端想和我斷開連接，但此時可能還沒有做好準備，服務器可能需要繼續(xù)發(fā)送還未發(fā)完的數(shù)據(jù)，此時服務器先進行消息確認，確認報文中ACK置為1，先告訴客戶端我知道了你想和我斷開連接

3）服務器等到數(shù)據(jù)發(fā)送完成后，則發(fā)送一個斷開連接報文，將FIN置為1

4）客戶端收到后給服務器發(fā)送一個消息確認報文，將ACK置為1

TCP為什么是四次揮手？

1）四次揮手的目的是終止數(shù)據(jù)傳輸，必須等到雙方都沒有數(shù)據(jù)進行傳輸時才會斷開

2）三次揮手的話，服務器收到斷開連接報文后需同時回復ACK與FIN消息，但是此時可能數(shù)據(jù)還沒有傳輸完

半關閉、半連接、半打開

1）半關閉：TCP四次揮手過程中，A向B發(fā)送斷開連接請求報文，B收到并進行回復后沒有發(fā)送FIN給A，此時A處于半關閉狀態(tài)，它可以接收B發(fā)來的數(shù)據(jù)，但是不能給B發(fā)送數(shù)據(jù)

2）半連接：TCP三次握手過程中，A向B發(fā)送請求連接報文，B收到并進行回復后，但是A不進行第三次握手，這就是半連接，如果多次對B采取這樣的措施會導致B分配的資源一直這么耗著，直至資源耗盡，無法處理正常的連接請求

3）半打開：連接中一方異常關閉且另外一方并不知情，不通信是不會發(fā)現(xiàn)的，通信時A向B發(fā)送數(shù)據(jù)，B收到后發(fā)現(xiàn)連接并不存在，則發(fā)送RST（reset）包告知并重新建立連接

2MSL是什么，為什么需要它？

MSL：報文最大生存時間，即發(fā)送報文直至對方接收到的最長時間

2MSL：服務器在一定時間內(nèi)未收到客戶端的應答報文則進行重傳，即客戶端（請求斷開連接的一方）在第四次揮手的時候不會立刻進入closed狀態(tài)，而是進入time-wait狀態(tài)

1）客戶端發(fā)送的回復報文如果丟失，服務器在2MSL內(nèi)未收到則會重新發(fā)送斷開連接請求報文，如果直接closed，客戶端則無法收到服務器新發(fā)送的斷開連接請求報文，服務器無法關閉，造成半關閉

2）等待一段時間是為了讓本連接所產(chǎn)生的報文均從網(wǎng)絡上消失，下次連接不會出現(xiàn)舊的報文。若客戶端關閉了，那么它可以建立一個與剛剛關閉的連接相似的連接（IP地址與端口號相同），新的連接可能會收到原來連接上產(chǎn)生的TCP報文，這顯然是不正確的

什么是?；钣嫊r器？







TCP的可靠傳輸是如何實現(xiàn)的？

（1）序列號、確認應答、超時重傳: 數(shù)據(jù)到達接收方，接收方需要發(fā)出一個確認應答，表示已經(jīng)收到該數(shù)據(jù)段，并且確認序號會說明了它下一次需要接收的數(shù)據(jù)序列號。如果發(fā)送發(fā)遲遲未收到確認應答，那么可能是發(fā)送的數(shù)據(jù)丟失，也可能是確認應答丟失，這時發(fā)送方在等待一定時間后會進行重傳。這個時間一般是2RTT（報文段往返時間）+一個偏差值。

（2）窗口控制與高速重發(fā)控制/快速重傳（重復確認應答）: TCP會利用窗口控制來提高傳輸速度，意思是在一個窗口大小內(nèi)，不用一定要等到應答才能發(fā)送下一段數(shù)據(jù)，窗口大小就是無需等待確認而可以繼續(xù)發(fā)送數(shù)據(jù)的最大值。如果不使用窗口控制，每一個沒收到確認應答的數(shù)據(jù)都要重發(fā)。使用窗口控制，如果數(shù)據(jù)段1001-2000丟失，后面數(shù)據(jù)每次傳輸，確認應答都會不停地發(fā)送序號為1001的應答，表示我要接收1001開始的數(shù)據(jù)，發(fā)送端如果收到3次相同應答，就會立刻進行重發(fā)；但還有種情況有可能是數(shù)據(jù)都收到了，但是有的應答丟失了，這種情況不會進行重發(fā)，因為發(fā)送端知道，如果是數(shù)據(jù)段丟失，接收端不會放過它的，會瘋狂向它提醒……

（3）擁塞控制

TCP流量控制？

流量控制是為了控制發(fā)送方發(fā)送數(shù)據(jù)的速度從而確保接收方來得及進行接收，否則的話會觸發(fā)自動重傳機制造成網(wǎng)絡流量的浪費，采用滑動窗口的方法實現(xiàn)，接收方會通知發(fā)送方自己能夠接收的數(shù)據(jù)大小，發(fā)送方會發(fā)送大小不超過這個數(shù)據(jù)量的數(shù)據(jù)，也叫做“窗口”的大小，即rwnd。

可能會產(chǎn)生死鎖，即接收端接收窗口為0時，發(fā)送端不能繼續(xù)發(fā)送數(shù)據(jù)。

此時當接收端的窗口大小不為0時，會給發(fā)送方發(fā)送一個報文進行告知，但是如果該報文丟失了，則會產(chǎn)生死鎖，發(fā)送端等待接收端窗口不為0，接收端等待發(fā)送方發(fā)數(shù)據(jù)。

可以采用持續(xù)計時器，所接收端窗口為0，則啟動持續(xù)計時器，超時發(fā)送端則發(fā)送零窗口探測報文，若接收窗口仍為0，則重新啟動該持續(xù)計時器，即可打破死鎖的局面。

TCP擁塞控制？

擁塞控制是為了防止過多的數(shù)據(jù)注入網(wǎng)絡，造成網(wǎng)絡過載。

1）慢啟動：擁塞窗口（發(fā)送方動態(tài)變化的窗口cwnd）乘法增大

2）擁塞避免：當擁塞窗口和閾值相等是變?yōu)榧臃ㄔ龃?br>
3）快重傳：使發(fā)送方盡快進行重傳，而不是等超時計時器超時再重傳。

當收到三個重復的ACK確認報文時則重傳，而不是等待超時計時器超時。







這樣可以避免某些個別的報文在傳輸過程中丟失，從而錯誤的認為是網(wǎng)絡的擁塞導致了重傳計時器超時，執(zhí)行慢啟動從而造成較低的效率。

4）快恢復：當滿足快重傳條件時，說明網(wǎng)絡沒有問題，并不執(zhí)行慢開始，而是將閾值設置為原來的1/2，擁塞窗口設置為新的閾值大小，并執(zhí)行擁塞避免







什么時候會發(fā)生報文的重傳？

1）重傳計時器超時，即在設定時間內(nèi)沒有收到確認報文

2）發(fā)送端收到了三個重復的ACK報文時立即重傳

TCP粘包/拆包？

需要明確

1）TCP是面向字節(jié)流的，本身并沒有“包”這個概念

2）只有TCP會發(fā)生粘包、拆包的問題，UDP數(shù)據(jù)是有明確的界限的，不會發(fā)生這個問題

什么是粘包問題？

發(fā)送方發(fā)送的數(shù)據(jù)到達接收方時粘成一包，從接收緩沖區(qū)來看，后一包的數(shù)據(jù)頭緊跟前一包的尾

什么時候需要考慮粘包問題？

1）短連接時不會出現(xiàn)，長連接上一條連接會發(fā)送多條數(shù)據(jù)，需要考慮

2）發(fā)送數(shù)據(jù)無結構，不考慮順序時只管發(fā)送接收即可，不需要考慮，發(fā)送數(shù)據(jù)有順序則需要考慮

3）數(shù)據(jù)間沒有明確的界限則需要考慮

什么情況下會發(fā)生粘包、拆包？

1）發(fā)送數(shù)據(jù)大于TCP發(fā)送緩沖區(qū)時會發(fā)生拆包

2）發(fā)送數(shù)據(jù)大于最大報文長度時，TCP在傳輸前進行拆包

3）發(fā)送數(shù)據(jù)小于TCP發(fā)送緩沖區(qū)大小，TCP將多次寫入緩沖區(qū)的數(shù)據(jù)一次發(fā)送出去，將發(fā)生粘包

4）接收端未來得及接收緩沖區(qū)中的數(shù)據(jù)，下次請求到達時接收的是上一次未接收完的內(nèi)容，將發(fā)生粘包

粘包、拆包的解決方法？

1）消息定長：約定數(shù)據(jù)包的長度

2）設置消息邊界：比如說使用分隔符來進行區(qū)分，但是無法確保分隔符不會在報文中出現(xiàn)

3）將消息分為消息頭和消息體：即在消息頭中記錄當前數(shù)據(jù)包的長度

HTTP與TCP的區(qū)別？

1）HTTP是應用層的協(xié)議，TCP是傳輸層的協(xié)議

2）HTTP建立在TCP之上，當瀏覽器需要從服務器上獲取數(shù)據(jù)時，會發(fā)送HTTP請求，其通過TCP建立連接進而進行數(shù)據(jù)傳輸，結束后斷開TCP連接

3）TCP建立連接需要三次握手，HTTP則是請求與響應模式

UDP如何實現(xiàn)可靠傳輸？

使用UDP的傳輸層無法確保數(shù)據(jù)的可靠傳輸，只能通過應用層實現(xiàn)，具體可以參照TCP，如：確認和應答、超時重傳等機制

TCP和UDP可以使用相同的端口嗎？

可以。TCP和UDP為傳輸層下的兩個協(xié)議，IP數(shù)據(jù)包首部有個叫做協(xié)議的字段，指出了上層協(xié)議是TCP還是UDP協(xié)議，操作系統(tǒng)有能力根據(jù)接受的報文的IP字段里面的協(xié)議部分判斷這個報文是什么報文，就是說，系統(tǒng)讀數(shù)據(jù)的時候還沒有讀到上層報文（TCP/UDP）的時候已經(jīng)知道上層是什么報文了，直接交給相關的內(nèi)核進程或協(xié)議棧處理就可以了，而在同一個協(xié)議內(nèi)部端口號唯一。所以可以認為操作系統(tǒng)是以協(xié)議、IP以及端口號來綁定端口的。

應用層

HTTP協(xié)議是什么？

HTTP是位于應用層的無狀態(tài)的通信協(xié)議

HTTP狀態(tài)碼？

1）1xx：表示信息，即收到請求，需要請求者繼續(xù)執(zhí)行操作

2）2xx：表示成功，即成功接收并已經(jīng)處理

3）3xx：表示重定向

4）4xx：表示客戶端發(fā)生錯誤

5）5xx：表示服務器發(fā)生錯誤

200：ok，請求成功處理

204：no content，請求成功處理，但是沒有內(nèi)容返回，瀏覽器不會刷新頁面，也不會導向別的頁面

301：永久重定向

302：暫時重定向

404：not found，無法找到該資源

500：internal server error：服務器內(nèi)部錯誤

HTTP請求和響應報文的格式？

請求報文：

1）請求行：請求方法+URL+協(xié)議及其版本

2）請求頭（首部）

3）請求體

響應報文：

1）狀態(tài)行

2）響應頭（首部）

3）響應體

抓取HTTP報文？

可以借助于Wireshark工具

HTTP1.0與HTTP1.1的區(qū)別？

1.0是短連接，在一個TCP連接上只能傳送一個HTTP請求和響應，1.1是長連接，在一個連接上可以傳送多個HTTP請求和響應，減少了建立以及關閉連接的消耗和延遲

HTTP2.0的特性？

1）多路復用：在一個連接中可以并發(fā)多個請求與響應，而不必等到上一個接收到了再發(fā)送下一個，不會出現(xiàn)隊頭阻塞的問題

2）頭部壓縮：雙方同時維護一張頭信息表，將字段存入該表并生成索引號，每次只發(fā)送索引號即可，提高了速度

3）二進制格式：頭與數(shù)據(jù)均為二進制，統(tǒng)稱為幀，即頭信息幀和數(shù)據(jù)幀，對計算機比較友好，提高數(shù)據(jù)傳輸?shù)男?br>
4）服務器推送：服務器可以主動給客戶端發(fā)送消息，如必要的附加資源，不必等到客戶端請求

HTTP有哪些問題，如何解決這些問題？

1）竊聽：消息是明文傳輸，可以進行信息加密

2）纂改：發(fā)送的內(nèi)容可能會遭到篡改，可以采用校驗機制

3）冒充：可能會被不法分子偽造身份，可以使用身份證書，防止別人偽造身份

如何理解數(shù)字簽名？

數(shù)字簽名是為了確保消息沒有被篡改

1）服務器將報文hash后生成概要信息，再用私鑰對其進行加密，生成“數(shù)字簽名”，服務器將報文以及該簽名一同發(fā)送給客戶端

2）客戶端收到后用公鑰進行解密，得到摘要，可以正常解密說明是對方發(fā)出的

3）客戶端對報文使用相同的hash函數(shù)，如果與2）中的摘要相同則表明沒有被篡改

如何理解數(shù)字證書？

數(shù)字證書可以確認對方的身份

服務器將自己的公鑰拿去給“證書中心”（CA），為公鑰做認證，證書中心使用自己的私鑰對服務器的公鑰及其相關信息進行加密，得到“數(shù)字證書”

HTTPS建立連接的過程？

1）客戶端向服務器發(fā)起建立連接請求

2）服務器收到后將自己的數(shù)字證書以及公鑰發(fā)送給客戶端

3）客戶端使用“證書中心”的公鑰對證書進行解密，從而確認服務器的身份

4）身份無誤后客戶端會創(chuàng)建一個隨機密鑰且用服務器的公鑰進行加密

5）服務器使用私鑰得到該隨機密鑰，隨后雙方均使用該隨機密鑰進行數(shù)據(jù)的加密傳輸

對稱加密算法以及非對稱加密算法？

1）對稱加密算法：加密和解密使用相同的密鑰

優(yōu)點：計算量小，速度快，效率高

缺點：不安全，容易泄漏，為了安全，不同的會話需要使用不同的密鑰，管理起來比較費勁

有：IDEA

2）非對稱加密：使用公鑰進行加密，私鑰進行解密

優(yōu)點：安全，不容易泄漏

缺點：速度慢

有：RSA

HTTP和HTTPS的區(qū)別？

1）HTTP不安全，HTTPS采用信息加密、校驗機制以及證書認證的方式，因而是安全的

2）HTTP連接的建立比較簡單，TCP三次握手后即可進行報文的傳輸，HTTPS連接的建立相對比較復雜，三次握手之后還需要SSL/TSL握手的過程才可以進行數(shù)據(jù)的傳輸

3）HTTP端口號是80，HTTPS是443

4）HTTPS需要向“證書中心”（CA）做認證，來保證服務器身份可信，因而成本會高一些

get和post的區(qū)別？

1）get是從服務器上獲取資源，post是向服務器上提交資源

2）get是安全且冪等的，即不會更改服務器上的資源且多次請求得到的內(nèi)容相同，post是不安全且不冪等的

3）get請求的參數(shù)會顯示在地址欄，因而支持的數(shù)據(jù)量比較小且不安全，post請求的參數(shù)在請求體內(nèi)，因而支持的數(shù)據(jù)量比較大且安全

cookie的工作機制是什么樣的？

1）瀏覽器向服務器發(fā)送請求

2）服務器收到后會為其建立一個獨特的身份標識，在響應時將該標識連同響應信息一起發(fā)送給瀏覽器，瀏覽器收到后就將其存儲起來

3）瀏覽器再次發(fā)送請求時會將cookie連同請求信息發(fā)送給服務器

4）服務器收到后進行解析即可確認用戶身份

默認情況下關閉瀏覽器cookie就會失效

session的工作機制是什么樣的？

1）瀏覽器向服務器發(fā)送請求

2）服務器收到后會為其生成一個sessionid并將瀏覽器的信息保存起來，服務器將sessionid連同響應信息一起發(fā)送給瀏覽器，瀏覽器收到后就將其存儲起來

3）瀏覽器再次發(fā)送請求時會將cookie連同請求信息發(fā)送給服務器

4）服務器收到后進行解析得到sessionid，根據(jù)

sessionid查找相關信息即可確認用戶身份

從上面的流程中可以看出，session的使用依賴于cookie的支持，若cookie被禁用，則可以使用url重定向的方式，在每個使用sessionid的頁面的鏈接中加入sessionid

為什么會有cookie和session？它們之間的區(qū)別是什么？

因為HTTP是無狀態(tài)的，不能每次用戶請求都需要重新進行登錄，需要記錄用戶的信息

1）cookie存儲在瀏覽器中，session存儲在服務器上

2）cookie不安全，session安全

3）cookie可以減輕服務器負擔，session會加重服務器負擔

如何查看瀏覽器的cookie？

點擊F12打開開發(fā)者模式，在Console中輸入document.cookie即可







瀏覽器輸入URL到顯示頁面發(fā)生了什么？

1）應用層先進行DNS解析，根據(jù)URL得到目標主機的ip地址

2）應用層將請求的信息裝入HTTP報文，發(fā)送HTTP請求

3）傳輸層收到后將其分割成以報文段為單位的數(shù)據(jù)包進行管理，通過TCP三次握手與目標端口建立安全的通信

4）網(wǎng)絡層收到后根據(jù)ip地址通過ARP協(xié)議得到目標主機的mac地址

5）數(shù)據(jù)鏈路層進行數(shù)據(jù)的傳輸

6）到達服務器后會從下到上層層解包，直至應用層

7）服務器收到請求后，查找相應的資源并作出響應

8）瀏覽器顯示內(nèi)容

DNS解析的過程？

DNS的目的是將域名轉化為ip地址，使得用戶能夠更加方便的訪問互聯(lián)網(wǎng)，只需要記住域名即可

1）瀏覽器緩存

2）本機的hosts文件

3）本地域名服務器：如果本地域名服務器緩存中有，則直接返回結果，否則使用迭代查詢的方法依次詢問根域名服務器、頂級域名服務器以及主域名服務器







搜索欄是如何實現(xiàn)的呢？

1）字典樹進行匹配

2）倒排索引：通過關鍵字找文檔，即直接定位到該關鍵字所在的所有文檔，然后進行加載

普通索引：通過文檔去查找關鍵字

網(wǎng)絡安全

DDOS攻擊了解嗎？

分布式拒絕服務攻擊，不斷給服務器發(fā)送請求，占用服務器資源，使得服務器不能正常處理其它用戶的請求，使其不能給其他人服務

哈希攻擊了解嗎？

主要是針對哈希函數(shù)的特性，精心構造數(shù)據(jù)，使得數(shù)據(jù)的哈希值都相同，將這些數(shù)據(jù)保存在哈希表中，就會退化成單鏈表，解決的方法有使用可變的哈希函數(shù)。

sql注入是什么，如何解決？

在輸入框中輸入sql語句，使后臺執(zhí)行該語句，從而達到非法登錄系統(tǒng)等目的

1）對特殊字符進行轉義

2）預編譯

3）嚴格控制數(shù)據(jù)類型

關鍵詞：試題,總結,網(wǎng)絡,計算機

74
73
25
news

版權所有? 億企邦 1997-2025 保留一切法律許可權利。

為了最佳展示效果，本站不支持IE9及以下版本的瀏覽器，建議您使用谷歌Chrome瀏覽器。 點擊下載Chrome瀏覽器
關閉