Every day GoSquared’s tracking infrastructure processes billions of HTTP requests. We’ve spent a lot of time making the servers that process these requests as efficient as possible. We try\u00a0to reduce the average payload size of those requests as much as possible to keep bandwidth low.<\/p>\n
The average response in one of our tracking requests looks something like this:<\/p>\n
_gs('_4');<\/code><\/pre>\nThat’s ten bytes. Now, you might think that’s pretty damn small but there’s a problem. Here are the actual bytes that get sent over the wire from one of our servers to serve that request:<\/p>\n
HTTP\/1.1 200 OK\\r\\n\nConnection: keep-alive\\r\\n\nTransfer-Encoding: chunked\\r\\n\nContent-Type: text\/javascript\\r\\n\nDate: Wed, 18 Feb 2015 17:44:12 GMT\\r\\n\n\\r\\n\n10\\r\\n\n_gs('_4');\\r\\n\n0\\r\\n\n\\r\\n<\/code><\/pre>\nOuch! That’s quite a lot of extra stuff added to the\u00a0actual message body. Those headers add up. If you’re\u00a0unfamiliar with the behaviour of the Transfer-Encoding header, you may also be wondering what’s up with that 10\\r\\n...\\r\\n0\\r\\n\\r\\n<\/code>\u00a0wrapped around our response payload. It’s\u00a0called chunked<\/strong> encoding and is a way of sending data over HTTP when you don’t know in advance exactly how big the payload will be.<\/p>\nContent-Length vs. Transfer-Encoding: chunked<\/h2>\n
When a browser (or any other client making a HTTP request) processes the response from a server, it needs to know when it’s finished. Essentially, the client needs to be able to tell the difference between the server having finished sending its response data versus\u00a0there being a brief pause in bytes coming in over the wire. There are two ways this can happen:<\/p>\n
The Content-Length header<\/h3>\n
This is the simplest way for a server to tell the browser when it’s done sending data. When the response is sent, the header section will include a line of the format Content-Length: XYZ<\/code>. The browser then knows that after the header section, there are XYZ<\/code> bytes of body to read, after which the response is complete.<\/p>\nHowever, there’s a problem with this. The server might want to start sending the response before knowing how big it’s going to be. For example, if it’s reading a large file from disk, or proxying a request from elsewhere, it doesn’t want to have to load the whole response into memory in order to read its byte length and then<\/em> send it out over the wire. The solution to this problem is chunked encoding<\/strong>.<\/p>\nTransfer-Encoding: chunked<\/h3>\n
Chunked encoding is signified by the presence of a Transfer-Encoding: chunked<\/code> header in the response. The server then sends the response in “chunks” which take the format LENGTH\\r\\nPAYLOAD\\r\\n. <\/code>Finally, it then finished the response with a zero-length chunk, as can be seen above. This is great for servers that don’t need to know payload size ahead-of-time. It’s\u00a0not-so-great for situations like ours. We send billions of teeny-tiny responses every day and we’re counting every single byte.<\/p>\nWhat we did<\/h2>\n
Prior to a few days ago, all responses sent from our tracking endpoints used chunked encoding \u00a0because that’s the default behaviour for a HTTP server created in Node.js. By explicitly setting a Content-Length<\/code> header, we effectively disabled chunked encoding and saved a bunch of bytes in the process.<\/p>\nHere’s the line that we added:<\/p>\n
response.setHeader('Content-Length', Buffer.byteLength(body));<\/code><\/pre>\nThis changed the response payload from what you saw\u00a0above, to this:<\/p>\n
HTTP\/1.1 200 OK\\r\\n\nConnection: keep-alive\\r\\n\nContent-Length: 9\\r\\n\nContent-Type: text\/javascript\\r\\n\nDate: Wed, 18 Feb 2015 17:44:12 GMT\\r\\n\n\\r\\n\n_gs('_4')<\/code><\/pre>\n