[email protected] This thread would be better continued at: http://groups.google.com/group/spdy-dev/
On Dec 1, 5:44 pm, Shahms King <[email protected]> wrote: > On Nov 16, 3:11 pm, "[email protected]" <[email protected]> > wrote: > > > > > > > On Nov 14, 12:55 am, Bram Cohen <[email protected]> wrote: > > > > I've looked over thespdydocumentation, such as it is, and have a > > > bunch of questions and comments. > > > Thanks for taking a look > > > > First and foremost: What is the transition plan? I gather from a post > > > on this group thatspdyis supposed to be backwards compatible with > > > http, which would seem to imply that the client should somehow hint in > > > the initial (commmon to both) http headers that it supportsspdyand > > > that the server should somehow clearly indicate in its response that > > > it would like to proceed withspdy, but the exact details of what > > > hinting is acceptable aren't even alluded to in the current > > > documentation. It's very important that this be made clear, especially > > > if it isn't something along the lines of what I just said. There's > > > also the laudable but problematic comment thatspdyshould always use > > > ssl, but more on that later. > > > We need to nail this down. Here are the two leading options we like: > > a) Run over SSL & modify the SSL handshake to carry additional > > information about the protocol to select at the higher level. > > b) Roll the HTTP version number; only after a successful HTTP/2.0 (or > > whatever) versioned response does it move intoSPDYmode. > > c) Use the existing HTTP/1.1 functionality for exactly this, aka the > "Upgrade:" header and "101 Switching Protocols" response. > > e.g. > > Client: > > GET / HTTP/1.1 > Host: foo.com > Upgrade: SPDY/1.0 > <rest of initial headers> > > Server: > HTTP/1.1 101 Switching Protocols > <some headers, if you really want> > <blank line> > <SPDY response> > > --Shahms > > > > > > > > Terminating POST requests with an empty frame is a gross hack. Making > > > it have real semantics would be nicer and more flexible. For starters, > > > it could differentiate between cancelled and finished requests. > > > Maybe we have a hole in the docs; but there is a FIN_FLAG which can be > > carried on most of the control or any data packet. While you can send > > a zero-length frame with the FIN bit, more efficient is to just put > > the FIN bit on the last frame. > > > Cancelled requests are handled via the FIN_STREAM control frame. > > > > I'm skeptical of the proposed prioritization scheme's utility. While > > > there's nothing particularly wrong with including it, I suspect that > > > server-based heuristics for determining what to send first are likely > > > to work a lot better. The simplest such scheme is to send all html > > > objects first, followed by all flash objects, then images, and finally > > > video. Within each type sort by size and send the smallest objects > > > first. I suspect it's hard to improve on this simple approach. > > > Alright - you are just proposing mime-types instead of numbers, that > > is basically what we do but numbers are easier to sort. > > > Priorities are actually pretty critical, and subtle.SPDYis not > > aiming to merely optimize the way bits are flown across the network. > > We're trying to optimize for page-load-time. CSS files, in most > > modern browsers, turn out to block a large section of rendering. If > > they are delayed, or forced to compete for bandwidth with lower- > > priority requests (like images), overall PLT and time-to-first paint > > are significantly increased. The need for priorities amplifies in the > > presence of packet loss. We need to write a whole paper about this, > > because it is subtle, differs from the way other protocols have aimed > > to improve performance, and is very interesting :-) > > > > There's a very common use case which is supported suboptimally byspdy > > > as it currently stands, which is that when a user clicks a hyperlink > > > you generally want to cancel all currently pending requests from the > > > server and start a new one for the new page. One can send a whole slew > > > of cancels, but it would be a lot more elegant to have some kind of > > > request grouping built into the protocol. > > > Agree - we've discussed and hope to add this. Priorities, by the way, > > also can assist here with differentiating foreground and background > > page loads. This may sound like a minor nit, and in a way it is. But > > we really want the user to be free to load 10 pages from the new york > > times, and be assured that the foreground tab will load first and > > unencumbered. > > > > The documentation says thatspdyalways uses SSL. While I get very > > > excited at the prospect of ubiquitous web encryption, after mulling it > > > over my recommendation (and I cringe as I type this) is to view the > > > issue as outside the scope ofspdyand drop it. I'm fully in favor of > > > having an initiative to add encryption by default to http, but it's an > > > orthogonal issue with a whole other set of problems and tying any such > > > thing tospdyis likely to kill both of them. > > > When we think of protocols of the future, we think it is intolerable > > that you could connect to your bank and not have the site actually be > > your bank. Why our protocols allow this even today is embarrassing. > > The amount of money lost annually due to failing to protect > > communications is absurd. We have to solve it. > > > We will use this opportunity to improve SSL performance as well; and > > we believe that hardware has improved enough that the scalability > > issues here are minimal. > > > Finally, the one issue remaining is that of caching; using of SSL > > impairs caching significantly. But the web has evolved since 1995. > > Proxies are no longer the caching solution of choice. Edge networks > > are vastly superior in terms of performance, predictability, and > > cost. And.... they support SSL too - something that proxies never > > really could handle. > > > > On the plus side for using ssl, it encrypts the traffic, which is a > > > useful end in and of itself, and it makes the protocol able to go over > > > existing proxies. > > > Yes, it has deployment advantages :-) > > > > The first downside to ssl sounds stupid, but it's basically a deal > > > killer. When a connection is first initiated, the sending side doesn't > > > necessarily know if the receiving side wishes to speak ssl, and ssl > > > being a complete substitute at the connection layer has no way of > > > being transitioned to being on in an already transferring connection, > > > so basically you're stuck with no graceful transition plan. > > > I don't think this is true. See above. > > > > There's a > > > reason why http and https are separate protocols, and the one stupid > > > little fact that they require different urls is the main reason why > > > encryption of web traffic isn't a lot more widespread than it is > > > currently. > > > We could get into historical reasons why we are where we are. > > > I think the primary reason is that http existed first, and it didn't > > make sense to nuke all of http in favor of a costly, slow, and > > unproven SSL. Since then, we've lived with two protocols. > > > How many user studies showing that users don't notice the padlock > > indicating SSL do we need to read before we realize that users > > shouldn't need to make a conscious choice for security? > > > > The two aren't even comparable to each other - most sites > > > don't run an https server, and among those that do it's downright rare > > > for them to be the same content being transported over two different > > > protocols. > > > SPDYneeds to run side-by-side with HTTP and HTTPS already, so sites > > that don't want to upgrade, don't need to. > > > >Spdycan't do anything to make this situation better, and I > > > think it shouldn't try. It's far easier to simply allowspdyto work > > > over either http or https and let sites which want to get the > > > encryption and existing proxy compatibility benefits at the expense of > > > extra resources and cert brain damage of ssl to use https. If you'd > > > like to know my thoughts on what a good transition plan for getting > > > http widely encrypted are, I'd be happy to share them, but it's rather > > > far afield from and orthogonal tospdy, and would best be served as an > > > independent proposal. > > > I suspect we disagree on most of this stuff. If we're not ready to > > start building a secure internet now, when will we ever be ready? > > Remember - it will take years to rollout. We shouldn't be designing > > for today. We should be designing for tomorrow. > > > In the end, you may be proven right. Until that happens, we're aiming > > high - we want the web to be fast and all servers to be > > authenticated. End users will thrive if we are successful, both in > > terms of a faster internet and also because the web will be safer. > > > But, we need lots of smart folks to help figure out what the right > > choices are. Hope you'll stay engaged. > > > Mike > > > > Other problems with ssl include: it adds an extra round trip, it bulks > > > up the data with hash bytes for data integrity, it requires enough CPU > > > on the server that it could melt some high-volume sites, and the cert > > > policies are completely brain damaged. That last one is in principle > > > simple enough to fix: allow self-signed certs without giving the end > > > user a security warning, but that will inevitably ignite several holy > > > wars and make getting through a standards process a nightmare. The > > > others would be best served by using something lighter weight than ssl > > > which makes no pretense of man in the middle prevention, but that's a > > > whole other topic. > > > > Unrelated to all that, and likely outside the scope ofspdy, is the > > > brain damage in DNS. The biggest problems with common DNS practice are > > > that it simply gives an IP rather than a mapping from a service to an > > > (ip, port) pair, and that when it specifies multiple IPs the specified > > > behavior is to pick one randomly rather than > > ... > > read more » -- Chromium Discussion mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-discuss
