О сетях

Мир сетей сложен. Пользователи могут соединиться с Интернетом с помощью широкого диапазона технологий — кабельные модемы, DSL, Wi-Fi, сотовые соединения, спутниковые восходящие каналы, Ethernet и даже традиционные акустические модемы. Каждое из этих соединений имеет отличные характеристики, включая различия в пропускной способности, задержке, потере пакетов и надежности.

Для добавления дальнейшей сложности соединение пользователя с Интернетом не рассказывает целую историю. Продвигающийся от пользователя к Интернет-серверу, сетевые данные пользователя проходят куда угодно от одного до десятков физических межсоединений, любое из которых могло быть высокоскоростной строкой OC-768 (почти в 40 миллиардах бит в секунду), скудный модем на 300 бодов (в 300 битах в секунду), или что-либо промежуточное. Хуже, в любой момент, скорость соединения пользователя с сервером могла измениться решительно — кто-то мог включить микроволновую печь, вмешивающуюся в связь Wi-Fi пользователя, пользователь мог обойти или изгнать из сотового диапазона, кто-то с другой стороны мира мог начать загружать большой фильм от сервера, к которому пользователь пытается получить доступ и т.д.

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

Сразу

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

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

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

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

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

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

  Для добавления дальнейшей сложности иногда у пользователя может быть доступ к ресурсам только в то время как в определенных сетях. Например, AirPlay может соединиться с Apple TV только в то время как в той же сети. К ресурсам корпоративной сети можно получить доступ только в то время как на работе или по виртуальной частной сети (VPN). Визуальная Голосовая почта может быть доступной только по сети сотового поставщика услуг (в зависимости от поставщика услуг). И т.д.

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

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

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

  При помощи высшего уровня API Вы предоставляете операционной системе больше информации о том, что Вы фактически пытаетесь выполнить так, чтобы это могло более оптимально обработать Ваш запрос. Этот высокоуровневый APIs также решает многие самые сложные и трудные сетевые проблемы для Вас — кэширование, прокси, выбор из числа многократных IP-адресов для узла, и т.д. Если Вы пишете свой собственный низкоуровневый код для выполнения тех же задач, необходимо обработать ту сложность сами (и отладить и поддержать рассматриваемый код).

• Разработайте свое программное обеспечение тщательно для минимизации угроз безопасности. Используйте в своих интересах технологии безопасности, такие как Уровень защищенных сокетов (SSL) и Transport Layer Security (TLS), чтобы предотвратить спуфинг и скрыть уязвимые данные от любопытных глаз и тщательно исследовать недоверяемое содержание для предотвращения переполнения буфера и целочисленных переполнений.

Этот документ поможет Вам изучить эти понятия и больше.

Как использовать этот документ

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

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

Следующая глава, Оценивая Ваши Сетевые Потребности, предоставляет больше подробную информацию о выборе семьи API и определении, какие типы сетевых задач Ваша программа выполнит. Эта глава тогда указывает на Вас на другие главы (Обнаружение и Распространение Сетевых служб, Создание HTTP и Запросов HTTPS, и Используя Сокеты и Потоки Сокета), которые описывают некоторые общие сетевые задачи, которые Ваша программа, возможно, должна была бы выполнить.

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