다음 이미지를 이해하는 데 도움이 정말 필요하지만 맥락에 대한 배경 정보를 제공하겠습니다.
포트 8080에서 프록시를 사용하도록 구성되고 인터넷 액세스가 필요한 앱이 있습니다. 하루 중 무작위로 앱이 연결에 실패하고 그냥 종료됩니다. 우리는 원인을 알아내려고 노력하고 있습니다. 우리는 FW 및 프록시 URL 규칙을 배제했습니다(작동할 때 항상 동일한 URL에 도달하고 어쨌든 실패합니다). 문제는 프록시 자체의 성능 문제와 관련된 네트워크라고 생각합니다. 문제의 원인을 파악하기 위해 해당 문제가 발생했을 때 네트워크 캡처를 수행해 왔습니다.
다음 이미지를 보면 IP 세부 정보가 제거된 스니펫입니다. 소스가 "42"인 첫 번째 줄은 포트 8080에서 프록시(IP 35)를 통해 TLS 요청을 하는 클라이언트 시스템입니다. 참고: 일반적으로 작동하고 동일한 URL/IP를 요청하지만 이것은 실패한 경우 중 하나입니다. 하단 창은 첫 번째 녹색 선의 세부 정보입니다.
강조 표시된 부분 "다음 시퀀스 번호"는 35(두 번째부터 마지막 줄까지)에서 마지막으로 반환된 패킷의 ACK와 일치합니다. 이는 본질적으로 클라이언트에게 전송된 모든 데이터를 수신했음을 알리는 응답입니다(이는 장치가 데이터 수신을 승인하면서 작동 중임을 의미합니다(FW 또는 네트워크 문제가 없음을 의미)). 하지만 데이터를 다시 보내지는 않습니다. 그 직후 클라이언트는 TCP RST를 발행합니다. 여기에 내 해석이 있지만 내 TCP 기술이 약간 녹슬었기 때문에 누군가 확인해 주었으면 합니다.
클라이언트가 어떤 형태의 요청을 프록시에 보내고 있지만 어떤 이유로 프록시가 (애플리케이션 계층에서) 응답하지 않습니다. 프록시가 TCP ACK로 응답하므로 이는 네트워킹 계층에서 모든 것이 양호함을 의미합니다. 이는 데이터가 네트워킹 스택을 통해 프록시 자체로 전달될 때 연결을 끊는 것이 프록시임을 의미합니다. 왜 그런 일이 일어나는지는 아직 모르지만 프록시 팀에 문의하여 이를 조사해야 한다고 말할 수 있도록 명확한 설명을 찾고 있습니다(그들은 이것이 프록시라고 생각하지 않습니다).
내 주장을 뒷받침하는 또 다른 증거는 RST 이전 이미지에서 볼 수 있는 첫 번째 4줄이 여러 번 반복된다는 것입니다. 다시 말하지만 이는 클라이언트가 요청이 무엇이든 다시 보내고 있지만 응답을 받지 못한다는 것을 의미합니다. 그런 다음 결국 포기하고 재설정을 발행합니다.
분명히 프록시 앞에는 로드 밸런서가 있고 프록시는 실제로 여러 대의 시스템입니다. 백엔드 중 하나에 문제가 있고 LB가 풀에서 노드를 제거하지 않아 잠재적으로 데이터를 블랙홀로 보내는 것 같은 느낌이 듭니다.
저는 2차 소견을 찾고 있습니다. 캡처한 내용을 토대로 위에 있는 요약이 정확해 보입니까?
답변1
그 직후 클라이언트는 TCP RST를 발행합니다.
즉시는 아닙니다. RST는 서버에서 마지막 ACK를 보낸 후 30초 후에 클라이언트에서 전송됩니다.
... RST 이전 이미지에 보이는 첫 번째 4줄은 여러 번 반복됩니다.
이것들은 같은 선이 아닙니다. ACK에 대해 다른 값을 갖습니다.
내 해석은 클라이언트가 더 큰 페이로드(따라서 이를 승인하기 위한 서버의 여러 ACK)로 요청을 보낸 다음 프록시가 응답을 다시 보낼 것으로 기대한다는 것입니다. 30초 동안 응답이 없으면 클라이언트는 RST와의 연결을 포기하고 닫습니다.
프록시가 응답을 보내지 않는 이유는 명확하지 않습니다. 프록시 문제일 수도 있습니다. 그러나 이는 업스트림 서버의 문제일 수도 있으며 서버는 문제를 클라이언트에 전파할 뿐입니다.
해석이 틀릴 수도 있으니 주의하세요. 제공되는 컨텍스트 및 패킷 캡처가 많지 않으므로 정보를 바탕으로 한 추측에 가깝습니다.