Efter att klienten har anslutit sig till tjänsten på en specifik port, får han tillgång till tjänsten med det etablerade protokollet. Ett protokoll är ett förutvecklat förfarande för informationsutbyte mellan den som vill använda tjänsten och den som tillhandahåller tjänsten. Den ”part” som behöver tjänsten kan vara en person, men oftast är den det datorprogram, Till exempel, Webbläsare. Protokoll är ofta textliga beskrivningar av proceduren för informationsutbyte mellan en klient och en server.

UNIX

Det kanske enklaste protokollet är för dagtjänsten. Om du ansluter till port 13 på en maskin som stöder en dagtidsserver kommer den servern att svara med information om dagens datum och tid och kopplar sedan bort anslutningen. Protokollet är som följer: "Om en klient upprättar en anslutning till en dagtidsserver, skickas datum- och tidsdata till den, varefter anslutningen kopplas bort." De flesta UNIX-maskiner stöder denna server. Du kan kontakta honom med hjälp av Telnet-applikationen. På UNIX kommer sessionen att se ut så här:

• %telnet web67.ntx.net 13
• Anslutning till web67.ntx.net.
• Avbryttecknet "^]".
• Söndag 25 oktober 08:34:06 1998

Windows

På en Windows-maskin kan du komma åt den här servern genom att ange "telnet web67.ntx.net 13" i MSDOS-fönstret.

I det här exemplet är web67.ntx.net UNIX-servermaskinen och 13 är portnumret för dagtidstjänsten. Telnet-applikationen ansluter till port 13 (telnet ansluter vanligtvis till port 23, men du kan ange vilken annan port som helst att ansluta till), sedan skickar servern datum- och tidsdata och stänger sedan anslutningen. De flesta versioner av Telnet har möjlighet att ange ett portnummer, och den här funktionen kan användas oavsett vilken version av Telnet som är installerad på maskinen.

De flesta protokoll är mer komplexa än dagtidsprotokollet och definieras i offentligt tillgängliga Requests for Comments (RFC) (för ett bra arkiv över alla RFC:er se sunsite.auc.dk/RFC/). Varje Webbserver på Internet överensstämmer med HTTP-protokollkraven sammanställda i The Original HTTP-dokument 1991. Den viktigaste formen av protokoll som förstås av en HTTP-server involverar bara ett kommando: GET. Om du upprättar en anslutning till en server som kör HTTP och skickar en "GET-filnamn"-förfrågan, kommer servern att svara genom att skicka innehållet till förfrågningskällan specificerad fil, och kopplar sedan bort anslutningen. En typisk session ser ut så här:

• %telnet webbplats 80
• Försöker ansluta till 78.110.59.235...
• Anslutning till pcwork.ru.
• Avbryttecknet "^]".
• Anslutningen avaktiveras av den externa värddatorn.

I den initiala versionen av HTTP-protokollet behövde bara det faktiska filnamnet skickas, till exempel [/] eller Protokollet ändrades senare för att kunna hantera fullständiga URL:er. Detta gjorde det möjligt för företag som hanterar virtuella domäner, under förhållanden där många domäner finns på en dator, att använda en IP-adress för alla sådana domäner.

Sammanfatta

Efter att ha läst den här artikeln har du lärt dig mycket om. Specifikt vet du nu att när du skriver en URL i en webbläsare händer följande:

1. delade upp webbadressen i tre delar:

• Protokoll ("http")
• Servernamn ("webbplats") - in Nyligen positiv tendens att förkorta de tre första bokstäverna www
• Filnamn ("webserver.htm")

Webbläsaren kontaktar namnservern för att översätta servernamnet till en IP-adress, som används av den webbläsaren för att ansluta till motsvarande servermaskin.

Efter att ha tagit emot IP-adressen upprättar den angivna webbläsaren en anslutning till WEB-servern som har denna IP-adress på port 80.

I enlighet med HTTP-protokollet skickar webbläsaren en GET-begäran till denna server för att ta emot filen (Observera att tillsammans med GET-begäran kan cookies skickas från webbläsaren till servern - detaljer finns i artikeln om hur cookies arbete).

Servern skickar HTML-text den begärda webbsidan till webbläsaren. (Cookies kan också skickas från servern till webbläsaren i sidhuvudet.)

Webbläsaren läser HTML-taggarna och visar motsvarande sida på skärmen.

Tillägg: Säkerhet

Av denna beskrivning kan vi dra slutsatsen att en WEB-server kan vara ett ganska enkelt program. Den tar filnamnet som skickas med kommandot GET, hittar filen den letar efter och skickar den till webbläsaren. Även med all porthantering och portkommunikationskod kan du enkelt skapa ett C-program som fungerar som en enkel WEB-server på mindre än 500 rader programkod. Naturligtvis är en fullfjädrad företagswebbserver mer komplex, men de grundläggande principerna för dess drift är fortfarande mycket enkla.

