引言

接上文，容器內(nèi)web程序一般會(huì)綁定到http://0.0.0.0:{某監(jiān)聽端口}或http://+:{某監(jiān)聽端口}，以確保使用容器IP可以訪問到web應(yīng)用。

正如我們?cè)贏SP.NET Core官方鏡像顯示的，ASP.NET Core程序在容器內(nèi)80端口監(jiān)聽請(qǐng)求

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是什么鬼？請(qǐng)求為什么會(huì)被路由到監(jiān)聽http://+:80地址的web服務(wù)器？

UrlPrefix

這里涉及一個(gè)不為人知的概念：UrlPrefix

UrlPrefix是統(tǒng)一資源定位符Url的前綴部分：scheme://host:port/relativeURI

• "https://www.adatum.com:80/vroot/"

• "https://adatum.com:443/secure/database/"

• "http://+:80/vroot/"

web程序啟動(dòng)后，根據(jù)監(jiān)聽地址UrlPrefix中的主機(jī)元素，會(huì)向系統(tǒng)組件Http Server API注冊(cè)不同的路由桶，由Http Server API將接收的請(qǐng)求路由到合適的web程序。

容器內(nèi)web程序監(jiān)聽http://+:80地址，+ 是強(qiáng)通配符，意味著web程序在容器（輕量級(jí)虛擬機(jī)）內(nèi)以任意主機(jī)名監(jiān)聽80端口的請(qǐng)求。

監(jiān)聽地址UrlPrefix 中的主機(jī)元素有四種形態(tài)：

強(qiáng)通配符 ( + )
當(dāng)主機(jī)元素是一個(gè)加號(hào)（+），UrlPrefix匹配所有可能的主機(jī)名，這時(shí)的UrlPrefix屬于強(qiáng)通配符類別。
強(qiáng)通配符在如下場(chǎng)景下有用：當(dāng)web程序要忽略請(qǐng)求到達(dá)的方式或忽略請(qǐng)求host標(biāo)頭中指定的站點(diǎn)時(shí)，web服務(wù)器監(jiān)聽地址的主機(jī)元素可設(shè)置為強(qiáng)通配符+

顯式主機(jī)名
當(dāng)主機(jī)元素是完全限定的域名，web服務(wù)器的主機(jī)元素直接與傳入請(qǐng)求的host標(biāo)頭相匹配， 明確的主機(jī)名對(duì)于多站點(diǎn)很有用，這些Web站點(diǎn)根據(jù)請(qǐng)求所指向的站點(diǎn)傳遞不同的內(nèi)容。

綁定IP的弱通配符
主機(jī)元素為IP地址，這種類型的UrlPrefix匹配尚未與以上強(qiáng)通配符或顯式主機(jī)名匹配的任意IP地址主機(jī)名

弱通配符 ( * )
當(dāng)星號(hào)*作為主機(jī)元素出現(xiàn)時(shí)， 這種類型的UrlPrefix將會(huì)匹配尚未與以上強(qiáng)通配符、顯式或IP綁定的弱通配符匹配的任意主機(jī)名， 此主機(jī)元素可以用作默認(rèn)的catch-all，也可以用于指定URL名稱空間的較大部分，而不必使用許多UrlPrefixes

Http Server API維護(hù)了一張路由表，決定哪一個(gè)應(yīng)用程序接收傳入請(qǐng)求，這張路由表是從預(yù)留數(shù)據(jù)庫中構(gòu)建的,當(dāng)新產(chǎn)生一個(gè)注冊(cè)項(xiàng)或預(yù)留項(xiàng)，將會(huì)被放進(jìn)與特定主機(jī)元素相關(guān)的路由桶

路由桶優(yōu)先級(jí)

當(dāng)多個(gè)web程序監(jiān)聽的UrlPrefix有重疊時(shí)，Http Server API會(huì)根據(jù)注冊(cè)的1-->4路由桶依次匹配，路由桶中UrlPrefix的相對(duì)URI部分中最長(zhǎng)的匹配（假設(shè)URL的主機(jī)，端口和方案部分完全匹配）是最佳匹配。在路由桶中找到匹配項(xiàng)后，路由算法將停止搜索并跳過所有優(yōu)先級(jí)較低的存儲(chǔ)桶。

例如下面的注冊(cè)項(xiàng)：

• 注冊(cè)項(xiàng): https://+:80/vroot/ is registered by app1

• 注冊(cè)項(xiàng): https://adatum.com:80/ is registered by app2

• 注冊(cè)項(xiàng): https://*:80/ is registered by app3

對(duì)https://adatum.com:80/vroot/subdir/file.htm/的傳入請(qǐng)求路由給 app1，
對(duì)https://adatum.com:80/default.htm/的傳入請(qǐng)求路由給 app2，
對(duì)https://otheradatum.com:80/file.htm/的傳入請(qǐng)求路由給 app3

總結(jié)

• HTTP Sever API 提供了將請(qǐng)求路由到web程序的機(jī)制

• 應(yīng)用程序監(jiān)聽地址UrlPrefix的主機(jī)元素決定了路由策略，其中+強(qiáng)通配符 表示忽略請(qǐng)求主機(jī)名和請(qǐng)求的方式，可以認(rèn)為是囫圇吞棗的接收滿足（scheme、port、relativeUrl）的請(qǐng)求。

• 多個(gè)web程序監(jiān)聽的UrlPrefix有重疊時(shí)，Http Server API根據(jù)host元素形成的路由桶有優(yōu)先級(jí)

這應(yīng)該是一篇很冷門的知識(shí)點(diǎn)，但是結(jié)合我們的實(shí)際和理論，相信能給讀者的知識(shí)結(jié)構(gòu)添磚加瓦。

• https://docs.microsoft.com/zh-cn/windows/win32/http/urlprefix-strings?redirectedfrom=MSDN

• https://docs.microsoft.com/en-us/windows/win32/http/routing-incoming-requests

• https://stackoverflow.com/questions/7007929/what-does-a-plus-sign-mean-in-a-http-url-http-80

推薦閱讀

●?這么香的Chrome插件，你都安裝了嗎？

●?一文掌握Cookies前世今生

●?ASP.NET Core跨平臺(tái)技術(shù)內(nèi)幕

●?TPL Dataflow組件應(yīng)對(duì)高并發(fā),低延遲要求

●?實(shí)例解讀Docker Swarm

●?基于docker-compose的Gitlab CI/CD實(shí)踐&排坑指南

總結(jié)

以上是生活随笔為你收集整理的Http Server API路由请求到web程序的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。