Переход на безопасные протоколы: Нужно ли переходить на https и как это сделать без последствий?

01.10.2023 alexxlab

Содержание

HTTPS или переход на безопасное соединение

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

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

HTTPS (английская аббревиатура HyperText Transfer Protocol Secure) — это расширение стандартного протокола передачи данных HTTP, созданное для поддержки шифрования передачи данных в целях безопасности.

Объясним чуть более человеческим языком.

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

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

картинку выше).

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

HTTPS для малого бизнеса

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

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

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

Как получить SSL сертификат и перейти на защищенный протокол

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

Сегодня все проще как с самим процессом, так и с доступностью в цене. Рассмотрим пару примеров подключения – один из панели обычного виртуального хостинга, а второй из панели ISP Manager на VDS сервере.

HTTPS на виртуальном хостинге

Обычно, проще всего устанавливать SSL сертификаты на таком виде хостинга, при условии, что ваш сайт расположен у хорошей компании с качественным сервисом. Рассмотрим на примере панели Timeweb.

Первое, что надо сделать это выбрать тип сертификата, они бывают разными и отличаются не только степенью доверия, но и масштабом. На наш выбор есть четыре варианта.

Первые три от центра сертификации Comodo

Positive SSL — Работает только с одним доменом. Выпуск занимает минимум времени.
Positive Wildcard SSL — Работает на домене и всех его поддоменах.
EV SSL — Сертификат высокой надежности предоставляет самый высокий уровень шифрования, а также активирует зеленую адресную строку в браузере.

И последний от некоммерческого центра сертификации Let’s Encrypt, главной особенностью которого является его бесплатная выдача и возможность работы на поддоменах. Однако при его использовании никаких юридических данных владельца вы ни увидите в браузере и выдается он ограниченным сроком на 3 месяца.

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

HTTPS на VDS/VPS сервере с панель ISP Manager

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

Как и в первом варианте, нам нужен сертификат. Он может быть платный или бесплатный от Let’s Encrypt. Если за деньги, то для начала вам надо его купить, это можно сделать или в билинговой панели хостинга или напрямую в центре сертификации типа Comodo или Symantec. Затем в соответствующем разделе добавляем запись и вставляем все необходимые ключи, которые получили при покупке.

Далее необходимо зайти в список сайтов и у нужного домена выбрать добавленный сертификат.

Если вы хотите поставить бесплатный SSl от Let’s Encrypt, тогда для начала проверьте что у вас установлен данный модуль. Затем запускаем процесс получения сертификата. Тут рекомендуем выбрать подтверждение через DNS записи – этот способ намного проще и не должен вызвать сложностей. Если хотите, чтобы защищенные были так же поддомены, тогда надо установить опцию Wildcard.

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

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

Резюме

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

Если по какой-то причине у вас не получилось настроить SSl сертификат на своем сайте, а желание есть, тогда напишите нам и мы с радостью вам поможем это сделать.

2018-12-13
Команда VJ Studio

Понравилось? Поделитесь с другими

Как безопасно перейти на протокол HTTPS

Статья написана в рамках статейного конкурса Serpstat и SEOnews.

Условия конкурса

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

По умолчанию, все сайты работают по протоколу HTTP (HyperText Transfer Protocol) – протокол передачи гипертекста. HTTP был создан в 1992 году, он является довольно старым и в процессе работы с ним выявлены уязвимости в обеспечении безопасности передачи данных. Для повышения уровня безопасности в 2000 году было принято решение применить шифрование сетевого трафика по секретному алгоритму с использованием протоколов SSL и TLS. Разработанное расширение применили поверх существующего HTTP – так появился протокол HTTPS (HyperText Transfer Protocol Secure).

После правильной и корректной установки сертификатов HTTPS владелец сайта может обезопасить передаваемые и получаемые данные.

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

А уже в сентябре 2016 года Google заявил, что наличие протокола HTTPS для сайтов, которые используют пользовательские данные, будет одним из факторов ранжирования с 1 июня 2017 года, а также такие сайты с протоколом HTTPS будут помечены значком безопасный.

В свою очередь, сайты с HTTP-протоколом будут помечены значком «Небезопасный».

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

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

Есть несколько видов SSL-сертификатов:

платные и бесплатные;
именные и неименные;
для одного домена и мультидоменные;
доверенные и самоподписные.

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

Существует огромное количество статей в разнообразных SEO-блогах о правилах перехода с HTTP на HTTPS. (.*)$ https://mysite.com/$1 [R=301,L]

Через функцию в коде.

302 и любой другой редирект не рекомендуется использовать, так как 301 редирект – это постоянное перенаправление по адресу.

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

2. Проверка склейки зеркал

При переходе на HTTPS нужно проверить корректность склейки зеркала с WWW и без WWW. Другими словами, нужно выбрать и оставить только одно зеркало: https://mysite.com или https://www.mysite.com. Склейку рекомендуется проводить также 301 редиректом.

3. Замена внутренних и внешних ссылок на относительные

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

Проверить замену можно с помощью программы Xenu’s Link Sleuth.

Для этого создаем новый проект, вводим имя домена через протокол HTTPS и нажимаем кнопку «ОК». В результате сформированного отчета не должно быть URL-ов, подсвеченных красным цветом. Наличие красных URL-ов свидетельствует об ошибке.

ВАЖНО! Особое внимание уделяем ссылкам на другие ресурсы, так как они тоже будут переделаны под протокол HTTPS, и, в случае если один или несколько сайтов не поддерживают этот протокол, для них придется сделать исключение и прописать путь через HTTP.

4. Новые URL-ы страниц в sitemap.xml

Сгенерировать новый файл sitemap.xml с URL-ами по протоколу HTTPS.

5. Изменения в robots.txt

В файле для поисковых роботов прописать хост и путь к файлу sitemap.xml через защищенный протокол. Пример:

Host: https://mysite.com

……….

Sitemap: https://mysite.com/sitemap.xml

6. Доступность файлов sitemap.xml и robots.txt по двум протоколам

После склейки 301 редиректом всех страниц сайта по протоколу HTTP на HTTPS стоит настроить исключение для вышеуказанных файлов (sitemap. xml, robots.txt). Таким образом поисковые системы быстрее смогут проиндексировать новые URL-ы сайта по протоколу HTTPS.

7. Добавление нового сайта в Google, что показать поисковому роботу о новом адресе сайта

Под добавлением имеется в виду добавление записи в Google Search Console, но при этом, как и для смены домена, через Search Console нет возможности показать склейку. К сожалению, Google Search Console не предусматривает такого функционала, поэтому важно выполнить настройки, которые указаны ниже:

Корректный регион сайта, под который продвигается сайт. Выбираем пункт бокового меню «Поисковый трафик», а затем «Таргетинг по странам и языкам». Выставляем нужный регион (если регион не был проставлен автоматически, в зависимости от региональности доменного имени).

Добавить путь к файлу sitemap.xml (выбираем пункт бокового меню «Поисковый трафик», а затем «Файлы Sitemap»).

8. Переезд сайта в Яндекс.Вебмастере

Необходимо отправить заявку на смену протокола. Для этого в боковом меню вебмастера выбираем пункт «Индексирование», а затем — «Переезд сайта». Ставим галочку в чекбоксе «Добавить HTTPS», после чего нажимаем кнопку «Сохранить».

Стоит отметить, что Яндекс удалит страницы сайта по протоколу HTTP из индекса, а новые может добавлять на протяжении нескольких недель. Опасаться этого не стоит.

9. Отказ от ссылок в Google Search Console

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

Перейти в инструмент Google Disavow Links;
Нажать на кнопку «Отклонение ссылок». Если в инструменте есть файл формата *.txt, нужно его скачать и аналогично загрузить для домена с протоколом HTTPS.

10. Изменение URL-ов внешних ссылок

Чтобы улучшить ранжирование и увеличить вес, ранее для сайта закупались ссылки. Так как URL-ы изменились, все ссылки дают 301 ответ. Рекомендуется заменить в ссылках URL с HTTP на HTTPS.

Стоит отметить, что некорректно настроенный с технической точки зрения протокол HTTPS – это практически протокол HTTP с точки зрения защиты. Он может быть проблемным, менее эффективным с точки зрения поисковой оптимизации (позиций, трафика и как следствие, конверсии).

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

