電腦網路高頻面試題解析(含書籍推薦)

来源:https://www.cnblogs.com/binyue/archive/2020/02/03/12257268.html
-Advertisement-
Play Games

網路原理是工程師的必須瞭解的電腦基礎知識,先推薦下兩本好書,《圖解HTTP》和《圖解TCP/IP》。 《圖解TCP/IP》講解網路基礎知識、TCP/IP基礎知識、數據鏈路、IP協議、IP協議相關技術、TCP與UDP、路由協議、應用協議、網路安全等內容,《圖解HTTP》對HTTP協議進行了全面系統的 ...


網路原理是工程師的必須瞭解的電腦基礎知識,先推薦下兩本好書,《圖解HTTP》和《圖解TCP/IP》。

《圖解TCP/IP》講解網路基礎知識、TCP/IP基礎知識、數據鏈路、IP協議、IP協議相關技術、TCP與UDP、路由協議、應用協議、網路安全等內容,《圖解HTTP》對HTTP協議進行了全面系統的介紹,這兩本書的特點都是在講解的同時,配上了大量漫畫通信圖例,讀起來比較輕鬆。

高頻面試題解析

1、OSI七層網路模型的結構與功能

OSI是一個開放性的通信系統互連參考模型,OSI 七層模型通過七個層次化的結構模型使不同的系統不同的網路之間實現可靠的通訊。

OSI是一個定義得非常好的協議規範,但是比較複雜所以一般使用TCP/IP 的四層模型來描述。
就目前來說,TCP/IP 的四層模型更受廣泛認可,在電腦網路中,大家更多喜歡使用 TCP/IP 模型來進行劃分和理解。因為表示層、會話層以及應用層之間的界限在實際應用中並不清晰,讓人不好區分。

2、TCP/IP四層協議有哪些結構與功能

TCP/IP 參考模型是一個包含了不同網路層次的一系列網路協議的集合。一般 TCP/IP 參考考模型分為四層,從下到上分別是,數據鏈路層、網路層、傳輸層和應用層。

三種劃分方式的對應關係

也有將它分為五層的,也就是加上物理層,不過對於大部分的電腦網路應用,軟體工程師一般都是不關心物理層。

四層協議

應用層提供了不同應用數據包的處理協議。常見的有 HTTP、FTP、DNS、Email、Telnet 等。

傳輸層為應用程式提供了端到端的通信服務,該層的協議有兩個:TCP(Transmission Control Protocol,傳輸控制協議)和 UDP(User Datagram Protocol,用戶數據包協議)。其中 TCP 提供的是有連接可靠服務,UDP 提供的是無連接不可靠服務。

網路層也稱互聯網層,核心協議是 IP 協議,是路由演算法工作的主要層。

數據鏈路層包括了邏輯鏈路控制層(Logical Link Control,LLC)和介質訪問控制層(Media Access Control,MAC)兩個子層。LLC 負責識別網路層協議,然後對它們進行封裝。LLC 報頭告訴數據鏈路層一旦幀被接收到時,應當對數據包做何處理。數據鏈路層還包括了設備驅動程式部分的內容。

3、五層協議的體繫結構,都有哪些協議

上面說了四層協議,我們在四層協議的基礎上再來詳細的說明下五層協議。

(1)應用層

應用層(application-layer)的任務是通過應用進程間的交互來完成特定網路應用。應用層協議定義的是應用進程(進程:主機中正在運行的程式)間的通信和交互的規則。對於不同的網路應用需要不同的應用層協議。在互聯網中應用層協議很多,如功能變數名稱系統 DNS,支持萬維網應用的 HTTP 協議,支持電子郵件的 SMTP 協議等等。我們把應用層交互的數據單元稱為報文。

(2)運輸層

運輸層(transport layer)的主要任務就是負責向兩台主機進程之間的通信提供通用的數據傳輸服務。應用進程利用該服務傳送應用層報文。“通用的”是指並不針對某一個特定的網路應用,而是多種應用可以使用同一個運輸層服務。由於一臺主機可同時運行多個線程,因此運輸層有復用和分用的功能。所謂復用就是指多個應用層進程可同時使用下麵運輸層的服務,分用和復用相反,是運輸層把收到的信息分別交付上面應用層中的相應進程。

