布罗格的烘培机

换了系统，原来的收藏夹也用不上了，也没用过在线书签，所以打开Fiefox就会比较迷茫，还好在Linux下混了几日，Bookemarks也渐渐丰满起来，就来点评一下吧。

IceBin，Post ShoW，维道：
这不就是Blog吗，对，要做就做播客，不是什么PostCast，是传播新闻的播客，这才是真正的播客，去颠覆那些道貌岸然、自以为是的媒体。
上网看什么，天涯我现在很少去，凯迪也去的很少，就连我自己的JZT也很少更新了。如果总是看什么IT啊、WEB2.0啊，老是这些东西，你不觉的烦吗？
Blog发展了这么长时间了，现在是要聚合在一起了，要联合这些草根的力量，做网络的主人。
支持，就是胜利！

和讯博客：
以前我可能会看BlogChina，现在我对hexun上内容还比较感兴趣，时政、财经，还有MM的图片，让我不停的点来点去。
要做到无为而治很难，你越往这个方向用力可能效果越坏。做一个BSP，尽量少去干涉用户，让用户觉得你不存在，好象Blogbus连个像样的首页都没有。
说老实话我还是比较怀念以前的BlogChina的，文字个头比较大，页面内容也不算多，看着现在的Bokee真的有点找不到北了，完全是对BlogChina的反动，是开博客的倒车，也不知道方博士中了什么邪，难道IPO就那么重要吗。

胡言乱语说了一通，如果你有什么认为比较好看的网站，留个网址给我吧。

PS:再说点题外话，据香港某喉舌报纸透露说大陆将于今年底公开纪念胡耀邦90诞辰，ANTI同志又发议论了，居然扯上了新近任命的保密局局长，还从中看出一丝玄机。好一个试探民主，倒是后面有一句评论说的好：谁信谁傻。

在Ubuntu下用Firefox上网，在Mozilla Update网站上找到一个很漂亮的Firefox的主题，默认的主题用腻了，便把它换下来。在Mozilla Update找到的Theme不是超级好看就是超级烂，这一款的确很不错。

ifox下载URL:
https://addons.mozilla.org/themes/moreinfo.php?id=1106&application=firefox

PS:在中国Linux公社注册并发贴，没想有账号已有人用了，试着找回密码，居然我在2004年8月就注册了。
在Linux公社发了我的第一贴，给Fanx提意见，Fanx 1.1版中集成的是Opera而不是Firefox.
在Firefox面前，Opera没有任何优势，实在不值的去用它。

在Linux下我只有选择Firefox了（Opera没有预装所以就免了），总是感觉狐狸打开一个网页慢慢吞吞的，没有Opera快，上网查了一下有相关的提速的文章介绍，设置完成后果然有种改天换地的感觉。

具体方法如下：
启动FireFox，在地址栏中输入“about:config”，页面中找出以下选项（如果没有就新建一个）： “nglayout.initialpaint.delay”（默认值为250，更改为0）；“network.http.pipelining”（默认值为false，更改为true）；“network.http.proxy.pipelining”（默认值为false，更改为true）； “network.http.pipelining.maxrequests”（默认值为4，更改为8）完成设置后保存退出。

重新打开FireFox，这时候就会发现浏览网页的速度比修改之前要快多了。

以下是摘录的详细原理说明：

---

关于 firefox 里面和 HTTP 连接有关的参数设置

发信人: atppp (Big Mouse), 信区: Firefox
标 题: 关于 firefox 里面和 HTTP 连接有关的参数设置
发信站: BBS 水木清华站 (Sun Nov 21 08:14:43 2004), 站内

关于 firefox 里面和 HTTP 连接有关的参数设置

本文是我和一个大牛啰里啰唆的聊天记录整理翻译，属于科普，有些地方可能说得不准确，大家不要当作专业技术文章看。欢迎拍砖。

一个典型的网页，是由一个 html 文件和内嵌的各类元素组成的，这些元素包括页面内的图片，css 文件，javascript 文件等等。每一个内嵌的元素在 HTTP 协议的层面上和那个 html 文件是没有区别的：也就是都需要浏览器去服务器上抓下来。一个早期典型的浏览器是这样实现的：当用户敲入网址之后，浏览器和服务器建立连接，请求这个 html 页面，然后边接收服务器发送的 html 页面，边解析，碰到内嵌元素，可以立即开第二条连接请求。另外，如果内嵌元素很多，他可能会开多条连接同时请求。当所有需要的元素都下载完毕之后，浏览器就会将页面画出来。这个过程就是最早期的 HTTP/1.0 协议所设想
的浏览器实现。

