这篇文章,主要是对 HTTP 的基本概念、各个请求方法的作用、 get 方法和 post 方法的区别、 HTTP请求报文和响应报文、HTTP 1.x 的 keep-alive的作用、HTTPS为什么安全、常见加密算法、强制缓存协商缓存以及 Tcp 的三次握手和四次挥手做个简单的概述
主要是自我记录总结,话不多说,开整 🐼
温馨提示:
涉及不深、凑合着看- 因为没有画图,可能会有点抽象
文章内有引用过其他人的文档
1. Http基本概念
http 基本概念:
HTTP (HyperText Transfer Protocal === 超文本传输协议)
作用:用于在网络中传输数据
特点:基于 Tcp 的明文协议,意味着不安全(https 可以解决安全问题)
各个HTTP方法的具体作用是什么?
HTTP 1.0 标准中 ,定义了三种请求方法:GET、POST、HEAD
HTTP 1.1 标准中, 新增了请求的方法:PUT、PATCH、DELETE、OPTIONS、TRACE、CONNECT
GET: 通常用于请求服务器发送某些资源回来
POST:发送数据给服务器(新增)
HEAD:服务器中可能有一些非重大的资源,HEAD的一个使用场景是在下载一个大文件前先获取其大小再决定是否需要下载
PUT : 用于全量修改目标资源(看接口,也可以用于添加)
PATCH : 用于对资源进行部分修改
DELETE : 用于删除指定的资源
OPTIOS : 用于在每一次请求之前发送一次 OPTIONS 请求,看目标是否允许跨域,判断目标是否安全,如果允许跨域再去发下一次请求,这个操作是浏览器自动执行的
TRACE:用于让服务器原样返回任意客户端请求的信息内容
CONNECT : 连接方式改为管道方式的代理服务器(代理服务器:把服务器作为跳板,让服务器代替用户去访问其它网页,之后把数据原原本本的返回给用户)
GET / DELETE --- 参数是在地址栏中传递的
PUT / PATCH / POST --- 参数是在请求中传递的
2. get 方法和 post 方法的区别
两者都是 http 的请求方式,get 通常是用于向服务器发送请求,获取某些数据回来,pust 通常是发送数据给服务器,也可以用于新增。这两者的不同点,我觉得一个有五个:
- 首先是从数据传输方式来讲:get 方法时通过 URL 传输参数(也就是通过地址栏拼接参数);而 post 是通过请求体传输。
- 从数据传输安全来讲:GET 请求的数据暴露在 URL 中,可以通过浏览器历史记录、缓存等很容易查到数据信息,而 POST 方法因为数据在请求主体内,所以 POST 有一定的安全保障性 ,保证我们的数据安全
- 从数据类型上看:get 请求只允许 ASCII 字符,而 POST 请求是无限制的 ,也就是说 POST 请求也可以做文件上传等多种操作
- 从性能方面来看:GET 请求是无害的,刷新,后退等浏览器操作是无害的,而 POST 可能会引起重复提交表单
- 从功能特性层面上讲:传统意义上来讲 post 携带数据更安全,但是从协议本身而言,从另一个角度出发,认为 POST 是不安全的。因为我们从它的功能特性出发: GET 是安全且幂等的,POST 是非幂等的。这里的安全是指只读性,也就是是否会引起服务器修改数据,从 GET 的请求方式来看,它是向服务器发送请求,获取某些数据回来,也是间接的说明 GET 是拥有安全只读的,就是说这个方法不会引起服务器的变化;幂等的概念就是指同一个请求方法执行多次和仅执行一次的效果是完全一样的,通俗来讲就是我发多次请求,用来查询数据,尽管里面的内容不相同,但是效果是完全一样的并且服务器没有做任何修改;而 POST 是完全相反的,它是非安全,非幂等的。从它的请求方式来看,他是用于向服务器新增数据,也就是说会引起服务器的数据发生变化。使用 POST 多次发送请求之后,服务器每次接收到的结果都不一样。
3. HTTP 请求报文和响应报文
HTTP 请求报文的组成:请求行、请求头、{空行}、请求体
请求行:包含了请求方法、url、HTTP 协议版本,他们之间用空格进行分隔
请求头:里面的数据是抓包抓过来的,请求头由键值对组成,每行一对,键值之间用英文冒号: 进行分隔
空行:介于请求头和请求体之间
请求体:请求体中放置 POST 、PUT、PATCH 等请求方法所需要携带的数据
HTTP 响应报文的组成:响应行、响应头、响应空行、响应体
响应行:里面包含了 协议版本、状态码、状态码的原因短语三个内容组成,中间用空格分隔
响应头:响应头由键值对组成,每行一对,键值之间用英文冒号:进行分隔
空行:介于响应头和响应体之间
响应体:服务器发送回来的数据
4. HTTP 1.x 的 keep-alive 是什么作用?
作用:使客户端到服务端的连接持续有效(长连接),当出现对服务器的后续请求时,keep-alive 功能避免了建立或者重新建立连接
http1.0 默认关闭,需要手动开启,而 http1.1 后默认开启
背景:早期 http1.0 的时候需要创建新连接,而创建连接的过程需要消耗资源和时间,为了减少资源消耗、缩短响应时间,就需要复用已有连接
原理:在后来的 HTTP/1.0 以及 HTTP/1.1 中引⼊了复⽤连接的机制,也就是在请求头中加⼊Connection: keep-alive,以此告诉对⽅这个请求响应完成后不要关闭连接,下⼀次还⽤这个请求的连接进行后续交流。协议规定,如果想要保持连接,则需要在请求头中加上 Connection: keep-alive。
优点:较少的 CPU 和内存的占⽤(因为要打开的连接数变少了, 复用了连接) ;减少了后续请求的延迟(⽆需再进⾏握⼿)
缺点:因为在处理的暂停期间,本来可以释放的资源仍旧被占用。请求已经都结束了, 但是还一直连接着也不合适
解决(优化):栗子:Keep-Alive: timeout=5, max=100;
timeout:过期时间5秒(对应httpd.conf里的参数是:KeepAliveTimeout),
max是最多一百次请求,强制断掉连接。就是在timeout时间内又有新的连接过来,同时max会自动减1,直到为0,强制断掉。
5. HTTPS 基本概念
HTTP协议是网络通信的基石, 基于HTTP协议, 完成了很多的网页应用功能, 但是HTTP协议是明文传输数据的 HTTPS 是安全版的 HTTP。HTTP 协议在传输数据时采用的是明⽂方式传递,因此,⼀些敏感信息的传输就变得很不安全。而 HTTPS 就是为了解决 HTTP 的不安全⽽产⽣的。
6. HTTPS 是如何保证安全的
从算法方面提高安全性
HTTPS 在传输数据的过程中会对数据进行加密处理,保证安全性。
目前常见的加密算法分为两类:对称加密算法,非对称加密算法 。还有一类算法一般不用于加密,但普遍用于签名:Hash算法(散列算法)
1.对称加密算法
相同密钥加密解密, 可逆的! 可以用于加密解密传输数据,想使用对称加密算法, 一定要保证密钥不被泄漏 。
展开来讲:对称加密的特点是文件加密和解密使用相同的密钥,即加密密钥也可以用作解密密钥,这种方法在密码学中叫做对称加密算法,对称加密算法使用起来简单快捷,密钥较短,且破译困难。
通信的双⽅都使⽤同⼀个秘钥进⾏加密, 解密。
优点:计算量小、加密速度快、加密效率高
缺点:在数据传送前,发送方和接收方必须商定好秘钥,然后双方保存好秘钥。
如果一方的秘钥被泄露,那么加密信息也就不安全了
使用场景:本地数据加密、https通信、网络传输等
2.非对称加密算法
加密和解密其实可以使用不同的规则,只要这两种规则之间存在某种对应关系即可,这样就避免了直接传递之前的相同的密钥。这种新的加密模式被称为"非对称加密算法"。通信的双方使用不同的秘钥进行加密解密,即秘钥对(私钥 + 公钥)。特征: 私钥可以解密公钥加密的内容, 公钥可以解密私钥加密的内容。
优点:非对称加密与对称加密相比其安全性更好
缺点:加密和解密花费时间长、速度慢,只适合对少量数据进行加密。
使用场景:https会话前期、CA数字证书、登录认证等
3.HTTPS 加密解决方案
结合了对称加密算法和非对称加密算法
HTTPS 目前所使用的 TLS或SSL协议, 就是目前采用的加密通道的规范协议 ,它利用对称加密、(公私钥)非对称加密, 以及其密钥交换算法,可完成可信任的信息传输
利用 非对称加密 加密传输 对称加密所约定的密钥 (保证了密钥传输的安全)
后续, 利用对称加密, 有效便捷的进行数据传输
从数字证书方面提高安全性
为了安全性进一步加强,一般还需要签发数字证书,客户端 和 服务器端要初步互通消息时, 客户端发送请求可以拿到公开的公钥信息,假设一个场景:初步互通消息时, 如果请求拿到的公钥信息, 就是假的, 或者不安全的! 那么后续的所有操作, 都将是不安全的,所以为了证实公钥的安全可靠性,需要有数字证书,一般是CA机构颁发的
CA证书中心会对你网站的公钥, 网站的域名地址, 证书到期时间, 等一些相关信息一起加密签发数字证书, 保证你网站的安全性
在以后,访问网站时,当公司申请了 CA 证书后, 就应该在响应时, 将数字证书一起发送给客户端,而客户端, 接收到消息后, 就可以查看证书。如果正在访问的网站 和证书记载的网址不一致, 说明不安全, 可能被冒用, 浏览器就会发出警告,如果签发证书的机构, 不够权威, 也会发出警告, 如果证书过期了, 浏览器也会发出警告,CA机构,也不会再继续实时检测网站的安全有效性。
从数字签名方便提高安全性
为了防止证书被篡改,需要用到一个新技术:数字签名(根据证书内容,生成一个唯一的标识)
数字签名就是先⽤ CA ⾃带的 Hash 算法来计算出证书内容的⼀个摘要,然后使⽤ CA 私钥进行加密,组成数字签名。
当别⼈把他的证书发过来时,接收方⽤同样的算法再次⽣成摘要,⽤ CA 公钥解密后得到CA生成的摘要,两者进行对⽐后,
就能确定中间是否被⼈篡改。这样就能最⼤程度的保证通信的安全了。
7. HTTP2 和 HTTP1.x 比,有什么优势和特点?
HTTP1.X 同一时间, 只能并发建立 6-8 个 TCP 连接, 一个连接同时只能一个请求 (虽然可以 keep-alive复用, 但也得一个个来)
(建立连接的成本比较高, 不让一次性建立太多连接)
而新版本 HTTP/2 建立一次连接, 就可以并发很多个请求,大大提升了页面加载的效率
HTTP/2 的升级, 对于用户来说, 是跨时代的! 基于HTTP/2, 用户访问网页的速度会非常快(充分利用带宽)
HTTP/2: 淘宝, 天猫, 京东等, 已做升级 ....
- HTTP/2 采⽤⼆进制格式来传输数据,⽽⾮ HTTP 1.x 的⽂本格式,⼆进制协议解析起来更⾼效
- HTTP/2 采用一些头部压缩技术,减少在请求和响应头中重复携带的数据,降低网络负担
- HTTP/2 采⽤服务器推送方式,主动向客户端推送资源,提高页面加载效率
- HTTP/2 采⽤多路复用机制,减少需要创建的连接数量,降低资源占用和性能消耗
8. http 缓存控制
基本概念
Web 服务缓存 大致可以分为:数据库缓存、服务器端缓存(代理服务器缓存、CDN 服务器缓存)、浏览器缓存。
浏览器缓存 也包含很多内容: HTTP 缓存、indexDB、cookie、localstorage 等等。
HTTP缓存: (优化页面加载的效率, 如果没有缓存策略, 每次重新加载页面, 会非常慢!) 强缓存和协商缓存
http 缓存控制流程
浏览器缓存分为强缓存和 协商缓存,浏览器加载一个页面的简单流程如下:
-
浏览器先根据这个资源的 http头信息 来 判断是否命中强缓存。
如果命中则直接加载在缓存中的资源,并不会将请求发送到服务器。(强缓存)
-
如果未命中强缓存,则浏览器会将资源加载请求发送到服务器。
服务器来判断浏览器本地缓存是否失效。
若可以使用,则服务器并不会返回资源信息,浏览器继续从缓存加载资源。(协商缓存)
-
如果未命中协商缓存,则服务器会将完整的资源返回给浏览器,浏览器加载新资源,并更新缓存。(新的请求)
强缓存
向服务器发送一个请求,在浏览器的调试工具 Network 中查看时,有些数据是没有大小的,都是从缓存中读取的。也就是说,命中强缓存时,浏览器并不会将请求发送给服务器。在Chrome的开发者工具中看到http的返回码是200,但是在Size列会显示为(from cache)。
原理:强缓存是利用http的返回的响应头中的Expires或者Cache-Control (优先级更高) 两个字段来控制的,用来表示资源的缓存时间。
控制台打印:
new Date(‘Expires属性后面的时间’).toLocaleString() // 可查看具体时间
Expires:缓存过期时间,用来指定资源到期的时间,是服务器端的具体的时间点。Expires是Web服务器响应消息头字段,在响应http请求时告诉浏览器在过期时间前浏览器可以直接从浏览器缓存取数据,而无需再次请求。
假设一个场景:客户端在国内,服务器在国外,这样就会导致服务器和客户端的时间偏差很大(并且客户端时间会被修改的),就会导致缓存混乱。所以 Expires 有个很大的缺点,采用的失效时间是一个绝对时间**于是发展出了另一个缓存的属性 Cache-Control
Cache-Control:是一个相对时间,由于是相对时间,并且都是与客户端时间比较,所以服务器与客户端时间偏差也不会导致问题。
Cache-Control与Expires可以在服务端配置同时启用或者启用任意一个,同时启用的时候Cache-Control优先级高。
Cache-Control 可以由多个字段组合而成,主要有以下几个取值:
- max-age 指定一个时间长度,在这个时间段内缓存是有效的,单位是s。
- no-cache 强制所有缓存了该响应的用户,在使用已缓存的数据前,发送带验证的请求到服务器, 问服务器是否可以读缓存。
- no-store 禁止缓存,每次请求都要向服务器重新获取数据。
如果命中强缓存,在有效期内使用了本地浏览器的缓存,请求资源是不会像服务器发送请求的,同时也可以减轻服务器压力
协商缓存(强缓存未命中)
大白话就是 :强缓存服务器会给你个东西,告诉什么时候过期,在有效期内都可以随便去使用。如果过了有效期,就要去重新去发请求,但是有些资源又没有必要去重新发请求。协商缓存就是如果过了有效期,还要继续使用,就会延长时间,而且也不会去重新发起请求。协商缓存是对强缓存的一个调度,或者说是一个补充
若未命中强缓存(强缓存过期了),则浏览器会将请求发送至服务器。
原理:服务器根据http头信息中的Last-Modify/If-Modify-Since或Etag/If-None-Match来判断是否命中协商缓存。如果命中,则http返回码为304 (你本地之前加载的资源是有效的),浏览器从缓存中加载资源。
展开:
Last-Modify/If-Modify-Since:
浏览器第一次请求一个资源的时候, 服务器返回的header中会加上Last-Modify,Last-modify是一个时间标识该资源的最后修改时间
当浏览器再次请求该资源时(进行协商请求时),发送的请求头中会包含If-Modify-Since,该值为缓存之前返回的Last-Modify。服务器收到If-Modify-Since后,根据实际服务器的资源的最后修改时间, 进行判断是否命中缓存。
由于对比的是服务端的修改时间,所有就算客户端于服务端时间有差距,也不会有问题,但是有时候通过最后修改时间来判断资源是否修改还是不太准确。比如一个场景:最后一次修改,只能精确到秒级,一秒进行了多次修改就不行了,所以此时需要Etag/If-None-Match来处理
Etag/If-None-Match(实体标识):
与Last-Modify/If-Modify-Since (最后修改时间)不同的是,Etag/If-None-Match返回的是一个校验码(ETag: entity tag)。
作用:可以保证每一个资源是唯一的,资源变化都会导致ETag变化。ETag值的变更则说明资源状态已经被修改。服务器根据浏览器上发送的If-None-Match值来判断是否命中缓存。
ETag生成靠以下几种因子:文件的i-node编号,是Linux/Unix用来识别文件的编号;文件最后修改时间;文件大小等,生成Etag的时候,可以使用其中一种或几种因子,使用抗碰撞散列函数来生成。生成一个标记文件的唯一值
Etag的出现主要是为了解决几个Last-Modified比较难解决的问题:
-
Last-Modified标注的最后修改只能精确到秒级
如果某些文件在1秒钟以内,被修改多次的话,它将不能准确标注文件的修改时间
-
有可能存在服务器没有准确获取文件修改时间,或者与代理服务器时间不一致等情形
Etag 的优势:Etag是服务器自动生成或者由开发者生成的对应资源在服务器端的唯一标识符,能够更加 准确的控制缓存,所以尽管Last-Modified已经足以让浏览器知道本地的缓存副本是否足够新,所以还是需要Etag(实体标识)。Last-Modified与ETag是可以一起使用的,服务器会优先验证ETag,一致的情况下,才会继续比对Last-Modified,最后才决定是否返回304
小结:
强缓存 :检查过期时间, 判断缓存是否失效, 如果不失效, 直接用, 不发请求 大大的减少了 服务器的请求次数, 在过期时间内, 直接从客户端内存中读
协商缓存: 强缓存命中失效了, 超过过期时间了, 拿着标识(最后的修改时间, 唯一标识etag), 去问服务器, 是否真的过期了,如果验证通过, 服务器会直接响应 304, 且不会返回资源
不太使用资源,例如图片,是非常适合应用强缓存的,过期的时间也可以设置很长;另外,如果是一些很可能会变的资源, 也希望能缓存 ,过期时间设置短一些, 一旦过期, 使用协商缓存。不过更好的选择是二者搭配来使用。
9. Tcp 协议,以及三次握手,四次挥手
TCP(Transmission Control Protocol 传输控制协议) 是一种面向连接(连接导向) 的、可靠的、 基于IP的传输层协议。
TCP 使⽤校验、确认和重传机制来保证可靠传输
而 HTTP协议 就是建立在 TCP / IP 协议 之上的一种应用。
Tcp三次招手,四次握手:
三次握手:确定是否可以建立连接,双方都需要确认。第一次握手,客户端会问服务器在不在,我要发送建立连接的请求了;第二次握手服务器会应答说我在,可以建立连接,并会反问客户端你在不在;第三次握手,客户端就会回应说我在。是一个双方确认连接的过程
四次挥手:是关闭连接,为了安全准确的关闭服务器,避免资源浪费防止数据丢失,保证资源的完整性。第一次挥手:首先是客户端的页面加载完毕,要求停止传输,请求断开连接;第二次挥手:服务器同意,但是服务器需要检查一下数据是否传输完毕;第三次挥手:服务器已经检查完毕,发现数据已经全部传输完成,通知客服端断开连接;第四次挥手:客户端收到断开连接的消息,也会关闭自己的连接。是客服端服务器双方断开连接的过程
一次完整的 HTTP 服务过程
- 浏览器查找域名对应的IP地址(DNS 查询:浏览器缓存->系统缓存->路由器缓存->ISP DNS 缓存->根域名服务器)
- 根据这个IP,找到对应的服务器,发起TCP的三次握手
- 建立TCP连接后, 发起HTTP请求
- 服务器 301 重定向
- 浏览器跟踪重定向地址,请求另一个带 www 的网址
- 服务器返回一个 HTTP 响应
- 浏览器进 DOM 树构建
- 服务器响应HTTP请求,浏览器得到html代码
- 浏览器发送请求获取嵌在 HTML 中的资源(如图片、音频、视频、CSS、JS等)
- 浏览器对页面进行渲染呈现给用户,浏览器完成显示完成页面
- 服务过程完毕, 关闭TCP连接, 四次挥手