運輸層主要使用以下兩種協議:
傳輸控制協議 TCP(Transmisson Control Protocol)--提供面向連接的,可靠的數據傳輸服務。
用戶數據協議 UDP(User Datagram Protocol)--提供無連接的,盡最大努力的數據傳輸服務(不保證數據傳輸的可靠性)。

(3)網路層

網路層(network layer)負責為分組交換網上的不同主機提供通信服務。 在發送數據時,網路層把運輸層產生的報文段或用戶數據報封裝成分組和包進行傳送。在 TCP/IP 體繫結構中,由於網路層使用 IP 協議,因此分組也叫 IP 數據報 ,簡稱 數據報。
這裡要註意:不要把運輸層的“用戶數據報 UDP ”和網路層的“ IP 數據報”弄混。另外,無論是哪一層的數據單元,都可籠統地用“分組”來表示。
網路層的另一個任務就是選擇合適的路由,使源主機運輸層所傳下來的分株,能通過網路層中的路由器找到目的主機。
這裡強調指出,網路層中的“網路”二字已經不是我們通常談到的具體網路,而是指電腦網路體繫結構模型中第三層的名稱.
互聯網是由大量的異構(heterogeneous)網路通過路由器(router)相互連接起來的。互聯網使用的網路層協議是無連接的網際協議(Intert Prococol)和許多路由選擇協議,因此互聯網的網路層也叫做網際層或IP層。

(4)數據鏈路層

數據鏈路層(data link layer)通常簡稱為鏈路層。兩台主機之間的數據傳輸,總是在一段一段的鏈路上傳送的,這就需要使用專門的鏈路層的協議。 在兩個相鄰節點之間傳送數據時,數據鏈路層將網路層交下來的 IP 數據報組裝程幀,在兩個相鄰節點間的鏈路上傳送幀。每一幀包括數據和必要的控制信息(如同步信息,地址信息,差錯控制等)。
在接收數據時,控制信息使接收端能夠知道一個幀從哪個比特開始和到哪個比特結束。這樣,數據鏈路層在收到一個幀後,就可從中提出數據部分,上交給網路層。
控制信息還使接收端能夠檢測到所收到的幀中有誤差錯。如果發現差錯,數據鏈路層就簡單地丟棄這個出了差錯的幀,以避免繼續在網路中傳送下去白白浪費網路資源。如果需要改正數據在鏈路層傳輸時出現差錯(這就是說,數據鏈路層不僅要檢錯,而且還要糾錯),那麼就要採用可靠性傳輸協議來糾正出現的差錯。這種方法會使鏈路層的協議複雜些。

(5)物理層

在物理層上所傳送的數據單位是比特。
物理層(physical layer)的作用是實現相鄰電腦節點之間比特流的透明傳送,儘可能屏蔽掉具體傳輸介質和物理設備的差異。 使其上面的數據鏈路層不必考慮網路的具體傳輸介質是什麼。“透明傳送比特流”表示經實際電路傳送後的比特流沒有發生變化,對傳送的比特流來說,這個電路好像是看不見的。

4、TCP和UPD的主要特點對比

UDP 的主要特點
UDP 是無連接的;
UDP 使用盡最大努力交付,即不保證可靠交付,因此主機不需要維持複雜的鏈接狀態(這裡面有許多參數);
UDP 是面向報文的;
UDP 沒有擁塞控制,因此網路出現擁塞不會使源主機的發送速率降低(對實時應用很有用,如 直播,實時視頻會議等);
UDP 支持一對一、一對多、多對一和多對多的交互通信;
UDP 的首部開銷小,只有8個位元組,比TCP的20個位元組的首部要短。

