По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Все, что нужно знать не разработчикам: SDK – это строительные блоки разработки приложений.
Если ваша компания занимается тем, что разрабатывает или добавляет функциональные возможности в приложение, то вы, вероятно, слышали, как ваши разработчики используют термин «SDK». SDK (software development kit) – это пакет разработки средств ПО (иногда его называют devkit). Как можно понять из названия, это набор инструментов и инструкций, которые разработчики используют для создания приложений. SDK избавляют разработчиков от необходимости писать каждый банальный фрагмент кода своими руками. Они помогают стандартизировать разработку, что позволяет приложениям без каких-либо затруднений работать на различном оборудовании, операционных системах и совместно с другими приложениями.
Итак, какое это вообще имеет для вас значение, если вы не разработчик программного обеспечения? Так как архитектура вашего приложения напрямую связана с его коммерческой ценностью, то, когда вы выбираете то, какие компоненты использовать (например, Stripe или PayPal для платежей), ваш выбор должен быть продиктован SDK. Здесь мы привели краткое описание того, что такое SDK, как они работают и как сравнить их по качеству.
Пакет разработки средств ПО (SDK - Software Development Kit): определение и примеры
SDK – набор инструментов, который используют разработчики для создания приложений с помощью готовых компонентов, тем самым не утруждая себя тем, чтобы создавать эти компоненты собственноручно. SDK предназначены для работы с определенными операционными системами, оборудованием и языками программирования.
А вот вам аналогия из реальной жизни: если вы собираетесь собрать книжную полку, то SDK – это все то, что вы найдете в коробке из IKEA, то есть предварительно собранные детали, инструменты и инструкции, как все это собрать. А чтобы, например, собрать стол без SDK, вам придется пойти в лес, срубить дерево, чтобы у вас был свой пиломатериал, причем использовать для этого придется топор, который вы тоже должны сделать сами.
Если, например, вы хотите создать мобильное приложение, то вам нужно загрузить iOS SDK от Apple. Это даст вам доступ к любым инструментам iPhone, которые вам будут нужны для того, чтобы создать приложение, например, подключение к камере, интерфейсу Siri или включение push-уведомлений. Аналогично, если вы хотите внедрить платформу Auth0 в свои мобильные и веб-приложения, то вы должны загрузить iOS SDK, Android SDK и веб-SDK.
Что находится в SDK?
Практически все SDK содержат несколько основных компонентов:
Библиотеки кода. Это исходный код, который разработчики могут подключают, чтобы приложение выполняло те функции, которые им нужно.
Программный интерфейс приложения (API - Application programming interface). Они позволяют приложению без проблем подключаться к другим службам (подробнее об этом позже).
Интегрированная среда разработки (IDE - Integrated development environment). Это интерфейс, с помощью которого разработчики пишут программы. В него встроен компилятор, который переводит высокоуровневый язык программирования, на котором написан исходный код SDK, на язык более низкого уровня, который можно использовать для сборки приложений.
Документация. Это инструкции для разработчиков, в которых описано, как нужно использовать код. Понятная и подробная документация – важный критерий хорошего SDK.
Отладчик. Отладка автоматически исправляет мелкие ошибки, упрощая тем самым процесс разработки приложения.
Примеры кода. Они помогают разработчикам начать работу. Это примеры кода в действии, которые показывают, как их можно использовать.
Некоторые SDK также содержат учебные руководства и другие инструментальные средства поддержки.
Виды SDK
Для создания большинства приложений используются самые различные SDK. Некоторые из этих SDK оптимизируют приложение для конкретного устройства или операционной системы, а некоторые позволяют разработчикам добавлять различные инструменты.
SDK с точки зрения аппаратных средств: SDK предназначены не только для мобильных и веб-приложений; они также используются для программирования Интернета вещей (IoT). Поэтому, если вы покупаете, например, набор солнечных батарей, то поставщик оборудования может включить в поставку SDK, чтобы разработчики могли запрограммировать их так, как им нужно.
Операционная система мобильного устройства: как мы уже говорили, для того, чтобы разработать приложение, которое бы работало как на Android, так и на Apple необходимы SDK для каждой ОС.
Язык программирования для веб-приложений: разработчикам требуются SDK, которые позволяют создавать веб-приложения на том языке программирования, который они выбрали, например, Python, Ruby, JavaScript или PHP.
SDK с открытым исходным кодом: это бесплатные SDK, и разработчики могут их модифицировать как сочтут нужным. Это может быть, как преимуществом, когда дело доходит до настройки, так и недостатком, когда возникают риски для безопасности.
Проприетарные SDK: в отличие от SDK с открытым исходным кодом, для проприетарных, или коммерческих, SDK нужна лицензия на использование, и к тому же разработчики не могут менять его исходный код.
SDK vs API
Различие между SDK и API может легко запутать вас, однако оно одновременно и очень простое, и очень важное.
API – это фрагменты кода, которые взаимодействуют между двумя частями программного обеспечения. Таким образом, если вы создаете приложение для совместных поездок, то вам нужны API, которые бы соединяли его с телефоном пользователя и, соответственно, возможностью обмена сообщениями, платежной платформой и GPS. Все эти элементы могут находиться в разных серверных частях, но API позволяет им взаимодействовать друг другом и обеспечивает беспроблемное взаимодействие с пользователем.
Большинство SDK содержат API, поэтому разработчики могут создавать приложения, которые подразумевают возможность подключения и взаимодействия. Без API подключение приложений чем-то похоже на знаменитую сцену из «Аполлона-13».
Но все не так просто, так как вы можете использовать API и без SDK. А в некоторых случаях разработчикам приходится выбирать между SDK и API, чтобы можно было произвести интеграцию с конкретной службой. Преимущество SDK заключается в том, что его проще и быстрее интегрировать (как стол из IKEA – большая часть работы уже сделана за вас). Преимущество API в том, что он более компактный (то есть не содержит библиотек кода для ненужных вам функций) и дает больше возможностей для индивидуальной настройки (если вы мастерите свой собственный стол, то вы можете спроектировать его так, как вам нужно, - любого размера, который вам нужен).
Составляющие хорошего SDK
Если вы создаете приложение, то, скорее всего, для таких функций, как оплата, обмен сообщениями или аутентификация, вы будете использовать SDK. Разработчикам крайне сложно дается создание этих компонентов, и любые ошибки могут повлечь за собой серьезные проблемы с безопасностью. При выборе поставщика для этих услуг, вы можете сравнивать цены и функции, но также вы должны обратить внимание на их SDK.
Вот что должно быть в хорошем SDK:
Легковесность: вам нужен SDK, который бы выполнял все необходимые функции с минимальным количеством кода. В противном случае мобильное приложение может занимать слишком много места на телефоне пользователя и работать медленнее, чем нужно. Когда вы перестраиваете устаревшее приложение, то стоит посмотреть, сколько кода используют ваши существующие решения и задаться вопросом, а не упростит ли их SDK.
Хорошая документация: представим: два практически идентичных SDK. Однако, если у одного есть подробная документация о том, как его использовать, а второй оставляет разработчиков разбираться с этим самостоятельно, то навряд ли их можно считать равными.
Индивидуальная настройка: некоторые SDK настраивать нельзя, то есть вы можете использовать их только такими, какие они есть. Это становится проблемой, когда разработчики решают, что хотят настроить продукт под свои уникальные потребности или добавить фирменное оформление или графику.
Безопасность: очень важно использовать SDK только из надежных источников, чтобы исключить возможность того, что вы нечаянно добавите вредоносный или иной нежелательный код в приложение. Из отчета SafeDK: «58% проверенных приложений все еще используют, как минимум, один SDK, который обращается к личным данным пользователя». В эпоху законов о конфиденциальности данных это может привести к тому, что ваше приложение может нажить себе юридических неприятностей.
Простота использования: хороший SDK должен предоставлять учебные руководства и примеры кода, а также давать разработчикам возможность обращаться к надежному сообществу или службам поддержки при возникновении каких-либо проблем.
SDK: не просто еще одна аббревиатура, которая сбивает с толку
Любая компания, которая создает новые приложения или добавляет новые функции в уже существующие, будет использовать SDK как часть процесса разработки. Но SDK – это не просто загадочные концепции программирования; они напрямую влияют на безопасность приложения, его индивидуальную настройку и срок до выпуска на рынок. Если вы не разработчик, то вам необязательно разбираться во всех тонкостях данной темы, но вы должны уметь задавать правильные вопросы.
Предыдущая статья из цикла про устранение неисправностей DHCP на Cisco доступна по ссылке.
Последняя статья будет посвящена некоторым проблемам с FHRP, мы начнем с VRRP!
Урок 1
В сценарии выше у нас есть проблема с HSRP. Сначала разберем топологию. С левой стороны находится клиент (мы используем маршрутизатор, чтобы иметь возможность воссоздать его в GNS3), который использует виртуальный IP-адрес в качестве шлюза по умолчанию. R2 и R3 настроены для HSRP. На правой стороне есть маршрутизатор с IP-адресом 4.4.4.4 на интерфейсе loopback0. К сожалению, наш клиент не может пропинговать 4.4.4.4. Что здесь происходит?
Сначала мы отправим эхо-запрос от клиента на IP-адрес 4.4.4.4. Вы видите символ U (недостижимый), поэтому мы знаем, что получаем ответ от шлюза по умолчанию.
Таблица маршрутизации была отключена на этом клиентском маршрутизаторе (нет ip-маршрутизации), но вы можете видеть, что шлюз по умолчанию был настроен. Давайте посмотрим, доступен ли этот IP-адрес.
Достигнуть шлюза по умолчанию не проблема, поэтому мы можем перенести фокус на R2 или R3.
Мы можем использовать команду show standby, чтобы убедиться, что R3 является активным маршрутизатором HSRP. Давайте проверим, может ли он достичь IP-адреса 4.4.4.4.
Увы ...пинг не проходит.
Его нет в таблице маршрутизации, и если вы посмотрите внимательно, то увидите, что FastEthernet1/0 не находится в таблице маршрутизации как непосредственно подключенный, это указывает на то, что что-то не так с этим интерфейсом.
Ну вот...интерфейс отключен.
R3(config)#interface fastEthernet 1/0
R3(config-if)#no shutdown
Включим его!
Ну вот, теперь он работает.
Проблема устранена ... теперь клиент может пинговать 4.4.4.4! Есть еще одна вещь, хотя ... мы используем HSRP, так что наш шлюз по умолчанию не является единственной точкой отказа, но в этом случае R3 имел сбой соединения...разве R2 не должен взять на себя управление?
interface tracking было включено, и вы можете видеть, что приоритет должен уменьшиться на 10, если интерфейс FastEthernet1/0 перейдет в состояние down. Это означает, что обычно R2 должен взять на себя управление, но preemption is disabled по умолчанию для HSRP.
R2(config)#interface fastEthernet 0/0
R2(config-if)#standby 1 preempt
R3(config)#interface fastEthernet 0/0
R3(config-if)#standby 1 preempt
Прежде чем отпраздновать нашу победу в устранении неполадок, мы должны убедиться, что эта проблема больше не возникнет в будущем. Мы включим приоритет на обоих маршрутизаторах. Теперь все готово!
Итог урока: убедитесь, что preemption включена для HSRP, если вы используете interface tracking
Урок 2
Вот та же топология, но на этот раз мы используем VRRP вместо HSRP. Однако проблема заключается в другом: клиент жалуется, что не все IP-пакеты попадают в 4.4.4.4.
Некоторые из IP-пакетов не поступают в 4.4.4.4.
IP-адрес шлюза: 192.168.123.254.
Шлюз пингуется без проблем.
R2 не может достичь 4.4.4.4, но у R3 нет никаких проблем. Прежде чем мы продолжим проверять, почему R2 не может достичь 4.4.4.4, мы взглянем на конфигурацию VRRP, чтобы увидеть, какой маршрутизатор является главным.
Вывод show vrrp интересен. Оба маршрутизатора считают, что они активны, и, если вы посмотрите внимательно, вы поймете, почему. Аутентификация включена, и в key-string имеется несоответствие. Поскольку оба маршрутизатора активны, половина пакетов окажется в R2, а остальные в R3. Вот почему наш клиент видит, что некоторые пакеты приходят, а другие нет. Давайте исправим нашу аутентификацию:
R2(config)#interface fa0/0
R2(config-if)#vrrp 1 authentication md5 key-string SECRET
Мы сделаем key-string одинаковыми.
Это сообщение в консоли R2 является многообещающим.
R3 был выбран в качестве главного маршрутизатора. Теперь давайте выясним, почему R2 не смог достичь 4.4.4.4, поскольку эта проблема устранена.
Странно, R2 показывает только одну запись в таблице маршрутизации, что-то не так с FastEthernet 1/0.
Кажется, кому-то нравится команда shutdown Имейте в виду, что это может быть что-то еще списки доступа, blocking traffic между R2 и R4, port-security (если был коммутатор в середине), интерфейсы в режиме err-disabled, неправильные IP-адреса и другое. Проверьте все!
R2(config)#interface fastEthernet 1/0
R2(config-if)#no shutdown
Включим интерфейс!
Проблема устранена!
Итог урока: убедитесь, что маршрутизаторы VRRP могут связаться друг с другом.
FTP расшифровывается как File Transfer Protocol, или протокол передачи данных. Это сетевой протокол/протокол обмена данными, благодаря которому файлы передаются между компьютерами через сеть TCP/IP (протокол управления передачей/интернет-протокол).
Примеры сетей TCP/IP:
HTTP (протокол передачи гипертекста)
HTTPS (протокол защищенной передачи гипертекста)
FTP (протокол передачи файлов)
Как работает протокол передачи файлов?
Для обмена файлами между компьютерами через FTP необходимо открыть FTP-сервер (о том, что это такое, ниже).
В зависимости от типа посещаемого сервера, для доступа к файлам вас могут попросить ввести имя пользователя и пароль. Соединения с сервером, которые не запрашивают авторизации до открытия доступа к файлам, называются анонимными FTP.
Как только пользователь успешно открыл/авторизовался на FTP-сервере, он может скачивать или загружать файлы на сервер.
Получить доступ к FTP-серверу можно одним из нижеприведенных способов:
Через веб-браузер. Вы можете напечатать адрес сервера в своем браузере. Он будет выглядеть примерно так: ftp.myftpfiles.com или https://www.myftpfiles.com. Оказавшись на сервере, вы можете работать с файлами, которые загрузил туда их владелец.
Через FTP-клиент
Что такое FTP-клиент?
FTP-клиент – это программное обеспечение для соединения между запрашивающим доступ компьютером и сервером, на котором хранятся файлы.
Существует великое множество различных FTP-клиентов. Они предлагают графический пользовательский интерфейс (GUI), с которым можно взаимодействовать.
Ниже показано, как выглядит FTP-клиент, и как им пользоваться. Мы будем работать в FileZilla.
В изображении выше видны текстовые поля. Адрес сервера вводится в текстовое поле Host. Текстовые поля Username и Password нужны для серверов, которые открывают доступ к файлам только после авторизации. Текстовое поле Port обычно имеет значение 21. Это специальный порт для FTP. После заполнения всех необходимых полей вы можете нажать Quickconnect и подключиться к серверу.
В левой части приложения есть local site, то есть мой компьютер со списком существующих директорий. Справа – Remote site, то есть место, где показывается вся информация и файлы на сервере.
Что такое FTP-сервер?
По сути, FTP-сервер – это компьютер, на который изначально загружались файлы. У каждого сервера есть FTP-адрес. Пользователь может открыть FTP-сервер через TCP/IP в браузере или через FTP-клиент.
Сервер позволяет посетителю загружать и скачивать файлы.
Безопасны ли FTP-сервера?
Хоть многие FTP-серверы и требуют авторизации, они не считаются защищенными, поскольку в протоколе отсутствует шифрование. Из-за этого повышается вероятность того, что доступ к файлам на FTP-сервере получат сторонние или нежелательные лица.
Самый предпочтительный и безопасный протокол для FTP – это SFTP (Secure File Transfer Protocol - защищенный протокол передачи данных). Это как HTTP и HTTPS.
SFTP считается более безопасным, поскольку данные на сервере зашифрованы.
К альтернативным вариантам относятся:
FTPS (File Transfer Protocol Secure)
HTTPS (Hypertext Transfer Protocol Secure)
AS2 (Applicability Statement 2)
Плюсы использования FTP
Вот несколько плюсов от использования FTP:
более быстрая передача файлов
поддержка многими хостами
возможность передачи больших файлов
возможность запланировать передачу файлов
возобновление передачи файлов после прерывания
Минусы использования FTP
Есть ряд минусов при использовании FTP:
FTP-серверам не хватает безопасности
основные браузеры (Chrome и Firefox) больше не поддерживают FTP
файлы и учетные данные пользователей не зашифрованы
на некоторых серверах могут присутствовать вредоносные файлы
Заключение
В данной статье мы поговорили о протоколе передачи файлов, который позволяет нам обмениваться файлами между компьютерами внутри сети.
Мы разобрали, что такое FTP-клиент и FTP-сервер. Кроме того, рассказали, почему FTP-серверы считаются незащищенными и предложили ряд более «безопасных» альтернатив. И, наконец, мы рассмотрели плюсы и минусы использования FTP.