DEV Community: Alvin

What Actually Happens When You Put a CDN in Front of Your Website?

Alvin — Wed, 12 Aug 2026 03:26:53 +0000

If you've worked on web performance for any amount of time, you've probably heard the advice:

“Put it behind a CDN.”

But what does a CDN actually do between the browser and your server?

The simplest way I think about it is this:

A CDN, or Content Delivery Network, is a distributed network of edge servers that delivers content from locations closer to users instead of sending every request back to one origin server.

That shorter path can reduce latency, speed up content delivery, reduce load on the origin, and make an application more resilient when traffic increases.

But the interesting part is what happens after a user hits your URL.

A request without a CDN

Imagine your application is hosted on an origin server in the United States.

A user in Singapore opens your website.

Without a CDN, requests for HTML, JavaScript, CSS, images, downloads, or other resources may have to travel all the way to your origin infrastructure and back.

Conceptually:

User in Singapore
       ↓
Internet
       ↓
Origin server in the US
       ↓
Internet
       ↓
User

That physical and network distance matters.

More distance generally means more network hops and more round trips, which can translate into additional latency.

Now put a CDN in between.

User
  ↓
Nearby CDN edge server
  ↓
Origin server (only when needed)

The CDN becomes a delivery layer between users and your origin.

So how does a CDN decide where requests go?

CDNs operate distributed edge servers across multiple geographic locations.

When a request comes in, technologies such as DNS-based routing, Anycast, and global traffic management can help direct that request toward an appropriate edge location.

Then the edge checks whether it can serve the content itself.

This is where caching becomes important.

Cache hit vs. cache miss

Two terms explain a large part of basic CDN behavior.

Cache hit

A cache hit means the requested resource is already stored on the edge server.

For example:

GET /images/product.png

If that image is already cached at a nearby edge location, the CDN can send it directly to the user.

The origin doesn't need to handle that request.

Cache miss

A cache miss means the requested content isn't currently available in that edge cache.

The CDN requests the resource from the origin, returns it to the user, and—depending on your cache rules—may store a copy for future requests.

So the flow becomes:

First request:
User → Edge → Origin → Edge → User

Later request:
User → Edge → User

This is one of the main reasons CDNs can reduce origin traffic as well as latency.

What controls how long something stays cached?

One important setting is TTL, or Time to Live.

TTL determines how long a cached resource can remain at the edge before it expires.

Assets that rarely change—such as logos, versioned JavaScript bundles, CSS, fonts, or software files—can often use longer cache durations.

Frequently changing resources may need shorter TTLs.

And if something needs to disappear from cache immediately, CDNs typically provide a cache purge mechanism.

This sounds simple, but cache policy can have a huge impact on CDN performance.

A CDN isn't just “cache everything forever.”

The real goal is deciding:

what can be cached;
where it should be cached;
how long it should stay cached;
and when it needs to be refreshed.

What about dynamic content?

This is where the idea that “CDNs are just caches” starts to break down.

Not everything can be cached.

API responses, authenticated pages, personalized content, shopping carts, and other dynamic requests may need to reach the origin.

A modern CDN can still help.

Even when a response isn't served from cache, CDN infrastructure can optimize the network path through techniques such as persistent connections, TCP/TLS optimization, dynamic acceleration, and newer protocols such as HTTP/2, HTTP/3, and QUIC.

So there are really two related ideas:

Caching reduces how often the origin is needed.

Network acceleration makes requests faster when the origin is needed.

Does a CDN replace web hosting?

No.

This is a distinction that sometimes gets lost.

Web hosting stores and runs your website or application. A CDN sits between users and that origin infrastructure to improve how content is delivered.

You still need an origin.

Think of it roughly like this:

	Web Hosting	CDN
Main job	Host the application/content	Deliver and accelerate content
Location	Origin infrastructure	Distributed edge locations
Handles	Original application and files	Cached and accelerated requests
Goal	Run the site	Get content to users efficiently

A CDN complements your hosting architecture rather than replacing it.

Do you actually need a CDN?

Not every side project needs an enterprise CDN setup.

But I'd start seriously considering one when:

users are distributed across multiple countries or regions;
performance varies significantly by geography;
your application serves lots of images, video, JavaScript, downloads, or other large assets;
your origin is handling a high volume of repeat requests;
traffic spikes are becoming difficult to manage;
availability and DDoS protection matter to the application.

The more geographically distributed your audience becomes, the more useful the edge model tends to become.

A CDN is also part of your reliability and security architecture

Performance gets most of the attention, but CDNs can do more than make pages load faster.

Because traffic passes through the CDN before reaching the origin, that network layer can also help with traffic distribution, origin protection, DDoS mitigation, web application security, and handling sudden spikes.

That makes the CDN an important infrastructure decision—not just a frontend optimization.

The short version

If I had to summarize CDN architecture in a few lines:

A CDN puts distributed edge infrastructure between users and your origin.

It can:

route users toward an appropriate edge location;
serve cached content without contacting the origin;
retrieve and cache content when there's a cache miss;
accelerate dynamic traffic that still needs the origin;
reduce origin load;
improve performance, scalability, reliability, and security.

Once you see the request flow, “use a CDN” stops feeling like a magic performance trick.

It's really a question of moving content and network processing closer to the people requesting it.

If you want a deeper breakdown of CDN caching, edge servers, common use cases, and how to evaluate a CDN provider, I found this more comprehensive guide useful:

What Is a CDN? — CDNetworks

Quick FAQ

What does CDN stand for?
CDN stands for Content Delivery Network.

What is a CDN in simple terms?
It's a distributed network of servers that helps deliver web content from locations closer to users.

Does a CDN host my website?
Not usually. Your hosting infrastructure remains the origin; the CDN works in front of it.

