本發(fā)明涉及數(shù)據(jù)通信技術(shù)領(lǐng)域，尤其涉及一種日志文件的傳輸方法及系統(tǒng)。

背景技術(shù)：

日志文件用來儲存和記錄系統(tǒng)運行情況和用戶使用情況的詳細信息，這些信息是查看系統(tǒng)運行狀態(tài)和排查問題的主要依據(jù)。例如，某個軟件中應用程序出現(xiàn)崩潰情況，那么可以從程序事件的日志文件中找到相應的記錄，從而幫助相關(guān)技術(shù)人員分析并解決問題。

以線上系統(tǒng)日志信息為例，日志文件可以用來對線上業(yè)務運行過程的記錄和運行程序的監(jiān)控，通過分析記錄的日志文件可以為出現(xiàn)和可能出現(xiàn)的錯誤進行提示、警告，還可以統(tǒng)計業(yè)務信息，為業(yè)務邏輯改進和應用程序升級提供可靠的依據(jù)。

在現(xiàn)代軟件發(fā)展中，日志文件的傳輸和審查幾乎是確定軟件問題的唯一辦法?，F(xiàn)有日志文件的傳輸方法，應用服務器上各應用程序模塊產(chǎn)生的日志文件通過lib庫發(fā)送給日志客戶端，日志客戶端保存所收到的日志文件，進一步的，日志客戶端還可以根據(jù)配置的日志服務器ip地址和相關(guān)端口號，將所收到的日志文件發(fā)送給日志服務器。

在實現(xiàn)本發(fā)明的過程中，發(fā)明人發(fā)現(xiàn)現(xiàn)有技術(shù)中至少存在如下問題：

在現(xiàn)有日志文件的傳輸方法中，由于日志文件的傳輸過程處于開放的互聯(lián)網(wǎng)環(huán)境下，因此，日志文件在傳輸過程中容易受到釣魚網(wǎng)、dns重定向等網(wǎng)絡(luò)攻擊，使得日志文件的安全性在傳輸過程中無法得到有效保障。

技術(shù)實現(xiàn)要素：

為解決上述技術(shù)問題，本發(fā)明實施例期望提供一種日志文件的傳輸方法及系統(tǒng)，可以有效地提高日志文件在傳輸過程中的安全性。

本發(fā)明的技術(shù)方案是這樣實現(xiàn)的：

本發(fā)明實施例提供了一種日志文件的傳輸方法，所述方法包括：

發(fā)送端按照對稱加密算法將待傳輸?shù)娜罩疚募M行加密；

所述發(fā)送端使用傳輸層安全tls協(xié)議將加密后的日志文件傳輸給接收端；其中，所述tls協(xié)議包括：tls記錄層協(xié)議和tls傳輸層協(xié)議；

所述接收端按照所述對稱加密算法將所述日志文件進行解密。

在上述實施例中，所述對稱加密算法至少包括以下其中之一：des算法、3des算法、tdea算法、blowfish算法、rc5算法以及idea算法。

在上述實施例中，所述發(fā)送端采用tls協(xié)議將加密后的日志文件傳輸給接收端，包括：

所述發(fā)送端使用所述tls記錄層協(xié)議將加密后的日志文件進行封裝；

所述發(fā)送端使用所述tls傳輸層協(xié)議將封裝后的日志文件傳輸給所述接收端。

在上述實施例中，在所述發(fā)送端使用所述tls傳輸層協(xié)議將封裝后的日志文件傳輸給所述接收端之前，所述方法還包括：

所述發(fā)送端使用所述tls傳輸層協(xié)議對封裝后的日志文件進行安全認證；

當所述發(fā)送端對封裝后的日志文件認證成功時，所述發(fā)送端將封裝后的日志文件發(fā)送給所述接收端。

在上述實施例中，在所述發(fā)送端按照對稱加密算法將待傳輸?shù)娜罩疚募M行加密之前，所述方法還包括：

所述發(fā)送端生成所述對稱加密算法對應的加密密鑰，以使所述發(fā)送端使用所述加密密鑰將所述日志文件進行加密；

所述發(fā)送端將所述加密密鑰發(fā)送給所述接收端，以使所述接收端使用所述加密密鑰將所述日志文件進行解密。

本發(fā)明實施例還提供了一種日志文件的傳輸系統(tǒng)，所述系統(tǒng)包括：發(fā)送端和接收端；其中，

所述發(fā)送端，用于按照對稱加密算法將待傳輸?shù)娜罩疚募M行加密；使用傳輸層安全tls協(xié)議將加密后的日志文件傳輸給所述接收端；其中，所述tls協(xié)議包括：tls記錄層協(xié)議和tls傳輸層協(xié)議；

所述接收端，用于按照所述對稱加密算法將所述日志文件進行解密。

在上述實施例中，所述對稱加密算法至少包括以下其中之一：des算法、3des算法、tdea算法、blowfish算法、rc5算法以及idea算法。

在上述實施例中，所述發(fā)送端，具體用于使用所述tls記錄層協(xié)議將加密后的日志文件進行封裝；使用所述tls傳輸層協(xié)議將封裝后的日志文件傳輸給所述接收端。

在上述實施例中，所述發(fā)送端，還用于使用所述tls傳輸層協(xié)議對封裝后的日志文件進行安全認證；當對封裝后的日志文件認證成功時，將封裝后的日志文件發(fā)送給所述接收端。

在上述實施例中，所述發(fā)送端，還用于生成所述對稱加密算法對應的加密密鑰，以使所述發(fā)送端使用所述加密密鑰將所述日志文件進行加密；將所述加密密鑰發(fā)送給所述接收端，以使所述接收端使用所述加密密鑰將所述日志文件進行解密。

由此可見，在本發(fā)明實施例的技術(shù)方案中，發(fā)送端先按照對稱加密算法將待傳輸?shù)娜罩疚募M行加密，然后發(fā)送端使用tls協(xié)議將加密后的日志文件傳輸給接收端，最后接收端按照對稱加密算法將日志文件進行解密。也就是說，在本發(fā)明實施例的技術(shù)方案中，發(fā)送端不但可以按照對稱加密算法將待傳輸?shù)娜罩疚募M行加密，而且還可以使用tls協(xié)議將加密后的日志文件傳輸給接收端。而在現(xiàn)有技術(shù)中，發(fā)送端在將日志文件傳輸給接收端的過程中，發(fā)送端并未按照對稱加密算法將待傳輸?shù)娜罩疚募M行加密，也并未使用tls協(xié)議將加密后的日志文件傳輸給接收端，即：日志文件的傳輸過程處于開放的互聯(lián)網(wǎng)環(huán)境下，日志文件在傳輸過程中容易受到釣魚網(wǎng)、dns重定向等網(wǎng)絡(luò)攻擊。因此，和現(xiàn)有技術(shù)相比，本發(fā)明實施例提出的日志文件的傳輸方法及系統(tǒng)，可以有效地提高日志文件在傳輸過程中的安全性；并且，本發(fā)明實施例的技術(shù)方案實現(xiàn)簡單方便、便于普及，適用范圍更廣。

附圖說明

圖1為本發(fā)明實施例中日志文件的傳輸方法的實現(xiàn)流程示意圖；

圖2為本發(fā)明實施例中采用tls協(xié)議傳輸日志文件的實現(xiàn)流程示意圖；

圖3為本發(fā)明實施例中日志文件的傳輸系統(tǒng)的組成結(jié)構(gòu)示意圖。

具體實施方式

下面將結(jié)合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術(shù)方案進行清楚、完整地描述。

實施例一：

圖1為本發(fā)明實施例中日志文件的傳輸方法的第一實現(xiàn)流程示意圖。如圖1所示，日志文件的傳輸方法可以包括以下步驟：

步驟101、發(fā)送端按照對稱加密算法將待傳輸?shù)娜罩疚募M行加密。

對稱加密(也叫私鑰加密)是指加密和解密使用相同密鑰的加密算法。有時又叫傳統(tǒng)密碼算法，就是加密密鑰能夠從解密密鑰中推算出來，同時解密密鑰也可以從加密密鑰中推算出來。而在大多數(shù)的對稱算法中，加密密鑰和解密密鑰是相同的，所以也稱這種加密算法為秘密密鑰算法或單密鑰算法。它要求發(fā)送方和接收方在安全通信之前，商定一個密鑰。對稱算法的安全性依賴于密鑰，泄漏密鑰就意味著任何人都可以對他們發(fā)送或接收的消息解密，所以密鑰的保密性對通信性至關(guān)重要。

在本發(fā)明的具體實施例中，對稱加密算法可以至少包括以下其中之一：des算法、3des算法、tdea算法、blowfish算法、rc5算法以及idea算法。其中，des算法是把64位的明文輸入塊變?yōu)閿?shù)據(jù)長度為64位的密文輸出塊，其中8位為奇偶校驗位，另外56位作為密碼的長度。首先，des把輸入的64位數(shù)據(jù)塊按位重新組合，并把輸出分為l0、r0兩部分，每部分各長32位，并進行前后置換，最終由l0輸出左32位，r0輸出右32位，根據(jù)這個法則經(jīng)過16次迭代運算后，得到l16、r16，將此作為輸入，進行與初始置換相反的逆置換，即得到密文輸出。到目前為止，除了用窮舉搜索法對des算法進行攻擊外，還沒有發(fā)現(xiàn)更有效的辦法，而56位長密鑰的窮舉空間為2^56，這意味著如果一臺計算機的速度是每秒種檢測100萬個密鑰，那么它搜索完全部密鑰就需要將近2285年的時間，因此，des算法是一種很可靠的加密方法。

具體地，在本發(fā)明的具體實施例中，接收端可以執(zhí)行以下代碼將日志文件進行加密：

filestreamfspic＝newfilestream(picturebox1.imagelocation,filemode.open,fileaccess.read)；//圖片流

filestreamfsout＝file.open(textbox1.text，filemode.open，fileaccess.read)；//解密文件流；

byte[]bykey＝newbyte[16]；//初始化；

keyivbyte[]byiv＝newbyte[8]；

fspic.read(bykey，0，16)；

fspic.read(byiv，0，8)；

stringstrpath＝textbox1.text；//加密文件的路徑；

intintlent＝strpath.lastindexof("\\")+1；

intintlong＝strpath.length；

stringstrname＝strpath.substring(intlent，intlong–intlent)；//要加密的文件名稱；

stringstrlinpath＝"c:\\"+strname；//臨時解密文件路徑；

filestreamfs＝newfilestream(strlinpath，filemode.create,fileaccess.write)；

rc2cryptoserviceproviderdesc＝newrc2cryptoserviceprovider()；//desc進行解密；

cryptostreamcsdecrypt＝newcryptostream(fsout,desc.createdecryptor(bykey,byiv)，cryptostreammode.read)。

步驟102、發(fā)送端使用tls協(xié)議將加密后的日志文件傳輸給接收端；其中，tls協(xié)議包括：tls記錄層協(xié)議和tls傳輸層協(xié)議。

在本發(fā)明的具體實施例中，ssl(securesocketslayer安全套接層)協(xié)議，及其繼任者tls(transportlayersecurity傳輸層安全)協(xié)議，是為網(wǎng)絡(luò)通信提供安全及數(shù)據(jù)完整性的一種安全協(xié)議，目的是為互聯(lián)網(wǎng)通信，提供安全及數(shù)據(jù)完整性保障。tls與ssl在傳輸層對網(wǎng)絡(luò)連接進行加密，用于保障網(wǎng)絡(luò)數(shù)據(jù)傳輸安全，利用數(shù)據(jù)加密技術(shù)，確保數(shù)據(jù)在網(wǎng)絡(luò)傳輸過程中不會被截取及竊聽。ssl協(xié)議已成為全球化標準，所有主要的瀏覽器和web服務器程序都支持ssl協(xié)議，可通過安裝ssl證書激活ssl協(xié)議。具體地，tls協(xié)議可以包括：記錄層(recordlayer)協(xié)議和傳輸層協(xié)議；其中，記錄層協(xié)議用于確定傳輸層數(shù)據(jù)的封裝格式；傳輸層協(xié)議使用x.509認證，之后利用非對稱加密演算來對通信方做身份認證，之后交換對稱密鑰作為會談密鑰(sessionkey)。這個會談密鑰是用來將通信兩方交換的數(shù)據(jù)做加密，保證兩個應用間通信的保密性和可靠性，使客戶端與服務器之間的通信不被攻擊者竊聽。

具體地，在本發(fā)明的具體實施例中，發(fā)送端可以執(zhí)行以下代碼將加密后的日志文件傳輸給接收端：

post/upload？upload_progress_id＝12344http/1.1

host:localhost：3000

content-length：1325

origin:：http：//localhost:3000

...otherheaders...

content-type：multipart/form-data；

boundary＝----webkitformboundaryepkpff7tjbaqx29l

------webkitformboundaryepkpff7tjbaqx29l

content-disposition：form-data；name＝"max_file_size"

100000

------webkitformboundaryepkpff7tjbaqx29l

content-disposition：form-data；name＝"uploadedfile"；filename＝"hello.o"

content-type:application/x-object

...contentsoffilegoeshere...

------webkitformboundaryepkpff7tjbaqx29l--

步驟103、接收端按照對稱加密算法將日志文件進行解密。

在本發(fā)明的具體實施例中，接收端在接收到發(fā)送端發(fā)送的日志文件之后，若想解讀日志文件，則需要使用加密用過的密鑰及相同算法的逆算法對日志文件進行解密，才能使其恢復成可讀明文。在對稱加密算法中，使用的密鑰只有一個，發(fā)送端和接收端都使用這個密鑰對數(shù)據(jù)進行加密和解密，這就要求解密方事先必須知道加密密鑰。

具體地，在本發(fā)明的具體實施例中，接收端可以執(zhí)行以下代碼將日志文件進行解密：

binaryreadersr＝newbinaryreader(csdecrypt)；//從要加密流中讀出文件內(nèi)容；

binarywritersw＝newbinarywriter(fs)；//寫入解密流；

sw.write(sr.readbytes(convert.toint32(fsout.length)))；

//sw.flush()；

sw.close()；

sr.close()；

fs.close()；

fsout.close()；

fspic.close()；

csdecrypt.flush()；

file.delete(textbox1.text.trimend())；//刪除原文件；

file.copy(strlinpath,textbox1.text)；//復制加密文件；

file.delete(strlinpath)；//刪除臨時文件。

本發(fā)明實施例提出的日志文件的傳輸方法，發(fā)送端先按照對稱加密算法將待傳輸?shù)娜罩疚募M行加密，然后發(fā)送端使用tls協(xié)議將加密后的日志文件傳輸給接收端，最后接收端按照對稱加密算法將日志文件進行解密。也就是說，在本發(fā)明實施例的技術(shù)方案中，發(fā)送端不但可以按照對稱加密算法將待傳輸?shù)娜罩疚募M行加密，而且還可以使用tls協(xié)議將加密后的日志文件傳輸給接收端。而在現(xiàn)有技術(shù)中，發(fā)送端在將日志文件傳輸給接收端的過程中，發(fā)送端并未按照對稱加密算法將待傳輸?shù)娜罩疚募M行加密，也并未使用tls協(xié)議將加密后的日志文件傳輸給接收端，即：日志文件的傳輸過程處于開放的互聯(lián)網(wǎng)環(huán)境下，日志文件在傳輸過程中容易受到釣魚網(wǎng)、dns重定向等網(wǎng)絡(luò)攻擊。因此，和現(xiàn)有技術(shù)相比，本發(fā)明實施例提出的日志文件的傳輸方法，可以有效地提高日志文件在傳輸過程中的安全性；并且，本發(fā)明實施例的技術(shù)方案實現(xiàn)簡單方便、便于普及，適用范圍更廣。

實施例二：

圖2為本發(fā)明實施例中日志文件的傳輸方法的第二實現(xiàn)流程示意圖。如圖2所示，日志文件的傳輸方法可以包括以下步驟：

步驟201、發(fā)送端按照對稱加密算法將待傳輸?shù)娜罩疚募M行加密。

在本發(fā)明的具體實施例中，對稱加密算法可以至少包括以下其中之一：des算法、3des算法、tdea算法、blowfish算法、rc5算法以及idea算法。其中，des算法是把64位的明文輸入塊變?yōu)閿?shù)據(jù)長度為64位的密文輸出塊，其中8位為奇偶校驗位，另外56位作為密碼的長度。首先，des把輸入的64位數(shù)據(jù)塊按位重新組合，并把輸出分為l0、r0兩部分，每部分各長32位，并進行前后置換，最終由l0輸出左32位，r0輸出右32位，根據(jù)這個法則經(jīng)過16次迭代運算后，得到l16、r16，將此作為輸入，進行與初始置換相反的逆置換，即得到密文輸出。到目前為止，除了用窮舉搜索法對des算法進行攻擊外，還沒有發(fā)現(xiàn)更有效的辦法，而56位長密鑰的窮舉空間為2^56，這意味著如果一臺計算機的速度是每秒種檢測100萬個密鑰，那么它搜索完全部密鑰就需要將近2285年的時間，因此，des算法是一種很可靠的加密方法。

步驟202、發(fā)送端使用tls記錄層協(xié)議將加密后的日志文件進行封裝。

在本發(fā)明的具體實施例中，安全傳輸層協(xié)議(tls)用于在兩個通信應用程序之間提供保密性和數(shù)據(jù)完整性。該協(xié)議由兩層組成：tls記錄層協(xié)議(tlsrecord)和tls傳輸層協(xié)議(tlshandshake)；其中，較低的層為tls記錄協(xié)議，位于某個可靠的傳輸協(xié)議(例如tcp)上面。因此，在本發(fā)明的具體實施例中，發(fā)送端可以使用tls記錄層協(xié)議將加密后的日志文件進行封裝。tls記錄層協(xié)議是一種分層協(xié)議。每一層中的信息可能包含長度、描述和內(nèi)容等字段。記錄協(xié)議支持信息傳輸、將數(shù)據(jù)分段到可處理塊、壓縮數(shù)據(jù)、應用mac、加密以及傳輸結(jié)果等。對接收到的數(shù)據(jù)進行解密、校驗、解壓縮、重組等，然后將它們傳送到高層客戶機。

步驟203、發(fā)送端使用tls傳輸層協(xié)議將封裝后的日志文件傳輸給接收端。

在本發(fā)明的具體實施例中，tls握手協(xié)議提供的連接安全具有以下三個基本屬性：1)、tl傳輸層協(xié)議可以使用非對稱的，或公共密鑰的密碼術(shù)來認證對等方的身份；2)、共享加密密鑰的協(xié)商是安全的。對偷竊者來說協(xié)商加密是難以獲得的。此外經(jīng)過認證過的連接不能獲得加密，即使是進入連接中間的攻擊者也不能。3)、協(xié)商是可靠的。沒有經(jīng)過通信方成員的檢測，任何攻擊者都不能修改通信協(xié)商。因此，在本發(fā)明的具體實施例中，發(fā)送端可以使用tls傳輸層協(xié)議將封裝后的日志文件傳輸給接收端。

步驟204、接收端按照對稱加密算法將日志文件進行解密。

在本發(fā)明的具體實施例中，接收端在接收到發(fā)送端發(fā)送的日志文件之后，若想解讀日志文件，則需要使用加密用過的密鑰及相同算法的逆算法對日志文件進行解密，才能使其恢復成可讀明文。在對稱加密算法中，使用的密鑰只有一個，發(fā)送端和接收端都使用這個密鑰對數(shù)據(jù)進行加密和解密，這就要求解密方事先必須知道加密密鑰。

根據(jù)上述的描述可知，通過上述的步驟201-204，發(fā)送端可以先使用tls記錄層協(xié)議將加密后的日志文件進行封裝，然后發(fā)送端再使用tls傳輸層協(xié)議將封裝后的日志文件傳輸給接收端。這樣，在tls協(xié)議的保護下，加上對稱加密的方法，可以最大限度的保證日志文件的安全傳輸。

較佳地，在本發(fā)明的具體實施例中，發(fā)送端在使用tls傳輸層協(xié)議將封裝后的日志文件傳輸給接收端之前，發(fā)送端還可以使用tls傳輸層協(xié)議對封裝后的日志文件進行安全認證；當發(fā)送端對封裝后的日志文件認證成功時，發(fā)送端將封裝后的日志文件發(fā)送給接收端；當發(fā)送端對封裝后的日志文件認證失敗時，發(fā)送端則結(jié)束日志文件的傳輸流程。

較佳地，在本發(fā)明的集體實施例中，發(fā)送端在按照對稱加密算法將待傳輸?shù)娜罩疚募M行加密之前，發(fā)送端還可以生成對稱加密算法對應的加密密鑰，以使發(fā)送端使用加密密鑰將日志文件進行加密；此外，發(fā)送端還可以將加密密鑰發(fā)送給接收端，以使接收端使用加密密鑰將日志文件進行解密。

本發(fā)明實施例提出的日志文件的傳輸方法，發(fā)送端先按照對稱加密算法將待傳輸?shù)娜罩疚募M行加密，然后發(fā)送端使用tls協(xié)議將加密后的日志文件傳輸給接收端，最后接收端按照對稱加密算法將日志文件進行解密。也就是說，在本發(fā)明實施例的技術(shù)方案中，發(fā)送端不但可以按照對稱加密算法將待傳輸?shù)娜罩疚募M行加密，而且還可以使用tls協(xié)議將加密后的日志文件傳輸給接收端。而在現(xiàn)有技術(shù)中，發(fā)送端在將日志文件傳輸給接收端的過程中，發(fā)送端并未按照對稱加密算法將待傳輸?shù)娜罩疚募M行加密，也并未使用tls協(xié)議將加密后的日志文件傳輸給接收端，即：日志文件的傳輸過程處于開放的互聯(lián)網(wǎng)環(huán)境下，日志文件在傳輸過程中容易受到釣魚網(wǎng)、dns重定向等網(wǎng)絡(luò)攻擊。因此，和現(xiàn)有技術(shù)相比，本發(fā)明實施例提出的日志文件的傳輸方法，可以有效地提高日志文件在傳輸過程中的安全性；并且，本發(fā)明實施例的技術(shù)方案實現(xiàn)簡單方便、便于普及，適用范圍更廣。

實施例三：

圖3為本發(fā)明實施例中日志文件的傳輸系統(tǒng)的組成結(jié)構(gòu)示意圖。如圖3所示，所述系統(tǒng)包括：發(fā)送端301和接收端302；其中，

所述發(fā)送端301，用于按照對稱加密算法將待傳輸?shù)娜罩疚募M行加密；使用傳輸層安全tls協(xié)議將加密后的日志文件傳輸給所述接收端302；其中，所述tls協(xié)議包括：tls記錄層協(xié)議和tls傳輸層協(xié)議；

所述接收端302，用于按照所述對稱加密算法將所述日志文件進行解密。

進一步的，所述對稱加密算法至少包括以下其中之一：des算法、3des算法、tdea算法、blowfish算法、rc5算法以及idea算法。

進一步的，所述發(fā)送端301，具體用于使用所述tls記錄層協(xié)議將加密后的日志文件進行封裝；使用所述tls傳輸層協(xié)議將封裝后的日志文件傳輸給所述接收端302。

進一步的，所述發(fā)送端301，還用于使用所述tls傳輸層協(xié)議對封裝后的日志文件進行安全認證；當對封裝后的日志文件認證成功時，將封裝后的日志文件發(fā)送給所述接收端302。

進一步的，所述發(fā)送端301，還用于生成所述對稱加密算法對應的加密密鑰，以使所述發(fā)送端301使用所述加密密鑰將所述日志文件進行加密；將所述加密密鑰發(fā)送給所述接收端302，以使所述接收端302使用所述加密密鑰將所述日志文件進行解密。

本發(fā)明實施例提出的日志文件的傳輸系統(tǒng)，發(fā)送端先按照對稱加密算法將待傳輸?shù)娜罩疚募M行加密，然后發(fā)送端使用tls協(xié)議將加密后的日志文件傳輸給接收端，最后接收端按照對稱加密算法將日志文件進行解密。也就是說，在本發(fā)明實施例的技術(shù)方案中，發(fā)送端不但可以按照對稱加密算法將待傳輸?shù)娜罩疚募M行加密，而且還可以使用tls協(xié)議將加密后的日志文件傳輸給接收端。而在現(xiàn)有技術(shù)中，發(fā)送端在將日志文件傳輸給接收端的過程中，發(fā)送端并未按照對稱加密算法將待傳輸?shù)娜罩疚募M行加密，也并未使用tls協(xié)議將加密后的日志文件傳輸給接收端，即：日志文件的傳輸過程處于開放的互聯(lián)網(wǎng)環(huán)境下，日志文件在傳輸過程中容易受到釣魚網(wǎng)、dns重定向等網(wǎng)絡(luò)攻擊。因此，和現(xiàn)有技術(shù)相比，本發(fā)明實施例提出的日志文件的傳輸系統(tǒng)，可以有效地提高日志文件在傳輸過程中的安全性；并且，本發(fā)明實施例的技術(shù)方案實現(xiàn)簡單方便、便于普及，適用范圍更廣。

本領(lǐng)域內(nèi)的技術(shù)人員應明白，本發(fā)明的實施例可提供為方法、系統(tǒng)、或計算機程序產(chǎn)品。因此，本發(fā)明可采用硬件實施例、軟件實施例、或結(jié)合軟件和硬件方面的實施例的形式。而且，本發(fā)明可采用在一個或多個其中包含有計算機可用程序代碼的計算機可用存儲介質(zhì)(包括但不限于磁盤存儲器和光學存儲器等)上實施的計算機程序產(chǎn)品的形式。

本發(fā)明是參照根據(jù)本發(fā)明實施例的方法、設(shè)備(系統(tǒng))、和計算機程序產(chǎn)品的流程圖和/或方框圖來描述的。應理解可由計算機程序指令實現(xiàn)流程圖和/或方框圖中的每一流程和/或方框、以及流程圖和/或方框圖中的流程和/或方框的結(jié)合?？商峁┻@些計算機程序指令到通用計算機、專用計算機、嵌入式處理機或其他可編程數(shù)據(jù)處理設(shè)備的處理器以產(chǎn)生一個機器，使得通過計算機或其他可編程數(shù)據(jù)處理設(shè)備的處理器執(zhí)行的指令產(chǎn)生用于實現(xiàn)在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能的裝置。

這些計算機程序指令也可存儲在能引導計算機或其他可編程數(shù)據(jù)處理設(shè)備以特定方式工作的計算機可讀存儲器中，使得存儲在該計算機可讀存儲器中的指令產(chǎn)生包括指令裝置的制造品，該指令裝置實現(xiàn)在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能。

這些計算機程序指令也可裝載到計算機或其他可編程數(shù)據(jù)處理設(shè)備上，使得在計算機或其他可編程設(shè)備上執(zhí)行一系列操作步驟以產(chǎn)生計算機實現(xiàn)的處理，從而在計算機或其他可編程設(shè)備上執(zhí)行的指令提供用于實現(xiàn)在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能的步驟。

以上所述，僅為本發(fā)明的較佳實施例而已，并非用于限定本發(fā)明的保護范圍。