File fragment breakpoint resuming method and system based on front-end self-adaptive network condition

Abstract

The invention provides a file fragment breakpoint resume method and system based on a front-end adaptive network condition. A front end measures RTT, estimates bandwidth, identifies a network type and generates a network quality score through a detection request; dynamically determining the fragment size and the concurrent number according to the score, slicing the file, and generating a fragment index and the total fragment number. And executing full hash on the small file, and generating a file identifier on the large file by adopting sampling hash of a head section, a tail section and a random middle section. Persistently storing the file identifier, the network score and the uploaded fragment index; before uploading, an uploaded fragment list is pre-checked to the rear end, and missing fragments are calculated and only missing parts are uploaded. During uploading, network changes are monitored in a timing and event mode, parameters are dynamically adjusted, failure fragments retry according to exponential back-off, degradation is triggered, automatic pause is conducted when the network deteriorates, and recovery is conducted after stabilization. And after all fragmentation is completed, rear-end merging is triggered, and hash consistency is verified, so that the large file uploading efficiency and reliability in a weak network scene are improved.

Description

Technical Field

[0001] This invention belongs to the field of computer network and web front-end development technology, and in particular relates to a method and system for resuming file segmented transmission based on front-end adaptive network conditions. Background Technology

[0002] With the increasing demand for uploading large files such as videos, model files, and log packages in web applications, traditional one-time uploads or fixed-chunk uploads are prone to interruptions, timeouts, and duplicate uploads in complex network environments. On the one hand, network fluctuations or transmission failures often require restarting the upload process, significantly reducing efficiency and impacting user experience in weak network environments.

[0003] On the other hand, while the fixed chunking strategy can reduce the impact of a single failure, it lacks dynamic adaptation to changes in network conditions: under weak network conditions such as bandwidth below 1Mbps, chunks that are too small will lead to a significant increase in the number of HTTP requests, thereby exacerbating network interaction overhead and further slowing down transmission.

[0004] In addition, when the packet loss rate is high in a mobile network environment, the probability of a single transmission failure increases; at the same time, browser memory and main thread resources are limited, which may cause page response delays and stuttering when uploading very large files, resulting in an unstable upload process.

[0005] Therefore, a technical solution is needed that can assess network quality in real time at the front end and adaptively adjust the fragment size, concurrency, retry and pause recovery strategies accordingly, while supporting breakpoint resume and merge verification, in order to improve the efficiency and reliability of large file uploads. Summary of the Invention

[0006] In view of this, the present invention aims to propose a file fragmentation breakpoint resumption method and system based on front-end adaptive network conditions, so as to at least solve one of the problems in the background art.

[0007] To achieve the above objectives, the technical solution of the present invention is implemented as follows: A file fragment resuming method based on front-end adaptive network conditions includes: S1. Obtain the file to be uploaded on the front end, and get the file size and type, and generate file identification information; S2. Send a probe request to the server to measure the round-trip time (RTT), estimate the bandwidth and obtain the network type, and calculate the network quality score (qualityScore) based on the preset scoring function. S3. Determine the chunk size and concurrency based on the qualityScore. Higher quality results in larger chunks and higher concurrency, while lower quality results in smaller chunks and lower concurrency. S4. Perform hash calculation on the file: calculate the full hash when the file size is less than a preset threshold; otherwise, calculate the file hash fileHash by sampling the first segment, the last segment, and a random middle segment. S5. Slice the file into chunks by chunkSize to generate a chunk set. Generate a chunk index chunkIndex and a total number of chunks totalChunks for each chunk. Write fileHash, qualityScore and the uploaded chunk index set to local storage to persist the upload progress. S6. Before uploading, send a fragment pre-check request to the backend and carry fileHash. Receive the list of uploaded fragments returned by the backend, compare it with the local record to obtain the missingChunks index set of fragments to be uploaded, and only perform the upload on the fragments corresponding to missingChunks. S7. Upload chunks concurrently according to concurrency. During the upload process, periodically evaluate the qualityScore and dynamically adjust chunkSize and concurrency based on its changes. When network degradation is detected and the preset pause conditions are met, the upload is paused. When the network recovers and the preset recovery conditions are met, the upload continues. S8. When a chunk upload fails, an exponential backoff retry is executed. If the number of retries exceeds the threshold, a degradation strategy is triggered to reduce the chunk size and reduce concurrency. After all chunks are uploaded, a merge request is sent to the backend. The backend merges the chunks by totalChunks and verifies hash consistency. If successful, the progress information in the local storage is cleared and the upload result is output.

[0008] Furthermore, the scoring function in step S2 satisfies a normalized output of 0 to 1 and includes bandwidth weight, RTT weight and network type weight, wherein the network type includes at least one of Wi-Fi, 5G, 4G and 3G.

[0009] Furthermore, the bandwidth estimation in step S2 is achieved by at least one of the following methods: obtaining the estimated downlink bandwidth by reading the browser's network information interface; or sending a fixed amount of test data to the server and calculating the bandwidth based on the transmission time.

[0010] Furthermore, in step S3, when the qualityScore is greater than the first threshold, the chunkSize is set to 5MB to 10MB and the concurrency is set to 3 to 5; when the qualityScore is between the first threshold and the second threshold, the chunkSize is set to 2MB to 5MB and the concurrency is set to 2 to 3; when the qualityScore is less than the second threshold, the chunkSize is set to 1MB and the concurrency is set to 1.

[0011] Furthermore, the sampling hash in step S4 includes: extracting a first length of data from the beginning of the file, extracting a second length of data from the end of the file, and randomly extracting at least one segment of data from the middle of the file, concatenating the extracted data, and then calculating the hash to reduce the computation time.

[0012] Furthermore, in step S5, the local storage is either localStorage or IndexedDB; the uploaded sharded index set is stored in the form of an array or bitmap and bound to fileHash to prevent accidental recovery across files.

[0013] Furthermore, in step S6, when the local record is inconsistent with the list of uploaded chunks returned by the backend, missingChunks are generated using the complement of the difference or intersection of the two, and priority is given to uploading missingChunks.

[0014] Furthermore, the pause conditions in step S7 include at least one of the following: RTT exceeds a preset threshold; bandwidth is lower than a preset threshold; network type is switched to low quality type; the recovery conditions include multiple consecutive detections of qualityScore being higher than a preset recovery threshold.

[0015] Furthermore, in step S8, the waiting time for exponential backoff retry increases by 1s, 2s, and 4s, and the maximum number of retries is 3. When the maximum number of retries is exceeded, the chunkSize is downgraded to the preset minimum fragment size and the concurrency is forcibly reduced to 1.

[0016] Furthermore, the periodic evaluation of network quality score in step S7 is achieved through at least one of timed triggering and network change event listening, and the adaptive adjustment of chunkSize and concurrency is immediately triggered when the network type changes significantly.

[0017] Furthermore, this solution discloses a file fragment breakpoint resume system based on front-end adaptive network conditions, including: a file access module, a network evaluation module, a strategy calculation module, a fragmentation and hashing module, a progress persistence module, a fragmentation pre-check and difference calculation module, a concurrent upload control module, a retry and degradation module, and a merge verification trigger module. The network evaluation module is used to obtain RTT, bandwidth and network type and calculate qualityScore; The strategy calculation module is used to determine chunkSize and concurrency based on the qualityScore; The sharding and hashing module is used to shard by chunkSize and perform full hashing or sample hashing to generate fileHash; The progress persistence module is used to write the fileHash and the collection of uploaded shard indexes to local storage; The fragment pre-check and difference calculation module is used to compare with the fragment list uploaded by the backend to generate missing Chunks; The concurrent upload control module is used to upload missing chunks on a concurrency basis and to pause and resume uploads when the network fluctuates. The retry and degradation module is used to perform exponential backoff retries on failed shards and degrade chunkSize and concurrency when a threshold is reached; The merge verification trigger module is used to trigger the backend to merge and verify hash consistency after sharding is completed.

[0018] Furthermore, the concurrent upload control module includes a dynamic parameter tuning unit based on qualityScore, which is used to adjust the number of concurrent connections in real time and update the locally stored qualityScore record according to quality changes during the upload process.

[0019] Furthermore, this solution discloses an electronic device, including a processor and a memory, wherein the memory stores a computer program, and the computer program, when executed by the processor, implements the method described.

[0020] Furthermore, this solution discloses a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described.

[0021] Compared with existing technologies, the file fragmentation breakpoint resumption method and system based on front-end adaptive network conditions described in this invention have the following advantages: (1) The front end of the present invention calculates RTT, estimates bandwidth and identifies network type by detecting requests, forms a normalized network quality score, and uses the score as the basis for determining the fragment size and concurrency, so that the fragments are smaller and the concurrency is lower under weak network conditions to reduce the failure rate, and the fragments are larger and the concurrency is higher under high-quality network conditions to make full use of bandwidth, thereby taking into account both efficiency and stability. (2) This invention uses full hashing for small files to ensure uniqueness verification; for large files, it uses sampling hashing of the first segment, the last segment, and a random middle segment. This reduces the hash calculation time and resource consumption while ensuring the accuracy of identification, and improves the availability of the front end. It is especially suitable for mobile terminals and weak network scenarios. (3) This invention writes key information such as file hash, network quality score and uploaded fragment index into localStorage or IndexedDB. Even if the page is refreshed, the browser crashes or the user closes the page and re-enters, the upload progress can be restored, avoiding duplicate uploads of completed fragments. (4) Before uploading, the present invention sends a fragment pre-check request to the backend to obtain the list of uploaded fragments. The frontend compares it with the local records to generate a set of missing fragments. Only the missing fragments are transmitted, which reduces redundant network overhead and improves the success rate of resuming interrupted transmission from the mechanism. (5) When the fragment upload fails, the present invention performs retry according to the incremental waiting time. After the number of attempts exceeds the threshold, a degradation strategy is triggered to reduce the fragment size and reduce the number of concurrent connections, so that the system can automatically converge to more robust transmission parameters when the network deteriorates, reducing the waste of resources caused by continuous failures. (6) This invention monitors network fluctuations in real time. When RTT increases significantly or bandwidth drops sharply, it automatically pauses uploading. Once the network stabilizes and the recovery conditions are met, it gradually resumes transmission, reducing frequent failures caused by weak network jitter and the waiting costs on the user side. (7) After all the fragments of the present invention are uploaded, the backend merge is triggered. The backend verifies the number of fragments and recalculates the complete file hash and compares it with the frontend hash. If there are missing fragments or inconsistent hashes, the backend can trigger re-verification or re-upload according to the error type to reduce the risk of file corruption. Attached Figure Description

[0022] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an undue limitation of the invention. In the drawings: Figure 1 This is a schematic diagram of the method described in an embodiment of the present invention. Detailed Implementation

[0023] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other.

[0024] In the description of this invention, it should be understood that the terms "center," "longitudinal," "lateral," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicating orientations or positional relationships based on the orientations or positional relationships shown in the accompanying drawings, are used only for the convenience of describing the invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, features defined with "first," "second," etc., may explicitly or implicitly include one or more of that feature. In the description of this invention, unless otherwise stated, "a plurality of" means two or more.

[0025] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art will understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0026] The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0027] This embodiment provides a solution applicable to large file upload scenarios on the web, particularly suitable for upload interruptions caused by mobile networks, weak networks, or frequent network switching. The strategy detects and quantifies network quality on the front-end, dynamically determines the chunk size and upload concurrency based on the score, and combines local progress persistence, front-end and back-end chunk status comparison, intelligent retry of failed chunks, and automatic pause and recovery mechanisms to resume uploads after interruption and perform final merging and verification. Background issues include the lack of dynamic network adaptation capabilities in traditional fixed chunking strategies, a surge in request counts under weak network conditions, and page response delays caused by browser main thread blocking during large file uploads.

