diff options
Diffstat (limited to 'files/it/web/http/overview/index.html')
| -rw-r--r-- | files/it/web/http/overview/index.html | 177 |
1 files changed, 177 insertions, 0 deletions
diff --git a/files/it/web/http/overview/index.html b/files/it/web/http/overview/index.html new file mode 100644 index 0000000000..93aa350114 --- /dev/null +++ b/files/it/web/http/overview/index.html @@ -0,0 +1,177 @@ +--- +title: Una panoramica su HTTP +slug: Web/HTTP/Overview +tags: + - HTTP + - Protocolli +translation_of: Web/HTTP/Overview +original_slug: Web/HTTP/Panoramica +--- +<div>{{HTTPSidebar}}</div> + +<p class="summary"><span class="seoSummary"><strong>HTTP</strong> è</span> un {{Glossary("protocollo")}} che permette il recupero di risorse, come le pagine HTML. <span class="tlid-translation translation" lang="it"><span title="">È il fondamento di ogni scambio di dati sul Web ed è un protocollo client-server,</span></span><span class="tlid-translation translation" lang="it"><span title="">il che significa che le richieste vengono avviate dal destinatario, solitamente il browser Web. </span></span><span class="tlid-translation translation" lang="it"><span title="">Un documento completo viene ricostruito dai diversi sotto-documenti recuperati, ad esempio testo, descrizione del layout, immagini, video, script e altro.</span></span></p> + +<p><img alt="A Web document is the composition of different resources" src="https://mdn.mozillademos.org/files/13677/Fetching_a_page.png" style="height: 319px; width: 545px;"></p> + +<p><span class="tlid-translation translation" lang="it"><span title="">Client e server comunicano scambiando messaggi individuali (al contrario di un flusso di dati).</span> <span title="">I messaggi inviati dal client, solitamente un browser Web, sono chiamati <em>richieste (requests)</em> e i messaggi inviati dal server come risposta sono chiamati <em>risposte</em> (<em>responses</em>).</span></span></p> + +<p><img alt="HTTP as an application layer protocol, on top of TCP (transport layer) and IP (network layer) and below the presentation layer." src="https://mdn.mozillademos.org/files/13673/HTTP%20&%20layers.png" style="float: left; height: 299px; padding-bottom: 15px; padding-right: 20px; width: 418px;"><span class="tlid-translation translation" lang="it"><span title="">Progettato all'inizio degli anni '90 (1990), HTTP è un protocollo estensibile che si è evoluto nel tempo</span></span>. <span class="tlid-translation translation" lang="it"><span title="">È un protocollo a livello di applicazione che viene inviato mediante </span></span>{{Glossary("TCP")}}, o mediante una connessione TCP cifrata {{Glossary("TLS")}}, <span class="tlid-translation translation" lang="it"><span title="">anche se teoricamente potrebbe essere utilizzato qualsiasi protocollo di trasporto affidabile.</span></span> <span class="tlid-translation translation" lang="it"><span title="">Grazie alla sua estensibilità, viene utilizzato non solo per recuperare documenti ipertestuali, ma anche immagini e video o per pubblicare contenuti su server, come con i risultati dei moduli HTML.</span> <span title="">HTTP può essere utilizzato anche per recuperare parti di documenti per aggiornare pagine Web su richiesta.</span></span></p> + +<h2 id="Componenti_di_sistemi_basati_su_HTTP"><span class="tlid-translation translation" lang="it"><span title="">Componenti di sistemi basati su HTTP</span></span></h2> + +<p><span class="tlid-translation translation" lang="it"><span title="">HTTP è un protocollo client-server: le richieste vengono inviate da un'entità, lo user-agent (o un proxy per conto di esso).</span> <span title="">Il più delle volte lo user-agent è un browser Web, ma può essere qualsiasi cosa, ad esempio un robot che esegue la scansione del Web per popolare e mantenere un indice del motore di ricerca.</span></span></p> + +<p><span class="tlid-translation translation" lang="it"><span title="">Ogni singola richiesta viene inviata a un server, che la gestisce e fornisce una risposta, chiamata response.</span> <span title="">Tra il client e il server ci sono numerose entità, chiamate collettivamente </span></span>{{Glossary("Proxy_server", "proxies")}}, <span class="tlid-translation translation" lang="it"><span title="">che eseguono operazioni diverse e fungono da gateway o</span></span> {{Glossary("Cache", "caches")}}, per esempio.</p> + +<p><img alt="Client server chain" src="https://mdn.mozillademos.org/files/13679/Client-server-chain.png"></p> + +<p><span class="tlid-translation translation" lang="it"><span title="">In realtà, ci sono più computer tra un browser e il server che gestisce la richiesta: ci sono router, modem e altro.</span> <span title="">Grazie alla struttura a strati del Web, questi sono nascosti nella rete e nei livelli di trasporto.</span> <span title="">L'HTTP è in cima, a livello applicazione.</span> <span title="">Sebbene importanti per diagnosticare i problemi di rete, i livelli sottostanti sono per lo più irrilevanti per la descrizione di HTTP.</span></span></p> + +<h3 id="Client_lo_user-agent">Client: lo user-agent</h3> + +<p><span class="tlid-translation translation" lang="it"><span title="">Lo user-agent è qualsiasi strumento che agisce per conto dell'utente.</span> <span title="">Questo ruolo viene svolto principalmente dal browser Web;</span> <span title="">altre possibilità sono i programmi utilizzati da ingegneri e sviluppatori Web per eseguire il debug delle loro applicazioni.</span></span></p> + +<p><span class="tlid-translation translation" lang="it"><span title="">Il browser è <strong>sempre</strong> l'entità che avvia la richiesta.</span> <span title="">Non è mai il server (sebbene nel corso degli anni siano stati aggiunti alcuni meccanismi per simulare i messaggi avviati dal server).</span></span></p> + +<p><span class="tlid-translation translation" lang="it"><span title="">Per presentare una pagina Web, il browser invia una richiesta iniziale per recuperare il documento HTML che rappresenta la pagina.</span> <span title="">Quindi analizza questo file, effettuando richieste aggiuntive corrispondenti a script di esecuzione, informazioni sul layout (CSS) da visualizzare e sotto-risorse contenute all'interno della pagina (solitamente immagini e video).</span></span> <span class="tlid-translation translation" lang="it"><span title="">Il browser Web quindi compone queste risorse per presentare all'utente un documento completo, la pagina Web.</span> <span title="">Gli script eseguiti dal browser possono recuperare più risorse nelle fasi successive e il browser aggiorna la pagina Web di conseguenza.</span></span></p> + +<p><span class="tlid-translation translation" lang="it"><span title="">Una pagina Web è un documento ipertestuale.</span> <span title="">Ciò significa che alcune parti del testo visualizzato sono collegamenti che possono essere attivati (di solito con un clic del mouse) per recuperare una nuova pagina Web, consentendo all'utente di dirigere il proprio user-agent e navigare nel Web.</span> <span title="">Il browser traduce queste indicazioni in richieste HTTP e interpreta ulteriormente le risposte HTTP per presentare all'utente una risposta chiara.</span></span></p> + +<h3 id="Il_Web_server">Il Web server</h3> + +<p><span class="tlid-translation translation" lang="it"><span title="">Sul lato opposto del canale di comunicazione, è il server, che <em>serve (restituisce)</em> il documento come richiesto dal client.</span> <span title="">Un server appare virtualmente come un'unica macchina: questo perché potrebbe essere un insieme di server, i quali condividono il carico (bilanciamento del carico) o un complesso software che interroga altri computer (come una cache, un DB server o un e-commerce</span> <span title="">server), generando totalmente o parzialmente il documento su richiesta.</span></span></p> + +<p><span class="tlid-translation translation" lang="it"><span title="">Un server non è necessariamente una singola macchina, ma più istanze di software server possono essere ospitate sulla stessa macchina.</span> <span title="">Con HTTP / 1.1 e l'intestazione {{HTTPHeader ("Host")}}, possono persino condividere lo stesso indirizzo IP. HERE!!!</span></span></p> + +<h3 id="Proxies">Proxies</h3> + +<p>Between the Web browser and the server, numerous computers and machines relay the HTTP messages. Due to the layered structure of the Web stack, most of these operate at the transport, network or physical levels, becoming transparent at the HTTP layer and potentially making a significant impact on performance. Those operating at the application layers are generally called <strong>proxies</strong>. These can be transparent, forwarding on the requests they receive without altering them in any way, or non-transparent, in which case they will change the request in some way before passing it along to the server. Proxies may perform numerous functions:</p> + +<ul> + <li>caching (the cache can be public or private, like the browser cache)</li> + <li>filtering (like an antivirus scan or parental controls)</li> + <li>load balancing (to allow multiple servers to serve the different requests)</li> + <li>authentication (to control access to different resources)</li> + <li>logging (allowing the storage of historical information)</li> +</ul> + +<h2 id="Basic_aspects_of_HTTP">Basic aspects of HTTP</h2> + +<h3 id="HTTP_is_simple">HTTP is simple</h3> + +<p>HTTP is generally designed to be simple and human readable, even with the added complexity introduced in HTTP/2 by encapsulating HTTP messages into frames. HTTP messages can be read and understood by humans, providing easier testing for developers, and reduced complexity for newcomers.</p> + +<h3 id="HTTP_is_extensible">HTTP is extensible</h3> + +<p>Introduced in HTTP/1.0, <a href="/en-US/docs/Web/HTTP/Headers">HTTP headers</a> make this protocol easy to extend and experiment with. New functionality can even be introduced by a simple agreement between a client and a server about a new header's semantics.</p> + +<h3 id="HTTP_is_stateless_but_not_sessionless">HTTP is stateless, but not sessionless</h3> + +<p>HTTP is stateless: there is no link between two requests being successively carried out on the same connection. This immediately has the prospect of being problematic for users attempting to interact with certain pages coherently, for example, using e-commerce shopping baskets. But while the core of HTTP itself is stateless, HTTP cookies allow the use of stateful sessions. Using header extensibility, HTTP Cookies are added to the workflow, allowing session creation on each HTTP request to share the same context, or the same state.</p> + +<h3 id="HTTP_and_connections">HTTP and connections</h3> + +<p>A connection is controlled at the transport layer, and therefore fundamentally out of scope for HTTP. Though HTTP doesn't require the underlying transport protocol to be connection-based; only requiring it to be <em>reliable</em>, or not lose messages (so at minimum presenting an error). Among the two most common transport protocols on the Internet, TCP is reliable and UDP isn't. HTTP therefore relies on the TCP standard, which is connection-based.</p> + +<p>Before a client and server can exchange an HTTP request/response pair, they must establish a TCP connection, a process which requires several round-trips. The default behavior of HTTP/1.0 is to open a separate TCP connection for each HTTP request/response pair. This is less efficient than sharing a single TCP connection when multiple requests are sent in close succession.</p> + +<p>In order to mitigate this flaw, HTTP/1.1 introduced <em>pipelining</em> (which proved difficult to implement) and <em>persistent connections</em>: the underlying TCP connection can be partially controlled using the {{HTTPHeader("Connection")}} header. HTTP/2 went a step further by multiplexing messages over a single connection, helping keep the connection warm and more efficient.</p> + +<p>Experiments are in progress to design a better transport protocol more suited to HTTP. For example, Google is experimenting with <a href="https://en.wikipedia.org/wiki/QUIC">QUIC</a> which builds on UDP to provide a more reliable and efficient transport protocol.</p> + +<h2 id="What_can_be_controlled_by_HTTP">What can be controlled by HTTP</h2> + +<p>This extensible nature of HTTP has, over time, allowed for more control and functionality of the Web. Cache or authentication methods were functions handled early in HTTP history. The ability to relax the <em>origin constraint</em>, by contrast, has only been added in the 2010s.</p> + +<p>Here is a list of common features controllable with HTTP.</p> + +<ul> + <li><em><a href="/en-US/docs/Web/HTTP/Caching">Caching</a></em><br> + How documents are cached can be controlled by HTTP. The server can instruct proxies and clients, about what to cache and for how long. The client can instruct intermediate cache proxies to ignore the stored document.</li> + <li><em>Relaxing the origin constraint</em><br> + To prevent snooping and other privacy invasions, Web browsers enforce strict separation between Web sites. Only pages from the <strong>same origin</strong> can access all the information of a Web page. Though such constraint is a burden to the server, HTTP headers can relax this strict separation on the server side, allowing a document to become a patchwork of information sourced from different domains; there could even be security-related reasons to do so.</li> + <li><em>Authentication</em><br> + Some pages may be protected so that only specific users can access them. Basic authentication may be provided by HTTP, either using the {{HTTPHeader("WWW-Authenticate")}} and similar headers, or by setting a specific session using <a href="/en-US/docs/Web/HTTP/Cookies">HTTP cookies</a>.</li> + <li><em><a href="/en-US/docs/Web/HTTP/Proxy_servers_and_tunneling">Proxy and tunneling</a></em><br> + Servers or clients are often located on intranets and hide their true IP address from other computers. HTTP requests then go through proxies to cross this network barrier. Not all proxies are HTTP proxies. The SOCKS protocol, for example, operates at a lower level. Other protocols, like ftp, can be handled by these proxies.</li> + <li><em>Sessions</em><br> + Using HTTP cookies allows you to link requests with the state of the server. This creates sessions, despite basic HTTP being a state-less protocol. This is useful not only for e-commerce shopping baskets, but also for any site allowing user configuration of the output.</li> +</ul> + +<h2 id="HTTP_flow">HTTP flow</h2> + +<p>When a client wants to communicate with a server, either the final server or an intermediate proxy, it performs the following steps:</p> + +<ol> + <li>Open a TCP connection: The TCP connection is used to send a request, or several, and receive an answer. The client may open a new connection, reuse an existing connection, or open several TCP connections to the servers.</li> + <li>Send an HTTP message: HTTP messages (before HTTP/2) are human-readable. With HTTP/2, these simple messages are encapsulated in frames, making them impossible to read directly, but the principle remains the same. For example: + <pre class="line-numbers language-html notranslate"><code class="language-html">GET / HTTP/1.1 +Host: developer.mozilla.org +Accept-Language: fr</code></pre> + </li> + <li>Read the response sent by the server, such as: + <pre class="line-numbers language-html notranslate"><code class="language-html">HTTP/1.1 200 OK +Date: Sat, 09 Oct 2010 14:28:02 GMT +Server: Apache +Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT +ETag: "51142bc1-7449-479b075b2891b" +Accept-Ranges: bytes +Content-Length: 29769 +Content-Type: text/html + +<!DOCTYPE html... (here comes the 29769 bytes of the requested web page)</code></pre> + </li> + <li>Close or reuse the connection for further requests.</li> +</ol> + +<p>If HTTP pipelining is activated, several requests can be sent without waiting for the first response to be fully received. HTTP pipelining has proven difficult to implement in existing networks, where old pieces of software coexist with modern versions. HTTP pipelining has been superseded in HTTP/2 with more robust multiplexing requests within a frame.</p> + +<h2 id="HTTP_Messages">HTTP Messages</h2> + +<p>HTTP messages, as defined in HTTP/1.1 and earlier, are human-readable. In HTTP/2, these messages are embedded into a binary structure, a <em>frame</em>, allowing optimizations like compression of headers and multiplexing. Even if only part of the original HTTP message is sent in this version of HTTP, the semantics of each message is unchanged and the client reconstitutes (virtually) the original HTTP/1.1 request. It is therefore useful to comprehend HTTP/2 messages in the HTTP/1.1 format.</p> + +<p>There are two types of HTTP messages, requests and responses, each with its own format.</p> + +<h3 id="Requests">Requests</h3> + +<p>An example HTTP request:</p> + +<p><img alt="A basic HTTP request" src="https://mdn.mozillademos.org/files/13687/HTTP_Request.png" style="height: 336px; width: 693px;"></p> + +<p>Requests consists of the following elements:</p> + +<ul> + <li>An HTTP <a href="/en-US/docs/Web/HTTP/Methods">method</a>, usually a verb like {{HTTPMethod("GET")}}, {{HTTPMethod("POST")}} or a noun like {{HTTPMethod("OPTIONS")}} or {{HTTPMethod("HEAD")}} that defines the operation the client wants to perform. Typically, a client wants to fetch a resource (using <code>GET</code>) or post the value of an <a href="/en-US/docs/Web/Guide/HTML/Forms">HTML form</a> (using <code>POST</code>), though more operations may be needed in other cases.</li> + <li>The path of the resource to fetch; the URL of the resource stripped from elements that are obvious from the context, for example without the {{Glossary("protocol")}} (<code>http://</code>), the {{Glossary("domain")}} (here, <code>developer.mozilla.org</code>), or the TCP {{Glossary("port")}} (here, <code>80</code>).</li> + <li>The version of the HTTP protocol.</li> + <li>Optional <a href="/en-US/docs/Web/HTTP/Headers">headers</a> that convey additional information for the servers.</li> + <li>Or a body, for some methods like <code>POST</code>, similar to those in responses, which contain the resource sent.</li> +</ul> + +<h3 id="Responses">Responses</h3> + +<p>An example response:</p> + +<p><img alt="" src="https://mdn.mozillademos.org/files/13691/HTTP_Response.png" style="height: 494px; width: 758px;"></p> + +<p>Responses consist of the following elements:</p> + +<ul> + <li>The version of the HTTP protocol they follow.</li> + <li>A <a href="/en-US/docs/Web/HTTP/Status">status code</a>, indicating if the request was successful, or not, and why.</li> + <li>A status message, a non-authoritative short description of the status code.</li> + <li>HTTP <a href="/en-US/docs/Web/HTTP/Headers">headers</a>, like those for requests.</li> + <li>Optionally, a body containing the fetched resource.</li> +</ul> + +<h2 id="APIs_based_on_HTTP">APIs based on HTTP</h2> + +<p>The most commonly used API based on HTTP is the {{domxref("XMLHttpRequest")}} API, which can be used to exchange data between a {{Glossary("user agent")}} and a server. The modern {{domxref("Fetch API")}} provides the same features with a more powerful and flexible feature set.</p> + +<p>Another API, <a href="/en-US/docs/Web/API/Server-sent_events">server-sent events</a>, is a one-way service that allows a server to send events to the client, using HTTP as a transport mechanism. Using the {{domxref("EventSource")}} interface, the client opens a connection and establishes event handlers. The client browser automatically converts the messages that arrive on the HTTP stream into appropriate {{domxref("Event")}} objects, delivering them to the event handlers that have been registered for the events' {{domxref("Event.type", "type")}} if known, or to the {{domxref("EventSource.onmessage", "onmessage")}} event handler if no type-specific event handler was established.</p> + +<h2 id="Conclusion">Conclusion</h2> + +<p>HTTP è un protocollo estensibile che è facile da usare. The client-server structure, combined with the ability to simply add headers, allows HTTP to advance along with the extended capabilities of the Web.</p> + +<p>Though HTTP/2 adds some complexity, by embedding HTTP messages in frames to improve performance, the basic structure of messages has stayed the same since HTTP/1.0. Session flow remains simple, allowing it to be investigated, and debugged with a simple <a href="/en-US/docs/Tools/Network_Monitor">HTTP message monitor</a>.</p> |