网络原理-集线器,网桥,交换机,路由器,网关详解

    目前,科技的发展,很多网络设备的界限也越来越模糊。比如集线器和交换机之间的界限已变得模糊,交换机也出现了3层交换机(有网络层模块),4层交换机(有传输层模块)。本文主要整理一些典型的网络设备及其功能比较。

核心总结:

1、hub(集线器)就是物理层的,会面向全端口转发物理层的包。当然因为全部转发会造成网络堵塞,所以hub还顺带集成了CSMA/CD,碰撞检测模块。
2、网桥,主要是为了hub的不足,工作在数据链路层,检测数据包mac地址,对数据包进行特定端口转发,避免造成网络堵塞。
3、交换机。一般指常见的二层交换机,工作在数据链路层。功能和网桥差不多。区别就是,网桥只有两个端口,只能连接两个子网。而交换机端口多,可以连接的子网多。
4、路由器,工作在网络层。对ip数据包进行路由转发。
5、网关,工作在应用层。仅用于两个高层协议不同的网络互连

1、HUB(集线器)


HUB是一个多端口的转发器,在以HUB为中心设备时,即使网络中某条线路产生了故障,并不影响其它线路的工作。所以HUB在局域网中得到了广泛的应用。

HUB按照对输入信号的处理方式上,可以分为无源HUB、有源HUB、智能HUB。

大多数的时候它用在星型与树型网络拓扑结构中,以RJ45接口与各主机相连(也有BNC接口)。在这方面,集线器所起的作用相当于多端口的中继器。其实,集线器实际上就是中继器的一种,其区别仅在于集线器能够提供更多的端口服务,所以集线器又叫多口中继器
集线器工作于OSI/RM参考模型的物理层和数据链路层的MAC(介质访问控制)子层。物理层定义了电气信号,符号,线的状态和时钟要求,数据编码和数据传输用的连接器。因为集线器只对信号进行整形、放大后再重发,不进行编码,所以是物理层的设备。10M集线器在物理层有4个标准接口可用,那就是:10BASE-5、10BASE-2、10BASE-T、10BASE-F。10M集线器的10BASE-5(AUI)端口用来连接层1和层2。

集线器(HUB),它是工作在物理层的设备, 由于它只是工作在物理层的设备,所以它并不关心也不可能关心OSI上面几层所涉及的,它的工作机制流程是:从一个端口接收到数据包时,会在其他端口把这个 包转发一次,因为它不知道也不可能知道这个包是发给谁的(物理层设备只关心电压这些物理概念),它也只能对所有人广播(这里和下文提到的 广播该词的意思和ARP请求时的广播有些不同,这里的广播意思是:使用物理层转发设备,如HUB,导致的广播,可以说这个广播是被逼的,因为设备的问题! 是设备转发包引起的广播!而ARP请求的广播是自己要求的,主动的,因为ARP请求包的目标地址IP是255.255.255.255,但ARP请求的广 播涉及IP层的知识,不在这篇文章讨论的范围,所以这里提到的广播,除非特别说明,否则都是第一个意思,也就说是”因设备转发数据包引起的广播” ),让他们自己处理了。

  这样一来会有不少问题,你发的数据其他人都收到了,私隐这总东西是不存在的!别入可以随便监听你信息!所以会话劫持在那个年代相当容易(记得俺第一次接触会话劫持这个概念的时候还是高2,那是2001~2002,呵,那时候集线器还是比较普遍的)。

  另外一个比较严重的问题是,如果一个大型的局域网,比如有500台机器,全部用HUB连接的,后果会怎么样呢??相当慢,网络的效率极差!为什么?如果500台机器都发一个包,那就是说每台机器,都需要接收差不多499个无用包…并且如果是需要回应的话……无用的数据包会充斥着整个的局域网,这就是传说中的广播风暴!

        为了侦测广播风暴,集线器采用了CSMA/CD(载波帧听多路访问/冲突检测)协议,CSMA/CD为MAC层协议,所以集线器也含有数据链路层的内容。但HUB本身不能识别MAC 地址和IP地址。

  为了减少广播风暴,网桥产生了(注意这里用的时候“减少”,不是“杜绝”,仅仅是减少!如果仅仅用网桥说能杜绝广播风暴,个人觉得还是不太准确,后来交换机的出现才可以说是完全杜绝了广播风暴的发生)!

  在介绍网桥之前,还想简单介绍另一个物理层的设备:“中继器”,这种设备的作用是把物理层传输的信号放大,由于长距离的传输,信号会有一定的损耗的,这种设备主要解决的就是这个问题。它和HUB的区别是:HUB主要是为了在物理层上转发数据的,所以它不关心电压值的大小,也不会放大物理信号;而中继器它的作用就是为了放大信号用的,SO…..

核心总结:有源/无源HUB工作在物理层,智能HUB覆盖物理层、链路层、网络层。依据IEEE 802.2协议,集线器功能是随机选出某一端口的设备,并让它独占全部带宽,与集线器的上联设备(交换机、路由器或服务器等)进行通信。

简单来说:HUB收到网络信号时,因为工作在物理层(智能HUB可以路由这里不考虑,有源HUB会对收到的网络信号进行放大或再生,无源HUB不会),所以HUB会无脑转发该网络信号到其他所有处于工作状态的端口上。

2、网桥


网桥也叫桥接器,是连接两个局域网的一种存储/转发设备,它能将一个大的LAN分割为多个网段,或将两个以上的LAN互联为一个逻辑LAN,使LAN上的所有用户都可访问服务器。
网桥可以是专门硬件设备,也可以由计算机加装的网桥软件来实现,这时计算机上会安装多个网络适配器(网卡)。
网桥的功能在延长网络跨度上类似于中继器,然而它能提供智能化连接服务,即根据帧的终点地址处于哪一网段来进行转发和滤除。网桥对站点所处网段的了解是靠“自学习”实现的,有透明网桥、转换网桥、封装网桥、源路由选择网桥。网桥示意如图1所示。

网桥工作在数据链路层,将两个LAN连起来,根据MAC地址来转发帧,可以看作一个“低层的路由器”(路由器工作在网络层,根据网络地址如IP地址进行转发)。

在网络互联中起到数据接收、地址过滤与数据转发的作用,用来实现多个网络系统之间的数据交换。
网桥的基本特征
1.网桥在数据链路层上实现局域网互连;
2.网桥能够互连两个采用不同数据链路层协议、不同传输介质与不同传输速率的网络
3.网桥以接收、存储、地址过滤与转发的方式实现互连的网络之间的通信;
4.网桥需要互连的网络在数据链路层以上采用相同的协议
5.网桥可以分隔两个网络之间的通信量,有利于改善互连网络的性能与安全性。

网桥连接不同网段的探讨:
首先网桥和普通的二层交换机都不具备网络层功能,也就是不能给网段上的pc机分配IP地址,然后一个网段只能有一个出口负责管理和外界连接,因为网段某节点pc发送的ARP请求,只能得到一个路由器的响应并分配ip。按照这样的推理。网桥连接的两个网段,只有一个地方的网段,连接有路由器并负责和外网进行数据交流。在路由器看来,内网是透明的,感觉就只有一个局域网。(上文的网段,应该就是网络分段的意思)

3、交换机


二层交换机工作于OSI参考模型的第二层,即数据链路层

交换机内部的CPU会在每个端口成功连接时,通过将MAC地址和端口对应,形成一张MAC表。在今后的通讯中,发往该MAC地址的数据包将仅送往其对应的端口,而不是所有的端口。因此交换机可用于划分数据链路层广播,即冲突域;但它不能划分网络层广播,即广播域

具体可分为:

  • 直通转发(cut-through):数据包的前6个字节(MAC地址)一到达交换机,即确定目的地址,向相应端口转发该数据包。这时可能该数据包在接收端口还没有传输完。适用于网络质量好,误码率低的情形。
  • 存储转发(store-and-forward):交换机把收到的完整数据包暂存,然后检查其校验和或其他;通过检验的数据包再读取其目的地址,向相应端口转发。
  • 无帧(fragment-free):基本类似于直通转发。但对数据包的前64个字节做存储-校验-转发。因为大部分误码、碰撞(collision)发生在数据包头64字节。

通常,交换机采取直通转发,如果误码率上升到某个阈值,再改用存储转发。

当一台交换机安装配置好之后,其工作过程如下:

  • 收到某网段(设为A)MAC地址为X的计算机发给MAC地址为Y的计算机的数据包。交换机从而记下了MAC地址X在网段A。这称为学习(learning)。
  • 交换机还不知道MAC地址Y在哪个网段上,于是向除了A以外的所有网段转发该数据包。这称为泛洪(flooding)。
  • MAC地址Y的计算机收到该数据包,向MAC地址X发出确认包。交换机收到该包后,从而记录下MAC地址Y所在的网段。
  • 交换机向MAC地址X转发确认包。这称为转发(forwarding)。
  • 交换机收到一个数据包,查表后发现该数据包的来源地址与目的地址属于同一网段。交换机将不处理该数据包。这称为过滤(filtering)。
  • 交换机内部的MAC地址-网段查询表的每条记录采用时间戳记录最后一次访问的时间。早于某个阈值(用户可配置)的记录被清除。这称为老化(aging)。

对于全交换(full-switch)局域网,交换机每个端口只连接一台设备,因此不会发生碰撞。交换机也不需要做过滤。

分类:

传统交换机(二层交换机)

交换机被广泛应用于二层网络交换。中档的网管型交换机还具有VLAN划分、端口自动协商、MAC访问控制列表等功能,并提供命令行界面图形界面控制台,供网络管理员调整参数

网桥和二层交换机的区别

交换机与网桥的区别(这里说的交换机就是我们常见的最普通的二层交换机)
局域网交换机的基本功能与网桥一样,具有帧转发、帧过滤和生成树算法功能。但是,交换机与网桥相比还是存在以下不同:
(1)交换机工作时,实际上允许许多组端口间的通道同时工作。所以,交换机的功能体现出不仅仅是一个网桥的功能,而是多个网桥功能的集合。即网桥一般分有两个端口,而交换机具有高密度的端口。
(2)分段能力的区别
由于交换机能够支持多个端口,因此可以把网络系统划分成为更多的物理网段,这样使得整个网络系统具有更高的带宽。而网桥仅仅支持两个端口,所以,网桥划分的物理网段是相当有限的。
(3)传输速率的区别
交换机与网桥数据信息的传输速率相比,交换机要快于网桥。
(4)数据帧转发方式的区别
网桥在发送数据帧前,通常要接收到完整的数据帧并执行帧检测序列FCS后,才开始转发该数据帧。交换机具有存储转发和直接转发两种帧转发方式。直接转发方式在发送数据以前,不需要在接收完整个数据帧和经过32bit循环冗余校验码CRC的计算检查后的等待时间。

三层交换机

三层交换机则可以处理第三层网络层协议,用于连接不同网段,通过对缺省网关的查询学习来创建两个网段之间的直接连接。

三层交换机具有一定的“路由”功能,但只能用于同一类型的局域网子网之间的互连。这样,三层交换机可以像二层交换机那样通过MAC地址标识数据包,也可以像传统路由器那样在两个局域网子网之间进行功能较弱的路由转发,它的路由转发不是通过软件来维护的路由表,而是通过专用的ASIC芯片处理这些转发;

四层交换机

四层交换机可以处理第四层传输层协议,可以将会话与一个具体的IP地址绑定,以实现虚拟IP [1] ;

七层交换器

更加智能的交换器,可以充分利用频宽资源来过滤,识别和处理应用层数据转换的交换设备。

二层交换机与集线器的区别

交换机与集线器不同之处是,集线器会将网络内某一用户发送的数据包传至所有已连接到集线器的电脑。而交换机则只会将数据包发送到指定目的地的电脑(透过MAC表),相对上能减少数据碰撞及数据被窃听的机会。交换机更能将同时传到的数据包分别处理,而集线器则不能。

最大的不同之处在于:集线器的每一个接口都处于相同的冲突域,而交换机的每个接口处于一个冲突域。在性能方面尤为突出:例如在100Mb/s的以太网络中有100个用户,使用集线器,每个用户只有1Mb/s(100Mb/s/100),因为Hub是共享式的网络;而使用交换机,每个接口有100Mb/s,如果有100个接口,总带宽为100*100Mb/s(最终的带宽大小取决于输入接口的带宽;即如果输入端口只有10000M,则达到上限前,每个用户都能使用100M带宽,但一旦所有用户的总需求超过10000M,用户将在相同优先级的原则下进行带宽分配),因为交换机是独立式的网络。

二层交换机与路由器的区别

从时间线上看,路由器诞生于交换机之后,为了弥补交换机不能定向转发数据包的缺陷。

“交换”一词最早出现于电话系统,指两个不同电话交换机之间语音信号的交换。故从本意上讲,交换是完成信号由交换设备入口至出口的转发的技术的统称。路由器名称中的“路由”(router)来自于路由器的转发策略–路由选择(routing)。交换机和路由器的区别有但不局限于以下几点(这里的交换机和路由器都是常规型号的):

1.两者工作在OSI模型的不同层次上
交换机工作在OSI模型第二层数据链路层,路由器工作在OSI模型第三层网络层。网络层提供更多的协议信息,方便路由器做出更加智能的转发选择。
2.两者转发时所依据的对象不同
交换机是基于MAC地址识别,实现封装数据包转发。路由器基于网络ID号(IP地址)。MAC一般被固化在网卡中,不可更改。而IP地址可以被系统或网络管理员进行设置和分配。
3.两者转发广播数据包的域不同
被交换机连接起来的网络属于同一广播域,广播数据包会在网络内所有网段上进行传播。连接在路由器上的网段则被分区为不同广播域,广播数据包只在各自广播域内传播而无法穿透路由器。路由器的这种子网隔离功能可以在一定程度上防止广播风暴。

三层交换机与路由器的区别

虽然三层交换机与路由器都具有路由转发功能,二者都运行在OSI模型的第三层,即网络层,但是二者并不等同,适用范围也不同,不会相互替代。

1.主打功能不同
三层交换机的主打的功能点是二层交换技术,并附加一点路由转发功能。路由器的主打功能是路由转发,并可能附加一些备用功能,比如硬件防火墙、二层交换技术等其它功能。
2.适用环境不同
三层交换机的路由转发功能一般都比较粗略,由于它一般用在简单的接入网的连接。它在以太网中的主要作用还是提供快速的二层数据交换,功能特点还是针对频繁的以太网数据交换。
路由器的设计初衷就是为了跨网段连接。尽管它也能在局域网内用于连接网络,但是它的路由转发功能主要用于不同类型网络之间,例如连接局域网广域网,连接以太网令牌环网。它的主打功能就是路由转发,专业处理复杂路由路径和复杂的网络连接。因此,路由器的路由转发功能,比三层交换机强大得多。路由器的优势是能够选择最佳路由、负荷分担、链路备份以及与其他网络进行路由信息的交换等功能。为了能够适应各种类型的网络,路由器的接口类型非常丰富,例如以太网接口、令牌环网接口、WLAN网卡、光纤接口等等。三层交换机一般只有以太网接口。
3.性能不同
三层交换机的路由转发是由硬件实现的,使用专用ASIC芯片来处理路由转发。路由器的路由转发是由软件实现的,在CPU中运行一段程序来处理路由转发。
所以三层交换机的转发效率会高过路由器,但是路由转发的功能都比较弱,由于路由转发功能是固化在硬件中的,不具有软件可扩展性,也就不会具有路由器的附加功能(例如防火墙功能)。

四、路由器


路由器英语:Router,又称路径器)是一种电讯网络设备,提供路由转送两种重要机制,可以决定数据包从来源端到目的端所经过的路由路径(host到host之间的传输路径),这个过程称为路由;将路由器输入端的数据包移送至适当的路由器输出端(在路由器内部进行),这称为转送。路由工作在OSI模型的第三层——即网络层,例如网际协议(IP)。
用于连接多个逻辑上分开的网络,所谓逻辑网络是代表一个单独的网络或者一个子网。当数据从一个子网传输到另一个子网时,可通过路由器的路由功能来完成。因此,路由器具有判断网络地址和选择IP路径的功能,它能在多网络互联环境中,建立灵活的连接,可用完全不同的数据分组和介质访问方法连接各种子网,路由器只接受源站或其他路由器的信息,属网络层的一种互联设备。

路由器的结构

路由器从功能上可以划分为:路由选择和分组转发。
分组转发结构由三个部分组成:交换结构、一组输入端口和一组输出端口。

路由器分组转发流程

从数据报的首部提取目的主机的 IP 地址 D,得到目的网络地址 N。
若 N 就是与此路由器直接相连的某个网络地址,则进行直接交付;
若路由表中有目的地址为 D 的特定主机路由,则把数据报传送给表中所指明的下一跳路由器;
若路由表中有到达网络 N 的路由,则把数据报传送给路由表中所指明的下一跳路由器;
若路由表中有一个默认路由,则把数据报传送给路由表中所指明的默认路由器;
否则报告转发分组出错。

路由选择协议

路由选择协议都是自适应的,能随着网络通信量和拓扑结构的变化而自适应地进行调整。
互联网可以划分为许多较小的自治系统 AS,一个 AS 可以使用一种和别的 AS 不同的路由选择协议。
可以把路由选择协议划分为两大类:

  • 自治系统内部的路由选择:RIP 和 OSPF
  • 自治系统间的路由选择:BGP

1. 内部网关协议 RIP

RIP 是一种基于距离向量的路由选择协议。距离是指跳数,直接相连的路由器跳数为 1。跳数最多为 15,超过 15 表示不可达。

RIP 按固定的时间间隔仅和相邻路由器交换自己的路由表,经过若干次交换之后,所有路由器最终会知道到达本自治系统中任何一个网络的最短距离和下一跳路由器地址。

距离向量算法:

  • 对地址为 X 的相邻路由器发来的 RIP 报文,先修改报文中的所有项目,把下一跳字段中的地址改为 X,并把所有的距离字段加 1;
  • 对修改后的 RIP 报文中的每一个项目,进行以下步骤:
  • 若原来的路由表中没有目的网络 N,则把该项目添加到路由表中;
  • 否则:若下一跳路由器地址是 X,则把收到的项目替换原来路由表中的项目;否则:若收到的项目中的距离 d 小于路由表中的距离,则进行更新(例如原始路由表项为 Net2, 5, P,新表项为 Net2, 4, X,则更新);否则什么也不做。
  • 若 3 分钟还没有收到相邻路由器的更新路由表,则把该相邻路由器标为不可达,即把距离置为 16。

RIP 协议实现简单,开销小。但是 RIP 能使用的最大距离为 15,限制了网络的规模。并且当网络出现故障时,要经过比较长的时间才能将此消息传送到所有路由器。

2. 内部网关协议 OSPF

开放最短路径优先 OSPF,是为了克服 RIP 的缺点而开发出来的。

开放表示 OSPF 不受某一家厂商控制,而是公开发表的;最短路径优先表示使用了 Dijkstra 提出的最短路径算法 SPF。

OSPF 具有以下特点:

  • 向本自治系统中的所有路由器发送信息,这种方法是洪泛法。
  • 发送的信息就是与相邻路由器的链路状态,链路状态包括与哪些路由器相连以及链路的度量,度量用费用、距离、时延、带宽等来表示。
  • 只有当链路状态发生变化时,路由器才会发送信息。

所有路由器都具有全网的拓扑结构图,并且是一致的。相比于 RIP,OSPF 的更新过程收敛的很快。

3. 外部网关协议 BGP

BGP(Border Gateway Protocol,边界网关协议)

AS 之间的路由选择很困难,主要是由于:

  • 互联网规模很大;
  • 各个 AS 内部使用不同的路由选择协议,无法准确定义路径的度量;
  • AS 之间的路由选择必须考虑有关的策略,比如有些 AS 不愿意让其它 AS 经过。

BGP 只能寻找一条比较好的路由,而不是最佳路由。

每个 AS 都必须配置 BGP 发言人,通过在两个相邻 BGP 发言人之间建立 TCP 连接来交换路由信息。

五、网关


网关(Gateway)又称网间连接器、协议转换器。默认网关在网络层上以实现网络互连,是最复杂的网络互连设备,仅用于两个高层协议不同的网络互连。网关的结构也和路由器类似,不同的是互连层。网关既可以用于广域网互连,也可以用于局域网互连 
【说明:由于历史的原因,许多有关TCP/IP的文献曾经把网络层使用的路由器称为网关,在今天很多局域网采用都是路由来接入网络,因此通常指的网关就是路由器的IP!】 
OSI中,网关有两种:一种是面向连接的网关,一种是无连接的网关。当两个子网之间有一定距离时,往往将一个网关分成两半,中间用一条链路连接起来,我们称之为半网关。
按照不同的分类标准,网关也有很多种。TCP/IP协议里的网关是最常用的,在这里我们所讲的“网关”均指TCP/IP协议下的网关。
那么网关到底是什么呢?网关实质上是一个网络通向其他网络的IP地址。比如有网络A和网络B,网络A的IP地址范围为“192.168.1.1~192. 168.1.254”,子网掩码为255.255.255.0;网络B的IP地址范围为“192.168.2.1~192.168.2.254”,子网掩码为255.255.255.0。在没有路由器的情况下,两个网络之间是不能进行TCP/IP通信的,即使是两个网络连接在同一台交换机(或集线器)上,TCP/IP协议也会根据子网掩码(255.255.255.0)判定两个网络中的主机处在不同的网络里。而要实现这两个网络之间的通信,则必须通过网关。如果网络A中的主机发现数据包的目的主机不在本地网络中,就把数据包转发给它自己的网关,再由网关转发给网络B的网关,网络B的网关再转发给网络B的某个主机(如附图所示)。网络A向网络B转发数据包的过程。
所以说,只有设置好网关的IP地址,TCP/IP协议才能实现不同网络之间的相互通信。那么这个IP地址是哪台机器的IP地址呢?网关的IP地址是具有路由功能的设备的IP地址,具有路由功能的设备有路由器、启用了路由协议的服务器(实质上相当于一台路由器)、代理服务器(也相当于一台路由器)。
在和 Novell NetWare 网络交互操作的上下文中,网关在 Windows 网络中使用的服务器信息块 (SMB) 协议以及NetWare网络使用的 NetWare 核心协议 (NCP) 之间起着桥梁的作用。网关也被称为 IP路由器。

整理自:百度百科、维基百科、https://www.cnblogs.com/hyddd/archive/2009/01/18/NetWorking.html

网络原理-计算机网络详解-入门必备常识

基本常识

局域网一定要路由器吗?

局域网需要连接到 因特网 那是肯定是需要路由器的 内网 到 外网 中间肯定是要有 NAT 网关才可以上网的。 呵呵 而且还要到电信部门申请一条宽带线。
如果不连因特网是不用路由器的,用交换机或者集线器都行
如果是两台电脑直接连的话,也不需要 hub和交换机。具体分析看这里

 

宽带也是分为:上行带宽 和下行带宽的。当你模拟电话拨号上网时,
V90 协议,电话拨号上网(下行56kbps,上行33.6kbps)
V92协议 电话拨号上网(下行 56kbps 上行48kbps)

以太网就是无线网吗

不是。
以太网是指802.3标准的有线网络标准,通常的介质是铜线,如CAT5/CAT6等,但也可以用光纤。
以太网速率有10Mbps/100Mbps/1Gbps/10Gbps/40Gbps等。
无线网通常指的是WiFi,是一种无线网络,遵循802.11系列标准,如802.11 a/b/g/n/ac等,速率有1Mbps/11Mbps/54Mbps/300Mbps/1Gbps等

家用的网线:传递的数字信号,原理是:详情链接

rj45网线中,单方向传输信号都是一对导线,里面用的是差分信号,传递给对方的是电压变化 信号。【双绞线 可以 屏蔽 外界的 电磁干扰,抗干扰强】

数字电路:从 单端信号 发展到 差分信号

单端信号
早期的数字总线大部分使用单端信号做信号传输,如TTL/CMOS信号都是单端信号。所谓单端信号,是指用一根信号线的高低电平的变化来进行0、1信息的传输,这个电平的高低变化是相对于其公共的参考地平面的。单端信号由于结构简单,可以用简单的晶体管电路实现,而且集成度高、功耗低,因此在数字电路中得到最广泛的应用。

大白话:单端信号 用一根线 接地,另一根 传递 电压 高低变化,当然也是 单方向 传输啦。

异步传输与同步传输分析  参考链接 

数据链路层为什么要分层?

     这个问题和前面讲到的有很大关系:(1)半双工模式下(说的是以太网)采用的是CSMA/CD的访问方式(2)全双工模式下则可直接收发,不管线路的忙闲状态。半双工和全双工是物理层的概念,而针对物理层的双工模式提供不同的访问方式则是数据链路层的概念。因此:数据链路层和物理层是相关的。为了针对物理层的不同工作模式进行访问,后来提出了逻辑链路控制子层(LLC)和媒体访问控制子层(MAC)。这样:不同的屋里层对应不同的MAC子层,LLC子层则完全独立。

 

1、网线说明

双绞线情况,有许多种不同的标准适用于这种基于的线的物理媒介。最广泛使用的包括10BASE-T100BASE-TX1000BASE-T (吉比特以太网), 速率分别为10 Mbit/s, 100 Mbit/s, and 1000 Mbit/s (1 Gbit/s)。这三种标准都使用相同的连接头。也有适用于光纤的以太网。以前家里常见的是100BASE-TX(熟称cat5;五类线),支持100M/s,使用4根线(8根线用了4根线,其他4根线没有用),等于两对线,一对线用于输出数字信号,一对线用于接收数字信号,实现全双工。目前常见的是cat5e(超5类线,可以传1000M/s

以太网在使用双绞线作为传输介质时只需要2对(4芯)线就可以完成信号的发送和接收。在使用双绞线作为传输介质的快速以太网中存在着三个标准:100Base-TX、100Base-T2和100Base-T4。其中:100Base-T4标准要求使用全部的4对线进行信号传输,另外两个标准只要求2对线。而在快速以太网中最普及的是100Base-TX标准,所以你在购买100M网络中使用的双绞线时,不要为图一点小便宜去使用只有2个线对的双绞线。在美国线缆标准(AWG)中对3类、4类、五类和超五类双绞线都定义为4对,在千兆位以太网中更是要求使用全部的4对线进行通信。所以,标准五类线缆中应该有4对线。

 

2、将网络接入速度为64Kbps(最大下载速度为8KB/S)及其以下的网络接入方式称为“窄带”,相对于宽带而言窄带的缺点是接入速度慢。(计算方式64/8[bit] =8KBytes/s) 
从2010年世界电信日(5.17)开始,不到4M一概称为窄带,只有4M或以上才能被称为宽带
纯粹的以64kbps这个数字来区分窄带和宽带是武断模糊的。这只是一个传输速率,而不能代表频谱宽度。要理解通信意义上的“宽带”而不是运营商提供的那种“ADSL宽带

3、网线中传输的是数字信号还是模拟信号?

网线的传输当然是数字信号了。当然前提是使用网线传输网络信号。(这里的网线指连接pc机的网线,因为网线连接猫时,会发生数模转换,如果 外面接入的是电话线,那会转换成模拟电信号。如果外面接入的是光纤,则会转换成数字光信号)

之所以这样说,是因为在某些场合网线是被当做8芯电线用来传输很多种不同信号,所以就不能确定网线里面一定传输的是数字信号。
比如模拟视频监控中,有使用网线做视频信号传输或者做音频线传输拾音器的音频信号,这时网线传输的就是模拟信号。又如网线也经常被用来传输485信号或者232信号,因为485只用都两芯,所以同时又传输有电话信号或者其他模拟信号,这时就是数字模拟信号同时传输了。
因此判断网线传输信号的类型要根据它的用途来确定。

4、调制解调器是一种计算机硬件,它能把计算机的数字信号翻译成可沿普通电话线传送的模拟信号,而这些模拟信号又可被线路另一端的另一个调制解调器接收,并译成计算机可懂的语言。这一简单过程完成了两台计算机间的通信。
调制解调器是Modulator(调制器)与Demodulator(解调器)的简称,中文称为调制解调器(港台称之为数据机),根据Modem的谐音,亲昵地称之为“猫”。它是在发送端通过调制将数字信号转换为模拟信号,而在接收端通过解调再将模拟信号转换为数字信号的一种装置。

所谓调制,就是把数字信号转换成电话线上传输的模拟信号;解调,即把模拟信号转换成数字信号。合称调制解调器。

调制解调器的英文是MODEM,它的作用是模拟信号和数字信号的“翻译员”。电子信号分两种,一种是”模拟信号“,一种是”数字信号“。我们使用的电话线路传输的是模拟信号,而PC机之间传输的是数字信号。所以当你想通过电话线把自己的电脑连入Internet时,就必须使用调制解调器来”翻译”两种不同的信号。连入Internet后,当PC机向Internet发送信息时,由于电话线传输的是模拟信号,所以必须要用调制解调器来把数字信号“翻译”成模拟信号,才能传送到Internet上,这个过程叫做”调制”。当PC机从Internet获取信息时,由于通过电话线从Internet传来的信息都是模拟信号,所以PC机想要看懂它们,还必须借助调制解调器这个“翻译”,这个过程叫作“解调”。总的来说就称为“调制解调”。

5、数字电话与模拟电话
数字电话就是语音信号处理采用数字电路方式而非模拟方式的电话,优点是语音清晰度以及抗干扰能力、保密性能等提高很多。家里用的普通有线电话机都是模拟机,这种座机目前还很少数字型的,因为电信公司的设备都还是模拟的,数字型一般用在无线子母机上,用于子机与母机之间的通讯,但母机与电信局的通讯还是模拟方式。

普通的固定电话机是模拟信号,市内通话不变成数字信号,如果用卡打长途电话或非直拨长途电话,则模拟信号在电话局内转换成数字信号,在通信线路上传播,到目的地电话局再还原成模拟信号。

6、串行通信与并行通信
串行接口简称串口,也称串行通信接口或串行通讯接口(通常指COM接口),是采用串行通信方式的扩展接口。串行通信是指 使用一条数据线,将数据一位一位地依次传输,每一位数据占据一个固定的时间长度。其只需要少数几条线就可以在系统间交换信息,特别适用于计算机与计算机、计算机与外设之间的远距离通信。

USB是英文 Universal Serial Bus 的缩写,翻译成中文的含义是“通用串行总线”。

上网属于串行通信。
串行信号指的是同一时刻点,两设备之间指存在一个数据脉冲进行收发。而每根电缆里面,同一时刻只有一个数据脉冲,可以传输较远距离。这样,并行线至少要求有一大排线,传输距离非常有限,电话线只有两根,所以是串行信号通信。(从pc的网卡出去到服务器的网卡前,至于计算机内部看了下百科–>数据总线是并行的,所以内部应该是并行传网络数据的,备注:需要去看看《微机原理》)

家用的网线是串行传输数字信号,里面用差分信号技术来传输电压变化信息。

在计算机和终端之间的数据传输通常是靠电缆或信道上的电流或电压变化实现的。如果一组数据的各数据位在多条线上同时被传输,这种传输方式称为并行通信。比如,老式打印机同电脑之间。

并行接口与CPU的连接
数据总线:是CPU与并行接口进行数据交换的通道。

⑵读出写入信号线:控制数据流向,确定操作是读还是写。
⑶复位线,准备好状态线:并行接口数据准备就绪。
中断请求线:并行接口向CPU进行中断请求。
⑸地址译码电路:进行选择不同的接口电路,选择接口电路内部不同的寄存器
并行接口
控制寄存器:接收CPU发来的控制命令。
⑵数据输入缓冲器、数据输出缓冲器:进行数据的输入、输出。
状态寄存器:提供接口电路工作状态供CPU查询。

7、ISDN与PSTN的区别是什么?

ISDN是综合业务数字网的简称,它由电话综合数字网(IDN)发展而来。ISDN是数字交换和数字传输的结合,它以迅速、准确、经济、有效的方式提供目前各种通信网络中现有的业务,而且将通信和数据处理结合起来,开创了很多前所未有的新业务。 ISDN是一个全数字的网络,也就是说,不论原始信号是话音、文字、数据还是图象只要可以转换成数字信号,都能在ISDN网络中进行传输。在传统的电话网络中,实现了网络内部的数字化,但在用户到电话局之间仍采用模拟传输,很容易由于沿途噪声的积累引起失真。而对于ISDN来说,实现了用户线的数字化,提供端到端的数字连接,传输质量大大提高。

公共交换电话网络(PSTN)是是一种全球语音通信电路交换网络,包括商业的和政府拥有的。它也指简单老式电话业务(POTS)。它是自Alexander Graham Bell发明电话以来所有的电路交换式电话网络的集合。如今,除了使用者和本地电话总机之间的最后连接部分,公共交换电话网络在技术上已经实现了完全的数字化。在和因特网的关系上,PSTN提供了因特网相当一部分的长距离基础设施。因特网服务供应商(ISPS)为了使用PSTN的长距离基础设施,以及在众多使用者之间通过信息交换来共享电路,需要付给设备拥有者费用。这样因特网的用户就只需要对因特网服务供应商付费。

大白话:
PSTN与ISDN的关系,一开始是只有PSTN,而且都是铜线连接的,打电话就是模拟电话到电话局的交换机,然后连线到目标电话。后来进行数字化改造了,PSTN中电话局与电话局之间的远程线路用数字化了。然后电话局到家的这段线路也数字话了,变成了ISDN。

ISDN与数字公用电话交换网(PSTN)有者非常紧密的联系,可认为是在PSTN上为支持数据业务扩展形成的。ISDN的最基本功能与PSTN一样,提供端到端的64kbps的数字连接以承载话音或其他业务。在此基础上,ISDN还提供更高带宽的N*64kbps电路交换功能。ISDN的综合交换节点还应具有分组交换功能,以支持数据分组的交换。在信令结构上也与PSTN相同,采用7号信令系统,其用户部分为ISUP协议。

 

8、数据交换的三种类型分为:电路交换,报文交换,分组交换。

分组交换:在网络层。包括 数据报  和 虚电路。

电路交换:在物理层。包括时分交换和空分交换【就是空间上选条路】。

报文交换:传输层 ,用于 进程通信。可以理解为数据的存储转发。

分组交换技术(Packet switching technology)也称包交换技术,是将用户传送的数据划分成一定的长度,每个部分叫做一个分组,通过传输分组的方式传输信息的一种技术。它是通过计算机和终端实现计算机与计算机之间的通信,在传输线路质量不高、网络技术手段还较单一的情况下,应运而生的一种交换技术。每个分组的前面有一个分组头,用以指明该分组发往何地址,然后由交换机根据每个分组的地址标志,将他们转发至目的地,这一过程称为分组交换

电路交换:就是电话线, A打给B ,AB之间的电话线就接通了,那么不管他两说没说话,说多久,直到挂断之前,该线都是在占用之中。

报文交换:每一个结点接收整个报文,检查目标结点地址,然后根据网络中的交通情况在适当的时候转发到下一个结点。经过多次的存储——转发,最后到达目标,因而这样的网络叫存储——转发网络。其中的交换结点要有足够大的存储空间(一般是磁盘),用以缓冲收到的长报文。

分组交换:高效、灵活、迅速、可靠。

 

9、国家骨干网

参考:https://www.zhihu.com/question/26703129/answer/33931108

1)中国科技网(CSTNET)、

2)中国公用计算机互联网(CHINANET/163)

3)中国教育和科研计算机网(CERNET)、

4)中国金桥信息网(CHINAGBN)。

5)2004年ChinaNet2(CN2)启动,中国电信第二张全国骨干网

6)中国联通China169

7)中国移动CMNET

电信163和联通169是中国最重要的两个骨干网络,两者承担着中国互联网80%以上的流量

其中,CSTNET和CERNET主要为科研、教育提供非营利性Internet服务,而CHINANET和CHINAGBN则对公众提供经营性Internet服务。


十、面向连接和无连接的思考

能否说:“电路交换和面向连接是等同的,而分组交换和无连接是等同的”?不行。这在概念上是很不一样的。这点可举例说明如下。

电路交换就是在A和B要通信的开始,必须先建立一条从A到B的连接(中间可能经过很多的交换结点)。当A到B的连接建立后,通信就沿着这条路径进行。A和B在通信期间始终占用这条信道(全程占用),即使在通信的信号暂时不在通信路径上流动时(例如打电话时双方暂时停止说话),也是同样地占用信道。通信完毕时就释放所占用的信道,即断开连接,将通信资源还给网络,以便让其他用户可以使用。因此电路交换是使用面向连接的服务。

但分组交换也可以使用面向连接服务。例如X.25网络、帧中继网络或ATM网络都是属于分组交换网。然而这种面向连接的分组交换网在传送用户数据之前必须先建立连接。数据传送完毕后还必须释放连接。

因此使用面向连接服务的可以是电路交换,也可以是分组交换。

使用分组交换时,分组在哪条链路上传送就占用了该链路的信道资源,但分组尚未到达的链路则暂时还不占用这部分网络资源(这时,这些资源可以让其他用户使用)。因此分组交换不是全程占用资源而是在一段时间占用一段资源。可见分组交换方式是很灵活的。

现在的因特网使用IP协议,它使用无连接的IP数据报来传送数据,即不需要先建立连接就可以立即发送数据。当数据发送完毕后也不存在释放连接的问题。因此使用无连接的数据报进行通信既简单又灵活。

面向连接和无连接是强调通信必须经过什么样的阶段。面向连接必须经过三个阶段:“建立连接→传送数据→释放连接”,而无连接则只有一个阶段:“传送数据”。

电路交换和分组交换则是强调在通信时用户对网络资源的占用方式。电路交换是在连接建立后到连接释放前全程占用信道资源,而分组交换则是在数据传送是断续占用信道资源(分组在哪一条链路上传送就占用该链路的信道资源)。

面向连接和无连接往往可以在不同的层次上来讨论。例如,在数据链路层,HDLC和PPP协议是面向连接的,而以太网使用的CSMA/CD则是无连接的。在网络层,X.25协议是面向连接的,而IP协议则是无连接的。在运输层,TCP是面向连接的,而UDP则是无连接的。但是我们却不能说:“TCP是电路交换”,而应当说:“TCP可以向应用层提供面向连接的服务”。

TCP是面向连接的,UDP是无连接,他们是传输层的协议。
ATM也是面向连接的,但是他主要是在数据链路层。
还有Novell+SPX、Apple+Talk+ATP等等,都是面向连接的。
而无连接协议中,最重要的是IP协议,在网络层。

TCP是面向连接的,网络层中的虚电路也是面向连接的,它们有何异同?

对于传输层来说,高层用户对传输服务质量要求是确定的,传输层协议内容取决于网络层所提供的服务。网络层提供面向连接的虚电路服务和无连接的数据报服务。如果网络层提供虚电路服务,它可以保证报文分组无差错、不丢失、不重复和顺序传输。在这种情况下,传输层协议相对要简单。即使对虚电路服务,传输层也是必不可少的。因为虚电路仍不能保证通信子网传输百分之百正确。例如在X.25虚电路服务中,当网络发出中断分组和恢复请求分组时,主机无法获得通信子网中报文分组的状态,而虚电路两端的发送、接收报文分组的序号均置零。因此,虚电路恢复的工作必须由高层(传输层)来完成。如果网络层使用数据报方式,则传输层的协议将要变得复杂。
现在的基于IP的互联网网络层不是面向连接的,因此需要传输层的TCP来保证传输的可靠。

网络原理-OSI七层模型和TCP/IP模型-详解

OSI七层模型和TCP/IP模型-详解

 ⬇️   ⬇️   ⬇️  下图中有错误:SLIP 和PPP 都属于 数据链路层协议  ⬇️   ⬇️   ⬇️

OSI 七层模型通过七个层次化的结构模型使不同的系统不同的网络之间实现可靠的通讯,因此其最主要的功能就是帮助不同类型的主机实现数据传输 。

完成中继功能的节点通常称为中继系统。在OSI七层模型中,处于不同层的中继系统具有不同的名称。

一个设备工作在哪一层,关键看它工作时利用哪一层的数据头部信息。网桥工作时,是以MAC头部来决定转发端口的,因此显然它是数据链路层的设备。
具体说:(中继系统分类)

物理层:网卡,网线,集线器,中继器,调制解调器

数据链路层:网桥,交换机

网络层:路由器

网关工作在第四层传输层及其以上

集线器是物理层设备,采用广播的形式来传输信息。

交换机就是用来进行报文交换的机器。多为链路层设备(二层交换机),能够进行地址学习,采用存储转发的形式来交换报文.。

路由器的一个作用是连通不同的网络,另一个作用是选择信息传送的线路。选择通畅快捷的近路,能大大提高通信速度,减轻网络系统通信负荷,节约网络系统资源,提高网络系统畅通率。

交换机和路由器的区别

交换机拥有一条很高带宽的背部总线和内部交换矩阵。交换机的所有的端口都挂接在这条总线上,控制电路收到数据包以后,处理端口会查找内存中的地址对照表以确定目的MAC(网卡的硬件地址)的NIC(网卡)挂接在哪个端口上,通过内部交换矩阵迅速将数据包传送到目的端口,目的MAC若不存在则广播到所有的端口,接收端口回应后交换机会“学习”新的地址,并把它添加入内部MAC地址表中。
使用交换机也可以把网络“分段”,通过对照MAC地址表,交换机只允许必要的网络流量通过交换机。通过交换机的过滤和转发,可以有效的隔离广播风暴,减少误包和错包的出现,避免共享冲突。
交换机在同一时刻可进行多个端口对之间的数据传输。每一端口都可视为独立的网段,连接在其上的网络设备独自享有全部的带宽,无须同其他设备竞争使用。当节点A向节点D发送数据时,节点B可同时向节点C发送数据,而且这两个传输都享有网络的全部带宽,都有着自己的虚拟连接。假使这里使用的是10Mbps的以太网交换机,那么该交换机这时的总流通量就等于2×10Mbps=20Mbps,而使用10Mbps的共享式HUB时,一个HUB的总流通量也不会超出10Mbps。
总之,交换机是一种基于MAC地址识别,能完成封装转发数据包功能的网络设备。交换机可以“学习”MAC地址,并把其存放在内部地址表中,通过在数据帧的始发者和目标接收者之间建立临时的交换路径,使数据帧直接由源地址到达目的地址。

从过滤网络流量的角度来看,路由器的作用与交换机和网桥非常相似。但是与工作在网络物理层,从物理上划分网段的交换机不同,路由器使用专门的软件协议从逻辑上对整个网络进行划分。例如,一台支持IP协议的路由器可以把网络划分成多个子网段,只有指向特殊IP地址的网络流量才可以通过路由器。对于每一个接收到的数据包,路由器都会重新计算其校验值,并写入新的物理地址。因此,使用路由器转发和过滤数据的速度往往要比只查看数据包物理地址的交换机慢。但是,对于那些结构复杂的网络,使用路由器可以提高网络的整体效率。路由器的另外一个明显优势就是可以自动过滤网络广播。

集线器与路由器在功能上有什么不同?

首先说HUB,也就是集线器。它的作用可以简单的理解为将一些机器连接起来组成一个局域网。而交换机(又名交换式集线器)作用与集线器大体相同。但是两者在性能上有区别:集线器采用的式共享带宽的工作方式,而交换机是独享带宽。这样在机器很多或数据量很大时,两者将会有比较明显的。而路由器与以上两者有明显区别,它的作用在于连接不同的网段并且找到网络中数据传输最合适的路径。路由器是产生于交换机之后,就像交换机产生于集线器之后,所以路由器与交换机也有一定联系,不是完全独立的两种设备。路由器主要克服了交换机不能路由转发数据包的不足。

总的来说,路由器与交换机的主要区别体现在以下几个方面:

(1)工作层次不同
最初的的交换机是工作在数据链路层,而路由器一开始就设计工作在网络层。由于交换机工作在数据链路层,所以它的工作原理比较简单,而路由器工作在网络层,可以得到更多的协议信息,路由器可以做出更加智能的转发决策。

(2)数据转发所依据的对象不同
交换机是利用物理地址或者说MAC地址来确定转发数据的目的地址。而路由器则是利用IP地址来确定数据转发的地址。IP地址是在软件中实现的,描述的是设备所在的网络。MAC地址通常是硬件自带的,由网卡生产商来分配的,而且已经固化到了网卡中去,一般来说是不可更改的。而IP地址则通常由网络管理员或系统自动分配。

(3)传统的交换机只能分割冲突域,不能分割广播域;而路由器可以分割广播域
由交换机连接的网段仍属于同一个广播域,广播数据包会在交换机连接的所有网段上传播,在某些情况下会导致通信拥挤和安全漏洞。连接到路由器上的网段会被分配成不同的广播域,广播数据不会穿过路由器。虽然第三层以上交换机具有VLAN功能,也可以分割广播域,但是各子广播域之间是不能通信交流的,它们之间的交流仍然需要路由器。

(4)路由器提供了防火墙的服务
路由器仅仅转发特定地址的数据包,不传送不支持路由协议的数据包传送和未知目标网络数据包的传送,从而可以防止广播风暴。

 

物理层

在OSI参考模型中,物理层(Physical Layer)是参考模型的最低层,也是OSI模型的第一层。
物理层的主要功能是:利用传输介质为数据链路层提供物理连接,实现比特流的透明传输。
物理层的作用是实现相邻计算机节点之间比特流的透明传送,尽可能屏蔽掉具体传输介质和物理设备的差异。使其上面的数据链路层不必考虑网络的具体传输介质是什么。“透明传送比特流”表示经实际电路传送后的比特流没有发生变化,对传送的比特流来说,这个电路好像是看不见的。

数据链路层

数据链路层(Data Link Layer)是OSI模型的第二层,负责建立和管理节点间的链路。该层的主要功能是:通过各种控制协议,将有差错的物理信道变为无差错的、能可靠传输数据帧的数据链路。
在计算机网络中由于各种干扰的存在,物理链路是不可靠的。因此,这一层的主要功能是在物理层提供的比特流的基础上,通过差错控制、流量控制方法,使有差错的物理线路变为无差错的数据链路,即提供可靠的通过物理介质传输数据的方法。
该层通常又被分为介质访问控制(MAC)和逻辑链路控制(LLC)两个子层。

MAC子层的主要任务是解决共享型网络中多用户对信道竞争的问题,完成网络介质的访问控制;

LLC子层的主要任务是建立和维护网络连接,执行差错校验、流量控制和链路控制。
数据链路层的具体工作是接收来自物理层的位流形式的数据,并封装成帧,传送到上一层;同样,也将来自上层的数据帧,拆装为位流形式的数据转发到物理层;并且,还负责处理接收端发回的确认帧的信息,以便提供可靠的数据传输。

网络层

网络层(Network Layer)是OSI模型的第三层,它是OSI参考模型中最复杂的一层,也是通信子网的最高一层。它在下两层的基础上向资源子网提供服务。其主要任务是:通过路由选择算法,为报文或分组通过通信子网选择最适当的路径。该层控制数据链路层与传输层之间的信息转发,建立、维持和终止网络的连接。具体地说,数据链路层的数据在这一层被转换为数据包,然后通过路径选择、分段组合、顺序、进/出路由等控制,将信息从一个网络设备传送到另一个网络设备。
一般地,数据链路层是解决同一网络内节点之间的通信,而网络层主要解决不同子网间的通信。例如在广域网之间通信时,必然会遇到路由(即两节点间可能有多条路径)选择问题。

在实现网络层功能时,需要解决的主要问题如下:
 寻址:数据链路层中使用的物理地址(如MAC地址)仅解决网络内部的寻址问题。在不同子网之间通信时,为了识别和找到网络中的设备,每一子网中的设备都会被分配一个唯一的地址。由于各子网使用的物理技术可能不同,因此这个地址应当是逻辑地址(如IP地址)。
 交换:规定不同的信息交换方式。常见的交换技术有:线路交换技术和存储转发技术,后者又包括报文交换技术和分组交换技术。
 路由算法:当源节点和目的节点之间存在多条路径时,本层可以根据路由算法,通过网络为数据分组选择最佳路径,并将信息从最合适的路径由发送端传送到接收端。
 连接服务:与数据链路层流量控制不同的是,前者控制的是网络相邻节点间的流量,后者控制的是从源节点到目的节点间的流量。其目的在于防止阻塞,并进行差错检测。

传输层

OSI下3层的主要任务是数据通信,上3层的任务是数据处理。而传输层(Transport Layer)是OSI模型的第4层。因此该层是通信子网和资源子网的接口和桥梁,起到承上启下的作用。
该层的主要任务是:向用户提供可靠的端到端的差错和流量控制,保证报文的正确传输。传输层的作用是向高层屏蔽下层数据通信的细节,即向用户透明地传送报文。该层常见的协议:TCP/IP中的TCP协议、Novell网络中的SPX协议和微软的NetBIOS/NetBEUI协议。
传输层提供会话层和网络层之间的传输服务,这种服务从会话层获得数据,并在必要时,对数据进行分割。然后,传输层将数据传递到网络层,并确保数据能正确无误地传送到网络层。因此,传输层负责提供两节点之间数据的可靠传送,当两节点的联系确定之后,传输层则负责监督工作。综上,传输层的主要功能如下:
传输连接管理:提供建立、维护和拆除传输连接的功能。传输层在网络层的基础上为高层提供“面向连接”和“面向无接连”的两种服务。
处理传输差错:提供可靠的“面向连接”和不太可靠的“面向无连接”的数据传输服务、差错控制和流量控制。在提供“面向连接”服务时,通过这一层传输的数据将由目标设备确认,如果在指定的时间内未收到确认信息,数据将被重发。
监控服务质量

会话层

会话层(Session Layer)是OSI模型的第5层,是用户应用程序和网络之间的接口,主要任务是:向两个实体的表示层提供建立和使用连接的方法。将不同实体之间的表示层的连接称为会话。因此会话层的任务就是组织和协调两个会话进程之间的通信,并对数据交换进行管理。
用户可以按照半双工、单工和全双工的方式建立会话。当建立会话时,用户必须提供他们想要连接的远程地址。而这些地址与MAC(介质访问控制子层)地址或网络层的逻辑地址不同,它们是为用户专门设计的,更便于用户记忆。域名(DN)就是一种网络上使用的远程地址例如:www.3721.com就是一个域名。会话层的具体功能如下:
会话管理:允许用户在两个实体设备之间建立、维持和终止会话,并支持它们之间的数据交换。例如提供单方向会话或双向同时会话,并管理会话中的发送顺序,以及会话所占用时间的长短。
 会话流量控制:提供会话流量控制和交叉会话功能。
寻址:使用远程地址建立会话连接。
出错控制:从逻辑上讲会话层主要负责数据交换的建立、保持和终止,但实际的工作却是接收来自传输层的数据,并负责纠正错误。会话控制和远程过程调用均属于这一层的功能。但应注意,此层检查的错误不是通信介质的错误,而是磁盘空间、打印机缺纸等类型的高级错误。

表示层

表示层(Presentation Layer)是OSI模型的第六层,它对来自应用层的命令和数据进行解释,对各种语法赋予相应的含义,并按照一定的格式传送给会话层。其主要功能是“处理用户信息的表示问题,如编码、数据格式转换和加密解密”等。表示层的具体功能如下:
数据格式处理:协商和建立数据交换的格式,解决各应用程序之间在数据格式表示上的差异。
数据的编码:处理字符集和数字的转换。例如由于用户程序中的数据类型(整型或实型、有符号或无符号等)、用户标识等都可以有不同的表示方式,因此,在设备之间需要具有在不同字符集或格式之间转换的功能。
压缩和解压缩:为了减少数据的传输量,这一层还负责数据的压缩与恢复。
数据的加密和解密:可以提高网络的安全性。

应用层

应用层(Application Layer)是OSI参考模型的最高层,它是计算机用户,以及各种应用程序和网络之间的接口,其功能是直接向用户提供服务,完成用户希望在网络上完成的各种工作。它在其他6层工作的基础上,负责完成网络中应用程序与网络操作系统之间的联系,建立与结束使用者之间的联系,并完成网络用户提出的各种网络服务及应用所需的监督、管理和服务等各种协议。此外,该层还负责协调各个应用程序间的工作。
应用层为用户提供的服务和协议有:文件服务、目录服务、文件传输服务(FTP)、远程登录服务(Telnet)、电子邮件服务(E-mail)、打印服务、安全服务、网络管理服务、数据库服务等。上述的各种网络服务由该层的不同应用协议和程序完成,不同的网络操作系统之间在功能、界面、实现技术、对硬件的支持、安全可靠性以及具有的各种应用程序接口等各个方面的差异是很大的。应用层的主要功能如下:
用户接口:应用层是用户与网络,以及应用程序与网络间的直接接口,使得用户能够与网络进行交互式联系。
实现各种服务:该层具有的各种应用程序可以完成和实现用户请求的各种服务。

OSI7层模型的小结

由于OSI是一个理想的模型,因此一般网络系统只涉及其中的几层,很少有系统能够具有所有的7层,并完全遵循它的规定。
在7层模型中,每一层都提供一个特殊的网络功能。从网络功能的角度观察:下面4层(物理层、数据链路层、网络层和传输层)主要提供数据传输和交换功能,即以节点到节点之间的通信为主;第4层作为上下两部分的桥梁,是整个网络体系结构中最关键的部分;而上3层(会话层、表示层和应用层)则以提供用户与应用程序之间的信息和数据处理功能为主。简言之,下4层主要完成通信子网的功能,上3层主要完成资源子网的功能。

以下是TCP/IP分层模型
┌────——────┐┌─┬─┬-┬─┬–┬-┬-┬─┬-┬─┬-┐
│              ││D│F│W│F│H│G│T│I│S│U│ │
│           ││N│I│H│T│T│O│E│R│M│S│其│
│第四层,应用        ││S│N│O│P│T│P│L│C│T│E│ │
│              ││ │G│I│ │P│H│N│ │P│N│ │
│              ││ │E│S│ │ │E│E│ │ │E│它│
│              ││ │R│ │ │ │R│T│ │ │T│ │
└───────——─┘└─┴─┴-┴─┴–┴-┴-┴─┴-┴─┴-┘
┌───────—–─┐┌─────────——-┬──——–────────┐
│第三层,传输层   ││      TCP   │        UDP        │
└───────—–─┘└────────——-─┴─────────——–─┘
┌───────—–─┐┌───—-──┬───—─┬───────——-──┐
│          ││            │ICMP   │           │
│第二层,网间层   ││            └──—──-┘            │
│          ││           IP                           │
└────────—–┘└────────────────────————-─-┘
┌────────——┐┌─────────——┬──────——–─────┐
│第一层,网络接口││   ARP/RARP│    其它            |
└────────——┘└─────────——┴─────——–──────┘

TCP/IP四层参考模型

TCP/IP协议被组织成四个概念层,其中有三层对应于ISO参考模型中的相应层。ICP/IP协议族并不包含物理层和数据链路层,因此它不能独立完成整个计算机网络系统的功能,必须与许多其他的协议协同工作。
TCP/IP分层模型的四个协议层分别完成以下的功能:
第一层:网络接口层
包括用于协作IP数据在已有网络介质上传输的协议。实际上TCP/IP标准并不定义与ISO数据链路层和物理层相对应的功能。相反,它定义像地址解析协议(Address Resolution Protocol,ARP)这样的协议,提供TCP/IP协议的数据结构和实际物理硬件之间的接口。
第二层:网间层
对应于OSI七层参考模型的网络层。本层包含IP协议、RIP协议(Routing Information Protocol,路由信息协议),负责数据的包装、寻址和路由。同时还包含网间控制报文协议(Internet Control Message Protocol,ICMP)用来提供网络诊断信息。
第三层:传输层
对应于OSI七层参考模型的传输层,它提供两种端到端的通信服务。其中TCP协议(Transmission Control Protocol)提供可靠的数据流运输服务,UDP协议(Use Datagram Protocol)提供不可靠的用户数据报服务。
第四层:应用层
对应于OSI七层参考模型的应用层和表达层。因特网的应用层协议包括Finger、Whois、FTP(文件传输协议)、Gopher、HTTP(超文本传输协议)、Telent(远程终端协议)、SMTP(简单邮件传送协议)、IRC(因特网中继会话)、NNTP(网络新闻传输协议)等,这也是本书将要讨论的重点。

来自:https://blog.csdn.net/yaopeng_2005/article/details/7064869

网络原理-OSI七层模型和TCP/IP模型-维基百科摘要

OSI七层模型和TCP/IP模型-维基百科摘要


开放式系统互联通信参考模型英语:Open System Interconnection Reference Model,缩写为 OSI),简称为OSI模型(OSI model),一种概念模型,由国际标准化组织提出,一个试图使各种计算机在世界范围内互连为网络的标准框架。定义于ISO/IEC 7498-1。

应用层(Application Layer)提供为应用软件而设的接口,以设置与另一应用软件之间的通信。例如: HTTP,HTTPS,FTP,TELNET,SSH,SMTP,POP3等。

表达层(Presentation Layer)把数据转换为能与接收者的系统格式兼容并适合传输的格式。

会话层(Session Layer)负责在数据传输中设置和维护电脑网络中两台电脑之间的通信连接。

传输层(Transport Layer)把传输表头(TH)加至数据以形成数据包。传输表头包含了所使用的协议等发送信息。例如:传输控制协议(TCP)等。

网络层(Network Layer)决定数据的路径选择和转寄,将网络表头(NH)加至数据包,以形成分组。网络表头包含了网络数据。例如:互联网协议(IP)等。

数据链路层(Data Link Layer)负责网络寻址、错误侦测和改错。当表头和表尾被加至数据包时,会形成帧。数据链表头(DLH)是包含了物理地址和错误侦测及改错的方法。数据链表尾(DLT)是一串指示数据包末端的字符串。例如以太网、无线局域网(Wi-Fi)和通用分组无线服务(GPRS)等。

分为两个子层:逻辑链路控制(LLC)数据通信协议层是七层OSI模型数据链路层的上部子层。LLC子层提供多路复用机制,使得多个网络协议(例如IPIPXDecnetAppletalk)可以在多点网络中共存并通过相同的网络介质传输。它还可以提供流量控制自动重复请求(ARQ)错误管理机制。LLC子层充当媒体访问控制(MAC)子层和网络层之间的接口。

物理层(Physical Layer)在局部局域网上传送数据帧(data frame),它负责管理电脑通信设备和网络媒体之间的互通。包括了针脚、电压、线缆规范、集线器、中继器、网卡、主机适配器等。

 

互联网协议族英语:Internet Protocol Suite,缩写IPS)[1]是一个网络通信模型,以及一整个网络传输协议家族,为互联网的基础通信架构。它常被通称为TCP/IP协议族(英语:TCP/IP Protocol Suite,或TCP/IP Protocols),简称TCP/IP

应用层

该层包括所有和应用程序协同工作,利用基础网络交换应用程序专用的数据的协议。 应用层是大多数普通与网络相关的程序为了通过网络与其他程序通信所使用的层。这个层的处理过程是应用特有的;数据从网络相关的程序以这种应用内部使用的格式进行传送,然后被编码成标准协议的格式。

传输层

传输层的协议,能够解决诸如端到端可靠性(“数据是否已经到达目的地?”)和保证数据按照正确的顺序到达这样的问题。在TCP/IP协议组中,传输协议也包括所给数据应该送给哪个应用程序。 在TCP/IP协议组中技术上位于这个层的动态路由协议通常被认为是网络层的一部分;一个例子就是OSPF(IP协议89)。 TCP(IP协议6)是一个“可靠的”、面向连结的传输机制,它提供一种可靠的字节流保证数据完整、无损并且按顺序到达。

网络互连层

TCP/IP协议族中的网络互连层(internet layer)在OSI模型中叫做网络层(network layer)。

正如最初所定义的,网络层解决在一个单一网络上传输数据包的问题。类似的协议有X.25ARPANETHost/IMP Protocol。 随着因特网思想的出现,在这个层上添加附加的功能,也就是将数据从源网络传输到目的网络。这就牵涉到在网络组成的网上选择路径将数据包传输,也就是因特网。 在因特网协议组中,IP完成数据从源发送到目的的基本任务。IP能够承载多种不同的高层协议的数据;这些协议使用一个唯一的IP协议号进行标识。ICMP和IGMP分别是1和2。 一些IP承载的协议,如ICMP(用来发送关于IP发送的诊断信息)和IGMP(用来管理多播数据),它们位于IP层之上但是完成网络层的功能,这表明因特网和OSI模型之间的不兼容性。所有的路由协议,如BGPOSPF、和RIP实际上也是网络层的一部分,尽管它们似乎应该属于更高的协议栈。

网络接口层

网络接口层实际上并不是因特网协议组中的一部分,但是它是数据包从一个设备的网络层传输到另外一个设备的网络层的方法。这个过程能够在网卡软件驱动程序中控制,也可以在韧体或者专用芯片中控制。这将完成如添加报头准备发送、通过实体媒介实际发送这样一些数据链路功能。另一端,链路层将完成数据帧接收、去除报头并且将接收到的包传到网络层。 然而,链路层并不经常这样简单。它也可能是一个虚拟专有网络(VPN)或者隧道,在这里从网络层来的包使用隧道协议和其他(或者同样的)协议组发送而不是发送到实体的接口上。

 

websocket协议-细说WebSocket – java篇

tcp/udp 是协议,而 socket 是实现 该协议的 接口。所以 网络编程 就是 socket 编程。因为 http 和 websocket 都是 http 80 端口 tcp 协议。所以 web 服务器 肯定要实现 ,socket 区分 http 字节流还是  websocket 字节流。 这个 暂时 没有深入,有机会 去研究  web 开源 服务器 ,看看 如何 做到 区分 。


文章待整理

http://www.111cn.net/wy/html5/69508.htm (手动解析 websocket   )

https://www.cnblogs.com/jingmoxukong/p/7755643.html (框架解析websocket)


关于网络编程 :

百度搜 tcp ip 网络编程

【Java TCP/IP Socket】Socket编程大合集
https://blog.csdn.net/ns_code/article/details/17526127

怎样算得上熟悉 TCP/IP 协议编程?
链接:https://www.zhihu.com/question/20795067/answer/16233370

常见的三个网络协议:NetBEUI、IPX/SPX、TCP/IP
http://network.51cto.com/art/200701/38792.htm

三大协议:NetBEUI、IPX/SPX 和TCP/IP
https://searchnetworking.techtarget.com.cn/12-15241/

NetBIOS
https://zh.wikipedia.org/wiki/NetBIOS

Internet协议
https://baike.baidu.com/item/Internet%E5%8D%8F%E8%AE%AE/11049108

网络拓扑 锁定
https://baike.baidu.com/item/%E7%BD%91%E7%BB%9C%E6%8B%93%E6%89%91/4804125?fr=aladdin

链路层包括 物理链路层 和 数据链路层

websocket协议-细说WebSocket – php篇

下面我画了一个图演示 client 和 server 之间建立 websocket 连接时握手部分,这个部分在 node 中可以十分轻松的完成,因为 node 提供的 net 模块已经对 socket 套接字做了封装处理,开发者使用的时候只需要考虑数据的交互而不用处理连接的建立。而 php 没有,从 socket 的连接、建立、绑定、监听等,这些都需要我们自己去操作,所以有必要拿出来再说一说。

   +--------+    1.发送Sec-WebSocket-Key        +---------+
    |        | --------------------------------> |        |
    |        |    2.加密返回Sec-WebSocket-Accept  |        |
    | client | <-------------------------------- | server |
    |        |    3.本地校验                      |        |
    |        | --------------------------------> |        |
    +--------+                                   +--------+

看了我写的上一篇文章的同学应该是对上图有了比较全面的理解。① 和 ② 实际上就是一个 HTTP 的请求和响应,只不过我们在处理的过程中我们拿到的是没有经过解析的字符串。如:

GET /chat HTTP/1.1
Host: server.example.com
Origin: http://example.com

我们往常看到的请求是这个样子,当这东西到了服务器端,我们可以通过一些代码库直接拿到这些信息。

一、php 中处理 websocket

WebSocket 连接是由客户端主动发起的,所以一切要从客户端出发。第一步是要解析拿到客户端发过来的 Sec-WebSocket-Key 字符串。

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

前文中也提到了 client 请求的格式(如上),首先 php 建立一个 socket 连接,监听端口的信息。

1. socket 连接的建立

关于 socket 套接字的建立,相信很多大学修过计算机网络的人都知道了,下面是一张连接建立的过程:

// 建立一个 socket 套接字
$master = socket_create(AF_INET, SOCK_STREAM, SOL_TCP);
socket_set_option($master, SOL_SOCKET, SO_REUSEADDR, 1);
socket_bind($master, $address, $port);
socket_listen($master);

相比 node,这个地方的处理实在是太麻烦了,上面几行代码并未建立连接,只不过这些代码是建立一个 socket 套接字必须要写的东西。由于处理过程稍微有复杂,所以我把各种处理写进了一个类中,方便管理和调用。

//demo.php
Class WS {
    var $master;  // 连接 server 的 client
    var $sockets = array(); // 不同状态的 socket 管理
    var $handshake = false; // 判断是否握手

    function __construct($address, $port){
        // 建立一个 socket 套接字
        $this->master = socket_create(AF_INET, SOCK_STREAM, SOL_TCP)   
            or die("socket_create() failed");
        socket_set_option($this->master, SOL_SOCKET, SO_REUSEADDR, 1)  
            or die("socket_option() failed");
        socket_bind($this->master, $address, $port)                    
            or die("socket_bind() failed");
        socket_listen($this->master, 2)                               
            or die("socket_listen() failed");

        $this->sockets[] = $this->master;

        // debug
        echo("Master socket  : ".$this->master."\n");

        while(true) {
            //自动选择来消息的 socket 如果是握手 自动选择主机
            $write = NULL;
            $except = NULL;
            socket_select($this->sockets, $write, $except, NULL);

            foreach ($this->sockets as $socket) {
                //连接主机的 client 
                if ($socket == $this->master){
                    $client = socket_accept($this->master);
                    if ($client < 0) {
                        // debug
                        echo "socket_accept() failed";
                        continue;
                    } else {
                        //connect($client);
                        array_push($this->sockets, $client);
                        echo "connect client\n";
                    }
                } else {
                    $bytes = @socket_recv($socket,$buffer,2048,0);
                    if($bytes == 0) return;
                    if (!$this->handshake) {
                        // 如果没有握手,先握手回应
                        //doHandShake($socket, $buffer);
                        echo "shakeHands\n";
                    } else {
                        // 如果已经握手,直接接受数据,并处理
                        $buffer = decode($buffer);
                        //process($socket, $buffer); 
                        echo "send file\n";
                    }
                }
            }
        }
    }
}

上面这段代码是经过我调试了的,没太大的问题,如果想测试的话,可以在 cmd 命令行中键入 php /path/to/demo.php;当然,上面只是一个类,如果要测试的话,还得新建一个实例。

$ws = new WS('localhost', 4000);

客户端代码可以稍微简单点:

var ws = new WebSocket("ws://localhost:4000");
ws.onopen = function(){
    console.log("握手成功");
};
ws.onerror = function(){
    console.log("error");
};

运行服务器代码,当客户端连接的时候,我们可以看到:

通过上面的代码可以清晰的看到整个交流的过程。首先是建立连接,node 中这一步已经封装到了 net 和 http 模块,然后判断是否握手,如果没有的话,就 shakeHands。这里的握手我直接就 echo 了一个单词,表示进行了这个东西,前文我们提到过握手算法,这里就直接写了。

