Eu percebi hoje que fundamentalmente não entendo como a comunicação de portas funciona.
Se eu inicializar uma instância de um servidor da Web ouvindo na porta 80, ela poderá responder a muitas solicitações de várias guias diferentes 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 portas.
Eu sempre levei isso como um dado, (apenas um processo pode se ligar 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 LISTEN em uma porta por vez (tecnicamente, um soquete é dedicado a escutar). Mas, uma porta pode lidar com muitos soquetes de transferência de dados, um soquete é uma combinação de IP local / porta e endereço IP remoto / porta remota. Dessa forma, uma vez que o servidor aceita a conexão de entrada enquanto LISTENing abre um novo socket dedicado àquela conversação e transfere o processamento para outra coisa, então volta para a LISTENING.
O navegador se conecta de uma porta aleatória alta (ou seja, > 1024) em seu computador à porta 80 de um servidor remoto. Portanto, não há conflito de portas em sua máquina.
Se você usar várias guias para se conectar ao mesmo servidor remoto (ou se houver muitos usuários se conectando ao servidor), todos eles irão para a mesma porta e serão atendidos pelo mesmo processo (ou seja, o servidor da Web do site).
O servidor que escuta na porta 80 não tem que lidar com vários processos. Os daemons TCP simples dos anos mais antigos só podiam lidar com uma conexão por vez. Você pode emular esse comportamento fazendo com que um programa como netcat escute em uma porta específica e tente conectar duas máquinas a ele. Um vai entrar, o outro vai saltar sem uma conexão. Esses daemons são praticamente inúteis, então você nunca mais os vê.
Para algo como um servidor web, ele está escutando diretamente na porta. O que você deve ter em mente é que ele está na parte superior 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 tem algumas opções.
Uma possibilidade é que ele passe o objeto socket para um novo thread no mesmo processo. Sempre que a comunicação acontece sobre este soquete, este segmento irá lidar com isso. O processo pai medeia quais encadeamentos estão ativos a qualquer momento, o que pode ser muito.
Outra possibilidade é que ele gere um novo processo e passe o objeto socket para o processo. Pelo que entendi, cabe agora ao sistema de soquete do sistema operacional mediar a comunicação entre esses processos-filhos e seus alvos. 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 em qualquer um dos modos.
Em essência, a biblioteca de soquetes fornece um nível de processamento paralelo para o servidor da web. Ele pode manipular várias conexões simultâneas transferindo dados ativamente, ao mesmo tempo aceitando novas conexões.
Para um navegador que pode executar várias tentativas de conexão a um servidor da Web para melhorar os tempos de carregamento, o paralelismo também se aplica ao navegador, isso é uma coisa boa e maravilhosa. O navegador controla o estado da página durante o carregamento e as várias tentativas de conexão que ela faz são parte do processo.
Existem, efetivamente, dois "tipos" de soquetes de fluxo. Um tem um wild card "other end", um tem um host específico: port para o outro lado.
Não é possível que dois sockets (ou melhor, nunca) tenham os mesmos identificadores "this end" e "other end". O soquete que é "escutado" (aceitando conexões de entrada) é aquele que tem um "fim diferente" de caractere curinga, de modo que apenas um de cada vez pode existir. Conforme as conexões chegam, um accept é feito, retornando um soquete com uma tupla host: port para a outra extremidade.
Sua pergunta me faz lembrar de alguns anos antes de a Cisco CCNA - ter as mesmas dúvidas:)
Primeiro, estabelecer várias conexões HTTP não está necessariamente ligado à quantidade de guias que você abriu no seu navegador. Ao visitar um site com anúncios ou código do Google Analytics, por exemplo, você se conectará 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 de volta. 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 é um ótimo & maneira rápida de obter o básico do TCP / IP. Isso me ajudou muito.
Tags networking tcp port