Transport multiservis tarmog'ining protokol arxitekturasi. UDP protokoli Udp so'rovlari

UDP (User Datagram Protocol) - IP tarmoqlari orqali ulanishsiz ma'lumotlarni uzatish uchun transport protokoli. Bu OSI modelining eng oddiy transport sathi protokollaridan biridir. Uning IP identifikatori 0x11.

UDP odatda video oqimlari va kabi ilovalarda qo'llaniladi Kompyuter o'yinlari, paketni yo'qotish maqbul bo'lgan va so'rovni qayta urinish qiyin yoki asoslanmagan yoki ulanishni yaratish qayta yuborishdan ko'ra ko'proq resurslarni talab qiladigan muammoga javob beruvchi ilovalarda (masalan, DNS so'rovlari). Aslida, UDP funktsiyalari multiplekslash va demultiplekslash operatsiyalariga, shuningdek, ma'lumotlardagi oddiy xatolarni tekshirishga tushadi. Shunday qilib, U DP dan foydalanilganda, dastur deyarli to'g'ridan-to'g'ri IP tarmoq sathi protokoli bilan bog'lanadi.

UDP dastur sathidan xabarlarni qabul qiladi, qabul qiluvchi tomonidan demultiplekslash uchun manba va maqsad port maydonlarini, shuningdek, ikkita boshqa maxsus maydonlarni qo'shadi va natijada olingan segmentni tarmoq qatlamiga o'tkazadi. Tarmoq qatlami segmentni datagrammaga o'rab oladi va uni "iloji bo'lsa" maqsadli xostga yo'naltiradi. Agar ikkinchisi segmentni muvaffaqiyatli qabul qilsa, UDP maqsad port raqami maydonidan foydalanib segment ma'lumotlarini kerakli jarayonga yo'naltiradi. Shuning uchun UDP ulanishsiz ma'lumotlarni uzatishni amalga oshiradi.

UDP protokol xizmatlaridan foydalanadigan amaliy qatlam protokoliga misol DNS hisoblanadi. DNS ilovasi so'rovni yaratganda, u DNS xabarini yaratadi va uni UDP protokoliga uzatadi.

UDP va TCP protokollarini solishtirish.

Agar ilova xabarni yetkazib berishni tasdiqlashni talab qilsa, u protokoldan foydalanadi TCP. TCP xabarni segmentlar deb ataladigan kichikroq qismlarga ajratadi. Ushbu segmentlar ketma-ket raqamlanadi va IP protokoliga o'tkaziladi, keyin esa paketlarni yig'adi. TCP ma'lum bir dastur tomonidan ma'lum bir xostga yuborilgan segmentlar sonini kuzatib boradi. Agar jo'natuvchi ma'lum vaqt ichida tasdiqni olmagan bo'lsa, TCP bu segmentlarni yetim deb hisoblaydi va ularni qayta yuboradi. Xabarning faqat yo'qolgan qismi qayta yuboriladi, butun xabar emas.

Qabul qiluvchi tugundagi TCP protokoli xabar segmentlarini qayta yig'ish va ularni tegishli dasturga uzatish uchun javobgardir.

FTP va HTTP ma'lumotlarni uzatish uchun TCP dan foydalanadigan ilovalarga misoldir.

Protokol UDP kafolatlanmagan ma'lumotlarni yetkazib berishni amalga oshiradi va qabul qiluvchidan tasdiqlashni talab qilmaydi. UDP - bu Internet protokoli (VoIP) orqali audio, video va ovozni uzatish uchun afzal qilingan protokol. Yetkazib berishni tasdiqlash faqat ma'lumotlarni uzatish jarayonini sekinlashtiradi va qayta yetkazib berish tavsiya etilmaydi. UDP protokolidan foydalanishga misol sifatida Internet radiosini keltirish mumkin.

ARP protokoli. Ilova.

ARP(inglizcha) Manzilni hal qilish protokoli- manzilni aniqlash protokoli) - kompyuter tarmoqlarida qo'llaniladigan past darajadagi protokol bo'lib, ma'lum tarmoq sathi manzilidan bog'lanish qatlami manzilini aniqlash uchun mo'ljallangan. Ushbu protokol Ethernet tepasida qurilgan IP tarmoqlarining keng tarqalganligi tufayli eng keng tarqalgan bo'lib qoldi, chunki deyarli 100% hollarda ARP bu kombinatsiya bilan qo'llaniladi. Protokol tavsifi 1982 yil noyabr oyida RFC 826 da nashr etilgan. ARP Ethernet segmenti orqali IP-paketlarni uzatish uchun mo'ljallangan. Qayerda umumiy tamoyil, ARP uchun taklif qilingan, boshqa turdagi tarmoqlar uchun ishlatilishi mumkin va ishlatilgan.

ARP xabarlarining quyidagi turlari mavjud: ARP so'rovi va ARP javobi. Yuboruvchi tizim qabul qiluvchi tizimning jismoniy manzilini so'rash uchun ARP so'rovidan foydalanadi. Javob (maqsad hostining jismoniy manzili) ARP javobi shaklida keladi.

Tarmoq qatlami paketi Ethernet segmenti orqali yuborilishidan oldin, tarmoq stegi ARP keshini tekshiradi va maqsad xost haqida kerakli ma'lumotlar allaqachon ro'yxatdan o'tganligini tekshiradi. Agar ARP keshida bunday yozuv bo'lmasa, u holda ARP translyatsiyasi so'rovi amalga oshiriladi. Tarmoqdagi qurilmalar uchun ushbu so'rov quyidagi ma'noga ega: "Quyidagi IP manzilga ega qurilmaning jismoniy manzilini kimdir biladimi?" Ushbu IP manzilga ega bo'lgan qabul qiluvchi ushbu paketni olganida, u javob berishi kerak: “Ha, bu mening IP manzilim. Mening jismoniy manzilim: …” Shundan so‘ng jo‘natuvchi o‘zining ARP keshini yangilaydi va ma’lumotni qabul qiluvchiga uzata oladi.

ARP kesh yozuvlari statik yoki dinamik bo'lishi mumkin. Yuqorida keltirilgan misol dinamik kesh yozuvini tavsiflaydi. ARP jadvalida statik yozuvlarni ham yaratishingiz mumkin.

ARP dastlab nafaqat IP protokoli uchun ishlab chiqilgan, balki hozirda asosan IP va MAC manzillarini xaritalash uchun ishlatiladi.

Ish printsipi

IP-manzilni mahalliy manzilga moslashtirishi kerak bo'lgan tugun ARP so'rovini hosil qiladi, uni bog'lovchi qatlam protokoli ramkasiga kiritadi, unda ma'lum IP-manzilni ko'rsatadi va so'rovni uzatadi.

Mahalliy tarmoqdagi barcha xostlar ARP so'rovini oladi va u erda ko'rsatilgan IP manzilni o'zlari bilan solishtiradi.

Agar ular mos kelsa, tugun ARP javobini yaratadi, unda u o'zining IP manzilini va mahalliy manzilini ko'rsatadi va uni allaqachon yo'naltirilgan yuboradi, chunki ARP so'rovida jo'natuvchi o'zining mahalliy manzilini ko'rsatadi.

Menga maqolalar turkumi juda yoqadi, bundan tashqari men har doim o‘zimni tarjimon sifatida sinab ko‘rmoqchi edim. Ehtimol, maqola tajribali ishlab chiquvchilar uchun juda ravshan bo'lib tuyulishi mumkin, ammo menimcha, bu har qanday holatda ham foydali bo'ladi.

Salom, mening ismim Glenn Fidler va men sizni onlayn kitobimning birinchi maqolasi bilan tabriklayman, O'yinni ishlab chiquvchilar uchun tarmoq dasturlash.

Ushbu maqolada biz tarmoq dasturlashning eng asosiy jihatlari - tarmoq orqali ma'lumotlarni qabul qilish va uzatishdan boshlaymiz. Ma'lumotlarni qabul qilish va uzatish tarmoq dasturchilari bajaradigan barcha vazifalarning eng asosiy va eng oddiy qismidir, lekin qaysi yo'lni davom ettirish yaxshiroq ekanligini aniqlash qiyin. Ushbu qismga etarlicha e'tibor bering - agar sizda tushunmovchilik bo'lsa, bu keyinchalik multiplayer o'yiningiz uchun dahshatli oqibatlarga olib kelishi mumkin!

Siz rozetkalar haqida allaqachon eshitgansiz va ular ikkita asosiy turda - TCP va UDPda kelishini bilishingiz mumkin. Ko'p o'yinchi o'yinini ishlab chiqishda qaror qabul qilishingiz kerak bo'lgan birinchi narsa bu qanday rozetkalardan foydalanish - TCP, UDP yoki ikkalasi?

Soket turini tanlash butunlay siz ishlab chiqayotgan o'yin janriga bog'liq. Ushbu maqolalar seriyasida men siz Halo, Battlefield 1942, Quake, Unreal, CounterStrike, Team Fortress va boshqalar kabi jangovar o'yin yozyapsiz deb taxmin qilaman.

Endi biz rozetkalarning har bir turining xususiyatlarini batafsil ko'rib chiqamiz (biz harakat uslubidagi o'yinni ishlab chiqayotganimizni hisobga olgan holda) va Internet qanday ishlashining tafsilotlariga biroz chuqurroq kirib boramiz. Batafsil ko'rib chiqilgandan so'ng, to'g'ri variant aniq bo'ladi!

TCP "uzatishni boshqarish protokoli" degan ma'noni anglatadi va IP "internet protokoli" degan ma'noni anglatadi. Ular birgalikda Internetda qilayotgan deyarli hamma narsani, ya'ni veb-sahifalarni ko'rishdan tortib IRC va elektron pochta aloqalarigacha - barchasi TCP/IP da ishlaydi.

Agar siz TCP rozetkalaridan foydalangan bo'lsangiz, TCP ishonchli ulanish printsipidan foydalanadigan protokol ekanligini bilishingiz kerak. Bu shuni anglatadiki, siz ikkita kompyuter o'rtasida aloqa o'rnatasiz va keyin ular o'rtasida ma'lumot yuborasiz, xuddi bitta kompyuterdagi faylga ma'lumot yozib, boshqa kompyuterda xuddi shu fayldan o'qiyotgandek.

Bunday holda, ulanish ishonchli va izchil hisoblanadi - ya'ni siz yuborgan barcha ma'lumotlar qabul qiluvchiga qanday tartibda yuborilgan bo'lsa, xuddi shunday tartibda etib borishi kafolatlanadi. Shuningdek, TCP ulanishini ma'lumotlarning uzluksiz oqimi deb hisoblash mumkin - protokolning o'zi ma'lumotlarni paketlarga ajratish va ularni tarmoq orqali yuborish haqida g'amxo'rlik qiladi.

Yana bir bor - hamma narsa oddiy yozish yoki fayldan o'qish kabi oddiy. Boshlang'ich Uotson!

Ammo bu foydalanish qulayligi aslida "kaput ostida" sodir bo'ladigan narsadan, pastroq darajada - IP protokoli darajasidan butunlay farq qiladi.

Bu darajada ulanish tushunchasi mavjud emas - buning o'rniga alohida paketlar bir kompyuterdan ikkinchisiga uzatiladi. Siz bu jarayonni odamlar bilan to'la xonada bir odamdan ikkinchisiga eslatma o'tkazish deb o'ylashingiz mumkin: oxirida eslatma kerakli odamga tushadi, lekin ayni paytda ko'p qo'llardan o'tadi.

Biroq, eslatma adresatga etib borishiga kafolat yo'q. Yuboruvchi shunchaki xat keladi degan umidda xat jo'natadi, lekin xat kelgan-kelmaganini ham bilmaydi - oluvchi javob yozishga qaror qilmaguncha.
Tabiiyki, aslida hamma narsa biroz murakkabroq, chunki jo'natuvchi kompyuter tarmoqdagi kompyuterlarning aniq ketma-ketligini bilmaydi, bu orqali paket imkon qadar tezroq yetib borishi uchun uzatilishi kerak. Ba'zan IP bir xil paketning bir nechta nusxalarini uzatadi, ular manzilga erishish uchun turli yo'llarni bosib o'tishi mumkin va har xil vaqtda kelishi mumkin.

Agar biz kompyuterlar o'rtasida ma'lumotni faylni o'qish/yozish uslubida emas, balki to'g'ridan-to'g'ri individual paketlarni yuborish va qabul qilish orqali uzatishni istasak nima bo'ladi?

Biz buni UDP yordamida amalga oshirishimiz mumkin. UDP "foydalanuvchi datagram protokoli" degan ma'noni anglatadi va u IP ustida ishlaydi (masalan, TCP), lekin ko'p funktsiyani qo'shish o'rniga bu IP-ga kichik qo'shimcha hisoblanadi.

UDP-dan foydalanib, biz paketni ma'lum bir IP-manzilga (masalan, 112.140.20.10) va portga (masalan, 52423) yuborishimiz mumkin va u belgilangan joyga yetguncha (yoki yo'qolib ketguncha) kompyuterdan kompyuterga uzatiladi. yo'l).

Shu bilan birga, qabul qiluvchi tomonda biz ma'lum bir portni (bizning holimizda 52423) tinglagan holda o'tiramiz va kutamiz va kimdirdan paket kelganida (hech qanday ulanish ishlatilmasligini unutmang), biz bu haqda bildirishnoma olamiz. jo'natuvchi kompyuterning manzili va porti, paket hajmi va shundan so'ng biz ushbu paketdagi ma'lumotlarni o'qiy olamiz.

UDP protokoli ma'lumotlarni yetkazib berishni kafolatlamaydi. Amalda, ko'pchilik paketlar, albatta, keladi, lekin har doim taxminan 1-5% yo'qotish bo'ladi va ba'zida paketlar umuman kelmaydigan vaqtlar mavjud (esda tutingki, jo'natuvchi va qabul qiluvchi o'rtasida minglab kompyuterlar bo'lishi mumkin, ularning har qandayida u ishlamay qolishi yoki ishdan chiqishi mumkin).

Shuningdek, UDP paketlarni etkazib berish tartibini kafolatlamaydi. Siz beshta paketni tartibda yuborishingiz mumkin - 1, 2, 3, 4, 5 - lekin ular butunlay boshqacha tartibda kelishi mumkin - masalan, 3, 1, 2, 5, 4. Shunga qaramay, amalda ular katta ehtimol bilan keladi. Ko'pincha to'g'ri tartibda kelasiz, lekin bunga tayanolmaysiz!

Va nihoyat, UDP IP-ga ko'p qo'shmasa-da, u bir narsani kafolatlaydi. Agar siz paketni yo'naltirsangiz, u to'liq keladi yoki umuman kelmaydi. Shunday qilib, agar siz 256 baytlik paketni boshqa kompyuterga yuborsangiz, u paketdan faqat birinchi 100 baytni qabul qila olmaydi - u barcha 256 baytni olishi kerak. Bu haqiqatan ham UDP protokoli kafolatlaydigan yagona narsa - qolgan hamma narsa sizning elkangizga tushadi.

Shunday qilib, biz qaror qabul qilishimiz kerak - TCP yoki UDP soketlaridan foydalanishimiz kerakmi? Keling, ularning xususiyatlarini ko'rib chiqaylik:

