대기 시간이 긴 링크를 통한 HTTP 성능

대기 시간이 긴 경로를 통해 로컬 서버로 파일을 전송하기 위해 이전에 FTP를 사용한 사용자가 있습니다. 이러한 전송 (선택이 아닌)에 대해 HTTP로 전환했으며 파일 전송 성능이 심각하게 저하되었습니다. 사용자 서버의 TCP 창 크기는 FTP 및 네트워크 대기 시간에 맞게 최적화되었습니다.

소스 서버 (예 : 웹 서비스)에서의 HTTP 구현에 따라 HTTP가 작은 / 기본 TCP 창 크기를 사용하거나 영향을 줄 수 있습니까?

http tcp

— 척 N.
소스

어떤 OS와 어떤 HTTP 서버가 사용되고 있는지 알려 주시겠습니까? 그리고 그들의 버전? 최신 OS의 많은 네트워크 스택에서 적응 가능한 TCP 창 크기를 사용하는지 또는 고정 값을 사용하여 적합하지 않은지 확인하기 위해 어떤 구성을 사용하는지 확인하는 것이 흥미로울 것입니다. TCP 패킷 추적 프로그램 (예 : Wireshark)을 사용하여 TCP 창 크기를 협상하는 방법과 방법을 고려할 수 있습니다.

— Huygens

질문을 업데이트하는 경우 알려주십시오 (예 : 내 이름으로 의견을 보내주십시오)

— Huygens

아니요, HTTP와 FTP는 기본적으로 순수한 TCP를 통해 파일을 전송합니다. FTP에서 작동했던 것과 동일한 TCP 조정이 HTTP에서도 작동해야합니다.

현재보고있는 성능 문제는 아마도 HTTP 클라이언트 나 서버 구현과 관련이있을 것입니다. 그들은 아마도 TCP를 효율적으로 사용하지 않을 것입니다. 예를 들어, 올바른 구현은 롤링 버퍼를 사용하여 항상 TCP 파이프를 가득 채우도록주의합니다. 순진한 구현은 한 번에 하나의 버퍼 만 TCP에 전달하고 새 버퍼를 전달하기 전에 버퍼가 완전히 전송 될 때까지 기다립니다. 이로 인해 파이프가 버퍼 사이에서 부분적으로 배수됩니다. 이는 지연 시간이 긴 링크에 대해 수행 할 수있는 최악의 작업 중 하나입니다. 이 실수를 저지른 FTP 클라이언트 나 서버가있는 경우,이 실수를 저지른 HTTP 클라이언트 나 서버만큼 성능이 떨어집니다.

이것은 순진한 구현이 TCP를 효율적으로 사용하지 않는 방법의 한 예일뿐입니다. 나는 이것이 당신의 경우에 일어나고있는 것이라고 반드시 말할 필요는 없지만 확실한 가능성입니다.

— iff
소스

고마워 나는 이것을 운없이 몇 시간 동안 연구 해왔다.

— 척 N.

한 측면에 동의하지 않습니다. 과거에는 대부분의 OS의 TCP 스택이 TCP 창 크기를 동적으로 조정할 수 없었습니다. 따라서 많은 옛날 앱이 수동으로 TCP 창 크기를 설정하고 고정했습니다 (소켓 옵션). 따라서 여기에서 사용되는 HTTP 서버는보다 현대적이고 적응 가능한 스택에서 실행될 수 있지만 대기 시간이 짧은 링크에 대해 구성되거나 프로그래밍되지 않을 수 있습니다. OS와 HTTP 서버가 실행되고 있다는 것을 알지 못하면 당신만큼 결정적이기는 어렵습니다.

— Huygens