[0028] I. Initialization and Task Context Construction After a user selects a file using the webpage file selector, the frontend retrieves the file object `File` in the `change` event and reads basic information such as file size and file type as the task context. Simultaneously, it generates a task identifier `uploadTaskId` for this upload, used to associate the upload status of the same file across multiple sessions. Preferably, `uploadTaskId` can be obtained by concatenating the file hash `fileHash`, file size, and file type, or by combining the session identifier `sessionId` returned by the backend with `fileHash`, to avoid conflicts caused by different files having the same name. In this embodiment, the frontend finally determines the `uploadTaskId` after network probing and hash calculation, and uses it as the key prefix for local persistent storage.

[0029] II. Network Quality Detection, Quantitative Scoring, and Jitter Reduction 1. RTT Measurement: The front end sends a lightweight probe request, such as / api / ping, to the server and records the difference between startTime and endTime as the round-trip time (RTT), which reflects the network's real-time response capability. A lower RTT, such as less than 100ms, usually corresponds to a better network.

[0030] 2. Bandwidth estimation: The front end can first use the browser interface navigator.connection.downlink to obtain the estimated downlink bandwidth; when compatibility is insufficient, a custom bandwidth test can be used, that is, send a fixed size of test data, such as 1MB, and calculate the actual bandwidth by the transmission time and convert it to Mbps.

[0031] 3. Network type identification: The front end reads navigator.connection.effectiveType to identify network types such as Wi-Fi, 5G, 4G, and 3G, and uses this as one of the scoring factors.

[0032] 4. Dynamic scoring: Define a network quality score, qualityScore, ranging from 0 to 1; the example scoring function is qualityScore equal to 0.4 multiplied by bandwidth weight plus 0.3 multiplied by RTT weight plus 0.3 multiplied by network type weight, where bandwidth weight and RTT weight can be obtained by normalization, and network type weight can be assigned according to Wi-Fi being higher than 4G being higher than 3G.

[0033] To avoid frequent switching of sharding strategies due to short-term network jitter, it is preferable to introduce a smoothing process for the qualityScore. For example, the moving average or exponentially weighted average of the most recent m detections can be used as the effectiveScore, and a minimum switching interval cooldownTime can be set. The strategy upgrade or downgrade is only triggered when the effectiveScore continuously exceeds the threshold boundary for a preset number of times, thereby reducing "back and forth switching".

[0034] III. Adaptive Determination of Fragment Size and Concurrency After obtaining the effectiveScore, the frontend calculates the chunkSize and concurrency of this upload: 1. Slice Size: When the network score is greater than 0.7 and the network type is WiFi or 5G, the slice size can be set to 5MB to 10MB; when the score is between 0.4 and 0.7, such as 4G network, the slice size can be set to 2MB to 5MB; when the score is less than 0.4, such as 3G or weak signal, the slice size is forced to be 1MB to reduce the risk of single slice failure.

[0035] 2. Concurrency: High-quality networks enable 3 to 5 concurrent requests; medium-quality networks default to 2 to 3 concurrent requests and allow dynamic increases or decreases; low-quality networks force single concurrent uploads to reduce the failure rate caused by congestion.

[0036] Furthermore, when the degradation policy is triggered, the fragment size can be further reduced to 512KB to cope with consecutive failures caused by severe network instability.

[0037] IV. File Fragmentation Generation and Hash Calculation Optimization 1. Split generation: The front end uses the File.slice method to cut the file in a loop by chunkSize to generate multiple Blob split objects, and attaches metadata chunkIndex and totalChunks to each split for subsequent sorting, verification and merging.

