1 Introduction

Since my blog uses a special WordPress active-active architecture (the macmini in the home data center is the primary-write and secondary-read node, and the VPS in Chicago Racknerd is the primary-read node), once there is a content change on the macmini node (all blog content modifications and new article publishing are completed on it), it is necessary to use a script to export the WordPress library in the mariadb database on the macmini node as a wordpress.sql file, and use the scp command to transfer the file to the specified directory of the Chicago node through the ssh connection with the Chicago node (originally, syncthing was used to synchronize based on the tailscale IP, but the outbound tailscale is basically scrapped, so scp is used instead). Subsequently, after detecting the file change, the inotify application on the Chicago node automatically executes the local script to complete the local import of the WordPress library, thereby achieving complete synchronization of the WordPress database content of the two nodes.

This process has been running well before, and I have never had any problems. However, a few days ago, I suddenly found that something went wrong during certain periods of time. The scp status kept switching between stalled and ETA. After 20%, the transmission speed became slower and slower, until the connection was finally closed:

Switching to rsync and limiting the average transfer speed does not work either:

At first I thought it was "some wall" doing something tricky, such as deep detection of specific protocols or data patterns and resetting connections. But after careful observation, I found that this problem is highly related to the time period: the situation becomes particularly bad after 23:00 every night, while it is much better during the day. In many cases, rsync can be successfully transferred. If it is really the influence of "some wall", it should not be only frequent at night.

I continued to dig for the cause, and finally locked the culprit on the restriction policy of Racknerd's Chicago node itself. Because the most serious period of the problem - for example, 22:00 in the evening in China, which is equivalent to 9:00 in the morning in Chicago, is exactly the beginning of their workday peak traffic; at 23:00 in China, it is exactly 10:00 in the morning in Chicago, which is also completely consistent with the time period when white-collar workers use the Internet on a large scale. On the other hand, when I test the transmission during the day in China (such as 9 or 10 in the morning), it is often still early morning or night in Chicago, when the network is in the off-peak period, the speed limit and packet loss are much lighter, and whether using scp or rsync, there is a high probability that the file can be successfully transferred.

After some research, I found that this seems to be a common bandwidth protection method used by many cheap VPS providers: they usually schedule traffic, apply shaping, or enable more aggressive traffic cleaning rules for single connections (single TCP sessions) during the morning peak of the computer room network (that is, local working hours) to ensure the overall availability of more paying customers or the entire computer room network. Because these low-priced VPS are essentially oversold, the node bandwidth is far from enough to meet the full capacity of each virtual machine, especially service providers like Racknerd, which are famous for "low-price annual payment", often directly limit the speed, drop packets, or even actively reset the connection to suppress sudden large file transfers during peak hours.

In addition, this limitation does not only occur in the transmission scenario over SSH (such as scp, rsync -e ssh). Single connection with large flow for a long time The following common situations are easy to be attacked:

• Use scp or rsync to copy large files over SSH (typically single TCP stream, with continuous and stable packets)
• FTP passive or active transfers of single large files are also vulnerable to attack.
• Tailscale / zerotier overlay networks run large files (although they are UDP, they are often treated as abnormal traffic on overseas routes)
• Using curl or wget to download large files directly can easily trigger shaping because of the high bandwidth of a single connection.
• Even on the Web, a single aria2c multithreaded download can often get around restrictions, whereas a single-threaded HTTP GET will be throttled or disconnected.

---

For cheap VPS service providers like Racknerd, this single connection speed limit or traffic scheduling will hardly affect most of their target customer groups (small websites, lightweight APIs, daily operations and maintenance). Only a very small number of users who need to frequently transfer large files or continuously use up the bandwidth will feel headache. This is exactly the "gray balance" that they acquiesce to through price and resource control.

---

2 Solutions

After encountering this problem, I actually thought about it carefully, and there are generally three main solutions I can think of.

First, HTTP/HTTPS service

The first thing that comes to mind is of course the solution that is most in line with Internet intuition: temporarily start an HTTP or HTTPS service on the macmini, and then let the Chicago node actively pull the file over using tools such as aria2c or wget -c that support multi-threaded breakpoint resumption. After all, HTTP is naturally suitable for file transfer and can easily handle segmented downloads. Multi-threading can also effectively circumvent Racknerd's strategy of limiting the speed of a single connection. In addition, I have long used Cloudflare Tunnel to safely expose the macmini website to the public network. Even if the registered domain name has been cancelled, the Tunnel can still provide access services, and there is no need to worry about the problem of domestic operators directly blocking HTTP traffic.

But on second thought, this is a bit of an overkill. My scenario is actually very simple. It's nothing more than transferring a SQL file of less than 100MB each time. For this, I have to configure a multi-site directory, add access authentication, and consider Cloudflare's cache rules, which is too cumbersome. As for tailscale or other intranet penetration tools based on WireGuard, they are even less suitable for this kind of cross-border large traffic scenario - under my current line, the stability of tailscale is not very reliable. Large files are often prone to disconnection. I dare not bet on it for such an important task.

Second: Cloud storage transfer

Just upload the file to a network disk or object storage, such as Google Drive, OneDrive, Alibaba Cloud OSS, Tencent COS, and then let the Chicago node download it from there. This method is actually very safe, because the HTTPS traffic of these large cloud companies is "mixed" enough. Even on a cheap VPS like Racknerd, their upstream operators are not very willing to arbitrarily limit the speed or deal with packet loss, making the download process very stable. What's more, these object storage or network disks naturally support breakpoint continuation and multi-threaded downloading. You can run aria2 and it's done, no matter how large the file is. But from another perspective, for my current scenario - I only need to transfer SQL files of tens of megabytes a few times a week, this method seems to be overkill. Uploading and downloading again, it takes an extra round. What can be done in 1 minute usually requires several rounds of tossing back and forth, which is a bit "killing a chicken with a sledgehammer" and not cost-effective.

The third method: breakpoint resume

This idea has become the most suitable solution for me: still use the simplest rsync to transfer files through a single SSH connection, and then use the "-partial-append-verify" feature to continue accumulating transmission from the breakpoint after the transmission is interrupted. Combined with the retry mechanism added in the script, wait for 10 seconds each time it fails and try again, up to 5 or 6 times, it can almost guarantee that the file will be completely transferred to the Chicago node within a limited time. Although this method will still be targeted by the single connection flow limiting strategy during peak hours in the Racknerd computer room, because the file is not large, it is easier to get things done in the actual environment by "cannibalizing" the segmented transmission multiple times. To be honest, the biggest advantage of this solution is that you don't need to install any additional services, you don't need to run an HTTP server, and you don't need to consider configuring complex object storage. The existing SSH can run and get it done, which is both worry-free and elegant.

So the final conclusion is very simple: if I want to transfer a video library of several hundred GB, I will definitely go with COS or OSS and use multi-threaded downloading; if I only transfer files abroad, HTTP will definitely be a good choice; but as I do now, my Mac Mini at home exports 50M SQL files several times a week and sends them to the Chicago VPS, relying on rsync breakpoint resumption to accumulate multiple times, which is really the most cost-effective "right way in the world".

Note: Actually, there is another most convenient way, which is to avoid the peak traffic period in Chicago during the day, and upload files honestly during other time periods. However, based on the guiding ideology of "Go ahead when there are difficulties, and go ahead even when there are none", of course we have to face the challenges head-on. The key is to still be able to write a good article~.

3 Use rsync to resume transfer

3.1 Introduction to rsync

rsync is a very commonly used file synchronization and transfer tool on Unix-like systems (Linux, macOS). It is known for its high efficiency. Its core feature is to only transfer the file parts that have actually changed (incremental transfer), and supports powerful compression and verification mechanisms. It can be used for backup between local folders, and can also be used to securely transfer files between different servers through the SSH protocol.

Compared with more "foolproof" transmission tools such as scp and ftp, the advantage of rsync is that it is extremely versatile and can be precisely controlled in more scenarios:

• When some files already exist on the target end, you can continue to transfer incrementally from the interruption point (for example, through –partial + –append-verify). Even if the network is disconnected, you can re-run the command and continue from the last progress. This is very suitable for cross-border networks that are prone to packet loss and interruption.
• Using the -z parameter can enable compression during transmission, which significantly reduces bandwidth consumption on international links and is usually faster.
• The -a (archive) parameter can be used to retain all metadata such as file timestamps, permissions, symbolic links, etc. at once, which is very suitable for accurate backup or server migration.
• Adding –delete can even make the target directory strictly synchronized with the state of the source directory, which will directly delete the redundant files in the target directory to avoid the long-term accumulation of junk files.
• Through –chown=user:group, you can directly modify the file owner and group when syncing to the target machine. This is very suitable for scenarios like Web panels that require specific permissions, such as iPanel, Baota and other site directories, so that the synchronized files can be used immediately.
• Adding –progress can display the real-time transfer progress of each file; using –bwlimit=2000 (in KB/s) can also limit the maximum bandwidth to avoid filling up the line.
• You can also use –exclude to flexibly exclude files that do not need to be synchronized, such as –exclude=.git or –exclude=*.log, to synchronize only the required content.

