新手问题 发送一个 http 请求最少需要多少流量?

assyer · 2014年01月27日 · 最后由 kgtonglousy 回复于 2014年02月08日 · 8033 次阅读

请求头什么的也被运营商算在流量里面吗?

当然。。

只发一个 http 的 HEAD 请求,差不多就是 0.5kb

运营商会按所有 IP 报文作为你的计费依据的……

#3 楼 @ch3n 居然有这么多,难怪会对 IM 有专门的协议呢

#5 楼 @assyer 没有 IM 会用 HTTP 的,性能差极了。

#6 楼 @kgen 上台面的 IM 协议可能确实不走 http , 说性能差极了不知道从何而来?

虽然不是一个层次的协议,个人使用的感觉,简单的应用场景,http 和 tcp 差不了太多,很多时候跟 http 前端一般还走一个 apache/nginx 有关,如果自己写程序直接监听 80 , 解析简单 http 差别应该没多大?

#7 楼 @hick 聊天是小数据高并发,封包拆包性能非常关键,HTTP 是第 7 层,TCP 是第 4 层,这个天壤之别,他们的层次差别,就像电脑和光纤的差别那么大。

当年奔 3 的机器,Windows 2000 Server 用 Port Complete 方式,单机可以 3000-4000 clients 并发。 要是用 HTTP,你可以试一下能不能达到 1/10。

还有,聊天是允许数据包丢失的,到达顺序错乱也可以,实效性比一致性更重要。如果你直接操作 UDP,很容易搞。如果你用 HTTP,丢了一个包,反复重发,它不收到,后续的包都不会被返回给应用层。

而且这不是用不用 HTTP 的问题,而是本来用 TCP 和 UDP 很方便的场景,为什么要用一个更麻烦,更慢,又不是为该场景设计的其他协议呢?

我说完了~

#8 楼 @kgen http 第七层 tcp 第四层!咱是在讨论实际问题,不是在讨论理论模型。还天壤之别,嘿嘿,真把 TCP/IP 协议族当完整的 OSI 模型啊?你是没毕业还是毕业没多久?

#9 楼 @hick 你自己测一下就知道了

#9 楼 @hick 你人身攻击前,请先自己研究一下。 如果你觉得理论和实际不符,那么请举例说明,如何在同等条件下,实现第 7 层协议比它的第 4 层协议还快。

@hick @kgen 专业的网络工程师过来说二句,做 IM 开发,讲究的不是 100% 送达,所以一般采用 udp,但是有的时候为了传墙 ( 比如防火墙封了 udp ),会使用 TCP。但使用 HTTP 纯属扯淡了。毕竟报头的数据太大了。这就如坐船去河对面,你没有必要用豪华油轮吧。而 HTTP 带的超文本协议功能是 IM 不需要的。

#12 楼 @lyfi2003 哇塞..你们公司的网络工程师还有时间研究 IM 上的网络包特性啊,太赞了。我们公司的网工已经快是运维里面最苦逼的团队了,天天建机房刷配置做 ACL.

另外我也 YY 一下,个么用 UDP 了之后,无法确认报文到达,那么不是还要花成本来 check 客户端信息的到达与否吗?然后如果再要能像 google hangouts 那样全平台同步信息,用 UDP 做是否也真的比 TCP 有优势呢?

PS: 我丫的是 SA, 真不懂,纯 YY

#9 楼 @hick 这个... 哥们我不知道你的自信是哪来的。虽然协议栈实际使用的时候不是按照 OSI 七层来的,但是我们跟所有人交流的基础都是建立在 OSI 七层模型上面的,最简单的例子是你做 VIP 的时候的健康检查做 TCP 还是做 HTTP, 我们都说是做四层还是七层检测,简单清晰直接,刚毕业的同学也听得懂。

没必要搞出这么多生涩的词汇来 BS 我们这些刚毕业的同学嘛..

#13 楼 @ruohanc

  1. 快速送快:tcp 对丢包网络的利用率非常低,比如 5% 丢包几乎就没法用了。而 udp 不一样,IM 讲究实时到,这样可以自定义检查,比如连续发几个重复包,分多路发送,这样确认方确认时就更大概率确认到。
  2. udp 几乎就是 ip 包,扩展支持群发是简单的事,而 tcp 就不容易了。

当然,如果你只是实现一个简单的送达平台,使用 tcp,http 都完全没问题。但考虑到效率,杀鸡用牛刀就不花算了。

#15 楼 @lyfi2003 槽,说的有道理。提到丢包率我就明白了,各种坑啊。

#15 楼 @lyfi2003 诶,那像 hangouts 那样放在浏览器里的怎么办..

所以催生了后来的 socket io 库和 websocket 协议吗?

#17 楼 @ruohanc 推理的非常正确~

#18 楼 @lyfi2003 听君一席话,胜读十年书 😆

卧槽,, 说好的 emoji 表情呢...

#18 楼 @lyfi2003 那是不是意味着用 Socket 来做 IM 会是比较好的选择?

#11 楼 @kgen 不想做无谓之争,我只不过做过 socket 做过 udp/tcp/http 服务而已。http 协议就是基于 tcp 协议的,发一个 tcp 短连接和 http 短连接的差别只在报文格式,没什么特别引起性能差异的因素。http 和 tcp 同是短链接的性能差别还小于在同一层的 tcp/udp 简单短链接模型。所以你说 http 和 tcp 在 OSI 差几层,还天壤之别,真的没法讨论。

#14 楼 @ruohanc 咱能说点实际点的么?嘿嘿 说出来怕被鄙视,我的自信只是我在 qzone 六七年的开发经验而已。说那么多,你也认为因为一个在 OSI 七层一个在四层所以天壤之别?这种讨论提 OSI 模型有意义么?怎么不说在 TCP/IP 里他们只差一层?同一层的 TCP/UDP 简单场景性能差异能将近 10 倍,所以 http 和 tcp 必定 10 倍以上?

我冒出来只是说 tcp/http 协议在简单场景下没那么大性能差异... 都在说啥啊,嘿嘿

#22 楼 @hick 说 HTTP 的头这么长,你如果就想发一个 "在吗?" 不就显得很浪费咩,从这个角度上来说,TCP 就比 HTTP 要好的多吧..

后来不是都转向 UDP 和 TCP 的讨论了么。别纠结 HTTP 了。UDP 和 TCP 的讨论的点是在于丢包率上,后来还说用 UDP 可以方便的实现群发,这个特性对 TCP 来说太重了。

BTW, 我是没用过 QZone, 这几年 QZone 已经能当 IM 用了.?

#23 楼 @ruohanc 我不知道前面是不是谁说 http 比 TCP 好什么的了?还是 22 楼那个意思,我冒出来只是说" tcp/http 协议在简单场景下没那么大性能差异".不知道为什么 @kgen 同学会把 http 和 tcp 的性能差看那么大。

其实我提这个的原因也是以前没认真想过和对比过 http 和 tcp 简单运用上的性能差异,以前都是很惯性的运用,顶多考虑下 tcp/udp , 但是仔细一想原理,简单的场景 http 和 tcp 能有多大差别啊

#24 楼 @hick 排除举栗恰当与否的问题,我还是基本认同 @kgen 的几个观点的啊,而且你跟他好像在观点上也没有实质的冲突,当他说性能差极了的时候肯定是踩坑了,有坑踩的场景已经不简单了,接着你们就开始分道扬镳各自讨论各自的了..

当开始讨论一个简单场景的时候,我们真的只需要请刚毕业的学生来回答就够了。因为你不管怎么折腾都坏不了,你做 QZone 的话,肯定对高并发高访问下的坑比较了解,这些应该是你擅长的部分,那就别回到简单场景去讨论嘛,说你在行的。

By the way: #9 楼 @hick 最后这句话确实不太合适。

#21 楼 @hick 你对于我提的 3 点问题,毫无建设性意见,也没有提出 HTTP 如何在这几个方面做得比 TCP 和 UDP 更好。

你攻击理论没意义的,文字游戏很廉价,拿点实际解决方案吧。

十几年前,我就潜心做 IM 好几年,嗯嗯,就是你鄙视的 TCP+UDP 实现的,你不能拿网页上和浏览器里面那种页面请求当作 IM 的。你说简单场景,IM 的简单场景是指不进行文件视频等多媒体文本传输的短文字场景,难到你的简单场景是指玩具场景么?

如果是内容简单,咱们继续讨论,如果是玩具(对并发数和性能不关心),那么我就不浪费时间跟你讨论这个了。祝你折腾得开心 😄

#26 楼 @kgen 哎,啥攻击不攻击的... 还楞给扣帽子说我鄙视 TCP+UDP 实现,这下我罪过大了... 我要不要说你鄙视 http ? 嘿嘿... 咱真没法讨论了,只建议心态平和点,沟通理解才能对称。前面说毕业不毕业的,只是针对你拿 OSI 模型说性能那种学生气的话,

强调好几次只对 TCP/HTTP 简单运用性能差异有兴趣,没兴趣也不反对你其他观点。倒是可以解释下简单短连接运用就是几个字节的请求,输出几 k 不等的打包或者不打包文本,

不是说你做 IM 别人说的就是 IM . 我做的 qzone 的服务我还真心觉得是玩具,都不涉及多媒体什么的,最多每秒几千次的 tcp 短连接请求; 冒昧请教下十几年前就潜心研究好几年的不是玩具的 IM 叫啥?这么问会不会被判嘴毒刻薄被封?嘿嘿

#27 楼 @hick 既然你还是在打嘴仗,我也只能当你没实际情况支撑观点了。 帖子里大家都在讨论技术本身,只有你在 9 楼挑起人身攻击,不浪费时间了。

#28 楼 @kgen #27 楼 @hick

俩大神都别闹了,我来分享个干货 (不是我写的), http://blog.csdn.net/russell_tao/article/details/18711023

HTTP 实现的话,如果每个消息都发一个请求,肯定是很慢的... 如果保持长连接,其实就和 TCP 没什么区别了... 用 SSE 这种既成协议,也可以少写很多代码...

考虑丢包和性能的话,还是 TCP 实现比较便利,简单改改就能利用上很多新的基于擦除码的类 TCP 协议了,要达到同样的消息抵达率,erasure code 比用 UDP 重复发同一个包要节省很多流量。而且现在也有 SCTP 协议,广播也不用自己鼓捣 UDP 了...

31 楼 已删除
需要 登录 后方可回复, 如果你还没有账号请 注册新账号