Выполнив все рекомендации, вам удастся перевести свой сайт с протокола HTTP на HTTPS, при этом сохранив позиции сайта и не потеряв посетителей и конверсии на сайте.

6 протоколов сетевой безопасности, которые вы должны знать

Что такое протоколы сетевой безопасности?

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

Связанное содержимое: Узнайте больше о угрозах сетевой безопасности Протоколы безопасности могут защитить от .

Сетевая модель OSI

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

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

Модель OSI содержит следующие уровни:

Уровень 1 — физический уровень — физическое кабельное или беспроводное соединение между узлами сети.
Уровень 2 — канальный уровень — создает и разрывает соединения, разбивает пакеты на кадры и передает их от источника к месту назначения.
Уровень 3 — сетевой уровень — разбивает сегменты на сетевые пакеты и собирает их после получения, а также маршрутизирует пакеты по оптимальному пути в физической сети.
Уровень 4 — Транспортный уровень — отвечает за повторную сборку сегментов на принимающей стороне, превращая их в данные, которые могут использоваться сеансовым уровнем.
Уровень 5 — сеансовый уровень — создает каналы связи, называемые сеансами, между устройствами. Сохраняет сеансы открытыми во время передачи данных и закрывает их по окончании.
Уровень 6 — уровень представления — подготавливает данные для прикладного уровня, определяя, как два устройства должны кодировать, шифровать и сжимать данные, чтобы обеспечить их правильный прием.
Уровень 7 — уровень приложений — используется программным обеспечением конечного пользователя, таким как веб-браузеры и почтовые клиенты. Отправляет и получает информацию, которая важна для конечных пользователей, используя такие протоколы, как HTTP, FTP и DNS.

6 Типы протоколов сетевой безопасности

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

Протокол безопасности интернет-протокола (IPsec) — уровень 3 OSI

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

Изначально IPsec содержал протоколы ESP и AH. Encapsulating Security Payload (ESP) шифрует данные и обеспечивает аутентификацию, а Authentication Header (AH) предлагает возможности защиты от повторного использования и защищает целостность данных. С тех пор пакет был расширен за счет включения протокола Internet Key Exchange (IKE), который предоставляет общие ключи, устанавливающие ассоциации безопасности (SA). Они обеспечивают шифрование и дешифрование через брандмауэр или маршрутизатор.

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

SSL и TLS — уровень 5 OSI

Протокол Secure Sockets Layer (SSL) шифрует данные, аутентифицирует источники данных и обеспечивает целостность сообщений. Он использует сертификаты X.509 для аутентификации клиента и сервера. SSL аутентифицирует сервер с помощью рукопожатия, согласовывая параметры сеанса безопасности и генерируя сеансовые ключи. Затем он может безопасно передавать данные, аутентифицируя их происхождение.

Сеансы SSL используют криптографические алгоритмы, аналогичные алгоритмам, используемым клиентом и сервером (определяются во время рукопожатия). Серверы могут поддерживать шифрование с помощью таких алгоритмов, как AES и Triple DES.

Сертификаты сервера X.509 являются обязательным требованием для SSL, позволяя клиенту проверить сервер. SSL также может использовать клиентские сертификаты X.509 для аутентификации. Эти сертификаты должны быть подписаны доверенным центром сертификации в связке ключей сервера.

Transport Layer Security (TLS) — это протокол на основе SSL, определенный IETF (SSL — нет).

Безопасность транспортного уровня дейтаграмм (DTLS) — уровень 5 OSI

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

Протокол Kerberos — уровень 7 OSI

Kerberos — это протокол проверки подлинности запроса службы для ненадежных сетей, таких как общедоступный Интернет. Он аутентифицирует запросы между доверенными хостами, предлагая встроенную поддержку операционных систем Windows, Mac и Linux.

Windows использует Kerberos в качестве протокола проверки подлинности по умолчанию и ключевого компонента таких служб, как Active Directory (AD). Поставщики услуг широкополосного доступа используют его для аутентификации телеприставок и кабельных модемов, подключающихся к их сетям.

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

