대역폭 업그레이드속도가 내 파일 복사본을 가속화하지 않은 이유는 무엇입니까?

"우리는 T1 (1.544 mbps)에서 T3 (44.736 mbps)로 업그레이드했기 때문에 해당 파일을 복사하는 데 90 분이 걸리는 이유는 무엇입니까?"

간단한 대답은 더 많은 용량이 더 빠른 바이트와 동일하지 않다는 것입니다. 용량을 거의 29(44.736 / 1.544) 정도 늘리면 동일한 90분 동안 29개의 파일을 복사할 수 있지만 한 파일을 더 빨리 복사할 수 없을 것입니다. 작년에 블로그 "응용 프로그램 성능 문제 및 대기 시간"이라는 제목의 블로그에 터치했지만 파일 전송및 copy_file 더 집중 블로그가 필요하다고 생각합니다.

키는 창 크기, 즉 수신 호스트/응용 프로그램에서 승인을 중지하고 기다릴 필요 없이 전송 호스트/응용 프로그램을 보낼 수 있는 바이트 수와 관련이 있습니다. FTP와 같은 일부 응용 프로그램에는 응용 프로그램 계층 승인이 없으며 TCP에 의존합니다. 이 경우 창 크기는 원격 호스트의 TCP 계층이 광고하는 내용, STCP가 지원하는 최대 최대 64K 바이트를 기반으로 합니다. 일부 응용 프로그램에는 응용 프로그램 계층 창이 있으며 이러한 응용 프로그램에대한 제한 창은 TCP 및 응용 프로그램 창의 더 작습니다.

최대 처리량은

W / RTT = T

어디

W는 바이트의 창 크기입니다.

RTT는 초 왕복 시간입니다.

T는 초당 바이트로 처리량입니다.

왕복 시간은 일부 데이터를 전송하고 승인을 얻는 데 걸리는 시간입니다. 장거리, 즉 크로스 컨트리의 경우, 그 시간은 주로 바이트가 이동해야 하는 거리와 끝점 사이의 모든 네트워크 장비의 처리 속도를 기반으로 합니다. 수신 호스트의 처리 속도, 패킷 크기(TCP MSS 값, "서브넷 에서 처리량을 개선하는 쉬운 방법")를 참조하고 물론 가장 느린 링크의 대역폭은 더 작은 역할을 합니다.

예를 들어 RTT가 0.050초이고 창이 64K인 경우 최대 처리량은 초당 1,310,720바이트(64* 1024/0.050)가 됩니다. 링크의 사용되지 않는 용량이 처리량보다 크면 용량을 늘리면 전송 시간이 빨라지지 않습니다.

T는 가능한 최대 처리량입니다. 창을 늘리거나 RTT를 줄이는 데 부족하면 상황이 더 빨라질 수 없지만 적대적인 네트워크 조건으로 인해 상황이 상당히 느려질 수 있습니다.

전송 시간을 예측하는 것은 파일 크기를 처리량으로 분할하는 것입니다.

F / W * RTT = Ti

어디

F는 바이트의 파일 크기입니다.

W는 바이트의 창 크기입니다.

RTT는 초 왕복 시간입니다.

Ti는 파일을 전송하는 데 몇 초 만에 시간입니다.

OSL은 4K의 응용 프로그램 창 크기를 가지고, OpenVOS 파일 시스템은 4K 바이트의 블록에 파일 크기를보고하므로 copy_file 명령을 사용하여 두 개의 OpenVOS 시스템 사이의 파일을 복사 하는 시간을 추정하는 것은 간단하다

F * RTT = Ti

어디

F는 블록의 파일 크기입니다.

RTT는 초 왕복 시간입니다.

Ti는 파일을 전송하는 데 몇 초 만에 시간입니다.

0.050 초 RTT가있는 링크에서는 OSL이 41 분 이상 걸리면 50,000 블록 파일 (50,000 * 0.05)을 복사합니다. 최대 처리량은 초당 81,920바이트(4096/0.050)입니다. 링크의 사용되지 않는 네트워크 용량이 초당 81,920바이트를 초과하는 한 용량을 추가하는 것은 파일을 복사하는 데 걸리는 시간을 줄이지 않습니다.

왕복 시간을 측정하는 가장 간단한 방법은 핑입니다. 안타깝게도 ping은 RTT에 대해 하나의 숫자를 제공하지 않지만 여러 숫자와 숫자는 다음과 같은 경우에 크게 다를 수 있습니다.

최상의 처리량을 계산하는 데 관심이 있으시면 가장 낮은 숫자를 사용합니다. 당신이 무엇을 기대해야하는지의 합리적인 추정에 관심이 있다면 10의 핑 수를 사용, 두 가장 높은 2 가장 낮은 숫자를 밖으로 밖으로 토스와 나머지 평균.

내가 적대적인 네트워크 위에서 말했듯이 크게 일을 느리게 할 수 있습니다.  Ping 시간 시간은 이를 나타냅니다. 따라서 시간 중지는 이러한 계산이 상당히 낙관적이라는 것을 의미합니다. 또한 발신자가 가능한 한 빨리 데이터를 읽고 보내지 못하게 하거나 수신자가 도착 속도보다 느리게 데이터를 읽을 수 있도록 하는 바쁜 디스크 및 CPU로 전송 속도가 느려질 수 있으며, 애플리케이션 승인(왕복 시간 증가) 및 전송 호스트가 전송을 중지하도록 하는 TCP 수신 버퍼를 채울 수 있습니다. 이러한 조건이 적용되는지 알 수 있는 유일한 방법은 패킷 추적입니다.