做web的同学来讨论一下Http request

典

一个网页一般包含很多资源，导致很多http request,
因为一个request的网络花销大，所以出了很多技术来应对这个问题，什么Cache / 并行下载 /  CDN等等

然后针对图片 / Css / JS 又出来了一些 "合成一个文件"的工具或技术， 所以又能减少request的数据。

我觉得要是有个新的网络标准支持 multi-file request就好了。
------------------------------------------------------------------------------------
一个网页打开的时候，假设包含100个图片，50个JS文件，50个CSS文件，
浏览器先排除掉cach了的内容，假设还有100个资源文件需要向服务器请求。
现有标准是直接发送100个请求，我希望有个新标准只发送一个请求，这个请求包含这100个文件的列表，
服务器收到请求后把100个文件找到，然后zip发送给客户端，这样http request数量就从100降到了1，
最重要的是开发人员/维护人员能得到解放，现在做Sprite， 合并JS/CSS等, 搞死人了
-------------------------------------------------------------------------------------

windix

其实现在的技术本来就像你说的这样:

"只发送一个请求，这个请求包含这100个文件的列表" HTTP Keep-alive -- 虽然确切的说是一个连接, 多个请求。时间浪费主要还是在申请建立连接上
"然后zip发送给客户端" 这个就是现在的常用gz压缩发送文本内容, 比如apache的mod_deflate, 不过通常只用在文本上, 毕竟图片什么的没什么压缩空间

典

就算了有了 Keep-alive，
“减少http request的数量”依然是提高网页速度的第一位的事情。 几乎所有的performance测试工具都会把这个项目摆在第一位，并没有因为有了keep alive, http request的数量就不重要了。

keep-alive只是解决了http request过程中局部的几个问题
To illustrate, here's a non-keepalive session with the client requesting two objects:
Client: Look up IP address of server in DNS
Client: Establish TCP/IP connection to server
Client: Send http request #1
Server: Serve requested resource
Server: Terminate http transaction #1
Server: Terminate TCP/IP connection
Client: Look up IP address of server in DNS
Client: Establish TCP/IP connection to server
Client: Send http request #2
Server: Serve requested resource
Server: Terminate http transaction #2
Server: Terminate TCP/IP connection


And now again with keep-alive:
Client: Look up IP address of server in DNS
Client: Establish TCP/IP connection to server
Client: Send http request #1
Server: Serve requested resource
Server: Terminate http transaction #1
Client: Send http request #2
Server: Serve requested resource
Server: Terminate http transaction #2
Server: Terminate TCP/IP connection

[ 本帖最后由 典 于 2012-2-21 12:54 编辑 ]

dalaohu

ScriptManager which existing for about 100 years. not perfect but helps

to opt the perf you can't just mindlessly say "combine", lots of the time you want to "Split'
you need to find the fine balance between combine and split.

if you combine 100 scripts, you are committing the suicide.

无视

这几天很热的asp.net mvc 4有对js/css bundle/minify的功能，基于folder level的，不过也可以customize.

http://weblogs.asp.net/scottgu/a ... net-4-5-series.aspx

dalaohu

that is independent of mvc which itself is a evolution of scriptmanager, mvcscriptmanager

典

原帖由 dalaohu 于 2012-2-21 13:18 发表
ScriptManager which existing for about 100 years. not perfect but helps

to opt the perf you can't just mindlessly say "combine", lots of the time you want to "Split'
you need to find the fine balance ...

这个也是我的提议的另外一个意义所在，
目前开发/维护人员为了取得平衡要花精力在这上面。
展开来说，假如有100个js函数（或者js object），5个页面a/b/c/d/e
1-20函数是所有页面都共用
21-30函数为a/b页面共用
31-60函数为b/c页面共用
61-100函数为e/a所共用

目前的标准下很难取得一个完美的平衡，是合并到一个js文件好呢，还是分成5个js文件好？还是10个好？实际上也只能大概大概分了。加载页面的时候大量的浪费在所难免

如果采用我的提议，就可以把js按功能尽量分成小文件了，这样加载一个页面就可以尽量少加载不必要的函数了，

dalaohu

yea IT is an applied science, there's only one way to find out - test test and test

典

原帖由 无视 于 2012-2-21 13:21 发表
这几天很热的asp.net mvc 4有对js/css bundle/minify的功能，基于folder level的，不过也可以customize.

http://weblogs.asp.net/scottgu/archive/2011/11/27/new-bundling-and-minification-support-asp-net-4-5-series.aspx

但是我觉得还是不理想，
至少还是要开发维护人员去做，而且结果也不理想，正如dalahu提到，合成一个文件有时候并不是好事

如果在标准上解决问题让系统去做这些事情就完美了

[ 本帖最后由 典 于 2012-2-21 13:46 编辑 ]

dalaohu

it really depends, I've seen enough stupid retards in big and not so big projects, put lots of processing code in Application_BeginRequest and Application_EndRequest.

in that case  you'll have to re think  your perf turning stragy.

无视

原帖由 dalaohu 于 2012-2-21 14:26 发表
that is independent of mvc which itself is a evolution of scriptmanager, mvcscriptmanager

嗯，scriptmanager本身给page嵌进去很多javascript,尤其是ajax那边的东西，什么都能干，事实上谁都不想用它干，mvc的solution就是纯server side的combination/minify，干净了很多。

我们原来的solution是有xml configuration file来做基于page level的js/css的集合，也有browser那边cache的机制，这是常用的大路solution，现在mvc既然有自己的solution了，而且同样可以扩展，开发起来就容易很多。

既然是tag level的markup，我猜web form那边同样可以用.

交易人生

这就是ｓｉｌｖｅｒｌｉｇｈｔ的好处，基本上传输的都是动态数据，界面控件一次到位。

dalaohu

You saying this is the benefit of silverlight, wpf, winform, java?

I call them desktop apps, based on a different dev paradigm

dalaohu

On the other hand I always wish that everyone's using Silverlight, that will make it a perfect world.

交易人生

但ｓｉｌｖｅｒｌｉｇｈｔ的确是ｗｅｂ　ａｐｐｌｉｃａｔｉｏｎ啊，用ｉｅ等浏览器，走的ｈｔｔｐ协议，宿主在ｉｉｓ　ｓｅｒｖｅｒ，ｐｒｏｊｅｃｔ利还有ａｓｐｘ，ｈｔｍｌ，ｊｓ．

肯定不是ｗｉｎ　ｆｏｒｍ，是ｗｅｂｆｏｒｍ。

未来，有个梦想，类似ｓｉｌｖｅｒｌｉｇｈｔ这种技术成为标准，不见得是ｓｉｌｖｅｒｌｉｇｈｔ啦，反正是一种国标，各个公司都遵守，对业界是场革命，不然ＩＴ　搞了这么多年，ｗｅｂ　ｆｏｒｍ还用这种Ｈｔｍｌ重复地传来传去，很多ｏｏ的设计理念在这里没用，整个和技术发展脱节。

交易人生

不见得是silverlight,不然google或者apple或者其他什么公司不干，要搞一套标准出来，类似的理念，对业界真是贡献。

dalaohu

我们想的一样

html js 太原始了。未来必须被革命掉

Dan.and.Andy

其实浏览器可以干很多事, http requests  真正的瓶颈来自国家间的光缆. 下一版的js新标准有类似c的"include"的功能, 具体我忘了. html5 有 web worker, 至于共同的标准,好像就是html5了.

rainmore

这里说的好像有和题目没有关系了。

不知道大家用没用过extjs，在debug的模式下，显示页面时js会load很多文件。但是之后的的request一般都是ajax，jsonp的request。request的量会比初始页面少很多。

但是如果一个网站的每一个页面都有很多js，css或是mms，这就有问题了。

这里太多问题可以讨论了。

fyang1024

LZ的设计提议有违HTTP的设计原则之一 --- Stateless

给一个文件列表，服务器返回一个打包文件包含列表中的文件, 这是应用层的事情