В чем различие между протоколом ftp и http с точки зрения межсетевого экрана

Обновлено: 05.07.2024

Как видно из таблицы 10.2, правила практически аналогичны правилам архитектуры 1. Межсетевой экран дополняет правила, которые использовались в маршрутизаторе в предыдущей архитектуре. Также мы видим, что не существует явного правила, позволяющего внутреннему почтовому серверу подключаться к почтовому серверу в отдельной сети. Причиной этому является правило 2, позволяющее любой системе (внутренней или внешней) подключаться к упомянутой системе.

Архитектура 3: двойные межсетевые экраны

Третья архитектура , о которой пойдет речь, использует двойные межсетевые экраны (см. рис. 10.5). Доступные из интернета системы располагаются между межсетевыми экранами, а внутренняя сеть расположена за вторым межсетевым экраном. В таблице 10.3 приведены правила для межсетевого экрана 1.

Вопрос к эксперту

Вопрос. Используются ли межсетевые экраны только на соединениях с интернетом?

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

Хорошим примером секретных сетей являются банковские сети. Каждый вечер банки связываются с системой федерального резерва для передачи денежных средств. Ошибки в этих сетях могут стоить банкам больших денег. Системы, управляющие такими соединениями, являются крайне секретными и жизненно важными для банковских структур. Для ограничения доступа к этим системам из других подразделений банка можно установить межсетевой экран .

Рис. 10.5. Архитектура 3: двойные межсетевые экраны

Как видно из таблицы 10-3, правила в данном случае аналогичны правилам межсетевого экрана в архитектуре 2. Но еще имеется и второй межсетевой экран . Правила для межсетевого экрана 2 приведены в табл. 10-4.

Эти примеры очень просты, однако они отражают функционирование межсетевых экранов, при котором разрешается только строго определенный доступ .

Мы активно используем оба протокола в нашем основном продукте — корпоративном мессенджере MyChat уже много лет, и за это время столкнулись со многими заблуждениями и непониманием работы этих двух фундаментальных протоколов обмена файлами в Интернете.

Если вы увидите какие-то ошибки или неточности, напишите об этом на форуме.

Дисклэймер: в английском языке есть два термина: “upload” и “download”. В русском нет хороших аналогов, поэтому для файлов, которые мы отдаём с клиента на сервер, применяем слово “заливать” (upload), а для файлов, которые забираем на клиент с сервера — используем слово “скачивать” (“download”).

Оба протокола используются для скачивания и заливки файлов в Интернете и локальных сетях. Для текста и бинарных данных. Оба протокола работают поверх TCP/IP. Но между ними есть несколько серьёзных различий.

Скорость передачи

Что делает FTP быстрым?

в передаваемом потоке нет мета описаний, только чистые бинарные данные. Справочные данные идут в отдельном соединении;
нет накладных расходов по перекодировке передаваемых данных.

повторное использование существующих постоянных соединений повышает производительность TCP, не тратится время на создание новых соединений;
конвейерная обработка позволяет быстрее запрашивать несколько файлов с одного и того же сервера;
(автоматическое) сжатие трафика уменьшает объём передаваемых данных, это может увеличить скорость передачи при условии быстрых клиента и сервера и медленного канала связи;
нет управляющих команд в потоке передачи данных, это экономит время обработки.

В конечном итоге чистый результат, конечно, зависит от конкретных деталей, но я бы сказал, что для одиночных статических файлов вы не сможете увидеть ощутимую разницу.

Возраст

Заливка

Оба протокола умеют это делать. У FTP есть команда "append", HTTP исповедует подход "вот вам данные, а вы сами разбирайтесь, что с ними делать", то есть, никаких команд по управлению заливаемыми файлами нет.

Форматы ASCII, EBCDIC или бинарный

FTP имеет представление о формате файла, поэтому может передавать данные как в ASCII, так и в двоичном виде (raw bytes). HTTP же всегда отправляет файлы в двоичном виде. Таким образом, FTP умеет преобразовывать данные "на лету", если они передаются между системами с разными архитектурами (Windows/Linux/мэйнфрэймы).

Например, если отправитель использует одну схему для кодирования конца строки ("EOL" — End-Of-Line), а получатель — другую, то FTP сделает так, что они друг друга поймут. Unix использует только символ NL (newLine x0A), а MS Windows два символа подряд, CR и LF (CarriageReturn и LineFeed — x0D0A). EBCDIC перекодировки используются на старых мэйнфреймах.

HTTP, в противовес FTP, предоставляет метаданные для файлов, "Content-Type". Таким образом, метаданные могут использоваться клиентами для интерпретации содержимого.

Заголовки

Пайплайны или конвейеры

Что-то подобное, хотя и не совсем похожее, есть и в FTP. Это поддержка множественных запросов для параллельного получения файлов в одном управляющем соединении. Конечно, для этого нужно использовать новые TCP соединения для передачи бинарных данных, по одному для каждого файла, однако, далеко не все FTP серверы поддерживают такие возможности.

FTP команды/ответы

Два соединения

Одна из самых больших проблем для FTP в реальной работе — это использование двух соединений. Первое — для отправки управляющих команд, а второе — для передачи содержимого файла. Для этой цели он каждый раз открывает отдельный поток TCP. Если вы передаёте 100 файлов, по очереди будут открыты и закрыты 100 TCP соединений.

Файрволы и NAT

FTP использует два соединения: управляющее и для передачи данных. Соединение для данных может идти в двух направлениях, и использовать динамические номера портов. Это добавляет головной боли администраторам и зачастую требует от файрволов понимания специфики функционирования FTP на уровне сетевого протокола, чтобы обеспечить нормальную работу.

Это также означает, что если обе стороны соединения находятся за NAT, вы, скорее всего, не сможете пользоваться FTP.

Кроме того, NAT убивает незанятые соединения, через которые длительное время не было передачи данных. Поэтому, во время долгих передач по FTP на медленных каналах связи мы оказываемся в ситуации, когда соединение оказывается разорванным, потому что NAT решил, что оно уже неактивно.

Чтобы такого не происходило, приходится время от времени отправлять фиктивные пустые команды, чтобы соединение поддерживалось в "живом" состоянии. Результат — небольшой, но лишний трафик.

Активный и пассивный режимы

FTP открывает второе соединение в активном или пассивном режиме. Если работает активный режим (соединение инициирует сервер) — будут проблемы с соединением в сложных сетях, потому что такое соединение невозможно через NAT. Поэтому, в большинстве случаев используется пассивный режим (passive mode), когда соединение происходит только со стороны клиента.

Зашифрованные управляющие соединения

Поскольку брандмауэры должны уметь "разбирать по косточкам" управляющее соединение FTP, чтобы дать возможность корректно открывать второе соединение для передачи бинарных данных, существует огромная проблема с зашифрованными соединениями (FTP-SSL или FTPS). Как только управляющее соединение становится зашифрованным, файрвол уже не в состоянии интерпретировать его команды, чтобы понимать, когда и как следует разрешить второе соединение между клиентом и сервером для передачи бинарных данных.

К тому же, разработка самого стандарта FTPS заняла слишком много времени, что привело к одновременному существованию нескольких гибридных версий, плохо совместимых между собой.

Схемы авторизации

Скачивание

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

Диапазоны/возобновление скачивания

Также у FTP есть проблемы при возобновлении соединений при заливке или скачивании файлов, начиная с сегмента, большего, чем 2 GB.

Постоянные соединения

FTP должен создавать новое соединение для каждой новой передачи. Многократные выполнения новых подключений плохо сказываются на производительности из-за необходимости "рукопожатий" (handshakes) для TCP соединений.

Во время передачи отправляющая сторона отдаёт поток данных блоками (размер блока + сами данные) до тех пор, пока они не закончатся, а потом передаёт блок с нулевой длиной, чтобы просигнализировать о конце файла.

Помимо того, что соединение не нужно закрывать и открывать заново для новых файлов, ещё одним очевидным плюсом такой схемы есть возможность обнаружения преждевременных аварийных отключений в процессе передачи.

Сжатие

FTP предоставляет официальное встроенное RLE сжатие, однако оно обычно неэффективно для большинства бинарных и текстовых данных. Есть много дополнительных "хакерских" реализаций для сжатия FTP трафика, но ни одна из них не стала официальной и широко используемой.

FTP поддерживает технологию для передачи данных с одного сервера на другой, как будто бы передачу ведет непосредственно сам клиент. Однако на большинстве серверов эта возможность закрыта из-за проблем с безопасностью, так как протокол FXP был недостаточно хорошо спроектирован.

Виртуальный хостинг на основе имени

