歡迎光臨錦工風機官方網站。提供優(yōu)質羅茨鼓風機，羅茨風機，回轉式鼓風機，星型供料器，氣力輸送設備等產品
本發(fā)明屬于數(shù)據交換，尤其涉及一種基于網閘的文件交換的方法及系統(tǒng)。
背景技術：
網閘技術的需求來自內網與外網數(shù)據互通的要求，比如政府的電子政務是對公眾服務，與互聯(lián)網連通，而內網的政府辦公網絡，由于保密的要求，內網若與外網連通，則面臨來自公網的各種威脅。安全專家給出的建議是：由于目前的安全技術，無論防火墻、UTM等防護系統(tǒng)都不能保證攻擊的一定阻斷，入侵檢測等監(jiān)控系統(tǒng)也不能保證入侵行為完全捕獲，所以最安全的方式就是物理的分開，所以在公安部的技術要求中，要求電子政務的內、外網絡之間“物理隔離”。沒有連接，來自外網對內網的攻擊就無從談起。
但是，網絡的物理隔離，給數(shù)據的通訊帶來很多不便，比如工作人員出差只能接入互聯(lián)網，要取得內網的文件就沒有辦法，只能讓辦公室的人把文件放在外網上。另外，內網辦公系統(tǒng)需要從外網提供的統(tǒng)計數(shù)據，由于服務隔離，數(shù)據的獲取也很困難。因此，隨著網絡業(yè)務的日益成熟，數(shù)據交換的需求提議強烈。
綜上所述，現(xiàn)有技術存在的問題是：
網閘和應用系統(tǒng)之間不能通過TCP進行交流，只能將數(shù)據落地成文件，應用系統(tǒng)直接和網閘打交道會很不方便。
而如果內網辦公系統(tǒng)需要向外網提供統(tǒng)計數(shù)據等服務，由于協(xié)議的不支持，服務被隔離，數(shù)據的獲取很困難。而且，現(xiàn)有技術中，沒有通過與發(fā)送節(jié)點和接收節(jié)點連接，實現(xiàn)TCP協(xié)議跨網閘的數(shù)據傳輸。
本發(fā)明通過發(fā)送節(jié)點和接收節(jié)點處理與網閘之間的數(shù)據交換的工作，并對外開放使用TCP進行數(shù)據傳輸，使的應用系統(tǒng)可以方便的處理自己的業(yè)務邏輯而不用考慮網閘的數(shù)據交換的問題。同時在TCP基礎上可以實現(xiàn)支持HTTP等協(xié)議，更加方便面向服務的應用系統(tǒng)。
技術實現(xiàn)要素：
針對現(xiàn)有技術存在的問題，本發(fā)明提供了一種基于網閘的文件交換的方法及系統(tǒng)，
本發(fā)明是這樣實現(xiàn)的，一種基于網閘的文件交換方法包括：
步驟一：使用TCP協(xié)議連接發(fā)送節(jié)點監(jiān)聽的IP和端口，將數(shù)據發(fā)送給發(fā)送節(jié)點；
步驟二：將收到的數(shù)據分割成固定長度的塊，并編號，然后打包為特定格式的數(shù)據文件，并生成額外的控制信息保存到元信息文件中，將打包好的數(shù)據文件和元信息文件發(fā)送給網閘；
步驟三：網閘通過擺渡的形式將發(fā)送節(jié)點發(fā)來的文件發(fā)送到接收節(jié)點的指定文件夾；
步驟四：接收節(jié)點不斷掃描指定目錄，發(fā)現(xiàn)目錄中有新文件，則開始處理新文件；元信息文件不存在，則不做任何處理，等待下一次掃描；
步驟五：接收節(jié)點將數(shù)據還原后，通過讀取配置文件獲得目標應用系統(tǒng)的配置信息，然后連接目標應用系統(tǒng)，連接成功后，通過建立好的TCP連接將數(shù)據發(fā)送至應用系統(tǒng)。
進一步，步驟四具體包括：
接收節(jié)點不斷掃描指定目錄，發(fā)現(xiàn)目錄中有新文件，則開始處理新文件；如果元信息文件不存在，則不做任何處理，等待下一次掃描；如果元信息文件存在，則讀取元信息文件獲取數(shù)據文件的信息。然后判斷是否存在數(shù)據文件，如果數(shù)據文件不存在，則不做處理，等待下次掃描；如果數(shù)據文件存在，但是和元信息文件的信息不匹配，說明數(shù)據文件還沒傳輸完畢，則不做處理，等待下次掃描；如果數(shù)據文件和元信息匹配，則將數(shù)據文件解包還原。還原過程中會驗證文件傳輸?shù)耐暾院蜁r序性。
進一步，步驟五中，如果連接失敗，則重試，重試3次均失敗后，將數(shù)據文件和元信息文件進行備份，用于目標系統(tǒng)恢復后再使用，并記錄錯誤日志。
本發(fā)明的另一目的在于提供一種實現(xiàn)基于網閘的文件交換方法的計算機程序。
本發(fā)明的另一目的在于提供一種實現(xiàn)所述基于網閘的文件交換方法的信息數(shù)據處理終端。
本發(fā)明的另一目的在于提供一種計算機可讀存儲介質，包括指令，當其在計算機上運行時，使得計算機執(zhí)行所述的基于網閘的文件交換方法。
本發(fā)明的另一目的在于提供一種實現(xiàn)所述基于網閘的文件交換方法的基于網閘的文件交換的系統(tǒng)，所述基于網閘的文件交換系統(tǒng)包括：
應用系統(tǒng)、發(fā)送節(jié)點、網閘、接收節(jié)點；
應用系統(tǒng)：利用TCP與發(fā)送節(jié)點、接收節(jié)點連接；用于將數(shù)據發(fā)送給發(fā)送節(jié)點，從接收節(jié)點接收數(shù)據，在網閘之間“透明”地實現(xiàn)數(shù)據交換；
發(fā)送節(jié)點：與應用系統(tǒng)、網閘連接；用于接收系統(tǒng)發(fā)送的數(shù)據，并將數(shù)據打包為特定的格式文件，并生成額外的控制信息保存到文件中，將文件交給網閘；
網閘：與發(fā)送節(jié)點、接收節(jié)點連接；用于接收發(fā)送節(jié)點傳送的文件，并通過擺渡的形式將文件發(fā)送到接收節(jié)點的指定文件夾；
接收節(jié)點：與網閘、應用系統(tǒng)連接；用于掃描網閘發(fā)送到指定目錄的文件，讀取控制信息，獲取特定格式文件的元信息，保證文件傳輸?shù)耐暾院蜁r序性，并將特定格式的文件內容還原為數(shù)據，最后將數(shù)據發(fā)送給應用系統(tǒng)。
進一步，所述網閘包括：
網閘為內外網之間的隔離設備，網閘內嵌系統(tǒng)在物理隔離的情況下進行數(shù)據交換。
綜上所述，本發(fā)明的優(yōu)點及積極效果為：
本發(fā)明通過與發(fā)送節(jié)點和接收節(jié)點連接，實現(xiàn)TCP協(xié)議跨網閘的數(shù)據傳輸；基于TCP協(xié)議的數(shù)據交換，使內外網兩側文件交換感覺不到網閘的存在，“透明”地實現(xiàn)數(shù)據交換，保證文件傳輸過程中的完整性和時序性；應用系統(tǒng)不用考慮網閘的存在，只需要跟發(fā)送節(jié)點和接收節(jié)點打交道就能通過TCP協(xié)議傳輸數(shù)據，為應用系統(tǒng)對外服務提供一種可能。
而如果應用系統(tǒng)直接和網閘打交道，則應用系統(tǒng)需要做很大的改動將數(shù)據落地為文件，然后通過網閘交換文件，無疑增加了應用系統(tǒng)開發(fā)和使用的難度。通過本發(fā)明可以有效地解耦，讓應用系統(tǒng)不用考慮網閘的存在，只需要專注原有業(yè)務就行。
附圖說明
圖1是本發(fā)明實施例提供的基于網閘的文件交換系統(tǒng)結構示意圖。
圖2是本發(fā)明實施例提供的文件交換系統(tǒng)工作流程圖。
圖中：1、應用系統(tǒng)；2、發(fā)送節(jié)點；3、網閘；4、接收節(jié)點。
具體實施方式
為了使本發(fā)明的目的、技術方案及優(yōu)點更加清楚明白，以下結合實施例，對本發(fā)明進行進一步詳細說明。應當理解，此處所描述的具體實施例僅僅用以解釋本發(fā)明，并不用于限定本發(fā)明。
內網辦公系統(tǒng)需要從外網提供的統(tǒng)計數(shù)據，由于服務隔離，數(shù)據的獲取很困難。
而且，現(xiàn)有技術中，沒有通過與發(fā)送節(jié)點和接收節(jié)點連接，實現(xiàn)TCP協(xié)議跨網閘的數(shù)據傳輸。
為解決上述技術問題，下面結合具體方案對本發(fā)明的應用原理作詳細描述。
如圖1所示，本發(fā)明實施例提供的基于網閘的文件交換系統(tǒng)包括：
應用系統(tǒng)1、發(fā)送節(jié)點2、網閘3、接收節(jié)點4。
應用系統(tǒng)1：利用TCP與發(fā)送節(jié)點2、接收節(jié)點4連接；用于將數(shù)據發(fā)送給發(fā)送節(jié)點2，從接收節(jié)點4接收數(shù)據，在網閘3之間“透明”地實現(xiàn)數(shù)據交換。
發(fā)送節(jié)點2：與應用系統(tǒng)1、網閘3連接；用于接收應用系統(tǒng)1發(fā)送的數(shù)據，并將數(shù)據打包為特定的格式文件，并生成額外的控制信息保存到文件中，將文件傳送給網閘3。
網閘3：與發(fā)送節(jié)點2、接收節(jié)點4連接；用于接收發(fā)送節(jié)點2傳送的文件，并通過擺渡的形式將文件發(fā)送到接收節(jié)點4的指定文件夾。
接收節(jié)點4：與網閘3、應用系統(tǒng)1連接；用于掃描網閘3發(fā)送到指定目錄的文件，讀取控制信息，獲取特定格式文件的元信息，保證文件傳輸?shù)耐暾院蜁r序性，并將特定格式的文件內容還原為數(shù)據，并將數(shù)據發(fā)送給應用系統(tǒng)1。
本發(fā)明實施例提供的網閘3包括：
網閘3為內外網之間的隔離設備，網閘3內嵌系統(tǒng)可在物理隔離的情況下實現(xiàn)數(shù)據交換。
如圖2所示，本發(fā)明實施例提供的基于網閘的文件交換方法包括：在網閘兩側各部署一個交換節(jié)點，通過定時掃描指定的目錄，發(fā)送和接收網閘兩側的文件，實現(xiàn)了內外網之間文件交換。
具體包括：
S101：應用系統(tǒng)通過TCP將數(shù)據發(fā)送給發(fā)送節(jié)點。
S102：發(fā)送節(jié)點將數(shù)據打包為特定的格式文件，并生成額外的控制信息保存到文件中，將文件發(fā)送給網閘。
S103：網閘將發(fā)送節(jié)點發(fā)送的文件通過擺渡的形式將文件發(fā)送到接收節(jié)點的指定文件夾。
S104：接收節(jié)點掃描網閘發(fā)送至指定目錄的文件，讀取控制信息，獲取特定格式文件的元信息，保證文件傳輸?shù)耐暾院蜁r序性，并將特定格式的文件內容還原為數(shù)據。
S105：接收節(jié)點將還原后的數(shù)據傳送至應用系統(tǒng)。
步驟S104具體包括：
接收節(jié)點不斷掃描指定目錄，發(fā)現(xiàn)目錄中有新文件，則開始處理新文件；如果元信息文件不存在，則不做任何處理，等待下一次掃描；如果元信息文件存在，則讀取元信息文件獲取數(shù)據文件的信息。然后判斷是否存在數(shù)據文件，如果數(shù)據文件不存在，則不做處理，等待下次掃描；如果數(shù)據文件存在，但是和元信息文件的信息不匹配，說明數(shù)據文件還沒傳輸完畢，則不做處理，等待下次掃描；如果數(shù)據文件和元信息匹配，則將數(shù)據文件解包還原。還原過程中會驗證文件傳輸?shù)耐暾院蜁r序性。
步驟S105中接收節(jié)點將數(shù)據還原后，通過讀取配置文件獲得目標應用系統(tǒng)的配置信息，然后連接目標應用系統(tǒng)，連接成功后，通過建立好的TCP連接將數(shù)據發(fā)送至應用系統(tǒng)。
如果連接失敗，則重試，重試3次均失敗后，將數(shù)據文件和元信息文件進行備份，用于目標系統(tǒng)恢復后再使用，并記錄錯誤日志。
以上所述僅為本發(fā)明的較佳實施例而已，并不用以限制本發(fā)明，凡在本發(fā)明的精神和原則之內所作的任何修改、等同替換和改進等，均應包含在本發(fā)明的保護范圍之內。
來源:中關村在線 更新時間:2012-04-15
作為保證不同安全級別網絡間的高安全隔離與實時數(shù)據交換的安全設備，安全隔離網閘已經在公安、稅務等政府行業(yè)得到廣泛應用，另外，在電力、煤炭、鋼鐵等能源行業(yè)和一些制造型企業(yè)也開始大量應用。鑒于廣大用戶對網閘安全隔離功能的信賴，之前不敢連的網絡也通過安全隔離網閘連接起來了，同時，用戶還寄希望于安全隔離網閘能對數(shù)據內容進行高安全的檢查控制。
在保證安全的前提下，安全隔離網閘廠商也在盡力地滿足著用戶對安全隔離網閘支持更多網絡應用的需求，且已經取得了顯著的成效。當前，安全隔離網閘已由最初只支持文件交換功能（工作原理是模擬人工拷盤），發(fā)展到具有數(shù)據庫同步、數(shù)據庫訪問、郵件訪問、安全Web訪問、FTP訪問等多種功能，能對HTTP、FTP、SMTP、POP3等通用協(xié)議進行內容檢查，但是目前絕大部分用戶的應用采用的都是自定義格式的私有協(xié)議，如果沒有對安全隔離網閘實施二次開發(fā)，就無法對交換的數(shù)據內容進行過濾。這是因為私有協(xié)議的數(shù)據格式、數(shù)據內容等都沒有公開，導致安全隔離網閘廠商無法定義出相應的數(shù)據內容檢查規(guī)則，也就無法實現(xiàn)高安全的隔離交換控制。
為了應對通用安全隔離網閘無法對私有協(xié)議進行數(shù)據內容檢查的問題，安全隔離網閘廠商、用戶以及相關的主管部門都在積極尋找相應對策，目前，主要有以下兩種技術路線。
其一，重點實現(xiàn)電路級數(shù)據單向傳輸，并強化用戶認證功能。如通過國家電力調度通信中心的檢測認證，在電力行業(yè)廣泛應用的“單向橫向安全隔離裝置”，以及國家保密局正在認證，可以部署在電子政務中的“安全隔離與信息單向導入系統(tǒng)”等，但部署這些單向安全隔離網閘時，也需要將應用系統(tǒng)進行改造，另外，這些單向安全隔離網閘應用擴展能力差，只適合在特定行業(yè)內強制推行，無法應用于雙向數(shù)據交換、應用復雜的網絡環(huán)境。
技術路線之二則是與用戶的具體應用相結合，在雙向數(shù)據交換的網絡環(huán)境下實現(xiàn)對交換數(shù)據內容的檢查，在這方面，廣大安全隔離網閘廠商也在不斷進行研發(fā)投入。
當前，由于絕大部分用戶的應用都需要進行雙向數(shù)據傳輸，因此第二種技術路線將是安全隔離網閘發(fā)展的必由之路，按照第一種技術路線發(fā)展的單向安全隔離網閘，則會發(fā)展成為一類獨立的安全產品。
下面，我們就以聯(lián)想網御在第二種技術路線方面的研發(fā)探索為例，通過聯(lián)想網御對私有協(xié)議的數(shù)據內容檢查解決方案，具體說明安全隔離網閘與用戶的具體應用相結合是如何方便靈活地實現(xiàn)的。
科學的體系架構
a) 科學的系統(tǒng)架構
聯(lián)想網御安全隔離網閘的系統(tǒng)硬件平臺由內網主機系統(tǒng)、外網主機系統(tǒng)、隔離交換矩陣三部分組成：內網/外網主機系統(tǒng)分別具有獨立的運算單元和存儲單元，并以聯(lián)想網御自主知識產權的VSP （Versatile Security Platform，通用安全平臺）作為操作系統(tǒng)；隔離交換矩陣基于LeadASIC專用芯片技術及相應的時分多路隔離交換邏輯電路，不受主機系統(tǒng)控制，能獨立完成應用數(shù)據的封包、擺渡、拆包，從而實現(xiàn)內外網之間的數(shù)據隔離交換。主機系統(tǒng)對交換數(shù)據的檢查流程如下圖所示。安全隔離網閘在完成常規(guī)的IP地址、協(xié)議類型、協(xié)議分析等檢查后，還能在數(shù)據通過隔離交換矩陣封包之前進行數(shù)據內容的檢查。
聯(lián)想網御安全隔離網閘數(shù)據檢查流程圖
b) 檢查框架
VSP操作系統(tǒng)中集成的USE（Uniform Security Engine，統(tǒng)一安全引擎）完成了協(xié)議終結、應用內容的還原和檢查。聯(lián)想網御安全隔離網閘以自定義的、開放的ACI（Application Checking Interface，應用檢查接口）為基礎，不但支持內置的、面向通用應用協(xié)議（如HTTP、FTP等）的多種檢查模塊，還支持內容檢查模塊的擴展。用戶可以根據需要來自行開發(fā)內容檢查模塊，并通過安全隔離網閘的WEB管理界面上傳至VSP操作系統(tǒng)，通過使用內容檢查模塊，用戶可實現(xiàn)對基于私有協(xié)議的應用內容的數(shù)據格式、完整性、關鍵字、內容安全的檢查。
聯(lián)想網御安全隔離網閘內容檢查框架圖
清晰的分工合作
在研發(fā)上，考慮到只有用戶對私有協(xié)議的數(shù)據格式、數(shù)據內容等信息最清楚，聯(lián)想網御因此提出“分工負責，合作開發(fā)”的研發(fā)思路。
“分工負責”指的是用戶（或用戶指定的軟件開發(fā)商）負責內容檢查模塊的開發(fā)，聯(lián)想網御則負責在安全隔離網閘上提供ACI應用檢查接口和豐富的開發(fā)支撐文檔。
“合作開發(fā)”指的是聯(lián)想網御將積極配合用戶進行相應的檢查模塊調試，使用戶開發(fā)的檢查模塊能在安全隔離網閘上發(fā)揮效用。
方便的調用方式
對于加載的多個內容檢查模塊，聯(lián)想網御安全隔離網閘可以有選擇性地在安全規(guī)則中調用，并且可以對具體內容檢查模塊進行檢查內容的啟用或禁止，如圖三和圖四所示。
聯(lián)想網御安全隔離網閘管理界面的安全規(guī)則截圖
聯(lián)想網御安全隔離網閘管理界面的檢查內容定義截圖
豐富的文檔支撐
為了方便用戶進行內容檢查模塊的開發(fā)，聯(lián)想網御提供了ACI軟件開發(fā)包。此開發(fā)包中的內容包括：模塊與安全隔離網閘之間的非標準統(tǒng)一接口開發(fā)說明文檔，包括應用編程接口的庫、頭、幫助、例子等；生成檢查模塊的說明文檔，包括模塊開發(fā)工具的庫、頭、幫助、例子；強認證、加密開發(fā)說明文檔，基于此文檔開發(fā)可實現(xiàn)主機與安全隔離網閘間的用戶身份驗證、用戶訪問權限控制和數(shù)據傳輸加密功能。
在安全隔離網閘產品與用戶具體應用相結合方面，以成熟的理論體系為前提，聯(lián)想網御已經與某氣象局、某廣播電臺、某煤礦等多個行業(yè)客戶共同進行了成功的實踐。
物理隔離網閘是使用帶有多種控制功能的固態(tài)開關讀寫介質連接兩個獨立主機系統(tǒng)的信息安全設備。由于物理隔離網閘所連接的兩個獨立主機系統(tǒng)之間，不存在通信的物理連接、邏輯連接、信息傳輸命令、信息傳輸協(xié)議，不存在依據協(xié)議的信息包轉發(fā)，只有數(shù)據文件的無協(xié)議“擺渡”，且對固態(tài)存儲介質只有“讀”和“寫”兩個命令。所以，物理隔離網閘從物理上隔離、阻斷了具有潛在攻擊可能的一切連接，使“黑客”無法入侵、無法攻擊、無法破壞，實現(xiàn)了真正的安全。
網閘是在兩個不同安全域之間，通過協(xié)議轉換的手段，以信息擺渡的方式實現(xiàn)數(shù)據交換，且只有被系統(tǒng)明確要求傳輸?shù)男畔⒉趴梢酝ㄟ^。其信息流一般為通用應用服務。
注：網閘的“閘”字取自于船閘的意思，在信息擺渡的過程中內外網（上下游）從未發(fā)生物理連接，所以網閘產品必須要有至少兩套主機和一個物理隔離部件才可完成物理隔離任務。
隔離網閘的一個基本特征，就是內網與外網永遠不連接，內網和外網在同一時間最多只有一個同隔離設備建立數(shù)據連接（可以是兩個都不連接，但不能兩個都連接）。
目前網絡威脅中相當大的一部分來自與瀏覽器威脅，網閘對這種威脅有用嗎？以前不久的圖片文件漏洞來說，網閘是不會對這種應用層數(shù)據進行過濾的，那么，威脅依然存在。而對于提供對外服務的網絡，對其中應用進行攻擊的例子大多是構造一些正常（看起來）的數(shù)據包，這些漏洞，都是針對應用層的，網閘束手無策。所以，“真正的安全”是不可能的，沒有絕對的安全！
網閘的結構一般都采用2+1：內機+外機+不可編程硬件。早期網閘的交換模塊以電子開關的形式實現(xiàn)物理上的隔離，而電子開關由于切換速率問題，無法滿足實時數(shù)據交換需求，已經被邏輯開關取而代之。 從嚴格意義上說，邏輯開關只是實現(xiàn)邏輯上的隔離，而不是物理上的。
私有協(xié)議就是交換模塊傳輸數(shù)據的硬件讀寫協(xié)議，不同廠家的接口不同，如SCSI，1394等
1.工作模式
網閘的數(shù)據交換都是基于代理實現(xiàn)的。。
網閘按工作方式可以分為主動模式和被動模式。在主動模式下，網閘作為客戶端，往網絡中的服務器上讀寫數(shù)據；在被動模式下，網閘充當服務器的角色，在本地打開監(jiān)聽端口，，接收外界的數(shù)據。從安全上來說，主動模式遠大于被動模式，但應用和性能較差。
2.數(shù)據交換流程
以下是被動工作模式大概的一個數(shù)據交換過程：
外網接收數(shù)據包-〉檢查包頭信息-〉拆除包頭信息-〉提取并檢查應用層數(shù)據-〉按私有協(xié)議封裝數(shù)據-〉傳輸?shù)絻染W-〉封裝成網絡協(xié)議包-〉傳輸?shù)絻染W接收端
保證數(shù)據傳輸手段主要有以下兩種：
協(xié)議阻斷：網閘在傳輸接收到的數(shù)據包時，需拆除協(xié)議包頭信息，然后將應用層數(shù)據按私有協(xié)議重新封裝分片，這樣能保證所有網絡攻擊只能到達外網。
專有協(xié)議檢測模塊：網閘的數(shù)據傳輸都是基于應用層代理，對于支持的應用層協(xié)議，都有相應的傳輸模塊。每個模塊只處理對應的應用層數(shù)據請求，且根據協(xié)議的特性對數(shù)據本身進行內容檢測、過濾等操作，保證數(shù)據的安全性。
從網閘的系統(tǒng)架構以及工作模式可看出，它的性能是比不上防火墻的，包括吞吐，延時，尤其是并發(fā)數(shù)。如果有哪個廠家宣稱自己的產品能達到線速，那簡直就是告訴別人他家做的不是網閘。
技術領域：
本發(fā)明涉及計算機網絡
技術領域：
，具體涉及通過http實現(xiàn)跨越網閘進行Socket保持連接通信的方法及系統(tǒng)。
背景技術：
：在日常工作中有時會遇到需要將原本在網閘內的通過Socket連接的通信業(yè)務，需要改進為可以與互聯(lián)網上其他用戶進行交互的需求。通常情況下Socket連接就是TCP連接，Socket連接一旦建立，通信雙方即可開始相互發(fā)送數(shù)據內容，直到雙方連接斷開。但在實際網絡應用中，客戶端到服務器之間的通信往往需要穿越多個中間節(jié)點，例如路由器、網關、防火墻等，大部分防火墻默認會關閉長時間處于非活躍狀態(tài)的連接而導致Socket連接斷連，因此需要通過輪詢告訴網絡，該連接處于活躍狀態(tài)。而http連接使用的是“請求—響應”的方式，不僅在請求時需要先建立連接，而且需要客戶端向服務器發(fā)出請求后，服務器端才能回復數(shù)據。很多情況下，需要服務器端主動向客戶端推送數(shù)據，保持客戶端與服務器數(shù)據的實時與同步。此時若雙方建立的是Socket連接，服務器就可以直接將數(shù)據傳送給客戶端；若雙方建立的是http連接，則服務器需要等到客戶端發(fā)送一次請求后才能將數(shù)據傳回給客戶端。因此在Socket通信中實現(xiàn)http進行轉發(fā)具有十分大的困難。目前，通過http進行Socket通信的方法并不多，隨著業(yè)務的需要，更多的系統(tǒng)切實的需要這種技術來完成特定的業(yè)務需要。技術實現(xiàn)要素：鑒于上述問題，提出了本發(fā)明以便提供一種克服上述問題或者至少部分地解決上述問題的通過http實現(xiàn)跨越網閘進行Socket保持連接通信的方法及系統(tǒng)，目的在于提供一種能夠既實現(xiàn)通過http轉發(fā)請求實現(xiàn)跨越網閘、防火墻進行Socket通信的機制，又能保持整個通訊過程中Socket始終連接不斷。依據本發(fā)明的一個方面，提供了通過http實現(xiàn)跨越網閘進行Socket保持連接通信的方法，包括以下步驟：步驟（1）、第一服務器的第一端口接收客戶端發(fā)起的請求，將請求數(shù)據包以Socket通信的方式發(fā)送給第一服務器的第二端口；步驟（2）、所述第二端口接收到所述請求數(shù)據包后，建立一SocketChannel使得所述第二端口與第一服務器的第三端口之間建立不斷開的連接通道；步驟（3）、所述第三端口通過所述連接通道接收到所述請求數(shù)據包后，建立與第二服務器進行通信的http請求，將所述第二端口發(fā)送過來的所述請求數(shù)據包通過所述http請求發(fā)送給所述第二服務器的第四端口；步驟（4）、所述第二服務器上已經建立存儲映射表，所述第四端口接收到所述請求數(shù)據包后，判斷所述客戶端IP地址是否存在于所述存儲映射表中；步驟（5）、如果不存在，則建立一個新的與業(yè)務服務器的Socket連接，發(fā)送接收到的所述請求數(shù)據包，并將該Socket連接信息以IP地址為主鍵存儲在所述存儲映射表中；步驟（6）、如果存在，則通過所述IP地址從所述存儲映射表中取得已經存在的Socket連接，通過該Socket連接發(fā)送接收到的所述請求數(shù)據包；步驟（7）、所述業(yè)務服務器通過原路徑的通信方式將處理結果數(shù)據包返回到所述客戶端。進一步地，所述步驟（1）和步驟（2）之間還包括：所述第二端口對客戶端請求進行監(jiān)聽，一旦監(jiān)聽到客戶端請求連接后，啟動線程進行Socket通信。進一步地，所述步驟（2）中具體包括：所述第二端口接收到所述請求數(shù)據包后，發(fā)起一個與第一服務器的第三端口進行通信的新的Socket連接；使用NIO流建立一個SocketChannel模擬Socket通信，所述第二端口與第一服務器的第三端口之間建立不斷開的連接通道；將所述第二端口通過Socket通信發(fā)送的所述請求數(shù)據包和與所述第三端口進行通信的所述Socket連接進行綁定。進一步地，所述步驟（4）中的所述存儲映射表，通過客戶端IP地址作為主鍵，存儲不同的Socket連接信息。更進一步地，所述步驟（7）中具體包括：所述業(yè)務服務器通過與所述第四端口之間建立的Socket連接進行通信，將處理結果數(shù)據包返回到所述第四端口；所述第四端口接收到所述處理結果數(shù)據包后，通過http協(xié)議回應所述第三端口的http請求，發(fā)送所述處理結果數(shù)據包；所述第三端口接收到所述處理結果數(shù)據包后，通過所述SocketChannel建立的所述連接通道，將所述處理結果數(shù)據包以Socket通信的方式發(fā)送給所述第二端口；所述第二端口將所述處理結果數(shù)據包通過與所述第一端口之間建立的Socket連接返回到客戶端。依據本發(fā)明的另一個方面，提供了通過http實現(xiàn)跨越網閘進行Socket保持連接通信的系統(tǒng)，包括：客戶端、第一服務器、第二服務器和業(yè)務服務器，其中：所述第一服務器在網閘外，所述客戶端將請求數(shù)據包通過Socket方式發(fā)送給所述第一服務器，所述第一服務器將來自所述第二服務器的處理結果數(shù)據包通過Socket方式發(fā)送給所述客戶端；所述第二服務器在網閘內，已經建立存儲映射表，所述第一服務器與所述第二服務器之間采用http協(xié)議的方式進行通信，所述第一服務器將來自所述客戶端的所述請求數(shù)據包通過第一端口、第二端口和第三端口以http協(xié)議的方式發(fā)送給所述第二服務器的第四端口，所述第二端口建立一個SocketChannel模擬Socket通信，所述第二端口與所述第三端口之間建立不斷開的連接通道，所述第二服務器將來自業(yè)務服務器的所述處理結果數(shù)據包以http協(xié)議的方式發(fā)送給所述第一服務器；所述第二服務器與所述業(yè)務服務器之間采用Socket連接，所述第二服務器將接收的所述請求數(shù)據包發(fā)送給所述業(yè)務服務器，所述業(yè)務服務器對所述請求數(shù)據包進行處理，并將處理結果數(shù)據包通過Socket方式發(fā)送給所述第二服務器。進一步的，還包括一判斷模塊，所述第四端口通過所述http請求接收到所述請求數(shù)據包后，調用所述判斷模塊判斷所述客戶端IP地址是否存在于所述存儲映射表中；如果不存在，則建立一個新的與業(yè)務服務器的Socket連接，發(fā)送接收到的所述請求數(shù)據包，并將該Socket連接信息以IP地址為主鍵存儲在所述存儲映射表中；如果存在，則通過所述IP地址從所述存儲映射表中取得已經存在的Socket連接，通過該Socket連接發(fā)送接收到的所述請求數(shù)據包。進一步的，所述存儲映射表通過IP地址作為主鍵，存儲不同的Socket連接信息。進一步的，還包括一SocketChannel建立模塊，適用于所述第二端口接收到所述請求數(shù)據包后，發(fā)起一個與第一服務器的第三端口進行通信的新的Socket連接，所述SocketChannel建立模塊使用NIO流建立一個SocketChannel模擬Socket通信，所述第二端口與所述第三端口之間建立不斷開的連接通道，將所述第二端口通過Socket通信發(fā)送的所述請求數(shù)據包和與所述第三端口進行通信的所述Socket連接進行綁定。進一步的，所述第一服務器的第一端口、第二端口和第三端口分別為7007、4003和9999端口，所述第二服務器的第四端口為4002端口。本發(fā)明具有以下有益效果：本發(fā)明提出了通過http實現(xiàn)跨越網閘進行Socket保持連接通信的方法及系統(tǒng)，通過該方法與系統(tǒng)，可以將原本不跨越防火墻與網閘的客戶端與業(yè)務服務器進行Socket通信的系統(tǒng)，改造為互聯(lián)網上任意客戶端將請求數(shù)據包通過套接字發(fā)送給指定的網閘外第一服務器，第一服務器通過http協(xié)議將數(shù)據包發(fā)送給網閘內的第二服務器，第二服務器接收請求后，通過Socket連接發(fā)送給業(yè)務服務器，業(yè)務服務器再通過Socket連接返回處理結果，通過同樣的機制將數(shù)據包發(fā)送到網閘外的客戶端。此外，通過SocketChannel與存儲映射表使得每次通信都保證了Socket連接的同一性，即連接不中斷。上述說明僅是本發(fā)明技術方案的概述，為了能夠更清楚了解本發(fā)明的技術手段，而可依照說明書的內容予以實施，并且為了讓本發(fā)明的上述和其它目的、特征和優(yōu)點能夠更明顯易懂，以下特舉本發(fā)明的具體實施方式。附圖說明通過閱讀下文優(yōu)選實施方式的詳細描述，各種其他的優(yōu)點和益處對于本領域普通技術人員將變得清楚明了。說明書附圖僅用于示出優(yōu)選實施方式的目的，而并不認為是對本發(fā)明的限制。顯而易見地，下面描述的附圖僅僅是本發(fā)明的一些實施例，對于本領域普通技術人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據這些附圖獲得其他的附圖。而且在整個附圖中，用相同的參考符號表示相同的部件。在附圖中：圖1示出了根據本發(fā)明實施例一的通過http實現(xiàn)跨越網閘進行Socket保持連接通信的方法流程圖；圖2示出了根據本發(fā)明實施例二的通過http實現(xiàn)跨越網閘進行Socket保持連接通信的方法流程圖；具體實施方式下面將參照附圖更詳細地描述本公開的示例性實施例。雖然附圖中顯示了本公開的示例性實施例，然而應當理解，可以以各種形式實現(xiàn)本公開而不應被這里闡述的實施例所限制。相反，提供這些實施例是為了能夠更透徹地理解本公開，并且能夠將本公開的范圍完整的傳達給本領域的技術人員。需要說明的是，在說明書及權利要求當中使用了某些詞匯來指稱特定組件。本領域技術人員應可以理解，硬件制造商可能會用不同名詞來稱呼同一個組件。本說明書及權利要求并不以名詞的差異來作為區(qū)分組件的方式，而是以組件在功能上的差異來作為區(qū)分的準則。如在通篇說明書及權利要求當中所提及的“包含”或“包括”為一開放式用語，故應解釋成“包含但不限定于”。說明書后續(xù)描述為實施本發(fā)明的較佳實施方式，然所述描述乃以說明書的一般原則為目的，并非用以限定本發(fā)明的范圍。本發(fā)明的保護范圍當視所附權利要求所界定者為準。為便于對本發(fā)明實施例的理解，下面將結合附圖以幾個具體實施例為例做進一步的解釋說明，且各個附圖并不構成對本發(fā)明實施例的限定。實施例一、通過http實現(xiàn)跨越網閘進行Socket保持連接通信的方法。圖1為根據本發(fā)明實施例一的通過http實現(xiàn)跨越網閘進行Socket保持連接通信的方法流程圖，如圖1所示，本發(fā)明實施例包括以下步驟：步驟S101：第一服務器的第一端口接收客戶端發(fā)起的請求，將請求數(shù)據包以Socket通信的方式發(fā)送給第一服務器的第二端口；步驟S102：所述第二端口接收到所述請求數(shù)據包后，建立一SocketChannel使得所述第二端口與第一服務器的第三端口之間建立不斷開的連接通道；步驟S103：所述第三端口通過所述連接通道接收到所述請求數(shù)據包后，建立與第二服務器進行通信的http請求，將所述第二端口發(fā)送過來的所述請求數(shù)據包通過所述http請求發(fā)送給所述第二服務器的第四端口；步驟S104：所述第二服務器上已經建立存儲映射表，所述第四端口接收到所述請求數(shù)據包；步驟S105：判斷所述客戶端IP地址是否存在于所述存儲映射表中；如果不存在，則進入下一步，反之跳轉到步驟S107；步驟S106：則建立一個新的與業(yè)務服務器的Socket連接，發(fā)送接收到的所述請求數(shù)據包，并將該Socket連接信息以IP地址為主鍵存儲在所述存儲映射表中；步驟S107：如果存在，則通過所述IP地址從所述存儲映射表中取得已經存在的Socket連接，通過該Socket連接發(fā)送接收到的所述請求數(shù)據包；步驟S108：所述業(yè)務服務器通過原路徑的通信方式將處理結果數(shù)據包返回到所述客戶端。本發(fā)明實施例中優(yōu)選的，所述步驟S101和步驟S102之間還包括：所述第二端口對客戶端請求進行監(jiān)聽，一旦監(jiān)聽到客戶端請求連接后，啟動線程進行Socket通信。本發(fā)明實施例中優(yōu)選的，所述步驟S102具體包括：所述第二端口接收到所述請求數(shù)據包后，發(fā)起一個與第一服務器的第三端口進行通信的新的Socket連接；使用NIO流建立一個SocketChannel模擬Socket通信，所述第二端口與第一服務器的第三端口之間建立不斷開的連接通道；將所述第二端口通過Socket通信發(fā)送的所述請求數(shù)據包和與所述第三端口進行通信的所述Socket連接進行綁定。本發(fā)明實施例中優(yōu)選的，所述步驟S104中的所述存儲映射表，通過客戶端IP地址作為主鍵，存儲不同的Socket連接信息。本發(fā)明實施例中優(yōu)選的，所述步驟S107中具體包括：所述業(yè)務服務器通過與所述第四端口之間建立的Socket連接進行通信，將處理結果數(shù)據包返回到所述第四端口；所述第四端口接收到所述處理結果數(shù)據包后，通過http協(xié)議回應所述第三端口的http請求，發(fā)送所述處理結果數(shù)據包；所述第三端口接收到所述處理結果數(shù)據包后，通過所述SocketChannel建立的所述連接通道，將所述處理結果數(shù)據包以Socket通信的方式發(fā)送給所述第二端口；所述第二端口將所述處理結果數(shù)據包通過與所述第一端口之間建立的Socket連接返回到客戶端。本發(fā)明實施例所述方法實現(xiàn)了跨越網閘進行Socket通信，通過在網閘的內外設有第一服務器與第二服務器。第一服務器在網閘外，主要負責接收互聯(lián)網中任意客戶端發(fā)起的業(yè)務請求，并且使用http協(xié)議將該請求數(shù)據包發(fā)送到網閘內的第二服務器，因此首先需要所述第一服務器能夠被運行通過網閘進行通信。所述第一服務器將客戶端Socket連接通信的所述請求數(shù)據包，通過http協(xié)議發(fā)送到網閘內所述第二服務器，需要三個端口，分別為7007即所述第一端口，4003即所述第二端口和9999即所述第三端口。第二服務器在網閘內，主要負責接收所述第一服務器發(fā)送的http請求數(shù)據包，然后通過Socket連接的方式將所述請求數(shù)據包發(fā)送給業(yè)務服務器，業(yè)務服務器進行處理后，將處理結果數(shù)據包通過Socket連接發(fā)送給第二服務器，第二服務器以Socket連接方式接收到數(shù)據后，再通過http請求的形式，發(fā)送到外網的所述第一服務器。通過http協(xié)議，實現(xiàn)了跨越網閘，提供了客戶端與業(yè)務服務器的通信通道，第二服務器需要一個端口，為4002即所述第四端口。7007端口即所述第一端口主要是接受互聯(lián)網上任意客戶端的請求，然后將請求數(shù)據包以Socket通信的方式發(fā)送給4003端口即所述第二端口。4003端口即所述第二端口對客戶端請求進行監(jiān)聽，一旦客戶端請求連接，所述4003端口即所述第二端口就啟動線程，進行Socket通信。接收到所述請求數(shù)據包后，首先發(fā)起一個與9999端口即所述第三端口進行通信的新的Socket連接，然后使用NIO流，建立一個SocketChannel，使用該類模擬Socket通信，建立4003端口即所述第二端口到9999端口即所述第三端口不斷開的連接通道，非同步，一次只處理一次連接通信，將4003端口即所述第二端口通過Socket通信發(fā)送的數(shù)據包和與9999端口即所述第三端口進行通信的Socket連接進行綁定。9999端口即所述第三端口通過所述連接通道，以流的形式接收到Socket通信方式發(fā)送的所述請求數(shù)據包后，建立與第二服務器進行通信的http請求，將4003端口即所述第二端口發(fā)來的數(shù)據流通過http請求發(fā)送給第二服務器的4002端口即所述第四端口。在所述第二服務器上，已經建立了一個HashMap（即所述的存儲映射表），該類中通過IP地址作為主鍵，存儲不同的Socket連接信息。4002端口即所述第四端口通過http請求的形式接受到數(shù)據流后，首先判斷客戶端IP地址是否存在于HashMap中，如果不存在，則建立一個新的與業(yè)務服務器的Socket通信連接，發(fā)送接收到的數(shù)據流，并將該Socket連接信息以IP地址為主鍵存儲在HashMap中。如果發(fā)送請求的客戶端IP地址已經存在于HashMap中，則通過IP地址從HashMap取得已經存在的Socket連接，通過該連接發(fā)送接收到的數(shù)據流。所述HashMap是基于哈希表的Map接口的實現(xiàn)。此實現(xiàn)提供所有可選的映射操作，并允許使用null值和null鍵。（除了非同步和允許使用null之外，HashMap類與Hashtable大致相同。）此類不保證映射的順序，特別是它不保證該順序恒久不變。此實現(xiàn)假定哈希函數(shù)將元素適當?shù)胤植荚诟魍爸g，可為基本操作（get和put）提供穩(wěn)定的性能。迭代collection視圖所需的時間與HashMap實例的“容量”（桶的數(shù)量）及其大小（鍵-值映射關系數(shù)）成比例。所以，如果迭代性能很重要，則不要將初始容量設置得太高（或將加載因子設置得太低）。業(yè)務服務器通過與4002端口即所述第四端口建立的Socket連接進行通信，將處理結果返回給4002端口即所述第四端口，4002端口即所述第四端口接收到數(shù)據后，通過http協(xié)議回應9999端口即所述第三端口的http請求，發(fā)送處理結果數(shù)據包。9999端口即所述第三端口接收到處理結果數(shù)據包后，通過SocketChannel連接通道，將處理結果以Socket通信的方式發(fā)送給4003端口即所述第二端口，4003端口即所述第二端口將數(shù)據通過與7007端口即所述第一端口之間建立的Socket連接返回給客戶端。需要說明的是，本發(fā)明實施例中采用的所述第一服務器的第一端口、第二端口和第三端口分別為7007、4003和9999端口，所述第二服務器的第四端口為4002端口，但實際操作中，所述端口可以是任意的，只要是能夠通信正常的端口即可。本發(fā)明實施例中采用了HashMap來實現(xiàn)所述存儲映射表，同樣的，所述HashMap也不是唯一的實現(xiàn)方案，只要是通過唯一的key（這里指客戶端IP地址）可以映射唯一存儲內容（這里指socket連接信息）的實現(xiàn)方案均可。上述過程經歷了若干次Socket連接與http請求的轉換，但是客戶端與業(yè)務服務器仍然保證了通過Socket通信的方式發(fā)送與接收數(shù)據，并且通過SocketChannel與HashMap使得每次通信都保證了Socket連接的同一性，即連接不中斷。實施例二、通過http實現(xiàn)跨越網閘進行Socket保持連接通信的方法。圖2為根據本發(fā)明實施例二的通過http實現(xiàn)跨越網閘進行Socket保持連接通信的方法流程圖，包括以下步驟：步驟S201：第一服務器的第一端口接收客戶端發(fā)起的請求，將請求數(shù)據包以Socket通信的方式發(fā)送給第一服務器的第二端口；步驟S202：所述第二端口對客戶端請求進行監(jiān)聽，監(jiān)聽到客戶端請求連接后，啟動線程進行Socket通信；步驟S203：所述第二端口接收到所述請求數(shù)據包后，發(fā)起一個與第一服務器的第三端口進行通信的新的Socket連接，使用NIO流建立一個SocketChannel模擬Socket通信，所述第二端口與所述第三端口之間建立不斷開的連接通道，將所述第二端口通過Socket通信發(fā)送的所述請求數(shù)據包和與所述第三端口進行通信的所述Socket連接進行綁定；步驟S204：所述第三端口通過所述連接通道接收到所述請求數(shù)據包后，建立與第二服務器進行通信的http請求，將所述第二端口發(fā)送過來的所述請求數(shù)據包通過所述http請求發(fā)送給所述第二服務器的第四端口；步驟S205：所述第二服務器上已經建立存儲映射表，其中所述存儲映射表通過IP地址作為主鍵，存儲不同的Socket連接信息，所述第四端口通過所述http請求接收到所述請求數(shù)據包；步驟S206：判斷所述客戶端IP地址是否存在于所述存儲映射表中；如果不存在，則進入下一步，反之，跳轉到步驟S208；步驟S207：則建立一個新的與業(yè)務服務器的Socket連接，發(fā)送接收到的所述請求數(shù)據包，并將該Socket連接信息以IP地址為主鍵存儲在所述存儲映射表中；步驟S208：則通過所述IP地址從所述存儲映射表中取得已經存在的Socket連接，通過該Socket連接發(fā)送接收到的所述請求數(shù)據包；步驟S209：所述業(yè)務服務器通過與所述第四端口之間建立的Socket連接進行通信，將處理結果數(shù)據包返回到所述第四端口；步驟S210：所述第四端口接收到所述處理結果數(shù)據包后，通過http協(xié)議回應所述第三端口的http請求，發(fā)送所述處理結果數(shù)據包；步驟S211：所述第三端口接收到所述處理結果數(shù)據包后，通過所述SocketChannel建立的所述連接通道，將所述處理結果數(shù)據包以Socket通信的方式發(fā)送給所述第二端口；步驟S212：所述第二端口將所述處理結果數(shù)據包通過與所述第一端口之間建立的Soket連接返回到客戶端。實施例三、通過http實現(xiàn)跨越網閘進行Socket保持連接通信的系統(tǒng)。下面對本發(fā)明實施例三的系統(tǒng)進行詳細說明。本發(fā)明實施例三的通過http實現(xiàn)跨越網閘進行Socket保持連接通信的系統(tǒng)包括：客戶端、第一服務器、第二服務器和業(yè)務服務器，所述第一服務器和所述第二服務器之間存在網閘，其中：所述第一服務器在網閘外，所述客戶端將請求數(shù)據包通過Socket方式發(fā)送給所述第一服務器，所述第一服務器將來自所述第二服務器的處理結果數(shù)據包通過Socket方式發(fā)送給所述客戶端；所述第二服務器在網閘內，已經建立存儲映射表，所述第一服務器與所述第二服務器之間采用http協(xié)議的方式進行通信，所述第一服務器將來自所述客戶端的所述請求數(shù)據包通過第一端口、第二端口和第三端口以http協(xié)議的方式發(fā)送給所述第二服務器的第四端口，所述第二端口建立一個SocketChannel模擬Socket通信，所述第二端口與所述第三端口之間建立不斷開的連接通道，所述第二服務器將來自業(yè)務服務器的所述處理結果數(shù)據包以http協(xié)議的方式發(fā)送給所述第一服務器；所述第二服務器與所述業(yè)務服務器之間采用Socket連接，所述第二服務器將接收的所述請求數(shù)據包發(fā)送給所述業(yè)務服務器，所述業(yè)務服務器對所述請求數(shù)據包進行處理，并將處理結果數(shù)據包通過Socket方式發(fā)送給所述第二服務器。本發(fā)明實施例中優(yōu)選的，還包括一判斷模塊，所述第四端口通過所述http請求接收到所述請求數(shù)據包后，調用所述判斷模塊判斷所述客戶端IP地址是否存在于所述存儲映射表中；如果不存在，則建立一個新的與業(yè)務服務器的Socket連接，發(fā)送接收到的所述請求數(shù)據包，并將該Socket連接信息以IP地址為主鍵存儲在所述存儲映射表中；如果存在，則通過所述IP地址從所述存儲映射表中取得已經存在的Socket連接，通過該Socket連接發(fā)送接收到的所述請求數(shù)據包。本發(fā)明實施例中優(yōu)選的，所述存儲映射表通過IP地址作為主鍵，存儲不同的Socket連接信息。本發(fā)明實施例中優(yōu)選的，還包括一SocketChannel建立模塊，適用于所述第二端口接收到所述請求數(shù)據包后，發(fā)起一個與第一服務器的第三端口進行通信的新的Socket連接，所述SocketChannel建立模塊使用NIO流建立一個SocketChannel模擬Socket通信，所述第二端口與所述第三端口之間建立不斷開的連接通道，將所述第二端口通過Socket通信發(fā)送的所述請求數(shù)據包和與所述第三端口進行通信的所述Socket連接進行綁定。本發(fā)明實施例中優(yōu)選的，所述第一服務器的第一端口、第二端口和第三端口分別為7007、4003和9999端口，所述第二服務器的第四端口為4002端口。目前的客戶端與服務器之間一般采用套接字Socket方式進行網絡通信。使用Socket的通信方式，傳輸速度一般比較快和穩(wěn)定，但是在很多網絡環(huán)境尤其是內部網絡中都設置了網閘，只允許使用基本端口，如網絡瀏覽端口80，其他端口不允許使用，如即時通信的聊天端口8000，在這種情況下，不能用傳輸控制協(xié)議TCP或者用戶數(shù)據報協(xié)議UDP與服務器進行直接連接。客戶端將請求數(shù)據包通過套接字Socket連接發(fā)送給第一服務器；所述第一服務器以Socket方式接收所述請求數(shù)據包，并將所述請求數(shù)據包以http協(xié)議的方式發(fā)送給第二服務器；所述第二服務器以http協(xié)議的方式接收所述請求數(shù)據包，并通過與業(yè)務服務器之間的套接字Socket連接將所述請求數(shù)據包發(fā)送給所述業(yè)務服務器；所述業(yè)務服務器對接收的所述請求數(shù)據包進行處理，將處理結果的返回數(shù)據包通過與所述第二服務器之間的套接字Socket連接發(fā)送給所述第二服務器；所述第二服務器以Socket方式接收所述返回數(shù)據包，并以http協(xié)議的方式將所述返回數(shù)據包發(fā)送給所述第一服務器；所述第一服務器以http協(xié)議的方式接收所述返回數(shù)據包，并通過與所述客戶端之間的套接字Socket連接將所述返回數(shù)據包發(fā)送給所述客戶端。其中，所述第一服務器與所述第二服務器之間采用http協(xié)議的POST方法或者http協(xié)議的GET方法傳送數(shù)據。對于只能使用Socket方式通信的客戶端和服務器，當通過互聯(lián)網連接時，通過Socket與http之間的協(xié)議轉換，可以實現(xiàn)采用Socket方式連接的客戶端和業(yè)務服務器穿透網閘通信。其中，客戶端為可以遠程訪問第一服務器的軟件模塊或硬件設備；第一服務器是一個可以保持Socket連接，并且可以發(fā)起http請求、接收http響應返回的外網應用軟件模塊；第二服務器是一個可以接收和響應http請求，并且可以保持Socket連接的內網應用軟件模塊；業(yè)務服務器為完成業(yè)務邏輯的軟件模塊或硬件設備，其可以通過JMS（JavaMessageService，Java消息服務）應用程序接口進行通信。其中，具體的實施細節(jié)如上述方法中所述，在此不再贅述。本發(fā)明提出了通過http實現(xiàn)跨越網閘進行Socket保持連接通信的方法及系統(tǒng)，以前只支持在同一網閘內通過Socket連接進行通信，從而完成業(yè)務需要，通過本發(fā)明所述方法及系統(tǒng)，能夠提供互聯(lián)網上任意用戶跨越網閘與防火墻進行Socket通信，并且通信過程中，保證同一IP地址客戶端發(fā)起的Socket請求也是同一的，同時不需要對原系統(tǒng)進行全面的改造，節(jié)省了研發(fā)改造成本。本領域普通技術人員可以理解：附圖只是一個實施例的示意圖，附圖中的模塊或流程并不一定是實施本發(fā)明所必須的。在此處所提供的說明書中，說明了大量具體細節(jié)。然而，能夠理解，本發(fā)明的實施例可以在沒有這些具體細節(jié)的情況下實踐。在一些實例中，并未詳細示出公知的方法、結構和技術，以便不模糊對本說明書的理解。顯然，本領域的技術人員可以對本發(fā)明進行各種改動和變型而不脫離本發(fā)明的精神和范圍。這樣，倘若本發(fā)明的這些修改和變型屬于本發(fā)明權利要求及其等同技術的范圍之內，則本發(fā)明也意圖包含這些改動和變型在內。當前第1頁1 2 3 
山東錦工有限公司
地址：山東省章丘市經濟開發(fā)區(qū)
電話：0531-83825699
傳真：0531-83211205
24小時銷售服務電話：15066131928
