Enne kui alustame tänast videoõpetust, tahan tänada kõiki, kes aitasid kaasa minu kursuse populaarsusele YouTube'is. Kui ma seda umbes 8 kuud tagasi alustasin, ei oodanud ma sellist edu - täna on minu tunde vaadanud 312724 11208 inimest, mul on 7 6 tellijat. Ma ei osanud uneski näha, et see tagasihoidlik algus nii kõrgele jõuab. Kuid ärgem raisakem aega ja asugem otse tänase õppetunni juurde. Täna täidame lüngad, mis tekkisid viimases 3 videotunnis. Kuigi täna on alles 3. päev, jagati XNUMX. päev XNUMX videotunniks, nii et täna vaatate tegelikult kaheksandat videotundi.
Täna käsitleme kolme olulist teemat: DHCP, TCP transport ja levinumad pordinumbrid. IP-aadressidest oleme juba rääkinud ja üks olulisemaid tegureid IP-aadressi konfigureerimisel on DHCP.
DHCP tähistab Dynamic Host Configuration Protocol ja see on protokoll, mis aitab hostide IP-aadresse dünaamiliselt konfigureerida. Nii et me kõik oleme seda akent näinud. Kui klõpsate suvandil "Hangi IP-aadress automaatselt", otsib arvuti DHCP-serverit, mis on konfigureeritud samas alamvõrgus ja saadab erinevaid pakette ja IP-aadressi päringuid. DHCP-protokollil on 6 sõnumit, millest 4 on IP-aadressi määramisel kriitilised.
Esimene teade on DHCP DISCOVERY teade. DHCP-tuvastussõnum sarnaneb tervitussõnumiga. Kui võrguga liitub uus seade, küsib see, kas võrgus on DHCP-server.
See, mida slaidil näete, näeb välja nagu leviedastustaotlus, kus seade võtab ühendust kõigi võrgus olevate seadmetega, kes otsivad DHCP-serverit. Nagu ma ütlesin, on see edastustaotlus, nii et kõik võrgus olevad seadmed kuulevad seda.
Kui võrgus on DHCP server, saadab see paketi – DHCP PAKKUMINE. Ettepanek tähendab, et DHCP-server saadab vastuseks otsingupäringule kliendile konfiguratsiooni, paludes kliendil teatud IP-aadressi aktsepteerida.
DHCP-server reserveerib IP-aadressi, antud juhul 192.168.1.2, seda ei anna, vaid pigem reserveerib selle aadressi seadmele. Samas sisaldab pakkumispakett oma DHCP-serveri IP-aadressi.
Kui selles võrgus on rohkem kui üks DHCP-server, pakub mõni teine DHCP-server kliendi leviedastuspäringu vastuvõtmisel sellele samuti oma IP-aadressi, näiteks 192.168.1.50. Pole tavaline, et samas võrgus on konfigureeritud kaks erinevat DHCP-serverit, kuid mõnikord juhtub see. Seega, kui kliendile saadetakse DHCP-pakkumine, saab ta 2 DHCP-pakkumist ja peab nüüd otsustama, millise DHCP-pakkumise ta soovib vastu võtta.
Oletame, et klient nõustub esimese taotlusega. See tähendab, et klient saadab DHCP REQUEST päringu, mis sõna-sõnalt ütleb: "Nõustun DHCP-serveri 192.168.1.2 pakutava IP-aadressi 192.168.1.1.
Päringu saamisel vastab 192.168.1.1 DHCP-server "okei, ma tunnistan seda", st kinnitab päringu ja saadab selle DHCP ACK-i kliendile. Kuid me mäletame, et teine DHCP-server on reserveerinud kliendile IP-aadressi 1.50. Kui ta saab kliendi leviedastuspäringu, saab ta tõrkest teada ja paneb selle IP-aadressi tagasi kogumisse, et saaks selle määrata mõnele teisele kliendile, kui ta saab uue päringu.
Need on 4 kriitilist sõnumit, mida DHCP IP-aadresside määramisel vahetab. Järgmisena on DHCP-l veel 2 teabeteadet. Klient väljastab teabesõnumi, kui see nõuab rohkem teavet, kui ta teises etapis DHCP OFFER klauslis sai. Kui server ei andnud DHCP pakkumises piisavalt teavet või kui klient vajab rohkem teavet kui pakkumise paketis sisalduv, küsib ta täiendavat DHCP teavet. On veel üks sõnum, mille klient saadab serverile – see on DHCP RELEASE. See teavitab teid, et klient soovib oma olemasoleva IP-aadressi vabastada.
Kõige sagedamini juhtub aga see, et kasutaja katkestab ühenduse võrguga enne, kui klient jõuab serverisse DHCP RELEASE saata. See juhtub siis, kui lülitate arvuti välja, mida me ka teeme. Sel juhul ei ole võrgukliendil või arvutil lihtsalt aega teavitada serverit kasutatud aadressi vabastamisest, seega pole DHCP RELEASE vajalik samm. IP-aadressi saamiseks on vaja järgmisi toiminguid: DHCP avastamine, DHCP pakkumine, DHCP päring ja DHCP käepigistus.
Ühes järgmistest õppetundidest räägin teile, kuidas me DNCP-kogumi loomisel DHCP-serverit konfigureerime. Koondamise all peame silmas seda, et käsite serveril määrata IP-aadressid vahemikus 192.168.1.1 kuni 192.168.1.254. Seega loob DHCP-server basseini, paigutab sinna 254 IP-aadressi ja saab võrgus olevatele klientidele aadresse määrata ainult sellest kogumist. Nii et see on midagi haldussätete sarnast, mida kasutaja saab teha.
Vaatame nüüd TCP-edastust. Ma ei tea, kas olete pildil kujutatud "telefoniga" tuttav, aga lapsepõlves kasutasime omavahel rääkimiseks neid nööriga ühendatud plekkpurke.
Kahjuks ei saa tänapäeva põlvkond endale sellist “luksust” lubada. Ma mõtlen täna, et lapsed on üheaastaselt teleka ees, mängivad PSP-d ja võib-olla see on vaieldav, aga ma arvan, et meil oli kõige parem lapsepõlv, tegelikult käisime õues mängimas ja tänapäeva lapsi ei saa diivanilt ära tõmmata. .
Mu poeg on alles aastane ja ma juba näen, et ta on iPadist sõltuvuses, ma mõtlen, et ta on veel väga väike, aga ma arvan, et tänapäeva lapsed sünnivad juba teades, kuidas elektroonilisi vidinaid käsitseda. Niisiis, ma tahtsin öelda, et lapsepõlves tegime mängides plekkpurkidesse augud ja kui me sidusime need nööriga ja ütlesime midagi ühte purki, siis teises otsas kuulis inimene, mida räägitakse. talle lihtsalt purki kõrva juurde pannes. Seega on see väga sarnane võrguühendusega.
Tänapäeval peab isegi TCP-edastustel olema ühendus, mis tuleb luua enne tegeliku andmeedastuse algust. Nagu eelmistes tundides arutasime, on TCP ühendusele orienteeritud edastamine, UDP aga ühendusele orienteeritud edastamine. Võib öelda, et UDP on koht, kus ma palli viskan ja teie otsustate, kas saate selle kinni püüda. See, kas sa oled selleks valmis või mitte, pole minu probleem, ma lihtsalt jätan ta maha.
TCP on pigem selline, et räägite mehega ja hoiatate teda ette, et viskate palli, nii et loote sideme ja siis viskate palli, nii et teie partner on tõenäolisemalt valmis seda püüdma. Seega loob TCP tegelikult ühenduse ja hakkab seejärel tegelikku edastamist tegema.
Vaatame, kuidas see sellise ühenduse loob. See protokoll kasutab ühenduse loomiseks 3-suunalist käepigistust. See ei ole väga tehniline termin, kuid seda on pikka aega kasutatud TCP-ühenduse kirjeldamiseks. Saatev seade algatab kolmesuunalise käepigistuse, kus klient saadab serverile SYN-lipuga paketi.
Oletame, et esiplaanil olev tüdruk, kelle nägu näeme, on seade A ja taustal olev tüdruk, kelle nägu pole näha, on seade B. Tüdruk A saadab tüdrukule B SYN-paketi ja ta ütleb: “Tore, kes- siis ta tahab minuga suhelda. Seega pean vastama, et olen valmis suhtlema! Kuidas seda teha? Võiks lihtsalt saata tagasi teise SYN-paketi ja seejärel ACK-i, mis näitab algse SYN-paketi kättesaamist. Kuid selle asemel, et saata ACK-e eraldi, moodustab server ühise paketi, mis sisaldab SYN-i ja ACK-i ning edastab selle võrgu kaudu.
Seega on seade A saatnud SYN-paketi ja saanud tagasi SYN/ACK-paketi. Nüüd peab seade A saatma seadmele B ACK-paketi, st kinnitama, et on saanud seadmelt B nõusoleku side loomiseks. Seega said mõlemad seadmed SYN- ja ACK-pakette ning nüüd võib öelda, et ühendus on loodud ehk 3-etapiline käepigistus on TCP-protokolli abil lõpule viidud.
Järgmisena vaatleme TCP aknatehnoloogiat. Lihtsamalt öeldes on see meetod, mida kasutatakse TCP/IP-s saatja ja vastuvõtja võimaluste üle läbirääkimiseks.
Oletame, et Windowsis proovime teisaldada suurt faili, näiteks 2 GB suurust, ühelt draivilt teisele. Kohe ülekande alguses annab süsteem meile teada, et failiedastus võtab aega ligikaudu 1 aasta. Kuid mõni sekund hiljem parandab süsteem ennast ja ütleb: "Oota, ma arvan, et see võtab umbes 6 kuud, mitte aasta." Möödub veidi rohkem aega ja Windows ütleb: "Ma arvan, et suudan faili üle kanda 1 kuu pärast." Sellele järgneb teade “1 päev”, “6 tundi”, “3 tundi”, “1 tund”, “20 minutit”, “10 minutit”, “3 minutit”. Tegelikult võtab kogu failiedastusprotsess vaid 3 minutit. Kuidas see juhtus? Esialgu, kui teie seade proovib suhelda teise seadmega, saadab see ühe paketi ja ootab kinnitust. Kui seade ootab kaua kinnitust, mõtleb see: "Kui ma pean selle kiirusega 2 GB andmeid edastama, kulub selleks umbes 2 aastat." Mõne aja pärast saab teie seade ACK-i ja mõtleb: "Olgu, ma saatsin ühe paketi ja sain ACK-i, seega saab saaja vastu võtta 1 paketi. Nüüd proovin saata talle ühe paki asemel kümme. Saatja saadab 10 paketti ja mõne aja pärast saab vastuvõtvalt seadmelt ACK kinnituse, mis tähendab, et saaja ootab järgmist, 10. paketti. Saatja arvab: "Tore, kuna saaja käsitles korraga 11 pakki, siis nüüd proovin talle kümne paki asemel saata 10 pakki." Ta saadab 100 pakki ja saaja vastab, et sai need kätte ja ootab nüüd 100 pakki. Seega aja jooksul edastatavate pakettide arv suureneb.
Seetõttu näete faili kopeerimisaja kiiret vähenemist võrreldes algselt väidetuga – see on tingitud suurenenud võimest edastada suuri andmemahtusid. Siiski saabub hetk, mil edastusmahu edasine suurendamine muutub võimatuks. Oletame, et saatsite 10000 9000 paketti, kuid vastuvõtja seadme puhver suudab vastu võtta ainult 9000. Sel juhul saadab vastuvõtja ACK-i teatega: "Ma olen saanud 9001 paketti ja olen nüüd valmis vastu võtma 9000." Sellest järeldab saatja, et vastuvõtva seadme puhvri maht on vaid 9000, mis tähendab, et edaspidi saadan ma mitte rohkem kui 9000 paketti korraga. Sel juhul arvutab saatja kiiresti välja aja, mis tal kulub ülejäänud andmehulga 3 paketi kaupa ülekandmiseks ja annab XNUMX minutit. Need kolm minutit on tegelik edastusaeg. Seda teeb TCP Windowing.
See on üks neist liikluse piiramise mehhanismidest, mille puhul saateseade lõpuks mõistab, milline on tegelik võrguvõimsus. Võib tekkida küsimus, miks nad ei suuda eelnevalt kokku leppida, milline on vastuvõtva seadme võimsus? Fakt on see, et see on tehniliselt võimatu, kuna võrgus on erinevat tüüpi seadmeid. Oletame, et teil on iPad ja sellel on erinev andmeedastus/vastuvõtja kiirus kui iPhone'il, teil võib olla erinevat tüüpi telefone või võib-olla on teil väga vana arvuti. Seetõttu on kõigil erinev võrgu ribalaius.
Seetõttu töötati välja TCP Windowing tehnoloogia, kui andmeedastus algab väikese kiirusega või minimaalse pakettide arvu edastamisega, suurendades järk-järgult liikluse "akent". Saadad ühe paketi, 5 paketti, 10 paketti, 1000 paketti, 10000 XNUMX paketti ja avad aeglaselt seda akent järjest rohkem ja rohkem, kuni “avamine” saavutab teatud aja jooksul saadetud maksimaalse võimaliku liiklusmahu. Seega on akende kontseptsioon osa TCP-protokolli tööst.
Järgmisena vaatleme levinumaid pordinumbreid. Klassikaline olukord on siis, kui teil on 1 põhiserver, võib-olla andmekeskus. See sisaldab failiserverit, veebiserverit, meiliserverit ja DHCP-serverit. Nüüd, kui üks klientarvutitest võtab ühendust andmekeskusega, mis asub pildi keskel, hakkab see saatma failiserveri liiklust kliendi seadmetele. Seda liiklust näidatakse punaselt ja see edastatakse konkreetse serveri konkreetse rakenduse jaoks konkreetse pordi kaudu.
Kuidas sai server teada, kuhu teatud liiklus peaks liikuma? Ta saab selle teada sihtkoha pordi numbrist. Kui vaatate kaadrit, näete, et iga andmeedastuse puhul on märgitud sihtpordi number ja lähtepordi number. Näete, et sinine ja punane liiklus ning sinine liiklus on veebiserveri liiklus, mõlemad lähevad samasse füüsilist serverisse, kuhu on installitud erinevad serverid. Kui see on andmekeskus, siis kasutab see virtuaalservereid. Niisiis, kuidas nad teadsid, et punane liiklus pidi minema tagasi selle IP-aadressiga vasakpoolsesse sülearvutisse? Nad teavad seda tänu pordinumbritele. Kui viitate Wikipedia artiklile "TCP- ja UDP-portide loend", näete, et see loetleb kõik standardsed pordinumbrid.
Kui kerite seda lehte allapoole, näete, kui suur see loend on. See sisaldab ligikaudu 61 000 numbrit. Pordinumbreid vahemikus 1 kuni 1024 tuntakse kõige levinumate pordinumbritena. Näiteks port 21/TCP on ftp käskude saatmiseks, port 22 ssh jaoks, port 23 Telneti jaoks ehk krüptimata sõnumite saatmiseks. Väga populaarne port 80 kannab andmeid HTTP kaudu, port 443 aga krüpteeritud andmeid HTTPS-i kaudu, mis on sarnane HTTP turvalise versiooniga.
Mõned pordid on pühendatud nii TCP-le kui ka UDP-le ning mõned täidavad erinevaid ülesandeid olenevalt sellest, kas ühendus on TCP või UDP. Niisiis, ametlikult kasutatakse HTTP jaoks TCP porti 80 ja mitteametlikult UDP porti 80 HTTP jaoks, kuid erineva HTTP protokolli - QUIC all.
Seetõttu ei ole TCP-s kasutatavate pordinumbrite eesmärk alati sama, mis UDP-s. Seda loendit pole vaja pähe õppida, seda on võimatu meeles pidada, kuid peate teadma mõnda populaarset ja levinumat pordinumbreid. Nagu ma ütlesin, on mõnel neist portidest ametlik otstarve, mis on standardites kirjeldatud, ja mõnel mitteametlik, nagu Chromiumi puhul.
Seega on selles tabelis loetletud kõik levinud pordinumbrid ning neid numbreid kasutatakse konkreetsete rakenduste kasutamisel liikluse saatmiseks ja vastuvõtmiseks.
Nüüd vaatame, kuidas andmed liiguvad üle võrgu selle vähese teabe põhjal, mida me teame. Oletame, et arvuti 10.1.1.10 soovib ühendust võtta selle arvutiga või serveriga, mille aadress on 30.1.1.10. Iga seadme IP-aadressi all on selle MAC-aadress. Toon näite MAC-aadressi kohta, millel on ainult viimased 4 tähemärki, kuid praktikas on see 48-bitine kuueteistkümnendsüsteem ja 12 tähemärki. Kuna igaüks neist numbritest koosneb 4 bitist, tähistavad 12 kuueteistkümnendnumbrit 48-bitist numbrit.
Nagu me teame, kui see seade soovib selle serveriga ühendust võtta, tuleb kõigepealt teha 3-suunalise käepigistuse esimene samm ehk saata SYN-pakett. Selle päringu tegemisel määrab arvuti 10.1.1.10 lähte pordi numbri, mille Windows loob dünaamiliselt. Windows valib juhuslikult pordi numbri vahemikus 1 kuni 65,000 1. Kuid kuna algusnumbrid vahemikus 1024 kuni 25000 on laialt teada, võtab süsteem sel juhul arvesse numbreid, mis on suuremad kui 25113 XNUMX, ja loob juhusliku allika pordi, näiteks numbri XNUMX.
Järgmiseks lisab süsteem paketile sihtpordi, antud juhul on selleks port 21, sest selle FTP-serveriga ühendust üritav rakendus teab, et peaks saatma FTP-liiklust.
Järgmisena ütleb meie arvuti: "Olgu, minu IP-aadress on 10.1.1.10 ja ma pean ühendust võtma IP-aadressiga 30.1.1.10." Mõlemad aadressid sisalduvad paketis ka SYN-i päringu moodustamiseks ja see pakett ei muutu enne ühenduse lõppemist.
Soovin, et saaksite sellest videost aru, kuidas andmed võrgus liiguvad. Kui meie päringu saatnud arvuti näeb lähte-IP-aadressi ja sihtkoha IP-aadressi, mõistab see, et sihtaadress pole selles kohtvõrgus. Unustasin öelda, et need on kõik /24 IP-aadressid. Nii et kui vaatate /24 IP-aadresse, saate aru, et arvutid 10.1.1.10 ja 30.1.1.10 ei ole samas võrgus. Seega saab päringu saatnud arvuti aru, et sellest võrgust lahkumiseks peab ta ühendust võtma 10.1.1.1 lüüsiga, mis on konfigureeritud ühel ruuteri liidestest. Ta teab, et peaks minema 10.1.1.1-le ja teab oma MAC-aadressi 1111, kuid ei tea lüüsi 10.1.1.1 MAC-aadressi. Mida ta teeb? See saadab leviedastuse ARP päringu, mille saavad vastu kõik võrgus olevad seadmed, kuid sellele vastab ainult ruuter IP-aadressiga 10.1.1.1.
Ruuter vastab oma AAAA MAC-aadressiga ning sellesse kaadrisse paigutatakse ka nii lähte- kui ka sihtkoha MAC-aadress. Kui kaader on valmis, tehakse enne võrgust lahkumist CRC andmete terviklikkuse kontroll, mis on vigade tuvastamiseks kontrollsumma leidmise algoritm.
Tsükliline liiasus CRC tähendab, et kogu see kaader, alates SYN-ist kuni viimase MAC-aadressini, juhitakse läbi räsialgoritmi, näiteks MD5, mille tulemuseks on räsiväärtus. Räsiväärtus ehk MD5 kontrollsumma asetatakse seejärel kaadri algusesse.
Märgistasin selle FCS/CRC, kuna FCS on kaadrikontrollijada, neljabaidine CRC väärtus. Mõned inimesed kasutavad tähistust FCS ja mõned kasutavad nimetust CRC, seega lisasin lihtsalt mõlemad nimetused. Kuid põhimõtteliselt on see lihtsalt räsiväärtus. See on vajalik veendumaks, et kõik võrgu kaudu saadud andmed ei sisalda vigu. Seega, kui see kaader jõuab ruuterini, arvutab ruuter esimese asjana ise kontrollsumma ja võrdleb seda FCS või CRC väärtusega, mida vastuvõetud kaader sisaldab. Nii saab ta kontrollida, et üle võrgu saadud andmed ei sisaldaks vigu, misjärel eemaldab ta kaadrist kontrollsumma.
Järgmisena vaatab ruuter MAC-aadressi ja ütleb: "Olgu, MAC-aadress AAAA tähendab, et kaader on adresseeritud mulle" ja kustutab kaadri osa, mis sisaldab MAC-aadresse.
Sihtkoha IP-aadressi 30.1.1.10 vaadates saab ta aru, et see pakett pole talle adresseeritud ja peab minema ruuteri kaudu kaugemale.
Nüüd “arvab” ruuter, et peab nägema, kus asub võrk aadressiga 30.1.1.10. Me pole veel marsruutimise täielikku kontseptsiooni käsitlenud, kuid teame, et ruuteritel on marsruutimistabel. Selles tabelis on kirje võrgu kohta aadressiga 30.1.1.0. Nagu mäletate, pole see hosti IP-aadress, vaid võrguidentifikaator. Ruuter "arvab", et suudab ruuteri 30.1.1.0 kaudu jõuda aadressile 24/20.1.1.2.
Võite küsida, kuidas ta seda teab? Pidage lihtsalt meeles, et see teab seda kas marsruutimisprotokollide või teie seadete põhjal, kui olete administraatorina konfigureerinud staatilise marsruudi. Kuid igal juhul sisaldab selle ruuteri marsruutimistabel õiget kirjet, nii et ta teab, et peaks selle paketi saatma aadressile 20.1.1.2. Eeldades, et ruuter teab juba sihtkoha MAC-aadressi, jätkame lihtsalt paketi edastamist. Kui ta seda aadressi ei tea, käivitab ta ARP uuesti, saab ruuteri MAC-aadressi 20.1.1.2 ja kaadri saatmise protsess jätkub uuesti.
Seega eeldame, et see juba teab MAC-aadressi, siis on meil BBB allika MAC-aadress ja CCC sihtkoha MAC-aadress. Ruuter arvutab uuesti FCS/CRC ja asetab selle kaadri algusesse.
Seejärel saadab see kaadri üle võrgu, kaader jõuab ruuterini 20.1.12, kontrollib kontrollsummat, veendub, et andmed pole rikutud, ja kustutab FCS/CRC. Seejärel "kärpib" MAC-aadressid, vaatab sihtkohta ja näeb, et see on 30.1.1.10. Ta teab, et see aadress on tema liidesega ühendatud. Korratakse sama kaadri moodustamise protsessi, ruuter lisab lähte- ja sihtkoha MAC-aadressi väärtused, teeb räsi, kinnitab räsi raami külge ja saadab selle üle võrgu.
Meie server, olles lõpuks saanud talle adresseeritud SYN päringu, kontrollib räsi kontrollsummat ja kui pakett vigu ei sisalda, siis kustutab räsi. Seejärel eemaldab ta MAC-aadressid, vaatab IP-aadressi ja mõistab, et see pakett on adresseeritud talle.
Pärast seda kärbib see OSI mudeli kolmanda kihiga seotud IP-aadressid ja vaatab pordinumbreid.
Ta näeb porti 21, mis tähendab FTP-liiklust, näeb SYN-i ja saab seetõttu aru, et keegi üritab temaga suhelda.
Nüüd loob server 30.1.1.10 käepigistuse kohta õpitu põhjal SYN/ACK paketi ja saadab selle tagasi arvutisse 10.1.1.10. Selle paketi vastuvõtmisel loob seade 10.1.1.10 ACK-i, edastab selle võrgu kaudu samamoodi nagu SYN-pakett ja pärast seda, kui server on saanud ACK-i, luuakse ühendus.
Üks asi, mida peaksite teadma, on see, et see kõik juhtub vähem kui sekundiga. See on väga-väga kiire protsess, mida ma püüdsin aeglustada, et kõik oleks teile selge.
Loodan, et sellest õpetusest õpitu on teile kasulik. Kui teil on küsimusi, kirjutage mulle aadressil [meiliga kaitstud] või jätke küsimused selle video alla.
Alates järgmisest õppetükist valin YouTube'ist välja 3 kõige huvitavamat küsimust, mille vaatan iga video lõpus üle. Nüüdsest on mul jaotis "Populaarsed küsimused", nii et postitan küsimuse koos teie nimega ja vastan sellele otse. Ma arvan, et see tuleb kasuks.
Täname, et jäite meiega. Kas teile meeldivad meie artiklid? Kas soovite näha huvitavamat sisu? Toeta meid, esitades tellimuse või soovitades sõpradele, Habri kasutajatele 30% allahindlus ainulaadsele algtaseme serverite analoogile, mille me teie jaoks välja mõtlesime: (saadaval RAID1 ja RAID10, kuni 24 tuuma ja kuni 40 GB DDR4-ga).
VPS (KVM) E5-2650 v4 (6 tuuma) 10 GB DDR4 240 GB SSD 1 Gbps kuni suveni tasuta kuue kuu eest tasudes saate tellida .
Dell R730xd 2 korda odavam? Ainult siin Hollandis! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – alates 99 dollarist! Millegi kohta lugema
Allikas: www.habr.com