https://wiki.cusu.edu.ua/api.php?action=feedcontributions&feedformat=atom&user=Hiss 2026-04-08T10:40:38Z Внесок користувача MediaWiki 1.23.2 https://wiki.cusu.edu.ua/index.php/%D0%9E%D0%B1%D0%B3%D0%BE%D0%B2%D0%BE%D1%80%D0%B5%D0%BD%D0%BD%D1%8F:%D0%9F%D1%80%D0%BE%D1%82%D0%BE%D0%BA%D0%BE%D0%BB_%D0%86%D0%A0v6 2008-12-24T10:03:17Z

<p>Hiss: </p> <hr /> <div>а мона хотяб одну якусь картинку втулить?<br /> <br /> --[[User:Bokiss-8|Bokiss-8]] 11:35, 24 декабря 2008 (EET)<br /> <br /> == Для тих, хто не читав всієї роботи: ==<br /> <br /> перед тим, як читати цю статтю бажано ознайомитись із статтею по IP... Матеріал буде легше сприйматись<br /> <br /> == для тих хто робив цю роботу: ==<br /> <br /> треба більше зрозумілих картинок цікавих чудових різних всяких!<br /> <br /> --[[User:Bokiss-8|Bokiss-8]] 12:01, 24 декабря 2008 (EET)<br /> <br /> <br /> Це вам не дитяча книжка, а все ж робота, яка претендує на звання майже наукової<br /> <br /> --[[User:Hiss|Hiss]] 12:03, 24 декабря 2008 (EET)</div>

Hiss https://wiki.cusu.edu.ua/index.php/%D0%9E%D0%B1%D0%B3%D0%BE%D0%B2%D0%BE%D1%80%D0%B5%D0%BD%D0%BD%D1%8F:%D0%9F%D1%80%D0%BE%D1%82%D0%BE%D0%BA%D0%BE%D0%BB_%D0%86%D0%A0v6 2008-12-24T10:03:03Z

<p>Hiss: </p> <hr /> <div>а мона хотяб одну якусь картинку втулить?<br /> <br /> --[[User:Bokiss-8|Bokiss-8]] 11:35, 24 декабря 2008 (EET)<br /> <br /> == Для тих, хто не читав всієї роботи: ==<br /> <br /> перед тим, як читати цю статтю бажано ознайомитись із статтею по IP... Матеріал буде легше сприйматись<br /> <br /> == для тих хто робив цю роботу: ==<br /> <br /> треба більше зрозумілих картинок цікавих чудових різних всяких!<br /> <br /> --[[User:Bokiss-8|Bokiss-8]] 12:01, 24 декабря 2008 (EET)<br /> <br /> Це вам не дитяча книжка, а все ж робота, яка претендує на звання майже наукової<br /> <br /> --[[User:Hiss|Hiss]] 12:03, 24 декабря 2008 (EET)</div>

Hiss https://wiki.cusu.edu.ua/index.php/%D0%9E%D0%B1%D0%B3%D0%BE%D0%B2%D0%BE%D1%80%D0%B5%D0%BD%D0%BD%D1%8F:%D0%9F%D1%80%D0%BE%D1%82%D0%BE%D0%BA%D0%BE%D0%BB_%D0%86%D0%A0v6 2008-12-24T10:01:40Z

<p>Hiss: Для тих, хто не читав всієї роботи:</p> <hr /> <div>а мона хотяб одну якусь картинку втулить?<br /> <br /> --[[User:Bokiss-8|Bokiss-8]] 11:35, 24 декабря 2008 (EET)<br /> <br /> == Для тих, хто не читав всієї роботи: ==<br /> <br /> перед тим, як читати цю статтю бажано ознайомитись із статтею по IP... Матеріал буде легше сприйматись</div>

Hiss https://wiki.cusu.edu.ua/index.php/%D0%9C%D0%B0%D1%81%D0%BA%D0%B0_%D0%BF%D1%96%D0%B4%D0%BC%D0%B5%D1%80%D0%B5%D0%B6%D1%96 2008-12-24T09:57:44Z

<p>Hiss: </p> <hr /> <div>Якщо маршрутизатори у мережі Internet використовують тільки мережний префікс адреси отримувача для передачі трафіка у організацію, то марщрутизатори всередині приватної мережі організації розширений мережний префікс для передачі трафіка індивідуальним підмережам. Розширеним мережним префіксом називають префікс мережі і номер підмережі.<br /> <br /> &lt;center&gt;[[Image:1 425.gif]]&lt;/center&gt;<br /> <br /> &lt;center&gt; Мал.3 Розширений мережний префікс.&lt;/center&gt;<br /> <br /> Поняття розширеного мережного префікса, по суті, еквівалентно поняттю маска підмережі (subnet mask). Маска підмережі - це двійкове число, яке містить одиниці у тих розрядах, які відносяться до розширеного мережного префікса. Маска підмережі дозволяє поділити ІР-адресу на дві частини: номер підмережі та номер пристрою у цій підмережі.<br /> <br /> Старші біти ІР-адреси використовуються робочими станціями і маршрутизаторами для визначення класу адреси. Після того, як клас визначений, пристрій може легко визначити межу між бітами, які використовувалися для ідентифікації номера мережі, і бітами номера пристрою у цій мережі. Однак для визначення межі бітів, які ідентифікують номер підмережі, така схема не підходить. Для цього саме і використовується 32-бітна маска підмережі, яка допомогає однозначно визначити необхідну межу.<br /> <br /> Біти у масці підмережі повинні бути усталені в одиницю, якщо система, яка перевіряє адресу, повинна розглядати відповідний біт у ІР-адресі як частину мережного префікса. Після визначення класу ІР-адреси, будь-який біт у номері пристрою, який має відповідний усталений біт у масці підмережі, використовується для ідентифікації номера підмережі. Частина номера пристрою, що залишилася, і якій відповідають нульові біти у масці підмережі, використовуються для задання номера пристрою. <br /> <br /> Документ RFC 1219 визначає основне правило, якому слід дотримуватися при привласнюванні номерів підмережам і пристроям. Номери підмереж призначаються таким чином, щоб старші біти у номері підмережі встановлювалися першими (тобто починаючи з крайньої лівої позиції). В той же час одиничні біти номериівпристроїв рекомендується встановлювати, починаючи з крайньої правої позиції. Отже, якщо дотримуватися цього правила, то на межі між номером підмережі і номером пристрою будуть існувати нульові невикористані біти. Це дозволяє змінити маску підмережі без зміни ІР-адреси, привласненої пристрою.<br /> <br /> У мережі із підмережами можна використовувати два види широкомовлення: направлене і обмежене. Направлене широкомовлення використовується для передавання дейтаграми всім пристроям визначеної підмережі. Для відправки дейтаграми всім пристроям у всіх підмережах необхідно використати обмежене широкомовлення із адресою 255.255.255.255. Необхідно, однак, врахувати, що маршрутизатори не пропускають дейтаграми з такою адресою (тому таке широкомовлення називається обмеженим).<br /> <br /> Номери мереж призначаються централізовано, якщо мережа є частиною Internet, або довільно, якщо мережа працює автономно. Номери вузлів і в тому і в іншому випадку адміністратор може призначати самостійно, не виходячи з дозволеного для цього класу мережі діапазону.<br /> <br /> Координуючу роль у централізованому розподілі ІР-адрес спочатку відігравала організація InterNIC, однак із зростанням мережі задача розподілу адрес стала дуже складною, і InterNIC делегувала частину своїх функцій іншим організаціям і крупним поставщикам послуг Internet.<br /> <br /> Якщо деяка ІР-мережа створена для роботи у &quot;автономному режимі&quot;, без зв'язку з Internet, в стандартах Internet визначено декілька діапазонів адрес, рекомендуємих для локального використання. Ці адреси не обробляються маршрутизаторами Internet ні за яких умов. Адреси, зарезервовані для локальних цілей, вибрані з різних класів: у класі А - це мережа 10.0.0.0, у класі В - це діапазон з 16 номерів мереж 172.16.0.0. - 172.31.0.0, у класі С - це діапазон з 255 мереж - 192.168.0.0. - 192.168.255.0.<br /> <br /> <br /> <br /> [[TCP/IP]]<br /> [[category:Комп'ютерні мережі]]</div>

Hiss https://wiki.cusu.edu.ua/index.php/%D0%9F%D1%96%D0%B4%D0%BC%D0%B5%D1%80%D0%B5%D0%B6%D1%96 2008-12-24T09:57:23Z

<p>Hiss: </p> <hr /> <div>Як відомо, ІР-адреса складається з двох їєрархічних рівнів. Необхідність у введенні третього рівня їєрархії - рівня підмереж - була зумовлена виникненням дефіциту номерів мереж і стрімким зростанням таблиць маршрутизації маршрутизаторів у Internet. Після впровадження рівня підмережі номер пристрою поділяється на дві частини - номер підмережі та номер пристрою у цій підмережі.<br /> <br /> &lt;center&gt;[[Image:1 424.gif]]&lt;/center&gt;<br /> <br /> &lt;center&gt; Мал.2 Формування трьохрівневої ієрархії.&lt;/center&gt;<br /> <br /> Збільшення кількості рівнів знімає проблему зростання таблиць маршрутизації завдяки тому, що інформація про топологію корпоративних мереж стає непотрібною магістральним маршрутизаторам Internet. Маршрути з мережі Internet до будь-якої конкретної підмережі, розташованої у мережі із заданою ІР-адресою, однакові і не залежать від того, у якій підмережі розташований отримувач. Це стало можливим завдяки тому, що всі підмережі мережі із заданим номером використовують один і той самий мережний префікс, хоч їх номери (номери підмереж) різні. Маршрутизаторам у приватній мережі потрібно відрізняти окремі підмережі, але для маршрутизаторів Internet всі підмережі відносяться до єдиного запису у таблиці маршрутизації. Це дозволяє адміністратору приватної мережі вносити будь-які зміни у логічну структуру всієї мережі, не впливаючи на розмір таблиць маршрутизації маршрутизаторів Internet.<br /> <br /> Крім того, легко розв'язується проблема виділення номерів при рості організації. Організація отримує номер мережі, а далі адміністратор довільно привласнює номери підмереж для кожної внутрішньої мережі. Це дозволяє організації розширювати свою мережу без необхідності отримання ще одного мережного номера.<br /> <br /> <br /> <br /> [[TCP/IP]]<br /> [[category:Комп'ютерні мережі]]</div>

Hiss https://wiki.cusu.edu.ua/index.php/%D0%92%D0%B8%D0%BA%D0%BE%D1%80%D0%B8%D1%81%D1%82%D0%B0%D0%BD%D0%BD%D1%8F_%D0%BC%D0%B0%D1%81%D0%BE%D0%BA_%D1%83_%D0%86%D0%A0-%D0%B0%D0%B4%D1%80%D0%B5%D1%81%D0%B0%D1%86%D1%96%D1%97 2008-12-24T09:56:57Z

<p>Hiss: </p> <hr /> <div>Традиційна схема поділу ІР-адреси на номер мережі і номер вузла базується на понятті класу, який визначається значеннями кількох перших біт адреси. Саме тому, що перший байт адреси 185.23.44.206 попадає у діапазон 128-191, ми можемо сказати, що ця адреса відноситься до класу В, а значить, номером мережі є перші два байти, доповнені двома нульовими байтами - 185.23.0.0, а номером вузла - 0.0.44.206.<br /> <br /> Для гнучкого встановлення межі між номером мережі і номером вузла використовують маску, Маска - це число, яке використовується у парі з ІР-адресою; двійковий запис маски містить одиниці у тих розрядах, які повинні у ІР-адресі інтерпретуватися як номер мережі. Поскільки номер мережі є цілою частиною адреси, одиниці у масці також повинні бути безперервною послідовністю. Для стандартних класів мереж маски мають такі значення:<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;клас А - 11111111.00000000.00000000.00000000 (255.0.0.0); &lt;/li&gt;<br /> &lt;li&gt;клас В - 11111111.11111111.00000000.00000000 (255.255.0.0);&lt;/li&gt; <br /> &lt;li&gt;клас С - 11111111.11111111.11111111.00000000 (255.255.255.0).&lt;/li&gt;<br /> &lt;/ul&gt;<br /> <br /> ____________________________________________________________________________________________________<br /> <br /> Примітка. Для запису масок використовують і інші формати, наприклад, зручно інтерпретувати значення маски, записаної у шістнадцятьковому коді: FF.FF.00.00 - маска для адрес класу В. Часто зустрічається і таке позначення 185.23.44.206/16 - цей запис означає, що маска адреси для цієї адреси містить 16 одиниць або що у вказаній адресі під номер адреси мережі відведено 16 двійкових розрядів.<br /> <br /> <br /> <br /> [[TCP/IP]]<br /> [[category:Комп'ютерні мережі]]</div>

Hiss https://wiki.cusu.edu.ua/index.php/%D0%9E%D1%81%D0%BE%D0%B1%D0%BB%D0%B8%D0%B2%D1%96_%D0%86%D0%A0-%D0%B0%D0%B4%D1%80%D0%B5%D1%81%D0%B8 2008-12-24T09:56:39Z

<p>Hiss: </p> <hr /> <div>У протоколі ІР існує декілька домовленостей про особливу інтерпретацію ІР-адрес. <br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;Якщо вся ІР-адреса складається тільки з двійкових нулів, то вона означає адресу того вузла, який згенерував цей пакет; цей режим використовується тільки у деяких повідомленнях ІСМР. &lt;/li&gt;<br /> &lt;li&gt;Якщо в полі адреси мережі стоять тільки нулі, по домовленості вважається, що вузол призначення належить тій самій мережі, що і вузол , який відправив пакет. &lt;/li&gt;<br /> &lt;li&gt;Якщо всі двійкові розряди ІР-адреси дорівнюють 1, то пакет з такою адресою призначення повинен розсилатися всім вузлам, які знаходяться у тій самій мережі, що і відправник цього пакета. Така розсилка називається обмеженим широкомовним повідомленням (limited broadcast).&lt;/li&gt; <br /> &lt;li&gt;Якщо в полі номера вузла призначення стоять тільки одиниці, то пакет, який має таку адресу, розсилається всім вузлам мережі із заданим номером мережі. Наприклад, пакет з адресою 192.190.21.255 доставляється всім вузлам мережі 192.190.21.0. Таке розсилання називається широкомовним повідомленням (broadcast). &lt;/li&gt;<br /> &lt;/ul&gt;<br /> <br /> Особливий зміст має ІР-адреса, перший октет якої дорівнює 127. Вона використовується для тестування програм і взаємодії процесів у межах однієї машини. Коли програма посилає дані за адресою 127.0.0.1, то утворюється як би &quot;петля&quot;. Дані не передаються по мережі, а повертаються модулям верхнього рівня як тільки но прийняті. Тому в ІР-мережі забороняється привласнювати машинам ІР-адреси, які починаються із 127. Ця адреса має назву loopback.<br /> <br /> У протоколі ІР немає поняття широкомовності у тому понятті, в якому воно використовується у протоколах канального рівня локальних мереж, коли дані повинні бути доставлені абсолютно всім вузлам. Як обмежена широкомовна ІР-адреса, так і широкомовна ІР-адреса мають межі розповсюдження у інтермережі - вони обмежені або мережею, до якої належить вузол-джерело пакета, або мережею, номер якої вказаний у адресі призначення. Тому поділ мережі за допомогою маршрутизаторів на частини локалізує широкомовний шторм межами однієї з частин, що складають загальну мережу просто тому, що немає способа адресувати пакет одночасно всім вузлам всіх мереж складеної мережі.<br /> <br /> Форма групової адреси - multicast - означає, що даний пакет повинен бути доставлений відразу декільком вузлам, які утворюють групу з номером, вказаним у полі адреси. Вузли самі ідентифікують себе, тобто визначають, до якої з груп вони відносяться. Один і той самий вузол може входити до декількох груп. Члени будь-якої групи multicast не обов'язково повинні належати одній мережі. Групова адреса не поділяється на поля номера мережі і вузла і обробляється маршрутизатором особливим чином.<br /> <br /> Основне призначення multicast-адрес - розповсюдження інформації за схемою &quot;один-до-багатьох&quot;. Хост, який хоче передавати одну й ту саму інформацію багатьом абонентам, за допомогою спеціального протокола IGMP (Internet Group Management Protocol) повідомляє про створення в мережі нової мультімовної групи із визначеною адресою. Маршрутизатори, які підтримують мультімовність, розповсюджують інформацію про створення нової групи у мережах, підключених до портів цього маршрутизатора. Хости, які хотять під'єднатися до знов створюваної мультімовної групи, повідомляють про це своїм локальним маршрутизаторам і ті передають цю інформацію хосту, ініціатору створення нової групи.<br /> <br /> Щоб маршрутизатори мали можливість автоматично розповсюджувати пакети з адресою multicast по складній мережі, необхідно використовувати у кінцевих маршрутизаторах модифіковані протоколи обміну маршрутною інформацією, такі як, наприклад, MOSPF (Multicast OSPF, аналог OSPF).<br /> Групова адресація призначена для економічного розповсюдження у Internet або у великій корпоративній мережі аудіо- чи відеопрограм, призначених одразу великій аудиторії слухачів або глядачів. Якщо такі засоби знайдуть широке застосування, то Internet зможе створити серйозну конкурецію радіо і телебаченню.<br /> <br /> <br /> <br /> [[TCP/IP]]<br /> [[category:Комп'ютерні мережі]]</div>

Hiss https://wiki.cusu.edu.ua/index.php/%D0%90%D0%B4%D1%80%D0%B5%D1%81%D0%B0%D1%86%D1%96%D1%8F_%D1%83_%D0%86%D0%A0-%D0%BC%D0%B5%D1%80%D0%B5%D0%B6%D0%B0%D1%85 2008-12-24T09:56:16Z

<p>Hiss: </p> <hr /> <div>Міжмережна схема адресації, що застосовується у протоколі ІР, описана у документах RFC 990 i RFC 997. В її основі покладено принцип відокремлення адресації мереж від адресації пристроїв у цих мережах. Така схема полегшує маршрутизацію. При цьому адреси повинні призначатися упорядковано (послідовно), для того, щоб зробити маршрутизацію більш ефективною.<br /> <br /> При застосуванні у мережі стеку протоколів ТСР/ІР порти кінцевих пристроїв отримують унікальні адреси, тобто адресується не сам пристрій у мережі, а визначене з'єднання цього пристрою з мережею. Ця схема приводить до низки неподобств. Одним з них є необхідність заміни адреси пристрою при переміщенні його у іншу мережу. Другий недолік в тім, що для роботи з пристроєм, який має декілька підключень у розподіленій мережі, необхідно знати всі його адреси, які ідентифікують ці підключення. <br /> <br /> Отже для кожного пристрою у мережах ІР можна говорити про адреси трьох рівнів:<br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;Фізична адреса пристрою (точніше - визначеного інтерфейсу). Для пристроїв у мережах Ethernet - це МАС-адреса мережної карти або порту маршрутизатора. Ці адреси призначаються виробниками обладнання. Фізична адреса має шість байтів: старші три байти - ідентифікатор фірми-виробника. Молодші три байти призначаються самим виробником;&lt;/li&gt;<br /> &lt;li&gt;ІР-адреса, що складається з чотирьох байтів. Ця адреса застосовується на мережному рівні еталонної моделі OSI;&lt;/li&gt;<br /> &lt;li&gt;Символьний ідентифікатор - ім'я. Цей ідентифікатор може призначатися адміністратором довільно.&lt;/li&gt;<br /> &lt;/ul&gt;<br /> <br /> Коли протокол ІР був стандартизований у вересні 1981 року, його специфікація вимагала, щоб кожний пристрій, підключений до мережі, мав унікальну 32-бітну адресу. Ця адреса поділяється на дві частини. Перша частина адреси ідентифікує мережу, в якій розміщений пристрій. Друга частина однозначно ідентифікує самий пристрій у рамках мережі. Така схема приводить до дворівневої адресної ієрархії.<br /> <br /> Зараз поле номера мережі у адресі називається мережним префіксом, так як воно ідентифікує мережу. Всі робочі станції у мережі мають один і той же префікс. При цьому вони повинні мати унікальні номери пристроїв. Дві робочі станції, розміщені в різних мережах, повинні мати різні мережні префікси, але при цьому вони можуть мати однакові номери пристроїв. <br /> <br /> Для забезпечення гнучкості у привласнюванні адрес комп'ютерним мережам розробники протоколу визначили, що адресний простір повинен бути поділений на три різних класи - А, В і С. Знаючи клас, Ви знаєте, де у 32-бітовій адресі проходить межа між мережним префіксом і номером пристрою. На мал.1 показані формати адрес цих основних класів.<br /> &lt;center&gt;[[Image:1 419.gif]]&lt;/center&gt;<br /> <br /> &lt;center&gt; Мал.1 Три класи ІР-адрес.&lt;/center&gt;<br /> <br /> Одна з основних переваг застосування класів є в тім, що по класу адреси можна визначити, де проходить межа між мережним префіксом і номером пристрою. <br /> <br /> Недоліком такого методу є необхідність зміни мережної адреси при підключенні додаткових пристроїв. Наприклад, якщо загальне число пристроїв у мережі класу С буде перевищувати 255, то вимагатиметься заміна її адреси на адресу класу В. Зміна мережних адрес потребує від адміністратора додаткових зусиль по налагодженню мережі. Крім того, введення класів адрес значно зменшує теоретично можливе число індивідуальних адрес. У поточній версії протоколу ІР (версія 4) загальне число адрес складає 4 294 967 296, так як протокол передбачає застосування 32 біт для задання адреси. Природньо, застосування частини бітів у службових цілях зменшує доступну кількість індивідуальних адрес.<br /> <br /> Клас А призначений для великих мереж. Кожна адреса класу А має 8-бітовий префікс мережі, у якому старший біт встановлений у 1, а наступні 7 використовуються для номера мережі. Для номера пристрою задіюються 24 біти, що залишилися. На сьогоднішній день всі адреси класу А вже виділені. Мережі класу А також позначаються як &quot;/8&quot;, поскільки адреси цього класу мають 8-бітовий префікс.<br /> <br /> Максимальне число мереж класу А складає 126 (2 адреси віднімаються, що складаються з одних нулів і одиниць). Кожна мережа цього класу підтримує до 16 777 214 пристроїв. Так як адресний блок класу А може містити максимум 2 147 483 648 (2 в степіні 31) індивідуальних адрес, а в протоколі ІР версіі 4 може підтримуватися максимум до 4 294 967 296 (2 в степіні 32) адрес, то клас А займає 50% загального адресного простору протоколу ІР.<br /> <br /> Клас В призначений для мереж середнього розміру. Кожна адреса класу В має 16-бітовий мережний префікс, у якому два старших біти дорівнюють 10, наступні 14 біт використовуються для номера мережі. Для номера пристрою надані 16 біт. Мережі класу В також позначаються як &quot;/16&quot;, поскільки адреса цього класу має 16-бітний мережний префікс.<br /> <br /> Максимальне число мереж класу В дорівнює 16 382 (2 в 14 степіні мінус 2). Кожна мережа цього класу підтримує до 65 534 (2 в 16 степіні мінус 2) пристроїв. Так як весь адресний блок класу В може містити максимум до 1 073 741 824 (2 в 30 степіні) індивідуальних адрес, він займає 25% загального простору протоколу ІР.<br /> <br /> Адреса класу С використовується у мережах з невеликим числом пристроїв. Кожна мережа класу С має 24-бітний префікс, в якому три старших біти дорівнюють 110, а наступні 21 біт використовуються для номера мережі. Під номери пристроїв виділені 8 біт, що залишилися. Мережі класу С також позначаються як &quot;/24&quot;, поскільки адреса цього класу має 24-бітний мережний префікс.<br /> <br /> Максимальне число мереж класу С складає 2 097 152 (2 в 21 степіні). Кожна мережа цього класу підтримує до 254 (2 у восьмій мінус 2) пристроїв. Клас С займає 12,5% загального адресного простору протоколу ІР.<br /> <br /> У доповнення до цих класів адрес надають ще два класи. У класі D старші чотири біти дорівнюють 1110. Цей клас використовується для групової передачі даних. У класі Е старші чотири біти дорівнюють 1111. Він зарезервований для проведення експериментів.<br /> <br /> Для зручності читання адрес у технічній літературі, прикладних програмах і т.д. ІР-адреси зображаються у вигляді чотирьох десяткових чисел, розділених точками. Кожне з цих чисел відповідає одному октету (8 бітам) ІР-адреси. Цей формат називають точечно-десятковим (Decimal-Point Notation) або точечно-десятковою нотацією.<br /> <br /> {| border=&quot;1&quot; cellpadding=&quot;2&quot;<br /> |+ ІР-адреса у точечно-десятковому форматі.<br /> |-<br /> ! 0... !! !! !! ...31<br /> |-<br /> ! 10010001 !! 00001010 !! 00100010 !! 00000011<br /> |-<br /> ! 145. !! 10. !! 34. !! 3.<br /> |}<br /> <br /> <br /> <br /> [[TCP/IP]]<br /> [[category:Комп'ютерні мережі]]</div>

Hiss https://wiki.cusu.edu.ua/index.php/%D0%A0%D1%96%D0%B2%D0%BD%D1%96_%D0%BF%D1%80%D0%BE%D1%82%D0%BE%D0%BA%D0%BE%D0%BB%D1%96%D0%B2_TCP/IP 2008-12-24T09:55:55Z

<p>Hiss: </p> <hr /> <div>Самий нижній (&lt;b&gt;&lt;I&gt;рівень IV&lt;/I&gt;&lt;/b&gt;) відповідає фізичному і канальному рівням моделі OSI. Цей рівень у протоколах TCP/IP не регламентується, але підтримує всі популярні стандарти фізичного і канального рівня: для локальних мереж це Ethernet, Token Ring, FDDI, Fast Ethernet, 100VG-AnyLAN, для глобальних мереж - протоколи з'єднань &quot;крапка-крапка&quot; SLIP і PPP, протоколи територіальних мереж з комутацією пакетів X.25, frame relay. Розроблена також спеціальна специфікація, що визначає використання технології ATM як транспорт канального рівня. Звичайно з появою нової технології локальних або глобальних мереж вона швидко включається в стек TCP/IP за рахунок розробки відповідного RFC, що визначає метод інкапсуляції пакетів IP у її кадри. <br /> <br /> Наступний рівень (&lt;b&gt;&lt;I&gt;рівень III&lt;/I&gt;&lt;/b&gt;) - це рівень межмережевої взаємодії, що займається передачею пакетів з використанням різних транспортних технологій локальних мереж, територіальних мереж, ліній спеціального зв'язку і т.п. <br /> <br /> Як основний протокол мережного рівня (у термінах моделі OSI) у стеку використовується протокол IP, що споконвічно проектувався як протокол передачі пакетів у складених мережах, що складаються з великої кількості локальних мереж, об'єднаних як локальними, так і глобальними зв'язками. Тому протокол IP добре працює в мережах зі складною топологією, раціонально використовуючи наявність у них підсистем і ощадливо витрачаючи пропускну здатність низькошвидкісних ліній зв'язку. Протокол IP є дейтаграмним протоколом, тобто він не гарантує доставку пакетів до вузла призначення, але намагається це зробити. <br /> <br /> До рівня міжмережевої взаємодії відносяться і всі протоколи, зв'язані зі складанням і модифікацією таблиць маршрутизації, такі як протоколи збору маршрутної інформації RIP (Routing Internet Protocol) і OSPF (Open Shortest Path First), а також протокол міжмережевих керуючих повідомлень ICMP (Internet Control Message Protocol). Останній протокол призначений для обміну інформацією про помилки між маршрутизаторами мережі і вузлом - джерелом пакета. За допомогою спеціальних пакетів ICMP повідомляється про неможливість доставки пакета, про перевищення часу життя або тривалості зборки пакета з фрагментів, про аномальні величини параметрів, про зміну маршруту пересилання і типу обслуговування, про стан системи і т.п. <br /> <br /> Наступний рівень (&lt;b&gt;&lt;I&gt;рівень II&lt;/I&gt;&lt;/b&gt;) називається основним. На цьому рівні функціонують протокол керування передачею TCP (Transmission Control Protocol) і протокол дейтаграм користувача UDP (User Datagram Protocol). Протокол TCP забезпечує надійну передачу повідомлень між вилученими прикладними процесами за рахунок утворення віртуальних з'єднань. Протокол UDP забезпечує передачу прикладних пакетів дейтаграмним способом, як і IP, і виконує тільки функції сполучної ланки між мережним протоколом і численними прикладними процесами. <br /> <br /> Верхній рівень (&lt;b&gt;&lt;I&gt;рівень I&lt;/I&gt;&lt;/b&gt;) називається прикладним. За довгі роки використання в мережах різних країн і організацій стік TCP/IP нагромадив велику кількість протоколів і сервісів прикладного рівня. До них відносяться такі широко використовувані протоколи, як протокол копіювання файлів FTP, протокол емуляції термінала telnet, поштовий протокол SMTP, використовуваний в електронній пошті мережі Internet, гіпертекстові сервіси доступу до вилученої інформації, такі як WWW і багато хто інші. <br /> <br /> <br /> <br /> [[TCP/IP]]<br /> [[category:Комп'ютерні мережі]]</div>

Hiss https://wiki.cusu.edu.ua/index.php/UDP 2008-12-24T09:55:15Z

<p>Hiss: </p> <hr /> <div>Протокол дэйтаграмм користувача '''UDP (User Datagram Protocol)''' є протоколом транспортного рівня і базується на можливостях, наданих міжмережевим протоколом IP. Основна задача TCP - забезпечення &quot;швидкої&quot; передачі даних у мережі. Його транспортна адреса в заголовку IP-сегмента дорівнює 17.<br /> <br /> Його основні характеристики перераховані нижче: <br /> - реалізує взаємодію в режимі без встановлення логічного (віртуального) з'єднання; <br /> - організує поблочний (дэйтаграммный, пакетний) тип передачі даних; <br /> - для ідентифікації партнерів по взаємодії на транспортному рівні використовує 16-бітові &quot;номери портів&quot;; <br /> - не гарантує надійної передачі даних (можлива як утрата UDP-пакетів, так і їхнє дублювання); <br /> - не має засобів повідомлення джерела UDP-пакета про правильність/помилковості в його прийомі адресатом; <br /> - не забезпечує правильний порядок доставки UDP-пакетів від джерела до приймача; <br /> - може гарантувати цілісність даних у UDP-пакеті за рахунок використання контрольної суми; <br /> - дуже простий (особливо, у порівнянні з протоколом TCP). <br /> <br /> Слід зазначити, що, по суті справи, протокол транспортного рівня UDP відіграє роль інтерфейсу для прикладних програм до засобів протоколу міжмережевого рівня IP. <br /> <br /> Формат заголовка UDP-пакета. <br /> 0 15 31<br /> +------------------------------+-------------------------------+<br /> | Порт джерела | Порт приймача |<br /> +------------------------------+-------------------------------+<br /> | Довжина | Контрольна сума |<br /> +------------------------------+-------------------------------+<br /> <br /> ''Довжина''. 16-бітове поле, що містить довжину (у байтах) усього UDP-пакета, включаючи заголовок і дані. <br /> <br /> ''Контрольна сума''. 16-бітове поле, що містить Internet-контрольну суму, підраховану для UDP-заголовка, даних пакета і псевдозаголовка. Псевдозаголовок (такий же, як для підрахунку контрольної суми в TCP-заголовку) містить у собі ряд полів IP-заголовка і має показану таку структуру:<br /> 0 7 15 31<br /> +-----------+-----------+-----------------------+<br /> | IP-адреса джерела |<br /> +-----------------------+-----------------------+<br /> | IP-адреса приймача |<br /> +-----------+-----------+-----------------------+<br /> | Нулі | Транспорт | Довжина IP-сегмента |<br /> +-----------+-----------+-----------------------+<br /> <br /> Якщо поле &quot;Контрольна сума&quot; UDP-заголовка містить нульове значення, це означає, що джерело UDP-пакета контрольну суму не підраховував, і приймач виконувати її перевірку не повинний. Деякі реалізації протоколу UDP (наприклад, у SunOS - клоні ОС UNIX від Sun Microsystems) контрольну суму не підраховують у принципі, покладаючись на можливості контролю цілісності даних, реалізовані в протоколах мережного рівня (наприклад, у Ethernet).<br /> <br /> <br /> <br /> [[TCP/IP]]<br /> [[category:Комп'ютерні мережі]]</div>

Hiss https://wiki.cusu.edu.ua/index.php/TCP 2008-12-24T09:54:56Z

<p>Hiss: </p> <hr /> <div>Протокол '''TCP''' (Transmission Соntrоl Рrоtосоl - протокол керування передачею ) - протокол керування передачею даних, що використовує автоматичну повторну передачу пакетів, що містять помилки. Протокол TCP відповідає за розбивку переданої інформації на пакети і правильне відновлення інформації з пакетів одержувача.<br /> <br /> Незважаючи на те, що TCP і UDP використовують той самий мережний рівень (IP), TCP надає додаткам абсолютно інші сервиси, ніж UDP. TCP надає заснований на з'єднанні надійний сервіс потоку байтів. <br /> <br /> Термін &quot;заснований на з'єднанні&quot; (connection-oriented) означає, що два додатки, що використовують TCP (як правило, це клієнт і сервер), повинні установити TCP з'єднання один з одним, після чого в них з'являється можливість обмінюватися даними. Типова аналогія - це набір телефонного номера, чекання відповіді від вилученого абонента, коли він говорить &quot;алло&quot;, після чого необхідно сказати, хто дзвонить. <br /> <br /> TCP забезпечує свою надійність завдяки наступному: <br /> - Дані від додатка розбиваються на блоки визначеного розміру, що будуть відправлені. Це цілком відрізняється від UDP, у якому кожен запис, що здійснює додаток, генерує IP датаграму цього розміру. Блок інформації, що передається від TCP у IP, називається сегментом (segment). <br /> - Коли TCP посилає сегмент, він установлює таймер, очікуючи, що з вилученого кінця прийде підтвердження на цей сегмент. Якщо підтвердження не отримане після закінчення часу, сегмент передається повторно. <br /> - Коли TCP приймає дані від віддаленої сторони з'єднання, він відправляє підтвердження. Це підтвердження не відправляється негайно, а звичайно затримується на долі секунди.<br /> - TCP здійснює розрахунок контрольної суми для свого заголовка і даних. Це контрольна сума, що розраховується на кінцях з'єднання, метою якої є виявити будь-яку зміну даних у процесі передачі. Якщо сегмент прибуває з невірною контрольною сумою, TCP відкидає його і підтвердження не генерується. (Очікується, що відправник відробить тайм-аут і здійснить повторну передачу.) <br /> - Через те що TCP сегменти передаються у вигляді IP датаграм, а IP датаграми можуть прибувати безладно, також безладно можуть прибувати і TCP сегменти. Після одержання даних TCP може по необхідності змінити їхню послідовність, у результаті додаток одержує дані в правильному порядку. <br /> - Через те що IP датаграма може бути продубльована, що TCP, який приймає, повинен відкидати продубльовані дані. <br /> - TCP здійснює контроль потоку даних. Кожна сторона TCP з'єднання має визначений простір буфера. TCP на приймаючій стороні дозволяє вилученій стороні посилати дані тільки в тому випадку, якщо одержувач може помістити них у буфер. Це запобігає переповненню буферів повільних хостів швидкими хостами.<br /> <br /> Між двома додатками по TCP з'єднання здійснюється обмін потоком 8-бітових байтів. Автоматично TCP не вставляє запису маркерів. Це називається сервісом потоку байтів (byte stream service). Якщо додаток на одному кінці записав спочатку 10 байт, потім 20 байт і потім ще 50 байт, додаток на іншому кінці з'єднання не може сказати якого розміру був кожен запис. На іншому кінці ці 80 байт можуть бути лічені, наприклад, за 4 рази по 20 байт за щораз. Один кінець з'єднання поміщає потік байт у TCP, і точно так само ідентичний потік байт з'являється на іншому кінці. <br /> <br /> TCP не інтерпретує вміст байтів. TCP поняття не має про те, чи відбувається обмін двійковими даними, ASCII символами, EBCDIC символами або чим-небудь ще. Ця інтерпретація потоку байтів здійснюється додатками на кожній стороні з'єднання.<br /> <br /> Передача TCP сегментів здійснюється у вигляді Internet датаграм. Заголовок датаграми в Internet протоколі має кілька інформаційних полів, включаючи адреси хост- комп'ютерів, що відправляють і приймають. Заголовок TCP слідує за Internet заголовком і доповнює його інформацією, специфічною для TCP протоколу. Такий розподіл допускає використання на рівні хост-комп’ютерів протоколів, інших ніж TCP. <br /> <br /> Формат TCP заголовка<br /> <br /> &lt;center&gt;[[Image:TCP1.jpg]]&lt;/center&gt;<br /> <br /> Відзначимо, що кожна мітка вказує тут місце для відповідного біта. <br /> <br /> ''Source Port'' (порт відправника) 16 біт<br /> номер порту відправника<br /> <br /> ''Destination Port'' (порт одержувача) 16 біт<br /> номер порту одержувача<br /> <br /> ''Sequence Number'' (номер черги) 32 біта<br /> Номер черги для першого октету даних у даному сегменті (за винятком тих випадків, коли є присутнім прапор синхронізації SYN). Якщо ж прапор SYN є присутнім, то номер черги є ініціалізаційним (ISN), а номер першого октету даних - ISN+1. <br /> <br /> ''Acknowledgment Number'' (номер підтвердження) 32 біта<br /> Якщо встановлено контрольний біт ACK, то це поле містить наступний номер черги, що відправник даної датаграми бажає одержати в зворотному напрямку. Номераи підтвердження посилаються постійно, як тільки з'єднання буде установлено. <br /> <br /> ''Data Offset (зсув даних)'' 4 біти<br /> Кількість 32-бітних слів у TCP заголовку. Указує на початок поля даних. TCP заголовок завжди кінчається на 32-бітній границі слова, навіть якщо він містить опції. <br /> <br /> ''Reserved 6 біт''<br /> Це резервне поле, повинне бути заповнено нулями. <br /> <br /> ''Control Bits'' (контрольні біти) 6 біт<br /> Біти цього поля зліва неправо<br /> URG: поле термінового покажчика задіяне <br /> ACK: поле підтвердження задіяне <br /> PSH: функція проштовхування <br /> RST: перезавантаження даного з'єднання <br /> SYN: синхронізація номерів черги <br /> FIN: немає більше даних для передачі<br /> <br /> ''Window (вікно)'' 16 біт<br /> Кількість октетів даних, починаючи з октету, чий номер зазначений у полі підтвердження. Кількість октетів, одержання яких чекає відправник дійсного сегмента. <br /> <br /> ''Checksum'' (контрольна сума) 16 біт<br /> Поле контрольної суми - це 16-бітне доповнення суми всіх 16- бітних слів заголовка і тексту. Якщо сегмент містить у заголовку і тексті непарну кількість октетів, що підлягають обліку в контрольній сумі, останній октет буде доповнений нулями праворуч для того, щоб утворити для надання контрольній сумі 16-бітне слово. Виниклий при такому вирівнюванні октет не передається разом із сегментом по мережі. Перед обчисленням контрольної суми поле цієї суми заповнюється нулями. <br /> <br /> Контрольна сума, крім усього іншого, враховує 96 біт псевдозаголовка, що для внутрішнього вживання ставиться перед TCP заголовком. Цей псевдозаголовок містить адресу відправника, адресу одержувача, протокол і довжину TCP сегмента. Такий підхід забезпечує захист протоколу TCP від помилившихся в маршруті сегментів. Цю інформацію обробляє Internet протокол. Вона передається через інтерфейс протокол TCP/локальна мережа як аргументи або результати запитів від протоколу TCP до протоколу IP.<br /> <br /> &lt;center&gt;[[Image:TCP2.jpg]]&lt;/center&gt;<br /> <br /> Довжина TCP сегмента - це довжина TCP заголовка і поля даних, вимірювана в октетах. Це не є точною вказівкою кількості переданих по мережі октетів, вона не враховує 12 октетів псевдозаголовку, проте розрахунок цього параметра усе-таки виконується. <br /> <br /> Urgent Pointer (терміновий покажчик) 16 біт<br /> Це поле повідомляє поточне значення термінового покажчика. Останній є позитивною величиною - зсувом щодо номера черги даного сегмента. Терміновий покажчик повідомляє номер черги для октету, що випливає за терміновими даними. Це поле інтерпретується тільки в тому випадку, коли в сегменті виставлений контрольний біт URG. <br /> <br /> Options (опції) довжина змінної<br /> Опції можуть розташовуватися наприкінці TCP заголовка, а їхня довжина кратна 8 біт. Всі опції враховуються при розрахунку контрольної суми. <br /> <br /> Опції можуть починатися з будь-якого октету. Вони можуть мати два формати:<br /> - однооктетний тип опцій; <br /> - октет типу опції, октет довжини опції й октети даних розглянутої опції. <br /> <br /> В октеті довжини опції враховуються октет типу опції, сам октет довжини, а також всі октети з даними. <br /> <br /> Відмітимо, що список опцій може виявитися коротше, ніж можна вказати в полі Data Offset. Місце в заголовку, що залишається за опцією &quot;End-of-Option&quot;, повинне бути заповнено нулями. Протокол TCP повинний бути готовий обробляти всі опції. <br /> <br /> В даний час визначені наступні опції:<br /> <br /> Тип Довжина Значення <br /> <br /> 0 - кінець списку опцій <br /> <br /> 1 - немає операцій <br /> <br /> 2 4 максимальний розмір сегмента<br /> <br /> <br /> Докладныше дивись на http://www.citforum.ru/internet/tifamily/tcpspec.shtml#3.1<br /> <br /> <br /> <br /> [[TCP/IP]]<br /> [[category:Комп'ютерні мережі]]</div>

Hiss https://wiki.cusu.edu.ua/index.php/SMTP 2008-12-24T09:54:22Z

<p>Hiss: </p> <hr /> <div>Електронна пошта (e-mail), безсумнівно, один із самих популярних додатків. [Caceres et al. 1991] показує, що приблизно половина всіх TCP з'єднань зайнята передачею поштових повідомлень з використанням простого протоколу передачі пошти (SMTP - Simple Mail Transfer Protocol). (З погляду кількості переданих байт, по FTP з'єднаннях передається значно більше даних.) [Paxson 1993] знайшов, що середнє поштове повідомлення містить приблизно 1500 байт даних, однак деякі повідомлення містять мегабайти даних, тому що електронну пошту іноді використовується для посилки файлів. <br /> <br /> &lt;center&gt;[[Image:SMTP.jpg]]&lt;/center&gt;<br /> <br /> На малюнку показаний обмін поштою з використанням TCP/IP.<br /> Користувачі спілкуються з користувацькими агентами (user agent). В даний час існує дуже багато реалізацій користувацьких агентів. Популярні користувацькі агенти для Unix це MH, Berkeley Mail, Elm і Mush. <br /> <br /> Обмін поштою з використанням TCP здійснюється за допомогою агентів передачі повідомлень (MTA - message transfer agent). Найбільш розповсюджені MTA для Unix систем це Sendmail. Користувачі звичайно не спілкуються з MTA. У задачу системного адміністратора входить установка локального MTA. <br /> <br /> '''''Протокол SMTP'''''. При спілкуванні між двома MTA використовується NVT ASCII. Команди посилаються клієнтом серверу, а сервер відповідає за допомогою цифрових кодів і опціональних текстових рядків (для читання людиною). Це трохи нагадує сценарій, що для FTP.<br /> Клієнт може послати серверу невелику кількість команд: менше дюжини. (Для порівняння, FTP має більше сорока команд.) <br /> <br /> <br /> <br /> [[TCP/IP]]<br /> [[category:Комп'ютерні мережі]]</div>

Hiss https://wiki.cusu.edu.ua/index.php/RARP 2008-12-24T09:53:55Z

<p>Hiss: </p> <hr /> <div>Коли завантажується система з локальним диском, вона звичайно одержує свою IP адресу з конфігураційного файлу, що зчитується з диска. Однак для систем, що не мають диска, таких як X термінали або бездискові робочі станції, потрібний інший спосіб визначення власної IP адреси. <br /> <br /> Кожна система в мережі має унікальну апаратну адресу, що призначається виробником мережного інтерфейсу (мережної плати). Принцип роботи RARP полягає в тому, що бездискова система може зчитувати свою унікальну апаратну адресу з інтерфейсної плати і послати RARP запит (широкомовний фрейм у мережу), де буде запит до кого-небудь відгукнутися і повідомити IP адресу (за допомогою RARP відгуку). <br /> <br /> Незважаючи на те що концепція досить проста, її реалізація як правило значно складніше ніж [[ARP]]. Офіційна специфікація RARP знаходиться в RFC 903 [Finlayson et al. 1984].<br /> <br /> '''''Формат пакета RARP'''''<br /> Формат пакета RARP практично ідентичний пакету [[ARP]] (див. малюнок на сторінці ARP). Єдина відмінність полягає в тому, що поле тип фрейму (frame type) для запиту або відгуку RARP встановлене в 0x8035, а поле op має значення 3 для RARP запиту і значення 4 для RARP відгуку.<br /> RARP запит є широкомовним, а RARP відгук звичайно персональний.<br /> <br /> ''Проблеми'' з RARP полягають у тому, що він використовує широкомовні запити на канальному рівні, тому більшість маршрутизаторів не можуть перенаправляти RARP запити; а також у тому, що передається мінімум необхідної інформації: тільки IP адреса системи. <br /> Незважаючи на те що концепція RARP досить проста, реалізація RARP сервера залежить від системи. Також треба відзначити, що не всі TCP/IP реалізації надають RARP сервер.<br /> <br /> <br /> <br /> [[TCP/IP]]<br /> [[category:Комп'ютерні мережі]]</div>

Hiss https://wiki.cusu.edu.ua/index.php/PPP 2008-12-24T09:53:17Z

<p>Hiss: </p> <hr /> <div>'''Point-to-Point Protocol''' (PPP) розроблений для розв’язання проблем зв'язаних з недостатньою кількістю стандартних засобів інкапсуляції протоколів виду &quot;point-to-point IP&quot;. Також PPP був також розроблений для спрощення видачі і керування IP адресами, асинхронної і bit-oriented синхронною інкапсуляцією, змішування мережних протоколів(network protocol multiplexing), конфігурувания і тестування якості зв'язку, виявлення помилок і опціями для встановлення таких особливостей мережного рівня як налаштування адрес і установка стиску даних. Для підтримки вище перерахованих якостей, PPP повинен надавати керування по розширеному Link Control Protocol (LCP) і сімейству протоколів Network Control Protocols (NCPs) які використовуються для встановлення параметрів зв'язку. Hа сьогоднішній день PPP підтримує не тільки IP, але й інші протоколи, включаючи IPX і DECNet.<br /> <br /> Протокол PPP (Point-to-Point Protocol;)служить для передачі мультипротокольних дейтограм від одного вузла до іншого. Даний протокол відноситься до числа найбільш важливих і широко використовуваних. Це і зрозуміло, більшість регіональних мереж будується з використанням з'єднань крапка-крапка. PPP підтримує, як асинхронний режим з 8 бітами даних без біта парності (погодиться з властивостями послідовного інтерфейсу, що мається практично на всіх ЕОМ), так і побітовий синхронний режим. <br /> Протокол містить у собі три складові частини:<br /> - Метод інкапсуляції дейтограм при передачі по послідовних комунікаційних каналах.<br /> - Протокол LCP для встановлення, конфігурування і тестування інформаційних каналів<br /> - Набір протоколів NCP для установки і конфігурування різних протоколів мережного рівня.<br /> <br /> Протокол керування каналом (LCP - Link Control Protocol) є частиною PPP. Кожен кадр PPP починається і завершується ''прапором'' 0x7E. За стартовим прапором-октетом випливає байт ''адреси'', що завжди дорівнює 0xFF.<br /> Формат кадру PPP представлений на малюнку<br /> <br /> &lt;center&gt;[[Image:PPP1.gif]]&lt;/center&gt;<br /> <br /> Кадр ppp може містити тільки ціле число байт. При інкапсуляції інших пакетів у PPP використовується біт-орієнтований протокол HDLC (High-level Data Link Control).<br /> <br /> ''Поле адреси'' завжди містить байт 0xff . Це вказує на те, що всі станції повинні прийняти цей кадр, і виключає необхідність виділення якихось спеціальних адрес. <br /> <br /> ''Байт керування'' завжди дорівнює 0x03, що вказує на ненумерований тип кадру. За замовчуванням кадри PPP передаються в режимі &quot;без установлення з'єднання&quot;. Якщо потрібна надійна доставка, використовується версія, описана в RFC-1663. <br /> ''Двооктетне поле протокол'' подібно по функції з полем тип у кадрі Ethernet і визначає те, як варто інтерпретувати інформаційне поле. Значення 0x0021 цього поля говорить про те, що наступне інформаційне поле містить у собі IP-дейтограмму. Поле CRC (Cyclic Redundancy Check) являє собою циклічну контрольну суму, призначену для виявлення помилок при транспортуванні PPP-кадру. <br /> <br /> Застосування ''прапорів-обмежників кадру'' (0x7E) створює ті ж проблеми, про які говорилося при описі SLIP-протоколу, - ці байти не можуть бути присутнім в інформаційному полі. У синхронному режимі ця проблема вирішується на апаратному рівні. При роботі в асинхронному режимі для цього використовується спеціальний ESC-символ, рівний 0x7D. Коли цей esc-символ зустрічається в інформаційному полі, шостий біт у наступному за ним байті інвертується. Так байт 0x7E буде перетворений у послідовність 0x7D, 0x5E, а байт 0x7D - у два байти 0x7D, 0x5D. Усі символи з кодами менше 0x20 також перетворяться в ESC-послідовності. Наприклад, 0x07 буде перетворений у 0x7D, 0x27. Це необхідно робити, тому що керуючі символи можуть зробити непередбачені впливи на режим роботи драйверів або модемів, використовуваних у каналі. <br /> <br /> Протокол ppp на відміну від SLIP допускає ''мультипротокольність і динамічне визначення IP-адрес партнерів''. Незважаючи на визначені переваги протоколу PPP перед SLIP, останній розповсюджений досить широко. Не важко бачити, що всі перераховані фізичні середовища використовують послідовний формат передачі інформації.<br /> <br /> <br /> Значення кодів поля протоколу від 0xxx до 3xxx ідентифікують протоколи мережного рівня, а значення в інтервалі 8xxx - bxxx говорять про те, що протокол відповідає NCP (Network Control Protocol). Коди з діапазону 4xxx - 7xxx використовуються для протоколів з низьким рівнем трафіку, а коди від cxxx до exxx відповідають керуючим протоколам (наприклад, LCP).<br /> <br /> Протокол PPP при встановленні з'єднання передбачає процедуру аутентификації, що є опціонною (дивися мал. нижче). Після переходу на мережний рівень викликається NCP-протокол, що виконує необхідну конфігурацію каналу.<br /> <br /> <br /> <br /> При виявленні несущої або з ініціативи клієнта система може спробувати установити з'єднання. У випадку успіху система переходить у фазу аутентификації. Якщо ж і фаза аутентификації завершується благополучно, система виконує підключення до мережі (IP, IPX, Appletalk і т.д.), налаштування мережного рівня виробляється в рамках протоколу NCP. В всіх інших випадках виконується повернення у вихідний стан. Процедура закриття з'єднання здійснюється протоколом LCP.<br /> <br /> У поле даних PPP-пакета може бути вкладений один LCP-пакет, у цьому випадку в поле протокол повинний бути записаний код 0x021 (Link Control Protocol). LCP-протокол служить для встановлення з'єднання шляхом обміну конфігураційними пакетами. По завершенні цього обміну система переходить у фазу аутентификації. Формат LCP-пакета показаний на мал. нижче.<br /> <br /> &lt;center&gt;[[Image:Lcp.gif]]&lt;/center&gt;<br /> <br /> Слідом за заголовком слідує поле даних. Поле код (1 октет) ідентифікує модифікацію LCP-пакета. Якщо отримано пакет з невідомим полем код, посилається пакет-відгук “відхилення коду”. Поле ідентифікатор (1 октет) служить для перебування відповідності між запитами і відгуками. Якщо отримано пакет з неправильним ідентифікатором, він просто знищується. Двооктетне поле &quot;довжина&quot; визначає розмір LCP-пакета, включаючи розмір заголовка. Октети прийнятого пакета за межами, заданими полем довжина ігноруються.<br /> <br /> (докладніше дивись на http://book.itep.ru/3/ppp_35.htm)<br /> <br /> <br /> <br /> [[TCP/IP]]<br /> [[category:Комп'ютерні мережі]]</div>

Hiss https://wiki.cusu.edu.ua/index.php/%D0%9F%D1%80%D0%BE%D1%82%D0%BE%D0%BA%D0%BE%D0%BB_%D0%86%D0%A0v6 2008-12-24T09:52:57Z

<p>Hiss: </p> <hr /> <div>Робота по розширенню протоколу ІР була розпочата у 1992 році. Необхідність цього диктувалась тим, що практично всі ресурси старої версії протоколу ІР (ІРv4) були вичерпані. Швидке зростання Інтернет привело до появи дефіциту ІР-адрес. Зросший трафік почав викликати перевантаження магістральних маршрутизаторів. Змінився і характер передаваємого трафіка. Все більшу роль у ньому почали займати мультімедійні дані. <br /> <br /> Нова версія протоколу ІР - версія 6 - була прийнята організацією IETF у 1995 році. Вона описана у документі RFC 1752. В теперішній час відбувається поступовий перехід до протоколу ІРv6. Існує декілька фрагментів мережі Інтернет, у яких маршрутизатори підтримують обидві версії ІР. Ці фрагменти об'єднані між собою і утворюють так звану &quot;шосту&quot; магістраль (6 bone). Для того, щоб передати дейтаграми протоколу ІРv6, магістраль 6 bone інкапсулює їх у дейтаграму ІР і передає їх через ті частини мережі Інтернет, які не підтримують нову версію протоколу. Цей процес називається тунелюванням. Слід пам'ятати, що поява додаткового заголовку при тунелюванні веде до зростання мережного трафіка. Документ RFC 1933 визначає чотири конфігурації тунелів між робочими станціями і маршрутизаторами: <br /> <br /> &lt;ul&gt;<br /> &lt;li&gt;маршрутизатор-маршрутизатор;&lt;/li&gt;<br /> &lt;li&gt;робоча станція-маршрутизатор;&lt;/li&gt;<br /> &lt;li&gt;робочі станції-маршрутизатори;&lt;/li&gt;<br /> &lt;li&gt;маршрутизатор-робоча станція. &lt;/li&gt;<br /> &lt;/ul&gt;<br /> <br /> Іншим методом, який дозволяє здійснити плавний перехід на нову версію, є застосування подвійних стеків. Подвійні стеки дозволяють вузлу у мережі ІР підтримувати обидві версії протоколу. Такі вузли називаються IPv6/IPv4-вузлами. Застосування подвійного стеку дозволяє роздільно переводити на протокол IPv6 кожний пристрій у мережі. За цим необхідно задіяти додаткові ресурси такого пристрою, змінити його конфігураційну інформацію і провести ряд інших операцій. <br /> <br /> Протокол IPv6 підтримується практично всіма сучасними операційними системами і виробниками мережного обладнання. Природньо, розвиток протоколу ІР повлік за собою модернізацію всього стеку ТСР/ІР. <br /> <br /> Схема адресації IPv6 істотньо відрізняється від схеми адресації протоколу ІР. Адреса отримувача і відправника у протоколі IPv6 задаються 128 бітами. Така довжина адресного простору дозволяє на достатньо великий період часу зняти проблему дефіциту адрес у мережі Інтернет. Основним механізмом, закладеним у схему адресації протоколу IPv6, є введення ієрархічного розподілу адресного простору на рівні. Замість попередніх двох рівнів - номера мережі і номера пристрою, - у протоколі IPv6 застосовується п'ять рівнів, поєднуючи два рівня ідентифікації провайдерів і три рівня ідентифікації абонентів у мережі. <br /> <br /> У протоколі IPv6 відмінено поділ адрес на класи. У основі розподілу адресного простору лежить технологія CIDR (Class-less Inter-Domain Routing, безкласової міждоменної маршрутизації). CIDR дозволяє об'єднувати маршрути. Одним записом у таблиці маршрутизації можна описувати сотні адрес. Це дозволяє значно зменшити об'єм маршрутної інформації у магістральних маршрутизаторах Інтернет.<br /> <br /> Технологія CIDR вводить поняття узагальненого мережного префікса. Маршрутизатори використовують цей мережний префікс для визначення меж у ІР-адресі між номером мережі і номером пристрою, замість традиційної перевірки перших трьох бітів адреси для виявлення класу адреси. Завдячуючи цьому технологія CIDR здатна підтримувати мережі довільного розміру. У технології CIDR будь-яка маршрутна інформація розсилається маршрутизаторами з указівкою мережного префіксу. Довжина мережного префіксу у бітах служить для визначення числа старших біт, які відповідають номеру мережі у запису таблиці маршрутизації.<br /> <br /> Технологія CIDR вже застосовується з четвертою версією протоколу ІР і підтримується протоколами маршрутизації OSPF, RIP-2 i BGP-4. Для плавного переходу до протоколу ІРv6 введений спеціальний тип адрес - IPv4-compatible (сумісні адреси). У цих адресах старші 96 біт містять нулі, а молодші 32 біти - звичайну адресу IPv4.<br /> <br /> <br /> <br /> [[TCP/IP]]<br /> [[category:Комп'ютерні мережі]]</div>

