网络相关知识
1. HTTP 和 HTTPS 的区别
HTTP 介绍
HTTP
即超文本传输协议,是实现网络通信的一种规范
在计算机和网络世界有,存在不同的协议,如广播协议、寻址协议、路由协议等等
而 HTTP 是一个传输协议,即将数据由 A 传到 B 或将 B 传输到 A,并且 A 与 B 之间能够存放很多第三方,如: A<=>X<=>Y<=>Z<=>B
传输的数据并不是计算机底层中的二进制包,而是完整的、有意义的数据,如 HTML 文件, 图片文件, 查询结果等超文本,能够被上层应用识别
在实际应用中,HTTP 常被用于在 Web 浏览器和网站服务器之间传递信息,以明文方式发送内容,不提供任何方式的数据加密
特点如下:
- 支持客户/服务器模式
- 简单快速:客户向服务器请求服务时,只需传送请求方法和路径。由于 HTTP 协议简单,使得 HTTP 服务器的程序规模小,因而通信速度很快
- 灵活:HTTP 允许传输任意类型的数据对象。正在传输的类型由 Content-Type 加以标记
- 无连接:无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求,并收到客户的应答后,即断开连接。采用这种方式可以节省传输时间
- 无状态:HTTP 协议无法根据之前的状态进行本次的请求处理
HTTPS 介绍
为了保证数据的安全性,让 HTTP 运行在安全的 SSL/TLS 协议上,即 HTTPS = HTTP + SSL/TLS,通过 SSL 证书来验证服务器的身份,并为浏览器和服务器之间的通信进行加密
SSL 协议位于 TCP/IP 协议与各种应用层协议之间,浏览器和服务器在使用 SSL 建立连接时需要选择一组恰当的加密算法来实现安全通信,为数据通讯提供安全支持
- 首先客户端通过 URL 访问服务器建立 SSL 连接
- 服务器接收到客户端的请求后,会将网站支持的证书信息(证书中包含的公钥)传输给客户端
- 客户端、服务器开始协商 SSL 连接的安全等级,也就是信息加密的等级
- 浏览器根据双方同意的安全等级,建立会话秘钥,然后利用网站的公钥将会话密码进行加密,并传输给网站
- 服务器会利用自己的私钥解密出会话秘钥,与客户端之间的通信
区别
- HTTP 是无状态的超文本传输协议,连接简单,数据是明文传输的,端口默认是 80
- HTTPS 是由 HTTP + SSL/TLS 协议构建的可进行数据加密、身份认证的具有安全性的超文本传输协议,端口默认是 443
2. 网络分层模型
OSI 理论模型
Open System Interconnection 开放式系统互联模型。是国际标准化组织 ISO 制定的理论模型
TCP/IP 四层模型
基于 OSI 理论模型建立的实际现实模型
3. TCP 的三次握手
- 第一次握手:客户端会向服务端发送请求(确保客户端发送能力没问题)
- 第二次握手:服务端会给客户端发送响应(确保服务端的接受能力、发送能力没问题)
- 第三次握手:客户端接收到服务端的响应(确保客户端的接收能力没问题)
目的:通过三次握手就可以确定双方的收发能力没问题。之后就可以正常通信了
4. TCP 的四次挥手
- 第一次挥手:客户端发送一个 FIN 报文,报文中会指定一个序列号。此时客户端处于 FIN_WAIT1 状态。
- 第二次挥手:服务端收到 FIN 之后,会发送 ACK 报文,且把客户端的序列号值 + 1 作为 ACK 报文的序列号值,表明已经收到客户端的报文了,此时服务端处于 CLOSE_WAIT 状态。
- 第三次挥手:如果服务端也想断开连接了,和客户端的第一次挥手一样,发给 FIN 报文,且指定一个序列号。此时服务端处于 LAST_ACK 的状态。
- 第四次挥手:客户端收到 FIN 之后,一样发送一个 ACK 报文作为应答,且把服务端的序列号值 + 1 作为自己 ACK 报文的序列号值,此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态
目的:
四次挥手的原因:服务端在收到客户端断开连接Fin
报文后,并不会立即关闭连接,而是先发送一个ACK
包先告诉客户端收到关闭连接的请求,只有当服务器的所有报文发送完毕之后,才发送FIN
报文断开连接,因此需要四次挥手
5. 说说 HTTP1.0/1.1/2.0 的区别
HTTP/1.0
HTTP/1.0
浏览器和服务器只保持短暂的连接,每次请求都需要和服务器建立一个 TCP
连接。请求处理完成后都会断开连接
例如,解析 HTML
文件,当发现文件中存在资源文件的时候,这时候又创建单独的链接
最终导致,一个 HTML 文件的访问包含了多次的请求和响应,每次请求都需要创建连接、关系连接,这种形式明显造成了性能上的缺陷
如果需要建立长连接,需要设置一个非标准的 Connection 字段 Connection: keep-alive
HTTP/1.1
在 HTTP/1.1
中,默认支持长连接 Connection: keep-alive
,即在一个 TCP 连接上可以传送多个 HTTP 请求和响应,减少了建立和关闭连接的消耗和延迟
建立一次连接,多次请求均由这个连接完成
同时,HTTP 1.1
还允许客户端不用等待上一次请求结果返回,就可以发出下一次请求,但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果,以保证客户端能够区分出每次请求的响应内容,这样也显著地减少了整个下载过程所需要的时间
同时,HTTP1.1
在 HTTP1.0
的基础上,增加更多的请求头和响应头来完善的功能,并且还添加了其他的请求方法
HTTP/2.0
HTTP/2.0
与之前版本相对,性能有很大的提升
多路复用
HTTP/2.0
复用 TCP 连接,在一个连接里,客户端和浏览器都可以同时发送多个请求或响应,而且不用按照顺序一一对应,这样就避免了队头堵塞
二进制分帧
HTTP/2.0
采用二进制格式传输数据,而非 HTTP 1.x 的文本格式,解析起来更高效
首部压缩
HTTP/2.0
在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键值对,对于相同的数据,不再通过每次请求和响应发送
首部表在 HTTP 的连接存续期内始终存在,由客户端和服务器共同渐进地更新
例如:下图中的两个请求, 请求一发送了所有的头部字段,第二个请求则只需要发送差异数据,这样可以减少冗余数据,降低开销
服务器推送
引入服务器推送,服务器会顺便把一些客户端需要的资源一起推送到客户端,如在响应一个页面请求中,就可以随同页面的其它资源
这种方式非常合适加载静态资源
总结
HTTP/1.0
- 浏览器与服务器只保持短暂的连接,浏览器的每次请求都需要与服务器建立一个 TCP 连接
HTTP/1.1
- 引入了持久连接,即 TCP 连接默认不关闭,可以被多个请求复用
- 在同一个 TCP 连接里面,客户端可以同时发送多个请求
- 虽然允许复用 TCP 连接,但是同一个 TCP 连接里面,所有的数据通信是按次序进行的,服务器只有处理完一个请求,才会接着处理下一个请求。如果前面的处理特别慢,后面就会有许多请求排队等着
- 新增了一些请求方法、一些请求头和响应头
HTTP/2.0
- 采用二进制格式而非文本格式
- 完全多路复用,而非有序并阻塞的、只需一个连接即可实现并行
- 使用报头压缩,降低开销
- 服务器推送
6. 浏览器输入 URL 后,发送了什么
1. URL 解析
首先判断输入的内容是一个合法的 URL 还是搜索的关键词
2. DNS 域名解析
然后通过 DNS 解析获取对应目标服务器的 IP 地址
3. TCP/IP 链接
在确认目标服务器的 IP 地址后,浏览器会与服务器经历三次握手建立 TCP 连接
4. 发送 HTTP 请求
建立 TCP 连接后,就可以进行通信,浏览器会发送 HTTP 请求到目标服务器
5. 响应请求
服务器接收到浏览器发送的请求后,就会响应请求,对资源进行解析
在服务器响应之后,由于现在 HTTP 默认开始长连接 Keep-alive,当页面关闭之后,TCP 连接则会经过四次挥手完成断开
6. 页面渲染
当浏览器接收到服务器响应的资源后,首先会对资源进行解析
- 查看响应头的信息,根据不同的指示做对应处理,比如重定向,存储 cookie,解压 gzip,缓存资源等等
- 查看响应头的 Content-Type 的值,根据不同的资源类型采用不同的解析方式
关于页面渲染简要概述如下:
- 解析 HTML,构建 DOM 树
- 解析 CSS,生成 CSS 规则树
- 合并 DOM 树和 CSS 规则树,得到一颗 render 渲染树
- 通过渲染树进行页面的布局,负责对各元素的尺寸大小、位置进行计算
- 绘制渲染树,绘制页面像素信息
- 浏览器会将各层的信息发送给 GPU,GPU 会将各层合成,显示在屏幕上
7. 常见的状态码有哪些,使用的场景
HTTP 状态码,用来表示网页服务器超文本传输协议响应状态的 3 位数字代码
分类
- 1xx 表示消息:代表请求已被接受,需要继续处理。这类响应是临时响应,只包含状态行和某些可选的响应头信息,并以空行结束
- 2xx 表示成功:代表请求已成功被服务器接收、理解、并接受
- 3xx 表示重定向:表示要完成请求,需要进一步操作。 通常,这些状态代码用来重定向
- 4xx 表示请求错误:代表了客户端看起来可能发生了错误,妨碍了服务器的处理
- 5xx 表示服务器错误:表示服务器无法完成明显有效的请求。这类状态码代表了服务器在处理请求的过程中有错误或者异常状态发生
8. UDP 和 TCP 的区别
UDP 的三大特点
- 简单,不需要与客户端建立连接所以无需握手
- 它不会建立连接,虽然有端口号,但是监听在这个地方,谁都可以传给它数据,它也可以传给任何人数据,甚至可以传给多个人数据
- 它不会根据网络的情况进行发包的拥塞控制,无论网络丢包丢成啥样,它该咋发还怎么发
UDP 的三大使用场景
- 需要资源少,在网络情况比较好的内网,或者对应丢包不敏感的引用
- 不需要一对一沟通,建立连接,而是可以广播的应用,谁都可以传给它数据,它也可以传给任何人数据,甚至可以传给多个人数据
- 需要处理速度快、延时低,可以容忍少数丢包,但是要去即便网络阻塞,也不能减慢发送速度
UDP | TCP | |
---|---|---|
是否连接 | 无连接 | 面向连接 |
是否可靠 | 不可靠运算,不使用流量控制和拥塞控制 | 可靠传输,使用流量控制和拥塞控制 |
连接对象个数 | 支持一对一、一对多、多对一和多得多的交互通信 | 只能是一对一通信 |
传输方式 | 面向报文 | 面向字节流 |
首部开销 | 首部开销小,8 字节 | 首部最小 20 字节,最大 60 字节 |
适用场景 | 适用于实时应用,例如视频会议、直播 | 适用于要求可靠传输的应用,例如文件传输 |