rsync can also work seamlessly with SSH (rsync -e ssh), and has advanced features such as secure transmission and breakpoint resumption and incremental verification, making it almost the preferred tool for multinational server backup and site synchronization.

---

It should be noted that rsync is a typical dual-end tool.Install rsync on both local and remote machines, because the remote will call its own rsync through ssh to participate in hash calculation and data pulling. This is why when executing rsync, the remote rsync will actually be implicitly called in ssh, and there is no need to open a separate daemon process or a dedicated service port like FTP to transmit safely. For this reason, rsync has become the preferred tool widely used in multinational server deployment, backup, and synchronization scripts.

---

3.2 Version requirements for implementing the power-off resume function

It should be noted that rsync has certain version requirements for implementing the breakpoint resume function (the --partial feature is supported by almost all versions, the --append feature requires version 2.6.4 or above, and the --append-verify feature requires the versions of both ends to be 3.x or above). Although rsync is built-in in many systems (such as macos and some distributions of linux), the versions vary greatly. Taking my macos as an example, the default version is 2.6.9, which cannot support the --append-verify function:

The rsync version installed by apt in Debian 12 of the Chicago node is 3.2.3, which can meet all the features of breakpoint resuming:

---

One of the biggest highlights of rsync is its "breakpoint resume" capability, which is a must for cross-border and easily interrupted network environments. However, its implementation is actually divided into different levels, and some parameters are required to clearly tell it how to resume the transfer.

1,–partial

This is the most basic and earliest supported (almost since the earliest 2.x) parameter in rsync.

• Effect: If the transfer process is interrupted (such as a network outage or manual stop), rsync will delete the target file being transferred by default to avoid leaving incomplete files.
• After adding --partial, rsync will keep this "incomplete file" and reuse it in the next transmission.
• Applicable Versions:All common rsync (2.x and above) are supported.

It actually just guarantees that "files are not deleted after interruption", which does not mean that rsync will continue uploading from the end of the file next time. Instead, it will scan, compare, calculate delta, and then possibly re-upload some blocks.

2,--append

• From rsync 2.6.4(2004) began to support.
• Effect: When there are already some files on the target side, rsync will directly append data from the end of the file without checking the content.
• Suitable for log scenarios where new data is added only at the end of the file, such as a growing log file.

The disadvantage is that it does not perform hash verification on the existing part. If the previous file is damaged or inconsistent, it will still be appended from the end, which may cause the file to be damaged without knowing it.

3.--append-verify

• From rsync 3.0.0(2008).
• An enhanced version of --append.
• Function: The transfer will also resume from the end of the target file, but after the transfer, the file will be verified to ensure that it is complete and correct. If the verification fails, it will return to the traditional "block comparison and transfer" process to ensure that the target file and the source file are ultimately consistent.
• It is very suitable for scenarios like ours where strict consistency is required for transmitting database backups, tar packages, SQL files, etc.

Common combinations: –partial –append-verify

In production scripts, you often see something like this:

rsync -avz --partial --append-verify -e "ssh -p 12345" localfile user@remote:/path/

Their respective roles:

• --partial ensures that partial files already downloaded to the target machine are not deleted if the transfer is interrupted.
• –append-verify The next time you run the program, it will continue to transfer from the end of the file, and will automatically perform a verification after the transfer to ensure that the file is complete and reliable.

In this way, even if the line is cross-border and easily disconnected, the file can be transferred stably and cumulatively by executing rsync multiple times, without wasting the data blocks that have already been transferred.

---

4 rsync ≠ scp + breakpoint resume

Many people first come into contact with rsync, often just because they need an "SCP that can resume transfers". Just like me, after using SCP to transfer files across borders and always failing, I hurriedly looked for alternatives, and was eventually attracted by "rsync supports resume transfers". But in fact, rsync is far more than that, and I think of this picture again:

