计算机网络(第六弹) --- 与 HTTP 有关的八个问题-CSDN博客

本文链接：https://blog.csdn.net/Onion_521257/article/details/127885674

当我们用浏览器打开一个网页时基本上都是基于 HTTP 协议来进行传输的, 其实用 APP 来打开一个界面看到的 APP 中的内容大概率也是基于 HTTP 协议传输的, 因此 HTTP 对于网络而言的重要性不言而喻!
HTTP 这个协议在传输层主要是基于 TCP 来实现的, TCP 是传输字节流的协议, 只是把数据按照字节来传输而已, 并没有传输一个 “结构化” 的数据, 而应用层协议就是将传输的字节流赋予一定的含义, 因此 HTTP 协议又可以认为是应用层协议中的典型代表.

❓❓❓问题一: HTTP 方法有哪些?

常用的方法有 GET 和 POST, 下文会进行详述; 不经常使用的还有以下几种:

HEAD: 用于获取报头, 查看状态码等;
PUT: 主要用于传输文件;
DELETE: 主要用来客户端指示服务端, 按照 URL 删除指定的资源;
OPTIONS: 用于查询支持的方法, 也就是用来查询针对请求 URL 指定资源支持的方法;
CONNECT: 此方法要求在与代理服务器通信的时候建立隧道, 并实现用隧道协议进行 TCP 通信;
TRACH: 主要针对客户端对请求消息传输路径的追踪, 此方法让 Web 服务器将之前的请求通信还给客户端的方法.

❓❓❓问题二: GET 和 POST 的区别有哪些?

HTTP 协议中的各种方法之间, 尤其是 GET 和 POST 之间是没有本质区别的, 但是在细节上还是有点区别, 如下:

数据位置: GET 把自定义数据放到 query string, POST 把自定义数据放到 body;
语义区别: GET 一般用于 “获取数据”, POST 一般用于提交数据;
幂等性: GET 请求一般会设计成 “幂等” 的, POST 请求一般不要求设计成 “幂等”; 关于"幂等": 数学上的术语, 某个请求, 执行一次和执行多次没有什么区别, 如果能做到这一点就称之为 “幂等” 的;

补充: 关于上面的这几点区别, 其实并不是绝对的, 某些规则都是可以打破的, RFC 标准中并没有描述 URL 的长度, 也没有描述 body 的长度, 更何况 GET 也可以有 body, POST 也可以有 URL.

其实关于 get 和 post 的区别的理解, 网上的有些说法不能说是不对, 但是是不科学, 不准确的, 下面的 ❌ 仅仅代表不科学, 不代表是错的, 如下面的三种说法:

说法一: GET 用于从服务器获取资源, POST 用于给服务器提交数据; ❌
现在很少严格遵循这样的设计初衷, GET 和 POST 都可以用来获取资源或者是提交数据;
说法二: GET 传输的数据量上限较小, URL 长度有限制, 而 POST 传输的数据量较大;❌
随着技术的更新迭代, URL 的长度也由多年前的 1K - 2K 变的很长, 甚至可能有几个 M 的大小, 因此说法二也是不准确的说辞; 其实关于长度的上限是多少? 以什么标准为准, 要以 RFC 标准文档为准, 在 RFC 2616 标准, 对于 URL 的长度是没有做出限制的, 但是标准就是一份文件而已, 实际开发的时候是要遵守标准, 但是也得看别人是否要遵守这个标准, 现在我们用的 Chrome 浏览器就对此 URL 的长度支持非常长, 一般不用担心长度的问题; 总之, 传输数据量的多少, 完全取决于不同浏览器和不同服务器之间的实现区别;
说法三: POST 比 GET 更安全; ❌
其实 POST 的 “安全” 只是掩耳盗铃, 只是把密码等某些信息放到了 body 中, 这些信息不会出现在 URL 中, 也就是地址栏中, 可能对于普通用户是看不到的, 但是程序猿小白随便用 fiddler 抓个包可能就看到了, 安全与不安全和数据放在哪里没有任何关系, 要想安全那就得加密, 不加密放在哪来也不安全, 因此说法三也是不够科学;
说法四: GET 只能传输文本数据, POST 可以传输二进制数据;❌
关于传输数据类型, 虽然 GET 的 query string 无法直接传输二进制数据, 但是可以针对二进制数据进行 url encode; URL 里面一般是放文本, body 里面可以放文本, 也可以放二进制, GET 也可以有 body, 我们完全可以针对二进制数据进行 URL encode, 这样就可以把数据通过 URL 来传递了.

❓❓❓问题三: 都知道哪些 HTTP 状态码?

在这里插入图片描述

403 Forbidden: 访问被拒绝, 因为没有权限, 很多涉及到用户名和密码的校验过程, 出现密码错误这类情况, 错误提示一般是 forbidden / access denied;
500 Internal Server Error: 表示服务器挂了;
302: 对于 302 这样的重定向响应来说, body 不是必需的, 这里的 body 就是一个简单的 HTML, 里面可能就只有一个 a 标签, 万一浏览器没有自动跳转, 那么用户手动点击此 a 标签也可以进行跳转; 如在登录界面输入用户名密码后, 如果密码错误, 在未登录的状态下访问一个私有项目, 则会报错 403, 现在用户名和密码正确了, 登录成功后就会自动跳转到这个项目里面; 浏览器就是根据 302 中的 Location 决定接下来去哪里.

❓❓❓问题四: header 中都有什么? 解读

header 里面就是一些键值对, 键值对和键值对之间使用 “换行” 来分割, 键和值之间使用 “冒号+空格” 来分割, header 中具体有多少行, 是不固定的, 具体是使用一个 “空行” 来作为分割标记.
在这里插入图片描述
补充: Location: http:// 127.x.x.1/xx, 浏览器看到 3xx 和 Location 就知道接下来要访问哪个地址了.

❓❓❓问题五: 如何使用代码来构造 HTTP 请求(构造请求的方式)?

在网页前端构造 HTTP 请求主要有 3 种方式, 如下:

直接在浏览器中输入 URL, 构造一个 GET;
使用 form 表单, 可以构造 GET 和 POST;
使用 ajax, 可以构造各种请求;
网络编程, 数据通过网络传输, 主要分为两个阶段, 先是等, 其次就是数据拷贝, ajax 可以在浏览器渲染页面的同时, 进行网络请求, 采用异步机制, 如果不这样, 那么浏览器要发起网络请求, 就会阻塞渲染页面的线程, 这样就会导致网络请求中的界面卡死!!!
也可以通过 Java 代码, 基于其中的 Socket 来构造一个 HTTP 请求, 任何能够访问网络的语言, 都可以构造 HTTP 请求, 字符串拼接.

❓❓❓问题六: HTTPS 与 HTTP 的区别?

HTTP 和 HTTPS 都是应用层协议, 应用层的协议很多时候都需要我们自己来定制协议, 可以将 http 理解为一些大佬们已经定义好了的现成的协议, 协议的格式简单, 支持的扩展能力强, 因此我们程序猿可以在大佬们的基础上进行自定制, 以此达到节省开发成本的作用. 需要注意 http 协议是基于 TCP 来实现的.
其实 HTTP 和 HTTPS 一个最直观地区别,如下图所示:
在这里插入图片描述

2022 年了, 现在大部分的网站基本都是 HTTPS, 浏览器也要求如果你不是 HTTPS 就会有一些提示, HTTPS 是要比 HTTP 更安全的, HTTP 是一个明文传输的协议, 本来要传的是啥, 实际穿的就是啥, 一旦传输的过程中数据被第三方获取到了, 可能就会造成一些重要信息的泄露, HTTPS 就是在 HTTP 的基础之上, 引入了一个加密层(SSL/TLS). 关于明文和密文的理解: 明文就是真正要传输的消息; 密文当然就是加密后传输的消息.

❓❓❓问题七: HTTPS 的传输过程? 为什么要有 HTTPS?

客户端先从服务器获取到证书, 证书中包含了公钥;
客户端对证书进行校验;
客户端生成一对对称密钥, 使用公钥对对称密钥进行加密, 然后发送给服务器;
服务器得到这个请求之后, 使用私钥解密, 得到对称密钥;
客户端发出后续的请求, 后续的请求都是使用这个对称密钥加密的;
收到的数据也都是使用此对称密钥进行解密.

关于对称加密: 对称密钥指的是明文 - - > 密文使用同一个密钥, 密文 - - > 明文也是使用同一个密钥, 对称密钥里面最关键的就是这个密钥, 客户端和服务器需要先约定好密钥是啥, 如果是客户端生成了密钥, 就需要通过网络告知服务器密钥是啥;
关于非对称加密: 一个网站生成一对公钥和私钥, 然后将公钥给公开出去, 自己保留私钥; 客户端就先拿这个网站的公钥来对自己的对称密钥进行加密, 然后传输密文给服务器, 服务器拿私钥解密, 也就得到了密钥的明文; 只要有了这个密钥, 后续就可以直接使用对称加密来进行传输;
总之, 对称加密成本是比较低的, 毕竟机器资源消耗少, 速度也快; 非对称加密, 成本比对称加密要高很多, 机器消耗的资源多, 速度也慢!

为什么要引入 HTTPS 呢?
引入 HTTPS 就是要解决数据传输的安全问题: