Moje zrozumienie ankiet HTTP, Long ankiet, HTTP Streaming i WebSockets

Kilka świetnych odpowiedzi od innych, które obejmują dużo ziemi. Tu jest trochę więcej.

Jedyną zaletą WebSockets nad wtyczkami takimi jak aplety Java, Flash lub Silverlight jest to, że WebSockets są natywnie wbudowane w przeglądarki i nie polegają na wtyczkach.

Jeśli przez to rozumiesz, że możesz używać apletów Java, Flasha lub Silverlight do nawiązania połączenia z gniazdem, to tak, jest to możliwe. Jednak nie widzisz tego zbyt często w realnym świecie z powodu ograniczeń.

Na przykład pośrednicy mogą i robią zamknięcie tego ruchu. Standard WebSocket został zaprojektowany tak, aby był kompatybilny z istniejącą infrastrukturą HTTP i dlatego jest znacznie mniej podatny na ingerencję pośredników, takich jak firewalle i proxy.

Ponadto WebSocket może korzystać z portów 80 i 443 bez konieczności stosowania dedykowanych portów, ponownie dzięki projektowi protokołu, aby był jak najbardziej kompatybilny z istniejącą infrastrukturą HTTP.

Te alternatywy gniazd (Java, Flash i Silverlight) są trudne do bezpiecznego użycia w architekturze cross-origin. Tak więc ludzie często próbujący ich użyć cross-origin będą tolerować niepewność, a nie iść do wysiłku, aby zrobić to bezpiecznie.

Mogą również wymagać otwarcia dodatkowych "niestandardowych" portów (co administratorzy nie lubią robić) lub plików zasad, którymi należy zarządzać.

W skrócie, używanie Javy, Flasha lub Silverlight do łączności z gniazdem jest problematyczne na tyle, że nie widzisz go zbyt często wdrażanego w poważnych architekturach. Flash i Java mają tę zdolność od Prawdopodobnie co najmniej 10 lat, a jednak nie jest powszechna.

WebSocket standard był w stanie rozpocząć od nowego podejścia, mając na uwadze te ograniczenia i miejmy nadzieję, że wyciągnął z nich pewne wnioski.

Niektóre implementacje WebSocket używają Flasha (lub ewentualnie Silverlight i/lub Java) jako alternatywy, gdy połączenie WebSocket nie może być ustanowione (np. podczas uruchamiania w starej przeglądarce lub gdy pośrednik ingeruje).

Podczas gdy jakaś strategia awaryjna w takich sytuacjach jest inteligentna, a nawet konieczna, większość z tych, którzy używają Flasha i innych, będzie cierpieć z powodu wad opisanych powyżej. Nie musi tak być - istnieją obejścia, aby osiągnąć bezpieczne połączenia zdolne do połączenia między źródłami za pomocą Flash, Silverlight itp . - ale większość implementacji tego nie zrobi, ponieważ nie jest to łatwe.

Na przykład, jeśli polegasz na WebSocket dla połączenia cross-origin, które będzie działać dobrze. Ale jeśli następnie uruchomić w starej przeglądarce lub firewall / proxy zakłócony i polegać na Flashu, powiedzmy, jako zapasowy, będzie trudno zrobić to samo połączenie cross-origin. Chyba, że nie zależy ci na ochronie.

Oznacza to, że trudno jest mieć jedną zunifikowaną architekturę, która działa dla połączeń natywnych i nie natywnych, chyba że jesteś gotowy włożyć sporo pracy lub przejść z ramy, które dobrze to zrobiły. W idealnej architekturze nie zauważysz, czy połączenia są natywne, czy nie; Ustawienia zabezpieczeń będą działać w obu przypadkach; ustawienia klastrowania nadal będą działać; planowanie pojemności nadal będzie działać i tak dalej.

Jedyną zaletą WebSockets nad strumieniowaniem http jest to, że nie musisz się starać, aby "zrozumieć" i przeanalizować otrzymane dane.

To nie jest tak proste jak otwarcie strumienia HTTP i siedzenie wróć, gdy Twoje dane będą przepływać przez minuty, godziny lub dłużej. Różni klienci zachowują się inaczej i musisz tym zarządzać. Na przykład niektórzy klienci buforują Dane i nie wypuszczają ich do aplikacji, dopóki nie zostanie osiągnięty pewien próg. Co gorsza, niektórzy nie będą przekazywać danych do aplikacji, dopóki połączenie nie zostanie zamknięte.

Więc jeśli wysyłasz wiele wiadomości do klienta, możliwe jest, że aplikacja kliencka nie otrzyma danych, dopóki nie otrzyma 50 wiadomości o wartości danych / align = "left" / To nie jest zbyt w czasie rzeczywistym.

Chociaż strumieniowanie HTTP może być realną alternatywą, gdy WebSocket nie jest dostępny, nie jest to panaceum. Wymaga dobrego zrozumienia, aby działać w solidny sposób w złych warunkach sieci w rzeczywistych warunkach.

Czy są jakieś inne znaczące różnice, których mi brakuje?

Jest jeszcze jedna rzecz, o której nikt jeszcze nie wspomniał, więc poruszę ją.

Protokół WebSocket był zaprojektowany jako warstwa transportowa dla protokołów wyższego poziomu. Chociaż możesz wysyłać wiadomości JSON lub co-nie bezpośrednio przez połączenie WebSocket, może ono również przenosić standardowe lub niestandardowe protokoły.

Na przykład, można zrobić AMQP lub XMPP przez WebSocket, jak ludzie już to zrobili. Tak więc klient może otrzymywać wiadomości od brokera AMQP, tak jakby był podłączony bezpośrednio do samego brokera (aw niektórych przypadkach tak jest).

Lub jeśli masz istniejący serwer z jakimś niestandardowym protokołem, możesz przenieść to przez WebSocket, rozszerzając w ten sposób ten serwer zaplecza do sieci. Często istniejąca aplikacja, która została zablokowana w przedsiębiorstwie, może rozszerzyć jej zasięg za pomocą WebSocket, bez konieczności zmiany żadnej infrastruktury zaplecza.

(oczywiście, chcesz być w stanie zrobić to wszystko bezpiecznie, więc skontaktuj się z dostawcą lub dostawcą WebSocket.)

Niektórzy określali WebSocket jako TCP dla sieci. Ponieważ tak jak TCP transportuje wyższy poziom protokoły, podobnie jak WebSocket, ale w sposób zgodny z infrastrukturą sieciową.

Tak więc wysyłanie wiadomości JSON (lub cokolwiek innego) bezpośrednio przez WebSocket jest zawsze możliwe, należy również wziąć pod uwagę istniejące protokoły. Ponieważ dla wielu rzeczy, które chcesz zrobić, prawdopodobnie istnieje protokół, który został już pomyślany, aby to zrobić.

Przepraszam, jeśli ponownie zadaję lub łączę wiele pytań już na SO w jedno pytanie, ale po prostu chcę mieć idealny sens ze wszystkich informacji, które są tam w SO I Internecie dotyczące tych pojęć.

To było świetne pytanie, A odpowiedzi były bardzo pouczające!

Jeśli mogę zapytać o jedną dodatkową rzecz: natknąłem się gdzieś w artykule, który mówi, że strumieniowanie http może być również buforowane przez proxy, podczas gdy websockets nie są. co to znaczy?

(StackOverflow ogranicza rozmiar odpowiedzi na komentarze, więc musiałem odpowiadać tutaj, a nie w linii.)

Niektóre serwery proxy buforują statyczne zasoby, aby kolejne żądania od innych klientów mogły uzyskać te statyczne zasoby z proxy, zamiast wracać do centrum serwer WWW, aby je zdobyć. Jest to buforowanie i jest to świetna strategia odciążania żądań i przetwarzania z Twoich centralnych usług.

So client #1 requests http://example.com/images/logo.gif , say. To żądanie przechodzi przez proxy aż do centralnego serwera WWW, który obsługuje logo.gif. Jako logo.gif przechodzi przez proxy, proxy zapisze Ten obraz i powiąże go z adresem http://example.com/images/logo.gif .

Kiedy przychodzi klient # 2 along, a także prośby http://example.com/images/logo.gif , proxy może zwrócić obraz i nie jest wymagana komunikacja z powrotem do serwera www w centrum. Daje to szybszą odpowiedź użytkownikowi końcowemu, co zawsze jest świetne, ale oznacza to również, że na środku jest mniejsze obciążenie. Może to przekładać się na niższe koszty sprzętu, niższe koszty sieci itp. Więc to dobrze.

Problem pojawia się, gdy logo.gif jest aktualizowany na serwerze WWW. Pełnomocnik będzie nadal służyć stary obraz nieświadomy, że istnieje nowy obraz. Prowadzi to do całej sprawy wokół wygaśnięcia, tak że proxy będzie buforować obraz tylko przez krótki czas, zanim "wygaśnie", a następne żądanie przechodzi przez proxy do serwera WWW, który następnie odświeża pamięć podręczną proxy. Istnieją również bardziej zaawansowane rozwiązania, w których centralny serwer może wypchnąć się do znanych pamięci podręcznych itp., a rzeczy mogą być dość wyrafinowane.

Jak to ma związek z Twoim pytanie?

Pytałeś o strumieniowanie HTTP, gdzie serwer strumieniuje HTTP do klienta. Ale streaming HTTP jest tak samo jak zwykły HTTP, z wyjątkiem tego, że nie przestajesz wysyłać danych. Jeśli serwer WWW obsługuje obraz, wysyła HTTP do klienta, który ostatecznie się kończy: wysłałeś cały obraz. A jeśli chcesz wysyłać dane, to jest dokładnie tak samo, ale serwer po prostu wysyła przez naprawdę długi czas (jakby to był gigantyczny obraz, powiedzmy) lub nawet nigdy się nie kończy.

Z punktu proxy w widoku nie można odróżnić HTTP dla zasobu statycznego, takiego jak obraz, lub danych ze streamingu HTTP. W obu tych przypadkach Klient wystąpił z prośbą do serwera. Proxy zapamiętał to żądanie, a także odpowiedź. Następnym razem, gdy pojawi się żądanie, serwer proxy wyśle tę samą odpowiedź.

Więc jeśli twój klient złożył wniosek o ceny akcji, powiedzmy, i otrzymał odpowiedź, wtedy następny klient może złożyć to samo żądanie i uzyskać buforowane dane. Pewnie nie tego chcesz! Jeśli żądasz cen akcji, chcesz najnowszych danych, prawda?

Istnieją sztuczki i obejścia, aby poradzić sobie z takimi problemami, to prawda. Oczywiście możesz uzyskać streaming HTTP do pracy, ponieważ jest on obecnie używany. Wszystko jest przejrzyste dla użytkownika końcowego, ale ludzie, którzy rozwijają i utrzymują te architektury, muszą przejść przez obręcze i zapłacić cenę. Skutkuje to zbyt skomplikowanymi architekturami, co oznacza większą konserwację, więcej sprzętu, większą złożoność, więcej kosztów. Oznacza to również, że deweloperzy często muszą dbać o coś, czego nie powinni mieć, kiedy powinni skupiać się na aplikacji, GUI i logice biznesowej - nie powinni martwić się o podstawową komunikację.

HTTP ogranicza liczbę połączeń, jakie klient może mieć z serwerem do 2 (chociaż można to złagodzić za pomocą subdomen). Firefox i Chrome pozwalają na więcej (choć nie pamiętam dokładnie, ile). Może to nie wydawać się wielkim problemem, ale jeśli używasz 1 połączenia stale do aktualizacji w czasie rzeczywistym, wszystkie inne żądania muszą wąskie gardło przez inne połączenie HTTP. I jest kwestia posiadania więcej otwarte połączenia z klientami obciążają serwer.

WebSockets są protokołem opartym na TCP i jako taki nie cierpią z tego limitu połączeń na poziomie HTTP (ale, oczywiście, obsługa przeglądarki nie jest jednolita).