მთავარი განსხვავება "ინტერნეტ თაობის" პორტატულ აუდიო ფლეერებსა და მათ წინამორბედებს შორის არის მათი მჭიდრო ინტეგრაცია პერსონალურ კომპიუტერთან.

წარსულში, პორტატული ფლეერები უკრავდნენ მუსიკას ჩვეულებრივი მოსახსნელი მედიიდან და არ სჭირდებოდათ ყურსასმენების გარდა რაიმესთან დაკავშირება

ბოლო დრომდე კომპიუტერი იყო მათი შინაარსის ერთადერთი წყარო. ამავდროულად, საჭირო იყო პორტატული პლეერისა და კომპიუტერის დაწყვილების მექანიზმი. ამოცანა იყო მონაცემთა ციფრული ფორმით გადაცემა ერთი მედიიდან (კომპიუტერში) მეორეზე (პლეერში) კომპიუტერული ინდუსტრიაში მიღებული ფორმატით.

კონტენტი უნდა გადაიტანოს კომპიუტერიდან, სადაც ის ჩვეულებრივ ინახება 3.5" მყარ დისკზე, პორტატულ მედია ფლეერებზე: ფლეშ მეხსიერება, 1" და 1.8" მყარ დისკებზე.

ამიტომ, რაიმე სახის კომპიუტერული მონაცემთა ინტერფეისი უნდა იქნას გამოყენებული.

ნებისმიერ ასეთ ინტერფეისში შეიძლება გამოირჩეოდეს ორი დონე. პირველი არის ფიზიკური, ე.ი. პირდაპირ მავთულები, კონექტორები, მიკროსქემები და ა.შ. მეორე არის პროგრამული უზრუნველყოფა, რომელიც, შედარებით რომ ვთქვათ, არის ინსტრუქციებისა და ალგორითმების ნაკრები, რომლის მიხედვითაც ხდება მონაცემების გაცვლა ფიზიკურ დონეზე. ამ პროგრამულ ფენას ხშირად პროტოკოლს უწოდებენ. დღეს ჩვენ ძირითადად ამაზე ვისაუბრებთ. მომხმარებლისთვის ეს არის ინტერფეისის „სახე“ მისი შესაძლებლობები და უარყოფითი მხარეები განსაზღვრავს მთლიანობაში მოწყობილობის მოხერხებულობას ან სირთულეს.

პროტოკოლის სრულად ფუნქციონირებისთვის საჭიროა ორი პროგრამული კომპონენტი. პირველ რიგში, ეს არის დრაივერი, რომელიც პირდაპირ აკავშირებს პორტატულ მოწყობილობას და კომპიუტერს პროგრამული უზრუნველყოფის დონეზე. მეორეც, ეს პროგრამული უზრუნველყოფა, რაც მომხმარებელს საშუალებას აძლევს მართოს პროტოკოლი და გამოიყენოს იგი თავისი საჭიროებისთვის. პროგრამული უზრუნველყოფა, მკაცრად რომ ვთქვათ, არ არის პროტოკოლის პირდაპირი ნაწილი. მაგრამ მისი არსებობის გარეშე, თავად პროტოკოლის არსებობა უაზრო ხდება. ამიტომ, ამ სტატიაში განვიხილავთ პროგრამულ უზრუნველყოფას, როგორც განსახილველი პროტოკოლების განუყოფელ ნაწილს.

ნებისმიერი პროგრამული პროტოკოლი იყენებს დრაივერებს და პროგრამულ უზრუნველყოფას, თუმცა ამ კომპონენტების განხორციელება თითოეულ კონკრეტულ შემთხვევაში შეიძლება მნიშვნელოვნად განსხვავდებოდეს. პროტოკოლის წარმატება უხეშად შეიძლება გამოითვალოს ფორმულის გამოყენებით: შესაძლებლობები მინუს უხერხულობა. შესაძლებლობები ეხება ხელმისაწვდომი ფუნქციების სპექტრს. ნაკლოვანებები ჩვეულებრივ მოიცავს გამოყენების გაუმჭვირვალობას, მოუხერხებელ ინსტალაციას, სწავლის სირთულეს და შეზღუდულ თავსებადობას.

ციფრული პორტატული ტექნოლოგიის სტანდარტებით, MP3 ფლეერები უკვე საკმაოდ ძველი კლასის მოწყობილობებია. ისინი გამოჩნდნენ იმ დროს, როდესაც კომპიუტერის ინფრასტრუქტურა სრულიად მოუმზადებელი იყო კომპიუტერის, როგორც მულტიმედიური მასპინძლის როლისთვის. როგორც ფიზიკურ, ასევე პროგრამულ დონეზე, არ არსებობდა ფართოდ გავრცელებული და სტანდარტიზებული გადაწყვეტილებები ამ სფეროში, ისინი მხოლოდ დამუშავების პროცესში იყვნენ, ემზადებოდნენ ბაზარზე გასასვლელად, ან არსებობდნენ ცალი რაოდენობით. პორტატული მოწყობილობების სხვა დაკავშირებული კლასები მსგავს მდგომარეობაში აღმოჩნდნენ: მობილური შესანახი მოწყობილობები, ციფრული კამერები, მობილური ტელეფონები, PDA. ყველა ამ ტიპის მობილური ტექნოლოგია გამოჩნდა დაახლოებით ერთსა და იმავე დროს, 90-იანი წლების მეორე ნახევარში. მათი გამოჩენამ მოითხოვა ერთიანი სტანდარტული პროტოკოლების შემუშავება კომპიუტერების პორტატულ აღჭურვილობასთან დასაწყვილებლად.

ფიზიკურ დონეზე ყველაფერი შედარებით ნათელი იყო. პირველი პორტატული მოწყობილობები იძულებულნი გახდნენ გამოეყენებინათ COM და LPT - იმ დროს უბრალოდ არ არსებობდა სხვა ფართოდ ხელმისაწვდომი ინტერფეისები.

LPT კონექტორი კვლავ შეგიძლიათ იპოვოთ უმეტეს კომპიუტერებზე

ამრიგად, ეს იყო LPT ფიზიკური ინტერფეისი, რომელსაც იყენებდნენ MP3 ფლეერების დამფუძნებლები, Saehan MpMan და Diamond Rio. ამ პერიოდს შეიძლება ეწოდოს „ხელოსნობა“ დეველოპერებს უნდა გამოეყენებინათ ინტერფეისები და პროტოკოლები, რომლებიც თავდაპირველად შეიქმნა სრულიად განსხვავებული ამოცანებისთვის.

თუმცა, პორტატული აუდიოს ახალ თაობას დიდხანს არ მოუწია ტანჯვა ნელი და მოუხერხებელი ინტერფეისების ბორკილებში: უკვე მომდევნო 1999 წელს მწარმოებლებმა წარმოადგინეს მოწყობილობების ფართო სპექტრი ახალი სტანდარტის გამოყენებით: USB, უნივერსალური სერიული ავტობუსი.

გარკვეული პერიოდის განმავლობაში, თითქოსდა ბრძოლა USB-სა და Firewire პროტოკოლს შორის, ძირითადად Apple Macintosh კომპიუტერებზე იყო გავრცელებული.

ომიFirewire-USB პორტატულ ფლეერებში: დანiPod 1G - მხოლოდFirewire - მდეiPod 5G - მხოლოდUSB