It can not only resume synchronization from the breakpoint after the network is disconnected, but also efficiently compare the file contents of the source and target to achieve true incremental transmission - even if the file is hundreds of megabytes, as long as only a few KB have been changed, rsync will only transfer the difference blocks of a few KB. This algorithm-level superiority is simply impossible for simple tools such as scp and ftp.

The following is an example of how I used scp and rsync to transfer the same wordpress library file using the same link at the same time for comparison.
scp took 12 seconds:

rsync took only 4 seconds:

This is when the link is very good. When the file is transferred in one go, rsync only takes one-third of the time of scp. If the link is very bad and scp keeps retransmitting, rsync will be much faster by relying on breakpoint resumption. Not to mention that rsync can also add compression, retain file timestamps and permissions, delete unnecessary files on the target end (--delete), and even directly modify the owner of the remote file through --chown, allowing it to directly advance from a file synchronization tool to a deployment tool.

It was created to "maintain precise consistency on both ends", and breakpoint resumption is just the most visible part of its capabilities.

5 Synchronize directories using rsync

5.1 Overview

When many people mention rsync, they think of using it to transfer a single large file (such as wordpress.sql in this article). But in actual production and operation and maintenance scenarios,The most common use of rsync is to synchronize directories. —— For example, website code, static resources, backup files, media libraries, configuration file directories, etc.

5.2 The simplest directory synchronization

Let's first look at the most common and simple example:

rsync -av /local/site/ user@remote:/var/www/site/

What does this command do?

• -a (archive mode) recursively enters subdirectories and retains file permissions, owners, timestamps, soft links and other metadata. It is equivalent to the combination of -rlptgoD and is very suitable for backup or deployment.
• -v (verbose) displays detailed process.
• The "/" at the end of /local/site/ is very important: with "/", it means to synchronize the contents of the directory to the remote instead of synchronizing the site directory itself; without "/", the site directory itself will be copied to the remote, becoming /var/www/site/site/.

---

Many people will write it as follows for the first time:

rsync -av /local/site user@remote:/var/www/

Then I found that there is an extra /var/www/site/ directory on the remote machine. If you just want to put the files in site into /var/www/site/, remember to add / after the local path.

---

5.3 Using –delete to maintain strict consistency

If you are doing online deployment (such as updating a blog or static site), the most common thing is to add –delete:

rsync -av --delete /local/site/ user@remote:/var/www/site/

This means: keep the remote directory strictly consistent with the local directory; if there are more files in the remote directory (which have been deleted locally), rsync will delete them for you.One master syncs multiple slaves, or scenarios with very high requirements for deployment consistency.

5.4 Ensure consistent ownership and permissions

On some VPS or production servers, you need to ensure that the owner and group are correct (such as www-data or nginx user). In this case, you can use –chown:

rsync -av --delete --chown=www-data:www-data /local/site/ user@remote:/var/www/site/

This way, there is no need to worry about the problem that local users and remote users are different.

5.5 Add some compression, suitable for cross-border routes

If you are syncing across borders (for example, I am syncing from my home data center to Chicago), you can add -z to compress the transmission, which significantly reduces bandwidth consumption and increases speed:

rsync -avz --delete /local/site/ user@remote:/var/www/site/

5.6 Summary

So several common combinations of rsync in directory synchronization scenarios are:

• -a retains meta information (permissions, timestamps, soft links, owner and group, etc.)
• -v Print synchronization process
• -z enables compression, suitable for multinational
• –delete Make the target directory strictly consistent with the source
• –chown ensures that the owner and group are consistent

This is why almost all website automation deployment, NAS synchronization, and backup scripts useThis is why rsync is used to replace scp, ftp and other tools.

6 Install the latest rsync on macos

Since the rsync version installed on the Chicago node's Debian 12 already meets the requirements, there is no need to bother. I only need to use homebrew to install the new version of rsync on the MacMini:

brew install rsync

The new rsync will be installed in /opt/homebrew/bin/rsync (Apple Silicon) or /usr/local/bin/rsync (Intel).

Confirm the version of rsync with the following command:

/opt/homebrew/bin/rsync --version

The latest version of rsync currently installed by brew is 3.4.1:

If you don't want to use an absolute path (such as /opt/homebrew/bin/rsync) every time to call the new version of rsync installed by Homebrew, you can modify Shell environment variable files to make it take effect automatically.

The specific steps are:

1. Find your ~/.zprofile (Zsh login configuration file) or ~/.zshrc (Zsh interactive configuration file) and open it with vim ~/.zprofile or open -e ~/.zprofile (or any editor).

2. Add a line like this to the file.Make sure to put it at the end of the file(to avoid being overwritten by other exports later):

export PATH="/opt/homebrew/bin:/opt/homebrew/sbin:$PATH"

This line means putting the executable file path of Homebrew at the front of $PATH, so that the system will give priority to finding the software installed by brew. However, do not write it like this:

export PATH="/opt/homebrew/bin:/opt/homebrew/sbin"

This will cause all the original system paths to be lost, causing basic commands such as ls and cat to become invalid.

3. After modifying and saving, return to the terminal to execute

source ~/.zprofile hash -r

4. Finally, check with the following command:

which rsync rsync --version

Confirm that the output is /opt/homebrew/bin/rsync and the version is 3.4.x, which means the configuration is successful. Take my macmini as an example:

Note: Install rsync directly on Debianapt update && apt install rsyncJust follow the command, I won’t write a separate chapter about it.

7 Using rsync's breakpoint-resume feature to transfer files over SSH

I have rsync installed on my local home data center macmini and remote Chicago node debian12, and ssh is configured correctly (it is recommended to configure local to remote SSH public key access first, if you are not familiar with it, you can refer to the article:Debian series configuration ssh public key login), you can directly use rsync to start transferring files. First set the export path and target server information as follows:

# Set the export path, taking the local wordpress.sql file of the macmini that I want to export as an example: EXPORT_PATH="/Volumes/data/docker/wordpress/db/wordpress.sql" # Target Chicago vps information, including ssh username, target vps IP address, ssh port and remote path REMOTE_USER="root" REMOTE_HOST="107.xx.xx.xx" REMOTE_PORT="12345" REMOTE_PATH="/docker/wordpress/db/wordpress.sql"

The final rsync command is as follows:

/opt/homebrew/bin/rsync -az --progress --partial --append-verify -e "ssh -p REMOTE_PORT"EXPORT_PATHREMOTE_USER@REMOTE_HOST:$REMOTE_PATH"

Of course, you can also write it directly without defining variables, but it will look very long:

/opt/homebrew/bin/rsync -az --progress --partial --append-verify -e "ssh -p 12345" "/Volumes/data/docker/wordpress/db/wordpress.sql" "[email protected]:/docker/wordpress/db/wordpress.sql"

If an error occurs during the transfer, just run the command again to resume the transfer. After repeating this several times, the file transfer can be successfully completed.

8 Advanced: Automatic retransmission using shell scripts

The method of manually running commands repeatedly to resume breakpoints is also problematic, but it is a bit low from a technical point of view. It is okay to use it occasionally, but it will definitely drive me crazy if I use it frequently, so I finally have to use a shell script. The following is the script I use for your reference:

#!/bin/bash # Load environment variables (for ssh call to take effect) source ~/.bash_profile # Set the exported source path EXPORT_PATH="/Volumes/data/docker/wordpress/db/wordpress.sql" # Target server information REMOTE_USER="root" REMOTE_HOST="107.xx.xx.xx" REMOTE_PORT="12345" REMOTE_PATH="/docker/wordpress/db/wordpress.sql.tmp" FINAL_PATH="/docker/wordpress/db/wordpress.sql" # rsync retry configuration MAX_RETRY=10 RETRY_DELAY=10 # seconds echo "Start exporting WordPress database..." if docker exec -u root mariaDB01 mysqldump -uroot -pyourpassword --databases wordpress > "EXPORT_PATH"; then echo "Export successful:EXPORT_PATH" # rsync retry loop COUNT=0 SUCCESS=0 while [[ COUNT -ltMAX_RETRY ]]; do echo " ((COUNT+1)) attempts to transfer rsync..." /opt/homebrew/bin/rsync -az --progress --partial --append-verify -e "ssh -pREMOTE_PORT"EXPORT_PATHREMOTE_USER@REMOTE_HOST:REMOTE_PATH" if [[ ? -eq 0 ]]; then echo "rsync transfer successful!" SUCCESS=1 break else echo "rsync transfer failed, waitingRetry after RETRY_DELAY seconds..." sleep RETRY_DELAY ((COUNT++)) fi done if [[SUCCESS -ne 1 ]]; then echo "🚨 rsync failed after multiple attempts, exit the script!" exit 1 fi # Remote and local md5 verification echo "🔍 Get remote file MD5..." REMOTE_MD5=(ssh -p "REMOTE_PORT"REMOTE_USER@REMOTE_HOST" "md5sum REMOTE_PATH | awk '{print \$1}'") LOCAL_MD5=(/sbin/md5 -q "EXPORT_PATH") echo "Local MD5:LOCAL_MD5" echo "Remote MD5: REMOTE_MD5" if [[ "LOCAL_MD5" == "REMOTE_MD5" ]]; then echo "MD5 verification is consistent, execute remote rename..." ssh -p "REMOTE_PORT"REMOTE_USER@REMOTE_HOST" "mv REMOTE_PATHFINAL_PATH" # Bark notification echo "Sending Bark notification..." curl -s --max-time 5 -A "useragent" \ "https://xx.tangwudi.com/myiphone-token/macminiNode notification/wordpressDatabase export successful" >/dev/null curl -s --max-time 5 -A "useragent" \ "https://xx.tangwudi.com/mymacmini-token/macminiNode notification/wordpressDatabase export successful" >/dev/null echo "Task completed, all processes executed successfully!" else echo "MD5 check is inconsistent, please check the transmission process!" exit 1 fi else echo "Database export failed" exit 1 fi echo "Script end"

