pptp简练文档

pptp简练文档
pptp简练文档

centOS5.2下搭建基于pptp的vpn服务

时间:2010年6月4号

网名:搅局者

博客:https://www.360docs.net/doc/1f4218423.html,/u3/115191/index.html

从2.6.15开始,linux内核内建了MPPE的支持,所以只需装ppp和pptpd软件就可以

https://www.360docs.net/doc/1f4218423.html,/下载站点,需要下载的软件

1.装ppp包

[root@localhost~]#rpm-qa|grep ppp先检查,但是系统默认的这个包是不支持的所以要卸载rp-pppoe-3.5-32.1

ppp-2.4.4-2.el5

[root@localhost~]#yum remove ppp有依赖关系,所以用yum卸载省事

[root@localhost~]#rpm-ivh ppp-2.4.3-5.src.rpm安装ppp包

[root@localhost~]#cd/usr/src/redhat/SPECS/

[root@localhost SPECS]#ls

ppp.spec

[root@localhost SPECS]#rpmbuild-bb ppp.spec生成rpm包

[root@localhost RPMS]#cd i386/

[root@localhost i386]#pwd

/usr/src/redhat/RPMS/i386

[root@localhost i386]#ls

ppp-2.4.3-5.c5.i386.rpm ppp-debuginfo-2.4.3-5.c5.i386.rpm

[root@localhost i386]#rpm-ivh ppp-2.4.3-5.c5.i386.rpm安装ppp包

[root@localhost i386]#rpm-ivh ppp-2.4.3-5.c5.i386.rpm

Preparing...###########################################[100%] 1:ppp###########################################[100%] [root@localhost i386]#rpm-ivh ppp-debuginfo-2.4.3-5.c5.i386.rpm

Preparing...###########################################[100%] 1:ppp-debuginfo###########################################[100%] [root@localhost i386]#

2.装pptp包

[root@localhost~]#tar zxvf pptpd-1.3.4.tar.gz

[root@localhost pptpd-1.3.4]#cd pptpd-1.3.4

[root@localhost pptpd-1.3.4]#./configure

[root@localhost pptpd-1.3.4]#make

[root@localhost pptpd-1.3.4]#make install

3.启动pptp

[root@localhost~]#/usr/local/sbin/pptpd

查看状态

[root@localhost~]#ps-e|grep pptpd

7561?00:00:00pptpd

[root@localhost~]#ps-ef|grep pptpd

root75611022:14?00:00:00/usr/local/sbin/pptpd

root75804302022:14pts/200:00:00grep pptpd

[root@localhost~]#netstat-natp|grep1723

tcp000.0.0.0:17230.0.0.0:*LISTEN 7561/pptpd

关闭

[root@localhost~]#pkill pptpd关闭

4.配置文件

[root@localhost pptpd-1.3.4]#cp samples/pptpd.conf/etc/

[root@localhost pptpd-1.3.4]#cp samples/options.pptpd/etc/ppp/

[root@localhost pptpd-1.3.4]#cp samples/chap-secrets/etc/ppp/

[root@localhost etc]#vim pptpd.conf主配置文件

ppp/usr/sbin/pppd pppd文件位置

option/etc/ppp/options.pptpd指定options.pptpd配置文件的位置

localip192.168.64.128vpn服务器监控的ip

remoteip192.50.50.100-200分配给vpn客户端的ip地址

netmask255.255.255.0子网掩码

[root@localhost ppp]#vim chap-secrets用户名密码放在这里"admin"pptpd"123456"*

用户服务名称密码客户端ip(*代表所有,任意)

[root@localhost ppp]#vim options.pptpd用于保存与客户端连接相关配置,一般可以不用更改,但如果要加dns服务器的ip或一些其它的在这里添加就行

ms-dns202.106.0.20这是指定dns服务器的ip,其它的都默认就可以

配置完要重新启动

6.客户端

windows客户端----网络连接里----新建连接---连接到我工作场所的网络---虚拟专用网络连接---公司名(随意添)---不拨初始连接-----vpn的ip----完成

然后连接测试,并看获取ip就说明成功。

下图是建立客户端:

创建新连接

这个名字随便起

这个ip要是vpn服务器刚才配置的localip

用刚才设置的用户名和密码登陆测试

出现下图说明成功

在windows客户端用如下命令查看刚才获取的ip

说明成功!!其它的如果有iptables则添加转发规则。

注意事项:如果有问题就看日志/var/log/messages,如果的配置文件里打开了debug则会有详细的日志信息。

经常会有问题的是在/etc/pptpd.conf下的logwtmp这个选项打开了,但是在options配置文件里却找不到,所一般把这个选项去掉,当然也可以加上这个模块。

报文结构

报文结构

1.以太网的报文结构 DA SA TYPE DATA CRC 6 6 2 46-1500 4(单位: Bytes) DA:目的Mac地址 SA:源Mac地址 Type:指示Mac层的上层协议类型 DATA:数据字段 CRC:校验字段 Vlan的帧格式 DA SA Tag TYPE DATE CRC 6 6 4 2 46-150 0 4(单位:Bytes) Tag:包括TPID(Tag Protocol Identifier--是IEEE定义的新的类型,表明这是一个加了802.1Q标签的帧)和TCI(含帧的控制信息,包括Priority-优先级;CFI-值为0说明是规范格式,1为非规范格式;Vlan ID) 2.HUB解决的问题 共享带宽的设备,可以实现多台电脑同时使用一条数据总线来上网或组成局域网 3.交换机接的的问题