De flesta servrar lägger till en viss nivå av säkerhet i arbetsflödet. För detta ändamål används till exempel lösenordsskyddade sidor. När du försöker öppna en sådan sida med din webbläsare visas en dialogruta som ber dig att ange ditt användarnamn och lösenord. Servern ger ägaren av WEB-sidan möjlighet att använda en lista med namn och lösenord för personer som har tillåtelse till denna sida; i det här fallet tillåter servern att endast se sidan för de som har rätt lösenord. Avancerade servrar har ytterligare funktioner säkerhet som krypterar information som utbyts mellan servern och webbläsaren, vilket gör det möjligt att överföra känslig information som kreditkortsnummer över Internet.

Detta är praktiskt taget alla funktioner som en server designad för att skicka standard, statiska WEB-sidor kan utföra. Statiska sidor är de WEB-sidor som inte ändras förrän de har redigerats av utvecklaren.

Tillägg: Dynamiska sidor

Vad sägs om dynamisk WEB sidor? Till exempel:

• I vilken bok som helst med recensioner får du lämna meddelanden i HTML-form och nästa gång du tittar på den sparas den nya informationen på den här sidan.
• I skärmbilden Network Solutions whois, som svar på inmatning av ett domännamn, tas en WEB-sida emot, vars utseende beror på det angivna namnet.
• I vilken sökmotor som helst i HTML-formulär introduceras nyckelord, varefter maskinen skapar en sida som visar sökresultatet för dessa ord.

I alla ovanstående fall söker WEB-servern inte bara önskad fil. Den bearbetar den mottagna informationen och skapar en WEB-sida som på ett visst sätt motsvarar den mottagna förfrågan. I nästan alla fall använder WEB-servern den så kallade CGI-proceduren för att lösa detta problem.

Varje servermaskin exponerar tjänster från Internet med hjälp av numrerade portar, en för varje tjänst som är tillgänglig på servern. Till exempel, om servermaskinen har en WEB-server och en FTP-server, görs vanligtvis åtkomst till WEB-servern via port 80, och till FTP-server- via port 21. Klienter ansluter till tjänsten genom att välja lämplig adress och ansluta till lämplig port.

Varje populär tjänst tilldelas ett specifikt portnummer. Följande är de vanligaste portnumren:

• eko 7
• dagtid 13
• qotd 17 (dagens citat)
• ftp 21
• telnet 23
• smtp 25 (e-post)
• tid 37
• namnserver 53 (namnserver)
• smeknamn 43 (vem är vem)
• gopher 70
• finger 79
• WWW 80

Restriktioner

Om servermaskinen tillåter anslutning till en port från Internet och denna port inte är skyddad, kan du ansluta till den var som helst på Internet och använda motsvarande tjänst. Det bör noteras att det inte finns några restriktioner som kräver att t.ex. WEB-servern ansluter på port 80. Genom att driftsätta din egen maskin och installera WEB-serverns mjukvara på den kan du, om så önskas, ange att WEB-servern ska fungera , till exempel på port 918 , eller på någon annan ledig hamn. Sedan, om maskinen heter xxx.yyy.com, kan du ansluta till den här servern över Internet med URL:en xxx.yyy.com:918. ":918"-delen anger explicit portnumret och måste läggas till av alla som vill kontakta denna server. Om ingen port anges försöker webbläsaren som standard att ansluta till den gemensamma porten 80.

HTTP. Det bygger på interaktion" klient-server", det vill säga det antas att:

1. Konsument- klient efter att ha initierat en anslutning med leverantör-servern, skickar den en begäran;
2. Leverantör- server, efter att ha tagit emot begäran, utför de nödvändiga åtgärderna och returnerar ett svar med resultatet till klienten.

   I det här fallet finns det två möjliga sätt att organisera arbetet på klientdatorn:

   • Tunn klientär en klientdator som överför all informationsbehandling till servern. Exempel tunn klient kan fungera som en dator med en webbläsare som används för att arbeta med webbapplikationer.
   • Fet klient, tvärtom, bearbetar information oberoende av servern och använder den senare huvudsakligen endast för datalagring.

Innan vi går vidare till specifika klient-server-webbtekniker, låt oss titta på de grundläggande principerna och strukturen för det grundläggande HTTP-protokollet.

HTTP-protokoll

HTTP (HyperText Transfer Protocol - RFC 1945, RFC 2616) är ett applikationslagerprotokoll för överföring av hypertext.

Den centrala enheten i HTTP är resurs Webbadressen som pekade på i klientförfrågan. Dessa resurser är vanligtvis filer som lagras på servern. En egenskap hos HTTP-protokollet är möjligheten att i förfrågan och svar specificera metoden för att representera samma resurs enligt olika parametrar: format, kodning, språk etc. Det är tack vare möjligheten att specificera metoden för att koda ett meddelande att klienten och servern kan utbyta binär data, även om detta protokoll initialt utformats för att överföra symbolisk information. Vid första anblicken kan detta verka som ett slöseri med resurser. Faktum är att data i symbolisk form tar upp mer minne, meddelanden skapar ytterligare belastning på kommunikationskanaler, men detta format har många fördelar. Meddelanden som sänds över nätverket är läsbara och efter att ha analyserat mottagna data, Systemadministratör kan enkelt hitta felet och åtgärda det. Om det behövs kan en person spela rollen som en av de interagerande applikationerna genom att manuellt mata in meddelanden i önskat format.