В FTP вы вообще не можете использовать виртуальный хостинг на основе имён, пока команда HOST не будет реализована на сервере, с которым вы соединены. Это свежая спецификация, и она ещё мало распространена.

Просмотр каталогов

Однако, в силу того, что авторы спецификации FTP жили в разное время, команды для получения списка файлов в каталоге (LIST и NLST) не имеют чётко описанного формата вывода. Поэтому авторам FTP клиентов приходится заниматься написание синтаксических анализаторов текста, чтобы попытаться правильно угадать, что за данные им передаёт сервер. Более поздние спецификации (RFC3659) предусматривают новые команды типа MLSD, но они ещё не получили широкого распространения и плохо поддерживаются разными серверами и клиентами.

Поддержка прокси

Одно из серьёзных преимуществ HTTP перед FTP — это поддержка прокси, встроенная в него с самого начала. Технология отлажена и очень хорошо работает. Многие протоколы могут быть инкапсулированы внутрь HTTP, как в своеобразный "конверт" для прохождения прокси-серверов.

FTP всегда использовался с прокси серверами, но это никогда не было стандартизировано, и всегда требовало специальных подходов в каждом конкретном случае.

Перед нами не стоит цель с головой окунуться в дебри и по косточкам разобрать абсолютно все разделы этой темы, но вот знание основ работы ФТП и его безопасных вариантов SFTP, FTPS, а также туннелирования посредством SSH-соединения может оказать вам практическую пользу в дальнейшем. В процессе повествования я постараюсь избежать ненужных заумных выражений и объяснить все простыми и понятными словами.

Если HTTP, который также является протоколом, был изначально предусмотрен создателями для осуществления передачи гипертекста (что это такое?) и небольших текстовых файликов, то ФТП служит для "транспортировки" практически любых файлов.

ФТП-соединение по умолчанию происходит через port 21, если не установлен другой порт. Важно также отметить, что этот протокол снабжен двоичным (бинарным) режимом передачи, что экономит трафик и сокращает время обмена данными при передачи больших файлов.

Взаимодействие между Клиентом и Сервером по ФТП

Перед тем, как продолжить, необходимо определиться с еще некоторыми терминами, которые будут совсем не лишними для восприятия картины в целом.

необходима аутентификация пользователей (ввод логина и пароля);
все операции производятся в рамках текущей сессии;
возможность осуществления различных действий: загрузка и выгрузка файлов, их переименование и удаление, создание и удаление каталогов и т.д.;
применяется отдельный канал для каждого соединения;
поддерживается два варианта передачи: текстовый и двоичный (бинарный), что позволяет передавать файлы различного размера;

Ярким примером ФТП-сервера может служить server хостинга (что означает этот термин), на котором "живет" сайт. Эта информация для вебмастеров не является тайной за семью печатями, но вот тем, кто только планирует заняться сайтостроением, будет как раз к месту.

Или применить более сложный вариант, ежели используется порт, отличный от 21:

Однако же, использование веб-обозревателя в таком разрезе позволит лишь просмотреть или скачать интересующие файлы. Для того, чтобы в полной мере задействовать все плюсы FTP, в качестве клиента следует применить специализированный софт наподобие Файлзиллы (в этом мануале даны все нужные инструкции по установке, настройке и работе с данной программой):

Чтобы подключиться через уже настроенный клиент FileZilla к удаленному серверу, необходимо ввести название хоста, в качестве которого используется IP-адрес сайта, соответствующий его домену (что такое доменное имя и как его приобрести), имя пользователя, пароль и порт.

Кстати, в статье о Файлзилле дана не только стандартная информация, но и практические советы по устранению ее уязвимости в плане безопасности (несмотря на кучу плюсов, проблемы такого рода у ней есть, впрочем, как и у других программ подобного профиля), поэтому настоятельно рекомендую прочитать этот материал, перейдя по чуть выше предоставленной ссылке.

Если расписать этот процесс по пунктам, то получится примерно следующее:

Если пользователь является администратором сайта, который расположен на удаленном сервере, то после аутентификации и подключения он в силах совершать любые возможные действия.

Однако, в интернете довольно много бесплатных ФТП-серверов, по сути являющихся библиотеками разного рода файлов, которые предназначены для хранения и скачивания текстовых документов, музыки, фото, видео, дистрибутивов программ и т.п.

Кроме стандартного соединения с сервером, предусматривающего ввод данных аутентификации, существует понятие анонимного FTP, когда любой пользователь может подключиться к серверу без предоставления персональных данных. Если при этом использовать браузер в качестве клиента, то адрес доступа к файлу может быть упрощен и представлен так:

Безопасный ФТП (SFTP, FTPS и с использованием SSH)

Этот протокол изначально не задумывался как защищенный, так ка разрабатывался в далеком 1971 году и использовался поначалу лишь в научно-исследовательской сети APRANET, доступ в которую имели только несколько военных объектов и университетов.

Но с развитием Мировой Паутины ее частью стал помянутый APRANET, а, следовательно, и технология FTP перекочевала туда же, поскольку обладала многими преимуществами. Однако, одновременно на несколько порядков возросла опасность несанкционированного доступа.

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

1.1. Неявный является устаревшим и использует стандартный протокол, требующий применения SSL или TLS, которые могут обеспечить шифрование информации. При таком методе обязательно нужно использовать порты, отличные от обычных, что создает неудобства, поскольку нарушается совместимость клиентов и серверов, не поддерживающих FTPS.

Главное, в чем заключается его отличие от стандартного ФТП и ФТПС, это то, что СФТП шифрует абсолютно все команды, имена пользователей, пароли и другую конфиденциальную информацию. Так как это совершенно другая конфигурация, клиенты FTP (FTPS) не могут соединиться с SFTP-сервером.

Дело в том, что если несколько SSH-клиентов устанавливают туннель для управляющего канала, который изначально осуществляется через 21 порт (а такая ситуация практически всегда и наблюдается), то защищенным окажется именно этот канал. При передаче же данных клиентское программное обеспечение откроет новые TCP-соединения, которые будут находиться уже вне воздействия защитной оболочки SSH.

Надеюсь, вы не запутались во всех этих вариантах безопасных протоколов. Для того, чтобы как-то облегчить понимание, позволю себе сделать краткое резюме. Объективно обеспечивающим самую высокую степень защиты является SFTP. Немного уступает ему в надежности явный FTPS, однако он более удобен, поскольку дает возможность пользоваться обычными портами. Какой из них выбрать, зависит от вида задачи, которая перед вами стоит и, конечно, настроек сервера.

Поскольку это сетевая передача, включающая взаимодействие между несколькими системами, первое, что нужно учитывать, - это точно определить местонахождение одного или нескольких хостов в сети, а второе - как надежно и эффективно

Передача данных. Здесь будет использоваться протокол TCP / IP.

1.1 Набор протоколов TCP / IP

Протокол TCP / IP (протокол управления передачей) состоит из протокола IP сетевого уровня и протокола TCP транспортного уровня.

Уровень IP отвечает за расположение сетевого хоста и маршрутизацию передачи данных. Хост в Интернете может быть однозначно определен по IP-адресу.

Уровень TCP отвечает за прикладной надежный или ненадежный механизм передачи данных, который является основным объектом сетевого программирования.

TCP / IP - это группа протоколов, которую можно разделить на три уровня: сетевой уровень, транспортный уровень и прикладной уровень:

1.2 TCP

TCP - протокол управления передачей, который обеспечивает ориентированные на соединение, надежные службы потоков байтов. Прежде чем клиент и сервер обмениваются данными друг с другом, между двумя сторонами должно быть установлено TCP-соединение, а затем

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

После установки TCP-соединение будет поддерживаться до тех пор, пока одна из сторон связи не закроет соединение. Когда соединение прерывается, и сервер, и клиент могут инициировать разъединение TCP-соединения.

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

Между сокетами должно быть установлено соединение на основе протокола TCP. Когда сокет (обычно серверный сокет) ожидает установления соединения, другой сокет

Может потребоваться соединение.После подключения двух сокетов они могут выполнять двустороннюю передачу данных, и обе стороны могут отправлять или получать операции.

TCP - это протокол, ориентированный на соединение. Соединение устанавливается посредством трехстороннего рукопожатия. Соединение должно быть удалено после завершения связи. Поскольку TCP является протоколом, ориентированным на соединение, его можно использовать только для связи точка-точка. Кроме того, для установления соединения требуется время и накладные расходы.
Данные передачи TCP не имеют ограничений по размеру и передачи больших объемов данных.
TCP - надежный протокол, он может гарантировать, что получатель может полностью и правильно получить все данные, отправленные отправителем.

