[jira] [Comment Edited] (TS-3153) Ability to disable protocols based on SNI information

["Sudheer Vinukonda (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TS-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14189030#comment-14189030 ] 

Sudheer Vinukonda edited comment on TS-3153 at 10/29/14 9:31 PM:
-----------------------------------------------------------------

This approach only works for new sessions initiated by the client - If the client reuses the same spdy session for multiple domains (assuming the certs match), then, this will not work. 

Below are some browser behavior examples. Note that, I've seen cases with both mozilla and chrome where, the browser reuses the same spdy session across domains when certs match.

http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3-1#TOC-4.3-One-Connection-Per-Domain

{code}
4.3 One Connection Per Domain

SPDY attempts to use fewer connections than other protocols have traditionally used. The rationale for this behavior is because it is very difficult to provide a consistent level of service (e.g. TCP slow-start), prioritization, or optimal compression when the client is connecting to the server through multiple channels.

Through lab measurements, we have seen consistent latency benefits by using fewer connections from the client. The overall number of packets sent by SPDY can be as much as 40% less than HTTP. Handling large numbers of concurrent connections on the server also does become a scalability problem, and SPDY reduces this load.

The use of multiple connections is not without benefit, however. Because SPDY multiplexes multiple, independent streams onto a single stream, it creates a potential for head-of-line blocking problems at the transport level. In tests so far, the negative effects of head-of-line blocking (especially in the presence of packet loss) is outweighed by the benefits of compression and prioritization.
{code}

https://bugzilla.mozilla.org/show_bug.cgi?id=528288#c60

{code}
The spdy host coalescing (aka ip pooling or de-sharding), requires a little bit of cert verification. See https://groups.google.com/forum/#!topic/spdy-dev/UW0_X2GaMSQ

This basically means that if host A and B share the same IP address then the SPDY connection for A can be used for transactions of host B if the cert we are using for host A would be acceptable for host B (and the coalesce feature is enabled, of course). The canonical example here is that A==foo.domain.com and B==bar.domain.com and A's cert is *.domain.com. This is how the google services operate, as a pertinent example. But if A's cert covered just foo.domain.com we don't want to put the requests for bar.domain.com down that pipe.
{code}


was (Author: sudheerv):
This approach only works for new sessions initiated by the client - If the client reuses the same spdy session for multiple domains (assuming the certs match), then, this will not work. 

Below are some browser behavior examples:

http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3-1#TOC-4.3-One-Connection-Per-Domain

{code}
4.3 One Connection Per Domain

SPDY attempts to use fewer connections than other protocols have traditionally used. The rationale for this behavior is because it is very difficult to provide a consistent level of service (e.g. TCP slow-start), prioritization, or optimal compression when the client is connecting to the server through multiple channels.

Through lab measurements, we have seen consistent latency benefits by using fewer connections from the client. The overall number of packets sent by SPDY can be as much as 40% less than HTTP. Handling large numbers of concurrent connections on the server also does become a scalability problem, and SPDY reduces this load.

The use of multiple connections is not without benefit, however. Because SPDY multiplexes multiple, independent streams onto a single stream, it creates a potential for head-of-line blocking problems at the transport level. In tests so far, the negative effects of head-of-line blocking (especially in the presence of packet loss) is outweighed by the benefits of compression and prioritization.
{code}

https://bugzilla.mozilla.org/show_bug.cgi?id=528288#c60

{code}
The spdy host coalescing (aka ip pooling or de-sharding), requires a little bit of cert verification. See https://groups.google.com/forum/#!topic/spdy-dev/UW0_X2GaMSQ

This basically means that if host A and B share the same IP address then the SPDY connection for A can be used for transactions of host B if the cert we are using for host A would be acceptable for host B (and the coalesce feature is enabled, of course). The canonical example here is that A==foo.domain.com and B==bar.domain.com and A's cert is *.domain.com. This is how the google services operate, as a pertinent example. But if A's cert covered just foo.domain.com we don't want to put the requests for bar.domain.com down that pipe.
{code}

> Ability to disable protocols based on SNI information
> -----------------------------------------------------
>
>                 Key: TS-3153
>                 URL: https://issues.apache.org/jira/browse/TS-3153
>             Project: Traffic Server
>          Issue Type: Improvement
>          Components: HTTP/2, SPDY
>            Reporter: Bryan Call
>             Fix For: 5.2.0
>
>         Attachments: TS-3153.diff
>
>
> We are running into problems where certain origin servers are having issues when SPDY is enabled.  It would be great to have more control over when protocols are enabled.
> One way to do this would be to add a protocol options to the entry in the ssl_multicert config.  We wound then add additional entries for domains that need to disable the protocols.  All protocols should be enabled by default.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)