sqlserver数据传输协议分析.docx

sqlserver数据传输协议分析.docx

《sqlserver数据传输协议分析.docx》由会员分享，可在线阅读，更多相关《sqlserver数据传输协议分析.docx（11页珍藏版）》请在冰豆网上搜索。

sqlserver数据传输协议分析

竭诚为您提供优质文档/双击可除

sql,server数据传输协议分析

　　篇一：

tFtp协议分析

　　计算机网络作业

　　题目

　　学院

　　专业

　　学生姓名

　　导师姓名tFtp协议分析电子工程学院xxxxxxxxxxxxxxx（学号02113xxx）胡建伟

　　1.tFtp协议简介

　　tFtp（trivialFiletransferprotocol，简单文件传输协议）是tcp/ip协议族中的一个用来在客户机与服务器之间进行简单文件传输的协议，提供不复杂、开销不大的文件传输服务。

端口号为69。

tFtp的版本2是因特网的正式标准[RFc1350]。

　　1.1概述

　　虽然tFtp也使用客户服务器方式，但它使用udp数据报（但是我们也不能确定有些tFtp协议是基于其它传输协议完成的），因此tFtp需要自己的差错改正措施。

tFtp只支持文件传输而不支持交互。

tFtp没有一个庞大的命令集，因此它不具备通常的Ftp的许多功能，它只能从文件服务器上获得或写入文件，不能列出目录，不进行认证，它传输8位数据。

　　tFtp协议概述：

　　1.简单文件传送协议（trivialFiletransferprotocol）

　　2.最初用于引导无盘系统，被设计用来传输小文件

　　3.基于udp协议实现，但也可以由其他协议实现

　　4.不具备Ftp的许多功能

　　5.只能从服务器获取或写入文件，不能列出目录

　　6.不进行认证

　　1.2模式

　　与Ftp相似，tFtp传输过程中也有传输模式之分，模式的意思是如何解释数据包里的内容，比如是字符串还是二进制等。

目前tFtp传输有三种模式：

　　netascii型：

是8位的ascii码形式（文本模式）

　　octet型：

即普通的二进制型（二进制模式）

　　mail型：

过时，不再使用

　　另外，通讯双方也可以自定义所需的传输模式。

　　1.3特点

　　tFtp的主要特点是：

（1）每次传送的数据报文中有512字节的数据，但最后一次可不足512字节。

（2）数据报文按序编号，从1开始。

　　（3）支持ascii码或二进制传送。

　　（4）可对文件进行读或写。

　　（5）使用很简单的首部。

　　1.4优点

　　tFtp的优点主要有两个。

　　第一，tFtp可用于udp环境。

　　例如，当需要将程序或文件同时向许多机器下载时就往往需要使用tFtp。

　　第二，tFtp代码所占的内存较小。

　　这对较小的计算机或某些特殊用途的设备是很重要的。

这些设备不需要硬盘，只需要固化了tFtp，udp和ip的小容量只读存储器即可。

当接通电源后，设备执行只读存储器中的代码，在网络上广播一个tFtp请求。

网络上的tFtp服务器就发送响应，其中包括可执行二进制程序。

设备收到此文件后将其放入内存，然后开始运行程序。

这种方式增加了灵活

　　性，也减少了开销。

　　2.tFtp包格式

　　因为tFtp使用udp，而udp使用ip，ip还可以使用其它本地通信方法。

因此一个tFtp包中会有以下几段：

本地媒介头，ip头，数据报头，tFtp头，剩下的就是tFtp数据了。

tFtp在ip头中不指定任何数据，但是它使用udp中的源和目标端口以及包长度域。

由tFtp使用的包标记（tid）在这里被用做端口，因此tid必须介于0到65,535之间。

tFtp头中包括两个字节的操作码，这个码指出了包的类型，包头次序为：

　　tFtp共定义了五种类型的包格式，格式的区分由包数据前两个字节的opcode字段区分，分别是：

　　读文件请求包：

Readrequest，简写为RRq，对应opcode字段值为1

　　写文件请求包：

writerequest，简写为wRq，对应opcode字段值为2

　　文件数据包：

data，简写为data，对应opcode字段值为3

　　回应包：

