http协议

流媒体协议详解_步基的博客-CSDN博客

目录

一 http简介

二 quic协议详解

1 重传机制

2 流量控制

3连接迁移

三 tcp拥塞控制

1滑动窗口

2 拥塞窗口

3拥塞控制算法

4 超时重传

5 快速重传/快速恢复

---

一 http简介

http0.9

1991年发布， 没有header，功能非常简单，只支持GET

http1.0

1996年发布，明文传输安全性差，header特别大。它相对0.9有以下增强：

• 增加了header(使用元数据与数据解耦)
• 增加了status code，用于声明请求的结果。
• content-type可以传输其它文件。
• 请求头增加了http/1.0版本号。

支持GET, POST 和 HEAD方法

缓存策略：http1.0的缓存策略主要是依赖header中的If-Modiified-Since,Expire(到期)

缺点：短连接，每请求一次资源就新建一次tcp连接

http1.1

1997发布，是现在使用最广泛的版本。它相对1.0有以下增强：

• 可以设置keepalive让http重用tcp连接(请求必需串行发送)，长连接
• 支持pipeline传输，请求发出后可以继续发送请求
• 增加了HOST头，让服务端知道用户请求的是哪个域名
• 增加了type、language、encoding等header
• 断点续传（通过在 Header 设置参数）
• 新增OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。

缓存策略：http1.1的缓存策略要比http1.0略多,例如 Entity tag(实体标签), If-Unmodified-Since, If-Match, If-None-Match等.

2014年更新了内容：

• 增加了TLS支持,即https传输
• 支持四种模型：短连接，可重用tcp的长链接，服务端push模型(服务端主动将数据推送到客户端cache中)，websocket模型

缺点：还是文本协议，客户端服务端都需要利用cpu解压缩

http2.0

2015年发布，主要是提升安全性与性能。它相对1.1的增强有：

• header压缩(合并同时发出请求的相同部分)
• 二进制分帧传输，更方便头部只传输差异部分
• 流多路复用，同一服务下只需要用一个连接，节省了连接
• 服务器推送，一次客户端请求服务端可以多次响应。
• 可以在一个tcp连接中并发发送请求

缺点：基于tcp传输，会有队头阻塞问题(丢包停止窗口滑动)，tcp会丢包重传。tcp握手延时长，协议僵化问题。

http3.0  

2018年发布，基于谷歌的QUIC，底层使用udp代码tcp协议，用户空间使用。（TCP/udp由操作系统内核实现，系统空间）

这样解决了队头阻塞问题，同样无需握手,性能大大地提升，默认使用tls加密。

二 quic协议详解

1 重传机制

packet number；PKN=4，重传的PKN=2的数据包。offset表示该数据包在总数据中的偏移

2 流量控制

与tcp流量控制滑动窗口原理类似

 和 TCP 不同的是：QUIC 的滑动窗口分为 Connection 和 Stream 两种级别。Connection 流量控制：规定了所有数据流的总窗口大小；Stream 流量控制：规定了每个流的窗口大小。

 则整个 Connection 的可用窗口大小为：20+30+10 = 60

3连接迁移

当客户端切换网络时，和服务器的连接并不会断开，仍然可以正常通信，对于 TCP 协议而言，这是不可能做到的。因为 TCP 的连接基于 4 元组：源 IP、源端口、目的 IP、目的端口，只要其中 1 个发生变化，就需要重新建立连接。但 QUIC 的连接是基于 64 位的 Connection ID，网络切换并不会影响 Connection ID 的变化，连接在逻辑上仍然是通的。

三 tcp拥塞控制

发送方需要缓存已发出但尚未收到 ACK 的包，接收方收到包但没有被用户进程消费之前也得把收到的包留着。但是，缓存是有大小限制的，程序消费数据和链路传输数据的能力也是有限的，发送端和接受端都需要滑动窗口和拥塞窗口机制来限制可发送或者可接收数据的最大范围。

1滑动窗口

滑动窗口分为：发送窗口swnd和接收窗口rwnd。由于TCP是全双工协议，发送端和接收端各自都有发送窗口和接收窗口。各自的接收窗口大小取决于应用、系统、硬件的限制（TCP传输速率不能大于应用的数据处理速率）。各自的发送窗口则要求取决于对端通告的接收窗口。

滑动窗口解决的是流量控制的的问题（接收端和发送端对数据包的处理速度不同）。接收端的缓存传输数据给应用层，这个过程不一定是即时的，如果发送速度太快，会出现接收端数据overflow，流量控制解决的是这个问题。TCP 首部里的 window 字段就是用来表示窗口大小：即接收方目前能接收的缓冲区的剩余大小。

                                                                                     发送方滑动窗口

已发送但还未收到ACK 和未发送    #2和#3这2部分都是发送窗口。

零窗口：如果发送方一直没有收到 ACK，随着数据不断被发送，很快可用窗口就会被耗尽。在这种情况下，发送方也就不会继续发送数据了，这种发送端可用窗口为零的情况称为零窗口。如果发送端陷入零窗口的状态，就会启动零窗口定时器，去定时地询问接收端窗口是否可用。

 

                                                                              接收方滑动窗口

未收到但可接收的数据，#3部分属于接收窗口。如果进程读取缓冲区速度有所变化，接收端可能也会改变接收窗口的大小，每次通告给发送端，就可以控制发送端的发送速度了。这就是所谓的滑动窗口，也就是流量控制机制。由于TCP协议栈在操作系统内核中实现，应用程序无需直接设置窗口大小。

2 拥塞窗口

拥塞窗口 cwnd（congestion window）是发送方维护的一个的状态变量，它会根据网络的拥塞程度动态变化的。

1）滑动窗口解决的是发送方和接收方接收数据速率不一致的问题,通过设置滑动窗口(可以通俗的理解为接收方的缓存)可以缓解这一个问题。具体的操作是接收方会向发送方通知自己可以接受数据的大小，而发送方会根据这个数值，发送数据。
2）拥塞窗口用控制全局网络的拥塞情况。通过控制发送方每次发送的流量的多少，用来逐渐试探整体网络的拥塞程度。如果没有拥塞控制，发送方每次发送的数据大小为滑动窗口，在只有2台主机的时候确实是没有问题的，但是如果放到现实的网络大环境中来说是行不通的。因为如果每台主机都发送的窗口大小的数据，那么整个网络系统必然会瘫痪。所以通过在发送方设置拥塞窗口，可以有效缓解网络压力。

3拥塞控制算法

慢启动、拥塞避免、快速重传、快速恢复：

    1）在 TCP 连接建立完毕后，会先使用慢启动算法，指数级逐渐增大拥塞窗口（+1 +2 +4 +8…）。
    2）当拥塞窗口达到慢启动门限 ssthresh（slow start threshold）时，会使用拥塞避免算法，线性逐渐增大拥塞窗口。（+1 +1 +1…）
    3）当发生超时重传或快速重传时，会使用拥塞发生算法：
        发生超时重传，将 ssthresh 设为 cwnd/2，将 cwnd 设为初始值，然后会再次使用慢启动算法。
        发生快速重传，使用快速恢复算法，然后进入拥塞避免阶段。

4 超时重传

当发送方未在规定时间内接收到 ACK 确认包时，就会超时重传。每当遇到一次超时重传的时候，都会将下一次超时时间间隔设为先前值的两倍。两次超时，就说明网络环境差，不宜频繁反复发送。

                                                                    超时重传图1

5 快速重传/快速恢复

快速重传不以时间为驱动，而是以数据驱动重传。

如果接收方收到一个失序的报文段，就即回送一个 ACK 给发送方。

快速重传的工作方式是当收到三个相同的 ACK 报文时，会在定时器过期之前，重传丢失的报文段。

                                                              快速重传和快速恢复图2

        滑动窗口由接收端控制，向发送端通告，这样就可以保证发送端发出的包数量上限是明确的，也就不会存在淹没接收端导致来不及处理的情况。

         拥塞窗口由发送端控制，它会根据网络中的情况动态的调整，通过慢启动、拥塞避免、拥塞发生、快速恢复四个算法，就可以很好地调整窗口的大小。和滑动窗口一起限制了发送端最大的发送范围，从而保证了拥塞在网络上不会发生。