Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

HTTP 2.0 Will Be a Binary Protocol

timothy posted 1 year,15 days | from the cram-your-stuff-in-this-box dept.

The Internet 566

earlzdotnet writes "A working copy of the HTTP 2.0 spec has been released. Unlike previous versions of the HTTP protocol, this version will be a binary format, for better or worse. However, this protocol is also completely optional: 'This document is an alternative to, but does not obsolete the HTTP/1.1 message format or protocol. HTTP's existing semantics remain unchanged.'"

cancel ×

566 comments

Makes sense (3, Interesting)

thetagger (1057066) | 1 year,15 days | (#44227569)

HTTP is the world's most popular protocol and it's bloated and slow to parse.

Re:Makes sense (5, Insightful)

cheesybagel (670288) | 1 year,15 days | (#44227641)

It might be bloated and slow. But it is also easily extendable and human readable.

Re:Makes sense (1, Insightful)

Lisias (447563) | 1 year,15 days | (#44227723)

It might be bloated and slow. But it is also easily extendable and human readable.

What's could be good if HUMANS were intended to read it.

Re:Makes sense (5, Insightful)

Progman3K (515744) | 1 year,15 days | (#44227853)

It might be bloated and slow. But it is also easily extendable and human readable.

What's could be good if HUMANS were intended to read it.

Yeah, it's a good thing no humans work as programmers or ever debug this thing

Re:Makes sense (-1)

Anonymous Coward | 1 year,15 days | (#44228013)

This is why humans read the protocol directly, instead of say, using a protocol analyzer software like wireshark,.... oh wait

Re:Makes sense (5, Interesting)

dgatwood (11270) | 1 year,15 days | (#44228129)

I frequently get fairly close to the raw protocol, using curl, and have even been known to manually make HTTP requests in a telnet session on occasion. That said, I'm assuming a future version of curl would simply translate the headers and stuff into the historical format for human readability, making this sort of change fairly unimportant in the grand scheme of things.

Re:Makes sense (0)

lgw (121541) | 1 year,15 days | (#44227789)

Binary formats are just as easy to make extendable. Whether a format is extendable or not has very little to do with the encoding scheme chosen for things like numbers.

Human readable is a bug, not a feature. Bandwidth is an important expense, and "human readable" means you pay 2x or more for bandwidth, for no real gain.

Re:Makes sense (5, Insightful)

Anonymous Coward | 1 year,15 days | (#44227929)

The amount of text that comes with HTTP is pretty inconsequential compared to the payload it's carrying.

Re:Makes sense (4, Interesting)

omnichad (1198475) | 1 year,15 days | (#44228337)

Except cookies. And even worse - ViewState variables posted on badly coded .NET applications. Some of those are near the hundred kilobyte range.

Re:Makes sense (5, Insightful)

h4rr4r (612664) | 1 year,15 days | (#44227989)

Says someone who never has to debug a damn thing.

Re:Makes sense (3, Insightful)

CadentOrange (2429626) | 1 year,15 days | (#44228163)

+1 If I had mod points. I've found the readability of HTTP crucial on numerous occasions.

Re:Makes sense (2, Informative)

Joce640k (829181) | 1 year,15 days | (#44228343)

Ditto.

The HTTP header is miniscule compared to the HTML/images on the web page. Making it binary is a Stupid Fucking Idea.

Re:Makes sense (-1)

Anonymous Coward | 1 year,15 days | (#44228179)

So, in order to facilitate debugging which can be done with tools, we should make trillions of other transactions less efficient.

Re:Makes sense (5, Insightful)

denbesten (63853) | 1 year,15 days | (#44228265)

Human readable is a bug...

Says someone who never has to debug a damn thing.

Amen, Ditto, etc.
If only there were some way [wikipedia.org] to both make it "human readable" and to somehow reduce the bandwidth.

Re:Makes sense (0)

Anonymous Coward | 1 year,15 days | (#44228345)

I use the proper tools to debug "a thing." Human-readability is irrelevant.

Re:Makes sense (2)

Alomex (148003) | 1 year,15 days | (#44228165)

Human readable is a bug, not a feature.

[Citation needed]

for no real gain.

Right, because making it easier to debug is not a real gain, but an imaginary one, and also bandwidth being so expensive one can barely afford the extra 1K of headers from HTML. I mean nowadays sending that can take as long as 1 millisecond over a slow connection. Who has that kind of time?

Re:Makes sense (2)

steelfood (895457) | 1 year,15 days | (#44227863)

You can also make binary blobs human readable. Just have an official spec on how to translate binary into English.

take me back to (4, Insightful)

mjwalshe (1680392) | 1 year,15 days | (#44227939)

the joys of debugging x.400 and reading a x.409 dump *NOT*

Why is it that news Internet standards seem to want to go down the route that the OSI did -

Re:take me back to (1)

K. S. Kyosuke (729550) | 1 year,15 days | (#44228219)

I'd have thought that just because there are bad binary standards doesn't mean that all binary standards have to suck.

Re:Makes sense (4, Informative)

PhrostyMcByte (589271) | 1 year,15 days | (#44228027)

It might be bloated and slow. But it is also easily extendable and human readable.

Human readable yes, extendable no. Well, it's not extendable in any meaningful way. Even though it looks like it on a quick look, if you read the spec you quickly realize there really is no generic structure to a message -- you cannot parse an HTTP request if you do not fully understand it. Even custom headers like the commonly used X-Foo-Whatever are impossible to parse or even simply ignore, so implementations just use an unspecified de-facto parsing and pray to the web gods that it works.

This makes HTTP parsers very complicated to write correctly and even moreso if you want to build a library for others to extend HTTP with. This isn't a text VS binary issue, but simply a design flaw. Hopefully HTTP 2.0 fixes this.

As they say, HTTP 1.1 isn't going anywhere -- this'll be a dual-stack web with 2.0 being used by new browsers and 1.1 still available for old browsers/people.

Re:Makes sense (0)

nschubach (922175) | 1 year,15 days | (#44228125)

X headers are for browser specific and/or programs written to understand them. If you didn't create it or use it for any real purpose, why are you trying to parse it? Just skip to the end of the line and pick up the next header that you know how to deal with.

Re:Makes sense (0, Redundant)

PhrostyMcByte (589271) | 1 year,15 days | (#44228369)

That's my point -- you can't simply skip to the next line. Where a HTTP header's value ends and the next header begins is dependent on the header. They can even span multiple lines. Custom headers are impossible to parse correctly, so implementations usually just assume they'll be on a single line, or maybe quoted like some of the standard headers allow.

Re:Makes sense (4, Funny)

ArcadeMan (2766669) | 1 year,15 days | (#44228145)

As they say, HTTP 1.1 isn't going anywhere -- this'll be a dual-stack web with 2.0 being used by new browsers and 1.1 still available for old browsers/people.

In Korea, HTTP 1.1 is for old people.

Re:Makes sense (1)

dgatwood (11270) | 1 year,15 days | (#44228173)

This makes HTTP parsers very complicated to write correctly and even moreso if you want to build a library for others to extend HTTP with.

I knew Jack Moréso, and HTTP, sir, is no Jack Moréso.

Re:Makes sense (0)

Anonymous Coward | 1 year,15 days | (#44227651)

And easy to debug thanks to telnetting to port 80 (or whatever).

Re:Makes sense (1)

Lisias (447563) | 1 year,15 days | (#44227805)

Easily fixable by writing a HTTP binary client TELNET style.

This kind of complain remembers me a time when my mails would be rejected on a mailing list if not hard formatted using 76 columns. The list owner liked using a old unix MUA (just for the sake of it) that didn't know how to do line wrap.

He could, of course, use MUTT - but by some reason he wanna use that crappy old MUA.

HTTP and SMTP should be binary decades ago.

I already were using binary mail transfer protocol on my BBS days.

Re:Makes sense (1)

tepples (727027) | 1 year,15 days | (#44227927)

Easily fixable by writing a HTTP binary client TELNET style.

Then the problem comes when you're the first person to write such a client for a given platform, and you're trying to assure this client's correctness.

Re:Makes sense (1)

gmuslera (3436) | 1 year,15 days | (#44227923)

Considering that most of http should go now to port 443 (and with perfect forward secrecy, to make it harder), and that is a bit more complex to debug it by telnet, it could not be a great loss.

Anyway, will miss the good times when telnetting to port 80, 25, 110 and so on were common debugging tool.

Re:Makes sense (1, Insightful)

UltraZelda64 (2309504) | 1 year,15 days | (#44227659)

Most popular protocol? What ever happened to TCP?

Re:Makes sense (1)

asmkm22 (1902712) | 1 year,15 days | (#44227699)

I think it can be argued that most popular doesn't always mean most implemented.

Re:Makes sense (0)

Anonymous Coward | 1 year,15 days | (#44227793)

I think it can be argued that most popular doesn't always mean most implemented.

99.99999999999999999999999999999999% of http connections are over tcp...

Re:Makes sense (1)

aliquis (678370) | 1 year,15 days | (#44227709)

Most popular protocol? What ever happened to TCP?

What happened to IP?

See what I did there?

Re:Makes sense (-1)

UltraZelda64 (2309504) | 1 year,15 days | (#44227765)

Yes, but considering TCP is a core part of IP... what you did kind of falls flat.

Re:Makes sense (1)

Anonymous Coward | 1 year,15 days | (#44227855)

You got it backwards. TCP is a layer 4 protocol, IP is a layer 3 protocol. Lots of packets are send over UDP and not TCP, but they still use IP underneath.

Re:Makes sense (0)

Anonymous Coward | 1 year,15 days | (#44227895)

Do you guys even OSI?

Re:Makes sense (4, Informative)

Progman3K (515744) | 1 year,15 days | (#44227899)

Yes, but considering TCP is a core part of IP... what you did kind of falls flat.

Nope, that's like saying hamburgers are a core part of cows.

You make hambugers out of cows, you don't make cows out of hamburgers.

You make TCP out of IP, you don't make IP out of TCP.

Re:Makes sense (1)

x0ra (1249540) | 1 year,15 days | (#44228235)

You make TCP out of IP, you don't make IP out of TCP.

Actually, TCP and IP are totally independent protocol.

Re:Makes sense (0)

Anonymous Coward | 1 year,15 days | (#44228253)

Now, the porterhouse steak, on the other hand, is a core part of the cow. Thing comes from right in the middle.

Re:Makes sense (0)

Anonymous Coward | 1 year,15 days | (#44227949)

Considering TCP (layer 4) is a completely separate protocol from IP (layer 3), you are a complete moron. aliquis is correct.

Re:Makes sense (0)

UltraZelda64 (2309504) | 1 year,15 days | (#44228117)

Maybe I should have clarified that I was talking about the Internet Protocol SUITE.

Re:Makes sense (4, Funny)

Anonymous Coward | 1 year,15 days | (#44227773)

Wrong! .Its UDP. I sent a note to asking him to confirm this fact, but he never replied.

Re:Makes sense (4, Funny)

plover (150551) | 1 year,15 days | (#44227975)

Knock-knock.
Who's there?
UDP packet.
UDP packet who?

Re:Makes sense (2, Informative)

SuricouRaven (1897204) | 1 year,15 days | (#44228069)

*silence*

Re:Makes sense (5, Funny)

dgatwood (11270) | 1 year,15 days | (#44228263)

And then there's the joke one of my coworkers wrote on his whiteboard: "I know a joke about UDP, but you might not get it."

Re:Makes sense (3, Funny)

Em Adespoton (792954) | 1 year,15 days | (#44228299)

Knock-knock.
Who's there?
UDP packet.
UDP packet who?

Knock-knock.
UDP Packet
Who's There? ....

Re:Makes sense (5, Funny)

WaffleMonster (969671) | 1 year,15 days | (#44227779)

Most popular protocol? What ever happened to TCP?

From looks of the draft it has been reimplemented within HTTP.

Port multiplier (1)

tepples (727027) | 1 year,15 days | (#44227993)

At this point, some people will have the urge to rise and scream "Inner platform effect! Anti-pattern! [wikipedia.org] " But consider that HTTP is like opening a separate port for every URL, so that you're no longer limited to having one instance of an application listen for connections.

Re:Port multiplier (0)

Anonymous Coward | 1 year,15 days | (#44228081)

A different port for every URL? Could you please explain?

Re:Port multiplier (4, Interesting)

tepples (727027) | 1 year,15 days | (#44228283)

With TCP, you need a separate port number for each service. For example, a Doom server runs on port 666, and an RDP server runs on port 3389. With Web Sockets, you can put all services behind one port and give each a separate path. For example, ws://example.com/doom lets a client open a Doom session, and ws://example.com/rdp lets a client open an RDP session. The advantage of using a path instead of a port number is that it can host a far larger number of services. For example, two users of a server could run game servers on ws://example.com/~WaffleMonster/doom and ws://example.com/~tepples/doom.

Re:Makes sense (1)

tandr (108948) | 1 year,15 days | (#44228155)

Folks, I don't know if you looked at the draft, but I think he was serious - take a look at section "5.1. Stream States"

Re:Makes sense (1)

bluefoxlucid (723572) | 1 year,15 days | (#44227697)

This binary protocol will be scrapped for JSON.

Re:Makes sense (3, Interesting)

Trepidity (597) | 1 year,15 days | (#44227965)

Not particularly bloated or slow to parse, especially on modern hardware. HTTP/2.0, which is basically a minorly tweaked version of Google SPDY, doesn't even claim speedups more than about 10%.

Re:Makes sense (1)

sl4shd0rk (755837) | 1 year,15 days | (#44228203)

it's bloated and slow to parse.

It was much less bloated before Javascript and CSS started throwing up in every corner of every webpage everywhere. A binary protocol isn't going to make up for bloat caused by "Mash all the things!" developer mentality.

Re:Makes sense (1)

Joce640k (829181) | 1 year,15 days | (#44228359)

HTTP is the world's most popular protocol and it's bloated and slow to parse.

Do you even know what HTTP is?

Maybe you're thinking of HTML or something.

Binary protocol.. and what else? (2, Insightful)

Anonymous Coward | 1 year,15 days | (#44227653)

It's nice to have a link to the draft. But couldn't we have just a little more "what's new" than it's binary? This is slashdot... Filled with highly techincal people. At least a rundown of the proposed changes would be very helpful in a discussion. The fact that they're proposing a binary protocol doesn't really matter to anyone besides anyone who wants to telnet to a port and read the protocol directly.

Re:Binary protocol.. and what else? (4, Informative)

gl4ss (559668) | 1 year,15 days | (#44227877)

It's nice to have a link to the draft. But couldn't we have just a little more "what's new" than it's binary? This is slashdot... Filled with highly techincal people. At least a rundown of the proposed changes would be very helpful in a discussion. The fact that they're proposing a binary protocol doesn't really matter to anyone besides anyone who wants to telnet to a port and read the protocol directly.

from quick glance, multiple transfers and communications channels("streams" in the drafts lingo) can be put through the single connection, cutting tcp connection negotiations.

Worth the tradeoff.. (1)

Midnight_Falcon (2432802) | 1 year,15 days | (#44227671)

Makes it harder to troubleshoot by using telnet to send basic HTTP commands, and speedily develop applications with nuts and bolts tools over plaintext -- but the tradeoff is it can transfer a ton of data over one TCP socket, greatly simplifying the network layer of HTTP, and most certainly adding a lot of performance. For webserver admins, this will make life a lot easier.

Re:Worth the tradeoff.. (2)

bluefoxlucid (723572) | 1 year,15 days | (#44227721)

HTTP already does that with pipelining. One connection, many files, optional compression on the body. The header is tiny.

Re:Worth the tradeoff.. (0)

Anonymous Coward | 1 year,15 days | (#44227871)

From what I learned when you goto a webpage you transmit to port 80 but it's some random port back to you. You can have it use a single port for both?

Re:Worth the tradeoff.. (1)

tepples (727027) | 1 year,15 days | (#44228049)

One connection, many files

HTTP/1.1 keep-alive and pipelining don't let the user agent cancel a (large) transfer in progress without closing and reopening the connection.

The header is tiny.

Unless things like Host:, User-agent:, and Cookie: need to be resent for each request.

Re:Worth the tradeoff.. (1)

0123456 (636235) | 1 year,15 days | (#44227727)

Maybe if the average web page didn't contain 16MB of Javascript these days, you wouldn't need to worry so much about how much data you can send over one connection.
 

Re:Worth the tradeoff.. (1)

robmv (855035) | 1 year,15 days | (#44227799)

don't worry we will make Javascript 2.0 binary too. With the number of compilers targeting Javascript I don't see this as a joke :(

Re:Worth the tradeoff.. (1)

jandrese (485) | 1 year,15 days | (#44227889)

Heck, I'm surprised there isn't a javascript virutal machine already in browsers that sites could pre-compile scripts for, especially with the advent of the webpage as an application. We're doing GL calls with a scripted language for gods sake.

While I'm sure modern browsers JIT compile javascript, it's amazing that we have to do that in the first place.

Re:Worth the tradeoff.. (4, Insightful)

plover (150551) | 1 year,15 days | (#44228055)

I know! We'll call this mythical virtual machine something catchy, like "Flash".

Re:Worth the tradeoff.. (1)

Anonymous Coward | 1 year,15 days | (#44227823)

Please, you're being too generous. That 16mb of Javascript exists so that it can custom-load another 24mb of Javascript which in turn loads the customized html for your user agent string, this is followed by the 124mb of Flash ads that are scheduled to be of higher load priority than the plaintext, but still below the Javascript over-structure. After that, then you've got the AJAX interface, because buttons and links are so 1992. Even this is assuming there aren't any specialized Java or ActiveX controls that you need to download and trust (or else the page will be replaced by a 'please install the following malware to view this page' error message).

And that's just to read the headline, the actual story is divided between 4 more such pages, even though the actual text content is shorter than this comment.

Re:Worth the tradeoff.. (1)

Kazoo the Clown (644526) | 1 year,15 days | (#44227883)

If you're worried about 16MB of Javascript code, you got bigger problems than whether the protocol is binary or not. And that suggests a new product feature-- a browser plug-in that blocks 1) any content using binary, and 2) any content over a maximum size, say 1MB. Less is more.

Re:Worth the tradeoff.. (4, Interesting)

lgw (121541) | 1 year,15 days | (#44227847)

Makes it harder to troubleshoot by using telnet to send basic HTTP commands

Since we're using a tool in the first place, it's just as easy to use a tool that understands the binary format. Back before open source toolchains had really caught on as a concept, human readable formats were a big plus, because proprietary tools could be hard to come by. Not really a concern these days, as long as the binary format is unencumbered.

Re:Worth the tradeoff.. (2)

belphegore (66832) | 1 year,15 days | (#44228063)

...unless you're on an embedded platform for which you don't have a compiler, and maybe busybox might build in this fancy new binary HTTP client tool in a few decades, but it'll be another few decades after that before manufacturers enable it and ship it.

Re:Worth the tradeoff.. (1)

WaffleMonster (969671) | 1 year,15 days | (#44228239)

but the tradeoff is it can transfer a ton of data over one TCP socket, greatly simplifying the network layer of HTTP

One thing it does not do is make anything more simple. Everything that was there must still be there plus a whole lot more.

, and most certainly adding a lot of performance. For webserver admins, this will make life a lot easier

This is not at all clear to me. Perhaps faster over fat low latency links sending hundreds of little thumbnail images... however vs multiple concurrent TCP sessions on high latency lossy links you are HOL stalled by multiplexing within TCP.

Concurrent TCP sessions has been a reasonably effective way of masking TCP/HTTP shortcommings. If you throw in some newfangled TCP options such as fast open/start even over reasonable links I would be surprised to see any difference v HTTP pipelining in real world benchmarks.

And aint it swell to hear they have chosen to reserrect CRIME attacks with header compression.

Does it improve coders? (4, Funny)

Freshly Exhumed (105597) | 1 year,15 days | (#44227681)

Can't wait to use the new 046102 047111 005113 tag!

Re:Does it improve coders? (0)

Anonymous Coward | 1 year,15 days | (#44227737)

It will make sniffing and diagnosing problems that much harder. But I welcome my new binary overlords.....

Re:Does it improve coders? (1)

lazarith (2649605) | 1 year,15 days | (#44227963)

If by "harder," you mean someone will need to re-code the sniffer program and the CPU will need to decode the traffic into human-readable format, then yes. But as far as the user/diagnoser is concerned, not really.

Re:Does it improve coders? (3, Informative)

Tailhook (98486) | 1 year,15 days | (#44228361)

Whatever problems you imagine are already being suffered in the form of SPDY. HTTP/2.0 emerged from SPDY and SPDY is supported by popular clients including Chrome and Firefox which handle traffic from Google, Twitter and Facebook, all of whom are serving SPDY today.

Wireshark has been picking apart SPDY for a couple years now. Developers see decomposed HTTP traffic in their browser consoles or HTTP APIs with little awareness of SPDY, so they rarely care.

Bandwidth costs money. Those rare instances when someone has to bench-check an HTTP transaction using a raw TCP stream have a really low priority.

Re:Does it improve coders? (0)

Anonymous Coward | 1 year,15 days | (#44227825)

Don't you mean the 001100010010011110100001101101110011? 110110... [0011000100...110011.com]

Re:Does it improve coders? (1)

binarylarry (1338699) | 1 year,15 days | (#44227917)

This is HTTP not HTML.

Re:Does it improve coders? (1)

ebh (116526) | 1 year,15 days | (#44228213)

OK, then the 046102 047111 005113 header.

SPDY (1)

phizi0n (1237812) | 1 year,15 days | (#44227693)

Isn't the HTTP 2.0 spec based on Google's SPDY protocol? It is basically just HTTP 1.1 but with header compression and the ability to either send or hint that extra files will be needed.

SPDY? (1)

PCM2 (4486) | 1 year,15 days | (#44227739)

I am not big on my networking protocols, but didn't the HTTP 2.0 group decide to base its work on Google's SPDY protocol? The two don't look the same to me, but some of the descriptions in this spec do look like reshuffled versions of the SPDY spec. What's the relationship between the two these days?

Re:SPDY? (2)

Shimbo (100005) | 1 year,15 days | (#44227891)

Draft 0 [ietf.org] was SPDY. It's usually the way that standards evolve from one proposal; cut and shut standards don't often work out.

Death to serialize! (0)

Anonymous Coward | 1 year,15 days | (#44227761)

I see a world where layout is delivered as it is now, and HTTP 2.0 is used for back-end communications. Streaming in content or responding to interactivity, and just generally being used to apply state to our currently stateless world.

It's really about multiplexing (4, Interesting)

Animats (122034) | 1 year,15 days | (#44227775)

The big change is allowing multiplexing in one stream. It's a lot like how Flash multiplexes streams.

Re:It's really about multiplexing (1)

TitusC3v5 (608284) | 1 year,15 days | (#44227845)

If you're working with binary instead of text, you should probably give it different name. HyperTEXT transfer protocol will be poor choice given the new format.

Re:It's really about multiplexing (1)

jandrese (485) | 1 year,15 days | (#44227931)

But it is still transferring hypertext? HTML is HyperText Markup Language. Just because the headers are binary encoded doesn't change what it is transferring. Granted, these days it might be more accurate to call it the JavaScript Transfer Protocol, because there is generally more JS than HTML on your typical page.

Re:It's really about multiplexing (0)

Anonymous Coward | 1 year,15 days | (#44227951)

It still transfers hypertext (HTML); it just does it compressed and multiplexed and encrypted.

Re:It's really about multiplexing (0)

Anonymous Coward | 1 year,15 days | (#44228093)

Ultimately networks serialize everything to bits, so "text" has been a misnomer from the beginning. It should have been the HyperBit Transfer Protocol, or HBTP. Right?

Actually HTTP/2.0 maintains the "text" nature of traditional HTTP. It provides multiplexing and pipelining so concurrent requests/responses can share a TCP connection without serializing and it simplifies and compresses headers. Ultimately, however, one can recover a given HTTP request/response such that it would appear compatible with legacy HTTP, although that isn't strictly true.

So no, we need not wrap ourselves around the axle over the "text" portion of the name.

Re:It's really about multiplexing (5, Interesting)

Trepidity (597) | 1 year,15 days | (#44227979)

It reads almost like they reimplemented all of TCP inside of HTTP, complete with stream set-up and teardown, queuing, congestion control, etc. Why not just use... TCP to manage multiple streams?

Re:It's really about multiplexing (4, Funny)

Anonymous Coward | 1 year,15 days | (#44228111)

You need something better to manage the streams.
What would happen if the streams crossed?

Re:It's really about multiplexing (5, Funny)

kimvette (919543) | 1 year,15 days | (#44228181)

> What would happen if the streams crossed?

Try to imagine all life as you know it stopping instantaneously and every molecule in your body exploding at the speed of light.

Avoids repeating TCP slow start (1)

tepples (727027) | 1 year,15 days | (#44228139)

Application-level multiplexing avoids repeating TCP slow start when the user agent starts downloading additional resources in parallel, such as style sheet, script, and images, or when the user agent stops a download before it has finished.

It's this simple (0)

Anonymous Coward | 1 year,15 days | (#44227787)

Hey, Microsoft -- see what they did here? THAT'S how you make a radical update to a computer standard or interface without pissing off your users.

Now admit you have to eat the whole crow, not just a nibble or two, and give us Win 8.2 or 9.0 that lets users banish Metro to the binary hell from which it crawled.

THIS IS A DRAFT, NOT HTTP 2.0 (5, Interesting)

Anonymous Coward | 1 year,15 days | (#44227909)

This is FAR from a done deal. The binary/ASCII question is being hotly debated.

New TCP (2)

qbast (1265706) | 1 year,15 days | (#44227985)

HTTP/2.0 defines stream multiplexing, framing, stream control, prioritizing - pretty much replicating TCP. What is the point of putting TCP-like protocol on top of TCP ?

Re:New TCP (1)

Anonymous Coward | 1 year,15 days | (#44228061)

TCP is purely bi-directional streaming. It doesn't have message framing, let alone the rest of that stuff.

Re:New TCP (1)

Crimey McBiggles (705157) | 1 year,15 days | (#44228191)

Ok, valid point. Why not implement these changes at the transport layer then? I'd venture a guess it's the same reasons security was pushed to the application layer (SSL, SSH, etc). It irks me to see the open web being destroyed by governments, so this news makes me think it'd be easier to embed backdoors, going from plaintext to binary.

Re:New TCP (0)

Anonymous Coward | 1 year,15 days | (#44228153)

Dude, I heard you like TCP so we put TCP inside your TCP.

Can someone describe in human terms (1)

Anonymous Coward | 1 year,15 days | (#44228007)

How does this benefit anything? I was under the assumption that most http traffic is compressed (usually gzip I think,) so while the ability to read the http directly exists easily, most transmissions were already binary, at least for the payload. How does making the headers and stuff binary benefit us that much? We're talking what .... maybe 2% of the entire message being optimized?

I'm an admin, not a app/web developer, so if someone knows, can you explain it in non-RFC terms that even those not familiar with the tech can understand?

Re:Can someone describe in human terms (4, Funny)

Intropy (2009018) | 1 year,15 days | (#44228277)

Think of it like a car, but instead of wheels, frame and engine, it uses binary.

FIRST. (-1)

Anonymous Coward | 1 year,15 days | (#44228011)

IS DYING LIKE THE own lube, beverage, a full-time gNAA unpleasant

What a clustferfuck (3, Interesting)

l0ungeb0y (442022) | 1 year,15 days | (#44228205)

Seems it's going binary to have EVERYTHING be a stream, with frame based communications, different types of frames denoting different types of data and your "web app" responsible for detecting and handling these different frames. Now I get that there's a lot of demand for something more than Web Socket, and I know that non-Adobe video streaming such as HLS are pathetic, but this strikes me as terrible.

Really, why recraft HTTP instead of recrafting browsers? Why not get Web Socket nailed down? Is it really that hard for Google and Apple to compete with Adobe that instead of creating their own Streaming Media Services they need HTTP2.0 to force every server to be a streaming media server?

Adobe's been sending live streams from user devices to internet services and binary based data communication via RTMP for several years, but HTML5 has yet to deliver on the bandied about "Device API" or whatever it's called this week even though HTML5 pundits have been bashing on Flash for years.

So if Adobe is really that bad and Flash sucks that much, why are we re-inventing HTTP to do what Flash has been doing for years?
Why can't these players like Apple and Google do this with their web browsers, or is it because none of these players really wants to work together because no one really trusts each other?

At the end of the day, we all know it's all just one big clusterfuck of companies trying to get in on the market Adobe has with video and the only way to make this happen in a cross-platform way is to make it the new HTTP standard. So instead of a simple text based protocol, we will now be saddled with streaming services that really aren't suited to the relatively static text content that comprises the vast majority of web content.

But who knows, maybe I'm totally wrong and we really do need every web page delivered over a binary stream in a format not too different from what we see with video.

Re:What a clustferfuck (1)

qbast (1265706) | 1 year,15 days | (#44228257)

What is wrong with HLS? Definitely simplest adaptive streaming protocol to work with.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...