Cikkek - Hálózat - bemutató írás saját webszerver

Internet játszik az életünkben nagy szerepet. Mi az e-mail, megtudja a legfrissebb információkat, hogy utolérjék a barátok ICQ-n keresztül. De ez együtt jár a szót interneten, a legtöbb ember az első helyen? Oldalakon. Sok az „internet” szót felidézni a kedvenc oldalak, és néhány (nem túl fejlett) azonosítják a WWW és az internet, bár az utóbbi sok más érdekes dolgot: az e-mail, IRC, p2p-hálózat, MUD, és így tovább. De a World Wide Web meghatározó szerepet tölt be.

Az alapja a WWW Hypertext Transfer Protocol protokoll. Azt kell mondanom, hogy a HTTP lehet használni nem csak a sebességváltó oldalak, hanem az átviteli minden mást. A rendszer segítségével a HTTP protokoll, lehet letölteni, például a közelmúltban megjelent film vagy friss mp3 :). A p2p-hálózatok HTTP-protokollt használjuk erre a célra.

Ebben a leckében lesz szó, hogyan kell írni egy egyszerű webszerver. Azt feltételezzük, hogy Ön ismeri az alapokat a winsock programozás és képesek létrehozni foglalatok és csatlakozzon semmit :).

Alapjai HTTP protokoll

HTTP Az ötlet nagyon egyszerű. A kliens küld egy kérést a szervernek, kezeli azt, és elküldi a megfelelő válasz. A válasz lehet kért fájl egy üzenet arról, hogy a fájl a szerveren, vagy van valami más. Est lekérdezés felépítése a következő:

<метод> - ilyen kéréseket. A két fő: GET és POST. Egymástól különböznek főleg módon történő továbbításának kiegészítő információkat küldött kérelemmel együtt. Ebben a bemutató, akkor csak azokat a GET módszer - amely funkcionálisan hasonlít a poszt, de egy kicsit könnyebb. A módszer POST elmondom a második része ez a bemutató, persze, ha van ilyen, akkor született :).

<\n> - két bájt 0Dh, 0Ah természetesen ismerős minden szerelő :).

Tehát az eljárás az általunk azonosított. Abban a pillanatban, egy kérés, hogy mi (ügyfél) kell küldeni a szerverre a következőképpen néz ki:

Most meg kell foglalkozni a fejléc mezőket. Segítségükkel a kliens elküldi további információt maga, vagy a természet a kérelmet. Például gyakran használt fejléc mező egy „User-Agent”. Opera, például küldi a következőket:

Felhasználó-Agent: Mozilla / 4.0 (compatible; MSIE 5.0; Windows 98) Opera 6,02 [en]

Itt van, hogyan néz ki most a vizsgálatot:

Meg kell jegyezni, hogy bár ezek és más fejléc mezők nagyon kívánatos, de szigorúan véve ezek nem kötelező, tehát lehet, hogy nem. Én is szeretnék felhívni a figyelmet arra a tényre, hogy az utolsó header file kövesse _dva_ <\n>, nem egy. Ez fontos.

Most megnézzük az összes fenti a szempontból a webszerver (valójában mi is fog írni egy webszerver, emlékszem.)). Ő vár rá nem kérés, feldolgozza azt, és elküldi a választ, hogy valahogy így néz ki:

Kézhezvételét követően a kérelmet, a szerver meg kell adni az ügyfélnek a válasz kódját (ez egy háromjegyű szám), valamint az ahhoz kapcsolódó üzenetet. Például, ha a kért dokumentumot találtak, az első sorban a válasz valami olyasmi lesz a következő:

Ha a válasz kódokat nehéz kódolni szabvány (200 azt jelenti, hogy a kérelmet a vonatkozó dokumentum / információ sikeresen feldolgozta és ad vissza), majd <сообщение> csak attól függ, a képzelet (természetesen abban az értelemben, hogy meg kell egyeznie <кодом_ответа>. Például ahelyett, hogy a „HTTP / 1.1 200 OK” tudjuk küldeni a „HTTP / 1.1 200 Akarod, megkapod” :).

Válaszként a szerver is lehet a fejléc mezőben. Ezek további információt nyújtanak a válasz és az adatok megy vele. Ezután fogom nyújtani a legfontosabb (nekünk).

Content-Type - Ez a fejezet meghatározza, milyen típusú információkat adni. A főbb típusok a szabványban meghatározott, és amit írsz ezen a területen függ az ügyfél viselkedését, amikor az adatok fogadását. Például ha elküldi a felhasználó böngészőjének html-fájlt, akkor meg kell adnia „text / html” adattípus, különben a böngésző megjeleníti a fájl rendesen, vagy nem jelennek meg, és felajánlja, hogy a felhasználó letölt.

Content-Length - Meghatározza az adat hosszát (ide nem értve a maga válaszoljon fejlécadat) bájt.

A fentiek alapján, a szerver válaszát így néz ki:

Ha azt akarjuk, hogy küldjön egy egyszerű html-fájlt, akkor csökkentheti a válasz a következő:

Ennek eredményeként megkapjuk az alábbiakat. A kliens kérést küld egy dokumentumot fekvő, például a gyökér a szerver:

A szerver fogadja a kérést, folyamatok és kiadja a gyökér oldalon:

„Web kiszolgáló”, aminek a forrása a fentiekből kitűnik, hogy ez nagyon primitív. Ő csak azt tudja, hogyan fogadja a kérést, és ellenőrzése nélkül, hogy a pontosság, csak, hogy az üdvözlő html-oldalt.

A http.asm minden, remélem, ez elég világos. Inicializáljuk az aljzatok, hozzon létre egy ablakot (amit majd később elmagyarázom), akkor írja be az üzenetet hurok és mielőtt bezárja az alkalmazást, hívja WSACleanup.

A legérdekesebb dolog van http_window.asm. Feldolgozásában a WM_CREATE üzenetet hozunk létre egy foglalat:

És akkor hívja a következő funkciókat:

Ez az, amit mond, ez a funkció Platform SDK:

[Top WSAAsynctSelect Funkció Leírás]

WSAAsyncSelect függvény azt mutatja, hogy a Windows üzeneteket küldeni kapcsolatos események egy adott aljzatba.

s - a socket kilincset a kapcsolódó eseményeket, hogy fog jelenteni.

HWND - kezelje az ablakhoz, amelyet meg kell küldeni ezeket az üzeneteket.

wMsg - Az üzenet lesz elküldve.

Levent - kicsit maszk, amely meghatározott események az érdeklődés.

Ha a hívás WSAAsyncSelect funkció sikeres, akkor a visszatérési érték nulla. Egyébként SOCKET_ERROR kerül vissza, és hibakód nyerhető hívja WSAGetLastError.

Vegye figyelembe, hogy miután WSAAsyncSelect küld egy üzenetet egy adott esemény kapcsolódó foglalat, amíg nem bizonyos műveleteket, új jelentések ugyanazon esemény, nem kap. Például, ha olyan üzenetet kap FD_ACCEPT (valaki megpróbálja zakonnektitsya neked), a jelentések többi próbálkozás a kapcsolat nem kap, amíg nem hívja fel a elfogadni funkciót.

Kérünk WM_SOCKET, meghatározott http.asm, mint egy üzenetet, hogy elküldi a Windowson, amikor lesz egy üzenetet érdekes számunkra. A szükséges információ lesz a wParam (socket fogantyú, amely kapcsolatban van az esemény), és lParam (alsó szó - esemény kód).

Valójában az adatok vonalak és választ ad arra, hogyan lehet az alkalmazás szerver (nem feltétlenül web). Ez teszi a hallgatni funkciót.

[Beginning hallgatni függvény leírása]

hallgatni socket funkció meghatározza az állam, ahol hallgat a port a bejövő kapcsolatokat.

s - a socket leíró

elmaradás - A legnagyobb számú bejövő kapcsolatokat.

Ha hívás közben nem voltak hibák, hallgatni nulla értékkel tér vissza. Egyébként SOCKET_ERROR értéket ad vissza, és egy hibaüzenet lesz elérhető WSAGetLastError funkciót.

Üzenet érkezett WM_SOCKET. Ez azt jelenti, hogy volt néhány érdekes számunkra egy olyan esemény társított hallgatási aljzatba.

Valaki megpróbál csatlakozni a web szerver. Hívásfogadás funkció lehetővé teszi a bejövő kapcsolatokat.

[Kezdete elfogadja a leírás]

A elfogadja a funkció lehetővé teszi a bejövő kapcsolat.

s - a socket leíró, amelyet korábban feltöltött a hallgatási állapotban a hallgatni funkciót. A tényleges kapcsolat létrejött keresztül csatlakozó visszajuttatott accept'om.

addrlen - Nem kötelező mutató kettős szó, amely tartalmazza addr hosszát.

Ha nem volt hiba, a fogadja vissza egy új socket leíró, és amelyen keresztül a kapcsolat fog bekövetkezni.

Egyébként INVALID_SOCKET, és a hibakód kerül vissza lesz elérhető WSAGetLastError funkciót.

Amennyiben az aljzat lezárták az ügyfél, akkor is közel az oldalán.

További információ a HTTP protokoll azt ajánlom, hogy olvassa el RFC 2068.

[C] Aquila / WASM.RU