Skocz do zawartości
  • Cześć!

    Witaj na forum RootNode - aby pisać u nas musisz się zarejestrować, a następnie zalogować. Posty pisane z kont niezarejestrowanych nie są widoczne publicznie.

Poradnik: Jak wybrać hosting? - prośba o opinie


kazur

Rekomendowane odpowiedzi

Cześć!

 

TL;DR:
Stworzyłem i udostępniłem za darmo poradnik „Jak wybrać hosting?”. Co o nim sądzisz? 

 

LINK: https://jakwybrachosting.pl/poradnik/

 
Wersja pełna:
Nie mogłem już patrzeć na kolejne pytania na FB czy na forach „Jaki hosting polecacie?” i wysyp dziesiątek komentarzy „naganiaczy” pod każdym z takich postów. Gdyby jeszcze toczyła się tam w tych komentarzach merytoryczna dyskusja i wypytywanie o potrzeby pytającego, to byłoby OK. Ale nie. Zazwyczaj komentarze pod takimi postami to po prostu wklejenie linka do strony firmy hostingowej, czy banały w stylu „u mnie działa” i „ja jestem zadowolony”.
Dlatego też przysiadłem do tematu i postanowiłem stworzyć i udostępnić bezpłatnie poradnik, który pokaże, w konkretnych punktach co trzeba sprawdzić, wybierając hosting dla swojego biznesu.
A niestety strony wielu firm hostingowych to w większości przypadków jedno wielkie lanie wody, zamiast konkretów (każdy hosting twierdzi, że jest szybki, no bo ma SSD i oferuje dużo gigabajtów i a prawie wszystko jest „bez limitów” 🙂).
Chciałem, aby treść tego poradnika była maksymalnie konkretna - bez lania wody. Ale tez z drugiej strony napisana prostym i przystępnym językiem, aby przeciętna osoba startująca z działalnością online mogła zrozumieć całość.
Ostatecznie na tę chwilę wyszło mi 21 rzeczy, które trzeba sprawdzić, wybierając hosting. Całość podzieliłem na 4 podstawie parametry (dysk, transfer itd.) i 17 bardziej szczegółowych limitów i ograniczeń, które zazwyczaj trudno znaleźć na stronach hostingów lub napisane są „drobnym druczkiem”.
Dodatkowo napisałem tam parę słów o domenach i „Dlaczego warto patrzeć z przymrużeniem oka na »polecane hostingi«, rankingi wielkości hostingów i opinie o hostingach w sieci?”.
Na stronie udostępniłem też PDF z checklistą, która podsumowuje informacje z poradnika i zawiera zwięzłą listę pytań, które trzeba zadać swojemu hostingowdawcy.
I to tyle na dziś, choć planów mam jeszcze sporo. Chcę po prostu ułatwić wybór NAJLEPSZEGO hostingu wszystkim, którzy startują z działalnością online czy uciekają od swojego obecnego hostingodawcy. Najlepszego w danym przypadku, a nie najlepszego „dla wszystkich” 🙂.
A piszę to wszystko, bo zanim zacznę działać dalej z tematem, chciałbym prosić o pomoc.
 
Napisz mi proszę - co sądzisz o tym poradniku? Czy jest OK? Czegoś tam brakuje? Coś zbyt uprościłem lub niedostatecznie wyjaśniłem?
Będę wdzięczny za każdy komentarz czy uwagę - może być tu, może być na maila czy priv 🙂
Odnośnik do komentarza
Udostępnij na innych stronach

Cześć! 

