Какова максимальная скорость кабельного соединения?

Этот вопрос, как никакой другой, встречает наибольшее непонимание, вызывая непрекращающиеся споры, подогреваемые гипотетическими заключениями, большей частью неверными.

Теоретическая пропускная способность LPT-порта в ECP режиме составляет 2.5 мегабит в секунду (и эта цифра часто приводится в инструкциях на материнские платы), а COM – 125 (250) килобит. Но практическая скорость передачи данных существенно меньше. Насколько именно она меньше заранее сказать невозможно. Это зависит от скорости процессора, объема оперативной памяти, типа кабеля, выбранного транспортного протокола, степени сжимаемости передаваемых данных и т.д.

Кабельное соединение очень сильно загружает процессор ведомого компьютера, и мощности младших моделей Pentium может попросту не хватить. Для быстрой работы требуется по меньшей мере Pentium-II или Celeron с таковой частотой 300 – 500 мегагерц. Владельцы старших моделей Pentium могут увеличить скорость соединения, установив в свойствах протокола TCP/IP галочки "Использовать программное сжатие данных" и "Использовать сжатие заголовков IP".,

а так же отключив все остальные протоколы: NetBEUI, IPX/SPX. Заметьте, что На "тормозных" же процессорах, установка программного сжатия уменьшает скорость! – поскольку процессор не успевает одновременно сжимать данные параллельно одновременно с их передачей.

С учетом вышесказанного прямое кабельное соединение через стандартный последовательный порт обеспечит скорость порядка двадцати – двадцати пяти килобит в секунду, а если контроллеры COM-портов обеих машин выполнены на базе микросхемы 16550A (или совместимой с ней), скорость передачи возрастет до ста и более килобит в секунду. Однако в Windows 9x скорость последовательного порта по умолчанию составляет всего лишь 19.200 бит в секунду, а в Windows 2000 и того меньше – 9.600! Чтобы ее увеличить вызовите диалог свойств последовательного порта "Панель управления" à

"Система" à

"Оборудование" à

"Диспетчер устройств" à

"Порты LPT и COM" и в поле "Скорость" установите максимальное значение.

Прямое соединение через параллельный ECP-порт посредством кабеля типа "LapLink" обеспечивает скорость передачи данных до 0.5 мегабит в секунду, а приема вдвое меньше – в пределах 0.3 – 0.35 мегабит в секунду.

Продвинутые кабели типа "DirectParallel® Universal Fast Cable" со встроенными чипами задействуют оба фронта волны, за счет чего ухитряются передавать до 6 мегабит каждую секунду, и принимать за это же время от 3 мегабит и выше! То есть, они в два с лишним раза превосходят теоретическую скорость, практически сравниваясь в производительности с 10 мегабитными сетевыми картами!



Рисунок 22 Рис 0x00A Внешний вид кабеля DirectParallel® Universal Fast Cable

Каково назначение ключей tracert?

Чаще всего утилита tracert вызывается без ключей, с одним лишь указанием IP-адреса или доменного имени трассируемого узла, но в некоторых случаях этого оказывается недостаточно и приходится прибегать к дополнительным ухищрениям.

Ключ –d запрещает определение доменных имен промежуточных узлов. Это несколько ускоряет трассировку и порою бывает полезно. Тем более что имена узлов в любое время можно определить и самостоятельно по их IP-адресам с помощью утилиты nslookup.

Ключ –h задает максимальное количество трассируемых узлов (по умолчанию 30), – это предотвращает возможные зацикливания, что полезно при автономном пакетном запуске. При интерактивной же работе с программой ее всегда можно прервать нажатием <Ctrl-Break>. В некоторых, очень экзотических случаях, тридцати переходов для достижения узла назначения не хватает и их количество приходится увеличивать, например, так: "tracert www.overfar.ch -h 121".

Ключ –w задает предельный интервал ожидания отклика от каждого узла в миллисекундах. Если ответ от узла не будет получен в течение указанного времени, в соответствующей колонке интервала задержки появится "звездочка", а потеря всех трех дейтаграмм кряду вызовет "ругательство" "Превышен интервал ожидания для запроса". В таком случае следует воспользоваться ключом -w и увеличить интервал ожидания до нескольких секунд, например, до десяти: "tracert www.overlazy.fu -w 10000". Стоит отметить – увеличение времени ожидания не помогает, если маршрутизатор не посылает уведомлений или их уничтожает межсетевой экран (см. "Почему трассировка умирает на полпути к серверу назначения").

Ключ –j задает список узлов для свободной маршрутизации от клиента. "Свобода" маршрутизации подразумевает, что дейтаграмма посетит все перечисленные узлы в указанном порядке, но соседние в списке узлы могут воспользоваться для передачи дейтаграммы услугами любых других промежуточных узлов. Эта возможность бывает полезна если между клиентом и сервером существует неединственный маршрут и пользователь хочет принудительно направить пакеты по выбранному им пути. На выбор пути наложено множество ограничений, в частности, промежуточные маршрутизаторы могут отказаться пересылать пакет по насильно навязанному адресу, особенно если этот узел вне пределов видимости данного маршрутизатора. Например:

C:\>tracert -j 195.161.42.222 {>>>> сноска IP-адрес узла freeproxy.com} www.aha.ru

Трассировка маршрута к www.aha.ru [195.2.70.38] с максимальным числом прыжков 30:

  1   901 ms   861 ms   952 ms  cisco03-s0.krintel.ru [195.161.42.210]

  2  1061 ms  1042 ms  1442 ms  ns.krintel.ru [195.161.42.222]

  3     *        *        *     Превышен интервал ожидания для запроса.

  4     *        *        *     Превышен интервал ожидания для запроса.

Трассировка быстро "умирает", поскольку, узел ns.krintel.ru не может сообразить как ему передать пакет на freeproxy.com, и уничтожает его от безысходности. Поэтому, использование ключа –j – прерогатива администраторов и высококвалифицированных пользователей.

Родственные вопросы:

Почему трассировка умирает на полпути к серверу назначения

Каково назначение ключей утилиты ping?

Несмотря на свою простоту, утилита ping из штатной поставки Windows, принимает достаточно большое количество ключей командной строки, более чем поверхностно описанных в прилагаемой документации. Неудивительно, что многие возможности ping ускользают не только от начинающих, но и умудренных жизнью пользователей!

Ключ –w используется для задания интервала ожидания эхо – ответа в миллисекундах (по умолчанию 20 секунд). Если отклик от сервера не будет получен в течение указанного времени, утилита ping сообщит "Превышен интервал ожидания для запроса", намекая на неработоспособность сервера или повреждение сети. На загруженных каналах медленных провайдеров ответ может прийти и через 30, и даже через 60 секунд, поэтому, интервал ожидания приходится увеличивать, например, так:

C:\>ping www.nastyhost.fu

Обмен пакетами с www.nastyhost.fu [195.2.70.38] по 32 байт:

Превышен интервал ожидания для запроса.

Превышен интервал ожидания для запроса.

Превышен интервал ожидания для запроса.

Превышен интервал ожидания для запроса.

Статистика Ping для 195.2.70.38:

    Пакетов: отправлено = 4, получено = 0, потеряно = 4 (100% потерь),

Приблизительное время передачи и приема:

    наименьшее = 0мс, наибольшее =  0мс, среднее =  0мс

C:\>ping www.nastyhost.fu  -w 60000

Обмен пакетами с www.nastyhost.fu [195.2.70.38] по 32 байт:

Ответ от 195.2.70.38: число байт=32 время=34100мс TTL=117

Ответ от 195.2.70.38: число байт=32 время=38310мс TTL=117

Ответ от 195.2.70.38: число байт=32 время=39001мс TTL=117

Ответ от 195.2.70.38: число байт=32 время=10220мс TTL=117

Статистика Ping для 195.2.70.38:

    Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь),

Приблизительное время передачи и приема:

    наименьшее = 10220мс, наибольшее =  39001мс, среднее =  30408мс

Ключ –n задает количество отправляемых эхо – запросов (по умолчанию 4). Увеличение количества запросов бывает необходимо для контроля надежности и устойчивости работы сервера. Чем выше качество канала, тем меньше разброс по времени ответов.

Ключ –t заставляет утилиту ping посылать запросы в бесконечном цикле до ее прерывания нажатием комбинации клавиш <Ctrl-C>. Внимание: <Ctrl-Break> не прерывает процесс, а выводит текущую статистику! Этот ключ очень удобен для ожидания момента пробуждения некстати зависшего сервера – запустил "ping www.hover-server.fu -t"  и жди появления сообщения "Host Alive" или что-то в этом роде.

Ключ –l задает размер дейтаграммы без учета длины заголовка (28 байт), посылаемой в эхо – запросе. Допустимыми являются значения от 0 до 65.500 включительно. По умолчанию размер дейтаграммы составляет 32 байта. Манипулируя этим значением можно выяснить зависимость скорость доставки – размер дейтаграммы. Если размер дейтаграммы превысит некоторую критическую величину (определяемую каждым промежуточным узлом самостоятельно), дейтаграмма разрезается на несколько пакетов подходящего размера, каждый из которых добирается до конечной точки маршрута самостоятельно, а на узле назначения они вновь собираются в исходную дейтаграмму.

Ключ –f устанавливает на дейтаграмме специальную пометку, запрещающую ее разрезание (то есть, говоря техническим языком, фрагментацию). Если хотя бы один из промежуточных узлов не может обрабатывать пакеты таких размеров, он прибивает дейтаграмму и посылает отправителю уведомление, объясняя причину смерти тем, что требуется фрагментация, но установлена пометка, ее запрещающая. Впрочем, некоторые узлы не посылают такого уведомления, молчаливо отправляя пакет на тот свет или же разрезают дейтаграмму вопреки запрету (впрочем, последнее встречается редко). Вкупе с ключом –l, задающим длину дейтаграммы, запрет фрагментации ключом –f, позволяет определить максимальный размер не фрагментируемых пакетов. (см. "Оптимизация соединения с Интернет" и "Описание утилиты MTUSpeed").

Ключ –i задает время жизни (сокращенно TTL – Time To Live) пакета посылаемых дейтаграмм, измеряемое количеством узлов, которые может посетить пакет (по умолчанию 128). Каждый промежуточный узел уменьшает значение TTL на единицу и когда оно достигает нуля, пакет уничтожается с посылкой отправителю соответствующего уведомления. Это обстоятельство позволяет отслеживать маршрут путешествия пакетов, используя ping вместо утилиты tracert, что будет нелишним в тех ситуациях, когда tracert нет под рукой. (см. "Как определить полный путь (прохождение) при скачивании файла").



Для контроля выясним маршрут к некоторому узлу с помощью tracert, входящей в штатную поставку Windows:

Трассировка маршрута к aport.ru [194.67.18.8]

с максимальным числом прыжков 30:

C:\>tracert www.aport.ru

  1   150 ms   130 ms   131 ms  nas.itech.ru [195.151.210.36]

  2   140 ms   141 ms   150 ms  ns.itech.ru [195.151.210.33]

  3   221 ms   180 ms   220 ms  gw.itech.ru [195.151.210.29]

  4   310 ms   401 ms   330 ms  195.151.200.90

  5   300 ms   341 ms   270 ms  krd-gw.mtt.ru [195.151.52.41]

А теперь вызовем ping, задав значение TTL равное одному. Первый же маршрутизатор, уменьшив его на единицу, обнаружит, что оно равно нулю и пошлет нам соответствующее уведомление. Итак…

C:\>ping www.aport.ru -i 1

Обмен пакетами с aport.ru [194.67.18.8] по 32 байт:

Ответ от 195.151.210.36: Превышен срок жизни (TTL) при передаче пакета.

И в самом деле, получен ответ от узла 195.151.210.36 – первого маршрутизатора в цепочке, как это видно по протоколу работы tracert.

Теперь увеличим значение TTL до двух и повторим процедуру:

C:\>ping www.aport.ru -i 2

Обмен пакетами с aport.ru [194.67.18.8] по 32 байт:

Ответ от 195.151.210.33: Превышен срок жизни (TTL) при передаче пакета.

Действительно, теперь найдет второй маршрутизатор в цепочке! Увеличиваем значение TTL еще на единицу…

C:\>ping www.aport.ru -i 3

Обмен пакетами с aport.ru [194.67.18.8] по 32 байт:

Ответ от 195.151.210.29: Превышен срок жизни (TTL) при передаче пакета.

В самом деле, этот прием работает! Правда, уж очень утомительно перебирать пакеты вручную. Но работу легко оптимизировать командным файлом следующего содержания {>>>> сноска Работает только под Windows 2000 или выше} FOR /L (%%I) IN (1,1,30) DO ping %1 -i %%I, вызываемого с аргументом – доменным именем или IP-адресом трассируемого узла, и он самостоятельно начнет перебирать все значения TTL от 1 до 30.

Ключ –v задает значения поля типа службы (TOS - Type Of Service). Тип сервиса с помощью некоторых абстрактных параметров указывает предпочтительный вид обслуживания – минимальная задержка, максимальная пропускная способность, максимальная надежность, минимальные издержки на пересылку или обычная, неприоритетная, пересылка. Предпочтение может быть отдано только одному типу приоритета – нельзя одновременно требовать молниеносной скорости пересылки пакета в купе с соломоновой надежностью его доставки. Выбирайте уж что-то одно!



Тип сервиса задается одним из следующих десятичных чисел (См. таблицу 3). Как легко видеть, каждому значению соответствует свой бит:

Код сервиса	Пояснение
2	минимальные издержки на пересылку
4	максимальная надежность доставки
8	максимальная пропускная способность
16	минимальная задержка

Таблица 3. Допустимые типы сервиса в поле TOS

Не все маршрутизаторы анализируют поле TOS, - многие из них его напрочь игнорируют, что и подтверждает следующий эксперимент.

C:\>ping www.itech.ru -v 0x2

Обмен пакетами с ns1.itech.ru [195.151.210.34] по 32 байт:

Ответ от 195.151.210.34: число байт=32 время=130мс TTL=254

C:\>ping www.itech.ru -v 0x4 -n 1

Обмен пакетами с ns1.itech.ru [195.151.210.34] по 32 байт:

Ответ от 195.151.210.34: число байт=32 время=130мс TTL=254

C:\>ping www.itech.ru -v 0x8 -n 1

Обмен пакетами с ns1.itech.ru [195.151.210.34] по 32 байт:

Ответ от 195.151.210.34: число байт=32 время=130мс TTL=254

C:\>ping www.itech.ru -v 16

Обмен пакетами с ns1.itech.ru [195.151.210.34] по 32 байт:

Ответ от 195.151.210.34: число байт=32 время=130мс TTL=254

Независимо от типа сервиса время отклика всегда составляло ровно 130 мс, и быстроты пересылки при TOS равном 16 не наблюдалось. А вот пример сети, поддерживающей TOS.

C:\>ping www.krintel.ru -v 2

Обмен пакетами с www.krintel.ru [195.161.42.218] по 32 байт:

Ответ от 195.161.42.218: число байт=32 время=2143мс TTL=127

C:\>ping www.krintel.ru -w 10000 -v 4

Обмен пакетами с www.krintel.ru [195.161.42.218] по 32 байт:

Ответ от 195.161.42.218: число байт=32 время=1763мс TTL=127

C:\>ping www.krintel.ru  -v 8

Обмен пакетами с www.krintel.ru [195.161.42.218] по 32 байт:

Превышен интервал ожидания для запроса.

Ответ от 195.161.42.218: число байт=32 время=1332мс TTL=127

C:\>ping www.krintel.ru -v 16

Обмен пакетами с www.krintel.ru [195.161.42.218] по 32 байт:



Ответ от 195.161.42.218: число байт=32 время=1092мс TTL=127

Наибольшая задержка наблюдалась при TOS равном 2 (минимальные издержки на пересылку), а наименьшая – при TOS равным 16 (минимальная задержка), и чуть менее быстрой оказались посылки с TOS равным 8.

Какую пользу из этого можно извлечь? А вот какую – прикладные программы могут манипулировать полем TOS по своему усмотрению, выбирая значение, соответствующее специфике своей работы. Например, telnet-клиенты, ICQ и чаты очень чувствительны к задержкам, ftp клиентам задержки не страшны – была бы хорошей пропускная способность, и т.д. Разумеется, если промежуточные узлы игнорируют содержимое поля TOS, никакого выигрыша не получается и высокоприоритетные пакеты (например, от ICQ) обрабатываются с той же скоростью, что и пакеты, скажем, от почтового сервера, не критичные к скорости доставки. Использование ping с ключом –v позволяет выяснить поддерживается ли TOS на данном маршруте и если имеется несколько альтернативных маршрутов – выбрать из них наиболее подходящий {>>>>> сноска К слову сказать, далеко не все приложения устанавливают поле TOS в соответствующее значение, оставляя его по умолчанию}

Ключ –r заставляет промежуточные узлы записывать в заголовок отправляемых эхо – запросов свои IP-адреса (см. "Можно ли обойти защиту от трассировки?"). Не все маршртузаторы поддерживают такую возможность, но очень многие. Ping, вызванная с ключом –r, позволяет отслеживать маршрут пересылки пакетов и могла бы полностью заменить собой утилиту tracert (см. "Как определить полный путь (прохождение) при скачивании файла") если бы не ограничения, налагаемые размером IP-заголовка на максимальное количество запоминаемых адресов, – их умещается всего девять, и более длинные пути отслеживать этим способом невозможно.

Ключ –s похож на ключ –r, но заставляет промежуточные узлы вносить в заголовок не свои адреса, а временную метку (или "штамп времени" в плохом русском переходе). По общепринятым соглашениям временная метка представляет собой четырехбайтовое поле, содержащее число миллисекунд, истекших с начала полуночи всеобщего скоординированного времени, однако, на практике это соглашение мало кто соблюдает и многие маршрутизаторы заполняют это поле всякой отсебятиной, интерпретируемой только одним им известным способом.



На количество запоминаемых временных меток наложены те же самые ограничения, что и на количество запоминаемых IP-адресов, за одним небольшим исключением – временная метка, вставленная неизвестно каким маршрутизатором, бесполезна (разве что маршрут путешествия пакетов заведомо не меняется с течением времени и может быть предварительно выявлен трассировкой). По умолчанию утилита ping автоматически запоминает IP-адреса узлов при записи временных меток – таких пар в заголовок пакета может вместиться только четыре.

Временная метка выгодно отличается тем, что позволяет вычислять точную скорость пересылки пакета, поскольку содержит в себе не общий интервал задержки (от пересылки в оба конца), а время пересылки на заданный узел. По непонятным причинам штатная (да и большинство остальных) реализация утилиты ping не позволяет задавать запись временной метки для произвольного узла в цепочке (хотя, в принципе это возможно), чем полностью обесценивает ключ –s, ну, право же, редкий сервер отделен от клиента менее чем четырьмя промежуточными узлами!

Пример вызова ping с ключом –s приведен ниже. Обратите внимание на временную метку – похоже она представляет собой ни что иное, как случайное число.

C:\>ping www.itech.ru   -s 2

Обмен пакетами с ns1.itech.ru [195.151.210.34] по 32 байт:

Ответ от 195.151.210.34: число байт=32 время=151мс TTL=254

    Штамп времени: 195.151.210.36 : 3658968578 ->

               195.151.210.34 : 2275040770

Ответ от 195.151.210.34: число байт=32 время=140мс TTL=254

    Штамп времени: 195.151.210.36 : 3357240834 ->

               195.151.210.34 : 1956535810

Ответ от 195.151.210.34: число байт=32 время=141мс TTL=254

    Штамп времени: 195.151.210.36 : 3122621954 ->

               195.151.210.34 : 1738694146

Ответ от 195.151.210.34: число байт=32 время=140мс TTL=254

    Штамп времени: 195.151.210.36 : 2888003074 ->

               195.151.210.34 : 1504075266

Статистика Ping для 195.151.210.34:

    Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь),



Приблизительное время передачи и приема:

    наименьшее = 140мс, наибольшее =  151мс, среднее =  143мс

Ключ –j задает список узлов для свободной маршрутизации от клиента и аналогичен одноименному ключу утилиты tracert (см. "Каково назначение ключей tracert?").

Ключ –k похож на ключ –j, но задает список узлов для жесткой маршрутизации, т.е. пакет передается из рук в руки строго по перечню перечисленных узлов и ни один их них не может позволить себе воспользоваться услугами "собственного" маршрутизатора для передачи пакета следующему узлу. Если узел не может передать пакет напрямую, он уничтожает его и посылает отправителю соответствующее уведомление, дескать, такая маршрутизация от источника невозможна. Существует очень мало причин, требующих применения свободной, а тем более жесткой маршрутизации. Все это пережиток старых времен, – современные сети самостоятельно решают проблемы маршрутиазции пакетов и пытаться помочь им, право, не стоит – они и без того справляются со своей задачей слишком хорошо.

Ключ –-a задает определение имен узлов по их IP-адресам. Так, во всяком случае, сказано в документации. Смысл этого неясен – такое определение и без того происходит автоматически независимо от наличия (отсутствия) ключа "-a".

Родственные вопросы:

Провайдер и удаленный доступ à Оптимизация соединения с Интернет

Провайдер и удаленный доступ à Описание утилиты MTUSpeed

Как определить полный путь (прохождение) при скачивании файла

Можно ли обойти защиту от трассировки?

Каково назначение ключей tracert?

Каково назначение полей DUN-файла?

Ниже приведен пример содержимого такого файла с краткими комментариями.

[Entry]

Entry_Name=Соединение               ; название ключа реестра, хранящего имя и пароль пользвателя

; для входа в сеть. см. HKEY_CURRENT_USER\RemoteAccess\Addresses

Import_Name=Соединение             ; название соединения – оно будет отображаться в заголовке