ამასთან, პორტატული აუდიოს დიდი ნაწილი სწრაფად და უმტკივნეულოდ გადავიდა უნივერსალურ სერიულ ავტობუსზე, ხურავს, ყოველ შემთხვევაში, სადენიანი გადაწყვეტილებების ფარგლებში, ფიზიკურ დონეზე მონაცემთა გადაცემის საკითხს.

პროგრამული პროტოკოლებისთვის საქმეები ასე მარტივად არ მუშაობდა. ამაზე მოკლე პერიოდიროდესაც მწარმოებლები აიძულეს გამოეყენებინათ COM და LPT, პროგრამული უზრუნველყოფის პროტოკოლები ექსკლუზიურად საკუთარი დიზაინით იყო. სინამდვილეში, ისინი სხვა ვერაფერი იქნებოდნენ, რადგან... ორივე COM და LPT ინტერფეისი შეიქმნა ერთ დროს, ბუნებრივია, მულტიმედიური ფაილების პორტატულ ციფრულ ფლეერებზე გადასატანად. ამ უკანასკნელისთვის დრაივერებისა და პროგრამული გარსების შემმუშავებელი არავინ იყო, გარდა თავად დეველოპერებისა და სტანდარტიზაციაზე საუბარი საერთოდ არ ყოფილა.

მაგრამ USB-ის გამოჩენამ პრობლემა არ გადაჭრა. ინდუსტრია, უპირველეს ყოვლისა, ეხება მობილური შენახვის მოწყობილობებისა და ციფრული კამერების სტანდარტული პროტოკოლების შექმნას. MP3 ფლეერებთან სიტუაცია სულაც არ იყო გასაგები: აიკრძალებოდა თუ არა და თუ არ აკრძალული იყო, მაშინ რა ფუნქციები უნდა ჰქონდეს პროტოკოლებს, რომ SDMI ფორუმს მისცეს შუქი. ასეთ პირობებში, პროგრამული უზრუნველყოფის პროტოკოლების შემუშავება მაინც დაეცა მოწყობილობის დეველოპერს. ეს გაგრძელდა მინიმუმ ოთხი წლის განმავლობაში, სანამ, საბოლოოდ, სტანდარტული მონაცემთა გადაცემის პროტოკოლები არ გამოჩნდა მოთამაშეებში. ეს წლები იყო პირველი ტიპის პროგრამული პროტოკოლების დომინირების დრო - საკუთრების თუ დახურული.

მათი დამახასიათებელი მახასიათებელი იყო ინდივიდუალური დრაივერები და პროგრამული უზრუნველყოფა თითოეული მწარმოებლისთვის და ხშირად მოთამაშეთა ყოველი ახალი თაობისთვის ერთი და იმავე მწარმოებლის პროდუქტებში.

საკუთრების პროტოკოლი, როგორც მაგალითიRCA-ტომსონილირა. იყენებს საკუთარ დრაივერს (PDP2222.SYS), რომელიც ცალ-ცალკე უნდა იყოს დაინსტალირებული თითოეულ კომპიუტერზე, რომელთანაც გეგმავთ პლეერის დაკავშირებას

ეს უამრავ უხერხულობას უქმნის მომხმარებელს. არანაირი გამჭვირვალობაზე საუბარი არ არის - მომხმარებელი თავად იძულებულია ხელით დააინსტალიროს დრაივერები და პროგრამული უზრუნველყოფა მისი ფლეერისთვის. ამ შემთხვევაში შეიძლება წარმოიშვას სხვადასხვა სირთულეები, მაგალითად, თუ მყიდველი შეცდომით აკავშირებს მოთამაშეს კომპიუტერს დრაივერების დაყენებამდე.

მოთამაშის დაკავშირების პროცედურის შერევის შემდეგ, მომხმარებელმა რისკავს აღფრთოვანებულიყო მსგავსი შეტყობინებებით, ყველა საჭირო დრაივერის შემდგომი დაყენების შემდეგაც კი.

ასევე უმჯობესია დაივიწყოთ თავსებადობა: დრაივერები და პროგრამული უზრუნველყოფა მუშაობდა მხოლოდ მოთამაშის მოცემულ მოდელთან (საუკეთესო შემთხვევაში, მოცემული მწარმოებლის რამდენიმე მოდელთან), ხოლო მოთამაშეს შეეძლო მხოლოდ კომპიუტერთან მუშაობა, რომელზეც ეს დრაივერები და პროგრამული უზრუნველყოფა იყო დაინსტალირებული. თავდაპირველად, პროგრამული უზრუნველყოფის ჭურვების შესაძლებლობები ძალიან მწირი იყო და შემოიფარგლებოდა მხოლოდ აუდიო ფაილების მოთამაშის მეხსიერებაში კოპირებით. მოგვიანებით, გამოჩნდა პლეერზე შინაარსის კოპირების მრავალი გზა: ინდივიდუალურად ტრეკის საშუალებით ან მოთამაშის მეხსიერების შინაარსის სინქრონიზაციის გზით კომპიუტერზე განთავსებული აუდიო ფაილებიდან შედგენილი ბიბლიოთეკის შინაარსთან. ზოგიერთი პროგრამული ჭურვი მხარს უჭერდა მხოლოდ ერთ მეთოდს. დროთა განმავლობაში, პროგრამამ შეიძინა დამატებითი შესაძლებლობები, მაგალითად, ნებისმიერი ფაილის კოპირება, არა მხოლოდ პლეერის მიერ მხარდაჭერილი, რამაც შესაძლებელი გახადა მისი გამოყენება როგორც შენახვის მოწყობილობა (ფუნქციას მეტსახელად Data Taxi ერქვა). თუმცა, ის ფაქტი, რომ ამ ოპერაციამ მოითხოვა დრაივერების და პროგრამული უზრუნველყოფის ინსტალაცია კომპიუტერზე, სერიოზულად შეამცირა ამ ფუნქციის სარგებლიანობა. როგორც წესი, საერთოდ არ იყო საუბარი ჭურვების მაღალ ესთეტიკურ თვისებებზე, უნაკლო სამუშაოზე და კარგ ერგონომიკაზე. მაშინ მომხმარებლები, უმეტესწილად, უხეში და ხელუხლებელი ხალხი იყვნენ: ისინი აკოპირებდნენ ფაილებს პლეერში - და ეს კარგია.

მწარმოებლების უმეტესობამ გაიარა საკუთრების სისტემები: iriver, Rio Audio, Creative, Cowon, Mpio და ა.შ. თითოეულ ამ მწარმოებელს ერთ დროს ჰქონდა საკუთარი დრაივერები და საკუთარი პროგრამული უზრუნველყოფა, ზოგი უფრო წარმატებული, ზოგი ნაკლებად წარმატებული. ნებისმიერ შემთხვევაში, როდესაც პლეერი შეიცვალა სხვა მწარმოებლის მოწყობილობაზე, მომხმარებელი იძულებული გახდა მოერგოს ახალ გარსს თავისი ლოგიკით და მახასიათებლებით. ბევრი მწარმოებელი აგრძელებს თავისი მოწყობილობების აღჭურვას დღეს ამ პროგრამებით, როგორც MSC/UMS სტანდარტების ან MTP გადაწყვეტილებების ალტერნატივა.

საკუთრებისჭურვი- მენეჯერები: Iriver Music Manager, Cowon JetAudio, Mpio Manager, Creative Play Center

ყველანაირი ჭურვის ზოოპარკი მომხმარებელს ვერ შეეფერებოდა (მათ მაინც შეეძლოთ შეეგუონ ჭრელი მძღოლების არსებობას). ის ასევე არ შეეფერებოდა მწარმოებლებს, განსაკუთრებით მცირე მწარმოებლებს, რომლებსაც არ გააჩნდათ რესურსები მაღალი ხარისხის პროგრამული უზრუნველყოფის შესაქმნელად. ამიტომ, 1999 წელს - 2000-იანი წლების დასაწყისში, მესამე მხარის ჭურვების გამოყენებამ გარკვეული პოპულარობა მოიპოვა.

მათ შორის არის MusicMatch Jukebox პროგრამა.

ინტერფეისიMusicMatch ჯუკბოქსი

Windows PC-სთვის iTunes-ის მოსვლამდე, ის აქ გამოიყენებოდა Apple iPod-თან მუშაობისთვის. ის ასევე მუშაობდა სხვა მწარმოებლების მოთამაშეებთან, როგორიცაა RCA-Thomson.

პროგრამები, როგორიცაა MusicMatch Jukebox, იყო სტანდარტიზაციის პირველი თესლი. მათ შესაძლებელი გახადეს სხვადასხვა მწარმოებლის მოთამაშეების გამოყენება თითოეული მათგანისთვის დამატებითი პროგრამული უზრუნველყოფის დაყენების გარეშე. გამოსავალი არ იყო უნაკლო, ეს იყო მხოლოდ ნაბიჯი მრავალფეროვანი პროტოკოლებიდან და ჭურვიდან სტანდარტიზებულ გადაწყვეტებამდე. ამ შემთხვევაში, მხოლოდ პროტოკოლის კონტროლის ინტერფეისი იყო სტანდარტიზებული თითოეული მოწყობილობისთვის ცალკეული დრაივერების დაყენება. თავად ჭურვები არ იყო ოპერაციული სისტემის ნაწილი, ისინი უნდა დაყენებულიყო ცალკე, ინტერნეტიდან ან თანმხლები CD-დან. მათი ფუნქციონალობა, სტაბილურობა და მოხერხებულობა ხშირად აჩენდა კითხვებს. ყველა მოთამაშე არ იყო მხარდაჭერილი, რამაც აიძულა მწარმოებლები აღჭურვა მათი მოწყობილობები პლაგინებით პოპულარული პროგრამის მენეჯერებისთვის.

ხელმისაწვდომია საიტზე ჩამოტვირთვისთვისRCA-Lyra: ძირითადად მოდული ამისთვისMusicMatchჯუკბოქსი და მხოლოდ ამის შემდეგ საკუთარი ჭურვილირადიჯეი

ჩვეულებრივ, დროთა განმავლობაში, პროგრამა "გამსუქდა", გადაიზარდა მომხმარებლისთვის არასაჭირო ფუნქციებით, რეკლამით და მოითხოვდა უფრო და უფრო მეტ რესურსს.

წარსულში კიდევ ერთი პოპულარული ჭურვი არისRealJukebox

ამავდროულად, კონკურენტული წნევა იზრდებოდა: 2001 წელს Windows Media Player გახდა სტანდარტული Windows XP-ით, ხოლო 2003 წელს გამოჩნდა iTunes for Windows. მცირე აზიურმა კომპანიებმა 2002-2003 წლებში ასევე იპოვეს ამ პროგრამული უზრუნველყოფის კარგი შემცვლელი - ღია MSC/UMS პროტოკოლი. შედეგად, ჭურვები, როგორიცაა MusicMatch Jukebox, ჩამოვარდა სცენაზე, რათა ადგილი დაუთმო შემდეგი თაობის პროტოკოლებს. მაგრამ მათი მემკვიდრეობა უშედეგო არ იყო: "ერთი გარსი სხვადასხვა მოთამაშეებისთვის" მოდელი დიდწილად მემკვიდრეობით მიიღო Microsoft PlaysForSure სისტემამ.

თუმცა, საკუთრების სისტემების ერთ-ერთმა მახასიათებელმა მათ საშუალება მისცა გადარჩენილიყვნენ იმაზე მეტხანს, ვიდრე გონივრულია გარკვეულ ბაზრებზე. მათმა დახურულმა ბუნებამ შექმნა დაბრკოლებები პლეერის გამოყენებისას კომპიუტერიდან კომპიუტერში მონაცემების თავისუფლად გადასატანად, ანუ, RIAA-ს თანახმად, ციფრული მეკობრეობის ინსტრუმენტად გამოყენებისას. პრობლემურ ბაზრებზე, როგორიცაა ამერიკის, კომპანიები, რომლებსაც არ სურთ ზედმეტი ყურადღების მიქცევა, განაგრძეს საკუთრების მიდგომა ზოგადი გადაწყვეტილებების გაჩენის შემდეგაც კი.

საიტზეiriver-ის არაკომერციული firmware ჯერ კიდევ სპეციალურად აღინიშნება, როგორცUMS ანMTP

აქ შეგიძლიათ გახსოვდეთ, მაგალითად, iriver ან Creative. iriver მოთამაშეები ძირითადად იწარმოებოდა ორი ვერსიით: აშშ-ს ბაზრისთვის - მუშაობდა საკუთრების პროტოკოლით, სხვებისთვის - ღია MSC/UMS-ის საშუალებით. დახურული პროტოკოლებისთვის ეს „სიცოცხლე სიკვდილის შემდეგ“ გაგრძელდა 2004 წელს MTP პროტოკოლის გამოქვეყნებამდე, რომელიც შედარებით უნივერსალური იყო, მაგრამ ჩამწერ კომპანიებსაც შეეფერებოდა.

პერიოდი 2002-2004 წწ იყო გადასვლა დახურული სისტემების „ბნელი ხანიდან“ თანამედროვე პროტოკოლების შედარებით ღიაობამდე. დღეს, სუფთა საკუთრების პროტოკოლები სრულიად გამორთულია.

თქვენ ალბათ გსმენიათ ფრაზა, "თქვენ უნდა გამოიყენოთ VPN თქვენი კონფიდენციალურობის დასაცავად". ახლა თქვენ ფიქრობთ: "კარგი, მაგრამ როგორ მუშაობს VPN?"

ინტერნეტში ბევრი სტატიაა, რომელიც გვთავაზობს ერთი პროტოკოლის გამოყენებას, მაგრამ ცოტამ დაუთმო დრო VPN-ის ძირითადი ტექნოლოგიების ახსნას. ამ სტატიაში მე აგიხსნით რა არის VPN პროტოკოლები, მათი განსხვავებები და რა უნდა მოძებნოთ.

რა არის VPN?

სანამ კონკრეტულ VPN პროტოკოლებს გადავხედავთ, მოდით სწრაფად გადავხედოთ რა არის VPN.

არსებითად, VPN საშუალებას გაძლევთ შეხვიდეთ საჯარო ინტერნეტში პირადი კავშირის გამოყენებით. როდესაც თქვენ დააწკაპუნეთ ბმულზე ინტერნეტში, თქვენი მოთხოვნა მიდის სწორ სერვერზე, როგორც წესი, აბრუნებს სწორ შინაარსს. თქვენი მონაცემები არსებითად შეუფერხებლად მიედინება A-დან B-მდე და ვებსაიტს ან სერვისს შეუძლია დაინახოს თქვენი IP მისამართი სხვა საიდენტიფიკაციო მონაცემებთან ერთად.

როდესაც იყენებთ VPN-ს, ყველა თქვენი მოთხოვნა პირველად გადაიცემა VPN პროვაიდერის საკუთრებაში არსებულ კერძო სერვერზე. თქვენი მოთხოვნა გადადის A-დან C-მდე B-ის მეშვეობით. თქვენ შეგიძლიათ წვდომა ყველა მონაცემზე, რომელიც ადრე იყო თქვენთვის ხელმისაწვდომი (და ზოგიერთ შემთხვევაში, უფრო მეტზე). მაგრამ ვებსაიტს ან სერვისს აქვს მხოლოდ VPN პროვაიდერის დეტალები: მათი IP მისამართი და ა.შ.

VPN-ს მრავალი გამოყენება აქვს, მათ შორის თქვენი მონაცემებისა და პირადობის დაცვა, მჩაგვრელი ცენზურის თავიდან აცილება და თქვენი კომუნიკაციების დაშიფვრა.

რა არის VPN პროტოკოლები?

VPN პროტოკოლი ზუსტად განსაზღვრავს, თუ როგორ ხდება თქვენი მონაცემები თქვენს კომპიუტერსა და VPN სერვერს შორის. პროტოკოლებს განსხვავებული სპეციფიკაციები აქვთ, რაც მომხმარებლებს უპირატესობებს სთავაზობს სხვადასხვა გარემოებებში. მაგალითად, ზოგი უპირატესობას ანიჭებს სიჩქარეს, ზოგი კი ყურადღებას ამახვილებს კონფიდენციალურობაზე და უსაფრთხოებაზე.

მოდით გადავხედოთ ყველაზე გავრცელებულ VPN პროტოკოლებს.

1. OpenVPN

OpenVPN არის ღია კოდის VPN პროტოკოლი. ეს ნიშნავს, რომ მომხმარებლებს შეუძლიათ შეამოწმონ წყაროს კოდი დაუცველობისთვის ან გამოიყენონ იგი სხვა პროექტებში. OpenVPN გახდა ერთ-ერთი ყველაზე მნიშვნელოვანი VPN პროტოკოლი. OpenVPN არის ღია წყარო და არის ერთ-ერთი ყველაზე უსაფრთხო პროტოკოლი. OpenVPN საშუალებას აძლევს მომხმარებლებს დაიცვან თავიანთი მონაცემები არსებითად შეუვალი AES-256 გასაღების დაშიფვრის გამოყენებით (სხვათა შორის), 2048-ბიტიანი RSA ავტორიზაცია და 160-ბიტიანი SHA1.

გარდა ძლიერი დაშიფვრის უზრუნველყოფისა, OpenVPN ასევე ხელმისაწვდომია თითქმის ყველა პლატფორმისთვის: Windows, MacOS, Linux, Android, iOS, მარშრუტიზატორები და სხვა. თუნდაც Windows Phoneდა Blackberry-ს შეუძლია მისი გამოყენება!

OpenVPN პროტოკოლი წარსულში გააკრიტიკეს იმის გამო დაბალი სიჩქარით. თუმცა, ბოლოდროინდელმა განხორციელებებმა გარკვეული დაჩქარება დაფიქსირდა და ყურადღება უნდა მიექცეს უსაფრთხოებასა და კონფიდენციალურობას.

2.L2TP/IPSec

Layer 2 Tunnel Protocol არის ძალიან პოპულარული VPN პროტოკოლი. L2TP არის მოძველებული PPTP-ის მემკვიდრე (იხილეთ PPTP სექცია ქვემოთ დამატებითი დეტალებისთვის) შემუშავებული Microsoft-ისა და L2F-ის მიერ შემუშავებული Cisco-ს მიერ. თუმცა, L2TP რეალურად არ უზრუნველყოფს რაიმე დაშიფვრას ან კონფიდენციალურობას.

შესაბამისად, სერვისები, რომლებიც იყენებენ L2TP-ს, ხშირად ასოცირდება IPsec უსაფრთხოების პროტოკოლთან. განხორციელების შემდეგ, L2TP/IPSec ხდება ერთ-ერთი ყველაზე უსაფრთხო VPN კავშირი. ის იყენებს AES-256 ბიტიან დაშიფვრას და არ აქვს ცნობილი დაუცველობა (თუმცა IPSec, სავარაუდოდ, კომპრომეტირებული იყო NSA-ს მიერ).

თუმცა, მიუხედავად იმისა, რომ L2TP/IPSec-ს არ აქვს ცნობილი დაუცველობა, მას აქვს მცირე უარყოფითი მხარეები. მაგალითად, ნაგულისხმევად პროტოკოლი იყენებს UDP პორტს 500. ეს აადვილებს ტრაფიკის აღმოჩენას და დაბლოკვას.

3.SSTP

Secure Socket Tunneling Protocol არის კიდევ ერთი პოპულარული VPN პროტოკოლი. SSTP-ს აქვს ერთი მნიშვნელოვანი უპირატესობა: ის სრულად არის ინტეგრირებული ყველასთან ოპერაციული სისტემა Microsoft Windows Vista SP1-ის დაყენებიდან. ეს ნიშნავს, რომ შეგიძლიათ გამოიყენოთ SSTP Winlogon-თან ერთად ან დამატებითი უსაფრთხოებისთვის ჭკვიანი ჩიპი. გარდა ამისა, ბევრ VPN პროვაიდერს აქვს ჩაშენებული კონკრეტული SSTP ინსტრუქციები Windows-ისთვის. მათი ნახვა შეგიძლიათ VPN პროვაიდერის ვებსაიტზე.

SSTP იყენებს 2048-ბიტიან SSL/TLS სერთიფიკატებს ავტორიზაციისთვის და 256-ბიტიან SSL გასაღებებს დაშიფვრისთვის. საერთო ჯამში, SSTP საკმაოდ უსაფრთხოა.

SSTP არსებითად არის Microsoft-ის საკუთრების პროტოკოლი. ეს ნიშნავს, რომ ვერავინ შეძლებს სრულად შეამოწმოს ძირითადი კოდი. თუმცა, მათი უმეტესობა კვლავ მიიჩნევს SSTP უსაფრთხოდ.

დაბოლოს, SSTP-ს აქვს Windows, Linux და BSD სისტემების მშობლიური მხარდაჭერა. Android, macOS და iOS მხარს უჭერენ მესამე მხარის კლიენტებს.

4. IKEv2

Internet Key Exchange ვერსია 2 არის კიდევ ერთი VPN პროტოკოლი, რომელიც შემუშავებულია Microsoft-ისა და Cisco-ს მიერ. თავად IKEv2 არის გვირაბის პროტოკოლი, რომელიც უზრუნველყოფს გასაღების გაცვლის უსაფრთხო სესიას. ამიტომ (მისი წინამორბედის მსგავსად), IKEv2 ხშირად წყვილდება IPSec-თან დაშიფვრისა და ავთენტიფიკაციისთვის.

მიუხედავად იმისა, რომ IKEv2 არ არის ისეთი პოპულარული, როგორც სხვა VPN პროტოკოლები, მას აქვს მრავალი მობილური VPN გადაწყვეტა. ეს გამოწვეულია იმით, რომ მას შეუძლია ხელახლა დაკავშირება ინტერნეტის დროებითი დაკარგვის მომენტებში, ასევე ქსელის გადართვის დროს (მაგალითად, Wi-Fi-დან მობილურ მონაცემამდე).

IKEv2 არის საკუთრების პროტოკოლი Windows, iOS და Blackberry მოწყობილობების მშობლიური მხარდაჭერით. ღია კოდის ვერსიები ხელმისაწვდომია Linux-ისთვის, ხოლო Android-ის მხარდაჭერა ხელმისაწვდომია მესამე მხარის აპლიკაციების საშუალებით.

სამწუხაროდ, მიუხედავად იმისა, რომ ikev2 პროტოკოლი შესანიშნავია მობილური კომუნიკაციებიარსებობს ძლიერი მტკიცებულება იმისა, რომ აშშ-ის NSA აქტიურად იყენებს მის ხარვეზებს IPSec ტრაფიკის შეფერხების მიზნით.

5.PPTP

წერტილიდან წერტილამდე გვირაბის პროტოკოლი არის ერთ-ერთი უძველესი VPN პროტოკოლი. ის ჯერ კიდევ გამოიყენება ზოგიერთ ადგილას, მაგრამ სერვისების უმეტესობა დიდი ხანია განახლებულია უფრო სწრაფ და უსაფრთხო პროტოკოლებზე.

PPTP დაინერგა ჯერ კიდევ 1995 წელს. ის რეალურად ინტეგრირებული იყო Windows 95-თან, რომელიც შექმნილია dial-up კავშირებთან მუშაობისთვის. ეს იყო ძალიან სასარგებლო იმ დროს.

მაგრამ VPN ტექნოლოგია განვითარდა და PPTP აღარ არის უსაფრთხო. მთავრობებმა და კრიმინალებმა დიდი ხანია დაარღვიეს PPTP დაშიფვრა, რაც პროტოკოლით გაგზავნილ ნებისმიერ მონაცემს დაუცველს ხდის.

თუმცა, ის ჯერ არ არის მთლად მკვდარი... ხედავთ, ზოგს სჯერა, რომ PPTP უკეთეს შეერთების სიჩქარეს იძლევა ზუსტად უსაფრთხოების მახასიათებლების არარსებობის გამო (თანამედროვე პროტოკოლებთან შედარებით). ამრიგად, ის კვლავ გამოიყენება, რადგან მომხმარებლებს უბრალოდ სურთ ნახონ Netflix სხვა ადგილიდან.

მოდით შევაჯამოთ VPN პროტოკოლები

ჩვენ გადავხედეთ ხუთ მთავარ VPN პროტოკოლს. მოდით სწრაფად შევაჯამოთ მათი დადებითი და უარყოფითი მხარეები.

OpenVPN:არის ღია წყარო, გთავაზობთ უძლიერეს დაშიფვრას, რომელიც შესაფერისია ყველა აქტივობისთვის, აქვს ოდნავ ნელი კავშირის დრო.

L2TP/IPSec:ფართოდ გამოყენებული პროტოკოლი, კარგი სიჩქარე, მაგრამ ადვილად იბლოკება ერთ პორტზე დამოკიდებულების გამო.

SSTP:კარგი უსაფრთხოება, რთული დაბლოკვა და აღმოჩენა.

IKEv2:სწრაფი, მოსახერხებელი მობილური მოწყობილობები, რამდენიმე ღია კოდის განხორციელებით (პოტენციურად ძირს უთხრის NSA-ს მიერ).

PPTP:სწრაფი, ფართოდ მხარდაჭერილი, მაგრამ სავსე უსაფრთხოების ხვრელებით, გამოიყენება მხოლოდ სტრიმინგისთვის და ძირითადი ვებ დათვალიერებისთვის.

სრული უსაფრთხოებისა და სიმშვიდისთვის, აირჩიეთ VPN პროვაიდერი, რომელიც გთავაზობთ პროტოკოლების არჩევანს. ალტერნატიულად, შეგიძლიათ გამოიყენოთ ფასიანი VPN გადაწყვეტილებები, როგორიცაა ExpressVPN, ვიდრე უფასო სერვისი. როდესაც იხდით VPN-ს, თქვენ ყიდულობთ სერვისს. როდესაც იყენებთ უფასო VPN-ს, წარმოდგენაც არ გაქვთ, რისი გაკეთება შეუძლიათ მათ თქვენს მონაცემებთან.

რომელ VPN პროტოკოლს იყენებთ ჩვეულებრივ? გთავაზობთ თუ არა თქვენი VPN პროვაიდერი არჩევანს? უთხარით კომენტარებში!

2017 წლის 17 ივლისი , BIS ჟურნალი No3(26)/2017წ

უსაფრთხო წვდომის ტექნოლოგიებისა და პროტოკოლების შედარება

VPN არის ყველა ინფორმაციული უსაფრთხოების სისტემის განუყოფელი ნაწილი, მათ შორის ის, ვინც იცავს ფინანსური ორგანიზაციების საინფორმაციო სისტემებს. ეს ტექნოლოგია არის უმარტივესი, ყველაზე გასაგები და ხელმისაწვდომი გზა გეოგრაფიულად განაწილებული საიტების უსაფრთხოდ გაერთიანებისა და ინფორმაციის საიმედოდ დასაცავად საჯარო ქსელებში გადაცემისას.

VPN გამოყენების მრავალი სცენარი არსებობს: დისტანციურ ოფისებს შორის ურთიერთქმედების ორგანიზება, დისტანციური თანამშრომლების ან კლიენტების დაკავშირება, ბანკომატების დაკავშირება, მონაცემთა ცენტრების წვდომა, რომლებშიც კონცენტრირებულია ბანკის საინფორმაციო სისტემების რესურსები. გარდა ურთიერთქმედების უზრუნველსაყოფად, ზოგიერთ შემთხვევაში VPN საშუალებას გაძლევთ შექმნათ მკაფიო დაცვის პერიმეტრი და უზრუნველყოთ საინფორმაციო სისტემის სეგმენტების ხელმისაწვდომობა.

თუმცა, სანამ კონკრეტული გადაწყვეტის პროვაიდერის არჩევას დაიწყებთ, აუცილებელია და მნიშვნელოვანია გვესმოდეს, რა VPN ტექნოლოგიები არსებობს და რა განსხვავებებია მათ შორის.

საკუთრების პროტოკოლები

მონაცემთა გადაცემის ყველა პროტოკოლი იყოფა ორ კატეგორიად.

პირველი კატეგორია, რომელიც განხილული იქნება, არის საკუთრების (დახურული) პროტოკოლები და ტექნოლოგიები, რომლებიც ცალკეული კომპანიების ინტელექტუალური საკუთრებაა. ამ მიდგომის უპირატესობა ის არის, რომ ტექნოლოგია შეიძლება შედარებით სწრაფად შეიცვალოს, რათა დააკმაყოფილოს აღჭურვილობის მწარმოებლის მოთხოვნები ან კონკრეტული მომხმარებლის სურვილები. თუმცა, ასევე არის მთელი რიგი უარყოფითი მხარეები.

პირველ რიგში, დიდია იმის ალბათობა, რომ მომხმარებელი საკუთარი ხარჯებით გახდეს კვლევისა და ტექნიკური გაუმჯობესების ობიექტი. იმისათვის, რომ შემცირდეს არქიტექტურული შეცდომების რისკი, აუცილებელია შემუშავება მაქსიმალურად სრულად ახალი ტექნოლოგიარაც შეიძლება ფართო სპექტრის ექსპერტების ჩართვა. სამწუხაროდ, რუსი მოვაჭრეების მომხმარებელთა ბაზა, რომლებიც იყენებენ საკუთრების პროტოკოლებს, ყოველთვის არ იძლევა ამის საშუალებას. სხვათა შორის, უცხოური IT ბაზრის ლიდერები არ მიდიან საკუთრების პროტოკოლების შექმნის გზას. ისინი ავითარებენ ზოგადად მიღებული პროტოკოლების ფუნქციონირებას, ხსნიან წვდომას მათ ტექნოლოგიაზე და აქცევენ მას საჯარო, ხელმისაწვდომი სხვა მწარმოებლებისთვის.

მეორეც, მნიშვნელოვანი მინუსი არის ის, რომ პროდუქტის არასტანდარტული დიზაინი და არადოკუმენტირებული მოწყობილობის ქცევა მომხმარებელს შეუძლია პროდუქტის მომწოდებელზე დამოკიდებული გახადოს. თუ სერვისის ან მომსახურების ხარისხი აღარ შეესაბამება მომხმარებელს, საკუთრების პროტოკოლიდან მეორეზე გადასვლა შეიძლება იყოს ძალიან ძვირი, ან თუნდაც შეუძლებელი უსაფრთხოების სისტემის სრული რემონტის გარეშე. საუკეთესო შემთხვევაში, მომხმარებელს შეუძლია იმედი ჰქონდეს გამოყენებული ტექნიკის პლატფორმების გამოყენებაზე, რომლებზეც შესაძლებელია ახალი პროგრამული უზრუნველყოფის დაყენება. S-Terra CSP-ის სპეციალისტებს უკვე ჰქონდათ თავიანთი VPN კარიბჭის Stonesoft-ის პლატფორმებზე დაყენების გამოცდილება (რომელიც, მიუხედავად იმისა, რომ იყენებდა სტანდარტულ პროტოკოლებს, ცნობილია, რომ შეწყვიტა აქტიური საქმიანობა ქსელის უსაფრთხოების ბაზარზე რუსეთში).

მესამე, ნებისმიერი არასტანდარტული დიზაინი ქმნის პრობლემებს მოწყობილობების პრობლემების აღმოფხვრის ან გაუმართაობის დროს. აუცილებელია პერსონალზე იყოს ადამიანები, რომლებმაც იციან როგორც სტანდარტული აღჭურვილობის ქცევა, ასევე კონკრეტული მწარმოებლის ტექნოლოგიების სპეციფიკური მოქმედება.

და მეოთხე, თქვენ უნდა გაითვალისწინოთ ის ფაქტი, რომ საკუთრების პროტოკოლს აქვს სხვა მწარმოებლებთან თავსებადობის მიღწევის მინიმალური შანსები.

საჯარო პროტოკოლები

მეორე კატეგორია არის საჯარო (ან სტანდარტული) პროტოკოლები, რომლებიც შეიძლება გამოყენებულ იქნას სხვადასხვა გამყიდველების მიერ წარმოებულ აღჭურვილობაში. ამ ტექნოლოგიების აღწერა მოცემულია ინტერნეტ ინჟინერიის სამუშაო ჯგუფის (IETF) სპეციალურ დოკუმენტებში (Request for Comments, RFC). ისინი შექმნილია და ავსებენ საუკეთესო ინდუსტრიის ექსპერტებს. VPN-სთვის ყველაზე ხშირად გამოყენებული საჯარო პროტოკოლებია IPsec და SSL სხვადასხვა ვარიაციით.

SSL (TLS)

პროტოკოლების ეს ოჯახი შექმნილია კლიენტის დისტანციური წვდომის უზრუნველსაყოფად და ორიენტირებულია კონკრეტულზე მორგებული აპლიკაციები. SSL (TLS) გამოყენების რამდენიმე ვარიანტი არსებობს:

უკლიენტო რეჟიმი.ეს რეჟიმი იყენებს ცალმხრივ ავთენტიფიკაციას სერვერიდან კლიენტის მხარეს. ამ შემთხვევაში, მომხმარებელს არ სჭირდება სპეციალიზებული კლიენტის პროგრამული უზრუნველყოფის ინსტალაცია ტრაფიკის დასაცავად, საკმარისია სამუშაო სადგურზე მხოლოდ კრიპტოპროვაიდერის არსებობა. ამ რეჟიმში მუშაობა შესაძლებელია მხოლოდ ვებ აპლიკაციებით, ხოლო რუსულ რეალობაში არის კავშირი არც თუ ისე პოპულარულ Internet Explorer ბრაუზერთან. მოქმედების ეს რეჟიმი შესაფერისია, მაგალითად, სცენარების შეზღუდული ჩამონათვალისთვის ვებ პორტალზე უსაფრთხო წვდომისთვის.

კლიენტის რეჟიმი.თუ თქვენ გჭირდებათ რაიმე სხვა აპლიკაციაზე წვდომის უზრუნველყოფა, გამოიყენება სპეციალური SSL (TLS) კლიენტი. ამ რეჟიმში შესაძლებელია ორმხრივი ავთენტიფიკაციის გამოყენება.
პროტოკოლის ერთ-ერთი მთავარი უპირატესობა არის კლიენტის პირადი კონფიგურაციის არარსებობა ან მინიმალური საჭიროება. თუმცა, თუ სამუშაო სადგურზე დაინსტალირებულია ახალი პროგრამა ან ახალი სერვისი, რომელიც მოითხოვს წვდომას, მომხმარებელს დასჭირდება ამ პარამეტრების დამატება კლიენტის პარამეტრებში.

თქვენ ასევე უნდა გაითვალისწინოთ ის ფაქტი, რომ სტანდარტული SSL მუშაობს აპლიკაციის დონეზე და ვერ იცავს ტრაფიკს ქსელის აღჭურვილობისგან ან ქსელის სეგმენტებისგან. DTLS პროტოკოლს შეუძლია ამ პრობლემის გადაჭრა, მაგრამ მას ასევე აქვს კლიენტ-სერვერის მოდელი და ფართოდ არ გამოიყენება რუს მწარმოებლებს შორის.

IPsec მუშაობს OSI მოდელის ქვედა ფენაზე და არ საჭიროებს აპლიკაციის მხარდაჭერას მუშაობისთვის. ის შესანიშნავია უსაფრთხო კავშირების შესაქმნელად, როგორც ფილიალებს შორის გეოგრაფიულად განაწილებულ ქსელში, ასევე უსაფრთხო დისტანციური წვდომის ორგანიზებისთვის.

ქსელის დონეზე მომუშავე პროტოკოლის გამო, VPN ოპერაცია არ საჭიროებს პროგრამულ ცვლილებებს სამუშაო ადგილზე. მომხმარებლის ყველა აპლიკაცია მუშაობს „გამჭვირვალედ“ და არ იცის VPN-ის არსებობის შესახებ. პროტოკოლი ყოველთვის უზრუნველყოფს ორმხრივ ავთენტიფიკაციას.

დისტანციური წვდომის განხორციელებისას საჭიროა კლიენტის პერსონალიზებული კონფიგურაცია თითოეული კონკრეტული სამუშაო სადგურისთვის. ამავდროულად, კლიენტი იცავს ყველა ქსელურ ურთიერთქმედებას სამუშაო სადგურსა და დისტანციურ ქსელს შორის. შესაბამისად, მომხმარებლის სამუშაო ადგილებზე სამუშაო სადგურებზე არასანქცირებული წვდომისგან დაცვის საშუალებების არსებობის აუცილებლობა უფრო აქტუალურია, ვიდრე SSL-ის შემთხვევაში.

IPsec არის ყველაზე ცნობილი პროტოკოლი VPN-ების შესაქმნელად და აგრძელებს განვითარებას. გამოჩნდა IKE გასაღების განაწილების პროტოკოლის მეორე ვერსია, პროტოკოლის დასტა არის IPv6 სტანდარტის ნაწილი.

ზემოაღნიშნულის გარდა, სტანდარტულ პროტოკოლებს IPsec და SSL (TLS) აქვთ გარკვეული უპირატესობები რუსულ რეალობაში. ჩვენ ვსაუბრობთ სტანდარტიზაციის ტექნიკური კომიტეტის საქმიანობაზე "კრიპტოგრაფიული ინფორმაციის დაცვა" (TC 26) კრიპტოგრაფიისთვის რუსულ GOST სტანდარტებში ერთიანი შემცვლელი ერთეულების და ელიფსური მრუდის პარამეტრების გამოყენების რეკომენდაციების შემუშავების სფეროში, აგრეთვე მათ გამოყენებაზე. მონაცემთა გადაცემის პროტოკოლებში. ამ საქმიანობამ უკვე გამოიღო ნაყოფი - არაერთმა რუსმა მწარმოებელმა, მათ შორის კომპანია S-Terra SSP-მა, უზრუნველყო მათი სერტიფიცირებული გადაწყვეტილებების თავსებადობა IPsec პროტოკოლის გამოყენებისას. რა თქმა უნდა, საკუთრების პროტოკოლები რომ ყოფილიყო გამოყენებული, ასეთი შედეგები არ იქნებოდა მიღწეული. მიუხედავად იმისა, რომ ასეთი პროცესები სწრაფად არ ხდება, მომხმარებლებს აქვთ სანუკვარი ოცნების ასრულების პერსპექტივა - სხვადასხვა სერტიფიცირებული VPN გადაწყვეტილებების ერთმანეთთან ტექნიკური თავსებადობის გაჩენა.

სტანდარტული პროტოკოლების გამოყენება სხვადასხვა სფეროში (Syslog, SNMP, Netflow და ა.შ.) საშუალებას გაძლევთ დააკავშიროთ პროდუქტები ერთ სისტემაში. მაგალითად, ეს პრაქტიკა ზოგადად მიღებულია მონიტორინგისა და SIEM სისტემების მშენებლობის პრობლემების გადაჭრისას.

ჩვენ ვაკეთებთ დასკვნებს

სტანდარტული პროტოკოლის არჩევისას მომხმარებელმა უნდა განსაზღვროს სასურველი გამოყენების შემთხვევა. თუ მისთვის საკმარისია მხოლოდ ინდივიდუალური სერვისების დაცვა და დაყენების სიმარტივე მნიშვნელოვანია - SSL (TLS), თუ საჭიროა ობიექტებს შორის სრული ქსელური კავშირი - მისი არჩევანია IPSec.

ამავე დროს, უნდა გვახსოვდეს, რომ მონაცემთა გადაცემის პროტოკოლის გარდა, თითოეულ გადაწყვეტას აქვს დიდი რაოდენობით სხვადასხვა ტექნოლოგიებიდა თვისებები. აქედან გამომდინარე, ღირს მთლიანობაში პროდუქტების შეფასება და შედარება, განსახილველი ამოცანის მიხედვით.

დღეს მე ვისაუბრებ მშვენიერ სამაუწყებლო პროტოკოლზე RTMFP. ის ახორციელებს ბევრ საინტერესო მიდგომას და არსებობს უამრავი ცრურწმენა მის შესაძლებლობებთან დაკავშირებით. მინდა ამ თემის მიმართ ინტერესი გავაღვივოთ და არსებული ილუზიები გავფანტოთ. პირდაპირი ეთერისთვის უკეთესი ვერაფერი ვიპოვე, ამიტომ გადავწყვიტე დამეწერა ეს პოსტი.

ფონი

დიდი ხნის წინ შორეულ გალაქტიკაში...
2004 წელს ცხოვრობდა Amicima, Inc.რომელშიც შემუშავდა GPL პროტოკოლის იმპლემენტაცია MFP - MFPNet. მერე გაათავისუფლეს amiciPhone- სკაიპის ერთ-ერთი კონკურენტი, მაგრამ პოზიციონირების პრობლემების გამო საქმე არც ისე კარგად წავიდა. 2007 წელს ისინი Adobe-მ შეიძინა, რადგან მათ სჭირდებოდათ კარგი რეალურ დროში სამაუწყებლო პროტოკოლი.

რა ჭირს RTMP-ს?

RTMPარ არის რეალურ დროში სამაუწყებლო პროტოკოლი:

• შეფერხებების მინიმიზაციის პრობლემა არ მოგვარდება;
• მაუწყებლობა ჩერდება მოწყობილობის მისამართის შეცვლისას;
• TCP მნიშვნელოვნად ზრდის შეყოვნებას და აფუჭებს შეტყობინებებს მიწოდების არასაჭირო შემოწმებებით;
• ფანჯრის ზომის კონტროლი არ არის.

მობილური ქსელების განვითარების სიჩქარის გათვალისწინებით, Amicima-ს შეძენა საკმაოდ ლოგიკური და პერსპექტიული გადაწყვეტილება იყო.

წინასწარი წარმოდგენები RTMFP-ის შესახებ

1. ეს არის საკუთრების პროტოკოლი

   Adobe-მ გადაწყვიტა მისი გამოქვეყნება ფორმაში RFC7016საზოგადოების ყურადღების მიქცევის მიზნით, მაგრამ როგორღაც გამოუვიდა. უცნაურად საკმარისია, რომ ეს არ ჰგავს ცრუ RTMP სპეციფიკაციას და უფრო ჰგავს MFP-ს.

   პროტოკოლი თავისთავად მოდულარულია: სერტიფიკატების გაცვლა, დაშიფვრა და ნაკადის სინქრონიზაცია განხორციელებულია ცალკე პროფილის სახით. რაც ხდება Flash-ში რჩება Flash-ში. მესამე მხარის გადაწყვეტილებების დეველოპერებისთვის, როგორიცაა კუმულუსი,Flash დარჩა შავ ყუთად; რატომღაც ჩუმად და შეუმჩნევლად გამოვიდა 2014 წლის აპრილში Adobe-ს RTMFP პროფილი Flash კომუნიკაციისთვის.

2. ეს არის UDP - რაც ნიშნავს, რომ მიწოდების გარანტია არ არსებობს

   რეალურ დროში საკმაოდ ბევრი პროტოკოლი იყენებს UDP-ს და ამატებს ქსელის საკონტროლო ჯამს და შერჩევითი მიწოდების შემოწმებებს მიწოდების გარანტირებისთვის. ისინი ამოწმებენ მხოლოდ იმას, რაც უნდა მოვიდეს და არა ყველაფერს ზედიზედ. აუდიო/ვიდეოსთვის, პაკეტის მიწოდების კონტროლს უფრო მეტი აზრი არ აქვს. ფანჯრის ზომა (MTU) ჩვეულებრივ მაქსიმალური და სტატიკურია, რაც ზრდის ცარიელი დაკვრის სიტუაციის ალბათობას შემდგომში შეუსაბამო მონაცემების მიღებისას, როდესაც პაკეტი დაიკარგება.

