引論：我們為您整理了13篇ssl協議范文，供您借鑒以豐富您的創作。它們是您寫作時的寶貴資源，期望它們能夠激發您的創作靈感，讓您的文章更具深度。

篇1

ssl Protocol Analysis and Implementation

HU Xiao-ye1,LI Jun-yi2

(1.Baoji University of Arts and Sciences Equipment Department,Baoji 721007,China; 2.Dept. Comput. Sci. & tech., Shanxi Police Profession College,Xi'an 710043,China)

Abstract: Aim Discuss the configuration and working process of the SSL protocol,apply SSL to achieve internet security.Means First understand the system construction of SSL protocol,then understand the protocol's working process by SSL communicate and handclasp protocol process.Result SSL protocol is a security protocol base on the TCP/IP,SSL protocol settle the problem of security on internet,make up the shortage of TCP/IP,give us security of data transfer in internet.Conclusion Discussing the configuration and working process of the SSL protocol, make us to understand the SSL protocol all-around, and bring forward it's shortage and consummate it.

Key words: SSL protocol;C/S configuration;handclasp protocol;TCP/IP protocol

1 引言

目前，隨著Internet的快速發展，互聯網上的信息安全越來越引起人們的關注。特別是近年來基于互聯網的網上銀行、電子商務和電子政務的發展，如何保證傳輸信息，特別是網上交易信息的不可否認性、保密性、完整性已成為急待解決的問題。為此，人們發明了安全套接層SSL協議(Security Socket Layer Protocol，簡稱SSL)，是Internet上使用廣泛的保密通信的一種安全協議。

2 概述

SSL協議是由Netscape公司為制定數據安全性所開發的通信協議。1995年，Netscape公司提出了SSL2.0之后，很快就成為一個事實上的標準，并為眾多的廠商所采用。1996年，Netscape公司了SSL3.0，該版本增加了對除了RSA算法之外的其他算法的支持和一些安全特性，并且修改了前一個版本中一些小的問題，相比SSL2.0更加成熟和穩定。1999年l月EITF基于SSL協議了TLS1.0(Transport Layer Security)版本，Netscape公司宣布支持該開放的標準。

SSL協議向基于TCP/護的客戶/服務器應用程序提供了客戶端和服務器的鑒別、數據完整性、及信息機密性等安全措施。該協議通過在應用程序進行數據交換前交換SSL初始握手信息來實現有關安全特性的審查。在SSL握手信息中采用了DES、MDS等加密技術來實現機密性和數據完整性，并采用X.509的數字證書實現鑒別。該協議已成為事實上的工業標準，并被關泛應用于Internet和Intranet的服務器產品和客戶端產品中。如Netscape公司、微軟公司、IBM公司等領導Internet/Intranet網絡產品的公司已在使用該協議。

3 SSL協議的體系結構

SSL協議主要由兩層組成，分別是握手協議層和記錄協議層，握手協議建立在記錄協議之上，此外還有警告協議、更改密碼說明協議和應用數據協議等對話協議和管理提供支持的子協議。其組成如圖所示：

握手協議HandshakeProtocol和記錄協議Record Protocol是SSL協議的核心組成部分。其上是超文本協議HTTP、文件傳輸協議FTP和傳輸控制協議TELNET。它們控制文本的傳輸。支撐握手、記錄協議的低層通信是用戶數據報文和TCP/IP協議。

SSL發出消息是將數據分為可管理的塊、壓縮、使用MAC和加密并發出加密的結果。接受消息需要解密、驗證、解壓和重組，再把結果發往更高一層的客戶。以下是兩個主要協議的論述和分析。

1) 記錄協議：具體實現壓縮/解壓縮、加密/解密、計算機MAC等與安全有關的操作。建立之上的還有：

更改密碼說明協議：此協議由一條消息組成，可由客戶端或服務器發送，通知接收方后面的記錄將被新協商的密碼說明和密鑰保護，接收方得此消息后，立即指示記錄層把即將讀狀態變成當前讀狀態，發送方發送此消息后，應立即指示記錄層把即將寫狀態變成當前寫狀態。

警告協議：警告消息傳達消息的嚴重性并描述警告。一個致命的警告將立即終止連接。與其他消息一樣，警告消息在當前狀態下被加密和壓縮。警告消息有以下幾種：

關閉通知消息、意外消息、錯誤記錄MAC消息、解壓失敗消息、握手失敗消息、無證書消息、錯誤證書消息、不支持的證書消息、證書撤回消息、證收過期消息、證書未知和參數非法消息等等。

應用數據協議：將應用數據直接傳遞給記錄協議。

SSL記錄協議原理如圖2所示。

2) 握手協議：SSL握手協議是用來在客戶端和服務器端傳輸應用數據而建立的安全通信機制。

―算法協商：首次通信時，雙方通過握手協議協商密鑰加密算法，包括數據加密算法和文摘算法。

―身份驗證：在密鑰協商完成后，客戶端與服務器端通過證書交換，互相驗證對方的身份，一般通過目錄服務器的L DAP查詢完成。

―確定密鑰：最后使用協商好的密鑰交換算法產生一個只有雙方知道的秘密信息，客戶端和服務器各自根據這個秘密信息確定數據加密算法的參數(一般是對稱密鑰)。

由此可見，SSL協議是端對端的通信安全協議，即數字通信安全管道。

4SSL協議的實現工作過程

4.1 SSL通信過程

基于OpenSSL的程序可以被分為兩個部分：客戶機和服務器，使用SSL協議使通信雙方可以相互驗證對方身份的真實性，并且能夠保證數據的完整性和機密性。建立SSL通信的過程如圖3所示。

SSL通信模型采用標準的C/S結構，除了在TCP層上進行傳輸之外，與普通的網絡通信協議沒有太大的區別，基于OpenSSL的程序都要遵循以下幾個步驟：

1) OpenSSL初始化

在使用OpenSSL之前，必須進行相應的協議初始化工作，這可以通過下面的函數實現：

int SSL_library_int(void);

2) 選擇會話協議

在利用OpenSSL開始SSL會話之前，需要為客戶端和服務器制定本次會話采用的協議，目前能夠使用的協議包括TLSv1.0、SSLv2、SSLv3、SSLv2/v3。

需要注意的是，客戶端和服務器必須使用相互兼容的協議，否則SSL會話將無法正常進行。

3) 創建會話環境

在OpenSSL中創建的SSL會話環境稱為CTX，使用不同的協議會話，其環境也不一樣的。申請SSL會話環境的OpenSSL函數是：

SSL_CTX *SSL_CTX_new(SSL_METHOD * method);

當SSL會話環境申請成功后，還要根據實際的需要設置CTX的屬性，通常的設置是指定SSL握手階段證書的驗證方式和加載自己的證書。制定證書驗證方式的函數是：

int SSL_CTX_set_verify(SSL_CTX *ctx,int mode,int(*verify_callback),int(X509_STORE_CTX *));

為SSL會話環境加載CA證書的函數是：

SSL_CTX_load_verify_location(SSL_CTX *ctx,const char *Cafile,const char *Capath);

為SSL會話加載用戶證書的函數是：

SSL_CTX_use_certificate_file(SSL_CTX *ctx, const char *file,int type);

為SSL會話加載用戶私鑰的函數是：

SSL_CTX_use_PrivateKey_file(SSL_CTX *ctx,const char* file,int type);

在將證書和私鑰加載到SSL會話環境之后，就可以調用下面的函數來驗證私鑰和證書是否相符：

int SSL_CTX_check_private_key(SSL_CTX *ctx);

4) 建立SSL套接字

SSL套接字是建立在普通的TCP套接字基礎之上，在建立SSL套接字時可以使用下面的一些函數：

SSL *SSl_new(SSL_CTX *ctx);

//申請一個SSL套接字

int SSL_set_fd(SSL *ssl,int fd);)

//綁定讀寫套接字

int SSL_set_rfd(SSL *ssl,int fd);

//綁定只讀套接字

int SSL_set_wfd(SSL *ssl,int fd);

//綁定只寫套接字

5) 完成SSL握手

在成功創建SSL套接字后，客戶端應使用函數SSL_connect( )替代傳統的函數connect( )來完成握手過程:

int SSL_connect(SSL *ssl);

而對服務器來講，則應使用函數SSL_ accept ( )替代傳統的函數accept ( )來完成握手過程:

int SSL_accept(SSL *ssl);

握手過程完成之后，通常需要詢問通信雙方的證書信息，以便進行相應的驗證，這可以借助于下面的函數來實現:

X509 *SSL_get_peer_certificate(SSL *ssl);

該函數可以從SSL套接字中提取對方的證書信息，這些信息已經被SSL驗證過了。

X509_NAME *X509_get_subject_name(X509 *a);

該函數得到證書所用者的名字。

6) 進行數據傳輸

當SSL握手完成之后，就可以進行安全的數據傳輸了，在數據傳輸階段，需要使用SSL_read( )和SSL_write( )來替代傳統的read( )和write( )函數，來完成對套接字的讀寫操作：

int SSL_read(SSL *ssl,void *buf,int num);

int SSL_write(SSL *ssl,const void *buf,int num);

7) 結束SSL通信

當客戶端和服務器之間的數據通信完成之后，調用下面的函數來釋放已經申請的SSL資源：

int SSL_shutdown(SSL *ssl);

//關閉SSL套接字

void SSl_free(SSL *ssl);

//釋放SSL套接字

void SSL_CTX_free(SSL_CTX *ctx);

//釋放SSL會話環境

4.2 SSL握手協議的工作過程

SSL協議的工作過程主要就是握手協議的工作過程。下面我們重點講述握手協議的工作過程。圖4是握手協議簡化的握手順序。

SSL協議具體握手過程描述如下：

―客戶Client端發送ClientHello信息給服務器Server端，Server回答ServerHello。這個過程建立的安全參數包括協議版本、“佳話”標識、加密算法、壓縮方法。另外，還交換兩個隨機數：ClientHello.Random和ServerHello.Random.用以計算機“會話主密鑰”。

―Hello消息發送完后，Server會發送它的證書和密鑰交換信息，如果Server端被認證，它就會請求Client端的證書，在驗證以后，Server就發送H elloDone消息以示達成了握手協議，即雙方握手接通。

―Server請求Client證書時，Client要返回證書或返回“沒有證書的指示，這種情況用于單向認證，即客戶端沒有裝證書，然后Client發送密鑰交換消息。

―服務器Server此時要回答“握手完成“消息(Finished)，以示完整的握手消息交換已經全部完成。

―握手協議完成后，Client端即可與Server端傳輸應用加密數據，應用數據加密一般是用第②步密鑰協商時確定的對稱加/解密密鑰，如DE S、3DE等等，目前商用加密強度為128位。非對稱密鑰一般為RAS，商用強度1024位，用于證書的驗證。

5 總結

SSL協議很好的解決了Internet上信息的安全傳輸，彌補了TCP/IP協議的不足，使得我們在網絡上傳輸數據得到安全保障。SSL協議雖然得到了廣泛的應用，但是它也存在了很多不足。SSL協議中引入了很多安全機制，如非對稱密鑰交換、數據加密、消息認證碼MAC、身份認證等，因為用以保護數據的所有加密密鑰都是通過masterSecret來產生的，故協議的所有安全幾乎都依賴于masterSecret的保密，如果某個會話的masetrSecert被攻破的話，這個會話就會完全暴露于攻擊之下。而且SSL協議不提供交易的不可抵賴性。對于電子商務應用來說，使用SSL可保證信息的真實性、完整性和保密性。但由于SSL不對應用層的消息進行數字簽名，因此不能提供交易的不可否認性，這是 SSL在電子商務中使用的最大不足。有鑒于此，網景公司在從Communicator 4.04版開始的所有瀏覽器中引入了一種被稱作"表單簽名（Form Signing）"的功能，在電子商務中，可利用這一功能來對包含購買者的訂購信息和付款指令的表單進行數字簽名，從而保證交易信息的不可否認性。綜上所述，在電子商務中采用單一的SSL協議來保證交易的安全是不夠的，但采用"SSL+表單簽名"模式能夠提供較好的安全性保證。

參考文獻：

[1] 顧兵.VPN技術在企業中的應用[J].中國海洋平臺,2003(1)：44-46.

[2] 懂洪偉,馮斌,楊開蕎.VPN關鍵技術探討[J].計算機工程,2002(11):159-161,177.

篇2

一、SSL協議

1.SSL概述

SSL（Secure Socket Layer,安全套接層）協議是 Netscape 公司于1994年提出的一個網絡安全通信協議，是一種在兩臺機器之間提供安全通道的協議。它具有保護傳輸數據，以及識別通信機器的功能。SSL最初是通過加密HTTP連接為Web瀏覽器提供安全而引入的。

SSL在TCP上提供一種通用的通道安全機制，任何可以在TCP上承載的協議都能夠使用SSL加以保護。在TCP或IP四層協議族中，SSL協議位于傳輸層與應用層之間，基于可靠傳輸協議TCP，服務于各種應用層協議，如HTTP、POP、TELNET等，它們在SSL協議上運行分別被稱作HTTPS、POPS、TELNETS協議等，分別對應的端口號為443、995、992等。

圖1 SSL協議結構圖

2.SSL體系結構

SSL協議在結構上分為兩個層次：底層為記錄層協議（Record Protocol），負責封裝高層協議（包括握手協議）的數據，保證SSL連接的數據保密性和完整性；高層為握手層，由四個并行的協議構成：握手協議（Handshake Protocol）、修改密碼參數協議（Change Cipher Spec Protocol）、報警協議（Alert Protocol）、應用數據協議（Application data Protocol），高層協議需要記錄層協議支持，其中握手協議與其他的高層協議不同，主要負責在交換應用層數據之前進行協商加密算法與密鑰，其他高層協議屬于應用開發的范疇，而要得到握手協議的支持，而握手協議則是SSL底層實現必須具有的功能，因為記錄層協議的完成也由它來保證。

二、基于SSL協議的VPN技術研究

1.SSLVPN概念

SSL VPN是指一種基于數據包封裝技術的，利用SSL或TLS協議結合強加密算法和身份認證技術的，可靠安全地構建VPN的一種方法。它作為一種新的VPN的實現方法，SSL VPN可以用來構建外聯網、內聯網和遠程接入訪問。它通過數據包封裝的隧道技術來實現虛擬專用網的私有性，通過PKI技術和密碼學技術來鑒別通信雙方的身份和確保傳輸數據的安全。

2.SSL VPN的工作模式

(1)基于Web模式的SSL VPN系統

客戶端使用瀏覽器通過SSLVPN 服務器來訪問企業局域網的內部資源。SSLVPN 服務器相當于一個數據中轉站，Web瀏覽器對WWW服務器的訪問經過SSL VPN服務器的處理（解密、身份鑒別、訪問控制）后轉發給WWW服務器，從WWW服務器發往Web瀏覽器的數據經過SSL VPN服務器處理（過濾、加密）后送到Web瀏覽器。

圖2 基于Web模式的SSL VPN系統

(2)基于客戶模式的SSL VPN

用戶在客戶端安裝一個SSL VPN客戶端程序，當客戶端訪問企業內部的應用服務器時，需要經過SSL VPN客戶端程序和SSL VPN服務器之間的保密傳輸后才能到達。從而在SSLVPN客戶端和 SSLVPN服務器之間，由SSL協議構建一條安全通道，保護客戶端與SSLVPN服務器之間的數據傳輸。此時，SSLVPN服務器充當服務器的角色，SSL VPN客戶端充當客戶端的角色。

圖3 基于客戶端模式的SSL VPN系統

(3)局域網到局域網模式的SSL VPN系統

在網絡邊緣都安裝和配置了SSLVPN服務器。當一個局域網內的終端要訪問遠程網絡內的應用服務器時，需要經過兩個SSL VPN服務器之間的保密傳輸后才能到達。從而在兩個SSLVPN服務器之間，由SSL協議構建一條安全通道，保護局域網之間的數據傳輸。此時，SSL VPN服務器充當安全網關的角色。

圖4 局域網到局域網模式的SSL VPN系統

參考文獻:

篇3

解決方法：

篇4

Internet payment system based on SSL and SET protocol

JIANG Zhihua

(Info. Eng. College, Shanghai Maritime Univ., Shanghai 200135, China)

Abstract： Internet payment is the bottleneck that restricts the development of E-Business. So the general internet payment system framework for bank card is introduced, and an Internet payment system based on Secure Socket Layer (SSL) and Secure Electronic Transaction (SET) protocol is proposed. And its payment flow and security are detailed and discussed.

Key words： Internet payment; secure socket layer; secure electronic transaction; E-Business; payment system; E-Wallet

0 引 言

網絡支付方式是電子商務發展的關鍵要素.電子商務交易支付涉及支付安全和實現平臺的統一，信息安全技術已經為網絡支付研究出一系列安全加密及信息傳輸的技術規范，如以安全套接層(Secure Socket Layer, SSL)協議和安全電子交易協議(Secure Electronic Transaction, SET)為代表的網絡支付協議及應用于網上的數字簽名、用戶論證等技術.本文結合SSL和SET網絡支付協議及應用技術，討論基于第三方運營的網絡支付方式，發揮SET的嚴密性和SSL的簡單直觀性等特點，使網絡支付系統構建體現資源整合、方便交易特色的統一支付平臺.

1 網絡支付模式

網絡支付是指電子商務交易的當事人，包括消費者、廠商和金融機構，使用安全電子支付手段通過網絡進行的貨幣支付或資金流轉，對支付的要求是能夠實現跨地跨行的交易支付快捷且安全，并保證銀行之間、銀行商戶之間的資金結算準確無誤.電子支付的方式主要有3類：一類是電子貨幣類，如電子現金和電子錢包等；另一類是電子信用卡類，包括銀行磁卡、智能卡和電話卡等；還有一類是電子支票類，如電子支票、電子匯款和電子劃款等.

在電子支付的3種基本支付方式中信用卡（銀行卡）支付得到世界范圍內的普及［1］，能很好地解決小額在線支付結算中的安全問題，因此越來越多的人愿意接受并且喜歡利用信用卡進行網絡支付.信用卡網絡支付模式總體有下面4種.

1.1 無安全措施的信用卡支付模式

這種支付模式是指持卡人利用信用卡進行支付結算時，幾乎沒有采取任何技術上的安全措施而把信用卡號碼和密碼直接傳送給商家，然后由商家負責后續處理的模式(見圖1).這是在電子商務發展初期各方面都不太成熟，特別是銀行對電子商務的支持還不完善的情況下出現的，風險由商家負責，安全性差，持卡人的信用卡隱私信息完全被商家掌握，支付效率較低.［2］

1.2 借助第三方機構的信用卡支付模式

為了降低在無安全措施支付模式中的風險，在買方和賣方之間啟用1個具有誠信的第三方機構，這個機構持有持卡客戶的信用卡賬號信息用于與銀行的支付結算，并負責將交易信息在商家和客戶之間傳遞(見圖2).這種方式對第三方機構的公正、信譽和操作規范有很高的要求［3］，主要風險由第三方機構承擔，安全性得到一定的保證；但由于并未發揮銀行網絡在支付中的作用，在提高安全性的同時支付效率沒有得到提高，成本也較高，且不太適合小額的網上支付.

1.3 基于SSL協議機制的信用卡支付模式

這種方式為Internet環境下信用卡支付的典型方式(見圖3)：使用SSL作為安全會話，保護和防止Internet其他用戶獲取信用卡帳號等機密信息.交易多方身份驗證機構認證中心(Certification Authority,CA)的作用是間接的，主要是為支付各方頒發證書.用戶以明文方式輸入其信用卡號，該卡號將被加過密的SSL會話發送給商家的服務器并轉發給發卡銀行.這種通過商家中轉支付信息的SSL支付模式不能保證支付賬戶信息不被商家看到，所以改進的SSL支付模式就是客戶瀏覽器與銀行服務器之間直接建立SSL加密聯接.SSL支付模式是應用最為廣泛的網絡支付模式，其特點是應用方便、成本較低、安全性高、市場產品成熟，國內大多數商業銀行的信用卡網絡支付系統都采用這種技術模式，絕大多數的網上商家均支持這種模式的信用卡應用.

SET協議是由Visa和MasterCard聯合開發的1種開放性標準.SET協議可以讓持卡人在開放網絡上發送安全的支付指令和獲取認證信息.SET主要用于兼容當前的信用卡網絡，目前涉及的是B2C的電子商務交易.在交易之前，客戶必須到相應的發卡銀行柜臺辦理應用SET協議機制的信用卡，并下載安裝持卡客戶端軟件（電子錢包軟件），將信用卡相關信息添加進客戶端軟件，最后為其中的信用卡申請數字證書；同樣，商戶需到銀行辦理這類信用卡結算事宜，得到服務器端SET支持軟件，并且從CA得到數字證書.作為銀行網絡與外部網的接口支付網關，也須得到數字證書的認證.在交易過程中，SET介入信用卡支付的全過程，由于加密、認證較多，支付處理速度相對SSL機制的信用卡支付稍慢，各方開銷也大一些，但該協議設計得很安全，已經成為事實上的工業標準.［4］

2 基于SSL和SET的網絡支付

2.1 網絡支付原理

目前應用較多的SSL和SET機制各有優劣.SSL強調的重點在于實現網絡支付的便捷性，即可以在任何1網的PC上進行網上支付（需要安全認證和數字證書的下載），但是用戶必須遵循不同銀行卡相對獨立的支付規則，且針對銀行的是特約商戶，一般商戶不能支持所有銀行卡.而SET流程設計安全，一般利用安裝在物理設備（用戶PC硬盤）之上的電子錢包模擬實際購物，對于用戶而言很直觀也比較易用，但是移動性卻因為需要安裝電子錢包軟件而喪失，每次網絡支付都要安裝電子錢包軟件很不現實.

結合SSL和SET網上支付的優勢，將安裝在本地硬盤的電子錢包置于網絡上，由獨立的第三方（網絡服務商）管理用戶電子錢包，并使網上錢包與銀行的前端接口――支付網關有機結合，這樣用戶在網上購物與支付時，以瀏覽器加密專用通道（即SSL）的方式使用SET機制的電子錢包功能.

2.2 網絡支付流程

網絡支付流程見圖4.

從圖4可知，利用網上錢包進行在線支付的大致流程如下：（1）申請電子錢包.客戶要在網上錢包服務商處開通網上錢包功能，申請電子錢包并進行設置.一般情況下客戶可以到柜臺申請，也可以在線申請，成功后用戶得到網上錢包的賬號和密碼.用戶還需對自己的電子錢包進行設置，將信用卡及支付卡賬號、密碼等信息存入網上錢包的個人賬戶中，除此之外還應對電子錢包的保密性做設置.（2）使用錢包中的信用卡支付.網上錢包實際上是個統一的支付平臺，用戶在SSL會話界面輸入自己的網上錢包賬號和密碼進入錢包系統，選擇信用卡進行支付.此時SET介入其中，對于銀行支付網關，可以是與網上錢包平臺集成的統一支付網關，也可以是銀行自身的支付網關.收單行扣款成功返還給網上錢包平臺，再通過SSL通知客戶支付成功信息.

3 網絡支付的安全性討論

網絡支付給用戶帶來使用上的方便，而且SSL和SET的結合能夠使支付交易的速度得到提高.SSL和SET協議在網絡安全上根據不同的安全要求和級別采取相應的安全防范措施.同樣，網絡支付在應用中也采用諸如數字簽名、數字信封和數字摘要等技術，使其安全性問題就在于第三方錢包運營商的公正性（如錢包用戶基本信息的保密問題等）以及錢包用戶身份合法性上.

前者應當強化第三方機構（服務商）的審核，可以在應用中由業界普遍認同的絕對公正的金融機構擔任網上錢包的服務商，同時CA應適時地加以身份鑒證；技術上加強用戶對錢包賬戶信息的自我控制，對錢包運營商的數據監控.對于后者［5］，應加強密碼系統的安全性，用戶應注意賬戶信息的保密和密碼的及時更新，必要時可以采用動態密碼機制.另外將賬戶信息集成在存儲設備（如智能卡）上，采用雙重身份登陸方法，也是實現網上錢包個人安全登陸的好辦法.目前，國內金融網絡建設的“銀聯”模式就是這樣的實際應用，“銀聯”是依托于銀行卡跨行跨地的資金流轉業務而產生的，除了提供銀行卡方便的現金支取和消費刷卡之外，其技術優勢可完全應用于網絡支付，作為第三方的支付網關，代表眾多商業銀行的支付工具，已經實現在線支付的即時到賬，各類具有銀聯標志的銀行卡都能方便地完成網絡支付，并且正得到越來越多的應用.

4 結 論

本文闡述的是基于SSL和SET相結合的網絡支付系統，是權衡兩者利弊的較佳方案.可以看到，網絡支付依托的是傳統的網絡支付模型和工具，在系統構成上主要要素不變，這就說明已經成熟的網絡支付協議及安全技術是支付系統的基礎，而在支付方式的形式上有比較大的拓展空間，這要根據實際的支付環境來決定.在設計網絡支付系統時，應充分考慮支付環境和交易的情況，做到安全和便捷的統一.

參考文獻：

［1］ 梁春曉, 安徽. 電子商務從理念到行動［M］. 北京: 清華大學出版社, 2001.

［2］ 柯新生. 網絡支付與結算［M］. 北京: 電子工業出版社, 2004.

篇5

隨著計算機技術和Internet的飛速發展，商業活動實現了電子化，從而發展成為電子商務。電子商務借助互聯網、企業內部網和增值網等計算機與網絡和現代通信技術，按照一定的標準，利用電子化工具，將傳統的商業活動的各個環節電子化、網絡化，從而以數字化方式來進行交易活動和相關服務活動。

電子商務包括電子貨幣交換、供應鏈管理、電子交易市場、網絡營銷、在線事務處理、電子數據交換（EDI）、存貨管理和自動數據收集系統。電子商務完全不同于傳統的商務活動，它是一種以網絡為載體的新的商務運作方式。

（1）SSL不能提供交易的不可否認性。SSL協議是基于Web應用的安全協議，它只能提供安全認證，保證SSL鏈路上的數據完整性和保密性。卻不能對電子商務的交易應用層的信息進行數字簽名，因此，SSL不能提供交易的不可否認性，這可以說是SSL在電子商務中最大的缺陷。

（2）SSL只能提供客戶機到服務器之間的兩方認證，無法適應電子商務中的多方交易業務。

（3）SSL易遭受Change Cipher Spec消息丟棄攻擊。由于SSL握手協議中存在一個漏洞：在finished消息中沒有對變換加密的說明消息進行認證處理，在接收到該消息前，所有的密碼族都不做任何加密處理和MAC保護，只有在接收到Change Cipher Spec消息之后，記錄層才開始對通信數據進行加密和完整性保護。這種處理機制使得SSL易遭受Change Cipher Spec消息丟棄攻擊。

（4）SSL無法避免通信業務流分析攻擊。由于SSL位于TCP/IP的協議層之上，因此，無法對TCP/IP協議頭部進行保護，導致潛在的隱患。攻擊者通過獲取IP地址、URL請求的長度以及返回的Web頁面的長度等信息，可以分析出用戶訪問的目標，再加上SSL協議只支持對 塊密碼的隨機填充，沒有提供對流式密碼算法的支持，使得SSL無法阻止這類攻擊。

4  總結

電子商務正飛速地發展。用于保障電子商務活動的安全協議主要有S-HTTP、STT、IKP、SET和SSL。其中SSL協議是目前電子商務采用的主要的網上交易協議。SSL協議采用了加密、認證等安全措施，結合了Hash算法，較好地保證了數據在傳輸過程中的保密性、可靠性和完整性，在一定程度上放置了欺騙、篡改、重放等攻擊。本文在介紹SSL協議棧及其工作原理和機制的基礎上，對基于SSL的電子商務的安全性進行了分析。

參考文獻：

篇6

SSL Protocol in the Network Communication of the Application

ZHANG Yang

(Liaoning University Computing Center, Shenyang 110036, China)

Abstract: SSL protocol is to provide a secure channel between computers a security protocol, data transmission is encrypted. This article has wireless video surveillance system for the study, the introduction of the SSL protocol in the system, the application of the protocol on the server and the client’s network communication, which can achieve data transmission security, authentication and message integrity.

Key words: SSL protocol; information security; network communication

無線視頻監控系統服務器和客戶端之間采用的C/S模式組成的，實現對視頻信號實時采集和壓縮編碼后，將圖像傳輸到指定的視頻服務器上。那么命令信息在傳輸過程中，數據的安全性是我們需要解決的重要問題。所以在該系統中引入了SSL協議，把SSL協議應用在服務器和客戶端的網絡通信中，通過數據加密提高信息的安全性。

1系統設計原則和目標

1.1系統設計原則

該系統的服務器和客戶端都是在windows操作系統利用VC的socket建立連接，實現網絡通信。考慮到服務器和客戶端之間數據傳輸的安全性和有效性，設計過程中注意以下幾個方面：

1）并發性：因為服務器和客戶端之間建立聯系，一般是一臺服務器對應多個客戶端進行通信的，每個終端優先級是平等的，為了實現客戶端的并發，在服務器端采用VC中的多線程技術，使得每個客戶端都能和服務器同時產生通信。

2）安全性：該系統是服務器和客戶端之間利用socket通信，客戶端向服務器發送請求命令，服務器收到后回應請求，如果在通信過程中命令信息不加密，信息容易被非法竊取，直接通過TCP協議傳輸信息是不安全的，所以要引入SSL協議，使所有的命令信息是加密傳輸的，保證了信息的安全性。

3）實時性：由于視頻監控系統對畫面的實時性要求非常高的，如果圖像也是通過加密傳輸的話，會嚴重影響圖像的傳輸速率，也就失去了實時性的要求，所以，我們在處理圖像傳輸時就不像命令信息一樣通過SSL加密傳輸了，滿足了圖像的實時性要求。1.2系統設計的目標

該系統實現的目標就是服務器端和客戶端建立連接，滿足并發性的要求；在通信過程中，雙方發送的命令信息通過SSL加密傳輸，提高安全性；圖像傳輸通過TCP協議傳輸，滿足視頻傳輸的實時性。

2網絡通信模塊的設計

主要討論的是服務器和客戶端之間的網絡通信問題，服務器和客戶端之間有兩種信息:服務器向客戶端轉發的視頻流信息；服務器和客戶端之間傳輸的命令信息。從信息的安全性考慮，在該系統中引入SSL加密協議，在數據傳輸過程中，即使數據被黑客竊取也不會將數據還原。確保了數據的安全性。

因為監控視頻對圖像的實時性要求非常高，不能有太長的時間延遲，而視頻在傳輸過程中產生的流量非常之大，直接通過TCP協議傳輸視頻信息可以有效降低時間延遲。

因此，通過SSL協議傳輸各種命令信息，我們可以把SSL通信模塊封裝成sslclient類和sslserver類，提供了接口函數，只需要調用對應的API就可以實現SSL加密通信。

3 SSL網絡通信技術的實現

3.1 SSL通信模塊的工作流程

該系統的整個結構可以分為服務器和客戶端兩個部分組成，而其中的SSL通信模塊為現實這兩個部分之間的數據通信的安全傳輸提供服務。主要從外部和內部兩個方面來分析，從外部來看，系統包括初始化握手部分和數據傳輸部分兩個部分內容，這兩個部分的內容具體對應SSL協議的“握手協議”和“記錄協議”。從內部來看，SSL模塊可劃分為初始化、SSL連接、身份認證和數據傳輸幾個模塊，初始化主要為SSL連接做準備工作，身份認證主要是驗證對方數字證書以證明身份的有效性。如果服務器也要求進行客戶端身份認證，會以同樣的方法對客戶端的證書進行驗證。當服務器和客戶端互相進行驗證之后。會在兩者之間成功建立SSL連接，形成一個安全數據傳輸通道，傳輸數據類似于TCP的套接字，直接寫入或者讀取數據。如圖1所示。

圖1 SSL通信模塊的結構圖

3.2實現的過程

在通信模塊中，服務器實現的過程很簡單，和客戶端實現的過程類似，服務器等待客戶端發送請求的連接，之后初始化一條SSL連接，它就從客戶端讀取或寫入數據發送到客戶端。按照功能也可以分為四部分：初始化過程、連接過程、身份認證過程和數據傳輸。

1）初始化過程：客戶端的開發時調用openssl函數實現的，首先是初始化SSL庫，在選擇會話連接所使用的協議：ssl_method* sslv3_client_method();再去申請SSL會話的CTX:ssl_ctx* ssl_ctx_new(ssl_method* meth);，目的是連接對象進行SSL握手、數據的讀寫；最后是家在私有密鑰和數字證書并設置加密套件。

然而服務器初始化過程和客戶端初始化過程類似，不同只是服務器調用sslv3_server_method()函數來實現的。

2）連接過程：服務器調用listen函數開始監聽客戶端的TCP連接請求，調用accept函數接受客戶端的TCP連接；申請一個BIO對象，把SSL綁在在這個對象上；調用SSL的accept函數接受客戶端的SSL連接。

3）身份認證：由于系統采用雙向身份認證機制進行身份認證，所以服務器和客戶端的證書都要互相進行認證方可正常通信，二者進行信息對比，如果一致，表明驗證通過，否則將關閉與客戶端之間的連接。

4）數據傳輸：服務器與客戶端建立連接后就可傳輸數據，所有數據是經SS加密處理后進行傳輸的。

4結束語

在當今信息化飛速發展的社會中，信息數據在日常生活和工作中顯得越來越重要，所以信息安全的重要性也越來越受到人們的重視，數據在保存和傳輸過程中如何可以防止黑客竊取，正是該文研究的對象。該文以視頻監控作為實例來研究，既要保證視頻傳輸的實時性，又要保障數據的安全性，所以我們采用服務器和客戶端之間采用靈活的雙重連接制，通過SSL協議進行數據加密傳輸，提高了機密信息傳輸的安全性。

參考文獻：

[1]付沙,何誠,文旭華.基于SSL協議的安全網絡通信的理論和實現[J].計算機與現代,2006(11).

[2]曾強.網絡安全協議SSL原理及應用[D].天津:天津大學,2005.

[3]唐玲.數字證書系統的設計研究[D].合肥:合肥工業大學,2004.

[4]韓澄宗.網絡實驗室中的視頻監控系統[D].杭州:浙江大學,2006.

篇7

隨著當前各類高校及高職學校的校園網建設并投入使用，校園網的各種信息資源需要通過網絡為身處不同地點的教師、學生及員工共享使用。當前許多高職院校均存在多個校區的網絡構架，僅通過互聯網絡實現網絡的聯接，顯然會存在較多的隱患，畢竟互聯網是一個開放的使用TCP/IP技術實現網絡連接和不可管理的互聯網絡。因此，如何解決位于不同校區的網絡基礎設施有可能互不兼容子網絡實現安全的互聯互通成為一個較為突出的難題。而這些在其他各類網絡互聯中的難題催生了VPN技術的出現。

1 VPN技術分類

VPN（virtual private network）技術是指利用網絡資源臨時建立一個安全的網絡連接，或特定的網絡通道將網絡中物理上分布于不同區域的局域網絡連接成為一個邏輯上的專門網絡，一般VPN技術采用隧道技術、身份認證技術、數據加密技術以及密鑰管理等關鍵技術來實施網絡通信的數據安全性保護。

VPN技術根據實現技術的不同一般可以分為PPTP、L2TP、MPLS、IPSec、SSL等，其中，基于SSL協議的VPN技術是目前應用最為廣泛的一種VPN技術。

2 基于SSL協議的VPN技術

一般來說，SSL協議是在客戶端和服務器端之間建立安全通道的一種協議，該協議對通信雙方身份進行認證同時對傳輸的數據進行保護。SSL協議通常是建立在如TCP協議這樣的可靠的傳輸層協議之上，同時獨立于應用層協議。高層的應用協議HTTP、FTP大多可透明地運行于SSL協議之上。

1）SSLVPN的實現原理。SSLVPN是一種數據包封裝技術，一般采用SSL/TLS協議與加密算法、身份認證技術等構建VPN。雖然SSL協議不是為實現VPN而設計的，但SSL對VPN實現所需的數據加密、身份認證和密鑰管理等提供了必要的技術支持。

在實現過程中，用戶通過瀏覽器內建的Secure SocketLayer封包處理功能，連回到網絡內部的SSLVPN服務器，采用網絡封包轉向的方式，讓用戶在遠程計算機執行應用程序，讀取網絡內部服務器數據。SSLVPN一般采用標準的安全套接層（SSL）對數據進行加密，在應用層上保護數據的安全性。SSLVPN技術可實現用戶安全的進行內部網絡的訪問。

2）SSLVPN的特點

其客戶端支撐維護簡單，大多基于SSL協議的遠程訪問不需要在遠程客戶端上安裝軟件就可以通過Web瀏覽器訪問到企業內部的網絡資源；還可以實現遠程安全接入，通常在網絡防火墻后設置一個SSL服務器在用戶通過瀏覽器上輸入URL后，該連接通過SSL服務器進用戶身份驗證后映射到相應的應用服務器上實現遠程安全接入；SSLVPN還可對加密隧道進行細分，讓網絡用戶不僅可接入互聯網還可訪問內部資源；SSLVPN還可穿越NAT和防火墻設備；能夠較好地抵御外部系統和病毒攻擊；在網絡部署上靈活方便，因為SSLVPN一般部署在內網中防火墻之后，可以隨時根據需要，添加需要VPN保護的服務器，不影響原有網絡結構。

當然，SSLVPN技術也存在其認證方式僅有通過相應的證書來進行單向認證的不足之處。

3 SSL VPN在多校區校園網中的應用

多校區校園網一般是由于當前同于區域內的多所職業院校進行合并后形成的特色，一般校區分布在不同行政區域，有多個獨立的校區，校區之間地理位置上不接壤等，一般為了實現幾個校區之間的互聯，多采用租用當地通信運行商的光線實現網絡互聯。

在此類校園網絡中，其網絡數據資源如電子圖書館必須要根據電子版權的有關版權保護規定通過安全和加密技術控制分發內容和途徑，以防止非法的使用。在高職院校中多數電子資源都存在IP訪問限制，其數據庫資源多在資源提供商的服務器上。服務商一般采用訪問者的IP地址認證來確認授權的用戶的使用。因此校內的IP都可方便的使用相應資源，而校外的合法用戶，由于在網絡外部，其IP都不在范圍內，就使得他們無法瀏覽所需的網絡資源，這是一種可管理、可認證、安全的遠程訪問校園內部資源的解決方案， SSLVPN方案就解決了校外網用戶訪問校內網的數字資源的問題。同時，SSLVPN也極大的方便校園網中的應用理人員對設備的管理，對于一些簡單的網絡或資源故障，管理人員可以通過SSLVPN對相應的設備進行操作實現故障排除。并且SSLVPN在連接時采用了安全認證，也保證了數據傳輸時的安全。

總之，VPN技術使得未來網絡中基于WEB訪問的網絡資源運行模式起到了極大的促進作用，其中SSLVPN技術也由于大量移動網絡的應用而得以廣泛的應用。

參考文獻：

[1] 馬淑文.SSL VPN技術在校園網中的應用與研究[J].計算機工程與設計，2008（11）：5137-5143.

[2] 陽富民，劉軍平.統一認證技術研究與實現[J].計算機工程與科學， 2007，29（2）：124-126.

[3] 奧尼爾，冉曉旻.Web服務安全技術與原理[M].北京：清華大學出版社，2003.

[4] 戴宗坤，唐三平.VPN與網絡安全[M].北京：電子工業出版社，2002.

篇8

文獻標識碼：A 文章編號：1672-7800（2015）005-0154-04

作者簡介：牛樂園（1990-），女，河南許昌人，中南民族大學計算機科學學院碩士研究生，研究方向為信息安全。

0 引言

人類建立了通信系統后，如何保證通信安全始終是一個重要問題。伴隨著現代通信系統的建立，人們利用數學理論找到了一些行之有效的方法來保證數字通信安全。簡單而言就是將雙方通信的過程進行保密處理，比如對雙方通信的內容進行加密，這樣可有效防止偷聽者輕易截獲通信內容。SSL（Secure Sockets Layer） 及其后續版本 TLS（Transport Layer Security）是目前較為成熟的通信加密協議，常被用于在客戶端和服務器之間建立加密通信通道。TLS是安全傳輸層協議，用于在兩個通信應用程序之間提供保密性和數據完整性。截至目前其版本有1.0，1.1、1.2[1]，由兩層協議組成：TLS 記錄協議（TLS Record）和 TLS 握手協議（TLS Handshake）。

1 TLS協議結構

TLS協議是對SSL協議規范后整理的協議版本，建立在可靠的傳輸層上，如TCP（UDP則不行）。應用層可利用TLS協議傳輸各種數據，來保證數據的安全性和保密性[2]。

安全傳輸層協議（TLS）用于在兩個通信應用程序之間提供保密性和數據完整性。該協議由兩層組成：TLS 記錄協議（TLS Record）和TLS握手協議（TLS Handshake）。較低層為 TLS記錄協議，位于某個可靠的傳輸協議（如TCP）上。

TLS記錄協議是一種分層協議。每一層中的信息可能包含長度、描述和內容等字段。記錄協議支持信息傳輸、將數據分段到可處理塊、壓縮數據、應用 MAC、加密以及傳輸結果等，并對接收到的數據進行解密、校驗、解壓縮、重組，然后將它們傳送到高層客戶機。

TLS記錄層從高層接收任意大小不間斷的連續數據。密鑰計算：記錄協議通過算法從握手協議提供的安全參數中產生密鑰、IV 和 MAC 密鑰。TLS 握手協議由3個子協議組構成，允許對等雙方在記錄層的安全參數上達成一致、自我認證、例示協商安全參數、互相報告出錯條件。

TLS握手協議由3種協議封裝，包括改變密碼規格協議、警惕協議、握手協議。TLS協議結構如圖1所示。

2 TLS1.2消息流程

在整個通訊過程中，為實現TLS的安全連接，服務端與客戶端要經歷如下5個階段[3]：①Client申請鏈接，包含自己可以實現的算法列表以及其它信息；②Server回應鏈接，回應中確定了這次通信所使用的算法，將證書發送給對方，證書中包含了自己的身份和公鑰；③Client在收到消息后會生成一個秘密消息ClientKeyExchange――（此秘密消息經處理后，將用作加密密鑰（會話密鑰）），用Web服務器的公鑰加密并傳至Server；④Server再用私鑰解密秘密消息ClientKeyExchange，并進行處理，生成會話密鑰（用于之后的數據加密），會話密鑰協商成功；⑤Client和Server得到會話密鑰，并用此會話密鑰進行數據加密。

TLS1.2在傳輸層協議的消息主要包含8條消息，消息結構如圖2所示，分別是ClientHello版本協商、ServerHello版本協商、Server Certificate證書消息、HelloDone接收結束標識、 ClientKeyExchange即Client交換密鑰消息、Client的Finished消息、CertificateVeri驗證證書消息、Server的Finished消息。

2.1 ClientHello和消息

ClientServer

client_version|| client_random|| session_id|| cipher_suites|| compression_methods|| extensions

消息描述：該消息包括客戶端的版本號client_version，用于告知服務器client可以支持的協議最高版本，來協商安全協議版本。client_random是client產生的一個隨機數，由client的日期和時間加上28字節的偽隨機數組成，用于后面的主密鑰計算。session_id由服務連接得到，發送給server來建立一個新的會話連接。cipher_suites是client提供給server可供選擇的密碼套件，用于協商密鑰交換，數據加密以及散列算法。compression_methods是客戶端支持的壓縮算法。extensions是客戶端的擴展域。

client_version： Protocol version（協議版本），該字段表明了客戶能夠支持的最高協議版本3.3。

random：它由客戶的日期和時間加上28字節的偽隨機數組成，該客戶隨機數將用于計算master secret（主秘密）和prevent replay attacks（防止重放攻擊）。

session_id：一個會話ID標識一個可用的或者可恢復的會話狀態。一個空的會話ID表示客戶想建立一個新的TLS連接或者會話，而一個非空的會話ID表明客戶想恢復一個先前的會話。session_id有3個來源：①之前的會話連接；②當前連接，客戶端僅僅想通過更新random結構得到連接值時使用；③當前激活的連接，為了建立幾個獨立的連接而不再重復發起連接握手。

2.2 ServerHello消息

ServerClient：

server_version||server_random|| session_id|| cipher_suites|| compression_methods|| extensions

消息描述：該消息包含6個消息項，server_version取客戶端支持的最高版本號和服務端支持的最高版本號中的較低者，本文所用的是TLS1.2。server _random是服務端生成的隨機數，由服務器的時間戳加上28字節的偽隨機數組成，也用于主密鑰的生成。session_id提供了與當前連接相對應的會話的標識信息。從客戶端處接收到會話標識后，服務器將查找其緩存以便找到一個匹配的session_id。

server_version： Protocol version（協議版本），取客戶端支持的最高版本號和服務端支持的最高版本號中的較低者。TLS版本為3.3。random：它由客戶的日期和時間加上28字節的偽隨機數組成，該客戶隨機數將用于計算master secret（主秘密）和prevent replay attacks（防止重放攻擊）。session_id：該域提供了與當前連接相對應的會話的標識信息。如果從客戶端接收到的會話標識符非空，則服務器將查找其緩存以便找到一個匹配。

2.3 Server Certificate消息

ServerClient：

version||serialNumber||algorithmIdentifier||issuer||utcTime||subject_name||subject_key_info|| signature

消息描述：該項消息為可選項，證書主要包含4部分內容，version是證書版本，文章統一定為X509v3。主體名稱指明使用該證書的用戶為server_subject。subject_key_info是證書包含的公鑰信息，該消息項有兩項內容：一個是證書的公鑰，發送給client后用于加密client生成的預主密鑰，并把密文信息發送給server。server收到該密文信息后可以使用自己的私鑰解密得到預主密鑰；另一個是所用的散列算法。signature：證書驗證簽名信息，用以驗證證書。version：證書版本號，為X.509V3。subject_name：證書主體名稱。

subject_key_info：標識了兩個重要信息：①主體擁有的公鑰的值；②公鑰所應用算法的標識符。證書私鑰對證書的所有域及這些域的Hash值一起加密。

2.4 ServerKeyExchange消息

ServerClient：

KeyExchangeAlgorithm|| ServerDHParams

KeyExchangeAlgorithm：密鑰交換算法，文章定義的密鑰交換算法為RSA。ServerDHParams：Diffi-Hellman參數，若交換算法為RSA，則此項為空。

2.5 CertificateRequest消息

ServerClient：

certificate_types|| supported_signature_algorithms|| certificate_authorities

消息描述： 可選消息項，該消息是Server服務器向Client請求驗證證書信息。在一般應用中只對Server服務器進行認證，而Server服務器要允許只有某些授權的Client才能訪問服務器，此時需要用到該消息對Client進行認證。Client認證是通過Server服務器給Client發送一條 CertificateRequest消息而開始，如果Server發送這條消息，則Client必須向server發送自己的證書。客戶端收到該消息后，發送一條 Certifcate 消息（與服務器傳送證書的消息一樣）和一條 CertificateVerify 消息予以應答。

certificate_type：客戶端提供的證書類型，該處為rsa_sign。supported_signature_algorithms：可以驗證server的散列/簽名算法對。certificate_authorities：可以接受證書消息的特定名稱。