Can a CDN accelerate APIs?
Yes. Even when API responses aren't cached, CDNs can improve delivery through optimized routing and connection acceleration.

Is CDN caching the same as browser caching?
No. Browser caching stores content on an individual user's device, while CDN caching stores content at shared edge servers that can serve many users.

What 2025 Attack Traffic Means for Developers and Security Teams

Alvin — Thu, 06 Aug 2026 03:37:56 +0000

Security reports often lead with large numbers.

Billions of malicious requests. Terabit-scale DDoS attacks. Millions of automated bot requests every day.

The numbers matter, but the more useful question for developers is this:

What do these traffic patterns reveal about how applications are being attacked?

Based on traffic observed and mitigated by CDNetworks during 2025, one pattern stands out. Many attacks are designed to resemble legitimate activity.

They use standard protocols, expected application paths, authenticated sessions, and technically valid API requests. Detecting them requires more than matching signatures or blocking unusual IP addresses.

Here are four signals engineering and security teams should pay attention to.

1. DDoS Protection Must Cover More Than Bandwidth

CDNetworks blocked more than 227 million network-layer DDoS attack requests in 2025.

Among them:

329 attacks exceeded 1 Tbps
The largest attack reached 1.55 Tbps
Software and IT Services was the most targeted sector for network-layer DDoS attacks

Terabit-scale attacks are becoming a repeatable operational scenario.

However, network capacity represents only part of the problem.

Application-layer DDoS attacks can target expensive operations such as:

Login and authentication
Search
Checkout
Dynamic content generation
API requests
Database-intensive queries

A relatively small HTTP request can trigger several backend operations. Enough requests to a resource-intensive endpoint may degrade an application without saturating the network.

For engineering teams, DDoS testing should therefore examine application dependencies, worker pools, database capacity, caching behavior, and third-party services, alongside bandwidth.

2. Web Attacks Require End-to-End Request Visibility

CDNetworks blocked more than 21.51 billion web application attack requests during 2025.

Almost 60% occurred during the second half of the year, while HTTP protocol anomalies accounted for 45% of the total.

Modern application requests often travel through several components:

Client
  ↓
CDN or security edge
  ↓
Load balancer
  ↓
Reverse proxy or API gateway
  ↓
Application server
  ↓
Database and internal services

Each component may interpret malformed headers, encodings, request lengths, or protocol behavior differently.

This creates opportunities for attackers to test inconsistencies between systems.

Edge logs alone may not provide enough context. Teams should be able to connect a suspicious request with:

The targeted endpoint
Authentication status
Session history
Application response
Upstream latency
Backend errors
Related requests from the same identity or device

Consistent request IDs across the delivery path make this investigation significantly easier.

3. Bot Management Is a Policy Problem

In 2025, 74% of classified bot traffic came from bad bots.

CDNetworks also observed an average of 1.64 million AI bot requests per day, with data scrapers accounting for more than 72% of recorded AI bot activity.

The technical challenge is that automated traffic can serve very different purposes.

A bot may be:

A search crawler
A monitoring service
An AI agent
A commercial scraper
A credential-stuffing tool
An inventory-hoarding bot
An account-abuse system

Blocking all automation would disrupt legitimate services. Allowing all automation would expose applications, data, accounts, and infrastructure resources.

Bot policies should therefore reflect the purpose of each endpoint.

For example:

routes:
  /public-docs:
    verified-crawlers: allow
    unknown-bots: rate-limit

  /account:
    crawlers: block
    suspicious-automation: challenge

  /api/inventory:
    authentication: required
    behavioral-monitoring: enabled

The exact syntax depends on the security platform, but the underlying principle remains the same. Public content, account systems, APIs, and transactional workflows should not share one universal bot policy.

4. API Abuse Can Look Technically Valid

CDNetworks blocked an average of more than 15 billion malicious API requests per month during 2025.

API attacks can be difficult to identify because individual requests may appear legitimate.

A malicious request may:

Use valid JSON
Match the expected schema
Include a valid token
Target a documented endpoint
Stay below an IP rate limit
Receive a successful response

The risk appears when the request is connected to behavior over time.

Consider an authenticated user querying an inventory API. One request may be expected. Thousands of queries distributed across several accounts, devices, and IP addresses may indicate scraping or automated purchasing activity.

Traditional IP-based rate limiting may miss this pattern.

Sensitive APIs should also evaluate:

account_id
api_key
session_id
device_id
organization_id
endpoint
resource_id
action_frequency
historical_behavior

Security controls need to measure both request volume and business impact.

Examples include the number of accounts created, coupons redeemed, items reserved, records accessed, or payment methods tested.

The Shared Engineering Challenge

DDoS attacks, web attacks, bots, and API abuse affect different parts of the technology stack, but they reveal the same challenge:

Attack traffic often uses legitimate-looking behavior.

This makes context essential.

Security teams need infrastructure data, while developers understand application workflows. Platform teams understand dependencies, while identity teams understand users, sessions, and permissions.

These signals become more valuable when they are connected.

What Teams Should Review

Based on the 2025 traffic patterns, engineering and security teams should review five areas:

Expensive endpoints
Identify requests that consume substantial compute, database, or third-party resources.
Cross-layer observability
Connect edge, application, API, identity, and backend telemetry.
Identity-aware limits
Apply controls across accounts, tokens, sessions, devices, and organizations, rather than relying solely on IP addresses.
Endpoint-specific bot policies
Define which automated agents can access each application workflow.
Long-term behavioral analysis
Look for attack activity developing over days or weeks, as well as sudden traffic spikes.

Final Thought

Blocking malicious requests remains necessary, but request-level inspection alone cannot explain every attack.

Developers and security teams also need to understand who is performing an action, how the behavior changes over time, which resources are affected, and whether the outcome aligns with expected business use.

That context is becoming a core part of application resilience.

The figures in this article are drawn from the 2025 CDNetworks State of Web Application and API Protection Report and reflect traffic observed and mitigated by the CDNetworks security platform during 2025.

Best CDN for Live Streaming in 2026: A Developer’s Guide to Choosing the Right Provider

Alvin — Fri, 31 Jul 2026 02:33:03 +0000

TL;DR

A live streaming CDN improves video delivery by serving content from edge servers closer to viewers.
The best CDN depends on your audience location, latency requirements, streaming protocols, and operational needs.
CDNetworks is a strong choice for global live streaming, especially when Asia-Pacific performance and ultra-low latency matter.
Akamai excels at large-scale enterprise broadcasting with a mature global network.
Cloudflare, Fastly, and AWS each offer advantages for specific deployment models and development workflows.

What you'll learn

What a live streaming CDN does and why it matters
How a CDN improves streaming performance
How I evaluated the top CDN providers
A side-by-side comparison of five leading live streaming CDNs
A practical framework for choosing the right CDN for your streaming platform

What is a live streaming CDN?

A live streaming CDN (Content Delivery Network) is a distributed network of edge servers that delivers live video from locations closer to viewers instead of relying on a single origin server.

Instead of sending every request back to the origin, the CDN replicates and distributes the live stream across multiple edge locations. Viewers connect to the nearest edge server, reducing network distance and improving playback quality.

Live streaming CDNs are commonly used for:

Sports broadcasts
OTT streaming platforms
Live commerce
Online education
Enterprise events
Gaming and esports

Why Live Streaming Needs a CDN

A live streaming CDN improves video delivery by distributing content through geographically distributed edge servers instead of forcing every viewer to connect directly to a centralized origin server.

When thousands or even millions of viewers join a live event, sending every request to a single origin server can quickly become a bottleneck. A CDN solves this problem by spreading traffic across multiple edge locations (also known as Points of Presence or PoPs), allowing viewers to receive video content from a server closer to their location.

                     Broadcaster
                         |
                         |
                    Origin Server
                         |
                         |
                 CDN Edge Network
                         |
        ┌────────────────┼────────────────┐
      US PoP           EU PoP          Asia PoP
        |                |                |
     Viewer A         Viewer B         Viewer C

This distributed architecture helps reduce delivery latency, minimize buffering, improve stream reliability, and support large-scale audiences across different regions.

Common use cases

Live streaming CDNs are widely used for scenarios that require high-quality video delivery, global reach, and the ability to handle sudden spikes in audience traffic.

Sports and esports broadcasting
OTT and media streaming platforms
Live commerce
Virtual classrooms
Enterprise live events
Gaming livestreams

How I evaluated the best live streaming CDNs

No CDN is the best choice for every streaming platform.

Instead of focusing on marketing claims, I evaluated providers using the technical characteristics that have the greatest impact on production live streaming.

The evaluation focused on six areas.

Evaluation Criteria	Why It Matters
Global edge network	Reduces latency by serving viewers from nearby locations
Live streaming performance	Improves playback quality, startup time, and latency
Scalability	Handles sudden traffic spikes during live events
Origin offload	Reduces origin bandwidth costs and improves reliability
Security & availability	Protects against DDoS attacks and service disruptions
Integration	Simplifies deployment with modern streaming protocols and APIs

I also considered compatibility with common streaming technologies, including:

RTMP
FLV
HLS
DASH
WebRTC
SRT
CMAF
QUIC

5 best CDN providers for live streaming

Many CDN providers support live video delivery, but only a handful consistently provide the combination of low latency, scalability, and operational reliability required for production streaming.

Here's how the 5 leading CDN providers compare.

Quick recommendations

Choose the provider that best matches your priorities.

CDNetworks — Best for global streaming with strong Asia-Pacific performance and ultra-low latency.
Akamai — Best for enterprise broadcasters operating at global scale.
Cloudflare — Best for developer-focused streaming platforms.
Fastly — Best for programmable edge delivery and low-latency HTTP streaming.
AWS — Best for teams already building on AWS services.

Comparison of best CDN for live streaming

Provider	Global Coverage	Best For	Streaming Protocols	Indicative Latency*	Security	Scalability
CDNetworks	3,000+ PoPs in 90+ countries	OTT, gaming, media, live commerce	RTMP, FLV, HLS, DASH, SRT, CMAF, WebRTC, QUIC	<500 ms (WebRTC)	DDoS, WAF, Bot Management, API Security	200+ Tbps
Akamai	Extensive global network	Enterprise media delivery	HLS, DASH, CMAF	2–5 s	DDoS, WAF, API Security, Zero Trust	Enterprise scale
Cloudflare	Large global edge network	Interactive streaming and developer platforms	HLS, LL-HLS, WebRTC	<1 s (WebRTC Beta)	DDoS, WAF, Zero Trust	Highly scalable
Fastly	Global edge network	Real-time streaming	HLS, DASH, CMAF	2–4 s	DDoS, WAF	High-performance edge
AWS	AWS global infrastructure	AWS-native streaming	HLS, DASH, CMAF	3–6 s	AWS Shield, AWS WAF	Elastic AWS scaling

Latency figures are indicative and depend on protocol selection, encoder settings, player buffering, network conditions, and overall streaming architecture. WebRTC deployments typically achieve sub-second latency, while LL-HLS workflows generally operate in the multi-second range.

Why choose CDNetworks for live streaming?

CDNetworks is a strong option for organizations that need reliable global delivery while maintaining excellent performance in Asia-Pacific.

Its combination of network coverage, protocol support, media services, and integrated security makes it suitable for:

OTT platforms
Live commerce
Sports broadcasting
Gaming
Online education
Enterprise streaming

Pros

3,000+ PoPs across 90+ countries
200+ Tbps network capacity
Strong Asia-Pacific and Mainland China optimization
Supports RTMP, FLV, HLS, DASH, SRT, CMAF, WebRTC, and QUIC
WebRTC streaming with glass-to-glass latency below 500 ms
Flexible ingest and Player SDKs
4K-ready cloud transcoding
Live recording and real-time screenshot services
Built-in DDoS protection, WAF, and access control

Considerations

Advanced media capabilities are primarily designed for enterprise deployments.
Smaller streaming projects may not need the full breadth of the platform.

Why choose Akamai for enterprise streaming?

Akamai is best suited for organizations running large-scale broadcasts where reliability is more important than minimizing operational complexity.

Pros

Extensive global edge infrastructure
Supports HLS, DASH, CMAF, and Low-Latency HLS
Mature enterprise security stack
Proven performance during high-profile live events

Considerations

Premium pricing
More operational overhead than lightweight CDN platforms

Why choose Cloudflare for developer-focused streaming?

Cloudflare combines CDN delivery, networking, and security into a unified platform, making it attractive for engineering teams building modern applications.

Pros

Large global network
Supports HLS, LL-HLS, and WebRTC
Built-in DDoS protection, WAF, bot management, and Zero Trust
Developer-friendly APIs

Considerations

Video delivery is not as specialized as providers focused primarily on streaming.
Some advanced streaming capabilities require additional Cloudflare services.

Why choose Fastly for low-latency HTTP streaming?

Fastly focuses on real-time content delivery with a programmable edge platform.

If your application requires fast cache updates and customizable request handling, Fastly is worth considering.

Pros

Low-latency delivery
Supports HLS, DASH, and CMAF
Programmable edge platform
Fast cache invalidation

Considerations

Smaller network footprint than some competitors
Edge programming features are most valuable for teams with in-house engineering expertise

Why choose AWS for AWS-native streaming?

AWS is a natural fit for organizations already running their infrastructure on AWS.

It integrates closely with Amazon S3, AWS Elemental Media Services, AWS Shield, and AWS WAF.

Pros

Global AWS infrastructure
Supports HLS, DASH, and CMAF
Tight integration with AWS media services
Elastic scaling

Considerations

Building a complete streaming workflow usually involves multiple AWS services.
Pricing and architecture can become complex at scale.

How do you choose the right live streaming CDN?

The right CDN depends on your workload rather than the longest feature list.

Here's the evaluation process I'd recommend.

1. Define your latency requirements

Start by identifying your application.

Interactive applications such as gaming, live commerce, auctions, and video calls typically require sub-second latency, making WebRTC a strong candidate.

Traditional OTT streaming usually prioritizes scalability and playback quality over the lowest possible latency.

2. Know where your viewers are

Audience location directly affects CDN performance.

If most viewers are concentrated in a particular region, prioritize providers with strong regional coverage.

For global audiences, choose a provider with broad geographic reach.

For Asia-Pacific users, evaluate regional routing performance in addition to overall network size.

3. Verify protocol compatibility

Your CDN should support the protocols used throughout your streaming workflow.

Common protocols include:

HLS
DASH
RTMP
WebRTC
LL-HLS
CMAF
SRT

Protocol compatibility can simplify deployment while improving playback across different devices.

4. Consider long-term operations

Streaming reliability depends on more than video delivery.

Evaluate additional capabilities such as:

DDoS protection
WAF
Analytics
Monitoring
APIs
Technical support
Media workflow services

These features become increasingly important as audience size grows.

5. Validate with production-like traffic

Specifications are useful, but real-world testing is more valuable.

Before committing to a provider, benchmark performance using traffic that resembles your production workload.

Measure metrics such as:

Startup time
Time to First Byte (TTFB)
End-to-end latency
Rebuffering rate
Playback stability
Regional performance

Real traffic often reveals differences that product documentation cannot.

What Is RTMP? Understanding RTMP Streaming and Live Ingest

Alvin — Thu, 30 Jul 2026 03:29:45 +0000

Live streaming looks simple from the viewer side: click play and watch.

Behind that experience is a complex pipeline involving encoding, media transport, processing, packaging, and delivery. Among the many protocols involved, RTMP (Real-Time Messaging Protocol) remains one of the most widely supported technologies for live streaming ingest.

Although RTMP is no longer used for browser playback, it continues to play an important role in connecting encoders with streaming platforms.

What Is RTMP?

RTMP is an application-layer protocol designed to transmit audio, video, metadata, and control messages between connected systems.

Originally associated with Adobe Flash streaming, RTMP was historically used for both media transport and playback. However, after Adobe ended Flash Player support on December 31, 2020, modern browsers stopped supporting native RTMP playback.

Today, RTMP is mainly used for live ingest.

A typical streaming workflow looks like this:
Camera or video source → Encoder → RTMP or RTMPS ingest → Media server → Transcoding and packaging → CDN → Viewer

In this architecture, RTMP handles the contribution side of streaming, while protocols such as HLS, DASH, or WebRTC are commonly used for viewer delivery.

This separation explains why RTMP remains relevant in modern streaming systems.

How RTMP Streaming Works

RTMP streaming starts when an encoder establishes a connection with a media server and continuously sends encoded media data.

1. Capture and Encode the Source

The process begins with a video source such as cameras, screen capture systems, gaming devices, and broadcast production systems

The encoder compresses raw audio and video into a stream suitable for transmission.

Important encoding parameters include:

Video codec
Audio codec
Resolution
Frame rate
Bitrate
Keyframe interval

Incorrect encoder settings can cause unstable ingest, processing failures, or playback problems.

