Cén fáth ar féidir teip seachfhreastalaí SockJS a bheith le feiceáil ach tar éis an chúltaca
Seans go n-úsáideann an cosán WebSocket agus cúltaca XHR cliaint HTTP éagsúla. Aithnigh an t-iompar atá ag teip sula n-athraíonn tú a shocruithe seachfhreastalaí.
Nuair a oibríonn WebSocket ar líonra amháin ach go dteipeann ar SockJS ar líonra eile, b'fhéidir gur chuir an dara líonra an cúltaca XHR i ngníomh. Féadann sé sin an cur i bhfeidhm HTTP a dhéanann na hiarratais a athrú — agus mar sin an chumraíocht seachfhreastalaí a úsáidtear.
Aimsigh an chéad URL a theip agus an t-iompar a roghnaigh sí. Is féidir le SockJS iarraidh faisnéise HTTP a dhéanamh sula roghnaíonn sé iompar; is oibríochtaí ar leith iad an handshake WebSocket agus na hiarratais vótaíochta ina dhiaidh sin. Ní chruthaíonn cumraíocht handshake atá ag obair an cosán a úsáidtear do gach ceann acu.
I gcliant Java Spring, glacann RestTemplateXhrTransport le RestTemplate cumraithe. Soláthraíonn a mhonarcha iarratas agus a chliant HTTP bunúsach an cosán seachfhreastalaí agus an fhíordheimhniú a thacaíonn an cúltaca. Le Spring 6 agus HttpClient 5, cumraigh fíormhonarcha iarratas an RestTemplate sin. Má úsáideann an cur i bhfeidhm sin comhpháirteanna Apache HTTP, caithfidh a ghlúin teacht leis an gcomhtháthú.
Tá a shocruithe ceangail doiciméadaithe féin ag an gcliant WebSocket. Ní chuireann airíonna seachfhreastalaí JVM isteach ar chosán ach amháin má léann a chliant nithiúil iad. Cuir comparáid idir na timpeallachtaí atá ag obair agus atá ag teip de réir iompair, cur i bhfeidhm cliaint, seachfhreastalaí roghnaithe agus an chéad earráid. Más rud é nach dteipeann ach XHR, lean a chosán, a fhíordheimhniú agus a fhreagraí fadtréimhseacha in ionad socruithe an chliaint WebSocket atá ag obair a athrú arís agus arís eile.