A browser network request processing method, system and computer readable storage medium

Abstract

The embodiment of the application discloses a kind of browser network request processing method, system and computer readable storage medium.The method comprises: in the bare hardware environment of no operating system kernel, browser engine is received by the network request initiated by webpage in running, constructs network packet and completes uplink data sending;Remote response data received is written into shared memory buffer pool, and the response data is parsed and reorganized in situ;The ownership of shared memory buffer pool carrying parsed and reorganized data is handed over to the browser tab memory area of network request initiation, to execute business callback.The network data processing of the embodiment of the application does not need operating system intervention, can substantially eliminate the performance overhead brought by memory copy, system call and privilege switching, significantly reduce the response delay of webpage network request.

Description

Technical Field

[0001] This application relates to bare-metal browsers, user-mode network communication and memory data processing technologies, and particularly to kernelless zero-copy browser network request processing methods, systems, and computer-readable storage media. Background Technology

[0002] In browser-based web page network access scenarios, web pages retrieve remote business data through network request interfaces. Current mainstream Chrome browsers rely on the operating system kernel to support network transmission. A complete network data link requires multiple memory copies, frequent system calls, and repeated switching between kernel mode and user privilege levels, resulting in significant performance overhead. The main drawbacks of this approach include excessive redundant operations in the data transmission link, continuous latency caused by memory copies and privilege switching, and an inability to achieve lightweight, high-speed network access. Summary of the Invention

[0003] This application provides a browser network request processing method, system, and computer-readable storage medium to solve one or more technical problems in existing browser network transmission, such as reliance on the operating system kernel, multiple memory copies in the data link, frequent system calls, high transmission latency due to privilege level switching, and large operating overhead.

[0004] On one hand, embodiments of this application provide a browser network request processing method, the method comprising: The browser engine receives network requests initiated by web pages, and the browser engine runs in a bare-metal hardware environment without an operating system kernel; The browser engine calls the user-mode transmission control protocol / Internet Protocol stack to construct network data packets, fills the hardware send descriptor through the network interface controller driver, and completes the uplink data transmission by the network interface controller via direct memory access. The browser engine controls the network interface controller to write remote response data into a pre-allocated shared memory buffer pool via direct memory access, and parses and reassembles the response data in-place within the shared memory buffer pool. When the response data arrives in segments in an ordered manner, the reassembly does not perform memory copying; when the response data arrives in segments out of order, the reassembly performs data shifting and copying within the shared memory buffer pool. The browser engine transfers ownership of the shared memory buffer block containing the parsed and reconstructed data to the memory area of ​​the browser tab that initiated the network request, in order to execute the business callback.

[0005] Preferably, the step of parsing and reassembling the response data in-situ within the shared memory buffer pool specifically includes: performing TCP segmentation and reassembly and Hypertext Transfer Protocol response parsing in-situ within the shared memory buffer pool; performing corresponding decryption operations according to the negotiated transport layer security encryption algorithm; if an algorithm that supports in-situ decryption is compatible, decryption is completed directly within the shared memory buffer pool; if an algorithm that cannot support in-situ decryption is not compatible, an independent plaintext storage area is allocated.

[0006] Preferably, the method further includes: After the ownership of the shared memory buffer pool is transferred, the shared buffer memory will be mapped to the dedicated software fault isolation memory area of ​​the corresponding tab. Add software fault isolation address mask (SFI) calculation to memory access instructions so that the memory address can be restricted to the memory range of the current tab page through SFI calculation.

[0007] Preferably, the method further includes: After the webpage initiates the network request and completes the uplink data transmission, the browser engine suspends the currently executing coroutine and moves it into the network waiting queue. When the network interface controller generates a hardware receive interrupt, the interrupt handler integrated into the browser engine and at the same privilege level as the web page code writes the network event into the coroutine scheduling queue. The browser engine's coroutine scheduler reads network events from the coroutine scheduling queue and wakes up the corresponding waiting coroutines to continue executing the data processing steps of the shared memory buffer.

[0008] Preferably, the method further includes: The browser engine reads the pre-configured domain permission whitelist of the webpage during the just-in-time compilation phase of the webpage script; When identifying network request calls during compilation, it is determined whether the access domain name bound to the identified network request is in the domain permission whitelist. If it is not in the domain permission whitelist, a compilation error is generated directly and the generation of the corresponding network request code is blocked. When a network request is initiated by dynamically constructing an access domain name during webpage operation, the browser engine's built-in network module determines whether the constructed complete domain name is in the domain permission whitelist. If not, the network request initiated by the dynamically constructed access domain name is discarded.

[0009] On the other hand, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the aforementioned browser network request processing method.

[0010] In another aspect, this application also provides a browser network request processing system, wherein the browser engine runs in a bare-metal hardware environment without an operating system kernel. The system includes: a request receiving module, a data construction and sending module, a data in-situ processing module, and a buffer pool ownership transfer module. The request receiving module is used to receive network requests initiated by web pages; The data construction and transmission module is used to call the user-space transmission control protocol / Internet Protocol stack to construct network data packets, fill hardware transmission descriptors through the network interface controller driver, and complete the uplink data transmission by the network interface controller via direct memory access. The in-situ data processing module is used to control the network interface controller to write remote response data into a pre-allocated shared memory buffer pool via direct memory access, and to parse and reassemble the response data in-situ within the shared memory buffer pool. When the response data arrives in segments in an ordered manner, the reassembly does not involve memory copying; when the response data arrives in segments out of order, the reassembly performs data shifting and copying within the shared memory buffer pool. The buffer pool ownership transfer module is used to transfer ownership of the shared memory buffer block carrying the parsed and reassembled data to the browser tab memory area that initiated the network request, so as to execute the business callback.

[0011] This application's embodiments rely on a kernelless bare-metal browser architecture to construct a complete user-space network link. Network data processing does not require operating system intervention, significantly eliminating the performance overhead caused by memory copying, system calls, and privilege switching, and significantly reducing the response latency of webpage network requests. In addition, a software fault isolation mechanism ensures the secure isolation of network data across tabs. Attached Figure Description

[0012] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a flowchart of a browser network request processing method according to an embodiment of this application; Figure 2 This is a flowchart of the network data isolation optimization method in the embodiments of this application; Figure 3 This is a flowchart of the coroutine interruption scheduling optimization method according to an embodiment of this application; Figure 4 This is a flowchart of the network permission verification optimization method according to an embodiment of this application; Figure 5 This is a block diagram of the browser network request processing system according to an embodiment of this application. Detailed Implementation

[0013] The technical solution of this application will be clearly and completely described below with reference to the concepts in the embodiments of this application. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0014] As mentioned earlier, the existing Chrome browser's network processing architecture relies on the operating system kernel to complete the entire network transmission process. When a webpage calls a network request interface, it needs to go through multiple layers of relay, including the browser process, the operating system socket API, the kernel transmission control protocol stack (TCP / IP stack), and the kernel's dedicated data buffer. Each time data passes through a relay layer, a memory copy operation needs to be performed, and a single complete webpage request performs at least four memory copies. Meanwhile, each read / write operation and network data wait requires a system call (syscall), each lasting over 100 nanoseconds. Furthermore, system calls trigger a privilege level switch between user mode (the lowest privilege level at the CPU ring level, Ring 3, which cannot directly manipulate hardware, modify page tables, manage memory, or send / receive network card data) and kernel mode (the highest privilege level at the CPU ring level, Ring 0, which can directly access all hardware, physical memory, interrupt controllers, network cards, disks, and other low-level resources). This switch refreshes the Translation Lookaside Buffer (TLB, a high-speed hardware buffer built into the CPU specifically for storing virtual address-to-physical address mappings), adding additional computational overhead. Moreover, after a network hardware interrupt occurs, the operating system kernel needs to intervene and distribute the interrupt event. This complex hierarchical structure and the accumulation of redundant operations result in high network request latency. To address these issues, existing user-space network solutions are incompatible with browser operating environments. For example, user-space protocol stacks such as DPDK and mTCP (running on DPDK) still rely on the Linux kernel (VFIO-PCI binding, IOMMU management) for hardware binding and resource management, lacking browser integration. Similarly, dedicated operating systems like Arrakis and IX lack Just-In-Time (JIT) compilation and software isolation capabilities for web page scripts, making it impossible to directly integrate browser tab execution logic. Therefore, there is no zero-copy network transmission solution that is browser-oriented and completely independent of the kernel and virtualization management program. Based on these shortcomings, this application proposes a kernel-free, zero-copy browser network request processing solution. A detailed description follows with accompanying drawings.

[0015] See Figure 1The figure illustrates a summary flow of a browser network request processing method according to an embodiment of this application. This process runs in a bare-metal hardware environment without an operating system kernel, and the specific steps include: Step S11: The browser engine receives a network request initiated by the web page script. The browser engine runs in a bare-metal hardware environment without an operating system kernel. In this embodiment, the browser engine operates in a bare-metal state, without the kernels of general-purpose operating systems such as Linux and Windows, and does not rely on kernel network interfaces such as sockets and I / O polling. The webpage initiates a remote data retrieval command through a standard network request interface (e.g., the browser's standard JavaScript network request API, also translated as the network resource retrieval interface / network data request interface, which is used by the webpage's JS code to send HTTP / HTTPS requests to a remote server to obtain network resources such as interface data, images, audio, video, and files). The upper-layer module of the engine captures this request and distributes it downwards to the user-space network protocol module. This step can output the identifier of the network request to be processed and the domain name of the requested access, as input for subsequent data packet construction.

