Comments
yourfanat wrote: I am using another tool for Oracle developers - dbForge Studio for Oracle. This IDE has lots of usefull features, among them: oracle designer, code competion and formatter, query builder, debugger, profiler, erxport/import, reports and many others. The latest version supports Oracle 12C. More information here.
Cloud Expo on Google News
SYS-CON.TV
Cloud Expo & Virtualization 2009 East
PLATINUM SPONSORS:
IBM
Smarter Business Solutions Through Dynamic Infrastructure
IBM
Smarter Insights: How the CIO Becomes a Hero Again
Microsoft
Windows Azure
GOLD SPONSORS:
Appsense
Why VDI?
CA
Maximizing the Business Value of Virtualization in Enterprise and Cloud Computing Environments
ExactTarget
Messaging in the Cloud - Email, SMS and Voice
Freedom OSS
Stairway to the Cloud
Sun
Sun's Incubation Platform: Helping Startups Serve the Enterprise
POWER PANELS:
Cloud Computing & Enterprise IT: Cost & Operational Benefits
How and Why is a Flexible IT Infrastructure the Key To the Future?
Click For 2008 West
Event Webcasts
Google SPDY Protocol Would Require Mass Change in Infrastructure
Google’s desire to speed up the web via a new protocol is laudable, but the SPDY protocol would require massive changes across n

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.

blockquote 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:

    blockquote 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.

Read the original blog entry...

About Lori MacVittie
Lori MacVittie is responsible for education and evangelism of application services available across F5’s entire product suite. Her role includes authorship of technical materials and participation in a number of community-based forums and industry standards organizations, among other efforts. MacVittie has extensive programming experience as an application architect, as well as network and systems development and administration expertise. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she conducted product research and evaluation focused on integration with application and network architectures, and authored articles on a variety of topics aimed at IT professionals. Her most recent area of focus included SOA-related products and architectures. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.

Latest Cloud Developer Stories
Coca-Cola’s Google powered digital signage system lays the groundwork for a more valuable connection between Coke and its customers. Digital signs pair software with high-resolution displays so that a message can be changed instantly based on what the operator wants to communicat...
In his session at 21st Cloud Expo, Raju Shreewastava, founder of Big Data Trunk, provided a fun and simple way to introduce Machine Leaning to anyone and everyone. He solved a machine learning problem and demonstrated an easy way to be able to do machine learning without even cod...
Blockchain. A day doesn’t seem to go by without seeing articles and discussions about the technology. According to PwC executive Seamus Cushley, approximately $1.4B has been invested in blockchain just last year. In Gartner’s recent hype cycle for emerging technologies, blockchai...
In his keynote at 18th Cloud Expo, Andrew Keys, Co-Founder of ConsenSys Enterprise, provided an overview of the evolution of the Internet and the Database and the future of their combination – the Blockchain. Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSy...
"IBM is really all in on blockchain. We take a look at sort of the history of blockchain ledger technologies. It started out with bitcoin, Ethereum, and IBM evaluated these particular blockchain technologies and found they were anonymous and permissionless and that many companies...
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
Click to Add our RSS Feeds to the Service of Your Choice:
Google Reader or Homepage Add to My Yahoo! Subscribe with Bloglines Subscribe in NewsGator Online
myFeedster Add to My AOL Subscribe in Rojo Add 'Hugg' to Newsburst from CNET News.com Kinja Digest View Additional SYS-CON Feeds
Publish Your Article! Please send it to editorial(at)sys-con.com!

Advertise on this site! Contact advertising(at)sys-con.com! 201 802-3021



SYS-CON Featured Whitepapers
ADS BY GOOGLE