diff options
Diffstat (limited to 'files/pt-br/web/api/websockets_api')
4 files changed, 860 insertions, 0 deletions
diff --git a/files/pt-br/web/api/websockets_api/index.html b/files/pt-br/web/api/websockets_api/index.html new file mode 100644 index 0000000000..1a24b9d86a --- /dev/null +++ b/files/pt-br/web/api/websockets_api/index.html @@ -0,0 +1,178 @@ +--- +title: WebSockets +slug: WebSockets +tags: + - Referencia + - Sumario + - WebSockets +translation_of: Web/API/WebSockets_API +--- +<p>WebSockets é uma tecnologia avançada que torna possível abrir uma sessão de comunicação interativa entre o navegador do usuário e um servidor. Com esta API, você pode enviar mensagens para um servidor e receber respostas orientadas a eventos sem ter que consultar o servidor para obter uma resposta.</p> + +<div class="cleared row topicpage-table"> +<div class="section"> +<h2 class="Documentation" id="Documentation" name="Documentation">Documentação</h2> + +<dl> + <dt><a href="/pt-BR/docs/WebSockets/Escrevendo_aplicacoes_cliente_WebSocket" title="WebSockets/Writing WebSocket client applications">Escrevendo aplicações cliente WebSocket</a></dt> + <dd>Um tutorial para escrever clientes WebSocket para ser executado no browser.</dd> + <dt><a href="/en-US/docs/WebSockets/WebSockets_reference" title="WebSockets/WebSockets reference">Referencias WebSockets</a></dt> + <dd>Uma referência para a API WebSocket do lado do cliente.</dd> + <dt><a href="/en-US/docs/WebSockets/Writing_WebSocket_servers" title="WebSockets/Writing WebSocket servers">(TBD)Escrevendo servidores WebSocket</a></dt> + <dd><a href="/en-US/docs/WebSockets/Writing_WebSocket_servers" title="WebSockets/Writing WebSocket servers">Um guia para escrever código do lado do servidor para lidar com o protocolo WebSocket.</a></dd> +</dl> + +<p><a href="/en-US/docs/tag/WebSockets" title="tag/WebSockets">Saiba mais...</a></p> +</div> + +<div class="section"> +<h2 class="Tools" id="Tools" name="Tools">Ferramentas</h2> + +<ul> + <li><a class="external" href="http://socket.io" title="http://socket.io/">Socket.IO</a>: Uma poderosa plataforma cruzada para API WebSocket <a class="external" href="http://nodejs.org" title="http://nodejs.org/">Node.js</a>.</li> + <li><a class="link-https" href="https://github.com/Worlize/WebSocket-Node" title="https://github.com/Worlize/WebSocket-Node">WebSocket-Node</a>: Uma implementação para servidor da API WebSocket<a class="external" href="http://nodejs.org" title="http://nodejs.org/">Node.js</a>.</li> + <li><a href="http://ajf.me/websocket/#libs" title="http://websocket.us/#libs">Uma lista mais ampla de frameworks e bibliotecas aqui</a></li> +</ul> + +<h2 class="Related_Topics" id="Related_Topics" name="Related_Topics">Tópicos Relacionados</h2> + +<ul> + <li><a href="/en-US/docs/AJAX" title="AJAX">AJAX</a>, <a href="/en-US/docs/JavaScript" title="JavaScript">JavaScript</a></li> +</ul> +</div> +</div> + +<h2 id="Veja_Também">Veja Também</h2> + +<ul> + <li><a class="external" href="http://tools.ietf.org/html/rfc6455">RFC 6455 - O Protocolo WebSocket</a></li> + <li><a class="external" href="http://www.w3.org/TR/websockets/">Especificação da API WebSocket</a></li> + <li><a href="/en-US/docs/Server-sent_events" title="Server-sent_events">Eventos enviados para servidor</a></li> + <li><a class="external" href="http://websocket.us/">WebSocket.us</a> - Uma comunidade sem fins lucrativos baseada no site WebSocket</li> +</ul> + +<h2 id="Navegadores_Compatíveis">Navegadores Compatíveis</h2> + +<p>{{CompatibilityTable}}</p> + +<div id="compat-desktop"> +<table class="compat-table"> + <tbody> + <tr> + <th>Características</th> + <th>Chrome</th> + <th>Firefox (Gecko)</th> + <th>Internet Explorer</th> + <th>Opera</th> + <th>Safari</th> + </tr> + <tr> + <td>Suporte a versão 76 {{obsolete_inline}}</td> + <td>6</td> + <td>{{CompatGeckoDesktop("2.0")}}</td> + <td>{{CompatNo}}</td> + <td>11.00 (desativado)</td> + <td>5.0.1</td> + </tr> + <tr> + <td>Protocolo suporta versão 7 {{obsolete_inline}}</td> + <td>{{CompatNo}}</td> + <td>{{CompatGeckoDesktop("6.0")}}<br> + {{property_prefix("Moz")}}</td> + <td>{{CompatNo}}</td> + <td>{{CompatNo}}</td> + <td>{{CompatNo}}</td> + </tr> + <tr> + <td>Protocolo suporta versão 10 {{obsolete_inline}}</td> + <td>14</td> + <td>{{CompatGeckoDesktop("7.0")}}<br> + {{property_prefix("Moz")}}</td> + <td>HTML5 Labs</td> + <td>{{CompatUnknown}}</td> + <td>{{CompatUnknown}}</td> + </tr> + <tr> + <td>Suporte padrão - RFC 6455</td> + <td>16</td> + <td>{{CompatGeckoDesktop("11.0")}}</td> + <td>10</td> + <td>12.10</td> + <td>6.0</td> + </tr> + </tbody> +</table> +</div> + +<div id="compat-mobile"> +<table class="compat-table"> + <tbody> + <tr> + <th>Características</th> + <th>Android</th> + <th>Firefox Mobile (Gecko)</th> + <th>IE Mobile</th> + <th>Opera Mobile</th> + <th>Safari Mobile</th> + </tr> + <tr> + <td>Suporte a versão 76 {{obsolete_inline}}</td> + <td>{{CompatUnknown}}</td> + <td>{{CompatUnknown}}</td> + <td>{{CompatUnknown}}</td> + <td>{{CompatUnknown}}</td> + <td>{{CompatUnknown}}</td> + </tr> + <tr> + <td>Protocolo suporta versão 7 {{obsolete_inline}}</td> + <td>{{CompatUnknown}}</td> + <td>{{CompatUnknown}}</td> + <td>{{CompatUnknown}}</td> + <td>{{CompatUnknown}}</td> + <td>{{CompatUnknown}}</td> + </tr> + <tr> + <td>Protocolo suporta versão 8 (IETF rascunho 10) {{obsolete_inline}}</td> + <td>{{CompatUnknown}}</td> + <td>{{CompatGeckoMobile("7.0")}}</td> + <td>{{CompatUnknown}}</td> + <td>{{CompatUnknown}}</td> + <td>{{CompatUnknown}}</td> + </tr> + <tr> + <td>Suporte padrão - RFC 6455</td> + <td>16 (Chrome)</td> + <td>{{CompatGeckoDesktop("11.0")}}</td> + <td>{{CompatUnknown}}</td> + <td>12.10</td> + <td>6.0</td> + </tr> + </tbody> +</table> +</div> + +<h3 id="Notas_Gecko">Notas Gecko</h3> + +<p>O suporte a WebSockets no Firefox continua acompanhando as constantes especificações do WebSocket. O Firefox 6 implementa a versão 7 do protocolo subjacente, enquanto o Firefox 7 implementa a versão 8 (conforme especificado pelo rascunho IETF 10). O Firefox móvel recebeu suporte WebSocket no Firefox mobile 7.0.</p> + +<h4 id="Gecko_6.0">Gecko 6.0</h4> + +<p>Antes do Gecko 6.0 {{geckoRelease("6.0")}}, estava incorreto, um objeto <code>WebSocket</code> que alguns sites implicavam que os serviços <code>WebSocket</code> não eram prefixados. Este objeto foi renomeado para <code>MozWebSocket</code>.</p> + +<h4 id="Gecko_7.0">Gecko 7.0</h4> + +<p>Iniciado no Gecko 7.0 {{geckoRelease("7.0")}}, o <code>network.websocket.max-connections</code> preferencialmente usado para determinar o número máximo de conexões do WebSocket que pode m ser abertas de cada vez. O valor padrão é 200.</p> + +<h4 id="Gecko_8.0">Gecko 8.0</h4> + +<p>Iniciado no Gecko 8.0 {{geckoRelease("8.0")}}, a extensão de fluxo de expansão para o protocolo WebSocket foi desativada, por estar obsoleta nas especificações. Isso resolve incompatibilidades com alguns sites.</p> + +<h4 id="Gecko_11.0">Gecko 11.0</h4> + +<p>Antes do Gecko 11.0, as mensagens recebidas e enviadas estavam limitadas a 16 MB de tamanho. Agora elas podem ter até 2 GB de tamanho. Note, no entanto, que as limitações de memória (especialmente em dispositivos móveis) tornam isso apenas teoria, não se aplica à prática. Na realidade, as transferências desse tamanho falharão em dispositivos que não possuem memória suficiente.</p> + +<p>Além disso, o ArrayBuffer envia e recebe suporte para dados binários</p> + +<p>Iniciado no Gecko 11.0, a API do WebSocket já não é prefixada.</p> + +<div class="warning"><strong>Atenção:</strong>Entre outras coisas, um motivo chave para o WebSockets estar desativado por padrão no Firefox 4 e 5 é a descoberta de um <a class="external" href="http://www.ietf.org/mail-archive/web/hybi/current/msg04744.html" title="http://www.ietf.org/mail-archive/web/hybi/current/msg04744.html">Problema de segurança no design do protocolo</a>. Isso foi corrigido no Firefox 6 implementando uma versão mais recente do protocolo que corrige o problema.</div> diff --git a/files/pt-br/web/api/websockets_api/writing_websocket_client_applications/index.html b/files/pt-br/web/api/websockets_api/writing_websocket_client_applications/index.html new file mode 100644 index 0000000000..af608ae641 --- /dev/null +++ b/files/pt-br/web/api/websockets_api/writing_websocket_client_applications/index.html @@ -0,0 +1,182 @@ +--- +title: Escrevendo aplicações cliente WebSocket +slug: WebSockets/Escrevendo_aplicacoes_cliente_WebSocket +tags: + - Cliente + - Exemplo + - Guía + - WebSocket API +translation_of: Web/API/WebSockets_API/Writing_WebSocket_client_applications +--- +<p><span style="line-height: 1.5;">Aplicações cliente usam o </span><a href="/en-US/docs/Web/API/Websockets_API">WebSocket API</a> para se comunicar com <a href="/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers">WebSocket servers</a> sob o protocolo WebSocket.</p> + +<p>{{AvailableInWorkers}}</p> + +<div class="warning"> +<p>O fragmento de código neste artigo foi tomado de um exemplo de chat usando WebSocket. <a href="https://github.com/mdn/samples-server/tree/master/s/websocket-chat">v</a>eja o código, então experimente o exemplo. <strong>O exemplo atual possui um bug; ele está tentando usar WebSockets inseguro e precisa ser atualizado para usar WebSocokets seguro. Iremos arrumar isso em breve!</strong></p> +</div> + +<h2 id="Criando_um_objeto_WebSocket">Criando um objeto WebSocket </h2> + +<p>Para se comunicar utilizando o protocolo WebSocket, você precisa criar um objeto <code><a href="/en/WebSockets/WebSockets_reference/WebSocket" title="en/WebSockets/WebSockets reference/WebSocket">WebSocket</a>,</code> que automaticamente tentará abrir a conexão com o servidor.</p> + +<p>O construtor WebSocket aceita dois campos, um obrigatório e um opcional:</p> + +<pre class="notranslate">WebSocket WebSocket( + in DOMString url, + in optional DOMString protocols +); +</pre> + +<dl> + <dt><code>url</code></dt> + <dd>A URL para se conectar. Esta deve ser a URL para qual o WebSocket irá responder.</dd> + <dt><code>protocols</code> {{ optional_inline() }}</dt> + <dd>Uma única string indicando o protocolo ou uma <em>array </em>de strings de protocolos. Estas strings são usadas para indicar sub-protocolos, de forma que um único servidor pode implementar múltiplos sub-protocolos WebSocket (por exemplo, você pode querer que um servidor seja capaz de lidar com diferentes tipos de interações a depender do <code>protocol</code> especificado). Se não especificar uma string de protocolo, uma string vazia é assumida.</dd> +</dl> + +<p>O construtor lançará a exceção <strong><code>SECURITY_ERR</code></strong> se o destino não permitir acesso. Isso pode acontecer se você tentar utilizar uma conexão insegura (a maioria dos {{Glossary("user agent", "user agents")}} agora necessitam de um link seguro para todas as conexões WebSocket, a menos que estejam no mesmo dispositivo ou na mesma rede).</p> + +<dl> +</dl> + +<h3 id="Erros_de_Conexão">Erros de Conexão</h3> + +<p>Se um erro ocorrer durante a tentativa de conexão, primeiro um simpes evento com o nome "error" é enviado ao objeto <a href="/en/WebSockets/WebSockets_reference/WebSocket" title="WebSocket"><code>WebSocket</code></a> (invocando, assim, seu manipulador <code>onerror</code>), e então o <a href="/en/WebSockets/WebSockets_reference/CloseEvent" title="CloseEvent"><code>CloseEvent</code></a> é enviado ao objeto <a href="/en/WebSockets/WebSockets_reference/WebSocket" title="WebSocket"><code>WebSocket</code></a> (invocando o manipulador <code>onclose</code>) para indicar a razão pela qual a conexão foi fechada.</p> + +<p>O browser pode exibir uma descrição de erro mais detalhada na saída do console, ou mesmo um código de encerramento conforme definido na <a class="external" href="http://tools.ietf.org/html/rfc6455#section-7.4" title="RFC 6455 Section 7.4">RFC 6455, Section 7.4</a> através do <a href="/en/WebSockets/WebSockets_reference/CloseEvent" title="CloseEvent"><code>CloseEvent</code></a>. Está implementado a partir do Firefox 11.</p> + +<h3 id="Exemplos">Exemplos</h3> + +<p>Neste simples exemplo, criaremos um novo WebSocket, conectando ao servidor em <code><span class="nowiki">ws://www.example.com/socketserver</span></code>. Neste exemplo utilizaremos um protocolo customizado denominado "protocolOne", embora possa ser omitido.</p> + +<pre class="brush: js notranslate">var exampleSocket = new WebSocket("ws://www.example.com/socketserver", "protocolOne"); +</pre> + +<p>No retorno, <code>exampleSocket.readyState</code> está como <code>CONNECTING</code>. O <code>readyState</code> se tornará <code>OPEN</code> quando a conexão estiver pronta para transferir dados.</p> + +<p>Se quiser abrir uma conexão e for flexível quanto aos protocolos suportados, você pode especificar um array de protocolos:</p> + +<pre class="brush: js notranslate">var exampleSocket = new WebSocket("ws://www.example.com/socketserver", ["protocolOne", "protocolTwo"]); +</pre> + +<p>Uma vez que a conexão for estabelecida (isso é, <code>readyState</code> está <code>OPEN</code>), <code>exampleSocket.protocol</code> informará qual protocolo o servidor selecionou.</p> + +<p>Nos exemplos acima, <code>ws</code> foi substituído por <code>http</code>, de forma similar <code>wss</code> substitui <code>https</code>. Estabelecer uma conexão WebSocket depende do <a href="/en-US/docs/Web/HTTP/Protocol_upgrade_mechanism">Mecanismo de Aprimoramento HTTP</a>, de forma que o pedido para atualização de protocolo está implícito quando endereçamos o servidor HTTP como <code><span class="nowiki">ws://www.example.com</span></code> ou <code><span class="nowiki">wss://www.example.com</span></code>.</p> + +<h2 id="Enviando_dados_ao_servidor">Enviando dados ao servidor</h2> + +<p>Uma vez a conexão aberta, você pode iniciar a transmisão de dados ao servidor. Para tanto, chame o método <code><a href="/en/WebSockets/WebSockets_reference/WebSocket#send()" title="en/WebSockets/WebSockets reference/WebSocket#send()">send()</a></code> do <code>WebSocket</code> para cada mensagem que queira enviar:</p> + +<pre class="brush: js notranslate">exampleSocket.send("Aqui vai algum texto que o servidor esteja aguardando urgentemente!"); +</pre> + +<p>Você pode enviar dados como uma string, {{ domxref("Blob") }}, ou um <a href="/en/JavaScript_typed_arrays/ArrayBuffer" title="en/JavaScript typed arrays/ArrayBuffer"><code>ArrayBuffer</code></a>.</p> + +<div class="note"><strong>Note:</strong> Nas versões anteriores à 11, o Firefox suporta apenas o envio de dados como string.</div> + +<p>Visto que estabelecer uma conexão funciona de forma assícrona e, consequentemente, propensa a erros, não há garantia de sucesso ao chamar o método <code>send()</code> imediatamente após criar um objeto WebSocket. Podemos, pelo menos, ter certeza de que a tentativa de envio dos dados apenas ocorre quando uma conexão é estabelecida definindo um manipulador de eventos <code>onopen</code>:</p> + +<pre class="brush: js notranslate">exampleSocket.onopen = function (event) { + exampleSocket.send("Aqui vai algum texto que o servidor esteja aguardando urgentemente!"); +}; +</pre> + +<h3 id="Utilizando_JSON_para_transmitir_objetos">Utilizando JSON para transmitir objetos</h3> + +<p>Uma forma conveniente é usar <a href="/en/JSON" title="en/JSON">JSON</a> para enviar dados razoavelmente complexos ao servidor. Por exemplo, um aplicação de chat pode interagir com o servidor empregando um protocolo que utilize pacotes de dados JSON encapsulados:</p> + +<pre class="brush: js notranslate">// Enviar texto para todos os usuarios atraves do servidor +function sendText() { + // Construir um objeto do tipo msg contendo o dado que o servidor precisa processar a partir do cliente de chat. + var msg = { + type: "message", + text: document.getElementById("text").value, + id: clientID, + date: Date.now() + }; + + // Enviar o objeto msg como um JSON em formato de string. + exampleSocket.send(JSON.stringify(msg)); + + // Esvaziar o campo input do elemento text, pronto pra receber a próxima linha de texto do usuário. + document.getElementById("text").value = ""; +} +</pre> + +<h2 id="Recebendo_mensagens_do_servidor">Recebendo mensagens do servidor</h2> + +<p>A API WebSockets é dirigida por <a href="https://developer.mozilla.org/pt-BR/docs/Web/Guide/Events/Overview_of_Events_and_Handlers">eventos</a>; quando mensagens são recebidas, um evento de "mensagem" é entregue à função <code>onmessage</code>. Para começar a ouvir os dados de entrada, você pode fazer algo conforme o exemplo abaixo:</p> + +<pre class="brush: js notranslate">exampleSocket.onmessage = function (event) { + console.log(event.data); +} +</pre> + +<h3 id="Recebendo_e_interpretando_objetos_JSON">Recebendo e interpretando objetos JSON</h3> + +<p>Vamos considerar que a aplicação cliente de chat remete o envio de dados {{ anch("Utilizando JSON para transmitir objetos") }}. Existem diversos tipos de pacotes de dados que o cliente pode receber, tais como:</p> + +<ul> + <li>Handshake de login</li> + <li>Messagem de texto</li> + <li>Atualizações da lista de usuários</li> +</ul> + +<p>O código que interpreta as mensagens de entrada se parecerá com esse:</p> + +<pre class="brush: js notranslate">exampleSocket.onmessage = function(event) { + var f = document.getElementById("chatbox").contentDocument; + var text = ""; + var msg = JSON.parse(event.data); + var time = new Date(msg.date); + var timeStr = time.toLocaleTimeString(); + + switch(msg.type) { + case "id": + clientID = msg.id; + setUsername(); + break; + case "username": + text = "<b>User <em>" + msg.name + "</em> signed in at " + timeStr + "</b><br>"; + break; + case "message": + text = "(" + timeStr + ") <b>" + msg.name + "</b>: " + msg.text + "<br>"; + break; + case "rejectusername": + text = "<b>Seu usuario foi configurado como <em>" + msg.name + "</em> porque o nome que você escolheu está em uso.</b><br>" + break; + case "userlist": + var ul = ""; + for (i=0; i < msg.users.length; i++) { + ul += msg.users[i] + "<br>"; + } + document.getElementById("userlistbox").innerHTML = ul; + break; + } + + if (text.length) { + f.write(text); + document.getElementById("chatbox").contentWindow.scrollByPages(1); + } +}; +</pre> + +<p>Aqui utilizamos <a href="/en/JavaScript/Reference/Global_Objects/JSON/parse" title="en/JavaScript/Reference/Global Objects/JSON/parse"><code>JSON.parse()</code></a> para conveter o objeto JSON de volta ao objeto original, em seguida, examine e aja de acordo com seu conteúdo.</p> + +<h3 id="Formato_de_dados_de_texto">Formato de dados de texto</h3> + +<p>O formato de Texto recebido através de uma conexão WebSocket está no formato UTF-8.</p> + +<h2 id="Fechando_a_conexão">Fechando a conexão</h2> + +<p>Quando finalizar o uso da conexão WebSocket, invoque o método <a href="/en/WebSockets/WebSockets_reference/WebSocket#close()" title="en/WebSockets/WebSockets reference/WebSocket#close()"><code>close()</code></a>:</p> + +<pre class="brush: js notranslate">exampleSocket.close(); +</pre> + +<p>Pode ser útil examinar o atributo <code>bufferedAmount</code> do socket antes de tentar fechar a conexão para determinar se qualquer dado ainda está pendente de transmissão na rede. </p> + +<h2 id="Considerações_de_segurança">Considerações de segurança</h2> + +<p>WebSockets não devem ser utilizados em um contexto de um ambiente misto, isto é, você não deveria abrir uma conexão não-segura a partir de uma página previamente carregada utilizando HTTPS, ou vice-versa. A maioria dos browsers atuamente apenas permitem conexões seguras pelo Websocke, e não mais suportam contextos diferentes desse.</p> diff --git a/files/pt-br/web/api/websockets_api/writing_websocket_server/index.html b/files/pt-br/web/api/websockets_api/writing_websocket_server/index.html new file mode 100644 index 0000000000..553ba11aec --- /dev/null +++ b/files/pt-br/web/api/websockets_api/writing_websocket_server/index.html @@ -0,0 +1,237 @@ +--- +title: 'Escrevendo um servidor WebSocket em C #' +slug: WebSockets/Writing_WebSocket_server +translation_of: Web/API/WebSockets_API/Writing_WebSocket_server +--- +<h2 id="Introdução">Introdução</h2> + +<p>Se você quiser usar uma API WebSocket, você precisara ter um servidor. Neste artigo vou mostrar como escrever um WebSocket em C#. Você pode fazer isso em qualquer linguagem server-side, mas para manter as coisas simples e mais compreensíveis eu escolhi uma linguagem Microsoft.</p> + +<p>Este servidor está em conformidade com a <a href="http://tools.ietf.org/html/rfc6455" title="http://tools.ietf.org/html/rfc6455">RFC 6455</a>, por isso irá tratar apenas as conexões com os navegadores Chrome versão 16, Firefox 11, IE 10 ou superior. </p> + +<h2 id="Primeiros_passos">Primeiros passos</h2> + +<p>Os WebSocket´s se comunicam através de uma conexão TCP (Transmission Control Protocol), felizmente o C# possui a classe <a href="https://msdn.microsoft.com/pt-br/library/system.net.sockets.tcplistener.aspx">TcpListener</a> que, como o nome sugere, tem a função de escutar (Listener) as comunicações via TCP. A classe TcpListener está no namespace System.Net.Sockets.</p> + +<div class="note"> +<p><span style="line-height: 1.572;">É uma boa idéia usar a palavra chave using para escrever menos. Isso significa que não é preciso você reescrever o namespace toda vez que usar uma classe dele.</span></p> +</div> + +<h3 id="TcpListener">TcpListener</h3> + +<p>Construtor:</p> + +<pre class="brush: cpp">TcpListener(System.Net.IPAddress localaddr, int port)</pre> + +<p>Aqui você define onde o servidor será acessível.</p> + +<div class="note"> +<p><span style="line-height: 1.572;">Para setar facilmente o tipo esperado no primeiro parâmetro, use o método estático Parse da classe IPAddress.</span></p> +</div> + +<p><span style="line-height: 1.572;">Métodos</span><span style="line-height: 1.572;">:</span></p> + +<ul> + <li><span style="line-height: 1.572;">Start()</span></li> + <li><span style="line-height: 1.572;">System.Net.Sockets.<a href="http://msdn.microsoft.com/en-us/library/system.net.sockets.tcpclient.aspx" title="http://msdn.microsoft.com/en-us/library/system.net.sockets.tcpclient.aspx">TcpClient</a> AcceptTcpClient()<br> + Espera por uma conexão TCP, aceita a conexão e retorna um objeto TcpClient.</span></li> +</ul> + +<p><span style="line-height: 1.572;">Veja como usar o que aprendemos:</span></p> + +<pre class="brush: cpp">using System.Net.Sockets; +using System.Net; +using System; + +class Server { + public static void Main() { + TcpListener server = new TcpListener(IPAddress.Parse("127.0.0.1"), 80); + + server.Start(); + Console.WriteLine("Server has started on 127.0.0.1:80.{0}Waiting for a connection...", Environment.NewLine); + + TcpClient client = server.AcceptTcpClient(); + + Console.WriteLine("A client connected."); + } +} +</pre> + +<h3 id="TcpClient"><span style="line-height: 1.572;">TcpClient</span></h3> + +<p>Métodos:</p> + +<ul> + <li><code>System.Net.Sockets.<a href="http://msdn.microsoft.com/en-us/library/system.net.sockets.networkstream.aspx" title="http://msdn.microsoft.com/en-us/library/system.net.sockets.networkstream.aspx">NetworkStream</a> GetStream()</code><br> + Obtém o fluxo (stream) do canal de comunicação. Ambos os lados do canal de comunicação possuem a capacidade de ler e escrever.</li> +</ul> + +<p>Propriedades:</p> + +<ul> + <li><code>int Available</code><br> + Este é o numero de bytes de dados que foram enviados. o valor é zero enquanto <em>NetworkStream.DataAvailable</em> for <em>falso</em>.</li> +</ul> + +<h3 id="NetworkStream">NetworkStream</h3> + +<p>Métodos:</p> + +<pre class="brush: cpp">Write(Byte[] buffer, int offset, int size)</pre> + +<p>Grava bytes do buffer, <em>offset </em>e <em>size </em>determinam o tamanho da mensagem.</p> + +<pre><span class="brush: cpp" style="line-height: 1.572;">Read(Byte[] buffer, int offset, int size)</span></pre> + +<p>Lê bytes para o <em>buffer, offset e size </em>determinam o tamanho da mensagem.<em> </em></p> + +<p>Vamos estender nosso exemplo.</p> + +<pre class="brush: cpp">TcpClient client = server.AcceptTcpClient(); + +Console.WriteLine("A client connected."); + +NetworkStream stream = client.GetStream(); + +//enter to an infinite cycle to be able to handle every change in stream +while (true) { + while (!stream.DataAvailable); + + Byte[] bytes = new Byte[client.Available]; + + stream.Read(bytes, 0, bytes.Length); +}</pre> + +<h2 id="Handshaking">Handshaking</h2> + +<p>Quando um cliente se conecta a um servidor, ele envia uma solicitação GET para atualizar a conexão com o WebSocket a partir de uma simples requisição HTTP. Isto é conhecido como handshaking (aperto de mão).</p> + +<div class="warning"> +<p>Este código tem um defeito. Digamos que a propriedade client.<code>Available</code> retorna o valor 2 porque somente a requisição GET está disponível até agora. a expressão regular iria falhar mesmo que os dados recebidos sejam perfeitamente válidos.</p> +</div> + +<pre class="brush: cpp">using System.Text; +using System.Text.RegularExpressions; + +Byte[] bytes = new Byte[client.Available]; + +stream.Read(bytes, 0, bytes.Length); + +//translate bytes of request to string +String data = Encoding.UTF8.GetString(bytes); + +if (new Regex("^GET").IsMatch(data)) { + +} else { + +}</pre> + +<p>Criar a resposta é mais fácil do que entender porque você deve fazê-lo desta forma.</p> + +<p>Você deve,</p> + +<ol> + <li>Obter o valor do cabeçalho da requisição <em>Sec-WebSocket-Key</em> sem qualquer espaço à direita e à esquerda;</li> + <li>Concatenar com "258EAFA5-E914-47DA-95CA-C5AB0DC85B11";</li> + <li>Calcular o código SHA-1 e Base64 dele;</li> + <li>Reescreva no cabeçalho de resposta o valor de <em>Sec-WebSocket-Accept</em> como parte de uma resposta HTTP.</li> +</ol> + +<pre class="brush: cpp">if (new Regex("^GET").IsMatch(data)) { + Byte[] response = Encoding.UTF8.GetBytes("HTTP/1.1 101 Switching Protocols" + Environment.NewLine + + "Connection: Upgrade" + Environment.NewLine + + "Upgrade: websocket" + Environment.NewLine + + "Sec-WebSocket-Accept: " + Convert.ToBase64String ( + SHA1.Create().ComputeHash ( + Encoding.UTF8.GetBytes ( + new Regex("Sec-WebSocket-Key: (.*)").Match(data).Groups[1].Value.Trim() + "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" + ) + ) + ) + Environment.NewLine + + Environment.NewLine); + + stream.Write(response, 0, response.Length); +} +</pre> + +<h2 id="Decodificação_de_mensagens">Decodificação de mensagens</h2> + +<p>Após um <em>handshake</em> de sucesso o cliente ponde enviar mensagens ao servidor, mas agora estas mensagens são codificadas.</p> + +<p>Se nós enviarmos "MDN", nós obtemos estes bytes:</p> + +<table> + <tbody> + <tr> + <td>129</td> + <td>131</td> + <td>61</td> + <td>84</td> + <td>35</td> + <td>6</td> + <td>112</td> + <td>16</td> + <td>109</td> + </tr> + </tbody> +</table> + +<p>- 129:</p> + +<table> + <thead> + <tr> + <th scope="col">FIN (Esta é toda a mensagem?)</th> + <th scope="col">RSV1</th> + <th scope="col">RSV2</th> + <th scope="col">RSV3</th> + <th scope="col">Opcode</th> + </tr> + </thead> + <tbody> + <tr> + <td>1</td> + <td>0</td> + <td>0</td> + <td>0</td> + <td>0x1=0001</td> + </tr> + </tbody> +</table> + +<p>FIN: Você pode enviar sua mensagem em quadros (frames), mas agora as coisas ficaram mais simples.<br> + <span style="line-height: 1.572;">Opcode </span><em>0x1</em><span style="line-height: 1.572;"> significa que este é um texto. Veja aqui a </span><a href="http://tools.ietf.org/html/rfc6455#section-5.2" style="line-height: 1.572;" title="http://tools.ietf.org/html/rfc6455#section-5.2">lista completa de Opcodes</a>.</p> + +<p>- 131:</p> + +<p>Se o segundo byte menos 128 estiver entre 0 e 125, este é o tamanho da mensagem. Se for 126, os 2 bytes seguintes (16-bit inteiro sem sinal) e se 127, os 8 bytes seguintes (64-bit inteiro sem sinal) são o comprimento.</p> + +<div class="note"> +<p>Eu posso escolher 128, porque o primeiro bit sempre será 1.</p> +</div> + +<p>- 61, 84, 35 e 6 são os bytes de chave para decodificar. Sempre mudam.</p> + +<p>- O restante dos bytes codificados são a mensagem<span style="line-height: 1.572;">.</span></p> + +<h3 id="Algoritmo_de_decodificação">Algoritmo de decodificação</h3> + +<p>byte decodificado = [byte codificado XOR (posição do byte codificado MOD 4º byte da chave)]</p> + +<p>Exemplo em C#:</p> + +<pre class="brush: cpp">Byte[] decoded = new Byte[3]; +Byte[] encoded = new Byte[3] {112, 16, 109}; +Byte[] key = Byte[4] {61, 84, 35, 6}; + +for (int i = 0; i < encoded.Length; i++) { + decoded[i] = (Byte)(encoded[i] ^ key[i % 4]); +}</pre> + +<h2 id="Link_Relacionado">Link Relacionado</h2> + +<ul> + <li><a href="/en-US/docs/WebSockets/Writing_WebSocket_servers">Writing WebSocket servers</a></li> +</ul> + +<div id="cke_pastebin" style="position: absolute; top: 2209.23px; width: 1px; height: 1px; overflow: hidden; left: -1000px;"> </div> diff --git a/files/pt-br/web/api/websockets_api/writing_websocket_servers/index.html b/files/pt-br/web/api/websockets_api/writing_websocket_servers/index.html new file mode 100644 index 0000000000..e493605538 --- /dev/null +++ b/files/pt-br/web/api/websockets_api/writing_websocket_servers/index.html @@ -0,0 +1,263 @@ +--- +title: Escrevendo um servidor WebSocket +slug: WebSockets/Writing_WebSocket_servers +tags: + - Guía + - HTML5 + - Tutorial + - WebSocket + - WebSockets +translation_of: Web/API/WebSockets_API/Writing_WebSocket_servers +--- +<p><span class="seoSummary">Um servidor de WebSocket é uma aplicação TCP que escuta uma porta de um servidor que segue um protocolo específico, simples assim. A tarefa de criar um servidor personalizado costuma assustar as pessoas; no entanto, pode ser fácil implementar um simples servidor WebSocket na sua plataforma de escolha. </span></p> + +<p>Um servidor WebSocket pode ser escrito em qualquer linguagem de programação server-side que é capaz de utilizar <a href="https://en.wikipedia.org/wiki/Berkeley_sockets">Berkeley sockets</a>, tais como C(++) , ou Python, ou mesmo o <a href="/en-US/docs/PHP">PHP</a> e o <a href="/en-US/docs/Web/JavaScript/Server-Side_JavaScript">server-side JavaScript</a>. Esse não é um tutorial em uma linguagem de programação específica, mas serve como guia para facilitar a escrita do seu próprio servidor.</p> + +<p>Você precisará saber como o HTTP funciona e ter uma experiência média com programação.</p> + +<p>Dependendo do suporte da linguagem, pode ser necessário o conhecimento sobre soquetes TCP. O escopo deste guia é apresentar o conhecimento mínimo que você precisa para escrever um servidor WebSocket.</p> + +<div class="note"> +<p>Leia a útlima especificação sobre WebSockets, a <a href="http://datatracker.ietf.org/doc/rfc6455/?include_text=1">RFC 6455</a>. As seções 1 e 4-7 são especialmente interessantes para implementadores de servidores. A seção 10 discute assuntos sobre segurança que você definitivamente deveria examinar antes de expor seu servidor.</p> +</div> + +<p>Um servidor de WebSocket é explicado de maneira bem simples aqui. Servidores de WebSocket geralmente são servidores separados e especializados (para balanceamento de carga ou outras razões práticas), então, geralmente você irá usar um proxy reverso (como um servidor HTTP comum) para detectar a solicitação de handshakes do WebSocket, pré-processá-los e enviar esses clientes para um servidor WebSocket real. Isso significa que você não precisa encher seu código com cookies e manipuladores de autenticação (por exemplo).</p> + +<p><a name="Handshake">O <em>Handshake</em> ("aperto de mão") do WebSocket</a></p> + +<p>Primeiro de tudo, o servidor deve ouvir as conexões socket recebidas usando um socket TCP padrão. Dependendo da sua plataforma, isso pode já ter sido tratado previamente. Por exemplo, vamos assumir que seu servidor está ouvindo example.com, porta 8000, e seu servidor socket responde às requisições GET em <code>/chat</code>.</p> + +<div class="warning"> +<p><strong>Aviso:</strong> O servidor pode ouvir qualquer porta que escolher, mas se escolher qualquer porta diferente de 80 e 443, podem ocorrer problemas relacionados aos firewalls e/ou proxies. Conexões na porta 443 tendem a ter mais sucesso com mais frequência, isso requer uma conexão segura (TLS/SSL). Também, note que a maioria dos browsers (notavelmente o Firefox 8+) não permite conexões de servidores WebSocket de páginas seguras.</p> +</div> + +<p>O handshake é a "Web" no WebSockets. É a ponte do HTTP para o Websocket. No handshake, detalhes da conexão são negociados, e qualquer uma das partes pode voltar antes da conclusão se os termos são desfavoráveis. O servidor deve ser cuidadoso para entender tudo que o cliente perguntar, caso contrário, serão introduzidas questões de segurança.</p> + +<h3 id="Requisição_Handshake_do_Cliente">Requisição Handshake do Cliente</h3> + +<p>Mesmo que você esteja construindo um servidor, um cliente ainda precisa iniciar o processo de handshake do WebSocket. Então você deve saber como interpretar a requisição do cliente. O cliente vai enviar uma requisição HTTP padrão que é parecida com isso (a versão do HTTP <strong>deve</strong> ser 1.1 ou maior, e o método <strong>deve</strong> ser um <code>GET</code>):</p> + +<pre>GET /chat HTTP/1.1 +Host: example.com:8000 +<strong>Upgrade: websocket</strong> +<strong>Connection: Upgrade</strong> +Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== +Sec-WebSocket-Version: 13 + +</pre> + +<p>O cliente pode solicitar extensões e/ou subprotocolos aqui; veja <a href="#Miscellaneous">Miscellaneous</a> para mais detalhes. Também, cabeçalhos comuns como <code>User-Agent</code>, <code>Referer</code>, <code>Cookie</code>, ou cabeçalhos de autenticação poderiam estar bem aqui. Faça o que você quiser com eles; eles não pertencem diretamente ao WebSocket. Também é seguro ignora-los. Em muitas configurações comuns, um proxy reverso ja tratou deles.</p> + +<p>Se qualquer cabeçalho não foi entendido ou conter um valor incorreto, o servidor deve enviar um erro "<a href="https://developer.mozilla.org/en-US/docs/HTTP/Response_codes#400">400 Bad Request</a>" e fechar o socket imediatamente. É comum, também dar a razão pelo qual o handshake falhou no body da resposta do HTTP, mas muitas mensages nunca serão mostradas (os browsers não mostram isso). Se o servidor não reconhecer a versão do WebSockets, deve enviar um cabeçalho <code>Sec-WebSocket-Version</code> que contenha a(s) versão(versões) que o mesmo entenda. (Esse guia explica o v13, o mais novo). Agora, vamos continuar para o cabeçalho mais curioso, o <code>Sec-WebSocket-Key</code>.</p> + +<div class="note"> +<p><strong>Dica:</strong> Todos os browsers vão enviar um <a href="https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS#Origin"><code>Origin</code> header</a>. Você pode usar esse cabeçalho por segurança (verifique pelo de mesma origem, whitelisting/ blacklisting, etc.) e envie uma <a href="https://developer.mozilla.org/en-US/docs/HTTP/Response_codes#403">403 Forbidden</a> se você não gostou do que viu. Sobretanto, fique ciente que os agentes non-browser podem apenas enviar uma falsa <code>Origin</code>. Muitas aplicações vão rejeitar requisições sem cabeçalho.</p> +</div> + +<div class="note"> +<p><strong>Dica:</strong> A request-uri (<code>/chat</code> aqui) não tem significado definido na especificação. Muitas pessoas utilizam habilmente para que servidores lidem com muiltíplas aplicações WebSocket. Por exemplo, <code>example.com/chat</code> deve invocar um app de chat com multiplos usuários, enquanto <code>/game</code> no mesmo servidor poderia invocar um jogo multiplayer.</p> +</div> + +<div class="note"> +<p><strong>Nota:</strong> <a href="https://developer.mozilla.org/en-US/docs/HTTP/Response_codes">Regular HTTP status codes</a> podem apenas ser usados antes do handshake. Depois que o handshake sucede, você deve usar um conjunto de códigos diferentes (definidos na seção 7.4 da especificação).</p> +</div> + +<h3 id="Resposta_Handshake_do_Servidor">Resposta Handshake do Servidor</h3> + +<p>Quanto o servidor receber a requisição de handshake, ele deve enviar um resposta especifica (odd-looking) que indica que o protocolo está sendo alterado de HTTP para WebSocket. Essa resposta se parece com isso (lembre-se cada final do cabeçalho com <code>\r\n</code> e coloque um <code>\r\n</code> extra depois do último):</p> + +<pre><strong>HTTP/1.1 101 Switching Protocols</strong> +Upgrade: websocket +Connection: Upgrade +<strong>Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= + +</strong></pre> + +<p>Adicionalmente, o servidor pode decidir sobre os pedidos de extensão/subprotocolo aqui; veja <a href="#Miscellaneous">Miscellaneous</a> para mais detalhes. O <code>Sec-WebSocket-Accept</code> é uma parte interessante. O servidor deve deriva-lo do <code>Sec-WebSocket-Key</code> que o cliente enviou. Para obte-lo, concatene <span style="line-height: 1.5em;">o </span><code style="font-size: 14px;">Sec-WebSocket-Key</code><span style="line-height: 1.5em;"> do cliente e a string "</span><code style="font-size: 14px;">258EAFA5-E914-47DA-95CA-C5AB0DC85B11</code><span style="line-height: 1.5em;">" juntos (isso é uma "</span><a href="https://en.wikipedia.org/wiki/Magic_string" style="line-height: 1.5em;">magic string</a><span style="line-height: 1.5em;">"), pegue o </span><a href="https://en.wikipedia.org/wiki/SHA-1" style="line-height: 1.5em;">SHA-1 hash</a><span style="line-height: 1.5em;"> do resultado, e retorne o</span><span style="line-height: 1.5em;"> codigo </span><a href="https://en.wikipedia.org/wiki/Base64" style="line-height: 1.5em;">base64</a><span style="line-height: 1.5em;"> do hash.</span></p> + +<div class="note"> +<p><strong>FYI:</strong> Esse processo, aparentemente complicado existe para que seja óbvio para o cliente se o servidor suporta ou não o WebSockets. Isso é importante por causa de problemas com segurança que aparecem se o servidor aceita a conexão WebSocket mas interpreta que os dados são uma requisição HTTP.</p> +</div> + +<p>Então se a chave foi "<code>dGhlIHNhbXBsZSBub25jZQ==</code>", o cabeçalho <code>Sec-WebSocket-Accept</code> aceito será "<code>s3pPLMBiTxaQ9kYGzzhZRbK+xOo=</code>". Uma vez que o servidor envie estes cabeçalhos, o handshake esta completo e você pode começar a trocar dados!</p> + +<div class="note"> +<p>O servidor pode enviar outros cabeçalhos como Set-Cookie, ou perguntar por autenticação ou redirecionar via outros códigos de status, antes enviando a resposta do handshake.</p> +</div> + +<h3 id="Acompanhamento_dos_clientes">Acompanhamento dos clientes</h3> + +<p>Isso não está diretamente relacionado ao protocolo de WebSocket, mas vale apena mencionar aqui: seu servidor terá que acompanhar os soquetes dos clientes para que você não tenho que fazer o handshake novamente com clientes que já concluiram o handshake. O mesmo endereço IP do cliente pode tentar se conectar varias vezes (mas o servidor pode negar se tentarem fazer muitas conexões em razão de se defender de <a href="https://pt.wikipedia.org/wiki/Ataque_de_negação_de_serviço">ataques de negação de serviço</a>).</p> + +<h2 id="Trocando_Data_Frames">Trocando Data Frames</h2> + +<p>Tanto o cliente quanto o servidor podem enviar mensagens a qualquer momento — essa é a mágia do WebSocket. Entretanto, extrair informações desses chamados "frames" de dados não é um experiencia tão magica assim. Apesar de todos os <em>frames </em>seguirem um mesmo formato, os dados do cliente são enviados criptografados para o servidor, usando <a href="https://en.wikipedia.org/wiki/XOR_cipher">criptografia XOR</a> (com uma chave de 32 bits). A <a href="http://tools.ietf.org/html/rfc6455#section-5">seção 5 da especificação</a> do <a href="https://datatracker.ietf.org/doc/rfc6455/">protocolo de WebSocket</a> descreve isso em detalhes.</p> + +<h3 id="Formato">Formato</h3> + +<p>Cada <em>data frame</em> (do cliente para o servidor ou vice-versa) segue o mesmo formato:</p> + +<pre>Frame format: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-------+-+-------------+-------------------------------+ + |F|R|R|R| opcode|M| Payload len | Extended payload length | + |I|S|S|S| (4) |A| (7) | (16/64) | + |N|V|V|V| |S| | (if payload len==126/127) | + | |1|2|3| |K| | | + +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - + + | Extended payload length continued, if payload len == 127 | + + - - - - - - - - - - - - - - - +-------------------------------+ + | |Masking-key, if MASK set to 1 | + +-------------------------------+-------------------------------+ + | Masking-key (continued) | Payload Data | + +-------------------------------- - - - - - - - - - - - - - - - + + : Payload Data continued ... : + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + | Payload Data continued ... | + +---------------------------------------------------------------+</pre> + +<p>O bit de MASK simplesmente diz se a mensagem está codificada. Mensagens do cliente devem estar mascaradas, então seu servidor deve esperar que o valor de MASK seja 1. De fato, a <a href="http://tools.ietf.org/html/rfc6455#section-5.1">seção 5.1 da especificação</a> diz que seu servidor deve se desconectar de um cliente se este cliente enviar mensagens que não estão mascaradas. Quando enviando um <em>frame</em> para o cliente, não mascare a mensagem e não defina o bit MASK. Explicaremos o mascaramento mais tarde.</p> + +<div class="blockIndicator note"> +<p>Você tem que mascarar as mensagens mesmo quando usando secure socket (SSL).<br> + Os campos RSV de 1 à 3 do cabeçalho podem ser ignorados, eles são para extenções.</p> +</div> + +<p>O campo <code>opcode</code> define como interpretar o <code>payload data</code>: <kbd>0x0</kbd> para continuo, <kbd>0x1</kbd> para texto (que sempre está codificadao em UTF-8), <kbd>0x2</kbd> para binário, e outros conhecidos como "control codes" seram discutidos posteriormente. Nessa versão de WebSockets, <kbd>0x3</kbd>, a <kbd>0x7</kbd> e <kbd>0xB</kbd> a <kbd>0xF</kbd> tem o mesmo significado.</p> + +<p>O bit FIN disso se é a ultima mensagem da serie. Se for <kbd>0</kbd>, então o servidor irá continuar esperando por mair partes da mensagem; caso contrário, o servidor pode considerar a mensagem como enviada.</p> + +<p>Se falará mais sobre isso depois.</p> + +<h3 id="Decodificando_o_Payload_Length">Decodificando o Payload Length</h3> + +<p>Para ler o <code>payload data</code>, você deve saber quando parar de ler. Por isso é importante saber o tamanho do payload (payload length). Infelizmente, conseguir essa informação é de certa forma complicado. Para obte-lá, seguimos esses passos:</p> + +<ol> + <li>Ler os bits 9-15 (inclusivo) e interpretar como um unsigned integer. Se o valor for de 125 ou menor, esse é o tamanho; temos a resposta. Se o valor é igual a 126, então vai para o passo 2, ou se for 127, então vai para o passo 3.</li> + <li>Ler os próximos 16 bits e interpretar como um unsined integer, esse é o tamanho; temos a resposta</li> + <li>Ler os próximos 64 bits e interpretar como um unsigned integer (o bit mais significante DEVE ser 0), esse é o tamanho; temos a resposta.</li> +</ol> + +<h3 id="Lendo_e_Desmascarando_o_Dado">Lendo e Desmascarando o Dado</h3> + +<p>Se o bit <code>MASK</code> for definido (e deve estar, para mensagens cliente-para-servidor), leia os próximos 4 octetos (32 bits); isso é a chave da mascara. Uma vez que o <code>payload length</code> e o <code>masking key</code> são decodificados, você pode seguir em frente e ler o número de bytes do socket.</p> + +<p>Vamos chamar os dados de <strong>ENCODED</strong>, e a chave de <strong>MASK</strong>.</p> + +<p>Para conseguir o <strong>DECODED</strong>, faça um loop sobre os octetos de <strong>ENCODED</strong> e um XOR do (i módulo 4) ezimo octeto de <strong>MASK</strong>. Em pseudo-código (isso é para ser valida em JavaScript):</p> + +<pre>var DECODED = ""; +for (var i = 0; i < ENCODED.length; i++) { + DECODED[i] = ENCODED[i] ^ MASK[i % 4]; +<span style="line-height: 1.5;">}</span></pre> + +<p>Agora você pode descobrir o que DECODED significa, dependendo da sua aplicação.</p> + +<h3 id="Fragmentação_de_Mensagens">Fragmentação de Mensagens</h3> + +<p>Os campos <code>FIN</code> e <code>opcode</code> trabalham juntos para enviar uma mensagens quebradas em mais de um <em>frame</em>. Isso é chamado de fragmentação. Fragmentação está disponível apenas sobre <code>opcode</code> <kbd>0x0</kbd> a <kbd>0x2</kbd>.</p> + +<p>Lembre que o <code>opcode</code> diz o que o <em>frame</em> deve fazer. Se for <kbd>0x1</kbd>, o payload um é texto. Se for <kbd>0x2</kbd>, o payload são dados binários. Entretanto, se for <kbd>0x0</kbd>, o <em>frame</em> é um<em>frame de continuação</em>. Isso significa que o servidor deve concatenar o <em>frame</em> de payload com o último frame recebido do cliente.</p> + +<p>Aqui está um exemplo, de como o servidor reage a um cliente enviando uma mensagem de texto. A primeira mensagem é enviada em um frame unico, enquanto a segunda mensagem é enviada através de tres frames. Os detalhes de <code>FIN</code> e <code>opcode</code> são mostrados apenas para o cliente:</p> + +<pre style="font-size: 14px;"><strong>Client:</strong> FIN=1, opcode=0x1, msg="hello" +<strong>Server:</strong> <em>(process complete message immediately) </em>Hi. +<strong>Client:</strong> FIN=0, opcode=0x1, msg="and a" +<strong>Server:</strong> <em>(listening, new message containing text started)</em> +<strong>Client:</strong> FIN=0, opcode=0x0, msg="happy new" +<strong>Server:</strong> <em>(listening, payload concatenated to previous message)</em> +<strong>Client:</strong> FIN=1, opcode=0x0, msg="year!" +<strong>Server:</strong> <em>(process complete message) </em>Happy new year to you too!</pre> + +<p>Note que o primeiro <em>frame</em> que contém a mensagem inteira tem o <code>FIN igual a 1</code> e o <code>opcode igual a 0x1</code>, entao o servidor pode processar ou responder como achar melhor.<br> + O segundo frame enviado pelo cliente é uma mensagem de texto com payload <code>opcode igual a 0x1</code>, mas a mensagem inteira ainda não chegou (<code>FIN=0</code>). Todos as partes restantes da mensagem são enviados em frames continuos (<code>opcode=0x0</code>), e o frame final da mensagem é marcado com <code>FIN=1</code>. <a href="http://tools.ietf.org/html/rfc6455#section-5.4">Seção 5.4 da especificação</a> descreve a fragmentação de mensagens.</p> + +<h2 id="Pings_e_Pongs_O_Heartbeat_do_WebSockets">Pings e Pongs: O Heartbeat do WebSockets</h2> + +<p>Em qualquer momento do handshake, tanto o cliente quanto o servidor podem enviar um ping para a outra parte. Quando o ping é rescebido, o destinatário deve responder com um pong assim que possível. Você pode usar isso para garantir que o cliente está conectado, por exemplo.</p> + +<p>Um ping ou um pong é um frame comum, entretanto é usado para controle. Pings tem o valor de opcode <kbd>0x9</kbd>, enquanto que pongs tem o opcode <kbd>0xA</kbd>. Quando você recebe um ping, envia de volta um pong com o mesmo exato <code>payload data</code> do ping (para pings e pongs, o <code>payload length</code> máximo é 125). Você também pode ter um pong sem nunca receber um ping; ignore isso caso ocorra.</p> + +<div class="blockIndicator note"> +<p>Se você receber mais de um ping antes de ter a chance de enviar um pong, você envia apenas um pong.</p> +</div> + +<h2 id="Fechando_a_conexão">Fechando a conexão</h2> + +<p>Para fechar a conexão tanto cliente quanto servidor podem enviar um frame de controle com dados contendo a sequencia de controles especifica para iniciar o fim do handshake (detalhado na seção 5.5.1). Assim que receber esse tipo de frame, a outra parte envia um frame de fechamento em resposta. A primeira parte então fecha a conexão. Quais quer outros dados recebidos depois de fechar a conexão é descartado. </p> + +<h2 id="Diversos"><a name="Miscellaneous">Diversos</a></h2> + +<div class="note"> +<p>Códigos WebSocket, extensões, subprotocols, etc. são registrados na <a href="http://www.iana.org/assignments/websocket/websocket.xml">IANA WebSocket Protocol Registry</a>.</p> +</div> + +<p>As extensões e subprotocolos do WebSocket são negociados via headers durante the handshake. Algumas vezes extensões e subprotocolos paracem muito similares para serem coisas diferentes, mas eles tem claras distinções. Extensões controlam os <strong>frame</strong> do WebSocket e <strong>modificam</strong> o payload, enquanto os subprotocolos estruturam o <strong>payload</strong> do WebSocket e <strong>nunca modificam</strong> nada. Extensões são opcionais e generalizadas (como comporessam); subprotocolos são mandatórios e localizados (como os usados para chat e para jogos MMORPG).</p> + +<h3 id="Extensões">Extensões</h3> + +<div class="note"> +<p><strong>Essa sessão precisa ser mais desenvolvida. Por favor edite se você tiver conhecimento sobre.</strong></p> +</div> + +<p>Imagine um extensão que comprime um arquivo antes de ser enviado em um e-mail para alguem. Independente do que você faça, está enviando o <em>mesmo</em> dado de formas diferentes. O destinatário eventualmente terá os mesmos dados que a cópia local que você tem, mas foram enviadas de formas diferentes. Isso é o que extensões fazem. WebSockets definem um protocolo e um forma simples de envio de dados, mas uma extensão como um compressor pode enviar o mesmo dado em um formado menor.</p> + +<div class="note"> +<p>Extensões são explicadas nas sessões 5.8, 9, 11.3.2 e 11.4 da especificação.</p> +</div> + +<h3 id="Subprotocols">Subprotocols</h3> + +<p>Pense em um subprotocolo como um <a href="https://pt.wikipedia.org/wiki/XML">esquema XML</a> personalizado ou <a href="https://en.wikipedia.org/wiki/Document_Type_Definition">doctype declaration</a>. Você ainda está usando XML e sua sintaxe, mas também é restringido por uma estrutura em que concordou. Os subprotocolo WebSocket são exatamente assim. Eles não apresentam nada sofisticado, apenas estabelecem estrutura. Como um doctype ou esquema, ambas as partes devem concordar com o subprotocolo; diferente de um doctype ou esquema, o subprotocolo é implementado no servidor e não pode ser referenciado externamente pelo cliente.</p> + +<div class="note"> +<p>Subprotocolos são explicados nas sessões 1.9, 4.2, 11.3.4 e 11.5 da especificação.</p> +</div> + +<p>Um cliente precisa solicitar um subprotocolo específico. Para fazer isso, ele enviará algo como isso <strong>como parte do handshake original</strong>:</p> + +<pre>GET /chat HTTP/1.1 +... +Sec-WebSocket-Protocol: soap, wamp + +</pre> + +<p>ou, equivalentemente:</p> + +<pre>... +Sec-WebSocket-Protocol: soap +Sec-WebSocket-Protocol: wamp + +</pre> + +<p>Agora, o servidor deve escolher um dos protocolos que o cliente sugeriu e suporta. Se houver mais de um, envie o primeiro que o cliente enviou. Imagine que nosso servidor possa usar <code>soap</code> e <code>wamp</code>. Em seguida, no handshake de resposta, ele enviará:</p> + +<pre>Sec-WebSocket-Protocol: soap + +</pre> + +<div class="warning"> +<p>O servidor não pode enviar mais de um cabeçalho <code>Sec-Websocket-Protocol</code>.<br> + Se o servidor não quiser usar nenhum subprotocolo, <strong>ele não deverá enviar nenhum cabeçalho <code>Sec-WebSocket-Protocol</code></strong>. O envio de um cabeçalho em branco está incorreto.<br> + O cliente pode fechar a conexão se não conseguir o subprotocolo desejado.</p> +</div> + +<p>Se você deseja que seu servidor obedeça a certos subprotocolo, então naturalmente precisará de código extra no servidor. Vamos imaginar que estamos usando um subprotocolo <code>json</code>. Neste subprotocolo, todos os dados são transmitidos como JSON. Se o cliente solicitar esse protocolo e o servidor quiser usá-lo, o servidor precisará ter um analisador JSON. Na prática, isso fará parte de uma biblioteca, mas o servidor precisará transmitir os dados.</p> + +<div class="note"> +<p><strong>Tip:</strong> Para evitar o conflito de nomes, recomenda-se que o subprotocolo seja nomeado como parte da string do domínio. Se você está desenvolvendo um aplicativo de bate-papo personalizado que usa um formato proprietário exclusivo da Exemplo Inc., então você pode usar isso: <code>Sec-WebSocket-Protocol: chat.example.com</code>. Note que isso não é necessário, é apenas uma convenção opcional, e você pode usar qualquer string que desejar.</p> +</div> + +<h2 id="Relacionado">Relacionado</h2> + +<ul> + <li><a href="https://github.com/alexhultman/libwshandshake">Biblioteca para o "<em>aperto de mão"</em> do WebSocket em C++</a></li> + <li><a href="/en-US/docs/WebSockets/Writing_WebSocket_server" title="/en-US/docs/WebSockets/Writing_WebSocket_server">Tutorial: Servidor Websocket em C#</a></li> + <li><a href="/en-US/docs/WebSockets/Writing_WebSocket_client_applications">Escrevendo aplicações WebSocket do cliente</a></li> + <li><a href="/en-US/docs/WebSockets/WebSocket_Server_Vb.NET">Tutorial: Servidor Websocket em VB.NET</a></li> + <li><a href="https://datatracker.ietf.org/doc/rfc6455/">Especificação do protocolo (RFC 6455)</a></li> +</ul> |