2023年銀聯銀行卡聯網聯合技術規范V第部分通訊接口_第1頁
2023年銀聯銀行卡聯網聯合技術規范V第部分通訊接口_第2頁
2023年銀聯銀行卡聯網聯合技術規范V第部分通訊接口_第3頁
2023年銀聯銀行卡聯網聯合技術規范V第部分通訊接口_第4頁
2023年銀聯銀行卡聯網聯合技術規范V第部分通訊接口_第5頁
已閱讀5頁,還剩22頁未讀 繼續免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

Q/CUP

中國銀聯股份有限公司企業標準

Q/CUP006.5—2012

代替Q/CUP006.5—2011

中國銀聯銀行卡聯網聯合技術規范V2.1

第5部分通信接口規范

TechnicalSpecificationsonBankcardInteroperabilityV2.1

Part5SpecificationonCommunicationInterface

2012-11-02發布2012-11-02實施

中國銀聯股份有限公司發布

Q/CUP006.5—2012

目次

前言..................................................................................II

1范圍.....................................................................................1

2銀聯網絡概述.............................................................................1

2.1規范要求..............................................................................1

2.2銀聯網絡拓撲結構.....................................................................1

2.3入網機構接入線路選擇..................................................................1

3網絡接口...............................................................................2

3.1入網機構的物理接入方式...............................................................2

3.2接入設備要求.........................................................................3

4通信接口協議.............................................................................4

4.1概述...................................................................................4

4.2通信配置.............................................................................5

4.3協議定義...........................................................................12

參考文獻..................................................................................22

附錄A(資料性附錄)入網機構通訊線路數量計算原則..................................23

Q/CUP006.5—2012

%*—a-

刖三

本標準對中國銀聯跨行交易網絡中聯機交易與文件傳輸的通信接口應滿足的要求做了規定,包括

通信鏈路的選擇、接入方式選擇、接入設備的要求和通信協議的規定。

本標準由中國銀聯股份有限公司提出。

本標準由中國銀聯股份有限公司制定。

本標準起草單位:中國銀聯股份有限公司、國內入網機構。

本標準主要起草人:戚躍民、郭銳、鄭澎、徐靜雯、李潔、吳金壇、王力斌、苗恒軒、萬高峰、

陸爾東、蔣慧科、杜秉一、趙偉。

Q/CUP006.5—2012

中國銀聯銀行卡聯網聯合技術規范V2.1

第5部分通信接口規范

1范圍

本標準規定了中國銀聯跨行交易網絡中聯機交易與文件傳輸的通信接口應滿足的要求,包括通信

鏈路的選擇、接入方式選擇、接入設備的要求和通信協議的規定。

本標準適用于所有加入中國銀聯銀行卡信息交換網絡的入網機構。

2銀聯網絡概述

2.1規范要求

銀聯網絡要求穩定可靠、結構簡單、便于維護管理。入網機構必須遵照本規范對網絡通信接口方

面的要求,建設與銀聯網絡的接口,保障各入網機構和銀聯網絡之間互聯互通,并提供銀行卡信息安

全、穩定、可靠的存取控制。

2.2銀聯網絡拓撲結構

銀聯網絡是一個二層的網絡結構,其中的網絡節點按層次不同,可劃分為:核心節點:上海信息

中心/北京信息中心;骨干節點:銀聯分公司,如圖1所示。

圖1銀聯網絡結構示意圖

全國性的入網機構與境內的外資銀行,(如全國性的商業銀行總行、匯豐銀行境內機構)直接與

上海信息中心與北京信息中心連接,屬于直接接入機構。

間接接入機構,如當地農村信用社或城市商業銀行,選擇當地銀聯分公司接入銀聯網絡;而全國

性入網機構在各地的分之機構可選擇當地的銀聯分公司接入,也可以采用總對總的方式,通過其全國

性入網機構接入銀聯網絡。

2.3入網機構接入線路選擇

2.3.1直接接入機構接入線路選擇

根據目前運營商的分布情況,電信主要服務中國南方地區,而新聯通主要服務中國北方地區,因

此對于全國性入網直接接入機構與境內外資銀行的接入要求如下:

采用電信的SDH線路與上海信息中心互聯,對于交易量大的機構可采用MSTP的方式進行接入。

I

Q/CUP006.5—2012

采用新聯通的SDH線路與北京信息中心互聯,對于交易量大的機構也可以采用MSTP的方式接入。

2.3.2間接接入機構接入線路選擇

銀聯分公司與間接接入機構在通訊接入線路上的選擇視各地區具體情況確定,但每一個接入機構

都應有主備通訊設備和主備通訊線路,并且主備線盡量選擇當地不同的運營商,防止通訊設備與線路

的單點故障。

3網絡接口

3.1入網機構的物理接入方式

3.1.1直接接入機構接入方式

對于全國性的入網機構與境內的外資銀行通過直接與上海信息中心、北京信息中心互聯的方式接

入,并且選擇電信、新聯通運營商的SDH或MSTP線路。如下圖:

圖2直接接入機構接入方式

3.1.2間接接入機構接入方式

間接接入機構,可采取就近接入方式,根據當地的實際情況選擇1-2家不同運營商的專線接入當

地的銀聯分公司。如下圖:

2

Q/CUP006.5—2012

對于上述兩種接入方式的說明如下:

直接接入機構須采用電信與新聯通的兩個不同的運營商的SDH或MSTP線路與上海信息中心、北京信

息中心互聯。

間接接入機構可以根據具體情況選用其他通信鏈路方式(建議使用SDH、MSTP線路),但必須滿足

本規范中的使用兩條通信鏈路和備份鏈路的規定。

正常情況下,兩條鏈路分別承載實時交易數據和非實時數據,當任何一條鏈路中斷時,另外一條

中繼線路可以承載全部的數據。為了保證實時交易數據總是被優先處理,建議在路由器上對交易數據

流使用LLQ的Qos策略。

3.2接入設備要求

3.2.1基本要求

銀聯要求各入網機構選擇路由器作為廣域網接入設備。

路由器是廣域網(WAN)之間互連的關鍵設備。路由器支持不同的廣域網物理接口,能夠實現負載

平衡,阻止廣播風暴,控制網絡流量以及提高系統容錯能力。

3.2.2設備接口要求

3.2.2.1物理接口

入網機構與銀聯網絡互連的廣域網設備應支持下述接口:

a)高速同步串行接口

b)G.703-E1接口

c)10Base-T和lOOBaseT接口

3.2.2.2互聯使用協議

a)互聯線路使用的封裝協議:

HDCL

PPP

Ethernet

b)互聯使用的路由協議:

靜態路由

常用動態路由協議

c)網絡管理/安全協議:

SNMP

TelnetRemoteAccess

AccessLists(Routing)

DebugCommands

PingCommands

Syslog

EventLogging

3.2.3網絡互聯與線路切換

3.2.3.1直接接入機構的互聯與線路切換

直接接入機構采用浮動靜態路由或動態路由協議實現與上海信息中心或北京信息中心的互聯互通。

在配置中確保互聯上海信息中心的線路為主用線路,當該線路故障時,機構路由能自動切換至與北京

信息中心的備用線路上,而當主用線路故障恢復后,路由又能自動回切至主用線路上。如下圖:

3

Q/CUP006.5—2012

3.2.3.2間接接入機構與銀聯分公司的互聯與線路切換

間接接入機構與銀聯分公司采用浮動靜態路由實現互聯互通。當主線中斷時,機構的路由能自動

切換至備線上,當主線恢復時,路由能實現自動回切。如下圖:

4通信接口協議

4.1概述

銀聯處理中心和入網機構在物理通訊線路連通的基礎上,需要雙方建立一定的通信連接并制定相

應的通信控制協議,實現雙方之間聯機報文的處理和文件傳輸。銀聯處理中心和入網機構應根據實際

的需要,在以下方面滿足通信的要求:

a)銀聯處理中心和入網機構建立的通信連接方式;

b)雙方采用的通信協議;

c)雙方通信設備上運行的通信軟件。

4

Q/CUP006.5—2012

4.1.1通信連接的選擇

在TCP/IP協議的基礎上,使用socket編程接口編寫通信程序。一個socket連接由本地IP地址、端

口號和遠端IP地址、端口號唯一確定。

IPlIP2

圖4socket連接示意圖

銀聯處理中心和入網機構建立的socket連接種類應能滿足業務的處理要求。對于實時性要求高的

聯機交易,銀聯處理中心和入網機構建立的連接是長連接,銀聯處理中心將不再支持短連接的方式。

對于實時性要求不高的文件傳輸,銀聯處理中心和入網機構采用短連接的方式。

4.1.2協議和通信設備要求

銀聯處理中心向入網機構提供TCP/IP協議通信接口,與入網機構的通信程序使用套接字(socket)

技術編寫。在銀聯處理中心一側,通信服務器上安裝有與入網機構通信的socket通信軟件,該軟件提

供的通信接口符合本規范的通信控制協議。在入網機構一側,通信主機上也應安裝有相應的通信軟件,

該通信程序也應符合本規范規定的通信控制協議,實現與銀聯處理中心的通信。

入網機構路由器廣域網口應對銀聯處理中心開放,使銀聯處理中心能夠通過簡單網絡管理協議或