HTTP/1.0 这种多连接的运作模式是可以改进的。建立 TCP 连接的过程是这样：客户端给服务器发一个网络包说我要和你建立连接，服务器收到之后回一个网络包说“我愿意”，然后客户端要再发给服务器一个网络包说“好那咱们开始传数据吧”。这一来一去三个包才能建立 TCP 连接。连接建立之后，浏览器给服务器发请求，服务器给浏览器回应。完事之后又要来回几个网络包关闭 TCP 连接。如果页面有很多文件长度很短的元素，每个元素都需要单建一条连接就会导致网络上大量的都是 TCP 建立连接和断开连接的网络包。另外，TCP 有一个特性叫做 slow start，其含义可以大致这样解释：TCP 连接要求发送端发送一定数量的网络包之后接收端就要回一个“我收到”的网络包，而且网络包在经过每个路由器的时候包头都要被重写，所以在网络不丢包的情况下网络包越大网络的效率就越高。TCP 连接寻找最优网络包大小的方法是，在 TCP 连接建立的初期，网络包的大小是很小的，根据网络状况，两端的程序才会逐步增大网络包的大小以适应带宽提高网络传输的效率。所以浏览器给服务器发请求，如果每发一个请求就关闭连接的话，那这个连接的数据传输很难达到带宽所能承载的速度。

基于这种种原因，HTTP/1.1 很快出来了，提出了持久连接（persistent connection）的概念，也就是说同一条 HTTP 连接，可以同时处理多个请求，同时用一定的机制保证各个请求之间的分离性。具体的操作过程是：服务器给浏览器发送回应之后，并不马上关闭连接；浏览器判断上一个请求的回应已经收完的情况下，可以在这同一个连接上发第二个请求。这种运作模式大大减少了网络包，实验也表明这种做法很有效。但是，由于服务器上保持连接要占用一定的资源，所以一般服务器不会永久保持持久连接，而且也不推荐浏览器和服务器之间建立过多的持久连接。

持久连接可以进一步提速。这就是 pipelining 了。上面可以看到，浏览器需要等待持久连接里上一个请求的回应完全收完才能发送后面的请求。如果和服务器的连接比较慢，往往持久连接大部分时间都花在等待而非数据发送/接收上。pipelining 的意思是，浏览器可以在一个持久连接里一次给服务器发送多个请求，服务器在这个连接上依次回应这些请求。这种运作方式和浏览器缓存结合起来的时候会尤其有效果。比方，图片浏览过后会存在浏览器缓存中，再次请求的时候浏览器会对服务器说，我这里已经有这个图片的缓存了，修改时间是XXXX，如果服务器上这个图片在这之后没有修改过，就不用重发了。这种情
况下，服务器会发一个很短的 304 Not Modified 类型的回应。如果没有 pipelining，每次这样问一下都要等待网络上传输打一个来回；而如果有 pipelining，浏览器可以同时问服务器我这里 4 个图片是否有修改，如果服务器对 pipelining 支持的好，它甚至可以将四个回应放到同一个网络包里面传回来，这是一个大大的加速。

pipelining 最早提出的时候还有一种设想的用法是，如果服务器对 pipelining 支持的好，可以把同一个 pipeline 里面的两个请求放到两个 CPU 上去处理，这样能进一步加快响应速度。当然这个可能也没什么用。

好咯，回过来看一下 firefox about:config network.http.* 的相关参数

network.http.keep-alive 默认是 true
是否允许持久连接，这个默认就是 true，改成 false 的是大傻瓜。

network.http.keep-alive.timeout 默认是 300
持久连接允许的保持时间，这个调大了没意义，因为一般 server 设置的就是 300。server 把你咔嚓了你还能有什么办法。

network.http.max-connections-per-server 默认是 8
连接同一个服务器允许的最大连接数，一般认为在开启持久连接的情况下把这个数值调大没什么作用，而且不太道德。需要调大的情况比方：你同时从网站下 10 个大文件。

network.http.max-persistent-connections-per-server 默认是 2
连接同一个服务器允许的最大持久连接数，这个数值 HTTP/1.1 标准推荐的是 2。调大了反而增加你自己的网络消耗，而且一般一个服务器允许的持久连接数是有限的，你调大了就可能造成别人可用的减少，如果大家都调大，就意味着网络效率的丧失。我个人建议不要动这个数值。

network.http.pipelining 默认是 false
是否允许 pipelining，这个功能因为目前还是试验阶段，所以默认没有打开。强烈建议打开。

network.http.pipelining.maxrequests 默认是 4
每个持久连接允许一次发送的请求数。如果 pipeline 里面有一个大图片或者执行时间较长的脚本，后面已经发送的请求就会被阻塞（注意服务器必须是依次回应请求）；而在这种情况下，如果没有使用 pipelining，浏览器发现一个请求处理时间很长，自然会使用另一条持久连接用作后续请求，甚至进一步开启非持久连接。另外，如果服务器支持 pipelining 不好而过早的关闭连接，浏览器势必要重新发送请求。基于这种种原因，有人认为这个数字设置得比 2 大反而会降低浏览速度。我个人的推荐是，这个数值一般情况可以保持默认值 4，如果浏览的网站有大量的静态小图片，或者网络速度较慢，可以尝试将其调大。

network.http.max-persistent-connections-per-proxy 默认是 4
每个代理服务器允许的最大持久连接数。4 是目前比较公认的最合适的数值，尽管HTTP/1.1 的推荐值是 2。

network.http.proxy.keep-alive 默认是 true
连接代理服务器是否允许持久连接。true 挺好的。

network.http.proxy.pipelining 默认是 false
连接代理服务器是否允许 pipelining。目前普遍认为大多数代理服务器支持 pipelining 并不好，所以一般不建议打开。

pipelining 目前是一个有争议的，仍旧在实验阶段的特性。虽然它可能确实会加快浏览速度，但是这在一定程度上取决于网络的各项因素，所以不要盲目的按照网上建议的方式设置相关的参数。


--

※ 修改:·atppp 于 Nov 21 10:30:44 修改本文·[FROM: 128.12.181.*]
※ 来源:·BBS 水木清华站 smth.org·[FROM: 128.12.181.*]

从2002年开始制作miniRSTD，现在已经是第5版了，几乎是每年就要刻录2张。因手上的miniRSTD送人，这次更新又换了几个软件，再用200M的小光盘刻录下来。

闲来无事就喜欢试用一下其它的浏览器，我用电脑也有近十年了，不过泡网时间不长，所以90年代的浏览器大战也就未曾经历过，但对Netscape却有着一丝敬意，如果没有当年Netscape宣布开放Netscape Communications源代码，我们今天也很难见到一个活力四射的Mozilla社区，也就用不到Firefox这样优秀的Browser。

新的Netscape 8.0使用Mozilla的核心，同时可以选择IE内核作为备用，这一点还比较有趣，之前有人在MyIE上调用过Mozilla核心但非常麻烦，NC8.0在切换双核心上操作比较简单，只是点左下角的一个图标就行了。从菜单上就可以看出NC8.0和FF非常的相似，连设置界面都是一种风格，只是NC8.0的默认外观要好看很多。

Netscape一直走的是一种大而全的路，以前还捆绑Winamp、RealPlayer等，可惜这种方式很难让人接受，就是Mozilla也会觉得过于庞大，于是象Firefox才会异军突起。Netscape 8.0启动速度要比FF慢不少，启动时显示的“启动画面”让我觉得它很笨重。使用浏览器无非只是测试一下显示效果，网页显示速度如何，兼容性如何，其它大多数的功能我是用不上的，我所认为好的软件就应该是只做好它的本职工作，不要搞什么大而全,这样只会增大使用者的负担。

如果问我为什么要用Netscape 8.0，也许就是那种古典而又现代的界面，那种英雄没落却又不甘寂寞的气魄，和心中的一丝丝敬意。

Netscape 8.0的下载地址：
http://browser.netscape.com/

PS:从这篇日志起，就给每个日志起一个有意思的名称做文件名，也算是利用一下Z-Blog的新功能吧。