2010-12-09 6 views
2

Angenommen, ich betreibe eine Website (auf IIS7) für Anfragen auf Port 8000. Jetzt enthält diese Website nur statischen Inhalt (dh HTML-Dateien). Wenn ich also zur URL http://localhost:8000 blicke, zeigt der Browser die Standard-HTML-Seite der Website an. Aber wenn ich auch einen Self-Hosting-WCF-Dienst leite, der auf Anfragen unter URL http://localhost: 8000 hört (dieser WCF-Dienst wird nicht von IIS gehostet), zeigt der Browser stattdessen Daten über den WCF-Dienst an:IIS7 und WCF Verwirrung

a) Don ' Ich weiß viel über TCP/IP, aber soweit ich weiß, kann immer nur eine Anwendung bestimmte IP und Ports abhören, aber sowohl die Website als auch der WCF-Dienst können hier die gleiche IP-Adresse und Portnummer abhören. Wie ist das möglich?

b) Wenn ich eine lokale URL (zB http://localhost:8000) in den Browser eingebe, fragt der Browser keine Seite über IIS ab? Wenn ja, warum werden dann Details zu einem WCF-Service und nicht zur Standardseite einer Website angezeigt? Dieser WCF-Dienst wird nicht einmal von IIS gehostet.

Danke

Antwort

2

Es ist wahr, dass in der Regel nur ein einziger Prozess auf einem bestimmten Sockel hören kann. Es wurde jedoch in Windows gearbeitet, um dies speziell für HTTP-Listener zu unterstützen, insbesondere mit der Einführung von HTTP.SYS in IIS 6.0.

Im Grunde ist es der Kernel, der tatsächlich auf die HTTP-Anfragen wartet, und dann wird die Verbindung zu einem von mehreren Listener-Prozessen in user-land geroutet.

Die WCF-HTTP-Listener für das Selbsthosting sind ebenfalls auf HTTP.sys angewiesen, sodass sie bei Bedarf Ports mit IIS teilen können (oder über mehrere selbst gehostete WCF-Dienste hinweg).

+0

A - Aber warum liefert Http.Sys eine Anfrage an den WCF-Dienst und nicht an IIS? B - Also "sogar" lokale "Browser (die sich also auf demselben Rechner wie IIS befinden) nicht direkt mit IIS in Verbindung, sondern indirekt über Http.sys? – user437291

+2

Niemand kontaktiert IIS direkt; noch entscheiden die Anwendungen (lokal oder nicht), wen sie kontaktieren sollen. Der abhörende Socket selbst wird vom Windows-Kernel im Namen aller Prozesse überwacht, die sich bei HTTP.SYS registriert haben. Dann schaut es sich den Pfad an, der in der HTTP-Anfrage spezifiziert wurde und entscheidet, wohin die Anfrage weitergeleitet werden soll (welcher Hörprozess). – tomasr

+2

Ich hätte hinzugefügt, dass Teil des aktuellen Problems ist, dass WCF und IIS die gleiche Basisadresse verwenden, was es schwierig macht zu entscheiden, wer die Anfrage bearbeiten soll. Sie können jedoch Pfade in der Anfrage verwenden, um es herauszufinden (z. B. registrieren Sie Ihren selbst gehosteten WCF-Prozess unter http: // *: 8000/path/anstelle von http: // *: 8000 /) – tomasr