Запрос учетных данных при доступе к сайтам полного доменного имени на основе WebDav в Windows
В этой статье описано решение проблемы, из-за которой вам будет предложено ввести учетные данные при доступе к сайтам полного доменного имени (FQDN) на основе web Distributed Authoring and Versioning (WebDav) в Windows.
Применимо к: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Исходный номер базы знаний: 943280
Симптомы
Рассмотрим следующий сценарий.
- Вы используете компьютер под управлением Windows Vista или более поздней версии Windows.
- WebDav используется для доступа к сайту полного доменного имени.
В этом сценарии вам будет предложено ввести свои учетные данные или вам будет отказано в доступе, даже если учетная запись пользователя, которую вы используете, имеет достаточные разрешения для доступа к этому сайту.
При работе с перемещенными папками в представлении обозревателя также может появиться следующее сообщение об ошибке:
Ваш клиент не поддерживает открытие этого списка с помощью проводника Windows.
Причина
В Windows Vista или более поздних версиях Windows служба WebClient используется, чтобы разрешить проводнику Windows взаимодействовать с ресурсом WebDAV. Служба WebClient использует службы WINDOWS HTTP (WinHTTP) для выполнения сетевых операций ввода-вывода на удаленном узле.
WinHTTP отправляет учетные данные пользователя только в ответ на запросы, которые выполняются на локальном сайте интрасети. Однако WinHTTP не проверяет параметры зоны безопасности в Internet Explorer, чтобы определить, находится ли веб-сайт в зоне, которая позволяет автоматически отправлять учетные данные.
Если прокси-сервер не настроен, WinHTTP отправляет учетные данные только на локальные сайты интрасети.
Если URL-адрес не содержит точки в имени сервера, как показано в следующем примере, предполагается, что сервер находится на локальном сайте интрасети. http://sharepoint/davshare
Если URL-адрес содержит точки, предполагается, что сервер находится в Интернете. Точки указывают, что используется FQDN-адрес. Таким образом, учетные данные не отправляются на этот сервер автоматически, если прокси-сервер не настроен и если этот сервер не указан для обхода прокси-сервера.
Сервер можно указать для обхода прокси-сервера с помощью списка обхода или скрипта конфигурации прокси-сервера.
В этом случае вам будет отказано в доступе или вам будет предложено ввести учетные данные, когда веб-сайт запрашивает учетные данные. Даже в этом случае параметры зоны безопасности игнорируются.
Решение
В этот раздел, описание метода или задачи включены действия, содержащие указания по изменению параметров реестра. Однако неправильное изменение параметров реестра может привести к возникновению серьезных проблем. Поэтому следует в точности выполнять приведенные инструкции. Для дополнительной защиты создайте резервную копию реестра, прежде чем редактировать его. Так вы сможете восстановить реестр, если возникнет проблема. Дополнительные сведения о резервном копировании и восстановлении реестра см. в следующей статье, чтобы просмотреть статью о резервном копировании и восстановлении реестра в Windows.
Сведения о реестре
Чтобы устранить эту проблему, создайте запись реестра. Для этого выполните следующие действия:
- Нажмите кнопку «Пуск», введите regedit и нажмите клавишу ВВОД.
- Найдите и выделите следующий подраздел реестра:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters - В меню «Правка » наведите указатель мыши на пункт «Создать» и выберите » Многостроковое значение».
- Введите AuthForwardServerList и нажмите клавишу ВВОД.
- В меню Правка щелкните Изменить.
- В поле данных «Значение » введите URL-адрес сервера, на котором размещена веб-папка, и нажмите кнопку » ОК».
Примечание. Вы также можете ввести список URL-адресов в поле данных «Значение «. Дополнительные сведения см. в разделе «Пример списка URL-адресов» этой статьи.
- Если вы добавили запись реестра AuthForwardServerList, имейте в виду, что при реализации обычной проверки подлинности или дайджест-проверки подлинности в сети использование записи реестра не может препятствовать запросу учетных данных. Это поведение предназначено для обычной проверки подлинности и дайджест-проверки подлинности.
- После изменения реестра необходимо перезапустить службу WebClient.
Пример списка URL-адресов
В поле данных « Значение» для новой записи можно ввести список URL-адресов, например в следующем примере:
- https://*.Contoso.com
- http://*.dns.live.com
- *.microsoft.com
Этот список URL-адресов позволяет службе WebClient отправлять учетные данные по следующим каналам:
- Любой зашифрованный канал для дочернего домена домена с именем Contoso.com .
- Любой небезопасный канал для дочернего домена домена с именем dns.live.com .
- Любой канал к серверу, имя которого заканчивается на .microsoft.com .
После настройки списка URL-адресов учетные данные будут автоматически выполнять проверку подлинности на серверах WebDAV, даже если эти серверы находятся в Интернете.
Что следует избегать в списке URL-адресов
- Не добавляйте символ звездочки (*) в конце URL-адреса. Это может создать угрозу безопасности. Например, не используйте следующий URL-адрес:
http://*.dns.live.* - Не добавляйте звездочку (*) перед строкой или после нее. Это может привести к тому, что служба WebClient отправит учетные данные пользователя на дополнительные серверы. Например, не используйте следующие URL-адреса:
- http://*Contoso.com В этом примере служба также отправляет учетные данные пользователя http://extra_charactersContoso.com в .
- http://Contoso*.com В этом примере служба также отправляет учетные данные пользователя http://Contosoextra_characters.com в .
- http://*.dns.live.com/
- http://*.dns.live.com/DavShare
- http://*dns.live.com:80
Этот список URL-адресов не влияет на параметры зоны безопасности. Этот список URL-адресов используется только для определенной цели пересылки учетных данных на серверы WebDAV. Список должен быть создан как можно более строго, чтобы избежать проблем безопасности. Кроме того, так как нет определенного списка запретов, учетные данные перенаправляться на все серверы, соответствующие этому списку.
Состояние
Корпорация Майкрософт подтвердила, что это проблема в продуктах Майкрософт, перечисленных в начале этой статьи.
Обратная связь
Были ли сведения на этой странице полезными?
Настройка веб-клиента удаленного рабочего стола для пользователей
Веб-клиент удаленного рабочего стола позволяет пользователям обращаться к инфраструктуре удаленных рабочих столов организации через совместимый браузер. Они смогут взаимодействовать с удаленными приложениями или рабочими столами, как с локальным компьютером, независимо от того, где они находятся. После настройки веб-клиента удаленного рабочего стола все, что нужно будет пользователям, чтобы приступить к работе — это URL-адрес, по которому они смогут обратиться к клиенту, а также учетные данные и поддерживаемый веб-браузер.
Веб-клиент поддерживает использование прокси приложения Azure AD, но не поддерживает прокси-службу веб-приложения. Дополнительные сведения см. в разделе С помощью служб удаленных рабочих столов с помощью служб прокси-сервера приложений.
Что потребуется для настройки веб-клиента
Перед началом работы необходимо помнить следующее.
- Убедитесь, что в вашем развертывании Удаленного рабочего стола есть шлюз удаленных рабочих столов, посредник подключений к удаленному рабочему столу и служба веб-доступа к удаленным рабочим столам на платформе Windows Server 2016 или Windows Server 2019.
- Убедитесь, что развертывание настроено для использования клиентских лицензий «на пользователя», а не клиентских лицензий «на устройство». В противном случае будут использованы все лицензии.
- Установите обновление KB4025334 для Windows 10 на шлюзе удаленных рабочих столов. Более поздние накопительные пакеты обновления могут уже содержать обновление из этой статьи базы знаний.
- Убедитесь, что общедоступные доверенные сертификаты настроены для ролей шлюза удаленных рабочих столов и веб-доступа к удаленным рабочим столам.
- Убедитесь, что все компьютеры, к которым подключены пользователи, работают в одной из следующих версий ОС:
- Windows 10
- Windows Server 2008 R2 или более поздней версии.
Пользователи ощутят более высокую производительность подключения к Windows Server 2016 (или более поздней версии) и Windows 10 (версии 1611 или более поздней версии).
Если вы использовали веб-клиент во время действия предварительной версии и установили версию, предшествующую версии 1.0.0, то сначала необходимо удалить более ранний клиент, а затем перейти на новую версию. Если появится сообщение об ошибке: «The web client was installed using an older version of RDWebClientManagement and must first be removed before deploying the new version» (Веб-клиент был установлен с помощью более ранней версии RDWebClientManagement и должен быть удален перед развертыванием новой версии), выполните следующие действия.
- Откройте командную строку с повышенными привилегиями PowerShell.
- Выполните командлет RDWebClientManagement Uninstall-Module, чтобы удалить новый модуль.
- Закройте и снова откройте командную строку с повышенными привилегиями PowerShell.
- Выполните командлет RDWebClientManagement Install-Module — RequiredVersion , чтобы установить более ранний модуль.
- Выполните командлет RDWebClient удаления, чтобы удалить более ранний веб-клиент.
- Выполните командлет RDWebClientManagement Uninstall-Module, чтобы удалить более ранний модуль.
- Закройте и снова откройте командную строку с повышенными привилегиями PowerShell.
- Выполните шаги обычной установки, как описано ниже.
Как опубликовать веб-клиент удаленного рабочего стола
Чтобы впервые установить веб-клиент, выполните следующие действия.
- На сервере посредника подключений к удаленному рабочему столу получите сертификат, используемый для подключений к удаленному рабочему столу, и экспортируйте его как CER-файл. Скопируйте CER-файл из посредника подключений к удаленному рабочему столу на сервер, которому назначена роль веб-доступа к удаленным рабочим столам.
- На сервере веб-доступа к удаленным рабочим столам откройте командную строку с повышенными привилегиями PowerShell.
- В Windows Server 2016 обновите модуль PowerShellGet, так как версия папки «Входящие» не поддерживает установку модуля управления веб-клиентом. Чтобы обновить PowerShellGet, выполните следующий командлет.
Install-Module -Name PowerShellGet -ForceПримечание. Для доступа к коллекция PowerShell требуется протокол TLS 1.2 или более поздней версии. Используйте следующую команду, чтобы включить TLS 1.2 в сеансе PowerShell:
[Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12Важно! Необходимо будет перезапустить PowerShell, чтобы обновление вступило в силу, в противном случае модуль может не работать.
Install-Module -Name RDWebClientManagementInstall-RDWebClientPackageImport-RDWebClientBrokerCert
Publish-RDWebClientPackage -Type Production -LatestУбедитесь, что можете получить доступ к веб-клиенту по его URL-адресу с именем вашего сервера в следующем формате: https://server_FQDN/RDWeb/webclient/index.html . В URL-адресе важно использовать имя сервера, которое соответствует общедоступному сертификату для веб-доступа к удаленным рабочим столам (обычно это полное доменное имя сервера).
Примечание. При выполнении командлета Publish-RDWebClientPackage может появиться предупреждение о том, что клиентские лицензии «на устройство» не поддерживаются, даже если развертывание настроено для использования клиентских лицензий «на пользователя». Если в развертывании используются клиентские лицензии «на пользователя», это предупреждение можно игнорировать. Мы отображаем его, чтобы убедиться, что вам известно об ограничении конфигурации.
Чтобы просмотреть список всех поддерживаемых командлетов модуля RDWebClientManagement, выполните следующий командлет PowerShell.
Get-Command -Module RDWebClientManagementКак обновить веб-клиент удаленного рабочего стола
Если доступна новая версия веб-клиента удаленного рабочего стола, выполните следующие действия, чтобы обновить развертывание, установив новый клиент.
-
Откройте командную строку с повышенными привилегиями PowerShell на сервере веб-доступа к удаленным рабочим столам и выполните следующий командлет, чтобы скачать последнюю доступную версию веб-клиента.
Install-RDWebClientPackagePublish-RDWebClientPackage -Type Test -LatestPublish-RDWebClientPackage -Type Production -LatestКак удалить веб-клиент удаленного рабочего стола
Чтобы удалить все следы веб-клиента, выполните следующие действия.
- На сервере веб-доступа к удаленным рабочим столам откройте командную строку с повышенными привилегиями PowerShell.
- Отмените публикацию тестового и рабочего клиентов, удалите все локальные пакеты, а затем удалите параметры веб-клиента.
Uninstall-RDWebClientUninstall-Module -Name RDWebClientManagementКак установить веб-клиент удаленного рабочего стола без подключения к Интернету
Выполните следующие действия, чтобы развернуть веб-клиент на сервере веб-доступа к удаленным рабочим столам, который не подключен к Интернету.
Установка без подключения к Интернету доступна для версии 1.0.1 и более поздних версий модуля PowerShell RDWebClientManagement.
По-прежнему требуется компьютер администратора с доступом к Интернету, чтобы скачать необходимые файлы перед их передачей на автономный сервер.
Пока что на компьютере пользователя требуется подключение к Интернету. Это будет устранено в будущем выпуске клиента, чтобы обеспечить сценарий полностью автономного режима.
На устройстве с доступом к Интернету
- Откройте командную строку PowerShell.
- Импортируйте модуль PowerShell управления веб-клиентом удаленного рабочего стола из коллекции PowerShell.
Import-Module -Name RDWebClientManagementSave-RDWebClientPackage "C:\WebClient\"Find-Module -Name "RDWebClientManagement" -Repository "PSGallery" | Save-Module -Path "C:\WebClient\"На сервере веб-доступа к удаленным рабочим столам
Следуйте инструкциям в разделе Как опубликовать веб-клиент удаленного рабочего стола, но вместо шагов 4 и 5 выполните следующее.
-
Получить последнюю версию модуля PowerShell для управления веб-клиентом можно двумя способами:
Импорт модуля управления веб-клиентами удаленного рабочего стола PowerShell:Import-Module -Name RDWebClientManagementInstall-RDWebClientPackage -Source "C:\WebClient\rdwebclient-1.0.1.zip"Подключение к посреднику подключений к удаленному рабочему столу без шлюза удаленных рабочих столов в Windows Server 2019
В этом разделе описывается, как обеспечить подключение веб-клиента к посреднику подключений к удаленному рабочему столу без шлюза удаленных рабочих столов в Windows Server 2019.
Настройка сервера посредника подключений к удаленному рабочему столу
Выполните следующие действия, если сертификат не привязан к серверу брокера удаленных рабочих столах
- Выберите Диспетчер серверов>Службы удаленных рабочих столов.
- В разделе Обзор развертывания выберите раскрывающееся меню Задачи.
- Выберите Edit Deployment Properties (Изменить свойства развертывания), откроется новое окно Свойства развертывания будет открыт.
- В окне Свойства развертывания в меню слева выберите Сертификаты.
- Из списка «Уровни сертификатов» выберите Посредник подключений к удаленному рабочему столу: включение единого входа в систему. У вас есть два варианта: (1) создайте новый сертификат или (2) существующий сертификат.
Выполните следующие действия, если сертификат, ранее привязанный к серверу брокера удаленных рабочих столах
- Откройте сертификат, привязанный к посреднику, и скопируйте значение Thumbprint.
- Чтобы привязать этот сертификат к защищенному порту 3392, откройте командную строку PowerShell с повышенными привилегиями и выполните следующую команду, заменив «< thumbprint >« значением, скопированным на предыдущем шаге.
netsh http add sslcert ipport=0.0.0.0:3392 certhash="" certstorename="Remote Desktop" appid=""Примечание. Чтобы проверить, был ли сертификат привязан правильно, выполните следующую команду.
netsh http show sslcertВ списке привязок SSL-сертификатов убедитесь, что правильный сертификат привязан к порту 3392.
Настройка узла сеансов удаленных рабочих столов
Если сервер узла сеансов удаленных рабочих столов отличается от сервера посредника подключений к удаленному рабочему столу, выполните следующие действия.
- Создайте сертификат для компьютера узла сеансов удаленных рабочих столов, откройте его и скопируйте значение Thumbprint.
- Чтобы привязать этот сертификат к защищенному порту 3392, откройте командную строку PowerShell с повышенными привилегиями и выполните следующую команду, заменив «< thumbprint >« значением, скопированным на предыдущем шаге.
netsh http add sslcert ipport=0.0.0.0:3392 certhash="" appid=""Примечание. Чтобы проверить, был ли сертификат привязан правильно, выполните следующую команду.
netsh http show sslcertВ списке привязок SSL-сертификатов убедитесь, что правильный сертификат привязан к порту 3392.
Общие наблюдения
- Убедитесь, что узел сеансов удаленных рабочих столов и сервер посредника подключений к удаленному рабочему столу выполняются в Windows Server 2019.
- Убедитесь, что для узла сеансов удаленных рабочих столов и сервера посредника подключений к удаленному рабочему столу настроены общедоступные доверенные сертификаты.
Примечание. Если узел сеансов удаленных рабочих столов и сервер посредника подключений к удаленному рабочему столу работают на одном компьютере, необходимо настроить только сертификат сервера посредника подключений к удаленному рабочему столу. Если узел сеансов удаленных рабочих столов и сервер посредника подключений к удаленному рабочему столу используют разные компьютеры, то для них должны быть настроены уникальные сертификаты.
Как предварительно настроить параметры для пользователей веб-клиента удаленного рабочего стола
В этом разделе описывается, как использовать PowerShell для настройки параметров для развертывания веб-клиента удаленного рабочего стола. Эти командлеты PowerShell позволяют управлять возможностями пользователя изменять параметры в соответствии с требованиями безопасности или рабочим процессом вашей организации. Следующие параметры находятся на боковой панели Параметры веб-клиента.
«Suppress telemetry» (Отключение телеметрии)
По умолчанию пользователь может включить или отключить сбор данных телеметрии, которые отправляются в корпорацию Майкрософт. Сведения о собираемых данных телеметрии майкрософт см. в нашем заявлении о конфиденциальности по ссылке на боковой панели «Сведения «.
Будучи администратором, вы можете отключить сбор данных телеметрии для развертывания с помощью следующего командлета PowerShell.
Set-RDWebClientDeploymentSetting -Name "SuppressTelemetry" $trueПо умолчанию пользователь может включить или отключить сбор данных телеметрии. Логическое значение $false будет соответствовать поведению клиента по умолчанию. Логическое значение $true отключает телеметрию и запрещает включение телеметрии пользователем.
«Remote resource launch method» (Метод запуска удаленного ресурса)
В настоящее время этот параметр работает только с веб-клиентом RDS, а не с веб-клиентом Виртуального рабочего стола Azure.
По умолчанию пользователи могут запускать удаленные ресурсы (1) в браузере или (2), скачав .rdp файл для обработки с другим клиентом, установленным на своем компьютере. Если вы администратор, вы можете задать для своего развертывания строго определенный способ запуска удаленных ресурсов с помощью следующей команды PowerShell:
Set-RDWebClientDeploymentSetting -Name "LaunchResourceInBrowser" ($true|$false)По умолчанию пользователь может выбрать любой из методов запуска. Логическое значение $true вынудит пользователя запускать ресурсы в браузере. Логическое значение $false заставляет пользователя запускать ресурсы, скачивая .rdp файл для обработки с помощью локально установленного клиента RDP.
Сброс конфигурации RDWebClientDeploymentSetting до значений по умолчанию
Чтобы сбросить параметр веб-клиента на уровне развертывания до конфигурации по умолчанию, выполните следующий командлет PowerShell и укажите имя сбрасываемого параметра, используя параметр -name.
Reset-RDWebClientDeploymentSetting -Name "LaunchResourceInBrowser" Reset-RDWebClientDeploymentSetting -Name "SuppressTelemetry"Устранение неполадок
Если пользователь сообщает о следующих проблемах при первом запуске веб-клиента, в разделах ниже описывается, как устранить эти проблемы.
Что делать, если в браузере пользователя отображается предупреждение о безопасности при попытке получения доступа к веб-клиенту
Возможно, роль веб-доступа к удаленным рабочим столам не использует доверенный сертификат. Убедитесь, что для роли веб-доступа к удаленным рабочим столам настроен общедоступный доверенный сертификат.
Если это не помогло, возможно, имя сервера в URL-адресе клиента отличается от имени, указанного в сертификате для веб-доступа к удаленным рабочим столам. Убедитесь, что в URL-адресе используется полное доменное имя сервера, на котором размещена роль веб-доступа к удаленным рабочим столам.
Что делать, если пользователь не может подключиться к ресурсу с помощью веб-клиента, хотя и видит соответствующий элемент в разделе «Все ресурсы»
Если пользователь сообщил, что он не может подключиться к ресурсам с помощью веб-клиента, хотя видит их в списке, проверьте следующее.
- Правильно ли настроена роль шлюза удаленных рабочих столов для использования общедоступного доверенного сертификата?
- Установлены ли необходимые обновления на сервер шлюза удаленных рабочих столов? Убедитесь, что на сервере установлено обновление KB4025334.
Если пользователь при попытке подключения получает сообщение об ошибке «unexpected server authentication certificate was received» (был получен непредвиденный сертификат аутентификации), то в нем будет отображен отпечаток сертификата. Выполните поиск в диспетчере сертификатов на сервере посредника подключений к удаленному рабочему столу с помощью этого отпечатка, чтобы найти соответствующий сертификат. Убедитесь, что сертификат настроен для использования для роли посредника подключений к удаленному рабочему столу на странице свойств развертывания Удаленного рабочего стола. Убедившись, что срок действия сертификата еще не истек, скопируйте сертификат в виде CER-файла на сервер веб-доступа к удаленным рабочим столам и выполните следующую команду на сервере веб-доступа к удаленным рабочим столам, заменив значение в квадратных скобках путем к файлу сертификата.
Import-RDWebClientBrokerCert
Диагностика проблем с помощью журнал консоли
Если не удается устранить проблему, следуя инструкциям по устранению неполадок в этой статье, попробуйте самостоятельно диагностировать источник проблемы, просмотрев журнал консоли в браузере. Веб-клиент предоставляет метод для записи действий из журнала консоли браузера при использовании веб-клиента для диагностики проблем.
- Щелкните многоточие в правом верхнем углу и перейдите на страницу About (О программе) с помощью раскрывающегося меню.
- В разделе Capture support information (Запись сведения для поддержки) нажмите кнопку Start recording (Начать запись).
- Выполните операции в веб-клиенте, создав проблему, которую вы пытаетесь диагностировать.
- Перейдите на страницу About (О программе) и нажмите кнопку Stop recording (Остановить запись).
- Браузер автоматически скачает TXT-файл RD Console Logs.txt. Этот файл содержит полное действие журнала консоли, созданное при воспроизведении целевой проблемы.
В консоль также можно перейти непосредственно через браузер. Консоль обычно находится в разделе средств разработчика. Например, можно открыть журнал в Microsoft Edge, нажав клавишу F12 или щелкнув многоточие, а затем открыв меню Дополнительные средства>Средства разработчика.
Помощь в работе с веб-клиентом
Если возникла проблема, которую не удается устранить с помощью инструкций из этой статьи, сообщите нам о ней на форуме, посвященном Виртуальному рабочему столу Azure, на портале сообщества Microsoft Tech Community.
Клиент-сервер
Теперь, когда вы знаете цель и потенциальные преимущества программирования на стороне сервера, мы подробно рассмотрим, что происходит, когда сервер получает «динамический запрос» от браузера. Поскольку большая часть серверного кода веб-сайта обрабатывает запросы и ответы аналогичным образом, это поможет вам понять, что нужно делать при написании большей части собственного кода.
Перед стартом: Базовая компьютерная грамотность. Базовое понимание того, что такое веб-сервер. Цель: Изучить взаимодействие между клиентом и сервером на динамическом веб-сайте и, в частности, узнать, какие действия нужно произвести в коде серверной части. В обсуждении нет реального кода, поскольку мы ещё не выбрали, какой именно веб-фреймворк будем использовать для написания нашего кода! Тем не менее, это обсуждение всё ещё очень актуально, поскольку описанное поведение должно быть реализовано вашим серверным кодом независимо от того, какой язык программирования или веб-фреймворк вы выберите.
Веб-серверы и HTTP (для начинающих)
Веб-браузеры взаимодействуют с веб-серверами при помощи протокола передачи гипертекста (HTTP). Когда вы кликаете на ссылку на странице, заполняете форму или производите поиск, браузер отправляет на сервер HTTP-запрос.
Этот запрос включает:
- Путь (URL), который определяет целевой сервер и ресурс (например, HTML-файл, конкретная точка данных на сервере или запускаемый инструмент).
- Метод, который определяет необходимое действие (например, получить файл, сохранить или обновить какие-либо данные). Различные методы/команды и связанные с ними действия перечислены ниже:
- GET – получить определённый ресурс (например, HTML-файл, содержащий информацию о товаре или список товаров).
- POST – создать новый ресурс (например, добавить новую статью на вики, добавить новый контакт в базу данных).
- HEAD – получить метаданные об определённом ресурсе без получения содержания, как это делает запрос GET . Например, вы можете использовать запрос HEAD , чтобы узнать, когда ресурс в последний раз обновлялся, и только потом использовать (более «затратный») запрос GET , чтобы загрузить сам ресурс, если он был изменён.
- PUT – обновить существующий ресурс (или создать новый, если таковой не существует).
- DELETE – удалить определённый ресурс.
- TRACE , OPTIONS , CONNECT , PATCH – эти команды используются для менее популярных/более сложных задач, поэтому пока мы не будем их рассматривать.
- URL-параметры: GET запросы зашифровывают данные в URL-адресе, который отправляется на сервер, путём добавления пар имя/значение в его конец, например, http://mysite.com?name=Fred&age=11 . В этом случае всегда ставится знак вопроса ( ? ), отделяющий основную часть URL-адреса от URL-параметров, знак равно (=), отделяющий каждое имя от соответствующего ему значения, и амперсанд (&), разделяющий пары. URL-параметры, по своей сути, «небезопасны», так как могут быть изменены пользователями и затем отправлены повторно. В результате, URL-параметры / GET запросы не используются для запросов, которые обновляют данные на сервере.
- POST данные. POST запросы добавляют новые ресурсы, данные которых зашифрованы в теле самого запроса.
- Куки-файлы клиентской части. Куки-файлы содержат данные сессий о клиенте, включая ключи, которые сервер может использовать для определения статуса его авторизации и разрешения/права доступа к ресурсам.
Веб-серверы ожидают сообщений с запросами от клиентов, обрабатывают их, когда они приходят и отвечают веб-браузеру через сообщение с HTTP-ответом. Ответ содержит Код статуса HTTP-ответа, который показывает, был ли запрос успешным (например, « 200 OK » означает успех, « 404 Not Found » если ресурс не может быть найден, « 403 Forbidden », если пользователь не имеет права просматривать ресурс, и т. д.). Тело успешного ответа на запрос GET будет содержать запрашиваемый ресурс.
После того как HTML-страница возвращена, она отрисовывается браузером. Во время этого браузер может обнаружить ссылки на другие ресурсы (например, HTML-страница обычно ссылается на JavaScript и CSS-файлы) и послать отдельные HTTP-запросы для загрузки этих файлов.
Как статические, так и динамические веб-сайты (речь о которых идёт в следующих разделах) используют точно такой же протокол/шаблоны обмена данными.
Пример GET запроса/ответа
Вы можете сформировать простой GET запрос кликнув по ссылке или через поиск по сайту (такой как страница поисковой системы). Например, HTTP-запрос, отправленный во время выполнения запроса «client server overview» на сайте MDN, будет во многом похож на текст ниже (он не будет идентичным, потому что части сообщения зависят от вашего браузера/настроек).
Примечание: Формат HTTP сообщения определён в «веб-стандарте» (RFC7230). Вам не нужно знать этот уровень детализации, но, по крайней мере, теперь вы знаете, откуда это появилось!
Запрос
Каждая строка запроса содержит информацию о запросе. Первая часть называется заголовок и содержит важную информацию о запросе, точно так же, как HTML head содержит важную информацию о HTML-документе (но не содержимое документа, которое расположено внутри тэга «body»):
GET https://developer.mozilla.org/en-US/search?q=client+server+overview&topic=apps&topic=html&topic=css&topic=js&topic=api&topic=webdev HTTP/1.1 Host: developer.mozilla.org Connection: keep-alive Pragma: no-cache Cache-Control: no-cache Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Referer: https://developer.mozilla.org/en-US/ Accept-Encoding: gzip, deflate, sdch, br Accept-Language: en-US,en;q=0.8,es;q=0.6 Cookie: sessionid=6ynxs23n521lu21b1t136rhbv7ezngie; csrftoken=zIPUJsAZv6pcgCBJSCj1zU6pQZbfMUAT; dwf_section_edit=False; dwf_sg_task_completion=False; _gat=1; _ga=GA1.2.1688886003.1471911953; ffo=true
Первая и вторая строки содержат большую часть информации, о которой говорилось выше:
- Тип запроса ( GET ).
- URL целевого ресурса ( /en-US/search ).
- URL-параметры ( q=client%2Bserver%2Boverview&topic=apps&topic=html&topic=css&topic=js&topic=api&topic=webdev ).
- Целевой/хост-веб-сайт (developer.mozilla.org).
- Конец первой строки также содержит короткую строку, идентифицирующую версию протокола ( HTTP/1.1 ).
Последняя строка содержит информацию о клиентских куки — в данном случае можно увидеть куки, включающие id для управления сессиями ( Cookie: sessionid=6ynxs23n521lu21b1t136rhbv7ezngie; . ).
Оставшиеся строки содержат информацию об используемом браузере и о видах ответов, которые он может обработать. Например, здесь вы можете увидеть:
- Мой браузер ( User-Agent ) — Mozilla Firefox ( Mozilla/5.0 ).
- Он может принимать информацию, упакованную в gzip ( Accept-Encoding: gzip ).
- Он может принимать указанные кодировки ( Accept-Charset: ISO-8859-1,UTF-8;q=0.7,*;q=0.7 ) и языков ( Accept-Language: de,en;q=0.7,en-us;q=0.3 ).
- Строка Referer идентифицирует адрес веб-страницы, содержащей ссылку на этот ресурс (то есть источник оригинального запроса, https://developer.mozilla.org/en-US/ ).
HTTP-запрос может также содержать body, но в данном случае этого нет.
Ответ
Первая часть ответа на запрос показана ниже. Заголовок содержит следующую информацию:
- Первая строка содержит код ответа 200 OK , говорящий о том, что запрос выполнен успешно.
- Мы можем видеть, что ответ имеет text/html формат ( Content-Type ).
- Также мы видим, что ответ использует кодировку UTF-8 ( Content-Type: text/html; charset=utf-8 ).
- Заголовок также содержит длину ответа ( Content-Length: 41823 ).
В конце сообщения мы видим содержимое body, содержащее HTML-код возвращаемого ответа.
HTTP/1.1 200 OK Server: Apache X-Backend-Server: developer1.webapp.scl3.mozilla.com Vary: Accept,Cookie, Accept-Encoding Content-Type: text/html; charset=utf-8 Date: Wed, 07 Sep 2016 00:11:31 GMT Keep-Alive: timeout=5, max=999 Connection: Keep-Alive X-Frame-Options: DENY Allow: GET X-Cache-Info: caching Content-Length: 41823 .
Остальная часть заголовка ответа содержит информацию об ответе (например, когда он был сгенерирован), сервере и о том, как он ожидает, что браузер обработает страницу (например, строка X-Frame-Options: DENY говорит браузеру не допускать внедрения этой страницы, если она будет внедрена в (en-US) на другом сайте).
Пример POST запроса/ответа
HTTP POST создаётся, когда вы отправляете форму, содержащую информацию, которая должна быть сохранена на сервере.
Запрос
В приведённом ниже тексте показан HTTP-запрос, сделанный когда пользователь загружает новые данные профиля на этом сайте. Формат запроса почти такой же, как пример запроса GET , показанный ранее, хотя первая строка идентифицирует этот запрос как POST .
POST https://developer.mozilla.org/en-US/profiles/hamishwillee/edit HTTP/1.1 Host: developer.mozilla.org Connection: keep-alive Content-Length: 432 Pragma: no-cache Cache-Control: no-cache Origin: https://developer.mozilla.org Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36 Content-Type: application/x-www-form-urlencoded Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Referer: https://developer.mozilla.org/en-US/profiles/hamishwillee/edit Accept-Encoding: gzip, deflate, br Accept-Language: en-US,en;q=0.8,es;q=0.6 Cookie: sessionid=6ynxs23n521lu21b1t136rhbv7ezngie; _gat=1; csrftoken=zIPUJsAZv6pcgCBJSCj1zU6pQZbfMUAT; dwf_section_edit=False; dwf_sg_task_completion=False; _ga=GA1.2.1688886003.1471911953; ffo=true csrfmiddlewaretoken=zIPUJsAZv6pcgCBJSCj1zU6pQZbfMUAT&user-username=hamishwillee&user-fullname=Hamish+Willee&user-title=&user-organization=&user-location=Australia&user-locale=en-US&user-timezone=Australia%2FMelbourne&user-irc_nickname=&user-interests=&user-expertise=&user-twitter_url=&user-stackoverflow_url=&user-linkedin_url=&user-mozillians_url=&user-facebook_url=
Основное различие заключается в том, что URL-адрес не имеет параметров. Как вы можете видеть, информация из формы закодирована в теле запроса (например, новое полное имя пользователя устанавливается с использованием: &user-fullname=Hamish+Willee ).
Ответ
Ответ от запроса показан ниже. Код состояния « 302 Found » сообщает браузеру, что сообщение обработано, и что необходим второй HTTP-запрос для загрузки страницы, указанной в поле Location . В остальном информация аналогична информации для ответа на запрос GET .
HTTP/1.1 302 FOUND Server: Apache X-Backend-Server: developer3.webapp.scl3.mozilla.com Vary: Cookie Vary: Accept-Encoding Content-Type: text/html; charset=utf-8 Date: Wed, 07 Sep 2016 00:38:13 GMT Location: https://developer.mozilla.org/en-US/profiles/hamishwillee Keep-Alive: timeout=5, max=1000 Connection: Keep-Alive X-Frame-Options: DENY X-Cache-Info: not cacheable; request wasn't a GET or HEAD Content-Length: 0
Примечание: HTTP-ответы и запросы, показанные в этих примерах, были захвачены с помощью приложения Fiddler, но вы можете получить аналогичную информацию с помощью веб-снифферов (например, http://web-sniffer.net/) или с помощью расширений браузера, таких как HttpFox. Вы можете попробовать это сами. Воспользуйтесь любым из предложенных инструментов, а затем перейдите по сайту и отредактируйте информацию профиля, чтобы увидеть различные запросы и ответы. В большинстве современных браузеров также есть инструменты, которые отслеживают сетевые запросы (например, инструмент Network Monitor в Firefox).
Статические сайты
Статический сайт — это тот, который возвращает тот же жёсткий кодированный контент с сервера всякий раз, когда запрашивается конкретный ресурс. Например, если у вас есть страница о товаре в /static/myproduct1.html , эта же страница будет возвращена каждому пользователю. Если вы добавите ещё один подобный товар на свой сайт, вам нужно будет добавить ещё одну страницу (например, myproduct2.html ) и так далее. Это может стать действительно неэффективным — что происходит, когда вы попадаете на тысячи страниц товаров? Вы повторяли бы много кода на каждой странице (основной шаблон страницы, структуру и т. д.), И если бы вы захотели изменить что-либо в структуре страницы — например, добавить новый раздел «связанные товары» — тогда вам придётся менять каждую страницу отдельно.
Примечание: Статические сайты превосходны, когда у вас небольшое количество страниц и вы хотите отправить один и тот же контент каждому пользователю. Однако их обслуживание может потребовать значительных затрат по мере увеличения количества страниц.
Давайте вспомним, как это работает, снова взглянув на диаграмму архитектуры статического сайта, на которую мы смотрели в последней статье.

Когда пользователь хочет перейти на страницу, браузер отправляет HTTP-запрос GET с указанием URL-адреса его HTML-страницы. Сервер извлекает запрошенный документ из своей файловой системы и возвращает HTTP-ответ, содержащий документ и код состояния HTTP Response status code 200 OK (успех). Сервер может вернуть другой код состояния, например, « 404 Not Found », если файл отсутствует на сервере или « 301 Moved Permanently », если файл существует, но был перемещён в другое место.
Серверу для статического сайта нужно будет только обрабатывать GET-запросы, потому что сервер не сохраняет никаких модифицируемых данных. Он также не изменяет свои ответы на основе данных HTTP-запроса (например, URL-параметров или файлов cookie).
Понимание того, как работают статические сайты, тем не менее полезно при изучении программирования на стороне сервера, поскольку динамические сайты точно так же обрабатывают запросы для статических файлов (CSS, JavaScript, статические изображения и т. д.).
Динамические сайты
Динамический сайт — это тот, который может генерировать и возвращать контент на основе конкретного URL-адреса запроса и данных (а не всегда возвращать один и тот же жёсткий код для определённого URL-адреса). Используя пример сайта товара, сервер будет хранить «данные» товара в базе данных, а не отдельные HTML-файлы. При получении GET -запроса для товара сервер определяет идентификатор товара, извлекает данные из базы данных и затем создаёт HTML-страницу для ответа, вставляя данные в HTML-шаблон. Это имеет большие преимущества перед статическим сайтом:
Использование базы данных позволяет эффективно хранить информацию о товаре с помощью легко расширяемого, изменяемого и доступного для поиска способа.
Использование HTML-шаблонов позволяет очень легко изменить структуру HTML, потому что это нужно делать только в одном месте, в одном шаблоне, а не через потенциально тысячи статических страниц.
Анатомия динамического запроса
В этом разделе представлен пошаговый обзор «динамического» цикла HTTP-запроса и ответа, основываясь на том, что мы рассмотрели в последней статье, с гораздо более подробной информацией. Чтобы не отдаляться от практики, мы будем использовать контекст веб-сайта менеджера спортивной команды, где тренер может выбрать имя своей команды и размер команды в HTML-форме и вернуться к предлагаемому «лучшему составу» для своей следующей игры.
На приведённой ниже диаграмме показаны основные элементы веб-сайта «team coach», а также пронумерованные ярлыки для последовательности операций, когда тренер обращается к списку «лучших команд». Частями сайта, которые делают его динамичным, являются веб-приложение (так мы будем ссылаться на серверный код, обрабатывающий HTTP-запросы и возвращающие HTTP-ответы), база данных, которая содержит информацию об игроках, командах, тренерах и их отношениях, и HTML-шаблоны.

После того, как тренер отправит форму с именем команды и количеством игроков, последовательность операций будет следующей:
- Веб-браузер отправит HTTP-запрос GET на сервер с использованием базового URL-адреса ресурса ( /best ) и кодирования номера команды и игрока в форме URL-параметров (например, /best?team=my_team_name&show=11) или как часть URL-адреса (например, /best/my_team_name/11/ ). Запрос GET используется, потому что речь идёт только о запросе выборки данных (а не об их изменении).
- Веб-сервер определяет, что запрос является «динамическим» и пересылает его в веб-приложение для обработки (веб-сервер определяет, как обрабатывать разные URL-адреса на основе правил сопоставления шаблонов, определённых в его конфигурации).
- Веб-приложение определяет, что цель запроса состоит в том, чтобы получить «лучший список команд» на основе URL ( /best/ ) и узнать имя команды и количество игроков из URL-адреса. Затем веб-приложение получает требуемую информацию из базы данных (используя дополнительные «внутренние» параметры, чтобы определить, какие игроки являются «лучшими», и, возможно, определяя личность зарегистрированного тренера из файла cookie на стороне клиента).
- Веб-приложение динамически создаёт HTML-страницу, помещая данные (из базы данных) в заполнители внутри HTML-шаблона.
- Веб-приложение возвращает сгенерированный HTML в веб-браузер (через веб-сервер) вместе с кодом состояния HTTP 200 («успех»). Если что-либо препятствует возврату HTML, веб-приложение вернёт другой код, например, «404», чтобы указать, что команда не существует.
- Затем веб-браузер начнёт обрабатывать возвращённый HTML, отправив отдельные запросы, чтобы получить любые другие файлы CSS или JavaScript, на которые он ссылается (см. шаг 7).
- Веб-сервер загружает статические файлы из файловой системы и возвращает их непосредственно в браузер (опять же, правильная обработка файлов основана на правилах конфигурации и сопоставлении шаблонов URL).
Операция по обновлению записи в базе данных будет обрабатываться аналогичным образом, за исключением того, что, как и любое обновление базы данных, HTTP-запрос из браузера должен быть закодирован как запрос POST.
Выполнение другой работы
Задача веб-приложения — получать HTTP-запросы и возвращать HTTP-ответы. Хотя взаимодействие с базой данных для получения или обновления информации является очень распространённой задачей, код может делать другие вещи одновременно или вообще не взаимодействовать с базой данных.
Хорошим примером дополнительной задачи, которую может выполнять веб-приложение, является отправка электронной почты пользователям для подтверждения их регистрации на сайте. Сайт также может выполнять протоколирование или другие операции.
Возвращение чего-то другого, кроме HTML
Серверный код сайта может возвращать не только HTML-фрагменты и файлы в ответе. Он может динамически создавать и возвращать другие типы файлов (текст, PDF, CSV и т. д.) или даже данные (JSON, XML и т. д.).
Идея вернуть данные в веб-браузер, чтобы он мог динамически обновлять свой собственный контент (AJAX) существует довольно давно. Совсем недавно «Одностраничные приложения» стали популярными, где весь сайт написан с одним HTML-файлом, который динамически обновляется по мере необходимости. Веб-сайты, созданные с использованием приложений такого рода, переносят большие вычислительные затраты с сервера на веб-браузер и приводят к тому, что веб-сайты, ведут себя больше как нативные приложения (очень отзывчивые и т. д.).
Веб-фреймворки упрощают веб-программирование на стороне сервера
Веб-фреймворки на стороне сервера делают написание кода для обработки описанных выше операций намного проще.
Одной из наиболее важных операций, которые они выполняют, является предоставление простых механизмов для сопоставления URL-адресов для разных ресурсов/страниц с конкретными функциями обработчика. Это упрощает сохранение кода, связанного с каждым типом ресурса, отдельно от остального. Это также имеет преимущества с точки зрения обслуживания, поскольку вы можете изменить URL-адрес, используемый для доставки определённой функции в одном месте, без необходимости изменять функцию обработчика.
Для примера рассмотрим следующий код Django (Python), который связывает два URL-шаблона с двумя функциями просмотра. Первый шаблон проверяет, что HTTP-запрос с URL-адресом ресурса /best будет передан функции с именем index() в модуле views . Запрос, который имеет шаблон « /best/junior », вместо этого будет передан функции просмотра junior() .
# file: best/urls.py # from django.conf.urls import url from . import views urlpatterns = [ # example: /best/ url(r'^$', views.index), # example: /best/junior/ url(r'^junior/$', views.junior), ]
Примечание: Первые параметры в функциях url() могут выглядеть немного необычно (например, r’^junior/$’ , потому что они используют метод сопоставления шаблонов под названием «регулярные выражения» (RegEx или RE). Вам не нужно знать, как работают регулярные выражения на этом этапе, кроме того, что они позволяют нам сопоставлять шаблоны в URL-адресе (а не жёстко закодированные значения выше) и использовать их в качестве параметров в наших функциях просмотра. В качестве примера, действительно простой RegEx может говорить «соответствовать одной заглавной букве, за которой следуют от 4 до 7 строчных букв».
Веб-фреймворк также упрощает функцию просмотра для получения информации из базы данных. Структура наших данных определяется в моделях, которые являются классами Python, которые определяют поля, которые должны храниться в основной базе данных. Если у нас есть модель с именем Team с полем «team_type», мы можем использовать простой синтаксис запроса, чтобы получить все команды, имеющие определённый тип.
В приведённом ниже примере представлен список всех команд, у которых есть точный (с учётом регистра) team_type «junior» («младший») — обратите внимание на формат: имя поля ( team_type ), за которым следует двойной знак подчёркивания, а затем тип соответствия для использования (в этом случае exact («точное»)). Существует много других типов соответствия, и мы можем объединить их. Мы также можем контролировать порядок и количество возвращаемых результатов.
#best/views.py from django.shortcuts import render from .models import Team def junior(request): list_teams = Team.objects.filter(team_type__exact="junior") context = 'list': list_teams> return render(request, 'best/index.html', context)
После того, как функция junior() получает список младших команд, она вызывает функцию render() , передавая исходный HttpRequest , HTML-шаблон и объект «context», определяющий информацию, которая должна быть включена в шаблон. Функция render() — это функция удобства, которая генерирует HTML с использованием контекста и HTML-шаблона и возвращает его в объект HttpResponse .
Очевидно, что веб-фреймворки могут помочь вам в решении многих других задач. В следующей статье мы обсудим намного больше преимуществ и некоторые популярные варианты веб-фреймворков.
Резюме
На этом этапе вы должны хорошо ознакомиться с операциями, которые должен выполнять серверный код, и знать некоторые способы, с помощью которых веб-фреймворк на стороне сервера может сделать это проще.
В следующем модуле мы поможем вам выбрать лучший веб-фреймворк для вашего первого сайта.
Found a content problem with this page?
- Edit the page on GitHub.
- Report the content issue.
- View the source on GitHub.
This page was last modified on 3 авг. 2023 г. by MDN contributors.
Веб-клиент
Служба позволяет изменять или добавлять файлы, хранящиеся в Интернете. Если эта стандартная функция Windows вам не нужна, то службу лучше отключить.
Служба Веб-клиент занимает около 800 Кбайт оперативной памяти и запускается с правами локальной службы (NT AUTHORITYLocalService) автоматически при каждом входе пользователя в систему (при этом она запускается как часть процесса svchost.exe). Чтобы отключить эту службу, необходимо воспользоваться параметром Start из ветви реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesWebClient.
Для запуска службы Веб-клиент необходимо, чтобы была запущена служба Перенаправить клиентов WebDav. Она описывается в ветви реестра HKEY_LOCAL_MACHINE SYSTEMCurrentControlSetServicesMRxDAV.
Для работы службы Веб-клиент необходима библиотека webclnt.dll.
Читайте также
Клиент
Клиент Клиент, который желает послать запрос серверу, блокируется до тех пор, пока сервер не завершит обработку запроса. Затем, после завершения сервером обработки запроса, клиент разблокируется, чтобы принять «ответ».Это подразумевает обеспечение двух условий: клиент
30.3. Тестовый клиент TCP
30.3. Тестовый клиент TCP В листинге 30.1[1] показан клиент, который будет использоваться для тестирования всех вариаций нашего сервера.Листинг 30.1. Код клиента TCP для проверки различных версий сервера//server/client.с 1 #include «unp.h» 2 #define MAXN 16384 /* максимальное количество байтов, которые
10.1.2 TCP и модель клиент/сервер
10.1.2 TCP и модель клиент/сервер TCP естественным образом интегрируется в окружение клиент/сервер (см. рис. 10.1). Серверное приложение прослушивает (listen) поступающие запросы на соединение. Например, службы WWW, пересылки файлов или доступа с терминала прослушивают запросы,
Программа-клиент
Программа-клиент Программа-клиент бесплатной версии Roger Wilco отличается тем, что в ее окне отсутствует вкладка Host Base Station (Обосноваться на базовой станции). Это естественно, поскольку сервер запускается отдельно и настраивается в режиме командной строки. Тем не менее,
DHCP-клиент
DHCP-клиент Данная служба используется при существовании в сети DHCP-сервера. DHCP-сервер предназначен для выдачи всем компьютерам, не имеющим постоянного IP-адреса, временного IP-адреса, чтобы они могли работать в сети. Служба является отличным средством автоматизирования
Веб-клиент
Веб-клиент Служба позволяет изменять или добавлять файлы, хранящиеся в Интернете. Если эта стандартная функция Windows вам не нужна, то службу лучше отключить.Служба Веб-клиент занимает около 800 Кбайт оперативной памяти и запускается с правами локальной службы (NT
Почтовый клиент Evolution
Почтовый клиент Evolution Почтовым клиентом и по совместительству программой для управления контактами и временем для оконной среды GNOME является Evolution (http://www.gnome.org/projects/evolution/). Изначально он разработан и поддерживается фирмой Novell, с сентября 2004 года входит в состав GNOME.
Многопротокольный клиент SIM
Многопротокольный клиент SIM Simple Instant Messenger (SIM, http://sim-im.org/) – еще один многопротокольный клиент обмена сообщениями с открытыми исходными текстами, работающий, кроме Linux, на платформах, поддерживаемых используемой им библиотекой Qt: Microsoft Windows, FreeBSD и Mac OS X. Основатель проекта
Клиент Ekiga
Клиент Ekiga В дистрибутиве Ubuntu в качестве приложения для IP-телефонии и проведения видеоконференций используется Ekiga (http://www.ekiga.org/). Первая версия этой программы была написана Демиеном Сандрасом, который сегодня является одним из руководителей проекта, в качестве дипломной
Глава 18 FTP-клиент
Глава 18 FTP-клиент Постановка задачи Разработать FTP-клиент. Программа должна соединяться с FTP-cepвером, проходить аутентификацию и предоставлять пользователю возможность работать с файлами, которые находятся на сервере. У пользователя должна быть возможность передавать и
Почтовый клиент
Почтовый клиент В переводе с компьютерного жаргона это простая программа для приема и отправки электронной почты. Это нужная операция, поэтому программ такого рода множество. Однако Outlook – самая простая и удобная, что нетрудно доказать.Во-первых, Outlook универсален: он
Клиент-сервер
Клиент-сервер Средства локального доступа.* Локальная заглушка TCP/IP. Для многоуровневых серверных приложений и других клиентов доступ к локальному серверу на любой поддерживаемой платформе осуществляется через протокол TCP/IP: даже при отсутствии сетевой карты соединение
Что такое клиент Firebird?
Что такое клиент Firebird? Клиент Firebird — это приложение, обычно написанное на языке высокого уровня, которое предоставляет конечному пользователю доступ к средствам и инструментам системы управления базами данных Firebird и к данным, хранимым в базах данных. Интерактивная
21.5.1. Команда ftp — стандартный FTP-клиент
21.5.1. Команда ftp — стандартный FTP-клиент Для открытия соединения с любым FTP-сервером введите команду: ftp <имя или адрес FTP-сервера> Можно просто ввести команду ftp, а в ответ на приглашение ftp> ввести команду: open <имя или адрес FTP-сервера> Лично мне больше нравится первый
QIP — альтернативный ICQ-клиент
QIP — альтернативный ICQ-клиент Возможно, для общения в ICQ вам больше понравится альтернативный ICQ-клиент — программа QIP. Существуют две версии этой программы: QIP 2005 и OIP Infium. На нетбуке предпочтение стоит отдать более простой и компактной версии — QIP 2005.В программе QIP 2005 есть