On Nov 14, 12:55 am, Bram Cohen <[email protected]> wrote: > I've looked over the spdy documentation, 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 that spdy is 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 supports spdy and > that the server should somehow clearly indicate in its response that > it would like to proceed with spdy, 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 that spdy should 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 into SPDY mode. > > 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. SPDY is 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 by spdy > 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 that spdy always 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 of spdy and 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 to spdy is 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. SPDY needs to run side-by-side with HTTP and HTTPS already, so sites that don't want to upgrade, don't need to. > Spdy can't do anything to make this situation better, and I > think it shouldn't try. It's far easier to simply allow spdy to 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 to spdy, 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 of spdy, 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. Hopefully spdy will 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
