【軟考中級網絡工程師】知識點之 UDP 協議:網絡通信中的高效輕騎兵

目錄

  • 一、UDP 協議簡介
  • 二、UDP 協議特點
    • 2.1 無連接性
    • 2.2 不可靠性
    • 2.3 面向數據報
    • 2.4 低開銷
    • 2.5 廣播支持
  • 三、UDP 協議工作原理
    • 3.1 UDP 報文格式
    • 3.2 UDP 數據傳輸過程
  • 四、UDP 協議應用場景
    • 4.1 實時音視頻傳輸
    • 4.2 在線游戲
    • 4.3 DNS 查詢
    • 4.4 其他應用場景
  • 五、UDP 與 TCP 對比
    • 5.1 可靠性對比
    • 5.2 性能對比
    • 5.3 適用場景對比
  • 六、UDP 協議使用注意事項
    • 6.1 數據長度限制
    • 6.2 校驗和的作用與局限性
  • 七、總結


一、UDP 協議簡介

在計算機網絡的龐大體系中,UDP 協議(User Datagram Protocol,用戶數據報協議)占據著傳輸層的重要位置,與 TCP 協議一同為應用層提供數據傳輸服務。它就像是一位 “快遞員”,以獨特的方式在網絡中傳遞數據。與 TCP 這位嚴謹、可靠的 “快遞員” 不同,UDP 更像是一位追求效率的 “急行者” 。

UDP 是一種無連接的傳輸層協議,這意味著它在發送數據時不需要像 TCP 那樣,先與接收方建立一個可靠的連接。就好比寄快遞時,不需要提前打電話確認收件人是否在家,直接把包裹投遞出去。這種特性使得 UDP 的傳輸過程更加簡單和快速,減少了建立連接的時間開銷,特別適合那些對實時性要求較高,能夠容忍少量數據丟失的應用場景。

UDP 在網絡通信中承擔著重要的職責。它為應用程序提供了一種直接、高效的數據傳輸方式,允許應用程序將數據封裝成 UDP 數據報,然后通過網絡發送給目標主機。在這個過程中,UDP 數據報就像是一個個獨立的 “包裹”,每個 “包裹” 都包含了源端口、目的端口、長度和校驗和等關鍵信息,這些信息就像是包裹上的收件人地址、寄件人地址、重量和快遞單號,幫助數據準確地在網絡中傳輸和交付。

二、UDP 協議特點

UDP 協議之所以能夠在網絡傳輸中占據重要地位,得益于其獨特的特點。這些特點使它在不同的應用場景中發揮著關鍵作用,下面我們就來詳細剖析 UDP 協議的特點。

2.1 無連接性

UDP 協議無需像 TCP 協議那樣,在發送數據之前與接收方進行復雜的三次握手來建立連接,也不需要在數據傳輸結束后進行四次揮手來關閉連接。在 UDP 通信中,發送方就像一位心急的快遞員,不提前確認收件人是否在家,直接將數據報這個 “包裹” 扔出去,接收方也隨時準備接收這些 “包裹” 。UDP 的無連接性與 TCP 的連接性對比如下:
在這里插入圖片描述

這種無連接的特性極大地減少了通信延遲,提高了傳輸效率,特別適合那些對實時性要求極高,數據傳輸量相對較小且對可靠性要求相對較低的應用場景,如實時監控系統中的視頻流傳輸,監控攝像頭需要快速將視頻數據發送出去,即使偶爾丟失一些數據幀,也不會對整體的監控效果產生太大影響。

2.2 不可靠性

UDP 協議不保證數據報的可靠傳輸,這是它與 TCP 協議的一個重要區別。在 UDP 傳輸過程中,可能會出現丟包、重復或亂序等情況 。例如,當網絡擁塞時,數據報可能會被丟棄;由于不同數據報在網絡中傳輸的路徑不同,到達接收方的順序可能與發送方發送的順序不一致 。從發送方的角度來看,它發送數據報后,不會等待接收方的確認,也不會進行重傳操作。就好像發短信,發送出去后,我們并不知道對方是否收到,也不會自動重發。這意味著使用 UDP 協議的應用程序需要自行處理這些可能出現的問題,比如在實時語音通話中,少量語音數據的丟失可以通過語音的連貫性和上下文來彌補,不會嚴重影響通話質量。