[0038] 2. File hashing: To reduce the hashing overhead of large files, this embodiment adopts a hybrid strategy: when the file is less than 50MB, spark-md5 is used for full hashing; when the file is large, a sampling hashing strategy is adopted, that is, 2MB is taken from the beginning and end and 3 segments of 1MB data are randomly selected from the middle, concatenated and the hash value is calculated, thereby reducing the calculation time while ensuring accuracy.

[0039] Optionally, to enhance fragment-level integrity verification, a chunkHash can be calculated for each fragment and carried when uploading the fragment; the backend performs consistency verification on the calculated fragment values ​​before writing to disk to avoid fragment content corruption under weak network conditions.

[0040] V. Breakpoint Information Persistence and Cross-Session Recovery Before the upload begins, the frontend creates a local progress record object, progressRecord, and persists it through localStorage or IndexedDB. The stored content includes at least the uploaded chunk index set uploadedChunks, the file hash fileHash, and the current network quality score qualityScore. After each chunk is successfully uploaded, uploadedChunks is incrementally updated and synchronously written to local storage to ensure that the upload status can be restored after the page is refreshed or the browser crashes.

[0041] When the user reopens the page or refreshes it, the front end reads the progressRecord. If it exists and the fileHash matches the current file's calculated result, the resume upload process begins. If they do not match, it is considered a new task, and the old record is cleared and reinitialized.

[0042] VI. Pre-upload checks, difference calculations, and queue construction Before the actual upload, the frontend sends a shard pre-check request to the backend, such as / api / checkChunks, carrying the fileHash to obtain the list of shards that the backend has successfully received; for example, if the backend returns 1, 2, 4, 5, it means that the 3rd shard has not been uploaded.

[0043] After merging the backend-returned list with the local uploadedChunks to remove duplicates, the frontend calculates the missing chunk index array missingChunks and only uploads the chunks corresponding to missingChunks, thereby avoiding duplicate transmission of successfully uploaded chunks.

[0044] Furthermore, the front-end constructs an upload queue, uploadQueue, whose elements can contain fields such as chunkIndex, blob, chunkSize, chunkHash, and retryCount; initially, uploadQueue only contains elements corresponding to missingChunks.

[0045] Concurrent scheduling, failure retry, automatic pause and resume 1. Concurrency Scheduling: The frontend maintains an active request count (activeCount). When activeCount is less than concurrency and uploadQueue is not empty, a fragment to be uploaded is retrieved from the queue and an upload request is initiated. After any upload request is completed, activeCount is decremented by 1, and the next fragment is scheduled, until uploadQueue is empty and all requests are completed. The concurrency count (concurrency) can be dynamically adjusted up or down based on network performance during task execution. When downgrading, it can naturally converge to the target concurrency by "stopping the addition of new requests" without forcibly terminating requests already in transit.

[0046] 2. Exponential backoff retries: When a chunk upload fails, the frontend performs an exponential backoff retries on that chunk, with the delay time increasing by 1 second, 2 seconds, and 4 seconds, for a maximum of 3 attempts. If it fails 3 times, the network is considered to be severely unstable, triggering a degradation strategy, such as reducing the chunkSize to 512KB and simultaneously reducing the concurrency to 1, and then regenerating the subsequent chunk splitting scheme or using smaller chunks only for chunks that have not yet been uploaded.

[0047] 3. Intelligent Pause and Resume: The front end monitors network fluctuations in real time. When it detects a sudden increase in RTT greater than 500ms or a sudden drop in bandwidth less than 0.5Mbps, it automatically pauses upload tasks by no longer queuing new upload requests and suspending any transmission requests that can be aborted. When the network stabilizes, for example, when the qualityScore is greater than 0.5 for three consecutive tests, uploads are gradually resumed and chunkSize and concurrency are recalculated based on the current score.

[0048] 8. Real-time feedback, dynamic network monitoring, and dynamic policy optimization The front-end calculates the upload percentage based on the length of uploadedChunks and totalChunks and renders a progress bar, while also displaying the estimated remaining time (ETA). Whenever a chunk upload is completed or the status changes due to a failure and retry, a UI refresh and local storage synchronization are triggered.