Till skillnad från många andra protokoll är HTTP ett minneslöst protokoll. Detta innebär att protokollet inte lagrar information om tidigare klientförfrågningar och serversvar. Komponenter som använder HTTP kan självständigt upprätthålla tillståndsinformation kopplad till senaste förfrågningar och svar. Till exempel klient webbapplikation, skicka förfrågningar, kan övervaka svarsförseningar och webbserver kan lagra IP-adresser och begära rubriker för de senaste klienterna.

Allt programvara för att arbeta med HTTP-protokollet är indelat i tre huvudkategorier:

• Servrar- leverantörer av informationslagrings- och bearbetningstjänster (behandling av begäran).
• Kunder- Slutkonsumenter av servertjänster (sända förfrågningar).
• Proxyservrar att stödja färdtjänsternas arbete.

Huvudkunderna är webbläsare t.ex.: Internet Explorer, Opera, Mozilla Firefox, Netscape Navigator och andra. De mest populära webbserverimplementeringarna är: Internet Information Tjänster (IIS), Apache, lighttpd, nginx. De mest kända proxyserverimplementeringarna: Squid, UserGate, Multiproxy, Naviscope.

Det "klassiska" HTTP-sessionsschemat ser ut så här.

1. Upprätta en TCP-anslutning.
2. Kundförfrågan.
3. Serversvar.
4. Avbryter TCP-anslutningen.

Således skickar klienten en begäran till servern, får ett svar från den, varefter interaktionen stoppas. Vanligtvis är klientbegäran en begäran att överföra ett HTML-dokument eller någon annan resurs, och serversvaret innehåller koden för denna resurs.

HTTP-begäran som skickas av klienten till servern innehåller följande komponenter.

• Statusrad (ibland används termerna statusrad eller frågerad för att referera till den).
• Rubrikfält.
• Tom linje.
• Begäran kropp.

Statusfältet tillsammans med rubrikfält ibland också kallas förfrågans rubrik.

Ris. 2.1.

Statusfältet har följande format:

request_method URL_pecypca protocol_version HTTP

Låt oss titta på komponenterna i statusfältet, med särskild uppmärksamhet på förfrågningsmetoderna.

Metod som anges i statusraden avgör hur resursen vars URL anges på samma rad påverkas. Metoden kan ta värdena GET, POST, HEAD, PUT, DELETE, etc. Trots överflöd av metoder är bara två av dem verkligen viktiga för en webbprogrammerare: GET och POST.

• SKAFFA SIG. Enligt den formella definitionen är GET-metoden avsedd att erhålla en resurs med en specificerad URL. Vid mottagande av en GET-begäran måste servern läsa den angivna resursen och inkludera resurskoden som en del av svaret till klienten. Resursen vars URL skickas som en del av begäran behöver inte vara en HTML-sida, bildfil eller annan data. Resursens URL kan peka på körbar programkod som, om vissa villkor är uppfyllda, måste köras på servern. I det här fallet returneras inte programkoden till klienten, utan den data som genereras under dess exekvering. Även om GET-metoden per definition är avsedd att hämta information kan den användas för andra ändamål. GET-metoden är ganska lämplig för att överföra små bitar av data till servern.
• POSTA. Enligt samma formella definition är huvudsyftet med POST-metoden att överföra data till servern. Men liksom GET-metoden kan POST-metoden användas på många olika sätt och används ofta för att hämta information från en server. Precis som med GET-metoden pekar URL:en som anges i statusfältet till en specifik resurs. POST-metoden kan också användas för att starta en process.
• HEAD- och PUT-metoderna är modifieringar av GET- och POST-metoderna.

Protokollversion HTTP anges vanligtvis i följande format:

HTTP/version.modification

Rubrikfält, efter statusraden, låter dig förfina begäran, dvs. överföra till servern Ytterligare information. Rubrikfältet har följande format:

Fältnamn: Värde

Syftet med ett fält bestäms av dess namn, som skiljs från värdet med ett kolon.

Namnen på några av de vanligaste rubrikfälten i en klientförfrågan och deras syfte visas i Tabell 2.1.

Tabell 2.1. HTTP-begäran rubrikfält.

Rubrikfält HTTP -begäran	Menande
Värd	Domännamn eller IP-adress för värden som klienten har åtkomst till
Referent	URL till dokumentet som refererar till resursen som anges i statusfältet
Från	Adress E-post användare som arbetar med klienten
Acceptera	MIME-typer av data som bearbetas av klienten. Det här fältet kan ha flera värden, separerade med kommatecken. Ofta används fältet Acceptera rubrik för att tala om för servern vilka typer grafiska filer klienten stödjer
Acceptera-språk	En uppsättning identifierare med två tecken, separerade med kommatecken, som indikerar de språk som stöds av klienten
Acceptera-Charset	Lista över teckenuppsättningar som stöds
Innehållstyp	MIME-typ av data som finns i förfrågningskroppen (om begäran inte består av en enda rubrik)
Innehåll-Längd	Antal tecken i förfrågningstexten (om begäran inte består av en enda rubrik)
Räckvidd	Närvarande om klienten inte begär hela handlingen, utan endast en del av den
Förbindelse	Används för att hantera TCP-anslutning. Om fältet innehåller Close betyder det att servern ska stänga anslutningen efter att ha bearbetat begäran. Keep-Alive-värdet föreslår att TCP-anslutningen ska hållas öppen så att den kan användas för efterföljande förfrågningar
Användaragent	Kundinformation

