Aplicativos web em C++ usando o Tufão

Quando eu comento sobre desenvolvimento web em C++ a alguns programadores, eles demonstram uma falta de fé perceptível na ideia, enquanto outros ficam curiosos e começam a discutir como as peculiaridades da linguagem afetam o seu uso na área. Inspirado pela framework Node.js, desenvolvi o Tufão.

[ Hits: 23.704 ]

Por: Vinícius dos Santos Oliveira em 12/06/2012 | Blog: https://vinipsmaker.github.io/


Um pouco sobre HTTP



Não é realmente necessário entender o HTTP para criar aplicações web, mas é interessante que se tenha uma visão geral do mesmo para projetar aplicações mais robustas e saber como contornar suas limitações. Não espere se tornar um mestre do protocolo lendo esse texto, mas também não espere que esse seja um texto introdutório para que você aprenda a implementar o protocolo. Meu único objetivo aqui é destacar algumas peculiaridades do HTTP. Caso queira um conhecimento mais profundo, comece pela RFC2616.

HTTP é um protocolo cliente-servidor baseado em mensagens usado para obtenção de entidades. A responsabilidade do servidor é responder as mensagens de requisição e um mesmo servidor pode servir diferentes recursos.

Cada mensagem HTTP é composta de uma linha inicial, que depende do tipo de mensagem (requisição ou resposta), um conjunto de linhas de cabeçalho, que compõem os metadados da mensagem, e o corpo da mensagem, que carrega uma entidade.

As mensagens HTTP possuem algumas propriedades. Quero que você, durante a leitura desse texto, esteja ciente das seguintes:
  • Existe um verbo associado a cada mensagem de requisição.

    As mensagens de requisição mais comuns utilizam o método GET, que em condições normais não modifica o recurso-alvo, mas outros métodos existem, sejam eles definidos no RFC2616 ou criados por aplicações específicas como o Subversion. Alguns deles são:
    • GET: Requisita uma entidade identificada pelo recurso indicado.
    • HEAD: Permite obter os metadados da mensagem sem obter a entidade.
    • POST: Permite que o cliente envie dados (uma imagem, um texto, ...) para o servidor.

  • O cliente pode enviar mensagens ao servidor, mas o contrário não acontece.

    Mesmo que a conexão já tenha sido iniciada pelo cliente. Para contornar o problema existem várias soluções, cada uma com diferentes desvantagens. Para resolver o problema foi desenvolvido o protocolo WebSocket, para ser usado em conjunto com a capacidade do HTTP de atualizar o protocolo em uso por uma conexão já em andamento.

  • Para cada conexão com um servidor, só uma mensagem de requisição pode ser enviada por vez.

    Isso não significa que o cliente deve esperar pela resposta da primeira mensagem antes de fazer a segunda requisição, mas que duas mensagens não podem ser embaralhadas. Caso fosse possível, o servidor poderia responder as mensagens em qualquer ordem, que seria um recurso interessante para ter um melhor aproveitamento de rede em casos onde uma requisição específica demanda um tempo maior para ser respondida.

  • O corpo de uma mensagem nem sempre é igual à entidade a ela associada.

    Algumas vezes são aplicadas transformações, que podem adicionar alguns benefícios:
    • Compressão, permitindo um melhor uso do tráfego de rede. Atualmente não é suportado de forma transparente pelo Tufão, mas planejado para a versão 0.4.
    • Quebra da mensagem em chunks. No protocolo HTTP/1.0, era necessário que o servidor enviasse o tamanho do corpo da mensagem antes da mensagem, o que dificultava o uso do protocolo para enviar dados que ainda estavam sendo gerados. Usar o protocolo para transmissão ao vivo, por exemplo, seria uma péssima ideia.


Para obter a página inicial da Wikipédia, por exemplo, a seguinte mensagem de requisição seria enviada:

GET /wiki/Main_Page HTTP/1.1
Host: en.wikipedia.org
Connection: close


A mensagem de requisição possui uma linha inicial conhecida como request line, que indica, além do método, o recurso desejado e a versão HTTP suportada.

O começo da mensagem de resposta para a requisição acima, no momento em que fiz a requisição, foi:

HTTP/1.0 200 OK
Date: Sun, 27 May 2012 20:50:07 GMT
Server: Apache
X-Content-Type-Options: nosniff
Cache-Control: private, s-maxage=0, max-age=0, must-revalidate
Content-Language: en
Vary: Accept-Encoding,Cookie
Last-Modified: Sun, 27 May 2012 20:10:23 GMT
Content-Length: 59587
Content-Type: text/html; charset=UTF-8
X-Cache: MISS from cp1007.eqiad.wmnet
X-Cache-Lookup: MISS from cp1007.eqiad.wmnet:3128
Age: 665
X-Cache: HIT from cp1004.eqiad.wmnet
X-Cache-Lookup: HIT from cp1004.eqiad.wmnet:80
Connection: close


A primeira linha da mensagem de resposta é chamada de status line e indica a validade da requisição. Isso é, se o recurso requisitado foi encontrado ou não, se o intervalo requisitado é satisfazível, entre outros. Os códigos mais comuns são "200 OK", usado quando não há erros, e "404 Not Found", usado quando não existe uma entidade associada ao recurso requisitado pelo cliente.