2.3 面向數據報

UDP 協議以數據報為單位傳輸數據,每個數據報都是獨立的,包含了完整的源端口、目的端口、數據長度和校驗和等信息。發送方可以將多個數據報連續發送,這些數據報在網絡中獨立傳輸,互不干擾。就好比把多個包裹分別扔出去,每個包裹都有自己的路線,可能會先到、后到或丟失,但它們之間沒有關系。接收方在接收到數據報后,根據數據報中的目的端口信息,將數據交付給相應的應用程序 。UDP 不會對數據進行拆分或合并,這與 TCP 將數據看成一連串無結構的字節流的傳輸方式不同。例如,在 DNS 查詢中,每次查詢請求和響應都是以獨立的數據報形式進行傳輸的。

2.4 低開銷

UDP 的頭部結構非常簡單,只有 8 個字節,相比 TCP 協議 20 - 60 字節的頭部,開銷明顯更小。這 8 個字節主要包含源端口、目的端口、長度和校驗和四個字段。源端口和目的端口用于標識發送方和接收方的應用程序,長度字段表示整個 UDP 數據報(包括頭部和數據部分)的總長度,校驗和用于檢測數據報在傳輸過程中是否發生錯誤 。UDP 沒有復雜的連接建立和關閉過程,也沒有流量控制和擁塞控制機制。這些特性使得 UDP 在傳輸數據時,能夠以更快的速度進行,減少了數據傳輸的延遲,特別適合那些對傳輸速度要求較高,能夠容忍一定數據丟失的應用,如在線游戲中的實時數據傳輸,玩家的操作指令需要快速發送到服務器,UDP 的低開銷特性可以滿足這一需求。以下展示 UDP 和 TCP 頭部大小對比:
在這里插入圖片描述

2.5 廣播支持

UDP 協議支持廣播和多播通信方式,這使得它在一些特定的應用場景中具有獨特的優勢。廣播是指發送方將數據發送給網絡中的所有設備,多播則是指發送方將數據發送給一組特定的設備 。在一個局域網中,進行網絡設備的發現和配置時,可以使用 UDP 廣播,一臺設備發送廣播消息,局域網內的其他設備都能接收到。在視頻會議中,主持人可以通過 UDP 多播將視頻和音頻數據發送給所有參會人員,實現高效的數據傳輸 。通過 UDP 的廣播和多播功能,可以減少網絡帶寬的占用,提高數據傳輸的效率,特別適合那些需要一對多或多對多通信的場景。

三、UDP 協議工作原理

3.1 UDP 報文格式

UDP 報文由首部和數據兩部分組成,首部長度固定為 8 字節,由四個字段組成,每個字段都是 16 位(2 字節)。繪制 UDP 報文頭類圖如下:
在這里插入圖片描述

下面詳細解釋各個字段的含義和作用:

  • 源端口號(Source Port):16 位字段,標識發送數據報的應用程序所在的端口。它的取值范圍是 0 到 65535 。通常情況下,源端口號由操作系統分配,用于標識發送數據報的應用程序。當接收方需要回復發送方時,就可以根據這個源端口號將響應數據發送回正確的應用程序。例如,在 DNS 查詢中,客戶端隨機選擇一個源端口號(如 53000)發送查詢請求,DNS 服務器在回復時,會將響應數據發送到這個源端口號 。
  • 目的端口號(Destination Port):同樣是 16 位字段,標識接收數據報的應用程序所在的端口,取值范圍也是 0 到 65535 。目的端口號用于確定數據報應該交給哪個應用程序處理。當 UDP 數據報到達目標主機后,操作系統會根據這個目的端口號,將數據報交付給對應的應用程序。比如,DNS 服務器的默認目的端口號是 53,當 DNS 查詢請求到達服務器時,操作系統會根據目的端口號 53,將請求數據交給 DNS 服務程序進行處理 。
  • 長度(Length):16 位字段,表示整個 UDP 數據報的長度,包括 UDP 頭部和數據部分 。最小值是 8,因為 UDP 頭部的長度固定為 8 字節。如果數據部分的長度為 0,那么整個 UDP 報文的長度就是 8 字節。假設一個 UDP 數據報,頭部為 8 字節,數據部分為 50 字節,那么長度字段的值就是 58(8 + 50) 。這個字段可以幫助接收方確定 UDP 數據報的邊界,正確地解析出數據部分。
  • 校驗和(Checksum):16 位字段,用于驗證 UDP 報文在傳輸過程中是否發生了錯誤 。它通過 UDP 頭部、數據部分以及偽首部進行計算。偽首部包括源 IP 地址、目的 IP 地址、協議號(17 表示 UDP)和 UDP 報文長度。發送方在計算校驗和時,會將這些信息一起參與計算,得到一個 16 位的校驗和值,填充到校驗和字段中 。接收方收到數據報后,會按照同樣的方法重新計算校驗和,并與接收到的校驗和字段進行比較。如果兩者相等,說明數據報在傳輸過程中沒有發生錯誤;如果不相等,說明數據報可能已經損壞,接收方通常會丟棄該數據報。

