ბიბლიოთეკა
00/07 · ~36 წთ
GUIDEDECK · როგორ გადააქვს ვებს ბაიტები

ქსელები —
პაკეტის მოგზაურობა
თქვენი აპლიკაციიდან მავთულამდე.

36-წუთიანი სამუშაო სესია იმაზე, თუ რა ხდება სინამდვილეში, როცა ბმულს დააჭერთ — შრეები, IP და TCP vs UDP, DNS, TLS, HTTP-ის ვერსიები, შუაში მდგარი ყუთები (დატვირთვის ბალანსერები, პროქსები, CDN-ები) და ინსტრუმენტები, რომლებითაც ამ ყველაფრის დებაგი შეიძლება, როცა რამე გაფუჭდება.

~36 წთდამწყები → საშუალოვენდორნეიტრალური
გადაახვიეთ
01 · აზრობრივი მოდელი 4 წთ

ქსელი აგებულია
შრეებად — თითოეული მომდევნოს მალავს.

ინტერნეტი არავის დაუპროექტებია ერთ გიგანტურ პროგრამად. ეს არის შრეების სტეკი, სადაც თითოეული ერთ საქმეს აგვარებს და დანარჩენს ქვემოთ გადასცემს. თქვენი აპლიკაცია ამბობს "გააგზავნე ეს ტექსტი"; კაბელში ძაბვა მას არასდროს აღელვებს. სტეკის გაგება დებაგის საუკეთესო რუკაა: როცა რაღაც ფუჭდება, შეგიძლიათ იკითხოთ — რომელი შრე.

პროტოკოლი — შეთანხმებული წესების ნაკრები, რომელსაც ორი კომპიუტერი მიჰყვება, რომ ერთმანეთი გაიგონ — როგორც სატელეფონო საუბრის ორივე მხარე თანხმდება ერთსა და იმავე ენაზე ილაპარაკოს, რიგრიგობით თქვას სათქმელი და ყურმილის დადებამდე "ნახვამდის" თქვას. შრე ამ საუბარში ერთი საქმეა (ბიტების გადატანა, ჰოსტის პოვნა, საიმედო მიწოდება, შეტყობინების ფორმატირება) და თითოეული შრე მხოლოდ უშუალოდ მის ზემოთ და ქვემოთ მდგომს ესაუბრება.

TCP/IP-ის მოდელი — ოთხი პრაქტიკული შრე

  • Link — ბიტებს გადააქვს უშუალოდ დაკავშირებულ ორ მანქანას შორის (Wi-Fi, Ethernet). იყენებს MAC მისამართებს.
  • Internet — პაკეტს მრავალ ქსელში ატარებს სწორ მანქანამდე. ეს არის IP.
  • Transport — მონაცემებს ამ მანქანაზე სწორ პროგრამას აწვდის, საიმედოდ ან არასაიმედოდ. ეს არის TCP / UDP.
  • Application — შინაარსი: HTTP, DNS, ელფოსტა. ის, რასაც თქვენი კოდი რეალურად ლაპარაკობს.

გაიგონებთ OSI-ის 7-შრიან მოდელზეც — ეს უფრო ძველი სასწავლო დიაგრამაა. დღემდე ამბობენ "Layer 4 დატვირთვის ბალანსერი" (ტრანსპორტი) ან "Layer 7" (აპლიკაცია); ეს ციფრები OSI-დან მოდის.

Application HTTP · DNS · TLS the meaning Transport TCP · UDP · ports to the right program Internet IP · routing to the right machine Link Wi-Fi · Ethernet · MAC bits on the wire down the stack to send

გასაგზავნად თქვენი მონაცემები სტეკში ქვევით მიდის; მეორე მანქანაზე კი უკან ზევით ადის.

IP პაკეტი
MAC
TCP სეგმენტი
IP
პორტი
HTTP მონაცემები
Link ფრეიმი
თითოეული შრე თავის ჰედერს (მისამართს) ამატებს

ინკაფსულაცია: თითოეული შრე ზემოთ მდგომს თავის ჰედერში ახვევს — როგორც წერილი კონვერტში, კონვერტი ტომარაში, ტომარა კი მანქანაში.

წაიკითხეთ სქემა — ინკაფსულაცია

  • თქვენი HTTP მონაცემები წერილია. TCP ამატებს ჰედერს პორტით (რომელი პროგრამა), IP ამატებს მანქანის მისამართს, Link კი — შემდეგი ნახტომის აპარატურულ მისამართს.
  • შუაში მდგარი როუტერები მხოლოდ იმ გარე შრეებს ხსნიან, რომლებიც სჭირდებათ — კითხულობენ IP მისამართს და არა თქვენს მონაცემებს.
  • მიმღები უკუღმა ხსნის შესახვევებს და წერილს თავის აპლიკაციას აწვდის. იგივე კონვერტები, საპირისპირო თანმიმდევრობით გახსნილი.

ჰგავს  ამანათის გაგზავნას: თქვენ წერილს წერთ, კურიერი დაუმატებს გასაგზავნ ეტიკეტს, საწყობი კი — მარშრუტს; თითოეული შრე ენდობა ქვედას, რომ ის მიიტანს.

02 · მისამართები, პორტები, ტრანსპორტი 6 წთ

IP პოულობს მანქანას; პორტები კი — პროგრამას.

IP მისამართი შენობის მისამართივითაა; პორტი კი — ბინის ნომერი მასში. ერთად ისინი ერთ გაშვებულ პროგრამაზე მიგვითითებენ. ამის თავზე ირჩევთ ტრანსპორტს: TCP, როცა ყველა ბაიტი თანმიმდევრობით უნდა მივიდეს, და UDP, როცა სიჩქარე სისრულეს სჯობს.

IP მისამართი — მანქანის ციფრული მისამართი ქსელში. IPv4 ასე გამოიყურება: 93.184.216.34 (დაახლოებით 4.3 მილიარდი შესაძლო — ახლა უკვე მწირია, ამიტომ NAT-ით ვინაწილებთ). IPv6 ასეთია: 2606:2800:220:1::1 და პრაქტიკულად ულიმიტო ადგილი აქვს. პორტი არის რიცხვი 0-დან 65535-მდე, რომელიც ამბობს, მანქანაზე რომელმა პროგრამამ უნდა მიიღოს მონაცემები.
:80

HTTP — ჩვეულებრივი ვებ ტრაფიკი.

:443

HTTPS — დაშიფრული ვებ ტრაფიკი.

:53

DNS — სახელების ძებნა.

:22

SSH — დაშორებული შელი.

TCP — საიმედო სატელეფონო ზარი

სანამ მონაცემები წავა, TCP აკეთებს სამბიჯიან handshake-ს, რომ საუბარზე შეთანხმდნენ. შემდეგ თითოეულ ნაწილს ნომრავს, ელოდება დადასტურებებს, თავიდან აგზავნის დაკარგულს და ანელებს, როცა ქსელი გადატვირთულია — ასე თქვენი ბაიტები სრულად და თანმიმდევრობით მიდის.

  • SYN — კლიენტი: "შეიძლება ვისაუბროთ?"
  • SYN-ACK — სერვერი: "დიახ, გესმით ჩემი?"
  • ACK — კლიენტი: "დიახ — დავიწყოთ."
client server SYN SYN-ACK ACK · data flows

სამი შეტყობინება აწყობს კავშირს — ერთი სრული შემოვლა რეალური მონაცემების პირველ ბაიტამდე.

TCP — საიმედო, თანმიმდევრული
// Used by: web (HTTP), email, file transfer // + delivery guaranteed, in order, no dupes // + flow & congestion control built in - handshake + acks add latency & overhead // "Resend page 3 — it never arrived."
UDP — სწრაფი, მსუბუქი
// Used by: video calls, gaming, DNS, QUIC // + tiny overhead, no setup, no waiting // + you control retries (or skip them) - packets can drop, arrive late or out of order // "Lost a frame? Skip it — keep the call live."

