衛(wèi)星寬帶通信系統(tǒng)(編輯修改稿)
2025-09-11 21:18 本頁(yè)面
【文章內(nèi)容簡(jiǎn)介】 24 衛(wèi)星網(wǎng)絡(luò)中的 TCP協(xié)議 續(xù) 18 ? 衛(wèi)星 TCP性能增強(qiáng)方法 ?端對(duì)端解決方法，包括： ?TCP增強(qiáng)技術(shù)：大窗口 (LW)選項(xiàng)， 增大初始窗口 (IIW)，字節(jié)計(jì)數(shù) (BC)，慢啟動(dòng)后的延遲確認(rèn) (DAASS)，選擇性確認(rèn) (SACK)，顯式擁塞通告 (ECN) ?TCP Vegas ?TCP Peach amp。 Peach+， TCP Swift ?基于中間件的解決方法，或性能增強(qiáng)代理，包括TCP分裂 (Splitting)和 TCP欺騙 (spoofing) 25 衛(wèi)星網(wǎng)絡(luò)中的 TCP協(xié)議 續(xù) 19 ? 大窗口 (LW)選項(xiàng) ?RFC 1323定義了一系列窗口擴(kuò)展選項(xiàng)，以供在包含衛(wèi)星鏈路的具有大的帶寬延時(shí)積的網(wǎng)絡(luò)中使用 ?具有較大帶寬延時(shí)積的網(wǎng)絡(luò)，如 ATM網(wǎng)絡(luò)、 Gigabit以太網(wǎng)、包交換同步光纖網(wǎng)絡(luò)和衛(wèi)星網(wǎng)絡(luò)等，都需要大窗口的支持，因此幾乎所有的商用 TCP實(shí)現(xiàn)都支持該選項(xiàng) 26 衛(wèi)星網(wǎng)絡(luò)中的 TCP協(xié)議 續(xù) 20 ? 增大初始窗口 (IIW) ?M. Allman， S. Floyd和 C. Partridge，“ Increasing TCP‘s Initial Window,” Inter RFC 2414，September 1998 ?慢啟動(dòng)開(kāi)始時(shí)初始化窗口的大小增加為 3到 4個(gè)報(bào)文段，這樣就會(huì)產(chǎn)生更多的確認(rèn)包，縮短慢啟動(dòng)過(guò)程的持續(xù)時(shí)間 ?由于擁塞窗口能夠更快地增加，系統(tǒng)性能得以改善，特別是在大 RTT鏈路上傳輸小文件時(shí)性能的改善越明顯 27 衛(wèi)星網(wǎng)絡(luò)中的 TCP協(xié)議 續(xù) 21 ? 增大初始窗口 (IIW) ?初始化窗口 (Winit) ?慢啟動(dòng)持續(xù)時(shí)間 ? ?i n i t m i n 4 , m a x ( 2 , 4 3 8 0 )W M S S M S S? ? ?2 m a x 2 i n i t( l o g W l o g W )SSt R T T? ? ?28 衛(wèi)星網(wǎng)絡(luò)中的 TCP協(xié)議 續(xù) 22 ? 選擇性確認(rèn) SACK ?TCP SACK， IETF RFC 2022 ?TCP (Tahoe/Reno) 的一個(gè)重要問(wèn)題是對(duì)單個(gè)傳輸窗口內(nèi)丟失多個(gè)報(bào)文段比較敏感，這會(huì)導(dǎo)致連接失去其自定時(shí)特性并超時(shí) ?TCP SACK是一個(gè)數(shù)據(jù)恢復(fù)算法，接收端可以選擇性地指示那些報(bào)文段是沒(méi)有接收到的。 這樣發(fā)端可以明確地僅重傳丟失的報(bào)文段，從而大幅度減少不必要的重傳 29 衛(wèi)星網(wǎng)絡(luò)中的 TCP協(xié)議 續(xù) 23 ? 選擇性確認(rèn) SACK ?可以與已有的擁塞控制算法 (如慢啟動(dòng)、擁塞避免?？焖倩謴?fù)和快速重傳 )混合使用，如 Reno+SACK ?在長(zhǎng)延時(shí)、中等報(bào)文段丟失率 (低于窗口尺寸的 50％ )的情況下， TCP SACK的性能良好 ?SACK能夠顯著地降低超時(shí)的出現(xiàn)次數(shù)，與其它的非 SACK版本相比也未表現(xiàn)出過(guò)度的侵略性 30 衛(wèi)星網(wǎng)絡(luò)中的 TCP協(xié)議 續(xù) 24 ? 選擇性確認(rèn) SACK ?在不同的地面 Inter設(shè)置條件下，采用 SACK時(shí)平均吞吐率提高約 15％～ 50％ ?在鏈路的差錯(cuò)率很大的情況下，采用 TCP SACK也不能防止大量超時(shí)的出現(xiàn)， TCP的平均吞吐率會(huì)低于 15％ ?采用 SACK選項(xiàng)時(shí)，需要對(duì) TCP的收發(fā)端協(xié)議棧進(jìn)行大量的修改 31 衛(wèi)星網(wǎng)絡(luò)中的 TCP協(xié)議 續(xù) 25 ? 慢啟動(dòng)后的延遲確認(rèn) DAASS ?在慢啟動(dòng)后才使用延遲確認(rèn)，這樣在 TCP連接主動(dòng)增加擁塞窗口大小時(shí)提供了足夠多的確認(rèn)，而在TCP連接穩(wěn)定后減少確認(rèn)數(shù)目以節(jié)約網(wǎng)絡(luò)資源 ?DAASS的主要問(wèn)題是如何實(shí)現(xiàn)：接收端必須知道發(fā)送端什么時(shí)候開(kāi)始慢啟動(dòng)過(guò)程，從而決定是否使用延遲確認(rèn) 32 衛(wèi)星網(wǎng)絡(luò)中的 TCP協(xié)議 續(xù) 26 ? 顯式擁塞通告 ECN ?在網(wǎng)絡(luò)開(kāi)始擁塞時(shí)，顯式通告機(jī)制將 IP包頭中 1比特ECN域設(shè)置為 1來(lái)通知終端節(jié)點(diǎn) ?相應(yīng)地，終端節(jié)點(diǎn)減小其傳輸速率，因此可以避免網(wǎng)絡(luò)出現(xiàn)嚴(yán)重的擁塞現(xiàn)象并導(dǎo)致大量不必要的報(bào)文段丟失 ?發(fā)送端可以在重傳定時(shí)器超時(shí)或接收到 3個(gè)重復(fù)確認(rèn)之前就可以收到顯式的擁塞信息，因此，如果一個(gè)報(bào)文段丟失而沒(méi)有擁塞指示，則該報(bào)文段的丟失就一定是有鏈路的差錯(cuò)造成的，發(fā)送端無(wú)需降低其傳輸速率 ?ECN方法的實(shí)現(xiàn)要求 IP支持 ECN域，要求 TCP能夠獲得 IP包頭中的信息，因此需要對(duì) TCP/IP協(xié)議棧中的部分協(xié)議進(jìn)行相應(yīng)的修改 33 衛(wèi)星網(wǎng)絡(luò)中的 TCP協(xié)議 續(xù) 27 ? TCP Vegas ?TCP Vegas不以包丟失作為擁塞指示，而是使用傳輸速率來(lái)實(shí)現(xiàn)擁塞控制 ?在每一個(gè)往返程時(shí)間，發(fā)送端基于傳輸窗口和測(cè)量的往返程時(shí)間來(lái)計(jì)算傳輸速率。計(jì)算出的速率與期望的速率相比較。期望的速率等于傳輸窗口除以基本往返程時(shí)間，基本往返程時(shí)間則是迄今為止測(cè)得的最小往返程時(shí)間 ?基本
黨政相關(guān)相關(guān)推薦
鄂ICP備17016276號(hào)-1