Простой протокол управления сетью (SNMP) — уровень 7 OSI

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

Компоненты архитектуры SNMP включают диспетчер, агент и информационную базу управления (MIB). Менеджер — это клиент, агент — это сервер, а MIB — это база данных. Агент SNMP отвечает на запросы менеджера, используя MIB. Хотя SNMP широко доступен, администраторы должны настроить параметры по умолчанию, чтобы обеспечить связь между агентами и системой управления сетью для реализации протокола.

С введением SNMPv3 в 2004 году протокол SNMP получил три важные функции безопасности: шифрование пакетов для предотвращения прослушивания, проверки целостности, чтобы гарантировать, что пакеты не были подделаны в пути, и аутентификацию для проверки того, что сообщения исходят из известного источника. .

HTTP и HTTPS — уровень 7 OSI

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

HTTPS — это безопасная версия HTTP, обеспечивающая безопасность связи между браузерами и веб-сайтами. Это помогает предотвратить спуфинг DNS и атаки «человек посередине», что важно для веб-сайтов, которые передают или получают конфиденциальную информацию. Все веб-сайты, требующие входа пользователя в систему или обработки финансовых транзакций, являются привлекательными целями для кражи данных и должны использовать HTTPS.

HTTPS работает по протоколу SSL или TLS, используя открытые ключи для обеспечения шифрования общих данных. HTTP использует порт 80 по умолчанию, а HTTPS использует порт 443 для безопасной передачи. При использовании HTTPS сервер и браузер должны установить параметры связи перед началом передачи данных.

Связанное содержимое:

SASE (Secure Access Service Edge) — это развивающаяся сетевая архитектура, которая сочетает функции сетевой безопасности с возможностями глобальной сети (WAN), обеспечивая единый подход к сетевой безопасности и подключению.

Протоколы безопасности для быстрого перехода BSS

Цзяньфэн Ма ³ ,
Чангуан Ван ⁴ и
Чжо Ма ⁴

Глава

218 доступов

Abstract

Наряду с быстрым развертыванием WLAN резко возрастет плотность беспроводных точек доступа. В этом случае непрерывность обслуживания требует, чтобы беспроводная система обеспечивала достаточную достоверность этих частых переключений между различными базовыми станциями. Например, при использовании аудиоуслуг через WLAN должна быть гарантирована пропускная способность, позволяющая мобильным клиентским устройствам установить новую ассоциацию с другой новой точкой доступа как можно скорее после разрыва соединения с прежней. Задержка, полученная в результате процесса передачи обслуживания, состоит из трех частей, включая время на зондирование и обнаружение, аутентификацию и повторную ассоциацию службы. Если задержка превышает 50 мс, то прерывание явно будет ощущаться ушами. Тем не менее задержка в существующей сети IEEE 802.11 обычно составляет в среднем несколько сотен миллисекунд, что может привести к негативным последствиям, таким как периодические прерывания передачи, потеря соединения, ухудшение качества звука и т.д. Таким образом, протокол быстрой передачи обслуживания играет важную роль в масштабном развертывании аудиоуслуг в сетях IEEE 802.11. В этой главе, согласно тщательному анализу IEEE 802.11r, который определяет быструю передачу обслуживания между точками доступа в WLAN ESS, представлены используемые протоколы безопасности. Чтобы компенсировать недостаток устойчивости схемы к DoS в стандарте, мы предлагаем две новые безопасные схемы быстрой передачи обслуживания, которые основаны на MIC и на основе хэш-цепочки. Наконец, мы представляем безопасное и быстрое решение для передачи обслуживания в зависимости от местоположения. Это решение характеризуется следующими функциями: гарантия качества обслуживания, определение местоположения и быстрое переключение на основе местоположения.

Скачать главу в формате PDF

Ссылки

IEEE Computer Society. IEEE 802.1f/D3. Рекомендуемая практика для взаимодействия точек доступа разных поставщиков через протокол между точками доступа в системах распределения, поддерживающих работу IEEE 802.11 ^TM. Нью-Йорк: IEEE, 2002.
. Google Scholar
Компьютерное общество IEEE. IEEE 802.11r-2008. Стандарт IEEE для информационных технологий — телекоммуникации и обмен информацией между системами — локальные и городские сети — особые требования. Часть 11: управление доступом к среде беспроводной ЛВС и поправка к спецификациям физического уровня 2: быстрый переход набора базовых услуг. Нью-Йорк: IEEE, 2008.
Google Scholar
Мишра А., Шин М. , Арбо В. Эмпирический анализ процесса передачи обслуживания MAC-уровня IEEE 802.11. Обзор компьютерных коммуникаций ACM, 2003 г., 33 (2): 93–102.
Перекрёстная ссылка Google Scholar
Рамани И., Сэвидж С. SyncScan: практическая быстрая передача обслуживания для инфраструктурных сетей IEEE 802.11: Proceedings of IEEE infocom 2005, 1(1): 675–684.
Google Scholar
Сампраку И., Бурас С., Карубалис Т. Быстрая и эффективная передача IP в беспроводных локальных сетях IEEE 802.11: ICWN’04: Материалы Международной конференции 2004 г. по беспроводным сетям. Лас-Вегас, Невада, США, 2004 г.: 249–255.
Google Scholar
Sharma S, Zhu N, Chiueh T. Передача мобильного IP с малой задержкой для беспроводных локальных сетей в режиме инфраструктуры. Журнал IEEE по отдельным областям связи, специальный выпуск по всем беспроводным IP-сетям, 2004 г. , 22 (4): 643–652.
Google Scholar
Велайос Х., Карлссон Г. Методы сокращения времени переключения уровня MAC IEEE 802.11b: ICC 2004: Proceedings of IEEE ICC 2004. Париж, Франция, 2004.
Google Scholar
Шин М., Мишра А., Арбо В. Улучшение задержки передачи обслуживания IEEE 802.11 с использованием графов соседей: MobiSys 2004: результаты ACM MobiSys 2004. Бостон, Массачусетс, США, 2004: 70–83.
Google Scholar
Мишра А., Шин М., Арбо В. А. Кэширование контекста с использованием графов соседей для быстрой передачи обслуживания в беспроводной сети: Труды IEEE infocom 2004. Гонконг, март 2004 г., версия 1: 351–311.
Google Scholar
Барг М., Халсебоч Р. , Эртинк Э. и др. Методы быстрой аутентификации для передачи обслуживания между беспроводными локальными сетями IEEE 802.11: Proceedings of ACM WMASH 2004. Филадельфия, Пенсильвания, США, 2004: 51–60.
Google Scholar
Pack S, Choi Y. Схема быстрой передачи обслуживания, основанная на прогнозировании мобильности в беспроводных локальных сетях общего пользования. Сообщения о слушаниях IEE, 2004 г., 151(5): 489–495.
Перекрёстная ссылка Google Scholar
Kim H, Park S, Park C и др. Выборочное сканирование каналов для быстрой передачи обслуживания в беспроводной локальной сети с использованием графа соседей. Материалы ITC-CSCC. Япония, июль 2004 г., Берлин: pringer, LNCS 3260: 194–203.
Google Scholar
Брик В., Мишра А., Банерджи С. Устранение задержек передачи обслуживания в беспроводных сетях IEEE 802.11 с использованием нескольких радиомодулей: приложения, опыт и оценка: Труды IMC 2005. Ассоциация USENIX, Беркли, Калифорния, США, 2005: 27–32.
Google Scholar
Waharte S, Ritzenthaler K et al. Выборочное активное сканирование для быстрой передачи обслуживания в WLAN с использованием сенсорных сетей: Труды IEEE MWCN 2004. 2004: 59–70.
Google Scholar
Пак С., Юнг Х., Квон Т. и др. SNC: схема выборочного кэширования соседей для быстрой передачи обслуживания в беспроводных сетях IEEE 802.11. Обзор мобильных вычислений и связи ACM, 2005 г., 9 (4): 39–49.
Перекрёстная ссылка Google Scholar

Ссылки на скачивание

Информация об авторе

Авторы и организации

Ключевая лаборатория компьютерных сетей и информационной безопасности (Министерство образования), Университет Сидянь, Сиань, 710071, Китай
Проф.