先看一张图, 从这张图里, 能看到请求是如何从CLR
进入HttpRuntime
的.
一、AppManagerAppDomainFactory
看到这张图是从 AppManagerAppDomainFactory
开始的, 按照汤姆大叔博文中所说, 是在CLR初始化加载的时候, 来加载这个类的. 那么来看一下这个类吧.
使用Reflector
反编译搜索AppManagerAppDomainFactory
类, 可以看到(由于这个类并不多, 那么我先贴一个完整的出来吧):
[SecurityPermission(SecurityAction.LinkDemand, Unrestricted=true)]
public sealed class AppManagerAppDomainFactory : IAppManagerAppDomainFactory
{
// Fields
private ApplicationManager _appManager = ApplicationManager.GetApplicationManager();
// Methods
public AppManagerAppDomainFactory()
{
this._appManager.Open();
}
internal static string ConstructSimpleAppName(string virtPath)
{
if (virtPath.Length > 1)
{
return virtPath.Substring(1).ToLower(CultureInfo.InvariantCulture).Replace('/', '_');
}
if (!BuildManagerHost.InClientBuildManager && HostingEnvironment.IsDevelopmentEnvironment)
{
return "vs";
}
return "root";
}
[return: MarshalAs(UnmanagedType.Interface)]
public object Create(string appId, string appPath)
{
object obj2;
try
{
if (appPath[0] == '.')
{
FileInfo info = new FileInfo(appPath);
appPath = info.FullName;
}
if (!StringUtil.StringEndsWith(appPath, '\\'))
{
appPath = appPath + @"\";
}
ISAPIApplicationHost appHost = new ISAPIApplicationHost(appId, appPath, false);
ISAPIRuntime o = (ISAPIRuntime) this._appManager.CreateObjectInternal(appId, typeof(ISAPIRuntime), appHost, false, null);
o.StartProcessing();
obj2 = new ObjectHandle(o);
}
catch (Exception)
{
throw;
}
return obj2;
}
public void Stop()
{
this._appManager.Close();
}
}
至于这里详细的解说, 推荐去 MVC之前的那些事儿 去瞧瞧, 这里并不是我想表述的重点, 就不介绍了.
只要知道, 按照大叔的说法, 这里, 在CreateObjectInternal
方法中, 创建了AppDomain
, 创建了HostingEnvironment
等一些列操作.
后续所有的比如HttpRuntime, HttpContext
等, 都是依托于这个AppDomain
.
二、主题
经过各种我不知道的内部处理, 非托管代码开始正式调用 ISAPIRuntime
的 ProcessRequest
(后面简称为PR方法)了.
(ISPAIRuntime
继承了IISPAIRuntime
接口,该接口可以和COM进行交互,并且暴露了ProcessRequest
接口方法)
不要问我为什么会调用PR方法, 因为我也不知道, 但是真的是这个方法.
public sealed class ISAPIRuntime : MarshalByRefObject, IISAPIRuntime, IISAPIRuntime2, IRegisteredObject
{
// Fields
private static int _isThisAppDomainRemovedFromUnmanagedTable;
private const int WORKER_REQUEST_TYPE_IN_PROC = 0;
private const int WORKER_REQUEST_TYPE_IN_PROC_VERSION_2 = 2;
private const int WORKER_REQUEST_TYPE_OOP = 1;
// Methods
[SecurityPermission(SecurityAction.Demand, Unrestricted=true)]
public ISAPIRuntime();
[SecurityPermission(SecurityAction.LinkDemand, Unrestricted=true)]
public void DoGCCollect();
public override object InitializeLifetimeService();
[SecurityPermission(SecurityAction.LinkDemand, Unrestricted=true)]
public int ProcessRequest(IntPtr ecb, int iWRType);
internal static void RemoveThisAppDomainFromUnmanagedTable();
[SecurityPermission(SecurityAction.LinkDemand, Unrestricted=true)]
public void StartProcessing();
[SecurityPermission(SecurityAction.LinkDemand, Unrestricted=true)]
public void StopProcessing();
[TargetedPatchingOptOut("Performance critical to inline this type of method across NGen image boundaries")]
void IISAPIRuntime2.DoGCCollect();
[TargetedPatchingOptOut("Performance critical to inline this type of method across NGen image boundaries")]
int IISAPIRuntime2.ProcessRequest(IntPtr ecb, int iWRType);
[TargetedPatchingOptOut("Performance critical to inline this type of method across NGen image boundaries")]
void IISAPIRuntime2.StartProcessing();
[TargetedPatchingOptOut("Performance critical to inline this type of method across NGen image boundaries")]
void IISAPIRuntime2.StopProcessing();
void IRegisteredObject.Stop(bool immediate);
}
这里有个方法, 看名字就觉得好熟悉, 好吧, 点进去看一下:
GC 一个叫垃圾回收的东东, 好熟悉的名字. OK, 这不是重点, 接下来继续.
[SecurityPermission(SecurityAction.LinkDemand, Unrestricted=true)]
public int ProcessRequest(IntPtr ecb, int iWRType)
{
IntPtr zero = IntPtr.Zero;
if (iWRType == 2)
{
zero = ecb;
ecb = UnsafeNativeMethods.GetEcb(zero);
}
ISAPIWorkerRequest wr = null;
try
{
bool useOOP = iWRType == 1;
wr = ISAPIWorkerRequest.CreateWorkerRequest(ecb, useOOP);
wr.Initialize();
string appPathTranslated = wr.GetAppPathTranslated();
string appDomainAppPathInternal = HttpRuntime.AppDomainAppPathInternal;
if ((appDomainAppPathInternal == null) || StringUtil.EqualsIgnoreCase(appPathTranslated, appDomainAppPathInternal))
{
HttpRuntime.ProcessRequestNoDemand(wr);
return 0;
}
HttpRuntime.ShutdownAppDomain(ApplicationShutdownReason.PhysicalApplicationPathChanged,
SR.GetString("Hosting_Phys_Path_Changed",
new object[] { appDomainAppPathInternal, appPathTranslated }));
return 1;
}
catch (Exception exception)
{
try
{
WebBaseEvent.RaiseRuntimeError(exception, this);
}
catch
{
}
if ((wr == null) || !(wr.Ecb == IntPtr.Zero))
{
throw;
}
if (zero != IntPtr.Zero)
{
UnsafeNativeMethods.SetDoneWithSessionCalled(zero);
}
if (exception is ThreadAbortException)
{
Thread.ResetAbort();
}
return 0;
}
}
第一个注意到的就是该方法的IntPtr
类型的参数ecb,ecb是啥?ecb是一个非托管的指针,全称是Execution Control Block
,在整个Http Request Processing过程中起着非常重要的作用,我们现在来简单介绍一个ECB
。
非托管环境ISAPI
对ISAPIRuntime
的调用,需要传递一些必须的数据,比如ISAPIRuntime
要获取Server Variable
的数据,获取通过Post Mehod
传回Server的数据;以及最终将Response
的内容返回给非托管环境ISAPI,然后呈现给Client用户。一般地ISAPIRuntime
不能直接调用ISAPI,所以这里就通过一个对象指针实现对其的调用,这个对象就是ECB,ECB实现了对非托管环境ISAPI的访问。
还有一点特别需要强调的是,ISAPI
对ISAPIRutime
的调用是异步的,也就是说ISAPI调用ISAPIRutime之后立即返回。这主要是出于Performance
和Responsibility
考虑的,因为ASP.NET Application天生就是一个多线程的应用,为了具有更好的响应能力,异步操作是最有效的解决方式。但是这里就会有一个问题,我们知道我们对ASP.NET 资源的调用本质上是一个Request/Response的Message Exchange Pattern,异步调用往往意味着ISAPI将Request
传递给ISAPIRuntime
,将不能得到ISAPIRuntime
最终生成的Response
,这显然是不能接受的。而ECB解决了这个问题,ISAPI
在调用ISAPIRutime
的ProcessRequest
方法时会将自己对应的ECB的指针传给它,ISAPIRutime
不但可以将最终生成的Response
返回给ISAPI
,还能通过ECB
调用ISAPI
获得一些所需的数据。
CreateWorkerRequest
这个方法还是要看一下的, 有收获哦.
internal static ISAPIWorkerRequest CreateWorkerRequest(IntPtr ecb, bool useOOP)
{
if (useOOP)
{
EtwTrace.TraceEnableCheck(EtwTraceConfigType.DOWNLEVEL, IntPtr.Zero);
if (EtwTrace.IsTraceEnabled(5, 1))
{
EtwTrace.Trace(EtwTraceType.ETW_TYPE_APPDOMAIN_ENTER, ecb, Thread.GetDomain().FriendlyName, null, false);
}
return new ISAPIWorkerRequestOutOfProc(ecb);
}
int num = UnsafeNativeMethods.EcbGetVersion(ecb) >> 0x10;
if (num >= 7)
{
EtwTrace.TraceEnableCheck(EtwTraceConfigType.IIS7_ISAPI, ecb);
}
else
{
EtwTrace.TraceEnableCheck(EtwTraceConfigType.DOWNLEVEL, IntPtr.Zero);
}
if (EtwTrace.IsTraceEnabled(5, 1))
{
EtwTrace.Trace(EtwTraceType.ETW_TYPE_APPDOMAIN_ENTER, ecb, Thread.GetDomain().FriendlyName, null, true);
}
if (num >= 7)
{
return new ISAPIWorkerRequestInProcForIIS7(ecb);
}
if (num == 6)
{
return new ISAPIWorkerRequestInProcForIIS6(ecb);
}
return new ISAPIWorkerRequestInProc(ecb);
}
通过判断ecb和type类型的具体内容,来决定创建什么类型的WorkerRequest
(上述类型的ISPAIWorkerRequest
都继承于HttpWorkerRequest
),上面的代码可以看出对不同版本的IIS进行了不同的包装,通过其Initialize方法来初始化一些基本的信息(比如:contentType, querystring的长度,filepath等相关信息)。
ProcessRequestNoDemand
这个方法, 是真正进入ASP.NET Runtime Pipeline的唯一入口, 传递的参数是上面屏蔽了差异化以后的WorkerRequest
对象实例.来看一下这个方法
internal static void ProcessRequestNoDemand(HttpWorkerRequest wr)
{
RequestQueue queue = _theRuntime._requestQueue;
wr.UpdateInitialCounters();
if (queue != null)
{
wr = queue.GetRequestToExecute(wr);
}
if (wr != null)
{
CalculateWaitTimeAndUpdatePerfCounter(wr);
wr.ResetStartTime();
ProcessRequestNow(wr);
}
}
Ok, 接下来, 继续看, PRNow方法, 其实内部调用的是 HttpRuntime
的 ProcessRequestInternal
方法.
private void ProcessRequestInternal(HttpWorkerRequest wr)
{
Interlocked.Increment(ref this._activeRequestCount);
if (this._disposingHttpRuntime)
{
try
{
wr.SendStatus(0x1f7, "Server Too Busy");
wr.SendKnownResponseHeader(12, "text/html; charset=utf-8");
byte[] bytes = Encoding.ASCII.GetBytes("<html><body>Server Too Busy</body></html>");
wr.SendResponseFromMemory(bytes, bytes.Length);
wr.FlushResponse(true);
wr.EndOfRequest();
}
finally
{
Interlocked.Decrement(ref this._activeRequestCount);
}
}
else
{
HttpContext context;
try
{
context = new HttpContext(wr, false);
}
catch
{
try
{
wr.SendStatus(400, "Bad Request");
wr.SendKnownResponseHeader(12, "text/html; charset=utf-8");
byte[] data = Encoding.ASCII.GetBytes("<html><body>Bad Request</body></html>");
wr.SendResponseFromMemory(data, data.Length);
wr.FlushResponse(true);
wr.EndOfRequest();
return;
}
finally
{
Interlocked.Decrement(ref this._activeRequestCount);
}
}
wr.SetEndOfSendNotification(this._asyncEndOfSendCallback, context);
HostingEnvironment.IncrementBusyCount();
try
{
try
{
this.EnsureFirstRequestInit(context);
}
catch
{
if (!context.Request.IsDebuggingRequest)
{
throw;
}
}
context.Response.InitResponseWriter();
IHttpHandler applicationInstance = HttpApplicationFactory.GetApplicationInstance(context);
if (applicationInstance == null)
{
throw new HttpException(SR.GetString("Unable_create_app_object"));
}
if (EtwTrace.IsTraceEnabled(5, 1))
{
EtwTrace.Trace(EtwTraceType.ETW_TYPE_START_HANDLER, context.WorkerRequest,
applicationInstance.GetType().FullName, "Start");
}
if (applicationInstance is IHttpAsyncHandler) //异步处理
{
IHttpAsyncHandler handler2 = (IHttpAsyncHandler) applicationInstance;
context.AsyncAppHandler = handler2;
handler2.BeginProcessRequest(context, this._handlerCompletionCallback, context);
}
else //同步处理
{
applicationInstance.ProcessRequest(context);
this.FinishRequest(context.WorkerRequest, context, null);
}
}
catch (Exception exception)
{
context.Response.InitResponseWriter();
this.FinishRequest(wr, context, exception);
}
}
}
最让人开心的, 可能就是看到, 在这个方法中创建了 HttpContext
对象和 HttpApplication
对象.
接下来, 分别看一下这两个对象的创建.
1). HttpContext
internal HttpContext(HttpWorkerRequest wr, bool initResponseWriter)
{
this._timeoutStartTimeUtcTicks = -1L;
this._timeoutTicks = -1L;
this._threadAbortOnTimeout = true;
this.ThreadContextId = new object();
this._wr = wr;
this.Init(new HttpRequest(wr, this), new HttpResponse(wr, this));
if (initResponseWriter)
{
this._response.InitResponseWriter();
}
PerfCounters.IncrementCounter(AppPerfCounter.REQUESTS_EXECUTING);
}
我们又看到了2个惊喜的代码,HttpRequest
和HttpResponse
的实例化,通过对WorkerRequest
和对HttpContext
对象this参数的传递,将获取各自需要的信息
2). HttpApplication
这个对象的创建, 是后面那句标红的部分.
IHttpHandler applicationInstance = HttpApplicationFactory.GetApplicationInstance(context);
通过HttpApplicationFactory
的GetApplicationInstance
静态方法,获取我们熟悉的HttpApplication
对象实例,由于HttpApplication
对象是继承IHttpAsyncHandler
,而IHttpAsyncHandler
又继承于IHttpHandler
,所以上面app的类型是IHttpHandler
是没有错的。继续看后面的if (app is IHttpAsyncHandler
)代码,就知道了app
肯定走这里的分支,然后执行调用asyncHandler.BeginProcessRequest
方法了。
至此,HttpRuntime
已经正式发挥其无可替代的作用了,也正式通过此对象正式进入了HttpApplication
对象的创建以及大家熟知的HttpApplication
以后的生命周期了。