2. 提取 Sec-WebSocket-Key 信息

function getKey($req) {
    $key = null;
    if (preg_match("/Sec-WebSocket-Key: (.*)\r\n/", $req, $match)) { 
        $key = $match[1]; 
    }
    return $key;
}

这里比较简单,直接正则匹配,websocket 信息头一定包含 Sec-WebSocket-Key,所以我们匹配起来也比较快捷~

3. 加密 Sec-WebSocket-Key

function encry($req){
    $key = $this->getKey($req);
    $mask = "258EAFA5-E914-47DA-95CA-C5AB0DC85B11";

    return base64_encode(sha1($key . '258EAFA5-E914-47DA-95CA-C5AB0DC85B11', true));
}

将 SHA-1 加密后的字符串再进行一次 base64 加密。如果加密算法错误,客户端在进行校检的时候会直接报错:

4. 应答 Sec-WebSocket-Accept

function dohandshake($socket, $req){
    // 获取加密key
    $acceptKey = $this->encry($req);
    $upgrade = "HTTP/1.1 101 Switching Protocols\r\n" .
               "Upgrade: websocket\r\n" .
               "Connection: Upgrade\r\n" .
               "Sec-WebSocket-Accept: " . $acceptKey . "\r\n" .
               "\r\n";

    // 写入socket
    socket_write(socket,$upgrade.chr(0), strlen($upgrade.chr(0)));
    // 标记握手已经成功,下次接受数据采用数据帧格式
    $this->handshake = true;
}

这里千万要注意,每一个请求和相应的格式,最后有一个空行,也就是 \r\n,开始测试的时候把这东西给弄丢了,纠结了半天。

当客户端成功校检key后,会触发 onopen 函数:

5. 数据帧处理

// 解析数据帧
function decode($buffer)  {
    $len = $masks = $data = $decoded = null;
    $len = ord($buffer[1]) & 127;

    if ($len === 126)  {
        $masks = substr($buffer, 4, 4);
        $data = substr($buffer, 8);
    } else if ($len === 127)  {
        $masks = substr($buffer, 10, 4);
        $data = substr($buffer, 14);
    } else  {
        $masks = substr($buffer, 2, 4);
        $data = substr($buffer, 6);
    }
    for ($index = 0; $index < strlen($data); $index++) {
        $decoded .= $data[$index] ^ $masks[$index % 4];
    }
    return $decoded;
}

这里涉及的编码问题在前文中已经提到过了,这里就不赘述,php 对字符处理的函数太多了,也记得不是特别清楚,这里就没有详细的介绍解码程序,直接把客户端发送的数据原样返回,可以算是一个聊天室的模式吧。

// 返回帧信息处理
function frame($s) {
    $a = str_split($s, 125);
    if (count($a) == 1) {
        return "\x81" . chr(strlen($a[0])) . $a[0];
    }
    $ns = "";
    foreach ($a as $o) {
        $ns .= "\x81" . chr(strlen($o)) . $o;
    }
    return $ns;
}

// 返回数据
function send($client, $msg){
    $msg = $this->frame($msg);
    socket_write($client, $msg, strlen($msg));
}

客户端代码:

var ws = new WebSocket("ws://localhost:4000");
ws.onopen = function(){
    console.log("握手成功");
};
ws.onmessage = function(e){
    console.log("message:" + e.data);
};
ws.onerror = function(){
    console.log("error");
};
ws.send("李靖");

在连通之后发送数据,服务器原样返回:

二、注意问题

1. websocket 版本问题

客户端在握手时的请求中有Sec-WebSocket-Version: 13,这样的版本标识,这个是一个升级版本,现在的浏览器都是使用的这个版本。而以前的版本在数据加密的部分更加麻烦,它会发送两个key:

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Key1: xxxx
Sec-WebSocket-Key2: xxxx

如果是这种版本(比较老,已经没在使用了),需要通过下面的方式获取

function encry($key1,$key2,$l8b){ //Get the numbers preg_match_all('/([\d]+)/', $key1, $key1_num); preg_match_all('/([\d]+)/', $key2, $key2_num);

    $key1_num = implode($key1_num[0]);
    $key2_num = implode($key2_num[0]);
    //Count spaces
    preg_match_all('/([ ]+)/', $key1, $key1_spc);
    preg_match_all('/([ ]+)/', $key2, $key2_spc);

    if($key1_spc==0|$key2_spc==0){ $this->log("Invalid key");return; }
    //Some math
    $key1_sec = pack("N",$key1_num / $key1_spc);
    $key2_sec = pack("N",$key2_num / $key2_spc);

    return md5($key1_sec.$key2_sec.$l8b,1);
}

只能无限吐槽这种验证方式!相比 nodeJs 的 websocket 操作方式:

//服务器程序
var crypto = require('crypto');
var WS = '258EAFA5-E914-47DA-95CA-C5AB0DC85B11';
require('net').createServer(function(o){
    var key;
    o.on('data',function(e){
        if(!key){
            //握手
            key = e.toString().match(/Sec-WebSocket-Key: (.+)/)[1];
            key = crypto.createHash('sha1').update(key + WS).digest('base64');
            o.write('HTTP/1.1 101 Switching Protocols\r\n');
            o.write('Upgrade: websocket\r\n');
            o.write('Connection: Upgrade\r\n');
            o.write('Sec-WebSocket-Accept: ' + key + '\r\n');
            o.write('\r\n');
        }else{
            console.log(e);
        };
    });
}).listen(8000);

多么简洁,多么方便!有谁还愿意使用 php 呢。。。。

2. 数据帧解析代码

本文没有给出 decodeFrame 这样数据帧解析代码,前文中给出了数据帧的格式,解析纯属体力活。

3. 代码展示

对这部分感兴趣的同学可以再去深究。代码用到了demo.php和ws.html两个文件。

<?php
class WS {
	var $master;
	var $sockets = array();
	var $debug = false;
	var $handshake = false;

	function __construct($address, $port){
		$this->master=socket_create(AF_INET, SOCK_STREAM, SOL_TCP)     or die("socket_create() failed");
		socket_set_option($this->master, SOL_SOCKET, SO_REUSEADDR, 1)  or die("socket_option() failed");
		socket_bind($this->master, $address, $port)                    or die("socket_bind() failed");
		socket_listen($this->master,20)                                or die("socket_listen() failed");
		
		$this->sockets[] = $this->master;
		$this->say("Server Started : ".date('Y-m-d H:i:s'));
		$this->say("Listening on   : ".$address." port ".$port);
		$this->say("Master socket  : ".$this->master."\n");
		
		while(true){
			$socketArr = $this->sockets;
			$write = NULL;
			$except = NULL;
			socket_select($socketArr, $write, $except, NULL);  //自动选择来消息的socket 如果是握手 自动选择主机
			foreach ($socketArr as $socket){
				if ($socket == $this->master){  //主机
					$client = socket_accept($this->master);
					if ($client < 0){
						$this->log("socket_accept() failed");
						continue;
					} else{
						$this->connect($client);
					}
				} else {
					$this->log("^^^^");
					$bytes = @socket_recv($socket,$buffer,2048,0);
					$this->log("^^^^");
					if ($bytes == 0){
						$this->disConnect($socket);
					}
					else{
						if (!$this->handshake){
							$this->doHandShake($socket, $buffer);
						}
						else{
							$buffer = $this->decode($buffer);
							$this->send($socket, $buffer); 
						}
					}
				}
			}
		}
	}
	
	function send($client, $msg){
		$this->log("> " . $msg);
		$msg = $this->frame($msg);
		socket_write($client, $msg, strlen($msg));
		$this->log("! " . strlen($msg));
	}
	function connect($socket){
		array_push($this->sockets, $socket);
		$this->say("\n" . $socket . " CONNECTED!");
		$this->say(date("Y-n-d H:i:s"));
	}
	function disConnect($socket){
		$index = array_search($socket, $this->sockets);
		socket_close($socket);
		$this->say($socket . " DISCONNECTED!");
		if ($index >= 0){
			array_splice($this->sockets, $index, 1); 
		}
	}
	function doHandShake($socket, $buffer){
		$this->log("\nRequesting handshake...");
		$this->log($buffer);
		list($resource, $host, $origin, $key) = $this->getHeaders($buffer);
		$this->log("Handshaking...");
		$upgrade  = "HTTP/1.1 101 Switching Protocol\r\n" .
					"Upgrade: websocket\r\n" .
					"Connection: Upgrade\r\n" .
					"Sec-WebSocket-Accept: " . $this->calcKey($key) . "\r\n\r\n";  //必须以两个回车结尾
		$this->log($upgrade);
		$sent = socket_write($socket, $upgrade, strlen($upgrade));
		$this->handshake=true;
		$this->log("Done handshaking...");
		return true;
	}

	function getHeaders($req){
		$r = $h = $o = $key = null;
		if (preg_match("/GET (.*) HTTP/"              ,$req,$match)) { $r = $match[1]; }
		if (preg_match("/Host: (.*)\r\n/"             ,$req,$match)) { $h = $match[1]; }
		if (preg_match("/Origin: (.*)\r\n/"           ,$req,$match)) { $o = $match[1]; }
		if (preg_match("/Sec-WebSocket-Key: (.*)\r\n/",$req,$match)) { $key = $match[1]; }
		return array($r, $h, $o, $key);
	}

	function calcKey($key){
		//基于websocket version 13
		$accept = base64_encode(sha1($key . '258EAFA5-E914-47DA-95CA-C5AB0DC85B11', true));
		return $accept;
	}

	function decode($buffer) {
		$len = $masks = $data = $decoded = null;
		$len = ord($buffer[1]) & 127;

		if ($len === 126) {
			$masks = substr($buffer, 4, 4);
			$data = substr($buffer, 8);
		} 
		else if ($len === 127) {
			$masks = substr($buffer, 10, 4);
			$data = substr($buffer, 14);
		} 
		else {
			$masks = substr($buffer, 2, 4);
			$data = substr($buffer, 6);
		}
		for ($index = 0; $index < strlen($data); $index++) {
			$decoded .= $data[$index] ^ $masks[$index % 4];
		}
		return $decoded;
	}

	function frame($s){
		$a = str_split($s, 125);
		if (count($a) == 1){
			return "\x81" . chr(strlen($a[0])) . $a[0];
		}
		$ns = "";
		foreach ($a as $o){
			$ns .= "\x81" . chr(strlen($o)) . $o;
		}
		return $ns;
	}

	
	function say($msg = ""){
		echo $msg . "\n";
	}
	function log($msg = ""){
		if ($this->debug){
			echo $msg . "\n";
		} 
	}
}
	

new WS('localhost', 4000);
<script type="text/javascript">
var ws = new WebSocket("ws://localhost:4000");
ws.onopen = function(){
	console.log("握手成功");
}
ws.onmessage = function(e){
	console.log("message:" + e.data);
}
ws.onerror = function(){
	console.log("error");
}
</script>

 

4. 相关开源库参考

http://socketo.me Ratchet 为 php 封装的一个 WebSockets 库。

Google 上搜索 php+websoket+class,也能找到不少相关的资料。

三、参考资料

来自:https://www.barretlee.com/blog/2013/12/25/cb-websocket-with-php/     可以关注微信公众号 (小胡子哥)


文章错误纠正:

1、握手函数中不应该加chr(0),只应该发送$upgrade,否则后续消息发到浏览器中都会提示A server must not mask any frames that it sends to the client.

———————————————————

2、我想问下 在demo.php 中 您用了一个全局变量‘$handshake’ 来标记是否握手 好像这边会导致只有第一次连接的client能够成功连上,第二个client,第三个client的就连接不上了

3、我试过了可以改成 ,在把new socket变量加到全局变量$socket之后 ,就立即进行握手动作。 可以解决我之前遇到的只能第一个client连接上的问题。

websocket协议-细说WebSocket – Node篇

在上一篇提高到了 web 通信的各种方式,包括 轮询、长连接 以及各种 HTML5 中提到的手段。本文将详细描述 WebSocket协议 在 web通讯 中的实现。

一、WebSocket 协议

1. 概述

websocket协议允许不受信用的客户端代码在可控的网络环境中控制远程主机。该协议包含一个握手和一个基本消息分帧、分层通过TCP。简单点说,通过握手应答之后,建立安全的信息管道,这种方式明显优于前文所说的基于 XMLHttpRequest 的 iframe 数据流和长轮询。该协议包括两个方面,握手链接(handshake)和数据传输(data transfer)。

2. 握手连接

这部分比较简单,就像路上遇到熟人问好。

Client:嘿,大哥,有火没?(烟递了过去)
Server:哈,有啊,来~ (点上)
Client:火柴啊,也行!(烟点上,验证完毕)

握手连接中,client 先主动伸手:

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

客户端发了一串 Base64 加密的密钥过去,也就是上面你看到的 Sec-WebSocket-Key。 Server 看到 Client 打招呼之后,悄悄地告诉 Client 他已经知道了,顺便也打个招呼。

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat

Server 返回了 Sec-WebSocket-Accept 这个应答,这个应答内容是通过一定的方式生成的。生成算法是:

mask  = "258EAFA5-E914-47DA-95CA-C5AB0DC85B11";  // 这是算法中要用到的固定字符串
accept = base64( sha1( key + mask ) );

key 和 mask 串接之后经过 SHA-1 处理,处理后的数据再经过一次 Base64 加密。分解动作:

1. t = "GhlIHNhbXBsZSBub25jZQ==" + "258EAFA5-E914-47DA-95CA-C5AB0DC85B11"
   -> "GhlIHNhbXBsZSBub25jZQ==258EAFA5-E914-47DA-95CA-C5AB0DC85B11"
2. s = sha1(t) 
   -> 0xb3 0x7a 0x4f 0x2c 0xc0 0x62 0x4f 0x16 0x90 0xf6 
      0x46 0x06 0xcf 0x38 0x59 0x45 0xb2 0xbe 0xc4 0xea
3. base64(s) 
   -> "s3pPLMBiTxaQ9kYGzzhZRbK+xOo="

上面 Server 端返回的 HTTP 状态码是 101,如果不是 101 ,那就说明握手一开始就失败了~

下面就来个 demo,跟服务器握个手:

var crypto = require('crypto');

require('net').createServer(function(o){
    var key;
    o.on('data',function(e){
        if(!key){
            // 握手
            // 应答部分,代码先省略
            console.log(e.toString());
        }else{

        };
    });
}).listen(8000);

客户端代码:

var ws=new WebSocket("ws://127.0.0.1:8000");
ws.onerror=function(e){
  console.log(e);
};

上面当然是一串不完整的代码,目的是演示握手过程中,客户端给服务端打招呼。在控制台我们可以看到:

看起来很熟悉吧,其实就是发送了一个 HTTP 请求,这个我们在浏览器的 Network 中也可以看到:

但是 WebSocket协议 并不是 HTTP 协议,刚开始验证的时候借用了 HTTP 的头,连接成功之后的通信就不是 HTTP 了,不信你用 fiddler2 抓包试试,肯定是拿不到的,后面的通信部分是基于 TCP 的连接。

服务器要成功的进行通信,必须有应答,往下看:

//服务器程序
var crypto = require('crypto');
var WS = '258EAFA5-E914-47DA-95CA-C5AB0DC85B11';
require('net').createServer(function(o){
    var key;
    o.on('data',function(e){
        if(!key){
            //握手
            key = e.toString().match(/Sec-WebSocket-Key: (.+)/)[1];
            key = crypto.createHash('sha1').update(key + WS).digest('base64');
            o.write('HTTP/1.1 101 Switching Protocols\r\n');
            o.write('Upgrade: websocket\r\n');
            o.write('Connection: Upgrade\r\n');
            o.write('Sec-WebSocket-Accept: ' + key + '\r\n');
            o.write('\r\n');
        }else{
            console.log(e);
        };
    });
}).listen(8000);

关于crypto模块,可以看看官方文档,上面的代码应该是很好理解的,服务器应答之后,Client 拿到 Sec-WebSocket-Accept ,然后本地做一次验证,如果验证通过了,就会触发 onopen 函数。

//客户端程序
var ws=new WebSocket("ws://127.0.0.1:8000/");
ws.onopen=function(e){
    console.log("握手成功");
};

可以看到

3. 数据帧格式

官方文档提供了一个结构图

 0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-------+-+-------------+-------------------------------+
 |F|R|R|R| opcode|M| Payload len |    Extended payload length    |
 |I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |
 |N|V|V|V|       |S|             |   (if payload len==126/127)   |
 | |1|2|3|       |K|             |                               |
 +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
 |     Extended payload length continued, if payload len == 127  |
 + - - - - - - - - - - - - - - - +-------------------------------+
 |                               |Masking-key, if MASK set to 1  |
 +-------------------------------+-------------------------------+
 | Masking-key (continued)       |          Payload Data         |
 +-------------------------------- - - - - - - - - - - - - - - - +
 :                     Payload Data continued ...                :
 + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
 |                     Payload Data continued ...                |
 +---------------------------------------------------------------+

第一眼瞟到这张图恐怕是要吐血,如果大学修改计算机网络这门课应该不会对这东西陌生,数据传输协议嘛,是需要定义字节长度及相关含义的。

FIN      1bit 表示信息的最后一帧,flag,也就是标记符
RSV 1-3  1bit each 以后备用的 默认都为 0
Opcode   4bit 帧类型,稍后细说
Mask     1bit 掩码,是否加密数据,默认必须置为1 (这里很蛋疼)
Payload  7bit 数据的长度
Masking-key      0 or 4 bit 掩码
Payload data     (x + y) bytes 数据
Extension data   x bytes  扩展数据
Application data y bytes  程序数据
https://tools.ietf.org/html/rfc6455#section-5.2

 Masking-key:  0 or 4 bytes

      All frames sent from the client to the server are masked by a
      32-bit value that is contained within the frame.  This field is
      present if the mask bit is set to 1 and is absent if the mask bit
      is set to 0.  See Section 5.3 for further information on client-
      to-server masking.

每一帧的传输都是遵从这个协议规则的,知道了这个协议,那么解析就不会太难了,下面我就直接拿了次碳酸钴同学的代码。

4. 数据帧的解析和编码

数据帧的解析代码:

function decodeDataFrame(e){
  var i=0,j,s,frame={
    //解析前两个字节的基本数据
    FIN:e[i]>>7,Opcode:e[i++]&15,Mask:e[i]>>7,
    PayloadLength:e[i++]&0x7F
  };
  //处理特殊长度126和127
  if(frame.PayloadLength==126)
    frame.length=(e[i++]<<8)+e[i++];
  if(frame.PayloadLength==127)
    i+=4, //长度一般用四字节的整型,前四个字节通常为长整形留空的
    frame.length=(e[i++]<<24)+(e[i++]<<16)+(e[i++]<<8)+e[i++];
  //判断是否使用掩码
  if(frame.Mask){
    //获取掩码实体
    frame.MaskingKey=[e[i++],e[i++],e[i++],e[i++]];
    //对数据和掩码做异或运算
    for(j=0,s=[];j<frame.PayloadLength;j++)
      s.push(e[i+j]^frame.MaskingKey[j%4]);
  }else s=e.slice(i,frame.PayloadLength); //否则直接使用数据
  //数组转换成缓冲区来使用
  s=new Buffer(s);
  //如果有必要则把缓冲区转换成字符串来使用
  if(frame.Opcode==1)s=s.toString();
  //设置上数据部分
  frame.PayloadData=s;
  //返回数据帧
  return frame;
}

数据帧的编码:

//NodeJS
function encodeDataFrame(e){
  var s=[],o=new Buffer(e.PayloadData),l=o.length;
  //输入第一个字节
  s.push((e.FIN<<7)+e.Opcode);
  //输入第二个字节,判断它的长度并放入相应的后续长度消息
  //永远不使用掩码
  if(l<126)s.push(l);
  else if(l<0x10000)s.push(126,(l&0xFF00)>>2,l&0xFF);
  else s.push(
    127, 0,0,0,0, //8字节数据,前4字节一般没用留空
    (l&0xFF000000)>>6,(l&0xFF0000)>>4,(l&0xFF00)>>2,l&0xFF
  );
  //返回头部分和数据部分的合并缓冲区
  return Buffer.concat([new Buffer(s),o]);
}

有些童鞋可能没有明白,应该解析哪些数据。这的解析任务主要是服务端处理,客户端送过去的数据是二进制流形式的,比如:

var ws = new WebSocket("ws://127.0.0.1:8000/"); 
ws.onopen = function(){ 
  ws.send("握手成功"); 
};

Server 收到的信息是这样的:

一个放在Buffer格式的二进制流。而当我们输出的时候解析这个二进制流:

//服务器程序
var crypto = require('crypto');
var WS = '258EAFA5-E914-47DA-95CA-C5AB0DC85B11';
require('net').createServer(function(o){
    var key;
    o.on('data',function(e){
        if(!key){
            //握手
            key = e.toString().match(/Sec-WebSocket-Key: (.+)/)[1];
            key = crypto.createHash('sha1').update(key + WS).digest('base64');
            o.write('HTTP/1.1 101 Switching Protocols\r\n');
            o.write('Upgrade: websocket\r\n');
            o.write('Connection: Upgrade\r\n');
            o.write('Sec-WebSocket-Accept: ' + key + '\r\n');
            o.write('\r\n');
        }else{
            // 输出之前解析帧
            console.log(decodeDataFrame(e));
        };
    });
}).listen(8000);

那输出的就是一个帧信息十分清晰的对象了:

5. 连接的控制

上面我买了个关子,提到的Opcode,没有详细说明,官方文档也给了一张表:

 |Opcode  | Meaning                             | Reference |
-+--------+-------------------------------------+-----------|
 | 0      | Continuation Frame                  | RFC 6455  |
-+--------+-------------------------------------+-----------|
 | 1      | Text Frame                          | RFC 6455  |
-+--------+-------------------------------------+-----------|
 | 2      | Binary Frame                        | RFC 6455  |
-+--------+-------------------------------------+-----------|
 | 8      | Connection Close Frame              | RFC 6455  |
-+--------+-------------------------------------+-----------|
 | 9      | Ping Frame                          | RFC 6455  |
-+--------+-------------------------------------+-----------|
 | 10     | Pong Frame                          | RFC 6455  |
-+--------+-------------------------------------+-----------|

decodeDataFrame 解析数据,得到的数据格式是:

{
    FIN: 1,
    Opcode: 1,
    Mask: 1,
    PayloadLength: 4,
    MaskingKey: [ 159, 18, 207, 93 ],
    PayLoadData: '握手成功'
}

那么可以对应上面查看,此帧的作用就是发送文本,为文本帧。因为连接是基于 TCP 的,直接关闭 TCP 连接,这个通道就关闭了,不过 WebSocket 设计的还比较人性化,关闭之前还跟你打一声招呼,在服务器端,可以判断frame的Opcode:

var frame=decodeDataFrame(e);
console.log(frame);
if(frame.Opcode==8){
    o.end(); //断开连接
}

客户端和服务端交互的数据(帧)格式都是一样的,只要客户端发送 ws.close(), 服务器就会执行上面的操作。相反,如果服务器给客户端也发送同样的关闭帧(close frame):

o.write(encodeDataFrame({
    FIN:1,
    Opcode:8,
    PayloadData:buf
}));

客户端就会相应 onclose 函数,这样的交互还算是有规有矩,不容易出错。

二、注意事项

1. WebSocket URIs

很多人可能只知道 ws://text.com:8888,但事实上 websocket 协议地址是可以加 path 和 query 的。

ws-URI = "ws:" "//" host [ ":" port ] path [ "?" query ]
wss-URI = "wss:" "//" host [ ":" port ] path [ "?" query ]

如果使用的是 wss 协议,那么 URI 将会以安全方式连接。 这里的 wss 大小写不敏感。

2. 协议中”多余”的部分(吐槽)

握手请求中包含Sec-WebSocket-Key字段,明眼人一下就能看出来是websocket连接,而且这个字段的加密方式在服务器也是固定的,如果别人想黑你,不会太难。

再就是那个 MaskingKey 掩码,既然强制加密了(Mask为1表示加密,加密方式就是 MaskingKey 与 PayLoadData 进行异或处理),还有必要让开发者处理这个东西么?直接封装到内部不就行了?

3. 与 TCP 和 HTTP 之间的关系

WebSocket协议是一个基于TCP的协议,就是握手链接的时候跟HTTP相关(发了一个HTTP请求),这个请求被Server切换到(Upgrade)websocket协议了。websocket把 80 端口作为默认websocket连接端口,而websocket的运行使用的是443端口。

三、参考资料

四、特别感谢

再次感谢 次碳酸钴 跟我交流了几个小时 : ),本文部分 node 代码参考自他的博客。

下次将以php作为后台,讲解websocket的相关知识。

细说WebSocket-php篇


文章部分内容纠正:

1、t = “GhlIHNhbXBsZSBub25jZQ==”,串最前面少了一个d
2、console.log(crypto.createHash(‘sha1’).update(‘dGhlIHNhbXBsZSBub25jZQ==258EAFA5-E914-47DA-95CA-C5AB0DC85B11’).digest(‘sha1’)); //输出:<SlowBuffer b3 7a 4f 2c c0 62 4f 16 90 f6 46 06 cf 38 59 45 b2 be c4 ea>,不像你的,前面带0x,你是怎么弄的?

3、解码部分:if(frame.PayloadLength==126) frame.length=(e[2]<<8) + e[3], i=4; //其中的frame.length,好像应该是frame.Payloadlength。下一行中也是。看了一下,次碳酸钴,那边已经改了。

4、编码部分:s.push(126,(l&0xFF00)>>2,l&0xFF); 其中的>>2,好像应该是>>8。下一行类似。

websocket协议-websocket简史

WebSocket 简介及应用实例

HTML5 的出现,标志着后 Flash 时代各种现代浏览器的集体爆发,也是谨防 Adobe 一家独大的各家厂商们,历经多年各自为战,想换个活法儿并终于达成一定共识后,所积kao累bei的技术的一次集中释放 — 正所谓 “H5 是个筐,什么都可以往里装”。

其中引人瞩目并被广泛支持的一项,就是此次要谈论的 WebSocket 了。本文将尝试说明它被用来解决什么问题,以及与久经沙场的“传统” Socket 又有什么异同等基础问题。

I. 定义及由来

望文而生义,面对 WebSocket 这个名称,web 无需做太多解释,傻傻分不清楚的 socket 看着也是相当的面熟;甭管有没有联系,先来了解一下也无妨:

(1.1) 传统的 Socket API

Socket 往往指的是 TCP/IP 网络环境中的两个连接端,以及为方便此类开发所设计的一组编程 API

如图,英文单词 “socket” 的字面原义是 “孔” 或 “插座”。

作为一个技术用语时,socket 通常取后一种意思,像一个多孔插座。用于描述一个通信链路两端的 IP 地址和端口等,可以用来实现不同设备之间的通信。SocketTCP Socket都是通用的叫法,中文一般习惯性的译作**“套接字”、“TCP套接字”** 等。

…至于为嘛把“插座儿”翻译成“套接字”,好奇的程序猿并不在少数,科考文章在文章底部参考链接中可以找到。

可以将服务端主机想象成一个布满各种插座的房间,每个插座有一个编号,有的插座提供 220 伏交流电,有的提供固定电话信号,有的则提供有线电视节目。客户端软件将插头接入不同编号的插座,就可以得到不同的服务

Socket API 所处的楼层

OSI 模型作为一种概念模型,由国际标准化组织(ISO)提出,一个试图使各种计算机在世界范围内互连为网络的标准框架。我们熟悉的 HTTP、FTP 等协议都工作在最顶端的应用层(Application Layer)。

而 **TCP/IP 协议族(Protocol Suite)**将软件通信过程抽象化为四个抽象层,常被视为是简化的七层OSI模型。当多个层次的协议共同工作时,类似数据结构中的堆栈,因此又被称为 TCP/IP 协议栈(Protocol Stack)

单说 TCP 的话,指的是面向连接的一种传输控制协议。TCP 连接之后,客户端和服务器可以互相发送和接收消息,在客户端或者服务器没有主动断开之前,连接一直存在,故称为长连接。

Socket 其实并不是一个标准的协议,而是应用层与 TCP/IP 协议族通信的中间软件抽象层,它是一组接口,工作位置基本在 OSI 模型会话层(第5层),是为了方便大家直接使用更底层协议(一般是 TCP 或 UDP )而存在的一个抽象层。

在设计模式中,Socket其实就是一个门面(facade)模式,它把复杂的 TCP/IP 协议族隐藏在 Socket API 后面,对用户来说,一组简单的接口就是全部,让 Socket 去组织数据,以符合指定的协议

最早的一套 Socket API 是采用 C 语言实现的,也就成为了 Socket 的事实标准。

常见的 Socket API 实现

一些语言的实现

传统的后端编程语言基本都有 Socket API 的封装;而在 HTML5 出现之前,要想用纯前端技术实现 TCP Socket 的客户端,也基本只有 Java Applet (java.net.Socketjava.net.DatagramSocketjava.net.MulticastSocket) 、Flash (flash.net.Socketflash.net.XMLSocket) 或 Silverlight(System.Net.Sockets) 等可以选择。

下面以 PHP 的 服务器/客户端 实现为例,演示一个最基础的例子:

<?php
//server.php

set_time_limit(0);
$ip = '127.0.0.1';
$port = 1999;
// 创建一个Socket
$sock = socket_create(AF_INET,SOCK_STREAM,SOL_TCP);
// 绑定Socket地址和端口
$ret = socket_bind($sock,$ip,$port);
// 开始监听链接
$ret = socket_listen($sock,4);

$count = 0; //最多接受几次请求后就退出
do {
	// 另一个Socket来处理通信
    if (($msgsock = socket_accept($sock)) >= 0) {        
        // 发到客户端
        $msg ="server: HELLO CLIENTS!\n";
        if (socket_write($msgsock, $msg, strlen($msg))) {
        	echo "发送成功!\n";
        }
        // 获得客户端的输入
        $buf = socket_read($msgsock,8192);
        
        $talkback = "接受成功!内容为:$buf\n";
        echo $talkback;
        
        if(++$count >= 5){
            break;
        };    
    }
    // 关闭sockets
    socket_close($msgsock);
} while (true);
socket_close($sock);
echo "TCP 连接关闭OK\n";
?>
<?php
//client.php

error_reporting(E_ALL);
set_time_limit(0);
$port = 1999;
$ip = "127.0.0.1";

// 创建Socket
$socket = socket_create(AF_INET, SOCK_STREAM, SOL_TCP);
// 绑定Socket地址和端口
$result = socket_connect($socket, $ip, $port);
if ($result >= 0) echo "TCP 连接OK\n";

$in = "client: HELLO SERVER!\r\n";
if(socket_write($socket, $in, strlen($in))) {
    echo "发送成功!\n";
}
$out = '';
while($out = socket_read($socket, 8192)) {
    echo "接受成功!内容为:",$out;
}

socket_close($socket);
echo "TCP 连接关闭OK\n";
?>

(1.2) HTML5 带来的 WebSocket 协议

WebSockets 为 C/S 两端提供了实时交互通信的能力,允许服务器主动发送信息给客户端,是一种区别于 HTTP 的全新双向数据流协议

简单的说,传统的 TCP Socket 是一套相对标准化的 API,而出现时间不久的 WebSocket 是一种网络协议 — 两码事。

WebSocket 底层是基于 TCP 协议的,所以早期草案中叫做 TCPConnection,最后之所以改名,其实是借用了传统 Socket 沟通 TCP 网络两端的意思而已。

要解决的问题

*HTTP 的工作方式*
在基于 请求/响应 模式的 HTTP/HTTPS 下,如果是对实时性要求较高的场景,客户端就需要不停的询问服务端有无可用的数据,这在各方面都是笨拙而不划算的。

*WebSocket 的工作方式*
而在 WebSocket 的全双工(允许数据在两个方向上同时传输)方式下,客户端只要静静地听招呼即可,有可用数据时服务端会自动通知它。

WebSocket 的用武之地

大部分传统的方式既浪费带宽(HTTP HEAD 是比较大的),又消耗服务器 CPU 占用(没有信息也要接受请求);而 WebSocket 则会大幅降低上述的消耗,更适用于以下场景:

  • 实时性要求高的应用
  • 聊天室
  • IoT (物联网 – internet of things)
  • 在线多人游戏

兼容性也令人满意,非要说何时不适用的话,大概就是少数必须兼容老旧浏览器,或者对实时要求明显不高的情况下了。

HTTP 的扩展

WebSocket 连接的 URL 使用 ws://wss:// 等开头,其加密、cookie 等策略和对应的 HTTP/HTTPS 基本相同。

HTTP、WebSocket 等应用层协议,都是基于 TCP 协议来传输数据的,可以把这些高级协议理解成对 TCP 的封装。


Websocket协议是为了解决web即时应用中服务器与客户端浏览器全双工通信的问题而设计的,是完全意义上的Web应用端的双向通信技术,可以取代之前使用半双工HTTP协议而模拟全双工通信,同时克服了带宽和访问速度等的诸多问题。协议定义为ws和wss协议,分别为普通请求和基于SSL的安全传输,占用端口与http协议系统,ws为80端口,wss为443端口,这样可以支持HTTP代理。

协议包含两个部分,第一个是“握手”,第二个是数据传输。

一、Websocket URI

定义的两个协议框架ws和wss与http类似,而且各自部分的要求也是在HTTP协议中使用的一样,各自的URI如下:

ws-URI = “ws:” “//” host [ “:” port ] path [ “?” query ]
wss-URI = “wss:” “//” host [ “:” port ] path [ “?” query ]

其中port是可选项,query前接“?”。

二、握手(Opening & Closing Handshake)打开连接

当建立一个Websocket连接时,为了保持基于HTTP协议的服务器软件和中间件进行兼容工作,客户端打开一个连接时使用与HTTP连接的同一个端口到服务器进行连接,这样被设计为一个升级的HTTP请求。

1、发送握手请求

此时的连接状态是CONNECTING,客户端需要提供host、port、resource-name和一个是否是安全连接的标记,也就是一个WebSocket URI。

客户端发送的一个到服务器端握手请求如下:

 

        GET /chat HTTP/1.1
        Host: server.example.com
        Upgrade: websocket
        Connection: Upgrade
        Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
        Origin: http://example.com
        Sec-WebSocket-Protocol: chat, superchat
        Sec-WebSocket-Version: 13

这个升级的HTTP请求头中的字段顺序是可以随便的。与普通HTTP请求相比多了一些字段。

    • Connection必须设置Upgrade,表示客户端希望连接升级。
    • Upgrade字段必须设置Websocket,表示希望升级到Websocket协议。
    • Sec-WebSocket-Key是随机的字符串,服务器端会用这些数据来构造出一个SHA-1的信息摘要。把“Sec-WebSocket-Key”加上一个特殊字符串“258EAFA5-E914-47DA-95CA-C5AB0DC85B11”,然后计算SHA-1摘要,之后进行BASE-64编码,将结果做为“Sec-WebSocket-Accept”头的值,返回给客户端。如此操作,可以尽量避免普通HTTP请求被误认为Websocket协议。
    • Sec-WebSocket-Version 表示支持的Websocket版本。RFC6455要求使用的版本是13,之前草案的版本均应当弃用。
    • Origin字段是可选的,通常用来表示在浏览器中发起此Websocket连接所在的页面,类似于Referer。但是,与Referer不同的是,Origin只包含了协议和主机名称。
    • 其他一些定义在HTTP协议中的字段,如Cookie等,也可以在Websocket中使用。
    • Sec-WebSocket-Protocol:字段表示客户端可以接受的子协议类型,也就是在Websocket协议上的应用层协议类型。上面可以看到客户端支持chat和superchat两个应用层协议,当服务器接受到这个字段后要从中选出一个协议返回给客户端。
发送请求的要求:
  • 请求的WebSocket URI必须要是定义的有效的URI。
  • 如果客户端已经有一个WebSocket连接到远程服务器端,不论是否是同一个服务器,客户端必须要等待上一个连接关闭后才能发送新的连接请求,也就是同一客户端一次只能存在一个WebSocket连接。如果想同一个服务器有多个连接,客户端必须要串行化进行。如果客户端检测到多个到不同服务器的连接,应该限制一个最大连接数,在web浏览器中应该设定最多可以打开的标签页的数目。这样可以防止到远程服务器的DDOS攻击,但这是对到多个服务器的连接,如果是到同一个服务器连接,并没有数目限制。
  • 如果使用了代理服务器,那么客户端建立连接的时候需要告知代理服务器向目标服务器打开TCP连接。
  • 如果连接没有打开,一定是某一方出现错误,此时客户端必须要关闭再次连接的尝试。
  • 连接建立后,握手必须要是一个有效的HTTP请求
  • 请求的方式必须是GET,HTTP协议的版本至少是1.1
  • Upgrade字段必须包含而且必须是”websocket”,Connection字段必须内容必须是“Upgrade”
  • Sec-Websocket-Version必须,而且必须是13 (固定版本号)

2、返回握手应答

服务器返回正确的相应头后,客户端验证后将建立连接,此时状态为OPEN。服务器响应头如下:
        HTTP/1.1 101 Switching Protocols
        Upgrade: websocket
        Connection: Upgrade
        Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
        Sec-WebSocket-Protocol: chat

响应头握手过程中是服务器返回的是否同意握手的依据。

  • 首行返回的是HTTP/1.1协议版本和状态码101,表示变换协议(Switching Protocol)
  • Upgrade 和 Connection:这两个字段是服务器返回的告知客户端同意使用升级并使用websocket协议,用来完善HTTP升级响应
  • Sec-WebSocket-Accept:服务器端将加密处理后的握手Key通过这个字段返回给客户端表示服务器同意握手建立连接。
  • Sec-Websocket-Procotol:服务器选择的一个应用层协议。

上述响应头字段被客户端浏览器解析,如果验证到Sec-WebSocket-Accept字段的信息符合要求就会建立连接,同时就可以发送WebSocket的数据帧了。如果该字段不符合要求或者为空或者HTTP状态码不为101,就不会建立连接。

服务器端响应步骤:
  • 解析握手请求头:获取握手依据Key并进行处理,检测HTTP的GET请求和版本是否准确,Host字段是否有权限,Upgrade字段中websocket是一个与大小写无关的ASCII字符串,Connection字段是一个大小写无关的”Upgrade”ASCII字符串,Websocket协议版本必须为13,其他的关于Origin、Protocol和Extensions可选。
  • 发送握手响应头:检测是否是wss协议连接,如果是就是用TLS握手连接,否则就是普通连接。服务器可以添加额外的验证信息到客户端进行验证。当进行一系列验证之后,服务器必须返回一个有效的HTTP响应头。响应头中每一行一个字段,结束必须为“\r\n”,使用的ABNF语法。
除了上述必要头字段之外,其他的HTTP协议定义的字段都可以使用,如Set-Cookie等。
websocket 采用 帧格式传输数据,详见  有关 websocket 基础 的博客。

 浏览器中的实现

在浏览器中可以直接调用 WebSocket 对象,其定义如下:

enum BinaryType { "blob", "arraybuffer" };
[Constructor(USVString url, optional (DOMString or sequence<DOMString>) protocols = []), Exposed=(Window,Worker)]
interface WebSocket : EventTarget {
  readonly attribute USVString url;

  // ready state
  const unsigned short CONNECTING = 0;
  const unsigned short OPEN = 1;
  const unsigned short CLOSING = 2;
  const unsigned short CLOSED = 3;
  readonly attribute unsigned short readyState;
  readonly attribute unsigned long long bufferedAmount;

  // networking
  attribute EventHandler onopen;
  attribute EventHandler onerror;
  attribute EventHandler onclose;
  readonly attribute DOMString extensions;
  readonly attribute DOMString protocol;
  void close([Clamp] optional unsigned short code, optional USVString reason);

  // messaging
  attribute EventHandler onmessage;
  attribute BinaryType binaryType;
  void send(USVString data);
  void send(Blob data);
  void send(ArrayBuffer data);
  void send(ArrayBufferView data);
};

使用起来大概是这样的:

var ws = new WebSocket('ws://www.xxx.com/some.php');
ws.send('xxx'); //每次只能发送字符串
ws.onmessage = function(event) {
	var data = event.data;
};
ws.onerror = function() {
	ws.close();
};

II. 一个多用户交互的 WebSocket 实例

这里随便设想一个用户场景,比如我们要做一个在线纸牌游戏,肯定就是一个多人进入同一个房间的形式,并且每个人的动作能广播给其他人。

下面用 WebSocket 做一个最基础的验证原型,让每个玩家知道其他人的进入、离开、出牌、悔牌,甚至是耍赖换牌等:

(2.1) 服务器端的实现

我们用 nodejs+expressjs 搭建基础服务器,并用 https://github.com/websockets/ws 封装的库实现 WebSocket 协议的服务器端逻辑:

// server.js

var express = require('express')
var ws = require('./ws')

var app = express()

app.get('/', function (req, res) {
    res.sendFile(__dirname + '/ws.html');
})

app.listen(3000, function () {
  console.log('Example app listening on port 3000!')
})
// ws.js

const { Server, OPEN } = require('ws');

const clients = []; //array of websocket clients
const cardsArr = []; //array of {cardId, count, title, ...}

let _lock = false;

const wss = new Server({port: 40510})
wss.on('connection', function (ws) {

	const _cid = clients.push(ws) - 1;

	ws.on('message', function (json) {

		const {
			act,
			cid,
			data
		} = JSON.parse(json);

		switch (act) {
			case 'client:join':
				_onCustomerJoin(ws, _cid);
				break;
			case 'client:leave':
				_onCustomerLeave(cid);
				break;
			case 'client:add': //增加牌
				_onAddCard(cid, data);
				break;
			case 'client:update': //修改牌
				_onUpdateCard(cid, data);
				break;
			case 'client:remove': //删除牌
				_onRemoveCard(cid, data);
				break;
			case 'client:win': //下单
				_onWin(cid);
				break;
			default:
				console.log('received: %s', act, cid)
				break;
		}

	});
});

function _ensureLock(func) {
	return function() {
		if (_lock) return;
		_lock = true;
		const rtn = func.apply(null, arguments);
		_lock = false;
		return rtn;
	};
}

function _findCard(cardId) {
	const cidx = cardsArr.map(Card=>Card.cardId).indexOf(cardId);
	return cidx;
}

const _broadcast = (excludeId, msg, data=null)=>{
	clients.forEach( (client, cidx)=>{
		if (cidx === excludeId) return;
		if (client && client.readyState === OPEN) {
			client.send(JSON.stringify({
				act: 'server:broadcast',
				msg: msg,
				data: data
			}));
		}
	} );
};

const _onCustomerJoin = (ws, cid)=>{
	ws.send(JSON.stringify({
		act: 'server:regist',
		data: {
			cid: cid
		}
	}));
	_broadcast(cid, '玩家加入:', {cid: cid});
};
const _onCustomerLeave = (cid)=>{
	clients[cid].terminate();
	clients.splice(cid, 1);
	_broadcast(cid, '玩家退出:', {cid: cid});
};
const _onAddCard = _ensureLock( (cid, data)=>{
	const d = _findCard(data.cardId);
	if (d !== -1) {
		cardsArr.splice(d, 1);
	}
	cardsArr.push(data);
	_broadcast(-1, '玩家添加了牌', {
		cid: cid,
		Card: data,
		cardsArr: cardsArr
	});
} );
const _onUpdateCard = _ensureLock( (cid, data)=>{
	const d = _findCard(data.cardId);
	if (d === -1) return;
	cardsArr[d] = data;
	_broadcast(-1, '玩家更改了牌', {
		cid: cid,
		Card: data,
		cardsArr: cardsArr
	});
} );
const _onRemoveCard = _ensureLock( (cid, data)=>{
	const d = _findCard(data.cardId);
	if (d === -1) return;
	cardsArr.splice(d, 1);
	_broadcast(-1, '玩家删除了牌', {
		cid: cid,
		Card: data,
		cardsArr: cardsArr
	});
} );
const _onWin = _ensureLock( (cid)=>{
	//do sth. here
	_broadcast(cid, '玩家胡牌了');
} );

(2.2) 客户端的实现

<h1></h1>
<div></div>

<button onclick="_add()">出牌</button>
<button onclick="_update()">换牌</button>
<button onclick="_remove()">悔牌</button>
<button onclick="_win()">胡牌</button>
<button onclick="_leave()">离开</button>

<script>
    let cid = null; 

    const ws = new WebSocket('ws://localhost:40510');

    ws.onopen = function () {
        console.log('websocket is connected ...');

        _send({
            act: 'client:join'
        });
    };

    ws.onmessage = function (ev) {
        
        const {
            act,
            msg,
            data
        } = JSON.parse(ev.data);

        switch(act) {
            case 'server:regist':
                cid = data.cid;
                console.log(`regist: cid is ${cid}`);
                document.querySelector('h1').innerHTML = 'I AM: ' + cid;
                break;
            case 'server:broadcast':
                console.log('从服务器端接收的广播:', msg, data);
                if (data && data.cardsArr) {
                    document.querySelector('div').innerHTML = JSON.stringify(
                        data.cardsArr, null, 4
                    );
                }
                break;
            default:
                console.log(ev);
                break;
        }
    }

    function _send(json) {
        ws.send(JSON.stringify(json));
    }

    function _add() {
        _send({
            act: 'client:add',
            cid: cid,
            data: {
                cardId: 111,
                count: 1,
                title: '红桃A'
            }
        })
    }
    function _update() {
        _send({
            act: 'client:update',
            cid: cid,
            data: {
                cardId: 111,
                count: 2,
                title: '黑桃9'
            }
        })
    }
    function _remove() {
        _send({
            act: 'client:remove',
            cid: cid,
            data: {
                cardId: 111
            }
        })
    }
    function _win() {
        _send({
            act: 'client:win',
            cid: cid
        })
    }
    function _leave() {
        _send({
            act: 'client:leave',
            cid: cid
        })
    }
</script>

(2.3) 运行效果

玩家 0 加入:

玩家 1 加入:

玩家 1 出牌:

玩家 1 胡牌并退出:

与 WebSocket 类似的技术

实际上,每当谈到实时双向通信的问题时,我们自然会想起历年来一些基于 HTTP 技术的尝试;也正是基于这些之前工作中的实践和困扰,WebSocket 才应运而生。让我们大概回顾一下相关的方案及其缺陷:

轮询 (Polling)

借助于 setInterval() 等方式,客户端不断的发送请求并得到响应。这种做法比较简单,可以在一定程度上解决问题。不过对于轮询的时间间隔需要进行仔细考虑。轮询的间隔过长,会导致用户不能及时接收到更新的数据;轮询的间隔过短,会导致查询请求过多,增加服务器端的负担。

长轮询 (Long Polling)

这是对轮询的一种改进。客户端发出请求后,服务器端用 while(true) 等方式阻塞住请求,直到有可用数据才发送响应数据,而客户端收到响应后再发送下一个请求。

这种方式又被成为 “Hanging GET”、“反向 Ajax” 或 “Comet” 等,虽然看上去很像服务器推送,但仍然是基于 HTTP 的一种慢响应;且在数据更新频繁的情况下,其效率并不优于一般的轮询。

HTTP 流 (Streaming)

使用 HTTP 1.1 且响应头中包含 Transfer-Encoding: chunked 的情况下,服务器发送给客户端的数据可以分成多个部分,保持打开(while-true, sleep等),并周期性 flush() 分块传输。

客户端只发送一个HTTP连接,在 xhr.readyState==3 状态下,用 xhr.responseText.substring 获取每次的数据。

但是数据响应可能会因 代理服务器 或 防火墙 等中间人造成延迟,所以可能还要额外探测这种情况以切换到长轮询方式。

SSE (Server-Sent Events)

SSE 规范也是 HTML 5 规范的一个组成部分。服务器端响应的内容类型是text/event-stream,在浏览器端使用 EventSource 对象处理返回的数据。

比之于 WebSocket,SSE 的缺点在于:

  • 不支持 CORS
  • 单向通道,只能服务器向浏览器端发送
  • 浏览器兼容性稍差

III. 总结

  • 传统的 TCP Socket 往往指的是 TCP/IP 网络环境中的两个连接端,以及为方便此类开发所设计的一组编程 API
  • WebSockets 为 C/S 两端提供了实时交互通信的能力,允许服务器主动发送信息给客户端
  • WebSockets 是 HTML 5 规范的一个组成部分,是一种区别于 HTTP 的全新双向数据流协议
  • 全双工通信的 WebSockets 有效改善了之前 长轮询 等方式的弊端
  • WebSockets 适用于实时性要求高的应用、聊天室、多人游戏等

参考:

https://juejin.im/post/5ae3eb9b51882567382f5767

https://www.cnblogs.com/oshyn/p/3574497.html


http://www.cnblogs.com/hustskyking/p/websocket-with-node.html

http://www.cnblogs.com/hustskyking/p/websocket-with-php.html

https://www.cnblogs.com/zxtceq/p/6963964.html

web通信方式-概述和总结

web通信,一个特别大的topic,涉及面也是很广的。因最近学习了 javascript 中一些 web 通信知识,在这里总结下。文中应该会有理解错误或者表述不清晰的地方,还望斧正!

一、前言


1. comet技术

浏览器作为 Web 应用的前台,自身的处理功能比较有限。浏览器的发展需要客户端升级软件,同时由于客户端浏览器软件的多样性,在某种意义上,也影响了浏览器新技术的推广。在 Web 应用中,浏览器的主要工作是发送请求、解析服务器返回的信息以不同的风格显示。AJAX 是浏览器技术发展的成果,通过在浏览器端发送异步请求,提高了单用户操作的响应性。但 Web 本质上是一个多用户的系统,对任何用户来说,可以认为服务器是另外一个用户。现有 AJAX 技术的发展并不能解决在一个多用户的 Web 应用中,将更新的信息实时传送给客户端,从而用户可能在“过时”的信息下进行操作。而 AJAX 的应用又使后台数据更新更加频繁成为可能。

随着互联网的发展,web 应用层出不穷,也不乏各种网站监控、即时报价、即时通讯系统,为了让用户得到更好的体验,服务器需要频繁的向客户端推送信息。开发者一般会采用基于 AJAX 的长轮询方式或者基于 iframe 及 htmlfile 的流方式处理。当然有些程序需要在客户端安装各种插件( Java applet 或者 Flash )来支持性能比较良好的“推”信息。

2. HTTP协议中的长、短连接

短连接的操作步骤是:建立连接——数据传输——关闭连接…建立连接——数据传输——关闭连接
长连接的操作步骤是:建立连接——数据传输…(保持连接)…数据传输——关闭连接

长连接与短连接的不同主要在于client和server采取的关闭策略不同。短连接在建立连接以后只进行一次数据传输就关闭连接,而长连接在建立连接以后会进行多次数据数据传输直至关闭连接(长连接中关闭连接通过Connection:closed头部字段)。

二、web 通信


首先要搞清楚,xhr 的 readystate 各种状态。

属性 描述
onreadystatechange 存储函数(或函数名),每当 readyState 属性改变时,就会调用该函数。
readyState 存有 XMLHttpRequest 的状态。从 0 到 4 发生变化。

0: 请求未初始化
1: 服务器连接已建立
2: 请求已接收
3: 请求处理中
4: 请求已完成,且响应已就绪

status 200: “OK”
404: 未找到页面

1.轮询

轮询是一种“拉”取信息的工作模式。设置一个定时器,定时询问服务器是否有信息,每次建立连接传输数据之后,链接会关闭。

前端实现:

var polling = function(url, type, data){
    var xhr = new XMLHttpRequest(), 
        type = type || "GET",
        data = data || null;

    xhr.onreadystatechange = function(){
        if(xhr.readyState == 4) {
            receive(xhr.responseText);
            xhr.onreadystatechange = null;
        }
    };

    xhr.open(type, url, true);
    //IE的ActiveXObject("Microsoft.XMLHTTP")支持GET方法发送数据,
    //其它浏览器不支持,已测试验证
    xhr.send(type == "GET" ? null : data);
};

var timer = setInterval(function(){
    polling();
}, 1000);

在轮询的过程中,如果因为网络原因,导致上一个 xhr 对象还没传输完毕,定时器已经开始了下一个询问,上一次的传输是否还会在队列中,这个问题我没去研究。如果感兴趣可以自己写一个ajax的请求管理队列。(研究结果:后一个会把前一个覆盖掉 即前一个就算返回 也不会认了)

2.长轮询(long-polling)

长轮询其实也没啥特殊的地方,就是在xhr对象关闭连接的时候马上又给他接上~ 看码:

var longPoll = function(type, url){
    var xhr = new XMLHttpRequest();

    xhr.onreadystatechange = function(){
        // 状态为 4,数据传输完毕,重新连接
        if(xhr.readyState == 4) {
            receive(xhr.responseText);
            xhr.onreadystatechange = null;

            longPoll(type, url);
        }
    };

    xhr.open(type, url, true);
    xhr.send();
}

只要服务器断开连接,客户端马上连接,不让他有一刻的休息时间,这就是长轮询。

3.数据流

数据流方式,在建立的连接断开之前,也就是 readystate 状态为 3 的时候接受数据,但是麻烦的事情也在这里,因为数据正在传输,你拿到的 xhr.response 可能就是半截数据,所以呢,最好定义一个数据传输的协议,比如前2个字节表示字符串的长度,然后你只获取这个长度的内容,接着改变游标的位置。

假如数据格式为: data splitChar   data为数据内容,splitChar为数据结束标志(长度为1)。 那么传输的数据内容为 data splitChar data splitChar data splitChar…

var dataStream = function(type, url){
    var xhr = new XMLHttpRequest();

    xhr.onreadystatechange = function(){

        // 状态为 3,数据接收中
        if(xhr.readyState == 3) {
            var i, l, s;

            s = xhr.response; //读取数据
            l = s.length;     //获取数据长度

            //从游标位置开始获取数据,并用分割数据
            s = s.slice(p, l - 1).split(splitChar);

            //循环并操作数据
            for(i in s) if(s[i])  deal(s[i]);

            p = l;  //更新游标位置

        }

        // 状态为 4,数据传输完毕,重新连接
        if(xhr.readyState == 4) {
            xhr.onreadystatechange = null;

            dataStream(type, url);
        }
    };

    xhr.open(type, url, true);
    xhr.send();
};

这个代码写的是存在问题的,当readystate为3的时候可以获取数据,但是这时获取的数据可能只是整体数据的一部分,那后半截就拿不到了。readystate在数据传输完毕之前是不会改变的,也就是说他并不会继续接受剩下的数据。我们可以定时去监听readystate,这个下面的例子中可以看到。

这样的处理不算复杂,但是存在问题。上面的轮询和长轮询是所有浏览器都支持的,所以我就没有写兼容IE的代码,但是这里,低版本IE不允许在readystate为3的时候读取数据,所以我们必须采用其他的方式来实现。

在ajax还没有进入web专题之前,我们已经拥有了一个法宝,那就是iframe,利用iframe照样可以异步获取数据,对于低版本IE可以使用iframe来接受数据流。

if(isIE){
    var dataStream = function(url){
        var ifr = document.createElement("iframe"), doc, timer;

        ifr.src = url;
        document.body.appendChild(ifr);

        doc = ifr.contentWindow.document;

        timer = setInterval(function(){

            if(ifr.readyState == "interactive"){
                // 处理数据,同上
            }

            // 重新建立链接
            if(ifr.readyState == "complete"){
                clearInterval(timer);

                dataStream(url);
            }
        }, 16);
    };
};

定时去监听iframe的readystate的变化,从而获取数据流,不过,上面的处理方式还是存在问题。数据流实现“服务器推”数据的原理是什么呢,简单点说,就是文档(数据)还没有加载完,这个时候浏览器的工作就是去服务器拿数据完成文档(数据)加载,我们就是利用这点,给浏览器塞点东西过去~ 所以上述利用iframe的方式获取数据,会使浏览器一直处于加载状态,title上的那个圈圈一直在转动,鼠标的状态也是loading,这看着是相当不爽的。幸好,IE提供了HTMLFile对象,这个对象就相当于一个内存中的Document对象,它会解析文档。所以我们创建一个HTMLFile对象,在里面放置一个IFRAME来连接服务器。这样,各种浏览器就都支持了。

if(isIE){
    var dataStream = function(url){
        var doc = new ActiveXObject("HTMLFile"), 
            ifr = doc.createElement("iframe"), 
            timer, d;

        doc.write("<body/>");

        ifr.src = url;
        doc.body.appendChild(ifr);

        d = ifr.contentWindow.document;

        timer = setInterval(function(){

            if(d.readyState == "interactive"){
                // 处理数据,同上
            }

            // 重新建立链接
            if(d.readyState == "complete"){
                clearInterval(timer);

                dataStream(url);
            }
        }, 16);
    };
};

4.websocket

websocket是前端一个神器,ajax用了这么久了,相关技术也是很成熟,不过要实现个数据的拉取确实十分不易,从上面的代码中也看到了,各种兼容性问题,各种细节处理问题,自从有了websocket,哈哈,一口气上五楼…

var ws = new WebSocket("ws://www.example.com:8888");

ws.onopen = function(evt){};
ws.onmessage = function(evt){
    deal(evt.data);
};
ws.onclose  = function(evt){};

//ws.close();

新建一个WebSocket实例,一切就OK了,ws:// 是websocket的连接协议,8888为端口号码。onmessage中提供了data这个属性,相当方便。

(WebSocket一种在单个 TCP 连接上进行全双工通讯的协议。WebSocket通信协议于2011年被IETF定为标准RFC 6455,并被RFC7936所补充规范,WebSocketAPI被W3C定为标准。)

5.EventSource

HTML5中提供的EventSource这玩意儿,这是无比简洁的服务器推送信息的接受函数。

new EventSource("test.php").onmessage=function(evt){
    console.log(evt.data);
};

简洁程度和websocket是一样的啦,只是这里有一个需要注意的地方,test.php输出的数据流应该是特殊的MIME类型,要求是”text/event-stream”,如果不设置的话,你试试~ (直接抛出异常)

6.ActionScript

情非得已就别考虑这第六种方式了,虽说兼容性最好,要是不懂as,出了点bug你也不会调试。

具体实现方法:在 HTML 页面中内嵌入一个使用了 XMLSocket 类的 Flash 程序。JavaScript 通过调用此 Flash 程序提供的套接口接口与服务器端的套接口进行通信。JavaScript 在收到服务器端以 XML 格式传送的信息后可以很容易地控制 HTML 页面的内容显示。flash现在差不多也快淘汰了)

7.Java Applet套接口

这玩意儿原理和Flash类似,不过我不懂,就不细说了。(Java Applet现在差不多也快淘汰了)

三、后端处理方式


本文主要是总结Javascript的各种通讯方式,后端配合node来处理,应该是挺给力的。

var conns = new Array();

var ws = require("websocket-server");
var server = ws.createServer();

server.addListener("connection", function(connection){
  console.log("Connection request on Websocket-Server");
  conns.push(connection);
  connection.addListener('message',function(msg){
        console.log(msg);
        for(var i=0; i<conns.length; i++){
            if(conns[i]!=connection){
                conns[i].send(msg);
            }
        }
    });
});
server.listen(8888);

下面是一个php的测试demo。

header('Content-Type:text/html; charset=utf-8');
while(1){
    echo date('Y-m-d H:i:s');
    flush();
    sleep(1);
};

四、web 通信方式利弊分析

  • 轮询,这种方式应该是最没技术含量的,操作起来最方便,不过是及时性不强,把定时器的间隔时间设置的短一些可以稍微得到缓和。
  • 长轮询,算是比较不错的一个web通讯方式,不过每次断开连接,比较耗服务器资源,客户端到无所谓。
  • 数据流,他和长轮询不同之处是接受数据的时间不一样,数据流是readystate为3的时候接受,低版本IE不太兼容,处理起来略麻烦,而且还要自己设计数据传输协议。不过他对资源的消耗比上面几种都可观。
  • websocket和EventSource,两个利器,不过,没几个浏览器支持,这是比较让人伤心~(现在2018年,主流浏览器都支持了,毕竟原博客2013年发的)
  • ActionScript和Java Applet,两者都是需要在客户端安装插件的,一个是Flash插件,一个是Java插件,而且搞前端的人一般对这东西不太熟悉,如果没有封装比较好的库可以使用,那建议还是别用了。

五、参考资料


来自:http://www.cnblogs.com/hustskyking/p/web-communication.html

http协议-headers-各字段详解

Cache-Control:must-revalidate, no-cache, private。

这个值告诉客户端,服务端不希望客户端缓存资源,在下次请求资源时,必须要从新请求服务器,不能从缓存副本中获取资源。
Cache-Control是响应头中很重要的信息,当客户端请求头中包含Cache-Control:max-age=0请求,明确表示不会缓存服务器资源时,Cache-Control作为作为回应信息,通常会返回no-cache,意思就是说,“不缓存就不缓存呗”;当客户端在请求头中没有包含Cache-Control时,服务端往往会定,不同的资源不同的缓存策略,比如说oschina在缓存图片资源的策略就是Cache-Control:max-age=86400,这个意思是,从当前时间开始,在86400秒的时间内,客户端可以直接从缓存副本中读取资源,而不需要向服务器请求。

Connection:keep-alive

这个字段作为回应客户端的Connection:keep-alive,告诉客户端服务器的tcp连接也是一个长连接,客户端可以继续使用这个tcp连接发送http请求。关于长连接的更多知识,后面我再详细讲。

Content-Encoding:gzip

告诉客户端,服务端发送的资源是采用gzip编码的,客户端看到这个信息后,应该采用gzip对资源进行解码。

Content-Type:text/html;charset=UTF-8

告诉客户端,资源文件的类型,还有字符编码,客户端通过utf-8对资源进行解码,然后对资源进行html解析。通常我们会看到有些网站是乱码的,往往就是服务器端没有返回正确的编码。

Content-type: text/html; charset=xxx的优先级要高于
<META http-equiv=”content-type” content=”text/html; charset=xxx”>
因为一个在headers中,一个在网页中。浏览器响应时,有时候是json文件,pdf文件等,这些文件里面没有设置编码,不像网页文件内部可以设置编码。所以headers中的>Content-type 优先级更高。

服务器可以设置响应文件的编码,其实功能相当于在 headers中设置 Content-type。如果headers已经有了Content-type,那就按服务器设置的方案,修改编码方式。

对于网页编码,headers中Content-type: text/html; charset=xxx;可以不用指定charset=xxx;因为网页内部也可以设置编码方案。

当时做了一个简易的web服务器,关键细节总结。

返回消息时,http 请求头和请求体 之间 需要 加 一个  【回车+换行】两个步骤。当然,java里面就一句  xxx.println();

当时,输出响应头时:

xxx.println(“Content-Type: text/css”); 这个css的类型,没有单独写。只是用if else 单独判断输出了   text/html   text/javascript   text/png    image/jpeg   image/gif  ,其他的 一律输出  application/octet-stream  类型。所以一开始,请求 css 文件 时,响应头是  application/octet-stream  类型。然后,浏览器加载网页时,居然没有加载 css 文件。因为它认为 下载 的css文件,类型不对。所以网页渲染时,页面布局 混乱了。后来改成 输出 Content-Type: text/css 时,页面渲染成功了。

ETAG:字符串(出现在http1.1协议中,可选字段)

ETag在HTTP头字段中的使用是可选的(不像HTTP/1.1的其他头字段是强制性的)。HTTP规范从未指定生成ETag的方法。

ETag又叫实体标签(entity tag)是HTTP协议提供的若干机制中的一种Web缓存验证机制,并且允许客户端进行缓存协商。这就使得缓存变得更加高效,而且节省带宽。如果资源的内容没有发生改变,Web服务器就不需要发送一个完整的响应。ETag也可用于乐观并发控制,作为一种防止资源同步更新而相互覆盖的方法。

ETag是一个不透明的标识符,由Web服务器根据URL上的资源的特定版本而指定。如果那个URL上的资源内容改变,一个新的不一样的ETag就会被分配。用这种方法使用ETag即类似于指纹,并且他们能够被快速地被比较,以确定两个版本的资源是否相同。ETag的比较只对同一个URL有意义——不同URL上的资源的ETag值可能相同也可能不同,从他们的ETag的比较中无从推断。

Date:Sun, 21 Sep 2014 06:18:21 GMT

这个是服务端发送资源时的服务器时间,刚开始我不知道GMT是格林尼治所在地的标准时间,以为是服务器的时间错了,还去服务器上查看过时间。http协议中发送的时间都是GMT的,这主要是解决在互联网上,不同时区在相互请求资源的时候,时间混乱问题。

Expires:Sun, 1 Jan 2000 01:00:00 GMT

这个响应头也是跟缓存有关的,告诉客户端在这个时间前,可以直接访问缓存副本,很显然这个值会存在问题,因为客户端和服务器的时间不一定会都是相同的,如果时间不同就会导致问题。所以这个响应头是没有Cache-Control:max-age=***这个响应头准确的,因为max-age=date中的date是个相对时间,不仅更好理解,也更准确。

Pragma:no-cache

这个含义与Cache-Control等同。

Server:Tengine/1.4.6

这个是服务器和相对应的版本,只是告诉客户端服务器信息,没有更多的意思。

Transfer-Encoding:chunked

这个响应头告诉客户端,服务器发送的资源的方式是分块发送的。一般分块发送的资源都是服务器动态生成的,在发送时还不知道发送资源的大小,所以采用分块发送,每一块都是独立的,独立的块都能标示自己的长度,最后一块是0长度的,当客户端读到这个0长度的块时,就可以确定资源已经传输完了。


HTTP Header 之Content-Type介绍

Content-Type 实体头部用于指示资源的MIME类型 media type 。

在响应中,Content-Type标头告诉客户端实际返回的内容的内容类型。浏览器会在某些情况下进行MIME查找,并不一定遵循此标题的值; 为了防止这种行为,可以将标题 X-Content-Type-Options 设置为 nosniff

在请求中 (如POST 或 PUT),客户端告诉服务器实际发送的数据类型。

Header type Entity header
Forbidden header name no
CORS-safelisted response-header yes
句法
Content-Type: text/html; charset=utf-8
Content-Type: multipart/form-data; boundary=something
指令
media-type
资源或数据的 MIME type 。
charset
字符编码标准。
boundary
对于多部分实体,boundary 是必需的,其包括来自一组字符的1到70个字符,已知通过电子邮件网关是非常健壮的,而不是以空白结尾。它用于封装消息的多个部分的边界。
例子

Content-Type 在HTML表单中

在通过HTML form提交生成的POST请求中,请求头的Content-Type由<form>元素上的enctype属性指定

<form action="/" method="post" enctype="multipart/form-data">
  <input type="text" name="description" value="some text">
  <input type="file" name="myFile">
  <button type="submit">Submit</button>
</form>

请求头看起来像这样(在这里省略了一些 headers):

POST /foo HTTP/1.1
Content-Length: 68137
Content-Type: multipart/form-data; boundary=---------------------------974767299852498929531610575

---------------------------974767299852498929531610575
Content-Disposition: form-data; name="description" 

some text
---------------------------974767299852498929531610575
Content-Disposition: form-data; name="myFile"; filename="foo.txt" 
Content-Type: text/plain 

(content of the uploaded file foo.txt)
---------------------------974767299852498929531610575
规范
Specification Title
RFC 7233, section 4.1: Content-Type in multipart Hypertext Transfer Protocol (HTTP/1.1): Range Requests
RFC 7231, section 3.1.1.5: Content-Type Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content

 

参考:

https://my.oschina.net/manmao/blog/549123