Content Caching

<< Back to Technical Glossary

Content Caching Definition

Content caching is a performance optimization mechanism in which data is delivered from the closest servers for optimal application performance. For example, content from a single server can be copied and distributed across various data centers and clouds. When that content needs to be accessed, the content can be retrieved from any of the cached locations based on geographic location, performance, and bandwidth availability.

Diagram showing client devices communicating with server which communicates with internet. Internet communicates with multiple servers.

Content Caching FAQs

What is Content Caching?

Page load time directly impacts user experience (UX) and conversions. Users can face major delays when loading content if an application or website can only retrieve content from a single origin server. Poor performance often occurs as the server waits for images, videos, text and documents to be retrieved from distant, back-end servers and travel across junctions.

Content caching is a mechanism for optimizing application performance and overcoming this difficulty. Clients can experience much faster response times to follow up requests for documents that were cached.

Data and content from a single server can be duplicated and distributed across multiple clouds and data centers so it can be retrieved by users from the closest servers. Content caching from various locations can be based on geographic location, but also bandwidth availability or performance.

To reduce stress on the origin server and page load time, developers use web browser caches and distributed content caching servers managed by commercial content delivery networks (CDNs). This is called content delivery network caching or CDN caching.

A cache in computing is a high-speed layer for storage of transient data. It allows future requests for the cached data to be served up faster by providing a more optimized storage location. Caching enables users to reuse previously computed or retrieved data efficiently.

Typically, cached data is stored in fast access hardware such as random-access memory (RAM) and may be used with software. The main purpose of a cache is to reduce the need to access the slower storage layer to enhance data retrieval performance.

In contrast to databases which generally retain durable, complete data, caches usually store a subset of data temporarily, trading capacity to gain speed.

Apply content caching on network layers including CDN and DNS, and throughout various layers of technology including databases, operating systems, and web applications. Content caching can significantly improves IOPS and reduce latency for many read-heavy application workloads, such as gaming, Q&A portals, social networking, and other forms of shared content. Cached information may include API requests/responses, computationally intensive calculations, database query results, and web artifacts such as JavaScript, HTML, and image files. Content caching also benefits high-performance computing simulations, recommendation engines and other compute-intensive, data-heavy workloads.

In a distributed computing environment, data can span multiple content caches and be stored in a central location for the benefit of all users.

Example of Content Caching

Amazon subscribers in any location might place a number of demands on their subscription. They will stream their favorite show and demand fast access and minimum buffering time, and shop and expect Prime shipping times in their location, for example. To ensure content caching works, Amazon does things like copy streaming videos from origin servers to caching servers all over the world and moving inventory stocks the same way.

Using the distributed network this way for digital content is pushing content to the edge.

Why Use Content Caching?

There are many reasons to use content caching:

Faster site, application performance. Serves cached content of all kinds and static content at the same speed, reducing latency. Reading data from in-memory cache offers extremely fast data access and improves the overall performance of the website or application. In addition to lower latency, in-memory systems increase read throughput or request rates—formally known as input/output operations per second or IOPS—compared to disk-based databases.

Predictable performance. Spikes in usage are a common challenge. For example, social media apps on election day or during the Super Bowl, or eCommerce websites on Cyber Monday or Black Friday. Increased database load causes higher latencies and unpredictable overall application performance. High throughput in-memory cache helps solve these problems.

Added capacity. Taking repetitive tasks away from your origin servers provides more capacity for applications to serve more users.

Eliminate database hotspots. Small subsets of data create hotspots that are accessed more frequently in many applications—for example a trending product or celebrity profile. Storing the most commonly accessed data in an in-memory cache provides fast and predictable performance while mitigating the need to overprovision.

Availability. Serves up cached content when origin servers fail to protect users from catastrophic errors.

Why is Content Delivery Network (CDN) Caching?

A content delivery network caches videos, images, webpages, and other content in proxy servers. Proxy servers are closer to end users than to receive requests from clients and pass them along to other destinations. CDN dynamic content caching can deliver content more rapidly because the servers are closer to the requesting users.

The CDN reduces response time and increases throughput by using the edge location nearest to the originating request location. A CDN cache hit happens when a user makes a successful request to a cache for content the cache has saved. A cache hit allows for faster loading of content since the CDN can deliver it immediately.

A CDN cache miss happens when the requested content is not saved. A cache miss causes the CDN server to pass the request along to the origin server which responds, and this also allows later requests to result in a cache hit.

There are other kinds of caching. For example, DNS servers cache recent DNS queries so they can instantly reply with domain IP addresses. And search engines may cache websites that are often in SERPs to respond to user queries even when the websites themselves cannot respond.

Does VMware NSX Advanced Load Balancer Offer Content Caching Solutions?

Yes. Vantage can cache content, enabling reduced workloads for both Vantage and servers and faster page load times for clients. When a server sends a response, Vantage can add the object to its cache and serve it to subsequent clients that make the same request. In this way, caching can reduce the number of requests and connections sent to the server.

Enabling content caching and compression allows Vantage to compress text-based objects and store both the original uncompressed and compressed versions in the cache. Vantage serves subsequent client requests that support compression from the cache—greatly reducing the compression workload because there is no need to compress every object every time.

For more on the actual implementation of load balancers, check out our Application Delivery How-To Videos.

Cloud Load Balancing

<< Back to Technical Glossary

Cloud Load Balancing Definition

Cloud load balancing is the process of distributing computing resources and workloads and in a cloud computing environment.

Like other load balancing solutions, cloud load balancing maximizes resource availability and reduces document management system costs. Cloud DNS load balancing also has advantages over traditional load balancing solutions, including ease of scaling to meet demand and, typically, lower cost.

Cloud native load balancing improves service availability and helps prevent downtimes in cloud environments.

This image depicts information passing through software and hardware load balancers to be reached in their final destination to cloud load balancing.


Cloud Load Balancing FAQs

What is Cloud Load Balancing?

Load balancing has a simple aim: prevent individual server instances from becoming overwhelmed with incoming traffic by distributing application traffic across multiple servers. A load balancer shares the load from user traffic across multiple instances of applications to reduce the risk that they will experience performance issues.

Cloud load balancing allocates compute resources and workloads evenly in a cloud environment to ensure that cloud applications achieve greater reliability and efficiency. Enterprises use cloud load balancing to host distributed resources between several application servers, computers, or networks in order to manage client requests effectively.

Cloud load balancing providers optimize available compute resources for an organization while reducing application response time for users as much as possible. In this basic goal, cloud and hybrid cloud load balancing have been very successful.

The more recent cloud era has prompted the evolution of cloud load balancers and cloud load balancing solutions, however. They still play a critical part in application high availability, but cloud based load balancers do much more.

Cloud load balancing solutions may:

  • Automate application rollout
  • Help protect mission-critical applications from security vulnerabilities
  • Integrate with CI/CD processes
  • Lend visibility into application and network health
  • Move workloads across public clouds
  • Offer granular insights into end-user experience
  • Provide elastic scale based on application loads

What is Cloud Load Balancing as a Service (LBaaS)?

Many cloud providers rent load balancing services to customers on an as-needed basis in a process called load balancing-as-a-service (LBaaS). This often takes the place of dedicated on-premise appliances for traffic routing and the need to configure and maintain them in-house, although LBaaS can also use on-premise servers to balance workloads.

LBaaS operates much like traditional load balancing. However, rather than in-house traffic distribution across a cluster of servers in one data center, LBaaS is managed as an on-demand or subscription service in a cloud environment and balances workloads across servers there. Some LBaaS environments are managed by a single cloud vendor, in contrast to hybrid cloud load balancers and multi-cloud balancers that distribute traffic between multiple cloud providers.

There are several benefits to load balancing-as-a-service:

  • Scalability: LBaaS enables users to scale cloud load balancing services easily and rapidly to accommodate spikes in traffic with no need to manually configure additional physical load balancing infrastructure.
  • Reduced costs: Compared to hardware appliances, LBaaS is usually less costly and demands less effort, time, and internal resources to maintain.
  • Availability: Users can guarantee high availability and minimize latency even when a server is down by connecting to the server that is geographically closest.

Cloud Load Balancing Techniques

Cloud server load balancing accelerates performance, maintains application resilience, and guards services and applications in the cloud from unprecedented failures. Here is a closer look at some of the features of cloud load balancing algorithms and how they are used.

Seamless Autoscaling

Cloud load balancing solutions can help users autoscale applications and manage fluctuations in the workload efficiently. As server and cloud application requests decrease, so does resource consumption, and the cloud load balancer achieves its cost-savings goal.

To achieve this, cloud service providers must define an autoscaling policy at the time of set up, so the cloud DNS load balancer allows the auto scaler to react and scale to the detected load.

Support for Multiple Protocols

Cloud load balancing software supports many protocols, including TCP, HTTP/2, and UDP load balancing, because it is specifically curated to serve cloud applications.

Active Health Checks

Cloud DNS load balancers automatically monitor the health of the upstream servers by performing periodic health checks. The cloud load balancer sends specific health check requests and verifies a response for every server in the cloud application. These checks ensure healthy backends for when new connection requests come to the cloud application.

High Performance

Cloud load balancing services ensure even workload distribution in real time, regardless of the traffic or number of requests on the cloud application.

Benefits of Load Balancing in the Cloud

Any organization that offers a range of cloud infrastructures and services hoping to scale needs a cloud load balancing solution to meet more global customer requests. And even without plans for supplementing cloud infrastructure or additional cloud services, workload can increase suddenly at any time. If it does, the cloud application relies on a cloud DNS load balancer to respond to server requests in a timely way.

But when it comes to cloud computing environments, managing network traffic is just part of what software-defined load balancers can do. Here are some of the biggest benefits of using a cloud load balancer.

Easier Automation

Cloud load balancing enables businesses to use predictive analytic tools to identify traffic bottlenecks well in advance. This in turn empowers companies to fuel their decisions with actionable applications insights in near real-time—a process which is critical for automation.

High Performance Applications

More traffic shouldn’t mean poor performance; with the right cloud load balancer service, it won’t. Load balancers maintain performance by distributing the workload at all times.

Seamless Management of Traffic Surges

Single servers can become overburdened by requests during times when cloud-based services have massive workloads to manage. These times are ideal for cloud server load balancing software, which ensures quick response times and high levels of service availability seamlessly in cloud computing environments—and faster than a team of IT professionals trained to counter traffic surges could.


Because cloud load balancers route and distribute traffic evenly among multiple units and servers in the network, even if one node in a chain can’t handle the workload, another active node can handle the load immediately. In other words, cloud load balancing architecture is inherently flexible.

Reliability and Scalability

Cloud infrastructures are built to ensure scalability. Cloud computing environments can immediately scale up whenever high volumes of website or application traffic occur, but this scaling comes with a downside.

As a cloud environment automatically scales up, it will simultaneously run many application instances and spin up several virtual servers. But these new servers cannot receive traffic surges in an organized, categorical, coordinated fashion. Instead, some virtual servers may be overcome with requests, while others have little to no traffic.

Cloud load balancers easily distribute traffic surges seamlessly between application instances and newly spun servers, serving as a key cloud network component. Cloud load balancer services efficiently redirect traffic when a cloud service or resource crashes, shifting the workload within the cloud environment to another resource.


The ability to skip housing, configuring, and maintaining load balancing architecture in-house means better cloud service performance at a significantly lower price. Startups, small businesses, and medium-sized enterprises can use cloud load balancers and services run on the cloud.

Emergency API Management

Cloud-based service providers are capable of identifying which servers are unavailable and redirecting traffic and requests in real-time. Many cloud service providers such as Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform even stretch across multiple geographical regions.

This is particularly relevant during times of natural disasters like earthquakes, tsunamis, and floods or other emergencies afflicting particular geographical areas. These kinds of issues often result in inoperational cloud servers, which cloud server load balancers can react to by redirecting traffic to unaffected geographical locations.

Why is Cloud Load Balancing Important?

Cloud load balancing is an essential service for cloud-hosted applications. Overwhelmed servers can fail, causing substantial latency and possible outages for users. This is true for individual servers in a data center and for servers running in the cloud.

But understanding the importance of cloud load balancing solutions comes down to the differences between hardware vs. software load balancing in the cloud generally. Hardware load balancing appliances face disadvantages in the cloud.

Traditional network load balancing solutions are often prohibited from running in vendor-managed cloud environments, and when they’re not, they tend to manage cloud traffic inefficiently. They demand a sophisticated IT team to implement, tune, and maintain, so only larger businesses actually see the improved reliability and high performance benefits from hardware-based load balancing.

In contrast, software-based load balancers are designed and built to run in any location or environment, which is why they are optimal for cloud infrastructure and applications. They are affordable even for smaller companies because they run on commodity hardware, and in the cloud like any other software application.

Does VMware NSX Advanced Load Balancer Offer a Cloud Load Balancer Service?

The VMware NSX Advanced Load Balancer delivers the best of both worlds: complete enterprise features and cloud native automation and elasticity that works consistently in on-prem, private cloud, or public cloud. The platform offers intelligent web application firewall (WAF), full-featured L4L7 load balancing, customizable health monitoring, advanced HTTP content switching capabilities, DNS/IPAM services, and GSLB across multiple clouds. The VMware NSX Advanced Load Balancer manages, orchestrates and secures traffic to applications with consistent policies across clouds dynamically from a single, integrated platform based on business metrics such as security, performance, cost, and compliance requirements.

Find out more about how easy it is to provide flexibility and reduce risk with Advanced NSX Load Balancer’s enterprise grade cloud load balancing solution.

For more on the actual implementation of load balancers, check out our Application Delivery How-To Videos.

Connectionless Protocol

<< Back to Technical Glossary

Connectionless Protocol Definition

A connectionless protocol refers to the communication between two network endpoints without a prior arrangement in which one network endpoint simply sends a message to the other. At the sending end, the device transmits the unit of data before ensuring that the receiving end’s device is ready.

This type of protocol describes most open internet transmissions, although some protocols request a retransmission as needed to allow for error correction. There are a variety of supported connectionless protocols online, including HTTP (hypertext transfer), ICMP, IP, IPX, UDP, and TIPC. A connectionless protocol differs from a connection-oriented protocol, in which both devices must communicate with each other.

Image depicts the cycle of a Connectionless Protocol end-to-end communication system.


Connectionless Protocol FAQs

What is a Connectionless Protocol?

A connectionless network protocol is an alternative type of data transmission in which a network endpoint sends an IT signal automatically, without determining whether a receiver exists or stands ready to receive it. This stands in contrast to many conventional connection-based data transmission methods, which usually establish device connectivity checks or dedicated handshaking.

A connectionless transport layer protocol is a type of open signal like a radio frequency transmission. It is simply sent or broadcast outward, without as much regard for the recipient. Connection-based protocols have an intended destination and a defined point of origin, more like a cabled connection.

Although connection-oriented protocols function more effectively in certain cases, for data delivery in many systems, a connectionless protocol is adequate. Many connectionless protocols can facilitate multi-casting to a variety of receivers, and these protocols are often favored due to lower overhead costs since there’s no need to implement connectivity protocols such as those relating to handshakes.

Although connectionless transport protocols may drop a minimal number of data packets, in some cases this may not be noticed by receivers. Tools such as elastic load balancers that prevent packet loss can also mitigate against this type of issue.

Connection-Oriented and Connectionless Protocols

Connection-based services or connection-oriented services and connectionless services are the two services that layers provide to layers above them.

Connection-Oriented Services

Users of connection-oriented services follow a sequence of operations:

  • Establish connection
  • Send information
  • Release connection


To provide connection-oriented services, it is necessary to establish a connection first, and then start the communication, send the information, and then release the connection. This type of service is more reliable, because if there is an error on the receiver’s end, the sender can resend the information.

Connection-oriented means that devices perform a handshake when they communicate to set up an end-to-end connection. The handshaking process can vary significantly and may be a simple transport layer protocol TCP synchronization, or a complex negotiation of communications parameters with a modem. Obviously, connection-oriented systems demand on bi-directional communications and cannot function in unidirectional environments.

Connectionless Protocols

In connectionless protocols, users make no effort to establish a dedicated end-to-end connection. Instead, they simply send the information, ideally ensuring there is adequate speed and minimal interference. Just like on a citizen band radio or walkie talkie, if the message is garbled, the only recourse is to ask for a clarification. Advantages of connectionless protocols include simpler form, lower overhead, no need for circuit setup, and ability to multicast.

Connectionless services designate the intended destination of each message or packet of information. The system routes each packet independently, just like postal packages, so there’s no way to be sure you’ll get all of the information in correct order.

There are advantages and disadvantages of connectionless and connection-oriented protocols. The difference between connectionless and connection-oriented communication breaks down as follows:

Connection-oriented protocols Connectionless protocols
authentication is needed no authentication necessary
checks whether message is received, sends again if error occurs no guarantees of delivery
more reliable less reliable
stream based message based
analogous to telephone analogous to postal
long and steady bursts of communication
congestion is not possible congestion is possible
packets follow the same route packets do not follow same route
high range bandwidth required low range bandwidth adequate


Both connectionless communication and connection-oriented communication typically connect two or more than two devices providing services typically offered by the network layer.

Connection vs Connectionless Protocols: Layers and Services

In computer networking and the open system interconnection (OSI) model, the transport layer is the fourth layer, responsible for end-to-end network communication. The transport layer brings logical communication to application processes that run on different hosts.

