1. 从输⼊ URL 到页面展示到底发生了什么?
整体流程 : 客户端获取URL - > DNS解析 - > TCP连接 - >发送HTTP请求 - >服务器处理请求 - >返回报文 - >浏览器解析渲染页面 - > TCP断开连接
客户端(浏览器):
- (应用层)
- 浏览器收到客户请求,先检查浏览器的缓存中是否有缓存该资源,如果有直接返回;如果没有,进行下一步的网络请求。
- DNS解析。什么是DNS解析? 当用户输入一个网址并按下回车键的时候,浏览器得到了一个域名。而在实际通信的过程中,我们需要的是一个IP地址,因此需要先把域名转换为相应的IP地址,这个过程称为DNS解析。 如果请求协议是HTTPS,那么还需要建立TLS连接。DNS解析时会按照: 本地浏览器缓存 -> 本地Host文件 -> 路由器缓存 -> DNS 服务器 -> 根DNS服务器 的顺序查询域名对应的IP地址。
- 根据HTTP协议生成HTTP请求报文(应用层结束)
- (传输层) 浏览器与服务器IP建立TCP连接。根据TCP协议连接从客户端到服务端(通过三次握手)客户端给服务端发送一个带SYN(同步)标志的数据包给客户端,然后客户端接收到信息再给客户端回传一个带有SYN / ACK(确认)标志的数据包以示传达确认信息,客户求最后端的再传送一个带ACK标志的数据包,代表“握手”结束,连接成功.TCP协议再把请求报文按序号分割成多个报文段(
- (网络层) 根据IP协议(传输数据),ARP协议(获取MAC地址),OSPF协议(选择最优路径),搜索服务器地址,一边中转一边传输数据
- (数据链路层) 到达后通过数据链路层,物理层负责0,1比特流与物理设备电压高低,光的闪灭之间的互换。数据链路层负责将0,1序列划分为数据帧从一个节点传输到临近的另一个节点,这些节点是通过MAC来唯一标识的(MAC,物理地址,一个中主机会有一个MAC地址)。
服务端:
通过数据链路层 - >通过网络层 - >再通过传输层(根据TCP协议接收请求报文并重组报文段) - >再通过应用层(通过HTTP协议对请求的内容进行处理) - >再通过应用层 - >传输层 - >网络层 - >数据链路层 - >到达客户端
客户端:
通过数据链路层 - >网络层 - >传输层(根据TCP协议接收响应报文并重组) - >应用层(HTTP协议对响应进行处理) - >浏览器渲染页面 - >断开连接协议四次挥手)
2. 三次握手的过程 (为什么是三次握手? 为什么不是两次、四次?)
三次握手的过程:
- 客户端向服务端发送一个SYN 报文、初始化序列号(seq = x),客户端进入SYN_SENT的状态。
- 服务端收到客户端的SYN后, 回复一个ACK的确认报文、序列号(ack = x + 1), 同时发送一个SYN报文、序列号(seq = y), 然后服务端进入SYN_SENT的状态。
- 客户端收到服务端的SYN和ACK报文之后,向服务端发送一个ACK报文、序列号(ack = y +1), 然后客户端和服务端都进入ESTABLISHED的状态,连接建立成功。
为什么不是两次握手或四次握手?
因为三次握手才能确保双方都建立了连接并且不浪费资源。 如果是两次握手的话,服务端就无法确认客户端是否收到了自己的回复,所以每收到一个SYN,服务器都会去主动建立连接, 而四次握手会造成资源浪费,因为只靠三次握手双方就可以确认对方都能够收到自己的信息,所以四次握手可以优化为三次。
3. 四次挥手的过程(为什么是四次挥手?)
四次挥手发生在断开连接的时候,在程序中当调用了close()会使用TCP协议进行四次挥手。
客户端和服务器端都可以主动发起断开连接,谁先调用close()谁就是发起。
因为在TCP连接的时候,采用三次握手建立的的连接是双向的,在断开的时候需要双向断开。
过程:
- 客户端发送一个想要断开连接的FIN报文 和初始序列号(seq = x)给服务端,然后客户端进入FIN_WAIT_1的状态。
- 服务端收到连接后,会发送一个表示收到的报文ACK给客户端,其中包含一个序列号 seq = x + 1, 然后服务端进入CLOSED_WAIT的状态,客户端收到之后进入FIN_WAIT_2的状态。
- 当服务端想要断开连接时, 发送一个FIN报文和初始序列号 seq = y 给客户端,然后进入LAST_ACK的状态。
- 客户端收到后,发出ACK报文进行应答,其中包含序列号 seq = y + 1, 此时客户端进入TIME_WAIT的状态。 服务端在收到客户端的ACK报文后进入CLOSED状态, 如果客户端等待2MSL没有收到回复,才关闭连接。
为什么是四次挥手?
TCP是全双工通信,可以双向传输数据。 通信中的一方在数据传输结束后可以向另一方发送释放连接的通知,待收到对方的确认回复后,进入半关闭的状态。 当另一方的数据也传送完毕后,则发出连接释放的通知,对方确认后才会完全关闭TCP连接。总之,两次挥手可以释放一端到另一端的TCP连接,完全释放连接需要四次挥手。
4. TCP与UDP的概念,特点,区别和对应的使用场景
概念
TCP (传输控制协议), 是一种面向连接的、可靠的、基于字节流的传输层通信协议。
UDP(用户数据包协议), 为用户提供了一种无需建立连接就可以发送封装的IP数据包的方法。
特点
TCP: 面向连接,传输可靠,传输形式为字节流,传输速度慢,所需资源多。
UDP: 无需连接,不可靠,传输形式为数据报文段,传输速度快,所需资源少。
区别
TCP | UDP | |
---|---|---|
面向连接 | 是 | 否 |
可靠 | 可靠 | 不可靠(不保证顺序和是否丢失) |
流量控制 | 滑动窗口 | 无 |
拥塞控制 | 慢开始、拥塞避免、快重传、快恢复 | 无 |
效率 | 低 | 高 |
状态 | 有状态 | 无状态 |
传输形式 | 面向字节流 | 面向报文 |
首部开销 | 大 | 小 |
广播/多播 | 点对点 | 一对一、一对多、多对一、多对多 |
应用场景
TCP :对效率要求低,对准确性要求高的场景,比如:网页浏览、邮件传输、消息传递、文件传输等
UDP:对效率要求高,对准确性要求低的场景,比如:视频直播、域名转换、实时游戏等
5. HTTP请求常见的状态码和字段
常见字段
- Host:客户端发送请求时,标识服务端主机的域名
- connect-length:服务器返回数据时,带有该字段,表示回应的数据长度
- conntection:常用于客户端要求服务端采用HTTP长连接时使用
- conntect-type:服务端返回的数据的数据类型
- Connect-Encoding:服务端返回的数据使用了什么压缩格式
HTTP状态码
- 1xx :提示信息,表示请求处理的中间状态
- 2xx :请求成功(200 : 请求成功,通常用于浏览器。 204:无内容 206:部分内容)
- 3xx:请求重定向
- 4xx:请求错误
- 5xx:服务器错误
6. 常见的请求方式,GET和POST请求的区别
- 作用
- GET请求一般用来从服务端获取资源
- POST请求一般用来提交表单
- 参数传递方式
- GET请求的参数一般储存在URL中,且只接受 ASCII码字符
- POST请求的参数一般在请求体中,对于数据类型也没有限制
- 安全性
- 由于GET请求的参数一般直接暴露在URL中,所以更不安全,不能用来传递敏感信息
- 参数长度
- GET请求一般要求长度在2KB以内
- POST请求一般对长度没有限制
- HTTP协议没有body和URL的长度限制,对URL限制的大多是浏览器和服务器的原因
- 缓存机制
- GET请求的数据会被浏览器主动cache,而POST不会,除非主动设置
- GET请求的数据会被完整保留在浏览器的历史记录里,而POST中的参数不会被保留
- GET请求的URL可以被保存为书签
- GET请求在浏览器回退时是无害的,而POST会再次提交数据
- 编码机制
- GET请求只能进行URL编码
- POST请求支持多种编码方式
- 时间消耗
- GET请求产生一个TCP数据包
- POST请求会产生两个TCP数据包
- 对于GET请求,浏览器会把header和data一起发送出去,服务器返回 200(返回数据);
- 对于POST,浏览器先发送header,服务器返回 100(continue), 浏览器再发送data,服务器返回200 ok(返回数据).
- 安全幂等
- 幂等指的是执行相同的操作可以获得相同的结果。
- GET请求是安全幂等的。由于GET操作是只读的操作,所以无论执行多少次,服务器上的数据都是安全的,且每次的结构都是相同的。
- POST每次都要重新提交表单,会修改服务器上的数据,所以是不安全的,且多次提交数据就会创建多个资源,所以是不幂等的。
7. 什么是强缓存和协商缓存(准备的是后端,放弃这题了)
8. HTTP1.0 和HTTP1.1的区别
- 长连接
- HTTP1.0默认是短连接,每一次请求都要建立一次TCP连接
- HTTP1.1支持长连接,并且一个TCP连接中可以传输多个HTTP请求和响应,且默认开启Connection:Keep-alive
- 缓存机制
- HTPP 1.0 默认使用If-Modified-Since/Expires缓存机制
- HTTP1.1新增了一些缓存机制
- 管线化
- 由于HTTP的长连接,使得管线化成为可能,管线化使得请求能够“并行”传输,但是响应必须是按照发出的顺序返回,性能在一定程度上得到了改善
- Host头部
- 增加了Host字段,使得一个服务器能够用来创建多个Web站点
- 新增了24个错误状态响应码
- 带宽优化
- HTTP1.0存在一些浪费带宽的问题,例如客户端只需要某个对象的某一部分,服务器却把整个对象传递过来了,并且不支持断点续传的功能
- HTTP1.1增加了range字段,可以指定只请求某个资源的某一部分数据 ,即返回码是206。
9. HTTP 2.0 与 HTTP 1.1的区别
- 二进制分帧
- HTTP2.0在应用层(HTTP)和传输层(UDP/TCP)之间增加了一个二进制分帧层,突破了HTTP1.1的局限,增加了传输的效率,实现低延时和高吞吐
- 多路复用
- 允许同时通过单一的HTTP2.0连接发起多重的请求-响应消息,这个强大的功能是基于“二进制分帧”的特性。
- 压缩头部
- 在HTTP1.1中,不支持头部的压缩,HTTP2.0可以使用HPACK算法对数据头部进行压缩,更小的头部在传输的过程中速度就会更快。高效的压缩算法可以很大程度上压缩头部,减少发送包的数量从而降低延迟。
- 服务端推送
-在HTTP2.0中,服务器可以对客户端的一个请求产生多次响应,即服务器可以额外向客户端发送数据而无需获得请求。