2.6 Client Certificate消息

ClientServer：

version||serialNumber||algorithmIdentifier||issuer||utcTime||subject_name||subject_key_info|| signature

消息描述：可選消息項，該證書主要包含4部分內容，version是證書版本，文章統一定為X509v3。主體名稱指明使用該證書的用戶為server_subject。subject_key_info是證書包含的主要公鑰信息，該消息項有兩項內容：一個是證書的公鑰，另一個是所用的散列算法。signature是證書驗證簽名信息，用以驗證證書。

version：證書的版本號，為X.509V3。subject_name：證書主體名稱。subject_key_info：標識了兩個重要信息：①主體擁有的公鑰的值；②公鑰所應用的算法的標識符。算法標識符指定公鑰算法和散列算法（如RSA和SHA-1）。signature：用證書私鑰對證書的所有域及這些域的Hash值一起加密。

2.7 ClientKeyExchange消息

ClientServer：

KeyExchangeAlgorithm|| EncryptedPreMasterSecret

消息描述：該消息是密鑰交換消息。之前的消息協商中規定密鑰交換算法為RSA算法，所以該消息中KeyExchangeAlgorithm的內容為RSA。此時，client隨機生成一個48字節的預主密鑰，用從server證書得來的公鑰來加密這個預主密鑰，加密算法為RSA算法。client加密預主密鑰并在ClientKeyExchange消息中將密文EncryptedPreMasterSecret發給server，使server得到預主密鑰。

KeyExchangeAlgorithm：算法選擇為RSA。EncryptedPreMasterSecret：客戶端生成一個48字節的預主密鑰，用從server證書得來的公鑰來加密該預主密鑰，加密預主密鑰消息并發送密文。

2.8 CertificateVerif消息

ClientServer

handshake_messages[handshake_messages_length]

消息描述：可選消息項，如果服務器請求驗證客戶端，則該消息完成服務器驗證過程。客戶端發送一個certificate_verify消息，其中包含一個簽名，對從第一條消息以來的所有握手消息的HMAC值（用master_secret）進行簽名。handshake_messages指所有發送或接收的握手消息，從clienthello消息開始到CertificateVerif消息之前（不包括CertificateVerif消息）的所有消息集合，包括握手消息的類型和變長字段。這是到目前為止HandShake結構的整合。

3 Blanchet演算模型建立流程

Blanchet演算模型主要包括類型定義、時間定義、方法定義、通道定義、時間聲明、初始化進程描述[4]、客戶端進程描述與服務端進程描述。TLS1.2最主要的功能體現在客戶端與服務端的消息傳遞。

3.1 協議事件聲明

在Blanchet演算中首先要聲明要證明的事件。TLS1.2協議的消息流程中最重要的就是認證性和密鑰的保密性[5]。認證性包括客戶端對服務端的認證和服務端對客戶端的認證，保密性是對會話密鑰的秘密性進行認證。表示server事件發生之前client事件一定發生，用來驗證服務端用戶。在更嚴格的定義下進行服務端驗證，事件聲明代碼如下。

event server（output）.

event client（output）.

query x：output；

event server（x）==>client（x）.

query x：output；

event inj：server（x）==>inj：client（x）.

query secret premastersecret.

3.2 初始化進程

協議模型初始化進程如下所示，ClientProcess表示客戶端進程[6]，ServerProcess表示服務端端進程，表示多個ClientProcess進程并發執行，集中一次模擬現實協議執行。

process

in（start，（））；

new seedone：rsakeyseed；

let pkeyrsa：rsapkey=rsapkgen（seedone） in

let skeyrsa：rsaskey=rsaskgen（seedone） in

new seedtwo：keyseed；

let signpkey：pkey=pkgen（seedtwo） in

let signskey：skey=skgen（seedtwo） in

new keyhash：hashkey；

out（c，（pkeyrsa，signpkey，keyhash））；

（（！ N ClientProcess） |

（！ N ServerProcess） ）

3.3 客戶端和服務端進程

客戶端的消息流程包括版本協商、算法協商、密鑰協商、密鑰交換和請求驗證。版本協商是協商客戶端、服務端可以通用的版本[7]，一般是客戶端和服務端都支持的最高版本，密鑰協商完成后Client向Server發送verifydata認證請求消息，內容包括username、servicename、methodname，method_specific，請求Server驗證身份，并在此定義對客戶端的驗證事件client（verifydata）。

服務端進程首先接收客戶端進程發送的版本信息[8]，并與自己的版本信息匹配協商得到協商版本client_version。版本信息協商完成后接收客戶端所支持的算法信息，至此算法協商完成。進入密鑰協商階段，首先Server接收Client發送的密鑰參數信息c_s_random_s，用來計算hash驗證；Server收到Client的驗證請求后對Client進行驗證并接收Client發來的驗證消息，用所收到的所有消息計算驗證信息。在此插入事件event server（verifydata_fc）來驗證客戶端。

3.4 驗證結果

本文在介紹TLS1.2協議的基礎上對其數據流程進行分析[9]，使用Blanchet建立模型并分析其安全性和認證性。經過一系列的流程跟進并使用自動化證明工具Cryptoverif對TLS1.2進行模型建立，經過一系列的Game轉換得出分析結果如圖3所示[10]。結果證明，TLS1.2協議的會話密鑰具有安全性，在認證階段能夠對客戶端通過消息簽名進行驗證。

4 結語

為了研究TLS1.2協議在應用中的安全性，本文對TLS1.2協議的消息流程進行了分析。通過對每一步消息流中消息項的研究分析，得出TLS1.2協議的整體消息結構，最終實現服務端對客戶端的驗證流程分析。基于Blanchet演算對分析的消息流程應用一致性對服務端認證客戶端和客戶端對服務端的驗證建立模型。協議模型通過協議轉換工具轉換為CryptoVerif的輸入代碼TLS1.2.cv，使用CryptoVerif對模型進行分析，并證明了TLS1.2協議的安全性與認證性。后續研究中將給出TLS1.2協議的Java安全代碼，并分析其安全性。

參考文獻：

[1] 陳力瓊，陳克非.認證測試方法對TLS協議的分析及其應用[J].計算機應用與軟件，2008，25（11）：6-7.

[2] 于代榮，楊揚，馬炳先，等.基于身份的TLS協議及其BAN邏輯分析[J].計算機工程，2011，37（1）：142-144.

[3] MORRISSEY P， P SMART N，WARINSCHI B.The TLS handshake protocol： a modular analysis[J]. Journal of Cryptology，2010，23（2）：187-223.

[4] 盧敏，申明冉.基于RSA簽名的TLS協議的新攻擊發現及其改進[J].消費電子，2013（14）：69-70.

[5] 高志偉，耿金陽.基于優先級策略的 TLS 握手協議研究[J].石家莊鐵道大學學報：自然科學版，2014（3）：69-74.

[6] 唐鄭熠，李祥.Dolev-Yao攻擊者模型的形式化描述[J].計算機工程與科學，2010（8）：36-38.

[7] 邵飛.基于概率進程演算的安全協議自動化分析技術研究[D].武漢：中南民族大學，2011.

篇9

一、Modbus RTU協議與S7-200相互關系簡介

目前支持Modbus通信的DCS、PLC系統和過程儀表大都采用基于串行接口的Modbus RTU模式，西門子公司提供了針對西門子PLC Modbus RTU的協議庫。極大的簡化了Modbus RTU通信的開發，以便快速實現二者的相關應用。通過Modbus RTU從站指令庫，使得S7-200可以作為Modbus RTU中的從站，以實現與Modbus主站設備的通信。

二、軟硬件準備

1.軟件：ModScan測試軟件、Step7-MicroWin V4.0SP06編程軟件、S7-200Modbus指令庫文件。

2.硬件：PC機、西門子S7-200PLC（CUP224XP CN REL02.01）、PPI編程電纜、USB-TO-Serial電纜、RS232轉RS485模塊。

3.焊接RS485通訊電纜一根（Date+ DB9 3引腳、Date- DB9 8引腳）、RS485通訊電纜連接200PLC的Port0端口。

三、使用Modbus 指令庫需要注意事項

1.使用Modbus指令庫，對STEP7 Micro/win軟件版本的要求。軟件版本必須是V3.2或者以上版本。

2.S7-200 CPU必須是固化程序修訂版2.00或最好支持Modbus主設備協議庫。

3.目前市場已經推出針對端口0和端口1的Modbus RTU主站指令庫，以及針對端口0的Modbus RTU從站指令庫，故在使用時一定要區分開。

4.一旦CPU的端口被用于Modbus RTU主站或從站協議通訊時，該端口就無法用于其他用途，包括與STEP7 Micro/win通訊。當需要與STEP7 Micro/win通訊時把CPU打到STOP位即可通訊。

5.利用指令庫編程前首先應為其分配存儲區，否則Step7-MicroWin在編譯時會報錯。分配存儲區時在對話框輸入庫存儲區的起始地址，注意避免該地址與程序中其他地址重復使用，也可以點擊“建議地址”按鈕，系統將自動計算存儲區分配地址。

四、S7-200 PLC控制器組態

我們是用ModScan32做主站來讀取從站（S7-200）的數據。所以在S7-200 PLC里面只用Modbus從站協議指令, Modbus從站協議指令包括MBUS_INT和MBUS_SLVE兩條協議指令。如圖1

圖 1

1.MBUS_INT指令，用于啟用和初始化或停止Modbus從站通信。在使用MBUS_SLVE指令之前，必須執行MBUS_INT指令。在指令完成后立即設定“完成”位，才能執行下一條指令。MBUS_INT指令引腳含義如下：

1.1EN：西門子指令使能位。因為是初始化用觸點SM0.1即可。

1.2Mode：“模式”參數。用于啟動和停止Modbus通信，允許使用以下兩個數值：1-啟動，2-停止。

1.3Address：“地址”參數。輸入Modbus從站地址，取值范圍為1～247.

1.4Baud：“波特率”參數。Baud：“波特率”參數可選1200、2400、9600、19200等。

1.5Parity：“奇偶校驗”參數。0-無校驗；1-奇校驗；2-偶校驗。

1.6Delay：“延時” 參數。附加字符間延時，默認值為0。

1.7MaxIQ：“最大I/Q位”參數。設置參與通信的最大I/O點數，S7-200的I/O映像區為128/128，默認值為128。

1.8MaxAI：“最大AI字”參數。設置參與通信的最大AI通道數，可為16或32。

1.9MaxHold：設定供Modbus地址4xxxx使用的V存儲器中的字保持寄存器數目。

1.10HoldStart：保持寄存器區起始地址，以&VBx指定。

1.11Done：初始化完成標志，成功初始化后置1。

1.12Error：初始化錯誤代碼。0-無錯誤。

2.MBUS_SLVE指令，用于Modbus主設備發出請求服務，并且必須每次掃描時執行，以便允許該指令檢查和回復Modbus請求。MBUS_SLVE指令無輸入參數，在每次的掃描EN開啟時執行。MBUS_SLVE指令引腳含義如下：

2.1EN：西門子指令使能位。因為每個周期都需要執行，故用SM0.0即可。

2.2Done：“完成”參數。Modbus執行通信時置1，無Modbus通信活動時為0。

2.3Error：錯誤代碼。0-無錯誤。

五、測試軟件ModScan32設置

ModbusRTU測試軟件ModScan32，在通訊中是中主站，監視從站和向從站發送命令。以下是ModbusRTU測試軟件ModScan32如圖2： 圖 2

ModScan32測試軟件的畫面中相關參數意義如下:

1.通信端口的選擇。如果PC用的 RS485 轉換器接的是串口一（COM1），此下拉選項設置為 COM1 即可。

2.Baud：波特率的選擇。與S7-200 PLC內設置保持一置。

3.Word：數據位。默認值8。

4.Parit：奇偶校驗。與S7-200 PLC內設置保持一置。

5.Stop：停止位。默認值1.

6.Device Id：下位機地址。與S7-200中MBUS_INT模塊的Address引腳一置。

7.Address：寄存器的起始地址。

8.Length：寄存器長度。

9.MODBUS Point Type：Modbus點類型選擇。依次出現的是繼電器狀態、輸入狀態、鎖存器、輸入寄存器。

10.Number of Polls：發送和接受命令的次數。

11.Valid Slave Responses：有效命令的次數。

六、通訊測試

S7-200 PLC和測試軟件ModScan32設置完畢后，系統上電、通訊線連接好就可以進行調試。Modbus RTU地址與S7-200的地址對應關系 Modbus地址總是以00001、30004之類的形式出現。S7-200內部的數據存儲區與MODBUS的0、1、3、4共4類地址的對應關系所示:

MODBUS地址

S7-200數據區

00001-00128……………………………Q0.0-Q15.7

10001-10128……………………………I0.0-I15.7

30001-30032……………………………AIW0-AIW32

40001-4xxxx……………………………T + 2*(xxxx-1)

其中T為S7-200中的緩沖區起始地址，即HoldStart。如果已知S7-200中的V存儲區地址，推算MODBUS地址的公式為：MODBUS地址=40000+(T/2+1)

篇10

一、借用條款

1、借用條件：

甲方使用乙方的adsl寬帶上網業務。

2、甲方借用乙方adsl設備（限壹臺），設備具體描述如下：

品牌：

型號：

序列號：

3、該adsl設備所有權歸乙方所有，在甲方使用乙方adsl寬帶業務的前提下，乙方將此臺adsl設備免費借給甲方使用。

4、借用期內，若甲乙雙方中任何一方提出停借請求，都必須以書面形式提前一個月通知對方，經雙方協商一致，甲方歸還adsl設備給乙方后雙方解除本協議。

二、雙方的責任和義務

1、借用期內若甲方暫停使用adsl寬帶業務，應將adsl設備歸還乙方，本協議同時自動終止。用戶恢復使用adsl業務后如需要再借用設備必須重新簽定借用協議。

2、借用期內若甲方取消使用adsl寬帶業務，將視為甲方單方面終止協議，甲方必須將adsl設備及時歸還給乙方，本協議自動終止。

3、乙方保證所提供adsl設備的質量。在借用期內，甲方必須妥善保管adsl設備。

4、借用期內，如果adsl設備因質量原因發生故障，甲方可將設備帶到乙方處更換。

5、借用期內，如果adsl設備因人為損壞發生故障，經原生產廠家確認可以維修，甲方需承擔維修費用，乙方將負責提供備用設備保證甲方正常使用，直到設備修理好后雙方置換；如果原生產廠家確認設備無法維修，本協議自動終止，甲方需承擔設備賠償責任，具體賠償金額為____________________元。賠償費用一次性在電話______________托收。

6、借用期內，乙方免費提供該設備的首次安裝、調試服務，并代為培訓該設備的安裝調測方法，至于其它范圍的服務，以乙方公開的服務承諾為準。

7、如出現以下情況之一，本協議將自動終止：

第一種情況：甲方暫停使用乙方adsl業務；

第二種情況：甲方由adsl業務轉為其它寬帶業務；

第三種情況：甲方不再使用乙方adsl業務；

8、協議終止前甲方應將adsl設備（包括設備、外包裝、說明書、連線、包裝盒內附屬配件等）及其它連同adsl設備一同借用的附屬設備（語音分離器等）一并完好歸還。若歸還時發生包裝不全、設備缺損等情況，甲方應負責補全，否則甲方應照價賠償。

三、爭議和仲裁

1、所有與本協議執行有關的爭議將通過雙方友好協商解決，如果雙方不能通過友好協商解決爭議，則將該爭議提交至鎮江市仲裁委員會仲裁。

2、仲裁裁定的最終結果對雙方均有約束力。

3、仲裁費用由敗方承擔。

4、仲裁進行過程中，雙方將繼續執行仲裁部分以外的協議內容。

四、其它事項

1、本協議由于不可抗力導致不能履行的，雙方均不承擔違約責任，共同協商變更或解除協議。

2、本協議與國家法律法規或上級部門的政策和規定相抵觸時，應依據國家法律法規或上級部門的政策和規定變更本協議。

3、本協議自雙方簽字蓋章之日起生效，該協議在甲方使用乙方adsl寬帶業務期間有效。本協議一式兩份，雙方各執一份，具有同等法律效力。

篇11

Logistic方程是荷蘭生物學家Verhulst在19世紀中葉提出的，它不僅能夠大體上描述人口及許多物種數量的變化規律，而且在經濟、管理、傳染病學等領域也有著廣泛的應用。因為由這一方程建立的模型能夠描述一些事物符合邏輯的客觀規律，所以稱它為Logistic方程。最初的人口模型是英國著名人口學家Malthus調查了英國一百多年的人口統計資料，得出了人口增長率r不變的假設，并據此建立了著名的人口增長模型

（1）

其中N=N（t）表示時刻t的人口數量，N0是初始時刻人口的數量，很容易解出

（2）

當r>0時，（1）式表示人口數量按指數規律隨時間無限增長。但從長期來看，任何地區的人口都不可能無限增長。實際情況是人口增長到一定數量以后，增長速度就會慢下來。因為自然資源、環境條件等因素對人口的增長都會起到阻滯作用，而且隨著人口的增加，這種阻滯作用會越來越大，所以人口增長率 就不應該是個常量，應該隨人口數量的增加而變小。不妨令 ，其中Nm是自然資源和環境條件所容納的最大人口數量，r為固有增長率。可以看到當N=Nm時，人口就不再增長，即r（Nm）=0。于是得到人口的阻滯增長模型（Logistic模型）

（3）

rN體現人口自身的增長趨勢，因子 則體現了資源和環境對人口增長的阻滯作用。若以N為橫軸，dN/dt為縱軸，方程（3）的圖形（圖1），可以看到人

圖1 圖2

口增長速度dN/dt隨N的變化趨勢先快后慢，當N=Nm/2時增長速度最快。方程（3）可以用分離變量法求得 （圖2），是平面上一條S形曲線，人口增長速度先快后慢，當t∞時，NNm，拐點在N=Nm/2處。這個模型描繪的人口變化趨勢與實際情況基本符合，而方程（3）稱為Logistic方程，方程右端帶有阻滯增長因子。

2 Logistic方程在技術革新推廣中的應用

社會的進步離不開技術的進步創新，對于一項新技術在該領域中推廣一直是經濟學家和社會學家關注的問題。假設在某一社會中某領域共有Nm個企業，初始時刻有N0家企業采用了一項新技術，N（t）表示t時刻采用新技術的企業數量， 那么這項技術如何推廣到該領域中的其它企業，其它企業將以怎樣的速度接受該技術呢？在推廣過程中我們可以認為，對于一個尚未采用新技術的企業家來說，只有當采用新技術的企業家對他談論了該技術后，他才有可能會采納。那么在t到t+t這段時間內，新增的企業數量N應該與之前已采納新技術的企業數量N（t）和還不知道這項技術的企業數量Nm-N（t）成正比，即

其中c為比例系數，它與人們接受新事物的能力，新技術轉化為生產力等方面有關

當t0時，得

（4）

（5）

