Introdução ao fluxo de chamadas socket em sistemas Unix/Linux

Ao programar com sockets TCP/IP, desenvolvedores frequentemente utilizam um conjunto padrão de funções como socket(), bind(), listen(), connect() e accept(). Embora o uso dessas interfaces pareça simples do ponto de vista da aplicação, compreender o que realmente ocorre sob o capô — especialmente nas transições entre modo usuário e modo kernel, e nas transformações das estruturas internas do sistema operacional — é essencial para dominar a programação de rede.

Este artigo descreve passo a passo como cada uma dessas chamadas afeta tanto o estado visível ao processo quanto as estruturas gerenciadas pelo kernel, focando especificamente no protocolo TCP sobre IPv4. A abordagem segue a jornada completa desde a criação do descritor até a aceitação de uma conexão estabelecida.

Visão geral: modo usuário vs. modo kernel

Aplicações rodando em espaço de usuário não têm permissão direta para manipular recursos de baixo nível como pilhas de protocolo ou tabelas de conexão. Para isso, dependem de chamadas de sistema (system calls), que provocam uma transição de contexto para o modo kernel, onde o sistema operacional executa as operações solicitadas com privilégios elevados.

• Modo usuário: ambiente restrito onde os processos rodam; acesso limitado ao hardware e às estruturas internas do kernel.
• Modo kernel: espaço privilegiado onde o SO controla diretamente dispositivos, memória e protocolos; todas as operações reais de rede acontecem aqui.

Cada chamada socket envolve:

1. O processo invocar a função (ex: connect(fd, ...)).
2. A CPU trocar para modo kernel via interrupção de software (ex: syscall).
3. O kernel localizar objetos internos associados ao fd.
4. Modificação ou criação de estruturas de controle.
5. Retorno ao modo usuário com resultado (sucesso/erro ou novo descritor).

Estrutura central no kernel: da fd até o controle TCP

Quando um programa obtém um inteiro sockfd, esse valor é apenas um identificador. Sua verdadeira utilidade vem da cadeia de objetos mantidos pelo kernel:

Processo (task_struct)
   └── Tabela de descritores (files_struct)
        └── fd = 3
             └── struct file
                  └── struct socket
                       └── struct sock (TCP control block)
                            ├── Endereço local (IP, porta)
                            ├── Endereço remoto
                            ├── Estado TCP (LISTEN, ESTABLISHED, etc.)
                            ├── Buffers de recepção/transmissão
                            └── Filas de conexão (semi-conectados, completos)

Essa hierarquia mostra que o fd é apenas a ponta do iceberg: ele serve como chave para acessar estruturas complexas dentro do kernel responsáveis pela comunicação real.

Etapa 1: socket() – Criação do ponto de comunicação

No código do usuário:

int sockfd = socket(AF_INET, SOCK_STREAM, 0);

O que parece ser apenas uma alocação retorna um inteiro (por exemplo, 3), mas internamente o kernel realiza várias ações:

• Aloca um novo descritor livre na tabela de arquivos do processo.
• Cria um objeto struct file representando o arquivo aberto genérico.
• Instancia um struct socket como abstração de soquete.
• Inicializa um struct sock específico para TCP com estado inicial CLOSED.

Neste estágio, ainda não há endereços atribuídos. O soquete é apenas um recipiente vazio, pronto para configuração.

Etapa 2: bind() – Definição da identidade local

Exemplo típico no servidor:

struct sockaddr_in addr;
addr.sin_family = AF_INET;
addr.sin_port = htons(8080);
addr.sin_addr.s_addr = INADDR_ANY;

bind(sockfd, (struct sockaddr*)&addr, sizeof(addr));

Dentro do kernel:

• O sistema verifica se a combinação IP:porta já está em uso.
• Se permitido, associa o endereço local fornecido ao struct sock ligado ao fd.
• Registra essa associação em uma tabela hash global para futuras consultas (como roteamento de pacotes entrantes).

Após o bind(), o soquete passa a ter uma "identidade":

Local: 0.0.0.0:8080 (aceita em qualquer interface)
Remoto: indefinido
Estado: CLOSED

Observação importante: clientes raraemnte chamam bind() explicitamente porque o kernel fará isso automaticamente durante connect(), escolhendo uma porta temporária (ephemeral port) e o IP de saída adequado.

Etapa 3: listen() – Transformação em ponto de escuta

No código:

listen(sockfd, 128);

Esta chamada não cria novos descritores nem estabelece conexões. Seu papel é estrutural e conceitual:

• Altera o estado interno do struct sock de CLOSED para LISTEN.
• Ativa ou inicializa duas filas lógicas:
  • Fila de semi-conexões (SYN queue): armazena pedidos após recebimento do SYN, antes da conclusão do handshake.
  • Fila de conexões completas (accept queue): contém conexões totalmente estabelecidas, esperando por accept().
• Define a capacidade máxima da fila com base no parâmetro backlog.

O soquete agora é um ponto de escuta passivo: ele não troca dados diretamente, apenas coordena a entrada de novas conexões.

Etapa 4: connect() – Iniciação ativa da conexão (cliente)

Do lado do cliente:

connect(sockfd, &servaddr, sizeof(servaddr));

O kernel realiza múltiplas etapas:

1. Verifica se o soquete já tem um endereço local vinculado; caso contrário, realiza bind implícito com uma porta efêmera (ex: 49152).
2. Armazena o endereço do servidor (ex: 192.168.1.10:8080) no bloco de controle TCP.
3. Muda o estado para SYN_SENT e envia o primeiro segmento SYN.
4. Espera pelos próximos dois segmentos (SYN-ACK + ACK) para concluir o handshake.
5. Após sucesso, o estado torna-se ESTABLISHED e a chamada retorna.

Após connect(), o mesmo fd passa a rperesentar uma conexão ativa com ambos os pares definidos:

Local: 192.168.1.20:49152
Remoto: 192.168.1.10:8080
Estado: ESTABLISHED

Etapa 5: Processamento do pedido no servidor (antes do accept)

Quando o pacote SYN chega ao servidor, o kernel age independentemente do processo de usuário:

1. Identifica o destino usando IP:porta (8080) e localiza o soquete escutando nesse端口.
2. Cria uma entrada temporária (request_sock) na fila de semi-conexões.
3. Responde com SYN+ACK.
4. Ao receber o último ACK, move essa entrada para a fila de conexões completas.

O soquete original (ligado ao listenfd) permanece inalterado em estado LISTEN, continuando apto a aceitar novos clientes.

Etapa 6: accept() – Extração da conexão estabelecida

Chamada típica:

int connfd = accept(listenfd, NULL, NULL);

Aqui reside um dos maiores equívocos: accept() não transforma o soquete escutador em uma conexão. Em vez disso:

1. O kernel localiza o soquete associado ao listenfd.
2. Verifica a fila de conexões completas.
3. Se vazia, o processo é bloqueado até que uma conexão chegue.
4. Se houver uma conexão pronta, o kernel retira o struct sock correspondente dessa fila.
5. Aloca um novo descritor (ex: fd=4).
6. Cria um novo struct file apontando para esse struct sock.
7. Devolve o novo fd ao usuário como connfd.

Resultado:

• listenfd (fd=3): continua em LISTEN, aguardando novos clientes.
• connfd (fd=4): representa a conexão específica com o cliente, agora pode usar read()/write().

Resumo das mudanças por função

Conclusão

As chamadas socket não são apenas uma sequência mecânica de funções. Elas refletem uma arquitetura bem definida entre usuário e kernel, onde:

• O descritor de arquivo é a interface entre os mundos.
• O kernel mantém toda a complexidade do estado de conexão.
• O soquete escutador nunca troca dados — ele apenas coordena novas conexões.
• O soquete conectado retornado por accept() é que lida com a troca de dados.

Compreender essa divisão permite entender melhor temas avançados como escalabilidade com epoll(), tratamento de sobrecarga de fila, reutilização de endereços (SO_REUSEADDR) e modelos de I/O assíncrono. Mais do que memorizar APIs, é fundamental enxergar a máquina por trás delas.