După cunoașterea mișcării fizice a biților în mediu și rutarea datagramelor pe Internet, este timpul să luăm în considerare serviciile pentru aplicații legate de transferul de date. Să începem cu User Datagram Protocol (UDP). Acesta este un protocol destul de simplu, care permite aplicațiilor să schimbe mesaje individuale.
Fig. 9.1. Întrebarea și răspunsul DNS
Încărcările pentru deschiderea și închiderea conexiunilor la trimiterea de volume mari de mesaje pot fi excluse prin trimiterea de simple întrebări și răspunsuri. În plus, UDP servește ca o bază excelentă pentru proiectarea instrumentelor de monitorizare, depanare, întreținere sau testare.
UDP este un serviciu principal care transmite mesaje simple, la un singur IP, pentru transmiterea ulterioară pe rețea. Deoarece IP nu oferă un transfer de încredere, nu există nici o garanție de livrare a mesajului. Dacă o aplicație încearcă să înainteze cererile sale către datagrame UDP, dar nu primește răspunsuri într-un interval de timp rezonabil, aplicația trebuie să retrimită datele.
Uneori, acest lucru duce la solicitări duplicate pe server. Dacă aplicația include un mesaj de identificare a tranzacției, serverul va putea recunoaște duplicarea și va exclude o copie suplimentară a mesajului. Pentru aceste acțiuni, aplicația în sine este responsabilă, nu UDP.
Ce se întâmplă după ce datele sosesc la gazda destinației? Cum se livrează la cererea corectă (proces)?
În Fig. 9.2 că pentru fiecare nivel există un identificator de protocol care să indice operațiile efectuate asupra datelor. La al doilea nivel, tipul Ethernet X'08-00 din antetul cadrului indică faptul că cadrul trebuie transferat la IP. La al treilea nivel, câmpul de protocol din antetul IP specifică protocolul de nivel patru, unde trebuie trimise date (de exemplu, 6 pentru TCP sau 17 pentru UDP).
Fig. 9.2. Redirecționarea datelor către stratul aplicației
O gazdă poate participa simultan în mai multe comunicări. Deci, cum afectează datagrama UDP firul general și trebuie livrat stratului de aplicație dorit? Acest proces de transfer de date către procesul dorit este deseori numit demultiplexare. Răspunsul este că fiecărui punct final UDP i se atribuie un identificator pe 16 biți denumit un număr de port. Termenul "port" nu are un mare succes pentru acest identificator. Portul pentru părțile client și server ale aplicației nu are nimic de-a face cu porturile hardware și calea fizică a transferului de date).
Porturile cu numere de la 0 la 1023 sunt rezervate serviciilor standard. Astfel de porturi sunt numite bine-cunoscute. Utilizarea acestora permite clientului să identifice serviciul la care dorește să acceseze. De exemplu, accesul la DNS (care se bazează pe UDP) se face printr-un port bine-cunoscut 53.
Cine numește porturi bine-cunoscute? Deoarece nu este greu de ghicit, IANA este implicată în acest lucru. Numerele porturilor pentru aplicații specifice sunt înregistrate de această organizație și publicate în documentul Numere RFC atribuite. Lista abreviată a porturilor UDP din documentul curent privind numerele atribuite RFC este prezentată în tabelul 9.1.
Tabelul 9.1 Exemple de porturi UDP cunoscute
Folosit pentru a raporta probleme de rețea
Câteva servicii binecunoscute oferă module pentru testare, depanare și măsurare. De exemplu, ecoul (echo) cu portul 7, corespunzător numelui său, returnează orice datagram trimis la acest port. Serviciul Resping al portului 9, dimpotrivă, șterge orice datagrama trimisă la acest port din rețea. Generatorul de caractere răspunde la orice mesaj cu o datagramă care conține între 0 și 512 octeți. Numărul de octeți este ales aleator.
citat Serviciul zilei (citat din zi) este responsabil pentru orice datagramă un anumit mesaj, de exemplu, în unele sisteme, programul afișează avere la înregistrarea „înțelept“ sfaturi (în acest exemplu arată fraza lui Winston Churchill: „O persoană poate poticni accidental pe adevăr, dar cele mai multe din cazuri, nu observă și continuă să caute mai departe. "):
Comentariul lui Churchill despre om:
Omul se va poticni ocazional peste adevăr, dar majoritatea
el se va ridica.
Serviciul de zi răspunde la orice datagramă cu un mesaj care conține data și ora curente în format ASCII. Un astfel de format poate fi citit pe ecran fără transformări suplimentare. În caz contrar, serviciul Network Time Protocol (NTP) se comportă, oferind o metodă sigură pentru sincronizarea calculatoarelor de rețea.
Știm deja că serverul de nume este accesibil prin portul 53 și comanda nslookup. Porturile 161 și 162 sunt utilizate de protocolul de administrare a rețelei simple.
În plus față de numerele atribuite oficial, orice sistem cu TCP / IP poate rezerva o serie de numere pentru servicii și aplicații importante de rețea.
Restul numerelor de port (peste 1023) sunt furnizate clienților din software-ul gazdă după cum este necesar. Selecția include următorii pași:
1. Utilizatorul pornește programul client (de exemplu, nslookup).
2. Procesul client execută o rutină de sistem care are sens: "Vreau să efectuez comunicarea UDP. Dă-mi un port".
3. Rutina sistemului selectează un port nefolosit din grupul de porturi disponibile și îl oferă clientului.
Puteți vedea că TCP identifică de asemenea sursa și destinația cu identificatorul de port pe 16 biți. De exemplu, portul 21 este utilizat pentru a accesa serviciul de transfer de fișiere. și portul 23 pentru serviciul de înregistrare telnet.
Numerele TCP și UDP sunt independente una de cealaltă. Un proces poate trimite mesaje de la UDP numărul portului 1700, în timp ce cealaltă continuă să sesiune TCP pe portul 1700. Există mai multe servicii disponibile atât prin TCP, UDP și prin intermediul. În acest caz, IANA prevede atribuirea aceluiași număr de port pentru serviciile UDP și TCP. Cu toate acestea, obiectivele de comunicare rămân în locuri diferite.
Conexiuni active la Internet (inclusiv servere)
Proto Adresa Recv-Q Adresă locală Adresă locală (stat)
Tcp 0 0 127.0.0.1.1340 127.0.0.1.111 TIME_WAIT
Tcp 0 0 128.121.50.145.25 128.252.223.5.1526 SYN_RCVD
Tcp 0 0 128.121.50.145.25 148.7.9.160.65.3368 ESTABLISHED
Tcp 0 438 128.121.50.145.23 130.132.57.246.2219 ESTABLISHED
Tcp 0 0 128.121.50.145.25 192.5.5.1.4022 TIME_WAIT
Tcp 0 0 128.121.50.145.25 141.218.1.100.3968 TIME_WAIT
Tcp 0 0 128.121.50.145.25 35.8.2.2.3722 TIME_WAIT
Tcp 0 0 128.121.50.145.1338 165.247.48.4.25 ESTABLISHAT
Tcp 0 0 128.121.50.145.25 128.173.4.8.3626 ESTABLISHED
Tcp 0 0 128.121.50.145.25 192.48.96.14.3270 ESTABLISHED
Ce mecanism este necesar pentru a rula User Datagram Protocol? Mai întâi, UDP trebuie să primească un identificator de protocol unic (17). Această valoare va fi plasată în câmpul Protocol IP cu numele Protocol în toate mesajele UDP trimise. Mesajele primite cu o valoare de 17 în câmpul de protocol IP sunt livrate către UDP. Protocolul UDP generează mesajul prin adăugarea unui antet simplu la datele din aplicație. Acest antet specifică numerele de port sursă și de destinație.
În Fig. 9.3 arată formatul antetului UDP. Antetul conține numere de porturi de sursă și destinație pe 16 biți care definesc punctele finale de comunicare. Câmpul de lungime specifică numărul total de octeți din antet și parte pentru datele mesajului UDP. Câmpul de verificare vă permite să verificați corectitudinea conținutului mesajului.
Fig. 9.3. Antetul UDP
Rețineți că antetul IP conține o sumă de control pentru a verifica corectitudinea câmpurilor sale. Scopul sumelor de control UDP este de a verifica conținutul mesajului UDP.
În UDP, suma de control este calculată ca o combinație a unui pseudo antet special creat (pseudo header) care conține câteva informații IP, un antet UDP și date din mesaj.
Fig. 9.4. Câmpuri Pseudo-header pentru suma de control UDP
Utilizarea unei sume de control în comunicare nu este obligatorie. Când nu este utilizat, câmpul are o valoare de zero. Dacă suma de control a fost calculată și egală cu zero, o astfel de valoare este reprezentată de o secvență de astfel de valori.
În plus față de trimiterea și recepționarea datagramelor, UDP ar trebui să fie ghidată de bunul simț atunci când trimite datele în jos de la aplicație la IP și furnizează o indicație a erorilor de la IP la aplicație.
Fig. 9.5 conține ieșirea combinată a părților IP și UDP ale cererii și răspunsurile lor corespunzătoare. Acest rezultat a fost obținut în monitorul rețelei locale Sniffer de la Network General. Cererea conținea o cerere de ieșire a informațiilor despre stare și a fost trimisă de gazdă către stația de gestionare a rețelei. O parte din datele din mesajul de solicitare și de răspuns nu sunt listate.
Fig. 9.5. Antete IP și UDP pentru solicitare și răspuns
În ambele anteturi, câmpul IP al protocolului este 17, ceea ce indică utilizarea protocolului UDP. Suma de control UDP nu este calculată pentru cerere, dar este prezentă în răspuns.
Analizorul Sniffer recunoaște că portul 161 este atribuit serviciului de rețea.
Atunci când o aplicație primește un port UDP, software-ul de protocol de rețea își rezervă mai multe tampoane pentru a stoca coada de datagramuri utilizator care sosesc la acel port. Serviciile bazate pe UDP nu pot prezice numărul de datagrame care sosesc simultan și le pot gestiona.
Dacă mai multe datagrame vin la serviciu decât se poate ocupa, atunci mesajele suplimentare sunt pur și simplu eliminate. Acest fapt poate fi detectat utilizând secțiunea Overflow Socket UDP din raportul statisticii de rețea. De exemplu, următorul raport este generat de comanda netstat:
0 anteturi incomplete
0 câmpuri lungi de date
0 controale necorespunzătoare
17 preaplinuri de soclu
Protocolul User Datagram este definit în RFC 768. RFC 862 la 865 discută serviciile UDP, ecoul, aruncarea, generarea de caractere și citația zilei. RFC 867 descrie timpul de folosință al zilei. un RFC 1119 reprezintă a doua versiune a serviciului de timp al rețelei. Protocolul BOOTP este discutat în Capitolul 11, iar în următoarele capitole vor fi menționate servicii suplimentare UDP.
Articole similare
-
Material didactic pe tema sondajului copilului, descărcare gratuită, socială
-
Capitolul 1 Sunteți un câine de tranzacționare, citiți online, fără înregistrare
Trimiteți-le prietenilor: