计算机网络（二）：HTTP 和 HTTPS

A.iguodala

已于 2022-03-26 14:15:56 修改

阅读量3.3k

点赞数 14

分类专栏：计算机网络文章标签： java 计算机网络 http https

于 2021-07-25 19:53:58 首次发布

本文链接：https://blog.csdn.net/weixin_48922154/article/details/119058497

版权

文章目录

1. URL 和 URI
- 1.1 统一资源标识符
- 1.2 URL格式
2. HTTP报文
3. HTTP 连接
4. 与 HTTP 协作的 Web 服务器
5. 识别、认证与安全
6. HTTPS
7. HTTP/1.1、HTTP/2、HTTP/3 演变

1. URL 和 URI

与 URI（Uniform Resource Identifier，统一资源标识符） 相比，我们更熟悉 URL（UniformResource Locator，统一资源定位符）。URL正是使用 Web 浏览器等访问 Web 页面时需要输入的网页地址。

每个URL地址由两部分组成：存放对象的服务器主机名和对象的路径名。

1.1 统一资源标识符

URI 是 Uniform Resource Identifier 的缩写。RFC2396 分别对这 3 个单词进行了如下定义。

Uniform：规定统一的格式可方便处理多种不同类型的资源，而不用根据上下文环境来识别资源指定的访问方式。另外，加入新增的协议方案（如http: 或 ftp:）也更容易。
Resource：资源的定义是“可标识的任何东西”。另外，资源不仅可以是单一的，也可以是多数的集合体。
Identifier：表示可标识的对象。也称为标识符。

URI 可以用字符串标识某一互联网资源，而 URL表示资源的地点（互联网上所处的位置）。可见 URL是 URI 的子集。

1.2 URL格式

在这里插入图片描述

登录信息（认证）：指定用户名和密码作为从服务器端获取资源时必要的登录信息（身份认证）。此项是可选项。
服务器地址：使用绝对 URI 必须指定待访问的服务器地址。地址可以是类似hackr.jp 这种 DNS 可解析的名称，或是 192.168.1.1 这类 IPv4 地址名，还可以是 [0:0:0:0:0:0:0:1] 这样用方括号括起来的 IPv6 地址名。
服务器端口号：指定服务器连接的网络端口号。此项也是可选项，若用户省略则自动使用默认端口号。
带层次的文件路径：指定服务器上的文件路径来定位特指的资源。这与 UNIX 系统的文件目录结构相似。
查询字符串：针对已指定的文件路径内的资源，可以使用查询字符串传入任意参数。此项可选。
片段标识符：使用片段标识符通常可标记出已获取资源中的子资源（文档内的某个位置）。但在 RFC 中并没有明确规定其使用方法。该项也为可选项。

2. HTTP报文

HTTP 报文是在 HTTP 应用程序之间发送的数据块。这些数据块以一些文本形式的元信息（meta-information）开头，这些信息描述了报文的内容及含义，后面跟着可选的数据部分。这些报文在客户端、服务器和代理之间流动。

2.1 报文的组成部分

HTTP 报文是简单的格式化数据块。每条报文都包含一条来自客户端的请求，或者一条来自服务器的响应。它们由三个部分组成：对报文进行描述的起始行（start line）、包含属性的首部（header）块，以及可选的、包含数据的主体（body）部分。

在这里插入图片描述

2.1.1 起始行

所有的 HTTP 报文都以一个起始行作为开始。

请求行
- 请求报文请求服务器对资源进行一些操作。请求报文的起始行，或称为请求行，包含了一个方法和一个请求 URL，还包含 HTTP 的版本号。
响应行
- 响应报文承载了状态信息和操作产生的所有结果数据，将其返回给客户端。响应报文的起始行，或称为响应行。
- 包含了响应报文使用的 HTTP 版本、数字状态码，以及描述操作状态的文本形式的原因短语。

2.1.2 首部

跟在起始行后面的就是零个、一个或多个 HTTP 首部字段，HTTP 首部字段向请求和响应报文中添加了一些附加信息。本质上来说，它们只是一些名 / 值对（键值对）的列表。

HTTP 规范定义了几种首部字段。应用程序也可以随意发明自己所用的首部。HTTP首部可以分为以下五类。

通用首部：既可以出现在请求报文中，也可以出现在响应报文中。不论报文是何类型，都为其提供一些有用信息。
请求首部：提供更多有关请求的信息。
响应首部：提供更多有关响应的信息。
实体首部：描述主体的长度和内容，或者资源自身。
扩展首部：规范中没有定义的新首部。

2.1.3 实体的主体部分

HTTP 报文的第三部分是可选的实体主体部分，她与首部之间有一个空行。实体的主体是 HTTP 报文的负荷。就是 HTTP 要传输的内容。

HTTP 报文可以承载很多类型的数字数据：图片、视频、HTML 文档、软件应用程序、信用卡事务、电子邮件等。

2.2 HTTP 方法

在这里插入图片描述

GET：获取资源
- GET 方法用来请求访问已被 URI 识别的资源。指定的资源经服务器端解析后返回响应内容。
POST：传输实体主体
- POST 方法用来传输实体的主体。数据就放在报⽂的 body ⾥。
PUT：传输文件
- PUT 方法用来传输文件。就像 FTP 协议的文件上传一样，要求在请求报文的主体中包含文件内容，然后保存到请求 URI 指定的位置。
- 但是，鉴于 HTTP/1.1 的 PUT 方法自身不带验证机制，任何人都可以上传文件 , 存在安全性问题，因此一般的 Web 网站不使用该方法。或者要进行密码验证之后可以上传。
HEAD：获得报文首部
- HEAD 方法和 GET 方法一样，只是不返回报文主体部分。用于确认URI 的有效性及资源更新的日期时间等。
DELETE：删除文件
- DELETE 方法用来删除文件，是与 PUT 相反的方法。DELETE 方法按请求 URI 删除指定的资源。
- 和PUT一样不带验证机制所以存在安全问题。
OPTIONS：询问支持的方法
- OPTIONS 方法用来查询针对请求 URI 指定的资源支持的方法。就是查询某个资源可以使用什么方法，返回GET、POST等。
TRACE：追踪路径
- TRACE 方法是让 Web 服务器端将之前的请求通信环回给客户端的方法。
CONNECT：要求用隧道协议连接代理
- CONNECT 方法要求在与代理服务器通信时建立隧道，实现用隧道协议进行 TCP 通信。主要使用 SSL（Secure Sockets Layer，安全套接层）和 TLS（Transport Layer Security，传输层安全）协议把通信内容加密后经网络隧道传输。

GET 和 POST 的区别是什么？

GET 是幂等的，POST 不是，也就是GET多次请求和一次请求相同，不会对服务器产生负面影响，而 POST 可能造成表单的重复提交等。
GET 的 URL 地址可以被缓存到书签，而 POST 不能。
GET请求会被浏览器主动cache，而POST不会，除非手动设置。
GET请求只能进行url编码，而POST支持多种编码方式。
GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。
GET请求在URL中传送的参数是有长度限制的，而POST么有。
对参数的数据类型，GET只接受ASCII字符，而POST没有限制。
GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。
GET参数通过URL传递，POST放在Request body中。
在 HTTP 协议层面：
- GET 只会发送一个TCP数据包，将首部和实体数据一起发送，然后服务器进行响应。
- 而 POST 会先将数据包的首部发送，服务器响应 100 continue，然后继续发送实体部分，服务器进行处理。也就是总共会发送两个 TCP 数据包。