今天我們來介紹一下RSVP協議。這個協議在一些工作領域中還是很重要的，所以學好這個協議也是對我們的一些工作有所幫助的。為了完成因特網的控制，我們規定了很多種類的協議進行規范，這樣才能進行主機和主機間的傳輸。那么，在這之中，我們來介紹一下RSVP協議。這個協議很多朋友都不是很清楚。

資源預留協議（RSVP）是一種用于互聯網上質量整合服務的協議。RSVP協議允許主機在網絡上請求特殊服務質量用于特殊應用程序數據流的傳輸。路由器也使用RSVP發送服務質量（QOS）請求給所有結點（沿著流路徑）并建立和維持這種狀態以提供請求服務。通常RSVP請求將會引起每個節點數據路徑上的資源預留。

RSVP 只在單方向上進行資源請求，因此，盡管相同的應用程序，同時可能既擔當發送者也擔當接受者，但RSVP協議對發送者與接受者在邏輯上是有區別的。RSVP運行在 IPV4 或 IPV6 上層，占據協議棧中傳輸協議的空間。

RSVP不傳輸應用數據，但支持因特網控制協議，如 ICMP、IGMP 或者路由選擇協議。正如路由選擇和管理類協議的實施一樣，RSVP的運行也是在后臺執行，而并非在數據轉發路徑上。

RSVP本質上并不屬于路由選擇協議，RSVP協議的設計目標是與當前和未來的單播（unicast）和組播（multicast）路由選擇協議同時運行。RSVP進程參照本地路由選擇數據庫以獲得傳送路徑。

以組播為例，主機發送 IGMP 信息以加入組播組，然后沿著組播組傳送路徑，發送RSVP信息以預留資源。路由選擇協議決定數據包轉發到哪。

RSVP只考慮根據路由選擇所轉發的數據包的QOS。為了有效適應大型組、動態組成員以及不同機種的接收端需求，通過RSVP，接收端可以請求一個特定的QOS[RSVP93] 。

QOS 請求從接收端主機應用程序被傳送至本地RSVP進程，然后RSVP協議沿著相反的數據路徑，將此請求傳送到所有節點（路由器和主機），但是只到達接收端數據路徑加入到組播分配樹中時的路由器。所以，RSVP預留開銷是和接受端的數量成對數關系而非線性關系。