TCP Fidindeca Transporto
Ni ĉiuj konas la protokolon TCP kiel fidindan transportprotokolon, sed kiel ĝi certigas la fidindecon de transporto?
Por atingi fidindan transdonon, multaj faktoroj devas esti konsiderataj, kiel ekzemple datenkorupto, perdo, duobligo kaj misordaj fragmentoj. Se ĉi tiuj problemoj ne povas esti solvitaj, fidinda transdono ne povas esti atingita.
Tial, TCP utiligas mekanismojn kiel sekvencnumero, agnoskorespondo, resenda kontrolo, konekta administrado kaj fenestrokontrolo por atingi fidindan dissendon.
En ĉi tiu artikolo, ni koncentriĝos pri la glitfenestro, fluokontrolo kaj obstrukciĝokontrolo de TCP. La retransmisia mekanismo estas kovrita aparte en la sekva sekcio.
Reta Flua Kontrolo
Reta Flukontrolo aŭ konata kiel Reta Trafika Kontrolo estas fakte manifestiĝo de la subtila rilato inter produktantoj kaj konsumantoj. Vi verŝajne ofte renkontis ĉi tiun scenaron ĉe la laboro aŭ en intervjuoj. Se la kapacito de la produktanto produkti multe superas la kapaciton de la konsumanto konsumi, tio kaŭzos senfine kreski la atendovicon. En pli grava kazo, vi eble scias, ke kiam RabbitMQ-mesaĝoj amasiĝas tro multe, tio povas kaŭzi rendimentan degradiĝon de la tuta MQ-servilo. La samo validas por TCP; se ne kontrolita, tro multaj mesaĝoj estos metitaj en la reton, kaj la konsumantoj superos sian kapaciton, dum la produktantoj daŭre sendos duplikatajn mesaĝojn, kio multe influos la rendimenton de la reto.
Por trakti ĉi tiun fenomenon, TCP provizas mekanismon por la sendinto kontroli la kvanton de senditaj datumoj surbaze de la efektiva riceva kapacito de la ricevilo, kio estas konata kiel fluokontrolo. La ricevilo konservas ricevan fenestron, dum la sendinto konservas sendfenestron. Notindas, ke ĉi tiuj fenestroj estas nur por ununura TCP-konekto kaj ne ĉiuj konektoj dividas fenestron.
TCP provizas flukontrolon per uzado de variablo por riceva fenestro. La riceva fenestro donas al la sendinto indikon pri kiom da kaŝmemora spaco ankoraŭ haveblas. La sendinto kontrolas la kvanton da senditaj datumoj laŭ la efektiva akceptokapacito de la ricevilo.
La ricevilo sciigas la sendinton pri la grandeco de la datumoj, kiujn ĝi povas ricevi, kaj la sendinto sendas ĝis tiu limo. Tiu limo estas la fenestrograndeco, ĉu vi memoras la TCP-kaplinion? Ekzistas kampo por ricevilo, kiu estas uzata por indiki la nombron da bajtoj, kiujn la ricevilo povas aŭ volas ricevi.
La sendinta gastiganto periode sendos fenestran sondpakaĵeton, kiu estas uzata por detekti ĉu la ricevinta gastiganto ankoraŭ kapablas akcepti datumojn. Kiam la bufro de la ricevilo riskas superflui, la fenestrograndeco estas agordita al pli malgranda valoro por instrukcii la sendinton kontroli la kvanton da senditaj datumoj.
Jen diagramo de Reta Flukontrolo:
Kontrolo de Reta Obstrukciĝo
Antaŭ ol enkonduki la kontrolon de ŝtopiĝo, ni devas kompreni, ke krom la riceva fenestro kaj la senda fenestro, ekzistas ankaŭ ŝtopiĝofenestro, kiu estas ĉefe uzata por solvi la problemon pri je kiu rapideco la sendinto komencas sendi datumojn al la riceva fenestro. Tial, la ŝtopiĝofenestro estas ankaŭ prizorgata de la TCP-sendinto. Ni bezonas algoritmon por decidi kiom da datumoj estas konvene sendi, ĉar sendi tro malmultajn aŭ tro multajn datumojn ne estas ideala, tial la koncepto de ŝtopiĝofenestro.
En la antaŭa retfluoregado, kion ni evitis estis la sendinto pleniganta la kaŝmemoron de la ricevilo per datumoj, sed ni ne sciis kio okazis en la reto. Tipe, komputilaj retoj estas en komuna medio. Rezulte, povas esti retŝtopiĝo pro komunikado inter aliaj gastigantoj.
Kiam la reto estas ŝtopita, se granda nombro da pakaĵetoj daŭre estas sendataj, tio povas kaŭzi problemojn kiel prokrasto kaj perdo de pakaĵetoj. Ĉe tiu punkto, TCP resendos la datumojn, sed la retransdono pliigos la ŝarĝon sur la reto, rezultante en pli grandaj prokrastoj kaj pli da pakaĵetperdoj. Tio povas eniri en malica ciklo kaj daŭre pligrandiĝi.
Tiel, TCP ne povas ignori tion, kio okazas en la reto. Kiam la reto estas ŝtopita, TCP oferas sin reduktante la kvanton da datumoj, kiujn ĝi sendas.
Tial, oni proponas kontrolon de ŝtopiĝo, kiu celas eviti plenigi la tutan reton per datumoj de la sendinto. Por reguligi la kvanton da datumoj, kiujn la sendinto sendu, TCP difinas koncepton nomatan la fenestro de ŝtopiĝo. La algoritmo pri kontrolo de ŝtopiĝo adaptos la grandecon de la fenestro de ŝtopiĝo laŭ la grado de ŝtopiĝo de la reto, por kontroli la kvanton da datumoj senditaj de la sendinto.
Kio estas obstrukciĝa fenestro? Kion ĉi tio rilatas al la sendofenestro?
La Obstrukciĝa Fenestro estas statvariablo konservata de la sendinto, kiu difinas la kvanton da datumoj, kiujn la sendinto povas sendi. La obstrukciĝa fenestro ŝanĝiĝas dinamike laŭ la obstrukciĝa nivelo de la reto.
La Senda Fenestro estas interkonsentita fenestra grandeco inter la sendinto kaj ricevilo, kiu indikas la kvanton da datumoj, kiujn la ricevilo povas ricevi. La obstrukciĝa fenestro kaj la senda fenestro estas rilataj; la senda fenestro kutime egalas al la minimumo de la obstrukciĝa kaj ricevanta Fenestroj, tio estas, swnd = min(cwnd, rwnd).
La fenestro de obstrukciĝo cwnd ŝanĝiĝas jene:
Se ne estas ŝtopiĝo en la reto, t.e., ne okazas retransmisia tempolimo, la ŝtopiĝofenestro pligrandiĝas.
Se estas obstrukciĝo en la reto, la obstrukciĝo-fenestro malpliiĝas.
La sendinto determinas ĉu la reto estas ŝtopita per observado ĉu la ACK-konfirmpakaĵo estas ricevita ene de la specifita tempo. Se la sendinto ne ricevas la ACK-konfirmpakaĵon ene de la specifita tempo, oni konsideras ke la reto estas ŝtopita.
Aldone al la fenestro de obstrukciĝo, estas tempo diskuti la algoritmon pri TCP-obstrukciĝo-kontrolo. La algoritmo pri TCP-obstrukciĝo-kontrolo konsistas el tri ĉefaj partoj:
Malrapida Komenco:Komence, la cwnd-obstrukciĝfenestro estas relative malgranda, kaj la sendinto pliigas la obstrukciĝfenestron eksponente por rapide adaptiĝi al la kapacito de la reto.
Evitado de Obstrukciĝo:Post kiam la obstrukciĝfenestro superas certan sojlon, la sendinto pliigas la obstrukciĝfenestron laŭ lineara maniero por malrapidigi la kreskorapidecon de la obstrukciĝfenestro kaj eviti troŝarĝi la reton.
Rapida Resaniĝo:Se okazas obstrukciĝo, la sendinto duonigas la obstrukciĝo-fenestron kaj eniras la rapidan reakiran staton por determini la lokon de la ret-reakiro per la ricevitaj duplikataj konfirmoj, kaj poste daŭre pliigas la obstrukciĝo-fenestron.
Malrapida Komenco
Kiam TCP-konekto estas establita, la obstrukciĝa fenestro cwnd estas komence agordita al minimuma MSS (maksimuma segmentograndeco) valoro. Tiel, la komenca sendorapideco estas ĉirkaŭ MSS/RTT bajtoj/sekundo. La efektiva disponebla bendlarĝo estas kutime multe pli granda ol MSS/RTT, do TCP volas trovi la optimuman sendorapidecon, kiun oni povas atingi per malrapida komenco.
En la malrapid-starta procezo, la valoro de la obstrukciĝa fenestro cwnd estos inicialigita al 1 MSS, kaj ĉiufoje kiam la sendita pakaĵsegmento estas agnoskita, la valoro de cwnd estos pliigita je unu MSS, tio estas, la valoro de cwnd fariĝos 2 MSS. Post tio, la valoro de cwnd estas duobligita por ĉiu sukcesa sendo de pakaĵsegmento, kaj tiel plu. La specifa kreskoprocezo estas montrita en la sekva figuro.
Tamen, la sendokvoto ne ĉiam povas kreski; la kresko devas iam finiĝi. Do, kiam finiĝas la pliiĝo de la sendokvoto? Malrapida komenco tipe finas la pliiĝon de la sendokvoto laŭ unu el pluraj manieroj:
La unua maniero estas la kazo de pakaĵperdo dum la senda procezo de malrapida komenco. Kiam pakaĵperdo okazas, TCP metas la fenestron de obstrukciĝo cwnd de la sendinto al 1 kaj rekomencas la procezon de malrapida komenco. Ĉe ĉi tiu punkto, koncepto de sojlo de malrapida komenco ssthresh estas enkondukita, kies komenca valoro estas duono de la valoro de cwnd kiu generas pakaĵperdon. Tio estas, kiam obstrukciĝo estas detektita, la valoro de ssthresh estas duono de la fenestrovaloro.
La dua maniero estas rekte korelacii kun la valoro de la malrapid-komenca sojlo ssthresh. Ĉar la valoro de ssthresh estas duono de la fenestra valoro kiam ŝtopiĝo estas detektita, pakaĵperdo povas okazi kun ĉiu duobligo kiam cwnd estas pli granda ol ssthresh. Tial, estas plej bone agordi cwnd al ssthresh, kio kaŭzos, ke TCP ŝaltos al ŝtop-kontrola reĝimo kaj finos malrapid-komencan.
La lasta maniero kiel malrapida komenco povas finiĝi estas se tri redundaj ACK-oj estas detektitaj, TCP plenumas rapidan retransmision kaj eniras la reakiran staton. (Se ne estas klare kial estas tri ACK-pakaĵetoj, ĝi estos klarigita aparte en la retransmisia mekanismo.)
Evitado de Obstrukciĝo
Kiam TCP eniras la staton de kontrolo de obstrukciĝo, cwnd estas agordita al duono de la sojlo de obstrukciĝo ssthresh. Tio signifas, ke la valoro de cwnd ne povas esti duobligita ĉiufoje kiam pakaĵsegmento estas ricevita. Anstataŭe, relative konservativa aliro estas adoptita, en kiu la valoro de cwnd estas pliigita je nur unu MSS (maksimuma pakaĵsegmenta longo) post kiam ĉiu dissendo estas kompletigita. Ekzemple, eĉ se 10 pakaĵsegmentoj estas agnoskitaj, la valoro de cwnd nur pliiĝos je unu MSS. Ĉi tio estas lineara kreskomodelo kaj ĝi ankaŭ havas supran limon por kresko. Kiam okazas pakaĵperdo, la valoro de cwnd estas ŝanĝita al MSS, kaj la valoro de ssthresh estas agordita al duono de cwnd. Aŭ ĝi ankaŭ haltigos la kreskon de MSS kiam 3 redundaj ACK-respondoj estas ricevitaj. Se tri redundaj ACK-oj ankoraŭ estas ricevitaj post duonigo de la valoro de cwnd, la valoro de ssthresh estas registrita kiel duono de la valoro de cwnd kaj la stato de rapida reakiro estas enirita.
Rapida Resaniĝo
En la stato "Rapida Reakiro", la valoro de la fenestro de obstrukciĝo "cwnd" estas pliigita je unu MSS por ĉiu ricevita redunda ACK, tio estas, ACK kiu ne alvenas sinsekve. Tio celas uzi la pakaĵsegmentojn kiuj estis sukcese senditaj en la reto por plibonigi la dissendefikecon kiel eble plej multe.
Kiam alvenas konfirmo de la perdita pakaĵsegmento, TCP malpliigas la valoron de cwnd kaj poste eniras la staton de evitado de obstrukciĝo. Tio estas por kontroli la grandecon de la obstrukciĝofenestro kaj eviti pluan pliigon de la reto-obstrukciĝo.
Se okazas templimo post la stato de obstrukciĝo-kontrolo, la retkondiĉo fariĝas pli grava kaj TCP migras de la stato de obstrukciĝo-evitado al la stato de malrapida komenco. En ĉi tiu kazo, la valoro de la obstrukciĝo-fenestro cwnd estas agordita al 1 MSS, la maksimuma pakaĵsegmenta longo, kaj la valoro de la malrapida komenco-sojlo ssthresh estas agordita al duono de cwnd. La celo de ĉi tio estas iom post iom pliigi la grandecon de la obstrukciĝo-fenestro post kiam la reto resaniĝas por balanci la transmisian rapidon kaj la gradon de retobstrukciĝo.
Resumo
Kiel fidinda transportprotokolo, TCP efektivigas fidindan transporton per sekvencnumero, agnosko, retransmisia kontrolo, konekta administrado kaj fenestra kontrolo. Inter ili, la flukontrola mekanismo kontrolas la kvanton de datumoj senditaj de la sendinto laŭ la efektiva riceva kapacito de la ricevilo, kio evitas problemojn de retŝtopiĝo kaj rendimenta degradiĝo. La obstrukciĝa kontrolmekanismo evitas la okazon de retŝtopiĝo per alĝustigo de la kvanto de datumoj senditaj de la sendinto. La konceptoj de obstrukciĝa fenestro kaj senda fenestro estas rilataj unu al la alia, kaj la kvanto de datumoj ĉe la sendinto estas kontrolata per dinamika alĝustigo de la grandeco de la obstrukciĝa fenestro. Malrapida komenco, obstrukciĝa evitado kaj rapida reakiro estas la tri ĉefaj partoj de la TCP-obstrukciĝa kontrolalgoritmo, kiuj alĝustigas la grandecon de la obstrukciĝa fenestro per malsamaj strategioj por adaptiĝi al la kapacito kaj obstrukciĝa grado de la reto.
En la sekva sekcio, ni detale ekzamenos la retransmisian mekanismon de TCP. Retransmisia mekanismo estas grava parto de TCP por atingi fidindan transdonon. Ĝi certigas la fidindan transdonon de datumoj per retransdono de perditaj, koruptitaj aŭ prokrastitaj datumoj. La efektiviga principo kaj strategio de la retransmisia mekanismo estos prezentitaj kaj analizitaj detale en la sekva sekcio. Restu agorditaj!
Afiŝtempo: 24-a de februaro 2025