• Ulanish printsipidan foydalanadi
• Yetkazib berish va qaytarishni kafolatlaydi
• Ma'lumotni avtomatik ravishda paketlarga ajratadi
• Ma'lumotlar juda intensiv yuborilmasligini ta'minlaydi (ma'lumotlar oqimini boshqarish)
• Foydalanish oson - fayldan yozish/o'qish kabi

• Ulanish printsipidan foydalanmaydi - uni qo'lda amalga oshirishingiz kerak bo'ladi
• Paketlarni yetkazib berish va yetkazib berish tartibini kafolatlamaydi - ular noto'g'ri tartibda, dublikat bilan kelishi yoki umuman kelmasligi mumkin!
• Siz qo'lda ma'lumotlarni paketlarga bo'lishingiz va ularni yuborishingiz kerak
• Ma'lumotni juda intensiv yuborishdan ehtiyot bo'lishingiz kerak
• Agar paket yo'qolsa, uni qandaydir tarzda kuzatib borishingiz va kerak bo'lganda uni qayta yuborishingiz kerak

Lekin yoq.

TCP-dan foydalanish, ehtimol, ko'p o'yinchi o'yinini ishlab chiqishda qilishingiz mumkin bo'lgan eng yomon xatodir. Buning sababini tushunish uchun, keling, TCP dan foydalanishni nima osonlashtiradiganini ko'rib chiqaylik!

TCP qanday ishlaydi

Xo'sh, u buni qanday qiladi?

Birinchidan, TCP ma'lumotlar oqimining abstraktsiyasidan foydalanadi - siz ushbu oqimga shunchaki bayt ma'lumotlarni yozishingiz mumkin va TCP uning belgilangan joyga etib borishiga ishonch hosil qiladi. IP ma'lumotlarni paketlarda uzatganligi va TCP IP ustida ishlaganligi sababli, TCP foydalanuvchining kirish oqimini alohida paketlarga ajratishi kerak. Shunday qilib, TCP ichida ba'zi mantiq ma'lumotlarni navbatga to'playdi va ular etarli bo'lganda, u paketni hosil qiladi va uni belgilangan joyga yuboradi.

Agar biz juda kichik paketlarni o'tkazishimiz kerak bo'lsa, bu xatti-harakatlar ko'p o'yinchi o'yinimiz uchun muammo bo'lishi mumkin. TCP ma'lum bir o'lchamdagi paketni (masalan, yuz baytdan ortiq) hosil qilish uchun etarli miqdorda to'planmaguncha ma'lumotlarimizni uzatmaslikka qaror qilishi mumkin. Va bu katta muammo, chunki mijozdan (pleyer tugmachalarini bosish) ma'lumotlarni imkon qadar tezroq serverga o'tkazish kerak va agar protokol tomonidan ma'lumotlarni buferlash tufayli kechikishlar bo'lsa, u holda mijoz tomonidagi o'yinchi uchun. o'yin yoqimli tarzda eng bo'lmaydi. Bunday holda, o'yin ob'ektlarini yangilash kechikish bilan va kamdan-kam hollarda sodir bo'ladi - holbuki biz ob'ektlarni o'z vaqtida va tez-tez yangilashimiz kerak.

TCP-da buni tuzatish imkoniyati mavjud - “TCP_NODELAY”. U protokolga ma'lumotlarning jo'natish navbatida to'planishini kutmaslik, balki darhol jo'natish kerakligini aytadi.

Afsuski, ushbu parametr o'rnatilgan bo'lsa ham, TCP onlayn o'yinlarda foydalanilganda juda ko'p muammolarga ega.

Barcha muammolarning ildizi TCP yo'qolgan yoki tartibsiz paketlarni qayta ishlash usulida yotadi, bu ishonchli va izchil ulanish xayolini yaratadi.

TCP ulanish ishonchliligini qanday ta'minlaydi

Ammo paketlardan biri kelmasa nima bo'ladi? Yoki paketlar ishlamay qolganmi yoki dublikat bilan kelgan bo'lsa?

TCP qanday ishlashining tafsilotlarini chuqur o'rganmasdan (va bu juda murakkab mavzu - uni TCP/IP Illustrated da o'qishingiz mumkin), jarayon quyidagicha ko'rinadi: TCP paketni yuboradi, paket kelmaganligini aniqlaydi. , va bir xil paketni qabul qiluvchiga qayta yuboradi. Ikki nusxadagi paketlar qabul qiluvchi tomonida yo'q qilinadi va tartibsiz kelgan paketlar hamma narsa bo'lishi kerak bo'lgan tarzda - ishonchli va tartibda bo'lishi uchun qayta tartiblanadi.

Muammo shundaki, TCP ma'lumotlar oqimini shu tarzda "sinxronlashtirganda", agar paket yo'qolsa, yo'qolgan paket qayta yuborilmaguncha (va belgilangan manzil tomonidan qabul qilinmaguncha) uzatish to'xtaydi. Agar kutish vaqtida yangi ma'lumotlar kelib tushsa, ular navbatga qo'yiladi va yo'qolgan paket kelmaguncha uni o'qiy olmaysiz. Paketni qayta yuborish qancha vaqt oladi? Bu hech bo'lmaganda paketning aylanma vaqtini (TCP qaysi paketni qayta yuborishni aniqlaganda) va yo'qolgan paketni qayta yetkazib berish vaqtini oladi. Shunday qilib, agar kompyuterlar orasidagi ping 125 ms bo'lsa, paketni qayta uzatish soniyaning beshdan bir qismini, eng yomon holatda esa yarim soniyagacha davom etadi (tasavvur qiling-a, qayta yuborilgan paket to'satdan yo'qolib qolsa). Veseluxa!

Nima uchun hech qachon ko'p o'yinchi o'yinlari uchun TCP dan foydalanmasligingiz kerak

Keling, ko'p o'yinchi o'yinining oddiy misolini ko'rib chiqaylik, masalan, 3D shooter. O'yinning tarmoq qismi juda sodda tarzda qurilgan: o'yin tsiklining har bir iteratsiyasida mijoz serverga o'yinchining barcha harakatlarining tavsifini yuboradi (bosilgan tugmalar, sichqonchaning holati va boshqalar) va har bir iteratsiya server ushbu ma'lumotlarni qayta ishlaydi. , o'yin dunyosining modelini yangilaydi va joriylarini dunyo ob'ektlarining mijoz pozitsiyalariga qaytaradi, shunda u o'yinchi uchun yangi ramka chizadi.

Shunday qilib, bizning o'yinimizda, agar paket tarmoq orqali uzatilayotganda yo'qolsa, o'yin to'xtaydi va paket qayta topshirilguncha kutadi. Mijoz tomonida o'yin ob'ektlari muzlab qoladi va serverda o'yinchilar ham harakat qila olmaydi yoki otishmaydi, chunki server yangi paketlarni qabul qila olmaydi. Yo'qotilgan paket nihoyat kelganda, u endi ahamiyatsiz bo'lgan eskirgan ma'lumotlarni o'z ichiga oladi. Bundan tashqari, bundan keyin kutish vaqtida navbatda to'plangan barcha paketlar ham keladi va ularning barchasi tsiklning bir iteratsiyasida qayta ishlanishi kerak. To'liq chalkashlik!

Afsuski, TCP ning bu xatti-harakatini o'zgartirishning hech qanday usuli yo'q va bunga hojat ham yo'q, chunki bu TCP ning ma'nosidir. Bu Internet orqali ma'lumotlar uzatishni ishonchli va izchil ma'lumotlar oqimiga aylantirish uchun zaruratdir.
Lekin bizga ishonchli va izchil ma’lumotlar oqimi kerak emas.

Mijozdan serverga imkon qadar tezroq olish uchun bizga maʼlumotlar kerak va biz maʼlumotlar qayta yuborilishini kutmoqchi emasmiz.
Shuning uchun siz hech qachon ko'p o'yinchi o'yinlari uchun TCP dan foydalanmasligingiz kerak.

Lekin kuting! Nega men UDP va TCP dan birgalikda foydalana olmayman?

Haqiqiy vaqtda o'yin ma'lumotlari, masalan, foydalanuvchi kliklari va o'yin dunyosi holati uchun faqat eng dolzarb ma'lumotlar muhim, ammo boshqa turdagi ma'lumotlar uchun, masalan, bir kompyuterdan boshqasiga yuborilgan buyruqlar to'plami, kanalning ishonchliligi va izchilligi. juda muhim bo'lishi mumkin.

Albatta, foydalanuvchi kiritishi va dunyo holati ma'lumotlari uchun UDP dan va yetkazib berilishi kafolatlanishi kerak bo'lgan ma'lumotlar uchun TCP dan foydalanish jozibador. Siz hatto buyruqlarning bir nechta "iplarini" yaratishingiz mumkin deb o'ylayotgan bo'lishingiz mumkin - masalan, biri yuklash darajalari uchun, ikkinchisi AI buyruqlari uchun. Siz shunday deb o'ylaysiz: "Agar darajani yuklash uchun ma'lumotlar paketi yo'qolib qolsa, menga AI guruhlari kerak emas, chunki ular mutlaqo bog'liq emas!" Bunday holda, siz haqsiz va har bir buyruq oqimi uchun TCP soketini yaratishga qaror qilishingiz mumkin.

Bir qarashda, bu ajoyib g'oya. Ammo muammo shundaki, TCP va UDP ikkalasi ham IP ustida ishlaganligi sababli, ikkala protokol paketlari bir-biriga ta'sir qiladi - allaqachon IP darajasida. Bu ta'sir qanday aniq namoyon bo'lishi juda murakkab savol bo'lib, u TCP-dagi ishonchlilik mexanizmlari bilan bog'liq. Lekin, har qanday holatda ham, TCP dan foydalanish odatda UDP paketining yo'qolishiga olib kelishini yodda tuting. Agar siz bu haqda ko'proq bilmoqchi bo'lsangiz, ushbu maqolani o'qishingiz mumkin.

Xulosa

Keyingi maqolalarda men buni qanday qilishni aytaman - UDP-ga asoslangan ulanishlar yordamida o'z protokolingizni amalga oshirishdan, uzatish ishonchliligi va ma'lumotlar oqimini boshqarishni amalga oshirishgacha.

Kirish

UDP oddiy datagrammaga yo'naltirilgan transport qatlami protokoli: jarayon bir vaqtning o'zida bitta UDP datagramini chiqaradi, natijada bitta IP datagram uzatiladi. Bu TCP kabi oqimga yo'naltirilgan protokollardan farqli o'laroq, bu erda dastur tomonidan chiqarilgan ma'lumotlar miqdori yuborilgan IP-datagrammalari soniga deyarli hech qanday aloqasi yo'q.

11.1-rasmda UDP datagrammasining IP datagrammaga inkapsulyatsiyasi ko'rsatilgan.

11.1-rasm UDP inkapsulyatsiyasi.

Rasmiy UDP spetsifikatsiyasi RFC 768 [Postel 1980] da berilgan.

UDP ishonchsiz protokoldir: u dastur IP qatlamiga yozadigan datagrammalarni yuboradi, lekin ularning yakuniy manziliga etib borishiga kafolat yo'q. Ishonchlilik nuqtai nazaridan, siz UDP dan foydalanishdan qochishingiz va har doim TCP kabi ishonchli protokollardan foydalanishingiz mumkin. TCP ni ko'rib chiqqandan so'ng, biz ushbu mavzuga qaytamiz va qanday turdagi ilovalar UDP dan foydalanishi mumkinligini ko'rib chiqamiz.

Ilovalar IP-datagrammasining hajmi haqida tashvishlanishga hojat yo'q. Agar u ma'lum bir tarmoq uchun MTU hajmidan kattaroq bo'lsa (2-bob, bo'limga qarang), IP-datagramma qismlarga bo'linadi. Bu, jo'natuvchi xost ulangan birinchi tarmoqdan tashqari, datagram manbadan manzilga o'tadigan har bir tarmoq uchun amal qiladi. (Biz transport MTU kontseptsiyasini 2-bobning bo'limida aniqladik.) IP bo'linishi ushbu bobning bir qismida batafsilroq muhokama qilinadi.

UDP sarlavhasi

11.2-rasmda UDP sarlavhasida mavjud maydonlar ko'rsatilgan.

11.2-rasm UDP sarlavhasi.

Port raqamlari yuborish va qabul qilish jarayonlarini ko'rsatadi. Bu shuni ko'rsatadiki, TCP va UDP IP dan kelgan ma'lumotlarni demultiplekslash uchun maqsad port raqamidan foydalanadi. IP TCP va UDP (IP sarlavhasidagi protokol qiymatidan foydalangan holda) uchun kiruvchi IP maʼlumotlargrammalarini demultipleks qilganligi sababli, TCP TCP port raqamlariga, UDP esa UDP port raqamlariga qaraydi. TCP port raqamlari UDP port raqamlaridan mustaqil.

Ushbu mustaqillikka qaramay, agar zaxiralangan xizmat TCP va UDP tomonidan taqdim etilsa, odatda ikkala transport qatlami uchun bir xil port raqami tanlanadi. Bu protokol talabi sifatida emas, balki qulaylik uchun amalga oshiriladi.

UDP uzunligi maydoni UDP sarlavhasi va UDP ma'lumotlarining baytlardagi uzunligini o'z ichiga oladi. Ushbu maydon uchun minimal qiymat 8 bayt. (Agar ma'lumotlar uzunligi nol bo'lgan UDP datagrami yuborilsa, hech qanday yomon narsa bo'lmaydi.) UDP uzunligi parametri ortiqcha. IP-datagrammasi o'zining umumiy uzunligini baytlarda o'z ichiga oladi, shuning uchun UDP datagrammasining uzunligi umumiy uzunlikdan IP sarlavhasining uzunligidan minus hisoblanadi (bu sarlavha uzunligi maydonida ko'rsatilgan).

UDP nazorat summasi

UDP nazorat summasi UDP sarlavhasi va UDP ma'lumotlarini qamrab oladi. Eslatib o'tamiz, IP sarlavhasidagi nazorat summasi faqat IP sarlavhasini qamrab oladi - u IP datagramidagi ma'lumotlarni qamrab olmaydi. UDP ham, TCP ham sarlavhalarida nazorat summalarini o'z ichiga oladi, ular sarlavha va ma'lumotlarni qamrab oladi. UDP uchun nazorat summasi ixtiyoriy, TCP uchun esa talab qilinadi.

UDP nazorat summasi (3-bo'lim, bo'lim) IP sarlavhasining nazorat summasi (to'lib ketgan 16 bitli so'zlar yig'indisi) bilan bir xil tarzda hisoblanadi, ammo farqlar mavjud. Birinchidan, UDP datagrammasi toq sonli baytlardan iborat bo'lishi mumkin, nazorat summasini hisoblash esa 16 bitli so'zlarni qo'shishni o'z ichiga oladi. Bu nazorat summasini hisoblash uchun zarur bo'lsa, datagramning oxiriga nol to'ldirish baytlarini qo'shadi. (To'ldirish baytlari uzatilmaydi.)

UDP va TCP-da faqat nazorat summasini hisoblash uchun 12 baytli psevdo-sarlavhalar (UDP datagramlari va TCP segmentlarida) mavjud. Pseudo-sarlavhalar IP sarlavhasidan ma'lum maydonlarni o'z ichiga oladi. Bularning barchasi ma'lumotlarning mo'ljallangan manziliga yetib kelganligini ikki marta tekshirish uchun amalga oshiriladi (IP ushbu xostga yuborilmagan datagrammalarni qabul qilmaydi va boshqa yuqori qatlam uchun mo'ljallangan UDP datagrammalarini yo'naltira olmaydi). 11.3-rasmda psevdo-sarlavha va UDP datagrammasi ko'rsatilgan.

11.3-rasm UDP nazorat summasini hisoblash uchun ishlatiladigan maydonlar.

Ushbu rasmda biz toq uzunlikdagi datagramni maxsus ko'rsatdik, bu holda nazorat summasini hisoblash uchun qo'shimcha bayt talab qilinadi. E'tibor bering, nazorat summasini hisoblashda UDP datagram uzunligi ikki marta paydo bo'ladi.

Hisoblangan nazorat summasi 0 bo'lsa, u barcha bitlar (65535) sifatida saqlanadi, bu qiymatlar birlik-to'ldiruvchi arifmetikada ekvivalent bo'ladi. Agar uzatilgan nazorat summasi 0 bo'lsa, bu jo'natuvchi nazorat summasini hisoblamaganligini anglatadi.

Agar jo'natuvchi nazorat summasini hisoblab chiqsa va qabul qiluvchi xatolik borligini aniqlasa, UDP datagrami jimgina yo'q qilinadi va hech qanday xato xabari yaratilmaydi. (Agar IP qatlami IP sarlavhasining nazorat summasida xatolikni aniqlasa, xuddi shunday bo'ladi.)

UDP nazorat summasi jo'natuvchi tomonidan hisoblab chiqiladi va qabul qiluvchi tomonidan tasdiqlanadi. Bu sizga UDP sarlavhasidagi yoki jo'natuvchi va qabul qiluvchi o'rtasidagi yo'lda sodir bo'lgan ma'lumotlardagi har qanday o'zgarishlarni aniqlash imkonini beradi.

UDP nazorat summasi ixtiyoriy parametr bo'lsa-da, uni har doim hisoblash kerak. 1980-yillarning oxirida ba'zi kompyuter ishlab chiqaruvchilari UDP dan foydalanadigan Tarmoq fayl tizimining (NFS) tezligini oshirish uchun sukut bo'yicha UDP nazorat summasini hisoblashni o'chirib qo'yishni boshladilar. Bu bitta LAN tarmog'ida qabul qilinishi mumkin, bunda CRC ma'lumotlar havolasi qatlamidagi (Ethernet yoki Token halqali ramkalar) freymlar uchun hisoblab chiqiladi, bu datagram routerlar orqali o'tayotganda ramka buzilishini aniqlash uchun ishlatilishi mumkin. Ishoning yoki ishonmang, ularning dasturiy ta'minoti yoki apparatida xatoliklarga ega bo'lgan marshrutizatorlar bor, ular yo'naltiradigan datagramlardagi bitlarni o'zgartiradi. Agar nazorat summasi opsiyasi o'chirilgan bo'lsa, bu xatolarni UDP datagramlarida aniqlab bo'lmaydi. Shuni ham ta'kidlash kerakki, ba'zi bir havola sathi protokollari (masalan, SLIP) havoladagi ma'lumotlar uchun nazorat summasini hisoblashning hech qanday shakliga ega emas.

Xost talablari RFC sukut bo'yicha UDP nazorat summasini hisoblashni yoqishni talab qiladi. Ular, shuningdek, qabul qilingan nazorat summasi jo'natuvchi tomonidan hisoblangan bo'lsa (qabul qilingan nazorat summasi nolga teng bo'lmagan taqdirda) tekshirilishi kerakligini talab qiladi. Ba'zi ilovalar buni e'tiborsiz qoldiradi va agar chiquvchi nazorat summasini hisoblash opsiyasi yoqilgan bo'lsa, qabul qilingan nazorat summasini tekshiradi.

tcpdump buyrug'ining chiqishi

Muayyan tizimda UDP nazorat summasini hisoblash opsiyasi yoqilganligini aniqlash juda qiyin. Odatda ilova qabul qilingan UDP sarlavhasining nazorat summasi maydoniga kirish huquqiga ega emas. Ushbu muammoni hal qilish uchun muallif tcpdump dasturiga yana bir variantni qo'shdi, shundan so'ng u qabul qilingan UDP nazorat summalarini chiqarishni boshladi. Qabul qilingan qiymat 0 bo'lsa, bu jo'natuvchi nazorat summasini hisoblamaganligini anglatadi.

11.4-rasmda tarmog'imizdagi uch xil tizimga va undan chiqish ko'rsatilgan. Biz standart echo serverga 9 bayt ma'lumotga ega bo'lgan bitta UDP datagramini jo'natib, sock() dasturini ishga tushirdik.

1 0,0 sun.1900 > gemini.echo: udp 9 (UDP cksum=6e90)
2 0,303755 (0,3038) gemini.echo > sun.1900: udp 9 (UDP csum=0)

3 17.392480 (17.0887) sun.1904 > aix.echo: udp 9 (UDP cksum=6e3b)
4 17.614371 (0.2219) aix.echo > sun.1904: udp 9 (UDP ckssum=6e3b)

5 32.092454 (14.4781) sun.1907 > solaris.echo: udp 9 (UDP cksum=6e74)
6 32.314378 (0.2219) solaris.echo > sun.1907: udp 9 (UDP cksum=6e74)

Shakl 11.4. UDP nazorat summasi opsiyasi ma'lum bir xostda yoqilganligini aniqlash uchun ishlatilishi mumkin bo'lgan tcpdump dan chiqdi.

Bu erda biz uchta tizimdan ikkitasida UDP nazorat summasi opsiyasi yoqilganligini ko'rishimiz mumkin.

Shuni ham yodda tutingki, chiquvchi datagramma kiruvchi datagramma bilan bir xil nazorat summasiga ega (3 va 4, 5 va 6-qatorlar). 11.3-rasmda ikkita IP-manzil va ikkita port raqamlari almashtirilganligini ko'rasiz. Pseudo-sarlavha va UDP sarlavhasidagi boshqa maydonlar maʼlumotlar aks-sado berilgandan beri oʻzgarishsiz qoldi. Bu UDP nazorat summasi (va haqiqatan ham TCP/IP protokollari oilasidagi barcha nazorat summalari) oddiy 16 bitli summa ekanligini tasdiqlaydi. Uning yordami bilan ikkita 16 bitli qiymatlarning joylarini o'zgartirishdan iborat bo'lgan xatoni aniqlash mumkin emas.

Ba'zi statistika

[Mogul 1992] 40 kun davomida ishlayotgan juda band NFS serverida nazorat summasi xatolarining yuzaga kelishi haqida ba'zi statistik ma'lumotlarni taqdim etadi. 11.5-rasmda statistik ma'lumotlar ko'rsatilgan.

Shakl 11.5 Tekshirish summalari yordamida aniqlangan buzilgan paketlar statistikasi.

Oxirgi ustun paketlarning taxminiy sonini ko'rsatadi, chunki boshqa protokollar Ethernet va IP qatlamidan foydalanadi. Masalan, IP-datagrammalarida hamma Ethernet freymlari ishlatilmaydi; ARP Ethernet-dan ham foydalanadi. Hamma IP datagrammalari UDP yoki TCP tomonidan ishlatilmaydi, chunki ICMP ham IP dan foydalanadi.

E'tibor bering, UDP nazorat summasi xatolaridan ko'ra ko'proq TCP nazorat summasi xatolari aniqlangan. Bu, ehtimol, TCP odatda "uzoq masofali" ulanishlarni (ko'plab marshrutizatorlar, ko'priklar va boshqalar orqali o'tadi) o'rnatishi bilan bog'liq, UDP trafik esa odatda mahalliydir.

Shuning uchun, pastki qatorda sanab o'tilgan xatolar har doim ham ma'lumotlar havolasi qatlami (Ethernet, Token ring) bilan bog'liq emas. Ma'lumotlarni uzatishda siz har doim oxirgi nuqtalarda nazorat summasini yoqishingiz kerak. Biroq, agar uzatilayotgan ma'lumotlar qandaydir qiymatga ega bo'lsa, siz UDP yoki TCP nazorat summalariga to'liq ishonmasligingiz kerak, chunki bu oddiy nazorat summalari va ular ma'lumotlarni barcha mumkin bo'lgan xatolardan himoya qilishga kafolat bermaydi.

Oddiy misol

Biz paypoq dasturidan ba'zi UDP datagramlarini yaratish uchun foydalanamiz, biz ularni tcpdump yordamida ko'rib chiqamiz:

>bsdi % paypoq -v -u -i -n4 svr4 tashlang
140.252.13.35.1108 da 140.252.13.34.9 da ulangan

bsdi % paypoq -v -u -i -n4 -w0 svr4 tashlang
140.252.13.35.1110 da 140.252.13.34.9 da ulangan

Dasturni ishga tushirishning birinchi holatida disk raskadrovka rejimi (-v) o'rnatiladi, siz dinamik ravishda tayinlangan portlar raqamlarini ko'rishingiz mumkin, sukut bo'yicha TCP o'rniga UDP (-u) ko'rsatilgan va manba rejimi o'rnatilgan, variant ( -i), bu biz standart kirishdan o'qish yoki standart chiqishga yozish o'rniga ma'lumotlarni jo'natishimizni anglatadi. -n4 opsiyasi unga 4 ta datagramni (standart 1024 o'rniga) svr4 xostiga yuborishni aytadi. Yo'q qilish xizmati 1-bobdagi bo'limda tasvirlangan. Biz har bir yozuv uchun 1024 baytlik standart chiqish hajmidan foydalanamiz.

Biz dasturni ikkinchi marta ishga tushirganimizda, -w0 ni belgilab, bu nol uzunlikdagi datagramlarni hosil qiladi. 11.6-rasmda ikkita misol uchun tcpdump buyrug'ining chiqishi ko'rsatilgan.

1 0,0 bsdi.1108 > svr4.discard: udp 1024
2 0,002424 (0,0024) bsdi.1108 > svr4.discard: udp 1024
3 0,006210 (0,0038) bsdi.1108 > svr4.discard: udp 1024
4 0,010276 (0,0041) bsdi.1108 > svr4.discard: udp 1024

5 41.720114 (41.7098) bsdi.1110 > svr4.discard: udp 0
6 41.721072 (0.0010) bsdi.1110 > svr4.discard: udp 0
7 41.722094 (0.0010) bsdi.1110 > svr4.discard: udp 0
8 41.723070 (0.0010) bsdi.1110 > svr4.discard: udp 0

11.6-rasm UDP datagramlari bir yo'nalishda yuborilganda tcpdump buyrug'ining chiqishi.

Chiqish to'rtta 1024 bayt datagrammani va undan keyin to'rtta nol uzunlikdagi datagrammani ko'rsatadi. Har bir datagram bir necha millisekundlik oraliq bilan oldingisiga amal qiladi. (Ikkinchi buyruqni kiritish uchun 41 soniya kerak bo'ldi.)

Birinchi datagramma yuborilgunga qadar jo‘natuvchi va qabul qiluvchi o‘rtasida aloqa yo‘q edi. (TCP ni muhokama qilishda biz ma'lumotlarning birinchi bayti yuborilishidan oldin ulanish o'rnatilishi kerakligini ko'rsatamiz.) Shuni ta'kidlash kerakki, qabul qiluvchi ma'lumotlarni qabul qilganda tasdiqnoma bermaydi. Ushbu misolda jo'natuvchi ma'lumotlarning masofaviy uchida olinganligini bilmaydi.

Va nihoyat, dasturni har safar ishga tushirganingizda UDP manba port raqami o'zgarishini unutmang. Port birinchi bo'lib 1108, keyin 1110 edi. 1-bobda biz mijozlar tomonidan ishlatiladigan dinamik ravishda tayinlangan port raqamlari odatda 1024 dan 5000 gacha bo'lishini ko'rsatdik.

IP bo'linishi

11.9-rasmda ushbu holat uchun ICMP erishib bo'lmaydigan xato formati ko'rsatilgan. U ko'rsatilgan formatdan farq qiladi, chunki ikkinchi 32 bitli so'zdagi 16-31 bitlar 0 ga o'rnatilmagan holda keyingi MTU hop ni o'z ichiga olishi mumkin.

11.9-rasm. Parchalanish zarur bo'lganda ICMPga erishib bo'lmaydigan xatolik, lekin "parchalanma" biti o'rnatilgan.

Router ushbu yangi ICMP xato formatini qo'llab-quvvatlamasa, keyingi hop MTU 0 ga o'rnatiladi.

Yangi Router talablari RFC [Almquist 1993] marshrutizator ICMP kirish mumkin bo'lmagan xabarni chiqarganda ushbu yangi shaklni yaratishi kerakligini belgilaydi.

Biz muhokama qiladigan muammo netb router va xost quyoshi o'rtasidagi SLIP dial-up havolasining MTU ni aniqlashga urinayotganda ICMP xatosi olganimizda yuzaga keldi. Biz bu havolaning MTU ni sundan netbga bilamiz, chunki birinchidan, bu SLIP ni xost quyoshida sozlashda ko'rsatilgan, ikkinchidan, biz 3-bobning bo'limida netstat buyrug'ini ishga tushirganimizda MTU ni ko'rdik. Endi biz aniqlamoqchimiz. MTU boshqa yo'nalishda. (Bu SNMP yordamida MTUni qanday aniqlashni tushuntiradi.) Nuqtadan nuqtaga bog'lanish uchun MTU har ikki yo'nalishda ham bir xil bo'lishi shart emas.

Aniqlash uchun quyidagi texnikadan foydalanilgan. Biz host solaris-dan bsdi xostiga ping yubordik va paketlarga parchalanish qo'llanilmaguncha ma'lumotlar paketi hajmini oshirdik. Jarayon 11.10-rasmda ko'rsatilgan.

11.10-rasm Netb va quyosh o'rtasidagi SLIP aloqasining MTU ni aniqlash uchun foydalanilgan tizimlar.

Sun hostida tcpdump dasturi ishga tushirildi, bu bizga SLIP kanalida parchalanish qanday amalga oshirilayotganini ko'rish imkonini berdi. Parchalanish ko'rinmadi va ping paketidagi ma'lumotlar hajmi 500 baytdan 600 gacha ko'tarilguncha hamma narsa yaxshi edi. Kiruvchi aks-sado so'rovlari ko'rinib turardi (go'yo parchalanish yo'q), lekin aks-sado javoblari yo'qoldi.

Nima bo'layotganini yaxshiroq tushunish uchun tcpdump ham bsdi-da ishga tushirildi, shundan so'ng nima yuborilgani va nima qabul qilingani aniq bo'ldi. 11.11-rasmda chiqish ko'rsatilgan.

1 0,0 solaris >
2 0,000000 (0,0000) bsdi >
3 0,000000 (0,0000) quyosh >
parchalash kerak, mtu = 0 (DF)

4 0.738400 (0.7384) solaris > bsdi: icmp: echo soʻrovi (DF)
5 0.748800 (0.0104) bsdi > solaris: icmp: echo javob (DF)
6 0,748800 (0,0000) sun > bsdi: icmp: solarisga kirish mumkin emas -
parchalash kerak, mtu = 0 (DF)

11.11-rasm 600 bayt o'lchamdagi IP datagramma bilan solarisdan ping dan bsdi ga tcpdump dasturining chiqishi.

Birinchidan, har bir satrdagi ifoda (DF) IP sarlavhasidagi "parchalanmang" biti bittaga o'rnatilganligini bildiradi. Bu shuni anglatadiki, Solaris 2.2 odatda ushbu bitni MTU transportini aniqlash mexanizmining bir qismi sifatida o'rnatadi.

1-qator ping tarmoqdan quyoshga parchalanmasdan va DF bit o'rnatilgan holda o'tishini ko'rsatadi, shuning uchun biz SLIP xost tarmog'i uchun muhim MTU hajmiga hali erishilmagan degan xulosaga kelishimiz mumkin.

Shuningdek, 2-qatordan DF bayrog'i har bir aks-sado javobiga ko'chirilishiga e'tibor bering. Aynan shu narsa muammoga sabab bo'ldi. Echo javobi aks-sado so‘rovi bilan bir xil o‘lchamda (600 baytdan sal ko‘proq), lekin asosiy quyoshning chiquvchi SLIP interfeysining MTU qiymati 552. Echo javobi qismlarga bo‘lingan bo‘lishi kerak, lekin DF bayrog‘i o‘rnatilgan. Bu quyosh ICMP erishib bo'lmaydigan xatolikni keltirib chiqaradi va uni bsdi ga yuboradi (u yo'q qilingan joyda).

Shuning uchun biz solarisdan aks-sadolarni ko'rmadik. Javoblar quyoshdan o'tmagan. 11.12-rasmda paketlarning bosib o'tish yo'li ko'rsatilgan.

11.12-rasm Ushbu misol uchun paket almashinuvi.

Nihoyat, 11.11-rasmdagi 3 va 6-qatorlardagi mtu=0 ifodasi 11.9-rasmda ko'rsatilganidek, quyosh ICMP kirish mumkin bo'lmagan xabardagi chiquvchi interfeys uchun MTU ni qaytarmasligini ko'rsatadi. (25-bobda biz bu muammoni SNMP yordamida hal qilamiz va netb interfeysining SLIP MTU 1500 ekanligiga ishonch hosil qilamiz.)

Traceroute yordamida transport MTUni aniqlash

Ko'pgina tizimlar transport MTU ni aniqlash funktsiyasini qo'llab-quvvatlamaganligi sababli, biz traceroute() dasturini transport MTU ni aniqlashi uchun o'zgartiramiz. Biz paketni parchalanmaslik biti bilan yuboramiz. Birinchi yuborilgan paketning hajmi chiquvchi interfeysning MTU ga teng bo'ladi. ICMP "parchalanib bo'lmaydi" xatosi qaytarilsa, paketni qisqartiramiz. hajmi. Agar ICMP xatosini yuborgan yo'riqnoma ICMP xabarida MTU chiquvchi interfeysini o'z ichiga olgan yangi versiyani qo'llab-quvvatlasa, biz natijada olingan qiymatdan foydalanamiz; aks holda biz keyingi kichikroq MTUni sinab ko'ramiz. RFC 1191 [Mogul and Deering 1990] cheklangan miqdordagi MTU qiymatlari mavjudligini ta'kidlaganidek, dasturimizda jadval mavjud. mumkin bo'lgan qiymatlar va shunchaki keyingi kichikroq qiymatga o'tadi.

SLIP kanalida 296 MTU borligini bilib, xost quyoshidan xost slipiga o'xshash algoritmni sinab ko'raylik:

quyosh% traceroute.pmtu slip

chiquvchi MTU = 1500
1 bsdi (140.252.13.35) 15 ms 6 ms 6 ms
2 bsdi (140.252.13.35) 6 ms
parchalanish talab qilinadi va DF to'plami, yangi MTU = 1492 ni sinab ko'ring
parchalanish talab qilinadi va DF o'rnatildi, yangi MTU = 1006 ni sinab ko'ring
parchalanish talab qilinadi va DF o'rnatildi, yangi MTU = 576 ni sinab ko'ring
parchalanish talab qilinadi va DF o'rnatildi, yangi MTU = 552 ni sinab ko'ring
parchalanish talab qilinadi va DF o'rnatildi, yangi MTU = 544 ni sinab ko'ring
parchalanish talab qilinadi va DF o'rnatildi, yangi MTU = 512 ni sinab ko'ring
parchalanish talab qilinadi va DF o'rnatildi, yangi MTU = 508 ni sinab ko'ring
parchalanish talab qilinadi va DF o'rnatildi, yangi MTU = 296 ni sinab ko'ring
2 slip (140.252.13.65) 377 ms 377 ms 377 ms

Ushbu misolda, bsdi router ICMP xabarida chiquvchi MTU interfeysini qaytarmadi, shuning uchun biz keyingi MTU qiymatiga tushamiz. 2 TTL uchun chiqishning birinchi qatori bsdi xost nomi haqida xabar beradi, lekin bu ICMP xatosida yo'riqnoma tomonidan qaytarilganligi sababli. 2 TTL uchun oxirgi chiqish liniyasi biz kutgan narsadir.

Chiquvchi interfeysning MTU-ni olish uchun bsdi-da ICMP kodini o'zgartirish oson. Va agar biz buni qilsak va dasturimizga qaytsak, biz quyidagi natijani olamiz:

quyosh% traceroute.pmtu slip
slip uchun traceroute (140.252.13.65), maksimal 30 hops
chiquvchi MTU = 1500
1 bsdi (140.252.13.35) 53 ms 6 ms 6 ms
2 bsdi (140.252.13.35) 6 ms
parchalanish talab qilinadi va DF o'rnatiladi, keyingi hop MTU = 296
2 slip (140.252.13.65) 377 ms 378 ms 377 ms

Bu erda sakkiz xil MTU qiymatini sinab ko'rishning ma'nosi yo'q; marshrutizator kerakli qiymatni xabar qildi.

Jahon Internet

Traceroute-ning o'zgartirilgan versiyasi butun dunyo bo'ylab turli xostlarda bir necha marta ishga tushirilgan. Turli transatlantik va transpasifik kanallari yordamida 15 ta davlatga (jumladan, Antarktidaga) yetib bordi. Biroq, buni amalga oshirishdan oldin, biz pastki tarmoq va netb router (11.12-rasm) o'rtasidagi SLIP dial-up aloqasining MTU ni Ethernetdagi kabi 1500 ga oshirdik.

Dastur 18 marta ishga tushirilgandan faqat ikkitasida transport MTU 1500 dan kam bo'lgan. Bitta transatlantik havolada MTU 572 (g'alati qiymat, hatto RFC 1191 ro'yxatida ham yo'q) bo'lgan va marshrutizator qaytarmagan. Yangi formatda ICMP xatosi. Yaponiyadagi ikkita marshrutizator o'rtasidagi yana bir havola 1500 baytli kadrlarni qayta ishlamadi va yo'riqnoma yangi formatda ICMP xatosini qaytarmadi. MTU 1006 ga qisqartirilgandan so'ng, hamma narsa ishladi.

