

Optimizing HTTP headers for ‘ajax’ webapps - ivanstojic
http://blog.mibbit.com/?p=143

======
tptacek
Reminds me of:

<http://cr.yp.to/sarcasm/modest-proposal.txt>

------
jwilliams
This is actually a good idea.

Google has already proposed a gzip content compression scheme that could
operate over a number of pages.

It would also be feasible for them to come up with a header compression scheme
- perhaps even in Chrome first.

~~~
axod
Agreed. I think a great option would be for the server to specify in a
response header that it doesn't care about any headers for the rest of the
keep-alive connection, unless they change.

X-Only-Send-Header-Changes: true

~~~
epi0Bauqu
axod, I came across this the other day: <http://axod.blogspot.com/>

I've been getting into comet a bit more lately, and am wondering (if you don't
mind telling of course) 1) what you are currently using on the backend and 2)
if you ever checked out Meteor (which I was playing with today)?

~~~
axod
I decided to write my own. Gives me much more flexibility and am able to
change, adapt, streamline the backend as much as I like. (Java nio) It peaks
at about 10k connections at the busy times at the moment (incoming and
outgoing). The backend code is about 22k lines of code, but that's everything
- not just the base comet server.

I did have a look at Meteor and some of the other comet type servers but they
didn't look like they would be a great solution for what I needed.

------
patio11
Sounds like premature optimization to me. You can't "save" bandwidth at the
sub-packet level. It is like trying to "save" space used on files of less than
a kilobyte in length -- you can do the math showing impressive theoretical
gains, but other layers of your hardware/software stack process the data in
chunks larger than that anyway, all your effort is for naught.

~~~
heyadayo
@patio11: Actually, you can save bandwidth at the sub-packet level. Ethernet
is a common link layer protocol that we can examine: It has a variable length
frame, and because it uses time-delimited bit-level framing, the smaller your
ethernet frame the quicker it can be sent. The only real caveat to axod's
article is that you often can't save on performance of intermediary systems
(routers) because they tend to pre-allocate blocks of memory for packets, so
no memory is saved when some packets are smaller. But your ISP doesn't meter
you at the link layer anyway (or often even the IP level), so the savings as
reported by the article are absolutely real in terms of bandwidth costs. (as
in money)

------
kwamenum86
Interesting technique and could spur thought in optimization tangential js
operations...but does 300 bytes really matter that much?

~~~
axod
as I say this will save mibbit 300GB/month So yes it does matter for me

~~~
kwamenum86
Ah, good point. With computes 300 bytes, 300 milliseconds, and other seemingly
minor values matter because they are multiplied by large numbers. Every bit
counts all the time I guess if you have a high traffic web app.

------
truebosko
Nice trick and a quick read. Thanks

------
est
just use comet istead

~~~
axod
People seem to be terribly confused as to what Comet is.

This is Comet if you really want to use that word. Comet goes over HTTP.

~~~
e1ven
I suspect that his point is-

Using long-lifed connections, and sliding more data through as time goes on,
avoids some of the overhead of additional HTTP headers that you see in opening
new requests and replies.

~~~
axod
That is good for _receiving_ data. Yes, having a single JSONP etc would save
some headers there. (Although creates other issues).

But for sending data from the browser, you can't do any other sort of
streaming, so you have to send a new request each time.

~~~
e1ven
Sure, I suspect he was referring to the server modifications section, not the
Javascript. The JS really is a clever idea, I didn't realize that was
configurable through JS!

Edit- Just checked the posting history of the OP. He looks like a troll. I
withdraw my comment, he was just being a jerk.

Cool demo, though. Very clever- I wouldn't have necessarily thought about the
header size in the sends.

