Давным-давно, когда деревья были зелёными, колбаса вкусной, а компьютеры занимали целые помещения, а тот и здания, для общения с этими «динозаврами» люди использовали терминалы – телевизор с клавиатурой ничего сам по себе не умеющий, предназначенный только для отображения данных с большого компьютера и передающий ему команды пользователя.
Скорость связи такого терминала с центральным компьютером была, по нынешним меркам, смехотворной и измерялась килобитами. Соответственно ничего интереснее буковок и циферок на таком терминале отображать не получалось. Точнее получалось, но плохо. Существовали графические терминалы, но, не смотря, ни на какие ухищрения, медленный канал связи с центральным компьютером делал работу с такими устройствами мучительной.
Шло время, электронные компоненты стремительно «съеживались» и не менее стремительно «умнели». Пришла эпоха ПК. Отсутствие медленного канала связи между компьютером и устройством отображения информации позволило использовать полноценный графический интерфейс.
Вообще говоря, полноцветный графический интерфейс это очень и очень серьезный поток данных. Грубо оценить объем этого потока довольно просто. Берем типичное разрешение экрана – 1366х768 точек. Каждая точка обычно описывается тремя байтами (по байту на каждую RGB компоненту, что совокупно позволяет отображать 16 миллионов цветов). И все это хозяйство обновляется 60 раз в секунду. Итого: 1366*768*3*60 = 188835840 байт или порядка 180 мегабайт в секунду. Для набирающего популярность Full HD (1920x1080) путем тех же расчетов получим число 356 МБ/с. Переведя эти числа из мегабайтов в мегабиты, традиционно используемые для измерения скорости сетевых интерфейсов, получим примерно 1,4 и 2,8 Гб/с соответственно.
Для видеокарт с интерфейсом PCI-E x16, имеющих пропускную способность от 32 до 256 Гб/с это не проблема, а вот сетка, даже гигабитная, на первый взгляд с таким потоком данных не справится. Однако не всё так плохо. Наш расчет, на самом деле, не более чем сферический конь в вакууме. Дело в том, что передавать весь экран, да еще 60 раз в секунду, обычно, нет никакой необходимости. Ситуация когда изменяется весь экран и изменяется очень часто, характерна для игр и видео, в остальных случаях изменения затрагивают только часть изображения и происходят куда реже чем 60 раз в секунду. Не вдаваясь в технические детали, просто констатируем, что для адекватной передачи картинки рабочего стола в режиме реального времени хватает нескольких мегабит в секунду.
Это тоже не мало, однако развивались не только компьютеры, но и средства телекоммуникаций. Сегодня скорости в десятки мегабит доступны не только в рамках локальных сетей и у провайдеров выделенных линий, но и в мобильном сегменте.
В предыдущей заметке мы «изобретали» информационный телепортер, позволяющий безопасно подключаться к домашней/офисной сети из любого места. В простейшем случае это даст нам доступ к общим файлам, избавив от необходимости таскать с собой и синхронизировать информацию.
Однако файл – файлу рознь. Если объем файла – гигабайты, а скорость сети – мегабиты, работу ни быстрой, ни комфортной не назовешь. Чтение гигабайтного файла на 10-ти мегабитном канале, займет никак не менее четверти часа. Еще столько же понадобится для записи, если мы внесем какие-либо изменения. Кроме того, для доступа к файлу, обычно нужны программы, а они не всегда под рукой. Кроме того, живем мы не в «сферическом вакууме», а в реальном мире. Канал связи, в особенности мобильный, может и «порваться» в самый неподходящий момент.
Посему, правильнее, проще и безопаснее подключится к собственному рабочему столу на собственном домашнем/офисном ПК.
Такого рода подключения доступны на всех популярных платформах. Для Windows это RDP, для Linux – VNC, для Mac OS X ARD.
Однако сегодня мы ограничимся технологией Remote Desktop Protocol, встроенной в ОС Windows. К слову,RDP доступен и для некоторых Linux систем, правда не «из коробки» и не без определенных проблем.
Вообще RDP под Linux – тема для отдельной заметки, но если этот путь кому-то интересен вот вам компоненты для проверенного, работающего решения: Debian + LXDE (есть готовые сборки 32 или 64 bit) +X11RDP-o-Matic от Scarygliders.
Ну а в Windows (XP/Vista/7/8) всё очень просто, хотя слегка по-разному. :-)
Для начала жмем [Win]+[Pause/Break].
Откроется окно «Система»/«Свойства системы».
В Windows Vista/7/8 жмем на «Дополнительные параметры системы» (в Windows XP никуда не жмем, мы уже и так там где надо)
Далее переходим на вкладку «Удаленный доступ»/«Удаленное использование»/«Удаленные сеансы»
Разрешаем подключение к рабочему столу и выбираем пользователей, которым можно подключаться.
Здесь стоит иметь ввиду: настройку встроенного FireWall, Windows сделает самостоятельно, а вот если на компьютере есть сторонние антивирусы/сетевые экраны, то настроить их придется вам. Суть настройки – разрешить входящие подключения на порт 3389 (стандартный порт RDP).
Подключится к удаленному рабочему столу тоже проще простого. В состав Windows входит программа «mstsc.exe» (MicroSoft Terminal Services Client). В меню она называется «Подключение к удаленному рабочему столу».
Для настройки подключения нужно знать IP адрес компьютера, к которому вы намерены подключиться, имя пользователя и пароль. Кроме удаленного экрана программа позволяет перенаправить звук, буфер обмена, использовать в удаленном сеансе локальные принтеры и диски.
Кроме «родного» RDP клиента, существуют и альтернативные. К примеру кроссплатформенный (Windows, Linux, Mac OS X, iOS, Android, Chrome, Windows CE и Windows Phone) клиент 2X RDP. Интересен он тем что умеет структурно организовать множество RDP подключений и масштабировать окно удаленного рабочего стола.
Кроме того «в ассортименте» 2X.COM есть 2XOS – легкая операционная система на базе Linux для установки или сетевой загрузки на тонкие клиенты. Вещь исключительно полезная для изготовления из устаревших компьютеров вполне дееспособных RDP клиентов (пусть и не слишком тонких, в смысле габаритов).
Еще один серьезный довод в пользу RDP – не критичность к потере связи. При разрыве связи сеанс пользователя продолжает выполняться. Вторично (после восстановления связи) подключившись к удаленному рабочему столу, вы увидите ровно то на чем остановились, не потеряв ни бита информации.
Ну а теперь, по традиции, добавим в эту бочку мёда несколько ложечек дёгтя. :-)
Во-первых, RDP подключение очень неважно подходит для динамических игр и просмотра видео. Впрочем, это должно быть, очевидно, из вступительной части заметки.
Во-вторых, Microsoft, в своих настольных системах, разрешает одновременно работать только одному пользователю. Т.е. если вы удаленно подключитесь к компьютеру, за которым кто-то работает, это приведет к блокировке экрана.
На самом деле настольная Windows может работать как сервер терминалов хоть с двумя, хоть с десятью пользователями одновременно. Железо современных ПК тоже не слишком «переутомится» от такой нагрузки. Ограничения на количество одновременных подключений введены намеренно, и технически снять их достаточно просто. Все что для этого требуется – поправить два десятка байт в одном единственном файле. Существует утилита Universal Termsrv.dll Patch выполняющая эту задачу и снимающая ограничение на количество одновременных подключений рабочему столу, но, как следствие, нарушающая лицензионное соглашение.
У Microsoft конечно же есть решения позволяющие разворачивать «взрослые» терминальные сервера на много-много «койко-мест». Это и универсальный Windows Server 2012 и специализированный Windows MultiPoint Server 2011. Но и бюджет у этих решений тоже «взрослый».