2013-02-23 4 views
0

마이크로 칩 임베디드 플랫폼에서 실행중인 웹 서버를 디버깅하고 있습니다. 펌웨어 소스가 모든 TCP/IP 통신을 완전히 제어 할 수 있다는 점을 제외하면 임베디드 부분은 관련이 없어야합니다.개별 HTTP GET 파일 요청 간의 브라우저 지연

특히 Internet Explorer에서는 서버 콘텐츠를 렌더링하기 전에 필요한 모든 GET 요청 사이에 3 초에서 10 초 정도의 지연이 있습니다. 처음으로 사이트에 액세스 할 때 아무 것도 캐시되지 않으면 일반적으로 검색 할 파일이 약 5 개 (htm, css, js)이므로 사용자가 페이지를보기 전에 15 초 이상 걸립니다.

Wireshark 캡처는 웹 서버가 각 연결 요청을 받으면 즉시 응답하기 때문에 지연을 도입하는 클라이언트라는 것을 보여줍니다. 연결이 완료되고 양측이 FIN/ACK를 보낸 후에 클라이언트가 다음 GET을 위해 다음 SYN을 보내기 전에 최소 3 초의 일시 중지가 표시됩니다. SYN에서 FIN/ACK 로의 완벽한 연결에는 문제가 없으며 0.5 초도 걸리지 않습니다.

최종 ACK 패킷의 확인 번호가 그에 따라 증가하므로 각 측에서 상대방 FIN 플래그를 확인하고 있음을 확인했습니다. 나는 캡처를 클라이언트의 MAC 주소와 관련된 모든 트래픽을 표시하도록 확장했으며 지연 중에는 어떤 종류도 존재하지 않습니다.

아무도 무슨 일이 일어나고 있는지 알 수 있습니까? HTTP 헤더와 같은 서버 측에서이 문제가 발생합니까? 어떤 도움을 주셔서 감사합니다.

답변

1

나는이 문제가 웹 서버가 청취 TCP 소켓을 하나만 실행하고 있다는 결론을 내렸다.

Internet Explorer와 같은 클라이언트는 병렬 스레드로 파일을 검색 할 수있는 여러 개의 동시 요청을 분명히 기대할 수 있습니다. 하나의 스레드가 하나의 청취 소켓을 점유하면 두 번째 파일을 얻으려는 두 번째 스레드는 첫 번째 스레드가 소켓을 해제 할 때까지 대기해야합니다. 두 번째 스레드의 첫 번째 연결 시도가 실패하면 다시 시도하기 전에 3 초 후 시간 초과되어야합니다.

알고리즘이 시간 종료되기 때문에 소켓이 수신 대기 상태로 돌아 가기 전에 0.5 초만 차지하는 것은 중요하지 않습니다. 두 번째 스레드는 시간 초과 될 때까지 다시 시도하지 않으므로 파일 요청 간의 지연이 발생합니다.

클라이언트는 소켓이 다시 사용 가능하다는 것을 알기에 가장 좋은 위치에있는 첫 번째 스레드로 두 번째 파일 요청을 전달할 정교함이 없습니다. 이러한 기능은 광산과 같은 경우에 처리량을 최적화 할 수 있습니다.