Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Small things add up: 4chan's migration to a cookieless domain

chrishateswriting.com

Post reply on HN
Print view View original

11–20 of 139 posts

Re: Small things add up: 4chan's migration to a cookieless domain

#11

Post by sliverstorm »

quchen wrote: post #7
sliverstorm wrote: post #3

Earlier quoted context omitted.

That's still 25GB/month of bandwidth they save. Who knows, maybe that nudges them out of a high-cost data tier.

My point was that "saving 25 GiB" is way below anything they can possibly care about. How much traffic does 4chan handle in a single hour? I think it's pretty safe to assume that 25 GiB is significantly lower than one standard deviation of their monthly traffic, so cutting costs with it is also not feasible.

Ok, so let's assume you are right. Did he make the wrong choice? The shorter name seems strictly better to me- whether we feel it is trivially better, it saves traffic and the domain name has lost no information.

If he reworked old code just to save 50 bytes, that would probably be a mistake, but it sounds like the work was being done anyway and he had the choice to save 50 bytes OR use a longer domain name.

Re: Small things add up: 4chan's migration to a cookieless domain

#12

Post by moot »

quchen wrote: post #2

> 50 bytes may not seem like a lot, but when you’re serving 500 million pageviews per month, it adds up. That's a void argument in the article. If they were serving pages with 500 bytes each this would indeed be a huge improvement, but no page is 500 bytes. I just opened 4chan.org, and the markup before is already 1,836 bytes. The entire frontpage of /b/ is 114,428 bytes, and saving 50 is absolutely negligible. On th…

You're absolutely right -- it is negligible. When you're serving upwards of a petabyte per month, 23 GB isn't exactly a lot!

> On the other hand, if saving single bytes was significant, there would be a lot more potential in the source by shortening CSS class names etc. rather than picking a short domain name.

Also spot on, but the point I was trying to make is I was given the choice of choosing a longer domain and a shorter one, and the shorter one resulted in smaller page size, which does result in some (though as you put it, negligible) savings in terms of transfer. CSS/JS refactoring/pruning would definitely be a better bang for your buck if your goal was solely to reduce page weight, but my primary goal was to decrease request overhead and this was just a side benefit at no additional cost to me.

As an aside, I would say the non-technical benefit of the longer domain (4chan-cdn.org) would have been avoiding user confusion, but I feel this is mitigated since visiting 4cdn.org directly bounces you to www.4chan.org and our custom error pages make 4cdn.org clearly 4chan related.

Re: Small things add up: 4chan's migration to a cookieless domain

#14

Post by tomp »

> If you’ve been linked directly to a Facebook photo, you may have noticed the domain wasn’t facebook.com, but instead something like fbcdn-x-x.akamaihd.net. Large sites load static content from special domains for a few reasons, but primarily to reduce request overhead, and sometimes security.

This works for 4chan, but in case of Facebook, it actually reduces security - since cookies cannot be checked for photos on static domains, everybody can access every photo (as long as they are given an URL), regardless of the photo's privacy settings. In the case of Facebook, they are probably using sufficiently random URLs that mostly mitigate the issue, but a naive implementation could be very problematic.

Re: Small things add up: 4chan's migration to a cookieless domain

#15

Post by moot »

pieter wrote: post #9

I doubt domain length will really make any difference, gzip compression should take care of a longer domain name.

The 50 bytes figure represents a compressed response. (We actually write all of our pages compressed to disk before serving them -- nothing is served dynamically. But that's for another post...)

The example below isn't the most scientific, but should give you a rough idea.

  Test index page with different static URLs:
  URLs as 4cdn.org -- 23261 bytes compressed
  URLs as 4chan-cdn.org -- 23311 bytes compressed
  URLs as 4chan.org (control) -- 23278 bytes compressed

Re: Small things add up: 4chan's migration to a cookieless domain

#16

Post by quchen »

moot wrote: post #12
quchen wrote: post #2

> 50 bytes may not seem like a lot, but when you’re serving 500 million pageviews per month, it adds up. That's a void argument in the article. If they were serving pages with 500 bytes each this would indeed be a huge improvement, but no page is 500 bytes. I just opened 4chan.org, and the markup before is already 1,836 bytes. The entire frontpage of /b/ is 114,428 bytes, and saving 50 is absolutely negligible. On th…

You're absolutely right -- it is negligible. When you're serving upwards of a petabyte per month, 23 GB isn't exactly a lot! > On the other hand, if saving single bytes was significant, there would be a lot more potential in the source by shortening CSS class names etc. rather than picking a short domain name. Also spot on, but the point I was trying to make is I was given the choice of choosing a longer domain and a…

Right, if you use a short domain name "because why not" for something new that's alright. It was just the "it adds up" part that I was commenting on.

Do you have (well, you're moot, so -- want to share) some more data of 4chan's current size? I'm sure lots of people would be interested in hearing about that. (This would probably make a great individual post.)

Re: Small things add up: 4chan's migration to a cookieless domain

#17

Post by moot »

tomp wrote: post #14

> If you’ve been linked directly to a Facebook photo, you may have noticed the domain wasn’t facebook.com, but instead something like fbcdn-x-x.akamaihd.net. Large sites load static content from special domains for a few reasons, but primarily to reduce request overhead, and sometimes security. This works for 4chan, but in case of Facebook, it actually reduces security - since cookies cannot be checked for photos on…

Totally. In our case the main security benefit is that we allow the uploading of SWFs, and it mitigates the threat of cookie stealing via Flash (which we've actually seen attempted). Previously we'd used 4channel.org for this, but I switched that over along with the migration to 4cdn.org.

Re: Small things add up: 4chan's migration to a cookieless domain

#18

Post by zachrose »

tomp wrote: post #14

> If you’ve been linked directly to a Facebook photo, you may have noticed the domain wasn’t facebook.com, but instead something like fbcdn-x-x.akamaihd.net. Large sites load static content from special domains for a few reasons, but primarily to reduce request overhead, and sometimes security. This works for 4chan, but in case of Facebook, it actually reduces security - since cookies cannot be checked for photos on…

I'm interested in learning more about _how_ secure random URL parts are, and what kinds of attacks are seen in practice. Presumably an IP would get blocked after enough 404s?

Re: Small things add up: 4chan's migration to a cookieless domain

#19

Post by maaaats »

adriancooney wrote: post #10

I never even contemplated the size of cookies before seeing this. It never occurred to me that it could create such an overhead. It'd be incredibly handy if we could set a header like `x-send-cookies: NO` to stop the browser sending cookies along for static content. Great post, a real eye opener.

Here as well. I knew of several reasons to serve static content from a different domain/cdn, but never thought of this cookie-benefit.

Re: Small things add up: 4chan's migration to a cookieless domain

#20

Post by moot »

sliverstorm wrote: post #11
quchen wrote: post #7

Earlier quoted context omitted.

My point was that "saving 25 GiB" is way below anything they can possibly care about. How much traffic does 4chan handle in a single hour? I think it's pretty safe to assume that 25 GiB is significantly lower than one standard deviation of their monthly traffic, so cutting costs with it is also not feasible.

Ok, so let's assume you are right. Did he make the wrong choice? The shorter name seems strictly better to me- whether we feel it is trivially better, it saves traffic and the domain name has lost no information. If he reworked old code just to save 50 bytes, that would probably be a mistake, but it sounds like the work was being done anyway and he had the choice to save 50 bytes OR use a longer domain name.

> If he reworked old code just to save 50 bytes, that would probably be a mistake, but it sounds like the work was being done anyway and he had the choice to save 50 bytes OR use a longer domain name.

Basically this. I thought it was an interesting side benefit that came at no additional cost to the main benefit of greatly reducing request overhead for static resources.

Post reply on HN