SYN/ACK를 무시합니다.

Mac OSX 네트워크 클라이언트 때때로 HTTPS 포트에 연결하는 데 문제가 있습니다. 네트워크 추적을 보면, 우리는이를보고있다 : 그 예상 그래서SYN/ACK를 무시합니다.

T0.0 client:port -> server:443 SYN 
T0.1 server:443 -> client:port SYN, ACK 
T3.1 server:443 -> client:port SYN, ACK 
T6.1 server:443 -> client:port RST

3 초 지연은 실패 SYN/ACK에 재 시도에 대한 TCP 제한 시간을 일치합니다. 그러나 여기서 놀라운 점은 클라이언트가 ACK 나 RST로 응답하지 않는다는 것입니다. 클라이언트가 두 번 로그인하려고하면 성공합니다. 이 문제는 많은 첫 번째 연결 시도에서 재생산됩니다. 동시에 진행되는이 프로그램의 다른 HTTPS 연결이 있으며 네트워크 추적에 문제가없는 것처럼 보입니다.

내 생각에 소켓이 때때로 잘못 관리되는 경쟁 조건이 있습니다. 그러나 지금까지는 어떤 코드에서든이 영향을받은 클라이언트 (매우 크고 복잡한 소프트웨어)를 다시 만들 수 없었습니다. nmap 및 hping3을 사용하여 패킷을 수작업으로 만든 경우에도 클라이언트는 항상 적어도 RST를 보냅니다.

SYN/ACK에 응답하지 않도록 사용자 영역 코드에서 이와 같이 소켓을 구성 (의도적으로 또는 실수로) 할 수있는 방법이 있습니까?

출처

2010-11-19 Rob Napier

아니요, SYN/ACK를 닫을 때를 제외하고 사용자 토지의 TCP 소켓을 구성하여 들어오는 SYN/ACK에 대한 응답으로 나가는 RST를 유발할 방법이 없습니다. 그것은 나에게 커널 버그처럼 들린다. 이러한 모든 연결에 대해 궁금하네요. 단위 시간당 새 연결 수를 최소화하려면 HTTP를 최대한 사용하도록 설정해야합니다.

출처

2010-11-19 23:46:19 EJP

SYN/ACK는 TCP 프로토콜의 3 방향 핸드 셰이크 연결의 일부이므로 무시할 수 없습니다. 문제는 서버 소켓이 제대로 열려 있지 않은 것 같습니다. 다른 가설은 서버가 액세스 할 수 없다는 것입니다 (방화벽이 방화벽을 차단하는 등).

프로그램을 알지 못하는 것보다 더 많은 도움을주기는 어렵습니다. 희망이 도움이!

편집 : 이전 클라이언트의 소켓을 올바르게 닫고 있는지 확인하십시오. 이전 소켓이 올바르게 닫히지 않고 OS가 허용 된 열린 소켓의 한계에 도달 할 수 있습니다. 이 경우 RST 패킷이 전송됩니다.

출처

2010-11-19 16:29:42 jmpcm

서버에 액세스 할 수없는 경우 SYN/ACK가 표시되지 않습니다. 내 문제는 * my * 측에서 필요한 ACK를 보내지 않는다는 것입니다. 규칙에 관계없이 SYN/ACK를 무시할 수 있습니다. 실제로 발생하기 때문에 현실이 항상 사양보다 우선합니다. 마찬가지로 소켓이 다 떨어지면 초기 SYN을 보내지 않을 것이지만 나는 그렇습니다. 내 작업 이론은 두 개의 다른 서버와 통신하려고 실수로 동일한 소켓 파일 디스크립터를 사용하여 네트워크 스레드에 연결해야한다는 것입니다. 그래도 시도해 보면 어떻게 될지 설명 할 수 없었습니다. –

미안하지만, 나는 당신과 의견이 다릅니다. TCP 연결에서 3 방향 핸드 셰이크를 무시할 수 없습니다! 이를 무시하면 연결이 설정되지 않습니다. 그러나 당신의 이론은 옳을 수 있습니다 : 클라이언트 측에서는 동일한 소켓에 동시 스레드를 사용하여 액세스하고 있으며 그 중 하나가 ACK를 전송하지 않고 소켓을 닫을 수 있으므로 서버가 보낸 RST를 전송할 수 있습니다. 이론을 확인해보십시오 (나는 당신의 프로그램을 모른다). 사실, RST의 가장 일반적인 원인은 소켓이 닫혀 있다는 것입니다. – jmpcm

OP에 동의합니다. 위의 대답은 분명히 잘못되었습니다. 서버 소켓이 올바르게 열리지 않았다면 SYN/ACK를 보냈습니다. – EJP

SYN/ACK를 무시합니다.

답변

관련 문제