Квитирование соединения TCP
Что я нашел, но если Вы хотите более быструю передачу, инициируют передачу от локального компьютера и копируют в локальный диск.
Т.е. скопируйте \computer1\myshare в c:\files\myshare, не используйте третий компьютер и копию от \computer1\myshare до \computer2\mynewshare.
Механизм квитирования, используемый в TCP, разработан так, чтобы два хоста, пытаясь связаться, могли согласовать параметры сетевого соединения прежде, чем начать коммуникацию. Обе стороны могут предположить, что другой компьютер готов, и начните надежно отправлять данные.
Вот упрощенная схема пакетов, отправляемых с обеих сторон во время квитирования:
SYN ->
SYN received
Host A <- SYN ACK Host B
SYN ACK received
ACK ->
ACK received
TCP connection is established
SYN (синхронизируются), и ACK (подтверждают), что сообщения указаны битом/числом в заголовке TCP сегмента.
Процесс также разработан так, чтобы оба конца могли инициировать и согласовать отдельные соединения одновременно.
Для окончания соединения между двумя компьютерами другая трехсторонняя связь выполняется для разъединения соединения TCP. Инициирование и разрушение соединения TCP являются частью того, что делает TCP надежным протоколом.
См. также: Каково различие между UDP и TCP?
Так, чтобы оба конца могли быть довольно уверены, что другой конец знает, что соединение устанавливается.
Править: Два пути недостаточно, поскольку получатель не может знать, что отправитель знает, что получатель ответил, и соединение готово пойти, и это делает его (соединение двухстороннего квитирования) ненадежный по сравнению с трехсторонним квитированием
-
1
-
2Если бы я имитировал пакет SYN от поддельного адреса, и затем получатель ответил пакетом ACK к тому адресу, если бы это были только два пути квитирование, то получатель пакета SYN думал бы, что установил соединение, когда это hadn' t, потому что имитировавший адрес просто отбросил бы пакет ACK. Трехэтапное квитирование избегает этого. – Dentrasi 5 July 2009 в 11:48
-
3
Поймите, что это - действительно четырехстороннее квитирование (два в каждом направлении). Существует SYN-> ACK и и SYN <-ACK. Хост-B просто экономит время путем отправки его SYN одновременно он Хоста ACK.
Кроме того, Dentrasi имел комментарий, что трехстороннее квитирование предотвращает спуфинг, но это не совсем верно.
Посмотрите больше информации на nmap сайте: http://nmap.org/book/osdetect-usage.html
"Системы Прогноза Последовательности TCP с плохим поколением порядкового номера начальной буквы TCP уязвимы для ослепления нападений спуфинга TCP. Другими словами, можно установить полную связь с теми системами и отправить (но не получить), данные при спуфинге другого IP-адреса. Журналы цели покажут имитировавший IP, и можно использовать в своих интересах любые доверительные отношения между ними. Это нападение было всем гневом в середине девяностых когда люди наиболее часто используемый rlogin для разрешения логинов их учетной записи без любого пароля от доверяемых IP-адресов. Kevin Mitnick, как предполагается, использовал это нападение для вторжения в компьютеры Tsutomu Shimomura в декабре 1994".
Дополнительная информация о TCP упорядочивает нападения прогноза здесь: http://en.wikipedia.org/wiki/TCP_sequence_prediction_attack
Нетехническое объяснение - 3 пути квитирование требуются для полнодуплексного разговора/соединения. Соединение означает соглашение между двумя сторонами. Средства соглашения, когда X отправляют затем Y, получают и когда Y отправляют X, получают. Каждое это одностороннее соглашение требует двух шагов каждый, попросите разрешение (SYN), и знать другой будет послушать/получать/брать (ACK), что Вы отправляете. Так два шага SYN-ACK.
Это по существу - четырехстороннее квитирование, неродные 2 (передающий ACK к X Y) и неродной 3 (отправляющий SYN в X Y) объединяются (неродной 3, осуществил контрейлерные перевозки на неродной 2), в конце, заканчивающемся за один шаг. Это возможно, так как оба, отправляют одновременно от Y (тот же хост), и информация содержится в немного в заголовке TCP (никакие проблемы больше обычного размера). Таким образом на общих 3 шагах от 4 шагов.
техническое объяснение - TCP является протоколом состояний, путь его конечный автомат работает и изменяется, его состояния симметрично в обоих концы. Установленное состояние достигнуто при получении ACK из другой машины. Для обоих объекты для достижения соединения установленное состояние машины состояний должны получить ACK. Таким образом, получение ACK важно, и получить ACK, который хост должен отправить SYN. Хорошо снова процесс с 4 шагами, объединенный в 3 шага, посмотрите заключенное в кавычки объяснение.
Отдых является деталями - как выбор случайного значения SYN, так, чтобы нападения прогнозов могли быть предотвращены. Что касается нападения, Man-in-the-middle неизбежен. PS поместил комментарий, если кто-либо хочет знать как. Я думаю, что большинство из Вас знало бы как, его очень очевидное, таким образом, я сохраняющий Вас время считывания.
Трехэтапное квитирование устанавливает соединение. Точно так же, как, когда Вы берете свой телефон, получите тональный сигнал готовности к набору номера, наберите номер, услышьте вызов, и затем другая сторона заявляет "привет".
Была попытка давно для сокращения количества "административных" пакетов, требуемых настраивать и разъединять недолгое соединение TCP. Это назвали "TCP для Транзакций" или "T/TCP" и описывают в RFC1644:
http://www.faqs.org/rfcs/rfc1644.html
TCP был первоначально разработан для обеспечения виртуального канала для долговечных соединений, где установка и рвется, время простоя не было так же важно. Поскольку клиент-серверная модель стала более распространенной, потребность в чем-то как T/TCP стала более очевидной.
T/TCP использует некоторые механизмы кэширования сервера, чтобы позволить первому пакету нового соединения содержать данные. Запрос разрушения от стороны сервера может также осуществить контрейлерные перевозки на последнем пакете данных. Это сокращает количество пакетов, требуемых для fto сообщения единственной полезной нагрузки пакета три.
К сожалению, T/TCP никогда не достигал критической массы.