HUB产生的广播问题 4.Vlan解决的问题 Vlan是为解决以太网的广播问题和安全性而提出的,它在以太网帧的基础上增加了Vlan头,用Vlan ID把用户划分为更小的工作组,限制不同工作组间的用户二层互访,每个工作组就是一个虚拟的局域网。虚拟局域网的好处是可以限制广播范围,并能够形成虚拟工作组,攻台管理网络 5.路由器和二层交换机的区别 路由工作在第三层,交换机工作在第二层 路由有包交换过滤功能。所有端口分别属于不同的广播和冲突域 交换机没有包交换和过滤功能。所有端口共享一个广播域,每个端口是一个冲突域 6.OSPF的几种报文 HELLO:周期性发送,用来发现和维持OSPF 的邻居关系 DD:描述了本地LSDB的摘要信息,用于两台路由器进行数据同步 LSR:向对方请求所需的LSA,只有在双方成功交换DD报文后才会向对方发出LSR报文

常见报文格式汇总

附件:报文格式 1.1Ethernet数据包格式(RFC894) 1、DstMac的最高字节的最低BIT位如果为1,表明此包是以太网组播/广播包, 送给CPU处理。 2、将DstMac和本端口的MAC进行比较,如果不一致就丢弃。 3、获取以太网类型字段Type/Length。 0x0800→IP 继续进行3层的IP包处理。 0x0806→ARP 送给CPU处理。 0x8035→RARP 送给CPU处理。 0x8863→PPPoE discovery stage 送给CPU处理。 0x8864→PPPoE session stage 继续进行PPP的2层包处理。 0x8100→VLAN 其它值当作未识别包类型而丢弃。 1.2PPP数据包格式 1、获取PPP包类型字段。 0x0021→IP 继续进行3层的IP包处理。 0x8021→IPCP 送给CPU处理。 0xC021→LCP 送给CPU处理。 0xc023→PAP 送给CPU处理。 0xc025→LQR 送给CPU处理。 0xc223→CHAP 送给CPU处理。 0x8023→OSICP 送给CPU处理。 0x0023→OSI 送给CPU处理。 其它值当作未识别包类型而丢弃。

1.3 ARP 报文格式(RFC826) |←----以太网首部---->|←---------28字节ARP 请求/应答 ------ 1.4 IP 报文格式(RFC791)(20bytes) TOS 1.5 PING 报文格式(需IP 封装)(8bytes) 1.6 TCP 报文格式(需IP 封装)(20bytes)

紧急指针有效 ACK 确认序号有效 PSH 接收方应该尽快将这个报文交给应用层RST 重建连接 SYN 同步序号用来发起一个连接 FIN 发端完成发送认务 1.7UDP报文格式(需IP封装)(8bytes) 1.8MPLS报文格式 MPLS报文类型: 以太网中0x8847(单播) 0x8848(组播) PPP类型上0x8281(MPLSCP)

(完整版)OSPF的五种报文

OSPF的五种报文 2008-09-14 10:53 Router-LSA 由每个路由器生成,描述了路由器的链路状态和花费。传递到整个区域。 Network-LSA,由DR生成,描述了本网段的链路状态,传递到整个区域。 Net-Summary-LSA,由ABR生成,描述了到区域内某一网段的路由,传递到相关区域。 Asbr-Summary-LSA,由ABR生成,描述了到ASBR的路由,传递到相关区域。 AS-External-LSA,由ASBR生成,描述了到AS外部的路由,传递到整个AS(STUB 区域除外)。 1、hello报文:最常用的一种报文,周期性的发送给本路由器的邻居。内容包括一些定时器的数值、DR、BDR 以及自己已知的邻居。Hello 报文格式如表4-2 所示。 主要字段解释如下: * Network Mask:发送Hello 报文的接口所在网络的掩码。 * HelloInterval:发送Hello 报文的时间间隔。如果相邻两台路由器的Hello 间隔时间不同,则不能建立邻居关系。 * Rtr Pri:DR 优先级。如果设置为0,则路由器不能成为DR/BDR。

* RouterDeadInterval:失效时间。如果在此时间内未收到邻居发来的Hello 报文,则认为邻居失效。如果相邻两台路由器的失效时间不同,则不能建立邻居关系。 2、DD报文:两台路由器进行数据库同步时,用DD 报文来描述自己的LSDB,内容包括LSDB 中每一条LSA 的Header(LSA 的Header 可以唯一标识一条LSA)。LSA Header 只占一条LSA 的整个数据量的一小部分,这样可以减少路由器之间的协议报文流量,对端路由器根据LSA Header 就可以判断出是否已有这条LSA。DD 报文格式如表4-3 所示。 主要字段的解释如下: * Interface MTU:在不分片的情况下,此接口最大可发出的IP 报文长度。 * I(Initial):当发送连续多个DD 报文时,如果这是第一个DD 报文,则置为1,否则置为0。 * M(More):当发送连续多个DD 报文时,如果这是最后一个DD 报文,则置为0。否则置为1,表示后面还有其他的DD 报文。 * MS(Master/Slave):当两台OSPF 路由器交换DD 报文时,首先需要确定双方的主从关系,Router ID 大的一方会成为Master。当值为1 时表示发送方为Master。 * DD Sequence Number:DD 报文序列号,由Master 方规定起始序列号,每发送一个DD 报文序列号加1,Slave 方使用Master 的序列号作为确认。主从双方利用序列号来保证DD 报文传输的可靠性和完整性。 3、LSR:两台路由器互相交换过DD 报文之后,知道对端的路由器有哪些LSA 是本地的LSDB所缺少的,这时需要发送LSR 报文向对方请求所需的LSA。内容包

