1. HTTP
Http协议属于应用层,即用户访问的第一层就是http
1.1 http报文
http的请求报文
- HTTP请求体是我们请求数据时先发送给服务器的数据,毕竟我向服务器那数据,先要表明我要什么吧
- HTTP请求体由:
请求行
、请求头
、请求数据
组成的, - 注意:GET请求是没有请求体的
post
get
http的响应报文
响应报文包含三部分 状态行
、响应首部字段
、响应内容实体
实现
1.2 HTTP有哪些方法?
- HTTP1.0定义了三种请求方法: GET, POST 和 HEAD方法
- HTTP1.1新增了五种请求方法:OPTIONS, PUT, DELETE, TRACE 和 CONNECT
这些方法的具体作用是什么?
- GET: 通常用于请求服务器发送某些资源
- HEAD: 请求资源的头部信息, 并且这些头部与 HTTP GET 方法请求时返回的一致. 该请求方法的一个使用场景是在下载一个大文件前先获取其大小再决定是否要下载, 以此可以节约带宽资源
- OPTIONS: 用于获取目的资源所支持的通信选项
- POST: 发送数据给服务器
- PUT: 用于新增资源或者使用请求中的有效负载替换目标资源的表现形式
- DELETE: 用于删除指定的资源
- PATCH: 用于对资源进行部分修改
- CONNECT: HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器
- TRACE: 回显服务器收到的请求,主要用于测试或诊断
GET和POST有什么区别?
- 数据传输方式不同:GET请求通过URL传输数据,而POST的数据通过请求体传输。
- 安全性不同:POST的数据因为在请求主体内,所以有一定的安全性保证,而GET的数据在URL中,通过历史记录,缓存很容易查到数据信息。
- 数据类型不同:GET只允许 ASCII 字符,而POST无限制
- GET无害: 刷新、后退等浏览器操作GET请求是无害的,POST可能重复提交表单
- 特性不同:GET是安全(这里的安全是指只读特性,就是使用这个方法不会引起服务器状态变化)且幂等(幂等的概念是指同一个请求方法执行多次和仅执行一次的效果完全相同),而POST是非安全非幂等
GET
请求会被浏览器主动缓存,而POST
不会,除非手动设置GET
请求参数会被安逗保留在浏览器历史记录里,而POST
中的参数不会被保留GET
产生一个TCP数据包,POST
产生两个数据包(Firefox只发一次)。GET浏览器把 http header和data一起发出去,响应成功200,POST先发送header,响应100 continue,再发送data,响应成功200
PUT和POST都是给服务器发送新增资源,有什么区别?
PUT 和POST方法的区别是,PUT方法是幂等的:连续调用一次或者多次的效果相同(无副作用),而POST方法是非幂等的。
除此之外还有一个区别,通常情况下,PUT的URI指向是具体单一资源,而POST可以指向资源集合。
举个例子,我们在开发一个博客系统,当我们要创建一篇文章的时候往往用POST https://www.jianshu.com/articles
,这个请求的语义是,在articles的资源集合下创建一篇新的文章,如果我们多次提交这个请求会创建多个文章,这是非幂等的。
而PUT https://www.jianshu.com/articles/820357430
的语义是更新对应文章下的资源(比如修改作者名称等),这个URI指向的就是单一资源,而且是幂等的,比如你把『刘德华』修改成『蔡徐坤』,提交多少次都是修改成『蔡徐坤』
PUT和PATCH都是给服务器发送修改资源,有什么区别?
PUT和PATCH都是更新资源,而PATCH用来对已知资源进行局部更新。
1.3 HTTP的状态码
2XX 成功
- 200 OK,表示从客户端发来的请求在服务器端被正确处理 ✨
- 201 Created 请求已经被实现,而且有一个新的资源已经依据请求的需要而建立
- 202 Accepted 请求已接受,但是还没执行,不保证完成请求
- 204 No content,表示请求成功,但响应报文不含实体的主体部分
- 206 Partial Content,进行范围请求 ✨
3XX 重定向
- 301 moved permanently,永久性重定向,表示资源已被分配了新的 URL
- 302 found,临时性重定向,表示资源临时被分配了新的 URL ✨
- 303 see other,表示资源存在着另一个 URL,应使用 GET 方法丁香获取资源
- 304 not modified,表示服务器允许访问资源,但因发生请求未满足条件的情况
- 307 temporary redirect,临时重定向,和302含义相同
4XX 客户端错误
- 400 bad request,请求报文存在语法错误 ✨
- 401 unauthorized,表示发送的请求需要有通过 HTTP 认证的认证信息 ✨
- 403 forbidden,表示对请求资源的访问被服务器拒绝 ✨
- 404 not found,表示在服务器上没有找到请求的资源 ✨
- 408 Request timeout, 客户端请求超时
- 409 Confict, 请求的资源可能引起冲突
5XX 服务器错误
- 500 internal sever error,表示服务器端在执行请求时发生了错误 ✨
- 501 Not Implemented 请求超出服务器能力范围,例如服务器不支持当前请求所需要的某个功能,或者请求是服务器不支持的某个方法
- 503 service unavailable,表明服务器暂时处于超负载或正在停机维护,无法处理请求
- 505 http version not supported 服务器不支持,或者拒绝支持在请求中使用的 HTTP 版本
1.4 HTTP缓存
HTTP缓存主要是数据保存在客户端
,也就是浏览器或其他客户端应用程序中。当客户端首次请求服务器的资源时,服务器会将资源的副本
传送到客户端,并附带一些缓存控制信息,比如过期时间、验证标识等。客户端会根据这些信息来决定是否在未来的请求中重用这些缓存的资源,从而减少对服务器的请求。
1.4.1 强缓存
强缓存两个相关字段,「Expires」,「Cache-Control」。
「强缓存分为两种情况,一种是发送HTTP请求,一种不需要发送。」
首先检查强缓存,这个阶段**不需要发送HTTP请求。**通过查找不同的字段来进行,不同的HTTP版本所以不同。
- HTTP1.0版本,使用的是Expires,HTTP1.1使用的是Cache-Control
Expires
Expires
即过期时间,时间是相对于服务器的时间而言的,存在于服务端返回的响应头中,在这个过期时间之前可以直接从缓存里面获取数据,无需再次请求。比如下面这样:
复制代码
Expires:Mon, 29 Jun 2020 11:10:23 GMT
表示该资源在2020年7月29日11:10:23
过期,过期时就会重新向服务器发起请求。
这个方式有一个问题:「服务器的时间和浏览器的时间可能并不一致」,所以HTTP1.1提出新的字段代替它。
Cache-Control
HTTP1.1版本中,使用的就是该字段,这个字段采用的时间是过期时长,对应的是max-age。
复制代码
Cache-Control:max-age=6000
上面代表该资源返回后6000秒,可以直接使用缓存。
当然了,它还有其他很多关键的指令,梳理了几个重要的👇
注意点:
- 当Expires和Cache-Control同时存在时,优先考虑Cache-Control。
- 当然了,当缓存资源失效了,也就是没有命中强缓存,接下来就进入协商缓存👇
1.4.2 协商缓存
当服务器响应中设置了Cache-Control: no-cache
或 Cache-Control: must-revalidate
等指令,它表明客户端在每次需要使用缓存时都需要与服务器进行验证。这被称为协商缓存,因为客户端在使用缓存之前需要与服务器协商,验证缓存是否仍然有效。
另外,Cache-Control
还配合其他头部字段,如ETag
和Last-Modified
来实现协商缓存:
强缓存失效后,浏览器在请求头中携带响应的缓存Tag
来向服务器发送请求,服务器根据对应的tag,来决定是否使用缓存。
缓存分为两种,「Last-Modified」 和 「ETag」。两者各有优势,并不存在谁对谁有绝对的优势
,与上面所讲的强缓存两个Tag所不同。
Last-Modified
这个字段表示的是**「最后修改时间」**。在浏览器第一次给服务器发送请求后,服务器会在响应头中加上这个字段。
浏览器接收到后,「如果再次请求」,会在请求头中携带If-Modified-Since
字段,这个字段的值也就是服务器传来的最后修改时间。
服务器拿到请求头中的If-Modified-Since
的字段后,其实会和这个服务器中该资源的最后修改时间
对比:
- 如果请求头中的这个值小于最后修改时间,说明是时候更新了。返回新的资源,跟常规的HTTP请求响应的流程一样。
- 否则返回304,告诉浏览器直接使用缓存。
ETag
ETag是服务器根据当前文件的内容,对文件生成唯一的标识,比如MD5算法,只要里面的内容有改动,这个值就会修改,服务器通过把响应头把该字段给浏览器。
浏览器接受到ETag值,会在下次请求的时候,将这个值作为**「If-None-Match」**这个字段的内容,发给服务器。
服务器接收到**「If-None-Match」后,会跟服务器上该资源的「ETag」**进行比对👇
- 如果两者一样的话,直接返回304,告诉浏览器直接使用缓存
- 如果不一样的话,说明内容更新了,返回新的资源,跟常规的HTTP请求响应的流程一样
两者对比
-
性能上,
Last-Modified
优于ETag
,Last-Modified
记录的是时间点,而Etag
需要根据文件的MD5算法生成对应的hash值。 -
精度上,
ETag
优于Last-Modified
。ETag
按照内容给资源带上标识,能准确感知资源变化,Last-Modified
在某些场景并不能准确感知变化,比如👇- 编辑了资源文件,但是文件内容并没有更改,这样也会造成缓存失效。
- Last-Modified 能够感知的单位时间是秒,如果文件在 1 秒内改变了多次,那么这时候的 Last-Modified 并没有体现出修改了。
1.5 长连接
http1.0
协议采用的是"请求-应答"模式,当使用普通模式,每个请求/应答客户与服务器都要新建一个连接,完成之后立即断开连接(http
协议为无连接
的协议)
http1.1
版本支持长连接,即请求头添加Connection: Keep-Alive
,使用Keep-Alive模式(又称持久连接,连接复用)建立一个TCP
连接后使客户端到服务端的连接持续有效,可以发送/接受多个http
请求/响应,当出现对服务器的后续请求时,Keep-Alive功能避免了建立或者重新建立连接
长连接优缺点
优点
减少CPU及内存的使用
,因为不需要经常建立和关闭连接支持管道化
的请求及响应模式减少网络堵塞
,因为减少了TCP请求减少了后续请求的响应时间
,因为不需要等待建立TCP、握手、挥手、关闭TCP的过程- 发生错误时,也
可在不关闭连接的情况下进行错误提示
缺点
一个长连接建立后,如果一直保持连接,对服务器来说是多么的浪费资源呀,而且长连接时间的长短,直接影响到服务器的并发数
还有就是可能造成队头堵塞
(下面有讲),造成信息延迟
作者:沐华
链接:juejin.cn/post/699462…
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
队头阻塞
HTTP/1.1
中的队头阻塞(Head-of-Line Blocking)是指在一个持久连接
(Keep-Alive Connection)中,如果某个请求的响应在服务器端还未准备好
,那么后续的请求响应也会被阻塞
,直到前面的响应完成。这可能会导致性能下降,影响用户体验。
队头阻塞的情况可能发生在以下场景:
- 串行处理: 在一个
持久连接
中,HTTP/1.1 默认是按照请求的顺序进行处理的。如果某个请求的处理时间较长
,即使后面的请求已经准备好了,也要等待前面的请求响应完成,导致后续请求被阻塞。 - 并行连接限制: 虽然HTTP/1.1 支持持久连接,但同时打开的连接数量仍然受到限制。
浏览器通常对同一个域名的并行连接数量
有限制,如果某个请求的响应还未完成,可能会占用一个连接,导致其他请求等待。
这种队头阻塞的问题在网页加载时尤其显著,因为一个网页通常包含多个资源(如图片、样式表、脚本等)的请求。如果其中一个资源的请求响应较慢,会阻塞其他资源的加载,从而影响整体的加载速度。
为了解决HTTP队头阻塞问题,一些方法可以考虑:
-
并发连接: 因为一个域名允许分配多个长连接,就相当于增加了任务队列,不至于一个队列里的任务阻塞了其他全部任务。现在的浏览器标准中一个域名
并发连接
可以有6~8
个,记住是6~8个,不是6个(Chrome6个/Firefox8个) -
资源合并: 将多个小的资源合并为一个大的资源,减少请求的数量,从而降低队头阻塞的可能性。
-
域名分片: 通过将
一个域名下的资源拆分到不同的子域名
下,利用浏览器对不同域名的并行连接限制,来减少队头阻塞。举个例子,比如
TianTian.com
,可以分出很多二级域名,比如Day1.TianTian.com
,Day2.TianTian.com
,Day3.TianTian.com
,这样子就可以有效解决队头阻塞问题。 -
使用HTTP/2: HTTP/2 使用
多路复用
技术,可以在一个连接上并行传输多个请求和响应,减少队头阻塞的影响。
HTTPS
那么区别有哪些呢👇
- HTTP 是明文传输协议,HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议,比 HTTP 协议安全。
- HTTPS比HTTP更加安全,对搜索引擎更友好,利于SEO,谷歌、百度优先索引HTTPS网页。
- HTTPS标准端口443,HTTP标准端口80。
- HTTPS需要用到SSL证书,而HTTP不用。
我觉得记住以下两点HTTPS主要作用就行👇
-
对数据进行加密,并建立一个信息安全通道,来保证传输过程中的数据安全;
-
对网站服务器进行真实身份认证。
作者:TianTianUp
链接:juejin.cn/post/685728…
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
作者:沐华
链接:juejin.cn/post/699462…
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
作者:寻找海蓝96
链接:juejin.cn/post/684490…
来源:稀土掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。