[0049] Network dynamic monitoring employs two collaborative methods: one is timed detection, such as performing a network quality assessment every 5 seconds using setInterval to update the qualityScore; the other is event monitoring, such as binding the navigator.connection.onchange event, which immediately triggers a recalculation of chunkSize and concurrency and updates scheduling parameters when the network type or bandwidth changes significantly, such as switching from 4G to WiFi.

[0050] Furthermore, the front end can use additional metrics such as "number of strategy adjustments", "success rate of the most recent k sharding attempts", and "average sharding time" to dynamically adjust weights or thresholds, making the strategy closer to the actual link performance; for example, when the score is high but timeouts occur continuously, the concurrency can be temporarily reduced to prioritize stability.

[0051] 9. Merge Request and Overall Verification After Upload: After all fragments have been uploaded, the frontend sends a merge request to the backend, such as / api / merge, carrying fileHash and totalChunks. After receiving the request, the backend first verifies whether the actual number of fragments received is equal to totalChunks, then concatenates the fragment content according to the chunkIndex order, and recalculates the complete file hash and compares it with the frontend fileHash.

[0052] If the hash verification matches, the backend generates and stores the final file, returning the file URL or a success status. Upon receiving a successful response, the frontend clears its local progressRecord and notifies the user that the upload is complete. If the merge fails, for example, due to hash mismatch or missing fragments, the frontend triggers a re-verification based on the error type, re-obtains the list of uploaded fragments, and only re-uploads the missing fragments. If necessary, a full retry is also triggered.

[0053] 10. Exemplary Parameters and Operating Procedures Taking a 1GB file as an example: When the user is in a WiFi or 5G environment and the qualityScore is greater than 0.7, the front end selects 5MB to 10MB chunks and enables 3 to 5 concurrent connections to reduce the number of chunks and make full use of bandwidth; when the user switches from WiFi to 4G, causing the score to drop to the 0.4 to 0.7 range, the front end triggers parameter tuning through the onchange event, adjusting the chunk size to 2MB to 5MB and converging the concurrency to 2 to 3; when the network deteriorates further and the RTT is greater than 500ms or the bandwidth is less than 0.5Mbps, the task is automatically paused and waits for the score to be higher than 0.5 for 3 consecutive times before resuming. If it still fails frequently after resuming, it triggers exponential backoff and degradation, reducing the chunk size to 512KB and the concurrency to 1 to improve the success rate of resuming the download.

[0054] The above embodiments are only used to illustrate the implementation of this solution. Those skilled in the art can make equivalent substitutions or adjustments to the scoring model weights, thresholds, sampling hash slice lengths, concurrency upper and lower limits, number of retries and backoff time, etc., without departing from the concept of this invention, and all such substitutions or adjustments should fall within the protection scope of this invention.

Claims

1. A method for resuming interrupted file segmentation based on front-end adaptive network conditions, characterized in that, include: S1. Obtain the file to be uploaded on the front end, and get the file size and type, and generate file identification information; S2. Send a probe request to the server to measure the round-trip time (RTT), estimate the bandwidth and obtain the network type, and calculate the network quality score (qualityScore) based on the preset scoring function. S3. Determine the chunk size and concurrency based on the qualityScore. Higher quality results in larger chunks and higher concurrency, while lower quality results in smaller chunks and lower concurrency. S4. Perform hash calculation on the file: calculate the full hash when the file size is less than a preset threshold; otherwise, calculate the file hash fileHash by sampling the first segment, the last segment, and a random middle segment. S5. Slice the file into chunks by chunkSize to generate a chunk set. Generate a chunk index chunkIndex and a total number of chunks totalChunks for each chunk. Write fileHash, qualityScore and the uploaded chunk index set to local storage to persist the upload progress. S6. Before uploading, send a fragment pre-check request to the backend and carry fileHash. Receive the list of uploaded fragments returned by the backend, compare it with the local record to obtain the missingChunks index set of fragments to be uploaded, and only perform the upload on the fragments corresponding to missingChunks. S7. Upload chunks concurrently according to concurrency. During the upload process, periodically evaluate the qualityScore and dynamically adjust chunkSize and concurrency based on its changes. When network degradation is detected and the preset pause conditions are met, the upload is paused. When the network recovers and the preset recovery conditions are met, the upload continues. S8. When a chunk upload fails, an exponential backoff retry is executed. If the number of retries exceeds the threshold, a degradation strategy is triggered to reduce the chunk size and reduce concurrency. After all chunks are uploaded, a merge request is sent to the backend. The backend merges the chunks by totalChunks and verifies hash consistency. If successful, the progress information in the local storage is cleared and the upload result is output.

