Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Runtime della funzione Web Lambda
Lambda Web Functions esegue il codice del server HTTP utilizzando runtime gestiti. L'applicazione deve avviare un server HTTP che ascolti sull'host e sulla porta specificati dalla `AWS_LAMBDA_HTTP_ENDPOINT` variabile di ambiente. Le funzioni Web Lambda sono attualmente supportate. Node.js Per impostazione predefinita, il runtime viene caricato `index.js` nella radice del pacchetto di distribuzione. Per utilizzare un file di ingresso diverso, imposta la variabile di `AWS_LAMBDA_NODEJS_ENTRYPOINT` ambiente. Per informazioni dettagliate, vedi [Variabili di ambiente](web-functions-revisions-env-vars.md).
## Supportata Node.js versioni
| Identificatore di runtime | Versione Node.js | Stato |
| --- | --- | --- |
| nodejs24.x | Node.js24 | Supportata |
Specificate l'identificatore di runtime nella `runtimeConfig` sezione quando create una revisione. Ad esempio:
```
"runtimeConfig": { "runtime": "nodejs24.x" }
```
Il runtime di `nodejs24.x` Web Function segue lo stesso ciclo di deprecazione del corrispondente runtime di Lambda Event Functions. Per le date di deprecazione e il processo di deprecazione, vedere. [Policy di deprecazione del runtime](lambda-runtimes.md#runtime-support-policy)
## Applicazione automatica delle patch in fase di esecuzione
Lambda aggiorna automaticamente il Node.js runtime con aggiornamenti di sicurezza e correzioni di bug. L'applicazione delle patch si applica al livello di runtime sottostante e non modifica il codice dell'applicazione. L'`runtime`identificatore della revisione (ad esempio,`nodejs24.x`) si risolve sempre nell'ultima versione con patch del runtime principale.
**Nota**
I controlli di gestione del runtime non sono supportati per Web Functions. Non è possibile aggiungere una versione di patch specifica o disabilitare l'applicazione automatica delle patch. Lambda utilizza sempre l'ultima versione con patch del runtime specificato.
Per ulteriori informazioni su come Lambda gestisce gli aggiornamenti di runtime, consulta. [Informazioni su come Lambda gestisce gli aggiornamenti delle versioni di runtime](runtimes-update.md)
## Framework web supportati
È possibile utilizzare qualsiasi framework Node.js Web che avvia un server HTTP. I framework più diffusi includono:
+ Express
+ Next.js
+ Fastify
+ Koa
Non è necessario lo AWS Lambda Web Adapter o un altro adattatore da evento a HTTP. L'applicazione gestisce le richieste HTTP direttamente utilizzando il routing e il middleware standard del framework. Alcuni framework, ad esempio Next.js in modalità standalone, leggono le proprie variabili di ambiente per l'indirizzo di ascolto. Per questi framework, utilizzate un file di `index.js` ingresso che imposta tali variabili `AWS_LAMBDA_HTTP_ENDPOINT` prima dell'avvio del server. Per informazioni dettagliate, vedi [Variabili di ambiente](web-functions-revisions-env-vars.md). Per un'applicazione completa, vedere. [Minima Express applicazione](web-functions-samples.md#web-functions-samples-express)
## Node.js modello di esecuzione
Node.jsutilizza un modello di esecuzione basato sugli eventi. Per impostazione predefinita, Node.js esegue il JavaScript codice su un singolo thread principale e I/O le operazioni (chiamate di rete, accesso al file system) non sono bloccanti e sono basate sugli eventi. L'applicazione può creare thread aggiuntivi con il `worker_threads` modulo se ne ha bisogno. Questo modello ha importanti implicazioni per le funzioni Web:
**Concorrenza tramite asincrono I/O**
Il tuo server gestisce più richieste simultanee utilizzando operazioni asincrone (/, Promises, callback)`async`. `await` Mentre una richiesta attende la risposta del database, il ciclo di eventi serve altre richieste. Questo è il motivo per cui Web Functions è in grado di gestire molte richieste simultanee in un unico ambiente senza più thread.
**Evita di bloccare il ciclo degli eventi**
CPU-intensive le operazioni sincrone (analisi JSON di grandi dimensioni, calcoli complessi, letture sincrone di file) bloccano il ciclo degli eventi e impediscono l'elaborazione di tutte le altre richieste. Se la tua applicazione funziona, trasferiscila sui thread di CPU-heavy lavoro o riducila per limitare l'impatto. `maxConcurrencyPerEnvironment`
**Richiedi l'isolamento**
Poiché tutte le richieste condividono lo stesso processo e lo stesso ciclo di eventi, evita di archiviare lo stato per richiesta in variabili globali. Utilizzate il contesto middleware con ambito di richiesta (ad esempio Express`req`/`res`objects) per isolare i dati della richiesta.
Per indicazioni sulla configurazione in `maxConcurrencyPerEnvironment` base alle caratteristiche dell'applicazione e della CPU, consulta. I/O [Comportamento di scalabilità per Lambda Web Functions](web-functions-scaling.md)
## Memoria e Node.js mucchio
Ogni ambiente di esecuzione dispone di 2 GB di memoria. Quanto segue si applica all'Node.jsheap V8:
+ L'heap predefinito è 1.024 MB.
+ Per utilizzare un heap più grande, imposta `NODE_OPTIONS` le variabili di ambiente della revisione, ad esempio `NODE_OPTIONS=--max-old-space-size=1536` (il valore è in MB).
+ Un valore impostato `NODE_OPTIONS` sostituisce quello predefinito. Se si imposta solo`--max-old-space-size`, Lambda non viene impostata `--max-semi-space-size` e Node.js utilizza i propri valori predefiniti.
+ L'heap, i buffer, le allocazioni native, il runtime e le richieste concorrenti devono rientrare tutti nei 2 GB di memoria ambientale.
## Come Lambda indirizza le richieste alla tua applicazione
Gli endpoint Web Function accettano solo traffico HTTPS, sulla porta 443. Il protocollo HTTP semplice non viene fornito, quindi non è necessario reindirizzare l'HTTP a HTTPS o configurare TLS nell'applicazione.
Lambda termina TLS sull'endpoint e inoltra ogni richiesta al server HTTP dell'applicazione all'interno dell'ambiente di esecuzione. La tua applicazione utilizza il semplice HTTP sull'indirizzo fornito da Lambda; non gestisci mai i certificati o la configurazione TLS nel tuo codice.
Lambda sceglie l'host e la porta su cui il server deve ascoltare. Lambda comunica l'indirizzo all'applicazione tramite la variabile di `AWS_LAMBDA_HTTP_ENDPOINT` ambiente, in formato. `host:port` Usa questa variabile, impostata da Lambda, per determinare dove viene ascoltato il tuo server. L'applicazione deve leggere la variabile all'avvio:
```
const [host, port] = (process.env.AWS_LAMBDA_HTTP_ENDPOINT || 'localhost:3000').split(':');
app.listen(port, host);
```
Lambda non imposta la variabile sul computer locale. L'indirizzo di fallback si applica solo quando la variabile non è impostata, quindi viene utilizzato solo nelle esecuzioni locali. Per utilizzare un indirizzo locale diverso, `AWS_LAMBDA_HTTP_ENDPOINT` impostalo tu stesso. Per un esempio, consulta [Esegui il server HTTP localmente](web-functions-testing.md#web-functions-testing-local).
Lambda aggiunge un'`lambda-web-request-id`intestazione a ogni richiesta inoltrata all'applicazione e restituisce lo stesso valore dell'intestazione di risposta, in modo da poter correlare una richiesta del client con i log dell'applicazione.
Lambda indirizza le richieste Web all'indirizzo specificato da. `AWS_LAMBDA_HTTP_ENDPOINT` Se il server è in ascolto su un host o una porta diversi, le richieste non raggiungono l'applicazione.
Il server deve iniziare l'ascolto entro 10 secondi dall'avvio e ogni richiesta fornita è vincolata dall'impostazione della `timeoutSeconds` revisione. Per la sequenza di avvio e spegnimento, vedi. [Ciclo di vita dell'ambiente di esecuzione](web-functions-env-lifecycle.md) Per informazioni sulla configurazione`timeoutSeconds`, consulta. [Gestione delle revisioni delle funzioni Web](web-functions-revisions.md)