Өнөөдрийн видео хичээлийг эхлүүлэхийн өмнө миний хичээлийг YouTube дээр түгээхэд хувь нэмрээ оруулсан бүх хүмүүст баярлалаа гэж хэлмээр байна. Би үүнийг 8 сарын өмнө эхлүүлэхдээ ийм амжилтанд хүрнэ гэж төсөөлөөгүй байсан - өнөөдөр миний хичээлийг 312724 хүн үзсэн, би 11208 захиалагчтай болсон. Энэ даруухан эхлэл ийм өндөрлөгт хүрнэ гэж зүүдэлсэн ч үгүй. Гэхдээ цаг дэмий үрэлгүй өнөөдрийн хичээлдээ шууд орцгооё. Өнөөдөр бид сүүлийн 7 видео хичээл дээр гарсан цоорхойг нөхөх болно. Хэдийгээр өнөөдөр 6 дахь өдөр боловч 3 дахь өдөр нь 3 видео хичээлд хуваагдсан тул өнөөдөр та найм дахь видео хичээлийг үзэх болно.
Өнөөдөр бид 3 чухал сэдвийг авч үзэх болно: DHCP, TCP тээвэрлэлт, хамгийн түгээмэл портын дугаарууд. Бид IP хаягуудын талаар аль хэдийн ярьсан бөгөөд IP хаягийн тохиргоонд хамгийн чухал хүчин зүйлүүдийн нэг нь DHCP юм.
DHCP нь Dynamic Host Configuration Protocol гэсэн үг бөгөөд энэ нь хостуудын IP хаягийг динамикаар тохируулахад тусалдаг протокол юм. Тиймээс бид бүгд энэ цонхыг харсан. "IP хаягийг автоматаар авах" сонголтыг дарахад компьютер ижил дэд сүлжээнд тохируулагдсан DHCP серверийг хайж, янз бүрийн пакетууд болон IP хаягийн хүсэлтийг илгээдэг. DHCP протокол нь 6 мессежтэй бөгөөд үүнээс 4 нь IP хаяг өгөхөд чухал үүрэгтэй.
Эхний мессеж нь DHCP DISCOVERY мессеж юм. DHCP илрүүлэх мессеж нь мэндчилгээний мессежтэй төстэй. Шинэ төхөөрөмж сүлжээнд нэгдэх үед сүлжээнд DHCP сервер байгаа эсэхийг асууна.
Таны слайдаас харж буй зүйл нь DHCP сервер хайж буй төхөөрөмж сүлжээн дэх бүх төхөөрөмжтэй холбогдох өргөн нэвтрүүлгийн хүсэлт шиг харагдаж байна. Миний хэлсэнчлэн энэ бол өргөн нэвтрүүлгийн хүсэлт тул сүлжээнд байгаа бүх төхөөрөмж үүнийг сонсох боломжтой.
Хэрэв сүлжээнд DHCP сервер байгаа бол пакет илгээдэг - DHCP OFFER санал. Санал гэдэг нь DHCP сервер нь илрүүлэх хүсэлтийн хариуд үйлчлүүлэгчээс тодорхой IP хаягийг хүлээн авахыг хүссэн тохиргоог үйлчлүүлэгч рүү илгээдэг гэсэн үг юм.
DHCP сервер нь IP хаягийг хадгалдаг бөгөөд энэ тохиолдолд 192.168.1.2 нь үүнийг өгөхгүй, харин энэ хаягийг төхөөрөмжид зориулж хадгалдаг. Үүний зэрэгцээ санал болгож буй багц нь DHCP серверийн өөрийн IP хаягийг агуулдаг.
Хэрэв энэ сүлжээнд нэгээс олон DHCP сервер байгаа бол өөр DHCP сервер нь үйлчлүүлэгчийн өргөн нэвтрүүлгийн хүсэлтийг хүлээн авмагц IP хаягаа санал болгоно, жишээ нь 192.168.1.50. Нэг сүлжээнд хоёр өөр DHCP сервер тохируулах нь тийм ч түгээмэл биш боловч заримдаа ийм зүйл тохиолддог. Тиймээс DHCP саналыг үйлчлүүлэгч рүү илгээх үед 2 DHCP саналыг хүлээн авах бөгөөд одоо аль DHCP саналыг хүлээж авахыг шийдэх ёстой.
Үйлчлүүлэгч эхний өргөдлийг хүлээн авсан гэж үзье. Энэ нь үйлчлүүлэгч DHCP REQUEST хүсэлтийг шууд утгаараа "Би DHCP сервер 192.168.1.2 санал болгож буй 192.168.1.1 IP хаягийг хүлээн зөвшөөрч байна" гэсэн үг юм.
Хүсэлтийг хүлээн авмагц 192.168.1.1 DHCP сервер нь "за, би зөвшөөрч байна" гэж хариулах бөгөөд өөрөөр хэлбэл хүсэлтийг хүлээн зөвшөөрч, энэ DHCP ACK-г үйлчлүүлэгч рүү илгээдэг. Гэхдээ өөр DHCP сервер нь үйлчлүүлэгчийн хувьд 1.50 IP хаягийг нөөцөлсөн гэдгийг бид санаж байна. Үйлчлүүлэгчийн өргөн нэвтрүүлгийн хүсэлтийг хүлээн авмагц тэр бүтэлгүйтлийн талаар мэдэж, өөр хүсэлт хүлээн авбал өөр үйлчлүүлэгчид үүнийг оноож өгөхийн тулд тэр IP хаягийг сан руу буцааж оруулах болно.
Эдгээр нь IP хаягийг өгөхдөө DHCP солилцдог 4 чухал мессеж юм. Дараа нь DHCP нь өөр 2 мэдээллийн мессежтэй байна. Хоёрдахь алхам дахь DHCP OFFER заалтаас илүү мэдээлэл шаардлагатай бол үйлчлүүлэгч мэдээллийн мессежийг гаргадаг. Хэрэв сервер DHCP саналд хангалттай мэдээлэл өгөөгүй эсвэл үйлчлүүлэгч санал болгож буй багцад агуулагдахаас илүү мэдээлэл авах шаардлагатай бол нэмэлт DHCP мэдээлэл авахыг хүсдэг. Үйлчлүүлэгчийн сервер рүү илгээдэг өөр нэг мессеж байна - энэ бол DHCP RELEASE юм. Энэ нь үйлчлүүлэгч одоо байгаа IP хаягаа гаргахыг хүсч байгааг танд мэдэгдэнэ.
Гэсэн хэдий ч ихэвчлэн тохиолддог зүйл бол үйлчлүүлэгч DHCP RELEASE-г сервер рүү илгээхээс өмнө сүлжээнээс салдаг. Энэ нь таны компьютерийг унтраах үед тохиолддог бөгөөд үүнийг бид хийдэг. Энэ тохиолдолд сүлжээний клиент буюу компьютерт ашигласан хаягаа гаргахын тулд серверт мэдэгдэх цаг байхгүй тул DHCP RELEASE нь шаардлагатай алхам биш юм. IP хаяг авахад шаардлагатай алхамууд нь: DHCP илрүүлэх, DHCP санал, DHCP хүсэлт, DHCP гар барих.
Дараагийн хичээлүүдийн аль нэгэнд би DNCP сан үүсгэх үед DHCP серверийг хэрхэн тохируулахыг танд хэлэх болно. Нэгтгэх гэдэг нь та серверт IP хаягийг 192.168.1.1-ээс 192.168.1.254 хүртэлх зайд өгөхийг хэлнэ гэсэн үг юм. Тиймээс DHCP сервер нь сан үүсгэж, түүнд 254 IP хаяг байрлуулж, зөвхөн энэ сангаас сүлжээнд байгаа үйлчлүүлэгчдэд хаяг өгөх боломжтой болно. Тэгэхээр энэ нь хэрэглэгчийн хийж чадах удирдлагын тохиргоотой адил зүйл юм.
Одоо TCP дамжуулалтыг харцгаая. Таныг зурган дээрх "утас"-ыг мэддэг эсэхийг мэдэхгүй ч бид багадаа утсаар холбосон эдгээр цагаан тугалгатай лаазнууд хоорондоо ярилцдаг байсан.
Харамсалтай нь өнөөгийн үеийнхэн ийм “тансаг” авч чадахгүй. Өнөөдөр хүүхдүүд нэг настайгаасаа зурагтын өмнө байдаг, тэд PSP тоглодог, магадгүй энэ нь маргаантай байдаг, гэхдээ бид хамгийн сайхан хүүхэд насаа өнгөрөөсөн гэж бодож байна, бид гадаа гарч, тоглоом тоглодог байсан, одоогийн хүүхдүүдийг буйдангаас холдуулах боломжгүй юм. .
Миний хүү дөнгөж нэг настай, би түүнийг iPad-д донтсоныг нь аль хэдийн харж байна, би тэр залуу хэвээр байна гэсэн үг, гэхдээ одоогийн хүүхдүүд аль хэдийн электрон хэрэгсэлтэй харьцахаа мэддэг болсон гэж бодож байна. Тэгээд хүүхэд байхдаа бид нар тоглож байхдаа лаазыг нүхлээд, утсаар уяад нэг лаазанд юм хэлэхэд нөгөө талд нь хүн юу ярьж байгааг сонсдог байсан гэж хэлмээр санагдлаа. зүгээр л лаазыг нь чихэнд нь наахад л . Тиймээс энэ нь сүлжээний холболттой маш төстэй юм.
Өнөө үед TCP дамжуулалт ч гэсэн бодит өгөгдөл дамжуулах эхлэхээс өмнө заавал байх ёстой холболттой байх ёстой. Өмнөх хичээлүүдэд дурдсанчлан TCP нь холболтод чиглэсэн дамжуулалт, UDP нь холболтод чиглэсэн дамжуулалт юм. UDP бол миний бөмбөг шидэж байгаа газар бөгөөд та үүнийг барьж чадах эсэх нь танд хамаарна гэж хэлж болно. Чи үүнийг хийхэд бэлэн байгаа эсэх нь миний асуудал биш, би түүнийг зүгээр л орхих болно.
TCP нь та нэг залуутай ярилцаж, бөмбөг шидэх гэж байгаагаа урьдчилан сануулж байгаатай адил бөгөөд та холбоо тогтоож, дараа нь бөмбөгийг шидэж, ингэснээр таны хамтрагч бөмбөгийг барьж авахад илүү бэлэн байх болно. Тиймээс TCP нь холболтыг бүтээж, дараа нь бодит дамжуулалтыг хийж эхэлдэг.
Ийм холболтыг хэрхэн бий болгож байгааг харцгаая. Энэ протокол нь холболт үүсгэхийн тулд 3 талын гар барих аргыг ашигладаг. Энэ нь тийм ч техникийн нэр томъёо биш боловч TCP холболтыг тодорхойлоход удаан хугацаагаар ашиглагдаж ирсэн. 3 талын гар барих ажиллагааг илгээгч төхөөрөмж эхлүүлж, үйлчлүүлэгч SYN туг бүхий пакетыг сервер рүү илгээдэг.
Бидний царайг харж байгаа урд талын охин нь А төхөөрөмж, цаана нь байгаа царай нь харагдахгүй байгаа охин нь Б төхөөрөмж гэж бодъё.А охин Б охин руу SYN пакет илгээж, тэр: "Гайхалтай, тэр надтай харилцахыг хүсч байна. Тиймээс би харилцахад бэлэн гэдгээ хариулах хэрэгтэй байна!" Үүнийг хэрхэн хийх вэ? Өөр нэг SYN багцыг буцааж илгээж, дараа нь анхны SYN пакетийг хүлээн авсан тухай ACK-г илгээж болно. Гэхдээ сервер нь ACK-г тусад нь илгээхийн оронд SYN болон ACK-г агуулсан нийтлэг пакет үүсгэж, сүлжээгээр дамжуулдаг.
Энэ үед А төхөөрөмж SYN пакет илгээж, SYN/ACK багцыг буцааж хүлээн авсан. Одоо А төхөөрөмж В төхөөрөмжид ACK пакет илгээх ёстой, өөрөөр хэлбэл В төхөөрөмжөөс холбоо тогтоох зөвшөөрөл авсан гэдгээ баталгаажуулах ёстой. Ийнхүү хоёр төхөөрөмж хоёулаа SYN болон ACK пакетуудыг хүлээн авсан бөгөөд одоо холболт хийгдсэн гэж хэлж болно, өөрөөр хэлбэл TCP протоколыг ашиглан 3 үе шаттай гар барих ажил дууссан.
Дараа нь бид TCP Windowing технологийг авч үзэх болно. Энгийнээр хэлбэл, энэ нь илгээгч болон хүлээн авагчийн чадавхийг тохиролцохын тулд TCP/IP-д хэрэглэгддэг арга юм.
Windows дээр бид 2 ГБ хэмжээтэй том файлыг нэг дискнээс нөгөөд шилжүүлэхийг оролдож байна гэж бодъё. Шилжүүлгийн эхэн үед систем нь файлыг шилжүүлэхэд ойролцоогоор 1 жил шаардагдахыг мэдэгдэнэ. Гэвч хэдхэн секундын дараа систем өөрөө өөрийгөө засаад: "Өө, түр хүлээнэ үү, би үүнд нэг жил биш, 6 сар зарцуулна гэж бодож байна" гэж хэлэх болно. Дахиад бага зэрэг хугацаа өнгөрөхөд Windows "Би 1 сарын дараа файлыг шилжүүлж чадна гэж бодож байна" гэж хэлэх болно. Үүний дараа "1 өдөр", "6 цаг", "3 цаг", "1 цаг", "20 минут", "10 минут", "3 минут" гэсэн мессежүүд гарч ирнэ. Үнэн хэрэгтээ файл дамжуулах бүх процесс ердөө 3 минут болно. Энэ яаж болсон бэ? Эхлээд таны төхөөрөмж өөр төхөөрөмжтэй холбогдохыг оролдох үед нэг пакет илгээж, баталгаажуулахыг хүлээнэ. Хэрэв төхөөрөмж баталгаажуулахыг удаан хүлээвэл "хэрэв би ийм хурдаар 2 ГБ өгөгдөл дамжуулах шаардлагатай бол 2 жил орчим болно" гэж боддог. Хэсэг хугацааны дараа таны төхөөрөмж ACK хүлээн авч, "За, би нэг пакет илгээж, ACK хүлээн авсан тул хүлээн авагч 1 пакет хүлээн авах боломжтой. Одоо би түүнд нэг биш 10 багц илгээхийг хичээх болно." Илгээгч нь 10 пакет илгээж, хэсэг хугацааны дараа хүлээн авагч төхөөрөмжөөс ACK баталгаажуулалтыг хүлээн авдаг бөгөөд энэ нь хүлээн авагч дараагийн 11 дэх багцыг хүлээж байна гэсэн үг юм. Илгээгч: "Гайхалтай, хүлээн авагч нэг дор 10 пакет илгээсэн тул би түүнд арав биш 100 пакет илгээхийг хичээх болно." Тэр 100 пакет илгээж, хүлээн авагч нь хүлээн авсан гэж хариулж, одоо 101 пакет хүлээж байна. Тиймээс цаг хугацаа өнгөрөх тусам дамжуулагдсан пакетуудын тоо нэмэгддэг.
Ийм учраас та анх дурдсантай харьцуулахад файл хуулах хугацаа хурдан буурч байгааг харж байна - энэ нь их хэмжээний өгөгдөл дамжуулах чадвар нэмэгдсэнтэй холбоотой юм. Гэсэн хэдий ч дамжуулалтын хэмжээг цаашид нэмэгдүүлэх боломжгүй болох үе ирдэг. Та 10000 пакет илгээсэн гэж бодъё, гэхдээ хүлээн авагчийн төхөөрөмжийн буфер нь зөвхөн 9000-ыг хүлээн авах боломжтой. Энэ тохиолдолд хүлээн авагч нь "Би 9000 пакет хүлээн авлаа, одоо 9001 пакет хүлээн авахад бэлэн байна" гэсэн мессеж бүхий ACK илгээдэг. Эндээс илгээгч нь хүлээн авагч төхөөрөмжийн буфер нь ердөө 9000-ын багтаамжтай гэж дүгнэсэн нь одооноос би нэг удаад 9000-аас илүүгүй пакет илгээх болно гэсэн үг юм. Энэ тохиолдолд илгээгч нь үлдсэн өгөгдлийг 9000 пакетаар дамжуулахад шаардагдах хугацааг хурдан тооцоолж, 3 минут өгдөг. Эдгээр гурван минут бол дамжуулах бодит хугацаа юм. Үүнийг TCP Windowing хийдэг.
Энэ бол илгээгч төхөөрөмж нь эцсийн эцэст сүлжээний хүчин чадал гэж юу болохыг ойлгодог траффик дарах механизмуудын нэг юм. Хүлээн авах төхөөрөмжийн хүчин чадал ямар байх талаар тэд яагаад урьдчилан тохиролцож чадахгүй байгааг та гайхаж магадгүй юм? Сүлжээнд янз бүрийн төрлийн төхөөрөмжүүд байдаг тул энэ нь техникийн хувьд боломжгүй зүйл юм. Та iPad-тай, iPhone-оос өөр мэдээлэл дамжуулах/хүлээн авагчийн хурдтай, өөр төрлийн утастай, эсвэл маш хуучин компьютертэй гэж бодъё. Тиймээс хүн бүр өөр өөр сүлжээний зурвасын өргөнтэй байдаг.
Тийм ч учраас өгөгдөл дамжуулах бага хурдтай эсвэл хамгийн бага тооны пакет дамжуулалтаар эхэлж, урсгалын "цонх" -ыг аажмаар нэмэгдүүлж байх үед TCP Windowing технологийг боловсруулсан. Та нэг пакет, 5 пакет, 10 пакет, 1000 пакет, 10000 пакет илгээж, тодорхой хугацаанд илгээсэн траффикийн хамгийн дээд хэмжээнд хүрэх хүртэл "нээлт" цонхыг аажмаар нээнэ. Тиймээс Цонхны тухай ойлголт нь TCP протоколын үйл ажиллагааны нэг хэсэг юм.
Дараа нь бид хамгийн түгээмэл портын дугааруудыг авч үзэх болно. Сонгодог нөхцөл бол танд 1 үндсэн сервер, магадгүй дата төвтэй байх явдал юм. Үүнд файл сервер, вэб сервер, шуудангийн сервер, DHCP сервер орно. Одоо, хэрэв үйлчлүүлэгч компьютерийн аль нэг нь зургийн голд байрлах дата төвтэй холбоо барвал энэ нь файлын серверийн траффикийг клиент төхөөрөмж рүү илгээж эхэлнэ. Энэ урсгалыг улаанаар харуулсан бөгөөд тодорхой серверээс тодорхой програмын тусгай порт дээр дамжуулагдах болно.
Тодорхой урсгал хаашаа явах ёстойг сервер яаж мэдсэн бэ? Тэр үүнийг очих портын дугаараас сурдаг. Хэрэв та хүрээг харвал өгөгдөл дамжуулах бүрт очих портын дугаар болон эх портын дугаарыг дурьдсан байхыг харах болно. Цэнхэр, улаан урсгал, цэнхэр урсгал нь вэб серверийн траффик бөгөөд хоёулаа өөр өөр сервер суулгасан ижил физик сервер рүү очдог болохыг харж болно. Хэрэв энэ нь дата төв юм бол виртуал сервер ашигладаг. Тэгэхээр улаан урсгал тэр IP хаягтай зүүн зөөврийн компьютер руу буцах ёстойг тэд яаж мэдсэн бэ? Тэд портын дугаарын ачаар үүнийг мэддэг. Хэрэв та Википедиагийн "TCP ба UDP портуудын жагсаалт" гэсэн өгүүллийг харвал бүх стандарт портын дугааруудыг жагсаасан байхыг харах болно.
Хэрэв та энэ хуудсыг доош гүйлгэж үзвэл энэ жагсаалт хэр том болохыг харж болно. Энэ нь ойролцоогоор 61 тоог агуулдаг. 000-ээс 1 хүртэлх портын дугаарыг хамгийн түгээмэл портын дугаар гэж нэрлэдэг. Жишээлбэл, порт 1024/TCP нь ftp командыг илгээх, 21-р порт нь ssh, 22-р порт нь Telnet, өөрөөр хэлбэл шифрлэгдээгүй мессеж илгээх зориулалттай. Маш алдартай порт 23 нь HTTP-ээр өгөгдөл дамжуулдаг бол 80 порт нь HTTPS-ээр шифрлэгдсэн өгөгдлийг дамжуулдаг бөгөөд энэ нь HTTP-ийн аюулгүй хувилбартай төстэй юм.
Зарим портууд нь TCP болон UDP-д зориулагдсан байдаг ба зарим нь холболт нь TCP эсвэл UDP эсэхээс хамаарч өөр өөр үүрэг гүйцэтгэдэг. Тиймээс албан ёсоор TCP 80 портыг HTTP-д ашигладаг бөгөөд албан бусаар UDP 80 портыг HTTP-д ашигладаг, гэхдээ өөр HTTP протоколын дагуу - QUIC.
Тиймээс TCP дахь портын дугаарууд нь UDP-тэй ижил зүйлийг хийх зорилготой байдаггүй. Та энэ жагсаалтыг цээжээр сурах шаардлагагүй, үүнийг санах боломжгүй, гэхдээ та алдартай, хамгийн түгээмэл портын дугаарыг мэдэх хэрэгтэй. Миний хэлсэнчлэн эдгээр портуудын зарим нь стандартад заасан албан ёсны зорилготой, зарим нь Chromium-тай адил албан бус зорилготой байдаг.
Тиймээс, энэ хүснэгтэд бүх нийтлэг портын дугаарыг жагсаасан бөгөөд эдгээр дугаарууд нь тодорхой програмуудыг ашиглах үед урсгалыг илгээх, хүлээн авахад ашиглагддаг.
Одоо бидний мэддэг өчүүхэн мэдээлэл дээр үндэслэн өгөгдөл сүлжээгээр хэрхэн дамждагийг харцгаая. 10.1.1.10 компьютер энэ компьютер эсвэл 30.1.1.10 хаягтай сервертэй холбогдохыг хүсч байна гэж бодъё. Төхөөрөмж бүрийн IP хаягийн доор MAC хаяг байна. Би зөвхөн сүүлийн 4 тэмдэгттэй MAC хаягийн жишээг өгч байна, гэхдээ бодит байдал дээр энэ нь 48 тэмдэгтээс бүрдэх 12 битийн арван зургаатын тоо юм. Эдгээр тоо тус бүр нь 4 битээс бүрддэг тул 12 арван арван цифр нь 48 битийн тоог илэрхийлдэг.
Бидний мэдэж байгаагаар хэрэв энэ төхөөрөмж энэ сервертэй холбогдохыг хүсвэл 3 талын гар барих эхний алхам буюу SYN пакет илгээх ёстой. Энэ хүсэлтийг хийх үед компьютер 10.1.1.10 нь Windows динамикаар үүсгэсэн эх портын дугаарыг зааж өгөх болно. Windows санамсаргүй байдлаар 1-ээс 65,000 хүртэлх портын дугаарыг сонгоно. Гэхдээ 1-ээс 1024 хүртэлх тоонуудын эхлэлийн тоо түгээмэл байдаг тул энэ тохиолдолд систем нь 25000-аас дээш тоог авч үзээд санамсаргүй эх үүсвэрийн порт, жишээлбэл, 25113 дугаарыг бий болгоно.
Дараа нь систем нь пакет руу очих портыг нэмэх бөгөөд энэ тохиолдолд порт 21 болно, учир нь энэ FTP сервертэй холбогдохыг оролдож буй програм нь FTP траффик илгээх ёстой гэдгийг мэддэг.
Дараа нь манай компьютер "За, миний IP хаяг 10.1.1.10, би 30.1.1.10 IP хаягтай холбогдох хэрэгтэй" гэж хэлдэг. Эдгээр хаягууд хоёулаа SYN хүсэлт үүсгэхийн тулд багцад багтсан бөгөөд холболт дуусах хүртэл энэ пакет өөрчлөгдөхгүй.
Энэ видеоноос өгөгдөл сүлжээгээр хэрхэн дамждагийг ойлгохыг хүсч байна. Хүсэлтийг илгээж буй манай компьютер эх сурвалжийн IP хаяг болон очих газрын IP хаягийг харах үед очих хаяг нь тухайн дотоод сүлжээнд байхгүй гэдгийг ойлгодог. Эдгээр нь бүгд /24 IP хаяг гэдгийг хэлэхээ мартсан байна. Тэгэхээр /24 IP хаягийг харвал 10.1.1.10 болон 30.1.1.10 компьютерууд нэг сүлжээнд байхгүй гэдгийг ойлгох болно. Тиймээс хүсэлтийг илгээж буй компьютер нь энэ сүлжээнээс гарахын тулд чиглүүлэгчийн аль нэг интерфэйс дээр тохируулагдсан 10.1.1.1 гарцтай холбогдох ёстой гэдгийг ойлгож байна. Энэ нь 10.1.1.1 рүү очих ёстойг мэддэг бөгөөд 1111 гэсэн MAC хаягаа мэддэг боловч 10.1.1.1 гарцын MAC хаягийг мэддэггүй. Тэр юу хийж байна вэ? Энэ нь сүлжээнд байгаа бүх төхөөрөмжүүдийг хүлээн авах өргөн нэвтрүүлгийн ARP хүсэлтийг илгээдэг боловч зөвхөн 10.1.1.1 IP хаягтай чиглүүлэгч л хариу өгөх болно.
Чиглүүлэгч нь өөрийн AAAA MAC хаягаар хариу өгөх бөгөөд эх сурвалж болон очих MAC хаягуудыг мөн энэ хүрээнд байрлуулах болно. Фрейм бэлэн болмогц сүлжээнээс гарахын өмнө алдааг илрүүлэх хяналтын нийлбэрийг олох алгоритм болох CRC өгөгдлийн бүрэн бүтэн байдлын шалгалтыг хийнэ.
Cyclic Redundancy CRC гэдэг нь SYN-ээс сүүлчийн MAC хаяг хүртэлх бүх хүрээг MD5 гэх мэт хэш алгоритмаар ажиллуулж, хэш утгыг үүсгэдэг гэсэн үг юм. Дараа нь хэш утга буюу MD5 хяналтын нийлбэрийг хүрээний эхэнд байрлуулна.
FCS нь Frame Check Sequence буюу дөрвөн байт CRC утга учир би үүнийг FCS/CRC гэж шошгосон. Зарим хүмүүс FCS, зарим нь CRC гэсэн тэмдэглэгээг ашигладаг тул би хоёр тэмдэглэгээг орууллаа. Гэхдээ үндсэндээ энэ нь зүгээр л хэш утга юм. Сүлжээгээр хүлээн авсан бүх өгөгдөлд алдаа байхгүй эсэхийг шалгах шаардлагатай. Тиймээс, энэ хүрээ чиглүүлэгчид хүрэх үед чиглүүлэгчийн хийх хамгийн эхний зүйл бол шалгах нийлбэрийг өөрөө тооцоолж, хүлээн авсан фрейм агуулсан FCS эсвэл CRC утгатай харьцуулах явдал юм. Ингэснээр тэр сүлжээгээр хүлээн авсан өгөгдөлд алдаа байхгүй эсэхийг шалгах боломжтой бөгөөд үүний дараа тэрээр хяналтын нийлбэрийг хүрээнээс хасах болно.
Дараа нь чиглүүлэгч MAC хаягийг хараад "За, MAC хаяг AAAA гэдэг нь хүрээ надад хаяглагдсан гэсэн үг" гэж хэлээд MAC хаягуудыг агуулсан фреймийн хэсгийг устгана.
30.1.1.10 очих IP хаягийг харвал тэр энэ пакет түүнд хаяглаагүй бөгөөд чиглүүлэгчээр цааш явах ёстой гэдгийг ойлгох болно.
Одоо чиглүүлэгч нь 30.1.1.10 хаягтай сүлжээ хаана байгааг харах хэрэгтэй гэж "бодож" байна. Бид чиглүүлэлтийн тухай бүрэн ойлголтыг хараахан авч үзээгүй байгаа ч чиглүүлэгчид чиглүүлэлтийн хүснэгттэй байдгийг бид мэднэ. Энэ хүснэгтэд 30.1.1.0 хаягтай сүлжээний оруулга байна. Таны санаж байгаагаар энэ нь хостын IP хаяг биш, харин сүлжээний танигч юм. Чиглүүлэгч нь 30.1.1.0 чиглүүлэгчээр дамжин 24/20.1.1.2 хаягт хүрч чадна гэж "бодох" болно.
Тэр яаж үүнийг мэддэг юм бэ гэж та асууж магадгүй юм. Хэрэв та администраторын хувьд статик маршрутыг тохируулсан бол энэ нь чиглүүлэлтийн протоколууд эсвэл таны тохиргооноос үүнийг мэдэх болно гэдгийг санаарай. Гэхдээ ямар ч тохиолдолд энэ чиглүүлэгчийн чиглүүлэлтийн хүснэгт нь зөв оруулгыг агуулсан тул энэ пакетийг 20.1.1.2 руу илгээх ёстой гэдгийг мэддэг. Чиглүүлэгч нь очих газрын MAC хаягийг аль хэдийн мэддэг гэж үзвэл бид пакетыг үргэлжлүүлэн дамжуулах болно. Хэрэв тэр энэ хаягийг мэдэхгүй бол ARP-г дахин эхлүүлж, чиглүүлэгчийн 20.1.1.2 MAC хаягийг хүлээн авч, фрейм илгээх үйл явц дахин үргэлжилнэ.
Тиймээс бид энэ нь MAC хаягийг аль хэдийн мэддэг гэж үзвэл BBB эх сурвалжийн MAC хаяг болон CCC очих MAC хаягтай болно. Чиглүүлэгч нь FCS/CRC-г дахин тооцоолж, хүрээний эхэнд байрлуулна.
Дараа нь энэ фреймийг сүлжээгээр илгээж, фрейм нь чиглүүлэгч 20.1.12-т хүрч, шалгах нийлбэрийг шалгаж, өгөгдөл гэмтээгүй эсэхийг шалгаж, FCS/CRC-г устгадаг. Дараа нь MAC хаягуудыг "тайрч", очих газраа хараад 30.1.1.10 байна. Энэ хаяг нь түүний интерфейстэй холбогдсон гэдгийг тэр мэддэг. Ижил хүрээ үүсгэх процесс давтагдаж, чиглүүлэгч нь эх сурвалж болон очих MAC хаягийн утгыг нэмж, хэшийг хийж, хэшийг фрейм рүү хавсаргаж, сүлжээгээр дамжуулдаг.
Манай сервер эцэст нь түүнд хаягласан SYN хүсэлтийг хүлээн авсны дараа хэш шалгах нийлбэрийг шалгаж, хэрэв пакет алдаагүй бол хэшийг устгадаг. Дараа нь тэр MAC хаягуудыг устгаж, IP хаягийг хараад энэ пакет өөрт нь хаяглагдсан болохыг ойлгов.
Үүний дараа OSI загварын гурав дахь давхаргатай холбоотой IP хаягуудыг тайрч, портын дугааруудыг харна.
Тэрээр 21-р портыг хардаг бөгөөд энэ нь FTP траффик гэсэн үг бөгөөд SYN-ийг хардаг тул хэн нэгэн түүнтэй холбогдох гэж оролдож байгааг ойлгодог.
Одоо бид гар барих талаар олж мэдсэн зүйл дээрээ үндэслэн 30.1.1.10 сервер нь SYN/ACK пакет үүсгээд 10.1.1.10 компьютерт буцааж илгээх болно. Энэхүү пакетийг хүлээн авмагц 10.1.1.10 төхөөрөмж нь ACK үүсгэж, SYN пакетийн адилаар сүлжээгээр дамжуулж, сервер ACK хүлээн авсны дараа холболт үүснэ.
Таны мэдэх ёстой нэг зүйл бол энэ бүхэн секунд хүрэхгүй хугацаанд болдог. Энэ бол маш хурдан бөгөөд бүх зүйл танд ойлгомжтой байхын тулд үүнийг удаашруулахыг хичээсэн.
Энэ зааварт сурсан зүйл тань танд хэрэг болно гэж найдаж байна. Хэрэв танд асуулт байвал над руу бичнэ үү [имэйлээр хамгаалагдсан] эсвэл энэ видеоны доор асуултаа үлдээгээрэй.
Дараагийн хичээлээс эхлэн би YouTube-ээс хамгийн сонирхолтой 3 асуултыг сонгож, видео бүрийн төгсгөлд хянан үзэх болно. Одооноос би "Шилдэг асуултууд" булантай байх тул таны нэрийн хамт асуулт тавьж, шууд хариулах болно. Энэ нь ашигтай байх болно гэж бодож байна.
Бидэнтэй хамт байсанд баярлалаа. Манай нийтлэл танд таалагдаж байна уу? Илүү сонирхолтой контент үзэхийг хүсч байна уу? Захиалга өгөх эсвэл найзууддаа санал болгох замаар биднийг дэмжээрэй, Хабр хэрэглэгчдэд зориулсан 30% хямдралтай, анхан шатны түвшний серверүүдийн өвөрмөц аналогийг бид танд зориулан зохион бүтээжээ. (RAID1 болон RAID10, 24 хүртэлх цөм, 40 ГБ хүртэл DDR4-тэй байх боломжтой).
VPS (KVM) E5-2650 v4 (6 цөм) 10GB DDR4 240GB SSD 1Gbps зун хүртэл үнэгүй зургаан сарын хугацаанд төлөхдөө та захиалж болно .
Dell R730xd 2 дахин хямд байна уу? Зөвхөн энд Нидерландад! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 доллараас! тухай уншина уу
Эх сурвалж: www.habr.com