socket
2015-06-17 20:30
246 查看
磨刀不误砍柴工,让我们从概念入手,逐步深入。
所谓socket通常也称作"套接字",用于描述IP地址和端口,是一个通信链的句柄。应用程序通常通过"套接字"向网络发出请求或者应答网络请求。Socket通讯是我们开发多人在线游戏中的常用通讯方式,它主要有流式Socket(SOCK_STREAM)和数据报式Socket(SOCK_DGRAM)两种类别,AS3中我们一般使用的是基于TCP的流式socket,因此本文也主要讲解这一种方式。既然这篇文章主要讲解的是流式socket,那让我们来看看什么是TCP.
TCP是一种流协议(stream protocol)。这就意味着数据是以字节流的形式传递给接收者的,没有固有的"报文"或"报文边界"的概念。
从这方面来说,读取TCP数据就像从串行端口读取数据一样--无法预先得知在一次指定的读调用中会返回多少字节( 也就是说能知道总共要读多少,但是不知道具体某一次读多少, 在AS3中的API表现为 socket. bytesAvailable. )。
为了说明这一点,让我们来看一个例子:我们假设在主机A和主机B的应用程序之间有一条TCP连接,主机A有两条报文D1,D2要发送到B主机,并两次调用send(as3中即flush)来发送,每条报文调用一次。
![](http://bbs.9ria.com/forum.php?mod=image&aid=118288&size=300x300&key=6bed2300de4e3127282b42ab2621147f&nocache=yes&type=fixnone)
那么,我们自然而然的希望两条报文是作为两个独立的实体,在各自的分组中发送,如图1:
![](http://bbs.9ria.com/forum.php?mod=image&aid=118289&size=300x300&key=8f5ea427cb7f45074c19b37940cb4984&nocache=yes&type=fixnone)
这样的话,我们无需做任何特别的处理,便能够很容易的区分每一个独立的数据,并根据需求分别做相应的处理。 但现实往往是有所偏差的,实际的数据传输过程很可能不会遵循这个模型。而是会采用以下四种方式之一进行传输。如图2:
![](http://bbs.9ria.com/forum.php?mod=image&aid=118290&size=300x300&key=802242cc8225056f93c30f4f2df7bbd6&nocache=yes&type=fixnone)
D1和D2数据作为两个独立的分组,分别到达主机B;
D1和D2合为一个整体组,一起到达主机B;
D1的部分数据先到达主机B,剩下的D1数据和D2和在一组到达主机B;
D1和D2的部分数据先到达主机B, D2后到达主机B;
实际上,可能的情况还不止4种。 既 然是深入,那我们来看看为何会产生以上几种传输方式,可能有些开发人员感觉不需要了解这些,但还是极力推荐适当了解,我们要知其然,也要知其所以然,这其 实也为我们后面进行网络编程提供了理论依据和优化思路。言归正题,往下看,让我们来了解下TCP协议,我们知道TCP提供了全双工,可靠的传输服务。
TCP 通过以下方式来提供可靠性:
应用数据被分割成T C P认为最适合发送的数据块。
当TCP发出一个段后,它启动一个定时器,等待目的端确认收到这个报文段。如果不能及时收到一个确认,将重发这个报文段。
当TCP收到发自TCP连接另一端的数据,它将发送一个确认。这个确认不是立即发送,通常将推迟几分之一秒(一般200毫秒左右)。
TCP将保持它首部和数据的检验和。这是一个端到端的检验和,目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错, TCP将丢弃这个报文段和不确认收到此报文段(希望发端超时并重发)。
既然T C P报文段作为I P数据报来传输,而I P数据报的到达可能会失序,因此TCP报文段的到达也可能会失序。如果必要, T C P将对收到的数据进行重新排序,将收到的数据以正确的顺序交给应用层。
既然I P数据报会发生重复, T C P的接收端必须丢弃重复的数据。
TCP 还能提供流量控制。TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据,这将防止较快主机致使较慢主 机的缓冲区溢出,比如,发送方要发送8Kb的数据到接收端,但接收端的缓冲区已经只剩下2K的空间了,那么发送方最多只能发2Kb的数据,那么这时候不得 不把数据拆分发送。
而为了防止网络的拥塞现象,TCP提出了一系列的拥塞控制机制与算法,比如Nagle算法等,这些也可以看做是产生半包,黏包现象的其中一方面因素吧。
基于以上原因,TCP提供的是可靠的字节流服务,它不在字节流中插入记录标识符(当然这里说的是数据本身,而不是为了数据传输底层加入的一些信息,如图3), TCP 对字节流的内容也不作任何解释,它不知道传输的数据字节流是二进制数据,还是ASCII字符或者其他类型数据等,所以,对字节流的解释由TCP连接双方的应用层解释,这也是我们在写socket网络编程中所需 要做的事情。
![](http://bbs.9ria.com/forum.php?mod=image&aid=118291&size=300x300&key=1d1beb4a90f574827a8f80bce9fe62b7&nocache=yes&type=fixnone)
如果想更多更深入了解网络方面的知识,可阅读这本经典书《TCP/IP详解》。 基于以上理论,我们可以来做个实验,使用AIR桌面程序做一个简单的服务端测试程序,以及建立一个AS工程客户端, 客户端和服务端连接成功之后,服务端发送200000次数据给客户端,每次发送一个整形数据后马上调用flush,代码如图4、图5:
![](http://bbs.9ria.com/forum.php?mod=image&aid=118292&size=300x300&key=20152e7bc9cb09536b62187b6f74c5ff&nocache=yes&type=fixnone)
图4
![](http://bbs.9ria.com/forum.php?mod=image&aid=118293&size=300x300&key=014c249af9474536e7c186aab072ae71&nocache=yes&type=fixnone)
图5
当我们运行程序后发现,在200000次发送数据中,其实客户端最终的输出接收数据的次数远远少于200000次;那么这里有个结论:
当程序调用flush发送数据,只是从应用程序维护的一个缓存区拷贝到内核缓冲区,或者是说推入TCP协议栈中就返回了成功的标识,也就是说推进TCP协议栈的数据并不是马上发送的,TCP协议栈有自己的发送和控制策略。 所以这也解释了一些童鞋好奇为什么使用flush函数发送次数和数据接收事件响应次数不相等的原因以及半包、黏包现象产生的原因。
以 上讲的种种理论,最终还是为下面要讲的socket编程作铺垫的,标题写的深入,那么关于如何建立连接方面的这里不作讲解,可自行查阅相关内容,既然上面 我们说了,流式socket是以字节流的形式传输信息的,跟水流一样,没有边界,要做什么操作,传了什么内容,哪里是事情的开头,哪里又是事情的结尾,我 们完全是不知道的,所以我们一般在发送方需要对要传输的数据一定的格式,而接收方则按同样的规则解析这种格式,也就是我们常说的封包和拆包。也就是说我们 处理字节流是以包为单位进行处理的,包的结构一般如下,图6:
![](http://bbs.9ria.com/forum.php?mod=image&aid=118294&size=300x300&key=089f5d6ced0a97c95ea551ef4eaf62a3&nocache=yes&type=fixnone)
图6
一般是包头|Header|+包体|Body|+包尾|End|组成,有时候包尾部分也直接归入Body部分,形成|Header|+|Body|的结构。
包尾部分的信息一般用于校验包的完整性或者合法性等。
包头长度,信息字段的位置一般都是固定的,必须包含的字段一般有“包的长度(packetLen)”和“操作码(cmd)”(如图6),提供长度是为了方面我们解析数据包,而提供操作码是为了让程序知道,该条信息是要做什么操作。除以上两个字段,其他字段根据需要增减。
Socket数据处理流程:
既然上面我们人为的给数据进行了封包,那么我们处理数据就是以包为单位进行处理的。
1、 因为包头|Header|长度固定,当收到数据时,先检验缓冲区有效数据长度,是否大于等于包头长度,如果小于包头长度,则说明数据不够,则继续等待下一次数据的到来, 如果大于包头长度,则读取包头长度的数据,并按一定的格式解析包头数据,从包头中获取到包的长度(packetLen),此时包头处理基本完毕。
2、 根据包头读取到的packetLen,从而计算出包体部分的数据长度(比如bodyLen),再判断缓存区剩余数据长度是否大于等于bodyLen,如果不是,同样等待, 如果是,则从缓存区读出包体部分,进而按照一定的格式读取里面的数据(例如readInt(),readShort()…);此时包数据基本读取完毕!
3、 上面我们说过网络中的字节流没有界线的,因此我们该知道每次到达的数据,也就是缓冲区的数据,有可能不止一个数据包,因此需要循环执行 1,2步。
验证包的完整性和合法性:
之前说过我们在包尾或者是包体的最后位置会适当加上一些信息,来验证包的完整性或者合法性。
举个例子,我们通过一定的规则,把包体的数据位置顺序打乱,最后在包尾加上规则信息,以便接收端能按同样的规则解析还原数据,再通过两端比较,就知道包是否完整和合法等 其实要验证包是否合法,有很多的方法。
比如说判断包头操作码cmd的范围,传的数据长度是否跟包头声明的长度对应,或者整个包长度是否超过最大包的限制等等,不同的人有不同的做法,但目的基本是一样的。
时间有限,代码就不写了。
网络编程优化:
我们知道TCP有一系列的流量控制,网络拥塞控制的处理方案。但在AS3中,Adobe封装的太好了,导致很多底层东西AS目前都碰不了。 唯一我们能给点安慰的,就是基于TCP流量控制这一点上。
来重温一下:
TCP 还能提供流量控制。TCP 连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据,这将防止较快主机致使较慢主机的缓冲区溢出。
因此我们很自然的想到,尽量保持接收方TCP缓冲区有足够的容量,以便较快发送主机能及时发出数据,防止阻塞。
既然这样,那么AS客户端的一般保险处理方式是采取“快读取慢解析”的一种思路,也就是说当有接收到数据,我们会使用ByteArray一次性读取缓冲区的数据,然后再进行解包操作。
不过这里有个疑问,大伙可以研究探讨: Socket 类和ByteArray类同样实现了IDataInput, IdataOutput接口,那是不是socket其实已经实现了跟我们利用ByteArray存取数据的预防措施呢,也就是说内部数据存储部分跟 ByteArray具有同样的实现,如果是的话,那我们是不需要做 (&&)部分提及的把缓存区数据一次性写进 ByteArray后再进行包解析操作的方式,如果不是,那么还是实现 (&&):这一步来得保险,Adobe封装太好了,大伙可以研究下这里。
所谓socket通常也称作"套接字",用于描述IP地址和端口,是一个通信链的句柄。应用程序通常通过"套接字"向网络发出请求或者应答网络请求。Socket通讯是我们开发多人在线游戏中的常用通讯方式,它主要有流式Socket(SOCK_STREAM)和数据报式Socket(SOCK_DGRAM)两种类别,AS3中我们一般使用的是基于TCP的流式socket,因此本文也主要讲解这一种方式。既然这篇文章主要讲解的是流式socket,那让我们来看看什么是TCP.
TCP是一种流协议(stream protocol)。这就意味着数据是以字节流的形式传递给接收者的,没有固有的"报文"或"报文边界"的概念。
从这方面来说,读取TCP数据就像从串行端口读取数据一样--无法预先得知在一次指定的读调用中会返回多少字节( 也就是说能知道总共要读多少,但是不知道具体某一次读多少, 在AS3中的API表现为 socket. bytesAvailable. )。
为了说明这一点,让我们来看一个例子:我们假设在主机A和主机B的应用程序之间有一条TCP连接,主机A有两条报文D1,D2要发送到B主机,并两次调用send(as3中即flush)来发送,每条报文调用一次。
那么,我们自然而然的希望两条报文是作为两个独立的实体,在各自的分组中发送,如图1:
这样的话,我们无需做任何特别的处理,便能够很容易的区分每一个独立的数据,并根据需求分别做相应的处理。 但现实往往是有所偏差的,实际的数据传输过程很可能不会遵循这个模型。而是会采用以下四种方式之一进行传输。如图2:
D1和D2数据作为两个独立的分组,分别到达主机B;
D1和D2合为一个整体组,一起到达主机B;
D1的部分数据先到达主机B,剩下的D1数据和D2和在一组到达主机B;
D1和D2的部分数据先到达主机B, D2后到达主机B;
实际上,可能的情况还不止4种。 既 然是深入,那我们来看看为何会产生以上几种传输方式,可能有些开发人员感觉不需要了解这些,但还是极力推荐适当了解,我们要知其然,也要知其所以然,这其 实也为我们后面进行网络编程提供了理论依据和优化思路。言归正题,往下看,让我们来了解下TCP协议,我们知道TCP提供了全双工,可靠的传输服务。
TCP 通过以下方式来提供可靠性:
应用数据被分割成T C P认为最适合发送的数据块。
当TCP发出一个段后,它启动一个定时器,等待目的端确认收到这个报文段。如果不能及时收到一个确认,将重发这个报文段。
当TCP收到发自TCP连接另一端的数据,它将发送一个确认。这个确认不是立即发送,通常将推迟几分之一秒(一般200毫秒左右)。
TCP将保持它首部和数据的检验和。这是一个端到端的检验和,目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错, TCP将丢弃这个报文段和不确认收到此报文段(希望发端超时并重发)。
既然T C P报文段作为I P数据报来传输,而I P数据报的到达可能会失序,因此TCP报文段的到达也可能会失序。如果必要, T C P将对收到的数据进行重新排序,将收到的数据以正确的顺序交给应用层。
既然I P数据报会发生重复, T C P的接收端必须丢弃重复的数据。
TCP 还能提供流量控制。TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据,这将防止较快主机致使较慢主 机的缓冲区溢出,比如,发送方要发送8Kb的数据到接收端,但接收端的缓冲区已经只剩下2K的空间了,那么发送方最多只能发2Kb的数据,那么这时候不得 不把数据拆分发送。
而为了防止网络的拥塞现象,TCP提出了一系列的拥塞控制机制与算法,比如Nagle算法等,这些也可以看做是产生半包,黏包现象的其中一方面因素吧。
基于以上原因,TCP提供的是可靠的字节流服务,它不在字节流中插入记录标识符(当然这里说的是数据本身,而不是为了数据传输底层加入的一些信息,如图3), TCP 对字节流的内容也不作任何解释,它不知道传输的数据字节流是二进制数据,还是ASCII字符或者其他类型数据等,所以,对字节流的解释由TCP连接双方的应用层解释,这也是我们在写socket网络编程中所需 要做的事情。
如果想更多更深入了解网络方面的知识,可阅读这本经典书《TCP/IP详解》。 基于以上理论,我们可以来做个实验,使用AIR桌面程序做一个简单的服务端测试程序,以及建立一个AS工程客户端, 客户端和服务端连接成功之后,服务端发送200000次数据给客户端,每次发送一个整形数据后马上调用flush,代码如图4、图5:
图4
图5
当我们运行程序后发现,在200000次发送数据中,其实客户端最终的输出接收数据的次数远远少于200000次;那么这里有个结论:
当程序调用flush发送数据,只是从应用程序维护的一个缓存区拷贝到内核缓冲区,或者是说推入TCP协议栈中就返回了成功的标识,也就是说推进TCP协议栈的数据并不是马上发送的,TCP协议栈有自己的发送和控制策略。 所以这也解释了一些童鞋好奇为什么使用flush函数发送次数和数据接收事件响应次数不相等的原因以及半包、黏包现象产生的原因。
以 上讲的种种理论,最终还是为下面要讲的socket编程作铺垫的,标题写的深入,那么关于如何建立连接方面的这里不作讲解,可自行查阅相关内容,既然上面 我们说了,流式socket是以字节流的形式传输信息的,跟水流一样,没有边界,要做什么操作,传了什么内容,哪里是事情的开头,哪里又是事情的结尾,我 们完全是不知道的,所以我们一般在发送方需要对要传输的数据一定的格式,而接收方则按同样的规则解析这种格式,也就是我们常说的封包和拆包。也就是说我们 处理字节流是以包为单位进行处理的,包的结构一般如下,图6:
图6
一般是包头|Header|+包体|Body|+包尾|End|组成,有时候包尾部分也直接归入Body部分,形成|Header|+|Body|的结构。
包尾部分的信息一般用于校验包的完整性或者合法性等。
包头长度,信息字段的位置一般都是固定的,必须包含的字段一般有“包的长度(packetLen)”和“操作码(cmd)”(如图6),提供长度是为了方面我们解析数据包,而提供操作码是为了让程序知道,该条信息是要做什么操作。除以上两个字段,其他字段根据需要增减。
Socket数据处理流程:
既然上面我们人为的给数据进行了封包,那么我们处理数据就是以包为单位进行处理的。
1、 因为包头|Header|长度固定,当收到数据时,先检验缓冲区有效数据长度,是否大于等于包头长度,如果小于包头长度,则说明数据不够,则继续等待下一次数据的到来, 如果大于包头长度,则读取包头长度的数据,并按一定的格式解析包头数据,从包头中获取到包的长度(packetLen),此时包头处理基本完毕。
2、 根据包头读取到的packetLen,从而计算出包体部分的数据长度(比如bodyLen),再判断缓存区剩余数据长度是否大于等于bodyLen,如果不是,同样等待, 如果是,则从缓存区读出包体部分,进而按照一定的格式读取里面的数据(例如readInt(),readShort()…);此时包数据基本读取完毕!
3、 上面我们说过网络中的字节流没有界线的,因此我们该知道每次到达的数据,也就是缓冲区的数据,有可能不止一个数据包,因此需要循环执行 1,2步。
验证包的完整性和合法性:
之前说过我们在包尾或者是包体的最后位置会适当加上一些信息,来验证包的完整性或者合法性。
举个例子,我们通过一定的规则,把包体的数据位置顺序打乱,最后在包尾加上规则信息,以便接收端能按同样的规则解析还原数据,再通过两端比较,就知道包是否完整和合法等 其实要验证包是否合法,有很多的方法。
比如说判断包头操作码cmd的范围,传的数据长度是否跟包头声明的长度对应,或者整个包长度是否超过最大包的限制等等,不同的人有不同的做法,但目的基本是一样的。
时间有限,代码就不写了。
网络编程优化:
我们知道TCP有一系列的流量控制,网络拥塞控制的处理方案。但在AS3中,Adobe封装的太好了,导致很多底层东西AS目前都碰不了。 唯一我们能给点安慰的,就是基于TCP流量控制这一点上。
来重温一下:
TCP 还能提供流量控制。TCP 连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据,这将防止较快主机致使较慢主机的缓冲区溢出。
因此我们很自然的想到,尽量保持接收方TCP缓冲区有足够的容量,以便较快发送主机能及时发出数据,防止阻塞。
既然这样,那么AS客户端的一般保险处理方式是采取“快读取慢解析”的一种思路,也就是说当有接收到数据,我们会使用ByteArray一次性读取缓冲区的数据,然后再进行解包操作。
不过这里有个疑问,大伙可以研究探讨: Socket 类和ByteArray类同样实现了IDataInput, IdataOutput接口,那是不是socket其实已经实现了跟我们利用ByteArray存取数据的预防措施呢,也就是说内部数据存储部分跟 ByteArray具有同样的实现,如果是的话,那我们是不需要做 (&&)部分提及的把缓存区数据一次性写进 ByteArray后再进行包解析操作的方式,如果不是,那么还是实现 (&&):这一步来得保险,Adobe封装太好了,大伙可以研究下这里。
相关文章推荐
- 多线程03-NSOperationQueue(掌握)
- BS CS的区别
- java try catch finally中的return问题
- scp协议原理
- 正则表达式
- 初识JAVA
- 团队开发------第一次冲刺第2天
- Container with most water
- 生产者-消费者问题
- JDK中的Date类的小误区和获取自定义日期的号数和毫秒转日期
- js--小结③
- ReactiveCocoa & MVVM 学习总结二
- Qt学习笔记003 2015/6/17
- nim和面向对象(一)
- MDaemon空间不足如何搬家
- Oracle常用的性能诊断语句
- leetcode--ValidateBinarySearchTree
- 归并排序的实现
- tomcat服务器解析(七)-- Processor&Endpoint&ProtocolHandler
- 在没有安装office2010的64位系统上C#读取excel内容出现 'Microsoft.Jet.OLEDB.4.0' provider is not registered on the loca