Чи правда, що TCP є коротким для TCP / IP, і вони означають те саме?
Чи можливо побудувати TCP поверх іншого протоколу, крім IP ?
Чи правда, що TCP є коротким для TCP / IP, і вони означають те саме?
Чи можливо побудувати TCP поверх іншого протоколу, крім IP ?
Відповіді:
TCP і IP (v4 & v6), безумовно, відокремлюються, і одне не означає іншого, як доведено на прикладі TCP над IPX ( RFC 1791 ).
Однак TCP не може бути побудований на будь- якому мережевому протоколі. Дві причини:
Специфікація TCP, RFC 793 , не є гарним джерелом для вирішення цього питання, оскільки вона визнає, що він залишає свій інтерфейс із нижчим шаром значною мірою не визначеним.
Примітка a) Щоб TCP збирав дейтаграми, надруковані на маленьких аркушах паперу (чи перевозяться вони голубами чи більш розумною мережевою мережею), розмір корисного навантаження повинен бути записаний у стандартному місці. Крім того, шар адаптації може евристично визначати розмір сегмента. Оптичний сканер, що використовується при реалізації хостового стека специфікації пташиних носіїв ( RFC 1149 ), включав такий евристичний адаптаційний шар, але він залишається недокументованим.
Я не прочитав весь RFC, але мова в розділі 1.4, начебто, говорить про те, що можна використовувати будь-який протокол "нижчого рівня".
Інтерфейс між протоколом TCP та протоколом нижчого рівня по суті не визначений, за винятком того, що передбачається, що існує механізм, за допомогою якого два рівні можуть асинхронно передавати інформацію один одному. Як правило, очікується, що протокол нижчого рівня задасть цей інтерфейс. TCP призначений для роботи в дуже загальному середовищі взаємопов'язаних мереж. Протокол нижчого рівня, який передбачається в цьому документі, є Інтернет-протоколом.
TCP не є коротким для TCP / IP.
TCP / IP часто використовується як скорочений вислів " Internet Protocol Suite " і зазвичай включає інші стандартні протоколи. Коли люди кажуть TCP / IP, вони, як правило, включають UDP через IP (у якому UDP використовується замість TCP) та безліч інших протоколів, таких як ARP, ICMP, DNS, SNMP та інші протоколи додаткового рівня.
Програми використовують протоколи додаткового шару, такі як SMTP (для електронної пошти). Вони сидять на одному з двох протоколів транспортного рівня - TCP та UDP. Кілька протоколів рівня додатків будуть використовувати один або обидва UDP та TCP, але більшість використовуються лише з одним протоколом транспортного рівня.
TCP і UDP - це два протоколи транспортного рівня, що використовуються в пакеті Internet Protocol Suite. Якщо є інші, я не знаю про них, а будь-який інший би представляв зникаюче невелике використання спеціаліста. Були визначені інші протоколи транспортного рівня - їх використання, ймовірно, становить лише невелику частку глобального IP-трафіку †
Хоча теоретично можливо використовувати TCP через щось інше, ніж IP, на практиці TCP завжди використовується через IP - Інтернет-протокол. IP переміщує пакети між мережами (уявляйте IP як з'єднання декількох локальних мереж разом)
Ethernet - це лише найпопулярніше сімейство протоколів низькорівневого каналу зв’язкового рівня, на яких переносяться TCP / IP, але TCP / IP також широко використовується для ATM та інших.
Єдиними протоколами транспортного рівня, які значно використовуються в мережах, що використовують пакет Internet Protocol Suite, є TCP та UDP.
† Просто заради задоволення, я виміряв трафік на своїй (дуже) невеликій локальній мережі, яка включає NetBIOS (через TCP), SSH, Rsync, електронну пошту, оновлення програмного забезпечення, DNS, загальний чат Windows-box та кілька інших типів трафіку.
Зверніть увагу також на це твердження у поширених запитаннях Google щодо їх протоколу QUIC
Чому ви не створили цілком новий протокол, а не використовували UDP? Середні вікна в Інтернеті сьогодні, як правило, блокують трафік, якщо це не трафік TCP або UDP
(мій акцент)
Причина, по якій TCP / IP є такою поширеною абревіатурою (на відміну від, скажімо, UDP / IP або SCTP / IP), полягає в тому, що два протоколи були розроблені разом, а в оригінальному документі Vint Cerf та Bob Kahn дві концепції були об'єднані разом в єдиний протокол. Незабаром після цього вони були розділені на IP для забезпечення маршрутизації та TCP для забезпечення потоку, мультиплексування, виявлення помилок тощо. Лише через шість років UDP було введено, щоб забезпечити "легкий" шар мультиплексування без решти накладні витрати, пов'язані з TCP.
Тим не менш, TCP і IP - це дві окремі речі і повністю і навмисно незалежні. Те, що TCP не вимагає IP, відразу видно з того, що TCP може працювати немодифікованим як на IPv4, так і на IPv6, що є двома абсолютно різними протоколами.
Трохи працюючи, ви могли б створити конкуруючий протокол до IP, який би слугував однаковим цілям, але він, мабуть, повинен містити більшість, якщо не всі однакові функції, і, ймовірно, в будь-якому випадку виглядає так, як IP. Ви можете стверджувати, що розширення до IP (наприклад, IPSec) - це фактично альтернативні протоколи 3 рівня, тому ви йдете.
TCP і IP - як масло над хлібом.
Ви можете з'єднати що - небудь ще , що працює з будь-яким протоколом, але ці два настільки доповнюють один одного , це просто смакота надійний спосіб для передачі даних і заповнити животик з інтернет - даними. Він змащує трубку, щоб дозволити іншим сухим харчовим продуктам та передачі даних однаковою мірою підтримувати це сполучення. Але це ні в якому разі не є ексклюзивним.
Q Однак, чи не можливо TCP бути побудований поверх іншого протоколу, крім IP?
A Так це можливо. Мені подобаються Morse Code та Pigeon приклади TCP без IP.
Я завжди чув, що TCP є коротким для TCP / IP
Насправді він розшифровується як протокол контролю передачі через Інтернет-протокол
і вони означають те саме.
Це не правильно.
По-перше, Ethernet - це апаратна система низького рівня, яка контролює функціонування фактичних апаратних деталей.
Далі, подумайте про IP як телефонну систему або дорожні знаки. Він забезпечує основне управління з'єднанням двох точок разом.
З іншого боку, TCP більше схожий на систему обміну повідомленнями або службовця з управління трафіком, який спрямовує повідомлення / машини до правильної точки.
TCP / IP у сукупності забезпечує систему надійної передачі даних до будь-яких двох підключених пристроїв.
В Інтернеті, коли ви хочете надсилати або отримувати дані, IP-частина системи - це та частина, яка контролює встановлення фактичних апаратних з'єднань з проводами (або бездротовими хвилями). Частина системи TCP - це програмне забезпечення, яке відповідає за взяття даних та їх розбиття, надсилання, повторний монтаж отриманих даних, перевірку даних та повторне надсилання при необхідності.
Існує незліченна кількість пояснень з аналогіями та технічними деталями, особливо у відео-формі . Особливо добре в цій темі є DifferenceBetween.net .
Однак чи не можливо TCP бути побудований поверх іншого протоколу, крім IP?
Так, ви дійсно можете створити альтернативну систему для TCP, яка використовує IP. Погляньте на Інтернет-протокол Suite для отримання детальної інформації.
> the fact that !TCP can go over IP does not necessarily mean TCP can go over !IP Huh?
psusi намагається бути розумним, використовуючи "!" як "не оператор". Його коментар слід читати як: "той факт, що те, що не є TCP, може переходити через IP, не обов'язково означає, що TCP може переходити через щось, що не є IP". Це зроблено з посиланням на останнє речення вашої відповіді, яке показало існування "альтернативних систем TCP". Однак показ, що існують альтернативи TCP, не обов'язково означає і не натякає на те, що альтернативи IP є.
TCP - протокол рівня 4. Він забезпечує гарантовану транспортування даних у вигляді впорядкованого потоку з одного процесу на комп'ютер до іншого процесу на тому ж / іншому комп'ютері.
IP - протокол 3 рівня. Він забезпечує транспортування від одного господаря до іншого.
Поки існує протокол, який може робити хост для передачі даних, TCP буде працювати.
Отже, TCP може бути реалізований через будь-який протокол, але, ми лише зробили IP. IP простий і робить свою роботу.
Немає необхідності в іншому протоколі 3 рівня.
Розробляючи мережу, ви повинні вибрати набір протоколів (які в основному є наборами правил зв'язку між машинами) для кожного з різних "шарів" (які ви можете уявити як різні рівні абстракції, які дизайнери мережі люблять майте на увазі під час створення та комбінування протоколів).
Простіша версія: протоколи - це як вікна, в які ми поміщаємо свої повідомлення . Ці скриньки мають різний розмір, і ви поміщаєте своє повідомлення в найменший ящик, потім найменший у вікні, який трохи більший і т. Д. Вибираючи набір протоколів, вибираєте, які коробки ви будете використовувати для кожного " шар ", який оточує ваше повідомлення.
TCP і IP - це протоколи для двох незалежних шарів, які були створені разом і використовувались разом; але дуже добре може використовуватися з іншими протоколами. Це трапляється досить часто: ви можете використовувати IP разом з протоколом, який не є TCP, або TCP разом з протоколом, який не стосується IP .
Причина, по якій TCP / IP є такою поширеною абревіатурою, полягає в тому, що ці два протоколи, що утворюються разом, є основою Інтернету і були ключовими для його успіху .
(TCP та IP мають деякі функції, які були розроблені спеціально для того, щоб вони працювали разом, на що часто скаржаться пуристи, але вони насправді не заважають вам взаємодіяти з іншими протоколами)
Я думаю, що можна запустити TCP через транспорт IPX, якщо ви хочете пройти ретро.
Однак чи не можливо TCP бути побудований поверх іншого протоколу, крім IP?
Крім класичних TCP / IPv4 та TCP / IPv6, було розроблено кілька експериментальних протоколів, наприклад:
В рамках наших зусиль Net100 та Probe щодо вдосконалення об'ємних передач через швидкісні та високі затримки в мережі, ми розробили інструментальну та настроювану версію TCP, що працює над UDP. TCP-подібний транспорт UDP служить тестовим джгутом для експериментів з TCP-подібними елементами управління на рівні програми, аналогічному TReno.
І iproxy: Запуск TCP-послуг через UDP , що цікавіше:
iproxy складається з проксі-клієнта та проксі-сервера на стороні сервера, що дозволяє довільним послугам TCP / IP переходити через широкомовні UDP-програми Broadcast, Multicast або Unicast. Спочатку він був задуманий як спосіб налаштування серверів, яким не було надано IP-адресу в локальній мережі за допомогою веб-інтерфейсу.
Отже, ви бачите: TCP в одноадресному UDP, і навіть TCP в широкомовному або багатоканальному UDP !
AFAIK тільки TCP / IPv4 і TCP / IPv6 користуються великим розміщенням.
Відповідь - ні! Наприклад, є старий RFC, що описує TCP через IPX: http://tools.ietf.org/html/rfc1791
Для тих, хто має короткі спогади, IPX був протоколом Novell Netware: http://en.wikipedia.org/wiki/Internetwork_Packet_Exchange
Впровадження TCP поверх різних протоколів, які підтримують транспортування базової дейтаграми, вже існує. Насправді, навіть не потрібно вказувати інформацію про маршрутизацію (TCP навіть не потребує IP для роботи, достатньо буде лише каналу serila з неявним одержувачем).
Отже, у вас реалізовано TCP поверх UDP (перевага: ви використовуєте один порт на стороні "сервера" або можете вбудовувати його через існуюче з'єднання, що транспортує різні мультиплексовані канали). Лише рівень IP забезпечує маршрутизацію, але TCP не потрібен. Важливо лише те, що концепція MTU забезпечується нижчим рівнем.
Це дозволяє протоколі обходити обмеження NAT-траверсації, не вимагаючи реєстрації порту перекладу UPnP для конкретного хоста. Це дозволяє незалежну настройку MTU та MSS, оптимізованих для кожного клієнта замість кожного проміжного спільного маршрутизатора. Можливі й інші протоколи маршрутизації (в тому числі для доставки через мережеві трансляції та широкомовні мережі). І у вас є вибір механізмів безпеки.
Приклад використання - Gogo6.net (який реалізує свій транспортний канал IPv6 через сеанс TCP, використовуючи повторне здійснення TCP через UDP v4 (він працює на більшості домашніх маршрутизаторів доступу, які все ще мають лише адресу IPv4, і не завжди підтримує метод UPnP ; без потреби налаштовувати його користувачами, використовуючи постійний номер порту, специфічний для програми, навіть коли він не працює)
Іншими прикладами є інкапсуляція TCP через HTTP (або HTTPS) версії 1.1 з нативним його "потоковим" розширенням. Більшість VPN, які дозволяють з’єднувати мережі через Інтернет, будуть робити те саме. Міст може навіть інкапсулювати декілька протоколів: Ethernet, PPP, IPv4 та IPv6 (розширюючи лише локальний сегмент локальної мережі або Ethernet), NetBEUI / LanMan, виявлення маршрутизатора (в мостовій мережі), в тому числі в режимі "необроблений" (що дозволяє DHCPv4 або DHCPv6) у мостова мережа. HTTPS використовується тому, що інкапсуляція через HTTPS дозволяє також шифрувати та автентифікувати для встановлення та забезпечення мосту, але не вимагає кінцевої аутентифікації / шифрування для клієнтів та серверів через мостикову мережу, а також тому, що маршрутизатори дуже оптимізовані для HTTP і HTTPS.
Є приклади систем зв’язку в армії, що використовують TCP, але не IP, оскільки комунікаційний шлях - це з'єднання послідовного типу, яке не отримує маршрутизацію через маршрутизатори тощо. Якщо ви подивитеся на пакет TCP, перш ніж він перейде з поля IP, це не можна використовувати IP, якщо ваш протокол "маршрутизації" відрізняється.