第一篇：傳輸層中的安全協(xié)議（范文模版）

傳輸層安全協(xié)議

隨著計算機網(wǎng)絡的普及與發(fā)展，網(wǎng)絡為我們創(chuàng)造了一個可以實現(xiàn)信息共享的新環(huán)境。但是由于網(wǎng)絡的開放性，如何在網(wǎng)絡環(huán)境中保障信息的安全始終是人們關注的焦點。在網(wǎng)絡出現(xiàn)的初期，網(wǎng)絡主要分布在一些大型的研究機構、大學和公司。由于網(wǎng)絡使用環(huán)境的相對獨立和封閉性，網(wǎng)絡內(nèi)部處于相對安全的環(huán)境，在網(wǎng)絡內(nèi)部傳輸信息基本不需要太多的安全措施。隨著網(wǎng)絡技術的飛速發(fā)展，尤其是Internet的出現(xiàn)和以此平臺的電子商務的廣泛應用，如何保證信息在Internet的安全傳輸，特別是敏感信息的保密性、完整性已成為一個重要問題，也是當今網(wǎng)絡安全技術研究的一個熱點。在許多實際應用中，網(wǎng)絡由分布在不同站點的內(nèi)部網(wǎng)絡和站點之間的公共網(wǎng)絡組成。每個站點配有一臺網(wǎng)關設備，站點內(nèi)網(wǎng)絡的相對封閉性和單一性，站點內(nèi)網(wǎng)絡對傳輸信息的安全保護要求不大。二站點之間網(wǎng)絡屬于公共網(wǎng)絡，網(wǎng)絡相對開發(fā)，使用情況復雜，因此需要對站點間的公共網(wǎng)絡傳輸?shù)男畔⑦M行安全保護。

在網(wǎng)際層中，IPSec可以提供端到端的網(wǎng)絡層安全傳輸，但是它無法處理位于同一端系統(tǒng)之中的不同的用戶安全需求，因此需要在傳輸層和更高層提供網(wǎng)絡安全傳輸服務，來滿足這些要求。基于兩個傳輸進程間的端到端安全服務，保證兩個應用之間的保密性和安全性，為應用層提供安全服務。Web瀏覽器是將HTTP和SSL相結合，因為簡單在電子商務也應用。

在傳輸層中使用的安全協(xié)議主要有以下幾個：

1.SSL(安全套接字層協(xié)議)

SSL(Secure Socket Layer)是由Netscape設計的一種開放協(xié)議;它指定了一種在應用程序協(xié)議(例如http、telnet、NNTP、FTP)和TCP/IP之間提供數(shù)據(jù)安全性分層的機制。它為TCP/IP連接提供數(shù)據(jù)加密、服務器認證、消息完整性以及可選的客戶機認證。SSL的主要目的是在兩個通信應用程序之間提供私密信和可靠性。這個過程通過3個元素來完成：

l 握手協(xié)議。這個協(xié)議負責協(xié)商被用于客戶機和服務器之間會話的加密參數(shù)。當一個SSL客戶機和服務器第一次開始通信時，它們在一個協(xié)議版本上達成一致，選擇加密算法，選擇相互認證，并使用公鑰技術來生成共享密鑰。

l 記錄協(xié)議。這個協(xié)議用于交換應用層數(shù)據(jù)。應用程序消息被分割成可管理的數(shù)據(jù)塊，還可以壓縮，并應用一個MAC(消息認證代碼);然后結果被加密并傳輸。接受方接受數(shù)據(jù)并對它解密，校驗MAC，解壓縮并重新組合它，并把結果提交給應用程序協(xié)議。l 警告協(xié)議。這個協(xié)議用于指示在什么時候發(fā)生了錯誤或兩個主機之間的會話在什么時候終止。

下面我們來看一個使用WEB客戶機和服務器的范例。WEB客戶機通過連接到一個支持SSL的服務器，啟動一次SSL會話。支持SSL的典型WEB服務器在一個與標準HTTP請求(默認為端口80)不同的端口(默認為443)上接受SSL連接請求。當客戶機連接到這個端口上時，它將啟動一次建立SSL會話的握手。當握手完成之后，通信內(nèi)容被加密，并且執(zhí)行消息完整性檢查，知道SSL會話過期。SSL創(chuàng)建一個會話，在此期間，握手必須只發(fā)生過一次。

SSL握手過程步驟：

步驟1：SSL客戶機連接到SSL服務器，并要求服務器驗證它自身的身份。步驟2：服務器通過發(fā)送它的數(shù)字證書證明其身份。這個交換還可以包括整個證書鏈，直到某個根證書權威機構(CA)。通過檢查有效日期并確認證書包含有可信任CA的數(shù)字簽名，來驗證證書。

步驟3：然后，服務器發(fā)出一個請求，對客戶端的證書進行驗證。但是，因為缺乏公鑰體系結構，當今的大多數(shù)服務器不進行客戶端認證。

步驟4：協(xié)商用于加密的消息加密算法和用于完整性檢查的哈希函數(shù)。通常由客戶機提供它支持的所有算法列表，然后由服務器選擇最強健的加密算法。

步驟5：客戶機和服務器通過下列步驟生成會話密鑰：

a.客戶機生成一個隨機數(shù)，并使用服務器的公鑰(從服務器的證書中獲得)對它加密，發(fā)送到服務器上。

b.服務器用更加隨機的數(shù)據(jù)(從客戶機的密鑰可用時則使用客戶機密鑰;否則以明文方式發(fā)送數(shù)據(jù))響應。

c.使用哈希函數(shù)，從隨機數(shù)據(jù)生成密鑰。

SSL協(xié)議的優(yōu)點是它提供了連接安全，具有3個基本屬性：

l 連接是私有的。在初始握手定義了一個密鑰之后，將使用加密算法。對于數(shù)據(jù)加密使用了對稱加密(例如DES和RC4)。

l 可以使用非對稱加密或公鑰加密(例如RSA和DSS)來驗證對等實體的身份。l 連接時可靠的。消息傳輸使用一個密鑰的MAC，包括了消息完整性檢查。其中使用了安全哈希函數(shù)(例如SHA和MD5)來進行MAC計算。

對于SSL的接受程度僅僅限于HTTP內(nèi)。它在其他協(xié)議中已被表明可以使用，但還沒有被廣泛應用。

注意：IETF正在定義一種新的協(xié)議，叫做“傳輸層安全”(Transport Layer Security,TLS)。它建立在Netscape所提出的SSL3.0協(xié)議規(guī)范基礎上;對于用于傳輸層安全性的標準協(xié)議，整個行業(yè)好像都正在朝著TLS的方向發(fā)展。但是，在TLS和

SSL3.0之間存在著顯著的差別(主要是它們所支持的加密算法不同)，這樣，TLS1.0和SSL3.0不能互操作。

2.SSH(安全外殼協(xié)議)

SSH是一種在不安全網(wǎng)絡上用于安全遠程登錄和其他安全網(wǎng)絡服務的協(xié)議。它提供了對安全遠程登錄、安全文件傳輸和安全TCP/IP和X-Window系統(tǒng)通信量進行轉發(fā)的支持。它可以自動加密、認證并壓縮所傳輸?shù)臄?shù)據(jù)。正在進行的定義SSH協(xié)議的工作確保SSH協(xié)議可以提供強健的安全性，防止密碼分析和協(xié)議攻擊，可以在沒有全球密鑰管理或證書基礎設施的情況下工作的非常好，并且在可用時可以使用自己已有的證書基礎設施(例如DNSSEC和X.509)。

SSH協(xié)議由3個主要組件組成：

l 傳輸層協(xié)議，它提供服務器認證、保密性和完整性，并具有完美的轉發(fā)保密性。有時，它還可能提供壓縮功能。

l 用戶認證協(xié)議，它負責從服務器對客戶機的身份認證。

l 連接協(xié)議，它把加密通道多路復用組成幾個邏輯通道。

SSH傳輸層是一種安全的低層傳輸協(xié)議。它提供了強健的加密、加密主機認證和完整性保護。SSH中的認證是基于主機的;這種協(xié)議不執(zhí)行用戶認證。可以在SSH的上層為用戶認證設計一種高級協(xié)議。

這種協(xié)議被設計成相當簡單而靈活，以允許參數(shù)協(xié)商并最小化來回傳輸?shù)拇螖?shù)。

密鑰交互方法、公鑰算法、對稱加密算法、消息認證算法以及哈希算法等都需要協(xié)商。數(shù)據(jù)完整性是通過在每個包中包括一個消息認證代碼(MAC)來保護的，這個MAC是根據(jù)一個共享密鑰、包序列號和包的內(nèi)容計算得到的。

在UNIX、Windows和Macintosh系統(tǒng)上都可以找到SSH實現(xiàn)。它是一種廣為接受的協(xié)議，使用眾所周知的建立良好的加密、完整性和公鑰算法。

3.SOCKS協(xié)議

“套接字安全性”(socket security,SOCKS)是一種基于傳輸層的網(wǎng)絡代理協(xié)議。它設計用于在TCP和UDP領域為客戶機/服務器應用程序提供一個框架，以方便而安全的使用網(wǎng)絡防火墻的服務。

SOCKS最初是由David和Michelle Koblas開發(fā)的;其代碼在Internet上可以免費得到。自那之后經(jīng)歷了幾次主要的修改，但該軟件仍然可以免費得到。SOCKS版本4為基于TCP的客戶機/服務器應用程序(包括telnet、FTP,以及流行的信息發(fā)現(xiàn)協(xié)議如http、WAIS和Gopher)提供了不安全的防火墻傳輸。SOCKS版本5在RFC1928中定義，它擴展了SOCKS版本4，包括了UDP;擴展了其框架，包括了對通用健壯的認證方案的提供;并擴展了尋址方案，包括了域名和IPV6地址。

當前存在一種提議，就是創(chuàng)建一種機制,通過防火墻來管理IP多點傳送的入口和出口。這是通過對已有的SOCKS版本5協(xié)議定義擴展來完成的，它提供單點傳送TCP和UDP流量的用戶級認證防火墻傳輸提供了一個框架。但是，因為SOCKS版本5中當前的UDP支持存在著可升級性問題以及其他缺陷(必須解決之后才能實現(xiàn)多點傳送)，這些擴展分兩部分定義。

l 基本級別UDP擴展。

l 多點傳送UDP擴展。

SOCKS是通過在應用程序中用特殊版本替代標準網(wǎng)絡系統(tǒng)調(diào)用來工作的(這是為什么SOCKS有時候也叫做應用程序級代理的原因)。這些新的系統(tǒng)調(diào)用在已知端口上(通常為1080/TCP)打開到一個SOCKS代理服務器(由用戶在應用程序中配置，或在系統(tǒng)配置文件中指定)的連接。如果連接請求成功，則客戶機進入一個使用認證方法的協(xié)商，用選定的方法認證，然后發(fā)送一個中繼請求。SOCKS服務器評價該請求，并建立適當?shù)倪B接或拒絕它。當建立了與SOCKS服務器的連接之后，客戶機應用程序把用戶想要連接的機器名和端口號發(fā)送給服務器。由SOCKS服務器實際連接遠程主機，然后透明地在客戶機和遠程主機之間來回移動數(shù)據(jù)。用戶甚至都不知道SOCKS服務器位于該循環(huán)中。

使用SOCKS的困難在于，人們必須用SOCKS版本替代網(wǎng)絡系統(tǒng)調(diào)用(這個過程通常稱為對應用程序SOCKS化---SOCKS-ification或SOCKS-ifying)。幸運的是，大多數(shù)常用的網(wǎng)絡應用程序(例如telnet、FTP、finger和whois)都已經(jīng)被SOCKS化，并且許多廠商現(xiàn)把SOCKS支持包括在商業(yè)應用程序中.·散列表：

基本思想：散列表(又稱“哈希表”)，以查找碼的值為自變量，通過一定的函數(shù)關系，計算出對應的函數(shù)值，并以它作為該結點的存儲地址，對結點進行存儲。查找時，再根據(jù)查找碼，用同一個函數(shù)計算出地址，去取出結點。

特點：在散列表中可對結點進行快速檢索。

·散列函數(shù)：

選擇標準：選擇一個好的散列函數(shù)，對于使用散列表方法是很關鍵的。對于查找碼中的任一值，經(jīng)散列函數(shù)交換，映像到地址集合中任一地址的概率是相等的，即所得地址在整個地址區(qū)間中是隨機的，稱此類哈希函數(shù)是“均勻”的。“均勻”是衡量好的哈希函數(shù)的主要標準。

·碰撞的處理：

碰撞的定義：在散列法中，不同的關鍵碼值可能對應到同一存儲地址，即k1!=k2，但h(k1)=h(k2)現(xiàn)象，稱作碰撞(或沖突)。

處理方法：

(1)開放地址法(線性探測法)：就是當碰撞發(fā)生時形成一個探測序列，沿著這個序列逐個地址探測，直到找到一個開放的地址(即未被占用的單元)、將發(fā)生碰撞的關鍵碼值存入該地址中。最簡單的探測序列為線性探測序列，即若發(fā)生碰撞的地址為d，則探測的地址序列為：

d+1,d+2,...,m-1,0,1,...,d-1

其中，m是散列表存儲區(qū)域大小。

(2)拉鏈法：就是給散列列表每個結點增加一個link字段，當碰撞發(fā)生時利用link字段拉鏈，建立鏈接方式的同義詞于表。每個同義詞子表的第一個元素都在散列表基本區(qū)域中、同義詞其他元素，采用建立溢出區(qū)的方法，即另開辟一片存儲區(qū)間作為溢出區(qū)，用于存放各同義詞表的其他元素。

傳輸層是TCP/IP模型中的核心層次，提供面可靠地向連接的TCP協(xié)議和不可靠面向無連接的UDP協(xié)議，為信息互聯(lián)提供了基礎。傳輸層的安全協(xié)議彌補了網(wǎng)際層安全的協(xié)議如IPSec等協(xié)議的不足，同時也為高層應用層的進程和安全協(xié)議如S-HTTP、HTTPS等協(xié)議提供了有力的保障。

第二篇：傳輸層協(xié)議分析實驗報告

2.傳輸層協(xié)議分析 2.A 數(shù)據(jù)包 捕獲分析部分 2.1 實驗目的 理解 TCP 報文首部格式和字段的作用，TCP 連接的建立和釋放過程，TCP 數(shù)據(jù)傳輸中編號與確認的作用。

2.2 實驗內(nèi)容 應用 TCP 應用程序傳輸文件，截取 TCP 報文，分析 TCP 報文首部信息，TCP 連接的建立過程，TCP 數(shù)據(jù)的編號和確認機制。

2.3 實驗原理 TCP 協(xié)議是傳輸控制協(xié)議的簡稱，工作在網(wǎng)絡層協(xié)議之上，是面向連接的，可靠的，端到端的傳輸層協(xié)議。

1)TCP 的報文格式 TCP 報文段分為頭部和數(shù)據(jù)兩部分，如圖 1：

圖 1

TCP 報文段的總體結構 TCP 首部 TCP 數(shù)據(jù)部分

TCP 報文段首部又分為固定部分和選項部分，固定部分為 20B，如圖 2 所示，這些字段的組合實現(xiàn)了 TCP 的所有功能。

圖 2 TCP 報文段的首部

0

源端口 目的端口 序號 確認號 頭部 長度（4bit）

保留 U R G A C K P S H R S T S Y N F I N

窗口 校驗和 緊急指針 選項（長度可變）

填充 TCP 采用傳輸輸連接的方式傳送 TCP 報文，傳輸連接包括連接建立、數(shù)據(jù)傳輸和連

接釋放三個階段。

2)TCP 連接的建立 TCP 連接建立采用“3 次握手”方式。

首先，主機 A 的 TCP 向主機 B 的 TCP 發(fā)出連接請求報文段，其首部中的同步位 SYN 應置 1，同時選擇一個序號 X，表明在后面?zhèn)魉蛿?shù)據(jù)時的第一個數(shù)據(jù)字節(jié)的序號是 X+1，如圖 3所示：

圖 3

TCP 連接建立的 3 次握手過程

然后，主機 B 的 TCP 收到連接請求報文段后，若同意，則發(fā)回確認。在確認報文段中應將 SYN 和 ACK 都置 1，確認號應為 X+1，同時也為自己選擇一個序號 Y。

最后，主機 A 的 TCP 收到 B 的確認后，要向 B 發(fā)回確認，其 ACK 置 1,確認號為 Y+1，而自己的序號為 X+1。TCP 的標準規(guī)定，SYN 置 1 的報文段都要消耗掉一個序號。同時，運行客戶進程的主機 A 的 TCP 通知上層應用進程，連接已經(jīng)建立。當主機 A 向 B 發(fā)送第一個數(shù)據(jù)報文段時，其序號仍為 X+1，因為前一個確認報文段并不消耗序號。

當運行服務器進程的主機 B 的 TCP 收到主機 A 的確認后，也通知其上層應用進程，連接已經(jīng)建立。

另外，在 TCP 連接建立的過程中，還利用 TCP 報文段首部的選項字段進行雙方最大報文段長度 MSS 協(xié)商，確定報文段的數(shù)據(jù)字段的最大長度。雙方都將自己能夠支持的 MSS 寫入選項字段，比較之后，取較小的值賦給 MSS，并應用于數(shù)據(jù)傳送階段。

3)TCP 數(shù)據(jù)的傳送 為了保證TCP傳輸?shù)目煽啃裕琓CP采用面向字節(jié)的方式，將報文段的數(shù)據(jù)部分進行編號，每個字節(jié)對應一個序號。并在連接建立時，雙方商定初始序號。在報文段首部中，序號字段和數(shù)據(jù)部分長度可以確定發(fā)送方傳送數(shù)據(jù)的每一個字節(jié)的序號，確認號字段則表示接收方希望下次收到的數(shù)據(jù)的第一個字節(jié)的序號，即表示這個序號之前的數(shù)據(jù)字節(jié)均已收到。這樣既做到了可靠傳輸，又做到了全雙工通信。

