Vietnes sadaļas
Redaktora izvēle:
- Kas ir SSD un kā to instalēt?
- Kā programmā Word likt uzsvaru uz burta
- Kā pārvērst attēlus PNG formātā?
- Tehniskas problēmas un to risinājumi v
- Bioshock remastered nesāksies
- Kā iestatīt melodiju vajadzīgajam kontaktam viedtālrunī Nokia X2 ar divām SIM kartēm
- Bezmaksas programmas Windows lejupielādēt bez maksas
- Kā ierakstīt jebkuru ISO attēlu USB zibatmiņas diskā
- Zvani no nezināmiem numuriem
- Es aizmirsu sava Google konta paroli un, piesakoties, saņemu ziņojumu, ka ievadījāt nepareizu paroli.
Reklāma
| Uz kāda protokola darbojas udp? Kā vienkāršā izteiksmē TCP atšķiras no UDP? |
|
UDP ir vienkāršs protokols, un tam ir noteikta darbības joma. Pirmkārt, tās ir klienta un servera mijiedarbība un multivide. Tomēr lielākajai daļai interneta lietojumprogrammu ir nepieciešama uzticama, konsekventa pārraide. UDP neatbilst šīm prasībām, tāpēc ir nepieciešams cits protokols. Šo protokolu sauc par TCP, un tas ir interneta darba zirgs. TCP pamati Pārraides kontroles protokols (TCP) tika īpaši izstrādāts, lai nodrošinātu uzticamu baitu straumi no gala līdz galam neuzticamā interneta tīklā. Savstarpēji savienots tīkls atšķiras no atsevišķa tīkla ar to, ka tā dažādām sadaļām var būt ļoti atšķirīgas topoloģijas, joslas platumi, latentuma vērtības, pakešu izmēri un citi parametri. TCP izstrāde koncentrējās uz protokola spēju pielāgoties tīkla īpašībām un būt noturīgam, saskaroties ar dažādām problēmām. TCP protokols ir aprakstīts RFC 793. Laika gaitā ir atklātas dažādas kļūdas un neprecizitātes, un dažos aspektos prasības ir mainītas. Detalizēts šo precizējumu un labojumu apraksts ir sniegts RFC 1122. Protokola paplašinājumi ir sniegti RFC 1323. Katrai mašīnai, kas atbalsta TCP protokolu, ir TCP transporta entītija, kas ir vai nu bibliotēkas procedūra, lietotāja process vai sistēmas kodola daļa. Jebkurā gadījumā transporta entītija pārvalda TCP plūsmas un saskarni ar IP slāni. TCP entītija saņem lietotāju datu plūsmas no lokālajiem procesiem, sadala tās gabalos, kas nav lielāki par 64 KB (praksē šis skaitlis parasti ir 460 baiti datu, kas ļauj tos ievietot vienā Ethernet kadrā ar IP un TCP galvenēm), un nosūta tos kā atsevišķas IP datagrammas. Kad iekārtā nonāk IP datu diagrammas, kas satur TCP datus, tās tiek nodotas TCP entītijai, kas rekonstruē sākotnējo baitu straumi. Vienkāršības labad mēs dažreiz izmantosim "TCP", lai atsauktos uz TCP transporta entītiju (programmatūras daļu) vai TCP protokolu (noteikumu kopu). No konteksta būs skaidrs, kas ir domāts. Piemēram, izteicienā “Lietotājs pārsūta TCP datus” ir dabiski norādīta transporta entītija TCP. IP slānis negarantē pareizu datagrammu piegādi, tāpēc TCP ir jāuzrauga noildzes, kurām beidzies derīguma termiņš, un, ja nepieciešams, atkārtoti jāpārsūta paketes. Dažreiz datagrammas nonāk nepareizā secībā. TCP ir atbildīgs arī par ziņojumu atkopšanu no šādām datagrammām. Tādējādi TCP ir izstrādāts, lai nodrošinātu tādu uzticamību, kādu vēlas daudzi lietotāji un ko nenodrošina IP. TCP pakalpojuma modelis TCP pakalpojums ir balstīts uz tā sauktajām ligzdām (ligzdām vai galapunktiem), ko izveidojis gan sūtītājs, gan saņēmējs. Tie tika apspriesti Berkeley Sockets sadaļā. Katrai ligzdai ir numurs (adrese), kas sastāv no resursdatora IP adreses un resursdatoram lokāla 16 bitu numura, ko sauc par portu. TCP portu sauc par TSAP adresi. Lai piekļūtu TCP pakalpojumam, ir skaidri jāizveido savienojums starp sūtīšanas iekārtas ligzdu un saņēmēja iekārtas ligzdu. Vienu kontaktligzdu var izmantot vairākiem savienojumiem vienlaikus. Citiem vārdiem sakot, divi vai vairāki savienojumi var beigties vienā kontaktligzdā. Savienojumus atšķir ar ligzdas ID abos galos - (ligzda1, ligzda2). Virtuālo kanālu numuri vai citi identifikatori netiek izmantoti. Portu numurus, kas ir mazāki par 1024, ko sauc par populārajiem portiem, rezervē standarta pakalpojumi. Piemēram, jebkurš process, kas vēlas izveidot savienojumu ar resursdatoru, lai pārsūtītu failu, izmantojot FTP, var sazināties ar mērķa resursdatora 21. portu un tādējādi sazināties ar tā FTP dēmonu. Populāro ostu saraksts ir pieejams vietnē www.iana.org. Mēs, protams, varētu saistīt FTP dēmonu ar 21. portu sāknēšanas laikā, pēc tam saistīt telnet dēmonu ar 23. portu utt. Tomēr, ja mēs to darītu, mēs tikai tērētu atmiņu ar informāciju par dēmoniem, kas patiesībā , tie lielākoties ir dīkstāvē. Tā vietā parasti tiek izmantots viens dēmons, ko sauc par inetd UNIX, kas sazinās ar vairākiem portiem un gaida pirmo ienākošo savienojumu. Kad tas notiek, inetd izveido jaunu procesu un izsauc atbilstošo dēmonu, lai apstrādātu pieprasījumu. Līdz ar to pastāvīgi darbojas tikai inetd, pārējie tiek izsaukti tikai tad, kad tiem ir darbs. Inetd ir īpašs konfigurācijas fails, no kura tas var uzzināt par portu piešķiršanu. Tas nozīmē, ka sistēmas administrators var konfigurēt sistēmu tā, lai pastāvīgie dēmoni tiktu saistīti ar noslogotākajiem portiem (piemēram, 80), bet inetd – ar pārējiem.
Visi TCP savienojumi ir pilni dupleksi un no punkta uz punktu. Pilna dupleksa nozīmē, ka satiksme vienlaikus var plūst pretējos virzienos. Savienojums no punkta uz punktu nozīmē, ka tam ir divi galapunkti. TCP neatbalsta apraidi un multiraidi. TCP savienojums ir baitu straume, nevis ziņojumu straume. Robežas starp ziņojumiem netiek saglabātas. Piemēram, ja nosūtīšanas process TCP straumē ieraksta četrus 512 baitu datu gabalus, šie dati var tikt piegādāti saņemšanas procesam kā četri 512 baitu gabali, divi 1024 baitu gabali, viens 2048 baitu fragments vai kaut kas cits. cits. Saņēmējs nevar noteikt, kā dati tika rakstīti. Šis īpašums ir arī failiem UNIX sistēmā. Programma, kas nolasa sliedi, nevar noteikt, kā šis fails tika uzrakstīts: pa blokiem, baitiem vai pilnībā uzreiz. Tāpat kā UNIX sistēmas failos, arī TCP programmām nav ne jausmas, ne par ko nerūp baitu nozīme. Viņiem baits ir tikai baits. Kad TCP saņem datus no lietojumprogrammas, tas var nosūtīt tos visus uzreiz vai buferizēt, lai vienlaikus nosūtītu lielāku datu daļu, kā tas izvēlas. Tomēr dažreiz lietojumprogrammai ir nepieciešams nekavējoties nosūtīt datus. Pieņemsim, piemēram, ka lietotājs piesakās attālā mašīnā. Pēc tam, kad viņš ir ievadījis komandu un nospiedis taustiņu Enter, ir svarīgi, lai viņa ievadītā rinda nekavējoties tiktu piegādāta attālajai mašīnai, nevis buferizēta līdz nākamās rindas ievadīšanai. Lai piespiestu datus pārsūtīt bez kavēšanās, lietojumprogramma var iestatīt karogu PUSH. Dažas vecākas lietojumprogrammas izmantoja PUSH karogu kā ziņojumu norobežotāju. Lai gan šis triks dažreiz darbojas, ne visas TCP ieviešanas nodod PUSH karogu saņēmējai lietojumprogrammai. Turklāt, ja TCP entītija saņem vēl vairākas šādas paketes, pirms līnijā tiek nosūtīta pirmā PUSH pakete (tas ir, izvadlīnija ir aizņemta), TCP entītijai būs tiesības nosūtīt visus šos datus kā vienu datu diagrammu, nesadalot tos atsevišķās daļās. Pēdējā pieminēšanas vērta TCP pakalpojuma funkcija ir steidzami dati. Kad lietotājs, kas mijiedarbojas ar programmu, interaktīvi nospiež taustiņu Dzēst vai Ctrl-C, lai pārtrauktu attālo procesu, kas notiek, sūtīšanas lietojumprogramma ievieto vadības informāciju izvades datu straumē un nodod to TCP pakalpojumam kopā ar karodziņu STEIDZAMS. Šis karodziņš liek TCP entītijai pārtraukt datu uzkrāšanu un nekavējoties atbrīvot visu, kas tai ir, lai izveidotu savienojumu ar tīklu. Kad steidzami dati nonāk galamērķī, saņemošā lietojumprogramma tiek pārtraukta (tas ir, UNIX terminoloģijā tiek "signalizēta"), pēc tam tā var nolasīt datus no ievades straumes un meklēt starp tiem steidzamus datus. Steidzamo datu beigas ir atzīmētas, lai lietojumprogramma varētu atpazīt, kur tie beidzas. Steidzamo datu sākums nav atzīmēts. Lietojumprogrammai tas jāizdomā pašai. Šī shēma nodrošina neapstrādātu signalizācijas mehānismu, atstājot visu pārējo lietojumprogrammas ziņā. TCP protokols Šajā sadaļā TCP protokols tiks apspriests vispārīgi. Nākamajā sadaļā mēs apspriedīsim protokola galveni katrā laukā. Galvenā TCP īpašība, kas nosaka visu protokola struktūru, ir tāda, ka TCP savienojumā katram baitam ir savs 32 bitu kārtas numurs. Interneta pirmajos gados pamata datu pārraides ātrums starp maršrutētājiem pa nomātajām līnijām bija 56 Kbps. Lai saimniekdators nepārtraukti izsūknē datus ar maksimālo ātrumu, paietu vairāk nekā nedēļa, lai kārtas numuri sasniegtu pilnu apli. Pie pašreizējā ātruma kārtas numuri var ļoti ātri beigties, par to vairāk vēlāk. Apstiprinājumiem un bīdāmā loga mehānismam tiek izmantoti atsevišķi 32 bitu kārtas numuri, kas arī tiks apspriesti vēlāk. Sūtošās un saņēmējas TCP entītijas apmainās ar datiem segmentu veidā. Segments sastāv no fiksētas 20 baitu galvenes (kā arī izvēles daļas), kurai var sekot datu baiti. Segmentu lielumu nosaka TCP programmatūra. Tas var apvienot datus, kas iegūti vairāku rakstīšanas darbību rezultātā, vienā segmentā vai, gluži pretēji, sadalīt vienas ierakstīšanas rezultātu pa vairākiem segmentiem. Segmentu lielumu ierobežo divi ierobežojumi. Pirmkārt, katram segmentam, ieskaitot TCP galveni, ir jāiekļaujas IP paketes 65 515 baitu kravnesības laukā. Otrkārt, katram tīklam ir maksimālā pārsūtīšanas vienība (MTU), un katram segmentam ir jāiekļaujas MTU. Praksē maksimālās pārraides vienības izmērs parasti ir 1500 baiti (kas atbilst Ethernet slodzes lauka lielumam), un tādējādi nosaka segmenta izmēra augšējo robežu. Galvenais TCP entītiju izmantotais protokols ir bīdāmo logu protokols. Pārraidot segmentu, sūtītājs iedarbina taimeri. Kad segments nonāk galamērķī, saņēmēja TCP entītija nosūta atpakaļ segmentu (ar datiem, ja ir ko nosūtīt, vai bez datiem) ar numuru. apstiprinājums ir vienāds ar nākamā paredzamā segmenta kārtas numuru. Ja apstiprinājuma taimauts beidzas, sūtītājs atkārtoti nosūta segmentu. Lai gan šis protokols šķiet vienkāršs, ir vairākas detaļas, kas jāizpēta sīkāk. Segmenti var nonākt nepareizā secībā. Tā, piemēram, iespējams, ka baiti no 3072 līdz 4095 jau ir saņemti, taču par tiem nevar nosūtīt apstiprinājumu, jo baiti no 2048 līdz 3071 vēl nav saņemti. Turklāt segmenti tīklā var uzkavēties tik ilgi, ka sūtītājs beidzas noildze un pārsūta tos vēlreiz. Atkārtoti pārraidītais segments var ietvert dažādus fragmentu diapazonus, tāpēc būs nepieciešama ļoti rūpīga administrēšana, lai noteiktu jau pareizi saņemto baitu numurus. Tomēr, tā kā katrs straumes baits ir unikāli identificēts pēc tā nobīdes, šis uzdevums ir izpildāms. TCP jāspēj risināt šīs problēmas un tās efektīvi atrisināt. Daudz pūļu ir veltīts TCP straumju veiktspējas optimizēšanai. Nākamajā sadaļā mēs apspriedīsim vairākus algoritmus, kas tiek izmantoti dažādās TCP protokola implementācijās. TCP segmenta galvene Katrs segments sākas ar 20 baitu fiksēta formāta galveni. Tam var sekot papildu lauki. Pēc papildu laukiem var būt līdz 65 535 - 20 - 20 = 65 495 baiti datu, kur pirmie 20 baiti ir IP galvene un otrie ir TCP galvene. Segmenti nedrīkst saturēt datus. Šādus segmentus bieži izmanto, lai nosūtītu apstiprinājumus un kontroles ziņojumus. Apskatīsim TCP galvenes laukus pēc lauka. Lauki Uztvērēja ports un Avota ports ir lokālā savienojuma galapunktu identifikatori. Porta numurs kopā ar resursdatora IP adresi veido unikālu 48 bitu galapunkta identifikatoru. Šādu identifikatoru pāris, kas saistīti ar avotu un galamērķi, unikāli identificē savienojumu. Lauki Secības numurs un Apstiprinājuma numurs veic savas parastās funkcijas. Ņemiet vērā, ka lauks Apstiprinājuma numurs attiecas uz nākamo gaidāmo baitu, nevis uz pēdējo saņemto baitu. Abi ir 32 biti, jo katrs datu baits TCP straumē ir numurēts. Laukā TCP Header Length ir norādīts TCP galvenes lielums, kas izteikts 32 bitu vārdos. Šī informācija ir nepieciešama, jo laukam Neobligātie lauki un līdz ar to arī visa galvene var būt dažāda garuma. Būtībā šis lauks norāda nobīdi no segmenta sākuma līdz datu laukam, ko mēra 32 bitu vārdos. Tas ir tāds pats kā nosaukuma garums.
Tālāk nāk neizmantots 6 bitu lauks. Tas, ka šī joma ir saglabājusies ceturtdaļgadsimtu, liecina par to, cik pārdomāts ir TCP dizains. Tam seko seši 1 bita karodziņi. URG bits ir iestatīts uz 1, ja tiek izmantots lauks Steidzami datu rādītājs, kurā ir baita nobīde no pašreizējā baita kārtas numura līdz steidzamo datu atrašanās vietai. Šādi TCP ievieš pārtraukuma ziņojumus. Kā jau minēts, TCP protokols nodrošina tikai lietotāja signāla piegādi adresātam, neinteresējoties par pārtraukuma cēloni. Ja ACK bits ir iestatīts uz 1, laukā Apstiprinājuma numurs ir nozīmīgi dati. Pretējā gadījumā šajā segmentā nav apstiprinājuma, un lauks Apstiprinājuma numurs tiek vienkārši ignorēts. PSH bits būtībā ir PUSH karodziņš, kas liek sūtītājam likt uztvērējam piegādāt datus lietojumprogrammai, tiklīdz tas saņem paketi, nevis uzglabāt to buferī, līdz tā ir pilna. (Lai palielinātu efektivitāti, saņēmējs var veikt buferi.) RST bits tiek izmantots, lai atiestatītu savienojuma stāvokli, kas resursdatora kļūmes vai cita iemesla dēļ ir nonācis strupceļā. To izmanto arī, lai noraidītu nederīgu segmentu vai mēģinājumu izveidot savienojumu. Ja saņemat segmentu ar iestatītu RST bitu, ir radusies problēma. SYN bits tiek izmantots, lai izveidotu savienojumu. Savienojuma pieprasījumam ir SYN bits = 1 un ACK bits = 0, kas nozīmē, ka apstiprinājuma lauks netiek izmantots. Atbilde uz šo pieprasījumu satur apstiprinājumu, tāpēc šo bitu vērtības ir: SYN= 1, ACK-1. Tādējādi SYN bits tiek izmantots, lai norādītu segmentus CONNECTION REQUEST un CONNECTION ACCEPTED, un tiek izmantots ACK bits. lai tos atšķirtu vienu no otra. FIN bits tiek izmantots savienojuma pārtraukšanai. Tas norāda, ka sūtītājam nav vairāk datu, ko pārsūtīt. Tomēr pat pēc savienojuma pārtraukšanas process var turpināties datu saņemšanai bezgalīgi. Segmentiem ar FIN un SYN bitiem ir kārtas numuri, lai nodrošinātu, ka tie tiek izpildīti pareizā secībā. Plūsmas kontrole TCP protokolā tiek veikta, izmantojot mainīga izmēra bīdāmo logu. Laukā Window Size ir norādīts, cik baitu var nosūtīt pēc apstiprinājuma baita. Lauka Window Size vērtība var būt nulle, kas nozīmē, ka ir saņemti visi baiti līdz apstiprinājuma numuram-1, taču adresātam pašlaik ir problēmas un viņš vēl nevar saņemt atlikušos baitus. Atļauju turpmākai pārsūtīšanai var iegūt, nosūtot segmentu ar tādu pašu Apstiprinājuma numura lauka vērtību un loga lieluma lauka vērtību, kas nav nulle. Dažos protokolos kadru apstiprinājumi ir saistīti ar atļaujām turpināt pārraidi. Šīs attiecības izriet no stingri fiksētā bīdāmā loga izmēra šajos protokolos. Izmantojot TCP, apstiprinājumi tiek atdalīti no atļaujām pārsūtīt datus. Būtībā uztvērējs varētu teikt: "Es esmu saņēmis baitus līdz k-ro, bet es nevēlos turpināt saņemt datus šobrīd." Šis sadalījums (izteikts kā mainīga izmēra bīdāms logs) nodrošina protokolam papildu elastību. Tālāk mēs apspriedīsim šo aspektu sīkāk. Kontrolsummas lauks tiek izmantots, lai palielinātu uzticamību. Tajā ir galvenes, datu un pseidogalvenes kontrolsumma. Veicot aprēķinus, lauks Kontrolsumma tiek iestatīts uz nulli, un datu lauks tiek papildināts ar nulles baitu, ja tā garums ir nepāra skaitlis. Kontrolsummas algoritms vienkārši pievieno visus 16 bitu vārdus divu komplementā un pēc tam aprēķina visas summas papildinājumu. Rezultātā, kad adresāts pārbauda visu segmentu, ieskaitot lauku Kontrolsumma, rezultātam jābūt 0.
Pseidogalvene satur 32 bitu avota un galamērķa IP adreses, TCP protokola numuru (6) un baitu skaitu TCP segmentam (ieskaitot galveni). Pseidogalvenes iekļaušana TCP kontrolsummā palīdz atklāt nepareizi piegādātas paketes, lai gan tā pārkāpj protokola hierarhiju, jo tajā esošās IP adreses pieder IP slānim, nevis TCP slānim. UDP kontrolsummai izmanto to pašu pseidogalveni. Lauks Neobligātie lauki nodrošina papildu iespējas, kas nav ietvertas standarta galvenē. Izmantojot vienu no šiem laukiem, katrs resursdators var norādīt maksimālo lietderīgās slodzes lauka lielumu, ko tas var pieņemt. Jo lielāks ir izmantoto segmentu izmērs, jo lielāka ir efektivitāte, jo tas samazina 20 baitu galvenes, taču ne visi resursdatori var pieņemt ļoti lielus segmentus. Savienojuma iestatīšanas laikā saimniekdatori var sazināties viens ar otru par maksimālo kravnesības lauka lielumu. Pēc noklusējuma šis izmērs ir 536 baiti. Visiem saimniekdatoriem ir jāpieņem TCP segmenti, kuru izmērs ir 536 + 20 = 556 baiti. Katram virzienam var būt savs maksimālais kravnesības lauka izmērs. Līnijām ar lielu pārsūtīšanas ātrumu un/vai lielu latentumu 64 KB logs ir pārāk mazs. Tādējādi TZ līnijai (44,736 Mbit/s) pilnu logu var pārsūtīt uz līniju tikai 12 ms laikā. Ja brauciena laiks turp un atpakaļ ir 50 ms (parasti transkontinentālajam optiskajam kabelim), 3/4 laika sūtītājs pavada, gaidot apstiprinājumu. Sazinoties caur satelītu, situācija būs vēl sliktāka. Lielāks loga izmērs uzlabotu efektivitāti, bet 16 bitu loga lieluma lauks to neļauj. RFC 1323 piedāvāja jaunu Window Scale parametru, par kura vērtību divi resursdatori varētu vienoties, izveidojot savienojumu. Šis skaitlis ļauj pārvietot loga lieluma lauku līdz 14 bitiem pa kreisi, ļaujot loga izmēram paplašināties līdz 230 baitiem (1 GB). Pašlaik lielākā daļa TCP protokolu ieviešanas atbalsta šo funkciju. Vēl viena iespēja, kas piedāvāta RFC 1106 un tagad tiek plaši izmantota, ir izmantot selektīvo atkārtotā mēģinājuma protokolu, nevis atkāpties. atkārtoti pārsūtīt visus neapstiprinātos segmentus, tostarp tos, kas tika saņemti pareizi. RFC 1106 ierosināja izmantot negatīvus apstiprinājumus (NAK), lai adresāts varētu pieprasīt vienu segmentu vai vairākus segmentus. Pēc saņemšanas saņēmēja puse var apstiprināt visus buferī saglabātos datus, tādējādi samazinot atkārtoti pārsūtīto datu apjomu. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Bits | 0 - 7 | 8 - 15 | 16 - 23 | 24 - 31 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | Avota adrese | |||||||||||||||||||||||||||||||
| 32 | ||||||||||||||||||||||||||||||||
| 64 | ||||||||||||||||||||||||||||||||
| 96 | ||||||||||||||||||||||||||||||||
| 128 | Saņēmēja adrese | |||||||||||||||||||||||||||||||
| 160 | ||||||||||||||||||||||||||||||||
| 192 | ||||||||||||||||||||||||||||||||
| 224 | ||||||||||||||||||||||||||||||||
| 256 | UDP garums | |||||||||||||||||||||||||||||||
| 288 | Nulles | Nākamais virsraksts | ||||||||||||||||||||||||||||||
| 320 | Avota ports | Galamērķa osta | ||||||||||||||||||||||||||||||
| 352 | Garums | Pārbaudes summa | ||||||||||||||||||||||||||||||
| 384+ | Dati |
|||||||||||||||||||||||||||||||
Avota adrese ir tāda pati kā IPv6 galvenē. Saņēmēja adrese - gala saņēmējs; ja IPv6 pakete nesatur maršrutēšanas galvenes, tad tā būs galamērķa adrese no IPv6 galvenes, pretējā gadījumā sākuma mezglā tā būs maršrutēšanas galvenes pēdējā elementa adrese un saņēmēja mezglā, galamērķa adrese no IPv6 galvenes. Nākamās galvenes vērtība ir vienāda ar protokola vērtību — 17 UDP. UDP garums - UDP galvenes un datu garums.
Uzticamība un risinājumi pārslodzes problēmām
Tā kā UDP lietojumprogrammas nav uzticamas, tām jābūt gatavām dažiem zaudējumiem, kļūdām un dublēšanās gadījumiem. Daži no tiem (piemēram, TFTP) pēc izvēles var pievienot elementārus uzticamības mehānismus lietojumprogrammu līmenī.
Bet visbiežāk šādus mehānismus UDP lietojumprogrammas neizmanto un pat traucē tiem. Multivides straumēšana, reāllaika vairāku spēlētāju spēles un VoIP ir to lietojumprogrammu piemēri, kurās bieži tiek izmantots UDP protokols. Šajās konkrētajās lietojumprogrammās pakešu zudums parasti nav liela problēma. Ja lietojumprogrammai ir nepieciešams augsts uzticamības līmenis, varat izmantot citu protokolu (TCP) vai izmantot kļūdām izturīgas kodēšanas metodes (dzēšanas kodu). ru lv).
Nopietnāka iespējamā problēma ir tā, ka atšķirībā no TCP uz UDP balstītām lietojumprogrammām ne vienmēr ir labi pārslodzes kontroles un novēršanas mehānismi. Uz sastrēgumiem jutīgas UDP lietojumprogrammas, kas patērē ievērojamu daļu pieejamā joslas platuma, var apdraudēt interneta stabilitāti.
Tīkla mehānismi tika izstrādāti, lai samazinātu iespējamo sastrēgumu ietekmi nekontrolētas, liela ātruma slodzes laikā. Tīkla elementi, piemēram, maršrutētāji, kas izmanto pakešu rindas un nomešanas metodes, bieži vien ir vienīgie pieejamie rīki, lai palēninātu pārmērīgu UDP trafiku. DCCP (Datagram Congestion Control Protocol) ir izstrādāts kā daļējs šīs iespējamās problēmas risinājums, pievienojot gala resursdatoram mehānismus, lai uzraudzītu ātrdarbīgu UDP straumju, piemēram, straumēšanas multivides, pārslodzes.
Lietojumprogrammas
Daudzas galvenās interneta lietojumprogrammas izmanto UDP, tostarp DNS (kur pieprasījumiem jābūt ātriem un jāsastāv tikai no viena pieprasījuma, kam seko viena atbildes pakete), vienkāršais tīkla pārvaldības protokols (SNMP), maršrutēšanas informācijas protokols (RIP), dinamiskā resursdatora konfigurācija (DHCP) .
Balss un video trafiku parasti veic, izmantojot UDP. Tiešraides video un audio straumēšanas protokoli ir izstrādāti, lai apstrādātu nejaušus pakešu zudumus, lai kvalitāte būtu tikai nedaudz pasliktināta, nevis piedzīvotu lielu aizkavi, kad zaudētās paketes tiek atkārtoti pārsūtītas. Tā kā gan TCP, gan UDP darbojas vienā tīklā, daudzi uzņēmumi ir pamanījuši, ka nesenais UDP trafika pieaugums no šīm reāllaika lietojumprogrammām kavē TCP lietojumprogrammu, piemēram, datu bāzu vai grāmatvedības sistēmu, veiktspēju. Tā kā uzņēmumiem ir svarīgas gan biznesa, gan reāllaika lietojumprogrammas, daži uzskata, ka kvalitatīvu problēmu risinājumu izstrāde ir galvenā prioritāte.
UDP un TCP salīdzinājums
TCP ir uz savienojumu orientēts protokols, kas nozīmē, ka ir nepieciešams "rokasspiediens", lai izveidotu savienojumu starp diviem resursdatoriem. Kad savienojums ir izveidots, lietotāji var sūtīt datus abos virzienos.
- Uzticamība- TCP pārvalda ziņojumu apstiprināšanu, atkārtotu pārsūtīšanu un taimautu. Tiek veikti daudzi mēģinājumi nosūtīt ziņojumu. Ja tas tiek pazaudēts ceļā, serveris vēlreiz pieprasīs pazaudēto daļu. Izmantojot TCP, netrūkst datu vai (vairāku taimautu gadījumā) nav bojātu savienojumu.
- Kārtība- ja secīgi tiek nosūtīti divi ziņojumi, pirmā ziņa vispirms nonāks adresāta programmā. Ja datu gabali tiek saņemti nepareizā secībā, TCP nosūta ārpuskārtas datus uz buferi, līdz visus datus var pasūtīt un nosūtīt uz lietojumprogrammu.
- Smagums- TCP nepieciešamas trīs paketes, lai pirms datu nosūtīšanas izveidotu ligzdas savienojumu. TCP uzrauga uzticamību un pārslodzes.
- Vītņošana- dati tiek nolasīti kā baitu plūsma, netiek pārsūtīti īpaši apzīmējumi ziņojuma robežām vai segmentiem.
UDP ir vienkāršāks, uz ziņojumiem balstīts bezsavienojumu protokols. Šāda veida protokoli neizveido īpašu savienojumu starp diviem resursdatoriem. Komunikācija tiek panākta, pārraidot informāciju vienā virzienā no avota uz saņēmēju, nepārbaudot saņēmēja gatavību vai stāvokli. Lietojumprogrammās Voice over IP (TCP/IP) UDP ir priekšrocības salīdzinājumā ar TCP, kur jebkurš rokasspiediens var novērst labu balss saziņu. Izmantojot VoIP, galalietotājiem ir jāsniedz visi nepieciešamie ziņojuma saņemšanas apstiprinājumi reāllaikā.
- Neuzticams- kad tiek nosūtīta ziņa, nav zināms, vai tā sasniegs galamērķi - tā var pazust pa ceļam. Nav tādu jēdzienu kā apstiprināšana, atkārtota pārraide, taimauts.
- Traucējumi- ja vienam adresātam tiek nosūtīti divi ziņojumi, tad secību, kādā tie sasniedz mērķi, nevar paredzēt.
- Vieglums- nav ziņojumu pasūtīšanas, nav savienojuma izsekošanas utt. Tas ir mazs transporta slānis, kas izstrādāts IP.
- Datagrammas- paketes tiek nosūtītas atsevišķi un tiek pārbaudītas tikai tad, ja tās pienāk. Paketēm ir noteiktas robežas, kuras tiek ievērotas pēc saņemšanas, tas nozīmē, ka lasīšanas darbība saņemšanas ligzdā ģenerēs ziņojumu tādu, kāds tas sākotnēji tika nosūtīts.
- Nav pārslodzes kontroles- Pats UDP neizvairās no sastrēgumiem. Liela joslas platuma lietojumprogrammas var izraisīt sastrēgumu sabrukumu, ja vien tās neievieš lietojumprogrammas līmeņa vadīklas.
UDP (User Datagram Protocol) ir transporta protokols datu pārraidei bez savienojuma, izmantojot IP tīklus. Tas ir viens no vienkāršākajiem OSI modeļa transporta slāņa protokoliem. Tā IP ID ir 0x11.
UDP parasti izmanto tādās lietojumprogrammās kā video straumēšana un datorspēles, kur pakešu zudums ir pieņemams un atkārtots mēģinājums ir sarežģīts vai nepamatots, vai izaicinājumu atbildes lietojumprogrammās (piemēram, DNS vaicājumos), kur savienojuma izveide aizņem vairāk resursu nekā atkārtota sūtīšana. Faktiski UDP funkcijas ir saistītas ar multipleksēšanu un demultipleksēšanu, kā arī vienkāršu kļūdu pārbaudi datos. Tādējādi, izmantojot U DP, lietojumprogramma gandrīz tieši sazinās ar IP tīkla slāņa protokolu.
UDP saņem ziņojumus no lietojumprogrammas slāņa, pievieno avota un mērķa porta laukus demultipleksēšanai, ko veic uztvērējs, kā arī divus citus īpašus laukus un nodod iegūto segmentu tīkla slānim. Tīkla slānis iesaiņo segmentu datagrammā un, ja iespējams, pārsūta to galamērķa resursdatoram. Ja pēdējais veiksmīgi saņem segmentu, UDP pārsūta segmenta datus vajadzīgajam procesam, izmantojot mērķa porta numura lauku. Tāpēc tiek teikts, ka UDP nodrošina datu pārraidi bez savienojuma.
Lietojumprogrammas slāņa protokola piemērs, kas izmanto UDP protokola pakalpojumus, ir DNS. Kad DNS lietojumprogramma ģenerē vaicājumu, tā izveido DNS ziņojumu un nosūta to UDP protokolam.
UDP un TCP protokolu salīdzinājums.
Ja lietojumprogrammai ir nepieciešams apstiprinājums par ziņojuma piegādi, tā izmanto protokolu TCP. TCP sadala ziņojumu mazākos gabalos, ko sauc par segmentiem. Šie segmenti tiek secīgi numurēti un nodoti IP protokolam, kas pēc tam apkopo paketes. TCP seko segmentu skaitam, ko konkrēta lietojumprogramma nosūtījusi konkrētam resursdatoram. Ja sūtītājs noteiktā laika periodā nesaņem apstiprinājumu, TCP šos segmentus uzskata par bāreņiem un nosūta tos atkārtoti. Atkārtoti tiek nosūtīta tikai zaudētā ziņojuma daļa, nevis viss ziņojums.
Saņēmēja mezgla TCP protokols ir atbildīgs par ziņojumu segmentu atkārtotu salikšanu un pārsūtīšanu uz attiecīgo lietojumprogrammu.
FTP un HTTP ir piemēri lietojumprogrammām, kas izmanto TCP datu piegādei.
Protokols UDP veic negarantētu datu piegādi un neprasa apstiprinājumu no saņēmēja. UDP ir vēlamais protokols audio, video un balss straumēšanai, izmantojot interneta protokolu (VoIP). Piegādes apstiprināšana tikai palēninās datu pārsūtīšanas procesu, un atkārtota piegāde nav ieteicama. UDP protokola izmantošanas piemērs ir interneta radio.
ARP protokols. Pieteikums.
ARP(Angļu) Adrešu izšķiršanas protokols- adreses noteikšanas protokols) ir datortīklos izmantots zema līmeņa protokols, kas paredzēts, lai noteiktu saites slāņa adresi no zināmas tīkla slāņa adreses. Šis protokols ir kļuvis visizplatītākais, pateicoties visuresošajiem IP tīkliem, kas izveidoti uz Ethernet, jo gandrīz 100% gadījumu ar šo kombināciju tiek izmantots ARP. Protokola apraksts tika publicēts 1982. gada novembrī RFC 826. ARP bija paredzēts IP pakešu pārsūtīšanai pa Ethernet segmentu. Tajā pašā laikā ARP ierosinātais vispārējais princips, iespējams, tika izmantots cita veida tīkliem.
Pastāv šādi ARP ziņojumu veidi: ARP pieprasījums un ARP atbilde. Nosūtošā sistēma izmanto ARP pieprasījumu, lai pieprasītu saņēmējas sistēmas fizisko adresi. Atbilde (mērķa resursdatora fiziskā adrese) tiek sniegta ARP atbildes veidā.
Pirms tīkla slāņa paketes nosūtīšanas pa Ethernet segmentu tīkla steks pārbauda ARP kešatmiņu, lai noskaidrotu, vai tajā jau ir reģistrēta nepieciešamā informācija par mērķa resursdatoru. Ja ARP kešatmiņā šāda ieraksta nav, tiek veikts ARP apraides pieprasījums. Šim vaicājumam par ierīcēm tīklā ir šāda nozīme: "Vai kāds zina tās ierīces fizisko adresi, kurai ir šāda IP adrese?" Kad saņēmējs ar šo IP adresi saņems šo paketi, viņam būs jāatbild: “Jā, šī ir mana IP adrese. Mana fiziskā adrese ir:…” Pēc tam sūtītājs atjauninās savu ARP kešatmiņu un varēs pārsūtīt informāciju adresātam.
ARP kešatmiņas ieraksti var būt statiski vai dinamiski. Iepriekš sniegtajā piemērā ir aprakstīts dinamiskās kešatmiņas ieraksts. Varat arī izveidot statiskus ierakstus ARP tabulā.
ARP sākotnēji tika izstrādāts ne tikai IP protokolam, bet tagad to galvenokārt izmanto IP un MAC adrešu kartēšanai.
Darbības princips
Mezgls, kuram IP adrese jāsakārto ar vietējo adresi, ģenerē ARP pieprasījumu, ievieto to saites slāņa protokola rāmī, norādot tajā zināmo IP adresi, un pārraida pieprasījumu.
Visi vietējā tīkla resursdatori saņem ARP pieprasījumu un salīdzina tur norādīto IP adresi ar savu.
Ja tie sakrīt, mezgls ģenerē ARP atbildi, kurā norāda savu IP adresi un vietējo adresi un nosūta to jau virzītu, jo ARP pieprasījumā sūtītājs norāda savu vietējo adresi.
Man ļoti patīk visa rakstu sērija, turklāt vienmēr gribēju izmēģināt sevi kā tulkotāju. Varbūt pieredzējušiem izstrādātājiem raksts šķitīs pārāk pašsaprotams, bet man šķiet, ka tas jebkurā gadījumā noderēs.
Labdien, mani sauc Glens Fīdlers, un es sveicu jūs pirmajā rakstā manā tiešsaistes grāmatā Tīkla programmēšana spēļu izstrādātājiem.
Šajā rakstā mēs sāksim ar tīkla programmēšanas elementārākajiem aspektiem – datu saņemšanu un pārsūtīšanu tīklā. Datu saņemšana un pārsūtīšana ir visvienkāršākā un vienkāršākā daļa no visa tīkla programmētāju veicamo uzdevumu klāsta, taču bieži vien ir grūti noteikt, kā rīkoties vislabāk. Pievērsiet šai daļai pietiekami daudz uzmanības – ja jums radīsies pārpratums, tas vēlāk var radīt briesmīgas sekas jūsu vairāku spēlētāju spēlei!
Visticamāk, jūs jau esat kaut ko dzirdējis par ligzdām un, iespējams, zināt, ka tām ir divi galvenie veidi - TCP un UDP. Pirmā lieta, kas jums jāizlemj, izstrādājot vairāku spēlētāju spēli, ir tas, kāda veida ligzdas izmantot - TCP, UDP vai abus?
Kontaktligzdas veida izvēle ir pilnībā atkarīga no jūsu izstrādātās spēles žanra. Šajā rakstu sērijā pieņemu, ka tu raksti asa sižeta spēli – piemēram, Halo, Battlefield 1942, Quake, Unreal, CounterStrike, Team Fortress utt.
Tagad mēs sīkāk aplūkosim katra ligzdas veida īpašības (ņemot vērā to, ka mēs izstrādājam darbības stila spēli), un iedziļināsimies interneta darbības detaļās. Pēc detalizētas pārskatīšanas pareizā iespēja kļūs acīmredzama!
TCP apzīmē "pārraides kontroles protokols" un IP apzīmē "interneta protokols". Kopā tie ir pamatā gandrīz visam, ko darāt tiešsaistē, sākot no tīmekļa pārlūkošanas līdz IRC un e-pasta saziņai — tas viss darbojas, izmantojot TCP/IP.
Ja kādreiz esat izmantojis TCP ligzdas, tad jums jāzina, ka TCP ir protokols, kas izmanto uzticama savienojuma principu. Tas nozīmē, ka jūs izveidojat savienojumu starp diviem datoriem un pēc tam nosūtāt datus starp tiem tāpat, it kā jūs rakstītu informāciju failā vienā datorā un lasītu to no tā paša faila citā.
Šajā gadījumā savienojums tiek uzskatīts par uzticamu un konsekventu - tas ir, visa jūsu nosūtītā informācija tiek garantēta, ka tā sasniegs adresātu tādā pašā secībā, kādā tā tika nosūtīta. Tāpat TCP savienojumu var uzskatīt par nepārtrauktu datu plūsmu – pats protokols rūpējas par datu sadalīšanu paketēs un nosūtīšanu pa tīklu.
Vēlreiz - viss ir tikpat vienkārši kā parasta rakstīšana vai lasīšana no faila. Elementārais Vatsons!
Bet šī lietošanas vienkāršība ir pilnīgi atšķirīga no tā, kas patiesībā notiek "zem pārsega", zemākā līmenī - IP protokola līmenī.
Šajā līmenī nav savienojuma jēdziena - tā vietā atsevišķas paketes tiek pārsūtītas no viena datora uz otru. Šo procesu var uzskatīt par notis nodošanu no vienas personas otrai cilvēku pilnā telpā: beigās notis nonāk pie īstā cilvēka, bet tajā pašā laikā iziet cauri daudzām rokām.
Tomēr nav garantijas, ka piezīme sasniegs adresātu. Sūtītājs vienkārši nosūta zīmīti, cerot, ka tā atnāks, bet pat nezina, vai ziņa ir pienākusi vai nē – līdz adresāts nolemj atrakstīt.
Protams, patiesībā viss ir nedaudz sarežģītāk, jo sūtītājs nezina precīzu tīkla datoru secību, caur kuru pakete ir jāpārsūta, lai tā nonāktu pēc iespējas ātrāk. Dažreiz IP pārraida vairākas vienas un tās pašas paketes kopijas, kuras var izmantot dažādus ceļus, lai sasniegtu galamērķi, un, visticamāk, tās nonāks dažādos laikos.
Ko darīt, ja mēs vēlamies pārsūtīt informāciju starp datoriem nevis faila lasīšanas/rakstīšanas stilā, bet gan tieši nosūtot un saņemot atsevišķas paketes?
Mēs to varam izdarīt, izmantojot UDP. UDP apzīmē “lietotāja datagrammas protokols”, un tas darbojas virs IP (piemēram, TCP), taču tā vietā, lai pievienotu daudz funkcionalitātes, tas ir tikai neliels IP papildinājums.
Izmantojot UDP, mēs varam nosūtīt paketi uz noteiktu IP adresi (piemēram, 112.140.20.10) un portu (piemēram, 52423), un tā tiks pārsūtīta no datora uz datoru, līdz tā sasniegs galamērķi (vai pazudīs). veids).
Tajā pašā laikā uztvērēja pusē mēs vienkārši sēžam un gaidām, klausāmies noteiktu portu (mūsu gadījumā 52423), un, kad no kāda pienāk pakete (atcerieties, ka netiek izmantoti savienojumi), mēs par to saņemam paziņojumu ar sūtītāja datora adrese un ports, paketes lielums, un pēc tam mēs varam nolasīt datus no šīs paketes.
UDP protokols negarantē datu piegādi. Praksē lielākā daļa pakešu, protams, pienāk, taču vienmēr ir aptuveni 1-5% zudums, un dažreiz ir laika periodi, kad paketes vispār nepienāk (atcerieties, ka starp sūtītāju un saņēmēju var rasties tūkstošiem datoru, no kuriem jebkurā tas var neizdoties vai sabojāt).
Tāpat UDP negarantē pakešu piegādes secību. Jūs varat nosūtīt piecas paketes secībā - 1, 2, 3, 4, 5 -, taču tās var nonākt pavisam citā secībā - piemēram, 3, 1, 2, 5, 4. Atkal, praksē tās, visticamāk, tiks lielāko daļu laika ierodas pareizā secībā, taču uz to nevar paļauties!
Visbeidzot, lai gan UDP neko daudz nepievieno IP, tas garantē vienu lietu. Ja pārsūtīsiet paketi, tā tiks vai nu pilnībā, vai arī netiks saņemta vispār. Tātad, ja nosūtāt 256 baitu paketi uz citu datoru, tad tas nevar saņemt tikai pirmos 100 baitus no paketes – tam jāsaņem visi 256 baiti. Tas tiešām ir vienīgais, ko UDP protokols garantē – viss pārējais gulstas uz jūsu pleciem.
Tātad mums ir jāizlemj - vai mums vajadzētu izmantot TCP vai UDP ligzdas? Apskatīsim to īpašības:
- Izmanto savienojuma principu
- Garantē piegādi un apgriešanu
- Automātiski sadala informāciju paketēs
- Nodrošina, lai dati netiktu nosūtīti pārāk intensīvi (datu plūsmas kontrole)
- Viegli lietojams - piemēram, rakstīšana/lasīšana no faila
- Neizmanto savienojuma principu - jums tas būs jāīsteno manuāli
- Negarantē paku piegādi un piegādes kārtību - tās var ierasties nepareizā secībā, ar dublikātiem vai arī nepienākt vispār!
- Dati ir manuāli jāsadala paketēs un jānosūta
- Jāuzmanās, lai nenosūtītu datus pārāk intensīvi
- Ja pakete ir pazaudēta, jums tā kaut kā jāizseko un, ja nepieciešams, jānosūta atkārtoti
Bet nē.
TCP izmantošana, iespējams, ir vissliktākā kļūda, ko varat pieļaut, izstrādājot vairāku spēlētāju spēli. Lai saprastu, kāpēc, apskatīsim, kas padara TCP tik vienkāršu lietošanu!
Kā darbojas TCP
TCP un UDP darbojas papildus IP, taču patiesībā tie ir pilnīgi atšķirīgi. UDP darbojas ļoti līdzīgi kā IP, savukārt TCP abstrahē lietotāju no visām pakešu problēmām, padarot mijiedarbību līdzīgu faila lasīšanai/rakstīšanai.Tātad, kā viņš to dara?
Pirmkārt, TCP izmanto datu straumes abstrakciju — jūs varat vienkārši ierakstīt datu baitus šajā straumē, un TCP nodrošinās, ka tie nonāk galamērķī. Tā kā IP pārraida datus paketēs un TCP darbojas virs IP, TCP ir jāsadala lietotāja ievades straume atsevišķās paketēs. Tātad TCP iekšienē kāda loģika savāc datus rindā, un, kad to ir pietiekami daudz, tā veido paketi un nosūta to galamērķim.
Šāda rīcība varētu būt problēma mūsu vairāku spēlētāju spēlei, ja mums ir jāpārsūta ļoti mazas paketes. Var gadīties, ka TCP nolemj nepārsūtīt mūsu datus, kamēr tie nav uzkrājuši pietiekami daudz, lai izveidotu noteikta izmēra (teiksim, vairāk nekā simts baitu) paketi. Un tā ir liela problēma, jo ir nepieciešams pēc iespējas ātrāk pārsūtīt datus no klienta (spēlētāja taustiņsitienus) uz serveri, un ja ir aizkave datu buferizācijas dēļ ar protokolu, tad atskaņotājam klienta pusē spēle nebūs pati patīkamākā. Šajā gadījumā spēļu objektu atjaunināšana notiks ar kavēšanos un reti - turpretim objekti ir jāatjaunina laikā un bieži.
TCP ir iespēja to labot - “TCP_NODELAY”. Tas norāda protokolam, lai tas negaidītu, kamēr dati uzkrājas sūtīšanas rindā, bet gan nekavējoties jānosūta.
Diemžēl pat tad, ja šī opcija ir instalēta, TCP, izmantojot tiešsaistes spēlēs, ir daudz problēmu.
Visu problēmu cēlonis ir veids, kā TCP apstrādā pazaudētas vai nepareizas paketes, radot ilūziju par uzticamu un konsekventu savienojumu.
Kā TCP nodrošina savienojuma uzticamību
Pārsūtot, TCP sadala datu straumi atsevišķās paketēs, pārsūta tās tīklā, izmantojot neuzticamu IP protokolu, un pēc tam uztver sākotnējo straumi no saņemtajām paketēm rekonstruē saņemošā datorā.Bet kas notiek, ja kāda no paciņām nepienāk? Vai arī, ja pakas pienāk ne kārtībā, vai ar dublikātiem?
Pārāk neiedziļinoties detaļās par to, kā darbojas TCP (un šī tiešām ir ļoti sarežģīta tēma – to var izlasīt TCP/IP Illustrated), process izskatās šādi: TCP nosūta paketi, nosaka, ka pakete nav atnākusi. , un atkārtoti nosūta to pašu paketi adresātam. Pakešu dublikāti tiek likvidēti saņēmēja pusē, un pakas, kas pienāk ne kārtībā, tiek pārkārtotas, lai viss būtu kā nākas – uzticami un kārtībā.
Problēma ir tāda, ka tad, kad TCP šādā veidā “sinhronizē” datu straumi, ja pakete tiek pazaudēta, pārraide apstājas, līdz pazaudētā pakete tiek atkārtoti nosūtīta (un galamērķis to saņem). Ja gaidīšanas laikā pienāk jauni dati, tie tiks ierindoti rindā un tos nevarēs nolasīt, kamēr nebūs ieradusies pazaudētā pakete. Cik ilgs laiks nepieciešams, lai atkārtoti nosūtītu paku? Tas aizņem vismaz paketes aprites laiku (kad TCP nosaka, kuru paketi atkārtoti nosūtīt), kā arī laiku, lai atkārtoti piegādātu pazaudēto paketi. Tātad, ja ping starp datoriem ir 125 ms, paketes atkārtota nosūtīšana aizņems apmēram piektdaļu sekundes un sliktākajā gadījumā līdz pussekundei (iedomājieties, ja arī atkārtoti nosūtītā pakete pēkšņi pazūd). Veselukha!
Kāpēc nekad nevajadzētu izmantot TCP vairāku spēlētāju spēlēm
TCP izmantošanas problēma tiešsaistes spēlēs ir tāda, ka atšķirībā no pārlūkprogrammām, e-pasta un citām lietojumprogrammām spēles ir atkarīgas no reāllaika mijiedarbības. Daudziem spēles aspektiem, piemēram, lietotāja taustiņsitieniem un spēlētāju pozīcijai spēlē, nav nozīmes tam, kas notika pirms sekundes, bet gan spēles pasaules jaunākajam stāvoklim.Apskatīsim vienkāršu vairāku spēlētāju spēles piemēru, piemēram, 3D šāvēja. Spēles tīkla daļa ir veidota ļoti vienkārši: katra spēles cikla iterācija, klients nosūta serverim visu spēlētāja darbību aprakstu (nospiesti taustiņi, peles pozīcija utt.), un katrā iterācijā serveris apstrādā šos datus. , atjaunina spēļu pasaules modeli un nosūta atpakaļ pašreizējos uz pasaules objektu klientu pozīcijām, lai tas spēlētājam izveidotu jaunu rāmi.
Tātad mūsu spēlē, ja pakete tiek pazaudēta, pārraidot tīklu, spēle apstājas un gaida, līdz pakete tiek piegādāta atkārtoti. Klienta pusē spēļu objekti sasalst, un serverī spēlētāji arī nevar pārvietoties vai šaut, jo serveris nevar pieņemt jaunas paketes. Kad beidzot pienāk pazaudētā pakete, tajā ir novecojusi informācija, kas vairs nav aktuāla. Turklāt pēc tam pienāk arī visas tās paketes, kas uzkrājušās rindā gaidīšanas laikā, un tās visas ir jāapstrādā vienā cilpas iterācijā. Pilnīgs apjukums!
Diemžēl šo TCP uzvedību nevar mainīt, un tas arī nav nepieciešams, jo tā ir TCP nozīme. Tas ir nepieciešams, lai datu pārraidi internetā padarītu par uzticamu un konsekventu datu plūsmu.
Taču mums nav vajadzīga uzticama un konsekventa datu plūsma.
Mums ir nepieciešami dati, lai tie pēc iespējas ātrāk nonāktu no klienta uz serveri, un mēs nevēlamies gaidīt, kad dati tiks nosūtīti atkārtoti.
Tāpēc nekad nevajadzētu izmantot TCP vairāku spēlētāju spēlēm.
Bet pagaidi! Kāpēc es nevaru izmantot gan UDP, gan TCP kopā?
Reāllaika spēļu datiem, piemēram, lietotāju klikšķiem un spēļu pasaules stāvoklim, ir svarīgi tikai jaunākie dati, bet cita veida datiem, piemēram, komandu kopām, kas tiek sūtītas no viena datora uz otru, kanāla uzticamība un konsekvence. var būt ļoti svarīgi.
Protams, ir vilinoši izmantot UDP lietotāja ievadei un pasaules stāvokļa datiem, un TCP datiem, kuru piegādei ir jāgarantē. Iespējams, jūs pat domājat, ka varētu izveidot vairākus komandu “pavedienus”, piemēram, vienu ielādes līmeņiem, otru AI komandām. Jūs domājat: "Man nav vajadzīgas AI komandas, kas gaida rindā, ja datu pakete, lai ielādētu līmeni, pazūd, jo tās ir pilnīgi nesaistītas!" Šajā gadījumā jums ir taisnība, un jūs varat izlemt izveidot TCP ligzdu katrai komandu straumei.
No pirmā acu uzmetiena šī ir lieliska ideja. Bet problēma ir tā, ka, tā kā TCP un UDP darbojas virs IP, abu protokolu paketes ietekmēs viena otru - jau IP līmenī. Kā tieši šis efekts izpaudīsies, ir ļoti sarežģīts jautājums, un tas ir saistīts ar TCP uzticamības mehānismiem. Bet jebkurā gadījumā ņemiet vērā, ka TCP izmantošana parasti palielina UDP pakešu zudumu. Ja vēlaties uzzināt vairāk par to, varat izlasīt šo rakstu.
Secinājums
Es iesaku ne tikai izmantot UDP, bet izmantot tikai UDP un neko citu. Neizmantojiet TCP un UDP kopā — tā vietā uzziniet, kā pats ieviest nepieciešamos TCP līdzekļus, pamatojoties uz UDP.Nākamajos rakstos es jums pastāstīšu, kā to izdarīt - no sava protokola ieviešanas, izmantojot UDP balstītus savienojumus, līdz pārraides uzticamības un datu plūsmas kontroles ieviešanai.
Laba diena, dārgie lasītāji.
Pēc populāra pieprasījuma es šodien publicēju jums rakstu, kas iepazīstinās jūs ar datortīkla terminu pamatiem, proti:
- Tīkla protokoli - kas ir šie biedējošie nosaukumi un kam tie tiek izmantoti?
- UDP, TCP, ICMP - kas, kāpēc un kāda ir atšķirība
- Ikvienam ir IP adrese, bet ne visi zina, kāpēc šī lieta :-)
- Adreses maska (apakštīkls)
- Vārteja
- Daži vārdi par maršrutēšanas tabulām
- Ostas – kas tās īsti ir?
- MAC adrese
Tādi.
Raksts, manuprāt, noderēs ikvienam, gan mazam, gan lielam, jo tajā ir ne tik daudz dīvainu, nesaprotamu darbību vai vārdu kopums, bet gan pieejamā valodā sniegts informācijas bloks, kas vismaz sniegs jums ir izpratne par to, kā tas viss darbojas kopumā un kāpēc tas ir vajadzīgs. Aiziet.
Tīkla protokoli TCP/IP, NWLink IPX/SPX, NetBEUI
Sāksim ar to, kas ir tīkla protokols un kam tas tiek izmantots.
Tīkla protokols ir programmatūras ieviestu noteikumu kopums saziņai starp datoriem. Sava veida valoda, kurā datori runā viens ar otru un pārraida informāciju. Iepriekš datori, tā sakot, bija daudzvalodu, un vecākas Windows versijas izmantoja veselu protokolu kopumu - TCP/IP, NWLink IPX/SPX, NetBEUI. Tagad mēs esam panākuši vispārēju vienošanos, un standarts ir kļuvis par tikai TCP/IP protokola izmantošanu, un tāpēc tas tiks apspriests tālāk.
Kad viņi runā par TCP/IP, viņi ar šo nosaukumu parasti saprot daudzus dažādus... noteikumus vai, teiksim, standartus, kas ir noteikti, izmantojot (vai lietošanai) šo protokolu. Tā, piemēram, ir noteikumi, saskaņā ar kuriem notiek ziņojumu apmaiņa starp pasta serveriem, un ir noteikumi, saskaņā ar kuriem galalietotājs saņem vēstules savā pastkastē. Ir noteikumi videokonferenču vadīšanai un noteikumi par “telefona” sarunu organizēšanu internetā. Patiesībā tie pat nav īsti noteikumi... Vairāk kā sava veida gramatika, vai kā. Nu ziniet, angļu valodā ir viena struktūra dialogu konstruēšanai, franču valodā ir cita... Tātad TCP/IP kaut kas līdzīgs, t.i. noteikta virkne dažādu gramatisko noteikumu ir tieši integrētais TCP/IP protokols vai, precīzāk, TCP/IP protokolu kaudze.
Tīkla protokoli UDP, TCP, ICMP
TCP/IP protokolā datu pārraidei tiek izmantoti TCP un UDP protokoli. Daudzi droši vien ir dzirdējuši, ka ir gan TCP, gan UDP porti, taču ne visi zina, kāda ir atšķirība un kas tas ir. Tātad..
Datu pārraidei, izmantojot TCP protokolu (Transmission Control Protocol), nepieciešams informācijas saņemšanas apstiprinājums. "Nu, viņi saka, vai jūs to sapratāt?" Ja nosūtītāja puse nesaņem nepieciešamo apstiprinājumu noteiktajā termiņā, dati tiks pārsūtīti atkārtoti. Tāpēc TCP tiek uzskatīts par savienojumu balstītu protokolu, savukārt UDP (User Datagram Protocol) nav. UDP tiek izmantots gadījumos, kad saņemšanas apstiprinājums nav nepieciešams (piemēram, DNS pieprasījumi vai IP telefonija (kuras spilgts pārstāvis ir Skype)). Tas ir, atšķirība ir uzņemšanas apstiprinājuma klātbūtnē. Šķiet “Tas ir viss!”, bet praksē tam ir svarīga loma.
Ir arī ICMP protokols (Internet Control Message Protocol), ko izmanto datu pārsūtīšanai par tīkla parametriem. Tas ietver utilītu pakotņu veidus, piemēram, ping, attālums nav sasniedzams, TTL utt.
Kas ir IP adrese
Katram tāda ir, bet ne visiem ir priekšstats par to, kāda veida adrese ir un kāpēc bez tās nav iespējams iztikt. ES tev saku.
IP adrese ir 32 bitu numurs, ko izmanto, lai identificētu datoru tīklā. Ir ierasts rakstīt adresi katra šī skaitļa okteta decimāldaļās, iegūtās vērtības atdalot ar punktiem. Piemēram, 192.168.101.36
IP adreses ir unikālas, kas nozīmē, ka katram datoram ir sava ciparu kombinācija, un tīklā nevar būt divi datori ar vienu un to pašu adresi. IP adreses tiek izplatītas centralizēti, interneta pakalpojumu sniedzēji iesniedz pieteikumus valsts centriem atbilstoši savām vajadzībām. Pakalpojumu sniedzēju saņemtie adrešu diapazoni tiek tālāk sadalīti starp klientiem. Klienti savukārt paši var darboties kā nodrošinātājs un izplatīt saņemtās IP adreses starp apakšklientiem utt. Izmantojot šo IP adrešu izplatīšanas metodi, datorsistēma precīzi zina datora, kuram ir unikāla IP adrese, “atrašanās vietu”; - pietiek ar to, ka viņa nosūta datus uz "īpašnieka" tīklu, un pakalpojumu sniedzējs, savukārt, analizēs galamērķi un, zinot, kam šī adrešu daļa tiek piešķirta, nosūtīs informāciju nākamajam īpašniekam. IP adreses apakšdiapazons, līdz dati nonāk galamērķa datorā.
Vietējo tīklu izbūvei tiek piešķirti īpaši adrešu diapazoni. Tās ir adreses 10.x.x.x, 192.168.x.x, 10.x.x.x, no 172.16.x.x līdz 172.31.x.x, 169.254.x.x, kur x nozīmē jebkuru skaitli no 0 līdz 254. No norādītajām adresēm pārsūtītās paketes netiek maršrutētas, citiem vārdiem sakot, tās vienkārši netiek sūtītas pa internetu, un tāpēc datoriem dažādos lokālos tīklos var būt atbilstošas adreses no norādītajiem diapazoniem. Tas ir, uzņēmumam LLC "Horns and Hooves" un SIA "Vasya and Company" var būt divi datori ar adresēm 192.168.0.244, bet nevar, teiksim, ar adresēm 85.144.213.122, kas saņemti no interneta pakalpojumu sniedzēja, jo . Internetā nevar būt divas identiskas IP adreses. Lai nosūtītu informāciju no šādiem datoriem uz internetu un atpakaļ, tiek izmantotas īpašas programmas un ierīces, kas, strādājot ar internetu, aizstāj vietējās adreses ar reālām. Citiem vārdiem sakot, dati tiek nosūtīti uz tīklu no reālas IP adreses, nevis no vietējās. Šis process notiek lietotājam nepamanīts, un to sauc par adreses tulkošanu. Vēlos arī pieminēt, ka viena tīkla ietvaros, teiksim, uzņēmuma Horns and Hooves LLC, nevar būt divi datori ar vienu lokālo IP adresi, t.i., augstāk minētajā piemērā bija domāts, ka viens dators ar adresi 192.168.0.244 vienā uzņēmumā, otrs ar tādu pašu adresi citā. Tajā pašā uzņēmumā divi datori ar adresi 192.168.0.244 vienkārši nesanāks.
Jūs droši vien esat dzirdējuši tādus terminus kā ārējais IP un iekšējais IP, pastāvīgais (statiskais IP) un mainīgais (dinamiskais) IP. Īsumā par tiem:
- ārējais IP ir tieši tas pats IP, ko sniedz jūsu pakalpojumu sniedzējs, t.i. Piemēram, jūsu unikālā adrese internetā ir 85.144.24.122
- iekšējais IP ir lokālais IP, t.i. Piemēram, jūsu IP lokālajā tīklā ir 192.168.1.3
- statiskā IP ir IP, kas nemainās ar katru savienojumu, t.i. jums uzticēts stingri un uz visiem laikiem
- dinamiskā IP ir peldoša IP adrese, kas mainās ar katru savienojumu
Jūsu IP veids (statiskā vai dinamiskā) ir atkarīgs no jūsu pakalpojumu sniedzēja iestatījumiem.
Kas ir adreses maska (apakštīkls)
Apakštīkla jēdziens tika ieviests, lai varētu atlasīt daļu vienas organizācijas IP adrešu, daļu citas utt. Apakštīkls ir IP adrešu diapazons, kas tiek uzskatīts par piederīgu vienam lokālajam tīklam. Strādājot lokālajā tīklā, informācija tiek nosūtīta tieši adresātam. Ja dati ir paredzēti datoriem ar IP adresi, kas nepieder lokālajam tīklam, tad tiem tiek piemēroti īpaši noteikumi, lai aprēķinātu maršrutu pārsūtīšanai no viena tīkla uz otru.
Maska ir parametrs, kas programmatūrai norāda, cik datoru ir iekļauti noteiktā grupā (apakštīklā). Adreses maskai ir tāda pati struktūra kā pašai IP adresei: tā ir četru skaitļu grupu kopa, no kurām katra var būt diapazonā no 0 līdz 255. Šajā gadījumā, jo zemāka ir maskas vērtība, jo vairāk datoru ir pievienots šim apakštīklam. Mazo uzņēmumu tīklos maska parasti ir 255.255.255.x (piemēram, 255.255.255.224). Tīkla maska ir piešķirta datoram kopā ar IP adresi. Tā, piemēram, tīklā 192.168.0.0 ar masku 255.255.255.0 var būt datori ar adresēm no 192.168.0.1 līdz 192.168.254 192.168.0.0 ar masku no 255.255.8.1.1.9.1.25.9 168.0 .127. Es domāju, ka jēga ir skaidra. Parasti pakalpojumu sniedzēji izmanto tīklus ar nelielu iespējamo datoru skaitu, lai saglabātu IP adreses. Piemēram, klientam var tikt piešķirta adrese ar masku 255.255.255.252. Šajā apakštīklā ir tikai divi datori.
Kad dators ir saņēmis IP adresi un zina apakštīkla maskas vērtību, programma var sākt darboties šajā lokālajā apakštīklā. Taču, lai apmainītos ar informāciju ar citiem datoriem globālajā tīklā, ir jāzina noteikumi, kur sūtīt informāciju ārējam tīklam. Šim nolūkam tiek izmantots tāds raksturlielums kā vārtejas adrese.
Kas ir vārteja?
Vārteja ir ierīce (dators vai maršrutētājs), kas pārsūta informāciju starp dažādiem IP apakštīkliem. Ja programma nosaka (pēc IP un maskas), ka mērķa adrese nav daļa no vietējā apakštīkla, tā nosūta šos datus uz ierīci, kas darbojas kā vārteja. Protokola iestatījumos norādiet šādas ierīces IP adresi.
Lai strādātu tikai lokālajā tīklā, vārteja var nebūt norādīta.
Individuāliem lietotājiem, kas pieslēdzas internetam, vai maziem uzņēmumiem ar vienu savienojuma kanālu sistēmai jābūt tikai vienai vārtejas adresei — tā ir tās ierīces adrese, kurai ir interneta pieslēgums. Ja ir vairāki maršruti, būs vairāki vārti. Šajā gadījumā datu ceļa noteikšanai tiek izmantota maršrutēšanas tabula.
Kas ir maršrutēšanas tabulas
Un tā mēs gludi sasniedzām viņus. Un tā.. Kas tie par galdiņiem?
Organizācijai vai lietotājam var būt vairāki interneta pieslēguma punkti (piemēram, rezerves kanāli gadījumam, ja ar pirmo pakalpojumu sniedzēju kaut kas noiet greizi, bet internets tik un tā ir ļoti nepieciešams) vai arī savā struktūrā var būt vairāki IP tīkli. Šajā gadījumā, lai sistēma zinātu, pa kuru ceļu (caur kuru vārteju) nosūtīt šo vai citu informāciju, tiek izmantotas maršrutēšanas tabulas. Katras vārtejas maršrutēšanas tabulas norāda tos interneta apakštīklus, par kuriem informācija ir jāpārsūta caur tām. Šajā gadījumā vairākām vārtejām var iestatīt vienādus diapazonus, bet ar dažādām datu pārraides izmaksām: piemēram, informācija tiks nosūtīta pa kanālu, kuram ir viszemākās izmaksas, un, ja tas viena vai otra iemesla dēļ neizdodas, nākamais. pieejams lielākā daļa tiks automātiski izmantots lēts savienojums.
Kas ir tīkla porti
Pārsūtot datus, papildus sūtītāja un saņēmēja IP adresēm informācijas pakete satur portu numurus. Piemērs: 192.168.1.1:80, šajā gadījumā 80 ir porta numurs. Ports ir numurs, ko izmanto, saņemot un pārsūtot datus, lai identificētu procesu (programmu), kuram jāapstrādā dati. Tātad, ja pakete tiek nosūtīta uz 80. portu, tas norāda, ka informācija ir paredzēta HTTP serverim.
Portu numuri no 1 līdz 1023 tiek piešķirti konkrētām programmām (tā saucamajiem labi zināmajiem portiem). Portus ar numuru 1024 -65 535 var izmantot patentētās programmās. Šādā gadījumā iespējamie konflikti ir jārisina pašām programmām, izvēloties brīvo portu. Citiem vārdiem sakot, porti tiks sadalīti dinamiski: iespējams, ka nākamreiz, kad programma startēs, tā izvēlēsies citu porta vērtību, ja vien, protams, manuāli, izmantojot iestatījumus, neiestatīsit portu.
Kas ir MAC adrese
Fakts ir tāds, ka tīklā nosūtītās paketes tiek adresētas datoriem, nevis pēc to nosaukumiem vai IP adreses. Pakete ir paredzēta ierīcei ar noteiktu adresi, ko sauc par MAC adresi.
MAC adrese ir unikāla tīkla ierīces adrese, kuru tai ir piešķīris iekārtas ražotājs, t.i. Tas ir sava veida apzīmogots jūsu tīkla kartes numurs. MAC adreses pirmā puse ir ražotāja identifikators, otrā ir šīs ierīces unikālais numurs.
Parasti MAC adrese ir nepieciešama, lai identificētu, piemēram, ar pakalpojumu sniedzēju (ja pakalpojumu sniedzējs izmanto MAC adreses saistīšanu, nevis pieteikšanās paroli) vai maršrutētāja iestatīšanai.
Kur redzēt visus tīkla iestatījumus
Gandrīz aizmirsu pateikt dažus vārdus par to, kur to visu var apskatīt un mainīt.
| Lasīt: |
|---|
Jauns
- Kā programmā Word likt uzsvaru uz burta
- Kā pārvērst attēlus PNG formātā?
- Tehniskas problēmas un to risinājumi v
- Bioshock remastered nesāksies
- Kā iestatīt melodiju vajadzīgajam kontaktam viedtālrunī Nokia X2 ar divām SIM kartēm
- Bezmaksas programmas Windows lejupielādēt bez maksas
- Kā ierakstīt jebkuru ISO attēlu USB zibatmiņas diskā
- Zvani no nezināmiem numuriem
- Es aizmirsu sava Google konta paroli un, piesakoties, saņemu ziņojumu, ka ievadījāt nepareizu paroli.
- Tīkla adapterim nav derīgu IP iestatījumu - problēmas risinājums
