Contents

计算机网络-小林coding-HTTP篇

本系列笔记为作者在跟随小林coding学习的时候做的笔记。感谢小林大大。加上自己的笔记

HTTP 常见面试题

HTTP 基本概念

HTTP :超文本传输协议HyperText Transfer Protocol。专门在「两点」之间「传输」文字、图片、音频、视频等「超文本」数据的「约定和规范」。

CSDN Ysming88 http报文详解

http请求报文内容:请求行+请求头部+空行+请求数据(体)

/images/计算机网络/小林coding/http头.png

HTTP 常见的状态码有哪些

https://cdn.xiaolincoding.com/gh/xiaolincoder/ImageHost/%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BD%91%E7%BB%9C/HTTP/6-%E4%BA%94%E5%A4%A7%E7%B1%BBHTTP%E7%8A%B6%E6%80%81%E7%A0%81.png
  • 「101 Switch Protocols」升级协议,websocket就是使用该方法来从http升级过来的

  • 「204 No Content」响应头没有 body 数据

  • 「206 Partial Content」HTTP 分块下载或断点续传,表示响应返回的 body 数据并不是资源的全部,而是其中的一部分

  • 「301 Moved Permanently」表示永久重定向,说明请求的资源已经不存在了,需改用新的 URL 再次访问

  • 「302 Found」表示临时重定向,说明请求的资源还在,但暂时需要用另一个 URL 来访问

301 和 302 都会在响应头里使用字段 Location,指明后续要跳转的 URL,浏览器会自动重定向新的 URL,尽量使用301,302可能会造成网址劫持,CSDN 一起荡起双桨

  • 「304 Not Modified」不具有跳转的含义,表示资源未修改,重定向已存在的缓冲文件,也称缓存重定向,也就是告诉客户端可以继续使用缓存资源,用于缓存控制
  • 「403 Forbidden」表示服务器禁止访问资源,并不是客户端的请求出错
  • 「404 Not Found」表示请求的资源在服务器上不存在或未找到,所以无法提供给客户端
  • 「501 Not Implemented」表示客户端请求的功能还不支持,类似“即将开业,敬请期待”的意思
  • 「502 Bad Gateway」通常是服务器作为网关或代理时返回的错误码,表示服务器自身工作正常,访问后端服务器发生了错误
  • 「503 Service Unavailable」表示服务器当前很忙,暂时无法响应客户端,类似“网络服务正忙,请稍后重试”的意思
  • 500,400为可预见性错误

HTTP 常见字段有哪些

  • Host 字段:客户端请求,指定服务器的域名
  • Content-Length 字段:服务器回应,表明本次回应的数据长度(单位字节)

HTTP 协议通过设置回车符、换行符作为 HTTP header 的边界,通过 Content-Length 字段作为 HTTP body 的边界,这两个方式都是为了解决“粘包”的问题(HTTP报文可能会被拆分成多个TCP报文,不知道一个HTTP报文的边界在哪)

  • Connection 字段:客户端请求,使用「 HTTP 长连接」机制

HTTP长连接即复用TCP连接,只要任意一端没有明确提出断开连接,则保持 TCP 连接状态。

HTTP/1.1 版本的默认连接都是长连接,老版本需要设置该字段为Keep-Alive

TCP的Keepalive是它的保活机制,即客户端每隔一段时间(小于服务器的长连接超时时间keepalive_timeout)发送一个保活报文来重置服务端的长连接超时计时器。

  • Content-Type 字段:服务器回应,本次数据是什么格式,如:Content-Type: text/html; charset=utf-8

客户端请求的时候,可以使用 Accept 字段声明自己可以接受哪些数据格式:Accept: */*

  • Content-Encoding 字段:服务器回应,数据使用了什么压缩格式,如:Content-Encoding: gzip

客户端在请求时,用 Accept-Encoding 字段说明自己可以接受哪些压缩方法

GET 与 POST

GET 的语义是从服务器获取指定的资源。GET 请求的参数位置一般是写在 URL 中,URL 规定只能支持 ASCII, ,浏览器会对 URL 的长度有限制

POST 的语义是根据请求载荷(报文body)对指定的资源做出处理。携带数据的位置一般是写在报文 body 中, body 中的数据可以是任意格式的数据,浏览器不会对 body 大小做限制。

安全和幂等的概念

  • 在 HTTP 协议里,所谓的「安全」是指请求方法不会「破坏」服务器上的资源
  • 所谓的「幂等」,意思是多次执行相同的操作,结果都是「相同」的

根据RFC规范,GET 方法一般不涉及修改数据是安全且幂等的,POST 涉及修改数据是不安全也不幂等的。可以对 GET 请求的数据做缓存,一般不会缓存 POST 请求

GET 请求可以带 body 吗?

RFC 规范并没有规定 GET 请求不能带 body 的。理论上,任何请求都可以带 body ,URL参数。

HTTP 缓存技术

两种实现:强制缓存和协商缓存

强制缓存:决定是否使用缓存的主动性在于浏览器这边。两个 HTTP 响应头部(Response Header)字段实现

  • Cache-Control, 是一个相对时间;
  • Expires,是一个绝对时间;

Cache-Control的优先级高于 Expires

Cache-Control 来实现强缓存。具体的实现流程如下:

  1. 客户端第一次请求访问服务器资源时,服务器在 Response 头部加上 Cache-Control设置过期时间大小;
  2. 客户端再次请求访问服务器中的该资源时,先比较时间与 Cache-Control 中设置的过期时间,计算该资源是否过期。没有过期使用缓存,否则重新请求服务器;
  3. 服务器再次收到请求后,会设置 Response 头部的 Cache-Control
https://cdn.xiaolincoding.com//mysql/other/1cb6bc37597e4af8adfef412bfc57a42.png

协商缓存:与服务端协商之后,通过协商结果(304)来判断是否使用本地缓存,两种头部字段实现

  • 请求头添加If-Modified-Since字段(值为上次请求服务器响应的Last-Modified字段值)给服务器。如果在该值之后修改了就返回新数据并将最后修改时间Last-Modified添加到响应头返回200,否则直接返回304。基于时间
  • 请求头添加If-None-Match字段(值为上次请求服务器响应的Etag字段值)给服务器。如果在该资源变化了就返回新数据并将Etag添加到响应头返回200,否则直接返回304。基于唯一标志

Etag 的优先级更高

https://cdn.xiaolincoding.com/gh/xiaolincoder/ImageHost4@main/%E7%BD%91%E7%BB%9C/http1.1%E4%BC%98%E5%8C%96/%E7%BC%93%E5%AD%98etag.png
https://cdn.xiaolincoding.com/gh/xiaolincoder/network/http/http%E7%BC%93%E5%AD%98.png

HTTP 特性

HTTP/1.1

优点

  1. 简单:基本的报文格式 header + body,头部信息 key-value
  2. 灵活和易于扩展:请求方法、URI/URL、状态码、头字段组成可以自定义和扩充;下层可以随意变化
  3. 应用广泛和跨平台

缺点

  1. 无状态:解决方法Cookie,jwt
  2. 明文传输:解决方法https
  3. 不安全:不验证通信方的身份,无法证明报文的完整性,解决方法https

HTTP/1.1 的性能

  1. 长连接:复用TCP
  2. 管道网络传输:等待响应不阻塞发送请求(响应会按顺序发回来,先收到的请求响应会阻塞后收到的请求响应)
  3. 队头阻塞:先进入发送队列的统一TCP请求被阻塞时会阻塞后进的

HTTP 与 HTTPS

区别

  1. HTTP 明文传输,HTTPS 在 TCP 和 HTTP 之间加入了 SSL/TLS 安全协议加密传输
  2. HTTPS 连接建立更复杂(SSL/TLS握手)
  3. HTTP 默认80端口,HTTPS 默认443端口
  4. HTTPS的服务器需要向CA申请证书

HTTPS 解决了 HTTP 哪些问题

  • 窃听(机密性):信息加密(混合加密)
https://cdn.xiaolincoding.com/gh/xiaolincoder/ImageHost/%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BD%91%E7%BB%9C/HTTP/20-%E6%B7%B7%E5%90%88%E5%8A%A0%E5%AF%86.png
  • 篡改(完整性):校验机制(摘要算法+数字签名)

https://cdn.xiaolincoding.com/gh/xiaolincoder/ImageHost/%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BD%91%E7%BB%9C/HTTP/%E6%91%98%E8%A6%81%E7%AE%97%E6%B3%95.png

https://cdn.xiaolincoding.com/gh/xiaolincoder/ImageHost/%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BD%91%E7%BB%9C/HTTP/%E6%95%B0%E5%AD%97%E7%AD%BE%E5%90%8D.png

  • 冒充:身份证书(数字证书)
https://cdn.xiaolincoding.com/gh/xiaolincoder/ImageHost/%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BD%91%E7%BB%9C/HTTP/22-%E6%95%B0%E5%AD%97%E8%AF%81%E4%B9%A6%E5%B7%A5%E4%BD%9C%E6%B5%81%E7%A8%8B.png

TLS流程

https://cdn.xiaolincoding.com/gh/xiaolincoder/ImageHost/%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BD%91%E7%BB%9C/HTTP/23-HTTPS%E5%B7%A5%E4%BD%9C%E6%B5%81%E7%A8%8B.png
TLS流程图

premaster是用服务端公钥加密的随机数,客户端在第三次握手时发送给服务端

客户端验证CA流程

https://cdn.xiaolincoding.com/gh/xiaolincoder/ImageHost4@main/%E7%BD%91%E7%BB%9C/https/%E8%AF%81%E4%B9%A6%E7%9A%84%E6%A0%A1%E9%AA%8C.png

证书信任链验证

https://cdn.xiaolincoding.com/gh/xiaolincoder/ImageHost4@main/%E7%BD%91%E7%BB%9C/https/%E7%94%A8%E6%88%B7%E4%BF%A1%E4%BB%BB.png

https://cdn.xiaolincoding.com/gh/xiaolincoder/ImageHost4@main/%E7%BD%91%E7%BB%9C/https/%E8%AF%81%E4%B9%A6%E9%93%BE.png

HTTPS 的应用数据是如何保证完整性的

TLS 在实现上分为握手协议和记录协议两层:

  • TLS 握手协议就是我们前面说的 TLS 四次握手的过程,负责协商加密算法和生成对称密钥,后续用此密钥来保护应用程序数据(即 HTTP 数据);
  • TLS 记录协议负责保护应用程序数据并验证其完整性和来源,所以对 HTTP 数据加密是使用记录协议;

HTTPS 一定安全可靠吗

当信任了中间人服务器证书,中间人就可以窃听修改

https://cdn.xiaolincoding.com/gh/xiaolincoder/network/http/https%E4%B8%AD%E9%97%B4%E4%BA%BA.drawio.png

HTTPS 协议本身到目前为止还是没有任何漏洞的,即使你成功进行中间人攻击,本质上是利用了客户端的漏洞(用户点击继续访问或者被恶意导入伪造的根证书),并不是 HTTPS 不够安全。

抓包工具(如charles)截取 HTTPS 数据工作原理与中间人一致的

HTTP/1.1、HTTP/2、HTTP/3 演变

HTTP/1.1 相比 HTTP/1.0

  • 长连接
  • 管道(pipeline)网络传输:客户端可以不等待前一个请求的响应发送新请求

HTTP/2 优化

  • 头部压缩
  • 二进制格式
  • 并发传输,多个stream复用同一个TCP
  • 服务器主动推送资源

HTTP/3 优化

  • 无队头阻塞:HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP
  • 更快的连接建立
  • 连接迁移

Websocket

小林coding原文

Http和RPC区别

HTTP (HyperText Transfer Protocol) 和 RPC (Remote Procedure Call) 是两种不同类型的通信协议。它们主要的区别在于用途、性能、安全性和灵活性等方面。以下是它们的一些关键区别:

  1. 用途:HTTP是为了让Web浏览器和服务器之间进行通信而设计的,它基于请求/响应模型,并且无状态。RPC则是一种更通用的协议,它允许一个程序在网络上调用另一个程序上的函数或过程,就像调用本地函数或过程一样。

  2. 性能:RPC通常比HTTP更快,更高效,因为它更接近底层,而且可以使用各种各样的传输协议和编码方案。HTTP则是基于文本的,因此可能比较慢且冗余。

  3. 安全性:HTTP支持各种各样的安全机制,如基本认证,摘要认证,SSL/TLS等。RPC的安全性依赖于使用的具体协议和实现,可能需要自行实现安全措施。

  4. 灵活性:HTTP是基于REST架构风格的,它的灵活性较高,支持多种数据格式(如HTML、XML、JSON等),并且可以很容易地通过互联网路由。RPC通常需要特定的客户端和服务器代码,对网络的要求更高,但它支持更多的交互模式,如请求/响应,发布/订阅,点对点等。

在实际使用中,你可能会看到一种称为gRPC的框架,这是Google开发的一个高性能、开源的RPC框架。gRPC可以使用HTTP/2作为底层传输协议,使用Protocol Buffers作为接口定义语言和消息交换格式,从而结合了HTTP和RPC的优点

tcp如何保证可靠传输

TCP (Transmission Control Protocol) 是一个可靠的、面向连接的传输层协议。它通过以下机制来保证数据的可靠传输:

  1. 确认和重传:当接收方收到数据包,它会向发送方发送确认信息(ACK)。如果发送方在一定的超时时间内未收到确认信息,它会重传数据包。这是 TCP 保证可靠传输的核心机制。

  2. 序列号:TCP 为每一个发送的字节分配一个序列号,接收端根据这个序列号来重新组装数据,确保数据按照发送顺序被接收。

  3. 流量控制:TCP 使用滑动窗口机制进行流量控制。这个窗口的大小由接收方决定,表示接收方当前能够接收的数据量。这确保了发送方不会因为发送数据过快而导致接收方处理不过来。

  4. 拥塞控制:当网络出现拥塞,丢包率增加时,TCP 会减少发送数据的速率,避免因为网络拥塞而导致更多的数据丢失。当网络情况改善后,TCP 会逐步增加发送速率。

  5. 错误检测:TCP 使用校验和(checksum)来检测数据在传输过程中是否出现错误。如果接收到的数据包校验和有误,那么这个数据包会被丢弃,然后依赖重传机制来获取丢弃的数据。

通过这些机制,TCP 能够在 IP 网络(一个不可靠的网络)上提供可靠的数据传输。

 |