Hacker News Reader

> Killing TCP/IP completely and inventing a more efficiently compressed, more government resistant and more easily encryptable Protocol would be highly anticipated.

You do realize HTTP and TCP/IP reside at very different OSI stack levels, right? Reïnventing TCP is not HTTP's job.

eh, yes.. now what? You do realize that the HTTP RFCs define what protcols are used?

I know that most TCP improvements mostly add new behaviour to specific situations, especially congestion and yes I have read those papers/links. I know that many improvements are UDP based. So, I think you misread it. I said kill TCP/IP in order to replace it by something better and wished that HTTP/2.0 would be that anticipated step. Did you even check the alternatives, before going negative?

> Did you even check the alternatives, before going negative?

One does not need alternatives to dislike a system. Alternatives may affect if the system is used, but they don't negate criticism of it.

I don't think HTTP 2 should replace TCP/IP or any other protocol that low in the OSI stack. That is not what HTTP was designed for and I believe throwing out the ideas behind its creation and still calling a new protocol HTTP is disingenuous.

What is so difficult about encrypting HTTP with an SSL Layer?

SSL is a key you keep and an unlocked padlock you give someone. They use it to give back a box with no idea how to open it.

You configure a web server with a key and a padlock. It keeps the key and serves the padlock. How can this be improved? (Serious question, maybe it can - this concept still seems esoteric to many)

SSL has the concept of many central authority organs (many of them got compromised or hand their private keys to government agencies), there is the proposal of a web-of-trust to counter that, but it's not there yet.

Hmm, do you suggest a new protcol/idea/improvement? A TCP/IP alternative also needs a security layer (not necessarily SSL though).

No offense, but if it's so easy, then you may know something many scientists and researchers and cryptographers haven't discovered, in any case I'm happy and all ears, if you are willing to contribute to a solution.. http://en.wikipedia.org/wiki/Secure_Socket_Layer

Replacing SSL/TLS just because of the current CA system is absurd. Nothing in either requires CAs (indeed, in theory anyone can issue a root certificate, and that's very much a feature). The issue is how to convey what certificates are legimite and which are not, and that's a tangential issue to whether you allow trusted subtrees or not.

> more efficiently compressed, more government resistant and more easily encryptable Protocol

Probably these things should not all be done at the same layer.

indeed & I never said that.

QUIC (which may become TCP 2.0 for HTTP/3.0 to run over) sounds like what you're looking for.

QUIC lives on top of UDP. If we reinvent TCP on top of UDP we may as well just throw in the towel on IPv6 and embrace IPv4 + NAT. Why bother trying to fix layer 2 when we're content to fuck shit up on the higher layers for the sake of back compat? IPv6 is our chance to bring back end-to-end networking with stateless routers.

QUIC is the prototype; if you build an experiment that doesn't work in the short term then you never learn from it and you can't fix the flaws you didn't learn about. Once it's finished maybe it could become a real protocol instead of layered on UDP.

>and take a more advanced step than

Already done several times. Have look at UDP and its usages.

See the links in my post, did you check them? Most are UDP based.