VPN을 통한 파일 공유가 느리게 느껴지는 이유: 대역폭이 아니라 왕복
파일 공유 프로토콜은 LAN 지연을 전제합니다. 수다스러운 메타데이터, 작은 파일 작업, MTU 문제는 대역폭을 늘려도 고쳐지지 않는 멈춤을 만듭니다.
VPN 너머의 공유 폴더를 열고 디렉터리 목록이 기어가듯 진행되기를 기다리는 것은 익숙한 경험이며, 첫 반응은 대역폭을 탓하는 것입니다. 대개 링크는 거의 놀고 있습니다. 프로토콜은 응답을 기다리는 데 시간을 쓰고, 기다릴 때마다 LAN에서는 결코 청구되지 않던 왕복 한 번이 통째로 듭니다. 작업의 모양을 고치면 공유는 다시 쓸 만해집니다.
원격 작업 사본은 모양이 잘못됐다
SMB는 파일을 열고 메타데이터를 읽고 수많은 작은 교환으로 확인을 보냅니다. 매핑된 드라이브 위의 버전 관리 작업 사본은 로컬 파일 시스템 지연을 전제하고 작은 파일을 많이 읽습니다. 데스크톱 데이터베이스는 사용자가 작업하는 동안 페이지를 끌어옵니다. 이들 각각은 교환 횟수에 비례해 비용이 늘어나므로 지연을 배수로 만들며, 그래서 40 ms 터널은 몇백 번의 작업을 몇 초로 바꿉니다. 그 계산에서 페이로드 크기는 거의 무관합니다.
암호화 오버헤드는 그중 작은 부분에 불과하지만, 재전송 한 번과 무너진 혼잡 윈도가 관련된 바이트보다 훨씬 비싸기 때문에 손실이 더 나쁩니다.
메가바이트보다 왕복부터 세라
용량을 사기 전에 지연을 측정하십시오. ping 한 번이면 각 교환이 무엇을 지불하는지 알 수 있습니다.
ping -c 10 fileserver.example.net요약은 최소·평균·최대 왕복 시간을 보여 주며, 편차는 평균만큼 중요합니다. 평균에 디렉터리 목록이 수행하는 교환 횟수를 곱한 뒤 실제로 관찰한 시간과 비교하십시오. 큰 파일 하나는 빠르게 전송되는데 탐색이 느리다면 제약은 지연과 요청 수입니다. 절대 포화되지 않는 링크에 열 배의 용량을 더해도 아무것도 바뀌지 않습니다.
바이트가 아니라 작업을 옮겨라
더 넓은 관에 돈을 쓰는 대신 작업이 일어나는 위치를 바꾸십시오. 저장소를 마운트하는 대신 서비스하고, 차이만 보내는 도구로 한꺼번에 복사하십시오.
rsync -av --info=progress2 ./project/ [email protected]:/srv/share/project/저장소를 서비스하면(hgweb이나 원격 Git처럼) 클라이언트가 로컬 클론에서 작업하므로 파일 시스템 호출이 터널을 건너지 않습니다. rsync는 양쪽을 훑고 바뀐 블록만 보내므로 순진한 복사가 치르는 교환의 대부분을 없앱니다. 데스크톱 데이터베이스는 서버 측 엔진에 두고 클라이언트는 화면만 남기거나, 클라이언트 전체를 내부 호스트에서 돌려야 합니다. 각 선택은 프로토콜이 얼마나 많은 지연에 노출되는지를 바꾸며, 바로 그 점이 핵심입니다.
같은 크기 근처에서 멈추는 것은 MTU 증상
ping과 작은 페이지는 되는데 큰 전송이 비슷한 데이터 양 뒤에 멈춘다면 대역폭이 아니라 패킷 크기를 가리킵니다.
ping -M do -s 1400 -c 3 fileserver.example.netICMP와 IP 헤더가 28바이트를 더하기 때문에, 시험이 성공하면 1428바이트 IP 패킷이 단편화 없이 경로를 지나갑니다. 단편화 금지 플래그로 실패한다면 터널의 사용 가능한 MTU가 서버의 가정보다 작다는 뜻입니다. 9000바이트 버퍼를 1500바이트 경로로 보내는 서버는 단편화나 손실을 강요하며, ICMP가 필터링되면 경로 MTU 탐색은 조용히 실패할 수 있습니다. 터널의 MTU를 낮추거나 OpenVPN에서 mssfix 를 켜거나 서버 버퍼를 줄인 뒤 같은 전송을 다시 실행해 확인하십시오.
중요한 차이를 측정하라
정책이 허용하는 곳에서 같은 작업을 로컬·터널 통과·직접 인터넷 경로의 세 가지로 실행하십시오. 각각에 대해 왕복 시간, 큰 스트림 하나의 속도, 디렉터리 목록이나 앱 실행에 걸리는 시간을 기록하십시오. 로컬 실행과 터널 실행을 비교하면 어떤 비용이 지배적인지 보입니다. 느리게 끝나는 복사는 속도나 지연 문제를, 일정한 지점에서 죽는 복사는 패킷 크기나 경로의 상태 저장 장치를 가리킵니다.
처음 몇 메가바이트만 끌린다면 인증과 메타데이터를 보지만, 모든 것이 기어간다면 용량과 손실을 보십시오. 맞는 원인을 고치고, WAN 링크가 LAN 케이블처럼 행동하리라 기대하지 마십시오.