HttpClient 4.x (Tutorial) / HttpClient 4.x (Учебник): 2. Connection management (Диспетчер соединений)
| Английский оригинал | Перевод на русский | |
|---|---|---|
Сожалеем, но текст оригинала доступен только зарегистрированным пользователям. |
Глава 2. Управление соединениями gi1gi 25.11.10 в 17:53 |
|
|
HttpClient имеет полный контроль над процессами инициализации и прерывания соединения, а также над операциями ввода/вывода активных соединений. Однако различными аспектами соединений можно управлять с помощью ряда параметров. gi1gi 25.11.10 в 17:56 |
||
|
Ниже представлены параметры, влияющие на операции над соединения: gi1gi 25.11.10 в 17:57 |
||
|
'http.socket.timeout': определяет тайм-аут для сокета (SO_TIMEOUT), в миллисекундах (максимальный период между двумя последовательными пакетами данных, в течении которого сокет будет бездействовать). Значение 0 интерпретируется как бесконечное время ожидания. gi1gi 25.11.10 в 18:04 |
||
|
'http.tcp.nodelay': определяет, будет ли алгоритм Nagle будет использоваться. Алгоритм Nagle пытается сохранить пропускную способность путем сведения к минимуму числа отправляемых сегментов. Когда вашему приложению нужно минимизировать задержки сети и повысить производительность, вы можете отключить алгоритм Nagle (т.е. enable TCP_NODELAY). Данные будут отправляться быстрее за счет увеличения пропускной способности. gi1gi 25.11.10 в 18:05 |
||
|
'http.socket.buffer-size': определяет размер внутреннего буфера сокета, использующегося для буферизации данных во время приема/передачи HTTP сообщений. gi1gi 25.11.10 в 18:05 |
||
|
'http.socket.linger': определяет SO_LINGER с указанным временем задержки в секундах. Максимальное значение тайм-аута зависит от платформы. Значение 0 означает, что опция отключена. Значение -1 означает, что используется значение по умолчанию для JRE. Настройка влияет только на операции закрытия сокета. gi1gi 25.11.10 в 18:06 |
||
|
'http.connection.timeout': определяет тайм-аут для устанавливления соединения, в миллисекундах. Значение 0 интерпретируется как бесконечное. gi1gi 25.11.10 в 18:06 |
||
|
'http.connection.stalecheck': определяет, нужно ли использовать проверку старых подключений. Отключение проверки старых подключений может привести к заметному улучшению производительности (проверка может вызывать до 30 миллисекунд накладныех расходов для каждого запроса), однако при этом есть риск ошибки ввода-вывода при выполнении запроса на соединение, которое было закрыто на стороне сервера. Для выполнения критических операций проверки должны быть отключены. gi1gi 25.11.10 в 18:06 |
||
|
'http.connection.max-line-length': определяет максимальный предел длины линии. Если установлено в положительное значение, любая HTTP линия, превышающая этот предел, будет вызывать java.io.IOException. Отрицательное или нулевое значение будет одинаково отключить проверку. gi1gi 25.11.10 в 18:14 |
||
|
'http.connection.max-header-count': определяет максимально допустимое количество HTTP заголовков. Если установлено положительное значение, и число HTTP заголовков, полученных из потока данных, превышает этот предел будет выброшено java.io.IOException. Отрицательное или нулевое значение будут одинаково отключать проверку. gi1gi 25.11.10 в 18:15 |
||
|
ConnConnectionPNames.MAX_STATUS_LINE_GARBAGE='http.connection.max-status-line-garbage': определяет максимальное количество игнорируемых строк перед ожидаемой строкой статуса HTTP-ответа. С HTTP/1.1 постоянными соединениями возникает проблема, когда сломанный сценарий может вернуть неверный Content-Length (послать больше байт, чем указано). К сожалению, в некоторых случаях, это не может быть обнаружено сразу после плохого ответа, а лишь перед следующим ответом. Таким оборазом, HttpClient должны быть в состоянии пропустить эти лишнии строки. gi1gi 06.02.11 в 14:32 |
+1 | |
|
2.2. Постоянные соединения gi1gi 25.11.10 в 18:16 |
||
|
Процесс установления соединения одного хоста с другим является довольно сложным и включает в себя несколько обменов пакетов между двумя конечными точками, которые могут занимать довольно много времени. Накладные расходы на «рукопожатия» соединения могут быть значительными, особенно для небольших HTTP сообщений. Можно добиться гораздо более высокой пропускной способности, если открывать соединения, которые могут быть использованы повторно, выполняющие несколько запросов. gi1gi 25.11.10 в 18:31 |
||
|
HTTP/1.1 заявляет, что HTTP соединения могут быть использованы повторно для нескольких запросов по умолчанию. HTTP/1.0 совместимые хосты также могут использовать аналогичный механизм явно сообщить свои предпочтения поддерживать соединение и использовать его для нескольких запросов. HTTP агенты также могут удерживать простаивающие соединения действующими в течение определенного периода времени в случае если для последующих запросов понадобится соединение с тем же самым хостом. Способность сохранять соединения действующими, как правило, называют постоянство соединения. HttpClient полностью поддерживает постоянные соединения. gi1gi 25.11.10 в 18:31 |
||
|
2.3. Маршрутизация HTTP-соединений gi1gi 25.11.10 в 18:55 |
||
|
HttpClient в состоянии наладить связь с целевым хостом либо непосредственно, либо через маршрут, который может включать несколько промежуточных соединений также называемях хопами (hops). HttpClient различает соединения по обычному туннелированому и уровневому маршрутам. Использование нескольких промежуточных прокси-серверов для туннеллирования соединения к хост называется цепочкой прокси. gi1gi 25.11.10 в 19:01 |
||
|
Обычные маршруты устанавливаются путем непосредственного соединения с целевым хостом или через единственный прокси. Туннелированые маршруты устанавливаются путем подключения к первому прокси туннелирование через цепочку прокси-серверов до цели. Маршруты без прокси не могут быть туннелированными. Уровневые маршруты устанавливаются слоев протокол в существующее соединение. Протоколы могут быть только уровневыми по туннелю к цели, или через прямое соединение без прокси. gi1gi 25.11.10 в 19:02 |
||
|
Интерфейс RouteInfo представляет информацию о точном маршруте к целевому хосту, включая одно или несколько промежуточных шагов или хопов. HttpRoute является конкретной реализацией RouteInfo, которая не может быть изменена (неизменна). HttpTracker является изменяемой реализацией RouteInfo, исползуемой внутри HttpClient отслеживать остальные прыжки с конечной целью маршрута. HttpTracker может быть обновлен после успешного выполнения следующего шага в направлении маршрута цели. HttpRouteDirector является вспомогательным классом, который может быть использован для вычисления следующего шага маршрута. Этот класс предназначен для внутреннего использования HttpClient. gi1gi 25.11.10 в 19:10 |
||
|
Интерфейс HttpRoutePlanner представляет стратегию для вычисления полного пути к требуемой цели на основе контекста выполнения. HttpClient умолчанию поставляется с двумя реализациями HttpRoutePlanner. Реализация ProxySelectorRoutePlanner основана на java.net.ProxySelector. По умолчанию, он будет брать настройки прокси из JVM, либо из свойств системы или из браузера, запустившего приложение. Реализация DefaultHttpRoutePlanner не использует ни системные свойства Java, ни свойства самой системы или настройки прокси из браузера. Она вычисляет маршруты, основываясь исключительно на параметрах HTTP, описанных ниже. gi1gi 25.11.10 в 19:10 |
||
|
2.3.2. Защищенные HTTP-соединения gi1gi 01.12.10 в 13:52 |
||
|
HTTP-соединения можно считать безопасным, если информация, передаваемая между двумя конечными точками соединения не могут быть прочитаны или изменены неуполномоченным третьим лицом. SSL/TLS протокол является наиболее широко используемой техникой для обеспечения безопасности HTTP-транспортировки. Однако, могут быть использованы и другие методы шифрования. Обычно, над HTTP транспортировкой надстраивают уровень SSL/TLS для зашифрованных соединений. gi1gi 01.12.10 в 13:59 |
||
|
2.4. Параметры HTTP-маршрута gi1gi 01.12.10 в 09:17 |
||
|
На вычисление маршрута могут влиять следующие параметры: gi1gi 01.12.10 в 09:18 |
||
|
'http.route.default-proxy': определяет прокси-сервер, который будет использоваться планировщиками маршрутов по умолчанию, которые не используют настройки JRE. gi1gi 01.12.10 в 09:25 |
||
|
'http.route.local-address': определяет локальный адрес, которые будут использоваться всеми планировщиками маршрутов по умолчанию. На машинах с несколькими сетевыми интерфейсами, этот параметр может быть использован для выбора сетевого интерфейса, через который происходит соединение. gi1gi 01.12.10 в 09:29 |
||
|
'http.route.forced-route': определяет вынужденный маршрут, который будет использоваться всеми планировщиками маршрутов по умолчанию. Вместо вычисления маршрута будет возвращен данный вынужденный маршрут, даже если он указывает на совершенно другой целевой хост. gi1gi 01.12.10 в 09:33 |
||
|
2.5. Фабрики сокетов gi1gi 01.12.10 в 09:33 |
||
|
HTTP-соединения внутренне используют объекты java.net.Socket для управления передачей данных по сети. Они, однако, полагаться на интерфейс SocketFactory для создания, инициализации и подключения сокетов. Это позволяет пользователям HttpClient реализовавать специфичный для приложения код инициализации сокета во время выполнения. PlainSocketFactory является фабрикой по умолчанию для создания и инициализации простого(без шифрования) сокета. gi1gi 01.12.10 в 10:11 |
||
|
Процесс создания сокета и подключения его к хосту не связаны, так что сокет может быть закрыт в то же время заблокирован в операции подключения. gi1gi 01.12.10 в 10:54 |
+1 | |
|
PlainSocketFactory sf = PlainSocketFactory.getSocketFactory(); gi1gi 01.12.10 в 10:03 |
||
|
HttpParams params = new BasicHttpParams(); gi1gi 01.12.10 в 10:03 |
||
|
2.5.1. Уровневые защищенные сокеты gi1gi 01.12.10 в 16:08 |
||
|
LayeredSocketFactory расширяет интерфейс SocketFactory. Фабрики уровневых сокетов способны создавать сокеты, которые образуют дополнительный уровень над существующими простыми сокетами. Уровневые сокеты используются в основном для создания безопасных соединений через прокси. HttpClient содержит SSLSocketFactory, который реализует SSL/TLS уровни. Пожалуйста, обратите внимание, что HttpClient не использует какие-либо собственные функции шифрования. Он полностью зависит от стандартных Java Cryptography (JCE) и Secure Sockets (JSEE) расширений. gi1gi 01.12.10 в 13:32 |
||
|
2.5.2. SSL/TLS настройки gi1gi 01.12.10 в 13:43 |
||
|
HttpClient использует SSLSocketFactory для создания SSL-соединения. SSLSocketFactory позволяет выполнить настройку очень гибко. Она может принять экземпляр javax.net.ssl.SSLContext в качестве параметра и использовать его для создания соединений SSL с пользовательскими настройками. gi1gi 01.12.10 в 13:51 |
||
|
TrustManager easyTrustManager = new X509TrustManager() gi1gi 01.12.10 в 11:34 |
||
|
@Override gi1gi 01.12.10 в 11:34 |
||
|
@Override gi1gi 01.12.10 в 11:35 |
||
|
@Override gi1gi 01.12.10 в 11:35 |
||
|
}; gi1gi 01.12.10 в 11:36 |
||
|
SSLContext sslcontext = SSLContext.getInstance("TLS"); gi1gi 01.12.10 в 11:36 |
||
|
SSLSocketFactory sf = new SSLSocketFactory(sslcontext); gi1gi 01.12.10 в 11:37 |
||
|
HttpParams params = new BasicHttpParams(); gi1gi 01.12.10 в 11:37 |
||
|
Адаптация SSLSocketFactory подразумевает определенную степень знакомства с концепциями SSL/TLS протокола, подробное описание которого выходит за рамки этого документа. Пожалуйста, обратитесь к Java Secure Socket Extension за более подробным описанием javax.net.ssl.SSLContext и связанными с ними инструментами. gi1gi 01.12.10 в 11:45 |
||
|
2.5.3. Проверка имени хоста gi1gi 01.12.10 в 09:34 |
||
|
В дополнение к проверке доверия и аутентификации клиента осуществляется на SSL/TLS уровне протокола, HttpClient дополнительно можно проверить совпадения имен целевых хостов хранятся в сертификат X.509 сервера, когда соединение было установлено. Эта проверка может обеспечить дополнительные гарантии подлинности материала доверия сервера. X509HostnameVerifier интерфейс представляет стратегию для хоста проверки. HttpClient поставляется с тремя X509HostnameVerifier. Важно: имя хоста проверки не следует путать с проверкой доверия SSL. gi1gi 05.12.10 в 15:39 |
||
|
StrictHostnameVerifier: строгий верификатор имени хоста работает так же, как Sun Java 1.4, Sun Java 5, Sun Java 6. Это также довольно близко к IE6. Эта реализация, как представляется, совместимый с RFC 2818 для работы с маски. Имя должно совпадать с первым CN, или любой из предмета альтов. Шаблон может произойти в CN, и в любом из предмета альтов. gi1gi 05.12.10 в 15:40 |
||
|
BrowserCompatHostnameVerifier: имя верификатор, который работает так же, как Керл и Firefox. Имя должно совпадать с первым CN, или любой из предмета альтов. Шаблон может произойти в CN, и в любом из предмета альтов. Единственное различие между BrowserCompatHostnameVerifier и StrictHostnameVerifier в том, что шаблон (например, "*. foo.com") с BrowserCompatHostnameVerifier матчи все поддомены, в том числе "abfoo.com". gi1gi 05.12.10 в 16:02 |
||
|
AllowAllHostnameVerifier: Это имя верификатор существу превращается хоста проверки с. Эта реализация не-оп, и никогда не бросает javax.net.ssl.SSLException. gi1gi 05.12.10 в 16:02 |
