一文搞懂Http! 结合现实生活

鲤鱼池
82 阅读7分钟

定义

超文本传输协议（HTTP）是一个用于传输超媒体文档（例如 HTML）的应用层协议。

知识体系

计算机网络.png

1. URL

例子：
URL 就是快递单上的完整收件地址，比如：
https://www.shop.com/products?id=123&ref=promo

  • 协议部分（https://）：选择快递公司，比如用 DHL 还是 FedEx。
  • 域名部分（www.shop.com）：写明快递的目的地（收件人）。
  • 路径部分（/products）：告诉快递员具体送到哪间房（某个具体页面）。
  • 查询参数部分（?id=123&ref=promo）：附带的信息，比如产品编号和促销码。

image.png

2. 协议（HTTP 与 HTTPS）

例子：
HTTP 和 HTTPS 是两种快递运输方式。

  • HTTP：普通运输，包裹信息没有加密，任何人都可以看到你的快递单内容（明文传输）。
  • HTTPS：加密运输，所有包裹信息都被封装成暗号，只有收件人能解开（SSL/TLS 加密）。
  • GET： 请求获取Request-URI所标识的资源
  • POST： 在Request-URI所标识的资源后附加新的数据
  • HEAD： 请求获取由Request-URI所标识的资源的响应消息报头
  • PUT： 请求服务器存储一个资源，并用Request-URI作为其标识（修改数据）
  • DELETE： 请求服务器删除对应所标识的资源

3. DNS

例子：
DNS 就像快递公司的导航系统。帮你找到派送地址

  • 你告诉快递员收件人名字（域名），比如“John's Bakery”。
  • 快递公司通过导航系统查出具体的地址（IP 地址），然后送到目的地。

4. TCP 的三次握手

例子：
三次握手就像快递员确认地址是否正确：

  1. 第一步（请求发送）：快递员打电话问你：“这是你的地址吗？”
  2. 第二步（接收确认）：你回答：“是的，我在家。”
  3. 第三步（最终确认）：快递员回复：“好，我马上送过去。”

为什么要三次？
客户端和服务端都需要直到各自可收发，因此需要三次握手（即为了确保双方都能沟通正常，避免误送或白跑。）

image.png

你可以能会问，2 次握手就足够了？。但其实不是，因为服务端还没有确定客户端是否准备好了。比如步骤 3 之后，服务端马上给客户端发送数据，这个时候客户端可能还没有准备好接收数据。因此还需要增加一个过程

5. TCP 的四次挥手

例子：
四次挥手就像快递送达后结束服务：

  1. 第一步：快递员说：“我送完了，可以挂电话了吗？”
  2. 第二步：你说：“等一下，我再检查包裹。”
  3. 第三步：你确认没问题，说：“检查好了，挂吧。”
  4. 第四步：快递员挂电话，服务结束。

image.png

  • 客户端要求断开连接，发送一个断开的请求，这个叫作（FIN）。
  • 服务端收到请求，然后给客户端一个 ACK，作为 FIN 的响应。
  • 这里你需要思考一个问题，可不可以像握手那样马上传 FIN 回去？
  • 其实这个时候服务端不能马上传 FIN，因为断开连接要处理的问题比较多，比如说服务端可能还有发送出去的消息没有得到 ACK；也有可能服务端自己有资源要释放。因此断开连接不能像握手那样操作——将两条消息合并。所以，服务端经过一个等待，确定可以关闭连接了，再发一条 FIN 给客户端。
  • 客户端收到服务端的 FIN，同时客户端也可能有自己的事情需要处理完，比如客户端有发送给服务端没有收到 ACK 的请求，客户端自己处理完成后，再给服务端发送一个 ACK。
  • 为了确保数据能够完成传输。因为当服务端收到客户端的 FIN 报文后，发送的 ACK 报文只是用来应答的，并不表示服务端也希望立即关闭连接。当只有服务端把所有的报文都发送完了，才会发送 FIN 报文，告诉客户端可以断开连接了，因此在断开连接时需要四次挥手。

6. 报文（HTTP 请求与响应）

