No protocolo UDP, um soquete é identificado exclusivamente pelo IP de origem e pela porta de origem.
No protocolo TCP, o soquete é identificado exclusivamente pelo IP de origem, porta de origem, IP de destino e porta de destino. Por que o protocolo TCP requer duas informações extras
Nota: para a terminologia TCP, o soquete é o par endereço-porta; um par de soquetes define a conexão . (Por RFC 793 p5)
Receio que você esteja enganado sobre o UDP, que, embora ele realmente não tenha "soquetes" - mesmo que a biblioteca Berkeley Sockets os chame assim, e é razoável chamar um par de endereço-porta - multiplexes em essencialmente da mesma maneira que o TCP.
Uma situação típica em que você pode ver isso é o caso de várias resoluções DNS simultâneas de um host para o mesmo servidor DNS, onde claramente apenas o número da porta de origem é necessariamente diferente. Você pode ver que essa é exatamente a mesma situação que várias conexões TCP simultâneas de um cliente para um único servidor da web.
O UDP possui datagramas sem conexão. O host A envia o datagrama a partir de um par de endereço-porta, direcionado a um par de endereço-porta em B, que normalmente, mas nem sempre, responde da maneira espelhada. Falando mais livremente da "comunicação", ele opera exatamente nas mesmas quatro tuplas que uma conexão TCP.
Às vezes, você verá referência a uma tupla de 5 (procotol, endereço de origem, porta de origem, endereço de destino, porta de destino), onde o protocolo seria 17 para UDP, 6 para TCP etc. É para isso que a maioria dos firewalls, roteadores etc. usa para NAT e operações similares para identificar esse par de comunicação.
mesmo que o servidor tenha estabelecido um soquete TCP especificamente para essa sessão em uma porta diferente
Receio que você também esteja enganado sobre o TCP, possivelmente por causa do conflito de terminologia entre a definição do protocolo TCP (RFC 793) e sua implementação prática mais comum, a Berkeley Sockets Library, usada no Unix, e tudo o que descende. isto.
Se você se concentrar no protocolo, é muito mais claro: não há "porta diferente". O servidor da Web está escutando apenas , por exemplo, 1.1.1.1, porta 80. O cliente envia apenas a partir da ilustração 2.2.2.2, porta 56789. Cada pacote único será 1.1.1.1:80 a 2.2.2.2:56789 ou vice-versa ; facilmente verificada olhando pacotes com tcpdump / wireshark / etc.
(Para resumir brevemente a implementação de Berkeley, uma conexão TCP é representada por um número inteiro chamado tipicamente, mas de maneira confusa sockfd
; um soquete TCP é representado por a struct sockaddr
. A accept()
chamada de sistema fala de maneira muito confusa de fazer um "novo soquete conectado", pelo que significa nova conexãoestrutura no estado conectado. A tupla dessa coisa resultante estaria em nosso exemplo (1.1.1.1, 80, 2.2.2.2, 56789). Com relação ao UDP, a biblioteca permite que você considere o UDP conectado, o que é uma maneira conveniente, embora completamente errada, de descrever a troca de datagramas UDP entre dois processos, e apenas significa que a estrutura lembra o par de endereço-porta remota, o que, em termos de programação, torna o UDP "conexão" se parece com uma TCP. Lembre-se de que a biblioteca de Berkeley não é apenas para IP e tem generalizações de vários sistemas de rede subjacentes diferentes. Se você quiser acompanhar esses termos de programação de rede, sugiro Stack Overflow, que possui muitos programadores de rede muito competentes.)