2. Establish an RTMP Connection

The encoder connects to an RTMP or RTMPS endpoint provided by the streaming platform.

The workflow typically includes:

RTMP handshake
Connection request
Stream creation
Publishing the live feed

RTMP uses commands such as connect, createStream, and publish to establish and manage the streaming session.

3. Transfer Media Through Messages and Chunks

RTMP transports different types of information through the same connection:

Video data
Audio data
Metadata
Timing information
Control messages

Large messages can be divided into smaller chunks, allowing different data types to be transmitted efficiently over a persistent connection.This design is one reason RTMP became widely adopted in broadcast workflows.

4. Process and Deliver the Stream

After receiving the RTMP stream, the media platform can:

Authenticate the publisher
Transcode into multiple qualities
Generate adaptive bitrate streams
Package content into HLS, DASH, or WebRTC
Apply access controls
Deliver content through a CDN

RTMP handles the upstream contribution workflow, while other technologies handle scalable delivery.

What Is RTMP Ingest?

RTMP ingest is the process of sending a live stream from an encoder to a media platform.

It is the connection point between content production and streaming infrastructure. A typical RTMP ingest workflow:
Encoder → RTMP Ingest Server → Media Processing → Streaming Distribution

RTMP ingest remains popular because of its broad compatibility with:

OBS and other software encoders
Hardware encoders
Broadcast systems
Enterprise streaming platforms

For many organizations, replacing existing RTMP workflows would require significant changes to production infrastructure.

RTMPS: Secure RTMP Streaming

RTMPS is RTMP transmitted over a TLS-encrypted connection.

Unlike standard RTMP, RTMPS protects data while it travels between the encoder and ingest server.

For production environments, RTMPS is generally preferred when supported.

However, transport encryption is only one part of streaming security. A complete security strategy should also include:

Stream key protection
Publisher authentication
Viewer authorization
Digital rights management
Access-control policies

RTMPS improves connection security but does not replace broader content protection strategies.

RTMP vs HLS vs SRT vs WebRTC

Different streaming protocols solve different problems.

Protocol	Primary Role	Typical Connection	Main Strength	Main Consideration
RTMP or RTMPS	Live ingest	Encoder to media server	Broad publishing compatibility	Plain RTMP is unencrypted
HLS	Viewer playback and distribution	Server to player	HTTP-based delivery at scale	Segmenting and buffering affect latency
SRT	Contribution and transport	Source to media infrastructure	Recovery across unpredictable networks	Both endpoints must support SRT
RTSP	Session setup and control	Client and media server	Controls media sessions	Commonly works with separate transport mechanisms
WebRTC	Interactive real-time communication	Browser, application, or peer communication	Real-time browser and application interaction	Scaling and architecture can be more complex

A common modern architecture is:
RTMP → Media Processing → HLS → Viewer

RTMP provides compatibility at ingest, while HLS provides scalable playback.

For interactive applications such as video conferencing or real-time collaboration, WebRTC may be a better choice.

Advantages and Limitations of RTMP

Advantages of RTMP

Mature Ecosystem
RTMP is supported by many existing encoders, production tools, and streaming platforms.

Simple Ingest Workflow
Many organizations already have established RTMP publishing workflows, monitoring systems, and operational processes.

Flexible Media Processing
Platforms can receive RTMP streams and convert them into multiple delivery formats.

Limitations of RTMP

No Encryption Without RTMPS
Standard RTMP does not encrypt traffic.

Not Suitable for Browser Playback
Modern browsers generally require protocols such as HLS, DASH, or WebRTC.

Latency Depends on the Entire Pipeline
RTMP itself does not determine final viewer latency.

Latency depends on:

Encoding configuration
Network conditions
Transcoding
Packaging
CDN delivery
Player buffering

How to Improve RTMP Streaming Reliability

Reliable RTMP streaming depends on the entire workflow, not only the protocol itself.

Key practices include:

Choose a suitable ingest endpoint: Evaluate network stability, routing quality, packet loss, and available upload capacity before production streaming.
Follow encoding requirements: Match the platform’s supported codec settings, bitrate, resolution, frame rate, and keyframe interval to avoid ingest instability.
Use RTMPS when available: Encrypted ingest helps protect media data and connection information during transmission.
Protect publishing credentials: Stream keys should be treated as sensitive credentials. Avoid public exposure, unnecessary sharing, and unused long-lived keys.
Prepare redundancy for critical events: Important broadcasts should consider backup encoders, network connections, power sources, or ingest endpoints.
Monitor the complete delivery pipeline: A successful encoder connection does not guarantee a good viewer experience. Monitor ingest health, processing status, CDN delivery, and playback quality.

How CDNetworks Supports RTMP Ingest and Live Streaming

RTMP remains a widely used ingest protocol because it integrates with established encoders and live streaming workflows.

CDNetworks Media Delivery services support RTMP ingest workflows by connecting RTMP-based publishing with distributed media delivery.

CDNetworks’ Enhanced RTMP/FLV support is designed to:

Maintain compatibility with popular streaming software such as OBS and VLC.
Support a broader range of media formats.
Reduce the need for additional protocol replacement or adaptation.
Support low-latency streaming experiences.
Help providers balance audience experience with streaming costs.

These capabilities allow organizations to continue using existing RTMP workflows while integrating with modern media delivery infrastructure.

Final Thoughts

RTMP is not the newest streaming protocol, but it remains an important part of modern live streaming workflows because of its compatibility and ecosystem maturity.

Modern streaming architectures are not built around one protocol. RTMP, HLS, SRT, and WebRTC each solve different problems across ingest, delivery, contribution, and interaction.

Understanding where RTMP fits is still essential for building reliable and scalable streaming systems.