當然，數(shù)據(jù)傳送階段有許多復雜的問題和情況，如流量控制、擁塞控制、重傳機制等，本次實驗不探究。

被動打開 主動打開 確認

確認 連接請求

4)TCP 連接的釋放 在數(shù)據(jù)傳輸結束后，通信的雙方都可以發(fā)出釋放連接的請求。TCP 連接的釋放采用“4次握手”。如圖

應 用 進 程 釋放連接通知主機應用進程A不再發(fā)送報文確認 應用進程釋放連接①②確認B不再發(fā)送報文FIN,SEQ-XACK,SEQ=Y,ACK=X+1FIN,ACK,SEQ=Y,ACK=X+1ACK,SEQ=X+1,ACK=Y+1AB 圖 4 TCP 連接釋放的 4 次握手過程 首先，設圖 4 中主機 A 的應用進程先向其 TCP 發(fā)出釋放連接的請求，并且不再發(fā)送數(shù)據(jù)。TCP 通知對方要釋放從 A 到 B 這個方向的連接，將發(fā)往主機 B 的 TCP 報文段首部的中止位置 1，其序號 X 等于前面已傳送過的數(shù)據(jù)的最后一個字節(jié)的序號加 1。

主機 B 的 TCP 收到釋放連接通知后即發(fā)出確認，其序號為 Y，確認號為 X+1，同時通知高層應用進程，如圖中的箭頭①。這樣從 A 到 B 的連接就被釋放了，連接處于半關閉狀態(tài)，相當于主機 A 對主機 B 說“我已經(jīng)沒有數(shù)據(jù)發(fā)送了。但是如果你還有數(shù)據(jù)要發(fā)送，我仍然接收。” 此后，主機 B 不再接收 A 發(fā)來的數(shù)據(jù)。但若主機 B 還有一些數(shù)據(jù)要發(fā)給 A，則可以繼續(xù)發(fā)送（這種情況很少）。主機 A 只要正確收到數(shù)據(jù)，仍然向 B 發(fā)送確認。

若主機 B 不再向主機 A 發(fā)送數(shù)據(jù)，其應用進程就通知 TCP 釋放連接，如圖中的箭頭②。主機 B 發(fā)出的連接釋放報文段必須將中止位 FIN 和確認位 ACK 置 1，并使其序號仍為 Y（因為簽名發(fā)送的確認報文段不消耗序號），但是還必須重復上次已經(jīng)發(fā)送過的 ACK＝X+1。主機A 必須對此發(fā)出確認，將 ACK 置 1，ACK=Y+1,而自己的序號仍然是 X+1，因為根據(jù) TCP 標準，前面發(fā)送過的 FIN 報文段要消耗掉一個序號。這樣就把 B 到 A 的反方向的連接釋放掉。主機A 的 TCP 再向其應用進程報告，整個連接已經(jīng)全部釋放。

2.4 實驗步驟 驟 步驟 1

在 Wireshark 中設置過濾條件，協(xié)議為 TCP

HTTP，地址為本機－>any，并開始截獲報文;步驟 2

打開 www.tmdps.cn.，完成后，保存截獲的報文并命名為“TCP 學號”，分析捕獲的報文。

這里，TCP 的連接和建立采用的是：

三次握手

方式，本機是

192.168.3.3

，遠端主機是 192.168.3.183。

步驟 3

分析 TCP 連接建立過程的前 3 個報文，填寫下表 1：

表 表 1

TCP 建立過程的三個報文信息 字段名稱 第一條報文 第二條報文 第三條報文

報文序號 1704 1716 1718 Sequence Nunber 830 849 835 ACK Number 289 291 237 ACK 1 291 1 SYN 1 1 1

步驟 4

分析截獲報文中數(shù)據(jù)發(fā)送部分的第一條 TCP 報文及其確認報文，將報文中的字段值填寫在表格 2 中。

表 表 2

TCP 報文首部信息

字段名 長度 字段值 字段意義 發(fā)送報文 確認報文 源端口 16 發(fā)送

目標端口 16 確認 端口號是唯一標識 序號 32

確認好 32 確認

頭部長度 4

保留 6

保留字段 窗口 16

校驗和 16

緊急指針 16

選項（長度可變）

步驟 5

