> Can we expect in Workers Unbound support for Websockets, WebRTC, HTTP Connect, and Server Sent Events?
Definitely yes on WebSocket. In fact, the only reason we haven't rolled out WebSocket support already is because it's not very useful without long-running CPU. Workers Unbound fixes that so I'll be dusting off my old WebSocket implementation PR soon.
I think Server Sent Events are just streaming HTTP? That should work today (but with the same caveat that CPU limits may cause trouble).
WebRTC is a peer-to-peer (browser-to-browser) protocol. We don't currently have plans to implement it directly in Workers, though that's an interesting idea.
By "HTTP connect", I assume you mean the CONNECT HTTP method, usually used to tunnel TLS connections through forward proxies? That's a request I haven't heard before, but it's interesting. I guess what you'd get, basically, is the ability to establish TCP-like connections that are addressed to HTTP URLs and connect over port 80/443? Is this commonly used for things other than forward proxies?
> Would there be support for protocols other than HTTP? Say, a raw TCP / UDP connection that is handed off by Spectrum to a Worker [1]?
Not part of the current plan but definitely something we'd like to do eventually.
> Inability to rate limit Workers in a cost effective way gives me sleepless nights
Yeah, our rate limiting product is not really intended to be used to rate-limit the whole site to control costs. It is more intended to, say, rate-limit your login form to prevent brute-force password guessing.
That said, we do have layer 7 DDoS protections, and those run in front of your worker. If an attack gets past them and hits your worker, I'd encourage you to raise a support ticket asking for compensation for the attack traffic that we failed to block. I am not personally in a position to promise that we'd refund you but I believe it has happened in the past.
> Will the same isolate (Unbounded Worker), if kept running for long, be able to handle multiple connections/requests concurrently,
JavaScript is inherently single-threaded, so an isolate can only be executing code on behalf of one request at a time. That said, it is already the case that multiple concurrent requests may be handled by the same isolate (one request may be executing while another is e.g. waiting for a response from a remote server). But today you can't really take advantage of that, because you have no control over exactly which isolate receives any particular request, no any way to communicate between neighboring isolates. This is definitely something we're working on but nothing to announce at this time.