Legitima negotiatio in retis DDoS-Guard nuper centum gigabitas per alterum superavit. Nunc, 50% omnium negotiationum nostrarum clientium interretialium generatur. Haec sunt multa decem milia ditionum valde diversae et in pluribus casibus singularem aditum requirunt.
Infra incisus est quomodo nos ante nodos administramus et testimonium SSL pro centenis milibus situs edunt.
Aliquam eget ante posuere, maximus magna quis, facilisis est. Sumitur nginx vel haproxy vel lighttpd, illud configurare secundum duces et oblivisci. Si opus est aliquid mutare, reload facimus et iterum obliviscimur.
Omnia mutantur cum magna volumina negotiationis in musca processeris, legitimam petitionum aestimas, comprime et usoris cache contentum, simulque parametros pluries in secundo mutare. Usor exitum in omnibus nodis externis videre vult statim postquam occasus in propria ratione mutavit. A user etiam complura milia (et interdum decem milia) ditiones ex singulis mercaturae parametris per API prehendere potest. Haec omnia statim in America, et in Europa, et in Asia β opus non est levissimum, considerans Moscuae solum plures esse nodos filtrationis physice separatos.
Cur plures magnae certae nodis circum orbem terrarum sunt?
-
Qualitas servitii pro cliente negotiationis - petitiones ab USA opus est ut discursum in USA (including impetus, parsing et alia anomalia), et Moscuam vel Europam non trahant, inaestimabiliter mora processus augendi.
-
Impetum mercaturae locales esse debent - operatores transitus in oppugnationibus degradare possunt, quorum volumen saepe 1Tbps excedit. Impetum traiciendi commercii super nexus transatlanticos vel transasianos non est bona idea. Causas reales habuimus cum Tier-1 operariorum dixerunt: "Volumus oppugnationum quas recipis periculosum est nobis." Quam ob rem advenientes rivos accipimus quam proxime ad eorum fontes quam maxime.
-
Stricta requisita ad continuitatem servitii - centra purganda non debent ab invicem pendere vel ab eventibus localibus in nostro mundo celeriter mutato. Nonne virtutem omnibus 11 tabulatis MMTS-9 perebdomadam exscindisti? - non forsit. Nullus client, qui nexum physicum non habet in hoc particulari loco, patietur, et officia interreti nullo adiunctis patientur.
Quomodo haec omnia administrare?
Officii configurationes omnibus nodis anterioribus quam celerrime distribuantur (idealiter statim). Non potes solum textum capere et reficere configs et daemones omni mutatione reboare - eadem nginx processus claudit (operarius descendit) paucis plus momentis (vel fortasse horae si longae sessiones interreti sunt).
Cum nginx configurationis reloading, sequens pictura satis normalem;
De memoria utendo:
Veteres operarii memoriam devorant, etiam memoria quae ex numero nexuum non linealiter pendet β hoc normale est. Cum cliente hospites clausi sunt, haec memoria liberabitur.
Cur non hoc fluit cum nginx mox incepit? Nulla erat HTTP/2, nulla WebSocket, nulla ingens diu hospites vivos custodientes. 70% negocii interreti nostri HTTP est/2, quod coniunctiones longissimas significat.
Solutio simplex est - nginx non utuntur, frontes non administrant in textilibus fasciculis, et certe figurationes textus transpacificis per canales vehementes non mittunt. Canales sunt, utique praestiti et reservati, sed eas non minus transcontinentes facit.
Nostram habemus frontem librariam, de qua interna in sequentibus articulis dicemus. Summa quod facere potest applicatio mutationum millenum configurationis per secundam in musca, sine restarts, reloads, subito augetur in memoria tabes et omnia quae. Hoc simillimum est cum Hot Codice Reload, exempli gratia in Erlang. Notitia reponitur in datorum clavibus clavem-distributis et statim ab actuatoribus anterioribus legitur. Illae. SSL libellum per interface vel API Moscuae imposuisti, et paucis secundis paratum est ire ad centrum purgandum in Los Angeles. Si bellum subito incidit et interretus toto orbe evanescit, nodi nostri libere laborare persgent et scindendum reparabunt quam primum unus e canalibus dedicatis Los Angeles-Amsterdam-Moscuam, Moscoviae-Amsterdam-Hong-Kong- Los-Los in promptu erit. Angeles vel unus saltem e GRE tergum obducat.
Eadem haec mechanismus nobis permittit ut statim edas et renoves Let's Encrypt testimoniales. Simpliciter hoc sic operatur;
-
Simulac unam saltem petitionem HTTPS videmus pro dominio clientis nostri sine certificatorio (vel cum certificatorio elapso), nodi externi, qui petitionem accepit, hoc de auctoritate certificationis internae refert.
-
Si usor non prohibuit edictum Let's Encrypt, certificationis auctoritas CSR generat, confirmationis indicium ex LE accipit et eam omnibus frontibus per alveum encryptum mittit. Nunc quilibet nodi potest confirmare petitionem certis LE.
-
Paucis momentis, libellum rectam et clavem privatam recipiemus et in frontes eodem modo mittemus. Iterum sine daemones restarting
-
7 diebus ante expletum diem, procedendi modus recipiendi libellum initiatur
Nunc in reali tempore 350k testimoniales versamur, omnino perspicui utentibus.
In sequentibus articulis seriei, de aliis notis realibus temporis processui magnarum negotiationum interretialium loquar - exempli gratia de RTT examinandis incompletis notitiis ad emendandum qualitatem servitii pro clientibus transitoriis et generatim de tuenda negotiatione transitus e terabit impetus, de traditione et aggregatione informationis negotiationis, de WAF, fere illimitata CDN et multae machinae ad partus contentus optimizing.
Tantum usores descripserunt in aliquet participare possunt. Te gratissimum esse.
Quid primum scire vis?
-
14,3%Algorithmus pro pampineis et analysibus qualitatem interretialem negotiationis<3
-
33,3%Interna DDoS-Guard7 balancers
-
9,5%Praesidium transit L3/L4 traffic2
-
0,0%Websites protegens in transitu traffic0
-
14,3%Web Application Firewall3
-
28,6%Parsing contra tutelam et clicking6 "
21 utentes decreverunt. 6 utentes abstinuerunt.
Source: www.habr.com