; диалогового окна звонилки

Multilink=no                                         ; многоканальные подключения запрещены

[Phone]

Dial_As_Is=yes                                    ; если "no" то использовать код страны и параметры связи

Phone_Number=56806                      ; номер телефона для дозвона

[Device]

Type=modem                                      ; устройство, использующееся для удаленного доступа

Name=Rockwell 33.6 DPF Ext         ; название модема (как его определила Windows)

Settings_Size=108                               ; количество байт строки установок

Settings=6C000xxxxxx0C                                : установки модема в бинарном виде

[Server]

Type=PPP                                             ; протокол, использующийся для связи с провайдером

SW_Compress=yes                             ; даешь программное сжатие данных!

{В макете книги тут лишний перенос!!! Строка не соответствует комментарию!}

PW_Encrypt=no                                  ; не требуется шифровать пароль

Network_Logon=yes                          ; да, входить в сеть

SW_Encrypt=no                                  ; нет, трафик шифровать не надо

Negotiate_NetBEUI=no                     ; протоколу NetBEUI (связь между системами Windows) – нет!

Negotiate_IPX/SPX=no                     ; протоколу IPX/SPX (Novell Netware) – нет!

Negotiate_TCP/IP=yes                       ; протоколу TCP/IP (Internet Protocol) – да!

[TCP/IP]                                                ; настройки протокола TCP/IP

Specify_IP_Address=no                    ; IP-адреса выдаются сервером, а не назначаются вручную

Specify_Server_Address=no             ; адреса DNS выдаются сервером, а не назначаются вручную

IP_Header_Compress=yes                                ; сжатию заголовков IP-пакетов – да!

Gateway_On_Remote=yes                               ; использовать удаленный шлюз по умолчанию

Клиентские решения

Большинство почтовых клиентов оснащено специальными фильтрами, избавляющими пользователя от нежелательной (с его точки зрения) корреспонденции. В зависимости от гибкости фильтра критерием нежелательности может быть и размер письма (вложения), и адрес отправителя, и его домен, и тема сообщения, и ключевое слово, содержащиеся в его теле, – да все что угодно!

Судьба такого нежеланного сообщения опять-таки зависит от гибкости фильтра и пожеланий пользователя – оно может быть удалено прямо на сервере (актуально для писем неприлично большого размера), помещено в папку "удаленные" или любую другую, назначенную пользователем (актуально для писем от надоедливых собеседников – с одной стороны их послания сохраняются "на всякий пожарный случай", а с другой – не мозолят глаза).

???? Рисунок "карикатура" сидит охотник в засаде и стреляет из двустволки по письмам, летящим в виде уток

Достаточно эффективной мерой против надоедливой рекламы о заработке будет удаление всех сообщений, содержащих в поле "тема" слова "free", "money" и т.д., впрочем, тут самое главное – не переусердствовать! К выбору критерия следует подходить со всей ответственностью и осторожностью: фильтр – оружие слепое, он и полезные сообщения удалит – стоит им случайно попасть под соответствие критерию. Особенно внимательным следует быть при задании шаблона сообщений, автоматически удаляемых с сервера, – ведь в случае ошибки восстановить их уже не удастся. Перемещать нежелательную корреспонденцию в папку "Удаленные" намного безопаснее, но безопасность эта достается дорогой ценой – ведь в этом случае их приходится загружать с сервера, теряя драгоценное (и порой поминутно оплачиваемое) время, и все достоинство фильтра сводится лишь к тому, что нежелательные сообщения не мозолят глаза.

С поиском ключевых слов в теле сообщения связана своя тонкость. Популярный протокол POP3 не поддерживает функции поиска на сервере и эту операцию приходится выполнять на компьютере клиента уже после загрузки сообщения, а загрузка это – время. Поэтому, если возникает такая необходимость, лучше воспользоваться почтовым ящиком, поддерживающим протокол IMAP4, позволяющий искать ключевые слова в сообщении без его загрузки с сервера.

Маленькие секреты издательсткой

Лет десять назад изданием своей книжки было можно гордиться. Типографии тогда были маленькие и медленные, а редакторы ворчливые и строгие, так и норовящие загубить все творчество на корню

.Сейчас же все изменилось, но до сих пор по массовому мнению – издание своей книжки дело не простое, за которое "простому смертному" и браться не стоит. Но, нет, стоит! Стоит  только попробовать, войти во вкус, как потом просто невозможно остановиться!

Весь вопрос в том, как начать? И стоит ли начинать вообще? Где же взять "руководство начинающего писателя", чтобы сделать первые шаги? К сожалению, ничего подобного на рынке не наблюдается. Да и в личном общении далеко не каждый автор с готовностью поделится своим опытом. Действительно, зачем ему лишняя конкуренция?

Кстати, на счет конкуренции. Россыпи книг на лотках часто отпугивают молодых писателей от мысли издать что-то свое. Кажется, что все темы, которые только существуют в мире, исчерпаны и вылизаны дочиста, и ничего нового добавить не получится.

На самом деле ситуация вовсе не так безнадежна. Скорее наоборот. Хорошие книги можно пересчитать по пальцам одной руки. Во всяком случае, на рынке технической литературы все обстоит именно так.

Особенно это стало хорошо заметно на фоне бурного развития информационных технологий. Большинство авторов в погоне за скоростью приносят в жертву качество. Практически все изданные за последнее время книги едва ли покрывают технические руководства описываемых программных продуктов и большей частью бесполезны для рядового пользователя.

Откроем любую книгу, посвященную такому популярному продукту, как Microsoft Word. Эдакий "кирпич" под тысячу страниц. Но, увы, часто это просто подробное описание пунктов меню, большая часть из которых никакого описания и вовсе не требует!

Можно ли научиться работать с помощью этой книги? Сомнительно. Ведь техника работы c Word-ом не ограничивается одним лишь умением тискать мышь и клавиатуру. Необходимы навыки и приемы работы. И постигать их придется методом проб и ошибок самому.

Почему же покупаются такие книги? Вероятно, по инерции, да и лучшего все равно ничего нет. А если попробовать самим написать что-нибудь на эту тему? Утолить свой и чужой информационный голод?

И такая ситуация не только с одним Word-ом. Буквально про любое приложение можно сказать то же самое. Особенно в области программирования и разработки приложений. Насыщенность рынка книжной продукцией это только иллюзия. На самом деле новые издания расходятся моментально.

Итак… будем считать, я склонил вас к мысли, что издать собственную книжку вовсе не бредовая идея, и попробовать все же стоит. Но для начала лучше потренироваться на публикациях в периодических изданиях.

Это не только даст некоторые навыки, но и облегчит дальнейшее общение с издателями, которым будет по чему судить о вашем профессионализме.

Но прежде, чем засесть за написание статьи, неплохо бы сначала выбрать журнал, для публикации, и писать в принятом для него стиле. Ведь у каждого журнала свой круг читателей. Это могут быть деловые люди, инженеры, программисты, студенты, подростки. И для каждого из них нужен свой подход. Иначе, прочитав первые несколько строчек, они просто закроют журнал или просто перилистнут пару страниц.

Предположим, журнал выбран. Каковы дальнейшие действия? Находим электронный адрес главного редактора и вежливо просим его сообщить условия публикации. Вообще-то по логике вещей следовало бы обратится к ведущему одного из разделов, близкого по тематике к вашей статье, но… Из личного опыта могу вас заверить, что главный редактор обычно отвечает на порядок быстрее и подробнее.

Из условий публикации в первую очередь необходимо узнать следующие:

