TCP vs. Http Benchmark

Question

Mam aplikację sieci Web siedzącą na IIS i rozmowę z [remote] Service-Machine. Nie jestem pewien, czy wybrać TCP lub Http, jako główny protokół.

więcej szczegółów:

1. będę mieć więcej niż jedną usługę \ końcowego
2. niektóre z nich będą jednokierunkowe
3. drugi będą dwie drogi
4. strony internetowe będą działać frontem do usług
5. mówimy o hi skalę stronie internetowej

Dobrze znam różnicę, ale szukam dobrego testu porównawczego, który pokazuje, o ile szybszy jest TCP?

Answer 1

HTTP jest warstwą wbudowaną w warstwę TCP dla niektórych elementów, które standaryzują transmisję danych. Naturalnie używanie gniazd TCP będzie mniej uciążliwe niż korzystanie z protokołu HTTP. Jeśli zależy nam tylko na wydajności, to zwykły TCP jest najlepszym rozwiązaniem dla Ciebie.

Możesz rozważyć HTTP ze względu na łatwość obsługi i prostotę, która ostatecznie skraca czas programowania. Jeśli robisz coś, co może być bezpośrednio wykorzystane przez przeglądarkę (przez wywołanie AJAX), powinieneś użyć HTTP. Aby nieistniejąca przeglądarka bezpośrednio korzystała z połączeń TCP bez HTTP, musiałbyś używać Flasha lub Silverlight i zwykle dzieje się tak w przypadku treści bogatych, takich jak wideo i/lub audio. Jednak wiele współczesnych przeglądarek (od 2013 r.) Obsługuje interfejsy API, aby uzyskać dostęp do zasobów sieciowych, audio i wideo bezpośrednio za pośrednictwem JavaScript. Jedyne, co należy wziąć pod uwagę, to stopień wykorzystania nowoczesnych przeglądarek internetowych wśród użytkowników; patrz caniuse.com, aby uzyskać najnowsze informacje dotyczące zgodności przeglądarki.

Jeśli chodzi o testy porównawcze, jedyną rzeczą, jaką znalazłem, jest this. Patrz strona 5, ma wykres wydajności. Zauważ, że tak naprawdę nie porównuje jabłek z jabłkami, ponieważ porównuje opcję danych TCP/Binary z opcją danych HTTP/XML. Co nasuwa pytanie: jakie dane są na temat twoich usług? binarny (wideo, audio, pliki) lub tekst (JSON, XML, HTML)?

W ogólnym systemie zorientowanym na wydajność, takim jak w sektorze wojskowym lub finansowym, prawdopodobnie będą używane zwykłe połączenia TCP. Gdzie jako ogólne firmy skoncentrowane na sieci zdecydują się korzystać z HTTP i używać usług IIS lub Apache do hostowania swoich usług.

Answer 2

Zawsze można to porównać.

Ogólnie rzecz biorąc, jeśli to, co chcesz osiągnąć, można łatwo zrobić przez HTTP (to jest jedyny powód, dla którego w przeciwnym razie myślałeś o używaniu surowego TCP do zwiększenia wydajności) prawdopodobnie powinieneś po prostu użyć HTTP. Oczywiście, możesz programować w gniazdach, ale po co zawracać sobie głowę? Wiele osób poświęciło wiele czasu i wysiłku na budowanie bibliotek i serwerów klienckich HTTP. Spędzili oni więcej czasu, optymalizując i testując ten kod, niż kiedykolwiek będziecie mogli wydać na swoje gniazda TCP. Jest po prostu tyle możliwych błędów, z którymi musiałbyś sobie poradzić, przypadki skrajne i optymalizacje, które można wykonać, że zwykle łatwiej i bezpieczniej jest używać funkcji bibliotecznej dla HTTP.

Co więcej, specyfikacje HTTP definiują wszystkie rodzaje funkcji (oraz implementację klientów/serwerów, z których można korzystać "za darmo", tj. Bez dodatkowych prac wdrożeniowych), co znacznie ułatwia współdziałanie z innymi firmami. "Oto mój adres URL, tutaj są zasady dotyczące tego, co wysyłasz, oto zasady dotyczące tego, co wracam ..."

Answer 3

Pytanie, na które naprawdę potrzebujesz odpowiedzi, brzmi "czy TCP lub HTTP będą szybsze dla Aplikacja ". Odpowiedź jest taka, że ​​zależy to od natury aplikacji i sposobu korzystania z protokołu TCP i/lub HTTP w aplikacji. Ogólny test porównawczy HTTP i TCP nie odpowie na twoje pytanie, ponieważ szanse na to, że test porównawczy nie pasuje do zachowania aplikacji.

Teoretycznie optymalnie zaprojektowane/zaimplementowane rozwiązanie wykorzystujące protokół TCP będzie szybsze niż korzystanie z protokołu HTTP. Ale może to być znacznie więcej pracy do wdrożenia ... w zależności od szczegółów aplikacji.

Istnieją inne problemy, które mogą wpłynąć na Twój wybór. Na przykład, mniej prawdopodobne jest, że napotkasz problemy z firewallem, jeśli korzystasz z protokołu HTTP, niż gdy używasz TCP na jakimś losowym porcie. Innym jest to, że HTTP ułatwiłoby wdrożenie systemu równoważenia obciążenia między serwerem IIS a systemami zaplecza.

Wreszcie, na koniec dnia prawdopodobnie ważniejszy jest system, który jest niezawodny, łatwy w utrzymaniu i (być może) skalowalny, niż szybki. Rozsądną strategią jest najpierw wdrożenie prostej wersji, ale planuj w głowie, jak ją przyspieszyć ... jeśli proste rozwiązanie jest zbyt wolne.