• Telnet
• Conexões de Telnet
• Telnet ordena
• TN3270
• File Transfer Protocol (FTP)
• Ordens de FTP
• Conexões de FTP
• Transferências da terceira pessoa de FTP
• Acesso a FTP anônimo
• Servidores de FTP
• Trivial File Transfer Protocol (TFTP)
• TFTP ordena
• Pacotes de TFTP
• Simple Mail Transfer Protocol (SMTP)
• SMTP ordena
• A utilidade de Berkeley
• O hosts.equiv e Arquivos .rhosts
• rlogin
• rsh
• rcp
• rwho
• ruptime
• reis
• Sumário
• Perguntas e Respostas
• Concurso
• Oficina

— 6 —
Telnet e FTP

Durante cinco dias anteriores viu a arquitetura de TCP/IP, bem como tanto o Protocolo de Internet como o Protocolo de Controle de Transmissão no detalhe considerável. Basear-se nestes dois protocolos é uma camada de protocolos de camada de aplicação que se associam comumente com TCP/IP. Hoje olho para os protocolos de camada de aplicação mais comuns: Telnet, File Transfer Protocol (FTP), Trivial File Transfer Protocol (TFTP), e Simple Mail Transfer Protocol (SMTP), bem como uma suite de instrumentos chamaram a r-utilidade de Berkeley.

Cobrir os quatro protocolos no detalhe completo necessitaria várias centenas de páginas, portanto hoje examino os aspectos mais importantes dos protocolos, inclusive os seus objetivos, as suas relações a TCP e IP, os seus códigos de controle e comportamento e o seu uso típico. Cada um dos quatro protocolos de camada de aplicação tem vantagens que o fazem de maneira ideal ajustado com um determinado objetivo. Espero que até ao fim do dia entenda porque se usam e como se ajustam no mundo TCP/IP.

Telnet

A Telnet (rede de telecomunicações) programa destina-se para fornecer uma senha de entrada remota ou capacidade terminal virtual através de uma rede. Em outras palavras, um usuário na máquina A deve ser capaz de registrar em log na máquina B em qualquer lugar na rede, e pelo que o usuário se preocupe, parece que o usuário se senta em frente da máquina B. O serviço de Telnet fornece-se pelo porto de TCP número 23 (ver a Tabela 4.1 ou o Apêndice D, "Números de Porto Bem Conhecidos", para os números de porto TCP). O termo Telnet usa-se para referir-se tanto ao programa como ao protocolo que fornecem estes serviços.

Telnet desenvolveu-se porque um dia o único método de permitir a uma máquina acessar recursos de outra máquina (inclusive unidades de disco rígido e programas guardados lá) deveu estabelecer uma conexão usando dispositivos de comunicações como moduladores ou redes em portos seriais dedicados ou adaptadores de rede. Isto é um pouco mais complicado do que poderia aparecer à primeira vista por causa da larga diversidade de terminais e computadores, cada um com os seus próprios códigos de controle e características terminais. Quando diretamente unido a outra máquina, o CPU da máquina deve dirigir a tradução de códigos terminais entre os dois, que põe uma carga grande do CPU. Com várias senhas de entrada remotas ativas, o CPU de uma máquina pode passar um período de tempo irregular que dirige as traduções. Isto é especialmente um problema com servidores que podem tratar muitas conexões ao mesmo tempo: se cada um teve de tratar-se com a tradução terminal cheia, o CPU de servidor pode atolar-se somente executando esta função.

Telnet alivia este problema pela embutidura as sequências características terminais dentro do protocolo de Telnet. Quando duas máquinas comunicam a utilização Telnet, própria Telnet pode determinar e estabelecer as comunicações e parâmetros terminais da sessão durante a fase de conexão. O protocolo de Telnet inclui a capacidade de não apoiar um serviço que um fim da conexão não pode tratar. Quando uma conexão se estabeleceu por Telnet, ambos os fins combinaram um método das duas máquinas para trocar a informação, tomando a carga do CPU de servidor de um montante relativamente grande deste trabalho.

Normalmente, Telnet implica um processo no servidor que aceita pedidos de entrada em uma sessão de Telnet. Em sistemas UNIX, este processo chama-se telnetd. No Windows NT e outros sistemas operacionais baseados no PC, um programa Telnet Server implica-se normalmente. O cliente (o fim fazendo a chamada) dirige um programa, telnet normalmente chamado, que tenta a conexão ao servidor. Um parente do programa telnet é o programa rlogin, que é comum em máquinas UNIX e para o qual olho depois hoje; ver a seção intitulada "a Utilidade de Berkeley".

---

O programa rlogin fornece a funcionalidade quase idêntica a Telnet e acrescenta o suporte do ambiente UNIX. Muitas máquinas, especialmente estações de trabalho de UNIX, atuam tanto como cliente como como servidor simultaneamente, permitindo a um usuário registrar em log em outras máquinas na rede e outros usuários para registrar em log na máquina do usuário.

---

Conexões de Telnet

O protocolo de Telnet usa o conceito de uma rede terminal virtual ou NVT, para definir ambos os fins de uma conexão de Telnet. Cada fim da conexão (cada NVT) tem um teclado lógico e impressora. A impressora lógica pode expor carateres, e o teclado lógico pode gerar carateres. A impressora lógica é normalmente uma tela terminal, ao passo que o teclado lógico é normalmente o teclado do usuário, embora possa ser um arquivo ou outra corrente de entrada. Estes termos também se usam em File Transfer Protocol (FTP) e Simple Mail Transfer Protocol (SMTP). A figura 6.1 ilustra o NVT e teclado lógico e impressora.

A figura 6.1. Uma rede terminal virtual de Telnet.

O protocolo de Telnet trata os dois fins da conexão como NVTs. Os dois programas em qualquer fim (telnet e telnetd de um servidor UNIX) dirigem a tradução de terminais virtuais a dispositivos físicos reais. O conceito de terminais virtuais permite a Telnet interligar a qualquer tipo do dispositivo, enquanto um mapeamento está disponível dos códigos virtuais para o dispositivo físico. Uma vantagem desta aproximação consiste em que alguns dispositivos físicos não podem apoiar todas as operações, portanto o terminal virtual não tem aqueles códigos. Quando os dois fins estabelecem a conexão, a falta destes códigos observa-se, e as sequências que os usariam ignoram-se. Este processo é franco: um fim pergunta se a função se apoia, e outras respostas positivamente ou negativamente. Se se apoiar, os códigos necessários enviam-se. A lista de funções apoiadas é coberta rapidamente nesta maneira.

Quando uma conexão se estabelece por Telnet, telnetd (ou independentemente de que o programa atua como o servidor de Telnet) começa um processo no servidor para dirigir aplicações. Cada aperto da tecla em uma sessão de Telnet deve atravessar vários processos diferentes, como mostrado na Figura 6.2. Cada aperto da tecla atravessa telnet, telnetd, e as aplicações que se usam durante a sessão de Telnet. Algumas aplicações querem comunicar-se por um dispositivo terminal, portanto o sistema remoto dirige um motorista pseudo-TTY que atua como um terminal à aplicação. Se uma interface de windowed tal como X ou Motivo se usar no anfitrião e máquinas remotas, os sistemas devem instrui-los a permitir a informação windowing passar-se para a frente e para trás; de outra maneira, a máquina remota tenta abrir as janelas no servidor.

A figura 6.2. Uma conexão de Telnet.

