46. Транспортные протоколы Интернета: tcp. Основы tcp

Протокол TCP (Transmission Control Protocol — протокол управления передачей) был специально разработан для обеспечения надежного сквозного байтового потока по ненадежной интерсети. Объединенная сеть отличается от отдельной сети тем, что ее различные участки могут обладать сильно различающейся топологией, пропускной способностью, значениями времени задержки, размерами пакетов и другими параметрами. При разработке TCP основное внимание уделялось способности протокола адаптироваться к свойствам объединенной сети и отказоустойчивости при возникновении различных проблем.

Протокол TCP описан в RFC 793.

Каждая машина, поддерживающая протокол TCP, обладает транспортной сущностью TCP, являющейся либо библиотечной процедурой, либо пользовательским процессом, либо частью ядра системы. В любом случае, транспортная сущность управляет TCP-потоками и интерфейсом с IP-уровнем. ТСР-сущность принимает от локальных процессов пользовательские потоки данных, разбивает их на куски, не превосходящие 64 Кбайт (на практике это число обычно равно1460 байтам данных, что позволяет поместить их в один кадр Ethernet с заголовками IP и TCP), и посылает их в виде отдельных IP-дейтаграмм. Когда IP-дейтаграммы с TCP-данными прибывают на машину, они передаются ТСР-сущности, которая восстанавливает исходный байтовый поток.

Транспортная сущность TCP - часть программного обеспечения.

Протокол TCP - набор правил.

Уровень IP не гарантирует правильной доставки дейтаграмм, поэтому именно TCP приходится следить за истекшими интервалами ожидания и в случае необходимости заниматься повторной передачей пакетов. Бывает, что дейтаграммы прибывают в неправильном порядке. Восстанавливать сообщения из такихдейтаграмм обязан также TCP. Таким образом, протокол TCP призван обеспечить надежность, о которой мечтают многие пользователи и которая не предоставляется протоколом IP.

47. ТпИ: udp Вызов удаленной процедуры

RPC. Идея: как вызов ф-ии на языке программирования. Разрешено программам вывзвать процедуры на сервере. Процесс1 вызывающий пр2 блокируется пока выполняется пр2. Передаётся например в виде параметров, а ответ – результат процедуры. Клиентская программа д.б связана с маленькой библиотечной процедурой - клиентская заглушка, (отображает серверную процедуру в пространство адресов клиента.). У сервера – серверная заглушка. Они скрывают то, что вызов серверной процедуры осуществляется удаленно. шаг1 – вызов клиентом клиентской заглушки, параметры помещаются в стек. шаг2 – упаковка параметров (маршалинг) кл.заглушки в стек, системный вызов на отправку сообщения шаг3 – ядро системы передаёт сбщ с клиентской машины на сервер шаг4 – Ядро передаёт входящий пакет серв.заглушке шаг5 – она вызывает серверную процедуру с дермаршилизованными ппараметрами. При ответе тоже самое только наоборот. !Кл.процедура выполянет локальный вызов кл.заглушки с именем серверной процедуры, параметры передаются обычным образом т.к кл.загл и кл.процедура в 1м адр пространстве. проблемы: 1) работа с указателями невозможна. Только с уловками - простейшие копирование и восстановление (возвращение измененного переданного указателья от сервера если он изменился) 2) нет возможности определения размеров параметров, которые ограниченны процедурами. 3) не всегда можно распознать типы параметров. При вызове принт f моежт быть смесь целочисленных и вещественных параметров. 4) применение глобальных переменных 1234 – поэтому нужны ограничения для нормального RPC. Когда для RPC не хватает UDP используется TCP-соединение.