一種基于ecos 系統的強制門戶的內核實現方法及系統的制作方法
【專利摘要】本發明提供一種基于ECOS系統的強制門戶的內核實現方法，包括：服務器端與客戶端間模擬傳輸控制協議第一次握手；客戶端發送HTTP請求數據包；服務器端解析HTTP請求數據包，判斷HTTP請求數據包的數據端口號是否為默認端口號，若否，HTTP請求數據包轉發至橋轉發層；若是，判斷服務器端的強制門戶層中全局標志位是否置1，若是，HTTP請求數據包發送給橋轉發層；若否，HTTP請求數據包發送至強制門戶層；服務器端與客戶端間模擬傳輸控制協議第二和第三次握手；客戶端發送請求讀取由統一資源定位符所標志的信息的HTTP請求報文，強制門戶層丟棄HTTP請求報文，偽造并發送攜帶有200OK字段的主體消息的HTTP請求報文。本發明真正實現強制門戶功能，推送速度快，且用戶無需自行配置。
【專利說明】—種基于ECOS系統的強制門戶的內核實現方法及系統
【技術領域】
[0001]本發明屬于計算機網絡通信【技術領域】，涉及一種內核實現方法及系統，特別是涉及一種基于ECOS系統的強制門戶的內核實現方法及系統。
【背景技術】
[0002]隨著互聯網的發展，網絡應用、網絡業務迅速增加，用戶除了使用原來的互聯網瀏覽業務外，IPTV(網絡電視)，IP Phone (網絡電話)等其他業務也增加進來。隨著運營商業務的擴張，用戶所需要的設備配置工作也就越來越多，需要一種機制，方便用戶了解運營商的最新消息，同時也可以讓運營商作一些宣傳、廣告、通知等推送業務，或者讓用戶知道自己的接入設備的運行狀態。所謂推送業務，即運營商將強制門戶網站推送到用戶面前，讓用戶在首次訪問時，自動轉到強制門戶網站上，讓用戶了解一些重要信息、廣告、宣傳等等。
[0003]強制門戶是一種受限制的網絡連接，其中所有客戶端HTTP請求都重定向到提供商的站點。此網站然后可能提示用戶同意運營商的條款和條件、輸入付款信息或輸入憑據來驗證以前的付款協議，或者提供廣告和運營商的詳細信息。如果要在內核重定向客戶端的http請求,就要實現tcp模擬三次握手,與tcp的重傳機制和http消息偽造機制來實現用戶測的URL重定向。
[0004]而現有技術實現強制門戶功能是通過修改DNS域名解析模塊。例如，用戶需要訪問WWW.google, com網址，首先用戶接入設備的dnsproxy程序截獲該DNS查詢報文,如果用戶是第一次查詢，就返回強制門戶的IP地址，而不是應該返回的google網站的IP地址，這樣用戶瀏覽器顯示的就是強制門戶頁面。但這種方案的缺點是DNS只在做域名解析時候才能生效，如果用戶直接輸入IP地址訪問，就繞過了 DNS域名解析模塊，不能彈出強制門戶，無法真正實現強制門戶功能。
[0005]因而，如何提供一種基于ECOS系統的強制門戶的內核實現方法及系統，以解決現有技術中如果用戶直接輸入IP地址時則不能彈出強中門戶，無法真正實現強制門戶功能的缺陷，實已成為本領域從業者亟待解決的技術問題。
【發明內容】
[0006]鑒于以上所述現有技術的缺點，本發明的目的在于提供一種基于ECOS系統的強制門戶的內核實現方法及系統，用于解決現有技術中如果用戶直接輸入IP地址時則不能彈出強制門戶，無法真正實現強制門戶功能的問題。
[0007]為實現上述目的及其他相關目的，本發明一方面提供一種基于ECOS系統的強制門戶的內核實現方法，應用于包括客戶端和服務器端的基于嵌入式可配置操作系統的強制門戶的內核實現系統，所述基于ECOS系統的強制門戶的內核實現方法包括:步驟一，當用戶需訪問互聯網時，所述服務器端與所述客戶端之間模擬傳輸控制協議第一次握手以建立基于傳輸控制協議的通信鏈接；所述服務器端具有強制門戶層和橋轉發層；步驟二，所述客戶端發送HTTP請求數據包至所述服務器端；步驟三，所述服務器端解析所述HTTP請求數據包，判斷所述HTTP請求數據包的數據端口號是否為默認端口號；若所述數據端口號為默認端口號，則判斷所述服務器端的強制門戶層中全局標志位是否置1，若所述強制門戶層中全局標志位未置1，則將所述HTTP請求數據包發送至所述強制門戶層；步驟四，所述服務器端與所述客戶端之間模擬傳輸控制協議第二和第三次握手；步驟五，當所述服務器端與所述客戶端建立所述通信鏈接后，所述客戶端發送請求讀取由統一資源定位符所標志的信息的HTTP請求報文至所述強制門戶層，所述服務器端中所述強制門戶層丟棄該HTTP請求報文，偽造另一攜帶有200 OK字段的主體消息的HTTP請求報文，并發送至所述客戶端。
[0008]優選地，當判斷所述HTTP請求數據包的數據端口號不為默認端口號時，則將所述HTTP請求數據包轉發至所述橋轉發層。
[0009]優選地，當所述強制門戶層中全局標志位置I時，將所述HTTP請求數據包發送至所述橋轉發層。
[0010]優選地，所述模擬傳輸控制協議第二次握手的步驟包括:偽造第二傳輸控制協議報文，將所述第二傳輸控制協議報文中的標志字段置為同步報文和確認報文，將偽造的第二傳輸控制協議報文發送至所述客戶端以回復所述客戶端發送第一傳輸控制協議報文的同步報文，創建一定時器，判斷在超過所述定時器所規定的時間內所述客戶端是否回復關于接收到所述第二傳輸控制協議報文的確認報文，若否，則表不所述第二傳輸控制協議報文丟失，重新傳輸所述第二傳輸控制協議至所述客戶端；若是，則模擬傳輸控制協議第三次握手；所述模擬傳輸控制協議第三次握手的步驟包括:接收所述客戶端回復的關于接收到所述第二傳輸控制協議報文的確認報文，刪除所述定時器；所述強制門戶層在接收到所述客戶端回復的關于接收到所述第二傳輸控制協議報文的確認報文后，處于通信鏈接已建立狀態。
[0011]優選地，所述基于ECOS系統的強制門戶的內核實現方法還包括:所述強制門戶層還接收客戶端發送的第二傳輸控制協議報文的終止報文；所述強制門戶層在接收到所述客戶端回復關于接收到所述第二傳輸控制協議報文的確認報文或終止報文，偽造另一確認報文，將偽造的另一確認報文發送至所述客戶端以通知該次通信鏈接關閉。
[0012]優選地，統一資源定位符重定向所采用的是基于超文本標記語言的刷新和跳轉重定向技術。
[0013]優選地，所述主體消息攜帶格式為〈meta http-equiv = “refresh”content =“延時跳轉時間；url =運營商重定向URL/”>的超文本標記語言；若所述延時跳轉時間為0，表示立即跳轉；若所述延時跳轉時間大于10s，則表示正常應用，所述強制門戶層創建另一定時器，判斷在超過所述另一定時器所規定的時間內所述客戶端是否回復關于接收到所述攜帶有200 OK字段的主體消息的HTTP請求報文的確認報文，若是，則表示所述客戶端接收到所述攜帶有200 OK字段的主體消息的HTTP請求報文，并對所述攜帶有200 OK字段的主體消息的HTTP請求報文回復確認報文，所述強制門戶層接收到所述客戶端回復的確認報文，刪除所述另一定時器；若否，則重新傳輸所述攜帶有200 OK字段的主體消息的HTTP請求報文。
[0014]本發明另一方面還提供一種基于ECOS系統的強制門戶的內核實現系統，應用于嵌入式可配置操作系統，所述基于ECOS系統的強制門戶的內核實現系統包括:服務器端，包括強制門戶層和橋轉發層，用于當用戶需訪問互聯網時，與客戶端之間模擬傳輸控制協議第一次握手以建立基于傳輸控制協議的通信鏈接；當所述客戶端發送HTTP請求數據包至所述服務器端時，所述服務器端用于解析所述HTTP請求數據包，判斷所述HTTP請求數據包的數據端口號是否為默認端口號，若否，則將所述HTTP請求數據包轉發至所述橋轉發層；若是，則判斷所述服務器端的所述強制門戶層中全局標志位是否置1，若是，則把所述HTTP請求數據包發送至所述橋轉發層；若否，則將所述HTTP請求數據包發送至所述強制門戶層，模擬傳輸控制協議第二和第三次握手；當所述服務器端與所述客戶端建立所述通信鏈接后，所述客戶端發送請求讀取由統一資源定位符所標志的信息的HTTP請求報文至所述強制門戶層時，所述服務器端用于丟棄該HTTP請求報文，重新偽造另一攜帶有200 OK字段的主體消息的HTTP請求報文，并發送至所述客戶端。
[0015]優選地，所述強制門戶層用于:模擬傳輸控制協議第一次握手，所述強制門戶層接收所述客戶端發送的、用于請求與其建立基于傳輸控制協議的通信鏈接的第一傳輸控制協議報文，所述第一傳輸控制報文包括同步報文；其中，所述強制門戶層初始處于偵聽所述第一傳輸控制協議報文的偵聽狀態；在接收到所述同步報文后，所述強制門戶層處于同步報文已接收狀態；模擬傳輸控制協議第二次握手，偽造第二傳輸控制協議報文，將所述第二傳輸控制協議報文中的標志字段置為同步報文和確認報文，將偽造的第二傳輸控制協議報文回復至所述客戶端以回復所述客戶端發送第一傳輸控制協議報文的同步報文，創建一定時器，判斷在超過所述定時器所規定的時間內所述客戶端是否回復關于接收到所述第二傳輸控制協議報文的確認報文，若否，則表不所述第二傳輸控制協議報文丟失，重新傳輸所述第二傳輸控制協議至所述客戶端；若是，則模擬傳輸控制協議第三次握手；模擬傳輸控制協議第三次握手，接收所述客戶端回復的關于接收到所述第二傳輸控制協議報文的確認報文，刪除所述定時器；所述強制門戶層在接收到所述客戶端回復關于接收到所述第二傳輸控制協議報文的確認報文后，處于通信鏈接已建立狀態。
[0016]如上所述，本發明的基于ECOS系統的強制門戶的內核實現方法及系統，具有以下有益效果:
[0017]第一:所述基于ECOS系統的強制門戶的內核實現方法及系統從根本上解決了現有技術在用戶直接輸入IP地址訪問后，不能夠彈出強制門戶，真正實現了強制門戶功能；
[0018]第二:所述基于ECOS系統的強制門戶的內核實現方法及系統推送速度快，并且用戶無需自行配置。
【專利附圖】
【附圖說明】
[0019]圖1顯示為本發明的基于ECOS系統的強制門戶的內核實現方法的流程圖。
[0020]圖2顯示為本發明的基于ECOS系統的強制門戶的內核實現系統原理結構圖。
[0021]元件標號說明
[0022]I 基于ECOS系統的強制門戶的內核實現系統
[0023]11 服務器端
[0024]111 強制門戶層
[0025]112 橋轉發層
[0026]SI ?S9 步驟【具體實施方式】
[0027]以下通過特定的具體實例說明本發明的實施方式，本領域技術人員可由本說明書所揭露的內容輕易地了解本發明的其他優點與功效。本發明還可以通過另外不同的【具體實施方式】加以實施或應用，本說明書中的各項細節也可以基于不同觀點與應用，在沒有背離本發明的精神下進行各種修飾或改變。需說明的是，在不沖突的情況下，以下實施例及實施例中的特征可以相互組合。
[0028]需要說明的是，以下實施例中所提供的圖示僅以示意方式說明本發明的基本構想，遂圖式中僅顯示與本發明中有關的組件而非按照實際實施時的組件數目、形狀及尺寸繪制，其實際實施時各組件的型態、數量及比例可為一種隨意的改變，且其組件布局型態也可能更為復雜。
[0029]本發明的基本原理為:當用戶登錄互聯網web時，將請求的http報文發送給ADSL橋，由于這個http請求是基于tcp的,而本方案是在ecos的內核層實現的,所以本方案的強制門戶模塊首先要對用戶發送tcp的建立連接的數據包做模擬的三次握手，以建立tcp連接。然后用戶會發送http get請求，強制門戶模塊就丟棄這個get請求，然后置一個標志位，表示已經推送過強制頁面，然后仿造一個2000k的http包，http的body里面攜帶“〈HTMLXHEADXmeta http-equiv = \〃REFRESH\〃content = \〃0 ；URL =運營商推送網站的地址\〃>〈/HEADX/HTML>”，用戶收到這個200 OK的HTTP請求后，就會登錄運營商推送的網站。當用戶再次登錄互聯網web時，強制門戶模塊會判斷標志位是否置1，來實現不影響用戶上網功能。
[0030]實施例一
[0031]本實施例提供一種基于ECOS系統的強制門戶的內核實現方法，應用于包括客戶端和服務器端的基于嵌入式可配置操作系統的強制門戶的內核實現系統，請參閱圖1，顯示為基于ECOS系統的強制門戶的內核實現方法的流程圖，所述基于ECOS系統的強制門戶的內核實現方法包括:
[0032]SI，當用戶需訪問互聯網WEB時，所述服務器端與所述客戶端之間模擬傳輸控制協議第一次握手以建立基于傳輸控制協議的通信鏈接。所述服務器端具有強制門戶層和橋轉發層。步驟Si具體為:模擬傳輸控制協議第一次握手，所述服務器端中所述強制門戶層接收所述客戶端發送的、用于請求與其建立基于傳輸控制協議的通信鏈接的第一傳輸控制協議報文，所述第一傳輸控制協議報文包括同步報文；其中，所述強制門戶層初始處于偵聽所述第一傳輸控制協議報文的偵聽狀態；在接收到所述第一同步報文后，所述強制門戶層處于同步報文已接收狀態。
[0033]S2，所述客戶端發送HTTP請求數據包至所述服務器端。在本實施例中，所述HTTP請求數據包為網頁請求的數據包。
[0034]S3，所述服務器端解析所述HTTP請求數據包，并判斷所述HTTP請求數據包的數據端口號是否為默認端口號；即所述服務器端接收到所述第一傳輸控制協議報文后取出所述第一傳輸控制協議里的端口號字段，判斷該端口號字段是否為所述HTTP請求數據包的默認端口號(80端口)，若否，則執行步驟S4，即將所述HTTP請求數據包轉發至所述橋轉發層；若是，則繼續執行步驟S5。
[0035]S5，判斷所述服務器端的強制門戶層中全局標志位是否置1，若是，則表示所述用戶不是第一次上網，便返回步驟S4，即將所述HTTP請求數據包發送給所述橋轉發層；若否，則執行步驟S6。
[0036]S6，將所述HTTP請求數據包發送至所述強制門戶層，啟動強制門戶功能。
[0037]S7，所述服務器端與所述客戶端之間模擬傳輸控制協議第二次握手，具體地，所述強制門戶層偽造第二傳輸控制協議報文，將所述第二傳輸控制協議報文中的標志字段置為同步報文和確認報文，將偽造的第二傳輸控制協議報文發送至所述客戶端以回復所述客戶端發送的第一傳輸控制協議報文中的同步報文，創建一定時器，判斷在超過所述定時器所規定的時間內所述客戶端是否回復關于接收到所述第二傳輸控制協議報文的確認報文，若否，則表示所述第二傳輸控制協議報文丟失，重新傳輸所述第二傳輸控制協議至所述客戶端；若是，則執行S8S8，模擬傳輸控制協議第三次握手；
[0038]具體地，接收所述客戶端回復的關于接收所述第二傳輸控制協議報文的確認報文，刪除所述定時器。所述強制門戶層在接收到所述客戶端回復的關于所述第二傳輸控制協議報文的確認報文后，所述強制門戶層處于基于傳輸控制協議的通信鏈接已建立狀態。
[0039]S9，當所述服務器端與所述客戶端建立所述通信鏈接后，所述客戶端發送請求讀取由統一資源定位符所標志的信息的HTTP請求報文至所述強制門戶層，所述強制門戶層丟棄該HTTP請求報文，重新偽造另一攜帶有200 OK字段的主體消息的HTTP請求報文以實現URL(統一資源定位符重定向)，該HTTP請求報文的TCP段的標志位字段置為終止報文或確認報文，并將所述攜帶有200 OK字段的主體消息的HTTP請求報文發送至所述客戶端。統一資源定位符重定向所采用的是基于超文本標記語言的刷新和跳轉重定向技術。所述攜帶有2000K字段的主體消息中攜帶有如下超文本標記語音(HTML語音)。所述主體消息攜帶格式為〈meta http-equiv =“refresh”content =“延時跳轉時間；url =運營商重定向URL/”>的超文本標記語言。由于搜索引擎能夠讀取HTML語音，所以對于所述刷新和跳轉重定向技術，即自動跳轉法，搜索引擎能夠自動檢測出來。若所述延時跳轉時間為0，表示立即跳轉，若延時跳轉事件為0，就能被視為作弊，從而受到懲罰；若所述延時跳轉時間大于10s(—般為1s以上)，則表示正常應用，所述強制門戶層創建另一定時器，判斷在超過所述另一定時器所規定的時間內所述客戶端是否回復關于接收到所述攜帶200 OK字段的主體消息的HTTP請求報文的確認報文，若是，則表示所述客戶端接收到所述攜帶有200 OK字段的主體消息的HTTP請求報文，并對所述攜帶有200 OK字段的主體消息的HTTP請求報文回復確認報文，所述強制門戶層接收到所述客戶端回復的確認報文，刪除所述另一定時器；若否，則重新傳輸所述攜帶有200 OK字段的主體消息的HTTP請求報文。
[0040]S10，所述強制門戶層接收到客戶端發送的第二傳輸控制協議報文的終止報文；所述強制門戶層在接收到所述客戶端回復關于接收到所述第二傳輸控制協議報文的確認報文或終止報文后，偽造另一確認報文，將偽造的另一確認報文發送至所述客戶端以通知該次通信鏈接關閉。
[0041]本實施例所述的基于ECOS系統的強制門戶的內核實現方法從根本上解決了現有技術在用戶直接輸入IP地址訪問后，不能夠彈出強制門戶，真正實現了強制門戶功能，推送速度快，并且用戶無需自行配置。
[0042]實施例二
[0043]本實施例提供一種基于ECOS系統的強制門戶的內核實現系統1，應用于嵌入式可配置操作系統(ECOS系統)，請參閱圖2，顯示為基于ECOS系統的強制門戶的內核實現系統I的原理結構圖，所述基于ECOS系統的強制門戶的內核實現系統包括服務器端11和客戶端12，所述服務器端11包括強制門戶層111及橋轉發層112。在本實施例中，所述服務器端11為ADSL橋設備。而強制門戶層111及橋轉發層112位于在所述ADSL橋設備的內核中。
[0044]其中，所述服務器端11用于當用戶需訪問互聯網時，與所述客戶端12之間模擬傳輸控制協議第一次握手以建立基于傳輸控制協議的通信鏈接。模擬傳輸控制協議第一次握手，所述服務器端11中所述強制門戶層111接收所述客戶端12發送的、用于請求與其建立基于傳輸控制協議的通信鏈接的第一傳輸控制協議報文，所述第一傳輸控制協議報文包括同步報文；其中，所述強制門戶層111初始處于偵聽所述第一傳輸控制協議報文的偵聽狀態；在接收到所述第一同步報文后，所述強制門戶層處于同步報文已接收狀態。
[0045]所述客戶端12用于發送HTTP請求數據包至所述服務器端11。在本實施例中，所述HTTP請求數據包為網頁請求的數據包。
[0046]所述服務器端11當接收到所述HTTP請求數據包時用于解析所述HTTP請求數據包，判斷所述HTTP請求數據包的數據端口號是否為默認端口號，即所述服務器端11中強制門戶層111接收到所述第一傳輸控制協議報文后取出所述第一傳輸控制協議里的端口號字段，判斷該端口號字段是否為所述HTTP請求數據包的默認端口號(80端口)，若否，則將所述HTTP請求數據包轉發至所述橋轉發層112 ;若是，則判斷所述服務器端11的強制門戶層111中全局標志位是否置1，若是，則表示所述用戶不是第一次上網，便把所述HTTP請求數據包發送給所述橋轉發層112 ;若否，則將所述HTTP請求數據包發送至所述強制門戶層111，啟動強制門戶功能。
[0047]所述服務器端11中所述強制門戶層111還用于與所述客戶端之間模擬傳輸控制協議第二次握手，所述強制門戶層111偽造第二傳輸控制協議報文，將所述第二傳輸控制協議報文中的標志字段置為同步報文和確認報文，將偽造的第二傳輸控制協議報文發送至所述客戶端12以回復所述客戶端12發送的第一傳輸控制協議報文中的同步報文，創建一定時器，判斷在超過所述定時器所規定的時間內所述客戶端12是否回復關于接收到所述第二傳輸控制協議報文的確認報文，若否，則表不所述第二傳輸控制協議報文丟失，重新傳輸所述第二傳輸控制協議至所述客戶端12 ;若是，則模擬傳輸控制協議第三次握手；模擬傳輸控制協議第三次握手，接收所述客戶端12回復的關于接收所述第二傳輸控制協議報文的確認報文，刪除所述定時器。所述強制門戶層111在接收到所述客戶端12回復的關于所述第二傳輸控制協議報文的確認報文后，所述強制門戶層111處于基于傳輸控制協議的通信鏈接已建立狀態。
[0048]當所述服務器端11與所述客戶端12建立所述通信鏈接后，所述客戶端12還用于發送請求讀取由統一資源定位符所標志的信息的HTTP請求報文至所述服務器端11中的強制門戶層111。
[0049]所述服務器端11中所述強制門戶層111當所述客戶端12發送請求讀取由統一資源定位符所標志的信息的HTTP請求報文至所述服務器端11時，所述強制門戶層111丟棄該請求讀取由統一資源定位符所標志的信息的HTTP請求報文，重新偽造另一攜帶有200 OK字段的主體消息的HTTP請求報文以實現URL (統一資源定位符重定向)，該請求讀取由統一資源定位符所標志的信息的HTTP請求報文的TCP段的標志位字段置為終止報文或確認報文，并將所述攜帶有200 OK字段的主體消息的HTTP請求報文發送至所述客戶端12。統一資源定位符重定向所采用的是基于超文本標記語言的刷新和跳轉重定向技術。所述攜帶有200 OK字段的主體消息中攜帶有如下超文本標記語音(HTML語音)。所述主體消息攜帶格式為〈meta http-equiv = “refresh”content =“延時跳轉時間；url =運營商重定向 URL/”>的超文本標記語言。由于搜索弓I擎能夠讀取HTML語音，所以對于所述刷新和跳轉重定向技術，即自動跳轉法，搜索引擎能夠自動檢測出來。若所述延時跳轉時間為0，表示立即跳轉，若延時跳轉事件為0，就能被視為作弊，從而受到懲罰；若所述延時跳轉時間大于1s ( 一般為1s以上)，則表示正常應用，所述強制門戶層111創建另一定時器，判斷在超過所述另一定時器所規定的時間內所述客戶端12是否回復關于接收到所述攜帶有200 OK字段的主體消息的HTTP請求報文的確認報文，若是，則表示所述客戶端12接收到所述攜帶有200 OK字段的主體消息的HTTP請求報文，并對所述攜帶有200 OK字段的主體消息的HTTP請求報文回復確認報文，所述強制門戶層111接收到所述客戶端12回復的確認報文，刪除所述另一定時器；若否，則重新傳輸所述攜帶有200 OK字段的主體消息的HTTP請求報文。
[0050]所述服務器端11中所述強制門戶層111還用于接收所述客戶端12發送的第二傳輸控制協議報文的終止報文。所述強制門戶層111在接收到所述客戶端12回復關于接收到所述第二傳輸控制協議報文的確認報文或終止報文后，偽造另一確認報文，將偽造的另一確認報文發送至所述客戶端12以通知該次通信鏈接關閉。
[0051 ] 例如，用戶要訪問ffffff.GOOGLE.COM網址，通過本發明所述的基于ECOS系統的強制門戶的內核實現方法及系統，用戶瀏覽器顯示的就是運營商指定的強制門戶頁面給用戶，以方便用戶更多的了解運營商的最新消息，和一些重要的宣傳和廣告等業務。
[0052]綜上所述，本發明所述的基于ECOS系統的強制門戶的內核實現方法及系統從根本上解決了現有技術在用戶直接輸入IP地址訪問后，不能夠彈出強制門戶，真正實現了強制門戶功能，推送速度快，并且用戶無需自行配置。
[0053]所以，本發明有效克服了現有技術中的種種缺點而具高度產業利用價值。
[0054]上述實施例僅例示性說明本發明的原理及其功效，而非用于限制本發明。任何熟悉此技術的人士皆可在不違背本發明的精神及范疇下，對上述實施例進行修飾或改變。因此，舉凡所屬【技術領域】中具有通常知識者在未脫離本發明所揭示的精神與技術思想下所完成的一切等效修飾或改變，仍應由本發明的權利要求所涵蓋。
【權利要求】
1.一種基于ECOS系統的強制門戶的內核實現方法，應用于包括客戶端和服務器端的基于嵌入式可配置操作系統的強制門戶的內核實現系統，其特征在于，所述基于ECOS系統的強制門戶的內核實現方法包括: 步驟一，當用戶需訪問互聯網時，所述服務器端與所述客戶端之間模擬傳輸控制協議第一次握手以建立基于傳輸控制協議的通信鏈接；所述服務器端具有強制門戶層和橋轉發層； 步驟二，所述客戶端發送HTTP請求數據包至所述服務器端； 步驟三，所述服務器端解析所述HTTP請求數據包，判斷所述HTTP請求數據包的數據端口號是否為默認端口號；若所述數據端口號為默認端口號，則判斷所述服務器端的強制門戶層中全局標志位是否置1，若所述強制門戶層中全局標志位未置1，則將所述HTTP請求數據包發送至所述強制門戶層； 步驟四，所述服務器端與所述客戶端之間模擬傳輸控制協議第二和第三次握手； 步驟五，當所述服務器端與所述客戶端建立所述通信鏈接后，所述客戶端發送請求讀取由統一資源定位符所標志的信息的HTTP請求報文至所述強制門戶層，所述服務器端中所述強制門戶層丟棄該HTTP請求報文，偽造另一攜帶有200 OK字段的主體消息的HTTP請求報文，并發送至所述客戶端。
2.根據權利要求1所述的基于ECOS系統的強制門戶的內核實現方法，其特征在于:當判斷所述HTTP請求數據包的數據端口號不為默認端口號時，則將所述HTTP請求數據包轉發至所述橋轉發層。
3.根據權利要求1所述的基于ECOS系統的強制門戶的內核實現方法，其特征在于:當所述強制門戶層中全局標志位置I時，將所述HTTP請求數據包發送至所述橋轉發層。
4.根據權利要求1所述的基于ECOS系統的強制門戶的內核實現方法，其特征在于: 所述模擬傳輸控制協議第二次握手的步驟包括:偽造第二傳輸控制協議報文，將所述第二傳輸控制協議報文中的標志字段置為同步報文和確認報文，將偽造的第二傳輸控制協議報文發送至所述客戶端以回復所述客戶端發送第一傳輸控制協議報文的同步報文，創建一定時器，判斷在超過所述定時器所規定的時間內所述客戶端是否回復關于接收到所述第二傳輸控制協議報文的確認報文，若否，則表不所述第二傳輸控制協議報文丟失，重新傳輸所述第二傳輸控制協議至所述客戶端；若是，則模擬傳輸控制協議第三次握手； 所述模擬傳輸控制協議第三次握手的步驟包括:接收所述客戶端回復的關于接收到所述第二傳輸控制協議報文的確認報文，刪除所述定時器；所述強制門戶層在接收到所述客戶端回復的關于接收到所述第二傳輸控制協議報文的確認報文后，處于通信鏈接已建立狀態。
5.根據權利要求1所述的基于ECOS系統的強制門戶的內核實現方法，其特征在于:所述基于ECOS系統的強制門戶的內核實現方法還包括:所述強制門戶層還接收客戶端發送的第二傳輸控制協議報文的終止報文；所述強制門戶層在接收到所述客戶端回復關于接收到所述第二傳輸控制協議報文的確認報文或終止報文，偽造另一確認報文，將偽造的另一確認報文發送至所述客戶端以通知該次通信鏈接關閉。
6.根據權利要求1所述的基于ECOS系統的強制門戶的內核實現方法，其特征在于:統一資源定位符重定向所采用的是基于超文本標記語言的刷新和跳轉重定向技術。
7.根據權利要求1所述的基于ECOS系統的強制門戶的內核實現方法，其特征在于:所述主體消息攜帶格式為〈meta http-equiv =“refresh”content =“延時跳轉時間；url =運營商重定向URL/”>的超文本標記語言；若所述延時跳轉時間為0，表示立即跳轉；若所述延時跳轉時間大于10s，則表示正常應用，所述強制門戶層創建另一定時器，判斷在超過所述另一定時器所規定的時間內所述客戶端是否回復關于接收到所述攜帶有200 OK字段的主體消息的HTTP請求報文的確認報文，若是，則表示所述客戶端接收到所述攜帶有200 OK字段的主體消息的HTTP請求報文，并對所述攜帶有200 OK字段的主體消息的HTTP請求報文回復確認報文，所述強制門戶層接收到所述客戶端回復的確認報文，刪除所述另一定時器；若否，則重新傳輸所述攜帶有200 OK字段的主體消息的HTTP請求報文。
8.一種基于ECOS系統的強制門戶的內核實現系統，應用于嵌入式可配置操作系統，其特征在于，所述基于ECOS系統的強制門戶的內核實現系統包括: 服務器端，包括強制門戶層和橋轉發層，用于當用戶需訪問互聯網時，與客戶端之間模擬傳輸控制協議第一次握手以建立基于傳輸控制協議的通信鏈接；當所述客戶端發送HTTP請求數據包至所述服務器端時，所述服務器端用于解析所述HTTP請求數據包，判斷所述HTTP請求數據包的數據端口號是否為默認端口號，若否，則將所述HTTP請求數據包轉發至所述橋轉發層；若是，則判斷所述服務器端的所述強制門戶層中全局標志位是否置1，若是，則把所述HTTP請求數據包發送至所述橋轉發層；若否，則將所述HTTP請求數據包發送至所述強制門戶層，模擬傳輸控制協議第二和第三次握手； 當所述服務器端與所述客戶端建立所述通信鏈接后，所述客戶端發送請求讀取由統一資源定位符所標志的信息的HTTP請求報文至所述強制門戶層時，所述服務器端用于丟棄該HTTP請求報文，重新偽造另一攜帶有200 OK字段的主體消息的HTTP請求報文，并發送至所述客戶端。
9.根據權利要求8所述的基于ECOS系統的強制門戶的內核實現系統，其特征在于:所述強制門戶層用于: 模擬傳輸控制協議第一次握手，所述強制門戶層接收所述客戶端發送的、用于請求與其建立基于傳輸控制協議的通信鏈接的第一傳輸控制協議報文，所述第一傳輸控制報文包括同步報文；其中，所述強制門戶層初始處于偵聽所述第一傳輸控制協議報文的偵聽狀態；在接收到所述同步報文后，所述強制門戶層處于同步報文已接收狀態； 模擬傳輸控制協議第二次握手，偽造第二傳輸控制協議報文，將所述第二傳輸控制協議報文中的標志字段置為同步報文和確認報文，將偽造的第二傳輸控制協議報文回復至所述客戶端以回復所述客戶端發送第一傳輸控制協議報文的同步報文，創建一定時器，判斷在超過所述定時器所規定的時間內所述客戶端是否回復關于接收到所述第二傳輸控制協議報文的確認報文，若否，則表不所述第二傳輸控制協議報文丟失，重新傳輸所述第二傳輸控制協議至所述客戶端；若是，則模擬傳輸控制協議第三次握手； 模擬傳輸控制協議第三次握手，接收所述客戶端回復的關于接收到所述第二傳輸控制協議報文的確認報文，刪除所述定時器；所述強制門戶層在接收到所述客戶端回復關于接收到所述第二傳輸控制協議報文的確認報文后，處于通信鏈接已建立狀態。
【文檔編號】H04L29/08GK104038506SQ201410293134
【公開日】2014年9月10日 申請日期:2014年6月25日 優先權日:2014年6月25日
【發明者】龐駿 申請人:上海斐訊數據通信技術有限公司