I många fall, när du arbetar på webben, finns det inget förfrågningsorgan. När CGI-skript körs kan data som skickas till dem i begäran placeras i förfrågans brödtext.

Vi har släppt en ny bok "Content Marketing in i sociala nätverk: Hur du kommer in i dina prenumeranters huvuden och får dem att bli kära i ditt varumärke."

Webbtjänst (tjänst) är ett program som organiserar interaktion mellan webbplatser. Information från en portal överförs till en annan.

Det finns till exempel ett flygbolag. Hon har många flygresor, vilket gör att hon har många biljetter. Den överför information via en webbtjänst till en webbplats för reseaggregat. En användare som kommer åt aggregatorn kommer att kunna köpa biljetter till detta flygbolag direkt där.

Ett annat exempel på webbtjänster är en väderspårningssajt som innehåller information om väderförhållanden i en specifik stad eller ett land som helhet. Denna informationen används också ofta av tredje part.

Informationen på Internet är varierad. Webbplatserna hanteras av olika system. Olika överförings- och krypteringsprotokoll används. Webbtjänster förenklar utbytet av information mellan olika webbplatser.

Webbtjänster arkitektur och protokoll

Du kan definiera 3 myndigheter som interagerar med varandra: katalog, entreprenör och kund. Efter att ha skapat tjänsten registrerar entreprenören den i katalogen och kunden hittar tjänsten där.

Mekanismen för datautbyte bildas i webbtjänstbeskrivningen. Detta är en specifikation som täcker vidarebefordringsformat, innehållstyper, transportprotokoll som används i processen för informationsutbyte mellan kunden och tjänstetransportören.

Idag används oftast flera tekniker för att implementera olika webbtjänster:

1. TCP/IP är ett protokoll som förstås av nästan alla nätverksutrustning, från stordatorer till bärbara enheter och handdatorer.
2. HTML är ett universellt märkningsspråk som används för att visa innehåll på konsumentenheter.
3. XML är ett universellt verktyg för att bearbeta alla typer av data. Andra protokoll för informationsutbyte kan fungera på grundval av detta: SOAP och WSDL.
4. UDDI är en universell källa till erkännande, integration och beskrivning. Det fungerar som regel i privata nätverk och har ännu inte hittat tillräcklig distribution.

Mångsidigheten hos de presenterade teknologierna är grunden för att förstå webbtjänster. De arbetar för standardteknik, oberoende av applikationsleverantörer och andra nätverksresurser. Kan användas i alla operativsystem, applikationsservrar, programmeringsspråk etc.

Fördelar

• Skapa de nödvändiga förutsättningarna för interaktion mjukvarukomponenter oavsett plattform.
• Webbtjänster är baserade på öppna standardprotokoll. Tack vare införandet av XML förenklas skapandet och konfigureringen av webbtjänster.
• Användningen av HTTP garanterar interaktion mellan systemen genom tillgång till Internet.

Brister

• Låg prestanda och stor trafikvolym, i jämförelse med RMI, CORBA, DCOM-system, på grund av användningen av XML-meddelanden i textsammanhang.
• Säkerhetsnivå. Alla moderna webbtjänster måste implementera kodning och kräver användarbehörighet. Huruvida HTTPS räcker här eller om mer tillförlitliga protokoll behövs, såsom XML-kryptering, SAML, etc., avgörs under utvecklingen.

Uppgifter för webbtjänster

Webbtjänster kan användas inom många områden.

B2B-transaktioner

Integrering av processer sker omedelbart, utan medverkan av människor. Till exempel uppdatera onlinebutikskatalogen med nya produkter. De förs till lagret och lagerhållaren noterar ankomsten i databasen. Informationen överförs automatiskt till webbutiken. Och köparen, istället för att markera "Ej i lager" på produktkortet, ser dess kvantitet.

Integration av företagstjänster

Om företaget använder företagsprogram, kommer webbtjänsten att hjälpa till att sätta upp deras gemensamma arbete.

Skapa ett klient-serversystem

Tjänster används för att konfigurera klienten och servern. Detta ger fördelar:

• Du kan inte sälja själva programvaran, utan göra betald tillgång till webbtjänsten;
• Det är lättare att lösa problem med programvara från tredje part;
• det är lättare att organisera åtkomst till serverns innehåll och material.

En webbtjänst är en applikation som förenklar den tekniska installationen av resursinteraktion.

World Wide Web är en färdig plattform för att skapa och använda distribuerade maskinorienterade system baserade på webbtjänster. Webbservern fungerar som en applikationsserver som inte nås av slutanvändare utan av tredjepartsapplikationer. Detta gör att du kan återanvända funktionella element, eliminera kodduplicering och förenkla lösningen av applikationsintegrationsproblem.

Webb-service, webb-service(engelsk webbtjänst) är nätverksteknik, tillhandahåller inter-program interaktion baserat på webbstandarder. W3C definierar en webbtjänst som "ett mjukvarusystem utformat för att stödja interoperabel maskin-till-maskin-kommunikation över ett nätverk."

