BR112017011050B1 - Método e sistema de rede para implementar transparência de endereço de ip de fonte em uma rede de comunicação - Google Patents

Abstract

MÉTODO E SISTEMA DE REDE PARA TRANSPARÊNCIA DE ENDEREÇO DE FONTE EM UMA REDE DE COMUNICAÇÃO. Trata-se de sistemas e métodos para transparência de endereço de fonte em uma rede de comunicação que incluem um servidor proxy e uma porta de comunicação de IP em que o servidor proxy recebe um fluxo de tráfego de um dispositivo de usuário final e determina um endereço de fonte para o fluxo de tráfego detectado; o servidor proxy cria adicionalmente uma interface virtual que corresponde ao dispositivo de usuário final, a partir do qual o fluxo de tráfego foi recebido e usa a interface virtual para que o dispositivo de usuário final troque os dados entre o dispositivo de usuário final e um servidor de web designado. A interface virtual envia o fluxo de tráfego para o servidor de web designado com uso do endereço de fonte que é o mesmo ou uma variante do endereço de fonte para o dispositivo de usuário final, a partir do qual o fluxo de tráfego foi recebido.

Description

CAMPO DA TÉCNICA

[0001] A presente revelação refere-se, em geral, a redes de banda larga. Mais particularmente, algumas modalidades da presente revelação são direcionadas aos sistemas e métodos para implantar transparência de endereço de fonte para comunicações de rede.

ANTECEDENTES

[0002] Servidores proxy são amplamente usados por Provedores de Serviço de Internet (ISPs) para melhoria de desempenho, também para segurança intensificada. Um servidor proxy funciona tipicamente interceptando- se tráfego de camada de aplicação e/ou de camada 4 para / a parir do dispositivo de usuário final e, então, realiza operações especializadas, tais como servir conteúdo em cache, filtrar conteúdo malicioso com uso da Qualidade de Serviço (QoS) mais ideal, com base no tipo de conteúdo, etc. Embora realize essas funções, o servidor proxy atua no lugar do dispositivo de usuário final e, por essa razão, divide o trajeto de tráfego em dois segmentos: tráfego entre o dispositivo de usuário final e o servidor Proxy e o tráfego entre servidor Proxy e o servidor de origem.

[0003] A Figura 1 ilustra um exemplo simplificado do uso de servidor Proxy em uma rede. No exemplo ilustrado, o servidor proxy 134 pode ser implementado como um sistema de computação ou uma aplicação que pode ser configurada para atuar como um intermediário entre o dispositivo de usuário final 132 e um servidor de web (por exemplo, um servidor de origem 138), que pode ser acessado por meio da Internet 136. Servidores proxy, tais como servidor proxy 134, tipicamente intermedeiam para tratar solicitações para serviços ou recursos de um ou mais dispositivos de usuário final 132. Em operação, o dispositivo de usuário final 132 se conecta ao servidor proxy e solicita serviço de outro servidor, tal como, por exemplo, servidor de origem 138. O serviço pode incluir, por exemplo, um arquivo, uma conexão, uma página da web ou outro recurso disponível a partir do servidor de origem 138. O servidor proxy recebe a solicitação e se comunica com o servidor de origem 138 como um proxy para o usuário final. Embora um dispositivo de usuário final 132 e um servidor de origem 138 sejam ilustrados, os servidores proxy 134 podem tratar tipicamente o tráfego dentre múltiplos dispositivos de usuário final 132 e servidores de origem 138.

[0004] O tráfego entre o servidor proxy 134 e o servidor de origem 112, 114, conforme visto pelo servidor de origem 138, ou quaisquer dispositivos intermediários, origina-se e termina no servidor proxy 134. O endereço de IP de fonte de origem de tráfego 112 é aquele do servidor proxy 134 e não aquele do dispositivo de usuário final no lugar do qual o servidor proxy está solicitando o conteúdo. Uma dentre as funções centrais do servidor proxy 134 é a identificação e o rastreamento de fluxos de tráfego individuais. O início ou o fim de um fluxo de tráfego é dependente do tipo de protocolo de aplicação e / ou de camada 4, mas usualmente tem interações muito bem definidas.

[0005] Como exemplo, no caso de protocolo de camada 4 de TCP, o handshake de 3 vias é um indicador bem definido para início de um fluxo de tráfego e, em qualquer ponto no tempo, as 5 tuplas de TCP (Endereço de Fonte, Porta de Fonte, Endereço de Destino, Porta de Destino e Protocolo) identificam unicamente um fluxo de tráfego. Interações semifechadas de TCP podem ser usadas como um indicador para o fim do fluxo de tráfego. No caso do protocolo de camada de aplicação de HTTP, um fluxo / transação de HTTP se inicia com a mensagem de solicitação de HTTP de recibo (por exemplo, GET, POST, PUT, HEAD etc.). O servidor proxy rastreia o fluxo de HTTP combinando-se as solicitações e as respostas correspondentes (200 OK, 302 Encontrado, 404 Não Encontrado, etc.). O recibo de uma resposta completa (que pode transpor múltiplos segmentos de TCP) marca o fim do fluxo / da transação de HTTP. Em qualquer momento, o servidor proxy 134 tem informações de estado completas em todos os fluxos entre o dispositivo de usuário final 132 e si mesmo, bem como os fluxos de tráfego correspondentes entre si mesmo e o servidor de origem 138.

[0006] A presença do endereço de IP de servidor proxy no tráfego 114 pode impedir o uso de aplicações, tais como intercepção legal, geolocalização ou conformação de tráfego, que confiam no endereço de IP de fonte para realizar suas funções. Para possibilitar o uso de tais funções especializadas, o endereço de IP de fonte do tráfego, a partir do servidor proxy, é idealmente aquele do dispositivo de usuário final. O uso de endereço de IP de dispositivo de usuário final 132 como o endereço de fonte no tráfego que se origina do servidor proxy é denominado como Transparência de Endereço de IP de Fonte. Uma solução convencional para alcançar a transparência de endereço de IP de Fonte é o uso de aplicação / dispositivo especializado para realizar a alternância de camada 4.

[0007] A Figura 2 ilustra um exemplo do uso de dispositivo / aplicação de comutador de camada 4 para implantar transparência de endereço de IP de Fonte. Conforme observado na Figura 2, esse exemplo inclui um comutador, ou uma aplicação, de camada 4, 140 que fornece uma interface para servidor proxy 134. A aplicação / o dispositivo de comutação de camada 4 140, em várias implantações, tem capacidade para identificar os fluxos de tráfego. Com uso de informações de controle de tempo de execução e de configuração, a aplicação / o comutador de camada 4 140 pode ser configurado para alterar os conteúdos de cabeçalho de IP e da camada 4 (por exemplo, TCP). Essa capacidade da aplicação / do comutador de camada 4 140 pode ser usada para inserir o endereço de IP de dispositivo de usuário final 132 nos pacotes de IP que transporta os segmentos de camada 4. Consequentemente, no exemplo da Figura 2, em trajetos de sinal 164 e 165, o endereço de IP de fonte é aquele de dispositivo de usuário final 132; no trajeto de sinal 166, o endereço de IP de fonte é aquele de servidor proxy 134; e nos trajetos 168, o endereço de IP de fonte é aquele de dispositivo de usuário final 132. Além disso, é ilustrada a sinalização de controle 162 para permitir que o servidor proxy controle o comutador de camada 4 140.

[0008] Os dispositivos de comutador de camada 4 prontos para uso são disponibilizados para inspecionar fluxos de tráfego de camada 4 e, então, realizar uma variedade de funções que incluem alternação de endereços de IP de fonte. O uso de um dispositivo separado pode fornecer a vantagem de rápida colocação no mercado, mas pode ter a desvantagem de custo de equipamento elevado. Há, também, questões de redundância de sistema que precisam ser consideradas, ao usar um dispositivo de comutação de camada 4 autônomo. Implementar a função de comutador de camada 4 como aplicação de software autônoma, dentro do servidor proxy é uma alternativa possível ao uso do dispositivo separado. Entretanto, a implantação de comutador de camada 4 tem seus próprios custos de desenvolvimento, complexidade de processamento, questões de dimensionamento, bem como custos de manutenção de software.

SUMÁRIO

[0009] Sistemas e métodos são fornecidos em várias modalidades para fornecer transparência de endereço de IP de fonte para comunicações de rede conduzidas com o uso de um servidor proxy. Particularmente, várias modalidades dos sistemas e métodos revelados no presente documento podem ser configuradas para criar e utilizar uma interface virtual para comunicações de transparência de endereço de IP de fonte. A interface virtual pode ser configurada para permitir que o servidor proxy utilize o endereço de IP de dispositivos de usuário final, ou uma variação do mesmo, como o endereço de IP para comunicações a partir do servidor proxy, ao se comunicar com servidores ou elementos de rede, tais como, por exemplo, servidores de origem ou outros servidores de web. Em várias modalidades, a interface virtual pode ser configurada para incluir um endereço de IP virtual vinculado à interface de enlace de retorno do servidor proxy.

[0010] Em várias modalidades, quando o servidor proxy detecta o início do fluxo de tráfego, (por exemplo, quando o servidor proxy recebe uma solicitação do dispositivo de usuário final), o servidor proxy cria um endereço de IP virtual para aquele dispositivo. Isso é denominado, no presente documento, como uma interface virtual. O endereço de IP virtual pode ser ajustado para uma variante do endereço de IP de fonte do dispositivo de usuário final (isto é, o endereço de fonte da conexão de TCP). Por exemplo, o endereço de IP virtual de um dispositivo de usuário final pode ser o endereço de IP +1 de dispositivo de usuário final. Em outras modalidades, o endereço de IP virtual é alguma outra variante do endereço de IP de dispositivo de usuário final. Preferencialmente, entretanto, o endereço de IP virtual é escolhido como estando na mesma sub-rede do endereço de IP do dispositivo de usuário final. Com a interface virtual estabelecida para o dispositivo, o servidor proxy usa aquela interface virtual para trocar dados no lugar do dispositivo de usuário final correspondente. Por exemplo, o servidor proxy usa tabelas de roteamento definidas (que podem ser difusão seletiva de uma Porta de Comunicação de IP, por exemplo) para rotear comunicações para o servidor de web com uso do endereço de IP virtual como o endereço de fonte.

[0011] Tipicamente a criação e atribuição de endereços de IP virtuais podem ser realizadas com o uso de uma única chamada de API ou um único comando de CLI. Devido ao fato de que, em algumas aplicações, o cliente de usuário final pode usar tipos diferentes de endereços (por exemplo, endereços de IPv4 e/ou IPv6), o servidor proxy pode criar dois endereços de IP virtuais (por exemplo, um para IPv4 e outro para IPv6).

[0012] Em uma modalidade, um método para transparência de endereço de fonte em uma comunicação inclui um servidor proxy que recebe um fluxo de tráfego de um dispositivo de usuário final e que determina um endereço de fonte para o fluxo de tráfego detectado; o servidor proxy que determina um endereço de IP virtual que corresponde a um endereço de IP de fonte do dispositivo de usuário final, a partir do qual o fluxo de tráfego foi recebido, e que usa o endereço de IP virtual para trocar dados entre o dispositivo de usuário final e um servidor de web designado; e a interface virtual que envia o fluxo de tráfego para o servidor de web designado com uso do endereço virtual como seu endereço de fonte. O endereço virtual pode ser o mesmo ou uma variante do endereço de fonte para o dispositivo de usuário final, a partir do qual o fluxo de tráfego foi recebido. Em troca, o servidor proxy recebe uma resposta ao fluxo de tráfego a parti do servidor de web designado e roteia a resposta para o dispositivo de usuário final.

[0013] Em algumas modalidades, o servidor proxy que recebe um fluxo de tráfego de um dispositivo de usuário final compreende receber o fluxo de tráfego por meio de uma porta de comunicação de IP, e a porta de comunicação de IP determina se o fluxo de tráfego deve ser tratado com o uso de transparência de endereço de fonte. A determinação da possibilidade de o fluxo de tráfego dever ser tratado com o uso de transparência de endereço de fonte pode ser efetuada determinando-se uma porta de destino para o fluxo de tráfego designado pelo dispositivo de usuário final e fazendo-se com que a determinação se baseie na porta de destino designada pelo dispositivo de usuário final. Em várias modalidades, uma gama de portas de destino pode ser usada para identificar uma conexão transparente de endereço de IP de fonte. A porta de comunicação de IP pode ser adicionalmente configurada para criar um mapeamento de endereço de IP entre o dispositivo de usuário final e o servidor proxy.

[0014] O processo pode, adicionalmente, ser configurado de modo que o servidor proxy receba a resposta ao fluxo de tráfego, a partir do servidor de web designado diretamente ou por meio da porta de comunicação de IP. Consequentemente, a porta de comunicação de IP pode receber a resposta e determinar se a resposta deve ser roteada para o servidor proxy ou se a resposta deve se desviar do servidor proxy. A porta de comunicação de IP pode ser configurada para armazenar informações que indicam se o fluxo de tráfego deve ser tratado com o uso de transparência de endereço de fonte, e a porta de comunicação de IP que determina se a resposta deve ser roteada para o servidor proxy pode incluir verificar as informações armazenadas para determinar se o fluxo de tráfego que corresponde à resposta foi tratado com o uso de transparência de endereço de fonte.

[0015] Em modalidades adicionais, um sistema de rede que implanta transparência de endereço de fonte para comunicações entre um dispositivo de usuário final e um servidor, pode incluir um servidor proxy, que tem uma pluralidade de interfaces virtuais. O servidor proxy pode ser configurado para realizar as operações que incluem: receber um fluxo de tráfego a partir de um dispositivo de usuário final e determinar um endereço de fonte para o fluxo de tráfego detectado; criar uma interface virtual que corresponde ao dispositivo de usuário final, a partir do qual o fluxo de tráfego foi recebido; e enviar, por meio da interface virtual, o fluxo de tráfego para o servidor de web designado com o uso de um endereço de fonte que é o mesmo ou uma variante do endereço de fonte para o dispositivo de usuário final, a partir do qual o fluxo de tráfego foi recebido.

[0016] O sistema de rede pode incluir uma porta de comunicação de IP, em que a porta de comunicação de IP é configurada para receber o fluxo de tráfego e determinar se o fluxo de tráfego deve ser tratado com o uso de transparência de endereço de fonte. Em várias modalidades, determinar se o fluxo de tráfego deve ser tratado com o uso de transparência de endereço de fonte pode incluir determinar uma porta de destino para o fluxo de tráfego designado pelo dispositivo de usuário final e fazer com que a determinação se baseie na porta de destino designada pelo dispositivo de usuário final. A porta de comunicação de IP também pode ser configurada para criar um mapeamento de endereço de IP entre o dispositivo de usuário final e o servidor proxy.

[0017] Outros recursos e aspectos da revelação se tornarão evidentes a partir da descrição detalhada a seguir, obtida em conjunto com os desenhos anexos, os quais ilustram, a título de exemplo, os recursos, de acordo com várias modalidades. O sumário não se destina a limitar o escopo da invenção, que é definido somente pelas reivindicações anexas ao mesmo.

BREVE DESCRIÇÃO DOS DESENHOS

[0018] A tecnologia revelada no presente documento, de acordo com uma ou mais várias modalidades, é descrita em detalhes, em referência às figuras a seguir. Os desenhos são fornecidos com propósitos apenas de ilustração e retratam meramente as modalidades exemplificativas ou típicas da tecnologia revelada. Esses desenhos são fornecidos para facilitar a compreensão do usuário da tecnologia revelada e não devem ser considerados limitantes da amplitude, escopo ou aplicabilidade da mesma. Deve ser observado que, a título de clareza e facilidade de ilustração, esses desenhos não são, necessariamente feitos em escala.

[0019] A Figura 1 ilustra um exemplo simplificado do uso de servidor Proxy em uma rede.

[0020] A Figura 2 ilustra um exemplo do uso de dispositivo / aplicação de comutador de camada 4 para implantar transparência de endereço de IP de fonte, de acordo com ensinamentos convencionais.

[0021] A Figura 3 é um diagrama que ilustra um exemplo de uma interface virtual incluída com um servidor proxy, de acordo com uma modalidade dos sistemas e métodos revelados no presente documento.

[0022] A Figura 4 é um diagrama que ilustra um processo exemplificativo para criar uma interface virtual, de acordo com uma modalidade dos sistemas e métodos revelados no presente documento.

[0023] A Figura 5 é um diagrama que ilustra uma implantação exemplificativa que inclui uma porta de comunicação de IP, de acordo com uma modalidade dos sistemas e métodos revelados no presente documento.

[0024] A Figura 6 é um diagrama em escada que ilustra uma comunicação exemplificativa através de um servidor proxy, com o uso de transparência de endereço de IP de fonte, de acordo com uma modalidade da tecnologia descrita no presente documento.

[0025] A Figura 7 é um fluxograma operacional que ilustra um processo exemplificativo para enviar uma comunicação de um usuário final para um servidor de web, de acordo com uma modalidade dos sistemas e métodos descritos no presente documento.

[0026] A Figura 8 é um diagrama que ilustra um exemplo para rotear uma resposta a uma solicitação enviada com o uso de transparência de endereço de IP de fonte, de acordo com uma modalidade dos sistemas e métodos descritos no presente documento.

[0027] A Figura 9 ilustra um sistema de computador, mediante o qual modalidades exemplificativas, de acordo com os sistemas e métodos revelados no presente documento, podem ser implementadas.

[0028] A Figura 10 ilustra um conjunto de chips, no qual as modalidades dos sistemas e métodos revelados no presente documento podem ser implementadas.

[0029] As figuras não são destinadas a serem exaustivas ou a limitar a invenção à forma precisa revelada. Deve ser compreendido que a invenção pode ser praticada com modificação e alteração, e que a tecnologia revelada é limitada apenas pelas reivindicações e as equivalentes das mesmas.

DESCRIÇÃO DETALHADA

[0030] Várias modalidades dos sistemas e métodos revelados no presente documento fornecem mecanismos para fornecer transparência de endereço de IP de fonte para comunicações de rede conduzidas com o uso de um servidor proxy. Particularmente, várias modalidades dos sistemas e métodos revelados no presente documento podem ser configuradas para criar e utilizar uma interface virtual, que pode ser configurada para permitir que o servidor proxy utilize o endereço de IP de dispositivos de usuário final (ou uma variante do mesmo) como o endereço de IP de fonte, ao se comunicar com servidores ou elementos de rede, tais como, por exemplo, servidores de origem ou outros servidores de web. Em várias modalidades, o servidor proxy pode ser configurado para usar a interface virtual para rotear comunicações para o servidor de web com uso do endereço de IP virtual como o endereço de fonte.

[0031] Em várias modalidades, quando o servidor proxy detecta o início do fluxo de tráfego, o mesmo verifica o endereço de IP de fonte usado pelo fluxo de tráfego detectado e cria uma interface virtual para o dispositivo de usuário final, a partir do qual o fluxo é detectado. Por exemplo, em algumas aplicações, o tráfego pode fluir para o servidor proxy em uma LAN virtual (VLAN), e o servidor proxy obtém informações do dispositivo de usuário final para criar o endereço de IP virtual. O tráfego pode, então, ser obtido daquele endereço de IP virtual, e o servidor proxy roteia o fluxo na VLAN que está envolvido.

[0032] Conforme observado, em várias modalidades, a interface virtual inclui um ou mais endereços de IP virtuais vinculados à interface de enlace de retorno do servidor proxy. O endereço de IP virtual pode ser uma variante do endereço de IP de fonte do dispositivo de usuário final correspondente. Por exemplo, o endereço de IP virtual pode ser o endereço de IP de dispositivo de usuário final, aumentado ou diminuído por um valor de número inteiro (por exemplo, endereço de IP de fonte + 1). Preferencialmente, o endereço de IP virtual, apesar de uma variante do endereço de IP de fonte, está na mesma sub-rede como o endereço de IP de fonte.

[0033] O endereço de IP da nova interface virtual é ajustado para o endereço de IP virtual associado ao dispositivo de usuário final correspondente. Em várias modalidades, as interfaces virtuais são criadas como comunicações que ocorrem com novos dispositivos de usuário final, e podem ser terminadas quando aqueles fluxos são terminados.

[0034] A Figura 3 é um diagrama que ilustra um exemplo de uma interface virtual incluída com um servidor proxy, de acordo com uma modalidade dos sistemas e métodos revelados no presente documento. Em referência, agora, à Figura 3, nesse exemplo, um servidor proxy 244 é dotado de uma interface virtual 250. A interface virtual 250, em várias modalidades pode, na verdade, incluir múltiplas interfaces virtuais para fornecer uma única interface virtual que corresponde a cada uma dentre uma pluralidade de dispositivos de usuário final 132. Em algumas modalidades, a interface virtual inclui um endereço de IP virtual associado aos terminais de usuário final (por exemplo, dispositivos de usuário final 132 na Figura 2) e servidores de web (por exemplo, servidores de origem 138 na Figura 2).

[0035] Ao invés de terminar as interfaces virtuais quando os fluxos são terminados, em algumas modalidades, as interfaces virtuais podem ser mantidas e reusadas à medida que novos fluxos, a partir de dispositivos de usuário final correspondentes são iniciados. Consequentemente, em várias modalidades, quando o servidor proxy 244 cria uma interface virtual para um dispositivo de usuário final 132, o mesmo armazena um indicador na memória para a interface virtual, então, a interface virtual pode ser cancelada para uso posterior. Por exemplo, o mesmo pode ser configurado para criar uma entrada de memória de interface virtual (por exemplo, uma entrada de tabela) para a interface virtual que é indexada ou inserida (ou, de outro modo, passível de pesquisa) com uso do endereço de IP do dispositivo de usuário final 132. Visto que as comunicações subsequentes são recebidas de dispositivos de usuário final 132, seus endereços de IP associados podem ser verificados contra as entradas de tabela de interface virtual para determinar se uma interface virtual já foi criada para o dispositivo de usuário final.

[0036] Em operação, a interface virtual criada para o dispositivo pode ser configurada para se comunicar com o servidor de web (por exemplo, servidor de origem 138) com uso do endereço de IP virtual criado associado ao terminal correspondente (por exemplo, Dispositivo de usuário final 132) como o endereço de fonte para a comunicação. Consequentemente, quaisquer ações tomadas ou respostas dadas pelo servidor de web designado podem obter tais ações e fornecer tais respostas com o uso de um endereço de IP virtual com base no endereço de IP de fonte do terminal de solicitação. Por essa razão, as comunicações de um dispositivo de usuário final 132 nos trajetos de comunicação 264 e 268 incluem o endereço de IP virtual associado àquele dispositivo de usuário final 132. Em algumas modalidades, o endereço de IP de fonte para comunicações nos trajetos 268 é aquele da interface virtual, que é uma variante do dispositivo de usuário final 132. Em outras modalidades, o endereço de IP virtual pode ser o mesmo que o endereço de IP de fonte do dispositivo de usuário final correspondente. Conforme observado acima, em algumas modalidades, o endereço de IP virtual é o endereço de IP +1 de usuário final para o dispositivo de usuário final correspondente. Esse pode ser o caso para ambos os endereços de IP IPv4 e IPv6. Adicionalmente, a sub- rede de rede pode ser configurada para o dispositivo de usuário final, de modo que se garanta que o endereço virtual de endereço +1 esteja na sub-rede atribuída do dispositivo de usuário final.

[0037] Em várias modalidades, as tabelas de comutador de camada 3 e quatro podem ser usadas para facilitar a tecnologia descrita. Os exemplos disso são revelados em mais detalhes abaixo. As informações de estado usadas para o comutador de camada 4 já estão disponíveis no servidor proxy, visto que identificar os fluxos de tráfego e atuar sobre eles é uma função central do servidor proxy. Várias modalidades usam as informações de estado e adicionam funcionalidade para suportar a transparência de endereço de IP de fonte. Por exemplo, uma interface virtual pode ser implementada como uma representação lógica de uma interface de rede que pode ou não pode ser associada a uma interface / adaptador de rede física. A interface virtual pode ser implementada de modo que a mesma possa ser tratada pelo sistema operacional do mesmo modo que o sistema operacional trata uma interface de rede física. Devido ao fato de que muitos sistemas operacionais contemporâneos suportam API ou comandam a interface de linha para criar e apagar interfaces virtuais, a interface virtual, conforme revelado no presente documento, pode ser criada com uso dessas ferramentas em várias modalidades. Para suportar a transparência de endereço de IP de fonte, o endereço de IP do dispositivo de usuário final é atribuído à interface virtual, conforme descrito acima. Todas as transferências de dados no lugar do dispositivo de usuário final que são destinadas a utilizar a transparência de endereço de IP de fonte podem usar a interface virtual (criada especificamente para aquele dispositivo de usuário final em várias modalidades). Em operação, quando a interface virtual se comunica com o servidor de web, a pilha de IP / TCP do sistema operacional insere o endereço de IP atribuído à interface virtual como o endereço de IP de fonte para aquela comunicação.

[0038] A Figura 4 é um diagrama que ilustra um processo exemplificativo para criar uma interface virtual, de acordo com uma modalidade dos sistemas e métodos revelados no presente documento. Em referência, agora, à Figura 4, nesse exemplo, na operação 334, o servidor proxy cria uma interface virtual. Conforme observado acima, em algumas modalidades, a interface virtual pode incluir uma tabela de interface virtual que pode ser povoada com entradas que correspondam aos dispositivos de usuário final que se comunicam através do servidor proxy. Na operação 337, o servidor proxy detecta um fluxo de tráfego partir de um dispositivo de usuário final. Quando o fluxo de tráfego é detectado, o servidor proxy determina o endereço de IP de fonte para o fluxo e pesquisa a tabela de interface virtual com uso daquele endereço de IP de fonte. Isso é ilustrado na operação 341. Se o endereço de IP de fonte for detectado na tabela, isso indica que uma interface virtual já foi criada pelo servidor proxy para aquele dispositivo de usuário final, e que a interface virtual existe.

[0039] Se a interface virtual já existir, o servidor proxy usa aquela interface virtual existente para trocar dados através da Internet. Isso é ilustrado pelas operações 345 e 347. Se, por outro lado, a interface virtual já não existir para aquele usuário final, o servidor proxy cria uma nova interface virtual e atribui o endereço de IP de fonte do dispositivo de usuário final, ou uma variante do mesmo, como o endereço de IP da interface virtual criada mais nova. Isso é ilustrado pelas operações 345, 352 e 354. Tendo criado a nova interface virtual, o servidor proxy pode se comunicar com o servidor de web designado por meio da Internet, com uso dessa interface virtual. O exemplo ilustrado na Figura 4 presume que as interfaces virtuais podem ser criadas e mantidas após o término dos fluxos que correspondem àquelas interfaces virtuais. Conforme observado no presente documento, em outras modalidades, interfaces virtuais são criadas conforme necessário, quando fluxos são criados, e terminadas quando seus fluxos correspondentes terminam.

[0040] Em várias modalidades, uma porta de comunicação de IP pode ser incluída para determinar se as respostas dos servidores de web devem retornar diretamente para um dispositivo de usuário final, ou se as mesmas devem ser roteadas através do servidor proxy. A Figura 5 é um diagrama que ilustra uma implantação exemplificativa que inclui uma porta de comunicação de IP, de acordo com uma modalidade dos sistemas e métodos revelados no presente documento. Como o exemplo da Figura 3, o exemplo ilustrado na Figura 5 inclui um servidor proxy 244, que inclui uma interface virtual 250. Conforme observado acima, embora uma interface virtual 250 seja mostrada, uma pessoa de habilidade comum na técnica, após ler esta descrição irá compreender que múltiplas interfaces virtuais 250 podem ser criadas para o servidor proxy 244.

[0041] Além do servidor proxy 244, esse exemplo inclui uma porta de comunicação de IP 252. Embora a porta de comunicação de IP 252 seja mostrada como estando separada do servidor proxy 244, a funcionalidade de porta de comunicação de IP 252 pode ser integrada, ou, de outro modo, empacotada com o servidor proxy 244. No exemplo ilustrado, todas as comunicações entre a Internet e os servidores de web e os dispositivos de usuário final são roteadas através da porta de comunicação de IP 252, com a exceção das comunicações 268 da interface virtual para a Internet. Em outras modalidades, todas as comunicações entre a Internet e os servidores de web e os dispositivos de usuário final são roteadas através da porta de comunicação de IP 252. A porta de comunicação de IP 252, em várias modalidades, pode ser usada para determinar se o tráfego deve ser roteado através de servidor proxy 244, ou se as comunicações entre o dispositivo de usuário final 132 e a Internet podem ser conduzidas sem rotear através de servidor proxy 244. Os exemplos de funcionalidade que podem ser incluídos na porta de comunicação de IP 252, em várias modalidades, são descritos abaixo.

[0042] Em várias modalidades, o servidor proxy invoca uma linha de comando Linux para adicionar e remover interfaces virtuais com o uso de comandos e subcomandos de IP Linux. Em algumas implantações, os dispositivos de usuário final se comunicam com os endereços de IPV4 e IPV6, quando os mesmos se conectam ao servidor proxy. O servidor proxy, por sua vez, invoca as linhas de comendo de acabamento para Linux para adicionar interfaces virtuais a IPV4 e IPV6. Uma vez criada, a interface virtual pode ser configurada como a extremidade frontal para o servidor proxy. Todas as solicitações de saída são encaminhadas pela interface virtual, com uso do endereço de IP virtual. Essas solicitações podem ser roteadas com uso das tabelas de roteamento de nível de kernel do servidor proxy, que, em algumas modalidades, são fornecidas pela porta de comunicação de IP. Consequentemente, o servidor proxy abre uma nova conexão para a Internet, novamente, sendo que o endereço de IP de fonte é uma variante do endereço do dispositivo de usuário final original, devido ao fato de que a conexão é obtida a partir da interface virtual, com o endereço de IP do dispositivo de usuário final. Devido ao fato de que as interfaces virtuais usam o endereço de IP virtual, as solicitações de saída parecem que são, na verdade, obtidas por meio dos dispositivos de usuário final originais. A resposta do servidor de web opera de forma similar, em que a conexão de retorno retorna para o servidor proxy e, particularmente, para a interface virtual associada ao endereço de IP virtual. A interface virtual roteia a resposta ao dispositivo de usuário final correspondente.

[0043] Em algumas modalidades, uma vez que uma interface virtual é criada, todas as comunicações em direção a um ou mais servidores de origem iniciadas pelo servidor proxy no lugar de um dispositivo de usuário final, que usa transparência de endereço de IP de fonte, atravessam a interface virtual que corresponde àquele dispositivo de usuário final. Uma API usada para a rede comunicação (por exemplo, soquetes Berkeley / POSIX) pode ser incluída para fornecer um mecanismo para especificar a interface / dispositivo para usar para a comunicação. Conforme observado acima, em várias modalidades, pode-se confiar na pilha de TCP / IP do servidor proxy para inserir o endereço de IP virtual atribuído à interface virtual como o endereço de IP de fonte. Isso garante que todo o tráfego que se origina dessa interface virtual tenha o endereço de IP correspondente associado ao seu dispositivo de usuário final correspondente.

[0044] Cronômetros ou outras técnicas similares podem ser usados para medir o tempo ocioso, de modo que as interfaces virtuais possam ser removidas ou, de outro modo, limpas quando as mesmas não forem mais necessárias ou não estiverem mais em uso. Em várias modalidades, quando o servidor proxy detecta que aquele dispositivo de usuário final está ocioso, a interface virtual é apagada. Para manter a faixa de tempo ocioso e as interfaces ativas, o servidor proxy pode ser configurado para atualizar a interface virtual (por exemplo, uma entrada de tabela de interface virtual) com data e hora da recepção / transmissão mais recente de dados. Em outras modalidades, as informações de data e hora não são mantidas na interface virtual, mas, ao contrário, são mantidas como parte do protocolo de comunicação normal entre o usuário final e o servidor proxy. Ou seja, a interface virtual pode ser terminada quando a conexão entre o dispositivo de usuário final e o servidor proxy expirar. Por exemplo, em algumas modalidades, o usuário final e o servidor proxy se comunicam com o uso de um protocolo especializado, tal como, por exemplo, o protocolo de troca de bloco multiplexada (MBX), que usa o TCP como seu mecanismo de transporte subjacente. Em tais modalidades, o sistema pode confiar no rastreamento de tempo ocioso mantido como parte de MBX para determinar quando terminar as interfaces virtuais. Em outras palavras, as interfaces virtuais podem ser terminadas ou destruídas quando a conexão de MBX expirar.

[0045] As interfaces virtuais consumem os recursos de sistema operacional (por exemplo, entradas de tabela de roteamento), e o limite superior no número de interfaces virtuais que pode ser criado é tipicamente dependente do sistema operacional. Devido ao fato de que o servidor proxy trata de grandes quantidades de dispositivos de usuário final, os recursos de sistema operacional são, preferencialmente, usados racionalmente. Periodicamente, o servidor Proxy varre todas as entradas na tabela de interface virtual. As interfaces virtuais que estão ociosas (determinadas com uso do tempo atual e do tempo que corresponde ao acesso mais recente) por mais do que um período de tempo configurável são apagadas. Similar à criação de interface, o apagamento de interface virtual é tipicamente uma única chamada de API ou comando de CLI, dependendo da implantação. Conforme observado acima, em algumas modalidades, isso pode ser efetuado com base na ociosidade da conexão de MBX.

[0046] Como parte do tratamento de transações, a partir de dispositivos de usuário final, para grandes instalações, uma grande quantidade de interfaces será criada e apagada dinamicamente. Para pacotes de IP a serem roteados de volta para a interface virtual correta, o servidor proxy pode ser configurado para empregar os protocolos de roteamento padrão, tais como, por exemplo, o Protocolo de Porta de Comunicação Limite (BGP). Quando o BGP é usado, a configuração é preferencialmente sintonizada para permitir a convergência rápida de rotas, de modo que os pacotes do servidor de origem possam ser roteados de volta para o servidor Proxy.

[0047] Em algumas instalações, a porta de comunicação de IP e o servidor proxy podem ser configurados no mesmo rack, ou mesmo, no mesmo chassi. Entretanto, os protocolos de roteamento usados para rotear comunicações da porta de comunicação de IP para o servidor proxy (e vice- versa) que não estão conscientes dessa proximidade podem rotear essas comunicações através do comutador na parte superior de rack, que é ineficiente e adiciona latência. Em várias modalidades, o protocolo BGP pode ser configurado para usar um salto direto entre a porta de comunicação de IP e o servidor proxy, sem ter que passar pelo comutador na parte superior de rack. Isso pode ser efetuado, por exemplo, com base nos endereços MAC de dispositivo.

