HTTP---基础知识

天天开心！！！

一、HTTP基本概念

1. 什么是HTTP，又有什么用？

HTTP（Hyper Text Transfer Protocol，超文本传输协议），是用于客户端和服务器之间数据传输的应用层协议，主要用在Web浏览器和服务器之间的通信。HTTP最初是为传输HTML文档设计的，但现在支持多种类型的数据，如图片、视频、文本等。

• 举个例子
• Web浏览：浏览器使用HTTP从服务器获取网页和资源，如图片和CSS文件
• 数据传输：开发者使用HTTP在客户端和服务器之间发送和接收数据，特别是在Web API和RESTT服务中。每当你通过浏览器访问一个网页的时候。你往往会输入：http://www.baidu.com…

无状态性：每个HTTP请求都是独立的，不记录之前的任何请求，请求一次，就返回一次（与之前的单播类似）。这简化了协议的实现，但可能会需要使用其他格式（如Cookies或Sessions）来保存状态

2. 一次HTTP请求的过程

底层过程：

1. 输入域名 -> 浏览器跳转 -> 浏览器DNS缓存 -> 本地DNS缓存 -> 路由器DNS缓存 -> DNS服务器  
   - 客户端向服务端发起查询：递归查询  
   - 服务端向服务端发起查询：迭代查询  

2. 浏览器向服务器发起TCP连接（三次握手）  
   - 客户端：请求包连接，`SYN=1 seq=x`  
   - 服务端：响应客户端，`SYN=1 ACK=1 seq=y ack=x+1`  
   - 客户端：建立连接，`ACK=1 seq=x+1 ack=y+1`  

3. 客户端发起http请求：  
   1）请求方法：`GET/POST/HEAD/...`  
   2）请求的Host主机：从URL中提取  
   3）请求资源：如`/xxx.html` `/statics/image/xxx.jpg`  
   4）请求端口：默认`http是80`，`https是443`  
   5）请求携带参数：请求首部信息  
   6）请求最后空行  

4. 服务端响应内容：  
   1）使用WEB服务软件  
   2）响应请求文件类型  
   3）文件是否压缩  
   4）主机是否长连接  

5. 客户端向服务端发起TCP断开（四次挥手）  
   - 客户端：断开请求，`FIN=1 seq=x`
	服务端 --> 响应断开 `FIN=1 ACK=1 ack=x+1 seq=y` --> 客户端  
	服务端 --> 断开连接 `FIN=1 ACK=1 ack=x+1 seq=z` --> 客户端  
	客户端 --> 确认断开 `FIN=1 ACK=1 ack=z+1 seq=x+1` --> 服务端

3.HTTP的协议头

HTTP的协议头分为请求头和响应头

1. HTTP的请求头（对应客户端）

• HTTP请求头包含三部分：请求行（构建请求阶段）、请求头、请求体。

需要注意的点

• Host：指定服务器的域名和端口号（例如：Host.example.com）
• User-Agent：描述客户端应用程序的名称和版本（例如：User-Agent：Mozilla/5.0）
• Accept：指示客户端可以处理的媒体类型（例如：Accept：text/html）
• Content-Type：指示请求主体的数据类型，常见于POST和PUT请求（例如：Content-Type：application/json）
• Authorization：包含认证凭据，用于保护的资源访问（例如：Authorization：Basic）

2. 响应头（对应服务器）
   服务器端接收客户端的请求，将做出处理并返回相应数据，包含响应行，响应头和响应体
   
   浏览器会根据响应数据作出不同的反应，例如不同的Content-Encoding（编码格式）对应使用不同的解码方式；Content-type（数据类型）若为文件类型返回服务器文件，若为json返回XHR；状态码为200代表请求成功，404表示路径不存在等。
   需要注意：

• Content-Type：描述响应内容的媒体类型（例如：Content-Type：text/html）
• Content-length：指示响应主体的长度（以字节为单位）
• Cach-Control：指定缓存策略（例如：Cache-Control：no-cache）
• Set-Cookie：在客户端存储一个Cookie，以后可以用于会话管理
  

4.POST和GET的区别

5. HTTP状态码

6.HTTP的优缺点

二、HTTP的版本演进

HTTp协议从1.0发展到3.0，经历了多次改进。每个版本都有其特定的功能改进和性能优化。

目前主流使用的HTTP版本仍然是HTTP /1.1,但HTTP/2.0正在快速普及，尤其是在性能要求高的环境中，CDN（内容分发网络）服务商普遍采用HTTP/2来提升性能，而HTTP/3也正在逐步被采用，未来可能会成为新的标准，它已经得到了许多现代浏览器（如Chrome、Firefox和Edge）和部分大型互联网公司的支持（如Google和FaceBook）。

1. 各版本的区别
   
   

• 关于SPDY
  SPDY是Google开发的基于TCP的会话层协议，用以最小化网络延迟，提升网络速度，优化用户的网络使用体验。SPDY并不是一种用于替代HTTP的协议，而是对HTTP协议的增强
  新协议的功能包括数据流多路复用、请求优先级以及HTTP报头压缩，谷歌表示引入SPDY协议后，在实验室测试中页面加载速度比原先快64%。
  随后SPDY协议得到Chrome、Firefox等大型浏览器的支持，在一些大型网站和小型网站中部署，这个高效的协议引起了HTTP工作组的注意在，在此基础上制定了官方HTTP2.0标准，
  之后几年SPDY和http2.0继续演进互相促进，Htt2.9让服务器、浏览器和网站开发者在新协议中获得更好的体验，很快被大众所认可。

• 关于HTTP2.0的多路复用
  客户端和服务器将交互数据分解为相互独立的帧，互不影响地交错传输，最后再对端根据帧头众的流标识符把它们重新组装起来，从而实现了TCP链接的多路复用。

• 关于服务端推送
  服务器推送是2.0版本新增的一个强大的功能，和一般而对一问一答的C/S交互不同，推送式交互中服务器可以对客户端的一个请求发送多个响应，除了对最初请求的响应外还向客户端推送额外的资源，无需客户端明确地请求也可以推送。
  就比如我们去餐厅吃饭，服务好的快的餐厅在我们点好一份牛肉面之后，还会给你送上餐巾纸、筷子、勺子等。这样主动式的服务，节约了客人的事件并且提高了用餐体验。
  在实际的C/S交互众，这种主动推送额外资源的方法很有效，因为几乎灭个网络应用都会包含多种资源，客户端需要全部逐个获取它们，此时如果让服务器提前推送这些资源，从而可以有效减少额外的延迟时间，因为服务器可以知道客户端下一步要请求什么资源。

1.各个版本的应用场景

1. HTTP/1.0：简单的网页加载场景
   假设，你正在访问一个包含多个图片的简单网页，比如一个文章页面，其中包含文本、多个图片和有些样式表。

• HTTP/1.0的处理方式：每个资源（HTML文档、每张图片、每个CSS文件）都需要单独建立一个TCP连接。当你加载这个网页时，浏览器必须为每个资源与服务器进行三次握手和连接，再请求资源，最后关闭连接，假如，你的这个网页上有1000个资源，那么它就会建立1000个TCP连接，当然每个连接都需要经历三次握手、四次挥手，整个过程非常费劲

2. HTTP/1.1：电商网站优化加载 假设，你正在浏览一个电商网站，页面包含几十个商品图片、JavaScript文件和样式表

• HTTP/1.1的改进：
  持久连接：浏览器和服务器可以复用同一个TCP连接进行多个请求和响应，这意味着加载整个页面只需要建立一次TCP连接，极大减少了延迟
  分块传输编码：如果网页内容是动态生成的，服务器可以逐块发送数据，而不必等所有内容准备好再发送，这提升了用户体验。

3. HTTP/2：高流量新闻网站场景
   假设，你在访问一个新闻网站，页面有大量图片、视频、广告和动态加载的内容

• HTTP/2的多路复用，所有这些资源都可以通过一个TCP连接同时传输。图片、视频、广告等内容不需要排队等待，而是可以并行加载
• 头部压缩：HTTP/2会压缩请求和响应头部，节省带宽，尤其是在使用CDN加载全球资源时效果显著
• 服务器推送：如果你在加载一个新闻页面时，服务器可以主动推送相关资源（如常用的CSS和JavaScript），即使浏览器还没有请求
• 整个页面几乎同时加载完毕，没有明显的等待，头部压缩还减少了数据流量，特别有助于移动网络用户

4.HTTP/3：实时视频应用场景
假设，你在使用一个实时视频会议应用，或者在玩一款实时在线游戏，这些应用都延迟非常敏感，且需要在网络波动时保持稳定。

• HTTP/3的优势
• 基于QUIC协议：HTTP/3使用UDP而非TCP传输数据，连接建立时间极短，即使网络有波动或数据包丢失，QUIC也能快速恢复，不会像TCP那样出现明显的卡顿
• 低延迟：HTTP/3能在一个连接上并行传输多个数据流，任何一个流的数据包丢失不会影响其他流，确保视频和音频流畅。
• 在网络不稳定的情况下，视频和音频仍然非常清晰，延迟显著降低。你不会感受到明显的卡顿，体验更流畅

2、注意要点

1. HTTP/1.1的管道化问题

• 管道化的工作原理
  在HTTP/1.1中，管道化允许客户端在同一个TCP连接上同时发送多个请求，而不必等待第一个请求的响应回来，然而，响应必须按顺序返回
  例如：如果你发送了三个请求（请求A、B和C），服务器必须按顺序处理并发送响应（A的响应必须先到，然后是B，再是C），即使后面的请求可以更早完成
• 问题
• 推头阻塞（Head-of-Line Blocking）：如果第一个请求A的响应很慢，所有后续请求（B和C）的响应都会被阻塞，必须等待A的响应完成才能处理，这大大限制了并行请求的效率
• 实现复杂性：由于队头阻塞和一些不兼容的问题，HTTP/1.1的管道化很少被实际采用，大多数浏览器甚至默认禁用这项功能。

2. 多路复用的工作原理