美式报文格式说明

美国气象报文简要说明 美国气象报文主体部分与国内报文基本一致,只是有些项目(风速、能见度等)采用的单位不一样。美国气象报文与国内最大的区别在于它有“备注”(RMK)部分,用于说明详细的天气温度、露点等附加信息。 下面就美国气象报文与国内报文的差异部分作详细解释: 国内报文: METAR ZSHC 081100Z 35003MPS 0700 R30/0900 -SG FZFG OVC006 M00/M01 Q1026 NOSIG= 美国报文: METAR KGNV 201953Z AUTO 24015KT 3/4SM R28/2400FT +TSRA BKN008 OVC015CB 26/25 A2985 RMK TSB32RAB32 一:地面风 1. 美国报文风速采用节(KT)为单位,一般的,我们认 为1MPS≈2KT 2. 风向是指风的来向,且为真北方向; 3. 当风速小于等于6KT,且风向不定,标注标示符 “VRB”; 4. 但风速小于3KT,定义为静风(calm),报文中用 -1-

00000KT 表示 二:能见度 1. 美国报文能见度采用英里(SM)为单位,一般的, 1SM=1600M 2. 在自动观测报文中,M1/4SM 表示能见度小于 1/4SM,10SM 表示能见度大雨等于10SM(类似国 内报文中9999)。 3. 值得注意的是,由于报文编排的缘故,当能见度大于 1SM 时能见度数值显示间隔比较大,比如:METAR KGNV 201953Z AUTO 24015KT 1 3/4SM……,这 时该机场能见度为一又四分之三英里,即2800 米。 4. 如果,报文中能见度没有显示单位表示符,则默认为 是米。 三:跑到视程 1. 美国报文跑道视程采用英尺(FT)为单位; 2. 当RVR 数据丢失,标注RVRNO 四: 备注部分 1. 美国气象报文与国内报文比较增加了备注部分,表示 符“RMK” ①当气象现象在本场5SM 以内,则认为该气象现象 是在本场发生的; ②当气象现象在本场5SM-10SM 以内,则报告附近

TCP报文格式详解

TCP报文格式详解 TCP报文格局详解 2011-08-31 TCP和谈只定义了一种报文格局 建立、拆除连接、传输数据应用同样的报文 TCP报文格局 TCP报文段首部(20个字节) 源端口和目标端口:各占2个字节,16比特的端标语加上32比特的IP地址,共同构成相当于传输层办事接见点的地址,即“插口”; 这些端口可用来将若干高层和谈向下复用; 序号字段和确认序号字段: 序号:占4个字节,是本报文段所发送的数据项目组第一个字节的序号。在TCP传送的数据流中,每一个字节都有一个序号。例如,一报文段的序号为300,而起数据供100字节,则下一个报文段的序号就是400; 确认序号:占4字节,是期望收到对方下次发送的数据的第一个字节的序号,也就是期望收到的下一个报文段的首部中的序号; 因为序号字段有32比特长,可以对4GB的数据进行编号,如许就可包管当序号反复应用时,旧序号的数据早已在收集中消散了;

数据偏移字段 数据偏移:占4比特,默示数据开端的处所离TCP报文段的肇端处有多远。这实际上就是TCP报文段首部的长度。因为首部长度不固定,是以数据偏移字段是须要的。 保存字段:6比特,供往后应用,今朝置为0。 6个比特的把握字段 紧急比特URGent:当URG=1时,注解此报文应尽快传送,而不要按本来的列队次序来传送。与“紧急指针”字段共同应用,紧急指针指出在本报文段中的紧急数据的最后一个字节的序号,使接管方可以知道紧急数据共有多长; 确认比特ACK:只有当ACK=1时,确认序号字段才有意义; 急迫比特PSH:当PSH=1时,注解恳求远地TCP将本报文段立即传送给其应用层,而不要比及全部缓存都填满了之后再向上交付。 复位比特ReSeT:当RST=1时,注解呈现严重错误,必须开释连接,然后再重建传输连接。复位比特还用来拒绝一个不法的报文段或拒绝打开一个连接; 同步比特SYN:在建树连接时应用,当SYN=1而ACK=0时,注解这是一个连接恳求报文段。对方若赞成建树连接,在发还的报文段中使SYN=1和ACK=1。是以,SYN=1默示这是一个连接恳求或毗邻接管报文,而ACK的值用来区分

相关报文格式

装箱单报文(货代-EDI) 相比普通装箱单报文,EDI发送给码头的智能闸口装箱单报文主要多了“装箱单编号”字段,报文格式定义如下:

注: 温度中,除正(+)负(-)号及小数点外,最多只能三位数字. 注: 危险货物闪点中,除正(+)负(-)号及小数点外,最多只能三位数字.