[0048] A Figura 6 é um diagrama em escada que ilustra uma comunicação exemplificativa através de um servidor proxy, com o uso de transparência de endereço de IP de fonte, de acordo com uma modalidade da tecnologia descrita no presente documento. Esse exemplo é descrito em termos de uma rede que inclui um Servidor de Aceleração de Web (WAS), um Cliente de Aceleração de Web (WAC) e porta de comunicação de IP (IPGW). O WAS 610 é um servidor proxy que implanta funções de aceleração de HTTP. A porta de comunicação de IP realiza funções de roteamento para rotear sinais entre o WAC e o WAS. No exemplo de uma rede de satélite, a porta de comunicação de IP pode ser configurada como um roteador especializado que implanta várias funções de aceleração de TCP e de roteamento específico de rede de satélite. Conforme observado acima, a porta de comunicação de IP pode ser parte do servidor proxy (WAS) ou pode ser um dispositivo separado. O WAC 442 é um dispositivo de usuário final e, em algumas aplicações, reside no terminal (por exemplo, um terminal de abertura muito pequena (VSAT)) e interage com o WAS 460 para implantar funções de aceleração de HTTP. Conforme observado acima, em algumas modalidades, o WAC 442 e o WAS 460 se comunicam com o uso de um protocolo especializado denominado como a Troca de Bloco Multiplexada (MBX). O protocolo de MBX usa TCP como seu mecanismo de transporte subjacente.

[0049] Para continuidade e facilidade de compreensão pelo leitor, o cliente de aceleração de web é denominado como um dispositivo de usuário final 442, e o servidor de aceleração de web é denominado como um servidor proxy 460. Conforme observado nesse exemplo, o dispositivo de usuário final 442 envia uma mensagem configurada de MBX para o servidor proxy 460. Isso é ilustrado por 470. A mensagem flui através da porta de comunicação de IP 454, no momento em que a porta de comunicação de IP cria uma entrada de tabela para a conexão, se a conexão for identificada como uma conexão transparente de endereço de IP de fonte. Em várias modalidades, uma ou mais portas de destino específicas, ou gama de portas de destino, pode ser usada para identificar uma conexão transparente de endereço de IP de fonte. Nessa modalidade, a porta de destino é uma porta especialmente identificada (mostrada como 11223 no exemplo ilustrado), que, nesse exemplo, é usada pelo dispositivo de usuário final 442 para selecionar transparência de endereço de IP de fonte. Consequentemente, quando a porta de comunicação de IP 454 reconhece essa porta de destino, a entrada de tabela é criada correspondendo ao dispositivo de usuário final 442. Do mesmo modo, a interface virtual é criada no servidor proxy 460 com base na identificação da porta de destino. Em outras modalidades, outros mecanismos podem ser usados para selecionar transparência de endereço de IP de fonte para a conexão. Esses outros mecanismos podem incluir, por exemplo, a definição de sinalizações ou outros semáforos na comunicação, ou outros mecanismos de sinalização ou técnicas de camada de MAC.

[0050] Com a transparência de endereço de IP de fonte estabelecida, na operação 472, o dispositivo de usuário final 442 envia uma comunicação para o servidor proxy 460. Deve-se observar que, nesse exemplo, essa comunicação é enviada com o uso de porta de destino especialmente identificada (por exemplo, 11223). Essa comunicação também tem um endereço de IP de fonte como o dispositivo de usuário final em si (designado como WAC no exemplo ilustrado) com uma porta de fonte designada como X. A porta de destino é o servidor proxy (designado como WAS no exemplo ilustrado).

[0051] O servidor proxy 460 recebe essa comunicação, e a interface virtual envia essa comunicação para o servidor de web designado. Isso é ilustrado em 474. Conforme observado pelas designações, o endereço de IP de fonte é uma variante do endereço de IP de fonte original do dispositivo de envio (VARWAC, nesse exemplo). Em outras modalidades, o endereço de IP de fonte permanece como o endereço de IP de fonte original, como o dispositivo de envio (WAC, nesse exemplo). Além disso, nesse exemplo, a porta de fonte foi mudada para Y. Para facilitar o roteamento para o servidor de web apropriado, conforme identificado pelo dispositivo de usuário final de envio 442, o servidor proxy (por exemplo, pela interface virtual) designa o endereço de IP de destino como WS e a porta de destino como 80.

[0052] O servidor de web 465 recebe a comunicação e fornece a resposta apropriada. Por exemplo, a comunicação pode ser uma solicitação para baixar ou recuperar as informações do servidor de web. Consequentemente, as informações solicitadas são enviadas de volta para o dispositivo de solicitação. Isso é ilustrado em 476. Nesse exemplo, o servidor de web 465 compreende que o dispositivo de solicitação tem um endereço de IP de fonte de VARWAC (que é o endereço de IP virtual da interface virtual, e que, nessa modalidade, é uma variação do endereço de IP de fonte original do dispositivo de usuário final), e, consequentemente, envia a resposta de volta para o endereço de IP de destino VARWAC na porta de fonte Y. Com base no protocolo de rede, essa mensagem é roteada para a porta de comunicação de IP 454.

[0053] A porta de comunicação de IP 454 interroga uma resposta e determina que a mesma foi enviada em resposta a uma comunicação com o uso de transparência de endereço de IP de fonte. A mesma também determina que a solicitação foi enviada por meio do servidor proxy. Isso pode ser determinado, por exemplo, com base nas definições de tabela feitas durante a configuração 470. Exemplos mais detalhados disso são descritos abaixo. Com base nessas determinações, a porta de comunicação de IP 454 não sabe enviar a mensagem diretamente para o dispositivo de usuário final original (WAC), mas, ao contrário, fornece a resposta ao servidor proxy, conforme indicado em 478. O servidor proxy muda o endereço de IP de fonte da mensagem para o endereço de IP de servidor proxy (WAS, nesse exemplo), muda a porta de fonte para uma porta que identifica a transparência de endereço de IP de fonte (112233, nesse exemplo) e envia uma mensagem para o original usuário final designado (WAC) em seu endereço de IP de fonte original (WAC) na porta de destino X.

[0054] A Figura 7 é um fluxograma operacional que ilustra um processo exemplificativo para enviar uma comunicação de um usuário final para um servidor de web, de acordo com uma modalidade dos sistemas e métodos descritos no presente documento. A título de clareza, esse exemplo pode ser descrito periodicamente, em termos do diagrama em escada exemplificativo ilustrado na Figura 6.

[0055] Na operação 732, a porta de comunicação de IP constrói as tabelas de alternância. Em algumas modalidades, a porta de comunicação de IP pode construir para alternar as tabelas para a alternância de tráfego. Em algumas modalidades, o IPGW é configurado para manter duas tabelas separadas para alternância de tráfego. Uma tabela pode ser usada para identificar as sessões de TCP entre o dispositivo de usuário final e o servidor proxy, e outra tabela pode ser usada para identificar e registrar o início e o término de sessões entre o dispositivo de usuário final e o servidor proxy. Como exemplo adicional, em uma modalidade, a porta de comunicação de IP é configurada para a de Alternância de Camada 4 (L4ST) identificando-se e registrando-se o início e o término de sessões de TCP entre um terminal e um servidor de web em uma porta designada. A porta de comunicação de IP pode ser configurada para tratar de comunicações que se desviam do servidor proxy, bem como comunicações que são direcionadas através do servidor proxy.

[0056] Para comunicações que se desviam do servidor proxy (designado, em algumas modalidades, pelas portas de destino designadas), a porta de comunicação de IP usa a L4ST para alternar o tráfego que retorna do servidor de web diretamente para o dispositivo de solicitação de usuário final, desviando-se do servidor proxy. Para todas as outras portas de destino, que incluem portas que usam transparência de endereço de IP de fonte, a porta de comunicação de IP roteia tráfego para o servidor proxy. Consequentemente, a porta de comunicação de IP pode rastrear sessões que se desviam do servidor proxy na tabela L4ST. No exemplo ilustrado na Figura 7, isso é mostrado na operação 734, na qual a porta de comunicação de IP registra todos os fluxos de TCP de não MBX na primeira tabela de transparência de fonte. O tratamento de comunicações que usam portas de transparência de endereço de IP de fonte pode ser denominado, de forma resumida, como STTS, ou alternância de tráfego de transparência de fonte, em algumas aplicações.

[0057] No exemplo ilustrado, a porta de comunicação de IP também constrói uma Tabela de Alternância de Camada 3 (L3ST), identificando-se e registrando-se o início e o término de sessões (por exemplo, sessões de MBX no exemplo acima) entre um dispositivo de usuário final e um servidor proxy. Qualquer pacote de TCP destinado ao terminal que não inicia uma nova sessão de TCP e também não combina com uma sessão existente na tabela L4ST (isto é, não é designado como desviando do servidor proxy) é encaminhado para o servidor proxy apropriado pela porta de comunicação de IP com base na tabela L3ST.

