8 - Content Distrobution Flashcards
The web and Caching
Caches can improve web performance. We’ll learn about HTTP, which is that app layer protocol that your browser makes. HTTP is layered on top of a byte stream protocol like TCP usually. The server maintains no info about past clients bc they’re stateless.
HTTP Request contents
- The request line, which indicates the method of the request. A GET request returns the contents associated with a url. A POst sends data to the server, and a HEAD request returns only the headers of the GET request. GET requests can be used to send data to to the server too. The request line also includes the url which is relative, and is something like index.html. It also includes the version of the http protocol. It can contain additional optional headers.
Additional HTTP Headers
- The referrer: indicates the url that caused the page to be requested. If an oobject is being reequested as part of embedded content in another page, the referrer might be the page that’s embedding the content.
- User Agent: the client software being used to fetch the page. Like Chrome or FireFox.
HTTP Response
Includes a Status Line, which includes the http version and a response code.
Response Codes
100’s: typically informational
200’s: Indicate success, so for example 200 response code is common that indicates ok.
300’s: indicate redirects. 301 indicates a permanent redirect.
400’s: Client errors, 404 means not found.
500’s. Server errors.
Additional Response Headers
- Location, used for redirection.
- server, which indicates server software.
- Allow: describes how the content is encoded, if it’s compressed.
- content-length: indicates how long the content is in terms of bytes.
- Expires: indicates how long the content can be cached.
- Last Modified: indicates the last time the page was modified.
Early HTTP
only had one request or response per TCP connection. it was simple to implement but the drawback is that it requires a TCP connection for every request. Introducing a lot of overhead, slowing transfer. TCP 3 way handshake is needed for every request, and also TCP slow start for every connection. Short transfers are bad because of slow start. Also as TCP connections are terminated after every request is completed, the servers have many connections that are forced to keep TCP connections in time wait states, until the timers expire resulting in additional resources that the server needs to keep reserved even after the connections have completed. So a solution to increased efficiency is persistent connections.
Persistent Connections
Multiple http requests/responses are multiplexed onto a single TCP connection. Delimeters at the end of an http request indicates the end of a request, and the content length allows the receiveer to identify how long a response is. So the server has to know the size of the transfer in advance. Persistent connections can also be combined with something called pipelining. In pipelining a client sends the next request as soon as it encounters a reference object. So there’s as litle as one round trip time for all referenced objects before they began to be fetched. Persistent connections with pipelining is the default behavior in http 1.1.
Caching
To improve performance, clients cache parts of a web page. it can occur in multiple places. Your browser can cache objects locally, or caches can also be deployed on the network, sometimes your IsP may have a web cache, like CDN’s.
Caching improves performance
If the origin server is far from the client, we know that TCP throughput is inverseley proportional to RTT. so the further the content, the slower the web page will load. Both bc latency is bigger, and bc the throughput is lower. If the client can fetch content from the local cache, performance is improved, or by from a closer cache location. Caching can also improve the performance when multiple clients are requesting the same content. Now, not only do all th elocal clients benefit from the content being cached locally. But the ISP also saves costs on transit. BC it doesn’t have to pay to keep transferring the same content over the links. To ensure that clients are seeing the most recent version of a page, caches expire content based on an expire setter in the header. Caches also check with the origin server, to see if the origin content has been modified. If the content hasn’t been modified, the origin server responds to a cache check request with a 304 or a not modified response.
Directing Clients to caches
- One way is browser configuration. You open your browser and specifically config it to point to a local cache so all http requests first are directed to the local cache, before the request is forwarded to the origin.
- The second approach: the origin server or service hosting the content, might direct your browser to a cache. This can be done with a special reply to a DNS request. We can see these when we do a DNS lookup for Google.com. The response returns a number of IP addresses and when you ping the ip address, we see that the resulting ip address is only 1 millisecond away. Which indicates that the server is extremely close.