What is HTTP?

tl;dr - The Hypertext Transfer Protocol, or HTTP, is the predominant tool in the transferring of resources on the web, and a "must-know" for many application delivery concepts utilized on BIG-IP

HTTP defines the structure of messages between web components such as browser or command line clients, servers like Apache or Nginx, and proxies like the BIG-IP. As most of our customers manage, optimize, and secure at least some HTTP traffic on their BIG-IP devices, it’s important to understand the protocol. This introductory article is the first of eleven parts on the HTTP protocol and how BIG-IP supports it. The series will take the following shape:

  1. What is HTTP? (this article)
  2. HTTP Series Part II - Underlying Protocols
  3. HTTP Series Part III - Terminology
  4. HTTP Series Part IV - Clients, Proxies, & Servers — Oh My!
  5. HTTP Series Part V - Profile Basic Settings
  6. HTTP Series Part VI - Profile Enforcement
  7. HTTP Series Part VII - Oneconnect
  8. HTTP Series Part VIII - Compression & Caching
  9. HTTP Series Part IX - Policies & iRules
  10. HTTP Series Part X - HTTP/2

A Little History

Before the World Wide Web of Hypertext Markup Language (HTML) was pioneered, the internet was alive and well with bulletin boards, ftp, and gopher, among other applications. In fact, by the early 1990’s, ftp accounted for more than 50% of the internet traffic! But with the advent of HTML and HTTP, it only took a few years for the World Wide Web to completely rework the makeup of the internet. By the late 1990’s, more than 75% of the internet traffic belonged to the web.

What makes up the web? Well get ready for a little acronym salad. There are three semantic components of the web: URIs, HTML, and HTTP.

  • The URI is the Uniform Resource Identifier. Think of the URI as a pointer. The URI is a simple string and consists of three parts: the protocol, the server, and the resource. Consider
    . The protocol is https, the server is devcentral.f5.com, and the resources is /articles/. URL, which stands for Uniform Resource Locator, is actually a form of a URI, but for the most part they can be used interchangeably. I will clarify the difference in the terminology article.
  • HTML is short for the HyperText Markup Language. It’s based on the more generic SGML, or Standard Generic Markup Language. HTML allows content creators to provide structure, text, pictures, and links to documents. In our context, this is the HTTP payload that BIG-IP might inspect, block, update, etc.
  • HTTP as declared earlier, is the most common way of transferring resources on the web. It’s core functionality is a request/response relationship where messages are exchanged. An example of a GET message in the HTTP/1.1 version is shown in the image below.

This is eye candy for now as we’ll dig in to the underlying protocols and HTTP terminology shown here in the following two articles. But take notice of the components we talked about earlier defined there. The protocol is identified as HTTP. Following the method is our resource /home, and the server is identified in the Host header. Also take note of all those silly carriage returns and new lines. Oh, the CRLF!! If you’ve dealt with monitors, you can feel our collective pain!

HTTP Version History

Whereas HTTP/2 has been done for more than two years now, current usage is growing but less than 20%, with HTTP/1.1 laboring along as the dominant player. We’ll cover version-specific nuances later in this series, but the major releases throughout the history of the web are:

  • HTTP/0.9 - 1990
  • HTTP/1.0 - 1996
  • HTTP/1.1 - 1999
  • HTTP/2 - 2015

Given the advancements in technology in the last 18 years, the longevity of HTTP/1.1 is a testament to that committee (or an indictment on the HTTP/2 committee, you decide!) Needless-to-say, due to the longevity of HTTP/1.1, most of the industry expertise exists here. We’ll wrap this series with HTTP/2, but up front, know that it’s a pretty major departure from HTTP/1.1, most notably is that it is a binary protocol, whereas earlier versions of HTTP were all textual.

Updated Jun 06, 2023
Version 2.0

Was this article helpful?


  • The TCP connection setup behavior for a Standard virtual server varies depending on whether a TCP profile or a TCP and Layer 7 profile, such as HTTP, is associated with the virtual server.


    Hi Jason, While going through Eric's 201 guide , I found this to be confusing. How can tcp behavior be different for a Standard virtual server, as i am aware , there is always a default http profile in the backend. Can you help me understand this.


    Thanks! Sukesh Tandon


  • @Sukesh, the difference between TCP only and TCP+HTTP is how the server side is initiated. Without HTTP, the server side TCP handshake is initiated as soon as the handshake is completed on the client side. With HTTP, the BIG-IP waits for the first request from the client to initiate the TCP connection. Details are in K8082 on AskF5.


  • Hi Jason,yes you are correct. But If I configure a standard vip on port 80 and do not configure/associate any manual http profile. In such scenario, is there a default (hidden) http profile associated?


    Thanks for the response!


  • @Sukesh, no. In that scenario, it is only processed by BIG-IP as tcp traffic and the http filter is not applied the hud chain, so no http commands would work in iRules or local traffic policies.