web服务器apache架构与原理

简介:

web服务器                                                                               

 

  在开始了解Apache前,我们先熟悉一下web服务器,因为apache也是web服务器的一种。

  Web系统由客户端(浏览器)和服务器端两部分组成。Web系统架构也被称为B/S架构。最常见的Web服务器有Apache、IIS等,常用的浏览器有IE、Firefox、chrome等。 当你想访问一个网页时,需要在浏览器的地址栏中输入该网页的URL(Uniform Resource Locator,简称为URL)地址,或者是通过 超链接链接到该网页。浏览器会向该网页所在的服务器发送一个HTTP请求,服务器会对接收到的请求信息进行处理,然后将处理的结果返回给浏览器,最终将浏 览器处理后的结果呈现给用户。

 

web服务器端的工作流程:

(1)客户端发送请求

  客户端(通过浏览器)和Web服务器建立TCP连接,连接建立以后,向Web服务器发出访问请求(如get)。根据HTTP协议,该请求中包含了客户端的IP地址、浏览器的类型和请求的URL等一系列信息。

(2)服务器解析请求

  Web服务器对请求按照HTTP协议进行解码来确定进一步的动作,设计的内容有三鼐要点:方法(GET)、 文档(/sample.html)、和浏览器使用的协议(HTTP/1.1)其中方法告诉服务器应完动的动作,GET方法的含义很明显是:服务器应定位、 读取文件并将它返回给客户。

Web服务器软件现在就知道了,它应该找到文件/sample.html,并使用HTTP/1.1协议将内存返回给客户。信息是经过与请求到来相同的连接发出的,所以服务器不需要定们客户或创建新的连接。

(3)读取其它信息(非必须步骤)

    Web服务器根据需要去读取请求的其它部分。在HTTP/1.1下,客户还应给服务器提供关于它的一些信息。元信息(metainformation)可用来描述浏览器及其能力,以使服务器能据此确定如何返回应答。

(4)完成请求的动作

  若现在没有错误出现,WWW服务器将执行请求所要求的动作。要获取(GET)一个文档,web服务器在其文档树中搜索请求的文件(/sample.html)。这是由服务器机器上作为操作系统一部分的文件系统完成的。若文件能找到并可正常读取,则服务器将把它返回给客户。

如果成功:文件被发送出去。

  首先,web服务器发送一个状态码及一些描述信息。既然文件已经找到,则发送状态码200,表示一切都 OK ,文档随后发出,因为发送的信息是HTML文档,所以Content-type 取值为text/html。文档长为1024个字节,所以 Content-type 取1024 。服务器软件的标识及文件的时间属性信息也被包含在头域中。

如果失败:返回错误指示。

  如果请求的文件没有找到或找到但无法读取,测请求无法满足。这时将返回不同于200的状态码。最常见的问题是请求中的文件名拼写有误,所以服务器无法找到该文件。这种情况下,服务器将发送一个状态码---404 给客户。

(5)关闭文件和网络连接,结束会话。

当文件已被发邮或错误已发出后,web服务器结束整个会话。它关闭打开的的被请求文件,关闭网络端口从而结束网络连接。有关的其它工作则是由客户端来完成的,包括接收数据,并以用户可读的方式呈现出来。这些与服务器无关。

 

 

apache架构                                                                             

 

  Apache 作为历史最悠久的web服务器,一直是web应用系统的首选,是世界上被广泛应用的web 服务器软件,它可以运行在几乎所有广泛使用的计算机平台上,由于其跨平台和安全性被广泛使用,是最流行的web服务器端软件之一,也是流行架构LAMP的重要组成部分。

  作为世界上最流行的Web服务器,Apache遵循的同样是HTTP协议,默认端口号为80。下面来是apache 架构图。

Apache 特点:

 

  •   支持最新的HTTP/1.1通信协议。Apache是最先使用HTTP/1.1协议的Web服务器之一,它完全兼容HTTP/1.1协议并与HTTP/1.0协议向后兼容。Apache已为新协议所提供的全部内容做好了必要的准备。
  •   支持多计算机平台。Apache几乎可以在所有的计算机操作系统上运行,包括主流的UNIX、Linux及Windows操作系统。
  •   配置文件简单,易操作。用户可以通过直接修改Apache的配置文件信息来修改Apache,操作起来十分方便。
  •   支持实时监视服务器状态和定制服务器日志。Apache在记录日志和监视服务器自身运行状态方面提供了很大的灵活性,可以通过Web浏览器来监视服务器的状态,也可以根据自己的需要来定制日志。
  •   支持多种方式的HTTP认证。
  •   支持Web目录修改。用户可以使用特定的目录作为Web目录。
  •   支持CGI脚本,如Perl、PHP等。
  •   支持服务器端包含指令(SSI)。
  •   支持安全Socket层(SSL)。
  •   支持FastCGI。
  •   支持虚拟主机。即通过在一台服务器上使用不同的主机名来提供多个HTTP服务。Apache支持基于IP、主机名和端口号三种类型的虚拟主机服务。
  •   跟踪用户会话。当用户浏览基于Apache的Web站点时,可以通过Apache的mod_usertrack模块对其进行跟踪。
  •   支持动态共享对象。Apache的模块可在运行时动态加载,这就意味着这些模块可以被装入服务器进程空间,从而减少系统的内存开销。
  •   支持多进程。当负载增加时,服务器会快速生成子进程来处理,从而提高系统的响应能力。
  •   支持第三方软件开发商提供的功能模块。比如Apache加载mod_jserv模块后可以支持Java Servlet,这样就可以运行Java应用程序了。
  •   支持多线程和多进程混合模型的MPM。 当MPM类型指定为worker时,由于是使用线程来处理,所以可以处理海量的请求,而系统资源的开销要小于基于进程的服务器。

 

Apache 工作模拟                                                    

 

  Apache 2.X  支持插入式并行处理模块,称为多路处理模块(MPM)。在编译apache时必须选择也只能选择一个MPM,对类UNIX系统,有几个不同的MPM可供选择,它们会影响到apache的速度和可伸缩性。

  Worker MPM 使用多个子进程,每个子进程中又有多个线程。每个线程处理一个请求,该MPM通常对高流量的服务器是一个不错的选择。因为它比prefork MPM需要更少的内存且更具有伸缩性。

  Prefork MPM : 使用多个子进程,但每个子进程不包含多线程。每个进程只处理一个连接。在许多系统上它的速度和worker MPM一样快,但是需要更多的内存。这种无线程的设计在某些性况下优于worker MPM,因为它可在应用于不具备线程安全的第三方模块上(如 PHP3/4/5),且在不支持线程调试的平台上易于调试,另外还具有比worker MPM更高的稳定性。 

   (后面会介绍如果这两种模式以及apache更多的设置与监控等)

目录
相关文章
|
4月前
|
存储 消息中间件 Kafka
Confluent 首席架构师万字剖析 Apache Fluss(一):核心概念
Apache Fluss是由阿里巴巴与Ververica合作开发的Flink表存储引擎,旨在提供低延迟、高效率的实时数据存储与变更日志支持。其采用TabletServer与CoordinatorServer架构,结合RocksDB和列式存储,实现主键表与日志表的统一管理,并通过客户端抽象整合湖仓历史数据,弥补Paimon在实时场景下的性能短板。
722 22
Confluent 首席架构师万字剖析 Apache Fluss(一):核心概念
|
存储 Cloud Native 数据处理
从嵌入式状态管理到云原生架构:Apache Flink 的演进与下一代增量计算范式
本文整理自阿里云资深技术专家、Apache Flink PMC 成员梅源在 Flink Forward Asia 新加坡 2025上的分享,深入解析 Flink 状态管理系统的发展历程,从核心设计到 Flink 2.0 存算分离架构,并展望未来基于流批一体的通用增量计算方向。
444 0
从嵌入式状态管理到云原生架构:Apache Flink 的演进与下一代增量计算范式
|
4月前
|
存储 消息中间件 Kafka
Confluent 首席架构师万字剖析 Apache Fluss(三):湖流一体
原文:https://jack-vanlightly.com/blog/2025/9/2/understanding-apache-fluss 作者:Jack Vanlightly 翻译:Wayne Wang@腾讯 译注:Jack Vanlightly 是一位专注于数据系统底层架构的知名技术博主,他的文章以篇幅长、细节丰富而闻名。目前 Jack 就职于 Confluent,担任首席技术架构师,因此这篇 Fluss 深度分析文章,具备一定的客观参考意义。译文拆成了三篇文章,本文是第二篇。
611 25
Confluent 首席架构师万字剖析 Apache Fluss(三):湖流一体
|
4月前
|
存储 消息中间件 Kafka
Confluent 首席架构师万字剖析 Apache Fluss(二):核心架构
原文:https://jack-vanlightly.com/blog/2025/9/2/understanding-apache-fluss 作者:Jack Vanlightly 翻译:Wayne Wang@腾讯 译注:Jack Vanlightly 是一位专注于数据系统底层架构的知名技术博主,他的文章以篇幅长、细节丰富而闻名。目前 Jack 就职于 Confluent,担任首席技术架构师,因此这篇 Fluss 深度分析文章,具备一定的客观参考意义。译文拆成了三篇文章,本文是第二篇。
541 19
|
4月前
|
机器学习/深度学习 自然语言处理 监控
23_Transformer架构详解:从原理到PyTorch实现
Transformer架构自2017年Google发表的论文《Attention Is All You Need》中提出以来,彻底改变了深度学习特别是自然语言处理领域的格局。在短短几年内,Transformer已成为几乎所有现代大型语言模型(LLM)的基础架构,包括BERT、GPT系列、T5等革命性模型。与传统的RNN和LSTM相比,Transformer通过自注意力机制实现了并行化训练,极大提高了模型的训练效率和性能。
|
7月前
|
存储 监控 算法
园区导航系统技术架构实现与原理解构
本文聚焦园区导航场景中室内外定位精度不足、车辆调度路径规划低效、数据孤岛难以支撑决策等技术痛点,从架构设计到技术原理,对该系统从定位到数据中台进行技术拆解。
357 0
园区导航系统技术架构实现与原理解构
|
8月前
|
存储 消息中间件 canal
zk基础—2.架构原理和使用场景
ZooKeeper(ZK)是一个分布式协调服务,广泛应用于分布式系统中。它提供了分布式锁、元数据管理、Master选举及分布式协调等功能,适用于如Kafka、HDFS、Canal等开源分布式系统。ZK集群采用主从架构,具有顺序一致性、高性能、高可用和高并发等特点。其核心机制包括ZAB协议(保证数据一致性)、Watcher监听回调机制(实现通知功能)、以及基于临时顺序节点的分布式锁实现。ZK适合小规模集群部署,主要用于读多写少的场景。

推荐镜像

更多