-- максимальный допустимый объем публикации (обычно от 10 до 30-40 килобайт

-- стоимость одного килобайта печатного текста (колеблется от 1$ до 15$, обычно 5$-8$)

Правила оформления текста могут сильно разниться от журнала к журналу, но это не настолько критичный фактор, что бы всерьез брать его во внимание. Тем более, что если в вас заинтересованы, то примут даже рукопись на газетной бумаге, - все равно приведение текста в "божеский" вид - задача верстальщика.



Это, кстати, многие упускают из виду и пытаются форматировать текст самостоятельно. Так вот, ни в коем случае этого делать не надо! Этим вы только усложняете жизнь другим людям. Ваше форматирование до верстки все равно не дойдет, поэтому пишите "сплошным" тестом, выделяя лишь заголовки и абзацы.

Таблицы и рисунки настоятельно рекомендуется поставлять в отдельных файлах, а в тексте лишь давать на них ссылку, формат которой либо описать перед текстом, либо спросить у редактора.

Кстати, комментарии и просьбы к редакторам и верстальщикам, беспорядочно разбросанные по тексту - это самое худшее, что может быть в их работе. Строго говоря, верстальщик вообще не читает текст. Он его верстает. И "выкусывать" комментарии для него занятие не из приятных.

Все необходимое пишите в одном месте до или после текста статьи. Но в любом случае не увлекайтесь таким занятием. Верстальщику самому лучше знать, как оформить текст. И не нужно пояснять редактору, что в такой-то строке "карова доет малако" вовсе не опечатка, а ваш тонкий авторский замысел. Просто избегайте таких ситуаций вот и все.

Кстати, часто можно услышать жаркие споры на счет редакторской правки. Насколько она правомерна и так далее. Вообще-то после внесения любых изменений, редактор обязан отправить их автору на утверждение. Но практически это медленно, неудобно и даже бессмысленно. Поэтому часто правка осуществляется "задним числом" и автор порой узнает о ней, только увидев свою публикацию в журнале.

Случается, что редактор урезает статью вдвое, а то и втрое или делает из двух одну. А некоторые позволяют вписывать "отсебятину", которая не только уродует текст, но еще и портит вашу репутацию.

Можно ли этого избежать? Конечно. Просто оговаривайте необходимость предварительного просмотра отредактированного текста. А лучше, – пожелайте такому редактору удачи и отправитесь к другому, благо, что сегодня есть куда.

Действительно, с хорошими редакторами проблем не возникает, тогда как с плохими вы будете больше заняты "разборками", чем работой.



Частый вопрос начинающих, – что делать, если редакторская правка вас не устраивает? Разумеется, отвергнуть ее и вернуться к вашему варианту. Схема тут простоя. Автор этого произведения вы, следовательно, и владелец вы и никто другой. Вы вправе отказать редактору. Правда, редактор вправе в свою очередь отказать вам в публикации, но… тогда можно пойти к другому редактору или попытаться найти компромиссный вариант.

Однако, к словам хорошего редактора практически всегда следует прислушиваться, поскольку его цель улучшить текст, даже если на первый взгляд это не очевидно (из практики автора – бывает, получишь рецензию на свою статью и такое возмущение охватывает: "да что это за редактор такой?! что он себе позволяет?!", а потом, подумав хорошенько, понимаешь – "а ведь он прав!").

От сотрудничества с таким редактором можно только выиграть, и поднять свой профессиональный уровень, что не раз потом поможет в будущем. Теоретически редактор должен присылать нечто вроде рецензии на ваше произведение, но практически ни у кого из них на это не находится времени (редактура, кстати, одна из самых низкооплачиваемых работ в издательском бизнесе). Имеет смысл попросить редактора да дополнительное вознаграждение прислать максимально подробную рецензию, чтобы не совершать в дальнейшем одни и те же ошибки.

Кстати, необходимо уточнить, о каком же мы редакторе говорим. Ведь он не один в издательстве! Обычно этим занято, по крайней мере, два человека – ведущий раздела и главный редактор.

Но вот отношения между ними могут очень сильно разниться от издательства к издательству.

Так, в одном случае, ведущий раздела может и вовсе не иметь ни каких прав, и как бы он не одобрял вашу статью все равно конечное решение остается за главным редактором.

В другом случае, у редакторов разделов "своя вотчина", на которую главный без особой нужды предпочитает не залезать.

Поэтому ориентируйтесь по обстановке с кем вам окажется удобнее сотрудничать. Ищите человека, который реально отвечает за публикацию, и отсылайте все статьи ему. Это сократит много нервов и времени.



Когда статья отредактирована, и редактор дал добро, она помещается в "актив" и через какое-то время может быть опубликована. Весь вопрос – через какое. К сожалению, разброс здесь бывает очень большим. Может быть в ближайшем номере, а может быть и через полгода. Поэтому если хотите публиковаться регулярно, то пишите не одну статью и сотрудничайте не с одним журналом. Только ни в коем случае не посылайте одну и ту же статью в два и более журналов. Случись такое, и с вами, скорее всего, навсегда распрощаются. Впрочем, некоторые, очень немногие, журналы на это смотрят "сквозь пальцы", но все равно повторная публикация чести вам это не добавляет.

Часто после нескольких удачных статей вам могут выделить немного журнального пространства в каждом номере, для постоянных публикаций. А в будущем могут сделать и редактором раздела.

На первое можно соглашаться с удовольствуем, а вот польза от второго очень сомнительна. Быть редактором – это добровольно возлагать на себя ответственность и множество обязанностей часто за смешную плату. Впрочем, для некоторых и этого оказывается достаточно.

Раз уж мы коснулись финансовых вопросов, обсудим заодно и сроки выплат гонораров. Чаще всего выплата происходит спустя какое-то время после выхода тиража из типографии и его распространения. Или же издательство выплачивает деньги за прошлый номер (учитывая, что подавать материалы для публикации приходится заблаговременно, как правило, за месяц, то выходит, что гонорар вряд ли будет выплачен ранее, чем два - три месяца, спустя начала работы над статьей).

Но иногда, в качестве исключения, вам могут выплатить деньги немедленно после подачи материала или даже дать аванс до начала работы над статьей! Разумеется, только в том случае, если в вас будет заинтересованы.

То же относится и к размеру гонораров. Разберемся, откуда вообще получаются объявленные цифры? Все очень просто – на каждый номер главному редактору отпускается некоторая сумма, которой он будет расплачиваться с всеми-всеми авторами (а иногда и редакторами, верстальщиками, – хотя обычно они оплачиваются отдельно).



Выходить за пределы оговоренной суммы редактору крайне не рекомендуется. Однако распределение денег между отдельными авторами – исключительно его забота. Ваш гонорар зависит только от интереса редактора к вашим материалам.

Таким образом, вполне может случиться, что вам заплатят вдвое или даже втрое больше "средней" суммы. Кстати, "средняя сумма" – понятие растяжимое. Если редактор сообщает, что гонорары у них от 3 до 6 долларов за килобайт, то это означает лишь то, что таковы выплаты большинству авторов. То есть, если вдруг все авторы сразу подадут чертовски хорошие статьи, то вовсе не факт, что каждый из них получит по 6$ - бюджета не хватит. Все равно от кого-то придется "отщипнуть".

Впрочем, это только одна из возможных схем. Бывает и так, что бюджет практически не лимитирован или наоборот, главному редактору приказано строго придерживаться тарифной сетки и не допускать большого разброса.

Наконец, выходит журнал с вашей статьей. Что бы была возможность похвастаться этим перед знакомым, писателям принято дарить авторские экземпляры. Обычно столько, сколько у вас хватает наглости попросить. Приблизительно от трех до пяти штук, но бывает и больше. Впрочем, зачем нам больше? Мариновать их что - ли?

И вот тут молодые авторы с нетерпением ждут отзывов в свой адрес. Увы, часто (даже почти всегда) им отвечает гробовое молчание или резкие, ругательные оскорбления в их адрес. К этому придется привыкнуть как к неизбежному злу.

И чем больше вы будете публиковаться, тем больше у читателей будет желание видеть вас таким, каким они хотят вас видеть, а не таким, какой вы на самом деле есть. И это нормально. Так устроен мир. Читатель всегда хочет "перетянуть одеяло на себя". Но пусть не будет это поводом к действию. Оставайтесь самим собой. У каждого автора есть своя читательская аудитория, – а всем угодить просто невозможно. А идти на поводу отдельно взятых читателей – дурная привычка, которая до добра еще никого не доводила.

Кстати, наивно думать, что даже интенсивные публикации могут существенно помочь в поисках хорошей работы. Вероятность этого достаточно низка, хотя спустя какое-то время, если ваше имя будет постоянно мелькать в десятках популярных изданий, то работодатель может придти к вам сам (разумеется, если статьи будут соответствующего уровня)



Впрочем, о работе. Можно ли заработать себе на жизнь написанием статей? Написание статьи в 30 килобайт у разных людей занимает от вечера до недели. И, во всяком случае, любой способен написать пару статей в месяц. Исходя их среднего гонорара в 6$ получается что-то между трехсот и четырехсот долларов в месяц. А что? Средняя зарплата по Москве приблизительно такая же.

Однако статьи (особенно технические) сами по себе из воздуха не возникают. Чтобы их писать, нужно интенсивно работать и быть в курсе последних событий и технологий. И вот тут возникает неувязка.

Требуется чрезвычайно обширные знания, чтобы каждый месяц выдавать по три- четыре статьи и при этом еще успевать подбирать материал. К тому же ни кто не даст гарантий, что каждая статья будет опубликована. Какой-то процент из них будут "браковать" или откладывать в дальний ящик.

Да еще если вспомнить об урезании материала, "завернутых" темах номера, наплывах статей от других авторов, кризисах, инфляциях… то выходит, что подобный способ заработать себе на жизнь не самый лучший из возможных.

Но зато он позволяет приобрести опыт, который может пригодиться при написании книг, например. Но это уже разговор другого разговора…

Метод локального кэша

Большинство браузеров поддерживают кэширование страниц т.е. сохраняет их содержимое во временных файлах для ускорения последующих обращений. До тех пор пока кэш не будет затерт новыми поступлениями, ранее загруженные страницы можно смотреть и без подключения к Интернету. В Internet Explorer-e для этого достаточно установить галочку напротив пункта "Работать автономно" в меню "Файл". Разумно увеличить размер кэша, чтобы избежать его скорого затирания. Он задается ползунком "Папка временных файлов Интернета: занимать на диске не более" ("Сервис" à "Свойства обозревателя" à

"Временные файлы Интернета" à

"Настройка"). Оптимальное значение лежит в пределах 300 – 500 мегабайт, только помните, что в действительности потребуется гораздо больше места, особенно на FAT16, т.к. web-страницы содержат огромное количество мелких файлов, а каждый файл независимо от своего размера занимает, по крайней мере, один кластер диска.

Разумеется, кэш – крайне ненадежное место хранения для ценных web-страниц, кроме того, как быть, если потребуется сохранить страницу на дискету или передать другу, у которого вообще нет Интернет?

Если временные файлы записываются "как есть", без всяких там поползновений, их можно без труда "выдернуть" из кэша и сохранить отдельно (см. "Где Internet Explorer хранит автономные страницы?"). Единственная проблема - определить какие именно файлы среди сотен, а то и тысяч остальных следует сохранять.

Первым делом необходимо найти саму страницу – как правило, ее имя совпадает с именем htm файла в URL. Т.е. если ссылка на страницу выглядела как "http://mysite/nasa/hubble.htm", то в кэше следует искать файл hubble.htm. У Internet Explorer есть одна особенность – во избежание затирания одноименных файлов, к концу имени каждого из них он дописывает порядковый номер, заключенный в угловые скобки (типа nubble[666].htm), поэтому, правильный шаблон для поиска должен выглядеть так: "Имя файла*.расшрение", например, "Hubble*.htm".

Теперь перейдет к соби ранию картинок. Чтобы определить их имена, откройте html-странницу в любом подходящем текстовом редакторе, например, "Блокноте" и задайте поиск тегов "IMG". В общем виде тег должен выглядеть так: "<IMG SRC="image/rose.jpg">". Выражение, стоящее права от "SRC", как не трудно догадаться, и содержит искомое имя файла. Ищем его в кэше и "выдираем". Один тонкий момент – куда этот файл сохранить. Если его поместить в одну директорию с самой html-страницей, он отображаться не будет! Ведь "SRC" указывает браузеру, что картина расположена в директории "image"! Значит, необходимо создать директорию "image" в том же каталоге, в котором лежит страница, и поместить в нее злополучный файл. Еще одна тонкость – если путь выглядит как "../image/pic/mimose.fig", это означает, что директория image располагается на один уровень выше чем та, в которой лежит html-страница. Т.е. древо каталогов должно выглядеть так:

MyDir

 +--dir_for_html

 ¦  L--hubble.htm

 L--image

    L--pic

       L--mimose.jpg

Если путь "SRC" начинается с указания протокола (например, SRC="http://mysite.com/image/ngc1976.gif"), необходимо текстовым редактором вырезать все лишнее – т.е. все кроме имени файла, иначе браузер будет обращаться не к локальному файлу, а попытаться получить его из Интернета.

Раз уж мы начали резать, то имеет смысл оттяпать от всех картинок полные пути, оставив только имена файлов (например, было "../image/pic/mimose.fig" стало "mimose.fig") – это избавит от необходимости воссоздавать оригинальную структуру каталогов сервера и позволит валить все файлы в одну директорию.

Единственная проблема заключается в том, что не всегда ясно какой из нескольких файлов следует "выдирать" из кэша. Скажем, требуется заполучать pic.jpg, а в кэше содержится добрый десяток файлов с такими именами – pic[1].jpg, pic[2],jpg, pic[3],jpg и т.д. Можно попробовать, поочередно открывая их, попробовать определить какой из них какой – визуально, по смыслу. Однако это удается далеко не всегда. К тому же описанный метод достаточно трудоемок и долог. Может, есть что попроще?

Метод ручной работы

После завершения загрузки страницы выберите в меню "Вид" пункт "Просмотр в виде HTML". Откроется редактор "Блокнот", содержащий исходный HTML-код web-странички. Сохраните его на диск.

Однако, HTML-код, это только текст, а картинки, как это ни прискорбно, придется сохранять вручную – щелкая по каждой картинке правым мышем и выбирая в контекстном меню пункт "Сохранить на диск". Возможно, даже скорее всего, при этом придется воссоздавать оригинальную структуру директорий сервера или же вносить изменения непосредственно в сохраненный HTML-код (см. "Метод локального кэша").

Если картинок много, работа рискует затянуться надолго, очень надолго. Это несколько лучше, чем ковыряться в мусорной яме кэша, но ненамного. Причем, если страница разделена на несколько фреймов – т.е. независимо отображаемых областей, – сохранять их придется по отдельности, кликая по экрану в границах каждого фрейма правой клавишей мыша и выбирая пункт "Просмотр в виде HTML".

Метод Save As

Еще ранние версии Internet Explorer имели в меню "Файл" пункт "Сохранить", однако, они сохраняли не все содержимое страницы, а один лишь текст, лишенный графики. Такое положение дел, очевидно, не могло устроить пользователей и в последних версиях разработчики пошли на уступки, научив браузер полностью сохранять страницу на диск.

Пятая версия Internet Explorer в диалоговом окне "Сохранить как…" позволяет выбирать следующие типы файлов:

·         Web-страница полностью (html)

·         Web-архив один файл (mht)

·         Web-страница только HTML

·         Текстовой файл (*.txt)

Два последних пункта особого интереса не представляют, но вот на первых двух имеет смысл остановиться подробнее. Выбор "Web-страница полностью (html)" приводит к сохранению каждого элемента страницы в отдельном файле, помещаемого в автоматически создаваемую папку, совпадающую по имени с сохраняемой страницей, но имеющую расширение "files". То есть, при сохранении страницы "Тушканчики средней полосы" HTML-текст будет помещен в файл "Тушканчики средней полосы.htm", а все картинки – в папку "Тушканчики средней полосы.files".

Чтобы просмотреть сохраненную страницу необходимо дважды кликнуть по htm-файлу, а чтобы перенести ее на другой компьютер, необходимо скопировать и сам htm-файл, и соответствующую ему папку с расширением files. Неправда ли, довольно неудобно? К тому же множество мелких файлов интенсивно пожирают дисковое пространство.

Поэтому, лучше сохранять страницы в виде одного mht-файла. Он удобен в обращении и не захламляет диск лишними каталогами. Но – требует для своего просмотра наличия Outlook Express 5.x или выше (если передаете такой файл товарищу – убедитесь, что он сможет его прочитать).

После сохранения страницы обязательно проверьте, сохранилась ли в действительности она или нет. Просто запустите новую копию браузера или в меню "Файл" выберите пункт "Создать"à"Окно" и откройте только что записанный на диск HTML- или MHT-файл. По непонятной причине Internet Explorer частенько "скручивает дулю" – не сохраняет страницы, оставляя их пустыми. Причем, повторные попытки сохранения никаких результатов не дают!

Что делать? Попробуйте испытать какой-нибудь другой метод….

Метод Select All

Вероятно, самый универсальный метод всех времен и народов – это буфер обмена. Выберите в меню "Правка" пункт "Выделить все" или нажмите <Ctrl-A>, а затем вставьте скопированный фрагмент в документ Microsoft Word 2000 и сохраните его либо как html- либо как doc-файл – по своему вкусу.

Мне пришло письмо: "Если вы просматриваете данное сообщение…."

Получив сообщение a la "Если вы просматривание данное сообщение, то вы поражены злобным вирусом, против которого одно спасение – форматирование жесткого диска с последующим выбрасыванием компьютера из окна" не волнуйтесь – это всего лишь глупая шутка, и никакого вреда от просмотра такого письма нет. Конечно, при условии, что вы не открываете никаких, содержащихся в нем вложений, и не кликаете по ссылкам. Вложения действительно могут содержать вирусы, особенно если они относятся к потенциально опасным типам файлов (см. "Безопасность à

Какие почтовые вложения безопасны?"), а нажатие на ссылку способно запустить зловредную программу, в том числе и вирусную, или же передать злоумышленнику ваше имя и пароль под которым вы вошли в систему.

В принципе, теоретически возможно заразиться не только чтением письма, но даже его получением с сервера! Но практически же подавляющее большинство вирусов распространяются с помощью самих пользователей, доверчиво запускающих подсунутую им программу.

Родственные вопросы:

Безопасность à Какие почтовые вложения безопасны?

Модемы – вопросы и ответы

"Ничто не может быть плохим или хорошим само по себе"

Френк Херберт "Дюна"

Могут ли хакеры подломать провайдера и похитить мой пароль? Анастасия Isida@greco.org

Заботы по хранению своих сетевых реквизиторов провайдеры обычно возлагают на пользователей. Дескать, никому не сообщайте свой пароль, не записывайте его на бумажке, приклеенной сбоку монитора (варианты – под клавиатурой, под мышиным ковриком), никогда - никогда не запускайте программы неизвестного происхождения и т.д. А что, если хакер атакует провайдера? Сможет ли он "спионерить" пароль пользователей или нет?

Большинство провайдеров категорически отрицают такую возможность, делая "пальцы веером" и извергая целый фонтан непонятных простому обывателю слов. Дескать, как это можно не знать, что ни в открытом, ни в зашифрованном виде пароли у них не хранятся и, так называемый "файл паролей" содержит вовсе не сами пароли, а хэши (грубо говоря – контрольные суммы паролей). А знание хэша не позволяет установить оригинальный пароль иначе, чем последовательным перебором. Если клиент не выбрал себе простое словарное слово, наподобие "mafia" или "chongachanga" подобрать его пароль даже на самом крутом Pentium-е удастся не быстрее, чем наступит очередной ледниковый период!

Тем временем, ворованные пароли продаются хакерами едва ли не на каждом углу – ау! ледниковый период. Провайдеры, в пылу своего красноречия, тактично умалчивают, что под Windows NT\2000 оригинальный пароль пользователя для входа на сервер и вовсе не нужен – сервер его и сам не знает! Во время аутентификации клиент передает не пароль, а хэш пароля. Сервер берет этот хэш и сверяет его с эталонной записью, хранящейся в базе. Если хакер проникнет на сервер и получит доступ к базе, он сможет похитить все хэши!

Несколько лучше дела обстоят с UNIX – она шифрует пароли по аналогичной схеме, но требует от пользователя не хэш, а открытый пароль, выполняя вычисление контрольной суммы самостоятельно. Даже если злоумышленники утянут "файл паролей", ничего кроме контрольных сумм паролей они не обнаружат, а обратить контрольную сумму и получить исходный пароль ой как не просто! – Потребуется много времени и много быстрых компьютеров, а у рядового злоумышленника ни того, ни другого в избытке не имеется!

Однако открытость пароля предоставляет возможность его перехвата – если злоумышленник вломится на компьютер провайдера и незаметно установит там "жучок", он сможет подсматривать пароли всех входящих в сеть пользователей со всеми вытекающими отсюда последствиями.

Теоретически взлом провайдера с похищением паролей пользователей вполне реален и ничего мифического в этом нет, причем такие события происходят достаточно часто… К сожалению, рядовой пользователь не может определить надежность защиты провайдера – это по силу только системным администраторам и самим хакерам.

Могут ли злоумышленники подключится

Модемные протоколы основаны на двухстороннем обмене электрическими импульсами, поэтому, подключать параллельный модем к телефонной линии бессмысленно – он не сможет нормально работать в таких условиях.

Правда, существует специальное оборудование для "шпионской прослушки", стоящее немерянных денег, но способное осуществить такой перехват. За его неимением некоторые отчаянные головы пытаются декодировать электрические сигналы с помощью Sound Blaster-а, вмонтированного в Notebook. И, говорят, получается!

Можно ли автоматически отвечать

Многие почтовые службы, в том числе и бесплатные, поддерживают услугу "Автоответчик" – возможность автоматического ответа на приходящие письма. Это бывает полезно во многих случаях: представьте, уезжаете вы, скажем, в командировку на пару недель, а тем временем вам идут письма, отправители которых гадают – и куда же это их адресат запропастился? Или вот, предположим, Big-Boss захотел, чтобы на каждое полученное на корпоративный ящик письмо в ответ высылался прайс – лист вашей фирмы (каталог производимых изделий) – ситуация, знакомая, правда? Автоответчик, не напрягая секретаря, быстро и дешево выполнит эту работу, пускай и будет действовать вслепую. Впрочем, придать автоответчику некоторые зачатки интеллектуальности помогают грамотно настроенные фильтры (см. ответ на предыдущий вопрос).

Методика управления автоответчиками до сих пор не стандартизирована (и вряд ли будет стандартизирована в обозримом будущем) и каждый из них работает по-своему – за подробностями обращайтесь к администратору вашей почтовой службы.

Рассмотрим для наглядности включение и конфигурирование автоответчика на примере службы mail.ru. Набираем ее адрес в строке браузера – www.mail.ru (управление автоответчиком из почтового клиента не поддерживается), вводим свой логин и пароль, а затем, в открывшейся странице переходим к ссылке "Настройки". Так… ждем-с окончания загрузки страницы… среди прочей нечисти находим ссылку "Автоответчик" и щелкаем по ней. Появляется окно управления автоответчиком – с формой для задания автоматического ответа и полями для указания даты включения и выключения автоответчика. Заполнив форму по своему усмотрению, взводим галочку "Включать автоматический ответ" и нажимаем кнопочку "Сохранить".

Все! С этого момента автоответчик включен и готов к работе. Чтобы убедиться в этом, можно послать несколько писем самому себе. Для внепланового же отключения автоответчика до окончания установленного срока, достаточно снова зайти в "Настройки" à

"Автоответчик" и снять галочку "Включать автоматический ответ", после чего "Сохранить" изменения.

Рисунок 33 Рис. 0х027 Управление автоответчиком службы mail.ru

Внимание: отправка письма самому себе вызывает зацикливание некоторых автоответчиков, поскольку они отправляют ответ на свой же адрес, а потом ответ на свой ответ… и так до бесконечности, пока ящик не переполнится и система встанет. Вообще-то, грамотные разработчики должны предусматривать такую тривиальную ситуацию, но некоторые забывают об этом.

Можно ли обойти защиту от трассировки?

Обойти защиту от трассировки ничуть не легче, чем достать Луну с неба, но если очень-очень хочется, попробуйте обратится за помощью к утилите ping – будучи запущенной с ключом –r, она заставляет промежуточные узлы вносить свои IP-адреса в заголовок дейтаграммы. Не все маршрутизаторы поддерживают такую возможность, но подавляющее большинство из них подчиняется этому требованию.

Последний узел в цепочке принимает пакет и возвращает эхо-отклик, содержащий в себе заголовок входящего пакета с адресами промежуточных хостов.

C:\>ping chat.ru -r 9

Обмен пакетами с chat.ru [212.24.32.192] по 32 байт:

Ответ от 212.24.32.192: число байт=32 время=410мс TTL=246

  Маршрут: 195.151.210.36 ->

           195.151.210.30 ->

           195.151.200.89 ->

           195.151.52.42 ->

           194.84.251.245 ->

           193.232.88.18 ->

           193.232.244.41 ->

           212.24.32.2 ->

           212.24.32.192

Весьма существенный камень преткновения – жесткое ограничение на количество запоминаемых узлов – емкость IP-заголовка при всем желании не позволяет вмещать более девяти IP-адресов, что в большинстве случаев оказывается недостаточно. Во время проектирования IP-протокола эта цифра не казалась ограничением, скорее наоборот – запасом на будущее, равно как на заре рассвета микрокомпьютеров 640 килобайт оперативной памяти были пределом мечтаний, и никому бы и в голову не пришло, что наступят времена, когда такого объема может не хватить.

К тому же, ping – не панацея и эхо - отклики могут быть так же запрещены администраторами, как и уведомления об уничтожении пакетов (см. "Почему ping не проходит, а сайт сервера нормально работает и открывается?"). Правда, эхо - отклики администраторы запрещают гораздо реже, чем блокируют трассировку, поэтому, в некоторых случаях такой прием может помочь. Конечно, при условии, что клиента с сервером разделяет не более восьми узлов!

Родственные вопросы:

Почему ping не проходит, а сайт сервера нормально работает и открывается?

Можно ли сделать так, чтобы компьютер

Заставить компьютер связываться с провайдером в определенное время можно с помощью "Планировщика", входящего в штатную поставку Windows98\2000. Кликните по иконке с часами и календарем, расположенной в правом нижнем углу – откроется окно "Назначение задания". Кликните по иконке "Добавить задание", затем укажите путь к ранее созданному командному файлу следующего содержания "start Ярлык Соединения с Интернет" (см. "Можно ли войти в Интернет, используя только командную строку" и "Как избавится от запроса подтверждения правильности имени и пароля перед набором номера?"), а затем выберете необходимый сценарий расписания для запуска (см. рис. 8)

Для автоматического запуска почтового клиента добавьте его ярлык в папку "Автозагрузка" или создайте еще один сценарий Планировщика. Необходимо рассчитать время так, чтобы почтовый клиент запустился после того, как будет установлено соединение, на что требуется несколько минут.

Рисунок 8 Рис 0x020 Добавление нового задания Планировщика

{К рисунку – заменить синий фон на белый}

::Альтернативный вариант – заставьте почтового клиента самостоятельно устанавливать соединение с Интернет при запуске. Для этого в меню "Сервис" приложения "Outlook Express" выберите пункт "Параметры" и перейдите к закладке "Подключение". В "Телефонном соединении" сбросьте флажок "Спрашивать перед изменением номера соединения", и взведите "Разрывать связь после получения и отправки сообщений". В графе "Соединение с Интернетом" нажмите кнопку "Изменить" и в открывшемся диалоговом окне перейдите к вкладке "Подключение". В списке "Настройка удаленного доступа" выберите соединение, которое будет использоваться для подключения к сети и назначьте его соединением по умолчанию, нажав одноименную кнопку, расположенную справа внизу. Переместите радио кнопку в положение "Всегда использовать принятые по умолчанию".

Все! Теперь почтовый клиент, будучи запущенным, автоматически войдет в сеть, заберет всю накопившуюся к этому моменту почту и затем разорвет соединение. Запустить же почтового клиента в заданное время можно с помощью Планировщика, о чем было рассказано выше.

Родственные вопросы:

Можно ли войти в Интернет, используя только командную строку

Как избавится от запроса подтверждения правильности имени и пароля перед набором номера?

Можно ли увидеть карту всего Internet, связи, каналы, структура? Сергей Иванов

С "высоты птичьего полета" карту Интернет можно изобразить прямой линией с множеством нанесенных на нее IP адресов, так, чтобы каждый IP-адрес был связан со всеми остальными (см. рис. 10)

Рисунок 10 Рис. 0x014 – Схематическое изображение карты Интернет

Подлетев поближе, мы увидим, что IP-адреса группируются в "стаи", на техническом языке именуемые сетями, а самих сетей существует бесчисленное множество. Члены одной сети, как правило, обслуживаются одним "вожаком", то бишь одним поставщиком сетевых услуг и очень прытко спариваются друг с другом – гораздо легче и быстрее, чем с членами чужих сетей. С другой стороны – если вожак скинет копыта (провайдер зависнет) – парализуется работа всей стаи.

Определить принадлежность узла к той или иной подсети можно по его IP-адресу. Существует несколько различных типов сетей, отличающихся друг от друга максимально возможным количеством входящих в них узлов, – от сетей-малюток в пару сотен абонентов до гигантских мегаполисов из десятков миллионов узлов. Чем же вызвана такая вопиющая несправедливость?

Камень преткновения в ограниченной разрядности IP-адреса – при всем желании в жалкие 32 бита нельзя втиснуть больше, чем четыре миллиарда постоянных узлов. Учитывая все ускоряющие темпы роста Интернет – это совсем немного!

Если откинуть немногочисленные клинические случаи (оговоренные ниже), всякий IP-адрес состоит, по меньшей мере, из адреса сети и адреса узла в этой сети. Адрес сети занимает от одного до трех октетов (октет – это восьмерка бит, в общепринятой нотации представленная десятичным числом от 0 до 255 и отделенная от другого октета символом точки). Из-за переменной длины определить принадлежат ли два IP-адреса одной или различным сетям не так-то просто! Поэтому, ниже приведена таблица 2, облегчающая решение этой задачи.

Диапазон IP адресов		Класс сети		Макс. кол-во узлов сети		Макс. кол-во сетей
001.ххх.ххх.ххх - 126.ххх.ххх.ххх		А		16.777.214		126
128.000.ххх.ххх – 191.255.ххх.ххх		B		65.534		16.382
192.000.000.ххх – 223.255.255.ххх		С		254		2.097.150

<
Таблица 2 Классификация сетей Интернет

Попробуем это таблицей воспользоваться. Например, есть у нас два адреса: 119.013.200.01 и 119.014.22.221 – так, смотрим, старший, т.е. первый слева октет, – 119 – входит в диапазон 1 – 126 и, следовательно, указывает на сеть класса А. Три остальных октета задают адрес узла в этой сети. Таким образом, оба IP-адреса принадлежат одной сети – 119.000.000.000.

Другой пример: возьмем адреса 191.222.067.129 и 191.221.067.129. Так-с, первый октет – 191 – явно не входит в интервал 1 – 126 и не принадлежит сети класса А, но принадлежит сети класса B. Адрес сети класса B задается двумя октетами, следовательно, второй октет слева – это продолжение адреса сети. Но у наших IP-адресов вторые слева октеты разные – 222 против 221. Выходит, эти узлы принадлежат различным сетям.

Чтобы построить карту Интернет остается только разобраться как соединяются узлы одной сети и как сами сети взаимодействуют друг с другом.

При модемном соединении с провайдером все абоненты соединяются друг с другом и с внешним миром через специальный выделенный сервер (см. рис. 11.1). Для локальных Ethernet сетей более характерно "параллельное" подсоединение – с внешним миром узлы общаются через специальный сервер, а друг с другом – напрямую без посредников. Разумеется, это упрощенная модель: сети могут делиться на подсети, связанные между собой маршрутизаторами, а каждый узел локальной сети может принимать входящие звонки с одного или нескольких модемов. Таким образом, схема функционирования типичного провайдера сильно отличается от идеализированных моделей и ближе к рис. 11.2.



Рис 0x015 Типичная схема подключения к провайдеру,      Рис 0x016 Типичная локальная Ethernet-сеть



Рисунок 11 Рис 0x017. Комбинированная модель

Сами сети в свою очередь так же соединены меж собой некоторым образом, причем, не всегда напрямую, а зачастую через длинную цепочку промежуточных сетей. Самое интересное, маршрут путешествия пакетов от одной сети к другой в большинстве случаев не единственный и не постоянный. Точно так, из Москвы в Ленинград можно отправиться и на самолете, и на поезде, и на легковой машине, и… да мало ли еще на чем! Аналогично: при соединении с сайтом Microsoft.com, случается, что один пакет направляется по трансатлантическому кабелю, другой – из-за перегрузки маршрутизатора – идет через спутник, а третий доставляется совсем иным путем.



Разумеется, это возможно только в тех случаях, когда сети соединены друг с другом множественным образом, иначе – путь только один, равно как из таежной деревни Большие Грибы в Москву можно добраться лишь одним путем – сначала на санях до вокзала, а оттуда поездом до точки назначения с кучей пересадок. И никаких вам ни самолетов, ни вертолетов, ни спутников…

??? Рисунок "карикатура" – обыграть предыдущий абзац

Чтобы построить любую карту, не обязательно именно Интернет, необходимо отправиться в путешествие в процессе которого наносить на бумагу свой маршрут с указанием географических (или Интернет) координат. В Интернете координатами служат IP-адреса, ну а в роли картографа выступает утилита tracert из штатной поставки Windows, скрупулезно отмечающая все промежуточные узлы, посещенные пакетом. Остается только выбрать маршрут путешествия. Куда бы нам направится? Давайте посетим сайт провайдера www.aha.ru. Итак, набираем в "Сеансе MS-DOS" "tracert.exe www.aha.ru" и ждем-с. Маршрут путешествия автора, пользующегося услугами првайдера krinel, выглядел так:

Трассировка маршрута к www.aha.ru [195.2.70.38]

1   831 ms   871 ms     *     cisco03-s0.krintel.ru [195.161.42.210]

2   801 ms   771 ms   801 ms  ns.krintel.ru [195.161.42.222]

3   841 ms   831 ms   821 ms  195.161.241.1

4   841 ms   831 ms   851 ms  195.161.241.226

5   831 ms   802 ms   841 ms  217.106.16.49

6   811 ms   811 ms   891 ms  217.106.17.69

7   842 ms   811 ms   861 ms  bb-pos1-1-0-155m.moscow.rostelecom.ru [213.24.141.185]

8   891 ms     *      861 ms  bgw2-giga4-0-0.Moscow.Rostelecom.ru [195.161.0.2]

9  1061 ms   751 ms   831 ms  m9-2-atm3-0-5.zenon.net [195.161.161.158]

10   932 ms   811 ms   871 ms  m9-3-giga5-0-0.msk.zenon.net [195.2.89.13]

11  1001 ms   851 ms   842 ms  jam-l3sw-2-giga1-2.msk.zenon.net [213.189.198.22

22   942 ms   871 ms   931 ms  jam-slb-1.msk.zenon.net [195.2.70.38]

О чем этот протокол говорит? Сначала пакеты попадают на "сортировочный пункт" – маршрутизатор cisco03.krintel.ru с IP-адресом 195.161.42.210. Обратившись к таблице 2, выясняем, что это сеть класса "С", следовательно, адрес сети задается тремя старшими октетами и выглядит так: 195.161.42.0. Затем пакеты направляются на "сборочный пункт" – ns.krinel.ru, судя по адресу сети, принадлежащий все тому же провайдеру, а затем – в другую сеть 195.161.241.0, затем вновь в другую и, наконец, добираются до крупного провайдера RosTelecom, который и является провайдером провайдера krintel. Погуляв немного по серверам Ростелеком-а, пакетики, наконец, устремляются в локальную сеть провайера zenon – того, что владеет сервером www.aha.ru…



Таким образом, первая линия на карте Интернет проведена. Попробуем теперь другой маршрут – исследуем траекторию путешествия пакетов к серверу NASA, расположенного в далекой Америке.

Трассировка маршрута к foundation.hq.nasa.gov [198.116.142.34]

1   781 ms   982 ms   991 ms  cisco03-s0.krintel.ru [195.161.42.210]

2   831 ms   912 ms   901 ms  ns.krintel.ru [195.161.42.222]

3   971 ms   832 ms   861 ms  195.161.241.1

4   841 ms   851 ms   841 ms  195.161.241.226

5   841 ms   861 ms   852 ms  217.106.16.49

6   862 ms   861 ms   831 ms  aa-bb-s3-2-0.Rostov.Rostelecom.ru [217.106.17.25]

7   851 ms     *      861 ms  bb-pos1-1-0-155m.moscow.rostelecom.ru [213.24.141.185]

8     *      882 ms   821 ms  bgw2-giga4-0-0.moscow.rostelecom.ru [195.161.0.2]

9  1052 ms  1031 ms  1112 ms  dar1-serial4-1-0-0.NewYorknyr.cw.net [206.24.206.65]

10  1081 ms  1062 ms  1101 ms  acr2-loopback.NewYorknyr.cw.net [206.24.194.62]

11  1062 ms     *     1112 ms  corerouter2.WestOrange.cw.net [204.70.9.139]

12  1111 ms  1162 ms  1061 ms  core4.Washington.cw.net [204.70.4.105]

13  1042 ms  1161 ms  1072 ms  cable-and-wireless-peering.Washington.cw.net [204.70.1.18]

14  1081 ms  1102 ms  1232 ms  mae-east.nsn.nasa.gov [192.41.177.125]

15  1132 ms  1121 ms  1152 ms  128.161.3.14

16  1231 ms  1242 ms  1312 ms  128.161.1.62

17  1372 ms  1602 ms  1392 ms  border.hcn.hq.nasa.gov [198.116.63.34]

Ага, оказывается, начальная часть маршрута совпадает – куда бы мы ни шли, мы все равно попадаем в Ростелеком, на базовый перевалочный путь, т.е. ту железнодорожную станцию Больших Грибов, куда приходится добиться на санях.

Впрочем, не всегда одними и тем же путями – в прошлый раз пакет направлялся на Московский сервер Ростелеком, а сейчас – на Ростовский! Но в целом путь всех пакетов идентичен – жирным шрифтом выделены совпадающие в обоих случаях точки маршрута.

Продолжая действовать в том же духе, поочередно соединясь с различными сетями, в некотором (весьма отдаленном) будущем мы сумеем построить если карту не всего Интернет, то, по крайней мере, некоторой его части. Нельзя ли как-нибудь автоматизировать этот процесс? Увы, нет…



Так надо ли этим заниматься? В общем-то, нет, но знать каким именно образом ваш провайдер соединен с внешним миром и кто провйдер првайдера под час очень полезно. Проследим маршрут пакетов к серверу www.aha.ru, подключившись к другому провайдеру – itech.

Трассировка маршрута к www.aha.ru [195.2.70.38]

1   140 ms   130 ms   140 ms  nas.itech.ru [195.151.210.36]

2   151 ms   140 ms   150 ms  ns.itech.ru [195.151.210.33]

3   171 ms   160 ms   170 ms  gw.itech.ru [195.151.210.29]

4   161 ms   160 ms   180 ms  195.151.200.90

5   260 ms   231 ms   300 ms  krd-gw.mtt.ru [195.151.52.41]

6   391 ms   340 ms   371 ms  Moscow18-S3-7-0.RoSprint.net [194.84.251.246]

7   340 ms   451 ms   410 ms  Moscow41-F1-0.RoSprint.net [193.232.88.23]

8   360 ms   501 ms   330 ms  m9-3-fa4-1-0.zenon.net [193.232.244.48]

9   821 ms   901 ms  2164 ms  jam-l3sw-2-giga1-2.msk.zenon.net [213.189.198.25]

10  441 ms   320 ms   341 ms  jam-slb-1.msk.zenon.net [195.2.70.38]

Заметно, что теперь пакеты доходят втрое быстрее (320 ms задержки против 870) к тому же маршрут вдвое короче, а сам провайдер пользуется услугами Sprint-а, а не Ростелекома. Но самое интересное посмотреть каким образом идут пакты от провайдера itech к провайдеру krintel. Самих провайдеров физически разделяет каких-то двадцать километров, поэтому, думается, маршрут пакетов будет очень коротким…

Трассировка маршрута к krintel.ru [195.161.42.222]

1     *     2984 ms     *     nas.itech.ru [195.151.210.36]

2  2895 ms  1051 ms   180 ms  ns.itech.ru [195.151.210.33]

3   220 ms   491 ms   180 ms  gw.itech.ru [195.151.210.29]

4   240 ms   261 ms   220 ms  195.151.200.90

5   621 ms  1162 ms  1872 ms  krd-gw.mtt.ru [195.151.52.41]

6     *        *        *     Превышен интервал ожидания для запроса.

7   451 ms   450 ms   311 ms  Moscow01-F0-0-0.RoSprint.net [193.232.88.20]

8   360 ms   501 ms   360 ms  Petersburg01-A1-0-0-1.RoSprint.net [193.232.90.5]

9  1142 ms   521 ms     *     Fe1-0-0.STPAR1.St-petersburg.opentransit.net [193.251.248.41]



10   511 ms   611 ms   490 ms  A0-0-0.634.STHAR2.Stockholm.opentransit.net [193.251.150.241]

11   631 ms   441 ms   390 ms  P1-1.STHBB1.Stockholm.opentransit.net [193.251.150.33]

12   391 ms   561 ms   430 ms  P4-0.LONBB1.London.opentransit.net [193.251.154.185]

13   421 ms   540 ms   491 ms  P6-0-0.LONAR1.London.opentransit.net [193.251.154.114]

14   501 ms   430 ms   411 ms  195.66.225.48

15  1953 ms  1863 ms  2603 ms  ldn-hex-b1-srp5-0.telia.net [193.45.0.129]

16   741 ms   431 ms   441 ms  sto-b3-pos3-0.telia.net [193.45.129.37]

17   610 ms   491 ms   591 ms  sto-fre-i1-srp1-0.telia.net [193.45.129.4]

18   500 ms   381 ms   461 ms  rosstelecom.k.telia.net [193.45.36.202]

19  2925 ms   811 ms   641 ms  gsr-giga2-2.Moscow.Rostelecom.ru [195.161.0.7]

20   431 ms   721 ms   441 ms  bb-pos5-0-155M.Rostov.Rostelecom.ru [213.24.141.186]

21   420 ms   441 ms   451 ms  aa-s1-0.Krasnodar2.Rostelecom.ru [217.106.17.2]

22   751 ms   411 ms   521 ms  217.106.16.50

23   470 ms   421 ms   471 ms  195.161.241.227

24   531 ms   601 ms   550 ms  krintel.ru [195.161.42.222]

О-го-го! Двадцать четыре перехода, с заходом в Санкт-Петербург, Стокгольм, Лондон, Москву, Краснодар, Ростов... Вот это "короткая" дорога! Дважды обогнуть Землю, чтобы попасть в исходную точку!

Зная, как провайдер соединен с внешним миром, с другими странами и провайдерами, можно не задумываясь распознавать самый быстрый из нескольких зеркальных серверов, причем осмысленно, а не  методом тыка!

Например, входя в сеть через провайдера krintel бессмысленно пользоваться web и ftp Proxy-серверами провайдера itech – это только замедлит соединение. Напротив, зная, что у krintel-а связь с Америкой препаршивейшая, а с Японией даже быстрее, чем по России – имеет смысл найти бесплатный японский Proxy и через него скачивать с сайта любимой фирмы новую beta-версию всем известного браузера.

Можно ли войти в Интернет, используя только командую строку?

Да, можно, но с некоторыми ограничениями. Штатная поставка Windows9x содержит лишь GUI-шную утилиту удаленного доступа. Ее, в принципе, можно вызвать и из командной строки, но работать она будет все равно в графическом режиме. Напротив, поставка Windows NT\2000 включает в себя полноценное консольное приложение для удаленного доступа – rasdial, вообще не использующее графического интерфейса.

Можно ли восстановить случайно удаленное сообщение?

Общеизвестно, что при удалении сообщений Outlook Express в действительности их не уничтожает, а перемещает в папку "Удаленные". Но можно восстановить сообщение, удаленное из "Удаленных"?

Штатными средствами – нет и автору не известна ни одна, умеющая это делать, утилита. Но, если со времени удаления сжатие папок не выполнялось и фоновое сжатие отключено (см. ответ на предыдущий вопрос), – стоит попытаться сделать это вручную.

В Windows 9x все сообщения хранятся в почтовых файлах "как есть" (см. ответ на вопрос "Где Outlook хранит мои письма?") в одноименных файлах и, открыв их любым подходящим текстовым редактором, можно найти удаленное сообщение, вырезать его и сохранить на диск. В Windows 2000 сообщения так же хранятся "как есть", но имена почтовых файлов по умолчанию не совпадают с именами соответствующих папок – будьте внимательны!

Родственные вопросы:

Где Outlook Express хранит мои письма ?

Я удалил из паки большое количество сообщений, но ее размер не изменился

На какие характеристики модема следует обращать внимание в первую очередь?

Покупая двадцати одно дюймовый монитор, мы абсолютно уверены, что он будет работать именно на двадцать один дюйм, а не всего лишь на семнадцать или того хуже – четырнадцать! С модемами же ситуация совсем иная: на наших телефонных линиях практически ни какой из них не "разгоняется" до 56 килобитод

в секунду – наиболее популярной на сегодняшний день скорости, горделиво красующейся на коробках. Реальная производительность модемов весьма разнится от одного изделия к другому, порой отличаясь в десятки раз, но какой бы высокой скорость ни была – модем бесполезен, если постоянно "роняет" трубку или – что хуже – и вовсе не может установить соединение.

В примере с мониторами все ясно – все основные характеристики как-то: диагональ, разрешение, частота, зернистость интуитивно понятны каждому покупателю и не требуют дополнительных разъяснений. А вот на что в первую очередь обращать внимание при покупке модема? Вопрос не имеет однозначного ответа – все зависит от рода и качества телефонной линии, на которой вы собираетесь этот модем эксплуатировать.

Для местных каналов связи в первую очередь актуальны: устойчивость модема к затуханию сигнала, устойчивость к постоянному шуму и импульсным помехам (треску). Для междугородних в дополнение к этому – максимально допустимое расхождение частот, устойчивость к джиттеру (резким скачкам фазы), степень переносимости

нелинейности АЧХ ("завалов" и "подъемов" на некоторых частотах).

Затухание сигнала: вследствие сопротивления кабелей мощность сигнала по мере его продвижения от передатчика к приемнику неуклонно снижается и, если затухание окажется достаточно сильным, приемник может вообще не расслышать сигнал. Минимальная мощность сигнала, уверенно воспринимаемая приемником, называется его чувствительностью. {КОНЕЦ КУРСИВА}Чувствительность модема принято выражать в децибелах относительно мощности в 1 мВт. Попросту говоря, чем больше по модулю, приведенное в паспорте значение, чем лучше модем справляется с затуханием.

Чувствительность большинства модемов лежит в интервале от –40 до – 50 дБм, чего вполне достаточно в большинстве случаев, даже более чем – на линиях с незначительным затуханием модем "глохнет" от "крика" своего собеседника и чувствительность приходится снижать. Для оптимальной настройки на конкретную линию модему необходимы регуляторы уровня приема и передачи. Они могут быть либо ручными (такие ставят на модели среднего класса), либо автоматическими (такие встречаются на дорогих моделях), а на дешевых поделках зачастую по обыкновению никаких регуляторов вообще нет или присутствует только регулятор передачи.

??? Рисунок "карикатура" – один модем, стоящий на ногах как человек, орет что есть силы, а другой затыкает свои уши пальцами

На низкокачественных телефонных линиях затухание зачастую не остается постоянным, а меняется с течением времени по случайному или периодическому закону – в этом случае ручная регулировка дает немного пользы и намного выгоднее применить модем с автоподстройкой уровня сигнала.

Очень важная характеристика – обычно замалчиваемая производителями – скорость приема данных на пределе чувствительности. Она, за исключением клинических случаев, лежит в интервале от 500 до 2.000 байт в секунду. Высокая паспортная чувствительность модема указывает лишь на возможность удержания соединения при снижении сигнала до такого-то данного уровня, но отнюдь не гарантирует стабильность и производительность его работы в таких условиях. На практике высокочувствительные модемы отличаются лишь способностью противостоять временным затуханием сигнала без разрыва связи.

Скоростной показатель по затуханию позволяет приблизительно оценить среднюю скорость передачи в зависимости от степени затухания сигнала. и Выражается он безразмерной величиной, равной площади фигуры, образованной пересечением графика "скорость (степень затухания)" с координатными осями.

Шум: монотонное шипение, так же называемое "белым шумом", описывается тем же законом, что и результат работы генератора случайных чисел. Белый шум, наложенный на полезный сигнал, можно выдать только "с мясом" – самим полезным сигналом. Фактическая амплитуда полезного сигнала равна разности амплитуд сигнала и шума. Отсюда – абсолютная величина амплитуды шума не имеет никакого значения – качество линии определяется отношением уровня сигнала к уровню шума.



Важнейшие шумовые характеристики модема – это: показатель критического отношения сигнала к шуму и скоростной показатель качества по зашумлению. Показатель критического отношения сигнала к шуму определяет максимально возможную степень зашумленности линии, при которой еще возможно поддержание связи, а скоростной показатель качества по затуханию выражается безразмерной величиной, равной площади фигуры, образованной пересечением графика "скорость (степень зашумленности)" с координатными осями.

У различных моделей модемов показатель критического отношения сигнала к шуму неодинаков и колеблется от 2 до 11 дБ, чем эта величина больше, тем более качественная линия требуется модему для работы.

Импульсные помехи: щелчки и трески на линии в режиме блочной передачи как минимум приводят к необходимости повторной посылки кадра, а максимум – перенастройке параметров соединения. Разрыв связи от кратковременных помех случается крайне редко и указывает на неправильную настройку или неисправность модема.

Расхождение частот: высокочастотное уплотнение связи, использующие в основном на междугородних каналах, основано на сдвиге спектра передаваемого сигнала в высокочастотную область – это позволяет, сдвигая спектр каждого абонента на "свое" расстояние, "упаковать" в один высокочастотный канал множество низкочастотных. Разумеется, на принимающей стороне приходится проделывать обратную операцию – сдвигать спектр вниз – в область меньших частот.

В силу конструктивных особенностей синхронизация между приемником и передатчиком отсутствует, что приводит к невозможности точного воспроизведения частоты исходного сигнала – возможен как "недодвиг", так и "передвиг". По нормативам максимально допустимое отклонение составляет ±7 Гц, но на практике приходится сталкиваться и с большими значениями.

Противостоять сдвигам частоты помогают специальные компенсаторы, встроенные в модем – чем совершеннее компенсатор, тем больший сдвиг он может выдержать. Расхождение частот никак не сказывается на скорости обмена данными, но, начиная с некоторой величины, компенсатор не справляется и связь не устанавливается.



Критическое значение сдвига варьируется от одной модели модема к другой и заключено в интервале от ±10 до ±20 Гц – чем оно больше, тем лучше модем.

Джиттер: наводки от источников переменного тока и индукторных вызовов с соседних каналов, проходя через аппаратуру высокочастотного уплотнения, приводят к паразитной модуляции и, как следствие, – дрожанию фазы с частотой порядка 100 Гц. Основная энергия джиттера сосредоточена в узком диапазоне 2-20 Гц и специальные фильтры, встроенные в модем, могут ее подавить.

Разумеется, степень подавления джиттера различными моделями модемов не одинакова – одни рвут связь уже при 20°, в то время как другие спокойно выдерживают 45°. Чем эта величина больше – тем лучше.

Нелинейность АЧХ: вследствие индуктивного сопротивления линии, затухание сигнала быстро растет с частотой, и для преодоления этой беды применяют эквалайзер, позволяющий выборочно усиливать строго определенные частоты, а не весь спектр сигнала целиком.

Пункты переприема – попросту говоря ретрансляторы – вносят в сигнал свои искажения – усилители заваливают АЧХ по краям, причем каждый из них по-своему, отчего после N-ого пункта переприема АЧХ сигнала начинает приобретать очень причудливый вид, напоминая разлапистый горный кряж с многочисленными "пиками" и "провалами". Исправить такие искажения может только очень сложный эквалайзер. К сожалению, общепринятой величины, выражающей "интеллектуальность" эквалайзера не существует, и в отчетах независимых экспертов фигурирует другая величина – максимальное количество станций переприема, которое может "вынести" модем. При условии, что все модемы тестировались на одной аппаратуре, эта величина позволяет сравнивать относительное качество одних моделей с другими.

Эхо: своим появлением дуплексная передача не в последнюю очередь обязана изобретению адаптивных эхо компенсаторов, – без них уровень шумов был бы настолько высок, что о скоростях передачи свыше 2.400 бит в секунду пришлось бы забыть. С ростом скорости допуски на эхо резко ужесточаются, а сами компенсаторы невероятно усложняются, порой приближаясь к сложности самого модема, а то и превосходя его. Производители дешевых моделей экономят в первую очередь на эхо - компенсаторах, и такие модемы крайне неудовлетворительно работают на линях среднего и низкого качества – они либо вообще не могут соединиться на скорости выше 14.400 – 19.200, либо постоянно роняют трубку.



Подавление эха – задача, тесно граничащая с искусственным интеллектом, и общепринятых единиц для ее выражения нет.

{ВСТАВИТЬ ПЕРЕНОС СТРОКИ \n}

Производители модемов с упорством, достойным упрямейших из ослов, всеми силами замалчивают реальные технические характеристики своих изделий, и уж тем более избегают приводить их в паспорте. Поэтому, техническая документация – слабый помощник при выборе конкретной модели модема. Приходится обращаться к независимым источникам и отчетам тестирования модемов различными экспертами. Чаще всего их измерения носят объективный характер и достаточно достоверны, но:

во-первых, как правило, это измерения с настройками по умолчанию – иначе, говорят эксперты, будут сравниваться не сами модемы, а искусство их настройки. Но настройки по умолчанию под час мало чему путному соответствуют, и такие тесты должны быть интересны только покупателям a la "принес – воткнул - работает", не собирающихся "колдовать" над своим модемом;

во-вторых, независимые тестеры редко измеряют все перечисленные выше параметры, а без этого результат тестирования, мягко говоря, ущербленный, неполноценный. Скажем, к чему модему высокая чувствительность, если он не может справиться ни с эхом, ни с шумом – постоянными спутниками тихого сигнала. Это все равно, что скоростная гоночная машина со слабыми тормозами и плохим управлением – крути – не крути, а ездить на полной скорости все равно не придется.

Выбор модема – рулетка! и Здесь очень трудно дать заочно конкретный совет, но автор все-таки

же попробует…

Родственные вопросы:

Выбор модема (следующий)

Как выбрать модем по руке

Как подобрать правильную строку инициализации или что делать, если модем не работает?

Надежнее ли "сохранение пароля" его ручного ввода?

Сравнивать надежность "сохраненного пароля" с его ручным вводом – все равно, что сравнивать тяжесть километров и литров. Это совершенно разные категории каждая со своими достоинствами и недостатками.

Недостатки пароля, вводимого вручную, следующие:

а) длинный пароль трудно запомнить, и приходится где-то записывать, что создает угрозу его раскрытия, а короткий или осмысленный пароль злоумышленник сможет легко подобрать;

б) пароль, набираемый на клавиатуре, могут подсмотреть посторонние (гости, коллеги и т.д.);

с) зловредная программа-шпион (вирус, например) может отслеживать нажатие клавиш и отсылать их своему "хозяину";