TCP 連接建立時，其報文首部與其它 TCP 報文不同，有一個 option 字段，它的作用是什么？結合 IEEE802.3 協(xié)議規(guī)定的以太網(wǎng)最大幀長分析此數(shù)據(jù)是怎么得出來的？ 步驟 6

分析 TCP 數(shù)據(jù)傳送階段的前 8 個報文，將報文信息填入表 3：

表 表 3

TCP 數(shù)據(jù)傳送部分的前 8 個報文 報文序號 報文種類 序號字段 確認號字段 數(shù)據(jù)長度 被確認報文序號 窗口 3744 確認 289 1 324 289 123 3754 發(fā)送 1 0 66

16580 3764 確認 1 1 344 291 123 3784 發(fā)送 1 0 66

16579 3794 確認 237 1 290 237 123 3804 發(fā)送 1 0 66

16593 3814 確認 289 0 290 290 16768 3824 確認 290 1 290 290 16768

2.5

實驗總結 在實驗中，通過分析截獲的 TCP 報文首部信息，可以看到首部中的序號、確認號等字段是 TCP 可靠連接的基礎。

分析 TCP 頭部信息，分析“3 次握手”過程。通過對數(shù)據(jù)傳送階段報文的初步分析，了解數(shù)據(jù)的編碼和確認機制。

總之，TCP 協(xié)議中的各項設置都是為了在數(shù)據(jù)傳輸時提供可靠的面向連接的服務。

2.B 編程造 構造 UDP 數(shù)據(jù)包 部分 使用 C 語言構造 UDP 數(shù)據(jù)包程序。

1)UDP 首部和偽首部結構體定義

/* UDP 首部*/ struct udphdr{ unsigned short u_src;unsigned short u_dst;unsigned short u_len;unsigned short u_cksum;char u_data[U_MAXLEN];//UDP 中校驗使用的偽首部 struct pseudo_header {int srcIp;short udp_len;char rsv;char protocol;unsigned short src_port;

};unsigned short dsc_port;unsigned short len;unsigned short check_sum;char data[2];};

2）構建 UDP 報文數(shù)據(jù)

int build_udp_Package(struct socket_pair * sp,const unsigned char *buf,int len,unsigned char *udpPacket[],int *udpPacketLen){ *udpplen=sizeof(struct udp_hdr)+len;struct udp_hdr*uh=(struct udp_hdr*)udppkt;unsigned char*dbuf=(udppkt+sizeof(struct udp_hdr));memcpy(dbuf,buf,len);Uh->source=htons(s_port);Uh->dest=htons(d_port);Uh->len=htons(sizeof(struct udp_hdr0)+len);Uh->check=0;Un->check=udpcksum(d_ip,d_port,s_ip,udppkt,sizeof(struct udp_hdr)+len);return udppkt;}

第三篇：房屋加層協(xié)議

房屋加層協(xié)議

甲方：吳勇軍，武陵源寶峰路居委會八組 乙方：滿維勇，慈利縣楊柳鋪級新溥村一組

現(xiàn)將甲方現(xiàn)有住房二層再加上二層，共為四層，承包給乙方修建，采用八萬六千八佰元，包工包料的方式給乙方一次性包干，現(xiàn)將有關事項協(xié)議如下： 一、一層門前方加二根磚柱，廚房和衛(wèi)生間給建為一個標間，樓梯下面改為衛(wèi)生間。二、二層樓梯上半跑打掉縮短休息臺一米寬。三、三層達到四個標間，在三層上方是圈梁，預制板結構。四、四層達到四個標間，在四層上方，是整體現(xiàn)膠結構。五、五層隔熱層就是前面雨散50公分寬，前面一口夸起尖，樓梯口后面是平臺。

六、其它，包括前后落水管到位，室內(nèi)電線口是組到位，房屋的前面墻包做外漆包括磚柱。

七、乙方在施工期間，一是要保證該房屋的質(zhì)量，材料的質(zhì)量保證上等達到甲方滿意。乙方在施工期間，應該是安全第一、質(zhì)量第一，施工期間乙方發(fā)生任何事故與甲方無關，甲方概不負責，乙方自行處理。

八、付款方式：①乙方動工時付乙方壹萬伍仟元；②一層完工時付乙方貳萬元；③主體完工時，付乙方貳萬伍仟元；④整棟房屋完工時，經(jīng)過甲方驗收后滿意，付乙方全部工資，結清雙方滿意協(xié)議。

九、房屋工期，從動工時之日起，除下雨天例外20天保證完成主體結構。

另外：四層頂后面現(xiàn)膠做不銹鋼護手欄桿。以上協(xié)方雙方簽字后，生法律效力。