Those hosts run inside a layered architecture composed of various protocols and other network components. The transport layer and its protocols offer host-to-host communication services for applications, including connection-oriented communication, flow control, multiplexing, and reliability. Protocols are simply sets of rules that control the meaning and format of messages, frames, or packets that the server and client exchange.

The OSI model of general networking and the transport layer of the internet protocol suite, which serves as the internet’s foundation, have distinct implementation details. There are five classes of transport protocols defined for the OSI transport layer. They range from TP0, with the least error recovery, to TP4, which offers more error recovery and is intended for less reliable networks.

The Transmission Control Protocol (TCP) is the best-known transport protocol of the internet protocol suite. User Datagram Protocol (UDP) is a connectionless protocol used for less complex transmissions, TCP is the more complex protocol, used for connection-oriented transmissions based on its stateful design incorporating data stream services and reliable transmission. Together, UDP and TCP comprise nearly all internet traffic.

Services are the operations that any given layer in the OSI Reference model is able to provide to the layer above it. A service defines the operation itself that a layer can perform, but the service does not specify any details of implementation.

In the transport layer, data on the host computers is delivered to the appropriate application processes. The system forms data segments by statistically multiplexing data from different application processes, and adds destination and source port numbers to each transport layer data segment’s header. The port numbers together with the source and destination IP addresses constitute a network socket—an address for identification of the process-to-process communication. The session layer supports this function in the OSI model.

Certain transport layer protocols support virtual circuits—for example TCP does, but UDP does not. This means these protocols provide connection-oriented communication using a packet-oriented network. TCP also supports error recovery for end-to-end reliable communication through error detecting code and automatic repeat request (ARQ) protocol.

The much simpler UDP protocol uses packets called datagrams instead of segments. It does not provide reliable communication or virtual circuits.

These differences mean that TCP may be used for various protocols, including email transfer and HTTP web browsing, while UDP is more likely to be used for functions such as broadcasting and multicasting, where retransmission to many hosts is not possible. Offering shorter latency, higher throughput, lower costs, and other benefits of connectionless communication, UDP is often used when packet loss can occasionally be accepted during real-time multimedia communication—for example, for online computer games, IP-TV, and IP-telephony.

Datagrams are referring to connectionless protocols. A connectionless protocol layer lacks an acknowledgment scheme and sequence number, meaning the protocol is connectionless. However, it can also be called datagram.

Clients and servers that use a perfect channel to communicate share a dedicated point-to-point channel—or an illusory version of such a connection. First, the client and server must establish the connection to communicate and transmit the data, afterwards closing the connection. The channel guarantees that all data transmitted over the channel is sent and received in the same order.

When clients and servers use datagrams to communicate, they send and receive completely independent packets over the network. The packets do not have a dedicated point-to-point channel and travel on whatever route is available.

In contrast, a connection-oriented protocol layer has an expected acknowledgment process and sequence numbers, and if they are not received, retransmission takes place. This is how connection-oriented protocols guarantee delivery of data. They are more reliable protocols.

There are two main protocols at the transport layer of the OSI Reference Model: the connection-oriented TCP, and the connectionless UDP. TCP works based on a set of rules and uses them to negotiate before establishing a logical connection and sending the data. It is therefore used for applications that demand these types of connections and service features.

UDP is preferred for use with applications that don’t have those features or connections, but do need faster performance. By not negotiating and then establishing a connection, the UDP saves time.

Some refer to this as a kind of circuit-switching. However, a TCP connection is still sending data as packets, not actually creating a circuit between devices. There is still potential for mixed pieces of data, data loss, or other problems that come with packet switched communications. In other words, TCP and other connection-oriented protocols do not eliminate the need for circuit-switching technologies.

A packet switching network follows connectionless networking protocols that divide messages into packets before sending them, including Wide Area Network (WAN) protocols and TCP/IP. This is distinct from circuit switching technology.

Does the VMware NSX Advanced Load Balancer Platform Support Connectionless Protocols?

Yes. The VMware NSX Advanced Load Balancer supports both connection-oriented (TCP) protocols, as well as connectionless protocols such as UDP and HTTP.

Before sending any TCP connection to the server, the VMware NSX Advanced Load Balancer rewrites the client IP address, regardless of which TCP profile type a virtual service uses. Along these lines, the platform rewrites the destination address from the virtual service IP address to the server IP address. The Service Engine source IP address is always what the server sees.

Learn more about the VMware NSX Advanced Load Balancer’s support for connectionless protocols here.

For more on the actual implementation of load balancing, security applications and web application firewalls check out our Application Delivery How-To Videos.

Cross Site Scripting

<< Back to Technical Glossary

Cross Site Scripting Definition

Cross-Site Scripting (XSS) is a type of injection attack in which attackers inject malicious code into websites that users consider trusted. A cross-site scripting attack occurs when an attacker sends malicious scripts to an unsuspecting end user via a web application or script-injected link (email scams), or in the form of a browser side script. The end user’s browser will execute the malicious script as if it is source code, having no way to know that it should not be trusted.

Attackers may exploit a cross-site scripting vulnerability to bypass the same-origin policy and other access controls. Because the end-user browser then believes the script originated with a trusted source, that malicious code can access any session tokens, cookies, or other sensitive information the browser retains for the site to use.

Although they are relatively easy to prevent and detect, cross-site scripting vulnerabilities are widespread and represent a major threat vector.

Diagram outlines cross site scripting (XSS), a type of injection attack.

What is Cross Site Scripting?

Cross-site scripting is a code injection attack on the client- or user-side. The attacker uses a legitimate web application or web address as a delivery system for a malicious web application or web page. When the victim visits that app or site, it then executes malicious scripts in their web browser.

Cross-site scripting attacks are frequently triggered by data that includes malicious content entering a website or application through an untrusted source—often a web request. The web user receives the data inside dynamic content that is unvalidated, and contains malicious code executable in the browser. This is often in JavaScript but may also be in Flash, HTML, or any other type of code that the browser may execute.