TCP 的主要特點
TCP 是面向連接的。(就好像打電話一樣,通話前需要先撥號建立連接,通話結束後要掛機釋放連接);
每一條 TCP 連接只能有兩個端點,每一條TCP連接只能是點對點的(一對一);
TCP 提供可靠交付的服務。通過TCP連接傳送的數據,無差錯、不丟失、不重覆、並且按序到達;
TCP 提供全雙工通信。TCP 允許通信雙方的應用進程在任何時候都能發送數據。TCP 連接的兩端都設有發送緩存和接收緩存,用來臨時存放雙方通信的數據;
面向位元組流。TCP 中的“流”(Stream)指的是流入進程或從進程流出的位元組序列。“面向位元組流”的含義是:雖然應用程式和 TCP 的交互是一次一個數據塊(大小不等),但 TCP 把應用程式交下來的數據僅僅看成是一連串的無結構的位元組流。

5、TCP 三次握手和四次揮手

為了準確無誤地把數據送達目標處,TCP協議採用了三次握手策略。
我們看一下《圖解HTTP》的漫畫圖解:

具體操作的示意圖:

客戶端–發送帶有 SYN 標誌的數據包–一次握手–服務端
服務端–發送帶有 SYN/ACK 標誌的數據包–二次握手–客戶端
客戶端–發送帶有帶有 ACK 標誌的數據包–三次握手–服務端

6、為什麼要三次握手?

三次握手的目的是建立可靠的通信通道,說到通訊,簡單來說就是數據的發送與接收,而三次握手最主要的目的就是雙方確認自己與對方的發送與接收是正常的。
第一次握手:Client 什麼都不能確認;Server 確認了對方發送正常
第二次握手:Client 確認了:自己發送、接收正常,對方發送、接收正常;Server 確認了:自己接收正常,對方發送正常
第三次握手:Client 確認了:自己發送、接收正常,對方發送、接收正常;Server 確認了:自己發送、接收正常,對方發送接收正常
所以三次握手就能確認雙發收發功能都正常,缺一不可。

7、三次握手為什麼要傳回 SYN,為什麼要ACK

SYN 是 TCP/IP 建立連接時使用的握手信號。在客戶機和伺服器之間建立正常的 TCP 網路連接時,客戶機首先發出一個 SYN 消息,伺服器使用 SYN-ACK 應答表示接收到了這個消息,最後客戶機再以 ACK(Acknowledgement 確認字元 )消息響應。這樣在客戶機和伺服器之間才能建立起可靠的TCP連接,數據才可以在客戶機和伺服器之間傳遞。
接收端傳回發送端所發送的 SYN 是為了告訴發送端,我接收到的信息確實就是你所發送的信號了。
雙方通信無誤必須是兩者互相發送信息都無誤。傳了 SYN,證明發送方到接收方的通道沒有問題,但是接收方到發送方的通道還需要 ACK 信號來進行驗證。

8、為什麼要四次揮手

斷開一個 TCP 連接需要四次揮手:

  • 客戶端-發送一個 FIN,用來關閉客戶端到伺服器的數據傳送
  • 伺服器-收到這個 FIN,它發回一 個 ACK,確認序號為收到的序號加1 。和 SYN 一樣,一個 FIN 將占用一個序號
  • 伺服器-關閉與客戶端的連接,發送一個FIN給客戶端
  • 客戶端-發回 ACK 報文確認,並將確認序號設置為收到序號加1

任何一方都可以在數據傳送結束後發出連接釋放的通知,待對方確認後進入半關閉狀態。當另一方也沒有數據再發送的時候,則發出連接釋放通知,對方確認後就完全關閉了TCP連接。
舉個例子:A 和 B 打電話,通話即將結束後,A 說“我沒啥要說的了”,B回答“我知道了”,但是 B 可能還會有要說的話,A 不能要求 B 跟著自己的節奏結束通話,於是 B 可能又巴拉巴拉說了一通,最後 B 說“我說完了”,A 回答“知道了”,這樣通話才算結束。

9、TCP、UDP 協議的區別

UDP 在傳送數據之前不需要先建立連接,遠地主機在收到 UDP 報文後,不需要給出任何確認。雖然 UDP 不提供可靠交付,但在某些情況下 UDP 確是一種最有效的工作方式(一般用於即時通信),比如: QQ 語音、 QQ 視頻 、直播等等。

