接上文,容器內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)的請求。這應該是一篇偏冷門的知識點,可是結合咱們的實際和理論,相信能給讀者的知識結構添磚加瓦。