xiaohanliang
Network
Network
  • hi
  • LOWER
    • 0. arp决定下一跳
    • 1. dns决定终点
    • 2. [WIP]dns是不是真的有这些层级
  • MIDDLE
    • 0. 如何理解tcp握手的设计
    • 1. 诡异的tcp拆包现象
    • 2. tcp是一种高效的协议吗
    • 3. 为什么说没有人可以裸用tcp
    • 4. 尝试理解tcp的设计
    • 5. 连接建立@tcp调优
    • 6. 连接断开@tcp调优
    • 7. [WIP]拥塞控制@tcp调优
    • 8. 不需要这些花里胡哨的东西
    • 9. 怎么又是socket又是tcp
  • UPPER
    • 0. 为什么大家都用http
    • 1. [WIP]为什么http也keep-alive
    • 2. 如何保证pipeline的顺序到达
    • 3. 如何保证http的安全性
    • 4. 只不过https基于tls连接
    • 5. 怎么理解get/post
    • 6. http2为什么更快
    • 7. [WIP]内置加速的http3
    • 8. 怎样制造出实时效果-ws
    • 9. kcp是如何榨干你的带宽的
  • DEVICES
    • [302] 跳转到Linux网络设备
  • KUBERNETES NETWORK
    • [302] 跳转到容器网络
Powered by GitBook
On this page
  • Introduction
  • HTTP也粘包?
  • 思路-1.使用Content-Length
  • 思路-2. 使用Transfer-Encoding

Was this helpful?

  1. UPPER

1. [WIP]为什么http也keep-alive

Previous0. 为什么大家都用httpNext2. 如何保证pipeline的顺序到达

Last updated 4 years ago

Was this helpful?

Introduction

正常情况下一条HTTP请求结束以后就会断开连接, 下一条连接就会从TCP握手重新开始. 或者你也可以选择使用KeepAlive属性(现在基本都是默认打开的), 连接建立起来以后不会断开, 下一个请求来了直接复用现有链接, 这就是我们经常说的HTTP长连接

从表面上看, 光是不用握手这一点就省了不少时间, 但也不是所有场景都需要你开KeepAlive, 比如一个冷门图片下载, 一年都下不了几次, 为它还KeepAlive就是浪费服务器连接数

在这之后还开发出了一些新技术, 叫HTTP-Pipelining, 意思是不用等回复就直接连发数条消息, 大概是这样的:

HTTP也粘包?

回顾一下刚刚的pipelining, 里面是三条HTTP消息一起过来的, 如果这三条消息分别代表三条请求, 我们应该怎么把这三条请求拆开?

思路-1.使用Content-Length

好在HTTP报头有一个字段能告诉我们这条消息的长度, 那我们直接读出这么多长度就算读完一条消息就好了

思路-2. 使用Transfer-Encoding

但如果没有这个字段呢? 怎么分包呢? 这种情况的确是存在的, 思考如果只是一个简单的页面或是一张简单的图片, 那么服务器可以给你算一个大小出来. 但如果是动态的生成的, 那怎么办? 难道等全部生成完再发吗? 一下给整出个大内存消耗, 用户也要等很长时间,不合适.

这个时候我们就把动态的东西切成一小段一小段的发给你, 我们每一段都叫一个chunk, 每一段chunk都配有一个长度, 最后这么多段chunk合在一起构成一个完整的视频, 我们会先把chunk-size写在chunk头, 然后你把chunk-size读出来就可以了就能读出一个完整的包出来