Как устанавливается прокси-соединение с URLSession?

Я просматривал сеанс 711 конференции WWWDC 2015 Apple: "Сеть с НСУРЛСессия". Ближе к концу спикер упоминает URLSessionStreamTask, который можно использовать для прямого ввода-вывода через сокет. И он упоминает, как прокси-соединение (HTTP) может быть переведено в потоковую задачу.

Слайд содержит:

NSURLSessionStreamTask
DataTask conversion

NSURLSessionDataTask may be converted to a stream task
• Use NSURLSession to get through HTTP proxies
Conversion can occur when response is received

А на следующем слайде есть частичный пример кода:

func URLSession(session: NSURLSession, dataTask: NSURLSessionDataTask,
                    didReceiveResponse response: NSURLResponse,
                              completionHandler: (NSURLSessionResponseDisposition) -> Void) {
    completionHandler(.BecomeStream)
}

func URLSession(session: NSURLSession, dataTask: NSURLSessionDataTask,
                 didBecomeStreamTask streamTask: NSURLSessionStreamTask) {
}

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

И поскольку они обычно используют HTTP вместо HTTPS, активируют ли такие соединения ATS (безопасность транспорта приложений)?


person CTMacUser    schedule 28.08.2017    source источник


Ответы (1)


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

Я думаю, они пытались сказать, что если вы отправляете запросы HTTP (ick) через прокси-сервер, который на самом деле поддерживает связь WebSocket, iOS знает, как попросить прокси-серверы правильно обновить соединение. Этот же механизм обновления часто используется для выполнения HTTPS-запроса через HTTP-прокси, если он поддерживается, и если вы устанавливаете HTTPS-соединение, последующее обновление WebSockets должно работать, несмотря на прокси-сервер, несмотря ни на что, потому что прокси-сервер уже просто передает биты туда и обратно к этому моменту.

person dgatwood    schedule 03.09.2017
comment
Я спрашиваю о прокси-серверах старой школы 1990-х годов, которые, я думаю, использовали HTTP CONNECT. Я думаю, что они все еще используются сегодня. В ссылке, которую вы предоставили на WebSocket, также упоминается HTTP-CONNECT. - person CTMacUser; 04.09.2017
comment
Вы спрашиваете, как использовать это напрямую для связи с произвольным сервером, который не говорит по HTTP/HTTPS? Я не думаю, что вы можете сделать это без реализации собственной пользовательской библиотеки HTTP. Однако код NSURLSession/Connection автоматически использует эту команду, когда необходимо установить соединение HTTPS через прокси-сервер, настроенный пользователем для общесистемного использования. - person dgatwood; 04.09.2017
comment
Это не прокси-процесс: 1 — используйте HTTP-СОЕДИНЕНИЕ с прокси-сервером, указав имя хоста и порт целевого сервера вместе с любым именем пользователя/паролем, необходимым для прокси-сервера. 2 -- если прокси-сервер возвращает код OK, используйте соединение с нужным протоколом, верно? Я спрашиваю, как создать URLRequest, необходимый для (1). - person CTMacUser; 05.09.2017
comment
Насколько я понимаю, с точки зрения приложения процесс A. подключается к имени хоста целевого сервера. Механизм NSURL распознает, что он настроен на использование прокси-сервера, и подключается к прокси-серверу, отправляет соответствующий запрос для запроса туннеля на нужный сервер, а затем открывает HTTPS-соединение по этой ссылке. Если затем сервер запрашивает обновление с этого на поток, это происходит позже. Ваше приложение вообще не взаимодействует с прокси-сервером напрямую. - person dgatwood; 05.09.2017
comment
Если вам нужно настроить прокси-словарь, чтобы указать, какой сервер вы используете, см. эту ссылку: stackoverflow.com/questions/28101582/ - person dgatwood; 05.09.2017
comment
Да, если вы используете верхний уровень механизма NSURL, поддержка прокси осуществляется автоматически. Но я пишу код на более низком уровне; Я должен предоставить это автоматическое оборудование для всех остальных. Поэтому мне приходится делать прокси вручную. Я спрашиваю, как начать с этого. - person CTMacUser; 10.09.2017
comment
С механизмом NSURL на любом уровне поддержка прокси осуществляется автоматически (хотя вы можете изменить используемый прокси, как описано в приведенной выше ссылке). С API-интерфейсами NSURL* вы не можете установить соединение с прокси-сервером. Просто прокси так не работают. Вы подключаетесь к нужному серверу HTTP/HTTPS, и ОС прозрачно запрашивает прокси-сервер, если он настроен, для пересылки трафика. И так же работают не веб-прокси. - person dgatwood; 10.09.2017
comment
Если вы пытаетесь сделать что-то еще (например, использовать веб-прокси для не-веб-трафика), вам придется написать собственный код для взаимодействия с прокси-сервером с использованием голых сокетов TCP (например, getStreamsToHost:port:inputStream:outputStream). И это выходит за рамки вопроса SO. Лучшее, что я могу сделать, это указать вам на RFC 2817: ietf.org/rfc/rfc2817.txt - person dgatwood; 10.09.2017
comment
Вы уверены насчет любого уровня? Обратите внимание, что в моем OP я использую NSSessionStreamTask, который принимает имя хоста и порт вместо URL-адреса. Он не может автоматически использовать прокси, поскольку схема не указана, поэтому система не знает, на какие настройки прокси ссылаться. Сама суть этого запроса заключается в веб-прокси для невеб-трафика. Я не понимаю, почему это выходит за рамки SO. - person CTMacUser; 11.09.2017
comment
Да на любом уровне. Если то, что они сказали на выступлении на WWDC, верно, то описываемый вами API должен автоматически использовать любой прокси-сервер, настроенный для сеанса. Если этого не происходит, я бы назвал это ошибкой. Чтобы было ясно, то, что я говорил, выходит за рамки SO, это исходный код для полного клиента веб-прокси (вероятно, тысячи строк кода). :-) - person dgatwood; 11.09.2017