På mandag blev Facebook fuldstændig slået offline og tog Instagram og WhatsApp (for ikke at nævne et par andre websteder) ned med det. Mange har været hurtige til at sige, at hændelsen havde at gøre med BGP eller Border Gateway Protocol med henvisning til kilder inde fra Facebook, trafikanalyse og tarminstinkt om, at “det altid er DNS eller BGP.” Facebook er på vej tilbage, men det hele stiller spørgsmålet:
Hvad er BGP?
På et meget grundlæggende niveau er BGP er et af de systemer, som internettet bruger til at få din trafik dertil, hvor den skal hen hurtigst muligt. Fordi der er masser af forskellige internetudbydere, backbone -routere og servere, der er ansvarlige for, at dine data kommer til f.eks. Facebook, er der masser af forskellige ruter, dine pakker kan ende med at tage. BGP's opgave er at vise dem vejen og sikre, at det er den bedste rute.
Jeg har hørt BGP beskrevet som et system med posthuse, en flyveleder og mere, men jeg tror, at min foretrukne forklaring var en, der lignede det med et kort. Forestil dig BGP som en flok mennesker, der laver og opdaterer kort, der viser dig, hvordan du kommer til YouTube eller Facebook.
BGP er som et kort, der fortæller din computer, hvis broer den skal krydse for at komme til Facebook
Når det kommer til BGP, er internettet opdelt i store netværk, kendt som autonome systemer. Du kan forestille dig dem som ø -nationer – de er netværk, der kontrolleres af en enkelt enhed, som kan være en internetudbyder, som Comcast, et firma, som Facebook eller en anden stor organisation som en regering eller et større universitet. Det ville være ekstremt svært at bygge broer, der forbinder hver ø med alle de andre, så BGP er det, der er ansvarligt for at fortælle dig, hvilke øer (eller autonome systemer) du skal igennem for at komme til din destination.
Da internettet altid ændrer sig, skal kortene opdateres – du vil ikke have, at din internetudbyder leder dig ad en gammel vej, der ikke længere går til Google. Fordi det ville være en massiv opgave at kortlægge hele internettet hele tiden, deler autonome systemer deres kort. De vil lejlighedsvis tale med deres ø -naboer for at se og kopiere de opdateringer, de har foretaget til deres kort.
Drej til venstre ud i floden
Ved at bruge kort som ramme er det let at forestille sig, hvordan ting kan gå galt. Dengang da forbrugerne første gang fik adgang til GPS, var der altid vittigheder om, at man skulle køre ud af en klippe eller ind i midten af ørkenen. Det samme kan ske med BGP – hvis nogen begår en fejl, kan det ende med at føre trafik et sted, det ikke skal gå, hvilket vil forårsage problemer. Hvis den ikke fanges, ender den fejl på alles kort. Der er andre måder, det kan gå galt på, men vi kommer lidt til dem.
Ja, ja, kort. Giv mig et eksempel.
Selvfølgelig! Dette er massivt forenklet, men forestil dig, at du vil oprette forbindelse til et imaginært teknisk nyhedswebsted kaldet Convergence. Konvergens bruger ISP NetSend, og du bruger DecadeConnect. I dette eksempel kan DecadeConnect og NetSend ikke tale direkte med hinanden, men din internetudbyder kan tale med Border Communications, som kan tale med Form, som kan tale med NetSend. Hvis det er den eneste rute, så ville BGP sikre dig, at du og konvergens kunne kommunikere igennem den. Men hvis alternativt både DecadeConnect og NetSend var forbundet til ThirdLevel, ville BGP sandsynligvis vælge at dirigere din trafik igennem den, da det er en kortere hop.
Okay, så BGP er kan du lide kort, der beskriver alle de hurtigste måder fra dig til et websted?
Ret! Desværre kan det blive endnu mere kompliceret, fordi den korteste ikke altid er bedst. Der er masser af grunde til, at en routingsalgoritme ville vælge en vej frem for en anden – omkostninger kan også være en faktor, idet nogle netværk opkræver andre, hvis de vil inkludere dem på deres ruter.
Kortlægning af uændrede veje er svært; forestil dig at kortlægge internettet
Kort er også super vanskelige! Jeg opdagede dette for nylig for at prøve at planlægge en tur, hvor der eksisterede veje på et kort og ikke et andet eller var forskellige mellem kort. Den ene vej havde endda tre forskellige navne på tværs af tre kort. Hvis det er så svært at finde ud af en “by”, der har alle fem veje, kan du forestille dig, hvordan det er at prøve at forbinde hele internettet sammen. Rigtige veje ændrer sig ikke så ofte, men websteder kan flytte fra et land til et andet eller ændre, tilføje eller fratrække tjenesteudbydere, og internettet skal bare håndtere det.
Jeg husker sådan noget fra min algoritme og datastrukturer – prøvede at bygge algoer for at finde den korteste rute.
Jeg tager dit ord om det . Jeg droppede, så snart jeg hørte om grafer.
Men Facebook gjorde det ikke! Faktisk har det bygget sit eget BGP -system, som lader det lave “hurtige trinvise opdateringer” ifølge et papir, der blev præsenteret tidligere på året. Når det er sagt, er systemet, virksomheden beskriver der, beregnet til kommunikation inden for datacentre – på dette tidspunkt er det svært at sige, hvad der forårsagede Facebooks problemer mandag, og det ville tage nogen klogere end mig at sige, om Facebooks datacenterkommunikation kunne forårsage dette slags problem. Cybersecurity -reporter Bryan Krebs hævder, at afbrydelsen skyldtes en “rutinemæssig BGP -opdatering.”
I InFacebooks tekniske opdatering sagde det, at problemet var forårsaget af “konfigurationsændringer på rygradsrouterne, der koordinerer netværkstrafik mellem vores datacentre.” Det førte derefter til en “kaskadende effekt på den måde [Facebooks] datacentre kommunikerer, hvilket bragte [dets] tjenester i stå.” I hvert fald for mit øje lyder det som om, at problemet var, at Facebook kommunikerede i sig selv, ikke til omverdenen (selvom det naturligvis kan forårsage en verdensomspændende afbrydelse, i betragtning af hvor meget af sin egen netværksstabel Facebook kontrollerer).
Hvad gør DNS har at gøre med alt dette?
For at låne en forklaring fra Cloudflare: DNS fortæller dig, hvor du skal hen, og BGP fortæller dig, hvordan du kommer dertil. DNS er, hvordan computere ved, hvilken IP -adresse et websted eller en anden ressource kan findes på, men den viden i sig selv er ikke nyttig – hvis du spørger din ven, hvor deres hus er, har du sandsynligvis stadig brug for GPS for at få dig der .
Cloudflare har også en stor teknisk oversigt over, hvordan BGP -fejl også kan ødelægge DNS -anmodninger – artiklen handler specifikt om mandagens Facebook -hændelse, så det er værd at læse, hvis du leder efter en forklaring på, hvordan det så ud fra et autonomt systems perspektiv .
Hvad kan gå galt med BGP?
Mange ting. Ifølge Cloudflare omfatter to bemærkelsesværdige hændelser, at en tyrkisk internetudbyder ved et uheld fortalte hele internettet at lede sin trafik til sin tjeneste i 2004, og en pakistansk internetudbyder ved et uheld forbød YouTube på verdensplan efter kun at have gjort det for sine brugere. På grund af BGP's evne til at sprede sig fra det autonome system til det autonome system (som en påmindelse er en af de ting, der gør det så brugbart), kan en gruppe, der laver en fejl, kaskade.
BGP kaldes undertiden kanalen bånd af internettet
En gruppe ved at blive ejet kan også forårsage problemer – i 2018 kunne hackere kapre anmodninger til Amazons DNS og stjæle tusindvis af dollars i Ethereum ved at gå på kompromis med en separat internetudbyders BGP -servere. Amazon var ikke den, der blev hacket, men trafik, der var beregnet til det, endte et andet sted.
Eller du kan ødelægge det og slette hele din service fra internettet med en dårlig BGP -opdatering. BGP kaldes kærligt internettets gaffatape, men intet klæbemiddel er perfekt.
Så hvad skete der med Facebook?
Det ser ud til, at Facebooks servere af en eller anden grund fortalte alle at tage dem af deres kort. Facebook har udsendt en indledende rapport, men det er let på detaljer-det er muligt, at Facebook planlægger at frigive en mere dybdegående forklaring senere og siger, hvorfor ændringerne blev foretaget, men dette kan også være det sidste, vi hører om det (i det mindste officielt) .
Imidlertid rapporterer Cloudflares CTO, at tjenesten så masser af BGP -opdateringer fra Facebook (hvoraf de fleste var ruteudtag eller sletning af linjer på kortet, der førte til Facebook) lige før det blev mørkt. En af Fastlys teknologiske leads tweetede, at Facebook stoppede med at levere ruter til Fastly, da den gik offline, og KrebsOnSecurity bakker op om tanken om, at det var en opdatering til Facebooks BGP, der slog sine tjenester ud.
Jeg vil anbefale Cloudflares forklaring, hvis du vil have nitty-gritty tekniske detaljer.
Hvis BGP var problemet, hvordan løser Facebook det?
I betragtning af at afbrydelsen fortsatte i timevis, synes svaret at være “ikke let.” Facebook havde brug for at sørge for, at den reklamerede for de korrekte optegnelser, og at disse rekorder blev hentet af internettet som helhed. Med andre ord var det nødvendigt at sikre, at dets kort var rigtige, og at alle kunne se dem.
Det er dog lettere sagt end gjort. Der var rapporter om, at Facebook-medarbejdere blev lukket ude af badgesikrede døre og om medarbejdere, der kæmpede for at kommunikere. I situationer som disse skal du ikke kun finde ud af, hvem der har viden til at løse problemet, og hvem der har tilladelser til at løse problemet, men hvordan du forbinder disse mennesker. Og når hele din virksomhed er død i vandet, er det ingen let opgave- The Verge modtog rapporter om ingeniører, der fysisk blev sendt til et Facebook-datacenter i Californien for at forsøge at løse problemet.
Relateret
Låst og helt nede: Facebook kæmper for at løse massive afbrydelser
Ville Web3 løse dette problem?
Stop det. Jeg vil græde.
Men for hurtigt at besvare spørgsmålet, sandsynligvis ikke – selvom Facebook hoppede på det decentrale tog, skulle der stadig være en protokol, der fortæller dig, hvor du skal finde sine ressourcer. Vi har set, at det er muligt at fejlkonfigurere eller ødelægge blockchain-kontrakter før, så jeg ville være lidt mistroisk over for alle, der sagde, at en kontrakt og blockchain-baseret internet ville være immun over for denne slags problemer.
< p id = "7sIC21"> Sikker på, at det var en vild timing på det afbrydelse i betragtning af alle de dårlige Facebook -nyheder, ikke?
Rigtigt, så åbenbart, at alt dette skete, mens en whistleblower gik på tv og luftede Facebooks snavsede vasketøj, gør det virkelig let at komme med alternative forklaringer. Men det er lige så muligt, at dette er en uskyldig fejl, som en (meget, meget uheldig) person på Facebooks it -personale lavede.
For hvad det er værd, er det Facebooks forklaring. Det lægger skylden på en “fejlbehæftet konfigurationsændring”, som den foretog, ikke nogen snedige hacks.
Opdater den 4. oktober, 22:44 ET: Opdateret med oplysninger fra Facebooks officielle ingeniørindlæg.