Протокол управления передачей (протокол TCP) может выполнять базовую пересылку данных, используя непрерывный поток данных размером в байт. Данные упаковываются в сегменты для передачи протоколом Интернета. В общем TCP сам выполняет управление потоком и сам решает, когда передавать и когда задержать данные, если потребуется. Определена функция push, которая позволяет пользователю узнать, когда TCP успешно передал все данные, предоставленные ему приложением. Посылающий TCP может собирать данные от посылающих пользователей и посылать эти данные в сегментах по своему собственному усмотрению, пока не будет вызвана функция push, после чего он должен послать все не отосланные данные. Когда принимающий TCP видит флаг PUSH, он не должен ждать дополнительные данные от посылающего TCP, прежде чем передать данные в получающий процесс. Push заставляет TCP переслать и доставить полученные до этого момента данные прямо получателю. Мы увидим флаг push в некоторых примерах.
Чтобы восстановить поврежденные, потерянные, пришедшие в неправильном порядке или как-нибудь иначе поврежденные данные, TCP присваивает порядковый номер каждому передаваемому октету. Это позволяет уровню TCP на получающей машине знать, в каком порядке должны прийти пакеты, чтобы правильно их собрать. В дополнение к порядковым номерам, каждый правильно полученный пакет должен также подтверждаться (путем передачи служебного сообщения АСК) получающим TCP. Если АСК не получен в течение периода ожидания, данные будут посланы повторно. Для определения, что пакет был поврежден, используется контрольная сумма. Она добавляется к каждому сегменту, передаваемому посылающей машиной, и проверяется получателем.
Управление потоком обеспечивается с помощью "окна", которое посылается назад с каждым АСК. Это окно является диапазоном порядковых номеров, которые могут быть переданы в следующем раунде коммуникации. Они находятся за последним успешно полученным сегментом. Окно указывает число октетов, которое может послать отправитель, прежде чем получить следующее разрешение. Чтобы хост разрешал общаться через TCP в одно время нескольким процессам, используются порты. Добавление номера порта в конце адреса IP (например: 123.123.123.123:29) формирует со-кет. Пара сокетов используется для идентификации соединения, поэтому сокет можно использовать для переноса данных в обоих направлениях в одно время, т.е. это "дуплексная передача".
Хотя каждый хост отвечает за номера портов, которые он использует для этих соединений, некоторые функции были присвоены "хорошо известным портам". Эти службы доступны по известным адресам. Список этих хорошо известных портов находится в Приложении А. Комбинация сокетов, номеров последовательности и размеров окон называется соединением. Два процесса общаются, устанавливая сначала соединение. Когда коммуникация заканчивается, соединение закрывается, чтобы освободить ресурсы.
Есть два интерфейса, поддерживаемые протоколом управления передачей. Это интерфейс пользователя и интерфейс Интернета. Интерфейс пользователя позволяет вызвать пять основных функций протокола. Этими функциями являются: Открыть соединение, Закрыть соединение, Передать данные, Получить данные и Статус. Функция "Статус" выдает информацию о соединении. Эти пять вызовов действуют так же, как их аналоги в любой другой программе. Например, можно открыть или закрыть файл таким же образом, как TCP выполняет функции аналогичного типа. Пассивный запрос OPEN (открыть) означает, что процесс хочет принять входящие запросы соединения, а не пытается инициировать соединение.
Часто процесс, запрашивающий пассивный OPEN, будет принимать запрос соединения от любого вызывающего абонента. В этом случае для обозначения неуказанного сокета будет использоваться внешний сокет только из нулей. Неопределенные внешние сокеты допускаются только на пассивных OPEN. Процесс службы, которая желает предоставлять услуги для других неизвестных процессов, будет создавать пассивный запрос OPEN с неопределенным внешним сокетом. Затем можно будет создать соединение с любым процессом, который запрашивает соединение с этим локальным сокетом. Это полезно, если известно, что этот локальный сокет связан с данной службой.
Хорошо известные сокеты являются удобным механизмом связывания адреса сокета со стандартной службой. Например, процесс "TelnetServer" постоянно присвоен определенному сокету, а другие сокеты зарезервированы для передачи файлов. Интерфейс Интернета, поддерживаемый TCP, предоставляет только два вызова. Он может посылать или получать дейтаграммы, адресованные модулям TCP на других хостах. Эти вызовы имеют ряд параметров, которые можно задавать. Они задаются как флаги в кадре, как мы увидим в примерах трассировок. Эти параметры включают тип службы, приоритеты, безопасность и другую управляющую информацию.
Модель TCP/интерфейс пользователя является моделью, где команды пользователя получают немедленный ответ и, возможно, ответ с задержкой с помощью события или псевдопрерывания. В следующих описаниях термин "сигнал" означает "причина задержанного ответа". Ответы об ошибках предоставляются как строки символов. Например, пользовательские команды, обращающиеся к соединениям, которые не существуют, получают в ответ сообщение "Ошибка: соединение не открыто" ("error: connection not open").
Отметим, что в последующем все арифметические операции с номерами последовательности, номерами подтверждений, окнами и т.д. выполняются по модулю 2 ', так как это размер пространства номеров последовательности. Отметим также, что "=<" означает "меньше или равно (по модулю 232)". Обработка входящих сегментов состоит в том, что они сначала проверяются на правильный номер последовательности (т.е. содержатся в диапазоне ожидаемого "окна получения" в пространстве номеров последовательности), а затем обычно выстраиваются в очередь и обрабатываются в порядке номеров последовательности. Когда сегмент перекрывает другие уже полученные сегменты, он реконструируется, чтобы содержать только новые данные, и соответствующим образом изменяются поля заголовка. Обратите внимание, что если не упомянуто никакое изменение, TCP остается в том же состоянии (т.е. ТСВ не существует). Создайте новый блок управления передачей (ТСВ) для хранения информации о состоянии соединения. Запишите информацию об идентификаторе локального сокета, внешнем сокете, приоритете, безопасности/ячейке и времени ожидания пользователя. Некоторые части внешнего сокета могут быть не определены при пассивном OPEN и должны заполняться параметрами входящего сегмента SYN. Проверьте, что апрошенные безопасность и приоритет допустимы для этого пользователя; если нет, верните "ошибка: приоритет недопустим" или "ошибка: защита/ячейка недопустимы". Если соединение активно, введите состояние LISTEN и вернитесь. Если в активном состоянии и определен внешний сокет, пошлите сегмент SYN. Выбирается начальный номер посылаемой последовательности (ISS). Сегмент SYN посылается в форме <SEQ=ISS><CTL=SYN>. Задайте SND.UNA как ISS, SND.NXT как ISS+1, введите состояние SYN-SENT и вернитесь. Если вызывающая сторона не имеет доступа к указанному локальному сокету, возвращается "ошибка: соединение недопустимо для этого процесса". Если нет места для создания нового соединения, возвращается "ошибка: недостаточно ресурсов".
Состояние прослушивания
Если текущее состояние соединения ACTTV и определен внешний сокет, то измените состояние на активное и выберите ISS. Пошлите сегмент SYN, задайте SND.UNA как ISS, SND.NXT как ISS+1.Введите состояние SYN-SENT. Данные, связанные с SEND, могут быть посланы с сегментом SYN или выстроены в очередь для передачи после ввода состояния ESTABLISHED. Бит срочности (если запрошен в команде) должен посылаться с сегментами данных, посланными в результате этой команды. Если для занесения запроса в очередь нет места, возвращается сообщение "ошибка: недостаточно ресурсов". Если внешний сокет не определен, возвращается сообщение "ошибка: внешний сокет не определен".
Каждый сервер делает доступными для клиентов в сети множество ресурсов. Ресурсом может быть дерево каталогов, именованный канал, принтер и т.д. Клиентская машина видит сервер как единственного поставщика файла или другого доступного ресурса, поэтому она не знает о каких-либо зависимостях от хранения или службы.
Протокол CIFS требует аутентификации сервера пользователей, прежде чем будет разрешен доступ к файлу, и каждый сервер аутентифицирует своих собственных пользователей. Клиентская система должна посылать информацию аутентификации на сервер, прежде чем сервер разрешит доступ к своим ресурсам.
Протокол CIFS определяет два метода, которые могут быть выбраны сервером для безопасности: общий уровень и уровень пользователя.
Сервер общего уровня делает доступным некоторый каталог на дисковом устройстве (или другой ресурс). Для доступа может потребоваться дополнительный пароль. Таким образом, любой пользователь в сети, знающий имя сервера, имя ресурса и пароль, получает доступ к ресурсу. Серверы с безопасностью общего уровня могут использовать различные пароли для одного и того же общего ресурса, где различные пароли предоставляют различный уровень доступа.
Сервер уровня пользователя делает некоторый каталог на дисковом устройстве (или другой ресурс) доступным, но требует дополнительно, чтобы клиент предоставил имя и соответствующий пароль пользователя для получения доступа. Серверы уровня пользователя могут применить имя учетной записи и пароль, предоставленные клиентом. Серверы уровня пользователя предпочтительнее серверов общего уровня для любой новой серверной реализации, так как организации обычно считают, что сервер уровня пользователя легче администрировать. Серверы уровня пользователя могут применять имя учетной записи для проверки списков контроля доступа на отдельных файлах или иметь один список контроля доступа, который применяется ко всем файлам в каталоге.
Когда сервер уровня пользователя проверяет имя учетной записи и пароль, предоставленные клиентом, идентификатор, представляющий этот аутентифицированный экземпляр пользователя, возвращается клиенту в поле Идентификатор пользователя (UID) ответного SMB. Этот UID должен включаться во все последующие запросы, сделанные от имени пользователя с этого клиента. Сервер общего уровня не возвращает в поле UID никакой полезной информации.
Модель безопасности на уровне пользователя была добавлена после выпуска первоначального диалекта протокола CIFS, и, следовательно, некоторые клиенты могут оказаться неспособными послать имена учетных записей и пароли на сервер. Сервер в режиме безопасности на уровне пользователя, общающийся с одним из таких клиентов, будет позволять клиенту соединяться с ресурсами, даже если клиент не прислал информацию об имени учетной записи и пароле:
1. Если имя компьютера клиента идентично имени учетной записи, известной на сервере, и если предоставленный пароль для соединения с общим ресурсом совпадает с паролем этой учетной записи, неявно будет выполнен "вход пользователя в систему" с помощью этих значений. Если это не сработает, то сервер может отказать в запросе или присвоить используемое по умолчанию имя учетной записи по своему выбору.
2. Значение UID в последующих запросах клиента будет игнорироваться, и весь доступ будет проверяться в предположении имени учетной записи, выбранной выше.