TCP 提供面向連接的服務。在傳送數據之前必須先建立連接,數據傳送結束後要釋放連接。
TCP 不提供廣播或多播服務。由於 TCP 要提供可靠的,面向連接的運輸服務(TCP的可靠體現在TCP在傳遞數據之前,會有三次握手來建立連接,而且在數據傳遞時,有確認、視窗、重傳、擁塞控制機制,在數據傳完後,還會斷開連接用來節約系統資源),這一難以避免增加了許多開銷,如確認,流量控制,計時器以及連接管理等。這不僅使協議數據單元的首部增大很多,還要占用許多處理機資源。TCP 一般用於文件傳輸、發送和接收郵件、遠程登錄等場景。

10、TCP 協議如何保證可靠傳輸

1)確認和重傳:接收方收到報文就會確認,發送方發送一段時間後沒有收到確認就會重傳。
2)數據校驗:TCP報文頭有校驗和,用於校驗報文是否損壞
3)數據合理分片和排序:
tcp會按最大傳輸單元(MTU)合理分片,接收方會緩存未按序到達的數據,重新排序後交給應用層。
而UDP:IP數據報大於1500位元組,大於MTU。這個時候發送方的IP層就需要分片,把數據報分成若幹片,是的每一片都小於MTU。而接收方IP層則需要進行數據報的重組。由於UDP的特性,某一片數據丟失時,接收方便無法重組數據報,導致丟棄整個UDP數據報。
4)流量控制:當接收方來不及處理髮送方的數據,能通過滑動視窗,提示發送方降低發送的速率,防止包丟失。
5)擁塞控制:當網路擁塞時,通過擁塞視窗,減少數據的發送,防止包丟失。

11、TCP 利用滑動視窗實現流量控制的機制

流量控制是為了控制發送方發送速率,保證接收方來得及接收。
TCP 利用滑動視窗實現流量控制。
滑動視窗(Sliding window)是一種流量控制技術。早期的網路通信中,通信雙方不會考慮網路的擁擠情況直接發送數據。由於大家不知道網路擁塞狀況,同時發送數據,導致中間節點阻塞掉包,誰也發不了數據,所以就有了滑動視窗機制來解決此問題。
TCP 中採用滑動視窗來進行傳輸控制,滑動視窗的大小意味著接收方還有多大的緩衝區可以用於接收數據。發送方可以通過滑動視窗的大小來確定應該發送多少位元組的數據。當滑動視窗為 0 時,發送方一般不能再發送數據報,但有兩種情況除外,一種情況是可以發送緊急數據,例如,允許用戶終止在遠端機上的運行進程。另一種情況是發送方可以發送一個 1 位元組的數據報來通知接收方重新聲明它希望接收的下一位元組及發送方的滑動視窗大小。

接收方發送的確認報文中的視窗欄位可以用來控制發送方視窗大小,從而影響發送方的發送速率。將視窗欄位設置為 0,則發送方不能發送數據。

12、TCP擁塞控制的機制以及演算法

在某段時間,若對網路中某一資源的需求超過了該資源所能提供的可用部分,網路的性能就要變壞。這種情況就叫擁塞。
擁塞控制就是為了防止過多的數據註入到網路中,這樣就可以使網路中的路由器或鏈路不致過載。擁塞控制所要做的都有一個前提,就是網路能夠承受現有的網路負荷。擁塞控制是一個全局性的過程,涉及到所有的主機,所有的路由器,以及與降低網路傳輸性能有關的所有因素。相反,流量控制往往是點對點通信量的控制,是個端到端的問題。流量控制所要做到的就是抑制發送端發送數據的速率,以便使接收端來得及接收。
為了進行擁塞控制,TCP 發送方要維持一個 擁塞視窗(cwnd) 的狀態變數。擁塞控制視窗的大小取決於網路的擁塞程度,並且動態變化。發送方讓自己的發送視窗取為擁塞視窗和接收方的接受視窗中較小的一個。
TCP的擁塞控制採用了四種演算法,即 慢開始 、 擁塞避免 、快重傳 和 快恢復。在網路層也可以使路由器採用適當的分組丟棄策略(如主動隊列管理 AQM),以減少網路擁塞的發生。