3.2 UDP 數據傳輸過程

UDP 數據從發送端到接收端的傳輸流程相對簡單,下面繪制序列圖來展示這個過程:
在這里插入圖片描述

具體步驟如下:

  1. 發送端應用程序生成 UDP 數據報:發送端應用程序將要發送的數據交給 UDP 層,UDP 層創建一個 UDP 數據報,填充源端口號、目的端口號、長度和校驗和等首部字段,并將應用程序的數據封裝在數據部分 。
  2. UDP 層將數據報交給 IP 層:UDP 層完成數據報的封裝后,將其交給 IP 層進行進一步處理 。
  3. IP 層封裝并發送數據報:IP 層接收 UDP 數據報后,為其添加 IP 首部,包括源 IP 地址、目的 IP 地址等信息,然后通過網絡將封裝好的 IP 數據報發送出去 。在這個過程中,數據報可能會經過多個路由器的轉發,最終到達目標主機。
  4. 接收端 IP 層接收并處理數據報:目標主機的 IP 層接收到數據報后,檢查 IP 首部的目的 IP 地址是否為本機地址 。如果是,去除 IP 首部,將 UDP 數據報交給 UDP 層;如果不是,根據路由表進行轉發。
  5. 接收端 UDP 層處理數據報:UDP 層接收到 UDP 數據報后,首先檢查校驗和字段,驗證數據報在傳輸過程中是否發生錯誤 。如果校驗和正確,根據目的端口號,將數據報交付給對應的接收端應用程序;如果校驗和錯誤,通常會丟棄該數據報。
  6. 接收端應用程序接收數據:接收端應用程序從 UDP 層獲取到數據,進行后續的處理。

四、UDP 協議應用場景

UDP 協議憑借其獨特的特性,在眾多領域得到了廣泛的應用。它就像一把萬能鑰匙,雖然不是適用于所有的鎖,但在某些特定的 “鎖” 面前,卻能發揮出無與倫比的作用。以下是 UDP 協議常見的一些應用場景:

4.1 實時音視頻傳輸

在視頻會議、直播等實時音視頻傳輸場景中,UDP 協議是當之無愧的首選 。以視頻會議為例,參會者們需要實時地看到和聽到對方的音視頻內容,這就對數據傳輸的實時性提出了極高的要求。UDP 協議的無連接性和低延遲特性,使得它能夠快速地將音視頻數據發送出去,減少了因建立連接而帶來的時間消耗 。即使在網絡狀況不佳的情況下,偶爾丟失一些數據幀,對于人的視覺和聽覺來說,也不會造成太大的影響,因為人眼和人耳具有一定的容錯能力,能夠根據前后的內容進行一定程度的腦補和填補 。例如,在一些在線教育平臺的直播課程中,使用 UDP 協議進行視頻流傳輸,能夠讓學生們實時地觀看到老師的授課畫面和聽到講解聲音,即使出現短暫的卡頓或少量數據丟失,也不會影響整體的學習體驗。在視頻會議場景下,繪制 UDP 和 TCP 傳輸音視頻數據的對比序列圖如下:
在這里插入圖片描述

4.2 在線游戲

