我们注意到，大部分的 socket接口都是阻塞型的。所谓阻塞型接口是指系统调用（一般是 IO接口）不返回调用结果并让当前线程一直阻塞，只有当该系统调用获得结果或者超时出错时才返回。实际上，除非特别指定，几乎所有的 IO接口 (包括 socket 接口 )都是阻塞型的。这给网络编程带来了一个很大的问题，如在调用 send()的同时，线程将被阻塞，在此期间，线程将无法执行任何运算或响应任何的网络请求。这给多客户机、多业务逻辑的网络编程带来了挑战。这时，很多程序员可能会选择多线程的方式来解决这个问题。多线程服务器程序 应对多客户机的网络应用，最简单的解决方式是在服务器端使用多线程（或多进程）。多线程（或多进程）的目的是让每个连接都拥有独立的线程（或进程），这样任何一个连接的阻塞都不会影响其他的连接。 具体使用多进程还是多线程，并没有一个特定的模式。传统意义上，进程的开销要远远大于线程，所以，如果需要同时为较多的客户机提供服务，则不推荐使用多进程；如果单个服务执行体需要消耗较多的 CPU 资源，譬如需要进行大规模或长时间的数据运算或文件访问，则进程较为安全。通常，使用 pthread_create () 创建新线程，fork() 创建新进程。 我们假设对上述的服务器 / 客户机模型，提出更高的要求，即让服务器同时为多个客户机提供一问一答的服务。于是有了如下的模型。图2. 多线程服务器模型 在上述的线程 / 时间图例中，主线程持续等待客户端的连接请求，如果有连接，则创建新线程，并在新线程中提供为前例同样的问答服务。 很多初学者可能不明白为何一个 socket 可以 accept 多次。实际上，socket 的设计者可能特意为多客户机的情况留下了伏笔，让 accept() 能够返回一个新的 socket。下面是 accept 接口的原型： int accept(int s, struct sockaddr *addr, socklen_t *addrlen)输入参数 s 是从 socket()，bind() 和 listen() 中沿用下来的 socket 句柄值。执行完 bind() 和 listen() 后，操作系统已经开始在指定的端口处监听所有的连接请求，如果有请求，则将该连接请求加入请求队列。调用 accept() 接口正是从 socket s 的请求队列抽取第一个连接信息，创建一个与 s 同类的新的 socket 返回句柄。新的 socket 句柄即是后续 read() 和 recv() 的输入参数。如果请求队列当前没有请求，则 accept() 将进入阻塞状态直到有请求进入队列。 上述多线程的服务器模型似乎完美的解决了为多个客户机提供问答服务的要求，但其实并不尽然。如果要同时响应成百上千路的连接请求，则无论多线程还是多进程都会严重占据系统资源，降低系统对外界响应效率，而线程与进程本身也更容易进入假死状态。 很多程序员可能会考虑使用“线程池”或“连接池”。“线程池”旨在减少创建和销毁线程的频率，其维持一定合理数量的线程，并让空闲的线程重新承担新的执行任务。“连接池”维持连接的缓存池，尽量重用已有的连接、减少创建和关闭连接的频率。这两种技术都可以很好的降低系统开销，都被广泛应用很多大型系统，如 websphere、tomcat 和各种数据库等。 但是，“线程池”和“连接池”技术也只是在一定程度上缓解了频繁调用 IO 接口带来的资源占用。而且，所谓“池”始终有其上限，当请求大大超过上限时，“池”构成的系统对外界的响应并不比没有池的时候效果好多少。所以使用“池”必须考虑其面临的响应规模，并根据响应规模调整“池”的大小。 对应上例中的所面临的可能同时出现的上千甚至上万次的客户端请求，“线程池”或“连接池”或许可以缓解部分压力，但是不能解决所有问题。 总之，多线程模型可以方便高效的解决小规模的服务请求，但面对大规模的服务请求，多线程模型并不是最佳方案。下一章我们将讨论用非阻塞接口来尝试解决这个问题。使用select()接口的基于事件驱动的服务器模型 大部分 Unix/Linux 都支持 select 函数，该函数用于探测多个文件句柄的状态变化。下面给出 select 接口的原型： FD_ZERO(int fd, fd_set* fds) FD_SET(int fd, fd_set* fds) FD_ISSET(int fd, fd_set* fds) FD_CLR(int fd, fd_set* fds) int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout) 这里，fd_set 类型可以简单的理解为按 bit 位标记句柄的队列，例如要在某 fd_set 中标记一个值为 16 的句柄，则该 fd_set 的第 16 个 bit 位被标记为 1。具体的置位、验证可使用 FD_SET、FD_ISSET 等宏实现。在 select() 函数中，readfds、writefds 和 exceptfds 同时作为输入参数和输出参数。如果输入的 readfds 标记了 16 号句柄，则 select() 将检测 16 号句柄是否可读。在 select() 返回后，可以通过检查 readfds 有否标记 16 号句柄，来判断该“可读”事件是否发生。另外，用户可以设置 timeout 时间。 下面将重新模拟上例中从多个客户端接收数据的模型。图4.使用select()的接收数据模型 上述模型只是描述了使用 select() 接口同时从多个客户端接收数据的过程；由于 select() 接口可以同时对多个句柄进行读状态、写状态和错误状态的探测，所以可以很容易构建为多个客户端提供独立问答服务的服务器系统。图5.使用select()接口的基于事件驱动的服务器模型 这里需要指出的是，客户端的一个 connect() 操作，将在服务器端激发一个“可读事件”，所以 select() 也能探测来自客户端的 connect() 行为。 上述模型中，最关键的地方是如何动态维护 select() 的三个参数 readfds、writefds 和 exceptfds。作为输入参数，readfds 应该标记所有的需要探测的“可读事件”的句柄，其中永远包括那个探测 connect() 的那个“母”句柄；同时，writefds 和 exceptfds 应该标记所有需要探测的“可写事件”和“错误事件”的句柄 ( 使用 FD_SET() 标记 )。 作为输出参数，readfds、writefds 和 exceptfds 中的保存了 select() 捕捉到的所有事件的句柄值。程序员需要检查的所有的标记位 ( 使用 FD_ISSET() 检查 )，以确定到底哪些句柄发生了事件。 上述模型主要模拟的是“一问一答”的服务流程，所以，如果 select() 发现某句柄捕捉到了“可读事件”，服务器程序应及时做 recv() 操作，并根据接收到的数据准备好待发送数据，并将对应的句柄值加入 writefds，准备下一次的“可写事件”的 select() 探测。同样，如果 select() 发现某句柄捕捉到“可写事件”，则程序应及时做 send() 操作，并准备好下一次的“可读事件”探测准备。下图描述的是上述模型中的一个执行周期。图6. 一个执行周期 这种模型的特征在于每一个执行周期都会探测一次或一组事件，一个特定的事件会触发某个特定的响应。我们可以将这种模型归类为“事件驱动模型”。 相比其他模型，使用 select() 的事件驱动模型只用单线程（进程）执行，占用资源少，不消耗太多 CPU，同时能够为多客户端提供服务。如果试图建立一个简单的事件驱动的服务器程序，这个模型有一定的参考价值。 但这个模型依旧有着很多问题。 首先，select() 接口并不是实现“事件驱动”的最好选择。因为当需要探测的句柄值较大时，select() 接口本身需要消耗大量时间去轮询各个句柄。很多操作系统提供了更为高效的接口，如 linux 提供了 epoll，BSD 提供了 kqueue，Solaris 提供了 /dev/poll …。如果需要实现更高效的服务器程序，类似 epoll 这样的接口更被推荐。遗憾的是不同的操作系统特供的 epoll 接口有很大差异，所以使用类似于 epoll 的接口实现具有较好跨平台能力的服务器会比较困难。 其次，该模型将事件探测和事件响应夹杂在一起，一旦事件响应的执行体庞大，则对整个模型是灾难性的。如下例，庞大的执行体 1 的将直接导致响应事件 2 的执行体迟迟得不到执行，并在很大程度上降低了事件探测的及时性。图7. 庞大的执行体对使用select()的事件驱动模型的影响 幸运的是，有很多高效的事件驱动库可以屏蔽上述的困难，常见的事件驱动库有 libevent 库，还有作为 libevent 替代者的 libev 库。这些库会根据操作系统的特点选择最合适的事件探测接口，并且加入了信号 (signal) 等技术以支持异步响应，这使得这些库成为构建事件驱动模型的不二选择。下章将介绍如何使用 libev 库替换 select 或 epoll 接口，实现高效稳定的服务器模型。使用事件驱动库libev的服务器模型 Libev 是一种高性能事件循环 / 事件驱动库。作为 libevent 的替代作品，其第一个版本发布与 2007 年 11 月。Libev 的设计者声称 libev 拥有更快的速度，更小的体积，更多功能等优势，这些优势在很多测评中得到了证明。正因为其良好的性能，很多系统开始使用 libev 库。本章将介绍如何使用 Libev 实现提供问答服务的服务器。 （事实上，现存的事件循环 / 事件驱动库有很多，作者也无意推荐读者一定使用 libev 库，而只是为了说明事件驱动模型给网络服务器编程带来的便利和好处。大部分的事件驱动库都有着与 libev 库相类似的接口，只要明白大致的原理，即可灵活挑选合适的库。） 与前章的模型类似，libev 同样需要循环探测事件是否产生。Libev 的循环体用 ev_loop 结构来表达，并用 ev_loop( ) 来启动。 void ev_loop( ev_loop* loop, int flags ) Libev 支持八种事件类型，其中包括 IO 事件。一个 IO 事件用 ev_io 来表征，并用 ev_io_init() 函数来初始化： void ev_io_init(ev_io *io, callback, int fd, int events) 初始化内容包括回调函数 callback，被探测的句柄 fd 和需要探测的事件，EV_READ 表“可读事件”，EV_WRITE 表“可写事件”。 现在，用户需要做的仅仅是在合适的时候，将某些 ev_io 从 ev_loop 加入或剔除。一旦加入，下个循环即会检查 ev_io 所指定的事件有否发生；如果该事件被探测到，则 ev_loop 会自动执行 ev_io 的回调函数 callback()；如果 ev_io 被注销，则不再检测对应事件。 无论某 ev_loop 启动与否，都可以对其添加或删除一个或多个 ev_io，添加删除的接口是 ev_io_start() 和 ev_io_stop()。 void ev_io_start( ev_loop *loop, ev_io* io ) void ev_io_stop( EV_A_* ) 由此，我们可以容易得出如下的“一问一答”的服务器模型。由于没有考虑服务器端主动终止连接机制，所以各个连接可以维持任意时间，客户端可以自由选择退出时机。图8. 使用libev库的服务器模型 上述模型可以接受任意多个连接，且为各个连接提供完全独立的问答服务。借助 libev 提供的事件循环 / 事件驱动接口，上述模型有机会具备其他模型不能提供的高效率、低资源占用、稳定性好和编写简单等特点。 由于传统的 web 服务器，ftp 服务器及其他网络应用程序都具有“一问一答”的通讯逻辑，所以上述使用 libev 库的“一问一答”模型对构建类似的服务器程序具有参考价值；另外，对于需要实现远程监视或远程遥控的应用程序，上述模型同样提供了一个可行的实现方案。 总结 本文围绕如何构建一个提供“一问一答”的服务器程序，先后讨论了用阻塞型的 socket 接口实现的模型，使用多线程的模型，使用 select() 接口的基于事件驱动的服务器模型，直到使用 libev 事件驱动库的服务器模型。文章对各种模型的优缺点都做了比较，从比较中得出结论，即使用“事件驱动模型”可以的实现更为高效稳定的服务器程序。文中描述的多种模型可以为读者的网络编程提供参考价值。
目录
1、网络协议
其实协议在我们生活中也能找到相应的影子。
举个例子，有 2 个男生准备追求同一个妹子，妹子来自河南，讲河南话，还会点普通话；一个男生来自胡建，讲闽南语，也会点普通话；另一个男生来自广东，只讲粤语；
协议一致，沟通自如
语言不通，无法沟通
你们猜猜？最后谁牵手成功了？答案肯定是来自胡建的那位，双方可以通过 普通话 进行沟通，表达内容都能理解。而来自广东的帅哥只会讲粤语，不会普通话，妹子表示听不懂，就无法进行沟通下了。
每个人的成长环境不同，所讲的语言、认知、理解能力也就不同。为了使来自五湖四海的朋友能沟通自如，就需要大家协商，认识某一个语言或规则，彼此能互相理解，这个语言就是普通话。
通过这个例子，大家可以这样理解：
把普通话比作“协议”、把聊天比作“通信”，把说话的内容比作“数据”。
相信这样类比，大家就知道，协议是什么了？
简单地说，就是程序员指定一些标准，使不同的通信设备能彼此正确理解、正确解析通信的内容。我们都知道计算机世界里是二进制，要么 1，要么 0，那为啥可以表达丰富多彩的内容呢？
也是因为协议，不同字段，不同组合，可以解析不同意思，这就依然协议，让协议来正确处理。
例如，我们使用手机连 WiFi 来刷抖音，使用的是 802.11（WLAN）协议，通过这个协议接入网络。如果你所连的 WIFI 是不需要手动设置 IP 地址，是通过自动获取的，就使用到了 DHCP 协议，这样你的手机算上接入了 局域网， 如果你局域网内有台 NAS 服务器，存放了某些不可描述的视频资源，你就可以访问观看了，但这时你可能无法访问互联网资源，例如，你还想刷会抖音，看看妹子扭一扭，结果出现如下画面：
出现这种画面，说明无法使用 互联网， 可能是无线路由器没有设置好相关协议，比如： NAT、PPPoE 协议（上网账号或密码设置错误了），只有设置正确了，就可以通过运营商（ISP）提供的线路把局域网接入到互联网中，实现手机可以访问互联网上的资源（服务器）。玩微信撩妹子、刷抖音看妹子。
网络协议示意图
延伸阅读
1、局域网：最显著的特点就是范围有限，行政可控的区域可以是一所高校、一个餐厅、一个园区、一栋办公楼或一个家庭的私有网络。
2、城域网：原本是介意局域网和广域网之间，实际工作中很少再刻意去区分城域网和广域网了，所以这边不再介绍。
3、广域网：简单说就是负责把多个局域网连接起来，它的传输距离长距离传输，广域网的搭建一般是由运营商来。
4、互联网：把全世界上提供资源共享的 IT 设备所在网络连接起来，接入了互联网就可以随时随地访问这些资源了。
5、物联网：把所有具有联网功能的物体都接入互联网就形成了物联网。如空调联网，就可以远程控制空调； 汽车 联网，就可以远程获取行程数据。
总结一下吧！我们可以把电脑、手机等 IT 设备比喻做来自五湖四海的人们，大家都通过多种语言（网络协议）实现沟通（通信）。所有人要一起交流，就用普通话，大家都能理解。所有胡建人在一起，就用闽南语进行沟通，彼此也能理解。这么的方言，就好比计算机网络世界里也有这么多协议，只是不同协议用在不同地方。
好奇的同学，可能就会问，那网络协议是由谁来规定呢？这就需要提到一个组织，ISO。这个组织制定了一个国际标准 ，叫做 OSI 参考模型，如下，很多厂商都会参考这个制定网络协议。
OSI 参考模型图
2、OSI 参考模型
既然是模型，就好比模范一样，大家都要向它学习，以它为原型，展开学习研究。前面我们也提到了一些协议，这么多协议如果不进行归纳，分层，大家学习起来是不是感觉很凌乱？
所以 OSI 参考模型就是将这样复杂的协议整理并进行分层，分为易于理解的 7 层，并定义每一层的 服务 内容，协议的具体内容是 规则 。上下层之间通过 接口 进行交互，同一层之间通过 协议 进行交互。相信很多网络工程师在今后工作中遇到问题，讨论协议问题还会用到这个模型展开讨论。所以说，对于计算机网络初学者来说，学习了解 OSI 参考模型就是通往成功的第一步。
OSI 参考模型分层功能
7.应用层
为应用程序提供服务并规定应用程序中通信相关的细节，OSI 的最高层。包括文件传输、Email、远程登录等协议。程序员接触这一层比较多。
应用层示例图
6.表示层
主要负责数据格式的转换，为上下层能够处理的格式。如编码、加密、解密等。
表示层示例图
5.会话层
即负责建立、管理和终止通信连接（数据流动的逻辑通路），数据分片、重组等传输的管理。
会话层示例图
4.传输层
保证可靠传输，不需要再路由器上处理，只需再通信双方节点上进行处理，如处理差错控制和流量控制。
传输层示例图
3.网络层
主要负责寻址和路由选择，将数据包传输到目的地。
网络层示例图
2.数据链路层
负责物理层面上互连、节点之间的通信传输，将0 、 1 序列比特流划分为具有意义的数据帧传输给对端。这一层有点类似网络层，网络层也是基于目的地址来传输，不同是：网络层是将数据包负责在整个网络转发，而数据链路层仅是在网段内转发，所以大家抓包会发现，源目 MAC 地址每经过一个二层网段，都会变化。
数据链路层示例图
1.物理层
负责 0、1 比特流（0、1 序列）与电压高低电平、光的闪灭之间的互相转换，为数据链路层提供物理连接。
物理层示例图
OSI 为啥最后没有得到运用呢？其实最主要的原因，是 OSI 模型出现的比 tcp/ip 出现的时间晚，在 OSI 开始使用前，TCP/IP 已经被广泛的应用了。如果要换成 OSI 模型也不太现实。其次是 OSI 是专家们讨论，最后形成的，由于没有实践，导致该协议实现起来很复杂，很多厂商不愿意用 OSI，与此相比，TCP/IP 协议比较简单，实现起来也比较容易，它是从公司中产生的，更符合市场的要求。综合各种因素，最终 OSI 没有被广泛的应用。
下面我们来看看 TCP/IP 与 OSI 分层之间的对应关系及相应的协议：
4.应用层
从上图，可以知道 TCP/IP 四层模型，把应用层、表示层、会话层集成再一起了，该层的协议有：HTTP 、 POP3 、 TELNET 、 SSH 、 FTP 、 SNMP 等。
目前，大部分基于 TCP/IP 的应用都是 客户端/服务端 架构。一般我们把提供资源服务的那一侧叫服务端， 发起访问服务资源的这一侧叫客户端。
应用层
3.传输层
主要职责就是负责两端节点间的应用程序互相通信，每个节点上可能有很多应用程序，例如，登录了微信，又打开了网页，又打开迅雷看看，那数据到达后怎么正确传送到相应的应用程序呢？那就需要 端口号 来正确识别了。传输层中最为常见的两个协议分别是传输控制协议 TCP （Transmission Control Protocol）和用户数据报协议 UDP （User Datagram Protocol）
面向连接 顾名思义，就是建立连接，什么时候建立连接呢？就是在通信之前需要先建立一条逻辑的通信链路。就跟我们平时打电话一样，得先拨通，通了之后即链路建立好了，这条链路只有你和对方可以在这条链路传播说话内容。挂电话后，这条链路也就断开了。
面向无连接 无连接，即通信之前不需要建立连接，直接发送即可。跟我们以前写信很像，不需要管对方在不在？直接写信寄过去就可以了。
面向连接传输
面向无连 接传输
2.网络层
主要职责就是将数据包从源地址发送到目的地址。
在网络传输中，每个节点会根据数据的 IP 地址信息，来判断该数据包应该由哪个接口（网卡）发送出去。各个地址会参考一个发出接口列表， MAC 寻址中所参考的这张表叫做 MAC 地址转发表 ，而 IP 寻址中所参考的叫做 路由表 。MAC 地址转发表根据自学自动生成。路由控制表则根据路由协议自动生成。MAC 地址转发表中所记录的是实际的 MAC 地址本身，而路由表中记录的 IP 地址则是集中了之后的网络号（即网络号与子网掩码）。
1.网络接口层
在 TCP/IP 把物理层和数据链路层集成为 网络接口层 。主要任务是将上层的数据封装成帧发送到网络上，数据帧通过网络到达对端，对端收到后对数据帧解封，并检查帧中包含的 MAC 地址。如果该地址就是本机的 MAC 地址或者是广播地址，则上传到网络层，否则丢弃该帧。
封装与解封装
所谓的封装，其实就跟你寄快递的时候，给物品加上纸盒包装起来或者快件到站点，快递员贴一层标签的过程。在网络上，就是上层的数据往下送的时候，下层会添加头部，不过，只有在二层，不仅会加上头部，还会在上层数据尾部添加 FCS。
封装
所谓解封装，就如同你收到快件一样，一层一层地拆外包装，直到看到快件。网络也是，一层一层地拆掉头部，往上层传送，直到看到数据内容。
解封装
我们把应用层的数据封装传输层头部后的报文，称为 段 ；
把段封装网络层头部后的报文，称为 包 ；
把包封装以太网头部和帧尾，称为 帧 。
欢迎分享，转载请注明来源：夏雨云
微信扫一扫
支付宝扫一扫
评论列表（0条）