慢開始: 慢開始演算法的思路是當主機開始發送數據時,如果立即把大量數據位元組註入到網路,那麼可能會引起網路阻塞,因為現在還不知道網路的符合情況。經驗表明,較好的方法是先探測一下,即由小到大逐漸增大發送視窗,也就是由小到大逐漸增大擁塞視窗數值。cwnd初始值為1,每經過一個傳播輪次,cwnd加倍。

擁塞避免: 擁塞避免演算法的思路是讓擁塞視窗cwnd緩慢增大,即每經過一個往返時間RTT就把發送放的cwnd加1.
快重傳與快恢復:
在 TCP/IP 中,快速重傳和恢復(fast retransmit and recovery,FRR)是一種擁塞控制演算法,它能快速恢復丟失的數據包。沒有 FRR,如果數據包丟失了,TCP 將會使用定時器來要求傳輸暫停。在暫停的這段時間內,沒有新的或複製的數據包被髮送。有了 FRR,如果接收機接收到一個不按順序的數據段,它會立即給發送機發送一個重覆確認。如果發送機接收到三個重覆確認,它會假定確認件指出的數據段丟失了,並立即重傳這些丟失的數據段。有了 FRR,就不會因為重傳時要求的暫停被耽誤。  當有單獨的數據包丟失時,快速重傳和恢復(FRR)能最有效地工作。當有多個數據信息包在某一段很短的時間內丟失時,它則不能很有效地工作。

13、在瀏覽器中輸入url地址後顯示主頁的過程

一次完整的http請求過程,總體來說分為以下幾個過程:
1.DNS功能變數名稱解析
2.建立TCP連接
3.發送HTTP請求
4.伺服器處理請求
5.返回HTTP報文
6.關閉TCP連接
7.瀏覽器解析HTML
8.瀏覽器佈局渲

14、常見的Http狀態碼

http狀態返回代碼:1xx(臨時響應)、2xx (成功)、3xx (重定向)、4xx(請求錯誤)、5xx(伺服器錯誤)

2XX 成功

200 OK,表示從客戶端發來的請求在伺服器端被正確處理
201 Created 請求已經被實現,而且有一個新的資源已經依據請求的需要而建立
202 Accepted 請求已接受,但是還沒執行,不保證完成請求
204 No content,表示請求成功,但響應報文不含實體的主體部分
206 Partial Content,進行範圍請求

3XX 重定向

301 moved permanently,永久性重定向,表示資源已被分配了新的 URL
302 found,臨時性重定向,表示資源臨時被分配了新的 URL
303 see other,表示資源存在著另一個 URL,應使用 GET 方法丁香獲取資源
304 not modified,表示伺服器允許訪問資源,但因發生請求未滿足條件的情況
307 temporary redirect,臨時重定向,和302含義相同

4XX 客戶端錯誤

400 bad request,請求報文存在語法錯誤
401 unauthorized,表示發送的請求需要有通過 HTTP 認證的認證信息
403 forbidden,表示對請求資源的訪問被伺服器拒絕
404 not found,表示在伺服器上沒有找到請求的資源
408 Request timeout, 客戶端請求超時
409 Confict, 請求的資源可能引起衝突

5XX 伺服器錯誤

500 internal sever error,表示伺服器端在執行請求時發生了錯誤
501 Not Implemented 請求超出伺服器能力範圍,例如伺服器不支持當前請求所需要的某個功能,或者請求是伺服器不支持的某個方法
503 service unavailable,表明伺服器暫時處於超負載或正在停機維護,無法處理請求
505 http version not supported 伺服器不支持,或者拒絕支持在請求中使用的 HTTP 版本

15、HTTP有哪些方法?

HTTP1.0定義了三種請求方法: GET, POST 和 HEAD方法
HTTP1.1新增了五種請求方法:OPTIONS, PUT, DELETE, TRACE 和 CONNECT

