In this lesson, we’ll discuss HTTP (Hypertext Transfer Protocol). This is the foundation protocol of the current internet. We’ll look at why it’s important in AV, how it works, and where it can cause some performance concerns.
The HTTP protocol was first introduced in about 1990. However, by 1995, the idea of the worldwide web had moved beyond a vision and was quickly being developed. During the next four years, HTTP version 1.0 was standardized and the first browser appeared. At its formation, it was designed to transfer only text. However, during this same four-year period, modifications were made to allow it to transfer various forms of multimedia. Today, virtually all internet activity is based on its capabilities.
HTTP is a client-request, server-response protocol. There are a limited number of commands that a client (the browser) can send to the server to request a function be carried out. For example, a “GET” request might ask for a file. A “Post” command might request that a file to be uploaded be accepted by the server. Most often, commands are short, in clear text, and indicate the version of HTTP being used. Likewise, responses are limited to a few codes and a few actions. The response might indicate “OK” (I found the file) or “Re-direct” (you’ll need to get this file from another server). Client requests are sent to the server’s port 80. In fact, it’s the port 80 destination that indicates to management software and to the server that it is a web format request. This is used so widely that such requests are rarely blocked by firewalls. A common misconception is that the client also uses port 80. It does not. It uses a randomly assigned port, whatever the operating system chooses, but is always above 1024.
Aside from normal browsing, how do we use it in AV? To begin with, many devices can be configured using a browser. We simply open the browser, place the address of the device in the URL field and hit <Enter>. The device has a built-in browser that generally opens a page requesting the username and password. We also use HTTP in adaptive bit rate (ABR) video (DASH, HLS, Smooth Streaming, etc.). In this case, HTTP requests are sent to the server indicating the desired video file, bytes to be retrieved, and certain other metadata chosen from the manifest initially supplied by the server. Finally, HTTP is used in video referred to as WebRTC. This can be a conference between browsers with audio, video, either, or both.
Sometimes the poor performance of HTTP-based video is blamed on the design of the protocol. However, more often than not, the degradation is the result of one of several other factors. For example, it can be a result of the authentication procedures used to verify the video is authorized for delivery. ABR and device logins that require external authentication are sensitive to this issue. HTTP video streams, such as ABR, also use TCP and can be degraded by competing traffic, especially if the traffic is in the opposite direction. This may seem counterintuitive. But, I suggest you research some my other writings on the topic of bufferbloat to understand why.
HTTP traffic represents nearly 90 percent of the traffic on the internet. It’s apparent it will continue to be used by both AV and IT into the future.
Phil Hippensteel, PhD, is a regular AV Technology contributor. He teaches at Penn State Harrisburg.
