BR112017006261B1 - Método para endereçamento múltiplo sensível a aplicativo para aceleração de tráfego de dados em redes de comunicação de dados - Google Patents

Abstract

ENDEREÇAMENTO MÚLTIPLO SENSÍVEL A APLICATIVO PARA ACELERAÇÃO DE TRÁFEGO DE DADOS EM REDES DE COMUNICAÇÃO DE DADOS. É proposto um método para endereçamento múltiplo sensível a aplicativo com protocolo de tunelamento de trajetos múltiplos. Um pacote de dados de cliente de mensagem é classificado com base em aplicativo a partir do qual é originado o pacote de dados. A estrutura do cabeçalho do pacote de dados é modificada para gerar um pacote de dados de proxy compreendendo o payload de dados de cliente e uma estrutura de proxy de cliente, parâmetros de protocolo indicando um sequenciamento.

Description

ANTECEDENTES

[001] O protocolo de controle de transmissão (TCP) é o protocolo dominante em uso hoje em dia na Internet. TCP é transportada pelo protocolo de Internet (IP) e é usado em uma variedade de aplicativos que incluem a transferência de arquivo confiável e aplicativos de navegador de rede da Internet. A Camada de Portas Seguras (Secure Sockets Layer - SSL) e a Segurança da Camada de Transporte (Transport Layer Security - TLS) são protocolos criptográficos projetados para proporcionar segurança de comunicação através das redes publicas, tais como a Internet. O protocolo SSL é o protocolo dominante para comunicações de rede segura, tais como as comunicações seguras pela Internet. A principal função do protocolo SSL consiste em prover privacidade, segurança e confiabilidade entre dois aplicativos de comunicação. A privacidade e segurança são providas através da criptografia da conexão e da autenticação da identidade baseada em certificados, ao passo que a confiabilidade é provida por meio de manutenção confiável de uma conexão segura através da verificação da integridade da mensagem. Como tal, o protocolo SSL envolve uma troca de mensagens intensiva para estabelecer e manter conexão ou sessão.

[002] A Força Tarefa de Engenharia da Internet (IETF) criou o protocolo TLS em uma tentativa de padronizar SSL dentro da comunidade da Internet. O protocolo TLS foi projetado para facilitar os aplicativos cliente/servidor para se comunicarem com segurança de modo a evitar escutas, violação ou falsificação de mensagens. Tal como ocorre com SSL, o protocolo TLS exige o estabelecimento inicial de uma conexão ou sessão de TLS entre o cliente e o servidor. Mais especificamente, uma vez tendo sido acordado entre o cliente e o servidor a quantidade usada de TLS, eles negociam uma conexão dinâmica usando um procedimento de aperto de mão, durante o qual o cliente e o servidor acordam sobre parâmetros diversos usados para estabelecer a segurança da conexão. Consequentemente, tal como ocorre com SSL, o protocolo TLS envolve uma troca intensiva de mensagens e de apertos de mãos para estabelecer e manter a conexão ou sessão.

[003] O Protocolo de Transferência de Hipertexto (HTTP) é um protocolo de camada de aplicativo para sessões de informações de hipermídia distribuídas, colaborativas, que serve como o fundamento para comunicações de dados de camada de aplicativo pela Internet. O hipertexto é um texto estruturado que usa enlaces lógicos (hiper-enlaces) entre nodos que contendo, e HTTP serve como o protocolo para a troca ou transferência de hipertexto. O Protocolo Seguro de Transferência de Hipertexto (HTTPS) é o protocolo de comunicação para comunicação segura usando o protocolo HTTP. HTTPS consiste na camada de HTPP sobre o protocolo SSL/TLS, acrescentando assim as capacidades de SSL/TLS às comunicações de HTTP. A segurança de HTTPS consiste, portanto, na de TLS subjacente que utiliza chaves públicas e secretas a longo prazo para trocar uma chave de sessão de curto prazo para criptografar o fluxo de dados entre o cliente e o servidor. Levando-se em conta o estabelecimento, conservação e troca de mensagens de chave intensivos dos protocolos TCP, SSL/TLS e HTPP/HTTPS, estes protocolos podem sofrer uma degradação significativa de desempenho em uma rede alto nível de latência (uma rede gorda longa (LFN), por exemplo, tal como uma rede por satélite). Em uma LFN, o volume de transmissão de TCP, por exemplo, se degrada devido ao controle de congestionamento por TCP, SSL/TLS sofre de um atraso elevado de estabelecimento de sessão, e HTTP tem um grande tempo ocioso entre uma solicitação e uma resposta.

[004] Uma LFN típica é a rede de satélite que provê uma grande capacidade de conexão, mas apresenta uma grande latência das mensagens devido ao longo percurso dos sinais entre um terminal em terra e uma órbita de satélite (uma órbita geoestacionária, por exemplo). Devido à longa distância entre um terminal em terra e um satélite em uma órbita geoestacionária, uma rede de satélite geossincrônica típica tem um grande atraso de propagação entre um terminal de usuário (Terminal de Abertura Muito Pequena (VSAT), por exemplo) e o gateway central de satélite (aproximadamente 240-270 ms, por exemplo, de atraso de propagação para um percurso só de ida para/do satélite). Assim, um tempo de percurso de ida e volta típico (RTT) para tal rede é superior a 480-540 ms. Além disso, os canais à montante de um sistema de satélite são compartilhados por muitos VSATs e assim sofrem da contenção de acesso. Para resolver a contensão da rede do meio à montante entre VSATs e para aumentar a qualidade de serviço são tipicamente empregados algoritmos de Largura de Banda por Demanda (BoD) para a alocação de recursos de rede nas redes de satélite. Quando uma unidade VSAT recebe pacotes de um cliente, ela envia uma solicitação de largura de banda correspondente de um centro de controle de rede (NOC) ou gateway, e o NOC responde uma alocação de slots de canal para preencher a solicitação de largura de banda. A negociação para lá e para cá entre o VSAT e o NOC acrescenta assim RTTs adicionais ao processo de comunicação. Assim, leva pelo menos três atrasos de propagação (720-810 ms) para enviar um pacote de VSAT à gateway.

[005] Para superar a degradação do volume de transmissão de TCP em LFNs, foram desenvolvidos proxies que melhoram o desempenho (PEP) a vem sendo usados durante uma década agora. Veja, por exemplo, J. Border et al., “Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations”, IETF RFC 3135, junho de 2001. Em algumas redes de satélite de banda larga, PEP pode ser a função da rede principal. Em redes de satélites, os proxies de PEP podem estar localizados tanto no gateway do satélite como nos locais distantes do terminal de usuário, permitindo que os remetentes de TCP rapidamente preencham o enlace de alta capacidade. O PEP da camada de transporte (PEP de TCP, por exemplo), por exemplo, no gateway imita mensagens de reconhecimento (ACKs) para reduzir o tempo de espera para ACKs no remetente, e usa um grande tamanho de janela para preencher o enlace. Além disso, HTTP é baseado em um processo de solicitação e resposta (uma solicitação de página da web e uma resposta do conteúdo da página da web, por exemplo). Com um enlace de atraso de propagação elevado (um enlace por satélite, por exemplo) o processo de solicitação-resposta provoca atrasos grandes no carregamento da página da web. Para resolver tais problemas de latência em LFNs, há muito vêm sendo empregados mecanismos de busca prévia de HTTP. Antes que o navegador da web chegue a solicitar os objetos embutidos de um site da web, por exemplo, um servidor de proxy de HTTP no gateway antecipa tais solicitações analisando as páginas de HTML, fazendo uma busca prévia pelos objetos embutidos e os empurra para um cliente de proxy de HTTP no terminal do satélite do usuário. Servindo os objetos que estão no cache ao terminal de satélite, fica reduzido o tempo de resposta. Embora um LFN funcione relativamente bem com a navegação da web usando PEP de TCP e a busca prévia de HTTP, continuam os problemas com a latência quando se acessam sites seguros da web. A maioria dos sites seguros da web (sites da web do e-comércio e sites de e-mail da web) proporcionam uma segurança de canal usando HTTP através de SSL/TLS (HTTPS). Com HTTPS, como o conteúdo da web está criptografado, o servidor de proxy de HTTP não pode ler e analisar o conteúdo criptografado da web. Portanto o mecanismo de busca prévia de HTTP por sites seguros da web não pode ser usado para sites da web seguros. Além disso, SSL/TLS introduz um atraso adicional para o estabelecimento da sessão. O estabelecimento completo de sessão de SSL/TLS exige dois tempos de ida e volta (RTTs) o que introduz uma latência significativa e outros problemas nas LFNs.

[006] Outras abordagens foram desenvolvidas para resolver a degradação do desempenho do tráfego SSL através das redes de satélite. De acordo com tal abordagem (Ponte SSL - veja, por exemplo, a patente U.S. No. 7.584.500), servidores de proxy operam como um servidor de proxy de HTPP distribuído com capacidades de HTTPS, mantendo os servidores de proxy deste modo a proteção SSL de comunicação entre o navegador e o servidor, e buscam previamente documentos seguros por meio de solicitações de conteúdo seguro reescritas. Mais especificamente, Ponte SSL é baseada na divisão de uma sessão SSL fim-a-fim em três sessões: uma sessão entre um cliente e um de proxy em VSAT e um de proxy no gateway de IP de satélite, e a última sessão entre um de proxy no gateway de IP e um servidor da web. Como um proxy no gateway cria uma sessão SSL para um servidor da web, ele pode descriptografar os objetos da web e analisar o arquivo de HTML e podem, deste modo, conduzir a busca prévia em HTPP no gateway. Usando esta abordagem, no entanto terceiros (provedores de serviços de internet por satélite, por exemplo) têm acesso a dados seguros e assim a ponte SSL não é uma abordagem aceitável para proporcionar uma segurança fim-a-fim.

[007] Uma outra abordagem (SSL de Modo Duplo ou DSSL - veja A. Roy-Chowdhury et al., “Security Issues in Hybrid Networks with a Satellite Component” IEEE Wireless Comunications, dezembro de 2005) é baseada na criptografia de modo duplo de páginas da web. De acordo com esta abordagem, a conexão segura tem dois modos - uma conexão em modo principal fim-a-fim entre o cliente e o servidor da web, e uma conexão de modo secundário que tem o proxy de HTTP de hub como um nó intermediário. Um cliente e um servidor da web têm duas chaves (K1 e K2) para a criptografia, mas os proxies no terminal de usuário e no gateway têm somente uma chave (K2). A chave K1 é usada para criptografar a página da web toda e a chave K2 é usada para criptografar os enlaces dos objetos embutidos da página. Assim, os servidores da web devem inserir dois elementos de dados: enlaces do objeto e a página da web. O de proxy no gateway pode analisar os enlaces dos objetos usando a chave K2, de modo que ele possa previamente solicitar os objetos.Consequentemente, no entanto, a abordagem DSSL é mais complexa em comparação com SSL, pois ele exige a criação de uma conexão adicional e assim envolve custos adicionais para estabelecer e manter essa conexão. Além disso, os servidores da web analisam o arquivo de HTLM e analisam os enlaces dos objetos e os terceiros (o proxy no gateway, por exemplo) podem ler os enlaces de objetos, e, portanto, DSSL de modo análogo não pode proporcionar uma segurança completa de uma extremidade à outra.

[008] De acordo com uma outra abordagem (TCP de caminhos múltiplos ou MPTCP - veja, por exemplo, Ford et al., “TCP Extensions for Multipath Operation with Multiple Addresses, IETF RFC-6824, janeiro de 2013), uma única sessão de transmissão de TCP é provida através de uma multiplicidade de caminhos ou enlaces (conforme empregado no presente, o termo “caminho” ou “caminhos” ou “enlace” ou “enlaces” são usados indiferentemente). Mais especificamente, uma conexão de TCP de caminhos múltiplos proporciona uma transmissão de bytes bidirecional entre dois anfitriões comunicando-se como TCP normal, o que permite que os anfitriões usem caminhos diferentes com diferentes endereços de IP para permutar pacotes que pertencem à conexão de MPTCP. Na camada de rede, cada sub-fluxo de MPTCP parece um fluxo de TCP regular cujos segmentos portam um novo tipo de opção de TCP, sendo, deste modo, uma nova opção de TCP usada para ID de conexão, números de sequência e números de ACK de sub-fluxos. MPTCP proporciona um benefício de confiabilidade e um volume maior de transmissão, no entanto, ele pode apresentar problemas de compatibilidade com caixas intermediárias ou proxies. Tais caixas intermediárias podem reescrever cabeçalhos de TCP e omitir opões de TCP desconhecidas (Veja, por exemplo, Raiciu et al., “How Hard Can it Be? Designing and Implementing a Deployable Multipath TCP”, Protocolos de NSDI, San Jose, CA, abril de 2012). PEP termina conexões de TCP, por exemplo, e assim MPTCP não seria compatível com proxies de PEP. Mesmo que PEP encaminhe a opção de MPTCP, se o proxy de PEP não implementar a funcionalidade de MPTCP (não proporciona ACKs de dados de MPTCP, por exemplo), a conexão poderá ser rompida.

[009] O TCP de Conexões Múltiplas (MCTCP - veja, por exemplo, Scharf, “Multi-Connection TCP (MCTCP) Transport, IETF, projeto de Internet, julho de 2010) e Transporte de Conexões Múltiplas de Payload (PLMT - veja, por exemplo, Singh et al., Payload Multi-Connection Transport Using Multiple Addresses” IETF, projeto de Internet, agosto de 2010) propõem outras versões de MPTCP, em que, em vez da opção de TCP, eles usam uma camada de calço (entre a camada de transporte e a camada de aplicação) para inserir informações de fluxo de múltiplos caminhos. MCTCP, no entanto, também usa a opção de TCP para apertos de mão de TCP para criar as conexões de caminhos múltiplos, e assim apresenta os mesmos problemas potenciais de incompatibilidade com caixas intermediárias. Além disso, tanto MCTCP e PLMT exigem conexões adicionais para modos de conexões múltiplas, o que aumenta os custos para o estabelecimento e a conservação de tais conexões adicionais. As conexões adicionais são críticas em LFNs, especialmente em redes de satélite cujo RTT pode ser superior a 700 ms. Devido a estas conexões adicionais para cada fluxo, elas não são úteis para fluxos curtos de TCP.

[010] Redes híbridas terrestres e de satélite também foram desenvolvidas (Veja, por exemplo, Arora et al., “Asymmetric Internet Access Over Satellite-Terrestrial Networks”, Protocolos de AIAA International Communications Satellite Systems Conference, fevereiro de 1996). De acordo com tal rede híbrida um terminal híbrido proporciona duas interfaces de rede, sendo uma para conexão a um terminal de satélite de recepção somente e sendo a outra para uma conexão de saída para um modem terrestre. Esta abordagem híbrida fornece todo o upload ou tráfego de entrada através do modem/rede terrestre e recebe todo o download ou o tráfego de saída através da rede de satélite. Devido aos caminhos definidos para cada direção, no entanto, este sistema apresenta problemas com o desempenho e o uso de grande volume de dados das redes terrestres. Algumas mensagens de estabelecimento de sessão (tais como as mensagens de alô do servidor de SSL), por exemplo, são enviadas através da rede de satélite, resultando em atrasos de estabelecimento de sessão maiores. Além disso, a rede terrestre é submetida a um uso pesado de dados (com um gasto correspondentemente elevado, por exemplo) com arquivos de upload grandes. Adicionalmente, o sistema híbrido usa tunelamento de IP, o que é incompatível com a divisão de um fluxo em dois caminhos (com tais fluxos divididos surge um problema com o furo de um número de sequência e um número de ACK).

[011] O que é necessário, portanto, são abordagens para endereçamento múltiplo sensível a aplicativo com protocolos de tunelamento de caminhos múltiplos para se voltar para o desempenho de protocolo de rede e para a degradação de transmissão de dados em redes longas e gordas (LFNs) e especialmente no caso de protocolos de redes seguros e transmissão de dados através de sessões de redes seguras.

ALGUMAS MODALIDADES EXEMPLARES

[012] Algumas modalidades da presente invenção se voltam com vantagem para exigência e necessidades citadas acima, assim como a outras, propondo abordagens para o endereçamento múltiplo sensível a aplicativo com protocolos de tunelamento de caminhos múltiplos para se voltar ao desempenho de protocolo de rede e para a degradação da transmissão de dados em redes longas e gordas (LFNs - redes de satélite com atrasos relativamente longos, por exemplo, tais como as redes de satélite geossincrônicas) e especialmente no caso de protocolos de rede segura e transmissão de dados através de sessões de redes seguras. De acordo com modalidades exemplares, esta abordagem um novo sistema de endereçamento múltiplo que propõe um caminho auxiliar de rede de baixa latência (LLN - tal como uma rede celular terrestre) em paralelo com os caminhos de LFN, que encaminha seletivamente o tráfego de dados através dos caminhos de LLN e de LFN para melhorar o desempenho de protocolos de rede e a transmissão de dados (em navegação segura na web, tal como HTTPS, por exemplo) e para facilitar o controle da quantidade usada de dados através das redes respectivas.

[013] De acordo com modalidades exemplares, é proposto um método para endereçamento múltiplo sensível a aplicativo com protocolos de tunelamento de caminhos múltiplos. Um dispositivo de proxy de cliente localizado em um nó de cliente de uma rede de comunicação de dados recebe um primeiro pacote de dados de cliente de um fluxo de dados de cliente fonte originando-se de um dispositivo de cliente fonte, compreendendo o primeiro pacote de dados de cliente um payload de dados de cliente e uma estrutura de cabeçalho de cliente baseada em um ou mais protocolos de comunicação de dados. Uma classificação de mensagens para o primeiro pacote de dados de cliente é determinada com base em um ou mais parâmetros baseados em aplicativo associados com um aplicativo do qual se originou o primeiro pacote de dados de cliente. A estrutura de cabeçalho de cliente do primeiro pacote de dados de cliente é modificada para gerar um pacote de dados de proxy de cliente compreendendo o payload de dados de cliente e uma estrutura de cabeçalho de proxy de cliente, compreendendo a estrutura de cabeçalho de proxy de cliente informações sobre o fluxo incluindo parâmetros de cliente fonte e servidor de destino e um identificador do dispositivo de proxy de cliente, um ou mais parâmetros de protocolo da estrutura de cabeçalho de cliente, indicando pelo menos um sequenciamento do protocolo de fonte do primeiro pacote de dados de clientes e parâmetros de um primeiro protocolo de comunicação de dados de proxy incluindo pelo menos um parâmetro de fonte do dispositivo de proxy de cliente e pelo menos um parâmetro de destino de um dispositivo de proxy de servidor localizado em um nó de servidor ou de gateway da rede de comunicação de dados. Um primeiro enlace de uma multiplicidade de enlaces de comunicação de rede é selecionado para a transmissão do pacote de dados de proxy de cliente ao dispositivo de proxy do servidor, sendo a seleção baseada na classificação de mensagens determinada do primeiro pacote de dados de cliente. O pacote de dados de proxy de cliente é transmitido ao dispositivo de proxy de servidor por meio do primeiro enlace de comunicação de rede, sendo o primeiro protocolo de comunicação de dados de proxy configurado para a transmissão do pacote de dados de proxy de cliente ao dispositivo de proxy de servidor por meio de uma conexão de protocolo respectiva através do primeiro enlace de comunicação de rede.

[014] De acordo com uma outra modalidade, o dispositivo de proxy de servidor recebe o pacote de dados de proxy de cliente. Um registro de fluxo de cliente é gravado em uma tabela de informação sobre o fluxo para o fluxo de dados de cliente fonte, incluindo o registro do fluxo de cliente os parâmetros do cliente fonte e do servidor de destino a partir das informações de fluxo da estrutura de cabeçalho de proxy de cliente, do identificador de dispositivo de proxy de cliente e do identificador de fonte do dispositivo de proxy de servidor específico ao registro de fluxo. A estrutura de cabeçalho de proxy de cliente do pacote de dados de proxy de cliente é modificada para gerar um segundo pacote de dados de cliente compreendendo o payload de dados de cliente e uma estrutura de cabeçalho de servidor de cliente, compreendendo a estrutura de cabeçalho de servidor de cliente compreende parâmetros de protocolo de transmissão de proxy de servidor que incluem os parâmetros do servidor de destino a partir das informações de fluxo da estrutura de cabeçalho de proxy de cliente, de um parâmetro de endereço de fonte do dispositivo de proxy de servidor, e do identificador da fonte do dispositivo de proxy do servidor. O segundo pacote de dados de cliente é transmitido a um dispositivo de servidor de destino.

[015] De acordo com uma outra modalidade, o dispositivo de servidor de destino recebe o segundo pacote de dados de cliente. É gerado um primeiro pacote de dados de servidor compreendendo um payload de dados de servidor que se refere ao primeiro pacote de dados de cliente e uma estrutura de cabeçalho de servidor baseada em um ou mais dos protocolos de comunicação de dados, compreendendo a estrutura de cabeçalho de servidor parâmetros de protocolo de comunicação de servidor incluindo um parâmetro de endereço de fonte do dispositivo de servidor de destino, o parâmetro de endereço de fonte do dispositivo de proxy de servidor, e o identificador de fonte de dispositivo de proxy de servidor. O primeiro pacote de dados de servidor é transmitido ao dispositivo de proxy de servidor.

[016] De acordo com uma outra modalidade, o dispositivo de proxy de servidor recebe o primeiro pacote de dados de servidor, uma classificação de mensagem para o primeiro pacote de dados de servidor é determinada com base em um ou mais parâmetros à base de aplicativo associados com um aplicativo do qual se originou o primeiro pacote de dados de servidor. O registro de fluxo de cliente é adquirido da tabela de informações sobre fluxo consultando-se o registro baseado no identificador de fonte do dispositivo de proxy de servidor incluído na estrutura de cabeçalho de servidor do primeiro pacote de dados de servidor. A estrutura de cabeçalho de servidor do primeiro pacote de dados de servidor é modificada para gerar um pacote de dados de proxy de servidor compreendendo o payload de dados de servidor e uma estrutura de cabeçalho de proxy de servidor, compreendendo a estrutura de cabeçalho de proxy de servidor informações provenientes do registro de fluxo de cliente incluindo os parâmetros do cliente fonte e do servidor de destino, indicando um ou mais parâmetros de protocolo da estrutura de cabeçalho de servidor pelo menos um sequenciamento de protocolo de fonte do primeiro pacote de dados de servidor, e incluindo os parâmetros de um segundo protocolo de comunicação de dados de proxy pelo menos um parâmetro de fonte do dispositivo de proxy de servidor e pelo menos um parâmetro de destino do dispositivo de proxy de cliente. Um segundo enlace da multiplicidade de enlaces de comunicação de rede é selecionado para a transmissão do pacote de dados de proxy de servidor ao dispositivo de proxy de cliente, sendo a seleção baseada na classificação determinada da mensagem do primeiro pacote de dados de servidor. O pacote de dados de proxy de servidor é transmitido ao dispositivo de proxy de cliente por meio do segundo enlace de comunicação de rede, sendo o segundo protocolo de comunicação de dados de proxy configurado para a transmissão do pacote de dados de proxy de servidor ao dispositivo de proxy de cliente por meio da conexão de protocolo respectiva através do segundo enlace de comunicação de rede.

[017] De acordo com uma outra modalidade, o dispositivo de proxy de cliente recebe o pacote de dados de proxy de servidor. A estrutura de cabeçalho de proxy de servidor do pacote de dados de proxy de servidor é modificada para gerar um segundo pacote de dados de servidor compreendendo o payload de dados de servidor e uma estrutura de cabeçalho de cliente de servidor, compreendendo a estrutura de cabeçalho de cliente de servidor os parâmetros de protocolo da estrutura de cabeçalho de servidor indicando pelo menos o sequenciamento pelo protocolo de fonte do primeiro pacote de dados de servidor, e incluindo os parâmetros de protocolo de comunicação de cliente o parâmetro de endereço de fonte do dispositivo de servidor de destino e um parâmetro de endereço de destino do dispositivo de cliente de fonte. O segundo pacote de dados de servidor é transmitido ao dispositivo de cliente de fonte.

[018] Outros aspectos, características e vantagens da invenção se tornarão facilmente evidentes da descrição detalhada que segue, simplesmente pela ilustração de uma série de modalidades e implementações específicas, incluindo o melhor modo reivindicado para a colocação em prática da invenção. A invenção é também capaz de outras modalidades diferentes e os seus diversos detalhes podem ser modificados em diversos respeitos óbvios, tudo sem que haja desvio do espírito e do âmbito da invenção. Consequentemente, os desenhos e a descrição devem ser considerados como tendo uma natureza ilustrativa e não restritiva.

BREVE DESCRIÇÃO DOS DESENHOS

[019] A presente invenção é ilustrada a título de exemplo e não como uma limitação, nas figuras dos desenhos apensos em que os mesmos números de referência se referem aos mesmos elementos, e em que: As Figuras 1A, 1B e 1C ilustram sistemas de comunicação para empregar endereçamento múltiplo sensível a aplicativo com protocolos de tunelamento de caminhos múltiplos, de acordo com modalidades exemplares da presente invenção; A Figura 2A ilustra um diagrama de blocos ilustrando um sistema que emprega o endereçamento múltiplo sensível a aplicativo com protocolos de tunelamento de caminhos múltiplos utilizando a abordagem da caixa intermediária, em que uma caixa intermediária de cliente é implementada em um ponto extremo de rede de cliente e uma caixa intermediária de servidor é implementada em um ponto extremo da rede de servidor, de acordo com modalidades exemplares da presente invenção; A Figura 2B ilustra um diagrama ilustrando um sistema de satélite empregando endereçamento múltiplo sensível a aplicativo com protocolos de tunelamento de caminhos múltiplos utilizando a abordagem de caixa intermediária, sendo uma caixa intermediária de cliente implementada em cada ponto extremo de rede de cliente e sendo uma caixa intermediária de servidor implementada em um ponto de entrada para uma conexão da internet para uma multiplicidade de pontos extremos da rede de servidor, de acordo com modalidades exemplares da presente invenção; A Figura 3 ilustra um diagrama ilustrando um processo de registro de caixa de cliente, de acordo com as modalidades exemplares da presente invenção; A Figura 4A ilustra um diagrama de locos ilustrando abordagens de tunelamento de caminhos múltiplos, de acordo com as modalidades exemplares da presente invenção; A Figura 4B ilustra um formato de cabeçalho de fluxo para um formato de objeto de tipo-comprimento-valor (TLV), de acordo com uma modalidade exemplar da presente invenção; As Figuras 5A e 5B ilustram diagramas de blocos ilustrando uma arquitetura para uma abordagem de classificação de uma multiplicidade de tabelas de correspondência, de acordo com modalidades exemplares da presente invenção; e A Figura 6 ilustra um formato de mensagem para controle do tráfego definido por usuário, de acordo com uma modalidade exemplar da presente invenção.

DESCRIÇÃO DETALHADA

[020] São propostas abordagens para endereçamento múltiplo sensível a aplicativo com protocolos de tunelamento de caminhos múltiplos para se voltar ao desempenho de protocolo de rede e degradação da transmissão de dados em redes longas e gordas (LFNs) e especialmente no caso de protocolos de rede segura e transmissão de dados através de sessões de rede seguras. De acordo com as modalidades exemplares, tal abordagem compreende um novo sistema de endereçamento múltiplo que proporciona um caminho auxiliar de rede de baixa latência (LLN - tal como uma rede celular terrestre) em paralelo com os caminhos de LFN que encaminham seletivamente o tráfego de dados por meio dos caminhos de LLN e de LFN para melhorar o desempenho de protocolo de rede e a transmissão de dados (em navegação segura na web, tal como HTTPS, por exemplo) e para facilitar o controle da quantidade usada de dados através das redes respectivas. Na descrição que segue, para os fins de explicação são apresentados numerosos detalhes específicos para proporcionar uma compreensão abrangente das modalidades da invenção. É evidente, no entanto aos versados na técnica que as modalidades da invenção podem ser implementadas sem estes detalhes específicos ou com um arranjo equivalente. Em outros casos, estruturas e dispositivos bem conhecidos são mostrados na forma de diagrama de blocos para evitar desnecessariamente obscurecer as modalidades da invenção.

[021] Além disso, conforme poderá ser observado um módulo ou componente (conforme se refere no presente) pode ser composto de componente(s) de software, que são armazenados em uma memória ou em um outro meio de armazenagem legível por computador e executados por um ou mais processadores ou CPUs dos dispositivos respectivos. Conforme também será observado, no entanto, um módulo pode alternativamente ser composto por componente(s) de hardware ou componente(s) de firmware ou por uma combinação de componentes de hardware, firmware e/ou software. Além disso, com referência às diversas modalidades exemplares descritas no presente, embora determinadas funções sejam descritas como sendo efetuadas por determinados componentes ou módulos (ou por suas combinações), tais descrições são dadas como exemplos e não se destinam, portanto, a ser limitantes. Consequentemente, qualquer tal função pode ser prevista como sendo efetuada para os outros componentes ou módulos (ou por suas combinações), sem que haja desvio do espírito e do âmbito geral da presente invenção.

[022] As Figuras 1A, 1B, 1C ilustram sistemas de comunicação para empregar abordagens para se voltar ao desempenho de protocolos de rede e a degradação na transmissão de dados em redes longas e gordas (LFNs), de acordo com modalidades exemplares da presente invenção. Com referência à Figura 1A, um sistema de comunicação de banda larga 110 inclui um ou mais transmissores 112 (dos quais é mostrado um) que geram formatos de ondas de sinais para transmissão a um ou mais receptores 116 (dos quais é mostrado um). Os formatos de onda dos sinais são transmitidos através de um canal de comunicação 114, que (a título de exemplo) pode compreender um canal de um sistema de comunicação terrestre, terrestre sem fio ou de satélite. Neste sistema de comunicação discreto 110, o transmissor 112 tem uma fonte de sinais que produz um conjunto discreto de sinais de dados, sendo cada um dos sinais de dados transmitido através de um formato de onda de sinal correspondente. O conjunto discreto de sinais de dados pode ser primeiro codificado (para o meio de um código de correção de erro à frente, por exemplo) para combater ruído e outros problemas associados com o canal 114. Depois de codificados, os sinais codificados podem então ser modulados para uma portadora para transmissão através do canal 114. Os formatos de onda de sinais são atenuados, ou de outro modo qualquer alterados, pelo canal 114.

[023] A Figura 1B ilustra um sistema de comunicação de satélite 130, de acordo com modalidades exemplares. O sistema de comunicação de satélite 130 inclui um satélite 132 que suporta comunicações entre uma multiplicidade de terminais de satélites (STs) 134a, 134n, uma série de gateways (GWs) 138a, 138n, e um centro de operações da rede (NOC) 142. Os STs, GWs e o NOC transmitem e recebem sinais através das antenas 136a, 136n, 146a, 146n e 156 respectivamente. De acordo com diferentes modalidades, o NOC 142 pode residir em um local separado que pode ser atingido por meio de um canal de satélite separado ou pode residir dentro de um site de GW. O NOC 142 desempenha as funções de plano de gerenciamento do sistema 130, ao passo que as GWs 138a, 138n desempenham as funções de plano de dados do sistema 130. O NOC 142 desempenha tais funções como gerenciamento e configuração de rede, downloads de software (para os STs 134a, 134n, por exemplo), monitoração do estado, funções estatísticas (coleta, agregação e relato, por exemplo), funções de segurança (geração, gerenciamento e distribuição de chaves, por exemplo), registro e autenticação de STs, e gerenciamento de diversidade de GWs. O NOC 142 se comunica com cada GW por meio do satélite 132, ou por meio de uma rede de comunicação privada segura 152 (um túnel IPsec, por exemplo, através de um enlace dedicado ou uma rede privada virtual (VPN) ou túnel de IPsec através de uma rede pública tal como a Internet). Deve ser observado que, de acordo com uma modalidade exemplar, as abordagens por classificação de mensagens das modalidades da presente invenção se voltam à classificação de tráfego de dados correndo através de um ponto de agregação ou nó. Adicionalmente cada GW e o NOC têm conectividade a uma ou mais redes de comunicação pública tal como a Internet ou uma PSTN.

[024] De acordo com uma outra modalidade exemplar, cada uma das GWs 138a, 138n incluem um ou mais gateways de IP (IPGWs) - sendo as funções de plano de dados divididos entre um GW e as suas IPGWs respectivas. GW 138a, por exemplo, inclui IPGWs 148a(1) 148a(n) e GW 138n inclui IPGWs 148n(1) 148n(n). Um GW pode desempenhar tais funções como modulação e codificação de saída de camada de enlace e de camada física (modulação e codificação adaptativa de DVB S2, por exemplo), manipulação de entrada de camada de enlace e camada física (IPOS, por exemplo), alocação de largura de banda de entrada e equilíbrio de carga, priorização de saída, aceleração da web e compressão de HTTP, controle de fluxo, criptografia, comutações de redundâncias, e aplicação de normas de restrição do tráfego. Embora a IPGW possa desempenhar tais funções como compressão de dados, melhoramento do desempenho de TCP (proxies de melhoramento de desempenho de TCP, tais como imitação de TCP), funções de proxy de HTTP, funções de qualidade de serviço (classificação, priorização, diferenciação detecção precoce aleatória (RED), controle de fluxo de TCP/UDP), normas de uso de largura de banda, equilíbrio de carga dinâmica, e encaminhamento. Consequentemente, o PEP de TCP e proxies de HTTP estão localizados no gateway do satélite. Além disso, um GW e o IPGW respectivo podem ser colocalizados com o NOC 142. Os STs 134a, 134n provêm conectividade a um ou mais anfitriões 144a, 144n e/ou roteadores 154a, 154n, respectivamente. O sistema de comunicação de satélite 130 pode operar como um sistema de tubo dobrado, em que o satélite essencialmente opera como uma repetidora ou tubo dobrado. Alternativamente, o sistema 130 pode empregar um satélite de comutação ou processamento suportando comunicações de grade (ponto a ponto comunicação diretamente entre dois STs 134a e 134n, por exemplo).

[025] Em um sistema de tubo dobrado de uma modalidade exemplar, o satélite 132 opera como uma repetidora ou tubo dobrado e as comunicações para os STs 134a 134n e provenientes deles são transmitidos através do satélite 132 para as IPGWs respectivas associadas com os STs específicos e provenientes delas. Além disso, em um sistema de feixe pontual, qualquer um feixe pontual opera como um tubo dobrado para a região geográfica coberta pelo feixe. Cada feixe pontual opera, por exemplo, como um canal de comunicação de tubo dobrado para os STs e/ou IPGW(s) dentro da região geográfica coberta pelo feixe. Consequentemente, as transmissões de sinais ao satélite ou são provenientes de um ST e destinadas a um gateway associado, ou provenientes de um gateway e destinadas a um ST associado. De acordo com uma modalidade, diversos GWs/IPGWs são distribuídos por toda a região geográfica coberta por todos os feixes pontuais do satélite 132, em que, em um feixe em que um GW (e IPGWs respectivos) estão localizados, somente o um GW (e nenhum dos STs) ocupa aquele feixe. Além disso, cada IPGW pode servir com um nó de agregação para uma multiplicidade de nós remotos ou STs. O número total de GWs/IPGWs, e a distribuição geográfica dos GWs/IPGWs depende do número de fatores, tais como a capacidade total do satélite dedicado ao tráfego de dados, carga de tráfego geográfico do sistema (com base em densidades populacionais e na distribuição geográfica dos STs), locais de centros de dados terrestres disponíveis (troncos de dados terrestres para acesso a redes públicas e privadas dedicadas, por exemplo).

[026] Mais especificamente, com referência à Figura 1C, por exemplo, para uma comunicação de dados do ST 134a a uma rede de comunicação pública 158 (a Internet, por exemplo), o ST 134a está associado com um IPGW (tal como o IPGW 148a(1), por exemplo - selecionado de uma combinação de IPGWs disponíveis ao ST 134a, tal como IPGWs 148(1) 148a(5) — em que a combinação de IPGWs é um subconjunto adequado dos IPGWs 148(1) 148a(n) localizados no GW 138a). Os dados são primeiro transmitidos, através do satélite 132, do ST 134a ao IPGW 148a(1) associado. O IPGW 148a(1) determina a destinação como sendo a Internet 158. O IPGW então refaz os pacotes de dados (em forma de uma comunicação TCP/IP, por exemplo) e encaminha a comunicação de dados, através do enlace terrestre 164, à Internet 158. Além disso, em uma rede de firma, por exemplo, uma firma pode implementar diversos STs remotos em escritórios remotos. Mais especificamente, o ST 134n, localizado em um local remoto de uma firma pode desejar se comunicar com segurança com a sede da firma 162. Consequentemente, para uma comunicação de dados do ST 134n à sede da firma 162, os dados são primeiro transmitidos, através do satélite 132, do ST 134n para um IPGW associado com o ST 134n (IPGW 148a(5), por exemplo). O IPGW 148a (5) determina a destinação como sendo a sede da firma 162. O IPGW então refaz os pacotes de dados (em forma de uma comunicação de IPsec, por exemplo) e encaminha a comunicação de dados de IPsec, através dos enlaces terrestres seguros 166 (através de rede privada 152) à sede da firma 162. No ambiente da rede de uma firma, um outro exemplo envolve uma comunicação de firma da sede da firma a uma série de locais remotos (uma comunicação multicast para os STs 134a 134n, por exemplo) - em que STs 134a 134n são correspondentemente associados com os dois IPGWs 148a(1) e 148a(5) (agrupados entre os dois IPGWs com base no equilíbrio de carga e nas capacidades de IPGWs, por exemplo). Nesta situação, um gateway ou roteador, dentro da rede local da sede da firma 162 transmite a comunicação de dados, por meio de enlaces terrestres seguros 166 (através da rede privada 152), aos IPGWs 148a(1) e 148a(5). Os IPGWs determinam que a comunicação é destinada aos STs remotos 134a 134n, e empacotam os dados em forma de uma comunicação multicast endereçada à comunidade de STs 134a 134n. Os IPGWs então transmitem a comunicação de dados, através do satélite 132, para decodificação pela comunidade de STs 134a 134n. Consequentemente, o satélite de tal sistema atua como um tubo dobrado ou repetidora, transmitindo as comunicações entre os STs 134a 134n e os seus IPGWs respectivos associados 148a 148n.

[027] Mais especificamente com referência à Figura 1C, para uma comunicação de dados do ST 134a a uma rede de comunicação pública 158 (a Internet, por exemplo), o ST 134a é associado com um IPGW (IPGW 148a(1), por exemplo - selecionado de uma combinação de IPGWs disponíveis ao ST 134a, tal como IPGWs 148a(1)-148a(5) - em que a combinação de IPGWs é um subconjunto adequado dos IPGWs 148a(1)-148a(n) localizado no GW 138a). Os dados são primeiro transmitidos através do satélite 132, do ST 134a ao IPGW 148a(1) associado. O IPGW 148a(1) determina a destinação como sendo a Internet 158. O IPGW então recompõe os dados em pacotes (em forma de uma comunicação de TCP/IP, por exemplo) e encaminha a comunicação de dados, através do enlace terrestre 164 à Internet 158. Além disso, em uma rede de firmas, por exemplo, uma firma pode implementar diversos STs remotos em escritórios remotos. Mais especificamente ST 134n localizado em um local de firma remoto pode desejar se comunicar com segurança com a sede da firma 162. Consequentemente, para uma comunicação de dados proveniente de ST 134n para a sede da firma 162, os dados são primeiro transmitidos, através do satélite 132, do ST 134n a um IPGW associado com o ST 134n (IPGW 148a(5), por exemplo). O IPGW 148a (5) determina a destinação como sendo a sede da firma 162. O IPGW então recompõe os dados em pacotes (em forma de uma comunicação de IPsec, por exemplo) e encaminha a comunicação de dados de IPsec, através dos enlaces terrestres seguros 166 (através da rede privada 152) à sede de firma 162. Dentro da situação de rede de firma, um outro exemplo envolve uma comunicação da firma da sede da firma a uma série de locais remotos (uma comunicação multicast aos STs 134a-134n, por exemplo) - em que STs 134a-134n são correspondentemente associados com os dois IPGWs 148a(1) e 148a(5) (agrupados entre os dois IPGWs com base no equilíbrio de carga e nas capacidades dos IPGWs, por exemplo). Nestas circunstâncias, um gateway ou roteador, dentro da rede local de sede da firma 162, transmite a comunicação de dados por meio de enlaces terrestres seguros 166 (através da rede privada 152) aos IPGWs 148a(1) e 148a(5). Os IPGWs determinam que a comunicação é destinada aos STs remotos 134a 134n, e empacota os dados em forma de uma comunicação multicast endereçada à comunidade de STs 134a-134n. Os IPGWs então transmitem a comunicação de dados, através do satélite 132, para decodificação pela comunidade de STs 134a-134n. Consequentemente, o satélite de tal sistema atua como um tubo dobrado ou repetidor, transmitindo comunicações entre os STs 134a-134n e seus IPGWs respectivos associados 148a-148n.

[028] De acordo com modalidades exemplares da presente invenção, é proposto um caminho auxiliar de rede de latência relativamente baixa (LLN) em paralelo com um ou mais caminhos de latência de uma LFN (canais de uma rede de satélite, por exemplo). Esta arquitetura facilita, por exemplo, um melhor desempenho da sessão de protocolo ou estabelecimento e conservação de enlace e melhora a transmissão de dados (resultando em uma redução no tempo de carga de página (PLT), por exemplo, para páginas da web através de conexões seguras, tais como conexões de protocolo HTTPS e SSL/TLS) com a adição de um caminho auxiliar de LLN, pode ser reduzida a latência do tráfego de HTTPS tendo ao mesmo tempo a vantagem de uma grande capacidade de enlace dos caminhos de LFN. De acordo com uma modalidade, a classificação da mensagem sensível a aplicativo é aplicada para a classificação de mensagens e de dados, e então somente algumas mensagens e dados (com base na classificação) utilizam o caminho de baixa latência, o que proporciona um uso eficiente da largura de banda através do caminho de LLN. A título de exemplo, a LLN pode ser utilizada para enviar mensagens de aplicativos sensíveis à latência que apresentam um impacto maior ou mais significativo sobre o desempenho do aplicativo (pequenas mensagens interativas tais como consulta de DNS, aperto de mão TCP, estabelecimento de sessão de SSL e mensagens de HTTP GET, por exemplo), ao passo que a LFN seria utilizada para enviar mensagens de aplicativo grandes e menos sensíveis a latência que apresentam um impacto inferior ou menos significativo sobre o desempenho do aplicativo (mensagens de resposta de HTTP - dados do servidor de web, por exemplo). Em outras palavras, a classificação de mensagem inteligente (aplicada à camada de aplicativo, por exemplo) proporciona uma distribuição eficiente de mensagens de dados entre os caminhos de LLN e os caminhos de LFN (encaminhando pequenas mensagens de solicitação, tais como solicitação de HTTP através de SSL/TLS, através de um caminho de LLN, por exemplo, e encaminhando grandes mensagens de resposta, tais como resposta de HTTP por SSL/TLS através de um caminho de LFN). Tais abordagens de endereçamento múltiplo de rede sensível a aplicativo das modalidades exemplares, portanto, reduzem o tempo ocioso entre a solicitação e a resposta de mensagens de HTTPS, tornando ao mesmo tempo mais eficiente o uso de uma quantidade relativamente pequena de largura de banda da rede de baixa latência. Além disso, encaminhando pequenas mensagens interativas (mensagens de aperto de mão de TCP e de estabelecimento de sessões SSL/TLS, por exemplo) através dos caminhos de LLN, as abordagens de endereçamento múltiplo de rede sensível a aplicativo das modalidades exemplares reduzem assim o tempo de estabelecimento e conexão de sessão. As modalidades exemplares de tais abordagens por classificação de mensagens serão descritas mais detalhadamente abaixo com referência à Figura 5.

[029] De acordo com as modalidades exemplares, os caminhos de rede de baixa latência podem compreender qualquer um dos diversos tipos de redes que proporcionam um tempo de ida e volta (RTT) relativamente menor em comparação com uma LFN, tal como uma rede de satélite geossincrônica. A título de exemplo, os caminhos de LLN podem ser providos através de redes de linha por fio diversas (telefonia/discagem, DSL, cabo, fibra, por exemplo, etc.) e de redes sem fio (redes celulares, tais como redes 3G/4G, por exemplo, redes de linha de sítio, e redes sem fio empregando plataformas aéreas, tais como plataformas de grande altitude, veículos aéreos sem piloto, e satélites de baixa órbita). No caso de uma rede celular 3G/4G, por exemplo, uma grande porcentagem dos usuários/assinantes existentes terá já assinaturas para planos de dados celulares 3G/4G (planos de dados de smartfone, por exemplo). Além disso, os serviços da Internet 3G/4G podem também ser utilizados em modalidades exemplares, tais como FreedomPop e NetZero (cada um dos quais proporciona uma quantidade fixa de quantidade usada de dados de Internet livre por mes). Alternativamente, os provedores de serviços da Internet por satélite podem estabelecer planos abrangentes com provedores dos serviços celulares 3G/4G, dos quais pode ser provida a banda larga a assinantes de Internet por satélite para caminhos de dados respectivos de LLN, de acordo com modalidades da presente invenção. Deste modo, por um custo relativamente baixo (largura de banda limitada de LLN por assinante de serviços por satélite), os provedores de serviços por satélite podem melhorar significativamente o desempenho do serviço, de acordo com modalidades da presente invenção.

[030] Além disso, de acordo com uma modalidade, a abordagem de endereçamento múltiplo de rede sensível a aplicativo pode ser empregada por meio de uma implementação de caixa intermediária, implementando uma caixa intermediária em cada uma das extremidades do cliente e do servidor de enlaces/caminhos de uma rede de comunicação. A título de exemplo, cada caixa intermediária compreende duas conexões de rede, uma conexão da rede LFN (uma conexão de rede por satélite, por exemplo) e uma conexão de rede terrestre (uma conexão de rede celular 3G/4g, por exemplo). As caixas intermediárias dividem e fundem fluxos para os usuários finais (navegadores de web de clientes e servidores da web, por exemplo) usando um protocolo prático de tunelamento de caminhos múltiplos, de acordo com modalidades exemplares (descritos mais detalhadamente abaixo). A abordagem da caixa intermediária assim opera utilizando protocolos e infra-estrutura correntes da rede (Internet, por exemplo), sem necessitar de qualquer modificação de cabeçalhos de IP e de cabeçalhos de TCP/udp, e seria compatível com redes correntes de banda largura por satélite (redes por satélite empregando protocolos de TCP e TCP PEP, por exemplo). Além disso, o software do aplicativo nos nós do cliente e do servidor (navegadores da web e programas de servidor da web, por exemplo) não necessitariam de modificação para compatibilidade com as caixas intermediárias implementadas. Além disso, através da abordagem de caixa intermediária, o usuário/assinante pode ser dotado com a capacidade de controlar a quantidade usada de dados da rede de baixa latência e da LFN (para controlar os custos, por exemplo). Para evitar uma cobrança extra por exceder os limitadores de dados de uma rede respectiva, os usuários/assinantes podem controlar a quantidade usada de dados entre os caminhos de rede de baixa latência e de LFN (o sistema pode prover ao usuário a capacidade de configurar uma cota de dados para cada rede). Adicionalmente, reduzindo a latência por meio do uso de caminhos de rede de baixa latência para transmitir determinadas mensagens, as LFNs de grande largura de banda podem ser exploradas para o fornecimento econômico de outras transmissões de mensagens menos sensíveis a atraso. De acordo com modalidades exemplares, a classificação de mensagens sensível a aplicativo deste modo facilita a utilização eficiente de caminhos de rede de baixa latência para prover serviços de rede melhorados.

[031] De acordo com modalidades exemplares, para melhorar o desempenho de HTTPS, um fluxo é enviado através de uma multiplicidade de redes dividindo-se o fluxo. A multiplicidade de redes, no entanto, pode ser gerenciada por diferentes provedores de serviço, e assim o mesmo fluxo através de diferentes redes terá endereços de IP fonte e números de portas diferentes. Quando é efetuado um aperto de mãos de TCP através de um caminho (uma rede terrestre, por exemplo), os pacotes subsequentes do mesmo fluxo através do outro caminho (uma rede de satélite, por exemplo) serão abandonados em um servidor da web, pois a conexão TCP para o caminho não existe no servidor (devido a endereços de IP e números de porta diferentes). Consequentemente, modalidades da presente invenção proporcionam mecanismos e protocolos para manipular tais fluxos de TCP de caminhos múltiplos.

[032] Conforme foi especificado acima, o protocolo de controle de transmissão de caminhos múltiplos (MPTCP) foi desenvolvido para uma única transmissão de TCP a ser enviada por múltiplos caminhos. MPTCP tem o benefício da confiabilidade e nível mais alto de transmissão enviando pacotes de TCP por diferentes caminhos. MPTCP, no entanto, exige uma nova opção de TCP, e assim ele apresenta um problema de implementação nos casos em que caixas intermediárias não são configurados para manipular uma nova opção ou para reescrever as opções de TCP. Além disso, em redes pós satélite, esta nova opção de TCP não funciona com PEP de TCP que termina uma conexão de TCP entre um terminal de usuário por satélite (um terminal de abertura muito pequena ou VSAT, por exemplo) e o gateway de satélite. Além disso, MPTCP exige que os clientes e servidores da web precisem ter uma pilha de MPTCP. Além disso, a ausência de classificação de mensagens em MPTCP não permite que o sistema controle a quantidade usada de dados de rede, de modo que isso resulta em uma cobrança extra pelo uso de dados de redes terrestres. O remetente poderia enviar grandes arquivos tais como arquivos de imagens e de vídeo através da rede terrestre.

[033] A Figura 2A ilustra um diagrama de blocos ilustrando um sistema que emprega endereçamento múltiplo sensível a aplicativo com protocolos de tunelamento de caminhos múltiplos utilizando uma abordagem de caixa intermediária, em que uma caixa intermediária de cliente é implementada em cada ponto final de rede de cliente e uma caixa intermediária de servidor é implementada em um ponto de entrada em uma conexão da Internet para múltiplos pontos finais de rede de servidor de acordo com as modalidades exemplares da presente invenção. Com referência às Figuras 2A e 2B, um caixa intermediária de cliente (caixa C) que tem múltiplas conexões de rede é implementado em cada site de cliente (remoto) entre o(s) terminal(ais) de cliente e as conexões de LLN e LFN. De modo correspondente, um caixa intermediária de servidor (caixa S) é implementado no site de servidor (em um portal da Internet, por exemplo, conforme mostrado na Figura 2B), entre as conexões de LLN e de LFN e o(s) servidor(es) alvo. Conforme ainda ilustrado na Figura 2B, a caixa S pode ser implementada em um ponto de entrada em uma conexão da Internet a um ou mais servidores alvo (os servidores da web seguros ilustrados, tais como servidores da web ou servidores do aplicativo, por exemplo). A caixa C e a caixa S são os pontos de dividir-e-fundir dos fluxos de TCP respectivos. Na direção de volta, da extremidade de cliente remoto à extremidade de servidor da rede, a caixa C determina os pacotes de entrada de um fluxo ou sessão que será transmitidos através do enlace de LLN e os pacotes de entrada que serão transmitidos através da LFN. Na direção à frente ou de saída, da extremidade de gateway/servidor à extremidade de rede do cliente remoto, a caixa S determina os pacotes de saída de um fluxo ou sessão que serão transmitidos através do enlace de LLN e os pacotes de saída que serão transmitidos através da LFN. As caixas intermediárias manipulam caminhos múltiplos do mesmo fluxo, de modo que os clientes e os servidores não precisam estender seus protocolos e aplicativos para dar suporte ao endereçamento múltiplo.

Registro

[034] Durante uma fase de inicialização (ligação da energia, por exemplo) de acordo com uma modalidade exemplar, um caixa C registra os seus múltiplos endereços de IP para uma caixa S respectiva - a caixa C terá um endereço de IP atribuído para cada uma das suas interfaces de rede. Com base nos endereços de IP registrados, a caixa S pode enviar pacotes à caixa C através dos múltiplos caminhos de LFN e de LLN. A título de exemplo, o processo de registro emprega mensagens de sinalização explícita para o registro, usando um número de portas pré-configuradas específicas da caixa S - deste modo, com base no número de portas da caixa S, a caixa S sabe que as mensagens de sinalização se destinam a mensagens de controle de endereçamento múltiplo tais como de registro. As mensagens de solicitação de registro que incluem um identificador da caixa C (um ID de terminal, por exemplo) e o enlace de rede, podem ser enviadas através de uma rede de endereçamento múltiplo. O ID de terminal pode ser atribuído por provedores de serviço da Internet de satélite com antecedência, ou então a caixa C pode simplesmente usar o endereço MAC do modem de rede de satélite respectivo. A título de um outro exemplo, a caixa S respectiva com a qual uma caixa C registra pode ser configurada pelo provedor de serviço de rede por meio de um endereço de IP específico da caixa S ou por meio de um nome de domínio atribuído à caixa S que traduz para o endereço de IP respectivo por meio de um processo de consulta de DNS.

[035] A Figura 3 ilustra um diagrama ilustrando um processo de registro de caixa C, de acordo com modalidades exemplares da presente invenção. Quando a caixa S recebe a mensagem de solicitação de registro, ela registra o ID do terminal, o endereço de IP da rede fonte, e o número de portas. No caso em que a caixa C se encontra por trás de uma função de tradução de endereço de rede de um provedor de serviço, a caixa S recebe os endereços públicos de IP da caixa C como os endereços de fonte. A tradução de endereços de rede (NAT) é uma metodologia de remapeamento de um espaço de endereço de IP (um espaço de endereço de IP privado de uma rede de firma, por exemplo) para um outro espaço de endereço de IP (o espaço de endereço de IP público da Internet, por exemplo) modificando as informações do endereço de rede dos cabeçalhos do pacote de IP ou do pacote de datagrama antes de serem transmitidos do dispositivo de encaminhamento de NAT. A caixa S armazena as informações de registro em uma tabela de encaminhamento e envia uma mensagem de resposta de registro à caixa C para confirmar o registro. De acordo com um aspecto, o processo de registro pode ser uma abordagem de estado macio, em que são periodicamente transmitidas mensagens mantidas vivas.

[036] Com referência à Figura 3, a caixa C tem duas interfaces de rede com endereços respectivos privados A1 e A2 de IP, para fazer interface com dois enlaces de rede L1 e L2 (um de LLN e um de LFN, por exemplo). A título de exemplo, o enlace de rede L1 pode ser de uma LLN administrada por um provedor de serviço e o enlace de rede L2 pode ser de uma LFN administrada pelo mesmo provedor de serviço ou por um diferente. O endereço de IP A1 é atribuído à caixa C como o endereço de IP privado para o enlace L1 e o endereço A2 de IP é atribuído à caixa C como o endereço privado de IP para o enlace L2. Além disso, por meio da função NAT, A1* e A2* são os endereços públicos de IP atribuídos aos endereços privados A1 e A2 de IP da caixa C. O ID de terminal (RIS) da caixa C é A - o TID identifica a caixa C específica com a qual os endereços de IP estão associados (a caixa S pode distinguir entre as diferentes caixas C associadas àquela caixa S). A tabela de Registro mostra as informações armazenadas de registro ou de encaminhamento na caixa S. Periodicamente, com base no período de tempo T, a caixa C envia mensagens manter vivas para a caixa S e a caixa S envia respostas manter vivas respectivas de volta para a caixa C. Consequentemente, conforme ilustrado a caixa C envia as duas solicitações de registro ao endereço de IP da caixa S (A3). A solicitação, Req (A, L1) é para registro do seu endereço de IP privado A1 como o endereço fonte para transmissões de pacotes de entrada provenientes da caixa C, e o endereço de destinação para transmissões de pacotes de saída da caixa S, através do enlace de rede L1. A solicitação, e Req (A, L2) se destina a registro do seu endereço privado de IP A2 como o endereço fonte para transmissões de pacotes de entrada do caixa C, e o endereço de destinação para transmissões de pacotes de saída de caixa S, através do enlace de rede L2. A caixa S, com base no NAT, recebe as duas solicitações com os endereços fonte respectivos sendo o endereço público A1* de IP (associado através de NAT ao endereço privado A1) e o endereço público de IP A2* (associado através de NAT ao endereço privado A2). Consequentemente, a caixa S registra o endereço público A1* de IP como o endereço para pacotes a serem transmitidos para a caixa C com TID=A através do enlace L1, e registra o endereço público A2* de IP como o endereço para pacotes a serem transmitidos para a caixa C com o TID=A através do enlace L2. A caixa S também armazena as portas respectivas de fonte de caixa C na tabela.

[037] Um outro exemplo de tal Tabela de Registro é mostrado abaixo na Tabela 1. Os lançamentos da Tabela 1 refletem duas caixas C diferentes comunicando-se com uma única caixa S (caixa C A e caixa C B). Cada caixa C se comunica com a caixa S por meio de dois enlaces diferentes de rede (um enlace 1 de LLN e um enlace 2 de LFN). O endereço público de IP para a caixa C A através do enlace LLN 1 é 67.44.192.130, o endereço público de IP para a caixa C A através do enlace de LFN 2 é 70.192.217.80, o endereço público de IP para a caixa C B através do enlace 1 de LLN é 67.44.20.115, e o endereço público de IP para a caixa C B através do enlace 2 de LFN é 70.192.115.85. A porta de Cliente fonte para a caixa C A através do enlace 1 de LLN é 574, a porta de Cliente fonte para a caixa C A através do enlace 2 de LFN é 293, a porta de cliente fonte para a caixa C G através do enlace 1 de LLN é 1938 e a porta de Cliente fonte para a caixa C B através do enlace 2 de LFN é 332. Estes dados são coletados e armazenados pela caixa S por meio dos processos de registro de caixa C discutidos acima.Tabela 1. Tabela de Registro

[038] De acordo com um outro aspecto, o processo de registro pode ser uma abordagem assíncrona, de modo que a caixa C ou a caixa S atualiza o registro no caso de uma alteração do estado da rede. A título de exemplo, quando uma das redes está desligada, a caixa C pode enviar uma mensagem de sinalização para terminar o endereçamento múltiplo através da outra rede. A título de outro exemplo, se um usuário exceder uma cota de dados aplicável de uma das redes (excede a cota de dados de assinatura da LLN, por exemplo), a caixa S pode enviar uma mensagem de sinalização para terminar o endereçamento múltiplo. Além disso, além do registro das informações de caixa C respectiva, o processo de registro pode também abrir as conexões entre a caixa C e a caixa S, que são usadas para enviar pacotes entre a caixa C e a caixa S. Assim, as mensagens de registro podem ser enviadas através do mesmo protocolo de transporte (TCP ou UDP) em forma de tunelamento de caminhos múltiplos (descrito mais detalhadamente abaixo).

Tunelamento de caminhos múltiplos:

[039] De acordo com modalidades exemplares, para se enviar mensagens entre uma caixa C e uma caixa S através de múltiplos mecanismos, é proposto um mecanismo de tunelamento de caminhos múltiplos. Com tal abordagem, como o mesmo fluxo é enviado através de caminhos de diferentes redes, o cabeçalho de TCP original não pode ser usado. Mais especificamente, como alguns pacotes são enviados através de uma rede e os demais são enviados através da outra rede, a utilização dos cabeçalhos de TCP original resultaria em furos no número de sequência e no número de ACK nos nós de extremidade de cada caminho. Os furos resultariam, consequentemente, em perdas de pacotes quando as caixas intermediárias tais como PEP de TCP gerenciam os estados de TCP. Para resolver tais problemas com a numeração da sequência e de ACK, modalidades exemplares fazem a previsão do encapsulamento do cabeçalho de TCP original e do payload em uma nova camada de transporte (TCP ou UDP), com base nas associações de enlaces de TID e endereços de IP criadas durante o processo de registro. Assim o cabeçalho de TCP original e o payload de TCP se tornam o payload do novo pacote de camada de transporte encapsulado. Depois de o pacote ter sido entregue à extremidade de destinação, a caixa intermediária nessa extremidade usa o cabeçalho de TCP original para o anfitrião de extremidade (o (s) terminal (ais) do cliente de destino na extremidade de cliente ou do servidor de destino na extremidade de servidor). Assim, fica preservada a conexão de TCP fim-a-fim entre um cliente fonte e o servidor de destinação. Consequentemente, o encapsulamento ou tunelamento de caminhos múltiplos é usado para o envio de pacotes através de caminhos múltiplos entre caixas intermediárias, e o encapsulamento de TCP original é preservado através dos enlaces além das caixas intermediárias, o que permite que o sistema funcione na infra-estrutura da internet corrente e que funcione com outras caixas intermediárias que gerenciam os estados de TCP.

[040] De acordo com modalidades exemplares, são descritos no presente documento dois métodos de tunelamento de caminhos múltiplos de camada de transporte, o tunelamento de múltiplos caminhos de UDP e o tunelamento de múltiplos caminhos de TCP. A Figura 4A ilustra um diagrama de blocos ilustrando abordagens de tunelamento de múltiplos caminhos, de acordo com as modalidades exemplares da presente invenção. Tais abordagens de tunelamento de caminhos múltiplos não dividem as sessões de SSL - elas não descriptografam pacotes de SSL no homem-intermediário, de modo que o sistema conserva a segurança de fim-a-fim. Além disso, de acordo com modalidades exemplares, os tunelamentos de caminhos múltiplos de UDP e de TCP empregados entre a caixa C e caixa S são empregados respectivamente independentemente através de cada enlace de rede com base nos processos de Protocolo de Datagrama de Usuário padrão e em processos de Protocolo de Controle de Transmissão padrão. Em outras palavras, o processamento para o fluxo de pacotes através de cada enlace (tal como estabelecimento de conexão, sequenciamento, reconhecimentos, confirmações de transmissão etc.) é efetuado de acordo com o padrão de protocolo aplicável. As caixas intermediárias deste modo se comunicam umas com as outras através de cada enlace de rede por meio de uma conexão de UDP ou de TCP respectiva, usando a pilha padrão de UDP ou de TCP. Consequentemente, os pacotes recebidos através de um enlace dado de rede pelo caixa intermediária de destinação são processados como um fluxo único através desse enlace, de acordo com o protocolo aplicável. Em seguida, quando o protocolo é extraído pela caixa intermediária de destinação, e é adquirido o pacote original, os pacotes provenientes dos múltiplos enlaces são reagrupados e transmitidos para a(s) destinação (ões) com base nas informações de fluxo de fonte original obtidas dos cabeçalhos de pacote original.

[041] De acordo com modalidade do tunelamento da primeira camada de transporte, é empregado o tunelamento de caminhos múltiplos de UDP, sendo os pacotes de TCP originais enviados dentro dos pacotes de datagrama de UDP (TCP-através de-UDP). Como o tunelamento de UDP usa um modelo de transmissão sem conexões simples, o tunelamento de caminhos múltiplos de UDP não necessita do gerenciamento de diferentes sessões para os enlaces de diferentes redes (o enlace de LLN e o enlace de LFN, por exemplo). Em vez disso, os pacotes originais de TCP são encapsulados e transmitidos em forma de datagramas de UDP pela caixa intermediária de fonte e a caixa intermediária de destinação extrai o encapsulamento de UDP para recuperar os pacotes originais de TCP. Com UDP, a caixa intermediária de fonte envia a mensagem à caixa intermediária de destinação sem um estabelecimento prévio de sessões ou canais específicos. A confiabilidade, o controle de fluxo e o controle de congestão são providos pelos pacotes originais de TCP de fim-a-fim (cliente-a-servidor) encapsulados dentro de UDP. Com o tunelamento de caminhos múltiplos de UDP em uma rede que emprega PEP de TCP (uma rede de satélite, por exemplo), no entanto, o tunelamento de UDP não pode usar o benefício de PEP de TCP, pois os pacotes de UDP tipicamente se desviam do PEP de TCP de tais redes.

[042] De acordo com a modalidade de tunelamento de segunda camada de transporte, é empregado um tunelamento de caminhos múltiplos de TCP, sendo os pacotes originais de TCP encapsulados dentro de pacotes de dados de TCP (TCP-através de-TCP). Ao contrário do tunelamento de caminhos múltiplos de UDP, o tunelamento de caminhos múltiplos de TCP pode receber o benefício de PEP de TCP. A título de exemplo, para se empregar PEP de TCP, cada caixa intermediária é configurada com uma funcionalidade semelhante a PEP, que dividiria uma conexão de TCP em três conexões: uma conexão entre um cliente e uma caixa c, uma outra conexão entre a caixa C e a caixa S respectiva, e a outra conexão entre a caixa S e um servidor de destinação. Nestas circunstâncias, as caixas intermediárias gerariam reconhecimentos locais aos anfitriões finais respectivos para preencher o enlace entre caixas intermediárias e dar suporte à confiabilidade entre um anfitrião final e uma caixa intermediária. A confiabilidade entre a caixa C e a caixa S é provida pelas conexões de TCP entre as caixas intermediárias.

[043] Como os fluxos são transmitidos através de uma conexão de cada rede criada durante o processo de registro, os fluxos são multiplexados através de cada conexão. Assim fluxos separados são multiplexados em conjunto através de cada enlace de rede entre caixas intermediárias. Para facilitar a identificação do fluxo respectivo ao qual pertence cada pacote (desmultiplexar os fluxos através de cada enlace de rede, por exemplo), as informações sobre o fluxo são inseridas em cada um dos pacotes para identificar o fluxo original respectivo. Além do novo cabeçalho de camada de transporte é inserido, por exemplo, um cabeçalho de fluxo (ID de terminal de caixa C (TID) e informação de fluxo, por exemplo) nos pacotes transmitidos entre a caixa C e a caixa S. Mais especificamente, de acordo com uma modalidade, o cabeçalho de fluxo inclui o TID da caixa C, o endereço de IP do cliente de fonte respectivo, o endereço de IP do servidor de destinação, a porta de fonte do cliente de fonte, e a porta de destinação do servidor de destinação. De acordo com uma outra modalidade, os números das portas de fonte e de destinação não estão incluídos no cabeçalho de fluxo, uma vez que estes números de porta estarão já incluídos no cabeçalho original de TCP (que permanece no pacote encapsulados). A Figura 4B ilustra um formato de cabeçalho de fluxo para um formato de objeto de tipo-comprimento-valor (TLV), de acordo com uma modalidade exemplar da presente invenção. Neste cabeçalho de fluxo, “Tipo” é o tio de pacote (à montante dos caminhos múltiplos ou à jusante dos caminhos múltiplos). “Comprimento” é o comprimento do cabeçalho, “Comprimento Total” é o comprimento do pacote (usado para identificar cada pacote quando os pacotes são multiplexados na mesma conexão). “Ver” é a versão do endereço de (IPv4 ou IPv6, por exemplo), “Protocolo” é o protocolo de encapsulamento de pacote (UDP ou TCP, por exemplo), “ID de terminal” é o ID da caixa C, “Endereço de IP de Fonte” é o endereço privado de IP do cliente de fonte, e “Endereço de IP de Destinação” é o endereço de IP do servidor de destinação. O cabeçalho pode opcionalmente incluir um campo “Porta de Fonte” identificando o número da porta do Cliente de fonte e “Porta de Destinação” identificando o número de porta de destinação do servidor de destinação. O endereço de IP de fonte e o número da porta são usados para identificar fluxos para cliente que compartilham a mesma caixa C, ao passo que o ID de terminal é usado para identificar a caixa C. O endereço de IP de destinação e o número da porta de destinação são o endereço de IP e o número da porta (443 para SSL/TLS, por exemplo) de servidor final.

[044] Com referência à Figura 4A, por exemplo, um pacote 441 do TCP original (contendo o cabeçalho 402 do TCP e os dados 403) é transmitido pelo cliente para a caixa C, por meio de uma rede de IP local, tal como o pacote 442 de IP. Com base nas especificações do Protocolo da Internet (IP), o cabeçalho 401 de IP inclui um endereço de IP de fonte (o endereço de do cliente de fonte) e um endereço de IP de destinação (o endereço de IP do servidor de destinação). Com base nas especificações do Protocolo de Controle de Transmissão (TCP), o cabeçalho de TCP 402 inclui uma porta de fonte (a porta respectiva do cliente de fonte) e uma porta de destinação (a porta de destinação do servidor de destinação). O pacote 441, por exemplo, pode ser uma mensagem de HTTP Get solicitando uma página específica da web do servidor. A caixa C, com base na abordagem de classificação de mensagem aplicada determina que a mensagem curta HTTP Get deve ser transmitida para a caixa S por meio do enlace de LLN. A caixa C recebe o pacote e extrai o cabeçalho 401 de IP. A caixa C então encapsula o pacote 441 acrescentando o cabeçalho de informações sobre fluxo 406, o cabeçalho 405 de UDP/TCP (no caso do tunelamento de caminhos múltiplos de UDP, o cabeçalho 405 consiste em um cabeçalho de UDP, e, no caso do tunelamento de caminhos múltiplos de TCP, o cabeçalho 405 consiste em um cabeçalho de TCP), e o cabeçalho 404 de IP. De acordo com uma modalidade, as informações do cabeçalho de fluxo incluem o TID da caixa C, o endereço de IP de cliente de fonte (proveniente do cabeçalho 401 de IP), e o endereço de IP de servidor de destinação (também proveniente do cabeçalho 401 de IP). Conforme foi mencionado acima, de acordo com uma outra modalidade, o cabeçalho de fluxo pode também incluir o número da porta de cliente de fonte e o número da porta de destinação de servidor de destinação (obtido de cabeçalho 402 do TCP). O cabeçalho 405 de UDP/TCP inclui as informações solicitadas de UDP ou de TCP para a conexão de fluxo respectiva através do LLN à caixa S. Finalmente, o cabeçalho 404 de IP inclui a endereço de IP de fonte para o pacote (o endereço de IP da caixa C de fonte associada com o enlace de LLN), e o endereço de IP de destinação (o endereço de IP da caixa S de destinação).

[045] Quando a caixa S recebe o pacote ela registra determinadas informações de fluxo provenientes de diversos cabeçalhos em uma Tabela de Informações de Fluxo que é utilizada para correlacionar pacotes que respondem recebidos dos pontos finais de destinação (servidores, por exemplo) aos fluxos respectivos, e para gerar os cabeçalhos de encapsulamento adequados para transmitir de volta às caixas C respectivas e eventualmente de volta aos clientes respectivos (conforme será descrito mais detalhadamente abaixo). A caixa S também extrai o cabeçalho de fluxo 406, o cabeçalho de UDP/TCP 405 e o cabeçalho de IP 404 do pacote recebido. A caixa S então reencapsula o cabeçalho 408 de TCP de pacote e os dados 403 como o novo pacote 443 de IP destinado para o servidor de destinação e o número da porta respectivo. O cabeçalho 407 de IP para este novo pacote 443 de IP inclui um endereço de IP de fonte (o endereço de IP da caixa S da fonte) e um endereço de IP de destinação (o endereço de IP do servidor de destinação - obtido do cabeçalho de fluxo 406). Em outras palavras, quando a caixa S recebe um pacote, ela registra as informações de fluxo do pacote na Tabela de Informações de Fluxo, restaura o endereço de IP da destinação (servidor de web, por exemplo) para o endereço original e altera o endereço de IP de fonte para o seu endereço de IP (atuando como um proxy, por exemplo). Além disso, para o cabeçalho 408 de TCP, a caixa S gera um número de porta de saída (isto é, um número de porta de fonte exclusivo para o fluxo de cliente de fonte respectivo) e registra a porta de saída na Tabela de Informações do Fluxo para o fluxo de cliente respectivo. A caixa S insere o número de porta de saída no cabeçalho 408 de TCP como a porta da fonte que é usada para transmitir o fluxo ao servidor. Deste modo, com base no cabeçalho de fluxo e em outras informações de cabeçalho de cada pacote recebido de uma caixa C através dos enlaces de diferentes redes, a caixa S pode determinar e registrar (na Tabela de Informações de Fluxo) um fluxo de fonte original específico do qual se originou o pacote (isto é, os pacotes de dados que se originam de um fluxo de fonte proveniente de um endereço de IP de cliente de fonte comum, por meio de uma caixa C comum, a um endereço de IP de servidor de destinação comum).

[046] O servidor então processaria a mensagem recebida (uma mensagem HTTP Get, por exemplo) e enviaria os dados de resposta respectivos (dados do site da web solicitado pela mensagem Get, por exemplo). Conforme se poderia observar, a troca de mensagens de solicitação e resposta entre o cliente e o servidor pode ser de diversos tipos diferentes sem que haja desvio do âmbito da presente invenção. Um aplicativo pode estar funcionando no terminal do cliente, por exemplo, que opera através de um servidor remoto do aplicativo (um aplicativo de jogo interativo on-line ou um aplicativo de produtividade de escritório com um anfitrião remoto, por exemplo), podendo o terminal de cliente estar transmitindo dados de aplicativo ao servidor do aplicativo ou pode ser outros tipos de mensagens interativas de solicitação solicitando determinadas respostas de dados do servidor do aplicativo. Voltando ao exemplo de uma solicitação de HTTP Get, o servidor processará a solicitação e iniciará um fluxo de volta ao cliente pelos dados de site da web solicitados. Cada pacote de dados será primeiro formatado como um pacote 444 de TCP incluindo os dados 423 e o cabeçalho de TCP 428. O cabeçalho 428 do TCP incluirá um número de porta de fonte (a porta respectiva do servidor) e um número de porta de destinação (o número de porta de saída da caixa S provido por meio do cabeçalho 408 de TCP). O servidor encapsulará o pacote 444 de TCP como um pacote 445 de IP. O cabeçalho 427 de IP incluirá um endereço de IP de fonte (o endereço de IP do servidor) e um endereço de IP de destinação (o endereço de IP do caixa S). Além disso, como o servidor de destinação recebe os pacotes de um luxo de fonte específico (independentemente do enlace de rede específico entre a caixa C respectiva e a caixa S através da qual cada pacote foi transmitido), o servidor pode remontar o fluxo com base no cabeçalho de TCP 408.

[047] Quando a caixa S recebe um pacote do servidor, de acordo com a modalidade exemplar, a caixa S fará uma determinação da classificação de sensível a aplicativo para determinar o enlace adequado de rede para a transmissão do pacote de volta à caixa C (de modo análogo ao da determinação feita pela caixa C para determinar o enlace de rede adequado para a transmissão do pacote de solicitação à caixa S). Neste caso, como o pacote de dados contém uma resposta da web a uma solicitação de HTTP Get, a caixa S pode determinar que o enlace de LFN é o enlace adequado de rede. Além disso, a caixa S precisará determinar o fluxo específico ao qual o pacote pertence. De acordo com uma modalidade, esta determinação é feita com base na Tabela de informações de Fluxo compilada pela caixa S. Um exemplo de tal Tabela de Informações de Fluxo é dado abaixo na Tabela 2. A Tabela de Informações de Fluxo inclui um registro (fileira) para cada fluxo de dados de cliente de fonte original. Com referência à Tabela @, duas tais registro de fluxo de dados de fonte são mostrados. O primeiro registro reflete um fluxo transmitido através do DI A da caixa C, proveniente do endereço de IP original (privado, por exemplo) do cliente de fonte respectivo (192.168.10.2) para o endereço de IP de destinação do servidor de destinação respectivo (23.202.245.155) - obtido pela caixa S do cabeçalho de fluxo 406 (que se originou, pelo menos parcialmente, do cabeçalho 401 de IP). As demais informações de fluxo registradas para este luxo de dados consistem em um número de porta de fonte do cliente de fonte respectivo (4928) e a porta de destinação do servidor de destinação (443) - obtido pela caixa S do cabeçalho 402 de TCP. Adicionalmente, as informações de fluxo registradas na tabela para este fluxo também incluem uma porta de saída (2931) (que é um número de porta de fonte gerado pela caixa S e fornecido ao servidor de destinação como sendo a porta de fonte no cabeçalho 408 de TCP) e um identificador de protocolo (6) (que identifica o tipo de protocolo - UDP ou TCP, por exemplo) . De modo análogo o segundo registro reflete um fluxo transmitido pelo TID B da caixa C, do endereço de IP original (privado) da cliente de fonte respectivo (192.168.20.5) ao endereço de IP de destinação do servidor de destinação respectivo (171.161.203.100); e reflete um número de porta de fonte do cliente de fonte respectivo (2718), a porta de destinação do servidor de destinação (443) e a porta de saída da caixa S (2932), e o identificador de protocolo (6).Tabela 2; Tabela de Informações de Fluxo

[048] Quando a caixa S recebe o pacote, ela obtém as informações de porta de saída da caixa S para o fluxo respectivo proveniente do cabeçalho 428 de TCP e usa este identificador de porta para acessar as informações de fluxo respectivas da Tabela de Informações de Fluxo. Se a porta de saída da caixa S for 2931, por exemplo, então a caixa S determina que o pacote pertence a um fluxo transmitido por meio do TID A da caixa C, do endereço de IP e da porta do cliente de fonte (endereço 192.168.10.2 e da porta 4928) ao endereço de IP e à porta de destinação do Servidor de destinação (ao endereço 23.202.245.155 e à porta 443), e usando o tipo de protocolo identificado pelo protocolo entre a caixa C e a caixa S. Além disso, com base no tid da caixa C determinado a partir do registro da Tabela de Informações de Fluxo respectivo e do enlace de rede através do qual a caixa S pretende transmitir o pacote, a caixa S obtém o endereço de IP respectivo (endereço de IP público, por exemplo) da caixa C respectiva para o enlace a partir da Tabela de Registro. Com base nestas informações, a caixa S encapsula o pacote 446 de TCP para transmissão à caixa C por meio da LFN. Para o cabeçalho 422 do TCP, a caixa S insere os números das portas de fonte e de destinação do servidor e do cliente de fonte. Para o cabeçalho de fluxo 426, a caixa S insere o endereço de IP de fonte e o endereço de IP de destinação obtidos do registro respectivo da Tabela de Informações de Fluxo, de modo que a caixa C possa determinar o luxo de cliente específico ao qual o pacote pertence. A caixa S encapsula o cabeçalho de fluxo 426/cabeçalho 422 de TCP/dados 423 como um pacote de UDP ou de TCP (dependendo do tipo de protocolo determinado) para utilizar a conexão de protocolo apropriada entre a caixa S e a caixa C através do enlace de rede respectivo. Além disso, a caixa S encapsula aquele pacote como um pacote de IP, com o cabeçalho 424 de IP incluindo o endereço de IP da caixa S como o endereço de fonte e o endereço de IP da caixa C (endereço de IP público, por exemplo) para o enlace de rede respectivo como o endereço de destinação.

[049] Quando a caixa C recebe o pacote da caixa S, ela extrai o cabeçalho de fluxo 426, o cabeçalho 425 de UDP/TCP e o cabeçalho 424 de IP do pacote para recuperar o pacote 447 do TCP. Além disso, a caixa C recupera o endereço de IP e o número da porta do cliente de fonte original e recupera o endereço de IP e o número da porta de destinação do servidor de destinação das informações do cabeçalho de fluxo 426. A caixa C então encapsula o pacote 447 de TCP como um pacote de IP, com o cabeçalho 421 do IP incluindo o endereço de IP de servidor como o endereço de fonte e o endereço de IP de cliente como o endereço de destinação - como se o pacote tivesse vindo diretamente do servidor, por exemplo. No tocante ao cabeçalho 422 do TCP, conforme montado pela caixa S, o cabeçalho inclui os números de porta de fonte e de destinação do servidor e do cliente de fonte - também como se o pacote tivesse vindo diretamente do servidor. Além disso, como a caixa C respectiva recebe os pacotes de um fluxo de fonte específico (independentemente do enlace de rede específico entre a caixa C e a caixa S respectivas e através do qual cada pacote foi transmitido), a caixa C pode remontar o fluxo com base no cabeçalho 422 de TCP.

[050] Além disso, como são inseridos novos cabeçalhos (cabeçalho de UDP/TCP e informações sobre fluxo) em pacotes, pode ser encontrado um problema com a unidade de transmissão máxima (MTU). Se o tamanho do pacote original for o MTU do caminho, por exemplo, o pacote será abandonado quando forem inseridos novos cabeçalhos adicionais (uma vez que o pacote excederá o tamanho de MTU para o caminho). Para superar tais problemas com MTU, de acordo com modalidades exemplares, o valor do tamanho de segmento máximo (MSS) dos pacotes respectivos TCP SYN e SYN-ACK é alterado. A título de exemplo, quando um pacote TCP SYN chega na caixa C e um pacote TCP SYN-ACK chega na caixa S, para as conexões de TCP respectivas, cada caixa intermediária modificará a opção de MSS para acomodar as informações sobre o cabeçalho adicional. Se o valor original de MSS for 1460, por exemplo, então o novo valor de MSS se torna 1460 - Lh, em que Lh reflete o comprimento dos cabeçalhos adicionais. Consequentemente, quando se negociam os parâmetros de MSS/MTU de TCP com o cliente e o servidor, a caixa C e a caixa S (a caixa C em relação ao cliente e a caixa S em relação ao servidor) negociarão o tamanho do segmento para deixar espaço para a adição dos respectivos cabeçalhos. Nesse contexto, a caixa C e a caixa S, por exemplo, negociam parâmetros de conexão de TCP fim-a-fim.

Classificação de mensagens:

[051] Conforme foi introduzido acima, de acordo com modalidades exemplares, a classificação de mensagens é aplicada para a identificação dos tipos de mensagens de dados para encaminhar pequenas mensagens interativas através de um caminho de LLN (um caminho de rede de latência relativamente baixa, por exemplo) e para enviar mensagens grandes através de um caminho de LFN (um caminho de rede de satélite geossincrônico). A título de ex, as mensagens de aperto de mão de TCP e as mensagens de estabelecimento de sessão de SSL/TLS são geralmente mensagens pequenas em comparação com mensagens de resposta de HTTPS, mas elas são interativas. Assim, elas podem ser transmitidas através de um caminho de LLN por meio de caixas intermediárias, o que reduz significativamente o tempo de conexão minimizando ao mesmo tempo o consumo de dados através do caminho de LLN. Além disso, as mensagens de solicitação de HTTPS provenientes de clientes são geralmente mensagens de pequeno tamanho e cabem em um pacote de TCP, mas a transmissão destas mensagens sofre um atraso maior do que as mensagens de resposta, devido ao processamento BoD do tráfego à montante (conforme discutido acima). A título de um outro exemplo, portanto, as mensagens de solicitação de HTTPS, portanto, podem também ser enviadas através de um caminho de LLN por meio das caixas intermediárias. Como um outro exemplo, um usuário pode fazer upload de arquivo de grande tamanho usando SSL/TLS (para serviços de armazenamento em nuvem, por exemplo, usando SSL/TLS (número de porta 443 de TCP) para fazer upload e download de arquivos para segurança e privacidade). A transmissão de tal tráfego de SSL/TLS (upload seguro de arquivos de imagens e de vídeos para armazenamento em nuvem) através do caminho de LLN, no entanto, resultaria em um uso de largura de banda grande de LLN para um aplicativo não sensível a atraso. Para resolver este problema, a título de um outro exemplo, o sistema/caixa intermediária pode limitar a quantidade de dados em upload por fluxo. Em seguida, quando se estiver fazendo um upload de uma quantidade de dados que excedem o limite, os pacotes adicionais do fluxo seriam enviados através de um caminho de LFN.

[052] Por outro lado, mensagens de resposta de HTTPS são geralmente muito maiores do que as mensagens de solicitação. Além disso, as mensagens de resposta de HTTPS são criptografadas, de modo que não é possível se identificar o tamanho da mensagem ou o tipo de mensagem (arquivos de imagens, arquivos de vídeos, arquivos de texto pequeno, por exemplo, etc.) Mesmo que os registros de SSL/TLS forneçam o tamanho de mensagens de SSL/TLS, quando uma mensagem de aplicativo é repartida em uma multiplicidade de mensagens (segmentadas no nível de SSL/TLS), é difícil e pouco prático tentar e determinar o tamanho real da mensagem do aplicativo. Além disso, a divisão de uma mensagem de resposta para enviá- la através de um caminho de LFN e de um caminho de LLN não seria eficaz ou prático em termos de tempo de download, pois o anfitrião final (o cliente e a caixa C, por exemplo) ainda tem que esperar até receber a mensagem completa da resposta. De acordo com as modalidades exemplares, portanto, as mensagens de resposta de HTTPS podem ser enviadas através dos caminhos de LFN. Além disso, as modalidades exemplares da presente invenção seriam aplicáveis a outras regras/diretrizes de classificação (como pode ser facilmente determinado para diferentes protocolos de comunicação, por exemplo).

[053] De acordo com modalidades exemplares, para se classificar diferentes mensagens, pode ser empregada uma abordagem de tabela de filtro ou de correlação. As Figuras 5A e 5B ilustram diagramas de blocos ilustrando uma arquitetura para uma abordagem de classificação por tabela de correlação múltipla, de acordo com as modalidades exemplares da presente invenção. Quando um pacote chega na caixa intermediária, o pacote passa por estágios de tabelas de correlação. Em seguida com base na marcação de pacotes em cada estágio, o pacote é encaminhado às interfaces de rede adequadas para encapsulamento e transmissão através do enlace de rede respectivo. Com referência à Figura 5A, de acordo com as modalidades exemplares, o mecanismo de classificação de mensagens dentro de cada caixa intermediária (caixa C e caixa S) compreenderá um módulo de classificação de mensagens 501 e um módulo de encaminhamento 503.

[054] A título de exemplo, com referência à Figura 5B, a classificação de primeiro estágio pode ser baseada em uma tabele de correlação baseada em porta (Tabela 0) que classifica pacotes de mensagens com base no número da porta de destinação. Em tal primeiro estágio, pacotes de mensagens podem ser classificados com base em números de porta bem conhecidos que são associados com determinados aplicativos e/ou tipos de mensagem. Tais classificações bem conhecidas baseadas em portas podem incluir mensagens de consulta DNS (número de porta UDP 53), mensagens de HTTP (número de porta 80 de TCP), mensagens OCSP (número de porta 80 de TCP), mensagens de SSL/TLS (número de porta 443 de TCP) e outras. Depois do primeiro estágio, cada pacote pode ser passado para um segundo estágio de classificação que utiliza uma abordagem de classificação especial, dependendo do resultado da classificação baseada em porta para o pacote. A título de um outro exemplo, como as mensagens de HTTP e mensagens de OCSP geralmente usam ambas o mesmo número de porta de TCP (80), os pacotes que incluem a porta 80 como a porta de destinação do cabeçalho de TCP podem ser enviados a um segundo estágio de classificação que utiliza uma tabela de filtro de endereços de IP de destinação específica (Tabela 4). A classificação pela Tabela 4 pode incluir, por exemplo, uma lista de endereços de IP do servidor de OCSP que diferencia mensagens de OCSP de mensagens de HTTP com base na correlação do endereço de IP com um endereço na lista de endereços do servidor de OCSP da Tabela 4. Além disso, tal tabela de endereços de IP de servidor de OCSP pode ser gerada com base nos endereços de IP dados em resposta durante a fase de consulta de DNS para os nomes de servidores respectivos de OCSP. Como resultado deste segundo estágio, as mensagens na porta 80 que tem um endereço de IP de OCSP correlacionado seriam então marcadas para transmissão por meio da interface de enlace de LLN (interface de rede terrestre, por exemplo) da caixa C ou S.

[055] A título de um outro exemplo, como os pacotes endereçados à porta 53 são classificados como mensagens de consulta de DNS, os pacotes respectivos podem ser marcados para transmissão através do enlace de LLN sem se aplicar nenhum outro estágio de classificação.

[056] A título de outro exemplo, depois da classificação com base em porta, os pacotes de TCP com a porta 443 podem ser repassados para um segundo estágio de classificação que filtra os pacotes de TCP com base no tamanho do payload (Tabela 1). Neste estágio, os pacotes de mensagens de SSL/TLS da porta 443 podem ser filtrados para diferenciar entre pacotes de aperto de mão/controle de TCP e pacotes de dados baseados no tamanho de payload de pacote. Quando o tamanho de payload indica, por exemplo, que a totalidade da mensagem está incluída em um pacote (tamanho de payload = 0, por exemplo), então esse pacote é determinado como sendo uma mensagem de configuração ou de controle e pode assim ser marcado para ser enviada pelo enlace de LLN.

[057] Alternativamente, para pacotes de mensagens da porta 443 maiores, a título de um outro exemplo, para se classificar tais mensagens de SSL/TLS por tipo, pode ser aplicada uma classificação baseada em mensagem. Quando o tamanho de mensagem é superior à MTU, a mensagem é segmentada em uma multiplicidade de pacotes de TCP. O primeiro pacote segmentado porta o cabeçalho de registro de SSL/TLS, mas os pacotes segmentados seguintes não portam os registros de SSL/TLS. Assim a classificação tradicional com base em pacotes não pode saber se os pacotes segmentados seguintes são mensagens de estabelecimento de sessão de SSL/TLS ou mensagens de dados de aplicativo de SSL/TLS. De acordo com uma modalidade, portanto, é aplicado um método de classificação dinâmico (Tabela 2), usando-se a classificação à base de payload para manipular as mensagens segmentadas. A título de exemplo, podem ser usados dois campos do cabeçalho de registro de TLS: tipo de conteúdo e comprimento. O campo do tipo de conteúdo do cabeçalho de registro de TLS indica se as mensagens de TLS são mensagens de estabelecimento de sessão ou mensagens de dados de aplicativo - de modo que, com base neste indicador, os pacotes da mensagem respectiva podem ser marcados para transmissão por meio do enlace de rede adequado (com base na mensagem ser uma mensagem de estabelecimento de sessão ou uma mensagem de dados de aplicativo, por exemplo). O campo de comprimento do cabeçalho de registro de TLS indica se a mensagem está segmentada e quantos pacotes segmentados constituem a mensagem. Quando a mensagem é recebida, é obtido o campo de comprimento do cabeçalho de registro de TLS, e quando o campo de comprimento especifica que a mensagem é maior do que o tamanho de pacote, fica determinado que a mensagem é segmentada em uma multiplicidade de pacotes. As informações sobre o luxo para a mensagem são registradas (conforme descrito acima), assim como o tamanho da mensagem restante. Subsequentemente, quando cada pacote da mensagem segmentada é recebido o tamanho da mensagem restante é atualizado, e quando todos os pacotes de mensagem segmentada são recebidos (o tamanho da mensagem restante se torna zero, por exemplo), as informações armazenadas para essa mensagem podem ser deletadas.

[058] De acordo com outras modalidades sobre classificação de mensagens, um estágio de classificação adicional pode ser aplicado com base no nível de assinatura ou outros limites na capacidade do enlace para um enlace de rede específico. A título de exemplo, um estágio de filtro de limitador de fluxo pode ser aplicado com base no limite da capacidade da assinatura do cliente (Tabela 3) para o tráfego de cliente agregado utilizando esse enlace de rede (o enlace de LLN pode ter um limite de capacidade máxima periódica para um Cliente específico, por exemplo, com base no nível da assinatura do Cliente). Consequentemente, o filtro da Tabela 3 pode rastreado quando o tráfego do cliente atinge um limite de capacidade para o enlace respectivo, filtrando então os pacotes de mensagem dos fluxos de dados desse Cliente e encaminhando-os por meio do enlace de LFN (independentemente de qualquer classificação de mensagem aplicada por estágios anteriores) para evitar exceder o limite de capacidade respectivo. Consequentemente, qualquer estágio individual anterior pode ser encaminha através do estágio de classificação da Tabela 3 (conforme indicado pelos caminhos tracejados da Figura 58 através da Tabela 3). Este filtro se destina a evitar um volume elevado de dados provenientes do upload passando através de um caminho de LLN com uma cota de dados limitada. Se o fluxo exceder o limite de dados de fluxo, os pacotes no fluxo serão enviados através da rede com uma cota de dados elevada (o caminho de LFN, por exemplo).

[059] Conforme pode ser observado, diversos estágios de classificação adicional ou combinações de estágios adicionais de classificação podem ser aplicados às portas ilustradas na Figura 5B, ou a portas adicionais (Porta xxx na Tabela N), com base em outras regras de encaminhamento e portas conhecidas associadas com outros tipos de aplicativo/mensagem, sem que haja desvio do âmbito e ideias de modalidades da presente invenção. Além disso, logo que se completa o processo de classificação da mensagem, os pacotes de dados da mensagem são encaminhados ao módulo de encaminhamento 503, sendo aplicado o tunelamento de caminhos múltiplos e sendo os pacotes providos à interface de rede adequada da caixa intermediária respectiva.

Controle de Tráfego Definido pelo Usuário:

[060] De acordo com modalidades exemplares, cada usuário/assinante pode ter exigências de cotas de dados diferentes para os caminhos auxiliares de rede LLN (uma rede de dados celular terrestre, por exemplo), tal como através de serviços terrestres diferentes da Internet e planos de dados. Consequentemente, tais modalidades proporcionam um controle do tráfego definido pelo usuário, podendo um usuário configurar um plano de dados e perfil de preferência de caminho do tráfego em uma caixa intermediária (durante o processo de registro, por exemplo). A título de exemplo, o sistema pode empregar mensagens de registro para repassar perfis de usuário respectivos à caixa S e proporcionar mensagens periódicas de manter vivo para periodicamente atualizar e monitorar a quantidade usada de dados na caixa C e na caixa S. A título de um outro exemplo, um usuário pode configurar uma preferência de caminho específico por tipos de mensagem e limitador de dados para cada enlace e configurar este perfil dentro da caixa C respectiva. Uma vez configuradas, as mensagens de registro repassam as informações do perfil à caixa S e a caixa S armazena o perfil do usuário e o utiliza na determinação dos caminhos adequados para mensagens respectivas. Além disso, uma caixa C poderia consumir a quantidade usada de dados sem passar pela caixa S. A consulta de DNS e as mensagens de OCSP, por exemplo, podem ser enviadas diretamente aos servidores através d uma rede terrestre. Assim a caixa C pode ser configurada para atualizar periodicamente a caixa S para o limitador de dados disponível respectivo para cada enlace. Para se obter isso, as mensagens de manter vivo podem portar um objeto de quantidade usada, que indica a quantidade usada de dados que não passaram pela caixa S para que a caixa S conserve uma quantidade usada de dados precisa no tocante ao limitador aplicável. A Figura 6 ilustra um formato de mensagem para controle de tráfego definido por usuário, de acordo com uma modalidade exemplar da presente invenção. De acordo com formato ilustrado na Figura 6, as mensagens de registro portam um cabeçalho de fluxo, objeto de limite ou de limitador e objeto de caminho, e as mensagens de manter vivo portam cabeçalho de fluxo e objeto de quantidade usada.

[061] A título de um outro exemplo, com base no perfil do usuário, a caixa C controla o tráfego à montante e a caixa S controla o tráfego à jusante. Se a quantidade usada de dados de uma LLN (rede terrestre, por exemplo) atinge o plano de dados permitido, a caixa C e a caixa S em seguida enviam o tráfego através dos caminhos de LFN (caminhos de rede de satélite, por exemplo). Este controle de tráfego definido por usuário permite que os usuários evitem os custos extras pelo uso deste sistema.

[062] A título de um outro exemplo, a caixa C pode inserir um carimbo de hora na solicitação de registro e mensagens de manter vivo à montante, e a caixa S pode enviar de volta o carimbo de hora em resposta de registro e mensagens de manter vivo à jusante, de modo que a caixa C pode periodicamente monitorar o atraso das redes respectivas. O atraso medido pode então ser usado para determinar periodicamente atrasos de caminho relativos. Por este motivo, se ocorrer uma situação em que um caminho de LLN apresenta um atraso maior em relação aos caminhos de LFN (devido a congestionamento de enlaces ou outros problemas com o desempenho, por exemplo), o sistema pode então recorrer aos caminhos de LFN para todo o tráfego até a situação ser resolvida ou se tornar disponível um caminho alternativo de LLN.

Implementação

[063] Em sistemas de rede de satélite, de acordo com uma modalidade, as caixas S estão localizadas em sites de gateway de satélite, pois todo o tráfego de satélite passa pelo gateway. De acordo com outras modalidades, no entanto, não há nenhuma limitação de localizações da caixa S. consequentemente, levando-se em conta os muitos locais de implementação potenciais para uma caixa S, de acordo com uma outra modalidade exemplar, uma caixa C pode ser configurada com um mecanismo ou processo para a localização da caixa S mais adequada em qualquer ponto dado no tempo - tal como sempre que se dá uma nova partida na caixa C. Além disso, tal mecanismo para localizar uma caixa S respectiva pode ser por consulta de DNS. Alternativamente, a atribuição da caixa S a uma caixa C dada pode, por exemplo, ser baseada na implementação da caixa S de um provedor de serviço de rede respectivo, e pode ser implementado através de um protocolo de partida provido à caixa C pelo provedor.

[064] No tocante à graduação da caixa S, as caixas S podem apresentar problemas com a graduação dinâmica, pois eles manipulam fluxos entre caixas C e servidores da web. Durante o tempo ocupado e de pico, por exemplo, uma caixa S exige uma potência de processamento computacional maior, ao passo que durante um tempo não é de pico, a caixa S pode exigir menos potência de processamento. De acordo com outras modalidades exemplares, tal problema com a graduação dinâmica pode ser atenuado usando-se computação de nuvem, que pode empregar o lançamento dinâmico de casos VM e mecanismos de equilíbrio de cargas dentre caixas S.

[065] Além disso, como tais abordagens com caixas intermediárias de sistema podem ser implementadas para modalidades exemplares por meio de um sistema de computação de nuvem, podem ser empregadas tecnologias e abordagens de rede definida por software (SDN) para gerenciar serviços de rede. Sem SDN, quando há uma reconfiguração/nova provisão de rede, e quando há alterações no perfil de usuário, os administradores de rede têm que lidar manualmente com as alterações. Uma abordagem de SDN, no entanto, permite que os administradores de rede gerenciem facilmente as alterações, usando o controlador central da SDN. Assim, esta abordagem de SDN permite que o sistema abaixe os custos com gerenciamento e gerencie rapidamente as alterações dinâmicas de rede e de perfis de usuário. Além disso, a abordagem de SDN poderia ser configurada para empregar abordagens em que fluxos correlatos seriam enviados às caixas intermediárias respectivas adequadas.

[066] Embora modalidades exemplares da presente invenção possam prover diversas implementações (incluindo componentes de hardware, firmware e/ou software, por exemplo) e, a não ser que seja declarado em contrário, todas as funções são desempenhadas por uma CPU ou por um processador executando um código de programa executável por computador armazenado em uma memória não transitória ou em meio de armazenamento legível por computador, os diversos componentes podem ser implementados em diferentes configurações de hardware, firmware, software e/ou uma combinação deles. Exceto na medida em que é descrito em contrário no presente documento, os diversos componentes mostrados em esboço ou em forma de blocos nas figuras são individualmente bem conhecidos e a sua construção interna e operação não são críticas nem para a fabricação nem para o uso da presente invenção ou para a descrição do melhor modo dela.

[067] No relatório precedente, foram descritas diversas modalidades com referência aos desenhos apensos. Será, portanto, evidente que diversas modificações podem ser introduzidas nelas, e podem ser implementadas modalidades adicionais, sem que haja desvio de um âmbito mais amplo da invenção conforme ela é apresentada nas reivindicações que seguem. O relatório e os desenhos, consequentemente, devem ser considerados em um sentido ilustrativo e não restritivo.

Claims (5)

1. Método, compreendendo: receber, por um dispositivo de proxy de cliente (C-box) localizado em um nó de cliente (cliente) de uma rede de comunicação de dados (152, 158), uma pluralidade de pacotes de dados de cliente (442) de um fluxo de dados de cliente de fonte originando-se de um dispositivo de cliente de fonte (cliente) por uma sessão de comunicação segura entre o dispositivo de cliente fonte (cliente) e um dispositivo de servidor de destinação (servidor), em que cada um da pluralidade de pacotes de dados de cliente (442) compreende um payload de dados de cliente (403) e uma estrutura de cabeçalho de cliente com base em um ou mais protocolos de comunicação (401, 402); determinar uma classificação de mensagem (501) para cada um dos pacotes de dados de cliente (442) com base em um ou mais parâmetros com base em aplicativo associados com um aplicativo do qual se originou o pacote de dados de cliente (442); modificar a estrutura de cabeçalho de cliente (401, 402) de cada um dos pacotes de dados de cliente (442) por encapsulamento do pacote de dados de cliente com base em um respectivo protocolo de comunicação de dados de proxy de cliente e, então, gerar um respectivo pacote de dados de proxy de cliente compreendendo o respectivo payload de dados de cliente (403) e uma respectiva estrutura de cabeçalho de proxy de cliente (404, 405, 406), em que a estrutura de cabeçalho de proxy de cliente compreende informações de fluxo (406) incluindo parâmetros de cliente de fonte e de servidor de destinação e um identificador do dispositivo de proxy de cliente (C-box), um ou mais parâmetros de protocolo da estrutura do cabeçalho de cliente indicando pelo menos um sequenciamento pelo protocolo de fonte do pacote de dados de cliente (442), e os parâmetros do respectivo protocolo de comunicação de dados de proxy de cliente incluindo pelo menos um parâmetro de fonte do dispositivo de proxy de cliente (C- box) e pelo menos um parâmetro de destinação de um dispositivo de proxy de servidor (S-box) localizado em um nó de servidor (servidor) ou de gateway da rede de comunicação de dados (152, 158); selecionar um enlace dentre uma multiplicidade de enlaces de comunicação de rede (LLN, LFN) para a transmissão de cada pacote de dados de proxy de cliente ao dispositivo de proxy de servidor (S-box), em que a seleção é com base na classificação da mensagem determinada do respectivo pacote de dados de cliente (442); e transmitir cada pacote de dados de proxy de cliente ao dispositivo de proxy de servidor (S-box) por meio do respectivo enlace de comunicação de rede (LLN, LFN) selecionado de acordo com o respectivo protocolo de comunicação de dados de proxy de cliente, em que o respectivo protocolo de comunicação de dados de proxy de cliente é configurado para a transmissão dos pacotes de dados de proxy de cliente ao dispositivo de proxy de servidor (S-box) por meio de uma conexão de protocolo respectiva através do respectivo enlace de comunicação de rede (LLN, LFN); CARACTERIZADO pelo fato de que o dispositivo de proxy de cliente processa as transmissões de pacotes através de cada um dos enlaces de comunicação de rede (LLN, LFN) como um único fluxo através dos enlaces de comunicação de rede de acordo com o respectivo protocolo de comunicação de dados de proxy de cliente, sem dividir a sessão de comunicação segura do fluxo de dados de cliente de fonte e, assim, preservando a segurança de ponta a ponta da sessão de comunicação segura, em que a divisão da sessão de comunicação segura compreende dividir a sessão de comunicação segura em uma sessão entre o cliente fonte (Cliente) e o dispositivo de proxy de cliente (C-box); uma sessão entre o dispositivo de proxy de cliente (C-box) e o dispositivo de proxy de servidor (S-box); e uma sessão entre o dispositivo de servidor de proxy (S-box) e o dispositivo de servidor de destino; e com base na informação de fluxo (406) da estrutura de cabeçalho de proxy de cliente, o protocolo de comunicação de dados de proxy de cliente pode ser retirado de cada pacote de dados de proxy de cliente recebido pelo dispositivo de servidor de proxy (S-box) através da pluralidade de comunicações de rede enlaces (LLN, LFN) e os pacotes de dados do cliente podem ser remontados no fluxo de dados do cliente de origem.

2. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que compreende ainda: receber, pelo dispositivo de proxy de servidor (S-box), o pacote de dados de proxy de cliente (442); fazer um registro de fluxo de cliente em uma tabela de informações (Tabela 2) sobre fluxo para o fluxo de dados de cliente de fonte, em que o registro de fluxo de cliente inclui os parâmetros de cliente de fonte e servidor de destinação a partir das informações de fluxo da estrutura de cabeçalho de proxy de cliente, do respectivo identificador do dispositivo de proxy de cliente (A, B) e de um identificador de fonte do dispositivo de proxy de servidor (S-box) específicos ao registro de fluxo; modificar a estrutura de cabeçalho de proxy de cliente (404, 405, 406) de cada pacote de dados de proxy de cliente para gerar respectivos segundos pacotes de dados de cliente (443), cada compreendendo o payload de dados de cliente (403) e uma estrutura de cabeçalho de servidor de cliente (407, 408), em que a estrutura de cabeçalho de servidor de cliente compreende parâmetros de protocolo de transmissão de proxy de servidor incluindo os parâmetros de servidor de destinação provenientes das informações de fluxo da estrutura de cabeçalho de proxy de cliente, um parâmetro de endereço de fonte do dispositivo de proxy de servidor (S-box), e o identificador de fonte de dispositivo de proxy de servidor; e transmitir os segundos pacotes de dados de cliente (443) ao dispositivo de servidor de destinação (servidor).

3. Método, de acordo com a reivindicação 2, CARACTERIZADO pelo fato de que compreende: receber, pelo dispositivo de servidor de destinação (servidor), os segundos pacotes de dados de cliente (443); gerar um respectivo pacote de dados de servidor (445), cada um compreendendo um payload de dados de servidor (423) que se refere aos pacotes de dados de cliente e uma estrutura de cabeçalho de servidor (427, 428) com base em um ou mais protocolos de comunicação de dados, em que a estrutura de cabeçalho de servidor compreende os parâmetros de protocolo de comunicação de servidor que incluem um parâmetro de endereço de fonte do dispositivo de servidor de destinação (servidor), o parâmetro de endereço de fonte do dispositivo de proxy de servidor (S-box) e o identificador de fonte de dispositivo de proxy de servidor; e transmitir o pacote de dados de servidor (445) ao dispositivo de proxy de servidor (S-box).

4. Método, de acordo com a reivindicação 3, CARACTERIZADO pelo fato de que compreende ainda: receber, pelo dispositivo de proxy de servidor (S-box), os primeiros pacotes de dados de servidor (445); determinar uma classificação de mensagem (501) para cada pacote de dados de servidor com base em um ou mais dos parâmetros à base de aplicativo associados com um aplicativo do qual se originou o pacote de dados de servidor (445); adquirir o registro de fluxo de cliente da tabela de informações de fluxo consultando o registro baseado no identificador de fonte de dispositivo proxy de servidor incluído na estrutura de cabeçalho de servidor do primeiro pacote de dados de servidor (445); modificar a estrutura de cabeçalho de servidor (427, 428) de cada um dos pacotes de dados de servidor por encapsulamento do pacote de dados de servidor baseado em um respectivo protocolo de comunicação de dados de proxy de servidor e, então, gerar um respectivo pacote de dados de proxy de servidor (446) compreendendo o payload de dados de servidor (423) e uma estrutura de cabeçalho de proxy de servidor (424, 425, 426), em que a estrutura de cabeçalho de proxy de servidor compreende informações proveniente do registro de fluxo de cliente incluindo os parâmetros de cliente de fonte e servidor de destinação, um ou mais parâmetros de protocolo da estrutura de cabeçalho de servidor indicando pelo menos um sequenciamento de protocolo de fonte do pacote de dados de servidor (445) e os parâmetros de um respectivo protocolo de comunicação de dados de proxy de servidor incluindo pelo menos um parâmetro de fonte do dispositivo de proxy de servidor (S-box) e pelo menos um parâmetro de destinação do dispositivo de proxy de cliente (C-box); selecionar um enlace da multiplicidade de enlaces de comunicação de rede (LFN) para a transmissão do pacote de dados de proxy de servidor (446) ao dispositivo de proxy de cliente (C-box), sendo a seleção baseada na classificação de mensagem (501) determinada do primeiro pacote de dados de servidor (445); transmitir cada um dos pacotes de dados de proxy de servidor ao dispositivo de proxy de cliente (C-box) por meio do respectivo enlace de comunicação de rede (LLN, LFN) selecionado de acordo com o respectivo protocolo de comunicação de dados de proxy de cliente, em que o protocolo de comunicação de dados de proxy é configurado para a transmissão do pacote de dados de proxy de servidor ao dispositivo de proxy de cliente (c-box) por meio de uma conexão de protocolo respectiva através do respectivo enlace de comunicação de rede (LLN, LFN).

5. Método, de acordo com a reivindicação 4, CARACTERIZADO pelo fato de que compreende ainda: receber, pelo dispositivo proxy de cliente (c-box), os pacotes de dados de proxy de servidor; modificar a estrutura de cabeçalho de proxy de servidor (424, 425, 426) de cada um dos pacotes de dados de proxy de servidor para gerar um segundo pacote de dados de servidor (427) compreendendo o payload de dados de servidor (423) e uma estrutura de cabeçalho de cliente de servidor (421, 422), em que a estrutura de cabeçalho de cliente de servidor compreende os parâmetros de protocolo da estrutura de cabeçalho de servidor indicando pelo menos o sequenciamento do protocolo de fonte do primeiro pacote de dados de servidor, e os parâmetros de protocolo de comunicação de cliente incluindo o parâmetro de endereço de fonte do dispositivo de servidor de destinação (servidor) e um parâmetro de endereço de destinação do dispositivo de cliente de fonte (cliente); e transmitir os segundos pacote de dados de servidor (447) ao dispositivo de cliente de fonte (cliente).

Images