Para começar Telnet, deve fornecer o nome ou o endereço IP da máquina a unir-se com. O nome pode usar-se só se o sistema tiver um meio de resolver o nome no seu endereço IP, tal como com o Sistema de Nome de domínio. Um nome de porto pode usar-se normalmente para unir-se a um serviço específico, mas isto se usa infrequentemente. Por exemplo, para unir-se a uma máquina com o endereço IP 205.150.89.1, entraria nesta ordem:

telnet 205.150.89.1

Se o sistema tinha o nome darkstar, que foi solúvel no seu endereço IP, pode emitir esta ordem:

telnet darkstar

Se nenhum nome, o endereço ou o porto se especificarem, Telnet entra no seu modo de ordem e espera por instruções específicas. Quando a conexão se estabelece, uma carteira de identidade de usuário e a senha solicitam-se. Pode logar com qualquer carteira de identidade de usuário que é válida no sistema remoto (não tem de ser a mesma carteira de identidade de usuário que tem no sistema local). Uma conexão típica a um servidor UNIX parece a isto:

telnet 205.150.89.1

Trying...

Connected to tpci

Escape character is '^]'.

HP-UX tpci A.09.01 A 9000/720 (ttys2)

login: tparker

password: xxxxxxxx

$

Como pode ver no código precedente, Telnet tentou unir-se ao sistema remoto, disse-lhe que se uniu, logo fundou os parâmetros de comunicações entre os dois sistemas. Quando isto se fez, a senha de entrada pronta expôs-se (como em qualquer terminal UNIX), seguiu-se de um pedido de senha. Se a senha de entrada e a senha se permitirem, mostra-se que a concha de UNIX pronta (um sinal de dólar) indica que a máquina remota é ativa agora.

Pode usar um nome de máquina como a parte da Telnet só ordena se o sistema tiver um meio de resolver o nome para o seu endereço IP. Se não, nenhuma conexão se estabelece, embora Telnet pudesse permanecer no modo de ordem. À saída, use Ctrl+D ou a sequência de intervalo exposta como parte da mensagem de lançamento.

Pode entrar no modo de ordem de Telnet em qualquer momento, normalmente usando Ctrl +] combinação-chave (segure Ctrl e aperte a chave de suporte de forma triangular direita). Se se unir atualmente a uma sessão ativa quando entra no modo de ordem, Telnet espera por você para emitir uma ordem, realizá-la, e logo voltar à sessão automaticamente. O modo de ordem deixa-o entrar em ordens quanto ao cliente (a máquina que está fisicamente em frente de) em vez do servidor. Precisaria de fazer isto para modificar diretórios ou dirigir uma aplicação local, por exemplo.

Uma vez que a conexão estabelece-se com sucesso, a sua sessão comporta-se como se estivesse na máquina remota, com todas as ordens válidas daquele sistema operacional. Todas as instruções são quanto ao servidor, portanto uma ordem diretiva mostra o diretório atual no servidor, não o cliente. Para ver o diretório do cliente, teria de entrar no modo de ordem. Uma sessão de logout e senha de entrada de Telnet de mostra, que chama de uma estação de trabalho UNIX (merlin) a um servidor (tpci_hpws4, um nome que pode resolver-se pelo servidor de nome) segue:

merlin> telnet tpci_hpws4

Trying...

Connected to tpci_hpws4.

Escape character is '^]'.

HP-UX tpci_hpws4 A.09.01 A 9000/720 (ttys2)

login: tparker

password: xxxxxxxx

tpci_hpws4-1> pwd

/u1/tparker

tpci_hpws4-2> cd docs

tpci_hpws4-3> pwd

/u1/tparker/docs

tpci_hpws4-2> <Ctrl+d>

Connection closed by foreign host.

merlin>

Uma vez que se une à máquina remota, a sessão comporta-se exatamente como se estivesse naquela máquina. Para registrar em log fora da sessão remota, simplesmente emita a ordem de logout (no exemplo prévio, o UNIX Ctrl+D combinação), e devolve-se à sua máquina local. O programa telnet é útil quando está em um abaixo de - máquina acionada ou terminal e quer usar capacidades de processamento de outra máquina, ou se outra máquina tiver um determinado instrumento que não quer carregar na sua máquina local.

A utilidade de Telnet está disponível para muitos sistemas operacionais diferentes. A figura 6.3 mostra um Windows de Grupos de trabalho aplicação de Telnet (parte de uma suite aplicada TCP/IP maior de NetManage chamado ChameleonNFS, para o qual olho em muito mais detalhe do Dia 10, "Fundando uma Rede de TCP/IP de Mostra: DOS e Clientes de Windows") registrando em log em um SCO UNIX servidor. Mesmo quando a máquina local tem uma interface gráfica como Windows, pode unir-se mais provavelmente a máquinas remotas usando uma interface baseada no caráter.

A figura 6.3. Usar Telnet de um Windows de máquina de Grupos de trabalho.

Se a chamada e a recepção de estações de trabalho usarem uma interface de usuário gráfico (GUI) como Motivo ou X, e quer usá-los em vez de uma interface baseada no caráter, deve instruir ambos os fins para usar o terminal local para windowing (porque não pode ver uma janela no terminal remoto). Localmente, um programa dirige-se que instrui o sistema operacional para permitir a outras máquinas expor diretamente para a tela, e o remoto deve ter uma instrução de redirecionar ordens de windowing à tela local. Muitos sistemas UNIX executam esta função como isto:

tpci_server-1> xhost +

tpci_server-2> telnet tpci_hpws4

Trying...

Connected to tpci_hpws4.

Escape character is '^]'.

HP-UX tpci_hpws4 A.09.01 A 9000/720 (ttys2)

login: tparker

password: xxxxxxxx

tpci_hpws4-1> setenv DISPLAY tpci_server:0.0

tpci_hpws4-2> <Ctrl+d>

Connection closed by foreign host.

tpci_server-3>

O UNIX xhost + a instrução diz à máquina local permitir ao sistema remoto controlar janelas na tela local (que normalmente não se permite fazer). A instrução setenv EXPÕE machine_name realizado nos jogos de máquina UNIX remotos a EXPOSIÇÃO de variável de ambiente de concha de UNIX à tela local. Sempre que uma janela deva abrir-se (como quando uma aplicação de Motivo se dirige), o windowing aparece na tela local, e o processamento conduz-se no remoto. Estes exemplos são para UNIX, mas uma sequência semelhante trabalha em outras máquinas e GUIs.

As aplicações completas que fornecem esta capacidade de correr local X e janelas Motif em um Windows, o Windows 95 ou máquina de Windows NT estão disponíveis de vários vendedores comerciais. Por exemplo, a Figura 6.4 mostra que uma aplicação que corre em um servidor remoto chamou mandel que atrai números de Mandelbrot. O servidor instruíram-no a expor a janela no Windows local da máquina de Grupos de trabalho usando um X pacote de cliente para máquinas de Windows. O servidor passa toda a informação sobre o tamanho, posição, e cores da janela, bem como instruções para desenhar os conteúdos ao habitante local X cliente. A janela aparece no Windows da máquina de Grupos de trabalho exatamente como ia no servidor UNIX.

A figura 6.4. Usar um X cliente para mostrar janelas UNIX X em um PC.

Telnet ordena

Várias opções de serviço estão disponíveis quando uma sessão de Telnet se estabelece. Os seus valores podem modificar-se durante o curso de uma sessão de Telnet se ambos os fins combinarem (um fim poderia impedir-se permitir ou inutilizar um serviço por causa de administrador ou colocações de recurso). Há quatro verbos usados pelo protocolo de Telnet à oferta, recusam, solicitam e previnem serviços: não vai, fazer e fazer não, respectivamente. Os verbos projetam-se para juntar-se (/e faça). Para ilustrar como estes se usam, considere a seguinte sessão de Telnet, que tem a exposição destes verbos acesos usando as opções de pino de madeira de ordem de telnet:

