Consulting FAQ

What are the conception and effect of Content Delivery Network?

Azure Content Delivery Network adds a new layer of network architecture to the existing Internet by caching the content of websites to the network “edge” nearest to the user. With this new layer, you can obtain the required content from a closer location, which provides a high-bandwidth, low-latency user experience.

What is CNAME?

A CNAME (canonical name) record generally redirects to an alias. For example, if your custom accelerated domain name is www.abc.com, the service domain name caused by website acceleration (after you have configured it) would be www.abc.com.mschcdn.com. You must have the domain-name registration company delete the corresponding A record for www.abc.com and add www.abc.com.mschcdn.com as the CNAME record for the domain name. Then, when you access www.abc.com, you will obtain the IP address record of the accelerated node that was parsed by www.abc.com.mschcdn.com.

What factors affect the cache hit rate?

What factors affect the cache hit rate?

  • Settings for cache configuration and content prefetching.

  • The HTTP header causes inability to cache.

  • Just added, not many cached files.

  • The type of source station means that the amount of content that can be cached is small.

  • Website visit numbers are low and the expiration time is short, so the number of files hit is small.

How long does it take to create Content Delivery Network domain name?

The process of checking that the supplied custom domain name and ICP number match and are valid takes no more than one business day to complete. If the details pass the Internet Content Provider (ICP) review, the Content Delivery Network service will be registered within 60 minutes, so that it can be propagated by the network. At the same time, you also need to configure the CNAME mapping details, as indicated by the notifications in the interface, before the cache content can finally be accessed via the custom domain name.

Is a record number necessary for activating Content Delivery Network?

The Ministry of Industry and Information Technology requires a record number for using Content Delivery Network. In terms of the specific ICP filing requirements, the only requirement is that the custom Content Delivery Network acceleration domain name you use has an ICP. There are no requirements for the source station itself, and source stations both inside and outside China are supported.

Do second-level domain names need to be filed?

Second-level domain names do not need to be filed. For example, if sample.com has been filed, images.sample.com does not need to be filed, and it is sufficient to provide the record number for sample.com when you create the Content Delivery Network acceleration node.

How long can Content Delivery Network serve after the record number becomes invalid?

When the record number is expired, you should update it at the Communications Authority themselves. By default, it will be forced to return to source if it is not recorded within 7 days. If the recording period is too long, and you want to use a Content Delivery Network service, you can contact us by issuing a work order.

Can I use the Content Delivery Network if the domain name is redirected?

Yes, but we suggest that you accelerate the domain name following the redirect, because it is not necessary to accelerate domain names before the redirect.

What types of acceleration does Azure Content Delivery Network support?

Acceleration types supported by Azure Content Delivery Network include web acceleration, Video on Demand (VoD) acceleration, live streaming media (direct broadcast) acceleration, and HTTPS acceleration.

Currently, Content Delivery Network principally provides static acceleration, but it also includes some dynamic acceleration technologies. Examples include returning to source by using multiline nodes and Transmission Control Protocol (TCP) optimization. Active webpage acceleration techniques such as PHP, ASP.NET, and JSP are not supported, but more dynamic page acceleration methods will be gradually added in the future.

What are the specific differences between the web acceleration, VoD acceleration, live-streaming media acceleration, and HTTPS acceleration in the Content Delivery Network acceleration type options?

The various Content Delivery Network acceleration types correspond to different usage scenarios:

  1. Web acceleration is for accelerating relatively small, static files such as webpages (HTML, CSS, images, or JS).

  2. Download acceleration is generally for distributing large files of more than 20 MB in size.

  3. VoD acceleration is for HTTP-based VoD.

  4. Live streaming media acceleration is for live streaming media (direct broadcast).

  5. HTTPS acceleration is for situations with relatively high security requirements and is principally intended for use with smaller types of files.

The differences in terms of how these acceleration types work with the Content Delivery Network backend is mainly that each type is powered by different network node equipment. But you do not need to perform any additional configuration.

What are the default cache rules for Azure Content Delivery Network?

  • The system’s default cache rules for web acceleration are:

    1. Dynamic files, such as those with the extensions PHP, ASPX, ASP, JSP, DO, DWR, CGI, FCGI, ACTION, ASHX, AXD, and JSON—are not cached.
    2. Files with the extensions SHTML, HTML, HTM, and JS are cached for half a day (720 minutes) by default.
    3. All other static files are cached for one day (1,440 minutes) by default.
  • The system’s default cache rules for download acceleration are:

    1. Dynamic files, such as those with the extensions PHP, ASPX, ASP, JSP, and DO—are not cached.
    2. Files with the extensions 7Z, APK, WDF, CAB, DHP, EXE, FLV, GZ, IPA, ISO, MPK, MPQ, PBCV, PXL, QNP, R00, RAR, XY, XY2, ZIP, and CAB are cached for one month.
  • The system’s default cache rules for VoD acceleration are:

    1. Dynamic files, such as those with the extensions PHP, ASPX, ASP, JSP, and DO—are not cached.
    2. MP3 and WMA files are cached for one day.
    3. Audio files such as .mp3 and .wma files—are cached for one day.
    4. Files with the extensions 7Z, APK, WDF, CAB, DHP, EXE, FLV, GZ, IPA, ISO, MPK, MPQ, PBCV, PXL, QNP, R00, RAR, XY, XY2, ZIP, and CAB are cached for one month.
  • The system’s default cache rules for live streaming media acceleration are:

    1. TS files are cached for two minutes.
    2. M3U8 files are cached for two seconds.

Cache rule logic:

  1. If you configure no-cache rules, then matches are assigned in order of priority. However, because matching also requires cache rules, the cache rules are matched from high to low.

  2. If a particular URL is not matched in either the cache or no-cache rules, the Content Delivery Network’s default rules will be followed.

What is the maximum duration for file caching at a Content Delivery Network node?

The maximum duration for file caching at a Content Delivery Network node is set according to your cache rules, and the system sets no limit for the duration.

How long does it take to synchronize the cache rules and to synchronize the cache files at a Content Delivery Network node?

After you set your cache rules, it takes about 10 min to issue them. The synchronization time for the cache rules at a Content Delivery Network node depends on the set cache rules and the file size.

How can the newly submitted URL be enabled to provide the effect of advance caching?

Content Delivery Network does not cache files actively, unless you so request. Some nodes without requests from users will always have no cache. To let the newly submitted URL provide the effect of advanced caching, we suggest that you use the “Content Prefetch” feature on the Azure CDN management interface.

Can cache rules be configured for wildcard domain names?

Can cache rules be configured for wildcard domain names? If you have created a wildcard domain name, the cache rules will be set up under the wildcard domain name. To help simplify the process, wildcard domain names are mainly used for multiple domain names with the same configuration. They can be created at the same time as real domain names, with the configuration for the real domain name taking priority for matching. For example, if the rule for a1.example.com is different, you can create a new endpoint for a1.example.com and create cache rules there. In this situation, the configuration there would have priority over the configuration for *.example.com.

Are cache refresh operations supported if the custom domain name is a wildcard domain name?

If the custom domain name is a wildcard domain name, the refresh URL must specify the subdomain when the cache refresh is submitted. For example, if the custom domain name is *.domain.com and the customer wants to refresh content under img.domain.com, the subdomain img.domain.com should be specified to perform the cache refresh operation.

Can wildcard domain names be used with preloading?

Preloading requires a subdomain, and it must be possible to access the URL normally. The status code is 200.

What is the difference between “source station address (back-to-source address)” and “back-to-source domain name (back-to-source host header)”?

The back-to-source address indicates the actual, accessible address of the source station, which may be an IP address or a domain name. If it's a domain name, Content Delivery Network, during the return to source, will resolve the address for the domain name and then access it via the resolved IP.

