小林coding计网-HTTP篇

Mr.ZhaoAbout 10 min

1. 常见面试题

1.1 HTTP是什么

HTTP 是超文本传输协议

HTTP 是一个在计算机世界里专门在「两点」之间「传输」文字、图片、音频、视频等「超文本」数据的「约定和规范」

1.2 HTTP常见状态码

  • 1xx：提示信息，协议处理的一种中间状态，表示接收的请求正在处理
  • 2xx：成功，服务器正常收到客户端的请求，并处理完毕
    • 200 OK 是最常见的成功状态码，表示一切正常。如果是非 HEAD 请求，服务器返回的响应头都会有 body 数据
    • 204 No Content与 200 OK 基本相同，但响应头没有 body 数据
    • 206 Partial Content 应用于 HTTP 分块下载或断点续传，表示响应返回的 body 数据并不是资源的全部，而是其中的一部分
  • 3xx：重定向，表示客户端请求的资源发送了变动，需要客户端用新的 URL 重新发送请求获取资源
    • 301 Moved Permanently永久重定向，说明请求的资源已经不存在了，需改用新的 URL 再次访问
    • 302 Found临时重定向，说明请求的资源还在，但暂时需要用另一个 URL 来访问
    • 301 和 302 都会在响应头里使用字段 Location，指明后续要跳转的 URL，浏览器会自动重定向新的 URL
    • 304 Not Modified不具有跳转的含义，表示资源未修改，重定向已存在的缓冲文件，也称缓存重定向，也就是告诉客户端可以继续使用缓存资源，用于缓存控制
  • 4xx：客户端错误，表示客户端发送的报文有误，服务器无法处理，也就是错误码的含义
    • 400 Bad Request表示客户端请求的报文有错误，但只是个笼统的错误
    • 403 Forbidden表示服务器禁止访问资源，并不是客户端的请求出错
    • 404 Not Found表示请求的资源在服务器上不存在或未找到，所以无法提供给客户端
  • 5xx：服务器错误，表示客户端请求报文正确，但是服务器处理时内部发生了错误
    • 500 Internal Server Error与 400 类似，是个笼统通用的错误码，服务器发生了什么错误，我们并不知道
    • 501 Not Implemented表示客户端请求的功能还不支持，类似“即将开业，敬请期待”的意思
    • 502 Bad Gateway通常是服务器作为网关或代理时返回的错误码，表示服务器自身工作正常，访问后端服务器发生了错误
    • 503 Service Unavailable表示服务器当前很忙，暂时无法响应服务器，类似“网络服务正忙，请稍后重试”的意思

1.3 HTTP常见字段

  • Host 客户端发送请求时，用来指定服务器的域名
  • Content-Length服务器在返回数据时，会有 Content-Length 字段，表明本次回应的数据长度
  • Connection 最常用于客户端要求服务器使用 TCP 持久连接，以便其他请求复用。HTTP/1.1 版本的默认连接都是持久连接，但为了兼容老版本的 HTTP，需要指定 Connection 首部字段的值为 Keep-Alive
  • Content-Type服务器回应时，告诉客户端，本次数据是什么格式。客户端请求的时候，可以使用 Accept字段声明自己可以接受哪些数据格式
  • Content-Encoding表示服务器返回的数据使用了什么压缩格式。客户端在请求时，用 Accept-Encoding字段说明自己可以接受哪些压缩方法
  • ETag一种将资源以字符串形式做唯一性标识的方式，服务器为每份资源分配对应的ETag值；资源更新时候，ETag值也更新。例如：Google中英文网页的URI虽然相同但对应的ETag不同

1.4 GET和POST区别

安全：是指请求方法不会「破坏」服务器上的资源 幂等：多次执行相同的操作，结果都是「相同」的

方法GETPOST
语义请求获取指定的资源（只读）对指定的资源做出处理（新增或提交数据）
安全性安全、幂等不安全、不幂等
缓存可被缓存一般不会缓存
请求数据位置一般写在URL中一般写在报文 body 中

如果不照RFC规范定义的语义来实现的话， 上述都不一定

它们是 HTTP 请求协议的请求方法，而 HTTP 又是基于TCP/IP的关于数据如何在万维网中如何通信的协议，所以 GET/POST 实际上都是 TCP 链接

1.5 强制缓存和协商缓存

缓存技术强制缓存协商缓存
特点浏览器判断没过期，则使用缓存（浏览器主动）状态码304，告知客户端是否可以使用缓存（与服务端协商）
字段Cache-control:相对时间（优先级高） Expires：绝对时间请求If-Modified-Since和响应Last-Modified：如果在这个时间后更新了才接受 & 响应资源最后修改时间
请求If-None-Match和响应ETag：和ETag不一致的时候才接受（ETag优先级高）
结果如果最后修改时间较新，则返回最新资源 200 否则返回304如果资源变化了返回200，否则返回304

1.6 HTTP1.1

优点：

  1. 简单
  2. 灵活易扩展（例如HTTPS和HTTP/3对TCP层的修改）
  3. 应用广泛，跨平台

缺点：

  1. 无状态——Cookie解决
  2. 不安全
    • 明文传输 - 被窃听
    • 不验证通信方身份 - 被冒充和伪装
    • 不校验报文完整性 - 被篡改

和HTTP1.0相比的优势：

  1. 长连接——减少重复操作的开销
  2. 管道网络传输——不等回应即可发送第二个请求，减少响应时间
  3. 队头阻塞

1.7 HTTPS

HTTP的通信接口部分用SSL/TLS协议代替 == HTTPS（即HTTP + 加密 + 认证 + 完整性保护）

协议HTTPHTTPS
安全性明文传输TCP 和 HTTP 之间加入了 SSL/TLS 安全协议，加密传输报文
连接三次握手三次握手+SSL/TLS握手
端口号80443

另外HTTPS需要向CA申请数字证书来确保服务器的身份

如何解决HTTP的安全问题：

  • 明文传输产生的窃听问题——信息加密 （混合加密）
  • 不验证身份产生的冒充问题——校验机制 （证书）
  • 不校验完整性产生的篡改问题——身份证书 （摘要算法）

常见非对称加密算法：RSA、DSA、ECC、DH

常见对称加密算法：DES、3DES、AES、RC（记：RC或者ES结尾的是对称）

1.8 HTTP的演变

协议HTTP/1.1HTTP/2HTTP/3(QUIC的特点)
改进1.长连接
2.管道运输：一次发送多个请求
3.废弃了两种请求方法LINK和UNLINK，新增了CONNECT、OPTIONS和TRACE
4.新增了大量状态码		1.头部压缩
2.二进制格式
3.数据流：可以乱序发送，后stream ID组成HTTP信息
4.多路复用，串行变成并发
5.服务器推送		TCP->UDP+ QUIC
1.无队头阻塞
2.更快的连接建立（QUIC包含TLS，只需1个RTT）
3.连接迁移
不足1.头部冗长，未经压缩，浪费带宽，造成延迟
2.没有请求优先级，所以队头阻塞(HTTP层)
3.服务器只能被动接收客户端的请求		TCP层队头阻塞 TCP和TLS握手时延普及慢，很多网络设备不识别QUIC
小林coeding计网-HTTP篇01.png
小林coeding计网-HTTP篇01.png

2. HTTP1.1如何优化

三个角度具体优化方法
避免发送HTTP请求缓存 客户端第一次请求及数据保存在本地磁盘，形成<key,value>
过期？在请求的ETag带上第一次请求中响应头部的摘要，服务器收到后会与本地资源的摘要作比较，如果相同则返回不含包体的304 Not Modified
减少请求次数1.减少重定向请求次数：利用中间的代理服务器知晓规则
2.合并请求：合并资源，如CSS、webpack
3.延迟发送请求：按需获取，滑动页面的时候再获取资源
减少服务器响应数据大小无损压缩：gzip。请求Accepy-Encoding，响应Content-Encoding（文本、程序代码)
有损压缩：舍弃一些数据（质量）。请求Accept中的q质量因子（音视频、图片）

3. HTTPS如何优化

  1. 硬件优化、软件优化：HTTPS 协议是计算密集型，而不是 I/O 密集型，所以不能把钱花在网卡、硬盘等地方，应该花在 CPU 上
  2. 协议优化
    1. 用ECDHE替换RSA，往返1RTT
    2. TLS 1.2->TLS 1.3，往返1RTT；在Hello时就发送椭圆曲线，且废除RSA和DH
  3. 证书优化
    1. 证书选择：椭圆曲线证书比RSA密钥长度短
    2. 证书验证优化：OCSP(Online Certificate Status Protocal)、OCSP Stapling
  4. 密钥缓存（无前向安全，且易被重放攻击）
    1. Session ID：双方缓存密钥，Session ID和密钥相当于key-value。但是也有缺点，首先是每一个客户端都要保存密钥，其次是现在网站一般多服务器，不一定命中上次的服务器
    2. Session Ticket：客户端负责缓存
    3. Pre-shared Key：TLS 1.3重连只需要0 RTT。重连时Ticket和HTTP一起发给服务端
    4. 解决重放攻击，应给密钥设定过期时间

4. HTTP2提高传输效率、吞吐能力

  • 兼容HTTP1.1

    • 没有在URL改变协议名字，只在应用层做了改变，还是基于TCP传输，但是把HTTP分解成了语义和语法，语义没变，还是请求方法、状态码和头字段等，语法有很多改变

  • 头部压缩（解决头部冗长问题）

    • HPACK取代gzip
      • 静态表：首先两端维护一个字典，用索引号index代替字段名（GET，200，https等），共61种高频字符串
      • 动态表：发送新首部时在静态表里添加索引号
      • Huffman编码：关于首部字段的内容用哈夫曼编码代替，基于二进制编码，不需要\r\n，改用表示字符串长度的Value Length

  • 二进制帧

    • 二进制+位运算

  • 并发传输（解决队头阻塞问题）

    • 多个Stream复用一条TCP连接，达到并发效果；每个帧头携带Stream ID，同一Stream内部的帧严格有序，方便接收后组装；还可以设置优先级，比方说先传递HTML再传递图片
    • 包含关系：TCP连接 > Stream > Message >Frame

  • 服务器主动推送（解决不支持服务器推送问题）

但是HTTP2是基于TCP传输数据的，TCP是字节流协议，必须保证字节数据是完整连续的，内核才会将缓冲区的数据给HTTP应用，这方面存在阻塞，因此改用UDP，即HTTP3

5. HTTP3

之前存在的问题：

  1. 队头阻塞：TCP丢包时，整个TCP都要等待重传
  2. 握手延迟：发起HTTP请求时，需要经过TCP+TLS总计3RTT时延
  3. 网络迁移需要重新连接：4G切WiFi时要重新握手，因为IP地址和端口变动了

QUIC协议特点：

  1. 无队头阻塞，Stream之间没有依赖
  2. 更快建立连接：QUIC包含TLS，只需要1RTT即可握手
  3. 连接迁移：通过连接ID标记两个端点，而不是IP地址和端口

其他：HPACK升级->QPACK，静态表91项