Чтобы понять TCP, вы должны знать так называемое «трехстороннее рукопожатие, четыре раза до свидания». Так называемое трехстороннее рукопожатие означает, что соединение, которое должно быть установлено перед отправкой данных, называется трехсторонним рукопожатием.

Это означает ориентированный на соединение.

Пакет, отправленный TCP, имеет порядковый номер, и другая сторона должна дать обратную связь после получения пакета. Если обратная связь не будет получена через определенный период времени, она автоматически выполнит повторную передачу тайм-аута. Следовательно, самым большим преимуществом TCP является надежность. Один

TCP очень важен для сетевой коммуникации.Например, удаленное соединение (Telnet) и передача файлов (FTP) требуют, чтобы данные переменной длины передавались надежно. Но надежная передача - это

По цене проверка правильности содержимого данных неизбежно отнимет время обработки компьютера и пропускную способность сети, поэтому передача TCP не так эффективна, как UDP.

1.3 UDP

UDP-User Datagram Protocol - это простой протокол транспортного уровня, ориентированный на дейтаграммы без установления соединения. UDP не обеспечивает надежность, он просто отправляет дейтаграмму, которую приложение передает на уровень IP.

Идите, но нет гарантии, что они доберутся до места назначения. Поскольку UDP не нужно устанавливать соединение между клиентом и сервером перед передачей дейтаграммы, и нет такого механизма, как повторная передача тайм-аута, она передается

UDP - это протокол без установления соединения, каждая дейтаграмма представляет собой независимую информацию, включая полный адрес источника или адрес назначения, она передается в пункт назначения любым возможным путем в сети.

Таким образом, невозможно гарантировать достижение места назначения, время достижения места назначения и правильность содержания.

UDP - это протокол связи без установления соединения. Данные UDP включают номер порта назначения и номер порта источника. Поскольку для обмена данными не требуется соединение, его можно транслировать.
При передаче данных UDP существует ограничение на размер, и каждая передаваемая дейтаграмма должна быть ограничена 64 КБ.
UDP - ненадежный протокол, и дейтаграммы, отправленные отправителем, не обязательно приходят к получателю в том же порядке.

Видео, QQ, TFTP (простая передача файлов), SNMP (простой протокол управления сетью), RTP (протокол передачи в реальном времени) RIP (протокол маршрутной информации, такой как отчеты о фондовом рынке, авиационное письмо

Информация), DNS (расшифровка доменного имени). Обратите внимание на скорость и плавность хода.

Протокол UDP прост в эксплуатации и требует меньшего контроля, поэтому обычно используется для приложений клиент / сервер в высоконадежных распределенных системах в локальных сетях. Например, система видеоконференцсвязи не требует

Аудио- и видеоданные абсолютно корректны при условии обеспечения непрерывности, в этом случае, очевидно, разумнее использовать UDP.

1.4 Socket

Сокет обычно также называется «сокет», используется для описания IP-адреса и порта и является дескриптором коммуникационной цепочки. Две программы в сети реализуют обмен данными через двустороннее соединение.

Другими словами, один конец этой двусторонней связи называется Socket, а Socket однозначно определяется IP-адресом и номером порта. Приложения обычно делают запросы к сети через «сокеты».

Или отвечать на сетевые запросы. Socket - очень популярный программный интерфейс протокола TCP / IP. Однако тип протокола, поддерживаемого Socket, - это не только TCP / IP, поэтому между ними

Нет нужного подключения. В среде Java программирование Socket в основном относится к сетевому программированию на основе протокола TCP / IP.

Socket - это уровень абстракции промежуточного программного обеспечения для связи между прикладным уровнем и набором протоколов TCP / IP.Это набор интерфейсов. В режиме проектирования Socket фактически является режимом фасада, который объединяет сложные

Семейство протоколов TCP / IP скрыто за интерфейсом Socket.Для пользователей набор простых интерфейсов - это все, что позволяет Socket организовать данные в соответствии с указанным протоколом.

Поскольку соединение Socket обычно является TCP-соединением, после того, как соединение Socket установлено, взаимодействующие стороны могут начать отправлять данные друг другу, пока соединение между двумя сторонами не будет разорвано. Но на самом деле

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

Неактивное соединение вызывает отключение Socket-соединения, поэтому необходимо сообщить сети посредством опроса, что соединение активно.