tpci_server-1> telnet

telnet> toggle options

Will show option processing.

telnet> open tpci_hpws4

Trying...

Connected to tpci_hpws4.

Escape character is '^]'.

SENT do SUPPRESS GO AHEAD

SENT will TERMINAL TYPE (don't reply)

SEND will NAWS (don't reply)

RCVD do 36 (reply)

sent won't 36 (don't reply)

RECD do TERMINAL TYPE (don't reply)

RCVD will SUPPRESS GO AHEAD (don't reply)

RCVD do NAWS (don't reply)

Sent suboption NAWS 0 80 (80) 0 37 (37)

Received suboption Terminal type - request to send.

RCVD will ECHO (reply)

SEND do ECHO (reply)

RCVD do ECHO (reply)

SENT won't ECHO (don't reply)

HP-UX tpci_hpws4 A.09.01 A 9000/720 (ttys2)

login:

---

As ordens de Telnet usam-se pelo protocolo, não por usuários (embora possa emiti-los durante uma sessão de Telnet, mas isto só usa-se normalmente com objetivos diagnósticos). Não há ordens de usuário de Telnet inerentes, outras do que o pino de madeira de modo de ordem, porque o papel de Telnet deve uni-lo a um sistema remoto e deixá-lo usá-lo diretamente.

---

Um jogo parcial de códigos de ordem de Telnet mostra-se na Tabela 6.1. Os códigos adicionais usam-se para representar funções de impressora como etiquetas horizontais e verticais e alimentos de forma, mas estes se deixaram da mesa da causa de brevidade. A parte do jogo de código de ordem de Telnet inclui seis funções terminais (IP, AO, AYT, a CE, EL e GA) que são comuns através da maior parte de definições terminais, portanto se definem formalmente no padrão de Telnet.

As ordens de Telnet enviam-se em um pacote formal chamado uma ordem, como mostrado na Figura 6.5. Tipicamente as ordens contêm dois ou três bytes: a instrução de Interpretar como ordem (IAC), o código de ordem que se envia e qualquer parâmetro opcional à ordem. As opções apoiadas por Telnet mostram-se na Tabela 6.2.

A figura 6.5. A estrutura de ordem de Telnet.

Se se referir ao código prévio que se inclina com as opções toggled em, algumas ordens podem entender-se mais claramente agora. Por exemplo, REPERCUTIRÁ (que se transmitiria como valores 255 251 1) instrui outro fim para começar a ecoar atrás carateres que recebe. A ordem não REPERCUTIRÁ (a ordem seria 255 252 1) indica que o remetente não ecoará atrás carateres ou quer deixar de repercutir.

---

O uso de carateres ASCII e as pequenas mesas de ordens e opções fazem relativamente fácil seguir comunicações de Telnet.

---

TN3270

Muitos computadores centrais usam EBCDIC, ao passo que a maior parte de mais pequenas máquinas confiam em ASCII. Isto pode causar um problema tentando a Telnet de máquinas baseadas em EBCDIC a máquinas baseadas em ASCII e vice-versa, porque os códigos que se transferem não são exatos. Para corrigir isto, uma aplicação de Telnet chamada TN3270 desenvolveu-se, que fornece a tradução entre os dois formatos.

Quando TN3270 se usa para unir-se entre duas máquinas, própria Telnet estabelece a conexão inicial, e logo um fim estabelece-se para a tradução. Se uma máquina ASCII estiver chamando uma máquina EBCDIC, a tradução entre os dois formatos conduz-se no EBCDIC (servidor) fim a menos que haja um portão entre eles, em que caso o portão pode executar a tradução.

Muitas suites aplicadas TCP/IP que incluem um programa Telnet também incluem um programa TN3270. Por exemplo, a Figura 6.6 mostra uma janela TN3270 da suite NetManage ChameleonNFS no processo da união a um computador central máquina baseada em EBCDIC. O endereço IP do computador central usa-se para iniciar a conexão.

A figura 6.6. TN3270 fornece a conversão entre ASCII e EBCDIC.

File Transfer Protocol (FTP)

O Protocolo de Transferência de arquivos, FTP normalmente chamado, é uma utilidade de arquivos gerentes através de máquinas sem ter necessidade de estabelecer uma sessão remota com Telnet. O FTP permite-lhe transferir arquivos para a frente e para trás, dirigir diretórios e correio eletrônico de acesso. O FTP não se projeta para permitir a acesso a outra máquina realizar programas, mas é a melhor utilidade de transferências de arquivos.

O FTP usa dois canais TCP. O porto de TCP 20 é o canal de dados, e o porto 21 é o canal de ordem. O FTP é diferente da maior parte de outros programas aplicados TCP/IP em que realmente usa dois canais, permitindo a transferência simultânea de ordens de FTP e dados. Também se diferencia em um outro aspecto importante: o FTP conduz todas as transferências de arquivos no primeiro plano, em vez do contexto. Em outras palavras, o FTP não usa spoolers ou filas, portanto olha o processo de transferência em tempo real. Usando TCP, o FTP elimina a necessidade de incomodar-se com confiança ou gestão de conexão, porque o FTP pode confiar em TCP para executar estas funções propriamente.

Na conversação de FTP, os dois canais que existem entre as duas máquinas chamam-se o intérprete de protocolo, ou PI, e o processo de transferência de dados ou DTP. A PI transfere instruções entre as duas implementações usando o canal de ordem de TCP 21, e o DTP transfere dados sobre o canal de dados TCP 20. Isto mostra-se na Figura 6.7.

A figura 6.7. Conexões de canal de FTP.

O FTP é semelhante a Telnet em que usa um programa de servidor que corre continuamente e um programa separado que se realiza no cliente. Em sistemas UNIX, estes programas denominam-se ftpd e ftp, respectivamente (semelhante a telnetd e telnet).

Ordens de FTP

Antes de olhar para como pode usar o FTP para transferir arquivos, deve olhar para as ordens atrás do próprio protocolo. Como com ordens de Telnet, estes são para o uso do protocolo só e não devem usar-se por um usuário (embora os administradores às vezes usem as ordens de FTP para depuração e objetivos diagnósticos).

As ordens de protocolo internas de FTP são sequências ASCII de quatro carateres terminadas por um caráter newline. Alguns códigos necessitam parâmetros depois deles. Uma vantagem primária de usar carateres ASCII para ordens consiste em que um usuário pode observar que a ordem flui e o entende facilmente. Isto ajuda consideravelmente no processo de depuração. Também, permite a um usuário informado comunicar-se diretamente com o componente de servidor de FTP (ftpd).

As ordens de FTP usadas pelo protocolo resumem-se na Tabela 6.3. Estas ordens provêem o processo de conexão, verificação de senha e as transferências de arquivos reais. Estes não devem confundir-se com as ordens disponíveis para um usuário.

O FTP também usa códigos de retorno simples para indicar condições de transferência. Cada código de retorno é um número de três dígitos, o primeiro dos quais significa uma execução bem sucedida (o primeiro dígito é 1, 2, ou 3) ou um fracasso (o primeiro dígito é 4 ou 5). Os segundos e terceiros dígitos especificam o código de retorno ou condição incorreta mais detalhadamente. Os códigos de retorno de FTP mostram-se na Tabela 6.4 e a Tabela 6.5. Os códigos do terceiro dígito não se incluem aqui porque há muitos deles e variam entre implementações.

O FTP permite transferências de arquivos em vários formatos, que são normalmente dependentes do sistema. A maioria de sistemas (inclusive sistemas UNIX) tem só dois modos: texto e binário. Algumas instalações de computador central acrescentam o suporte de EBCDIC, ao passo que muitos sítios mandam projetar um tipo local para transferências rápidas entre máquinas de rede locais (o tipo local poderia usar 32-ou palavras de 64 bits).

As transferências de texto usam carateres ASCII separados por retorno de carro e carateres newline, ao passo que o binário permite a transferência de carateres sem conversão ou formatação. O modo binário é mais rápido do que o texto e também permite para a transferência de todos os valores de ASCII (necessário para arquivos de não-texto). Na maior parte de sistemas, o FTP começa no modo de texto, embora muitos administradores de sistema agora estabeleçam o FTP no modo binário como um default da conveniência dos seus usuários. O FTP não pode transferir permissões de arquivo, porque estes não se especificam como parte do protocolo.

Antes de transferir arquivos com o FTP, assegure-se que usa o modo de transferência correto. Transferindo um arquivo binário como ASCII resulta no lixo! Confira com o seu administrador de sistema se for inseguro do modo ou olhar as mensagens regressos de FTP para ver o modo usado.

Conexões de FTP

O FTP começa-se normalmente com o nome ou o endereço da máquina de objetivo. Como com Telnet, o nome deve ser solúvel em um endereço IP da ordem de ter sucesso. A máquina de objetivo também pode especificar-se da linha de comando de FTP. Por exemplo, para unir-se ao endereço IP 205.150.89.5, emitiria esta ordem:

ftp 205.150.89.5

Quando o FTP se une ao destino, deve ser capaz de registrar em log no sistema como um usuário válido (como faz unindo-se por Telnet). Alguns sistemas permitem uma senha de entrada anônima ou senha de entrada de hóspede de transferências de arquivos de FTP (normalmente usando o seu nome do usuário como uma senha como um registro do seu acesso; ver a seção intitulada "Acesso a FTP Anônimo"), mas a maioria necessita que você tenha o acesso regular à máquina. O seguinte extrato mostra o processo de senha de entrada como um usuário fornece uma senha de entrada e senha da máquina remota:

ftp tpci_hpws4

Connected to tpci_hpws4.

220 tpci_hpws4 FTP server

Name (tpci_hpws4:tparker):

331 Password required for tparker.

Password:

230 User tparker logged in.

Remote system type is UNIX.

Using binary mode to transfer files.

Em grandes redes onde um sistema como Páginas amarelas (YP) ou Network Information Services (NIS) se usa, as senhas de entrada de FTP permitem-se normalmente na maior parte de máquinas. Se YP ou NIS não se empregarem, deve estar no arquivo de usuários válido para obter o acesso a FTP. Como com Telnet, pode registrar em log no remoto com uma carteira de identidade de usuário diferente da sua senha de entrada de máquina local. Para transferir arquivos, deve ter as permissões próprias no remoto, se as permissões de arquivo se proverem pelo sistema operacional.

Depois de registrar em log em outra máquina usando o FTP, não está de fato na máquina remota. Está ainda logicamente no cliente, portanto todas as instruções de transferências de arquivos e movimento diretivo devem ser com respeito à sua máquina local, não a remota. Observe que isto é o contrário de Telnet (uma distinção que causa a confusão considerável entre recém-chegados ao FTP e Telnet).

Lembre-se de que todas as referências para arquivos e diretórios são quanto à máquina que iniciou a sessão de FTP. Se não tiver cuidado, pode sobregravar acidentalmente de arquivos existentes.

O processo seguido do FTP quando uma conexão se estabelece é como se segue:

1. Senha de entrada: Verifica a carteira de identidade de usuário e senha.
   


2. Diretório Define: Identifica o diretório inicial.
   


3. Defina o modo de transferência de arquivos: Define o tipo da transferência.
   


4. Transferência de dados de partida: Permite ordens de usuário.
   


5. Transferência de dados de parada: Fecha a conexão.
   

Os passos executam-se na sequência para cada conexão. Um usuário tem várias ordens disponíveis para controlar o FTP; as ordens o mais frequentemente usadas resumem-se na Tabela 6.6.

A utilização de FTP é semelhante a Telnet, exceto que todos os movimentos de arquivos são quanto ao cliente. Por isso, a colocação de um arquivo move-o do cliente ao servidor, ao passo que a obtenção de um arquivo é o reverso. Uma sessão de FTP de mostra segue:

tpci_hpws1-1> ftp tpci_hpws4

Connected to tpci_hpws4.

220 tpci_hpws4 FTP server (Version 1.7.109.2 Tue Jul 28 23:32:34 GMT 1992) ready.

Name (tpci_hpws4:tparker):

331 Password required for tparker.

Password:

230 User tparker logged in.

Remote system type is UNIX.

Using binary mode to transfer files.

ftp> pwd

257 "/u1/tparker" is current directory.

ftp> get mandelfile1.gif

remote: mandelfile1.gif local: mandelfi.gif

200 PORT command successful

150 Opening BINARY mode data connection for mandelfile1.gif

226 File transfer complete

1192834 bytes sent in 0.89 seconds

ftp> <Ctrl+d>

tpci_hpws1-2>

Nesta amostra curta, transferi mandelfile1.gif chamado de um arquivo de uma máquina UNIX (o servidor) à máquina local (o cliente). Poderia ter notado que o nome de arquivo foi truncado automaticamente pelo servidor para ajustar as convenções de nomeação de sistema de arquivos de DOS. Também, observe que usei o modo binário (que foi o default de sistema). Se o default tivesse sido modo ASCII, somente teria transferido mais de um megabyte do lixo total que não pode usar-se para nada.

Uma opção de depuração está disponível da linha de comando acrescentando-d à ordem. Isto expõe as instruções de canal de ordem. As instruções do cliente mostram-se com uma flecha como o primeiro caráter, ao passo que as instruções do servidor têm três dígitos em frente deles. Um PORTO na linha de comando indica o endereço do canal de dados no qual o cliente espera pela resposta do servidor. Se nenhum PORTO se especificar, o canal 20 (o valor à revelia) usa-se. Infelizmente, o progresso de transferências de dados não pode seguir-se no modo de depuração. Uma sessão de mostra com a opção de ajuste permitida mostra-se aqui:

tpci_hpws1-1> ftp -d

ftp> open tpci_hpws4

Connected to tpci_hpws4.

220 tpci_hpws4 FTP server Name (tpci_hpws4:tparker):

---> USER tparker

331 Password required for tparker.

Password:

---> PASS qwerty5

230 User tparker logged in.

---> SYST

215 UNIX Type: L8

Remote system type is UNIX.

---> Type I

200 Type set to I.

Using binary mode to transfer files.

ftp> ls

---> PORT 47,80,10,28,4,175

200 PORT command successful.

---> TYPE A

200 Type set to A.

---> LIST

150 Opening ASCII mode data connection for /bin/ls.

total 4

-rw-r-----  1 tparker  tpci    2803  Apr 29 10:46 file1

-rw-rw-r--  1 tparker  tpci    1286  Apr 14 10:46 file5_draft

-rwxr-----  2 tparker  tpci   15635  Mar 14 23:23 test_comp_1

-rw-r-----  1 tparker  tpci      52  Apr 22 12:19 xyzzy

Transfer complete.

---> TYPE I

200 Type set to I.

ftp> <Ctrl+d>

tpci_hpws1-2>

Poderia notar no código prévio como o modo se modifica do binário para ASCII para enviar a listagem diretiva, e logo atrás ao binário (o valor à revelia de sistema). Pode ver como os dois sistemas se comunicam para expor as mensagens de posição que aparecem sem a opção de depuração ativa.

Quando o FTP se usa em um ambiente de usuário gráfico, poderia ser capaz de usar um instrumento baseado em GUI. Por exemplo, ChameleonNFS de NetManage fornece a utilidade de FTP mostrada na Figura 6.8. Neste caso, o cliente de NFS no Windows da máquina de Grupos de trabalho uniu-se a um servidor UNIX. O lado Local da janela mostra a máquina de Windows, e o lado Remoto da janela mostra os conteúdos de sistema de arquivos atuais da caixa UNIX. Usando uma utilidade baseada em GUI como este, pode usar o rato e vários botões para transferir arquivos para a frente e para trás entre máquinas.

A figura 6.8. Muitos sistemas operacionais têm um cliente de FTP baseado em GUI.

Transferências da terceira pessoa de FTP

O FTP permite a uma transferência ocorrer por uma terceira máquina posicionada entre o cliente e o servidor. Este procedimento conhece-se como uma transferência de à terceira pessoa e é às vezes necessário para obter permissões próprias de acessar a máquina remota. A figura 6.9 mostra a esquemática de uma transferência da terceira pessoa, com a conexão de controle feita por uma terceira máquina.

A figura 6.9. Uma transferência de FTP da terceira pessoa.

Fundando uma conexão da terceira pessoa, o cliente abre as conexões de controle entre a máquina remota e o segundo cliente que trata o canal de controle. Só o canal de controle atravessa o segundo cliente, ao passo que o canal de dados vai diretamente entre os dois fins.

Quando um pedido de transferência se submete, transfere-se pelo segundo cliente, que verifica permissões e logo adiante o pedido ao servidor. A transferência de dados pode realizar-se diretamente, porque as permissões se verificaram no canal de controle.

Acesso a FTP anônimo

O FTP necessita que uma carteira de identidade de usuário e senha permitam capacidades de transferência de arquivos, mas há um método mais liberal de permitir o acesso geral a um arquivo ou diretório, chamado FTP anônimo. O FTP anônimo retira a exigência para uma conta de senha de entrada na máquina remota, normalmente permitindo a senha de entrada anônima com uma senha do hóspede ou do nome do usuário real do usuário. A seguinte sessão mostra o uso de um sistema de FTP anônimo:

tpci_hpws4-1> ftp uofo.edu

Connected to uofo.edu.

220 uofo.edu FTP server (Version 1.7.109.2 Tue Jul 28 23:32:34 GMT 1992) ready.

Name (uofo:username): anonymous

331 Guest login ok, send userID as password.

Password: tparker

230 Guest login ok, access restrictions apply.

ftp> <Ctrl+d>

tpci_hpws4-2>

Se o sistema remoto se fizer para permitir senhas de entrada anônimas, incita-se a uma senha e logo dá-se um aviso sobre limitações de acesso. Se houver um arquivo no sistema remoto necessita, uma ordem adquirir transfere-o. Os sítios de FTP anônimos ficam comuns, especialmente com a popularidade da Internet.

Servidores de FTP

A maior parte de máquinas UNIX atuam como servidores de FTP à revelia. Para fornecer facilidades de servidor de FTP, dirigem o demônio ftpd quando o sistema operacional se inicializa. O demônio trata-se normalmente pelo UNIX inetd processo. Quando começa a usar inetd, o demônio inetd olha o porto de ordem de TCP (canal 21) para um pedido que chega em uma conexão, logo começa ftpd para reparar aquele pedido. Se quiser assegurar que o seu sistema de Linux ou UNIX pode tratar pedidos de FTP, assegure-se que o demônio ftpd pode começar-se quando necessário por inetd verificando o arquivo de configuração inetd (normalmente/etc/inetd.config ou/etc/inetd.conf) para uma linha que parece a isto:

ftp stream  tcp  nowait  root  /usr/etc/ftpd   ftpd -l

Se esta linha não existir, deve acrescentá-lo. Com a maior parte de sistemas UNIX esta linha já está no arquivo de configuração inetd, embora pudesse comentar-se fora, em que caso deve retirar o símbolo de comentário.

O Windows, o Windows de Grupos de trabalho e o Windows 95 toda a falta um programa de servidor de FTP como parte do seu software de distribuição (embora o Windows 95 realmente tenha um cliente de FTP), portanto tem de acrescentar um pacote comercial. Muitas suites TCP/IP comerciais incluem um processo de servidor de FTP. A figura 6.10 mostra o grupo de programa NetManage ChameleonNFS, que inclui um programa de servidor de FTP que pode usar como um exemplo para o Windows de máquinas do Windows 3.x e Grupos de trabalho.

A figura 6.10. O diálogo de Servidor de FTP de NetManage trata o processo de servidor de FTP.

Para começar o software NetManage FTP Server, clique duas vezes no ícone de servidor de FTP no grupo de programa NetManage. Aparece um diálogo, mostrado na Figura 6.10. O processo de servidor de FTP é ativo agora, e cada um em outra máquina na sua rede local pode unir-se agora à sua máquina, supondo que tenham o acesso.

O acesso ao seu serviço de FTP controla-se pelas listas de usuário mantidas pelo pacote de Servidor de FTP. Selecionar a opção de menu Users do diálogo de Servidor de FTP de NetManage abre o diálogo de Usuários, mostrado na Figura 6.11. Isto deixa-o acrescentar nomes do usuário ao seu sistema. Se outro usuário em uma máquina diferente tentar unir-se ao seu software de servidor de FTP, o servidor verifica que o seu nome do usuário e a senha combinam com o nome e senha na qual entra neste diálogo. Isto deixa-o fundar uma lista de usuários que podem transferir arquivos para e do seu sistema, enquanto o servidor de FTP corre.

A figura 6.11. O acesso à sua máquina controla-se por meio do diálogo de Usuários de Servidor de FTP.

Se estiver dirigindo um processo de servidor de FTP, muitas vezes é uma boa ideia de criar um diretório somente do FTP. Muitos usuários preferem criar um diretório chamado público, que é onde todos os arquivos a transferir-se em e fora do sistema local se colocam. Isto deixa-o prevenir a eliminação acidental ou a transferência de arquivos em outros diretórios no seu sistema, bem como provê-lo com a oportunidade de filtrar o material de entrada de conveniência, vírus, e assim por diante. Se usar um diretório de transferência, verifique-o regularmente e assegure-se todos os usuários que têm o acesso ao seu sistema pode trabalhar só naquele diretório.

Se quiser fornecer um anônimo ou conta de hóspede de usuários na sua LAN ou alguma outra rede que pode unir-se à sua máquina, deve fundar uma conta com nenhuma senha ou com uma senha simples como hóspede. É muito importante restringir as áreas que um hóspede ou a senha de entrada anônima podem usar.

Como mencionado antes, o Windows 95 fornece-se com o software de FTP de cliente mas não um servidor de FTP. Pode usar outros aspectos do Windows 95 como um sistema de transferência de arquivos, como arquivo e impressão que compartilha sobre qualquer rede existente, mas estes não usam o FTP. Se quiser fundar um servidor de FTP na sua máquina do Windows 95, tem de instalar a terceira pessoa software comercial com esta finalidade.

Um pacote de servidor de FTP do Windows 95 popular chamou o FTP que Serv-U se escreveu por Rob Beckers e se fornece como shareware. Um arquivo executável chamado Serv-U começa o servidor. Para controlar o acesso ao seu sistema do Windows 95, pode fundar senhas de entrada usando a opção de menu Serv-U Users. Isto expõe uma tela que o deixa acrescentar senhas de entrada e senhas, bem como os diretórios e dirige o usuário tem o acesso a. A figura 6.12 mostra o diálogo de Usuário/Grupo Editar com um usuário que se acrescenta. Quando um usuário de outro sistema registra em log na sua máquina do Windows 95, pedem-se a uma senha de entrada e senha.

A figura 6.12. Funde todos os usuários do seu servidor de FTP com o diálogo de Usuário/Grupo Editar.

Trivial File Transfer Protocol (TFTP)

Trivial File Transfer Protocol (TFTP) é um dos protocolos de transferência de arquivos mais simples no uso. Diferencia-se do FTP de dois modos primários: não registra em log para a máquina remota, e usa User Datagram Protocol (UDP) connectionless protocolo de transporte em vez de TCP. Usando UDP, TFTP não controla o progresso da transferência de arquivos, embora realmente tenha de empregar algoritmos mais complexos para assegurar a integridade de dados própria. Evitando registrando em log para o, acesso de usuário remoto e problemas de permissão de arquivo evitam-se. TFTP usa o identificador de porto TCP número 69, embora TCP não se implique no protocolo.

TFTP tem poucas vantagens quanto ao FTP. Não se usa normalmente para transferências de arquivos entre máquinas onde o FTP pode usar-se em vez disso, embora TFTP seja útil quando um terminal diskless ou a estação de trabalho se implicam. Tipicamente, TFTP usa-se para carregar aplicações e fontes nestas máquinas, bem como para aperfeiçoar. TFTP é necessário nestes casos porque as máquinas diskless não podem realizar o FTP até que se carreguem totalmente com um sistema operacional. O pequeno tamanho executável de TFTP e as exigências de memória fazem-no ideal para a inclusão em uma alça, onde o sistema só necessita TFTP, UDP e um motorista de rede, todos dos quais podem fornecer-se em um pequeno EPROM.

TFTP trata acesso e permissões de arquivo por restrições imponentes do seu próprio. Na maior parte de sistemas UNIX, por exemplo, um arquivo pode transferir-se só se for acessível a todos os usuários no remoto (tanto lido como escreva que as permissões se estabelecem). Por causa das regulações de acesso lassas, a maior parte de administradores de sistema impõem mais controle sob TFTP (ou interdiga o seu uso completamente); de outra maneira, é bastante fácil para um usuário informado acessar ou transferir arquivos que podem constituir uma violação de segurança.

As transferências de TFTP podem falhar por muitas razões, porque praticamente qualquer espécie do erro encontrado durante uma operação de transferência causa um fracasso completo. TFTP realmente apoia algumas mensagens de erro básicas, mas não pode tratar erros simples como recursos insuficientes de uma transferência de arquivos ou até um fracasso de localizar um arquivo solicitado.

TFTP ordena

As instruções importantes no conjunto de comandos de TFTP mostram-se na Tabela 6.7. O conjunto de comandos TFTP é semelhante ao FTP, mas se diferencia em vários aspectos importantes por causa do aspecto connectionless do protocolo. O mais evidente é a ordem unir, que simplesmente determina o endereço da repartícula de pó em vez de iniciar uma conexão.

TFTP permite tanto texto como transferências binárias, como faz o FTP. Como tanto com Telnet como com FTP, TFTP usa um processo de servidor (tftpd em um sistema UNIX) e um executável, tftp normalmente chamado. Uma sessão de TFTP de mostra em um anfitrião de UNIX mostra-se aqui, com opções de traço cheias e transferências binárias acesas:

tpci_hpws1-1> tftp

tftp> connect tpci_hpws4

tftp> trace

Packet tracing on.

tftp> binary

Binary mode on.

tftp> verbose

Verbose mode on.

tftp> status

Connected to tpci_hpws4.

Mode: octet Verbose: on Tracing: on

Rexmt-interval: 5 seconds, Max-timeout: 25 seconds

tftp> get /usr/rmaclean/docs/draft1

getting from tpci_hpws4:/usr/rmaclean/docs/draft1 to /tmp/draft1 [octet]

sent RRQ <file=/usr/rmaclean/docs/draft1, mode=octet>

received DATA <block1, 512 bytes>

send ACK <block=1>

received DATA <block2, 512 bytes>

send ACK <block=3>

received DATA <block4, 128 bytes>

send ACK <block=3>

Received 1152 bytes in 0.2 second 46080 bits/s]

tftp> quit

tpci_hpws1-2>

Na sessão em cima, pode ver que o traço e as ordens verbosas acendem a repetição das instruções que fluem entre as duas máquinas durante uma transferência de arquivos. Cada vez um bloco de dados envia-se depois que a ordem adquirir emite-se (enviar instrução de ACK mostrada na sessão em cima), uma instrução recebida devolve-se para reconhecer o ACK.

TFTP está disponível em todos os sistemas UNIX bem como em suites TCP/IP de outros sistemas operacionais. A figura 6.13 mostra a utilidade TFTP de ChameleonNFS, que o deixa entrar no nome do host remoto, os nomes de arquivo remotos e locais e o tipo da transferência que quer. A transferência de arquivos então executa-se em background usando UDP.

A figura 6.13. Usar TFTP para transferir um arquivo.

Pacotes de TFTP

TFTP usa UDP como um protocolo de transporte, portanto TFTP pode usar a cabeçada UDP para encapsular a informação sobre protocolo TFTP. TFTP usa a fonte UDP e campos de porto de destino para estabelecer os dois fins da conexão. Realiza isto pelo uso de Identificadores de Transferência de TFTP ou TIDs, que se criam por TFTP e se passam a UDP, que então os coloca nas cabeçadas.

Como com Telnet e FTP, TFTP usa a atadura de porto, onde a máquina de envio seleciona um TID, e o remoto estabelece-se no porto número 69 (o número de porto de TFTP). A máquina remota responde com um reconhecimento de um pedido de conexão, um porto de fonte de 69, e o destino TID entregou o pedido.

TFTP usa cinco tipos de Unidades de Dados de Protocolo, que se mencionam como pacotes no léxico TFTP. Estes pacotes enumeram-se na Tabela 6.8. O seu leiaute mostra-se na Figura 6.14. As mensagens de erro apoiadas por TFTP mostram-se na Tabela 6.9.

A figura 6.14. Leiaute de pacote de TFTP.

O leiaute tanto de RRQ como de pacotes WRQ tem um campo de Modo, que indica o tipo da transferência. Há três modos atualmente disponíveis para TFTP:

• NetASCII: códigos de ASCII padrão.
  


• Byte: bytes de 8 bits e informação binária.
  


• Correio: Indica que o destino é usuário, não um arquivo (a informação transfere-se como NetASCII).
  

O bloco último em todos os pacotes contém entre 0 e 511 bytes de dados, etiquetados 0 na Figura 6.14. Isto forra fora o bloco de dados a 512 bytes.

O processo de comunicações usado por TFTP começa com o cliente que envia um RRQ ou WRQ solicitam ao servidor por UDP. Como parte do pedido, um número transacional, o nome de arquivo e um código para identificar o modo de transmissão a usar-se especificam-se. O número transacional usa-se para identificar futuras transações na sequência.

Como não há conexão entre os dois, o cliente estabelece um cronômetro e espera por uma resposta do servidor. Se um não chegar antes que o cronômetro vença, outro pedido envia-se. Depois que um ACK recebe-se, um pacote de DADOS transmite-se, para o qual outro ACK ou um ERRO se recebem. Se houver vários pacotes a transferir-se, constroem-se assim têm um comprimento de 512 bytes e um número de sequência que incrementa. O processo termina quando um pacote de DADOS com um comprimento de menos de 512 bytes se recebe pelo servidor. Para cada pacote enviado, TFTP espera por um reconhecimento antes de enviar o seguinte, um sistema conhecido como um protocolo de retorno.

Simple Mail Transfer Protocol (SMTP)

Simple Mail Transfer Protocol (SMTP) é o método de Internet definido para transferir o correio eletrônico. SMTP é semelhante ao FTP de muitos modos, inclusive a mesma simplicidade da operação. SMTP usa o porto TCP número 25.

A maior parte de sistemas UNIX usam sendmail chamado de programas ou mmdf para implementar SMTP (bem como vários outros protocolos de correio). O programa sendmail, por exemplo, atua como tanto um cliente como um servidor, normalmente correndo em background como um demônio. Os usuários não interagem com sendmail diretamente mas usam um programa de correio de parte dianteira como correio, mailx, ou Correio. Estas interfaces de sistema de correio passam a mensagem a sendmail da expedição.

SMTP usa carretéis ou filas. Quando uma mensagem se envia a SMTP, coloca-o em uma fila. SMTP tenta expedir a mensagem da fila sempre que se una a máquinas remotas. Se não puder expedir a mensagem dentro de um limite de tempo determinado, a mensagem devolve-se ao remetente ou retira-se.

SMTP ordena

As transmissões de dados de SMTP usam um formato simples. Todo o texto de mensagem transfere-se como carateres ASCII de 7 bits. O fim da mensagem indica-se por um período único em uma linha por si mesmo. Se por alguma razão uma linha na mensagem começar com um período, um segundo acrescenta-se pelo protocolo para evitar a confusão com o indicador de fim da mensagem.

SMTP tem um conjunto de comandos de protocolo simples, enumerado na Tabela 6.10. Usando estes elementos de protocolo, o correio transfere-se com um mínimo do esforço.

Quando uma conexão se estabelece, dois sistemas SMTP trocam códigos de autenticação. Depois disto, um sistema envia uma ordem de CORREIO ao outro para identificar o remetente e fornecer a informação sobre a mensagem. O SMTP de recepção devolve um reconhecimento, depois do qual um RECIBO se envia para identificar o recipiente. Se mais de um recipiente na posição de receptor se identificar, várias mensagens de RECIBO enviam-se, mas a própria mensagem só se transmite uma vez. Depois que cada RECIBO lá é uma confirmação da ordem. Uma ordem de DADOS segue-se das linhas de mensagem, até que um período único em uma linha por si mesmo indique o fim da mensagem. A conexão fecha-se com uma ordem ABANDONADA.

Os campos de endereço de recipiente e remetente usam formatos de Internet padrão, implicando o nome do usuário e nome de domínio (como tparker@tpci.com). O domínio pode substituir-se por outra informação se uma conexão direta se estabelecer, ou se houver uma máquina de expedição no caminho. SMTP usa Domain Name System (DNS) para todos os endereços.

A utilidade de Berkeley

A universidade da Califórnia em Berkeley contribuiu para o desenvolvimento de TCP/IP e contribuiu muitos programas de serviço para o conjunto de ferramentas aplicado. Estes conhecem-se normalmente pelo termo r-utilidade de Berkeley. Chamam-nos r-utilidade porque todos eles começam com a carta r (para o remoto). A maioria da utilidade é UNIX-específica, embora se tenham desde então todos transportado em diagonal a outros sistemas operacionais.

O hosts.equiv e Arquivos .rhosts

Para permitir a máquinas comunicar-se corretamente sobre redes, os direitos de acesso de máquinas e usuários devem estabelecer-se. Normalmente, registrando em log em outra máquina, um usuário deve fornecer a uma carteira de identidade de usuário e uma senha. Quando registra em log em muitas máquinas, redatilografar esta informação pode ser tedioso e demorado. Também pode ser um problema de segurança, porque é fácil escrever um programa que controla conexões de rede desta informação. Um modo de permitir o acesso rápido sem logar de fato e prevenir a intercepção de senhas é claramente útil em alguns casos.

O administrador de sistema pode decidir que todos os nomes do usuário usaram em outras máquinas cujos nomes estão no arquivo hosts.equiv permitem-se pelo acesso na máquina local. Isto permite um protocolo que questiona uma máquina do acesso para verificar o arquivo hosts.equiv o nome de máquina de solicitação, e se se encontrar, para conceder o acesso ao usuário na máquina remota. O usuário tem os mesmos direitos de acesso que na sua máquina de casa.

Se o protocolo não encontrar uma entrada no arquivo hosts.equiv, pode verificar outro arquivo mantido no diretório padrão de um usuário, chamado .rhosts. Um usuário pode controlar quem tem o acesso ao seu nome do usuário com o arquivo .rhosts no seu diretório padrão, permitindo a outros usuários logar como se fossem aquele usuário. O arquivo .rhosts deve possuir-se pelo usuário (ou raiz) e não permitir escrevem o acesso a todos os usuários (em um sistema UNIX, outra permissão não pode ser escrevem). Um arquivo .rhosts compõe-se de uma linha de cada usuário para permitir-se no diretório padrão. A linha compõe-se de um nome de máquina e um nome do usuário. Uma amostra .rhosts arquivo mostra-se aqui:

tpci_hpws1 rmaclean

tpci_hpws1 bsmallwood

tpci_hpws3 ychow

tpci_hpws3 bsmallwood

tpci_hpws4 glessard

tpci_hpws4 bsmallwood

tpci_sunws1 chatton

merlin tparker

merlin ahoyt

merlin lrainsford

Este arquivo permite a usuário bsmallwood logar de três máquinas diferentes.

rlogin

A ordem de rlogin (para a senha de entrada remota) permite a um usuário registrar em log em outra máquina. É muito semelhante na funcionalidade a Telnet, embora o protocolo seja muito mais simples. Há um programa de fundo que corre em rlogind chamado do servidor, e o programa rlogin reside no cliente.

O protocolo rlogin começa uma sessão enviando três cadeias de caráter, separadas por 0s. A primeira cadeia é a carteira de identidade de senha de entrada do usuário (no cliente), a segunda cadeia é o nome do usuário do servidor (normalmente mas não sempre o mesmo como o nome do usuário no cliente), e a terceira cadeia é o nome do usuário e a tarifa de transmissão do terminal do usuário (como wyse60/19200). Quando recebido no servidor, as cadeias podem converter-se em variáveis de ambiente (como a variável de terminal de TERMO DE UNIX). Não pode registrar em log na máquina remota com uma carteira de identidade de usuário diferente, porque o sistema não incita para o nome do usuário. Realmente incita para uma senha, de qualquer modo.

Depois que o processo de senha de entrada conclui-se, o rlogin não usa nenhum protocolo. Cada caráter que datilografa na máquina de cliente envia-se ao servidor, ao passo que cada caráter gerado pelo servidor se expõe no seu consolo. A única saída à sua máquina local é fechando a conexão usando Ctrl+D ou entrando no caráter de fuga em uma linha por si mesmo. À revelia, o caráter de fuga é um til (~).

Algumas versões de rlogin permitem uma fuga de concha, uma interrupção temporária da sessão rlogin e um regresso ao sistema operacional, usando ~!.

rsh

A utilidade rsh (concha remota) deixa-o realizar ordens em uma máquina remota. Como com a maior parte de utilidade de Berkeley, um processo de fundo chamou rshd implica-se. Realizar uma ordem em uma máquina remota é uma matéria de acrescentar rsh e o nome de máquina para a frente da linha de comando, como rsh tpci_hpws3 quem ou alcatrão rsh tpci_sunws1 xvf/dev/rct0 (usando exemplos de UNIX). A utilidade rsh depende da presença de hosts.equiv ou de .rhosts para permitir a senha de entrada; de outra maneira, o acesso não se concede.

A utilidade rsh não é uma concha no sentido que não interpreta ordens como o UNIX C concha de Bourne ou concha. Em vez disso, uma ordem introduzida envia-se à entrada e saída padrão do servidor, realizando a ordem como um processo local por meio da conexão TCP. A vantagem primária disto consiste em que um o shell script que realiza na sua máquina local pode submeter-se à máquina remota sem modificação, onde corre exatamente como se foi local (exceto a utilização do sistema de arquivos da repartícula de pó). Infelizmente, qualquer código de retorno gerado pelo sistema remoto não se retorna à sua máquina local. Também, as aplicações mais orientadas à tela não funcionam propriamente, porque não têm produção terminal para escrever a.

rcp

Berkeley rcp (cópia remota) a ordem é semelhante ao UNIX cp a ordem, exceto que trabalha através da rede. A sintaxe de ordem e as listas de opção de rcp são o mesmo como cp, embora um nome de máquina se especifique normalmente como parte do nome de arquivo pela adição do nome de máquina seguido de uns dois pontos (ver os seguintes exemplos). Mesmo a cópia recursiva de diretórios apoia-se (uma característica útil e atraente de rcp que não está disponível abaixo do FTP ou TFTP). O programa rcp atua tanto como servidor como como cliente, iniciado quando um pedido chega.

rcp tpci_hpws4:/user/tparker/doc/draft1 .




rcp file2 merlin:/u1/bsmallwood/temp/file2




rcp -r merlin:/u2/tparker/tcp_book tpci_server/tcp_book




rcp merlin:/u1/ychow/iso9000_doc tpci_server:/u1/iso/doc1/iso_doc_from_ychow




rcp file4 tparker@tpci.com:new_info

Como os exemplos indicam, os nomes de arquivo tanto nas máquinas locais como em remotas especificam-se, com convenções de UNIX padrão apoiadas. O terceiro exemplo mostra um arquivo que se transfere de uma máquina para o outro, nenhum dos quais é a máquina da qual a ordem se inicia. O exemplo último mostra o uso de um nome de DNS-estilo cheio do endereço de destino.

A utilidade rcp é um método mais rápido de transferir arquivos do que o FTP, embora rcp necessite a permissão de acesso por um arquivo .rhosts (não hosts.equiv). Sem uma entrada neste arquivo, o acesso recusa-se e FTP ou TFTP deve usar-se.

rwho

O rwho (remoto quem) ordem usa o demônio rwhod para expor uma lista de usuários na rede. Mostra a todos os usuários de rede, compilados de um pacote regularmente enviado da informação de toda a gerência rwhod programas. A frequência desta transmissão de pacote é dependente do sistema mas está normalmente na ordem de todo o mundo a três minutos. Quando um programa rwhod recebe uma transmissão de outra máquina, coloca-o em um arquivo de sistema do futuro uso. (O arquivo em um sistema UNIX chama-se/usr/spool/rwho.)

Quando uma máquina não enviou uma mensagem de transmissão dentro de um prazo (normalmente onze minutos), supõe-se que a máquina desconectou da rede e todos os usuários enumerados como ativo naquela máquina no arquivo de sistema se ignoram. O programa rwhod deixa uma carteira de identidade de usuário da sua transmissão se nada se tenha introduzido no terminal do usuário na última hora.

A produção de um pedido de rwho mostra-se no seguinte exemplo. Para cada usuário, mostra o seu nome do usuário, a sua máquina e nome terminal, e o tempo e a data da sua senha de entrada.

bsmallwood merlin:tty2p      Feb 29 09:01

etreijs    tpci_hpws2:tty01  Feb 29 12:12

rmaclean   goofus:tty02      Feb 28 23:52

tparker    merlin:tty01      Feb 29 11:43

ychow      prudie:tty2a      Feb 28 11:37

O programa rcp tem um problema principal em grandes redes: o envio contínuo de pacotes de atualização por cada máquina cria um montante considerável do tráfego de rede. Por essa razão, algumas implementações diretamente solicitam os nomes do usuário só quando um pedido de rwho se recebe.

ruptime

A utilidade ruptime expõe uma lista de todas as máquinas na rede, a sua posição, o número de usuários ativos, carga atual e tempo decorrido desde que o sistema se inicializou. O programa usa a mesma informação que a ordem de rwho.

Uma produção de mostra de uma ordem de ruptime segue:

merlin     up    3:15,12 users, load 0.90, 0.50, 0.09

prudie     down  9:12

tpci_hpws1 up   11:05, 3 users, load 0.10, 0.10, 0.00

tpci_hpws2 up   23:59, 5 users, load 0.30, 0.25, 0.08

tpci_hpws3 down  6:45

tpci_hpws4 up    9:05, 1 user,  load 0.12, 0.05, 0.01

reis

Os reis (execução remota) programa são um remanescente de versões mais adiantadas do sistema operacional UNIX. Projetou-se para permitir a execução remota de uma ordem por rexecd chamado de um processo de servidor. A utilidade usa o porto TCP dedicado número 512.

O protocolo usado por reis é muito semelhante a rsh, exceto que uma senha criptografada se envia com o pedido e há um processo de senha de entrada cheio. A utilidade de reis usa-se raramente porque rsh é um método mais rápido e mais conveniente para realizar uma ordem remotamente.

Sumário

Hoje olhei para os protocolos aplicados primários que usam TCP/IP, bem como a utilidade de Berkeley. Agora que pode ver como trabalho de protocolos em cima do TCP e protocolos IP, a estrutura em camadas de TCP/IP fica mais pronunciada. Os textos de futuros dias baseiam-se nesta informação.

Perguntas e Respostas

Qual é o objetivo de Telnet e FTP?

Telnet fornece uma capacidade de senha de entrada remota, ao passo que o FTP lhe permite transferir arquivos através da rede.

Que canais (números de porto) se usam por Telnet, FTP e SMTP?

Telnet usa o porto número 23. O FTP usa o porto número 21 para a informação sobre controle e porto número 20 de dados. SMTP usa o porto número 25.

Quando você a questão a adquire a ordem no FTP, move um arquivo do habitante local ao remoto, ou vice-versa?

As ordens de FTP são quanto ao remoto, portanto uma ordem adquirir move um arquivo do habitante local ao remoto.

Como faz TFTP diferenciam-se de FTP?

TFTP não necessita logar. Envia um pedido sobre UDP. Com o FTP, deve registrar em log no destino diretamente ou por um dispositivo da terceira pessoa.

O rlogin diferencia-se de telnet?

O programa rlogin desenvolveu-se antes e para a maior parte de usuários não tem diferença. Há algumas dependências de versão com alguns lançamentos de rlogin, refletindo o seu antes (e menos apresentado de maneira cheia) origens.

Concurso

1. Explique qual uma rede o terminal virtual é.
   


2. Desenhe diagramas mostrando dois - e sessões de FTP de três partidos, indicando os números de porto usados por cada máquina.
   


3. Porque quereria permitir o acesso a FTP anônimo? Lá há alguma razão de desaprová-lo?
   


4. TFTP permite a arquivos transferir-se sem logar. Que problemas isto pode causar?
   


5. Qual é a Utilidade de Berkeley?
   

Oficina

Se tiver o acesso a uma Telnet ou sessão de FTP, tente registrar em log em uma máquina remota e transferir arquivos para a frente e para trás. Tente reconhecer que Telnet faz tudo quanto à máquina local, ao passo que o FTP é quanto ao remoto.