O que acontece quando 2 hosts simultâneos estabelecem uma conexão em um handshake de 3 vias

Digamos que dois hosts, A e B, tentem iniciar uma conexão entre si, mas o SYN de A chega a B antes que o SYN de B chegue ao A.

Minha resposta é que A enviaria SYN ACK e ignoraria o SYN de B. Estou correto?

networking tcp sockets

— orange
fonte

Não. Duas conexões são estabelecidas e cabe ao seu aplicativo detectar isso e decidir se é necessário descartá-las.

— Sven

@Sven Então não há algum tipo de protocolo declarado pela RFC?

— orange

O que? Pense nisso: o Host A tenta o SSH para o Host B e vice-versa. Por que uma das conexões não deve ser estabelecida? Eles são completamente não relacionados.

— Sven

SvW está correto, as conexões são independentes. Enquanto não houver nada impedindo que as conexões sejam estabelecidas, ambas seriam. A ordem é indeterminada, dada a informação fornecida. A ordem também é irrelevante, a menos que os aplicativos que iniciam e recebem as conexões em cada extremidade interajam de alguma forma que coloque alguma relevância na ordem de conexão.

— Chris S

@psusi - não, bem, tipo de não. Assim, posso estabelecer uma sessão SSH de comp A a comp B e depois uma de comp B a comp A e ambas podem ser pela porta 22. Tenha em mente que a porta 22 é a porta DESTINATION. As portas SOURCE em ambos os lados serão diferentes - então elas ainda serão duas conexões autônomas usando as mesmas portas de destino e não haverá conflitos. Eu posso até estabelecer duas conexões SSH de comp A a comp B, ambas usando a porta 22 como a porta DESTINATION e ainda funcionará bem, mas ambas as conexões ainda terão diferentes portas SOURCE.

— MaQleod

Respostas:

Duas conexões seriam feitas. O TCP não está ciente do estado dessa maneira - nenhuma conexão teria qualquer conceito da outra conexão.

Por exemplo:

Connection 1:
192.168.1.5 sends SYN to 192.168.1.6 on port 80.

Connection 2:
192.168.1.6 sends SYN to 192.168.1.5 on port 80.

Para que isso continue, ambos precisariam de um serviço de escuta na porta 80, então cada um teria algo escutando no TCP para a porta 80 e esse serviço receberia o SYN e responderia com um SYN-ACK:

Connection 1:
192.167.1.6 responds with SYN-ACK to 192.168.1.5 on port 80

Connection 2:
192.167.1.5 responds with SYN-ACK to 192.168.1.6 on port 80

Tenha em mente que esses serviços de escuta estão em máquinas opostas - não há como saber que o outro também recebeu um SYN, então não há razão para não enviar um SYN-ACK.

Como o protocolo TCP determina, uma vez que o lado de origem recebe o SYN-ACK, ele responderá:

Connection 1:
192.168.1.5 sends ACK to 192.168.1.6 on port 80.

Connection 2:
192.168.1.6 sends ACK to 192.168.1.5 on port 80.

Agora você tem duas conexões independentes com handshakes TCP completos. Como mencionado nos comentários de SvW: se isso é ruim, cabe a qualquer aplicativo iniciar as conexões para determinar se esse estado estava presente e descobrir qual conexão quebrar - essa parte não é o trabalho do TCP.

— MaQleod
fonte

Lembre-se de que um soquete TCP é um quádruplo srcHost: srcPort: dstHost: dstPort e que, para uma conexão ser estabelecida, um host deve escutar em uma porta específica.

Portanto, para a primeira conexão, o soquete A: portA: B: portB será (B ouve na portB):

no estado SYN_SENT em A
no estado SYN_RECEIVED em B

E para a segunda conexão, A: portA ': B: portB' (escuta no portA ')

em SYN_SENT em B
no estado LISTEN em A

— Xavier Lucas
fonte

Você se importa de postar a resposta completa à minha pergunta, por favor. Pelo que entendi, haverá 2 conexões certo? Em que ordem chegam as mensagens? Obrigado! :)

— orange

Esta é realmente a resposta completa para sua pergunta. As duas conexões não estão relacionadas porque, se você enviar um pacote SYN, a outra mão deverá estar no estado LISTEN para que a conexão seja estabelecida. Então portas são necessariamente diferentes.

— Xavier Lucas

Supondo que ambos os hosts usem o mesmo par de portas, uma conexão seria estabelecida. Na prática, isso não acontece, porque quando os hosts estabelecem uma conexão, eles usam uma porta local aleatória e uma porta remota bem conhecida, portanto, os dois hosts não usam o mesmo par de portas. Então, mesmo que o fizessem, o momento teria que ser o certo, de modo que os SYNs passassem um no outro em vôo. Se um host obtiver o SYN antes de enviar o seu próprio, ele responderá com um RST.

— psusi
fonte