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

資源預留協(xié)議（RSVP）是一種用于互聯(lián)網(wǎng)上質(zhì)量整合服務的協(xié)議。RSVP協(xié)議允許主機在網(wǎng)絡上請求特殊服務質(zhì)量用于特殊應用程序數(shù)據(jù)流的傳輸。路由器也使用RSVP發(fā)送服務質(zhì)量（QOS）請求給所有結(jié)點（沿著流路徑）并建立和維持這種狀態(tài)以提供請求服務。通常RSVP請求將會引起每個節(jié)點數(shù)據(jù)路徑上的資源預留。

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

RSVP不傳輸應用數(shù)據(jù)，但支持因特網(wǎng)控制協(xié)議，如 ICMP、IGMP 或者路由選擇協(xié)議。正如路由選擇和管理類協(xié)議的實施一樣，RSVP的運行也是在后臺執(zhí)行，而并非在數(shù)據(jù)轉(zhuǎn)發(fā)路徑上。

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

以組播為例，主機發(fā)送 IGMP 信息以加入組播組，然后沿著組播組傳送路徑，發(fā)送RSVP信息以預留資源。路由選擇協(xié)議決定數(shù)據(jù)包轉(zhuǎn)發(fā)到哪。

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

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