tcp协议交互.docx

tcp协议交互.docx

《tcp协议交互.docx》由会员分享，可在线阅读，更多相关《tcp协议交互.docx（9页珍藏版）》请在冰豆网上搜索。

tcp协议交互

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

tcp协议交互

　　篇一：

tcp协议交互过程

　　取出项目tcp协议交互过程

　　c：

clients：

server

　　c：

0x21Root\subFolder\subFolder\0结束请求项目目录结构，参数从根项目开始。

s：

0x22返回项目目录结构，从根目录开始。

\0结束，在一条协议命令内完成。

　　。

。

。

more。

。

。

　　如果出现错误则返回0x23，字符串错误信息\0结束。

　　c：

0x31Root\subFolder\0结束请求目录的fileinfo.xml文件。

　　s：

0x32如果一条协议总长度大于8kb时，按每协议文件大于8k字节分包发送协议内容：

　　总长度：

4字节（0表示无内容）；

　　当前包长度4字节（0表示结束）；

　　内容。

。

。

　　如果出现错误则返回0x33，字符串错误信息\0结束。

　　c：

0x41Root\subFolder\0结束请求目录的errorpage.xml文件。

　　s：

0x42如果一条协议总长度大于8kb时，按每协议文件大于8k字节分包发送，连续发发

　　送

　　协议内容：

　　总长度：

4字节（0表示无内容）；

　　当前包长度4字节（0表示结束）；

　　内容。

。

。

　　如果出现错误则返回0x43，字符串错误信息\0结束。

　　c与s循环上述过程直到取得所有文件列表获取完毕

　　c：

0x51发出请求下载文件，xml格式

　　file.htm

　　file.jpg

　　。

。

。

more。

。

。

　　如果一条协议总长度大于8kb时，按每协议文件大于8k字节分包发送，连续发发送。

　　协议内容：

　　总长度：

4字节（0表示无内容）；

　　当前包长度4字节（0表示结束）；

　　内容。

。

。

　　s：

0x52把请求的文件打成zip包发送给客户端。

zip包内的结构为以根项目开始多级子项

　　目结构如果一条协议总长度大于8kb时，按每协议文件大于8k字节分包发送，连续发发送。

　　协议内容：

　　总长度：

4字节（0表示无内容）；

　　当前包长度4字节（0表示结束）；

　　内容。

。

。

　　如果出现错误则返回0x53，字符串错误信息\0结束。

　　结束通讯

　　提交项目

　　c：

0x61提出文件上传请求

　　s：

0x62同意上传。

　　0x63原因\0结束不同意上传

　　c：

0x71发送文件内容，如果一条协议总长度大于8kb时，按每协议文件大于8k字节分

　　包发送，连续发发送

　　协议内容：

　　总长度：

4字节（0表示无内容）；

　　当前包长度4字节（0表示结束）；

　　内容。

。

。

　　把要需要更新的文件以根项目开始的目录结构提交到服务器上。

每一级具有文件的目录都必须带有一个.cms目录，其中存储newfileinfo.xml文件。

文件内容如下：

　　20xx-11-179:

12:

52

　　123456b

　　1

　　目录创建操作

　　c：

0x81目录结构内容

　　字符串：

Root\subFolder\subFolder\r\n

　　Root\subFolder\subFolder\r\n

　　\0结束

　　s:

0x82返回创建成功

　　0x73失败原因\0结束返回创建失败

　　如果服务器上已存在目录则不能创建。

　　删除操作

　　c:

0x91删除内容xml形式表示，字符串\0结束

　　root\subfolder\subfolder

　　root\subfoler\subfolder\file.htm

　　s：

0x92返回成功

　　0x93失败原因字符串\0结束返回失败

　　发布操作

　　c：

0xa1发布配置内容，\0结束发出发布操作。

　　s：

0xa2返回，成功

　　0xa3错误原因\0结束错误原因：

被发布的项目已被锁定、服务已被锁定、找不到项目、服务不存在。

发布过程终止。

　　s:

0xb24字节累计数，服务器返回分析文件个数。

每100个为单位。

　　s：

0xb3错误原因\0结束发布过程终止。

　　s:

0xb4分析结束。

