web服务器工作原理

Posted 2023-05-15

Step1：用户在地址栏输入一个网址，然后点击回车键；
Step2：浏览器与服务器建立TCP连接；
Step3：浏览器将用户的事件按照HTTP协议要求的格式打包成数据包，这个过程的本质就是在待发送缓冲区中有这一段HTTP协议格式的字节流；
Step4：浏览器确认服务器可写，将该数据包推入Internet中，最终，该包被递交到服务端；
Step5：服务器在接收到该数据包后，以同样的格式进行解析，获取客户端的意图；
Step6：在获取了客户端的意图之后，服务器进行分类处理，或是提供某一文件，或是处理相关数据；
Step7：将处理结果装入缓冲区，或者文档，或是其他内容；
Step8：服务器将按照HTTP协议格式，将Step7中的数据进行打包；
Step9：服务器确定对端可写，将数据包推入Internet，该包经过网络处理，最终返回至客户端；
Step10：客户端拿到包之后，以HTTP协议格式进行解包，然后解析数据；
Step11：客户端处理相关数据，并且展示在页面之上。

以上这11步，就是web服务器最基本的工作原理。通过梳理，我们不难发现，这就是一个简单的网络通信过程。换句话说，就是一个简单的发送数据、接受数据、处理数据的过程。更高级的web服务器，无非也就是将上述的三个基础内容划分得更加详细一点而已。 参考技术A 回答

Web服务的工作原理是各公司从注册表(ebXML或UDDI的注册表)获得发布信息，建立满足要求的执行过程，然后向注册表发布它们的服务。以后，其他公司发现注册表中列出的一项服务，同意已制定的标准，然后开展业务。一旦在标准上取得一致并且约定的规则得到满足，应用程序就可以接管交易处理，因而从开展业务的开销中去除了人工互动。在这种模型中，通过利用现有基础设施，应用可以交换有关公司希望提供和消费的服务的信息。此外，应用还可以查询注册表，查找可以以更优惠条件提供同样服务的其他应用(公司)。在标准方面，UDDI作为一种用于Web的黄页被编制出来，它可以通过WSDL访问。WSDL支持类似于UDDI特性的ebXML注册特性。除了与UDDI的数据库特性竞争外，ebXML的Web服务部分曾被考虑与SOAP标准进行竞争。幸运的是，OASIS已将SOAP集成到ebXML中。目前，这些协议既相互重叠(UDDI和ebXML)又相互补充(SOAP和ebXML)。·UDDI(通用描述、发现和集成)：UDDI是Microsoft、IBM和Ariba为制定一项用于描述、注册和发现Web服务的Internet标准而成立的联盟。由此而来的UDDI框架是“一个企业可以注册其Web服务并查找其他Web服务的数据库集合。”应用程序使用SOAP API来读取或提供与UDDI相关的WSDL文档。·WSDL(Web服务描述语言)：WSDL文件，即UDDI和ebXML注册表的子集合，提供联系信息、Web服务的描述、它们的位置以及如何调用它们的规范。UDDI注册表按行业类别和地理位置细分。WSDL文件常常由另外的信息源(如，COM IDL或CORBA文件或EJB类定义)生成。WSDL用于描述通过Internet（或其他网络）可访问的程序以及同这些程序进行交流的信息格式和协议。它可以使Web服务的功能通过标准的方式展示出来，从而使Web服务和开发工具更易兼容。·SOAP(简单对象访问协议)：SOAP是使用XML通过Internet发送信息和访问动态Web服务的友好界面。其主要作用在于确保信息通过互联网在业务应用之间传输的可靠性。作为一种用在分布式环境中交换结构化数据的协议，它包括三个部分：信封、报头(可选)和协议消息体。信封标记SOAP消息的开始与结束。它还可以规定在网络上数据的编码规则。SOAP报

参考技术B web服务器工作原理：
1、用户在浏览器中输入要访问的web站点地址或在已打开的站点点击超链接。
2、由DNS进行域名解析，找到服务器的IP地址，向该地址指向的web服务器发出请求。
3、web服务器根据请求将URL地址转换为页面所在的服务器上的文件全名，查找相应的文件。
4、若URL指向静态文件，则服务器将文件通过http协议传输给用户浏览器；若html文档中嵌入了ASP,php,JSP等程序，则由服务器直接运行后返回给用户；
如果web服务器所运行程序包含对数据库的访问，服务器会将查询指令发送给数据库服务器，对数据库执行查询操作，查询结果由数据库返回给web服务器，再由web服务器将结果潜入页面，并以html格式发送给浏览器。
5、浏览器解释html文档，在客户端屏幕上展示结果。

Web服务器概念较为广泛，我们最常说的Web服务器指的是网站服务器，它是建立在Internet之上并且驻留在某种计算机上的程序。Web服务器可以向Web客户端(如浏览器)提供文档或其他服务，只要是遵循HTTP协议而设计的网络应用程序都可以是Web客户端。

Web服务器涵盖了HTTP服务器(这一点可以自行百度百科), Web服务器不仅能够存储信息，还能在用户通过Web浏览器提供的信息的基础上运行脚本和程序。

Web服务器最主要的功能是提供静态的文件。日常的上网浏览大多是网页浏览，少数时候才会有一些数据的提交操作。

tomcat等web服务器的工作原理

很多时候我们都想知道，web容器或web服务器（比如Tomcat或者jboss）是怎样工作的？ 它们是怎样处理来自全世界的http请求的？ 它们在幕后做了什么动作？ Java Servlet API（例如ServletContext，ServletRequest，ServletResponse和Session这些类）在其中扮演了什么角色？ 这些都是web应用开发者或者想成为web应用开发者的人必须要知道的重要问题或概念。 在这篇文章里，我将会尽量给出以上某些问题的答案。 请集中精神！

文章章节：

• 什么是web服务器、应用服务器和web容器？
• 什么是Servlet？ 他们有什么作用？
• 什么是ServletContext？ 它由谁创建？
• ServletRequest和ServletResponse从哪里进入生命周期？
• 如何管理Session？ 知道cookie吗？
• 如何确保线程安全？

什么是web服务器，应用服务器和web容器？

我先讨论web服务器和应用服务器。 让我在用一句话大概讲讲：

“在过去它们是有区别的，但是这两个不同的分类慢慢地合并了，而如今在大多在情况下和使用中可以把它们看成一个整体。 ”

在Mosaic浏览器（通常被认为是第一个图形化的web浏览器）和超链接内容的初期，演变出了“web服务器”的新概念，它通过HTTP协议来提供静态页面内容和图片服务。 在那个时候，大多数内容都是静态的，并且HTTP 1.0只是一种传送文件的方式。 但在不久后web服务器提供了CGI功能。 这意味着我们可以为每个web请求启动一个进程来产生动态内容。 现在，HTTP协议已经很成熟了并且web服务器变得更加复杂，拥有了像缓存、安全和session管理这些附加功能。 随着技术的进一步成熟，我们从Kiva和NetDynamics学会了公司专属的基于Java的服务器端技术。 这些技术最终全都融入到我们今天依然在大多数应用开发里使用的JSP中。

以上是关于web服务器的。现在我们来讨论应用服务器。

在同一时期，应用服务器已经存在并发展很长一段时间了。 一些公司为Unix开发了Tuxedo（面向事务的中间件）、TopEnd、Encina等产品，这些产品都是从类似IMS和CICS的主机应用管理和监控环境衍生而来的。 大部分的这些产品都指定了“封闭的”产品专用通信协议来互连胖客户机(“fat” client)和服务器。 在90年代，这些传统的应用服务器产品开始嵌入HTTP通信功能，刚开始要利用网关来实现。 不久后它们之间的界线开始变得模糊了。

同时，web服务器越来越成熟，可以处理更高的负载、更多的并发和拥有更好的特性； 应用服务器开始添加越来越多的基于HTTP的通信功能。 所有的这些导致了web服务器与应用服务器的界线变得更窄了。

目前，“应用服务器”和“web服务器”之间的界线已经变得模糊不清了。 但是人们还把这两个术语区分开来，作为强调使用。

当有人说到“web服务器”时，你通常要把它认为是以HTTP为核心、web UI为向导的应用。 当有人说到“应用服务器”时，你可能想到“高负载、企业级特性、事务和队列、多通道通信（HTTP和更多的协议）”。 但现在提供这些需求的基本上都是同一个产品。

以上就是关于web服务器和应用服务器的全部内容。现在我们来看看第三个术语，即web容器。

在Java方面，web容器一般是指Servlet容器。Servlet容器是与Java Servlet交互的web容器的组件。web容器负责管理Servlet的生命周期、把URL映射到特定的Servlet、确保URL请求拥有正确的访问权限和更多类似的服务。综合来看，Servlet容器就是用来运行你的Servlet和维护它的生命周期的运行环境。

什么是Servlet？他们有什么作用？

在Java里，Servlet使你能够编写根据请求动态生成内容的服务端组件。 事实上，Servlet是一个在javax.servlet包里定义的接口。 它为Servlet的生命周期声明了三个基本方法——init()、service()和destroy()。 每个Servlet都要实现这些方法（在SDK里定义或者用户定义）并在它们的生命周期的特定时间由服务器来调用这些方法。

类加载器通过懒加载（lazy-loading）或者预加载（eager loading）自动地把Servlet类加载到容器里。每个请求都拥有自己的线程，而一个Servlet对象可以同时为多个线程服务。当Servlet对象不再被使用时，它就会被JVM当做垃圾回收掉。

懒加载的Servlet

预加载的Servlet

什么是ServletContext？它由谁创建？

当Servlet容器启动时，它会部署并加载所有的web应用。 当web应用被加载时，Servlet容器会一次性为每个应用创建Servlet上下文（ServletContext）并把它保存在内存里。 Servlet容器会处理web应用的web.xml文件，并且一次性创建在web.xml里定义的Servlet、Filter和Listener，同样也会把它们保存在内存里。 当Servlet容器关闭时，它会卸载所有的web应用和ServletContext，所有的Servlet、Filter和Listner实例都会被销毁。

从Java文档可知，ServletContext定义了一组方法，Servlet使用这些方法来与它的Servlet容器进行通信。 例如，用来获取文件的MIME类型、转发请求或者编写日志文件。 在web应用的部署文件（deployment descriptor）标明“分布式”的情况下，web应用的每一个虚拟机都拥有一个上下文实例。 在这种情况下，不能把Servlet上下文当做共享全局信息的变量（因为它的信息已经不具有全局性了）。 可以使用外部资源来代替，比如数据库。

ServletRequest和ServletResponse从哪里进入生命周期？

Servlet容器包含在web服务器中，web服务器监听来自特定端口的HTTP请求，这个端口通常是80。 当客户端（使用web浏览器的用户）发送一个HTTP请求时，Servlet容器会创建新的HttpServletRequest和HttpServletResponse对象，并且把它们传递给已经创建的Filter和URL模式与请求URL匹配的Servlet实例的方法，所有的这些都使用同一个线程。

request对象提供了获取HTTP请求的所有信息的入口，比如请求头和请求实体。 response对象提供了控制和发送HTTP响应的便利方法，比如设置响应头和响应实体（通常是JSP生成的HTML内容）。 当HTTP响应被提交并结束后，request和response对象都会被销毁。

如何管理Session？知道cookie吗？

当客户端第一次访问web应用或者第一次使用request.getSession()获取HttpSession时，Servlet容器会创建Session，生成一个long类型的唯一ID（你可以使用session.getId()获取它）并把它保存在服务器的内存里。 Servlet容器同样会在HTTP响应里设置一个Cookie，cookie的名是JSESSIONID并且cookie的值是session的唯一ID。

根据HTTP cookie规范（正规的web浏览器和web服务器必须遵守的约定），在cookie的有效期间，客户端（web浏览器）之后的请求都要把这个cookie返回给服务器。 Servlet容器会利用带有名为JSESSIONID的cookie检测每一个到来的HTTP请求头，并使用cookie的值从服务器内容里获取相关的HttpSession。

HttpSession会一直存活着，除非超过一段时间没使用。 你可以在web.xml里设定这个时间段，默认时间段是30分钟。 因此，如果客户端已经超过30分钟没有访问web应用的话，Servlet容器就会销毁Session。 之后的每一个请求，即使带有特定的cookie，都再也不会访问到同一个Session了。 servletcontainer会创建一个新的Session。

现有的Session

新的Session

另外，在客户端的session cookie拥有一个默认的存活时间，这个时间与浏览器的运行时间相同。 因此，当用户关闭浏览器后（所有的标签或者窗口），客户端的Session就会被销毁。 重新打开浏览器后，与之前的Session关联的cookie就再也不会被发送出去了。 再次使用request.getSession()会返回一个全新的HttpSession并且使用一个全新的session ID来设置cookie。

如何确保线程安全?

你现在应该已经知道所有的请求都在共享Servlet和Filter。 这是Java的一个很棒的特性，它是多线程的并且不同的线程（即HTTP请求）可以使用同一个实例。 否则，对每一个请求都重新创建一个实体会耗费很多的资源。

你同样要知道，你不应该使用Servlet或者Filter的实例变量来存放任何的请求或者会话范围内的数据。 这些数据会被其他Session的所有请求共享。 这是非线程安全的！ 下面的例子说明了这个问题：

1 2 3 4 5 6 7 8 9 10 11 12

public class MyServlet extends HttpServlet {     private Object thisIsNOTThreadSafe; //Don't to this       protected void doGet(HttpServletRequest request,  HttpServletResponse response) throws ServletException, IOException     {         Object thisIsThreadSafe;  // BAD!! Shared among all requests!         thisIsNOTThreadSafe = request.getParameter("foo"); // OK, this is thread safe.         thisIsThreadSafe = request.getParameter("foo");     } }

不要这样做，这会导致软件出bug。

---

欢迎加入技术交流群，属于我们互联网技术人的专属群，共同交流和学习！

长按下方的二维码即可快速进群！！！

群里会不定期发送各种技术和视频资料

加小编微信：lvy99888,拉你入群