網絡連通測試等方法獲得與各入網機構通信連通狀況的信息,便于銀聯處理中心對通信網絡進行監控

和管理。

4.2通信配置

4.2.1IP地址和端口號配置

各入網機構接入銀聯網絡使用的IP地址由銀聯處理中心統一分配。入網機構和銀聯處理中心通信

所用的端口號由雙方各自決定。測試系統與生產系統使用不同的IP地址。

4.2.1.1聯機交易的IP地址和端口號配置

銀聯處理中心使用多臺聯機交易通信服務器與一個入網機構通信,每臺通信服務器應有一個IP地

址。為了便于管理和配置以及提高系統的可用性,在每一個IP上,銀聯處理中心通過分配不同的端口

號和入網機構建立多條連接,每個端口號只能建立一條socket連接,如下圖所示。

5

Q/CUP006.5—2012

圖5銀聯處理中心和入網機構聯機交易連接示意圖

在圖5中,IP1和IP2的portl和port2均用于和入網機構1連接,port3和port4用于和入網機構2

連接。

同樣,入網機構也要為銀聯處理中心發起建立的每條連接指定不同的端口號,指定的端口號均應

介于1024與65535之間。

4.2.1.2文件傳輸的IP地址和端口號配置

銀聯處理中心使用多臺文件服務器與入網機構進行文件傳輸。

在分配給機構的ip上,銀聯處理中心給入網機構指定建立連接的端口號,入網機構也要為銀聯處

理中心指定建立連接的相應IP地址和端口號。

圖6銀聯處理中心和入網機構文件傳輸連接示意圖

4.2.1.3IP地址和端口限制

6

Q/CUP006.5—2012

在聯機交易中,銀聯處理中心為每個入網機構分配的聯機交易通信服務器或文件服務器的IP地址

和端口號都已經確定。為了便于管理和保障系統安全性,銀聯處理中心不允許入網機構使用提供給其

他入網機構的IP地址和端口號。銀聯處理中心通信程序對請求建立連接的遠端IP地址做合法性檢查,

如果是規定的IP地址則允許建立連接,否則拒絕連接。

圖7IP地址和端口限制示意圖

4.2.2連接數目和方式

4.2.2.1聯機交易的連接數目和方式

聯機交易采用長連接的方式。Socket連接建立后,除非發生異常中斷,否則雙方不再關閉連接,

始終保持連通狀態,雙方可以直接發送或接收數據。

銀聯支持入網機構采用單工和雙工兩種通訊方式的接入。

4.2.2.1.1單工方式

單工方式是指一條連接只用于單方向的接收或發送。只用于發送交易報文的長連接稱為發送長連

接,只用于接收交易報文的長連接稱為接收長連接。由一條發送長連接和一條接收長連接組成一個通

訊連接對。對于單工方式本規范規定:

(1)在一個連接對中,如果是入網機構發現它的發送長連接中斷,則關閉連接對中的接收長連接,

并向處理中心重新發起連接請求,重建連接對的網絡連接,電建時不能對其他連接對斷鏈亞連。

(2)在一個連接對中,如果入網機構檢測到,發送長連接或接收長連接已經被中斷,則認為該連

接對已經中斷,將關閉本連接對中的所有連接,并向處理中心發起連接請求。如果入網機構檢測到3

分鐘之內在接收連接上沒有收到任何報文(包括空閑連接查詢報文),則認為該接收連接已經中斷,

將關閉本連接對中的發送長連接,并向處理中心發起連接請求,重建該連接對的網絡連接,商建時不

能對其他連接對斷鏈重連。

(3)在一個連接對中,如果處理中心發現連接對中的發送長連接中斷,而相應的接收長連接正常

時,則處理中心首先關閉接收長連接,然后恢復到偵聽狀態,等待入網機構重新發起建立連接的請求。

如果處理中心檢測到3分鐘之內在接收連接上沒有收到任何報文(包括空閑連接查詢報文),則認為該

7

Q/CUP006.5—2012

接收連接已經中斷,將關閉本連接對中的發送長連接,然后恢復到偵聽狀態,等待入網機構重新發起

建立連接的請求。

(4)只要處理中心接收到入網機構建立發送長連接的請求,即使此時處理中心的發送長連接是正

常的,也需要斷開當前發送長連接,按照入網機構請求重建新的發送長連接。

圖8聯機交易的連接示意圖

入網機構和銀聯處理中心建立的長連接數應和入網機構的交易量有關。銀聯處理中心提供二進二

出共四條單工長連接到八進八出共十六條單工長連接的連接方式,入網機構應根據自己的交易量大小

選擇其中之一。

入網機構

圖9二進二出單工長連接示意圖

8

Q/CUP006.5—2012

圖10四進四出單工長連接示意圖

銀聯處理中心給每個入網機構指定至少兩臺通信服務器,因此入網機構和銀聯處理中心的連接對

必須是偶數的,每臺通信服務器上的連接數至少是一進一出兩條單工長連接。六進六出單工長連接和

八進八出單工長連接的示意圖均類似圖9和圖10。在系統運行中,應對具體的連接數目做參數化管

理,可以根據入網機構具體交易量大小情況做調整。

4.2.2.1.2雙工方式

雙工方式是指一條連接既做為接收長連接又作為發送長連接,僅由一條連接就完成了接收和發送

的功能。對于雙工方式本規范規定:

(1)在雙工方式中,如果入網機構檢測到,該連接已經被中斷,則關閉本連接,并向處理中心發

起連接請求,重建連接對的網絡連接。

(2)如果入網機構檢測到3分鐘之內在連接上沒有收到任何報文(包括空閑連接查詢報文),則

認為該連接已經中斷,將關閉本連接對,并向處理中心發起連接請求,重建該連接對的網絡連接。

(3)在雙工方式中,如果處理中心發現連接中斷,則處理中心將恢復到偵聽狀態,等待入網機構

重新發起建立連接的請求。如果處理中心檢測到3分鐘之內在連接上沒有收到任何報文(包括空閑連接

查詢報文),則認為該連接已經中斷,將關閉本連接對,處理中心將恢復到偵聽狀態,等待入網機構

重新發起建立連接的請求。

(4)只要處理中心接收到了入網機構建立連接的請求就應該立刻響應。

9

Q/CUP006.5—2012

圖11聯機交易的連接示意圖

入網機構和處理中心建立的長連接數應和入網機構的交易量有關。處理中心提供兩條雙工長連接

到八條雙工長連接的連接方式,入網機構應根據自己的交易量大小選擇其中之一。

處理中心給每個入網機構指定至少兩臺通信服務器,因此入網機構和銀聯處理中心的雙工長連接

必須是偶數的,每臺通信服務器上的連接數至少是一條雙工長連接。在系統運行中,應對具體的連接

數目做參數化管理,可以根據入網機構具體交易量大小情況做調整。

4.2.2.1.3支持應答報文原路返回

應答報文原路返回的含義是:支持在回送應答報文時使用該交易請求報文上送時的線路進行回送,

機構可以選擇是否要求CUPS對應答報文原路返回。

如果入網機構沒有選擇開啟此功能,則入網機構作為受理方上送的交易經過CUPS處理后,將應答

報文發送給入網機構時,將在入網機構與CUPS已經建立的通信線路中任意選擇一條線路作為報文返回

線路。

如果入網機構選擇開啟此功能,則入網機構作為受理方上送的交易經過CUPS處理后,將應答報文

發送給入網機構時,將選擇入網機構上送報文時的使用的線路作為報文返回線路。

若在返回應答時,發送請求時的線路與CUPS斷開,機構可以選擇由CUPS將應答報文通過其他工作

正常的線路返回,機構也可以選擇由CUPS丟棄此應答報文。

雖然真正含義上的原路返回為上文定義的內容,但銀聯處理中心還支持更廣義的概念,能夠提供

如下兩個粒度的原路返回功能:

1、對機構的通訊主機,銀聯可提供通訊主機組管理,原路返回粒度可控制到該組。即,只通過該

組內的連接返回,但并不是發起請求的連接。這樣可以控制是返回到同一個處理中心,還是返回到同

一臺通訊主機;

2、對機構的通訊主機,銀聯還可提供單個IP管理,原路返回粒度可控制到該IP。即,只通過該IP

中的連接返回,但并不是發起請求的連接。

因此,銀聯處理中心是提供了更為廣義的“線路組原路返回”概念。即,交易應答可以通過與交

易請求上送線路在同一組的任一線路返回。線路分組的方法可以應入網機構的要求采取不同的策略(比

如:入網機構側屬于同一個中心/同一臺服務器/同一個IP的線路分在同一組)。

4.2.2.2文件傳輸的連接數目和方式

入網機構和銀聯處理中心之間的文件傳輸不是實時性的聯機業務,因此規定使用短連接的方式。

雙方建立一條全雙工的連接,連接建立后,雙方在同一條連接上收發請求和應答。當文件傳送完成后,

雙方關閉連接。

10

Q/CUP006.5—2012

CUPS入網機構

圖12文件傳輸的連接示意圖

4.2.3通信負載均衡

銀聯處理中心和每個入網機構建立多條連接不僅為了防止單點故障,還應在多條通信連接上實現

通信負載均衡。

例如,銀聯處理中心通過兩條或四條發送連接向入網機構發送報文時,可以采用簡單輪詢的方式,

即從第一條發送連接開始路由,第一個報文從第一條發送連接發送,第二個報文從第二條發送連接發

送,依次類推,到最后一個連接時再路由到第一條可用的發送連接。

CUPS入網機構

圖13簡單輪詢方式

除了簡單輪詢的方法,還可以通過監測各通信服務器和各條連接的負載情況動態調整各條連接的

路由選擇。

通過將銀聯處理中心和入網機構之間的通信負載合理的分配到各條連接和各臺通信服務器上,可

以防止出現某臺通信服務器上處理壓力過大的問題。

4.2.4Socket選項設置

在利用socket技術編寫通信程序時,為了保證通信雙方可以正常通信,需要設置相關的選項,其中

有的選項是協議相關的。在不同的系統中,socket選項有不同的默認值。這里只規定幾個主要的socket

選項設置,其他選項均使用系統默認值。

a)保持socket的“UNGER”選項為缺省狀態,即“關閉”狀態。這個選項影響到使用TCP協議

的socket關閉操作的行為。設置該選項為“關閉”狀態,使socket關閉操作保持默認行為,

即close。函數調用立即返回,如果socket發送緩沖區中還有數據,則系統會發送這些數據。

b)設置socket的“REUSEADDR”為“打開”狀態。設置這個選項可以保證socket監聽進程在異

常退出并重新啟動后,仍可以成功綁定到原監聽端口。該選項主要用在監聽socket連接請求

的服務器端。

c)設置socket的“KeepAlive”為“打開”狀態,設置這個選項可以保證在socket連接沒有流

量時,自動開始發送KeepAlive偵測包,偵測socket是否已經斷開。

II

Q/CUP006.5—2012

4.3協議定義

4.3.1參考資料

有關TCP/IP協議的背景信息和協議定義可以參考以下文檔:

a)RFC791InternetProtocolfortheIPprotocol;

b)RFC792InternetControlMessageProtocolfortheICMPprotocol;

c)RFC793TransmissionControlProtocolfortheTCPprotocol;

d)RFC1122RequirementsforInternetHosts-CommunicationLayers;

e)RFC1123RequirementsforInternetHosts—ApplicationandSupport;

g)RFC959FileTransferProtocol0

4.3.2協議定義范圍

本節論述的通信控制協議以TCP/IP協議為基礎,規定了銀聯處理中心和入網機構之間建立多條

socket連接的方式,雙方在多條連接上傳輸報文的方法以及通信異常的檢測和處理方法。

4.3.3基本規定

4.3.3.1數據編碼格式

銀聯處理中心和入網機構之間傳送的所有數據均是八位的二進制數據,沒有特殊含義字符和控制

字符。

4.3.3.2通信接口和業務流程的無關性

通信接口程序不對交易報文的類型作識別,不對報文內容作處理。因此,業務流程上的任何變動

對通信接口程序無影響,反之亦然。

4.3.4聯機交易控制協議

4.3.4.1建立連接

4.3.4.1.1連接建立過程

銀聯處理中心和入網機構在建立連接時,采用的是client-server方式。服務方監聽客戶的連接

請求,客戶方調用connect。發送連接請求,開始TCP的三步握手過程。雙方連接建立的過程如下:

b)客戶方調用connect。發起連接請求,使客戶方的TCP發送同步數據段(SYN段)。服務方TCP

收到后返回應答(ACK段),同時發送自己的同步數據段。客戶方connect。調用返回;

12

Q/CUP006.5—2012

c)客戶方TCP對服務方的同步數據段返回應答,連接建立,服務方accept。調用返回。

當連接成功建立或發生錯誤時,客戶方的connect。調用返回?可能發生的錯誤有以下幾種情況:

a)客戶方TCP在一定時間內沒有收到SYN段的應答,調用返回超時錯誤ETIMEDOUT。不同系統

規定的超時時間從75秒到幾分鐘不等。

b)如果服務方TCP給客戶方TCP重置應答RST,調用返回連接拒絕錯誤,說明在服務方沒有監

聽進程運行,或監聽進程已退出。

c)如果網絡中某路由器返回目的不可達的ICMP應答,則客戶機系統會重發連接請求直到超時,

此時調用返回主機不可達錯誤EHOSTUNREAQL

Connect調用使客戶端TCP從CLOSED狀態轉變到SYN_SENT狀態。如果連接成功建立,則轉變到

ESTABLISHED狀態。如果出錯,則socket不再可用,必須被關閉。

起始點

圖15socket連接建立狀態轉換圖

4.3.4.1.2連接建立時序

對于單工方式而言,在銀聯處理中心和入網機構初始建立連接時,要求先由入網機構發起連接請

求。銀聯處理中心在監聽端口監聽入網機構的連接請求,在接收到入網機構的連接請求并通過合法性

檢查后,根據入網機構的IP地址和監聽端口號向入網機構發起連接請求,完成一進一出兩條單工長連

接的建立。在該連接對的建立過程中,銀聯處理中心將設置一進一出兩條單工長連接建立的最長時間

間隔參數值。如果中心建立好接收連接后,在最長1分鐘內仍無法建立與機構的發送連接,則中心主動

斷開與該發送連接相對應的接收連接,回復到偵聽狀態,等待接收入網機構重新建立連接的請求。建

立其他連接的過程與此相同。如果建立連接的過程超時或發生錯誤,則關閉本地socket后,重新建立

連接。如果一條連接中斷需要重新建立,則應按照4.2.2.1.1節描述分情況處理。

下圖說明連接建立的時序:

13

Q/CUP006.5—2012

入網機構

CUPS

圖16銀聯處理中心和入網機構單工連接時序圖

對于雙工方式而言,在銀聯處理中心和入網機構初始建立連接時,要求先由入網機構發起連接請

求。銀聯處理中心在監聽端口監聽入網機構的連接請求,在接收到入網機構的連接請求并通過合法性

檢查后,連接即告成功,完成了一條雙工長連接的建立。

下圖說明連接建立的時序:

14

Q/CUP006.5—2012

AMSIK

avs

圖17銀聯處理中心和入網機構雙工連接時序圖

4.3.4.2報文格式

銀聯處理中心和入網機構之間的交易報文封裝在IP數據包內,通過TCP/IP協議傳送。每一個報文

由四字節報文長度和報文數據構成,如圖18所示。由于TCP數據是一個“流”的概念,報文邊界不易

確定,因此在每個報文前提供四個字節的報文長度值,用來確定每個報文的長度。本規范規定報文最

大長度不超過2048字節。

報文數據格式可參見報文接口規范的說明。報文長度是四個字節的ASCH碼串,指明后面的報文數

據的長度,但該長度不包括報文長度域本身的四個字節值。通過報文長度域,報文的接收方可以很容

易確定每個交易報文的長度。

報文長度報文數據

描述長度(字節)

報文長度4

報文數據不定長

圖18數據報文格式說明

4.3.4.3數據傳輸控制

4.3.4.3.1傳輸方式

15

Q/CUP006.5—2012

銀聯處理中心和入網機構之間的socket連接初始化過程完成后,雙方可開始報文交換。雙方采用

異步傳輸方式傳輸交易報文,即一方發送一筆交易請求后,不必等待對方的應答,可以接著發送下一

筆交易請求。

因為銀聯處理中心和入網機構存在多條socket連接,應答報文從哪條連接返回不確定。對此,應

用層上的業務處理流程必須加以判斷處理。

發送方發送一個交易請求后,由于通信鏈路中斷或其他通信異常情況的發生,發送方將不能確保

接收方一定能夠收到報文數據。在通信異常情況下,發送方多表現為發送數據超時,因此在應用層的

業務流程上要有相應的超時控制。

4.3.4.3.2報文發送和接收

報文發送一方發送報文數據,調用write。返回后,準備下一筆報文數據的發送。報文接收一方調

用read。接收報文,當有報文數據到達后讀調用返回。

圖19報文發送和接收示意圖

接收方在讀取數據時,應按照長度加報文再長度加報文的方式,先讀取四個字節的長度,用于確

定報文的實際長度,再按實際報文長度值讀取其后的報文數據。如果接收方一次讀取沒有接收到完整

的報文,必須再次讀取直到接收到規定長度的報文數據。發送方發送報文時,先在報文前加上四個字

節的報文長度值再與報文一起發送。

報文報文報文報文

長度數據長度數據

圖20報文流小意圖

接收方在讀取數據的過程中,網絡有可能發生中斷或發送方寫數據進程意外退出甚至宕機,此時

接收方要根據異常情況做相應處理。通信異常處理參見4.3.4.7節。

16

Q/CUP006.5—2012

4.3.4.4關閉連接的處理

這里規定的是銀聯處理中心或入網機構需要正常關閉一個連接時要做的處理。正常關閉一個

socket連接需要經過四個步驟:

圖21關閉socket連接過程

a)當客戶方調用close()主動關閉socket,該方TCP發送FIN段給服務方,表示結束發送數據;

b)服務方TCP接收到FIN段后,進入被動關閉socket過程。服務方TCP收到FIN段后,會通知

服務方的應用進程,read。調用會返回0;

c)服務方讀調用返回0后,調用close()關閉socket,服務方TCP會向客戶方TCP發送FIN段;

d)客戶方TCP收到FIN段后,返回應答。

從以上過程可以知道,當連接的一方關閉socket后,另一方的socket會得到通知。對于銀聯處理

中心和入網機構的接收連接,通過read。調用返回值可以獲得該通知。對于發送連接,通過select。

調用查詢本地socket是否接收到通知數據。若有通知數據到達,調用read。,若返回。表示對方socket

已關閉。

當銀聯處理中心或入網機構需要關閉一條發送連接時,先停止在該條連接上發送數據,然后調用

close。關閉本地socket.接收方調用read。讀取數據,當調用返回0時,表明發送方socket已關閉,

并調用close。關閉本地socket。此時,雙方完成連接的關閉。

4.3.4.5空閑連接處理

對于單工通信方式,如果銀聯處理中心或入網機構一條發送連接上超過2分鐘沒有發送報文數據,

則向接收方發送“空閑連接查詢”控制報文。該報文不帶任何附加數據,并置報文長度域的值為零。

銀聯處理中心或入網機構通信層收到這樣的報文后,直接丟棄該報文。

17

Q/CUP006.5—2012

報文長度(4字節):

“0000”

圖22空閑連接查詢報文格式

如果接收方socket收到該控制報文,說明雙方連接正常,如果在3分鐘之內沒有收到對方的“空閑

連接查詢”控制報文,則說明接收長連接已經中斷,需要關閉該連接socket,并且斷開發送長連接。

如果連接中斷或接收方宕機、通信進程異外退出,發送方TCP會向本地socket返回相應的錯誤通知,發

送方根據read。調用返回的錯誤信息做相應的異常處理,參見4.3.4.7節。如果接收方在接收連接上

有3分鐘未收到任何數據,此時,若入網機構作為接收方,則關閉該連接對,并重新向銀聯處理中心發

起建立連接的請求;若銀聯處理中心作為接收方,則關閉該連接對,并恢復到偵聽狀態,等待入網機

構重新發起建立連接的請求。

發送方接收方

圖23空閑連接處理示意圖

對于雙工的通信方式,如果發送方或者接收方中有一方檢測到一條連接空閑超過2分鐘,則通過該

連接向對端發送一次空閑測試報文;對端收到該報文后直接丟棄。如果在3分鐘之內沒收到對端的空閑

連接測試報文或者交易報文,此時,若入網機構作為接收方,則關閉該條連接,并重新向銀聯處理中

心發起建立連接的請求;若銀聯處理中心作為接收方,則關閉該連接,并恢復到偵聽狀態,等待入網

機構重新發起建立連接的請求。

4.3.4.6流量控制

銀聯處理中心連接各入網機構,各入網機構的報文都要經銀聯處理中心轉接。為了防止銀聯處理

中心在交易高峰時段,因處理數據量過大導致系統性能下降甚至崩潰,需要在銀聯處理中心和入網機

構之間做通信流量控制。

TCP協議的窗口機制能夠協調通信雙方的數據收發速度,具有一定的流量控制作用。當接收方監測

到應用層消息隊列已滿或將滿時,通過“緩讀”的方法適當延長從接收連接上讀取數據的間隔,沒有

被讀取的數據緩存在socket連接的緩沖區內。隨著緩沖區的數據增加,TCP協議的窗口機制會使發送方

TCP減小數據發送量,未發送的數據緩存在發送方緩沖區內。當發送緩沖區滿時,發送方的發送進程會

被系統核心阻塞。接收方的系統處理能力恢復正常后,恢復從接收連接上讀取數據的間隔,接收緩沖

區數據的減少通過TCP窗口機制使發送方TCP增大數據發送量,從而使發送緩沖區數據減少,被阻塞的

發送進程恢復運行。

銀聯處理中心除了通信層的流量控制機制外,在應用層上也做了流量的控制。當銀聯處理中心應

用系統過忙時,銀聯處理中心通信網關在原始報文前加上新增報文頭后返回給入網機構,新增報文頭

中的拒絕原因碼為系統忙。

除銀聯處理中心進行流量控制以外,建議入網機構也需要有與之對應的流量控制策略。這樣在銀

聯系統異常恢復以后,對于積壓的大量請求、應答或沖正交易應能夠及時處理。基于此,建議入網機

構在自身系統設計的TPS(每秒交易量)峰值情況下,能夠處理的交易持續時間不低于30分鐘。

18

Q/CUP006.5—2012

4.3.4.7通信異常處理

