Preface

Actually, writing a dedicated article to talk about multi-dialing doesn't seem to make much sense, mainly because the prerequisite is that your home broadband supports multi-dialing, which is purely a stroke of luck: it depends on fate. It just so happens that my home data center has pushed multi-dialing to its limit, and thinking that there are still quite a few netizens whose home broadband supports multi-dialing, I decided to write an article about it, and while I'm at it, help everyone clear up some concepts, such as upstream bandwidth aggregation and downstream bandwidth aggregation.

Actually, to talk about multi-dialing, we should first mention another concept: multi-outlet link load balancing. Since the split of China Telecom and China Unicom into North and South, and the subsequent emergence of operators like China Mobile and Railcom (and if it was a school, there was also an Education Network link), a chaotic battle among multiple operators began, with operators restricting access to each other (cross-operator traffic was charged). At that time, CDNs were not yet popular, so various enterprises and institutions hosting their own websites could usually only use their existing broadband (generally one of Telecom, Unicom, or Mobile; only a few could use two or three simultaneously, such as banks, securities firms, or similar institutions that naturally faced all users), and then apply for a few public IPs from their partner broadband operators. Large ICPs at that time would use mirror sites (such as Telecom mirror sites, Unicom mirror sites, Mobile mirror sites) to solve the problem of cross-operator access.

For visitors, if the operator used by the visited site is not the same as the one they use, the access experience would be very poor. Therefore, at this time, a solution was introduced for enterprises and institutions: multi-outlet link load balancing. The core idea is to introduce broadband lines from multiple operators simultaneously, and then select the most suitable line based on the operator to which the visited site's IP belongs, in order to achieve the best access experience (while also achieving outlet link backup). At the same time, because the bandwidth and prices of different operators' links vary, strategies are needed to balance the use of each operator's outlet link by outgoing access requests. (This is for the visitor's organization; for site providers with multiple operator links, there is also corresponding multi-link load balancing access, which guides different users to use different operator links through DNS resolution—just a brief mention here, without going off on a tangent).

Why mention this? Because multi-dialing is actually a special type of multi-outlet link load balancing, except that it involves multiple links from the same operator, and the bandwidth is exactly the same.

Multi-dialing

Is there a public IP?

