Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Lections (1).doc
Скачиваний:
22
Добавлен:
12.02.2016
Размер:
1.43 Mб
Скачать

Зміни, що відбудуться при переході від iPv4 до iPv6

  1. Збільшення заголовку

  2. Збільшення поля адреса

  3. В IPv6 немає поля довжини заголовку, так як в заголовку відсутні параметри

  4. 2 адреси в IPv6 поміщаються в 64 розрядні границі, якщо заголовок є 64 розрядний.

  5. В заголовку поля IPv6 немає поля фрагментації

  6. Заголовок IPv6 не включає контрольну суму. Виключаючи контрольну суму приходимо до того, що маршрутизатори, які перенаправляють пакети не повинні перераховувати контрольну суму заголовка, після того, як зміняться параметри персилки, що розвантажую маршрутизатори і збільшує перепускну здатність.

  7. В IPv4 відсутня багато адресна передача.

  8. В IPv6 маршрутизатори не форматують пакети.

  9. IPv6 потребує підтримки параметру безпеки і аутентифікації

В багатьох мережах відсутні MTU – максимальний розмір пакета, величина якого диктується апаратними засобами. Найменьша величина MTU між 2–ма вузлами – транспортна MTU (не обов’язково є однакова). Якщо MTU змінюється, то IPv4 і IPv6 використовує фрагментацію.

Фрагменти не з’єднуються заново, поки не досягнуть отримувача. Вузли IPv4 виконують фрагментацію датаграм, які вони генерують, а маркери виконують фрагментацію датаграм, які вони передають.

IPv4 і IPv6 визначають мінімальний розмір буфера – це мінімальний розмір датаграми, який підтримується. IPv6 – 1500, IPv4 – 576 б.

Відправка по TCP

В кожного сокета ТСР є буфер відправки, розмір якого ми можемо змінювати, за допомогою функції SO_SNDBUF.

Коли аплікація викликає функцію write ядро копіює з буфера аплікації у буфер відправки сокета.

Якщо для всіх даних аплікації недостатньо місця в буфері сокета, цей процес припиняється, тобто переходить в стан очікування. В цьому випадку ми говоримо, що ми використовуємо звичайний блокуючий сокет. Ядро повертає управління з функції write тільки після того, як останній байт з буфера аплікації буде переданий в буфер відправки сокета.

Звідси висновок, що повернення з функції write в сокет говорить про те, що ми можемо знову використати буфер аплікації, але ми не знаємо напевно, чи отримав наш співрозмовник або аплікація адресата дані.

ТСР поміщає дані в буфер відправки сокета і відправляє їх.

Співрозмовник ТСР повинен підтвердити дані і тільки коли від нього прийде сегмент АСК, який підтверджує прийом даних, наш ТСР зможе знищити дані з буфера відправки сокета. ТСР повинен зберігати копію даних, доки не буде підтверджено доставку.

Відправка по udp

В даному випадку буфер відправки сокета зображено пунктирними лініями, оскільки він не існує. Розмір буфера відправки пакета UDP – це просто верхня межа розміру дейтаграми UDP, яка може бути записана в сокет. Якщо аплікація записує дейтаграму яка більша розміру буфера відправка сокета, тоді повертається повідомлення про помилку. Оскільки протокол UDP не є надійним. Йому не потрібно зберігати копію даних аплікацій. Йому не потрібно мати справжній буфер відправки. Дані аплікації переважно копіюються в буфер ядра по мірі просування по стеку протоколів, але ця копія скидується канальним рівнем після його передачі.

UDP просто передає свій заголовок і передає протоколу ІР. IPv4, IPv6 добавляє свій заголовок, визначає вихідний інтерфейс виконуючи ф-ції маршрутизації, а потім добавляє дейтаграму в чергу виводу канального рівня – це коли розмір дайтаграми не перевищує буфер. Або фрапл. дейтаграму і добавляє кожний фрагмент в чергу канального рівня.

Якщо аплікація UDP відправляє великі дейтаграми існує набагато більша ймовірність фрагментації ніж у випадку ТСР, Оскільки ТСР розбиває дані аплікації на порції, які дорівнюють розміру MSS, якщо немає сокету в UDP. Успішне завершення ф-ції запису в сокет UPD говорить про те, що або дейтаграма, або фрагменти дейтаграми були доставлені до черги виводу канального рівня.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]