д) ручной ввод пароля – утомительное занятие, особенно если его приходится вводить помногу раз на день.

Недостатки "сохраненного пароля" следующие:

а) зловредная программа-шпион (вирус, например) может вытащить из компьютера сохраненный пароль и отослать его своему "хозяину";

б) любой человек, сев за компьютер, безо всяких программ сможет получить доступ к защищенному паролем ресурсу, т.к. ручного ввода пароля не требуется.

"Сохранение пароля" ничуть не безопаснее его ручного ввода – если у потенциального похитителя пароля есть доступ к компьютеру или возможность запустить на нем шпионскую программу, он с одинаковой легкостью украдет и "сохраненный", и "ручной" пароль. Но автоматическое сохранение пароля очень удобно и не стоит пренебрегать этой возможностью!

Накрутка – как средство конкурентной борьбы

Баннер мало показать. Надо знать кому его показать! Например, реклама крановых электродвигателей, вывешенная на ботаническом сайте, будет чрезвычайно малоэффективна, хотя - с точки зрения многих баннерных компаний - вполне законна.

Причем, сам рекламодатель, купивший столько-то своих показов, зачастую не имеет ни какого представления о том: кому и где они будут показаны (и будут ли показаны вообще)! Конкуренты могут воспользоваться этим фактом для размещения его баннеров на таких страницах, где их увидит совсем другая целевая аудитория. И, хотя все показы будет засчитаны, ожидаемого результата реклама не принесет и деньги, затраченные на нее, окажутся выброшенными впустую.

Впрочем, от этого очень легко защититься. Покупая показы, необходимо всегда обязательно оговариватьоговаривайте

тематику сайтов, на которых они будут расположены. В противном случае эффективность рекламы будет неоправданно низкой даже и без вмешательства конкурентов.