ცერის წესი: აირჩიეთ TCP, როცა დაკარგული მონაცემი შედეგს აფუჭებს (ვებ გვერდი, საბანკო გადარიცხვა). აირჩიეთ UDP, როცა დაძველებული მონაცემი მაინც უსარგებლოა და ლოდინს წინსვლა გირჩევნიათ (ორი წამის წინანდელი ხმოვანი პაკეტი ვერავის უშველის).

03 · სახელები მისამართებად 5 წთ

DNS ინტერნეტის
სატელეფონო წიგნია.

თქვენ გახსოვთ example.com; მანქანები კი ციფრებით მიდიან, როგორიცაა 93.184.216.34. DNS არის სერვისი, რომელიც ერთს მეორედ თარგმნის — და რადგან ეს ძებნა ყოველი ახალი კავშირის წინ ხდება, აგრესიულად ქეშირდება, რომ ყველაზე ნელი ნაბიჯი არ გახდეს.

DNS — Domain Name System — ადამიანისთვის მოსახერხებელ სახელს (example.com) აქცევს IP მისამართად, რომელიც პაკეტს სჭირდება. წარმოიდგინეთ, რომ ტელეფონში კონტაქტი სახელით გაქვთ შენახული: აჭერთ "დედას" და ტელეფონი ნომერს კრეფს. DNS იმავე ძებნას აკეთებს ყოველი დომენისთვის, რომელსაც სტუმრობთ.

რეზოლვერი იერარქიას გადის: root → .com → დომენის საკუთარი სერვერი, შემდეგ კი მისამართს გაწვდით.

როგორ იხსნება ერთი ძებნა

  • თქვენი მანქანა ეკითხება რეკურსიულ რეზოლვერს (რომელსაც თქვენი ISP უშვებს ან საჯაროს, მაგალითად 1.1.1.1 / 8.8.8.8).
  • თუ პასუხი უკვე არ იცის, ეკითხება root სერვერებს, რომლებიც .com-ის (TLD) სერვერებზე მიუთითებენ, ისინი კი — დომენის ავტორიტეტულ სერვერზე.
  • ეს სერვერი აბრუნებს A ჩანაწერს (IPv4) ან AAAA ჩანაწერს (IPv6). რეზოლვერი ქეშავს მას და პასუხს გაძლევთ.

ჩანაწერები, რომლებსაც შეხვდებით — და რატომ არის ქეშირება მნიშვნელოვანი

A / AAAA

სახელი → IP

A სახელს IPv4 მისამართს უსადაგებს; AAAA კი — IPv6-ს. ძირითადი ძებნა.

CNAME

ფსევდონიმი

ერთ სახელს მეორეზე მიუთითებს (www → example.com). ერთი კანონიკური სამიზნე, ბევრი ფსევდონიმი.

MX

ფოსტის გზა

ამბობს, რომელი სერვერები იღებენ დომენის ელფოსტას. TXT თავისუფალ ტექსტს ინახავს (SPF, დომენის დადასტურება).

TTL

ქეშის სიცოცხლე

Time To Live, წამებში — რამდენ ხანს შეიძლება იყოს ჩანაწერი ქეშში, სანამ ხელახლა მოძებნა დასჭირდება.

რატომ ქეშირდება DNS ყველგან

  • ძებნა, რომელიც ყოველ ჯერზე მთელ იერარქიას გაივლიდა, შეყოვნებას დაამატებდა ყოველ პირველ მოთხოვნას. ქეშირება ჩვეულ შემთხვევას თითქმის ნულ შემოვლამდე ამცირებს.
  • შედეგები მრავალ შრეზე ქეშირდება — თქვენს ბრაუზერში, ოპერაციულ სისტემაში, რეზოლვერში — და თითოეული ჩანაწერის TTL-ს პატივს სცემს.
  • კომპრომისი: ჩანაწერის შეცვლის შემდეგ ძველი პასუხები შეიძლება TTL-ის ამოწურვამდე დარჩეს. დაგეგმილ მიგრაციამდე შეამცირეთ TTL, რომ ცვლილებები სწრაფად გავრცელდეს.
# ვკითხოთ საჯარო რეზოლვერს A ჩანაწერი dig example.com A +short 93.184.216.34 # +noall +answer ხედი TTL-საც აჩვენებს dig example.com example.com. 3600 IN A 93.184.216.34 # ^^^^ TTL: ქეშში 3600 წმ (1 სთ)
04 · დაშიფვრა და ნდობა 6 წთ

HTTPS უბრალოდ HTTP-ია
TLS გვირაბის შიგნით.

S სიტყვაში HTTPS არის TLS, რომელიც ერთდროულად სამ საქმეს აკეთებს: შიფრავს ტრაფიკს, რომ მოსმენისას მხოლოდ უაზრობა ჩანდეს, ამოწმებს მთლიანობას, რომ გზაში არაფერი შეცვლილიყო, და ადასტურებს, რომ ნამდვილად სწორ სერვერს ესაუბრებით და არა თაღლითს.

TLS — Transport Layer Security (SSL-ის თანამედროვე მემკვიდრე) — ჩვეულებრივ კავშირს დაშიფვრაში ახვევს. TLS 1.3 მიმდინარე ვერსიაა; ის უფრო სწრაფია და ძველ დაუცველ ვარიანტებს აგდებს. სერტიფიკატი დომენის ციფრული პირადობის მოწმობაა, ხელმოწერილი სანდო სასერტიფიკაციო ცენტრის (CA) მიერ — სწორედ ეს ხელმოწერა უშლის ხელს ვინმეს, საიტად მოგვევლინოს.
client server ClientHello ServerHello + cert verify · key exchange encrypted application data 🔒

TLS 1.3 დაცულ არხს ერთი შემოვლით აწყობს და შემდეგ ყოველი ბაიტი დაშიფრულია.

handshake ნაბიჯ-ნაბიჯ

  • ClientHello — "აი, რომელ შიფრებსა და ვერსიებს ვუჭერ მხარს, და აი შემთხვევითი რიცხვი."
  • ServerHello + სერტიფიკატი — სერვერი ირჩევს შიფრს და აგზავნის თავის სერტიფიკატს (ხელმოწერილ საჯარო გასაღებს).
  • შემოწმება — კლიენტი ამოწმებს, სერტიფიკატის ჯაჭვი მისთვის უკვე სანდო CA-მდე მიდის თუ არა. თუ არა, იღებთ იმ შემაშფოთებელ ბრაუზერის გაფრთხილებას.
  • გასაღების გაცვლა — ორივე მხარე გამოჰყავს საერთო საიდუმლო გასაღები (ECDHE-ით) და სწრაფ სიმეტრიულ დაშიფვრაზე გადადის.
კონფიდენციალობა

მოსმენა არ ხდება

ღია Wi-Fi-ზე პაკეტების ჩაჭერა ნებისმიერს შეუძლია. TLS-თან ერთად ისინი მხოლოდ შიფრტექსტს იჭერენ — გასაღების გარეშე უსარგებლოს.

მთლიანობა

ჩარევა არ ხდება

თითოეულ შეტყობინებას თან ახლავს ტეგი, ამიტომ გზაში ნებისმიერი ცვლილება (ჩაშენებული რეკლამა, შებრუნებული ბიტი) აღმოჩნდება და უარყოფილი იქნება.

ავთენტიფიკაცია

სწორი სერვერი

სერტიფიკატი ადასტურებს, რომ სერვერს დომენი ეკუთვნის — ასე პაროლს თაღლითს არ გადასცემთ.

