Wat is het verschil tussen http-verzoek en het schrijven van HTTP-aanvraagtekst naar tcp/ip-socket op poort 80

Kan iemand het verschil tussen de HTTP-aanvraag en de verwerking en socketverzoeken op de 80-poort verklaren? Zoals ik heb begrepen, luistert de HTTP-server naar de 80-poort en wanneer iemand een HTTP-verzoek op deze poort verzendt, verwerkt de server dit. Dus wanneer we socketlistener op poort 80 plaatsen en dan een HTML-bericht schrijven - betekent dit dat we gewoon HTTP-verzoek verzenden? Maar zoals Fiddler zei - het is fout. Wat is het verschil op pakketniveau? Of een ander lager dan presentatie -niveau tussen HTTP-aanvraag en HTTP-geformuleerd schrijven naar socket? Bedankt.

3

1 antwoord

Allereerst is poort 80 de standaardpoort voor HTTP, dit is niet vereist. U kunt HTTP-servers ook op andere poorten laten luisteren.

Wat betreft het verschil tussen "gewone" HTTP-verzoeken en degene die u zelf boven een socket maakt - er is geen verschil. De "gewone" HTTP-verzoeken waarnaar u verwijst (bijvoorbeeld gemaakt door een webbrowser) worden ook over sockets geïmplementeerd, net zoals u het zelf handmatig zou doen. En hetzelfde geldt voor de server. De implementatie van de HTTP-server luistert naar binnenkomende socketverbindingen en parseert de gegevens die daar passeren, net zoals u dat zou doen.

Zolang u uw socket-geldig HTTP-protocol verzendt (volgens de RFC), mag er geen verschil zijn in het pakketniveau (als de onderste netwerkstack identiek is).

Houd er rekening mee dat de socketlaag slechts de laag is die de HTTP-gegevens altijd passeren. Het maakt niet echt uit wie de gegevens daar heeft geplaatst, het komt net van de andere kant op dezelfde manier als waarin het werd geplaatst.

Houd er rekening mee dat u enige vrijheid heeft bij het zelf implementeren van een HTTP. Er zijn veel optionele velden en de volgorde van de headers doet er niet toe. Het is dus mogelijk dat twee verschillende HTTP-implementaties verschillend zijn op het pakketniveau, maar zich in principe hetzelfde gedragen.

De beste manier om echt te zien wat er op het niveau van het pakket gebeurt, is door een sniffer-achtige snoer of packetzer te gebruiken. Een sniffer slaat de pakketten van het netwerk op en toont hun inhoud. Dus als u verschillende HTTP-implementaties (van verschillende browsers) en uw eigen socketimplementatie opneemt, kunt u de vereiste wijzigingen aanbrengen om ze op het pakketniveau identiek te maken.

6
toegevoegd
ja .. goed gevormd schrijven dat doe je in de socket is perfect HTTP
toegevoegd de auteur talkol, de bron
Bedankt voor de reactie en voor het wijzen op gereedschappen, om ze te proberen. U zei wat ik eerder bedoelde - dat goed geformuleerde write-in socket http is. Ik schrijf niet mijn eigen server =) Ik werk gewoon met sommige api die via sockets op de 80-poort zijn geleverd en schrijf tekst naar socket in een antwoord op een http-geformuleerd verzoek. Ik maak het met het object C# TcpClient. Maar ik begin gewoon door te werken met een ingepakt en verfraaid HttpWebRequest-object - retourneert een fout. En bovendien - schrijven met TcpClient wordt niet bijgehouden door violist, die alle http-verzoeken bijhoudt. Dus nogmaals bedankt voor tools zal ze uitproberen.
toegevoegd de auteur Daniil Grudzinskiy, de bron
ik heb wat bewerkingen in vorige post, nog niet bekend met stackowerflow
toegevoegd de auteur Daniil Grudzinskiy, de bron
Begrepen! Wireshurk regels! Jongens die een soapdienst hebben geschreven, voegen een dummy-symbool toe vóór het bericht. De slechtste zeep in mijn leven.
toegevoegd de auteur Daniil Grudzinskiy, de bron