Áður en við byrjum á kennslumyndbandinu í dag vil ég þakka öllum sem lögðu sitt af mörkum til vinsælda námskeiðsins míns á YouTube. Þegar ég byrjaði á því fyrir um 8 mánuðum síðan bjóst ég ekki við slíkum árangri - í dag hafa 312724 manns skoðað kennsluna mína, ég er með 11208 áskrifendur. Aldrei óraði mig fyrir því að þetta hógværa upphaf myndi ná slíkum hæðum. En við skulum ekki eyða tíma og fara beint í lexíu dagsins. Í dag ætlum við að fylla í eyðurnar sem komu upp í síðustu 7 myndbandskímunum. Þó að dagurinn í dag sé aðeins 6. dagur var dagur 3 sundurliðaður í 3 myndbandstíma, þannig að í dag munt þú í raun horfa á áttundu myndbandstímann.
Í dag munum við fjalla um 3 mikilvæg efni: DHCP, TCP flutning og algengustu gáttarnúmerin. Við höfum þegar talað um IP tölur og einn mikilvægasti þátturinn í uppsetningu IP vistfanga er DHCP.
DHCP stendur fyrir Dynamic Host Configuration Protocol og það er samskiptareglur sem hjálpa til við að stilla IP vistföng fyrir gestgjafa. Svo við höfum öll séð þennan glugga. Þegar þú smellir á valkostinn „Fá sjálfkrafa IP-tölu“ leitar tölvan að DHCP-þjóni sem er stilltur á sama undirneti og sendir ýmsa pakka og beiðnir um IP-tölu. DHCP samskiptareglur eru með 6 skilaboð, þar af 4 sem eru mikilvæg til að úthluta IP tölu.
Fyrstu skilaboðin eru DHCP DISCOVERY skilaboð. DHCP uppgötvunarskilaboðin eru svipuð kveðjuskilaboðum. Þegar nýtt tæki tengist netinu spyr það hvort það sé DHCP þjónn á netinu.
Það sem þú sérð á glærunni lítur út eins og útsendingarbeiðni þar sem tækið hefur samband við öll tæki á netinu í leit að DHCP netþjóni. Eins og ég sagði er þetta útsendingarbeiðni, þannig að öll tæki á netinu heyra það.
Ef það er DHCP netþjónn á netinu sendir hann pakka - DHCP TILBOÐstilboð. Tillaga þýðir að DHCP þjónninn, sem svar við uppgötvunarbeiðni, sendir stillingu til viðskiptavinarins og biður hann um að samþykkja ákveðna IP tölu.
DHCP-þjónninn áskilur sér IP-tölu, í þessu tilfelli 192.168.1.2, gefur það ekki upp, heldur heldur þetta vistfang fyrir tækið. Á sama tíma inniheldur tilboðspakkinn sitt eigið IP-tala DHCP netþjónsins.
Ef það eru fleiri en einn DHCP þjónn á þessu neti, mun annar DHCP þjónn, við móttöku útsendingarbeiðni viðskiptavinarins, einnig bjóða honum IP tölu sína, td 192.168.1.50. Það er ekki algengt að hafa tvo mismunandi DHCP netþjóna stillta á sama neti, en stundum gerist það. Þannig að þegar DHCP tilboð er sent til viðskiptavinar fær hann 2 DHCP tilboð og verður nú að ákveða hvaða DHCP tilboð hann vill samþykkja.
Gerum ráð fyrir að viðskiptavinurinn samþykki fyrstu umsóknina. Þetta þýðir að viðskiptavinurinn sendir beiðni um DHCP REQUEST sem segir bókstaflega "Ég samþykki IP töluna 192.168.1.2 sem DHCP þjónninn 192.168.1.1 býður upp á."
Við móttöku beiðninnar svarar 192.168.1.1 DHCP þjónninn „allt í lagi, ég viðurkenni það,“ það er að segja að hann viðurkennir beiðnina og sendir þetta DHCP ACK til viðskiptavinarins. En við munum að annar DHCP þjónn hefur frátekið IP tölu 1.50 fyrir viðskiptavininn. Þegar það hefur móttekið útsendingarbeiðni viðskiptavinar mun það vita um bilunina og mun setja það IP tölu aftur í laugina svo það geti úthlutað því til annars viðskiptavinar ef það fær aðra beiðni.
Þetta eru 4 mikilvæg skilaboð sem DHCP skiptist á þegar úthlutað er IP-tölum. Næst hefur DHCP 2 fleiri upplýsingaskilaboð. Upplýsingaskilaboð eru gefin út af viðskiptavini ef hann krefst meiri upplýsinga en þær fengu í DHCP TILBOÐSákvæðinu í öðru skrefi. Ef þjónninn gaf ekki nægar upplýsingar í DHCP tilboðinu, eða ef viðskiptavinurinn þarf meiri upplýsingar en þær sem voru í tilboðspakkanum, biður hann um frekari DHCP upplýsingar. Það eru enn ein skilaboðin sem viðskiptavinurinn sendir til þjónsins - þetta er DHCP LEYSA. Það upplýsir þig um að viðskiptavinurinn vilji gefa út núverandi IP tölu sína.
Hins vegar, það sem oftast gerist er að notandinn aftengir sig frá netinu áður en viðskiptavinurinn hefur tíma til að senda DHCP RELEASE á netþjóninn. Þetta gerist þegar þú slekkur á tölvunni, sem við gerum. Í þessu tilviki hefur netþjónninn, eða tölvan, einfaldlega ekki tíma til að láta þjóninn vita um að gefa út notað heimilisfang, svo DHCP RELEASE er ekki nauðsynlegt skref. Nauðsynleg skref til að fá IP tölu eru: DHCP uppgötvun, DHCP tilboð, DHCP beiðni og DHCP handabandi.
Í einni af næstu kennslustundum mun ég segja þér hvernig við stillum DHCP miðlara þegar búið er til DNCP laug. Með sameiningu er átt við að þú segir þjóninum að úthluta IP tölum á bilinu 192.168.1.1 til 192.168.1.254. Þannig mun DHCP þjónninn búa til laug, setja 254 IP vistföng í hana og geta úthlutað vistföngum til viðskiptavina á netinu eingöngu úr þessari laug. Svo þetta er eitthvað eins og stjórnunarstilling sem notandinn getur gert.
Nú skulum við líta á TCP sendingu. Ég veit ekki hvort þú þekkir "símann" sem er á myndinni, en þegar við vorum krakkar notuðum við þessar blikkdósir tengdar með streng til að tala saman.
Því miður hefur kynslóð nútímans ekki efni á slíkum „lúxus“. Ég meina í dag eru krakkar fyrir framan sjónvarpið frá eins árs aldri, þau spila PSP og það er kannski umdeilanlegt en ég held að við áttum bestu æskuna, við fórum í raun út og spiluðum leiki og það er ekki hægt að draga börn dagsins í burtu úr sófanum .
Sonur minn er bara ársgamall og ég sé nú þegar að hann er háður iPad, ég meina hann er enn mjög ungur en ég held að börn í dag séu þegar fædd og kunna að meðhöndla rafeindagræjur. Svo ég vildi segja að þegar við lékum okkur sem börn myndum við gera göt á blikkdósir, og þegar við bundum þær með bandi og sögðum eitthvað í eina dós, þá heyrði manneskjan á hinum endanum hvað var sagt. til hans, einfaldlega með því að setja dósina að eyranu á honum. Svo það er mjög svipað og nettengingu.
Í dag þurfa jafnvel TCP-flutningar að vera með tengingu sem þarf að koma á áður en raunverulegur gagnaflutningur hefst. Eins og við ræddum í fyrri kennslustundum er TCP tengimiðuð sending á meðan UDP er tengimiðuð sending. Það má segja að UDP sé þar sem ég kasta boltanum og það er undir þér komið að sjá hvort þú náir honum. Hvort sem þú ert tilbúinn að gera það eða ekki er ekki mitt vandamál, ég ætla bara að fara frá honum.
TCP er meira eins og þú talar við gaur og varar hann fyrirfram við því að þú sért að fara að kasta bolta, þannig að þú myndar tengsl og kastar svo boltanum þannig að félagi þinn sé líklegri til að ná honum. Þannig að TCP byggir í raun upp tenginguna og byrjar síðan að framkvæma sendinguna.
Við skulum skoða hvernig það skapar slíka tengingu. Þessi samskiptaregla notar 3-vega handabandi til að búa til tengingu. Þetta er ekki mjög tæknilegt hugtak, en það hefur lengi verið notað til að lýsa TCP tengingu. Þriggja-átta handaband er hafið af senditækinu, þar sem viðskiptavinurinn sendir pakka með SYN fána til þjónsins.
Segjum að stúlkan í forgrunni, sem við sjáum andlitið á, sé tæki A, og stúlkan í bakgrunni, þar sem andlit hennar sést ekki, sé tæki B. Stúlka A sendir SYN pakka til stúlku B og hún segir: „frábært, hver- þá vill hann eiga samskipti við mig. Svo ég þarf að svara því að ég er tilbúinn til að hafa samskipti!“ Hvernig á að gera það? Maður gæti einfaldlega sent aftur annan SYN pakka og síðan ACK sem gefur til kynna móttöku á upprunalega SYN pakkanum. En í stað þess að senda ACK sérstaklega, myndar þjónninn sameiginlegan pakka sem inniheldur SYN og ACK og sendir það yfir netið.
Svo á þessum tímapunkti hefur tæki A sent SYN pakka og fengið til baka SYN/ACK pakka. Nú þarf tæki A að senda tæki B ACK pakka, það er að segja að það hafi fengið samþykki frá tæki B til að koma á samskiptum. Þannig fengu bæði tækin SYN og ACK pakka og nú getum við sagt að tengingunni hafi verið komið á, það er að segja að 3 þrepa handaband hafi verið lokið með TCP samskiptareglum.
Næst munum við skoða TCP Windowing tækni. Einfaldlega sagt, það er aðferð sem notuð er í TCP / IP til að semja um getu sendanda og móttakanda.
Segjum að í Windows séum við að reyna að flytja stóra skrá, segjum 2 GB að stærð, frá einu drifi til annars. Strax í upphafi flutnings mun kerfið tilkynna okkur að skráaflutningurinn muni taka um það bil 1 ár. En nokkrum sekúndum síðar mun kerfið leiðrétta sig og segja: "ó, bíddu aðeins, ég held að það taki um 6 mánuði, ekki ár." Aðeins meiri tími mun líða og Windows mun segja: "Ég held að ég gæti flutt skrána eftir 1 mánuð." Þessu fylgja skilaboðin "1 dagur", "6 klst", "3 klst", "1 klst", "20 mínútur", "10 mínútur", "3 mínútur". Reyndar mun allt skráaflutningsferlið aðeins taka 3 mínútur. Hvernig gerðist þetta? Í upphafi, þegar tækið þitt reynir að eiga samskipti við annað tæki, sendir það einn pakka og bíður eftir staðfestingu. Ef tækið bíður lengi eftir staðfestingu hugsar það: „ef ég þarf að flytja 2 GB af gögnum á þessum hraða mun það taka um 2 ár. Eftir nokkurn tíma fær tækið þitt ACK og hugsar, „allt í lagi, ég sendi einn pakka og fékk ACK, þess vegna getur viðtakandinn fengið 1 pakka. Nú ætla ég að reyna að senda honum 10 pakka í staðinn fyrir einn.“ Sendandi sendir 10 pakka og fær eftir nokkurn tíma ACK staðfestingu frá móttökutækinu sem þýðir að viðtakandinn bíður eftir næsta, 11. pakka. Sendandi hugsar: „frábært, þar sem viðtakandinn meðhöndlaði 10 pakka í einu, núna ætla ég að reyna að senda honum 100 pakka í stað tíu. Hann sendir 100 pakka og viðtakandinn svarar að hann hafi fengið þá og bíði nú eftir 101 pakka. Þannig eykst fjöldi sendra pakka með tímanum.
Þetta er ástæðan fyrir því að þú sérð hröð lækkun á afritunartíma skráar miðað við það sem upphaflega var gefið upp - þetta er vegna aukinnar getu til að flytja mikið magn af gögnum. Hins vegar kemur að því að frekari aukning á flutningsmagni verður ómöguleg. Segjum að þú hafir sent 10000 pakka en biðminni tækis móttakarans getur aðeins tekið við 9000. Í þessu tilviki sendir viðtakandinn ACK með skilaboðunum: "Ég hef fengið 9000 pakka og er nú tilbúinn til að taka á móti 9001." Af þessu dregur sendandinn þá ályktun að biðminni viðtökutækisins rúmi aðeins 9000, sem þýðir að héðan í frá mun ég ekki senda meira en 9000 pakka í einu. Í þessu tilviki reiknar sendandinn fljótt út þann tíma sem það mun taka hann að flytja það sem eftir er af gagnamagni í skömmtum af 9000 pökkum og gefur 3 mínútur. Þessar þrjár mínútur eru raunverulegur sendingartími. Það er það sem TCP Windowing gerir.
Þetta er ein af þessum umferðarþrengslum þar sem senditækið skilur að lokum hver raunveruleg netgeta er. Þú gætir verið að velta fyrir þér hvers vegna þeir geta ekki komið sér saman fyrirfram um hver getu móttökutækisins er? Staðreyndin er sú að þetta er tæknilega ómögulegt vegna þess að það eru mismunandi gerðir af tækjum á netinu. Segjum að þú sért með iPad og hann er með annan gagnaflutnings-/móttakarahraða en iPhone, þú gætir átt mismunandi gerðir af símum eða kannski með mjög gamla tölvu. Þess vegna hafa allir mismunandi netbandbreidd.
Þess vegna var TCP Windowing tækni þróuð, þegar gagnaflutningur hefst á lágum hraða eða með sendingu á lágmarksfjölda pakka, sem eykur smám saman umferðar "gluggann". Þú sendir einn pakka, 5 pakka, 10 pakka, 1000 pakka, 10000 pakka og opnar þann glugga hægt og rólega meira og meira þar til „opnunin“ nær hámarks mögulegum umferðarmagni sem send er á tilteknu tímabili. Þannig er hugtakið Windowing hluti af rekstri TCP samskiptareglunnar.
Næst munum við skoða algengustu gáttanúmerin. Klassíska ástandið er þegar þú ert með 1 aðalþjón, kannski gagnaver. Það inniheldur skráarþjón, vefþjón, póstþjón og DHCP miðlara. Nú, ef ein af biðlaratölvunum hefur samband við gagnaverið, sem er staðsett í miðri myndinni, mun það byrja að senda skráaþjónaumferð til viðskiptavinartækja. Þessi umferð er sýnd með rauðu og verður send á tilteknu tengi fyrir tiltekið forrit frá tilteknum netþjóni.
Hvernig vissi þjónninn hvert ákveðin umferð ætti að fara? Hann lærir þetta af númeri áfangastaðshafnar. Ef þú skoðar rammann þá sérðu að í hverjum gagnaflutningi er getið um áfangagáttarnúmer og upprunahafnarnúmer. Þú getur séð að bláa og rauða umferðin, og bláa umferðin er umferð á vefþjónum, fara báðir á sama líkamlega netþjóninn, sem er með mismunandi netþjóna uppsetta. Ef þetta er gagnaver, þá notar það sýndarþjóna. Svo hvernig vissu þeir að rauða umferðin átti að fara aftur til vinstri fartölvunnar með þessa IP tölu? Þeir vita þetta þökk sé gáttanúmerum. Ef þú vísar í Wikipedia greinina „Listi yfir TCP og UDP höfn“ muntu sjá að hún sýnir öll stöðluð gáttanúmer.
Ef þú flettir niður þessa síðu geturðu séð hversu stór þessi listi er. Það inniheldur um það bil 61 númer. Gáttarnúmer frá 000 til 1 eru þekkt sem algengustu gáttarnúmerin. Til dæmis er port 1024/TCP til að senda ftp skipanir, port 21 er fyrir ssh, port 22 er fyrir Telnet, það er til að senda ódulkóðuð skilaboð. Hin mjög vinsæla höfn 23 flytur gögn yfir HTTP, en höfn 80 flytur dulkóðuð gögn yfir HTTPS, sem er svipað og örugga útgáfan af HTTP.
Sumar tengi eru tileinkaðar bæði TCP og UDP og sumar framkvæma mismunandi verkefni eftir því hvort tengingin er TCP eða UDP. Svo, opinberlega er TCP tengi 80 notað fyrir HTTP og óopinberlega er UDP tengi 80 notað fyrir HTTP, en undir annarri HTTP samskiptareglu - QUIC.
Þess vegna er gáttanúmerum í TCP ekki alltaf ætlað að gera það sama og í UDP. Þú þarft ekki að læra þennan lista utanbókar, það er ómögulegt að muna það, en þú þarft að kunna nokkur vinsæl og algengustu portnúmer. Eins og ég sagði hafa sumar þessara hafna opinberan tilgang, sem lýst er í stöðlunum, og sumar hafa óopinberan tilgang, eins og er með Chromium.
Svo, þessi tafla sýnir öll algeng gáttarnúmer og þessi númer eru notuð til að senda og taka á móti umferð þegar tiltekin forrit eru notuð.
Nú skulum við skoða hvernig gögn flytjast yfir netið út frá þeim litlu upplýsingum sem við vitum. Segjum að tölva 10.1.1.10 vilji hafa samband við þessa tölvu, eða þennan netþjón, sem hefur heimilisfangið 30.1.1.10. Fyrir neðan IP tölu hvers tækis er MAC vistfang þess. Ég er að gefa dæmi um MAC vistfang með aðeins síðustu 4 stöfunum, en í reynd er það 48-bita sextánda tölu með 12 stöfum. Þar sem hver af þessum tölum samanstendur af 4 bitum, tákna 12 sextánstafir 48 bita tölu.
Eins og við vitum, ef þetta tæki vill hafa samband við þennan netþjón, verður fyrsta skrefið í 3-vega handabandi að gera fyrst, það er að senda SYN pakka. Þegar þessi beiðni er gerð mun tölva 10.1.1.10 tilgreina upprunagáttarnúmerið, sem Windows býr til á virkan hátt. Windows velur af handahófi gáttarnúmer á milli 1 og 65,000. En þar sem upphafstölur á bilinu 1 til 1024 eru víða þekktar, mun kerfið í þessu tilfelli líta á tölur sem eru stærri en 25000 og búa til handahófskennda upprunagátt, til dæmis númer 25113.
Næst mun kerfið bæta áfangastað við pakkann, í þessu tilfelli er það port 21, vegna þess að forritið sem er að reyna að tengjast þessum FTP netþjóni veit að það ætti að senda FTP umferð.
Næst segir tölvan okkar: „Allt í lagi, IP-talan mín er 10.1.1.10 og ég þarf að hafa samband við IP-töluna 30.1.1.10.“ Bæði þessi vistföng eru einnig innifalin í pakkanum til að mynda SYN beiðni, og þessi pakki mun ekki breytast fyrr en í lok tengingarinnar.
Ég vil að þú skiljir af þessu myndbandi hvernig gögn berast yfir netið. Þegar tölvan okkar sem sendir beiðnina sér uppruna-IP-tölu og IP-tölu áfangastað, skilur hún að áfangastaðfangið er ekki á því staðarneti. Ég gleymdi að segja að þetta eru allt /24 IP tölur. Þannig að ef þú skoðar /24 IP vistföngin muntu átta þig á því að tölvur 10.1.1.10 og 30.1.1.10 eru ekki á sama neti. Þannig skilur tölvan sem sendir beiðnina að til að yfirgefa þetta net verður hún að hafa samband við 10.1.1.1 gáttina, sem er stillt á einu af viðmótum beinisins. Það veit að það ætti að fara í 10.1.1.1 og veit MAC vistfangið 1111, en veit ekki MAC vistfang gáttarinnar 10.1.1.1. Hvað er hann að gera? Það sendir útsendingar ARP beiðni sem öll tæki á netinu munu fá, en aðeins beininn með IP tölu 10.1.1.1 mun svara henni.
Bein mun bregðast við með AAAA MAC vistfangi sínu, og bæði uppruna- og áfangastað MAC vistföng verða einnig sett í þennan ramma. Þegar ramminn er tilbúinn, verður CRC gagnaheilleikaathugun, sem er reiknirit til að finna eftirlitssummu til að greina villur, framkvæmd áður en netið er yfirgefið.
Cyclic Redundancy CRC þýðir að allur ramminn, frá SYN til síðasta MAC vistfangs, er keyrður í gegnum hashing reiknirit, til dæmis MD5, sem leiðir til kjötkássagildis. Hash-gildið, eða MD5 checksum, er síðan sett í byrjun rammans.
Ég merkti það FCS/CRC vegna þess að FCS er Frame Check Sequence, fjögurra bæta CRC gildi. Sumir nota heitið FCS og sumir nota heitið CRC, svo ég lét bara báðar tilnefningarnar fylgja með. En í grundvallaratriðum er þetta bara kjötkássagildi. Það er nauðsynlegt til að ganga úr skugga um að öll gögn sem berast um netið innihaldi ekki villur. Þess vegna, þegar þessi rammi nær til beinisins, er það fyrsta sem beinirinn gerir að reikna út eftirlitssumman sjálfan og bera hana saman við FCS eða CRC gildið sem móttekinn rammi inniheldur. Þannig getur hann athugað hvort gögnin sem berast um netið innihaldi ekki villur, eftir það mun hann fjarlægja eftirlitssumman úr rammanum.
Næst mun leiðin skoða MAC vistfangið og segja, „Allt í lagi, MAC vistfang AAAA þýðir að ramminn er stílaður á mig,“ og eyða þeim hluta rammans sem inniheldur MAC vistföngin.
Þegar hann horfir á IP-tölu áfangastaðarins 30.1.1.10 mun hann skilja að þessi pakki er ekki stílaður á hann og verður að fara lengra í gegnum beininn.
Nú „heldur“ beininn að hann þurfi að sjá hvar netið með heimilisfangið 30.1.1.10 er staðsett. Við höfum ekki farið yfir heildarhugmyndina um leið ennþá, en við vitum að beinar eru með leiðartöflu. Þessi tafla er með færslu fyrir netið með heimilisfanginu 30.1.1.0. Eins og þú manst er þetta ekki IP-tölu gestgjafans heldur netauðkennið. Beininn mun „helda“ að hann geti náð heimilisfanginu 30.1.1.0/24 með því að fara í gegnum beini 20.1.1.2.
Þú gætir spurt, hvernig veit hann þetta? Hafðu bara í huga að það mun vita þetta annað hvort frá leiðarsamskiptareglum eða frá stillingum þínum ef þú sem stjórnandi hefur stillt kyrrstæða leið. En í öllum tilvikum inniheldur leiðartafla þessa leiðar rétta færslu, svo það veit að það ætti að senda þennan pakka til 20.1.1.2. Að því gefnu að leiðin viti nú þegar MAC-tölu áfangastaðarins munum við einfaldlega halda áfram að senda pakkann áfram. Ef hann veit ekki þetta heimilisfang mun hann ræsa ARP aftur, fá MAC vistfang beinisins 20.1.1.2 og ferlið við að senda rammann mun halda áfram aftur.
Svo við gerum ráð fyrir að það viti nú þegar MAC vistfangið, þá munum við hafa BBB uppruna MAC vistfang og CCC áfangastað MAC vistfang. Beininn reiknar aftur FCS/CRC og setur það í byrjun rammans.
Það sendir síðan þennan ramma yfir netið, ramminn nær til beini 20.1.12, hann athugar eftirlitssumman, tryggir að gögnin séu ekki skemmd og eyðir FCS/CRC. Það „stýrir“ síðan MAC vistföngin, skoðar áfangastaðinn og sér að hann er 30.1.1.10. Hann veit að þetta heimilisfang er tengt viðmótinu hans. Sama rammamyndunarferlið er endurtekið, beininn bætir við uppruna- og áfangastað MAC vistfangsgildum, gerir kjötkássa, festir kjötkássa við rammann og sendir það yfir netið.
Miðlarinn okkar, eftir að hafa loksins fengið SYN beiðnina sem beint er til hans, athugar kjötkássatöluna og ef pakkinn inniheldur ekki villur eyðir hann kjötkássa. Svo fjarlægir hann MAC vistföngin, horfir á IP töluna og áttar sig á því að þessi pakki er stílaður á hann.
Eftir það styttir það IP tölurnar sem tengjast þriðja lagi OSI líkansins og skoðar gáttanúmerin.
Hann sér port 21, sem þýðir FTP umferð, sér SYN og skilur því að einhver er að reyna að hafa samband við hann.
Nú, byggt á því sem við lærðum um handabandið, mun þjónn 30.1.1.10 búa til SYN/ACK pakka og senda hann aftur í tölvuna 10.1.1.10. Við móttöku þessa pakka mun tæki 10.1.1.10 búa til ACK, senda það í gegnum netið á sama hátt og SYN pakki, og eftir að þjónninn fær ACK verður tengingunni komið á.
Eitt sem þú ættir að vita er að þetta gerist allt á innan við sekúndu. Þetta er mjög, mjög hratt ferli sem ég reyndi að hægja á svo að allt sé á hreinu.
Ég vona að þér finnist það sem þú lærðir í þessari kennslu gagnlegt. Ef þú hefur einhverjar spurningar, vinsamlegast skrifaðu mér á [netvarið] eða skildu eftir spurningar undir þessu myndbandi.
Frá og með næstu kennslustund mun ég velja 3 áhugaverðustu spurningarnar af YouTube, sem ég mun fara yfir í lok hvers myndbands. Héðan í frá mun ég hafa hlutann „Helstu spurningar“ svo ég mun senda inn spurningu ásamt nafni þínu og svara henni í beinni. Ég held að þetta verði til bóta.
Þakka þér fyrir að vera hjá okkur. Líkar þér við greinarnar okkar? Viltu sjá meira áhugavert efni? Styðjið okkur með því að leggja inn pöntun eða mæla með því við vini, 30% afsláttur fyrir Habr notendur á einstökum hliðstæðum upphafsþjónum, sem var fundið upp af okkur fyrir þig: (fáanlegt með RAID1 og RAID10, allt að 24 kjarna og allt að 40GB DDR4).
VPS (KVM) E5-2650 v4 (6 kjarna) 10GB DDR4 240GB SSD 1Gbps ókeypis fram á sumar þegar greitt er fyrir sex mánaða tímabil er hægt að panta .
Dell R730xd 2 sinnum ódýrari? Aðeins hér í Hollandi! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - frá $99! Lestu um
Heimild: www.habr.com