The best known product for traffic manipulation is likely F5′s legendary iRules, but other vendors have similar capability such as A10′s aFlex.   Essentially, this puts an application development platform. Typically this is done with a standard programming language, such as a modified TCL for iRules and aFlex.

Some vendors, (Cisco I’m looking at you, as well as Brocade but I’m less familiar with them lately) lack the ability to manipulate traffic using application logic.

For vendors, this is a great feature to have. Its attractive to potential customers, and it makes it difficult to move to a platform that doesn’t have this feature. I call it the Charlton Heston feature, since you’ll only pull it out of a client’s cold dead hands.  Once you use it, you’re fairly dependent on it.

Get your paws off me, you damned dirty network admins!

In general, I’m a fan of iRules and their ilk. There’s just too many situations where the ability to manipulate HTTP content has saved the day.

So what kind of manipulation can you do?  There are rules to scrub credit card numbers, so if a web application tries to display a credit card number such as “5123-1234-1234-1234″ (a big no-no according to PCI-DSS), the load balancer would do a regular expression search for that pattern, and replace it with “XXX-XXX-XXXX-1234″ before sending the response off to the client.

With a programming language and regular expressions, just about anything is possible. And there in lies a problem.

Two Edged Sword

Having application logic on the load balancer is a double-edged sword.  One the one hand, it allows you to have very granular control over headers and content for requests and responses.  The drawback is it allows you to have very granular control over headers and content for requests and responses.

The awesomeness of this manipulation is evident, but there are some caveats.

We’ll fix it in post

There’s a running joke in the film industry called “we’ll fix it in post”.  Essentially, it means who cares if we get it right here, we’ll just fix it with special effects or editing.  Except it hardly ever works.  You’ve got the same hazard in something like iRules; it can be a lousy and lazy way to fix to a problem that really should be fixed in the code.

Capacity

Of course, all this regular expressioning and application logic come at a cost in terms of CPU.  The more of it you do, the lower capacity you’ll have.  A load balancer capable of serving up 4 Gbits of second of traditional Layer 4-7 traffic may have its capacity dropped to 500 Mbps.  And there’s no way of telling what the new performance ceiling would be (until you hit it like Wile E Coyote on a rocket sled).

This is less of an issue than it used to be, as Moore’s law has made processors faster and faster, allowing load balancers to handle increasingly difficult tasks, while bandwidth requirements have not increased nearly as dramatically. Not many organizations have more than a couple hundred megabits per second to the Internet, while load balancers are capable of handling several (even dozens) of Gigabits.

Latency

Latency is a dirty word in networks and applications, and certainly a potential issue with application logic.  If you’re going to look at a cookie, the latency imposed by a load balancer will be minimal.  If you’re going to calculate Pi to the 100th digit on every HTTP request, that’s going to add a certain amount of latency to the transaction.  Like the capacity ceiling, it’s very difficult to predict what that additional latency will be when adding more and more logic. And depending on the load profile, that latency may vary quite a bit over time.

Creep

Capacity and latency are easy enough issues to deal with, but creep is very problematic.  It’s a “Layer 8″ problem, and one that can quickly spiral out of control.

Typically the creep comes into play when you first implement application logic, and it fixes a vexing problem. You’re the hero, and someone perks their ears up and says “wow, what else can you do with it?”

“Anything”, you say confidently.  And anything is what they throw at you. Add semi-colons at the end of paragraphs, replace all double-spaces after a period with single spaces, etc.

It can very easily spiral out of control, so you need to know when to put your foot down (hint: early).

Skills

To develop this application logic, you need to understand HTTP really well. When developing most web applications on a platform like ASP or PHP, you don’t really need to understand HTTP all that well.  But the load balancer manipulates on the HTTP level, so you’ll really need to be up on your HTTP. You also need to have the programming skills to pay the bills. Especially for a network admin, those programming muscles might not get flexed on a regular basis.

