计网-HTTP

什么是HTTP？

是什么？
HTTP： 超文本传输协议 HyperText Transfer Protocol
是一个基于TCP的应用层协议，专门在互联网中的「两点」之间「传输」文字、图片、音频、视频等「超文本」数据的「协议」

特点
0、简单
HTTP 基本的报文格式就是 header + body，头部信息也是 key-value 简单文本的形式，易于理解，降低了学习和使用的门槛。

1、 灵活可扩展

• 自己很随便：
  HTTP只规定了报文的基本格式，比如用空格分隔单词，用换行分隔字段，“header+body”等，报文里的各个组成部分都没有做严格的语法语义限制，可以由开发者任意定制。
  HTTP协议里的请求方法、URL、状态码、头字段等每个部分都没有被固定死，都允许开发人员自定义和扩充。
• 对别人没要求：
  同时 HTTP 由于是工作在应用层（ OSI 第七层），它的下层可以随意变化的。比如：HTTPS 就是在 HTTP 与 TCP 层之间增加了 SSL/TLS 安全传输层，HTTP/3 直接把 TCP 层换成了基于 UDP 的 QUIC。

1、基于TCP实现可靠传输
但是HTTP并不能保证数据一定能够发送到另一端，“可靠”只是向使用者提供了一个“承诺”，会在下层用多种手段“尽量”保证数据的完整送达。

2、最能打的应用层协议
其他的应用层协议都仅关注很小的应用领域，局限在很少的应用场景。
而HTTP凭借着可携带任意header字段和body数据的报文结构，以及连接控制、缓存代理等方便易用的特性，只要不太苛求性能，HTTP几乎可以传递一切东西，满足各种需求，称得上是一个“万能”的协议。

3、请求-应答通信模式

5、两个双刃剑特点：

• 无状态
  每个请求都是互相独立、毫无关联的，协议不要求客户端或服务器记录请求相关的信息。
  好处：减轻服务器的负担
  坏处：每次请求都是独立的，所以需要重复验证用户身份，解决办法：Cookie
• 明文传输
  好处：明文意味着在传输过程中的信息，是可方便阅读的，为我们调试工作带了极大的便利性。
  坏处：不安全。解决办法：HTTPS

下面的特点都是由灵活可扩展特点扩展而来的

4、长连接
HTTP 1.0中是短连接，每进行一次 HTTP 通信就要断开一次 TCP连接。很浪费资源。
HTTP/1.1 开始默认长连接。长连接中只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。等数据发送完了再断开连接，明显提升效率。

4、分块传输编码
在 HTTP 通信过程中，请求的编码实体资源尚未全部传输完成之前，浏览器无法显示请求页面。在传输大容量数据时，通过把数据分割成多块，能够让浏览器逐步显示页面。
这种把实体主体分块的功能称为分块传输编码（Chunked Transfer Coding）。

6、 支持范围请求（视频拖曳）
执行范围请求时，会用到首部字段 Range 来指定资源的 byte 范围

7、内容协商(返回最合适的内容)
内容协商机制是指客户端和服务器端就响应的资源内容进行交涉，然后提供给客户端最为适合的资源。
例如：同一个 Web 网站有可能存在着多份相同内容的页面。比如英语版和中文版的 Web 页面，它们内容上虽相同，但使用的语言却不同。

HTTP 报文详解

HTTP 报文主要由三大部分组成：

• 起始行（请求行/响应行）：描述请求或响应的基本信息；
• 首部header：使用 key-value 形式更详细地描述报文；
• 报文主体（entity/body）：实际传输的数据
  

HTTP 报文分为请求报文和响应报文两种。

请求报文：

响应报文：

请求行&响应行

请求行格式：
请求方法+URL+遵循的协议及版本

响应行格式：
协议版本+状态码+状态码原因短语

HTTP 请求方法

GET ：查
URI指定的资源经服务器端解析后返回响应内容

POST ：创建、新增
POST可能会修改服务器上的资源的请求

PUT ：修改（几乎不用，甚至禁止使用）

DELETE ：删除
按请求 URI 删除指定的资源。

GET和POST的区别

我们常说的一些区别都是一些表面上的，比如：GET没有POST安全、GET请求时URL的长度是有限制的、GET没有body而POST有body等等。这些都是针对浏览器中的要求

HTTP协议没有规定这么多条条框框
此时GET和POST只是HTTP协议中的两种请求方式，而HTTP协议是基于TCP/IP的应用层协议， 无论GET还是POST，用的都是同一个传输层协议，所以在传输上没有区别，GET也可以有body，POST也不一定非要使用body，只要客户端和服务器端确定好规范即可。

GET和POST都不安全：
无论是GET请求还是POST请求，其本质都是不安全的，为什么这样说呢？如果仅仅从GET请求的参数在地址栏是可见的，POST是不可见的，那就太肤浅了。 由于HTTP自己本身是一个明文协议，每个HTTP请求和返回的数据在网络上都是明文传播，无论是url、header还是body。 只要在网络节点捉包，就能获取完整的数据报文，要防止泄密的唯一手段就是使用HTTPS

为什么在浏览器中GET请求方式的url长度有限制呢？
对url的限制是浏览器做的，不是http协议做的
因为浏览器要对url进行解析，而解析的时候就要分配内存。对于一个字节流的解析，必须分配buffer来保存所有要存储的数据。而url这种东西必须当作一个整体看待，无法一块一块处理，于是就处理一个请求时必须分配一整块足够大的内存。如果url太长，而并发又很高，就容易挤爆服务器的内存。

URI和URL

• URI
  Uniform Resource Identifier统一资源标识符
  URI只是一种概念，使用它在某一规则下就能够唯一地标记互联网上的资源。规则有很多种比如：用 身份证号、姓名等等，只要能唯一的标识即可。
• URL
  Uniform Resource Locator统一资源定位符
  也就是我们俗称的网址，URL是URI概念的一种具体的实现方式

URL举例：

上面三个框起来的是URL必备三部分：
①协议
②域名
③带层次的文件路径

HTTP的版本

HTTP队头阻塞是由请求-应答模型所导致的
因为HTTP规定报文必须是“一发一收”，这就形成了一个先进先出的“串行”队列。
队列里的请求没有轻重缓急的优先级，只有入队的先后顺序，排在前面的请求被处理之后，后面的请求才能被处理，否则只能阻塞。
TCP队头阻塞是由其重传机制导致的
接收窗口发现某个数据包丢失就会阻塞接收数据，直到丢失数据包重传到达之后才会继续接收新的数据包，导致后面的数据包都会排队阻塞。

HTTP/1.1(不解决队头阻塞)

相较1.0的新增和改进：

• 允许数据分块（chunked）

• 支持 pipeline，客户端无需等待接收第一次请求的响应，即可发送第二次请求。虽然提升了发送端的性能，但是服务器应答仍需排队，没有解决队头阻塞。
  

HTTP/2(解决HTTP的队头阻塞)

1、支持多路复用：在一个 HTTP/2 连接上可以并发多个流，也就是多个“请求 - 响应”报文
2、 支持服务端主动推送数据

HTTP/2 是如何解决“队头阻塞”问题的？
每一个请求响应都是一个流，流和流之间可以并行不依赖，所以可以不用排队，也就不存在队头阻塞，
不同流有唯一标识所以流之间的数据不会错乱，而流内的帧也保证有序，所以数据收发没有问题。

HTTP/3(彻底解决队头阻塞)

为了完全避免TCP重传机制导致的队头阻塞，就必须抛弃TCP，于是HTTP/3 基于QUIC协议，QUIC是⼀个新的传输层协议，建⽴在UDP之上，因为UDP是⽆序的，包之间没有依赖关系，所以就从根本上解决了“队头阻塞”

QUIC特点
最重要的三个特点：彻底解决队头阻塞、更快的连接建立、支持连接迁移

1. 无队头阻塞
   由于 QUIC 使用的传输协议是 UDP，UDP 不关心数据包的顺序，即使数据包丢失，UDP 也不关心。所以如果QUIC 中的某个流中的数据包丢失了，只会阻塞该流，其他流不会受影响。因此彻底避免了队头阻塞

2. 更快的连接建立
   QUIC 内部包含了 TLS，它在自己的帧会携带 TLS 里的“记录”，再加上 QUIC 使用的是 TLS1.3，因此仅需 1 个 RTT 就可以「同时」完成建立连接与密钥协商，甚至在第二次连接的时候，应用数据包可以和 QUIC 握手信息（连接信息 + TLS 信息）一起发送，达到 0-RTT 的效果

3. 连接迁移
   QUIC使⽤Connection ID来标记通信的两个端点，客⼾端和服务器可以⾃⾏选择⼀组ID来标记⾃⼰，这样就解除了TCP⾥连接对IP地址+端⼝的四元组的强绑定，⽀持“连接迁移。
   ⽐如⼿机由4G切换到WiFi。这时IP地址会发⽣变化，TCP就必须重新建⽴连接。⽽QUIC连接⾥的两端连接ID不会变，所以连接在“逻辑上”没有中断，它就可以在新的IP地址上继续使⽤之前的连接，消除重连的成本，实现连接的⽆缝迁移。

HTTP响应状态码

菜鸟教程-状态码总结