MAC0215 - Kurose & Ross, Capítulos 1 e 2

Capítulo 1: Computer Networks and the Internet

O capítulo nos apresenta o que é a Internet e como são organizadas redes de computadores. Independente de como se configura uma rede, é necessário que hajam dispositivos para se comunicarem, um meio compartilhado sobre o qual é feita a comunicação, e um protocolo em comum pelo qual os dispositivos vão se comunicar. Os autores elaboram também sobre a Internet como uma infraestrutura para a providência de serviços para aplicações, sejam elas jogos on-line, serviços de e-mail, compartilhamento de arquivos, comunicação de voz, enfim. As aplicações que se comunicam devem seguir os mesmos requisitos que aplicamos aos dispositivos, mas, neste caso, o "meio compartilhado" será providenciado pelas camadas inferiores da rede.
Falando em camadas, o livro chega na definição de camadas de rede segundo o modelo TCP/IP, sendo elas:

Camada física, que versa sobre a transmissão de ondas eletromagnéticas por meio de cabo, ar ou outro meio físico;
Camada de enlace, que trata da comunicação, verificação e eventual correção de erros nos bits transmitidos entre dois dispositivos adjacentes em um dado meio físico;
Camada de roteamento, que trata das rotas entre dois dispositivos, não necessariamente adjacentes, mas alcançáveis a partir dos enlaces;
Camada de transporte, que realiza a verificação de erros de pacotes vindos da camada de roteamento e tem a responsabilidade de levar o pacote em questão para a aplicação de destino; e
Camada de aplicação, que é responsável por produzir, mostrar e interpretar os dados de interesse. O e-mail, o jogo e o chat de voz ficam aqui.

Além disso, os autores diferenciam os dispositivos que estão na borda da rede, os dispositivos-fim das comunicações que usam as cinco camadas, e os dispositivos que estão no núcleo da rede. São tratadas diferentes tecnologias de meio físico e de enlace em ambos os casos: na borda da rede, trata-se de conexão via linha telefônica, cabo coaxial, a (à época) inovadora fibra residencial, cobre trançado, wi-fi e rádio; no núcleo da rede, falam sobre comutação de pacote e circuito, multiplexação, e nessa edição ainda não se fala de comutação de células.
Por fim, versam sobre as diferentes causas de atraso na rede, considerações sobre ataques em rede e um breve histórico do desenvolvimento dessa área de tecnologia.

Capítulo 2: Application Layer

Como visto no início do resumo sobre o capítulo 1, aplicações são o principal motivo pelo qual uma rede de computadores existe. Não faz sentido conectar dois computadores apenas para trocar endereços MAC ou criar um roteamento IP entre eles a não ser que algum dado de fato "útil" seja transmitido ente eles, sendo assim, uma aplicação é necessária. A primeira categorização que os autores fazem é no que diz respeito à arquitetura da aplicação, que pode ser cliente-servidor ou peer-to-peer.

Uma aplicação cliente servidor tem hosts com papéis bem-definidos: um deles é o servidor, que idealmente é uma máquina sempre ligada e conectada à rede, responsável por responder a requisições; e o cliente, que é quem faz essas requisições. Esse modelo de aplicação, usado em servidores web e serviços de email, permite que os dados fiquem centralizados e haja uma previsibilidade da disponibilidade do serviço, mas também costuma ter requisitos arquiteturais cada vez maiores conforme um determinado serviço se expande.

Uma aplicação peer-to-peer (P2P), por outro lado, não depende de um único servidor centralizado, e sim diversos hosts conectados intermitentemente na rede, sendo eles os próprios dispositivos dos usuários do serviço. Esse tipo de aplicação escala automaticamente conforme mais usuários usufruem de um serviço, já que eles próprios passam a compor a arquitetura. Entretanto, a maioria das redes voltadas ao usuário final são dimensionadas para pouco tráfego upstream e muito tráfego downstream, e esse tipo de aplicação depende muito da boa vontade dos usuários para manter o serviço seguro e funcionando.

A comunicação entre a aplicação em um host e a aplicação em outro host necessariamente passa pela comunicação entre todas as camadas da rede, sendo que a interface entre a camada de aplicação e a camada de transporte é chamada de socket.
A camada de transporte fornece algumas configurações para o desenvolvedor da aplicação (como escolha de protocolo e tamanho de buffer), enquanto o lado da aplicação é obviamente responsabilidade única do desenvolvedor.
Enviar dados através de um socket consiste em confiar que, depois de entregar a mensagem no socket, alguma infraestrutura vai levar aquela mensagem até o socket da aplicação do host alvo, endereçado por um par de endereço IP e número de porta (camada 3 e camada 4, respectivamente).

Os tipos de serviço oferecidos pela camada de transporte são:

Transferência confiável
Vazão
Atraso
Segurança

Os principais protocolos da camada de transporte são TCP (confiabilidade, segurança se usando SSL, a troco de ser mais complexo e orientado a conexão), e UDP, que permite que a aplicação despeje a maior quantidade de dados que ela conseguir mas é suscetível a perdas e pacotes desordenados.

Esse capítulo traz alguns exemplos de protocolos da camada de aplicação, começando pelo protocolo HTTP na seção 2.2. Ele é responsável pela transferência de páginas web como essa (também chamadas de documentos), e cada objeto (arquivo) referenciado nesse documento é endereçado por uma URL. O cliente típico de uma aplicação HTTP é um browser.

Uma importante distinção feita durante a explicação do funcionamento protocolo é a entre conexões persistentes e não-persistentes. No primeiro caso, todo par requisição-resposta é feito por uma mesma conexão TCP, enquanto no segundo, para cada requisição é necessário fazer o handshake novamente.
Conexões persistentes aceleram o tempo de resposta ao permitir que o browser faça as requisições em seguida sem que elas sofram o overhead de criar uma conexão nova, que é uma operação custosa. Não à toa esse é o modo padrão.
Conexões não-persistentes favorecem tempo de resposta menor de outra forma, já que abrir 10 conexões TCP para uma mesma página Web ao mesmo tempo nos aponta para soluções com paralelismo, mas colocam bastante peso no servidor já que um "usuário persistente" estaria valendo por 10 "não-persistentes", no sentido de criar conexões.

A seção então segue explicando a estrutura das mensagens HTTP: a mensagem é composta de uma linha identificadora, um cabeçalho e um corpo, sendo que a linha identificadora distingue entre requisição e resposta, o cabeçalho contém informações referentes àquela mensagem (por exemplo, qual o Host desejado, qual o tipo de dado retornado, etc), e o corpo contém os dados requisitados (se houve sucesso).
O servidor pode responder por si só todas as requisições ou ter um "proxy" que atua em seu nome respondendo as requisições de clientes fisicamente mais próximos. Isso ajuda a melhorar o tempo de resposta, já que esse proxy atua como um cache do servidor da mesma forma que um cache de memória num computador (cache miss e tudo).
A parte sobre HTTP também fala sobre cookies, que permitem ao servidor identificar um navegador para que um usuário não tenha que logar novamente, remarcar seus favoritos, e também serve pra bastante coisa problemática (como identificação e venda de dados para terceiros) que hoje em dia já virou pauta da LGPD europeia e banners irritantes em websites.

A seção 2.3 traz o FTP (transferência de arquivos) como exemplo de um protocolo simples assim como HTTP, mas necessariamente tendo que ter duas conexões paralelas: uma para transferência de dados e outra para manutenção de controle do estado do usuário.

A seção 2.4, por outro lado, traz o e-mail como essa aplicação que usa um conjunto de protocolos para realizar seu propósito (enviar correio eletrônico): SMTP para enviar um email de um cliente para o servidor de e-mail de outro, e POP3 ou IMAP para que um cliente acesse sua caixa de entrada. Também há uma seção sobre acesso de e-mail via browser, que vai usar o HTTP para usar uma página web como front-end dessa pilha de protocolos, e o e-mail é enviado diretamente do servidor de e-mail do usuário usando SMTP.

A aplicação DNS fornece um serviço de identificação e tradução de nomes mnemônicos (example.com) para endereços utilizáveis pela camada 3 (2001:db8::2:1) . É um serviço distribuído e baseado na propagação dos registros DNS de um determinado servidor DNS para outros servidores. Também serve para fornecer apelidos a nomes normais que ainda são muito complicados ou difíceis de lembrar (relay9.test.example.com) para nomes mais "digeríveis" (test.example.com), e para direcionar o tráfego para um determinado endereço mnemônico para um IP específico, seja para fins de balanceamento de carga, seja para fins nefários (DNS Poisoning).
Sendo a camada de tradução da internet para o usuário, servidores DNS são bem importantes, já que se um determinado local da internet não tem um registro DNS, dificilmente ele será acessível para usuários finais. Falhas em serviços de DNS podem causar incômodo para usuários, instabilidade de serviço ou até mesmo um apagão de rede.
Exemplos de problemas de DNS recentes são:

o apagão do Facebook em 2021 que deixou seus serviços fora do ar quase o dia todo, inclusive trancando funcionários para fora de seus escritórios; e
os registros dos sites bcc.ime.usp.br e bcc.ime.usp.br/ (repare na barra adicional!), que redirecionam para sites diferentes na data de escrita desse resumo. O pessoal do Apoio BCC está ciente do problema, mas não é prioridade agora (e sempre temos os links, no fim das contas).

Até agora tudo que a gente viu foram aplicações cliente-servidor, mas vimos que existem também aplicações peer-to-peer. A seção 2.6 expande sobre alguns exemplos de aplicações P2P, como transferência de arquivos grandes (famosos Torrents), Tabelas Hash Distribuídas, e telefonia via internet usando Skype de exemplo (que, aparentemente, era do eBay antes de virar da Microsoft?!).

Bastante coisa é tratada sobre como manter a coerência de informação já que os peers podem entrar e sair a qualquer momento, e evitar perda de seções críticas de um determinado dado (no caso do BitTorrent), além de, também, fazer uma análise comparativa do tempo de distribuição de um arquivo grande em arquitetura cliente-servidor e em arquitetura P2P.

O capítulo termina dando exemplos em Java de programas simples utilizando TCP e UDP. Aqui vou dar uma resumida no funcionamento do TCP na etapa de conexão, já que as seções agora andam passo a passo explicando os programas e o que cada coisa faz.

Pra uma aplicação se conectar a um servidor, esse servidor precisa estar alcançável pela aplicação, ou seja, ter um socket aberto para que a conexão se inicie. Esse socket é chamado de welcoming socket. A aplicação inicia a conexão TCP com o servidor por meio desse welcoming socket, e, ao final do handshaking, é criado um novo socket, nesse caso o connection socket, que é aquele que irá receber e enviar de fato os dados de e para o cliente.
O TCP irá garantir que os bytes enviados por um dos lados da conexão sejam os mesmos que chegam do outro lado, usando mecanismos como detecção de erro e reenvio de mensagens (go-back-N, ACK cumulativo, etc), sendo papel da aplicação verificar se esses bytes são importantes ou só lixo.

E isso termina meu resumo desses dois capítulos! Esse livro é bem cheio de coisa e bem denso, mas é fácil de seguir contanto que você tenha algumas noções do que os exemplos se tratam. Esse resumo até que foi fácil de fazer já que boa parte das coisas eu tinha visto e o restante foi pouca novidade.
Quanto ao resumo, acho que ficou até que bem extenso, mas suficientemente mais curto que as (cerca de) 150 páginas do livro. Próxima parada, UNIX Networking : The Socket Programming API Volume 1, um livro que consegue ser maior que o Kurose, mas, ainda bem, acessível pelo sistema da biblioteca do IME USP.