Transportatio Fidelitatis TCP
Protocollum TCP ut protocollum translationis fidum omnibus notum est, sed quomodo fidelitatem translationis praestat?
Ad transmissionem certam efficiendam, multae res considerandae sunt, ut corruptio datorum, amissio, duplicatio, et fragmenta extra ordinem. Si hae difficultates solvi non possunt, transmissio certa effici non potest.
Quapropter, TCP mechanismis utitur ut numerus sequentiae, responsum agnitionis, imperium remittendi, administratio connexionis, et imperium fenestrae ad transmissionem certam efficiendam.
In hac dissertatione, fenestram mobilem, moderationem fluxus et moderationem congestionis TCP tractabimus. Mechanismus retransmissionis separatim in sequenti sectione tractabitur.
Moderatio Fluxus Retialis
Imperium Fluxus Retialis sive Imperium Traffici Retialis appellatum revera est manifestatio subtilis nexus inter productores et consumidores. Hoc scenario probabiliter saepe in opere vel in colloquiis occurristi. Si capacitas productoris ad producendum capacitatem consumendi consumidoris valde excedit, hoc efficiet ut ordo in infinitum crescat. In casu graviori, fortasse scias cum nuntii RabbitMQ nimis accumulantur, hoc degradationem perfunctionis totius servi MQ causare posse. Idem valet de TCP; nisi moderatur, nimis multi nuntii in rete immittentur, et consumidores capacitatem suam excesserint, dum productores nuntios duplicatos mittere pergent, quod perfunctionem retis magnopere afficiet.
Ad hoc phaenomenon tractandum, TCP mechanismum praebet quo mittenti quantitatem datorum missarum moderari potest secundum capacitatem receptionis actualem recipientis, quod "moderatio fluxus" appellatur. Receptor fenestram receptionis conservat, dum mittentis fenestram mittendi conservat. Notandum est has fenestras tantum uni nexui TCP destinatas esse nec omnes nexus fenestram communem habere.
TCP fluxum moderatur per variabilem fenestram receptionis. Fenestra receptionis mittenti indicationem dat de quanto spatio celato adhuc praesto sit. Mittens quantitatem datorum missarum secundum capacitatem acceptationis actualem recipientis moderatur.
Receptor mittentem de magnitudine datorum quae recipere potest certiorem facit, et mittentis usque ad hunc limitem mittit. Hic limes est magnitudo fenestrae, meministi caput TCP? Est ager fenestrae receptionis, qui adhibetur ad indicandum numerum octetorum quos receptor recipere potest vel vult.
Machina mittentis periodicē fasciculum "fenestrae exploratoriae" mittet, quo deprehenditur num machina recipiens adhuc notitias accipere possit. Cum memoria recipientis periclitatur ne redundet, magnitudo fenestrae ad valorem minorem constituitur ut mittenti instruatur quantitatem notitiarum missarum moderari.
Ecce diagramma Moderationis Fluxus Retialis:
Imperium Congestionis Retialis
Antequam moderationem congestionis introducamus, intellegendum est praeter fenestram receptionis et fenestram mittendi, etiam fenestram congestionis exstare, quae praecipue ad solvendum problema qua celeritate mittens data ad fenestram receptionis mittere incipit adhibetur. Ergo, fenestra congestionis etiam a mittente TCP curatur. Algorithmo indigemus ad decernendum quanta data mittere apta sit, cum nimis pauca vel nimis multa data mittere non sit ideale, unde conceptus fenestrae congestionis.
In priore moderatione fluxus retiarii, quod vitavimus erat mittens qui cellam recipientis datis implebat, sed nesciebamus quid in reti ageretur. Typice, retia computatralia in ambitu communi sunt. Propterea, congestio retiaria propter communicationem inter alios hospites fieri potest.
Cum rete obstructum est, si magnus numerus fasciculorum adhuc mittitur, problemata ut mora et amissio fasciculorum oriri possunt. Hoc tempore, TCP notitias retransmittet, sed retransmissio onus in rete augebit, maiores moras et plures amissiones fasciculorum efficiens. Hoc in circulum vitiosum incidere et pergere crescere potest.
Ergo, TCP ignorare non potest quae in reti geruntur. Cum rete congestum est, TCP se sacrificat quantitatem datorum quae mittit minuendo.
Quapropter, moderatio congestionis proponitur, quae totam retem datis a mittente implere vitare conatur. Ad quantitatem datorum a mittente mittendorum moderandam, TCP conceptum "fenestram congestionis" appellatum definit. Algorithmus moderationis congestionis magnitudinem fenestrae congestionis secundum gradum congestionis retis accommodabit, ut quantitatem datorum a mittente missarum moderetur.
Quid est fenestra congestionis? Quid hoc ad fenestram mittendi pertinet?
Fenestra Congestionis est variabilis status a mittente curata quae quantitatem datorum quae mittente mittere potest determinat. Fenestra congestionis dynamiciter mutatur secundum gradum congestionis retiarii.
Fenestra Mittens est magnitudo fenestrae inter mittentem et recipientem conventa, quae quantitatem datorum quam recipiens recipere potest indicat. Fenestra congestionis et fenestra mittens inter se conexae sunt; fenestra mittens plerumque aequalis est minimo Fenestrae congestionis et recipientis, id est, swnd = min(cwnd, rwnd).
Fenestra congestionis `cwnd` sic mutatur:
Si nulla congestio in reti est, id est, si nullus intervallus retransmissionis occurrit, fenestra congestionis augetur.
Si congestio in reti est, fenestra congestionis decrescit.
Mittens determinat utrum rete congestum sit observando utrum fasciculus agnitionis ACK intra tempus definitum acceptus sit. Si mittens fasciculum agnitionis ACK intra tempus definitum non accipit, habetur rete congestum esse.
Praeter fenestram congestionis, tempus est algorithmum moderationis congestionis TCP disserere. Algorithmus moderationis congestionis TCP tribus partibus principalibus constat:
Initium Lentum:Initio, fenestra congestionis cwnd relative parva est, et mittens fenestram congestionis exponentialiter auget ut celeriter capacitati retis accommodetur.
Vitatio Congestionis:Postquam fenestra congestionis limen certum excedit, mittens fenestram congestionis modo lineari auget ut incrementum fenestrae congestionis tardet et rete onerare vitet.
Celeris Recuperatio:Si congestio accidit, mittens fenestram congestionis dimidiat et statum recuperationis celeris intrat ut locum recuperationis retialis per confirmationes duplicatas acceptas determinet, deinde fenestram congestionis augere pergit.
Initium Lentum
Cum nexus TCP instituitur, fenestra congestionis `cwnd` initialiter ad minimum valorem MSS (maximum segmentum magnitudinis) constituitur. Hoc modo, initialis celeritas mittendi est circiter MSS/RTT bytes/secundum. Latitudo transmissionis actualis praesto plerumque multo maior est quam MSS/RTT, ergo TCP optimam celeritatem mittendi invenire vult, quae per initium tardum obtineri potest.
In processu initio tardo, valor fenestrae congestionis "cwnd" ad 1 MSS initiabitur, et quoties segmentum fasciculi transmissum agnoscitur, valor "cwnd" uno MSS augebitur, id est, valor "cwnd" 2 MSS fiet. Post hoc, valor "cwnd" pro qualibet transmissione prospera segmenti fasciculi duplicatur, et sic porro. Specificus processus incrementi in figura sequenti ostenditur.
Tamen, celeritas mittendi non semper crescere potest; incrementum aliquando finiri debet. Ergo, quando incrementum celeritatis mittendi finitur? Initium tardum typice incrementum celeritatis mittendi uno ex pluribus modis finit:
Prima via est casus amissionis fasciculorum durante processu mittendi initii lenti. Cum amissio fasciculorum accidit, TCP fenestram congestionis mittentis "cwnd" ad 1 ponit et processum initii lenti denuo incipit. Hoc loco, notio liminis initii lenti "ssthresh" introducitur, cuius valor initialis dimidium valoris "cwnd" qui amissionem fasciculorum generat est. Hoc est, cum congestio detegitur, valor "ssthresh" dimidium valoris fenestrae est.
Altera via est directe cum valore liminis initii lenti ssthresh correlare. Cum valor ssthresh dimidium valoris fenestrae sit cum congestio detegitur, amissio fasciculorum fieri potest cum singulis duplicationibus cum cwnd maior est quam ssthresh. Quapropter, optimum est cwnd ad ssthresh ponere, quod TCP ad modum moderationis congestionis mutare et initium lenti finire faciet.
Postrema via qua initium tardum finiri potest est si tres acks redundantes deteguntur, TCP celerem retransmissionem perficit et statum recuperationis intrat. (Si non liquet cur tres fasciculi ACK sint, separatim in mechanismo retransmissionis explicabitur.)
Vitatio Congestionis
Cum TCP statum moderationis congestionis intrat, cwnd ad dimidium liminis congestionis ssthresh constituitur. Hoc significat valorem cwnd non posse duplicari quoties segmentum fasciculi accipitur. Potius, modus relative conservativus adhibetur in quo valor cwnd augetur uno tantum MSS (maxima longitudine segmenti fasciculi) postquam singulae transmissiones completae sunt. Exempli gratia, etiamsi decem segmenta fasciculi agnoscuntur, valor cwnd augebitur uno tantum MSS. Hoc est exemplar incrementi linearis et etiam limitem superiorem incrementi habet. Cum amissio fasciculi fit, valor cwnd mutatur ad MSS, et valor ssthresh ad dimidium cwnd constituitur. Vel etiam incrementum MSS sistet cum tres responsa ACK redundantia accipiuntur. Si tres responsa ACK redundantia adhuc accipiuntur post dimidiationem valoris cwnd, valor ssthresh notatur ut dimidium valoris cwnd et status recuperationis celeris intrat.
Celeris Recuperatio
In statu Recuperationis Celeris, valor fenestrae congestionis cwnd uno MSS augetur pro quolibet ACK redundante accepto, id est, ACK qui non in serie advenit. Hoc fit ut segmenta fasciculorum quae feliciter in rete transmissa sunt adhibeantur ad efficientiam transmissionis quam maxime augendam.
Cum acceptio segmenti fasciculi amissi advenit, TCP valorem `cwnd` minuit, deinde statum vitandi congestionem intrat. Hoc fit ad magnitudinem fenestrae congestionis moderandam et ne congestio retiaria ulterius augeatur.
Si tempus exspectationis post statum moderationis congestionis occurrit, condicio retis gravior fit et TCP a statu vitandae congestionis ad statum initii lenti migrat. Hoc in casu, valor fenestrae congestionis cwnd ad 1 MSS statuitur, maxima longitudo segmenti fasciculi, et valor liminis initii lenti ssthresh ad dimidium cwnd statuitur. Propositum huius est magnitudinem fenestrae congestionis gradatim iterum augere postquam rete convaluit, ut celeritas transmissionis et gradus congestionis retis aequentur.
Summarium
TCP, ut protocollum translationis fidum, translationem fidam per numerum sequentiae, agnitionem, moderationem retransmissionis, administrationem connexionis et moderationem fenestrae efficit. Inter haec, mechanismus moderationis fluxus quantitatem datorum a mittente missorum secundum capacitatem receptionis actualem recipientis moderatur, quod problemata congestionis retialis et degradationis perfunctionis vitat. Mechanismus moderationis congestionis eventum congestionis retialis vitat per adaptationem quantitatis datorum a mittente missorum. Concepta fenestrae congestionis et fenestrae mittendi inter se conexa sunt, et quantitas datorum apud mittentem moderatur per adaptationem dynamicam magnitudinis fenestrae congestionis. Initium tardum, vitatio congestionis et recuperatio celeris sunt tres partes principales algorithmi moderationis congestionis TCP, quae magnitudinem fenestrae congestionis per varias strategias adaptant ad capacitatem et gradum congestionis retialis accommodandam.
In proxima sectione, mechanismum retransmissionis TCP accurate examinabimus. Mechanismus retransmissionis pars magni momenti est TCP ad transmissionem fidam efficiendam. Transmissionem fidam datorum per retransmissionem datorum amissarum, corruptarum vel dilatarum efficit. Principium implementationis et consilium mechanismi retransmissionis in proxima sectione accurate introducentur et analysabuntur. Manete intenti!
Tempus publicationis: Feb-XXIV-MMXXV