• HTTP/2通过再同一个TCP连接上使用二进制分帧技术，将所有数据分成小的帧（frame），并为没饿过请求和响应分配唯一的流ID，这样，多个请求和响应可以同时在一个连接上传输，且帧可以交错进行，不需要按顺序
• 例如，如你发送了三个请求（A、B和C），这些请求的帧可以交错发送，且服务器可以按任意顺序发送响应帧，即使一个请求（如A）变慢了，其他请求（B和C）的响应仍然可以及时送达。
• 优势：
  无对头阻塞：由于请求和响应可以交错传输，HTTP /2避免了HTTP/1.1中的队头阻塞问题，显著提升了传输效率
  更高的并行性：所有请求和响应在一个TCP连接上独立传输，即使一个流变慢，也不会影响其他流。

3. QUIC为什么那么快？为什么抛弃TCP？
   QUIC（Quick UDP Internet Connections）是一种基于UDP的新一代传输协议，最早由Google开发，后来被HTTP/3采用。QUIC之所以比TCP快，是因为它解决了TCP在现代网络中存在的一些效率和延迟问题。

• QUIC为什么弃用TCP？
  TCP自1970年诞生以来，设计上并为考虑现代网络的复杂性和需求。虽然TCP已经通过各种拓展（如快速重传、窗口缩放）来优化性能，但它仍然受到一些历史限制，例如队头阻塞和无法灵活调整的拥塞控制
  QUIC基于UDP重新设计协议，可以绕过TCP的这些局限性，专注于现代网络需求
  另外，现代互联网应用（如视频流、实施游戏和网页加载）对低延迟和高效率的需求越来越高，QUIC的设计更符合这些应用场景，可以在高延迟或丢包率高的环境中表现更佳。

• QUIC为什么快？
• 1. 减少连接建立的延迟
     TCP的连接建立：TCP使用三次握手来建立一个安全的连接，对于HTTPS连接，还需要再进行一次TLS握手，这意味着要经历多个来回，才能开始传输数据，这会导致较高的延迟，尤其是在高延迟的网络环境中（比如跨国网络访问）。
     QUIC的连接建立：QUIC将加密和连接握手合并在一起，通常只需要一个往返（1-RTT）甚至零个往返（0-RTT，基于之前的会话缓存）就可以建立连接，这显著减少了初次连接时的延迟

2. 内置加密（TLS 1.3）
QUIC在设计之初就内置了加密机制，使用了TLS 1.3来加密所有数据。相比之下，TCP需要通过一个单独的握手过程来启动TLS加密，QUIC的这种内置设计简化了加密过程并提高了安全性和连接速度。
3. 解决队头阻塞问题
TCP的队头阻塞：TCP是一个面向字节流的协议，如果某个数据包丢失，接收者必须等待该数据包被重新传输并恢复顺序，才能继续处理后面的数据包。这种重传机制会阻塞整个流的数据传输，增加延迟。
QUIC的多路复用：QUIC使用独立的流来传输数据，即使一个数据包丢失，也只会影响特定的流，不会阻塞其他流的数据传输。这种多路复用机制大幅减少了延迟，尤其在丢包率较高的网络中表现更优。
4. 更高效的丢包处理
TCP的拥塞控制：TCP的拥塞控制机制并不总能高效应对网络变化，而QUIC可以灵活的应对丢包和网络拥塞，使用高级的拥塞控制算法来优化传输性能
更快的丢包恢复：QUIC可以在传输层更快检测丢包并恢复数据，而不用等待传输层和应用层之间的多次交互。

三、HTTP与HTTPS

简单来说，https=http+ssl/tls，即加密的http
HTTP（HyperText Transfer Protocol Secure）是HTTP协议的安全版本，用于在客户端（如浏览器）和服务器之间安全地传输数据。HTTPS通过加密机制来保护用户和网站之间传输的信息，确保数据的机密性和完整性。

• HTTP：数据以明文形式传输，容易被拦截和篡改，适用于对安全性要求不高的通信
• HTTPS：数据加密传输，提供更高的安全性，特别适合保护敏感信息

1.HTTTPS的工作原理

1. 握手过程：
   当你在浏览器中访问一个HTTPS网站时，浏览器和服务器会进行一个加密“握手”过程。
   握手的目的是交换加密密钥，并建立一个安全的加密连接，这个过程会使用SSL/TLS协议，并涉及验证服务器的数字证书。

• 加密传输
  握手成功后，浏览器和服务器之间的所有数据都将通过加密通道传输，确保数据的安全性
• 使用数字证书
  网站通过使用由可信任的证书颁发机构（CA）签发的数字证书来证明自己的身份。浏览器会见擦汗证书的有效性，并显示安全锁图标，提示用户这是一个安全的连接

2. TLS握手过程解析
   握手的目的：

• 商定双方通信所使用的TLS版本（例如TLS1.0，1.2，1.3等等）
• 确定双方所要使用的密码组合
• 客户端通过服务器的公钥和数字证书上的数字签名验证服务器的身份
• 生成会话密钥，该密钥将用于握手结束后的对称加密。
  
  SSL/TLS握手过程