參考：https://www.rfc-editor.org/rfc/rfc5766.html?

?????? ? https://www.rfc-editor.org/rfc/rfc5389.html

目錄

1、新的STUN方法

2、新的STUN屬性

2.1、CHANNEL-NUMBER

2.2、LIFETIME

2.3、XOR-PEER-ADDRESS

2.4、DATA

2.5、XOR-RELAYED-ADDRESS

2.6、EVEN-PORT

2.7、REQUESTED-TRANSPORT

2.8、DONT-FRAGMENT

2.9、RESERVATION-TOKEN

3、新的STUN錯(cuò)誤返回碼

4、詳細(xì)示例

---

TURN，在RFC5766中定義，英文全稱Traversal Using Relays around NAT（TURN）：Relay Extensions to Session Traversal Utilities for NAT（STUN），即使用中繼穿透NAT：STUN的中繼擴(kuò)展。簡單的說，TURN與STUN的共同點(diǎn)都是通過修改應(yīng)用層中的私網(wǎng)地址達(dá)到NAT穿透的效果，異同點(diǎn)是TURN是通過兩方通訊的“中間人”方式實(shí)現(xiàn)穿透。

如果一個(gè)主機(jī)位于NAT的后面，在某些情況下它不能夠與其他主機(jī)點(diǎn)對點(diǎn)直接連接。在這些情況下，它需要使用中間網(wǎng)點(diǎn)提供的中繼連接服務(wù)。TURN協(xié)議就是用來允許主機(jī)控制中繼的操作并且使用中繼與對端交換數(shù)據(jù)。TURN與其他中繼控制協(xié)議不同的是它能夠允許一個(gè)客戶端使用一個(gè)中繼地址與多個(gè)對端連接。

TURN協(xié)議被設(shè)計(jì)為ICE的一部分，用于NAT穿越，雖然如此，它也可以在沒有ICE的地方單獨(dú)使用。

在典型配置中，TURN客戶端連接到專用網(wǎng)絡(luò)[RFC1918]并通過一個(gè)或多個(gè)NAT連接到公共互聯(lián)網(wǎng)。公共互聯(lián)網(wǎng)上有一個(gè)TURN服務(wù)器。互聯(lián)網(wǎng)上的其他地方是TURN客戶端希望與之通信的一個(gè)或多個(gè)對等體。這些對等體可能支持也可能不支持一個(gè)或多個(gè)NAT。客戶端使用服務(wù)器作為中繼向這些對等體發(fā)送數(shù)據(jù)包，并從這些對等體接收數(shù)據(jù)包。

圖1顯示了一個(gè)典型的部署。在此圖中，TURN客戶端和TURN服務(wù)器由NAT分開，客戶端位于NAT的私有端，服務(wù)器位于NAT的公共端。這個(gè)NAT被認(rèn)為是一個(gè)“壞”NAT；例如，它可能具有“地址和端口相關(guān)映射”的映射屬性(參見[RFC4787])。

由于客戶端位于NAT之后，服務(wù)器將來自客戶端的數(shù)據(jù)包視為來自NAT本身的傳輸?shù)刂贰＿@個(gè)地址被稱為客戶端的服務(wù)器反射傳輸?shù)刂?/span>；由服務(wù)器發(fā)送到客戶機(jī)的服務(wù)器反射傳輸?shù)刂返臄?shù)據(jù)包將由NAT轉(zhuǎn)發(fā)到客戶機(jī)的主機(jī)傳輸?shù)刂贰?/p>

客戶端使用TURN命令在服務(wù)器上創(chuàng)建和操作ALLOCATION。ALLOCATION是服務(wù)器上的數(shù)據(jù)結(jié)構(gòu)。該數(shù)據(jù)結(jié)構(gòu)包含分配的中繼(RELAYED)傳輸?shù)刂?/span>等。中繼傳輸?shù)刂肥欠?wù)器上的傳輸?shù)刂?#xff0c;對等方可以使用它讓服務(wù)器將數(shù)據(jù)中繼到客戶端。分配由其中繼傳輸?shù)刂肺ㄒ粯?biāo)識(shí)。

一旦創(chuàng)建了allocation，客戶端可以向服務(wù)器發(fā)送應(yīng)用程序數(shù)據(jù)以及數(shù)據(jù)將被發(fā)送到哪個(gè)對等體的指示，并且服務(wù)器將把該數(shù)據(jù)中繼到適當(dāng)?shù)膶Φ润w。客戶端在TURN消息中向服務(wù)器發(fā)送應(yīng)用數(shù)據(jù)；在服務(wù)器上，數(shù)據(jù)從TURN消息中提取，并以UDP數(shù)據(jù)報(bào)的形式發(fā)送給對等方。相反，對等體可以將UDP數(shù)據(jù)報(bào)中的應(yīng)用數(shù)據(jù)發(fā)送到中繼傳輸?shù)刂愤M(jìn)行分配；然后，服務(wù)器將把這些數(shù)據(jù)封裝在TURN消息中，并將其發(fā)送給客戶端，同時(shí)指明是哪個(gè)對等方發(fā)送了這些數(shù)據(jù)。因?yàn)門URN消息總是包含客戶端正在與哪個(gè)對等體通信的指示，所以客戶端可以使用單個(gè)分配來與多個(gè)對等體通信。

當(dāng)對等點(diǎn)位于NAT之后時(shí)，客戶端必須使用其服務(wù)器反射傳輸?shù)刂范皇侵鳈C(jī)傳輸?shù)刂穪碜R(shí)別對等點(diǎn)。例如，在上面的示例中，要向?qū)eer A發(fā)送應(yīng)用程序數(shù)據(jù)，客戶端必須指定192.0.2.150:32102(Peer A的服務(wù)器反射傳輸?shù)刂?，而不是192.168.100.2: 49582(Peer A的主機(jī)傳輸?shù)刂?。

在圖2中，客戶端向服務(wù)器發(fā)送一個(gè)沒有憑據(jù)的Allocate請求。由于服務(wù)器要求使用stun的長期憑據(jù)機(jī)制對所有請求進(jìn)行身份驗(yàn)證，因此服務(wù)器會(huì)使用401(未授權(quán))錯(cuò)誤代碼拒絕該請求。客戶端然后再次嘗試，這次包括憑證(未示出)。這一次，服務(wù)器接受Allocate請求，并返回Allocate成功響應(yīng)，其中包含分配給分配的中繼傳輸?shù)刂贰Ｉ院?#xff0c;客戶端決定刷新Allocate，從而向服務(wù)器發(fā)送刷新請求。刷新被接受，服務(wù)器回復(fù)刷新成功響應(yīng)。

1、新的STUN方法

本節(jié)列出了本規(guī)范中定義的新STUN方法的代碼點(diǎn)。有關(guān)這些新方法的語義，請參見本文的其他部分。

?? 0x003? :? Allocate????????? (only request/response semantics defined)

?? 0x004? :? Refresh?????????? (only request/response semantics defined)

?? 0x006? :? Send????????????? (only indication semantics defined)

?? 0x007? :? Data????????????? (only indication semantics defined)

?? 0x008? :? CreatePermission? (only request/response semantics defined

?? 0x009? :? ChannelBind?????? (only request/response semantics defined)

2、新的STUN屬性

這個(gè)STUN擴(kuò)展定義了以下新屬性:

???? 0x000C: CHANNEL-NUMBER

???? 0x000D: LIFETIME

???? 0x0010: Reserved (was BANDWIDTH)

???? 0x0012: XOR-PEER-ADDRESS

???? 0x0013: DATA

???? 0x0016: XOR-RELAYED-ADDRESS

???? 0x0018: EVEN-PORT

???? 0x0019: REQUESTED-TRANSPORT

???? 0x001A: DONT-FRAGMENT

???? 0x0021: Reserved (was TIMER-VAL)

???? 0x0022: RESERVATION-TOKEN

其中一些屬性的長度不是4的倍數(shù)。根據(jù)STUN規(guī)則，任何長度不是4字節(jié)倍數(shù)的屬性都必須緊跟1到3個(gè)填充字節(jié)，以確保下一個(gè)屬性(如果有的話)從4字節(jié)邊界開始(參見[RFC5389])。

2.1、CHANNEL-NUMBER

CHANNEL-NUMBER屬性包含頻道號(hào)。該屬性的值部分為4字節(jié)長，由一個(gè)16位無符號(hào)整數(shù)組成，后跟一個(gè)二進(jìn)制八位數(shù)RFFU (保留供將來使用)字段，該字段在傳輸時(shí)必須設(shè)置為0，在接收時(shí)必須忽略。

2.2、LIFETIME

LIFETIME屬性表示在沒有refresh的情況下服務(wù)器將維持allocation的持續(xù)時(shí)間。該屬性的值部分為4字節(jié)長，由一個(gè)32位無符號(hào)整數(shù)值組成，該整數(shù)值表示截止前剩余的秒數(shù)。

2.3、XOR-PEER-ADDRESS

XOR-PEER-ADDRESS指定TURN服務(wù)器上看到的peer的地址和端口。(例如，如果peer在NAT之后，則為peer的服務(wù)器反射傳輸?shù)刂贰?其編碼方式與XOR-MAPPED-ADDRESS [RFC5389]相同

2.4、DATA

DATA屬性出現(xiàn)在所有Send和Data indication中。該屬性的值部分是可變長度的，由應(yīng)用程序數(shù)據(jù)組成(也就是說，如果數(shù)據(jù)是在客戶端和peer之間直接發(fā)送的，將緊跟在UDP報(bào)頭之后的數(shù)據(jù))。如果該屬性的長度不是4的倍數(shù)，則必須在該屬性之后添加填充。

2.5、XOR-RELAYED-ADDRESS

XOR-RELAYED-ADDRESS出現(xiàn)在Allocate響應(yīng)中。它指定服務(wù)器分配給客戶端的地址和端口。它的編碼方式與XOR-MAPPED-ADDRESS[RFC5389]相同。

2.6、EVEN-PORT

此屬性允許客戶端請求中繼傳輸?shù)刂分械亩丝谑桥紨?shù)，并且(可選地)服務(wù)器保留下一個(gè)更高的端口號(hào)。該屬性的值部分長度為1字節(jié)。其格式是:

該值包含一個(gè)1位標(biāo)志:

R:? 如果為1，則請求服務(wù)器保留下一個(gè)更高的端口號(hào)(在同一IP地址上)用于后續(xù)分配。如果為0，則不請求此類預(yù)訂。

屬性值的其他7位必須在傳輸時(shí)設(shè)置為零，在接收時(shí)忽略。

由于該屬性的長度不是4的倍數(shù)，填充必須緊跟在該屬性之后。

2.7、REQUESTED-TRANSPORT

客戶端使用該屬性為分配的傳輸?shù)刂氛埱筇囟ǖ膫鬏攨f(xié)議。此屬性的值為4字節(jié)，格式如下:

Protocol字段指定所需的協(xié)議。此字段中使用的代碼點(diǎn)取自IPv4報(bào)頭的協(xié)議字段和IPv4報(bào)頭[Protocol-Numbers]中的NextHeader字段中允許的代碼點(diǎn)。該規(guī)范只允許使用碼點(diǎn)17(User Datagram Protocol，UDP)。

RFFU字段在傳輸時(shí)必須設(shè)置為零，在接收時(shí)必須忽略。它是留作將來使用的。

2.8、DONT-FRAGMENT

客戶端使用該屬性請求服務(wù)器在將應(yīng)用程序數(shù)據(jù)轉(zhuǎn)發(fā)給peer時(shí)設(shè)置IP報(bào)頭中的DF (Don't Fragment，不分段)位。該屬性沒有值部分，因此屬性長度字段為0。

2.9、RESERVATION-TOKEN

RESERVATION-TOKEN屬性包含唯一標(biāo)識(shí)服務(wù)器保留的中繼傳輸?shù)刂返膖oken。服務(wù)器在成功響應(yīng)中包括該屬性，以告訴客戶端關(guān)于token的信息，并且客戶端在隨后的Allocate請求中包括該屬性，以請求服務(wù)器使用該中繼傳輸?shù)刂愤M(jìn)行分配。

屬性值為8字節(jié)，包含token值。

3、新的STUN錯(cuò)誤返回碼

本文檔定義了以下新的錯(cuò)誤響應(yīng)代碼:

? ? ? ? 403? (Forbidden，禁止):請求有效，但由于管理或類似限制而無法執(zhí)行。

? ? ? ? 437 (Allocation Mismatch，Allocation不匹配):服務(wù)器收到請求，要求allocation到位，但不存在allocation；或者收到請求，? ? ? ? ? ? ? ? 不要求allocation，但存在allocation。

? ? ? ?441 (Wrong Credentials，錯(cuò)誤的憑據(jù)):(非Allocate)請求中的憑據(jù)與用于創(chuàng)建allocation的憑據(jù)不匹配。

