TCP/IP работает сверху вниз или снизу вверх?

Question

[123qwe]

Все мы знаем, что такое TCP/IP стек.
Раз вы это читаете, значит вы знаете как он работает в деталях.
Прикладной уровень(http)
Транспортный(tcp/udp)
Сетевой(ip)
ну а с остальным не так важно.
Допустим, что есть какое-то приложение, которое работает по сети.
Нужно отправить Данные из пункта А в пункт Б, а затем из пункта Б в пункт А.
Опишите этот процесс и использованием стека tcp/ip от начала до конца.Использую мою, трех-уровневую модель.

На высочайшем уровне абстракции, должно же быть примерно так:
Мы в пункте A, полетеееели... HTTP => TCP => IP теперь мы в пункте Б, пора обратно HTTP => TCP => IP вот мы и в пункте А.

Далее вопрос
IP отвечает ТОЛЬКО за "разделываение" данных на пакеты, и добавление мета-данных, или еще и как-то участвует в транспортировке?Если участвует, я тогда вообще не понимаю, если же нет - то картина вырисовывается.

Comments

[Saboteur]

TCP и UDP пакеты бегают по IP, то есть маршрутизация и транспортировка - это задача именно IP протокола. А разделывание данных на пакеты и добавление метаданных - задача почти каждого протокола. Например у TCP протокола - проверять валидность пакетов, собирать их в очередь, в случае ошибок - отправлять запрос на повторы пакетов. Естественно для этого он добавляет свои метаданные.

Answer 1

[CityCat4]

Рекомендую Олиферов почитать. Каждый уровень отвечает за свое. Вообще в стандартной модели ISO/OSI их семь, и обычно эту модель используют, когда говорят про уровни. Сетевой - это уровень 3, ни в какой транспортировке он не участвует, что он делает конкретно - читайте Олиферов и RFC. Ниже сетевого - канальный, он отвечает за фреймы Ethernet (если передача по Ethernet), еще ниже - физический - и вот он как раз отвечает за транспортировку. После транспортного идет уровень сеансовый - он практически нигде не используется сейчас, потом уровень представления - здесь работает SSL и потом уже уровень приложения.

Comments

[123qwe]

а я вычитал на вики, что IP как раз таки отвечает за транспортировку.Он изначально был для этого сделан.IP за транспортировку, а UPD/TCP за то, как именно транспортировать.

[CityCat4]

С когда это вики стало заменять RFC? Читайте профессиональную литературу, www.ozon.ru/context/detail/id/34377072 - например. Ну, или https://www.ietf.org/rfc.html - если в языке оригинала сильны.

Answer 2

[none7]

Вся эта модель не более чем условность, нужно её рассматривать, как иерархию структур данных, а вовсе не незыблемые и скрытые друг от друга уровни. В некоторых случаях в направлении отправки пакета может учитываться даже прикладной уровень, а HTTP разбираться непосредственно из Ethernet-кадров. HTTP ничто не мешает содержать Ethernet кадры. NAT определяющий направление отправки по номеру порта TCP и UDP вообще уже стал обыденностью. Прикладных протоколов содержащих IP-адреса и порты, вообще не должно быть в OSI, так как не позволяет абстрагироваться, но их полно. И это вышло боком при появлении IPv6, а с другими протоколами сетевого уровня они вообще несовместимы и на это закрыли глаза. И весь этот бардак нынче зовётся сетевым стеком.
IP конечно содержит механизм фрагментации, но по причине неудачного проектирования используется редко и не для TCP. TCP изначально создан для фрагментации бесконечных потоков данных с проверкой факта доставки, поэтому влезает на сетевой уровень, чтобы знать MTU, а получив некоторые ICMP пакеты даже разрывать соединение(no route, unreachable). Удалённому узлу, TCP тоже сообщает свой MTU.

Answer 3

[Тимур Сергеевич]

ip только указывает какому хосту этот пакет относится не более!

Answer 4

[Станислав Макаров]

1) прикладной уровень (HTTP) использует TCP как сервис (а именно - какое-либо API, предоставляемое ОС, например сокеты Беркли) и выражает желание отправить некоторое количество данных в пункт Б; в теории объем данных может быть любым, т.к. задача именно TCP - разбить данные на куски и прилепить к ним свой заголовок. Полученные куски с заголовками называются TCP-сегментами; в этих заголовках есть все, что необходимо для обеспечения всех гарантий, которые даёт TCP, а именно: а) номер пакета для получения пакетов в порядке их отправления и возможности сборки отправленных данных; б) целостность пакетов и отсутствие в них ошибок; в) номера портов получателя и отправителя (чтобы несколько программ на одной машине могли обмениваться данными); г) флажки для обслуживания TCP-соединения. Вся суть TCP сводится к предоставлению вам, т.е. прикладному уровню, некоего надежного виртуального "провода", которым вы как бы подключили одну программу на одной машине к другой программе на другой машине. В терминах типов коммутации, TCP поверх IP - это коммутация каналов поверх коммутации пакетов.
2) После сборки каждого сегмента TCP использует уровень IP как сервис, и отдает ему сегменты для упаковки в пакеты. Уровень IP нужен для предоставления возможности закинуть (т.е. маршутизировать) любой пакет с текущего узла на любой другой в сети. IP не предоставляет никаких гарантий о порядке прихода пакетов на узел, и даже о том, что они вообще придут (IPv6 также не проверяет целостность пакета), однако с его помощью сетевое оборудование в состоянии выбирать различные (!) пути для доставки пакетов получателю и осуществлять эту доставку. В заголовке IP-пакета, как на письме, указан узел-отправитель и узел-получатель.
После сборки пакета оный отправляется на канальный уровень для доставки по конкретной физической среде.

Теперь представим, если бы этих уровней (TCP/IP) не было. Самое простое, работающее по такой схеме, что приходит на ум - передача данных по COM-порту между двумя машинами. В такой схеме вы, вероятно, получали бы данные в порядке их отправления и возможно даже имели бы контроль ошибок, НО:
а) только одно приложение могло бы передавать/получать данные, т.к. нет виртуальных соединений (нет мультиплексирования);
б) для передачи данных машины нужно соединять физически. Ну или сажать тётеньку, которая бы перетыкала провода, как на первых телефонных станциях с ручной коммутацией каналов.
IP избавляет вас от пункта б), TCP - от пункта а) и тех доп. проблем, которые добавляет IP своим присутствием.