[
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)
