How are the bandwidth statistics in access monitoring collected?
Each CDN node collects traffic data in real time and reports it to the computing center, which aggregates the data into total traffic data and displays the bandwidth statistics by dividing the total traffic by the duration of use.
Example:
If the total traffic generated in a minute is 6 MB, then the corresponding bandwidth is (6 * 8) / 60 = 0.8 Mbps.
As the usage for bill-by-bandwidth is calculated based on the statistics at the 5-minute granularity, the corresponding bandwidth value is total traffic in 5 minutes / 300 seconds.
The traffic counted based on the downstream bytes in the log of an acceleration domain name is limited to the data at the application layer, while the traffic generated by actual data transfers over the network is around 5-15% more than application-layer traffic.
Consumption by TCP/IP headers: in TCP/IP-based HTTP requests, each packet has a maximum size of 1,500 bytes and includes TCP and IP headers of 40 bytes, which generate traffic during transfer but cannot be counted by the application layer. The overhead of this part is around 3%.
TCP retransmission: during normal data transfer over the network, around 3-10% of packets are lost on the internet and retransmitted by the server. This type of traffic cannot be counted by the application layer, which accounts for 3-7% of the total traffic.
As an industry standard, the billable traffic is the sum of the application-layer traffic and the overheads described above. Tencent Cloud CDN takes 10% as the overheads proportion, so the monitored traffic is around 110% of the logged traffic.
How do I calculate the traffic hit rate?
By default, CDN enables L2 cache (edge layer and intermediate layer). As long as a request hits either layer for response, it will be counted as a CDN node hit.
Traffic hit rate = (total downstream traffic - origin-pull traffic) / total downstream traffic.
How do I fix the problem of low traffic hit rate?
Check whether the cache is purged: cache purge clears the specified content on the node, leading to a temporarily low traffic hit rate.
Check whether new resources have been put onto the origin server: high numbers of new resources may cause origin-pulls by CDN nodes, leading to a low traffic hit rate.
Check whether the origin server works properly: if it is malfunctioning with multiple 4XX or 5XX errors, the traffic hit rate will be affected.
Check whether the cache validity is correctly configured: check the cache validity configuration on the Cache Configuration tab in the console. The rules are displayed in ascending order by priority, i.e., a rule takes precedence over the one above it.
Check whether Range GETs is enabled: check the Range GETs configuration on the Origin-pull Configuration tab in the console. If it is disabled, files will be pulled in their entirety instead of multiple parts as requested during origin-pull, which increases the origin-pull traffic and lowers the hit rate.
Check whether Ignore Query String is enabled: check the Ignore Query String on the Access Control tab in the console. If it is disabled, caching will be performed based on the full path. In this case, if the same resource is requested by different parameters, it cannot be matched and will be cached multiple times, lowering the traffic hit rate.
Do status code statistics include all status codes?
Yes. In the new version of CDN statistical analysis, monitoring curves are drawn for all status codes generated by origin servers, making it easier for you to troubleshoot.
How are district and ISP statistics calculated?
The district and ISP statistics are calculated based on the client IPs in the access log. As the calculation is completed based on the log, the simply accumulated billable data differs from the billable data when "all districts" or "all ISPs" is selected. For more information, please see the question 2 above.
How is CDN origin-pull traffic generated?
CDN origin-pull traffic is generated during the following three situations:
1. The requested resource is not cached on the CDN node and is pulled from the origin server.
2. The manually purged origin server is synced with the node.
3. The origin server is automatically purged.
What should I do if my CDN traffic has an exception or is under DDoS or CC attacks?
If you think the number of access requests to your business is moderate, you can download the access logs, and based on which to configure the access limits. CDN does not know your business logic, so no access limits are set for your business by default. Please configure as required by your business.
To avoid malicious requests or CC/DDoS attacks to your website, we strongly recommended you complete the following configurations:
1. Hotlink protection configuration: you can control the access to your business resources. By setting an access control policy on the value of the referer field in the HTTP request header, you can restrict the access source to prevent hotlinking by malicious users. For more information, please see Hotlink Protection Configuration. 2. IP blocklist/allowlist configuration: you can create filtering policies for source IPs of user requests based on your business needs, helping prevent hotlinking and attacks from malicious IPs. For more information, please see IP Blocklist/Allowlist Configuration. 3. IP access limit configuration: you can defend against CC attacks by limiting the number of access requests per second to a node allowed for a client IP. After the configuration is enabled, a 514 error will be returned for requests that exceed the QPS limit. Setting a lower frequency limit may affect the usage of your business by normal high-frequency users. Therefore, please set the threshold according to your actual business conditions and usage. For more information, please see IP Access Limit Configuration. 4. Bandwidth cap configuration: you can configure a bandwidth cap for a domain name. When the bandwidth consumed by the domain name exceeds this cap within a statistical cycle (5 minutes), all access requests will be forwarded to the origin server or the CDN service will be disabled depending on your configuration (in both cases, a 404 error will be returned for all access requests). For more information, please see Bandwidth Cap Configuration.
Is there a delay in using APIs to query data? How long is it?
There is a certain delay in using APIs to query data. Queries of real-time data such as access data and billing data have a delay of around 5-10 minutes, while queries of analytical data such as rankings will have delays of approximately half an hour. The data is calibrated on the backend at around 3 am Beijing Time.