Ushbu tajribalardan xulosa qilishimiz mumkinki, ko'pchilik (ammo hammasi emas) keng tarmoqli tarmoqlar hozirda 512 baytdan katta paketlarni ishlay oladi. Transport MTU qidiruv funksiyasidan foydalanish ilovalarga kattaroq MTUlar yordamida sezilarli darajada samarali ishlash imkonini beradi.

UDP dan foydalanganda transport MTU ni aniqlash

Keling, UDP dan foydalanadigan dastur va transport MTU kashfiyot mexanizmi o'rtasidagi o'zaro ta'sirni ko'rib chiqaylik. Ilova ba'zi bir oraliq kanal uchun juda katta bo'lgan datagramni yuborganda nima sodir bo'lishini ko'rishimiz kerak.

Transport MTU kashfiyot mexanizmini qo'llab-quvvatlaydigan yagona tizim Solaris 2.x bo'lgani uchun biz undan 650 baytlik datagramni slip uchun yuborish uchun manba xost sifatida foydalanamiz. Slip xost MTU 296 bo'lgan SLIP havolasining orqasida joylashganligi sababli, 268 baytdan (296 - 20 - 8) kattaroq har qanday UDP datagrammasi "parchalanmang" bit to'plami bsdi dan ICMP "parchalash mumkin emas" xatosini keltirib chiqarishi kerak. router. 11.13-rasmda kanallarning topologiyasi va MTU ko'rsatilgan.

11.13-rasm UDP yordamida transport MTUni aniqlash uchun foydalaniladigan tizimlar.

Quyidagi buyruq 5 soniyalik oraliqda o'nta 650 baytlik UDP datagrammasini yaratadi:

>solaris % paypoq -u -i -n10 -w650 -p5 slip tashlang

11.14-rasmda tcpdump buyrug'ining chiqishi ko'rsatilgan. Ushbu misol ishga tushirilganda, bsdi router ICMP "parchalash mumkin emas" xatosining bir qismi sifatida keyingi MTU ni qaytarmaslik uchun tuzilgan.

DF bit to'plami bilan yuborilgan birinchi datagramma (1-qator) bsdi routerdan kutilgan xatoni hosil qiladi (2-qator). Qizig'i shundaki, DF bit to'plami (3-qator) bilan yuborilgan keyingi datagram bir xil ICMP xatosini (4-qator) hosil qiladi. Biz ushbu datagramma DF bit o'chirilgan holda yuborilishini kutgan edik.

5-qatorda IP nihoyat ushbu manzilga datagrammalar DF ​​bit to'plami bilan yuborilmasligi kerakligini tushundi va keyin manba xostidagi datagrammalarni qismlarga ajratishni boshladi. Ushbu xatti-harakat avvalgi misollarda ko'rsatilganidan farq qiladi, bu erda IP o'zi UDP dan olingan datagrammalarni yuborgan, kichikroq MTU (bu holda bsdi) bo'lgan marshrutizatorlarga bo'linishga ruxsat berilgan.

1 0.0 solaris.38196 > slip.discard: udp 650 (DF)
2 0.004218 (0.0042) bsdi > solaris: icmp:

3 4.980528 (4.9763) solaris.38196 > slip.discard: udp 650 (DF)
4 4.984503 (0.0040) bsdi > solaris: icmp:
slip etib bo'lmaydi - parchalanish kerak, mtu = 0 (DF)

5 9.870407 (4.8859) solaris.38196 > slip.discard: udp 650 (frag 47942:552@0+)
6 9.960056 (0.0896) solaris > slip: (frag 47942:106@552)

7 14.940338 (4.9803) solaris.38196 > slip.discard: udp 650 (DF)
8 14.944466 (0.0041) bsdi > solaris: icmp:
slip etib bo'lmaydi - parchalanish kerak, mtu = 0 (DF)

9 19.890015 (4.9455) solaris.38196 > slip.discard: udp 650 (frag 47944:552@0+)
10 19.950463 (0.0604) solaris > slip: (frag 47944:106@552)

11 24.870401 (4.9199) solaris.38196 > slip.discard: udp 650 (frag 47945:552@0+)
12 24.960038 (0.0896) solaris > slip: (frag 47945:106@552)

13 29.880182 (4.9201) solaris.38196 > slip.discard: udp 650 (frag 47946:552@0+)
14 29.940498 (0.0603) solaris > slip: (frag 47946:106@552)

15 34.860607 (4.9201) solaris.38196 > slip.discard: udp 650 (frag 47947:552@0+)
16 34.950051 (0.0894) solaris > slip: (frag 47947:106@552)

17 39.870216 (4.9202) solaris.38196 > slip.discard: udp 650 (frag 47948:552@0+)
18 39.930443 (0.0602) solaris > slip: (frag 47948:106@552)

19 44.940485 (5.0100) solaris.38196 > slip.discard: udp 650 (DF)
20 44.944432 (0.0039) bsdi > solaris: icmp:
slip etib bo'lmaydi - parchalanish kerak, mtu = 0 (DF)

11.14-rasm UDP yordamida transport MTU ni aniqlash.

ICMP "parchalash mumkin emas" xabari keyingi hop MTUni o'z ichiga olmaydi, demak, IP hamma MTU 576 dan mamnun deb qaror qildi. Birinchi fragment (5-qator) 544 bayt UDP ma'lumotlarini, 8 baytni o'z ichiga oladi. UDP sarlavhasi va 20 bayt IP sarlavhasi, IP datagrammasining umumiy hajmi 572 baytni tashkil qiladi. Ikkinchi qism (6-qator) qolgan 106 bayt UDP ma'lumotlarini va 20 baytli IP sarlavhasini o'z ichiga oladi.

Afsuski, keyingi datagramma, 7-qatorda DF bit o'rnatilgan, shuning uchun u bsdi tomonidan o'chiriladi va ICMP xatosi qaytariladi. Bu erda nima sodir bo'ldi, IP taymerining muddati tugadi, u IP-ga DF bitini qayta o'rnatish orqali transport MTU ko'payganligini tekshirishni aytdi. 19 va 20-qatorlarda bu yana sodir bo'lishini ko'ramiz. DF biti bittaga o'rnatilgan 7 va 19-qatorlardagi vaqtlarni solishtirsak, transport MTU har 30 soniyada ortib borishi tekshirilayotganini ko'ramiz.

Bu 30 soniya taymer juda qisqa. RFC 1191 taymerni 10 daqiqaga o'rnatishni tavsiya qiladi. Taymer qiymatini ip_ire_pathmtu_interval parametri yordamida o'zgartirish mumkin (Ilova E, bo'lim). Solaris 2.2 da bitta UDP ilovasi yoki barcha UDP ilovalari uchun transport MTU aniqlashni o'chirib qo'yishning hech qanday usuli yo'q. Uni faqat butun tizim uchun ip_path_mtu_discovery parametrini o'zgartirish orqali yoqish yoki o'chirish mumkin. Ushbu misoldan ko'rib turganimizdek, UDP ilovalari parchalanishi mumkin bo'lgan datagrammalarni yuborayotganda MTU transportini aniqlash xususiyatini yoqish datagrammaning o'chirilishiga olib keladi.

Solarisda IP qatlami tomonidan qabul qilingan maksimal datagram hajmi (576 bayt) noto'g'ri. Biz 11.13-rasmda haqiqiy MTU 296 bayt ekanligini ko'rdik. Bu shuni anglatadiki, solaris tomonidan yaratilgan fragmentlar bsdi-da yana parchalanadi. 11.15-rasmda birinchi datagram kelishi uchun maqsad (slip) xostida olingan tcpdump chiqishi ko'rsatilgan (11.14-rasmdagi 5 va 6-satrlar).

1 0.0 solaris.38196 > slip.discard: udp 650 (frag 47942:272@0+)
2 0.304513 (0.3045) solaris > slip: (frag 47942:272@272+)
3 0.334651 (0.0301) solaris > slip: (frag 47942:8@544+)
4 0.466642 (0.1320) solaris > slip: (frag 47942:106@552)

11.15-rasm Solarisdan slip xostga kelgan birinchi datagramma.

Ushbu misolda, solaris xosti chiquvchi datagrammalarni qismlarga ajratmasligi kerak, lekin DF bitini o'chirib qo'yishi va kichikroq MTU bilan routerga parchalanishni amalga oshirishga ruxsat berishi kerak.

Endi biz xuddi shu misolni ishga tushiramiz, lekin bsdi routerning xatti-harakatlarini o'zgartiramiz, shunda u ICMP "parchalanib bo'lmaydi" xabarida keyingi MTU hopni qaytaradi. 11.16-rasmda tcpdump chiqishining birinchi olti qatori ko'rsatilgan.

1 0.0 solaris.37974 > slip.discard: udp 650 (DF)
2 0.004199 (0.0042) bsdi > solaris: icmp:

3 4.950193 (4.9460) solaris.37974 > slip.discard: udp 650 (DF)
4 4.954325 (0.0041) bsdi > solaris: icmp:
slip etib bo'lmaydi - parchalanish kerak, mtu = 296 (DF)

5 9.779855 (4.8255) solaris.37974 > slip.discard: udp 650 (frag 35278:272@0+)
6 9.930018 (0.1502) solaris > slip: (frag 35278:272@272+)
7 9.990170 (0.0602) solaris > slip: (frag 35278:114@544)

11.16-rasm UDP yordamida transport MTU ni aniqlash.

Yana bir bor ko'ramizki, dastlabki ikkita datagramma DF bit to'plami bilan yuborilgan va ikkalasi ham ICMP xatolarini olgan. Hozirgi vaqtda ICMP xatosi keyingi MTU ni ko'rsatadi, bu 296 ga teng.

5, 6 va 7-qatorlarda manba xost 11.14-rasmdagi kabi parchalanishni amalga oshirayotganini ko'ramiz. Agar keyingi MTU ma'lum bo'lsa, 11.15-rasmdagi bsdi router tomonidan yaratilgan to'rtta fragmentga nisbatan faqat uchta fragment hosil bo'ladi.

UDP va ARP o'rtasidagi o'zaro ta'sir

UDP dan foydalanib, biz UDP va odatiy ARP ilovasi o'rtasidagi juda qiziqarli o'zaro ta'sirni ko'rishimiz mumkin.

Biz paypoq dasturidan 8192 bayt ma'lumotga ega bitta UDP datagramini yaratish uchun foydalanamiz. Biz bu holatda oltita Ethernet fragmentlari hosil bo'lishini kutamiz (11-bobga qarang). Bundan tashqari, dasturni ishga tushirishdan oldin, biz ARP keshi bo'sh ekanligiga ishonch hosil qilamiz, shuning uchun birinchi fragment yuborilishidan oldin, ARP so'rovi va javobini almashish kerak.

bsdi % arp -a ARP keshi bo'shligini tekshiring
bsdi % paypoq -u -i -n1 -w8192 svr4 tashlang

Biz birinchi datagram ARP so'rovini yuborishini kutamiz. IP tomonidan yaratilgan keyingi beshta fragmentlar ikkita savol tug'diradi, ularga faqat tcpdump yordamida javob berishimiz mumkin: qolgan qismlar ARP javobi olinmaguncha yuborishga tayyor bo'ladimi, agar shunday bo'lsa, ARP bu bir nechta paketlar bilan nima qiladi? ARP javobini kutayotganda ma'lum bir manzilga? 11.17-rasmda tcpdump dasturining chiqishi ko'rsatilgan.

1 0,0 arp kim-bo'lgan svr4 bsdi ayting
2 0,001234 (0,0012) arp kim-svr4 bor bsdi ayting
3 0,001941 (0,0007) arp kim-svr4 bor bsdi ayting
4 0,002775 (0,0008) arp kim-svr4 bor bsdi ayting
5 0,003495 (0,0007) arp kim-svr4 bor bsdi ayt
6 0,004319 (0,0008) arp kim-svr4 bor bsdi ayting
7 0.008772 (0.0045) arp javob svr4 0:0:c0:c2:9b:26 da
8 0.009911 (0.0011) arp javob svr4 0:0:c0:c2:9b:26 da
9 0.011127 (0.0012) bsdi > svr4: (frag 10863:800@7400)
10 0,011255 (0,0001) arp javob svr4 0:0:c0:c2:9b:26 da
11 0.012562 (0.0013) arp javob svr4 0:0:c0:c2:9b:26 da
12 0.013458 (0.0009) arp javob svr4 0:0:c0:c2:9b:26 da
13 0.014526 (0.0011) arp javob svr4 0:0:c0:c2:9b:26 da
14 0.015583 (0.0011) arp javob svr4 0:0:c0:c2:9b:26 da

11.17-rasm Ethernet orqali 8192 baytlik UDP datagrammasini yuborishda paket almashinuvi.

Bu xulosa juda kutilmagan. Birinchidan, birinchi ARP javobini olishdan oldin, oltita ARP so'rovi yaratiladi. Siz taxmin qilganingizdek, IP tezda oltita parcha hosil qiladi va har biri uchun ARP so'rovi yuboriladi.

Keyin, birinchi ARP javobi olinganda (7-qator), faqat oxirgi fragment (9-qator) yuboriladi! Bu shuni anglatadiki, dastlabki beshta parcha tashlandi. Aslida, bu oddiy ARP ishlashiga misoldir. Aksariyat ilovalar faqat ARP javobini kutayotganda maqsad hostga yuboriladigan oxirgi paketni ushlab turadi.

Xost talablari RFC ARP suv toshqini oldini olish uchun ilovalarni talab qiladi (bir xil IP manzil uchun yuqori chastotali ARP so'rovlarini qayta-qayta yuborish). Tavsiya etilgan maksimal chastota sekundiga bir marta. Bu erda biz 4,3 millisekund ichida oltita ARP so'rovini ko'ramiz. Xost talablari RFC ARP kamida bitta paketni saqlashini talab qiladi va u eng oxirgi paket bo'lishi kerak. Bu biz aynan shu erda ko'rgan narsamiz.

Keyingi tushunarsiz anomaliya shundaki, svr4 oltita emas, yettita ARP javobini qaytardi.

Shuni ta'kidlash kerakki, tcpdump so'nggi ARP javobi qaytib kelganidan keyin yana 5 daqiqa ishladi va svr4 ICMP "qayta yig'ish vaqtida o'tib ketdi" xatosini qaytarib yuborishini ko'rishni kutmoqda. ICMP xabari hech qachon paydo bo'lmadi. (Biz ushbu xabarning formatini .da ko'rsatdik. 1 ga o'rnatilgan kod maydoni datagram qayta yig'ilayotganda vaqt o'tganligini bildiradi.)

Birinchi datagram fragmenti paydo bo'lganda IP qatlami taymerni ishga tushirishi kerak. Bu erda "birinchi" faqat birinchi fragmentni emas, balki berilgan datagram uchun kelgan birinchi fragmentni bildiradi (fragment ofseti 0). Oddiy kutish vaqtining qiymati 30 dan 60 soniyagacha. Agar ushbu datagram uchun barcha fragmentlar taymer muddati tugagunga qadar yetib kelmagan bo'lsa, barcha bo'laklar o'chiriladi. Agar bu bajarilmasa, hech qachon kelmaydigan qismlar (bu misolda ko'rganimizdek) qabul qilish buferining to'lib ketishiga olib kelishi mumkin.

ICMP xabarini ko'rmaganimizning ikkita sababi bor. Birinchidan, Berkeley ilovalarining aksariyati hech qachon bu xatoni yaratmaydi! Ushbu ilovalar taymerni o'rnatadi va taymer tugashi bilan barcha qismlarni o'chiradi, lekin ICMP xatosi yaratilmaydi. Ikkinchidan, birinchi fragment - UDP sarlavhasini o'z ichiga olgan ofset 0 ga teng bo'lgan fragment olinmadi. (Bu ARP tomonidan tushirilgan beshta paketning birinchisi edi.) Agar birinchi fragment olinmasa, ICMP xatosini yaratish uchun dastur talab qilinmaydi. Buning sababi shundaki, ICMP xatolik to'plami qaysi foydalanuvchi jarayoni ma'lumotlargrammani yuborganligini aniqlay olmaydi, chunki transport qatlami sarlavhasi mavjud emas edi. Va yuqori daraja (TCP ilovasi yoki UDP ilovasi) vaqt tugaydi va uzatishni takrorlaydi.

Ushbu bo'limda biz UDP va ARP o'rtasidagi aloqa qanday ishlashini ko'rib chiqish uchun IP parchalanishidan foydalandik. Agar jo'natuvchi bir nechta UDP datagrammalarini ketma-ket yuborsa, bu o'zaro ta'sirni ko'rish mumkin. Biz parchalanishdan foydalandik, chunki paketlar IP-dan foydalangan holda tezda yaratiladi, bu foydalanuvchi jarayoni bir nechta paketlarni yaratishga qaraganda ancha tezroq.

Maksimal UDP datagram hajmi

Nazariy jihatdan, IP-datagrammasining maksimal hajmi 65535 bayt bo'lishi mumkin, bu IP sarlavhasidagi 16 bitli to'liq uzunlikdagi maydon bilan cheklangan (qarang). IP sarlavhasining uzunligi 20 bayt va UDP sarlavhasining uzunligi 8 bayt bo'lgan UDP datagrammasi foydalanuvchi ma'lumotlari uchun maksimal 65507 baytni qoldiradi. Biroq, aksariyat ilovalar sezilarli darajada kichikroq datagramlardan foydalanadi.

Odatda ikkita cheklovlar o'ynaydi. Birinchidan, amaliy dastur dasturlash interfeysi bilan cheklanishi mumkin. Sockets API (1-bob, bo'lim) kirish va chiqish buferlarining hajmini o'rnatish uchun dastur tomonidan chaqirilishi mumkin bo'lgan funksiyani taqdim etadi. UDP rozetkasi uchun bu o'lcham UDP tomonidan o'qilishi va yozilishi mumkin bo'lgan UDP datagramining maksimal hajmiga bevosita bog'liq. Hozirgi vaqtda aksariyat tizimlar o'qilishi yoki yozilishi mumkin bo'lgan UDP datagramining standart maksimal hajmini ta'minlaydi, bu 8192 bayt. (Bu qiymat 8192 ga o'rnatiladi, chunki NFS sukut bo'yicha o'qiydi va yozadi.)

Quyidagi cheklov TCP/IP yadrosini amalga oshirish bilan belgilanadi. UDP datagrami hajmini 65535 baytdan kamroq qilib cheklaydigan dastur xususiyatlari (yoki xatolar) bo'lishi mumkin.

Muallif paypoq dasturidan foydalanib, turli xil UDP datagram o'lchamlari bilan tajriba o'tkazdi. SunOS 4.1.3 ostida loopback interfeysidan foydalangan holda, maksimal UDP datagram hajmi 32767 baytni tashkil etdi. Yuqori qiymatdan foydalanish mumkin emas edi. Ethernet orqali BSD/386 dan SunOS 4.1.3 ga o'tkazilganda Sun qabul qilishi mumkin bo'lgan IP datagrammasining maksimal hajmi 32786 (foydalanuvchi ma'lumotlari 32758 bayt bilan) edi. Solaris 2.2 da orqaga qaytish interfeysidan foydalangan holda IP-datagrammasining yuborilishi va qabul qilinishi mumkin bo'lgan maksimal hajmi 65535 bayt edi. Solaris 2.2 dan AIX 3.2.2 ga o'tkazishda maksimal hajmi 65535 bayt bo'lgan IP datagrammasini uzatish mumkin edi.

Datagramni kesish

IP ma'lum o'lchamdagi datagrammalarni jo'natishi va qabul qilishi, qabul qiluvchi dastur shu o'lchamdagi datagrammalarni o'qishga tayyor degani emas. UDP API ilovalarga bir vaqtning o'zida qayta ishlanadigan baytlarning maksimal sonini belgilash imkonini beradi. Qabul qilingan datagramma ilova qabul qilishga tayyor bo'lgan datagrammadan kattaroq bo'lsa nima bo'ladi?

Afsuski, javob dasturlash interfeysi va amalga oshirishga bog'liq.

Berkeley socket API ning an'anaviy versiyalari mos kelmaydigan ma'lumotlarni tashlab, datagrammalarni qisqartiradi. Ilovaning xabardor qilinishi versiyaga bog'liq. (4.3 BSD Reno va undan keyingi versiyalari ilovaga datagram kesilganligi haqida xabar berishi mumkin.) SVR4 ostidagi API soketlari (shu jumladan Solaris 2.x) datagrammalarni kesmaydi. Mos bo'lmagan har qanday ma'lumotlar ketma-ket o'qiladi. Ilovaga bir nechta o'qish tsikllari haqida xabar berilmaydi va bitta UDP datagrammasi yuboriladi. TLI API'lari ma'lumotlarni tashlab ketmaydi. Buning o'rniga, bir vaqtning o'zida o'qilishi mumkin bo'lgandan ko'proq ma'lumotlar mavjudligini ko'rsatadigan bayroq qaytariladi, shuning uchun dastur qolgan datagrammani ketma-ket o'qiy boshlaydi.

TCP ni muhokama qilganimizda, biz ushbu protokol dasturga hech qanday cheklovlarsiz ketma-ket bayt oqimlarini taqdim etishini ko'ramiz. TCP ilovaga kerakli o'lchamdagi ma'lumotlarni taqdim etadi - va bu interfeysda hech qanday ma'lumot yo'qolmaydi.

ICMP manbasini bostirish xatosi

UDP-dan foydalanib, siz ICMP manbasini o'chirish xatosini yaratishingiz mumkin. Ushbu xato tizim (marshrutizator yoki xost) tomonidan datagrammalarni qayta ishlashga qaraganda tezroq qabul qilganda paydo bo'lishi mumkin. "Bo'lishi mumkin" iborasiga e'tibor bering. Buferlar to'lgan bo'lsa va datagramlar o'chirilgan bo'lsa ham, tizim manbalarni bostirishni talab qilmaydi.

11.18-rasmda ICMP manbasini bostirish xatosi formati ko'rsatilgan. Biz sinov tarmog'imizda shunga o'xshash xatolikni yaratish uchun ideal holatdamiz. Biz datagrammalarni bsdi dan router suniga Ethernet orqali yuborishimiz mumkin va bu datagrammalar SLIP kanali orqali yo'naltirilishi kerak. SLIP kanali Ethernet-ga qaraganda ming marta sekinroq bo'lgani uchun biz buferni osongina to'ldirishimiz mumkin. Quyidagi buyruq bsdi xostidan 100 1024 bayt datagrammani router sun orqali solarisga yuboradi. Biz datagrammalarni standart o'chirish xizmatiga yuboramiz, bu erda ular e'tiborga olinmaydi:

>bsdi % paypoq -u -i -w1024 -n100 solaris tashlang

11.18-rasm ICMP manbasini bostirish xatosi.

11.19-rasmda ushbu buyruqqa mos keladigan tcpdump chiqishi ko'rsatilgan.

1 0.0 bsdi.1403 > solaris.discard: udp 1024
26 qator ko'rsatilmagan
27 0,10 (0,00) bsdi.1403 > solaris.discard: udp 1024
28 0,11 (0,01) quyosh > bsdi: icmp: manba o'chirish

29 0,11 (0,00) bsdi.1403 > solaris.discard: udp 1024
30 0.11 (0.00) quyosh > bsdi: icmp: manba oʻchirish
142 qator ko'rsatilmagan
173 0,71 (0,06) bsdi.1403 > solaris.discard: udp 1024
174 0.71 (0.00) quyosh > bsdi: icmp: manba oʻchirish

11.19-rasm Router quyoshidan ICMP manbasini bostirish.

Biz ushbu chiqishdan ko'plab qatorlarni olib tashladik. Dastlabki 26 ta datagramma xatosiz qabul qilindi: biz faqat birinchisining chiqishini ko'rsatdik. 27-datagramdan boshlab, har safar datagram yuborilganda biz manbani bostirish xatosini olamiz. Hammasi bo'lib 26+(74x2)=174 qator chiqdi.

2-bobdagi ketma-ket chiziq o'tkazish qobiliyatini hisoblashimizdan biz 1024 baytli datagramni 9600 bit / s tezlikda uzatish uchun bir soniyadan ko'proq vaqt ketishini ko'rishimiz mumkin. (Bizning misolimizda bu ko'proq vaqt talab etadi, chunki 20+8+1024 baytlik datagram parchalanadi, chunki sundan netbgacha bo'lgan SLIP havolasining MTU 552 baytni tashkil qiladi.) Biroq, 11.19-rasmda ko'rsatilgan vaqtlardan biz buni ko'ramiz. marshrutizator quyosh birinchisi SLIP kanaliga yuborilishidan oldin barcha 100 datagrammani bir soniyadan kamroq vaqt ichida qabul qildi. Biz uning ko'plab buferlaridan foydalanganimiz aniq.

Garchi RFC 1009 marshrutizatordan uning buferlari to'lganida manbani bostirish xatolarini yaratishni talab qilsa-da, yangi Router talablari RFC [Almquist 1993] buni o'zgartiradi va marshrutizator manbalarni bostirish xatolarini yaratmasligi kerakligini aytadi.

Misolda e'tibor berish kerak bo'lgan navbatdagi nuqta shundaki, paypoq dasturi hech qachon manba bostirilganligi haqida bildirishnomalarni olmagan yoki bo'lsa, ularga e'tibor bermagan. Bu shuni ko'rsatadiki, BSD ilovalari odatda UDP protokolidan foydalanganda olingan manbani bostirish xabarlarini e'tiborsiz qoldiradi. (TCP holatida bildirishnoma olinganda, manba bostirish hosil boʻladigan ulanish boʻyicha maʼlumotlarni uzatish sekinlashadi. Bu haqda 21-bob boʻlimida muhokama qilamiz.) Muammo shundaki, maʼlumotlarni yaratgan jarayon Bu esa, o'z navbatida, bostirish manbasini bostirish xabari olinganda allaqachon tugallangan bo'lishi mumkin. Haqiqatan ham, agar biz paypoq dasturi qancha vaqt ishlayotganini taxmin qilish uchun Unix vaqt dasturidan foydalansak, uning atigi 0,5 soniya davomida ishlaganini topamiz. Biroq, biz 11.19-rasmda ba'zi manbalarni bostirish xabarlari birinchi datagram jo'natilgandan 0,71 soniya o'tgach, ya'ni jarayon ishlashni to'xtatgandan keyin olinganligini ko'rdik. Agar dasturimiz 100 ta datagram ishlab chiqarsa va undan chiqsa nima bo'ladi. 100 ta datagrammaning hammasi ham yuborilmaydi - ularning ba'zilari chiqish navbatida bo'ladi.

Ushbu misol UDP ishonchsiz protokol ekanligini isbotlaydi va oqimni boshqarish muhimligini ko'rsatadi. Paypoq dasturi tarmoqqa 100 ta datagrammani muvaffaqiyatli yuborgan bo'lsa ham, faqat 26 tasi o'z manziliga yetib bordi. Qolgan 74 tasi katta ehtimol bilan oraliq router tomonidan tashlab yuborilgan. Agar ilova bildirishnomalarning ba'zi shakllarini qo'llab-quvvatlamasa, jo'natuvchi qabul qiluvchining ma'lumotlarni qabul qilganligini bilmaydi.

UDP serveri

Serverni loyihalash va amalga oshirishga ta'sir qiluvchi UDP dan foydalanishning bir qancha xususiyatlari mavjud. Mijozlarni loyihalash va amalga oshirish odatda serverlarni amalga oshirishdan ko'ra osonroqdir. Shuning uchun biz bu erda mijozni rivojlantirishdan ko'ra serverni rivojlantirishni muhokama qilamiz. Serverlar odatda operatsion tizim bilan o'zaro aloqada bo'lishadi va ko'pchilik serverlar bir vaqtning o'zida bir nechta mijozlar so'rovlarini boshqarishning qandaydir yo'li bo'lishini talab qiladi.

Odatda, mijoz ishga tushganda, u darhol bitta serverga ulanishni o'rnatadi. Boshqa tomondan, serverlar ishga tushadi va keyin mijozdan so'rov kelishini kutayotganda uyquga ketadi. UDP holatida, server mijozdan datagram kelganda "uyg'onadi", bu datagrammada qandaydir shakldagi so'rov bo'lishi mumkin.

Biz mijozlar va serverlarning dasturlash jihatlarini ko'rib chiqmaymiz (u hamma narsani batafsil tavsiflaydi), lekin biz UDP protokolidan foydalanadigan serverni loyihalash va amalga oshirishga ta'sir qiluvchi UDP protokolining xususiyatlarini ko'rib chiqamiz. (Biz TCP serverining tafsilotlarini 18-bobning bo'limida muhokama qilamiz.) Biz foydalaniladigan UDP ilovalariga qarab ba'zi xususiyatlarni ko'rib chiqamiz, shuningdek, ko'pchilik ilovalar uchun umumiy bo'lgan xususiyatlarni ko'rib chiqamiz.

Mijoz IP manzili va port raqami

Mijozdan UDP datagrami keladi. IP sarlavhasida manba va maqsad IP manzillari, UDP sarlavhasida esa manba va maqsad UDP port raqamlari mavjud. Ilova UDP datagrammasini olganida, operatsion tizim unga xabarni kim yuborganini aytishi kerak - manba IP manzili va port raqami.

Bu xususiyat bitta UDP serveriga bir nechta mijozlarni boshqarish imkonini beradi. Har bir javob so'rov yuborgan mijozga yuboriladi.

Belgilangan IP manzili

Ba'zi ilovalar datagram kimga mo'ljallanganligini, ya'ni maqsad IP manzilini bilishi kerak. Masalan, Xost talablari RFC TFTP serveri translyatsiya manziliga yuborilgan qabul qilingan ma'lumotlargrammalarni e'tiborsiz qoldirishi kerakligini belgilaydi. (Biz translatsiya manzilini , da TFTPni tasvirlaymiz.)

Bu shuni anglatadiki, operatsion tizim qabul qilingan UDP datagrammasidan dasturga maqsad IP manzilini o'tkazishi kerak. Afsuski, barcha ilovalar bu xususiyatni ta'minlamaydi.

Sockets API bu imkoniyatni IP_RECVDSTADDR opsiyasi yordamida ta'minlaydi. Matnda yoritilgan tizimlardan faqat BSD/386, 4.4BSD va AIX 3.2.2 bu variantni qo'llab-quvvatlaydi. SVR4, SunOS 4.x va Solaris 2.x qo'llab-quvvatlanmaydi.

UDP kiritish navbati

1-bobda biz ko'pchilik UDP serverlari bitta UDP porti (oldindan ma'lum bo'lgan server portlari) yordamida mijozlarga barcha so'rovlarga xizmat ko'rsatishi mumkinligini aytdik.

Odatda, ilova tomonidan ishlatiladigan har bir UDP porti bilan bog'langan kirish navbatining o'lchami cheklangan. Bu shuni anglatadiki, bir vaqtning o'zida turli mijozlardan kelgan so'rovlar avtomatik ravishda UDP navbatiga qo'yiladi. Qabul qilingan UDP datagrammalari qabul qilingan tartibda ilovaga yuboriladi (u keyingi datagrammani talab qilganda).

Biroq, agar navbat to'la bo'lsa, yadrodagi UDP moduli kiruvchi datagrammalarni o'chirib qo'yishi mumkin. Buni quyidagi tajriba orqali kuzatishimiz mumkin. Biz paypoq dasturimizni bsdi xostida boshlaymiz va shu bilan UDP serverini ishga tushiramiz:

bsdi % paypoq -s -u -v -E -R256 -r256 -P30 6666
140.252.13.33 dan 140.252.13.63 gacha: 1111111111 quyoshdan efir manziliga
140.252.13.34 dan, 140.252.13.35 gacha: 4444444444444 dan svr4 dan shaxsiy manzilga

Biz quyidagi bayroqlardan foydalandik: -s, dasturni server sifatida ishga tushiradi, UDP uchun -u, -v, mijozning IP-manzilini va -E manzil IP-manzilini chop etadi (bu holda tizim ruxsat beradi). Bundan tashqari, biz ushbu port uchun UDP qabul qilish buferini har bir dastur tomonidan o'qilishi mumkin bo'lgan o'lcham bilan (-r) 256 baytga (-R) o'rnatdik. -P30 bayrog'i birinchi datagramni o'qishdan oldin UDP portini tozalagandan so'ng 30 soniya kutishingizni aytadi. Bu bizga boshqa ikkita xostda mijozlarni ishga tushirish, ba'zi datagrammalarni yuborish va qabul qilish navbati qanday ishlashini ko'rish uchun vaqt beradi.

Server ishga tushirilgandan va 30 soniyalik pauza o'tgandan so'ng, biz mezbon quyoshda bitta mijozni ishga tushiramiz va uchta datagramma yuboramiz:

quyosh% paypoq -u -v 140.252.13.63 6666 Ethernet tarqatish manziliga
140.252.13.33.1252 da 140.252.13.63.6666 raqamiga ulangan
1111111111 11 bayt ma'lumot (yangi qator bilan)
222222222 10 bayt ma'lumot (yangi qator bilan)
33333333333 12 bayt ma'lumot (yangi qator bilan)

Belgilangan manzil - translyatsiya manzili (140.252.13.63). Keyin biz svr4 xostida boshqa mijozni ishga tushirdik va yana uchta datagramma yubordik:

svr4% paypoq -u -v bsdi 6666
0.0.0.0.1042 orqali 140.252.13.35.6666 raqamiga ulangan
4444444444444 14 bayt ma'lumot (yangi qator bilan)
555555555555555 16 bayt ma'lumot (yangi qator bilan)
66666666 9 bayt ma'lumot (yangi qator bilan)

Oldin bsdi-da ko'rsatilgan interaktiv chiqishda e'tiborga olish kerak bo'lgan birinchi narsa, dastur tomonidan faqat ikkita datagramma olingan: birinchisi quyoshdan, barchasi bitta edi va birinchisi to'rtta bo'lgan svr4 dan. Qolgan to'rtta datagram bekor qilindi.

11.20-rasmdagi tcpdump buyrug'ining chiqishi shuni ko'rsatadiki, barcha oltita datagramlar maqsadli xostga yetkazilgan. Datagramlar ikkita mijozdan teskari tartibda keldi: avval quyoshdan, keyin svr4 dan va hokazo. Bundan tashqari, oltitasi ham server uxlab yotgan paytda, taxminan 12 soniyada, 30 soniya ichida yetkazilganini payqashimiz mumkin.

1 0,0 sun.1252 > 140.252.13.63.6666: udp 11
2 2.499184 (2.4992) svr4.1042 > bsdi.6666: udp 14
3 4.959166 (2.4600) sun.1252 > 140.252.13.63.6666: udp 10
4 7.607149 (2.6480) svr4.1042 > bsdi.6666: udp 16
5 10.079059 (2.4719) sun.1252 > 140.252.13.63.6666: udp 12
6 12.415943 (2.3369) svr4.1042 > bsdi.6666: udp 9

Shakl 11.20 Ikki mijoz tomonidan yuborilgan UDP datagramlari uchun tcpdump chiqishi.

Shuni ham ta'kidlash kerakki, -E opsiyasi bilan server har bir datagramning maqsad IP-manzilini bilib olishi mumkin. Server translyatsiya manziliga yuborilgan birinchi qabul qilingan datagramma bilan nima qilishni tanlashi mumkin.

Ushbu misolda yana bir nechta xususiyatlarga e'tibor qaratish lozim. Birinchidan, dastur kiritish navbati to'lganligi haqida xabar bermadi. Qo'shimcha UDP datagramlari shunchaki o'chirildi. Shuningdek, biz tcpdump chiqishida mijozga datagramlar o'chirilganligi haqida xabar berish uchun hech narsa qaytarilmaganligini ko'ramiz. ICMP manbasini bostirish xabariga o'xshash hech narsa yuborilmadi, mutlaqo hech narsa. Va nihoyat, shuni ta'kidlashni istardikki, UDP kiritish navbati FIFO (birinchi kiruvchi, birinchi chiqadi) asosida ishlaydi, holbuki, biz ushbu bobning qismida ko'rganimizdek, ARP kiritish navbati LIFO (oxirgi, birinchi chiqadi) asosi.

Mahalliy IP-manzil cheklovi

Ko'pgina UDP serverlari UDP so'nggi nuqtalarini yaratishda IP manzillari uchun joker belgilardan foydalanadilar. Bu shuni anglatadiki, server portiga mo'ljallangan kiruvchi UDP datagramma har qanday mahalliy interfeys tomonidan qabul qilinadi. Masalan, biz 7777 portda UDP serverini ishga tushirishimiz mumkin:

>quyosh % paypoq -u -s 7777

Keyin ushbu oxirgi nuqta holatini ko'rish uchun netstat buyrug'idan foydalanamiz:

quyosh% netstat -a -n -f inet
Faol Internet ulanishlari (shu jumladan serverlar)
Proto Recv-Q Send-Q Mahalliy manzil Xorijiy manzil (shtat)
udp 0 0 *.7777 *.*

Ushbu chiqishda biz ko'plab satrlarni olib tashladik va faqat biz uchun qiziqarli bo'lganlarini qoldirdik. -a bayrog'i tarmoqning barcha so'nggi nuqtalari haqida xabar beradi. -n bayrog'i DNS-dan foydalanish va manzillarni nomlarga aylantirish o'rniga IP-manzillarni kasrli belgilarda chop etadi va xizmat nomlari o'rniga port raqamlarini chop etadi. -f inet opsiyasi faqat TCP va UDP so'nggi nuqtalari haqida xabar beradi.

Mahalliy manzil *.7777 sifatida chop etiladi, bu erda yulduzcha har qanday manzilni mahalliy IP manzil sifatida almashtirish mumkinligini bildiradi.

Server o'zining so'nggi nuqtasini yaratganda, u so'nggi nuqtaning mahalliy IP manzili sifatida xostning mahalliy IP-manzillaridan birini, jumladan, translyatsiya manzillaridan birini belgilashi mumkin. Bunday holda, kiruvchi UDP datagrammasi faqat belgilangan IP manzili belgilangan mahalliy manzilga mos keladigan bo'lsa, oxirgi nuqtaga uzatiladi. Paypoq dasturidan foydalanib, siz port raqamidan oldin IP-manzilni belgilashingiz mumkin va bu IP-manzil so'nggi nuqta uchun mahalliy IP-manzilga aylanadi. Masalan,

>quyosh % paypoq -u -s 140.252.1.29 7777

SLIP interfeysiga kelgan datagrammalardan 140.252.1.29 manzilli datagrammalarni tanlaydi. Netstat buyrug'ining chiqishi quyidagicha ko'rinadi:

udp 0 0 140.252.1.29.7777 *.*

Agar biz Ethernet orqali manzili 140.252.13.35 bo'lgan bsdi xostidan datagrammani ushbu serverga jo'natmoqchi bo'lsak, portning mavjud emasligi haqidagi ICMP xatosi qaytariladi. Server bu datagrammani hech qachon ko'rmaydi. 11.21-rasmda bu batafsilroq ko'rsatilgan.

1 0,0 bsdi.1723 > sun.7777: udp 13
2 0.000822 (0.0008) sun > bsdi: icmp: sun udp port 7777 ulanish imkonsiz

11.21-rasm UDP ma'lumotlar jadvalini qayta ishlashda serverning mahalliy manzilining mos kelmasligi natijasida yuzaga kelgan xato.

Xuddi shu portda boshqa serverlarni ishga tushirish mumkin, ularning har biri o'z mahalliy IP manziliga ega. Biroq, dastur tizimga bir xil port raqamini qayta ishlatishga ruxsat berishi kerak.

Soket opsiyasi SO_REUSEADDR API da ko'rsatilishi kerak. Buni paypoq dasturimiz -A opsiyasi yordamida amalga oshiradi.

Sun hostida biz bir xil UDP portida (8888) besh xil serverni ishga tushirishimiz mumkin:

quyosh% paypoq -u -s 140.252.1.29 8888 SLIP kanali uchun
quyosh% paypoq -u -s -A 140.252.13.33 8888 Ethernet uchun
quyosh% paypoq -u -s -A 127.0.0.1 8888 orqaga qaytish interfeysi uchun
quyosh% paypoq -u -s -A 140.252.13.63 8888 Ethernet eshittirish so'rovlari uchun
quyosh% paypoq -u -s -A 8888 qolgan hamma narsa uchun (IP-manzildagi meta-belgilar)

Serverlarning birinchisi -A bayrog'i bilan ishga tushirilishi kutilgan edi, bu tizimga bir xil port raqamini qayta ishlatish mumkinligini bildiradi. Netstat buyrug'ining chiqishi quyidagi beshta serverni ko'rsatadi:

Proto Recv-Q Send-Q Mahalliy manzil Xorijiy manzil (shtat)
udp 0 0 *.8888 *.*
udp 0 0 140.252.13.63.8888 *.*
udp 0 0 127.0.0.1 8888 *.*
udp 0 0 140.252.13.33 8888 *.*
udp 0 0 140.252.1.29 8888 *.*

Ushbu stsenariyda faqat 140.252.1.255 manzili uchun mo'ljallangan datagrammalar serverga mahalliy IP manzil sifatida ishlatiladigan joker belgilar bilan uriladi, chunki qolgan to'rtta server barcha mumkin bo'lgan manzillarni qamrab oladi.

IP manzilini almashtirishdan foydalanilganda, ustuvor tizim qo'llaniladi. Belgilangan IP-manzilga mos keladigan so'nggi nuqta har doim joker belgidan oldin tanlanadi. Joker belgining oxirgi nuqtasi faqat belgilangan manzil uchun moslik topilmasa ishlatiladi.

Tashqi IP manzillarini cheklash

Biz ilgari ko'rsatgan netstat buyrug'ining barcha chiqishida masofaviy IP manzillar va masofaviy port raqamlari *.* sifatida ko'rsatilgan. Bu shuni anglatadiki, oxirgi nuqta istalgan IP manzildan va istalgan port raqamidan kiruvchi UDP datagrammalarini qabul qiladi. Ko'pgina ilovalar UDP so'nggi nuqtalariga masofaviy manzillarni cheklash imkonini beradi.

Boshqacha qilib aytganda, oxirgi nuqta faqat belgilangan IP manzili va port raqamidan UDP datagrammalarini qabul qilishi mumkin. Bizning paypoq dasturimiz masofaviy IP manzili va port raqamini belgilash uchun -f opsiyasidan foydalanadi:

>quyosh % paypoq -u -s -f 140.252.13.35.4444 5555

Bunday holda, masofaviy IP-manzil 140.252.13.35 (bizning xost bsdi) ga o'rnatiladi va masofaviy port raqami 4444. Oldindan ma'lum bo'lgan server porti 5555. Agar netstatni ishga tushirsak, biz mahalliy IP manzilini ko'ramiz. Agar biz uni to'g'ridan-to'g'ri ko'rsatmagan bo'lsak ham, o'rnatiladi:

Proto Recv-Q Send-Q Mahalliy manzil Xorijiy manzil (shtat)
udp 0 0 140.252.13.33.5555 140.252.13.35.4444

Bu yon ta'sir Berkeley tizimlarida masofaviy IP-manzil va masofaviy port raqamini belgilash: agar masofaviy manzilni o'rnatishda mahalliy IP-manzil tanlanmagan bo'lsa, mahalliy manzil avtomatik ravishda tanlanadi. Mahalliy IP-manzil belgilangan masofaviy IP-manzilga erishish uchun IP-marshrutlash yordamida tanlangan interfeysning IP-manziliga o'rnatiladi. Darhaqiqat, ushbu misolda masofaviy manzilga ulangan Ethernet uchun quyosh IP-manzili 140.252.13.33.

11.22-rasmda UDP server o'zi uchun o'rnatishi mumkin bo'lgan uch turdagi manzillar va portlar ko'rsatilgan.

11.22-rasm UDP serveri uchun mahalliy va masofaviy IP manzillar va port raqamini belgilash.

Barcha holatlarda lport serverning oldindan ma'lum bo'lgan portidir va localIP mahalliy interfeysning IP manzili bo'lishi kerak. 11.22-rasmdagi uchta qatorni joylashtirish tartibi UDP modulining qaysi mahalliy so'nggi nuqta kiruvchi datagrammani olganligini aniqlashga harakat qilish tartibini ko'rsatadi. Eng cheklovchi manzildan portga assotsiatsiya (birinchi qator) avval tanlanadi va kamroq cheklovlisi (oxirgi satr, bu yerda IP manzili ham, port raqami ham meta-belgilar sifatida ko'rsatilgan) oxirgi marta tanlanadi.

Har bir port uchun bir nechta qabul qilish

RFCda ko'rsatilmagan bo'lsa-da, ko'pgina ilovalar bir vaqtning o'zida faqat bitta dasturni bitta mahalliy manzil va UDP port raqami bilan bog'lash imkonini beradi. UDP datagrammasi IP manzili va port raqami bo'yicha maqsad hostga etib kelganida, bitta nusxasi bitta oxirgi nuqtaga yetkaziladi. Oxirgi nuqtaning IP-manzili yuqorida ko'rsatilganidek, joker belgilar sifatida ko'rsatilishi mumkin.

Misol uchun, SunOS 4.1.3 da biz 9999-portda mahalliy IP-manzil bilan joker belgilar ko'rinishidagi bitta serverni ishga tushirdik:

>quyosh % paypoq -u -s 9999

Agar biz bir xil mahalliy joker manzilga va bir xil portga ega boshqa serverni ishga tushirishga harakat qilsak, u -A variantini belgilasak ham ishlamaydi:

quyosh% paypoq -u -s 9999 bunday bo'lmasligi kerak
mahalliy manzilni bog'lab bo'lmaydi: Manzil allaqachon ishlatilmoqda

quyosh% paypoq -u -s -A 9999 shuning uchun biz -A bayrog'ini belgiladik
mahalliy manzilni bog'lab bo'lmaydi: Manzil allaqachon ishlatilmoqda

Multicast qo'llab-quvvatlaydigan tizimlar uchun (qarang), narsalar boshqacha. Bir nechta so'nggi nuqtalar bir xil mahalliy manzil va UDP port raqamidan foydalanishi mumkin, ammo ilova APIga bunga ruxsat berilganligini aytishi kerak (-A bayrog'i SO_REUSEADDR soket opsiyasidan foydalanadi).

Multicastingni qo'llab-quvvatlaydigan 4.4BSD ilovadan bir nechta so'nggi nuqtalarga bir xil portni almashishga ruxsat berish uchun boshqa rozetka opsiyasini (SO_REUSEPORT) o'rnatishni talab qiladi. Bundan tashqari, har bir so'nggi nuqta ushbu parametrni, shu jumladan ushbu portdan foydalanadigan birinchi so'nggi nuqtani ko'rsatishi kerak.

UDP datagrammasi o'z IP-manziliga, ya'ni translyatsiya yoki multicast manziliga etib kelganida va ushbu IP-manzil va port raqami bilan bog'langan bir nechta so'nggi nuqtalar mavjud bo'lsa, kiruvchi ma'lumotlargrammasining nusxasi har bir so'nggi nuqtaga yuboriladi. (Oxirgi nuqtaning mahalliy IP-manzili joker belgilar sifatida koʻrsatilishi mumkin va istalgan maqsad IP-manziliga mos keladi.) Biroq, agar kelgan IP-datagrammada shaxsiy manzil boʻlgan maqsad IP-manzil boʻlsa, bitta soʻnggi nuqtaga datagrammaning faqat bitta nusxasi yetkaziladi. Qaysi so'nggi nuqta shaxsiy manzil datagrammasini qabul qilishi amalga oshirishga bog'liq.

Qisqacha xulosalar

UDP oddiy protokol. RFC 768 [Postel 1980] rasmiy spetsifikatsiyasi atigi uch sahifadan iborat. IP ustidagi va orqasidagi foydalanuvchi jarayonlariga taqdim etadigan xizmatlar port raqamlari va ixtiyoriy nazorat summalaridir. Biz nazorat summasi hisoblarini ko'rib chiqish va parchalanish qanday ishlashini ko'rish uchun UDP dan foydalandik.

Keyin biz yangi transport MTU aniqlash xususiyatining bir qismi bo'lgan ICMP erishib bo'lmaydigan xatolikni ko'rib chiqdik (2-bob, bo'limga qarang). Biz Traceroute va UDP yordamida transport MTUni aniqlashni ko'rib chiqdik. UDP va ARP o'rtasidagi o'zaro ta'sir jarayoni ham muhokama qilinadi.