Bardzo fajna inicjatywa, lecz bardzo w mojej ocenie, dość subiektywna w przykładach. W skrócie, 90% shared hostingów i tak używa cl, tak więc czego konkretnie dotyczą limity lve można wyczytać z dokumentacji, zaś przykład nginx vs lsws jest mocno nietrafiony.  Z moich doświadczeń, wynika że nawet lekko tweak'owany nginx potrafi obsłużyć znacznie więcej req/sec niż lsws, np. w przypadku ataku wspomnianych przez Ciebie botów, zaś subiektywny benchmark prawdopodobnie przeprowadzany jest na najwyższej wersji lsws, bez limitu cpu/workerów, a to z czego rzeczywiście korzystają hostingi per node, to już inna kwestia ;) Chciałbym zobaczyć benchmark np. nginx plus vs lsws unlimited przy konfiguracji by default,  wraz z panelami oraz przy zmianie kilku opcji - byłby znacznie bardziej wiarygodny. Oczywiście, w wielu przypadkach cache lsws będzie wygrywać i przy shared hostingu jest to najlepsze rozwiązanie, ale na pewno "szybkość" nie jest liczona w ten sposób, a już na pewno nie za pomocą ICMP/Ping względem lokacji - bardziej skupiłbym się na TTFB.

Metodologia top100 pokazuje przede wszystkim udział w rynku na podstawie utrzymywanych domen i mimo że osobiście mi też nie odpowiada tylko takie zestawienie, jest ono jak najbardziej rzeczywiste.

Przy dyskach NVMe / ssd też wypadałoby wspomnieć o używanych narzędziach, cache, macierzach, filesystemach etc. - 2xSSD softraid != macierzy 20x10k sas z dobrym cache'em - także tutaj bym również był ostrożny przy tego typu porównaniach.

Wersje PHP - oczywiście że w standardzie shared hosting oferuje od 4.4 do 7.4, wraz ze wszystkimi wersjami które nie są wspierane. Ba! Nawet nie wiem czy 5.6 jest kompilowane z utrzymywanych patch'y microsoft'u, tak jak ostatnio popularne "3rd party repo", ale wybór wersji powinien być nie mniejszy niż wszystkie, które wyszły. Od drugiej strony, często wygląða to tak, że klient może chcieć przenieść starą, mega podatną stronę i mimo próśb, informowania o konsekwencjach, koniec końców to jego wybór i fajnie, gdy usługodawca daje taką możliwość.

Duży plus za wypunktowanie pozostałych minusów.

Gdybyś potrzebował środowiska do testów czy jakiejkolwiek pomocy technicznej, daj znać a chętnie pomogę.

Pozdrawiam.

  • Lubię 1
Odnośnik do komentarza
Udostępnij na innych stronach

Poradnik przejrzałem na szybko. Poniżej zamieściłem coś, co rzuciło mi się w oczy.

Cytat

Są jednak nadal firmy, które nie oferują takiej możliwości i namawiają do kupna płatnego certyfikatu SSL, który pod względem technicznym nie różni się niczym od darmowego Let’s Encrypt. Warto wcześniej to sprawdzić.

Czyli nie ma różnic między darmowym a płatnym certyfikatem?

Edytowane przez dzagu
  • Lubię 1
Odnośnik do komentarza
Udostępnij na innych stronach

nie ma,  jedyna różnica jest taka że przy darmowym nie masz "gwarancji finansowych", które i tak można w praktyce o kant tyłka rozbić.

 

Przy okazji, jakby ktoś nie wiedział, "przedłużenie" certyfikatu to de facto wystawienie nowego (nawet cała procedura jest taka sama), więc nie ma co przepłacać "przedłużając" tylko kupować nowy.

Edytowane przez ćwierćadmin
Odnośnik do komentarza
Udostępnij na innych stronach

@Spoofy, niestety trochę pomyliłeś:

- technicznie - krótsza ważność certyfikatów Let's Encrypt nie wynika z ograniczeń technicznych. Let's Encrypt mogłoby spokojnie rozdawać certyfikaty ważne 2 lata, ale krótszą ważnością zachęcają do automatyzacji; Buypass daje 180 dni za darmo; StartSSL zanim ich wywalono z przeglądarek dawali nawet 3 lata za darmo. Google Cloud dla sesji SSH swojej chmurze wystawia certyfikaty ważne 2 dni.

- prawnie - poza urban legend w postaci "gwarancji", o której każdy słyszał, a nikt nie widział, nie ma różnic prawnych, wymogi są takie same dla wszystkich wystawców, zarówno komercyjnych jak i Let's Encrypt.

- praktycznie - tu się zgadzam, takim wymogiem mógłby być uparty prezes, który koniecznie chce mieć komercyjny certyfikat (wolny rynek), albo urządzenie, którego nie da się zautomatyzować (np. interfejs webowy drukarki, można użyć Let's Encrypt, ale konfigurowanie nowego certyfikatu co 3 miesiące byłoby męczące).

Odnośnik do komentarza
Udostępnij na innych stronach

5 minut temu, psz napisał:

@Spoofy, niestety trochę pomyliłeś:

- technicznie - krótsza ważność certyfikatów Let's Encrypt nie wynika z ograniczeń technicznych. Let's Encrypt mogłoby spokojnie rozdawać certyfikaty ważne 2 lata, ale krótszą ważnością zachęcają do automatyzacji; Buypass daje 180 dni za darmo; StartSSL zanim ich wywalono z przeglądarek dawali nawet 3 lata za darmo. Google Cloud dla sesji SSH swojej chmurze wystawia certyfikaty ważne 2 dni.

- prawnie - poza urban legend w postaci "gwarancji", o której każdy słyszał, a nikt nie widział, nie ma różnic prawnych, wymogi są takie same dla wszystkich wystawców, zarówno komercyjnych jak i Let's Encrypt.

- praktycznie - tu się zgadzam, takim wymogiem mógłby być uparty prezes, który koniecznie chce mieć komercyjny certyfikat (wolny rynek), albo urządzenie, którego nie da się zautomatyzować (np. interfejs webowy drukarki, można użyć Let's Encrypt, ale konfigurowanie nowego certyfikatu co 3 miesiące byłoby męczące).


@psz tak, chciałbym opisać różnicę wszystkich darmowych certów, beznadziejnych wtycznych gov'ów etc. ale nie chciałem tutaj znów rozwijać wątku, więc po prostu mocno skróciłem - chyba nie o tym tutaj temat ;)

Mógłbyś podrzucić linkiem do bloga z benchmarkiem nginx'a, a nie mi tu flame za skróty robisz :D

Pozdrawiam


Edit: np. : https://blog.cloudflare.com/how-we-scaled-nginx-and-saved-the-world-54-years-every-day/ 

Odnośnik do komentarza
Udostępnij na innych stronach

Jak to napisaliśmy na blogu 2 lata temu:

Cytat

Since then there's been an encryption revolution and we're proud that nearly all forward-thinking services offer SSL for free. If some service you're using still charges you extra to support encryption they’re ripping you off.

 

Wracając do tematu:

Przeczytam poradnik napiszę spostrzeżenia.

  • Lubię 1
Odnośnik do komentarza
Udostępnij na innych stronach

1 godzinę temu, Spoofy napisał:

Bardzo fajna inicjatywa, lecz bardzo w mojej ocenie, dość subiektywna w przykładach. W skrócie, 90% shared hostingów i tak używa cl, tak więc czego konkretnie dotyczą limity lve można wyczytać z dokumentacji, zaś przykład nginx vs lsws jest mocno nietrafiony.  Z moich doświadczeń, wynika że nawet lekko tweak'owany nginx potrafi obsłużyć znacznie więcej req/sec niż lsws, np. w przypadku ataku wspomnianych przez Ciebie botów, zaś subiektywny benchmark prawdopodobnie przeprowadzany jest na najwyższej wersji lsws, bez limitu cpu/workerów, a to z czego rzeczywiście korzystają hostingi per node, to już inna kwestia ;) Chciałbym zobaczyć benchmark np. nginx plus vs lsws unlimited przy konfiguracji by default,  wraz z panelami oraz przy zmianie kilku opcji - byłby znacznie bardziej wiarygodny. Oczywiście, w wielu przypadkach cache lsws będzie wygrywać i przy shared hostingu jest to najlepsze rozwiązanie, ale na pewno "szybkość" nie jest liczona w ten sposób, a już na pewno nie za pomocą ICMP/Ping względem lokacji - bardziej skupiłbym się na TTFB.

 

Przede wszystkim dzięki za Twoje uwagi! 🙂

W poradniku skupiam się bardziej na kwestiach, które wychodzą zazwyczaj z benchmarków albo po prosty suchych parametrach, które można znaleźć na stronie hostingu czy wypytać o nie support. Jasne, że zawsze "to zależy" i da się znaleźć shared, który na HDD będzie ostatecznie szybszy od SSD NVMe, czy stuningować nginxa, aby śmigał lepiej od litespeed.

Mam w planach przygotowanie za jakiś czas drugiego podobnego poradnika - Jak przetestować hosting?. Będzie to taka kontynuacja i przy okazji konkretne rzeczy, które można sprawdzić w ciągu 7-14-dniowego okresu testowego udostępnianego przez hostingi. I tam ostatecznie najważniejszy jest końcowy wynik m.in. TTFB.

 

Stay tuned! I pamiętaj, że poradnik nie jest dla takich wyjadaczy jak Ty, ale dla przeciętnego Kowalskiego, który chce postawić bloga na wordpressie czy jakiś prosty sklep na sharedzie :-).

 

1 godzinę temu, Spoofy napisał:

Metodologia top100 pokazuje przede wszystkim udział w rynku na podstawie utrzymywanych domen i mimo że osobiście mi też nie odpowiada tylko takie zestawienie, jest ono jak najbardziej rzeczywiste.

Oczywiście, że top100 jest rzetelne. Chodzi mi o to, aby wysoka pozycja nie była wyznacznikiem tego, że dany hosting warto wybrać 🙂

 

1 godzinę temu, Spoofy napisał:

Przy dyskach NVMe / ssd też wypadałoby wspomnieć o używanych narzędziach, cache, macierzach, filesystemach etc. - 2xSSD softraid != macierzy 20x10k sas z dobrym cache'em - także tutaj bym również był ostrożny przy tego typu porównaniach.

Słuszna uwaga, ale obawiam się, że przeciętna osoba instalująca WordPressa z autoinstallera może się w tym pogubić. Postaram się jednak w tym drugim poradniku przygotować sposób na samodzielne pretestowanie wydajności dysku w wersji "dla każdego" 🙂

 

1 godzinę temu, Spoofy napisał:

Wersje PHP - oczywiście że w standardzie shared hosting oferuje od 4.4 do 7.4, wraz ze wszystkimi wersjami które nie są wspierane. Ba! Nawet nie wiem czy 5.6 jest kompilowane z utrzymywanych patch'y microsoft'u, tak jak ostatnio popularne "3rd party repo", ale wybór wersji powinien być nie mniejszy niż wszystkie, które wyszły. Od drugiej strony, często wygląða to tak, że klient może chcieć przenieść starą, mega podatną stronę i mimo próśb, informowania o konsekwencjach, koniec końców to jego wybór i fajnie, gdy usługodawca daje taką możliwość.

 

Pełna zgoda. Chodzi tylko o to, aby hosting w 2020 roku nie uruchamiał klientom domyślnie PHP w wersji 5.6. No i dawał zawsze możliwość korzystania z najnowszej wersji.

 

Dzięki jeszcze raz za pomoc i uwagi i propozycję pomocy w przyszłości @Spoofy 🙂

 

Co do certyfikatów - moim zdaniem dla zwykłego Kolwalskiego prowadzącego sklep na woocomerce czy bloga nie ma w praktyce różnicy między lets encrypt a takim np. DV RapidSSL, czy innym. Podkreślam - w praktyce 🙂

 

@ćwierćadmin - przypomniałeś mi właśnie jeszcze historie z tymi "przedłużeniami", które były droższe od standardowego certyfikatu. Ciekawe czy dalej są firmy, które tak robią 🙂

 

@psz - liczę na Ciebie 🙂

  • Lubię 1
Odnośnik do komentarza
Udostępnij na innych stronach

Warto wspomnieć o mocy cpu dla jednego konta www, zabezpieczeniach (typu dnssec) czy rodzajach macierzy raid (0,1,5,6,10) na których są dane. Warto podzielić usługi na te działające w chmurze (przeważnie droższe ale lepsze) i te niechmurowe (tańsze ale bardziej zawodne). I jest coś takiego jak HTTP/2 - warto to ująć.

Odnośnik do komentarza
Udostępnij na innych stronach

Cytat

Warto podzielić usługi na te działające w chmurze (przeważnie droższe ale lepsze) i te niechmurowe (tańsze ale bardziej zawodne). I

Z ciekawości, która firma posiada ofertę hostingu współdzielonego opartej na chmurze (AWS/Azure/GCP)?

Odnośnik do komentarza
Udostępnij na innych stronach

Poradnik zasadniczo jest OK, kilka uwag:
 

  1. Punkty 10 i 14 częściowo opisują te same właściwości, sugeruję wydzielenie parametrów ograniczających czasy trwania procesów/skryptów/połączeń do jednego osobnego punktu.
  2. Brak informacji o adresie IP: stały vs współdzielony w kontekście wygody korzystania z zewnętrznego CDN oraz wpływu na dostarczalność poczty e-mail.
  3. Łatwość korzystania z CloudFlare - niektóre hostingi posiadają wygodne, wbudowane w panele integracje z tą usługą, niektóre niereformowalne hostingi bronią się przed CF rękami i nogami utrudniając korzystanie z tej usługi wszelkimi możliwymi metodami.
  4. Brakuje informacji o takich funkcjach jak: DKIM, DMARC dla poczty.
  5. Dwuskładnikowe uwierzytelnianie do panelu zarządzania (ewentualnie).
  • Lubię 1
Odnośnik do komentarza
Udostępnij na innych stronach

Dla kogo jest ten poradnik? Bo jeśli dla zwykłego zjadacza chleba, to on odpuści po kilku zdaniach. A jak nie odpuści, to zgłupieje od nadmiaru informacji ;) A jeśli dla użytkownika zaawansowanego, to nie będzie musiał go czytać, bo wszystko z tego wie. Wygląda to trochę jak dobry tekst pod zaplecze SEO ;)

Odnośnik do komentarza
Udostępnij na innych stronach

19 godzin temu, Michchalek napisał:

Warto wspomnieć o mocy cpu dla jednego konta www, zabezpieczeniach (typu dnssec) czy rodzajach macierzy raid (0,1,5,6,10) na których są dane. Warto podzielić usługi na te działające w chmurze (przeważnie droższe ale lepsze) i te niechmurowe (tańsze ale bardziej zawodne). I jest coś takiego jak HTTP/2 - warto to ująć.

 

CPU - jest

DNSSEC - dodane do ToDo 🙂

RAID - dodane do ToDo

Chmura/nie chmura - własnie nie wiem jak ugryźć ten temat od strony zwykłego, przeciętnego klienta hostingu.

HTTP/2 - jest

 

Dzięki @Michchalek!

 

18 godzin temu, mrViperoo napisał:

Z ciekawości, która firma posiada ofertę hostingu współdzielonego opartej na chmurze (AWS/Azure/GCP)?

 

No właśnie też się zastanawiam 🙂

 

5 godzin temu, Tom X napisał:

Poradnik zasadniczo jest OK, kilka uwag:
 

  1. Punkty 10 i 14 częściowo opisują te same właściwości, sugeruję wydzielenie parametrów ograniczających czasy trwania procesów/skryptów/połączeń do jednego osobnego punktu.
  2. Brak informacji o adresie IP: stały vs współdzielony w kontekście wygody korzystania z zewnętrznego CDN oraz wpływu na dostarczalność poczty e-mail.
  3. Łatwość korzystania z CloudFlare - niektóre hostingi posiadają wygodne, wbudowane w panele integracje z tą usługą, niektóre niereformowalne hostingi bronią się przed CF rękami i nogami utrudniając korzystanie z tej usługi wszelkimi możliwymi metodami.
  4. Brakuje informacji o takich funkcjach jak: DKIM, DMARC dla poczty.
  5. Dwuskładnikowe uwierzytelnianie do panelu zarządzania (ewentualnie).

 

