다른 브라우저에서 TCP/IP RST가 다르게 전송되는 경우

Question

Mac OS X (10.6)에서 YouTube 비디오 다운로드를 시작하고 이더넷 케이블을 5 초 정도 당긴 다음 다시 연결하면 다양한 결과가 나타납니다 브라우저에서. 오페라와 크롬을 사용하면 케이블을 다시 꽂은 후에 비디오가 계속로드됩니다. 그러나 사파리와 파이어 폭스는 절대로 그렇지 않습니다.

Wireshark를 사용하여 트래픽을 살펴보면 케이블을 다시 꽂은 후 Opera와 Chrome이 YouTube의 첫 번째 패킷을 ACK하지만 Safari와 Firefox가 TCP 헤더에서 RST 플래그 (0x4)를 설정하고 더 이상 트래픽이 발생하지 않습니다.

기기와 인터넷 연결 사이에 허브를 둘 수 있습니다. 케이블을 허브에 다시 연결할 때 문제가 없어지고 4 개의 브라우저 모두 비디오를 계속로드합니다. Wireshark 로그를 살펴보면, 머신이 멀티 캐스트 연결을 가까이서 볼 수 없으며 통과하는 패킷에 단순히 지연이 있음을 알 수 있습니다.

사파리와 파이어 폭스가 멀티 캐스트 연결을 닫은 다음 나중에 동일한 연결에서 데이터를 볼 경우 RST를 보냅니다.

내 질문은 왜입니까? 올바른 행동 방침은 무엇이며, 2/4 브라우저는 편도를하고있는 반면 다른 2/4는 다른 방식으로하고있는 이유는 무엇입니까? 파이어 폭스 어디에서 코드를 볼 수 있습니까?

대단히 감사합니다.

Answer 1

Firefox와 Safari는 멀티 캐스트 연결이 닫히면 열린 연결 목록에서 TCP 연결을 삭제 한 것으로 보입니다.

일단 TCP 연결이 닫히면 패킷을 보낼 때 RST 패킷을 보내면됩니다.

Answer 2

케이블을 당기면 인터페이스가 다운되고 이후 패킷에 "ICMP NO ROUTE HOST"가 표시됩니다. 그 때 무엇을 해야할지는 응용 프로그램에 달렸습니다. 즉각 포기 하시겠습니까? 아니면 더 오래 기다리시겠습니까? 파이어 폭스와 사파리는 오래 기다리지 않는 것처럼 보입니다.

허브를 그대로두면 컴퓨터에서 호스트에 대한 경로가 손실되었다는 것을 컴퓨터에서 알 수 없으므로 메시지가 나타나지 않습니다.

HTH,

Answer 3

나는이 오래된 질문 실현,하지만 난 비슷한 문제를 경험하고, 모든 자원을 찾는 많은 문제를 했어로 좀 더 철저한 정보 보증 생각합니다.

... 해당 응용 프로그램 수준의 브라우저 동작은 세계의 주요 기여는 다음과 같습니다

내 경험을 바탕으로

하고 Department of Computer Science at the University of Calgary의 연구, 저자는 TCP RST 패킷 응답에 관해서 발견 비정상적인 TCP 동작의 추세 특히 HTTP연결의 영구적 인 구현 및 관리의 불규칙성으로 인해이 문제가 발생합니다. 널리 사용되는 웹 브라우저의 TCP 동작을 수정하면 이러한 TCP RST 이상 의 대부분을 제거 할 수 있습니다.

기본적으로 브라우저는 TCP 재설정 동작을 다르게 구현하므로 결과적으로 다른 동작을 보게됩니다.또한 다른 운영 체제에서도 TCP RST headers differently을 구현하므로 다른 운영 체제에서 동일한 브라우저를 사용해도 약간 다른 결과가 발생할 수 있습니다. 중간에 허브를 추가하면 문제가 해결 될 수 있습니다.

Chromium 버그 추적기의이 문제는 why Chrome works과 관련이 있다고 생각합니다. 연결은 새로운 소켓 그룹, 문제가있는 연결을 다시 시도 할 수있는 단일 백업 소켓 요청이 너무 오래 걸리는 경우 비슷한 일이 Firefox in 2010

에 소개되었다. 이렇게하면 패킷 손실이있는 의 대기 시간이 줄어 듭니다.

일부 브라우저는 하나 이상의 RST 패킷 (IE 11/Safari 9/10, 테스트 결과 적어도)을 통해 연결을 적극적으로 종료합니다. chrome : // net-internals의 데이터를 기반으로 한 Chrome (v56 테스트)은 ERR_CONNECTION_RESET -103 오류가 발생한 후 동일한 소켓을 재사용하여 재 시도하는 것으로 보입니다. 그런 다음 성공할 때까지 몇 번 다시 시도합니다. 이 지능적인 재시도 동작은 특정 브라우저에서 연결이 끊어진 것을 다시 시작하게 할 수 있다고 생각합니다. 적절한 RFC 또는 스펙을 구현하지 못할 수도 있지만 (정확하게 찾을 수는 없습니다. HTTP/1.1 또는 단지 TCP Resets 일 수 있습니다)

내 경험으로 오늘은 Apache에서 Big- URL 패턴을 기반으로 트래픽을 두 개의 가상 서버 그룹 중 하나로 라우팅 한 IP F5 WAF/Load Balancer. Apache에서 keep keep alive를 해제하면 TCP RST 패킷이 반환되고 연결이 중단되는 문제가 해결되었습니다.