acknowledgement，简写为ack，对应opcode字段值为4

　　错误信息包：

error，简写为eRRoR，对应opcode字段值为5

　　1、读写请求包的格式如下图：

　　pRq（读请求）报文由客户使用，用来建立一条从服务器读数据的连接。

wRq（写请求）报文由客户使用，用来建立一条把数据写到服务器的连接，它的格式与pRq相同，除了头部的操作码是2。

　　RRq和wRq包（代码分别为1和2）中，文件名是netascii码字符，以0结束。

而mode域包括了字符串"netascii"，"octet"或"mail"，名称不分大小写。

接收到netascii格式数据的主机必须将数据转换为本地格式。

octet模式用于传输文件，这种文件在源机上以8位格式存储。

假设每个机器都存在一个8位的格式，这样的假设是最一般的。

比如dec-20，这是一种36位机，我们可以假设它是4个8位外加另外4位而构成。

如果机器收到octet格式文件，返回时必须与原来文件完全一样。

在使用mail模式时，用户可以在File处使用接收人地址，这个地址可以是用户名或用户名@主机的形式，如果是后一种形式，允许主机使用电子邮件传输此文件。

如果使用mail类型，包必须以wRq开始，否则它与netascii完全一样。

我们的讨论建立在发送方和接收方都在相同模式的情况下，但是双方可以以不同的模式进行传输。

例如一个机器可以是一台存储服务器，这样一台服务器需要将netascii格式转换为自己的格式。

另外，我们可以设想dec-20这种机器，它使用36位字长，用户这边可以使用特殊的机制一次读取36位，而服务器却可以仍然使用8位格式。

在这两种情况下，我们看到了两台机器使用不同格式的情况。

可以在两台主机间定义其它的传输方式，但是定义要小心，因为这种传输方式不为人知，而且也没有权威机构为其指定名称或定义它的模式。

　　2、data（数据）报文由客户和服务器使用，用来传送数据块，其格式如

　　下图所示：

　　数据包的操作码为3，它还包括有一个数据块号和数据。

数据块号域从1开始编码，每个数据块加1，这样接收方可以确定这个包是新数据还是已经接收过的数据。

数据域从0字节到512字节。

如果数据域是512字节则它不是最后一个包，如果小于512字节则表示这个包是最后一个包。

除了ack和用于中断的包外，其它的包均得到确认。

发出新的数据包等于确认上次的包。

wRq和data包由ack或eRRoR数据包确认，而RRq数据包由data或eRRoR数据包确认。

　　3、ack（确认）报文由客户和服务器使用，用来确认已收到数据块，这个报文只有

　　篇二：

http协议中你必须知道的三种数据格式

　　http协议中你必须知道的三种数据格式

　　实习中的一个主要工作就是分析http中的协议，自己也用python写过正则表达式对http请求和响应的内容进行匹配，然后把关键字段抽离出来放到一个字典中以备使用（可以稍微改造一下就是一个爬虫工具）。

　　http协议中的很多坑，自己都遇到过，我就针对自己遇到的几种http常见的数据格式，来做一个总结。

　　zlib压缩数据

　　对于zlib，一点也不陌生，我们平时用它来压缩文件，常见类型有zip、rar和7z等。

zlib是一种流行的文件压缩算法，应用十分广泛，尤其是在linux平台。

当应用zlib压缩到一个纯文本文件时，效果是非常明显的，大约可以减少70％以上的文件大小,这取决于文件中的内容。

　　zlib也适用于web数据传输，比如利用apache中的gzip（后面会提到，一种压缩算法）模块，我们可以使用gzip压缩算法来对apache服务器发布的网页内容进行压缩后再传输到客户端浏览器。

这样经过压缩后实际上降低了网络传输的字节数，最明显的好处就是可以加快网页加载的速度。

　　网页加载速度加快的好处不言而喻，节省流量，改善用户的浏览体验。

而这些好处并不仅仅限于静态内容，php动态页面和其他动态生成的内容均可以通过使用apache压缩模块压缩，加上其他的性能调整机制和相应的服务器端缓存规则，这可以大大提高网站的性能。

因此，对于部署在linux服务器上的php程序，在服务器支持的情况下，建议你开启使用gzipweb压缩。