[0058] Na operação 736, o dispositivo de usuário final inicia uma sessão (por exemplo, uma sessão de MBX) com o servidor proxy e divulga seu endereço de IP. Na operação 738, a porta de comunicação de IP cria um mapeamento de endereço de IP entre o dispositivo de usuário final e o servidor proxy. Em algumas modalidades, isso pode ser feito pelo servidor proxy em uma tabela de transparência de fonte. Isso identifica o estabelecimento de sessão (por exemplo, estabelecimento de sessão de MBX) entre o dispositivo de usuário final e o servidor proxy. Em algumas modalidades, a tabela de transparência de fonte pode ser denominada, por exemplo, como uma tabela de transparência de fonte de camada 3 (L3ST).

[0059] Na operação 740, o dispositivo de usuário final envia solicitações (comunicações) para o servidor proxy. Em resposta, o servidor proxy cria uma interface virtual com uso do endereço de IP do dispositivo de solicitação de usuário final (ou uma variante do mesmo), e usa aquela interface virtual para encaminhar aquelas solicitações para o servidor de web designado. Isso é ilustrado nas operações 742 e 744. Isso pode ser feito, por exemplo, diretamente para um roteador de tradução de endereço de rede (NAT) na rede de área local virtual apropriada (VLAN) (que pode ser a mesma que aquela na qual a solicitação de HTTP entrou).

[0060] Tendo, desse modo, descrito um exemplo para comunicar solicitações ou mensagens com o uso de transparência de fonte entre o dispositivo de usuário final em um servidor de web, um processo exemplificativo para comunicar a resposta é, agora, descrito. Particularmente, a Figura 8 é um diagrama que ilustra um exemplo para rotear uma resposta a uma solicitação enviada com o uso de transparência de endereço de IP de fonte, de acordo com uma modalidade dos sistemas e métodos descrita no presente documento. Em referência, agora, à Figura 8, na operação 842, a porta de comunicação de IP recebe o tráfego de web do servidor de web em resposta a uma solicitação enviada por um dispositivo de usuário final. Na operação 844, a porta de comunicação de IP determina se a comunicação é em resposta a uma solicitação que foi enviada pelo servidor proxy. Isso pode ser determinado, por exemplo, verificando-se a tabela L4ST para observar se a comunicação está listada na tabela. Se não estiver, na operação 860, a porta de comunicação de IP envia o pacote para o dispositivo de usuário final, sem processar pelo servidor proxy.

[0061] Se, por outro lado, a comunicação for em resposta a uma solicitação que foi roteada através do servidor proxy, a porta de comunicação de IP roteia a resposta ao servidor proxy. Como parte desse roteamento, a porta de comunicação de IP pode verificar a tabela de transparência de fonte para garantir que a comunicação esteja listada na tabela. Isso pode ser feito verificando-se o endereço de IP de destino para a comunicação, a fim de observar se o mesmo está listado na tabela (ou, de outro modo, verifica-se para observar se a interface virtual existe para esse fluxo). Isso é ilustrado pelas operações 846 e 850. Se o endereço de IP para a comunicação estiver na tabela, a porta de comunicação de IP pode rotear a comunicação para o servidor proxy para tratar por meio da interface virtual. Isso é ilustrado na operação 854. Se, por alguma razão, a comunicação não estiver listada na tabela, a porta de comunicação pode descartar a comunicação, conforme mostrado na operação 864. O servidor proxy então, roteia a resposta para o dispositivo de usuário final pretendido com uso da interface virtual. Isso é ilustrado na operação 858.

[0062] A Figura 9 ilustra um sistema de computador 900, mediante o qual as modalidades exemplificativas, de acordo com a presente invenção podem ser implementadas. O sistema de computador 900 pode incluir um barramento 902 ou outro mecanismo de comunicação para comunicar informações, e um processador 904 acoplado ao barramento 902 para processar informações. O sistema de computador 900 também pode incluir memória principal 906, tal como uma memória de acesso aleatório (RAM), ou outro dispositivo de armazenamento dinâmico, acoplado ao barramento 902, para armazenar informações e instruções a serem executadas pelo processador 904. A memória 906 também pode ser usada para armazenar informações variáveis temporárias ou outras informações intermediárias durante a execução de instruções a serem executada pelo processador 904. O sistema de computador 900 pode, adicionalmente, incluir uma memória apenas de leitura (ROM) 908 ou outro dispositivo de armazenamento estático acoplado ao barramento 902 para armazenar as informações estáticas e as instruções para o processador 904. Um dispositivo de armazenamento 910, tal como um disco magnético ou disco óptico, pode adicionalmente ser acoplado ao barramento 902 para armazenar informações e instruções.

[0063] O sistema de computador 900 pode ser acoplado, por meio de barramento 902, a um visor 912, tal como um tubo de raio de cátodo (CRT), visor de cristal líquido (LCD), visor de matriz ativa, visor de diodo emissor de luz (LED) / LED orgânico (OLED), visor de processamento de luz digital (DLP) ou visor de plasma, para exibir informações para um usuário de computador. Um dispositivo de entrada 914, tal como um teclado, que incluem teclas alfanuméricas e outras teclas, pode ser acoplado ao barramento 902 para comunicar informações e comandar seleções para processador 904. Outro tipo de dispositivo de entrada de usuário é o controle de cursor 916, tais como um mouse, uma bola de deslocamento, ou teclas de direção de cursor, para comunicar as informações de direção e as seleções de comando para o processador 904 e para controlar o movimento de cursor sobre o visor 912.

[0064] De acordo com várias modalidades dos sistemas e métodos revelados no presente documento, os módulos funcionais descritos no presente documento, tal como, por exemplo, servidores proxy, portas de comunicação de IP, dispositivos de usuário final, servidores de web, e assim por diante, podem ser implementados com o uso de um ou mais sistemas de computação para implantar a funcionalidade descrita no presente documento, bem como outra funcionalidade que pode ser realizada pelos vários dispositivos. Tal funcionalidade pode ser fornecida, de acordo com as modalidades exemplificativas, pelo sistema de computador 900 em resposta ao processador 904 que executa uma disposição de instruções contidas na memória principal 906. Tais instruções podem ser lidas na memória principal 906 a partir de outro meio legível por computador, tal como o dispositivo de armazenamento 910. A execução da disposição de instruções contidas na memória principal 906 faz com que o processador 904 realize um ou mais processos descritos no presente documento. Um ou mais processadores em uma disposição de múltiplos processamentos também podem ser empregados para executar as instruções contidas na memória principal 906. Em modalidades alternativas, o conjunto de circuitos conectados por cabo é usado no lugar ou em combinação com as instruções de software para implantar várias modalidades. Desse modo, as modalidades descritas na presente revelação não são limitadas a nenhuma combinação específica de software e de conjunto de hardware.

[0065] O sistema de computador 900 também pode incluir uma interface de comunicação 918 acoplada ao barramento 902. A interface de comunicação 918 pode fornecer uma comunicação de dados de duas vias que se acopla a um enlace de rede 920 conectado a uma rede local 922. A título de exemplo, a interface de comunicação 918 pode ser um modem ou um cartão de linha de assinante digital (DSL), um cartão de rede digital de serviços integrados (ISDN), um modem a cabo, ou um modem de telefone para fornecer uma conexão de comunicação de dados para um tipo correspondente de linha de telefone. Conforme outro exemplo, a interface de comunicação 918 pode ser um cartão de rede de área local (LAN) (por exemplo, para Ethernet™ ou uma rede de Modelo de Transferência Assíncrono (ATM)) para fornecer uma conexão de comunicação de dados para uma LAN compatível. Os enlaces sem fio também podem ser implementados. Em qualquer implantação, a interface de comunicação 918 envia e recebe sinais elétricos, eletromagnéticos ou ópticos que transportam fluxos de dados digitais que representam vários tipos de informações. Adicionalmente, a interface de comunicação 918 pode incluir dispositivos de interface periférica, tal como uma interface de Barramento em Série Universal (USB), uma interface de PCMCIA (Associação Internacional de Cartão de Memória de Computador Pessoal), etc.

[0066] O enlace de rede 920 fornece tipicamente comunicação de dados através de uma ou mais redes para outros dispositivos de dados. A título de exemplo, o enlace de rede 920 pode fornecer uma conexão através de rede local 922 para um computador hospedeiro 924, que tem conectividade com uma rede 926 (por exemplo, uma rede de área ampla (WAN) ou com a rede de comunicação de dados de pacote global, atualmente denominada, comumente, como a “Internet”) ou com equipamento de dados operado pelo provedor de serviço. A rede local 922 e a rede 926 podem, ambas, usar sinais elétricos, eletromagnéticos ou ópticos para transportar informações e instruções. Os sinais através das várias redes e dos sinais no enlace de rede 920 e através da interface de comunicação 918, que comunicam dados digitais com o sistema de computador 900, são formas exemplificativas de ondas de transportador que portam as informações e instruções.

[0067] O sistema de computador 900 pode enviar mensagens e receber dados, que incluem código de programa, através da rede (ou redes), enlace de rede 920 e interface de comunicação 918. No exemplo de Internet, um servidor (não mostrado) pode transmitir o código solicitado que pertence a um programa de aplicação para implantar uma modalidade da presente invenção, através da rede 926, da rede local 922 e da interface de comunicação 918. O processador 904 executa o código transmitido, enquanto é recebido e/ou armazena o código no dispositivo de armazenamento 910, ou outro armazenamento não volátil para execução posterior. Dessa maneira, o sistema de computador 900 obtém o código de aplicação na forma de uma onda transportadora.

[0068] O termo “meio legível por computador”, conforme usado no presente documento, refere-se a qualquer meio que participe no fornecimento de instruções para o processador 904 para execução. Tal meio pode obter muitas formas, incluindo, mas sem limitação, meios não voláteis, meios voláteis e meios de transmissão. Os meios não voláteis incluem, por exemplo, discos ópticos ou magnéticos, tais como dispositivo de armazenamento 910. Os meios voláteis podem incluir memória dinâmica, tal como memória principal 906. Os meios de transmissão incluem cabos coaxiais, fios de cobre e fibras ópticas, que incluem os fios que compreendem o barramento 902. Os meios de transmissão também podem obter a forma de ondas acústicas, ópticas ou eletromagnéticas, tais como aquelas geradas durante as comunicações de dados por infravermelho (IV) ou por radiofrequência (RF). As formas comuns de meios legíveis por computador incluem, por exemplo, um disquete, um disco flexível, disco rígido, fita magnética, qualquer outro meio magnético, um CD ROM, CDRW, DVD, qualquer outro meio óptico, cartões de perfuração, fita de papel, folhas de marcação óptica, qualquer outro meio físico com padrões de orifícios ou outros indícios opticamente reconhecíveis, uma RAM, uma PROM e EPROM, uma FLASH EPROM, qualquer outro cartucho ou chip de memória, uma onda transportadora, ou qualquer outro meio a partir do qual um computador possa ler.

[0069] Várias formas de meios legíveis por computador podem estar evolvidas no fornecimento de instruções para um processador para execução. A título de exemplo, as instruções para realizar pelo menos parte da presente invenção podem, inicialmente, ser portadas em um disco magnético de um computador remoto. Em tal cenário, o computador remoto carrega as instruções para a memória principal e envia as instruções através de uma linha de telefone com o uso de um modem. Um modem de um sistema de computador local recebe os dados na linha de telefone e usa um transmissor de infravermelho para converter os dados para um sinal de infravermelho e transmitir o sinal de infravermelho para um dispositivo de computação portátil, tal como uma assistência digital pessoal (PDA) e um computador do tipo laptop. Um detector de infravermelho no dispositivo de computação portátil recebe as informações e as instruções portadas pelo sinal de infravermelho e coloca os dados em um barramento. O barramento transporta os dados para a memória principal, a partir da qual um processador recupera e executa as instruções. As instruções recebidas pela memória principal podem, opcionalmente, ser armazenadas no dispositivo de armazenamento antes ou após a execução pelo processador.

[0070] A Figura 10 ilustra um conjunto de chips 930 no qual as modalidades da invenção podem ser implementadas. O conjunto de chips 930 pode incluir, por exemplo, componentes de processador e de memória, descritos em relação à Figura 10, incorporados em um ou mais pacotes físicos. A título de exemplo, um pacote físico inclui uma disposição de um ou mais materiais, componentes e/ou fios em um conjunto estrutural (por exemplo, uma placa-base) para fornecer uma ou mais características, tais como resistência física, conservação de tamanho e/ou limitação de interação elétrica.

[0071] Em uma modalidade, o conjunto de chips 930 inclui um mecanismo de comunicação, tal como um barramento 932, para passar informações dentre os componentes do conjunto de chips 930. Um processador 934 tem conectividade com o barramento 932 para executar instruções e processar informações armazenadas em uma memória 936. O processador 934 inclui um ou mais núcleos de processamento com cada núcleo configurado para realizar independentemente. Um processador de múltiplos núcleos possibilita o multiprocessamento dentro de um único pacote físico. Os exemplos de um processador de múltiplos núcleos incluem dois, quatro, oito, ou mais números de núcleos de processamento. Alternativamente, ou além disso, o processador 934 inclui um ou mais microprocessadores configurados duplamente por meio de barramento 932 para possibilitar a execução independente de instruções, canalização e multiencadeamento. O processador 932 também pode ser acompanhado de um ou mais componentes especializados para realizar certas funções e tarefas de processamento, tais como um ou mais processadores de sinal digital (DSP) 938 e/ou um ou mais circuitos integrados de aplicação específica (ASIC) 940. O DSP 938 pode tipicamente ser configurado para processar sinais do mundo real (por exemplo, som) em tempo real, independentemente do processador 1004. Similarmente, o ASIC 940 pode ser configurado para funções especializadas realizadas, não facilmente realizadas por um processador com propósito geral. Outros componentes especializados para ajudar na realização de funções inventivas descritas no presente documento incluem uma ou mais matrizes de porta programável em campo (FPGA) (não mostradas), um ou mais controladores (não mostrados), ou um ou mais outros chips de computador com propósito especial.

[0072] O processador 994 e os componentes anexos têm conectividade com a memória 936 por meio de barramento 932. A memória 936 inclui tanto memória dinâmica (por exemplo, RAM) quanto memória estática (por exemplo, ROM) para armazenar instruções executáveis que, quando executadas pelo processador 994, DSP 938 e/ou ASIC 940, realizam o processo das modalidades exemplificativas, conforme descrito no presente documento. A memória 1006 também armazena os dados associados ou gerados pela execução do processo.

[0073] Conforme usado no presente documento, o termo módulo pode descrever uma dada unidade de funcionalidade que pode ser realizada de acordo com uma ou mais modalidades do presente pedido. Conforme usado no presente documento, um módulo pode ser implementado com a utilização de qualquer forma de hardware, software, ou uma combinação dos mesmos. Por exemplo, um ou mais processadores, controladores, ASICs, PLAs, PALs, CPLDs, FPGAs, componentes lógicos, rotinas de software ou outros mecanismos, podem ser implementados para produzir um módulo. Na implantação, os vários módulos descritos no presente documento podem ser implementados como módulos distintos ou as funções e recursos descritos podem ser compartilhados em parte ou na totalidade dentre um ou mais módulos. Em outras palavras, conforme seria evidente para uma pessoa de habilidade comum na técnica, após ler esta descrição, os vários recursos e funcionalidade descritos no presente documento podem ser implementados em qualquer dada aplicação e podem ser implementados em um ou mais módulos compartilhados ou separados em várias combinações e permutações. Ainda que vários recursos ou elementos de funcionalidade possam ser individualmente descritos ou reivindicados como módulos separados, uma pessoa de habilidade comum na técnica irá compreender que esses recursos e funcionalidade podem ser compartilhados dentre um ou mais elementos de software e hardware comuns, e tal descrição não deve exigir ou implicar em que os componentes hardware ou software separados sejam usados para implantar tais recursos ou funcionalidade.

[0074] Onde os componentes ou módulos do pedido são implementados, na totalidade ou em parte, com o uso de software, em uma modalidade, esses elementos de software podem ser implementados para operar com um módulo de processamento ou de computação com capacidade para realizar a funcionalidade descrita, em relação no mesmo. Um tal módulo de computação exemplificativo é mostrado na Figura 3. Várias modalidades são descritas em termos desse módulo de computação exemplificativo 300. Após ler esta descrição, irá se tornar evidente para uma pessoa versada na técnica relevante como implantar a aplicação com o uso de outros módulos ou arquiteturas de computação.

[0075] Embora descrita acima em termos de várias modalidades e implantações exemplificativas, deve ser compreendido que os vários recursos, aspectos e funcionalidade descritos em uma ou mais das modalidades individuais não são limitados, em sua aplicabilidade, à modalidade particular com a qual os mesmos são descritos, mas, em vez disso, podem ser aplicados, sozinhos ou em várias combinações, a uma ou mais das outras modalidades da invenção, se tais modalidades forem descritas ou não e se os recursos forem apresentados como sendo parte de uma modalidade descrita ou não. Desse modo, a amplitude e o escopo da presente invenção não devem ser limitados por nenhuma das modalidades exemplificativas descritas acima.

[0076] Os termos e expressões usados neste pedido, e as variações dos mesmos, a menos que expressamente declarado de outro modo, devem ser interpretados como sem limitação em oposição a limitante. Como exemplos do que foi mencionado anteriormente: o termo “incluir” deve ser lido como significando “incluindo, sem limitação” ou similares; o termo “exemplo” é usado para fornecer casos exemplificativos do item em discussão, não uma lista exaustiva ou limitante dos mesmos; os termos “um” ou “uma” devem ser lidos como significando “pelo menos um", “um ou mais” ou similares; e os adjetivos como “convencional", “tradicional", “normal", “padrão", “conhecido” e termos de significado semelhante não devem ser interpretados como limitantes do item descrito para um dado período de tempo ou para um item disponível como de um dado tempo, mas, em vez disso, deve ser lido de modo a abranger as tecnologias convencionais, tradicionais, normais, ou padrão que podem estar disponíveis ou ser conhecidas agora ou em qualquer momento no futuro. Da mesma forma, quando este documento se refere às tecnologias que seriam evidentes ou conhecidas para uma pessoa de habilidade comum na técnica, tais tecnologias abrangem aquelas evidentes ou conhecidas para o técnico versado agora ou em qualquer momento no futuro. O uso do termo “módulo” não implica que os componentes ou a funcionalidade descrita ou reivindicada como parte do módulo estejam todos configurados em um pacote comum. Certamente, qualquer um ou todos dentre os vários componentes de um módulo, se componentes de controle de lógica ou outros componentes, podem ser combinados em um único pacote ou ser mantidos separadamente, e podem adicionalmente ser distribuídos em múltiplos agrupamentos ou pacotes ou através de múltiplos locais.

[0077] Adicionalmente, as várias modalidades apresentadas no presente documento são descritas no que se refere aos diagramas de blocos, fluxogramas e outras ilustrações exemplificativas. Como será evidente para um indivíduo de habilidade comum na técnica após a leitura deste documento, as modalidades ilustradas e suas várias alternativas podem ser implementadas sem se limitar aos exemplos ilustrados. Por exemplo, os diagramas de blocos e sua descrição conjunta não devem ser interpretados como exigindo uma arquitetura ou configuração particular.

Claims (16)

1. Método para implementar transparência de endereço de IP de fonte em uma rede de comunicação que compreende um servidor proxy (244, 460), caracterizado pelo fato de que compreende; o servidor proxy (244, 460) receber um fluxo de tráfego de um dispositivo de usuário final (132, 442) e determinar um endereço de IP de fonte do dispositivo de usuário final (132, 422) usado pelo fluxo de tráfego detectado; o servidor proxy (244, 460) determinar que o endereço de IP de fonte não existe em uma tabela de interface virtual, em que a tabela de interface virtual é configurada para ser povoada com interfaces virtuais, em que a cada uma das interfaces virtuais é atribuído um endereço de IP de fonte correspondente a um respectivo dispositivo de usuário final (132, 442); em resposta a determinar que um endereço de IP de fonte não existe na tabela de interface virtual, o servidor proxy (244, 460) criar uma interface virtual (250) correspondente ao dispositivo de usuário final (132, 442) a partir do qual o fluxo de tráfego foi recebido e com uso da interface virtual (250) para aquele dispositivo de usuário final (132, 442) para trocar dados entre o dispositivo de usuário final (132, 442) e um servidor de web designado (138, 465), em que a interface virtual (250) compreende uma representação lógica de uma interface de rede; o servidor proxy (244, 460) designar um endereço de IP de fonte à interface visual (250) criada que é a mesma que ou está na mesma sub-rede que o endereço de IP de fonte para o dispositivo de usuário final (132, 442), em que o servidor proxy (244, 460) e o dispositivo de usuário final (132, 442) são configurados para estabelecer uma conexão por meio de um protocolo de comunicação dedicado, de modo que uma marca temporal (timestamp) seja mantida como parte do protocolo, externa à tabela de interface virtual, para realizar o rastreamento de tempo ocioso da conexão para terminar a interface virtual (250); a interface virtual (250) enviar o fluxo de tráfego para o servidor de web designado (138, 465) com o uso do endereço de IP de fonte.

2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de receber um fluxo de tráfego de um dispositivo de usuário final (132, 442) compreende receber o fluxo de tráfego no servidor proxy (244, 460) em uma LAN virtual (VLAN).

3. Método, de acordo com a reivindicação 2, caracterizado pelo fato de que enviar o fluxo de tráfego para o servidor de web designado (138, 465) compreende obter o fluxo de tráfego a partir da interface virtual (250) e rotear o fluxo na VLAN.

4. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o endereço de IP de fonte da interface virtual (250) compreende um endereço virtual que é vinculado a uma interface de enlace de retorno do servidor proxy (244, 460).

5. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o servidor proxy (244, 460) determinar uma interface virtual (250) correspondente ao dispositivo de usuário final (132, 442) compreende o servidor proxy (244, 460) buscar uma memória virtual de interface com o uso do endereço de IP de fonte determinado para determinar se uma interface virtual (250) existe para o dispositivo de usuário final (132, 442).

6. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende adicionalmente o servidor proxy (244, 460) receber uma resposta ao fluxo de tráfego a partir do servidor de web designado (138, 465) e rotear a resposta para o dispositivo de usuário final (132, 442).

7. Método, de acordo com a reivindicação 6, caracterizado pelo fato de que compreende adicionalmente o servidor proxy (244, 460) mudar uma identificação de porta de fonte na resposta a uma porta de fonte do servidor proxy (244, 460).

8. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o servidor proxy (244, 460) receber um fluxo de tráfego de um dispositivo de usuário final (132, 442) compreende receber o fluxo de tráfego por meio de uma porta de comunicação de IP (252, 454), e em que o método compreende adicionalmente a porta de comunicação de IP (252, 454) receber o fluxo de tráfego e determinar se o fluxo de tráfego deve ser tratado com o uso de transparência de endereço de IP de fonte.

9. Método, de acordo com a reivindicação 8, caracterizado pelo fato de que determinar se o fluxo de tráfego deve ser tratado com o uso de transparência de endereço de IP de fonte compreende determinar uma porta de destino para o fluxo de tráfego designado pelo dispositivo de usuário final (132, 442).

10. Método, de acordo com a reivindicação 9, caracterizado pelo fato de que uma gama de portas de destino identifica uma conexão transparente de endereço de IP de fonte.

11. Método, de acordo com a reivindicação 8, caracterizado pelo fato de que compreende adicionalmente a porta de comunicação de IP que cria um mapeamento de endereço de IP entre o dispositivo de usuário final e o servidor proxy (244, 460).

12. Método, de acordo com a reivindicação 6, caracterizado pelo fato de que o servidor proxy (244, 460) receber uma resposta ao fluxo de tráfego do servidor de web designado (138, 465) compreende receber a resposta por meio de uma porta de comunicação de IP, e em que o método compreende adicionalmente a porta de comunicação de IP receber a resposta e determinar se a resposta deve ser roteada para o servidor proxy (244, 460) ou se a resposta deve se desviar do servidor proxy (244, 460).

13. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a interface virtual (250) correspondente ao dispositivo de usuário final (132, 442) compreende uma representação lógica de uma interface de rede que tem um endereço de IP de fonte que é o mesmo que o endereço de IP de fonte do dispositivo de usuário final correspondente (132, 442).

14. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que estabelecer a conexão por meio de um protocolo de comunicação dedicado envolve o estabelecimento de uma sessão entre o servidor proxy (244, 460) e o dispositivo do usuário final (132, 442).

15. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o protocolo de comunicação dedicado é um protocolo de troca de bloco multiplexada (MBX).

16. Sistema de rede que implementa transparência de endereço de IP de fonte para comunicações entre um dispositivo de usuário final e um servidor, sendo que o sistema é caracterizado pelo fato de que compreende: um dispositivo de computação compreendendo um servidor proxy (244, 460), o servidor proxy (244, 460) compreendendo uma tabela de interface virtual que compreende uma pluralidade de interfaces virtuais, em que a cada uma da pluralidade de interfaces virtuais (250) é atribuído um endereço de IP de fonte associado com o respectivo dispositivo de usuário final (132, 442), o servidor proxy (244, 460) configurado para realizar as operações que compreendem: receber um fluxo de tráfego de um dispositivo de usuário final (132, 442) e determinar um endereço de IP de fonte do dispositivo de usuário final (132, 442) usado pelo fluxo de tráfego detectado; criar uma interface virtual (250) correspondente ao dispositivo de usuário final (132, 442) a partir do qual o fluxo de tráfego foi recebido, em que a interface virtual (250) compreende uma representação lógica de uma interface de rede; atribuir um endereço de IP de fonte à interface virtual criada (250) que é o mesmo que ou está na mesma sub-rede que o endereço de IP de fonte para o dispositivo de usuário final (132, 442), em que o servidor proxy (244, 460) e o dispositivo de usuário final (132, 442) são configurados para estabelecer uma conexão por meio de um protocolo de comunicação dedicado, de modo que uma marca temporal seja mantida como parte do protocolo, externo à tabela de interface virtual, para realizar o rastreamento de tempo ocioso da conexão para terminar a interface virtual (250); e enviar, por meio da interface virtual (250) criada, o fluxo de tráfego para um servidor de web designado com o uso do endereço de IP de fonte atribuído.