There is almost a limitless variety of cross-site scripting attacks, but often these attacks include redirecting the victim to attacker-controlled web content, transmitting private data, such as cookies or other session information, to the attacker, or using the vulnerable web application or site as cover to perform other malicious operations on the user’s machine.

Types of Cross Site Scripting Attacks

Initially, two main kinds of cross-site scripting vulnerabilities were defined: stored XSS and reflected XSS. Amit Klein identified a third type of cross-site scripting attack in 2005 called DOM Based XSS.

Stored or Persistent Cross Site Scripting Attacks (Type-I XSS)

The potentially more devastating stored cross-site scripting attack, also called persistent cross-site scripting or Type-I XSS, sees an attacker inject script that is then stored permanently on the target servers. The script may be stored in a message board, in a database, comment field, visitor log, or similar location—anywhere users may post messages in HTML format that anyone can read. The victim’s browser then requests the stored information, and the victim retrieves the malicious script from the server.

For example, on a business or social networking platform, members may make statements or answer questions on their profiles. Typically these profiles will keep user emails, names, and other details private on the server.

An attacker may join the site as a user to attempt to gain access to that sensitive data. The attacker can create a profile and answer similar questions or make similar statements on that profile. If they insert a malicious script into that profile enclosed inside a script element, it will be invisible on the screen. When visitors click on the profile, the script runs from their browsers and sends a message to the attacker’s server, which harvests sensitive information.

This kind of stored XSS vulnerability is significant, because the user’s browser renders the malicious script automatically, without any need to target victims individually or even lure them to another website. This can result in a kind of client-side worm, especially on social networking sites, where attackers can design the code to self-propagate across accounts.

Reflected or Non-Persistent Cross-Site Scripting Attacks (Type-II XSS)

The reflected cross-site scripting vulnerability, sometimes called non-persistent cross-site scripting, or Type-II XSS, is a basic web security vulnerability. These vulnerabilities occur when server-side scripts immediately use web client data without properly sanitizing its content. The client data, often in HTTP query parameters such as the data from an HTML form, is then used to parse and display results for an attacker based on their parameters.

For example, a site search engine is a potential vector. Typically, the search string gets redisplayed on the result page. If the system does not screen this response to reject HTML control characters, for example, it creates a cross-site scripting flaw. The results page displays a URL that users believe navigates to a trusted site, but actually contains a cross-site script vector. Clicking the link is dangerous if the trusted site is vulnerable, as it causes the victim’s browser to execute the injected script.

Blind Cross Site Scripting

Blind cross-site scripting vulnerabilities are a type of reflected XSS vulnerability that occurs when the web server saves attacker input and executes it as a malicious script in another area of the application or another application altogether. Blind cross-site scripting attacks occur in web applications and web pages such as chat applications/forums, contact/feedback pages, customer ticket applications, exception handlers, log viewers, web application firewalls, and any other application that demands moderation by the user.

For example, an attacker may inject a malicious payload into a customer ticket application so that it will load when the app administrator reviews the ticket. The attacker input can then be executed in some other entirely different internal application.

Compared to other reflected cross-site script vulnerabilities that reveal the effects of attacks immediately, these types of flaws are much more difficult to detect. The server can save and execute attacker input from blind cross-site scripting vulnerabilities long after the actual exposure. Therefore, it is challenging to test for and detect this type of vulnerability.

DOM Based Cross-Site Scripting Vulnerabilities

DOM-based cross-site scripting injection is a type of client-side cross-site scripting attack. In a DOM-based XSS attack, the malicious script is entirely on the client side, reflected by the JavaScript code. The attacker code does not touch the web server.

For example, in 2011, a DOM-based cross-site scripting vulnerability was found in some jQuery plugins. DOM-based XSS attacks demand similar prevention strategies, but must be contained in web pages, implemented in JavaScript code, subject to input validation and escaping. Some JavaScript frameworks such as Angular.js include built-in cross site scripting defense measures against DOM-based scripting attacks and related issues.

Universal Cross-Site Scripting

Universal cross-site scripting, like any cross-site scripting attack, exploits a vulnerability to execute a malicious script. However, in contrast to some other attacks, universal cross-site scripting or UXSS executes its malicious code by exploiting client-side browser vulnerabilities or client-side browser extension vulnerabilities to generate a cross-site scripting condition. This allows an attacker to bypass or deactivate browser security features.

XSS Attack vs SQL Injection Attack

Cross-site scripting differs from other vectors for web attacks such as SQL injection attacks in that it targets users of web applications. SQL injection attacks directly target applications.

Cross-site Scripting Attack Vectors

Methods for injecting cross-site scripts vary significantly. Attackers can exploit many vulnerabilities without directly interacting with the vulnerable web functionality itself. Any data that an attacker can receive from a web application and control can become an injection vector.

Attackers may use various kinds of tags and embed JavaScript code into those tags in place of what was intended there. For example, these tags can all carry malicious code that can then be executed in some browsers, depending on the facts.

Here are some of the more common cross-site scripting attack vectors:

• script tags
• iframe tags
• img attributes
• input tags
• link tags
• the background attribute of table tags and td tags
• div tags
• object tags

JavaScript event attributes such as onerror and onload are often used in many tags, making them another popular cross-site scripting attack vector.

OWASP maintains a more thorough list of examples here: XSS Filter Evasion Cheat Sheet.

Cross Site Scripting Examples

Typically, by exploiting a XSS vulnerability, an attacker can achieve a number of goals:

• Capture the user’s login credentials
• Carry out all authorized actions on behalf of the user
• Disclose user session cookies
• Engage in content spoofing
• Impersonate the victim user
• Inject trojan functionality into the victim site
• Read any accessible data as the victim user
• Virtually deface the website

These outcomes are the same, regardless of whether the attack is reflected or stored, or DOM-based. The consequences of a cross-site scripting attack change based on how the attacker payload arrives at the server.

Non-persistent cross site scripting example

As a non persistent cross-site scripting attack example, Alice often visits Bob’s yoga clothing website. The site prompts Alice to log in with her username and password and stores her billing information and other sensitive data. When Alice logs in, the browser retains an authorization cookie so both computers, the server and Alice’s, the client, have a record that she is logged into Bob’s site.

Mallory, an attacker, detects a reflected cross-site scripting vulnerability in Bob’s site, in that the site’s search engine returns her abnormal search as a “not found” page with an error message containing the text ‘xss’:‘xss’);

Mallory builds that URL to exploit the vulnerability, and disguises her malicious site so users won’t know what they are clicking on. Now, she can message or email Bob’s users—including Alice—with the link.

When Alice clicks it, the script runs and triggers the attack, which seems to come from Bob’s trusted site. Mallory takes the authorization cookie from the site and logs in as Alice, taking her credit card information, address, and changing her password. If she does the same thing to Bob, she gains administrator privileges to the whole website.

Cross-site scripting countermeasures to mitigate this type of attack are available:

• Sanitize search input to include checking for proper encoding
• Set web server to redirect invalid requests
• Set web server to detect simultaneous logins and invalidate sessions
• Change website settings to display only last digits of payment credit cards
• Challenge users to re-enter passwords before changing registration details
• Prevent access from JavaScript with with HttpOnly flag for cookies

Persistent cross-site scripting example

Mallory registers for an account on Bob’s website and detects a stored cross-site scripting vulnerability. Specifically, she sees that posted comments in the news forum display HTML tags as they are written, and the browser may run any script tags.

Mallory posts a comment at the bottom in the Comments section: check out these new yoga poses! “script src=””

As soon as anyone loads the comment page, Mallory’s script tag runs. If the user is Alice or someone with an authorization cookie, Mallory’s server will steal it.

How to Prevent Cross-Site Scripting

There are several best practices in how to detect cross-site script vulnerabilities and prevent attacks:

Treat user input as untrusted. There is a risk of cross-site scripting attack from any user input that is used as part of HTML output. Even input from internal and authenticated users should receive the same treatment as public input.

Use escaping/encoding techniques. Depending on where you will deploy the user input—CSS escape, HTML escape, URL escape, or JavaScript escape, for example—use the right escaping/encoding techniques. Use libraries rather than writing your own if possible.

Use appropriate response headers. Use the Content-Type and X-Content-Type-Options headers to prevent cross-site scripting in HTTP responses that should contain any JavaScript or HTML to ensure that browsers interpret the responses as intended.

Sanitize HTML. It breaks valid tags to escape/encode user input that must contain HTML, so in those situations parse and clean HTML with a trusted and verified library. The right library depends on your development language, for example, SanitizeHelper for Ruby on Rails or HtmlSanitizer for .NET.

HttpOnly flag. Set the HttpOnly flag for cookies so they are not accessible from the client side via JavaScript.

Filter input upon arrival. As the system receives user input, apply a cross-site scripting filter to it strictly based on what valid, expected input looks like.

Encode data upon output. Encode user-controllable data as it becomes output with combinations of CSS, HTML, JavaScript, and URL encoding depending on the context to prevent user browsers from interpreting it as active content.

Use a Content Security Policy (CSP) or HTTP response header to declare allowed dynamic resources depending on the HTTP request source.

According to the Open Web Application Security Project (OWASP), there is a positive model for cross-site scripting prevention. This is an allowlist model that denies anything not explicitly granted in the rules. Find OWASP’s XSS prevention rules here.

Does VMware NSX Advanced Load Balancer Protect Against Cross-Site Scripting Attacks?

A web application firewall (WAF) is among the most common protections against web server cross site scripting vulnerabilities and related attacks. VMware NSX Advanced Load Balancer’s cross-site scripting countermeasures include point-and-click policy configurations with rule exceptions you can customize for each application, and input protection against cross-site scripting—all managed centrally.

For more on the actual implementation of load balancing, security applications and web application firewalls check out our Application Delivery How-To Videos.

Container Load Balancing

<< Back to Technical Glossary

Container Load Balancing Definition

Container load balancing and proxy services are essential for container-based applications built on the microservices architecture both in terms of traffic management and peak performance.

Diagram depicts container load balancing for microservices and container-based application environments.

What Is Container Load Balancing?

Container load balancing helps to deliver traffic management services for containerized applications efficiently. Today’s developers use containers to quickly test, deploy, and scale applications through continuous integration and continuous delivery (CI / CD). But the transient and stateless nature of container-based applications requires different traffic control for optimal performance.

Orchestration platforms like Kubernetes deploy and manage containers. A load balancer in front of the Docker engine will result in higher availability and scalability of client requests. This ensures uninterrupted performance of the microservices-based applications running inside the container. The ability to update a single microservice without disruption is made possible by load balancing Docker containers. When containers are deployed across a cluster of servers, load balancers running in Docker containers make it possible for multiple containers to be accessed on the same host port.

How Does Container Load Balancing Work?

Docker is a common platform for running applications in containers. This includes the packaging, distribution and management of independent applications within containers.

In addition to management tasks, container load balancing also involves infrastructure services that make sure the applications are secure and running efficiently.

The following is necessary:

• Containers deployed across a cluster of servers.
• Continuously updated without disruption.
• Load balancing for multiple containers on a single host accessed on the same port.
• Secure container communication.
• Monitoring of containers and the cluster.

What Are the Benefits of Container Load Balancing?

The benefits of container load balancing include:

• Balanced distribution — A user-defined load balancing algorithm distributes traffic evenly (if non-weighted round robin is applied) through the healthiest and most available backends to the endpoint group.
• Accurate health checks — Direct health checks of the pods is a more accurate way to determine the health of the backends.
• Better visibility and security — Visibility is possible at the pod or even container level, depending on the granularity required. The IP source is preserved for easier tracking of traffic sources.

