Sut y gall un porthladd dirprwy dderbyn HTTP a SOCKS ill dau
Esbonio sut y gall gwrandäwr cymysg bwriadol wahaniaethu rhwng HTTP a SOCKS, tra na all gwrandäwr un-protocol arferol wneud hynny.
Gall gwrandäwr dirprwy cymysg dderbyn HTTP a SOCKS ar un porthladd TCP oherwydd bod y gweinydd yn archwilio'r beitiau protocol cychwynnol. Nid y rhif porthladd sy'n gwneud y canfod hwnnw.
Mae cais dirprwy HTTP yn dechrau gyda dull HTTP, megis GET neu CONNECT. Mae cyfarchiad SOCKS yn dechrau gyda meysydd protocol deuaidd. Gall meddalwedd a gynlluniwyd ar gyfer y mewnbynnau hyn anfon y cysylltiad i'r trafodwr priodol.
Mae hon yn nodwedd weithredu benodol. Nid yw gwrandäwr HTTP arferol Squid yn dod yn gymysg am fod ei borthladd wedi'i newid i 1080, ac nid yw gwrandäwr SOCKS yn unig yn dysgu HTTP o osodiad porwr.
Mae TLS yn ychwanegu ffin arall: mae cysylltiad dirprwy amgryptiedig yn dechrau gyda TLS, nid gyda dull HTTP gweladwy. Mae cefnogi hynny ar yr un pwynt terfyn yn gofyn am driniaeth fwriadol ychwanegol; nid yw adnabod HTTP clir a SOCKS yn profi'r gallu hwnnw.
Defnyddiwch y protocol cleient a ddogfenwyd ar gyfer y pwynt terfyn. Os yw'r ddau yn gweithio, tystiolaeth yw hynny am wrandäwr cymysg y gweinydd hwnnw, nid rheswm dros adael y protocol heb ei nodi ym mhob cleient.
Mae gwrandäwr cymysg Glider yn rhoi enghraifft goncrit: mae'n pipo ar un beit heb ei defnyddio, yn anfon 0x05 i'w drafodwr SOCKS5, ac fel arall yn galw ei barswr HTTP. Mae'r parswr hwnnw yn dal i ddilysu'r cais sy'n dod i mewn; nid yw'r dewis anfon yn gwneud unrhyw fewnbwn yn HTTP dilys.
Nid yw rhannu'r gwrandäwr TCP ynddo'i hun yn darparu cysylltiad UDP SOCKS5. Mae Glider yn cychwyn ei wrandäwr UDP ar wahân. Mae dewis protocol TCP a'r trosglwyddo datagram diweddarach yn alluoedd ar wahân.