WSS fia Squid is net itselde as in gewoane WebSocket-opwurdearring
Skied fersifere WebSockets binnen CONNECT fan gewoane HTTP Upgrade-behanneling yn in trochstjoerproxy.
Sjocht Squid in HTTP Upgrade-fersyk, of allinne in tunnel dy't fersifere ferkear draacht? Dat bepaalt oft syn HTTP Upgrade-kontrôles de flater oanpakke.
| Gewoane eksplisite-proxyrûte | Wat Squid tsjinkomt |
|---|---|
wss:// | Meastentiids CONNECT, folge troch TLS fan de bestimming dy't de WebSocket-hânskek draacht |
ws:// | In gewoan HTTP Upgrade-fersyk dat de proxy ferwurkje kin |
De opwurdearringskontrôle fan Squid giet oer fersiken dy't hy ferwurket. It iepenbieret gjin fersifere HTTP-kopteksten yn in gewoane ûntrochsichtige WSS-tunnel. TLS-ûnderskepping of oare spesjale proxybehanneling feroaret sichtberens en kin eigen kompatibiliteitseasken meinimme.
Sykje foar WSS wêr't de rige stopt: ferbining mei de proxy, akseptearre CONNECT, ferifiearre TLS, dan de hânskek fan de applikaasje. In ôfwizing foar TLS is in oare flater as in wegere gewoane Upgrade-fersyk.
As in feroaring fan it opwurdearringsbelied nedich is, brûk dan de rjochtline foar de ynstalleare Squid-ferzje en stean it fereaske gedrach spesifyk ta. Alle opwurdearringsprotokollen tastean ferbreedt it belied bûten de bepaalde applikaasje.
In suksesfol HTTPS-sidefersyk fêstiget mar in part fan 'e rûte. Langduorjend WebSocket-ferkear kin noch mislearje troch easken fan 'e applikaasje, libbensdoer fan 'e ferbining of beheiningen fan tuskenlizzers, sels foar deselde hostnamme.