Эндрю Уэзеролл - Компьютерные сети. 5-е издание

Соединения

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

Ранее, в HTTP 1.0 после установки соединения посылался один запрос, на который приходил один ответ. После этого TCP-соединение разрывалось. В то время типичная веб-страница целиком состояла из HTML-текста, и такой способ взаимодействия был адекватным. Однако вскоре средняя веб-страница стала изобиловать большим количеством ссылок на различные значки и другие украшения. Очевидно, что установка TCP-соединения для передачи одного значка оказалась нерациональной и слишком дорогой.

Это соображение привело к созданию протокола HTTP 1.1, который поддерживал постоянные соединения( persistent connection). Это означало, что появилась возможность установки TCP-соединения, отправки запроса, получения ответа, а затем передачи и приема дополнительных запросов и ответов. Эта стратегия называется повторным использованием соединения( connection reuse). Таким образом, снизились накладные расходы, возникавшие при постоянных установках и разрывах соединения. Стало возможным также конвейеризировать запросы, то есть отправлять запрос 2 еще до прибытия ответа на запрос 1.

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

Рис. 7.16. HTTP: а — множественные соединения и последовательные запросы; б — постоянное соединение и последовательные запросы; в — постоянное соединение и конвейеризованные запросы

На рис. 7.16, б страница получена при помощи постоянного соединения. То есть TCP-соединение открывается с самого начала, затем посылаются те же самые 3 запроса, как и раньше один за другим, и только после этого соединение закрывается. Заметьте, что загрузка завершается быстрее. Это происходит по двум причинам: во-первых, не тратится время на установку дополнительных соединений. Для каждого TCP-соединения требуется дополнительное время, как минимум, для его подтверждения. Во-вторых, передача тех же картинок проходит быстрее. Спросите, почему? Все это из-за контроля перегрузок сети в TCP. Сразу после установки соединения TCP использует процедуру медленного старта, чтобы увеличить пропускную способность, пока он не изучит поведение сетевого пути. Вследствие этого периода «разогрева» на передачу информации посредством множественных коротких TCP-соединений уходит гораздо больше времени, чем в случае с использованием одного длительного TCP-соединения. Наконец, на рис. 7.16, в установлено одно постоянное соединение, а запросы передаются конвейеризовано. Второй и третий запросы отсылаются за особенно короткий промежуток времени, так как была получена достаточно большая часть главной страницы, чтобы можно было сделать вывод о том, что изображения должны быть загружены и отображены. В итоге приходят ответы на эти запросы. Этот метод сокращает время, в течение которого сервер не занят делом, так что он и дальше повышает производительность. Однако за постоянные соединения приходится платить. Новый вопрос, который возникает вокруг них, — это «когда закрывать соединение?» Соединение с сервером не должно разрываться, пока загружается страница. А что потом? Высок шанс того, что пользователь нажмет на ссылку, которая запросит еще одну страницу с сервера. Если соединение остается открытым, следующий запрос может быть отослан немедленно. Однако нет гарантии того, что клиент создаст запрос к серверу в ближайшее время. На практике клиенты и серверы обычно сохраняют постоянное соединение, пока не пройдет какого-то небольшого промежутка времени (например, 60 с), в течение которого не будет отослано ни одного запроса и не будет принято ни одного ответа, или же в том случае, если открыто слишком много соединений и некоторые следует закрыть.