　　s:

0xc24字节累计数，文件转换操作返回，每100个为一单位

　　s:

0xc3错误原因\0结束发布过程终止。

　　s:

0xc4转换结束。

　　s:

0xd2正在压缩

　　s:

0xd3错误原因\0结束发布过程终止。

　　s：

0xd4压缩完成

　　s:

0xe2上传传播发服务器

　　s:

0xe3错误原因\0结束发布过程终止。

　　s：

0xe4上传传播发服务器完成

　　篇二：

tcp协议通讯工作原理

　　tcp协议通讯工作原理

　　一、tcp三次握手

　　传输控制协议（transportcontrolprotocol）是一种面向连接的，可靠的传输层协议。

面向连接是指一次正常的tcp传输需要通过在tcp客户端和tcp服务端建立特定的虚电路连接来完成，该过程通常被称为“三次握手”。

可靠性可以通过很多种方法来提供保证，在这里我们关心的是数据序列和确认。

tcp通过数据分段（segment）中的序列号保证所有传输的数据可以在远端按照正常的次序进行重组，而且通过确认保证数据传输的完整性。

要通过tcp传输数据，必须在两端主机之间建立连接。

举例说明，tcp客户端需要和tcp服务端建立连接，过程如下所示：

　　在第一步中，客户端向服务端提出连接请求。

这时tcpsyn标志置位。

客户端告诉服务端序列号区域合法，需要检查。

客户端在tcp报头的序列号区中插入自己的isn。

服务端收到该tcp分段后，在第二步以自己的isn回应（syn标志置位），同时确认收到客户端的第一个tcp分段（ack标志置位）。

在第三步中，客户端确认收到服务端的isn（ack标志置位）。

到此为止建立完整的tcp连接，开始全双工模式的数据传输过程。

　　二、tcp标志

　　这里有必要介绍一下tcp分段中的标志（Flag）置位情况。

如下图所示:

　　*syn：

同步标志

　　同步序列编号（synchronizesequencenumbers）栏有效。

该标志仅在三次握手建立tcp连接时有效。

它提示tcp连接的服务端检查序列编号，该序列编号为tcp连接初始端（一般是客户端）的初始序列编号。

在这里，可以把tcp序列编号看作是一个范围从0到4，29　　

4，967，295的32位计数器。

通过tcp连接交换的数据中每一个字节都经过序列编号。

在tcp报头中的序列编号栏包括了tcp分段中第一个字节的序列编号。

　　*ack：

确认标志

　　确认编号（acknowledgementnumber）栏有效。

大多数情况下该标志位是置位的。

tcp报头内的确认编号栏内包含的确认编号（w+1，Figure-1）为下一个预期的序列编号，同时提示远端系统已经成功接收所有数据。

　　*Rst：

复位标志

　　复位标志有效。

用于复位相应的tcp连接。

　　*uRg：

紧急标志

　　紧急（theurgentpointer）标志有效。

紧急标志置位，

　　*psh：

推标志

　　该标志置位时，接收端不将该数据进行队列处理，而是尽可能快将数据转由应用处理。

在处理telnet或rlogin等交互模式的连接时，该标志总是置位的。

　　*Fin：

结束标志

　　带有该标志置位的数据包用来结束一个tcp回话，但对应端口仍处于开放状态，准备接收后续数据。

　　三、tcp端口

　　为了能够支持同时发生的并行访问请求，tcp提供一种叫做“端口”的用户接口。

端口是操作系统核心用来识别不同的网络回话过程。

这是一个严格的传输层定义。

通过tcp端口和ip地址的配合使用，可以提供到达终端的通讯手段。

实际上，在任一时刻的互联网络连接可以由4个数

　　字进行描述：

来源ip地址和来源端口，目的ip地址和目的端口。

位于不同系统平台，用来提供服务的一端通过标准的端口提供相应服务。

举例来说，标准的telnet守护进程（telnetdaemon）通过监听tcp23端口，准备接收用户端的连接请求。

　　四、tcp缓存（tcpbacklog）

　　通常情况下，操作系统会使用一块限定的内存来处理tcp连接请求。

每当用户端发送的syn标志置位连接请求到服务端的一个合法端口（提供tcp服务的一端监听该端口）时，处理所有连接请求的内存使用量必须进行限定。

如果不进行限定，系统会因处理大量的tcp连接请求而耗尽内存，这在某种程度上可以说是一种简单的dos攻击。

这块经过限定的，用于处理tcp连接的内存称为tcp缓存（tcpbacklog），它实际上是用于处理进站（inbound）连接请求的一个队列。

该队列保存那些处于半开放（half-open）状态的tcp连接项目，和已建立完整连接但仍未由应用程序通过accept（）调用提取的项目。

如果这个缓存队列被填满，除非可以及时处理队列中的项目，否则任何其它新的tcp连接请求会被丢弃。

　　一般情况下，该缓存队列的容量很小。

原因很简单，在正常的情况下tcp可以很好的处理连接请求。

如果当缓存队列填满的时候新的客户端连接请求被丢弃，客户端只需要简单的重新发送连接请求，服务端有时间清空缓存队列以相应新的连接请求。

　　在现实环境中，不同操作系统支持tcp缓冲队列有所不同。

在bsd结构的系统中，如下所示：

　　五、tcp进站（inbound）处理过程

　　为了更好的讲述tcpsynFlood的攻击过程，我们先来介绍一下正常情况下，tcp进站处理的过程。

　　服务端处于监听状态，客户端用于建立连接请求的数据包（ippacket）按照tcp/ip协议堆栈组合成为tcp处理的分段（segment）。

　　分析报头信息：

tcp层接收到相应的tcp和ip报头，将这些信息存储到内存中。

　　检查tcp校验和（checksum）：

标准的校验和位于分段之中（Figure-2）。

如果检验失败，不返回确认，该分段丢弃，并等待客户端进行重传。

　　查找协议控制块（pcb{}）：

tcp查找与该连接相关联的协议控制块。

如果没有找到，tcp将该分段丢弃并返回Rst。

（这就是tcp处理没有端口监听情况下的机制）如果该协议控制块存在，但状态为关闭，服务端不调用connect（）或listen（）。

该分段丢弃，但不返回Rst。

客户端会尝试重新建立连接请求。

　　建立新的socket：

当处于监听状态的socket收到该分段时，会建立一个子socket，同时还有socket{}，tcpcb{}和pcb{}建立。

这时如果有错误发生，会通过标志位来拆除相应的socket和释放内存，tcp连接失败。

如果缓存队列处于填满状态，tcp认为有错误发生，所有的后续连接请求会被拒绝。

这里可以看出synFlood攻击是如何起作用的。

　　丢弃：

如果该分段中的标志为Rst或ack，或者没有syn标志，则该分段丢弃。

并释放相应的内存。

　　篇三：

http协议与tcp协议简单理解

　　http协议与tcp协议简单理解

　　在c#编写代码，很多时候会遇到http协议或者tcp协议，这里做一个简单的理解。

　　tcp协议对应于传输层，而http协议对应于应用层，从本质上来说，二者没有可比性。

http协议是建立在tcp协议基础之上的，当浏览器需要从服务器获取网页数据的时候，会发出一次http请求。

http会通过tcp建立起一个到服务器的连接通道，当本次请求需要的数据完毕后，http会立即将tcp连接断开，这个过程是很短的。

所以http连接是一种短连接，是一种无状态的连接。

所谓的无状态，是指浏览器每次向服务器发起请求的时候，不是通过一个连接，而是每次都建立一个新的连接。

如果是一个连接的话，服务器进程中就能保持住这个连接并且在内存中记住一些信息状态。

而每次请求结束后，连接就关闭，相关的内容就释放了，所以记不住任何状态，成为无状态连接。

　　随着时间的推移，html页面变得复杂了，里面可能嵌入了很多图片，这时候每次访问图片都需要建立一次tcp连接就显得低效了。

因此keep-alive被提出用来解决效率低的问题。

从http/1.1起，默认都开启了keep-alive，保持连接特性，简单地说，当一个网页打开完成后，客户端和服务器之间用于传输http数据的tcp连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接keep-alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如apache）中设定这个时间。

