一種數據包傳輸方法和系統與流程
2023-12-08 22:49:46 2
本發明涉及網絡
技術領域：
：，尤其涉及一種數據包傳輸方法和系統。
背景技術：
：：隨著網際網路技術的不斷發展，各種應用程式如雨後春筍般密集湧現。為了提供更好的用戶體驗，針對應用程式的網絡加速服務也應運而生，以android應用代理加速為例，可以分為主動代理和被動代理兩種方式，主動代理是應用程式在發起網絡請求時主動進行代理加速，被動代理，又稱本地代理，是在系統層面通過某些手段將特定的請求數據包攔截至本地的加速服務程序，由本地代理程序做相應的加速控制後再將數據包重新發出去。現有的被動代理中，主要是通過添加重定向規則，將應用數據包重定向到代理程序來實現，但在某些實際應用中，發現僅僅依靠重定向規則可能無法區分待加速應用與經代理程序處理後發出的數據包，代理程序發出的數據包將會再次被重定向至代理程序，造成數據包在系統內死循環。技術實現要素：為了解決現有技術的問題，本發明實施例提供了一種數據包傳輸方法和系統。所述技術方案如下：一方面，一種數據包傳輸方法，所述方法包括：代理程序通過監聽埠接收請求數據包，為所述請求數據包設置標籤後，發送所述帶標籤的請求數據包；本地系統接收所述代理程序和所述應用程式發出的請求數據包，匹配所述請求數據包中的標籤，若匹配成功，則直接轉發所述請求數據包，若匹配失敗，則重定向所述請求數據包至所述代理程序監聽埠。進一步的，所述代理程序在為所述請求數據包設置標籤的同時，為所述標籤添加掩碼。進一步的，所述掩碼的取值範圍為0x8000000～0xfff00000。進一步的，所述本地系統版本為android5.0及其以上版本。進一步的，在所述代理程序發送所述帶標籤的請求數據包之前，所述代理程序判斷所述請求數據包是否需要進行加速，若需要則修改所述請求數據包的目的埠和目的ip地址至加速伺服器。進一步的，判斷所述請求數據包是否需要進行加速的方法包含：先白名單校驗，若校驗成功則所述請求數據包需要加速；若校驗失敗，則判斷所述請求數據包是否為http請求的數據包，如果是http，則根據url及預設規則判斷是否需要加速。進一步的，所述代理程序和所述應用程式運行在所述本地系統上。進一步的，所述本地系統內核為linux內核。另一方面，一種數據包傳輸系統，所述系統包括終端設備、加速伺服器和源站，所述終端設備的本地系統上運行有應用程式、代理程序；其中，所述代理程序通過監聽埠接收請求數據包，為所述請求數據包設置標籤後，發送所述帶標籤的請求數據包；本地系統接收所述代理程序和所述應用程式發出的請求數據包，匹配所述請求數據包中的標籤，若匹配成功，則直接轉發所述請求數據包至所述加速伺服器或所述源站，若匹配失敗，則重定向所述請求數據包至所述代理程序監聽埠。進一步的，所述代理程序在為所述請求數據包設置標籤的同時，為所述標籤添加掩碼。進一步的，所述掩碼的取值範圍為0x8000000～0xfff00000。進一步的，所述本地系統版本為android5.0及其以上版本。進一步的，在所述代理程序包含加速處理單元，在所述代理程序發送所述帶標籤的請求數據包之前，所述代理程序的加速處理單元，判斷所述請求數據包是否需要進行加速，若需要則修改所述請求數據包的目的埠和目的ip地址至加速伺服器。進一步的，所述代理程序的加速處理單元判斷所述請求數據包是否需要進行加速的方法包含：先白名單校驗，若校驗成功則所述請求數據包需要加速；若校驗失敗，則判斷所述請求數據包是否為http請求的數據包，如果是http，則根據url及預設規則判斷是否需要加速。進一步的，所述本地系統內核為linux內核。本發明實施例提供的技術方案帶來的有益效果是：本發明實施例的數據包傳輸方法，代理程序通過監聽埠接收請求數據包，為所述請求數據包設置標籤後，發送所述帶標籤的請求數據包；本地系統接收所述代理程序和所述應用程式發出的請求數據包，匹配所述請求數據包中的標籤，若匹配成功，則直接轉發所述請求數據包，若匹配失敗，則重定向所述請求數據包至所述代理程序監聽埠；對代理程序發送出去的數據包進行標籤設置，以使得本地系統可根據標籤區分來自應用和代理的請求數據包，並進行相應操作，避免數據包在本地的死循環。附圖說明為了更清楚地說明本發明實施例中的技術方案，下面將對實施例描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本發明的一些實施例，對於本領域普通技術人員來講，在不付出創造性勞動的前提下，還可以根據這些附圖獲得其他的附圖。圖1是本發明實施例一提供的一種數據包傳輸方法的流程圖；圖2是本發明實施例二提供的一種數據包傳輸方法的流程圖；圖3是本發明實施例三提供的一種數據包傳輸系統結構圖。具體實施方式為使本發明的目的、技術方案和優點更加清楚，下面將結合附圖對本發明實施方式作進一步地詳細描述。第一實施例參見圖1所示，本發明第一實施例提供一種數據包傳輸方法，該數據包傳輸方法中涉及代理程序、應用程式及本地系統，其中應用程式是為用戶提供具體業務服務的程序，例如瀏覽器、音樂視頻服務、及其他功能性服務程序，用戶通過對該些應用程式的操作來獲取相應的服務；代理程序對應用程式發出的請求數據包進行處理，以使得享受網絡加速服務的應用程式所發出的請求數據包能被轉發到加速伺服器；應用程式及代理程序均運行在本地系統上，本發明的實施例中，本地系統的內核為linux內核，可以是android系統，本實施例就是以android系統為例。本實施例中的數據包傳輸方法包括步驟a101～a103和步驟s101～s102，詳述如下。步驟a101：代理程序通過監聽埠接收請求數據包。如上所述，代理程序需要對應用程式發出的請求數據包進行處理，故在代理程序初始化時，設置專門的監聽埠，用於接收應用程式的請求數據包，例如，代理程序的監聽埠設置為8123。步驟a102：代理程序為所述請求數據包設置標籤。具體的，代理程序接收到請求數據包後通過創建代理socket，並使用linux的setsockopt函數對socket設置標籤，例如mark＝0x12345678。步驟a103：代理程序發送帶標籤的請求數據包。代理程序發送出的帶標籤的請求數據包將被本地系統接收。步驟s101：本地系統接收所述代理程序和所述應用程式發出的請求數據包。本發明的實施例中，本地系統為android系統，而android系統的內核為linux內核，眾所周知，netfilter是linux內核中的一個軟體框架，用於管理網絡數據包。iptables是基於netfilter基本架構實現的一個可擴展的的用戶層數據包管理工具，大部分linux系統都自帶iptables模塊，並通過它對網絡數據包進行過濾、攔截、重定向等操作，從而實現系統防火牆等功能，本發明的實施例中，也是通過iptables對代理程序和應用程式發出的請求數據包進行接收。步驟s102：匹配所述請求數據包中的標籤，若匹配成功，則直接轉發所述請求數據包，若匹配失敗，則重定向所述請求數據包至所述代理程序監聽埠。同樣的，本地系統通過設置iptablesmark標籤匹配規則和重定向規則，對數據包中的標籤進行匹配，若匹配成功，根據設置規則則直接轉發該請求數據包，若匹配失敗，則重定向該請求數據包至代理程序監聽埠。例如，設置iptablesmark標籤匹配規則、重定向規則如下：iptables-tnat-aoutput-mmark--mark0x12345678-jreturniptables-tnat-aoutput-ptcp-jredirect--to-port8123第一條規則的作用是當數據包具有mark＝0x12345678的標籤時，數據包不被重定向，以系統默認方式處理，否則執行第二條規則；第二條規則的作用是將數據包重定向至代理程序的監聽埠8123埠。如此一來，代理程序所發出的請求數據包均包含mark標籤，本地系統可通過mark標籤匹配來區分應用程式和代理程序，並進行分別處理，從而避免了
背景技術：
：中描述的死循環現象。可以理解的是，雖然本實施例的圖示中，步驟a103和s101之間是先後關係，但在實際應用中，步驟a101～a103為代理程序內部的執行步驟，而步驟s101～s102為本地系統內部執行的步驟，各步驟之間先後關係並非全部如此明確，故圖示僅用於對本實施例進行示意說明，本發明並不以此為限。更進一步的，本實施例中的數據包傳輸方法更包含步驟：代理程序判斷請求數據包是否需要進行加速，若需要則修改所述請求數據包的目的埠和目的ip地址至加速伺服器。如此一來，當本地系統接收到需要加速的請求數據包時，根據重定向規則，將會按照該請求數據包的目的埠和目的ip地址轉發該請求數據包至加速伺服器，加速伺服器為其提供相應的網絡加速服務。該步驟設置在步驟a103之前。具體而言，由於本地系統上可能安裝了多種應用程式，然而有些應用程式並沒有購買相應的加速服務，故代理程序應對需要加速的應用程式進行判斷，具體的判斷方法包含：先白名單校驗，若校驗成功則判斷所述請求數據包需要加速，其中所述白名單中保存了需要加速的應用程式包名信息；若校驗失敗，則判斷所述請求數據包是否為http請求的數據包，如果是http，則根據url及預設規則判斷是否需要加速。如此一來，可實現對應用程式的分類處理，只對需要加速的應用程式進行處理。第二實施例參見圖2所示，本發明第二實施例提供一種數據包傳輸方法，該數據包傳輸方法中涉及代理程序、應用程式及本地系統，其中應用程式是為用戶提供具體業務服務的程序，例如瀏覽器、音樂視頻服務、及其他功能性服務程序，用戶通過對該些應用程式的操作來獲取相應的服務；代理程序對應用程式發出的請求數據包進行處理，以使得享受網絡加速服務的應用程式所發出的請求數據包能被轉發到加速伺服器；應用程式及代理程序均運行在本地系統上，本發明的實施例中，本地系統的內核為linux內核，可以是android系統，本實施例就是以android系統為例。本實施例中的數據包傳輸方法包括步驟a201～a203和步驟s201～s202，詳述如下。步驟a201：代理程序通過監聽埠接收請求數據包。如上所述，代理程序需要對應用程式發出的請求數據包進行處理，故在代理程序初始化時，設置專門的監聽埠，用於接收應用程式的請求數據包，例如，代理程序的監聽埠設置為8123。步驟a202：代理程序為所述請求數據包設置標籤，並為所述標籤添加掩碼。具體的，代理程序接收到請求數據包後通過創建代理socket，並使用linux的setsockopt函數對socket設置標籤，並為該標籤添加掩碼，例如mark＝0x12345678/0xfff00000。步驟a203：代理程序發送帶掩碼標籤的請求數據包。代理程序發送出的帶標籤的請求數據包將被本地系統接收。步驟s201：本地系統接收所述代理程序和所述應用程式發出的請求數據包。本發明的實施例中，本地系統為android系統，而android系統的內核為linux內核，眾所周知，netfilter是linux內核中的一個軟體框架，用於管理網絡數據包。iptables是基於netfilter基本架構實現的一個可擴展的的用戶層數據包管理工具，大部分linux系統都自帶iptables模塊，並通過它對網絡數據包進行過濾、攔截、重定向等操作，從而實現系統防火牆等功能，本發明的實施例中，也是通過iptables對代理程序和應用程式發出的請求數據包進行接收。步驟s202：匹配所述請求數據包中的掩碼標籤，若匹配成功，則直接轉發所述請求數據包，若匹配失敗，則重定向所述請求數據包至所述代理程序監聽埠。同樣的，本地系統通過設置iptables掩碼標籤匹配規則和重定向規則，對數據包中的掩碼標籤進行匹配，若匹配成功，根據設置規則則直接轉發該請求數據包，若匹配失敗，則重定向該請求數據包至代理程序監聽埠。例如，設置iptables掩碼標籤匹配規則、重定向規則如下：iptables-tnat-aoutput-mmark--mark0x12345678/0xfff00000-jreturniptables-tnat-aoutput-ptcp-jredirect--to-port8123第一條規則的作用是當數據包具有mark＝0x12345678/0xfff00000的掩碼標籤時，數據包不被重定向，以系統默認方式處理，否則執行第二條規則；第二條規則的作用是將數據包重定向至代理程序的監聽埠8123埠。如此一來，代理程序所發出的請求數據包均包含mark標籤，本地系統可通過mark標籤匹配來區分應用程式和代理程序，並進行分別處理，從而避免了
背景技術：
：中描述的死循環現象。不僅如此，由於請求數據包中的標籤均帶有掩碼，可避免請求數據包在傳輸過程中，標籤被修改後無法正確匹配的問題，具體而言，在android5.0及其以上版本的系統中，系統中的netd會對數據包中的標籤進行篡改，若標籤中沒有增加掩碼，則無法正確進行匹配，經仔細研究發現，netd對於一個32bits的標籤的篡改，僅會影響其低20bits，故本實施例中，為標籤打上掩碼，並同時修改匹配規則，對未被篡改的部分進行匹配，從而避免了標籤被篡改後無法正確匹配的問題，相應的，在android5.0及其以上版本的系統中，掩碼的取值範圍為0x8000000～0xfff00000。可以理解的是，在一些其他版本的系統下，若符合相應規則，也可以根據本實施例的處理思路進行處理，本發明並不以此為限。可以理解的是，雖然本實施例的圖示中，步驟a203和s201之間是先後關係，但在實際應用中，步驟a201～a203為代理程序內部的執行步驟，而步驟s201～s202為本地系統內部執行的步驟，各步驟之間先後關係並非全部如此明確，故圖示僅用於對本實施例進行示意說明，本發明並不以此為限。更進一步的，本實施例中的數據包傳輸方法更包含步驟：代理程序判斷請求數據包是否需要進行加速，若需要則修改所述請求數據包的目的埠和目的ip地址至加速伺服器。如此一來，當本地系統接收到需要加速的請求數據包時，根據重定向規則，將會按照該請求數據包的目的埠和目的ip地址轉發該請求數據包至加速伺服器，加速伺服器為其提供相應的網絡加速服務。該步驟設置在步驟a203之前。具體而言，由於本地系統上可能安裝了多種應用程式，然而有些應用程式並沒有購買相應的加速服務，故代理程序應對需要加速的應用程式進行判斷，具體的判斷方法包含：先白名單校驗，若校驗成功則判斷所述請求數據包需要加速，其中所述白名單中保存了需要加速的應用程式包名信息；若校驗失敗，則判斷所述請求數據包是否為http請求的數據包，如果是http，則根據url及預設規則判斷是否需要加速。如此一來，可實現對應用程式的分類處理，只對需要加速的應用程式進行處理。第三實施例參見圖3所示，本發明第三實施例提供一種數據包傳輸系統，所述數據包傳輸系統包括終端設備、加速伺服器和源站，所述終端設備的本地系統上運行有應用程式、代理程序。具體而言，應用程式是為用戶提供具體業務服務的程序，例如瀏覽器、音樂視頻服務、及其他功能性服務程序，用戶通過對該些應用程式的操作來獲取相應的服務。應用程式接收用戶操作，並發出相應的請求數據包，該請求數據包將經過代理程序和本地系統，最終發送至加速伺服器或者源站進行回源，以響應用戶請求。代理程序對應用程式發出的請求數據包進行處理，以使得享受網絡加速服務的應用程式所發出的請求數據包能被轉發到加速伺服器。代理程序通過監聽埠接收請求數據包，為請求數據包設置標籤後，發送所述帶標籤的請求數據包。詳細而言，代理程序初始化時，設置專門的監聽埠，用於接收應用程式的請求數據包，例如，代理程序的監聽埠設置為8123。在接收到請求數據包後，通過創建代理socket，並使用linux的setsockopt函數對socket設置標籤，例如mark＝0x12345678。代理程序發送出的帶標籤的請求數據包將被本地系統接收。值得注意的是，在本發明的一些其他較佳實施例中，代理程序為請求數據包添加的標籤為帶有掩碼的標籤，例如mark＝0x12345678/0xfff00000，不僅可以實現標籤同樣的功能，還能防止在一些版本的系統中，標籤被篡改的而無法正確匹配的問題。例如在android5.0及其以上版本的系統中，系統中的netd會對數據包中的標籤進行篡改，若標籤中沒有增加掩碼，則無法正確進行匹配，經仔細研究發現，netd對於一個32bits的標籤的篡改，僅會影響其低20bits，故本實施例中，為標籤打上掩碼，並同時修改匹配規則，對未被篡改的部分進行匹配，從而避免了標籤被篡改後無法正確匹配的問題，相應的，在android5.0及其以上版本的系統中，掩碼的取值範圍為0x8000000～0xfff00000。可以理解的是，在一些其他版本的系統下，若符合相應規則，也可以根據本實施例的處理思路進行處理，本發明並不以此為限。代理程序在發送帶標籤的請求數據包之前，還需判斷請求數據包是否需要進行加速，若需要則修改所述請求數據包的目的埠和目的ip地址至加速伺服器。如此一來，當本地系統接收到需要加速的請求數據包時，根據重定向規則，將會按照該請求數據包的目的埠和目的ip地址轉發該請求數據包至加速伺服器，加速伺服器為其提供相應的網絡加速服務。而不需要加速的請求數據包將根據原始埠及ip地址被本地系統轉發至源站。具體而言，由於本地系統上可能安裝了多種應用程式，然而有些應用程式並沒有購買相應的加速服務，故代理程序應對需要加速的應用程式進行判斷，具體的判斷方法包含：先白名單校驗，若校驗成功則判斷所述請求數據包需要加速，其中所述白名單中保存了需要加速的應用程式包名信息；若校驗失敗，則判斷所述請求數據包是否為http請求的數據包，如果是http，則根據url及預設規則判斷是否需要加速。如此一來，可實現對應用程式的分類處理，只對需要加速的應用程式進行處理。本地系統接收所述代理程序和所述應用程式發出的請求數據包，匹配所述請求數據包中的標籤，若匹配成功，則直接轉發所述請求數據包至所述加速伺服器或所述源站，若匹配失敗，則重定向所述請求數據包至所述代理程序監聽埠。本發明的實施例中，本地系統為android系統，而android系統的內核為linux內核，眾所周知，netfilter是linux內核中的一個軟體框架，用於管理網絡數據包。iptables是基於netfilter基本架構實現的一個可擴展的的用戶層數據包管理工具，大部分linux系統都自帶iptables模塊，並通過它對網絡數據包進行過濾、攔截、重定向等操作，從而實現系統防火牆等功能，本發明的實施例中，也是通過iptables對代理程序和應用程式發出的請求數據包進行接收。同樣的，本地系統通過設置iptables標籤匹配規則和重定向規則，對數據包中的標籤進行匹配，若匹配成功，根據設置規則則直接轉發該請求數據包，若匹配失敗，則重定向該請求數據包至代理程序監聽埠，可以理解的是，在本發明的實施例中，本地系統在設置iptables標籤匹配規則時所設置的標籤與代理程序為請求數據包設置的標籤相同。以帶有掩碼的標籤為例，設置iptables標籤匹配規則、重定向規則如下：iptables-tnat-aoutput-mmark--mark0x12345678/0xfff00000-jreturniptables-tnat-aoutput-ptcp-jredirect--to-port8123第一條規則的作用是當數據包具有mark＝0x12345678/0xfff00000的掩碼標籤時，數據包不被重定向，以系統默認方式處理，否則執行第二條規則；第二條規則的作用是將數據包重定向至代理程序的監聽埠8123埠。如此一來，代理程序所發出的請求數據包均包含mark標籤，本地系統可通過mark標籤匹配來區分應用程式和代理程序，並進行分別處理，從而避免了
背景技術：
：中描述的死循環現象。不僅如此，由於請求數據包中的標籤均帶有掩碼，可避免請求數據包在傳輸過程中，標籤被修改後無法正確匹配的問題，具體而言，在android5.0及其以上版本的系統中，系統中的netd會對數據包中的標籤進行篡改，若標籤中沒有增加掩碼，則無法正確進行匹配，經仔細研究發現，netd對於一個32bits的標籤的篡改，僅會影響其低20bits，故本實施例中，為標籤打上掩碼，並同時修改匹配規則，對未被篡改的部分進行匹配，從而避免了標籤被篡改後無法正確匹配的問題，相應的，在android5.0及其以上版本的系統中，掩碼的取值範圍為0x8000000～0xfff00000。可以理解的是，在一些其他版本的系統下，若符合相應規則，也可以根據本實施例的處理思路進行處理，本發明並不以此為限。上述本發明實施例序號僅僅為了描述，不代表實施例的優劣。以上所描述的裝置實施例僅僅是示意性的，其中所述作為分離部件說明的單元可以是或者也可以不是物理上分開的，作為單元顯示的部件可以是或者也可以不是物理單元，即可以位於一個地方，或者也可以分布到多個網絡單元上。可以根據實際的需要選擇其中的部分或者全部模塊來實現本實施例方案的目的。本領域普通技術人員在不付出創造性的勞動的情況下，即可以理解並實施。通過以上的實施方式的描述，本領域的技術人員可以清楚地了解到各實施方式可藉助軟體加必需的通用硬體平臺的方式來實現，當然也可以通過硬體。基於這樣的理解，上述技術方案本質上或者說對現有技術做出貢獻的部分可以以軟體產品的形式體現出來，該計算機軟體產品可以存儲在計算機可讀存儲介質中，如rom/ram、磁碟、光碟等，包括若干指令用以使得一臺計算機設備(可以是個人計算機，伺服器，或者網絡設備等)執行各個實施例或者實施例的某些部分所述的方法。以上所述僅為本發明的較佳實施例，並不用以限制本發明，凡在本發明的精神和原則之內，所作的任何修改、等同替換、改進等，均應包含在本發明的保護範圍之內。當前第1頁12當前第1頁12