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

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

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

当然。。

只发一个 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楼 已删除
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册