Assuming an external user wants to use the link tohttps://app1.example.comaccess the application corresponding to app1 in the home data center, what is the specific access process? You can look at the following flowchart (assuming the home broadband has a public IPv4 address; if there is a public IPv6 address, the process will be simpler, while the process without a public address is somewhat different from this and will be discussed in a dedicated article later):

Next, we will go through the various technical knowledge points involved in the entire access process based on the flowchart above, where the processes marked in orange indicate that the relevant technical configurations need to be completed in the cloud, and the processes marked in green indicate that the relevant technical configurations need to be completed locally.

In the construction of the entire home data center, I used a total of 3 second-level domain names:

First, directly used at the home broadband egress, all applications are published through this domain name. This can be considered a backup access method; even if the cloud is completely interrupted, it can be accessed directly using https plus the port. The domain name provider is Alibaba Cloud (since home broadband has a dynamic IP address, this method requires a dynamic domain name client in the home broadband intranet to update the A record corresponding to the domain name on Alibaba Cloud in real time; I use iKuai's built-in dynamic domain name client to solve this problem).

Second, used to provide public access to the outside, solving the problem of home broadband not having port 80 and port 443. It is mainly used for domain name resolution of Tencent Cloud CDN and cloud hosts. The domain name provider is Tencent Cloud, and ICP filing is required.

Third, used for overseas access acceleration, with the main purpose of leveraging Cloudflare's free CDN. The domain name provider is Tencent Cloud, and ICP filing is required.

To use CDN acceleration for the app1.example.com domain name, you only need to add a CNAME for app1 in the domain name console of example.com, with the record value pointing to the address specified when configuring the CDN.

Theoretically, 2 domain names are actually enough (one can be used for the home broadband egress, CDN, and cloud host). I was mainly reluctant to give up the domain name on Alibaba Cloud that I was used to, and also wanted to take advantage of Tencent Cloud's newcomer discounts, so I simply bought 2 more on Tencent Cloud. Of course, it's also a bit of OCD—one domain name for one scenario, so I won't make mistakes when writing the solution.

Regarding the ICP filing issue, let me mention it briefly. It doesn't matter which provider you buy the domain name from (whether domestic or foreign); a domain name is just a function for resolving IPs. The key is that if the resolved IP is a domestic IP address, and the access requests (http and https) need to enter the domestic network and access domestic resources, the accessed domain name will be extracted and compared with the domestic ICP filing database. If the domain name is not in the filed database, it will be forced to redirect (http is in plain text, so the accessed domain name can be seen directly; although https is encrypted, SNI will expose the accessed domain name). Therefore, as long as you set up a website domestically, the ICP filing issue cannot be avoided (unless you can tolerate manually adding a port after the access link). Buying domain names from several major cloud providers (such as Alibaba Cloud, Tencent Cloud, etc.) has the advantage of convenient ICP filing, as well as free guidance from customer service (if you submit a personal ICP filing request and it doesn't meet the requirements, someone will keep calling you to teach you how to modify it~).

This part involves the specific configuration of the CDN. To configure the CDN, it is best to purchase the cloud host and domain name service from the corresponding cloud provider, which will simplify many steps (such as deploying SSL certificates, deploying CNAME, etc.). Of course, it is not mandatory; it doesn't matter if they are not bought together, it just involves some extra steps.

When configuring the CDN, you will be required to configure origin-pull parameters, acceleration type, access control, cache configuration, HTTPS, and some other advanced features. We will explain these in dedicated articles later.

This part involves the custom origin server address specified when configuring the CDN earlier. The origin server address is determined by the dynamic public IP of the home broadband egress. We mentioned earlier that iKuai can automatically update the A record information of the corresponding domain name in the domain name provider based on the change of the WAN port's public IPv4 address, so the origin server address in the CDN can directly point to the specific dynamic domain name of the home broadband egress (it can be specifically planned as the origin domain name, or used by a certain application, either is fine. If it is multi-dial, you also need to consider the balance of published traffic across multiple WAN ports).

It is not mandatory to use iKuai here; it's just that I use iKuai and find it convenient to write about. If it is not a multi-dial environment, it doesn't matter whether it is iKuai or not, as long as it supports automatic updates of dynamic domain names for multiple applications (iKuai's built-in dynamic domain name client is really powerful). Since the reverse proxy deployed in the intranet only needs to listen to one https port, only one port needs to be published externally on iKuai (it is recommended to be consistent with the port listened to by the reverse proxy deployed in the intranet; this is purely to avoid getting confused by various port conversions during subsequent application troubleshooting, and is not a mandatory requirement). You can forward all requests reaching the iKuai WAN port publishing port to the listening port of the intranet reverse proxy through port mapping.

This mainly involves the relevant configuration of the reverse proxy. The reverse proxy needs to be configured for the domain names of all published applications (it is best to plan the third-level domain names corresponding to each application in advance). At the same time, to prevent malicious IP resolution, a default site and an incorrect SSL certificate need to be configured (otherwise, the other party will reverse-lookup your domain name through the IP). Of course, this is most critical to configure on the cloud host. Home broadband has a dynamic IP, which is not as dangerous as the fixed IP of a cloud host, but to be safe, it should still be configured.

After the reverse proxy determines that the HOST of the access request is a legitimate domain name, it will insert some parameters from the original access request into a brand-new request sent to the Web Application Firewall (everyone must understand that this is a brand-new request sent by the reverse proxy as a client to the Web Application Firewall, rather than forwarding the original request, and by default, the reverse proxy does not carry various parameters from the original request, which is why there is a need to pass the original access request parameters to the next stop).

This mainly involves the relevant configuration of the Web Application Firewall. Since it is a home data center, application publishing must at least go through the filtering of a Web firewall. This Web Application Firewall is preferably open-source, free, and has a graphical interface; it should prevent common scans and attacks, support multiple semantic analyses, human-machine verification, high-frequency access blocking, etc. After the Web firewall confirms that the access request is legitimate, it will be sent to the next destination: the load balancing device.

A basic function that all load balancing devices have is health monitoring. If it detects that the application in the primary environment is down, it will directly forward the request to the same application in the backup environment (this is called active-standby mode; it can also send requests to the same application in both environments simultaneously using round-robin, ratio, etc., but this involves another issue, which is database synchronization, which I will talk about later). The load balancing device is not a mandatory option because there is a prerequisite of having two business environments: primary and backup. I introduced the load balancing device because I have two environments and didn't want to waste them; friends with only one set do not need it. Load balancing is a large field, and we will dedicate a section to it later.

In summary, although the client only enters the domain name in the browser and presses Enter to see the application content, the actual process is very complex. This is just a home data center with a relatively simple structure. If it were an enterprise data center, with more and finer divisions of business systems and security zones, it would be much more complex. However, logically speaking, the outline is the same, allowing everyone to get a glimpse of the whole picture.