Jak lepiej kopiować i wklejać duże pliki przez RDP?

Ostatnio podejmowałem kilka prób kopiowania i wklejania dużego (1,2 GB) pliku na zdalny komputer przez RDP. Komputer zdalny jest wirtualną maszyną testującą z centrum danych MS Windows Server 2008.

Najpierw próbowałem skopiować i wkleić przed północą, kiedy szybkość transferu była ograniczona przez komputer kliencki ISP do 100 kB / s. Tak więc zajęło to kilka godzin i byłem zmuszony anulować przesyłanie, ponieważ pulpit zdalny przestał reagować i działał zbyt wolno (powoli). Ponownie uruchomiłem go o północy, kiedy moja prędkość lokalnego transferu przekracza 4 MB / s.

Mam więc wrażenie, że niezależnie od szybkości (szerokopasmowego) transferu i kopiowania, zdalny komputer staje się powolny podczas kopiowania przez RDP. Jednocześnie pobieranie z Internetu nie powoduje spowolnienia zdalnego hosta.

AFAIU, to dlatego, że schowek komputera zdalnego, a więc jego pamięć zostaje przeciążona przez transfer.
Jak mogę kontrolować (ograniczyć) wykorzystanie schowka do określonego procesu (wklejanie pliku)?

Jaki jest możliwy sposób, aby to kontrolować?

Aktualizacja:
Po przeczytaniu tej małej prędkości transferu jest spowodowane szyfrowania wykorzystywane do kopiowania i wklejania przez RDP a ponieważ wierzę, jestem bardziej zainteresowany w ogólnej wydajności: zarówno czas, lub rapidness, uzyskania pliku, a także możliwość pracy bez czekania, ja zmieniłem tytuł pytania z:

• Jak kontrolować użycie schowka zdalnego pulpitu do wklejania dużego pliku?

do

• Jak lepiej kopiować i wklejać duże pliki przez RDP?

Na przykład, czy lepiej skopiować i wkleić jedno ogromne archiwum (zip), czy rozpakować i skopiować folder z rozpakowanymi plikami?

A dokładniej chciałem zapytać:

• Jakie są możliwe sposoby poprawy ogólnego doświadczenia:

  • prędkość transferu (tj. dostępność potrzebnego pliku)
  • responsywność zdalnego hosta (udostępnienie zdalnego komputera do pracy przed zakończeniem kopiowania i wklejania)?

Mówiąc plik Zip, masz na myśli nieskompresowane archiwum o takim samym rozmiarze jak wszystkie pojedyncze pliki? Czy masz na myśli skompresowane archiwum? Ponieważ właśnie tam, jeśli mówisz o skompresowanym archiwum, miałbyś szybszy transfer, co ściślej byłoby lepsze. Oczywiście, jeśli weźmiesz pod uwagę czas potrzebny na utworzenie archiwum i czas potrzebny na jego wyodrębnienie, wówczas specyfikacje obu komputerów wchodzą w grę, czy archiwum jest lepsze niż luźne pliki.

Teraz, gdy mówisz o RDP (w przeciwieństwie do VNC), wykorzystanie przepustowości połączenia zdalnego jest dość duże. RDP jest bardziej responsywny niż VNC, głębia kolorów to (domyślnie) ponad 256 kolorów (32 bity, jeśli go nie zmienisz), rozmiar ekranu będzie równy rozmiarowi pulpitu itp. Wszystkie te czynniki wpływa na to, ile przepustowości jest wykorzystywane tylko do połączenia zdalnego. Jeśli upuścisz rzeczy takie jak ... rozmiar pulpitu zdalnego i głębia kolorów do 16 bitów lub mniej, upewnij się, że nie udostępniasz dźwięku itp. ... spowoduje to zmniejszenie przepustowości połączenia zdalnego, dzięki czemu podczas przesyłania plików sesja zdalna powinna być bardziej responsywna.

Ostatecznie jednak, o ile nie zdołasz ograniczyć przepustowości transferu plików, sesja zdalna stanie się powolna, bez względu na to, co robisz podczas przesyłania plików, ponieważ do transferu między jak największą ilością dostępnego pasma zostanie wykorzystane zdalne urządzenie i twoje urządzenie.

EDYTOWAĆ

Próbujesz znaleźć prosty sposób przesyłania plików BEZ wpływu na jakość połączenia zdalnego. Nie ma znaczenia, czy są to duże pliki, czy małe pliki. Na swoim końcu (komputer kliencki) wyrzucasz małe ilości danych do komputera zdalnego (serwera). Wiesz ... pisanie na klawiaturze, polecenia myszy itp. Serwer cały czas wysyła do Ciebie duże ilości danych w postaci obrazów, które składają się na to, co widzisz przez połączenie zdalne. Tak więc przed przesłaniem jakichkolwiek plików JUŻ PRZESYŁASZ dużą ilość danych w jednym kierunku. Dlatego przywołałem rzeczy, które możesz zrobić, aby zmniejszyć ilość przesyłanych danych .... mianowicie użyć mniejszej rozdzielczości dla zdalnego komputera na pulpicie (w przeciwieństwie do pełnego ekranu) .... zmniejszenie liczby kolorów z 32 do 16 bitów lub nawet 8 bitów. Te dwa kroki bezpośrednio tam upuszczają ilość danych, które przesyłasz z serwera (zdalnego) do klienta (ciebie). Oznacza to również, że po rozpoczęciu przesyłania plików tym samym połączeniem i trasą połączenie zdalne będzie mniej obciążone.

Jak powiedziałem ... nic, co możesz zrobić, sprawi, że połączenie pozostanie czyste i responsywne. Czemu? Ponieważ jak tylko zaczniesz przesyłać pliki z serwera do klienta, będzie to pochłaniać każdą część przepustowości dostępną wzdłuż tego potoku .... i już wykorzystujesz część przepustowości wzdłuż tego potoku dla zdalnego samo połączenie.

Najpierw próbowałem skopiować i wkleić przed północą, kiedy szybkość transferu była ograniczona przez komputer kliencki ISP do 100 kB / s. Tak więc zajęło to kilka godzin i byłem zmuszony anulować przesyłanie, ponieważ pulpit zdalny przestał reagować i działał zbyt wolno (powoli). Ponownie uruchomiłem go o północy, kiedy moja prędkość lokalnego transferu przekracza 4 GB / s

Więc kiedy po raz pierwszy próbowałeś przesłać, miałeś połączenie pobierania 100kb / s. Przenosiłeś 1,2 gb plików tak szybko, jak to możliwe, co zepchnęłoby do zjedzenia tak dużej ilości 100 kb / s, jak to możliwe. Co zostawić , co pokój dla danych wspierających połączenia zdalnego pulpitu? Oczywiście byłoby to powolne i nie reagowało. Jedyną rzeczą, której również nie bierzesz pod uwagę, jest prędkość UPLOAD serwera. Jeśli prędkość wysyłania serwera jest mniejsza niż prędkość pobierania ... i w tej idealnej hipotetycznej drodze między serwerem a pozwoliłeś, aby ta prędkość wysyłania pozostała stała, gdy tylko zaczniesz przesyłać pliki, prawie wszystko tej przepustowości zostanie pochłonięte przez przesyłanie plików, co spowoduje pogorszenie połączenia zdalnego.

Czemu?

Ponieważ nic nie ogranicza transferu plików do określonej prędkości lub wartości procentowej dostępnej przepustowości, spróbuje użyć każdego możliwego kb / s. Z natury rzeczy spowoduje to zdalne połączenie.

Nawet przeniesienie plików z serwera na stronę trzecią (np. Gdzieś na serwerze FTP) spowodowałoby spowolnienie połączenia podczas tego transferu, ponieważ ponownie, tak duża część dostępnej przepustowości, jak to możliwe, zostałaby przydzielona do tego transferu. Jednak po zakończeniu transferu będzie można pobrać go z serwera FTP bez wpływu na czas reakcji połączenia zdalnego ... ponownie, ponieważ potok przychodzący po północy jest znacznie większy niż potok wychodzący serwera.

Dlatego spróbuję obniżyć jakość połączenia zdalnego.

Istnieje opcja RDP, która tworzy łącze do dysku lokalnego na komputerze zdalnym. Aby go włączyć, uruchom klienta RDP, kliknij (Pokaż) Opcje , → otwórz kartę „ Zasoby lokalne ”. → kliknij „ Więcej ” → zaznacz pole wyboru „ Napędy ”.

Po połączeniu otwórz Eksploratora Windows na zdalnym systemie. Twój dysk lokalny powinien pojawić się na dole listy dysków w Moim komputerze. Pojawia się jako „C na twojej_nazwie_komputera”.

Możesz teraz przeciągać i upuszczać pliki z jednego systemu do drugiego.

Używam robocopy na moim oknie z Windows 7, używając nazwy unc \\ tsclient.

Jak zasugerował w swojej odpowiedzi @Tom, lepiej jest D & D pliki zamiast C & Ping je. Ma to tę dodatkową zaletę, że obchodzi błąd, który przerywa przesyłanie pliku, jeśli używasz go Ctrl+Cna komputerze klienckim.

Myślę, że żadna z tych odpowiedzi tak naprawdę nie odpowiada na pytanie.

Microsoft RDP to protokół, który nie jest zbyt dobrze zoptymalizowany do przesyłania plików. Jeśli twoje połączenie jest trochę wolne, przesuwanie bitów pliku, które przemieszczają się przez ten sam potok sieciowy, co pakiety interfejsu użytkownika, takie jak rysowanie ekranu i ruch myszy, może spowodować przekroczenie limitu czasu jednej z tych rzeczy; a następnie serwer przyjmie, że utraciłeś połączenie i rozłączy cię, przerywając kanały IO. To oczywiście pogarsza problem.

Przede wszystkim należy rozważyć przepływ pracy i sprawdzić, czy istnieje łatwiejszy sposób przenoszenia plików innym kanałem (np. Przez Internet na serwer zamiast ze stacji roboczej), który nie narusza zasad bezpieczeństwa.

Jeśli zdecydujesz, że musisz użyć kanału kopiowania plików RDP, postępuj zgodnie z tymi wytycznymi, które działają całkiem dobrze dla mnie.

• Nie uzyskuj dostępu do dużych plików bezpośrednio ścieżką UNC do klienta. Na przykład, włączenie folderów współdzielonych i dostęp do pliku z \ TSCLIENT \ share. To popycha dużą zawartość pliku na małą rurkę wielokrotnego użytku.
• Zyskasz trochę optymalizacji i stabilności, mapując dysk. Na przykład NET USE X: \ TSCLIENT \ Share zamapuje dysk X: na powyższą lokalizację. Jednak przeciążenie rur sieciowych rozłączy Cię i odłączy także mapowanie dysków.
• Co najważniejsze, podczas uruchamiania klienta RDP wybierz ustawienie przepustowości sieci „Modem” lub „Wolno”. To znacznie lepiej zoptymalizuje przesyłanie plików i kanały dźwiękowe, aby nie mogły zablokować reszty potoku używanego do sterowania interfejsem użytkownika.
• W kliencie zdalnego pulpitu Microsoft OS X to ustawienie jest dziwnie niedostępne. W takim przypadku zainstaluj MacPorts i uruchom sudo port install rdesktop, a następnie możesz połączyć się z rdesktop i ustawieniem -xm (ustaw poziom „doświadczenie” na „modem lub 28,8K”)
• Jeśli zastosujesz się do powyższych zaleceń, będziesz mieć połączenie zoptymalizowane pod kątem stabilności, a wypychanie dużych plików nie rozłączy Cię. Teraz użyj bardziej kontrolowanego sposobu kopiowania plików niż kopiuj / wklej lub przeciągnij i upuść: na przykład spróbuj ** XCOPY X: *. Msi C: \ Install **, aby skopiować elementy pasujące do wzorca nazwy pliku do określonego katalog lokalny (serwer).

Mam nadzieję, że ktoś uzna te sugestie za pomocne. Z pewnością dla mnie działają.

Spójrz na http://www.bittorrent.com/sync/download

Jest to dużo szybsze i nie wymaga otwartej sesji RDP podczas kopiowania.

Nie wymaga również dostępu do ścieżki UNC, jak powyższe sugestie.

Twoje zdrowie

Zacząłem używać usług przesyłania plików opartych na przeglądarce WebRTC do tego typu rzeczy - obecnie korzystam z http://dragshare.com z dobrymi wynikami (wciąż w wersji beta).

Kopiowanie i wklejanie RDP zawsze było dla mnie uciążliwe - jest bardzo wolne, a jeśli masz tysiące plików, robi się nawet wolniej. Ma również limit maksymalnego rozmiaru pliku (o którym nie ostrzega, po prostu nie powiedzie się po próbie jego przekroczenia). WebRTC wydaje się być znacznie szybszy niż wszystko, co RDP kiedykolwiek mi pokazał.