Накрутка на стороне клиента

Качественная имитация пользователя – чрезвычайно сложная задача, требующая для своей реализации достаточно высокого программистского мастерства. Те же, кто обладает такой квалификацией, вряд ли будут связываться с накрутной баннеров. Во всяком случае, в сети не существует ни одной по настоящему добротной программы – "крутилки". Встречаются лишь едва-едва работающие макеты, содержащие множество ошибок и написанные, по-видимому, в процессе освоения языка Си и\или Perl. Ни одна из таких поделок не представляет серьезной угрозы и легко распознается простейшим анализатором.

Но зачем имитировать клиента, когда под рукой есть живой экземпляр? Для "ослепления" статистических методов злоумышленники прибегают к накрутке на клиентской стороне. Ниже рассмотрены четыре таких способа и ни от одного из них пока не придумано надежной защиты.

Насколько надежен брендмаузер?

Все брандмаузеры можно разделить на три категории – фильтры пакетов, контекстные фильтры и шлюзы уровня приложений (в обиходе называемые Proxy-серверами). В свою очередь существуют фильтры следующих уровней – прикладного, транспортного, сетевого и канального.

Первые три из них могут быть введены в заблуждение злоумышленниками, подделавшими заголовки IP-, TCP- и UDP-пакетов. Канальный уровень, т.е. уровень сопряжения с физической средой, имеет смысл контролировать только в локальной сети. При модемном соединении с провайдером эта операция ничего не дает, т.к. в этом случае все пакеты на канальном уровне приходят только от провайдера, и информации о физическом адресе узла-отправителя в них не содержится.

Контекстные фильтры Контекстные фильтры работают надежнее, но области их применения ограничены, к тому же они не способны к отражению новых атак, разработанных после их появления. Обычно они используются для поиска ключевых слов, наподобие “порно”, “секс”, “наркотики” и всех других, которые строгие родители запрещают читать своим чадам.

Шлюзы Шлюзы удобны в корпоративных сетях, но совершенно ни к чему частному пользователю, правда, если у кого-то есть два компьютера, то, выделив один под Proxy-сервер, можно попытаться обезопасить другой.

Существует множество утилит, которые позволяют посылать пакеты от чужого имени и, тем самым, вводить персональные брандмаузеры в заблуждение. Впрочем, злоумышленники можно действовать и вполне легальными (с точки зрения брандмаузера) средствами. Например: пусть жертва решила посетить некий сайт X. Разумеется, брандмаузер должен пропускать все пакеты, идущие от этого узла. Теперь – предположим, что сервер, на котором расположен сайт, предоставляет бесплатный (платный) хостинг всем желающим. Тогда, атакующий, разместив на этом серевре свою программу, сможет беспрепятственно бомбить жертву пакеты, которые не сможет отфильтровать брандмаузер.

Не могу скачать файл с ftp через Proxy-сервер (Firewall)! Почему это и как быть?

Специфика работы ftp-сервера такова, что он требует для своей работы установки сразу двух соединений: одного – для обмена командами, другого – для приема или посылки данных. "Командное" соединение всегда устанавливает клиент и Proxy-сервер (firewall) его благополучно "пропускает" (см. "Интернет. Общие вопросы à Что такое Proxy-сервер и как с ним работать?"), а вот соединение для передачи данных может устанавливать либо сам сервер (активный режим) или клиент (пассивный режим).

При работе под Proxy-сервером активный режим невозможен, т.к. Proxy допускает установку лишь исходящих соединений – от клиента к серверу, но не наоборот, а Firewall может быть сконфигурирован так, чтобы блокировать входящие соединения (хотя это и не обязательно). Поэтому ftp-клиент должен быть переведен в пассивный режим. Как конкретно это сделать рассказывается в документации, прилагаемой к используемому приложению (во всяком случае, должно рассказываться), если, конечно, данное приложение поддерживает пассивный режим.

Ниже в качестве примера приведена техника конфигурирования двух популярных ftp-клиентов – FAR-менеджера и "качальщика" ReGet. Все остальные конфигурируются приблизительно тем же образом (ищите пункт "Пассивный режим" или "Passive mode" по-английски).

Не пиши мне письмо…

Многие злоумышленники настолько ленивы, что не могут найти сил для создания даже примитивного сайта "я и моя собака". Вместо этого они вставляют баннеры в письма и рассылают их сотням тысяч, а то и миллионам адресатов.

Большинство почтовых клиентов поддерживает HTML-формат и просмотр полученного письма равносилен посещению web-страницы. Разница лишь в том, что владелец настоящей web-страницы должен сидеть-дожидаться когда же к нему зайдет пользователь (ну да, жди у моря погоды!), а спамер сам инициирует заход пользователя! Причем не одного, а очень многих сразу!

Не всем спонсорам нравится, когда их рекламируют таким варварским способом, но в общем случае, с точки зрения рекламодателя спам – реклама честная. За исключением, быть может, автоматически открывающихся окон и хитроумно спрятанных страниц (они ничуть не хуже себя чувствуют и в теле письма).

Существует принципиальная, но пока никем не реализованная возможность создания автономного Интернет-червая, который, используя ошибки реализации почтовых серверов и почтовых клиентов, получал бы список пользователей, зарегистрированных на сервере и адресов из "Адресной книги". В кратчайшие сроки удалось бы разослать рекламные письма десяткам миллионов получателей, а это – деньги, большие деньги!

Пользователям, не желающим становится орудием чужого обогащения, можно порекомендовать отключить поддержку скриптов в своем почтовом клиенте. Правда, после этого некоторые письма читать станет невозможно.

Ненадежность переменных окружения

Переменные окружения очень удобны для хранения различных настроек и организации межпроцессорного взаимодействия. Единственный существенный их недостаток – абсолютная незащищенность. Бытует мнение, что удаленный пользователь не может манипулировать переменными окружения на сервере, а потому, их использование вполне безопасно.

Но это не так! Протоколы telnet, ftp и некоторые другие разрешают даже анонимному пользователю не только читать, но и изменять любые переменные окружения по своему желанию. Поэтому, полагаться на них, право же, не стоит.

Особенно опасно хранить в них пути к библиотекам или файлам данных, - в этом случае, изменив переменную окружения, злоумышленник сможет "подсунуть" программе свою "троянизированную" библиотеку, последствия использования которой очевидны. Однако, описание подобных атак, выходит за рамки протоколов http и cgi, поэтому, в этой книге подробно не рассматривается.

Необходимо скачать большой файл

Такое часто случается… В сети существует не так уж мало серверов, не поддерживающих докачку, но хранящих файлы в несколько десятков мегабайт размером. Удивительно, о чем только думают их владельцы! На низкоскоростных низкокачественных линиях скачать такие файлы принципиально невозможно, поскольку разрыв наступает раньше, чем удается получить хотя бы половину файла.

Очень часто проблема решается поиском того же самого файла на каком-нибудь другом сервере, докачку поддерживающим. В этом помогают поисковые машины или ссылки на зеркала на самом сервере. Но этот примем, к сожалению, срабатывает не всегда – существуют и такие файлы, которые находится в единственном экземпляре на единственном в сети сервере.

Пользователи давно ведут непрекращающуюся "священную войну" по поводу "чья файлокачалка лучше". Некоторым утилитам даже приписывается мифическое (мистическое?) умение докачивать с любого сервера. В действительности же – все это легенды и не более того. В "докачке" ничего загадочного нет. Некоторые серверы поддерживают специальную команду, позволяющую начать передачу файла не с самого начала, а с произвольной позиции. Если же такой команды в "лексиконе" сервера нет, – докачка невозможна в принципе, и при обрыве соединения придется начинать качать все заново. Ну, разве, что файл скэшируется где-нибудь "по дороге".

Иногда выручает перекачка через кэширующий Proxy-сервер. При первом же запросе он получает файл целиком и сохраняет его на своем диске, избавляя клиента от "радости" общения с недокачивающим сервером. Однако сервер может легко запретить кэширование (что часто и происходит) – тогда такой прием не сработает. В частности, ни одна из известных автору качалок не умеет докачивать файлы, выдаваемые cgi-скриптами. А такая потребность возникает и очень часто! Как же быть?!

Проще всего воспользоваться услугами специальных серверов, позволяющих получать файлы с ftp- и web-серверов по электронной почте. Во-первых, соединение с почтовым ящиком провайдера обычно много быстрее, чем с далеким за бугорным сервером, а, во-вторых, в этом случае большой файл автоматически разрезается на несколько частей, что упрощает его получение.

Другой, более универсальный, способ состоит в использовании промежуточного сервера с максимально быстрым каналом. Чем быстрее канал, тем больше шансов на то, что файл будет целиком передан за один раз без разрывов. Затем же, с промежуточного сервера искомый файл может быть без проблем скачен на компьютер пользователя (естественно, промежуточный сервер должен поддерживать докачку, иначе не стоит и затевать весь этот сыр-бор). Альтернативный вариант – если такой сервер территориально близок, можно подъехать к его владельцу и переписать скаченный файл на дискету (CD-ROM, Zip и т.д.), сэкономив изрядное количество времени и денег.