　　gzip压缩两种类型

　　压缩算法不同，可以产生不同的压缩数据（目的都是为了减小文件大小）。

目前web端流行的压缩格式有两种，分别是gzip和defalte。

　　apache中的就是gzip模块，deflate是同时使用了lz77算法与哈夫曼编码（huffmancoding）的一个无损数据压缩算法。

deflate压缩与解压的源代码可以在自由、通用的压缩库zlib上找到。

　　更高压缩率的deflate是7-zip所实现的。

advancecomp也使用这种实现，它可以对gzip、png、mng以及zip文件进行压缩从而得到比zlib更小的文件大小。

在kensilverman的kzip与pngout中使用了一种更加高效同时要求更多用户输入的deflate程序。

　　deflate使用

　　inflateinit（），而gzip使用inflateinit2（）进行初始化，比

　　inflateinit（）多一个参数:

-max_wbits，表示处理rawdeflate数据。

因为gzip数据中的zlib压缩数据块没有zlibheader的两个字节。

使用inflateinit2时要求zlib库忽略zlibheader。

在zlib手册中要求windowbits为8..15，但是实际上其它范围的数据有特殊作用，如负数表示rawdeflate。

　　其实说这么多，总结一句话，deflate是一种压缩算法,是huffman编码的一种加强。

deflate与gzip解压的代码几乎相同，可以合成一块代码。

　　更多知识请见

　　维基百科zlib。

　　web服务器处理数据压缩的过程

　　web服务器接收到浏览器的http请求后，检查浏览器是否支持http压缩（accept-encoding信息）；

　　如果浏览器支持http压缩，web服务器检查请求文件的后缀名；

　　如果请求文件是html、css等静态文件，web服务器到压缩缓冲目录中检查是否已经存在请求文件的最新压缩文件；

　　如果请求文件的压缩文件不存在，web服务器向浏览器返回未压缩的请求（sql,server数据传输协议分析）文件，并在压缩缓冲目录中存放请求文件的压缩文件；

　　如果请求文件的最新压缩文件已经存在，则直接返回请求文件的压缩文件；

　　如果请求文件是动态文件，web服务器动态压缩内容并返回浏览器，压缩内容不存放到压缩缓存目录中。

　　举个栗子

　　说了这么多，下面举一个例子，打开抓包软件，访问我们学校的官网（），请求头如下:

　　get/_css/tpl2/system.csshttp/1.1

　　host:

　　connection:

keep-alive

　　user-agent:

mozilla/5.0（windowsnt10.0;wow64）applewebkit/537.36（khtml,likegecko）chrome/54.0.2840.59safari/537.36

　　accept:

text/css,*/*;q=0.1

　　Referer:

http:

///

　　accept-encoding:

gzip,deflate

　　accept-language:

zh-cn,zh;q=0.8

　　cookie:

a10-default-cookie-persist-20480-sg_bluecoat_a=aFFihimkFaaa

　　在第七行，

　　accept-encoding显示的是

　　gzip,deflate，这句话的意思是，浏览器告诉服务器支持gzip和deflate两种数据格式，服务器收到这种请求之后，会进行gzip或deflate压缩（一般都是返回gzip格式的数据）。

　　python的urllib2就可以设置这个参数：

　　request=urllib2.Request（url）

　　request.add_header（accept-encoding,gzip）

　　//或者设置成deflate

　　request.add_header（accept-encoding,deflate）

　　//或者两者都设置

　　request.add_header（accept-encoding,gzip,deflate）

　　服务器给的响应一般如下：

　　http/1.1200ok

　　date:

sat,22oct20xx11:

41:

19gmt

　　content-type:

text/javascript;charset=utf-8

　　transfer-encoding:

chunked

　　connection:

close

　　Vary:

accept-encoding

　　tracecode:

24798560510951725578102219

　　server:

apache

　　content-encoding:

gzip

　　400a

　　............ks#i....w...,....>..t..]..z...y..].mk..2..l..（略）

　　//响应体为压缩数据

　　从响应头来看，content-encoding:

gzip这段话说明响应体的压缩方式是gzip压缩，一般有几种情况，字段为空表示明文无压缩，还有content-encoding:

　　gzip和content-encoding:

deflate两种。

　　实际上gzip网站要远比deflate多，之前写过一个简单爬虫从

　　hao123的主页开始爬，爬几千个网页（基本涵盖所有常用的），专门分析响应体的压缩类型，得到的结果是：

　　accept-encoding不设置参数：

会返回一个无压缩的响应体（浏览器比较特别，他们会自动设置accept-encoding:

gzip：

deflate来提高传输速度）；

　　accept-encoding:

gzip，100%的网站都会返回gzip压缩，但不保证互联网所有网站都支持gzip（万一没开启）；

　　accept-encoding:

deflate：

只有不到10%的网站返回一个deflate压缩的响应，其他的则返回一个没有压缩的响应体。

　　accept-encoding:

gzip,deflate：

返回的结果也都是gzip格式的数据，说明在优先级上gzip更受欢迎。

　　响应头的encoding字段很有帮助，比如我们写个正则表达式匹配响应头是什么压缩：

　　（　　匹配到内容为空说明没有压缩，为

　　gzip说明响应体要经过gzip解压，为

　　deflate说明为deflate压缩。

　　python中的zlib库

　　在python中有zlib库，它可以解决gzip、deflate和zlib压缩。

这三种对应的压缩方式分别是：

　　RFc1950（zlibcompressedformat）

　　RFc1951（deflatecompressedformat）

　　RFc1952（gzipcompressedformat）

　　虽说是python库，但是底层还是c（c++）来实现的，这个

　　http-parser也是c实现的源码，nodejs的

　　http-parser也是c实现的源码，zlib

　　的c

　　源码在这里。

c真的好牛逼呀！

　　在解压缩的过程中，需要选择windowbits参数：

　　to（de-）compressdeflateformat,usewbits=-zlib.max_wbits

　　to（de-）compresszlibformat,usewbits=zlib.max_wbits

　　to（de-）compressgzipformat,usewbits=zli

　　例如，解压gzip数据，就可以使用zlib.decompress（data,zlib.max_wbits|16），解压deflate数据可以使用zlib.decompress（data,-zlib.max_wbits）。

　　当然，对于gzip文件，也可以使用python的gzip包来解决，可以参考下面的代码：

　　>>>importgzip

　　>>>importstringio

　　>>>fio=stringio.stringio（gzip_data）

　　>>>f=gzip.gzipFile（fileobj=fio）

　　>>>f.read（）test>>>f.close（）

　　也可以在解压的时候自动加入头检测，把32加入头中就可以触发头检测，例如：

　　>>>zlib.decompress（gzip_data,zlib.max_wbits|32）

　　test

　　>>>zlib.decompress（zlib_data,zlib.max_wbits|32）

　　test

　　以上参考stackoverflow

　　howcanidecompressagzipstreamwithzlib。

　　刚接触这些东西的时候，每天都会稀奇古怪的报一些错误，基本上google一下都能解决。

　　分块传输编码chunked

　　分块传输编码（chunkedtransferencoding）是超文本传输协议（http）中的一种数据传输机制，允许http由网页服务器发送给客户端应用（通常是网页浏览器）的数据可以分成多个部分。

　　分块传输编码只在http协议1.1版本（http/1.1）中提供。

　　通常，http应答消息中发送的数据是整个发送的，content-length消息头字段表示数据的长度。

数据的长度很重要，因为客户端需要知道哪里是应答消息的结束，以及后续应答消息的开始。

然而，使用分块传输编码，数据分解成一系列数据块，并以一个或多个块发送，这样服务器可以发送数据而不需要预先知道发送内容的总大小。

通常数据块的大小是一致的，但也不总是这种情况。

　　分块传输的优点

　　http1.1引入分块传输编码提供了以下几点好处：

　　http分块传输编码允许服务器为动态生成的内容维持http持久链接。

通常，持久链接需要服务器在开始发送消息体前发送content-length消息头字段，但是对于动态生成的内容来说，在内容创建完之前是不可知的。

　　分块传输编码允许服务器在最后发送消息头字段。

对于那些头字段值在内容被生成之前无法知道的情形非常重要，例如消息的内容要使用散列进行签名，散列的结果通过http消息头字段进行传输。

没有分块传输编码时，服务器必须缓冲内容直到完成后计算头字段的值并在发送内容前发送这些头字段的值。

　　http服务器有时使用压缩（gzip或deflate）以缩短传输花费的时间。

分块传输编码可以用来分隔压缩对象的多个部分。

在这种情况下，块不是分别压缩的，而是整个负载进行压缩，压缩的输出使用本文描述的方案进行分块传输。

在压缩的情形中，分块编码有利于一边进行压缩一边发送数据，而不是先完成压缩过程以得知压缩后数据的大小。

　　注：

以上内容来自于维基百科。

　　分块传输的格式

　　如果一个http消息（请求消息或应答消息）的transfer-encoding消息头的值为chunked，那么，消息体由数量未定的块组成，并以最后一个大小为0的块为结束。

　　每一个非空的块都以该块包含数据的字节数（字节数以十六进制表示）开始，跟随一个cRlF（回车及换行），然后是数据本身，最后块cRlF结束。

在一些实现中，块大小和cRlF之间填充有白空格（0x20）。

　　最后一块是单行，由块大小（0），一些可选的填充白空格，以及cRlF。

最后一块不再包含任何数据，但是可以发送可选的尾部，包括消息头字段。

　　消息最后以cRlF结尾。

例如下面就是一个chunked格式的响应体。

　　http/1.1200ok

　　date:

wed,06jul20xx06:

59:

55gmt

　　server:

apache

　　accept-Ranges:

bytes

　　transfer-encoding:

chunked

　　content-type:

text/html

　　content-encoding:

gzip

　　篇三：

实验8tcp协议分析

（2）

　　实验8tcp协议分析

　　6103114095计科143王祥真

　　一、实验目的：

　　1、掌握tcp协议的首部格式。

　　2、掌握tcp协议的序号确认机制。

　　3、掌握tcp协议的流量控制机制。

　　4、学会协议分析软件发送自定义数据包的方法。

　　二、实验原理：

　　tcp协议是面向连接服务和提供可靠数据传输的协议，通过抓包分析tcp的如何建立连接，数据传输，释放连接来分析tcp协议。

　　tcp协议是通过三次握手来建立连接，通过序列号和确认号来维护双方的通信，通过发送窗口的大小来控制流量。

　　通过多台电脑建立一台电脑的tcp连接，可以分析tcp流量控制的实质

　　三、实验设备：

　　服务器一台，pc机一台，交叉线一根。

　　四、实验步骤：

　　1、从实时模式切换到模拟模式，创建pc机连接服务器，并配置服务器和pc机ip地址，服务器ip：

192.168.1.254，pc机ip地址：

192.168.1.252

　　。

　　2、实验结果：

　　2、创建数据包并访问pdu信息窗口

（1）单击web客户端pc-->选择desktop（桌面）选项卡-->打开web浏览器-->在浏览器中输入web服务器的ip地址192.168.1.254-->单击go（转到）将会发出web服务器请求-->最小化web客户端配置窗口。

　　实验结果：

（2）单机（捕获/转发）按钮-->将会显示两个数据包，其中一个的旁边有眼睛图标，这表示该数据包在逻辑拓扑中显示为信封。

（注：

由于时间在模拟模式中是由事件驱动的，所以必须使用capture/Forward（捕获/转发）按钮来显示网络事件）

　　实验结果：

　　（3）在eventlist（事件列表）中找到第一个数据包，然后单击info（信息）列中的彩色正方形，会打开pduinformation（

　　pdu

　　信息）窗口。

　　实验结果：

　　4、入站和出站pdu

　　打开pduinformation（pdu信息）窗口时，默认显示osimodel（osi模型）视图。

此时单击outboundpdudetails（出站pdu详细数据）选项卡。

向下滚动到此窗口的底部。

将会看到http（启动这一系列事件的网页请求）在tcp数据段中封装成数据，然后依次封装到ip数据包和以太网帧，最后作为比特在介质中传输。

　　如果某设备是参与一系列事件的第一台设备，该设备的数据包只有

　　outboundpdudetails（出站pdu详细数据）选项卡；如果是参与一系列事件的最后一台设备，该设备的数据包只有inboundpdudetails（入站pdu详细数据）选项卡。