The back-to-source domain name indicates the host field value in the HTTP request header when Content Delivery Network returns to source. This field value is generally a character string in the form of a domain name. The source station uses this domain name to identify whether it is the same as the domain name that was configured on the source station.

If I use Content Delivery Network acceleration with a blob, do I directly use the blob address, rather than the custom domain name? Do I need to apply for filing and, if so, why?

Content Delivery Network is basically a group of network content caching nodes and is not equivalent to a your source station. The caching nodes only incorporate only the content that you have set up for caching, and even this might expire.

The purpose of custom domain names is that they can be given a CNAME so that the source station cache hit is directly returned when source website content is accessed via Content Delivery Network by using the custom domain name. Otherwise, it might be returned to source. This is the principle of Content Delivery Network.

If the custom domain name and the origin domain name were the same, the results would be:

  1. A back-to-source failure because the acceleration node would be accessed again via DNS instead of the source station when returning to source.
  2. An access failure because part of the source station content might not be on the acceleration nodes.

The law stipulates that custom domain names are subject to ICP record filing, but there are no requirements for source stations. However, if the second-level domain name for the custom domain name itself has already been filed, it is not necessary to file another application.

Is the gzip feature for HTTP headers supported?

If Azure Content Delivery Network is required to support the gzip feature of an HTTP header, you must submit a work order to activate such a function. When you submit the work order, provide the acceleration domain name, the source station domain name, and the type of file that needs to be accelerated.

If there are multiple subscriptions, how do I switch between them?

If you have multiple subscriptions, as shown in the diagram, you can select the down arrow in the Subscription ID area at the top right of the Azure portal website to select a suitable subscription ID.

FAQs

When an Azure account expires, how do I transfer Content Delivery Network to another account?

The automatic transfer of domain names between subscriptions is currently not supported. You must conduct the transfer manually. To do so, first delete any existing domain names from expired subscriptions, and then re-create the domain names in the new subscriptions. Those domain names will be reviewed again.

Is there a limit to the number of accelerated domain names I can add to a single account?

Azure Content Delivery Network has no limit on the number of accelerated domain names that you can add to each account.

Monthly 95th Percentile Bandwidth Peak Billing

The billing period for monthly 95th percentile billing is a calendar month. In a calendar month, the effective bandwidth for a subscription account that requires bandwidth billing are sorted in descending order down to the nearest 5 minutes. The top 5% of the bandwidth values are then removed. The highest maximum bandwidth value left is then used as the billing value for that month’s 95th percentile bandwidth peak billing. If we take a 30-day month as an example, the default is always a valid bandwidth value point. As a bandwidth value is taken every 5 minutes, 12 points are taken every hour, and 8,640 (12 × 24 × 30) points are taken each month. If all these points are arranged in descending order by bandwidth and the top 5% are removed, as 8,640 × 5% = 432 points, the 433rd point is the billing point.

What is the relationship between Content Delivery Network flow and back-to-source flow?

  • Content Delivery Network traffic indicates cache hits.

  • Back-to-source traffic indicates the missed portion.

What is the difference between log traffic and paid traffic?

The amount of network traffic data generated by CDN-accelerated domain names is 7–15% higher than the amount of log traffic data. This difference occurs because log traffic data is counted as application-level traffic. The Internet transmission process not only includes app log traffic, but also additional network usage caused by TCP/IP headers and TCP retransmission.

  • TCP/IP header usage: Internet data packets based on the HTTP protocol are 1,500 bytes long, including the 40-character headers for the TCP and IP protocols. Traffic generated by headers cannot be counted at the application level, so only 1,460 bytes of traffic are recorded in application-level logs. For this reason, packet headers account for 2.74% (40/1,460) of application-level log traffic, so there is a data error of around 3%.
  • TCP retransmission: Fluctuations in Internet networks cause around 3–10% of data packets to be discarded by the Internet. However, servers retransmit these lost data packets using the TCP protocol’s retransmission mechanism. Retransmitted data traffic is also not counted by the application layer.