An open-source monitoring acquisition method and system for multi-link hopping
Patent Information
- Application Number
- CN202610902763.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-06-23
- Publication Date
- 2026-10-16
AI Technical Summary
[0014]本公开的有益效果：本公开提供了一种多链路跳转的开源监控获取方法、系统，通过云节点负责重计算任务(加密/解密)，边缘节点专注低延迟转发，云节点和边缘节点共同构成了云边协同架构，通过云边协同架构使资源分配更高效。本公开通过模块化解耦设计，且配置可以组合或独立运行的各步骤(解析→跳转→加密→传输→重组)，从而便于灵活扩展和维护。本公开中，通过全链路安全闭环设计，实现DNS隐藏→AES加密→TLS 1.3传输，从而形成了三层防护体系。本公开中，可以配备有零信任模型，实现了分片加密密钥动态生成，避免长期有效密钥的潜在风险。
Smart Images
Figure CN122933854A_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to the field of video surveillance technology, specifically to an open-source monitoring acquisition method and system with multi-link hopping. Background Technology
[0002] With the deepening of the Internet of Things and smart city construction, video surveillance systems face challenges such as cross-regional network heterogeneity, insufficient adaptation of open source architecture, and security and compliance risks. At the same time, privacy-sensitive scenarios have given rise to the need for covert transmission of video streams, which requires breaking through the bottleneck of traffic feature exposure of traditional VPNs. Meanwhile, the popularization of ultra-high-definition video has driven the evolution of segmented transmission technology, which urgently needs to solve the problems of timing management, redundancy control, and distributed consistency of segmented reassembly. Summary of the Invention
[0003] To address the problems existing in the prior art, this disclosure proposes an open-source monitoring and acquisition method and system for multi-link hops, to solve at least one of the aforementioned technical problems. The technical solution adopted in this disclosure is as follows: In a first aspect, this disclosure provides an open-source monitoring method for obtaining multi-link jumps, the method comprising: S100: Resolve the domain name of the target monitoring source to obtain its IP address; S200: Obtain the original video stream based on the IP address; S300: The target video stream is obtained after preprocessing the original video stream; S400: The target video stream is transmitted to the requesting end (server end) via a multi-level jump mechanism through the cloud server node; S500: The requesting end (server end) performs a ciphertext (data ciphertext) operation on the received target video stream to obtain several ciphertext fragments; S600: The requesting end (server end) sorts all ciphertext fragments in timestamp order to obtain a ciphertext fragment sequence, and checks whether packet loss has occurred based on the ciphertext fragment sequence (if the fragment sequence number is not continuous, it means that it is missing); S700: If yes, complete the ciphertext fragment sequence based on the fault tolerance mechanism to ensure that the ciphertext fragment sequence numbers in the ciphertext fragment sequence are continuous, and then continue to execute S800; otherwise, execute S800 directly. S800: Reassemble the encrypted fragment sequence into the final video stream in sequence.
[0004] Preferably, before step S100, the method further includes: Rent a cloud server and deploy Nginx to build the necessary network transmission links.
[0005] Preferably, in step S100, an open-source monitoring system is used to resolve the domain name of the target monitoring source to obtain its IP address.
[0006] Preferably, in S300, the preprocessing includes segmentation, encryption, and splicing (encapsulation).
[0007] Preferably, in S400, the multi-level jump mechanism ensures data security during the forwarding process of data at multiple relay nodes. By encrypting the information between each relay node layer by layer, the security of data transmission is guaranteed, and the difficulty of tracing the source is increased.
[0008] Preferably, in step S500, the requesting end (server end) performs a ciphertext separation (data ciphertext) operation on the received target video stream, specifically including: Preferably, in step S600, the requesting end (server end) sorts all ciphertext fragments in timestamp order to obtain a ciphertext fragment sequence, and corrects clock deviations based on the timestamps in each ciphertext fragment to ensure data continuity.
[0009] Preferably, the method further includes: S900: Play and display the final video stream.
[0010] A second aspect of this disclosure provides an open-source monitoring and acquisition system for multi-link hops, the system comprising: The domain name resolution module is used to resolve the domain name of the target monitoring source to obtain its IP address; The video stream module is used to obtain the raw video stream based on the IP address; The preprocessing module is used to preprocess the original video stream to obtain the target video stream; A multi-level jump transmission module is used to transmit the target video stream to the requesting end (server end) based on a multi-level jump mechanism through a cloud server node; The ciphertext separation module is used by the requesting end (server end) to perform ciphertext separation (data ciphertext) operation on the received target video stream to obtain several ciphertext fragments; The fragment sorting module is used by the requesting end (server end) to sort all encrypted fragments in timestamp order to obtain an encrypted fragment sequence, and to check whether packet loss has occurred based on the encrypted fragment sequence (if the fragment sequence number is not continuous, it means that it is missing). The packet loss completion module is used to complete the ciphertext fragment sequence based on the triggered fault tolerance mechanism if the packet loss occurs, so as to ensure that the ciphertext fragment sequence numbers in the ciphertext fragment sequence are continuous, and then continue to execute the fragment reassembly module; otherwise, the fragment reassembly module is executed directly. The fragment reassembly module is used to reassemble the encrypted fragment sequence into the final video stream segment in sequence.
[0011] Preferably, the system further includes: The playback and display module is used to play and display the final video stream segment.
[0012] In a third aspect, this disclosure provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the open-source monitoring and acquisition method for multi-link jumps as described above.
[0013] In a fourth aspect, this disclosure provides an electronic device including a processor and a memory, the processor being configured to execute a computer program stored in the memory to implement the open-source monitoring and acquisition method for multi-link hops as described above.
[0014] The beneficial effects of this disclosure are as follows: This disclosure provides an open-source monitoring and acquisition method and system for multi-link hops. Cloud nodes handle heavy computation tasks (encryption / decryption), while edge nodes focus on low-latency forwarding. Together, cloud and edge nodes form a cloud-edge collaborative architecture, which improves resource allocation efficiency. This disclosure employs a modular, decoupled design, and the configuration allows for combined or independent operation of each step (resolution → hop → encryption → transmission → reassembly), facilitating flexible expansion and maintenance. This disclosure utilizes a full-link security closed-loop design, achieving DNS hiding → AES encryption → TLS 1.3 transmission, thus forming a three-layer protection system. This disclosure can be equipped with a zero-trust model, enabling dynamic generation of fragmented encryption keys and avoiding the potential risks of long-term valid keys.
[0015] Compared with the prior art, this disclosure has the following advantages: (1) Cross-regional high availability: Multi-regional cloud node deployment + Nginx load balancing avoids single points of failure and ensures stable access worldwide. It also automatically switches healthy nodes to cope with network fluctuations or regional failures.
[0016] (2) Concealment and censorship resistance: Multi-level redirection hides the real IP address of the target monitoring source, circumventing firewall blocking and DPI detection. Request headers are disguised as ordinary HTTPS traffic, reducing the risk of being identified as a video stream.
[0017] (3) Efficient fragmentation and fault tolerance mechanism: The video stream is processed in segments, and only damaged segments are retransmitted, reducing bandwidth waste. It supports out-of-order reassembly and FEC error correction, and tolerates network packet loss and latency.
[0018] (4) End-to-end security protection: Data fragmentation is encrypted based on the AES-256 algorithm and combined with TLS 1.3 transmission to prevent man-in-the-middle attacks. Dynamic key management avoids the risk of leakage caused by long-term valid keys.
[0019] This disclosure, through the combination of cloud-edge collaborative architecture, modular decoupling design, and end-to-end security closed-loop design, expands application scenarios: (A) Cross-border monitoring: solves cross-border network latency and blocking issues, suitable for global enterprise branch management; (B) Privacy protection: in scenarios such as home security and law enforcement evidence collection, data is encrypted throughout the process and traffic characteristics are concealed; (C) Emergency response: in scenarios such as drone inspection and temporary deployment, it enables rapid deployment and supports dynamic adjustment of monitoring sources. This disclosure also optimizes cost and efficiency: (A) Reduced overall cost: by adopting open-source components + elastic billing of cloud resources, the cost is reduced by 40% compared to traditional solutions; (D) Simplified operation and maintenance: automated parsing, breakpoint resume, and fault tolerance mechanisms reduce the need for manual intervention. Attached Figure Description
[0020] The accompanying drawings, which form part of this application, are used to provide a further understanding of this disclosure. The illustrative embodiments of this disclosure and their descriptions are used to explain this disclosure and do not constitute an undue limitation of this disclosure.
[0021] Figure 1 This is a flowchart of an open-source monitoring and acquisition method for multi-link hopping as described in Embodiment 1 of this disclosure.
[0022] Figure 2 This is an architecture diagram of an open-source monitoring and acquisition system for multi-link hopping as described in Embodiment 2 of this disclosure. Detailed Implementation
[0023] The present disclosure will now be described in detail with reference to the accompanying drawings and embodiments. It should be noted that, unless otherwise specified, the embodiments and features described in the present application can be combined with each other.
[0024] The following detailed descriptions are exemplary and intended to provide further detailed explanation of this disclosure. Unless otherwise specified, all technical terms used in this disclosure have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to limit the exemplary embodiments according to this disclosure.
[0025] Example 1: like Figure 1 As shown, this disclosure provides an open-source monitoring and acquisition method for multi-link hops, the method including: S100: Resolve the domain name of the target monitoring source to obtain its IP address; S200: Obtain the original video stream based on the IP address; S300: The target video stream is obtained after preprocessing the original video stream; S400: The target video stream is transmitted to the requesting end (server end) via a multi-level jump mechanism through the cloud server node; S500: The requesting end (server end) performs a ciphertext (data ciphertext) operation on the received target video stream to obtain several ciphertext fragments; S600: The requesting end (server end) sorts all ciphertext fragments in timestamp order to obtain a ciphertext fragment sequence, and checks whether packet loss has occurred based on the ciphertext fragment sequence (if the fragment sequence number is not continuous, it means that it is missing); S700: If yes, complete the ciphertext fragment sequence based on the fault tolerance mechanism to ensure that the ciphertext fragment sequence numbers in the ciphertext fragment sequence are continuous, and then continue to execute S800; otherwise, execute S800 directly. S800: Reassemble the encrypted fragment sequence into the final video stream in sequence.
[0026] In one specific embodiment, prior to S100, the method further includes: Rent a cloud server and deploy Nginx to build the necessary network transmission links.
[0027] To achieve a highly available access point across regions, cloud servers (Ubuntu system recommended) can be rented in multiple geographical regions globally (such as North China, East China, and North America). Each cloud server deploys Nginx and is configured as a reverse proxy to forward external requests to the internal monitoring source. Backend server groups can be defined on each cloud server using the upstream module to achieve load balancing and failover. TLS 1.3 encrypted transmission can be enabled on each cloud server, and a Let'sEncrypt free certificate can be configured to enhance HTTPS security. This cloud server + Nginx architecture hides the IP address of the real monitoring source, preventing direct exposure to the public internet, while leveraging the cloud service provider's BGP lines to optimize global access speed.
[0028] In one specific implementation, in step S100, an open-source monitoring system is preferably used to resolve the domain name of the target monitoring source to obtain its IP address.
[0029] For open-source monitoring systems (such as Frigate and MotionEyeOS), the IP address corresponding to the domain name of the target monitoring source can be dynamically resolved. For example, the dnspython library in Python can be used to recursively query the A record of the domain name and cache the results in Redis (with a 5-minute TTL). If resolution fails, an alarm is triggered and the system retryes with an alternative domain name; if the monitoring source changes its IP address, the cache is automatically refreshed periodically to retrieve the information. This step ensures that the system can adapt to scenarios where the monitoring source IP changes dynamically, avoiding service interruptions due to IP changes.
[0030] In one specific implementation, the preprocessing in S300 includes fragmentation, encryption, and splicing (encapsulation).
[0031] Furthermore, the preprocessing also includes PKCS7 filling.
[0032] Slicing can divide the original video stream into several independent data slices according to a preset fixed time slice (such as 1 second) or byte size (such as 1MB). Each data slice can be attached with a metadata header (including sequence number, timestamp, and total number of slices).
[0033] Encryption can be achieved by using the AES-256-CBC algorithm to encrypt the content of each data fragment, resulting in several ciphertexts corresponding to each data fragment.
[0034] Concatenation can generate random IVs (initialization vectors) for each data fragment and concatenate them with the corresponding ciphertext, thereby completing the concatenation of the corresponding random IVs and ciphertext for each group.
[0035] During preprocessing, a high-strength 256-bit (32-byte) encryption key can be used. This key should be generated using a secure random number generator or a key derivation function such as PBKDF2, avoiding hardcoding or plaintext storage. For each encryption key, whether for an independent file or a data fragment, a completely new, cryptographically secure random IV (which can be 16 bytes) is generated. After encryption, the corresponding random IV and ciphertext can be directly concatenated to form a standard output format of "random IV + ciphertext," ensuring correct separation during decryption. For data fragments, each fragment can be treated as an independent encryption unit, generating a unique random IV for each fragment and encrypting it separately. The ciphertext of all data fragments should be stored sequentially with their corresponding random IVs, preserving complete metadata (such as fragment order and total number of fragments). Finally, standard padding schemes such as PKCS#7 are used to ensure the data length meets the algorithm requirements. To achieve a higher level of security, an authentication tag based on HMAC-SHA256 (Encrypt-then-MAC mode) is attached after encryption. An authentication key separate from the encryption key is used to verify the integrity and authenticity of the ciphertext, effectively preventing tampering.
[0036] It's important to note that the key during preprocessing can be negotiated beforehand by the client and server (through RSA asymmetric encryption). Before encryption, the original video stream can be padded with PKCS7 to ensure data block alignment. Encrypted data fragments can be temporarily stored in cloud object storage (such as MinIO) for later transmission.
[0037] It is understandable that the target video stream obtained after preprocessing includes multiple combinations of random IVs and ciphertexts obtained by splicing. Each corresponding combination of random IVs and ciphertexts constitutes an encrypted data fragment, and each encrypted data fragment is transmitted independently.
[0038] Furthermore, the encrypted fragments are distributed and transmitted via cloud nodes: HTTP / 2 is prioritized to improve concurrency performance, and large files are uploaded in chunks (Multipart Upload). CDN is used to accelerate edge distribution of popular fragments, reducing back-to-origin pressure; Gzip compression is applied to fragments (optional) to reduce transmission size.
[0039] During transmission, the segment number and hash value are recorded, and the function of resuming interrupted transmission is supported. If the transmission of a segment fails, only that segment is retransmitted instead of the entire video.
[0040] In one specific implementation, in S400, the multi-level jump mechanism ensures data security during the forwarding process of data at multiple relay nodes. By encrypting the information between each relay node layer by layer, the security of data transmission is guaranteed, and the difficulty of tracing the source is increased.
[0041] Furthermore, by encrypting the information between each relay node layer by layer, it can be done as follows:
[0042] For ease of explanation, N is set to 3, meaning that a three-level communication link consisting of three relay nodes is used as an example. The following is the data encryption and decryption process of the three-level communication link: Step (1): Each data segment (raw data) of the target video stream can be encrypted using the IP address and time operator of the third-level relay node to obtain message data. Then, the information of the third-level relay node is added as a header to obtain the following first temporary data:
[0043] The original data is encrypted through a third-level relay node.
[0044] Step (2): Encrypt the first temporary data using the second-level node information and time operator, and add the second-level node information to obtain the following second temporary data:
[0045] Step (3): Encrypt the second temporary data using the first-level node information and time operator, and add the first-level relay node information to obtain the following third temporary data:
[0046] The above describes the first, second, and third temporary data displays. Each data fragment undergoes a layer-by-layer encryption process on the client program according to the link. The encrypted third temporary data is then sent to the first-level relay node via local routing. The first-level relay node then decrypts the data through the following process.
[0047] Step (4): The first-level relay node receives the third temporary data:
[0048] Step (5): The first-level relay node decrypts the third temporary data based on its own node information and dynamic key information to obtain the second temporary data. Based on the second temporary data, the information of the second-level relay node can be obtained. At this time, the second temporary data is sent to the second-level relay node:
[0049] Step (6): The second-level relay node decrypts the second temporary data based on its own node information and dynamic key information to obtain the first temporary data. Based on the first temporary data, the information of the third-level relay node can be obtained. At this time, the first temporary data is sent to the third-level relay node:
[0050] Step (7): The third-level node decrypts the first temporary data to obtain the corresponding data fragment (original data), and sends the data fragment to the requesting end (server).
[0051] Through the multi-level redirection mechanism described above, requests can be received by the entry Nginx, and the request headers can be modified (such as the User-Agent being disguised as a browser and the Referer pointing to a compliant site), and the session connection can be maintained through WebSocket or long polling.
[0052] In transmission based on a multi-level backoff mechanism, if 4xx / 5xx errors are encountered, an exponential backoff strategy can be used for retrying (up to 3 retries can be set). This multi-level backoff mechanism can effectively avoid deep packet inspection (DPI) of some network devices and stably retrieve video stream data.
[0053] Furthermore, in step S400, the target video stream is transmitted in a distributed manner through cloud server nodes.
[0054] Furthermore, the cloud server nodes preferentially use the HTTP / 2 protocol to improve concurrency performance.
[0055] Furthermore, during transmission, large files are uploaded in chunks (MultipartUpload) by the cloud server nodes. The cloud server nodes can combine with CDN to accelerate the edge distribution of popular chunks, reducing the pressure on the origin server; they can also perform Gzip compression on data chunks to reduce the data transmission volume.
[0056] During transmission, the segment number and hash value are recorded, and the function of resuming interrupted transmission is supported. If the transmission of a segment fails, only that segment is retransmitted instead of the entire video.
[0057] In one specific implementation, in step S500, the requesting end (server end) performs a ciphertext separation (data ciphertext) operation on the received target video stream, specifically including: After receiving the target video stream, the requesting end (server end) separates the data fragments of the target video stream into random IVs and data ciphertexts. It initializes the AES-CBC decryptor with a unified key, performs decryption operations on each separated data ciphertext, and removes PKCS7 padding to obtain several ciphertext fragments.
[0058] During the ciphertext separation process, the fragment sequence number and hash value should be strictly verified, and damaged or duplicate fragments should be discarded. Decrypted ciphertext fragments can be temporarily stored in a local cache, awaiting reassembly. Using a Hardware Security Module (HSM), the key is strictly confined within a security boundary, and all encryption operations are performed internally via API calls, ensuring that the key itself never leaves the secure environment or appears in application memory.
[0059] In one specific implementation, in S600, the requesting end (server end) sorts all ciphertext fragments in timestamp order to obtain a ciphertext fragment sequence, and corrects clock deviations based on the timestamps in each ciphertext fragment to ensure data continuity.
[0060] In one specific implementation, the fault tolerance mechanism in S700 includes: Prioritize retransmission of lost keyframes (IDR frames); For lost non-critical frames, forward error correction (FEC) and / or frame duplication compensation are used.
[0061] Furthermore, in S700 to S800, buffer management is preferably optimized to avoid memory overflow.
[0062] Furthermore, after S800, the method may further include: The integrity of the final video stream is verified using MD5 / SHA-256. This step further ensures the integrity of the final video stream. If packet loss is found in the final video stream, the process can return to step S700, display an error message, or directly trigger a fault-tolerance mechanism for completion.
[0063] In one specific embodiment, the method further includes: S900: Play and display the final video stream.
[0064] Furthermore, in the S900, the requesting end (server end), the front end, and the user end can use an adaptive player (such as Video.js or HLS.js) to render the video stream to support dynamic bitrate switching (Simulcast) to adapt to network fluctuations.
[0065] Furthermore, if a missing encrypted segment is detected in the final video stream, a loading animation is displayed and the video stream is re-uploaded in the background based on a fault-tolerance mechanism to complete the final video stream; audio and subtitles (if any) are synchronized during playback. For mobile devices, a native player (such as ExoPlayer for Android, AVPlayer for iOS) is integrated, and hardware decoding acceleration is enabled. The final user interface displays the video feed, status prompts, and error log entries.
[0066] Example 2: like Figure 2 As shown, in a second aspect, this disclosure provides an open-source monitoring and acquisition system for multi-link hops, the system comprising: Domain name resolution module 100 is used to resolve the domain name of the target monitoring source to obtain the IP address; Video stream module 200 is used to obtain the original video stream based on the IP address; Preprocessing module 300 is used to preprocess the original video stream to obtain the target video stream; The multi-level jump transmission module 400 is used to transmit the target video stream to the requesting end (server end) based on a multi-level jump mechanism through a cloud server node; The ciphertext separation module 500 is used by the requesting end (server end) to perform ciphertext separation (data ciphertext) operation on the received target video stream to obtain several ciphertext fragments; The fragment sorting module 600 is used by the requesting end (server end) to sort all ciphertext fragments in timestamp order to obtain a ciphertext fragment sequence, and to check whether packet loss has occurred based on the ciphertext fragment sequence (fragment sequence numbers are not continuous, indicating missing fragments). The packet loss completion module 700 is used to complete the ciphertext fragment sequence based on the triggered fault tolerance mechanism if the packet loss occurs, so as to ensure that the ciphertext fragment sequence numbers in the ciphertext fragment sequence are continuous, and then continue to execute the fragment reassembly module 800; otherwise, the fragment reassembly module 800 is executed directly. The fragment reassembly module 800 is used to reassemble the encrypted fragment sequence into a final video stream segment in sequence. The playback and display module 900 is used to play and display the final video stream segment.
[0067] The domain name resolution module 100, video stream module 200, preprocessing module 300, multi-level jump transmission module 400, ciphertext separation module 500, fragment sorting module 600, packet loss completion module 700, fragment reassembly module 800, and playback display module 900 in Example 2 correspond to S100, S200, S200, S300, S400, S500, S600, S700, S800, and S900 in Example 1, respectively.
[0068] Example 3: Embodiment 3 of this disclosure provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the open-source monitoring and acquisition method for multi-link jumps as described in Embodiment 1.
[0069] The computer-readable storage medium includes volatile or non-volatile, removable or non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, computer program modules, or other data). Computer-readable storage media include, but are not limited to, RAM (Random Access Memory), ROM (Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), flash memory or other memory technologies, CD-ROM (Compact Disc Read-Only Memory), DVD or other optical disc storage, cartridges, magnetic tapes, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer.
[0070] Example 4: Embodiment 4 of this disclosure provides an electronic device including a processor and a memory, wherein the processor is used to execute a computer program stored in the memory to implement the open-source monitoring and acquisition method for multi-link hopping described in Embodiment 1.
[0071] Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, and read-only memory (ROM).
[0072] Those skilled in the art will understand that embodiments of this disclosure can be provided as methods, systems, or computer program products. Therefore, this disclosure can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this disclosure can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0073] This disclosure is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0074] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0075] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0076] In the description of this specification, references to terms such as "an embodiment," "example," "specific example," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this disclosure. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.
[0077] In summary, the open-source monitoring and acquisition method and system for multi-link hopping provided in embodiments 1-4 of this disclosure utilizes cloud nodes to handle recomputation tasks (encryption / decryption) and edge nodes to focus on low-latency forwarding. The cloud and edge nodes together constitute a cloud-edge collaborative architecture, which makes resource allocation more efficient. This disclosure employs a modular, decoupled design, and the configuration allows for the combination or independent operation of each step (resolution → hopping → encryption → transmission → reassembly), facilitating flexible expansion and maintenance. In this disclosure, a three-layer protection system is formed through a full-link security closed-loop design, achieving DNS hiding → AES encryption → TLS 1.3 transmission. This disclosure can be equipped with a zero-trust model, enabling dynamic generation of fragmented encryption keys and avoiding the potential risks of long-term valid keys.
[0078] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this disclosure and not to limit them. Although this disclosure has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of this disclosure. Any modifications or equivalent substitutions that do not depart from the spirit and scope of this disclosure should be covered within the protection scope of the claims of this disclosure.
Claims
1. An open-source monitoring and acquisition method for multi-link hops, characterized in that, The method includes: S100: Resolve the domain name of the target monitoring source to obtain its IP address; S200: Obtain the original video stream based on the IP address; S300: The target video stream is obtained after preprocessing the original video stream; S400: The target video stream is transmitted to the requesting end via a multi-level redirection mechanism through a cloud server node; S500: The requesting end performs a ciphertext separation operation on the received target video stream to obtain several ciphertext fragments; S600: The requesting end sorts all ciphertext fragments in timestamp order to obtain a ciphertext fragment sequence, and checks whether packet loss has occurred based on the ciphertext fragment sequence; S700: If yes, complete the ciphertext fragment sequence based on the fault tolerance mechanism to ensure that the ciphertext fragment sequence numbers in the ciphertext fragment sequence are continuous, and then continue to execute S800; otherwise, execute S800 directly. S800: Reassemble the encrypted fragment sequence into the final video stream in sequence.
2. The open-source monitoring and acquisition method for multi-link hops as described in claim 1, characterized in that, Prior to S100, the method further includes: Rent a cloud server and deploy Nginx to build the necessary network transmission links.
3. The open-source monitoring and acquisition method for multi-link hops as described in claim 1, characterized in that, In step S100, an open-source monitoring system is preferably used to resolve the domain name of the target monitoring source to obtain its IP address.
4. The open-source monitoring and acquisition method for multi-link hops as described in claim 1, characterized in that, In S300, the preprocessing includes fragmentation, encryption, and splicing.
5. The open-source monitoring and acquisition method for multi-link hops as described in claim 1, characterized in that, In S400, the multi-level jump mechanism ensures data security during the forwarding process of data at multiple relay nodes. By encrypting the information between each relay node layer by layer, the security of data transmission is guaranteed, and the difficulty of tracing the source is increased.
6. The open-source monitoring and acquisition method for multi-link hops as described in claim 1, characterized in that, In step S500, the requesting end performs a ciphertext separation operation on the received target video stream, specifically including: After receiving the target video stream, the requesting end separates the data fragments of the target video stream into random IVs and ciphertexts. It initializes the AES-CBC decryptor with a unified key, performs decryption operations on each separated ciphertext, and removes PKCS7 padding to obtain several ciphertext fragments.
7. The open-source monitoring and acquisition method for multi-link hops as described in claim 1, characterized in that, In step S600, the requesting end sorts all ciphertext fragments in timestamp order to obtain a ciphertext fragment sequence, and corrects clock deviations based on the timestamps in each ciphertext fragment to ensure data continuity.
8. The open-source monitoring and acquisition method for multi-link hops as described in claim 1, characterized in that, In S700, the fault tolerance mechanism includes: Prioritize retransmission of lost keyframes; For lost non-critical frames, forward error correction and / or frame duplication compensation are used.
9. The open-source monitoring and acquisition method for multi-link hops as described in claim 1, characterized in that, The method further includes: S900: Play and display the final video stream.
10. An open-source monitoring and acquisition system for multi-link hops, characterized in that, The system includes: The domain name resolution module (100) is used to resolve the domain name of the target monitoring source to obtain the IP address; A video stream module (200) is used to obtain the original video stream based on the IP address; A preprocessing module (300) is used to preprocess the original video stream to obtain the target video stream; A multi-level jump transmission module (400) is used to transmit the target video stream to the requesting end through a cloud server node based on a multi-level jump mechanism; The ciphertext separation module (500) is used by the requesting end to perform ciphertext separation operation on the received target video stream to obtain several ciphertext fragments; The fragment sorting module (600) is used by the requesting end to sort all the ciphertext fragments in timestamp order to obtain a ciphertext fragment sequence, and to check whether packet loss has occurred based on the ciphertext fragment sequence. The packet loss completion module (700) is used to complete the ciphertext fragment sequence based on the triggered fault tolerance mechanism if the packet loss is true, so as to make the ciphertext fragment sequence number in the ciphertext fragment sequence continuous, and then continue to execute the fragment reassembly module (800); otherwise, the fragment reassembly module (800) is executed directly. The fragment reassembly module (800) is used to reassemble the encrypted fragment sequence into a final video stream segment in sequence; The playback and display module (900) is used to play and display the final video stream segment.