Web hosting

HTTP

About

• HTTP is a client/server, one-request/one-response protocol.
• Clients, also called user agents, submit requests for resources to an HTTP server.
• Servers receive incoming requests and process them by retrieving files from local disks, resubmitting them to other servers, querying databases, or performing other computations.

Pithy

Headers specify metadata about a request or response, such as to allow compression, or what types of content are accepted.

URLs

A URL is an identifier that specifies how and where to access a resource.

• URLs are not HTTP-specific; they are used for other protocols as well (.e.g, mobile operating systems use URLs to facilitate communication among apps)

scheme://[username:password@]hostname[:port][/path][?query][#anchor]

• hostname can be a domain name or IP address as well as an actual hostname.
• query section can include multiple parameters separated by ampersands. Each parameter is a key=value pair

Important

As with passwords, sensitive data should never appear as a URL query parameter because URL paths are often logged as plain text. The alternative is to transmit parameters as part of the request body. (You can’t really control this in other people’s web software, but you can make sure your own site behaves properly.)

TCP Connection Reuse

• TCP connections are expensive:
  • memory needed to maintain them
  • the three-way handshake to establish each new connection adds latency equivalent to a full round trip before an HTTP request can begin
• HTTP/1.0 did not include it; some developers added experimental support as an extension
• Connection: Keep-Alive was added informally to clients and servers, then improved and made the default in HTTP/1.1
• clients and servers send multiple requests over a single connection, saving the cost and latency of initiating and tearing down multiple connections

HTTP over TLS

• On its own, HTTP provides no network-level security:
  • URL, headers, and payload are open to inspection and modification at any point between the client and server
  • a malevolent infiltrator can intercept messages, alter their contents, or redirect requests to servers of its choice
• TLS (Transport Layer Security) runs as a separate layer between TCP and HTTP
• TLS supplies only the security and encryption for the connection; it does not involve itself at the HTTP layer

All versions of SSL are obsolete and formally deprecated, but the name SSL remains in wide colloquial use

Virtual hosts

• A single server can host more than one site at once

Question

how do you distinguish requests bound for admin.com from those bound for example.com if both kinds of traffic end up at the same network port?

Answer

Virtual hosts, provided by HTTP 1.1:

• defines a Host HTTP header that user agents set explicitly to indicate what site they’re attempting to contact
• servers examine the header and behave accordingly

Name-based virtual hosts combined with TLS is tricky under the hood:

Question

How do virtual hosts work over TLS, which encrypts the HTTP headers (including the Host: field)?

Answer

The problem is chicken-and-egg:

• TLS certificates are issued to specific hostnames, chosen when the certificate is generated
• the TLS connection must be established before the server can read the Host header, but without that header the server does not know which virtual host it should be impersonating, and hence which certificate to select

The fix is SNI (Server Name Indication). Two steps:

1. TLS handshake - client sends SNI (server_name extension) in the ClientHello, in cleartext, before encryption exists. Server uses it to pick the certificate (and TLS config / backend) to terminate the connection.
2. HTTP request - once the tunnel is up, the request carries Host: (HTTP/1.1) or the :authority pseudo-header (HTTP/2/3). The server uses that to route to the right virtual host.

Web Software

Web servers and HTTP proxy software

Features provided by web servers:

• Virtual hosts, allowing many sites to coexist peacefully within a single server
• Handling of TLS connections
• Configurable logging that tracks requests and responses
• HTTP basic authentication
• Routing to different downstream systems according to requested URLs
• Execution of dynamic content through application servers

Go and node.js have web severs built interally, they can handle HTTP without the need for seperate web servers.

NGINX is the recommended web server for production usage.

Load balancers

• Load balancers typically operate at layer 4 of OSI. They route requests based on IP and port.
• However they can operate at layer Layer 7 by inspecting requests and routing them according to their target URL, cookie values or other HTTP headeres.

As an added bonus, load balancers can improve security.

• They usually reside in the DMZ portion of a network and proxy requests to web servers behind an internal firewall.
• If HTTPS is in use, they also perform TLS termination: the connection from the client to the load balancer uses TLS, but the connection from the load balancer to the web server can be vanilla HTTP. This arrangement offloads some processing overhead from the web servers.

Caches

Caches live between clients and web servers and store the results of the most frequent requests, sometimes in memory. They can then intervene to answer requests for which they know the correct response, reducing load on the authoritative web servers and improving response times for users.

In caching jargon, an origin is the original content provider

You can use curl -H “Cache-Control: no-cache” to politely request a cache refresh. This is the same as invoking in a web browser

Proxy Cache

You can install a proxy cache at the edge of an organization’s network to speed up access for all users. When a user loads a web site, the requests are first received by the proxy cache

You can configure a proxy cache in two ways: actively, by changing users’ browser settings to point to the proxy; or passively, by having a network router send all web traffic through the cache server

Content Delivery Networks (CDNs)

A content delivery network (CDN) is a globally distributed system that improves web performance by moving content closer to users

When clients request content from a site that uses a CDN, they are routed to the closest node (called an edge server), thereby decreasing latency and reducing congestion for the origin.

Edge servers are similar to proxy caches. They store copies of content locally. If they don’t have a local copy of a requested resource or if their version of the content has expired, they retrieve the resource from the origin, respond to the client, and update their cache.

APIs

An API defines a set of methods through which a remote system can make use of an application’s data and services.

Web API calls are normal HTTP requests. They’re only “APIs” because the client and server have agreed, by convention, that certain URLs and verbs have specific meanings and effects within the domain of their interaction.

REST

REST (Representational State Transfer) is an architectural style of API design

applied to web services that 1) explicitly use HTTP verbs to communicate intent, and 2) use a directory-like path structure to locate resources. Most REST APIs use JSON as their underlying representation for data.

SOAP (not used anymore)

SOAP (Simple Object Access Protocol)

An older, rigid protocol for HTTP APIs that routes all calls through a few URLs using a heavy XML format, making payloads large and development cumbersome.

Web hosting in the cloud

For the sake of efficiency, we prefer to rely on vendor services when possible. Specifcally for load balancer, unless the ELB lacks a specific feature that you need, it is clearly the expedient choice.

Important

For the sake of your own sanity, avoid the building option unless the function in question is a core competence for your business.

Apache HTTPD

httpd is both the name given to the daemon’s binary and to the project. Ubuntu has taken the liberty of renaming httpd to apache2, which matches the name of the apt package but otherwise does little more than create confusion.

Although an entire httpd configuration can be contained in a single file, OS maintainers typically use the Include directive to split the default configuration into multiple files and directories

Debian and Ubuntu approach Apache config wierdly. In our experience, the Debian system is unnecessary and overly complex. A simple site-configuration subdirectory usually provides sufficient structure. If you’re running Debian or Ubuntu, though, it makes sense to stick with their defaults.

Virtual host configuration

When an HTTP request arrives, httpd identifies which virtual host to select by consulting the HTTP Host header and network port. It then matches the path portion of the requested URL to a Files, Directory, or Location directive to determine how to serve the requested content. This mapping process is known as request routing.

Logging HTTP

Keep web server logs on a dedicated partition to prevent a large log file from affecting the rest of the system. On most Linux distributions, the default package installation of Apache includes an appropriate logrotate configuration

Sticky sessions

Pithy

What are sticky session: proxy servers (HAProxy, etc.) can insert a cookie it’s own responses. Any future request form the same will include the cookie, the porxy server will use the value of the cookie to route the request back to the same server.

Resources

iana status codes