O texto de ontem examinou Internet Protocol (IP) no detalhe considerável. Como poderia lembrar-se, o Protocolo de Internet trata a funcionalidade de camada mais baixa. Hoje olho para a camada de transporte, onde Transmission Control Protocol (TCP) e User Datagram Protocol (UDP) entram no jogo.
TCP é um dos protocolos de camada de transporte o mais largamente usados, que se expandem da sua implementação original no ARPANET à união de sítios comerciais em todo o mundo. No Dia 1, "Sistemas abertos, Padrões e Protocolos", olhou para o modelo de sete camadas OSI, que carrega uma semelhança notável ao modelo em camadas de TCP/IP, portanto não é surpreendente que muitas das características da camada de transporte de OSI fossem baseadas em TCP.
Na teoria, um protocolo de camada de transporte pode ser uma rotina de software muito simples, mas TCP não pode chamar-se simples. Porque usam uma camada de transporte que é tão complexa como TCP? A razão mais importante depende da insegurança de IP. Como viu ontem, IP não garante a entrega de um datagrama; é um sistema connectionless sem confiança. IP simplesmente trata o encaminhamento de datagramas, e se os problemas ocorrerem, IP descarta o pacote sem um longo pensamento (gerando uma mensagem de erro ICMP atrás ao remetente no processo). A tarefa de apurar a posição dos datagramas enviou sobre uma rede e tratar o reenvio da informação se as partes se descartaram quedas a TCP, em que podem pensar como espingarda que monta sobre IP.
A maior parte de usuários pensam em TCP e IP como um par justamente tricotado, mas TCP pode ser (e frequentemente é) usado com outros protocolos sem IP. Por exemplo, TCP ou as partes dele usam-se em File Transfer Protocol (FTP) e Simple Mail Transfer Protocol (SMTP), ambos os quais não usam IP.
O Protocolo de Controle de Transmissão fornece um número considerável de serviços à camada IP e as camadas superiores. O mais importantemente, fornece um protocolo orientado à conexão às camadas superiores que permitem a uma aplicação estar segura que um datagrama distribuído sobre a rede se recebeu em sua totalidade. Neste papel, TCP atua como um protocolo de validação da mensagem que fornece comunicações fiáveis. Se um datagrama se corromper ou se perder, TCP normalmente trata a retransmissão, em vez das aplicações nas camadas mais altas.
TCP não é uma parte do software. É um protocolo de comunicações. Quando instala uma pilha de TCP na sua máquina, instala a camada TCP, e normalmente muito mais software para fornecer o resto dos serviços TCP/IP. TCP usa-se como uma frase universal para TCP/IP em muitos casos.
TCP dirige o fluxo de datagramas das camadas mais altas à camada IP, bem como datagramas de entrada da camada IP até os protocolos de nível mais alto. TCP tem de assegurar que as prioridades e a segurança se respeitam propriamente. TCP deve ser capaz de tratar a terminação de uma aplicação acima dele que esperava datagramas de entrada, bem como fracassos nas camadas mais baixas. TCP também deve manter uma mesa estatal de todas as correntes de dados em e fora da camada TCP. A isolação de todos estes serviços em uma camada separada permite a aplicações projetar-se sem respeito a confiança de mensagem ou controle de fluxo. Sem a camada TCP, cada aplicação teria de implementar os próprios serviços, que é uns resíduos de recursos.
TCP reside na camada de transporte, posicionada acima de IP mas em baixo das camadas superiores e as suas aplicações, como mostrado na Figura 4.1. TCP só reside em dispositivos que de fato processam datagramas, assegurando que o datagrama foi da fonte à máquina de objetivo. Não reside em um dispositivo que simplesmente os datagramas de vias, então não há normalmente camada TCP em um portão. Isto faz sentido, porque em um portão o datagrama não tem necessidade de ir mais alto no modelo em camadas do que a camada IP.
A figura 4.1. TCP fornece comunicações de um extremo a outro.
Como TCP é um protocolo orientado à conexão responsável por assegurar a transferência de um datagrama da fonte à máquina de destino (comunicações de um extremo a outro), TCP deve receber mensagens de comunicações da máquina de destino para acusar o recebimento do datagrama. O circuito virtual do termo usa-se normalmente para referir-se às comunicações entre as duas máquinas de fim, a maioria das quais são mensagens de reconhecimento simples (confirmação do recibo ou um código de fracasso) e números de sequência de datagrama.
Para ilustrar o papel de TCP, é instrutivo para seguir uma mensagem de mostra entre duas máquinas. Os processos simplificam-se nesta etapa, para estender-se depois hoje. A mensagem origina-se de uma aplicação em uma camada superior e passa-se a TCP da seguinte camada mais alta na arquitetura por algum protocolo (muitas vezes tratava como um protocolo de camada superior ou ULP, para indicar que reside acima de TCP). A mensagem passa-se como uma corrente — uma sequência de carateres individuais enviados assincronamente. Isto é em contraste com a maior parte de protocolos, que usam blocos fixos de dados. Isto pode pôr alguns problemas de conversão com aplicações que tratam blocos só formalmente construídos de dados ou insistem em mensagens de tamanho fixo.
TCP recebe a corrente de bytes e reúne-os em segmentos TCP ou pacotes. No processo de reunir o segmento, a informação sobre cabeçada anexa-se em frente dos dados. Cada segmento manda calcular uma soma de controle e introduzido dentro da cabeçada, bem como um número de sequência se houver mais de um segmento na mensagem inteira. O comprimento do segmento determina-se normalmente por TCP ou por um conjunto de valores de sistema pelo administrador de sistema. (O comprimento de segmentos TCP não tem nada a ver com o comprimento de datagrama IP, embora haja às vezes uma relação entre os dois.)
Se as comunicações de duas vias se necessitarem (tal como com Telnet ou FTP), uma conexão (circuito virtual) entre o envio e recepção de máquinas estabelece-se antes da passagem do segmento a IP do encaminhamento. Este processo começa com o software TCP de envio emitindo um pedido em uma conexão TCP com a máquina de recepção. Na mensagem é um número único (chamou um número de tomada) que identifica a conexão de máquina de envio. O software TCP de recepção destina o seu próprio número de tomada único e retorna-o à máquina original. Dois números únicos então definem a conexão entre as duas máquinas até que o circuito virtual se termine. (Olho para tomadas em um pouco mais detalhe durante um momento.)
Depois que o circuito virtual estabelece-se, TCP envia o segmento ao software IP, que então emite a mensagem sobre a rede como um datagrama. IP pode executar alguma das modificações do segmento que viu no material de ontem, como fragmentação dele e reagrupá-lo na máquina de destino. Estes passos são completamente transparentes às camadas TCP, de qualquer modo. Depois de enrolar o seu caminho sobre a rede, o IP de máquina de recepção passa o segmento recebido até a camada TCP da máquina de recipiente, onde se processa e se passa até as aplicações acima dele usando um protocolo de camada superior.
Se a mensagem foi mais de um segmento TCP muito tempo (não datagramas de IP), o software TCP de recepção reagrupa a mensagem usando os números de sequência contidos na cabeçada de cada segmento. Se um segmento estiver falhando ou corrupto (que pode determinar-se da soma de controle), TCP devolve uma mensagem com o número de sequência defeituoso no corpo. O software TCP que se origina então pode reenviar o mau segmento.
Se só um segmento se usar para a mensagem inteira, depois de comparar a soma de controle do segmento com um valor recentemente calculado, o software TCP de recepção pode gerar uma confirmação da ordem positiva (ACK) ou um pedido de reenviar ao segmento e via o pedido atrás à camada de envio.
A implementação TCP da máquina de recepção pode executar um controle de fluxo simples para prevenir a sobrecarga de buffers. Faz isto enviando um tamanho de buffer chamou um valor de janela à máquina de envio, depois da qual o remetente pode enviar só bastantes bytes para encher a janela. Depois disto, o remetente deve esperar por outro valor de janela a receber-se. Isto fornece um protocolo handshaking entre as duas máquinas, embora diminua o tempo de transmissão e ligeiramente aumente o tráfego de rede.
O uso de uma janela instável é mais eficiente do que um bloco único envia e esquema de reconhecimento por causa de atrasos que esperam pelo reconhecimento. Implementando uma janela instável, vários blocos podem enviar-se ao mesmo tempo. Um protocolo de janela de escorregamento propriamente configurado fornece uma quantidade tratada muito mais alta.
Como com a maior parte de protocolos baseados na conexão, os cronômetros são um aspecto importante de TCP. O uso de um cronômetro assegura que um excessivo espera não se implica esperando por um ACK ou uma mensagem de erro. Se os cronômetros vencerem, uma transmissão incompleta assume-se. Normalmente um cronômetro de expiração antes do envio de uma mensagem de reconhecimento causa uma retransmissão do datagrama da máquina que se origina.
Os cronômetros podem causar alguns problemas com TCP. As especificações de TCP provêem o reconhecimento de só o número de datagrama mais alto que se recebeu sem erro, mas isto não pode tratar propriamente a recepção fragmentária. Se uma mensagem se compuser de vários datagramas que chegam fora da ordem, a especificação afirma que TCP não pode reconhecer a recepção da mensagem até que todos os datagramas se tenham recebido. Assim, mesmo se todos exceto um datagrama no meio da sequência se receberam com sucesso, um cronômetro poderia vencer e fazer que a todos os datagramas fossem ressentem-se. Com grandes mensagens, isto pode causar um aumento no tráfego de rede.
Se o software TCP de recepção receber datagramas duplicados (como pode ocorrer com uma retransmissão depois de um intervalo ou devido a uma transmissão duplicada de IP), a versão de recepção de TCP descarta qualquer datagrama duplicado, sem incomodar-se com uma mensagem de erro. No fim de tudo, o sistema de envio só cuidados que a mensagem se recebeu — não quantas cópias se receberam.
TCP não tem um reconhecimento negativo (NAK) função; confia em um cronômetro para indicar a falta do reconhecimento. Se o cronômetro tenha vencido depois de enviar o datagrama sem receber um reconhecimento do recibo, o datagrama supõe-se ter-se perdido e retransmite-se. O software TCP de envio guarda cópias de todos os datagramas não reconhecidos em um buffer até que se tenham propriamente reconhecido. Quando isto acontece, o cronômetro de retransmissão para-se, e o datagrama retira-se do buffer.
TCP apoia uma função de empurrão dos protocolos de camada superior. Um empurrão usa-se quando uma aplicação quer enviar dados imediatamente e confirmar que uma mensagem passada a TCP se transmitiu com sucesso. Para fazer isto, uma bandeira de empurrão estabelece-se na conexão ULP, instruindo que TCP para expedir qualquer armazenou em buffer a informação da aplicação ao destino o mais logo possível (ao contrário da propriedade dele no buffer até que esteja pronto para transmiti-lo).
Todas as aplicações de camada superior que usam TCP (ou UDP) têm um número de porto que identifica a aplicação. Na teoria, os números de porto podem destinar-se em máquinas individuais, ou contudo desejos de administrador, mas algumas convenções se adotaram para permitir melhores comunicações entre implementações TCP. Isto permite ao número de porto identificar o tipo do serviço que um sistema TCP está solicitando do outro. Os números de porto podem modificar-se, embora isto possa causar dificuldades. A maior parte de sistemas mantêm um arquivo de números de porto e o seu serviço correspondente.
Tipicamente, os números de porto em cima 255 reservam-se para o uso privado da máquina local, mas os números abaixo 255 se usam para processos frequentemente usados. Uma lista de números de porto frequentemente usados publica-se pela Internet Autoridade de Números Destinada e está disponível por um RFC ou de muitos sítios que oferecem arquivos de sumário de Internet de carregar. Os números de porto comumente usados nesta lista mostram-se na Tabela 4.1. Os números 0 e 255 reservam-se.
Número de porto |
Nome de processo |
Descrição |
1 |
TCPMUX |
Multiplexador de serviço de porto de TCP |
5 |
RJE |
Entrada de emprego remota |
7 |
ECO |
Eco |
9 |
DESCARTE |
Descarte |
11 |
USUÁRIOS |
Usuários ativos |
13 |
DIA |
Dia |
17 |
Citação |
Cotação do dia |
19 |
CHARGEN |
Gerador de caráter |
20 |
DADOS DO FTP |
Protocolo de transferência de arquivos • Dados |
21 |
FTP |
Protocolo de transferência de arquivos • Controle |
23 |
TELNET |
Telnet |
25 |
SMTP |
Protocolo de transferência de correio simples |
27 |
NSW-FE |
Parte dianteira de sistema de usuário de NSW |
29 |
MENSAGEM-ICP |
MENSAGEM-ICP |
31 |
MENSAGEM-AUTH |
Autenticação de MENSAGEM |
33 |
DSP |
Protocolo de suporte de exposição |
35 |
Servidores de impressão privados | |
37 |
TEMPO |
Tempo |
39 |
RLP |
Protocolo de posição de recurso |
41 |
GRÁFICA |
Gráfica |
42 |
NAMESERV |
Servidor de nome do host |
43 |
NICNAME |
Quem é |
49 |
SENHA DE ENTRADA |
Protocolo de anfitrião de senha de entrada |
53 |
DOMÍNIO |
Servidor de nome de domínio |
67 |
BOOTPS |
Servidor de protocolo de alça |
68 |
BOOTPC |
Cliente de protocolo de alça |
69 |
TFTP |
Protocolo de transferência de arquivos trivial |
79 |
DEDO |
Dedo |
101 |
HOSTNAME |
Servidor de nome do host de NIC |
102 |
OIS-TSAP |
OIS TSAP |
103 |
X400 |
X.400 |
104 |
X400SND |
X.400 SND |
105 |
CSNET-NS |
Servidor de nome de caixa do correio de CSNET |
109 |
POP2 |
O Protocolo v2 de Correio |
110 |
POP3 |
O Protocolo v3 de Correio |
111 |
RPC |
Sol RPC Portmap |
137 |
NETBIOS-NS |
Serviço de nome de NETBIOS |
138 |
NETBIOS-DG |
Serviço de datagrama de NETBIOS |
139 |
NETBIOS-SS |
Serviço de sessão de NETBIOS |
146 |
OIS-TP0 |
ISO TP0 |
147 |
OIS-IP |
OIS IP |
150 |
SQL-REDE |
REDE DE SQL |
153 |
SGMP |
SGMP |
156 |
SQLSRV |
Serviço de SQL |
160 |
SGMP-CAPTURAS |
CAPTURAS DE SGMP |
161 |
SNMP |
SNMP |
162 |
SNMPTRAP |
SNMPTRAP |
163 |
CMIP-ARRANJAR-SE |
Gerente de CMIP/TCP |
164 |
CMIP-REAGENTE |
Agente de CMIP/TCP |
165 |
XNS-mensageiro |
Xerox |
179 |
BGP |
Protocolo de portão de borda |
Cada circuito de comunicação em e fora da camada TCP identifica-se unicamente por uma combinação de dois números, que em conjunto se chamam uma tomada. A tomada compõe-se do endereço IP da máquina e o número de porto usado pelo software TCP. Tanto o envio como a recepção de máquinas têm tomadas. Como o endereço IP é único através das interredes, e os números de porto são únicos para a máquina individual, os números de tomada também são únicos através das interredes inteiras. Isto permite a um processo falar com outro processo através da rede, baseada inteiramente no número de tomada.
TCP usa a conexão (não o porto de protocolo) como um elemento fundamental. Uma conexão concluída tem dois pontos finais. Isto permite a um porto de protocolo usar-se para várias conexões que ao mesmo tempo (multiplexam).
A seção última examinou o processo de estabelecer uma mensagem. Durante o processo, o envio TCP solicita uma conexão com a recepção TCP, usando os números de tomada únicos. Este processo mostra-se na Figura 4.2. Se o envio TCP quer estabelecer uma sessão de Telnet do seu porto número 350, o número de tomada se comporia do endereço IP de máquina de fonte e o porto número (350), e a mensagem teria um número de porto de destino de 23 (o número de porto de Telnet). A recepção TCP tem um porto de fonte de 23 (Telnet) e um porto de destino de 350 (o porto de máquina de envio).
A figura 4.2. Fundar um circuito virtual com números de tomada.
O envio e a recepção de máquinas mantêm uma mesa de porto, que enumera todos os números de porto ativos. As duas máquinas implicadas inverteram entradas de cada sessão entre os dois. Isto chama-se atando e mostra-se na Figura 4.3. A fonte e os números de destino simplesmente invertem-se para cada conexão na mesa de porto. Naturalmente, os endereços IP, e daqui os números de tomada, são diferentes.
A figura 4.3. Entradas obrigatórias em mesas de porto.
Se a máquina de envio estiver solicitando mais de uma conexão, os números de porto de fonte são diferentes, embora os números de porto de destino pudessem ser o mesmo. Por exemplo, se a máquina de envio tentava estabelecer três sessões de Telnet simultaneamente, os números de porto de máquina de fonte poderiam ser 350, 351, e 352, e os números de porto de destino seriam todos 23.
É possível para mais de uma máquina compartilhar a mesma tomada de destino — um processo chamou a multiplexão. Na Figura 4.4, três máquinas estabelecem sessões de Telnet com um destino. Todos eles usam o porto de destino 23, que é a multiplexão de porto. Como os datagramas que emergem do porto têm a informação sobre tomada cheia (com endereços IP únicos), não há confusão quanto à qual trabalham a máquina um datagrama destina-se a.
A figura 4.4. Multiplexão de um porto de destino.
Quando múltiplas tomadas se estabelecem, é possível que mais de uma máquina pudesse enviar um pedido de conexão com a mesma fonte e portos de destino. Contudo, os endereços IP das duas máquinas são diferentes, portanto as tomadas ainda se identificam unicamente apesar de fonte idêntica e números de porto de destino.
TCP deve comunicar-se com aplicações na camada superior e um sistema de rede na camada abaixo. Várias mensagens definem-se para o protocolo de camada superior a comunicações TCP, mas não há método definido de TCP para falar de abaixar camadas (normalmente, mas não necessariamente, IP). TCP espera que a camada abaixo dele defina o método de comunicação. Supõe-se normalmente que TCP e a camada de transporte se comunicam assincronamente.
O TCP ao método de comunicação de protocolo de camada superior (ULP) é bem definido, composto do grupo de primitivos de pedido de serviço. Os primitivos implicados em ULP a comunicações TCP mostram-se na Tabela 4.2.
Ordem |
Parâmetros esperados |
| |
ABORTO |
Nome de conexão local |
ATIVO E ABERTO |
Porto local, tomada remota |
Opcional: intervalo de ULP, ação de intervalo, precedência, segurança, opções | |
ATIVO ABERTO COM DADOS |
O porto de fonte, tomada de destino, dados, comprimento de dados, empurra a bandeira, bandeira urgente |
Opcional: intervalo de ULP, ação de intervalo, precedência, segurança | |
ALOCAR |
Nome de conexão local, comprimento de dados |
Fechar |
Nome de conexão local |
"CHEIO PASSIVO ABERTO" |
Porto local, tomada de destino |
Opcional: intervalo de ULP, ação de intervalo, precedência, segurança, opções | |
RECEBER |
O nome de conexão local, endereço de buffers, conta de byte, empurra a bandeira, bandeira urgente |
ENVIAR |
O nome de conexão local, endereço de buffers, comprimento de dados, empurra a bandeira, bandeira urgente |
Opcional: intervalo de ULP, ação de intervalo | |
POSIÇÃO |
Nome de conexão local |
UNSPECIFIED-PASSIVE-OPEN |
Porto local |
Opcional: intervalo de ULP, ação de intervalo, precedência, segurança, opções | |
| |
ENCERRAMENTO |
Nome de conexão local |
ENTREGAR |
Nome de conexão local, armazene em buffer o endereço, o comprimento de dados, a bandeira urgente |
ERRO |
Nome de conexão local, descrição incorreta |
FRACASSO ABERTO |
Nome de conexão local |
CARTEIRA DE IDENTIDADE ABERTA |
Nome de conexão local, tomada remota, endereço de destino |
ÊXITO ABERTO |
Nome de conexão local |
RESPOSTA DE POSIÇÃO |
O nome de conexão local, porto de fonte, endereço de origem, tomada remota, estado de conexão, recebe a janela, envia a janela, montante esperando ACK, recibo de espera de montante, modo urgente, precedência, segurança, intervalo, ação de intervalo |
FINITO |
Nome de conexão local, descrição |
TCP permite a dois métodos estabelecer uma conexão: ativo e passivo. Um estabelecimento de conexão ativo acontece quando TCP emite um pedido na conexão, baseada em uma instrução de um protocolo de nível superior que fornece o número de tomada. Uma aproximação passiva realiza-se quando o protocolo de nível superior instrui TCP para esperar pela chegada de pedidos de conexão de um sistema remoto (normalmente de uma instrução aberta ativa). Quando TCP recebe o pedido, destina um número de porto. Isto permite a uma conexão prosseguir rapidamente, sem esperar pelo processo ativo.
Há dois primitivos abertos passivos. Um aberto passivo especificado cria uma conexão quando o nível de precedência e o nível de segurança são aceitáveis. Um aberto passivo não especificado abre o porto a qualquer pedido. O último usa-se por servidores que esperam por clientes de um tipo desconhecido para unir-se a eles.
TCP tem regras estritas sobre o uso de processos de conexão passivos e ativos. Normalmente um aberto passivo executa-se em uma máquina, enquanto um aberto ativo se executa no outro, com a informação específica sobre o número de tomada, precedência (prioridade) e níveis de segurança.
Embora a maior parte de conexões TCP se estabeleçam por um pedido ativo a um porto passivo, é possível abrir uma conexão sem uma espera de porto passiva. Neste caso, o TCP que envia um pedido em uma conexão inclui tanto o número de tomada local como o número de tomada remoto. Se a recepção que TCP se configura para permitir ao pedido (baseado nas colocações de segurança e precedência, bem como critérios baseados na aplicação), a conexão pode abrir-se. Este processo olha-se para novamente na seção intitulada "TCP e Conexões".
TCP usa vários cronômetros para assegurar que os atrasos excessivos não se encontram durante as comunicações. Vários destes cronômetros são elegantes, tratando problemas que não são imediatamente óbvios no momento da primeira análise. Os cronômetros usados por TCP examinam-se nas seções seguintes, que revelam os seus papéis na asseguração que os dados se enviam propriamente de uma conexão ao outro.
O cronômetro de retransmissão dirige intervalos de retransmissão (RTOs), que ocorrem quando um intervalo pré-ajustado entre o envio de um datagrama e a confirmação da ordem de restituição se excede. O valor do intervalo tende a variar, dependendo do tipo de rede, compensar diferenças de velocidade. Se o cronômetro vencer, o datagrama retransmite-se com um RTO ajustado, que se aumenta normalmente exponencialmente a um limite pré-ajustado máximo. Se o limite máximo se exceder, o fracasso de conexão assume-se, e as mensagens de erro passam-se atrás à aplicação de camada superior.
Os valores do intervalo determinam-se medindo o tempo médio que os dados tomam para transmitir-se a outra máquina e o reconhecimento recebido atrás, que se chama o tempo de viagem de ida e volta ou RTT. De experimentos, destes RTTs calcula a média uma fórmula que desenvolve um valor esperado, chamado o tempo de viagem de ida e volta alisado ou SRTT. Este valor então aumenta-se para prestar contas de atrasos imprevistos.
Depois que uma conexão TCP fecha-se, é possível para datagramas que ainda fazem o seu caminho pela rede para tentar acessar o porto fechado. O cronômetro tranquilo destina-se para impedir o porto recém-fechado de reabrir-se novamente rapidamente e receber estes datagramas últimos.
O cronômetro tranquilo faz-se normalmente em duas vezes a vida de segmento máxima (o mesmo valor que o Tempo para Viver o campo em uma cabeçada IP), assegurando que todos os segmentos que ainda se dirigem ao porto se descartaram. Tipicamente, isto pode resultar em um porto que está indisponível durante até 30 segundos, incitando mensagens de erro quando outras aplicações tentam acessar o porto durante este intervalo.
O cronômetro de persistência trata uma ocorrência regularmente rara. É possível que uma janela receber pudesse ter um valor de 0, causando a máquina de envio à transmissão de pausa. A mensagem para reiniciar o envio poderia perder-se, causando um atraso infinito. O cronômetro de persistência espera um tempo pré-ajustado e logo envia um segmento de um byte em intervalos predeterminados para assegurar que a máquina de recepção ainda se enche.
A máquina de recepção reenvia a mensagem de tamanho da janela nula depois de receber um destes segmentos de posição, se ainda for backlogged. Se a janela estiver aberta, uma mensagem que dá o novo valor devolve-se, e as comunicações retomam-se.
Tanto guardar - o cronômetro vivo como o cronômetro ocioso acrescentaram-se às especificações TCP depois da sua definição original. Guardar - o cronômetro vivo envia um pacote vazio regularmente para assegurar que a conexão a outra máquina ainda é ativa. Se nenhuma resposta se tenha recebido depois de enviar a mensagem em que o cronômetro ocioso venceu, supõe-se que a conexão se quebre.
Guardar - o valor de cronômetro vivo estabelece-se normalmente por uma aplicação, com valores nos limites de 5 para 45 segundos. O cronômetro ocioso estabelece-se normalmente em 360 segundos.
TCP usa algoritmos de cronômetro adaptáveis para acomodar atrasos. Os cronômetros ajustam-se aos atrasos experimentados sobre uma conexão, alterando os valores de cronômetro para refletir problemas inerentes.
TCP tem de guardar a pista de muita informação sobre cada conexão. Faz isto por Transmission Control Block (TCB), que contém a informação sobre os números de tomada locais e remotos, enviar e receba buffers, segurança e valores de prioridade e o segmento atual na fila. O TCB também se arranja enviam e recebem números de sequência.
O TCB usa várias variáveis para guardar a pista de enviar e receber a posição e controlar o fluxo de informações. Estas variáveis mostram-se na Tabela 4.3.
Nome da variável |
Descrição |
| |
SND.UNA |
Envie não reconhecido |
SND.NXT |
Envie depois |
SND.WND |
Envie janela |
SND.UP |
Número de sequência de jogo urgente último |
SND.WL1 |
Número de sequência de atualização de janela última |
SND.WL2 |
Número de reconhecimento de atualização de janela última |
SND.PUSH |
Número de sequência de jogo empurrado último |
ISS |
Inicial enviam o número de sequência |
| |
RCV.NXT |
Número de sequência de seguinte jogo recebido |
RCV.WND |
O número de jogos que podem receber-se |
RCV.UP |
Número de sequência de dados urgentes últimos |
RCV.IRS |
Inicial recebem o número de sequência |
Usando estas variáveis, TCP controla o fluxo de informações entre duas tomadas. Uma sessão de conexão de mostra ajuda a ilustrar o uso das variáveis. Começa com Machine Um desejo enviar cinco blocos de dados a Machine B. Se o limite de janela for sete blocos, um máximo de sete blocos pode enviar-se sem reconhecimento. A variável SND.UNA em Machine A indica quantos blocos se enviaram mas são não reconhecidos (5), e a variável SND.NXT tem o valor do seguinte bloco na sequência (6). O valor da variável SND.WND é 2 (sete blocos possíveis, menos cinco enviados), portanto mais só dois blocos podem enviar-se sem sobrecarregar a janela. O Machine B devolve uma mensagem com o número de blocos recebidos, e o limite de janela ajusta-se consequentemente.
A passagem de mensagens para a frente e para trás pode ficar bastante complexa como a máquina de envio adiante bloqueia não reconhecido até o limite de janela, espera pelo reconhecimento de blocos mais adiantados que se retiraram da sugestão de entrada, e logo envio de mais blocos para encher a janela novamente. O rastreamento dos blocos torna-se uma matéria da escrituração, mas com grandes limites de janela e tráfego através de interredes que às vezes fazem que a blocos se percam, o processo é, de muitos modos, notável.
Como mencionado antes, TCP deve comunicar-se com IP na camada abaixo (utilização de um método IP-defined) e aplicações na camada superior (usando os primitivos TCP-ULP). TCP também deve comunicar-se com outras implementações TCP através de redes. Para fazer isto, usa Unidades de Dados de Protocolo (PDUs), que se chamam segmentos na conversação TCP.
O leiaute do TCP PDU (comumente chamava a cabeçada) mostra-se na Figura 4.5.
A figura 4.5. A unidade de dados de protocolo TCP.
Os campos diferentes são como se segue:
Depois do PDU ou cabeçada é os dados. O campo de Opções tem uma função útil: para especificar o tamanho de buffer máximo uma recepção a implementação de TCP pode acomodar. Como TCP usa áreas de dados de comprimento variável, é possível para uma máquina de envio criar um segmento que é mais longo do que o software de recepção pode tratar.
O campo de Soma de controle calcula a soma de controle baseada no tamanho de segmento inteiro, inclusive uma pseudocabeçada de 96 bits que se prefixa à cabeçada TCP durante o cálculo. A pseudocabeçada contém o endereço de origem, endereço de destino, identificador de protocolo e comprimento de segmento. Estes são os parâmetros que se passam a IP quando uma instrução enviar se passa, e também aqueles leem por IP quando a entrega se tenta.
TCP tem muitas regras impostas a como se comunica. Estas regras e os processos que TCP segue para estabelecer uma conexão, dados de transferência, e terminar uma conexão apresentam-se normalmente em diagramas estatais. (Como TCP é um protocolo dirigido pelo estado, as suas ações dependem do estado de uma bandeira ou construto semelhante.) A evitação de diagramas estatais demais complexos é difícil, portanto os diagramas de fluxo podem usar-se como um método útil para entender TCP.
Uma conexão pode estabelecer-se entre duas máquinas só se uma conexão entre as duas tomadas não existir, ambas as máquinas combinam com a conexão, e ambas as máquinas têm recursos TCP adequados para reparar a conexão. Se alguma destas condições não se encontrar, a conexão não pode fazer-se. A aceitação de conexões pode provocar-se por uma aplicação ou uma rotina de administração de sistemas.
Quando uma conexão se estabelece, dá-se certas propriedades que são válidas até que a conexão se feche. Tipicamente, estes são um valor de precedência e um valor de segurança. Estas colocações combinam-se pelas duas aplicações quando a conexão está no processo de estabelecer-se.
Na maioria dos casos, uma conexão espera-se por duas aplicações, portanto emitem pedidos abertos ativos ou passivos. A figura 4.6 mostra um diagrama de fluxo de um TCP aberto. O processo começa com TCP de A de Machine a recepção de um pedido em uma conexão do seu ULP, ao qual envia um primitivo aberto ativo a Machine B. (Refira-se atrás à Tabela 4.2 dos primitivos TCP.) O segmento que se constrói mandou estabelecer a bandeira SYN em (jogo a 1) e manda destinar um número de sequência. O diagrama mostra isto com a notação "SYN SEQ 50", indicando que a bandeira SYN é ligada e o número de sequência (Inicial Enviam o número de Sequência ou ISS) é 50. (Qualquer número pode ter-se escolhido.)
A figura 4.6. Estabelecimento de uma conexão.
A aplicação em Machine B emitiu uma instrução aberta passiva ao seu TCP. Quando o segmento SYN SEQ 50 se recebe, TCP de B de Machine retorna um reconhecimento a Machine um com o número de sequência de 51. O Machine B também determina um número ISS do seu próprio. O diagrama mostra esta mensagem como "ACK 51; SYN 200", indicando que a mensagem é um reconhecimento com a sequência número 51, mandou estabelecer a bandeira SYN, e tem um ISS de 200.
Depois do recebimento, Machine A retorna a sua própria mensagem de reconhecimento com o jogo de número de sequência a 201. Isto é "ACK 201" no diagrama. Então, tendo-se aberto e reconhecido a conexão, Machine A e Machine B ambos envia a conexão mensagens abertas pelo ULP às aplicações de solicitação.
Não é necessário para a máquina remota ter uma instrução aberta passiva, como mencionado antes. Neste caso, a máquina de envio fornece tanto o envio como recepção de números de tomada, bem como precedência, segurança e valores de intervalo. É característico para duas aplicações solicitar um aberto ativo ao mesmo tempo. Isto resolve-se bastante facilmente, embora realmente implique um pouco mais tráfego de rede.
A transferência de informação é franca, como mostrado na Figura 4.7. Para cada bloco de dados recebidos por TCP de A de Máquina do ULP, TCP encapsula-o e envia-o à Máquina B com um número de sequência crescente. Depois da Máquina o B recebe a mensagem, reconhece-o com um reconhecimento de segmento que incrementa o seguinte número de sequência (e daqui indica que recebeu tudo até aquele número de sequência). A figura 4.7 mostra a transferência de dois segmentos da informação — um cada caminho.
A figura 4.7. Transferências de dados.
O serviço de transporte de dados TCP de fato personifica seis subserviços:
Para fechar uma conexão, um dos TCPs recebe um fim primitivo do ULP e emite uma mensagem com o jogo de bandeira FINANCEIRO em. Isto mostra-se na Figura 4.8. No número, TCP de A de Machine envia o pedido de fechar a conexão a Machine B com o seguinte número de sequência. O Machine B então retorna um reconhecimento do pedido e o seu seguinte número de sequência. Depois disto, Machine B envia a mensagem fechada pelo seu ULP à aplicação e espera pela aplicação para reconhecer o fechamento. Este passo não é estritamente necessário; TCP pode fechar a conexão sem a aprovação da aplicação, mas um sistema bem-comportado informaria a aplicação da modificação no estado.
A figura 4.8. Encerramento de uma conexão.
Depois de receber aprovação de fechar a conexão da aplicação (ou depois que o pedido acabou), TCP de B de Machine retorna um segmento a Machine um com o jogo de bandeira FINANCEIRO. Finalmente, Machine A reconhece o fechamento, e a conexão termina-se.
Uma terminação abrupta de uma conexão pode ocorrer quando um lado fecha a tomada. Isto pode fazer-se sem qualquer aviso a outra máquina e sem respeito a qualquer informação no trânsito entre os dois. Além de paralisações súbitas causadas por maus funcionamentos ou perdas por vazamento de poder, a terminação abrupta pode iniciar-se por um usuário, uma aplicação ou uma rotina de monitorização de sistema que julga a conexão digna da terminação. Outro fim da conexão não poderia realizar que uma terminação abrupta ocorreu até que tente enviar uma mensagem e o cronômetro vence.
Para guardar a pista de todas as conexões, TCP usa uma mesa de conexão. Cada conexão existente tem uma entrada na mesa que mostra a informação sobre a conexão de um extremo a outro. O leiaute da mesa de conexão TCP mostra-se na Figura 4.9.
A figura 4.9. A mesa de conexão TCP.
A significação de cada coluna é como se segue:
TCP é um protocolo baseado na conexão. Há tempos quando um protocolo connectionless se necessita, portanto UDP se usa. UDP usa-se tanto com Trivial File Transfer Protocol (TFTP) como com Remote Call Procedure (RCP). As comunicações de Connectionless não fornecem a confiança, significando que não há indicação ao dispositivo de envio que uma mensagem se recebeu corretamente. Os protocolos de Connectionless também não oferecem capacidades de recuperação incorreta — que deve ignorar-se ou fornecer-se nas camadas mais alto ou mais baixas. UDP é muito mais simples do que TCP. Inter-relaciona com IP (ou outros protocolos) sem a preocupação de controle de fluxo ou mecanismos de recuperação incorreta, atuando simplesmente como um remetente e o receptor de datagramas.
UDP é connectionless; TCP é baseado em conexões.
A cabeçada de mensagem UDP é muito mais simples do que o TCP'S. Mostra-se na Figura 4.10. O enchimento pode acrescentar-se ao datagrama para assegurar que a mensagem é um múltiplo de 16 bits.
A figura 4.10. A cabeçada UDP.
Os campos são como se segue:
O campo de soma de controle UDP é opcional, mas se não se usar, nenhuma soma de controle se aplica ao segmento de dados porque a soma de controle de IP só se aplica à cabeçada IP. Se a soma de controle não se usar, o campo deve estabelecer-se em 0.
Hoje, olhei para TCP no detalhe razoável. Combinado com a informação durante três dias anteriores, agora tem a teoria e contexto necessário para entender melhor a utilidade TCP/IP, como Telnet e FTP, bem como outros protocolos que usam ou estreitamente se parecem com TCP/IP, como SMTP e TFTP.
Os detalhes de TCP/IP revisitam-se depois neste livro, mas pode prosseguir agora a usar de fato TCP/IP e o seu toolset.
Defina a multiplexão e como se usaria para combinar três máquinas de fonte a uma máquina de destino. Relacione-se a números de porto.
A multiplexão explicou-se em algum detalhe do Dia 1. Refere-se à combinação de várias conexões em uma. Três máquinas podem estabelecer cada um portos de fonte a uma máquina usando só um porto de recepção. Os números de porto das máquinas de envio seriam todos diferentes, mas todos os três usariam o mesmo número de porto de destino. Isto mostrou-se na Figura 4.4.
O que uma palavra melhor descreve a diferença entre TCP e UDP?
Conexões. TCP é baseado na conexão, ao passo que UDP é connectionless.
O que são números de porto e tomadas?
Um número de porto usa-se para identificar o tipo do serviço fornecido. Uma tomada é o endereço do porto no qual uma conexão se estabelece. Não há relação física inerente entre os dois, embora muitas máquinas destinem certas tomadas de determinados serviços (números de porto).
Descreva os cronômetros usados com TCP.
O cronômetro de retransmissão usa-se para controlar o reenvio de um datagrama. O cronômetro tranquilo usa-se para atrasar a redesignação de um porto. O cronômetro de persistência usa-se para testar uma janela receber. Guarde - os cronômetros vivos enviam dados vazios para guardar uma conexão viva. O cronômetro ocioso é o período de tempo para esperar por uma desconexão a terminar-se depois que nenhum datagrama se recebe.
Quais são os seis subserviços de transporte de dados oferecidos por TCP?
Os subserviços são cheios dúplex, oportunidade, encomendada, fluxo etiquetado, controlado e correção de erros.
A Oficina fornece perguntas de concurso ajudá-lo a solidificar a sua compreensão do material coberto. Algumas seções de Oficina deste livro também contêm exercícios para provê-lo da experiência na utilização o que aprendeu. Tente entender o concurso e respostas de exercício antes de continuar ao seguinte capítulo. As respostas fornecem-se no Apêndice F, "As respostas a Questionam".