웹 응답을 서버 쪽에서 보내는 데 걸리는 시간을 측정해야합니다. 저는 아약족과 클라이언트 쪽에서이 방법을 사용하고 있지만 클라이언트 측에 시간을 측정하는 서버 측 방법으로 만 제한된다는 것을 알고 있습니다.서버 만 사용하여 클라이언트에 HTTP 응답 시간 측정하기
대략적으로은 서버가 응답을 보낸 후 클라이언트 브라우저에서 ACK를 돌려 보내면 어림 잡을 수 있습니까?
설명한대로 ... http://www.usenix.org/event/usenix02/fu/fu_html/node10.html.
이 수치는 신뢰할 수 있습니까?
ACK는 전송 한 두 세그먼트마다 대략 한 번 도착합니다 (모두 정상이면). 그들은 고객이 데이터를 승인했음을 알려줍니다. 따라서 클라이언트에서 서버로의 이동 시간이 같다고 가정하면 deltaAckNum/deltaT는 평균 속도가 얼마나 큰지 알 수 있습니다. 분명히이 두 ACK 세그먼트가 더 많은 패킷을 나눌수록 더 좋습니다.
타임 스탬프 옵션을 보면 다양한 시점에서 RTT의 추정치를 얻을 수 있습니다. 한 쪽이 TSVal에서 타임 스탬프를 보내고 다른 쪽이 반환 패킷의 TSEcr 필드에서이를 에코합니다. 클라이언트에서 서버로의 지연뿐만 아니라 느낌을 얻는 데 도움이됩니다.
비록는 몇 "하지만,"언급 할 수있다 :
1) 특별히 누군가가 불평을하기 때문에 대용량 파일의 전송의 성능을 향상시키기 위해 노력하지 않는 한, 그것은 아주 잘 수 있습니다 병목 현상이 스택의 다른 곳에 있습니다. (예 : 서로의 요소를 모두 다운로드해야 항상 표시되도록하는 요소 등). 디버깅을 위해서는 YSlow이 좋을 것입니다.
2) 해당 클라이언트가 TCP 수준의 데이터를 ACK하지만 그 자체로 "영리한"것들 (셰이핑/컨텐트 필터링/etc 등)을 수행하는 프록시 같은 middlebox 뒤에있을 수 있습니다.