5. Estudo de Caso
5.2. Desenvolvimento do Servidor de Adaptação de Conteúdo
O servidor de classificação e filtragem de conteúdo [107] faz parte de uma arquitetura de adaptação de conteúdo que engloba um conjunto de servidores de adaptação de conteúdo, e um proxy de adaptação de conteúdo que estão em desenvolvimento.
Figura 42. Arquitetura para classificação e filtragem de conteúdo
A Figura 42 ilustra a arquitetura de adaptação de conteúdo, nesse caso destacando o servidor de classificação e filtragem.
Caso a política de adaptação defina a necessidade de classificação e filtragem de conteúdo o proxy envia uma requisição ICAP ao servidor de classificação e filtragem. Para otimizar a performance e aumentar as possibilidades de utilização, o servidor pode atuar nos dois modos de operação do protocolo ICAP.
O servidor de classificação e filtragem de conteúdo foi projetado de forma modular, permitindo a fácil integração de novos módulos de classificação. O modulo gerenciador de classificação e filtragem gerencia todos os módulos de classificação, a comunicação com o proxy de adaptação de conteúdo, utilizando o ICAP, incluindo o parser dos cabeçalhos ICAP e HTTP, e filtra o conteúdo a partir das informações enviadas pelos módulos de classificação. Os módulos de classificação
PICS e de imagem não fazem parte da atual implementação podendo ser objetos de trabalhos futuros.
5.2.1 Utilização das informações dos Perfis pelos servidores de Adaptação de Conteúdo.
O uso das informações armazenadas nos perfis não se limita à política de adaptação, elas também podem ser utilizadas pelos servidores de adaptação para customizar a adaptação de acordo com o contexto de entrega e preferências do usuário. No perfil de serviço são definidas quais informações serão enviadas ao servidor de adaptação. Usuário Provedor HTTP ou WAP HTTP + USER_ID O cabeçalho da requi- sição ICAP encapsula
as preferências dos usuários: icap://adaptation.com/ filter?filter_profile=001 &urldb=001&kwdb=00 5&append Proxy de Adaptação Perfil de Conteúdo content_type = html Perfil do Usuário Filter_Profile=001 URLDB=001 KWDB=005 APPEND=TRUE Perfil SLA PayForFiltering=True Servidor Web de OrigemHTTP HTTP ICAP Servidores de Adaptação 1 2 3 4 5 6 7 8 Requisição Resposta
Figura 43. Seqüência de adaptação de conteúdo
A Figura 43 apresenta um exemplo de envio de informações dos perfis para o servidor de classificação e filtragem de conteúdo. Nesse exemplo o usuário
contratou do provedor de acesso o serviço de classificação e filtragem de conteúdo e definiu as suas preferências, em relação a esse serviço, que foram armazenadas no perfil do usuário. Caso o serviço seja executado (a pré-condição PayForFiltering é atendida) as preferências do usuário relativas a este serviço são encapsuladas no cabeçalho da requisição ICAP (5) (ou SOAP) e enviada ao servidor de adaptação.
Uma requisição ICAP encapsula o cabeçalho ICAP, o cabeçalho de requisição HTTP, o cabeçalho de resposta HTTP e o corpo da página solicitada, sendo que estes dois últimos apenas quando se opera em respmod. Quando essa requisição ICAP chega ao servidor de classificação e filtragem de conteúdo, são extraídas informações: do cabeçalho ICAP, que definem as categorias de conteúdo a serem bloqueadas (e.g., filter_profile=001), a bases de dados de URLs e domínios categorizados que será utilizada (e.g., urldb=001) e, caso a adaptação esteja ocorrendo em respmod, a base de dados de palavras chave (e.g., kwdb=005). O domínio (domain) e a URL da página requisitada pelo usuário são extraídos do cabeçalho HTTP de requisição. Caso se esteja operando em respmod será extraído o conteúdo requisitado (body) possibilitando a classificação por palavras chave. A partir dessas informações é realizado o processo de classificação e filtragem de conteúdo cujo modelo de estados é apresentado na Figura 44.
5.2.2 Avaliação da eficiência do classificador de conteúdo.
Para realizar o teste de eficiência do classificador de conteúdo, o servidor de adaptação foi instalado em um centro universitário da grande São Paulo. Foram realizados testes em dois ambientes independentes: a rede administrativa, contendo 203 computadores; os laboratórios de informática de uma das faculdades, contendo 135 computadores. Durante um período de 48 horas foram verificadas 1215854 requisições (6,8 GB) da rede administrativa e 409428 requisições (2,8GB) da rede de laboratórios. Essas requisições foram geradas pelos próprios usuários da rede, não havendo nenhuma limitação ou controle, de modo a refletir um cenário real de utilização. De modo a causar o menor impacto possível no tempo de resposta dos acessos de funcionários e alunos, incluindo a já saturada rede da instituição, o servidor de adaptação utilizou o protocolo ICAP e operou apenas no modo reqmod. Esse modo gera um fluxo de dados menor na rede, pois somente as requisições são enviadas ao servidor de adaptação. Em contrapartida não é possível classificar o conteúdo por palavras chave, que funciona apenas em respmod. Os resultados obtidos são apresentados na Figura 45.
Do total de domínios classificados em ambas as redes 3 foram classificados indevidamente em categorias restritas (over-blocking) e 22 não foram classificados e passaram pelo filtro indevidamente (under-blocking). Esta verificação foi realizada manualmente, ou seja, acessando cada um dos domínios únicos. Dentre os que passaram pelo filtro, 19 pertenciam a domínios .br, o que demonstra uma menor eficiência das blacklists produzidas em outros países. Estes 22 domínios foram testados separadamente com o servidor de classificação e filtragem operando no modo respmod. Nessa nova análise de conteúdo utilizando palavras chave, 16 foram categorizados corretamente diminuindo assim sensivelmente a margem de erro.