Http的演化 Http1.1 Http2.0 Http3.0

2019-08-23

why tcp and http donot like each other

image

HTTP/2的多路复用和HTTP/1.X中的长连接复用的区别

HTTP/1.X 一次请求-响应，建立一个连接，用完关闭；每一个请求都要建立一个连接； HTTP/1.1 Pipeling解决方式为，若干个请求排队串行化单线程处理，后面的请求等待前面请求的返回才能获得执行机会，一旦有某请求超时等，后续请求只能被阻塞，毫无办法，也就是人们常说的线头阻塞； HTTP/2多个请求可同时在一个连接上并行执行。某个请求任务耗时严重，不会影响到其它连接的正常执行；

HTTP 0.9最初版

只支持get请求 Server response is in HTML 一个请求需要一个连接 image

HTTP/1.0

传输的数据不再局限于文本
Connection between server and client is closed after each request
每一个TCP连接只能发送一个HTTP请求，服务器发送完响应，就关闭连接。如果后面需要请求新的数据，则需要再次建立TCP连接，但是TCP建立连接的三次握手成本比较高，并且TCP连接初始的时候发送数据的速度相对较慢，有一个慢启动和拥塞避免的阶段。 极端情况，如果每次请求的数据很少，但是请求很频繁，这样每次请求很少的数据都需要建立连接然后断开。

HTTP1.1

长连接：引入了 TCP 连接复用，即一个 TCP 默认不关闭，可以被多个请求复用
持久连接下一个连接中的请求仍然是串行的，如果某个请求出现网络阻塞等问题，会导致同一条连接上的后续请求被阻塞。
所以HTTP/1.1中提出了pipelining概念

pipelining

引入了管道机制，即在同一个TCP连接里面，多个HTTP请求可以并行(同个域名、同一条 TCP 链接)，客户端不用等待上一次请求结果返回,就可以发出下一次请求（响应的顺序必须和请求的顺序一致，因此不常用）.
但这要求服务端必须按照请求发送的顺序返回响应，以保证客户端能 够区分出每次请求的响应内容。当顺序请求多个文件是，其中某个请求被阻塞时，在其后的所有请求也一并被阻塞，这就是队头阻塞（）
problem:lack of multiplexing in http 🥇
(1)signel,large request can bblock all others
(2)single,failing request can terminate whole pipeline

HTTP2.0

客户端在发送请求时会将每个请求的内容封装成不同的带有编号的二进制帧（Frame），然后将这些帧同时发送给服务端。服务端接收到数据之后，会将相同编号的帧合并为完整的请求信息。 同样，服务端返回结果、客户端接收结果也遵循这个帧的拆分与组合的过程。 有了二进制分帧后，对于同一个域，客户端只需要与服务端建立一个连接即可完成通信需求，这种利用一个连接来发送多个请求的方式称为多路复用。每一条路都被称为一个 stream（流）.

多路复用（multiplexing）： 废弃了 HTTP/1.1 中的管道，同一个TCP连接里面，客户端和服务器可以同时发送多个请求和多个响应，并且不用按照顺序来,通过streamId来互相区别。由于服务器不用按顺序来处理响应，所以避免了“对头堵塞”的问题。但在TCP协议级别上仍然存在类似的队头问题
Http2.0 solves HTTP head of line blocking, but still suffer from TCP head-of-line blocking

HTTP3.0

HTTP3 背后的主要思想是放弃 TCP，转而使用基于 UDP 的 QUIC （快速UDP互联网连接）协议。

video streaming

  • unsupported format
  • missing plugins
  • long start-up time
  • low quality
  • frequent stalls

Performance struggles with videl streaming

Understand the problems of traditional video streaming

Dynamic Adaptive Streaming over HTTP(DASH)

DASH enables adaptive bitrate streaming, where the video quality is adjusted dynamically based on the viewer’s network conditions. This ensures a smooth viewing experience by adapting to changes in available bandwidth.

Adaptive Bitrate Streaming 自适应比特率传输

a video file is split up into segments,typically with a duration between two and ten seconds. Each segment is encoded at several bitrates.
A manifest file describes what the order and bitrate of the segment is.
The video player processes this manifest file, and requests segments of a certain bitrate according to its own measurements ofthe available bandwidth.
向用户的视频播放器提供多个相同内容、不同大小文件的文件，然后客户端选择最合适的文件在设备上播放。
自适应比特率流动态跟踪 CPU、内存容量和网络状况，然后提供匹配的视频质量
源视频在服务器端以不同的比特率编码，然后将这些视频文件分成小段

Push-based video streaming

Server pushes stream to client,client acknowledges recption
Adaptation based on how many packets are received
Continuous flow from server to client

  • scalability(Video stream always comes from HTTP server)
  • Implementation(manual configuration ofthen required, firewalls may block UDP traffic)

Pull-based video streaming

DASH client requests video segments from HTTP server
Client re-assembles segments to form a video stream
Flexibility:each segment can come from a different server
Scalability:Server is dumb and state-less

  • Use of existing infrastructure
  • HTTp traversrs firewalls without problems
  • On-demand,live and time-shift streaming

    Self optimization problem

    Bandwidth measurements might be wrong

observing performance problem

many switches in bitrate
unfair sharing of bandwidth

https://juejin.cn/post/7079936383925616653