Puncte:-1

Înțelegerea ferestrei de primire TCP

drapel co

În prezent învăț despre TCP, în special despre aspectul ferestrei de recepție. Am citit din mai multe surse despre asta și vreau să mă asigur că înțeleg ceva.

Din ceea ce am învățat, receptor face publicitate unei „ferestre de primire”, care este - și aici mă confund - numărul de octeți pe care expeditorul are voie să-i trimită fără a fi confirmat, sau cu alte cuvinte, date în zbor.

Acum, dacă încerc să mă gândesc la asta, scopul nostru principal în controlul fluxului este să ne asigurăm că expeditorul nu va trimite mai mult decât poate procesa receptorul, adică dorim să prevenim o situație în care un expeditor le trimite date pe care receptorul va trebui să arunce, deoarece nu va avea unde să-l depoziteze!

Mergând cu această logică, ajung să cred că fereastra de primire ar trebui să corespundă cu dimensiunea bufferului de primire (nu știu dacă este exact aceeași, dar dimensiunea ferestrei ar trebui să fie oricum un derivat al bufferului de primire) și motivul pentru care limităm date în zbor trimis de expeditor este că - dacă expeditorul va trimite mai mult decât dimensiunea ferestrei (care, din nou, este un derivat al tamponului de primire), iar receptorul nu a confirmat unele dintre date (actualizarea dimensiunii ferestrei), există Mai fi o situație în care receptorul nu va ține pasul - adică va primi datele mai repede decât le poate procesa aplicația care le consumă, ceea ce duce la eliminarea segmentelor (sper că este clar).

Dar, citind acest post, @DavidShwartz spune că scopul datelor în zbor NU este de a evita supraumplerea buffer-ului, ci mai degrabă de a gestionează întârzierea introdusă de canalul de comunicare. Pe care nu prea înțeleg.

Problema este că fiecare sursă care vorbește despre acest subiect nu explică legătura dintre scopul general al controlului fluxului și lucrul cu date în zbor.

Poate cineva să explice asta mai detaliat?

drapel ky
Bună! Bună întrebare, nu vă pot da o explicație mai bună... poate că acest site este mai bun https://networkengineering.stackexchange.com/
djdomi avatar
drapel za
Solicitările de recomandări de produse, servicii sau materiale de învățare sunt în afara subiectului, deoarece atrag răspunsuri de calitate scăzută, cu opinii și spam, iar răspunsurile devin depășite rapid. În schimb, descrieți problema de afaceri la care lucrați, cercetarea pe care ați făcut-o și pașii făcuți până acum pentru a o rezolva.
digijay avatar
drapel mx
@djdomi: nu sunt sigur dacă acest lucru este în afara subiectului, nu cere material de învățare, ci un detaliu al specificației tcp.
Puncte:2
drapel ne
  1. date în zbor este un termen general folosit pentru a se referi la datele care au fost trimise, dar care nu au fost încă confirmate. Pentru că din punctul de vedere al expeditorului, aceste date sunt oarecum undeva în rețea. Fereastra expeditorului este cantitatea de date care poate fi în zbor, adică cantitatea de date pe care expeditorul le poate trimite înainte de a primi ACK pentru primul segment al ferestrei.

  2. ceea ce s-a spus în postarea legată este, cred că o formulare destul de prost formulată cu privire la motivul pentru care există o fereastră (adică mai multe pachete) în zbor, spre deosebire de unul singur.

încercați să vedeți ce se întâmplă dacă trimiteți un singur pachet și apoi așteptați ACK și comparați-l cu ceea ce se întâmplă dacă trimiteți 10 pachete la un moment dat, apoi așteptați ACK-uri. Este o sarcină destul de comună a examenului să se calculeze rata de transfer de date. Veți vedea, dacă întârzierea dintre expeditor și destinatar este foarte mică (de exemplu, sunt aproape fizic ca în aceeași clădire), trimiterea câte un pachet funcționează bine. dacă întârzierea este oarecum semnificativă, este foarte ineficient să trimiteți date câte un pachet.

  1. acum, dacă expeditorul doar trimite pachete, fără să-i privească pe alți participanți în rețea, există o mare probabilitate ca aceste pachete să fie scăpate și astfel resursele (la expeditor, în rețea, eventual la receptor) sunt doar irosite. Din acest motiv, fereastra expeditorului TCP este variabilă și depinde de două mecanisme: Controlul debitului și controlul congestiei.

Controlul fluxului face ceea ce ați descris. Scopul său este să nu supraîncărcați receptorul. Deci, receptorul spune doar expeditorului câte date poate accepta. Aceasta se numește fereastra receptorului (care este diferit de fereastra expeditorului). Mai exact, este spațiul din buffer-ul receptor al sistemului de operare. Aplicația este încorporată indirect aici, deoarece dacă aplicația nu preia date din buffer-ul receptorului, nu va fi spațiu eliberat.

Controlul congestionării este acolo pentru a se asigura că expeditorul nu supraîncărcă rețeaua.Este un subiect mare și complicat. Cu toate acestea, ceea ce este descris în celălalt răspuns este controlul congestiei și nu are nimic de-a face cu fereastra receptorului. Există așa-numitul fereastra de congestionare, care estimează (sau ar trebui să estimeze) câte date poate transfera rețeaua fără a fi supraîncărcată, (adică, scăparea de pachete).

Fereastra expeditorului este minimul dintre fereastra receptorului și fereastra de congestie, astfel încât expeditorul să nu supraîncărce nici receptorul, nici rețeaua.

Puncte:2
drapel br

Face pe amândouă.

Fereastra de primire este limitată de spațiul tampon disponibil, dar acest lucru nu este o problemă pentru majoritatea receptoarelor.

Cealaltă funcție importantă a ferestrei de recepție este de a extinde transmisia în timp, astfel încât nu este o explozie mare de zece pachete consecutive urmată de tăcere până când toate aceste date sunt confirmate, apoi o altă explozie.

În schimb, un mecanism numit „pornire lentă TCP” va crește treptat fereastra de primire pe măsură ce datele sunt transferate, astfel încât un transfer de lungă durată se termină cu un flux de pachete care sunt distanțate aproximativ egal, iar confirmarea pentru un pachet ajunge chiar în momentul în care următorul pachet de la sfârșitul ferestrei va trebui să iasă.

Odată ce acest flux a fost stabilit, fereastra se mărește și mai mult pentru a permite înlocuirea pachetelor pierdute fără blocare.

Se obține un flux bun dacă dimensiunea ferestrei crește liniar până la punctul în care atinge cantitatea de date neconfirmate în zbor, care este întârzierea transportului înmulțită cu viteza de transfer.

Motivul pentru care acest lucru nu poate fi rezolvat numai cu recunoaștere este că este destul de probabil ca pachetele dintr-o explozie să fie aruncate pe drum (eliminarea pachetelor este modalitatea rețelei de a indica congestia), așa că începerea conexiunii ar fi mult mai balbâială înainte de a converge în cele din urmă. pe un flux constant.

Dacă tamponul de primire este mai mic decât cantitatea de date neconfirmate în zbor, atunci fereastra de primire va atinge un plafon, iar fluxul va fi neuniform, cu excepția cazului în care stiva de recepție compensează acest lucru cu confirmări întârziate -- dar acesta este un scenariu netipic.

Effie avatar
drapel ne
1) tcp slow start nu are nimic de-a face cu fereastra receptorului. controlul fluxului și controlul congestiei sunt două lucruri separate. pornirea lentă mărește fereastra de congestie. iar fereastra expeditorului este setată la minimul de fereastra de receptor și fereastra de congestie. 2) controlul congestiei nu va preveni spargerea pachetelor. modul în care funcționează, acționează asupra primirii ACK-urilor, deci dacă din orice motiv ACK-urile sunt agregate, se va trimite rafală de pachete. Aveți nevoie de un mecanism separat, numit ritm pentru asta. 3) pachetele pierdute se blochează, se pot bloca cu jumătate de rtt, dar se pot bloca mult (de exemplu, pierderi de coadă).
Effie avatar
drapel ne
„Se realizează un flux bun dacă dimensiunea ferestrei crește liniar până la punctul în care atinge cantitatea de date neconfirmate în zbor, care este întârzierea de transport multiplicată cu viteza de transfer”, această afirmație nu are sens, deoarece fereastra este cantitatea de date în zbor sau numărul de date care pot fi în zbor.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.