Grande parte desses cabeçalhos não deve mudar entre a maior parte das páginas da Wikipédia, mas a principal mudança deve ocorrer no recurso requisitado (nesse caso /wiki/Main_Page) e no corpo da mensagem de resposta (omitido nesse caso).

Os cabeçalhos em uma mensagem construídos na forma "Chave: valor", com a chave sendo insensível a capitalização e podendo existir espaços arbitrariamente entre os elementos.

O cabeçalho Host é obrigatório no HTTP/1.1 e foi criado para permitir Virtual Hosting.

Cada cabeçalho tem um significado definido e implementações costumam simplesmente ignorar cabeçalhos desconhecidos ou não implementados.

O Tufão vai cuidar dos principais cabeçalhos e comportamentos para você, exigindo que você examine-os somente em casos especiais e foque sua atenção na construção das páginas.

Página anterior     Próxima página

Páginas do artigo
   1. Introdução
   2. Um pouco sobre HTTP
   3. Arquitetura do Tufão
   4. WebSocket
   5. Criando uma aplicação de chat
Outros artigos deste autor

VLC Media Player

Mupen64plus, o melhor emulador de Nintendo 64 disponível para GNU/Linux

Próximas Tecnologias do Sistema GNU/Linux

História da informática: Um pouco de datas e especificações

Tratamento de exceções na linguagem C

Leitura recomendada

Criando aplicações RESTful com Qt e Cutelyst

DotGNU: a resposta Open Source ao dotNET

Biblioteca VBMcgi: Crie aplicações Web CGI em C++ com acesso ao banco Interbase/Firebird sem mistério

BSD Sockets em linguagem C

Utilizando a biblioteca NCURSES - Parte II

  
Comentários
[1] Comentário enviado por bolche em 12/06/2012 - 14:23h

Legal, tava querendo brincar de aplicativos web em C++ faz um tempo.
Você podia aproveitar a infraestrutura de outro servidor web ao invés de fazer tudo do zero, por exemplo o apache, modificar o processo de construção para construir um módulo do apache ao invés de um servidor standalone. Talvez um protocolo mais agnóstico como FastCGI seja ainda melhor.
De qualquer maneira, muito legal!

[2] Comentário enviado por vinipsmaker em 12/06/2012 - 15:59h


[1] Comentário enviado por bolche em 12/06/2012 - 14:23h:

Legal, tava querendo brincar de aplicativos web em C++ faz um tempo.
Você podia aproveitar a infraestrutura de outro servidor web ao invés de fazer tudo do zero, por exemplo o apache, modificar o processo de construção para construir um módulo do apache ao invés de um servidor standalone. Talvez um protocolo mais agnóstico como FastCGI seja ainda melhor.
De qualquer maneira, muito legal!


Não criei tudo do 0, utilizo o parser HTTP criado durante o projeto Node.js.

E já pensei sobre o uso de FastCGI, mas queria diminuir o gargalo para aumentar o desempenho e fazer um servidor standalone é uma das estratégias. Isso, só ressaltando, traz outras implicações, mas é fácil contornar essa decisão usando, no Apache mesmo, proxy reverso ( http://httpd.apache.org/docs/2.0/mod/mod_proxy.html ).

[3] Comentário enviado por julio_hoffimann em 12/06/2012 - 19:45h

Parabéns pelo projeto Vinícius!

Abraço!

[4] Comentário enviado por fabio em 12/06/2012 - 20:00h

Muito bom mesmo. Como é o desempenho de sites em C++ se comparados com linguagens interpretadas, tal como o PHP? Vale a pena?

[5] Comentário enviado por julio_hoffimann em 12/06/2012 - 20:13h

Estava tentando lembrar o nome de um projeto recente da Google para aplicações web em código nativo: http://www.youtube.com/watch?v=UUnC5y4j0As

A idéia é poder rodar aplicações C/C++ ou outras linguagem de alta performance no navegador de forma segura, talvez seja de interesse do autor. ;-)

Abraço!

[6] Comentário enviado por vinipsmaker em 12/06/2012 - 22:24h


[5] Comentário enviado por julio_hoffimann em 12/06/2012 - 20:13h:

Estava tentando lembrar o nome de um projeto recente da Google para aplicações web em código nativo: http://www.youtube.com/watch?v=UUnC5y4j0As

A idéia é poder rodar aplicações C/C++ ou outras linguagem de alta performance no navegador de forma segura, talvez seja de interesse do autor. ;-)

Abraço!


http://en.wikipedia.org/wiki/Google_Native_Client ? Já conhecia.
:P

[7] Comentário enviado por vinipsmaker em 13/06/2012 - 09:09h


[4] Comentário enviado por fabio em 12/06/2012 - 20:00h:

Muito bom mesmo. Como é o desempenho de sites em C++ se comparados com linguagens interpretadas, tal como o PHP? Vale a pena?


Tem um texto onde eu discuti bastante sobre a escolha da linguagem para o Tufão:
http://vinipsmaker.wordpress.com/2012/05/07/understanding-tufao-part-1/

Mas, para discutir sobre desempenho, eu preciso fazer benchmarks, para não caminhar muito na direção do "achismo". Fico devendo um benchmark.


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner
Linux banner
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts