Почему бит ACK всегда установлен почти во всех пакетах TCP, ожидающих первый SYN? [Дубликат]
3 ответа
Это вроде как:
+-------------------------------------------------------+
| client network server |
+-----------------+ +--------------------|
| (connect) | ---- SYN ----> | |
| | <-- SYN,ACK -- | (accepted) |
| (connected) | ---- ACK ----> | |
\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/
when client sends...
\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/
| | | |
| (send) | ---- data ---> | |
| | <---- ACK ---- | (data received) |
\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/
when server sends...
\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/
| | | |
| | <--- data ---- | (send) |
| (data received) | ---- ACK ----> | |
\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/
...and so on, til the connection is shut down or reset
SYN запускает соединение; вы обычно увидите это только при установлении соединения. Но все данные, отправляемые через TCP, требуют ACK. Каждый отправленный байт должен быть учтен, или он будет повторно передан (или сброс соединения (закрыт) в тяжелых случаях).
Фактические соединения обычно не являются точно , как диаграмма выше, однако, по двум причинам:
- ACK могут создаваться, поэтому один ACK может подтвердить все полученные до этой точки. Это означает, что вы можете подтвердить два или более сообщений с одним ACK.
- ACK - это просто флаг и поле в заголовке TCP. Для отправки требуется, по крайней мере, пропускная способность заголовка, плюс все, что касается нижних слоев. Но сегменты данных уже включают все, что ... поэтому, если вы отправляете данные, вы можете отправить ACK в то же время бесплатно.
Большинство стеков TCP / IP пытаются уменьшить количество голых ACK без чрезмерного риска повторной передачи или сброса соединения. Таким образом, такой разговор вполне возможен:
\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/
| | | |
| | <--- data ---- | (send) |
| (data received) | | |
| (send) | -- data,ACK -> | |
| | | (data received) |
| | <- data,ACK -- | (send) |
| (data received) | | |
| (wait a bit) | <--- data ---- | (send) |
| (data received) | | |
| (send) | -- data,ACK -> | |
| | | (data received) |
| (send) | ---- data ---> | (wait a bit) |
| | | (data received) |
| | <- data,ACK -- | (send) |
| (data received) | | |
| (wait a bit) | (dead air) | |
| | ---- ACK ----> | |
\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/
Что касается UDP, нет встроенной концепции SYN и ACK - UDP по своей природе «ненадежный», а не соединение ориентированы, поэтому понятия не применяются так сильно. Ваше подтверждение обычно будет ответом сервера. Но некоторые протоколы на уровне приложений, построенные поверх UDP, будут иметь определенный протокол для подтверждения отправленных и полученных данных.
-
1+1 хороший ответ и прекрасное искусство ascii. – Byron Whitlock 30 August 2010 в 23:03
-
2ACK может усложниться. Это не для каждого пакета данных, но, как бы многие из них не были получены, может быть один ACK каждые 8 пакетов. Отправляющая сторона имеет window , сколько она будет отправлять, прежде чем должен получить ACK. Тогда есть Селективный ACK, который используется, чтобы сказать «Полученные байты 2000-8000, но не 0-2000». – Zan Lynx 30 August 2010 в 23:22
-
3Вау, спасибо за отличное объяснение! – Daniel T. 31 August 2010 в 00:51
-
4Протокол пользовательских дейтаграмм часто используется в протоколах запроса-ответа, где ответ на запрос будет демонстрировать, что он был получен, а отсутствие повторного запроса продемонстрирует ответчику, что либо его ответ был получен, либо отправитель запроса дал (и ответчику все равно, потому что его правильный ответ в любом случае больше не должен делать ничего). – supercat 30 April 2013 в 23:31
SYN только в начале.
ACK находится на последующих сегментах в любом направлении. [edit] ACK также определит размер окна. Если, например, размер окна равен 100, отправитель может отправить 100 сегментов, прежде чем он ожидает получить ACK. Например, если отправитель отправляет 100 сегментов, но сегмент номер 50 теряется, тогда получатель получит 1-49 & amp; 51 -100. Затем приемник будет ACK на 50 (следующий сегмент, который он ожидает), и установит размер окна на 1. Отправитель отправит 1 сегмент с порядковым номером 50. Приемник затем ACK на 101 и установит размер окна обратно на большее число [edit]
Оба являются фактически полями в заголовке TCP и могут быть отправлены с данными, хотя SYN и первый ACK обычно не имеют данных.
Таким образом, ни один из сценариев, которые вы описываете, верный. Первое на самом деле ближе к реальности, но все пакеты данных после SYN должны включать ACK, а также поле номера подтверждения, которое определяет количество ожидаемого следующего пакета.
Конец сеанса также включает рукопожатия с пакетами, помеченными FIN, и ACK, относящимися к ним.
Обменные порядковые номера используются для идентификации потерянных пакетов и включения механизма повтора, а также чтобы собрать весь поток пакетов в правильном порядке.
Кроме того, если это первый случай, есть ли преимущества UDP через TCP, если вы просто поддерживаете соединение открытым в течение длительного периода времени время?
С помощью UDP вы не можете просто поддерживать соединение открытым в течение длительного периода времени.
Эта последовательность флагов SYN / ACK / FIN - это то, что делает соединение.
С UDP нет SYN или ACK, поэтому связь является односторонней , доставка не гарантируется, и заказ не сохраняется. Но он имеет меньше накладных расходов, поэтому он полезен, когда скорость важнее надежности, например, в потоковых медиа.
Это еще немного упрощено, но это лучшее, что я могу сделать в данный момент.
В записи wikipedia на TCP есть намного больше, и, конечно, в RFC.
-
1Я также рекомендовал бы книгу «TCP / IP Illustrated, том 1 -« Протоколы »). W. Richard Stevens в дополнение к чтению Википедии и RFC. Это немного легче в мозгу :) – Michael J. Gray 20 June 2014 в 06:27
-
2Отправитель отправит 1 сегмент с порядковым номером 50. Приемник будет тогда ACK для 101 , не должен ли он быть . Приемник будет ACK для 51 , поскольку последний полученный сегмент составлял 50? – Rafael Eyng 16 June 2016 в 21:09
-
3Я не понимаю комментария о том, что «общение одностороннее». Это не имеет никакого смысла. UDP - это всего лишь тривиальный, чрезвычайно тонкий слой поверх IP, и поскольку он всего лишь IP с небольшим количеством шоколадного соуса сверху, вы можете отправлять пакеты UDP в направлениях both . – Cecil Ward 19 July 2017 в 05:12
-
4Если разработчик предпочитает использовать UDP, это делается для получения более высокой скорости работы и минимизации количества обменного трафика, или, альтернативно, для полного контроля над методами связи. Используя UDP, дизайнер может при желании построить новый вид протокола с полной свободой выбора. В некоторых приложениях может не требоваться надежная доставка, гарантии доставки по заказу или другие преимущества, предоставляемые такими протоколами, как TCP или SCTP. Тем не менее, дизайнеру, возможно, придется много работать над дизайном при использовании UDP, усложняя код приложения или завершая разработку пользовательского протокола. – Cecil Ward 19 July 2017 в 05:33
Изображение: исходный TCP-стандарт RFC 793 разрешил передачу данных с первым пакетом SYN. Однако сегодня это не так. Вы получаете отдельный SYN-пакет во время инициирования трехстороннего рукопожатия у запрашивающего соединения. Предположим, что A запрашивает соединение с B, таким образом, A отправляет пакет с установленным битом SYN. B отвечает ACK, чтобы подтвердить получение и отправляет A ACK + SYN-пакеты. Затем данные могут передаваться в дальнейшем.
Дордал имеет очень хорошее объяснение по этому вопросу. Нажмите эту ссылку здесь.