Questão Como as portas e os esquemas de URI são tratados por um servidor tcp / ip?


Eu estou trabalhando com a pilha lwip tcp / ip em um dispositivo embutido, e estou tentando entender como tudo funciona. Eu tenho procurado através da documentação e código, mas estou confuso com a forma como as portas e os esquemas de URI são manipulados pela pilha tcp / ip.

A primeira coisa confusa é que ambos parecem definir um protocolo. Isso é redundante?

Para o lwip, para configurar uma conexão tcp, cria-se um "bloco de controle de protocolo" (PCB). Isso é definido pelo endereço IP local e por uma porta. Isso parece fazer sentido - este PCB escuta na porta especificada. Como o esquema URI faz isso? Este PCB recebe algum esquema de uri? Eu também não vejo o esquema de URI sendo passado para a função de retorno de chamada para receber pacotes.

Como isso funciona se eu quiser mudar os protocolos - por exemplo, atualizar uma conexão HTTP em uma conexão Websocket? Se o handshake inicial for feito por HTTP: porta 80, como serão feitas outras comunicações sobre o WS: a porta X?

Por exemplo, aqui está a assinatura da função para ligar um PCB no lwip (no código C):

tcp_bind(struct tcp_pcb *pcb, struct ip_addr *ipaddr, u16_t port)

Isso liga o PCB a um endereço IP e um número de porta. No entanto, o esquema de URI não é especificado. Portanto, eu diria que o PCB é agnóstico ao esquema de URI. Se olharmos para o protótipo de retorno de chamada para receber pacotes:

err_t (* accept)(void *arg, struct tcp_pcb *newpcb, err_t err)

Novamente, o esquema de URI não aparece. Eu também tenho código fonte para uma implementação de um servidor HTTP usando lwip. Em nenhum lugar o esquema de URI aparece. Então, como os diferentes esquemas de URI são tratados pela pilha de IP? Eu não posso encontrar onde é passado como um argumento em retornos de chamada para lidar com o tráfego IP. Eu acho que deve estar faltando algo fundamental então.

Qualquer ajuda é apreciada!


1


origem




Respostas:


O TCP é um protocolo de fluxo genérico para entrega de dados confiável em ordem entre dois pontos de extremidade em uma rede IP como a Internet.

HTTP é um protocolo que é executado em cima do TCP. Outros protocolos que usam TCP são FTP, SSH, SSL etc.

As funções que você descreveu são para lidar com conexões TCP em geral.

Você deveria ler http://www.w3.org/Protocols/rfc2616/rfc2616.html para aprender o protocolo HTTP.

Uma breve visão geral de como uma solicitação HTTP é feita. Este exemplo é baseado no HTTP 1.0, já que é mais simples.

Quando você diz a um navegador para se conectar http://superuser.com, isso é o que acontece no fundo:

  1. O navegador faz uma pesquisa de DNS para superuser.com para descobrir o endereço IP do serviço.
  2. O navegador abre uma conexão TCP ao servidor para superuser.com
  3. Navegador envia GET / Solicitação HTTP para o servidor.
  4. O servidor envia de volta o arquivo correspondente ao / localização.

Portanto, o servidor não precisará saber nada sobre o esquema de URI aqui. O servidor precisa entender apenas as primitivas do protocolo HTTP (GET, POST, HEAD etc.) e retornar recursos correspondentes para o cliente através do soquete TCP.


0



Obrigado. Eu li através do protocolo http. Este também é um ótimo tutorial que é mais fácil de ler do que a especificação: jmarshall.com/easy/http - mhe
Como um esquema de URI diferente é tratado? Por exemplo, e se eu usar ws: ou ftp :? O esquema é inteiramente para o benefício do lado do cliente? O servidor não se importa? - mhe
O navegador usa o campo de protocolo na URL do recurso para selecionar o método apropriado para se conectar ao servidor. Por exemplo, com ftp: // URLs, o navegador se conecta à porta 21 do servidor remoto com o protocolo FTP. O servidor então executa o servidor FTP nessa porta específica para que a solicitação seja bem-sucedida. - Tero Kilkanen
Ok, então a parte do protocolo / esquema da URL é inteiramente do lado do cliente. O servidor nem precisa saber o que é. - mhe