在在線游戲領域,UDP 協議同樣發揮著關鍵作用 。對于玩家來說,游戲的流暢性和實時性至關重要。在一場激烈的多人在線射擊游戲中,玩家的每一次移動、射擊、跳躍等操作,都需要及時地傳輸到服務器,并同步給其他玩家。UDP 協議的低延遲和快速傳輸特性,能夠滿足游戲對實時數據傳輸的嚴格要求,確保玩家的操作指令能夠迅速地被服務器接收和處理,減少游戲中的延遲和卡頓現象 。雖然 UDP 協議不保證數據的可靠傳輸,但游戲開發者可以通過在應用層實現一些補償機制,如預測玩家的下一步動作、對重要數據進行多次發送等,來彌補 UDP 協議的不足,保證玩家能夠獲得流暢的游戲體驗 。以《英雄聯盟》這款熱門游戲為例,它使用 UDP 協議進行數據傳輸,玩家在游戲中的各種操作能夠快速地反饋到游戲畫面中,讓玩家沉浸在緊張刺激的游戲對戰中。繪制 UDP 在在線游戲中的數據傳輸流程圖如下:
在這里插入圖片描述

4.3 DNS 查詢

DNS(Domain Name System,域名系統)查詢是 UDP 協議的經典應用場景之一。DNS 的主要功能是將人類可讀的域名(如www.baidu.com)轉換為計算機能夠理解的 IP 地址(如 180.101.49.11) 。在進行 DNS 查詢時,通常只需要發送和接收一小部分數據,對可靠性的要求相對不高,而對查詢的速度卻有較高的要求。UDP 協議的快速傳輸特性和低開銷特性,使得它非常適合用于 DNS 查詢。當我們在瀏覽器中輸入一個網址并按下回車鍵時,計算機首先會向本地 DNS 服務器發送一個 UDP 查詢請求,本地 DNS 服務器接收到請求后,會根據緩存或進一步向其他 DNS 服務器查詢,最終將查詢到的 IP 地址返回給計算機,整個過程通常在極短的時間內完成 。如果使用 TCP 協議進行 DNS 查詢,由于 TCP 協議的連接建立和關閉過程較為復雜,會增加查詢的時間開銷,影響用戶的上網體驗。繪制 DNS 查詢使用 UDP 的交互圖如下:
在這里插入圖片描述

4.4 其他應用場景

除了上述應用場景外,UDP 協議還在許多其他領域有著廣泛的應用 。在 NTP(Network Time Protocol,網絡時間協議)中,UDP 協議用于在網絡設備之間同步時間信息 。NTP 要求低延遲,以確保各個設備的時間能夠準確同步,UDP 協議的低延遲特性正好滿足了這一需求。在物聯網設備通信中,許多物聯網設備資源有限,需要一種簡單、高效的傳輸協議。UDP 協議的無連接性和低開銷特性,使得它非常適合物聯網設備之間的通信,如傳感器將采集到的數據發送給網關,智能家居設備接收控制指令等場景。在一些實時監控系統中,監控攝像頭需要將采集到的視頻數據實時傳輸到監控中心,UDP 協議的快速傳輸和對少量數據丟失的容忍性,能夠保證監控畫面的實時性和連貫性。

五、UDP 與 TCP 對比

在網絡協議的大家庭中,UDP 和 TCP 作為傳輸層的兩大重要協議,各自有著獨特的特點和適用場景。它們就像是兩位性格迥異的快遞員,TCP 是一位嚴謹、負責的快遞員,總是確保包裹準確無誤、按順序地送達;而 UDP 則是一位風風火火的快遞員,追求速度和效率,不太在意包裹是否會丟失或順序是否正確 。下面我們將從可靠性、性能和適用場景三個方面對 UDP 和 TCP 進行詳細的對比。

5.1 可靠性對比

TCP 協議以其卓越的可靠性著稱,它就像一位責任心極強的快遞員,為了確保數據準確無誤地到達目的地,采用了多種機制 。通過序列號,TCP 為每個發送的數據段都分配了一個唯一的編號,接收方可以根據這些編號對數據進行排序,即使數據在傳輸過程中出現亂序,也能被正確地重組 。確認應答機制就像是快遞員每送一個包裹都會等待收件人的確認簽收,只有收到確認信息后,才會繼續發送下一個包裹。如果在規定的時間內沒有收到確認應答,TCP 會啟動超時重傳機制,重新發送未被確認的數據段,以確保數據不會丟失 。TCP 還具備流量控制和擁塞控制機制,能夠根據網絡的狀況動態調整數據的發送速率,避免網絡擁塞和數據丟失 。繪制 TCP 可靠性機制流程圖如下:
在這里插入圖片描述

相比之下,UDP 協議在可靠性方面就顯得有些 “粗心大意” 。它不保證數據報的可靠傳輸,就像快遞員把包裹扔出去后,不管收件人是否收到,也不會去確認 。在 UDP 傳輸過程中,數據報可能會因為網絡擁塞、鏈路故障等原因而丟失,而且 UDP 沒有重傳機制,一旦數據報丟失,應用程序也不會得到通知 。UDP 也不保證數據報的順序,由于不同數據報在網絡中傳輸的路徑不同,到達接收方的順序可能與發送方發送的順序不一致。

5.2 性能對比

在性能方面,UDP 和 TCP 各有千秋。UDP 協議由于其簡單的結構和無連接的特性,就像一位輕裝上陣的短跑運動員,在傳輸數據時具有較低的延遲和較高的傳輸效率 。UDP 不需要進行連接建立和關閉的過程,減少了握手的時間開銷,能夠快速地將數據發送出去 。UDP 的頭部開銷較小,只有 8 個字節,相比 TCP 的 20 - 60 字節,減少了數據傳輸的額外負擔 。在實時性要求較高的場景中,如實時音視頻傳輸、在線游戲等,UDP 的低延遲特性能夠確保數據的快速傳輸,提供流暢的用戶體驗。繪制 UDP 和 TCP 性能對比圖如下:
在這里插入圖片描述

然而,TCP 協議為了保證數據的可靠性,就像一位背負著沉重包裹的長跑運動員,在傳輸過程中引入了較多的開銷,導致其傳輸效率相對較低 。TCP 在發送數據前需要進行三次握手來建立連接,數據傳輸結束后還需要進行四次揮手來關閉連接,這個過程會消耗一定的時間和資源 。在數據傳輸過程中,TCP 需要對每個數據段進行確認應答和重傳,以及進行流量控制和擁塞控制,這些操作都會增加數據傳輸的延遲 。當網絡狀況不佳時,TCP 的重傳機制可能會導致大量的數據重傳,進一步降低傳輸效率。

5.3 適用場景對比

由于 UDP 和 TCP 在可靠性和性能上的差異,它們適用于不同的應用場景 。UDP 適用于那些對實時性要求較高,能夠容忍少量數據丟失的場景 。在實時音視頻傳輸中,如視頻會議、直播等,雖然偶爾丟失一些數據幀不會對人的視覺和聽覺造成太大的影響,但如果出現較大的延遲,就會導致音視頻卡頓,影響用戶體驗,因此 UDP 的低延遲特性非常適合這類場景 。在在線游戲中,玩家的操作指令需要快速地傳輸到服務器,UDP 的快速傳輸能夠滿足游戲對實時性的要求,即使少量指令丟失,也可以通過游戲的補償機制來彌補。

TCP 則適用于對數據可靠性和順序性要求較高的場景 。在文件傳輸中,如下載軟件、上傳文件等,確保文件的完整性和正確性至關重要,任何數據的丟失或錯誤都可能導致文件無法正常使用,因此 TCP 的可靠傳輸機制能夠保證文件完整無誤地傳輸 。在網頁瀏覽中,網頁的內容需要按照正確的順序加載,否則會出現頁面顯示錯誤的情況,TCP 的有序傳輸能夠滿足這一需求。

六、UDP 協議使用注意事項

6.1 數據長度限制

UDP 數據報的最大長度是有限制的,理論上,UDP 數據報的總長度(包括首部和數據部分)最大為 65535 字節,這是因為 UDP 首部中的長度字段是 16 位,其能夠表示的最大值就是 65535 。由于 UDP 首部固定為 8 字節,所以 UDP 數據部分的最大長度為 65527 字節 。在實際應用中,受限于底層網絡的 MTU(最大傳輸單元),UDP 數據報的大小往往會受到更嚴格的限制 。以以太網為例,其 MTU 通常為 1500 字節,刨去 20 字節的 IP 首部和 8 字節的 UDP 首部,UDP 數據部分的最大長度一般為 1472 字節 。當我們需要傳輸超過 MTU 大小的數據時,就需要在應用層手動進行分包處理,將大數據拆分成多個小的數據報進行發送 。在接收端,再根據數據報中的序號等信息進行重組,恢復原始數據 。例如,在使用 UDP 傳輸大文件時,我們可以將文件分割成多個 1472 字節(或更小)的數據塊,為每個數據塊添加序號,然后依次發送這些數據塊 。接收方在接收到數據塊后,根據序號將它們重新組裝成完整的文件。繪制 UDP 分包傳輸大數據的流程圖如下:
在這里插入圖片描述

6.2 校驗和的作用與局限性

UDP 協議中的校驗和字段用于檢測數據在傳輸過程中是否發生錯誤,它通過對 UDP 首部、數據部分以及偽首部進行計算得到 。偽首部包含源 IP 地址、目的 IP 地址、協議號(17 表示 UDP)和 UDP 報文長度等信息 。發送方在計算校驗和時,將這些信息與 UDP 數據報一起參與計算,得到一個 16 位的校驗和值,填充到校驗和字段中 。接收方收到數據報后,按照同樣的方法重新計算校驗和,并與接收到的校驗和字段進行比較 。如果兩者相等,說明數據報在傳輸過程中沒有發生錯誤;如果不相等,說明數據報可能已經損壞,接收方通常會丟棄該數據報。繪制 UDP 校驗和計算與驗證流程圖如下:
在這里插入圖片描述

然而,UDP 校驗和也存在一定的局限性。它只能檢測出數據在傳輸過程中是否發生了錯誤,但無法糾正錯誤。一旦校驗和驗證失敗,接收方只能丟棄數據報,而無法對錯誤的數據進行修復。UDP 校驗和并不能檢測出所有的錯誤 。由于校驗和是通過對數據進行特定算法計算得到的,存在一定的誤判概率,即數據可能發生了錯誤,但校驗和卻顯示正確 。在實際應用中,對于可靠性要求較高的數據傳輸,僅僅依靠 UDP 校驗和是不夠的,還需要在應用層采取其他的錯誤檢測和糾正措施,如 CRC(循環冗余校驗)等更強大的校驗算法,或者引入重傳機制來確保數據的準確傳輸。

七、總結

UDP 協議作為傳輸層的重要協議之一,以其獨特的無連接性、不可靠性、面向數據報、低開銷和廣播支持等特點,在網絡通信中占據著不可或缺的地位。它的工作原理簡單直接,通過簡潔的報文格式和高效的數據傳輸過程,為各種應用場景提供了快速的數據傳輸服務。

在實時音視頻傳輸、在線游戲、DNS 查詢等對實時性要求極高的場景中,UDP 協議憑借其低延遲和快速傳輸的特性,成為了首選的傳輸協議 。在這些場景中,UDP 協議就像是一位風馳電掣的快遞員,雖然偶爾會出現包裹丟失的情況,但能夠確保大部分包裹快速送達,滿足了應用對數據傳輸速度的嚴格要求。

與 TCP 協議相比,UDP 協議在可靠性和性能方面展現出了截然不同的特點。TCP 協議如同一位嚴謹細致的管家,通過各種復雜的機制確保數據的可靠傳輸和順序性;而 UDP 協議則像是一位追求速度的冒險者,更注重數據傳輸的效率和實時性。在實際應用中,我們需要根據具體的需求和場景,合理地選擇使用 UDP 協議或 TCP 協議,以實現最佳的網絡通信效果。

在使用 UDP 協議時,我們也需要注意數據長度限制和校驗和的作用與局限性等問題。了解這些注意事項,能夠幫助我們更好地發揮 UDP 協議的優勢,避免潛在的問題。

UDP 協議以其獨特的魅力,在網絡通信的舞臺上扮演著重要的角色。隨著網絡技術的不斷發展,UDP 協議也將在更多的領域中得到應用和創新,為我們的網絡生活帶來更多的便利和驚喜。

本文來自互聯網用戶投稿,該文觀點僅代表作者本人,不代表本站立場。本站僅提供信息存儲空間服務,不擁有所有權,不承擔相關法律責任。
如若轉載,請注明出處:http://www.pswp.cn/diannao/95317.shtml
繁體地址,請注明出處:http://hk.pswp.cn/diannao/95317.shtml
英文地址,請注明出處:http://en.pswp.cn/diannao/95317.shtml

如若內容造成侵權/違法違規/事實不符,請聯系多彩編程網進行投訴反饋email:809451989@qq.com,一經查實,立即刪除!