ICMP manbasini bostirish xatosi IP maʼlumotlargrammalarini qayta ishlashdan tezroq qabul qiluvchi tizim tomonidan yuborilishi mumkinligini tasdiqladik. UDP yordamida ICMP xatolarini osongina yaratish mumkin.

Mashqlar

1. Ushbu bobning bo'limida biz foydalanuvchi ma'lumotlarining hajmi 1473 bayt bo'lgan UDP datagramini yozish orqali Ethernet-da parchalanishga olib keldik. Agar IEEE 802 inkapsulyatsiyasi qo'llanilsa, Ethernet tarmog'ida parchalanishga olib kelishi mumkin bo'lgan foydalanuvchi ma'lumotlarining eng kichik hajmi qancha bo'lishi mumkin (2-bob, bo'lim)?
2. RFC 791 [Postel 1981a] ni o'qing va nima uchun oxirgisidan tashqari barcha fragmentlar uzunligi 8 baytga ko'paytirilishi kerakligini ayting.
3. 8192 bayt foydalanuvchi ma'lumotlariga ega Ethernet va UDP datagrammasini tasavvur qiling. Qancha fragment uzatiladi va har bir fragment uchun ofset uzunligi qancha bo'ladi?
4. Oldingi misolni davom ettirsak, tasavvur qiling-a, bu datagramlar keyinchalik MTU 552 bo'lgan SLIP kanaliga o'tkaziladi. Siz har bir fragmentdagi ma'lumotlar miqdori (IP sarlavhasidan tashqari hamma narsa) 8 baytga ko'p bo'lishi kerakligini yodda tutishingiz kerak. Qancha parcha uzatiladi va har bir fragmentning ofset va uzunligi qancha?
5. UDP dan foydalanadigan dastur 4 qismga bo'lingan datagrammani yuboradi. Tasavvur qiling-a, 1 va 2-qismlar o'z manziliga etib borishdi, 3 va 4-qismlar esa yo'qoldi. Ilova muddati tugaydi va 10 soniyadan so'ng UDP datagrammasini qayta uzatadi. Ushbu datagram birinchi uzatish bilan bir xil tarzda bo'linadi (bir xil ofset va bir xil uzunlik). Endi tasavvur qiling-a, 1 va 2-qismlar yo'qolgan, ammo 3 va 4-qismlar o'z manziliga etib boradi. Qabul qiluvchi hostdagi qayta yig'ish taymeri 60 soniyaga o'rnatiladi, shuning uchun 3 va 4-qismlar yakuniy manzilga etib kelganida, birinchi uzatishning 1 va 2-qismlari hali tashlab yuborilmagan edi. Qabul qiluvchi ushbu to'rtta bo'lakdan IP-datagrammani yig'a oladimi?
6. 11.15-rasmdagi fragmentlar haqiqatda 11.14-rasmdagi 5 va 6-qatorlarga mos kelishini qanday bilish mumkin?
), qattiq va bo'sh manbalarni yo'naltirish (8-bob, bo'lim). Sizningcha, bu variantlar parchalanish vaqtida qanday ko'rib chiqiladi? Javobingizni RFC 791 bilan solishtiring.
7. Biz kiruvchi IP ma'lumotlargrammalari maqsadli UDP port raqamiga qarab demultiplekslanganligini aytdik. Bu to'g'rimi?

Foydalanuvchi Datagram Protocol - UDP

UDP protokoli TCP/IP protokollar stekida ishlatiladigan ikkita transport sathi protokollaridan biridir. UDP ilova dasturiga o'z xabarlarini tarmoq orqali minimal qo'shimcha xarajatlar bilan, amaliy qatlam protokollarini IP ga o'tkazishga imkon beradi. Biroq, ilova dasturining o'zi xabarning belgilangan manzilga etkazilganligini tasdiqlash haqida g'amxo'rlik qilishi kerak. UDP datagram (xabar) sarlavhasi 2.10-rasmda ko'rsatilgandek ko'rinadi.

Guruch. 2.10. UDP xabar sarlavhasi tuzilishi

UDP protokoli ma'lumotlar birligi UDP paketi yoki foydalanuvchi datagrammasi deb ataladi. UDP paketi sarlavha va dastur sathi paketini o'z ichiga olgan ma'lumotlar maydonidan iborat. Sarlavha oddiy formatga ega va ikki baytli to'rtta maydondan iborat:

UDP manba porti - jo'natish jarayonining port raqami,

UDP maqsad porti - qabul qiluvchi jarayonining port raqami,

UDP xabar uzunligi - UDP paketining baytdagi uzunligi,

UDP nazorat summasi - UDP paketining nazorat summasi

UDP paketining barcha maydonlarini to'ldirish shart emas. Agar yuborilgan datagramma javobni kutmasa, jo'natuvchining manzili o'rniga nollar qo'yilishi mumkin. Shuningdek, siz nazorat summasini hisoblashdan bosh tortishingiz mumkin, ammo shuni yodda tutingki, IP protokoli nazorat summasini faqat IP-paket sarlavhasi uchun hisoblab chiqadi, ma'lumotlar maydoniga e'tibor bermasdan.

Sarlavhadagi portlar UDP protokolini ilovalardan xabarlarni yig'ish va protokol qatlamiga yuborish imkonini beruvchi multipleksor sifatida belgilaydi. Bunday holda, dastur ma'lum bir portdan foydalanadi. Tarmoq orqali muloqot qiladigan ilovalar turli portlardan foydalanishi mumkin, bu paket sarlavhasida aks ettirilgan. Hammasi bo'lib 216 xil portni aniqlash mumkin. Birinchi 256 portlar "ma'lum xizmatlar" deb ataladigan narsalarga tayinlangan, ular, masalan, DNS xizmatiga tayinlangan UDP 53 portini o'z ichiga oladi.

Maydon Uzunlik xabarning umumiy uzunligini aniqlaydi. Maydon Tekshirish summasi ma'lumotlar yaxlitligini nazorat qilish uchun xizmat qiladi. UDP protokolidan foydalanadigan dastur Checksum va Length maydonlarini tahlil qilish orqali ma'lumotlar yaxlitligiga e'tibor berishi kerak. Bundan tashqari, UDP orqali ma'lumotlarni almashishda, dastur dasturining o'zi ma'lumotlarni qabul qiluvchiga etkazib berishni nazorat qilish haqida g'amxo'rlik qilishi kerak. Bunga odatda dastur dasturlari o'rtasida yetkazib berish tasdiqlarini almashish orqali erishiladi.

UDP-ga asoslangan eng mashhur xizmatlar BIND domen nomlari xizmati va NFS taqsimlangan fayl tizimidir. Traceroute misoliga qaytsak, ushbu dastur UDP transportidan ham foydalanadi. Aslida, bu tarmoqqa yuboriladigan UDP xabaridir, lekin u xizmat ko'rsatmaydigan portdan foydalanadi, shuning uchun ICMP paketi yaratiladi, bu paket nihoyat yetib kelganida qabul qiluvchi mashinada xizmat etishmasligini aniqlaydi. maqsad mashinasi.

Transferni boshqarish protokoli - TCP

Agar dastur uchun tarmoq orqali ma'lumotlarni uzatish sifatini kuzatish muhim bo'lsa, unda bu holda TCP protokoli qo'llaniladi. Ushbu protokol ishonchli, ulanishga yo'naltirilgan va oqimga yo'naltirilgan protokol deb ham ataladi. Protokolning bu xossalarini muhokama qilishdan oldin tarmoq orqali uzatiladigan datagramma formatini ko‘rib chiqamiz (2.11-rasm). Ushbu tuzilishga ko'ra, TCP ham UDP kabi portlarga ega. Dastlabki 256 ta port WKS ga, 256 dan 1024 gacha bo'lgan portlar Unix xizmatlariga tayinlangan, qolganlaridan esa sizning ixtiyoringiz bilan foydalanish mumkin. Dalada Tartib raqami paket raqami butun xabarni tashkil etuvchi paketlar ketma-ketligida aniqlanadi, undan keyin tasdiqlash maydoni mavjud. Bilim raqami va boshqa nazorat ma'lumotlari.

Guruch. 2.11. TCP paket tuzilishi

Manba porti (SOURS PORT) 2 baytni egallaydi, jo'natish jarayonini aniqlaydi;

Belgilangan port (DESTINATION PORT) 2 baytni egallaydi, qabul qiluvchi jarayonini aniqlaydi;

Tartib raqami (SEQUENCE NUMBER) 4 baytni egallaydi, yuborilgan ma'lumotlar oqimiga nisbatan segmentning ofsetini aniqlaydigan bayt raqamini ko'rsatadi;

Tasdiqlangan raqam (TASKIRISH №) 4 baytni egallaydi, qabul qilingan segmentdagi maksimal bayt sonini o'z ichiga oladi, bittaga ko'paytiriladi; aynan shu qiymat kvitansiya sifatida ishlatiladi;

Sarlavha uzunligi (HLEN) 4 bit uzunlikda va 32 bitli so'zlar bilan o'lchangan TCP segmenti sarlavhasining uzunligini bildiradi. Sarlavha uzunligi aniqlanmagan va Options maydonida o'rnatilgan qiymatlarga qarab o'zgarishi mumkin;

Zaxira (REserved) 6 bitni egallaydi, maydon keyinchalik foydalanish uchun ajratilgan;

Kod bitlari (CODE BITS) 6 bitni egallaydi va ushbu maydonning tegishli bitlarini bittaga o'rnatish orqali belgilangan segmentning turi haqida xizmat ma'lumotlarini o'z ichiga oladi:

URG - shoshilinch xabar;

ACK - olingan segment uchun kvitansiya;

PSH - buferni to'ldirishni kutmasdan xabar yuborish so'rovi;

RST - ulanishni tiklash uchun so'rov;

SYN - ulanishni o'rnatishda uzatilgan ma'lumotlar hisoblagichlarini sinxronlashtirish uchun foydalaniladigan xabar;

FIN - uzatuvchi tomon uzatilgan ma'lumotlar oqimidagi oxirgi baytga yetganligining belgisidir.

Oyna (WINDOW) 2 baytni egallaydi, baytlarda oyna hajmining e'lon qilingan qiymatini o'z ichiga oladi;

Tekshirish summasi (CHECKSUM) 2 baytni oladi va har bir segment uchun hisoblanadi;

Shoshilinch ko'rsatkich (URGENT POINTER) 2 baytni egallaydi, URG kod biti bilan birgalikda ishlatiladi, bufer to'lib ketganiga qaramay, shoshilinch ravishda olinishi kerak bo'lgan ma'lumotlarning oxirini ko'rsatadi;

OPTIONS - bu maydon o'zgaruvchan uzunlikka ega va umuman yo'q bo'lishi mumkin, maksimal maydon hajmi 3 bayt; yordamchi muammolarni hal qilish uchun ishlatiladi, masalan, maksimal segment hajmini tanlashda;

PADDING, oʻzgaruvchan uzunlikdagi toʻldirish, sarlavha oʻlchamini 32 bitli soʻzlarning butun soniga etkazish uchun ishlatiladigan soʻqmoqli maydon.

TCP ning ishonchliligi shundan iboratki, ma'lumotlar manbai, agar u ma'lum vaqt ichida qabul qiluvchidan muvaffaqiyatli qabul qilinganligi to'g'risida tasdiqni olmasa, uni yuborishni takrorlaydi. Ushbu mexanizm deyiladi Qayta uzatish bilan ijobiy xabardorlik (PAR). Biz avval aniqlaganimizdek, TCP terminlarida uzatish birligi (ma’lumotlar paketi, xabar va boshqalar) segment deyiladi. TCP sarlavhasida nazorat summasi maydoni mavjud. Agar uzatish paytida ma'lumotlar shikastlangan bo'lsa, TCP segmentlarini IP paketlardan ajratuvchi modul buni nazorat summasi yordamida aniqlashi mumkin. Buzilgan paket yo'q qilinadi va manbaga hech narsa yuborilmaydi. Agar ma'lumotlar buzilmagan bo'lsa, u ilova xabarlari yig'ilishidan o'tkaziladi va manbaga tasdiqnoma yuboriladi.

Ulanish yo'nalishi ma'lumotlar segmentini yuborishdan oldin manba va maqsad TCP modullari boshqaruv ma'lumotlarini almashishi bilan belgilanadi. Bu almashinuv deyiladi qo'l siqish(so'zma-so'z "qo'l siqish"). TCP uch fazali qo'l silkitishdan foydalanadi:

Manba belgilangan manzil bilan ulanishni unga ketma-ketlik raqamlarini sinxronlashtirish (SYN) bayrog'i bilan paket jo'natadi. Ketma-ketlikdagi raqam ilova xabaridagi paket raqamini aniqlaydi. Bu 0 yoki bitta bo'lishi shart emas. Ammo boshqa barcha raqamlar uni asos sifatida ishlatadi, bu esa paketlarni to'g'ri tartibda to'plash imkonini beradi;

Qabul qiluvchi SYN kvitansiyasini tasdiqlash maydonida manba tomonidan o'rnatilgan raqamga mos keladigan raqam bilan javob beradi. Bundan tashqari, "ketma-ket raqam" maydonida manba tomonidan so'ralgan raqam ham ko'rsatilishi mumkin;

Manba maqsad segmentini qabul qilganligini tasdiqlaydi va ma'lumotlarning birinchi qismini yuboradi.

Grafik jihatdan bu jarayon 2.12-rasmda keltirilgan.

Guruch. 2.12. TCP ulanishini o'rnatish

Ulanish o'rnatilgandan so'ng, manba ma'lumotlarni qabul qiluvchiga yuboradi va undan olinganligini tasdiqlashni kutadi, so'ngra xabar tugaguncha ma'lumotlarni qayta yuboradi va hokazo. Xabar FIN biti bayroqlar maydoniga o'rnatilganda tugaydi, bu "boshqa ma'lumot yo'q" degan ma'noni anglatadi.

Protokolning oqimli tabiati SYN paketlarni emas, balki uzatilgan baytlarni hisoblash uchun boshlang'ich raqamni belgilashi bilan belgilanadi. Bu shuni anglatadiki, agar SYN 0 ga o'rnatilgan bo'lsa va 200 bayt uzatilgan bo'lsa, keyingi paketda o'rnatilgan raqam 2 emas, balki 201 bo'ladi.

Ko'rinib turibdiki, protokolning oqimliligi va ma'lumotlarning qabul qilinishini tasdiqlash talabi ma'lumotlarni uzatish tezligi muammosini keltirib chiqaradi. Ushbu muammoni hal qilish uchun "oyna" - maydon - oynadan foydalaning. Oynadan foydalanish g'oyasi juda oddiy: ma'lumotlarni uning qabul qilinganligi tasdiqlanishini kutmasdan uzating. Bu shuni anglatadiki, manba ma'lum miqdordagi ma'lumotni qabul qilishning tasdiqlanishini kutmasdan, oynaga teng ravishda uzatadi va shundan so'ng u uzatishni to'xtatadi va tasdiqlashni kutadi. Agar u uzatilgan ma'lumotlarning faqat bir qismi uchun tasdiqni olsa, u tasdiqlanganidan keyingi raqamdan yangi qismni uzatishni boshlaydi. Bu 2.13-rasmda grafik ko'rsatilgan.

Guruch. 2.13. TCP ma'lumotlarini uzatish mexanizmi

Ushbu misolda oyna 250 bayt kengligida o'rnatiladi. Bu shuni anglatadiki, joriy segment SYN ofset 250 bayt bo'lgan segmentdir. Biroq, butun oynani uzatgandan so'ng, manba TCP moduli faqat birinchi 100 baytni qabul qilish to'g'risida tasdiqnoma oldi. Shuning uchun uzatish 251 baytdan emas, balki 101 baytdan boshlanadi.

Shunday qilib, biz TCP protokolining barcha asosiy xususiyatlarini ko'rib chiqdik. Faqat TCP ma'lumotlar almashinuvi uchun foydalanadigan eng mashhur ilovalarni nomlash qoladi. Bular, birinchi navbatda, TELNET va FTP, shuningdek, World Wide Webning yuragi bo'lgan HTTP protokoli.

Keling, protokollar haqidagi suhbatni biroz to'xtatib, diqqatimizni butun TCP/IP tizimining IP manzillari kabi muhim tarkibiy qismiga qaratamiz.

Xayrli kun, aziz o'quvchilar.
Ommabop talabga ko'ra, bugun men siz uchun asosiy atamalarning asoslari bilan tanishtiradigan maqolani nashr etaman kompyuter tarmog'i, aynan:

• Tarmoq protokollari - bu qo'rqinchli nomlar nima va ular nima uchun ishlatiladi?
• UDP, TCP, ICMP - nima, nima uchun va qanday farq
• Hammaning IP manzili bor, lekin nima uchun bu narsa hamma ham bilmaydi :-)
• Manzil niqobi (quyi tarmoq)
• Gateway
• Marshrutlash jadvallari haqida bir necha so'z
• Portlar - ular aslida nima?
• MAC manzili

