博客

  • 網路工程師必備:如何排查網路故障?

     晚云浅 晴间多云

    網路故障排查是網路工程師的核心技能。

    透過端對端測試確認故障範圍,使用ping、traceroute、nslookup等基本指令檢查連結性和解析;檢查交換器、路由器和伺服器狀態;利用Wireshark等網路分析工具和Nagios、Zabbix等監控工具深入分析。

    網路故障可能由多種原因引起,如硬體故障、配置錯誤、網路擁塞等。故障會導致網路效能下降、服務中斷,影響使用者體驗和業務運作。
    一、故障排查步驟

    1. 確認故障範圍(端對端測試)端對端測試:從用戶終端到伺服器進行測試,確認故障發生的具體位置。分段排查:將網路分段,逐步縮小故障範圍。

    2. 使用基本指令ping: 測試網路連通性,檢查目標設備是否可達。

    例如:ping 192.168.1.1traceroute: 追蹤封包從來源到目標的路徑,顯示每個跳點的延遲。

    例如:traceroute 192.168.1.1nslookup: 查詢DNS記錄,檢查網域解析是否正常。

    例如:nslookup example.com3. 檢查設備狀態交換器:檢查交換器的介面狀態、錯誤計數、VLAN配置等。

    指令:show interfaces、show vlan路由器:檢查路由表、介面狀態、路由協定配置等。

    指令:show ip route、show interfaces伺服器:檢查伺服器的網路設定、服務狀態、日誌檔案等。指令:ifconfig、netstat、systemctl status <service>

    二、故障排查工具

    1. 網路分析工具(如Wireshark)Wireshark:擷取和分析網路封包,幫助診斷網路問題。

    例如:捕獲HTTP流量,分析請求和回應。

    2. 監控工具(如Nagios、Zabbix)Nagios:即時監控網路設備和服務狀態,提供警報和通知。 Zabbix:收集和分析網路效能數據,產生圖表和報告。

    三、實際案例:排查網路延遲問題場景:使用者報告造訪公司內部網站時出現延遲。

    步驟:

    1. 確認故障範圍:使用ping和traceroute指令,確認延遲發生在哪個網路段。

    2. 檢查設備狀態:登入交換器和路由器,檢查介面狀態和錯誤計數。檢查伺服器的網路配置和負載情況。

    3. 使用網路分析工具:使用Wireshark擷取網路流量,分析延遲原因(如網路擁塞、丟包等)。

    4. 最佳化網路配置:調整路由器和交換器的QoS配置,優先處理關鍵業務流量。優化伺服器資源,提高回應速度。

    5. 驗證修復效果:再次使用ping和traceroute指令,確認延遲問題已解決。透過系統的排查流程,提高故障處理效率網路故障排查需要係統化的方法與工具支援。透過確認故障範圍、使用基本指令、檢查設備狀態和利用網路分析工具,可以快速定位和解決網路問題,提高故障處理效率,確保網路的穩定性和效能。

     

  • 什麼是乙太網路?

    汽车以太网技术研究实验室

    1 到底什麼是以太網,這是一種協定嗎乙太網路通常指的是一種電腦網路技術,用於在區域網路(LAN)中傳輸資料。

    它最初由英特爾、DEC(Digital Equipment Corporation)和Xerox等公司在1970年代末和1980年代初共同開發,並於1980年代晚期和1990年代初期廣泛應用於企業和家庭網絡中。乙太網路技術本身包含了實體層(Physical Layer)和資料鏈結層(Data Link Layer)的規範,這些規範定義瞭如何在區域網路中傳輸資料幀(Frames)。它通常使用雙絞線、光纖或同軸電纜等物理介質進行資料傳輸。此外,乙太網路還涉及一系列的協定和標準,如IEEE 802.3系列標準,它規定了乙太網路的工作原理、資料傳輸速率、幀格式等細節。 IEEE 802.3標準定義了多種速率的以太網,從最初的10 Mbps(乙太網路)到現代的千兆乙太網路(Gigabit Ethernet)和萬兆乙太網路(10 Gigabit Ethernet)等。因此,可以說乙太網路既是一種電腦網路技術,也是一系列協定和標準的總稱。它是連接電腦、伺服器、網路設備和其他網路終端的基礎網路技術之一,廣泛用於各種規模的網路環境。

    2 兩個網路卡之間的雙絞線裡傳輸的是什麼訊號雙絞線用於連接網路設備,例如電腦、路由器、交換器等,以進行資料通訊。在乙太網路中,雙絞線通常用於傳輸數位訊號,而這些數位訊號表示二進位資料。具體來說,雙絞線傳輸的是差分訊號。在乙太網路中,通常使用差分訊號傳輸,即在一對雙絞線中,一個導線攜帶正電平訊號,而另一個導線攜帶負電平訊號。這種方式有助於減少電磁幹擾對訊號的影響,​​並提高訊號的穩定性和可靠性。在雙絞線中傳輸的訊號會根據特定的編碼規則(如曼徹斯特編碼、4B/5B編碼等)進行調製。這些編碼方式有助於實現時鐘恢復、減少誤碼率等目標,以確保資料的準確傳輸。整體而言,透過雙絞線傳輸的是經過數位編碼的二進位數據,這樣的數位訊號在乙太網路中用來表示各種類型的信息,包括數據、控制資訊等。

    3 乙太網路屬於類比通訊還是數位通訊乙太網路屬於數位通訊。在數位通訊中,數據以離散的數位形式進行傳輸和處理,而不是以連續的類比訊號形式。在乙太網路中,資料被轉換成數位訊號,透過網路中的電纜傳輸,並在目標裝置上再次解碼為資料。數位通訊具有許多優勢,包括抗干擾能力強、易於處理和複製、數據準確性高等。乙太網路作為一種數位通訊技術,能夠有效率地傳輸數據,並且適用於各種網路應用場景。

    4 乙太網路屬於串列通訊還是平行通訊乙太網路屬於串列通訊。在乙太網路中,資料透過一條電纜(例如雙絞線)以串列的方式傳輸。這是與並行通訊不同的。在串列通訊中,資料位元會依照時間順序一個接一個地傳輸,而在平行通訊中,多個位元同時傳輸。在乙太網路中,常見的實體層標準包括10BASE-T、100BASE-TX和1000BASE-T,它們都使用雙絞線來傳輸資料。在這些標準中,資料是按照一定的時間序列以串列方式在電纜上傳送的。總的來說,乙太網路採用了串列通訊的方式,這有助於降低電纜的成本、提高傳輸距離,並且更好地適應了高速資料傳輸的要求。

    5 平行通訊網路的實際案例包括:平行匯流排:並行匯流排是一種將多個處理器或裝置連接在一起的通訊網絡,它使用並行通訊技術,實現了高速、高效的資料傳輸。例如,Intel的Pentium處理器中的前端匯流排(FSB)就是一種平行匯流排。平行記憶體網路:平行記憶體網路是一種基於平行通訊的記憶體網絡,它將多個儲存單元連接在一起,實現了高速、高效的資料儲存和存取。例如,RAID(Redundant Array of Independent Disks)技術就是一種平行記憶體網路的應用。平行運算網路:平行運算網路是一種基於平行通訊的多處理器系統,它將多個處理單元連接在一起,實現了平行運算和處理。例如,叢集運算、網格運算和雲端運算等都是平行運算網路的應用。平行通訊協定:平行通訊協定是一種基於平行通訊的通訊協議,它可以在多個通訊鏈路上同時傳輸數據,提高了資料傳輸的速度和效率。例如,InfiniBand、PCI Express等都是平行通訊協定的應用。總之,平行通訊網路在許多領域都有應用,它可以提高資料傳輸的速度和效率,是實現高速、高效通訊的重要手段之一。

    6 乙太網路屬於單工或半雙工或全雙工乙太網路可以支援多種通訊模式,包括單工(Simplex)、半雙工(Half-Duplex)和全雙工(Full-Duplex)。具體的通訊模式取決於所使用的乙太網路標準和設備。單工(Simplex):單工通訊是指資料只能在一個方向上傳輸。在乙太網路中,單工通訊並不常見,因為它限制了通訊的靈活性。單工通訊通常用於一方向的廣播或接收,而不是雙向的互動。半雙工(Half-Duplex):半雙工通訊允許資料在兩個方向上傳輸,但不同的方向不能同時進行。在半雙工通訊中,設備需要在發送和接收之間切換。傳統的乙太網路(如10BASE-T和100BASE-TX)通常採用半雙工通訊。全雙工(Full-Duplex):全雙工通訊允許資料在兩個方向上同時傳輸,即設備可以同時發送和接收數據,而不需要切換。現代的乙太網路標準,如千兆乙太網路(1000BASE-T)和萬兆乙太網路(10GBASE-T),通常支援全雙工通訊。總體而言,儘管早期的乙太網路採用半雙工通信,但隨著技術的發展,現代乙太網路更傾向於使用全雙工通信,以提高頻寬和效能。然而,具體的通訊模式仍取決於網路設備的能力和配置。

    7 乙太網路屬於同步通訊還是非同步通訊1、乙太網路屬於非同步通訊。在非同步通訊中,資料的傳輸不依賴定時時脈訊號。乙太網路中的資料傳輸是基於事件觸發的,而不是透過固定的時鐘來同步發送和接收。在乙太網路中,資料幀被傳送到網路上,接收方根據訊框的起始和結束標記來解析資料。這種方式允許設備在需要時發送和接收數據,而不受固定時脈訊號的限制。因此,乙太網路的傳輸是事件驅動的,這使得網路設備能夠更靈活地適應不同的資料傳輸需求。相較之下,同步通訊需要發送和接收方的時鐘保持同步,以確保資料的準確傳輸。在非同步通訊中,由於沒有嚴格的時鐘同步要求,設備之間的通訊更加靈活,適用於乙太網路這樣的區域網路環境。 2.乙太網路是典型的同步時序邏輯,它的時脈訊號透過曼徹斯特編碼(以前)或4B/5B編碼(現在)編碼到了訊號當中,接收者需要從訊號當中使用鎖相環解出這個時脈訊號,這樣發送方和接收方就有了一個同步的時脈訊號。依靠這個同步的時脈訊號接收方能夠正確讀取發送方發送的資料。實際上幾乎所有的高速數位傳輸協定都是同步時序邏輯。然而,從軟硬體介面的角度來看,乙太網路通訊又是異步的。電腦不會直接透過CPU指令操作目前正在傳送的數據,而是透過一系列緩存,將資料送交到網路卡,或從網路卡讀取資料。資料到來時也是一樣的,網路卡不會在接收到網路封包第一位元組的時候就通知CPU處理,而是將接收到的資料先快取起來,隨時等待CPU或DMA在適當的時候讀取。這種有緩衝區的結構是典型的非同步通訊機制。不過,現在很多電信領域的以太網,已經演化出“同步以太網”,從設備要從線路上恢復時鐘,並將本地鐘鎖定到主設備發來的時鐘頻點上。因此乙太網路既有同步通訊的特點也有非同步通訊的特點,取決於特定的應用場景和情境環境。

    8 同步通訊的技術有哪些實際案例同步通訊是指資料的發送和接收在時間上是協調一致的,通訊雙方需要使用相同的時鐘或時序資訊來保持同步。以下是一些同步通訊的技術和實際案例:同步串行通訊:在串行通訊中,資料以位元的形式傳輸,而同步串行通訊使用時脈訊號來同步發送和接收方。 USB(Universal Serial Bus)和PCI Express是一些採用同步串行通訊的實際案例。 USB使用同步幀結構,而PCI Express使用基於包的同步通訊。同步並行通訊:並行通訊中的同步方式涉及同時傳輸多個位元位,並使用時脈訊號來保持同步。一些實際案例包括電腦內部的系統匯流排,例如PCI匯流排和PCI-X匯流排。同步通訊在網路中的應用:在電腦網路中,同步通訊也有一些應用。例如,同步乙太網路(Synchronous Ethernet)使用時脈訊號來協調網路中的各個節點,以提高時脈同步效能。同步通訊在無線通訊中的應用:在無線通訊中,同步通訊也是重要的。例如,LTE(Long-Term Evolution)等無線通訊標準採用同步技術,以確保基地台之間的同步性,進而提高網路效能。同步通訊在音訊視訊傳輸的應用:在音訊視訊傳輸中,同步通訊是至關重要的。例如,透過HDMI(High-Definition Multimedia Interface)傳輸的音訊視訊訊號需要同步,以確保音訊和視訊的一致性。同步通訊在即時系統中的應用:即時系統要求任務在規定的時間內完成,同步通訊在這些系統中是至關重要的。例如,工業自動化中的控制系統需要同步通訊來確保設備協同工作。這些實際案例突顯了同步通訊在不同領域中的廣泛應用,以確保資料傳輸的協調性和一致性。同步通訊有助於提高系統的可靠性和效能。

    9 非同步通訊在現實中有哪些實際案例非同步通訊是指資料的發送和接收之間沒有預定的時間關係,通訊雙方使用起始位元和停止位等手段來決定資料的起始和結束。以下是一些非同步通訊在現實中的實際案例:串行通訊中的非同步傳輸:大多數串行通訊協定中採用了非同步傳輸方式。例如,RS-232串列埠通訊就是一種非同步通訊協議,它在資料的起始和結束位置使用起始位元和停止位元來實現同步。電子郵件通訊:電子郵件系統通常採用非同步通訊方式。當使用者發送電子郵件時,它並不是即時傳送到接收者,而是在系統中儲存並等待接收者檢查並拉取。文件傳輸協定(FTP):FTP是一種用於在電腦之間傳輸檔案的協議,它採用非同步通訊方式。用戶可以在任意時間請求上傳或下載文件,而不需要嚴格的時間同步。 Web瀏覽器與伺服器通訊:在網頁瀏覽器與伺服器之間的通訊中,採用了非同步通訊的技術,例如Ajax(Asynchronous JavaScript and XML)。這允許在不刷新整個頁面的情況下異步加載數據,提高用戶體驗。感測器資料擷取:在嵌入式系統和物聯網應用中,感測器通常以非同步方式向中央控制系統發送資料。這允許感測器在需要時主動發送數據,而不需要與中央系統保持嚴格的時間同步。串口通訊設備:許多嵌入式設備和感測器與電腦之間的通訊採用非同步串口通訊。這種通訊方式簡單又靈活,適用於許多嵌入式系統。非即時聊天應用:一些即時通訊應用,尤其是非即時的訊息應用,採用了非同步通訊。訊息在發送者發送後,並不需要立即被接收者接收。這些實際案例展示了非同步通訊在各種應用場景中的廣泛應用。非同步通訊方式的靈活性和簡單性使其成為許多應用中的理想選擇。

    10 同步通訊和非同步通訊進行對比,各自有什麼優缺點同步通訊和非同步通訊是兩種不同的資料傳輸方式,它們在效能、複雜性和應用場景等方面存在一些差異。以下是同步通訊和非同步通訊的優缺點對比:同步通訊:優點:高效率:同步通訊的傳輸速率通常較高,因為資料的發送和接收在預定的時間關係內協調一致。即時性:適用於即時性要求較高的應用,如音訊視訊傳輸、即時控制系統等。易於調試:在同步通訊中,由於資料傳輸的時間關係已經確定,因此調試和故障排除相對較容易。缺點:複雜性:同步通訊系統通常需要更複雜的硬體和軟體支持,以確保時鐘同步和資料協調。靈活性差:不夠靈活,對設備和系統的要求較高,難以適應異構系統和設備。成本較高:由於同步通訊需要精密的時鐘同步和硬體支持,因此可能造成較高的成本。非同步通訊:優點:簡單性:非同步通訊相對簡單,不需要精確的時鐘同步,減少了系統的複雜性。靈活性:更靈活,適應性強,可以用來連接異質系統和設備。成本較低:由於不需要複雜的時脈同步和硬體支持,因此成本相對較低。缺點:效率相對較低:由於沒有預定的時間關係,可能導致資料傳輸效率相對較低。不適合即時應用:較不適合即時性要求較高的應用,如即時控制系統、音訊視訊傳輸等。較難調試:非同步通訊系統中,由於資料傳輸的時間關係不確定,調試和故障排除相對較難。在選擇同步通訊或非同步通訊時,需要根據特定的應用場景和要求進行權衡。有些應用更適合採用同步通信,而在其他場景中,非同步通信

  • 如何保障軟體供應鏈安全?

     保密科学技术

    近年來,軟體供應鏈安全事件頻發,2024年7月的微軟「藍色畫面」事件進一步凸顯了軟體供應鏈安全的重要性。

    軟體供應鏈源頭難以掌握、開源軟體引入的安全風險及軟體供應鏈安全管控制度和措施的不完善已成為軟體供應鏈安全面臨的主要挑戰。

    那麼,如何才能更好地保障軟體供應鏈安全呢?

    1.建構軟體物料清單,有效辨識軟體供應鏈風險。

    需要引導產業用戶和資訊科技企業建立軟體物料清單(SBOM),建立軟體全生命週期的供應鏈管理。同時,可透過廠商自評估與專業技術機構評估結合的方式,定期進行軟體供應鏈安全風險評估工作。

    2.建置軟體供應鏈安全公共服務平台,回饋共享軟體供應鏈情報。

    應積極推動業者、軟體供應商、網路安全服務機構等協同建置軟體供應鏈安全公共服務平台,持續提升供應鏈安全威脅情報蒐集能力,為軟體供應鏈保障提供警報服務及處置技術支援。

    3.建立常態化緊急應變機制,從容應對軟體供應鏈威脅。面向作業系統、資料庫等重點領域,應深入進行風險研判,並積極做好應對預案。

    此外,定期組織進行緊急演練,保障突發情況下關鍵資訊系統運作不受影響。

    4.加快提升核心技術水平,從源頭掌控軟體供應鏈。努力加速核心技術攻關,盡快完善軟體開發生態建設,力求引領更多技術方向,提升話語權和影響力。

     

    【摘自《保密科學技術》2024年2月刊《軟體供應鏈安全能力模型研究》一文,作者: 翟艷芬、袁薇、王鬱】

  • QUIC協定為什麼要基於UDP協定而不是直接基於IP協定

    原創  外太空的金山
    QUIC協定選擇基於UDP而不是直接基於IP協定主要有兩個原因:網路路徑上的中間盒支援問題和終端上核心支援問題。
    網路路徑上的中間盒支援問題:純IP協定在網路上不好傳播,因為網路中的許多元件(如NAT、防火牆、LB等)都是基於TCP和UDP的。

    如果不使用UDP,這些元件就無法辨識或正常運作。因此,為了保持網路的兼容性和功能性,QUIC選擇了基於UDP的實作方式。

    終端上核心支援問題:終端設備(尤其是用戶終端)的核心普遍支援UDP,但純IP協定的派發給使用者程序的方式未知。如果使用connectionID來派發,那麼核心需要進行相應的調整。這涉及到作業系統核心的重新設計,無論是微軟還是用戶都不太可能接受這樣的改動。因此,為了減少對現有系統和終端設備的改動需求,QUIC選擇了基於UDP的實作方式。

    綜上所述,QUIC協議選擇基於UDP而不是直接基於IP協議,主要是出於對網路相容性、功能保持以及對現有系統和終端設備影響最小的考慮QUIC 協議現在市面上已經有基於UDP 協議實現的可靠傳輸協議的成熟方案了,那就是QUIC 協議,已經應用在了HTTP/3。這次,聊聊 QUIC 是如何實現可靠傳輸的?又是如何解決上面 TCP 協定四個面向的缺陷?

    QUIC 是如何實現可靠傳輸的?要基於 UDP 實現的可靠傳輸協議,那麼就要在應用層下功夫,也就是要設計好協議的頭部字段。拿 HTTP/3 舉例子,在 UDP 訊息頭部與 HTTP 訊息之間,共有 3 層頭部:

    Packet HeaderPacket Header 首次建立連線時和日常傳輸資料時所使用的 Header 是不同的

    QUIC 也是需要三次握手來建立連線的,主要目的是為了協商連線 ID。協商出連線 ID 後,後續傳輸時,雙方只需要固定住連線 ID,從而實現連線遷移功能。

    所以,你可以看到日常傳輸資料的 Short Packet Header 不需要在傳輸 Source Connection ID 欄位了,只需要傳輸 Destination Connection ID。 Short Packet Header 中的Packet Number 是每個封包獨一無二的編號,它是嚴格遞增的,也就是說就算Packet N 遺失了,重傳的Packet N 的Packet Number 已經不是N,而是一個比N 大的值。

    為什麼這樣子設計?

    TCP 在重傳封包時的序號和原始封包的序號是相同的,也正是由於這個特性,引入了 TCP 重傳的歧義問題。

    當 TCP 發生逾時重傳後,客戶端發起重傳,然後接收到了服務端確認 ACK 。由於客戶端原始封包和重傳封包序號都是一樣的,那麼服務端針對這兩個封包回應的都是相同的 ACK。這樣的話,客戶端就無法判斷出是「原始報文的回應」還是「重傳報文的回應」,這樣在計算 RTT(往返時間) 時應該選擇從發送原始報文開始計算,還是重傳原始報文開始計算呢?RTO (超時時間)是基於 RTT 來計算的,那麼如果 RTT 計算不精準,那麼 RTO (超時時間)也會不精確,這樣可能導致重傳的機率事件增大。

    QUIC 封包中的 Pakcet Number 是嚴格遞增的, 即使是重傳報文,它的 Pakcet Number 也是遞增的,這樣就能更加精確計算出報文的 RTT。

    另外,還有一個好處,單調遞增的設計,可以讓資料包不再像TCP 那樣必須有序確認,支援亂序確認,當資料包Packet N 遺失後,只要有新的已接收資料包確認,當前視窗就會繼續向右滑動,這樣就不會因為丟包重傳將目前視窗阻塞在原地,從而解決了隊頭阻塞問題。

    QUIC Frame Header一個 Packet 封包中可以存放多個 QUIC Frame。每一個 Frame 都有明確的類型,針對類型的不同,功能也不同,自然格式也不同。我這裡只舉例 Stream 類型的 Frame 格式,Stream 可以認為就是一條 HTTP 請求,它長這樣:

     

    QUIC 是如何解決 TCP 隊頭阻塞問題的?

    在一條 QUIC 連線上可以並發發送多個 HTTP 請求 (Stream)。但是 QUIC 給每一個 Stream 分配了一個獨立的滑動窗口,這樣使得一個連接上的多個 Stream 之間沒有依賴關係,都是相互獨立的,各自控制的滑動窗口。

    假如 Stream2 丟了一個 UDP 包,也只會影響 Stream2 的處理,不會影響其他 Stream,與 HTTP/2 不同,HTTP/2 只要某個流中的封包遺失了,其他流也會因此受影響。

    QUIC 是如何做流量控制的? QUIC 是基於UDP 傳輸的,而UDP 沒有流量控制,因此QUIC 實現了自己的流量控制機制,QUIC 的滑動視窗滑動的條件跟TCP 有一點差別,但是同一個Stream 的資料也是要保證順序的,不然無法實作可靠傳輸,因此同一個Stream 的資料包遺失了,也會造成視窗無法滑動。

    QUIC 的 每個 Stream 都有各自的滑動窗口,不同 Stream 互相獨立,隊頭的 Stream A 被阻塞後,不妨礙 StreamB、C的讀取。而對於 HTTP/2 而言,所有的 Stream 都跑在一條 TCP 連接上,而這些 Stream 共享一個滑動窗口,因此同一個Connection內,Stream A 被阻塞後,StreamB、C 必須等待。

    QUIC 實現了兩種級別的流量控制,分別為Stream 和Connection 兩種級別:Stream 級別的流量控制:Stream 可以認為就是一條HTTP 請求,每個Stream 都有獨立的滑動窗口,所以每個Stream 都可以做流量控制,防止單一Stream 消耗連接(Connection)的全部接收緩衝。 Connection 流量控制:限制連線中所有 Stream 相加起來的總位元組數,防止發送方超過連線的緩衝容量。

    QUIC 更快的連接建立對於HTTP/1 和HTTP/2 協議,TCP 和TLS 是分層的,分別屬於內核實現的傳輸層、openssl 庫實現的表示層,因此它們難以合併在一起,需要分批次來握手,先TCP 握手(1RTT),再TLS 握手(2RTT),所以需要3RTT 的延遲才能傳輸數據,就算Session 會話服用,也需要至少2 個RTT。HTTP/3 在傳送資料前雖然需要 QUIC 協定握手,這個握手過程只需要 1 RTT,握手的目的是為確認雙方的「連線 ID」,連線遷移就是基於連線 ID 實現的。但是HTTP/3 的QUIC 協定並不是與TLS 分層,而是QUIC 內部包含了TLS,它在自己的幀會攜帶TLS 裡的“記錄”,再加上QUIC 使用的是TLS1.3,因此僅需1 個RTT 就可以「同時」完成建立連線與金鑰協商,甚至在第二次連線的時候,應用資料包可以和QUIC 握手資訊(連線資訊+ TLS 資訊)一起傳送,達到0-RTT 的效果。 如下圖右邊部分,HTTP/3 當會話恢復時,有效負載資料與第一個資料包一起傳送,可以做到 0-RTT(下圖的右下角):

    QUIC 平滑遷移連接基於 TCP 傳輸協定的 HTTP 協議,由於是透過四元組(來源 IP、來源連接埠、目的 IP、目的連接埠)確定一條 TCP 連線。

    那麼當行動裝置的網路從 4G 切換到 WIFI 時,表示 IP 位址變化了,那麼就必須斷開連接,然後重新建立 TCP 連線。而建立連線的過程包含 TCP 三次握手和 TLS 四次握手的時延,以及 TCP 慢啟動的減速過程,給用戶的感覺就是網路突然卡頓了一下,因此連線的遷移成本是很高的。

    QUIC 協定沒有用四元組的方式來「綁定」連接,而是透過連接ID來標記通訊的兩個端點,客戶端和伺服器可以各自選擇一組ID 來標記自己,因此即使行動裝置的網路變化後,導致IP 位址變更了,只要仍保有上下文資訊(例如連接ID、TLS 金鑰等),就可以「無縫」地複用原連接,消除重連的成本,達到了連接遷移的功能。

  • D-UN-DY-23:Dell Unity Deploy 2023 Exam

    D-UN-DY-23:Dell Unity Deploy 2023 Exam,統一部署

    可用語言:英語,法語,日語
    Dell Unity Deploy 2023 Certification Description
    認證概覽
    此認證有利於任何需要證明其能力的專業人士
    部署 Dell Unity、Dell Unity XT 和 Dell Unity VSA 系統。認證要求
    要成功完成此認證,候選人必須:
    1.透過實際操作產品擁有足夠的知識庫/技能經驗和/或接受推薦的訓練。
    2. 通過 Dell Unity Deploy 2023 考試
    注意:這些詳細資訊反映了截至 2023 年 2 月 6 日的認證要求。
    經過驗證的專業計劃定期更新認證以反映技術貨幣和相關性。

    請查看經過驗證的專業網站定期了解最新資訊。

    考試概述
    該考試評估在生產中管理 Dell Unity 儲存系統所需的知識和技能
    根據業務需求提供環境和配置。這也可能包括配置任務
    與 Dell Unity 系統的持續管理和一些基本整合主題保持一致。
    產品
    本次考試可能涉及的產品包括但不限於:
    • 戴爾Unity
    • 戴爾Unity XT
    • Dell Unity VSA
    考試主題
    本次考試可能涵蓋的主題包括:
    Dell Unity 平台概念、功能與架構 (10%)
    • 描述 Dell Unity 平台架構、特性與功能
    • 描述 Dell Unity VSA 軟體定義的儲存解決方案
    • 辨識 Dell Unity XT 硬體組件
    Dell Unity XT 和 UnityVSA 安裝與服務 (10%)
    • 安裝並初始化 Dell Unity XT 儲存系統
    • 部署和初始化 Dell UnityVSA 系統
    • 執行關鍵服務任務並確定相關資源
    • 描述 Dell Unity Platform 服務功能
    Dell Unity XT 和 UnityVSA 系統管理 (5%)
    • 識別並描述用於監控和管理 Dell Unity 系列儲存系統的使用者介面
    • 設定 Dell Unity XT 支援和基本系統設定以進行系統管理
    Dell Unity XT 和 UnityVSA 儲存配置和存取 (25%)
    • 描述動態和傳統儲存池及其配置方式
    • 描述動態池擴展、混合驅動器大小的注意事項以及重建過程
    • 設定區塊、檔案和VMware 資料儲存存儲
    • 配置主機對區塊儲存資源的存取
    • 設定 NAS 用戶端對 SMB 和 NFS 檔案儲存資源的存取
    • 設定VMware ESXi 主機以存取VMware 資料儲存儲存資源
    儲存效率、可擴充性和效能特徵 (25%)
    • 描述並設定FAST Cache
    • 描述和設定檔級保留
    • 描述和配置資料縮減
    • 描述和配置FAST VP
    資料保護和移動性 (25%)
    • 描述快照資料保護功能和快照創建
    • 描述複製資料保護功能
    • 為儲存資源建立同步和非同步複製會話
    上述每個主題後面的百分比反映了整個問題集的大致分佈
    D-UN-DY-23考試時間:90分鐘

  • 什麼是MicroPython?和Python的差別在哪裡?

    MicroPython 是一種針對微控制器和嵌入式系統最佳化的 Python 3 語言實作。它由澳洲物理學家 Damian George 創建,旨在提供一種輕量級的 Python 版本,以便在資源有限的環境中運作。與傳統的 Python(通常指 CPython)相比,MicroPython 在記憶體管理、庫支援和功能上有顯著不同。
    MicroPython 的特點
    輕量級:MicroPython 經過精簡,包含了 Python 標準庫中的一小部分,並針對微控制器進行了優化,使其能夠在內存和處理能力有限的設備上運行14。
    手動內存管理:與 CPython 的自動垃圾回收不同,MicroPython 需要用戶手動管理內存,這意味著開發者需要更仔細地分配和釋放內存12。
    互動式開發:MicroPython 支援 REPL(Read-Eval-Print Loop)模式,讓開發者在命令列中輸入程式碼並即時查看結果,這對於硬體程式設計非常有用

    MicroPython 与 Python 的主要区别

    特性 MicroPython Python (CPython)
    目标平台 微控制器和嵌入式系统 通用计算机(桌面、服务器等)
    库支持 仅支持部分标准库 拥有丰富的第三方库生态系统
    内存管理 手动内存管理 自动垃圾回收
    执行效率 针对资源受限环境优化 一般较高,但不针对特定硬件优化
    语法兼容性 与 Python 3 基本兼容 标准的 Python 3 实现

    MicroPython 在多個實際應用中展現了其靈活性和高效性,尤其是在物聯網(IoT)和嵌入式系統領域。以下是一些常見的應用場景:
    1. 物聯網設備
    MicroPython 被廣泛用於物聯網設備的開發,例如智慧家庭產品、環境監測感測器和智慧農業解決方案。由於其輕量級特性,MicroPython 能夠在資源有限的設備上運行,使得開發者能夠快速原型設計和部署 IoT 解決方案45。
    2. 教育與學習
    MicroPython 是許多教育機構和程式設計課程中教授程式設計的工具,特別是在 STEM 教育中。它提供了一個易於上手的環境,讓學生透過實際程式設計與硬體互動,從而激發他們對程式設計和電子學的興趣34。
    3. 機器人技術
    在機器人專案中,MicroPython 常用於控制馬達、感測器和其他硬體組件。開發者可以利用 MicroPython 快速實現控制邏輯,進行實驗和迭代12。
    4. DIY 項目
    許多愛好者和創客使用 MicroPython 來建立自己的電子專案。無論是製作自訂的控制面板、LED 燈光效果還是其他創意項目,MicroPython 提供了簡單的編程接口,使得這些項目更易於實現35。
    5. 數據採集與監測
    MicroPython 可用於資料擷取系統,例如氣象站或水質監測設備。這些系統通常需要處理感測器資料並將其上傳到雲端或本地伺服器,MicroPython 的網路功能使這一過程變得簡單且有效率46。
    總而言之,MicroPython 的應用範圍非常廣泛,涵蓋了從教育到專業開發的多個領域,特別是在需要與硬體直接互動的場景中表現突出。

  • 現如今,到底什麼技術堆疊最流行,我簡直不敢相信(全球調查)

     58沈剑 架构师之路

    技術人,都非常關注科技流行趨勢。
    那麼當下,全球什麼技術棧,什麼研發工具最流行呢? stackoverflow在23年底做了一個全球調查,涵蓋程式語言,資料庫,研發工具,IDE,AI輔助工具…. 等多方面。
    讓我們一起看看:我們是否在潮頭?中外又有什麼差異,值得我們反思借鏡的呢?
    第一項:開發語言(多選)

    各種語言的使用場景有所不同,抽取後端開發的常用語言:Python,45.32%Java,30.49%
    C#,29.16%
    C++,20.21%
    PHP,19.03%
    C,16.66%go,14.32%

    而大家問自己的體感,是這個狀況嗎?為什麼國外C#用很多,而go相對較少?而國內正好反過來呢?

    第二項:数据庫(多選)

    各種資料庫的使用場景有所不同(SQLite,Redis,ES),抽取後端固化儲存的資料庫:

    PostgreSQL:49.09%

    MySQL:40.59%

    SQL-Server:27.34%

    MongoDB:25.66%

    MariaDB:17.69%

    Dynamodb: 10.31%Oracle:10.06%
    社群研究中,PostgreSQL超越MySQL成為全球最受歡迎的資料庫!

    畫外音,較權威的DB-Engines的排名為:
    Oracle > MySQL > SQL-Server > PG

    這裡面,能看出一些國內外資料庫使用的差異:
    其一,國內外,開源與閉源的比例的差異。從全球統計資料來看,閉源商業資料庫 SQL-Server, Oracle 使用比例並不低;但是在國內,閉源商業資料庫的使用,卻沒有這麼高的比例,原因是什麼呢?
    其二,國內外,開源趨勢的差異。 PostgreSQL, MongoDB, MariaDB, Dynamodb… 等後起之秀,在中國幾乎沒有掀起什麼風浪,國內仍是MySQL的天下,原因又是什麼呢?
    其三,開源貢獻的差異。咱們的產品,排名最高的是:
    TiDB:0.19%,排名32位畫外音:國內聲音很大的OceanBase,PolarDB等產品都沒見影子。
    我們擁有全球最多的開發者、工程師、架構師、科學家、研究員… 然而,我們的科技創新競爭力卻… 為什麼會有這樣的差距?
    第三項:套件管理,依賴管理,打包工具(多選)

    這裡面,能看出一些國內外工具使用的差異:
    其一,容器化程度差異。從全球統計數據來看,Docker與K8s,基本上已經是標配,但國內的覆蓋率似乎沒有這麼高。容器化確實是降本增效的利器,為什麼大家的系統都會遷移不動?
    其二,Python流行度。 pip的排名如此靠前,比Make和Maven都高出一大截,與開發語言模組研究的結論是一致。為什麼國外Python比其他後端語言更受歡迎呢?
    畫外音:Make的比重超過Maven我沒想到的。
    第四項:IDE(多選)

    VS code:74.09%VS:28.74%
    IntelliJ IDEA:28.06%與大家預想的一樣嗎?

    國內外的差異在於:居然24.49%的人使用Notepad,22.59%的人使用Vim開發程序,這個比例應該是遠超國人的吧?
    畫外音:

    1. 沒有看到Vim與emacs之爭,emacs退出歷史舞台了嗎?

    2. 我當時用Source Insight與Vim寫C++,用Notepad寫PHP。為什麼?我的「小師傅」用這幾個工具。
    第五項:AI輔助工具(多選)

    在國外,工程師幾乎100%都用上AI輔助工具了,而且其中83%的工程師正用ChatGPT!兄弟姊妹們,你們用ChatGPT嗎,難道不自慚形穢嗎?
    第六項:AI程式輔助工具

    在國外,56%的工程師都用上Copilot輔助程式了!兄弟姊妹們,你們用著Copilot嗎,不自慚形穢嗎?
    今後,淘汰我們的可不是AI,而是那些用AI工具的其他工程師!
    第七項:文件管理與非同步協同(多選)

    Jira,遙遙領先confluence,屈居第二Markdown File,穩居第三Trello與Notion緊跟著畫外音:wiki大家都不用了嗎?

    對比國內,文件有什麼用,還要Markdown File?那更不可能了。即使有文檔,也只寫一次,接口與文檔,是不太可能對的上的。出了問題怎麼辦?看代碼呀!
    為什麼國內的工程師如此不重視文件?我是這麼考慮的:
    其一,習慣。
    看文檔,浪費我自己的時間,又麻煩。
    問別人,我比較方便。打攪別人?我才不管。
    長此以往,寫了文檔也沒人看,誰還寫文檔?

    其二,專案壓力。開發週期這麼緊張,程式碼都寫不完,還寫文件?當文檔成為額外的負擔,誰還寫?
    其三,文化。
    我只是暫時在這個模組,這個崗位,這個公司。混口飯吃而已,過一段時間就跳槽了。沒有文檔,我舉足輕重,現在出了問題,只有我能搞定。傳承?是給自己立競爭對手。未來出了問題?看代碼去呀,與我無關。
    結束語
    看完stackoverflow的2023年度流行技術棧與研發工具研究結果,感觸良多:為何國外C#,SQL-Server,Oracle用的多?咱們對開源的貢獻,為何遠低於國外?容器化,先進又好用,為何難以推進,使用率遠低於國外?手搓程式碼的工程師比例,為何遠低於國外? GPT與Copilot的使用比例,為何遠低於國外?對文檔的重視程度,為何遠低於國外?

  • 測試開發和軟體測試的差別?

     程大棉

    什麼是軟體測試?
    軟體測試就是在特定條件下對程式進行操作,在程式中需尋找 Bug 的過程,確保程式實現功能符合產品需求,程式品質符合準出標準。
    軟體測試招募要求:
    職位說明:
    1、電腦、資訊科技等相關專業專科及以上學歷;
    2、可熟練編寫linux下shell測試腳本;
    3.熟練使用Linux作業系統,熟悉linux系統下常用的效能及壓力測試程序;
    4、能夠完成伺服器的日常管理與維護工作;
    5、具備軟體測試的基本思想,能夠嚴謹的分析設計測試用例;
    6、良好的溝通能力,有嵌入式軟體測試經驗者優先.

    什麼是測試開發?
    測試開發仍屬於測試,分為兩類:一類是業務驅動型的測試開發,負責業務的測試工作,同時也需要深入業務,挖掘業務過程中各環節的品質的弱點,通過流程改造,開發測試工具等手段來提升自己的工作效率。工作中業務測試比例和工具開發比例基本上各50%,現在大廠的測試開發多為此類。一類是開發平台框架的測試開發,這類測試開發沒有業務測試工作,專職開發測試平台、測試框架供其他測試同學使用,開發的程式主要的使用者是測試。
    測驗開發招募要求:
    職位描述
    1.5年以上網路及傳統產業的測試開發經驗,對軟體品質保障有系統化的思考與經驗。能夠面對
    複雜情況建立體系化的軟體品質控制的策略和模型,並且有大型專案成功實踐的經驗;
    2.具備業務或測試技術(自動化、效能、安全、使用者體驗、穩定性等)某方面的專長,具有一定的
    業務建模能力或測試技術預研、選用、設計開發、統一規劃的能力。
    3.具備抽象提煉測試技術的共通性問題,主導業務線相關領域的測試系統建設,持續發現與解決重大
    系統、業務問題
    4.優秀的程式碼實作能力,精通C/C++,JAVA,Python等程式語言之一,並有實際專案程式碼經驗;
    5.邏輯能力強、思維活躍,接受新事物能力強;責任感強,積極主動,善於溝通,良好的團隊合作
    能力;良好英文溝通能力;
    6.大型網路名企經驗優先,數據及演算法測試經驗優先。

    測試開發和軟體測試的程式設計技能要求?

    普通的軟體測試人員的程式設計技能不是強要求,能看懂程式碼即可。測試開發的程式設計技能是強要求,必須具備一定的開發能力,能開發自動化測試工具,或二次開發開源專案。