相關文章

【Node.js從 0 到 1:入門實戰與項目驅動】2.1 安裝 Node.js 與 npm(Windows/macOS/Linux 系統的安裝步驟)

文章目錄 第 2 章:環境搭建 —— 準備你的開發工具 2.1 安裝 Node.js 與 npm(Windows/macOS/Linux 系統的安裝步驟) 一、通用安裝前檢查 二、Windows 系統安裝步驟 方法 1:通過官方安裝包(推薦) 方法 2:通過 nvm-windows 管理多版本(進階) 三、macOS 系統安裝步驟 方法…

C語言相關簡單數據結構:數據結構概念

目錄 1.需要的儲備知識 2.數據結構相關概念 2.1 什么是數據結構 什么是數據? 什么是結構? 概念: 總結: 2.2 為什么需要數據結構? 結論: C語?語法基礎到數據結構與算法,前?已經掌握并…

Docker 詳細介紹及使用方法

Docker 詳細介紹及使用方法 一、Docker 是什么? Docker 是一種開源的應用容器引擎,基于 Go 語言開發并遵從 Apache 2.0 協議開源。它允許開發者將應用程序及其依賴打包到一個輕量級、可移植的容器中,然后發布到任何流行的 Linux 機器上。Dock…

PHP request文件封裝

