WEB Technology高手帮忙

vch801

碰到一个棘手问题，本是另外一个TEAM的活儿，可居然两人同时休假，头儿就让我接手，晕啊 !

情况如下：
很多内部用户在抱怨使用某互联网站速度奇慢，可是该网站人员说只有我们的用户有此问题。
本部门用户分布在澳洲12个城市，其中PERTH意见最大。
察看了TICKET里有关此问题的纪录，问题从开始使用此网站就有， 已有3个月了， 前面人员已写报告要求升级PERTH处的链路。

做以下测试
1。用测试帐户从本机登陆该网站， 速度很快
2。远程桌面连接到PERTH一机器登陆该网站，速度依然很快。 ？！
联系PERETH ITSUPPORT，说他们周末上班，也很慢
由此排除链路速度原因。应另有原因

3。用PERTRH 本地PROBE抓包，由于用户太多，PROXY设置有三层：PERTH所有机器用当地的PROXY，PERTH的PROXY再用DATA CENTRE的PROXY， GATEWAY 还有最高一层PROXY 。
抓到的包源和目的地址是两个PROXY ！联系PERTH的人，说机器设置做死的，不能改。
4。分析包，发现大部分到该网站的流量是HTTPS
问题是， TCP 源或目的端口始终是8080， 在对外的HTTPS 中有CONNECT www.XXXX. :443 命令。  对HTTPS不了解，好像应该用TCP 443 才对，为什么TCP PORT 仍然是8080 ？
我想用户反应慢应该是在实际使用中，而我们用的测试帐号始终用HTTP；看来问题出在HTTPS ？
请问 ： PROXY会不会重定向HTTPS 端口号 ？
使用的是HTTP1.0，PROXY会不会显示图PARSE HTTP内容，因为实际为HTTPS流量，PARSE失败才转发出去，过多层的PROXY严重影响HTTPS性能 ？

最后，请问有何阅读材料推荐 ？

新风雨

。。。。。。。。。。。。。。。。。

在我以前的公司有过类似的经验，觉得还是链路问题。不过我们当时的情况是内部网，web （database) server在美国，用的是DDN ,后来upgrade了问题就好多了。因为用https会占用很大的带宽（主要由于频繁的数据查询），导致速度访问很慢。（仅供参考）

[ 本帖最后由 louis72 于 2006-10-11 04:09 编辑 ]

vch801

谢谢楼上的，可他们周末也很慢， 链路是1536/768 FRAME-RELAY； 周末只有很少很少人工作。 我会想办法看看PER TRANSACTION的流量 。

我们当时也是这样的，周末情况好一点，但还是很慢。当然，你们情况可能和我们不一样，但你可以对照一下其他site查一下。

神奇的快沙

问问dust2k
他应该有些想法的

stepau

HTTPS是通过PROXY来走也是可能的，因为PROXY是应用层的协议。觉得你需要看PROXY的日志

[ 本帖最后由 stepau 于 2006-10-11 09:24 编辑 ]

dust2k

这个可以分析一下HTTP Package的链路，如果清楚的知道三层Proxy的话，可以在用户端使用HTTP Sniffer测定一下平均的HTTP Request的response时间，然后根据这个时间一层Proxy一层Proxy地往上隔离来看到底是什么慢了，当然这是比较笨的办法，但还算有效吧。。如果有专门的网络性能分析仪，那就方便的很多。。

HTTPS通常要比HTTP慢很多，不仅是因为握手协议，而且每个申请应答都要加密，对服务器影响的尤其大，但Proxy在处理不会有特别的困难，不知道多层的处理如何，建议使用隔离测试先测HTTP，如果HTTP都没有问题，就要单独测试HTTPS，但HTTPS很不好测，呵呵。。

HTTPS的端口可以随便换，443只是个约定俗成的默认端口，不是强制一定要用的。。

[ 本帖最后由 dust2k 于 2006-10-11 21:32 编辑 ]