TCP -fidinda transporto
Ni ĉiuj konas la TCP -protokolon kiel fidindan transportan protokolon, sed kiel ĝi certigas la fidindecon de transporto?
Por atingi fidindan transdonon, multaj faktoroj devas esti pripensitaj, kiel ekzemple korupto de datumoj, perdo, duobligo kaj ekster-ordaj fragmentoj. Se ĉi tiuj problemoj ne povas esti solvitaj, fidinda transdono ne povas esti atingita.
Tial TCP uzas mekanismojn kiel sekvenca nombro, agnoska respondo, resenda kontrolo, konekta administrado kaj fenestra kontrolo por atingi fidindan transdonon.
En ĉi tiu papero, ni fokusos sur la glitiga fenestro, fluo -kontrolo kaj kongesta kontrolo de TCP. La retransmisia mekanismo estas kovrita aparte en la sekva sekcio.
Retfluo -Kontrolo
Reto -fluo -kontrolo aŭ scio kiel reta trafika kontrolo estas efektive manifestiĝo de la subtila rilato inter produktantoj kaj konsumantoj. Vi verŝajne renkontas ĉi tiun scenaron multe en la laboro aŭ en intervjuoj. Se la kapablo de la produktanto produkti multe superas la kapablon de la konsumanto konsumi, ĝi kaŭzos la voston nedifinite. En pli serioza kazo, vi eble scias, ke kiam RabbitMQ -mesaĝoj amasigas tro multe, ĝi povas kaŭzi agadon de la tuta MQ -servilo. La samo validas por TCP; Se lasita nekontrolita, tro multaj mesaĝoj estos enmetitaj en la reton, kaj la konsumantoj superas sian kapablon, dum la produktantoj daŭre sendos duplikatajn mesaĝojn, kiuj multe influos la agadon de la reto.
Por trakti ĉi tiun fenomenon, TCP provizas mekanismon por la sendanto por kontroli la kvanton de datumoj senditaj surbaze de la efektiva akcepto de la ricevilo, kiu estas konata kiel fluo -kontrolo. La ricevilo konservas ricevan fenestron, dum la sendanto konservas senditan fenestron. Oni devas rimarki, ke ĉi tiuj fenestroj estas nur por ununura TCP -konekto kaj ne ĉiuj ligoj dividas fenestron.
TCP provizas fluan kontrolon per uzado de variablo por riceva fenestro. La riceva fenestro donas al la sendanto indikon pri kiom da kaŝmemora spaco ankoraŭ haveblas. La sendanto kontrolas la kvanton da datumoj senditaj laŭ la efektiva akcepto -kapablo de la ricevilo.
La gastiganto de la ricevilo sciigas la sendanton pri la grandeco de la datumoj, kiujn ĝi povas ricevi, kaj la sendanto sendas ĉi tiun limon. Ĉi tiu limo estas la fenestra grandeco, ĉu vi memoras la TCP -kaplinion? Estas riceva fenestra kampo, kiu estas uzata por indiki la nombron da bajtoj, kiujn la ricevilo kapablas aŭ pretas ricevi.
La sendanto -gastiganto periode sendos fenestran sondan pakaĵon, kiu estas uzata por detekti ĉu la ricevilo -gastiganto ankoraŭ kapablas akcepti datumojn. Kiam la bufro de la ricevilo riskas superfluon, la fenestra grandeco estas agordita al pli malgranda valoro por instrui la sendanton kontroli la kvanton da datumoj senditaj.
Jen Reto -Fluo -Kontrola Diagramo:
Reto -Kongesta Kontrolo
Antaŭ ol enkonduki kontrolon de kongesto, ni devas kompreni, ke krom la riceva fenestro kaj la senda fenestro, ekzistas ankaŭ kongesta fenestro, kiu estas uzata ĉefe por solvi la problemon, je kiu rapideco la sendanto komencas sendi datumojn al la riceva fenestro. Tial, la kongesta fenestro ankaŭ estas konservita de la TCP -sendanto. Ni bezonas algoritmon por decidi kiom da datumoj taŭgas por sendi, ĉar sendi tro malmulte aŭ tro multe da datumoj ne estas ideala, tial la koncepto de kongesta fenestro.
En la antaŭa reto -fluo -kontrolo, tio, kion ni evitis, estis la sendanto 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, eble ekzistas retaj kongestoj pro komunikado inter aliaj gastigantoj.
Kiam la reto estas kongestita, se oni daŭre sendas grandan nombron da pakaĵoj, ĝi povas kaŭzi problemojn kiel prokrasto kaj perdo de pakaĵoj. Je ĉi tiu punkto, TCP retransdonos la datumojn, sed la retransdono pliigos la ŝarĝon en la reto, rezultigante pli grandajn prokrastojn kaj pli da paketaj perdoj. Ĉi tio povas eniri en malvirtan ciklon kaj plu grandiĝi.
Tiel, TCP ne povas ignori tion, kio okazas en la reto. Kiam la reto estas kongestita, TCP oferas sin reduktante la kvanton da datumoj, kiujn ĝi sendas.
Tial oni proponas kongestan kontrolon, kiu celas eviti plenigi la tutan reton per datumoj de la sendanto. Por reguligi la kvanton da datumoj, kiujn la sendanto devas sendi, TCP difinas koncepton nomatan la kongesta fenestro. La algoritmo pri kontrolo de kongesto ĝustigos la grandecon de la kongesta fenestro laŭ la kongesta grado de la reto, por kontroli la kvanton da datumoj senditaj de la sendanto.
Kio estas kongesta fenestro? Kion ĉi tio devas fari kun la sendita fenestro?
La kongesta fenestro estas ŝtata variablo konservita de la sendanto, kiu determinas la kvanton da datumoj, kiujn la sendanto povas sendi. La kongesta fenestro ŝanĝiĝas dinamike laŭ la kongesta nivelo de la reto.
La sendanta fenestro estas interkonsentita pri fenestra grandeco inter la sendanto kaj ricevilo, kiu indikas la kvanton da datumoj, kiujn la ricevilo povas ricevi. La kongesta fenestro kaj la sendanta fenestro rilatas; La sendanta fenestro kutime egalas al la minimumo de la kongesto kaj ricevas fenestrojn, tio estas SWND = min (cwnd, rWnd).
La kongesta fenestro CWND ŝanĝiĝas jene:
Se ne ekzistas kongesto en la reto, t.e., neniu retransmisia tempodaŭro okazas, la kongesta fenestro pliiĝas.
Se estas kongesto en la reto, la kongesta fenestro malpliiĝas.
La sendanto determinas ĉu la reto estas kongestita per observado ĉu la ACK -agnoska pakaĵo estas ricevita ene de la specifita tempo. Se la sendanto ne ricevas la ACK -agnoskon en la specifita tempo, oni konsideras, ke la reto estas kongestita.
Krom la kongesta fenestro, estas tempo diskuti la TCP -kongestan kontrolon -algoritmon. TCP -Kongesta Kontrolo -Algoritmo konsistas el tri ĉefaj partoj:
Malrapida komenco:Komence, la CWND -kongesta fenestro estas relative malgranda, kaj la sendanto pliigas la kongestan fenestron eksponente por rapide adaptiĝi al la kapablo de la reto.
Kongesta Evito:Post kiam la kongesta fenestro superas certan sojlon, la sendanto pliigas la kongestan fenestron laŭ lineara maniero por malrapidigi la kreskon de la kongesta fenestro kaj eviti superŝarĝon de la reto.
Rapida resaniĝo:Se la kongesto okazas, la sendanto duonigas la kongestan fenestron kaj eniras la rapidan reakiron -staton por determini la lokon de la reto -reakiro per la ricevitaj duplikataj ACK -oj, kaj tiam daŭre pliigas la kongresan fenestron.
Malrapida komenco
Kiam TCP -konekto estas establita, la kongesta fenestro CWND estas komence agordita al minimuma MSS (maksimuma segmento) valoro. Tiel la komenca sendanta indico temas pri MSS/RTT -bajtoj/sekundo. La efektiva disponebla larĝa bando estas kutime multe pli granda ol MSS/RTT, do TCP volas trovi la optimuman sendantan indicon, kiu povas esti atingita per malrapida komenco.
En la malrapida starta procezo, la valoro de la kongesta fenestro CWND estos pravalorizita al 1 MSS, kaj ĉiufoje kiam la transdonita paka segmento estas agnoskita, la valoro de CWND estos pliigita per unu MSS, tio estas la valoro de CWND fariĝos 2 MSS. Post tio, la valoro de CWND estas duobligita por ĉiu sukcesa transdono de paka segmento, ktp. La specifa kreska procezo estas montrita en la sekva figuro.
Tamen la sendanta indico ne ĉiam kreskas; La kresko devas finiĝi iam. Do, kiam finiĝas la sendanta indico? Malrapida-komenca tipe finas la kreskon de la sendanta indico laŭ unu el pluraj manieroj:
La unua maniero estas la kazo de paka perdo dum la sendanta procezo de malrapida komenco. Kiam paka perdo okazas, TCP fiksas la kongestan fenestron de la sendanto al 1 kaj rekomencas la malrapidan startan procezon. Je ĉi tiu punkto, koncepto de malrapida komenca sojlo estas enkondukita, kies komenca valoro estas la duono de la valoro de CWND, kiu generas paketan perdon. Tio estas, kiam kongesto estas detektita, la valoro de SSTHRESH estas duono de la fenestra valoro.
La dua maniero estas rekte korelacii kun la valoro de la malrapida starta sojlo ssthresh. Ĉar la valoro de SSTHRESH estas la duono de la fenestra valoro kiam kongesto estas detektita, paka perdo povas okazi kun ĉiu duobligo kiam CWND estas pli granda ol SSTHRESH. Tial estas plej bone agordi CWND al SSTHRESH, kiu kaŭzos TCP ŝanĝi al kongesta kontrolreĝimo kaj fini malrapidan komencon.
La lasta maniero kiel malrapida komenco povas finiĝi estas se tri redundaj ACKoj estas detektitaj, TCP plenumas rapidan retransmision kaj eniras la reakiron. (Se ne klaras kial estas tri ACK -pakaĵoj, ĝi estos klarigita aparte en la retransmisia mekanismo.)
Kongesta evitado
Kiam TCP eniras la staton de kontrolo de kongesto, CWND estas agordita al la duono de la kongesta sojlo. Ĉi tio signifas, ke la valoro de CWND ne povas esti duobligita ĉiufoje kiam oni ricevas paketan segmenton. Anstataŭe, relative konservativa aliro estas adoptita, en kiu la valoro de CWND estas pliigita per nur unu MSS (maksimuma paka segmento -longo) post kiam ĉiu transdono estas finita. Ekzemple, eĉ se 10 paketaj segmentoj estas agnoskitaj, la valoro de CWND nur pliiĝos per unu MSS. Ĉi tio estas lineara kreskmodelo kaj ĝi ankaŭ havas supran limon sur kresko. Kiam paka perdo okazas, la valoro de CWND estas ŝanĝita al MSS, kaj la valoro de SSTHRESH estas agordita al duono de CWND. Aŭ ĝi ankaŭ ĉesigos la kreskon de MSS kiam 3 redundaj ACK -respondoj estas ricevitaj. Se tri redundaj ACK -oj ankoraŭ ricevas post duonigado de la valoro de CWND, la valoro de SSTHRESH estas registrita kiel la duono de la valoro de CWND kaj la rapida reakira stato estas enigita.
Rapida resaniĝo
En la stato de rapida reakiro, la valoro de la kongesta fenestro CWND estas pliigita per unu MSS por ĉiu ricevita redunda ACK, tio estas ACK, kiu ne alvenas sinsekve. Ĉi tio uzas la paketajn segmentojn, kiuj estis sukcese transdonitaj en la reto por plibonigi la transdonan efikecon kiel eble plej multe.
Kiam ACK de la perdita paka segmento alvenas, TCP malpliigas la valoron de CWND kaj tiam eniras la staton de evitado de kongesto. Ĉi tio devas kontroli la grandecon de la kongesta fenestro kaj eviti plu pliigi la retan kongeston.
Se tempodaŭro okazas post la stato de kontrolo de kongesto, la reto-kondiĉo fariĝas pli serioza kaj TCP migras de la stato de evitado de kongesto al la malrapida starta stato. En ĉi tiu kazo, la valoro de la kongesta fenestro CWND estas agordita al 1 MSS, la maksimuma paka segmento-longo, kaj la valoro de la malrapida starta sojlo SSTHRESS estas agordita al duono de CWND. La celo de ĉi tio estas re-grade pliigi la grandecon de la kongesta fenestro post kiam la reto reakiras por ekvilibrigi la transdonan indicon kaj la gradon de reta kongesto.
Resumo
Kiel fidinda transporta protokolo, TCP efektivigas fidindan transporton per sekvenca nombro, agnosko, retransmisia kontrolo, konekta administrado kaj fenestra kontrolo. Inter ili, la mekanismo de fluo -kontrolo kontrolas la kvanton da datumoj senditaj de la sendanto laŭ la efektiva riceva kapablo de la ricevilo, kiu evitas la problemojn de reta kongesto kaj degradado de rendimento. La mekanismo de kontrolo de kongesto evitas la aperon de reta kongesto alĝustigante la kvanton da datumoj senditaj de la sendanto. La konceptoj de kongesta fenestro kaj sendanta fenestro rilatas unu al la alia, kaj la kvanto da datumoj ĉe la sendanto estas kontrolita dinamike alĝustigante la grandecon de la kongesta fenestro. Malrapida komenco, evitado de kongesto kaj rapida resaniĝo estas la tri ĉefaj partoj de TCP -kongesta kontrolo -algoritmo, kiuj ĝustigas la grandecon de la kongesta fenestro tra malsamaj strategioj por adaptiĝi al la kapablo kaj kongesta grado de la reto.
En la sekva sekcio, ni ekzamenos detale 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ŭ malfruaj datumoj. La efektiviga principo kaj strategio de la retransmisia mekanismo estos enkondukitaj kaj analizitaj detale en la sekva sekcio. Restu agordita!
Afiŝotempo: Feb-24-2025