GET: 通常用於請求伺服器發送某些資源
HEAD: 請求資源的頭部信息, 並且這些頭部與 HTTP GET 方法請求時返回的一致. 該請求方法的一個使用場景是在下載一個大文件前先獲取其大小再決定是否要下載, 以此可以節約帶寬資源
OPTIONS: 用於獲取目的資源所支持的通信選項
POST: 發送數據給伺服器
PUT: 用於新增資源或者使用請求中的有效負載替換目標資源的表現形式
DELETE: 用於刪除指定的資源
PATCH: 用於對資源進行部分修改
CONNECT: HTTP/1.1協議中預留給能夠將連接改為管道方式的代理伺服器
TRACE: 回顯伺服器收到的請求,主要用於測試或診斷

16、HTTP長連接、短連接

在HTTP/1.0中預設使用短連接。也就是說,客戶端和伺服器每進行一次HTTP操作,就建立一次連接,任務結束就中斷連接。當客戶端瀏覽器訪問的某個HTML或其他類型的Web頁中包含有其他的Web資源(如JavaScript文件、圖像文件、CSS文件等),每遇到這樣一個Web資源,瀏覽器就會重新建立一個HTTP會話。

而從HTTP/1.1起,預設使用長連接,用以保持連接特性。使用長連接的HTTP協議,會在響應頭加入這行代碼:
Connection:keep-alive
在使用長連接的情況下,當一個網頁打開完成後,客戶端和伺服器之間用於傳輸HTTP數據的TCP連接不會關閉,客戶端再次訪問這個伺服器時,會繼續使用這一條已經建立的連接。Keep-Alive不會永久保持連接,它有一個保持時間,可以在不同的伺服器軟體(如Apache)中設定這個時間。實現長連接需要客戶端和服務端都支持長連接。
HTTP協議的長連接和短連接,實質上是TCP協議的長連接和短連接。

17、HTTPS是如何保證安全的?

HTTP協議是一個應用層協議,通常運行在TCP協議之上。它是一個明文協議,客戶端發起請求,服務端給出響應的響應。
由於網路並不是可信任的,HTTP協議的明文特性會存在以下風險:

  • 通信數據有被竊聽和被篡改的風險
  • 目標網站有被冒充的風險

HTTPS其實就是secure http的意思,也就是HTTP的安全升級版。HTTP是應用層協議,位於HTTP協議之下是傳輸協議TCP。TCP負責傳輸,HTTP則定義了數據如何進行包裝。
HTTPS相對於HTTP有哪些不同呢?其實就是在HTTP跟TCP中間加多了一層加密層TLS/SSL。

HTTPS使用非對稱加密,加密數據用的密鑰(公鑰),跟解密數據用的密鑰(私鑰)是不一樣的。

18、HTTPS的中間人攻擊是什麼?

HTTPS從協議上解決了HTTP時代的中間人攻擊問題,但是HTTPS在用戶主動信任了偽造證書的時候也會發生中間人攻擊(比如早期的12306需要手動信任證書),HTTPS中間人攻擊流程如下:

客戶端用HTTPS連接伺服器的443埠
伺服器下發自己的數字證書給客戶端
黑客劫持了伺服器的真實證書,並偽造了一個假的證書給瀏覽器
瀏覽器可以發現得到的網站證書是假的,但是瀏覽器選擇信任
瀏覽器生成隨機對稱密鑰A,用偽造的證書中的公鑰加密發往伺服器
黑客同樣可以劫持這個請求,得到瀏覽器的對稱密鑰A,從而能夠竊聽或者篡改通信數據
黑客利用伺服器的真實公鑰將客戶端的對稱密鑰A加密發往伺服器
伺服器利用私鑰解密這個對稱密鑰A之後與黑客通信
黑客利用對稱密鑰A解密伺服器的數據,篡改之後利用對稱密鑰A加密發給客戶端
客戶端收到的數據已經是不安全的了

以上就是HTTPS中間人攻擊的原理,這也就是HTTPS抓包為什麼要信任證書的原因。

19、如何理解HTTP協議是無狀態的?

http協議時無狀態的,指的是協議對事物沒有記憶能力,伺服器不知道客戶端是什麼狀態,http是同一個無狀態面向連接的協議。

20、ping命令基於哪一層協議的原理是什麼?

