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

assyer · January 27, 2014 · Last by kgtonglousy replied at February 08, 2014 · 8033 hits

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

当然。。

只发一个 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 Floor has deleted
You need to Sign in before reply, if you don't have an account, please Sign up first.