In che modo lato server gestiscono le stesse richieste multiple allo stesso tempo?

1. Il modo in cui un runtime del linguaggio di programmazione assicura che le richieste simultanee che hanno lo stesso stato di destinazione non interferiscano l'una con l'altra è in definitiva attraverso un meccanismo chiamato "compare-and-set" che deve essere offerto dall'hardware su cui il il codice è in esecuzione.

   "Confronta e imposta" funziona come segue- due thread dicono all'hardware- "confronta il valore della variabile X a 300, quindi se uguale, imposta X a 301" - e l'hardware assicurerà che solo una di quelle istruzioni viene eseguito alla volta. Il primo restituirà un nuovo risultato per la variabile X, il secondo no.

   Detto questo, c'è molto, molto di più nella storia. Il meccanismo di confronto e impostazione è offerto dalle CPU nel contesto dei dati nei registri. Questi dati devono ancora essere convertiti in RAM e quindi conservati in modo durevole su un disco. Ci sono un numero infinito di modi in cui i costruttori di un sistema potrebbero non riuscire a orchestrare tutte le parti mobili necessarie per il completamento di questo macchinario, portando alla contabilità che va storta.

2. Nulla accade per caso, ma ci sono molte classi di progettazione, implementazione e difetti operativi che possono causare il comportamento di sistemi concorrenti con una coerenza inferiore alla desiderata.

3. Non esiste un singolo nome per vulnerabilità di questo tipo e nemmeno un singolo nome per il sottocampo dell'informatica in cui si verifica il lavoro rilevante per questo tipo di problema. Concorrenza, sistemi distribuiti, modelli di consistenza, isolamento delle transazioni, googling su uno qualsiasi di questi termini produrrà profonde vene per studiare per saperne di più.

   Nel contesto dei due esempi citati: la conteggio dei video di YouTube conta e le transazioni bancarie, l'importante è capire che questi due problemi hanno requisiti diversi.

   Non importa così tanto se YouTube congela le visualizzazioni a 300 o 310 o addirittura a 500 o qualche altro numero magico. Il limite è arbitrario ed è stato scelto da Google per ottimizzare il proprio flusso di lavoro. I piccoli conti non hanno alcun impatto economico o di altro tipo.

   Le contropartite nelle transazioni bancarie, d'altra parte, hanno ovviamente un impatto economico diretto.

   È anche importante capire che il lavoro richiesto ai programmatori e ai progettisti di sistemi distribuiti per ottenere esattamente la contabilità è molto diverso e molto più difficile che ottenere la contabilità approssimativamente.

   In breve, questi due problemi hanno requisiti diversi e hanno soluzioni diverse.

   La mancanza di coerenza nella soluzione dietro il conteggio delle visualizzazioni di YouTube è un riflesso dei requisiti, non un'implicazione che altre soluzioni a Google o in qualsiasi altro contesto contabile si comportano allo stesso modo.

How does a server side programming language handle this type of request?

La maggior parte dei linguaggi di programmazione non si occupa di questo. Invece, questo problema è generalmente risolto dai database, che è progettato per risolvere questo tipo di problemi usando le transazioni.

Ora la domanda si sposta su, come fanno i database a risolverlo? Una varietà di modi, vecchi database relazionali utilizzati per bloccare i record in modo che solo una richiesta possa modificare un determinato valore allo stesso tempo. I database relazionali moderni utilizzavano una tecnica denominata MVCC (controllo della concorrenza a più versioni), che utilizzava una struttura dati basata su log per consentire a più lettori e più scrittori di accedere allo stesso record in modo sicuro e simultaneo e di rilevare e eseguire il rollback in caso di conflitti di aggiornamento. Alcuni database distribuiti non relazionali eliminano la necessità di una rigida coerenza dei dati e consentono invece temporaneamente dati incoerenti, con garanzia "alla fine coerente".

Al livello più elementare, la primitiva utilizzava un'istruzione della CPU chiamata compare-and-swap. Ad un livello superiore, si dispone di una struttura dati un registro / diario di scrittura in anticipo, che tiene traccia delle modifiche in un file di sola aggiunta prima che le modifiche vengano incorporate nella struttura dati corrente. A livello di infrastruttura distribuita, disponi di vari algoritmi di consenso come Paxos o Raft e un numero di libri misti distribuiti specializzati per garantire una contabilità coerente su più macchine.

Il contatore delle visualizzazioni di YouTube impiega probabilmente un'infrastruttura distribuita con un contatore "alla fine coerente" piuttosto che un contatore completamente coerente. Ciò significa che in qualsiasi momento, il contatore di ciascuna replica potrebbe non riflettere mai il conteggio della vista universale reale, ma presumibilmente se il mondo smette di accedere a YouTube e al sistema viene concesso un po 'di tempo per raggiungere uno stato stabile, l'infrastruttura distribuita alla fine convergere al conteggio delle visualizzazioni reali.

can two requests access a variable or any sort of data and change its value at the same time? is the first arrived request to be handled first and then the second waits for its turn?

Con i database che utilizzano i blocchi, sì, solo una richiesta può accedere a un dato alla volta, la richiesta successiva deve attendere il completamento del primo. Con i database che impiegano MVCC, è possibile passare contemporaneamente più richieste, ma viene rilevato un conflitto di scrittura e la richiesta che si impegna in seguito viene interrotta. Con un contatore distribuito, eventualmente coerente, sono possibili più scrittori, ma sacrifichi una visualizzazione coerente dei dati.

Question:could it happen only by chance or 100% of the time?

Accade tutto il tempo, non necessariamente il 100% delle volte, ma spesso è sufficiente che quando un'applicazione deve essere ridimensionata, è necessario tenerne conto.

Question:What type of vulnerability is this? does it have a specific definition?

Se gestito correttamente, non dovrebbe esserci vulnerabilità. Le applicazioni devono definire il livello di garanzia di coerenza di cui ha bisogno. Le applicazioni finanziarie in genere richiedono una strong garanzia di coerenza, mentre il conteggio delle visualizzazioni di YouTube può offrire una consistenza più flessibile per prestazioni migliori.