საინტერესოა: handshake ნელ ასიმეტრიულ კრიპტოგრაფიას მხოლოდ იმდენ ხანს იყენებს, რამდენიც საერთო გასაღებზე შესათანხმებლად სჭირდება, შემდეგ კი ძირითადი მონაცემებისთვის სწრაფ სიმეტრიულ კრიპტოგრაფიაზე გადადის — ორივეს საუკეთესო მხარე. უფასო, ავტომატური სერტიფიკატები (მაგალითად Let's Encrypt) არის მიზეზი, რის გამოც HTTPS დღეს ვებში ნაგულისხმევია.

05 · რატომ დაჩქარდა ყოველი ვერსია 6 წთ

HTTP/1.1 → HTTP/2 → HTTP/3:
ლოდინის მოკვლა.

HTTP ვების ენაა — თავიდან ბოლომდე იგივე ზმნები (GET, POST). ვერსიებს შორის შეიცვალა ის, როგორ გადაიტანება ბაიტები, და ყოველმა ნაბიჯმა ლოდინის ერთი წყარო მოხსნა.

Head-of-line blocking — როცა ერთი გაჩერებული ერთეული უკან მდგომ ყველაფერს აყოვნებს — როგორც სალაროსთან ერთი რიგი, სადაც წინ მდგომს საფულე ვერ უპოვია და მთელი რიგი ელოდება. ყოველი HTTP-ის განახლება არსებითად ამ რიგის ერთი ვერსიის მოცილების მცდელობაა.
HTTP/1.1
ერთი TCP კავშირი
მოთხ. 1
მოთხ. 2
მოთხ. 3
ლოდინი…
სათითაოდ

ერთი მოთხოვნა სრულდება მეორის დაწყებამდე. ბრაუზერები ~6 კავშირს ხსნიდნენ პარალელურობის მისაბაძად.

HTTP/2
ერთი TCP კავშირი
ნაკადი 1
ნაკადი 2
ნაკადი 3
ყველა პარალელურად, გადაწნული
1 დაკარგული პაკეტი
მთელ TCP არხს აჩერებს

ბევრი ნაკადი ერთ კავშირს იზიარებს (მულტიპლექსირება) — მაგრამ TCP-ის დანაკარგი მაინც ყველას აჩერებს.

HTTP/3
QUIC UDP-ზე
TLS 1.3 ჩაშენებული
ნაკადი 1
ნაკადი 2 ✕
ნაკადი 3
დაკარგული პაკეტი აჩერებს
მხოლოდ თავის ნაკადს ✓
+ სწრაფი აწყობა, კავშირის მიგრაცია

ნაკადები დამოუკიდებელია, ამიტომ ერთი დანაკარგი დანარჩენებს ვერ ბლოკავს — აწყობა კი ერთი გაერთიანებული handshake-ია.

HTTP/1.1 — ტექსტი, ერთი მოთხოვნა კავშირზე

ადამიანისთვის წასაკითხი ტექსტური მოთხოვნები TCP კავშირზე, რომელიც ღია რჩება (keep-alive). მაგრამ ერთი კავშირი ერთ მოთხოვნას ამუშავებს, ამიტომ ნელი პასუხი რიგს ბლოკავს. შემოვლა იყო რამდენიმე კავშირის პარალელურად გახსნა — ფლანგვა, მაგრამ ორ ათწლეულს გაუძლო.

ძლიერი მხარე
მარტივი, უნივერსალური, ტრივიალურად დებაგირებადი — სიტყვასიტყვით ხელით აკრეფთ.
სატკივარი
სათითაოდ თითო კავშირზე; ჰედერების შეკუმშვა არ არის; შეყოვნებაზეა დამოკიდებული.

HTTP/2 — ბინარული ფრეიმინგი & მულტიპლექსირება

გადადის კომპაქტურ ბინარულ ფორმატზე და ბევრ მოთხოვნას ერთ კავშირზე გადაწნულ ნაკადებად ამულტიპლექსირებს, პლუს ჰედერების შეკუმშვა (HPACK). ხაფანგი: ყველაფერი მაინც ერთ TCP კავშირზე მიდის, ამიტომ ერთი დაკარგული პაკეტი ყველა ნაკადს აჩერებს — TCP-ის დონის head-of-line blocking.

ძლიერი მხარე
ერთი კავშირი, ბევრი პარალელური ნაკადი; უფრო მცირე ჰედერები; დიდი აჩქარება რეალურ პირობებში.
სატკივარი
TCP-ის დანაკარგი ყველა ნაკადს აჩერებს; server push უსარგებლო აღმოჩნდა და დღეს მოძველებულია.

HTTP/3 — HTTP QUIC-ზე, QUIC კი UDP-ზე

TCP-ს თმობს QUIC-ის სასარგებლოდ — ეს UDP-ზე აგებული ტრანსპორტია, რომელიც ნაკადებს დამოუკიდებლად ინახავს: დაკარგული პაკეტი მხოლოდ თავის ნაკადს აჩერებს. TLS 1.3 ჩაშენებულია, ამიტომ ტრანსპორტისა და დაშიფვრის handshake-ები ერთდება (ხშირად ერთ შემოვლაში) და კავშირს შეუძლია ქსელის შეცვლას გადაურჩეს (Wi-Fi → მობილური) ხელახლა დაკავშირების გარეშე.

ძლიერი მხარე
ტრანსპორტის დონეზე HOL ბლოკირება არ არის; უფრო სწრაფი აწყობა; შეუფერხებელი კავშირის მიგრაცია მობილურზე.
სატკივარი
UDP-ს ზოგჯერ უზღუდავენ ან ბლოკავენ; მეტი პროცესორი თითო პაკეტზე; უფრო ახალია, ამიტომ შემოწმება რთულია.
06 · შუაში მდგარი ყუთები 5 წთ

კლიენტსა და სერვერს შორის დგანან
დამხმარეები, რომლებიც მას მასშტაბირებასა და დაცვას უწევენ.

რეალურ სისტემებში იშვიათად ესაუბრება ერთი კლიენტი ერთ სერვერს. შუაში დგას რამდენიმე სტანდარტული შუამავალი — დატვირთვის ბალანსერი, რომ ტრაფიკი გაანაწილოს, პროქსები, რომ წინ ან უკან იდგნენ, და CDN, რომ კონტენტი მომხმარებელთან ახლოდან მიაწოდოს. იგივე სამშენებლო ბლოკები, სხვადასხვა საქმე.

ქეშირებული სტატიკური კონტენტი CDN-ის edge-იდან მიეწოდება; დანარჩენი ყველაფერი დატვირთვის ბალანსერამდე მიდის, რომელიც მას სერვერებზე ანაწილებს.

ვინ რას აკეთებს

  • დატვირთვის ბალანსერი — შემომავალ მოთხოვნებს ბევრ იდენტურ სერვერზე ანაწილებს (round-robin, least-connections) და წყვეტს იმაზე გაგზავნას, რომელიც health check-ს ვერ გადის.
  • Reverse proxy — ერთი შესასვლელი კარი თქვენი სერვერებისთვის: აგვარებს TLS-ს, ქეშირებას, მარშრუტიზაციას, სიხშირის ლიმიტებს. (Forward proxy კი კლიენტების წინ დგას.)
  • CDN — ქეშების გლობალური ქსელი მომხმარებლებთან ახლოს, რომ ტოკიოელმა ვიზიტორმა ტოკიოდან ჩატვირთოს და არა თქვენი ერთადერთი სერვერიდან ვირჯინიაში.
L4 vs L7 დატვირთვის ბალანსირება — L4 ბალანსერი მარშრუტს მხოლოდ IP-სა და პორტით ირჩევს (სწრაფია, პროტოკოლს ვერ ხედავს); L7 ბალანსერს HTTP ესმის, ამიტომ შეუძლია URL-ის ბილიკით, ჰოსტით ან ქუქით მარშრუტიზაცია — ოდნავ მეტ ფასად. შრეების ნომრები OSI-ის მოდელიდან მოდის, ნაწილი 01.

CDN / edge ვენდორები — აირჩიეთ შესაბამისობით

Cloudflare

მოცვა & უსაფრთხოება

  • დადებითი — უზარმაზარი ქსელი, გულუხვი უფასო ტარიფი, ინტეგრირებული DDoS/WAF და edge გამოთვლა (Workers).
  • უარყოფითი — თავისი აზრის მქონე პლატფორმა; ღრმა კონფიგურაციასა და edge რანტაიმს სწავლა სჭირდება.
Fastly

კონტროლი & მყისიერი purge

  • დადებითი — დაპროგრამებადი edge (VCL/Compute) და თითქმის მყისიერი ქეშის გასუფთავება; უყვართ ზუსტი კონტროლისთვის.
  • უარყოფითი — უფრო ძვირია და მეტ ხელით მუშაობას ითხოვს; უფასო ნაწილი მცირეა, დამწყებისთვის რთულია.
CloudFront

AWS-native

  • დადებითი — მჭიდრო ინტეგრაცია S3-სთან, ALB-სთან და დანარჩენ AWS-თან; ერთი ანგარიში, ერთი IAM.
  • უარყოფითი — კონფიგურაცია მრავალსიტყვიანია; საუკეთესო ღირებულებას მხოლოდ მაშინ იძლევა, თუ უკვე მთლიანად AWS-ზე ხართ.

როგორ ავირჩიო: უკვე AWS-ზე ხართ → CloudFront; გინდათ მაქსიმალური მზა უსაფრთხოება და უფასო დასაწყისი → Cloudflare; გჭირდებათ ქეშირების ზუსტი კონტროლი და მყისიერი გასუფთავება → Fastly.

07 · დებაგი და შეჯამება 4 წთ

როცა რამე ფუჭდება, იკითხეთ
რომელი შრე — და მერე აიღეთ ინსტრუმენტი.

შრეებად დაყოფილი მოდელი სწორედ აქ იხდის თავს: თითოეული ინსტრუმენტი კონკრეტულ შრეს ამოწმებს. იმუშავეთ ზემოდან ქვევით ან ქვევიდან ზემოთ, მაგრამ ჯერ შრე გამოყავით — ეს "საიტი არ მუშაობს"-ს ისეთ კითხვად აქცევს, რომელსაც რეალურად უპასუხებთ.

ქსელის ინსტრუმენტების ყუთი — რომელი როდის

dig / nslookup — სახელის პრობლემაა?

# სახელის ამოხსნა, პასუხი + TTL dig example.com A +short # კონკრეტულ რეზოლვერს ვეკითხებით (Cloudflare) dig @1.1.1.1 example.com # დელეგირების სრული ჯაჭვის ტრეისი dig example.com +trace

დაიწყეთ აქედან, როცა სახელი არ იხსნება ან ძველ ადგილას მიუთითებს. dig გაჩვენებთ ჩანაწერს, მის TTL-ს და რომელმა სერვერმა უპასუხა. nslookup უფრო მარტივი, კროსპლატფორმული ბიძაშვილია.

დადებითი
წამებში პოულობს DNS-ის პრობლემებსა და გავრცელების მდგომარეობას.
უარყოფითი
მხოლოდ სახელების შრე — არაფერს ამბობს იმაზე, სერვერი ჯანმრთელია თუ არა.

curl — HTTP/TLS შრე ჯანმრთელია?

# ჰედერები + სტატუსი, გადამისამართებით curl -sIL https://example.com # დრო + გამოყენებული პროტოკოლი curl -s -o /dev/null -w "%{http_version} %{time_total}s\n" \ https://example.com # TLS handshake-ის დათვალიერება curl -v https://example.com 2>&1 | grep -i TLS

აპლიკაციის შრის სამუშაო ცხენი: სტატუს-კოდები, ჰედერები, გადამისამართებები, TLS-ის დეტალები, თვით შეთანხმებული HTTP-ის ვერსიაც. თუ dig წესრიგშია, გვერდი კი — არა, შემდეგი გაჩერება curl-ია.

დადებითი
ხედავს სტატუსს, ჰედერებს, TLS-სა და დროს — ყველგან სკრიპტდება.
უარყოფითი
ამოწმებს ერთ მოთხოვნას; დატვირთვის ან მარშრუტის ინსტრუმენტი არაა.

traceroute / mtr — გზის რომელ მონაკვეთზე კვდება?

# ყველა ნახტომი ჰოსტამდე traceroute example.com # mtr = traceroute + ping, ცოცხლად და უწყვეტად mtr example.com # უყურეთ % დანაკარგის სვეტს თითო ნახტომზე

ხაზავს პაკეტების მარშრუტს და აჩვენებს, სად ჩნდება შეყოვნება ან დანაკარგი. mtr traceroute-ს მუდმივ ping-თან აერთიანებს, ასე რომ არასტაბილურ ნახტომს დროთა განმავლობაში დაინახავთ — იდეალურია "ზოგჯერ ნელია"-სთვის.

დადებითი
შეყოვნებასა და დანაკარგს კონკრეტულ ნახტომზე ან ქსელზე ალოკალიზებს.
უარყოფითი
ბევრი როუტერი ამ პრობებს პრიორიტეტს უკლებს, ამიტომ საშიშად გამოყურებული ნახტომი ცრუ კვალიც შეიძლება იყოს.

tcpdump / Wireshark — მაჩვენე რეალური პაკეტები

# 443-ე პორტის ტრაფიკის ჩაწერა ფაილში sudo tcpdump -i any port 443 -w cap.pcap # შემდეგ გახსენით cap.pcap Wireshark-ში # რომ handshake პაკეტ-პაკეტ შეამოწმოთ

ყველაზე ღრმა ხედი: ჩაწერეთ ნედლი პაკეტები და წაიკითხეთ. tcpdump მათ ბრძანების ხაზზე იჭერს; Wireshark კი მდიდარ ინტერფეისს გაძლევთ handshake-ების, ხელახალი გაგზავნებისა და reset-ების გასაშლელად. უკანასკნელი საშუალება, როცა უფრო მაღალი დონის ინსტრუმენტები ვერ ხსნიან.

დადებითი
უტყუარი სიმართლე — პაკეტების დონეზე არაფერი იმალება.
უარყოფითი
მრავალსიტყვიანია და მარტივი პრობლემებისთვის ზედმეტი; დაშიფრული დატვირთვა გასაღებების გარეშე გაუმჭვირვალე რჩება.

ტრიაჟი ზემოდან ქვევით

  • 1 · სახელი? dig — დომენი იმ IP-ზე იხსნება, რომელსაც ელოდებით?
  • 2 · მიწვდომადია? traceroute/mtr — პაკეტები ჰოსტამდე აღწევს და სად ჩერდება?
  • 3 · აპლიკაცია/TLS? curl -v — სწორი სტატუსი, ჰედერები, სერტიფიკატი, HTTP-ის ვერსია?
  • 4 · მაინც ჩიხშია? tcpdump + Wireshark — წაიკითხეთ თავად პაკეტები.
1იფიქრეთ შრეებით. Link → Internet → Transport → Application. ყველა პრობლემა ერთ-ერთ მათგანზე ცხოვრობს.
2IP პოულობს მანქანას, პორტი კი — პროგრამას. TCP — საიმედო & თანმიმდევრული; UDP — სწრაფი & დანაკარგებიანი.
3DNS ქეშირებული სატელეფონო წიგნია. სახელები → IP-ები, TTL კი წყვეტს, რამდენ ხანს დარჩება პასუხი.
4HTTPS = HTTP TLS-ის გვირაბში — კონფიდენციალობა, მთლიანობა, ავთენტიფიკაცია ერთ handshake-ში.
5HTTP-ის ყოველმა ვერსიამ ერთი რიგი მოკლა; შუაში მდგარი ყუთები (LB, პროქსი, CDN) origin-ს მასშტაბირებასა და დაცვას უწევენ.
ცოდნის შემოწმება

დაგამახსოვრდათ?

ხუთი სწრაფი კითხვა შრეებზე, ტრანსპორტზე, DNS-ზე, TLS-სა და HTTP-ის ვერსიებზე — მყისიერი პასუხი, შესვლის გარეშე.

შეაფასეთ ეს დასტა
იყავით პირველი

ნავიგაცია ← → ღილაკებით ან სქროლით · უკან ბიბლიოთეკაში