[發(fā)明專利]UDP數(shù)據(jù)傳輸?shù)姆椒?、裝置、存儲(chǔ)介質(zhì)及終端設(shè)備

有效

• 申請(qǐng)?zhí)枺?/td>: 201711433724.5
• 申請(qǐng)日: 2017-12-26
• 公開（公告）號(hào): CN108173928B
• 公開（公告）日: 2019-02-05
• 發(fā)明（設(shè)計(jì)）人: 張全發(fā)
• 申請(qǐng)（專利權(quán)）人: 北京百度網(wǎng)訊科技有限公司
• 主分類號(hào): H04L29/08
• 分類號(hào): H04L29/08;H04L29/06;H04L29/12
• 代理公司: 北京市鑄成律師事務(wù)所 11313
• 代理人: 張臻賢;王珺

本發(fā)明提出一種UDP數(shù)據(jù)傳輸?shù)姆椒?、裝置、存儲(chǔ)介質(zhì)及終端設(shè)備，其中，所述方法包括：接收服務(wù)端新建UDP會(huì)話的映射地址組，并將接收到的映射地址組記錄于映射表中；其中，所述映射地址組包括請(qǐng)求建立所述UDP會(huì)話的客戶端的UDP端口地址和為所述UDP會(huì)話創(chuàng)建的服務(wù)端的UDP端口地址；當(dāng)接收到UDP數(shù)據(jù)時(shí)，查詢所述映射表中是否存在可用于傳送所述UDP數(shù)據(jù)的映射地址組；若有，則根據(jù)查詢到的映射地址組，傳送所述UDP數(shù)據(jù)；若否，則根據(jù)所述UDP數(shù)據(jù)，更新所述映射表中映射地址組的狀態(tài)。采用本發(fā)明，能夠在設(shè)置網(wǎng)關(guān)僅提供一個(gè)UDP端口時(shí)，采用以往的網(wǎng)關(guān)穿透方式來傳送UDP數(shù)據(jù)，準(zhǔn)確傳輸U(kuò)DP數(shù)據(jù)。

技術(shù)領(lǐng)域

本發(fā)明涉及通信技術(shù)領(lǐng)域，尤其涉及一種UDP數(shù)據(jù)傳輸?shù)南螺d方法、裝置、存儲(chǔ)介質(zhì)及終端設(shè)備。

背景技術(shù)

在實(shí)時(shí)音視頻通信(Webrtc)應(yīng)用中，為保證實(shí)時(shí)性，和高可控性，往往采用UDP(User Datagram Protocol，用戶數(shù)據(jù)報(bào)協(xié)議)傳輸音視頻數(shù)據(jù)。Webrtc給出了一種使用P2P的通信架構(gòu)，即，使用可靠的TCP(Transmission Control Protocol，傳輸控制協(xié)議)傳輸信令數(shù)據(jù)，以及使用UDP傳輸音視頻媒體數(shù)據(jù)流；其中，Webrtc使用了ICE協(xié)議解決UDP數(shù)據(jù)NAT(Network Address Translation，網(wǎng)絡(luò)地址轉(zhuǎn)換)網(wǎng)關(guān)穿越的問題。在實(shí)際的產(chǎn)品需求中，需要利用一個(gè)對(duì)接Webrtc的Server端，來實(shí)現(xiàn)匯聚和分發(fā)多個(gè)端的流媒體數(shù)據(jù)；例如，結(jié)構(gòu)由原來的Client-A和Client-B直接通信，變?yōu)榱薈lient-A和Client-B通過Server端間接通信，具體參閱如圖1所示的網(wǎng)絡(luò)拓?fù)鋱D。

其中，Client-A和Client-B處于同一個(gè)NAT網(wǎng)絡(luò)內(nèi)，分別擁有內(nèi)網(wǎng)IP和外網(wǎng)IP兩個(gè)不同的地址；Server端是直接放在公網(wǎng)上的，提供可以直接訪問的公網(wǎng)ip。當(dāng)Client-A和Client-B均分別與Server端連接建立之后，Client-A與Server端的UDP通道(即映射地址組)為(220.181.30.11:50001,14.215.178.179:60001)；Client-B與Server端的UDP通道為(220.181.30.11:50002,14.215.178.179:60002)。但是，此時(shí)做為對(duì)外服務(wù)的Server端，并不能直接為Client-A和Client-B服務(wù)，需增設(shè)一網(wǎng)關(guān)，例如，負(fù)載均衡網(wǎng)關(guān)，可以保證數(shù)據(jù)傳輸?shù)陌踩涂煽?。此時(shí)，Server端并不會(huì)直接暴露在公網(wǎng)上，而是部署在負(fù)載均衡網(wǎng)關(guān)之后，那么Server端所處的網(wǎng)絡(luò)并不同于Client端所處的NAT網(wǎng)絡(luò)，則由于負(fù)載均衡網(wǎng)關(guān)的存在，Client端與Server端之間傳送UDP數(shù)據(jù)采用以往的NAT網(wǎng)關(guān)穿透方法并不能直接使用。

現(xiàn)有技術(shù)為了解決上述技術(shù)問題提供的方案是：

在系統(tǒng)中增設(shè)網(wǎng)關(guān)之后，為了能繼續(xù)采用以往的NAT網(wǎng)關(guān)穿透方式，提供的方案一是：在Server端增設(shè)多個(gè)UDP端口，并網(wǎng)關(guān)上開辟多個(gè)UDP端口與Server端增設(shè)的端口一一對(duì)應(yīng)。但本方案對(duì)部署的網(wǎng)絡(luò)環(huán)境要求較高，例如，申請(qǐng)網(wǎng)關(guān)提供UDP端口的數(shù)目和Server端提供UDP端口的最大連接數(shù)均有限制，以及，網(wǎng)關(guān)提供如此多的外放開放端口，會(huì)有很大的安全隱患。以圖2為例，若采用以往的網(wǎng)關(guān)穿透方式傳送UDP數(shù)據(jù)，則需要在網(wǎng)關(guān)開辟兩個(gè)UDP端口，分別與Client-A與Server的UDP通道和Client-B與Server端的UDP通道一一對(duì)應(yīng)。如若僅在網(wǎng)關(guān)中設(shè)置一個(gè)UDP端口，雖然能夠避免前述在網(wǎng)關(guān)中增設(shè)多個(gè)UDP端口產(chǎn)生的問題，但無法采用以往的網(wǎng)關(guān)穿透方式傳送UDP數(shù)據(jù)。

進(jìn)而，提供方案二是：在系統(tǒng)中增設(shè)網(wǎng)關(guān)，并在網(wǎng)關(guān)設(shè)置一個(gè)UDP端口，并在Server端提供一個(gè)UDP端口。本方案是常規(guī)的Server端的實(shí)現(xiàn)方式，既可以解決在網(wǎng)關(guān)中僅設(shè)置一個(gè)UDP端口并采用以往的網(wǎng)關(guān)穿透方式傳送UDP數(shù)據(jù)，但是其存有兩個(gè)缺陷：其一，Server端需要支持對(duì)Webrtc Server的對(duì)接，實(shí)現(xiàn)復(fù)雜度較高；其二，不利于擴(kuò)展和修改Server端。

發(fā)明內(nèi)容