记录结构: 00 头记录M1 01 其他接收方C1 10 船舶信息M1 11 装卸港信息M1 50 集装箱信息M1 51 提单号信息M999 52 货物信息M1 53 货物描述M1 54 唛头M1 55 危险品信息C1 56 箱号信息M1 99 尾记录M1 备注:其中,11 卸货港填写该箱在本航次中的实际下船港口,中转港默认和卸货港保持一致;52 体积/件数/重量是指本提单在该箱中的件体积/件数/重量;56 体积/件数/重量是也指本提单在该箱中的件体积/件数/重量。 报文例子: 00:COSTCO:CONTAINER LOAD PLAN:9:SENDER:NPEDI:200902110739:::' 10:UN9293806:ITAL CONTESSA:0502W E:LTP::Y:DE' 11:FRLEH::CNNGB::FRLEH:::' 50:MSKU7299054:22GP:L:O:200902110737:6080843:MSK:::::::SENDER-0000000000:CP H:W:AAA::' 51:559890777-A' 52:1:72:CT::2038:15::::' 53:17' 54:N/M' 56:MSKU7299054:72:2300:2038:15' 51:559890777-B' 52:1:25:CT::530:2::::'

MT报文有两种格式

MT报文有两种格式 MT103报文有两种格式MT 103和MT 103+ (stp),模式有Serial和Cover两种; Serial指发MT103至账户行,MT103带头寸; Cover指同时发MT103和MT202的方式,MT103发至收款行,不带头寸;202发至账户行,由账户行将款项汇至收款行。 目前得到的美元汇款路径记录是: 当您需要将美元汇入您的账户时,请通知汇款人按照如下方式填写汇款申请书: 从境外汇入 美元汇款路径的路径1: 银行固定格式(SWIFT格式)汇款人填写 INTERMEDIARY BANKER’S NAME(中转行名称): Bank Of America, N. A. New York Branch, New York 美国银行xx分行 SWIFT CODE(SWIFT代码): BOFAUS3NBene banker’s a/c No.(收款行在该代理行的账号):49 BENEFICIARY BANKER’S NAME(收款行名称): Industrial and Commercial Bank of China, Credit Card Center, HEAD OFFICE,PRC 中国工商银行股份有限公司总行信用卡中心 SWIFT CODE(SWIFT代码):

ICBKCNBJICC BENEFICARY(最终受益人): Beneficiary’s Name, Account No., Address and PhoneNo. (填写收款人名称、外币收款账号、详细地址和电话) ______________________________________________ 美元汇款路径的路径2: 银行固定格式(SWIFT格式)汇款人填写INTERMEDIARY BANKER’S NAME(中转行名称):JPMorgan Chase, New York Branch, New York 摩根大通银行xx分行 SWIFT CODE(SWIFT代码): CHASUS33 Bene banker’s a/c No.(收款行在该代理行的账号):95 BENEFICIARY BANKER’S NAME(收款行名称): Industrial and Commercial Bank of China, HEAD OFFICE, PRC 中国工商银行股份有限公司总行 SWIFT CODE(SWIFT代码): ICBKCNBJ BENEFICARY(最终受益人): Beneficiary’s Name, Account No., Address and PhoneNo. (填写收款人名称、外币收款账号、详细地址和电话)

ICMP报文的格式和种类

ICMP报文的格式和种类 rague | 13 九月, 2007 16:41 --------------------------------格式------------------------------------- 各种ICMP报文的前32bits都是三个长度固定的字段:type类型字段(8位)、code代码字段(8位)、checksum校验和字段(16位) 8bits类型和8bits代码字段:一起决定了ICMP报文的类型。常见的有: 类型8、代码0:回射请求。 类型0、代码0:回射应答。 类型11、代码0:超时。 16bits校验和字段:包括数据在内的整个ICMP数据包的校验和,其计算方法和IP头部校验和的计算方法是一样的。 下图是一张ICMP回射请求和应答报文头部格式 对于ICMP回射请求和应答报文来说,接下来是16bits标识符字段:用于标识本ICMP进程。 最后是16bits序列号字段:用于判断回射应答数据报。 ICMP报文包含在IP数据报中,属于IP的一个用户,IP头部就在ICMP报文的前面 一个ICMP报文包括IP头部(20字节)、ICMP头部(8字节)和ICMP报文IP头部的Protocol值为1就说明这是一个ICMP报文 ICMP头部中的类型(Type)域用于说明ICMP报文的作用及格式 此外还有代码(Code)域用于详细说明某种ICMP报文的类型

所有数据都在ICMP头部后面。RFC定义了13种ICMP报文格式,具体如下: 类型代码 类型描述 0 响应应答(ECHO-REPLY) 3 不可到达 4 源抑制 5 重定向 8 响应请求(ECHO-REQUEST) 11 超时 12 参数失灵 13 时间戳请求 14 时间戳应答 15 信息请求(*已作废) 16 信息应答(*已作废) 17 地址掩码请求 18 地址掩码应答 其中代码为15、16的信息报文已经作废。 下面是几种常见的ICMP报文: 1.响应请求 我们日常使用最多的ping,就是响应请求(Type=8)和应答 (Type=0),一台主机向一个节点发送一个Type=8的ICMP报文,如果途中没有异常(例如被路由器丢弃、目标不回应ICMP或传输失败),则目标返回Type=0的ICMP报文,说明这台主机存在,更详细的tracert通过计算 ICMP报文通过的节点来确定主机与目标之间的网络距离。 2.目标不可到达、源抑制和超时报文 这三种报文的格式是一样的,目标不可到达报文(Type=3)在路由器或主机不能传递数据报时使用,例如我们要连接对方一个不存在的系统端口(端口号小于 1024)时,将返回Type=3、Code=3的ICMP报文,它要告诉我们:“嘿,别连接了,我不在家的!”,常见的不可到达类型还有网络不可到达(Code=0)、主机不可到达(Code=1)、协议不可到达(Code=2)等。源抑制则充当一个控制流量的角色,它通知主机减少数据报流量,由于 ICMP没有恢复传输的报文,所以只要停止该报文,主机就会逐渐恢复传输速率。最后,无连接方式网络的问题就是数据报会丢失,或者长时间在网络游荡而找不到目标,或者拥塞导致主机

常见报文格式帧结构

常见报文格式汇总 1.1Ethernet数据包格式(RFC894) 1、目的Mac的最高字节的第8位如果为1,表明此包是以太网组播/广播包,送给CPU处理。 2、将目的Mac和本端口的MAC进行比较,如果不一致就丢弃。 3、获取以太网类型字段Type/Length。 0x0800→IP 继续进行3层的IP包处理。 0x0806→ARP 送给CPU处理。 0x8035→RARP 送给CPU处理。 0x8863→PPPoE discovery stage 送给CPU处理。 0x8864→PPPoE session stage 继续进行PPP的2层包处理。 0x8100→VLAN 其它值当作未识别包类型而丢弃。 4、Tag帧。 Type:长度为2字节,取值为0x8100,表示此帧的类型为802.1Q Tag帧。 PRI:长度为3比特,可取0~7之间的值,表示帧的优先级,值越大优先级越高。该优先级主要为QoS差分服务提供参考依据(COS)。 VID(Vlan ID):长度12bits,可配置的VLAN ID取值范围为1~4094。通常vlan 0和vlan 4095预留,vlan1为缺省vlan,一般用于网管。 1.2PPP数据包格式 1、获取PPP包类型字段。 0x0021→IP 继续进行3层的IP包处理。 0x8021→IPCP 送给CPU处理。 0xC021→LCP 送给CPU处理。 0xc023→PAP 送给CPU处理。 0xc025→LQR 送给CPU处理。 0xc223→CHAP 送给CPU处理。 0x8023→OSICP 送给CPU处理。 0x0023→OSI 送给CPU处理。 其它值当作未识别包类型而丢弃。

icmp报文格式 各种

ICMP分析 文档说明:由于排版的问题,请在“视图”中选择“Web版式”进行阅读。 目录 1 ICMP报文的分类和格式 (2) 1.1 ICMP报文格式概要介绍 (2) 1.2 各种类型的ICMP报文的格式 (3) 1.2.1 ICMP请求和回答报文格式 (3) 1.2.2ICMP差错报文格式 (5) 1.2.2.1 ICMP重定向报文格式 (5) 1.2.2.2 目的不可达差错报文格式 (5) 1.2.2.3 ICMP源站抑制差错报文、超时差错报文和参数问题差错报文 (6) 2 ICMP函数关系图 (7) 3 ICMP流程图 (8) 4 ICMP状态机 (10) 5 ICMP接口 (13) 5.1 数据接口 (13) 5.1.1 ICMP模块和下层的接口 (13) 5.1.1.1 IP层——>ICMP模块 (13) 5.1.1.2 ICMP模块——> IP层 (13) 5.1.2 ICMP模块和上层的接口 (14) 5.1.2.1 ICMP模块——>上层 (14) 5.1.2.1.1 pr_ctlinput函数 (14) 5.1.2.1.2 rtredirect函数 (15) 5.1.2.1.3 pfctlinput函数 (15) 5.1.2.1.4 rip_input函数 (16) 5.1.2.2 上层——> ICMP模块 (16) 5.1.2.2.1 icmp_error函数 (16) 5.1.2.2.2 rip_output函数 (17) 5.2 控制接口 (18) 5.2.1 概况 (18) 5.2.2 rip_ctloutput函数 (18) 5.2.3 rip_usrreq函数 (19) 5.2.4 icmp_sysctl函数 (19) 5.3 OS接口 (20) 5.3.1 microtime函数 (20) 5.3.2 m_freem函数 (20) 5.3.3 m_gethdr函数 (21)

SWIFT报文的结构与报文类型

. . . .. . SWIFT 标准资料(十五)2003年11月实施版 SWIFT 标准 报文的结构与报文类型 2003年11月发布标准 2003年标准发布指南-最终版本-2003年2月 全国金融标准化技术委员会秘书处 对外经济贸易大学金融科技中心 2003-08-06

SWIFT标准报文 SWIFT标准报文(金融服务报文) SWIFT开发的商业标准报文已经成功应用在金融服务领域,而且根据市场的需要在不断发展中。2003版SWIFT标准扩大了应用范围,规范了具体形式,同时采用了先进的技术成果、可以满足金融服务的需要,包括批量支付、投资基金、证券、信托等方面。SWIFT标准的下一个版本将在2005年5月发布。 下面表示的是SWIFT标准2003版的发布过程:从2002年8月开始到2003年11月 正式实施。 Standards Release 2003 Schedule for Standards Release 2003 For the Standards Release 2003, the development and implementation schedule is as follows: 16 August 2002 High-Level Information on Standards Release 2003 15 November 2002 Preliminary Standards Release Guide 2003 Preliminary Message Format Validation Rules 2003 14 February 2003 Final Standards Release Guide 2003 Final Message Format Validation Rules 2003 29 March 2003 Vendor T est System 12 July 2003 Testing & Training System If necessary, updates to Message Format Validation Rules 2003 12 September 2003 UHB shipment 15 November 2003 Standards Release 2003 Live

SWIFT报文格式手册

2006年度SWIFT报文格式更新手册(2006/11/18起生效)

S W I F T M T 7 0 0 / 7 0 1 I S S U E O F A D / C 开立跟单信用证 MT700/701 范围 1. 由开证行发送给通知行的报文(注意:收、发报行间必须具有BKE密押关系); 2. 用来列明开证行发报行所开立的信用证条款。

MT700/701 准则 ◆ 除非另外列明,所开立的跟单信用证遵循巴黎国际商会制定的《跟单信用证统一惯例》。当该信用证遵循此惯例时,通知行(收报行)必须将之通知受益人或是另一家通知行。 ◆ 除非另外列明,如果适用,跟单信用证项下的偿付遵循巴黎国际商会制定的《跟单信用证项下银行间偿付的统一规则》。 ◆ 当跟单信用证的长度超过一个MT700的容量时,可以用一个或几个(最多三个)MT701报文格式来补充传送信息。 ◆ 除非另外列明,根据该报文通知受益人或是另一家通知行的跟单信用证是已生效的信用证。 ◆ 对自由议付跟单信用证,如果收报行不再以MT710报文格式转通知,那么该银行必须在信用证上加注: ? 每次议付时必须提交通知受益人的信用证正本 ? 议付行必须在所通知的信用证正本上标注每一次的议付情况 ◆ 为了避免可能产生的误解,尽可能使用银行的SWIFT BIC代码来表示银行名称,而不要用“ourselves”、“yourselves”、“us”、“you”这些词。 ◆ 通知行应该明确清楚地将跟单信用证的全部内容(包括任何细节)通知受益人。 MT700/701 域使用规则 1. 报文中可以出现域39A或39B,但不能同时出现; 2. 域42C和42a在被使用时必须同时出现; 3. 在使用时,域42C和42a同时出现;或是42M 单独出现;或是42P单独出现,除此之外没有其它组合形式; 4. 报文中可以出现域44C或44D,但不能同时出现; 5. 用MT700开立的跟单信用证长度不超过10000个字符(包括报头和报尾)。而收到的MT700的报文长度达10600个字符。

TCP报文格式详解

TCP报文是TCP层传输的数据单元,也叫报文段。 1、端口号:用来标识同一台计算机的不同的应用进程。 1)源端口:源端口和IP地址的作用是标识报文的返回地址。 2)目的端口:端口指明接收方计算机上的应用程序接口。 TCP报头中的源端口号和目的端口号同IP数据报中的源IP与目的IP唯一确定一条TCP连接。 2、序号和确认号:是TCP可靠传输的关键部分。序号是本报文段发送的数据组的第一个字节的序号。在TCP传送的流中,每一个字节一个序号。e.g.一个报文段的序号为300,此报文段数据部分共有100字节,则下一个报文段的序号为400。所以序号确保了TCP传输的有序性。确认号,即ACK,指明下一个期待收到的字节序号,表明该序号之前的所有数据已经正确无误的收到。确认号只有当ACK标志为1时才有效。比如建立连接时,SYN报文的ACK标志位为0。 3、数据偏移/首部长度:4bits。由于首部可能含可项内容,因此TCP报头的长度是不确定的,报头不包含任何任字段则长度为20字节,4位首部长度字段所能表示的最大值为1111,转化为10进制为15,15*32/8 = 60,故报头最大长度为60字节。首部长度也叫数据偏移,是因为首部长度实际上指示了数据区在报文段中的起始偏移值。 4、保留:为将来定义新的用途保留,现在一般置0。 5、控制位:URG ACK PSH RST SYN FIN,共6个,每一个标志位表示一个控制功能。 1)URG:紧急指针标志,为1时表示紧急指针有效,为0则忽略紧急指针。 2)ACK:确认序号标志,为1时表示确认号有效,为0表示报文中不含确认信息,忽略确认号字段。 3)PSH:push标志,为1表示是带有push标志的数据,指示接收方在接收到该报文

网络协议报文格式大集合

目录 1序、 (2) 1.1 协议的概念 (2) 1.2 TCP/IP体系结构 (2) 2链路层协议报文格式 (2) 2.1 Ethernet报文格式 (2) 2.2 802.1q VLAN数据帧(4字节) (3) 2.3 QinQ帧格式 (4) 2.4 PPP帧格式 (4) 2.5 STP协议格式 (5) 2.5.1 语法 (5) 2.5.2 语义 (6) 2.5.3 时序 (8) 2.6 RSTP消息格式 (9) 2.6.1 语法 (9) 2.6.2 语义 (11) 2.6.3 时序 (13) 3网络层协议报文 (14) 3.1 IP报文头 (14) 3.2 ARP协议报文 (16) 3.2.1 语法 (16) 3.2.2 语义 (17) 3.2.3 时序 (17) 3.3 VRRP协议报文 (18) 3.3.1 语法 (18) 3.4 BGP协议报文 (19) 3.4.1 语法 (19) 3.4.2 语义 (25)

1 序、 1.1 协议的概念 协议由语法、语义和时序三部分组成: 语法:规定传输数据的格式; 语义:规定所要完成的功能; 时序:规定执行各种操作的条件、顺序关系; 1.2 TCP/IP体系结构 TCP/IP协议分为四层结构,每一层完成特定的功能,包括多个协议。本课程实验中相关协议的层次分布如附图3-1所示。 图1-1TCP/IP协议层次 这些协议之间的PDU封装并不是严格按照低层PDU封装高层PDU的方式进行的,附图3-2显示了Ethernet帧、ARP分组、IP分组、ICMP报文、TCP报文段、UDP数据报、RIP报文、OSPF报文和FTP报文之间的封装关系。 图1-2各协议PDU间的封装关系 2 链路层协议报文格式 2.1 Ethernet报文格式 最新的IEEE 802.3标准(2002年)中定义Ethernet帧格式如下:

IEC103规约报文格式

IEC103规约格式 1.基本报文格式 1.1固定帧长报文 10 H 启动字符 CODE 控制域 ADDR 地址域 C S 代码和 16 H 结束字符 注:代码和=控制域+地址域(不考虑溢出位,即256模和) 1.2可变帧长报文 68 H ————启动字符1(1byte) Length ————长度(1byte) Length ————长度(重复)(1byte) 68 H ————启动字符2(重复)(1byte) CODE ————控制域(1byte) ADDR ————地址域(1byte) ASDU ————链路用户数据[(length-2)byte] C S————代码和(1byte) 16 H ————结束字符(1byte) 注:(1)代码和=控制域+地址域+ ASDU代码和(不考虑溢出位,即256模和)(2)ASDU为“链路用户数据”包,具体格式将在下文介绍 (3)Length=ASDU字节数+2 1.3控制域定义 控制域分“主从”和“从主”两种情况。 (1)“主从”报文的控制域 D7 D6 D5 D4 D3 D2 D1 D0 备用 PRM FCB FCV 功能码 0 1 每位的具体定义请参考详细103规约。 (2) “从主”报文的控制域 D7 D6 D5 D4 D3 D2 D1 D0 备用 PRM ACD DFC 功能码 0 0 每位的具体定义请参考详细103规约。

1.4地址域 地址域为主站与之通信的从站地址,0-254:设备地址,255:广播地址。 2.链路规约数据单元(LDPU) 控制方向:从控制系统到继电保护设备(或间隔单元)的传输方向。 监视方向:从继电保护设备(或间隔单元)到控制系统的传输方向。 2.1控制方向 ●复位帧计数位 ●复位通信单元 ●召唤1级数据 ●召唤2级用户数据 ●请求链路状态 2.2监视方向 ●确认帧:

TCP报文格式

TCP报文格式 TCP(Transmission Control Protocol)传输控制协议是一种面向连接的、可靠的、基于字节流的传输层协议 TCP报文格式: 源端口号(2字节): d5 df(54751) 目的端口号(2字节): 22 b8(8888) TCP报头中的源端口号和目的端口号同IP数据报中的源IP与目的IP唯一确定一条TCP连接 序号(4字节): 37 59 56 75 用来标识TCP发端向TCP收端发送的数据字节流 确认序号(4字节):

由于该报文为SYN报文,ACK标志为0,故没有确认序号(ACK标志为1时确认序号才有效) 一旦连接建立,该值将始终发送(同ACK标志) 首部长度(4位):报文头长度(单位:位)/32 1000(转化为10进制为8,8*32/8 = 32,该报文报头长度为32个字节)存在该字段是因为TCP报头中任选字段长度可变 报头不包含任何任选字段则长度为20字节;4位所能表示的最大值为1111,转化为10进制为15,15*32/8 = 60,故报头最大长度为60字节 标志位(12位): 0000 00010010 Reserved: 000~ ~~~~~~~~ ECN(Explicit Congetsion Notification): ~~~0 ~~~~~~~~ = N / NS / Nonce Sum:有效排除潜在的ECN滥用,RFC 3540 ~~~~ 0~~~~~~~ = C / CWR(Congestion Window Reduced):拥塞窗口减少标志 ~~~~ ~0~~~~~~ = E / ECE / ECN-Echo:ECE / ECN标志

完整版OSPF的五种报文

OSPF勺五种报文 2008-09-14 10:53 Router-LSA由每个路由器生成,描述了路由器的链路状态和花费。传递到整个区域。 Network-LSA,由DR生成,描述了本网段的链路状态,传递到整个区域。 Net-Summary-LSA由ABR生成,描述了到区域内某一网段的路由,传递到相关区域。 Asbr-Summary-LSA由ABR生成,描述了到ASBF的路由,传递到相关区域。 AS-External-LSA,由ASBR^成,描述了到AS外部的路由,传递到整个A(STUB 区域除外)。 1、hello报文:最常用的一种报文,周期性的发送给本路由器的邻居。内容包括一些定时器的数值、DR BDR以及自己已知的邻居。Hello报文格式如表4-2 所示。 表4-? Hello tS文格式 D 7 15 31 Version Type* Packet i&ngth Router ID Area ID CTiecksunn AuType Authentlcaton Network Mask HeElolnterval Options Rtr Prl Designated Router Backup D亡引gnated Router 主要字段解释如下:* N e t w o r k M a s k:发送H e l l o报文的接口所在网络的掩码。* HelloInterval :发送Hello报文的时间间隔。如果相邻两台路由器的Hello间隔时间不同,则不能建立邻居关系。 * Rtr Pri : DR优先级。如果设置为0,则路由器不能成为DR/BDR * RouterDeadlnterval :失效时间。如果在此时间内未收到邻居发来的Hello报文,则认为邻居失效。如果相邻两台路由器的失效时间不同,则不能建立邻居关系。

各种数据报和数据包格式

