Помните, что TCP не выполняет опрос соединения
| | |
Программисты, приступающие к изучению семейства протоколов TCP/IP, но имеющие опыт работы с другими сетевыми технологиями, часто удивляются, что TCP не посылает приложению немедленного уведомления о потере связи. Поэтому некоторые даже считают, что TCP не пригоден в качестве универсальной технологии обмена данными между приложениями. В этом разделе разъясняются причины отсутствия у TCP средств для уведомления, достоинства и недостатки такого подхода и способы обнаружения потери связи прикладным программистом.
Как вы узнали в совете 9, сетевой сбой или крах системы могут прервать сообщение между хостами, но приложения на обоих концах соединения «узнают» б этом не сразу. Приложение-отправитель остается в неведении до тех пор пока TCP не исчерпает все попытки. Это продолжается довольно долго, в системах на базе BSD- примерно 9 мин. Если приложение не посылает данные, то оно может вообще не получить информации о потере связи. Например, приложение-сервер ожидает, пока клиент не обратится со следующим запросом. Но, поскольку у клиента нет связи с сервером, следующий запрос не придет. Даже когда TCP на стороне клиента прекратит свои попытки и оборвет соединение, серверу об этом будет ничего не известно.
Другие коммуникационные протоколы, например SNA или Х.25, извещают приложение о потере связи. Если имеется нечто более сложное, чем простая двухточечная выделенная линия, то необходим протокол опроса, который постой проверяет наличие абонента на другом конце соединения. Это может быть сообщение типа «есть что-нибудь для отправки?» или скрытые фреймы, посылаемые в фоновом режиме для непрерывного наблюдения за состоянием виртуального канала. В любом случае, за эту возможность приходится расплачиваться пропускной способностью сети. Каждое такое опрашивающее сообщение потребляет сетевые ресурсы, которые могли бы использоваться для увеличения полезной нагрузки.
Очевидно, одна из причин, по которым TCP не уведомляет о потере связи немедленно, - это нежелание жертвовать полосой пропускания. Большинству приложений немедленное уведомление и не нужно. Приложение, которому действительно необходимо срочно узнавать о недоступности другого конца, может реализовать этой цели собственный механизм. Далее будет показано, как это сделать.
Есть и философское возражение против встраивания в TCP/IP механизма немедленного уведомления. Один из фундаментальных принципов, заложенных при проектировании TCP/IP, - это принцип «оконечного разума» [Saltzer et al. 1984]. В применении к сетям упрощенно подразумевается следующее. «Интеллекту» нужно находиться как можно ближе к оконечным точкам соединения, а сама сеть должна быть относительно «неинтеллектуальной». Именно поэтому TCP обрабатывает ошибки самостоятельно, не полагаясь на сеть. Как сказано в совете 1, протокол IP (значит, и построенный на его основе TCP) делает очень мало предположений о свойствах физической сети. Относительно мониторинга наличия связи между приложениями этот принцип означает, что такой механизм должен реализовываться теми приложениями, которым это необходимо, а не предоставляться всем приложениям без разбора. В работе [Huitema 1995] принцип «оконечного разума» интересно обсуждается в применении к Internet.
Однако веская причина отсутствия у TCP средств для немедленного уведомления о потере соединения связана с одной из главных целей его проектирования: способностью поддерживать связь при наличии сбоев в сети. Протокол TCP - это результат исследований, проведенных при финансовой поддержке Министерства обороны США, с целью создания надежной технологии связи между компьютерами. Такая технология могла бы функционировать даже в условиях обрывов сетей из-за военных действий или природных катастроф. Часто сетевые сбои быстро устраняются или маршрутизаторы находят другой маршрут для соединения. Допуская временную потерю связи, TCP часто может справиться со сбоями, не ставя об этом в известность приложения.
Недостаток такого подхода в том, что код, отслеживающий наличие связи, необходимо встраивать в каждое приложение (которому это нужно), а непродуманная реализация может привести к ненужному расходу ресурсов или как-то иначе повредить пользователям. Но и в этом случае при встраивании мониторинга в приложение можно осуществить тонкую настройку алгоритма, чтобы он удовлетворял нуждам приложения и по возможности естественно интегрировался с прикладным протоколом.