?????? 442 (Unsupported Transport Protocol，不支持的傳輸協(xié)議): Allocate請求要求服務(wù)器在服務(wù)器和peer之間使用服務(wù)器不支持? ? ? ? ? ? ? ? 的傳輸協(xié)議。注意:這不是指5元組中使用的傳輸協(xié)議。

?????? 486? (Allocation Quota Reached，已達(dá)到Allocation配額):目前無法使用此用戶名創(chuàng)建更多Allocation。

?????? 508? (Insufficient Capacity，容量不足):由于達(dá)到了某些容量限制，服務(wù)器無法執(zhí)行請求。在Allocate響應(yīng)中，這可能是因?yàn)? ? ? ? ? ? ? ? ?服務(wù)器當(dāng)時(shí)沒有可用的中繼傳輸?shù)刂?#xff0c;沒有具有所請求屬性的地址，或者對應(yīng)于指定預(yù)留token的地址不可用。

4、詳細(xì)示例

本節(jié)給出了TURN的使用示例，詳細(xì)顯示了所交換消息的內(nèi)容。該示例使用概述中顯示的網(wǎng)絡(luò)圖(圖1)。

對于每條消息，都會(huì)顯示消息中包含的屬性及其值。為了方便起見，值以人類可讀的格式顯示，而不是顯示實(shí)際的八位字節(jié)；例如，"XOR-RELAYED-ADDRESS=192.0.2.15:9000"表示XOR-RELAYED-ADDRESS屬性包括192.0.2.15地址和9000端口，這里地址和端口在異或操作完成之前顯示。對于具有類似字符串值的屬性(例如，SOFTWARE="Example client, version 1.03"和NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm")，屬性的值以引號(hào)顯示，以提高可讀性，但這些引號(hào)不會(huì)出現(xiàn)在實(shí)際值中。

客戶端首先選擇一個(gè)用于TURN會(huì)話的主機(jī)傳輸?shù)刂?#xff1b;在這個(gè)例子中，客戶端選擇了10.1.1.2: 49721，如圖1所示。客戶端然后在服務(wù)器傳輸?shù)刂废蚍?wù)器發(fā)送Allocate請求。客戶端為此事務(wù)隨機(jī)選擇96位事務(wù)0xA56250D3F17ABE679422DE85；這在固定頭的事務(wù)id字段中編碼。客戶端包括SOFTWARE屬性，該屬性給出關(guān)于客戶端軟件的信息；這里的值是"Example client, version 1.03"，表示這是被稱為示例客戶端的1.03版。客戶端包含LIFETIME屬性，因?yàn)樗Ｍ峙渚哂斜饶J(rèn)的10分鐘更長的生命周期；該屬性的值為3600秒，相當(dāng)于1小時(shí)。客戶端必須始終在分配請求中包含REQUESTED-TRANSPORT屬性，并且該規(guī)范允許的唯一值是17，這表示服務(wù)器和對等方之間的UDP傳輸。客戶端還包括DONT-FRAGMENT屬性，因?yàn)樗Ｍ院笤诎l(fā)送指示中使用DONT-FRAGMENT屬性；這個(gè)屬性只包含一個(gè)屬性頭，沒有值部分。我們假設(shè)客戶端最近沒有與服務(wù)器交互，因此客戶端不包括USERNAME, REALM, NONCE, 或 MESSAGE-INTEGRITY屬性。最后，注意消息中屬性的順序是任意的(除了MESSAGE-INTEGRITY 和 FINGERPRINT),客戶端可能使用了不同的順序。

服務(wù)器要求對任何請求進(jìn)行身份驗(yàn)證。因此，當(dāng)服務(wù)器收到初始Allocate請求時(shí)，它會(huì)拒絕該請求，因?yàn)樵撜埱蟛话矸蒡?yàn)證屬性。遵循STUN [RFC5389]的長期憑證機(jī)制的過程，服務(wù)器包括值為401(Unauthorized)的ERROR-CODE屬性、指定服務(wù)器所使用的認(rèn)證領(lǐng)域的REALM屬性(在本例中是服務(wù)器的域“example.com”)，以及NONCE屬性中的nonce值。服務(wù)器還包括一個(gè)SOFTWARE屬性，它提供了關(guān)于服務(wù)器軟件的信息。如下圖：

