web 的工作原理
作为一名想学习网站开发, 或者更专业一点说叫"B/S体系结构系统"开发的同学来说, 可能首先想到的是学习各种前端技术, 例如: HTML, CSS, Javascript……, 以及各种动态网站开发技术, 诸如: ASP, ASP.NET, JSP, PHP…… . 但是, 在你开始之前, 请稍安勿躁, 了解一下网站是如何工作的往往是一件"磨刀不误砍柴工"的事情.
先上个图……本人比较懒, 所以就借用了别人做好的图, 还望原作者本着人道主义的精神不要追究我的责任
上图使用了一些相对专业的术语来描述了我们平时上网的一个过程. 简单来说就是我们上网的那台设备(通常称为"客户端", 可以是电脑/手机或别的东东) 上面安装的浏览器 (IE, Firefox, Chrome, Opera, Safari……) 作为我们的一个代理向网站服务器发送请求(Request), 网站服务器接收到请求后, 对请求中包含的信息进行解析, 进行一些处理后把处理的结果以响应(Response)的形式返回给浏览器, 最后浏览器解析返回的数据包并将其转化成一个可视化的界面, 就是我们看到的网页. 上网的过程大概也就是一个上述过程的循环.
其中, 一些术语和细节解释一下:
(1) 什么是URL?
(2) 什么是HTTP协议?"全球资源定位器 ( Uniform Resource Locator ). 真的好专业, 挺能唬人, 呵呵~ 简单来说, 就是用来描述Internet上的某一个资源所在位置的一个字符串, 比如我们平时说的网址, 当然也可以是Internet上的一张图片, 一个视频或其它东东. 根据URL计算机至少可以得到2个信息: (a) 资源所在的服务器的地址; (b) 资源在服务器上的存放路径.
超文本传输协议 ( Hyper Text Transport Protocol ). 呵呵, 还是好专业…… 好吧, 简单点说, 就是一种计算机之间传输数据所遵循的协议, 这里所说的协议其实是一种数据封装的规范. 计算机会把要传输的数据封装成一个叫做"数据包"的东东, 协议就规定了这个"数据包"里应该有些什么信息, 这些信息分别应该放在什么位置, 等等. HTTP协议就是众多协议中的一种, 它详细规定了浏览器与网站服务器之间进行数据传输的规范. 具体HTTP协议里规定了些什么东东? 感兴趣的同学可以查一下别的资料. 但可以想到里面肯定包含了收发方的地址信息和我们要传输的数据主体, 呵呵~ 总之, 上网看八卦就得靠它了……
(4) 服务器收到HTTP请求之后干什么呢? 大体来说, 3件事: (a) 找到你要的东西; (b) 进行一些应该在服务器端完成的处理, 比如: 执行服务器端脚本. 当然这一步并非对所有请求都是必须的; (c) 把处理结果封装成HTTP协议描述的数据包, 返回给客户端.
(5) 浏览器收到服务器返回的响应之后, 解析得到的数据, 将其转化成一个图形化的界面, 就是我们看到的网页. 当然, 如果其中还包含Javascript之类的脚本, 浏览器还会执行它……
接下来干什么呢? 输入另一个网址, 继续上网呗, 呵呵~ 当然, "输入"这个词不太准确, 我们不会老是去地址栏输网址吧…… "输入"的方式还可以是点击网页中的一个超链接或是提交网页中的一个表单(比如: 发帖子的时候, 在输入框里写好的要发的信息后点击"发送"按钮) . 还有别的方式吗? 也许, 但暂时想不到了……
OK, 现在大概有点感觉了吧……
~~~~~~~~~~~~~~~~~~~~~~ 华丽丽的分隔线 ~~~~~~~~~~~~~~~~~~~~~~~
下面有几点特别友情提醒一下, 省得今后犯些低级错误……
(1) 网站是工作在"两端"的 (服务器端和客户端), 即使有些情况下(比如开发/测试环境下) 服务器端和客户端可能是同一台电脑, 但应该服务器端和客户端执行的任务也是运行在两个完全隔离的进程或内存空间里的. 所以, 千万别干诸如在客户端脚本中读写服务器端脚本中变量的傻事!! 看不懂? 呵呵, 继续往下看就懂了……
(2) 服务器端除了接收请求和返回响应之外, 可能还会进行一些处理工作. 比如, 执行我们使用ASP/JSP技术做动态网站时候写在<% %> 中的代码, 这通常称为服务器端脚本. 当然, 服务器可能还会做更多事情, 比如: 读写数据库, 执行程序等等. 但无论如何, 服务器端无法直接操纵客户端, 它只能通过"间接"的方式, 比如: 在返回的响应中嵌入客户端脚本或指令, 由浏览器解释执行, 从而达到操纵客户端的目的.
(3) 服务器端返回的只有数据或"静态网页", 没有"服务器端脚本"或"服务器端变量". 即便要将服务器端内存中某个变量的值传给客户端, 也要经过所谓的"序列化"过程, 转换成数据流才能到达客户端. 所以, 千万别想着把一个服务器端对象直接开放给客户端来读写. 如果你真想这么干, 可以学习一下DWR框架……
(4) 对于浏览器而言无论它多么高档, 作为最基本的功能, 它处理的就是 HTML, CSS 和 Javascript, 至于其它的…… 比如: 播放Flash, 那就只能靠第三方的插件 或 浏览器生产商提供的一些扩展了. 所以, 别想着在浏览器里直接执行Java代码, 呵呵, 至少目前还不行.
(5) 无论什么设备, 只要它能接收HTTP请求, 返回HTTP响应那也就可以姑且称作"WEB服务器", 至于它如何处理接收到的请求, 那就得看你装了什么WEB服务器端软件了. 所以, 客户端可以是电脑, 手机或别的东东, 服务器端也不一定就是多么高档的一台机器, 它也可能就是一个单片机或嵌入式系统. 想想你进入路由器设置的那个界面, 呵呵~
(6) HTTP 和 HTML没有必然的联系! HTTP是描述数据封装格式的一种规范, 而HTML是用来告诉浏览器网页内容的一种语言. 所以, 通过HTTP协议传输的不一定非得是HTML文档, 也可以是"纯数据", 在使用Ajax技术时大多数情况下从服务器返回的仅是数据而已, 并非完整的HTML文档. 当然, 还可以想到…… 可以使用HTTP协议下载一个文件.
(7) 无论客户端和服务器端是多少庞大和复杂的一个系统, 最终将它们联系起来的只是HTTP协议描述的信息. 呵呵, 一切都将被转换为最朴素的数据流.
(8) 从上面的图可以看出, 整个工作过程的"起始点"是由客户端发起"请求", 也就是说, 服务器端是"被动"的响应. 所以, 通过一般的手段是无法由服务器端主动把数据"推送"给客户端的. 那不一般的手段是什么呢? 呵呵, 比如, 很多客户端框架中使用的"轮询"或"捎带"机制.
(9) 客户端和服务器端谁多干点活, 究竟那一些该"胖"些或"富"一些, 这是个永恒的话题, 没有绝对的结论. 但无论如何不应该让HTTP数据包胖起来, 也就是说, 尽可能地减少在客户端和服务器端之间传输的数据和传输的次数.
作为一名想学习网站开发, 或者更专业一点说叫"B/S体系结构系统"开发的同学来说, 可能首先想到的是学习各种前端技术, 例如: HTML, CSS, Javascript……, 以及各种动态网站开发技术, 诸如: ASP, ASP.NET, JSP, PHP…… . 但是, 在你开始之前, 请稍安勿躁, 了解一下网站是如何工作的往往是一件"磨刀不误砍柴工"的事情.
先上个图……本人比较懒, 所以就借用了别人做好的图, 还望原作者本着人道主义的精神不要追究我的责任
上图使用了一些相对专业的术语来描述了我们平时上网的一个过程. 简单来说就是我们上网的那台设备(通常称为"客户端", 可以是电脑/手机或别的东东) 上面安装的浏览器 (IE, Firefox, Chrome, Opera, Safari……) 作为我们的一个代理向网站服务器发送请求(Request), 网站服务器接收到请求后, 对请求中包含的信息进行解析, 进行一些处理后把处理的结果以响应(Response)的形式返回给浏览器, 最后浏览器解析返回的数据包并将其转化成一个可视化的界面, 就是我们看到的网页. 上网的过程大概也就是一个上述过程的循环.
其中, 一些术语和细节解释一下:
(1) 什么是URL?
(2) 什么是HTTP协议?"全球资源定位器 ( Uniform Resource Locator ). 真的好专业, 挺能唬人, 呵呵~ 简单来说, 就是用来描述Internet上的某一个资源所在位置的一个字符串, 比如我们平时说的网址, 当然也可以是Internet上的一张图片, 一个视频或其它东东. 根据URL计算机至少可以得到2个信息: (a) 资源所在的服务器的地址; (b) 资源在服务器上的存放路径.
超文本传输协议 ( Hyper Text Transport Protocol ). 呵呵, 还是好专业…… 好吧, 简单点说, 就是一种计算机之间传输数据所遵循的协议, 这里所说的协议其实是一种数据封装的规范. 计算机会把要传输的数据封装成一个叫做"数据包"的东东, 协议就规定了这个"数据包"里应该有些什么信息, 这些信息分别应该放在什么位置, 等等. HTTP协议就是众多协议中的一种, 它详细规定了浏览器与网站服务器之间进行数据传输的规范. 具体HTTP协议里规定了些什么东东? 感兴趣的同学可以查一下别的资料. 但可以想到里面肯定包含了收发方的地址信息和我们要传输的数据主体, 呵呵~ 总之, 上网看八卦就得靠它了……
(4) 服务器收到HTTP请求之后干什么呢? 大体来说, 3件事: (a) 找到你要的东西; (b) 进行一些应该在服务器端完成的处理, 比如: 执行服务器端脚本. 当然这一步并非对所有请求都是必须的; (c) 把处理结果封装成HTTP协议描述的数据包, 返回给客户端.
(5) 浏览器收到服务器返回的响应之后, 解析得到的数据, 将其转化成一个图形化的界面, 就是我们看到的网页. 当然, 如果其中还包含Javascript之类的脚本, 浏览器还会执行它……
接下来干什么呢? 输入另一个网址, 继续上网呗, 呵呵~ 当然, "输入"这个词不太准确, 我们不会老是去地址栏输网址吧…… "输入"的方式还可以是点击网页中的一个超链接或是提交网页中的一个表单(比如: 发帖子的时候, 在输入框里写好的要发的信息后点击"发送"按钮) . 还有别的方式吗? 也许, 但暂时想不到了……
OK, 现在大概有点感觉了吧……
~~~~~~~~~~~~~~~~~~~~~~ 华丽丽的分隔线 ~~~~~~~~~~~~~~~~~~~~~~~
下面有几点特别友情提醒一下, 省得今后犯些低级错误……
(1) 网站是工作在"两端"的 (服务器端和客户端), 即使有些情况下(比如开发/测试环境下) 服务器端和客户端可能是同一台电脑, 但应该服务器端和客户端执行的任务也是运行在两个完全隔离的进程或内存空间里的. 所以, 千万别干诸如在客户端脚本中读写服务器端脚本中变量的傻事!! 看不懂? 呵呵, 继续往下看就懂了……
(2) 服务器端除了接收请求和返回响应之外, 可能还会进行一些处理工作. 比如, 执行我们使用ASP/JSP技术做动态网站时候写在<% %> 中的代码, 这通常称为服务器端脚本. 当然, 服务器可能还会做更多事情, 比如: 读写数据库, 执行程序等等. 但无论如何, 服务器端无法直接操纵客户端, 它只能通过"间接"的方式, 比如: 在返回的响应中嵌入客户端脚本或指令, 由浏览器解释执行, 从而达到操纵客户端的目的.
(3) 服务器端返回的只有数据或"静态网页", 没有"服务器端脚本"或"服务器端变量". 即便要将服务器端内存中某个变量的值传给客户端, 也要经过所谓的"序列化"过程, 转换成数据流才能到达客户端. 所以, 千万别想着把一个服务器端对象直接开放给客户端来读写. 如果你真想这么干, 可以学习一下DWR框架……
(4) 对于浏览器而言无论它多么高档, 作为最基本的功能, 它处理的就是 HTML, CSS 和 Javascript, 至于其它的…… 比如: 播放Flash, 那就只能靠第三方的插件 或 浏览器生产商提供的一些扩展了. 所以, 别想着在浏览器里直接执行Java代码, 呵呵, 至少目前还不行.
(5) 无论什么设备, 只要它能接收HTTP请求, 返回HTTP响应那也就可以姑且称作"WEB服务器", 至于它如何处理接收到的请求, 那就得看你装了什么WEB服务器端软件了. 所以, 客户端可以是电脑, 手机或别的东东, 服务器端也不一定就是多么高档的一台机器, 它也可能就是一个单片机或嵌入式系统. 想想你进入路由器设置的那个界面, 呵呵~
(6) HTTP 和 HTML没有必然的联系! HTTP是描述数据封装格式的一种规范, 而HTML是用来告诉浏览器网页内容的一种语言. 所以, 通过HTTP协议传输的不一定非得是HTML文档, 也可以是"纯数据", 在使用Ajax技术时大多数情况下从服务器返回的仅是数据而已, 并非完整的HTML文档. 当然, 还可以想到…… 可以使用HTTP协议下载一个文件.
(7) 无论客户端和服务器端是多少庞大和复杂的一个系统, 最终将它们联系起来的只是HTTP协议描述的信息. 呵呵, 一切都将被转换为最朴素的数据流.
(8) 从上面的图可以看出, 整个工作过程的"起始点"是由客户端发起"请求", 也就是说, 服务器端是"被动"的响应. 所以, 通过一般的手段是无法由服务器端主动把数据"推送"给客户端的. 那不一般的手段是什么呢? 呵呵, 比如, 很多客户端框架中使用的"轮询"或"捎带"机制.
(9) 客户端和服务器端谁多干点活, 究竟那一些该"胖"些或"富"一些, 这是个永恒的话题, 没有绝对的结论. 但无论如何不应该让HTTP数据包胖起来, 也就是说, 尽可能地减少在客户端和服务器端之间传输的数据和传输的次数.