Концепция розеток: Socket является краеугольным камнем коммуникации и основным операционным блоком сетевой коммуникации, поддерживающей протокол TCP / IP. Это абстрактное представление конечной точки в процессе сетевой коммуникации, включая пять видов информации, необходимой для сетевой коммуникации: протокол, используемый для соединения, IP-адрес локального хоста, порт протокола локального процесса, IP-адрес удаленного хоста и протокол удаленного процесса. порт. Когда прикладной уровень передает данные через транспортный уровень, TCP сталкивается с проблемой предоставления одновременных услуг для нескольких прикладных процессов одновременно. Для передачи данных через один и тот же порт протокола TCP может потребоваться несколько подключений TCP или несколько процессов приложений. Чтобы различать различные процессы и соединения приложений, многие компьютерные операционные системы предоставляют интерфейс сокета (Socket) для взаимодействия приложения с протоколом TCP / IP. Прикладной уровень и транспортный уровень могут различать обмен данными между различными прикладными процессами или сетевыми соединениями через интерфейс Socket и реализовывать параллельную службу передачи данных.
Установите соединение через сокет: Для подключения к сокету требуется по крайней мере пара сокетов, один из которых работает на стороне клиента, называемый ClientSocket, а другой - на стороне сервера, называемый ServerSocket. Процесс подключения между сокетами делится на три этапа: мониторинг сервера, запрос клиента и подтверждение подключения.

Сервер прослушивает : Серверный сокет не обнаруживает конкретный клиентский сокет, но находится в состоянии ожидания подключения, мониторинга состояния сети в реальном времени и ожидания запроса на подключение от клиента;

Запрос клиента : Ссылается на сокет клиента, чтобы сделать запрос на соединение, а целевой объект для подключения - это сокет сервера. По этой причине сокет клиента должен сначала описать сокет сервера, к которому он подключен, указать адрес и номер порта сокета на стороне сервера, а затем сделать запрос подключения к сокету на стороне сервера.

Подтверждение подключения : Когда сокет на стороне сервера отслеживает или получает запрос на соединение сокета на стороне клиента, он отвечает на запрос сокета на стороне клиента, устанавливает новый поток и отправляет описание сокета на стороне сервера клиенту. Как только клиент подтвердит это описание, обе стороны формально установят соединение. Серверный сокет продолжает находиться в состоянии прослушивания и продолжает получать запросы на соединение от других клиентских сокетов.

Во многих случаях серверу необходимо активно передавать данные клиенту, чтобы данные клиента и сервера синхронизировались в реальном времени. В это время, если две стороны устанавливают соединение Socket, сервер может

Прямая передача данных клиенту;

Запустить запрос на подключение. Обычная практика заключается в том, что немедленно не требуется получать какие-либо данные, клиент также продолжает отправлять серверу запрос на «сохранение соединения» через регулярные промежутки времени, и сервер находится в

Ответьте клиенту после получения запроса, указав, что клиент находится «в сети». Если сервер не может получить запрос от клиента в течение длительного времени, клиент считается "не в сети".

Если время не может получить ответ от сервера, считается, что сеть отключена.

Для установления вторичного канала TCP потребуется трехстороннее рукопожатие.

Кроме того, чтобы получить подходящую скорость передачи, TCP необходимо потратить дополнительное время кольцевой связи (RTT). Установление каждой ссылки требует этих повторяющихся накладных расходов, и это не несет

Вы можете не только оставаться в сети, но и «спрашивать», есть ли у сервера новые данные, и если да, то он отправит данные клиенту.

1.6 FTP

Протокол передачи файлов (FTP) - это протокол для передачи файлов между двумя компьютерами в сети TCP / IP. FTP - самый ранний протокол, используемый в сети TCP / IP и ИНТЕРНЕТ.

Один из протоколов, он принадлежит к прикладному уровню набора сетевых протоколов. Клиент FTP может отдавать команды серверу для загрузки файлов, загрузки файлов и создания или изменения каталогов на сервере.

2.1 Коммутация уровня 2

Принцип обмена: реализовать сквозной обмен данными в соответствии с MAC-адресом второго уровня канала передачи данных;

(1) Определенный порт коммутатора принимает пакет данных, считывает MAC-адрес источника и получает MAC-адрес источника порта, подключенного к машине;

(2) Считайте MAC-адрес назначения и найдите соответствующий порт в таблице адресов;

(3) Если в таблице адресов есть порт, соответствующий MAC-адресу назначения, скопируйте данные непосредственно в этот порт;