1. Brzmi rozsądnie. Tak zrobię! 🙂 

2. Hmm... czy jakieś zwykłe hostingi współdzielone dają w standardzie indywidualne IP? Zazwyczaj jest to chyba opcja płatna dodatkowo.

3. O! Warto o tym wspomnieć. Może nie jako osobny punkt "do sprawdzenia", ale gdzieś o tym napisać. Dobry pomysł!

4. Zapisane w ToDo!

5. W sumie - też warto o tym gdzieś napisać.

 

Dzięki @Tom X!

 

5 godzin temu, Kapitan_Bomba napisał:

Dla kogo jest ten poradnik? Bo jeśli dla zwykłego zjadacza chleba, to on odpuści po kilku zdaniach. A jak nie odpuści, to zgłupieje od nadmiaru informacji ;) A jeśli dla użytkownika zaawansowanego, to nie będzie musiał go czytać, bo wszystko z tego wie. Wygląda to trochę jak dobry tekst pod zaplecze SEO ;)

 

Docelowo poradnik ma być dla zwykłego zjadacza chleba, który chce zgłębić temat. Zdecydowanie chciałem pisać takim językiem, aby całość była zrozumiała dla początkujących. Choć niestety wiem, że część sobie temat podaruje. Jak masz jakieś pomysły, aby coś uprościć, żeby było bardziej "zjadliwe" to pisz 🙂 

