-
;
Serviços de informação Internet podem ser o caminho primário para pessoas acessarem as publicações e bancos de dados do futuro. A disseminação de servicos como correio eletronico e aos sites da Web, motivam os usuarios a usar e exigir mais eficiencia dos servicos disponibilizados na Internet..
Uma característica notável na Internet é
que muitos dos serviços que executam sobre ela são implementados
usando uma arquitetura cliente/servidor. A arquitetura cliente/servidor
dos serviços de informação Internet é que torna
possível para qualquer computador conectado a Internet prover serviços
para qualquer outro. Esta é a maior diferença
entre a Internet e as redes comerciais como a CompServe, que provêem
todos os serviços de
computadores na rede e não permite usuários
fornecer informação (exceto email) para outros usuários.
Antes de descrevermos os serviços Internet nós
abrangeremos alguns conceitos iniciais sobre a estrutura e comunicação
dos mesmos. Depois de uma breve visão sobre os requisitos para disponibilizar/utilizar
os serviços de informação, em termos de hardware,
redes e humanos, trataremos em seguida mais detalhadamente o serviço
Internet World Wide Web.
Administração de Serviços Internet
Serviços de informação Internet podem ser o caminho primário para pessoas acessarem as publicações e bancos de dados do futuro. Você já pode ler muita coisa na rede, como um jornal ou uma revista, e efetuar negócios sérios, como compras e vendas, utilizando os serviços Gopher ou WWW.
A implantação de serviços de informação Internet é simples e barata o bastante para indivíduos e pequenos grupos filantrópicos desejarem possuí-los.
Organizações estão desdobrando os serviços Internet para prover serviços para seus clientes.
Por estas razões, serviços de informação Internet são excitantes. Talvez, o mais interessante serão as decisões tomadas sobre como usar estes serviços. Serviços Internet acabaram de alcançar uma massa crítica, onde o crescimento do número de usuários Internet estão atraindo serviços e vice-versa.
Antes de descrevermos os serviços Internet nós abrangeremos alguns conceitos iniciais sobre a estrutura e comunicação dos mesmos.
Depois de uma breve visão sobre os requisitos para disponibilizar/utilizar os serviços de informação, em termos de hardware, redes e humanos, trataremos em seguida mais detalhadamente o serviço Internet World Wide Web.
Como os serviços Internet estão estruturados
Uma característica notável na Internet é que muitos dos serviços que executam sobre ela são implementados usando uma arquitetura cliente/servidor.
Na clássica arquitetura de software cliente/servidor, há dois lados:
Clientes de serviço de informação tipicamente aceitam consultas ou outras entradas de teclado (ou mouse) de usuários, envia aquelas consultas ou caracteres para o servidor, e então gerencia a saída do dado resultante. Os servidores recebem consultas ou outros dados dos clientes, processa-os lendo os arquivos, conduz a busca ou executa comandos, e envia o resultado, ou uma indicação de status da operação, para os clientes.
A arquitetura cliente/servidor dos serviços de informação Internet é que torna possível para qualquer computador conectado a Internet prover serviços para qualquer outro. Esta é a maior diferença entre a Internet e as redes comerciais como a CompServe, que provêem todos os serviços de computadores na rede e não permite usuários fornecer informação (exceto email) para outros usuários.
Como o Cliente de Informação Conversa com o Servidor de Informação
Para mostrar como o cliente de informação conversa com o servidor de informação, usaremos um cliente Gopher comunicando-se com um servidor Gopher. O protocolo Gopher é a linguagem que usa os clientes Gopher para se comunicar com os servidores Gopher (e vice-versa). Seu propósito básico é levar as requisições do cliente para o servidor e documentos (ou informações sobre quais documentos estão disponíveis) do servidor para o cliente.
Primeiro, o usuários especificam que eles gostariam de ver um recurso em um servidor Gopher, como um documento em particular. Talvez ele faça isto clicando em um item de menu. O cliente aceita esta entrada e a traduz para uma consulta aceitável para enviar para o servidor Gopher. O cliente "olha" em /etc/services para encontrar o número de porta apropriado pelo qual contata o servidor Gopher e encontra isto:
Gopher 70/tcp
Esta linha significa que deseja-se conectar com o servidor Gopher conectando-se a porta 70 usando o protocolo TCP. O cliente então encapsula a consulta dentro de um pacote TCP, ou um série de pacotes TCP, se é uma consulta longa, e a envia para o servidor na porta 70 da máquina servidora.
O próprio servidor Gopher pode estar "executando" na porta 70 do computador destino, ou o inetd pode estar executando por ele. Se o inetd recebe o pacote TCP, ele checa o número da porta destino. Ele usa a mesma entrada do /etc/services (no sistema do servidor) para mapear o número da porta de volta para o nome do serviço, neste caso, Gopher. Uma vez ele figura aquela saída, inicializa o servidor Gopher, gopherd, e faz a conexão com o cliente remoto para o servidor.
O servidor Gopher processa o dado TCP recebido e interpreta a consulta. Desde que isto seja uma requisição para um arquivo particular no servidor, o servidor abre e lê o arquivo e então envia-o de volta para o cliente da rede, como uma corrente de pacotes TCP. O cliente recebe esta informação e armazena-a na memória ou no disco. Depois do arquivo completo ter sido enviado para o cliente, a conexão TCP é desfeita usando uma seqüência especial de pacotes TCP. Com a informação em um arquivo serializado, o cliente decide o que exibir para o usuário, incluindo possivelmente inicializar um programa de visualização de imagens. O ciclo está completo.
Note que a conexão TCP é feita e desfeita novamente para todos as requisições de documentos. Não há conexão TCP quando o usário está lendo documentos
Servidores Web são análogos a servidores Gopher, em que cada documento cria uma nova conexão TCP. No entanto, o Web suponhe um passo a frente: cada gráfico em um documento Web cria uma conexão TCP separada com o servidor que guarda aquele gráfico. Então, quando o usuário requer um documento, isto pode iniciar múltiplas requisições TCP com o mesmo ou diferente servidor Web.
FTP é completamente diferente de Gopher ou de Web. Ele cria duas conexões entre o servidor e o cliente, um para controle da conexão, e o outro para o envio de dados. A conexão de controle fica no ar durante o tempo que o usuário está "logado". A conexão de dados é feita quando necessário.
Serviços de Informação na Internet
Na Internet existem inúmeros tipos de serviços de informação. Nesta seção daremos uma ligeira visão de alguns destes serviços, dando um enfoque em o que é cada um deles e como operam.
Quando a ARPANET - primeira rede de computadores, da qual evoluiu a Internet - entrou em operação, os profissionais que a modelaram acreditavam que a troca de dados entre os programas que rodavam nos distintos computadores dominaram o tráfego na rede. Estavam errados. Hoje o volume de mensagens eletrônicas entre as pessoas tem ultrapassado o volume de comunicação entre os processos. A principal atração pelo correio eletrônico (e-mail) está na sua rapidez. Isso sem mencionar que ele não obriga que ambas as partes estejam simultaneamente disponíveis e permite gravarmos uma cópia da mensagem em um arquivo, enviando-a a outra pessoas na rede, de enviarmos uma determinada mensagem para várias pessoas ao mesmo tempo. Embora possa se encarado como uma caso especial de transferência de arquivos, o correio eletrônico possui algumas características peculiares. Por exemplo, os agente finais que enviam e recebem mensagens finais são pessoas, não máquinas. Este fato levou a elaboração de um sistema com duas partes distintas: uma disponibilidade interface humana, ou seja, a composição e a edição da mensagem; outra voltada unicamente ao seu transporte. Outra diferença entre o correio eletrônico e transferência simples de arquivo é que as mensagens enviadas eletronicamente são documentos altamente estruturados. Na maioria dos sistemas, as mensagens possuem vários campos em adição ao seu conteúdo, que incluem a identificação do remetente, seu endereço, o nome e endereço do destinatário, a data de envio, etc. A partir dos anos 70 e inicio dos anos 80 a proliferação e penetração dos sistemas de correio eletrônico tem-se acelerado em, várias empresas, tanto no exterior como no Brasil. Hoje, milhões de pessoas usam a Internet e o sistema de correio eletrônico para transportar qualquer tipo de informação. Um dos usos mais significativos é a possibilidade de pessoas que não estão perto umas das outras poderem trabalhar juntas em um projeto. De fato isso já é bastante comum.
Simples Mail Transfer Protocol (SMTP)
A Internet agrega uma grande quantidade de computadores de diferentes fabricantes e com diferentes sistemas operacionais. Por isso, engenheiros e técnicos se viram obrigados a desenvolver um conjunto de regras padrão para a troca de mensagens, sem as quais usuários de um determinado sistema não poderiam se comunicar com os de outro. Nasceu então o Simples Mail Transfer Protocol, que faz parte da família de protocolos TCP/IP. Com o objetivo de permitir a comunicação entre usuários através do SMTP, um conjunto de tarefas deve ser executado para garantir o sucesso na troca de mensagens. No sistema transmissor, o usuário prepara uma mensagem - através de um editor independente ou mesmo no editor pelo serviço de correio eletrônico - e a envia a outro usuário. O destinatário recebe as mensagens, as quais são armazenadas em um arquivo e disponibilizadas para serem lidas, impressas ou até, mesmo removidas. Quando uma mensagem é transmitida entre dois sistemas, o emissor e o destinatário são identificados através de uma cadeia de caracteres, com o seguinte formato: usuario@dominio, onde o domínio identifica uma organização ou host que envia ou recebe uma mensagem. Por exemplo, luiz@if.usp.br identifica o usuário Luiz no domínio if.usp.br. Quando recebemos as mensagens, o sistema de correio eletrônico nos apresenta uma lista de cabeçalhos contendo a data, remetente, tamanho da mensagem e assunto. Por este cabeçalho ficamos sabendo quando recebemos, quem enviou, o tamanho da mensagem.
O ato de enviar uma mensagem, uma simples colocação em uma caixa postal é, na realidade, uma entidade associada a um único usuário e administração pelos sistemas de arquivos consistindo em um diretório. Pode estar localizada em um mesmo host ou em hosts da rede. O objetivo do SMTP e transferir a mensagem com eficiência e segurança entre dois hosts, independentemente do subsistema de transmissão. Para assegurar o sucesso desta transferência, o SMTP utiliza os seguintes componentes:
Inicialmente, o módulo Sender-SMTP solicita o estabelecimento de um canal de transmissão bidirecional com o módulo Receiver-SMTP. O canal de transmissão do SMTP corresponde a uma conexão TCP, que utiliza-se da porta 25 do destinatário e de uma porta qualquer no originador. Se o pedido de conexão for aceito, o destinatário retorna a resposta com código 220, indicando que o serviço está pronto. Caso seja retornada uma resposta com código 421, o serviço está indisponível. Uma vez estabelecida a conexão TCP com sucesso, o Sender-SMTP envia o comando "HELO", que permite sua identificação junto ao Receiver-SMTP . Se este retorna uma resposta "OK". Então, o Sender-SMTP prossegue enviando o comando "MAIL", que indica o originador da mensagem. Se o Receiver-SMTP estiver disponível, ele emite uma resposta "OK". Então, o Sender-SMTP envia uma comando "RCPT", identificando o destinatário. Se o Receiver-SMTP estiver mais uma vez disponível, envia um "OK". Caso contrario, envia uma resposta de "rejeição" relativa ao destinatário (não à mensagem). O Sender-SMTP e o Receiver-SMTP podem negociar diversos destinatários. Em seguida, o Sender-SMTP envia a mensagem de "DATA", que pode ou não ser aceita pelo Receiver-SMTP, se processar com sucesso a mensagem recebida, ele responde com "OK". Como pode se observar, o diálogo no SMTP é internamente passo a passo, ou seja, cada comando é executado de cada vez. Terminadas as transações em um dado canal de comunicação, o Sender-SMTP deve enviar um comando "QUIT". Assim que for recebida a resposta "OK", para este comando, a conexão TCP pode ser liberada. O SMTP trata de erros referentes a host não-acessível, host fora da operação e endereço inválido do destinatário. Nos três primeiros casos, o SMTP recoloca a mensagem em fila de submissão e a mantém por um tempo determinado para posterior entrega. Se há problemas no endereço do destinatário, o SMTP tenta passar o seu e-mail de volta com a devida notificação de erro. Já quando a mensagem e transmitida com sucesso, o SMTP a coloca na caixa postal do destinatário ou as copia para uma fila de submissão, quando for necessário o reencaminhamento. Nesta fase em especial ele trata de erros referentes ao esgotamento da capacidade de armazenamento em disco. Enviando e recebendo mensagens com o usuário, você não interage com o agente transportador de seu sistema; ele opera diretamente, enviando e recebendo mensagens pelo SMTP. O componente do SMTP com o qual você interage é agente de usuário, que age como sua interface com o sistema de correio Internet, permitindo que você leia mensagens, apague as que já foram lidas e assim por diante. Há muitos tipos de agentes de usuários na Internet. Qual deles você usará para compor e ler suas mensagens, depende de qual está disponível em seu sistema.
Uma lista de discussão, também chamada de Mailing List, é uma lista de endereços eletrônicos de pessoas que se interessam por um determinado assunto.
Existem mais de 3500 listas, cobrindo praticamente qualquer assunto que você possa imaginar (de autismo até degustação de vinhos). As listas são muito úteis para obter informações atualizadas, solicitar ajuda para resolução de problemas (principalmente na área de informática), manter contato com colegas da mesma área, etc. Toda lista possui o seu próprio endereço eletrônico.
Quando uma mensagem é enviada para o endereço de uma lista, esta mensagem é repassada para todos os assinantes da lista, que quase sempre acabam respondendo a mensagem. O resultado deste processo é uma conversação.
Listas diferentes possuem estilos diferentes. Algumas são bem formais, tratando sempre do assunto para o qual ela foi criada. Já outras são bastante informais. Permitem que diversos tipos de assuntos sejam abordados.
Existem dois tipos listas:
Transferência de arquivo significa copiar arquivos de um computador para outro. Através deste processo, você pode copiar arquivos de outro computador para seu computador e do seu computador para o outro.
O FTP é o principal método de transferência de arquivos na Internet. Em princípio, a transferência de arquivos entre dois computadores, pressupõe que você tenha permissão de acesso nos dois sistemas. No entanto, existe uma forma de contornar esta restrição. Através do uso do serviço de FTP anônimo, você poderá ter acesso a um número muito grande de computadores da Internet que possuem arquivos disponíveis para o público. E sem custo! Documentos históricos, obras literárias que não são mais protegidas pelo direito autoral, poemas, imagens gráficas, programas de domínio público e muitas outras informações úteis podem ser encontradas nos locais que permitem FTP anônimo.
O FTP é usado, geralmente, quando você possui três informações:
Utilize ferramentas de procura de informações na Internet como, por exemplo, o Archie.
No caso de você não ter acesso direto a Internet, ou seja, a sua única forma de contato com ela é via correio eletrônico, não se desespere! Existe a possibilidade de fazer FTP via Correio Eletrônico.
Importante: é altamente recomendado que as sessões de FTP sejam realizadas fora do horário de expediente da organização que irá ser acessada. Desta forma, evitamos que esta máquina fique sobrecarregada a ponto de prejudicar os usuários diretos dela.Não esqueça das diferenças de fuso horário !
Telnet e finger são dois serviços que vem com a maioria dos sistema operacionais, então eles são largamente usados embora sejam razoavelmente primitivos.
O telnet é um serviço que permite ao usuário conectar-se a um computador remoto interligado à rede. Uma vez feita a conexão, o usuário pode executar comandos e usar recursos do computador remoto como se seu computador fosse um terminal daquela máquina que está distante.
O finger foi projetado para prover informação sobre os usuários de sistemas remotos (como o nome completo correspondente a um endereço de email de um usuário).
Gopher é uma ferramenta de busca de informação em redes, que permite ao usuário navegar, facilmente, através da complexidade da Internet.
Ele foi desenvolvido, no inicio da década de 90, pela Universidade de Minnesota (EUA) a fim de prover seu corpo docente e discente de um sistema de informação interno flexível, que pudesse ser atualizado pelos diversos detentores da informação. Isto criou um sistema distribuído de envio de documentos, pois as informações não ficavam todas armazenadas em uma única máquina. Durante os últimos dois anos, esta aplicação desenvolveu-se e passou a ser utilizada por diversas instituições. O resultado foi um conjunto de milhares de servidores internacionais de informação, onde cada um pode ser acessado via o outro de uma maneira simples, através de uma interface de menus.Seu nome é derivado do fato da Universidade possuir um "gopher" (marmota) como mascote do seu time de futebol; unindo-se assim este símbolo ao conceito de túneis intercomunicantes, característica essencial da ferramenta.
As informações e serviços disponíveis no servidor são apresentadas ao usuário em forma de menus estruturados hierarquicamente. Podemos utilizar a metáfora de uma bacia hidrográfica, onde temos um rio principal do qual partem os afluentes secundários, e destes partem outros afluentes e assim vai. Seguindo nesta linha, dizemos que o gopher permite ao usuário navegar pela Internet, a fim de encontrar a informação desejada.
Sua utilização é simples, até mesmo, para usuários principiantes, permitindo o acesso rápido à informação em diversos servidores, integrando diversos serviços (acesso remoto, transferência de arquivos ...) e demais ferramentas (WAIS, Archie...)As informações, podem ser de diversos tipos: texto, executáveis, imagens, sons gráficos etc., e podem estar agrupadas, inicialmente, dependendo do servidor por:
Até muito pouco tempo navegar pela Internet, utilizando todos recursos e ferramentas, era um obstáculo para qualquer leigo. Entre estes obstáculos pode-se citar: comandos difíceis; sistemas operacionais diferentes: macetes não populares; desconhecimento na busca de informações, de endereços de máquinas e de pessoas na rede. Estas tarefas eram um sacrifício para a maioria e representavam a desistência para muitos.
Com o surgimento, em 1993 World Wide Web (WWW, ou Web. ou teia mundial, ou cyberweb etc), o padrão gráfico da Internet, tudo mudou. Agora, num mesmo software de navegação pela rede (browser) disponibiliza-se texto, imagens e sons. É a rede em padrão multimídia, ou hipermídia, como é conhecida.
O World Wide Web é um sistema de informação distribuídas, baseado em hipermídia, criado por iniciativa de pesquisadores do CERN, na suíça e implementado no NCSA, nos EUA. O acesso as informações é feito de modo que o usuário não precise saber de onde a informação esta sendo buscada, podendo estar em qualquer ponto do mundo. Para acessar a "teia" é necessário um programa chamado (browser). O Browser lê e apresenta documentos e pode acessar documentos de outras fontes.
A vantagem do hipertexto é que em documento, se você quer mais informação sobre um assunto particular mencionado, você pode geralmente "clicar" sobre ele para ler mais detalhes. Na verdade, documentos podem ser, e freqüentemente são linkados com outros documentos por autores completamente diferentes - assim como fazendo anotações nos rodapés.
WAIS (Wide Area Information Service)
Enquanto Gopher e WWW são basicamente interfaces do usuário para navegar por dados e ter o mínimo de capacidade de busca, WAIS é para procurar dados, com o mínimo suporte para navegar. Gopher e WWW assumem que os usuários sabem onde procurar, enquanto o WAIS não. Em outras palavras, um servidor WAIS é um bom complemento para um servidor Web ou Gopher.
A busca WAIS usualmente começa no Diretório dos servidores, nos quais contêm um índice de todos os outros servidores. Então a busca real começa com o servidor mais apropriado.
WAIS procura os documentos em lista de servidores por uma ou mais palavras chaves e retorna um marca para cada documento.
WAIS trabalha indexando arquivos para que ele possa ser encontrado rapidamente quando os usuários enviam uma consulta. O software dos índices acomoda muitos tipos de dados, incluindo textos ASCII, LaTeX, PostScript, arquivos GIF ou TIFF etc. Se o tipo de dado que você quer tornar disponível não é já suportado, é relativamente fácil adicionar suporte para ele.
A maioria dos clientes WAIS provêem visualizadores para alguns formatos de documentos básicos WAIS e permite os usuários ou administradores especificarem programas externos para processar e apresentar os tipos de dados mais complicados.
Um problema com o WAIS é que seus índices de bancos de dados são grandes. Quando o WAIS tem o luxo de trabalhar com documentos baseados em texto, os índices de texto completo são construídos, podendo ser bastante grandes ou maior que os dados dele mesmo! Com grande coleções de arquivos texto, isto pode significar que você pagará um prêmio em espaço de disco para executar o WAIS.
Existe uma imensa gama de arquivos e softwares disponíveis em toda a rede e que provém informações nas mais diversas áreas. Archie é o recurso na Internet que permite descobrir exatamente onde estão localizados estes arquivos e programas.
O Archie é um grande compilador de listas de nomes de arquivos disponíveis em áreas de ftp anônimo. Suas bases de dados de uso público são mantidas em mais de 30 diferentes locais. O Archie foi originalmente desenvolvido na McGill University em Montreal e agora está sendo distribuído pela Bunyip Information Systems.
Ao fazer uma busca através de um servidor Archie, você estará solicitando a este servidor que procure em sua base de dados arquivos com uma expressão ou palavra. Este servidor responderá com uma lista de arquivos e diretórios que contenham essa expressão/palavra, informando também onde eles estão localizados e demais detalhes para uma transferência.
O Archie é particularmente útil para se encontrar softwares de acesso público disponíveis em rede e pode ser acessado de várias formas.
Requisitos do Sistema e da Rede
Se você está tornando informação disponível para a comunidade Internet via um servidor ligado em um de seus computadores, isto obviamente adicionará a rede tráfego de entrada e saída em seu computador, a carga imposta em seu processador, e o espaço de disco usado. Quanto ele adiciona depende não apenas dos tipos de serviços que você oferece, mas também em sua popularidade.
Logo que você pegar algum dado no horário de pico e no crescimento da demanda, é importante que você planeje antecipadamente as necessidade futuras.
Para prover um serviço Internet, você precisará de uma conexão Internet de tempo integral. A única questão é qual a velocidade. Para muito limitado serviço usando Gopher, Telnet, Finger ou WAIS, você poderia iniciar com uma conexão PPP de 28.8 kbaud, o qual requer apenas um modem padrão e uma linha telefônica. Mas para a maioria dos serviços, uma linha de 56 Kbaud é o mínimo. Para uma série de serviços, você desejará uma conexão rápida.
Há duas fontes de tráfego de servidores de informação: consultas enviadas para o servidor e as respostas dele enviadas como retorno. Você precisa medir ambos para determinar a carga que seu serviço põe na sua rede.
Em geral, consultas são usualmente pequenas, enquanto o retorno da resposta faz o volume do tráfego crescer a menos que você sirva poucos bits de informação. A demanda terá, é claro, picos em certos momentos.
Resolver quão potente computacionalmente um dado servidor será é muito importante.
Os próprios servidores de lista de mails são o mínimo de uso da CPU. Eles executam relativamente operações simples em seus arquivos aliases e não geram muito tráfego na rede. Mas o uso de listas de mails que são gerenciados pelo servidor pode ser muito intensivo para a CPU, dependendo do tamanho da lista de mail e do tamanho da mensagem para ser enviada. sendmail, o programa que libera mails na maioria dos sistemas UNIX, não é projetado para o envio eficiente de milhões de mensagens ao mesmo tempo, como pode ocorrer quando uma mensagem pode ser enviada para uma lista imensa.
Servidores de arquivo baseado em mail podem também gastar muito tempo de CPU executando transferências para usuários, processando os arquivos transferidos, e então enviando o mail destes arquivos.
Servidores FTP, Gopher e WWW consomem CPU na proporção do número de consultas que eles recebem e o tamanho dos arquivos que eles processam. Servidores do popular FTP são notórios por atolar processadores.
Servidores Web estão tendo bastante demanda simplesmente por causa do uso de imagens que torna grande o tamanho médio de um documento. Servidores WAIS são computacionalmente os que mais exigem dos servidores. Para manipular uma requisição de busca, um servidor WAIS deve abrir arquivos de índices, computar marcas (quando um dado documento parte o critério de busca), e executar outra tarefa não-trivial . Consequentemente, a carga por consulta em um servidor WAIS põe em alta o seu host servidor. Se não há mecanismos em WAIS para controlar o acesso ao seu servidor baseada na carga do sistema, você precisará de um rápido processador para servir um grande banco de dados WAIS.
É importante monitorar a carga média no horário de pico quando seu servidor crescer em popularidade, então você pode prever o que é necessário para a máquina ficar mais rápida.
Cada informação do servidor requer pelo menos bastante espaço de disco para acomodar todos os arquivos que você estará oferecendo (isto é, os conteúdos de seus arquivos FTP, ou os arquivos em sues bancos de dados WAIS).
De todos os serviços, apenas os servidores de mail e WAIS usualmente requerem um substancial espaço extra de disco. Como nós mencionamos anteriormente WAIS indexa arquivos de bancos de dados textual que podem ser iguais no tamanho, então você deve planejar ter um servidor WAIS que consome duas vezes o espaço de disco de seu conjunto de dados. Quando um email é enfileirado, ambos, lista de mails e servidores de arquivos baseados em mail, podem consumir uma razoável quantidade de espaço, desde que os cabeçalhos e corpos das mensagens de mail desejadas terminem em seu sistema de diretório da fila de mail. Isto é mais significante com servidores de arquivos baseados em mail, porque eles são mais prováveis de transmitir grandes mensagens de mails.
Os outros serviços tipicamente precisam de alguns arquivos de configuração, arquivos README, e podem ser um índice ou dois. Gopher, por exemplo, precisa de arquivos de índice em diretórios para dizer a ele qual menu de escolha oferecer. FTP também requer alguns conjuntos de programas aparte para usuários anônimos listarem arquivos, enfim. Mas basicamente, estes serviços não querem oferecer um consumo acima de um megabyte.
Para executar alguns dos serviços seguramente, entretanto, pode requerer que você tenha uma cópia separada dos dados que você está oferecendo para cada serviço, então cada servidor é restrito a sua própria cópia. Em outra palavras, se você executa Gopher, Web e servidores FTP, você pode precisar de três cópias para o mesmo dado.
Para executar um serviço de informação requer um entendimento do material deixado disponível pelo servidor, e um conhecimento de como estruturar este material intuitivamente e eficientemente. Também demanda dedicação e atualização constante da informação, para adicionar nova informação, e para checar a integridade dos links de seu servidor para outros servidores.
Muitos dos servidores de informação na Internet hoje em dia são executados pelas mesmas pessoas que compilam e instalam o servidor. Isto não é necessariamente uma má coisa. Algumas vezes, no entanto, há uma necessidade real de apontar um "zelador" para os dados em adição para (e separado de) alguém para gerenciar o servidor. Este "bibliotecário dos dados" é responsável pela estrutura e conteúdo dos dados servidos, mas não a operação do servidor. Os deveres do bibliotecário podem ser:
World Wide Web (ou simplesmente Web) é o maior serviço gráfico da Internet, e tem a mais poderosa habilidade de ligação com outros serviços de informação. Essas características tem feito da Web o serviço de informação Internet de maior crescimento.
A Web permite documentos com palavra, figuras, ou pontos, para outra mídia tais como, documentos com frases, clips se movendo ou arquivos de som. A Web pode ligar de algum ponto no documento ou na imagem para um outro ponto qualquer em outro documento.
Com um browser que tem uma Graphical User Interface (GUI) os links são seguidos pelo click do mouse. Essas versões baseadas em GUI são provavelmente o mais fácil de todos os serviços Internet para usar e divertir, porque eles podem misturar figuras e textos.
A Web foi inicialmente desenvolvida no CERN, uma parte no laboratório de física em Geneva, Switzerland. Inicialmente o trabalho focou a definição do protocolo cliente/servidor HTTP, o desenvolvimento do modelo servidor e uma biblioteca de programas chamada wwwlib.
Propósitos:
Um hyperlinking pode ser visto como um conjunto de links que podem levar para documentos diferentes e estes podem se encontrar em documentos espalhados pela Web. O processo de navegação, ou seja seguir hiperlinks do documento às vezes é chamado de surfing. O poder da Web, difere de outros ambientes é que hyperlinks podem navegar para documentos para outros documentos no mesmo diretório, em outro no mesmo servidor ou em outro servidor ou outro tipo de servidor localizado em qualquer parte do mundo.
Com a Web, documentos textos de ASCII são desenvolvidos em uma linguagem chamada de HyperText Markup Language (HTML). Tais documentos são chamados de documentos HTML, e geralmente tem extensão .html. Documentos HTML podem ser manualmente escritos com seu editor de textos ASCII preferido, pode ser convertido por filtros de outros formatos, ou pode ser criado dinamicamente em run-time pelo servidor Web ou script. A linguagem HTML é usada para descrever a estrutura de documentos e informação de hyperlinking.
A HTML possui uma sintaxe própria. A versão HTML 2.0 é baseada em alguns conceitos de SGML (Standard Generalized Markup Language), que é padrão ISO usada para marcação de documentos tanto na impressão quanto na publicação online. A versão mais recente é HTML 3.0 que usa o SGML - Compliance.
Um hyperlink de um documento HTML é composto por:
A URL descreve o protocolo usado para procurar o servidor alvo, o sistema de host no qual o documento reside, o caminho para um documento. Um exemplo de URL seria:
http://www.di.ufpe.br/~usuário/indice.html
Essa URL significa que o protocolo HTTP procura um servidor chamado www.di.ufpe.br (usa a porta 80, por default) onde ~usuário contém o documento hypertext chamado indice.html. O conceito de URL suporta outros protocolos importantes, tais como: Telnet, Gopher, FTP.
A URL descrita anteriormente é chamada de URL absoluta, pois a mesma especifica como chegar ao arquivo desejado. Existe uma forma simplificada de URL, chamada URL relativa, é uma forma resumida de referenciar outros documentos localizados no mesmo servidor do documento corrente.
Esse esquema uniforme de nomeação de recursos é que faz a WWW um ambiente rico em informação. Tornando os browsers Web ferramentas de acesso Universal na Internet.
No ambiente cliente/servidor da Web, o controle encontra-se com o browser Web. A tarefa do browser Web é usar a URL inicial para recuperar um documento Web de um servidor, interpretar o HTML, e apresentar o documento para o usuário com os acessórios explicitamente para fornecer um ambiente gráfico que pode embelezar páginas HTML estendendo browser de ambientes baseados em caracteres.
Quando o usuário seleciona um link hipertexto, o processo começa novamente - o browser usa a URL associada ao link para solicitar o documento, espera pelo retorno e então processo e mostra um novo documento.
A figura 5.1 mostra o relacionamento entre o browser Web e outros servidores de informação Internet.
Muitos browsers Web fazem outras coisas úteis sob o documento corrente, tais como: salvá-lo em disco, enviá-lo em uma mensagem, direcioná-lo para impressão, exibir seu fonte HTML.
O software servidor usado com o WWW é referenciado como servidor Web. Ele observa a porta 80 por default. Quando um cliente pergunta por uma página especifica, o servidor pega a página e retorna-a para o cliente.
A figura 5.1 mostra, como servidores Web podem excutar scripts especiais que habilita-os para servir como gateways para outros recursos de informação no seu sistema ou na Internet. Muitos recusos desses scripts de gateway já estão disponíveis na Web. Pode-se instalá-los e padronizar para seu site. Também pode-se desenvolver gateways para acesso a sistemas de informação local que pode não ser diretamente acessível via TCP/IP.
Browsers Web e servidores Web comunicam-se através do HTTP (Hypertext Transfer Protocol). Todo pedido de documento vindo do browser Web para o servidor Web é feito por conexão.
A primeira implementação do HTTP é agora conhecido com HTTP 0.9. A descrição completa desse protocolo está em algumas páginas. No HTTP 0.9, um programa cliente faz uma conexão para o servidor na Porta TCP 80. O mesmo possui algumas limitações, tais como: a mensagem pedido cresce linha a linha, somente documentos do tipo texto são tratados e não existia formalização de um tipo de cliente para submeter informação para o servidor. O HTTP1.0 foi desenvolvido de 1992 a 1996. Ele apareceu em RFC recentemente em Maio de 1996. Desde a RFC 1945 que é somente uma RFC informal, não era especificado um padrão Internet. O HTTP 1.0 foi formalizado e provê referência a seu servidor. Apresenta as características de trocar mais que simples informações textuais. Ele tornou-se um caminho para construir um sistema de informação hipermídia distribuído adaptado para muitas necessidades e propósitos. Ainda nesta versão, não foi resolvido o problema de múltiplas conexões, que degrada o desempenho da rede, assim como não foi resolvido o que deve ou não ser guardado em cache. O HTTP 1.0 suporta outros tipos de dados entres cliente e servidor Web, pela adição de MIME (Multimidia Internet Mail Extensions) como informação de cabeçalho, para o protocolo HTTP usa o tipo MIME como: text/ html ou image/ gif . Para solucionar problemas encontrados na versão 1.0 foi desenvolvido o HTTP 1.1, que será detalhado no próximo item.
Operação Geral
HTTP é um tipo de protocolo request-response. Existem três formas de request-response na qual o HTTP opera. A primeira é quando um agente usuário faz um pedido diretamente para o servidor original como mostra a figura 5.2 . Neste cenário, o UA faz uma conexão diretamente para o servidor original na porta default (se não especificada, assume-se a porta 80) e envia seu pedido. O servidor ficará atento para as conexões que chegam e começa a nova ligação ou processo para servir a nova requisição. Uma vez que o pedido tenha sido processado, o servidor envia a resposta de volta par o solicitador.
A segunda forma envolve uma agente proxy ou cahe intermediário. Neste caso, o UA faz seu pedido para o proxy em vez de pedir ao servidor original, como ilustra a figura 5.3. O proxy então faz o pedido ao servidor original em nome do cliente. O servidor responde para o proxy e então o proxy retransmite para o UA.
O cenário final envolve um agente intermediário, agindo como um túnel. Um túnel esconde o funil do pedido e resposta entre duas aplicações HTTP.A figura 5.4 mostra o caminho percorrido na comunicação do agente usuário e o servidor.
A diferença entre o proxy e o tunnel é como ele opera. O tunnel é simplesmente uma via pela qual o UA envia o pedido e recebe resposta do servidor original. Ou seja ele é um agente passivo, enquanto o proxy é ativo e pode reescrever cabeçalhos ou solicitar autenticação para usuários antes de prover serviços.
HTTP 1.1
O HTTP 1.1 é compatível com as aplicações desenvolvidas no HTTP 1.0. Existem sete tópicos que serão aqui tratados como diferença entre essas duas versões do HTTP. São elas :
Novo método de pedido - a especificação do HTTP 1.1. tem definido dois novos métodos nos quais são altamente benéficos para usuários finais, são eles: PUT e DELETE. O método que PUT um agente usuário (UA) para pedir, um servidor aceita um recurso e armazene-o como pedido - URI dado pelo cliente. Este método permite um UA atualizar ou criar um novo recurso no servidor. O método DELETE é auto-explicado: o UA está solicitando que o request - URI seja removido do servidor. A especificação do protocolo permite que o servidor defira a deleção de um recurso para quando o pedido é recebido. Ele moverá o recurso para uma localização não acessível. Isto permite que um servidor salve recursos deletados para um local seguro para rever antes do final da deleção e deve ser provavelmente implementado neste caminho por qualquer servidor.
Conexões Persistentes - o browser Web começou fazendo múltiplas conexões para o servidor original na ordem de velocidade acima do tempo de resposta. O protocolo HTTP 1.1 implementa, como comportamento default, a prática de conexões persistentes. Isto significa que uma vez que o cliente e um servidor abrem uma conexão, a mesma permanece aberta até que um dos dois especifique o pedido de fechamento. Quando aberta a conexão, o cliente está livre para enviar múltiplos pedidos sem esperar resposta.
Chunked Encoding - usando chunked encoding, um servidor ou processo CGI (Commun Gateway Interface) pode ser enviado de volta a uma entidade de tamanho desconhecido inicialmente, pelo envio a volta trás um chunk de tamanho conhecido.
Como mostrado na figura 5.5, o servidor envia o tamanho do chunk aguardado, em bytes e então o verdadeiro chunk de dado. Isso se repete até que todos os dados sejam enviados. Uma vez que todos os dados são emitidos, o tamanho final enviado é zero, indicando fim dos dados. Com este método, fica fácil para um servidor enviar dinamicamente dados gerados e fácil para o cliente decodificá-los.
Operação Fila de Bytes - o uso de fila de bytes não está limitado a recuperação de transferência. Certamente clientes podem desejar um limite no número de bytes do download anterior para efetivar o pedido completo. Um cliente com limite, de memória, espaço em disco, ou tamanho da banda passante pode pedir os primeiros dos vários bytes do recurso. Servidores não são obrigados a implementar este método, no entanto ele é fortemente recomendado pelo protocolo.
Negociação Satisfatória - às vezes é necessário que um servidor tenha diferentes representações de um recurso simples para ter um serviço melhor para o cliente. A representação alternativa pode ser versão na língua nacional de uma página, por exemplo. Isto pode ocorrer através de : formulário de server-driven, agent-driven ou negociação transparente. A primeira forma , é desempenhada no servidor original, baseado em um pedido do cliente. O servidor verificará os vários Accept-* nos cabeçalhos, um cliente pode enviar e, usando esta informação e outras opcionais, enviar a melhor resposta para ocliente. A segunda forma do conteúdo de negociação é agent-driven. Neste o servidor prover para o UA informações necessárias para escolher a melhor representação do recurso. Isto pode vir em forma de uma opção Alternates do cabeçalho ou no corpo da entidade para a resposta inicial. A forma final é chamada de negociação transparente. Nela, há uma cache intermediária que provê negociação server-driven baseada em informação do agent-driven do servidor.
Autenticação Resumida - com autenticação resumida, a password é mantida como um segredo compartilhado entre cliente e servidor. O computador servidor e cliente computa um valor resumido usando o algoritmo MD5 (Message Digest 5) durante a concatenação da password secreta e algum outro valor. Este resumo é então enviado através da rede. Desde que o servidor e o cliente saibam a password secreta, o cliente pode computar o valor resumido, enviando-o para o servidor, e então o servidor pode verificá-lo. Algoritmos como POP3 e protocolo APOP será um bom método de autenticação.
Caching - este modelo no HTTP 1.1 permite ao servidor uma grande quantidade de controle acima da resposta de caching. Primeiro, a especificação faz limpar o que é cachable e o que não é, geralmente só resposta de GET e HEAD são guardadas. O protocolo usa cabeçalho cache-control para transmitir instruções de caching do servidor e cliente para caches.
Existem browsers WWW para toda plataforma, sistema operacional e GUI. Eles são classificados em duas categorias: orientado a linha e click (gráfico). Quando um documento HTML é autorizado, ele pode ser disponibilizado e visualizado com diferentes browsers. Seu documento HTML pode ser visualizado no Mosaic na versão para Macintosh, ou no Mosaic versão para Microsoft Windows.
Exemplos:
Lynx
Browser Web é baseado em caracter e foi desenvolvido na Universidade do Kansas. Ele tem característica completa de um Browser Web que é otimizado para ser exibido em dispositivo geralmente em terminal VT100 ou emulador. Suporta Bookmarks para guardar as URLs preferenciais.
Mosaic
Esse browser é bem conhecido, foi desenvolvido no National Center for Supercomputer Applications (NCSA) na Universidade de Illinois. O arquivo binário do mesmo está disponível gratuitamente para plaformas UNIX. Mosaic foi escrito para Xwindow System e OSF/Motif. Ele suporta gráficos inline e outros formatos com gif e XBM. tipos de arquivo que são incompatíveis com Mosaic são : MPEG, arquivos com som, documentos PostScripts e imagens JPEG.
Netscape
Esse cliente é distribuído pela Netscape Communications Corporation . Netscape permite você ver e manipular páginas Web tão logo seus conteúdos comecem a chegar, dessa forma é melhor que forçar você esperar até que cada transferência seja completada. Isso faz com que o Netscape aparente maior rapidez que o Mosaic, e ele trabalha bem especialmente sobre conexões lentas de rede, tais como linhas SLIP. O Netscape é um produto comercial , e você paga para obter uma licença de uso, embora haja versões de teste e algumas gratuitas.
NCSA
O servidor Web NCSA é um servidor Web de domínio público escrito em C e projetado para ser pequeno e rápido. A NCSA é compatível com browsers a partir do HTTP 1.0. Você pode padronizar seu servidor para executar buscas, trabalhar com padrão HTML, provê mapas de imagem ativa e controle de acesso de usuário. O servidor NCSA também tem suporte a comandos ou outros arquivos de seu documento HTML.
CERN
O servidor Web CERN é um servidor de hipertexto de domínio público também escrito em C. Este servidor suporta gráficos, imagens ativas, scripts executáveis, e a habilidade de introduzir utilitário de pesquisa via CGI e provê acesso autorizado.
HTML
HTML 3.0 oferece um ambiente rico para descrição de :
Permite identificar figuras e tem texto envolvido
Permite identificação de múltiplas-colunas, múltiplas-filas de tabelas com habilidade para misturar gráficos inline e texto na mesma tabela.
Permite inclusão de múltiplos buttons per form
Permite que criação de barras de navegação gráfica nos documentos
Permite validação de HTML usando ferramentas SGML
Ainda existe pouca proteção para operações de serviços na Web como as que trabalham com número de cartão de crédito, assinatura eletrônica e outras. Como solução para problemas de segurança está sendo desenvolvida uma especificação do Secure HTTP.
O Secure HTTP garantirá autenticidade de transações e a confidencialidade de informações trocadas via HTTP. Numa aplicação com Secure HTTP habilitado, um usuário pode fixar assinatura digital que não pode ser rejeitada, permitindo contratos digitais que são ligados legalmente e examinados. Já são utilizados criptografia com algoritmos eficientes de chaves públicas e outras variações, em informações críticas.
Instalando um Servidor Pré-Compilado
NCSA chama seu servidor Web de HTTPd (HTTP daemon). Os arquivos pré-compilados devem ser colocados no diretório /usr/local/src, e devem ser gerados os seguintes diretórios:
cgi-bin - deve conter um exemplo de scripts gateway e binário pré-compilado. O diretório é chamado de cgi-bin porque gateways usam uma interface padrão com o servidor Web chamado Common Gateway Interface (CGI).
conf - contém todos os arquivos de configuração usados para controlar operações no servidor Web
icons - esse diretório contém a classificação de todos os icons que são usados pelo diretório indexado
logs - deve conter os arquivos de log de acesso e de erro
support - nele estão programas que são usados para controle de acesso de diretório e acesso global
Recupere o fonte do HTTPd NCSA, e coloque-o no /usr/local/src e descompacte-o.
Após uncompress e untar do fonte , coloque-o no diretório chamado httpd_1.3, por exemplo. O fonte distribuído contém os mesmos diretórios já descritos na seção anterior, exceto para o diretório adicional src. Para construir o HTTP NCSA deve-se compilar dois módulos separados: um servidor httpd e outro os gateways. Primeiro trataremos o servidor httpd. Copie com outro nome o arquivo Makefile do diretório http_1.3/src, pois faremos alteração no mesmo.
Editando o Makefile, verifique se serão necessárias as seguintes alterações:
- Mude a variável cc para o nome do compilador usado pelo seu sistema
- Mude a variável CFLAGS caso queira usar flags diferentes para seu compilador
- Adicione algumas bibliotecas extra que são necessárias no seu sistema com a variável EXTRA_LIBS
Execute o comando make para que a compilação seja efetuada.
Configuração Específica do Site
Agora que já dispomos dos binários, precisamos configurar o servidor Web NCSA para satisfazer o ambiente do site. Isto é através da edição de três arquivos de configuração.
httpd.conf - arquivo de configuração principal do servidor
srm-conf - arquivo de configuração de recursos do servidor
access.conf - arquivo de controle de acesso global (ACF)
Os arquivos de configuração httpd.conf e srm.conf são os mais importantes. Também é importante configurar o access.conf para compatibilizar com as alterações do httpd.conf.
Existe também uma cópia do arquivo de configuração chamado mine.types que é usado para controlar o mapeamento do arquivo de extensão para dados do tipo MIME. Os três arquivos principais de configuração são descarregados dentro do diretório conf e são inicialmente encontrados com extensão .conf-dist. Eles devem ser deixados sem alteração e devem ser copiados com uma nova extensão .conf, por exemplo.
Alteração Básica do httpd.conf
O httpd.conf controla como o servidor executará, mas não trata detalhes relacionados a arquivos de serviços. Geralmente as seguintes alterações são necessárias:
- Modificar User e Group para o nome desejado
- Assegurar que os nomes relativos ao item acima se encontram no /etc/passwd e /etc/group
- Modificar o administrador do serviço para webmaster@seu_domínio
- Mude o ServerRoot a path absoluta referente ao diretório onde foi colocado o binário do httpd
- Especificar o nome do servidor para ser www.seu_domínio
- Trocar o ServerType se deseja executar o servidor pelo inetd
Alterações Básicas do srm.conf
Este arquivo configura onde o servidor do httpd encontra arquivos e scripts. Logo, deve-se informar o path absoluto da árvore de documentos (DocumentRoot), desabilitar o UserDir.
Alterações Básicas do access.conf
O arquivo global de controle de acesso controla que tipo de acesso os browsers Web tem ao servidor Web ou diretórios. Portanto, deve-se modificar:
- A primeira diretiva caso o diretório cgi-bin tem localização diferente
- A diretiva Options associada com o diretório cgi-bin para remover a opção Indexes
- A segunda diretiva para compatibilizar o DocumentRoot com o que foi setado no srm.conf
A diretiva AllOverride para None
Inicializando o Servidor Web no inetd
Caso tenha sido modificada a diretiva ServerType no arquivo de configuração httpd.conf, será necessário modificar o inetd para inicializar o httpdd o servidor Web. Passos:
- Editar o /etc/services para adiciionar a linha: http número_porta/tcp
Editar o /etc/inetd.conf para adicionar a linha: http stream tcp nowait nobody
/usr/local/etc/httpd/httpd httpd
- Reinicializar o inetd pela identificação do seu processo e usar o Kill -HUP para reinicializar
Interpretando uma URL, temos: http://nome_servidor (protocolo://nome do servidor)
Quando uma URL não está incluída na path do diretório ou um nome de arquivo, o servidor Web retorna o conteúdo do arquivo index.html no diretório raiz do servidor ou , se o arquivo não existe, automaticamente é gerado um arquivo contendo o equivalente a ls -1.
O servidor httpd translada URLs para diretórios real da seguinte forma:
- Olha o começo da path da URL de algum diretório virtual definido peli Alias ou ScriptAlias no srm.conf. Se ele encontrar, recoloca o diretório virtual no diretório real e processa o pedido. No diretório virtual tem-se árvores separadas para diferentes tipos de informações.
- Olha para o prefixo de /~nome_usuário na URL e, se encontrar, olha a especificação do subdiretório público HTML do usuário para o arquivo. Se o subdiretório especificado pelo usuário não existe, retorna uma mensagem de erro. Isto não ocorre se o UserDir está deasabilitado no srm.conf.
- Do contrário, ele insere no DocumentRoot o início da path e processa o pedido.
Deve-se testar também utilizando Telnet na porta 80 (default) para teste direto da instalação do servidor. Para isto deve-se usar as primitivas próprias do protocolo.
Exemplo: telnet www.di.ufpe.br 80
Delegando o Gerenciamento na Árvore de Documento
Se o servidor suporta diferentes organizações ou funções, então pode-se querer dar a cada subdiretório na árvore de documentos a permissão de que seus proprietário gerenciem. Pode-se controlar quais usuários no seu sistema local podem escrever e modificar diferentes seções na árvore de documentos usando arquivo padrão UNIX.
Este controle pode ser feito através da diretiva UserDir no arquivo de configuração srm.conf. Se UserDir é setado para public_html, que diz ao httpd o pedido de serviço a seguir:
http://nome_servidor/~nome_usuario/doc.html
remapeando-o para:
~nome_usuario/public_html/doc.html
onde: nome_usuario é a entrada referente ao usuário no /etc/passwd
Se a diretiva UserDir estiver desabilitada, então a URL acima somente é tratada se existe um diretório chamado ~nome_usuario no DocumentRoot.
Convenções para Acesso Público
Existem várias convenções que se pode seguir para setar o servidor Web para acesso público. Uma delas envolve o nome do servidor que já foi setado. Embora o nome do servidor seja por default o mesmo nome do seu sistema, isto não é recomendado. A convenção Web é que o nome do servidor deve iniciar com www. Sendo assim, se a host é recife.di.ufpe.br será www.di.ufpe.br. Deve-se ter um CNAME no registro alias que mapeia o nome do servidor Web para um nome do sistema. Este dá a flexibilidade para mover seu servidor Web entre várias máquinas no sistema.
Há duas coisas para serem feitas periodicamente, uma é a atualização do HTML e outra é a modificação nos arquivos de log.
Não existe necessidade de parar ou reinicializar o servidor httpd, quando for atualizar os documentos HTML na árvore de documentos. Algumas pessoas editam o documento HTML enquanto o servidor está acessando-o online na Internet.
Gerenciando os Arquivos de Log
Os arquivos de Log crescem muito e não fica fácil analisá-los. Portanto, se a manutenção fosse automática teríamos ganho significativo na administração e manutenção dos mesmos.
Se está sendo executado o httpd sob o inetd, para automatizar este processo deve-se mover os arquivos de log sem afetar o servidor. O próximo pedido do cliente abre um novo TransferLog. No caso de usar o httpd standalone, o httpd daemon abre os arquivos de log uma vez que ele inicia, só há fechamento se o processo do httpd for morto. Mudar um dos arquivos de log, segue-se os passos são requeridos:
- Mover o arquivo de log para um novo nome. O servidor httpd continuará a escrever no mesmo arquivo de log, agora através do novo nome
- Reinicializar o servidor httpd standalone
Repositório de Documentos e Servidores
O script Perl (htget) HTML é um script não-interativo do servidor Web. Pode-se utilizá-lo para conseguir documentos simples ou duplicar parte ou toda a árvore de diretório. htget tem várias opções, as mudanças que devem ser feitas são as seguintes:
- htget copia o arquivo HTML especificada no diretório corrente
- A opção -s escreve no arquivo padrão de saída
- A opção -abs converte todas as URLs relativas em URLs absolutas. Em caso de recuperação de um simples arquivo que tem um link relativo, esta opção faz com que possa acessar todos os links por sua cópia local
- Finalmente, a opção -r copia recursivamente, cria subdiretórios abaixo do diretório corrente, e também recupera gráficos e outros arquivos
Existe dois arquivos de Log no servidor Web, o log de erro e o Log Transfer. Por default eles estão no logs/erro_log e logs/access_log no diretório raiz do servidor. Pode-se mudar a localização de nome de arquivo com as diretivas no httpd.conf. Formalmente, o formato do arquivo de log para acesso e:
host rfc931 authuser data_time request status bytes
onde:
host = hostname
RFC931 = protocolo da RFC931 comunica-se com RFC931-Compliant daemon no sistema executando o browser Web para determinar o nome do usuário executando o browser Web. O IdentityCheck por default está desabilitado
authuser = HTTP autenticou o usuário, ou não. Normalmente, o diretório que contém o arquivo acessado é protegido com do usuário
data_time = hora , data e local do pedido
request = pedido enviado pelo cliente
status = código de status da transição
bytes = número de bytes enviado na transação
Existem algumas ferramentas para ajudar na análise dos arquivos de Log. Tais como: getstats (análise estatística de acesso a páginas, domínio, diretório), wwwstat (faz análise sem ter privilégios de root) e uusage (análise estatística em gráficos).
Uma documento HTML é um arquivo texto ASCII que contém recursos HTML embutidos. Geralmente, os recursos HTML são usados para identificar a estrutura de do documento e são identificados por hiperlinks e suas URLs associada. HTML além de identificar a estrutura do documento e sugere o layout do documento.
Utilizando HTML pode-se identificar:
Da mesma forma que o documento é escrito de forma diferente, é lido de forma também diferente da tradicional. Em um texto comum, o leitor passa as páginas e o lê da mesma forma que o autor o escreveu, na mesma sequência. Com um documento em HTML, o autor rotula o texto com sua funcionalidade e o leitor interpreta estas funções. O leitor precisa usar um programa "cliente" que apresenta o documento na sua tela. A forma na qual o documento se apresenta pode variar muito, dependendo do programa no qual o documento é visualizado e da forma que este está setado. Mas isto não significa que o autor não sabe como o texto irá ficar, há marcações padrões
Diferenças entre HTML e Outros Formatos
As ferramentas usadas para escrever um documento em HTML são totalmente diferentes das usadas para um documento "normal". Em vez de decidir como cada parte do documento irá se apresentar, o autor decide que tipo de texto esta parte é. Então, em vez de gastar muito esforço para fazer o documento aparecer da forma correta em um único visualizador, o autor precisa fazer o documento aparecer de forma aceitável em uma série de diferentes visualizadores.
Apesar das diferenças, há algumas importantes similaridades. Processadores de texto usam rótulos como "comece texto em itálico" e "texto em itálico acaba aqui". Alguns processadores mostram esses rótulos (ex. WordPerfect), outros escondem (ex. Microsoft Word), porém, esses rótulos sempre estão lá, escondidos ou não. Em HTML, esses rótulos são totalmente explícitos; eles são simplesmente texto entre sinais de menor e maior, como: <um comando HTML>.
HTML-(Hypertext Markup Language) é usada para autoria e formatação de hipertextos para a Web, desta forma, apresenta uma sintaxe específica para tal. Alguns fatores consagraram HTML como a linguagem de autoria de hipertexto mais utilizada, como facilidade de construção de documentos, independente de plataforma, alta aplicabilidade possibilitada pela Web, flexibilidade, alto nível de abstração, entre outros. Na própria Web existem vários documentos para o iniciante em HTML que descrevem vários aspectos da linguagem. Há, também, documentos sobre características mais detalhadas da linguagem, como em HTML Documentation. Ou, ainda, a especificação oficial de HTML.
Diferentes Versões
Aversão mais recente, HTML3.0, é um conjunto de extensões para o formato HTML. Como HTML2.0, ela é baseada em SGML. As principais inovações são fill-out forms, tables, equações matemáticas e características para maior controle de layout. Fill-out forms podem incluir uma série de controles de entrada como checkboxes, radio buttons, entre outros.
Dentre as variações de HTML, uma é a mais promissora VRML1.0. VRML (Virtual Reality Modeling Language) foi idealizada para modelar um mundo virtual, o desafio era representar uma figura numa janela como na realidade, com sons e animações. Formalmente definindo-a, ela é uma tentativa de estender dentro da Web o domínio de gráficos tridimensionais. Ou seja, com VRML a Web ganha dados 3D e amplia consideravelmente as suas possibilidades de criação e formatação de textos.
CGI - Common Gateway Interface
CGI é um padrão para interface de aplicações externas com servidores de informação, tais como HTTP ou servidores Web. Um documento HTML que o daemon Web recupera é estático, o que significa que em estado constante o arquivo não muda. Um programa CGI, por outro lado, é executado em tempo-real, então ele pode gerar informação dinâmica.
A figura 8.1 ilustra como flui a informação básica através do CGI, o servidor Web, e o cliente. Quando o usuário entra com o texto ou responde uma query, o browser Web captura a chave do usuário para o servidor HTTP. O servidor HTTP aceita a entrada, inicializa o gateway e controla a entrada para o gateway via CGI. As chaves do usuário (Keystrokes) são passadas para o gateway via variáveis de ambiente (GET method) ou usando a entrada padrão (POST method). O gateway então analisa a entrada e processá-la. Ele pode gerar uma saída HTML, que é retorna para o servidor HTTP para passar para o cliente, ou ele pode salvar dados em arquivo ou banco de dados ou enviar email para alguém.
Um programa CGI é executável, ele é basicamente o equivalente a executar um programa em seu sistema, o que não é a coisa segura para fazer. Portanto, existem algumas precauções de segurança que precisam ser implementadas quando ele vai usar programas CGI. Provavelmente o único que afetará o usuário Web típico é o fato que programas CGI precisam residir em um diretório especial, assim que o servidor Web saiba executar o programa antes que apenas mostrá-lo no browser Web. Este diretório é frequentemente abaixo do controle direto do webmaster, proibindo o usuário regular de criar programas CGI. Existem outros caminhos para permitir acesso a scripts CGI, mas tudo é controlado por seu webmaster.
Se estamos usando a versão do servidor HTTP NCSA, então existirá um diretório chamado /cgi-bin. Este é um diretório especial onde todos os seus programas CGI residem. Um programa CGI pode ser escrito em qualquer linguagem que permita ser executado no sistema, tais como:
Documentos retornados por gateways CGI podem conter URLs absolutas para hiperlinks. URLs relativas não são trabalhadas, porque não existe "documento corrente" no qual atenda o método de acesso e nome de servidor.
Caso queira usar URLs relativas, use explicitamente <BASE> HTML, indicando a URL base do documento HTML (URL relativa).
Adicionando Diretórios cgi-bin
Scripts gateway são geralmente mantidos no cgi-bin, o diretório CGI binário no seu diretório ServerRoot. Se você planeja ter dúzias de gateways em uso desenvolvidos por pessoas diferentes, você pode querer dar a cada pessoa diretório cgi-bin separado de sua área da árvore de documento. Se isto for feito, modifique o arquivo de configuração, adicione a diretiva ScriptAlias para cada novo diretório cgi-bin acrescente-as no servidor Web. Por exemplo, para suportar três diretórios cgi-bin no servidor Web, as seguintes entradas devem ser acrescidas no srm.conf:
ScriptsAlias /cgi-bin /usr/local/etc/httpd/cgi-bin/
ScriptsAlias /cs-cgi-bin /cs/httpd/cgi-bin
ScriptsAlias /ee-cgi-bin /ee/web/scripts
Forms são uma progressão natural de consultas simples. Por exemplo, deseja-se coletar um string de pesquisa fornecido pelo usuário, qual a forma de apresentação mais adequada para se obter esta resposta -> Forms é uma boa solução.
Forms fazem parte do HTML 3.0, mas o servidor Web NCSA provê suporte para forms. Mosaic NCSA, Lynx e Nescape suportam um subconjunto de propósito geral desta funcionalidade. Funcionalidade suficiente para fazer forms prático e útil, ainda oferece um ambiente familiar para coletar dados dos usuários.
Existem quatro formas diferentes que permite o usuário acessar WAIS via WWW:
Comparação entre WWW, GOPHER e WAIS
Todos os três sistemas de informação são baseados no modelo cliente/servidor, eles diferem em termos de seus modelos de dados. No GOPHER, o dado é um menu, um documento, um índice ou uma conexão telnet.No WAIS, tudo é índice e tudo que é retornado do índice é documento. No WWW tudo é documento hipertexto que pode ser pesquisado.
Na prática, isto significa que WWW pode representar o GOPHER (um menu é uma lista de links, um documento GOPHER é um documento hipertexto sem links, sessões Telnet e Index são os mesmos) e WAIS (um índice WAIS é uma página procurável, retornando um documento sem link) modelos de dados bem como prover funcionalidades extras.
WWW atingiu uso crescente muito além do uso do GOPHER nos últimos meses, conforme as estatísticas mantida pelo backbone Internet (claro que, os browsers WWW podem acessar também servidores GOPHER).
Web : Controle de Acesso e Segurança
Controle de Acesso e Autenticação de Usuário
O acesso pode ser controlado usando dois métodos independentes:
Arquivos de Controle de Acesso
Controle de acesso e autenticação de usuário pode ser montado na base do servidor ou na base de diretório -por- diretório:
Pode-se permitir ou negar acesso de usuários para seu servidor Web baseado no endereço de domínio Internet. Esse mecanismo permite que haja controle através de uma organização ou departamento sem considerar nomes de usuários específico. Controle de Acesso Domain-Level e é feito totalmente pelo administrador.
Diretiva de Controle de Domínio
Arquivos de Controle de Acesso são dividido pelo diretório com a diretiva <Directory>. Com uma parte de diretório, as diretivas de controle de acesso são colocados com uma seção <Limit>
Diretivas:
order - define a regra de quais diretivas de deny e a allow, são avaliadas com uma section Limit
allow - define quais hosts podem acessar o diretório
deny - define quais hosts são privadas de acessar o diretório
Com autenticação de usuário, podemos permitir ou negar acessos individuais para o servidor Web ou árvore de diretório de documentos na base de nome de usuários e passwd. Não existe correspondência entre seu nível de sistema usernames/password (no /etc/passwd) e o arquivo username/password do sistema Web.
Quando o usuário acessa páginas que são protegidas com este mecanismo, são liberados dois prompts(username e password) para os quais eles devem responder corretamente antes do acesso página por página sem repetir prompts de autenticação. Isto porque o browser Web sabe o hostname, path do diretório e o nome/password para recuperação subsequente. O mesmo par nome/password é usado a qualquer hora que o browser Web acesse uma URL com o mesmo hostname e path do diretório.
Autenticação de usuário requer cooperação entre um o browser Web e seu servidor Web. Se o browser Web não suporta autenticação de usuário, usuários não podem ser autenticados.
Para usar autenticação de usuário, temos que manipular um arquivo chamado .htpasswd. Para isso, deve-se chamar o programa de mesmo nome, este não está incluído com o conjunto de arquivos pré-compilados, logo precisamos conseguir o fonte e compilá-lo. O fonte é o htpasswd.c e é encontrado no subdiretório de suporte.
Autenticação Individual
Autenticação individual é feita usando-se a combinação de diretivas de controle de acesso e o arquivo pessoal .htpasswd. Assumindo-se que está sendo usado o DocumentRoot default, apenas deve-se modificar o arquivo de configuração, como é exemplificado a seguir.
<Directory /usr/local/etc/httpd/htdocs>
options Indexes FollowSymlinks
AllowOverride None
AuthUserFile /usr/local/httpd/conf/.htpasswd
AuthGroupFile /dev/null
AuthName By Secret Password Only!
AuthType Basic
<Limit GET>
require user username
</Limit>
</Directory>
Depois cria-se uma hipertexto do arquivo password para nome do usuário especificado no seu arquivo de configuração access.conf. Exemplo: % htpassword -c /usr/local/etc/httpd/conf/.htpasswd nome_usuário.
Autenticação de Grupo
Na adição de autorização para usuário individualmente, também podemos colocá-lo dentro de um grupo ou tratar cada grupo como um todo. Para isso é necessário:
Quando configurar controle de acesso para seu servidor Web, tem-se que decidir a quem dá permissões e quais níveis de restrições devem ser aplicados a cada usuário, logo deve-se garantir que não será dado acesso a usuários sem autorização.
Árvore de Documentação de Links Externos
FTP e GOPHER tem restrição para arquivos na árvore de dados, diferentemente de servidores Web. Portanto, browser Web não podem caminhar randomicamente através da estrutura de diretórios do sistema. Todo acesso é relativo ao topo da árvore.
O grande perigo para um webmaster é um sistema com usuários que podem criar um link simbólico para diretório externo a árvore de documento. Isso pode acontecer em outro documento da própria árvore ou no diretório HTML pessoal do usuário. Para segurança, o webmaster deve desabilitar a opção FollowSymLink no access.conf ou mudar para SymLinksIfOwnerMatch.
Quando se está configurando o servidor Web, se nada é feito com a diretiva UserDir no srm.conf, o servidor Web provê acesso público pelo diretório public_html abaixo de cada diretório home do usuário. Alguns usuários no seu sistema não estará ciente disso, em alguns casos pode não ser problema. Outros querem fornecer documentos HTML deste diretório. Esses são os usuários que precisam de proteção e, algumas vezes, precisamos nos proteger contra possíveis furos de segurança.
Se todos os seus usuários tem seus diretórios home em uma mesma localização física (tal como /home), a proteção é fácil. Basta incluir as seguintes diretivas no arquivo de configuração access.conf:
<Directory /home>
AllowOverride None
Options Indexes
</Directory>
Setando a diretiva AllowOverride para None e a diretiva Options para Indexes prevenindo usuários de executar acidentalmente scripts CGI com problemas potencial de segurança, expressamente incluindo links simbólicos que deixa fora da árvore de documentos. Se quiser dar a seus usuários a liberdade de criar links simbólicos, no mínimo adicionar a cláusula SymLinksFOwnerMatch na diretiva Options para assegurar que eles possam estabelecer links simbólicos para arquivos e diretórios deles mesmos.
Server-Side Includes pode ser um perigo de segurança potencial. Similarmente as desconfianças referentes a scripts CGI, Server-Side Includes pode ser usado para escrever qualquer coisa dentro do HTML stream voltando para um browser Web. Ele é geralmente uma boa idéia para desabilitar completamente o Server-Side Includes onde quer que seja possível. Não somente será vetada a uma regra potencial de segurança, mas também estará conseguindo um grande ganho em performance no seu servidor Web.
À medida que as redes de computadores crescem e que o volume armazenado de informações aumenta, são desenvolvidas novas e engenhosas ferramentas visando facilitar a localização e o acesso aos dados disponíveis. Com o auxílio dessas ferramentas, é possível "navegar" na Internet e ter acesso à imensa gama de informações disponíveis na rede.
Os serviços(ferramentas) da Internet são sistemas que utilizam a filosofia cliente/servidor em que há módulos de programas distintos para executar os pedidos de informação (cliente) e para capturar os pedidos do usuário e apresentar os resultados da execução desses pedidos (servidor). Portanto, para usar os serviços é necessário instalar um módulo cliente e para disponibilizar informações um módulo servidor.
A maioria dos softwares para utilização/disponibilização dos serviços da Internet são de domínio público, isto é, podem ser recuperados gratuitamente na rede.
Vimos alguns serviços Internet (correio eletrônico, telnet, finger, WAIS, ...) que servem, cada um , para um propósito/necessidade.
World Wide Web é o servidor de informação mais usado da Internet. Isso porque esse serviço apresenta interface gráfica agradável, agrupa uma gama de informações de diversos nichos e suporta outros serviços de informação existentes na Internet. Sua implementação é baseada no modelo cliente/servidor, utiliza como protocolo para aplicação o HTTP e seu servidor tem como função básica o fornecimento de arquivos de hipertexto no formato HTML. Ainda falando sobre servidor Web, podemos citar que as informações contidas em arquivo podem ser estáticas, quando derivadas da estrutura de arquivos, podem ser ainda dinâmicas, quando geradas sob demanda. Essas informações dinâmicas resultam da execução de programas pelo servidor e podem ser de diferentes tipos: imagens, sons, etc.
Para oferecer todas as características apresentadas anteriormente, o administrador deve realizar as seguintes tarefas básicas:
Administrar qualquer serviço Internet requer o mínimo de conhecimento sobre como manipular as ferramentas na rede e sobre a informação que está sendo disponibilizada. Requer também uma análise freqüente do tráfego da sua rede e, o que ou como fazer para a sua rede ser eficiente, adicionando software ou hadware. Talvez o mais difícil seja decidir que serviços utilizar para disponibilizar suas informações na Internet.