On Sun, Jul 24, 2011 at 01:26:53PM +0200, Iñaki Baz Castillo wrote:
2011/7/22 Willy Tarreau <w(_at_)1wt(_dot_)eu>:
Iñaki, what we're saying is that the resolving applies first to HTTP
well before it is WS. For instance, a client could connect to an HTTP
server, fetch a few objects, then decide to upgrade the connection to
switch to WebSocket. DNS resolving for WS would not even be involved
here.
Hi. Maybe I'm the only who assumes that, usually, the WS server is not
colocated within the initial web server.
Web-based infrastructures make that almost mandatory at the frontend,
especially in massive hosting where you don't want to multiply IP addresses.
In general you have one single point which handles the IP:port and which
dispatches that to many servers based on the Host header, URI, file names,
cookies, etc...
This is, your text below is valid just in the case I browse a web page
in http://some-domain.org (so port 80) and retrieve a WS URI to
connect to ws://some-domain.org (so also port 80). In that case you
say that the http/ws client would decide to upgrade the connection so
"it must assume that the WS handshake must be sent to the same IP:port
resolved for the HTTP communication".
I don't agree with yout point. Doing the "upgrade" does not mean
reusing an existing TCP connection (in which HTTP took place) for
other purpose.
Huh ?
Instead, doing the WS upgrade means opening (or
reusing) a TCP connection, sending a HTTP GET with special semantics,
expect 101 and then start a bidirectional frame-based communication.
I still remember how the handshake works, thank you.
So sending the GET with "upgrade" has nothing to do with any previous
HTTP communication with the HTTP server.
Yes it has. Either you open a fresh new connection, or you reuse an
idle existing one. But to know that the connection is idle, you must
understand the protocol that was spoken on it and this protocol must
have clearly delimited messages. HTTP supports reuse of connections
(also called "keep-alive") and since the WS handshake is HTTP, it is
possible and I'd add even recommended to reuse an existing connection
to send a WS handshake, if one such connection exists.
I agree with what others have been saying : if/when a different handshake
is supported, eg. on a specific port without the HTTP upgrade, then it
will make sense.
Do you mean WS as a complete separate protocol running on a specific
WS port and so? I'd really would like it (rather than the exotic
pseudo-HTTP mechanism used right now), but I expect it will never
happen.
I'm sure it will happen. We need applications to be developped using
WS first. But there are places where :
- HTTP compatibility won't be needed
- masking will be annoying
- HTTP overhead will be too much
- HTTP round trip will be too much
I think that this will happen as soon as a working proposal for TLS NPN
appears, because the same requirements will exist (eg: how to specify
the resource name in a simpler way, etc...). Right now we need WS to be
able to replace long polling mechanisms which already work over HTTP, so
if we want it to be adopted, we need to deploy where previous methods
used to work. You just need to be patient :-)
But as of now we're relying on the lower layer. As Greg
said it, without a deep change in HTTP you won't be able to make the rule
a MUST for WS. However, John's suggest of using a SHOULD when the record
exists and the client can see it looks fine. What's the problem if not all
of your clients go to the same hosts ? You can even announce all of your
servers with A/AAAA and with SRV as well as long as they're running on the
same ports. Those who can use SRV just have more information than the other
ones and can be served better.
Having multiple A/AAAA records for a single domain does not provide
failover (as clients usually take just the first IP). I see your
point, but I expect no success at all.
That's not what I'm saying. Right now, people are using A/AAAA with short
TTLs and are updating the zones when a site fails (when I mean a site, I
mean a datacenter). This is something which happens rarely enough to be
acceptable. Using fast DNS updates for server failover does not work
because caches are everywhere and experience shows that even after one
month you still receive traffic on a server you've stopped announcing.
However, please read what I've explained in another mail about the
limitations of client-based failover in web environments.
Regards,
Willy
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf