Durante sete prévios dias viu TCP/IP e os seus protocolos associados cobertos na profundidade considerável. É agora tempo para começar a olhar para TCP/IP em um mais largo sentido. Hoje aprende como TCP/IP pode funcionar com outros protocolos em um sistema em rede. Também aprende sobre protocolos que não usam TCP/IP mas se encontram comumente.
É útil entender como TCP/IP funciona em conjunto com outros protocolos para que a gestão de TCP/IP seja mais clara (aprende sobre a direção de uma rede TCP/IP durante os próximos poucos dias). Poderia encontrar que algum material hoje se repete de dias mais adiantados ou se reformula ligeiramente para apresentar uma abordagem diferente ao sujeito. De certo modo, hoje ações como um sumário, embora incompleto, do sistema TCP/IP no conjunto.
Para preencher o dia, olho para os serviços opcionais diversos fornecidos por TCP/IP. A maioria dedica-se a uma tarefa simples, mas realmente servem o seu objetivo bem e usam TCP/IP, daqui a sua inclusão aqui.
TCP/IP não muitas vezes se encontra como um único protocolo. É normalmente um de vários protocolos usados em qualquer rede dada. Por isso, as interações entre TCP/IP (e os seus protocolos associados) e outros protocolos que poderiam estar trabalhando com ele devem entender-se. É o mais fácil começar a olhar para este sujeito de um ponto de vista de rede local e logo estender aquela visão de cobrir interredes.
As camadas de um protocolo TCP/IP, bem como a maior parte de outros protocolos OSI-modelares, projetam-se para ser independentes um de outro, permitindo a mistura de protocolos. Quando uma mensagem deve enviar-se sobre a rede a uma máquina remota, cada camada de protocolo baseia-se no pacote da informação enviada da camada em cima, acrescentando a sua própria cabeçada e logo passando o pacote à seguinte camada mais baixa. Depois de receber-se sobre a rede (empacotado em qualquer formato de rede se necessita), a máquina de recepção passa o pacote suportam as camadas, retirando a informação sobre cabeçada uma camada de uma vez.
Substituir qualquer camada na pilha de protocolo precisa que os novos protocolos possam interredes com outras camadas, bem como executar todas as funções necessárias daquela camada (por exemplo, duplicando os serviços do protocolo substituído). Também, executar operações duplicadas em mais de uma camada (operações redundantes) deve evitar-se por razões óbvias.
Para examinar o funcionamento de redes das camadas e a substituição ou a adição de outros, uma instalação simples pode usar-se como um ponto de partida. A figura 8.1 mostra uma arquitetura em camadas simples usando TCP e IP com a rede de Ethernet. A figura 8.1 também mostra a reunião de pacotes de Ethernet como passam da camada à camada.
A figura 8.1. Uma arquitetura em camadas simples.
Como viu antes neste livro, o processo começa com uma mensagem de alguma forma de Upper Layer Protocol (ULP) que ele mesmo passa uma mensagem de uma aplicação. Como a mensagem passa-se a TCP, acrescenta a sua própria informação sobre cabeçada e passos à camada IP, que faz o mesmo. Quando a mensagem IP se passa à camada de Ethernet, Ethernet acrescenta a sua própria informação na frente e verso da mensagem e distribui a mensagem sobre a rede.
O próprio sistema operacional não é nem uma camada mas corre em todas as partes da arquitetura em camadas inteira com conexões a cada camada. As interfaces entre protocolos de cada camada diferenciam-se dependendo da máquina de anfitrião, mas é conveniente ignorar a influência do sistema operacional para a simplicidade.
Embora este modelo simples pudesse parecer ideal, na prática tem alguns problemas. O mais importantemente, necessita que a IP inter-relacione diretamente com a camada de Ethernet. Esta interface não é um limpo; tem muitas conexões que estalam da arquitetura em camadas ideal.
Estender-se sobre o sistema em camadas necessita uma melhor compreensão das interfaces para a camada de rede em uma LAN. A figura 8.2 mostra uma arquitetura de camada estendida de uma LAN. Este tipo da arquitetura solicita sentido de choque múltiplo acesso (CSMA) e redes de choque descobre (CD) como Ethernet.
A figura 8.2. Arquitetura de rede.
A LAN implica algumas camadas adicionais. A camada de Logical Link Control (LLC) é uma interface entre a camada IP e as camadas de rede. Há várias espécies de configurações LLC, mas é suficiente neste ponto saber o seu papel básico como um buffer entre a rede e camadas IP como um sistema simples de um serviço connectionless ou como um sistema complicado de um serviço baseado na conexão. LLC usa-se normalmente com o Controle de Conexão de Dados de Alto nível padrão de conexão (de HDLC). Para o serviço connectionless, isto usa uma armação de mensagem de informação não numerada (UI), ao passo que os serviços baseados na conexão podem usar a armação de mensagem de modo equilibrado assíncrono (ABM), ambos apoiados por HDLC. A configuração de LLC com respeito a TCP/IP é importante.
A camada de Media Access Control (MAC) mencionou-se resumidamente no Dia 2, "TCP/IP e a Internet". MAC é responsável pelo tráfego gerente na rede, como detecção de choque e tempos de transmissão. Também trata funções de retransmissão e cronômetros. MAC é independente do meio de rede mas é dependente do protocolo usado na rede.
A camada física na arquitetura de Rede compõe-se de vários serviços. Attachment Unit Interface (AUI) fornece um anexo entre a camada física da máquina e o meio de rede. Tipicamente, o AUI é onde os portos de rede ou os macacos se localizam.
Medium Attachment Unit (MAU) compõe-se de duas partes: Physical Medium Attachment (PMA) e Medium Dependent Interface (MDI), ambos os quais podem considerar-se como partes separadas como mostrado no número. O MAU é responsável por dirigir a conexão da máquina ao próprio meio de LAN, bem como fornecer a verificação de integridade de dados básicos e a monitorização de meio de rede. O MAU tem funções que verificam a qualidade de sinal da rede e testam rotinas para verificar a operação correta da rede.
Quando estas camadas se acrescentam à arquitetura em camadas de uma pilha de protocolo, a camada de IP-Ethernet separa-se. Isto mostra-se na Figura 8.3. Este tipo da configuração é mais comum do que um mostrado na Figura 8.1 e chama-se normalmente a configuração IP/802 (porque Ethernet se define pela especificação IEEE 802).
A figura 8.3. TCP/IP com LLC/MAC.
A LAN IP/802 pode ser connectionless utilização de uma forma simples de LLC chamado LLC Type 1, que apoia a informação não numerada (UI). O LLC e a ajuda de camadas MAC separam IP da camada física. Mais cabeçadas acrescentam-se ao pacote de mensagem, mas estes têm a informação útil. A cabeçada LLC tem tanto fonte como pontos de acesso a serviço (SAP) de destino nela para identificar as camadas em cima.
UDP usa-se frequentemente em vez de TCP neste tipo da rede. UDP não é tão complexo como TCP, portanto a complexidade da rede inteira se reduz. Contudo, UDP não tem funcionalidade de integridade de mensagem construída em, portanto uma forma diferente de LLC (chamou LLC Type 2) se usa que implementa estas funções. LLC Type 2 fornece a funcionalidade de integridade de dados que TCP normalmente fornece, como sequencing, gestão de janela de transferência e controle de fluxo. A desvantagem é que estas funções são agora em baixo da camada IP, em vez do acima mencionado ele. Em caso de problemas fatais com a camada LLC, isto pode resultar em problemas que devem tratar-se na própria camada de aplicação.
As diferenças entre TCP e LLC Type 1 contra UDP e LLC Type 2 devem pesar-se cuidadosamente por um administrador de sistema. A combinação TCP/LLC 1 é mais complexa do que UDP/LLC 2 mas oferece a confiança excelente e a integridade, ao passo que UDP/LLC 2 é melhor para redes de alta quantidade tratada. Em alguns casos, UDP/LLC 2 resulta em funções duplicadas, porque as versões LLC se diferenciam consideravelmente entre vendedores.
Um sistema operacional de rede orientado ao PC popular é NetBIOS, que pode integrar-se limpamente a TCP/IP. A figura 8.4 mostra a arquitetura de rede desta espécie da LAN. NetBIOS reside acima do TCP ou protocolo UDP, embora normalmente tenha conexões sólidas naquela camada (portanto as duas camadas não podem separar-se limpamente). NetBIOS atua para unir aplicações em conjunto nas camadas superiores, fornecendo a alocação de recurso e a transmissão de mensagens.
A figura 8.4. A arquitetura de Rede de NetBIOS.
Três números de porto de Internet alocam-se para NetBIOS. Estes são para o serviço de nome de NetBIOS (porto 137), serviço de datagrama (porto 138) e serviço de sessão (porto 139). Também há a provisão de um mapeamento entre Domain Name Service (DNS) de Internet e o Servidor de Nome de NetBIOS (NBNS). (DNS é coberto detalhadamente no Dia 11, "Serviço de Nome de domínio".) O Servidor de Nome de NetBIOS usa-se para identificar PCs que funcionam em uma área de NetBIOS. Na interface entre NetBIOS e TCP, um mapeamento entre os nomes usa-se para produzir o nome de DNS.
IP pode configurar-se para correr acima de NetBIOS, eliminando TCP ou UDP inteiramente e dirigindo NetBIOS como um serviço connectionless. Neste caso, NetBIOS assome as funções da camada TCP/UDP, e os protocolos de camada superiores devem ter a integridade de dados, pacote sequencing e funções de controle de fluxo. Isto mostra-se na Figura 8.5. Nesta arquitetura, NetBIOS encapsula datagramas IP. O mapeamento forte entre IP e NetBIOS é necessário para que os pacotes de NetBIOS reflitam endereços IP. (Para fazer isto, NetBIOS codifica os nomes como IP.nnn.nnn.nnn.nnn.)
A figura 8.5. Dirigir IP acima de NetBIOS.
Este tipo da rede precisa que os protocolos de camada superiores (ULPs) tratem todas as características necessárias do protocolo TCP, mas a vantagem consiste em que a arquitetura de rede é simples e eficiente. Para algumas redes, este tipo da aproximação ajusta-se bem, embora o desenvolvimento de ULPs conveniente possa ser problemático de vez em quando.
Xerox Network System (XNS) usou-se largamente no passado e ainda conserva uma percentagem razoável do uso de rede. XNS é popular porque a Xerox lançou o código ao domínio público, daqui fazendo-o um sistema de rede rentável. Na maioria dos casos, os protocolos de XNS projetaram-se para trabalhar com Ethernet de Xerox, também. XNS agora aparece em vários pacotes de software de rede comerciais.
XNS pode usar IP, como mostrado na Figura 8.6. Sequenced Packet Protocol (SPP) está acima da camada IP, fornecendo alguma função de TCP, embora não seja um protocolo tão completo. Na camada ULP é o protocolo de Mensageiro, que fornece apresentação e serviços de camada de sessão.
A figura 8.6. A arquitetura de Rede XNS.
XNS usa os Protocolos de Transporte de Internet de termo para referir-se ao jogo de protocolos usados, inclusive IP. Entre os protocolos é Routing Information Protocol (RIP) e um protocolo incorreto semelhante a Internet Control Message Protocol (ICMP).
NetWare de Novell que transmite produto em rede tem um protocolo semelhante a IP chamado a Troca de Pacote de Internet (IPX), que é baseado em XNS de Xerox. A arquitetura IPX mostra-se na Figura 8.7. IPX normalmente usa UDP para um protocolo connectionless, embora TCP possa usar-se quando combinado com LLC Type 1.
A figura 8.7. A arquitetura de Rede IPX.
O empilhamento das camadas (com IPX acima de UDP) assegura que o UDP e as cabeçadas IP não se afetam, com a informação IPX encapsulada como parte do processo de mensagem habitual. Como com outros protocolos de rede, um mapeamento é necessário entre o endereço IP e os endereços de IPX. IPX usa rede e números de anfitrião de 4 e 6 bytes, respectivamente. Estes convertem-se como se passam a UDP.
É possível reconfigurar a rede para usar redes IPX usando TCP em vez de UDP e substituindo LLC Type connectionless 1 protocolo. Isto resulta na arquitetura mostrada na Figura 8.8. Usando esta arquitetura de camada, fazem o mapa de endereços IP usando ARP.
A figura 8.8. Uma arquitetura de Rede baseada em IPX.
ARCnet usa-se largamente para a LAN e tem uma Internet RFC para usá-lo com IP. A arquitetura é semelhante àquela da rede baseada em IPX mas com ARCnet que substitui IPX, como mostrado na Figura 8.9. As mensagens passadas de IP encapsulam-se em datagramas ARCnet.
A figura 8.9. A arquitetura de Rede situada em ARCnet.
Uma colocação especial do datagrama IP atrás da área de dados de cliente da cabeçada ARCnet assegura que a compatibilidade IP se mantém se a mensagem dever passar fora da rede ARCnet (por um convertedor). Fazem o mapa de endereços IP a endereços de ARCnet usando ARP. O protocolo também apoia RARP até certo ponto.
Fiber Distributed Data Interface (FDDI) é uma rede de alta velocidade ANSI-definida que usa o fio ótico pela fibra como um meio de transporte. FDDI adianta-se o suporte de cadeia por causa do máximo em todas as partes disto pode realizar-se. Para TCP/IP, FDDI usa uma arquitetura em camadas como outras redes discutidas. FDDI diferencia-se ligeiramente de outros meios de comunicação nisto há duas subcamadas da camada física.
O endereçamento de FDDI de esquema é semelhante a outras redes de Ethernet, necessitando um mapeamento simples, como visto com o sistema de Ethernet. IP e ARP podem usar-se ambos sobre FDDI. IP usa-se com LLC Type 1 serviço connectionless.
O tamanho de imagem de FDDI estabelece-se em 4.500 bytes, inclusive a cabeçada e outra informação sobre esboço. Depois que isto considera-se, há 4.470 bytes disponíveis para dados. (A Internet RFC de FDDI define 4.096 bytes de dados e 256 bytes de camadas de cabeçada acima da camada MAC.) Este grande tamanho de pacote pode causar problemas de alguns portões, portanto o encaminhamento de pacotes FDDI deve escolher-se cuidadosamente para prevenir o truncamento ou a corrupção do pacote por um portão que não pode tratar o grande tamanho de imagem. Em caso da dúvida, os pacotes de FDDI devem reduzir-se no tamanho a 576 bytes de dados.
As redes de X.25 modificam a arquitetura de rede usando uma camada OSI TP4 em cima de IP e a camada de Packet Layer Procedures (PLP) X.25 em baixo de IP. Isto mostra-se na Figura 8.10. TP4 é um protocolo parecido a TCP que não usa identificadores de porto. O destino e os campos de fonte na cabeçada são os pontos de acesso a serviço de transporte (TSAPs). TP4 é mais complexo do que TCP, que às vezes trabalha contra ele.
A figura 8.10. A arquitetura de Rede baseada em X.25.
X.25 não muitas vezes se usa em uma LAN, mas usa-se como uma conexão a uma rede trocada pelo pacote. Uma Internet RFC define as regras da comutação de pacotes baseada em IP X.25, inclusive os limites de tamanhos de datagrama IP (576 bytes) e circuitos virtuais.
O ISDN (ISDN) fornece redes TCP/IP trocadas pelo pacote. A arquitetura mostra-se na Figura 8.11. IP não está na pilha porque se incorpora normalmente em CLNP. (Tanto TCP como IP podem usar-se com ISDN em vez de OSI TP4 e CLNP, mas as versões ISDN se otimizam para aquela rede.)
A figura 8.11. A arquitetura de Rede baseada em ISDN.
ISDN usa uma arquitetura mais complexa do que a maior parte de redes, substituindo portões e encaminhadores com adaptadores terminais e nós ISDN. Estes executam as funções equivalentes mas têm um mais rígido (e complexo) arquitetura interna. Os detalhes não são relevantes aqui, portanto o leitor interessado se entrega a um bom livro de ISDN.
Switched Multi-Megabit Data Services (SMDS) o sistema é um público serviço connectionless trocado pelo pacote que provê a alta quantidade tratada de grandes tamanhos de pacote (até 9.188 bytes de dados). SMDS usa um assinante da rede e mecanismo de acesso de rede ao assinante do controle de fluxo. SMDS trabalha com IP inter-relacionando o SMDS à camada LLC.
SMDS que usa IP apoia múltiplas subredes IP lógicas (LISs), que pode dirigir-se separadamente mas tratar-se como uma unidade única por SMDS. Este método necessita que todas as subredes tenham ao mesmo endereço IP. A arquitetura das camadas SMDS é bastante complexa, portanto não são cobertos detalhadamente aqui. SMDS usa LLC Type 1 armações.
Dois novos protocolos de interredes de alta velocidade que ficam populares são Asynchronous Transfer Mode (ATM) e Faixa larga ISDN (BISDN). A arquitetura na máquina do usuário é semelhante às arquiteturas TCP/IP discutidas antes, embora as camadas adicionais possam acrescentar-se para fornecer novos serviços, como capacidades vídeo e sólidas.
O encaminhador, o portão ou outro dispositivo que acessa a rede de alta velocidade são mais complexos também. Chamado um adaptador terminal (como com ISDN), fornece uma interface moderna entre camadas de usuário e camadas de adaptação, que são específicas para a aplicação. Do adaptador terminal, o tráfego passa-se ao serviço ATM, que fornece a comutação e a multiplexão de serviços.
Como se supõe que o Windows 95 se torne o sistema operacional dominante em máquinas de PC que dirigem um DOS ou sistema operacional de Windows, vale a pena tomar uma olhada rápida para como o Windows 95 integra o software de ligação em rede no seu núcleo. A aproximação usada pelo Windows 95 é semelhante àquele do Windows NT e OS/2, portanto o conhecimento é útil para muitos sistemas operacionais em dispositivos de cliente comuns na LAN de hoje.
O Windows 95 refina a arquitetura de rede usada no Windows para Grupos de trabalho e Windows NT, resultando em melhor realização e confiança, bem como satisfazendo as exigências de exigências de rede diferentes como múltiplo suporte de protocolo. Como o Windows 95 apoia muitos protocolos de rede diferentes em 16-e Motorista de Modo Virtual de 32 bits (VxD) versões, a arquitetura deve fornecer a flexibilidade para acomodar um número de estruturas.
A arquitetura do Windows 95 é em camadas; uma arquitetura em camadas é o mais comum estrutura de ligação em rede (como OSI e TCP/IP). A arquitetura de rede usada no Windows 95 conhece-se como Windows Open Services Architecture (WOSA) de Microsoft. WOSA desenvolveu-se para permitir a aplicações trabalhar com vários tipos de rede diferentes, e inclui o grupo de interfaces projetadas para permitir a coexistência de vários componentes de rede.
Os componentes de software de ligação em rede do Windows 95 mostram-se nas suas respetivas camadas na Figura 8.12. Muitos dos componentes de rede são familiares de versões mais adiantadas do Windows de Grupos de trabalho, Windows NT, ou outros sistemas operacionais e protocolos de comunicações. Olho para cada camada na arquitetura do Windows 95 em um pouco mais detalhe para que a função de cada componente se entenda melhor. Como as aplicações de 32 bits ficam dominantes com o Windows 95 e Windows NT, olharei para eles nesta seção. As mais velhas aplicações de 16 bits tratam-se ligeiramente diferentemente, mas os princípios são o mesmo.
A figura 8.12. A arquitetura de software de ligação em rede do Windows 95 mostrando os componentes.
Uma das caraterísticas principais do Windows 95 é a inclusão do suporte de múltiplos protocolos simultâneos. O protocolo à revelia é IPX/SPX de NetWare. Também incluído são motoristas de NetBEUI e NetBIOS e VxD de 32 bits completo de TCP/IP. Todos estes motoristas são tomada-e-jogo permitida, permitindo a carga e descarga dinâmica.
O suporte de 95 de Windows de múltiplos protocolos realiza-se por Network Driver Interface Specification (NDIS), que é um superjogo do NDIS usado no Windows para Grupos de trabalho e Windows NT. O motorista NDIS 3.1 tem três partes: o próprio protocolo (que pode implementar-se por vendedores da terceira pessoa) e o gerente de protocolo, o MAC ou o miniporto e o empacotador de miniporto. O gerente de protocolo NDIS carrega e descarrega protocolos como necessário.
A versão de NDIS incluído com o Windows 95 acrescenta aumentos de tomada-e-jogo e novos minimotoristas. A capacidade de tomada-e-jogo acrescenta-se ao gerente de protocolo e a camada de Media Access Control (MAC), deixando motoristas de rede carregar e descarregar dinamicamente. O minimotorista (que é compatível com os modelos de minimotorista usados no Windows NT 3.5) reduz o montante do código que deve escrever-se para apoiar um adaptador de rede.
O Windows 95 permite o suporte de muitos servidores de rede concorrentemente. Isto é uma melhora sobre o Windows de Grupos de trabalho 3.11, que permitiu só a sua própria rede e uma rede adicional. O suporte de servidor do Windows 95 fornece-se por Network Provider Interface (NPI). Usando múltiplos protocolos de rede ao mesmo tempo, pode fundar uma máquina do Windows 95 para usar TCP/IP para redes UNIX, e NetBEUI ou IPX/SPX de redes de PC locais, se quiser. Alternativamente, como vê no Dia 10, "Fundando uma Rede de TCP/IP de Mostra: DOS e Clientes de Windows", pode fazer que o Windows 95 seja uma máquina TCP/IP-based pura.
As redes de TCP/IP oferecem um número de serviços opcionais que os usuários e as aplicações podem usar. Todos estes serviços opcionais têm definições estritas dos seus protocolos. Estes serviços opcionais e os seus números de porto destinados mostram-se na Tabela 8.1.
|
Serviço |
Porto |
Descrição |
|
Usuários ativos |
11 |
Devolve os nomes de todos os usuários no sistema remoto |
|
Gerador de caráter |
19 |
Regressos todos os carateres ASCII prontos para impressão |
|
Dia |
13 |
Devolve a data e tempo, dia da semana e mês do ano |
|
Descarte |
9 |
Descartes todas as mensagens recebidas |
|
Eco |
7 |
Regressos qualquer mensagem |
|
Citação do dia |
17 |
Devolve uma cotação |
|
Tempo |
37 |
Devolve o tempo desde primeiro de janeiro de 1900 (durante segundos) |
O serviço de Usuários Ativo devolve uma mensagem ao usuário que se origina que contém uma lista de todos os usuários atualmente ativos na máquina remota. O comportamento do TCP e versões UDP é o mesmo. Quando solicitado, o serviço de Usuários Ativo controla o porto 11 e, depois do estabelecimento de uma conexão, responde com uma lista dos usuários atualmente ativos e logo fecha o porto. UDP envia um datagrama, e TCP usa a própria conexão.
O serviço de Gerador de Caráter projeta-se para enviar o grupo de carateres de ASCII. Recebendo um datagrama (os conteúdos do qual se ignoram), o serviço de Gerador de Caráter devolve uma lista de todos os carateres ASCII prontos para impressão. O comportamento do TCP e as versões UDP do Gerador de Caráter são ligeiramente diferentes.
O Gerador de Caráter TCP controla o porto 19, e depois da conexão ignora toda a entrada e retorna uma corrente de carateres até que a conexão se quebre. A ordem de carateres fixa-se. O serviço de Gerador de Caráter UDP controla o porto 19 para um datagrama de entrada (lembre-se, UDP não cria conexões) e responde com um datagrama que contém um número aleatório de carateres. Até 512 carateres podem enviar-se.
Embora este serviço pudesse parecer inútil, realmente tem objetivos diagnósticos. Pode assegurar que uma rede pode transferir os 95 carateres ASCII prontos para impressão propriamente, e também pode usar-se para testar impressoras para a sua capacidade de imprimir todos os carateres.
O serviço Diurno devolve uma mensagem com a data atual e tempo. O formato que usa é o dia da semana, mês do ano, dia do mês, tempo e o ano. O tempo especifica-se em um formato de HH:MM:SS. Cada campo separa-se por espaços para permitir analisar dos conteúdos.
Tanto TCP como as versões UDP controlam o porto 13 e, recebendo um datagrama, devolvem a mensagem. O serviço Diurno pode usar-se com vários objetivos, inclusive a colocação de calendários de sistema e relógios para minimizar variações. Também pode usar-se por aplicações.
O serviço de Descarte simplesmente descarta tudo que recebe. TCP espera por uma conexão no porto 9, ao passo que UDP recebe datagramas por aquele porto. Algo de entrada se ignora. Nenhuma resposta se envia.
O serviço de Descarte poderia parecer inútil, mas pode ser útil para mensagens de experiência de encaminhamento durante a organização de sistema e a configuração. Também pode usar-se por aplicações no lugar de um serviço de descarte do sistema operacional (como/dev/null em UNIX).
O serviço de Eco devolve o que recebe. Chama-se pelo porto 7. Com TCP, simplesmente volta quaisquer dados baixam a conexão, ao passo que UDP devolve um datagrama idêntico (exceto a fonte e endereços de destino). Os ecos continuam até que a conexão de porto se quebre ou nenhum datagrama se recebe.
O serviço de Eco fornece a diagnóstica muito boa sobre o funcionamento apropriado da rede e os próprios protocolos. A confiança de transmissões pode testar-se este caminho, também. O tempo de tempo usado de enviar à recepção do eco fornece medições úteis de tempos de resposta e latência dentro da rede.
A Citação do serviço de Dia faz como o seu nome contém. Devolve uma cotação de um arquivo de citações, à toa selecionando uma um dia quando um pedido chega ao porto 17. Se um arquivo original de cotações não estiver disponível, o serviço falha.
O serviço de Tempo devolve o número de segundos que passaram desde primeiro de janeiro de 1990. O porto 37 acostuma-se ao enumerado de um pedido (TCP) ou receba um datagrama de entrada (UDP). Quando um pedido se recebe, o tempo envia-se como um número binário de 32 bits. Está à altura da aplicação de recepção para converter o número em um número útil.
O serviço de Tempo muitas vezes usa-se para sincronizar máquinas de rede ou para estabelecer relógios dentro de uma aplicação.
Como já mencionado, os serviços opcionais podem acessar-se de uma aplicação. Os usuários podem acessar diretamente o seu serviço da escolha (assunção que se apoia) usando Telnet. Um exemplo simples mostra-se aqui:
$ telnet merlin 7 Trying... Connected to merlin.tpci.com Escape character is '^T'. This is a message This is a message Isn't this exciting? Isn't this exciting? <Ctrl+T> $ telnet merlin 13 Trying... Connected to merlin.tpci.com Escape character is '^T'. Tues Jun 21 10:16:45 1994 Connection closed. $ telnet merlin 19 !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[[\]^_abcdefg "#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[[\]^_abcdefgh #$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[[\]^_abcdefghi $%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[[\]^_abcdefghij %&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[[\]^_abcdefghijk &'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[[\]^_abcdefghijkl '()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[[\]^_abcdefghijklm <Ctrl+T> $
Neste exemplo, uma conexão para transportar 7 partidas em diagonal uma sessão de Eco. Todo datilografado pelo usuário se ecoa atrás imediatamente, inalterado. Então uma conexão ao porto 13 fornece o serviço Diurno, mostrando a data atual e tempo. A conexão quebra-se pelo serviço uma vez que os dados se enviam. Finalmente, o Gerador de Caráter começa-se. Tanto os serviços de Gerador de Caráter como Eco terminaram-se com a sequência de intervalo de Telnet de Ctrl+T.
Cobri muito material neste capítulo, pela maior parte sobre o modo que TCP/IP pode interagir com outros sistemas de ligação em rede e protocolos. Combinando TCP/IP com redes existentes, as vantagens de ambos podem ganhar-se, bem como compatibilidade de oferecimento com uma ampla variação de dispositivos baseados em TCP.
Também olhei para vários protocolos que preenchem a família TCP/IP. Estes são serviços pela maior parte básicos, mas são essenciais para o funcionamento apropriado de uma rede TCP/IP-based.
Qual é o papel da camada de Media Access Control (MAC) em uma arquitetura de rede?
A camada MAC trata o tráfego da rede, inclusive choques e cronômetros. O MAC é independente do meio físico da rede, mas o seu papel exato e a implementação dependem dos protocolos de rede.
Qual é a diferença entre o Tipo 1 LLC e o Tipo 2 LLC?
O Tipo 1 de Logical Link Control (LLC) é uma forma mais simples que apoia a informação não numerada, projetada para TCP. LLC Type 2 é para UDP e oferece a funcionalidade de integridade de mensagem.
O que é XNS?
XNS é o Sistema de Rede de Xerox, um desenho de ligação em rede que a Xerox lançou ao domínio público. Como XNS é essencialmente livre, ganhou muito suporte. XNS apoia Ethernet.
O que é ISDN?
O ISDN é uma rede de alta velocidade trocada pelo pacote que apoia a faixa larga (muitos canalizam) as comunicações.
Porque é um protocolo de rede simples como o Gerador de Caráter apoiado?
Tão simples como pode ser, o protocolo de Gerador de Caráter (e muitos outros como ele) usa-se para tarefas básicas e perguntas que necessitariam codificação muito mais complexa e operações quando executado como parte de um protocolo maior. O protocolo de Gerador de Caráter é útil para testar comunicações. É pequeno, rápido, fácil implementar, e fácil entender.
