背景
網際網路業務的爆炸式增長和需求多樣化，給傳統的網際網路結構帶來了許多挑戰，使其僵化現象日趨明顯。若提出一種全新的網際網路架構來解決這一問題，將導致現有網際網路結構、路由器軟體和硬體的根本性變化;加之網際網路的“多供應商”特性，需要多個網際網路業務提供商(Internet Service Providers, ISPs)對網路架構變化的共同認可。這些因素將會使得全新的網際網路架構的出現面臨重重阻力。這時網路虛擬化(Network Virtualization, NV)技術就應運而生了。
在網路虛擬化環境(Network Virtualization Environment, NVE)中，多個虛擬網路(Virtual Network, VN)可能被映射到同一個底層物理網路上，以實現底層物理網路資源的透明共享。而網路虛擬化中面臨的一個重要挑戰是如何有效的實現虛擬網路(VN)到基礎設施網路(Infrastructure)的映射。高效的虛擬網路映射策略可以提高底層物理網路資源的效用，進而提高InP的收益；同時也可以有效的降低用戶的運維成本。因此，如何有效的實現虛擬網路的映射，是當前網路虛擬化領域中的一個研究重點。
虛擬網路的映射
(Virtual Network Mapping, VNM)。由於虛擬網路的一個虛擬節點可以被映射到底層物理網路的任意一個物理節點，且一條虛擬鏈路可能會對應於底層物理網路的多條物理鏈路，所以對任意給定的虛擬網路而言就存在多種向物理網路映射的方案。為了最大化共存的虛擬網路的數目，如何把業務提供商的虛擬網路請求映射到物理網路上，就顯得非常重要。然而帶節點和鏈路約束的虛擬網路( VN)請求的最優映射問題是NP一難問題[[53]，即便在事先給定VN請求的情況下也是如此。因此，大多數的研究中，採用啟發式算法來求解虛擬網路的最佳化映射問題。
現有的啟發式解決方案可以分為兩大類：
•離線VN映射問題解決方案
•線上VN映射問題解決方案。
在離線問題中，所有業務提供商的VN請求是事先己知的。致力於底層物理網路負載平衡的算法，該算法中假定網路資源量沒有限制。Lu and Turne:提供了一種單VN請求的映射算法，該算法的目標是最小化映射代價。給出一種分散式虛擬網路映射的算法，將VN分解成若干個星形的子虛擬網路(Sub-VN)，再將每個Sub-VN映射到底層物理網路上。則給出了基於多商品流(Multi-Commodity Flow MCF)思想的離線虛擬網路映射算法。關於線上虛擬網路映射問題研究中，Fan and Ammar針對運行於層疊網路上的有動態通信需求的業務，提出了動態拓撲重構的解決方案。Zhu和Ammar 針對這種問題的解決辦法是:定期計算所有的映射。然而這兩種線上問題算法都是假定基礎設施的資源是無限的。假定底層網路支持路徑拆分(分流)，並且引入路徑遷移機制定期重最佳化基礎設施提供商的資源利用率，給出用於最佳化特定拓撲映射的模組化算法。
虛擬網路映射面臨的挑戰
用戶的虛擬網路(VN)請求由虛擬節點集合和虛擬鏈路集合構成;每個虛擬節點和虛擬鏈路分別需要一定量的伺服器資源(如CPU、記憶體、磁碟等)和鏈路頻寬資源。虛擬網路的映射的本質就是尋求一個底層基礎設施網路的子網路來為虛擬網路請求提供所需的資源。因此，虛擬網路的映射工作包括兩部分內容:1),虛擬節點的映射，即將虛擬節點映射到物理伺服器上，並為其分配所需的伺服器資源、虛擬鏈路的映射，即將虛擬鏈路映射到底層基礎設施網路中的物理路徑上，並為其分配鏈路資源。考慮到物理伺服器的負載均衡以及降低失效影響的風險，來自於同一個虛擬網路的虛擬虛擬節點按一對一的原則映射到物理伺服器上(因為虛擬網路的設計己經考慮了用戶的計算任務和套用的拆分，所以在虛擬節點映射時不再考慮虛擬節點的拆分映射);而虛擬鏈路的映射則可能是一對多的映射，即一條虛擬鏈路對應的物理路徑可能由多條物理鏈路構成，更為複雜的是如果某條虛擬鏈路允許分流，則該虛擬鏈路則會被映射到多條物理路徑上。
在網路虛擬化環境(NVE)中，由於是多個虛擬網路(VN)共享同一個底層基礎設施網路的資源(伺服器資源和通信資源)，高效的VN映射就顯得非常必要了。從底層基礎設施網路提供商的角度來看，高效的VN映射策略能提高底層網路資源的效用、增加收益。用戶同樣希望高效的VN映射，因為它可以降低VN映射成本、易於獲得高QoS的服務。為了實現基礎設施網路提供商和用戶間的雙贏，許多研究人員進行了大量的關於VN映射的研究工作。然而，如何實現VN請求的最優映射，如最小化VN的映射成本或者最大化InP的收益，是一個NP一難問題，其求解複雜度極高。這也是實現最最佳化的VN映射時所面臨的主要難題。
@RequestMapping映射請求的使用
Spring MVC 使用@RequestMapping註解為控制器指定可以處理哪些 URL 請求，在控制器的類定義及方法定義處都可標註。
@RequestMapping
•類定義處：提供初步的請求映射信息。相當於當前 WEB 套用的根目錄
•方法處：提供進一步的細分映射信息。相對於類定義處的 URL。
•若類定義處未標註@RequestMapping，則方法處標記的 URL 相當於當前 WEB 套用的根目錄
•若類定義處標註@RequestMapping，則方法處標記的 URL 相對於類定義處的@RequestMapping而言的！
DispatcherServlet 截獲請求後，就通過控制器上@RequestMapping提供的映射信息確定請求所對應的處理方法。
映射請求參數、請求方法或請求頭
@RequestMapping除了可以使用請求 URL 映射請求外，還可以使用請求方法、請求參數及請求頭映射請求
@RequestMapping的 value、method、params 及 heads 分別表示請求 URL、請求方法、請求參數及請求頭的映射條件，他們之間是與的關係，聯合使用多個條件可讓請求映射更加精確化。
（1）params 和 headers支持簡單的表達式：
•param1: 表示請求必須包含名為 param1 的請求參數
•!param1: 表示請求不能包含名為 param1 的請求參數
•param1 != value1: 表示請求包含名為 param1 的請求參數，但其值 不能為 value1
•{“param1=value1”, “param2”}: 請求必須包含名為 param1 和param2 的兩個請求參數，且 param1 參數的值必須為 value1!
| @RequestMapping(value="/helloParams",params={"username","pwd!=123456"}) public String helloParams(){ return "success"; } |
表示請求URL中必須包含username參數，pwd可不包含，若包含pwd，則值不能為123456。
（2）Ant風格的請求URL
Ant 風格資源地址支持 3 種匹配符：
•?：匹配檔案名稱中的一個字元
•*：匹配檔案名稱中的任意多個任意字元[0個字元除外！]
•**：** 匹配多層路徑
例如：
•/user/*/createUser: 匹配
•/user/aaa/createUser、/user/bbb/createUser 等 URL
•/user/**/createUser: 匹配
•/user/createUser、/user/aaa/bbb/createUser 等 URL
•/user/createUser??: 匹配
•/user/createUseraa、/user/createUserbb 等 URL
（3）@PathVariable映射 URL 綁定的占位符
帶占位符的 URL 是 Spring3.0 新增的功能，該功能在 SpringMVC 向 REST 目標挺進發展過程中具有里程碑的意義
通過 @PathVariable 可以將 URL 中占位符參數綁定到控制器處理方法的入參中：
URL 中的 {xxx} 占位符可以通過 @PathVariable("xxx") 綁定到操作方法的入參中,需要注意的是：該註解的value屬性值要與占位符保持一致。
| @RequestMapping(value="/helloPathVariable/{id}") public String helloPathVariable(@PathVariable(value="id") Integer id) throws IOException{ System.out.println("id="+id); return "success"; } |
（4）method=RequestMethod.GET/POST/PUT/DELETE，可以實現REST請求風格的URL
（5） @RequestParam
@RequestParam可以接收請求的參數，相當於Servlet的getParameter()方法！
注意：要把@RequestParam和@PathVariable區分開：
三個默認屬性：
•value:這個欄位要與請求參數的name屬性值一致！
•required:布爾值，默認是true,當指定為false的時候，說明這個參數不是必須的，可以不帶!
•defaultValue：在我們不傳值的時候，默認使用defaultValue的值，傳遞參數的時候，使用我們傳遞的參數值！
| //獲取請求參數信息 @RequestMapping(value="/helloReqParam") public String helloReqParam(@RequestParam(value="username",required=false) String username){ System.out.println("username-------"+username); return SUCCESS; } |
（6） @RequestHeader
@RequestHeader:獲取請求頭信息，默認屬性：
•value:這個欄位要與請求參數的name屬性值一致！
•required:布爾值，默認是true,當指定為false的時候，說明這個參數不是必須的，可以不帶!
•defaultValue：在我們不傳值的時候，默認使用defaultValue的值，傳遞參數的時候，使用我們傳遞的參數值！
Servlet規範對映射請求的描述
在收到客戶端請求時，web 容器確定轉發到哪一個Web套用。選擇的Web套用必須具有最長的上下文路徑匹配請求URL的開始。當映射到Servlet時，URL匹配的一部分是上下文。Web 容器接下來必須用下面描述的路徑匹配步驟找出servlet來處理請求。用於映射到Servlet的路徑是請求對象的請求URL減去上下文和路徑參數部分。下面的URL路徑映射規則按順序使用。使用第一個匹配成功的且不會進一步嘗試匹配：
容器將嘗試找到一個請求路逕到servlet路徑的精確匹配。成功匹配則選擇該servlet。
容器將遞歸地嘗試匹配最長路徑前綴。這是通過一次一個目錄的遍歷路徑樹完成的，使用‘/’字元作為 路徑分隔設定。最長匹配確定選擇的servlet。
如果URL最後一部分包含一個擴展名（如.do），servlet容器將視圖匹配為擴展名處理請求的Servlet。 擴展名定義在最後一部分的最後一個‘.’字元之後。
如果前三個規則都沒有產生一個servlet匹配，容器將試圖為請求資源提供相關的內容。如果套用中定義 了一個“default”servlet，它將被使用。許多容器提供了一種隱式的default servlet用於提供內容。 容器必須使用區分大小寫字元串比較匹配。
1.容器將嘗試找到一個請求路逕到servlet路徑的精確匹配。成功匹配則選擇該servlet。
2.容器將遞歸地嘗試匹配最長路徑前綴。這是通過一次一個目錄的遍歷路徑樹完成的，使用‘/’字元作為 路徑分隔設定。最長匹配確定選擇的servlet。
3.如果URL最後一部分包含一個擴展名（如.do），servlet容器將視圖匹配為擴展名處理請求的Servlet。 擴展名定義在最後一部分的最後一個‘.’字元之後。
4.如果前三個規則都沒有產生一個servlet匹配，容器將試圖為請求資源提供相關的內容。如果套用中定義 了一個“default”servlet，它將被使用。許多容器提供了一種隱式的default servlet用於提供內容。 容器必須使用區分大小寫字元串比較匹配。
容器的匹配過程
精確路徑匹配。例子：比如servletA 的url-pattern為 /test，servletB的url-pattern為 /* ，這個時候，如果我訪問的url為http://localhost/test ，這個時候容器就會先進行精確路徑匹配，發現/test正好被servletA精確匹配，那么就去調用servletA，也不會去理會其他的 servlet了。
最長路徑匹配。例子：servletA的url-pattern為/test/*，而servletB的url-pattern為/test/a/*，此時訪問http://localhost/test/a時，容器會選擇路徑最長的servlet來匹配，也就是這裡的servletB。
擴展匹配，如果url最後一段包含擴展，容器將會根據擴展選擇合適的servlet。例子：servletA的url-pattern：*.action
如果前面三條規則都沒有找到一個servlet，容器會根據url選擇對應的請求資源。如果套用定義了一個default servlet，則容器會將請求丟給default servlet（什麼是default servlet？後面會講）。
1.精確路徑匹配。例子：比如servletA 的url-pattern為 /test，servletB的url-pattern為 /* ，這個時候，如果我訪問的url為http://localhost/test ，這個時候容器就會先進行精確路徑匹配，發現/test正好被servletA精確匹配，那么就去調用servletA，也不會去理會其他的 servlet了。
2.最長路徑匹配。例子：servletA的url-pattern為/test/*，而servletB的url-pattern為/test/a/*，此時訪問http://localhost/test/a時，容器會選擇路徑最長的servlet來匹配，也就是這裡的servletB。
3.擴展匹配，如果url最後一段包含擴展，容器將會根據擴展選擇合適的servlet。例子：servletA的url-pattern：*.action
4.如果前面三條規則都沒有找到一個servlet，容器會根據url選擇對應的請求資源。如果套用定義了一個default servlet，則容器會將請求丟給default servlet（什麼是default servlet？後面會講）。
根據這個規則表，就能很清楚的知道servlet的匹配過程，所以定義servlet的時候也要考慮url-pattern的寫法，以免出錯。對於filter，不會像servlet那樣只匹配一個servlet，因為filter的集合是一個鏈，所以只會有處理的順序不同，而不會出現只選擇一個filter。Filter的處理順序和filter-mapping在web.xml中定義的順序相同。
url-pattern詳解，在web.xml檔案中，以下語法用於定義映射：
以”/’開頭和以”/*”結尾的是用來做路徑映射的。 （對應於第2條匹配規則）
以前綴”*.”開頭的是用來做擴展映射的。（對應於第3條匹配規則）
“/”是用來定義default servlet映射的。（對應於第4條匹配規則）
剩下的都是用來定義詳細映射的。比如： /aa/bb/cc.action（對應於第1條匹配規則）
1.以”/’開頭和以”/*”結尾的是用來做路徑映射的。 （對應於第2條匹配規則）
2.以前綴”*.”開頭的是用來做擴展映射的。（對應於第3條匹配規則）
3.“/”是用來定義default servlet映射的。（對應於第4條匹配規則）
4.剩下的都是用來定義詳細映射的。比如： /aa/bb/cc.action（對應於第1條匹配規則）
所以，為什麼定義”/*.action”這樣一個看起來很正常的匹配會錯？因為這個匹配即屬於路徑映射，也屬於擴展映射，導致容器無法判斷。
注意
Request URI = context path + servlet path + path info.
Context paths 和 servlet paths 以 '/' 開始，但是不以'/'結尾.
HttpServletRequest 提供3個方法 getContextPath(),getServletPath() 和getPathInfo() 來分別獲取 context path, servlet path, path info。
1.Request URI = context path + servlet path + path info.
2.Context paths 和 servlet paths 以 '/' 開始，但是不以'/'結尾.
3.HttpServletRequest 提供3個方法 getContextPath(),getServletPath() 和getPathInfo() 來分別獲取 context path, servlet path, path info。
識別servlet路徑
為了匹配一個servlet請求URI，servlet容器遵循一個簡單的算法。 一旦確定了上下文路徑，如果有的話，它會評估該請求URI的其餘部分與在部署描述符中指定的servlet映射，按下列順序。如果它找到一個匹配在任何步驟，它不採取下一個步驟。
精確路徑匹配（上面匹配的第一條規則）：在這種情況下，getPathInfo()為空。
最長路徑匹配（上面匹配的第二條規則）：如果有一個匹配，請求URI的匹配部分是getServletPath() 結果，其餘部分是getPathInfo()。
擴展匹配（上面匹配的第三條規則）：在這種情況下，完整的請求URI是getServletPath()和getPathInfo()為空。
默認servlet匹配（上面匹配的第四條規則）：如果沒有默認的servlet，它會傳送未找到指示的servlet的錯誤訊息。
1.精確路徑匹配（上面匹配的第一條規則）：在這種情況下，getPathInfo()為空。
2.最長路徑匹配（上面匹配的第二條規則）：如果有一個匹配，請求URI的匹配部分是getServletPath() 結果，其餘部分是getPathInfo()。
3.擴展匹配（上面匹配的第三條規則）：在這種情況下，完整的請求URI是getServletPath()和getPathInfo()為空。
4.默認servlet匹配（上面匹配的第四條規則）：如果沒有默認的servlet，它會傳送未找到指示的servlet的錯誤訊息。