1.繼承FormRequest 其中id是路由傳參 name是對象中必填校驗<?phpnamespace App\Http\Requests\Admin\User;use Illuminate\Foundation\Http\FormRequest; use Illuminate\Validation\Rule;class user_info_uptRequest extends FormRequest {public function authorize():…

基于跨平臺的svg組件編寫一個svg編輯器

duxapp 提供了一套跨平臺的 SVG 編輯器組件&#xff0c;支持在多種環境中創建和編輯 SVG 圖形。該編輯器包含以下核心功能&#xff1a; 插入圖片繪制自由路徑添加文本創建基本形狀&#xff08;矩形、圓形、線條等&#xff09;對元素進行移動、縮放和旋轉操作 快速開始 import…

react+echarts實現圖表展示的兩種方法

前言&#xff1a;reactecharts實現圖表展示。1、直接用echarts的插件來實現1&#xff09;安裝npm install echarts2&#xff09;使用1、useEffect是react中集合onload/watch監聽等方法與一體的hook函數&#xff0c;他的第二個參數是空數組&#xff0c;則等同于onload&#xff0…

Apache 服務器基礎配置與虛擬主機部署

Apache 服務器基礎配置與虛擬主機部署 Apache 的核心定位與作用&#xff1a; Apache 的核心功能是處理 HTTP 請求并提供 Web 資源&#xff0c;是客戶端&#xff08;如瀏覽器&#xff09;與 Web 服務器之間的 “中間人”&#xff1a; 接收客戶端通過 HTTP/HTTPS 協議發送的請求…

線性代數 · 矩陣 | 最小多項式

注&#xff1a;本文為 “矩陣 | 最小多項式” 相關合輯。 略作重排&#xff0c;如有內容異常&#xff0c;請看原文。 最小多項式 橘子蜂蜜 于 2019-05-22 22:48:25 發布 根據哈密頓 - 凱萊&#xff08;Hamilton - Cayley&#xff09;定理&#xff0c;任給數域 PPP 上的一個 …

docter的使用、vscode(cursor)和docker的連接,詳細分析說明

目錄 一、基本命令 二、用案例來學習使用方法 &#x1f680; Pull Python 3.11 鏡像并創建命名容器 &#x1f4cb; 其他有用命令 在容器中安裝依賴 三、直接在鏡像中安裝依賴&#xff08;創建自己定制的鏡像&#xff09; 四、在 cursor 中選用容器作為編譯器 五、對于整…

如何使用AI大語言模型解決生活中的實際小事情?

我們總以為AI是遙不可及的未來科技&#xff0c;卻忽視了它早已成為生活中最實用的“隱形助手”。在信息爆炸的今天&#xff0c;我們每天被無數生活瑣事包圍&#xff1a;一封專業郵件反復修改措辭、孩子突如其來的數學難題、冰箱里僅剩的食材如何搭配、旅行行程的繁瑣規劃……這…

關于微信小程序的筆記

1.需要獲取demo素材圖片方法&#xff08;2,3&#xff09;2.使用逆向工具進行解包沒有安裝node的需要安裝一下安裝npm i -g wedecode0.8.0-beta.3獲取小程序文件存放路徑/Users/lin/Library/Containers/com.tencent.xinWeChat/Data/.wxapplet/packages/wx060ecb4f74eac0da根據具…

課堂筆記:吳恩達的AI課(AI FOR EVERYONE)-W2 AI項目工作流程

課堂筆記&#xff1a;吳恩達的AI課&#xff08;AI FOR EVERYONE&#xff09;-W2 AI項目工作流程 一、如何開始一個AI項目&#xff1f; 1、建設項目工作流程 2、選擇合適的AI項目 3、為這個項目收集數據和組織團隊二、AI項目的工作流程 &#xff08;1&#xff09;機器學習項目的…

逐際動力開源運控 tron1-rl-isaacgym 解讀與改進

文章目錄概覽基礎框架解讀線速度估計觀測結構仿真實驗點足式步態設計步態相位與接觸狀態建模步態接觸獎勵動作延遲我的改進Point-goal Locomotion觀測修改獎勵修改預訓練地形編碼器Sliced Wasserstein AutoEncoder模型訓練與結果參考材料概覽 這篇博客記錄了我參加逐際動力創學…

人工智能-python-機器學習-線性回歸與梯度下降:理論與實踐

文章目錄線性回歸與梯度下降&#xff1a;理論與實踐1. 引言2. 回歸分析2.1 什么是回歸&#xff1f;2.2 線性回歸2.3 損失函數2.4 多參數回歸3. 參數求解&#xff1a;最小二乘法3.1 最小二乘法 MSE3.2 最小二乘法的優缺點優點&#xff1a;缺點&#xff1a;4. 梯度下降4.1 梯度下…

前端,elment-plus組件:表格,分頁,對話框,表單

Element Plus 核心特性組件體系&#xff1a;表單、表格、彈窗、導航等高頻組件設計理念主題定制&#xff1a;Sass 變量覆蓋與暗黑模式無縫切換國際化支持&#xff1a;多語言動態切換的實現機制TypeScript 支持&#xff1a;完整的類型定義與開發友好性快速上手指南安裝與基礎配置…

【LeetCode】6. Z 字形變換

文章目錄6. Z 字形變換題目描述示例 1&#xff1a;示例 2&#xff1a;示例 3&#xff1a;提示&#xff1a;解題思路算法分析問題本質分析Z字形排列過程詳解Z字形排列可視化方向控制策略數學規律法詳解各種解法對比算法流程圖邊界情況處理時間復雜度分析空間復雜度分析關鍵優化點…

spring文件下載的方式

spring文件下載的方式方式一:通過ResponseEntity<Resource> 方式來下載方式二:通過ResponseEntity<StreamingResponseBody> 方式來下載方式三:通過Servlet原生下載方式四:通過ResponseEntity<byte[]> 方式來下載四種下載方式的對比1、核心特性對比2、典型場景…

寫一個redis客戶端軟件,參考 Another Redis Desktop Manager 的設計風格。

一個基于 Electron 開發的現代化 Redis 桌面客戶端&#xff0c;參考 Another Redis Desktop Manager 的設計風格。 github倉庫地址 https://github.com/henkuoai/redis-man-pc

Web3: DeFi借貸的安全基石, 了解喂價與清算機制的原理與重要性

今天我們要聊一個DeFi世界里至關重要&#xff0c;但又時常被誤解的話題&#xff1a;為什么DeFi協議需要定期更新喂價和執行清算&#xff1f; 如果大家參與過DeFi借貸&#xff0c;大家可能看到過“清算”這個詞&#xff0c;甚至會有點談虎色變。但實際上&#xff0c;清算和為其提…

「iOS」————響應者鏈與事件傳遞鏈

iOS學習響應者鏈和事件傳遞鏈傳遞鏈&#xff1a;hitTest:withEvent**pointInside:withEvent**響應鏈第一響應者和最佳響應者觸摸事件&#xff08;UITouch&#xff09;UIGestureRecognizer&#xff08;手勢識別器&#xff09;響應者鏈和事件傳遞鏈 iOS事件的主要由&#xff1a;…