Shunga o'xshash.

Maqola, menimcha, yoshu qari hamma uchun foydali bo'ladi, chunki u juda ko'p g'alati, tushunarsiz harakatlar yoki so'zlar to'plamini emas, balki hech bo'lmaganda tushunarli tilda taqdim etilgan ma'lumotlar blokini o'z ichiga oladi. Bularning barchasi qanday ishlashini va nima uchun kerakligini tushunasiz. Bor.

Tarmoq protokollari TCP/IP, NWLink IPX/SPX, NetBEUI

Keling, tarmoq protokoli nima va u nima uchun ishlatilishidan boshlaylik.
Tarmoq protokoli kompyuterlar o'rtasida aloqa qilish uchun amalga oshiriladigan dasturiy ta'minot qoidalari to'plamidir. Kompyuterlar bir-biri bilan gaplashadigan va ma'lumot uzatadigan til turi. Ilgari, kompyuterlar, aytganda, Windowsning ko'p tilli va eski versiyalarida protokollarning butun to'plamidan foydalanilgan - TCP/IP, NWLink IPX/SPX, NetBEUI. Endi biz umumiy kelishuvga erishdik va standart faqat TCP/IP protokolidan foydalanishga aylandi, shuning uchun u bundan keyin ham muhokama qilinadi.

TCP/IP haqida gapirganda, ular odatda bu nom bilan juda ko'p turli xil... qoidalarni yoki aytaylik, ushbu protokol yordamida (yoki foydalanish uchun) belgilangan standartlarni nazarda tutadilar. Masalan, pochta serverlari o'rtasida xabarlar almashinadigan qoidalar mavjud va oxirgi foydalanuvchi o'z pochta qutisiga xatlarni qabul qiladigan qoidalar mavjud. Video konferentsiyalarni o'tkazish qoidalari va Internet orqali "telefon" suhbatlarini tashkil qilish qoidalari mavjud. Darhaqiqat, bu qoidalar ham emas ... Ko'proq grammatika yoki boshqa narsa kabi. Xo'sh, bilasizmi, ingliz tilida dialoglarni qurish uchun bitta tuzilma mavjud, frantsuz tilida boshqasi ... Demak, TCP/IP da shunga o'xshash narsa, ya'ni. Turli xil grammatik qoidalarning ma'lum bir to'plami aniq ajralmas TCP/IP protokoli yoki aniqrog'i, TCP/IP protokoli stegi.

Tarmoq protokollari UDP, TCP, ICMP

TCP/IP protokoli doirasida ma'lumotlarni uzatish uchun ishlatiladigan protokollar TCP va UDP hisoblanadi. Ko'pchilik TCP va UDP portlari mavjudligini eshitgan bo'lishi mumkin, ammo farq nima ekanligini va nima ekanligini hamma ham bilmaydi. Shunday qilib..

TCP protokoli (Transmission Control Protocol) orqali ma'lumotlarni uzatish ma'lumotni qabul qilishni tasdiqlashni talab qiladi. "Xo'sh, ular aytishadi, siz buni oldingizmi? - Tushundim!" Agar uzatuvchi tomon belgilangan muddatda kerakli tasdiqni olmasa, ma'lumotlar qayta uzatiladi. Shuning uchun TCP ulanishga asoslangan protokol hisoblanadi, UDP (User Datagram Protocol) esa bunday emas. UDP qabul qilishni tasdiqlash talab etilmagan hollarda qo'llaniladi (masalan, DNS so'rovlari yoki IP-telefoniya (ularning Skype taniqli vakili)). Ya'ni, farq qabul qilishning tasdiqlanishi mavjudligidadir. "Hammasi shu!" Ko'rinadi, lekin amalda bu muhim rol o'ynaydi.

Tarmoq parametrlari haqidagi ma'lumotlarni uzatish uchun ishlatiladigan ICMP protokoli (Internet Control Message Protocol) ham mavjud. kabi foydali paket turlarini o'z ichiga oladi ping, erishib bo'lmaydigan masofa, TTL va boshqalar.

IP manzil nima

Har bir inson bor, lekin hamma ham bu qanday manzil ekanligini va nima uchun usiz yashash mumkin emasligini bilmaydi. Men sizga aytyapman.

IP manzil - tarmoqdagi kompyuterni aniqlash uchun ishlatiladigan 32 bitli raqam. Olingan qiymatlarni nuqta bilan ajratib, ushbu raqamning har bir oktetining o'nlik qiymatlarida manzilni yozish odatiy holdir. Masalan, 192.168.101.36

IP-manzillar noyobdir, ya'ni har bir kompyuterning o'ziga xos raqamlar kombinatsiyasi mavjud va tarmoqda bir xil manzilga ega ikkita kompyuter bo'lishi mumkin emas. IP-manzillar markazlashtirilgan tarzda taqsimlanadi, internet-provayderlar o'z ehtiyojlariga muvofiq milliy markazlarga arizalar kiritadilar. Provayderlar tomonidan qabul qilingan manzil diapazonlari mijozlar o'rtasida yanada taqsimlanadi. Mijozlar, o'z navbatida, o'zlari provayder sifatida harakat qilishlari va olingan IP manzillarini subklientlar va boshqalar o'rtasida taqsimlashlari mumkin. IP manzillarini tarqatishning ushbu usuli bilan kompyuter tizimi noyob IP-manzilga ega bo'lgan kompyuterning "joylashuvini" aniq biladi; - unga ma'lumotlarni "egasi" tarmog'iga yuborish kifoya, va provayder, o'z navbatida, manzilni tahlil qiladi va manzillarning bu qismi kimga berilganligini bilib, ma'lumotni keyingi egasiga yuboradi. ma'lumotlar maqsadli kompyuterga yetib borguncha IP-manzil pastki diapazoni.

Mahalliy tarmoqlarni qurish uchun maxsus manzil diapazonlari ajratilgan. Bular 10.x.x.x, 192.168.x.x, 10.x.x.x, 172.16.x.x dan 172.31.x.x, 169.254.x.x gacha bo'lgan manzillar, bu erda x 0 dan 254 gacha bo'lgan istalgan sonni bildiradi. Belgilangan manzillardan uzatiladigan paketlar yo'naltirilmaydi, boshqacha qilib aytganda, ular Internet orqali yuborilmaydi va shuning uchun turli xil mahalliy tarmoqlardagi kompyuterlar belgilangan diapazonlardan mos keladigan manzillarga ega bo'lishi mumkin. Ya'ni, kompaniya MChJ "Horns and Hooves" va MChJ "Vasya and Company" 192.168.0.244 manzilli ikkita kompyuterga ega bo'lishi mumkin, ammo Internet-provayderdan olingan 85.144.213.122 manzillari bilan, aytaylik, mumkin emas, chunki . Internetda ikkita bir xil IP manzil bo'lishi mumkin emas. Bunday kompyuterlardan Internetga va orqaga ma'lumot yuborish uchun Internet bilan ishlashda mahalliy manzillarni haqiqiylarga almashtiradigan maxsus dasturlar va qurilmalar qo'llaniladi. Boshqacha qilib aytganda, ma'lumotlar tarmoqqa mahalliy manzildan emas, balki haqiqiy IP-manzildan yuboriladi. Bu jarayon foydalanuvchi tomonidan sezilmasdan sodir bo'ladi va manzil tarjimasi deb ataladi. Shuni ham ta'kidlashni istardimki, bitta tarmoq ichida, aytaylik, Horns and Hooves MChJ kompaniyasida bitta mahalliy IP manzilga ega ikkita kompyuter bo'lishi mumkin emas, ya'ni yuqoridagi misolda 192.168.0.244 manzilli bitta kompyuter nazarda tutilgan edi. bir kompaniyada, ikkinchisi boshqasida bir xil manzilga ega. Xuddi shu kompaniyada 192.168.0.244 manzilli ikkita kompyuter bir-biriga mos kelmaydi.

Ehtimol siz tashqi IP va ichki IP, doimiy (statik IP) va o'zgaruvchan (dinamik) IP kabi atamalarni eshitgansiz. Ular haqida qisqacha:

• tashqi IP - bu provayderingiz sizga bergan IP-dir, ya'ni. Sizning Internetdagi yagona manzilingiz, masalan, 85.144.24.122
• ichki IP - mahalliy IP, ya'ni. Mahalliy tarmoqdagi IP manzilingiz, masalan, 192.168.1.3
• statik IP - har bir ulanish bilan o'zgarmaydigan IP, ya'ni. Sizga qat'iy va abadiy tayinlangan
• dinamik IP - har bir ulanish bilan o'zgarib turadigan suzuvchi IP-manzil

IP-manzilingiz turi (statik yoki dinamik) provayderingiz sozlamalariga bog'liq.

Manzil niqobi nima (quyi tarmoq)

Bir tashkilotning IP-manzillarining bir qismini, boshqasining bir qismini va hokazolarni tanlash mumkin bo'lishi uchun quyi tarmoq tushunchasi kiritildi. Quyi tarmoq - bir xil mahalliy tarmoqqa tegishli deb hisoblangan IP-manzillar qatori. Mahalliy tarmoqda ishlashda ma'lumot to'g'ridan-to'g'ri qabul qiluvchiga yuboriladi. Agar ma'lumotlar mahalliy tarmoqqa tegishli bo'lmagan IP-manzilli kompyuterlar uchun mo'ljallangan bo'lsa, unda bir tarmoqdan boshqasiga yo'naltirish marshrutini hisoblash uchun unga maxsus qoidalar qo'llaniladi.

Niqob - bu aytib beradigan parametr dasturiy ta'minot ushbu guruhda (quyi tarmoq) nechta kompyuter birlashtirilganligi haqida. Manzil maskasi IP-manzilning o'zi bilan bir xil tuzilishga ega: u har biri 0 dan 255 gacha bo'lishi mumkin bo'lgan to'rtta guruh raqamlar to'plamidir. Bunday holda, niqob qiymati qanchalik past bo'lsa, ushbu kichik tarmoqqa ko'proq kompyuterlar ulanadi. Kichik kompaniya tarmoqlari uchun niqob odatda 255.255.255.x (masalan, 255.255.255.224) hisoblanadi. Tarmoq niqobi IP manzili bilan birga kompyuterga tayinlanadi. Masalan, 255.255.255.0 maskali 192.168.0.0 tarmog'ida 192.168.0.1 dan 192.168.254 192.168.0.0 gacha bo'lgan manzillari bo'lgan kompyuterlar bo'lishi mumkin. 2,1 68,0. 127. Menimcha, ma'nosi aniq. Qoidaga ko'ra, IP-manzillarni saqlash uchun provayderlar kam sonli kompyuterlarga ega tarmoqlardan foydalanadilar. Masalan, mijozga 255.255.255.252 niqobli manzil berilishi mumkin. Ushbu quyi tarmoq faqat ikkita kompyuterni o'z ichiga oladi.

Kompyuter IP-manzilni olgandan so'ng va pastki tarmoq niqobining qiymatini bilgandan so'ng, dastur ushbu mahalliy quyi tarmoqda ishlashni boshlashi mumkin. Biroq, global tarmoqdagi boshqa kompyuterlar bilan ma'lumot almashish uchun siz tashqi tarmoq uchun ma'lumotni qayerga jo'natish qoidalarini bilishingiz kerak. Shu maqsadda Gateway manzili kabi xarakteristikadan foydalaniladi.

Gateway nima?

Shlyuz - bu turli xil IP quyi tarmoqlari o'rtasida ma'lumotlarni uzatuvchi qurilma (kompyuter yoki router). Agar dastur (IP va niqob bo'yicha) maqsad manzili mahalliy quyi tarmoqning bir qismi emasligini aniqlasa, u bu ma'lumotlarni shlyuz vazifasini bajaradigan qurilmaga yuboradi. Protokol sozlamalarida bunday qurilmaning IP-manzilini belgilang.

Faqat mahalliy tarmoqda ishlash uchun shlyuz ko'rsatilmagan bo'lishi mumkin.

Internetga ulanadigan individual foydalanuvchilar yoki bitta ulanish kanaliga ega bo'lgan kichik korxonalar uchun tizim faqat bitta shlyuz manziliga ega bo'lishi kerak - bu Internetga ulangan qurilmaning manzili. Agar bir nechta marshrutlar bo'lsa, bir nechta shlyuzlar bo'ladi. Bunday holda, ma'lumotlar yo'lini aniqlash uchun marshrutlash jadvalidan foydalaniladi.

Marshrutlash jadvallari nima

Shunday qilib, biz ularga muammosiz etib keldik. Va shuning uchun.. Bu qanday jadvallar?

Tashkilot yoki foydalanuvchi Internetga ulanishning bir nechta nuqtalariga ega bo'lishi mumkin (masalan, birinchi provayderda biror narsa noto'g'ri bo'lgan taqdirda zaxira kanallari, lekin Internet hali ham juda zarur) yoki uning tarkibida bir nechta IP-tarmoqlarni o'z ichiga olishi mumkin. Bunday holda, tizim u yoki bu ma'lumotlarni qaysi yo'l bilan (qaysi shlyuz orqali) yuborishni bilishi uchun marshrutlash jadvallari qo'llaniladi. Har bir shlyuz uchun marshrutlash jadvallari ular orqali ma'lumot uzatilishi kerak bo'lgan Internet quyi tarmoqlarini ko'rsatadi. Bunday holda, bir nechta shlyuzlar uchun siz bir xil diapazonlarni o'rnatishingiz mumkin, ammo ma'lumotlarni uzatish uchun har xil xarajatlar bilan: masalan, ma'lumot eng past narxga ega bo'lgan kanal orqali yuboriladi va agar u yoki boshqa sabablarga ko'ra muvaffaqiyatsiz bo'lsa, keyingi mavjud ko'pchilik avtomatik ravishda arzon ulanishdan foydalaniladi.

Tarmoq portlari nima

Ma'lumotlarni uzatishda, jo'natuvchi va qabul qiluvchining IP manzillaridan tashqari, ma'lumotlar paketi port raqamlarini o'z ichiga oladi. Misol: 192.168.1.1:80, - bu holda 80 port raqamidir. Port - bu ma'lumotlarni qayta ishlash kerak bo'lgan jarayonni (dasturni) aniqlash uchun ma'lumotlarni qabul qilish va uzatishda foydalaniladigan raqam. Shunday qilib, agar paket 80-portga yuborilsa, bu ma'lumot HTTP serveri uchun mo'ljallanganligini ko'rsatadi.

1 dan 1023 gacha bo'lgan port raqamlari ma'lum dasturlarga (ma'lum portlar deb ataladi) tayinlangan. 1024 -65 535 raqamli portlardan xususiy dasturlarda foydalanish mumkin. Bunday holda, mumkin bo'lgan nizolar bepul portni tanlash orqali dasturlarning o'zlari tomonidan hal qilinishi kerak. Boshqacha qilib aytadigan bo'lsak, portlar dinamik ravishda taqsimlanadi: dastur keyingi safar ishga tushganda, u boshqa port qiymatini tanlashi mumkin, agar siz portni sozlamalar orqali qo'lda o'rnatmasangiz.

MAC manzili nima

Gap shundaki, tarmoqqa yuborilgan paketlar nomlari yoki IP manzillari bilan emas, balki kompyuterlarga qaratilgan. Paket ma'lum bir manzilga ega bo'lgan qurilma uchun mo'ljallangan, u MAC manzili deb ataladi.

MAC manzili tarmoq qurilmasining o'ziga xos manzili bo'lib, unga uskuna ishlab chiqaruvchisi tomonidan tayinlangan, ya'ni. Bu tarmoq kartangizning muhrlangan raqamining bir turi. MAC manzilining birinchi yarmi ishlab chiqaruvchining identifikatori, ikkinchisi - bu qurilmaning noyob raqami.

Qoidaga ko'ra, MAC manzili provayder bilan identifikatsiya qilish uchun talab qilinadi (agar provayder login-parol o'rniga MAC manzilini bog'lashdan foydalansa) yoki routerni sozlashda.

Barcha tarmoq sozlamalarini qaerda ko'rish mumkin

Bularning barchasini qayerga qarash va o'zgartirish mumkinligi haqida bir necha so'z aytishni deyarli unutib qo'ydim.