Cybersecurity in 2026: The Trends Reshaping Modern Applications

Alvin — Fri, 24 Jul 2026 07:13:26 +0000

Cybersecurity in 2026 feels different.

It’s not simply because attacks are becoming more sophisticated or more frequent. What’s changing is where security problems begin. They’re no longer confined to isolated vulnerabilities or network boundaries—they’re increasingly emerging from the applications we build, the APIs we expose, the identities we manage, and the automated systems we rely on every day.

Modern applications have become highly distributed. AI is accelerating development cycles, APIs are powering nearly every digital experience, and machine identities are beginning to outnumber human users. At the same time, attackers are becoming faster, more automated, and increasingly capable of blending malicious behaviors into legitimate traffic patterns.

According to Statista, cybercrime cost businesses approximately $10.5 trillion in 2025 and is projected to reach $15.63 trillion by 2029. Ignoring these changes is becoming significantly more expensive than preparing for them.

Looking ahead to 2026, five cybersecurity trends stand out—not because they’re entirely new, but because they’re fundamentally changing how modern applications need to think about security.

AI Is Industrializing Cyberattacks

AI has become one of the most significant accelerators of cyberattacks. What makes AI particularly interesting isn’t simply its ability to automate existing attack techniques—it’s dramatically changing attacker economics by reducing both the cost and expertise required to launch sophisticated campaigns at scale.

The numbers are beginning to reflect this shift:

FBI IC3 recorded more than 22,000 AI-related complaints and over $893 million in adjusted losses during 2025.
The World Economic Forum reported that 87% of respondents identified AI-related vulnerabilities as the fastest-growing cyber risk throughout 2025.
Deepfakes contributed to nearly 10% of cyberattacks during 2024, with fraud losses ranging from $250,000 to $20 million per incident.

Technical Insight

We’re moving beyond scripted automation into adaptive attack operations. Large language models, agentic AI systems, browser automation frameworks, and proxy networks are enabling attackers to generate increasingly convincing phishing campaigns, automate vulnerability discovery, and launch context-aware social engineering attacks at unprecedented scale.

What’s changing isn’t simply attack volume—it’s attack velocity. AI is significantly shortening the time between discovering vulnerabilities and exploiting them while lowering the technical barriers required to execute sophisticated attacks.

Security Implications

Modern applications will increasingly need to prioritize:

Behavioral-based threat detection over static rule matching.
AI-assisted anomaly analysis and automated response capabilities.
Continuous authentication mechanisms across user and machine identities.
Adaptive security models capable of responding to evolving attack behaviors.

The question is no longer whether attackers will leverage AI—it’s how quickly defenders can adapt to AI-driven threats.

API Security Is Becoming Application Security

Modern applications are increasingly API-first, which also means they’re increasingly API-dependent.

Rapid AI adoption, microservices architectures, and multi-cloud deployments are continuously expanding the application attack surface. APIs that once existed only between internal services are increasingly exposed across partners, platforms, and AI integrations.

According to CybersecAsia, the speed of AI deployment is already exceeding the pace of API security adoption, creating growing concerns around shadow and unmanaged APIs.

According to API security observations published by CDNetworks throughout 2025, authentication bypass accounted for 18.8% of observed API attacks, while privilege escalation represented 12.5% of attack patterns. Low-frequency API attacks persisted for an average of 21.7 days, highlighting how difficult these attacks can be to detect using traditional security controls.

Technical Insight

What’s changing about API attacks is their behavior. Attackers aren’t necessarily generating massive traffic spikes or exploiting well-known vulnerabilities. Increasingly, they’re targeting authorization logic, session management mechanisms, and business workflows themselves.

Low-frequency attacks are particularly challenging because they often resemble legitimate user behaviors, allowing them to remain undetected for extended periods of time.

This is one of the reasons Web Application and API Protection (WAAP) is becoming increasingly strategic in 2026. Traditional WAF capabilities alone are no longer sufficient for protecting modern applications that depend heavily on APIs, automation, and distributed services.

Security Implications

API security is gradually becoming application security. Building secure applications increasingly means understanding:

Who is accessing an API.
Why they’re accessing it.
Whether their behavior aligns with expected business logic.
How APIs interact across distributed services and machine identities.

Continuous API discovery, behavioral baselining, and context-aware authorization will become increasingly important as API ecosystems continue expanding.

Availability Has Become an Architectural Concern

We often discuss cybersecurity through the lens of confidentiality and data protection. Increasingly, however, availability deserves equal attention.

Modern DDoS attacks aren’t necessarily becoming larger—they’re becoming more persistent.

According to technical traffic observations published by CDNetworks, more than 227.37 million network-layer DDoS attack requests were mitigated throughout 2025, with attack volumes remaining elevated for much of the year. CDNetworks also reported that 86% of terabit-scale DDoS incidents observed during 2024 lasted longer than ten minutes, highlighting the growing prevalence of sustained, high-capacity attacks.

Application-layer attacks continue presenting significant challenges as well. During 2025, 67.45% of Layer 7 DDoS attacks observed by CDNetworks were concentrated within the APAC region, reinforcing the importance of regional traffic visibility and application-layer protections.

At the same time, CDNetworks observed that 74% of bot traffic throughout 2025 originated from malicious bots, underscoring the growing need for adaptive bot management capabilities.

Technical Insight

What’s interesting here isn’t simply attack volume—it’s what the data suggests about attacker behavior. We’re increasingly seeing attackers optimize for sustained resource exhaustion rather than short-lived traffic bursts.

Modern attacks frequently combine automated bot traffic, application-layer abuse, and prolonged attack durations to maximize operational impact. Availability challenges are gradually moving beyond networking concerns and becoming application-level challenges.