Multi-dialing should also be discussed in two scenarios: with a public IP address and without a public IP address. Truly valuable multi-dialing is the case with a public IP address. For example, my home can support up to 3-dialing, which gives me 3 public IPv4 addresses (my home also has a public IPv6 address, but this doesn't require multi-dialing; just enabling it on one port is enough). If it is multi-dialing without a public IP address, you can optimize downloading and uploading by setting appropriate link balancing strategies (this also depends on the ISP's central office settings; there are many variables, so it's down to luck). However, optimizing the downlink is only suitable when the downlink bandwidth is small, such as 100 Mbps or 200 Mbps. Generally, for downlinks exceeding 300 or 500 Mbps, average households no longer need to fuss over downlink bandwidth as it is completely sufficient; the key is actually optimizing the use of uplink bandwidth.

The so-called "bandwidth aggregation"

Downlink bandwidth aggregation

In fact, there is no such concept as downlink bandwidth aggregation in multi-dialing. Friends who have worked with multi-outlet link load balancing should be very clear about this. You can increase download speeds through appropriate outlet strategies, but this improvement is not because the downlink bandwidth is aggregated, but because you have reasonably utilized the advantage of having multiple IP addresses across multiple outlet links. Furthermore, this comes with a prerequisite: it must be multi-threaded downloading, and the download site must not have speed limits on downloads.

Single-thread downloading only goes through a single egress link. This download speed depends first on the restrictions of the download site (Is single-thread speed limited? Is multi-thread simultaneous downloading allowed for a single IP? How many threads are allowed to download simultaneously for a single IP?), and only secondarily on your own broadband's downstream bandwidth. If the download site has no speed limit for single-thread downloading, then the speed limit of single-thread downloading comes from the downstream bandwidth of your broadband. However, in reality, the speed of single-thread downloading (clicking to download in a browser) is often hard to say, sometimes fast and sometimes slow (and it also differs between domestic and overseas, with overseas being almost impossible to download). But no matter how fast it is, it generally won't exceed the downstream rate of home broadband. Therefore, at this time, the speed bottleneck is often at the download site, so it has nothing to do with whether your home broadband downstream is 200, 300, 500, or 1000 Mbps (100 is still a bit too low), and at this point, even if you have 10G, it's completely useless. (Does this sound familiar? I mentioned "completely useless" a lot in my last article, and this is where it comes from).

If the bottleneck of single-thread download speed comes from the download site, then multi-thread downloading might be useful at this time, if the other party allows it, for example:

In this case, the power of multi-dialing comes into play:

If your home broadband supports 3-dialing (let's assume 3-dialing, taking my home as an example)

If your 3-dialing gets you 3 public IPv4 addresses (this is actually not a must; even if you get private IP addresses, they might eventually go out through 3 different public IPs because the ISP's public IPv4 address pool is large enough)

If your multi-dialing load balancing policy is configured properly (what "properly" means will be discussed later)

Then theoretically you can achieve 9 times the download speed (this is not because of any bandwidth stacking, but simply because you have 3 public IP addresses).

However, I believe this is no longer the norm nowadays. There probably aren't many of these normal downloads left, as most still use P2P.

Uplink bandwidth aggregation

This is even more elusive than the downstream bandwidth stacking mentioned earlier, because scenarios that require upstream bandwidth are often bound to your public IP (such as PT). Therefore, the upstream bandwidth of your single dial-up determines the upper limit of this application's bandwidth, and multi-dialing 100 times is useless. Of course, playing PT with multi-dialing is also possible, and you can fully utilize the upstream bandwidth of each link (provided you have a public IPv4 address; why not mention public IPv6 addresses? Unless the router's port mapping supports mapping from public IPv6 to private IPv6, public IPv6 addresses all go through routing and have nothing to do with multi-dialing). It's just a bit troublesome, as you have to specify different egress links for each PT tracker server. I used to do this, but I don't anymore. First, it's too troublesome with dozens of PT sites... Second, I have already "graduated" and no longer need upload volume~. In fact, if you really lack upload volume, it's better to buy a seedbox. Running PT on home broadband is still mainly for points, so bandwidth is actually not that important anymore.

Having clarified the basic concepts, we will continue to talk about multi-dialing.

Multi-dialing strategies

Earlier, I mentioned the issue of configuring the multi-dialing policy properly. What does "properly" mean? Actually, this mainly refers to how you utilize your multiple egress links, also from both downstream and upstream perspectives.

Downlink

If you don't have any detailed requirements, you can directly use the ”multi-line load balancing“ method to multiplex several egress links. There are also several options for this, such as:

Uplink

This is the real point I want to make. A core concept of a home data center is to achieve the goal of hosting websites at the lowest cost, while still maintaining an excellent user experience. I believe that multi-dialing with public IPv4 addresses (having public IPv6 addresses works too, but it has nothing to do with multi-dialing and I'll write a new article about that later) truly delivers economic benefits when it comes to website hosting. Through multi-dialing, I can obtain 3 public IPv4 addresses, which theoretically gives me 3 egresses, each with 50 Mbps of upload bandwidth (since ISPs leave some margin, the actual upload for each egress is over 60 Mbps). Combined with iKuai's DDNS function, access traffic from different websites can be distributed to different egresses to achieve load balancing for upstream traffic. This is the greatest benefit of multi-dialing with public IP addresses. Just think about it: what does a 180 Mbps upload mean? How expensive would it be if it were business fiber? :)

The biggest disadvantage of home data centers

Actually, the biggest problem with building a website in a home data center is the lack of ports 80 and 443. As for uplink bandwidth, even without multi-dialing, my current 60 Mbps is generally more than enough. Buying a mini host with 64G RAM and a 13th-gen i5 for your home only costs about 3,000 to 4,000 RMB (install PVE, create a bunch of VMs and LXC containers, how much money can you save compared to cloud hosts??), and its performance completely blows cloud hosts out of the water (of course, rich people can do as they please). So as long as the port 80 and 443 issue is resolved, there are no obstacles for the home data center (except for a minute or so of disconnection during periodic dynamic IP changes).

How to solve the port 80 and 443 issue? Use a CDN. Generally, it's a CDN from a domestic cloud provider (requires ICP filing), or it can be Cloudflare (after optimization, Cloudflare's access speed is already acceptable). The origin server of the CDN can be specified with non-80 and non-443 ports, which solves the most critical problem. Meanwhile, multi-dialing can provide multiple public IPv4 addresses. If you reasonably allocate the outbound link IPv4 addresses corresponding to the origin server domain names, a 3-dial setup can yield 180 Mbps (60 multiplied by 3, not directly stacked) of uplink bandwidth. What does that mean? How much money can you save?

Note: For multi-dialing to work, it relies on public IPv4 addresses, but this is estimated to become increasingly difficult in the future. Currently, Chengdu Telecom requires at least 499 RMB per month for a public IPv4 address (a package of 399 or more plus a 100 service fee), which is too uneconomical. I will never change my 199 package; if I change it (even if it's an upgrade), I probably won't be able to keep the public IPv4 address.

Configure public network access

As for the method of publishing to the public network, you need to choose the most suitable way based on your actual environment and the reverse proxy you use. You can refer to several of my previous articles:
1、Docker Series: Building Your Own Reverse Proxy Based on NPM Using Docker
2、Linux Panel Series: Configuring Reverse Proxy and Publishing Using Non-443 Ports
3、Home Data Center Series: Getting Cloudflare for Free via Domestic ICP-Filed Cloud Hosts to Achieve Fast Access to Domestic Sites from Abroad
4、Home Data Center Series: Getting Cloudflare for Free via Home Broadband Without Public IP to Achieve Fast Website Building (Universal)

Among them, the 1st and 2nd methods are suitable for environments with a public IP but without a legal 443 port (home broadband, non-filed cloud hosts), where non-standard ports need to be added after the URL (if using Cloudflare to build a website, no port needs to be added, but you need to customize the origin server port, which you can refer to:Home Data Center Series: Solving the Problem of Having a Public IP but No Legal 80 or 443 Ports for Website Building via Cloudflare's Origin Rules). The 3rd method is suitable for cloud hosts with ICP filing, and the 4th method is suitable for all environments (including environments without a public IP), which is also my recommended method (regardless of whether your environment has a public IP, because this method does not require running HTTPS traffic directly on the public network).