IP数据包格式 版本字段:4位。当前的IP协议版本是4,通常称为IPv4。下一个版本是6,称为IPv6 首部长度:4位,IP数据报首部的长度,每个单位为4个字节。IP数据报的长度是4个字节的整数倍。 服务类型:8位,服务类型。 前3位为优先级,用于表示数据报的重要程度,优先级取值从0(普通优先级)到7(网络控制高优先级)。 D、T和R位表示本数据报希望的传输类型。 D表示低时延(Delay)需求 T表示高吞吐量(Throughput)要求 R代表高可靠性(Reliability)要求。 总长度:总长度指首部和数据之和的长度,单位为字节。总长度字段为16位,因此数据报的最大长度为216-1=65535字节。 标识(identification):占16位。IP软件在存储器中维持一个计数器,每产生一个数据报,计数器就加1,并将此值赋给标识字段。但这个“标识”并不是序号,因为IP是无连接服务,数据报不存在按序接收的问题。当数据报由于长度超过网络的MTU而必须分片时,这个标识字段的值就被复制到所有的数据报的标识字段中。相同的标识字段的值使分片后的各数据报片最后能正确地重装成为原来的数据报。 标志(flag):占3位,但目前只有2位有意义。 标志字段中的最低位记为MF(More Fragment)。MF=1即表示后面“还有分片”的数据报。MF=0表示这已是若干数据报片中的最后一个。 标志字段中间的一位记为DF(Don’t Fragment),意思是“不能分片”。只有当DF=0时才允许分片。 片偏移:占13位。片偏移指出:较长的分组在分片后,某片在原分组中的相对位置。也就是说,相对用户数据字段的起点,该片从何处开始。片偏移以8个字节为偏移单位。这就是 说,每个分片的长度一定是8字节(64位)的整数倍。

网络报文格式

一、802.3报文 RFC(1516)报文头定义 Header Format Header ...--------+--------+--------+ MAC Header | 802.{3/4/5} MAC ...--------+--------+--------+ +--------+--------+--------+ | DSAP=K1| SSAP=K1| Control| 802.2 LLC +--------+--------+--------+ +--------+--------+---------+--------+--------+ |Protocol Id or Org Code =K2| EtherType | 802.2 SNAP +--------+--------+---------+--------+--------+ The total length of the LLC Header and the SNAP header is 8-octets, making the 802.2 protocol overhead come out on an nice boundary. The K1 value is 170 (decimal). The K2 value is 0 (zero). The control value is 3 (Unnumbered Information). 报文样例

二、AH报文 RFC2402 IPV4 加入AH BEFORE APPL YING AH ---------------------------- IPv4 |orig IP hdr | | | |(any options)| TCP | Data | ---------------------------- AFTER APPL YING AH --------------------------------- IPv4 |orig IP hdr | | | | |(any options)| AH | TCP | Data | --------------------------------- |<------- authenticated ------->| except for mutable fields 报文样例 IPV6 AH报文 RFC 2402 BEFORE APPL YING AH --------------------------------------- IPv6 | | ext hdrs | | | | orig IP hdr |if present| TCP | Data | --------------------------------------- AFTER APPL YING AH ------------------------------------------------------------ IPv6 | |hop-by-hop, dest*, | | dest | | | |orig IP hdr |routing, fragment. | AH | opt* | TCP | Data | ------------------------------------------------------------ |<---- authenticated except for mutable fields ----------->| 报文样例

报文头格式

TCP报文头:(一般20-60字节) 32位端口号: 源端口和目的端口各占16位,2的16次方等于65536,看端口的命令:netstat。 32位序号: 也称为顺序号(Sequence Number),简写为SEQ, 32位确认序号: 也称为应答号(Acknowledgment Number),简写为ACK。在握手阶段,确认序号将发送方的序号加1作为回答。 4位首部长度: 这个字段占4位,它的单位时32位(4个字节)。本例值为7,TCP的头长度为28字节,等于正常的长度2 0字节加上可选项8个字节。,TCP的头长度最长可为60字节(二进制1111换算为十进制为15,15*4字节=60字节)。 6位标志字段: ACK 置1时表示确认号(为合法,为0的时候表示数据段不包含确认信息,确认号被忽略。 RST 置1时重建连接。如果接收到RST位时候,通常发生了某些错误。 SYN 置1时用来发起一个连接。 FIN 置1时表示发端完成发送任务。用来释放连接,表明发送方已经没有数据发送了。

URG 紧急指针,告诉接收TCP模块紧要指针域指着紧要数据。注:一般不使用。 PSH 置1时请求的数据段在接收方得到后就可直接送到应用程序,而不必等到缓冲区满时才传送。注:一般不使用。 16位检验和: 检验和覆盖了整个的TCP报文段: TCP首部和TCP数据。这是一个强制性的字段,一定是由发端计算和存储,并由收端进行验证。 16位紧急指针:注:一般不使用。 只有当U R G标志置1时紧急指针才有效。紧急指针是一个正的偏移量,和序号字段中的值相加表示紧急数据最后一个字节的序号。 可选与变长选项:通常为空,可根据首部长度推算。用于发送方与接收方协商最大报文段长度(MSS),或在高速网络环境下作窗口调节因子时使用。首部字段还定义了一个时间戳选项。 最常见的可选字段是最长报文大小,又称为MSS (Maximum Segment Size)。每个连接方通常都在握手的第一步中指明这个选项。它指明本端所能接收的最大长度的报文段。1460是以太网默认的大小。

相关文档
最新文档