21天筑基期--HTTP系列
什么是HTTP?
HTTP
(HyperText Transfer Protocol),即超文本运输协议,是实现网络通信的一种规范
HTTP 和 HTTPS 的区别?
- HTTPS是HTTP协议的安全版本,HTTP协议的数据传输是明文的,是不安全的,HTTPS使用了SSL/TLS协议进行了加密处理,相对更安全
- HTTP 和 HTTPS 使用连接方式不同,默认端口也不一样,HTTP是80,HTTPS是443
- HTTPS 由于需要设计加密以及多次握手,性能方面不如 HTTP
- HTTPS需要SSL,SSL 证书需要钱,功能越强大的证书费用越高
HTTP 缓存有哪些方案?
缓存(强缓存) | 内容协商(弱缓存) | |
---|---|---|
HTTP 1.1 | Cache-Control: max-age=3600 Etag: ABC | If-None-Match: ABC 响应状态码:304 或 200 |
HTTP 1.0 | Expires: Wed, 21 Oct 2015 02:30:00 GMT Last-Modified: Wed, 21 Oct 2015 01:00:00 GMT | If-Modified-Since: Wed, 21 Oct 2015 01:00:00 GMT 响应状态码:304 或 200 |
说一下 GET 和 POST
GET
和POST
,两者是HTTP
协议中发送请求的方法
GET
GET
方法请求一个指定资源的表示形式,使用GET的请求应该只被用于获取数据
POST
POST
方法用于将实体提交到指定的资源,通常导致在服务器上的状态变化或副作用
本质上都是TCP
链接,并无差别
区别
-
数据传输方式不同:GET请求通过URL传输数据,而POST的数据通过请求体传输。
-
安全性不同:POST的数据因为在请求主体内,所以有一定的安全性保证,而GET的数据在URL中,通过历史记录,缓存很容易查到数据信息。
-
数据类型不同:GET只允许 ASCII 字符,而POST无限制
-
GET无害: 刷新、后退等浏览器操作GET请求是无害的,POST可能重复提交表单
-
特性不同:GET是安全(这里的安全是指只读特性,就是使用这个方法不会引起服务器状态变化)且幂等(幂等的概念是指同一个请求方法执行多次和仅执行一次的效果完全相同),而POST是非安全非幂等
理解TCP/IP协议
TCP/IP,传输控制协议/网际协议,是指能够在多个不同网络间实现信息传输的协议簇
- TCP(传输控制协议)
一种面向连接的、可靠的、基于字节流的传输层通信协议
- IP(网际协议)
TCP/IP 的四层结构则如下表所示:
层次名称 | 单位 | 功 能 | 协 议 |
---|---|---|---|
网络接口层 | 帧 | 负责实际数据的传输,对应OSI参考模型的下两层 | HDLC(高级链路控制协议)PPP(点对点协议) SLIP(串行线路接口协议) |
网络层 | 数据报 | 负责网络间的寻址数据传输,对应OSI参考模型的第三层 | IP(网际协议) ICMP(网际控制消息协议)ARP(地址解析协议) RARP(反向地址解析协议) |
传输层 | 报文段 | 负责提供可靠的传输服务,对应OSI参考模型的第四层 | TCP(控制传输协议) UDP(用户数据报协议) |
应用层 | 负责实现一切与应用程序相关的功能,对应OSI参考模型的上三层 | FTP(文件传输协议) HTTP(超文本传输协议) DNS(域名服务器协议)SMTP(简单邮件传输协议)NFS(网络文件系统协议) |
说说 HTTP1.0/1.1/2.0 的区别
HTTP1.0:
- 浏览器与服务器只保持短暂的连接,浏览器的每次请求都需要与服务器建立一个TCP连接
HTTP1.1:
- 引入了持久连接,即TCP连接默认不关闭,可以被多个请求复用
- 在同一个TCP连接里面,客户端可以同时发送多个请求
- 虽然允许复用TCP连接,但是同一个TCP连接里面,所有的数据通信是按次序进行的,服务器只有处理完一个请求,才会接着处理下一个请求。如果前面的处理特别慢,后面就会有许多请求排队等着
- 新增了一些请求方法
- 新增了一些请求头和响应头
HTTP2.0:
-
采用二进制格式而非文本格式
-
完全多路复用,而非有序并阻塞的、只需一个连接即可实现并行
-
使用报头压缩,降低开销
-
服务器推送
说说HTTP 常见的状态码有哪些,适用场景
状态码第一位数字决定了不同的响应状态,有如下:
- 1 表示消息
- 2 表示成功
- 3 表示重定向
- 4 表示请求错误
- 5 表示服务器错误
1xx
代表请求已被接受,需要继续处理。这类响应是临时响应,只包含状态行和某些可选的响应头信息,并以空行结束
常见的有:
- 100(客户端继续发送请求,这是临时响应):这个临时响应是用来通知客户端它的部分请求已经被服务器接收,且仍未被拒绝。客户端应当继续发送请求的剩余部分,或者如果请求已经完成,忽略这个响应。服务器必须在请求完成后向客户端发送一个最终响应
- 101:服务器根据客户端的请求切换协议,主要用于websocket或http2升级
2xx
代表请求已成功被服务器接收、理解、并接受
常见的有:
- 200(成功):请求已成功,请求所希望的响应头或数据体将随此响应返回
- 201(已创建):请求成功并且服务器创建了新的资源
- 202(已创建):服务器已经接收请求,但尚未处理
- 203(非授权信息):服务器已成功处理请求,但返回的信息可能来自另一来源
- 204(无内容):服务器成功处理请求,但没有返回任何内容
- 205(重置内容):服务器成功处理请求,但没有返回任何内容
- 206(部分内容):服务器成功处理了部分请求
3xx
表示要完成请求,需要进一步操作。 通常,这些状态代码用来重定向
常见的有:
- 300(多种选择):针对请求,服务器可执行多种操作。 服务器可根据请求者 (user agent) 选择一项操作,或提供操作列表供请求者选择
- 301(永久移动):请求的网页已永久移动到新位置。 服务器返回此响应(对 GET 或 HEAD 请求的响应)时,会自动将请求者转到新位置
- 302(临时移动): 服务器目前从不同位置的网页响应请求,但请求者应继续使用原有位置来进行以后的请求
- 303(查看其他位置):请求者应当对不同的位置使用单独的 GET 请求来检索响应时,服务器返回此代码
- 305 (使用代理): 请求者只能使用代理访问请求的网页。 如果服务器返回此响应,还表示请求者应使用代理
- 307 (临时重定向): 服务器目前从不同位置的网页响应请求,但请求者应继续使用原有位置来进行以后的请求
4xx
代表了客户端看起来可能发生了错误,妨碍了服务器的处理
常见的有:
- 400(错误请求): 服务器不理解请求的语法
- 401(未授权): 请求要求身份验证。 对于需要登录的网页,服务器可能返回此响应。
- 403(禁止): 服务器拒绝请求
- 404(未找到): 服务器找不到请求的网页
- 405(方法禁用): 禁用请求中指定的方法
- 406(不接受): 无法使用请求的内容特性响应请求的网页
- 407(需要代理授权): 此状态代码与 401(未授权)类似,但指定请求者应当授权使用代理
- 408(请求超时): 服务器等候请求时发生超时
5xx
表示服务器无法完成明显有效的请求。这类状态码代表了服务器在处理请求的过程中有错误或者异常状态发生
常见的有:
- 500(服务器内部错误):服务器遇到错误,无法完成请求
- 501(尚未实施):服务器不具备完成请求的功能。 例如,服务器无法识别请求方法时可能会返回此代码
- 502(错误网关): 服务器作为网关或代理,从上游服务器收到无效响应
- 503(服务不可用): 服务器目前无法使用(由于超载或停机维护)
- 504(网关超时): 服务器作为网关或代理,但是没有及时从上游服务器收到请求
- 505(HTTP 版本不受支持): 服务器不支持请求中所用的 HTTP 协议版本
从浏览器地址栏输入 url 到请求返回发生了什么
- URL解析
- DNS 查询
- TCP 连接
- HTTP 请求
- 响应请求
- 页面渲染
TCP 三次握手和四次挥手是什么
消息类型 | 描述 |
---|---|
SYN | 这个消息是用来初始化和建立连接的。 |
ACK | 帮助对方确认收到的 SYN 消息 |
SYN-ACK | 本地的 SYN 消息和较早的 ACK 数据包 |
FIN | 用来断开连接 |
三次握手
三次握手(Three-way Handshake)其实就是指建立一个TCP连接时,需要客户端和服务器总共发送3个包
主要作用就是为了确认双方的接收能力和发送能力是否正常、指定自己的初始化序列号为后面的可靠性传送做准备
过程如下:
-
第一次握手:客户端先向服务器发送一个同步数据包:同步SYN=1,确认ACK=0
-
第二次握手:
- 服务器收到客户端发送的第一个数据包后,根据SYN=1与ACK=0,判断出为主动建立连接的数据包。
- 若服务器同意连接,发送给客户端一个数据包:同步SYN=1,确认ACK=1进行回应。
- 第三次握手:客户端收到服务器的确认之后,再给服务器发送一个数据包:同步SYN=0,确认SYN=0,代表双方已同意建立连接,ACK=1,表示收到服务器的确认数据包。
为什么不是两次握手?
如果是两次握手,发送端可以确定自己发送的信息能对方能收到,也能确定对方发的包自己能收到,但接收端只能确定对方发的包自己能收到 无法确定自己发的包对方能收到
并且两次握手的话, 客户端有可能因为网络阻塞等原因会发送多个请求报文,延时到达的请求又会与服务器建立连接,浪费掉许多服务器的资源
四次挥手
tcp
终止一个连接,需要经过四次挥手
过程如下:
- 第一次挥手:客户端发送一个 FIN 报文,报文中会指定一个序列号。此时客户端处于 FIN_WAIT1 状态,停止发送数据,等待服务端的确认
- 第二次挥手:服务端收到 FIN 之后,会发送 ACK 报文,且把客户端的序列号值 +1 作为 ACK 报文的序列号值,表明已经收到客户端的报文了,此时服务端处于 CLOSE_WAIT状态
- 第三次挥手:如果服务端也想断开连接了,和客户端的第一次挥手一样,发给 FIN 报文,且指定一个序列号。此时服务端处于
LAST_ACK
的状态 - 第四次挥手:客户端收到 FIN 之后,一样发送一个 ACK 报文作为应答,且把服务端的序列号值 +1 作为自己 ACK 报文的序列号值,此时客户端处于 TIME_WAIT状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态,服务端收到 ACK 报文之后,就处于关闭连接了,处于 CLOSED 状态
四次挥手原因
服务端在收到客户端断开连接Fin
报文后,并不会立即关闭连接,而是先发送一个ACK
包先告诉客户端收到关闭连接的请求,只有当服务器的所有报文发送完毕之后,才发送FIN
报文断开连接,因此需要四次挥手
跨域
当前页面中的某个接口请求的地址和当前页面的地址如果协议、域名、端口其中有一项不同,就说该接口跨域了。 跨域限制的原因:浏览器为了保证网页的安全,出的同源协议策略
-
JSONP(前端体系课有完整且详细的介绍)
- 甲站点利用 script 标签可以跨域的特性,向乙站点发送 get 请求。
- 乙站点后端改造 JS 文件的内容,将数据传进回调函数。
- 甲站点通过回调函数拿到乙站点的数据。
-
CORS(前端体系课有完整且详细的介绍)
- 对于简单请求,乙站点在响应头里添加
Access-Control-Allow-Origin: http://甲站点
即可。
-
对于复杂请求,如 PATCH,乙站点需要:
-
响应 OPTIONS 请求,在响应中添加如下的响应头
makefile 复制代码 Access-Control-Allow-Origin: https://甲站点 Access-Control-Allow-Methods: POST, GET, OPTIONS, PATCH Access-Control-Allow-Headers: Content-Type
- 响应 POST 请求,在响应中添加
Access-Control-Allow-Origin
头。
-
- 如果需要附带身份信息,JS 中需要在 AJAX 里设置
xhr.withCredentials = true
。
- 对于简单请求,乙站点在响应头里添加
-
Nginx 代理 / Node.js 代理
- 前端 ⇒ 后端 ⇒ 另一个域名的后端
Cookie、Session、localStorage、sessionStorage
cookie
-
由服务端生成,保存在客户端(由于前后端有交互,所以安全性差,且浪费带宽)
-
存储大小有限(最大 4kb )
-
存储内容只接受
String
类型 -
保存位置:
- 若未设置过期时间,则保存在
内存
中,浏览器关闭后销毁 - 若设置了过期时间,则保存在
系统硬盘
中,直到过期时间结束后才消失(即使关闭浏览器)
- 若未设置过期时间,则保存在
-
数据操作不方便,原生接口不友好,需要自己封装
-
应用场景
- 判断用户是否登陆过网站,以便下次登录时能够实现自动登录(或者记住密码)
- 保存登录时间、浏览次数等信息
session
- 是后端关心的内容,依赖于 cookie(sessionID 保存在cookie中)
- 保存在服务端
- 存储大小无限制
- 支持任何类型的存储内容
- 保存位置:服务器内存,若访问较多会影响服务器性能
localStorage
- 持久化的本地存储,浏览器关闭重新打开数据依然存在(除非手动删除数据)。
- 应用场景:长期登录、判断用户是否已登录,适合长期保存在本地的数据。
sessionStorage
- 浏览器窗口关闭后数据被销毁。
- 应用场景:敏感账号一次性登录
总结
综上所述,我们可以知道,cookie
和 webStorage
( localStorage、sessionStorage )是前端工程师关心的内容,session
是后端关心的内容。
cookie
存储量小、安全性差、数据操作接口不友好,而 webStorage
存储量较大、安全性较高、数据接口友好。
若要持久的存储方式,推荐使用 localStorage
若要一次性会话的存储,推荐使用 sessionStorage
说说对WebSocket的理解
WebSocket,是一种网络传输协议,位于OSI
模型的应用层。可在单个TCP
连接上进行全双工通信,能更好的节省服务器资源和带宽并达到实时通迅
客户端和服务器只需要完成一次握手,两者之间就可以创建持久性的连接,并进行双向数据传输
- 较少的控制开销:数据包头部协议较小,不同于http每次请求需要携带完整的头部
- 更强的实时性:相对于HTTP请求需要等待客户端发起请求服务端才能响应,延迟明显更少
- 保持创连接状态:创建通信后,可省略状态信息,不同于HTTP每次请求需要携带身份验证
- 更好的二进制支持:定义了二进制帧,更好处理二进制内容
- 支持扩展:用户可以扩展websocket协议、实现部分自定义的子协议
- 更好的压缩效果:Websocket在适当的扩展支持下,可以沿用之前内容的上下文,在传递类似的数据时,可以显著地提高压缩率
应用
- 弹幕
- 媒体聊天
- 协同编辑
- 基于位置的应用
- 体育实况更新
- 股票基金报价实时更新
转载自:https://juejin.cn/post/7256759718811156538