TCP nula fenestro tra prokuro: identigu la ricevanton
Lokigu la TCP-fluadan regadon ĉe la klienta aŭ servila flanko de prokuro antaŭ ol atribui haltitan elŝuton al fenestra skalado aŭ bufra grando.
Paketa spuro diras TCP ZeroWindow. Antaŭ ol ŝanĝi kernan agordon, identigu la finpunkton, kiu anoncas la nulon.
Tiu finpunkto priskribas sian ricevan kapablon sur tiu TCP-konekto. Ĝi ne anoncas, kiom da bendlarĝo la tuta prokuro havas. Nulfenestra provo ebligas al la sendanto malkovri, ĉu la anoncita kapablo ŝanĝiĝis; provoj sole ne pruvas pakaĵperdon aŭ rompitan prokuron.
browser <-- TCP A --> proxy <-- TCP B --> websiteĈi tiuj estas apartaj TCP-interparoladoj. Supozu, ke la retumilo ĉesas legi grandan respondon kaj anoncas nulon sur A. La prokuro povas fine ĉesi malplenigi B dum ĝiaj propraj bufroj pleniĝas. Pli posta nula fenestro sur B povas esti sekvo de la malrapida kliento, ne la origina problemo.
La inversa situacio eblas dum alŝuto. Se la celloka aplikaĵo ĉesas konsumi datumojn, ĝia fenestro sur B povas fermiĝi. La premo tiam povas vojaĝi reen al la kliento tra la bufroj de la prokuro.
Ordigi la observojn
- Notu la finpunktojn de la konekto kaj la direkton de la tuŝita datentransigo.
- Identigu, kiu finpunkto unue anoncis ŝrumpantan aŭ nulan ricevan fenestron.
- Kontrolu, ĉu ĝia aplikaĵo legis, paŭzis ĉe alia operacio aŭ estis limigita de rimedoj.
- Komparu la tempadon sur la alia konekto de la prokuro antaŭ ol atribui la originan kaŭzon.
La fenestra analizaj etikedoj de Wireshark estas utilaj interpretoj de la kaptaĵo, ne instrukcio pliigi ĉiun ricevan bufron. Ankaŭ fenestra skalado devas esti interpretata konsiderante la intertraktadon de la konekto.
Provi alian finpunkton el prokura listo kaj vidi la transigon resaniĝi estas utila pruvo, ke la vojo ŝanĝiĝis. Ĝi tamen sole ne pruvas, ke la TCP-realigo de iu operaciumo estis difekta. Tenu la klarigon ligita al la riceva procezo kaj al la konekto, kie la atendo komenciĝis.