5 ms·

I think HTTP/2.0 should break backward compatibility and take a more advanced step than "little improvements like that". Killing TCP/IP completely and inventing

by X4 13y ago

I think HTTP/2.0 should break backward compatibility and take a more advanced step than "little improvements like that". Killing TCP/IP completely and inventing a more efficiently compressed, more government resistant and more easily encryptable Protocol would be highly anticipated. The reason is that even adopting HTTP2.0 in that state would take at least a decade or more. Here's stuff that backs my argument:s a) http://rina.tssg.org/docs/PSOC-MovingBeyondTCP.pdf http://rina.tssg.org/docs/PSOC-MovingBeyondTCP.pdf b) http://users.ece.cmu.edu/~adrian/630-f04/readings/bellovin-tcp-ip.pdf http://users.ece.cmu.edu/~adrian/630-f04/readings/bellovin-t... And here are more viable and real alternatives that not only increase the speed by a factor of n, but also increase security and compatibility to our mobile generation: http://www.fujitsu.com/global/news/pr/archives/month/2013/20130129-02.html http://www.fujitsu.com/global/news/pr/archives/month/2013/20... http://users.ece.cmu.edu/~adrian/630-f04/readings/bellovin-tcp-ip.pdf http://users.ece.cmu.edu/~adrian/630-f04/readings/bellovin-t... http://roland.grc.nasa.gov/nrg/local/sctp.net-computing.pdf http://roland.grc.nasa.gov/nrg/local/sctp.net-computing.pdf / http://tools.ietf.org/html/rfc4960 http://tools.ietf.org/html/rfc4960 http://www.qualcomm.com/media/documents/why-raptor-codes-are-better-tcpip-file-transfer http://www.qualcomm.com/media/documents/why-raptor-codes-are... PS: I was initially afraid that HTTP2.0 was optimized for Advertisers...pheww

ErsatzVerkehr 13y ago
> more efficiently compressed, more government resistant and more easily encryptable Protocol Probably these things should not all be done at the same layer.
- X4 13y ago
  indeed & I never said that.
qwerta 13y ago
>and take a more advanced step than Already done several times. Have look at UDP and its usages.
- X4 13y ago
  See the links in my post, did you check them? Most are UDP based.
jimktrains2 13y ago
> 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.
- X4 13y ago
  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?
  - jimktrains2 13y ago
    > 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.
wmf 13y ago
QUIC (which may become TCP 2.0 for HTTP/3.0 to run over) sounds like what you're looking for.
- nly 13y ago
  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.
  - wmf 13y ago
    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.
digitalsushi 13y ago
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)
- X4 13y ago
  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 http://en.wikipedia.org/wiki/Secure_Socket_Layer
  - gsnedders 13y ago
    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.

by X4 13y ago

ErsatzVerkehr 13y ago

> more efficiently compressed, more government resistant and more easily encryptable Protocol Probably these things should not all be done at the same layer.

X4 13y ago
indeed & I never said that.

qwerta 13y ago

>and take a more advanced step than Already done several times. Have look at UDP and its usages.

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

jimktrains2 13y ago

> 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.

X4 13y ago
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?
- jimktrains2 13y ago
  > 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.

wmf 13y ago

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

nly 13y ago
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.
- wmf 13y ago
  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.

digitalsushi 13y ago

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)

X4 13y ago
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 http://en.wikipedia.org/wiki/Secure_Socket_Layer
- gsnedders 13y ago
  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.