【正文】 pcvers。unsigned int prog。unsigned int vers。unsigned int proc。opaque_auth cred。opaque_auth verf。1 parameter2 parameter 。 。 。 }；RPC 答復(fù)信息：RPC 協(xié)議的答復(fù)信息的改變?nèi)Q于網(wǎng)絡(luò)服務(wù)器對(duì)調(diào)用信息是接收還是拒絕。答復(fù)信息請(qǐng)求包括區(qū)別以下情形的各種信息：RPC 成功執(zhí)行調(diào)用信息。RPC 的遠(yuǎn)程實(shí)現(xiàn)不是協(xié)議第二版，返回 RPC 支持的最低和最高版本號(hào)。在遠(yuǎn)程系統(tǒng)中，遠(yuǎn)程程序不可用。遠(yuǎn)程程序不支持被請(qǐng)求的版本號(hào)。返回遠(yuǎn)程程序所支持的最低和最高版本號(hào)。請(qǐng)求的過(guò)程號(hào)不存在。通常是呼叫方協(xié)議或程序差錯(cuò)。RPC答復(fù)信息形式如下：enum reply_stat stat{MSG_ACCEPTED = 0,MSG_DENIED = 1 }；5．1．3 Hadoop RPC機(jī)制及原理Hadoop RPC Server實(shí)現(xiàn)了一種抽象的RPC服務(wù)，同時(shí)提供Call隊(duì)列。RPC Server結(jié)構(gòu)：RPC Server的監(jiān)聽(tīng)者，用來(lái)接收RPC Client的連接請(qǐng)求和數(shù)據(jù)，其中將數(shù)據(jù)封裝成CALL后PUSH到CALL隊(duì)列中。：RPC Server的CALL處理者，和Server。Listener通過(guò)CALL隊(duì)列交互。：RPC Server響應(yīng)者，Server。Handler按照異步非阻塞的方式向RPC Client發(fā)送響應(yīng)，如果有未發(fā)送出去的數(shù)據(jù)，交由Server。Responder來(lái)處理完成。：RPC Server數(shù)據(jù)的接收者。提供接收數(shù)據(jù)，解析數(shù)據(jù)包的功能。：持有客戶端的Call信息。RPC Server的主要流程RPC Server作為服務(wù)的提供者主要有兩部分組成：接收Call調(diào)用和處理Call調(diào)用。接收Call調(diào)用負(fù)責(zé)接收來(lái)自RPC Client的調(diào)用請(qǐng)求，編碼成Call對(duì)象放入到Call隊(duì)列中，這一過(guò)程有Server。Listener完成。具體步驟如下：Listener線程監(jiān)聽(tīng)RPC Client發(fā)過(guò)來(lái)的數(shù)據(jù)當(dāng)有數(shù)據(jù)可以接收時(shí)，調(diào)用Connection的readAndProcess方法Connection對(duì)邊接受過(guò)來(lái)的數(shù)據(jù)邊處理，當(dāng)接到一個(gè)完整的Call包，則構(gòu)建一個(gè)Call對(duì)象，PUSH到Call隊(duì)列中，有Handler來(lái)處理Call隊(duì)列中的所有Call處理完的Call調(diào)用負(fù)責(zé)處理Call隊(duì)列中的每一個(gè)調(diào)用請(qǐng)求，有Handler線程來(lái)完成：Handler線程監(jiān)聽(tīng)Call隊(duì)列，如果Call隊(duì)列非空，按FIFO規(guī)則從Call隊(duì)列中取出Call借助JDK提供的Method，完成對(duì)目標(biāo)方法的調(diào)用，目標(biāo)方法由具體的業(yè)務(wù)邏輯實(shí)現(xiàn)返回響應(yīng)。 Client發(fā)送響應(yīng)，如果有未發(fā)送出的數(shù)據(jù)。完整的交互過(guò)程如下: 這里還需要提到的是，在namenode的高負(fù)荷運(yùn)行的環(huán)境下，單線程的Listener線程在讀取rpc call中帶來(lái)的參數(shù)時(shí)，如果該rpc call的調(diào)用所帶的參數(shù)非常的大（如BlockReport），那么Listener在讀取這種rpc call的調(diào)用參數(shù)時(shí)就會(huì)花費(fèi)很多的時(shí)間，那么此時(shí)單線程的Listener就成了namenode服務(wù)的瓶頸。所以后來(lái)對(duì)這種機(jī)制進(jìn)行了優(yōu)化，將對(duì)rpc call的參數(shù)讀取的方式也換成異步的方式，在Listener中增加了一個(gè)reader pool，將需要讀取參數(shù)的rpc call的read請(qǐng)求放入pool中，然后利用多個(gè)reader并行的讀取，這樣就能將listener線程給解放出來(lái)。reader讀取參數(shù)后，構(gòu)造出Call變量，放入Call隊(duì)列中。因此，后續(xù)的hadoop版本中都會(huì)增加一個(gè)配置參數(shù)：，以達(dá)到優(yōu)化rpc接收rpc call參數(shù)的效率[9]。5．2 Kerberos 5．2．1 Kerberos介紹Kerberos這一名詞來(lái)源于希臘神話“三個(gè)頭的狗——地獄之門(mén)守護(hù)者”Kerberos 是一種網(wǎng)絡(luò)認(rèn)證協(xié)議，其設(shè)計(jì)目標(biāo)是通過(guò)密鑰系統(tǒng)為客戶機(jī) / 服務(wù)器應(yīng)用程序提供強(qiáng)大的認(rèn)證服務(wù)。該認(rèn)證過(guò)程的實(shí)現(xiàn)不依賴于主機(jī)操作系統(tǒng)的認(rèn)證，無(wú)需基于主機(jī)地址的信任，不要求網(wǎng)絡(luò)上所有主機(jī)的物理安全，并假定網(wǎng)絡(luò)上傳送的數(shù)據(jù)包可以被任意地讀取、修改和插入數(shù)據(jù)。在以上情況下， Kerberos 作為一種可信任的第三方認(rèn)證服務(wù)，是通過(guò)傳統(tǒng)的密碼技術(shù)（如：共享密鑰）執(zhí)行認(rèn)證服務(wù)的。認(rèn)證過(guò)程具體如下：客戶機(jī)向認(rèn)證服務(wù)器（AS）發(fā)送請(qǐng)求，要求得到某服務(wù)器的證書(shū)，然后 AS 的響應(yīng)包含這些用客戶端密鑰加密的證書(shū)。證書(shū)的構(gòu)成為： 1) 服務(wù)器 “ticket” ； 2) 一個(gè)臨時(shí)加密密鑰（又稱為會(huì)話密鑰 “session key”） ?？蛻魴C(jī)將 ticket （包括用服務(wù)器密鑰加密的客戶機(jī)身份和一份會(huì)話密鑰的拷貝）傳送到服務(wù)器上。會(huì)話密鑰可以（現(xiàn)已經(jīng)由客戶機(jī)和服務(wù)器共享）用來(lái)認(rèn)證客戶機(jī)或認(rèn)證服務(wù)器，也可用來(lái)為通信雙方以后的通訊提供加密服務(wù)，或通過(guò)交換獨(dú)立子會(huì)話密鑰為通信雙方提供進(jìn)一步的通信加密服務(wù)。上述認(rèn)證交換過(guò)程需要只讀方式訪問(wèn) Kerberos 數(shù)據(jù)庫(kù)。但有時(shí)，數(shù)據(jù)庫(kù)中的記錄必須進(jìn)行修改，如添加新的規(guī)則或改變規(guī)則密鑰時(shí)。修改過(guò)程通過(guò)客戶機(jī)和第三方 Kerberos 服務(wù)器（Kerberos 管理器 KADM）間的協(xié)議完成。有關(guān)管理協(xié)議在此不作介紹。另外也有一種協(xié)議用于維護(hù)多份 Kerberos 數(shù)據(jù)庫(kù)的拷貝，這可以認(rèn)為是執(zhí)行過(guò)程中的細(xì)節(jié)問(wèn)題，并且會(huì)不斷改變以適應(yīng)各種不同數(shù)據(jù)庫(kù)技術(shù)。Kerberos又指麻省理工學(xué)院為這個(gè)協(xié)議開(kāi)發(fā)的一套計(jì)算機(jī)網(wǎng)絡(luò)安全系統(tǒng)。系統(tǒng)設(shè)計(jì)上采用客戶端/服務(wù)器結(jié)構(gòu)與DES加密技術(shù)，并且能夠進(jìn)行相互認(rèn)證，即客戶端和服務(wù)器端均可對(duì)對(duì)方進(jìn)行身份認(rèn)證。可以用于防止竊聽(tīng)、防止replay攻擊、保護(hù)數(shù)據(jù)完整性等場(chǎng)合，是一種應(yīng)用對(duì)稱密鑰體制進(jìn)行密鑰管理的系統(tǒng)。Kerberos的擴(kuò)展產(chǎn)品也使用公開(kāi)密鑰加密方法進(jìn)行認(rèn)證。5．2．2 Kerberos協(xié)議結(jié)構(gòu) Kerberos的組成Kerberos應(yīng)用程序庫(kù)：應(yīng)用程序接口，包括創(chuàng)建和讀取認(rèn)證請(qǐng)求，以及創(chuàng)建safe message 和private message的子程序。加密/解密庫(kù)：DES等。Kerberos數(shù)據(jù)庫(kù)：記載了每個(gè)Kerberos 用戶的名字，私有密鑰，截止信息(記錄的有效時(shí)間，通常為幾年)等信息。數(shù)據(jù)庫(kù)管理程序：管理Kerberos數(shù)據(jù)庫(kù)KDBM服務(wù)器(數(shù)據(jù)庫(kù)管理服務(wù)器)：接受客戶端的請(qǐng)求對(duì)數(shù)據(jù)庫(kù)進(jìn)行操作。認(rèn)證服務(wù)器(AS)：存放一個(gè)Kerberos數(shù)據(jù)庫(kù)的只讀的副本，用來(lái)完成principle的認(rèn)證，并生成會(huì)話密鑰．?dāng)?shù)據(jù)庫(kù)復(fù)制軟件：管理數(shù)據(jù)庫(kù)從KDBM服務(wù)所在的機(jī)器，到認(rèn)證服務(wù)器所在的機(jī)器的復(fù)制工作，為了保持?jǐn)?shù)據(jù)庫(kù)的一致性，每隔一段時(shí)間就需要進(jìn)行復(fù)制工作．用戶程序：登錄Kerberos，改變Kerberos密碼，顯示和破壞Kerberos標(biāo)簽（ticket）等工作。Microsoft Windows Server 2003操作系統(tǒng)上實(shí)現(xiàn)了Kerberos5身份驗(yàn)證協(xié)議。Windows　Server2003總是使用擴(kuò)展公鑰身份驗(yàn)證機(jī)制。KerBeros身份驗(yàn)證客戶端作為SSP（Security Support Provider）通過(guò)訪問(wèn)SSPI（Security Support Provider Interface）來(lái)實(shí)現(xiàn)身份驗(yàn)證。用戶身份驗(yàn)證初始化過(guò)程被集成在Winlogon這SSO（Single SignOn）體系中。利用對(duì)稱式加密法實(shí)作認(rèn)證對(duì)稱式加密法的定義為加密與解密時(shí)，必須使用相同的秘鑰（secret key），以及相同或類似的算法，也就是利用秘鑰將明文文字變成加密文字。 秘鑰通常是一串固定長(zhǎng)度(例如，128個(gè)位)的數(shù)據(jù)所組成。在實(shí)際應(yīng)用上，一般是以哈希函數(shù)(Hash function)，將用戶的密碼加以運(yùn)算求得哈希值(Hash code)，再以哈希值作為為秘鑰。由于哈希函數(shù)為單向運(yùn)算的函數(shù)，也就是說(shuō)，其他人無(wú)法利用秘鑰來(lái)反推原始的密碼。 對(duì)稱式加密法除了可用來(lái)對(duì)數(shù)據(jù)加密外，也可應(yīng)用在認(rèn)證的功能，其原理相當(dāng)簡(jiǎn)單，假設(shè)用戶 A 與 B 各自擁有一把相同的秘鑰 K，而且這兩人相信世界上不會(huì)有其他人擁有這一把 K。在實(shí)際進(jìn)行認(rèn)證時(shí)，可以有以下兩種方式： 當(dāng)用戶 A 利用 K 將某一段明文文字(PT)加密為加密文字(CT)，若對(duì)方可將 CT 解密為 PT，則 A 即可確認(rèn)具有此解密能力者為 B。 當(dāng)使用者 A 收到來(lái)自對(duì)方的一段加密文字 CT 時(shí)，若 A 能成功地利用 K 將 CT 解密為 PT，則 A 可確認(rèn)對(duì)方為 B。 有關(guān)對(duì)稱式加密法的認(rèn)證方式，許多人最常問(wèn)的問(wèn)題就是 A 與 B 如何共享秘鑰？要回答這個(gè)問(wèn)題必須先澄清一個(gè)基本觀念，也就是秘鑰共享在對(duì)稱式加密法的認(rèn)證方式中是一項(xiàng)預(yù)設(shè)的前提。秘鑰必須在事前透過(guò)其他的安全管道來(lái) 交換。唯有 A 與 B 共享秘鑰的條件下，接下來(lái)才能進(jìn)行對(duì)稱式加密法的認(rèn)證。 例如，在一般的企業(yè)網(wǎng)絡(luò)中，無(wú)論使用何種網(wǎng)絡(luò)系統(tǒng)，網(wǎng)管人員勢(shì)必需要以網(wǎng)絡(luò)以外的安全管道(直接面告或傳小紙條等等)，來(lái)告知新用戶的賬號(hào)/密碼。之后，用戶才能使用此賬號(hào)/密碼來(lái)登入網(wǎng)絡(luò)進(jìn)行認(rèn)證。 雖然 Kerberos 的整個(gè)架構(gòu)相當(dāng)復(fù)雜，但其基本精神即是利用對(duì)稱式加密法來(lái)認(rèn)證，所以請(qǐng)務(wù)必牢記對(duì)稱式加密法的認(rèn)證原理。若讀者對(duì)后文中 Kerberos 協(xié)議的架構(gòu)有任何疑惑，只要重新回歸到上述的基本原理，問(wèn)題大概都可以迎刃而解。 一對(duì)一認(rèn)證為了方便介紹，在此將假想一種簡(jiǎn)化的一對(duì)一認(rèn)證架構(gòu)，并說(shuō)明在此架構(gòu)下，利用對(duì)稱式加密法來(lái)認(rèn)證時(shí)，所需進(jìn)行的步驟。 假設(shè)現(xiàn)在網(wǎng)絡(luò)上有兩臺(tái)計(jì)算機(jī)客戶端與服務(wù)器?？蛻舳伺c服務(wù)器各自擁有一把相同的密鑰 Kclt，且世界上不會(huì)有其他人擁有這一把 Kclt，雙方事先已經(jīng)協(xié)調(diào)好要使用什么樣的算法。最后，客戶端與服務(wù)器的時(shí)間誤差必須同步化。 在上述條件下，若客戶端與服務(wù)器要相互認(rèn)證，其步驟如下： 1. 客戶端送出 Msg1 消息給服務(wù)器： Msg1：我是客戶端, {客戶端相關(guān)信息, 時(shí)間戳}Kclt 我是客戶端表示雙引號(hào)中的信息會(huì)以明文的方式來(lái)傳送。 {客戶端相關(guān)信息, 時(shí)間戳}Kclt 則是表示將大括號(hào)中的信息以 Kclt 加密后再傳送。本文將延用此一表示法來(lái)描述 Kerberos 協(xié)議中消息的內(nèi)容。 {客戶端相關(guān)信息, 時(shí)間戳}Kclt就是 Kerberos 中所謂的 Authenticator，可用來(lái)作為認(rèn)證的一段加密文字。Authenticator 是由認(rèn)證雙方所共享的秘鑰加密而成，內(nèi)容通常會(huì)包含多項(xiàng)信息，其中最重要的信息之一便是時(shí)間戳，也就是建立 Authenticator 的時(shí)間。時(shí)間戳的目的主要是為了防范重送攻擊。 2. 服務(wù)器收到 Msg1 消息 服務(wù)器收到 Msg1 消息之后，便可從消息中明文的部份可知道對(duì)方計(jì)算機(jī)自稱為客戶端。服務(wù)器從本身的安全數(shù)據(jù)庫(kù)中找出與客戶端共享的秘鑰 Kclt，再利用 Kclt 將 {客戶端相關(guān)信息, 時(shí)間戳} Kclt 解密。解密后，服務(wù)器可比對(duì) {客戶端相關(guān)信息, 時(shí)間戳} Kclt 中的客戶端與 我是客戶端 的內(nèi)容，若核對(duì)無(wú)誤，則服務(wù)器可確認(rèn)這個(gè)自稱為客戶端的家伙果真是客戶端，因?yàn)槭澜缟铣朔?wù)器外，只有客戶端才有使用 Kclt 來(lái)加密產(chǎn)生 Msg1 的能力。服務(wù)器可進(jìn)一步比對(duì) Msg1 消息中的時(shí)間戳與服務(wù)器目前的時(shí)間，若兩者在合理的誤差范圍內(nèi)，一般是 5 分鐘，則可排除重送攻擊的可能性。 3. 服務(wù)器送出 Msg2 消息 服務(wù)器將解密 Msg1 消息所得的時(shí)間戳以 Kclt 加密后，只取時(shí)間戳的意義在于，服務(wù)器才能藉此向客戶端證明自己有解密 Msg1 的能力，建立 Msg2 消息并傳送給客戶端： Msg2：{時(shí)間戳} Kclt 4. 客戶端收到 Msg2 消息 客戶端收到 Msg2 消息后，利用 Kclt 解密 Msg2，取得 Msg2 中的時(shí)間戳，并用來(lái)比對(duì)在步驟 1 中建立 Msg1 時(shí)的時(shí)間。若兩者相符，則客戶端即可確認(rèn)服務(wù)器的身份，因?yàn)槌丝蛻舳送猓挥蟹?wù)器才有使用 Kclt 來(lái)解密 Msg1 并建立 Msg2 的能力。 完成上述四個(gè)步驟之后，客戶端與服務(wù)器之間即完成相互認(rèn)證的動(dòng)作。這種一對(duì)一的認(rèn)證方式有一個(gè)先天的缺陷，也就是當(dāng)網(wǎng)絡(luò)中計(jì)算機(jī)的數(shù)目增加時(shí)，秘鑰的數(shù)目也 會(huì)隨之暴增，而產(chǎn)生管理上的困難。這就有如點(diǎn)對(duì)點(diǎn)的網(wǎng)絡(luò)架構(gòu)僅能用在小型的局域網(wǎng)絡(luò)上。若要能應(yīng)用在一般局域網(wǎng)絡(luò)上，勢(shì)必要使用集中式的管理架構(gòu)。 密鑰中心的認(rèn)證方式密鑰中心 (KDC，Key Distributed Center) 為集中式密鑰管理的核心機(jī)構(gòu)。密鑰中心儲(chǔ)存了網(wǎng)絡(luò)中每個(gè)主體，包括各種形式的客戶端與服務(wù)器的秘鑰，并負(fù)責(zé)這些秘鑰的管理與發(fā)送的工作。也就是說(shuō)，當(dāng)用戶 端與服務(wù)器之間需要相互認(rèn)證時(shí)，必須透過(guò)密鑰中心來(lái)完成認(rèn)證。 在實(shí)際的應(yīng)用上，密鑰中心必須負(fù)責(zé)建立 Session Key 與 Ticket。 Session Key：從先前對(duì)稱式加密法的認(rèn)證方式中，當(dāng)客戶端與服務(wù)器需要相互認(rèn)證時(shí)，雙方必須要擁有相同的秘鑰。在密鑰中心認(rèn)證方式的前提中，客戶端與密鑰中心共享客戶端 的秘鑰，服務(wù)器與密鑰中心共享服務(wù)器的秘鑰，但客戶端與服務(wù)器卻沒(méi)有共享的秘鑰。解決的方法即是利用 Session Key。 當(dāng)客戶端向密鑰中心要求與服務(wù)器認(rèn)證時(shí)，密鑰中心會(huì)建立兩把相同的 Session Key，并透過(guò) Ticket 的機(jī)制，安全地將 Session Key 分別傳送給客戶端與服務(wù)器，以便兩者進(jìn)行相互認(rèn)證的工作。 Ticket：Ticket 顧名思義與我們?nèi)粘Ｉ钏褂玫墓嚻?、電影票等類似，使用者必須透過(guò)某種管道，如購(gòu)買或申請(qǐng)來(lái)取得 Ticket，之后即可利用此 Ticket 來(lái)享受某種服務(wù)。 同理，密鑰中心建立服務(wù)器的 Ti