Для скачивания файла через промежуточный сервер можно воспользоваться либо telnet-доступом, запустив на удаленной машине ftp-клиента (см. вопрос "Разное à Что такое telnet и как с ним работать"), либо разместить на web-сервере специальный cgi-скрипт, делающий всю работу за вас (см. "Personal Web Server à  Какие сервера бесплатно предоставляют право исполнения cgi?", "Personal Web Server à

Как разместить скрипт на сервере?")

 

Родственные вопросы:

Разное à

Что такое telnet и как с ним работать

Personal Web Server à

Какие сервера бесплатно предоставляют право исполнения cgi?

Personal Web Server à

Как разместить скрипт на сервере?

Попытка скачать с WEB-сервера файл моим любимым "качальщиком" заканчивается провалом – сервер "ругается" и не "отдает" файл. В то же время, через браузер все работает нормально, но, естественно, без докачки. Почему так? (следующий)

О каких конкретно именно приложениях рассказывается в данной книге?

Хотя данная книга описывает не сами приложения, а общую концепцию работы, применимую к множеству приложений, большинство ответов содержат и готовые решения в стиле "нажми то-то, щелки там-то…" на примере конкретных приложений. Что же это за приложения?

В первую очередь те, которые использует сам автор в повседневной работе – Outlook Express 5.0, Internet Explorer 5.0, FAR 1.6, ReGet 1.4, Teleport Pro 1.28 и некоторые другие. В этом списке нет ни The Bat, ни Netscape Navigator, поскольку, во-первых, они не входят в штатную поставку операционной системы, а, во-вторых, функционально очень близки к Outlook Express\Internet Explorer и во избежание дублирования их описание опускается. В, третьих, ни The Bat, ни Netscape Navigator автору не симпатичны (моя селедка, что хочу, то и делаю).

Описаны следующие операционные системы: Windows 98 (Me), Windows NT 4.0 и Windows 2000 – все русские версии.

Об этой книге

::Краткая история …каждодневно отвечая на множество вопросов, приходящих мне по электронной почте и задаваемых лично – моими друзьями и приятелями, я задумался – а что, если собрать все свои ответы, слегка подредактировать, придав им "товарный" вид, и объединить их одной книге? Сказано – сделано, и результат этой работы лежит перед вами.

::Изложение

Возможно, даже наверняка, глубина изложения вам покажется непостоянной – от поверхностных объяснений "на пальцах" до дебрей технических подробностей, вмногие из которых с лету разберется не всякий нелегко понять начинающимй.

Да, это так! Настоящая книга не вытесана из цельного куска древесины, а собрана из мозаики различных пород – самостоятельных произведений, написанных в разное время и для разной аудитории.

Минус ли это? Да нет же, скорее наоборот! Каждый читатель, какой бы он ни был квалификации, найдет в книге что-то интересное для себя. Не книга, а прямо кладовая хочемяка!

::Стиль

Книга построена в стиле "вопрос – ответ". Ответы бывают двух видов – краткие и развернутые. Краткие ответы предваряются символом "Q" (от Question – вопрос), а развернутые – "A" (от Article – статья).

Обзор сокетов

Библиотека Winsock поддерживает два вида сокетов – синхронные (блокируемые) и асинхронные (неблокируемые). Синхронные сокеты задерживают управление на время выполнения операции, а асинхронные возвращают его немедленно, продолжая выполнение в фоновом режиме, и, закончив работу, уведомляют об этом вызывающий код.

ОС Windows 3.x поддерживает только асинхронные сокеты, поскольку, в среде с корпоративной многозадачностью захват управления одной задачей "подвешивает" все остальные, включая и саму систему. ОС Windows 9x\NT поддерживают оба вида сокетов, однако, в силу того, что синхронные сокеты программируются более простоще, чем асинхронные, последние не получили большого распространения. Эта статья Наш рассказ посвящена исключительно синхронным сокетам (асинхронные – тема отдельного разговора).

Сокеты позволяют работать со множеством протоколов и являются удобным средством межпроцессорного взаимодействия, но мы будет говорить в данной статье речь будет идти только о сокетах семейства протоколов TCP/IP, использующихся для обмена данными между узлами сети Интернет. Все остальные протоколы, такие как IPX/SPX, NetBIOS по причине ограниченности объема журнальной статьи рассматриваться не будут.

Независимо от вида, сокеты делятся на два типа – потоковые и дейтаграммные. Потоковые сокеты работают с установкой соединения, обеспечивая надежную идентификацию обоих сторон и гарантируют целостность и успешность доставки данных. Дейтаграмные сокеты работают без установки соединения и не обеспечивают ни идентификации отправителя, ни контроля успешности доставки данных, зато они заметно быстрее потоковых.

Выбор того или иного типа сокетов определяется транспортным протоколом на котором работает сервер, - клиент не может по своему желанию установить с дейтаграммным сервером потоковое соединение.

Замечание: дейтаграммные сокеты опираются на протокол UDP, а потоковые на TCP.

Описание утилиты MTUSpeed

 

Когда дзэнского наставника Бо-чжана спросили о  том, как он представляет себе поиски природы Будды,  он ответил: "Это похоже  на то, как если бы кто-то ездил на быке в поисках этого быка.

Неспециалистам тонкую настройку TCP/IP-параметров (см. "Оптимизация соединения с Интернет") удобнее выполнять не "Редактором Реестра", а какой-нибудь специальной утилитой с более дружелюбным интерфейсом.

Одной из таких утилит и является MTUSpeed, бесплатная копия которой может быть скачена со следующего сайта: http://www.mjs.u-net.com/download.htm. Она хорошо себя "чувствует" под всеми операционными системами семейства Microsoft Windows – Windows 95, Windows 98, Windows NT, Windows 2000, Windows Me, исключая лишь архаичную Windows 3.11 и более ранние версии (в них TCP/IP реализован по-другому).

Под Windows NT и Windows 2000 MTUSpeed требует для своего запуска прав администратора, в противном случае сообщает о критической ошибке, отказываясь работать даже в режиме просмотра параметров без их модификации.

Оптимизация соединения с Интернет

Повременная оплата соединения с Интернет горячо любима всеми нерадивыми провайдерами, кривые руки которых не могут как следует отстроить свое хозяйство и обеспечить надлежащую скорость обменабыструю связь. Клиент получает меньшее количество информации за то же время и в результате дольше торчит в Сети. А время – деньги. В самом, что ни на есть прямом смысле этого слова. Вот, если бы оплата шла за каждый скаченный мегабайт – будьте покойны – все бы летало как реактивный бомбардировщик с ракетой класса "Буш – Садам Хусейн", но многие ли провайдеры поддерживают такой тарифный план?

Ладно бы, все заключения ограничивались одной скоростью (в смысле полным отсутствуем таковой). Так нет же – соединение может быть нестабильным, часто обрываться, а то и не работать совсем – некоторые сайты могут не грузиться, ругаясь на загадочную ошибку "TTL Bug", закачка по ftp может вообще не "фэтэпить"… да разве ж перечислишь все злоключения, терзающие интернетчика!

Конечно, радикальнее всего – сменить провайдера, но это не всегда возможно. В больших городах счет провайдеров идет на десятки, а в провинциях он, монополист окаянный, нередко бывает в единичном экземпляре, что вдвойне хуже – монополисту незачем заботиться о своих клиентах – все равно они никуда не убегут, каким бы скверным качество обслуживания ни было. Да и куда бежать-то?

???? Рисунок "карикатура" Изобразить провайдера в виде спрута (щупальца – коммуникации), удушающего своими щупальцами пользователей.

Впрочем, в клинических случаях стоит задуматься о поиске провайдера в соседнем городе. Как ни парадоксально, но даже с учетом междугородней оплаты за телефон, иногда это выходит в несколько раз дешевле. Правда-правда! Именно так и приходиться поступать автору этой книги.

Менее радикальная мера – настроить параметры TCP/IP соединения на максимальную производительность, что дает прирост скорости обмена от 30% до 200% и избавляет от большей части разрывов. Остаются лишь фатальные сбои и зависания самого провайдера, побороть которые с клиентской стороны принципиально невозможно.

Существует множество программ, например, MTUSpeed (http://www.mjs.u-net.com/download.htm), (см. "Описание утилиты MTUSpeed") как раз и предназначенных для этой цели. Одна беда – ни одна из них не работает в полностью автоматическом режиме – все они всего лишь оболочки над системным реестром Windows, – так сказать, комфортный инструмент внесения в него изменений. Но легко сказать "вносить"! А как? Множество малопонятных и ничего не говорящих параметров, порой вообще без каких либо пояснений. Попытки же разобраться во всем "методом тыка" скорее еще больше снизят скорость, чем ее увеличат. Тут без хорошего руководства не обойтись!

Первое, чем мы займемся, – попытаемся устранить разрывы TCP-соединений (не путать с разрывами модемных соединений!). Они довольно многочисленны и разнообразны, а причинной их возникновения может быть и провайдер, и один из маршрутизаторов в длинной цепочке передачи пакетов, и сам удаленный сервер, с которым, собственно, и установлено соединение, и… да мало ли еще кто!

Начнем с провайдера. Итак, представим себе следующую картину (маслом по дереву): модем не бросает трубку, но все установленные соединения вдруг обрываются и после этого ни к одному серверу подключиться не удается. Положение спасает лишь реконнект – отключение от Интернет и повторный заход вновь. Мало того, что это медленно, да к тому же есть риск, нарваться на глухую "бизю" – если что освободившийся телефонный номер мгновенно в это время займет другой клиент (особенно если у провайдера острый недостаток входных номеров). В зависимости от кривости и нагрузки сервера такие разрывы могут происходить и эпизодически, и по несколько раз в час, а то и в даже каждую минуту, представляя собой настоящую превращая работу с Интернетом в настоящую пытку.

Причина их возникновенияПричина разрывов, скорее всего в том, что у провайдера неправильно настроен DHCP-сервер. Тот самый, что выдает пользователям IP-адреса. Как и любой собственник, он выдает отдает их не на совсем, а на некоторое, под час весьма непродолжительное, время. Если клиент (точнее его операционная система) по каким-то там причинам (сеть тормознула, крыша поехала, пакет кто-то прибил) не успеет продлить срок аренды, его IP-адрес будет безжалостно отнят. А?



когда же наконец,

клиент наконец "проснется" и пошлет петицию DHCP-серверу, тот смилостивится и отпустит с барского плеча еще один IP-адрес, типа, на, пользуйся на здоровье! И вроде бы все ничего, да вот не понимает "народная" Windows 95\98 таких извращений! Она ожидает получения IP-адреса всего лишь один раз – на стадии подключения к провайдеру.

Вернее, Получить-то IP-адрес она получает, но вот включить его в таблицу маршрутизации "забывает" и ни один отправляемый пакет не может уйти дальше своего компьютера. Приходится, взяв инициативу в свои руки, исправлять положение самостоятельно.

Прежде необходимо в сеансе MS-DOS запустить утилиту ipconfig

(входит в штатную поставку Windows) и посмотреть какой у нас IP-адрес. Если он выглядит как "0.0.0.0" – значит, DHCP-сервер флиртует с операционной системой (в смысле – висит глухо). Если же IP равен "127.0.0.1", – сети напрочь нет и тут что-то серьезное. А вот любое другое значение указывает на верный IP-адрес который необходимо добавить в голову таблицы маршрутизации, передав его утилите route из штатной поставки Windows следующим образом: "route.exe ADD 0.0.0.0 MASK 0.0.0.0 Ваш IP METRIC 1". Попробуйте установить соединение с каким-нибудь сервером – теперь все должно заработать.

Работает? Вот и славненько! Однако восстановить соединение без реконнекта – это только полдела. Хорошо бы устранить и причину этих разрывов – ведь не все же сервера поддерживают докачку и частые разрывы создают большие проблемы (см. "Получение файлов à

Необходимо скачать большой файл, но соединение постоянно рвется, а сервер не поддерживает "докачки"…").

В идеальном случае следовало бы взять провайдера за ухо и с помощь дяди прокурора ткнуть носом в DCHP-сервер, объясняя ему, что клиент не должен оплачивать некомпетентность инженерного персонала поставщика сетевых услуг за свой счет. Да только в нашей стране такой прием вряд ли возымеет действие… Приходится выкручиваться самостоятельно, но на клиентской стороне очень мало что можно сделать, да и то только программистам. Единственное, доступное "простым смертным" решение, – перейти на Windows 2000 - с этой проблемой она справляется на раз!



??? Рисунок "карикатура" Милиционер держит провайдера за ухо одной рукой, а другой рукой показывает на сервер. Вокруг стоят пользователи, по лицам которых видно, что одобряют такое развитие событий.

Второй по счету источник неприятностей – эта пресловутая ошибка "TTL bug", приводящая к невозможности установки соединения. Дело в том, что во избежание засорения сети "Летучими Голландцами", то есть, попросту говоря, зацикленными пакетами, каждый из них имеет ограниченный срок существования, указанный в заголовке и измеряемый количеством промежуточных узлов, которые может посетить пакет. Если пакет не будет доставлен за это время, он "прибивается" очередным маршрутизатором c посылкой отправителю соответствующего "похоронного" уведомления.

Чем больше транзитных узлов расположено между отправителем и получателем, тем дольше пакеты добираются из одного конца в другой. К счастью, время жизни пакета (аббревиатура TTL так и расшифровывается Time To Live

– время жизни) очень легко изменить, – запустите Редактор Реестра, предварительно зарезервировав сам реестр, и откройте ветвь HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\DefaultTTL для ОС Windows NT\2000 и HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP\DefaultTTL для Windows 9x - она-то и управляет сроком жизни пакетов. По умолчанию он равен 32 узлам, но, как показывает практика, в некоторых случаях этого явно недостаточно и стоит увеличить его по крайней мере вдвое. (Можно и больше – но от этого лучше не станет, хотя и хуже – тоже). После внесения изменений в реестр следует перезагрузится, заново войти в сеть и проверить – возымело ли это какое-то действие.

Возымело? Так… соединение с ftp-сервером установить удается, но вот закачка не работает, хоть убей – сколько ни жди, а индикатор прогресса издевательски остается на нуле процентов. Абыдно, понимаешь! Что ж, будем лечить! Попробуйте для начала включить опцию с интригующим названием Распознавание Черной Дыры – "Black Hole Detect".



Зачем она нужна? А вот зачем – хитрая Windows, стремясь увеличить скорость передачи данных, пытается вычислить максимальный размер пакета, который бы обрабатывался пересылающими его маршрутизаторами без разрезания. Разрезание (или, говоря профессиональным языком, фрагментация) ощутимо снижает скорость соединения, особенно если пакет дробится на две неравные половины. Например, путь компьютер клиента пытается передать пакет размером в 576 байт, но один из маршрутизаторов в цепочке "умеет считать" только до 512, и разрезает пакет на два, причем во второй попадает "хвостик" из 64 байт, плюс… заголовок, занимающий от 40 и более байт. В итоге – КПД второго пакета составит всего лишь 50%, что очень нехорошо!

Если Windows видит, что избежать фрагментации не удастся, она уменьшает размер пакета так, чтобы он без проблем прошел сквозь все маршрутизаторы одним куском. Но не проще было бы сразу задать минимальный размер? Нет, и вот почему – чем меньше пакет, тем выше накладные расходы на его пересылку (заголовок тоже ведь занимает место) и тем больше пакетов требуется переслать для передачи того же объема информации.

Умение Windows подбирать максимальный размер не фрагментируемого пакета всем хорошо, да вот беда – не всегда это работает. Некоторые, не слишком демократичные маршрутизаторы, получив слишком длинный (по их мнению) пакет с пометкой "не фрагментировать", прибивают его на месте безо всяких уведомлений! Windows же, не подозревая, что посланный ею пакет погиб, ждет отклика от сервера. Долго ждет… А затем, там и не дождавшись, вновь посылает тот же самый пакет. И все повторяется! Вот этот-то недемократичный маршрутизатор и называется "Черной дырой"!

Включение опции "Black Hole Detect" активирует хитроумный алгоритм распознания "Черных Дыр" для обхода их стороной. Но за все приходится платить, и такое детектирование несколько снижает общую производительность. Несильно – но все ж таки! Поэтому прибегать к нему следует только в крайних случаях – когда действительно что-то не работает – соединение есть, а трансфер (передача данных) на нуле.



Запустите "Редактор Реестра" и откройте ветвь HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP для Windows 95\98 и HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters для Windows NT\2000. Найдите или при необходимости создайте двоичный параметр PMTUBlackHoleDetect для Windows 95\98 и EnablePMTUBHDetect для Windows NT\2000. Теперь присвойте ему значение "1" и перезагрузитесь.

Что? Все равно не работает? Хм… Боги, боги, зачем вы так несправедливы?! Ничего не остается, как расстаться с надеждой пересылки пакетов максимального размера и перейти на размер, обязательный (ну, формально обязательный) для всех маршрутизаторов – 576 байт. Для этого в той же самой ветке реестра найдите (создайте) двоичный параметр PMTUDiscovery для Windows 95\98, а для Windows NT\2000 – EnablePMTUDiscovery и присвойте ему значение "0". Перезагрузитесь. Ну, Должно же это, наконец, заработать!

Кстати, с типом двух этих ключей творится что-то непонятное. Документация от Microsoft утверждает, что он (тип в смысле) должен представлять собой двойное слово, то бишь, по-английски DWORD. Однако у автора под Windows 2000 закачка по ftp начинает работать только после создания указанных ключей типа одиночного слова (WORD), а DWORD-ключи операционная система упорно игнорирует. Мистика какая-то…

Теперь поговорим об оптимизации соединения. Оптимизация – дело непростое. Это не то, что работает система или нет. Работать-то она работает, вот только как? Тривиальным измерением скорости скачиваемого файла ничего выяснить не удастся. График скорости только в исключительных случаях (и на хороших каналах) представляется прямой линией. Гораздо чаще он напоминает трассу Урюпинск – Ханты-Мансийск: сплошные бугры, колдобины, ямы, словом, крайне испещренная местность. Говорить о средней скорости можно только в переносном смысле, тем паче, что она может сильно варьироваться в зависимости от времени суток, сервера, с которым установлено соединение, количества осадков, выпавших в Африке, да мало ли еще от чего!



До начала экспериментов потребуется собрать статистику работы сети за некоторое время, скажем за неделю. В этом поможет программа Net Medic (www.download.ru) или любая другая, аналогичная ей. Затем, после внесения изменений в настройки системы, собирается другая статистика, опять-таки на протяжении семи - десяти дней, и сравнивается с предыдущей – изменилось ли что и если да, то в какую сторону?

Дело это, конечно, медленное, но иного способа тонкой настройки нет. Необходимо убедиться в увеличении скорости обмена со всеми серверами и во все времена суток, то есть, найти компромиссный оптимум. Не все, что хорошо для одного случая, так же хорошо подходит для другого. Взять ту же фрагментацию уже рассмотренную выше. Автоматическое определение подходящего размера пакета не всегда увеличивает скорость соединения, нередко оно ее уменьшает, под час весьма значительно – автоматическое определение занимает какое-то время, увеличивая накладные расходы и снижая КПД. Имеет смысл попробовать найти оптимальное значение вручную.

Первым делом необходимо указать Windows, что требуется использовать не максимально возможный, а заранее оговоренный размер пакета. Для этого установите значение ключа PMTUDiscovery (EnablePMTUDiscovery) в ноль. Затем задайте желаемый размер пакета. По умолчанию он равен 576 байтам – это значение по стандарту должны поддерживать все маршрутизаторы, да только кто эти стандарты соблюдает? Вот и встречаются узлы, обрабатывающие пакеты размером не более 512, 522, 556,… байт. В принципе, можно поставить 500 и не мучаться проблемой выбора, но так неинтересно. Разве не заманчиво методичным подбором байтов оптимизировать соединение до конца?

Размер пакетов для Windows 95\98 задается ключом MaxMTU, находящимся в той же самой ветке реестра, что и предыдущие ключи. С Windows NT\2000 посложнее, – чтобы выяснить местоположение ключа MTU необходимо определить идентификатор используемого адаптера. Перечень всех адаптеров компьютера содержится в ключе Adapters ветки HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters. Как правило, большинство персональных компьютеров обходятся лишь одним адаптером – контроллером удаленного доступа (нет, это не плата расширения, это драйвер такой) и буридановой проблемы выбора нужного идентификатора не стоит. Идентификатор же – это такое длинное малопонятное число, например, "{20692835-7194-467A-A2DC-0FAE23F0A70D}".



Запоминаем (записываем) его и открываем ветку HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ИдентиификаторАдаптера\Parameters\Tcpip (В Windows 2000 – HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Parameters\Tcpip\Interfaces\ИдентификаторАдаптера)

Среди прочего хлама здесь должен находится только что запомненный идентификатор адаптера, а в нем – ключ MTU, содержащий в себе максимальный размер пакета в байтах. Если такого ключа нет, его необходимо создать. Тип ключа MTU в обоих случаях соответствует двойному слову (DWORD).

Второй бастион оптимизации – размер TCP-окна. Чем "шире" окно, тем выше производительность, но в то же время больше издержки на повторные пересылки: случись какой сбой – не до конца заполненное окно очиститься и придется его "набивать" с самого начала. К тому же баловство с неумеренно широкими окнами часто приводит к образованию заторов в сети – промежуточные узлы не успевают обрабатывать сыплющийся на них поток пактов и все начинает жутко тормозить. Причем не только у виновника несчастья, но и у других ни в чем не повинных пользователей.

Ширина TCP-окна должна быть кратна размеру пакета за вычетом длины заголовка и превосходить его по крайне мере в четыре – шесть раз. В некоторых случаях наивысшая производительность достигается при ширине окна в 10х-12х

(где х – размер пакета без заголовка, называемый так же "квиком"), а то и больше. Некоторые отчаянные головы пробуют даже большие значения и утверждают, что все работает "на ура!", но у автора такие значения не показывают чудес производительности, поэтому, подтвердить сказанное он не берется. Размер заголовка непостоянен и варьируется от 40 до 60 байт – не забываете об этом при поиске оптимальной ширины окна!

Для изменения размеров окна откройте ветвь реестра HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP для Windows 95\98 и HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters для Windows NT\2000. Найдите или при необходимости создайте двоичный параметр (двойное слово, DWORD) DefaultRcvWindow для Windows 95\98 и TcpWindowSize для Windows NT\2000. Присвойте ему желаемое значение (например, "3680", если размер пакета, заданный ключом MTU равен 500 байт – (500 – 40) * 8 = 3/600) и перезагрузитесь.



Оцените, как изменилась скорость соединения. Если она возросла – увеличьте ширину окна еще на один квик (не байт!), если уменьшилась – сузьте окно, а если осталась без изменений, расширьте окно на пару квиков. Так, в конце – концов, будет найдено оптимальное значение. Интернет - гуру утверждают, что оптимум ширины окна зависит от загруженности провайдера и сильно колеблется в течение суток. При максимальной загруженности в "час пик" окно лучше прикрывать, оставляя лишь узкую щель (3х-4х), а ночью, когда все нормальные юзеры давно баиньки и канал полностью свободен, – широко распахивать обе створки (10x и выше). Никаких суточных вариаций у своих провайдеров автор не замечал, но готов поверить, что в некоторых случаях они могут иметь место и гуру не врут.

Помимо выше упомянутых опций, реестр Windows содержит множество других значений, относящихся к TCP/IP, но рассказывать о каждом из них было бы слишком утомительно, да и нецелесообразно – для этого пришлось бы написать отдельную книгу, страниц эдак на пятьсот.

Родственные вопросы:

Описание утилиты MTUSpeed (следующий)

У меня часто случается непонятный глюк….

Приложения à Исходный текст kf.bat

Получение файлов à Необходимо скачать большой файл, но соединение постоянно рвется, а сервер не поддерживает "докачки"…

Отсутствие фильтрации

Ошибки фильтрации пользовательского ввода (или полное отсутствие фильтрации, как таковой) – характеры в первую очередь для Perl, штатные функции которого слишком вольно интерпретируют переданные им аргументы и допускают множество умолчаний. К примеру, программист хочет открыть и вывести на экран запрошенный пользователем файл и создает код наподобие следующего:

open(f,$filename);

while(<f>)

{

print;

}

Ошибки очевидны: во-первых, злоумышленник может получить содержимое любого файла системы, доступного скрипту, передав запрос наподобие "/etc/passwd", а, во-вторых, указав в имени файла символ конвейера ("|"), он сможет запустить любое доступное скрипту приложение и увидеть в браузере результат его работы (например, "echo "+ +" >/.rhosts" позволит подключиться по протоколу rlogin без ввода пароля).

Но не всякая уязвимость так очевидна! Попробуйте найти ошибку в следующей реализации того же примера, усиленного принудительным добавлением расширения ".html" к имени открываемого файла:

open(f,$filename.".html");

while(<f>)

{

print;

}

На первый взгляд, злоумышленник не сможет ни открыть, ни запустить никакие другие файлы, кроме HTML. Но это не так! Дело в том, что ядро Perl не трактует символ нуля как конец строки и обрабатывает его точно так, как и все остальные символы. В то же время, компоненты Perl-а, написанные на Си, интерпретируют ноль как конец строки! Таким образом, для обхода защиты достаточно передать строку, содержащую на конце "\0" (например, "/etc/passwsd\0")! Помимо этого, функция open допускает возможность одновременного запуска множества файлов, - передача строки "|calc.exe|sol.exe|freecell.exe|" приведет к запуску приложений "Калькулятор", "Пасьянс Косынка" и "Пасьянс Свободная ячейка", независимо от того {<<< убрать "?"}будет ли добавлено в конце расширение ".html" или нет.

Даже "open(f, "/home/www/pages/".$filename."html")" не уберегает от использования нескольких символов конвейера, и тем более не предотвращает обращения к вышележащим каталогам, хотя на первый взгляд такая защита может показаться неприступной.

Решение проблемы заключается в фильтрации данных – удалении из ввода пользователя всех потенциально опасных символов или выдачи сообщения об ошибке при их обнаружении. Таких символов довольно много и все они (что очень неприятно) специфичны для каждой функции. Например, у open

опасны следующие символы и их комбинации:

·         ">",">>" и "+>" открытие файла для записи, дозаписи и перезаписи соответственно

·         "+<" открытие файла для записи и чтения

·         "|" и "`" запуск программы

·         "-" чтение со стандартного ввода

·         "&" обращение к файловому дескриптору (handle)

·         ".." и "/" – обращение к вышележащим каталогам

·         "\0" – задание конца строки

О возможности обращения к файлу по его дескриптору следует сказать особо. Пусть существует некоторый секретный файл (например, файл паролей или номеров кредитных карт), который открывается в начале работы программы, а затем на экран выводится содержимое файла, запрошенного пользователем, до закрытия секретного файла. Если злоумышленнику доступен исходный тест скрипта или хотя бы приблизительно известны манеры его разработчика, он сможет прочитать секретный файл с помощью самой программы, передав вместо имени его дескриптор! Для чего достаточно воспользоваться клонированием "x&filehandle" или созданием псевдонимов "x&=filehandle", где "x" обозначает режим доступа – "<" для чтения и ">" для записи. Следующий пример как раз и демонстрирует эту уязвимость.



open (psw,"passwd") || die;   #открытие файла паролей

#...некоторый код...

print "введите имя файла:"    #запрос имени отображаемого файла

$filename=<>; chop $filename;

if ($filename eq "passwd")    #проверка имени на корректность

{print "Hello,Hacker!\n";die;}

open(f,$filename) || die;     #вывод файла на экран

while(<f>)

{

print;

}

Если злоумышленник введет "<&=psw" или "<&psw", в окне собственного браузера он увидит содержимое файла паролей!

Аналогичным путем можно ознакомится и содержимым лексемы DATA, доступной через одноименный дескриптор и очень часто содержащей информацию, не для посторонних глаз. (Замечание: не все реализации Perl позволяют клонировать манипулятор DATA, и, в общем-то, они и не должны этого делать, но пренебрегать такой угрозой не стоит).

Много трудностей и непонимания вызывает интерполяция строк, заключенных в двойные кавычки. Язык Perl может автоматически подставлять вместо имени переменной ее содержимое, а вместо имени функции – возвращенный ею результат. Последняя возможность считается особо опасной, т.к. на первый взгляд позволяет злоумышленнику вызывать любые команды Perl и даже выполнять внешние программы с помощью функций exec, eval и многих других. Практически все руководства по написанию скриптов настоятельно рекомендуют фильтровать символы "@", "$", "[]", "{}", "()", и разработчики (даже опытные!) в большинстве своем послушно следуют этому требованию!

На самом деле никакой опасности нет – интерполяция строк выполняется только в текстах программ и никогда в значениях переменных. Наглядно продемонстрировать это утверждение позволяет следующий пример (предполагается, что во втором случае с клавиатуры вводится : "${\(print '>Hello')}"; наклонным шрифтом выделен вывод программы на экран):

$filename="${\(print '>Hello')}";         $filename=<>;



print "$filename";                        print "$filename";

>Hello1                                                                                                 ${\(print '>Hello')}

Замены имени функции на результат ее работы в пользовательском вводе не произошло! Независимо от того, заключена ли введенная строка в двойные кавычки или нет, она всегда отображается на экране такой, какая есть, без каких бы то ни было преобразований. Фильтровать символы интерполяции не нужно – их использование злоумышленником не возымеет никакого эффекта! Тем более, что "собака" является неотъемлемой частью адреса электронной почты и отказ от нее просто невозможен.

Так же напрасны опасения относительно обратной кавычки – "`". В документации по языку Perl сказано, что строка, заключенная в обратные кавычки, интерпретируется как команда операционной системы, которой она и передаются на выполнение. Да, это действительно так, но только по отношению к строкам текста программы, а не содержимому скалярных переменных. Т.е. конструкция "$a=`type /etc/passwd`;" занесет в переменную $a содержимое файла "/etc/passwd", но "$a=<>;" никогда не приведет к подобному результату – чтобы ни ввел пользователь, Поэтому, символ обратной кавычки никакой угрозы не несет и совершенно ни к чему его фильтровать.

Гораздо больше проблем связано с вызовом внешних программ, работающих с данными, введенными пользователем. Заведомо невозможно узнать - какие символы потенциально опасны, а какие нет. Большинство приложений помимо документированных функций имеют множество недокументированных особенностей или хуже того – ошибок реализации.

Никогда нельзя быть абсолютно уверенным, что ваш почтовый агент не воспримет вполне легальный адрес назначения как собственный ключ или управляющее сообщение. Даже если отмахнутся от подобных экзотических угроз, составление списка фильтруемых символов по-прежнему будет представлять проблему, т.к. из документации не всегда бывает ясно как поведет себя приложение, встретив ту или иную комбинацию символов. Помимо явно опасного перенаправления ввода-вывода, вызова конвейера, использования символов-джокеров, символов-разделителей и переноса строк, иногда приходится сталкиваться с такими неожиданными "подлостями" как, например, возможность автоматического развертывания UUE-сообщений.



Лучше всего – полностью отказаться от вызова внешних программ, реализуя все необходимое самостоятельно. Ту же процедуру отправки писем не сложно выполнить и средствами самого языка Perl, без каких либо обращений к SendMail-у или другому МТА, и файлы на диске искать не вызовом grep, а собственноручно написанным модулем. Усложнение программы компенсируется увеличением ее надежности и безопасности.

Очень важно понимать, что фильтрацию ввода нужно осуществлять только на серверной, но ни в коем случае только на клиентской стороне! Часто эту операцию поручают Java-апплетам, а то и вовсе Java-скриптам, не подумав, что они могут быть модифицированы или блокированы злоумышленником, поскольку исполняются на его собственной машине и не существует никакого способа отличить запрос, посланный Java-скриптом от запроса, посланного самими злоумышленников в обход скрипта. Java может быть полезна лишь для быстрого уведомления клиента об ошибке ввода, но не более того!

Outlook Express

Чтобы внести неугодного вам адресата в "черный список" достаточно подвести курсор к полученному от него сообщению и в меню "Сообщение" выбрать пункт "Блокировать отправителя". Отныне все письма, полученные от данного лица, будут автоматически перемещаться в папку "Удаленные".

Для отмены блокировки (или просмотра списка блокируемых отправителей) выберите в меню "Сервис" пункт "Правила для сообщений" à

"Список блокируемых отправителей". Появится диалоговое окно "черного списка" с интуитивно-понятными кнопками "Добавить", "Удалить", "Изменить".

Кнопка "Добавить" позволяет включать в "черный список" не только отдельные адреса, но и целые домены – стоит лишь указать имя (IP-адрес) почтового сервера, например, chat.ru, как все, отправленные с его помощью письма, будут автоматически отправляться в папку "Удаленные".

При необходимости задания более гибких критериев воспользуйтесь "Правилами для сообщений" ("Сервис" à

"Правила для сообщений" à

"Почта"). Появится диалог следующего вида:

1. Выберите условия для данного правила:

Искать сообщения, содержащие адресатов в поле "От:"

Искать сообщения, содержащие заданные слова в поле "Тема:"

Искать сообщения, содержащие заданные слова:

Искать сообщения, содержащие адресатов в поле "Кому:"

Искать сообщения, содержащие адресатов в поле "Копия:"

Искать сообщения, содержащие адресатов в поле "Кому:" и "Копия:"

Искать сообщения с пометкой важности

Искать сообщения, полученные с определенной учетной записи

Искать сообщения, размер которых превышает заданный размер

Искать сообщения с вложениями

Искать безопасные сообщения

Все сообщения

2.

Выберите действия для данного правила:

Переместить в заданную папку

Скопировать в заданную папку

Удалить

Переслать адресатам

Выделить цветом

Пометить

Пометить как прочитанное

Пометить сообщение как просмотренное или пропущенное

Ответить заданным сообщением

Прекращение выполнения дополнительных правил

Не загружать с сервера

Удалить с сервера

3. Описание правила (для правки щелкните по подчеркнутой величине)

4. Название правила.

Для создания правила отметьте галочкой соответствующие критерии окна № 1. Например, "Искать сообщения, содержащие адресатов в поле От" и "Искать сообщения, содержащие заданные слова в поле Тема". Затем в окне № 2 выберите желаемую реакцию на получение таких писем. Например, "Удалить". Можно выбрать несколько не взаимоисключающих действий, скажем, "Удалить" и "Ответить заданным сообщением". Действия "Не загружать с сервера" и "Удалить с сервера" исключают все остальные.

В окне № 3 "Описаний Правил" появится текст приблизительного следующего содержания:

Применить данное правило при получении сообщения

Искать сообщения, содержащие адресатов в поле "От:"

и Искать сообщения, содержащие заданные слова в поле "Тема:"

Удалить

и Ответить заданным сообщением

Подчеркнутые строки представляют собой гиперссылки – если подвести к ним мышь и нажать, появится диалог, задающий их свойства. Попробуйте нажать на ссылку "содержащие адреса" и посмотрите, что из этого получится.

На экране появляется диалог "Выбор получателей". Введите один или несколько адресов для занесения их в "черный список", нажимая после каждого адреса кнопку "Добавить", а для удаления, соответственно, – "Удалить". Копка "Параметры" позволяет уточнить следует ли искать письма, содержащие все введенные адреса одновременно или же любой

один из них, а может, нужно искать письма, не содержащие ни одного из перечисленных адресов?

Диалог "Ввод ключевых слов" в первом приближении аналогичен предыдущему – только вместо адресов теперь вводятся ключевые слова по одному, а "Параметры" позволяют уточнить – следует ли искать письма, содержащие все эти слова или же только одно из них.



Наконец, ссылка "Сообщение" открывает стандартный диалог открытия файла в котором необходимо указать путь к файлу сообщения, которое будет автоматически посылаться отправителю нежеланного сообщения.

Последняя гиперссылка "и" задает условия совпадения критериев – искать сообщения, содержащие таких-то адресатов и такую-то тему в заголовке, либо же искать сообщения, содержащие таких-то адресатов, или такую-то тему в заголовке.

Последнее, четвертое окно, задает название правила – количество правил не ограничено, но их имена должны отличаться.

Нажатие "ОК" создает фильтр по данному правилу и автоматически включает его в работу. Если же один или более критериев не были указаны, Outlook выделит их красным цветом и обиженно пискнет, заставляя продолжить формирование фильтра.

Для просмотра списка активных и существующих фильтров выберите в меню "Сервис" пункт "Правила для сообщений" à

"Список блокируемых отправителей" и перейдите к вкладке "Почта".

Любой фильтр можно применить и к ранее полученным сообщениям – что бывает полезно для очистки папки "Входящие" от накопившегося в ней спаммерского хлама – выберете нужную папку и нажмите "Применить".

Грамотно настроенные фильтры способны разгрузить пользователя от большей части работы по уходу за своими папками и содержанию их в чистоте и порядке. Пусть, к примеру, рассылка от "Городского Кота" помещается в одну папку, сообщения от друзей – в другую, а депеши от Big Boss-a выделяются цветом, дабы не пропустить их среди прочего потока писем… и.д. – ну чем не сказка?

Родственные вопросы:

Как установить подлинный адрес отправителя письма?"

Как удалить сообщение из почтового ящика, не принимая его на свой компьютер?

Первый шаг, второй, третий…

Для работы с библиотекой Winsock 2.х в исходный тест программы необходимо включить директиву "#include <winsock2.h>", а в командной строке линкера указать "ws2_32.lib". В Microsoft Visual Studio для этого достаточно нажать <Alt-F7>, перейти к закладке "Link" и к списку библиотек, перечисленных в строке "Object/Library modules", добавить "ws2_32.lib", отделив ее от остальных символом пробела.

Перед началом использования функций библиотеки Winsock ее необходимо подготовить к работе вызовом функции "int WSAStartup (WORD wVersionRequested, LPWSADATA lpWSAData)" передав в старшем байта слова wVersionRequested номер требуемой версии, а в младшем – номер подверсии.

Аргумент lpWSAData должен указывать на структуру WSADATA, в которую при успешной инициализации будет занесена информация о производителе библиотеки. Никакого особенного интереса она не представляет и прикладное приложение может ее игнорировать. Если инициализация проваливается, функция возвращает ненулевое значение.

 

Второй шаг – создание объекта "сокет". Это осуществляется функцией "SOCKET socket (int af, int type, int protocol)" Первый слева аргумент указывает на семейство используемых протоколов. Для Интернет - приложений он должен иметь значение AF_INET.

Следующий аргумент задает тип создаваемого сокета – потоковый

(SOCK_STREAM) или дейтаграммный (SOCK_DGRAM) (еще существуют и сырые сокеты, но они не поддерживаются Windows – см раздел "Сырые сокеты").

Последний аргумент уточняет какой транспортный протокол следует использовать. Нулевое значение соответствует выбору по умолчанию: TCP – для потоковых сокетов и UDP для дейтаграммных. В большинстве случаев нет никакого смысла задавать протокол вручную и обычно полагаются на автоматический выбор по умолчанию.

Если функция завершилась успешно она возвращает дескриптор сокета, в противном случае INVALID_SOCKET.

Дальнейшие шаги зависит от того, являет приложение сервером или клиентом. Ниже эти два случая будут описаны раздельно.

Клиент: шаг третий – для установки соединения с удаленным узлом потоковый сокет должен вызвать функцию "int connect (SOCKET s, const struct sockaddr FAR* name, int namelen)". Датаграмные сокеты работают без установки соединения, поэтому, обычно не обращаются к функции connect.

Примечание: за словом "обычно" стоит один хитрый примем программирования – вызов connect позволяет дейтаграмному сокету обмениваться данными с узлом не только функциями sendto, recvfrom, но и более удобными и компактными send и recv. Эта тонкость описана в Winsocket SDK и широко используется как самой Microsoft, так и сторонними разработчикам. Поэтому, ее использование вполне безопасно.

Первый слева аргумент – дескриптор сокета, возращенный функцией socket; второй - указатель на структуру "sockaddr", содержащую в себе адрес и порт удаленного узла с которым устанавливается соединение. Структура sockaddr используется множеством функций, поэтому ее описание вынесено в отдельный раздел "Адрес раз, адрес два…". Последний аргумент сообщает функции размер структуры sockaddr.

После вызова connect система предпринимает попытку установить соединение с указанным узлом. Если по каким-то причинам это сделать не удастся (адрес задан неправильно, узел не существует или "висит", компьютер находится не в сети), функция возвратит ненулевое значение.

Сервер: шаг третий – прежде, чем сервер сможет использовать сокет, он должен связать его с локальным адресом. Локальный, как, впрочем, и любой другой адрес Интернета, состоит из IP-адреса узла и номера порта. Если сервер имеет несколько IP адресов, то сокет может быть связан как со вмести ними сразу (для этого вместо IP-адреса следует указать константу INADDR_ANY равную нулю), так и с каким-то конкретным одним.

Связывание осуществляется вызовом функции "int bind (SOCKET s, const struct sockaddr FAR* name, int namelen)" Первым слева аргументом передается дескриптор сокета, возращенный функций socket, за ним следуют указатель на структуру sockaddr и ее длина (см. раздел "Адрес раз, адрес два…").



Строго говоря, клиент также должен связывать сокет с локальным адресом перед его использованием, однако, за него это делает функция connect, ассоциируя сокет с одним из портов, наугад выбранных из диапазона 1024-5000. Сервер же должен "садиться" на заранее определенный порт, например, 21 для FTP, 23 для telnet, 25 для SMTP, 80 для WEB, 110 для POP3 и т.д. Поэтому ему приходится осуществлять связывание "вручную".

При успешном выполнении функция возвращает нулевое значение и ненулевое в противном случае.

Сервер: шаг четвертый – выполнив связывание, потоковый сервер переходит в режим ожидания подключений, вызывая функцию "int listen (SOCKET s, int backlog )", где s – дескриптор сокета, а backlog – максимально допустимый размер очереди сообщений.

Размер очереди ограничивает количество одновременно обрабатываемых соединений, поэтому, к его выбору следует подходить "с умом". Если очередь полностью заполнена, очередной клиент при попытке установить соединение получит отказ (TCP пакет с установленным флагом RST). В то же время максимально разумное количество подключений определяются производительностью сервера, объемом оперативной памяти и т.д.

Датаграммные серверы не вызывают функцию listen, т.к. работают без установки соединения и сразу же после выполнения связывания могут вызывать recvfrom для чтения входящих сообщений, минуя четвертый и пятый шаги.

Сервер: шаг пятый – извлечение запросов на соединение из очереди осуществляется функцией "SOCKET accept (SOCKET s, struct sockaddr FAR* addr,  int FAR* addrlen)", которая автоматически создает новый сокет, выполняет связывание и возвращает его дескриптор, а в структуру sockaddr

заносит сведения о подключившемся клиенте (IP-адрес и порт). Если в момент вызова accept очередь пуста, функция не возвращает управление до тех пор, пока с сервером не будет установлено хотя бы одно соединение. В случае возникновения ошибки функция возвращает отрицательное значение.



Для параллельной работы с несколькими клиентами следует сразу же после извлечения запроса из очереди порождать новый поток (процесс), передавая ему дескриптор созданного функцией accept сокета, затем вновь извлекать из очереди очередной запрос и т.д. В противном случае, пока не завершит работу один клиент, север не сможет обслуживать всех остальных.

все вместе – после того как соединение установлено, потоковые сокеты могут обмениваться с удаленным узлом данными, вызывая функции "int send

(SOCKET s, const char FAR * buf, int len,int flags)" и "int recv (SOCKET s, char FAR* buf, int len, int flags)" для посылки и приема данных соответственно.

Функция send возвращает управление сразу же после ее выполнения независимо от того, получила ли принимающая сторона наши данные или нет. При успешном завершении функция возвращает количество передаваемых (не переданных!) данных – т.е. успешное завершение еще не свидетельствует от успешной доставке! В общем-то, протокол TCP (на который опираются потоковые сокеты) гарантирует успешную доставку данных получателю, но лишь при условии, что соединение не будет преждевременно разорвано. Если связь прервется до окончания пересылки, данные останутся не переданными, но вызывающий код не получит об этом никакого уведомления! А ошибка возвращается лишь в том случае, если соединение разорвано до вызова функции send!

Функция же recv возвращает управление только после того, как получит хотя бы один байт. Точнее говоря, она ожидает прихода целой дейтаграммы. Дейтаграмма – это совокупность одного или нескольких IP пакетов, посланных вызовом send. Упрощенно говоря, каждый вызов recv за один раз получает столько байтов, сколько их было послано функцией send. При этом подразумевается, что функции recv предоставлен буфер достаточных размеров, - в противном случае ее придется вызвать несколько раз. Однако, при всех последующих обращениях данные будет браться из локального буфера, а не приниматься из сети, т.к. TCP-провайдер не может получить "кусочек" дейтаграммы, а только ею всю целиком.



Работой обоих функций можно управлять с помощью флагов, передаваемых в одной переменной типа int третьим слева аргументом. Эта переменная может принимать одно из двух значений: MSG_PEEK и MSG_OOB.

Флаг MSG_PEEK заставляет функцию recv просматривать данные вместо их чтения. Просмотр, в отличие от чтения, не уничтожает просматриваемые данные. Некоторые источники утверждают, что при взведенном флаге MSG_PEEK функция recv не задерживает управления если в локальном буфере нет данных, доступных для немедленного получения. Это неверно! Аналогично, иногда приходится встречать откровенно ложное утверждение, якобы функция send со взведенным флагом MSG_PEEK возвращает количество уже переданных байт (вызов send не блокирует управления). На самом деле функция send игнорирует этот флаг!

Флаг MSG_OOB предназначен для передачи и приема срочных (Out Of Band) данных. Срочные данные не имеют преимущества перед другими при пересылке по сети, а всего лишь позволяют оторвать клиента от нормальной обработки потока обычных данных и сообщить ему "срочную" информацию. Если данные передавались функцией send с установленным флагом MSG_OOB, для их чтения флаг MSG_OOB функции recv так же должен быть установлен.

Замечание: настоятельно рекомендуется воздержаться от использования срочных данных в своих приложениях. Во-первых, они совершенно необязательны – гораздо проще, надежнее и элегантнее вместо них создать отдельное TCP-соединение. Во-вторых, по поводу их реализации нет единого мнения и интерпретации различных производителей очень сильно отличаются друг от друга. Так, разработчики до сих пор не пришли к окончательному соглашению по поводу того, куда должен указывать указатель срочности: или на последний байт срочных данных или на байт, следующий за последним байтом срочных данных. В результате, отправитель никогда не имеет уверенности, что получатель сможет правильно интерпретировать его запрос.

Еще существует флаг MSG_DONTROUTE, предписывающий передавать данные без маршрутизации, но он  не поддерживаться Winsock и, поэтому, здесь не рассматривается.



Дейтаграммный сокет так же может пользоваться функциями send и recv, если предварительно вызовет connect (см. "Клиент: шаг третий"), но у него есть и свои, "персональные", функции: "int sendto

(SOCKET s, const char FAR * buf, int len,int flags, const struct sockaddr FAR * to, int tolen)" и "int recvfrom

(SOCKET s, char FAR* buf, int len, int flags, struct sockaddr FAR* from,   int FAR* fromlen )".

Они очень похожи на send и recv, - разница лишь в том, что sendto и recvfrom требуют явного указания адреса узла принимаемого или передаваемого данные. Вызов recvfrom не требует предварительного задания адреса передающего узла – функция принимает все пакеты, приходящие на заданный UDP-порт со всех IP адресов и портов. Напротив, отвечать отправителю следует на тот же самый порт откуда пришло сообщение. Поскольку, функция recvfrom заносит IP-адрес и номер порта клиента после получения от него сообщения, программисту фактически ничего не нужно делать – только передать sendto тот же самый указатель на структуру sockaddr, который был ранее передан функции recvfrem, получившей сообщение от клиента.

Еще одна деталь – транспортный протокол UDP, на который опираются дейтаграммные сокеты, не гарантирует успешной доставки сообщений и эта задача ложиться на плечи самого разработчика. Решить ее можно, например, посылкой клиентом подтверждения об успешности получения данных. Правда, клиент тоже не может быть уверен, что подтверждение дойдет до сервера, а не потеряется где-нибудь в дороге. Подтверждать же получение подтверждения – бессмысленно, т.к. это рекурсивно неразрешимо. Лучше вообще не использовать дейтаграммные сокеты на ненадежных каналах.

Во всем остальном обе пары функций полностью идентичны и работают с теми самыми флагами – MSG_PEEK и MSG_OOB.

Все четыре функции при возникновении ошибки возвращают значение SOCKET_ERROR (== -1).

Примечание: в UNIX с сокетами можно обращаться точно так, как с обычными файлами, в частности писать и читать в них функциями write и read. ОС Windows 3.1 не поддерживала такой возможности, поэтому, при переносе приложений их UNIX в Windows все вызовы write и read должны были быть заменены на send и recv соответственно. В Windows 95 с установленным Windows 2.x это упущение исправлено, - теперь дескрипторы сокетов можно передавать функциям ReadFil, WriteFile, DuplicateHandle и др.



 

Шаг последний – для закрытия соединения и уничтожения сокета предназначена функция "int closesocket (SOCKET s)", которая в случае удачного завершения операции возвращает нулевое значение.

Перед выходом из программы, необходимо вызвать функцию "int WSACleanup (void)" для деинициализации библиотеки WINSOCK и освобождения используемых этим приложением ресурсов. Внимание: завершение процесса функцией ExitProcess автоматически не освобождает ресурсы сокетов!

Примечание: более сложные приемы закрытия соединения – протокол TCP позволяет выборочно закрывать соединение любой из сторон, оставляя другую сторону активной. Например, клиент может сообщить серверу, что не будет больше передавать ему никаких данных и закрывает соединение "клиент à

сервер", однако, готов продолжать принимать от него данные, до тех пор, пока сервер будет их посылать, т.е. хочет оставить соединение "сервер à

клиент" открытым.

Для этого необходимо вызвать функцию "int shutdown (SOCKET s ,int how )", передав в аргументе how одно из следующих значений: SD_RECEIVE для закрытия канала "сервер à

клиент", SD_SEND для закрытия канала "клиент à север", и, наконец, SD_BOTH для закрытия обоих каналов.

Последний вариант выгодно отличается от closesocket "мягким" закрытием соединения – удаленному узлу будет послано уведомление о желании разорвать связь, но это желание не будет воплощено в действительность, пока тот узел не возвратит свое подтверждение. Таким образом, можно не волноваться, что соединение будет закрыто в самый неподходящий момент.

Внимание: вызов shutdown не освобождает от необходимости закрытия сокета функцией closesocket!

Почему никто не слышал, чтобы вирус на машине запустил format c: Сергей Иванов

Ну почему же не слышал? Очень много вирусов так и поступает, особенно поделок, написанных школьниками ясельной группы только – только постигающих азы Бейсика… Чуть более серьезные любители уже умеют форматировать диск самостоятельно или же стирать на нем произвольные сектора по одному за день или всей кучей сразу. Форматирование – это вообще-то достаточно сложная операция и реализовать свой форматер в вирусе накладно, а большинству – откровенно лениво. Уничтожать информацию посекторно или целыми файлами – куда проще!

Поэтому "прятать" format.com или переименовывать его, чтобы до него не дотянулись вирусы – ненужно. Вирусы и без того справятся и совершат свои злодеяния… только очень небольшая группа насекомых без format.com не сможет выполнить своей деструктивной миссии.

Почему ping не проходит, а сайт сервера нормально работает и открывается?

Бывает, – ping к некоторому серверу упорно не проходит, какую бы ни выбрал задержку, но все сервисы (будь то почта или web) работают нормально. Почему? Все объясняется очень просто – администратор сервера защитил его межсетевым экраном, блокирующим либо эхо - запросы, либо эхо – отклики, либо и те, и другие

вместесразу. А может запрет эхо – откликов наложен на сам узел.

Все эти меры предосторожности объясняются тем, что эхо – посылки имеют более высокий приоритет по сравнению с обычными пакетами (иначе бы эха век не дождаться) и злоумышленники могут перегрузить сервер, направив на него штурм эхо – запросов. "Упасть", правда, сервер не упадет, но вот общая производительность несколько снизится. Хуже направить шторм эхо – запросов от имени жертвы, выходящей в Интернет по модему, – на нее обрушится сокрушительная лавина эхо – ответов от быстродействующего сервера (хорошо если одного), плотно забивающая канал…

Вот поэтому-то, для заблаговременного предотвращения возможности атаки, эхо – посылки и запрещаются, делая работу ping невозможной, но все службы сервера продолжают как ни в чем не бывало работать!

Почему при установке соединения Windows показывает скорость порта, а не скорость соединения?

Строго говоря, Windows вообще не умеет отображать текущую скорость соединения. В лучшем случае она показывает скорость, выбранную модемом на момент установки соединения, и не учитывает того, что адаптивная система модема может динамически как увеличивать, так и уменьшать ее при изменении качества линии. А, если модем управляется драйвером "стандартный модем", то и вовсе выводится не скорость соединения, а скорость порта, соединяющего модем с компьютером!

Если вам необходимо контролировать параметры соединения, лучше всего приобрести для этой цели модем со встроенным дисплеем, отображающим всю необходимую информацию (например, ZyXEL OMNI 56k Pro).

Операционная система Windows 2000 даже у некоторых знакомых ей модемов всегда отображает скорость порта, а не начальную скорость установки. Проблему решает следующий шаманский обряд – вызовите программу "Hyper Terminal" (входит в штатную поставку Windows) и наберите следующую команду: "AT&V1<ENTER>". Выйдите из "Hyper Terminal" – теперь до включения \ выключения модема все должно работать.

Почему трассировка умирает на полпути к серверу назначения?

Довольно часто попытка трассировки пути прохождения пакетов заканчивается провалом – трассировка "умирает" не доходя до сервера, выводя бесконечно длинную вереницу ругательств "Превышен интервал ожидания для запроса". Но сколько ни увеличивай интервал ожидания (см. "Каково назначение ключей tracert") – ругательства не исчезают!

C:\>tracert www.aport.ru -w 10000

Трассировка маршрута к aport.ru

[194.67.18.8]

с максимальным числом прыжков 30:

  1   140 ms   140 ms   130 ms  nas.itech.ru [195.151.210.36]

  2   140 ms   140 ms   140 ms  ns.itech.ru [195.151.210.33]

  3   190 ms   440 ms   171 ms  gw.itech.ru [195.151.210.29]

  4   160 ms   160 ms   171 ms  195.151.200.90

  5   171 ms   180 ms   941 ms  krd-gw.mtt.ru [195.151.52.41]

  6   181 ms   180 ms   190 ms  Moscow18-S3-7-0.RoSprint.net [194.84.251.246]

  7   180 ms   201 ms   190 ms  Moscow41-F1-0.RoSprint.net [193.232.88.23]

  8   180 ms   191 ms   180 ms  cisco12.Moscow.ST.NET [193.232.244.43]

  9   180 ms   181 ms   180 ms  cisco02.Moscow.ST.NET [194.186.157.241]

 10     *        *        *     Превышен интервал ожидания для запроса.

 11     *        *        *     Превышен интервал ожидания для запроса.

 12     *        *        *     Превышен интервал ожидания для запроса.

 13     *        *        *     Превышен интервал ожидания для запроса.

 14     *        *        *     Превышен интервал ожидания для запроса.

 15     *        *        *     Превышен интервал ожидания для запроса.

Виной тому пугливые администраторы, запрещающие в целях безопасности посылку уведомлений об уничтожении пакета с истекшим TTL, либо блокирующие дейтаграммы, приходящие на "левый" порт. Не то, чтобы трассировка могла сильно навредить, но к чему раскрывать другим анатомию своей локальной сети?

Аналогичная ситуация наблюдается и при попытке проникновения за Proxy-сервер – он либо вовсе отказывается посылать дейтаграмму на несуществующий порт, либо посылает, но прописывает собственное значение TTL в заголовке, отчего трассировка перестает работать. Причем, это справедливо по обе стороны от Proxy-сервера!

Родственные вопросы:

Каково назначение ключей tracert

Можно ли обойти защиту от трассировки?

Почему Windows 2000 так медленно загружает страницы и принимает файлы? Сабиха connectiond@ftw.fu

Часто переход на Windows2000 сопровождается смутными сомнениями – "две тысячи" это год выпуска или количество ошибок? А может быть, максимальная скорость сетевого соединения? Модем едва мигает лампочкой и больше, чем 2.000 байт в секунду не тянет. Что ли памяти мало или мегагерц? Пробуем увеличить и то, и другое – не помогает? Почему?!

А причина вся в том, что Windows 2000 при установке модема очень часто неправильно выставляет скорость порта. Например, Rockwell ACORP33.600 автора, она благополучно опознала, но почитала, что скорости порта в 9.600 бит (!) для успешной работы будет достаточно. Ну не свинство, а? ???? Рисунок "карикатура" свинья-копилка с логотипом Windows и монетой "2000 bugs", опускаемой в нее

Так-с, входим в систему с правами администратора, затем "Пуск" à

"Настройка" à

"Панель управления" à

"Система" à

вкладка "Оборудование" à

кнопка "Диспетчер устройств" à

"Порты COM и LPT" à "Свойства" того порта, на котором "висит" модем à вкладка "Параметры порта" à поле "Скорость". Устанавливаем максимальное значение и нажимаем "ОК".

Внимание! Скорость порта должна быть выше скорости модема, особенно если задействовано аппаратное сжатие. Модем может сжимать передаваемые данные в несколько раз, но если порт не обеспечит соответствующую пропускную способность, модем не сможет работать на полную мощь.

Подари врагу антивирус!

Отношения к антивирусам бывают самые разные - от фанатичной веры в их безграничное могущество до скептического убеждения в их полной бесполезности. Последнее мнение встречается значительно чаще. И не мудрено - качество многих антивирусных продуктов оставляет желать лучшего и пользы от них зачастую оказывается меньше, чем проблем.

Чаще всего использование антивируса сводится к его запуску в полностью автоматическом режиме "найти заразу и уничтожь". Это что-то вроде ракеты с автоприцеплом, интеллект которой не позволяет отличить самолет противника от стаи птиц. В общем, плакали бедные мирные файлы вместе со всей дисковой подсистемой в придачу.

??? Рисунок "карикатура" обыграть предыдущий абзац

Совершенствование технологий маскировки вирусов происходит быстрее нежели технологий их поиска. В результате возможны (и достаточно часты) как ложные срабатывания (т.е. обнаружение вируса там, где его и в помине нет), так и не распознавание вируса (несмотря на то, что он есть).

С появлением Интернет, техно-крысы заполучили еще один канал распространения своих творений, да какой канал! В эпоху рассвета BBS большим достижением считалось заразить за один раз сто-двести человек – ну, разве можно сравнить это с тем, что возможно сейчас? Стоит выложить программу с тайно внедренным в нее "насекомым" на десяток-другой посещаемых сайтов, как за один день ее могут "подцепить" тысячи пользователей!

К тому времени, пока разработчики антивируса успеют включить штамм вируса в очередное обновление, эпидемия может захватить все континенты (и такие случаи скорее правило, чем исключение). Если вирус писан не школьником, только постигающим азы программирования, а профессионалом, умело противодействующим анализу своего творения, - разработка противоядия может затянуться на неделю, если не больше. Тем временем, вирус будет продолжать свое наступление, проникая по быстрым каналам Интернет в самые отдаленные уголки сети.

Противостать таким вирусам вызвались так называемые "эвристические анализаторы", позволяющие с некоторой вероятностью находить новые, еще не известные вирусы. И все было бы хорошо, ни будь понятие "вирус" таким растяжимым - под эту категорию попадет множество безобидных и мирных программ, например, дисковые утилиты, сами антивирусы и даже… операционные системы!

Напротив, вирусы могут успешно маскироваться под "невинных овечек", обманывая даже самых строгих эвристических анализаторов. Разработчики антивирусов, собственно, и не утверждают, что эвристические анализаторы могут обнаруживать всех новых вирусов, но обещают, что, по крайней мере, девяносто (а может быть, и все девяносто девять) процентов из их будут успешно пойманы.

Такой неумеренный оптимизм рождает смутные сомнения, - помните анекдот о машине, исправной на девяносто девять процентов ("извини дорогой, тормоза попали в последний процент")? Невозможно быть "чуть-чуть беременной", как и "чуть-чуть неисправным". Антивирус либо работает, либо нет. Создатели вируса (за редкими исключениями) не настолько глупы, чтобы не протестировать свою заразу на всех мало-мальски популярных антивирусах - обнаруживают ли они ее или нет. Если обнаруживают, – продолжают совершенствовать свое детище до тех пор, пока оно не станет полностью невидимым.

Известно очень мало случаев когда новые вирусы находились именно эвристическим анализатором, зато "ругательства" на здоровые файлы стали притчей во языцах. Что делать пользователю? Стирать подчистую все, что вызывает подозрение? "Вот-вот", - шутят технокрысы, "зачем писать вирусы, лучше своему врагу подарить антивирус!".

По идее, можно отослать "ругаемый" файл в службу поддержки, - пускай там разбираются - вирус это или нет. Но, даже если оттуда придет ответ (что вовсе не факт), это случится нескоро.

Немногочисленные продвинутые антивирусы (список которых во избежание обвинений в рекламе приводиться не будет), умеют не только ругаться (ругаться-то дело не хитрое, на это много ума не надо), но и мотивировать причины своего неудовольствия. Дескать, вот тут замечено обращение к исполняемому файлу, тут - к системным областям диска, а здесь вообще шифрованный и хитрый-хитрый полиморфный код (с чего бы легальной программе шифроваться?!).

Пользователю предоставляется самому решать - опасная эта программа или нет. Например, если эмулятор 3Dfx, имеет скрытые функции для работы с Интернет, – поневоле задумаешься - настоящий ли эмулятор это, или шпион, тайно похищающий информацию с компьютера. Аналогично, "Кракеру Интернета", будь он действительно "Кракером Интернета", функции удаления файлов с диска совершенно ни к чему! Напротив, утилита, вычищающая "мусор" из "дальних пыльных углов" винчестера, может удалять файлы на вполне легальных основаниях.



А что будет, если вирус поразит какую-нибудь системную утилиту? Правильно, он окажется не обнаруженным, поскольку, эти потенциально опасные действия утилита может совершать и без него! Удивительно ли, что именно таким образом создатели вирусов и пытаются распространять своих "насекомых"?

"Обжегшись" пару раз на вирусах, многие пользователи порой и вовсе отказываются от копирования и установки на свой компьютер всех "нефирменных" программ. А если уж возникает в них необходимость - берут компакт-диск у приятеля, уже проверившего его "стерильность" на собственной шкуре. Риск подцепить заразу при этом уменьшается до нуля, но пользователю, наученному горьким опытом, этого мало, и он аккуратно скачивает с сайта-разработчиков последнюю версию полюбившегося ему антивируса, как говорится, "на всякий пожарный", чтобы уж точно быть уверенным, что никаких вирусов у него нет.

Но незащищенность Интернет позволяет злоумышленнику подсунуть свой жертве не оригинальный антивирус, а его "усовершенствованную" версию, заражающую все файлы во время их сканирования, если не что-то похуже. И такие случаи уже бывали, к тому же неоднократно! И поражались не только конечные пользователи, но и крупные дистрибьюторы!

Еще больше неприятностей доставляют ошибки, допущенные разработчиками антивирусов (антивирус, как и всякая программа, не свободен от ошибок). Нередко они приводят к полному уничтожению всей информации, хранящейся на жестком диске, - а на такую катастрофу способен далеко не каждый вирус!

Как ни крути, а никакой, даже самый "фирменный" и "продвинутый" антивирус не избавляет от необходимости периодического сохранения всей ценной информации на резервных носителях (стримерах, Zip-ах, CD-"писцах" и подобных им). Но если есть резервная копия, - так ли тогда необходим антивирус?

…антивирусы и в самом деле не так надежны, как этого ожидают приобретающие их пользователи. По-настоящему защищенными могут чувствовать себя лишь те, за чьими компьютерами следят живые специалисты, а не автоматические программы.



К сожалению, таковых специалистов никогда не будет достаточно, чтобы охватить весь существующий парк компьютеров, и на ближайшие несколько лет антивирусы останутся единственным предохранительным средством "домашних" пользователей.

От вирусов, как и от СПИДа, предохраняться можно, но безо всяких гарантий на успех. Правда, если вести упорядоченную во всех отношениях жизнь и не иметь отношений с личностями сомнительного происхождения, даже безо всяких предосторожностей риска заразиться практически нет!

В конечном счете, основную проблему представляют собой не вирусы, а низко квалифицированные пользователи (которые иногда занимают места системных администраторов) и упорное нежелание руководства уделять защите информации должное внимание.

По наиболее достоверным оценкам убытки от вирусов не превышают 5%-10% от всех происшествий вообще (вызванных поломками аппаратуры, стихийными бедствиями, неадекватными действиями пользователей и т.д.).

Фактически мы имеем дело с мифом, поддерживаемым заинтересованными в нем людьми (журналистами, специалистами по безопасности, разработчикам антивирусов и, наконец, самими пользователями, которым гораздо выгоднее свались все на вирус, якобы появившейся в самый неожиданный момент, и уничтоживший всю сделанную работу).

В "нормальных" операционных системах таких, например, как Windows NT или Windows 2000, проблема вирусов не столь актуальна, поскольку, они могут запретить модификацию исполняемых файлов и не допускают уничтожения критически важных данных. Обойти же такую защиту вирус сможет только теоретически.

Хотите обезопасить себя и навсегда забыть это страшное слово "вирус"? Тогда отправляйтесь в ближайший магазин за диском с Widows NT и спите спокойно!

Родственные вопросы:

Вирусы - кибернетический Минотавр или Мания?

В чем преимущества Windows 2000 по сравнению с 9x?

Поймай мечту за хвост!

Хотите, не покидая любимого кресла, увековечить свое имя, принести пользу науке и заглянуть за край обыденного? Все что вам потребуется - компьютер средней конфигурации и Интернет любой степени тормознутости, плюс немного терпения (хотя бы дней на сто), словом, ничего экзотического.

Среди прочего космического мусора, вращающегося над нашими головами, в полутора миллионах километрах над Землей парит внеатмосферная солнечная обсерватория SOHO (Solar and Hemispheric Observatory). Через определенные промежутки времени она фотографирует Солнце, а полученные снимки автоматически выкладываются на сайт http://sohowww.estec.esa.nl/data/realtime-images.html

Фактически это настоящая "живая камера", позволяющая заглянуть за кулисы нашего светила. Многие даже не подозревают на какие причудливые переплетения плазмы и газа способна природа. Непрекращающиеся активные процессы – вспышки, факелы, протуберанцы не только любопытны с познавательной точки зрения, но и красивы.

При наличии постоянного Интернет-соединения оригинальным украшением рабочего стола может стать автоматически обновляемое изображение Солнца, заменяющее традиционный хранитель экрана. Такую программу (под Макинтош и Windows 9x\Windows NT) с сервера NASA можно скачать абсолютно бесплатно, обратившись по адресу: http://sohowww.estec.esa.nl/whatsnew/screensaver.html.

Но наблюдения Солнца, сияющего на экране монитора, могут носить не только праздный характер. Их визуальный (да, да, именно визуальный, а не компьютерный!) анализ способен принести существенную пользу науке и увековечить ваше имя. Речь идет о "ловле комет". Некоторые "хвостатые странницы" так близко подлетают к нашему светилу, что попадают в поле зрения широкоугольного коронографа SOHO и оставляют свой след на фотоснимках. По некоторым причинам NASA не ведет их компьютерного поиска, оставляя эту затею на откуп любителям.

Между тем, открытие новой кометы – всегда событие, пускай, из ряда вон не выходящее, но имеющее далеко идущее последствия. Открывателю автоматически присуждается право окрестить "туманную звездочку" собственным именем (или псевдонимом), об открывателе тотчас узнают все астрономы мира, а изучение орбит комет позволяет пролить свет на многие загадки природы, в том числе приоткрывает занавесу тайны происхождения нашей Солнечной системы, а, значит, и нас с вами.

Сотни любителей всего мира систематически просматривают полученные SOHO изображения, и самые настойчивые открывают новую комету в среднем за сто-сто пятьдесят дней наблюдений. "Ловля" комет в чем-то похожа на обычную рыбалку – тесное переплетение удачи и мастерства, разочарований, азарта и моментов непередаваемого чувства вселенского удовлетворения. Это особый вид спорта, сочетающий коллективное братство (а астрономы, как, впрочем, и рыболовы, на удивление дружные ребята) с ролью индивидуальной личности.

Хотите и вы попробовать? Тогда заходите на сайт http://sungrazer.nascom.nasa.gov/ и подключайтесь к проекту. Значение английского языка необязательно (хотя, горячо приветствуется) – вся необходимая информация в сжатом виде изложена ниже. Начать посвящение будущих ловцов комет, вероятно, следует с описания самого спутника SOHO. Помимо прочей аппаратуры (не имеющий никакого отношения к поиску комет), его создатели оснастили космическую обсерваторию двумя коронографами, получившими условные обозначения С2 и С3.

Рисунок 43 ??? Рис с2.jpg Вид Солнца в коронограф C2

Рисунок 44 ??? Рис с3.jpg Вид Солнца в коронограф C3

Как и следует из названия, "коронограф" предназначается для наблюдений за солнечной короной. Невооруженным глазом ее можно наблюдать только во времена полных солнечных затмений, поскольку яркость короны в десятки тысяч раз меньше яркости слепящего диска фотосферы (видимой поверхности Солнца) и тонет в его лучах. Но если расположить перед объективом телескопа непрозрачный кружок, закрывающий солнце, то, тщательно подобрав его размер, можно добиться "искусственного затмения". (Конечно, в действительности коронограф устроен немного сложнее, но для работы с ним значение технических подробностей его работы необязательно).

Поле зрения коронографа С3 равно 6 градусам (видимый диаметр солнечного диска в двенадцать раз меньше), что всего лишь вдвое меньше орбиты Меркурия. Большинство комет двигаются по орбите настолько быстро, что "пролетают" это расстояние менее чем за двенадцать часов! Эх, совсем немного времени отпущено на поимку новой кометы! (Поле зрения коронографа "С2" всего лишь 3 градуса, поэтому, вероятность открытия кометы с его помощью существенно меньше).



Чем отличается комета от звезд? Нет, вовсе не хвостом (который заметен лишь у немногочисленных крупных комет), а… движением. Если сравнить между собой два снимка, полученные с некоторым интервалом, то настоящие звезды (за исключением, Солнца, конечно) не изменят своего взаимного расположения, а комета ощутимо "сдвинется" относительно окружающих ее звезд. Часто (но не всегда) кометы выглядят не точечными звездочками, а размытыми туманными пятнышками, размеры которых постепенно растут по мере приближения кометы к Солнцу.

Это минимально необходимая для "кометной рыбалки" информация, поэтому, заинтригованным читателям одна дорога – в библиотеку (или астрономический институт имени Штейнберга – ГАИШ), а может быть, даже в Московский Астроклуб (электронный адрес председателя andos@osp.ru), где им помогут удовлетворить любопытности и разъяснят остальные подробности.

Напоследок несколько полезных советов для начинающих. В первую очередь следует предостеречь читателей от соблазна использовать изображения с низким разрешением, - на них кометы попросту не видны. Лучше всего для анализа подходят снимки 1024x1024, хотя опытные "охотники" с некоторой натяжкой могут обходиться и вдвое меньшим разрешением. Но изображения худшего качества уже ни на что не годны.

Второе, – обнаружив нечто похожее на комету, не спешите уведомлять о своем открытии,– сначала убедитесь, что это не ошибка. Для проверки рекомендуется скачать с сайта по крайней мере четыре последовательных снимка и проследить по ним путь объекта, принятого за комету. Если перемещение подтвердится, – сообщите об этом координатору проекта Дугласу Биесекеру по адресу doug@sungrazer.nascom.nasa.gov.

Форма сообщения – произвольная, (письма обрабатывает живой человек, а не машина), но должна в себя включать:

а) инструмент (т.е. какой именно коронограф использовался C2 или C3);

б) дату и всемирное время, когда был получен снимок (внимание, не путайте это со временем, когда вы обнаружили комету);

в) координаты кометы на каждом из четырех снимков (координаты центра кометы измеряются в пикселах, отсчитываемых от любого из углов фотографии и записываются в формате XxY, например, так: 666x999);