This is an automated script designed specifically for scenarios with unstable transnational networks. It is used to export the MariaDB database of WordPress from a local Docker container and back it up to a remote node in Chicago. The process is as follows:

1. First, generate a complete SQL file for the WordPress library locally

2. Then, with the help of rsync's breakpoint resume (--partial +--append-verify) mechanism, it will automatically retry multiple times when encountering network fluctuations or interruptions caused by speed limits, to ensure the success of the transmission to the greatest extent possible.

3. After the file is transferred, the script will calculate the MD5 hash value locally and remotely for strict verification to confirm that the file content is completely consistent

4. Perform another atomic rename operation remotely to ensure that only complete and available database files are always available on the target server.

5. After all the processes are completed, the script will also send multi-channel push notifications to the mobile phone through Bark, so that you can grasp the backup results in time without staring at the terminal

The entire process from export, transmission, verification to final notification is fully automated, greatly reducing the need for manual intervention and avoiding potential data consistency risks caused by unstable cross-border lines.

9. Afterword

What’s frustrating is that when I was almost done writing the article and was about to use actual cases to verify the power of the rsync breakpoint resume modification solution, the result was a complete failure - the cross-border line suddenly became unusually smooth: the transfer of a 50-megabyte SQL file was not only successful in one go, but also incredibly fast, almost instantly filling up the bandwidth, and in the fastest case, it took only 3 seconds to complete the transfer:

I was stunned on the spot, and I tried it several times after 23:30 in the evening, hoping to wait for the line to return to the congestion during the previous peak hours, so that I could take some typical pictures of "breakpoint resume working". As a result, it was stable as a rock every time, and the battle ended in less than 10 seconds at most. The speed is comparable to transferring files between domestic computer rooms, and the export script was successful in one try:

This is so abnormal that it even makes me laugh and cry - I finally came up with an optimization solution, but because the network conditions are too good, I can't demonstrate its most shining scene.

However, if you calm down and think about it carefully, this is not a metaphysical phenomenon: the instability of cross-border networks is inherently "unpredictable". In many cases, it is not necessarily congested at peak times, but is often related to some temporary routing scheduling and the operator's QoS (quality control) strategy. For example, the backbone line occasionally has a short bandwidth release, or the computer room does not trigger the single connection speed limit threshold during certain time periods, and the transit nodes such as Cloudflare/HE.net may temporarily change the line, which will lead to this abnormal "extreme speed" occasionally.

On the other hand, it may also be related to the temporary use of a better return path by my local egress network. Even at the international egress, if the congestion at a peering (interconnection point) is relieved, the transmission speed will be greatly improved instantly. This is why we say that "a cross-border network is never something that can be fully predicted with scientific rigor." It is always in multiple dynamic scheduling and priority competition.

Therefore, this test happened to be a perfect match, resulting in the rsync optimization solution not being able to play its advantage of breakpoint resumption in the "bad scenario", which is a bit regrettable, but it also shows from the side that these robust designs were originally intended to be a backup for when 20% unfortunately encounters the worst line. In most cases, it is just a superfluous insurance. When the day comes when I really encounter a problem and need it, I won't be as flustered as before.