[0016] Step S12: Invoke the built-in user-space transmission control protocol / Internet Protocol stack to construct a network data frame, fill the hardware send descriptor through the network interface controller driver, and complete the uplink data transmission by the network interface controller via direct memory access; The user-space TCP / IP (Transmission Control Protocol / Internet Protocol) stack in this step can be entirely implemented using the browser's scripting language, without calling any kernel network interfaces. The user-space TCP / IP stack concatenates the Ethernet header, IP header, TCP header, and service payload, writing the complete network frame into the browser's transmit memory buffer, and then hands it over to the network interface controller driver for data transmission. Specifically, during uplink data transmission, the NIC (Network Interface Controller) driver can first allocate a blank hardware transmit descriptor in memory and then fill that descriptor. The hardware transmit descriptor (TX descriptor) is an instruction / metadata structure between the network interface controller (NIC) DMA hardware and the browser's bare-metal driver. It informs the NIC about the memory location of the data to be transmitted, the data length, and transmission control rules. Each transmit descriptor typically contains four key pieces of information: the physical address of the transmit buffer (the memory address of the packet data to be transmitted in the browser's memory), the packet length (the total number of bytes in the Ethernet / TCP data packet), hardware control flags (whether to automatically generate a CRC checksum, whether to trigger an interrupt upon completion of transmission, multi-segmentation flags, etc.), and status bits (marking whether the descriptor belongs to the CPU or the NIC DMA hardware). After the hardware transmit descriptor is written, a hardware register doorbell instruction triggers the NIC to directly read the data from the memory transmit buffer and transmit it externally. This step outputs the network frame to be transmitted and the hardware descriptor information, providing a basis for hardware transmission.

[0017] Step S13: The browser engine controls the network interface controller to write the remote response data to the pre-allocated shared memory buffer via Direct Memory Access (DMA). The global shared memory buffer pool is a global public memory pool of the browser engine. It is a software fault isolation (SFI) isolated memory area not belonging to any specific browser tab. A separate global trusted memory block is allocated as the carrier for network interface card (NIC) DMA-received data packets. All network packets received by the network interface controller are written to this shared memory buffer pool via DMA. This shared memory buffer pool can be pre-allocated from hugepage memory, without kernel intervention in memory mapping operations. This step outputs a shared buffer object storing the response data, which serves as the processing carrier for subsequent protocol parsing.

[0018] Step S14: Parse and reassemble the response data in-place within the shared memory buffer. When the response data arrives in ordered segments, the reassembly does not involve memory copying. When the response data arrives out of order, the reassembly performs data shifting and copying within the shared memory buffer. In this step, parsing the response data may include various operations as needed, such as TCP segmentation and reassembly, and Hypertext Transfer Protocol (HTTP) response parsing. Within the shared memory buffer pool, received data may fall into two categories: sequentially arriving data and out-of-order data. If network segment data arrives sequentially, only the data offset markers within the buffer are adjusted, changing the offset length; no memory copy is required. If network segment data arrives out of order, the out-of-order segments must be copied to the correct offset position within the buffer (the source and destination positions are both within the same pre-allocated large page RX buffer memory), while the remaining data remains in place. Furthermore, the received response data may be encrypted; in this case, the parsing process will also include file decryption. The decryption operation selects the corresponding decryption method based on the encryption algorithm. Specifically, it can perform the corresponding decryption operation based on the negotiated Transport Layer Security (TLS) encryption algorithm. When the negotiated encryption algorithm is an advanced encryption standard that supports in-place decryption (such as Galois / counter mode series algorithms), the plaintext is generated by directly overwriting the ciphertext in the shared buffer. When the encryption algorithm does not support in-place decryption, a new independent plaintext buffer is created to store the decrypted data. This step outputs the buffer that stores the plaintext data.

[0019] Step S15: Transfer ownership of the shared buffer block carrying the parsed data to the memory area of ​​the browser tab that initiated the network request in order to execute the business callback; This step transfers ownership of the shared memory buffer pool. That is, after buffered data processing is complete, memory usage rights are transferred from the global engine area to the dedicated SFI memory domain of the target tab that initiated the request. Ownership transfer requires certain triggering conditions to be met. In this embodiment, the buffer pool ownership transfer operation can be set to be performed when network data processing is complete (including but not limited to when TCP reassembly, TLS decryption, and HTTP parsing are all completed), and the valid business data of the network packets no longer needs to be processed by the underlying engine modules. Before the ownership transfer is executed, the buffer pool's read and write permissions are fully open to the engine's underlying user-space TCP / IP protocol stack, TLS decryption module, and HTTP parsing module, meaning it is both readable and writable: readable means the protocol stack can read the original network packets in the buffer pool to complete TCP fragmentation and reassembly, TLS decryption, and HTTP packet parsing (as described in the previous steps); writable means the protocol stack can modify the data in the buffer in-situ, such as AES-GCM overwriting ciphertext to generate plaintext and adjusting packet offset markers to achieve zero-copy processing. After ownership transfer is completed, the buffer pool memory is incorporated into the unified management of the corresponding tag software fault isolation SFI security domain. This step outputs an array buffer pointer that can be read by the web page script for use by the web page callback function.