Webbtjänster: Koncept och protokoll

En webbtjänst identifieras av en URI-sträng. Webbtjänsten har ett mjukvarugränssnitt presenterat i ett maskinbearbetbart format. Andra system interagerar med denna webbtjänst genom att utbyta protokollmeddelanden. HTTP-protokollet används som en transport för meddelanden. Beskrivningar av webbtjänster och deras API:er kan hittas med . Teknikens konceptuella diagram visas i, och förhållandet mellan protokollen visas i fig. 2.

Ris. 1. Webbtjänstkoncept

• TVÅL(Simple Object Access Protocol) - ett protokoll för att utbyta meddelanden mellan konsumenten och webbtjänstleverantören;
• WSDL(Web Services Description Language) - språk för att beskriva externa gränssnitt för en webbtjänst;
• UDDI(Universal Discovery, Description and Integration) - ett universellt igenkännings-, beskrivnings- och integrationsgränssnitt som används för att skapa en katalog över webbtjänster och komma åt den.

Ris. 2. Protokoll för webbtjänster

Alla specifikationer som används i tekniken är baserade på XML och ärver följaktligen dess fördelar (strukturering, flexibilitet etc.) och nackdelar (krånglighet, långsamhet).

TVÅL

SOAP (ursprungligen Simple Object Access Protocol, och i version 1.2 finns det ingen officiell avkodning av förkortningen) är ett enkelt protokoll för att komma åt objekt (komponenter i ett distribuerat datorsystem), baserat på utbyte av strukturerade meddelanden. Som alla textprotokoll kan SOAP användas med alla applikationslagerprotokoll: SMTP, FTP, HTTPS, etc., men oftast används SOAP över HTTP.

Alla SOAP-meddelanden är formaterade i en struktur som kallas kuvert(kuvert), inklusive följande element:

• Meddelande-ID (lokalt namn).
• Valfritt rubrikelement:
  • Noll eller fler egenskaper tillgängliga i det här namnområdet.
• Obligatoriskt Body-element (meddelandetext)
  • Noll eller fler referenser till använda namnutrymmen;
  • Barnelement meddelandetext

En detaljerad lista över SOAP-meddelandeelement finns i dataschemat (för SOAP version 1.2).

Exempel SOAP-meddelande:

Kuvert xmlns:env=" http://www.w3.org/2003/05/soap-envelope"> Rubrik> 1 2001-06-22T14:00:00-05:00 Rubrik> Kropp> Gå upp 06:30 Kropp> Kuvert>

XML-RPC: Inte en konkurrent, utan ett alternativ till SOAP

XML-RPC är ett mycket enkelt och effektivt protokoll för att kommunicera webbtjänster. Det är inte utformat för att lösa globala problem som SOAP, men används ofta i många webbutvecklingar.

XML-RPC koncept

Tabell 1. Grundläggande element i WSDL-protokollet.

WSDL 1.1-element	WSDL 2.0-element	Kort beskrivning
PortType	Gränssnitt	Representerar en beskrivning av webbtjänstens gränssnitt (en lista över operationer och deras parametrar).
Service	Service	Lista över systemfunktioner
Bindande	Bindande	Specificerar gränssnitt och ställer in bindningsparametrar med SOAP-protokollet: bindningsstil (RPC/Document) och transport (SOAP). Det här avsnittet är också tillgängligt för var och en av operationerna
Drift	Drift	Definierar operationen som visas av webbservern. En WSDL-operation är en analog till traditionella funktioner och procedurer.
Meddelande	inte använd	Ett meddelande kopplat till en specifik operation. Innehåller information som är nödvändig för att utföra en given operation. Varje meddelande kan bestå av flera logiska delar som beskriver datatyper och attributnamn. I version 2.0 uteslöts det pga Stöd för XML Schema introducerades för alla element.
Typer	Typer	Beskrivning av data i enlighet med XML Schema.

Ris. 3. WSDL-protokollstruktur

WSDL 1.1-specifikationen definierade fyra meddelandeutbytesmönster (operationstyper):

• Envägsoperationer: En operation kan ta emot ett meddelande men kommer inte att returnera ett svar.
• Request-response: Operationen kan acceptera en begäran och måste returnera ett svar.
• Fråga-svar (Sök-svar): operationen kan skicka en förfrågan och väntar på svar på den.
• Meddelande: Operationen kan skicka ett meddelande, men väntar inte på ett svar.

I WSDL 2.0 modifieras och utökas dessa mallar för att stödja felmeddelanden (till exempel mallen Robust-in-only), men för bakåtkompatibilitet WSDL 1.1-typer stöds

UDDI förlitar sig på industristandarder HTTP, XML, XML Schema (XSD), SOAP och WSDL. Det konceptuella förhållandet mellan UDDI och andra protokoll i webbtjänststacken visas i.

Ris. 4. UDDI:s plats i Web Services Protocol Stack

UDDI-registrets funktion är att representera data och metadata om webbtjänster. Det kan användas både online allmänt bruk och inom organisationens interna infrastruktur. UDDI-registret tillhandahåller en standardbaserad mekanism för klassificering, katalogisering och hantering av webbtjänster så att webbtjänster kan användas av andra applikationer. Denna mekanism inkluderar faciliteter för att hitta en tjänst, anropa den tjänsten och hantera metadata om den tjänsten.

De viktigaste funktionerna i UDDI är att publicera information om en tjänst till ett register och hämta den informationen tredje parts applikationer. Tillsammans med dessa implementeras också typiska funktioner för en katalogtjänst: representation av den lagrade datamodellen och strukturen informationsbas, relationer mellan registerobjekt, replikering, säkerhet osv. —Alla huvudfunktioner i registret presenteras som webbtjänster och är tillgängliga via UDDI API.

Webbtjänster: Pro et Contra

Fördelar

• Ge interaktion mjukvarusystem oavsett plattform.
• Baserat på öppna standarder och protokoll.
• Att använda HTTP tillåter applikationer att kommunicera över en brandvägg.

Brister

• Lägre prestanda och högre volym nätverkstrafik jämfört med tekniker som CORBA eller DCOM.

Permanent adress för denna sida:

Låter dig ta emot olika resurser, till exempel HTML-dokument. HTTP-protokollet ligger till grund för datautbyte på Internet. HTTP är ett klient-server kommunikationsprotokoll, vilket innebär att förfrågningar till servern initieras av mottagaren själv, vanligtvis en webbläsare. Det resulterande slutdokumentet kommer (kan) bestå av olika deldokument som ingår i slutdokumentet: till exempel separat mottagen text, en beskrivning av dokumentstrukturen, bilder, videofiler, skript och mycket mer.

Klienter och servrar kommunicerar genom att utbyta enstaka meddelanden (snarare än en dataström). Meddelanden som skickas av en klient, vanligtvis en webbläsare, anropas förfrågningar, och meddelanden som skickas av servern anropas svarar.

Även om HTTP utvecklades i början av 1990-talet, har det kontinuerligt förbättrats på grund av dess utbyggbarhet. HTTP är ett applikationslagerprotokoll som oftast använder kapaciteten hos ett annat protokoll - TCP (eller TLS - säker TCP) - för att vidarebefordra sina meddelanden, men vilket annat tillförlitligt transportprotokoll som helst kan teoretiskt användas för att leverera sådana meddelanden. På grund av dess utbyggbarhet används den inte bara för att klienten ska ta emot hypertextdokument, bilder och videor, utan också för att överföra innehåll till servrar, till exempel med HTML-formulär. HTTP kan också användas för att endast hämta delar av ett dokument i syfte att uppdatera en webbsida på begäran (till exempel via en AJAX-förfrågan).

Komponenter i HTTP-baserade system

HTTP är ett klient-serverprotokoll, det vill säga förfrågningar skickas av en part - en deltagare i utbytet (user-agent) (eller en proxy istället). Oftast är deltagaren en webbläsare, men det kan vara vem som helst, till exempel en robot som reser på webben för att fylla på och uppdatera webbsidors indexeringsdata för sökmotorer.

Varje begäran begäran) skickas till servern, som bearbetar den och returnerar ett svar (eng. svar). Mellan dessa förfrågningar och svar finns det vanligtvis många mellanhänder som kallas proxyservrar, som utför olika operationer och fungerar som gateways eller cacher, till exempel.

Vanligtvis finns det mellan webbläsaren och servern många fler olika mellanliggande enheter som spelar en viss roll i behandlingen av begäran: routrar, modem och så vidare. På grund av att nätverket är uppbyggt på basis av ett system av interaktionsnivåer (lager) är dessa mellanhänder "dolda" på nätverks- och transportnivåer. I detta lagersystem upptar HTTP det översta lagret, vilket kallas "applikations"-lagret (eller "applikationslagret"). Kunskap om nätverksskikt som presentation, session, transport, nätverk, länk och fysiskt är väsentligt för att förstå nätverksdrift och diagnostik. eventuella problem, men krävs inte för att beskriva och förstå HTTP.

Kund: utbytesdeltagare

En användaragent är alla verktyg eller enheter som agerar på uppdrag av en användare. Denna uppgift utförs i första hand av webbläsaren; i vissa fall är deltagarna program som används av ingenjörer och webbutvecklare för att felsöka sina applikationer.

Webbläsare Alltidär den enhet som skapar begäran. Servern gör vanligtvis inte detta, även om nätverket under åren har utvecklat sätt att tillåta förfrågningar på serversidan att uppfyllas.

För att visa en webbsida skickar webbläsaren en första begäran om att hämta HTML-dokumentet för den sidan. Efter detta undersöker webbläsaren detta dokument och begär ytterligare filer som behövs för att visa innehållet på webbsidan (körbara skript, sidlayoutinformation - CSS-tabeller stilar, ytterligare resurser i form av bilder och videofiler) som är direkt en del av källdokumentet, men som finns på andra platser i nätverket. Därefter ansluter webbläsaren alla dessa resurser för att visa dem för användaren i form av ett enda dokument - en webbsida. Skript som exekveras av webbläsaren själv kan ta emot ytterligare resurser över nätverket vid senare stadier av bearbetningen av webbsidan, och webbläsaren uppdaterar visningen av den sidan för användaren i enlighet därmed.

En webbsida är ett hypertextdokument. Det betyder att vissa delar av den visade texten är länkar som kan aktiveras (vanligtvis genom att klicka på en musknapp) för att hämta och följaktligen visa en ny webbsida (efter en länk). Detta gör att användaren kan "navigera" webbsidor (Internet). Webbläsaren konverterar dessa hyperlänkar till HTTP-förfrågningar och visar sedan de mottagna HTTP-svaren i en användarvänlig form.

webbserver

På andra sidan kommunikationskanalen finns en server som servar (eng. tjäna) användare, förse honom med dokument på begäran. Ur slutanvändarens synvinkel är servern alltid en virtuell maskin, som genererar ett dokument helt eller delvis, även om det i själva verket kan vara en grupp av servrar mellan vilka belastningen är balanserad, det vill säga förfrågningar från olika användare omfördelas, eller komplex programvara som pollar andra datorer (som cacheservrar , databasservrar, e-handelsapplikationsservrar och annat).

En server är inte nödvändigtvis placerad på en maskin, och vice versa - flera servrar kan finnas (värd) på samma maskin. Enligt HTTP/1.1-versionen och med en Host-header kan de till och med dela samma IP-adress.

Ombud

Mellan webbläsaren och servern finns ett stort antal nätverksnoder som sänder HTTP-meddelanden. På grund av sin skiktade struktur verkar de flesta av dem också på transportnätet eller fysiska nivåer, bli transparent för HTTP-lagret och potentiellt minska prestanda. Dessa operationer på applikationsnivå kallas ombud . De kan eller kanske inte är transparenta (ändringsförfrågningar går inte igenom dem) och kan utföra många funktioner:

• cache (cache kan vara offentligt eller privat, som webbläsarens cache)
• filtrering (som antivirusskanning, föräldrakontroll, …)
• lastbalansering (tillåt flera servrar att betjäna olika förfrågningar)
• autentisering (kontrollera åtkomst till olika resurser)
• loggning (tillstånd att lagra transaktionshistorik)

Grundläggande aspekter av HTTP

HTTP är enkelt

Även med den större komplexiteten som introduceras i HTTP/2 genom att kapsla in HTTP-meddelanden i ramar, är HTTP i allmänhet enkelt och läsbart för människor. HTTP-meddelanden kan läsas och förstås av människor, vilket ger enklare testning för utvecklare och minskad komplexitet för nya användare.

HTTP - utökningsbar

HTTP-huvudena som introducerades i HTTP/1.0 gjorde protokollet lätt att utöka och experimentera med. Ny funktionalitet kan till och med introduceras genom en enkel överenskommelse mellan klient och server om semantiken för den nya rubriken.

HTTP är tillståndslöst men har en session

HTTP är tillståndslöst: det finns inget förhållande mellan två förfrågningar som exekveras sekventiellt över samma anslutning. Detta innebär omedelbart risken för problem för en användare som försöker interagera med en viss sida sekventiellt, till exempel när han använder en kundvagn i en onlinebutik. Men medan HTTP-kärnan är tillståndslös, möjliggör cookies tillståndssessioner. Genom att använda header-utvidgbarhet läggs cookies till i arbetstråden, vilket gör att sessionen kan dela något sammanhang, eller tillstånd, på varje HTTP-begäran.

HTTP och anslutningar

Anslutningen hanteras i transportlagret och går därför i grunden utanför HTTPs gränser. Även om HTTP inte kräver att det underliggande transportprotokollet är anslutningsbaserat, kräver endast pålitlighet, eller inga förlorade meddelanden (d.v.s. åtminstone en felrepresentation). Bland de två vanligaste transportprotokollen på Internet är TCP tillförlitligt medan UDP inte är det. HTTP förlitar sig därefter på att TCP-standarden är anslutningsbaserad, även om en anslutning inte alltid krävs.

HTTP/1.0 öppnade en TCP-anslutning för varje begäran/svarsutbyte, med två viktiga nackdelar: att öppna en anslutning kräver flera meddelandeutbyten och är därför långsam, även om det blir mer effektivt när du skickar flera meddelanden, eller när du skickar meddelanden regelbundet: värma anslutningar är effektivare än kall.

För att mildra dessa brister introducerade HTTP/1.1 pipelining (vilket visade sig vara svårt att implementera) och beständiga anslutningar: den underliggande TCP-anslutningen kan delvis kontrolleras via anslutningshuvudet. HTTP/2 tog nästa steg genom att lägga till multiplexering av meddelanden över en enkel anslutning, vilket bidrog till att hålla anslutningen varm och effektivare.

Experiment genomförs för att utveckla ett bättre transportprotokoll som är mer lämpat för HTTP. Till exempel experimenterar Google med QUIC, som är baserat på UDP, för att tillhandahålla ett mer tillförlitligt och effektivt transportprotokoll.

Vad kan styras via HTTP

Den naturliga töjbarheten för HTTP har möjliggjort större kontroll och funktionalitet av webben över tid. Cache och autentiseringsmetoder var tidiga funktioner i HTTP-historien. Möjligheten att lätta på de ursprungliga restriktionerna tillkom å andra sidan på 2010-talet.

Följande är vanliga funktioner som hanteras med HTTP.

• 
  Servern kan instruera proxyservrar och klienter vad som ska cachelagras och hur länge. Klienten kan instruera mellanliggande cache-proxyer att ignorera lagrade dokument.
• Avslappnande källbegränsningar
  För att förhindra spionprogram och andra integritetskränkande intrång upprätthåller webbläsaren strikt åtskillnad mellan webbplatser. Endast sidor från samma källa kan komma åt information på webbsidan. Även om sådana begränsningar belastar servern, kan HTTP-rubriker lätta på den strikta separationen på serversidan, vilket gör att dokumentet kan bli en del av information från olika domäner (av säkerhetsskäl).
• Autentisering
  Vissa sidor är endast tillgängliga för speciella användare. Grundläggande autentisering kan tillhandahållas via HTTP, antingen genom att använda WWW-Authenticate och liknande rubriker, eller genom att skapa en speciell session med cookies.
• Proxy och tunnling
  Servrar och/eller klienter finns ofta på ett intranät och döljer sina riktiga IP-adresser för andra. HTTP-förfrågningar gå igenom en proxy för att passera denna nätverksbarriär. Alla proxyservrar är inte HTTP-proxyer. SOCKS-protokollet, till exempel, fungerar på en lägre nivå. Andra, såsom ftp, kan hanteras av dessa fullmakter.
• Sessioner
  Genom att använda en HTTP-cookie kan du associera en begäran med ett tillstånd på servern. Detta skapar en session, även om HTTP är ett tillståndslöst protokoll i sin kärna. Detta är användbart inte bara för kundvagnar i onlinebutiker, utan också för alla webbplatser som låter användaren anpassa utgången.

HTTP-ström

När en klient vill kommunicera med en server, oavsett om det är en slutlig server eller en mellanproxy, följer den dessa steg:

1. Öppna en TCP-anslutning: En TCP-anslutning kommer att användas för att skicka en begäran eller förfrågningar och ta emot ett svar. Klienten kan öppna en ny anslutning, återanvända en befintlig eller öppna flera TCP-anslutningar till servern.
2. Skicka ett HTTP-meddelande: HTTP-meddelanden (före HTTP/2) är läsbara för människor. Sedan HTTP/2, enkla meddelandenär inkapslade i ramar, vilket gör dem omöjliga att läsa direkt, men förblir i grunden desamma. GET / HTTP/1.1 Värd: webbplats Acceptera-språk: fr
3. Läser svar från server: HTTP/1.1 200 OK Datum: lör, 09 okt 2010 14:28:02 GMT Server: Apache Senast ändrad: Tis, 01 dec 2009 20:18:22 GMT ETag: "51142bc1-794497b-47491b-47497b-47497b" Acceptera-intervall: byte Innehåll-Längd: 29769 Innehåll-Typ: text/html
4. Stänger eller återanvänder anslutningen för ytterligare förfrågningar.

Om HTTP-pipeline är aktiverad kan flera förfrågningar skickas utan att vänta på att det första svaret tas emot i sin helhet. HTTP-pipelinen är svår att integrera i befintliga nätverk, där gamla programvaror samexisterar med moderna versioner. HTTP-pipelinen ersattes i HTTP/2 med mer tillförlitliga multiplexerade förfrågningar i en ram.

HTTP-meddelanden

HTTP/1.1 och tidigare HTTP-meddelanden är läsbara för människor. I HTTP/2 är dessa meddelanden inbäddade i en ny binär struktur, en ram, som tillåter optimeringar som header-komprimering och multiplexering. Även om en del av det ursprungliga HTTP-meddelandet skickas i den här versionen av HTTP, ändras inte semantiken för varje meddelande och klienten återskapar (praktiskt taget) den ursprungliga HTTP-begäran. Det är också användbart för att förstå HTTP/2-meddelanden i HTTP/1.1-format.

Det finns två typer av HTTP-meddelanden, förfrågningar och svar, var och en i olika format.

Förfrågningar

Exempel på HTTP-förfrågningar:

• HTTP-metod, vanligtvis ett verb som GET,
• Rubriker (valfritt) som ger ytterligare information till servern.
• Eller en kropp, för vissa metoder som POST, som innehåller resursen som skickades.

Svar

Exempel på svar:

• HTTP-protokollversion.
• HTTP-statuskod som indikerar framgången av begäran eller orsaken till misslyckandet.
• Statusmeddelande -- en kort beskrivning av statuskoden.
• HTTP-rubriker liknar rubriker i förfrågningar.
• Valfritt: en text som innehåller resursen som skickas.

Slutsats

HTTP är ett lättanvänt, utbyggbart protokoll. Klient-serverstrukturen, tillsammans med möjligheten att enkelt lägga till rubriker, tillåter HTTP att gå vidare med webbens expanderande möjligheter.

Även om HTTP/2 lägger till viss komplexitet genom att bädda in HTTP-meddelanden i ramar för att förbättra prestanda, förblir den grundläggande meddelandestrukturen med HTTP/1.0. Sessionstråden förblir enkel och möjliggör utforskning och felsökning med lätthet.