前言：中文期刊网精心挑选了tcp协议范文供你参考和学习，希望我们的参考范文能激发你的文章创作灵感，欢迎阅读。
tcp协议范文1
关键词： 流控制传输协议； 传输控制协议； 单路径； 多路径； 吞吐率； 延迟
中图分类号：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
tcp协议范文2
【关键词】TCP 协议；有色Petri网；形式化描述；可达树
随着数据通信和网络的发展，现在TCP/IP（Transfer Control Protocol/Internet Protocol）协议簇成为占主导地位的网络体系结构，被广泛的使用。有色Petri网（Colored Petri Net，CPN）是由丹麦的Jensen Kurt于1981年在Petri网基础上定义的一种具有层次性的高级Petri网。利用在计算机上开发的CPN的建模分析工具──CPN Tools，可以建立描述系统的CPN静态模型，并对系统模型的动态行为进行仿真，分析系统的分布、并发、同步、异步等特性，以及建立系统模型的状态空间并分析系统的活性问题、可达性问题等。由于CPN具有严格的网理论形式化的数学描述、上述的特性以及建模工具提供的仿真分析功能，因此在网络通信协议的验证和分析上得到了广泛的应用。
一、TCP协议连接的建立过程
TCP是一个可靠的，面向连接的，端到端的传输协议，它提供了具有流量控制的可靠的数据传输。TCP的连接建立称为“三次握手”。（1）客户发送第一个报文段，SYN报文段，在这个报文段中只有SYN标志置1，这个报文段的作用是使序号同步。客户端选择一个随机数作为第一序号，并把这个序号发给服务器。注意SYN报文段是一控制报文段，不携带任何数据但它消耗一个序列号。（2）服务器发送第二个报文段，即SYN+ACK报文段，其中有两个标志置为1这个报文段有两个目的，一个是使用SYN同步初始序号，另一个是服务器使用ACK标志确认已经从客户端收到的SYN报文段，同时给出期望从客户端收到的下一个序号。服务器还必须定义客户端要使用的接收窗口（rwnd），这就实现了TCP的流量控制。（3）客户端发送第三个报文段。这仅仅是一个ACK报文段。它使用ACK标志和确认号字段来确认收到了第二个报文。注意这个报文段的序号和SYN的报文段使用的序号一样，这个ACK报文段不消耗任何序号。客户还必须定义服务窗口值。在某些情况下第三个报文段可以携带客户端的第一个数据块，在这种情况下第三个报文段必须有一个新的序号来表示数据源的第一个自己的编号。一般的来说，第三个报文段不携带数据的，因而不消耗序号。
二、CPN模型
在利用CPN Tool建立具体模型之前，先对模型中各库所和变迁，以及颜色类型，变量做一说明。当P1，P2，P4，P7中有标识的时候，即发送端主动打开准备发送连接请求和接受端被动打开监听，发送第一个请求报文，其序号用变量n1绑定，在接收端收到这个请求信息的时候把n1加1作为服务器想从客户端得到下一报文段的序号，同时和自己的初始序号一起组成确认报文段序列，用（n3，n2）来绑定。当客户端接到这个报文的时候进行检查，如果n3=n1+1，说明得到服务器确认报文安全，发送客户确认报文，用（n3，n4）绑定，同时把n1作为数据传输的初始序号。如果n3不等于n1+1，客户端重新发送连接请求。在服务器端收到客户端确认报文的时进行检查，如果n4=n2+1，把n2作为接收数据的初始编号，等待接收数据，否则继续监听。在初始标识下最后到的P8和P11中有标记，说明连接建立成功。
三、模型验证与分析
Petri网的模型验证方法有两种：可达树（Reachability Tree）方法和线性代数（Matrix Equations）方法。在初始标识下通过工具CPN Tool我们可以得到连接的CPN模型的可达树。（1）可达树各结点中库所包含的标记不超过两个，且当库所包含两个标识时标记颜色各不相同，因此TCP协议连接建立的有色Petri网模型是安全的，有界的。（2）可达树中各变迁至少引发一次，没有从不引发的变迁。树中每个标号有后继标号，即每个标号都是可以引发的。对于可达集R（M0），每一标号都有一条从根到的变迁路径，即。根据活性的定义，可知该模型是活的，不会有死锁发生。（3）可达树中不存在无用的循环，其中两个循环是处理发送端和接收端所接受的报文序号是否匹配。（4）可达树中可达状态M3经变迁T3可回到初始状态，所以该CPN模型是可逆的。保证了协议周期的实现，即能够重复执行请求连接的功能。
本文利用有色Petri网的建模的方法和工具CPN Tool，建立了TCP协议的连接建立过程的有色Petri网模型，得到模型的了可达树，通过可达树的方法，验证了所建模型的有界性、安全性、活性、可逆性等性质。从而证明了所构造的形式化模型的正确性，同时也验证了协议的逻辑正确性。
参 考 文 献
[1]周必水，郦泓．有色Petri网在通信协议中的应用[J]．系统仿真学报．2003，15（8）：112～114
tcp协议范文3
【关键词】图层，帧
计算机辅助教学（Computer Assisted Instruction 简称CAI）指的是应用计算机作为教学的辅助手段，通过学习者与计算机交互作用完成教学过程。CAI构成了一种个别化学习环境，让学习者利用计算机的特点和优势，通过与计算机的交互，完成某一具体课程的学习。作为一种教学媒体，计算机可以起到与其它传播媒体一样的呈现知识、给予反馈等作用，但是由于其有着存贮、处理信息、工作自动化等功能，因此计算机辅助教学（CAI）具有如下特点：
（1）大容量的非顺序式信息呈现。计算机可存贮相当丰富的信息量，可包括一门课程或与某个对象有关的全部知识。学习者既可以浏览所有知识，也可以按需要获取其中任意所感兴趣的一部分，而不仅是按顺序阅读，或是按教师所给出的那一部分。
（2）学生可以控制学习内容和学习进度。通常的CAI系统都允许学生选择学习内容，也设置一些同步措施，仅当学生学习了前一部分知识后才进入下一步的学习。这样，学生的学习进展不受时间与地点的限制，可以取得最佳的学习速度。
（3）实现因人施教的教学原则和及时反馈原则。CAI系统可通过提问、判断、转移等交互活动，分析学生的能力和学习状况，调节学习过程，实现因人施教的教学原则和及时反馈原则。
（4）学生在CAI活动中处于一种积极、主动的精神状态。因为教学进度由学生控制和连续的提问-反馈或是操作一反应刺激等交互活动，学生在CAI活动中处于一种积极、主动的精神状态，不象被动受教时那么容易疲劳和受干扰，从而可以取得较好的教学效果。
（5）网络技术使CAI可获得群体的支持。目前的网络技术使CAI可获得群体的支持，解决个别化学习与群体学习的矛盾。
CAI活动的效果受教师态度的影响。实验证明，CAI活动的效果受教师态度的影响，积极推广CAI的教师所用CAI的教学效果好，反之亦然。
在过去的几年里，CAI的发展速度是超出人们想象的。就全国来言，大量的学校、部门、公司、企业，以各自不同的目的，带着极大的热情投入到CAI的开拓当中，并以各自不同的优势推动着CAI向前迅猛地发展，目前，已经形成了以下几个发展趋势：
1.多媒体技术的采用使CAI手段更加丰富。多媒体教学系统是一种以计算机为中心，处理、控制各种教学媒体综合进行教学活动的系统，它既具有各种教学媒体的特点和优势，又发挥了以计算机为核心的控制作用，因此他具有多重感观刺激，传输信息量大，易于接受，人机交互性强，操作简单等特点。它既是CAI发展方向，也是现代教育发展的方向，所以引起了各方人士高度的重视。
2.计算机生产技术的进步，存贮成本的降低， 使大量的存贮信息成为可能。目前，一方面硬盘的价格大幅度的降低，另一方面CD-ROM光盘的大量使用，使得存贮容量不再是问题。图形、动画、音像等各种素材得以大量存储和自由调用。这也为多媒体教学系统打下了良好的物质基础。
3.网络技术在教学领域的采用，使教学的观念发生了质的变化
4.平台软件为CAI软件制作提供了方便的开发工具。目前CAI领域中的一项重大事件是工具平台的使用。由于计算机技术的迅速发展，其功能不断加强，操作却越来越简便和易于掌握。这不但使非计算机专业人员编制CAI软件成为现实，而且使CAI软件实现了多媒体技术。
5.微机操作的窗口化。新一代的操作系统（平台）已经朝着直观、易懂的窗口化方向发展，以图标管理代替文件管理，以图标形状代替操作信息，以鼠标指点代替键盘操作方法。这为进一步普及微机应用提供了基础。
传输控制协议（Transmission Control Protocol TCP）是一种面向连接的、可靠的、基于字节流的运输层通信协议，通常由IETF的RFC 793说明。在简化的计算机网络OSI模型中，它完成运输层所指定的功能。在因特网协议族中，TCP层是位于IP层之上，应用层之下的中间层。不同主机的应用层之间经常需要可靠的、像管道一样的连接，但是IP层不提供这样的流机制，而是提供不可靠的包交换。
TCP原理的特点和功能如下：
（1）面向连接的服务。对保证数据流传输可靠性十分重要。
（2）高可靠性：方法：确认与超时重传。
（3）全双工通信
（4）支持流传输：流传输 无报文丢失、重复、乱序的正确数据报文序列；
（5）传输连接的可靠建立与释放：3次握手
（6）提供流量控制与拥塞控制
TCP协议的功能
（1）保证传输的可靠性。TCP协议是面向连接的。所谓连接，是指在进行通信之前，通信双方必须建立连接才能进行通信，而在通信结束后终止其连接。相对于面向无连接的IP协议而言，TCP协议具有高度的可靠性。当目的主机接收到由源主机发来的IP包后，目的主机将向源主机回送一个确认消息，这是依靠目的主机的TCP协议来完成的。
TCP协议中有一个重传记时器（RTO），当源主机发送IP包即开始记时需要说明的是，TCP协议所建立的连接是端到端的连接，即源主机与目的主机间的连接。internet中每个转接节点（路由器）对TCP协议段透明传输。
总之，IP协议不提供差错报告和差错纠正机制，而TCP协议向应用层提供了面向连接的服务，以确保网络上所传送的数据包被完整、正确、可靠地接收。一旦数据有损伤或丢失，则由TCP协议负责重传，应用层不参与解决。
（2）提供部分应用层信息的功能。在TCP协议之上是应用层协议（如FTP、SMTP、TELNET等），最终需依靠它们实现主机间的通信。TCP协议携带了部分应用层信息，可用来区别同一报文数据流的一组IP包及其性质。
TCP协议对这些应用层协议规定了整数标志符，称为端口序号。被规定的端口序号成为保留端口，其值在0～1 023范围内（如端口序号23，用于远程终端服务）。此外还有自由端口序号，供个人程序使用，或者用来区分两台主机间相同应用层协议的多个通信，即两台主机间复用多个用户会话连接。
进行通信的每台主机的每个用户会话连接都有一个插口序号，它由主机的IP地址和端口序号组成。在internet中插口序号是惟一的，一对插口序号惟一地标识了一个端口的连接（发端插口序号=源主机IP地址+源端口序号，收端插口序号=目的主机IP地址+目的端口序号）。利用插口序号可在目的主机中区分不同源主机对同一个目的主机相同端口序号的多个用户会话连接。
在TCP协议段的头部各域中具有码位项。其中，SYN码位为应用数据流的开始位（当SYN置1，表示该IP数据包为某一应用报文的第一份数据包），FIN码位为应用数据流的结束位（当FIN置1时，表示此时数据包为某应用报文的最后一份数据包）。因此可利用SYN/FIN两个码位来规定某一应用报文（或某一应用数据流）的开始与结束。
TCP协议就是利用端口序号和SYN/FIN码位来区分应用数据流并判断其性质的，从而使具有四层功能的高端路由器具有某些对应用数据流的控制功能。
TCP协议只定义了一种报文格式，建立、拆除连接、传输数据使用同样的报文
1.传输连接的建立
TCP是面向连接的协议，运输连接的建立和释放是每一次面向连接的通信中必不可少的过程
运输连接的管理就是使运输连接的建立和释放都能正常地进行。
在连接建立过程中要解决以下三个问题：（1）要使每一方能够确知对方的存在；（2）要允许双方协商一些参数（如，最大报文段长度，最大窗口大小，服务质量等）；（3）能够对运输实体资源（如缓冲区大小，连接表中的项目等）进行分配
2.TCP的传输连接管理――三次握手技术。（1）TCP连接的建立采用客户/服务器方式。（2）为了确保连接的建立和释放都是可靠的，TCP使用三次握手的方式，其中交换了三个报文。（3）已证明三次握手是在分组丢失、重复和延迟的情况下确保非模糊协定的充要条件。
3.为何使用三次握手
当客户端发送一连接请求报文段，没有收到服务器端的确认，认为丢失。客户端再重传一次，得到确认，传输数据，释放连接。
然而，客户端第一个请求报文段并没有丢失，而是延时到这次连接、数据传输、释放连接后才到达服务器端。服务器端认为又一次新的连接，向客户端发一确认。客户端由于并没有发起新的连接，不会发送数据，服务器端会一直等待，造成资源浪费。
3. TCP的流量控制。
（1）TCP采用可变发送窗口的技术进行流量控制，窗口大小的单位是字节。
（2）在TCP报文段首部的窗口字段写入的数值就是当前设定的接收窗口数值。
（3）发送窗口在连接建立时由双方商定，在通信过程中，接收端可根据自己的资源情况，随时动态地调整自己的接收窗口，并且告诉对方，使对方的发送窗口和自己的接收窗口一致。
说明：（1）发送端要发送的数据共9个报文段，每个报文符长100字节，共900个字节；（2）而接收端允许的发送窗口为500字节；（3）在当前情况下，发送方可连续发送5个报文段，而不必收到确认，（已发送了二个，还可发送三个报文符）；
4. TCP差错控制
差错控制包括检测受到损伤的报文段、丢失的报文段、失序的报文段和重复的报文段，以及检测出错后纠正差错的机制。差错检测三种工具：检验和、确认和超时。对各种出错报文段的处理：传输出错报文段（重传计时器）；丢失报文段（重传计时器）；重复报文段（报文序号）；乱序报文段（对乱序报文段不确认，直到收到所有它以前的报文段为止。）；确认丢失（累计确认）
本文主要是从计算机辅助教学入手，从TCP原理演示来具体生动地介绍CAI的特点.全文全面地介绍了TCP协议，又通过动画具体演示了TCP的连接和释放过程，能够生动地帮助学生理解TCP协议。从而具体体现了计算机辅助教学的优点。
计算机辅助教学与传统的教学方式相比较确实具有很多的优势。传统的教学以课堂集体教学为基础，这种教学通常以教师为中心，学生往往处于被动地位，其学习积极性难以调动。教师参照全班学生的平均水平和教学计划确定教学进度并向学生提供反馈信息，忽视、较少注意或难于注意学生的个别差异。对于家庭作业，尽管教师能逐个学生加以批阅，但反馈信息不够及时，有时学生几天后才能得到教师批改过的作业，而这时学生又去顾及新的知识。然而计算机辅助教学相对于教师的传统教学也有其固有的不足之处，比如真实性问题，虽然呈现给学生的信息可以是丰富多采的，但这些都是间接经验，是别人做好让学生看和听的，甚至有的信息的真实性会受到怀疑。还有其它的不足之处，这需要从事教育工作者的合理运用。
参考文献：
[1]吴功宜，《计算机网络》，清华大学出版社
[2]谢希仁，《计算机网络》，电子工业出版社
[3]肖秀金、陈霄峰，《网页设计培训教程》，地质出版社
[4]BehrouzA.Forouzan，Sophia Chung Fegan ，《TCP/IP协议族》，清华大学出版社
tcp协议范文4
关键词：嵌入式系统；以太网；TCP/IP协议；UDP；ARP
中图分类号：TP393文献标识码：A文章编号：1009-3044(2007)04-10947-03
1 引言
目前，嵌入式系统与网络的结合已经成为嵌入式系统发展过程中所必须要面对的问题之一。嵌入式系统的网络接入一般可以通过RS-232或RS-485等间接接入，也可以通过网络协议直接与网络相互连，其中，直接接入方式正逐步成为嵌入式系统接入网络的主要方式，但是需要精简TCP/IP协议栈的支持。目前使用广泛的通用TCP/IP协议栈所包含的协议内容比较全，但同时也比较复杂。由于硬件平台的差别，这些协议站无法直接应用于嵌入式系统，主要表现在以下三个方面：
(1)嵌入式操作系统都面向特定的领域和需求，嵌入式应用对实时性要求比较高。
(2)多任务操作系统的内存分配是动态的，但是在嵌入式系统中片RAM是静态分配的，用于存放收到的数据包的的空间很有限。
(3)嵌入式系统在程序的具体实现上与通用计算机系统有所不同，主要体现在指针、参数传递、变量和数据结构的定义等方面。
因此，需要通用TCP/IP协议栈的基础上进行精简和改写，以设计出精简、高效的TCP/IP协议子集，以供嵌入式系统接入网络使用。
2 TCP协议分析与简化
通用计算机系统有足够的资源支持，但是嵌入式系统则不同，因为其CPU处理能力和系统存储能力都受到成本限制，充分利用资源、提高系统性价比是开发嵌入式应用的根本特点。
2.1 嵌入式TCP/IP协议栈的特点
嵌入式系统一般都是为了满足某一特定的需求，对网络支持的要求相对比较低，需要什么协议就添加相应的模块，不需使用完整的TCP/IP协议。嵌入式TCP/IP协议栈应具有以下的特点：
(1)代码比较简洁，占用的存储空间尽可能小，尽可能为应用程序节省系统资源。
(2)需要传输的数据量一般比较少，协议的实现代码要有较高的执行效率，具有较高的实时性。
(3)便于裁剪和扩展，对于面向不同应用的嵌入式系统应当根据特点对协议进行简化或扩展，整个协议栈在满足功能需求的前提下尽可能精简。
TCP/IP协议栈具有层次特性，各个协议都有自己的数据格式，每次发送数据都要进行上下层协议的数据交换，进行打包和拆包的过程，在这个过程中如果采用数据拷贝的策略进行数据传递则会大大增加系统开销。在嵌入式系统中，往往无法建立起数据传递的缓冲区，需要采用“零拷贝”技术用传递数据指针的方法来解决各层协议间的数据传递，以提高系统的实时性能。
2.2 TCP/IP协议的精简
TCP/IP是几百种网络协议的集合。通用计算机系统有足够的资源支持通信协议在内核实现，因此完整的TCP/IP协议栈（如图1）能够在数据传输的可靠性和数据流量的控制上做很多工作。
但是对于嵌入式系统来说，其硬件资源十分有限，同时对协议的要求也相对较低，必须对通用的TCP/IP协议进行精简。进行精简的途径有两种：
(1)将无关于系统功能的协议削减掉。即保留必需的协议，而对其它无关协议进行裁剪。
(2)对单独的协议进行简化。例如完整的ARP协议支持以太网、令牌环等网络，但是嵌入式系统可能是面向于某一具体类型网络的，对于其他的部分就可以简化掉。
图1
简化后的协议仍然需要符合规定的标准：在网络接口层，系统需实现ARP应答协议，该协议用于将IP地址映射成以太网MAC地址；在网际层，需要实现IP协议，主要负责IP报文报头的正确性，并且对TCP和ICMP报文实行分流，此外，为了能够测试系统与网络的连接，在网际层还需要实现ICMP协议中的Ping应答协议，主要用于检查网络在传输层是否连通。作为运输层的主要协议，TCP和UDP协议一般都不能缺少，对于具体的应用，一般都至少要实现其中之一。HTTP、FTP等应用层协议一般无需实现。这样简化后，就可以得到图2所示的嵌入式TCP/IP协议栈的结构：
图2 嵌入式TCP/IP协议栈结构
3 各协议的具体实现
本文实现的嵌入式TCP/IP协议运行于以89C51单片机和RTL8019AS网络控制器为核心元件的硬件平台上，协议代码在Keil C51 V7.0环境下编写。在程序的initial文件中提供了相关函数对89C51和RTL8019AS进行了初始参数设置，限于文章篇幅，与具体硬件相关的问题不再作详细说明。
3.1 ARP协议的实现
ARP协议不携带用户的有效数据，报头长度为28字节。在ARP报头中操作码域表明了ARP包是ARP请求还是ARP回答，其值为1时为请求，为2时为应答。目标以太地址为目标节点IP对应的MAC地址，解析前是未知的。发送ARP请求应使用广播方式，网段内的各个主机收到后检查包内的IP地址，如果和本机的IP地址一样则使用单播的方式返回ARP应答，在应答ARP包中源以太地址的域中填入自己的MAC地址。在具体设计时，要考虑到系统解析地址的实时性，如果每次互联都要进行地址解析，则系统的实时性要下降，一般的做法是建立一个ARP地址映射表，存放常用IP地址与MAC地址的映射，这样在解析地址时首先遍历该表，如果目标地址已经被解析过则可以省去解析过程了。解析过程中还需要为ARP缓存中每个新生成条目赋予一个初始生存时间，使用定时器中断，经过某一时间间隔对所有条目进行刷新检测，若发现有条目发生超时，将其从ARP缓存中删除。ARP缓存条目结构设计如下：
typedef struct
{unsigned long ip_addr; //IP地址
unsigned char macaddr[6]; //MAC地址
unsigned char timer; //定时器}
ARP_CACHE; //ARP缓存条目结构
3.2 IP协议及Ping 应答的实现
IP协议是TCP/IP协议族中最为核心的协议。所有的TCP、UDP、ICMP及IGMP包都以IP数据报格式传输。IP报头的标准长度为20字节。在具体项目中由于数据量比较小，可以不考虑数据报分段的问题，即不允许数据报超出IP包的有效载荷。标准以太网帧数据域为1500字节，除去IP头之外还有1480字节可以为上层协议提供有效的数据载荷，应该能够满足数据传送的要求。这样简化可以省去软件处理IP数据分段和重组的开销，可以提高系统数据传输的实时性。IP协议对上一层传下来的报文加上IP首部和IP校验和并发往下一层，同时还要对下一层传上来的报文进行校验和检查，将校验正确的去掉IP首部，送往上一层。
为了便于测试，需要实现PING程序，在收到ICMP的回显请求包后按照格式组装一个ICMP的回显应答包并发送。相关的主要函数有：
void ping_request() //PING请求
void ping_answer() //PING应答
void ping_echo() //PING应答收到后回显
3.3 UDP协议的实现
UDP际上是直接利用IP协议进行数据报的传输，也就是将报文包含在IP数据包中 。UDP的数据传输是无连接，不可靠的，因为它不像TCP那样，为了达到目标，首先要在两点之间建立一个可靠的连接，因此UDP协议无法保证数据可靠性。但UDP协议具有对网络资源开销较小，数据处理速度快的优点，UDP协议属于简单的端到端的数据传输协议，其报头只有8字节，其中源端口表示UDP应用进程的端口号，除了0～1023预定的端口外，其余的都可以使用。具体实现时要完成对应用层传下来的数据包，加上UDP首部和UDP校验和，发往下一层。以及对下一层传上来的数据包，进行校验和检查，若正确去掉UDP首部，提出数据送给应用层。需注意的是，要产生一个伪首部用于UDP数据检验和计算，涉及到的主要函数有：
unsigned char verifyudpcrc(union netcard xdata *pRxdnet) //对ucp头进行校验，错误返回0
void udp_send(union netcard xdata *pTxdnet, unsigned char xdata * psource, unsigned int len) //UDP包发送处理
void udp_recieve(union netcard xdata *pRxdnet)UDP包接收处理
3.4 TCP协议的实现
TCP协议是面向连接的、端对端的可靠通信协议，可分以下几个步骤实现：
(1)建立连接。这一过程就是我们常说的三次握手过程。
(2)验证。采取相应的措施消除传输中的错误，保障传输的可靠性，利用序列号解决通信时重复和失序的问题。
(3)流量控制。设置发送和接收窗口。
TCP协议的功能是为应用层协议提供可靠的面向连接的数据传输服务，是嵌入式应用系统协议栈中最为复杂的协议。在TCP协议实现中，由于请求发起端(客户端)与请求相应端(服务器端)在通信中所处地位不同，相应地两者的中间演变状态也不完全相同。客户端与服务器端在一个TCP连接从正常建立到正常中止分别经历5个和6个状态，相应控制信息均在TCP头部信息的6位控制标记位中得以表示。对于嵌入式系统中TCP协议的实现，应从嵌入式应用的角度出发，尽可能减少冗余状态。程序中需要构造一个TCP_STATUS结构来记录每一个TCP连接的状态信息，其结构如下：
typedef struct
{unsigned long ip_addr; //源IP 地址
unsigned int port; //端口号
unsigned long remo_sequ; //对方序列号
unsigned long local_sequ; //本方序列号
unsigned long old_sequ; //上一次序列号
unsigned long remo_ack; //对方应答号
unsigned char timer; //超时用定时器
unsigned char quiet; //连接活动性
unsigned char state; //当前状态
}TCP_STATUS; //连接状态结构
4 结束语
嵌入式系统的应用非常广泛，解决嵌入式系统的网络接入问题具有十分重要的意义。本文实现的精简TCP/IP协议栈在具体应用中有良好表现，可以满足正常的数据传输。由于设计与实现的过程中将应用层协议全部精简，协议在运行过程中的流量控制能力及协议自身的安全性都有所下降，在对安全性和稳定性要求较高的应用场合（如军事、金融等领域），需要对协议的简化有所斟酌。
参考文献：
[1]罗蕾. 嵌入式实时操作系统及应用开发[M]. 北京:北京航空航天大学出版社. 2005.
[2]徐爱钧，彭秀华. Keil Cx51 V7.0单片机高级语言编程与μVision2应用实践[M]. 北京:电子工业出版社,2004.
[3]程耕国，高厚礼. 基于TCP/IP协议单片机上网的设计与实现[J]. 武汉科技大学学报(自然科学版)，2004,(2).
[4]田夏利，汪继军，薛胜军. 嵌入式Internet中UDP协议的实现[J]. 计算机与数字工程，2006,(2).
tcp协议范文5
等特点，对常用 TCP/IPV6 协议栈进行了裁减和简化，裁减掉一些不常用但不影响基本通信 功能的协议模块，同时对要保留下来要实现的各个协议进行简化，只实现其基本功能。设计完 成实现后的协议栈，具有代码量少，运行效率高和良好的可移植性等特点，适合于各种嵌入 式设备，是一种解决嵌入式设备接入 IPV6 网络的可行方案。
关键词：IPV6；嵌入式操作系统；邻居发现；ICMPV6；地址解释
Abstract
Via the research and analyse for the IPV6 technique in this article.In allusion to the MCU on embeded system is not fast，and the storage capability is low，we cut down the common IPV6 stack. In this design we cut down some unusuary used but not affect basic communication protcols.Besides， for the saved protocols we only realize it’s basic function.After the achievment we find that this stack little-codes， efficiency-runing and have good grafted ability. So it fit for embeded system devices， and be
considered as a feasible scheme for embedded system connecting to IPV6 network.
Keywords: PV6; Embedded Operating System; Neighbor Discovery; ICMPV6; Address Resolution.
1. 引言
嵌入式Internet技术是指把Internet技术 应用于嵌入式设备， 实现嵌入式设备的信息 交互，是嵌入式技术与Internet技术的结合， 具有非常广大的市场前景。目前不少厂商都 在进行这方面研究， 并推出了不少嵌入式 Internet解决方案，比较常用的成熟的解决方 案有，瑞士计算机科学院Adam Dunkels写的 ulP和 LWIP，它们以IPV4技术为基础，以精 简为指导思想，把复杂的TCP/IP技术引入嵌 入式设备，满足嵌入式设备接入网络的需 求。而作为IPV4改良版本的IPV6，是对IPV4 的升级和改进，是下一代网络的核心，如何 以IPV6技术为基础，设计一款和嵌入设备结 合的具 有 代码量 少 ，功能 简 单的精简 TCP/IPV6协议栈是一件非常现实意义的挑 战，也是本课题设计的目的所在。
2. IPV6 协议栈
IPV6协议栈是基于IPV6网络层的协议， 和IPV4一样，遵循现有互联网四层网络互联 体系结构，如图1所示。从图中我们可以看到， 协议栈分为网络接口层，互联网
层，传输层，应用层四层。应用层直接面 向用户，并提供访问其它层服务的功能;传 输层用于提供源主机和目的主机上的对等 实体对话;网络接口层屏蔽了具体的硬件实
现细节，负责底层数据的接收和发送；网络
层是整个TCP/IP体系结构的关键部分，其主 要功能是在网络上提供可靠的主机到主机 的数据传送。IPv6协议正是位于该层，它包 含的主要协议模块有IPV6，ICMPV6，邻居发 现ND，IPsec等。
2.1 IPV6 协议
根据RFC2460对IPV6功能的描述，IPV6 主要负责把上层来的数据段添加IPV6报头， 交由底层发送；把下层接收到的报文经过处 理和分析，交给TCP，UDP或ICMPV6处理。 和IPv4相比 IPv6的改变主要集中在以下几 个方面:地址容量的扩展，报头格式的简化， 支持扩展和选项的改进，数据流标签的能力，认证和保密的能力等[1]。
2.2 ICMPV6 协议
ICMPV6协议合并了IPv4中ICMP(控制 报文协议)，I- GMP(组成员协议)、ARP(地 址解析协议)等多个协议的功能，实现差错 控制，地址解释等功能，并支持Mobile IPv6。 ICMPV6报文封装在IP报文中，是IP报文的 有效载荷数据，它通过它的各种错误报文和 信息报文的交换来实现差错控制，地址解释 和路由前缀信息获取等功能。
2.3 邻居发现(Neighbor discovery) 协议
邻居发现协议ND是IPv6协议栈中的核 心协议，是IPV6解决邻节点交互的一个重要 协议。它定义了下列问题的解决机制：路由 发现，前缀发现，参数发现，地址自动配置， 地址解释，下一跳决定，邻居不可达，重复 地址检测，重定向。邻居发现的这些功能是 通过5个ICMP报文（邻居请求/邻居通告报 文，路由器请求/路由器通告报文，重定向报 文）的交换来实现的。 3. IPV6 协议栈的精简
协议栈精简的核心是“微型化”，我们对 协议栈进行协议模块裁减和单个协议简化。
3.1 协议模块裁减
协议模块裁减是指在保障基本通信功 能的前提下尽可能去掉一些协议模块，节省 系统资源。网络接口层我们只考虑 802.3 以 太网协议（CSMA/CD，MAC，LLC），不考 虑面向 CAN，RS-232，RS-485，射频，蓝牙等 相关的支持模块。接入方式上只考虑用路由 器接入方式，不考虑拨号连接方式，去掉和 拨号连接方式相关的面向点对点连接的 PPP 协议和 SLIP 协议，这两个协议在网络 接口层占用的代码量比较多；IP 层只实现基 本的报头，不实现扩展报头，去掉基于认证 头和封装安全载荷头选项的 IPsec 协议，安 全控制交给其他层。ICMPV6 和 ND 是核心
协议必须保留；传输层 TCP 和 UDP 可以全 部实现也可以只实现一种，考虑的适应性， 本设计中都给予实现。因此协议模块裁减后 要实现的核 心协议族 为 802.3 ， IPV6 ，
ICMPV6，ND，TCP，UDP。
3.2 单个协议简化
单个协议简化是指以单个协议为目标， 进行功能和数据结构的简化。对 IPV6 协议 来说，只接收，发送报文，不支持报文的分 片与重组，不支持扩展报头选项，对可靠连 接传输来讲，包过大得不到确认，会根据拥 塞控制机制和重传机制，减少数据分组长 度，进行重新发送，对大多数应用来说这不 会产生其他严重问题。对 ICMPV6 来说，只 实现错误报文中的目的不可达报文，信息报 文中的应答回复报文，不实现超时报文，报 文过大报文和应答请求报文，一般包过大， 超时报文由路由器实现，应答请求报文用于 主动测试中发起测试的 PC 机一端。对邻居 发现 ND 模块来说，只实现邻居请求和邻居 应答报文，嵌入式设备刚接入网络，它可以静 态的等待网络上路由器定时发送的路由公 告报文，而不是主动发送路由请求报文来获 取，不需实现路由请求/路由应答报文。嵌 入式设备连接的邻居接点，路由一般简单， 传输量少，不需重定向报文来进行路由定 向。简化的大块在 TCP，TCP 是整个协议簇 中最复杂，代码量最多的协议。它的功能模 块有：滑动窗口，流量控制，拥塞控制，TCP 连接状态机，往返时间估计，重传协议。本 协议栈的目标是有操作系统支持的嵌入式 系统，速度和存储量比 8 位和 16 位单片机 都有提高，不必采用分配固定缓冲区的形式 进行接收一帧处理一帧，可以考虑采用分配 一个较大的缓冲区实现滑动窗口机制，用来 提高传输效率，实验证明，传输效率的提高 是明显的，往返时间估计和重传机制比较简 单，代码量不大，可以实现，TCP 状态机表 示 TCP 进程通信的状态迁移，是 TCP 的核
心必须实现，可以不实现流量控制机制，因
为流量不是很大。因此 TCP 模块实现的功 能有：TCP 有限自动机，滑动窗口，往返时 间估计，重传协议。忽略流量控制与拥塞控 制模块，在可靠连接中，当因拥塞而发生数 据丢失的时候，发送方收不到确认就采用重 传机制重发数据[2]。
4. 嵌入式精简 IPV6 协议栈的设
计与实现
在设计协议栈过程中，我们在嵌入式操 作系统基础上设计和实现一个操作系统模 拟层，实现基本的时钟，消息管理和进程同 步等基本操作系统功能。协议进程方面，把 所有的协议栈封装到单独进程中，应用程序 可以驻留在其中或作为一个单独的进程，这 样既实现了与操作系统分离，又避免了层间 切换。对于内存管理采用类 BSD buf 结构， 把静态缓冲区和动态缓冲区链接起来[3]。
4.1 IPV6
IPV6 模块主要用于完成对接收到的 IPv6 数据报进行处理，对需要发送的 IPV6 数据包进行构造并递交底层发送。当接收到 一个数据包时，网络设备驱动调用 ip_input() 函数来对其 IP 报头进行检查，检查其版本 号，报文长度，载荷长度，目的节点地址和 下一报头，待检查无误后，根据下一包头的 类型分别提交给不同的处理模块。当要发送 数据时 ， 必须要知道发 送报文的下 一跳 IPV6 地址，以及该地址的相对应 MAC 地址， ip_route()函数就是为实现这样的功能而设 计的，其获取下一跳 IPV6 地址与其对应 MAC 地址的处理流程如图 2 所示。 图中，目的缓存用来存储着一系列最近 的报文流量与对应的下一跳 IP 地址的关系，
前缀列表存储着一系列子网前缀和其他地 址前缀及其对应的下一跳 IP 地址的关系， 如果两者中都没有找到匹配的记录，则再从 前缀列表中选择默认路由器作为传输的下 一跳 IPV6 地址。
在成功获取了下一跳 IPV6 地址后，数
据就进入传输阶段，传输阶段由 ip_outputif() 函数控制，ip_output()函数填充好报头，选择 好发送网络接口，然后激活发送网络接口进 行数据发送[4]。
4.2 ICMPV6
ICMPV6 负责接收， 解释和发 送 ICMPV6 报文。收到报文后，如果为邻居信 息报文则转交给邻居发现模块，如果为诊断 报文则交给 ICMPV6 诊断模块。ICMPV6 模 块只实现了应答回复报文，目的不可达报 文。当处理到达的 IP 报文时，如果下一报 头既不是 TCP，UDP 也不是 ICMPV6，那么 表示在嵌入式设备端的协议栈的已经到达 IP 层，是端口不可达，发送目的不可达报文。 当收到 ICMPV6 的应答请求报文时，就发送 应答回复报文，其格式与请求报文相似，在收 到的请求报文的基础上改变报文类型，重新 计算校验和，
在 IP 报头中将源，目的地址对调就可 以了。4.3 邻居发现
邻居发现是精简 IPV6 协议簇最核心的 协议，它利用邻居请求报文和邻居公告报文 的交换，实现地址解释，地址重复性检测， 以及地址自动配置功能。不实现路由器请求
/路由器公告报文，和重定向报文。
邻居请求报文
类型值为 135，报文 IP 头的源地址域为 发送邻居请求报文接口的地址或者未指定， 目的地址域为与被请求目标地址相关联的 被请求节点组播地址，或者就是被请求目标 地址本身。ICMPV6 报头域中的目标地址域 为被请求目标地址。选项域可以包含源链路 层地址选项，用来告诉对方发送请求节点的 MAC 地址，当源地址为指定
地址时必须包含该选项。
邻居公告报文
类型值为 136，用来响应邻居请求报文， 或者用来告知节点其链路层地址的改变，报 文 IP 头的源地址为发送邻居公告报文的接 口地址，目的地址为发送邻居请求的单播地 址，或者是用来公告给所有邻居节点其链路 层地址改变的全节点多播地址。目标地址就 是被解释的 IPV6 地址，或者在地址唯一性
验证中将要采用的 IPV6 地址。 地址解释就是节点仅仅知道邻居节点
IP 地址的情况下，通过发送邻居请求报文和 接收邻居公告报文，来得到对应节点链路层 地址的过程，是邻居发现模块中最重要的一 个功能模块，其处理过程如图 3 所示。
节点 A 知道节点 B 的链路 IPV6 地址
FEC0:0:0:1::B 但不知道节点 B 的链路层地 址 00-10-5C-F7-5C-96，沿箭头方向，A 发送邻 居请求报文，IP 域的目的地址是要求被解释
的目标地址 FEC0：0：0：1：：B。节点 B
收到邻居请求报文后，查看目标地址就是属 于本机，是则发送一个单播的邻居公告报文 给 A，在邻居公告报文的目的链路层地址选 项 里 包含节 点 B 的链 路层 地址
00-10-5C-F7-5C-96。这样
节点 A 知道了节点 B 的链路层地址， 地址解释过程完成[5]。
5. 测试与验证
5.1 在 Altera De2 上的实现与测试
课题的开发环境： Altera De2（硬件平 台）， Quartus II 5.1 和 Nios II 5.1（软件平 台），整个开发过程以 LWIP1.1.0 为参考， 在理解了 LWIP 的结构后在结合开发环境改 写。完成后对协议栈进行了测试和验证，测 试主要集中在网络层的 ND，IPV6，ICMPV6 模块。由 于邻居发 现模块建 立在 IPV6，ICMPV6 基础上的，对邻居模块的测试 相当于对 IPV6 和 ICMPV6 也进行了测试，
很具有代表性[6]。
受周围网络环境中无 IPV6 路由器所 限，测试在 IPV6 局域网上进行，Altera de2 通过以太网与 PC 机直接相连。测试对象电 路板 MAC 地址为 00-10-5C-F7-5F-
5D，其经过地址转换算法得到的本地 IPV6 地址为：fe80:210:5cff:fef7:5f5d，当它 接入网络时，为了对自己将要配置的地址进 行唯一性验证，它要发送邻居请求报文，通 过 PC 端网络抓包工具 Sniffer，我们抓到了由 目标板发出的邻居请求报文，如图 4 所示：
图 4 邻居请求报文
从图中看到其报文的类型值为 135。目
标地址为 fe80:210:5cff:fef7:5f5d。
测试协议栈在获取链路地址后，我们在
PC 机端执行 ping6 fe80::210:5cff:fef7:5f5d。 这个过程中要知道目标板的链路层地址，于 是发起针对目标板 IPV6 地址的地址解释。 在地址解释过程中，我们抓到了目标协议栈 发送的，包含自己链路层地址的单播邻居公 告报文，如图 5 所示。
图 5 邻居公告报文
由图可得知，报文类型值为 136，目标
地址为目
标板本地 IPV6 地址
fe80::210:5cff:fef7:5f5d。
5.2 在 s3c4410box 上的移植
移植目标平台：基于 s3c4410box 处理器的 ARM7 开发板，按照通用的方法，先移植了 uc/os-ii 嵌入式操作系统，在移植好 的基础上用操作系统函数编写了操作系统 模拟层，把网络接口层的函数指针指向电路 板提供的网卡驱动程序，在系统启动初试化 函数中添加针对 IPV6 协议栈的启动代码。 完成这些后我们使用 altera de2 上一样的测试方法进行测试，实验结果证明协议栈满足基本通信功能。证明协议栈可以在该电路板 上进行移植[7]。6. 结束语
本文介绍了嵌入式精简 TCP/IPV6 的设 计思想和实现方法，精简性和可移植性是其 考虑的主要方面，该协议栈是一种解决了嵌 入设备和接入 IPV6 网络的可行解决方案。
参考文献
[1] Robert e f. Embedded Internet Systems Come Home[ J]. IEEE Internet Computing，2001，5(1):52-53.
[2] Ruhuarvi j，Mahonen P，Saaranen M J. providing
[3] Soung S. Network-Driven layered multicast with IPV6[J]，Lecture Notesin Computer Science， 2000 ， Volume
18 :11.
[4] Liu Li-feng，Zou Shi-hong. A congestion and rate control scheme based on directed diffusion in wireless sensor networks[J].Journal of Beijing University of Posts and Telecommunications，2006，29(2):54-58.
[5] Chris M，Maillik T， A look at native Ipv6
multicast[J]， IEEE Internet Computing，2004 Volume8 Issue4: 48
[6] 周立功. SOPC 嵌入式系统实验教程. 深圳:北京航空航天出版社. 2006 :241-248
tcp协议范文6
关键词：互联网；嵌入式系统；协议栈；数据；报文；拥塞
中图分类号：TP311 文献标志码：A 文章编号：1009-3044(2008)31-0860-03
Research of Congestion Control Based on Embedded TCP/IP Protocol Stack
LI Chao1,2, HE Xian-bo1, WANG An-zhi1, HUANG Miao3
(puter College, China West Normal University, Nanchong 637002, China; 2.Nanchong Tourism School, Nanchong 637000, China; 3.Software Engineering School, Pingdingshan University, Pingdingshan 467003, China)
Abstract: This paper according to the present development condition of the computer network and embedded system software, summing up the general characteristics and procecing of the embedded TCP/IP protocol stack. Furthermore, discussing Congestion Control mechanism of the protocol stack in detail, especially analyzing and comparing sorts and implement algorithm of TCP Congestion Control mechanism and IP Congestion Control mechanism.Finally, setting up present Congestion Control solving methods of embedded TCP/IP protocol stack.
Key words: Internet; embedded system; protocol stack; data; message; congestion
1 引言
计算机网络的飞速发展，已经改变了人们的生产和生活方式。数字化信息家电的日益普及，使嵌入式系统连接到网络成为了可能。互联网采用的是无连接的端到端数据包交换，提供“尽力而为”服务模型的设计机制。这种机制的最大优势是设计简单，可扩展性强。然而随着互联网用户数量的膨胀，网络的拥塞问题也越来越严重。据统计，互联网上95%的数据流和90%的报文数使用的是TCP/IP协议，因此，嵌入式TCP/IP协议栈的拥塞控制机制对控制网络拥塞更具有特别重要的意义。
2 嵌入式TCP/IP协议栈概述
TCP/IP协议是由很多协议组成的协议族[1]。嵌入式系统引入互联网支持所需的主要协议为ARP、RARP、IP、ICMP和TCP协议。ARP和RARP协议提供网络地址的解析；ICMP协议提供网络诊断功能；TCP和IP协议提供网络传输和网络互联[1-2]。在网络接口层,系统需实现ARP应答协议，该协议用于将IP地址映射成以太网MAC地址；在网际层，需要实现IP协议，主要负责IP报文报头的正确性，并且对TCP和ICMP报文实行分流，此外，为了能够测试系统与网络的连接，在网际层还需要实现ICMP协议中的Ping应答协议，主要用于检查网络在传输层是否连通。
2.1 TCP/IP协议栈处理流程
TCP/IP协议栈接收数据包的过程就是解析数据包的过程。首先当一个数据帧到达时，网络接口控制程序将其读入缓冲区，检查协议类型字段，如果值依次为0X0800，表示数据域内为IP包；如果值依次为0X0806，表示数据域内为ARP包[3]。由此以确定使用那种协议模块来处理此分组。去掉以太网帧首部的数据包将被分配到IP缓存或者ARP缓存。接着，由IP协议处理模块或ARP协议处理模块继续解析。在IP协议模块处理数据包的过程，它要通过调用ARP协议获得对方主机的物理地址。
2.2 嵌入式TCP/IP协议栈的特点
嵌入式系统一般都是为了满足某一特定的需求，对网络支持的要求相对比较低，不需使用完整的TCP/IP协议。嵌入式TCP/IP协议栈的特点如下：
1) 开放的协议标准，独立于特定的计算机硬件、操作系统和网络硬件，可以运行在局域网，广域网和互联网中。
2) 统一的网络地址分配方案，使得整个TCP/IP设备在网中都具有唯一的地址；标准化的高层协议，可以提供多种可靠的用户服务。
3) 代码比较简洁，占用的存储空间尽可能小，尽可能为应用程序节省系统资源。
4) 便于裁剪和扩展，对于面向不同应用的嵌入式系统应当根据特点对协议进行简化或扩展。
TCP/IP协议栈具有层次特性，各个协议都有自己的数据格式，每次发送数据都要进行上下层协议的数据交换，进行打包和拆包的过程。在嵌入式系统中，往往无法建立数据传递的缓冲区，需要采用“零拷贝”技术来解决各层协议间的数据传递，以提高系统的实时性能。网络协议层次模型如图1所示。
3 拥塞控制概述
描述拥塞现象有许多不同的度量，如传输延时、数据吞吐量、队列长度和网络效率等，但是没有哪个度量能在局部和全局意义上完全满足拥塞评判要求，因此人们对拥塞控制并无严格定义，甚至对拥塞的定义都无法完全统一。
3.1 基本概念
定义1：若因为网络负载增加而导致用户的满意度降低，用户则认为网络发生拥塞。
形象地说，当网络中存在过多的报文时，网络的性能会下降，这种现象称为拥塞[4,5]。拥塞导致的直接结果是分组丢失率提高，端到端时延加大，甚至整个系统发生崩溃。当发生拥塞崩溃时，微小的负载增量将使网络的有效吞吐量急剧下降（如图2所示）。
定义2：当负载达到网络容量时，吞吐量开始缓慢增长，而响应时间急剧增加，这一点称为膝点(Knee)。
定义3：如果负载继续增加，路由器开始丢包，当负载超过一定量时，吞吐量开始急剧下降，这一点称为崖点(Cliff)。
定义4：拥塞控制就是采用某种策略或机制，保持网络工作在正常的状态下，也就是使网络经常工作在崖点左侧的区域内。从而避免拥塞的发生或者对拥塞的发生做出反应。拥塞控制的目标就是使网络在Knee附近工作。
3.2 产生拥塞的原因
网络拥塞是“尽力而为”服务模型的一个固有属性。用户间无法相互协作共享资源，多个用户对同一网络资源提出请求时，就可能发生拥塞。网络拥塞产生的原因有很多，直接原因主要有三个方面：1) 存储空间不足；2) 带宽容量不足；3) 处理器间处理能力和速度不一致。
3.3 拥塞控制算法的设计目标
由于拥塞控制算法性能的好坏会影响整个网络系统，因此在设计和评价算法时，应该站在整个系统的角度来考查。对于任何一种拥塞避免或控制方案，人们希望它能同时满足以下几点要求：高效性、公平性(鲁棒性)、稳定性、可扩展性。
4 TCP拥塞控制机制
TCP协议[6]是目前Internet上使用最广泛的一种传输层协议。TCP的主要目的是为了解决Internet的稳定性、异质性(接受端缓冲区大小，网络带宽及延迟等)、各流之间享用带宽的公平性，使用效率及拥塞控制等问题，从而为Internet提供可靠健壮的端到端通讯。TCP拥塞控制策略主要包括以下四个过程：
1) 慢启动阶段[7]：保证了连接建立初期进入网络的突发数据的流量不会过大。
2) 拥塞避免阶段：当数据发送速率超过一定阈值时，算法进入此阶段，而后发送速率缓慢线性增长，避免了网络拥塞的发生。
3) 快速重传阶段[9]：当网络发生拥塞造成数据丢失或者重传超时时，用该策略重传丢失的分组。
4) 快速恢复阶段：把网络从拥塞状态中恢复出来。
4.1 TCP拥塞控制的主要参数
1) 拥塞窗口(cwnd)：描述源端在拥塞控制情况下一次最多能发送的数据包数量。
2) 慢启动阈值(ssthresh)：拥塞控制中慢启动阶段和拥塞避免阶段的分界点。初始值设为65535bytes或awnd的大小。
3) 回路响应时间(RTT)：一个TCP数据包从源端发送到接收端、源端收到接受端确认的时间间隔。
4) 超时重传计数器(RTO)：描述数据包从发送到失效的时间间隔，是判断数据包丢失与否、网络是否拥塞的重要参数。通常设为2RTT和5RTT。
4.2 TCP拥塞控制算法
4.2.1 Reno算法
1990年Jacobson在Tahoe的基础上提出了Reno算法。Tahoe算法是最早被提出来的TCP源算法，但至今仍然被大多数TCP实现所采用。Reno算法对Tahoe的改进主要体现在两个方面。第一，收到连续三个dupACK，算法不经过慢启动，而直接进入拥塞避免阶段。第二，增加了快速重传/快速恢复(FR/FR)机制，具体过程为：
1) 收到三个dupACK进入FR/FR。ssthresh=max(cwnd/2,2)；
2) 重发去失的数据包；
3) 窗口膨胀。cwnd=ssthresh+ndupndup为收到的重复ACK数；
4) 当min(awnd，cwnd)足够大时，发送新的数据包；
5) 当收到非重复的ACK时，cwnd=ssthresh；
6) 转入拥塞避免阶段。可见，Reno在收到三个dupACK后，就转入FR/FR，而遇到超时，Reno和Tahoe一样进入慢启动阶段。可从Reno状态转换图直观地看到Reno的整个数据传输过程(如图3所示)。
Reno目前被广泛采用，以其算法的简单、有效和鲁棒性成为TCP源算法的主流。
4.2.2 NewReno算法
NewReno算法对Reno算法的改进是通过尽量避免Reno在快速恢复阶段的许多重传超时，利用一个ACK来确定部分发送窗口，立即重传余下的数据包，从而提高网络性能。目前，在因特网中使用最广泛的是NewReno算法。然而NewReno算法也存在着不足，它在高速远距离网络中不能有效利用带宽。
4.2.3 Sack算法
Sack算法也是对Reno算法的改进，当检测到拥塞后，不用重传数据包丢失到检测到丢失时发送的全部数据包，而是对这些数据包进行有选择的确认和重传，从而避免不必要的重传，减少时延，提高网络吞吐量。由于使用选择重传，所以在一个窗口中数据包多包丢失的情况下，Sack算法优于NewReno算法。但是Sack算法的主要缺点是要修改接收端TCP。
5 IP拥塞控制机制
随着Internet业务的迅猛发展，仅依靠单一的端到端的拥塞控制机制不可能有效地解决拥塞问题，另外期望所有用户在Internet应用中都遵守这种端到端的拥塞控制也是不现实的，这要求网络本身也必须参与对资源的管理与控制。基于此，提出了IP拥塞控制机制。
5.1 IP拥塞控制算法
5.1.1 随机及早检测(RED)算法
RED(Random Early Detective)算法在路由器监控队列长度，一旦发现拥塞迫近，就通知源端调整拥塞窗口。它也是通过丢包的方式使源端发现超时或重复应答，隐式通知源端拥塞情况。RED算法包含两部分：如何监控队列长度和何时丢弃数据包。首先，RED使用类似TCP计算超时时使用的权值Weight来计算平均排队长度：Qe=(1-Weight)×Qe+Weight×SampleQe其中，0
5.1.2 显示拥塞指示(ECN)算法
ECN(Explicit Congestion notification)算法在源端数据包中嵌入ECN，由路由器根据网络情况设置CE(Congestion Experienced)比特位，源端从网络中接收反馈回来的已被CE置位的数据包，再将随后发出的数据包标记为“可丢弃”的数据包。改进算法NewECN可通过调整拥塞窗口cwnd大小，纠正了有长时间RTT的TCP连接的偏差，改进了共享瓶颈处带宽的公平性。
5.1.3 加权公平排队(WFQ)算法
WFQ(Weight Fair Queue)是公平排队(FQ)算法的改进算法。WFQ算法对每个流即每个排队分配一个权值。这个权值决定了路由器每次转发该队列的比特数量，从而控制数据流得到的带宽。将所有权值看成1，那么FQ也是一种特殊的WFQ。权值的分配往往对应不同优先级的数据流，例如用IP包头中TOS域指定流的优先级，排队时再按优先级分配权值。总之，WFQ根据不同数据流应用的不同带宽要求，对每个排队队列采用加权方法分配缓存资源，从而增加了FQ对不同应用的适应性。
6 结论
讨论了嵌入式TCP/IP拥塞控制领域的研究热点。近年来,非线性规划和系统控制理论被引入拥塞控制研究中来,一些研究者使用数学模型来描述端系统和网关组成的系统，这对拥塞控制研究有很大的推动作用。然而，对于Internet这样一个复杂系统的分析与控制，只有通过通信、控制和数学等多学科的共同努力，才有望获得突破性成果。
参考文献：
[1] W.Richard STEVEN. TCP/IP详解 卷1：协议[M].范建华,胥光辉，张辉，等译.北京：机械工业出版社,2000：170-269.
[2] Jon C.SNADER. 高级TCP/IP编程[M]. 刘江林译.北京：中国电力出版社，2001:251-286
[3] Adam DUNKELS.Design and Implementation of the TCP/IP Stack[M]. Swedish:Institude of Computer Science,2001.
[4] Gevros P, Crowcroft J, Kirstein P, etal.Congestion control mechanisms and the best effort service model[J].IEEE Network,2001,15(3):16-26.
[5] Steves W.TCP Slows Start, Congestion Avoidance, Fast Retransmit and Fast Recovery Algorithms.RFC,2001[S], 1997.
[6] 陈岗,张会生.基于IPv6的移动互联网络研究与实现[J].微电子学与计算机,2006,23(2):40-42
