应用层协议 - HTTP

文章目录

前言

1 . 应用层概要

2. WWW

2.1 互联网的蓬勃发展

2.2 WWW基本概念

2.3 URI

3 . HTTP

3.1 工作过程

3.2 HTTP协议格式

3.3 HTTP请求

3.3.1 URL基本格式

3.3.2 认识方法

get方法

post方法

其他方法

3.3.2 认识请求报头

3.3.3 认识请求正文

3.4 HTTP响应

状态码

响应报头

4. HTTPS

加密

HTTPS的工作过程

对称加密

非对称加密

证书

总结

前言

大家好,今天给大家介绍一下应用层协议 - HTTP

1 . 应用层概要

在OSI参考模型中, IP协议, TCP协议以及UDP协议是通信最基本的部分, 它们属于OSI参考模型中的下半部分。

利用网络的应用程序很多, 包括Web浏览器, 电子邮件, 远程登录, 文件传输, 网络管理等。能够让这些应用进行特定通信处理的这是应用层协议。

2. WWW

2.1 互联网的蓬勃发展

万维网(WWW, world wide web) 是将互联网中的信息以超文本形式展现的系统。也叫做web。

可以展示www信息的客户端软件叫做Web浏览器，就比如我现在正在用的Chrome。

2.2 WWW基本概念

www定义了三个重要的概念, 它们分别是访问信息的手段和位置(URI), 信息的表现形式(HTML)以及信息的转发(HTTP, HyperText Transfer Protocol)

2.3 URI

URI 是 Uniform Resource Identifier的缩写, 用于标识资源。URI是一种可以用于www之外的高效识别码, 它被用于主页地址, 电子邮件, 电话号码等各种组合中。

上述例子属于是一般主页地址，也被叫做URL（Uniform Resource Locator）。 URL常被人们用来表示互联网中资源文件的具体位置。但是URI并不局限于互联网，它们两者的关系就是 URL是URI的子集。

UR I的 http 方案如下

3 . HTTP

3.1 工作过程

当用户在浏览器的地址栏输入所要访问的Web页面的URI之后, HTTP的处理就会开始。HTTP默认使用80端口。它的工作机制，首先是建立TCP连接，然后在这个TCP连接中进行请求应答以及数据报的发送。

3.2 HTTP协议格式

我们可以通过一款抓包工具查看HTTP的协议格式,这个工具也是我一直在用的。

Fiddler（下载地址）

打开Fiddler随便抓一个包就可以看到 HTTP的格式

请求格式

首行: [方法] + [url] + [版本]
Header: 请求的属性, 冒号分割的键值对;每组属性之间使用\n分隔;遇到空行表示Header部分结束
Body: 空行后面的内容都是Body. Body允许为空字符串. 如果Body存在, 则在Header中会有一个Content-Length属性来标识Body的长度;

响应格式

首行: [版本号] + [状态码] + [状态码解释]
Header: 请求的属性, 冒号分割的键值对;每组属性之间使用\n分隔;遇到空行表示Header部分结束
Body: 空行后面的内容都是Body. Body允许为空字符串. 如果Body存在, 则在Header中会有一个Content-Length属性来标识Body的长度; 如果服务器返回了一个html页面, 那么html页面内容就是在body中.

3.3 HTTP请求

3.3.1 URL基本格式