Does VMware NSX Advanced Load Balancer Offer Container Load Balancing?

Yes. The VMware NSX Advanced Load Balancer integrates with container-based environments to provide dynamically configured load balancing, service discovery, service proxy, application mapping, and autoscaling capabilities. The solution also provides end-to-end visibility and performance monitoring at the microservice and service-fabric levels, and autoscales application instances across thousands of nodes based on real-time traffic and application performance.

For more information see the following Container Load Balancing resources:

For more on the actual implementation of load balancers, check out our Application Delivery How-To Videos or watch the Enterprise-Grade Ingress and Load Balancing for Kubernetes How To Video here:

Container Monitoring

<< Back to Technical Glossary

Container Monitoring Definition

Container monitoring is the process of tracking the operation of a containerized application. Containers are of an ephemeral nature and are tricky to monitor compared to traditional applications running on virtual servers or bare metal servers. Yet container monitoring is an important capability needed for applications built on modern microservices architectures to ensure optimal performance.

Diagram depicts Container Monitoring for IT managers to monitor the health and performance of web applications running in container clusters.

What is Container Monitoring?

A container monitoring system collects metrics to ensure application running on containers are performing properly. Metrics are tracked and analyzed in real time to determine if an application is meeting expected goals.

A container monitoring service is an application performance management (APM) tool that gives IT teams a quick overview to rapidly develop and deploy applications using DevOps principles.

Container monitoring tools should not be confused with orchestration tools. Orchestration tools control the lifecycle of containers and are needed for deployment and scaling purposes.

What Are the Benefits of Container Monitoring?

The benefits of container monitoring include:
• Identifying issues proactively to avoid system outages.
• Monitoring time-series data to help applications run better.
• Implement changes safely by catching problems early and resolving issues quickly.

How Does Container Monitoring Work?

Container monitoring solutions use metric capture, analytics, transaction tracing and visualization.

Container monitoring covers basic metrics like memory utilization, CPU usage, CPU limit and memory limit. Container monitoring also offers the real-time streaming logs, tracing and observability that containers need. This information can tell an IT team when to scale up by providing utilization ratios. Application security monitoring can also be utilized.

Docker container performance monitoring and Kubernetes container monitoring require memory and CPU ratios for the cluster itself. If a container runs an HTTP server, request counts and metrics related to latency must be collected.

Comprehensive container monitoring takes into account the various layers in a stack and what each layer requires to function well. This includes text-based error data such as “could not connect to database” or “container restart.” Both numeric and text-based data is important for a container monitoring device to track.

Container Monitoring vs. Application Performance Monitoring

A good container monitoring system offers the following:
• Simple addition of instrumentation to existing code.
• Easy access to libraries of existing languages.
• Support for different data types.
• Visualization system and dashboards for exploring data.

How to Monitor Docker Containers?

Docker container performance monitoring includes the following:
• Detecting problems early.
• Tracking entire environments when making changes and upgrades.
• Refining applications for better performance.

Docker container monitoring tools provide Docker metrics for CPU utilization, memory, networking information and disk utilization. Docker stats command displays a live stream of statistics.

Does VMware NSX Advanced Load Balancer Offer Container Monitoring?

Yes. The VMware NSX Advanced Load Balancer integrates with container-based environments to provide end-to-end visibility and performance monitoring at individual microservice and overall application levels. The VMware NSX Advanced Load Balancer autoscales container instances across thousands of nodes based on real-time traffic and application performance. The VMware NSX Advanced Load Balancer Container Ingress also dynamically configures load balancing, service discovery, service proxy, application mapping, and autoscaling capabilities.

For more on the actual implementation of load balancers, check out our Application Delivery How-To Videos.

For more information on container monitoring see the following resources:

Container Orchestration

<< Back to Technical Glossary

Container Orchestration Definition

Container orchestration is the automatic process of managing or scheduling the work of individual containers for applications based on microservices within multiple clusters. The widely deployed container orchestration platforms are based on open-source versions like Kubernetes, Docker Swarm or the commercial version from Red Hat OpenShift.

Diagram depicts Container Orchestration for deploying and managing multiple application containers in an multi-cloud or on premise application delivery environment.

What is Container Orchestration?

Container orchestration is the automation of all aspects of coordinating and managing containers. Container orchestration is focused on managing the life cycle of containers and their dynamic environments.

Why Do We Need Container Orchestration?

Container orchestration is used to automate the following tasks at scale:
• Configuring and scheduling of containers
• Provisioning and deployments of containers
• Availability of containers
• The configuration of applications in terms of the containers that they run in
• Scaling of containers to equally balance application workloads across infrastructure
• Allocation of resources between containers
• Load balancing, traffic routing and service discovery of containers
• Health monitoring of containers
• Securing the interactions between containers.

How Does Container Orchestration Work?

Container orchestration works with tools like Kubernetes and Docker Swarm. Configurations files tell the container orchestration tool how to network between containers and where to store logs. The orchestration tool also schedules deployment of containers into clusters and determines the best host for the container. After a host is decided, the orchestration tool manages the lifecycle of the container based on predetermined specifications. Container orchestration tools work in any environment that runs containers.

Orchestration tools for Docker include the following:
• Docker Machine — Provisions hosts and installs Docker Engine.
• Docker Swarm — Clusters multiple Docker hosts under a single host. It can also integrate with any tool that works with a single Docker host.
• Docker Compose — Deploys multi-container applications by creating the required containers.

Orchestration tools for Kubernetes include the following features:
• Automated deployment and replication of containers.
• Online scale-in or scale-out of container clusters.
Load balancing groups of containers.
• Automated rescheduling of failed containers.
• Controlled exposure of network ports to systems outside of the cluster.

Docker Container Orchestration vs. Kubernetes Container Orchestration

The Docker container orchestration tool, also known as Docker Swarm, can package and run applications as containers, find existing container images from others, and deploy a container on a laptop, server or cloud (public cloud or private). Docker container orchestration requires one of the simplest configurations.

