2015-09-02 14 views
14

Ho sempre pensato a monte ea valle lungo le linee di un flusso reale, dove il flusso di informazioni è come l'acqua. Quindi a monte è da dove proviene l'acqua/i dati (ad esempio una richiesta HTTP) e downstream è dove va (ad esempio il sistema sottostante che fornisce servizi alla richiesta).Terminologia upstream/downstream utilizzata all'indietro? (Ad es. Nginx)

Ho guardato recentemente ai gateway API e ho notato che alcuni di essi utilizzavano l'inverso di questa definizione. L'ho scrollato di dosso come una stranezza al momento. Ho poi scoperto che nginx, su cui sono basati alcuni gateway API, utilizza anche la terminologia in modo opposto a quello che mi aspettavo. nginx chiama i server che invia richieste a "server upstream" e presumibilmente le richieste in entrata sarebbero quindi "client downstream".

Concettualmente sembra che nginx spingerebbe le richieste "in salita" se si andasse su un "server upstream", che è totalmente contro-intuitivo ... La gravità è invertita nella terra dei proxy inversi e dei gateway API, a quanto pare!

Ho visto altre discussioni parlare di upstream/downstream che rappresentano le dipendenze tra i sistemi, ma per i componenti middleware o infrastruttura che si trovano tra i sistemi l'idea delle dipendenze è un po 'più sciolta, e trovo più utile pensare in termini di flusso di informazioni ancora - perché di solito è la fonte delle tue dipendenze.

Ho capito che l'analogia del flusso è fondamentalmente errata o questi componenti software stanno recuperando i concetti?

risposta

23

Nel mondo HTTP, il termine "a monte server" è stato introdotto nella specifica HTTP/1.0, RFC 1945:

502 Bad Gateway

Il server, attuando come un gateway o proxy, ha ricevuto una risposta non valida da al server upstream a cui ha avuto accesso nel tentativo di soddisfare la richiesta.

definizione formale è stato aggiunto in seguito, in RFC 2616:

monte/valle

A monte ea valle descrivono il flusso di un messaggio: tutti i messaggi flusso da monte a valle.

Secondo questa definizione:

  • se siete alla ricerca di una richiesta, il client è a monte, e il server è a valle;
  • al contrario, se si sta osservando una risposta, il client è downstream e il server è a monte.

Allo stesso tempo, in HTTP maggior parte del flusso di dati non è per le richieste, ma per risposte. Quindi, se considererai il flusso di risposte, allora il termine "server upstream" sembra abbastanza ragionevole e logico. E il termine è di nuovo usato nella descrizione del codice di risposta 502 (è identico a quello HTTP/1.0), così come in altri posti.

La stessa logica può essere vista anche in termini di "download" e "caricamento" in linguaggio naturale. La maggior parte del flusso di dati proviene da server a client, ed è per questo che "scaricare" significa caricare qualcosa da un server a un client e "caricare" da un client a un server.

+3

Grazie, ha senso. Come qualcuno con un background di integrazione devo ammettere che tendevo a pensare alla direzione come a chi ha iniziato la comunicazione piuttosto che al volume di dati trasferiti. Posso capirlo ora nel contesto della definizione HTTP, ma dato che HTTP è inerentemente richiesta/risposta (vale a dire in due direzioni) vorrei che avessero evitato completamente la terminologia dato che in realtà non aiuta a capire la direzione! :) – ChrisC

Problemi correlati