方程（4）為技術革新推廣的Logistic模型，從方程（4）中還可以看到，企業家采用這一新技術的速度是先快后慢，當數量未達到Nm/2時，接納的速度越來越快，到達Nm/2后速度開始減慢，直到趨向于零，最終所有的企業都進行了技術革新，淘汰舊技術，采用新技術。

3 Logistic方程在傳染病學中的簡單應用

隨著科技的進步、衛生設施的改進、醫療水平的提高以及人們對自身健康的關注，曾經一些全球肆虐的傳染病像天花、霍亂已得到控制，但一些新的、變異的傳染病悄悄地向人類襲來。像上世紀的艾滋病、2003年SARS、今年的H7N9禽流感病毒，給我們的生命和財產都帶來了極大的危害。因此建立傳染病模型，分析感染人數的變化規律是一個有必要的工作。在這里我們建立關于傳染病傳播的簡單模型。

假設在疾病傳播期內所考察地區的總人數N不變，不考慮出生、死亡、遷移。人群分為易感者和已感染者，以下稱為健康人和病人。t時刻這兩類人在總人數中所占比例分別記作s（t）和i（t），每個病人每天有效接觸人數為常數λ，λ稱為日接觸率。那么從t到t+t時間段內新增病人人數為N[i（t+t）-i（t）]=λNs（t）i（t）t s（t）+i（t）=1

整理得到

當t0時，得 （6）

它的解為 （7）

其中i0為初始時刻病人所占比例。

由方程（6）及其解（7）同樣可以看到i=1/2時，病人增加得最快，可以認為是醫院門診量最大的一天，預示著傳染病的到來，此時 ，當有效接觸數λ越小，這一天來臨得就越晚，所以為了推遲這一天的到來，可以通過改善衛生環境、提高醫療水平、對患者作必要的隔絕來降低λ的值。另外一方面，從（7）可以看到當t∞時，i1即所有人都會感染，顯然不符合實際。這是因為我們沒考慮病人會被治愈，考慮到這一因素，只需要在方程（6）的右端再減去一個因子μi（μ表示日治愈率）即可，在這里我們就不討論。

由于Logistic方程能夠反映出一些事物本身符合邏輯的規律，它在社會、經濟、科學研究中都有著重要的作用，非常值得我們去深入研究。

參考文獻：

[1] 龔德恩，范培華.微積分[M].北京：高等教育出版社，2008.

[2] 姜啟源，謝金星，葉俊.數學模型（第3版）[M].北京：高等教育出版社，2004.

篇12

作為Lotus Notes和Domino協作軟件的重大拓展計劃,IBM Lotus將向Nokia Symbian設備、BlackBerry、Google Android操作系統和iPhone提供全新支持,以滿足日益增加的移動設備對企業應用和業務流程的需求。

據IDC預計,到2011年,市場將有1萬億與互聯網相連接的設備。為此,Lotus致力于向所有移動設備提供支持,保證用戶無論身處何處都能夠提供服務。如今,Lotus已率先為移動設備提供了最廣泛的郵件和協作支持,包括新版Lotus Notes Traveler軟件將對Google Android手機操作系統2.0和2.1版本提供協作支持。

IBM在本次大會上了“協作議程”(Collaboration Agenda),它集合了IBM行業領域的專家和專業知識、軟件實驗室的技術專家以及咨詢服務專家,旨在通過協作技術和行業專長,為企業量身定制協作路線圖和戰略,幫助企業改善人員互動方式,加速業務流程,實現可衡量回報。

篇13

工業控制己從單機控制走向分散控制，并走入網絡時代。工業控制網絡為數據采集、工業控制提供了方便，節省了成本，提高了性能。實際應用中，往往需要不同廠家控制系統的數據共享，或某集成系統不能滿足控制需要而額外加系統，需要將2種不同系統進行互聯。

1.Modbus協議簡介

Modbus協議是應用于控制器上的一種通用語言。通過此協議，控制器相互之間、控制器和其他設備之間可以進行通信。它己成為一種通用工業標準。通過Modbus 協議，不同廠商生產的控制設備可以連成工業網絡。

標準的Modbus 協議使用RS-232C兼容串行接口，它定義了連接口的針腳、電纜、信號位、傳輸波特率、奇偶校驗等。控制器能直接或經山Modem組網。Modbus協議將通訊參與者規定為“主"(Master)和“從”(Slave)。主設備可單獨和從設備通信，也能以廣播方式和所有從設備通信，而從設備之間不能通信。

Modbus協議建立了主設備查詢的格式:設備(或廣播)地址、功能代碼、所有要發送的數據、錯誤檢測域。設備(或廣播)地址提供從機地址，從機根據地址判別是否接收請求，以做出相應響應，用戶必須設置每臺從機的地址。功能代碼告訴從機該完成什么樣的動作，例如功能代碼3表示讀取從機保持寄存器并返回其中的內容，數據區的內容就必須包括從機的寄存器地址，需要讀的寄存器的個數。錯誤校驗域用于校驗信息是否正確傳輸，采用循環冗長檢測方法，CRC域附加在消急的最后，添加時先是低字節然后是高字節。故CRC的高位字節是發送消息的最后一個字節。

2.通信系統硬件組成及連接

Modbus 協議運行在RS-232/RS-485標準的接口系統中，實際應用中，可根據現場情況決定用哪一種:RS-232只能實現一對一的連接，其傳輸速率局限于20 Kbps,并且傳輸距離在沒有Modem的情況下只有15m左右(用戶可以用Modem擴展傳輸距離);RS-485最多可驅動32臺設備，其傳輸距離在100 Kbps時可達1200m。

TPS系統的RS-485接口最多可以連接15個設備，連接方法可參考手冊，終端要有120Ω的終端電阻。

3.通信系統硬件組態及編程

3.1 TPS系統組態

首先對SI IOP進行組態。在HPM(APM)控制功能組態中有以下一些參數與通訊有關:

NNUMERIC：Numeries量的最大個數，要求為16的倍數。

NSTRING：Strings量的最大個數，要求為16的倍數。

NTIME：Times量的最大個數，要求為32的倍數。

NARRSLOT：最大可以設置256個A rray點，其中最多80個可用于SI卡。

SCANPER：指明HPMM(APMM)以多長的周期掃描SI數據并把它們打包進Array點中，此參數影響到A rray點的最大設置量。當掃描周期為1s時，A rray點最多為80個;當掃描周期為0.5s時，Array點最多為40個;當掃描周期為0.25s時，Array點最多為20個。

組態畫面的第2頁組態Array點的類型、大小和起始地址索引。注意每種點的類型不能超過其規定的大小。其起始地址可為。0-99999之間的任意數值，TPS系統通過起始地址定義Modbus功能號和數據傳送地址，其中最高位決定所選用Modbus功能號，低4位為Modbus功能號讀/寫數據的地址。

3.2 Siemens PLC中的組態與編程

CP341/CP441-2模塊是西門子S7-300/400系列PLC中支持Modbus串行通訊的模塊，CP341有1個(CP441-2有2個)串行通訊口(RS-232C或TTY或RS-485/422)。以使用這種通訊模塊實現S7 300/400與Modbus主從站通訊，該系統使用CP341。要實現Modbus通訊時，需要在CP341/CP441-2模塊上插入相應協議的硬件狗，CP模板才能夠支持Modbus(RTU格式)。

首先安裝STEP7 5.x軟件和CP34.x模板所帶的軟件驅動程序。模板驅動程序包括了對CP341進行參數化的窗口、用于串行通訊的FB程序塊、模板不同應用方式的例子程序，CP341模板手冊的附錄B中說明了CP模板通訊口的針腳定義。當系統上電，CP341模板初始化完成后，SF燈點亮;斷電，在CP模塊上插入Modbus從站硬件狗，然后安裝Modbus從站軟件包，安裝完軟件包后，就可在項目中組態Modbus從站，雙擊CP341模塊，記錄下模板的硬件地址(編程時用到此參數)，在模塊的屬性窗口中點擊Parameter:按鈕，選擇Modbus從站協議，將PC和PLC連接起來，PLC上電，點擊Load Drivers圖標，彈出裝載驅動窗口:點擊Load Drivers按鈕，完成從站驅動安裝過程，進行Modbus驅動裝載的時候,PLC必須處于STOP狀態。再雙擊信封圖標，打開Modbus從站參數設置窗口，具體設置參數有波特率、數據位、奇偶校驗位、停止位、從站地址等。

設置完參數后進行編程，FB80是CP341的Modbus通訊功能塊，Modbus通訊功能塊用DB80作為其背景數據塊。FB 180是CY441-2的Modbus通訊功能塊，其背景功能塊為DB180，這2個功能塊必須在用戶程序的循環程序中運行(通常為081)。在081中調用FB80/ FB180，設置其輸入輸出參數，FB80和FB 180中參數具體可參考手冊。

PLC每一次冷啟動后必須進行1次Modbus功能塊初始化設置，具體體現為給CP_STA-RT 1個上升沿觸發信號，OB100為PLC冷啟動后執行的第1個功能塊，此處OB100是為通訊進行一些初始化設置。Modbus通訊功能塊調用FB 7 "PRCV_RK"(Receive data)和FB 8“P_SN D_RK"(Send data)(CP341)，SFB BSEN D( CP 441-2)進行CP和功能塊之間的通信，故相應的功能塊也應組態在工程中并下裝到CPU中。

4.結束語

目前DCS在石化企業中應用相當廣泛，但在一些場合，比如開關量較多、安全可靠性要求不是很高、信號比較集中等場合，DCS并不是最佳選擇，這時候也可以考慮PLC和DCS相結合的方法。使用這種方法，不但減小了TPS系統的控制負荷，提高了控制精度，而且費用較低，起到了良好的經濟效益。　[科]

【參考文獻】