Odnośnik do komentarza
Udostępnij na innych stronach

2 godziny temu, kazur napisał:

2. Hmm... czy jakieś zwykłe hostingi współdzielone dają w standardzie indywidualne IP? Zazwyczaj jest to chyba opcja płatna dodatkowo.

 

Tak, te sensowne mają stały/unikalny adres IP w standardzie, u innych trzeba dodatkowo dopłacić, u niektórych taki luksus nawet nie występuje ani w standardzie ani w cenniku.

Odnośnik do komentarza
Udostępnij na innych stronach

Dnia 4.04.2020 o 15:32, kazur napisał:

Chmura/nie chmura - własnie nie wiem jak ugryźć ten temat od strony zwykłego, przeciętnego klienta hostingu.

 

Pełna chmura ma pewną zaletę - odpowiem Ci na przykładzie. Jestem webmasterem osoby, która wystąpiła w Tańcu z Gwiazdami nie tak dawno. Aktor - nie bardzo rozpoznawalny. Jak tylko wyszedł na parkiet w TzG - "stanęła" jego strona WWW. Odebrałem wtedy telefon od mocno zdenerwowanego managera tego aktora. Jak to nie działa? co to jest? Stronka aktora notowała 1 GB ruchu miesięcznie, w czasie tego TzG wszystko padło, a firma hostingowa wypowiedziała mi umowę (nie wymienię która, nie korzystam już, niby mieli skalowane zasoby i takie pierdu pierdu). Stronę wrzuciłem na cloud. Na cloud 0 prblemów, przy następnym odcinku było co prawda mniejsze zainteresowanie, ale wtedy w ciągu 1 godziny strona wygenerowała 35 GB ruchu i cały czas działała. A przypominam że wcześniej w miesiącu generowała 1 GB. Tylko porównaj rodzaje cloudu - bo niektórzy nazywają cloudem to co w rzeczywistości jest shared hosting.

Edytowane przez Michchalek
Odnośnik do komentarza
Udostępnij na innych stronach

@Michchalek - Dzięki za info!

Wszystko jasne - chmura, skalowalność itd.

 

Tylko chodzi mi o to:

3 godziny temu, Michchalek napisał:

Tylko porównaj rodzaje cloudu - bo niektórzy nazywają cloudem to co w rzeczywistości jest shared hosting.

 

Tylko jak zwykły kowalski czytający poradnik, może w prosty sposób przeglądając strony WWW hostingów rozpoznać czy to jest "prawdziwa" chmura, czy tylko dostawca hostingu chwali się, że ma super elastyczne skalowanie zasobów i hosting w chmurze, a w rzeczywistości to po prostu dedyk postawiony w OVH czy innym Hetzner? Na to nie mam pomysłu.

 

 

 

Odnośnik do komentarza
Udostępnij na innych stronach

18 godzin temu, kazur napisał:

Tylko jak zwykły kowalski czytający poradnik, może w prosty sposób przeglądając strony WWW hostingów rozpoznać czy to jest "prawdziwa" chmura, czy tylko dostawca hostingu chwali się, że ma super elastyczne skalowanie zasobów i hosting w chmurze, a w rzeczywistości to po prostu dedyk postawiony w OVH czy innym Hetzner? Na to nie mam pomysłu.

 

Generalnie trzeba chyba opierać się na opisie usługi. Tutaj nie rozpoznasz, czy usługodawca próbuje coś przemycić nazywając to chmurą, czy faktycznie jest to chmura. Bez czytania opisu nie da rady. W różnych firmach też pojawiają się opisy usług jako "usługi cloud" (niby to samo co chmura a brzmi inaczej :) ) . Jeżeli nie chcesz wymieniać firm z nazwy kolejno w swoim artykule, to musisz nakreślić dokładnie jak rozpoznać cloud z opisu usługi a nie jej parametrów.

 

Tak jeszcze odnośnie SSL - są obecnie 2 algorytmy generowania SSLi, dla zwykłego "kowalskiego" wystarczy RSA, przy czym jest też ECDSA (masz tu opis: https://www.ssl.com/article/comparing-ecdsa-vs-rsa/).

 

Warto pomyśleć o wyróżnieniu tych 2 typów i sklasyfikowaniu dla kogo są bardziej optymalne i dlaczego. W zasadzie masz dużą dawkę wiedzy w tym artykule powyżej, warto się z nim zapoznać. Let's Encrypt masz tylko RSA, ale zakładając że poradnik może czytać ktoś prowadzący sklep i szukający np. właściwego SSLa - może warto dodać informacje o tym, jakie zalety niesie za sobą ECDSA i czemu kiedyś na pewno zastąpi RSA. W swoim poradniku SSL potraktowałeś trochę po macoszemu, pisząc tylko o Let's Encrypt. Zwykly "kowlaski" = ok, użytkownik wymagający = już nie tak do końca P)

Edytowane przez Michchalek
  • Lubię 1
Odnośnik do komentarza
Udostępnij na innych stronach

Jeśli chcesz dodać odpowiedź, zaloguj się lub zarejestruj nowe konto

Jedynie zarejestrowani użytkownicy mogą komentować zawartość tej strony.

Zarejestruj nowe konto

Załóż nowe konto. To bardzo proste!

Zarejestruj się

Zaloguj się

Posiadasz już konto? Zaloguj się poniżej.

Zaloguj się
×
×
  • Dodaj nową pozycję...

Powiadomienie o plikach cookie

Korzystając z forum, wyrażasz zgodę na: Warunki użytkowania, Regulamin, Polityka prywatności.