3. ჩვენ არ გვჭირდება RTMFP - ჩვენ გვაქვს WebRTC

   WebRTCეს არ არის პროტოკოლი, ეს არის ბრაუზერის ტექნოლოგია - SIP-ის RTP სტეკთან ინტეგრირების მცდელობა ბრაუზერში. თუ თქვენ დააკავშირებთ RTP, SRTP, SCTP, RTCP, ZRTP, RTSP, მიიღებთ RTMFP. მაგრამ რიგ შემთხვევებში, ასეთ კავშირებს აქვთ ჭარბი რაოდენობა და პრობლემები, რომლებიც არ არის RTMFP-ში.

   RTMFP-ს აქვს გადამისამართება NAT-ის საშუალებით, ფანჯრის ზომის კონტროლი, მეტამონაცემები ნაკადებისთვის, ზედმეტობის კონტროლით აპლიკაციის მხარეს, გადამისამართების/გადამისამართების სესიები და საკუთარი DHT.

   რამდენი RTP-ის მსგავსი პროტოკოლი გჭირდებათ ამ ყველაფრის დანერგვისთვის?.. 4-5 ცალი მგონია.

   სამაუწყებლო პროტოკოლების ამჟამინდელი განხორციელება ჰგავს სიტუაციას:
   

   „6 პროტოკოლია, მაგრამ ყველა მათგანს აქვს საბედისწერო ხარვეზი და ჩვენ კიდევ ერთს შევიმუშავებთ...“
   ერთი წელი გადის.
   "არსებობს 7 ოქმი და ყველა მათგანს აქვს საბედისწერო ნაკლი..."

   
   RTMFP არ არის არსებული გადაწყვეტილებების შეცვლის მცდელობა. ეს არის მათი განზოგადების მცდელობა, მოშორება ზედმეტი და ხელმისაწვდომი გახადოს მომხმარებლებისთვის.

RTMFP და OSI მოდელი

მოდით შევხედოთ OSI მოდელის რა ფენებს მოიცავს RTMFP პროტოკოლი.

• ფიზიკური და არხი

  არ არსებობს ეფემერული ენერგეტიკული რყევები მოციმციმე პეპლებისგან, მაგრამ ჩვენ გვსურს ჭარბი რაოდენობა მონაცემთა გადაცემის გზით დეფორმირებული ქვესივრცეში.

• ქსელი და ტრანსპორტი

  ეს არის IP და UDP multicast.
  არსებობს Path MTU აღმოჩენა და შეშუპების კონტროლი, უკვე ყუთში, თითოეული კონკრეტული ნაკადისთვის. არსებობს მონაცემთა გადაცემის რეჟიმი შერჩევითი მიწოდების შემოწმების სიხშირით - ჩვენ ვამოწმებთ მას ყოველ N პაკეტში ერთხელ. ყველა პაკეტს აქვს დროის შტამპი მიწოდების დაგვიანების შესაფასებლად. ჩაშენებული რგოლის ჰეშის მისამართი DHT ბოლო წერტილებისთვის.

• პრეზენტაციის ფენა

  Flash-ისთვის, ეს არის, რა თქმა უნდა, AMF3 და ინკაფსულირებული RTMP, მაგრამ ნებისმიერი სხვა მონაცემის გადაცემა შესაძლებელია.

უსაფრთხოება RTMFP-ში

• კლასიკური Diffie-Hellman გასაღების გაცვლა სტატიკური და ეფემერული კლავიშებით.
• ქუქიები და სერთიფიკატები სესიებში, პაკეტების ციფრული ხელმოწერის შესაძლებლობით. მართალია, სტანდარტულად ხელმოუწერელი პაკეტები ითვლება ძალაში
• AES128 გამოიყენება დაშიფვრისთვის, მაგრამ ნებისმიერი სხვა ბლოკის ალგორითმის გამოყენება შესაძლებელია.
• HMAC-SHA256 ან ქსელის გამშვები ჯამები.

მომხმარებლის ავთენტიფიკაცია და ავტორიზაცია შეიძლება განხორციელდეს განაცხადის მხრიდან. მავნე პროგრამების გაფილტვრის საკითხი ღია რჩება.

სად არის მკვლელის თვისება?

ვფიქრობ, ყველას ახსოვს ახალი პოპ ტელეფონის IPhone 6 Plus-ის უახლესი პრეზენტაციის მარცხი?

ასე რომ, წარმოიდგინეთ, რომ ერთი კლიენტი იღებს შემომავალ ნაკადს და გადასცემს მას ორზე მეტ ან მეტს (თუ ეს შესაძლებელია) და ასე შემდეგ - სანამ მაქსიმალური შესაძლო შეფერხება იძლევა საშუალებას. ამავდროულად, პერმუტაციები და დახარისხება ხდება კლიენტის ხეში რეალურ დროში, რათა შემცირდეს შეფერხებები და ოპტიმიზაცია მოახდინოს პაკეტის ფანჯარაში. შედეგად, თქვენ შეგიძლიათ მიაღწიოთ სამაუწყებლო სერვერის გამავალი ტრაფიკის მრავალჯერ შემცირებას.

და ყველა ნახავს მას...

გამოყენების შემთხვევები

1. შინაარსის გადაცემა რეალურ დროში

   ფაქტობრივად, ეს არის თავად პროტოკოლის მიზანი და ის ძალიან კარგად უმკლავდება ამ ამოცანას.
   მისი გამოყენება შესაძლებელია არა მხოლოდ აუდიო/ვიდეო გადაცემისთვის, არამედ როგორც ძირითადი ტრანსპორტი Flash თამაშებში.

2. CDN

   ეს არის P2P და ფაილის ჩამოსატვირთად საჭიროა მხოლოდ მისი სახელი, ჰეში და ზომა იცოდეთ.
   თქვენ შეგიძლიათ განახორციელოთ http2rtmfp კარიბჭე - შესაძლებლობები საკმაოდ საინტერესოა.

3. ვიდეო კონფერენციები და ჩეთები

   სნოუდენის შემდგომ ეპოქაში RTMFP არის ხელმისაწვდომი და უსაფრთხო P2P ტრანსპორტი. ასევე, მთავარი უპირატესობაა მაუწყებლობის გაგრძელების შესაძლებლობა მოწყობილობის ქსელის მისამართის შეცვლისას. WebRTC შეიძლება ჩამოვარდეს უჯრედების შეცვლისას 3G/4G-ში. RTP სტეკი კარგად არ არის შესაფერისი ასეთ გარემოში მაუწყებლობისთვის.

4. რეალურ დროში მონაცემთა გადაცემა კერძო ქსელებში

   ამ გამოყენების შემთხვევის მთავარი უპირატესობა არის მარშრუტიზაციის მოქნილი პოლიტიკის შესაძლებლობა, შეფერხებების მინიმიზაცია, არჩევითი პაკეტის მიწოდების დადასტურება და ჩაშენებული ტრაფიკის პრიორიტეტების ინსტრუმენტები. ამ ყველაფრის კონფიგურაცია შესაძლებელია ინდივიდუალურად თითოეული კონკრეტული აპლიკაციისთვის.

რა არის არსებული RTMFP გადაწყვეტილებები?

მოკლედ ძალიან ცუდადაა საქმე. დღეს ერთადერთი ღია განხორციელება არის კუმულუსი. ის ძალიან ნელა ვითარდება. დაფუძნებული არა RFC-ზე, არამედ Cirrus 1 RTMFP-ის პირველ უკუსვლებზე, ასე რომ, თავსებადობა მიმდინარე Cirrus 2 Flash პროფილთან საკმაოდ საეჭვოა. ის ახორციელებს სასარგებლო ფუნქციების უმეტესობას, მათ შორის P2P-ში სიჭარბის ორგანიზებას და მოწყობილობებს შორის მაუწყებლობას. არის FMS, მაგრამ მუშაობს FMSვით...

მოხარული ვიქნები, რომ მივიღო კონსტრუქციული კომენტარები.

კომენტარებში გთხოვთ მიუთითოთ RTMFP-ის ანალოგები, თუ იცით ისინი.