客戶端在接收到401錯(cuò)誤后，重新嘗試Allocate請求，這次包括認(rèn)證屬性。客戶端選擇一個(gè)新的事務(wù)id，然后用與以前相同的屬性填充新的Allocate請求。客戶端包括USERNAME屬性，并使用從服務(wù)器接收的realm值來幫助它確定使用哪個(gè)值；在這里，客戶端被配置為將用戶名“george”用于領(lǐng)域“example.com”。客戶端還包括REALM和NONCE屬性，它們是從401錯(cuò)誤響應(yīng)中復(fù)制的。最后，客戶端將MESSAGE-INTEGRITY屬性作為消息中的最后一個(gè)屬性，其值是Hashed消息。如下圖：

認(rèn)證碼-安全哈希算法1 (HMAC-SHA1)對消息內(nèi)容進(jìn)行哈希處理(顯示為“...”以上)；該HMAC-SHA1計(jì)算包括密碼值。因此，攻擊者不知道秘密密碼就無法計(jì)算message integrity。

服務(wù)器在收到認(rèn)證的分配請求后，檢查一切正常，然后創(chuàng)建allocation。服務(wù)器以Allocate成功響應(yīng)進(jìn)行回復(fù)。服務(wù)器包括給出Allocate壽命的LIFETIME命屬性；這里，服務(wù)器已經(jīng)將客戶端請求的1小時(shí)生命周期減少到20分鐘，因?yàn)樵撎囟ǚ?wù)器不允許超過20分鐘的生命周期。服務(wù)器包括XOR-RELAYED-ADDRESS屬性，其值是分配的中繼傳輸?shù)刂贰７?wù)器包括XOR-MAPPED-ADDRESS屬性，其值是客戶端的服務(wù)器反射地址；該值不會(huì)反過來被使用，而是為了方便客戶端而返回。服務(wù)器包括MESSAGE-INTEGRITY屬性，以認(rèn)證響應(yīng)并確保其完整性；請注意，響應(yīng)不包含USERNAME, REALM, 和 NONCE屬性。服務(wù)器還包括軟件屬性。如下圖：

然后，客戶端創(chuàng)建對Peer A的許可，為向其發(fā)送一些應(yīng)用程序數(shù)據(jù)做準(zhǔn)備。這是通過CreatePermission請求完成的。XOR-PEER-ADDRESS屬性包含為其建立許可的IP地址(peer A的ip地址)；請注意，屬性中的端口號(hào)在CreatePermission請求中使用時(shí)會(huì)被忽略，這里它被設(shè)置為0；此外，請注意客戶端如何使用Peer A的服務(wù)器反射IP地址，而不是其(私有)主機(jī)地址。客戶端使用與上一次分配請求中相同的username, realm, 和 nonce。雖然允許這樣做，但客戶端選擇不在該請求中包含SOFTWARE屬性。

服務(wù)器接收CreatePermission請求，創(chuàng)建相應(yīng)的權(quán)限，然后用CreatePermission成功響應(yīng)進(jìn)行回復(fù)。像客戶端一樣，服務(wù)器選擇不在其回復(fù)中包含SOFTWARE屬性。同樣，請注意成功響應(yīng)如何包含MESSAGE-INTEGRITY屬性(假設(shè)服務(wù)器使用長期憑據(jù)機(jī)制)，但不包含用USERNAME, REALM, 和NONCE屬性。

客戶端現(xiàn)在使用發(fā)送指示(indication)向Peer A發(fā)送應(yīng)用程序數(shù)據(jù)。Peer A的服務(wù)器反射傳輸?shù)刂吩赬OR-PEER-ADDRESS屬性中指定，應(yīng)用程序數(shù)據(jù)(此處僅顯示為“...”)在DATA屬性中指定。客戶端在應(yīng)用層執(zhí)行一種路徑MTU發(fā)現(xiàn)，因此指定(通過包含DONT-FRAGMENT屬性),服務(wù)器應(yīng)該在UDP數(shù)據(jù)報(bào)中設(shè)置DF位以發(fā)送給peer。無法使用STUN的長期憑據(jù)機(jī)制對指示進(jìn)行身份驗(yàn)證，因此消息中不包含MESSAGE-INTEGRITY屬性。希望確保其數(shù)據(jù)不被更改或偽造的應(yīng)用程序必須在應(yīng)用程序級(jí)別完整保護(hù)其數(shù)據(jù)。

當(dāng)接收到Send指示時(shí)，服務(wù)器提取應(yīng)用數(shù)據(jù)，并在UDP數(shù)據(jù)報(bào)中將其發(fā)送到Peer A，中繼的傳輸?shù)刂纷鳛閿?shù)據(jù)報(bào)的源傳輸?shù)刂?#xff0c;DF位按請求設(shè)置。請注意，如果客戶端之前沒有為對Peer A的服務(wù)器反射IP地址建立權(quán)限，那么服務(wù)器會(huì)默默地丟棄發(fā)送指示。

Peer A然后用它自己的包含應(yīng)用程序數(shù)據(jù)的UDP數(shù)據(jù)報(bào)進(jìn)行回復(fù)。數(shù)據(jù)報(bào)被發(fā)送到服務(wù)器上的中繼傳輸?shù)刂贰．?dāng)它到達(dá)時(shí)，服務(wù)器創(chuàng)建一個(gè)Data指示，在XOR-PEER-ADDRESS屬性中包含UDP數(shù)據(jù)報(bào)的源，在DATA屬性中包含來自UDP數(shù)據(jù)報(bào)的數(shù)據(jù)。結(jié)果DATA指示隨后被發(fā)送到客戶端。

客戶端現(xiàn)在將channel綁定到Peer B，在CHANNEL-NUMBER屬性中指定空閑channel號(hào)(0x4000)，在XOR-PEER-ADDRESS屬性中指定Peer B的傳輸?shù)刂贰Ｈ缜八?#xff0c;客戶端重新使用消息中最后一次請求的username, realm, 和 nonce。

收到請求后，服務(wù)器將channel號(hào)綁定到peer，為Peer B的IP地址安裝權(quán)限，然后用ChannelBind成功響應(yīng)進(jìn)行回復(fù)。

客戶端現(xiàn)在向服務(wù)器發(fā)送一個(gè)包含去往Peer B的數(shù)據(jù)的ChannelData消息，ChannelData消息不是STUN消息，因此沒有事務(wù)ID。相反，它只有三個(gè)字段: channel號(hào)、數(shù)據(jù)和數(shù)據(jù)長度；這里的channel號(hào)字段是0x4000(客戶端剛剛綁定到對Peer B的通道)。當(dāng)服務(wù)器接收到ChannelData消息時(shí)，它檢查channel當(dāng)前是否被綁定(它是綁定的)，然后使用中繼的傳輸?shù)刂纷鳛樵磦鬏數(shù)刂?#xff0c;使用192.0.2.210:49191(ChannelBind請求中XOR-PEER-ADDRESS屬性的值)作為目的傳輸?shù)刂?#xff0c;將數(shù)據(jù)以UDP數(shù)據(jù)報(bào)的形式向前發(fā)送到Peer B。

稍后，Peer B將UDP數(shù)據(jù)報(bào)發(fā)送回中繼傳輸?shù)刂贰＿@導(dǎo)致服務(wù)器向客戶端發(fā)送包含UDP數(shù)據(jù)報(bào)數(shù)據(jù)的ChannelData消息。由于UDP數(shù)據(jù)報(bào)到達(dá)的中繼傳輸?shù)刂?#xff0c;服務(wù)器知道向哪個(gè)客戶端發(fā)送ChannelData消息，并且知道使用channel 0x4000，因?yàn)檫@是綁定到192.0.2.210:49191的channel。請注意，如果沒有任何channel號(hào)綁定到該地址，服務(wù)器會(huì)使用Data指示來代替。

在20分鐘生命周期結(jié)束之前，客戶端會(huì)刷新allocation。這是使用Refresh請求完成的。和以前一樣，客戶端在請求中包含最新的username, realm, 和 nonce。客戶端還包括SOFTWARE屬性，遵循推薦的做法，總是在Allocate and Refresh消息中包括該屬性。當(dāng)服務(wù)器收到刷新請求時(shí)，它會(huì)注意到隨機(jī)數(shù)值已經(jīng)過期，因此在給定新隨機(jī)數(shù)值的情況下，會(huì)以438(Stale Nonce)錯(cuò)誤進(jìn)行回復(fù)。然后，客戶端重新嘗試請求，這次使用新的nonce值。第二次嘗試被接受，服務(wù)器以成功響應(yīng)進(jìn)行回復(fù)。請注意，客戶端在請求中沒有包含LIFETIME屬性，因此服務(wù)器會(huì)刷新默認(rèn)生命周期10分鐘的分配(從成功響應(yīng)中的LIFETIME屬性可以看出)。

總結(jié)

以上是生活随笔為你收集整理的TURN协议简要介绍的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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