Interesting... anyone know more about this?
[1] http://en.wikipedia.org/wiki/Slow-start [2] http://blog.benstrong.com/2010/11/google-and-microsoft-cheat...
I guess CentOS will get this in 2020, sigh, still waiting for initrwnd 10 support.
The particularly unfortunate part is, as much of the world's commercial hosting runs on RHEL, it's the world that doesn't get this until 2020. Well, except for services that roll custom kernels.
Every so often I am tempted to fiddle with debian, looks like more and more people are thinking that way:
http://w3techs.com/blog/entry/debian_is_now_the_most_popular...
Another good reason to stick with RHEL is that they do a very good job of maintaining compatibility between minor releases. You're pretty much guaranteed to be able to install a third-party package across all minor releases. If it installed on 6.0, odds are it will install and work on 6.4 without issue. Others make no such guarantees.
RHEL has way, way better (and accurate) documentation than any other distro I've used, particularly when it comes to unattended installations and server configuration tuning. Other distributions tend to focus much more on desktop users than massive server installations and their particular needs.
It's a common complaint among people that RHEL is always too far behind the curve in terms of software packages. But really, your OS will be stale the day after you install it, much like a car loses so much of its value the day you drive off the lot. Freshness is a tempting siren, but can lead you onto the rocks.
If you're a sane implementor, you're going to stick with any distribution you choose over the course of several years. You will favor uniformity over freshness, and stability over constant (and arguably needless) work. And no matter what distribution you choose, you are very likely to roll your own packages of whatever software is critical to your business, as you'll need custom patches and so forth.
If you care about taking advantage of prompt security updates from your distro provider, you will do this as little as you possibly can. Otherwise you need to pick up that burden yourself, and since most of us aren't security pros, it is a weight that should be assumed with great reluctance. You're no doubt familiar with the dilemma: Are you going to attempt to maintain stability (which isn't at all guaranteed) by backporting patches, or annoying your ops people by forcing version upgrades?
To a certain extent, how bad this gets is a function of how out-of-date your distro is. This is where having packages that are 4 years old can bite you -- you end up rolling your own far more often than you really should. Overuse of tools like virtualenv leads to the same problem.
If you're betting your business on this software and are operating at scale significantly larger than the typical Web service, odds are you're not going to live on the distro-provided packages for very long.
In comparison, I think "sarge" was the stable Debian in 2005. "sarge" is no longer oldstable- nor is etch. oldstable is "lenny", released in 2009.
Don't get me wrong, I like Debian, but when you compare "ease of upgrading", don't forget to consider "need to upgrade"!
But everytime I want to do something slightly interesting on our linux boxes, I'm thwarted by everything being so damn out of date on RHEL.
I can't run Sublime Text2, which irritates me, but worse I was wanting to use node-webkit for an experimental project and I can't even run that.
I'm more devops than sysadmin, so more expertise may have changed my experience, but when I did run a CentOS server, I thought, "yay, this is great"... until it came time to actually update.
Then, I realized that I had simply been accumulating up all of my upgrade pain as debt - with compound interest.
By comparison, upgrading Debian servers from version to version felt like hopping from bed to bed in a mattress store. Aside from a missed footing or two, it was usually a nice soft landing.
This is a huge downside for me. I worked for a remove server management company, and every time I had to work on a new (to us) RHEL4 or RHEL5 server (or CentOS equivalent), it was like pulling teeth. In order to run half the software our clients needed, I had to compile newer versions of daemons, create our own RPM packages, patch and recompile code. RHEL5 didn't even include memcached for crying out loud!
For 'enterprise deployments' I can understand wanting to go with RHEL if you don't know much about server administration and want to make it 'easier' on yourself, but even for basic web apps, most of the software you'll want to use is absent, out-of-date, or incompatible. I can't imagine anyone working for a startup wanting to use it.
It's API/ABI stability, and it's meant to be a feature of RHEL.
In fact, many of the security considerations are the same.
Except it's no longer SYN flooding at that point, it's full HTTP request flooding.
But in a sense isn't that really the goal of this design? To make it a bit more efficient to get requests to the application layer?
In any case, it seems like an application using this feature to have an efficient way of disabling it if it can't handle the current load. Kernels could add efficient heuristics to throttle it automatically too.
I'm more concerned that a bug in the entropy of the key generation process could turn these servers into massive reflected DoS amplifiers. E.g., the attacker sends 1 packet with the source address spoofed and the webserver replies with an entire HTTP result to the victim.
6.3 still does not support initrwnd which needs a minimum kernel of 2.6.38