Publishing websockets in Golang without upgrading a HTTP connection

<p>Hi folks. In a microservice application, I want a variety of our services to be able to add a task to a RabbitMQ stack, and have the websocket microservice pickup on that and fire off whatever message to whatever channel - the channel will be defined by the user&#39;s email address. </p> <p>I can see it&#39;s easy to set up WS with Go, and I&#39;ve got a couple different setups running now, but every tutorial I see involves upgrading an HTTP connection. Is there a way for me to just pull it off a queue and broadcast down to the client without the HTTP request coming in directly? The only service we use with HTTP is our main back-end API. Or am I confused about how this is working : ) </p> <p>edit: Thanks for the help. Makes sense that I have a separative HTTP Websocket microservice that my client opens the connection with on load, and my HTTP API just adds to the RabbitMQ stack when it needs to perform socket updates, which my WS microservice can then publish, if the client is registered there!</p> <hr/>**评论：**<br/><br/>Cvballa3g0: <pre><p>Websockets are upgrades over the http protocol.</p> <p>Try http long polling to a list/map of http writers. </p></pre>jerf: <pre><p>It isn&#39;t clear to me exactly what network architecture you are going for here, so all I can offer at the moment are these factoids:</p> <ul> <li>Websockets <em>are</em> upgraded HTTP connnections. There&#39;s no other way to get one.</li> <li>If you&#39;re speaking to and from a web browser, the only truly bidirectional option is a websocket. If you are almost entirely sending and receiving only rarely, you can send server-side events (google around, there&#39;s some packages for it) and accept events from the client as independent AJAX posts. However, you will get rate limited by the browser as to how many of those you can have going at once. It&#39;s gone up (in the not-so-distant past it was 2), but you can still overwhelm that limit if you try hard enough. Some use cases you won&#39;t even have to dream about hitting that limit (user fills out a form, posts the results when they hit submit), others you can hit almost instantly (autocompletion tries to autocomplete every time they hit a key, and the total latency of the request is much slower than the rate they are typing keys).</li> <li>If you are communicating internally, you can use TCP sockets directly. But you can&#39;t get a raw socket out to the web browser.</li> </ul></pre>szabba: <pre><p>I think OP might not expect the &#34;upgrade this HTTP connection&#34; bit to be exposed as part of the API? It&#39;s not that odd for someone not to know this is how things work &#34;under the hood&#34; with APIs that hide this.</p></pre>