Why This Matters

Building resilient applications in 2026 increasingly means assuming malicious traffic will coexist alongside legitimate users from day one.
Engineering teams should increasingly consider:
Multi-layer DDoS mitigation strategies.
Regional traffic visibility across globally distributed infrastructures.
Adaptive bot management capabilities.
Edge-based traffic filtering mechanisms.
Application-layer protections designed for modern workloads.

Availability is becoming an architectural concern rather than simply an operational one.

Content Is Becoming a Security Asset

AI crawlers represent one of the more interesting developments emerging across modern applications.

Unlike traditional malicious bots, AI crawlers exist within a much larger gray area. Some provide legitimate value through indexing and retrieval capabilities, while others create significant concerns around content ownership, licensing, attribution, and proprietary data reuse.

According to traffic intelligence published by CDNetworks throughout 2025, AI bot activity accounted for approximately 0.42% of total observed internet traffic, translating to roughly 1.64 million requests per day.
More significantly, 72.67% of observed AI bot activity was associated with content retrieval and data scraping operations.

CDNetworks also observed that OTT platforms accounted for 24% of application-layer DDoS attacks during 2025, followed by Broadcasting and Television at 23% and News and Publishing at 9%. Additionally, CDNetworks helped a licensed video and music content platform mitigate more than 10 million malicious crawler requests per day throughout 2025, highlighting how AI-driven scraping activities can directly affect copyrighted media assets.

Technical Insight

Applications can no longer assume that every visitor is either a human user or a malicious bot. Increasingly, they’ll need to distinguish between search crawlers, AI assistants, retrieval systems, legitimate automation, and malicious scraping activities.

The engineering challenge is no longer simply blocking malicious traffic—it’s making intelligent decisions about automated access.

Security Implications

Content protection is gradually becoming part of modern application security strategies.

Engineering teams should increasingly evaluate:

Bot identity and access intent.
Content sensitivity and business impact.
Usage patterns across automated traffic.
Granular access policies for AI crawlers and legitimate automation.

Modern applications will need to move beyond simple allow-or-block policies toward more intelligent approaches to automated access governance.

Identity Is Replacing the Traditional Perimeter

Perhaps the most significant shift happening across cybersecurity is the growing importance of identity security.

Traditional network perimeters are becoming increasingly difficult to define. Modern applications operate across cloud environments, remote workforces, APIs, and machine identities that extend far beyond conventional boundaries.

Identity is gradually replacing the perimeter itself.

According to Verizon’s 2025 findings, credential abuse accounted for approximately 22% of initial access vectors throughout the year. Meanwhile, APWG recorded 971,181 phishing attacks during Q1 2026, representing a 13.8% increase compared with Q4 2025, while the number of known Phishing-as-a-Service kits doubled throughout 2025.

Google has also highlighted the growing adoption of advanced MFA bypass techniques and increasingly sophisticated social engineering attacks, while deepfake technologies continue challenging traditional assumptions around identity verification.

Technical Insight

Attackers are no longer attempting only to compromise systems—they’re increasingly attempting to impersonate trust itself.

The implications extend far beyond user authentication. Machine identities are expanding rapidly across modern infrastructures, while compromised credentials can trigger automated actions across distributed environments with minimal friction.

Zero Trust Network Access (ZTNA) adoption is accelerating partly because of these changes. As legacy VPN technologies continue reaching end-of-life, organizations are increasingly shifting toward identity-aware access models that provide users with access only to the resources they require while limiting opportunities for lateral movement.

Security Implications

Identity protection in 2026 is becoming less about protecting credentials and more about continuously validating trust.

Modern security architectures should increasingly prioritize:

Zero Trust principles.
Adaptive authentication mechanisms.
Identity threat detection capabilities.
Machine identity governance.
Risk-based access controls across distributed environments.

Identity is becoming as strategic as cloud and network security in modern application architectures.

What Modern Applications Are Teaching Us

Looking across industries, several patterns are beginning to emerge.

E-commerce and retail platforms accounted for 24% of observed bot attacks during 2025, according to CDNetworks’ technical observations. API attacks represented 32% of attacks targeting the industry during 2024, while approximately 22% of major DDoS incidents in late 2025 targeted online retail infrastructures.
Gaming platforms remain particularly vulnerable to availability-related attacks. CDNetworks reported that gaming services experienced 57.38% of observed Layer 3 and Layer 4 attacks alongside 31.32% of Layer 7 attacks during 2024.
Healthcare organizations continue facing substantial ransomware risks, with approximately 40% anticipated to experience attacks during 2026. The average cost of healthcare data breaches is projected to reach $12.6 million.
Financial services remain heavily targeted by both API abuse and identity-related threats. According to CDNetworks, financial services accounted for 23.8% of observed API attacks throughout 2025, while Statista projects average breach costs within the sector will exceed $6.08 million during 2026. Deepfake attacks are accelerating as well, with Axios reporting that 55% of financial organizations experienced incidents during 2025, compared with 43% across other industries.

Although these industries face different challenges, they’re ultimately reinforcing similar lessons—security is moving closer to application architecture itself.

Final Thoughts

Cybersecurity in 2026 isn’t simply about defending against the next vulnerability.

Modern applications are changing faster than traditional security assumptions can keep pace. AI is reshaping attacker capabilities. APIs are continuously expanding application boundaries. Identity is replacing traditional perimeters, while availability and content protection are becoming architectural concerns rather than operational ones.

Perhaps the biggest change isn’t happening within cybersecurity itself—it’s happening within the applications we’re building.

Security is gradually moving closer to product architecture.

Building secure applications in 2026 increasingly means assuming that automation, malicious traffic, machine identities, and adaptive threats are part of the environment from day one. The question is no longer whether modern applications will face these challenges, but whether they’re designed to continuously adapt when they do.

5 Cybersecurity Trends Developers and Tech Leaders Should Watch in 2026

Alvin — Thu, 16 Jul 2026 09:57:40 +0000

Web applications and APIs sit at the center of modern digital services. They handle authentication, payments, search, content delivery, account management, and many of the workflows that developers build and maintain every day.

That also makes them persistent targets.

Each year, CDNetworks analyzes activity observed across our security platform to understand how threats involving web applications, APIs, bots, and digital services are changing.

This article translates five findings from the CDNetworks 2025 State of WAAP Report into practical considerations for developers, application security teams, platform engineers, and SREs.

Methodology note: The figures in this article reflect activity observed across the CDNetworks security platform during 2025. They describe activity within the scope of that platform telemetry and should not be interpreted as measurements of all global internet traffic.

TL;DR

AI is industrializing automated attacks. AI-assisted tools are making attack campaigns more adaptive, scalable, and accessible.
API abuse is becoming a primary path for business logic attacks. Technically valid requests can still produce malicious business outcomes.
AI bot traffic is creating a new governance challenge. Teams need granular policies based on bot identity, purpose, access frequency, and content sensitivity.
Multi-layer DDoS attacks are raising the bar for resilience. Campaigns can shift across network, transport, and application layers within the same attack.
APAC is facing concentrated application-layer attack pressure. APAC businesses are under greater pressure from attacks targeting their business-critical digital services.

Let’s take a closer look at each trend.

1. AI is industrializing automated attacks.

Our latest research shows that AI is changing the economics of cyberattacks.

Large language models, agentic AI tools, browser automation frameworks, and proxy networks are reducing the cost, time, and expertise required to run sophisticated campaigns.

As a result, automated threats are moving beyond rigid scripts toward more adaptive, context-aware, and human-like attack patterns.

This makes AI-driven automation a persistent and expanding threat to digital businesses.

2. API abuse is becoming a primary path for business logic attacks.

APIs have become a primary route to business impact.

In 2025, the CDNetworks security platform blocked more than 15 billion malicious API requests per month on average.

Many attackers are now abusing legitimate functions such as login, registration, search, ordering, and payments, often through valid identities, sessions, and normal request paths.

Because the activity can appear technically valid, business logic attacks are especially difficult to distinguish from genuine customer behavior.

3. AI bot traffic is creating a new governance challenge.

AI bots are automated agents that crawl, retrieve, summarize, or act on online content for AI systems.

In 2025, the CDNetworks security platform observed approximately 1.64 million AI bot requests per day on average.

Data scraping accounted for 72.67% of the observed AI bot activity.

This volume shows that AI bots have become a meaningful part of enterprise internet traffic.

But not all AI bots are harmful. Some support AI search, user-requested retrieval, or model improvement.

Because similar technical behavior can serve very different purposes, simple allow-or-block decisions are often insufficient. Businesses need more granular governance based on bot identity, intent, context, access frequency, content sensitivity, and potential business impact.

4. Multi-layer DDoS attacks are raising the bar for resilience.

Our research shows that DDoS campaigns are becoming more dynamic, with attackers shifting between Layers 3, 4, and 7 within the same campaign and adapting tactics in real time.

A customer case from 2025 illustrates how this trend can play out in practice.

The organization experienced a sustained, multi-day attack that targeted both its network and application layers.

The campaign peaked at:

1.4 Tbps across Layers 3 and 4
770,000 requests per second at Layer 7

CDNetworks mitigated the attack without business disruption.

For business leaders, the implication is clear.

DDoS risk now includes prolonged, multi-layered campaigns that can change tactics over time and pressure several parts of the digital environment at once.

Maintaining availability under these conditions requires adaptive protection and expert mitigation across both network and application layers.

5. APAC is facing concentrated application-layer attack pressure.

APAC accounted for 67.45% of the Layer 7 DDoS activity observed on the CDNetworks security platform in 2025.

The region’s e-commerce, fintech, gaming, SaaS, mobile, entertainment, and digital content sectors depend on high-frequency paths such as login, search, checkout, verification, payments, content access, and API calls.

Those revenue-critical workflows also make APAC businesses attractive targets for disruption, fraud, and abuse.

What Teams Should Prioritize in 2026

Taken together, these trends show how attackers are combining legitimate identities, valid API traffic, automated tools, and business-critical workflows to create operational and security risks.

For development, security, and platform teams, seven priorities stand out:

Protect revenue-critical API workflows, including login, checkout, payments, verification, and account recovery.
Strengthen business continuity and API resilience in APAC markets, where application-layer attack pressure is particularly concentrated.
Prepare for sudden spikes in automated traffic before they affect application availability, backend services, and downstream dependencies.
Reduce exposure from compromised trusted identities, including valid accounts, sessions, API keys, and service credentials.
Control the operational costs of AI-driven attacks, especially when automated requests trigger expensive application or infrastructure processes.
Govern AI bot interactions based on business impact, considering bot identity, purpose, access frequency, and content sensitivity.
Safeguard AI-enabled applications and agentic workflows with scoped permissions, controlled tool access, and stronger oversight of high-impact actions.

These priorities share a common goal: protecting critical digital services without creating unnecessary friction for legitimate users.

Final Thoughts

The emerging security challenge is not limited to blocking requests that look obviously malicious. Teams also need to identify legitimate functionality being used with malicious intent.

The CDNetworks 2025 State of WAAP Report provides the supporting research and additional analysis behind these trends.

👉 Read the full Report

If your team is assessing these risks and needs support from a specialist security provider, visit our website to learn how we help protect web applications, APIs, and digital services.

Disclosure: This article is based on security research and platform data from CDNetworks.