Orchestration in container services for Kubernetes allows container clustering via a container orchestration engine. Kubernetes has declarative management that hides complexity, and is open source so you can run it anywhere.

Benefits of Containerized Orchestration Tools

• Increased portability — Scale applications with a single command and only scale specific functions without affecting the entire application.
• Simple and fast deployment — Quickly create new containerized applications to address growing traffic.
• Enhanced productivity — Simplified installation process and decreased dependency errors.
• Improved security — Share specific resources without risking internal or external security. Application isolation improves web application security by separating each application’s process into different containers.

Does VMware NSX Advanced Load Balancer Integrate with Container Orchestration?

The VMware NSX Advanced Load Balancer provides a centrally orchestrated, ingress gateway for containers composed of a fabric of proxy services with dynamic load balancing, service discovery, security, micro-segmentation, and analytics for container-based applications running in OpenShift and Kubernetes environments.

The VMware NSX Advanced Load Balancer delivers a scalable, enterprise-class Container Ingress to deploy and manage business-critical workloads in production environments using Redhat container orchestration with OpenShift and Kubernetes clusters.

For more on the actual implementation of load balancers, check out our Application Delivery How-To Videos.

For more information on container orchestration see the following resources:

Container Management

<< Back to Technical Glossary

Container Management Definition

Container Management is the process of organizing, adding or replacing large numbers of software containers. Container management uses software to automatically create, deploy and scale containers. This gives rise to the need for container orchestration—a more specialized tool that automates the deployment, management, scaling, networking, and availability of container-based applications. For example, Kubernetes manages app health, replication, load balancing, and hardware resource allocation for you.

Diagram depicts Container Management for deploying and managing multiple application containers in an multi-cloud or on premise application delivery environment.

What is Container Management?

Container management uses a platform to organize software containers, which may also be referred to as operating-system-level virtualizations. The container management platforms optimize efficiency and streamline container delivery without complex interdependent system architectures.

Containers have become popular as enterprises use DevOps for faster development and deployment of applications. Containers include everything needed to run software, including files and libraries. Containers combine the libraries of an application or microservice into one deployable unit that does not deplete the CPU or memory resources of the host operating system. Container management includes scheduling, application security, storage and monitoring.

Why use Container Management?

Container management is necessary when enterprises rely on containers to quickly deploy and update applications. Container management software like Kubernetes and Docker Swarm is designed to handle the rapid changes in DevOps strategy.

Docker container management software and Kubernetes container management make orchestration, security and networking easier. Container management software systems are available as both open source and proprietary commercial products.

Why Do Containers need Management?

Containers need management services because a vast number of containers can become too complex for an IT team to handle.

Container management also provides automation that enables application developers to stay on top of rapid changes. The automatic deployment of container-based applications to operating systems and the public cloud requires management because orchestration platforms like Kubernetes can be complex.

Does VMware NSX Advanced Load Balancer Offer Container Management?

Yes. The VMware NSX Advanced Load Balancer integrates with container-based environments to provide a container ingress, dynamically configured load balancing, service discovery, service proxy, application mapping, and autoscaling capabilities. The solution also provides end-to-end visibility and performance monitoring at the microservice and service-fabric levels, and autoscales application instances across thousands of nodes based on real-time traffic and application performance.

For more on the actual implementation of load balancers, check out our Application Delivery How-To Videos.

For more information on container management see the following resources:

Container Deployment

<< Back to Technical Glossary

Container Deployment Definition

Container deployment is a method for quickly building and releasing complex applications. Docker container deployment is a popular technology that gives developers the ability to construct application environments with speed at scale.

Diagram depicts container deployment using container cluster management software such as; Docker, Kubernetes, OpenShift to deliver applications seamlessly to end users.

What is Container Deployment?

Container deployment is the action of putting containers to use. The deployment of containers uses management software that simplifies the launch and updates of applications. Container deployment provides fast access to environments and speeds up development because secure containers can be quickly downloaded and put to use. Container deployment also minimizes errors because it reduces the number of moving parts in development.

Applications are deployed with a combination of manual procedures and automated scripts. Security can be a concern when containers run at a root level, which increases vulnerability.

Container deployment tools such as Docker and OpenShift / Kubernetes multi-container deployment help manage the containers in real-world production environments. They replace what used to be a total reliance on IT engineers.

Why use Container Deployment?

Container deployments can replace many of the tasks previously handled by IT operations. When a tool like Docker deploys multiple containers, it places applications in virtual containers that run on the same operating system. This provides a benefit not offered by virtual machines. Using a virtual machine requires running an entire guest operating system to deploy a single application.

This is costly and slow if deploying many applications. If you deploy a Docker container, each container has everything needed to run the app and can be easily spun up or down for testing. This is how container deployment saves resources like storage, memory and processing power and speeds up the CI/CD pipeline.

Benefits of Container Deployment

• Run many individual applications on the same number of servers.

• Deliver ready-to-run applications in containers that hold all the codes, libraries and dependencies any application needs.

• Deploy easier and more secure deployment and management of applications.

• Modify an application and instantly run it anywhere.

Does VMware NSX Advanced Load Balancer Offer Container Deployment?

The VMware NSX Advanced Load Balancer offers an integrated solution with major container vendors such as Docker, Rancher, CoreOS and Mesosphere to help enterprises build and deploy microservices applications at scale using containers. The VMware NSX Advanced Load Balancer also partners with Red Hat Openshift and Kubernetes container orchestration platforms to offer multi-cluster, multi-cloud load balancing and load balancing.

For more information on container deployment see the following resources:

Content Caching Definition

Content caching is a performance optimization mechanism in which data is delivered from the closest servers for optimal application performance. For example, content from a single server can be copied and distributed across various data centers and clouds. When that content needs to be accessed, the content can be retrieved from any of the cached locations based on geographic location, performance, and bandwidth availability.