Cyn i ni ddechrau tiwtorial fideo heddiw, rwyf am ddiolch i bawb a gyfrannodd at boblogrwydd fy nghwrs ar YouTube. Pan ddechreuais i tua 8 mis yn ôl, nid oeddwn yn disgwyl y fath lwyddiant - heddiw mae 312724 o bobl wedi gweld fy ngwersi, mae gen i 11208 o danysgrifwyr. Ni freuddwydiais erioed y byddai'r dechreuad gostyngedig hwn yn cyrraedd y fath uchelfannau. Ond gadewch i ni beidio â gwastraffu amser a mynd yn syth at y wers heddiw. Heddiw byddwn yn llenwi'r bylchau a ddigwyddodd yn y 7 gwers fideo ddiwethaf. Er mai dim ond diwrnod 6 yw heddiw, cafodd diwrnod 3 ei rannu'n 3 gwers fideo, felly heddiw byddwch chi'n gwylio'r wythfed wers fideo mewn gwirionedd.
Heddiw byddwn yn ymdrin â 3 phwnc pwysig: DHCP, trafnidiaeth TCP, a'r niferoedd porthladd mwyaf cyffredin. Rydym eisoes wedi siarad am gyfeiriadau IP, ac un o'r ffactorau pwysicaf mewn cyfluniad cyfeiriad IP yw DHCP.
Mae DHCP yn sefyll am Brotocol Ffurfweddu Gwesteiwr Dynamig ac mae'n brotocol sy'n helpu i ffurfweddu cyfeiriadau IP yn ddeinamig ar gyfer gwesteiwyr. Felly rydyn ni i gyd wedi gweld y ffenestr hon. Pan gliciwch ar yr opsiwn “Cael cyfeiriad IP yn awtomatig”, mae'r cyfrifiadur yn edrych am weinydd DHCP sydd wedi'i ffurfweddu ar yr un is-rwydwaith ac yn anfon pecynnau a cheisiadau amrywiol am y cyfeiriad IP. Mae gan brotocol DHCP 6 neges, ac mae 4 ohonynt yn hanfodol ar gyfer aseinio cyfeiriad IP.
Y neges gyntaf yw neges DARGANFOD DHCP. Mae neges ddarganfod DHCP yn debyg i neges gyfarch. Pan fydd dyfais newydd yn ymuno â'r rhwydwaith, mae'n gofyn a oes gweinydd DHCP ar y rhwydwaith.
Mae'r hyn a welwch yn y sleid yn edrych fel cais darlledu lle mae'r ddyfais yn cysylltu â phob dyfais ar y rhwydwaith yn chwilio am weinydd DHCP. Fel y dywedais, mae hwn yn gais darlledu, felly gall pob dyfais ar y rhwydwaith ei glywed.
Os oes gweinydd DHCP ar y rhwydwaith, mae'n anfon pecyn - cynnig CYNNIG DHCP. Mae cynnig yn golygu bod y gweinydd DHCP, mewn ymateb i gais darganfod, yn anfon ffurfweddiad at y cleient, gan ofyn i'r cleient dderbyn cyfeiriad IP penodol.
Mae'r gweinydd DHCP yn cadw cyfeiriad IP, yn yr achos hwn 192.168.1.2, nid yw'n ei ddarparu, ond yn hytrach yn cadw'r cyfeiriad hwn ar gyfer y ddyfais. Ar yr un pryd, mae'r pecyn cynnig yn cynnwys ei gyfeiriad IP ei hun o'r gweinydd DHCP.
Os oes mwy nag un gweinydd DHCP ar y rhwydwaith hwn, byddai gweinydd DHCP arall, ar ôl derbyn cais darlledu'r cleient, hefyd yn cynnig ei gyfeiriad IP iddo, er enghraifft, 192.168.1.50. Nid yw'n gyffredin cael dau weinydd DHCP gwahanol wedi'u ffurfweddu ar yr un rhwydwaith, ond weithiau mae'n digwydd. Felly pan fydd cynnig DHCP yn cael ei anfon at gleient, mae'n derbyn 2 gynnig DHCP a rhaid iddo nawr benderfynu pa gynnig DHCP y mae am ei dderbyn.
Gadewch i ni dybio bod y cleient yn derbyn y cais cyntaf. Mae hyn yn golygu bod y cleient yn anfon cais CAIS DHCP sy'n dweud yn llythrennol "Rwy'n derbyn y cyfeiriad IP 192.168.1.2 a gynigir gan y gweinydd DHCP 192.168.1.1."
Ar ôl derbyn y cais, mae gweinydd DHCP 192.168.1.1 yn ymateb “iawn, rwy'n ei gyfaddef,” hynny yw, mae'n cydnabod y cais ac yn anfon y DHCP ACK hwn at y cleient. Ond cofiwn fod gweinydd DHCP arall wedi cadw cyfeiriad IP o 1.50 ar gyfer y cleient. Unwaith y bydd yn derbyn cais darlledu cleient, bydd yn gwybod am y methiant a bydd yn rhoi'r cyfeiriad IP hwnnw yn ôl i'r pwll fel y gall ei aseinio i gleient arall os bydd yn derbyn cais arall.
Dyma'r 4 neges hollbwysig y mae DHCP yn eu cyfnewid wrth aseinio cyfeiriadau IP. Nesaf, mae gan DHCP 2 neges arall o wybodaeth. Cyhoeddir neges wybodaeth gan y cleient os oes angen mwy o wybodaeth arno nag a gafodd yng nghymal CYNNIG DHCP yn yr ail gam. Os na ddarparodd y gweinydd ddigon o wybodaeth yn y cynnig DHCP, neu os oes angen mwy o wybodaeth ar y cleient na'r hyn a oedd wedi'i gynnwys yn y pecyn cynnig, mae'n gofyn am wybodaeth DHCP ychwanegol. Mae un neges arall y mae'r cleient yn ei hanfon at y gweinydd - dyma'r RHYDDHAU DHCP. Mae'n eich hysbysu bod y cleient am ryddhau ei gyfeiriad IP presennol.
Fodd bynnag, yr hyn sy'n digwydd amlaf yw bod y defnyddiwr yn datgysylltu o'r rhwydwaith cyn i'r cleient gael amser i anfon DATGANIAD DHCP i'r gweinydd. Mae hyn yn digwydd pan fyddwch chi'n diffodd y cyfrifiadur, rydyn ni'n ei wneud. Yn yr achos hwn, nid oes gan y cleient rhwydwaith, neu gyfrifiadur, amser i hysbysu'r gweinydd i ryddhau'r cyfeiriad a ddefnyddir, felly nid yw DHCP RELEASE yn gam gofynnol. Y camau gofynnol i gael cyfeiriad IP yw: darganfod DHCP, cynnig DHCP, cais DHCP, ac ysgwyd llaw DHCP.
Yn un o'r gwersi nesaf byddaf yn dweud wrthych sut yr ydym yn ffurfweddu gweinydd DHCP wrth greu cronfa DNCP. Wrth gyfuno, rydym yn golygu eich bod yn dweud wrth y gweinydd i neilltuo cyfeiriadau IP yn yr ystod 192.168.1.1 i 192.168.1.254. Felly, bydd y gweinydd DHCP yn creu cronfa, yn gosod 254 o gyfeiriadau IP ynddo, ac yn gallu neilltuo cyfeiriadau i gleientiaid ar y rhwydwaith o'r gronfa hon yn unig. Felly mae hyn yn rhywbeth fel gosodiad gweinyddol y gall y defnyddiwr ei wneud.
Nawr, gadewch i ni edrych ar drosglwyddiad TCP. Wn i ddim a ydych chi'n gyfarwydd â'r "ffôn" yn y llun, ond pan oedden ni'n blant roedden ni'n arfer defnyddio'r caniau tun hyn wedi'u cysylltu gan linyn i siarad â'n gilydd.
Yn anffodus, ni all cenhedlaeth heddiw fforddio “moethusrwydd” o'r fath. Rwy'n golygu heddiw bod plant o flaen y teledu o flwydd oed, maen nhw'n chwarae PSP ac efallai bod hyn yn ddadleuol ond rwy'n credu mai ni oedd y plentyndod gorau, aethon ni allan i chwarae gemau ac ni ellir tynnu plant heddiw o'r soffa .
Dim ond blwydd oed yw fy mab a gallaf weld yn barod ei fod yn gaeth i'r iPad, rwy'n golygu ei fod yn dal yn ifanc iawn ond credaf fod plant heddiw eisoes wedi'u geni yn gwybod sut i drin teclynnau electronig. Felly, roeddwn i eisiau dweud fel plant, pan fydden ni'n chwarae, y bydden ni'n gwneud tyllau mewn caniau tun, a phan fydden ni'n eu clymu â chortyn ac yn dweud rhywbeth i mewn i un can, yna ar y pen arall roedd y person yn gallu clywed beth oedd yn cael ei ddweud. iddo, yn syml trwy roi y can i'w glust . Felly mae'n debyg iawn i gysylltiad rhwydwaith.
Heddiw, rhaid i hyd yn oed trosglwyddiadau TCP gael cysylltiad y mae'n rhaid ei sefydlu cyn i'r trosglwyddiad data gwirioneddol ddechrau. Fel y trafodwyd mewn gwersi blaenorol, mae TCP yn drosglwyddiad sy'n canolbwyntio ar gysylltiad tra bod CDU yn drosglwyddiad sy'n canolbwyntio ar gysylltiad. Fe allech chi ddweud mai CDU yw lle rydw i'n taflu'r bêl a chi sydd i benderfynu a allwch chi ei dal. Nid yw p'un a ydych chi'n barod i'w wneud ai peidio yn broblem i mi, rydw i'n mynd i'w adael.
Mae TCP yn debycach i chi siarad â dyn a'i rybuddio ymlaen llaw eich bod chi'n mynd i daflu pêl, felly rydych chi'n ffurfio bond, ac yna rydych chi'n taflu'r bêl fel bod eich partner yn fwy tebygol o fod yn barod i'w dal. Felly mae TCP mewn gwirionedd yn adeiladu'r cysylltiad ac yna'n dechrau gwneud y trosglwyddiad gwirioneddol.
Gadewch i ni edrych ar sut mae'n creu cysylltiad o'r fath. Mae'r protocol hwn yn defnyddio ysgwyd llaw 3-ffordd i greu cysylltiad. Nid yw hwn yn derm technegol iawn, ond fe'i defnyddiwyd ers tro i ddisgrifio cysylltiad TCP. Mae ysgwyd llaw 3-ffordd yn cael ei gychwyn gan y ddyfais anfon, gyda'r cleient yn anfon pecyn gyda baner SYN i'r gweinydd.
Gadewch i ni ddweud mai dyfais A yw'r ferch yn y blaendir, y mae ei hwyneb yn gallu gweld, a'r ferch yn y cefndir, nad yw ei hwyneb yn weladwy, yw dyfais B. Mae merch A yn anfon pecyn SYN at ferch B, a dywed: “gwych, pwy- wedyn mae am gyfathrebu â mi. Felly, mae angen i mi ateb fy mod yn barod i gyfathrebu!” Sut i'w wneud? Gallai un anfon pecyn SYN arall yn ôl ac yna ACK yn nodi derbyn y pecyn SYN gwreiddiol. Ond yn lle anfon ACKs ar wahân, mae'r gweinydd yn ffurfio pecyn cyffredin sy'n cynnwys y SYN ac ACK ac yn ei drosglwyddo dros y rhwydwaith.
Felly ar y pwynt hwn, mae dyfais A wedi anfon pecyn SYN ac wedi derbyn pecyn SYN/ACK yn ôl. Nawr mae'n rhaid i ddyfais A anfon pecyn ACK i ddyfais B, hynny yw, cadarnhau ei bod wedi cael caniatâd dyfais B i sefydlu cyfathrebu. Felly, derbyniodd y ddau ddyfais becynnau SYN ac ACK, a nawr gallwn ddweud bod y cysylltiad wedi'i sefydlu, hynny yw, mae ysgwyd llaw 3-cam wedi'i gwblhau gan ddefnyddio'r protocol TCP.
Nesaf byddwn yn edrych ar dechnoleg TCP Windowing. Yn syml, mae'n ddull a ddefnyddir yn TCP/IP i drafod galluoedd yr anfonwr a'r derbynnydd.
Gadewch i ni ddweud ein bod yn Windows yn ceisio trosglwyddo ffeil fawr, dyweder 2 GB o faint, o un gyriant i'r llall. Ar ddechrau'r trosglwyddiad, bydd y system yn rhoi gwybod i ni y bydd trosglwyddo'r ffeil yn cymryd tua blwyddyn. Ond ychydig eiliadau yn ddiweddarach bydd y system yn cywiro ei hun ac yn dweud: “O, arhoswch funud, rwy’n meddwl y bydd yn cymryd tua 1 mis, nid blwyddyn.” Bydd ychydig mwy o amser yn mynd heibio a bydd Windows yn dweud: “Rwy’n meddwl efallai y byddaf yn gallu trosglwyddo’r ffeil mewn 6 mis.” Dilynir hyn gan y neges “1 diwrnod”, “1 awr”, “6 awr”, “3 awr”, “1 munud”, “20 munud”, “10 munud”. Mewn gwirionedd, dim ond 3 munud y bydd y broses trosglwyddo ffeil gyfan yn ei gymryd. Sut digwyddodd hyn? I ddechrau, pan fydd eich dyfais yn ceisio cyfathrebu â dyfais arall, mae'n anfon un pecyn ac yn aros am gadarnhad. Os yw'r ddyfais yn aros am amser hir am gadarnhad, mae'n meddwl: "os oes rhaid i mi drosglwyddo 3 GB o ddata ar y cyflymder hwn, bydd yn cymryd tua 2 flynedd." Ar ôl peth amser, mae'ch dyfais yn derbyn ACK ac yn meddwl, “iawn, anfonais un pecyn a derbyn ACK, felly gall y derbynnydd dderbyn 2 pecyn. Nawr byddaf yn ceisio anfon 1 pecyn ato yn lle un. ” Mae'r anfonwr yn anfon 10 pecyn ac ar ôl peth amser yn derbyn cadarnhad ACK gan y ddyfais sy'n derbyn, sy'n golygu bod y derbynnydd yn aros am y pecyn nesaf, 10eg. Mae’r anfonwr yn meddwl: “gwych, gan fod y derbynnydd wedi trin 11 pecyn ar unwaith, nawr byddaf yn ceisio anfon 10 pecyn ato yn lle deg.” Mae'n anfon 100 o becynnau, ac mae'r derbynnydd yn ymateb iddo eu derbyn a'i fod nawr yn aros am 100 o becynnau. Felly, dros amser, mae nifer y pecynnau a drosglwyddir yn cynyddu.
Dyma pam rydych chi'n gweld gostyngiad cyflym mewn amser copïo ffeiliau o'i gymharu â'r hyn a nodwyd yn wreiddiol - mae hyn oherwydd y gallu cynyddol i drosglwyddo symiau mawr o ddata. Fodd bynnag, daw pwynt pan fydd cynnydd pellach yn y cyfaint trawsyrru yn dod yn amhosibl. Dywedwch eich bod wedi anfon 10000 o becynnau, ond dim ond 9000 y gall byffer dyfais y derbynnydd eu derbyn.Yn yr achos hwn, mae'r derbynnydd yn anfon ACK gyda'r neges: "Rwyf wedi derbyn 9000 o becynnau ac rwyf bellach yn barod i dderbyn 9001." O hyn, daw'r anfonwr i'r casgliad mai dim ond 9000 o gapasiti sydd gan glustogi'r ddyfais sy'n derbyn, sy'n golygu na fyddaf yn anfon mwy na 9000 o becynnau ar y tro o hyn ymlaen. Yn yr achos hwn, mae'r anfonwr yn cyfrifo'n gyflym yr amser y bydd yn ei gymryd iddo drosglwyddo'r swm sy'n weddill o ddata mewn dognau o 9000 o becynnau, ac yn rhoi 3 munud. Y tair munud hyn yw'r amser trosglwyddo gwirioneddol. Dyna beth mae TCP Windowing yn ei wneud.
Dyma un o'r mecanweithiau sbarduno traffig hynny lle mae'r ddyfais anfon yn y pen draw yn deall beth yw capasiti gwirioneddol y rhwydwaith. Efallai eich bod yn pendroni pam na allant gytuno ymlaen llaw ar beth yw cynhwysedd y ddyfais derbyn? Y ffaith yw bod hyn yn dechnegol amhosibl oherwydd bod gwahanol fathau o ddyfeisiau ar y rhwydwaith. Gadewch i ni ddweud bod gennych chi iPad ac mae ganddo gyflymder trosglwyddo data / derbynnydd gwahanol nag iPhone, efallai bod gennych chi wahanol fathau o ffonau, neu efallai bod gennych chi gyfrifiadur hen iawn. Felly, mae gan bawb lled band rhwydwaith gwahanol.
Dyna pam y datblygwyd technoleg TCP Windowing, pan fydd trosglwyddo data yn dechrau ar gyflymder isel neu gyda throsglwyddo isafswm o becynnau, gan gynyddu'r “ffenestr” traffig yn raddol. Rydych chi'n anfon un pecyn, 5 pecyn, 10 pecyn, 1000 o becynnau, 10000 o becynnau ac yn agor y ffenestr honno'n araf fwy a mwy nes bod yr “agoriad” yn cyrraedd y swm mwyaf posibl o draffig a anfonir mewn cyfnod penodol o amser. Felly, mae'r cysyniad o Windowing yn rhan o weithrediad y protocol TCP.
Nesaf byddwn yn edrych ar y niferoedd porthladd mwyaf cyffredin. Y sefyllfa glasurol yw pan fydd gennych 1 prif weinydd, efallai canolfan ddata. Mae'n cynnwys gweinydd ffeiliau, gweinydd gwe, gweinydd post a gweinydd DHCP. Nawr, os yw un o'r cyfrifiaduron cleient yn cysylltu â'r ganolfan ddata, sydd wedi'i lleoli yng nghanol y llun, bydd yn dechrau anfon traffig gweinydd ffeiliau i ddyfeisiau cleient. Dangosir y traffig hwn mewn coch a bydd yn cael ei drosglwyddo ar borthladd penodol ar gyfer rhaglen benodol o weinydd penodol.
Sut oedd y gweinydd yn gwybod i ble y dylai traffig penodol fynd? Mae'n dysgu hyn o'r rhif porthladd cyrchfan. Os edrychwch ar y ffrâm, fe welwch fod sôn am rif y porthladd cyrchfan a rhif y porthladd ffynhonnell ym mhob trosglwyddiad data. Gallwch weld bod y traffig glas a choch, a'r traffig glas yn draffig gweinydd gwe, mae'r ddau yn mynd i'r un gweinydd corfforol, sydd â gweinyddwyr gwahanol wedi'u gosod. Os yw hon yn ganolfan ddata, yna mae'n defnyddio gweinyddwyr rhithwir. Felly sut oedden nhw'n gwybod bod y traffig coch i fod i fynd yn ôl i'r gliniadur chwith hwnnw gyda'r cyfeiriad IP hwnnw? Maent yn gwybod hyn diolch i rifau porthladdoedd. Os cyfeiriwch at erthygl Wicipedia “Rhestr o Borthladdoedd TCP a CDU”, fe welwch ei fod yn rhestru'r holl rifau porthladd safonol.
Os sgroliwch i lawr y dudalen hon gallwch weld pa mor fawr yw'r rhestr hon. Mae ynddo tua 61 o rifau. Gelwir rhifau porthladdoedd o 000 i 1 yn rhifau porthladd mwyaf cyffredin. Er enghraifft, mae porthladd 1024/TCP ar gyfer anfon gorchmynion ftp, mae porthladd 21 ar gyfer ssh, mae porthladd 22 ar gyfer Telnet, hynny yw, ar gyfer anfon negeseuon heb eu hamgryptio. Mae'r porthladd poblogaidd iawn 23 yn cario data dros HTTP, tra bod porthladd 80 yn cario data wedi'i amgryptio dros HTTPS, sy'n debyg i'r fersiwn ddiogel o HTTP.
Mae rhai porthladdoedd yn ymroddedig i TCP a CDU, ac mae rhai yn cyflawni gwahanol dasgau yn dibynnu a yw'r cysylltiad yn TCP neu CDU. Felly, yn swyddogol defnyddir porthladd TCP 80 ar gyfer HTTP, ac yn answyddogol defnyddir porthladd CDU 80 ar gyfer HTTP, ond o dan brotocol HTTP gwahanol - QUIC.
Felly, ni fwriedir i rifau porthladdoedd yn TCP bob amser wneud yr un peth ag yn y CDU. Nid oes angen i chi ddysgu'r rhestr hon ar y cof, mae'n amhosibl cofio, ond mae angen i chi wybod rhai rhifau porthladd poblogaidd a mwyaf cyffredin. Fel y dywedais, mae gan rai o’r porthladdoedd hyn ddiben swyddogol, a ddisgrifir yn y safonau, ac mae gan rai ddiben answyddogol, fel sy’n wir am Chromium.
Felly, mae'r tabl hwn yn rhestru'r holl rifau porthladd cyffredin, a defnyddir y niferoedd hyn i anfon a derbyn traffig wrth ddefnyddio cymwysiadau penodol.
Nawr, gadewch i ni edrych ar sut mae data'n symud ar draws y rhwydwaith yn seiliedig ar yr ychydig wybodaeth rydyn ni'n ei wybod. Gadewch i ni ddweud bod cyfrifiadur 10.1.1.10 eisiau cysylltu â'r cyfrifiadur hwn, neu'r gweinydd hwn, sydd â'r cyfeiriad 30.1.1.10. O dan gyfeiriad IP pob dyfais mae ei gyfeiriad MAC. Rwy'n rhoi enghraifft o gyfeiriad MAC gyda dim ond y 4 nod olaf, ond yn ymarferol mae'n rhif hecsadegol 48-did gyda 12 nod. Gan fod pob un o'r rhifau hyn yn cynnwys 4 did, mae 12 digid hecsadegol yn cynrychioli rhif 48-did.
Fel y gwyddom, os yw'r ddyfais hon am gysylltu â'r gweinydd hwn, rhaid gwneud cam cyntaf yr ysgwyd llaw 3-ffordd yn gyntaf, hynny yw, anfon pecyn SYN. Pan wneir y cais hwn, bydd cyfrifiadur 10.1.1.10 yn nodi'r rhif porth ffynhonnell, y mae Windows yn ei greu yn ddeinamig. Mae Windows yn dewis rhif porthladd rhwng 1 a 65,000 ar hap. Ond gan fod niferoedd cychwynnol yn yr ystod 1 i 1024 yn hysbys iawn, yn yr achos hwn bydd y system yn ystyried niferoedd sy'n fwy na 25000 ac yn creu porthladd ffynhonnell ar hap, er enghraifft, rhif 25113.
Nesaf, bydd y system yn ychwanegu porthladd cyrchfan i'r pecyn, yn yr achos hwn mae'n borthladd 21, oherwydd bod y cais sy'n ceisio cysylltu â'r gweinydd FTP hwn yn gwybod y dylai anfon traffig FTP.
Nesaf, dywed ein cyfrifiadur, “Iawn, fy nghyfeiriad IP yw 10.1.1.10, ac mae angen i mi gysylltu â'r cyfeiriad IP 30.1.1.10.” Mae'r ddau gyfeiriad hyn hefyd wedi'u cynnwys yn y pecyn i ffurfio cais SYN, ac ni fydd y pecyn hwn yn newid tan ddiwedd y cysylltiad.
Rwyf am i chi ddeall o'r fideo hwn sut mae data'n symud ar draws y rhwydwaith. Pan fydd ein cyfrifiadur sy'n anfon y cais yn gweld y cyfeiriad IP ffynhonnell a'r cyfeiriad IP cyrchfan, mae'n deall nad yw'r cyfeiriad cyrchfan ar y rhwydwaith lleol hwnnw. Anghofiais ddweud mai cyfeiriadau IP /24 yw'r rhain i gyd. Felly os edrychwch ar y cyfeiriadau IP /24, byddwch yn sylweddoli nad yw cyfrifiaduron 10.1.1.10 a 30.1.1.10 ar yr un rhwydwaith. Felly, mae'r cyfrifiadur sy'n anfon y cais yn deall, er mwyn gadael y rhwydwaith hwn, bod yn rhaid iddo gysylltu â phorth 10.1.1.1, sydd wedi'i ffurfweddu ar un o'r rhyngwynebau llwybrydd. Mae'n gwybod y dylai fynd i 10.1.1.1 ac mae'n gwybod ei gyfeiriad MAC o 1111, ond nid yw'n gwybod cyfeiriad MAC y porth 10.1.1.1. Beth mae e'n ei wneud? Mae'n anfon cais ARP darlledu y bydd pob dyfais ar y rhwydwaith yn ei dderbyn, ond dim ond y llwybrydd â chyfeiriad IP 10.1.1.1 fydd yn ymateb iddo.
Bydd y llwybrydd yn ymateb gyda'i gyfeiriad MAC AAAA, a bydd cyfeiriadau MAC ffynhonnell a chyrchfan hefyd yn cael eu gosod yn y ffrâm hon. Unwaith y bydd y ffrâm yn barod, cynhelir gwiriad cywirdeb data CRC, sef algorithm ar gyfer dod o hyd i wiriad i ganfod gwallau, cyn gadael y rhwydwaith.
Mae CRC Diswyddiad Cylchol yn golygu bod y ffrâm gyfan hon, o'r SYN i'r cyfeiriad MAC diwethaf, yn cael ei rhedeg trwy algorithm stwnsio, dyweder MD5, gan arwain at werth hash. Yna gosodir y gwerth hash, neu siec MD5, ar ddechrau'r ffrâm.
Fe'i labelais yn FCS/CRC oherwydd bod FCS yn Ddilyniant Gwirio Ffrâm, gwerth CRC pedwar beit. Mae rhai pobl yn defnyddio'r dynodiad FCS ac mae rhai yn defnyddio'r dynodiad CRC, felly gwnes i gynnwys y ddau ddynodiad. Ond yn y bôn dim ond gwerth hash ydyw. Mae angen gwneud yn siŵr nad yw'r holl ddata a dderbynnir dros y rhwydwaith yn cynnwys gwallau. Felly, pan fydd y ffrâm hon yn cyrraedd y llwybrydd, y peth cyntaf y bydd y llwybrydd yn ei wneud yw cyfrifo'r siec ei hun a'i gymharu â'r gwerth FCS neu CRC y mae'r ffrâm a dderbyniwyd yn ei gynnwys. Fel hyn, gall wirio nad yw'r data a dderbynnir dros y rhwydwaith yn cynnwys gwallau, ac ar ôl hynny bydd yn tynnu'r siec o'r ffrâm.
Nesaf, bydd y llwybrydd yn edrych ar y cyfeiriad MAC ac yn dweud, "Iawn, mae cyfeiriad MAC AAAA yn golygu bod y ffrâm wedi'i chyfeirio ataf," a dileu'r rhan o'r ffrâm sy'n cynnwys y cyfeiriadau MAC.
Gan edrych ar gyfeiriad IP cyrchfan 30.1.1.10, bydd yn deall nad yw'r pecyn hwn yn cael ei gyfeirio ato a rhaid iddo fynd ymhellach drwy'r llwybrydd.
Nawr mae'r llwybrydd yn “meddwl” bod angen iddo weld ble mae'r rhwydwaith gyda'r cyfeiriad 30.1.1.10 wedi'i leoli. Nid ydym wedi ymdrin â'r cysyniad llawn o lwybro eto, ond gwyddom fod gan lwybryddion fwrdd llwybro. Mae gan y tabl hwn gofnod ar gyfer y rhwydwaith gyda chyfeiriad 30.1.1.0. Fel y cofiwch, nid cyfeiriad IP y gwesteiwr yw hwn, ond y dynodwr rhwydwaith. Bydd y llwybrydd yn "meddwl" y gall gyrraedd y cyfeiriad 30.1.1.0/24 trwy fynd trwy'r llwybrydd 20.1.1.2.
Efallai y byddwch yn gofyn, sut mae'n gwybod hyn? Cofiwch y bydd yn gwybod hyn naill ai o'r protocolau llwybro neu o'ch gosodiadau os ydych chi fel gweinyddwr wedi ffurfweddu llwybr sefydlog. Ond beth bynnag, mae tabl llwybro'r llwybrydd hwn yn cynnwys y cofnod cywir, felly mae'n gwybod y dylai anfon y pecyn hwn i 20.1.1.2. Gan dybio bod y llwybrydd eisoes yn gwybod cyfeiriad MAC y gyrchfan, byddwn yn parhau i anfon y pecyn ymlaen. Os nad yw'n gwybod y cyfeiriad hwn, bydd yn dechrau ARP eto, yn derbyn cyfeiriad MAC y llwybrydd 20.1.1.2, a bydd y broses o anfon y ffrâm yn parhau eto.
Felly rydym yn tybio ei fod eisoes yn gwybod y cyfeiriad MAC, yna bydd gennym gyfeiriad MAC ffynhonnell BBB a chyfeiriad MAC cyrchfan CSC. Mae'r llwybrydd eto'n cyfrifo'r FCS / CRC ac yn ei osod ar ddechrau'r ffrâm.
Yna mae'n anfon y ffrâm hon dros y rhwydwaith, mae'r ffrâm yn cyrraedd llwybrydd 20.1.12, mae'n gwirio'r siec, yn sicrhau nad yw'r data wedi'i lygru, ac yn dileu'r FCS / CRC. Yna mae'n "cwtogi" y cyfeiriadau MAC, yn edrych ar y cyrchfan ac yn gweld ei fod yn 30.1.1.10. Mae'n gwybod bod y cyfeiriad hwn wedi'i gysylltu â'i ryngwyneb. Mae'r un broses ffurfio ffrâm yn cael ei hailadrodd, mae'r llwybrydd yn ychwanegu gwerthoedd cyfeiriad MAC ffynhonnell a chyrchfan, yn gwneud y stwnsh, yn atodi'r hash i'r ffrâm ac yn ei anfon ar draws y rhwydwaith.
Mae ein gweinydd, ar ôl derbyn y cais SYN o'r diwedd wedi'i gyfeirio ato, yn gwirio'r siec hash, ac os nad yw'r pecyn yn cynnwys gwallau, mae'n dileu'r hash. Yna mae'n tynnu'r cyfeiriadau MAC, yn edrych ar y cyfeiriad IP ac yn sylweddoli bod y pecyn hwn wedi'i gyfeirio ato.
Ar ôl hynny, mae'n cwtogi'r cyfeiriadau IP sy'n gysylltiedig â thrydedd haen y model OSI ac yn edrych ar rifau'r porthladdoedd.
Mae'n gweld porthladd 21, sy'n golygu traffig FTP, yn gweld y SYN ac felly'n deall bod rhywun yn ceisio cyfathrebu ag ef.
Nawr, yn seiliedig ar yr hyn ddysgon ni am yr ysgwyd llaw, bydd gweinydd 30.1.1.10 yn creu pecyn SYN/ACK a'i anfon yn ôl i gyfrifiadur 10.1.1.10. Ar ôl derbyn y pecyn hwn, bydd dyfais 10.1.1.10 yn creu ACK, yn ei basio trwy'r rhwydwaith yn yr un modd â phecyn SYN, ac ar ôl i'r gweinydd dderbyn yr ACK, bydd y cysylltiad yn cael ei sefydlu.
Un peth y dylech chi ei wybod yw bod hyn i gyd yn digwydd mewn llai nag eiliad. Mae hon yn broses gyflym iawn, iawn, y ceisiais ei arafu fel bod popeth yn glir i chi.
Gobeithio y bydd yr hyn a ddysgoch yn y tiwtorial hwn yn ddefnyddiol i chi. Os oes gennych unrhyw gwestiynau, ysgrifennwch ataf yn [e-bost wedi'i warchod] neu gadewch gwestiynau o dan y fideo hwn.
Gan ddechrau gyda'r wers nesaf, byddaf yn dewis y 3 chwestiwn mwyaf diddorol o YouTube, y byddaf yn eu hadolygu ar ddiwedd pob fideo. O hyn ymlaen bydd gennyf adran "Cwestiynau Gorau" felly byddaf yn postio cwestiwn ynghyd â'ch enw a'i ateb yn fyw. Credaf y bydd hyn yn fuddiol.
Diolch am aros gyda ni. Ydych chi'n hoffi ein herthyglau? Eisiau gweld cynnwys mwy diddorol? Cefnogwch ni trwy osod archeb neu argymell i ffrindiau, Gostyngiad o 30% i ddefnyddwyr Habr ar analog unigryw o weinyddion lefel mynediad, a ddyfeisiwyd gennym ni ar eich cyfer chi: (ar gael gyda RAID1 a RAID10, hyd at 24 craidd a hyd at 40GB DDR4).
VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps am ddim tan yr haf wrth dalu am gyfnod o chwe mis, gallwch archebu .
Dell R730xd 2 gwaith yn rhatach? Dim ond yma yn yr Iseldiroedd! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - o $99! Darllenwch am
Ffynhonnell: hab.com