I’ve also heard the argument that iRules and their ilk are only there to fix problems that should have been fixed in the code. And there’s a lot of truth in that; they are typically used in situations where the problem could also be solved at the application.

But that’s also like saying that I shouldn’t need a lock on my door, because people should not be jerks and go around stealing stuff.

In IT, there are always going to be situations where its either easier to fix the problem on the load balancer, or it’s the only viable solution (code locked down, client doesn’t control the code as its a third party, developer ran away to Brazil with their secret family and won’t return calls).

Bottom line? I’d rather have it than not have it, but I’m very careful with it. After all, with great power comes great potential for epic fail.

I’m a big fan of virtualization.  There’s a lot to like about it, including consolidation (getting rid of space-heater servers that do nothing running 1% CPU and sucking up electricity and throwing off heat), flexibility, and management.  I’ve even gone and got my VCP4 (VMware Ceritified Professional 4) certification.  (Hear that ladies? I’m certified.)

One aspect of virtualization I’m a fan of is the appliances.  Vendors are taking physical appliances (such as a Vyatta router) and turning it into a VM appliance.  I don’t have to worry about an underlying operating system (and the requisite patches), the appliance vendor handles the software and the OS.

Several load balancing vendors have gotten into that virtualization game.  Vendors that have traditionally offered hardware appliances now have virtual appliances (some for years).  From From F5 to KEMP, from Coyote Point to loadbalancer.org, there are a number of virtual load balancers/ADCs to choose from.   And for the most part, they offer the same features as their hardware brethren.

Their throughput and performance is hampered somewhat by the fact that they’re all software and no silicon. Everything is done in the x86 virtualized CPU(s).  Still, depending on how you provision them, they can generally handle several thousand HTTP requests per second even in Layer 7 mode.

The one caveat to virtual load balancers is that their SSL performance is severely limited.  Even value-market load balancers that do most of their functions in a general purpose CPU will still use SSL ASICs for the asymmetric crypto (even using the general processor for the less CPU-intensive symmetric crypto).

The first part of every new SSL connection is a very CPU-intensive asymmetric operation (about 1000x more CPU intensive than symmetric operations).    CPUs that can normally handle tens of thousand of regular TCP connections per second can only handle a few thousand SSL connections at the most.

It is technically possible to do hardware SSL acceleration on a VM load balancers however.  It requires that the virtual machine host (like VMWare ESXi) have an SSL card installed, and VM Passthrough enabled (where the virtual machine can have direct access to physical hardware).

Unfortunately, these SSL cards are tough to come by.  Cavium is probably the most notable vendor, but cards from them aren’t exactly easy to come by, and they’re fairly expensive.  You may not have the option if you’re using blade systems.   And if you you want to leverage features like HA and DRS (using ESX hosts in a cluster), then every machine in the cluster would need to have such a card.  I’m not aware of any virtual load balancer vendor that even supports this configuration.

There are a lot of situations where virtual load balancers make a lot of sense, but keep in mind that the SSL performance capability is going to be fairly constrained.

SSL performance is a tricky thing to measure.  There are a lot of different aspects to consider, and on top of that different vendors use slightly different definitions for the same terms. I was talking with a vendor the other day, and I realized as we were talking performance numbers we had different definitions for the term TPS (Transactions Per Second) and CPS (Connections Per Second).

TPS is probably one of the more ill-advised acronyms (boy do we love acronyms) for load balancers, because it’s open to debate what the “transaction” in transactions per second means.

SSL Basics

Before we talk about CPS versus TPS, let’s review some SSL basics.  In a new SSL connection, two things happen: An asymmetric exchange, then a transition to symmetric encryption.

The asymmetric part is why load balancers from F5 to KEMP use SSL accelerator chips.  It’s incredibly CPU intensive; so much so that a server that is capable of tens of thousands of connections per second of regular TCP connections is only capable of several hundred SSL connections.  To keep this from crippling the CPU, SSL accelerator processors are used to offload the cryptographic functions from the main CPU.

So when we measure SSL performance of a load balancer, we typically want to measure three things:

1: How many new SSL connections per second can a device handle, that is how many of the expensive RSA operations per second are possible.

2: How much bandwidth of SSL traffic can the device push.  This is symmetric encryption (such as AES), and is much easier on a CPU.

3: How many HTTP requests per second can the device handle after an SSL connection is established.  In HTTP 1.1, a client is allowed to make multiple HTTP requests off a single TCP/SSL connection.  This is far more efficient than the old HTTP 1.0 standard, that required a separate TCP connection for each object.  Many sites will have pages with literally hundreds of objects (I’m looking at you http://vg.no).

The trick is how many HTTP requests per SSL connection?  Personally, I’d say anywhere between 10 to 20 is a pretty good place to start, but that’s not what everyone uses.  In an epically flawed fight that o3 magazine picked with F5, author John Buswell claimed that an Nginx-based box he built could handle 25,000 TPS.

The system had no problems handling over 26,590 TPS, the test lab ran out of capacity to generate additional transactions. Compare that to the F5 Networks Big-IP 6900 which handles a maximum of 25,000 TPS but carries a starting price tag of $55,000.

The box he used had 2 quad core Opteron CPUs that were in no way capable of doing 26,000+ new SSL connections per second without an SSL accelerator card (which he didn’t use).  A few thousand 1024-bit RSA operations per second at the most, but definitely not 26,000.

He likely made the mistake of opening a couple of SSL connection, and running 25,000+ HTTP request per second off those open TCP/SSL connections (which is not even close to a real world scenario).   25,000 HTTP requests per second is within the capabilities of his box.  This is not how F5 measures TPS, nor how any other vendor measures TPS.  Of course, I’m only guessing at his methodology, as he never bothered to share his testing methodology.  (F5 and other vendors share their methodology).

TPS versus CPS

While SSL throughput is pretty easy to measure and the definition is identical for all vendors, the terms TPS and CPS aren’t.  So what do they mean?  CPS (Connections per Second) can mean a couple of things.  For SSL, it would typically mean new SSL connections, requiring the asymmetric operation.  Some vendors use TPS for this definition (the T standing for an asymmetric transaction), while other vendors use CPS for the SSL portion, and TPS for the HTTP-within-an-SSL connection.

So it’s important to understand what’s being measured.  Different vendors have different ideas of what that means, although they are honest differences of opinions (things reasonable people can disagree on).  Most vendors are reputable and will outline the methodology they used to come up with their numbers (03 magazine did not).

The fact is, we’re more addicted to cookies than even Cookie Monster

Came upon this post on Slashdot.org, a criticism of HTTP cookies entitled “HTTP cookies, or how not to design a protocol“.    It goes into many of the security issues surrounding HTTP cookies, and how the popular criticisms (privacy) aren’t the real problems.

The problem is, HTTP cookies are absolutely vital to everything we do on the Internet. Any website that we visit where the server builds up customized content (even if it’s just selection which region we’re from, like on Fedex.com), depends up on cookies.

Want to play a nasty prank on a co-worker who doesn’t lock their screen when they leave their desk?  Disable cookies on their browser.  Nothing works.

Cookies are just about the only mechanism in use to create a unique relationship between a client and a server. In other words, a cookie is the only way to establish a session.  Other than cookies (or long URLs), the HTTP protocol does not

In the end, we’re worse than cookie monster with our cookie addiction.

In the networking realm, there is the concept of PDUs, or Protocol Data Units.  These are the discreet messages for a particular protocol.   Every protocol has them.  In Layer 2, the Ethernet protocol has the Ethernet Frame, and for Layer 3 the IP protocol has the IP packet, just to name a few examples.   Each of theses PDUs have their own format.

For the HTTP protocol, which operates on Layer 7, we also have a PDU: The HTTP message.  HTTP messages are further divided into two categories: HTTP requests and responses.

When your browser wants an object, such as an JPG or HTML file, it must make a properly formatted HTTP request.  The server responds with an HTTP object.  One object equals one request plus one response.  Typically the response includes the object, although sometimes the response says simply “file not found” (HTTP 404), “object moved” (HTTP 301 or 302), or even “access denied” (HTTP 400), among others.

But the thing to keep in mind is that every object, which is to say every JPG, HTML, Flash, CSS, MPEG, every individual file, will require its own HTTP request and will generate an HTTP response from the server.  A web page consisting of 10 objects will require 11 HTTP requests:  One for the HTML page itself, and 10 additional requests to pull all of the objects referenced in the HTML.

In the next post, we’ll discuss some tools you can use to troubleshoot HTTP requests and responses.

Benefiting from Moore’s Law to a great extent are load balancers/ADCs, where the lowest end device from just about every vendor can handle traffic loads in the 50-100 Mbps range.  Of course, throughput isn’t a terrible way of measuring performance capability of a load balancer (100 Mbps of large file downloads is a heckuva lot easier than 100 Mbps of tiny file connections), but it does relate well to one very important factor in web site serving:

How big is your pipe?

Businesses of all sizes have seen steady increases in their available bandwidth to be sure, but while the growth may be steady, for the most part it tends to be a slower growth rate.  Much slower than doubling every 18 months, like in Moore’s Law.   The result is that increasingly that the lower end offerings from vendors are more than sufficient to run a larger share of web sites out there.

There are a number of reasons for this.  We’re no longer experiencing the exponential accross-the-board growth rates in users that occurred during the dot-com boom.  While there are some sites going through a growth explosion, for most websites in this economic environment, growth rates of any kind are fairly extraordinary.  So extra bandwidth isn’t in as high demand. Secondly, if you’re hosting your own data center as many large businesses do, getting extra bandwidth is often time consuming.  Moving from a single DS3 (45 Mbps) to an OC-3 (155 Mbps) is going to take some time to get that order fulfilled.

Cisco’s ACE 4710 appliance comes with a default license of 1 Gbps of throughput.  F5′s entry-level BIG-IP 1600 LTM maxes out at 1 Gbps.   In the Enterprise market, 500-Mbps to 1 Gbps is about the rock bottom in terms of performance capability.  Yet many of the high-end clients of these vendors don’t push nearly that much traffic.

Companies that aren’t media or mega-content providers (such as Google, Youtube, Yahoo!, Facebook, etc.) that have web applications serving customers or businesses typically don’t go above 100-200 Mbps in traffic, even for some Fortune 500 companies.  Of course, there are exceptions, and there are quite a few factors involved in determining the traffic characteristics of a site. Companies that are offering media such as streaming video or audio often use third-party content providers, such as Youtube or Akami, so as to keep that bandwidth off their own pipe.

So we’ve got all this idle CPU time, so why not make use of it?  That’s what many vendors are doing, in both the enterprise and value markets. With the steady rise in CPU power while bandwidth consumption lags behind, vendors are throwing more and more capabilities into these devices to take advantage of the unused CPU cycles, such as caching, compression, Layer-7 inspection, etc.  Vendors are offering more functionality with the greater power they have available to them.

But that he may have used the wrong terminology for the performance testing he did (saying it was TPS instead of HTTP requests per second) shows that there’s a lot of confusion on benchmark terminology, so I’m going to go over some of the basics.

TPS

In the load balancing world, TPS (Transactions per second) refer to the number of new SSL connections initiated.  The new part is important, because each new SSL connection requires a relatively CPU-expensive asymmetric encryption operation.  This is why most load balancers that do SSL have a separate chip for SSL processing (SSL ASIC), which offloads the SSL functionality from the main CPU.

Once the first step of an SSL connection is completed, the encryption then shifts to the much more CPU-friendly symmetric encryption, which is often referred to as “bulk encryption”.  Pushing bulk encryption throughput is relatively easy for a load balancer, even without an SSL accelerator chip.

However, HTTP/HTTPS typically involve short-lived connections, so there is relatively little throughput, and a lot of connection setup/teardown. Hence the need to know the TPS rating of a given device.

Many vendors will offer tiered licensing for SSL TPS.  So keep in mind when they mean TPS, they usually reffer to *new* SSL connections per second.

Connection Rate versus Request Rate

There are two ways to measure “rates” with load balancers:  Connection rate, and request rate.  While they sound similar, when you get right down to it, they’re actually quite different.

Connection rate refers to the number of TCP connections per second a device can handle.  HTTP request rate refers to the number of HTTP requests the device can handle.  How are they different? You can have multiple HTTP requests in a single TCP connection.

When your browser goes to a web site, it firsts initiates a TCP connection to the server (or in our case, a load balancer load balancing traffic for servers).  In that TCP connection, your browser will typically make several HTTP requests over that connection.

Making multiple requests over a single TCP connection is a lot easier than making a TCP connection for every single request.  In fact, the original HTTP 1.0 specification required on TCP connection per request.  The HTTP 1.1 specification fixed that, by allowing the multiple requests per TCP stream.

Layer-4 versus Layer-7

When a load balancer operates in Layer-4 mode, it’s functioning a lot like a router.  In fact, it’s not doing much more than your wireless access point at home.  Very little memory is consumed with each new connection, and only the TCP/IP header information is evaluated.

When a load balancer operates in Layer-7 mode, it’s functioning more like a server.  The TCP session is terminated at the load balancer, and a new TCP connection is initated to the server.  HTTP requests are buffered in the load balancer’s memory in order to be evaluated.  This requires a lot more processing power and a lot more memory.

Obviously, a load balancer can handle more Layer-4 workload than Layer-7, so it’s important to know which mode you plan on using when it comes to performance.

For many situations, connecting from the same subnet as your real servers is not a big deal.  However, there are some situations where this is required.  One of the most common reasons I see is that one of the web application servers needs to connect to a VIP that distributes load between other servers on that same subnet.

Most server load balancing happens through NAT (Network Address Translation), with the only exception being DSR (Direct Server Return).  You have the option of two different types of NAT: Half-NAT and Source-NAT (SNAT).  In half-NAT, only the destination address is changed on the way in.  In SNAT, both the source and destination are changed.

If you’re using half-NAT, you cannot connect to a VIP from the same subnet a server resides on.  The reason for this has something to do with the 4-steps required to do server load balancing NAT.

Figure 1: Network Scenario

Take a look at the network scenario depicted in Figure 1.  In this diagram, you see a client with the IP of 10.1.1.1, a VIP on a load balancer with an IP address of 192.168.1.200, and a server with an IP address of 192.168.1.11 as well as some other devices.

Now, the NAT happens in 4-steps, regardless of whether the load balancer is operating in Layer 4 or Layer 7 mode.  Take a look at Table 1 and it’s companion figure, Figure 2.

Table 1: Half-NAT

Figure 2: Half-NAT Path

Because NAT is done on the way in and on the way out, the load balancer needs to be in the path of traffic on the way and on the way out.  With half-NAT, this is done by either being in the Layer 2 path of traffic, or somewhat more commonly, the load balancer is the default gateway.

Now look what happens when we try to connect from the client PC on the same network as the servers.

Note that only three-steps occured.  This is because the server responds directly to the client.  Since everything is on the same Layer 3 network, there’s no reason to go through a default gateway.  The critical 4th step doesn’t occur, so the source address for the server response to the client is invalid.  The client sent a connection to 192.168.1.200, and it got a response back from 192.168.1.11.  When that happens, the client’s IP stack correctly drops all the reponses.

One solution is to do SNAT.  By NATing the source and destination addresses simultaneously, ensure that traffic goes through the load balancer on the way in and on the way out.  Observe what happens when we do Full-NAT in Table 3.  You’ll note we’ve added a new IP address 192.168.1.5, the SNAT address (this can also be a pool of multiple IP addresses).

SNAT makes it possible to connect to the VIP from the same subnet that the servers are on.  But there’s one little problem:  The true source IP address is now hidden from the servers, so the server logs would show all connections as originating from 192.168.1.5.  Many web sites count on the true source IP address of the client showing up in the logs in order to munge the logs.

So you’re caught between a rock and a hard place.  On one had, you have the true source preserved with half-NAT, but you can’t connect to the VIP from the same subnet as the servers.  On the other hand, you can connect to the VIP from the same subnet, but the true source is hidden.

There is a third option if you’re using HTTP or HTTPS.  When you SNAT you can also insert the real source IP address as an HTTP header in the request.  The server, if configured, can then record the HTTP header in its log instead of the Layer 3 source address.  However, this requires configuring both the load balancer and all the servers.  For Apache, it’s a one line config change.  For IIS, it requires an ISAPI filter (such as this one from F5).

Selective SNAT

Instead of deciding between SNAT and half-NAT, some vendors have the ability to use both on a VIP, choosing which based on the incoming source IP address.  A couple of vendors offer this option, but since I happen to have an A10 Networks AX2200 from a recent review, so I’ll use that as an example.

The first step is to build an access list that matches the network that you want to be SNAT’d. This would normally be the subnet that your servers reside on, although there are situations where it would make sense to add in a few more subnets.

A10 uses the standard Cisco IOS-style ACL (including inverse bitmask: 0.0.0.255)  We’re just using it to match the server’s network, 192.168.1.0/24.

Then, in the configuration for the TCP/UDP port of the Virtual Server, we associate ACL 1 with an SNAT pool.

Now, any connection to the VIP originating from the server subnet gets SNAT’d, while everyone else gets half-NAT’d.  Allowing the same subnet to connect while preserving the source IP address for everyone else.  It’s the best of both worlds.

Typically, Apache Bench (ab) is installed with the base Apache install, from at least Apache 1.3 on.  This includes when Apache is installed on Windows.

You can check all of the available options on the ab documentation page, but here’s a (very) quick reference to using it.

Two of the most important options are “-n” for the number of total connections, and “-c” for how many concurrent connections are done at the same time.

For instance, using the option “-n 1000″ will do 1,000 requests, one at a time, to a target URL.

ab -n 1000 http://website.com/

One at a time is rarely an effective test, so it’s best to use the “-c” option to specify a high number of concurrent connections, such as 100.

ab -n 1000 -c 100 http://website.com/

If you use concurrency, ab will split the total number of requests up amongst the concurrent settings.  For instance, using the option “-n 1000″ will do 1,000 connections, but “-n 2000 -c 100″ will only do 20 requests from 100 different connections (2,000 / 100 = 20).  So it’s best to use a much larger number of total connections if you’re doing concurrency.

ab -n 100000 -c 100 http://website.com/

When ab is finished running, it will spit out a performance report, including such info as the time taken for tests, requests per second, wait time, etc.

Finished 1000 requests

Server Software:        Apache/2.2.9
Server Hostname:        localhost
Server Port:            80

Document Path:          /
Document Length:        45 bytes

Concurrency Level:      10
Time taken for tests:   0.427 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      320640 bytes
HTML transferred:       45090 bytes
Requests per second:    2341.45 [#/sec] (mean)
Time per request:       4.271 [ms] (mean)
Time per request:       0.427 [ms] (mean, across all concurrent requests)
Transfer rate:          733.17 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    2   0.4      2       3
Processing:     0    2   0.5      2       7
Waiting:        0    2   0.5      2       6
Total:          0    4   0.7      4       8

Percentage of the requests served within a certain time (ms)
  50%      4
  66%      4
  75%      5
  80%      5
  90%      5
  95%      5
  98%      5
  99%      5
 100%      8 (longest request)

The ab utility defaults to one request per TCP connection (KeepAlive turned off).  If you want to use KeepAlive, where multiple requests are made through a TCP connection, use the “-K” option, open up as many TCP connections as you specify in concurrency (“-c”) and make the total number of quests through those few open TCP connections.

The utility is a simple but power tool for testing load balancers and web servers.  It doesn’t tend to reflect real-world usage, but it can be useful for baseline testing and troubleshooting.  I’ve found it quite useful over the years.

SNAT (Source NAT)

Source NAT is a term that are most often used to refer to two similar yet distinct concepts:

1. An IP address (or pool of IP addresses), typically on a publicly routed address space, used to allow servers behind a load balancer, typically on a non-routed RFC1918 address space, to make outbound connections to the Internet.
2. An IP address (or pool of IP addresses) that resides on the load balancer used to make connections to the web server, making it appear that all requests come from the load balancer (as opposed to the actual client IP). Another term used in this scenario is full-NAT.

Scenario 1 Example: Let’s say you have a couple of web servers sitting on a non-routed IP address space (such as 192.168.1.0/24). The load balancer is handling inbound NAT, NATing from the public Internet to the private address space. However, the servers also need to be able to make outbound connections. That is, connections that originate from the servers to some IP address on the public Internet (to download Microsoft patches, for example). To do this, you would set up a public IP address on the load balancer to act as a source NAT, the very same way a Linksys wireless router would. To hosts on the Internet, it would appear as if the connections were coming from this source NAT IP.

Scenario 2 Example: Because of some network or other logistical requirement, you cannot make the load balancer the default gateway of the servers. The very basics of load balancing require that you make sure traffic hits the load balancer on the way out (with the exception of DSR). The solution is to use a source NAT IP on the load balancer to proxy requests. This makes it look like all the HTTP connections and requests are coming from the load balancer. It doesn’t matter what the default gateway of the servers is, so long as there’s IP connectivity to the servers. The servers don’t even need to be on the same subnet as the load balancer with a source NAT. This can cause problems with some web logging applications (there are solutions to this), but it often greatly simplifies how a load balancer is placed in a network.

Persistence

When persistence is mentioned in the context of load balancing, it’s a pretty familiar term. Also referred to as sticky or server affinity, it’s the process of bypassing the normal load balancing algorithm and sending a given user to the same server each time that user makes a request. This is a requirement for web applications that are stateful (and the vast majority of them are).

Persistence is also a term used in the HTTP protocol, and it means something very different than load balancer persistence. With HTTP persistence, multiple requests are made through the same TCP connection, and it’s part of the HTTP 1.1 specification. In HTTP 1.0, a separate TCP connection was made for each object fetched. This meant that an HTML page with 20 images on it would require 21 separate TCP connections (20 images + HTML page).

This was rather wasteful, since the objects could be as small as a kilobyte or two. With HTTP 1.1, persistence allowed multiple objects pulled per page, so only 1 TCP connection would be required to pull a page and its 20 images.

Transparent

Transparent can mean a couple of different things depending on what specific concept you’re talking about. With several load balancer products, the term transparent is used to refer to whether or not the true source IP address of a client is preserved or hidden.

• Transparent: The source IP address of the client is preserved. Web servers see connections coming from the actual clients. This is also referred to as half-NAT.
• Non-transparent: The source IP address of the client is not preserved. Web servers see connections coming from a source NAT IP address on the load balancer. This is also referred to as full-NAT.

Transparent is called half-NAT, because either the source IP address or the destination IP address is changed by the load balancer, but not both. Non-transparent is called full-NAT because both the source and destination IP addresses are changed.

Transparent can also mean how the load balancer is deployed in a network. In the firewall world, a “transparent firewall” is a firewall that is setup like a load balancer in bridge-mode. It intercepts traffic purely by being in the Layer 2 path, instead of the Layer 3. This is sometimes used in load balancer terminology, but not often.

If you have any other terms that you might be confused with, drop me a line and I’ll see if I can’t make a post out of it: tony [at] lbdigest [dot] com.