 |
posted on Tuesday, November 17, 2009 4:20 AM
Google’s desire to speed up the web via a new protocol is laudable, but the SPDY protocol would require massive changes across networks to support  ArsTechnica had an interesting article on one of Google’s latest projects, a new web protocol designed to replace HTTP called SPDY.
 SPDY uses a single SSL-encrypted session between a browser and a client, and then compresses all the request/response overhead. The requests, responses, and data are all put into frames that are multiplexed over the one connection. This makes it possible to send a higher-priority small file without waiting for the transfer of a large file that's already in progress to terminate. Compressing the requests is helpful in typical ADSL/cable setups, where uplink speed is limited. For good measure, unnecessary and duplicated headers in requests and responses are done away with. SPDY also includes real server push and a "server hint" feature.
Having recently emerged from a trip into the world of service-providers and its associated protocols, the description of SPDY immediately brought to mind other asynchronous, message-oriented protocols such as SIP and DIAMETER. It therefore made me seriously consider the kind of massive changes that would be required to support such a protocol across all data center components: security, load balancing, acceleration, web servers, application servers, caches. Basically any network intermediary based on the premise of a strict request-reply, synchronous behavior would likely need radical changes to its core protocol handling systems.
MAJOR DIFFERENCES BETWEEN SPDY and HTTP
SPDY, as described, is asynchronous and message-oriented. Like DIAMETER, SPDY would allow multiple requests per connection, effectively turning a single connection designed to be used and then closed into a long-lived connection. This is more along the lines of a SIP connection which is initiated and held open until the session is terminated.This is very different from the HTTP model in which connections are opened and closed within fairly short time intervals and are not expected to be held open for exceedingly long periods of time. SPDY thus eliminates the overhead associated with opening and closing many connections and the negative impact that has on application performance. The current draft of the SPDY protocol states that “from the perspective of the server business logic or application API, nothing has changed”. But from the perspective of the infrastructure that needs to process the protocol, everything changes.
KEY CHANGES TO HTTP HEADERS
The following are directly from the draft of the SPDY protocol and document the changes from HTTP to SPDY REQUEST CHANGES - The first line of the request is unfolded into name/value pairs like other HTTP headers. The names of the first line fields are
method, url, and version. These keys are required to be present. The 'url' is the fully-qualified URL, containing protocol, host, port, and path. - HTTP request headers are compressed. This is accomplished by compressing all data sent by the client with gzip encoding.
Content-length is not a valid header. - Chunked encoding is no longer valid.
RESPONSE CHANGES - The response status line is unfolded into name/value pairs like other HTTP headers. The names of the status line are
status and version. These keys are required to be present Content-length is no longer valid. - Chunked encoding is no longer valid.
These changes would have a huge impact on infrastructure solutions, many of which rely on URI or HTTP headers (custom and standardized) to perform specific actions such as blocking, scanning, persistence (server affinity), or routing. The requirement that SPDY be transported via SSL has its own, well understood impact on infrastructure and is already dealt with by most devices, but SPDY also requires that headers are compressed via gzip. This means every intermediary requiring to perform some action based on the headers will need to decompress, process, and then likely recompress the headers before sending it on to the next hop. Coupling required compression with SSL would not only require support on all relevant infrastructure but will also likely reintroduce latency that could offset some of the performance gains claimed by testing of SPDY thus far.
SINGLE-CONNECTION: LONG LIVED SESSIONS
That all communication would essentially flow between the client and server over a single connection also poses a challenge for intermediaries that perform any kind of analysis or are required to act on the data exchanged. Load balancers, for example, are not generally designed to handle switching of messages in what becomes a 1:N connection:server scenario. The protocol could likely be supported as is by most load balancing solutions on a strictly layer 4 load balancing basis but advanced features that take advantage of application-aware capabilities such as message header and payload value routing (content-based routing) as well as egress functionality like Data Leak Prevention (DLP) would be much more difficult to implement, if not impossible for some solutions. This capability actually sounds a lot like HTTP pipelining on the request side. The single, long-lived connection would have more of an impact on the overall architecture and capacity planning. In some respects it would be easier, as there would be an easy 1:1 ratio between users and connections. But because each user is effectively being handed dedicated compute resources, this would actually change the resource consumption model on servers and make it more difficult to support high volumes of users without building out a scalable infrastructure.
ASYNCHRONOUS EXCHANGE OF MESSAGES
Further complicating the ability of infrastructure solutions to handle SPDY is its definition as asynchronous. Essentially asynchronous protocols do not enforce order of replies. That means a client could send three requests in a row without waiting for a response and the server could send back the response in a completely different order. Again, from the draft SPDY protocol:  Because TCP provides a single stream of data on which SPDY multiplexes multiple logical streams, it is important for clients and servers to interleave data messages for concurrent sessions.
This may not sound like a problem, but for infrastructure that is optimized to handle HTTP and has been built around its implicit behavior this would require changes to the core networking stacks on most devices. In a typical HTTP scenario a request is received, the infrastructure solution processes any applicable ingress policies, and then initiates a connection to the appropriate server and waits for a response. It appears that with SPDY, like DIAMETER, the infrastructure still processes any applicable ingress policies and initiates a connection but does not necessarily wait for a reply as it might need to act upon the next incoming message. This means a single network “session” would need to carefully track multiple incoming requests and outgoing responses at the same time on a per connection basis. This is not something most infrastructure is typically prepared to handle. Combined with the possibility that different requests may need to be routed to different servers within the infrastructure, this complicates the nature of application delivery and load balancing and could have a huge impact on the costs associated with cloud computing. Long lived sessions/connections initiated on secondary or tertiary servers launched to handle temporary capacity increases could hold open those connections long enough to incur excess charges that are unnecessary. Also similar to DIAMETER is the inclusion of a “real server push” feature. The ability of a server to act like a client and vice-versa is inherent in DIAMETER and this reverse flow of traffic is not something most infrastructure is prepared to process.
THE IMPACT ON INFRASTRUCTURE
Any infrastructure solution that is heavily focused on application layer (HTTP) processing for any purpose would likely need to make radical changes to its core networking and processing engines. Some solutions, particularly those tasked with load balancing and scaling existing message-based protocols may already be capable of supporting a protocol like SPDY. Whether the solutions that support DIAMETER and SIP load balancing and scalability could support SPDY without modification is highly dependent on whether support for the service-provider focused protocols is based on an underlying generic message-based implementation [PDF] or a protocol-specific implementation. The latter would be difficult to adapt to a new protocol while the former would be more easily extended to specifically support the requirements of new message-oriented protocols. But that’s only load balancing and scalability. There are many other infrastructure devices that are used to secure, monitor, accelerate, and otherwise manage HTTP that would need to be updated to handle such a new protocol. The upheaval across data centers would likely be on par with the anticipated challenges associated with mass migration from IPv4 to IPv6. Like that migration, however, support for both SPDY and HTTP could be achieved through the use of translating gateways; infrastructure capable of supporting both SPDY and HTTP or able to translate between the two could be utilized to enable a smoother transition. While it’s a fascinating and exciting notion, the introduction of a completely new protocol to replace HTTP seems more academic than realistic. More realistic would be for gradual implementation through adaptation of SPDY’s core concepts into the next generations of HTTP until HTTP is indistinguishably from a protocol such as SPDY. Making modifications and improvements to HTTP would be an evolutionary step rather than the revolutionary change implied with SPDY that would be almost too disruptive to adopt. That said, not everything that comes out of Google Labs is adopted as an industry wide solution. It’s an experimental environment and a good one at that. What may come out of the SPDY project may well in fact be changes to HTTP rather than the presentation of a new, radically different protocol. Regardless, SDPY and Google’s efforts have people talking about what’s wrong with HTTP and how it might be fixed and that conversation is one we’ve probably needed to have for quite some time now. You can read more about the tools Google offers and general problems with web performance at Google’s “Let’s Make the Web Faster” site.       
 
Related blogs & articles: Technorati Tags: MacVittie, F5, Google, SPDY, HTTP, infrastructure, DIAMETER, protocols, web, internet, IPv4, IPv6, acceleration, security, load balancing, application delivery, application security, architecture
|
|