ping命令基於網路層的命令,是基於ICMP協議工作的。


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 1 f=open("yesterday","r",encoding="utf-8") #文件句柄 2 data=f.read() 3 data2=f.read() 4 print (data) 5 print (" data2 ") 6 #讀文件時指針會在文件內移動,讀一次後,指針將所有的文本讀完後 ...
  • 二叉堆(也可作為簡單的優先隊列)的建立、增、刪、自調整。 main.cpp: #include <iostream> #include "BinaryHeap.h" using namespace std; int main() { BinaryHeap<int> bh(BinaryHeap<int ...
  • 原理 項目的資料庫字典表是一個很重要的文檔。通過此文檔可以清晰的瞭解數據表結構及開發者的設計意圖。 通常為了方便我都是直接在資料庫中建表,然後通過工具導出數據字典。 在Mysql資料庫中有一個information_schema庫,它提供了訪問資料庫元數據的方式。 什麼是元數據呢?就是關於數據的數據 ...
  • Redis詳解(八)——企業級解決方案 緩存預熱 緩存預熱就是系統上線後,提前將相關的緩存數據直接載入到緩存系統。避免在用戶請求的時候,先查詢資料庫,然後再將數據緩存的問題!用戶直接查詢事先被預熱的緩存數據! 緩存預熱解決方案: 緩存雪崩 緩存雪崩就是在一個較短的時間內,緩存中較多的key集中過期 ...
  • python和其他語言一樣,也有大量的第三方庫 在安裝python時預設都會安裝pip,安裝了pip後 在cmd.exe下可以運行pip 安裝庫 pip install 庫的名字 換源 因為PyPi地址在國外,國內訪問速度慢有些地方甚至訪問不了,把鏡像源換為國內地址速度簡直飛起 國內一些常用的軟體源 ...
  • Standard Template Library(STL)主要由兩種組件構成1:一是容器(container),包括vector、list、set、map等;另一種組件是用以操作這些容器的所謂泛型演算法(generic algorithm),包括find()、sort()、replace()、mer... ...
  • Redis詳解(七)——集群 ​Redis3.0版本之前,可以通過Redis Sentinel(哨兵)來實現高可用 ( HA ),從3.0版本之後,官方推出了Redis Cluster,它的主要用途是實現數據分片(Data Sharding),不過同樣可以實現HA,是官方當前推薦的方案。 在Redi ...
  • 可以說string和vector是C++標準庫中最重要的兩種類型,string支持可變長字元串,而vector表示可變長的集合。 string 頭文件:<string> 定義在命名空間 std 中,using std::string; string s1; // 預設初始化,s1是一個空串 stri ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發(一):使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說,近來想嘗試開發一款安卓APP,考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP,畢竟是使用Visual Studio開發工具,使用起來也比較的順手,結合微軟官方的教程進行了安卓 ...
  • 前言 QuestPDF 是一個開源 .NET 庫,用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫,它徹底改變了我們生成 PDF 文檔的方 ...
  • 項目地址 項目後端地址: https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址: ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址: http://tree ...
  • 話不多說,直接開乾 一.下載 1.官方鏈接下載: https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe,運行開始下載SQL server; 二. ...
  • 前言 隨著物聯網(IoT)技術的迅猛發展,MQTT(消息隊列遙測傳輸)協議憑藉其輕量級和高效性,已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫,為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog支持多種接收器用於日誌存儲,增強器用於添加屬性,LogContext管理動態屬性,支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項,適用於不同需求。 ...
  • 目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據,爬取信息時需要模擬瀏覽器行為,否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下: 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • 1.前言 什麼是熱更新 游戲或者軟體更新時,無需重新下載客戶端進行安裝,而是在應用程式啟動的情況下,在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR,Xlua,ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles,Addressable, ...
  • 本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺,其實像阿裡雲,騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後,它會送 ...
  • 通過以下方式可以高效,並保證數據同步的可靠性 1.API設計 使用RESTful設計,確保API端點明確,並使用適當的HTTP方法(如POST用於創建,PUT用於更新)。 設計清晰的請求和響應模型,以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證,確保接收到的數據符合預期格 ...