Համեմատած մոտ 20 տարի առաջ, ժամանակակից զարգացման աշխարհը մեծապես ընդլայնվել է, և դրա հետ մեկտեղ կարող են լինել բաղադրիչների վերացականումներ, որոնց մասին մենք սովորաբար ստիպված էինք երկար մտածել: Օրինակ, ապարատների մեծ մասը, որոնց հետ մենք գործ ունեինք, վերացարկվել է ամպի մեջ: Ծրագրավորման տարբեր լեզուներ օգնում են վերացականացնել համակարգի մակարդակի տարբեր առաջադրանքները բազմաթիվ հարթակներում: Կան նաև անհավանական թվով գրադարաններ՝ CRUD-ի (ստեղծել կարդալ թարմացումների ջնջման) հիմնական տիպի աշխատանքը կատարելու համար:

Այնուամենայնիվ, սա նշանակում է, որ մշակողների համար ավելի քիչ խթան կա սովորելու ավելի ցածր մակարդակի բաղադրիչներ, որոնք վերցված են դրանցից: Խոշոր ամպային մատակարարները վերացում են տարբեր ապարատային բաղադրիչներ, ինչպես նաև կառավարվող ծառայություններ, որոնք վերացնում են հարակից բաղադրիչների ամբողջ շերտերը: Սարքավորումների ուղղահայաց/հորիզոնական մասշտաբավորումը և միկրոծառայությունների աճն էլ ավելի են նվազեցրել համակարգչային գիտության հիմնական հիմունքներին անցնելու անհրաժեշտությունը (բացառությամբ բարձր մասնագիտացված ոլորտների, որոնք կենտրոնանում են հարդքոր աշխատանքի կամ ներկառուցված համակարգերի վրա):

Որպես ծրագրավորող՝ հաշվողական աշխատանքի մի քանի ավելի վաղ օրերից, ես ստիպված էի անընդհատ ուսումնասիրել իրերի ավելի խորը մակարդակները: Սա նշանակում է, որ ես նաև տեսել եմ այս գիտելիքի օգուտները: Այն ծրագրավորողների համար, ովքեր ցանկանում են կատարել հաջորդ քայլը, կամ պարզապես չեն կարող զսպել իրենց հետաքրքրասիրությունը իրերի ներքին աշխատանքի վերաբերյալ, ես որոշեցի հավաքել այս հոդվածը: Մենք կանդրադառնանք որոշ ոլորտների, որոնք հաճախ վերացվում են, և գիտելիքների հնարավոր կատեգորիաների վրա, որոնց վրա պետք է կենտրոնանանք՝ հնարավորության դեպքում հասանելի հատուկ ռեսուրսների միջոցով:

Ես նշեմ, որ այս հոդվածի բովանդակությունը շատ մանրակրկիտ է, բայց ձեզնից որևէ մեկը պետք չէ հեռացնել: Ազատորեն ընտրեք այն մասերը, որոնք առավել համապատասխան են ձեզ: Ավելի լավ է ինչ-որ բան վերցնել, քան ընդհանրապես ոչինչ: Համակարգի ավելի շատ մշակողներ, հավանաբար, պետք է վերցնեն ամեն ինչ մինչև օպերացիոն համակարգերը, ինչպես պահանջվում է ընթերցմամբ: Նրանք, ովքեր ավելի շատ են խորանում API/վեբ մշակման մեջ, հավանաբար կարող են մնալ ցանցային ոլորտներում: Ամեն դեպքում, որքան ավելի շատ իմանաք համակարգերի ավելի ցածր մակարդակների մասին, այնքան ավելի լավ պատրաստված կլինեք սխալ ընթացող բաների հետ գործ ունենալու համար (ինչն այսօր տեղի է ունենում ավելի հաճախ, քան կարելի է համարել):

Նշում. բոլոր հղումները հիմնականում վերաբերում են գրքի հրատարակչին (կամ մերձավոր մասնաճյուղին): Amazon-ի փոխկապակցված հղումներ չկան: Բացի այդ, գրքերի մեծ մասը պետք է կապված լինի ոչ հրատարակության հատուկ էջի հետ, բայց համոզվեք, որ հաստատեք հրատարակչի կայքում, որ այն վերջինն է:

Համակարգչային ճարտարապետություն

Երբ խոսքը վերաբերում է հաշվարկների ավելի ցածր մակարդակներին, իրական ապարատային բաղադրիչները մոտավորապես այնքան ցածր են, որքան այն ստանում է: Պրոցեսորը, հիշողությունը, համակարգի ավտոբուսները և այլն, համակարգի վրա գործառնությունների իրականացման հիմնական կառուցվածքային բլոկներն են: Հաշվի առնելով, թե որքան կարևոր է սա, համակարգչային ճարտարապետության մանրամասները հաճախ հանդիպում են որպես համակարգչային գիտության շատ դասերի մաս: Եթե ​​դուք չեք ենթարկվել նման դասընթացի, խորհուրդ եմ տալիս ուսումնասիրել Համակարգչային կազմակերպում և ձևավորում. Սարքավորումներ/Ծրագրային ինտերֆեյս: Դա բավականին խորը հայացք է համակարգչի ապարատային բաղադրիչներին:

Այսպիսով, ինչպե՞ս դա կարող է օգնել ձեզ գործնական առումով: Հիմնական ուղիներից մեկն այն է, եթե դուք գործ ունեք տվյալների բազաների հետ: Տվյալների բազայի հետ կապված կարևոր է հասկանալ հիշողության և սկավառակի աշխատանքի խնդիրները, ինչպես նաև, թե որքան մեծ բաց կա: Նույնը վերաբերում է պրոցեսորի փոխազդեցությանը երկուսի հետ: Բարձր արդյունավետությամբ հաշվողական աշխարհում նրանք կարող են օգուտ քաղել պրոցեսորի քեշը հասկանալուց, հատկապես քեշի հավասարեցման հետ կապված՝ քեշի բացթողումները կանխելու համար:

ժողով

Այժմ, երբ մենք գլուխներս փաթաթել ենք սարքաշարի շուրջ, ժամանակն է նայելու, թե ինչպես է ծրագրաշարը փոխազդում դրա հետ: Թեև C-ն բավականին ցածր մակարդակ է և որտեղ կարող են սկսել շատ ծրագրավորողներ, հավաքումը դեռևս հիմնարար շինանյութ է: Իրականում, C կոմպիլյատորների մեծամասնությունը C-ի կոդը բաժանելու է հավաքման: Ասված է, որ հավաքումը տարբերվում է բազմաթիվ համակարգերում: Օրինակ, կան x86 հավաքում (հաճախ համարվում է ամենատարածվածը), MIPS հավաքումը և նույնիսկ պրոցեսորի ապրանքանիշի մակարդակի տարբերությունները (Intel և AMD): RISC (նվազեցված հրահանգների հավաքածուի համակարգիչ) հավաքումը բավականին լավ է հավաքման հիմունքները ցույց տալու համար: Նրանց համար, ովքեր փնտրում են ավելի գործնական մոտեցում, x86 հավաքումը ավելի լավ տարբերակ է (թեև ամենահուսալի):

Մեդիա/գրաֆիկայի տիպի մշակման մեջ ներգրավվածները չափազանց կարևոր են համարում հավաքումը: Նույնը վերաբերում է նրանց, ովքեր փնտրում են խաղի զարգացման կենտրոնացած դիրք: Հաշվի առնելով, թե որքան սարսափելի կարող է լինել հավաքումը, Տես MIPS Run-ը լավ միջոց է ոտքի մատները հավաքելու մեջ առանց խելագարվելու: Google-ի արագ որոնումը կարող է օգնել ձեզ գտնել MIPS էմուլյատորներ նրանց համար, ովքեր չունեն այն: MIPS Assembly Language Programming-ը ևս մեկ հիանալի ռեսուրս է, որն օգտագործում է էմուլատոր գրքում: Կարող եք նաև դիտարկել ARM հավաքում՝ օգտագործելով յուրաքանչյուր հայտնի Rasberry Pi-ը:

x86 հավաքումը (և որոշ դեպքերում x86_64) օգտագործվում է շատ գործնական ծրագրերում: Հիմնական գործնական օգտագործումը Linux օպերացիոն համակարգն է (լավ, առնվազն x86 բաղադրիչները): Եթե ​​ցանկանում եք մի փոքր փորձարկել ջուրը, Art of Assembly Language-ը լավ սկիզբ է: Այժմ, եթե դուք իսկապես լուրջ եք, բարձր տեխնիկական Intel կամ AMD զարգացման ուղեցույցները լավ կանգառ են:

Նշում. AWS-ի օրինակները տարածվում են պրոցեսորի ճարտարապետության համար՝ հիմնված օրինակների դասի վրա: Աջակցության տեսակներն են AMD, Intel և (վերջերս) ARM:

Գ Զարգացում

«Սովորիր ծրագրավորել C-ով» շատ տարածված հայտարարություն է նրանց համար, ովքեր ցանկանում են զարգացնել կամ ավելին ստանալ: Ցավոք, «Ծրագիրը C-ում» մեր օրերում ինչ-որ անորոշ հասկացություն է, քանի որ հետևյալներից որևէ մեկը կարող է ձեր փորձը շատ տարբեր դարձնել.

  • Ո՞ր C ստանդարտի հետ եք աշխատում (K&R C, ANSI C, ISO C, C99, C11, C18)
  • Ո՞ր ՕՀ-ի հետ գործ ունեք (համակարգային որ զանգերն են հասանելի)
  • Որ ստանդարտ C գրադարանի ներդրման հետ գործ ունեք (ինչպես եք փոխազդում համակարգային զանգերի հետ, ինչպես նաև այլ հատուկ առանձնահատկություններ)
  • Ո՞ր կոմպիլյատորի հետ գործ ունեք (որ հնարավորություններն են ձեզ հասանելի, որոնք աջակցում են C ստանդարտներին, որոնք կարող եք օգտագործել)
  • Ինչ գրադարանների հետ կարող եք ինտերֆեյս (նախապրոցեսորային հրահանգները լայնորեն օգտագործվում են այս դեպքերում, երբեմն C-ն դարձնում է մի ամբողջ տիրույթի հատուկ լեզվի տեսք)

Գլխարկի տակ ընկնելու առումով, C-ի օգտագործումը UNIX-ի վրա հիմնված համակարգում բավականին պատշաճ միջոց է գործնական փորձ ձեռք բերելու համար:

Սկսելու համար կարևոր է հասկանալ հիմնական C-ն: Թեև K&R գիրքը (գրված է C-ի բնօրինակ մշակողների կողմից) հաճախ գովազդվում է որպես C-ի Աստվածաշունչ, ես գտնում եմ, որ այն ավելի շատ պատմական արժեք ունի և բավականին անջատված է ժամանակակից C-ից (թեև շատերը երդվելու դրանով, եթե դուք գնում եք միջուկի զարգացման ճանապարհով): Այս դեպքում ես խորհուրդ եմ տալիս սկսել C Programming. A Modern Approach-ից՝ լեզվի հիմունքները ծանոթանալու համար: Այնտեղից ես խորհուրդ եմ տալիս նայել 21st Century C-ն, որն անցնում է ավելի շատ գործիքների հետ կապված քննարկումների, ինչպիսիք են make-ը, gdb-ը, gcc-ն և այլն: Նաև հաշվի առեք C: A Reference Manual-ը, եթե ցանկանում եք արագ փնտրման գիրք:

Ինչ վերաբերում է C-ի ուսուցման գործնականությանը, ապա դա այն է, ինչի վրա հիմնված է հանրաճանաչ լեզուների արժանապատիվ մասը: Սա ներառում է Ruby (MRI), Python (Cython), PHP և… տեսակի NodeJS (V8-ը C++ է): C-ի իմացությունը կօգնի ձեզ հասկանալ, թե ինչպես են աշխատում այս լեզուները և նույնիսկ կկազմավորեք ձեզ շատ մանրամասն խորը սուզվելու վրիպազերծման համար: Վերջապես, շատ ծրագրավորման լեզուներ աջակցում են C միջերեսներին (կամ FFI, օտարերկրյա ֆունկցիայի միջերես) լեզվին: Սա կարող է օգտագործվել բարձր կատարողական ընդլայնումներ մշակելու համար այն դեպքերում, երբ ընդհանուր լեզվի կատարումը տուժում է:

Նշում. խորհուրդ եմ տալիս օգտագործել այս գրքերը Linux միջավայրում, նույնիսկ եթե դա նշանակում է վիրտուալ մեքենա պտտել: Դա այն է, ինչ այս օրերին աշխատում են սերվերների մեծ մասը, և, ամենայն հավանականությամբ, ձեզ կստեղծի գործնական փորձ:

Օպերացիոն համակարգ

Այժմ ժամանակն է դիտարկել օպերացիոն համակարգը: Շատ համակարգային զանգեր կատարվում են C-ի միջոցով, ուստի նախորդ բլոկները լավ հիմք են ստեղծում: Թեև Linux-ը ընդհանուր առմամբ համարվում է հայտնի մեկնարկային կետ, ես իրականում խորհուրդ եմ տալիս ուսումնասիրել Ընդլայնված ծրագրավորում UNIX միջավայրում: Պատճառն այն է, որ UNIX-ը տարածված բազա է հանրաճանաչ սերվերային ՕՀ-ների շրջանում: Այն կարող է ինչ-որ չափով ձեզ բերել նաև OSX հող, քանի որ այն հիմնված է BSD-ի վրա: Սա կներառի աներևակայելի գործնական ցածր մակարդակի զարգացում, ներառյալ IPC, վարդակներ, ֆայլի IO, ազդանշաններ և այլն:

Երբ դուք դա իջնեք, ժամանակն է անցնել համակարգի օգտատիրոջ միջերեսին: Այստեղ ես խորհուրդ եմ տալիս UNIX և Linux համակարգի կառավարման ձեռնարկ: Սա մի փոքր ավելի բարձր մակարդակի վրա է անցնում բաղադրիչները, բայց նաև ներկայացնում է հրամաններ, որոնք դուք կարող եք օգտագործել ձեր կոդի մեջ, ընդհանուր առմամբ, գործընթացի ձևավորման միջոցով: Հիմա, եթե դուք իսկապես ցանկանում եք դիտարկել նաև միջուկը, Հասկանալ Linux միջուկը լավ տեղ է սուզվելու համար: Ասել է թե՝ իսկապես հասկացեք, որ միջուկը շատ նվիրված գործընթաց է: Դա կարող է խանգարել ձեզ որոշ առումներով՝ խլելով ժամանակի արժանապատիվ հատվածը:

TCP/IP

Ոմանք կարող են համարել, որ սա մի քիչ տարօրինակ տեղ է սա լինելու համար: Տեխնիկապես դա ավելի ցածր մակարդակ է, քան օպերացիոն համակարգը: Պատճառն այն է, որ սա այստեղ է, այն է, որ ես նախատեսում եմ այստեղից դիտարկել ցանցային աբստրակցիաները, ինչը նշանակում է, որ ես պետք է հարվածեմ հիմնարար հիմնական հայեցակարգին՝ TCP/IP: TCP/IP նշանակում է փոխանցման վերահսկման արձանագրություն/Ինտերնետ արձանագրություն: Դա, ըստ էության, երկու առանձին բաղադրիչներ է, որոնք միավորված են մեկ լուծման մեջ: Պատճառն այն է, որ դրա իմացությունն այդքան կարևոր է, այն է, որ այն հանդիսանում է մի շարք հիմնարար ավելի բարձր մակարդակի արձանագրությունների կառուցման բլոկ, ինչպիսիք են SSH և HTTP:

Այստեղ իմ սիրելի ուղեցույցը TCP/IP ցանցի կառավարումն է: Այն ունի TCP/IP-ի բավականին ամուր խզում, ներառյալ հայտնի արձանագրությունները, որոնք կառուցվում են դրա վրա: Ինչ վերաբերում է TCP/IP-ի հետ ծրագրային ինտերֆեյսին, Unix Network Programming, Volume 1: The Sockets Networking API-ն, ես գտնում եմ, որ հիանալի ռեսուրս է: Թեև, ճիշտն ասած, դա շատ ավելին է, քան դա։ Այն նաև ներառում է այլ արձանագրություններ (UDP) և շատ բարձր մակարդակի ցանցային հասկացություններ, ինչպիսիք են մուլտիպլեքսավորումը և հեռարձակումը:

TCP/IP-ի իմացությունը կարևոր է, եթե դուք անում եք ցանկացած տեսակի ցանցի հետ կապված զարգացում, որն այս օրերին հանդիսանում է զարգացման մեծ մասը): Այն չափազանց օգտակար է ծառայության հաղորդակցության խնդիրները հայտնաբերելու համար: Դուք նույնպես չեք կարողանա անցնել անվտանգության բազմաթիվ մասնագիտություններ այս օրերին առանց դրա: Ի վերջո, դա օգտակար է գնահատելու համար, թե որ տեսակի ծրագրակազմն եք ցանկանում աջակցել որոշակի ծառայություններին:

DNS

DNS (Domain Name System) այն է, ինչ ես համարում եմ ցանցի վրա հիմնված հաջորդ հիմնական բաղադրիչը: Եթե ​​կոտրված է, ձեր կայքը անհասանելի է դառնում, ծառայությունները դադարում են միմյանց հետ խոսել, և փոստը դառնում է տարօրինակ: Վատագույն դեպքում ինչ-որ մեկը կարող է խլել ձեր կայքը: Ըստ էության, այն կարելի է համարել որպես ձեր հեռախոսի կոնտակտների ցանկ: Սթիվի համարը հիշելու և փորձելու փոխարեն, կարող եք պարզապես փնտրել նրա համարը անունով: DNS-ն օգնում է այս հարցում (և այլ ասպեկտներով)՝ օգնելով քարտեզագրել անունները IP հասցեներով:

Նախորդ ցանցային և Linux/UNIX կառավարման գրքերը պետք է օգնեն լուսաբանել որոշ հիմունքներ: Այնուամենայնիվ, DNS and BIND-ը շատ ամուր բովանդակություն է DNS-ն ավելի բարձր մակարդակի վրա հասկանալու համար (հատկապես քեշավորում և լուծում): Սա, այնուամենայնիվ, կհամարվի բավականին հիմնական գիտելիքներ: Կան բազմաթիվ DNS պրովայդերներ, որոնք կարող են տարբեր լինել տարբեր հատկանիշներով (աշխարհագրական DNS լուծում, բեռի հավասարակշռման DNS լուծում և այլն): Կարող են լինել նաև ծառայության մակարդակի DNS հարաբերություններ, ինչպիսիք են SPF և DKIM գրառումները, որոնք հաճախ օգտագործվում են էլփոստի սերվերները վավերացնելու համար:

Նշում. DNS-ը հիմնականում օգտագործում է UDP արձանագրությունը: Թեև UDP-ի իմացությունը նույնպես ձեռնտու է, դուք, ընդհանուր առմամբ, դրանից շատ չեք տեսնի DNS-ից դուրս. DNS-ի համատեքստում այն ​​ուսումնասիրելը, իմ կարծիքով, ավելի լավ գաղափար է:

Երթուղիավորում

TCP/IP-ի իմացությունը DNS-ի հետ մեկտեղ մեզ նախատեսում է հաջորդ ոլորտում՝ երթուղում: Երբ դուք ունեք տիրույթի անունը լուծված (հուսով եմ) IP հասցեով, դուք պետք է հասնեք այդ իրական համակարգին: Դա անելու գործընթացը հայտնի է որպես երթուղի: Կայք հասնելը հաճախ կարող է ներառել բարդ գործընթաց, որն անցնում է մի քանի ISP-ի, մատակարարների և ներքին ցանցերի միջև: Ցավոք սրտի, դա նաև ամենահիասթափեցնողն է, երբ ամեն ինչ սխալ է ընթանում: Մատակարարի հետ երթուղիների հետ կապված խնդիրները սովորաբար այն չեն, որոնց հետ կարող եք անձամբ զբաղվել և պետք է ապավինեք վերին հոսքի մատակարարներին:

Այնուամենայնիվ, երթուղավորման մութ մոգության մասին իմանալը կարող է օգտակար լինել խնդիրների վերլուծության և ներքին ցանցերի հնարավոր վրիպազերծման համար: Այս տարածքի համար ես խորհուրդ եմ տալիս IP Routing-ը որպես լավ ռեսուրս: Այն անդրադառնում է ոչ միայն ընդհանուր երթուղիներին, այլև այն արձանագրություններին, որոնք ետ ուղղում են: Մասնավորապես, BGP-ի իմացությունը կարող է չափազանց օգտակար լինել (AWS-ն դա օգտագործում է իր VPN ծառայության մեջ): Վերջիվերջո, թեև երթուղիների հետ ուղղակիորեն զբաղվելը շատ բան չէ, ինչի մասին շատ բան կտեսնեք, այնպես որ դրա կլանումը պետք է հաշվի առնել ուժեղ ինտելեկտուալ հետաքրքրասիրության տեսակների համար:

HTTP/1

Մի տեղից մյուսը տվյալներ ստանալու գաղափարի առկայության դեպքում ժամանակն է մտածել, թե ինչպիսի տվյալներ պետք է ուղարկվեն: REST-ը (ներկայացուցչական պետական ​​փոխանցում) սովորաբար օգտագործվում է և ավելի հաճախ՝ HTTP-ի (Hyper Text Transfer Protocol) միջոցով: Միանգամայն կոպիտ ասած, եթե դուք պատրաստվում եք որևէ տեսակի վեբ ծառայության մշակում կատարել՝ չիմանալով, որ սա վատ կարիերայի որոշում է: Սպասեք, որ HTTP-ի հետ կապված հարցեր կառաջանան նման պաշտոնների համար հարցազրույցներում:

Մինչ այժմ ես հիմնականում գրքեր էի խորհուրդ տալիս։ Սա հիմնականում պայմանավորված է հիմնական հիմունքների բավականին պարզ լինելու պատճառով: Համացանցը, մյուս կողմից, շատ է փոխվում կառուցվածքների մեջ: Օրինակ, 10 տարի առաջվա նման, դուք դեռ պետք է DNS հարցումներ կատարեք՝ տիրույթը IP հասցեով քարտեզագրելու համար (չնայած, թե որ IP հասցեն եք վերադարձնում, որոշվում է աստիճանաբար բարելավվող տեխնոլոգիայով): Մյուս կողմից, թե ինչպես եք դուք զբաղվում համացանցով, կարող է շատ տարբեր լինել:

Սա նաև այն հատվածն է, որտեղ դուք լավագույնս կարող եք ուսումնասիրել RFC-ն (մեկնաբանությունների հարցում), որոնք սովորաբար ավարտվում են որպես ստանդարտներ: Ընդհանուր առմամբ, RFC-ները մի բան են, որոնք դուք հաճախ կտեսնեք վեբ առնչվող արձանագրություններում: Ինժեներական այլ ստանդարտներ հակված են իրենց տեսնել IEEE-ում, ISO-ում և ANSI-ում: Օրինակ, DNS-ն ունի RFC, ինչպես TCP/IP: Մենք կդիտարկենք HTTP RFC-ն այստեղ: Նշենք, որ այս ստանդարտը պահպանվում է W3 (World Wide Web) կոնսորցիումի կողմից:

Կարևոր է չխառնել HTTP-ն HTML-ի հետ (Hyper Text Markup Language): HTP-ն բանակցում է HTML-ի փոխանցման շուրջ: Բարձր մակարդակի վրա RFC-ն կանդրադառնա.

  • Հարցման բայեր (ինչ տեսակի հարցում եք անում)
  • Հարցման վերնագրեր (բավականին ազատ ձև և սերվերից կախված մետատվյալներ՝ հարցման շուրջ)
  • Արձագանքման ծածկագրեր (ինչպես է լուծվել ձեր հարցումը)
  • Պատասխանների վերնագրեր (պատասխանի շուրջ մետատվյալներ)
  • Քեշավորում (ինչու ձեր նոր թարմացրած վեբ էջը կարող է չցուցադրել թարմացումները)

HTTP/2

Թեև HTTP/1-ը կամ բնօրինակ HTTP-ն այն է, ինչ դուք կտեսնեք շատ դեպքերում, HTTP/2-ը նույնպես արագություն է հավաքում: HTTP/1-ի հիմնական թերությունն այն է, որ այն ետ ու առաջ հաղորդակցություն էր բազմաթիվ կապերի միջոցով: HTTP/2-ը փորձում է լուծել այս խնդիրը՝ հնարավորություն տալով ետ և առաջ հաղորդակցությունը գոյություն ունենալ մեկ կապի միջոցով (նվազեցնելով սերվերի սպառումը կապերից): Հետաքրքիր է, որ սա W3-ի առաջարկ չէր և փոխարենը արված էր IETF-ի (Ինտերնետ ինժեներական աշխատանքային խմբի) կողմից: Այս արձանագրության մշակման մեծ մասը կատարվել է Google-ի կողմից: Սա RFC-ն է HTTP2-ի համար:

Շատ հիմնարար HTTP/1 շատ բան չի փոխվել, այնպես որ սա հիմնականում ավելացվելու է դրա վրա եղած տեղեկատվության վրա: Այստեղ դուք պետք է ուսումնասիրեք նոր հարցումների և պատասխանների տվյալները, ինչպես նաև հոսքային կապի նոր գործառույթները: HTTP/2 Վիքի էջն ունի բավականին համապարփակ սերվերի ծրագրակազմի ցուցակ, որն աջակցում է HTTP/2, եթե հետաքրքրված եք:

SSL/TLS

Մինչ այժմ բոլոր հաղորդակցությունները, որոնց մենք անդրադարձել ենք, անցնում է պարզ տեքստով: Նրանց համար, ովքեր զբաղվում են էլեկտրոնային առևտրի կայքերով, որոնք կարող են վերցնել վարկային քարտի տեղեկատվությունը, որը մեծ անվտանգության վտանգ է ներկայացնում: Կան նաև գաղտնիության հետևանքներ, երբ ISP-ները (Ինտերնետ Ծառայություններ Մատակարարներ) ի վիճակի են խլել/փոփոխել երթուղու տվյալները ձեր բրաուզերում (օրինակ՝ գովազդ ավելացնելու համար): SSL/TLS-ը ստեղծվել է որպես այս խնդրի լուծումներից մեկը:

Սա այն է, ինչը հաճախ կոչվում է «գաղտնագրում տարանցման ժամանակ»: HTTPS-ը HTTP արձանագրությունների շուրջ ծածկագրման շերտավորում է: SSL-ը (Secure Sockets Layer) իրականում առաջացել է TLS-ից (Transport Layer Security) պատմական նպատակներով: Այնուհետև դրանով ընթացավ։ Թեև TLS-ը համարվում է կապերի ապահովման առավել արդի միջոց, այն հաճախ կոչվում է «SSL» մի փոքր ապատեղեկացված իմաստով:

Դա նաև առավել բարդ արձանագրություններից մեկն է, որոնց հետ պետք է զբաղվել: Անվտանգ կապի ապահովման հարցում շատ բան է կատարվում: Թեև կան RFC-ներ SSL-ի և TLS-ի համար, սակայն փորձելը հասկանալ, թե ինչ է տեղի ունենում, կարող է իսկապես բարդանալ: Ես խորհուրդ եմ տալիս ուսումնասիրել Սերվերների և վեբ հավելվածների ապահովման համար SSL/TLS և PKI-ի ըմբռնումը և տեղակայումը: SSL / TLS-ի իրականացումը կրիպտոգրաֆիայի և PKI-ի միջոցով ևս մեկ լավ ընտրություն է, որը դուք կարող եք ուսումնասիրել:

Երկուսն էլ հասկանալը կարևոր է իմանալու համար, թե ինչ է տեղի ունենում անվտանգ կապերով: Այն նաև շատ արժեքավոր գիտելիք է, որ պետք է ունենալ որևէ արձանագրության հետ կապված խնդիրները վրիպազերծելիս: Դուք նաև ստիպված կլինեք մի փոքր զբաղվել դրանով API-ի վերջնակետերի հետ գործ ունենալու կամ ինքներդ ծառայության վերջնակետեր ստեղծելու համար: Հաշվի առնելով տեղեկատվական անվտանգության ներկայիս վիճակը (կամ դրա բացակայությունը), որոնցից որևէ մեկի օգտագործումը կարող է լինել բոնուսային մարքեթինգային կետ՝ հաճախորդներին ավելի վստահ դարձնելու ձեր արտադրանքի նկատմամբ:

SSH

SSH (Secure SHell) մշակվել է ավելի ապահով բանի անհրաժեշտությունից ելնելով, քան նախորդ տելնետ կապը: Թեև telnet-ը թույլ էր տալիս մուտք գործել այլ սերվերներ, պարզ տեքստային հաղորդակցությունը վատ ընտրություն էր ադմինիստրատիվ առաջադրանքները կատարելու համար, որոնք պահանջում էին հավատարմագրերը հեռարձակման միջոցով: Մինչդեռ (բավականին շփոթեցնող) շատ դեպքերում SSH հաճախորդը/սերվերը օգտագործում է OpenSSL, փաստացի արձանագրությունն ինքնին SSL չէ (և իրականում մշակվել է դրանից դուրս):

SSL/TLS-ի նման, RFC գոյություն ունի նաև SSH արձանագրության համար: Ասել է թե, դա նաև բավականին բարդ բաղադրիչ է մարսելու համար: SSH, The Secure Shell. The Definitive Guide-ը վերաբերում է ոչ միայն արձանագրությանը, այլև OpenSSH-ի գործնական կիրառմանը, որը հանրաճանաչ արձանագրության իրականացումն է: Սա իմանալը չափազանց արժեքավոր է սերվերներ ուղղակիորեն մուտք գործելու կամ SSH-ն օգտագործող ծրագրակազմի վրիպազերծման համար (օրինակ, Ansible-ն այն օգտագործում է համակարգի կառավարման համար): Շատ կարևոր է նաև հասկանալու համար, թե որն է թույլ SSH կապը, որը կարող է վտանգի տակ դնել տարանցիկ տվյալները:

SMTP

Այստեղ տեղադրելու բավականին հետաքրքիր արձանագրություն, բայց գործնականում էլփոստի ուղարկումը SMTP-ով (Simple Mail Transfer Protocol) բավականին նորմալ խնդիր է շատ կայքերի համար (ուղղակի կամ անուղղակի): Սա ներառում է հաճախորդների հաշիվ-ապրանքագրերի էլեկտրոնային նամակներ կամ համակարգերի մոնիտորինգի գործակալից ուղարկված հաշվետվություններ ադմինիստրատորի էլ.փոստի հասցեին: Ինչպես անունն է հուշում, այլ արձանագրությունների համեմատ այն ստանդարտի առումով այնքան էլ բարդ չէ: SMTP RFC-ն ինքնին արձանագրության բավականին պատշաճ ակնարկ է, թեև որոշ չափով երկար ընթերցված:

Ծրագրավորողի ուղեցույց ինտերնետ փոստի համար Ես խորհուրդ կտամ, եթե ավելի շատ գրքի նյութ եք փնտրում: Ասել է թե, այն նաև անցնում է POP3, IMAP և LDAP արձանագրությունների վրա: Գործնականում ավելի հավանական է, որ դուք էլփոստ ուղարկեք, այլ ոչ թե այն ստանաք, այնպես որ SMTP-ի վրա կենտրոնանալը, ամենայն հավանականությամբ, բավականաչափ լավ է (կամ պարզապես նայելով RFC-ին): LDAP-ն ավելի շատ հիմնված է նույնականացման վրա և մի փոքր դուրս է այն ամենի համար, ինչ մենք տեսնում ենք այստեղ:

Վրիպազերծում

Ես սա թողել եմ վերջնականապես այն պատճառով, որ որքան շատ եք հասկանում ներքինը, այնքան ավելի հեշտ է լուծել խնդիրները: Շատ դեպքերում, զարգացումը կոդ գրելու հետ ու առաջ գործընթաց է, այնուհետև պարզելու, թե ինչու այն չի աշխատում այնպես, ինչպես դուք հաճախել եք (եթե իսկապես հաջողակ չեք): Վրիպազերծման գործընթացը պարզեցնելու ունակությունը կօգնի ձեզ ավելի արագ ստանալ ընդհանուր արդյունքներ: Այն մեծացնում է ինքնապահովումը և նվազեցնում է զարգացման խնդիրը հաղթահարելու համար արտաքին գործոնների պահանջները:

Թեև անկասկած կան բազմաթիվ գործիքներ, որոնք կօգնեն վրիպազերծմանը, իրական գործընթացը սովորաբար գալիս է փորձի հետ: Դա պայմանավորված է նրանով, որ շատ բաներ ուսուցանվում են՝ նկատի ունենալով կատարյալ արդյունքը: Դուք հաճախ չեք տեսնում, որ ծրագրավորման գրքերը դիտավորյալ սխալներ են թույլ տալիս (եթե դա սխալների հետ կապված բաժին չէ, գուցե): Սա նկատի ունենալով, դժվար է բուն թեմայով գիրք առաջարկել: Շատերը, որոնք դուք կգտնեք, կլինեն վրիպազերծման գործիքների շուրջ, ինչպիսիք են GDB-ն (GNU DeBugger): Այնուամենայնիվ, այս գործիքը հաճախ լավագույնս օգտագործվում է C/ASM-ի հետ և կարող է դժվար լինել օգտագործել այնտեղ գտնվող ժամանակակից լեզուներից շատերի հետ:

Վրիպազերծման իրական փորձ ստանալու համար խորհուրդ եմ տալիս փնտրել բաց կոդով մի քանի նախագծեր, որոնք դուք հաճախ օգտագործում եք: Նախ ստուգեք լուծված խնդիրները և տեսեք, թե որն է լուծումը (փորձեք գտնել առնչվող PR-ով, այլ ոչ միայն աղմուկի հետ կապված խնդիրներ): Այնուհետև սկսեք հեշտ ընտրանքներով և փորձեք վերլուծել, թե ինչ սխալ է տեղի ունեցել: Փորձեք շատ ժամանակ չծախսել մեկ հարցի վրա (եթե դուք շատ մոտիվացված չեք կամ ծայրահեղ արժեքներ չեք տեսնում դրանից): Եթե ​​կա մեկը, որը խանգարում է ձեզ պահել այն, մինչև ինչ-որ մեկը շտկի այն, ապա տեսեք, թե որն էր լուծումը:

Որքան շատ անեք դա, այնքան ավելի լավ պատրաստված կլինեք խնդիրները լուծելիս: Մի առաջարկ, որի մասին կարող եմ մտածել, Linux-ի հանրաճանաչ բաշխումների հետ կապված խնդիրների լուծումն է: Նման խնդիրները սովորաբար ներառում են մեծ թվով փաթեթներ, որոնք օգտագործում են մի շարք տիրույթներ և տարբեր ծրագրավորման լեզուներ: Սա օգնում է մեծացնել ձեր վրիպազերծման գիտելիքները թեմաների լայն շրջանակի վերաբերյալ:

Եզրակացություն

Սա ավարտում է բավականին երկար քննարկումը՝ մեր օրերում սովորաբար վերացարկվածի ներքին ներքևի մեջ մտնելու վերաբերյալ: Նման գիտելիքները չափազանց օգտակար են տեխնոլոգիական դիրքերի համար շարունակվող պայքարում ձեզ ուրիշներից վեր դասելու համար: Այն կարող է նաև օգնել ձեզ արագացնել կոդի ընդհանուր զարգացումը և նախագծերն ավելի արագ դուրս բերել շուկա: Պարզապես հիշեք, որ միշտ օգտակար է գիտելիքները փոխանցելը: Դուք ցանկանում եք, որ ձեր գործընկերները նույնպես լավ հագեցած լինեն: