cap协议Word格式文档下载.docx
《cap协议Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《cap协议Word格式文档下载.docx（6页珍藏版）》请在冰豆网上搜索。
观察分组3，wireshark显示的序号是0。
选择分组首部的序号字段，原始框中显示“94f22ebe”。
wireshark显示的是逻辑序号，真正的初始序号不是0。
如图1所示：
图１：
逻辑序号与实际初始序号
syn分组通常是从客户端发送到服务器。
这个报文段请求建立连接。
一旦成功建立了连接，服务器进程必须已经在监听syn分组所指示的ip地址和端口号。
如果没有建立连接，syn分组将不会应答。
如果第一个分组丢失，客户端通常会发送若干syn分组，否则客户端将会停止并报告一个错误给应用程序。
如果服务器进程正在监听并接收到来的连接请求，它将以一个报文段进行相应，这个报文段的syn位和ack位都置为1。
通常称这个报文段为synack分组。
synack分组在确认收到syn分组的同时发出一个初始的数据流序号给客户端。
分组4的确认号字段在wireshark的协议框中显示1，并且在原始框中的值是“94f22ebf”（比“94f22ebe”多1）。
这解释了tcp的确认模式。
tcp接收端确认第x个字节已经收到，并通过设置确认号为x+1来表明期望收到下一个字节号。
分组4的序号字段在wireshark的协议显示为0，但在原始框中的实际值却是“84cabeb3”。
这表明tcp连接的双方会选择数据流中字节的起始编号。
所有初始序号逻辑上都视同为序号0。
最后，客户端发送带有标志ack的tcp报文段，而不是带syn的报文段来完成三次握手的过程。
这个报文段将确认服务器发送的synack分组，并检查tcp连接的两端是否正确打开合运行。
（2）关闭连接
当两端交换带有Fin标志的tcp报文段并且每一端都确认另一端发送的Fin包时，tcp连接将会关闭。
Fin位字面上的意思是连接一方再也没有更多新的数据发送。
然而，那些重传的数据会被传送，直到接收端确认所有的信息。
在tcp_pcattcp_n1.cap中，通过分组13至16我们可以看到tcp连接被关闭。
2、tcp重传
当一个tcp发送端传输一个报文段的同时也设置了一个重传计时器。
当确认到达时，这个计时器就自动取消。
如果在数据的确认信息到达之前这个计时器超时，那么数据就会重传。
重传计时器能够自动灵活设置。
最初tcp是基于初始的syn和synack之间的时间来设置重传计时器的。
它基于这个值多次设置重传计时器来避免不必要的重传。
在整个tcp连接中，tcp都会注意每个报文段的发送和接到相应的确认所经历的时间。
tcp在重传数据之前不会总是等待一个重传计算器超时。
tcp也会把一系列重复确认的分组当作是数据丢失的征兆。
在wireshark中选择file-〉open,打开文件pcattcp_retrans_t.cap和pcattcp_retrans_r.cap，对所俘获的分组进行分析如下：
（1）sack选项协商
在上面的每次跟踪中，我们能观察建立连接的三次握手。
在syn分组中，发送端在tcp的首部选项中通过包括sackpermitted选项来希望使用tcpsack。
在synack包中接收端表示愿意使用sack。
这样双方都同意接收选择性确认信息。
sack选项如图2所示：
图2：
sack选项
在tcpsack选项中，如果连接的一端接收了失序数据，它将使用选项区字段来发送关于失序数据起始和结束的信息。
这样允许发送端仅仅重传丢失的数据。
tcp接收端不能传递它们接收到的失序数据给处于等待状态的应用程序，因为它总是传递有序数据。
因此，接收到的失序数据要么被丢掉，要么被存储起来。
接收端的存储空间是有限的，tcp发送端必须保存一份已发送的数据的副本，以防止数据需要重发。
发送端必须保存数据直到它们收到数据的确认信息为止。
接收端通常会分配一个固定大小的缓冲区来存储这些失序数据和需要等待一个应用程序读取的数据。
如果缓冲区空间不能容纳下更多数据，那么接收端只有将数据丢弃，即使它是成功到达的。
接收端的通知窗口字段用来通知发送端还有多少空间可以用于输入数据。
如果数据发送的速度快于应用程序处理数据的速度，接收端就会发送一些信息来告知发送端其接收窗口正在减小。
在这个跟踪文件中，接收端通知窗口的大小是变化的，从16520个字节到17520个字节。
tcp发送端在发送之前有一个容纳数据的有限空间。
然而，和接收端不同的是，发送端是限制自己的发送速率。
如果缓冲区的空间满了，尝试写入更多数据的应用程序将被阻塞直到有更多的空间可以利用为止。
（2）分组的丢失与重传
用显示过滤器tcp.analysis.retransmission搜索重传。
在pcattcp_retrans_t.cap中应用
该过滤器，在这个跟踪文件中，我们看见分组12是这9次重传的第一次。
如图所示3：
图3：
pcattcp_retrans_t.cap中９次重传
通过观察分组12的细节，我们发现序号是1001，我们发现分组5也有同样的序号。
有趣的是，分组5是对1001到2460号字节的传输，而分组12却是对1001到2000号字节的重传。
分组20是对20xx到2460号字节的重传。
分组4是对1到1000号字节的传输，分组5是对1001到2460号字节的传输，分组7是对2461到3920号字节的传输。
我们已检查了发送端上获取的所有跟踪记录。
我们从接收端的角度来看同一个连接，我们会发现有些不同。
在pcattcp_retrans_r.cap中，我们发现1到1000号字节是在分组4里被传送的，而2461到3920号字节是在分组6（而不是分组7）中被传送的。
在这个跟踪文件中，分组5是1到1000号字节的确认。
我们没有看到1001到2460号字节的传输。
但是他们确实被传输送了，只是在发送端和接收端的某个环节丢失了。
现在我们来看接收端是如何处理这些丢失字节的。
在分组4达到以后，接收端会以确认号1001（分组5）作为响应。
在分组6的2461到3920号字节达到之后，接收端仍然以确认号1001（分组7）作为响应。
即使它接到的是附加数据，确认号仍然是它期望收到的下一个有序字节的序号。
同样在含有3921到5381号字节的分组8到达之后，接
篇二：
cap信令原理
mg003006
cap信令原理
issue1.1
华为技术有限公司
目录
课程说明.......................................................................................................................................1
课程介绍.......................................................................................................................................1
课程目标.......................................................................................................................................1
相关资料.......................................................................................................................................1
第1章camel原理.....................................................................................................................2
1.1概述........................................................................................................................................2
1.1.1camel的功能实体及其接口.......................................................................................3
1.1.2签约信息......................................................................................................................6
1.1.3dp标准.......................................................................................................................8
1.1.4camel触发机制......................................................................................................12
1.2基本呼叫状态模型（bcsm）.............................................................................................15
1.2.1基本呼叫管理（bcm）概述..........................................................................................15
1.2.2camel的始发基本呼叫状态模型o-bcsm.............................................................18
1.2.3camel的终接基本呼叫状态模型t-bcsm..............................................................21
第2章cap操作及ssF状态模型.............................................................................................26
2.1cap协议概述.....................................................................................................................26
2.2cap操作.............................................................................................................................26
2.3ssF状态迁移......................................................................................................................32
2.3.1概述..........................................................................................................................32
2.3.2“空闲”状态............................................................................................................34
2.3.3“等待指令”状态....................................................................................................34
2.3.4“等待用户交互结束”状态......................................................................................35
2.3.5“等待临时连接结束”状态......................................................................................36
2.3.6“监视”状态............................................................................................................37
2.3.7ssF状态迁移全集....................................................................................................38
2.4辅助ssF状态迁移模型......................................................................................................41
2.4.1概述..........................................................................................................................41
2.4.2“空闲”状态............................................................................................................42
2.4.3“等待指令”状态....................................................................................................42
2.4.4“等待用户交互结束”状态......................................................................................42
2.4.5辅助ssF状态迁移全集...........................................................................................43
2.5sRF
状态迁移......................................................................................................................43
2.5.1sRF应用组网...........................................................................................................43
2.5.2sRF状态迁移图.......................................................................................................45
2.5.3“空闲”状态............................................................................................................45
2.5.4“被连接”状态........................................................................................................46
2.5.5“用户交互”状态....................................................................................................46
2.6cap消息实例分析..............................................................................................................47
小结.............................................................................................................................................52
学习指导.....................................................................................................................................53
理论部分....................................................................................................................................53
课程介绍
课程目标
相关资料
课程说明本教材对应的产品为：
msc60大容量移动交换机本课程将对cap信令做详细的讲解，包括camel协议、cap操作、cap在ssF和scF等实体间的交互流程。
完成本课程学习，学员能够：
了解camel功能实体和各种接口了解camel基本呼叫状态模型掌握camel触发机制以及ssF和scp等实体间交互流程
mg003006cap信令原理issue1.1
第1章camel原理
1.1概述
camel（customisedapplicationsformobilenetworkenhancedlogic）的出现，是为了移动网能够提供独立于服务网络的业务运行机制。
camel并非提供一种补充业务，而是提供一种网络特征。
该特征简化了业务运营者从服务网络外对业务进行的控制。
因此，camel业务能够使网络运营者提供运营者自己决定的业务，即使用户漫游出hplmn，也不会对于业务的运行造成影响。
camel协议簇包括一系列的协议：
gsm02.78业务定义
gsm03.78camel功能实体定义
gsm09.78cap规范
为了适应camel应用，gsm的原有的部分协议也相应的做了修改。
主要修改的协议包括：
gsm09.02map规范
gsm03.18呼叫处理
gsm02.78协议定义了camel可以实现的业务特征，阐述了camel技术实现计费，漫游，补充业务配合的基本原理。
gsm03.78协议规定了camel功能实体分布，以及各个功能实体的状态迁移情况。
gsm09.78协议详细规定了camel功能实体间的cap操作，以及与tcap配合，差错处理，对话协商机制等。
gsm09.02协议是gsm协议簇原有协议。
为了支持camel，mapphaseii+对09.02协议做了扩展，支持与camel的相关操作。
gsm03.18协议是gsm协议簇原有协议。
为了支持camel，mapphaseii+对03.18协议做了扩展，支持在基本呼叫处理中嵌入camel相关处理。
篇三：
cap文件类型的数据包结构分析
cap文件类型的数据包结构分析
cap文件是比较通用的一种文件格式，基本上大多数抓包软件都支持以此格式将捕获的网络数据包存储下来。
需要说明的是，cap文件存储下来的，一般都是网络数据帧。
不同网络传输协议下的帧格式是有差异的，所以这里以以太网帧作讨论。
我所分析的cap包是由ethereal抓取的。
tcpdump和windump抓的包格式基本一致。
cap文件是全十六进制数据文件而不是文本文件，所以其结构需要分析，由于我并不打算做专门的分析软件，所以我只作对我来说有意义的
一些数据的分析。
cap里面的数据有些地方是和我们常规数据的顺序一样的，有些位置是标准的高位取反，根据该位置表示的数据类型确定。
cap文件的前24个16进制位是头文件相关的信息我们不用关心，随后紧跟的八个位（后面所有的位都指两个16进制数构成的一个十六进制位，如ac，b8就是两个
16进制位），是抓包的时间戳标记，里面应该包括了年月日和具体到毫秒级别的时间，前4位高低位的互换再乘1000可得到当前的时间精确到秒，后4位是微妙，算法同前面。
随后的8个位是比较重要的，其中前4个是我们抓取到的数据帧长度，同时也关系到我们如何在cap文件中得到下一组数据帧位置。
这四个位
每个的前两位高位取反后表示数据帧的长度，第一组是软件抓取到的数据帧长度，后面一组是网络中实际数据帧的长度。
一般来说第一组小于
等于第二组数据。
这八个位结束后，就是帧的具体内容，长度就是前面的第一组数，这个长度的后面，就是cap存的下一组帧数据，也就是说，
cap文件里面并没有规定捕获的帧数据之间有什么间隔字符串，我们需要靠第一组数确定，下一组数据在文件中的起始位置。
下面的内容其实应该算是tcp/ip书里的标准内容，不过我还是继续写吧。
我们接着讲后面负载的内容，6位的目标mac地址
升级会员 