2. The method according to claim 1, characterized in that, The bandwidth estimation in step S2 is achieved by at least one of the following methods: obtaining the estimated downlink bandwidth by reading the browser's network information interface; or sending a fixed amount of test data to the server and calculating the bandwidth based on the transmission time.

3. The method according to claim 1, characterized in that, In step S3, when the qualityScore is greater than the first threshold, the chunkSize is set to 5MB to 10MB and the concurrency is set to 3 to 5; when the qualityScore is between the first threshold and the second threshold, the chunkSize is set to 2MB to 5MB and the concurrency is set to 2 to 3; when the qualityScore is less than the second threshold, the chunkSize is set to 1MB and the concurrency is set to 1.

4. The method according to claim 1, characterized in that, The sampling hashing in step S4 includes: extracting a first length of data from the beginning of the file, extracting a second length of data from the end of the file, and randomly extracting at least one segment of data from the middle of the file. The extracted data are then concatenated and the hash is calculated to reduce the computation time.

5. The method according to claim 1, characterized in that, In step S6, when the local record is inconsistent with the list of uploaded chunks returned by the backend, missingChunks are generated by the complement of the difference or intersection of the two, and priority is given to uploading missingChunks.

6. The method according to claim 1, characterized in that, In step S8, the waiting time for exponential backoff retries increases by 1s, 2s, and 4s, and the maximum number of retries is 3. When the maximum number of retries is exceeded, the chunkSize is downgraded to the preset minimum fragment size and the concurrency is forcibly reduced to 1.

7. The method according to claim 1, characterized in that, In step S7, the periodic evaluation of network quality score is achieved through at least one of timed triggering and network change event listening methods, and the adaptive adjustment of chunkSize and concurrency is immediately triggered when the network type changes significantly.

8. A file fragmentation and breakpoint resumption system based on front-end adaptive network conditions, characterized in that, include: The module includes a file access module, a network evaluation module, a policy calculation module, a sharding and hashing module, a progress persistence module, a sharding pre-check and difference calculation module, a concurrent upload control module, a retry and degradation module, and a merge verification trigger module. The network evaluation module is used to obtain RTT, bandwidth and network type and calculate qualityScore; The strategy calculation module is used to determine chunkSize and concurrency based on the qualityScore; The sharding and hashing module is used to shard by chunkSize and perform full hashing or sample hashing to generate fileHash; The progress persistence module is used to write the fileHash and the collection of uploaded shard indexes to local storage; The fragment pre-check and difference calculation module is used to compare with the fragment list uploaded by the backend to generate missing Chunks; The concurrent upload control module is used to upload missing chunks on a concurrency basis and to pause and resume uploads when the network fluctuates. The retry and degradation module is used to perform exponential backoff retries on failed shards and degrade chunkSize and concurrency when a threshold is reached; The merge verification trigger module is used to trigger the backend to merge and verify hash consistency after sharding is completed.

9. The system according to claim 8, characterized in that, The concurrent upload control module further includes a dynamic parameter tuning unit based on qualityScore, which is used to adjust the number of concurrent uploads in real time according to quality changes and update the locally stored qualityScore record during the upload process.

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

Images