平时我们俗称的 "网址" 其实就是说的 URL (Uniform Resource Locator 统一资源定位符). 互联网上的每个文件都有一个唯一的URL，它包含的信息指出文件的位置以及浏览器应该怎么处理它. URL 的详细规则由因特网标准RFC1738 进行了约定(https://datatracker.ietf.org/doc/html/rfc1738)

一个具体的URL

https://v.bitedu.vip/personInf/student?userId=10000&classId=100

https : 协议方案名. 常见的有 http 和 https, 也有其他的类型. (例如访问 mysql 时用的 jdbc:mysql )
user:pass : 登陆信息. 现在的网站进行身份认证一般不再通过 URL 进行了. 一般都会省略
v.bitedu.vip : 服务器地址. 此处是一个 "域名", 域名会通过 DNS 系统解析成一个具体的 IP 地址. (通过 ping 命令可以看到, v.bitedu.vip 的真实 IP 地址为 118.24.113.28 )
端口号: 上面的 URL 中端口号被省略了. 当端口号省略的时候, 浏览器会根据协议类型自动决定使用哪个端口. 例如 http 协议默认使用 80 端口, https 协议默认使用 443 端口.
/personInf/student : 带层次的文件路径.
userId=10000&classId=100 : 查询字符串(query string). 本质是一个键值对结构. 键值对之间使用 & 分隔. 键和值之间使用 = 分隔.

3.3.2 认识方法

get方法

GET 是最常用的 HTTP 方法. 常用于获取服务器上的某个资源. 在浏览器中直接输入 URL, 此时浏览器就会发送出一个 GET 请求. 另外, HTML 中的 link, img, script 等标签, 也会触发 GET 请求.

特点

首行的第一部分为 GET

URL 的 query string 可以为空, 也可以不为空.

header 部分有若干个键值对结构.

body 部分为空.

post方法

POST 方法也是一种常见的方法. 多用于提交用户输入的数据给服务器(例如登陆页面). 通过 HTML 中的 form 标签可以构造 POST 请求, 或者使用 JavaScript 的 ajax 也可以构造 POST 请求.

特点

首行的第一部分为 POST URL 的 query string 一般为空 (也可以不为空) header 部分有若干个键值对结构. body 部分一般不为空. body 内的数据格式通过 header 中的 Content-Type 指定. body 的长度由 header 中的 Content-Length 指定.

其他方法

PUT：用于更新指定资源。
DELETE：用于删除指定资源。
PATCH：用于对资源进行部分更新。
HEAD：类似于GET请求，但只返回头部信息，不返回实际内容。
OPTIONS：用于获取目标资源支持的通信选项。
TRACE：用于追踪路径到目标资源的消息往返情况。
CONNECT：用于要求在与代理服务器通信时建立隧道。

3.3.2 认识请求报头

Host：指定请求的目标服务器的主机名和端口号。
User-Agent：标识客户端的用户代理（浏览器、应用程序等）。
Accept：指定客户端可以接受的响应内容类型。
Accept-Language：指定客户端接受的语言类型。
Accept-Encoding：指定客户端接受的内容编码方式。
Connection：指定是否保持连接或关闭连接。
Content-Type：指定请求体的MIME类型，用于POST请求。
Content-Length：指定请求体的长度。
Referer：指定请求的来源页面URL。
Cookie：包含客户端的Cookie信息。
Authorization：包含客户端的身份验证信息。

除了上述常见的请求报头外，还可以根据实际需求添加其他自定义的请求报头。请求报头提供了关于请求的各种信息，帮助服务器理解客户端的请求并作出相应的处理

3.3.3 认识请求正文

HTTP请求正文是HTTP请求中可选的部分，用于向服务器传递数据。请求正文通常出现在POST、PUT等需要向服务器提交数据的请求中。请求正文的内容格式取决于Content-Type请求头中指定的MIME类型。

Content-Type=application/x-www-form-urlencoded

tz=Asia%2FShanghai;

Hm_lvt_24f17767262929947cc3631f99bfd274=1622637014

gitee_user=true;

Hm_lpvt_24f17767262929947cc3631f99bfd274=1623298560;

在 application/x-www-form-urlencoded 编码中，数据会以键值对的形式使用 key1=value1 的格式进行编码，并使用 & 符号来分隔不同的键值对。

3.4 HTTP响应

状态码

总结

响应报头

响应报头的基本格式和请求报头的格式基本一致. 类似于 Content-Type , Content-Length 等属性的含义也和请求中的含义一致.

响应中的 Content-Type 常见取值有以下几种:

text/html : body 数据格式是 HTML
text/css : body 数据格式是 CSS
application/javascript : body 数据格式是 JavaScript
application/json : body 数据格式是 JSON

4. HTTPS

HTTPS 也是一个应用层协议. 是在 HTTP 协议的基础上引入了一个加密层. HTTP 协议内容都是按照文本的方式明文传输的. 这就导致在传输过程中出现一些被篡改的情况

在互联网上, 明文传输是比较危险的事情!!!

加密

加密就是把明文 (要传输的信息)进行一系列变换, 生成密文 .

解密就是把密文再进行一系列变换, 还原成明文 .

在这个加密和解密的过程中, 往往需要一个或者多个中间的数据, 辅助进行这个过程, 这样的数据称为密钥

HTTPS的工作过程

既然要保证数据安全, 就需要进行 "加密".

网络传输中不再直接传输明文了, 而是加密之后的 "密文".

加密的方式有很多, 但是整体可以分成两大类: 对称加密和非对称加密

对称加密

加密和解密使用的密钥是同一把就是对称加密

引入对称加密之后, 即使数据被截获, 由于黑客不知道密钥是啥, 因此就无法进行解密, 也就不知道请求的真实内容是啥了.

但是每一人使用的密钥不能是同一把, 因为如果是同一把的话, 那么黑客想要得到这把密钥就简单很多了! 这就导致了一个问题,那就是服务器管理和维护每个客户端和每把秘钥之间的对应关系是一件很麻烦的事

比较理想的做法就是在建立连接的时候协商出一个秘钥

但是如果直接把密钥明文传输, 那么黑客也就能获得密钥了~~ 此时后续的加密操作就形同虚设了.因此密钥的传输也必须加密传输!

到这里对称加密已经解决不了问题了, 陷入了一个循环中

非对称加密

非对称加密要用到两个密钥, 一个叫做 "公钥", 一个叫做 "私钥"

客户端在本地生成对称密钥, 通过公钥加密, 发送给服务器。
由于中间的网络设备没有私钥, 即使截获了数据, 也无法还原出内部的原文, 也就无法获取到对称密钥。
服务器通过私钥解密, 还原出客户端发送的对称密钥。并且使用这个对称密钥加密给客户端返回的响应数据。
后续客户端和服务器的通信都只用对称加密即可。由于该密钥只有客户端和服务器两个主机知道, 其他主机/设备不知道密钥即使截获数据也没有意义。

那么问题又来了, 客户端如何获取公钥, 客户端如何确定这个公钥是不是非法的?

证书

在客户端和服务器刚一建立连接的时候, 服务器给客户端返回一个证书. 这个证书包含了刚才的公钥, 也包含了网站的身份信息。

当客户端获取到这个证书之后, 会对证书进行校验(防止证书是伪造的)。

判定证书的有效期是否过期
判定证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构).
验证证书是否被篡改: 从系统中拿到该证书发布机构的公钥, 对签名解密, 得到一个 hash 值(称为签名), 设为 hash1. 然后计算整个证书的 hash 值, 设为 hash2. 对比 hash1 和 hash2 是否相等. 如果相等, 则说明证书是没有被篡改过的

不同的数据, 生成的 "签名" 差别很大. 这样使用这样的签名就可以一定程度的区分不同的数据. 常见的生成签名的算法有: MD5 和 SHA 系列。即使只动了证书中的一点数据, 那么两次得到的hash值就绝对不会相同, 因此, 证书是否是非法的可以很简单的被识别出来!!