Porównanie aplikacji TCP / IP z aplikacjami HTTP [zamknięte]

13

Jestem zainteresowany opracowaniem wielkoskalowej witryny zorientowanej na użytkownika, napisanej w Javie.

Jeśli chodzi o projektowanie, myślę o opracowaniu niezależnych, modułowych usług, które mogłyby pełnić rolę dostawców danych dla mojej głównej aplikacji internetowej.

Jeśli chodzi o pisanie tych usług modułowych (dostawców danych), mogę wykorzystać istniejący framework, taki jak Spring, i rozwinąć te usługi zgodnie z wzorcem projektowym RESTful, i udostępnić zasoby przez HTTP w formacie komunikatu takim jak JSON ... lub mogę wykorzystać istniejącą sieć frameworki takie jak Netty ( http://netty.io/ ) i format serializacji jak Protobufs ( https://developers.google.com/protocol-buffers/docs/overview ) i rozwijają serwer TCP, który wysyła tam iz powrotem serializowanego protobufa ładowność.

Kiedy wybrać jedną z nich? Czy przydałoby się korzystanie z formatu serializacji, takiego jak Protobufs, i przesyłanie strumienia bajtów przewodem? Czy używanie JSON wiązałoby się z dodatkowymi kosztami? Ile jest narzutu między używaniem TCP / IP a używaniem HTTP? Kiedy należy korzystać z usługi Spring over Netty i odwrotnie, aby zbudować taką usługę?

HiChews123
źródło
Wygląda na to, że myślisz o stosie technologii bardziej niż o rzeczywistych wymaganiach. Jak ktokolwiek z nas mógłby odpowiedzieć na to pytanie, nie wiedząc, co musisz zrobić ? Czy tworzysz grę wieloosobową, która ma mieć prawie zerowe opóźnienie? Lub aplikacja do zakładek społecznościowych, w której większość dostępu jest już za pośrednictwem protokołu HTTP, a dane mogą być buforowane przez wiele godzin i nawet nie dbasz o świeżość, nie mówiąc już o opóźnieniu?
Aaronaught
3
Nie sądzę, żeby OP prosiło nas o dokonanie wyboru dla niego. Po prostu zadaje pytanie na wysokim szczeblu, w jaki sposób dokonuje się takich wyborów i jakie czynniki są brane pod uwagę. Nie sądzę, że jest coś złego w udzieleniu na ten temat odpowiedzi na wysokim poziomie ... i zrobiłem to.
DXM,
Generalnie jestem przeciwny używaniu formatów binarnych, chyba że naprawdę musisz. Brak formatów plików binarnych, brak serializacji binarnych itp. Na przykład w Javie serializacje binarne powodują niezgodności między wersjami Java a wersjami własnego oprogramowania, ale uważam, że XML nie jest aż tak duży. Myślę, że następujące TCP / IP> HTTP> XML Oczywiście, to zależy od tego, co robisz. Myślę, że JSON jest alternatywą dla XML. Nie wiem wiele o Spring ani Netty, chociaż czytam, że ludzie używają Spring.
Kaydell,
+1 DXM, zadaję pytania na wysokim poziomie, aby zastanowić się nad podjęciem takiej decyzji.
HiChews123,

Odpowiedzi:

21

Zdecydowanie zalety / wady korzystania z JSON przez REST w porównaniu z bezpośrednim TCP / IP z protokołem binarnym i myślę, że już podejrzewasz, że protokół binarny będzie szybszy. Nie potrafię powiedzieć dokładnie, o ile szybciej (a to zależy od wielu czynników), ale zgaduję, że może 1-2 rzędy różnicy wielkości.

Na pierwszy rzut oka, jeśli coś jest 10-100 razy wolniejsze niż coś innego, możesz zareagować gwałtownie i zdecydować się na „szybką rzecz”. Jednak ta różnica prędkości występuje tylko w samym protokole. Jeśli istnieje dostęp do bazy danych / plików po stronie serwera, wybór warstwy transferu nie wpłynie na to. W niektórych przypadkach prędkość warstwy transferu może być znacznie mniejsza.

HTTP REST i JSON są dobre z wielu powodów:

  • są łatwe do spożycia przez prawie każdego. Możesz napisać swoją aplikację internetową, a następnie odwrócić się i opublikować swój interfejs API, aby mógł z niego korzystać reszta świata. Teraz każdy może trafić w te same punkty końcowe i dostać się do twoich usług
  • są łatwe do debugowania, możesz otworzyć sniffer pakietów lub po prostu zrzucić przychodzące żądania do plików tekstowych i zobaczyć, co się dzieje. Nie można tego zrobić za pomocą protokołów binarnych
  • są łatwo rozszerzalne. Możesz dodać więcej atrybutów i danych w późniejszym czasie i nie naruszać zgodności ze starymi klientami.
  • do użytku przez klientów javascript (nie jestem pewien, czy mają już parser JS protobuf, nie wierzcie, że istnieje)

Protobufy przez TCP / IP:

  • są szybsi

Gdyby to był mój wybór, wybrałbym HTTP REST i JSON. Jest powód, dla którego tylu innych firm i stron internetowych poszło tą drogą. Pamiętaj również, że w przyszłości zawsze możesz wesprzeć 2 punkty końcowe. Jeśli projekt jest poprawny, wybór punktu końcowego powinien być całkowicie oddzielony od logiki biznesowej po stronie serwera lub bazy danych. Więc jeśli później zrozumiesz, że potrzebujesz większej prędkości dla wszystkich / niektórych żądań, powinieneś być w stanie dodać protobufy przy minimalnym zamieszaniu. Jednak od samego początku REST / JSON sprawi, że zejdziesz z ziemi szybciej i poprowadzisz dalej.

Jeśli chodzi o Netty vs Spring. Nie korzystałem bezpośrednio z Netty, ale uważam, że jest to tylko lekki serwer WWW, gdzie Spring jest strukturą zapewniającą znacznie więcej niż tylko to. Ma warstwy dostępu do danych, planowanie zadań w tle i (myślę) model MVC, więc jest znacznie cięższy. Który wybrać? Jeśli zdecydowałeś się na HTTP, to następne pytanie prawdopodobnie brzmi, jak standardowa jest Twoja aplikacja? Jeśli masz zamiar napisać jakąś szaloną logikę niestandardową, która nie pasuje do standardowej formy, a wszystko czego potrzebujesz to tylko warstwa serwera HTTP, skorzystaj z Netty.

Podejrzewam jednak, że twoja aplikacja nie jest tak wyjątkowa i prawdopodobnie mogłaby skorzystać z wielu rzeczy, które Spring ma do zaoferowania. Oznacza to jednak, że powinieneś zbudować aplikację zgodnie ze strukturą Spring i postępować zgodnie z oczekiwaniami, co oznaczałoby, że dowiesz się więcej o Spring przed zanurzeniem się w swoim produkcie. Szkielety ogólnie są świetne, ponieważ znowu pozwalają szybciej oderwać się od ziemi, ale wadą jest to, że musisz dopasować się do ich formy zamiast robić własny projekt, a następnie oczekiwać, że szkielet po prostu zadziała.

(*) - w przeszłości zwracano uwagę, że moje posty nie odzwierciedlają opinii całego świata, więc przejdę do zapisu i dodam tylko, że mam ograniczone doświadczenie z Netty (wcześniej korzystałem z frameworka Play który jest oparty na Netty) lub Spring (czytałem tylko o tym). Więc weź to, co mówię, z odrobiną soli.

DXM
źródło
1
+1, szczególnie dla „tej różnicy prędkości występuje tylko w samym protokole. Jeśli dostęp do bazy danych / plików po stronie serwera, nie będzie miał wpływu na wybór warstwy transferu”. 99% dokładnie tak będzie, a przedwczesna optymalizacja (w niewłaściwym miejscu) w niczym nie pomoże.
Shivan Dragon,
Dziękujemy za twoją długą odpowiedź i dogłębną analizę dotyczącą porównania tych dwóch. Rozumiem korzyści wynikające z budowy aplikacji RESTful, ponieważ jest ona łatwa do wykorzystania przez klientów publicznych. Jednak w przypadku, gdy chcę zachować wszystko w domu i nie chcę ujawniać usługi (dbam o serializację / deserializację), nie widzę, dlaczego użycie niestandardowego protokołu binarnego nie byłoby pierwszym wyborem. Tak, możesz szybciej rozpocząć pracę z istniejącymi strukturami, ale kosztem zablokowania ich interfejsów API i mniej precyzyjnej kontroli.
HiChews123 16.10.13
REST jest łatwy do spożycia przez WSZYSTKICH klientów, nie tylko publicznych, ale na pewno są uwzględnieni. Moja firma ma produkt, który budujemy od około roku. Mieliśmy „zastrzeżony” protokół, który był czasem odpoczynku. Właśnie otworzyliśmy to przed innymi. Jednej rzeczy, której uczą cię w szkole biznesu, jest „myślenie o opcjach”, podejmowanie decyzji o pozostawieniu jak największej liczby opcji, abyś mógł podjąć decyzję w późniejszym terminie. Biorąc pod uwagę, że wszystkie są równe, wybrałbym REST nie dlatego, że mam dzisiaj klientów JS lub dostęp do API, ale że mam opcję posiadania go w przyszłości, jeśli będę go potrzebować. Z drugiej strony, jeśli ...
DXM,
... korzystasz z protokołu binarnego, idź. 96% szans, że twój wybór protokołu nie wpłynie na twoje ostateczne podanie, więc nie przejmowałbym się tą decyzją. I jak powiedziałem w odpowiedzi, z przyzwoitym projektem, powinieneś być w stanie zamienić protokoły w późniejszym terminie. Inną rzeczą, którą lubię, jest wypróbowanie obu przypadków, jeśli podejmuję decyzję, stukam monetą i wybieram opcję A. Następnym razem, gdy wykonam podobny projekt, wybieram opcję B, aby móc wrócić i porównaj / porównaj moje doświadczenie. Czasami to jedyny sposób, w jaki sam decydujesz, co jest lepsze
DXM,
@DXM, świetne odpowiedzi, brawo!
HiChews123 16.10.13
0

To właściwie nie jest pytanie. Zgodnie z pakietem protokołów internetowych tcp to protokół w warstwie transportowej, a http to protokół w warstwie aplikacji. Porównujesz ze sobą zupełnie różne rzeczy. (Zobacz więcej tutaj: http://en.wikipedia.org/wiki/Internet_protocol_suite )

W rzeczywistości większość http jest ponad tcp / ip. Aby odpowiedzieć na twoje pytanie, tak, powinieneś użyć tcp / ip. Następnie chcesz dodać protokół warstwy aplikacji (np. Http), a następnie format danych (np. Json, xml, html). Netty pozwala używać http, a protobuff jest równy json, xml, html.

Wszystko zależy od Twoich wymagań i jakiego rodzaju danych będziesz potrzebować do transportu. Czy potrzebujesz sesji w protokole, czy uścisk dłoni może poprawić konfigurację protokołu, ile danych wyślesz jednocześnie, czy potrzebujesz szyfrowania? Oto pytania, na które należy odpowiedzieć przy wyborze protokołu aplikacji.

Wybór formatu reprezentacji danych (json, xml, html, protobuff itp.) Zależy od przepustowości, czytelności, obsługi języka / narzędzi itp.

Nie można porównać http do tcp.

Pamiętaj, że prędkość to nie wszystko. Prędkość jest bezużyteczna, jeśli nie możesz wyrazić siebie w rozsądny sposób.

iveqy
źródło
5
W jego pytaniu nie ma nic, co sugerowałoby, że nie zna różnicy między warstwami stosu sieciowego. Zapytał, czy powinien używać HTTP (zakłada się, że HTTP jest warstwą powyżej TCP / IP), czy używać TCP / IP z własnym niestandardowym protokołem. W jego pytaniu nie ma nic złego.
Michael
Oczywiście się nie zgadzam. Nie tak go zrozumiałem
iveqy
1
Tak, rozumiem, że HTTP jest na warstwie wyższej niż TCP / IP, moje pytanie rzeczywiście dotyczy myślenia o podejmowaniu decyzji w kategoriach kompromisów - opóźnienia, szybkości rozwoju itp. Dziękuję za zadawanie pytań, o których muszę pomyśleć!
HiChews123 16.10.13
2
@ acspd7 Unikałbym tworzenia własnego protokołu, istnieje wiele sprawdzonych protokołów i jeśli twój protokół nie zapewni Ci przewagi nad konkurentami, prawdopodobnie lepiej Ci ze standardowym protokołem. Wdrożyłem niestandardowy protokół, było mnóstwo zabawy! Jednak szyfrowanie, dziurkowanie, utrzymanie przy życiu, uzgadnianie (różne sieci wymagają różnych długości ramek) itp. To dużo pracy, aby robić dobrze. Nie wspominając już o całej dokumentacji, której potrzebujesz. Zastanów się, czego naprawdę potrzebujesz w funkcjach, zanim zrobisz coś niestandardowego.
iveqy
1
GPB są dobrze udokumentowane, używane przez wiele innych, więc nie widzę żadnego problemu z korzystaniem z niego. Bycie bardziej zwięzłym niż XML i JSON powinno być świetne! (możesz nie mieć czytelności dla ludzi, ale jeśli nie jest to wymóg ...). Jednak nie tęsknisz za warstwą? Zwykle masz warstwę między tcp i xml, json, protobuff. Coś w stylu http, ssh itp.
iveqy 16.10.13