例子：

  • HTTP 请求报文：你给快递员的订单单据，写着“我要买一双鞋子（GET 请求）”。

    • 包括你的收件地址、产品型号等信息（请求头）。

  • HTTP 响应报文：商店给你寄回的包裹，里面装着你的鞋子和发票（响应头和正文）。

HTTP 协议的请求报文和响应报文的结构基本相同，由三大部分组成

  • 起始行（start line）：描述请求或响应的基本信息；
  • 头部字段集合（header）：使用 key-value 形式更详细地说明报文；
  • 消息正文（entity）：实际传输的数据，它不一定是纯文本，可以是图片、视频等二进制数据

这其中前两部分起始行和头部字段经常又合称为“请求头”或“响应头”，消息正文又称为“实体”，但与“header”对应，很多时候就直接称为“body”。

image.png 常见请求头：

  • Host: 服务器域名和端口号。
  • User-Agent: 客户端（如浏览器）信息。
  • Accept: 客户端可接收的数据类型。
  • Authorization: 身份认证信息。
  • Content-Type: 请求体的数据格式（如 application/json）。
  • Cookie: 向服务器发送的 Cookie 数据。

常见响应头：

  • Content-Type: 响应体的数据类型。
  • Content-Length: 响应体的长度（字节数）。
  • Set-Cookie: 设置 Cookie。
  • Cache-Control: 缓存策略。
  • Access-Control-Allow-Origin: 跨域资源共享（CORS）策略。

image.png

7. Cookie

例子：
Cookie 就像快递员记住你的偏好。

  • 第一次下单时，你告诉快递员“我住在 123 号房，最喜欢晚上送快递”。
  • 以后快递员再接到你的订单时，不用你重复说明，他自动按你的习惯操作。

8. WebSocket

例子：
WebSocket 就像你和快递员之间的实时对讲机。

  • 传统 HTTP 像写信交流，每次都得重新寄信，效率低。
  • WebSocket 建立了一条专线通话后，你和快递员可以随时实时沟通，比如“包裹到了楼下”。
  • WebSocket 是 Html5 定义的一个新协议，与传统的 http 协议不同，该协议允许由服务器主动的向客户端推送信息。
  • 使用 WebSocket 协议的缺点是在服务器端的配置比较复杂。WebSocket 是一个全双工的协议，也就是通信双方是平等的，可以相互发送消息。

为什么引入WebSocket

  • 简单地说，轮询就是不停地向服务器发送 HTTP 请求，问有没有数据，有数据的话服务器就用响应报文回应。如果轮询的频率比较高，那么就可以近似地实现“实时通信”的效果。
  • 但轮询的缺点也很明显，反复发送无效查询请求耗费了大量的带宽和 CPU 资源，非常不经济。
  • 所以，为了克服 HTTP“请求 - 应答”模式的缺点，WebSocket 就“应运而生”了

9. 浏览器

例子：
浏览器就像你的私人助理，负责处理整个购物流程：

  1. 查询产品（发出 HTTP 请求）。
  2. 获取商品详情（接收 HTTP 响应）。
  3. 展示页面（解析 HTML、CSS、JavaScript）。

10. Nginx

例子：
Nginx 是快递公司的分拣中心。

  • 它接收所有快递单，把不同的包裹分配到不同的部门处理（负载均衡）。
  • 静态文件（HTML/CSS/JS）直接发货；复杂的需求交给后台处理。

11. UDP 和 TCP

例子：

  • UDP（无连接传输） ：像撒传单，不管是否有人接到，效率很高，但可靠性差 （一个字就是快）。
  • TCP（面向连接传输） ：像寄快递，每步都有签收确认，确保包裹安全到达。（一个字就是稳）。

从浏览器地址栏输入url到显示页面的步骤

  • 浏览器根据请求的URL交给DNS域名解析，找到真实IP，向服务器发起请求；
  • 服务器交给后台处理完成后返回数据，浏览器接收文件（HTML、JS、CSS、图象等）；
  • 浏览器对加载到的资源（HTML、JS、CSS等）进行语法解析，建立相应的内部数据结构（如HTML的DOM）；
  • 载入解析到的资源文件，渲染页面，完成。
avatar
文章
阅读
粉丝