TCP sa Loob ng SSTP: Bakit Dalawang Beses Nangyayari ang Retransmission

Nauna ang sabi-sabi bago ang protocol. Magtanong-tanong at ang SSTP ang mabagal, ang opsiyong iniiwasan mo maliban kung may pumipilit. Ang reputasyong iyon ay naglalarawan ng isang paraan ng pagpalya sa isang uri ng ruta.

Totoo ang mekanismo. May kondisyon din ito, na hindi binabanggit ng reputasyon.

Dalawang maaasahang stream sa isang ruta

SSTP binabalot nito ang tunnel sa loob ng isang HTTPS session. Tumutakbo ang HTTPS sa ibabaw ng TCP, at ginagarantiyahan ng panlabas na stream ang maayos na paghahatid. Kaya't ang isang nawawalang segment ay humahadlang sa lahat ng nakapila sa likod nito. Ang mga susunod na byte na kabilang sa iba pang panloob na usapan ay naghihintay pa rin.

Pinapanatili ng mga panloob na TCP flow ang sarili nilang pagkakasunod-sunod at kontrol ng siksikan. Hindi nila nakikita ang panlabas na pagbawi, kaya't ang tanging napapansin nila ay isang pagtigil. Ang pagtigil ang senyales na nagsasabi sa kanila na siksikan ang ruta.

Ngayon sabay na umuurong ang dalawang patong. Iyon ang buong interaksyon, at sapat na ang isang nawalang segment para simulan ito.

Saan lumilitaw ang epekto at saan hindi

Sa malinis na ruta, bihirang may mabawi ang panlabas na stream. Hindi kailanman nagsisimula ang interaksyon, at maayos na dinadala ng SSTP ang interaktibong trapiko. Nabibigo ang pangkalahatang pahayag sa puntong ito mismo.

Lumilitaw ang epekto kapag naabot ng pagkawala o muling pag-aayos ang pinagbabatayang ruta. Ang siksikang Wi-Fi link o koneksyong mobile na may pabagu-bagong latency ang lumilikha ng mga kondisyon. Pagkatapos, ang naharang na panlabas na pila ay nagiging nakikitang pagkaantala sa loob ng tunnel.

Lumalaki rin ito kasabay ng karga ng trabaho. Maraming magkatulad na flow ang pumupuno sa pila at nagpapalala sa pagharang sa unahan ng pila. Ang isang interaktibong session sa parehong ruta ay maaaring maging katanggap-tanggap.

Ano ang karaniwang hindi sintomas

Hindi lahat ng mabagal na session ay problemang ito. Ang tuloy-tuloy na mababang rate mula sa unang packet ay tumutukoy sa kapasidad, paghubog o limitasyon ng server. Ang mga paghinto na tumutugma sa lokal na siksikan ay tumutukoy sa mga pila sa access link.

Magkakaiba ang mga lunas, kaya't diagnosis muna. Walang nagagawa ang pag-tune ng buffer para sa isang hinubog na link. Walang nagagawa ang pagpapalit ng protocol para sa server na naubos ang kapasidad. Ang paulit-ulit na reset ay tumutukoy sa ibang lugar.

# outer path quality to the SSTP endpoint
ping -c 50 203.0.113.44 | tail -3
mtr -rwc 50 203.0.113.44

# is the local link saturated while the session stalls?
sar -n DEV 2 5

# retransmissions on the outer connection
ss -tin dst 203.0.113.44

Gawin ang pagsukat habang nangyayari ang problema. Ang capture na kinuha sa isang malusog na minuto ay walang pinapatunayan tungkol sa loop na tumatakbo sa masamang minuto.

Isang paghahambing na mapagkakatiwalaan

Kung may tunay na ibang transport, ihambing ito sa kontroladong kondisyon. Parehong host, parehong network, parehong destinasyon at parehong gawain. Dapat nasa parehong sampung minuto ang dalawang pagtakbo upang tumugma ang mga kondisyon ng ruta.

Ang pagpapalit ng port ay hindi nagpapalit ng protocol. Ang pag-import ng walang kaugnayang profile sa isang SSTP client ay hindi lumilikha ng alternatibong transport. May saysay lamang ang paghahambing kapag inaalok ng server ang ikalawang opsiyon.

Panatilihing aktibo ang TLS verification sa lahat ng oras. Ang gawaing pagganap ay hindi dahilan para tanggapin ang hindi na-verify na sertipiko. Kung ang mga pagtigil ay lumilitaw pangunahin habang puspos ang uplink, tingnan ang pagpipila bago sisihin ang mga patong.