銀聯處理中心和入網機構的通信連接跨越了廣域網,廣域網線路距離長、通信環境復雜,會產生

各種通信異常的情況。為此,通信程序必須能夠及時檢測到通信異常的發生并做相應的處理,保證銀

聯處理中心和入網機構聯機交易的正常進行。

4.3.4.7.1通信異常分析

a)接收方通信進程終止。

發送方接收方

圖24接收方進程退出導致的通信異常

通信進程終止的原因包括正常退出、因執行出錯導致的異常退出、進程被系統管理員強行終止等。

此時,接收方的socket可能被通信進程正常關閉,也可能未被正常關閉。在這種情況下,接收方TCP

會向發送方TCP發送FIN段,發送方TCP向本地socket發送通知。在發送方通過select()調用可以捕獲該

通知,調用read。會返回結果0。如果發送方繼續向接收方發送數據,因為接收方socket已經關閉,接

收方TCP會向發送方TCP發送RST段。

發送方收到RST段后,若調用read。,則返回連接重置錯誤信息。若調用write。,則返回寫錯誤信

息。需要說明的是,在Unix平臺上,當調用write。出錯后,系統會向通信進程發送SIGPIPE信號,而

該信號默認行為將終止通信進程,故需要設置忽略該信號。

b)網絡中斷或接收方宕機。

圖25接收方宕機造成的通信異常

19

Q/CUP006.5—2012

發送方接收方

圖26網絡中斷造成的通信異常

如果接收方宕機或網絡發生中斷,發送方socket不會收到任何通知報文。發送方發送數據后,發

送方TCP的重傳機制會試圖重復嘗試發送數據。如果約9分鐘后發送方TCP一直收不到應答,則返回錯誤

信息,此后的讀寫調用都會出錯返回。read。調用會返回超時錯誤或主機不可達錯誤。

c)接收方宕機后重啟。

圖27接收方宕機重啟導致的通信異常

如果接收方宕機后重啟,則接收方TCP不保留原來的連接信息。接收方宕機后,如果發送方沒有發

送數據,則發送方不會知道接收方已宕機。在接收方重起后,發送方向接收方發送數據,則接收方TCP

會向發送方TCP發送RST段,發送方隨后的讀寫調用都會出錯,read。調用會返回連接重置錯誤信息。

d)如果發送方通信進程終止,則接收方read。調用會返回0。

e)如果發送方宕機或網絡中斷,接收方收不到任何通知。

4.3.4.7.2通信異常處理

通信異常處理,此處假設發送方為入網機構,接收方為銀聯處理中心。

4.3.4.7.2.1連接中斷的處理

發送方發送交易報文或空閑測試報文出錯,說明連接發生中斷,則關閉該連接,并主動向接收方

重新發起連接請求。接收方收到對方的重新連接請求,接收該請求并關閉原來的連接。

4.3.4.7.2.2接收方接收進程異常終止的處理

接收方接收進程意外退出會使發送方發送進程返回錯誤。發送方應關閉本地socket,重新向接收

方發起連接請求。

4.3.4.7.2.3發送方發送進程異常終止的處理

發送方發送進程異常終止,接收方read。調用會返回0。接收方應關閉本地socket,等待接收發送

方重新建立連接的請求。

4.3.4.7.2.4接收方宕機的處理

如果接收方宕機且不能及時重起時,發送方在未超時前不會獲得任何異常通知,這種情況與連接

中斷情況類似,按連接中斷的異常情況處理。如果接收方通信主機在發送方超時前重起,發送方TCP

20

Q/CUP006.5—2012

會收到接收方TCP返回的RST段,發送方的寫調用將返回出錯信息。此時,發送方關閉本地socket,并

向接收方請求重新建立連接。

4.3.4.7.2.5發送方宕機的處理

接收方不能獲知發送方已宕機。如果發送方在5分鐘之內重新發起連接請求,接收方收到連接請求

后重新建立連接,在合法性檢查通過之后,關閉原來的連接并建立新的連接。

4.3.5文件傳輸控制協議

這里只涉及利用流傳輸文件的控制,FTP建議參考標準FTP協議。

4.3.5.1報文格式

利用流傳輸傳送文件的報文格式與聯機交易使用的報文格式類似,由四字節報文長度和報文數據

構成。報文數據格式可參見《文件接口規范》的說明。

4.3.5.2建立連接

銀聯處理中心和入網機構之間的文件傳輸采用全雙工的socket連接,可以同時存在多條連接。文

件收發雙方應支持多條連接并發,具體條數由收發雙方根據實際需要協商確定。銀聯處理中心支持對

每個文件接收機構線路數的參數化配置,最少2條,最

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論