г) какой угол использовался для отсчета координат.

Вот и все! Удачной вам охоты!

Получение файлов

Анархия – это когда вас постоянно поливают дерьмом, а вы должны терпеть.

Аноним

Попытка скачать с WEB-сервера

Для идентификации программного обеспечения, установленного у клиента, в заголовке запроса, посылаемого web-серверу, предусмотрено специальное поле "User-Agent", заполняемое самим клиентом, точнее, его программным обеспечением, и по обыкновению содержащие название и версию этого самого программного обеспечения.

Зная, какие браузеры используют посетители его сайта, web-мастер может оптимизировать HTML-код соответствующим образом. Хотя, временами раздаются недовольные возгласы в стиле "руки прочь от подробностей интимной жизни посетителя", техника идентификации клиентов призвана служить их же благу.

И все было бы хорошо, если бы некоторые (слегка тронутые) web-мастера, не налагали бы ограничений на выбор программного обеспечения. Анализируя содержимое поля "User?Agent" они разрешают доступ к ресурсам в том, и только в том случае, если клиент использует "дозволенный" браузер, в противном же случае – от ворот поворот. Прямо как в анекдоте – моя селедка, что хочу, то и делаю!

Большинство браузеров – InternetExplorer, Netscape Navigator и др. – для своей идентификации используют кодовое имя "Mozilla", а "качальщики" файлов зачастую оставляют поле "User-Agent" пустым, либо же заполняют его некоторым образом по своему усмотрению. Поэтому, отличить такой "качальщик" от браузера очень легко! Вопрос: чем же мотивирован запрет на использование "качальщиков", следует задать этим самым "двинутым" web-мастерам, автор же ответить на него не в силах – это выше его понимания!

Можно ли обойти такую защиту? Разумеется, да - достаточно качальщику идентифицировать себя строкой "Mozilla" – если, конечно, такая возможность предусмотрена его разработчиком. В противном случае придется выбирать другого "качальщика" – с более гибкими настройками.

Очень сильно ушибленные web-мастера ухитряются распознавать такой обман, проверяя значение еще одного поля – "Referrer", содержащее адрес страницы откуда пришел клиент. {>>>> сноска прямо разворачивают целую военную компанию против своих посетителей!}. При скачке файла из браузера в это поле помещается адрес текущей страницы, но большинство "качальщиков" оставляют его пустым!

Разумеется, разработчикам "качальщиков" это препятствие нетрудно обойти – подумаешь, проблема – добавить несколько лишних строчек кода, – но вот пользователи "качалки", не поддерживающей заполнения поля "Referrer" скидывают ласты и выпадают в осадок, разыскивая более совершенную программу – поумнее.

Ниже будет приведен пример конфигурирования двух популярнейших приложений – ReGet и Teleport Pro. Во всех остальных случаях поможет прилагаемая к продукту документация, а в ее отсутствии эту операцию можно попытаться выполнить и самостоятельно, поскольку все приложения конфигурируются, в общем-то, аналогично.

???? Рисунок "карикатура" Веб-мастер, ведущий войну с посетителями – посетитель хочет забрать файл, а Веб мастер, вцепившись в него мертвой хваткой – не отдает!

При чтение некоторых сайтов выскакивает ошибка "TTL bug". Как с ней бороться?

Запустите Редактор Реестра и откройте ветвь HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP для Windows9x и HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters для Windows NT\2000. Найдите там, а при необходимости создайте, строковой параметр "DefaultTTL" и присвойте ему значение "128".

Подробнее об этом см. "Оптимизация соединения с Интернет", так же "Описание утилиты MTUSpeed".

Родственные вопросы:

Описание утилиты MTUSpeed

Оптимизация соединения с Интернет

Пример сеанса работы с telnet

Следующий эксперимент демонстрирует подключение к telnet?серверу "hobbiton.org" с регистрацией нового пользователя.

Выберите пункт "Удаленная система" меню "Подключить" в графическом клиенте или непосредственно укажите имя сервера в его консольной ипостаси.

Когда на экране появится диалоговое окно, изображенное на рисунке 55 в поле "Имя узла" укажите "hobbiton.org" (или адрес другого узла, с которым вы хотите установить соединение). Содержимое поля "порт" на данном этапе оставьте по умолчанию, – "telnet" или введите численное значение порта – "23", в поле "Типе терминала" выберите терминал "vt100".

Рисунок 56 Рисунок 060 Диалог "подключение"

Когда все будет сделано, нажмите кнопочку "подключить", и через пару секунд появится заставка “Open BSD”, с требованием ввода имени пользователя и пароля (смотри рисунок 56).

Рисунок 57 Рисунок 061 Начало telnet-сессии с сервером

Для регистрации нового пользователя введите вместо своего имени "newuser", – сервер, радостно хрюкнув, задаст несколько придирчивых вопросов о поле, возрасте, месте проживания и через некоторое время, варьирующиеся от десятков минут до нескольких дней, создаст новый аккаунт и запустит вас в систему.

Как с ней работать? см. "Как работать с UNIX?"

Родственные вопросы:

Как работать с UNIX?

Web-programming à

Какие сервера бесплатно предоставляют право исполнения cgi?

---

---