甲方：

乙方：

見證人：

簽約時間：

簽約地址：

第四篇：設備層租賃協(xié)議

房屋租賃協(xié)議

甲方：大連潤祥房地產(chǎn)開發(fā)有限公司

乙方：大連眾泰物業(yè)服務有限公司

根據(jù)《中華人民共和國合同法》、《中華人民共和國城市房地產(chǎn)管理法》及其他法律法規(guī)，甲乙雙方本著平等、自愿、公平、誠實信用的原則，經(jīng)協(xié)商一致，就乙方租賃甲方開發(fā)建設的潤澤園項目設備層一事，達成如下協(xié)議：

第一條房屋基本情況

（一）甲方開發(fā)建設的潤澤園項目設備層分別位于（詳見附表一）。

（二）房屋現(xiàn)狀：水泥砂漿地面、混合砂漿墻面及棚面；無間隔墻、無采暖、無給排水管道及設備（有給排水預留接駁口）、無電氣線路敷設（有電源預留接駁口）；位于二層的設備層內(nèi)排水管道水平管較多，對層高有限制。

（三）房屋權屬情況：

該房屋產(chǎn)權屬于甲方，甲方保證該房屋沒有產(chǎn)權糾紛。如因甲方原因使乙方不能如期使用或發(fā)生債權債務糾紛，由甲方承擔相應責任。

第二條 租賃期限

自2014年6月 15日至 2024年6月14日。

第三條 用途

乙方租賃本房屋，經(jīng)裝修改造后，部分用于職工宿舍，剩余部分對外經(jīng)營，雙方約定，對外經(jīng)營部分只能用于居住、辦公，不可用于工業(yè)、商業(yè)等對環(huán)境有污染、擾民等項目。

第四條 租金及支付

（一）租金：位于二層頂?shù)暮嫌?套，每套每年租金壹萬元，租期10年，租金合計：肆拾萬元；位于十六層頂?shù)?套，每套每年租金壹萬伍仟元，租期10年，租金合計：陸拾萬元，租金共計：壹佰萬元。

（二）租金支付方式：

第五條 各方責任

（一）甲方責任

1.合同簽訂后，甲方應向乙方提供所有設備層的竣工圖紙等詳細資料，作為乙方裝修改造的技術依據(jù)；

2.甲方保證其出租的房屋具備合法出租條件；

3.甲方應積極配合乙方的裝修改造工作，為乙方的裝修改造工作提供技術支持；

4.甲方有義務協(xié)助乙方辦理采暖、給排水、供電、網(wǎng)絡通信等接駁手續(xù)；

5.甲方

（二）乙方責任

1．乙方承諾租賃后的用途及使用范圍符合甲方要求；

2．乙方的裝修改造工作，應保證建筑物的結構安全，滿足環(huán)保及消防要求；

3．乙方在使用及經(jīng)營過程中，不得存在擾民行為；

4．乙方在租賃期間負責對房屋設施的維修保養(yǎng)；

5.；

6.受托人充分利用自身所擁有的推廣途徑，對委托人房屋進行推介，并協(xié)助租賃雙方達成交易，協(xié)助交易雙方辦理相關房屋轉移手續(xù)；

7．除本協(xié)議約定的費用外不以任何方式或理由向委托人收取其他費用；

8．未經(jīng)委托人同意不得將委托事項轉委托其它房地產(chǎn)經(jīng)紀機構或個人；

9．受托人同時接受交易雙方委托的，應向雙方當事人如實說明情況；

第七條 違約責任

（一）委托人違約責任

1.委托人故意提供虛假的上述房屋證件和資料的，受托人有權單方解除本協(xié)議，給受托人造成損失的，委托人應依法承擔賠償責任；

2.委托人泄露由受托人提供的租賃人資料，給受托人、租賃人造成損失的，委托人應依法承擔賠償責任；

3.委托人在委托期限內(nèi)或委托期滿十二個月內(nèi)自行與受托人介紹之客戶達成交易的，應按照本協(xié)議約定的標準向受托人支付傭金。

（二）受托人違約責任

1.受托人違背執(zhí)業(yè)保密義務，不應泄露委托人商業(yè)秘密或個人隱私，給委托人造成損害的，應按照相應標準支付違約金，約定違約金不足以彌補委托人損失的，委托人有權要求補充賠償，賠償金額視情節(jié)嚴重程度由雙方協(xié)商決定，協(xié)商不成，賠償金額以人民法院判定結果為準。

2.受托人有隱瞞、虛構信息或惡意串通等影響委托人利益的行為，委托人除有權解除本協(xié)議、要求退還已支付的相關款項外，受托人還應按照相應標準，向委托人支付違約金；違約金金額視情節(jié)嚴重程度由雙方協(xié)商決定，協(xié)商不成，違約金金額以人民法院判定結果為準。

3.在委托代辦事項中，受托人因工作疏漏，遺失委托人的證件、文件、資料、發(fā)票等，應給予相應經(jīng)濟補償；經(jīng)濟補償金額視情節(jié)嚴重程度由雙方協(xié)商決定，協(xié)商不成，經(jīng)濟補償金額以人民法院判定結果為準。

4、委托人委托受托人代辦稅費繳納事項，費用由委托方承擔，受托方在需要繳納相關稅費前7個工作日提交相關稅費明細給委托方，委托方5個工作日內(nèi)審核完畢并支付，受托方繳納完相關稅費后將稅務發(fā)票原件交給委托方，受托方可保留發(fā)票的復印件備查。因委托方原因未能及時繳納稅費，責任由委托方承擔，因受托方原因未能及時繳納稅費，責任由受托方承擔。

第八條不可抗力

因不可抗力不能按照約定履行本協(xié)議的，根據(jù)不可抗力的影響，可部分或全部免除責任。

第九條 協(xié)議變更與解除

（一）協(xié)議變更

在本協(xié)議履行期間，任何一方要求變更本協(xié)議條款，應書面通知對方，并經(jīng)雙方協(xié)商一致，可達成補充協(xié)議。補充協(xié)議為本協(xié)議的組成部分，與本協(xié)議具有同等效力。

（二）協(xié)議解除

經(jīng)雙方協(xié)商一致，可解除本協(xié)議。

第十條 爭議處理

本協(xié)議在履行中如發(fā)生爭議，雙方應協(xié)商解決。協(xié)商不能解決的，雙方同意按以下第（二）種方式解決糾紛。

（一）提交北京仲裁委員會仲裁；

（二）任何一方均可向房屋所在地人民法院提起訴訟。

第十一條本協(xié)議一式4份，具有同等法律效力，其中委托人2份，受托人2份，合同執(zhí)行期滿后自動失效。

第十二條 其他約定

本協(xié)議執(zhí)行期滿后，如果委托方繼續(xù)對本委托物業(yè)對外出租，受托方在同等條件下有優(yōu)先續(xù)約權。

委 托 人（簽章）：

大連潤祥房地產(chǎn)開發(fā)有限公司

法人代表（簽字）：

授權代表（簽字）：

簽訂時間：20年月

受 托 人（簽章）： 大連眾泰物業(yè)服務有限公司 法人代表（簽字）： 授權代表（簽字）：日

第五篇：CCNA學習指南 可靠傳輸協(xié)議

CCNA學習指南可靠傳輸協(xié)議

--奧山威克諾（西安尚賽）

EIGRP使用專用的RTP（可靠傳輸協(xié)議）來管理路由器間的消息傳輸，這些路由器必須能說并聽懂EIGRP語言。正如這個名稱所描述的，可靠是這個協(xié)議的核心。思科設計了一種使用杠桿原理來調(diào)節(jié)組播與單播的工作機制，從而實現(xiàn)了數(shù)據(jù)更新的快遞投遞以及對接收數(shù)據(jù)的跟蹤。

當EIGRP發(fā)送組播數(shù)據(jù)時，它使用D類的244.0.0.10地址，如前面講過的，每個EIGRP路由器都回注意到它的鄰居是誰，對于每一個要發(fā)送的組播，它都會維護一個應答鄰居的列表。如果EIGRP沒有收到某個鄰居發(fā)出的應答，那么它將嘗試切換到單播來重發(fā)同樣的數(shù)據(jù)。如果在嘗試發(fā)送了16次單播數(shù)據(jù)后，仍然沒有得到應答，則宣告此鄰居小時。人們通常將這個過程稱為可靠組播。

通過為每個數(shù)據(jù)包指定一個序列號，路由器可以跟蹤所發(fā)送的信息，通過這一技術，路由器可以從接收到的數(shù)據(jù)中鑒別出過時的、重復的或者是錯序的信息。

由于EIGRP是一個穩(wěn)定的協(xié)議，做到這些是十分必要的。EIGRP只在啟動時同步整個路由選擇數(shù)據(jù)庫，之后只在有變化時傳送變動的部分，從而維持路由選擇數(shù)據(jù)庫的連貫性。而持續(xù)的丟包或錯序接受都將會破壞這一連貫性，導致路由數(shù)據(jù)庫的混亂。