虽然这里使用tcp连接保持了一段时间，但是这个时间是有限范围的，到了时间点依然是会关闭的，所以我们还把其看做是每次连接完成后就会关闭。

后来，通过session,cookie等相关技术，也能保持一些用户的状态。

但是还是每次都使用一个连接，依然是无状态连接。

　　以前有个概念很容忍搞不清楚。

就是为什么http是无状态的短连接，而tcp是有状态的长连接？

http不是建立在tcp的基础上吗，为什么还能是短连接？

现在明白了，http就是在每次请求完成后就把tcp连接关了，所以是短连接。

而我们直接通过socket编程使用tcp协议的时候，因为我们自己可以通过代码区控制什么时候打开连接什么时候关闭连接，只要我们不通过代码把连接关闭，这个连接就会在客户端和服务端的进程中一直存在，相关状态数据会一直保存着。

　　在c#中会有socket，实际上socket是对tcp/ip协议的封装，socket本身并不是协议，而是一个调用接口（api）。

socket的出现只是使得程序员更方便地使用tcp/ip协议栈而已，是对tcp/ip协议的抽象，从而形成了我们知道的一些最基本的函数接口，比如create、listen、connect、accept、send、read和write等等。

　　比较形象的描述：

http是轿车，提供了封装或者显示数据的具体形式;socket是发动机，提供了网络通信的能力。

对于从c#编程的角度来讲，为了方便，你可以直接选择已经制造好的轿车http来与服务器交互。

但是有时候往往因为环境因素或者其他的一些定制的请求，必须要使用tcp协议，这时就需要使用socket编程，然后自己去处理获取的数据。

就像是你用已有的发动机，自己造了一辆卡车，去从服务器交互。

　　http/1.0和http/1.1都把tcp作为底层的传输协议。

http客户首先发起建立与服务器tcp连接。

一旦建立连接，浏览器进程和服务器进程就可以通过各自的套接字来访问tcp。

如前所述，客户端套接字是客户进程和tcp连接之间的“门”，服务器端套接字是服务器进程和同一tcp连接之间的“门”。

客户往自己的套接字发送http请求消息，也从自己的套接字接收http响应消息。

类似地，服务器从自己的套接字接收http请求消息，也往自己的套接字发送http响应消息。

客户或服务器一旦把某个消息送入各自的套接字，这个消息就完全落入tcp的控制之中。

tcp给http提供一个可靠的数据传输服务;这意味着由客户发出的每个http请求消息最终将无损地到达服务器，由服务器发出的每个http响应消息最终也将无损地到达客户。

　　c#代码连接远程数据库用的是tcp协议。

每次new一个connection的时候，connection.open就打开了这个tcp连接。

connection.close的时候就关闭了这个连接。

Ftp的底层也是tcp，不过是长连接的。

传输大文件比较快。

需要看具体场景。

在服务器端，如果程序是采取的长连接的方式，那么就能控制同时连接到这个服务器的连接个数，防止同时有多个连接。

但是采取短连接的方式，那么就不能控制同时连接到这个服务器上的连接的个数，这也是一个优点，可以同时处理大量连接请求。

但是如果连接请求量太大的话，可能造成服务器停止工作。

　　webservice不需要连接，一秒中至少可以支持上万/十万的请求，每次请求然后释放，没有空余的内存消耗。

一般不会限制同时连接的个数，这是优势。

messagequeue需要建立连接，支持上千的连接就很吃力了。

因为每个连接即使没有在请求数据，也会在内存中占用一定的空间存储。

会限制，比如sqlserver数据库服务器，一般最多同时连接16个。

　　http协议一定通过指定的端口，80，所以一般计算机上不会限制这个端口，所以http协议能够顺利通过所有机器上的防火墙。

而使用socket编程的话，就需要自己指定特定的端口，那么很可能这个端口是在某个环境中禁用的，那么就无法穿透防火墙。

iis使用的是80端口，也就是这个程序一直在监听着这个端口。

一旦发现有人要建立到这个端口的连接，他就会响应，然后建立连接。

这里说的连接都是短连接。

所以你对服务器上的网址的请求，都是通过80端口送到网站程序的。

然后通过这个端口发送的客户端浏览器。