[0020] This embodiment of the application does not initiate any operating system system calls throughout the entire process, eliminating the operating system kernel's involvement in the network link. It eliminates redundant steps such as socket system calls, kernel protocol stack relay, and multi-layer memory copying. The optimal data transmission link does not perform any memory copying, and the suboptimal link only requires a single copy, far less than the overhead of four or more copies required by existing browsers. Under normal ordered network traffic, zero-memory copying can be achieved; in out-of-order or special encryption scenarios, only a single copy is needed, significantly reducing network request processing latency. Furthermore, this embodiment maintains a single privilege level throughout the process, without switching between user mode and kernel mode privilege levels, effectively avoiding the computational power loss caused by frequent address translation buffer refreshes. Simultaneously, it relies on the tab-independent software fault isolation SFI memory domain to achieve network data isolation, balancing high performance and memory access security.

[0021] Among the aforementioned technical effects, one noteworthy term is "zero copy". In the embodiments of this application, "zero copy" does not mean absolutely 100% no copy in all scenarios, but rather a graded indicator based on traffic scenarios: (1) For the mainstream fast path (accounting for more than 90% of network traffic), there are truly 0 memcpy operations throughout the entire process, with no copy at all; (2) For a few slow paths (out-of-order TCP fragmentation, not supporting in-place decryption algorithms), there is at most 1 internal buffer copy, and it only occurs within the engine's global receive buffer pool, which can achieve "three no-crossing", namely, no crossing the kernel, no crossing the user-space process, and no crossing the tag memory.

[0022] The foregoing embodiments are basic embodiments of this application. In fact, various optimizations can be made on this basis to achieve better technical results. Several optimization directions are exemplified below to help those skilled in the art understand the core content and boundaries of this application.

[0023] One exemplary direction: Optimization of network data isolation While the aforementioned embodiments can complete the transfer of buffer ownership, they lack a clear mechanism for isolating network data between multiple tabs, posing a potential risk of other tabs illegally accessing the shared buffer. Therefore, this application's embodiments can add SFI collaborative isolation optimization to the aforementioned solution. See also... Figure 2 The diagram illustrates the process of optimizing network data isolation (to more fully demonstrate the technical solution, the previous step in the optimization process is marked with a dashed line), and the specific steps include: Step S21: After the ownership of the shared memory buffer pool is transferred, map the shared buffer memory to the corresponding tab's dedicated software fault isolation (SFI) memory area; After the ownership transfer of the shared memory buffer pool is complete, the browser engine's memory manager modifies the virtual address mapping of the buffer pool, incorporating this buffer pool memory into the Software Fault Isolation (SFI) memory domain of the single tab that initiated the network request, and synchronously updates the buffer reference count. From then on, the global engine's shared area loses read and write access to the buffer pool, and the buffer pool fully belongs to the garbage-collected heap memory space of the target tab. Data references are passed only through pointer offsets, without performing memory copying, achieving zero-copy data transfer. For example, if an image packet is currently being processed, and there is no further need for underlying protocol processing after its decryption, the browser engine modifies the buffer pool's virtual address mapping, placing the buffer pool into the SFI memory domain of the tab requesting the image. JavaScript code can directly reference this buffer pointer through `response.arrayBuffer()`, without needing to copy the image's binary data.

[0024] Step S22: Add Software Fault Isolation (SFI) address mask operation to the memory access instruction so as to restrict the memory address to the current tab page memory range through the Software Fault Isolation (SFI) address mask operation; In this embodiment, each tab can have an independent 4GB aligned memory base address. When JIT compiling the memory read / write instructions of the JS / Wasm network, a bitwise AND mask operation can be forcibly inserted. Valid access address = raw pointer & 0xFFFFFFFF + current tag base address This masking operation locks the addressing range within the Software Fault Isolation File (SFI) memory domain of the current tab, forcibly confining any illegal addresses to the current tab's 4GB range. This prevents access to shared memory buffers already assigned to other tabs, thus blocking other tabs from accessing the transferred shared memory buffers. It's important to note that if the masking operation points to the first or last sentinel page of the current tab, the hardware will directly trigger a memory anomaly, and the browser engine will immediately terminate the malicious tab's operation, providing double protection against cross-page data theft from network buffers. Furthermore, this method allows the entire 4GB of SFI memory to be released at once via munmap when the tab is closed, with buffered memory being reclaimed simultaneously, eliminating the need for separate release of the network buffer.

[0025] This optimized embodiment achieves network data isolation on two logical levels: First, after the buffer ownership is transferred, physical memory is only mapped to the virtual address space of the target tag, and there is no mapping entry for this buffer in the virtual address tables of other tags; second, even if a malicious webpage's JavaScript constructs an excessively large memory pointer to attempt to read the network buffer across tags, after SFI AND mask operations, the final access address will only fall within its own 4GB SFI area, and it will never be able to address the buffer pool memory already taken over by other tags. This embodiment naturally isolates the network buffers of each tab by relying on the transfer of buffer ownership and the hardware constraints of SFI mask, without the need for additional permission verification logic, and without cross-tag original memory pointers. It achieves mutual isolation of network data between multiple webpages with extremely low performance overhead, avoiding cross-page memory leaks and Spectre side-channel read vulnerabilities in Chrome's multi-process / ordinary SFI solutions.

[0026] Second exemplary optimization direction: Coroutine interrupt scheduling optimization The aforementioned basic embodiment does not define a network interruption handling mechanism, and existing technologies mostly employ a thread blocking mode. Taking Chrome and other conventional browsers with an operating system kernel as examples, when asynchronous network requests occur, an operating system thread plus kernel I / O multiplexing scheme is used. That is, after a web page initiates a network request, an independent worker thread is created. The thread calls the kernel interface and blocks while waiting for data from the network interface controller. During the blocking period, the thread continuously occupies operating system thread resources and thread stack memory, and the waiting / waking of the thread is entirely scheduled by the operating system kernel. This approach requires each request waiting for a network response to exclusively occupy a complete operating system thread and allocate an independent thread stack. When there are batches of concurrent network requests, the number of threads increases dramatically, and memory and CPU scheduling overhead increases significantly. At the same time, it must frequently interact with the kernel, resulting in severe performance degradation. In the aforementioned solution, only the data processing link of network card DMA transmission and reception and buffer ownership transfer is described, without defining how to resume the blocked web page request after a network card interruption, lacking asynchronous scheduling logic. Therefore, it is necessary to design a coroutine-driven interrupt scheduling process. See Figure 3The figure illustrates a schematic diagram of the coroutine interruption scheduling optimization process according to an embodiment of this application (to more completely demonstrate the technical solution, the previous step of the optimization process is marked with a dashed line in the figure), and the specific steps include: Step S31: After the webpage initiates the network request and completes the uplink data transmission, the browser engine suspends the currently executing coroutine and moves it into the network waiting queue; The "coroutine" in this step is different from the operating system kernel thread. A coroutine is a lightweight execution unit within the bare-metal browser. Coroutine stacks are small, and switching can be completed within a single privileged browser engine without operating system intervention. The "network wait queue" in this step is a browser engine-built memory queue used to store coroutine objects that have initiated requests and are waiting for the network interface controller to receive data. This step is the cleanup action after a network request is initiated, laying the groundwork for subsequent network interface controller interruption-triggered wake-up. When the webpage's JS code executes `fetch` to initiate a network request, the engine allocates a dedicated coroutine to execute the request logic. After completing TCP packet sending and submitting the send descriptor to the NIC, the current coroutine has no further executable logic and actively performs a coroutine suspension operation. The engine completely saves the coroutine's execution context (local variables, program pointer, buffer references), moves it to the network wait queue, yields CPU computing power, and schedules other ready coroutines to run. Unlike thread suspension, which requires kernel intervention and occupies MB-level stack space, coroutine suspension in this step is completed only within the engine. The stack expands dynamically as needed, and memory usage is only KB-level, resulting in extremely low resource consumption under massive concurrent requests.

[0027] Step S32: When the network interface controller hardware generates a receive interrupt, the interrupt handler integrated into the browser engine and at the same privilege level as the web page code writes the network event into the coroutine scheduling queue. In this step, after the Network Interface Controller (NIC) writes the remote response data to the global shared memory buffer pool via DMA, the hardware actively initiates a hardware interrupt signal. The CPU jumps to the browser's built-in interrupt handler, marks the shared buffer block, generates a network ready event, and writes the event to the engine's internal coroutine scheduling queue. The interrupt handler only transmits the "network data has arrived" event flag and does not perform business data processing, deferring complex calculations (heavy calculations such as TCP parsing and TLS decryption) to the coroutine, avoiding long CPU usage due to interrupts. The process takes only a few hundred nanoseconds. Chrome interrupts are handled by the kernel, which requires at least one system call and one privilege switch per interrupt. In comparison, this solution has no syscalls or Ring switches, eliminating TLB failures and context saving overhead.

[0028] Step S33: The browser engine's coroutine scheduler reads the network events in the coroutine scheduling queue and wakes up the corresponding waiting coroutines to continue executing the data processing steps of the shared memory buffer.

[0029] In this embodiment, the coroutine scheduler is a core module built into the browser engine. It continuously polls the coroutine scheduling queue, without relying on operating system kernel I / O multiplexing interfaces such as epoll and io_uring. All waiting and waking logic is handled by the browser's internal coroutine scheduler, reducing kernel interaction overhead and significantly lowering the resource consumption of asynchronous network requests. Specifically, when the scheduler detects a network ready event in the scheduling queue, it finds the corresponding suspended coroutine in the network waiting queue based on the buffer ID and coroutine identifier recorded in the event record, restores the execution context (stack, pointers, buffer references) saved by the coroutine, and marks the coroutine as ready. The CPU switches to the coroutine and continues to execute subsequent zero-copy data processing logic such as TCP fragmentation reassembly, TLS decryption, and buffer ownership transfer. After the coroutine is woken up, it directly performs DMA writing to the global buffer pool in the aforementioned steps, connecting the in-situ data processing and ownership transfer steps in the aforementioned technical solution. The entire process is interconnected and seamless.

[0030] Example Optimization Direction 3: Optimization of Network Permission Verification Generally, web pages dynamically construct the domain name based on business logic: the fixed domain name, parameters, and path are stored separately in the JS code, and the strings are concatenated at runtime to generate the complete request address, as shown in the pseudocode example: const base = "https: / / api."; const suffix = "test.com"; fetch(base +suffix + " / data"); Traditional browsers perform single-stage domain name verification only at runtime for these concatenated domain names. This can block fixed illegal domain names hard-coded in the code, but it cannot predict dynamically concatenated domain names during the compilation phase. This allows malicious scripts to bypass runtime single-stage verification through string segmentation, encrypted concatenation, and array concatenation, accessing unauthorized third-party interfaces and posing risks of data leakage and cross-site scripting attacks. Furthermore, compilation-stage verification alone cannot handle dynamically generated concatenated addresses at runtime, allowing dynamic domain names to completely bypass detection. This optimized implementation abandons this single-layer verification mode and instead adopts a two-layer permission verification logic of compiler verification and runtime dynamic filtering. It dual-controls domain name access at both the code compilation and network initiation stages, completely blocking permission bypass vulnerabilities caused by dynamically concatenated domain names. See also Figure 4 The diagram illustrates the optimized network permission verification process, including the following steps: Step S41: The browser engine reads the domain permission whitelist pre-configured by the webpage during the Just-In-Time (JIT) compilation stage of the webpage script; The "just-in-time compilation" step indicates that the browser engine can compile the JavaScript script into native machine code in real time. The pre-configured domain permission whitelist in this step refers to the list of allowed domains declared in the webpage's manifest configuration file. It contains fully trusted domains, and only domains on the list are allowed to initiate network requests to the webpage. This list can be configured by the website developer. In this step, after the webpage loads, the engine prioritizes parsing the webpage permission list and caches the authorized domains in the global permission table. When the JIT compiler starts the compilation script, it first loads the cached list of authorized domains, providing a data source for static domain comparison during the compilation phase and avoiding performance loss caused by repeatedly reading the configuration file during the compilation process.

[0031] Step S42: When identifying network request calls during the compilation process, determine whether the access domain name bound to the identified network request is in the domain name permission whitelist. If not, execute step S421: directly generate a compilation error and block the generation of the corresponding network request code. In this step, the JIT compiler can accurately identify all fetch network request calls by parsing the script syntax tree, and then distinguish between two different types of domains. If it is a fully hard-coded domain name, such as fetch("https: / / safe.com"), the compiler extracts it and matches it against the aforementioned permission list. If the domain name exists in the authorization list, the compilation proceeds normally, generating executable machine code; if it does not exist in the authorization list, the compilation is interrupted, a compilation error is thrown, and the corresponding fetch call cannot generate executable code, causing the network request to fail directly at webpage runtime. Thus, illegal fixed domain names (malicious third-party domain names) are intercepted directly before code execution, blocking illegal network calls without any attack window, saving network resources and forming the first layer of static security barrier; while traditional browsers only intercept at runtime, and illegal requests still reach the network processing flow.

[0032] Step S43: When a network request is initiated by dynamically constructing an access domain name during webpage operation, the browser engine's built-in network module determines whether the constructed complete domain name is in the domain name permission whitelist. If not, step S431 is executed: the network request initiated by the dynamically constructed access domain name is discarded.

[0033] Since JIT compilation can only parse fixed string domain names in the code and cannot predict dynamically generated domain names at runtime (e.g., string concatenation, variable concatenation, decryption-generated domain names, etc.), this step adds a second runtime verification. After the webpage reaches the fetch execution logic and the complete target domain name is concatenated, the request is sent to the network module, which extracts the concatenated complete domain name and compares it again with the aforementioned permission whitelist. If the comparison matches an authorized domain name, the zero-copy network data link is entered normally; if no authorized domain name is matched, the network request is discarded directly, no TCP handshake is initiated, no shared buffer is allocated, and the request fails. The verification logic in this step runs within the tab-specific SFI security department, only verifying the permission list of the current webpage. Permissions for different tabs are isolated from each other, and the filtering action occurs before the DMA writes to the RX buffer, so invalid requests will not occupy global shared memory buffer pool resources. This forms a second layer of dynamic security barrier.

[0034] This application's embodiments can implement dual-layer domain name permission interception at both the compilation and runtime stages. During the compilation stage, it intercepts illegal domain names statically hard-coded within the code. Static illegal domain names never enter the network transmission process, eliminating the need for RX buffer allocation and TCP connection establishment, thus saving network card, memory, and computing power resources. At runtime, it intercepts illegal domain names dynamically generated during program execution, preventing dynamic domain names from completely bypassing detection. This layered interception scheme effectively improves webpage network access security control capabilities without increasing request latency. Furthermore, whether intercepting illegal domain names at the compilation or runtime stages, the entire domain name verification logic runs within a single privilege level of the browser, without invoking operating system permission-related system calls, thus avoiding performance losses such as user-mode / kernel-mode privilege switching and TLB failure.

[0035] The foregoing description details the method embodiments provided in this application. In fact, this application also provides corresponding system embodiments. See [link to relevant documentation]. Figure 5 This diagram illustrates a structural block diagram of an embodiment of a browser network request processing system. The browser network request processing system U50 of this application embodiment involves a browser engine running in a bare-metal hardware environment without an operating system kernel. Specifically, it comprises: a request receiving module U51, a data construction and sending module U52, a data in-situ processing module U53, and a buffer pool ownership transfer module U54, wherein: The request receiving module U51 is used to receive network requests initiated by web pages. The data construction and transmission module U52 is used to call the user-space transmission control protocol / Internet protocol stack to construct network data packets, fill the hardware transmission descriptor through the network interface controller driver, and complete the uplink data transmission by the network interface controller via direct memory access. The in-place data processing module U53 is used to control the network interface controller to write remote response data into a pre-allocated shared memory buffer pool via direct memory access, and to parse and reassemble the response data in-place within the shared memory buffer pool. When the response data arrives in ordered segments, the reassembly does not involve memory copying; when the response data arrives out of order, the reassembly performs data shifting and copying within the shared memory buffer pool. The buffer pool ownership transfer module U54 is used to transfer ownership of the shared memory buffer pool that carries the parsed and reassembled data to the browser tab memory area that initiated the network request, in order to execute the business callback.

[0036] Based on the same principle, the aforementioned system embodiment can also be optimized, with further modules included in the system. For example, the system may further include: a network data isolation module U55, a coroutine interrupt scheduling module U56, and a network permission verification module U57. The network data isolation module U55 is used to map the shared memory buffer to the corresponding tab's dedicated software fault isolation memory area after the ownership transfer of the shared memory buffer pool is completed; it adds software fault isolation address mask calculations to memory access instructions to restrict the memory address to the current tab's memory range through software fault isolation SFI address mask calculations; the coroutine interrupt scheduling module U56 is used to suspend the currently executing coroutine and move it into the network waiting queue after the webpage initiates the network request and completes uplink data transmission; when the network interface controller generates a hardware receive interrupt, the system integrated into the browser engine and at the same privilege level as the webpage code... The interrupt handler writes network events to the coroutine scheduling queue; reads the network events in the coroutine scheduling queue and wakes up the corresponding waiting coroutines to continue executing the data processing steps of the shared memory buffer; the network permission verification module U57 is used to read the domain name permission whitelist pre-configured by the webpage during the just-in-time compilation stage of the webpage script; when identifying network request calls during the compilation process, it determines whether the access domain name bound to the identified network request is in the domain name permission whitelist. If not, it directly generates a compilation error and blocks the generation of the corresponding network request code; when dynamically concatenating the access domain name to initiate a network request during webpage operation, the browser engine's built-in network module determines whether the concatenated complete domain name is in the domain name permission whitelist. If not, it discards the network request initiated by the dynamically concatenated access domain name.

[0037] Both the aforementioned system embodiments and the further optimized technical functional modules can achieve the same technical effects as the aforementioned method embodiments. To avoid repetition, they will not be elaborated here.

[0038] Furthermore, the technical solution of this application can be formed on a computer-readable storage medium to form a computer program. The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

[0039] The embodiments of this application can achieve all the inventive objectives using the aforementioned software; therefore, the software portion has been primarily described. Those skilled in the art should understand that the embodiments of this application can be provided as an apparatus, system, or related computer program product. Therefore, this application can be implemented in some cases as a completely hardware embodiment, or as a completely software embodiment, or as an embodiment combining software and hardware aspects. Furthermore, this application 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.

[0040] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. 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, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0041] 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.

[0042] 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.

[0043] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0044] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0045] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0046] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0047] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A browser network request processing method, characterized in that, The method includes: The browser engine receives network requests initiated by web pages, and the browser engine runs in a bare-metal hardware environment without an operating system kernel; The browser engine calls the user-mode transmission control protocol / Internet Protocol stack to construct network data packets, fills the hardware send descriptor through the network interface controller driver, and completes the uplink data transmission by the network interface controller via direct memory access. The browser engine controls the network interface controller to write remote response data into a pre-allocated shared memory buffer pool via direct memory access, and parses and reassembles the response data in-place within the shared memory buffer pool. When the response data arrives in segments in an ordered manner, the reassembly does not perform memory copying; when the response data arrives in segments out of order, the reassembly performs data shifting and copying within the shared memory buffer pool. The browser engine transfers ownership of the shared memory buffer block containing the parsed and reconstructed data to the memory area of ​​the browser tab that initiated the network request, in order to execute the business callback.

2. The method according to claim 1, characterized in that, The step of parsing and reassembling the response data in-situ within the shared memory buffer specifically includes: TCP segmentation and reassembly and Hypertext Transfer Protocol response parsing are performed in-place within the shared memory buffer pool. The corresponding decryption operation is performed according to the negotiated transport layer security encryption algorithm. If the algorithm supports in-place decryption, the decryption is completed directly within the shared memory buffer pool. If the algorithm does not support in-place decryption, an independent plaintext storage area is allocated.

3. The method according to claim 1, characterized in that, The method further includes: After the ownership transfer of the shared memory buffer pool is completed, the shared memory buffer pool memory will be mapped to the corresponding tab's dedicated software fault isolation memory area; Add software fault isolation address mask operations to memory access instructions so that memory addresses can be restricted to the memory range of the current tab page through software fault isolation address mask operations.

4. The method according to claim 1, characterized in that, The method further includes: After the webpage initiates the network request and completes the uplink data transmission, the browser engine suspends the currently executing coroutine and moves it into the network waiting queue. When the network interface controller generates a hardware receive interrupt, the interrupt handler integrated into the browser engine and at the same privilege level as the web page code writes the network event into the coroutine scheduling queue. The browser engine's coroutine scheduler reads network events from the coroutine scheduling queue and wakes up the corresponding waiting coroutines to continue executing the data processing steps of the shared memory buffer pool.

5. The method according to claim 1, characterized in that, The method further includes: The browser engine reads the pre-configured domain permission whitelist of the webpage during the just-in-time compilation phase of the webpage script; When identifying network request calls during compilation, it is determined whether the access domain name bound to the identified network request is in the domain permission whitelist. If it is not in the domain permission whitelist, a compilation error is generated directly and the generation of the corresponding network request code is blocked. When a network request is initiated by dynamically constructing an access domain name during webpage operation, the browser engine's built-in network module determines whether the constructed complete domain name is in the domain permission whitelist. If not, the network request initiated by the dynamically constructed access domain name is discarded.

6. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method as described in any one of claims 1 to 5.

7. A browser network request processing system, characterized in that, The browser's engine runs in a bare-metal hardware environment without an operating system kernel. This system includes: a request receiving module, a data construction and sending module, a data in-situ processing module, and a buffer pool ownership transfer module, wherein: The request receiving module is used to receive network requests initiated by web pages; The data construction and transmission module is used to call the user-space transmission control protocol / Internet Protocol stack to construct network data packets, fill hardware transmission descriptors through the network interface controller driver, and complete the uplink data transmission by the network interface controller via direct memory access. The in-situ data processing module is used to control the network interface controller to write remote response data into a pre-allocated shared memory buffer pool via direct memory access, and to parse and reassemble the response data in-situ within the shared memory buffer pool. When the response data arrives in segments in an ordered manner, the reassembly does not involve memory copying; when the response data arrives in segments out of order, the reassembly performs data shifting and copying within the shared memory buffer pool. The buffer pool ownership transfer module is used to transfer ownership of the shared memory buffer block carrying the parsed and reassembled data to the browser tab memory area that initiated the network request, so as to execute the business callback.

Images