前言：中文期刊网精心挑选了tpp协议范文供你参考和学习，希望我们的参考范文能激发你的文章创作灵感，欢迎阅读。
tpp协议范文1
【关键词】tpp 经济格局 影响与展望
一、TPP简介
最早由APEC成员国中的新西兰、新加坡、智利、文莱四国发起的多边自由贸易协定――“跨太平洋战略经济伙伴关系”，原本无人问津，随着2009年美国宣布加入“跨太平洋伙伴关系协议”（简称TPP）谈判，开始受到各界关注。TPP的最终目标是要建成亚太地区市场准入水平更高、竞争政策范围更广、知识产权保护力度更大、劳工和环境标准更严、争端解决约束力更强的高标准自由区。耗时多年的TPP基本协议初步达成。
TPP只是美国应对东亚合作、获得非传统经济利益的工具。从成本收益的角度分析，经济小国或许能够从TPP中获益，但是对大国而言，TPP的经济价值甚微。TPP造成的贸易转移会使中国每年损失大约1000亿美元的出口，越南将是TPP达成的最大赢家，与中国、孟加拉国、印度等国家相比，越南将可以以更加优惠的条件向美国市场出口纺织品。
二、美国推动TPP的原因分析
（一）经济层面
TPP将给美国带来出口的大幅增长。美国的出口行业是美国加入TPP谈判的最大的受益者，比如农业领域以及那些依赖于知识产权的行业。美国农产品要出口到日本等国家仍面临很多障碍；另外有赖于知识产权行业的诸如制药、电影、媒体等行业都会得到适当的益处。TPP生效意味着美国会降低纺织业、制衣业和鞋业等关税，这些行业都将面临更激烈的挑战，也意味着一定的损失。一些学者对美国加入TPP，以及日本进一步加入TPP后的福利效应分析进行了有益的尝试。虽然这些研究基于静态模型，且对TPP成员扩大情况、TPP情景假设等方而的考虑还稍显不足，但是其基本结论却明确显示，美国加入TPP，所拉动的GDP增幅并不明显。
（二）政治层面
美国总统提出了转向亚洲或是亚洲再平衡，这是美国加强与亚洲经济关系的第一步。TPP包括了劳动者和环境保护，国有企业优惠限制等迄今为止贸易协定从未涉及的领域。事实上，与其说参与TPP是美国的短期经济行为，不如说是其战略性选择。一方面，TPP有助于提高美国企业参与亚太地区的商业机会与竞争能力。有研究表明，排除美国的亚洲经济一体化将导致美国福利受损，而TPP将会使美国的企业得到亚洲市场的准入机会。另一方面，美国通过TPP来达到平衡中国经济发展的影响，有助于维持美国的长期经济影响力。通过维持与韩国、日本等国家的经济联系甚至政治安全联系，达到排除中国竞争，确保美国主导亚太格局不受挑战。
三、TPP对中国经济的影响分析
（一）经济层面
中国是一个外向型经济体，具有较高贸易依存度。中国经济长期以来的发展与增长是对外贸易发挥重要作用。TPP对中国出口的影响体现在两个方面，一是出口贸易国的限制，二是出口条款规定的制约。TPP各成员国产业本身有内部互补性及贸易转移效应，TPP是南北合作型的区域贸易组织，区域内各国经济发展水平及出口产品各不相同。TPP中的新兴经济体同我国的产业结构及要素分配趋同，市场和结构上存在强烈同构性竞争。此外，TPP中高标准的过境审查程序对我国的出口贸易将一定的负面影响。
（二）政治层面
TPP的达成，“去中国化”导致中国被孤立，很可能意味着以“10+X”为主体的亚洲区域经济合作进程陷入停滞。与此同时，TPP战略的实施也削弱了中国对东亚区域的战略影响力。近年来，东亚地区经济发展和经济合作关系十分紧密，东亚经济一体化有了一个初步的尝试。随着东盟和亚太经合组织的成立，亚太地区的联系日益密切，亚太经济一体化程度越来越高。随着中国国际地位的不断提升，中国发展壮大成为亚太地区的第二大经济体，在亚太地区的影响力也不断扩大，相比之下，美国在亚太地区的影响力越来越力不从心，因而借助TPP将中国排除，使中国在东亚地区被边缘化。
四、小结
TPP不是一个排他的、封闭的国际贸易体系，并不是参加了TPP后，其成员国就要与其他非成员国断绝一切贸易往来。许多TPP成员国也是其他贸易协定的成员，也存在各种多边（贸易联盟）或双边协议。中国要采取相应的政策和措施，密切关注TPP的发展势头，及时调整方针政策并作出反应。更重要的是，应该提高自身的竞争力，更进一步深化改革，努力改善市场环境，尽可能适应瞬息万变的国际环境。同时，也应该探索TPP以外的各种可能的有利于周边地区经济发展的途径。
参考文献：
[1]全毅.TPP对东亚区域经济合作的影响：中关对话语权的争
夺日[J].亚太经济，2012（5）：12-18.
[2]乔其明，窦尔翔，李东阳.TPP谈判及其对中美贸易的影响
与战略[J]，2014（09）：11-13.
[3]杨立强，鲁淑.TPP与中日韩FTA经济影响的GTAP模拟分
析[J].东北亚论坛，2013（4）：39-47.
[4]王晶.TPP达成对我国制造业国际化的潜在影响及对策
[J].现代管理科学，2016（7）：85-86.
[5]罗凯天.TPP 劳工条款及其对中国的影响与应对研究[J].
tpp协议范文2
[关键词]TCP协议 网络安全 协议攻击
一、TCP连接的建立与终止
1.概述
虽然TCP使用不可靠的IP服务，但它却提供一种可靠的运输层服务。
2.建立连接协议(三次“握手”)
(1)客户端发送一个带SYN标志的TCP报文到服务器。这是三次握手过程中的报文1.
(2)服务器端回应客户端的，这是三次握手中的第2个报文，这个报文同时带ACK标志和SYN标志。因此它表示对刚才客户端SYN报文的回应；同时又标志SYN给客户端，询问客户端是否准备好进行数据通讯。
(3)客户必须再次回应服务段一个ACK报文，这是报文段。
3.连接终止协议(四次握手)
由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。
(1)TCP客户端发送一个FIN，用来关闭客户到服务器的数据传送(报文段4)。
(2)服务器收到这个FIN，它发回一个ACK，确认序号为收到的序号加1(报文段5)。和SYN一样，一个FIN将占用一个序号。
(3)服务器关闭客户端的连接，发送一个FIN给客户端(报文段6)。
(4)客户段发回ACK报文确认，并将确认序号设置为收到序号加1(报文段7)。
CLOSED：表示初始状态。
LISTEN：表示服务器端的某个SOCKET处于监听状态，可以接受连接了。
SYN_RCVD：这个状态表示接受到了SYN报文，在正常情况下，这个状态是服务器端的SOCKET在建立TCP连接时的三次握手会话过程中的一个中间状态，很短暂，基本上用netstat你是很难看到这种状态的，因此这种状态时，当收到客户端的ACK报文后，它会进入到ESTABLISHED状态。
SYN_SENT：这个状态与SYN_RCVD遥相呼应，当客户端SOCKET执行CONNECT连接时，它首先发送SYN报文，因此也随即它会进入到了SYN_SENT状态，并等待服务端的发送三次握手中的第2个报文。SYN_SENT状态表示客户端已发送SYN报文。
ESTABLISHED：表示连接已经建立了。
FIN_WAIT_1：FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是：FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即进入到FIN_WAIT_1状态。而当对方回应ACK报文后，则进入到FIN_WAIT_2状态，当然在实际的正常情况下，无论对方何种情况下，都应该马上回应ACK报文，所以FIN_WAIT_1状态一般是比较难见到的，而FIN_WAIT_2状态还有时常常可以用netstat看到。
FIN_WAIT_2：上面已经详细解释了这种状态，实际上FIN_WAIT_2状态下的SOCKET，表示半连接，也即有一方要求close连接，但另外还告诉对方，我暂时还有点数据需要传送给你，稍后再关闭连接。
TIME_WAIT：表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可回到CLOSED可用状态了。如果FIN_WAIT_1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。
CLOSING：这种状态比较特殊，属于一种比较罕见的例外状态。正常情况下，当你发送FIN报文后，按理来说是应该先收到(或同时收到)对方的ACK报文，再收到对方的FIN报文。但是CLOSING状态表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文。什么情况下会出现此种情况呢?那就是如果双方几乎在同时close一个SOCKET的话，那么就出现了双方同时发送FIN报文的情况，也即会出现CLOSING状态，表示双方都正在关闭SOCKET连接。
CLOSE_WAIT：这种状态的含义表示在等待关闭。怎么理解呢?当对方close一个SOCKET后发送FIN报文给自己，你系统毫无疑问地会回应一个ACK报文给对方，此时则进入到CLOSE_WAIT状态。接下来呢，实际上你真正需要考虑的事情是察看你是否还有数据发送给对方，如果没有的话，那么你也就可以close这个SOCKET，发送FIN报文给对方，也即关闭连接。所以你在CLOSE_WAIT状态下，需要完成的事情是等待你去关闭连接。
LAST_ACK：这个状态是被动关闭一方在发送FIN报文后，最后等待对方的ACK报文。当收到ACK报文后，也即可以进入到CLOSED可用状态了。
二、TCP协议安全问题
1.概述
TCP协议现在用得非常广泛，但它本身也有一些安全上的缺陷。一些缺陷是由于主机使用IP源地址作为认证机制引起的；Berkeley的r系列涮用就是一个明显的例子。其它的一些缺陷是由于网络控制机制，特别是路由协议，缺少认证机制引起的。
2.TCP序列号预测攻击
TCP序列号预测攻击最早是1985年由Robort.Morris对这一安全漏洞进行阐述的。他使用TCP序列号预测，即使是没有从服务器得到任何响应，来产生一个TCP包序列。这使他能欺骗在本地网络上的主机。
(1)攻击方法。TCP协议有一个非常令人着迷的漏洞，简单的说，就是通过预测初始序列号来伪造TCP包.并且不需要得到回应。这样就可以使攻击者伪装成一台和服务器在同一个局域网上的一台可信任的机器。通常建立TCP连接需要三次握手。客户机送一个初始序列号ISNc，服务器应答它并送出它自己的序列号ISNs，客户机再发出一个应答包。这三个数据包发送以后，就可以传输数据了。这个过程可以用下图来表示：
C一>S：SYN(ISNc)
S一>C：SYN(ISNs)，ACK(ISNc)
C一>S：ACK(ISNs)
C一>S：data
And/or
S一>C：data
这就是说，要使一个连接建立起来，C必须知道ISNs，这个数多少有一些随机性，假没入侵者X有一种方法可以预测ISNs。在这种情况下，他可以通过以下的步骤来模仿可信任的主机T：
X->S：SYN(ISNx)，SRC=T
S->T：SYN(ISNs)，ACK(ISNx)
X一>S：ACKfISNs)，SRC=T
X一>S：ACK(ISNs)，SRC=T，nasty-data
即使S一>T的数据包不经过X，X也能知道它的内容，因此能发送数据。如果x在一个能够执行命令的连接上实行这种攻击(例如Berkeley rsh服务)，他就可以运行――恶意的命令。那么怎样预测随机的ISN 呢?在Berkeley系统中，初始序列号变量是以每秒固定的数目递增的，而每次连接的序列号就是这个变量的一半。因此，如果有人通过合法的连接观察ISNs，他就有很大的机会通过计算得到下一次连接的ISNS。
应该指出的是服务器的应答消息S一>T：SYN(ISNs)，ACK(ISNx)。并没有消除这种攻击；虽然真正的T主机将接收到它，并且会重设连接。这并不是一个严重的障碍，因为我们可以通过一些拒绝服务的攻击使T主机暂时失效，也可以在T主机关机或重起的时候攻击。还有一种通过netstat服务对TCP序列号进行的攻击。在这种攻击中，入侵者模仿一台关闭的主机。如果在目标机上有netstat服务.它就会提供另一个端口必要的序列号信息：这样就根本不需要猜测了。
(2)防御。很明显，这种攻击的关键是Berkeley系统中初始序列号变量变化方式太简单了。TCP标准要求这个变量必须以每秒钟将近250，000的速度增长：Berkerey系统则使用了一个比它慢得多的速度然而关键的因素是间隔的大小而不是平均速度。从4.2BSD系统的每秒增加128到4.3BSD 的每秒增加125，000的改变是没有意义的。下面让我们来看看以250，000的频率运行是否有用。为了简单起见，现忽略了其它连接产生的问题，仅仅考虑本计数器固定速度的改变：为了知道当前的序列号，必须发送一个SYN包，并接收它的回应。如下：
X一>S：SYNfISNx1
S一>X：SYN(ISNs)，ACK(ISNx)(1)
第一个使服务器产生下一序列号的伪造的数据包，可以紧跟在服务器对探测包的回应后送出：
X一>S：SYN(ISNx)，SRC=T (2)
序列号ISNs在应答中使用
S一>T：SYN(ISNs)，ACK(ISNx)
它是由数据包(1)产生到服务器接收到数据包(1)之间的时间唯一确定的。但是这个时间是由X到S的来回时间确定的。因此如果攻击者能够测量或预测到这个时间。即使使用一个能精确的4微秒的时钟也不能阻止这种攻击。对来回时间的测量能精确到什么程度呢?如果假设网络很稳定，我们可以精确到10毫秒左右。很明显，互联网不可能长期这么稳定.但是却有可能在一个较短的时间内稳定。因此我们有2500个ISNs的可能值。考虑到重新测量来回时间所需的时间，我们假设每次尝试需要花5秒，那么一个攻击者很可能在7500秒内获得成功。条件更好的网络或更精确的测量，能够提高成功的可能性。因此，仅仅是按TCP协议标准是不行的。在这里，我们默认的假设是目标机上不运行任何进程。实际上，当新的请求到达时，是会运行一些进程的。在一个6MIPS的机器上，一个时钟周期-4秒大约可执行25条指令。高优先级的中断TCB分配顺序的不同，都对下一个序列号有相当大影响。这种随机的效果是被认为是主机的优点。
参考文献：
tpp协议范文3
关键词： 流控制传输协议； 传输控制协议； 单路径； 多路径； 吞吐率； 延迟
中图分类号：TP393 文献标志码：A 文章编号：1006-8228（2013）05-03-04
Comparison study of TCP and SCTP routing protocol
He Shijie， Tong Mengjun
（School of computer science， Hangzhou Dianzi University， Hangzhou， Zhejiang 310018， China）
Abstract： In order to get better understanding of SCTP protocol performance， the NS-2 network simulation software is utilized to compare TCP and SCTP protocols from a single path and multi path. The experimental results show that， in response to the link's deteriorating condition， the SCTP protocol has a larger throughput capacity ， and also a higher stability， and it can meet the transmission requirement of high performance network.
Key words： stream control transmission protocol； transmission control protocol； single path； multi path； throughput rate； delay
0 引言
SCTP代表的是流控制传输协议，它是由IEFT的信令传输工作组（SIGTRAN）新近提出的一种面向多媒体通信的流控制协议（SCTP），用于在IP网络上传输PSTN信令消息，即通常所说的SS7 over IP。
在国内，1985年是流控制传输协议技术开始萌芽的时期。从1985到1995年，该技术主要局限于计算机网络中接人端口数据流的控制技术，以防止计算设备之间大量数据互相通信时出现阻塞，保证更高的传输效率和可靠性。目前对该技术的研发仍处于较浅的层次，对整个IP网络中实规PSTN信令传输的技术还鲜有涉及；国内的SCTP研究还主要侧重于应用方面，比如SCTP与TCP的比较、SCTP在移动环境下的性能研究（例如平滑切换，移动IP，最后一跳性能恶化问题，基于SCTP移动Internet传输模型等）、基于独立路径拥塞控制的SCTP负荷分担机制研究、结合SS7的研究，以及SCTP的安全问题研究、军事应用等。
国外则更侧重于起草标准，如：定义SCTP负荷分担草案（多路径同时传输）；制定部分可靠传输标准；提交建立SCTP偶联后的动态地址重配置；提交SCTP API草案；定义SCTP对移动IP的支持；提交单播拥塞控制建议标准；TCP友好可变速率控制等等。目前，IETF致力于把SCTP作为一种通用的传输协议。对SCTP本身的研究集中在对其功能的完善和扩展上，主要是从两个本质特点入手：多路径和多流。同时，对SCTP应用的研究主要集中在两个方面：在移动网络中的应用和对多媒体的传输。
本文的主要研究工作是利用NS-2构建仿真平台，对SCTP和TCP这两种协议进行对比，并根据仿真的结果计算、分析和比较这两种协议的性能，发现它们各自的优缺点。
1 TCP和SCTP的单路径的对比研究
单路径的实验拓扑图如图1所示，一共有6个节点，2个路由节点。其中0-2是发送节点，5-7是相应的接收节点。3个发送节点都绑定了FTP应用，其中0号节点的数据包发送往5号节点，流标签为1；1号节点的数据包发送往6号节点，流标签为2；2号节点的数据包发送往7号节点，流标签为3。设置最大的传输单元为1500。路由3、4间的droptail队列大小分别为5、10。本实验主要更改了1号节点和6号节点的传输协议。现在设0-5号节点的路径为L1，1-6号节点的路径为L2，2-7号的路径为L3。变量主要在L1上面。其中发送节点到路由节点3，路由节点4到接收节点的带宽均为10Mbps，延迟均为15ms。路由节点3、4直接的带宽为1.7Mbps，延迟为15ms。这样路由节点3、4之间就成为接收方和发送方直接的瓶颈。
图1 实验拓扑图
实验一的过程是：在0.5s的时候三个节点同时开始发送数据，4s的时候断开L1，7s的时候断开L2。这样做的主要目的是让L1的数据包先在有两个TCP传输协议竞争的情况下进行数据传输，然后逐渐断开其他两个链路的数据传输，来观察TCP和SCTP在有TCP竞争条件下，数据传输的吞吐量，延迟和丢包率。吞吐量如图2所示。
图2 实验一中TCP和SCTP数据的吞吐量
图2所表示的是链路L2上的数据吞吐量。X坐标轴表示时间的变化，单位为s，Y坐标轴表示接收的数据量，单位为Byte。红色线表示TCP协议在droptail队列为5时的数据吞吐量。绿色线表示TCP协议在droptail队列为10时的数据吞吐量。蓝色线为SCTP协议在droptail队列为5时的数据吞吐量，黄色为SCTP协议在droptail队列为10时的数据吞吐量。从图2中可以看出，总体上SCTP的吞吐量远远高过TCP。对于SCTP来说，在droptail队列为5的时候，其吞吐量比10的时候略高，但差距不是很大。在两个TCP数据传输断掉以后，两种情况下的吞吐量趋于相同，而且数据吞吐量趋于稳定。看趋势，在9s以后，droptail队列为10的时候，其吞吐量会略大于5的时候。对于TCP协议来说，很明显，在droptail队列为10的时候，其吞吐量高于5的时候，在两个TCP协议的数据传输都断掉以后，数据吞吐量的增长率趋于平行式增长。
图3 实验一中TCP和SCTP延迟对比
图3是实验一中SCTP和TCP两种协议数据传输延迟的对比。如图所示，是TCP和SCTP在droptail队列为5的时候，两种协议延迟的对比。红色线为TCP的延迟，绿色的为SCTP的延迟。X坐标轴表示数据传输的时间变化，单位为s，Y坐标轴表示两种协议在某个时刻的延迟，单位为s。从图3中可以看到，两者的数据线略有交叉，SCTP的延迟略高于TCP；TCP的延迟是在一个范围内上下波动，而SCTP的延迟呈一种阶段性的梯度变化。从这里也可以看出两种数据传输的差别：TCP在链路达到稳定的时候，每次传输的数据量一定；而SCTP的数据传输，在没有拥塞避免的情况下，是呈指数增长的。
根据实验一的拓扑图，更改链路L1和L3的数据传输时间，此为实验二。在0.5s的时候1号节点开始发送数据，在1.5s的时候0号节点开始发送数据，在4.5s的时候3号节点开始发送数据，在7.5s的时候将L1和L3两条链路断开连接，8s的时候结束数据传输。通过观察TCP和SCTP协议在逐渐有一个TCP协议和两个TCP协议竞争的条件下的数据吞吐量，延迟和丢包率来对比两种协议。
图4 实验二中TCP和SCTP两种协议的数据吞吐量
在图4中，表示的是链路L2上的数据吞吐量。X坐标轴表示时间的变化，单位为s，Y坐标轴表示接收的数据量，单位为Byte。红色线表示TCP协议在droptail队列为5时的数据吞吐量。绿色线表示TCP协议在droptail队列为10时的数据吞吐量。蓝色线为SCTP协议在droptail队列为5时的数据吞吐量，黄色为SCTP协议在droptail队列为10时的数据吞吐量。从图4中可以看出，总体上来说，在相同的droptail队列值的情况下，SCTP的吞吐量远大于TCP的吞吐量。在两个TCP竞争数据传输出现后，它们的吞吐量都有一个短暂性的下降，然后继续趋于上升。在8.0s的时候，两种协议的吞吐量开始趋于稳定。
对比实验一和实验二中数据吞吐量的图，我们看到，由于实验一和实验二的区别在于竞争的TCP协议出现的时间不同，在实验一的环境下，SCTP在有其他协议竞争的条件下，能够更容易、更快地达到数据吞吐的稳定状态，这样非常有利于数据的传输。
图5是实验二中链路L2在droptail队列值为10的时候的延迟对比。红色线为TCP的延迟，绿色的为SCTP的延迟。X坐标轴表示数据传输的时间变化，单位为s，Y坐标轴表示两种协议在某个时刻的延迟，单位为s。由图5中可以看出，SCTP与TCP延迟随时间的走势相互交叉，与实验一中的情形类似，SCTP的延迟略高于TCP。
图5 实验二TCP和SCTP的延迟对比
图6 TCP和SCTP竞争时的延迟和吞吐量
图6是在实验一环境下，SCTP和TCP相互竞争下的延迟和吞吐量的对比，主要是链路L2和L3的对比，红色线表示的是TCP，绿色线表示TCP。图6上图中，X坐标轴表示数据传输的时间变化，单位为s，Y坐标轴表示两种协议在某个时刻的延迟，单位为s；图6下图中，X坐标轴表示时间的变化，单位为s，Y坐标轴表示接收的数据量，单位为Byte。从图6中可以看出，情况基本与上面的实验保持一致。在相同的droptail队列值的情况下，SCTP的吞吐量远大于TCP，但是TCP和SCTP的延迟相互交叉，SCTP延迟略高于TCP。
2 TCP和SCTP的多路径的对比研究
多路径的实验拓扑图如图7所示，节点0-2合起来是一个发端，节点3-5合起来是一个收端。0是核心节点，1、2是接口，即该端点的两个IP地址；3也是核心节点，4、5也是接口，也即该端点的两个IP地址。1和4路径命名为if0；2和5路径命名为if1。
在SCTP传输过程中，数据只能从接口发或收，不能直接从核心节点发或收。该实验过程为：应用层传输FTP数据，在0.5s后开始传输；在第5s前，路径if0、if1的带宽为5M，时延为50ms；在第5s，路径if0性能恶化，带宽变成1M，时延变为200ms；在第8s，传输结束。
图7 SCTP多路径仿真拓扑图
由于TCP没有多路径这个特点，所以，要与SCTP作对比，只能重新建立拓扑图。拓扑图如图8所示：数据传输过程和SCTP一样，应用层传输FTP数据，在0.5s后开始传输；在第5s的时候链路发生恶化，带宽变成1M，时延变为200毫秒；在第8s，传输结束。
图8 相应的TCP拓扑图
对于这两种协议延迟方面的比较，我们在上一节中已经有过很详细的对比，所以在这里，主要针对两种协议在多路径的情况下，对数据吞吐量作比较，如图9所示。
图9 多路径下TCP与SCTP吞吐量的比较
如图9，其中为了表示自己搭建的TCP网络和SCTP网络有对比性，所以测试了在图8中拓扑图中SCTP数据的吞吐量，如图9中的绿线。从图中来看，在6.5s以前两种拓扑图中SCTP的数据吞吐量完全吻合，这样看来，两种拓扑图是具有可比性的。图中蓝色线表示TCP协议的吞吐量，黄色线表示if0路径上SCTP的吞吐量，红色线表示if1路径是SCTP的吞吐量。X坐标轴表示时间的变化，单位为s，Y坐标轴表示接收的数据量，单位为Byte。从图9中看，5s之前链路没有恶化，SCTP默认if0是主路径，5s之后链路if0恶化，吞吐量开始下降，此时，因为有另一条路径if1的存在，而且链路状态比if0好，SCTP开始将if1作为主路径进行传输，图中if1的吞吐量开始上升，由此可以看出，SCTP的吞吐量在经过一段时间的降低之后，会恢复原来的吞吐量，使数据传输不受影响。由图9可以看出，TCP在路径出现恶化的时候，吞吐量开始下降，如果路径得不到缓解，吞吐量会受到很大的影响。由此可以看出，SCTP多路径的特点较TCP存在很大的优势。我们再来分析路径if0数据传输与时间的关系，如图10所示。图10中有上（红色）、中（绿色）、下（蓝色）三条线。上线（红色）代表 SCTP 把数据包发送到缓存，即入队列；中线（绿色）代表数据包从缓存注入到网络，即出队列；下线（蓝色）代表数据包从收端反馈回来的证实 SACK。纵坐标代表所发送的数据包序列号，横坐标代表时间，斜率指示传输速率（下面类似图的信息也是这样的）。在第5s，带宽和时延发生变化，路径性能变差，所以第5s后的斜率小于第5s前的斜率，即第5s后的传输速率小于第5s前的传输速率。
图10 if0上数据传输与时间的关系
3 结束语
本文主要是通过NS-2构建仿真平台，对TCP和SCTP在单路径和多路径的条件下进行对比。通过两个实验对比发现，两种协议在数据传输的延迟方面，SCTP协议略高于TCP协议，相差不是很大，但是SCTP的数据吞吐量远远大于TCP协议。由于SCTP具有多路径和多重定址的特点，在应对链路恶化的情况时，SCTP表现出更高的稳定性。作为一个新的传输协议，SCTP还具有很大的发展空间，SCTP较TCP更能满足高性能传输的要求，随着IP网络的迅猛发展，SCTP一定会有更广阔的应用空间。
参考文献：
[1] Esbold Unurkhaan， Erwin P， Andreas Jungmaier. Secure SCTP-A
Versatile Secure Transport Protocol[J].Springer，2004.10（3）：273
[2] V. Jaclbson. Congestion Avoidance and Contrl[J].ACM SIGCOMN，
1988.36（2）：273
[3] K.Fall and S.Floyd.Simulation-based comparisons of Tahoe Reno
and SACK TCP[J]. ACM Computer Communication Review，1996.26（3）：5
[4] L.Brakmo and L.Peterson.TCP Vegas：End to End Congestion
Avoidance on a Gloabal Internet[J]. IEEE Journal on Selected Areas in Communication，1995.13（8）：1465
[5] 周开波，刘桐，蒋皓等.mSCTP协议异构网络切换性能评估[J].现代电
信科技，2011.3（3）：19
[6] 方路平，刘世华，陈盼等.NS-2网络模拟基础与应用[M].国防工业出
版社，2008.
[7] 胡文静.SCTP主路径自动切换的研究[D].吉林大学硕士学位论文，
2006.
[8] 叶凌伟，陈雁.SCTP与TCP的功能对比及应用分析[J].中国数据通
信，2003.1（2）：43
[9] 贺，张继棠.流控传输协议SCTP的研究[J].山西电子技术，
2005.11（5）：21
[10] 黄晓波，郑应平.流控制传输协议与TCP协议的比较[J].微型机与应
用，2005.7（6）：37
[11] 成为青.流控制传输协议概述[J].电子电气教学学报，2003.4（2）：31
tpp协议范文4
关键词：流媒体；Rtmp；负载均衡
中图分类号：TP37 文献标识码：A文章编号：1009-3044(2011)01-226-03
Streaming Video on Demand System on Rtmp and Http Protocols
WANG Xu-peng
(College of Electronics and Information Engineering, Tongji University, Shanghai 201804, China)
Abstract: Design and implement streaming video on demand system which uses 3.5 framework and Actionscript3.0. The System supports both Rtmp protocol and Http protocol transmission, detailed analyze the vod principal of two protocols, improve the Http protocol transmission. For vod, introduce a new load balancing method to distribute video Requisitions. It considers both video data transmission distance and server load performance to ensure smooth playing.
Key words: streaming media; rtmp; load balancing
网络技术和通信技术的发展，拓宽了网络带宽，同时也更加丰富了网络应用。视频点播网站，网上教学正在成为新的网络宠儿。本文正是设计和实现了基于流媒体技术的医学教学视频点播系统，系统是下一代互联网的医学教学科研平台的子项目,为各高校师生提供教学服务。
1 流媒体简介
流媒体技术主要是将声音，影像，动画等数据分成一个个压缩包，向用户提供连续的，实时的传播，而不必等到整个视频文件下载完成才能观看。通过缓存技术提供流畅的视频播放，并且大大缩短了播放延迟，改善用户体验。流媒体的传输方式主要有顺序流式传输和实时流式传输。
顺序流式传输顾名思义在连接建立后，服务器会按照数据在视频文件中存放的次序顺序发送给客户端，不会对数据做额外的处理，而且这种传输如果不加限制的话采用的是一种尽力交付的方式。由于顺序流式传输实现简单，传输协议采用Http协议即可，视频文件放在web服务器，不需要专门的流媒体服务器支持，网站和视频完全可以集成在一起。
实时流式传输要求数据传输和用户播放是同步的，视频可以实时地被观看。服务器对于数据会分成视频和音频做额外的处理，因此需要特定的流媒体服务器支持，如RealServer，Windows Media Server。本文实时流式传输协议采用Rtmp，流媒体服务器为Red5。
2 流媒体点播解决方案
2.1 流媒体点播架构
整个医学教学视频点播系统采用3.5框架开发完成，实现基于Rtmp和Http协议两种传输方式。服务器包括静态服务器Nginx，动态内容服务器IIS7.0，Rtmp服务器Red5。
Nginx是一款高性能web服务器，构建于最新的linux2.6内核之上，采用epoll模式来处理大规模的并发连接，并可以配置使用最新的NPTL线程库，传输效率不会随着连接的线性增长而下降，相比于其它服务器内存占用极小。Nginx主要用于处理静态页面和作为反向服务器，对于动态页面和视频文件的请求转发给IIS7.0处理。这样既加快了静态内容的处理速度，又保护了后台数据库的安全。
IIS7.0对于所有的请求在进入HttpRuntime时，都会经过一系列注册的Module进行过滤，最后对于特定的请求交由指定的Handle处理。系统中通过配置WebConfig文件，将基于Http协议FLV文件的请求映射给FLVHandler，该类必须实现接口IHttpHandeler。
Red5是一款开源服务器，通过对数据包进行逆向工程的研究从而实现了Rtmp协议。主要功能是处理对于流媒体视频的请求，从FLV文件中提取出视频和音频，并将其打包成消息，在同一连接上传输不同的流，并支持客户端在点播时的各种操作命令响应。
Flash播放器由ActionScript3.0编写，实现Rtmp和Http两种协议的视频请求和播放，系统提供给用户上述两种点播方案。整个播放器作为SWF文件嵌入到web浏览器中，用户只需打开网页便可观看视频，无需下载播放器。
系统通信流程图如图1。
视频文件统一为FLV格式，FLV作为目前最流行的流媒体视频格式，其形成文件小，结构简单，非常适合网络传输。FLV文件主要由一个文件头和许多Tag组成，Tag类型主要分为视频流，音频流和脚本流。由于视频信息和音频信息采用分开存放的方式，所以Tag中需要Timestap确保视频和音频同步。Tag中的数据区会指明该Tag的编码类。FLV文件格式如表1。
2.2 Rtmp协议播放原理
Rtmp协议提供了流媒体视频的高效率传输，可以构架在Tcp协议之上。客户端与服务器维持着一个单一永久的连接，支持实时交流。Rtmp主要为多媒体视频提供多路传输和数据分包服务，不仅支持视频和音频数据实时传输，还支持RPC（远程过程调用）。视频，音频，操作命令，共享对象，控制消息和其它类型数据被打包成一个个消息，并打上时间戳用于同步，不同类型的消息在不同流上传输，多个消息流又交错复用在同一个连接上。消息包括Message头和Message主体。Message头格式如表2。
Message Stream Id主要用于在单一连接中识别不同的流，包括3个字节。Meaasge Type用于指明消息的类型，只有一个字节。类型1-7保留，用于传输控制消息，比如设置chunk大小，消息丢弃，用户控制消息等等。虽然通过设置Message Type可以将不同类型的消息在不同的流上传输，但Message也有其缺点，因此又将其分割成Chunk。分块可以将低优先级数据量大的Messag分割成小的Chunk，防止其阻塞优先级高数据量小的Message。流媒体传输的多路复用基于Message这一层，与Chunk无关。
Rtmp在建立连接时首先要进行3次握手，类似于Tcp协议，不过是为了服务器和客户端统一协议版本信息。然后建立连接，创建传输流，设置chunk大小，发送数据。在视频播放过程中，如果用户拖动进度条，便会触发seek操作，该消息会通过与视频数据不同的流发送到Red5，Red5会解析控制命令，返回用户需要的数据。
2.3 Http协议播放原理
对于Http协议请求FLV视频文件，由IIS7.0响应。默认情况，如果客户端带宽良好，则下载速度远远大于播放速度。由于要保存下载的数据量比较大，所以文件会缓存到硬盘，播放器中的加载进度条显示下载到硬盘的数据。当用户拖动播放视频时,只能播放已下载的视频信息，如果将播放进度条拖动到超过加载进度条时，则播放停止。为了解决这一问题，在IIS服务器增加专门响应FLV文件的Class，即FLVHandler。
首次请求视频文件，FLVHandler会读取服务器的视频文件通过网络输出流发送到客户端，播放器接收到视频数据后会调用回调方法onMetaData，该方法主要是从FLV文件中获取MetaData，也就是视频的基本信息，包括视频长度，帧率，实际宽度和高度等，其中还包括视频的关键帧信息。FLV的MetaData存储位置紧跟在FLV Header之后，其Tag类型也就是上文介绍FLV格式中提到的脚本流，MetaData对于视频文件并不是必须的，但是在播放过程中要显示视频时间，对视频进行拖动则需要MetaData信息。
视频拖动请求，如果拖动位置在播放器加载进度条之前，即该位置的视频数据已经下载到硬盘，则播放器会从本地硬盘读取数据进行播放。如果拖动位置数据还没有下载到硬盘，首先会从MetaData中找出距离拖动位置最近的关键帧，因为视频播放时必须从关键帧开始播放，关键帧包含了当前帧的全部数据。该关键帧所处位置会附在URL之后，然后向服务器重新发送一次视频请求。FLVHandler会检查请求参数，确保当前是视频拖动请求，如果参数值不为零且没有超过文件大小，则从该帧开始读取视频文件，也就是FLV文件中某一个关键帧Tag起始位置。如果这样就把信息发送到客户端，虽然有完整的视频和音频信息，但是播放器在读取时却无法识别这是一个FLV视频文件。因此根据FLV格式规定，需要在该帧之前添加FLV Header。此时播放器接收到的网络流便是由FLV Header和视频信息重新组合的FLV文件，但信息中缺少Metadata。当播放时检测到Metadata为空，不会触发回调方法onMetaData，因此元数据不会被更改，仍然为首次播放视频得到的Metadata。至此，基于Http协议的视频拖动播放结束。
传输改进，由于在播放过程中下载和播放分离，下载速度又可能很快，例如用户在观看到5分钟时，30分钟的视频文件已经下载完毕，如果此时用户不想继续观看，则剩余下载的文件就会浪费。为了节省服务器带宽，所以FLVHander在传输视频流时，在前50M时会尽力交付，然后在传输一段视频便会执行Sleep操作，通过线程睡眠降低传输速度，维持在超过视频比特率50k-80k之间，保证正常观看。
2.4 两者对比与结合
Rtmp和Http协议都可以用于流媒体视频点播。Rtmp协议在整个播放过程中只与服务器建立一次持久性连接，客户端与服务器之间一直处于数据交互之中，视频传输和播放是同步的。Http协议在客户端请求连接后，服务器只负责发送数据，并不知道发送的数据是什么类型，也不知道当前视频播放进度。系统将两种协议结合在一起，用户可以根据自己需要选择不同的传输协议。当客户端网络带宽良好时，可以采用Rtmp协议播放，播放过程中可以随意拖动，由于只需要在连接上发送一个控制消息，所以开销少，响应速度快。当网络带宽拥塞不能满足实时播放时，可以选择Http协议，用户可以先暂停播放，让视频先下载到本地硬盘，等到下载足够的数据再进行播放。相同视频的不同协议请求会由不同服务器处理，但读取的是同一文件。两种协议在切换过程时，会记录当前播放位置的关键帧，所以在切换协议后，仍然会从该位置开始播放，无需重新观看，以达到无缝切换的目的。
客户端带宽2mb/s,视频文件200mB, 长度40分钟，分别采用Rtmp协议和Http协议播放，测试数据如表4。
3 负载均衡
3.1 负载均衡架构
整个网络架构包括主服务器，视频缓存服务器。主服务器包括整个系统的所有功能，可以响应页面和视频请求，解析动态页面，操作和维护数据库，管理所有视频的基本信息。主服务器采用1+1的冗余模式，分为Active和Standby，两者物理上为独立的服务器存在，属于同一个局域网。当Active服务器遇到故障时，Standby服务器马上变为Active模式。两者没有主次之分，可以在两种模式下相互转换，但同时只能有一个服务器为Active。视频缓存服务器只含有视频文件，功能单一，只能响应视频的点播请求。视频缓存服务器根据地理位置分散布置，所有服务器连接形成的网络尽可能地覆盖较大的地理范围，为不同地区的用户提供服务。
3.2 负载均衡策略
系统负载均衡以软件的方式实现，包含两条策略，主要目的是：首先用户点播视频时，从距离自己位置最近的网络边缘服务器获取数据防止出现网络拥塞，减少视频传输距离，从而降低网络传输消耗。其次，防止部分服务器因负载过高而不能及时响应请求，降低服务器宕机的几率。
策略一：针对不同地理位置的视频点播请求会转发到不同的视频缓存服务器，转发流程如下：
1) 用户进入视频点播网站，选择需要观看的视频，发送该视频播放页面的请求。
2) 服务器判断该请求是视频播放页面，解析请求客户端的IP地址，通过IP地址库得到该IP的地理位置，地理范围具体到省级。通过视频缓存服务器登记信息找到距离该位置最近的服务器，写入将该服务器的IP地址，返回该页面。
3) 客户端浏览器解析返回页面，调用Flash播放器插件获取页面中的服务器IP地址参数，播放器向该服务器发送视频文件请求。
4) 视频缓存服务器获取请求信息，向客户端发送视频数据。
第一条策略的不足就是负载均衡服务器在分发请求时并不知道各个服务器的状态，如果此时某一地区有大量用户在进行视频点播时，所有的请求都会由距离该地区最近的缓存服务器处理，请求量过大时则会达到带宽瓶颈。相反，某一地区如果只有很少用户视频点播，则该地区的服务器会一直处于空闲状态，浪费系统资源。因此需要第二条策略进行补充。
策略二：所有视频缓存服务器后台都运行着一个监视进程，该进程主要用来查看当前服务器处理视频请求的并发连接数，工作流程如下：
1) 监视进程每过一段时间获取当前服务器的并发连接数，当并发连接接近该服务器的带宽瓶颈时，会发送一个类型为负载过高的消息通知主服务器。
2) 主服务器收到负载过高的消息时，会修改缓存服务器的登记信息，将该服务器暂时标记为失效，并替代为与该服务器地理位置最近的服务器，且该服务器无失效标志。此时该地区用户进行视频点播时，则会都转发到替代服务器上。
3) 当监视进程发现该服务器的并发连接数降低时，会发送一个类型为负载正常的消息通知主服务器。
4) 主服务器收到负载正常的消息时，会修改缓存服务器的登记信息，取消失效标记，移除替代服务器。
负载均衡策略就是在防止网络拥塞，尽量降低网络传输消耗的基础上，均衡各个视频缓存服务器的负载，避免出现系统性能瓶颈，瓶颈就是服务器的带宽。不保证每个服务器负载平均，但保证每个服务器都正常工作。当所有服务器负载都一样时，也就是负载都已经达到饱和状态，此时只能通过硬件升级来解决。
4 结束语
本文设计了基于WEB的流媒体视频点播系统，系统同时支持Rtmp协议和Http协议传输，实现了客户端和服务器及整个网络架构。视频播放时，两种协议可以相互切换，满足不同网络状况用户的需要。提出了一种新的专门针对视频点播的负载均衡策略，既节省网络传输开销，又兼顾到视频服务器的负载状况。
参考文献：
[1] 李方捷.ActionScript 3.0开发技术大全[M].北京：清华大学出版社,2009.
[2] 齐俊杰,胡洁,麻信洛.流媒体技术入门与提高[M].2版.北京：国防工业出版社,2009.
tpp协议范文5
【关键词】 慢性阻塞性肺疾病急性加重；血浆氨基末端脑钠肽前体；机械通气；撤机
DOI：10.14163/ki.11-5547/r.2017.01.016
Guiding significance of NT-proBNP for mechanical ventilation withdrawal in AECOPD CHEN Xiao-ya， LU Min， CHEN Zhao-peng. ICU， Dongguan City Huangjiang Hospital， Dongguan 523750， China
【Abstract】 Objective To explore guiding significance of N-terminal pro-brain natriuretic peptide （NT-proBNP） for mechanical ventilation withdrawal in acute exacerabation of chronic obstructive pulmonary disease （AECOPD）， to provide basis for increasing clinical rescue success rate in AECOPD patients. Methods A total of 60 AECOPD patient performing mechanical ventilation withdrawal were divided by successful withdrawal or not into successful group （34 cases） and failure group （26 cases）. Observation and comparison were made on serum NT-proBNP level， compliance of lung and lung ventilation before offline in two groups. Results There were no statistically significant difference in oxygen partial pressure， acute physiology and chronic health evaluationⅡ（APACHEⅡ） before offline in two groups （t=0.942， 0.080， P>0.05）. The successful group had lower oxygen partial pressure than the failure group， and shorter mechanical ventilation time than the failure group. Their differences had statistical significance （t=4.971， 5.955， P
【Key words】 Acute exacerabation of chronic obstructive pulmonary disease； N-terminal pro-brain natriuretic peptide； Mechanical ventilation； Withdrawal
随着全球气候的改变， 目前呼吸道疾病已成为住院和门诊发病率较高的疾病之一， 对于呼吸系统疾病的治疗， 如慢性阻塞性肺疾病、呼吸衰竭等， 均采用机械通气进行治疗， 而研究证明时撤机失败的一个被重视的原因， 患者常因撤机的时间不对， 导致治疗的失败[1]。血浆NT-proBNP是常使用的用于反映心功能的重要血液指标， 且多数临床医师在思考是否可以将NT-proBNP 作为撤机结局的预测指标值得思考[2-4]。本组研究旨在进一步探讨NT-proBNP对AECOPD撤机的指导意义， 现将结果报告如下。
1 资料与方法
1. 1 一般资料 选取本院重症加强护理病房（ICU） 2013年10月～2016年12月诊断为AECOPD并行有创机械通气的60例患者进行研究， 所有患者均符合AECOPD的诊断标准， 按照患者机械通气后撤机的成功与否分为成功组（34例）和失败组（26例）。其中， 成功组男19例， 女15例， 年龄48～75岁， 平均年龄（59.6±6.1）岁；失败组男14例， 女12例， 年龄49～77岁， 平均年龄（60.1±6.0）岁。两组患者性别， 年龄比较， 差异无统计学意义（P>0.05）， 具有可比性。 排除急性心肌梗死、左心衰竭等心功能不全疾病。
1. 2 方法 对本院ICU 60例诊断AECOPD并行有创机械通气患者的临床资料进行回顾性分析， 主要包括年龄、性别、APACHEⅡ评分、机械通气时间、血浆NT-proBNP以及肺顺应性， 撤机前的氧分压及二氧化碳分压的情况， 观察分析NT-proBNP对AECOPD机械通气撤机的指导效果。
1. 3 统计学方法 采用SPSS19.0统计学软件进行统计分析。计量资料以均数±标准差（ x-±s）表示， 采用t检验；计数资料采用χ2检验。P
2 结果
2. 1 两组患者脱机前氧分压、脱机前二氧化碳分压、机械通气时间、APACHEⅡ评分比较 两组患者脱机前氧分压、APACHEⅡ评分比较， 差异均无统计学意义（t=0.942、0.080， P>0.05）；成功组脱机前二氧化碳分压低于失败组， 机械通气时间短于失败组， 差异具有统计学意义 （t=4.971、5.955， P
2. 2 两组患者血浆NT-proBNP和肺顺应性比较 成功组患者血浆NT-proBNP为（1429.32±201.37）pg/ml， 显著高于失败组的（890.21±106.37）pg/ml， 肺顺应性为（63.09±8.71） ml/cm H2O，
显著优于对照组的（51.62±7.41）ml/cm H2O， 差异均具有统计学意义 （P
3 讨论
机械通气是目前治疗呼吸系统疾病最为常见也是富有成效的一个治疗方法。但目前的研究显示， 能否成功撤机是目前治疗成败的关键所在。且已有多项研究对影响机械性通气撤机的影响因素进行分析， 结果发现， 血清白蛋白、APACHEⅡ评分、NT-proBNP、血乳酸、谷草转氨酶（AST）、血肌酐、机械通气时间、肺部感染控制情况和咳嗽排痰能力等相关指标对撤机过程有不同程度影响， 对这些单因素进行多因素Logistic 回归分析结果提示， APACHEⅡ评分、NT-proBNP、咳嗽排痰能力和机械通气时间是撤机困难AECOPD 患者的独立危险因素[5-9]。
本组研究旨在探讨NT-proBNP对AECOPD机械通气撤机的指导意义， 为临床提高AECOPD 患者的抢救成功率提供依据。且对本院ICU 2013年10月～2016年12月\断AECOPD并行有创机械通气的60例患者的临床资料进行回顾性分析， 结果发现， 两组患者脱机前氧分压、APACHEⅡ评分比较， 差异均无统计学意义（t=0.942、0.080， P>0.05）；成功组脱机前二氧化碳分压低于失败组， 机械通气时间短于失败组， 差异具有统计学意义（t=4.971、5.955， P
血浆NT-proBNP是血浆B型利钠肽（BNP）经丝氨酸蛋白酶内切作用形成的一种无生物活性片段。NT-proBNP 水平可在多种不同生理和病理状态下显著升高， 如心室负荷增加、肺栓塞、继发性肺动脉高压、慢性阻塞性肺疾病并右心高负荷等[10-12]。且研究表明[13-15]， NT-proBNP与年龄、心功能分级呈明显的正相关性， 与左室射血分数和患者预后呈明显的负相关性。
本组研究结果显示， 成功组患者血浆NT-proBNP为（1429.32±201.37）pg/ml， 显著高于失败组的（890.21±106.37）pg/ml，
肺顺应性为（63.09±8.71） ml/cm H2O， 显著优于对照组的（51.62± 7.41）ml/cm H2O， 差异均具有统计学意义 （P
综上所述， 血浆NT-proBNP对AECOPD机械通气撤机的指导意义， 临床医师可根据患者血浆NT-proBNP的水平对患者进行适时的撤机， 以提高撤机成功率。
参考文献
[1] Doorduin J， van der Hoeven JG， Heunks LM.The differential diagnosis for failure to wean from mechanical ventilation.Curr Opin Anaesthesiol， 2016 ， 29（2）：150-157.
[2] 任世友， 李娜， 王茂筠， 等. 呼吸机撤机失败的原因分析及探讨. 临床肺科杂志， 2010， 15（6）：775-777.
[3] Hetland B， Lindquist R， Chlan LL.The influence of music during mechanical ventilation and weaning from mechanical ventilation： A review.Heart Lung， 2015 ， 44（5）：416-425.
[4] 刘怡. 血浆NT-proBNP联合肺顺应性对AECOPD患者脱机拔管预后的评估. 江西医药， 2016， 51（10）：1076-1078.
[5] 王碧炯， 方强. 血浆 NT-proBNP 对老年肺心病合并呼吸困难患者脱机拔管预后的预测价值. 中国急救医学， 2011， 31（4）：303-306.
[6] 张洁， 洪舟， 李荣， 等. NT-proBNP 在慢性充血性心力衰竭中的表达及与 NYHA 分级和 LVEF 的关系. 现代生物医学进展， 2015， 15（20）：3905-3907.
[7] 李智伯， 高心晶， 王东浩， 等. 呼吸综合指数预测慢性阻塞性肺疾病急性加重机械通气患者脱机结果的多中心研究. 中华危重病急救医学， 2013， 25（6）：339-342.
[8] 叶敏球， 黄跃清， 黄丹菊. 呼吸综合指数对慢性阻塞性肺疾病急性加重机械通气患者脱机结果的预测价值. 当代医学， 2014， 20（35）：100-101.
[9] 吴文杰. N端脑钠素前体联合SBT试验对机械通气撤机结局的预测意义. 首都医科大学， 2013.
[10] 封凯旋， 马斌， 黄晓丽， 等. 血浆NT-proBNP检测在AECOPD合并Ⅱ型呼吸衰竭患者治疗中的临床价值研究. 医学研究杂志， 2015， 44（4）：79-81.
[11] 石志红， 杨岚， 尚立群， 等. 自主呼吸试验指导慢性阻塞性肺疾病急性加重期有创机械通气撤离价值的初步评价. 武汉大学学报（医学版）， 2011， 32（3）：362-364.
[12] 袁宝生， 苏春燕， 张宏伟， 等. AECOPD患者机械通气撤机策略研究. 临床肺科杂志， 2009， 14（1）：97-98.
[13] 震， 贾士强， 彭占仙， 等. 睡眠状态下的浅快呼吸指数预测慢性阻塞性肺疾病急性加重期患者撤机的研究. 临床荟萃， 2015（5）：506-509.
tpp协议范文6
TCP/IP协议是网络中使用的基本通信协议。虽然从名字上看它包括两个协议：TCP协议和IP协议，但确切的说，TCP/IP实际上是一组协议，除了最常用的TCP和IP协议外，还包含许多其它的工具性协议、管理协议及应用协议。TCP/IP协议共分为4层，即：应用层、传输层、互连网络层、网络接入层。其中，应用层向用户提供访问Internet的一些高层协议，使用最广泛的有TELNET、FTP、SMTP、DNS等。传输层提供应用程序端到端的通信服务，该层有两个协议：TCP和UDP。互连网络层负责相邻主机之间的通信，该层协议主要有IP和ICMP等。网络接口层是TCP/IP协议软件的最低一层，主要负责数据帧的发送和接收。
典型协议安全性分析与防范
TCP协议
协议工作过程
TCP是基于连接的。为了在主机A和B之间传送TCP数据，必须先通过3次握手机制建立一条TCP连接。若A为连接方、B为响应方，则连接建立过程如下：首先，连接方A发送一个包含SYN标志的TCP报文(即同步报文)给B，SYN报文会指明连接方A使用的端口以及TCP连接的初始序号X； 随后，响应方B在收到连接方A的SYN报文后， 返回一个SYN+ACK的报文(其中SYN是自己的初始序号Y，ACK为确认号X+1，表示客户端的请求被接受，正在等待下一个报文)。最后，连接方A也返回一个确认报文ACK(序列号y+1)给响应方B。到此一个TCP连接完成。
TCP协议的安全问题
在连接过程中，可能受到的威胁如下：攻击者监听B方发出的SYN＋ACK报文，然后向B方发送RST包。接着发送SYN包，假冒A方发起新的连接。B方响应新连接，并发送连接响应报文SYN＋ACK。攻击者再假冒A方对B方发送ACK包。这样攻击者便达到了破坏连接的作用。若攻击者再趁机插入有害数据包，则后果更严重。
例如，在TCP的3次握手中，假设1个用户向服务器发送了SYN报文后突然死机或掉线，那么服务器在发出SYN+ACK应答报文后是无法收到客户端的ACK报文的(即第3次握手无法完成)，这种情况下服务器端一般会再次发送SYN+ACK给客户端，并等待一段时间后丢弃这个未完成的连接，这段时间的长度我们称为SYN Timeout，一般来说这个时间是分钟的数量级(大约为30秒-2分钟)；1个用户出现异常导致服务器的一个线程等待1分钟并不是什么大问题，但如果有一个恶意的攻击者大量模拟这种情况，服务器端将为了维护一个非常大的半连接列表而消耗非常多的资源。服务器端将忙于处理攻击者伪造的TCP连接请求而无暇理睬客户的正常请求，此时从正常客户的角度看来，服务器失去响应，这种情况我们称作服务器端受到了SYN Flood攻击。
防范方法
对于SYN Flood攻击，目前还没有完全有效的方法，但可以从以下几个方面加以防范：
(1)对系统设定相应的内核参数，使得系统强制对超时的SYN请求连接数据包复位，同时通过缩短超时常数和加长等候队列使得系统能迅速处理无效的SYN请求数据包；
(2)建议在该网段的路由器上做些配置的调整，这些调整包括限制SYN半开数据包的流量和个数；
(3)建议在路由器的前端做必要的TCP拦截，使得只有完成TCP三次握手过程的数据包才可进入该网段，这样可以有效的保护本网段内的服务器不受此类攻击。
IP协议
IP协议的安全问题
IP协议在互连网络之间提供无连接的数据包传输。IP协议根据IP头中的目的地址项来发送IP数据包。也就是说，IP路由IP包时，对IP头中提供的源地址不作任何检查，并且认为IP头中的源地址即为发送该包的机器的IP地址。这样，许多依靠IP源地址做确认的服务将产生问题并且会被非法入侵。其中最重要的就是利用IP欺骗引起的各种攻击。
以防火墙为例，一些网络的防火墙只允许网络信任的IP数据包通过。但是由于IP地址不检测IP数据包中的IP源地址是否为放送该包的源主机的真实地址，攻击者可以采用IP源地址欺骗的方法来绕过这种防火墙。另外有一些以IP地址作为安全权限分配依据的网络应用，攻击者很容易使用IP源地址欺骗的方法获得特权，从而给被攻击者造成严重的损失。事实上，每一个攻击者都可以利用IP不检验IP头源地址的特点，自己填入伪造的IP地址来进行攻击，使自己不被发现。
防范方法
基于IP欺骗的防范方法有：
(1)抛弃基于地址的信任策略。这是最简单的方法。
(2)进行包过滤。如果网络是通过路由器接入Internet的，那么可以利用路由器来进行包过滤。确认只有内部LAN可以使用信任关系，而内部LAN上的主机对于LAN以外的主机要慎重处理。路由器可以过滤掉所有来自于外部而希望与内部建立连接的请求。
(3)使用加密技术。阻止IP欺骗的一种简单的方法是在通信时要求加密传输和验证。当有多种手段并存时，加密方法可能最为适用。
ICMP协议
ICMP协议的安全问题
ICMP即Internet控制消息协议。用于在IP主机、路由器之间传递控制消息。控制消息是指网络通不通、主机是否可达、路由是否可用等网络本身的消息。Ping就是最常用的基于ICMP的服务。ICMP协议本身的特点决定了它非常容易被用于攻击网络上的路由器和主机。比如，可以利用操作系统规定的ICMP数据包最大尺寸不超过64KB这一规定，向主机发起“Ping of Death”(死亡之Ping)攻击。“Ping of Death” 攻击的原理是：如果ICMP数据包的尺寸超过64KB上限时，主机就会出现内存分配错误，导致TCP/IP堆栈崩溃，致使主机死机。此外，向目标主机长时间、连续、大量地发送ICMP数据包，使得目标主机耗费大量的CPU资源处理，也会最终使系统瘫痪。
防范方法
对于“Ping of Death”攻击，可以采取两种方法进行防范：
(1)路由器上对ICMP数据包进行带宽限制，将ICMP占用的带宽控制在一定的范围内。这样即使有ICMP攻击，它所占用的带宽也是非常有限的，对整个网络的影响非常少；