(4) Если в таблице адресов нет порта, соответствующего MAC-адресу назначения, транслируйте все порты, а когда машина получателя ответит, обновите таблицу адресов, и в следующий раз широковещательная передача не потребуется;

Постоянно повторяя вышеуказанный процесс, можно узнать информацию о MAC-адресе всей сети, а коммутатор уровня 2 просто запомнит и поддерживает свою таблицу адресов. Коммутатор второго уровня выбирает порт для пересылки данных в соответствии с MAC, и алгоритм очень прост, для реализации удобно использовать дешевые чипы, а скорость высокая.

2.2 Коммутация уровня 3

Принцип обмена: полный сквозной обмен данными по IP-адресу третьего сетевого уровня;

Сценарий: A (ip1) => переключатель уровня 3 => B (ip2)

(1) A отправляет данные B. Согласно IP-адресу B + маске подсети A может определить, находятся ли B и он сам в одном сегменте сети;

(2) Если B находится в том же сегменте сети, что и A, но A не знает MAC-адрес B, A отправит запрос ARP для получения MAC-адреса B и отправит данные B через коммутатор уровня 2 в соответствии с MAC;

(3) Если B не находится в том же сегменте сети, что и A, и не знает MAC-адрес B, A отправит пакет данных на шлюз (локальный узел A должен иметь MAC-адрес шлюза). После того, как шлюз получит пакет данных, он изменит MAC-адрес источника на собственный MAC-адрес шлюза, а MAC-адрес, соответствующий IP-адресу назначения, в качестве MAC-адреса назначения для завершения обмена данными.

Кажется, что коммутатор третьего уровня представляет собой комбинацию коммутатора второго уровня + функция маршрутизации, но это не так: после того, как данные проходят через устройство пересылки третьего уровня, будет записано сопоставление между IP и MAC, и оно понадобится в следующий раз.

При пересылке он больше не будет проходить через оборудование третьего уровня.

2.3 Четырехуровневый обмен

Коммутационное оборудование уровней 2 и 3 основано на сквозной коммутации. Эта технология коммутации на основе IP и MAC-адресов имеет очень эффективную скорость передачи, но не требует динамических требований к приложениям, основанных на хосте назначения.

Функция обмена данными.

Четырехуровневое устройство может не только выполнять сквозную коммутацию, но также выделять или ограничивать поток целевого хоста в соответствии с характеристиками его приложения;

Четырехуровневое устройство основано на обмене пакетами данных на уровне передачи, который представляет собой своего рода оборудование, построенное на уровне приложений TCP / IP для реализации требований пользовательских приложений; оно реализует своего рода службы контроля доступа и обеспечения качества на уровне приложений.

Сервис, это не столько аппаратное устройство, сколько программная система управления сетью.

Технология ядра четырехуровневой коммутации

Пакетная фильтрация Используйте четырехуровневую информацию для определения правил фильтрации, которые могут управлять связью TCP / UDP на указанном порту. Это может быть реализовано в высокоскоростном чипе, что значительно улучшает скорость фильтрации пакетов;
Приоритет пакета Устройства ниже третьего уровня имеют только такую информацию, как MAC, PORT и IP. Из-за отсутствия информации четвертого уровня невозможно подтвердить четырехуровневую информацию о приоритете, такую как TCP / IP; четырехуровневое устройство допускает приоритет на основе комбинации адреса / порта назначения (то есть службы приложения) уровень.
Балансировки нагрузки IP-адрес, связанный со службой балансировки нагрузки, превращается в кластер через различные физические службы для предоставления одной и той же службы и определяется как отдельный виртуальный сервер; этот виртуальный сервер является логическим сервером с независимым IP-адресом, пользовательскими данными Поток должен идти только на IP-адрес виртуального сервера, без связи с физическим сервером;

Только после выполнения трансляции сетевых адресов (NAT) через коммутатор можно получить реальный доступ;

Коммуникационный трафик в группе виртуальных серверов преобразуется для достижения баланса, который конкретно связан с OSPF, RIP, VRRP и другими протоколами;

2.4 Семиуровневый обмен

Оба конца программы сгенерируют экземпляр Socket, оперируют этим экземпляром и завершат требуемый сеанс. Для сетевого подключения сокеты равны, разницы нет не из-за сервера

Различные уровни создаются на стороне сервера или на стороне клиента. Будь то Socket или ServerSocket, их работа выполняется через класс SocketImpl и его подклассы.

Читайте также: