Przechodzę z programisty komputerowego na webowy i mam problem ze zrozumieniem, dlaczego HTTP jest bezstanowy. Jakie są tego powody? W jaki sposób programista komputerowy, taki jak ja, może przejść na bezpaństwowe środowisko programistyczne?
Przechodzę z programisty komputerowego na webowy i mam problem ze zrozumieniem, dlaczego HTTP jest bezstanowy. Jakie są tego powody? W jaki sposób programista komputerowy, taki jak ja, może przejść na bezpaństwowe środowisko programistyczne?
Odpowiedzi:
Oto najlepsze wytłumaczenie bezpaństwowego Internetu, jakie widziałem:
Jak wyjaśniłem REST mojej żonie
http://www.looah.com/source/view/2284
Żona: Kim jest Roy Fielding?
Ryan: Jakiś facet. On jest mądry.
Żona: Oh? Co on zrobił?
Ryan: Pomógł napisać pierwsze serwery sieciowe, a następnie przeprowadził mnóstwo badań wyjaśniających, dlaczego sieć działa tak, jak działa. Jego nazwa znajduje się w specyfikacji protokołu używanego do pobierania stron z serwerów do przeglądarki.
Żona: Jak to działa?
Ryan: Internet?
Żona: Tak.
Ryan: Hmm. To naprawdę niesamowite. Zabawne jest to, że wszystko jest bardzo niedoceniane. Protokół, o którym mówiłem, HTTP, jest zdolny do wszelkiego rodzaju schludnych rzeczy, które ludzie z jakiegoś powodu ignorują.
Żona: Masz na myśli http jak początek tego, co wpisuję w przeglądarce?
Ryan: Tak. Ta pierwsza część mówi przeglądarce, jakiego protokołu użyć. To, co tam wpisujesz, jest jednym z najważniejszych przełomów w historii komputerów.
Żona: Dlaczego?
Ryan: Ponieważ jest w stanie opisać lokalizację czegoś w dowolnym miejscu na świecie z dowolnego miejsca na świecie. To podstawa sieci. Możesz myśleć o tym jak o współrzędnych GPS dla wiedzy i informacji.
Żona: na strony internetowe?
Ryan: Za wszystko naprawdę. Ten facet, Roy Fielding, dużo mówi o tym, na co wskazują te rzeczy w badaniach, o których mówiłem. Sieć zbudowana jest w stylu architektonicznym o nazwie REST. REST zapewnia definicję zasobu, na co wskazują te rzeczy.
Żona: strona internetowa jest zasobem?
Ryan: W pewnym sensie. Strona internetowa jest reprezentacją zasobu. Zasoby to tylko koncepcje. Adresy URL - te rzeczy, które wpisujesz w przeglądarce ...
Żona: Wiem, co to jest adres URL ...
Ryan: Oh, racja. Mówią przeglądarce, że gdzieś jest jakiś pomysł. Przeglądarka może następnie poprosić o konkretne przedstawienie tej koncepcji. W szczególności przeglądarka prosi o przedstawienie tej koncepcji na stronie internetowej.
Żona: Jakie są inne rodzaje przedstawień?
Ryan: W rzeczywistości reprezentacje to jedna z tych rzeczy, które nie są często używane. W większości przypadków zasób ma tylko jedną reprezentację. Mamy jednak nadzieję, że reprezentacje będą częściej używane w przyszłości, ponieważ wszędzie pojawia się mnóstwo nowych formatów.
Żona: Jak co?
Ryan: Hmm. Istnieje koncepcja, że ludzie nazywają usługi sieciowe. Oznacza to wiele różnych rzeczy dla wielu różnych ludzi, ale podstawową koncepcją jest to, że maszyny mogą korzystać z Internetu tak jak ludzie.
Żona: Czy to kolejna robota?
Ryan: Nie, nie bardzo. Nie chodzi mi o to, że maszyny będą siedzieć przy biurku i przeglądać sieć. Ale komputery mogą używać tych samych protokołów do wysyłania wiadomości w obie strony. Robimy to od dłuższego czasu, ale żadna z technik, których używamy dzisiaj, nie działa dobrze, gdy trzeba być w stanie rozmawiać ze wszystkimi maszynami na całym świecie.
Żona: Dlaczego nie?
Ryan: Ponieważ nie zostały zaprojektowane do takiego użycia. Kiedy Fielding i jego kumple zaczęli budować sieć, najważniejsza była możliwość rozmowy z dowolną maszyną w dowolnym miejscu na świecie. Większość technik, których używamy w pracy, aby zmusić komputery do komunikowania się ze sobą, nie miała tych wymagań. Musisz tylko porozmawiać z małą grupą maszyn.
Żona: A teraz musisz porozmawiać ze wszystkimi maszynami?
Ryan: Tak - i więcej. Musimy być w stanie porozmawiać ze wszystkimi komputerami na temat wszystkich rzeczy, które są na wszystkich innych maszynach. Potrzebujemy więc sposobu, aby jedna maszyna powiedziała innej maszynie o zasobie, który może znajdować się na innej maszynie.
Żona: co?
Ryan: Powiedzmy, że rozmawiasz z siostrą, a ona chce pożyczyć zamiatarkę czy coś takiego. Ale ty tego nie masz - Twoja mama to ma. Więc powiedz siostrze, żeby zamiast tego dostała od mamy. Dzieje się tak przez cały czas, a maszyny też zaczynają mówić.
Żona: Jak więc maszyny mówią sobie nawzajem, gdzie są rzeczy?
Ryan: Oczywiście adres URL. Jeśli wszystko, o czym maszyny muszą rozmawiać, ma odpowiedni adres URL, utworzyłeś komputerowy odpowiednik rzeczownika. To, że ty, ja i reszta świata uzgodniliśmy, że rozmawiamy o rzeczownikach w określony sposób, jest dość ważne, prawda?
Żona: Tak.
Ryan: Maszyny nie mają uniwersalnego rzeczownika - dlatego są do bani. Każdy język programowania, baza danych lub inny rodzaj systemu ma inny sposób mówienia o rzeczownikach. Właśnie dlatego URL jest tak ważny. Pozwólmy wszystkim tym systemom powiedzieć sobie nawzajem o rzeczownikach.
Żona: Ale kiedy patrzę na stronę internetową, nie myślę o tym w ten sposób.
Ryan: Nikt tego nie robi. Poza Fieldingiem i garstką innych ludzi. Właśnie dlatego maszyny wciąż są do bani.
Żona: A co z czasownikami, zaimkami i przymiotnikami?
Ryan: Zabawne, że pytałeś, bo to kolejny duży aspekt REST. Czasowniki i tak są.
Żona: Tylko żartowałem.
Ryan: To był zabawny żart, ale tak naprawdę wcale nie jest żartem. Czasowniki są ważne. Istnieje silna koncepcja programowania i teorii CS zwana polimorfizmem. To jest naukowy sposób na powiedzenie, że różne rzeczowniki mogą mieć przypisany ten sam czasownik.
Żona: Nie rozumiem.
Ryan: Cóż .. Spójrz na stolik do kawy. Jakie są rzeczowniki? Kubek, taca, gazeta, pilot. Co możesz zrobić z tymi wszystkimi rzeczami?
Żona: Nie rozumiem ...
Ryan: Możesz je zdobyć, prawda? Możesz je odebrać. Możesz je przewrócić. Możesz je spalić. Możesz zastosować te same dokładne czasowniki do dowolnego przedmiotu tam siedzącego.
Żona: OK ... więc?
Ryan: Cóż, to ważne. Co, jeśli zamiast mnie mogę powiedzieć: „weź kubek” i „weź gazetę” i „weź pilota”; co jeśli zamiast tego musimy wymyślić różne czasowniki dla każdego z rzeczowników? Nie mogłem używać słowa „get” uniwersalnie, ale zamiast tego musiałem wymyślić nowe słowo dla każdej kombinacji czasownika / rzeczownika.
Żona: Łał! To jest dziwne.
Ryan: Tak jest. Nasze mózgi są wystarczająco inteligentne, aby wiedzieć, że te same czasowniki można stosować do wielu różnych rzeczowników. Niektóre czasowniki są bardziej szczegółowe niż inne i dotyczą tylko niewielkiego zestawu rzeczowników. Na przykład nie mogę prowadzić kubka i nie mogę pić samochodu. Ale niektóre czasowniki są prawie uniwersalne, takie jak GET, PUT i DELETE.
Żona: Nie możesz USUNĄĆ filiżanki.
Ryan: No dobra, ale możesz to wyrzucić. To był kolejny żart, prawda?
Żona: Tak.
Ryan: W każdym razie HTTP - ten protokół stworzony przez Fieldinga i jego przyjaciół - polega na stosowaniu czasowników do rzeczowników. Na przykład, gdy wchodzisz na stronę internetową, przeglądarka wykonuje HTTP GET na adres URL, który wpisujesz i wraca strona internetowa.
Strony internetowe zwykle mają obrazy, prawda? To są osobne zasoby. Strona internetowa po prostu określa adresy URL obrazów, a przeglądarka uruchamia się i wykonuje na nich więcej HTTP GET, dopóki nie zostaną uzyskane wszystkie zasoby i nie wyświetli się strona internetowa. Ale ważne jest tutaj to, że bardzo różne rodzaje rzeczowników można traktować tak samo. Czy rzeczownik jest obrazem, tekstem, wideo, mp3, pokazem slajdów, cokolwiek. Mogę uzyskać wszystkie te rzeczy w ten sam sposób, podając adres URL.
Żona: Wygląda na to, że GET jest dość ważnym czasownikiem.
Ryan: Tak jest. Zwłaszcza, gdy korzystasz z przeglądarki internetowej, ponieważ przeglądarki prawie po prostu GET. Nie robią wiele innych rodzajów interakcji z zasobami. Jest to problem, ponieważ wielu ludzi przypuszcza, że HTTP służy tylko do GETing. Ale HTTP jest w rzeczywistości protokołem o ogólnym przeznaczeniu do stosowania czasowników do rzeczowników.
Żona: Fajnie. Ale wciąż nie rozumiem, jak to cokolwiek zmienia. Jakiego rodzaju rzeczowników i czasowników chcesz?
Ryan: Cóż, rzeczowniki są tam, ale nie w odpowiednim formacie.
Pomyśl o tym, kiedy przeglądasz amazon.com i szukasz rzeczy do kupienia na Boże Narodzenie. Wyobraź sobie, że każdy z produktów to rzeczowniki. Teraz, jeśli były one dostępne w postaci zrozumiałej dla maszyny, można zrobić wiele schludnych rzeczy.
Żona: Dlaczego maszyna nie może zrozumieć normalnej strony internetowej?
Ryan: Ponieważ strony internetowe mają być zrozumiałe dla ludzi. Maszyna nie dba o układ i styl. Maszyny w zasadzie potrzebują tylko danych. Idealnie byłoby, gdyby każdy adres URL miał reprezentację czytelną dla człowieka i maszynową. Gdy komputer Pobiera zasób, poprosi o jego odczyt. Gdy przeglądarka POBIERA zasób dla człowieka, poprosi o zasób czytelny dla człowieka.
Żona: Czy ludzie musieliby tworzyć formaty maszynowe dla wszystkich swoich stron?
Ryan: Gdyby był cenny.
Słuchaj, rozmawialiśmy o tym z dużą abstrakcją. A może weźmiemy prawdziwy przykład. Jesteś nauczycielem - założę się, że w szkole masz duży system komputerowy lub trzy lub cztery systemy komputerowe, które pozwalają zarządzać uczniami: w jakich klasach uczęszczają, jakie są oceny, kontakty w nagłych wypadkach, informacje o książkach, z których uczysz itp. Jeśli systemy są oparte na sieci, prawdopodobnie istnieje adres URL dla każdej z rzeczowników: uczeń, nauczyciel, klasa, książka, pokój itp. W tej chwili pobieranie adresu URL przeglądarka wyświetla stronę internetową. Gdyby dla każdego adresu URL istniała reprezentacja do odczytu maszynowego, zatrzaskiwanie nowych narzędzi w systemie byłoby trywialne, ponieważ wszystkie te informacje byłyby użyteczne w standardowy sposób. Ułatwiłoby to również każdemu systemowi komunikowanie się ze sobą. Lub możesz zbudować system stanowy lub ogólnokrajowy, który byłby w stanie rozmawiać z każdym z poszczególnych systemów szkolnych w celu zbierania wyników testów. Możliwości są nieskończone.
Każdy z systemów uzyskiwałby od siebie informacje za pomocą prostego HTTP GET. Jeśli jeden system musi coś dodać do innego, użyje HTTP POST. Jeśli system chce coś zaktualizować w innym systemie, używa PUT HTTP. Pozostaje tylko ustalić, jak powinny wyglądać dane.
Żona: Więc nad tym pracujesz teraz ty i wszyscy ludzie z komputera? Decydowanie, jak powinny wyglądać dane?
Ryan: Niestety nie. Zamiast tego zdecydowana większość jest zajęta pisaniem warstw o skomplikowanych specyfikacjach, aby wykonywać te czynności w inny sposób, który nie jest tak przydatny ani wymowny. Rzeczowniki nie są uniwersalne, a czasowniki nie są polimorficzne. Rzucamy dziesięciolecia rzeczywistego użytkowania w terenie i sprawdzonej techniki i zaczynamy od czegoś, co wygląda podobnie do innych systemów, które zawiodły w przeszłości. Używamy HTTP, ale tylko dlatego, że pomaga nam to mniej rozmawiać z naszą siecią i osobami odpowiedzialnymi za bezpieczeństwo. Wymieniamy prostotę na krzykliwe narzędzia i kreatory.
Żona: Dlaczego?
Ryan: Nie mam pojęcia.
Żona: Dlaczego nic nie powiesz?
Ryan: Może ja to zrobię.
Jak myślisz, jak byłoby możliwe przechowywanie stanu miliardów miliardów miliardów miliardów połączeń? :) Więc przechowujesz stan tylko w razie potrzeby, w sesjach.
BTW: HTTP nie jest bezpołączeniowy.
persistent connections
tak zwane utrzymywanie aktywności. Nie jestem ekspertem od sieci, ale przez większość czasu masz prawdziwe połączenie HTTP :)
Jako programista pulpitu możesz czuć się bardziej komfortowo dzięki bogatemu interfejsowi użytkownika. Przejście do sieci może być krokiem wstecz. W świecie internetowym jest mniej swobody twórczej i może dać ci poczucie ograniczenia. Nie pozwól, żeby cię to przygnębiło! Istnieje wiele rzeczy, które mogą pomóc Ci przejść, a oto ich krótka lista:
Miłego programowania!
Ponieważ był czas, kiedy miliony stron internetowych nie istniały. Ponieważ był czas, kiedy tylko uniwersytety i ośrodki badawcze miały kilka stron. Był czas, kiedy nie było łączności szerokopasmowej, a http komunikowano z modemami 1200 bodów umieszczonymi na telefonach biurkowych. Był czas, kiedy „bogate aplikacje internetowe” wymagałyby, ich zdaniem, absurdalnej przepustowości. I pamiętaj, TCP / IP został stworzony, ponieważ wczesny Internet był bardzo zawodny.
HTTP 1.0 istniał już na początku lat 90. Zastanów się, jak wyglądał wtedy Internet i dlaczego zaprojektowali go w taki sposób.
Wszystko ewoluowało. Internet istniał przed przeglądarkami internetowymi i internetem. To był bulgoczący garnek ftp, telnet, gopher, ping, finger i kilku innych drobiazgów. Pierwsza przeglądarka internetowa, Mosaic (wydaje mi się, że dawno temu, 1991, chyba byłam na studiach) działała jak swoista mieszanka ftp i przeglądarki dokumentów. Magia polegała na tym, że w dokumencie mogłeś mieć linki, które utworzyłyby nowy dokument.
Cała interaktywność, którą rozwinęliśmy w ciągu następnych 20 lat. To też nie była szczęśliwa ewolucja. Mieliśmy wojny przeglądarkowe, IE i Netscape wykopały go w celu kontroli standardów (trochę uproszczenia;)), a różne inne firmy trzecie zaczęły wprowadzać wtyczki, aby umożliwić bogatą zawartość. Java miała być magiczną kulą i oczywiście Flash. Czy ktoś pamięta wtyczki VRML, które obiecały światy 3d i dostarczyły dokładnie pół tuzina modeli 3D Star Wars?
Trochę mnie poniosło pod koniec, ale masz pomysł :)
Głównymi przyczynami są kombinacja tego, co według wierzącego było celem HTTP, oraz ze względu na skalowalność. HTML został pierwotnie zaprojektowany do udostępniania informacji lub prac dyplomowych ponad granicami akademickimi. To był wyłącznie stylizowany tekst. Dopiero pierwsza przeglądarka pozwoliła wyświetlać zdjęcia, o których ludzie zaczęli myśleć poza tym modelem.
Następujące względy utrwaliły decyzję bezpaństwowca:
Ponieważ strony internetowe stały się bardziej złożone i zawierały wiele grafik i arkuszy stylów, HTTP poprawiono flagą „keep-alive”. Dzięki temu gniazdo będzie działało i klient będzie mógł zażądać kilku zasobów w tej samej rozmowie.
Biorąc pod uwagę obecny model korzystania z Internetu, pierwotna decyzja jest nadal ważna. Czasami może to być niewygodne, ale kilka małych, kwantowanych interakcji z serwerem skaluje się lepiej niż bezczynne gniazda.
Jeśli masz na myśli przeglądarki dwukierunkowe.
Względy bezpieczeństwa.
Na przykład SPAM !.
Przenoszenie komunikacji dwukierunkowej w Internecie na wyższy poziom
W przeciwnym razie internet będzie działał TCP / IP (dwa protokoły) i UDP.
Protokół kontroli transmisji(TCP) jest jednym z podstawowych protokołów pakietu protokołów internetowych. TCP jest jednym z dwóch oryginalnych składników pakietu, uzupełniającym protokół internetowy (IP), dlatego też cały pakiet jest powszechnie nazywany TCP / IP. TCP zapewnia usługę wymiany danych bezpośrednio między dwoma hostami w tej samej sieci, podczas gdy IP obsługuje adresowanie i routing wiadomości w jednej lub więcej sieci. W szczególności TCP zapewnia niezawodne, uporządkowane dostarczanie strumienia bajtów z programu na jednym komputerze do innego programu na innym komputerze. TCP to protokół, na którym polegają główne aplikacje internetowe, takie jak sieć WWW, poczta e-mail i przesyłanie plików. Inne aplikacje, które nie wymagają niezawodnej usługi przesyłania danych,
Protokół internetowy(IP) to główny protokół komunikacyjny używany do przekazywania datagramów (pakietów) w intersieci przy użyciu pakietu protokołów internetowych. Odpowiada za routing pakietów przez granice sieci, jest to główny protokół ustanawiający Internet. IP jest podstawowym protokołem w warstwie internetowej pakietu protokołów internetowych i ma za zadanie dostarczanie datagramów z hosta źródłowego do hosta docelowego wyłącznie na podstawie ich adresów. W tym celu IP określa metody adresowania i struktury enkapsulacji datagramów. Historycznie, IP było bezpołączeniową usługą datagramową w oryginalnym Programie Kontroli Transmisji, wprowadzonym przez Vinta Cerfa i Boba Kahna w 1974 roku, drugim z nich był protokół kontroli transmisji (TCP). Pakiet protokołu internetowego jest więc często określany jako TCP / IP.
W aplikacji komputerowej zakłada się, że użytkownik wykonuje pewną serię zadań z określonym początkiem i końcem. W takiej aplikacji sensowne jest (w rzeczywistości niewiele), aby użytkownicy logowali się na serwerach dostarczających dane i pozostawali zalogowani, dopóki nie skończą.
Interakcje internetowe (zwykle) nie są zgodne z tym samym modelem. Na przykład w witrynie eCommerce użytkownik może dojść do opisu produktu w wyniku wyszukiwania w Google i natychmiast opuścić tę stronę, aby spojrzeć na ofertę tego samego produktu w innej witrynie. Lub może rozpocząć proces realizacji zamówienia, a następnie zdecydować, że produkt jest zbyt drogi i porzucić go w połowie. Podstawowa koncepcja „hipertekstu” oznacza zdolność i oczekiwanie na przeskakiwanie z jednego miejsca do drugiego.
Stałe połączenia zużywają zasoby. Być może tylko gniazdo sieciowe, być może pula przeanalizowanych zapytań do bazy danych; wszystko zależy od aplikacji. Biorąc pod uwagę użytkownika, który może zniknąć w dowolnym momencie, utrzymywanie tych zasobów nie ma sensu.
W praktyce użytkownik nie musi mieć stałego połączenia. Aplikacja internetowa utrzymuje połączenia z dowolnymi potrzebnymi zasobami (np. Bazą danych) i współdzieli je między wszystkimi żądaniami użytkowników. Struktura aplikacji internetowych zapewnia sesje, które są ograniczonymi czasowo miejscami do przechowywania danych dotyczących poszczególnych użytkowników dla różnych żądań. Jedyną rzeczą, której nie możesz (łatwo) zrobić, są długotrwałe transakcje kontrolowane przez klienta, ale to zły pomysł nawet w aplikacji, która utrzymuje połączenia.
Internet niekoniecznie jest bezstanowy - w rzeczywistości, gdy spojrzysz na Java EE - mają Stateful EJB i Stateless EJB.
Głównym powodem, dla którego programiści zalecają stosowanie architektury bezstanowej, jest skalowalność. Wyobraź sobie, że próbujesz utrzymać stan wszystkich użytkowników po dodaniu i upuszczeniu serwerów w celu obsługi ruchu.
Naprawdę nie jest trudno stworzyć bezpaństwową architekturę. Najważniejsze jest utrzymanie jak najmniejszego stanu (zwykle identyfikator użytkownika - najlepiej w pliku cookie) i zmiana bazy danych zgodnie z wymaganiami.
Myślę, że tak się zaczęło i po prostu tak pozostało. Teraz, gdy wokół niego zbudowano tak wiele infrastruktury, nie można jej zmienić.
Być może zaczęło się to bezstanowe, ponieważ połączenia były początkowo mniej niezawodne, a także przepustowość była mniejsza. Jeśli nie masz wielu aktywnych połączeń, możesz łatwiej obsłużyć większy ruch.
Edytuj lub zostaw komentarz, jeśli masz lepsze informacje lub jeszcze lepiej, opublikuj własną odpowiedź!
Jest tak, ponieważ serwery zapewniają usługę (jest w nazwie). Składasz wniosek i otrzymujesz odpowiedzi - to wszystko.
Jeśli chodzi o przejście do tworzenia stron internetowych, wierzę, że ASP.NET Web Forms zrobi to w sposób, który będzie dla ciebie bardziej zrozumiały - ale tylko dlatego, że ukrywa to, co faktycznie dzieje się pod warstwami abstrakcji.
Wiele można zrozumieć, analizując nazwę HTTP (HyperText Transfer Protocol). Nigdy nie został zaprojektowany jako bogaty protokół interfejsu użytkownika. Pierwotny pomysł polegał na udostępnianiu dokumentów z łączami między nimi. Proszę o dokument, odpowiadasz kopią tego dokumentu.
Pierwotnie HTTP miał tylko jeden czasownik GET. W tym względzie został zaprojektowany dla treści statycznych. Dlaczego potrzebujesz stanu, gdy wszystko, co robisz, to zamawianie dokumentu, który ktoś udostępnia? I dlatego HTTP jest bezstanowy ... ze względu na swoje pochodzenie.