По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Основная цель TCP состоит в том, чтобы обеспечить транспортировать данные поверх IP. Как протокол более высокого уровня, он полагается на возможности адресации и мультиплексирования IPv6 для передачи информации на правильный хост назначения. По этой причине TCP не требует схемы адресации. Управление потоком TCP использует метод скользящего окна для управления потоком информации по каждому соединению между двумя хостами. Рисунок 1 демонстрирует это. На рисунке 1 предположим, что начальный размер окна установлен равным 20. Затем последовательность событий: В момент времени t1 отправитель передает 10 пакетов или октетов данных (в случае TCP это 10 октетов данных). В момент времени t2 получатель подтверждает эти 10 октетов, и для окна установлено значение 30. Это означает, что отправителю теперь разрешено отправлять еще до 30 октетов данных перед ожиданием следующего подтверждения; другими словами, отправитель может отправить до 40 октетов, прежде чем он должен будет дождаться подтверждения для отправки дополнительных данных. В момент времени t3 отправитель отправляет еще 5 октетов данных, номера 11–15. В момент времени t4 приемник подтверждает получение октетов через 15, и окно устанавливается на 40 октетов. В момент времени t5 отправитель отправляет около 20 октетов данных, пронумерованных 16–35. В момент времени t6 получатель подтверждает 35, и окно устанавливается на 50. Следует отметить несколько важных моментов, касающихся этой техники: Когда получатель подтверждает получение определенного фрагмента данных, он неявно также подтверждает получение всего, что было до этого фрагмента данных. Если приемник не отправляет подтверждение—к примеру , передатчик отправляет 16-35 в момент времени t5, а приемник не отправляет подтверждение—отправитель будет ждать некоторое время и считать, что данные никогда не поступали, поэтому он будет повторно отправлять данные. Если получатель подтверждает некоторые данные, переданные отправителем, но не все, отправитель предполагает, что некоторые данные отсутствуют, и ретранслирует с точки, которую подтвердил получатель. Например, если отправитель передал 16-35 в момент времени t6, а получатель подтвердил 30, отправитель должен повторно передать 30 и переслать. Окно устанавливается как для отправителя, так и для получателя Вместо использования номеров октетов TCP присваивает каждой передаче порядковый номер; когда приемник подтверждает определенный порядковый номер, передатчик предполагает, что приемник фактически получил все октеты информации вплоть порядкового номера передачи. Для TCP, таким образом, порядковый номер действует как своего рода “стенография” для набора октетов. Рисунок 2 демонстрирует это. На рисунке 2: В момент времени t1 отправитель объединяет октеты 1–10 и передает их, помечая их как порядковый номер 1. В момент времени t2 получатель подтверждает порядковый номер 1, неявно подтверждая получение октетов 1–10. В момент времени t3 отправитель связывает октеты 11–15 вместе и передает их, помечая их как порядковый номер 2. В момент времени t4 получатель подтверждает порядковый номер 2, неявно подтверждая октеты, отправленные через 15. В момент времени t5 предположим, что 10 октетов поместятся в один пакет; в этом случае отправитель отправит два пакета, один из которых содержит 16–25 с порядковым номером 3, а другой - октеты 26–35 с порядковым номером 4. В момент времени t6 приемник подтверждает порядковый номер 4, неявно подтверждая все ранее переданные данные. Что произойдет, если один пакет информации будет пропущен? Что делать, если первый пакет из потока в 100 пакетов не получен? Используя систему, описанную на рисунке 2, получатель просто не подтвердит этот первый пакет информации, вынуждая отправителя повторно передать данные через некоторое время. Однако это неэффективно; каждый потерянный пакет информации требует полной повторной отправки из этого пакета. Реализации TCP используют два разных способа, чтобы получатель мог запросить один пакет. Первый способ - тройное признание. Если получатель трижды подтверждает пакет, который предшествует последнему подтвержденному серийному номеру, отправитель предполагает, что получатель запрашивает повторную передачу пакета. Три повторных подтверждения используются для предотвращения неправильной доставки пакетов или отброшенных пакетов, вызывающих ложный запрос на повторную передачу. Второй способ заключается в реализации выборочных подтверждений (SACK).15 SACK добавляет новое поле к подтверждению TCP, которое позволяет получателю подтвердить получение определенного набора серийных номеров, а не предполагать, что подтверждение одного серийного номера также подтверждает каждый более низкий серийный номер. Как долго передатчик ждет перед повторной передачи? Первый способ, которым отправитель может обнаружить потерянный пакет - это время ожидания повторной передачи (RTO), которое рассчитывается как функция времени приема-передачи (RTT или rtt). Rtt — это временной интервал между передачей пакета отправителем и получением подтверждения от получателя. RTT измеряет задержку в сети от передатчика до приемника, время обработки в приемнике и задержку в сети от приемника до передатчика. Обратите внимание, что rtt может варьироваться в зависимости от пути, по которому каждый пакет проходит через сеть, локальных условий в момент коммутации пакета и т. д. RTO обычно рассчитывается как средневзвешенное значение, при котором более старые временные интервалы оказывают меньшее влияние, чем более поздние измеренные значения. Альтернативным механизмом, используемым в большинстве реализаций TCP, является быстрая ретрансляция. При быстрой повторной передаче получатель добавляет единицу к ожидаемому порядковому номеру в любом подтверждении. Например, если отправитель передает последовательность 10, получатель подтверждает последовательность 11, даже если он еще не получил последовательность 11. В этом случае порядковый номер в подтверждении подтверждает получение данных и указывает, какой порядковый номер он ожидает от отправителя для передачи в следующий раз. Если передатчик получает подтверждение с порядковым номером, который на единицу больше последнего подтвержденного порядкового номера три раза подряд, он будет считать, что следующие пакеты были отброшены. Таким образом, существует два типа потери пакетов в TCP, когда реализован быстрый запуск. Первый-это стандартный тайм-аут, который возникает, когда отправитель передает пакет и не получает подтверждения до истечения срока действия RTO. Это называется отказом RTO. Второй называется быстрым сбоем ретрансляции. Эти два условия часто обрабатываются по-разному. Как выбирается размер окна? При выборе размера окна необходимо учитывать ряд различных факторов, но доминирующим фактором часто является получение максимально возможной производительности при одновременном предотвращении перегрузки канала. Фактически, контроль перегрузки TCP, вероятно, является основной формой контроля перегрузки, фактически применяемой в глобальном Интернете. Чтобы понять контроль перегрузки TCP, лучше всего начать с некоторых определений: Окно приема (RWND): объем данных, которые приемник готов принять; это окно обычно устанавливается на основе размера буфера приемника или какого-либо другого ресурса, доступного в приемнике. Это размер окна, объявленный в заголовке TCP. Окно перегрузки (CWND): объем данных, которые передатчик готов отправить до получения подтверждения. Это окно не объявляется в заголовке TCP; получатель не знает размер CWND. Порог медленного запуска (SST): CWND, при котором отправитель считает соединение с максимальной скоростью передачи пакетов без возникновения перегрузки в сети. SST изначально устанавливается реализацией и изменяется в случае потери пакета в зависимости от используемого механизма предотвращения перегрузки. Большинство реализаций TCP начинают сеансы с алгоритма медленного старта. 16 На этом этапе CWND начинается с 1, 2 или 10. Для каждого сегмента, для которого получено подтверждение, размер CWND увеличивается на 1. Учитывая, что такие подтверждения должны занимать ненамного больше времени, чем один rtt, медленный запуск должен привести к удвоению окна каждого rtt. Окно будет продолжать увеличиваться с этой скоростью до тех пор, пока либо пакет не будет потерян (приемник не сможет подтвердить пакет), CWND не достигнет RWND, либо CWND не достигнет SST. Как только любое из этих трех условий происходит, отправитель переходит в режим предотвращения перегрузки. Примечание. Каким образом увеличение CWND на 1 для каждого полученного ACL удваивает окно для каждого rtt? Идея состоит в следующем: когда размер окна равен 1, вы должны получать один сегмент на каждый RTT. Когда вы увеличиваете размер окна до 2, вы должны получать 2 сегмента в каждом rtt; на 4, вы должны получить 4 и т. д. Поскольку получатель подтверждает каждый сегмент отдельно и увеличивает окно на 1 каждый раз, когда он подтверждает сегмент, он должен подтвердить 1 сегмент в первом rtt и установить окно на 2; 2 сегмента во втором rtt, добавляя 2 к окну, чтобы установить окно на 4; 4 сегмента в третьем RTT, добавив 4 к окну, чтобы установить размер окна равным 8 и т. д. В режиме предотвращения перегрузки CWND увеличивается один раз за каждый rtt, что означает, что размер окна перестает расти экспоненциально, а вместо этого увеличивается линейно. CWND будет продолжать расти либо до тех пор, пока получатель не подтвердит получение пакета (TCP предполагает, что это означает, что пакет был потерян или отброшен), либо пока CWND не достигнет RWND. Существует два широко распространенных способа, которыми реализация TCP может реагировать на потерю пакета, называемых Tahoe и Reno. Примечание. На самом деле существует множество различных вариаций Tahoe и Reno; здесь рассматриваются только самые базовые реализации. Также существует множество различных методов реагирования на потерю пакета, когда соединение находится в режиме предотвращения перегрузки. Если реализация использует Tahoe, и потеря пакета обнаружена посредством быстрой повторной передачи, она установит SST на половину текущего CWND, установит CWND на исходное значение и снова начнет медленный запуск. Это означает, что отправитель снова будет передавать 1, 2 или 10 порядковых номеров, увеличивая CWND для каждого подтвержденного порядкового номера. Как и в начале процесса медленного запуска, это приводит к удвоению CWND каждого rtt. Как только CWND достигнет SST, TCP вернется в режим предотвращения перегрузки. Если реализация использует Reno, и потеря пакета обнаружена посредством быстрой повторной передачи, она установит SST и CWND на половину текущего CWND и продолжит работу в режиме предотвращения перегрузки. В любой реализации, если обнаруживается потеря пакета из-за того, что получатель не отправляет подтверждение в пределах RTO, CWND устанавливается на 1, и медленный запуск используется для увеличения скорости соединения. Контроль ошибок TCP предоставляет две формы обнаружения ошибок и управления ими: Сам протокол, наряду с механизмом управления окнами, обеспечивает доставку данных в приложение по порядку и без какой-либо недостающей информации. Контрольная сумма дополнения единицы, включенная в заголовок TCP, считается более слабой, чем Cyclic Redundancy Check (CRC) и многие другие формы обнаружения ошибок. Эта проверка ошибок служит дополнением, а не заменой, коррекции ошибок, обеспечиваемой протоколами ниже и выше в стеке. Если получатель обнаруживает ошибку контрольной суммы, он может использовать любой из описанных здесь механизмов, чтобы запросить отправителя повторно передать данные—просто не подтверждая получение данных, запрашивая повторную передачу через SACK, активно не подтверждая получение данных через быструю повторную передачу или отправляя тройное подтверждение для конкретного сегмента, содержащего поврежденные данные. Номера портов TCP TCP не управляет каким-либо типом мультиплексирования напрямую; однако он предоставляет номера портов, которые приложения и протоколы выше TCP в стеке протоколов могут использовать для мультиплексирования. Хотя эти номера портов передаются в TCP, они обычно непрозрачны для TCP; TCP не придает никакого значения этим номерам портов, кроме использования их для отправки информации правильному приложению на принимающем узле. Номера TCP-портов делятся на два широких класса: хорошо известные и эфемерные. Хорошо известные порты определяются как часть спецификации протокола верхнего уровня; эти порты являются портами «по умолчанию» для этих приложений. Например, службу, поддерживающую Simple Mail Transfer Protocol (SMTP), обычно можно найти, подключившись к узлу с использованием TCP на порт номер 25. Службу, поддерживающую Hypertext Transport Protocol (HTTP), обычно можно найти, подключившись к узлу с использованием TCP на порт 80. Эти службы не обязательно должны использовать эти номера портов; большинство серверов можно настроить на использование какого-либо номера порта, отличного от указанного в спецификации протокола. Например, веб-серверы, не предназначенные для общего (или общедоступного) использования, могут использовать какой-либо другой TCP-порт, например 8080. Эфемерные порты значимы только для локального хоста и обычно назначаются из пула доступных номеров портов на локальном хосте. Эфемерные порты чаще всего используются в качестве исходных портов для TCP-соединений; например, хост, подключающийся к службе через порт 80 на сервере, будет использовать эфемерный порт в качестве исходного TCP-порта. До тех пор, пока любой конкретный хост использует данный эфемерный номер порта только один раз для любого TCP-соединения, каждый сеанс TCP в любой сети может быть однозначно идентифицирован через исходный адрес, исходный порт, адрес назначения, порт назначения и номер протокола, работающего поверх TCP. Настройка сеанса TCP TCP использует трехстороннее рукопожатие для установки сеанса: Клиент отправляет синхронизацию (SYN) на сервер. Этот пакет является обычным TCP-пакетом, но с битом SYN, установленным в заголовке TCP, и указывает, что отправитель запрашивает сеанс для настройки с получателем. Этот пакет обычно отправляется на хорошо известный номер порта или на какой-то заранее установленный номер порта, который, как известно клиенту, будет прослушиваться сервером по определенному IP-адресу. Этот пакет включает в себя начальный порядковый номер клиента. Сервер отправляет подтверждение для SYN, SYN-ACK. Этот пакет подтверждает порядковый номер, предоставленный клиентом, плюс один, и включает начальный порядковый номер сервера в качестве порядкового номера для этого пакета. Клиент отправляет подтверждение (ACK), включающее начальный порядковый номер сервера плюс один. Этот процесс используется для обеспечения двусторонней связи между клиентом и сервером перед началом передачи данных. Первоначальный порядковый номер, выбранный отправителем и получателем, в большинстве реализаций рандомизирован, чтобы не дать стороннему злоумышленнику угадать, какой порядковый номер будет использоваться, и захватить сеанс TCP на начальных этапах его формирования.
img
В 2012 году Джим Роскинд разработал новый транспортный протокол, основной целью которого было увеличение скорости, с которой данные могут передаваться по относительно стабильным высокоскоростным сетям. В частности: Сокращение трехстороннего рукопожатия до запуска одного пакета (нулевое рукопожатие) Уменьшение количества повторно передаваемых пакетов, необходимых для передачи данных Уменьшение блокировки заголовка между несколькими потоками данных в пределах одного потока TCP, вызванной потерей пакетов Уменьшение рукопожатия при запуске Как правило, значение rtt нельзя изменить, поскольку оно обычно ограничено физическим расстоянием и скоростью соединения между отправителем и получателем. Таким образом, один из лучших способов сократить общее время передачи данных - просто уменьшить количество циклов обмена, необходимых между отправителем и получателем для передачи заданного потока или блока данных. QUIC разработан для сокращения количества циклов приема-передачи, необходимых для установки нового соединения, от трехстороннего подтверждения TCP до процесса запуска с нулевым временем приема-передачи. Для этого QUIC использует серию криптографических ключей и хэшей; процесс состоит из: Клиент отправляет серверу приветствие (CHLO), содержащее требование подтверждения, которое представляет собой список типов сертификатов, которые клиент примет для проверки идентичности сервера; набор сертификатов, к которым у клиента есть доступ; и хэш сертификата, который клиент намеревается использовать в этом соединении. Одно конкретное поле, маркер адреса источника (STK) будет оставлено пустым, потому что раньше с этим сервером не было связи. Сервер будет использовать эту информацию для создания STK на основе информации, предоставленной в первоначальном приветствии клиента и исходном IP-адресе клиента. Сервер отправляет отклонение (REJ), которое содержит этот STK. Как только клиент получает STK, он включает его в будущие пакеты приветствия. Если STK совпадает с ранее использованным STK с этого IP-адреса, сервер примет приветствие. Примечание: Эта пара IP-адрес / STK может быть украдена, и, следовательно, исходный IP-адрес может быть подменен злоумышленником с доступом к любой связи с этой парой. Это известная проблема в QUIC, которая рассматривается в документации QUIC. Для сравнения, TCP требует, как минимум полтора rtts для создания нового сеанса: SYN, SYN-ACK, а затем следующий ACK. Сколько времени экономит при переходе на одно соединение rtt? Конечно, это зависит от реализации клиентского и серверного приложений. Однако многие веб-страницы и приложения для мобильных устройств должны подключаться к множеству разных серверов (возможно, к сотням) для создания единой веб-страницы. Если каждое из этих подключений уменьшить с полутора до одного RTT, это может значительно снизить производительность. Сокращение повторных передач QUIC использует ряд различных механизмов для уменьшения количества повторно передаваемых пакетов: Включая Forward Error Correction (FEC) во все пакеты; это позволяет получателю (часто) восстанавливать поврежденную информацию, а не запрашивать ее повторно. Использование отрицательных подтверждений (NACK) вместо SACK или механизма тройного ACK для запроса повторной передачи определенных порядковых номеров; это предотвращает неоднозначность между запросом на повторную передачу и условиями сети, которые вызывают отправку нескольких подтверждений. Использование быстрых подтверждений, как описано ранее для TCP. Использование управления окном предотвращения перегрузки CUBIC. Механизм предотвращения перегрузки CUBIC - самый интересный из них. CUBIC пытается выполнить двоичный поиск между последним размером окна перед отбрасыванием пакета и некоторым меньшим размером окна, рассчитанным с использованием множительного коэффициента. Когда обнаруживается потеря пакета (либо через тайм-аут RTO, либо через NACK), максимальный размер окна (WMAX) устанавливается равным текущему размеру окна, и вычисляется новый минимальный размер окна (WMIN). Окно отправителя устанавливается на WMIN, а затем быстро увеличивается до размера окна посередине между WMIN и WMAX. Как только окно достигает этой средней точки, размер окна очень медленно увеличивается при так называемом зондировании, пока не встретится следующий сброс пакета. Этот процесс позволяет CUBIC находить максимальную скорость передачи чуть ниже точки, в которой сеть начинает довольно быстро отбрасывать пакеты. Исключение блокировки начала строки "Единая транзакция" в Интернете часто является не "отдельной транзакцией", а скорее большим набором транзакций на нескольких разных серверах. Например, чтобы создать единую веб-страницу, сотни элементов, таких как изображения, скрипты, элементы каскадной таблицы стилей (CSS) и файлы языка гипертекстовой разметки (HTML), должны быть переданы с сервера на клиент. Эти файлы можно передавать двумя способами: последовательно или параллельно. Рисунок 1 иллюстрирует это. На рисунке 1 показаны три варианта передачи нескольких элементов от сервера к клиенту: В serialized варианте элементы передаются по одному в течение одного сеанса. Это самый медленный из трех возможных вариантов, так как вся страница должна быть построена поэлементно, при этом меньшие элементы ждут передачи больших, прежде чем их можно будет отобразить. В варианте с несколькими потоками (multiple streams) каждый элемент передается через отдельное соединение (например, сеанс TCP). Это намного быстрее, но требует создания нескольких подключений, что может негативно повлиять на ресурсы клиента и сервера. В мультиплексном (multiplexed) варианте каждый элемент передается отдельно через одно соединение. Это позволяет передавать каждый элемент с его собственной скоростью, но с дополнительными расходами ресурсов из-за опции нескольких потоков. Некоторые формы механизма мультиплексной передачи имеют тенденцию обеспечивать максимальную скорость передачи при наиболее эффективном использовании ресурсов, но как это мультиплексирование должно быть реализовано? Протокол передачи гипертекста версии 2 (HTTPv2) позволяет веб-серверу мультиплексировать несколько элементов в одном сеансе HTTP; поскольку HTTP работает поверх TCP, это означает, что один поток TCP может использоваться для параллельной передачи нескольких элементов веб-страницы. Однако один отброшенный пакет на уровне TCP означает, что каждая параллельная передача в потоке HTTP должна быть приостановлена на время восстановления TCP. QUICK решает эту проблему, позволяя нескольким потокам HTTP v2 находиться в одном быстром соединении. Это уменьшает транспортные издержки на клиенте и сервере, обеспечивая при этом оптимальную доставку элементов веб - страницы. Обнаружение MTU пути Одним из основных вопросов спора между асинхронным режимом передачи (ATM) и интернет-протоколом (IP) был фиксированный размер ячейки. В то время как IP-сети полагаются на пакеты переменной длины, ATM, чтобы обеспечить более высокую скорость коммутации и улучшить взаимодействие с множеством различных физических уровней Time Division Multiplexing (TDM), задал ячейки фиксированной длины. В частности, IPv4 обеспечивает не только пакет переменной длины, но и фрагментацию в процессе передачи. Рисунок 2 иллюстрирует это. На рис. 2 показано, что если A посылает пакет в направлении E, то какого размера он должен быть? Единственный канал, о котором действительно знает А, - это канал между собой и В, которое помечено как имеющее максимальный размер блока передачи 1500 октетов (Maximum Transmission Unit- MTU). Однако если A отправляет пакет длиной 1500 октетов, то этот пакет не сможет пройти через канал [C,D]. Есть два способа решить эту проблему. Первый заключается в том, что C фрагментирует пакет на два меньших пакета. Это возможно в IPv4; C может определить, что пакет не поместится на следующем канале, по которому пакет должен быть передан, и разбить пакет на два меньших пакета. Конечно, с этим решением есть ряд проблем. Например, процесс фрагментации пакета требует гораздо больше работы со стороны C, возможно, даже перемещение пакета из аппаратного пути коммутации в программный путь коммутации. Во-вторых, A никогда не отправляет пакет, превышающий минимальный MTU, по всему пути к E. Для этого A должен определить минимальный MTU на пути, и он должен иметь возможность фрагментировать информацию, отправляемую из протоколов верхнего уровня на несколько пакетов перед передачей. IPv6 выбирает этот последний вариант, полагаясь на обнаружение Path MTU (PMTU), чтобы найти минимальный MTU на пути (при условии, что PMTU действительно работает), и позволяя процессу IPv6 в A фрагментировать информацию из протоколов верхнего уровня на несколько пакетов, которые затем повторно собираются в исходный блок данных верхнего уровня в приемнике. Это решение, однако, также является проблемным. В недавней работе с системой доменных имен (DNS) исследователи обнаружили, что около 37% всех DNS- resolvers отбрасывают фрагментированные пакеты IPv6. Почему это происходит? Самый простой способ понять это-рассмотреть структуру фрагментированного пакета, а также природу DoS и DDoS атак. При передаче пакета, в пакет помещается заголовок, указывающий принимающую услугу (номер сокета или протокола какого-либо рода), а также информацию о передаваемой услуге. Эта информация важна для фильтрации пакета на основе различных политик безопасности, особенно если политика безопасности гласит: "разрешать только пакеты инициации сеанса в сеть, если пакет не принадлежит существующему сеансу." Другими словами, типичный фильтр с отслеживанием состояния, защищающий сервер, будет иметь некоторые основные правила, которым он следует: Если пакет инициирует новый сеанс, пересылайте его и создайте новую запись сеанса. Если пакет является частью существующего сеанса, перенаправьте его и сбросьте таймер сеанса. Если пакет не является частью существующего сеанса, отбросьте его. Время от времени очищайте старые сеансы. Возможно подделать пакет, похожий на настоящий, но это очень сложно, т.к. используются различные nonce и другие методы, чтобы препятствовать подобному поведению. Но фрагментация пакета удаляет заголовок из второй половины пакета, что фактически означает, что второй пакет во фрагментированной паре может быть присоединен только к определенному сеансу или потоку, отслеживая часть пакета, которая имеет полный заголовок. Как маршрутизатор или middlebox могут выполнить это? Он должен каким-то образом хранить копию каждого фрагмента пакета с заголовком где-нибудь в памяти, чтобы на пакет с заголовком можно было ссылаться для обработки любых будущих фрагментов. Как долго он должен хранить эти фрагменты с заголовками? На это нет ответа. Проще просто отбросить любые фрагменты, чем поддерживать состояние, необходимое для их обработки. Каков результат? Похоже, что даже фрагментация на основе исходного кода не очень полезна на уровне IP. Это должно напомнить об одном из основополагающих принципов пакета Интернет-протоколов: end-to-end принципе. End-to-end принцип гласит, что сеть не должна изменять трафик, передаваемый между двумя оконечными устройствами; или, скорее, сеть должна работать как черный ящик, соединяющий два устройства, никогда не изменяя данные, полученные от конечного хоста. Означает ли это, что вся фильтрация трафика должна быть запрещена в общедоступном Интернете, всерьез навязывая end-to-end правило, оставляя всю безопасность конечным хостам? Это представляет собой первоначальное обсуждения фильтрации пакетов в IPv6 с отслеживанием состояния. Однако это менее реалистичный вариант; более сильная защита - это не один идеальный файрволл, а скорее серия неидеальных файрволлов. Другая альтернатива - принять еще одну частичку реальности, о которой часто забывают в мире сетевой инженерии: утечка абстракций. Сквозной принцип описывает идеально абстрактную систему, способную передавать трафик от одного хоста к другому, и совершенно абстрагированный набор хостов, между которыми переносится трафик. Но утекают все нетривиальные абстракции; проблема MTU и фрагментации - это просто утечка состояния из сети в хост, а система на хосте пытается абстрагировать эту утечку в приложение, отправляющее трафик по сети. В такой ситуации лучше всего просто признать утечку и официально отправить информацию в стек, чтобы приложение могло лучше принять решение о том, как отправлять трафик. Другая альтернатива-принять еще одну частицу реальности, часто забываемую в мире сетевой инженерии: утечку абстракций. Сквозной принцип описывает идеально абстрагированную систему, способную передавать трафик от одного хоста к другому, и идеально абстрагированный набор хостов, между которыми осуществляется трафик. Но все нетривиальные абстракции протекают; проблема MTU и фрагментации-это просто утечка состояния из сети в хост, и система на хосте пытается абстрагировать эту утечку в приложение, отправляющее трафик по сети. В такой ситуации, возможно, лучше всего просто признать утечку и официально продвинуть информацию вверх по стеку, чтобы приложение могло принять лучшее решение о том, как отправлять трафик. Но это приводит к еще одному интересному вопросу для размышления: является ли описанная здесь фильтрация состояний предательством end-to-end принципа? Ответ зависит от того, считаете ли вы протокол верхнего уровня, отправляющий данные, конечной точкой, или систему, на которой работает приложение (следовательно, включая сам стек IP), конечной точкой. Так или иначе, эта двусмысленность преследовала Интернет с самых ранних дней, хотя мир сетевой инженерии не всегда серьезно задумывался о разнице между этими двумя точками зрения. ICMP Хотя транспортные протоколы, такие как TCP и QUIC, обычно привлекают наибольшее внимание среди протоколов среднего уровня, существует ряд других протоколов, которые не менее важны для работы сети на основе IP. Среди них - протокол ICMP, который, можно сказать, предоставляет метаданные о самой сети. ICMP - это простой протокол, который используется для запроса информации о конкретном состоянии или для отправки сетевыми устройствами информации о том, почему определенный пакет отбрасывается в какой-либо точке сети. В частности: ICMP может использоваться для отправки эхо-запроса или эхо-ответа. Эта функция используется для проверки связи с конкретным адресом назначения, который можно использовать для определения доступности адреса без использования слишком большого количества ресурсов на приемнике. ICMP можно использовать для отправки уведомления об отброшенном пакете из-за того, что он слишком велик для передачи по каналу (слишком большой пакет). ICMP может использоваться для отправки уведомления о том, что пакет был отброшен, поскольку его время жизни (TTL) достигло 0 (срок действия пакета истек при передаче). Ответ на слишком большой пакет можно использовать для определения максимального размера передаваемого блока (MTU) в сети; отправитель может передать большой пакет и дождаться, чтобы увидеть, не отправит ли какое-либо устройство в сети уведомление о слишком большом пакете через ICMP. Если такое уведомление приходит, отправитель может попробовать постепенно уменьшать пакеты, чтобы определить самый большой пакет, который может быть передан из конца в конец по сети. Ответ с истекшим транзитом может использоваться для отслеживания маршрута от источника до пункта назначения в сети (это называется трассировкой маршрута). Отправитель может передать пакет в конкретное место назначения, используя любой протокол транспортного уровня (включая TCP, UDP или QUIC), но с TTL равным 1. Сетевое устройство первого перехода должно уменьшить TTL и отправить обратно ICMP-сообщение с истекшим сроком действия в транзитном уведомлении отправителю. Отправляя серию пакетов, каждый с TTL на один больше, чем предыдущий, каждое устройство на пути может быть вынуждено передать отправителю сообщение ICMP с истекшим сроком действия в транзитном уведомлении, открывая весь путь пакета.
img
Транспортный уровень OSI (уровень 4) определяет несколько функций, наиболее важными из которых являются восстановление после ошибок и управление потоком. Точно так же протоколы транспортного уровня TCP / IP также реализуют те же типы функций. Обратите внимание, что и модель OSI, и модель TCP / IP называют этот уровень транспортным. Но, как обычно, когда речь идет о модели TCP / IP, имя и номер уровня основаны на OSI, поэтому любые протоколы транспортного уровня TCP / IP считаются протоколами уровня 4. Ключевое различие между TCP и UDP заключается в том, что TCP предоставляет широкий спектр услуг приложениям, а UDP-нет. Например, маршрутизаторы отбрасывают пакеты по многим причинам, включая битовые ошибки, перегрузку и случаи, в которых не известны правильные маршруты. Известно, что большинство протоколов передачи данных замечают ошибки (процесс, называемый error detection), и затем отбрасывают кадры, которые имеют ошибки. TCP обеспечивает повторную передачу (error recovery) и помогает избежать перегрузки (управление потоком), в то время как UDP этого не делает. В результате многие прикладные протоколы предпочитают использовать TCP. Разница между TCP и UDP в одном видео Однако не думайте, что отсутствие служб у UDP делает UDP хуже TCP. Предоставляя меньше услуг, UDP требует меньше байтов в своем заголовке по сравнению с TCP, что приводит к меньшему количеству байтов служебных данных в сети. Программное обеспечение UDP не замедляет передачу данных в тех случаях, когда TCP может замедляться намеренно. Кроме того, некоторым приложениям, особенно сегодня, к передаче голоса по IP (VoIP) и видео по IP, не требуется восстановление после ошибок, поэтому они используют UDP. Итак, сегодня UDP также занимает важное место в сетях TCP / IP. В таблице 1 перечислены основные функции, поддерживаемые TCP/UDP. Обратите внимание, что только первый элемент, указанный в таблице, поддерживается UDP, тогда как TCP поддерживаются все элементы в таблице. Таблица № 1 Функции транспортного уровня TCP/IP Функции Описание Мультиплексирование с использованием портов Функция, которая позволяет принимающим хостам выбирать правильное приложение, для которого предназначены данные, на основе номера порта. Восстановление после ошибок (надежность) Процесс нумерации и подтверждения данных с помощью полей заголовка Sequence и Acknowledgment Управление потоком с использованием окон Процесс, использующий размеры окна для защиты буферного пространства и устройств маршрутизации от перегрузки трафиком. Установление и завершение соединения Процесс, используемый для инициализации номеров портов, а также полей Sequence и Acknowledgment. Упорядоченная передача данных и сегментация данных Непрерывный поток байтов от процесса верхнего уровня, который "сегментируется" для передачи и доставляется процессам верхнего уровня на принимающем устройстве с байтами в том же порядке Далее описываются возможности TCP, а затем приводится краткое сравнение с UDP. Transmission Control Protocol Каждое приложение TCP / IP обычно выбирает использование TCP или UDP в зависимости от требований приложения. Например, TCP обеспечивает восстановление после ошибок, но для этого он потребляет больше полосы пропускания и использует больше циклов обработки. UDP не выполняет исправление ошибок, но требует меньшей пропускной способности и меньшего количества циклов обработки. Независимо от того, какой из этих двух протоколов транспортного уровня TCP / IP приложение выберет для использования, вы должны понимать основы работы каждого из этих протоколов транспортного уровня. TCP, как определено в Request For Comments (RFC) 793, выполняет функции, перечисленные в таблице 1, через механизмы на конечных компьютерах. TCP полагается на IP для сквозной доставки данных, включая вопросы маршрутизации. Другими словами, TCP выполняет только часть функций, необходимых для доставки данных между приложениями. Кроме того, роль, которую он играет, направлена на предоставление услуг для приложений, установленных на конечных компьютерах. Независимо от того, находятся ли два компьютера в одном Ethernet или разделены всем Интернетом, TCP выполняет свои функции одинаково. На рисунке 1 показаны поля заголовка TCP. Хотя вам не нужно запоминать названия полей или их расположение, оставшаяся часть этой лекции относится к нескольким полям, поэтому весь заголовок включен сюда для справки. Сообщение, созданное TCP, которое начинается с заголовка TCP, за которым следуют данные приложения, называется сегментом TCP. В качестве альтернативы также может использоваться более общий термин PDU уровня 4 или L4PDU. Мультиплексирование с использованием номеров портов TCP И TCP, и UDP используют концепцию, называемую мультиплексированием. Поэтому этот подраздел начинается с объяснения мультиплексирования с TCP и UDP. После этого исследуются уникальные возможности TCP. Мультиплексирование по TCP и UDP включает в себя процесс того, как компьютер думает при получении данных. На компьютере может быть запущено множество приложений, таких как веб-браузер, электронная почта или приложение Internet VoIP (например, Skype). Мультиплексирование TCP и UDP сообщает принимающему компьютеру, какому приложению передать полученные данные. Определенные примеры помогут сделать очевидной необходимость мультиплексирования. Сеть из примера состоит из двух компьютеров, помеченных как Анна и Гриша. Анна использует написанное ею приложение для рассылки рекламных объявлений, которые появляются на экране Григория. Приложение отправляет Григорию новое объявление каждые 10 секунд. Анна использует второе приложение, чтобы отправить Грише деньги. Наконец, Анна использует веб-браузер для доступа к веб-серверу, который работает на компьютере Григория. Рекламное приложение и приложение для электронного перевода являются воображаемыми, только для этого примера. Веб-приложение работает так же, как и в реальной жизни. На рисунке 2 показан пример сети, в которой Гриша запускает три приложения: Рекламное приложение на основе UDP Приложение для банковских переводов на основе TCP Приложение веб-сервера TCP Грише необходимо знать, в какое приложение передавать данные, но все три пакета поступают из одного и того же Ethernet и IP-адреса. Вы могли подумать, что Григорий может посмотреть, содержит ли пакет заголовок UDP или TCP, но, как вы видите на рисунке, два приложения (wire transfer и web) используют TCP. TCP и UDP решают эту проблему, используя поле номера порта в заголовке TCP или UDP соответственно. Каждый из сегментов TCP и UDP Анны использует свой номер порта назначения, чтобы Григорий знал, какому приложению передать данные. На рисунке 3 показан пример. Мультиплексирование основывается на концепции, называемой сокетом. Сокет состоит из трех частей: IP-адрес Транспортный протокол Номер порта Итак, для приложения веб-сервера Григория, сокет будет (10.1.1.2, TCP, порт 80), потому что по умолчанию веб-серверы используют хорошо известный порт 80. Когда веб-браузер Анны подключается к веб-серверу, Анна также использует сокет - возможно, такой: (10.1.1.1, TCP, 49160). Почему 49160? Что ж, Анне просто нужен номер порта, уникальный для Анны, поэтому Анна видит этот порт 49160. Internet Assigned Numbers Authority (IANA), организация, которая управляет распределением IP-адресов во всем мире, и подразделяет диапазоны номеров портов на три основных диапазона. Первые два диапазона резервируют номера, которые IANA затем может назначить конкретным протоколам приложений через процесс приложения и проверки, а третья категория резервирует порты, которые будут динамически выделяться для клиентов, как в примере с портом 49160 в предыдущем абзаце. Имена и диапазоны номеров портов (более подробно описано в RFC 6335): Хорошо известные (системные) порты: номера от 0 до 1023, присвоенные IANA, с более строгим процессом проверки для назначения новых портов, чем пользовательские порты. Пользовательские (зарегистрированные) порты: номера от 1024 до 49151, присвоенные IANA с менее строгим процессом назначения новых портов по сравнению с хорошо известными портами. Эфемерные (динамические, частные) порты: номера от 49152 до 65535, не назначены и не предназначены для динамического выделения и временного использования для клиентского приложения во время его работы. На рисунке 4 показан пример, в котором используются три временных порта на пользовательском устройстве слева, а сервер справа использует два хорошо известных порта и один пользовательский порт. Компьютеры используют три приложения одновременно; следовательно, открыто три сокетных соединения. Поскольку сокет на одном компьютере должен быть уникальным, соединение между двумя сокетами должно идентифицировать уникальное соединение между двумя компьютерами. Эта уникальность означает, что вы можете использовать несколько приложений одновременно, разговаривая с приложениями, запущенными на одном или разных компьютерах. Мультиплексирование на основе сокетов гарантирует, что данные будут доставлены в нужные приложения. Номера портов являются важной частью концепции сокетов. Серверы используют хорошо известные порты (или пользовательские порты), тогда как клиенты используют динамические порты. Приложения, которые предоставляют услуги, такие как FTP, Telnet и веб-серверы, открывают сокет, используя известный порт, и прослушивают запросы на подключение. Поскольку эти запросы на подключение от клиентов должны включать номера портов источника и назначения, номера портов, используемые серверами, должны быть известны заранее. Таким образом, каждая служба использует определенный хорошо известный номер порта или номер пользовательского порта. Как общеизвестные, так и пользовательские порты перечислены на www.iana.org/assignments/servicenames-port-numbers/service-names-port-numbers.txt. На клиентских машинах, откуда исходят запросы, можно выделить любой локально неиспользуемый номер порта. В результате каждый клиент на одном и том же хосте использует другой номер порта, но сервер использует один и тот же номер порта для всех подключений. Например, 100 веб-браузеров на одном и том же хост-компьютере могут подключаться к веб-серверу, но веб-сервер со 100 подключенными к нему клиентами будет иметь только один сокет и, следовательно, только один номер порта (в данном случае порт 80). Сервер может определить, какие пакеты отправлены от какого из 100 клиентов, посмотрев на порт источника полученных сегментов TCP. Сервер может отправлять данные правильному веб-клиенту (браузеру), отправляя данные на тот же номер порта, который указан в качестве порта назначения. Комбинация сокетов источника и назначения позволяет всем участвующим хостам различать источник и назначение данных. Хотя в примере объясняется концепция использования 100 TCP-соединений, та же концепция нумерации портов применяется к сеансам UDP таким же образом. Почитайте продолжение цикла про популярные приложения TCP/IP.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59