Dlaczego udostępnianie plików przez VPN wydaje się wolne: rundy, nie Mbps

Otwarcie folderu udostępnionego przez VPN i czekanie, aż lista katalogu będzie się wlec, to znane doświadczenie, a pierwszy odruch to obwinianie przepustowości. Zwykle łącze jest prawie bezczynne. Protokół spędza czas na czekaniu na odpowiedzi, a każde oczekiwanie kosztuje pełną rundę, której sieć lokalna nigdy nie naliczała. Napraw kształt pracy, a udostępnianie znów stanie się użyteczne.

Zdalna kopia robocza ma niewłaściwy kształt

SMB otwiera pliki, czyta metadane i potwierdza w wielu małych wymianach. Kopia robocza systemu kontroli wersji na zamapowanym dysku zakłada opóźnienie lokalnego systemu plików i czyta wiele małych plików. Baza danych na pulpicie pobiera strony, gdy użytkownik pracuje. Każde z tych zjawisk zamienia opóźnienie w mnożnik, bo koszt rośnie wraz z liczbą wymian wykonywanych przez operację; tunel o opóźnieniu 40 ms zamienia więc kilkaset operacji w kilka sekund. Rozmiar ładunku jest w tej arytmetyce prawie nieistotny.

Narzut szyfrowania to jego mała część; utrata jest gorsza, bo jedna retransmisja plus załamane okno przeciążenia kosztują znacznie więcej niż dotyczące bajty.

Licz rundy, zanim policzysz megabajty

Zmierz opóźnienie, zanim kupisz przepustowość. Jeden ping mówi, ile płaci każda wymiana.

ping -c 10 fileserver.example.net

Podsumowanie podaje minimalny, średni i maksymalny czas rundy, a rozrzut jest tak samo ważny jak średnia. Pomnóż średnią przez liczbę wymian wykonywanych przez listę katalogu, a potem porównaj z czasem, który naprawdę obserwujesz. Jeśli jeden duży plik idzie szybko, a przeglądanie jest wolne, ograniczeniem są opóźnienie i liczba żądań. Dodanie dziesięciu razy większej przepustowości do łącza, które nigdy się nie wysyca, nie zmienia zupełnie niczego.

Przenieś pracę, nie bajty

Zmień miejsce wykonywania pracy zamiast płacić za szerszą rurę. Udostępniaj repozytorium zamiast je montować i kopiuj masowo narzędziem, które wysyła tylko różnice.

rsync -av --info=progress2 ./project/ [email protected]:/srv/share/project/

Udostępnianie repozytorium, tak jak robi to hgweb lub zdalny Git, pozwala klientowi pracować na lokalnym klonie, więc jego wywołania systemu plików nigdy nie przechodzą przez tunel. rsync przechodzi obie strony i wysyła zmienione bloki, eliminując większość wymian, za które płaci naiwna kopia. Baza danych na pulpicie należy do silnika po stronie serwera, a klient sprowadza się do interfejsu, albo cały klient działa na wewnętrznym hoście. Każda opcja zmienia to, na ile opóźnień protokół jest narażony, i o to chodzi.

Zawieszanie przy tym samym rozmiarze to objaw MTU

Duże transfery, które zatrzymują się po mniej więcej tej samej ilości danych, gdy ping i małe strony działają, wskazują na rozmiar pakietu, a nie na przepustowość.

ping -M do -s 1400 -c 3 fileserver.example.net

Skuteczny test oznacza, że pakiet IP o rozmiarze 1428 bajtów przechodzi ścieżkę bez fragmentacji, bo nagłówki ICMP i IP dodają 28 bajtów. Niepowodzenie z flagą zakazu fragmentacji sugeruje, że użyteczne MTU tunelu jest mniejsze, niż zakłada serwer. Serwer wysyłający bufory o rozmiarze 9000 bajtów na ścieżkę o rozmiarze 1500 bajtów wymusza fragmentację lub odrzucenie, a wykrywanie MTU ścieżki może cicho zawieść, gdy ICMP jest filtrowany. Obniż MTU tunelu, włącz mssfix w OpenVPN albo zmniejsz bufory serwera, a potem powtórz ten sam transfer, aby potwierdzić.

Zmierz lukę, która ma znaczenie

Wykonaj tę samą operację trzema sposobami tam, gdzie pozwala polityka: lokalnie, przez tunel i bezpośrednią ścieżką internetową. Dla każdego zanotuj czas rundy, szybkość jednego dużego strumienia i to, ile zajmuje lista katalogu lub otwarcie aplikacji. Porównanie przebiegu lokalnego z przebiegiem przez tunel pokazuje, który koszt dominuje. Kopia, która kończy się powoli, sugeruje problem szybkości lub opóźnienia, a kopia, która umiera w stałym punkcie, sugeruje rozmiar pakietu lub urządzenie stanowe na ścieżce.

Gdy wloką się tylko pierwsze megabajty, patrz na uwierzytelnianie i metadane; gdy wszystko się wlecze, patrz na przepustowość i straty. Napraw pasującą przyczynę i przestań oczekiwać, że łącze WAN zachowa się jak kabel sieci lokalnej.