接上文,容器内web程序通常会绑定到http://0.0.0.0:{某监听端口}
或http://+:{某监听端口}
,以确保使用容器IP能够访问到web应用。web
正如咱们在ASP.NET Core官方镜像显示的,ASP.NET Core程序在容器内80端口监听请求算法
This image sets the ASPNETCORE_URLS environment variable to http://+:80 which means that if you have not explicity set a URL in your application, via app.UseUrl in your Program.cs for example, then your application will be listening on port 80 inside the container.数据库
http://+:80是什么鬼? 请求为何会被路由到监听http://+:80地址的web服务器?windows
这里涉及一个鲜为人知的概念:UrlPrefix服务器
UrlPrefix是统一资源定位符Url的前缀部分:scheme://host:port/relativeURIapp
- "https://www.adatum.com:80/vroot/"
- "https://adatum.com:443/secure/database/"
- "http://+:80/vroot/"
web程序启动后,根据监听地址UrlPrefix中的主机元素,会向系统组件Http Server API注册不一样的路由桶,由Http Server API将接收的请求时路由到合适的web程序。ide
容器内web程序监听http://+:80地址,+ 是强通配符,意味着web程序在容器(轻量级虚拟机)内以任意主机名监听80端口的请求。url
监听地址UrlPrefix 中的主机元素有四种形态:spa
匹配全部可能的主机名
,这时的UrlPrefix属于强通配符类别。传入请求的host标头相匹配
, 明确的主机名对于多站点颇有用,这些Web站点根据请求所指向的站点传递不一样的内容。Http Server API维护了一张路由表,
决定哪个应用程序接收传入请求
,这张路由表是从预留数据库中构建的,当新产生一个注册项或预留项,将会被放进与特定主机元素
相关的路由桶code
当多个web程序监听的UrlPrefix有重叠时,Http Server API会根据注册的1-->4路由桶依次匹配,路由桶中UrlPrefix的相对URI部分中最长的匹配(假设URL的主机,端口和方案部分彻底匹配)是最佳匹配。 在路由桶中找到匹配项后,路由算法将中止搜索并跳过全部优先级较低的存储桶。
例以下面的注册项:
注册项: https://+:80/vroot/ is registered by app1
注册项: https://adatum.com:80/ is registered by app2
注册项: https://*:80/ is registered by app3
对https://adatum.com:80/vroot/subdir/file.htm/的传入请求路由给 app1,
对https://adatum.com:80/default.htm/的传入请求路由给 app2,
对https://otheradatum.com:80/file.htm/的传入请求路由给 app3
将请求路由到web程序
的机制+强通配符
表示 忽略请求主机名和请求的方式,能够认为是囫囵吞枣的接收知足(scheme、port、relativeUrl)的请求。这应该是一篇偏冷门的知识点,可是结合咱们的实际和理论,相信能给读者的知识结构添砖加瓦。