Preden začnemo današnjo video vadnico, se želim zahvaliti vsem, ki so prispevali k priljubljenosti mojega tečaja na YouTubu. Ko sem ga začel pred približno 8 meseci, nisem pričakoval takšnega uspeha - danes si je moje lekcije ogledalo 312724 ljudi, imam 11208 naročnikov. Niti sanjalo se mi ni, da bo ta skromni začetek dosegel takšne višine. Toda ne izgubljajmo časa in pojdimo naravnost k današnji lekciji. Danes bomo zapolnili vrzeli, ki so nastale v zadnjih 7 video lekcijah. Čeprav je danes šele 6. dan, je bil 3. dan razdeljen na 3 video lekcije, tako da si boste danes pravzaprav ogledali osmo video lekcijo.
Danes bomo obravnavali 3 pomembne teme: DHCP, TCP transport in najpogostejše številke vrat. O naslovih IP smo že govorili in eden najpomembnejših dejavnikov pri konfiguraciji naslovov IP je DHCP.
DHCP pomeni Dynamic Host Configuration Protocol in je protokol, ki pomaga dinamično konfigurirati naslove IP za gostitelje. Torej smo vsi videli to okno. Ko kliknete možnost »Samodejno pridobi naslov IP«, računalnik poišče strežnik DHCP, ki je konfiguriran v istem podomrežju in pošlje različne pakete in zahteve za naslov IP. Protokol DHCP ima 6 sporočil, od katerih so 4 kritična za dodelitev naslova IP.
Prvo sporočilo je sporočilo DHCP DISCOVERY. Sporočilo o odkritju DHCP je podobno pozdravnemu sporočilu. Ko se nova naprava pridruži omrežju, vpraša, ali je v omrežju strežnik DHCP.
Kar vidite na diapozitivu, je videti kot zahteva za oddajanje, kjer naprava vzpostavi stik z vsemi napravami v omrežju in išče strežnik DHCP. Kot sem rekel, je to zahteva za oddajanje, zato jo lahko slišijo vse naprave v omrežju.
Če je v omrežju strežnik DHCP, pošlje paket - ponudbo DHCP PONUDBA. Predlog pomeni, da strežnik DHCP v odgovor na zahtevo po odkritju odjemalcu pošlje konfiguracijo, ki od odjemalca zahteva, da sprejme določen naslov IP.
Strežnik DHCP rezervira naslov IP, v tem primeru 192.168.1.2, ne zagotovi ga, ampak ta naslov rezervira za napravo. Hkrati paket ponudbe vsebuje svoj IP naslov DHCP strežnika.
Če je v tem omrežju več kot en strežnik DHCP, mu drug strežnik DHCP, ko prejme odjemalčevo zahtevo za oddajanje, ponudi tudi svoj naslov IP, na primer 192.168.1.50. Ni običajno, da sta v istem omrežju konfigurirana dva različna strežnika DHCP, vendar se včasih zgodi. Torej, ko je ponudba DHCP poslana stranki, ta prejme 2 ponudbi DHCP in se mora zdaj odločiti, katero ponudbo DHCP želi sprejeti.
Predpostavimo, da stranka sprejme prvo aplikacijo. To pomeni, da odjemalec pošlje zahtevo DHCP REQUEST, ki dobesedno pravi "Sprejemam naslov IP 192.168.1.2, ki ga ponuja strežnik DHCP 192.168.1.1."
Po prejemu zahteve strežnik 192.168.1.1 DHCP odgovori "v redu, priznam", to pomeni, da potrdi zahtevo in pošlje ta DHCP ACK odjemalcu. Toda spomnimo se, da je drug strežnik DHCP za odjemalca rezerviral naslov IP 1.50. Ko prejme odjemalčevo zahtevo za oddajanje, bo vedel za napako in bo ta naslov IP vrnil nazaj v skupino, tako da ga lahko dodeli drugemu odjemalcu, če prejme novo zahtevo.
To so 4 kritična sporočila, ki si jih DHCP izmenjuje pri dodeljevanju naslovov IP. Nato ima DHCP še 2 informativni sporočili. Odjemalec izda informacijsko sporočilo, če zahteva več informacij, kot jih je prejel v klavzuli DHCP OFFER v drugem koraku. Če strežnik v ponudbi DHCP ni zagotovil dovolj informacij ali če odjemalec potrebuje več informacij, kot jih vsebuje ponudbeni paket, zahteva dodatne informacije DHCP. Obstaja še eno sporočilo, ki ga odjemalec pošlje strežniku - to je DHCP RELEASE. Obvešča vas, da želi odjemalec sprostiti svoj obstoječi naslov IP.
Najpogosteje pa se zgodi, da uporabnik prekine povezavo z omrežjem, preden ima odjemalec čas, da strežniku pošlje DHCP RELEASE. To se zgodi, ko izklopite računalnik, kar počnemo mi. V tem primeru omrežni odjemalec ali računalnik preprosto nima časa obvestiti strežnik, naj sprosti uporabljeni naslov, zato DHCP RELEASE ni obvezen korak. Zahtevani koraki za pridobitev naslova IP so: odkrivanje DHCP, ponudba DHCP, zahteva DHCP in rokovanje DHCP.
V eni od naslednjih lekcij vam bom povedal, kako konfiguriramo strežnik DHCP pri ustvarjanju bazena DNCP. Z združevanjem mislimo, da strežniku naročite, naj dodeli naslove IP v območju od 192.168.1.1 do 192.168.1.254. Tako bo strežnik DHCP ustvaril bazen, vanj postavil 254 naslovov IP in le iz tega bazena bo lahko dodeljeval naslove odjemalcem v omrežju. To je torej nekaj podobnega skrbniški nastavitvi, ki jo lahko naredi uporabnik.
Zdaj pa poglejmo prenos TCP. Ne vem, če poznate "telefon" na sliki, toda ko smo bili otroci, smo za pogovor uporabljali te pločevinke, povezane z vrvico.
Takšnega “luksuza” si današnja generacija žal ne more privoščiti. Mislim, da so danes otroci pred TV-jem od enega leta naprej, igrajo PSP in morda je o tem sporno, ampak mislim, da smo imeli najlepše otroštvo, pravzaprav smo šli ven in se igrali igrice in današnjih otrok ni mogoče odmakniti od kavča. .
Moj sin je star komaj leto dni in že vidim, da je zasvojen z iPadom, mislim, da je še zelo majhen, ampak mislim, da se današnji otroci že rodijo, da znajo ravnati z elektronskimi pripomočki. Torej, hotel sem povedati, da smo kot otroci, ko smo se igrali, delali luknje v pločevinke in ko smo jih zavezali z vrvico in v eno pločevinko nekaj rekli, potem je na drugi strani človek slišal, kaj se govori preprosto tako, da mu pločevinko prislonite k ušesu. Torej je zelo podoben omrežni povezavi.
Danes morajo tudi prenosi TCP imeti povezavo, ki mora biti vzpostavljena, preden se dejanski prenos podatkov začne. Kot smo razpravljali v prejšnjih lekcijah, je TCP prenos, usmerjen v povezavo, medtem ko je UDP prenos, usmerjen v povezavo. Lahko bi rekli, da je UDP mesto, kjer vržem žogo in na vas je, da vidite, ali jo lahko ujamete. Ali si pripravljen na to ali ne, ni moj problem, samo pustil ga bom.
TCP je bolj podoben temu, da se s fantom pogovarjaš in ga vnaprej opozoriš, da boš vrgel žogo, tako da vzpostaviš vez, nato pa žogo vržeš, da je bolj verjetno, da jo bo tvoj partner pripravljen ujeti. Torej TCP dejansko vzpostavi povezavo in nato začne izvajati dejanski prenos.
Poglejmo, kako ustvari takšno povezavo. Ta protokol za vzpostavitev povezave uporablja 3-smerno rokovanje. To ni preveč tehnični izraz, vendar se že dolgo uporablja za opis povezave TCP. Naprava, ki pošilja, začne 3-smerno rokovanje, pri čemer odjemalec strežniku pošlje paket z zastavico SYN.
Recimo, da je deklica v ospredju, katere obraz lahko vidimo, naprava A, deklica v ozadju, katere obraz ni viden, pa je naprava B. Dekle A pošlje paket SYN deklici B in ta reče: »Super, kdo- potem hoče komunicirati z mano. Torej, moram odgovoriti, da sem pripravljen na komunikacijo!« Kako narediti? Enostavno bi lahko poslali nazaj drug paket SYN in nato ACK, ki označuje prejem prvotnega paketa SYN. Toda namesto ločenega pošiljanja ACK-jev strežnik oblikuje skupni paket, ki vsebuje SYN in ACK, ter ga pošlje po omrežju.
Torej je na tej točki naprava A poslala paket SYN in nazaj prejela paket SYN/ACK. Zdaj mora naprava A poslati napravi B paket ACK, to je potrditi, da je od naprave B prejela soglasje za vzpostavitev komunikacije. Tako sta obe napravi prejeli pakete SYN in ACK in zdaj lahko rečemo, da je bila povezava vzpostavljena, to je, da je bilo opravljeno 3-stopenjsko rokovanje po protokolu TCP.
Nato si bomo ogledali tehnologijo TCP Windowing. Preprosto povedano, to je metoda, ki se uporablja v TCP/IP za pogajanja o zmožnostih pošiljatelja in prejemnika.
Recimo, da v sistemu Windows poskušamo prenesti veliko datoteko, na primer veliko 2 GB, z enega pogona na drugega. Na samem začetku prenosa nas bo sistem obvestil, da bo prenos datoteke trajal približno 1 leto. Toda nekaj sekund kasneje se bo sistem popravil in rekel: "oh, počakaj malo, mislim, da bo trajalo približno 6 mesecev, ne eno leto." Še nekaj časa bo minilo in Windows bo rekel: "Mislim, da bom morda lahko prenesel datoteko čez 1 mesec." Temu bo sledilo sporočilo “1 dan”, “6 ur”, “3 ure”, “1 ura”, “20 minut”, “10 minut”, “3 minute”. Pravzaprav bo celoten postopek prenosa datoteke trajal le 3 minute. Kako se je to zgodilo? Na začetku, ko vaša naprava poskuša komunicirati z drugo napravo, pošlje en paket in čaka na potrditev. Če naprava dolgo čaka na potrditev, si misli: "če moram prenesti 2 GB podatkov pri tej hitrosti, bo to trajalo približno 2 leti." Čez nekaj časa vaša naprava prejme ACK in pomisli: »V redu, poslal sem en paket in prejel ACK, zato lahko prejemnik prejme 1 paket. Zdaj mu bom poskušal poslati 10 paketov namesto enega.” Pošiljatelj pošlje 10 paketov in čez nekaj časa od sprejemne naprave prejme potrditev ACK, kar pomeni, da prejemnik čaka na naslednji, 11. paket. Pošiljatelj si misli: »super, saj je prejemnik obdelal 10 paketov naenkrat, zdaj mu bom poskusil poslati 100 paketov namesto desetih.« Pošlje 100 paketov, prejemnik pa odgovori, da jih je prejel in sedaj čaka na 101 paket. Tako se sčasoma število prenesenih paketov povečuje.
Zato opazite hitro zmanjšanje časa kopiranja datoteke v primerjavi s prvotno navedenim - to je posledica povečane zmožnosti prenosa velikih količin podatkov. Vendar pa pride točka, ko nadaljnje povečanje obsega prenosa postane nemogoče. Recimo, da ste poslali 10000 paketov, medpomnilnik prejemnikove naprave pa jih lahko sprejme le 9000. V tem primeru prejemnik pošlje ACK s sporočilom: "Prejel sem 9000 paketov in zdaj sem pripravljen prejeti 9001." Iz tega pošiljatelj sklepa, da ima medpomnilnik sprejemne naprave kapaciteto samo 9000, kar pomeni, da od zdaj naprej ne bom poslal več kot 9000 paketov naenkrat. V tem primeru pošiljatelj hitro izračuna čas, ki ga bo potreboval za prenos preostale količine podatkov v delih po 9000 paketov, in poda 3 minute. Te tri minute so dejanski čas prenosa. To počne TCP Windowing.
To je eden od tistih mehanizmov za omejevanje prometa, kjer naprava, ki pošilja, sčasoma razume, kakšna je dejanska zmogljivost omrežja. Morda se sprašujete, zakaj se ne morejo vnaprej dogovoriti, kakšna je zmogljivost sprejemne naprave? Dejstvo je, da je to tehnično nemogoče, saj so v omrežju različne vrste naprav. Recimo, da imate iPad in ima drugačno hitrost prenosa/sprejemanja podatkov kot iPhone, morda imate različne vrste telefonov ali pa imate zelo star računalnik. Zato ima vsak drugačno pasovno širino omrežja.
Zato je bila razvita tehnologija TCP Windowing, ko se prenos podatkov začne pri nizki hitrosti ali s prenosom minimalnega števila paketov, s čimer se prometno »okno« postopoma povečuje. Pošljete en paket, 5 paketov, 10 paketov, 1000 paketov, 10000 paketov in počasi odpirate to okno vedno bolj, dokler "odpiranje" ne doseže največjega možnega obsega poslanega prometa v določenem časovnem obdobju. Tako je koncept oken del delovanja protokola TCP.
Nato si bomo ogledali najpogostejše številke vrat. Klasična situacija je, ko imate 1 glavni strežnik, morda podatkovni center. Vključuje datotečni strežnik, spletni strežnik, poštni strežnik in strežnik DHCP. Zdaj, če eden od odjemalskih računalnikov vzpostavi stik s podatkovnim centrom, ki se nahaja na sredini slike, bo začel pošiljati promet datotečnega strežnika v odjemalske naprave. Ta promet je prikazan rdeče in bo prenesen na določenih vratih za določeno aplikacijo iz določenega strežnika.
Kako je strežnik vedel, kam mora iti določen promet? To izve iz številke ciljnega pristanišča. Če pogledate okvir, boste videli, da je pri vsakem prenosu podatkov omenjena številka ciljnih vrat in številka izvornih vrat. Vidite lahko, da gresta modri in rdeči promet, modri promet pa je promet spletnega strežnika, oba na isti fizični strežnik, ki ima nameščene različne strežnike. Če je to podatkovni center, potem uporablja virtualne strežnike. Kako so torej vedeli, da naj bi se rdeči promet vrnil na ta levi prenosnik s tem naslovom IP? To vedo zahvaljujoč številkam vrat. Če se sklicujete na članek Wikipedije »Seznam vrat TCP in UDP«, boste videli, da navaja vse standardne številke vrat.
Če se pomaknete navzdol po tej strani, lahko vidite, kako velik je ta seznam. Vsebuje približno 61 številk. Številke vrat od 000 do 1 so znane kot najpogostejše številke vrat. Vrata 1024/TCP so na primer namenjena pošiljanju ftp ukazov, vrata 21 za ssh, vrata 22 za Telnet, torej za pošiljanje nešifriranih sporočil. Zelo priljubljena vrata 23 se uporabljajo za prenos podatkov po protokolu HTTP, medtem ko se vrata 80 uporabljajo za prenos šifriranih podatkov po protokolu HTTPS, ki je podoben varni različici HTTP.
Nekatera vrata so namenjena tako TCP kot UDP, nekatera pa opravljajo različne naloge glede na to, ali je povezava TCP ali UDP. Uradno se torej vrata TCP 80 uporabljajo za HTTP, neuradno pa vrata UDP 80 za HTTP, vendar pod drugim protokolom HTTP - QUIC.
Zato številke vrat v TCP niso vedno namenjene enakemu delovanju kot v UDP. Tega seznama se vam ni treba naučiti na pamet, nemogoče si ga je zapomniti, morate pa poznati nekaj priljubljenih in najpogostejših številk vrat. Kot sem rekel, imajo nekatera od teh vrat uraden namen, ki je opisan v standardih, nekatera pa neuraden namen, kot je to v primeru Chromiuma.
Torej, ta tabela navaja vse pogoste številke vrat in te številke se uporabljajo za pošiljanje in prejemanje prometa pri uporabi določenih aplikacij.
Zdaj pa poglejmo, kako se podatki premikajo po omrežju glede na malo informacij, ki jih poznamo. Recimo, da želi računalnik 10.1.1.10 vzpostaviti stik s tem računalnikom ali s tem strežnikom, ki ima naslov 30.1.1.10. Pod naslovom IP vsake naprave je njen naslov MAC. Dajem primer naslova MAC z zadnjimi 4 znaki, v praksi pa gre za 48-bitno šestnajstiško število z 12 znaki. Ker je vsako od teh števil sestavljeno iz 4 bitov, 12 šestnajstiških števk predstavlja 48-bitno število.
Kot vemo, če ta naprava želi vzpostaviti stik s tem strežnikom, je treba najprej opraviti prvi korak 3-smernega rokovanja, to je pošiljanje paketa SYN. Ko je podana ta zahteva, bo računalnik 10.1.1.10 določil izvorno številko vrat, ki jo Windows ustvari dinamično. Windows naključno izbere številko vrat med 1 in 65,000. Ker pa so začetne številke v območju od 1 do 1024 splošno znane, bo v tem primeru sistem upošteval številke, večje od 25000, in ustvaril naključna izvorna vrata, na primer številko 25113.
Nato bo sistem paketu dodal ciljna vrata, v tem primeru so to vrata 21, ker aplikacija, ki se poskuša povezati s tem strežnikom FTP, ve, da mora pošiljati promet FTP.
Nato naš računalnik reče: "V redu, moj naslov IP je 10.1.1.10 in moram stopiti v stik z naslovom IP 30.1.1.10." Oba naslova sta vključena tudi v paket za oblikovanje zahteve SYN in ta paket se ne bo spremenil do konca povezave.
Želim, da iz tega videa razumete, kako se podatki premikajo po omrežju. Ko naš računalnik, ki pošilja zahtevo, vidi izvorni naslov IP in ciljni naslov IP, razume, da ciljni naslov ni v tem lokalnem omrežju. Pozabil sem povedati, da so to vsi naslovi IP /24. Če torej pogledate naslove IP /24, boste ugotovili, da računalnika 10.1.1.10 in 30.1.1.10 nista v istem omrežju. Tako računalnik, ki pošilja zahtevo, razume, da mora zapustiti to omrežje vzpostaviti stik s prehodom 10.1.1.1, ki je konfiguriran na enem od vmesnikov usmerjevalnika. Ve, da mora iti na 10.1.1.1, in pozna svoj naslov MAC 1111, ne pozna pa naslova MAC prehoda 10.1.1.1. Kaj dela? Pošlje oddajno zahtevo ARP, ki jo bodo prejele vse naprave v omrežju, vendar se bo nanjo odzval samo usmerjevalnik z naslovom IP 10.1.1.1.
Usmerjevalnik se bo odzval s svojim naslovom MAC AAAA, v ta okvir pa bosta postavljena tudi izvorni in ciljni naslov MAC. Ko je okvir pripravljen, se pred izstopom iz omrežja izvede preverjanje celovitosti podatkov CRC, ki je algoritem za iskanje kontrolne vsote za odkrivanje napak.
Ciklična redundanca CRC pomeni, da se ta celoten okvir, od SYN do zadnjega naslova MAC, izvaja skozi algoritem zgoščevanja, recimo MD5, kar povzroči zgoščeno vrednost. Zgoščena vrednost ali kontrolna vsota MD5 se nato postavi na začetek okvira.
Označil sem ga FCS/CRC, ker je FCS zaporedje preverjanja okvirja, štiribajtna vrednost CRC. Nekateri uporabljajo oznako FCS, nekateri pa oznako CRC, zato sem vključil obe oznaki. Toda v bistvu je to samo zgoščena vrednost. Prepričati se je treba, da vsi podatki, prejeti prek omrežja, ne vsebujejo napak. Zato, ko ta okvir doseže usmerjevalnik, bo usmerjevalnik najprej sam izračunal kontrolno vsoto in jo primerjal z vrednostjo FCS ali CRC, ki jo vsebuje prejeti okvir. Tako lahko preveri, ali podatki, prejeti preko omrežja, ne vsebujejo napak, nato pa odstrani kontrolno vsoto iz okvira.
Nato bo usmerjevalnik pogledal naslov MAC in rekel: »V redu, naslov MAC AAAA pomeni, da je okvir naslovljen name,« in izbrisal del okvira, ki vsebuje naslove MAC.
Če pogleda ciljni naslov IP 30.1.1.10, bo razumel, da ta paket ni naslovljen nanj in mora iti dlje skozi usmerjevalnik.
Zdaj usmerjevalnik "misli", da mora videti, kje se nahaja omrežje z naslovom 30.1.1.10. Nismo še zajeli celotnega koncepta usmerjanja, vendar vemo, da imajo usmerjevalniki usmerjevalno tabelo. V tej tabeli je vnos za omrežje z naslovom 30.1.1.0. Kot se spomnite, to ni naslov IP gostitelja, ampak identifikator omrežja. Usmerjevalnik bo »mislil«, da lahko doseže naslov 30.1.1.0/24 prek usmerjevalnika 20.1.1.2.
Lahko se vprašate, kako on to ve? Upoštevajte le, da bo to vedel iz usmerjevalnih protokolov ali iz vaših nastavitev, če ste kot skrbnik konfigurirali statično pot. Toda v vsakem primeru usmerjevalna tabela tega usmerjevalnika vsebuje pravilen vnos, tako da ve, da mora ta paket poslati na 20.1.1.2. Ob predpostavki, da usmerjevalnik že pozna ciljni naslov MAC, bomo preprosto nadaljevali s posredovanjem paketa. Če tega naslova ne pozna, bo znova zagnal ARP, prejel MAC naslov usmerjevalnika 20.1.1.2 in postopek pošiljanja okvira se bo znova nadaljeval.
Predvidevamo torej, da že pozna naslov MAC, potem bomo imeli izvorni MAC naslov BBB in ciljni MAC naslov CCC. Usmerjevalnik znova izračuna FCS/CRC in ga postavi na začetek okvira.
Ta okvir nato pošlje po omrežju, okvir doseže usmerjevalnik 20.1.12, preveri kontrolno vsoto, se prepriča, da podatki niso poškodovani, in izbriše FCS/CRC. Nato "obreže" naslove MAC, pogleda cilj in vidi, da je 30.1.1.10. Ve, da je ta naslov povezan z njegovim vmesnikom. Isti postopek oblikovanja okvirja se ponovi, usmerjevalnik doda vrednosti izvornega in ciljnega naslova MAC, izvede zgoščevanje, pripne zgoščeno vrednost okvirju in ga pošlje po omrežju.
Naš strežnik, ko končno prejme nanj naslovljeno zahtevo SYN, preveri kontrolno vsoto zgoščene vrednosti in če paket ne vsebuje napak, izbriše zgoščeno vrednost. Nato odstrani naslove MAC, pogleda naslov IP in ugotovi, da je ta paket naslovljen nanj.
Po tem skrajša naslove IP, povezane s tretjo plastjo modela OSI, in pogleda številke vrat.
Vidi vrata 21, kar pomeni promet FTP, vidi SYN in zato razume, da nekdo poskuša komunicirati z njim.
Na podlagi tega, kar smo izvedeli o rokovanju, bo strežnik 30.1.1.10 ustvaril paket SYN/ACK in ga poslal nazaj v računalnik 10.1.1.10. Po prejemu tega paketa bo naprava 10.1.1.10 ustvarila ACK, ga posredovala skozi omrežje na enak način kot paket SYN in ko strežnik prejme ACK, bo povezava vzpostavljena.
Ena stvar, ki jo morate vedeti, je, da se vse to zgodi v manj kot sekundi. To je zelo, zelo hiter proces, ki sem ga poskušal upočasniti, da vam bo vse jasno.
Upam, da vam bo koristno, kar ste se naučili v tej vadnici. Če imate kakršna koli vprašanja, mi pišite na [e-pošta zaščitena] ali pustite vprašanja pod tem videoposnetkom.
Začenši z naslednjo lekcijo, bom izbral 3 najbolj zanimiva vprašanja z YouTuba, ki jih bom pregledal na koncu vsakega videa. Od zdaj naprej bom imel razdelek »Najpogostejša vprašanja«, tako da bom objavil vprašanje skupaj z vašim imenom in nanj odgovoril v živo. Mislim, da bo to koristno.
Hvala, ker ste ostali z nami. So vam všeč naši članki? Želite videti več zanimivih vsebin? Podprite nas tako, da oddate naročilo ali priporočite prijateljem, 30% popust za uporabnike Habr na edinstvenem analogu začetnih strežnikov, ki smo ga izumili za vas: (na voljo z RAID1 in RAID10, do 24 jeder in do 40 GB DDR4).
VPS (KVM) E5-2650 v4 (6 jeder) 10 GB DDR4 240 GB SSD 1 Gbps brezplačno do poletja pri plačilu za obdobje šestih mesecev lahko naročite .
Dell R730xd 2-krat cenejši? Samo tukaj na Nizozemskem! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128 GB DDR3 2x960 GB SSD 1 Gbps 100 TB - od 99 $! Preberite o
Vir: www.habr.com