Percebi hoje que fundamentalmente não entendo como a comunicação por porta funciona.
Se eu acionar uma instância de um servidor da Web que esteja escutando na porta 80, ele poderá responder a muitas solicitações de diversas guias do navegador, todas se comunicando pela porta 80.
No entanto, não consigo iniciar duas instâncias do servidor, ambas escutando na porta 80, pois isso resulta em um conflito de porta.
Eu sempre tomei isso como um dado (apenas um processo pode ser vinculado a uma porta específica a qualquer momento) sem realmente pensar nisso - não há vários processos se comunicando na porta 80? (ou seja, cada uma das guias em execução no navegador?)
Basicamente, apenas um processo pode OUVIR em uma porta por vez (tecnicamente, um soquete é dedicado à escuta). Porém, uma porta pode lidar com muitos soquetes transferindo dados, um soquete é uma combinação de IP / porta local e endereço IP / porta remota. Dessa forma, uma vez que o servidor aceite a conexão recebida enquanto LISTENing, ele abre um novo soquete dedicado a essa conversa e entrega o processamento para outra coisa e depois volta para LISTENing.
Na verdade, você pode ter vários processos ouvindo na mesma porta. Se você fizer isso com vários leitores de udp, por exemplo, obterá um balanceamento de carga no nível do kernel. Primeiro abra o soquete para ouvir, depois bifurque e tente recv()em cada processo.
@viraptor: Verdade, mas como o UDP é sem conexão, não há realmente uma distinção entre "ouvir" e "receber".
— 11138 Adam Robinson #
A mesma idéia funciona com o TCP, processo de bifurcação com soquete de escuta e aceitação () em ambos.
Na verdade, um soquete é apenas um "ponto final" para comunicação. Eu acho que o que você quis dizer é que um soquete conectado é uma combinação de IP / porta local e IP / endereço / porta remota. A palavra de soquete é usado tantas vezes que era difícil para mim para descobrir o que ele está descrição real é
O navegador se conecta de uma porta alta aleatória (ou seja,> 1024) do seu computador à porta 80 de um servidor remoto. Portanto, não há conflito de portas na sua máquina.
Se você usar muitas guias para conectar-se ao mesmo servidor remoto (ou houver muitos usuários conectando-se ao servidor), todas elas vão para a mesma porta e serão atendidas pelo mesmo processo (ou seja, o servidor web do site).
Essa é a resposta correta. As conexões TCP têm um número de porta nas duas extremidades. Os dois computadores envolvidos podem distinguir entre o site de conexão: 80 <-> navegador: 12397 e o site de conexão diferente: 80 <-> navegador: 22958.
O servidor que está escutando na porta 80 não precisa lidar com vários processos. Os daemons TCP simples de anos anteriores só podiam lidar com uma conexão por vez. Você pode emular esse comportamento com um programa como netcatescutar em uma porta específica e tentar conectar duas máquinas a ela. Um entra, o outro ricocheteia sem uma conexão. Esses daemons são praticamente inúteis, para que você nunca mais os veja.
Para algo como um servidor web, ele está ouvindo diretamente na porta. É importante lembrar que ele está no topo da biblioteca de soquetes do sistema operacional. Quando uma nova conexão é estabelecida, a biblioteca de soquetes passa o novo soquete para o software do servidor da web. Nesse ponto, o software do servidor da web possui algumas opções.
Uma possibilidade é que ele passe o objeto socket para um novo thread no mesmo processo. Sempre que ocorrer uma comunicação nesse soquete, esse thread o manipulará. O processo pai medeia quais threads estão ativos a qualquer momento, o que pode ser muito.
Outra possibilidade é que ele gere um novo processo e passe o objeto de soquete para o processo. Pelo que entendi, agora o sistema de soquete do sistema operacional medeia a comunicação entre esses processos filhos e seus destinos. O processo pai ainda tem algum controle sobre os processos, como matar os pendurados e outras comunicações entre processos.
Qual dessas abordagens é mais eficiente depende do sistema operacional. IIRC, o Apache pode ser executado nos dois modos.
Em essência, a biblioteca de soquetes fornece um nível de processamento paralelo ao servidor da web. Ele pode lidar com várias conexões simultâneas, transferindo dados ativamente, enquanto aceita novas conexões.
Para um navegador que pode ativar várias tentativas de conexão com um servidor da Web, a fim de melhorar o tempo de carregamento, o paralelismo também se aplica à extremidade do navegador, isso é uma coisa boa e maravilhosa. O navegador mantém o controle do estado da página durante o carregamento, e as várias tentativas de conexão que ele gera fazem parte do processo.
+1 por estar certo de tantas maneiras :)
Existem, efetivamente, dois "tipos" de soquetes de fluxo. Um deles tem um curinga "outro extremo", um tem um host específico: porta para o outro extremo.
Não há dois soquetes (ou melhor, jamais deveriam) ter os mesmos identificadores "este fim" e "outro fim". O soquete "escutado" (aceitando as conexões de entrada) é o que possui um curinga "outra extremidade"; portanto, apenas um de cada vez pode existir. À medida que as conexões chegam, um accepté feito, retornando um soquete com uma tupla host: port para a outra extremidade.
Sua pergunta me lembra alguns anos antes do Cisco CCNA - tinha as mesmas dúvidas :)
Primeiro, o estabelecimento de várias conexões HTTP não está necessariamente vinculado à quantidade de guias que você abriu no navegador. Ao visitar um site com anúncios ou código do Google Analytics, por exemplo, você estará se conectando a vários sites, apesar de estar apenas em uma guia.
De qualquer forma, quando o navegador se comunica com o servidor da web, a porta de destino do tráfego enviado ao servidor da web é a porta 80, enquanto a porta de origem é um número aleatório. A porta de origem é permitir que o servidor da Web saiba em qual porta ele deve se comunicar com você. Cada conexão http estabelecida terá sua própria porta aberta no seu computador. Tente executar o netstat com alguns sites abertos e você verá imediatamente o que quero dizer.
Você pode rir, mas este livro é uma maneira excelente e rápida de entender o básico do TCP / IP. Isto me ajudou bastante.