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 the much more useful > > behavior of trying the first one first, and if that fails go and try > > the second one. Having real failover on the client would make running > > high availability web sites vastly easier. Hopefullyspdywill succeed > > and then then Google can get around to trying to help fix some of > > these other problems. -- Chromium Discussion mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-discuss
