"방금 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이 50,000개 블록 파일(50,000 * 0.05)을 복사하는 데 약 41분 이상 소요됩니다. 최대 처리량은 초당 81,920바이트(4096 / 0.050)입니다. 링크의 미사용 네트워크 용량이 초당 81,920바이트보다 클 경우, 용량을 추가해도 파일 복사 시간이 단축되지 않습니다.
왕복 시간(RTT)을 측정하는 가장 간단한 방법은 ping을 사용하는 것입니다. 불행히도 ping은 RTT에 대해 하나의 숫자를 제공하지 않고 여러 숫자를 제공하며, 이 숫자들은 크게 달라질 수 있습니다. 예를 들어:
ping 172.16.1.80 Pinging host 172.16.1.80 : 172.16.1.80ICMP Echo Reply:TTL 53 time = 418 msICMP Echo Reply:TTL 53 time = 107 msICMP Echo Reply:TTL 53 time = 91 msICMP Echo Reply:TTL 53 time = 100 msHost 172.16.1.80 replied to all 4 of the 4 pingsready 12:03:15 |
최상의 처리량을 계산하고 싶다면 가장 낮은 수치를 사용하십시오. 예상 가능한 합리적인 추정치를 원한다면 핑 카운트 10을 사용한 후, 가장 높은 두 개와 가장 낮은 두 개를 제외하고 나머지를 평균화하십시오.
ping 172.16.1.80 -count 10Pinging host 172.16.1.80 : 172.16.1.80ICMP Echo Reply:TTL 53 time = 89 msICMP Echo Reply:TTL 53 time = 96 msICMP Echo Reply:TTL 53 time = 95 msICMP Echo Reply:TTL 53 time = 105 msICMP Echo Reply:TTL 53 time = 186 msICMP Echo Reply:TTL 53 time = 87 msICMP Echo Reply:TTL 53 time = 90 msICMP Echo Reply:TTL 53 time = 90 msICMP Echo Reply:TTL 53 time = 89 msICMP Echo Reply:TTL 53 time = 96 msHost 172.16.1.80 replied to all 10 of the 10 pingsready 12:12:39 calc 96 + 95 + 90 + 90 + 89 + 96 556ready 12:12:49 calc 556 / 692.6666666666667ready 12:12:57 |
위에서 언급했듯이 적대적인 네트워크는 속도를 상당히 저하시킬 수 있습니다. 핑 시간 초과 현상이 이를 나타내는 지표입니다. 따라서 모든 시간 초과 현상은 해당 계산이 상당히 낙관적일 가능성이 높음을 의미합니다. 디스크나 CPU가 과부하 상태일 경우 전송 속도가 저하될 수 있습니다. 이로 인해 송신 측이 데이터를 최대한 빠르게 읽고 전송하지 못하거나, 수신 측이 데이터 도착 속도보다 느리게 데이터를 읽게 되어 애플리케이션 확인 응답이 지연되고(왕복 시간 증가), TCP 수신 버퍼가 가득 차 송신 호스트가 전송을 중단할 수 있습니다. 이러한 상황이 발생하는지 확인하는 유일한 방법은 패킷 추적을 수행하는 것입니다.