Hiss https://wiki.cusu.edu.ua/index.php/IP 2008-12-24T09:52:31Z

<p>Hiss: </p> <hr /> <div>Міжмережевий протокол '''IP''' специфікований у RFC 791. Це самий фундаментальний протокол з комплекту TCP/IP - передає IP-дейтаграми по інтрамережі і виконує важливу функцію, що називається маршрутизацією, по суті справи це вибір маршруту, по якому дейтаграма буде випливати з пункту А в пункт B, і використання маршрутизаторів для &quot;стрибків&quot; між мережами. <br /> <br /> Його ''основні характеристики'' перераховані нижче: <br /> - реалізує обмін інформації пакетами, які будемо називати IP-сегментами (максимальний розмір IP-сегмента - 65535 байт); <br /> - є протоколом взаємодії без установлення логічного з'єднання; <br /> - для адресації вузлів мережі використовується адреса довжиною 4 байти; <br /> - забезпечує в разі потреби фрагментацію IP-сегментів; <br /> - IP-сегменти мають кінцевий час життя в мережі; <br /> - не гарантує надійність доставки IP-сегментів адресату; <br /> - не має засобів керування інтенсивністю передачі IP-сегментів стороною, що посилає, (flow control); <br /> - не гарантує правильну послідовність IP-сегментів на приймаючій стороні.<br /> <br /> Отже, IP - ''ненадійний протокол, що надає сервіс доставки датаграмм без з'єднання''. <br /> <br /> Під словом ''ненадійний'' ми маємо на увазі те, що не існує гарантії того, що IP датаграмма успішно досягне пункту призначення. Однак IP надає визначений сервіс обробки деяких подій. Коли що-небудь йде не так як хотілося б, як наприклад, тимчасове переповнення буфера в маршрутизатора, IP застосовує простий алгоритм обробки помилок: він відкидає датаграмму і намагається послати ICMP повідомлення відправникові. Будь-яка необхідна надійність повинна бути забезпечена верхніми рівнями (наприклад TCP). <br /> <br /> Термін ''без з'єднання'' (connectionless) означає, що IP не містить ніякої інформації про просування датаграмм. Кожна датаграмма обробляється незалежно від інших. Це також означає, що може бути доставлена зіпсована датаграмма. Якщо джерело відправляє дві послідовні датаграммы (перша A, потім B) в один і те ж пункт призначення, кожна з них маршрутизується незалежно і може пройти по різних маршрутах, датаграмма B може прибути раніше за A.<br /> <br /> '''''IP заголовок'''''.На малюнку показаний формат IP датаграми. Стандартный розмір IP заголовка складає 20 байт, якщо нема опцій.<br /> &lt;center&gt;[[Image:T3_1.jpg]]&lt;/center&gt;<br /> <br /> Старший значущий біт має номер 0 (ліворуч), а молодший значущий біт з 32-х біт має номер 31 і показаний праворуч. <br /> <br /> 4 байти з 32-бітного значення передаються в наступному порядку: спочатку біти 0 - 7, потім біти 8 - 15, потім 16 - 23 і, нарешті, 24 - 31. Такий порядок руху байтів називається big endian (метод збереження або передачі даних, при якому старший значущий біт або байт стоїть першим) і обов'язковий для всіх двійкових цілих чисел у TCP заголовках при їхній передачі по мережі. Це називається порядок мережних байтів (network byte order). Машини, що зберігають двійкові цілі в інших форматах, як наприклад у форматі little endian (little endian - метод збереження або передачі даних, при якому молодший значущий біт або байт стоїть першим), повинні конвертувати значення заголовків у відповідний порядок мережних байтів перед передачею даних. <br /> <br /> Довжина ''заголовка'' (header length) це кількість 32-бітних слів у заголовку, включаючи будь-які опції. Тому що це 4-бітне поле, воно обмежує розмір заголовка в 60 байт. Це обмеження сильно впливає на деякі опції, такі як опція запису маршруту. Звичайна величина в цьому полі (коли відсутні опції) - 5. <br /> <br /> Поле ''типу сервісу'' (TOS - type-of-service) складається з 3-бітного поля приставки (яке в даний час ігнорується), 4 біт TOS і невикористовуваного біта, що повинен дорівнювати 0.<br /> 4 біта TOS наступні: мінімальна затримка, максимальна пропускна здатність, максимальна надійність і мінімальна вартість. Тільки один з цих 4 біт може бути встановлений в одиницю одночасно. Якщо всі 4 біти рівні 0, це означає звичайний сервіс. RFC 1340 [Reynolds and Postel 1992] указує, як ці біти повинні бути встановлені для всіх стандартних додатків. RFC 1349 [Almquist 1992] містить деякі корекції для цього RFC і більш детальний опис характеристики TOS.<br /> <br /> ''Діалогові додатки'', Telnet і Rlogin, вимагають звести до мінімуму затримку, тому що вони використовуються людиною інтерактивно і здійснюють невелику передачу даних. Передача файлів з використанням FTP, з іншого боку, вимагає максимальної пропускної здатності. Максимальна надійність необхідна для мережного керування (SNMP) і для протоколів маршрутизації. Новини Usenet (NNTP) - це єдиний додаток, що вимагає мінімізації вартості. <br /> <br /> ''Поле повної довжини'' (total length) містить повну довжину IP датаграммы в байтах. Завдяки цьому полю і полю довжини заголовка, ми знаємо, з якого місця починаються дані в IP датаграмі і їхню довжину. Тому що це поле складається з 16 біт, максимальний розмір IP датаграми складає 65535 байт. Це поле змінюється в момент фрагментації і повторної зборки датаграми. <br /> <br /> Незважаючи на то що існує можливість відправити датаграму розміром 65535 байт, більшість канальних рівнів поділять подібну датаграму на фрагменти. Більш того, від хоста не потрібно приймати датаграму розміром більше за 576 байт. TCP поділяє користувацькі дані на частині, тому це обмеження звичайно не робить впливу на TCP. Що стосується UDP, послугами якого користуються багато додатків (RIP, TFTP, BOOTP, DNS, SNMP), те він обмежує себе 512 байтами користувацьких даних, що навіть менше обмеження в 576 байт. Більшість додатків у даний час (особливо ті, котрі підтримують NFS - Network File System) дозволяють використовувати IP датаграму розміром 8192 байта. <br /> <br /> Однак, поле повної довжини потрібно в IP заголовку для деяких каналів (як наприклад, Ethernet), що доповнює маленькі фрейми до мінімальної довжини. Незважаючи на те що мінімальний розмір фрейму Ethernet складає 46 байт (малюнок 2.1), IP датаграма може бути ще менше. Якщо поле повної довжини не було представлено, IP рівень не буде знати, скільки 46-байтных фреймів Ethernet вийде з IP датаграми. <br /> <br /> ''Поле ідентифікації'' (identification) унікально ідентифікує кожну датаграму, відправлену хостом. Значення, що зберігається в полі, звичайно збільшується на одиницю з посилкою кожної датаграми. <br /> Поле часу життя (TTL - time-to-live) містить максимальну кількість пересилань (маршутизаторов), через які може пройти датаграма. Це поле обмежує час життя датаграми. Значення установлюється відправником (як правило 32 або 64) і зменшується на одиницю кожним маршрутизатором, що обробляє датаграму. Коли значення в полі досягає 0, датаграмма видаляється, а відправник повідомляється про це за допомогою ICMP повідомлення. Подібний алгоритм запобігає зацикленню пакетів у петлях маршрутизації. <br /> <br /> ''Поле протоколу'' (protocol) вказує, який протокол відправив дані через IP. <br /> <br /> ''Контрольна сума заголовка'' (header checksum) розраховується тільки для IP заголовка. Вона не містить у собі дані, що слідують за заголовком. ICMP, IGMP, UDP і TCP мають контрольні суми у своїх власних заголовках, що охоплюють їхні заголовки і дані. <br /> <br /> Щоб розрахувати контрольну суму IP для вихідної датаграмми, поле контрольної суми спочатку встановлюється в 0. Потім розраховується 16-бітна сума з пірозрядним доповненням (One's complement - порозрядне доповнення до двійкової системи.) (заголовок цілком сприймається як послідовність 16-бітних слів). 16-бітне порозрядне доповнення цієї суми зберігається в поле контрольної суми. Коли IP датаграма приймається, обчислюється 16-бітна сума з порозрядним доповненням. Контрольна сума, розрахована приймачем, містить у собі контрольну суму, збережену відправником, контрольна сума приймача складається з бітів рівних 1, якщо в заголовку нічого не було змінено при передачі. Якщо в результаті не вийшли всі одиничні біти (помилка контрольної суми), IP відкидає прийняту датаграму. Повідомлення про помилку не генерується. Тепер задача верхніх рівнів яким-небудь образом визначити, що датаграма відсутнія, і забезпечити повторну передачу. <br /> <br /> Кожна IP датаграмма містить IP ''адреса джерела'' (source IP address) і IP ''адреса призначення'' (destination IP address). Це 32-бітні значення, що ми описали в розділі &quot;Адресація Internet&quot; глави 1. <br /> <br /> І останнє поле - ''поле опцій'' (options), це список додаткової інформації змінної довжини. В даний час опції визначені в такий спосіб: <br /> - безпека й обробка обмежень (для військових додатків, описане в RFC 1108 [Kent 1991]), <br /> - запис маршруту (запис кожного маршруту і його IP адреса, глава 7, розділ &quot;Опція запису IP маршруту&quot;), <br /> - тимчасова марка (запис кожного маршруту, його IP адреса і час, глава 7, розділ &quot;IP опція тимчасової марки&quot;), <br /> - вільна маршрутизація від джерела (указує список IP адрес, через які повинна пройти датаграма), і тверда маршрутизація від джерела (те ж саме, що й у попередньому пункті, однак IP датаграма повинна пройти тільки через зазначені в списку адреси).<br /> <br /> Ці опції рідко використовуються і не всі хости або маршрутизатори підтримують всі опції. <br /> <br /> Поле опцій завжди обмежено 32 бітами. Байти заповнення, значення яких дорівнює 0, додаються по необхідності. Завдяки цьому IP заголовок завжди кратний 32 биткам (як це потрібно для поля довжини заголовка).<br /> <br /> <br /> <br /> [[TCP/IP]]<br /> [[category:Комп'ютерні мережі]]</div>

Hiss https://wiki.cusu.edu.ua/index.php/IGMP 2008-12-24T09:51:10Z

<p>Hiss: </p> <hr /> <div>Кінцеві користувачі, які хочуть одержувати пакети багатоадресної розсилки, повинні мати можливість повідомити найближчим маршрутизаторам про своє бажання стати членом групи багатоадресної розсилки й одержувати пакети, призначені цій групі. Міжмережевий протокол керування групами - '''Internet Group Management Protocol (IGMP)''' - використовується для підтримки членства в групі багатоадресної розсилки. IGMP також використовується для узгодження роботи декількох маршрутизаторів багатоадресної розсилки, що виробляється шляхом вибору одного маршрутизатора в якості &quot;ведучого&quot;. Цей маршрутизатор відслідковує членство в групах багатоадресної розсилки, що мають активних членів у мережі. IGMP використовується для визначення, чи повинен маршрутизатор передавати в підключені до нього підмережі прийняті пакети чи ні. Маршрутизатор, прийнявши пакет групового розсилання, перевіряє по його джерелу, є чи хоча б один член групи багатоадресної розсилки, що зробив запит на прийом цих пакетів. Якщо так, то пакет просувається. Якщо не існує жодного члена групи багатоадресної розсилки, то пакет відкидається. <br /> <br /> IGMP версій 1 і 2<br /> Користувачі, які бажають одержувати пакети групового розсилання, повинні мати можливість приєднуватися до груп багатоадресної розсилки і залишати їх. Це досягається використанням протоколу IGMP. <br /> <br /> Нижче приведені коди типів протоколу IGMP:<br /> <br /> Тип Значення<br /> <br /> +---------------------------------------------------------------------------+<br /> <br /> 0x11 Запит на членство (якщо групова адреса дорівнює 0.0.0.0)<br /> <br /> 0x11 Запит на членство у визначеній групі (якщо є присутнім групова адреса)<br /> <br /> 0x16 Відповідь про приналежність групі (версія 2)<br /> <br /> 0x17 Залишити групу (версія 2)<br /> <br /> 0x12 Відповідь про приналежність групі (версія 1)<br /> <br /> +---------------------------------------------------------------------------+<br /> <br /> Маршрутизатори використовують IGMP для керування членством у групах многоадресной розсилання: <br /> - Користувачі посилають IGMP-відповіді для приєднання до групи. <br /> - IGMP версії 1 не має явного повідомлення &quot;залишити групу&quot;. Члену групи призначається таймер, і якщо значення таймера минає до одержання відповіді, то користувач видаляється з групи. <br /> - IGMP версії 2 надає окреме повідомлення &quot;залишити групу&quot;. Користувач посилає дане повідомлення маршрутизату багатоадресної розсилки, коли хоче залишити групу (у IGMP версії 2). <br /> - Маршрутизатор періодично посилає IGMP-запити (по груповій адресі усіх вузлів підмережі: 224.0.0.1), щоб довідатися, чи існують члени яких-небудь груп у його підмережах. Якщо від конкретної групи не приходить відповідь, то маршрутизатор вважає, що в мережі немає членів даної групи, і не передає її трафик. <br /> <br /> Поле TTL повідомлення-запиту встановлюється в 1, тому запити не передаються в інші підмережі. IGMP версії 2 пропонує кілька додатків до IGMP версії 1, таких як вибір єдиного &quot;ведучого&quot; маршрутизатора для кожної мережі, окреме повідомлення &quot;залишити групу&quot; і запити, специфічні для конкретної групи багатоадресної розсилки. <br /> <br /> У якості &quot;ведучого&quot; вибирається маршрутизатор з найменшою IP-адресою. Окреме повідомлення &quot;залишити групу&quot; додано для зменшення часу чекання і для того, щоб маршрутизатор міг опитувати конкретні групи багатоадресної розсилки й одержувати відповіді користувачів про приналежність цій групі. <br /> <br /> <br /> <br /> [[TCP/IP]]<br /> [[category:Комп'ютерні мережі]]</div>

Hiss https://wiki.cusu.edu.ua/index.php/ICMP 2008-12-24T09:50:51Z

<p>Hiss: </p> <hr /> <div>Міжмережевий протокол керуючих повідомлень '''''ICMP''''' (Internet Control Message Protocol), специфікований у RFC 792, відіграє роль транспортного протоколу для керуючої і діагностичної інформації, який обмінюються між собою IP-, TCP- або UDP-модулі потай від додатків. Протокол ICMP підтримується в обов'язковому порядку кожним IP-модулем. Його транспортна адреса в IP-заголовку дорівнює 1. <br /> <br /> <br /> &lt;center&gt;'''Заголовок ICMP-пакета'''&lt;/center&gt;<br /> Оскільки протокол ICMP використовується для транспортування досить різної інформації, то фіксується лише загальна структура заголовка ICMP-пакета, що має формат, показаний на малюнку нижче: <br /> 0 7 15 31<br /> +-----------+-----------+-----------------------+<br /> | Тип | Код | Контрольна сума |<br /> +-----------+-----------+-----------------------+<br /> | Різне |<br /> +-------------------------------------------------+<br /> : Тіло пакета: :<br /> : IP-заголовок і наступні за ним 8 байт даних :<br /> : або :<br /> : тестові дані :<br /> +--------------------------------------------------+<br /> <br /> ''Тип'' однобайтове поле, що містить ідентифікатор типу ICMP-пакета. Можливі значення цього поля приведені в таблиці. <br /> ---------------+---------------------------<br /> Поле &quot;Тип&quot; | Призначення<br /> ---------------+----------------------------<br /> 0 Відповідь на запит луни (эхо)<br /> 3 Адресат недоступний<br /> 4 Придушення джерела<br /> 5 Перенаправлення<br /> 8 Запит луни<br /> 11 Вичерпаний час життя<br /> 12 Помилка в параметрі<br /> 13 Запит тимчасової мітки<br /> 14 Відповідь на запит тимчасової мітки<br /> --------------+------------------------------<br /> <br /> ''Код'': однобайтовое поле, значення якого конкретизує призначення ICMP-пакета визначеного типу.<br /> <br /> ''Контрольна сума'': 16-бітове поле, що містить Internet-контрольну суму, підраховану для всього ICMP-пакета цілком. <br /> <br /> ''Різне'': чотирибайтовое поле, призначене для збереження різноманітної інформації, специфічної для ICMP-пакетів визначеного типу (наприклад, номера в TCP-послідовності, IP-адреси і т.п.). <br /> <br /> ''Тіло пакета'': тут утримується заголовок IP-сегмента, який є породженням даного ICMP-пакета, і перші 8 байт дані тіла цього IP-сегмента. Якщо ICMP-пакет є результат прояву аномалії в TCP- або UDP-взаємодії, то ці 8 байт будуть являти собою перші вісім байтів, відповідно, TCP- або UDP-заголовка, що дає можливість визначити, зокрема, номери портів (а, отже, і їхні прикладні програми, що використовують,). <br /> Для ICMP-пакетів деяких типів це може містити не початок IP-сегмента, а тестові дані. <br /> <br /> ''Джерелами й оброблювачами'' ICMP-пакетів могуть бути як IP-модулі, так і TCP- і UDP-модулі (але ніколи прикладні програми). <br /> <br /> Проблеми в доставці й обробці ICMP-пакетів ніколи не приводять до породження нових ICMP-пакетів, що повідомляють про ці проблеми. Зроблено це з метою уникнути можливих нескінченних циклів генерації ICMP-пакетів у мережі. <br /> <br /> &lt;center&gt;'''''Типи ICMP-пакетів'''''&lt;/center&gt;<br /> Тут розглядаються 6 типів ICMP-пакетів, реалізованих у всіх клонах і версіях ОС UNIX. <br /> <br /> '''''Адресат недоступний''''' <br /> ICMP-пакет цього типу генерується в наступних випадках: <br /> - мережа, вузол мережі, протокол або порт є недоступними; <br /> - у ході просування по мережі IP-сегмента потрібна була його фрагментація, однак у заголовку сегмента встановлений прапор DF, що забороняє робити це; <br /> - маршрут, що пропонується, зазначений у поле додаткових даних IP-сегмента, виявився недійсним (неіснуючим або неактивним). <br /> <br /> '''''Придушення джерела''''' <br /> У ситуаціях, коли деякий вузол (як правило, шлюз) не має досить місця у своїх буферах для розміщення даних, що інтенсивно надходять до нього, він може послати вузлам-джерелам ICMP-пакет даного типу (source quench). Вузол-джерело у відповідь на таке повідомлення зобов'язаний зменшити темп передачі даних. <br /> <br /> У ранніх UNIX-реалізаціях протоколів TCP/IP ICMP-пакети цього типу ігнорувалися. У TCP-реалізаціях, що підтримують алгоритм повільного старту, у відповідь на це повідомлення зменшується розмір &quot;вікна перевантаженості&quot;. UDP-модулі ігнорують це повідомлення, інформуючи при цьому прикладну програму, що обслуговується, про вимогу приймача зменшити інтенсивність і/або розмір дэйтаграмм. <br /> <br /> '''''Перенапрямок''''' <br /> ICMP-пакет цього типу посилається джерелу даних, коли вузол-шлюз виявляє, що джерело може направляти свої дані безпосередньо до наступного шлюзу маршруту. Такий ICMP-пакет містить у собі IP-адреса цього шлюзу. Ця IP-адреса повинна бути включена в таблицю маршрутизації на вузлі-джерелі даних. <br /> <br /> '''''Луна (Эхо)'''''<br /> Для реалізації луни IP-модуль на вузлі A відправляє вузлові B ICMP-пакет типу &quot;запит луни&quot;, що містить у своєму тілі замість IP-заголовка тестові дані довільної довжини. Вузол B, одержавши такий запит, повертає вузлу A ICMP-пакет типу &quot;відповідь на запит луни&quot;, що містить ті ж дані, що й у запиті. Луни-посилки використовуються для перевірки досяжності вилучених вузлів мережі і виміри часу проходження даних. <br /> <br /> '''''Вичерпано час життя''''' <br /> ICMP-пакет даного типу посилається джерелу IP-сегмента, що повинний бути скинутий по одній із двох причин: <br /> 1) вичерпаний час життя IP-сегмента; <br /> 2) вичерпаний припустимий час на зборку фрагментированного IP-сегмента. <br /> <br /> '''''Невірний параметр''''' <br /> За допомогою ICMP-пакета даного типу джерело IP-сегмента інформується про те, що даний сегмент скинутий унаслідок наявності помилки в якому-небудь з полів його заголовка<br /> <br /> <br /> <br /> [[TCP/IP]]<br /> [[category:Комп'ютерні мережі]]</div>

Hiss https://wiki.cusu.edu.ua/index.php/HTTP 2008-12-24T09:50:28Z

<p>Hiss: </p> <hr /> <div>Протокол '''HTTP''' (Hypertext Transfer Protocol, протокол передачі гіпертекстів) — це протокол прикладного рівня для розподілених гіпертекстових інформаційних систем. Крім передачі гіпертекстів він може застосовуватися й в інших областях, таких, як сервери імен і розподілені системи керування об'єктами, але для наших цілей важливо те, що на цьому протоколі з моменту своєї появи в 1990 р. і донині базується World Wide Web. Приведений нижче короткий його опис заснований на специфікації HTTP/1.1 (RFC 2616 , червень 1999 р.).<br /> <br /> HTTP є протоколом типу запит/відгук. Клієнт посилає серверу запит, що складається з типу запиту, URI і версії протоколу, за яких випливає повідомлення, що містить модифікатори запиту, клієнтську інформацію і, можливо, тіло запиту. Сервер відповідає рядком стану, що містить версію протоколу і код стану, за якою слідує повідомлення, що містить серверну інформацію, метаінформацію і, можливо, тіло повідомлення.<br /> <br /> У дійсності, ситуація звичайно є більш складною через участь у процесі обміну інформацією посередників між клієнтом і сервером. Існують три таких посередники: '''''проксі-сервер, шлюз і тунель''''':<br /> <br /> Проксі-сервер (або сервер повноважень) приймає запит клієнта, включаючи повний URI, переписує все повідомлення або частину його і передає виправлений запит серверу, зазначеному в URI.<br /> <br /> Шлюз розташовується над сервером і при необхідності транслює запити до протоколу більш низького рівня, підтримуваний сервером.<br /> <br /> Тунель не змінює переданих повідомлень, а використовується при передачі даних через посередника типу брандмауера (firewall).<br /> <br /> <br /> '''Переваги'''<br /> <br /> ''Простота'' – протокол настільки простий у реалізації, що дозволяє з легкістю створювати не тільки клієнтські додатки, але і примітивні сервери.<br /> <br /> ''Розширюваність'' - ви можете легко розширювати можливості протоколу завдяки упровадженню своїх власних заголовків, зберігаючи сумісність з іншими клієнтами і серверами. Вони будуть ігнорувати невідомі їм заголовки, але при цьому ви можете одержати необхідний вам функціонал при рішенні специфічної задачі.<br /> <br /> ''Поширеність'' - при виборі протоколу HTTP для рішення конкретних задач немаловажним фактором є його поширеність. Як наслідок, цей багато різної документації по протоколу на багатьох мовах світу, вставка зручних у використанні засобів розробки в популярні IDE, підтримка протоколу як клієнта багатьма програмами і великий вибір серед хостингових компаній із серверами HTTP.<br /> <br /> '''Недоліки і проблеми'''<br /> <br /> ''Великий розмір повідомлень'' - використання текстового формату в протоколі породжує відповідний недолік: великий розмір повідомлень у порівнянні з передачею двійкових даних. Через це зростає навантаження на устаткування при формуванні, обробці і передачі повідомлень. Для розв’язанна даної проблеми до протоколу вбудовані засоби для забезпечення кешування на стороні клієнта, а також засобу компресії переданого контенту. Нормативними документами по протоколі передбачена наявність проксі-серверів, що дозволяють клієнту одержати документ із найбільш близького до нього сервера. Також до протоколу було впроваджене дельта-кодування, щоб клієнту передавався не весь документ, а тільки його змінена частина.<br /> <br /> ''Відсутність «навігації»'' - хоча протокол розроблявся як засіб роботи з ресурсами сервера, у нього відсутні в явному виді засоби навігації серед цих ресурсів. Наприклад, клієнт не може явно запросити список доступних файлів, як у протоколі FTP. Передбачалося, що кінцевий користувач уже знає URI необхідного йому документа, закачавши який, він буде робити навігацію завдяки гіперпосиланням. Це цілком нормально і зручно для людини, але важко, коли стоять задачі автоматичної обробки й аналізу всіх ресурсів сервера без участі людини. Рішення цієї проблеми лежить цілком на плечах розробників додатків, що використовують даний протокол.<br /> <br /> ''Нема підтримки розподіленості'' - протокол HTTP розроблявся для рішення типових побутових задач де сам по собі час обробки запиту повинен забирати незначний час або взагалі не прийматися в розрахунок. Але в промисловому використанні із застосуванням розподілених обчислень при високих навантаженнях на сервер протокол HTTP виявляється безпомічний. У 1998 році W3C запропонував альтернативний протокол HTTP-NG (англ. HTTP Next Generation) для повної заміни застарілого з акцентуванням уваги саме на цій області. Ідею його необхідності підтримали великі фахівці з розподілених обчислень, але даний протокол дотепер перебуває в стадії розробки.<br /> <br /> '''''Структура протоколу'''''<br /> <br /> Кожне HTTP-повідомлення складається з трьох частин, що передаються в зазначеному порядку:<br /> <br /> - Стартовий рядок (англ. Starting line) — визначає тип повідомлення;<br /> <br /> - Заголовки (англ. Headers) — характеризують тіло повідомлення, параметри передачі та інші дані;<br /> <br /> - Тіло повідомлення (англ. Message Body) — безпосередньо даного повідомлення. Обов'язково повинно відокремлювати від заголовків порожнім рядком.<br /> <br /> Заголовки і тіло повідомлення можуть бути відсутні, але стартовий рядок є обов'язковим елементом, тому що вказує на тип запиту/відповіді. Виключенням є версія 0.9 протоколу, у якої повідомлення запиту містить тільки стартовий рядок, а повідомлення відповіді тільки тіло повідомлення.<br /> <br /> <br /> <br /> [[TCP/IP]]<br /> [[category:Комп'ютерні мережі]]</div>

Hiss https://wiki.cusu.edu.ua/index.php/FTP 2008-12-24T09:50:05Z

<p>Hiss: </p> <hr /> <div>FTP (RFC-959) забезпечує файловий обмін між віддаленими користувачами. Протокол FTP формувався багато років. Перші реалізації в МТИ відносяться до 1971. (RFC 114 і 141). RFC 172 розглядає протокол, орієнтований на користувача, і призначений для передачі файлів між ЕОМ. Пізніше в документах RFC 265 і RFC 281 протокол був удосконалений. Помітній переробці протокол піддався в 1973, і остаточний вигдяд він знайшов у 1985 році. Таким чином, даний протокол є одним з найстарших.<br /> Для реалізації обміну між двома персональними ЕОМ у межах мережі (програмні пакети PCTCP, і т.д.) можна резидентно завантажити FTPSRV або іншу еквівалентну програму. Також як і у випадку TELNET необхідна ідентифікація, але багато депозитаріїв допускають анонімний вхід (ім'я користувача ANONYMOUS, RFC-1635), що не вимагає слова пропуску (пароля) або допускає уведення вашої поштової адреси замість нього <br /> <br /> Робота FTP на користувацькому рівні містить кілька етапів:<br /> <br /> 1. Ідентифікація (введення імені-ідентифікатора і пароля).<br /> 2. Вибір каталогу.<br /> 3. Визначення режиму обміну (поблочний, потоковий, ASCII або двійковий).<br /> 4. Виконання команд обміну (get, mget, dir, mdel, mput або put).<br /> 5. Завершення процедури (quit або close).<br /> <br /> FTP досить незвичайна процедура, тому що підтримує два логічні зв'язки між ЕОМ. Один зв'язок служить для віддаленого доступу і використовує протокол Telnet. Інший зв'язок призначений для обміну даними. Сервер робить операцію passive open для порту 21 і чекає з'єднання з клієнтом. Клієнт здійснює операцію active open для порту 21. Канал залишається активним до завершення процедури FTP. TOS (тип IP-сервісу) відповідає мінімуму затримки, тому що цей канал використовується для ручного введення команд. Канал для передачі даних (TCP) формується щораз для пересилання файлів. Канал відкривається перед початком пересилання і закривається по коду end_of_file (кінець файлу). IP-тип сервісу (TOS) у цьому випадку орієнтований на максимальну пропускну здатність.<br /> <br /> Кінцевий користувач взаємодіє з протокольним інтерпретатором, у задачі якого входить керування обміном інформацією між користувачем і файловою системою, як місцевої, так і вилученої. Схема взаємодії різних частин Internet при роботі FTP зображена на мал. нижче<br /> <br /> &lt;center&gt;[[Image:FTP.jpg]]&lt;/center&gt;<br /> <br /> Спочатку по запиту клієнта формується канал керування, що надалі використовується для передачі команд від клієнта і відгуків від сервера. Інформаційний канал формується сервером по команді клієнта, він не повинний існувати постійно протягом усієї FTP-сесії і може формуватися і ліквідуватися в міру необхідності. Канал керування може бути закритий тільки після завершення інформаційного обміну. Для каналу керування використовується протокол Telnet. Після того як керуючий канал сформований, клієнт може посилати по ньому команди. Сервер сприймає, інтерпретує ці команди і передає відгуки.<br /> <br /> Можлива й інша схема взаємодії, коли з ініціативи клієнта здійснюється файловий обмін між двома ЕОМ, жодна з яких не є машиною клієнта.<br /> <br /> &lt;center&gt;[[Image:FTP2.gif]]&lt;/center&gt;<br /> <br /> На фазі завдання режиму обміну надаються наступні можливості:<br /> - Команда Block зберігає структуру логічних записів файлу.<br /> - Команда Stream встановлює режим, при якому не виробляється пересилання контрольної інформації для блоків. Це найбільш швидкий режим обміну, він працює за замовчуванням.<br /> - Команда TYPE може задати режими обміну IMAGE, ASCII або EBCDIC. З них ASCII - використовується за замовчуванням. Режим EBCDIC застосовується для обмінів між ЕОМ, що працюють з набором символів EBCDIC. Режим IMAGE припускає обмін 8-бітними байтами, використовується для передачі двійкової (а не текстової) інформації. Структурно інформація може передаватися у вигляді файлів (структура за замовчуванням), у вигляді послідовності записів (застосовно для текстових файлів ASCII або EBCDIC) або посторінково (остання структура не відноситься до числа що рекомендуються).<br /> <br /> Для копіювання файлу з віддаленого сервера використовується команда GET, для копіювання групи файлів - MGET, в останньому випадку застосовуються символи замінники, наприклад, MGET *.txt (або RFC-18*.txt, при цьому копіюються файли з RFC-1800.txt до RFC-1899.txt, якщо такі існують у поточному каталозі). Аналогом команди GET в якійсь мірі є команда DIR (ls), тільки вона переносить вміст каталогу, що для деяких операційних систем еквівалентно. При використанні модифікації mget виявляйте обережність - ви можете заблокувати телекомунікаційний канал тривалим копіюванням. Для запису файлу у віддалений сервер застосовується команда PUT. При операціях обміну звичайно використовується поточний каталог локальної ЕОМ. У вашому розпорядженні завжди мається можливість поміняти місцевий каталог за допомогою команди LCD або її аналога.<br /> Будь-яка команда обміну виконується в кілька етапів:<br /> - Формування каналу під керуванням клієнта, тому що саме клієнт видав команду get, dir, put і т.д.<br /> - Клієнт вибирає довільний номер порту на своєї ЕОМ і здійснює процедуру passive open для цього порту.<br /> - Клієнт посилає номер порту серверу по каналу керування (порт 21), використовуючи команду PORT. Можна обійтися і без команди PORT (використовується той же порт, що й у командному каналі), але це збільшує затримки і з цієї причини не рекомендується.<br /> - Сервер одержує номер порту по каналу керування і видає команду active open у зазначений порт Еом-клієнта. Сервер для каналу даних завжди використовує порт із номером 20.<br /> <br /> <br /> <br /> [[TCP/IP]]<br /> [[category:Комп'ютерні мережі]]</div>

Hiss https://wiki.cusu.edu.ua/index.php/DNS 2008-12-24T09:49:45Z

<p>Hiss: </p> <hr /> <div>Протокол '''DNS''' (Domain Name Service - служба доменних імен) забезпечує пошук імен хостыв, використовуючи розподілену по мережних серверах імен базу даних.<br /> <br /> Протокол DNS виконує дві основні ''функції''. Він дозволяє клієнтським комп'ютерам запитувати DNS-сервер про IP-адресу або ім'я якого-небудь хоста в мережі, а також дозволяє робити обмін інформацією між базами даних серверів DNS. У цьому протоколі використовується стандартний формат типу &quot;запит-відповідь&quot;, де клієнт посилає пакет запиту, і сервер відповідає або пакетом з інформацією, отриманоюз бази даних, або повідомленням про помилку, у якому вказується причина відмови в обробці запиту. У своїй роботі цей протокол використовує порт 53 і добре відомі протоколи — TCP або UDP. Причому останнім часом UDP став більш розповсюдженим методом транспортування пакетів по мережі Internet. Пакет DNS складається з п'яти полів: заголовка, питання, відповіді, повноважень і поля додаткової інформації.<br /> <br /> Формат повідомлень DNS показаний на малюнку.<br /> &lt;center&gt;[[Image:DNS.jpg]]&lt;/center&gt;<br /> <br /> '''''Ідентифікатор''''' - 16-бітове поле для позначення відповідності між запитами і відгуками.<br /> <br /> '''''Q''''' - 1-бітовий прапор запиту (query).<br /> <br /> '''''Запит''''' - 4-бітовий опис типу повідомлення:<br /> 0 стандартний запит (адреса по імені).<br /> 1 зворотний запит (ім'я за адресою).<br /> 2 запит стану сервера.<br /> <br /> '''''A (Authoritative Answer)''''' - 1-бітовий прапор, що показує відгук від уповноваженого (authoritative) сервера імен.<br /> <br /> '''''T (Truncation)''''' - відкидання. 1-бітовий прапор, що говорить про відкидання повідомлення.<br /> <br /> '''''R''''' - 1-бітовий прапор, який встановлюэться для дозволу запиту рекурсивним шляхом.<br /> <br /> '''''V''''' - 1-бітовий прапор підтримки рекурсивного сервісу.<br /> <br /> '''''B''''' - 3-бітове поле, зарезервоване для використання в майбутньому (0).<br /> <br /> '''''Rcode''''' -<br /> Код відгуку - 4-бітове поле, що встановлюэться сервером імен для позначення стану запиту:<br /> 0 немає помилок.<br /> 1 неможливо інтерпретувати запит через формальну помилку. <br /> 2 обробка неможлива через збій на сервері. <br /> 3 запитане ім'я не існує. <br /> 4 непідтримуваний тип запиту. <br /> 5 відмова від виконання запиту.<br /> <br /> '''''Лічильник питань''''' - 16-бітове поле, що містить число записів у розділі питань.<br /> <br /> '''''Лічильник відповідей''''' - 16-бітове поле, що містить число записів про ресурси в розділі відповідей. <br /> <br /> '''''Лічильник Authority''''' - 16-бітове поле, що визначає число записів про ресурси сервера імен у розділі authority (повноваження).<br /> <br /> '''''Лічильник доповнень''''' - 16-бітове поле, що визначає число записів про ресурси сервера імен у додатковому розділі.<br /> <br /> <br /> <br /> [[TCP/IP]]<br /> [[category:Комп'ютерні мережі]]</div>

Hiss https://wiki.cusu.edu.ua/index.php/ARP 2008-12-24T09:49:21Z

<p>Hiss: </p> <hr /> <div>IP адреси мають яке-небудь значення лише в сімействі протоколів TCP/IP. Канальні рівні, такі як Ethernet або Token ring, мають власну схему адресації (в основному 48-бітні адреси); мережні рівні, у свою чергу, використовують ці канальні рівні. Мережа Ethernet, може бути використана різними мережними рівнями в той саме час. Комп'ютери, що використовують різні мережні протоколи, можуть знаходитися на тому самому фізичному кабелі. <br /> <br /> Коли фрейм Ethernet відправляється від одного хоста по локальній мережі до іншого, по його 48-бітный Ethernet адресі визначається, до якого інтерфейсу він повинен бути доставлений. Драйвер мережної плати ніколи не дивиться на IP адреси призначення в IP датаграмы. <br /> <br /> Іншими словами виникає необхідність встановити відповідність між двома різними формами адрес: 32-бітними IP адресами і яким-небудь типом адрес канального рівня. RFC 826 [Plummer 1982] - офіційна специфікація ARP. <br /> <br /> &lt;center&gt;[[Image:Arp1.jpg]]&lt;/center&gt;<br /> <br /> На малюнку показані: протокол визначення адреси (ARP - address resolution protocol) і зворотний протокол визначення адреси (RARP - reverse address resolution protocol).<br /> <br /> '''''ARP''''' надає динамічне зіставлення IP адрес і відповідних апаратних адрес. Ми використовуємо термін динамічне, тому що це відбувається автоматично і звичайно не залежить від використовуваних прикладних програм або волі системного адміністратора. <br /> <br /> ''RARP'', в основному, використовується системами без твердих дисків (бездискові робітники станції або X термінали), однак тут потрібна ручна конфігурація за участю системного адміністратора. <br /> <br /> '''Формат пакета ARP''' <br /> На малюнку показаний формат ARP запиту і формат ARP відгуку, у випадку використання Ethernet і IP адрес. (ARP можна використовувати в інших мереж, при цьому він здатний установлювати відповідність не тільки для IP адрес. Перші чотири поля, що слідують за полем типу фрейму, вказують на типи і розміри заключних чотирьох полів.)<br /> <br /> &lt;center&gt;[[Image:Arp2.jpg]]&lt;/center&gt;<br /> <br /> Два перших поля в Ethernet заголовку - ''поля джерела і призначення Ethernet''. Спеціальна адреса призначення Ethernet, що складається з усіх одиниць, означає широкомовну адреса. Фрейми з такою адресою будуть отримані всіма Ethernet інтерфейсами на кабелі. <br /> <br /> Двобайтовий ''тип фрейму'' (frame type) Ethernet вказує, дані якого типу, підуть слідом. Для ARP запиту або ARP відгуку це поле містить 0x0806. <br /> <br /> Вирази ''апаратний'' (hardware) і ''протокол'' (protocol) використовуються для опису полів у пакетах ARP. Наприклад, ARP запит запрошує апаратну адресу (у даному випадку Ethernet адреса) відповідну адресі протоколу (у даному випадку IP адреса).<br /> <br /> Поле ''hard type'' вказує на тип апаратної адреси. Для Ethernet це значення дорівнює одиниці. Prot type указує тип адреси протоколу, до якого буде приведена відповідність. Для IP адрес використовується значення 0x0800. По своєму цільовому призначенню це значення відповідає полю типу у фреймі Ethernet, що містить IP датаграмму.<br /> <br /> Два наступних однобайтних поля, ''hard size'' і ''prot size'', указують на розміри в байтах апаратної адреси й адреси протоколу. У ARP запитах і відгуках вони складають 6 для Ethernet і 4 для IP адреси.<br /> <br /> Поле ''op'' указує на тип операції: ARP запит (значення встановлюється в 1), ARP відгук (2), RARP запит (3) і RARP відгук (4). Це поле необхідне, тому що поля типу фрейму (frame type) однакові для ARP запиту і ARP відгуку. <br /> <br /> Наступні чотири поля: ''апаратна адреса відправника'' (Ethernet адреса в даному прикладі), ''адреса протоколу'' (IP адреса), ''апаратна адреса призначення'' й ''адреса протоколу призначення''. Зверніть увагу, що в даному випадку відбувається деяке дублювання інформації: апаратна адреса відправника може бути отримана як з Ethernet заголовка, так і з ARP запиту. <br /> <br /> Для ARP запиту всі поля заповнені, за винятком апаратної адреси призначення. Коли система одержує ARP запит, що призначається їй, вона вставляє свою апаратну адресу, змінює місцями адреси джерела і призначення, встановлює поле op у значення 2 і відправляє відгук.<br /> <br /> <br /> <br /> [[TCP/IP]]<br /> [[category:Комп'ютерні мережі]]</div>

Hiss https://wiki.cusu.edu.ua/index.php/%D0%9E%D1%81%D0%BD%D0%BE%D0%B2%D0%B8_TCP/IP 2008-12-24T09:49:06Z

<p>Hiss: </p> <hr /> <div>TCP/IP - це засіб для обміну інформацією між комп'ютерами, об'єднаними в мережу. Не має значення, чи складають вони частину однієї і тієї ж мережі або підключені до окремих мереж. Не грає ролі і те, що один з них може бути комп'ютером Cray, а інший Macintosh. TCP/IP - це не залежний від платформи стандарт, що перекидає мости через прірву, що лежить між різнорідними комп'ютерами, операційними системами і мережами. Це протокол, що глобально керує Internet, і значною мірою завдяки мережі TCP/IP завоював свою популярність. <br /> <br /> Розуміння TCP/IP головним чином має на увазі здатність розбиратися в наборах таємничих протоколів, що використовуються головними комп'ютерами TCP/IP для обміну інформацією. <br /> '''''TCP/IP''''' – це абревіатура терміна Transmission Control Protocol/Internet Protocol (Протокол керування передачею/Протокол Internet). У термінології обчислювальних мереж ''протокол'' – це заздалегідь погоджений стандарт, що дозволяє двом комп'ютерам обмінюватися даними. Фактично TCP/IP не один протокол, а декілька. Саме тому ви часто чуєте, як його називають набором, або комплектом протоколів, серед яких TCP і IP - два основних. <br /> <br /> Програмне забезпечення для TCP/IP, на комп'ютері, являє собою специфічну для даної платформи реалізацію TCP, IP і інших членів сімейства TCP/IP. Звичайно в ньому також маються такі високорівневі прикладні програми, як FTP (File Transfer Protocol, Протокол передачі файлів), що дають можливість через командний рядок керувати обміном файлами по мережі. <br /> <br /> Причина, по якій TCP/IP настільки важливий сьогодні, полягає в тому, що він дозволяє самостійним мережам підключатися до Internet або поєднуватися для створення часток інтрамереж. Обчислювальні мережі, що складають інтрамережу, фізично підключаються через пристрої, що називаються маршрутизаторами або IP-маршрутизаторами. ''Маршрутизатор'' - це комп'ютер, що передає пакети даних з однієї мережі в іншу. В інтрамережі, що працює на основі TCP/IP, інформація передається у виді дискретних блоків, що називаються IP-пакетами (IP packets) або IP-дейтаграмами (IP datagrams). Завдяки програмному забезпеченню TCP/IP усі комп'ютери, підключені до обчислювальної мережі, стають &quot;близькими родичами&quot;. Власне кажучи воно ховає маршрутизатори і базову архітектуру мереж і робить так, що все це виглядає як одна велика мережа. Точно так само, як підключення до мережі Ethernet розпізнаються по 48-розрядних ідентифікаторах Ethernet, підключення до інтрамережі ідентифікуються 32-розрядними IP-адресами, що ми виражаємо у формі десяткових чисел, розділених крапками (наприклад, 128.10.2.3). Узявши IP-адресу вилученого комп'ютера, комп'ютер в інтрамережі або в Internet може відправити дані на нього, начебто вони складають частину однієї і тієї ж фізичної мережі. <br /> <br /> TCP/IP дає рішення проблеми обміну даними між двома комп'ютерами, підключеними до одній і тієї ж інтрамережі, але приналежним різним фізичним мережам. Рішення складається з декількох частин, причому кожен член сімейства протоколів TCP/IP вносить свою лепту в загальну справу.<br /> <br /> <br /> <br /> [[TCP/IP]]<br /> [[category:Комп'ютерні мережі]]</div>

Hiss https://wiki.cusu.edu.ua/index.php/ATM 2008-12-24T09:48:39Z

<p>Hiss: </p> <hr /> <div>'''''Асинхронний режим передачі даних''''' (Asynchronous Transfer Mode, ATM) - універсальна транспортна мережа для передачі неоднорідного трафіка: даних, голосу і відео. <br /> <br /> Слово ''асинхронний'' у назві означає, що тактові генератори передавача і приймача не синхронізовані, а самі комірки передаються і мультиплексуються по запитах. При мультиплексуванні використовується статистична технологія. Асинхронна передача не припускає впорядкування комірок по каналах при пересиланні. ATM підтримує апаратну і пакетну комутацію.<br /> <br /> Протокол ATM розбиває весь трафік на пакети строго фіксованої довжини (їх називають комірками), що асинхронно мультиплексуються в єдиний цифровий тракт відповідно до привласненого пріоритету. Завдяки малій довжині кмірок (53 байта, з них 48 байт несуть корисну інформацію, а комірка АТМ у випадку транспортування голосових даних відповідає 6 мс звучання), можна організувати одночасну передачу потоку даних відразу декількох служб, критичних вчасно доставки – комірки з даними різних додатків будуть вставлятися в потік поперемінно, забезпечуючи кожному додатку необхідну швидкість обміну даними. <br /> У залежності від обсягу трафіка можуть бути організовані ATM-канали зі швидкістю передачі від 1,5 Мб/c до 40 Гб/c, при цьому дана технологія дозволяє уникати простою каналів.<br /> <br /> Протокол ATM виконує комутацію за номером віртуального з'єднання, який у технології ATM розбитий на дві частини - ідентифікатор віртуального шляху (VPI) і ідентифікатор віртуального канала (VCL). Крім цієї основної задачі протокол ATM виконує ряд функцій по контролю за дотриманням трафік-контракту з боку користувача мережі, маркуванню осередків-порушників, відкиданню осередків-порушників при перевантаженні мережі, а також керуванню потоком осередків для підвищення продуктивності мережі (природно, при дотриманні умов трафік-контракта для усіх віртуальних з'єднань). Протокол ATM працює з комірками наступного формату, представленого на малюнку 2.3.<br /> <br /> &lt;center&gt;[[Image:ATM.jpg]]&lt;/center&gt;<br /> <br /> Поле ''Керування потоком'' (Generic Flow Control) використовується тільки при взаємодії кінцевого вузла і першого комутатора мережі. В даний час його точні функції не визначені.<br /> <br /> Поля ''Ідентифікатор віртуального шляху'' (Virtual Path Identifier, VPI) і ''Ідентифікатор віртуального каналу'' (Vitual Channel Identifier, VCI) займають відповідно 1 і 2 байти. Ці поля задають номер віртуального з'єднання, розділений на старшу (VPI) і молодшу (VCI) частини.<br /> <br /> Поле ''Ідентифікатор типу даних'' (Payload Type Identifier, РTI) складається з 3-х біт і задає тип даних, що переносяться коміркою, користувацькі або керуючі (наприклад, керуючі встановленням віртуального з'єднання). Крім того, один біт цього поля використовується для вказівки перевантаження в мережі - він називається Explicit Congestion Forward Identifier (ECFI) - і передає інформацію про перевантаження але напрямок потоку даних.<br /> <br /> У полі ''Пріоритет втрати кадру'' (Cell Loss Priority, CLP) комутатори ATM відзначають комірки, що порушують угоди про параметри якості обслуговування, щоб видалити їх при перевантаженнях мережі. Таким чином, осередку з CLP-0 є для мережі високопріоритетними, а з комірки CLP-1 - низькопріоритетними.<br /> <br /> Поле ''Керування помилками в заголовку''(Header Error Control, НЕС) містить контрольну суму, обчислену для заголовка комірки. Контрольна сума обчислюється за допомогою техніки коригувальних кодів Хэммінга, тому вона дозволяє не тільки виявляти помилки, але і виправляти всі одиночні помилки, а також деякі подвійні. Поле НЕС забезпечує не тільки виявлення і виправлення помилок у заголовку, але і перебування границі початку кадру в потоці байтів кадрів, що є кращим фізичним рівнем технології ATM, або ж у потоці біт фізичного рівня, заснованого на комірках. Комутатор ATM обчислює контрольну суму для послідовності з 5 байт, що знаходяться в поле даних кадру CTM-N, і, якщо обчислена контрольна сума говорить про коректність заголовка комірки ATM, перший байт стає границею комірки. Якщо ж це не так, то відбувається зрушення на один байт і операція продовжується. Таким чином, технологія ATM виділяє асинхронний потік комірок ATM у потоці біт фізичного рівня, заснованого на комірках.<br /> <br /> Розглянемо методи комутації комірок ATM на основі пари чисел VPI/VCI. Комутатори ATM можуть працювати в двох режимах - комутації віртуального шляху і комутації віртуального каналу. У першому режимі комутатор виконує просування комірки тільки на підставі значення поля VPI, а значення поля VCI він ігнорує. Вони доставляють комірки з однієї мережі користувача в іншу на підставі тільки старшої частини номера віртуального каналу. У результаті один віртуальний шлях відповідає цілому набору віртуальних каналів, що комутуються як єдине ціле.<br /> <br /> Після доставки комірки в локальну мережу ATM її комутатори починають комутувати осередку із врахуванням як VPI, так і VCI, але при цьому їм вистачає для комутації тільки молодшої частини номера віртуального з'єднання, так що фактично вони працюють з VCI, залишаючи VPI без зміни. Останній режим називається режимом комутації віртуального каналу.<br /> <br /> Інформація взята з http://rfcmd.ru/book_07/h2_7<br /> <br /> <br /> <br /> [[TCP/IP]]<br /> [[category:Комп'ютерні мережі]]</div>

Hiss https://wiki.cusu.edu.ua/index.php/ATM 2008-12-24T09:48:15Z

<p>Hiss: </p> <hr /> <div>'''''Асинхронний режим передачі даних''''' (Asynchronous Transfer Mode, ATM) - універсальна транспортна мережа для передачі неоднорідного трафіка: даних, голосу і відео. <br /> <br /> Слово ''асинхронний'' у назві означає, що тактові генератори передавача і приймача не синхронізовані, а самі комірки передаються і мультиплексуються по запитах. При мультиплексуванні використовується статистична технологія. Асинхронна передача не припускає впорядкування комірок по каналах при пересиланні. ATM підтримує апаратну і пакетну комутацію.<br /> <br /> Протокол ATM розбиває весь трафік на пакети строго фіксованої довжини (їх називають комірками), що асинхронно мультиплексуються в єдиний цифровий тракт відповідно до привласненого пріоритету. Завдяки малій довжині кмірок (53 байта, з них 48 байт несуть корисну інформацію, а комірка АТМ у випадку транспортування голосових даних відповідає 6 мс звучання), можна організувати одночасну передачу потоку даних відразу декількох служб, критичних вчасно доставки – комірки з даними різних додатків будуть вставлятися в потік поперемінно, забезпечуючи кожному додатку необхідну швидкість обміну даними. <br /> У залежності від обсягу трафіка можуть бути організовані ATM-канали зі швидкістю передачі від 1,5 Мб/c до 40 Гб/c, при цьому дана технологія дозволяє уникати простою каналів.<br /> <br /> Протокол ATM виконує комутацію за номером віртуального з'єднання, який у технології ATM розбитий на дві частини - ідентифікатор віртуального шляху (VPI) і ідентифікатор віртуального канала (VCL). Крім цієї основної задачі протокол ATM виконує ряд функцій по контролю за дотриманням трафік-контракту з боку користувача мережі, маркуванню осередків-порушників, відкиданню осередків-порушників при перевантаженні мережі, а також керуванню потоком осередків для підвищення продуктивності мережі (природно, при дотриманні умов трафік-контракта для усіх віртуальних з'єднань). Протокол ATM працює з комірками наступного формату, представленого на малюнку 2.3.<br /> <br /> &lt;center&gt;[[Image:ATM.jpg]]&lt;/center&gt;<br /> <br /> Поле ''Керування потоком'' (Generic Flow Control) використовується тільки при взаємодії кінцевого вузла і першого комутатора мережі. В даний час його точні функції не визначені.<br /> <br /> Поля ''Ідентифікатор віртуального шляху'' (Virtual Path Identifier, VPI) і ''Ідентифікатор віртуального каналу'' (Vitual Channel Identifier, VCI) займають відповідно 1 і 2 байти. Ці поля задають номер віртуального з'єднання, розділений на старшу (VPI) і молодшу (VCI) частини.<br /> <br /> Поле ''Ідентифікатор типу даних'' (Payload Type Identifier, РTI) складається з 3-х біт і задає тип даних, що переносяться коміркою, користувацькі або керуючі (наприклад, керуючі встановленням віртуального з'єднання). Крім того, один біт цього поля використовується для вказівки перевантаження в мережі - він називається Explicit Congestion Forward Identifier (ECFI) - і передає інформацію про перевантаження але напрямок потоку даних.<br /> <br /> У полі ''Пріоритет втрати кадру'' (Cell Loss Priority, CLP) комутатори ATM відзначають комірки, що порушують угоди про параметри якості обслуговування, щоб видалити їх при перевантаженнях мережі. Таким чином, осередку з CLP-0 є для мережі високопріоритетними, а з комірки CLP-1 - низькопріоритетними.<br /> <br /> Поле ''Керування помилками в заголовку''(Header Error Control, НЕС) містить контрольну суму, обчислену для заголовка комірки. Контрольна сума обчислюється за допомогою техніки коригувальних кодів Хэммінга, тому вона дозволяє не тільки виявляти помилки, але і виправляти всі одиночні помилки, а також деякі подвійні. Поле НЕС забезпечує не тільки виявлення і виправлення помилок у заголовку, але і перебування границі початку кадру в потоці байтів кадрів, що є кращим фізичним рівнем технології ATM, або ж у потоці біт фізичного рівня, заснованого на комірках. Комутатор ATM обчислює контрольну суму для послідовності з 5 байт, що знаходяться в поле даних кадру CTM-N, і, якщо обчислена контрольна сума говорить про коректність заголовка комірки ATM, перший байт стає границею комірки. Якщо ж це не так, то відбувається зрушення на один байт і операція продовжується. Таким чином, технологія ATM виділяє асинхронний потік комірок ATM у потоці біт фізичного рівня, заснованого на комірках.<br /> <br /> Розглянемо методи комутації комірок ATM на основі пари чисел VPI/VCI. Комутатори ATM можуть працювати в двох режимах - комутації віртуального шляху і комутації віртуального каналу. У першому режимі комутатор виконує просування комірки тільки на підставі значення поля VPI, а значення поля VCI він ігнорує. Вони доставляють комірки з однієї мережі користувача в іншу на підставі тільки старшої частини номера віртуального каналу. У результаті один віртуальний шлях відповідає цілому набору віртуальних каналів, що комутуються як єдине ціле.<br /> <br /> Після доставки комірки в локальну мережу ATM її комутатори починають комутувати осередку із врахуванням як VPI, так і VCI, але при цьому їм вистачає для комутації тільки молодшої частини номера віртуального з'єднання, так що фактично вони працюють з VCI, залишаючи VPI без зміни. Останній режим називається режимом комутації віртуального каналу.<br /> <br /> Інформація взята з http://rfcmd.ru/book_07/h2_7<br /> <br /> [[TCP/IP]]<br /> [[category:Комп'ютерні мережі]]</div>

Hiss https://wiki.cusu.edu.ua/index.php/ARP 2008-12-24T09:47:43Z

<p>Hiss: </p> <hr /> <div>IP адреси мають яке-небудь значення лише в сімействі протоколів TCP/IP. Канальні рівні, такі як Ethernet або Token ring, мають власну схему адресації (в основному 48-бітні адреси); мережні рівні, у свою чергу, використовують ці канальні рівні. Мережа Ethernet, може бути використана різними мережними рівнями в той саме час. Комп'ютери, що використовують різні мережні протоколи, можуть знаходитися на тому самому фізичному кабелі. <br /> <br /> Коли фрейм Ethernet відправляється від одного хоста по локальній мережі до іншого, по його 48-бітный Ethernet адресі визначається, до якого інтерфейсу він повинен бути доставлений. Драйвер мережної плати ніколи не дивиться на IP адреси призначення в IP датаграмы. <br /> <br /> Іншими словами виникає необхідність встановити відповідність між двома різними формами адрес: 32-бітними IP адресами і яким-небудь типом адрес канального рівня. RFC 826 [Plummer 1982] - офіційна специфікація ARP. <br /> <br /> &lt;center&gt;[[Image:Arp1.jpg]]&lt;/center&gt;<br /> <br /> На малюнку показані: протокол визначення адреси (ARP - address resolution protocol) і зворотний протокол визначення адреси (RARP - reverse address resolution protocol).<br /> <br /> '''''ARP''''' надає динамічне зіставлення IP адрес і відповідних апаратних адрес. Ми використовуємо термін динамічне, тому що це відбувається автоматично і звичайно не залежить від використовуваних прикладних програм або волі системного адміністратора. <br /> <br /> ''RARP'', в основному, використовується системами без твердих дисків (бездискові робітники станції або X термінали), однак тут потрібна ручна конфігурація за участю системного адміністратора. <br /> <br /> '''Формат пакета ARP''' <br /> На малюнку показаний формат ARP запиту і формат ARP відгуку, у випадку використання Ethernet і IP адрес. (ARP можна використовувати в інших мереж, при цьому він здатний установлювати відповідність не тільки для IP адрес. Перші чотири поля, що слідують за полем типу фрейму, вказують на типи і розміри заключних чотирьох полів.)<br /> <br /> &lt;center&gt;[[Image:Arp2.jpg]]&lt;/center&gt;<br /> <br /> Два перших поля в Ethernet заголовку - ''поля джерела і призначення Ethernet''. Спеціальна адреса призначення Ethernet, що складається з усіх одиниць, означає широкомовну адреса. Фрейми з такою адресою будуть отримані всіма Ethernet інтерфейсами на кабелі. <br /> <br /> Двобайтовий ''тип фрейму'' (frame type) Ethernet вказує, дані якого типу, підуть слідом. Для ARP запиту або ARP відгуку це поле містить 0x0806. <br /> <br /> Вирази ''апаратний'' (hardware) і ''протокол'' (protocol) використовуються для опису полів у пакетах ARP. Наприклад, ARP запит запрошує апаратну адресу (у даному випадку Ethernet адреса) відповідну адресі протоколу (у даному випадку IP адреса).<br /> <br /> Поле ''hard type'' вказує на тип апаратної адреси. Для Ethernet це значення дорівнює одиниці. Prot type указує тип адреси протоколу, до якого буде приведена відповідність. Для IP адрес використовується значення 0x0800. По своєму цільовому призначенню це значення відповідає полю типу у фреймі Ethernet, що містить IP датаграмму.<br /> <br /> Два наступних однобайтних поля, ''hard size'' і ''prot size'', указують на розміри в байтах апаратної адреси й адреси протоколу. У ARP запитах і відгуках вони складають 6 для Ethernet і 4 для IP адреси.<br /> <br /> Поле ''op'' указує на тип операції: ARP запит (значення встановлюється в 1), ARP відгук (2), RARP запит (3) і RARP відгук (4). Це поле необхідне, тому що поля типу фрейму (frame type) однакові для ARP запиту і ARP відгуку. <br /> <br /> Наступні чотири поля: ''апаратна адреса відправника'' (Ethernet адреса в даному прикладі), ''адреса протоколу'' (IP адреса), ''апаратна адреса призначення'' й ''адреса протоколу призначення''. Зверніть увагу, що в даному випадку відбувається деяке дублювання інформації: апаратна адреса відправника може бути отримана як з Ethernet заголовка, так і з ARP запиту. <br /> <br /> Для ARP запиту всі поля заповнені, за винятком апаратної адреси призначення. Коли система одержує ARP запит, що призначається їй, вона вставляє свою апаратну адресу, змінює місцями адреси джерела і призначення, встановлює поле op у значення 2 і відправляє відгук.<br /> <br /> [[TCP/IP]]<br /> [[category:Комп'ютерні мережі]]</div>

Hiss https://wiki.cusu.edu.ua/index.php/%D0%9E%D1%81%D0%BD%D0%BE%D0%B2%D0%B8_TCP/IP 2008-12-24T09:47:03Z

<p>Hiss: </p> <hr /> <div>TCP/IP - це засіб для обміну інформацією між комп'ютерами, об'єднаними в мережу. Не має значення, чи складають вони частину однієї і тієї ж мережі або підключені до окремих мереж. Не грає ролі і те, що один з них може бути комп'ютером Cray, а інший Macintosh. TCP/IP - це не залежний від платформи стандарт, що перекидає мости через прірву, що лежить між різнорідними комп'ютерами, операційними системами і мережами. Це протокол, що глобально керує Internet, і значною мірою завдяки мережі TCP/IP завоював свою популярність. <br /> <br /> Розуміння TCP/IP головним чином має на увазі здатність розбиратися в наборах таємничих протоколів, що використовуються головними комп'ютерами TCP/IP для обміну інформацією. <br /> '''''TCP/IP''''' – це абревіатура терміна Transmission Control Protocol/Internet Protocol (Протокол керування передачею/Протокол Internet). У термінології обчислювальних мереж ''протокол'' – це заздалегідь погоджений стандарт, що дозволяє двом комп'ютерам обмінюватися даними. Фактично TCP/IP не один протокол, а декілька. Саме тому ви часто чуєте, як його називають набором, або комплектом протоколів, серед яких TCP і IP - два основних. <br /> <br /> Програмне забезпечення для TCP/IP, на комп'ютері, являє собою специфічну для даної платформи реалізацію TCP, IP і інших членів сімейства TCP/IP. Звичайно в ньому також маються такі високорівневі прикладні програми, як FTP (File Transfer Protocol, Протокол передачі файлів), що дають можливість через командний рядок керувати обміном файлами по мережі. <br /> <br /> Причина, по якій TCP/IP настільки важливий сьогодні, полягає в тому, що він дозволяє самостійним мережам підключатися до Internet або поєднуватися для створення часток інтрамереж. Обчислювальні мережі, що складають інтрамережу, фізично підключаються через пристрої, що називаються маршрутизаторами або IP-маршрутизаторами. ''Маршрутизатор'' - це комп'ютер, що передає пакети даних з однієї мережі в іншу. В інтрамережі, що працює на основі TCP/IP, інформація передається у виді дискретних блоків, що називаються IP-пакетами (IP packets) або IP-дейтаграмами (IP datagrams). Завдяки програмному забезпеченню TCP/IP усі комп'ютери, підключені до обчислювальної мережі, стають &quot;близькими родичами&quot;. Власне кажучи воно ховає маршрутизатори і базову архітектуру мереж і робить так, що все це виглядає як одна велика мережа. Точно так само, як підключення до мережі Ethernet розпізнаються по 48-розрядних ідентифікаторах Ethernet, підключення до інтрамережі ідентифікуються 32-розрядними IP-адресами, що ми виражаємо у формі десяткових чисел, розділених крапками (наприклад, 128.10.2.3). Узявши IP-адресу вилученого комп'ютера, комп'ютер в інтрамережі або в Internet може відправити дані на нього, начебто вони складають частину однієї і тієї ж фізичної мережі. <br /> <br /> TCP/IP дає рішення проблеми обміну даними між двома комп'ютерами, підключеними до одній і тієї ж інтрамережі, але приналежним різним фізичним мережам. Рішення складається з декількох частин, причому кожен член сімейства протоколів TCP/IP вносить свою лепту в загальну справу.<br /> <br /> [[TCP/IP]]<br /> [[category:Комп'ютерні мережі]]</div>

Hiss https://wiki.cusu.edu.ua/index.php/%D0%92%D1%81%D1%82%D1%83%D0%BF_(TCP/IP) 2008-12-24T09:45:54Z

<p>Hiss: </p> <hr /> <div>Протоколи мережної взаємодії TCP/IP є результатом еволюційного розвитку протоколів глобальної обчислювальної мережі ARPANET. <br /> Роботи зі створення мережі ARPANET були розпочаті рядом університетів США і фірмою BBN у 1968 р. У 1971 р. мережа була введена в регулярну експлуатацію і забезпечувала для усіх своїх вузлів три основні послуги: <br /> · інтерактивний вхід користувача на вилучений вузол; <br /> · передача файлів між вузлами мережі; <br /> · електронна пошта. <br /> Усі ці засоби базувалися на транспортних послугах, наданих програмою керування мережі NCP (Network Control Program), що реалізує свій внутрішній набір протоколів. <br /> Накопичений до 1974 р. досвід експлуатації мережі ARPANET виявив багато недоліків протоколів NCP і дозволив визначити основні вимоги до нового набору протоколів, що отримали назву TCP/IP: <br /> · незалежність від середовища передачі повідомлень; <br /> · можливість підключення до мережі ЕОМ будь-якої архітектури; <br /> · єдиний спосіб організації з'єднання між вузлами в мережі; <br /> · стандартизація прикладних протоколів. <br /> Широко використовувана нині версія 4 протоколів TCP/IP була стандартизована в 1981 р. у вигляді документів, названих RFC (Request For Comment). Повний перехід мережі ARPANET на нові протоколи був завершений у 1982 р. Ця мережа зіграла роль &quot;зародка&quot; всесвітньої мережі Internet, побудованої на базі протоколів TCP/IP. <br /> Реалізація протоколів TCP/IP виявилася найбільш вдалою у версіях BSD4.2 і BSD4.3 операційної системи UNIX. Ця реалізація є еталоном (станартом &quot;de facto&quot;) для всіх наступних. <br /> <br /> <br /> [[TCP/IP]]<br /> [[category:Комп'ютерні мережі]]</div>

Hiss https://wiki.cusu.edu.ua/index.php/%D0%9E%D0%B1%D0%B3%D0%BE%D0%B2%D0%BE%D1%80%D0%B5%D0%BD%D0%BD%D1%8F:%D0%9C%D0%B5%D1%80%D0%B5%D0%B6%D1%96_3G 2008-12-24T09:41:23Z

<p>Hiss: </p> <hr /> <div>== Пропозиції та зауваження, щодо викладеного матеріалу. ==<br /> <br /> ----<br /> Велике побажання - вичитуйте текст та іноді користуйтеся перевіркою орфографії!!!! (перевірка працює і у Вікі)</div>

Hiss https://wiki.cusu.edu.ua/index.php/HTTP 2008-12-08T18:12:11Z

<p>Hiss: </p> <hr /> <div>Протокол '''HTTP''' (Hypertext Transfer Protocol, протокол передачі гіпертекстів) — це протокол прикладного рівня для розподілених гіпертекстових інформаційних систем. Крім передачі гіпертекстів він може застосовуватися й в інших областях, таких, як сервери імен і розподілені системи керування об'єктами, але для наших цілей важливо те, що на цьому протоколі з моменту своєї появи в 1990 р. і донині базується World Wide Web. Приведений нижче короткий його опис заснований на специфікації HTTP/1.1 (RFC 2616 , червень 1999 р.).<br /> <br /> HTTP є протоколом типу запит/відгук. Клієнт посилає серверу запит, що складається з типу запиту, URI і версії протоколу, за яких випливає повідомлення, що містить модифікатори запиту, клієнтську інформацію і, можливо, тіло запиту. Сервер відповідає рядком стану, що містить версію протоколу і код стану, за якою слідує повідомлення, що містить серверну інформацію, метаінформацію і, можливо, тіло повідомлення.<br /> <br /> У дійсності, ситуація звичайно є більш складною через участь у процесі обміну інформацією посередників між клієнтом і сервером. Існують три таких посередники: '''''проксі-сервер, шлюз і тунель''''':<br /> <br /> Проксі-сервер (або сервер повноважень) приймає запит клієнта, включаючи повний URI, переписує все повідомлення або частину його і передає виправлений запит серверу, зазначеному в URI.<br /> <br /> Шлюз розташовується над сервером і при необхідності транслює запити до протоколу більш низького рівня, підтримуваний сервером.<br /> <br /> Тунель не змінює переданих повідомлень, а використовується при передачі даних через посередника типу брандмауера (firewall).<br /> <br /> <br /> '''Переваги'''<br /> <br /> ''Простота'' – протокол настільки простий у реалізації, що дозволяє з легкістю створювати не тільки клієнтські додатки, але і примітивні сервери.<br /> <br /> ''Розширюваність'' - ви можете легко розширювати можливості протоколу завдяки упровадженню своїх власних заголовків, зберігаючи сумісність з іншими клієнтами і серверами. Вони будуть ігнорувати невідомі їм заголовки, але при цьому ви можете одержати необхідний вам функціонал при рішенні специфічної задачі.<br /> <br /> ''Поширеність'' - при виборі протоколу HTTP для рішення конкретних задач немаловажним фактором є його поширеність. Як наслідок, цей багато різної документації по протоколу на багатьох мовах світу, вставка зручних у використанні засобів розробки в популярні IDE, підтримка протоколу як клієнта багатьма програмами і великий вибір серед хостингових компаній із серверами HTTP.<br /> <br /> '''Недоліки і проблеми'''<br /> <br /> ''Великий розмір повідомлень'' - використання текстового формату в протоколі породжує відповідний недолік: великий розмір повідомлень у порівнянні з передачею двійкових даних. Через це зростає навантаження на устаткування при формуванні, обробці і передачі повідомлень. Для розв’язанна даної проблеми до протоколу вбудовані засоби для забезпечення кешування на стороні клієнта, а також засобу компресії переданого контенту. Нормативними документами по протоколі передбачена наявність проксі-серверів, що дозволяють клієнту одержати документ із найбільш близького до нього сервера. Також до протоколу було впроваджене дельта-кодування, щоб клієнту передавався не весь документ, а тільки його змінена частина.<br /> <br /> ''Відсутність «навігації»'' - хоча протокол розроблявся як засіб роботи з ресурсами сервера, у нього відсутні в явному виді засоби навігації серед цих ресурсів. Наприклад, клієнт не може явно запросити список доступних файлів, як у протоколі FTP. Передбачалося, що кінцевий користувач уже знає URI необхідного йому документа, закачавши який, він буде робити навігацію завдяки гіперпосиланням. Це цілком нормально і зручно для людини, але важко, коли стоять задачі автоматичної обробки й аналізу всіх ресурсів сервера без участі людини. Рішення цієї проблеми лежить цілком на плечах розробників додатків, що використовують даний протокол.<br /> <br /> ''Нема підтримки розподіленості'' - протокол HTTP розроблявся для рішення типових побутових задач де сам по собі час обробки запиту повинен забирати незначний час або взагалі не прийматися в розрахунок. Але в промисловому використанні із застосуванням розподілених обчислень при високих навантаженнях на сервер протокол HTTP виявляється безпомічний. У 1998 році W3C запропонував альтернативний протокол HTTP-NG (англ. HTTP Next Generation) для повної заміни застарілого з акцентуванням уваги саме на цій області. Ідею його необхідності підтримали великі фахівці з розподілених обчислень, але даний протокол дотепер перебуває в стадії розробки.<br /> <br /> '''''Структура протоколу'''''<br /> <br /> Кожне HTTP-повідомлення складається з трьох частин, що передаються в зазначеному порядку:<br /> <br /> - Стартовий рядок (англ. Starting line) — визначає тип повідомлення;<br /> <br /> - Заголовки (англ. Headers) — характеризують тіло повідомлення, параметри передачі та інші дані;<br /> <br /> - Тіло повідомлення (англ. Message Body) — безпосередньо даного повідомлення. Обов'язково повинно відокремлювати від заголовків порожнім рядком.<br /> <br /> Заголовки і тіло повідомлення можуть бути відсутні, але стартовий рядок є обов'язковим елементом, тому що вказує на тип запиту/відповіді. Виключенням є версія 0.9 протоколу, у якої повідомлення запиту містить тільки стартовий рядок, а повідомлення відповіді тільки тіло повідомлення.<br /> <br /> [[category:Комп'ютерні мережі]]</div>

Hiss https://wiki.cusu.edu.ua/index.php/HTTP 2008-12-08T18:11:55Z

<p>Hiss: </p> <hr /> <div>Протокол '''HTTP''' (Hypertext Transfer Protocol, протокол передачі гіпертекстів) — це протокол прикладного рівня для розподілених гіпертекстових інформаційних систем. Крім передачі гіпертекстів він може застосовуватися й в інших областях, таких, як сервери імен і розподілені системи керування об'єктами, але для наших цілей важливо те, що на цьому протоколі з моменту своєї появи в 1990 р. і донині базується World Wide Web. Приведений нижче короткий його опис заснований на специфікації HTTP/1.1 (RFC 2616 , червень 1999 р.).<br /> <br /> HTTP є протоколом типу запит/відгук. Клієнт посилає серверу запит, що складається з типу запиту, URI і версії протоколу, за яких випливає повідомлення, що містить модифікатори запиту, клієнтську інформацію і, можливо, тіло запиту. Сервер відповідає рядком стану, що містить версію протоколу і код стану, за якою слідує повідомлення, що містить серверну інформацію, метаінформацію і, можливо, тіло повідомлення.<br /> <br /> У дійсності, ситуація звичайно є більш складною через участь у процесі обміну інформацією посередників між клієнтом і сервером. Існують три таких посередники: '''''проксі-сервер, шлюз і тунель''''':<br /> <br /> Проксі-сервер (або сервер повноважень) приймає запит клієнта, включаючи повний URI, переписує все повідомлення або частину його і передає виправлений запит серверу, зазначеному в URI.<br /> <br /> Шлюз розташовується над сервером і при необхідності транслює запити до протоколу більш низького рівня, підтримуваний сервером.<br /> <br /> Тунель не змінює переданих повідомлень, а використовується при передачі даних через посередника типу брандмауера (firewall).<br /> <br /> <br /> '''Переваги'''<br /> <br /> ''Простота'' – протокол настільки простий у реалізації, що дозволяє з легкістю створювати не тільки клієнтські додатки, але і примітивні сервери.<br /> <br /> ''Розширюваність'' - ви можете легко розширювати можливості протоколу завдяки упровадженню своїх власних заголовків, зберігаючи сумісність з іншими клієнтами і серверами. Вони будуть ігнорувати невідомі їм заголовки, але при цьому ви можете одержати необхідний вам функціонал при рішенні специфічної задачі.<br /> <br /> ''Поширеність'' - при виборі протоколу HTTP для рішення конкретних задач немаловажним фактором є його поширеність. Як наслідок, цей багато різної документації по протоколу на багатьох мовах світу, вставка зручних у використанні засобів розробки в популярні IDE, підтримка протоколу як клієнта багатьма програмами і великий вибір серед хостингових компаній із серверами HTTP.<br /> <br /> '''Недоліки і проблеми'''<br /> <br /> ''Великий розмір повідомлень'' - використання текстового формату в протоколі породжує відповідний недолік: великий розмір повідомлень у порівнянні з передачею двійкових даних. Через це зростає навантаження на устаткування при формуванні, обробці і передачі повідомлень. Для розв’язанна даної проблеми до протоколу вбудовані засоби для забезпечення кешування на стороні клієнта, а також засобу компресії переданого контенту. Нормативними документами по протоколі передбачена наявність проксі-серверів, що дозволяють клієнту одержати документ із найбільш близького до нього сервера. Також до протоколу було впроваджене дельта-кодування, щоб клієнту передавався не весь документ, а тільки його змінена частина.<br /> <br /> ''Відсутність «навігації»'' - хоча протокол розроблявся як засіб роботи з ресурсами сервера, у нього відсутні в явному виді засоби навігації серед цих ресурсів. Наприклад, клієнт не може явно запросити список доступних файлів, як у протоколі FTP. Передбачалося, що кінцевий користувач уже знає URI необхідного йому документа, закачавши який, він буде робити навігацію завдяки гіперпосиланням. Це цілком нормально і зручно для людини, але важко, коли стоять задачі автоматичної обробки й аналізу всіх ресурсів сервера без участі людини. Рішення цієї проблеми лежить цілком на плечах розробників додатків, що використовують даний протокол.<br /> <br /> ''Нема підтримки розподіленості'' - протокол HTTP розроблявся для рішення типових побутових задач де сам по собі час обробки запиту повинен забирати незначний час або взагалі не прийматися в розрахунок. Але в промисловому використанні із застосуванням розподілених обчислень при високих навантаженнях на сервер протокол HTTP виявляється безпомічний. У 1998 році W3C запропонував альтернативний протокол HTTP-NG (англ. HTTP Next Generation) для повної заміни застарілого з акцентуванням уваги саме на цій області. Ідею його необхідності підтримали великі фахівці з розподілених обчислень, але даний протокол дотепер перебуває в стадії розробки.<br /> <br /> '''''Структура протоколу'''''<br /> <br /> Кожне HTTP-повідомлення складається з трьох частин, що передаються в зазначеному порядку:<br /> - Стартовий рядок (англ. Starting line) — визначає тип повідомлення;<br /> - Заголовки (англ. Headers) — характеризують тіло повідомлення, параметри передачі та інші дані;<br /> - Тіло повідомлення (англ. Message Body) — безпосередньо даного повідомлення. Обов'язково повинно відокремлювати від заголовків порожнім рядком.<br /> <br /> Заголовки і тіло повідомлення можуть бути відсутні, але стартовий рядок є обов'язковим елементом, тому що вказує на тип запиту/відповіді. Виключенням є версія 0.9 протоколу, у якої повідомлення запиту містить тільки стартовий рядок, а повідомлення відповіді тільки тіло повідомлення.<br /> <br /> [[category:Комп'ютерні мережі]]</div>

Hiss https://wiki.cusu.edu.ua/index.php/HTTP 2008-12-08T17:27:44Z

<p>Hiss: </p> <hr /> <div>Протокол '''HTTP''' (Hypertext Transfer Protocol, протокол передачі гіпертекстів) — це протокол прикладного рівня для розподілених гіпертекстових інформаційних систем. Крім передачі гіпертекстів він може застосовуватися й в інших областях, таких, як сервери імен і розподілені системи керування об'єктами, але для наших цілей важливо те, що на цьому протоколі з моменту своєї появи в 1990 р. і донині базується World Wide Web. Приведений нижче короткий його опис заснований на специфікації HTTP/1.1 (RFC 2616 , червень 1999 р.).<br /> <br /> HTTP є протоколом типу запит/відгук. Клієнт посилає серверу запит, що складається з типу запиту, URI і версії протоколу, за яких випливає повідомлення, що містить модифікатори запиту, клієнтську інформацію і, можливо, тіло запиту. Сервер відповідає рядком стану, що містить версію протоколу і код стану, за якою слідує повідомлення, що містить серверну інформацію, метаінформацію і, можливо, тіло повідомлення.<br /> <br /> У дійсності, ситуація звичайно є більш складною через участь у процесі обміну інформацією посередників між клієнтом і сервером. Існують три таких посередники: '''''проксі-сервер, шлюз і тунель''''':<br /> <br /> Проксі-сервер (або сервер повноважень) приймає запит клієнта, включаючи повний URI, переписує все повідомлення або частину його і передає виправлений запит серверу, зазначеному в URI.<br /> <br /> Шлюз розташовується над сервером і при необхідності транслює запити до протоколу більш низького рівня, підтримуваний сервером.<br /> <br /> Тунель не змінює переданих повідомлень, а використовується при передачі даних через посередника типу брандмауера (firewall).<br /> <br /> <br /> '''Переваги'''<br /> <br /> ''Простота'' – протокол настільки простий у реалізації, що дозволяє з легкістю створювати не тільки клієнтські додатки, але і примітивні сервери.<br /> <br /> ''Розширюваність'' - ви можете легко розширювати можливості протоколу завдяки упровадженню своїх власних заголовків, зберігаючи сумісність з іншими клієнтами і серверами. Вони будуть ігнорувати невідомі їм заголовки, але при цьому ви можете одержати необхідний вам функціонал при рішенні специфічної задачі.<br /> <br /> ''Поширеність'' - при виборі протоколу HTTP для рішення конкретних задач немаловажним фактором є його поширеність. Як наслідок, цей багато різної документації по протоколу на багатьох мовах світу, вставка зручних у використанні засобів розробки в популярні IDE, підтримка протоколу як клієнта багатьма програмами і великий вибір серед хостингових компаній із серверами HTTP.<br /> <br /> '''Недоліки і проблеми'''<br /> <br /> ''Великий розмір повідомлень'' - використання текстового формату в протоколі породжує відповідний недолік: великий розмір повідомлень у порівнянні з передачею двійкових даних. Через це зростає навантаження на устаткування при формуванні, обробці і передачі повідомлень. Для розв’язанна даної проблеми до протоколу вбудовані засоби для забезпечення кешування на стороні клієнта, а також засобу компресії переданого контенту. Нормативними документами по протоколі передбачена наявність проксі-серверів, що дозволяють клієнту одержати документ із найбільш близького до нього сервера. Також до протоколу було впроваджене дельта-кодування, щоб клієнту передавався не весь документ, а тільки його змінена частина.<br /> <br /> ''Відсутність «навігації»'' - хоча протокол розроблявся як засіб роботи з ресурсами сервера, у нього відсутні в явному виді засоби навігації серед цих ресурсів. Наприклад, клієнт не може явно запросити список доступних файлів, як у протоколі FTP. Передбачалося, що кінцевий користувач уже знає URI необхідного йому документа, закачавши який, він буде робити навігацію завдяки гіперпосиланням. Це цілком нормально і зручно для людини, але важко, коли стоять задачі автоматичної обробки й аналізу всіх ресурсів сервера без участі людини. Рішення цієї проблеми лежить цілком на плечах розробників додатків, що використовують даний протокол.<br /> <br /> ''Нема підтримки розподіленості'' - протокол HTTP розроблявся для рішення типових побутових задач де сам по собі час обробки запиту повинен забирати незначний час або взагалі не прийматися в розрахунок. Але в промисловому використанні із застосуванням розподілених обчислень при високих навантаженнях на сервер протокол HTTP виявляється безпомічний. У 1998 році W3C запропонував альтернативний протокол HTTP-NG (англ. HTTP Next Generation) для повної заміни застарілого з акцентуванням уваги саме на цій області. Ідею його необхідності підтримали великі фахівці з розподілених обчислень, але даний протокол дотепер перебуває в стадії розробки.<br /> <br /> [[category:Комп'ютерні мережі]]</div>

Hiss https://wiki.cusu.edu.ua/index.php/HTTP 2008-12-08T17:05:31Z

<p>Hiss: </p> <hr /> <div>'''Переваги'''<br /> <br /> ''Простота'' – протокол настільки простий у реалізації, що дозволяє з легкістю створювати не тільки клієнтські додатки, але і примітивні сервери.<br /> <br /> ''Розширюваність'' - ви можете легко розширювати можливості протоколу завдяки упровадженню своїх власних заголовків, зберігаючи сумісність з іншими клієнтами і серверами. Вони будуть ігнорувати невідомі їм заголовки, але при цьому ви можете одержати необхідний вам функціонал при рішенні специфічної задачі.<br /> <br /> ''Поширеність'' - при виборі протоколу HTTP для рішення конкретних задач немаловажним фактором є його поширеність. Як наслідок, цей багато різної документації по протоколу на багатьох мовах світу, вставка зручних у використанні засобів розробки в популярні IDE, підтримка протоколу як клієнта багатьма програмами і великий вибір серед хостингових компаній із серверами HTTP.<br /> <br /> '''Недоліки і проблеми'''<br /> <br /> ''Великий розмір повідомлень'' - використання текстового формату в протоколі породжує відповідний недолік: великий розмір повідомлень у порівнянні з передачею двійкових даних. Через це зростає навантаження на устаткування при формуванні, обробці і передачі повідомлень. Для розв’язанна даної проблеми до протоколу вбудовані засоби для забезпечення кешування на стороні клієнта, а також засобу компресії переданого контенту. Нормативними документами по протоколі передбачена наявність проксі-серверів, що дозволяють клієнту одержати документ із найбільш близького до нього сервера. Також до протоколу було впроваджене дельта-кодування, щоб клієнту передавався не весь документ, а тільки його змінена частина.<br /> <br /> ''Відсутність «навігації»'' - хоча протокол розроблявся як засіб роботи з ресурсами сервера, у нього відсутні в явному виді засоби навігації серед цих ресурсів. Наприклад, клієнт не може явно запросити список доступних файлів, як у протоколі FTP. Передбачалося, що кінцевий користувач уже знає URI необхідного йому документа, закачавши який, він буде робити навігацію завдяки гіперпосиланням. Це цілком нормально і зручно для людини, але важко, коли стоять задачі автоматичної обробки й аналізу всіх ресурсів сервера без участі людини. Рішення цієї проблеми лежить цілком на плечах розробників додатків, що використовують даний протокол.<br /> <br /> ''Нема підтримки розподіленості'' - протокол HTTP розроблявся для рішення типових побутових задач де сам по собі час обробки запиту повинен забирати незначний час або взагалі не прийматися в розрахунок. Але в промисловому використанні із застосуванням розподілених обчислень при високих навантаженнях на сервер протокол HTTP виявляється безпомічний. У 1998 році W3C запропонував альтернативний протокол HTTP-NG (англ. HTTP Next Generation) для повної заміни застарілого з акцентуванням уваги саме на цій області. Ідею його необхідності підтримали великі фахівці з розподілених обчислень, але даний протокол дотепер перебуває в стадії розробки.<br /> <br /> [[category:Комп'ютерні мережі]]</div>

Hiss https://wiki.cusu.edu.ua/index.php/HTTP 2008-12-08T16:56:46Z

<p>Hiss: </p> <hr /> <div>'''Переваги'''<br /> ''Простота'' – протокол настільки простий у реалізації, що дозволяє з легкістю створювати не тільки клієнтські додатки, але і примітивні сервери.<br /> <br /> ''Розширюваність'' - ви можете легко розширювати можливості протоколу завдяки упровадженню своїх власних заголовків, зберігаючи сумісність з іншими клієнтами і серверами. Вони будуть ігнорувати невідомі їм заголовки, але при цьому ви можете одержати необхідний вам функціонал при рішенні специфічної задачі.<br /> <br /> ''Поширеність'' - при виборі протоколу HTTP для рішення конкретних задач немаловажним фактором є його поширеність. Як наслідок, цей багато різної документації по протоколу на багатьох мовах світу, вставка зручних у використанні засобів розробки в популярні IDE, підтримка протоколу як клієнта багатьма програмами і великий вибір серед хостингових компаній із серверами HTTP.<br /> <br /> '''Недоліки і проблеми'''<br /> <br /> ''Великий розмір повідомлень'' - використання текстового формату в протоколі породжує відповідний недолік: великий розмір повідомлень у порівнянні з передачею двійкових даних. Через це зростає навантаження на устаткування при формуванні, обробці і передачі повідомлень. Для розв’язанна даної проблеми до протоколу вбудовані засоби для забезпечення кешування на стороні клієнта, а також засобу компресії переданого контенту. Нормативними документами по протоколі передбачена наявність проксі-серверів, що дозволяють клієнту одержати документ із найбільш близького до нього сервера. Також до протоколу було впроваджене дельта-кодування, щоб клієнту передавався не весь документ, а тільки його змінена частина.<br /> <br /> ''Відсутність «навігації»'' - хоча протокол розроблявся як засіб роботи з ресурсами сервера, у нього відсутні в явному виді засоби навігації серед цих ресурсів. Наприклад, клієнт не може явно запросити список доступних файлів, як у протоколі FTP. Передбачалося, що кінцевий користувач уже знає URI необхідного йому документа, закачавши який, він буде робити навігацію завдяки гіперпосиланням. Це цілком нормально і зручно для людини, але важко, коли стоять задачі автоматичної обробки й аналізу всіх ресурсів сервера без участі людини. Рішення цієї проблеми лежить цілком на плечах розробників додатків, що використовують даний протокол.<br /> <br /> ''Нема підтримки розподіленості'' - протокол HTTP розроблявся для рішення типових побутових задач де сам по собі час обробки запиту повинен забирати незначний час або взагалі не прийматися в розрахунок. Але в промисловому використанні із застосуванням розподілених обчислень при високих навантаженнях на сервер протокол HTTP виявляється безпомічний. У 1998 році W3C запропонував альтернативний протокол HTTP-NG (англ. HTTP Next Generation) для повної заміни застарілого з акцентуванням уваги саме на цій області. Ідею його необхідності підтримали великі фахівці з розподілених обчислень, але даний протокол дотепер перебуває в стадії розробки.<br /> <br /> [[category:Комп'ютерні мережі]]</div>

Hiss https://wiki.cusu.edu.ua/index.php/TCP/IP 2008-12-08T16:38:17Z

<p>Hiss: </p> <hr /> <div>[[Вступ (TCP/IP)]]<br /> <br /> [[Основи TCP/IP]]<br /> <br /> &lt;b&gt;Короткий опис найбільш відомих протоколів стеку TCP/IP з розшифровкою абревіатур&lt;/b&gt;<br /> <br /> [[ARP]]. (Address Resolution Protocol, протокол визначення адрес): протокол для визначення фізичної адреси інтерфейсу. Ця адреса необхідна для формування заголовка пакета канального рівня (кадру). Пакети ARP протоколу не доповнюються IP-заголовком міжмережного рівня, а одразу пакуються в кадри (пакети канального рівня), бо вони циркулюють тільки в межах однієї мережі.<br /> <br /> [[ATM]] ( Asynchronous Transfer Mode ) – нова універсальна технологія побудови каналів зв’язку для глобальних і локальних мереж, що забезпечує гарантовану якість і терміновість передавання даних. За цією технологією створюють нові швидкісні магістральні мережі для передавання даних в Україні. Високі ціни на обладнання стримують процес розширення застосування технології ATM . <br /> <br /> [[DNS]] ( Domain Name System ) – доменна система імен, яка призначена для перетворення символьних імен мережних ресурсів у цифрові адреси серверів, де розміщено ці ресурси. <br /> <br /> Ethernet – найбільш розповсюджена технологія побудови каналів зв’язку у локальних мережах. <br /> <br /> Frame Relay – найбільш розповсюджена технологія побудови каналів зв’язку для глобальних мереж. <br /> <br /> [[FTP]] (File Transfer Protocol, протокол передачі файлів): дозволяє передавати файли з одного комп'ютера на іншій з використанням TCP-з'єднань. У схожому, але менш розповсюдженому протоколі передачі файлів - Trivial File Transfer Protocol (TFTP) - для пересилання файлів застосовується UDP, а не TCP. <br /> <br /> [[HTTP]] ( Hypertext Transfer Protocol ) – протокол для передавання Web -сторінок (гіпертексту). <br /> <br /> [[ICMP]] (Internet Control Message Protocol, протокол керуючих повідомлень Internet): дозволяє IP-маршрутизаторам посилати повідомлення про помилки і керуючу інформацію іншим IP-маршрутизаторам і головним комп'ютерам мережі. ICMP-повідомлення &quot;подорожують&quot; у вигляді полів даних IP-дейтаграм і обов'язково повинні реалізовуватися у всіх варіантах IP. <br /> <br /> [[IGMP]] (Internet Group Management Protocol, протокол керування групами Internet): дозволяє IP-дейтаграмам поширюватися в циркулярному режимі (multicast) серед комп'ютерів, що належать до відповідних груп. <br /> <br /> [[IP]] (Internet Protocol, протокол Internet): низькорівневий протокол, що направляє пакети даних по окремих мережах, зв'язаних разом за допомогою маршрутизаторів для формування Internet або інтрамережі. Дані &quot;подорожують&quot; у формі пакетів, називаних IP-дейтаграмами. <br /> <br /> [[Протокол ІРv6]]<br /> <br /> [[PPP]] ( Point - to - Point Protocol ) – протокол, що широко застосовують для побудови каналу зв’язку між двома віддаленими вузлами, що з’єднані між собою фізичною лінією зв’язку. <br /> <br /> [[RARP]] (Reverse Address Resolution Protocol, протокол зворотного перетворення адрес): перетворить фізичні мережні адреси в IP-адреси. <br /> <br /> [[SMTP]] (Simple Mail Transfer Protocol, простий протокол обміну електронною поштою): визначає формат повідомлень, що SMTP-клієнт, що працює на одному комп'ютері, може використовувати для пересилання електронної пошти на SMTP-сервер, запущений на іншому комп'ютері. <br /> <br /> [[TCP]] (Transmission Control Protocol, протокол керування передачею): протокол орієнтований на роботу з підключеннями і передає дані у вигляді потоків байтів. Дані пересилаються пакетами - TCP-сегментами, - які складаються з заголовків TCP і даних. TCP - &quot;надійний&quot; протокол, тому що в ньому використовуються контрольні суми для перевірки цілісності даних і відправлення підтверджень, щоб гарантувати, що передані дані прийняті без перекручувань. <br /> <br /> [[UDP]] (User Datagram Protocol, протокол користувацьких дейтаграм): протокол, що не залежить від підключень, що передає дані пакетами, називаними UDP-дейтаграмами. UDP - &quot;ненадійний&quot; протокол, оскільки відправник не одержує інформацію, що показує, чи була в дійсності прийнята дейтаграма. <br /> <br /> <br /> &lt;b&gt;Структура протоколів TCP/IP. Протоколи TCP/IP поділяються на 4 рівні.&lt;/b&gt;<br /> &lt;center&gt;[[Image:777.PNG]]&lt;/center&gt;<br /> <br /> [[Рівні протоколів TCP/IP]]<br /> <br /> [[Адресація у ІР-мережах]]<br /> <br /> [[Особливі ІР-адреси]]<br /> <br /> [[Використання масок у ІР-адресації]]<br /> <br /> [[Підмережі]]<br /> <br /> [[Маска підмережі]]<br /> <br /> <br /> [[category:Комп'ютерні мережі]]</div>

Hiss https://wiki.cusu.edu.ua/index.php/TCP 2008-12-07T21:00:08Z

<p>Hiss: </p> <hr /> <div>Протокол '''TCP''' (Transmission Соntrоl Рrоtосоl - протокол керування передачею ) - протокол керування передачею даних, що використовує автоматичну повторну передачу пакетів, що містять помилки. Протокол TCP відповідає за розбивку переданої інформації на пакети і правильне відновлення інформації з пакетів одержувача.<br /> <br /> Незважаючи на те, що TCP і UDP використовують той самий мережний рівень (IP), TCP надає додаткам абсолютно інші сервиси, ніж UDP. TCP надає заснований на з'єднанні надійний сервіс потоку байтів. <br /> <br /> Термін &quot;заснований на з'єднанні&quot; (connection-oriented) означає, що два додатки, що використовують TCP (як правило, це клієнт і сервер), повинні установити TCP з'єднання один з одним, після чого в них з'являється можливість обмінюватися даними. Типова аналогія - це набір телефонного номера, чекання відповіді від вилученого абонента, коли він говорить &quot;алло&quot;, після чого необхідно сказати, хто дзвонить. <br /> <br /> TCP забезпечує свою надійність завдяки наступному: <br /> - Дані від додатка розбиваються на блоки визначеного розміру, що будуть відправлені. Це цілком відрізняється від UDP, у якому кожен запис, що здійснює додаток, генерує IP датаграму цього розміру. Блок інформації, що передається від TCP у IP, називається сегментом (segment). <br /> - Коли TCP посилає сегмент, він установлює таймер, очікуючи, що з вилученого кінця прийде підтвердження на цей сегмент. Якщо підтвердження не отримане після закінчення часу, сегмент передається повторно. <br /> - Коли TCP приймає дані від віддаленої сторони з'єднання, він відправляє підтвердження. Це підтвердження не відправляється негайно, а звичайно затримується на долі секунди.<br /> - TCP здійснює розрахунок контрольної суми для свого заголовка і даних. Це контрольна сума, що розраховується на кінцях з'єднання, метою якої є виявити будь-яку зміну даних у процесі передачі. Якщо сегмент прибуває з невірною контрольною сумою, TCP відкидає його і підтвердження не генерується. (Очікується, що відправник відробить тайм-аут і здійснить повторну передачу.) <br /> - Через те що TCP сегменти передаються у вигляді IP датаграм, а IP датаграми можуть прибувати безладно, також безладно можуть прибувати і TCP сегменти. Після одержання даних TCP може по необхідності змінити їхню послідовність, у результаті додаток одержує дані в правильному порядку. <br /> - Через те що IP датаграма може бути продубльована, що TCP, який приймає, повинен відкидати продубльовані дані. <br /> - TCP здійснює контроль потоку даних. Кожна сторона TCP з'єднання має визначений простір буфера. TCP на приймаючій стороні дозволяє вилученій стороні посилати дані тільки в тому випадку, якщо одержувач може помістити них у буфер. Це запобігає переповненню буферів повільних хостів швидкими хостами.<br /> <br /> Між двома додатками по TCP з'єднання здійснюється обмін потоком 8-бітових байтів. Автоматично TCP не вставляє запису маркерів. Це називається сервісом потоку байтів (byte stream service). Якщо додаток на одному кінці записав спочатку 10 байт, потім 20 байт і потім ще 50 байт, додаток на іншому кінці з'єднання не може сказати якого розміру був кожен запис. На іншому кінці ці 80 байт можуть бути лічені, наприклад, за 4 рази по 20 байт за щораз. Один кінець з'єднання поміщає потік байт у TCP, і точно так само ідентичний потік байт з'являється на іншому кінці. <br /> <br /> TCP не інтерпретує вміст байтів. TCP поняття не має про те, чи відбувається обмін двійковими даними, ASCII символами, EBCDIC символами або чим-небудь ще. Ця інтерпретація потоку байтів здійснюється додатками на кожній стороні з'єднання.<br /> <br /> Передача TCP сегментів здійснюється у вигляді Internet датаграм. Заголовок датаграми в Internet протоколі має кілька інформаційних полів, включаючи адреси хост- комп'ютерів, що відправляють і приймають. Заголовок TCP слідує за Internet заголовком і доповнює його інформацією, специфічною для TCP протоколу. Такий розподіл допускає використання на рівні хост-комп’ютерів протоколів, інших ніж TCP. <br /> <br /> Формат TCP заголовка<br /> <br /> &lt;center&gt;[[Image:TCP1.jpg]]&lt;/center&gt;<br /> <br /> Відзначимо, що кожна мітка вказує тут місце для відповідного біта. <br /> <br /> ''Source Port'' (порт відправника) 16 біт<br /> номер порту відправника<br /> <br /> ''Destination Port'' (порт одержувача) 16 біт<br /> номер порту одержувача<br /> <br /> ''Sequence Number'' (номер черги) 32 біта<br /> Номер черги для першого октету даних у даному сегменті (за винятком тих випадків, коли є присутнім прапор синхронізації SYN). Якщо ж прапор SYN є присутнім, то номер черги є ініціалізаційним (ISN), а номер першого октету даних - ISN+1. <br /> <br /> ''Acknowledgment Number'' (номер підтвердження) 32 біта<br /> Якщо встановлено контрольний біт ACK, то це поле містить наступний номер черги, що відправник даної датаграми бажає одержати в зворотному напрямку. Номераи підтвердження посилаються постійно, як тільки з'єднання буде установлено. <br /> <br /> ''Data Offset (зсув даних)'' 4 біти<br /> Кількість 32-бітних слів у TCP заголовку. Указує на початок поля даних. TCP заголовок завжди кінчається на 32-бітній границі слова, навіть якщо він містить опції. <br /> <br /> ''Reserved 6 біт''<br /> Це резервне поле, повинне бути заповнено нулями. <br /> <br /> ''Control Bits'' (контрольні біти) 6 біт<br /> Біти цього поля зліва неправо<br /> URG: поле термінового покажчика задіяне <br /> ACK: поле підтвердження задіяне <br /> PSH: функція проштовхування <br /> RST: перезавантаження даного з'єднання <br /> SYN: синхронізація номерів черги <br /> FIN: немає більше даних для передачі<br /> <br /> ''Window (вікно)'' 16 біт<br /> Кількість октетів даних, починаючи з октету, чий номер зазначений у полі підтвердження. Кількість октетів, одержання яких чекає відправник дійсного сегмента. <br /> <br /> ''Checksum'' (контрольна сума) 16 біт<br /> Поле контрольної суми - це 16-бітне доповнення суми всіх 16- бітних слів заголовка і тексту. Якщо сегмент містить у заголовку і тексті непарну кількість октетів, що підлягають обліку в контрольній сумі, останній октет буде доповнений нулями праворуч для того, щоб утворити для надання контрольній сумі 16-бітне слово. Виниклий при такому вирівнюванні октет не передається разом із сегментом по мережі. Перед обчисленням контрольної суми поле цієї суми заповнюється нулями. <br /> <br /> Контрольна сума, крім усього іншого, враховує 96 біт псевдозаголовка, що для внутрішнього вживання ставиться перед TCP заголовком. Цей псевдозаголовок містить адресу відправника, адресу одержувача, протокол і довжину TCP сегмента. Такий підхід забезпечує захист протоколу TCP від помилившихся в маршруті сегментів. Цю інформацію обробляє Internet протокол. Вона передається через інтерфейс протокол TCP/локальна мережа як аргументи або результати запитів від протоколу TCP до протоколу IP.<br /> <br /> &lt;center&gt;[[Image:TCP2.jpg]]&lt;/center&gt;<br /> <br /> Довжина TCP сегмента - це довжина TCP заголовка і поля даних, вимірювана в октетах. Це не є точною вказівкою кількості переданих по мережі октетів, вона не враховує 12 октетів псевдозаголовку, проте розрахунок цього параметра усе-таки виконується. <br /> <br /> Urgent Pointer (терміновий покажчик) 16 біт<br /> Це поле повідомляє поточне значення термінового покажчика. Останній є позитивною величиною - зсувом щодо номера черги даного сегмента. Терміновий покажчик повідомляє номер черги для октету, що випливає за терміновими даними. Це поле інтерпретується тільки в тому випадку, коли в сегменті виставлений контрольний біт URG. <br /> <br /> Options (опції) довжина змінної<br /> Опції можуть розташовуватися наприкінці TCP заголовка, а їхня довжина кратна 8 біт. Всі опції враховуються при розрахунку контрольної суми. <br /> <br /> Опції можуть починатися з будь-якого октету. Вони можуть мати два формати:<br /> - однооктетний тип опцій; <br /> - октет типу опції, октет довжини опції й октети даних розглянутої опції. <br /> <br /> В октеті довжини опції враховуються октет типу опції, сам октет довжини, а також всі октети з даними. <br /> <br /> Відмітимо, що список опцій може виявитися коротше, ніж можна вказати в полі Data Offset. Місце в заголовку, що залишається за опцією &quot;End-of-Option&quot;, повинне бути заповнено нулями. Протокол TCP повинний бути готовий обробляти всі опції. <br /> <br /> В даний час визначені наступні опції:<br /> <br /> Тип Довжина Значення <br /> <br /> 0 - кінець списку опцій <br /> <br /> 1 - немає операцій <br /> <br /> 2 4 максимальний розмір сегмента<br /> <br /> <br /> Докладныше дивись на http://www.citforum.ru/internet/tifamily/tcpspec.shtml#3.1<br /> [[category:Комп'ютерні мережі]]</div>

Hiss https://wiki.cusu.edu.ua/index.php/TCP 2008-12-07T20:58:48Z

<p>Hiss: </p> <hr /> <div>Протокол '''TCP''' (Transmission Соntrоl Рrоtосоl - протокол керування передачею ) - протокол керування передачею даних, що використовує автоматичну повторну передачу пакетів, що містять помилки. Протокол TCP відповідає за розбивку переданої інформації на пакети і правильне відновлення інформації з пакетів одержувача.<br /> <br /> Незважаючи на те, що TCP і UDP використовують той самий мережний рівень (IP), TCP надає додаткам абсолютно інші сервиси, ніж UDP. TCP надає заснований на з'єднанні надійний сервіс потоку байтів. <br /> <br /> Термін &quot;заснований на з'єднанні&quot; (connection-oriented) означає, що два додатки, що використовують TCP (як правило, це клієнт і сервер), повинні установити TCP з'єднання один з одним, після чого в них з'являється можливість обмінюватися даними. Типова аналогія - це набір телефонного номера, чекання відповіді від вилученого абонента, коли він говорить &quot;алло&quot;, після чого необхідно сказати, хто дзвонить. <br /> <br /> TCP забезпечує свою надійність завдяки наступному: <br /> - Дані від додатка розбиваються на блоки визначеного розміру, що будуть відправлені. Це цілком відрізняється від UDP, у якому кожен запис, що здійснює додаток, генерує IP датаграму цього розміру. Блок інформації, що передається від TCP у IP, називається сегментом (segment). <br /> - Коли TCP посилає сегмент, він установлює таймер, очікуючи, що з вилученого кінця прийде підтвердження на цей сегмент. Якщо підтвердження не отримане після закінчення часу, сегмент передається повторно. <br /> - Коли TCP приймає дані від віддаленої сторони з'єднання, він відправляє підтвердження. Це підтвердження не відправляється негайно, а звичайно затримується на долі секунди.<br /> - TCP здійснює розрахунок контрольної суми для свого заголовка і даних. Це контрольна сума, що розраховується на кінцях з'єднання, метою якої є виявити будь-яку зміну даних у процесі передачі. Якщо сегмент прибуває з невірною контрольною сумою, TCP відкидає його і підтвердження не генерується. (Очікується, що відправник відробить тайм-аут і здійснить повторну передачу.) <br /> - Через те що TCP сегменти передаються у вигляді IP датаграм, а IP датаграми можуть прибувати безладно, також безладно можуть прибувати і TCP сегменти. Після одержання даних TCP може по необхідності змінити їхню послідовність, у результаті додаток одержує дані в правильному порядку. <br /> - Через те що IP датаграма може бути продубльована, що TCP, який приймає, повинен відкидати продубльовані дані. <br /> - TCP здійснює контроль потоку даних. Кожна сторона TCP з'єднання має визначений простір буфера. TCP на приймаючій стороні дозволяє вилученій стороні посилати дані тільки в тому випадку, якщо одержувач може помістити них у буфер. Це запобігає переповненню буферів повільних хостів швидкими хостами.<br /> <br /> Між двома додатками по TCP з'єднання здійснюється обмін потоком 8-бітових байтів. Автоматично TCP не вставляє запису маркерів. Це називається сервісом потоку байтів (byte stream service). Якщо додаток на одному кінці записав спочатку 10 байт, потім 20 байт і потім ще 50 байт, додаток на іншому кінці з'єднання не може сказати якого розміру був кожен запис. На іншому кінці ці 80 байт можуть бути лічені, наприклад, за 4 рази по 20 байт за щораз. Один кінець з'єднання поміщає потік байт у TCP, і точно так само ідентичний потік байт з'являється на іншому кінці. <br /> <br /> TCP не інтерпретує вміст байтів. TCP поняття не має про те, чи відбувається обмін двійковими даними, ASCII символами, EBCDIC символами або чим-небудь ще. Ця інтерпретація потоку байтів здійснюється додатками на кожній стороні з'єднання.<br /> <br /> Передача TCP сегментів здійснюється у вигляді Internet датаграм. Заголовок датаграми в Internet протоколі має кілька інформаційних полів, включаючи адреси хост- комп'ютерів, що відправляють і приймають. Заголовок TCP слідує за Internet заголовком і доповнює його інформацією, специфічною для TCP протоколу. Такий розподіл допускає використання на рівні хост-комп’ютерів протоколів, інших ніж TCP. <br /> <br /> Формат TCP заголовка<br /> <br /> &lt;center&gt;[[Image:TCP1.jpg]]&lt;/center&gt;<br /> <br /> Відзначимо, що кожна мітка вказує тут місце для відповідного біта. <br /> <br /> ''Source Port'' (порт відправника) 16 біт<br /> номер порту відправника<br /> <br /> ''Destination Port'' (порт одержувача) 16 біт<br /> номер порту одержувача<br /> <br /> ''Sequence Number'' (номер черги) 32 біта<br /> Номер черги для першого октету даних у даному сегменті (за винятком тих випадків, коли є присутнім прапор синхронізації SYN). Якщо ж прапор SYN є присутнім, то номер черги є ініціалізаційним (ISN), а номер першого октету даних - ISN+1. <br /> <br /> ''Acknowledgment Number'' (номер підтвердження) 32 біта<br /> Якщо встановлено контрольний біт ACK, то це поле містить наступний номер черги, що відправник даної датаграми бажає одержати в зворотному напрямку. Номераи підтвердження посилаються постійно, як тільки з'єднання буде установлено. <br /> <br /> ''Data Offset (зсув даних)'' 4 біти<br /> Кількість 32-бітних слів у TCP заголовку. Указує на початок поля даних. TCP заголовок завжди кінчається на 32-бітній границі слова, навіть якщо він містить опції. <br /> <br /> ''Reserved 6 біт''<br /> Це резервне поле, повинне бути заповнено нулями. <br /> <br /> ''Control Bits'' (контрольні біти) 6 біт<br /> Біти цього поля зліва неправо<br /> URG: поле термінового покажчика задіяне <br /> ACK: поле підтвердження задіяне <br /> PSH: функція проштовхування <br /> RST: перезавантаження даного з'єднання <br /> SYN: синхронізація номерів черги <br /> FIN: немає більше даних для передачі<br /> <br /> ''Window (вікно)'' 16 біт<br /> Кількість октетів даних, починаючи з октету, чий номер зазначений у полі підтвердження. Кількість октетів, одержання яких чекає відправник дійсного сегмента. <br /> <br /> ''Checksum'' (контрольна сума) 16 біт<br /> Поле контрольної суми - це 16-бітне доповнення суми всіх 16- бітних слів заголовка і тексту. Якщо сегмент містить у заголовку і тексті непарну кількість октетів, що підлягають обліку в контрольній сумі, останній октет буде доповнений нулями праворуч для того, щоб утворити для надання контрольній сумі 16-бітне слово. Виниклий при такому вирівнюванні октет не передається разом із сегментом по мережі. Перед обчисленням контрольної суми поле цієї суми заповнюється нулями. <br /> <br /> Контрольна сума, крім усього іншого, враховує 96 біт псевдозаголовка, що для внутрішнього вживання ставиться перед TCP заголовком. Цей псевдозаголовок містить адресу відправника, адресу одержувача, протокол і довжину TCP сегмента. Такий підхід забезпечує захист протоколу TCP від помилившихся в маршруті сегментів. Цю інформацію обробляє Internet протокол. Вона передається через інтерфейс протокол TCP/локальна мережа як аргументи або результати запитів від протоколу TCP до протоколу IP.<br /> <br /> &lt;center&gt;[[Image:TCP2.jpg]]&lt;/center&gt;<br /> <br /> Довжина TCP сегмента - це довжина TCP заголовка і поля даних, вимірювана в октетах. Це не є точною вказівкою кількості переданих по мережі октетів, вона не враховує 12 октетів псевдозаголовку, проте розрахунок цього параметра усе-таки виконується. <br /> <br /> Urgent Pointer (терміновий покажчик) 16 біт<br /> Це поле повідомляє поточне значення термінового покажчика. Останній є позитивною величиною - зсувом щодо номера черги даного сегмента. Терміновий покажчик повідомляє номер черги для октету, що випливає за терміновими даними. Це поле інтерпретується тільки в тому випадку, коли в сегменті виставлений контрольний біт URG. <br /> <br /> Options (опції) довжина змінної<br /> Опції можуть розташовуватися наприкінці TCP заголовка, а їхня довжина кратна 8 біт. Всі опції враховуються при розрахунку контрольної суми. <br /> <br /> Опції можуть починатися з будь-якого октету. Вони можуть мати два формати:<br /> - однооктетний тип опцій; <br /> - октет типу опції, октет довжини опції й октети даних розглянутої опції. <br /> <br /> В октеті довжини опції враховуються октет типу опції, сам октет довжини, а також всі октети з даними. <br /> <br /> Відмітимо, що список опцій може виявитися коротше, ніж можна вказати в полі Data Offset. Місце в заголовку, що залишається за опцією &quot;End-of-Option&quot;, повинне бути заповнено нулями. Протокол TCP повинний бути готовий обробляти всі опції. <br /> <br /> В даний час визначені наступні опції:<br /> <br /> Тип | Довжина | Значення <br /> <br /> 0 | - | кінець списку опцій <br /> <br /> 1 | - | немає операцій <br /> <br /> 2 | 4 | максимальний розмір сегмента<br /> <br /> <br /> Докладныше дивись на http://www.citforum.ru/internet/tifamily/tcpspec.shtml#3.1<br /> [[category:Комп'ютерні мережі]]</div>

Hiss https://wiki.cusu.edu.ua/index.php/TCP 2008-12-07T20:56:45Z

<p>Hiss: </p> <hr /> <div>Протокол '''TCP''' (Transmission Соntrоl Рrоtосоl - протокол керування передачею ) - протокол керування передачею даних, що використовує автоматичну повторну передачу пакетів, що містять помилки. Протокол TCP відповідає за розбивку переданої інформації на пакети і правильне відновлення інформації з пакетів одержувача.<br /> <br /> Незважаючи на те, що TCP і UDP використовують той самий мережний рівень (IP), TCP надає додаткам абсолютно інші сервиси, ніж UDP. TCP надає заснований на з'єднанні надійний сервіс потоку байтів. <br /> <br /> Термін &quot;заснований на з'єднанні&quot; (connection-oriented) означає, що два додатки, що використовують TCP (як правило, це клієнт і сервер), повинні установити TCP з'єднання один з одним, після чого в них з'являється можливість обмінюватися даними. Типова аналогія - це набір телефонного номера, чекання відповіді від вилученого абонента, коли він говорить &quot;алло&quot;, після чого необхідно сказати, хто дзвонить. <br /> <br /> TCP забезпечує свою надійність завдяки наступному: <br /> - Дані від додатка розбиваються на блоки визначеного розміру, що будуть відправлені. Це цілком відрізняється від UDP, у якому кожен запис, що здійснює додаток, генерує IP датаграму цього розміру. Блок інформації, що передається від TCP у IP, називається сегментом (segment). <br /> - Коли TCP посилає сегмент, він установлює таймер, очікуючи, що з вилученого кінця прийде підтвердження на цей сегмент. Якщо підтвердження не отримане після закінчення часу, сегмент передається повторно. <br /> - Коли TCP приймає дані від віддаленої сторони з'єднання, він відправляє підтвердження. Це підтвердження не відправляється негайно, а звичайно затримується на долі секунди.<br /> - TCP здійснює розрахунок контрольної суми для свого заголовка і даних. Це контрольна сума, що розраховується на кінцях з'єднання, метою якої є виявити будь-яку зміну даних у процесі передачі. Якщо сегмент прибуває з невірною контрольною сумою, TCP відкидає його і підтвердження не генерується. (Очікується, що відправник відробить тайм-аут і здійснить повторну передачу.) <br /> - Через те що TCP сегменти передаються у вигляді IP датаграм, а IP датаграми можуть прибувати безладно, також безладно можуть прибувати і TCP сегменти. Після одержання даних TCP може по необхідності змінити їхню послідовність, у результаті додаток одержує дані в правильному порядку. <br /> - Через те що IP датаграма може бути продубльована, що TCP, який приймає, повинен відкидати продубльовані дані. <br /> - TCP здійснює контроль потоку даних. Кожна сторона TCP з'єднання має визначений простір буфера. TCP на приймаючій стороні дозволяє вилученій стороні посилати дані тільки в тому випадку, якщо одержувач може помістити них у буфер. Це запобігає переповненню буферів повільних хостів швидкими хостами.<br /> <br /> Між двома додатками по TCP з'єднання здійснюється обмін потоком 8-бітових байтів. Автоматично TCP не вставляє запису маркерів. Це називається сервісом потоку байтів (byte stream service). Якщо додаток на одному кінці записав спочатку 10 байт, потім 20 байт і потім ще 50 байт, додаток на іншому кінці з'єднання не може сказати якого розміру був кожен запис. На іншому кінці ці 80 байт можуть бути лічені, наприклад, за 4 рази по 20 байт за щораз. Один кінець з'єднання поміщає потік байт у TCP, і точно так само ідентичний потік байт з'являється на іншому кінці. <br /> <br /> TCP не інтерпретує вміст байтів. TCP поняття не має про те, чи відбувається обмін двійковими даними, ASCII символами, EBCDIC символами або чим-небудь ще. Ця інтерпретація потоку байтів здійснюється додатками на кожній стороні з'єднання.<br /> <br /> Передача TCP сегментів здійснюється у вигляді Internet датаграм. Заголовок датаграми в Internet протоколі має кілька інформаційних полів, включаючи адреси хост- комп'ютерів, що відправляють і приймають. Заголовок TCP слідує за Internet заголовком і доповнює його інформацією, специфічною для TCP протоколу. Такий розподіл допускає використання на рівні хост-комп’ютерів протоколів, інших ніж TCP. <br /> <br /> Формат TCP заголовка<br /> <br /> &lt;center&gt;[[Image:TCP1.jpg]]&lt;/center&gt;<br /> <br /> Відзначимо, що кожна мітка вказує тут місце для відповідного біта. <br /> <br /> ''Source Port'' (порт відправника) 16 біт<br /> номер порту відправника<br /> <br /> ''Destination Port'' (порт одержувача) 16 біт<br /> номер порту одержувача<br /> <br /> ''Sequence Number'' (номер черги) 32 біта<br /> Номер черги для першого октету даних у даному сегменті (за винятком тих випадків, коли є присутнім прапор синхронізації SYN). Якщо ж прапор SYN є присутнім, то номер черги є ініціалізаційним (ISN), а номер першого октету даних - ISN+1. <br /> <br /> ''Acknowledgment Number'' (номер підтвердження) 32 біта<br /> Якщо встановлено контрольний біт ACK, то це поле містить наступний номер черги, що відправник даної датаграми бажає одержати в зворотному напрямку. Номераи підтвердження посилаються постійно, як тільки з'єднання буде установлено. <br /> <br /> ''Data Offset (зсув даних)'' 4 біти<br /> Кількість 32-бітних слів у TCP заголовку. Указує на початок поля даних. TCP заголовок завжди кінчається на 32-бітній границі слова, навіть якщо він містить опції. <br /> <br /> ''Reserved 6 біт''<br /> Це резервне поле, повинне бути заповнено нулями. <br /> <br /> ''Control Bits'' (контрольні біти) 6 біт<br /> Біти цього поля зліва неправо<br /> URG: поле термінового покажчика задіяне <br /> ACK: поле підтвердження задіяне <br /> PSH: функція проштовхування <br /> RST: перезавантаження даного з'єднання <br /> SYN: синхронізація номерів черги <br /> FIN: немає більше даних для передачі<br /> <br /> ''Window (вікно)'' 16 біт<br /> Кількість октетів даних, починаючи з октету, чий номер зазначений у полі підтвердження. Кількість октетів, одержання яких чекає відправник дійсного сегмента. <br /> <br /> ''Checksum'' (контрольна сума) 16 біт<br /> Поле контрольної суми - це 16-бітне доповнення суми всіх 16- бітних слів заголовка і тексту. Якщо сегмент містить у заголовку і тексті непарну кількість октетів, що підлягають обліку в контрольній сумі, останній октет буде доповнений нулями праворуч для того, щоб утворити для надання контрольній сумі 16-бітне слово. Виниклий при такому вирівнюванні октет не передається разом із сегментом по мережі. Перед обчисленням контрольної суми поле цієї суми заповнюється нулями. <br /> <br /> Контрольна сума, крім усього іншого, враховує 96 біт псевдозаголовка, що для внутрішнього вживання ставиться перед TCP заголовком. Цей псевдозаголовок містить адресу відправника, адресу одержувача, протокол і довжину TCP сегмента. Такий підхід забезпечує захист протоколу TCP від помилившихся в маршруті сегментів. Цю інформацію обробляє Internet протокол. Вона передається через інтерфейс протокол TCP/локальна мережа як аргументи або результати запитів від протоколу TCP до протоколу IP.<br /> <br /> &lt;center&gt;[[Image:TCP2.jpg]]&lt;/center&gt;<br /> <br /> Довжина TCP сегмента - це довжина TCP заголовка і поля даних, вимірювана в октетах. Це не є точною вказівкою кількості переданих по мережі октетів, вона не враховує 12 октетів псевдозаголовку, проте розрахунок цього параметра усе-таки виконується. <br /> <br /> Urgent Pointer (терміновий покажчик) 16 біт<br /> Це поле повідомляє поточне значення термінового покажчика. Останній є позитивною величиною - зсувом щодо номера черги даного сегмента. Терміновий покажчик повідомляє номер черги для октету, що випливає за терміновими даними. Це поле інтерпретується тільки в тому випадку, коли в сегменті виставлений контрольний біт URG. <br /> <br /> Options (опції) довжина змінної<br /> Опції можуть розташовуватися наприкінці TCP заголовка, а їхня довжина кратна 8 біт. Всі опції враховуються при розрахунку контрольної суми. <br /> <br /> Опції можуть починатися з будь-якого октету. Вони можуть мати два формати:<br /> - однооктетний тип опцій; <br /> - октет типу опції, октет довжини опції й октети даних розглянутої опції. <br /> <br /> В октеті довжини опції враховуються октет типу опції, сам октет довжини, а також всі октети з даними. <br /> <br /> Відмітимо, що список опцій може виявитися коротше, ніж можна вказати в полі Data Offset. Місце в заголовку, що залишається за опцією &quot;End-of-Option&quot;, повинне бути заповнено нулями. Протокол TCP повинний бути готовий обробляти всі опції. <br /> <br /> В даний час визначені наступні опції:<br /> <br /> Тип Довжина Значення <br /> <br /> 0 - кінець списку опцій <br /> <br /> 1 - немає операцій <br /> <br /> 2 4 максимальний розмір сегмента<br /> <br /> <br /> Докладныше дивись на http://www.citforum.ru/internet/tifamily/tcpspec.shtml#3.1<br /> [[category:Комп'ютерні мережі]]</div>

Hiss https://wiki.cusu.edu.ua/index.php/TCP 2008-12-07T20:54:36Z

<p>Hiss: </p> <hr /> <div>Протокол '''TCP''' (Transmission Соntrоl Рrоtосоl - протокол керування передачею ) - протокол керування передачею даних, що використовує автоматичну повторну передачу пакетів, що містять помилки. Протокол TCP відповідає за розбивку переданої інформації на пакети і правильне відновлення інформації з пакетів одержувача.<br /> <br /> Незважаючи на те, що TCP і UDP використовують той самий мережний рівень (IP), TCP надає додаткам абсолютно інші сервиси, ніж UDP. TCP надає заснований на з'єднанні надійний сервіс потоку байтів. <br /> <br /> Термін &quot;заснований на з'єднанні&quot; (connection-oriented) означає, що два додатки, що використовують TCP (як правило, це клієнт і сервер), повинні установити TCP з'єднання один з одним, після чого в них з'являється можливість обмінюватися даними. Типова аналогія - це набір телефонного номера, чекання відповіді від вилученого абонента, коли він говорить &quot;алло&quot;, після чого необхідно сказати, хто дзвонить. <br /> <br /> TCP забезпечує свою надійність завдяки наступному: <br /> - Дані від додатка розбиваються на блоки визначеного розміру, що будуть відправлені. Це цілком відрізняється від UDP, у якому кожен запис, що здійснює додаток, генерує IP датаграму цього розміру. Блок інформації, що передається від TCP у IP, називається сегментом (segment). <br /> - Коли TCP посилає сегмент, він установлює таймер, очікуючи, що з вилученого кінця прийде підтвердження на цей сегмент. Якщо підтвердження не отримане після закінчення часу, сегмент передається повторно. <br /> - Коли TCP приймає дані від віддаленої сторони з'єднання, він відправляє підтвердження. Це підтвердження не відправляється негайно, а звичайно затримується на долі секунди.<br /> - TCP здійснює розрахунок контрольної суми для свого заголовка і даних. Це контрольна сума, що розраховується на кінцях з'єднання, метою якої є виявити будь-яку зміну даних у процесі передачі. Якщо сегмент прибуває з невірною контрольною сумою, TCP відкидає його і підтвердження не генерується. (Очікується, що відправник відробить тайм-аут і здійснить повторну передачу.) <br /> - Через те що TCP сегменти передаються у вигляді IP датаграм, а IP датаграми можуть прибувати безладно, також безладно можуть прибувати і TCP сегменти. Після одержання даних TCP може по необхідності змінити їхню послідовність, у результаті додаток одержує дані в правильному порядку. <br /> - Через те що IP датаграма може бути продубльована, що TCP, який приймає, повинен відкидати продубльовані дані. <br /> - TCP здійснює контроль потоку даних. Кожна сторона TCP з'єднання має визначений простір буфера. TCP на приймаючій стороні дозволяє вилученій стороні посилати дані тільки в тому випадку, якщо одержувач може помістити них у буфер. Це запобігає переповненню буферів повільних хостів швидкими хостами.<br /> <br /> Між двома додатками по TCP з'єднання здійснюється обмін потоком 8-бітових байтів. Автоматично TCP не вставляє запису маркерів. Це називається сервісом потоку байтів (byte stream service). Якщо додаток на одному кінці записав спочатку 10 байт, потім 20 байт і потім ще 50 байт, додаток на іншому кінці з'єднання не може сказати якого розміру був кожен запис. На іншому кінці ці 80 байт можуть бути лічені, наприклад, за 4 рази по 20 байт за щораз. Один кінець з'єднання поміщає потік байт у TCP, і точно так само ідентичний потік байт з'являється на іншому кінці. <br /> <br /> TCP не інтерпретує вміст байтів. TCP поняття не має про те, чи відбувається обмін двійковими даними, ASCII символами, EBCDIC символами або чим-небудь ще. Ця інтерпретація потоку байтів здійснюється додатками на кожній стороні з'єднання.<br /> <br /> Передача TCP сегментів здійснюється у вигляді Internet датаграм. Заголовок датаграми в Internet протоколі має кілька інформаційних полів, включаючи адреси хост- комп'ютерів, що відправляють і приймають. Заголовок TCP слідує за Internet заголовком і доповнює його інформацією, специфічною для TCP протоколу. Такий розподіл допускає використання на рівні хост-комп’ютерів протоколів, інших ніж TCP. <br /> <br /> Формат TCP заголовка<br /> <br /> &lt;center&gt;[[Image:TCP1.jpg]]&lt;/center&gt;<br /> <br /> Відзначимо, що кожна мітка вказує тут місце для відповідного біта. <br /> <br /> ''Source Port'' (порт відправника) 16 біт<br /> номер порту відправника<br /> <br /> ''Destination Port'' (порт одержувача) 16 біт<br /> номер порту одержувача<br /> <br /> ''Sequence Number'' (номер черги) 32 біта<br /> Номер черги для першого октету даних у даному сегменті (за винятком тих випадків, коли є присутнім прапор синхронізації SYN). Якщо ж прапор SYN є присутнім, то номер черги є ініціалізаційним (ISN), а номер першого октету даних - ISN+1. <br /> <br /> ''Acknowledgment Number'' (номер підтвердження) 32 біта<br /> Якщо встановлено контрольний біт ACK, то це поле містить наступний номер черги, що відправник даної датаграми бажає одержати в зворотному напрямку. Номераи підтвердження посилаються постійно, як тільки з'єднання буде установлено. <br /> <br /> ''Data Offset (зсув даних)'' 4 біти<br /> Кількість 32-бітних слів у TCP заголовку. Указує на початок поля даних. TCP заголовок завжди кінчається на 32-бітній границі слова, навіть якщо він містить опції. <br /> <br /> ''Reserved 6 біт''<br /> Це резервне поле, повинне бути заповнено нулями. <br /> <br /> ''Control Bits'' (контрольні біти) 6 біт<br /> Біти цього поля зліва неправо<br /> URG: поле термінового покажчика задіяне <br /> ACK: поле підтвердження задіяне <br /> PSH: функція проштовхування <br /> RST: перезавантаження даного з'єднання <br /> SYN: синхронізація номерів черги <br /> FIN: немає більше даних для передачі<br /> <br /> ''Window (вікно)'' 16 біт<br /> Кількість октетів даних, починаючи з октету, чий номер зазначений у полі підтвердження. Кількість октетів, одержання яких чекає відправник дійсного сегмента. <br /> <br /> ''Checksum'' (контрольна сума) 16 біт<br /> Поле контрольної суми - це 16-бітне доповнення суми всіх 16- бітних слів заголовка і тексту. Якщо сегмент містить у заголовку і тексті непарну кількість октетів, що підлягають обліку в контрольній сумі, останній октет буде доповнений нулями праворуч для того, щоб утворити для надання контрольній сумі 16-бітне слово. Виниклий при такому вирівнюванні октет не передається разом із сегментом по мережі. Перед обчисленням контрольної суми поле цієї суми заповнюється нулями. <br /> <br /> Контрольна сума, крім усього іншого, враховує 96 біт псевдозаголовка, що для внутрішнього вживання ставиться перед TCP заголовком. Цей псевдозаголовок містить адресу відправника, адресу одержувача, протокол і довжину TCP сегмента. Такий підхід забезпечує захист протоколу TCP від помилившихся в маршруті сегментів. Цю інформацію обробляє Internet протокол. Вона передається через інтерфейс протокол TCP/локальна мережа як аргументи або результати запитів від протоколу TCP до протоколу IP.<br /> <br /> &lt;center&gt;[[Image:TCP2.jpg]]&lt;/center&gt;<br /> <br /> Довжина TCP сегмента - це довжина TCP заголовка і поля даних, вимірювана в октетах. Це не є точною вказівкою кількості переданих по мережі октетів, вона не враховує 12 октетів псевдозаголовку, проте розрахунок цього параметра усе-таки виконується. <br /> <br /> Urgent Pointer (терміновий покажчик) 16 біт<br /> Це поле повідомляє поточне значення термінового покажчика. Останній є позитивною величиною - зсувом щодо номера черги даного сегмента. Терміновий покажчик повідомляє номер черги для октету, що випливає за терміновими даними. Це поле інтерпретується тільки в тому випадку, коли в сегменті виставлений контрольний біт URG. <br /> <br /> Options (опції) довжина змінної<br /> Опції можуть розташовуватися наприкінці TCP заголовка, а їхня довжина кратна 8 біт. Всі опції враховуються при розрахунку контрольної суми. <br /> <br /> Опції можуть починатися з будь-якого октету. Вони можуть мати два формати:<br /> - однооктетний тип опцій; <br /> - октет типу опції, октет довжини опції й октети даних розглянутої опції. <br /> <br /> В октеті довжини опції враховуються октет типу опції, сам октет довжини, а також всі октети з даними. <br /> <br /> Відмітимо, що список опцій може виявитися коротше, ніж можна вказати в полі Data Offset. Місце в заголовку, що залишається за опцією &quot;End-of-Option&quot;, повинне бути заповнено нулями. Протокол TCP повинний бути готовий обробляти всі опції. <br /> <br /> В даний час визначені наступні опції:<br /> Тип Довжина Значення <br /> 0 - кінець списку опцій <br /> 1 - немає операцій <br /> 2 4 максимальний розмір сегмента<br /> <br /> <br /> Докладныше дивись на http://www.citforum.ru/internet/tifamily/tcpspec.shtml#3.1<br /> [[category:Комп'ютерні мережі]]</div>

Hiss https://wiki.cusu.edu.ua/index.php/%D0%A4%D0%B0%D0%B9%D0%BB:TCP2.jpg 2008-12-07T20:27:48Z

<p>Hiss: </p> <hr /> <div></div>

Hiss https://wiki.cusu.edu.ua/index.php/TCP 2008-12-07T20:26:30Z

<p>Hiss: </p> <hr /> <div>Протокол '''TCP''' (Transmission Соntrоl Рrоtосоl - протокол керування передачею ) - протокол керування передачею даних, що використовує автоматичну повторну передачу пакетів, що містять помилки. Протокол TCP відповідає за розбивку переданої інформації на пакети і правильне відновлення інформації з пакетів одержувача.<br /> <br /> Незважаючи на те, що TCP і UDP використовують той самий мережний рівень (IP), TCP надає додаткам абсолютно інші сервиси, ніж UDP. TCP надає заснований на з'єднанні надійний сервіс потоку байтів. <br /> <br /> Термін &quot;заснований на з'єднанні&quot; (connection-oriented) означає, що два додатки, що використовують TCP (як правило, це клієнт і сервер), повинні установити TCP з'єднання один з одним, після чого в них з'являється можливість обмінюватися даними. Типова аналогія - це набір телефонного номера, чекання відповіді від вилученого абонента, коли він говорить &quot;алло&quot;, після чого необхідно сказати, хто дзвонить. <br /> <br /> TCP забезпечує свою надійність завдяки наступному: <br /> - Дані від додатка розбиваються на блоки визначеного розміру, що будуть відправлені. Це цілком відрізняється від UDP, у якому кожен запис, що здійснює додаток, генерує IP датаграму цього розміру. Блок інформації, що передається від TCP у IP, називається сегментом (segment). <br /> - Коли TCP посилає сегмент, він установлює таймер, очікуючи, що з вилученого кінця прийде підтвердження на цей сегмент. Якщо підтвердження не отримане після закінчення часу, сегмент передається повторно. <br /> - Коли TCP приймає дані від віддаленої сторони з'єднання, він відправляє підтвердження. Це підтвердження не відправляється негайно, а звичайно затримується на долі секунди.<br /> - TCP здійснює розрахунок контрольної суми для свого заголовка і даних. Це контрольна сума, що розраховується на кінцях з'єднання, метою якої є виявити будь-яку зміну даних у процесі передачі. Якщо сегмент прибуває з невірною контрольною сумою, TCP відкидає його і підтвердження не генерується. (Очікується, що відправник відробить тайм-аут і здійснить повторну передачу.) <br /> - Через те що TCP сегменти передаються у вигляді IP датаграм, а IP датаграми можуть прибувати безладно, також безладно можуть прибувати і TCP сегменти. Після одержання даних TCP може по необхідності змінити їхню послідовність, у результаті додаток одержує дані в правильному порядку. <br /> - Через те що IP датаграма може бути продубльована, що TCP, який приймає, повинен відкидати продубльовані дані. <br /> - TCP здійснює контроль потоку даних. Кожна сторона TCP з'єднання має визначений простір буфера. TCP на приймаючій стороні дозволяє вилученій стороні посилати дані тільки в тому випадку, якщо одержувач може помістити них у буфер. Це запобігає переповненню буферів повільних хостів швидкими хостами.<br /> <br /> Між двома додатками по TCP з'єднання здійснюється обмін потоком 8-бітових байтів. Автоматично TCP не вставляє запису маркерів. Це називається сервісом потоку байтів (byte stream service). Якщо додаток на одному кінці записав спочатку 10 байт, потім 20 байт і потім ще 50 байт, додаток на іншому кінці з'єднання не може сказати якого розміру був кожен запис. На іншому кінці ці 80 байт можуть бути лічені, наприклад, за 4 рази по 20 байт за щораз. Один кінець з'єднання поміщає потік байт у TCP, і точно так само ідентичний потік байт з'являється на іншому кінці. <br /> <br /> TCP не інтерпретує вміст байтів. TCP поняття не має про те, чи відбувається обмін двійковими даними, ASCII символами, EBCDIC символами або чим-небудь ще. Ця інтерпретація потоку байтів здійснюється додатками на кожній стороні з'єднання.<br /> <br /> Передача TCP сегментів здійснюється у вигляді Internet датаграм. Заголовок датаграми в Internet протоколі має кілька інформаційних полів, включаючи адреси хост- комп'ютерів, що відправляють і приймають. Заголовок TCP слідує за Internet заголовком і доповнює його інформацією, специфічною для TCP протоколу. Такий розподіл допускає використання на рівні хост-комп’ютерів протоколів, інших ніж TCP. <br /> <br /> Формат TCP заголовка<br /> <br /> &lt;center&gt;[[Image:TCP1.jpg]]&lt;/center&gt;<br /> <br /> Відзначимо, що кожна мітка вказує тут місце для відповідного біта. <br /> <br /> ''Source Port'' (порт відправника) 16 біт<br /> номер порту відправника<br /> <br /> ''Destination Port'' (порт одержувача) 16 біт<br /> номер порту одержувача<br /> <br /> ''Sequence Number'' (номер черги) 32 біта<br /> Номер черги для першого октету даних у даному сегменті (за винятком тих випадків, коли є присутнім прапор синхронізації SYN). Якщо ж прапор SYN є присутнім, то номер черги є ініціалізаційним (ISN), а номер першого октету даних - ISN+1. <br /> <br /> ''Acknowledgment Number'' (номер підтвердження) 32 біта<br /> Якщо встановлено контрольний біт ACK, то це поле містить наступний номер черги, що відправник даної датаграми бажає одержати в зворотному напрямку. Номераи підтвердження посилаються постійно, як тільки з'єднання буде установлено. <br /> <br /> ''Data Offset (зсув даних)'' 4 біти<br /> Кількість 32-бітних слів у TCP заголовку. Указує на початок поля даних. TCP заголовок завжди кінчається на 32-бітній границі слова, навіть якщо він містить опції. <br /> <br /> ''Reserved 6 біт''<br /> Це резервне поле, повинне бути заповнено нулями. <br /> <br /> ''Control Bits'' (контрольні біти) 6 біт<br /> Біти цього поля зліва неправо<br /> URG: поле термінового покажчика задіяне <br /> ACK: поле підтвердження задіяне <br /> PSH: функція проштовхування <br /> RST: перезавантаження даного з'єднання <br /> SYN: синхронізація номерів черги <br /> FIN: немає більше даних для передачі<br /> <br /> ''Window (вікно)'' 16 біт<br /> Кількість октетів даних, починаючи з октету, чий номер зазначений у полі підтвердження. Кількість октетів, одержання яких чекає відправник дійсного сегмента. <br /> <br /> ''Checksum'' (контрольна сума) 16 біт<br /> Поле контрольної суми - це 16-бітне доповнення суми всіх 16- бітних слів заголовка і тексту. Якщо сегмент містить у заголовку і тексті непарну кількість октетів, що підлягають обліку в контрольній сумі, останній октет буде доповнений нулями праворуч для того, щоб утворити для надання контрольній сумі 16-бітне слово. Виниклий при такому вирівнюванні октет не передається разом із сегментом по мережі. Перед обчисленням контрольної суми поле цієї суми заповнюється нулями. <br /> <br /> Контрольна сума, крім усього іншого, враховує 96 біт псевдозаголовка, що для внутрішнього вживання ставиться перед TCP заголовком. Цей псевдозаголовок містить адресу відправника, адресу одержувача, протокол і довжину TCP сегмента. Такий підхід забезпечує захист протоколу TCP від помилившихся в маршруті сегментів. Цю інформацію обробляє Internet протокол. Вона передається через інтерфейс протокол TCP/локальна мережа як аргументи або результати запитів від протоколу TCP до протоколу IP.<br /> <br /> [[category:Комп'ютерні мережі]]</div>

Hiss https://wiki.cusu.edu.ua/index.php/TCP 2008-12-07T20:16:34Z

<p>Hiss: </p> <hr /> <div>Протокол '''TCP''' (Transmission Соntrоl Рrоtосоl - протокол керування передачею ) - протокол керування передачею даних, що використовує автоматичну повторну передачу пакетів, що містять помилки. Протокол TCP відповідає за розбивку переданої інформації на пакети і правильне відновлення інформації з пакетів одержувача.<br /> <br /> Незважаючи на те, що TCP і UDP використовують той самий мережний рівень (IP), TCP надає додаткам абсолютно інші сервиси, ніж UDP. TCP надає заснований на з'єднанні надійний сервіс потоку байтів. <br /> <br /> Термін &quot;заснований на з'єднанні&quot; (connection-oriented) означає, що два додатки, що використовують TCP (як правило, це клієнт і сервер), повинні установити TCP з'єднання один з одним, після чого в них з'являється можливість обмінюватися даними. Типова аналогія - це набір телефонного номера, чекання відповіді від вилученого абонента, коли він говорить &quot;алло&quot;, після чого необхідно сказати, хто дзвонить. <br /> <br /> TCP забезпечує свою надійність завдяки наступному: <br /> - Дані від додатка розбиваються на блоки визначеного розміру, що будуть відправлені. Це цілком відрізняється від UDP, у якому кожен запис, що здійснює додаток, генерує IP датаграму цього розміру. Блок інформації, що передається від TCP у IP, називається сегментом (segment). <br /> - Коли TCP посилає сегмент, він установлює таймер, очікуючи, що з вилученого кінця прийде підтвердження на цей сегмент. Якщо підтвердження не отримане після закінчення часу, сегмент передається повторно. <br /> - Коли TCP приймає дані від віддаленої сторони з'єднання, він відправляє підтвердження. Це підтвердження не відправляється негайно, а звичайно затримується на долі секунди.<br /> - TCP здійснює розрахунок контрольної суми для свого заголовка і даних. Це контрольна сума, що розраховується на кінцях з'єднання, метою якої є виявити будь-яку зміну даних у процесі передачі. Якщо сегмент прибуває з невірною контрольною сумою, TCP відкидає його і підтвердження не генерується. (Очікується, що відправник відробить тайм-аут і здійснить повторну передачу.) <br /> - Через те що TCP сегменти передаються у вигляді IP датаграм, а IP датаграми можуть прибувати безладно, також безладно можуть прибувати і TCP сегменти. Після одержання даних TCP може по необхідності змінити їхню послідовність, у результаті додаток одержує дані в правильному порядку. <br /> - Через те що IP датаграма може бути продубльована, що TCP, який приймає, повинен відкидати продубльовані дані. <br /> - TCP здійснює контроль потоку даних. Кожна сторона TCP з'єднання має визначений простір буфера. TCP на приймаючій стороні дозволяє вилученій стороні посилати дані тільки в тому випадку, якщо одержувач може помістити них у буфер. Це запобігає переповненню буферів повільних хостів швидкими хостами.<br /> <br /> Між двома додатками по TCP з'єднання здійснюється обмін потоком 8-бітових байтів. Автоматично TCP не вставляє запису маркерів. Це називається сервісом потоку байтів (byte stream service). Якщо додаток на одному кінці записав спочатку 10 байт, потім 20 байт і потім ще 50 байт, додаток на іншому кінці з'єднання не може сказати якого розміру був кожен запис. На іншому кінці ці 80 байт можуть бути лічені, наприклад, за 4 рази по 20 байт за щораз. Один кінець з'єднання поміщає потік байт у TCP, і точно так само ідентичний потік байт з'являється на іншому кінці. <br /> <br /> TCP не інтерпретує вміст байтів. TCP поняття не має про те, чи відбувається обмін двійковими даними, ASCII символами, EBCDIC символами або чим-небудь ще. Ця інтерпретація потоку байтів здійснюється додатками на кожній стороні з'єднання.<br /> <br /> Передача TCP сегментів здійснюється у вигляді Internet датаграм. Заголовок датаграми в Internet протоколі має кілька інформаційних полів, включаючи адреси хост- комп'ютерів, що відправляють і приймають. Заголовок TCP слідує за Internet заголовком і доповнює його інформацією, специфічною для TCP протоколу. Такий розподіл допускає використання на рівні хост-комп’ютерів протоколів, інших ніж TCP. <br /> <br /> Формат TCP заголовка<br /> <br /> &lt;center&gt;[[Image:TCP1.jpg]]&lt;/center&gt;<br /> <br /> Відзначимо, що кожна мітка вказує тут місце для відповідного біта. <br /> <br /> Source Port (порт відправника) 16 біт<br /> номер порту відправника<br /> <br /> Destination Port (порт одержувача) 16 біт<br /> номер порту одержувача<br /> <br /> Sequence Number (номер черги) 32 біта<br /> Номер черги для першого октету даних у даному сегменті (за винятком тих випадків, коли є присутнім прапор синхронізації SYN). Якщо ж прапор SYN є присутнім, то номер черги є ініціалізаційним (ISN), а номер першого октету даних - ISN+1. <br /> <br /> Acknowledgment Number (номер підтвердження) 32 біта<br /> Якщо встановлено контрольний біт ACK, то це поле містить наступний номер черги, що відправник даної датаграми бажає одержати в зворотному напрямку. Номераи підтвердження посилаються постійно, як тільки з'єднання буде установлено. <br /> <br /> Data Offset (зсув даних) 4 біти<br /> Кількість 32-бітних слів у TCP заголовку. Указує на початок поля даних. TCP заголовок завжди кінчається на 32-бітній границі слова, навіть якщо він містить опції. <br /> <br /> Reserved 6 біт<br /> Це резервне поле, повинне бути заповнено нулями. <br /> <br /> Control Bits (контрольні біти) 6 біт<br /> Біти цього поля зліва неправо<br /> URG: поле термінового покажчика задіяне <br /> ACK: поле підтвердження задіяне <br /> PSH: функція проштовхування <br /> RST: перезавантаження даного з'єднання <br /> SYN: синхронізація номерів черги <br /> FIN: немає більше даних для передачі<br /> <br /> <br /> [[category:Комп'ютерні мережі]]</div>

Hiss https://wiki.cusu.edu.ua/index.php/TCP 2008-12-07T19:56:25Z

<p>Hiss: </p> <hr /> <div>Протокол '''TCP''' (Transmission Соntrоl Рrоtосоl - протокол керування передачею ) - протокол керування передачею даних, що використовує автоматичну повторну передачу пакетів, що містять помилки. Протокол TCP відповідає за розбивку переданої інформації на пакети і правильне відновлення інформації з пакетів одержувача.<br /> <br /> Незважаючи на те, що TCP і UDP використовують той самий мережний рівень (IP), TCP надає додаткам абсолютно інші сервиси, ніж UDP. TCP надає заснований на з'єднанні надійний сервіс потоку байтів. <br /> <br /> Термін &quot;заснований на з'єднанні&quot; (connection-oriented) означає, що два додатки, що використовують TCP (як правило, це клієнт і сервер), повинні установити TCP з'єднання один з одним, після чого в них з'являється можливість обмінюватися даними. Типова аналогія - це набір телефонного номера, чекання відповіді від вилученого абонента, коли він говорить &quot;алло&quot;, після чого необхідно сказати, хто дзвонить. <br /> <br /> TCP забезпечує свою надійність завдяки наступному: <br /> - Дані від додатка розбиваються на блоки визначеного розміру, що будуть відправлені. Це цілком відрізняється від UDP, у якому кожен запис, що здійснює додаток, генерує IP датаграму цього розміру. Блок інформації, що передається від TCP у IP, називається сегментом (segment). <br /> - Коли TCP посилає сегмент, він установлює таймер, очікуючи, що з вилученого кінця прийде підтвердження на цей сегмент. Якщо підтвердження не отримане після закінчення часу, сегмент передається повторно. <br /> - Коли TCP приймає дані від віддаленої сторони з'єднання, він відправляє підтвердження. Це підтвердження не відправляється негайно, а звичайно затримується на долі секунди.<br /> - TCP здійснює розрахунок контрольної суми для свого заголовка і даних. Це контрольна сума, що розраховується на кінцях з'єднання, метою якої є виявити будь-яку зміну даних у процесі передачі. Якщо сегмент прибуває з невірною контрольною сумою, TCP відкидає його і підтвердження не генерується. (Очікується, що відправник відробить тайм-аут і здійснить повторну передачу.) <br /> - Через те що TCP сегменти передаються у вигляді IP датаграм, а IP датаграми можуть прибувати безладно, також безладно можуть прибувати і TCP сегменти. Після одержання даних TCP може по необхідності змінити їхню послідовність, у результаті додаток одержує дані в правильному порядку. <br /> - Через те що IP датаграма може бути продубльована, що TCP, який приймає, повинен відкидати продубльовані дані. <br /> - TCP здійснює контроль потоку даних. Кожна сторона TCP з'єднання має визначений простір буфера. TCP на приймаючій стороні дозволяє вилученій стороні посилати дані тільки в тому випадку, якщо одержувач може помістити них у буфер. Це запобігає переповненню буферів повільних хостів швидкими хостами.<br /> <br /> Між двома додатками по TCP з'єднання здійснюється обмін потоком 8-бітових байтів. Автоматично TCP не вставляє запису маркерів. Це називається сервісом потоку байтів (byte stream service). Якщо додаток на одному кінці записав спочатку 10 байт, потім 20 байт і потім ще 50 байт, додаток на іншому кінці з'єднання не може сказати якого розміру був кожен запис. На іншому кінці ці 80 байт можуть бути лічені, наприклад, за 4 рази по 20 байт за щораз. Один кінець з'єднання поміщає потік байт у TCP, і точно так само ідентичний потік байт з'являється на іншому кінці. <br /> <br /> TCP не інтерпретує вміст байтів. TCP поняття не має про те, чи відбувається обмін двійковими даними, ASCII символами, EBCDIC символами або чим-небудь ще. Ця інтерпретація потоку байтів здійснюється додатками на кожній стороні з'єднання.<br /> <br /> Передача TCP сегментів здійснюється у вигляді Internet датаграм. Заголовок датаграми в Internet протоколі має кілька інформаційних полів, включаючи адреси хост- комп'ютерів, що відправляють і приймають. Заголовок TCP слідує за Internet заголовком і доповнює його інформацією, специфічною для TCP протоколу. Такий розподіл допускає використання на рівні хост-комп’ютерів протоколів, інших ніж TCP. <br /> <br /> Формат TCP заголовка<br /> <br /> &lt;center&gt;[[Image:TCP1.jpg]]&lt;/center&gt;<br /> <br /> Відзначимо, що кожна мітка вказує тут місце для відповідного біта. <br /> <br /> Source Port (порт відправника) 16 біт<br /> номер порту відправника<br /> <br /> Destination Port (порт одержувача) 16 біт<br /> номер порту одержувача<br /> <br /> Sequence Number (номер черги) 32 біта<br /> Номер черги для першого октету даних у даному сегменті (за винятком тих випадків, коли є присутнім прапор синхронізації SYN). Якщо ж прапор SYN є присутнім, то номер черги є ініціалізаційним (ISN), а номер першого октету даних - ISN+1. <br /> <br /> Acknowledgment Number (номер підтвердження) 32 біта<br /> Якщо встановлено контрольний біт ACK, то це поле містить наступний номер черги, що відправник даної датаграми бажає одержати в зворотному напрямку. Номераи підтвердження посилаються постійно, як тільки з'єднання буде установлено. <br /> <br /> Data Offset (зсув даних) 4 біти<br /> Кількість 32-бітних слів у TCP заголовку. Указує на початок поля даних. TCP заголовок завжди кінчається на 32-бітній границі слова, навіть якщо він містить опції. <br /> <br /> Reserved 6 біт<br /> Це резервне поле, повинне бути заповнено нулями. <br /> <br /> Control Bits (контрольні біти) 6 біт<br /> Біти цього поля зліва неправо<br /> <br /> <br /> [[category:Комп'ютерні мережі]]</div>

Hiss https://wiki.cusu.edu.ua/index.php/TCP 2008-12-07T19:51:29Z

<p>Hiss: </p> <hr /> <div>Протокол '''TCP''' (Transmission Соntrоl Рrоtосоl - протокол керування передачею ) - протокол керування передачею даних, що використовує автоматичну повторну передачу пакетів, що містять помилки. Протокол TCP відповідає за розбивку переданої інформації на пакети і правильне відновлення інформації з пакетів одержувача.<br /> <br /> Незважаючи на те, що TCP і UDP використовують той самий мережний рівень (IP), TCP надає додаткам абсолютно інші сервиси, ніж UDP. TCP надає заснований на з'єднанні надійний сервіс потоку байтів. <br /> <br /> Термін &quot;заснований на з'єднанні&quot; (connection-oriented) означає, що два додатки, що використовують TCP (як правило, це клієнт і сервер), повинні установити TCP з'єднання один з одним, після чого в них з'являється можливість обмінюватися даними. Типова аналогія - це набір телефонного номера, чекання відповіді від вилученого абонента, коли він говорить &quot;алло&quot;, після чого необхідно сказати, хто дзвонить. <br /> <br /> TCP забезпечує свою надійність завдяки наступному: <br /> - Дані від додатка розбиваються на блоки визначеного розміру, що будуть відправлені. Це цілком відрізняється від UDP, у якому кожен запис, що здійснює додаток, генерує IP датаграму цього розміру. Блок інформації, що передається від TCP у IP, називається сегментом (segment). <br /> - Коли TCP посилає сегмент, він установлює таймер, очікуючи, що з вилученого кінця прийде підтвердження на цей сегмент. Якщо підтвердження не отримане після закінчення часу, сегмент передається повторно. <br /> - Коли TCP приймає дані від віддаленої сторони з'єднання, він відправляє підтвердження. Це підтвердження не відправляється негайно, а звичайно затримується на долі секунди.<br /> - TCP здійснює розрахунок контрольної суми для свого заголовка і даних. Це контрольна сума, що розраховується на кінцях з'єднання, метою якої є виявити будь-яку зміну даних у процесі передачі. Якщо сегмент прибуває з невірною контрольною сумою, TCP відкидає його і підтвердження не генерується. (Очікується, що відправник відробить тайм-аут і здійснить повторну передачу.) <br /> - Через те що TCP сегменти передаються у вигляді IP датаграм, а IP датаграми можуть прибувати безладно, також безладно можуть прибувати і TCP сегменти. Після одержання даних TCP може по необхідності змінити їхню послідовність, у результаті додаток одержує дані в правильному порядку. <br /> - Через те що IP датаграма може бути продубльована, що TCP, який приймає, повинен відкидати продубльовані дані. <br /> - TCP здійснює контроль потоку даних. Кожна сторона TCP з'єднання має визначений простір буфера. TCP на приймаючій стороні дозволяє вилученій стороні посилати дані тільки в тому випадку, якщо одержувач може помістити них у буфер. Це запобігає переповненню буферів повільних хостів швидкими хостами.<br /> <br /> Між двома додатками по TCP з'єднання здійснюється обмін потоком 8-бітових байтів. Автоматично TCP не вставляє запису маркерів. Це називається сервісом потоку байтів (byte stream service). Якщо додаток на одному кінці записав спочатку 10 байт, потім 20 байт і потім ще 50 байт, додаток на іншому кінці з'єднання не може сказати якого розміру був кожен запис. На іншому кінці ці 80 байт можуть бути лічені, наприклад, за 4 рази по 20 байт за щораз. Один кінець з'єднання поміщає потік байт у TCP, і точно так само ідентичний потік байт з'являється на іншому кінці. <br /> <br /> TCP не інтерпретує вміст байтів. TCP поняття не має про те, чи відбувається обмін двійковими даними, ASCII символами, EBCDIC символами або чим-небудь ще. Ця інтерпретація потоку байтів здійснюється додатками на кожній стороні з'єднання.<br /> <br /> Передача TCP сегментів здійснюється у вигляді Internet датаграм. Заголовок датаграми в Internet протоколі має кілька інформаційних полів, включаючи адреси хост- комп'ютерів, що відправляють і приймають. Заголовок TCP слідує за Internet заголовком і доповнює його інформацією, специфічною для TCP протоколу. Такий розподіл допускає використання на рівні хост-комп’ютерів протоколів, інших ніж TCP. <br /> <br /> Формат TCP заголовка<br /> <br /> &lt;center&gt;[[Image:TCP1.jpg]]&lt;/center&gt;<br /> <br /> <br /> <br /> [[category:Комп'ютерні мережі]]</div>

Hiss https://wiki.cusu.edu.ua/index.php/%D0%A4%D0%B0%D0%B9%D0%BB:TCP1.jpg 2008-12-07T19:50:59Z

<p>Hiss: </p> <hr /> <div></div>

Hiss https://wiki.cusu.edu.ua/index.php/TCP 2008-12-07T19:37:55Z

<p>Hiss: </p> <hr /> <div>Протокол '''TCP''' (Transmission Соntrоl Рrоtосоl - протокол керування передачею ) - протокол керування передачею даних, що використовує автоматичну повторну передачу пакетів, що містять помилки. Протокол TCP відповідає за розбивку переданої інформації на пакети і правильне відновлення інформації з пакетів одержувача.<br /> <br /> Незважаючи на те, що TCP і UDP використовують той самий мережний рівень (IP), TCP надає додаткам абсолютно інші сервиси, ніж UDP. TCP надає заснований на з'єднанні надійний сервіс потоку байтів. <br /> <br /> Термін &quot;заснований на з'єднанні&quot; (connection-oriented) означає, що два додатки, що використовують TCP (як правило, це клієнт і сервер), повинні установити TCP з'єднання один з одним, після чого в них з'являється можливість обмінюватися даними. Типова аналогія - це набір телефонного номера, чекання відповіді від вилученого абонента, коли він говорить &quot;алло&quot;, після чого необхідно сказати, хто дзвонить. <br /> <br /> TCP забезпечує свою надійність завдяки наступному: <br /> - Дані від додатка розбиваються на блоки визначеного розміру, що будуть відправлені. Це цілком відрізняється від UDP, у якому кожен запис, що здійснює додаток, генерує IP датаграму цього розміру. Блок інформації, що передається від TCP у IP, називається сегментом (segment). <br /> - Коли TCP посилає сегмент, він установлює таймер, очікуючи, що з вилученого кінця прийде підтвердження на цей сегмент. Якщо підтвердження не отримане після закінчення часу, сегмент передається повторно. <br /> - Коли TCP приймає дані від віддаленої сторони з'єднання, він відправляє підтвердження. Це підтвердження не відправляється негайно, а звичайно затримується на долі секунди.<br /> - TCP здійснює розрахунок контрольної суми для свого заголовка і даних. Це контрольна сума, що розраховується на кінцях з'єднання, метою якої є виявити будь-яку зміну даних у процесі передачі. Якщо сегмент прибуває з невірною контрольною сумою, TCP відкидає його і підтвердження не генерується. (Очікується, що відправник відробить тайм-аут і здійснить повторну передачу.) <br /> - Через те що TCP сегменти передаються у вигляді IP датаграм, а IP датаграми можуть прибувати безладно, також безладно можуть прибувати і TCP сегменти. Після одержання даних TCP може по необхідності змінити їхню послідовність, у результаті додаток одержує дані в правильному порядку. <br /> - Через те що IP датаграма може бути продубльована, що TCP, який приймає, повинен відкидати продубльовані дані. <br /> - TCP здійснює контроль потоку даних. Кожна сторона TCP з'єднання має визначений простір буфера. TCP на приймаючій стороні дозволяє вилученій стороні посилати дані тільки в тому випадку, якщо одержувач може помістити них у буфер. Це запобігає переповненню буферів повільних хостів швидкими хостами.<br /> <br /> Між двома додатками по TCP з'єднання здійснюється обмін потоком 8-бітових байтів. Автоматично TCP не вставляє запису маркерів. Це називається сервісом потоку байтів (byte stream service). Якщо додаток на одному кінці записав спочатку 10 байт, потім 20 байт і потім ще 50 байт, додаток на іншому кінці з'єднання не може сказати якого розміру був кожен запис. На іншому кінці ці 80 байт можуть бути лічені, наприклад, за 4 рази по 20 байт за щораз. Один кінець з'єднання поміщає потік байт у TCP, і точно так само ідентичний потік байт з'являється на іншому кінці. <br /> <br /> TCP не інтерпретує вміст байтів. TCP поняття не має про те, чи відбувається обмін двійковими даними, ASCII символами, EBCDIC символами або чим-небудь ще. Ця інтерпретація потоку байтів здійснюється додатками на кожній стороні з'єднання.<br /> <br /> <br /> <br /> [[category:Комп'ютерні мережі]]</div>

Hiss https://wiki.cusu.edu.ua/index.php/TCP 2008-12-07T19:31:47Z

<p>Hiss: </p> <hr /> <div>Протокол '''TCP''' (Transmission Соntrоl Рrоtосоl - протокол керування передачею ) - протокол керування передачею даних, що використовує автоматичну повторну передачу пакетів, що містять помилки. Протокол TCP відповідає за розбивку переданої інформації на пакети і правильне відновлення інформації з пакетів одержувача.<br /> <br /> Незважаючи на те, що TCP і UDP використовують той самий мережний рівень (IP), TCP надає додаткам абсолютно інші сервиси, ніж UDP. TCP надає заснований на з'єднанні надійний сервіс потоку байтів. <br /> <br /> Термін &quot;заснований на з'єднанні&quot; (connection-oriented) означає, що два додатки, що використовують TCP (як правило, це клієнт і сервер), повинні установити TCP з'єднання один з одним, після чого в них з'являється можливість обмінюватися даними. Типова аналогія - це набір телефонного номера, чекання відповіді від вилученого абонента, коли він говорить &quot;алло&quot;, після чого необхідно сказати, хто дзвонить. <br /> <br /> TCP забезпечує свою надійність завдяки наступному: <br /> - Дані від додатка розбиваються на блоки визначеного розміру, що будуть відправлені. Це цілком відрізняється від UDP, у якому кожен запис, що здійснює додаток, генерує IP датаграму цього розміру. Блок інформації, що передається від TCP у IP, називається сегментом (segment). <br /> - Коли TCP посилає сегмент, він установлює таймер, очікуючи, що з вилученого кінця прийде підтвердження на цей сегмент. Якщо підтвердження не отримане після закінчення часу, сегмент передається повторно. <br /> - Коли TCP приймає дані від віддаленої сторони з'єднання, він відправляє підтвердження. Це підтвердження не відправляється негайно, а звичайно затримується на долі секунди.<br /> - TCP здійснює розрахунок контрольної суми для свого заголовка і даних. Це контрольна сума, що розраховується на кінцях з'єднання, метою якої є виявити будь-яку зміну даних у процесі передачі. Якщо сегмент прибуває з невірною контрольною сумою, TCP відкидає його і підтвердження не генерується. (Очікується, що відправник відробить тайм-аут і здійснить повторну передачу.) <br /> - Через те що TCP сегменти передаються у вигляді IP датаграм, а IP датаграми можуть прибувати безладно, також безладно можуть прибувати і TCP сегменти. Після одержання даних TCP може по необхідності змінити їхню послідовність, у результаті додаток одержує дані в правильному порядку. <br /> - Через те що IP датаграма може бути продубльована, що TCP, який приймає, повинен відкидати продубльовані дані. <br /> - TCP здійснює контроль потоку даних. Кожна сторона TCP з'єднання має визначений простір буфера. TCP на приймаючій стороні дозволяє вилученій стороні посилати дані тільки в тому випадку, якщо одержувач може помістити них у буфер. Це запобігає переповненню буферів повільних хостів швидкими хостами.<br /> <br /> <br /> <br /> <br /> [[category:Комп'ютерні мережі]]</div>

Hiss https://wiki.cusu.edu.ua/index.php/FTP 2008-12-07T19:12:50Z

<p>Hiss: </p> <hr /> <div>FTP (RFC-959) забезпечує файловий обмін між віддаленими користувачами. Протокол FTP формувався багато років. Перші реалізації в МТИ відносяться до 1971. (RFC 114 і 141). RFC 172 розглядає протокол, орієнтований на користувача, і призначений для передачі файлів між ЕОМ. Пізніше в документах RFC 265 і RFC 281 протокол був удосконалений. Помітній переробці протокол піддався в 1973, і остаточний вигдяд він знайшов у 1985 році. Таким чином, даний протокол є одним з найстарших.<br /> Для реалізації обміну між двома персональними ЕОМ у межах мережі (програмні пакети PCTCP, і т.д.) можна резидентно завантажити FTPSRV або іншу еквівалентну програму. Також як і у випадку TELNET необхідна ідентифікація, але багато депозитаріїв допускають анонімний вхід (ім'я користувача ANONYMOUS, RFC-1635), що не вимагає слова пропуску (пароля) або допускає уведення вашої поштової адреси замість нього <br /> <br /> Робота FTP на користувацькому рівні містить кілька етапів:<br /> <br /> 1. Ідентифікація (введення імені-ідентифікатора і пароля).<br /> 2. Вибір каталогу.<br /> 3. Визначення режиму обміну (поблочний, потоковий, ASCII або двійковий).<br /> 4. Виконання команд обміну (get, mget, dir, mdel, mput або put).<br /> 5. Завершення процедури (quit або close).<br /> <br /> FTP досить незвичайна процедура, тому що підтримує два логічні зв'язки між ЕОМ. Один зв'язок служить для віддаленого доступу і використовує протокол Telnet. Інший зв'язок призначений для обміну даними. Сервер робить операцію passive open для порту 21 і чекає з'єднання з клієнтом. Клієнт здійснює операцію active open для порту 21. Канал залишається активним до завершення процедури FTP. TOS (тип IP-сервісу) відповідає мінімуму затримки, тому що цей канал використовується для ручного введення команд. Канал для передачі даних (TCP) формується щораз для пересилання файлів. Канал відкривається перед початком пересилання і закривається по коду end_of_file (кінець файлу). IP-тип сервісу (TOS) у цьому випадку орієнтований на максимальну пропускну здатність.<br /> <br /> Кінцевий користувач взаємодіє з протокольним інтерпретатором, у задачі якого входить керування обміном інформацією між користувачем і файловою системою, як місцевої, так і вилученої. Схема взаємодії різних частин Internet при роботі FTP зображена на мал. нижче<br /> <br /> &lt;center&gt;[[Image:FTP.jpg]]&lt;/center&gt;<br /> <br /> Спочатку по запиту клієнта формується канал керування, що надалі використовується для передачі команд від клієнта і відгуків від сервера. Інформаційний канал формується сервером по команді клієнта, він не повинний існувати постійно протягом усієї FTP-сесії і може формуватися і ліквідуватися в міру необхідності. Канал керування може бути закритий тільки після завершення інформаційного обміну. Для каналу керування використовується протокол Telnet. Після того як керуючий канал сформований, клієнт може посилати по ньому команди. Сервер сприймає, інтерпретує ці команди і передає відгуки.<br /> <br /> Можлива й інша схема взаємодії, коли з ініціативи клієнта здійснюється файловий обмін між двома ЕОМ, жодна з яких не є машиною клієнта.<br /> <br /> &lt;center&gt;[[Image:FTP2.gif]]&lt;/center&gt;<br /> <br /> На фазі завдання режиму обміну надаються наступні можливості:<br /> - Команда Block зберігає структуру логічних записів файлу.<br /> - Команда Stream встановлює режим, при якому не виробляється пересилання контрольної інформації для блоків. Це найбільш швидкий режим обміну, він працює за замовчуванням.<br /> - Команда TYPE може задати режими обміну IMAGE, ASCII або EBCDIC. З них ASCII - використовується за замовчуванням. Режим EBCDIC застосовується для обмінів між ЕОМ, що працюють з набором символів EBCDIC. Режим IMAGE припускає обмін 8-бітними байтами, використовується для передачі двійкової (а не текстової) інформації. Структурно інформація може передаватися у вигляді файлів (структура за замовчуванням), у вигляді послідовності записів (застосовно для текстових файлів ASCII або EBCDIC) або посторінково (остання структура не відноситься до числа що рекомендуються).<br /> <br /> Для копіювання файлу з віддаленого сервера використовується команда GET, для копіювання групи файлів - MGET, в останньому випадку застосовуються символи замінники, наприклад, MGET *.txt (або RFC-18*.txt, при цьому копіюються файли з RFC-1800.txt до RFC-1899.txt, якщо такі існують у поточному каталозі). Аналогом команди GET в якійсь мірі є команда DIR (ls), тільки вона переносить вміст каталогу, що для деяких операційних систем еквівалентно. При використанні модифікації mget виявляйте обережність - ви можете заблокувати телекомунікаційний канал тривалим копіюванням. Для запису файлу у віддалений сервер застосовується команда PUT. При операціях обміну звичайно використовується поточний каталог локальної ЕОМ. У вашому розпорядженні завжди мається можливість поміняти місцевий каталог за допомогою команди LCD або її аналога.<br /> Будь-яка команда обміну виконується в кілька етапів:<br /> - Формування каналу під керуванням клієнта, тому що саме клієнт видав команду get, dir, put і т.д.<br /> - Клієнт вибирає довільний номер порту на своєї ЕОМ і здійснює процедуру passive open для цього порту.<br /> - Клієнт посилає номер порту серверу по каналу керування (порт 21), використовуючи команду PORT. Можна обійтися і без команди PORT (використовується той же порт, що й у командному каналі), але це збільшує затримки і з цієї причини не рекомендується.<br /> - Сервер одержує номер порту по каналу керування і видає команду active open у зазначений порт Еом-клієнта. Сервер для каналу даних завжди використовує порт із номером 20.<br /> <br /> <br /> [[category:Комп'ютерні мережі]]</div>

Hiss https://wiki.cusu.edu.ua/index.php/%D0%A4%D0%B0%D0%B9%D0%BB:FTP2.gif 2008-12-07T19:08:03Z

<p>Hiss: </p> <hr /> <div></div>

Hiss https://wiki.cusu.edu.ua/index.php/FTP 2008-12-07T19:07:34Z

<p>Hiss: </p> <hr /> <div>FTP (RFC-959) забезпечує файловий обмін між віддаленими користувачами. Протокол FTP формувався багато років. Перші реалізації в МТИ відносяться до 1971. (RFC 114 і 141). RFC 172 розглядає протокол, орієнтований на користувача, і призначений для передачі файлів між ЕОМ. Пізніше в документах RFC 265 і RFC 281 протокол був удосконалений. Помітній переробці протокол піддався в 1973, і остаточний вигдяд він знайшов у 1985 році. Таким чином, даний протокол є одним з найстарших.<br /> Для реалізації обміну між двома персональними ЕОМ у межах мережі (програмні пакети PCTCP, і т.д.) можна резидентно завантажити FTPSRV або іншу еквівалентну програму. Також як і у випадку TELNET необхідна ідентифікація, але багато депозитаріїв допускають анонімний вхід (ім'я користувача ANONYMOUS, RFC-1635), що не вимагає слова пропуску (пароля) або допускає уведення вашої поштової адреси замість нього <br /> <br /> Робота FTP на користувацькому рівні містить кілька етапів:<br /> <br /> 1. Ідентифікація (введення імені-ідентифікатора і пароля).<br /> 2. Вибір каталогу.<br /> 3. Визначення режиму обміну (поблочний, потоковий, ASCII або двійковий).<br /> 4. Виконання команд обміну (get, mget, dir, mdel, mput або put).<br /> 5. Завершення процедури (quit або close).<br /> <br /> FTP досить незвичайна процедура, тому що підтримує два логічні зв'язки між ЕОМ. Один зв'язок служить для віддаленого доступу і використовує протокол Telnet. Інший зв'язок призначений для обміну даними. Сервер робить операцію passive open для порту 21 і чекає з'єднання з клієнтом. Клієнт здійснює операцію active open для порту 21. Канал залишається активним до завершення процедури FTP. TOS (тип IP-сервісу) відповідає мінімуму затримки, тому що цей канал використовується для ручного введення команд. Канал для передачі даних (TCP) формується щораз для пересилання файлів. Канал відкривається перед початком пересилання і закривається по коду end_of_file (кінець файлу). IP-тип сервісу (TOS) у цьому випадку орієнтований на максимальну пропускну здатність.<br /> <br /> Кінцевий користувач взаємодіє з протокольним інтерпретатором, у задачі якого входить керування обміном інформацією між користувачем і файловою системою, як місцевої, так і вилученої. Схема взаємодії різних частин Internet при роботі FTP зображена на мал. нижче<br /> <br /> &lt;center&gt;[[Image:FTP.jpg]]&lt;/center&gt;<br /> <br /> Спочатку по запиту клієнта формується канал керування, що надалі використовується для передачі команд від клієнта і відгуків від сервера. Інформаційний канал формується сервером по команді клієнта, він не повинний існувати постійно протягом усієї FTP-сесії і може формуватися і ліквідуватися в міру необхідності. Канал керування може бути закритий тільки після завершення інформаційного обміну. Для каналу керування використовується протокол Telnet. Після того як керуючий канал сформований, клієнт може посилати по ньому команди. Сервер сприймає, інтерпретує ці команди і передає відгуки.<br /> <br /> Можлива й інша схема взаємодії, коли з ініціативи клієнта здійснюється файловий обмін між двома ЕОМ, жодна з яких не є машиною клієнта.<br /> <br /> [[category:Комп'ютерні мережі]]</div>

Hiss