HTTP协议面试题🚴‍♂️HTTP协议的发展历史？🚴‍♂️HTTP协议常见的方法？🚴‍♂️GET和POST的区别？

🚴‍♂️HTTP协议的发展历史？

HTTP0.9,HTTP1.0正式版本之前的统称，请求报文只包含GET方法和资源路径，响应只包含HTML文件。
缺点:可传输文件类型有限，只支持HTML文件。没有多余的信息做错误处理。

HTTP1.0,HTTP的正式版本,
新增了头部字段和可选的请求方法Post和Head.
借助content-type头部字段可以传输丰富的文件类型,比如图片,视频,二进制文件等等.
缺点:tcp连接不能复用,每一次请求都要重新通过三次握手建立和服务器的连接.

HTTP1.1,对HTTP1.0的加强,
提供了丰富的请求方法.
为了解决HTTP1.0TCP无法被复用的问题引入了持久连接.
引入管道机制允许在同一个TCP连接中同时发送几个请求.
新增了实现分块传输编码的transfer-Encoding头部.
新增了Host请求头配合服务器实现虚拟主机.
缺点:
1.客户端复用TCP连接时,前面的请求如果响应很慢则会阻塞队列后面的请求,形成客户端队头阻塞问
题.如果使用管道机制,由于响应要按照请求的顺序返回,第一个到达服务器的请求很慢时也会阻塞其他
请求,形成服务器的对头阻塞问题.
2.无状态特性
3.明文传输
4.不验证消息的完整性.
5.不支持服务器推送

谷歌自行研发的SPDY协议.

HTTP/2,不会有子版本的一个版本.
二进制分针.
多路复用,客户端和服务器可以同时发送多个请求和响应,而且不受顺序的限制.
头部压缩.
服务端推送:在返回HTML文件给客户端的同时,服务器可以同时返回HTML依赖的资源.
请求优先级:即使在多路复用的情况下,由于带宽的影响客户端还是会阻塞请求的发送,可以为请求设置不
同的优先级,高优先级的请求首先会被处理.
缺点:
1.TCP的对头阻塞问题没有得到解决
2.多路复用会造成请求的短暂爆发,增加服务器的压力.
3.多路复用连接数超过上限,有可能造成批量超时.
4.TSL层的加入会增加和服务器建立连接的往返实际(RTT).

HTTP/3版本,
基于UDP

🚴‍♂️HTTP协议常见的方法？

  HTTP1.0：get、post、Head
  HTTP1.1：options、put、delete、trace、connect
  GET：用于从服务器获取资源。
  POST：用于向服务器提交数据。
  Head：和GET请求类似，但不返回资源主体，可用于判断服务器资源的有效性和更新时间
  Options：用于查询服务器指定资源的支持的请求方法。
  Put：用于向服务器传输文件。
  Delete：和PUT相反，请求服务器删除指定的资源。
  Trace：Trace服务器让web服务器将请求信息返回给客户端，配合Max-Forwards追踪
  请求发出去之后的传输情况。
  Connect：要求与代理服务器建立隧道，实现用隧道进行TCP通讯。

🚴‍♂️GET和POST的区别？

  1.传输数据的方式不同，GET请求的数据拼接到URL上，POST请求的数据放在请求体中。
  0.GET请求能够发送的数据只有几百个字节，而POST请求没有限制。
  2.支持的数据编码不同，GET请求只支持ASCII编码，而POST请求没有限制。
  3.对于请求的响应，GET请求的响应可以被缓存，POST不能被缓存。
  4.GET请求会受到浏览器后退或者刷新的影响，而Post请求不会。
  5.GET请求是安全且幂等的，POST请求是不安全非幂等的。同样的GET请求执行多次效果
  是一致的，GET请求不会引起服务端状态的变化。

🚴‍♂️HTTP常见的状态码？

100：服务器已接收客户端的请求，等待处理客户端接下来的请求。
101：服务器根据客户端的请求成功切换切换了协议，比如webSocket的ws、wss协议
200：获取服务器资源或者是提交数据成功。
204：服务器已处理客户端的请求，但响应报文中无响应主体。
206：服务器处理客户端的范围请求，并返回范围数据。
301：永久性重定向，表示请求资源的URI已更新，客户端应该请求新的URI并更新书签。
302：临时性重定向，请求的资源URI暂时更新，客户端不用更新本地书签。

303：服务器指定客户端根据返回的URI，发起GET请求。

304：服务器资源为改变，使用本地缓存资源。
400：请求失败，客户端请求报文出错。
401：表示客户端请求的资源需要HTTP认证。
403：拒接访问服务器的指定资源。
404：Not Found，找不到URI指定的资源。
416：客户端指定的范围请求越界。
500：服务器处理请求是出现逻辑错误。
503：服务器繁忙或者是停机维护，可以通过retry-after返回可访问时间。

🚴‍♂️301、302、303、307的规范标准和事实标准？

事实标准：几乎所有的浏览器在接到301、302、303状态码时，都会忽略响应的主体内容，并把请求方法由POST改为GET方法重新发起请求。

规范标准：在规范中规定，对于响应状态码为301、302时，禁止客户端把POST改为GET。如果确实需要改为GET并重新发起请求，应该返回303和location。

303和307是HTTP1.1新增的，是对302的细分，浏览器对303的处理和原来浏览器对302的处理一样浏览器对307的处理和原理文档规范规定不能把post改为get请求处理一样。

🚴‍♂️三次握手？

三次握手是客户端为了和服务器建立连接,在客户端和服务端交换三次报文的过程.在连接之前,客户端的套接字和服务端的套接字都没有关于通讯需要的控制信息,比如通讯目标的IP地址和端口号,序号和窗口等信息.通过连接在通讯双方之间交换控制信息,并在套接字中记录这些信息,为之后的收发数据做准备

第一次握手时:
客户端会创建一个TCP头部,这个TCP会包含客户端和服务端的端口号,并把控制位ACK和SYN设为0和1,并设置适当的序号和窗口大小.然后通过系统协议栈发往服务器.

第二次握手时:
数据包到达服务器后,服务器协议栈根据端口号找到等待连接的套接字,在套接字中记录相关信息并把状态改为正在连接.然后返回一个和第一次握手时类似的数据包,不同的是ACK标志位设置为1.

第三次握手时:
数据包被客户端接收后,客户端会判断标志位ACK是否等于1,如果等于1则向套接字中写入服务器的IP地址和端口号.客户端状态改为连接完毕.并向服务器回复一个ACK标志位为1的数据包. 服务端收到数据包后判断ACK标志位是否等于１，至此客户端和服务器建立连接．

🚴‍♂️为什么是三次而不是两次？

  如果握手的过程只有两次，服务器端会因为网络上的过期无效的连接请求建立连接，从而浪费系统资源．
  由于网络的不稳定性，第一次握手的数据包可能会在网络中发生拥塞阻塞，通过超时重传客户端建立了
  和服务端的连接，并通讯完毕后断开了连接．这时如果网络上拥塞的数据包突然到达服务器，在两次握手
  的情况下，服务器误以为客户端发起了新的连接请求，则会回复客户端并立即建立连接，如果是三次握手的
  话，客户端会忽略服务器的回复，服务器在得不到客户端的确认后中断这次意外的连接．

🚴‍♂️谁先发起断开连接请求?

  在HTTP1.0中,客户端和服务器通讯完毕后,服务器会首先发起断开连接请求.
  在HTTP1.1中,服务器返回响应数据之后,客户端还可以继续发起下一个请求信息,如果客户端没有后续的请求
  ,客户端会发起断开连接请求.

🚴‍♂️四次挥手？

  TCP 的连接的拆除需要发送四个包，因此称为四次挥手(Four-way handshake)，也叫做改进的三次握手。
  客户端或服务器均可主动发起挥手动作，在 socket 编程中，任何一方执行 close() 操作即可产生挥手操
  作。
  第一次挥手(FIN=1，seq=x)假设客户端想要关闭连接，客户端发送一个 FIN 标志位置为1的包，表示
  自己已经没有数据可以发送了，但是仍然可以接受数据。发送完毕后，客户端进入 FIN_WAIT_1 状态.
  
  第二次挥手(ACK=1，ACKnum=x+1)服务器端确认客户端的 FIN 包，发送一个确认包，表明自己接受到了客户
  端关闭连接的请求，但还没有准备好关闭连接。发送完毕后，服务器端进入 CLOSE_WAIT 状态，客户端接收
  到这个确认包之后，进入 FIN_WAIT_2 状态，等待服务器端关闭连接。
  
  第三次挥手(FIN=1，seq=y)服务器端准备好关闭连接时，向客户端发送结束连接请求，FIN 置为1。发送完毕
  后，服务器端进入 LAST_ACK 状态，等待来自客户端的最后一个ACK。
  
  第四次挥手(ACK=1，ACKnum=y+1)客户端接收到来自服务器端的关闭请求，发送一个确认包，
  并进入 TIME_WAIT状态，等待可能出现的要求重传的 ACK 包。服务器端接收到这个确认包之后，
  关闭连接，进入 CLOSED 状态。客户端等待了某个固定时间（两个最大段生命周期，
  2MSL，2 Maximum Segment Lifetime）之后，没有收到服务器端的 ACK ，认为服务器端已经正常关闭
  连接，于是自己也关闭连接，进入 CLOSED 状态。

🚴‍♂️客户端等待2*MSL才断开连接的原因？

  由于网络的不稳定性,客户端最后返回的ACK后可能会丢失.这时服务器会超时重传一次FIN,如果客户端没有
  等待2*MSL的时间就关闭连接,则重传的FIN包到达客户端后,会由于套接字被删除而无法被客户端协议栈接收
  处理.另一方面,如果其他的应用程序要建立套接字且恰好使用同一端口,重传的FIN包就会错误的到达新创建
  的套接字,新创建的套接字就会立即执行断开操作.

🚴‍♂️请求报文的组成？

  请求行
      请求方法 URI HTTP版本
  请求头
  
  ----空一行----
  请求体

🚴‍♂️响应报文的组成？

  状态行
      HTTP版本 状态码 状态描述符
  响应头
  
  ----空一行----
  响应体

🚴‍♂️状态码和状态描述符的异同？

状态码和状态描述符: 用于描述服务器处理HTTP请求的结果。
状态码: 三位数字组成，便于客户端应用程序的解析。
状态描述符: 是对状态码的语义化描述，便于开发人员理解和调试。

🚴‍♂️HTTP配合浏览器实现缓存的相关字段？

  强缓存:Expires,Cache-Control:private/public/max-age/no-store/no-cache/must-revalidate
  协商缓存:Last-Modified,if-modified-since,Etag,if-None-Match

  1.先判断cache-control,在max-age时间之内,返回200 from cache;
  2.如果没有cache-control,再判断Expires,在expires指定时间之前返回200 from cache.
  3.在强缓存失效的情况下,向服务器发送验证请求.
  4.服务器判断请求的if-None-Match、if-Modify-since

🚴‍♂️浏览器为什么需要同源策略？

没有同源策略限制的情况下，web世界是绝对开放的，不同源的站点可以任意修改对方的DOM或者读取本地数据，可以任意加载执行受信任的脚本，网站的隐私安全和行为得不到保障。同源策略的加入后，在不同源站点之间的DOM操作、数据读写、网络交互添加了有效的规则，很大程度上保障网站的行为和数据安全。

🚴‍♂️浏览器的同源策略有哪些策略？

DOM层面：同源策略限制来自不同源的JavaScript脚本对当前DOM的读和写操作

数据层面：同源策略限制了不同源的站点读取当前站点的cookie、localStorage、Index DB等本地数据

网络层面：同源策略限制当前站点的JavaScript脚本通过XMLHttpRequest等方式和不同源的远程服务器交互

🚴‍♂️前端如何实现跨域请求？

  JSONP:兼容性好,只支持GET请求,需要服务器配合.
  CROS:跨域资源共享:https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Access_control_CORS
  nigxn反向代理:
  iframe和postMessage:

🚴‍♂️JSONP是如何实现?

  1.创建script标签.
  2.准备回调函数
  3.把请求参数和回调方法拼接到URL.
  4.把script标签的src设置为拼接好的URL.
  5.把script标签添加到文档中.
  6.服务端解析请求参数和函数名,把处理结果拼接进函数中返回.
  7.浏览器执行返回的代码字符串,调用准备好的方法把结果暴露

🚴‍♂️CORS的请求过程描述?

  1.如果符合简单请求的标准,则直接发送Ajax请求,并在请求头的Host字段字段请求的域.服务器通过响应头
    的Access-Control-Allow-Origin标明支持跨域访问的域,浏览器判断请求域是否命中,命中则返回响应,
    否则忽略响应.
  2.如果是非简单请求,则通过Options请求发送预验请求,请求头包括本次请求的请求方法,请求头,请求域.
    服务器返回目标资源的跨域请求的允许范围.浏览器对比判断是否被允许,允许则像简单请求一样发送Ajax
    请求.否则默认AJAX请求失败.不做任何操作.
  3.如果跨域请求需要携带cookie或者是HTTP认证信息,可以设置WithCredentials:true;这种情况下,
    如果响应中没有设置Access-Control-Allow-Credentials:true;或者是Access-Control-Allow-Origin:*;
    浏览器则不会读取responce.

🚴‍♂️什么是简单请求?

  1.请求方法限定在GET,POST,HEAD
  2.可以自定义的头部:Accept-Language,Accept,Content-Language,width,
              Viewport-width,Downlink,DPR.3.Content-Type限制在text/plain,mutilpart/form-Data,application/x-www-form-urlencoded
  4.没有使用XMLHttpRequestUpload和ReadableStream对象

🚴‍♂️跨域资源共享的相关HTTP头部?

Access-Control-Allow-Origin: 访问控制允许的域.

Access-Control-Request-Headers: 访问控制请求头

Access-Control-Request-Methods: 访问控制请求方法

Access-Control-Allow-Headers: 访问控制允许的请求头.

Access-Control-Allow-Methods: 访问控制允许的请求方法.

Access-Control-Max-age: 预验请求的响应中返回,设置一定的时间内不需要发送预验请求

Access-Control-Allow-Credentials: 指定浏览器设置WithCredentials:true时,是否允许浏览器读取response

🚴‍♂️HTTP协议的缺点?

通讯使用明文,内容可能会被窃取.
不验证对方的身份,可能遭遇客户端伪装和服务器伪装.
无法验证消息的完整性,收到的报文可能被篡改,遭遇中间人攻击.

🚴‍♂️HTTPS如何实现加密传输？

HTTPS全称是超文本安全传输协议,是在HTTP协议的基础上添加一层SSL协议层.

HTTP协议先和SSL协议通讯,然后SSL协议再和TCP协议层通讯.

[参考链接](https://time.geekbang.org/column/article/110354)

🚴‍♂️什么是SSL/TLS？

SSL：安全套接层协议(Secure Socket Layer)，位于OSI协议的第五层，会话层，由网景公司于1994年提出，先后有V1、V2、V3三个版本，由于潜在安全问题逐渐被淘汰。

TLS：传输层安全(Transport Layer Security)，是SSL协议的规范实现，有TLS1.0、TSL1.1、 TSL1.2、TSL1.3四个版本，目前流行使用的是TSL1.2版本。

🚴‍♂️TLS加密算法是对称加密算法还是非对称加密算法？

TSL加密算法采用了混合加密的方式，握手过程中使用非对称加密算法，握手结束后的数据传输使用对称加密算法

原因:相同的安全强度下,非对称加密算法的密钥长度是对称加密算法的密钥长度的10倍左右,加密解密效率是毫秒级别,而对称加密的效率只有纳秒级别

TSL协议组成:

记录协议、握手协议、警告协议、变更密码规范协议、扩展协议

TSL的密码套件：

客户端和服务端都支持多种密码套件，握手的时候会协商使用某个密码套件。比如ECDHE-RSA-AES256-GCM-SHA384

握手时使用 ECDHE 算法进行密钥交换，用 RSA 签名和身份认证，握手后的通信使用 AES 对称算法，密钥长度 256 位，分组模式是 GCM，摘要算法 SHA384 用于消息认证和产生随机数

🚴‍♂️HTTPS的缺点？

1、操作系统要对通讯的数据包进行加密解密，会消耗CPU和内存资源，导致处理速度变慢
2、协议栈中增加了一层SSL层，在原有的基础上还要进行SSL通讯，整体上通讯量增加

🚴‍♂️WEB安全？

1.主动攻击：主动攻击是指攻击者通过直接访问web应用，把攻击代码传入的攻击模式。
2.主动攻击的代表：SQL注入攻击、OS命令注入攻击。

1.被动攻击：被动攻击是指利用圈套策略执行攻击代码的攻击模式。
2.被动攻击的代表：跨站脚本攻击、跨站点请求伪造。

1.跨站脚本攻击
2.跨站脚本攻击是指通过存在安漏洞的web网站运行非法的HTML标签或者是JavaScript脚本的攻击方式。
3.使用用户输入的内容在未转义的情况下，动态生成HTML标签。比如表单输入或者是用户评论。
4.根据用户输入的ＵＲＬ查询参数，动态设置表单内容。攻击者可以根据HTML标签规则闭合原有标签，然后拼接
  自定义标签。
5.通过注入恶意脚本窃取用户的cookie，利用用户的登录状态发送伪造攻击请求。

1.SQL注入攻击
2.SQL注入攻击是指利用web服务器数据库的漏洞，运行非法的SQL产生的攻击。
3.开发者直接使用用户的输入作为SQL语句的查询条件，会给攻击者注入非法SQL的攻击机会。

1.OS注入攻击
2.OS注入攻击是指通过web服务器执行非法的操作系统命令达到攻击的目的。
3.比如客户端请求服务端发送利用操作系统命令发送电子邮件。 

1.DDOS攻击
2.DDOS攻击指的是一种让服务器呈停止状态的攻击。
3.海量请求
4.攻击服务器漏洞。

1.会话劫持。
2.会话劫持指的是攻击者通过某种手段拿到用户的会话ID，非法使用ID伪装用户，达到攻击的目的。

🚴‍♂️创建HTTP首部

分类: 通用首部字段、请求首部字段、响应首部字段、实体首部字段

通用首部字段

Cache-Control：
connection: keep-alive、控制代理不再转发的字段
Date：HTTP报文的日期和时间。
Pragma：HTTP1.0向后兼容的字段
Transfer-Encoding：报文主体的传输编码
Upgrate：检测HTTP协议是否可以使用更高的版本比如websocket
Via：追踪客户端和服务器的报文传输的路径。配合trace方法和max-forwards使用

请求首部字段

Accept：告诉服务器客户端可以处理的媒体类型和优先级，比如text/html、image/jpg、video/mpeg、
    application/zip
Accept-charset：告诉服务器客户端支持的字符集及优先级。
Accept-Encoding：告诉服务器客户端支持的字符编码及优先级。
Accept-Language：客户端支持的自然语言集。
From：告诉服务器的用户的地址邮件地址。
Host：指定服务器的同一IP下多个域名的其中一个。
If-Modified-Since:确认本地缓存资源是否过期。
If-None-Match:
If-Match:
Etag:
if-range:如果指定值和Etag一致，则作为范围请求处理，范围由range指定，否则返回全部资源。
Max-Forwards:
Range:
User-Agen:用户代理

响应首部字段

Accept-Ranges:告知客户端服务器是否能够处理范围请求。
Age：代理服务器向源服务器验证的时间。
Etag:服务器的资源的唯一标识符。
Location：重定向后，新的资源的地址。
Retry-After：返回503状态，并告诉客户端多久后再请求。
Server：服务器应用程序的信息。

实体首部字段

Allow：GET，POST告诉客户端资源的支持方法
Content-Encoding：告诉客户端内容主体的内容编码
Content-language：实体内容语言
Content-Length: 实体内容长度
Content-Range：实体内容的范围

cookie相关：
Cookie：
Set-Cookie:name=value;expires ;path ;domain ;HttpOnly ;SameSite:strict、LAX、none ;secure: ;

控制网站内容作为iframe显示的方式
x-Frame-Options:DENY、SAMEORIGIN

🚴‍♂️在浏览器输入URL到页面呈现的全过程？

  1.浏览器解析用户输入的URL地址，得到服务器域名和请求文件路径。
  2.根据HTTP请求的报文格式构建请求报文。
  3.在请求发送之前，查询浏览器缓存，如果命中缓存则直接直接返回本地缓存。
  4.委托调用socket库的DNS解析程序发送域名解析查询，得到IP地址。
  5.准备好请求报文和IP地址后，委托socket发送HTTP请求。
  6.socket库创建本地套接字，并把套接字描述符返回给浏览器。
  7.本地系统协议栈通过三次握手建立和服务器的套接字的连接，建立连接后，双方套接字都有和对方通讯
    的信息。
  8.socket库委托协议栈把请求报文以电信号的形式发送出去，经过网络路由器等设备的转发到达服务器。
  9.到达服务器所在的网络后，先由服务器的防火墙筛选过滤。
  10.通过防火墙后，达到服务器的缓存代理服务器，如缓存匹配成功直接返回。
  11.缓存代理失效后，根据负载均衡指定的服务器，访问源服务器。
  12.源服务器匹配路由和控制器处理后，沿反方向返回响应报文。
  13.响应到达客户端后，浏览器从缓冲区中读取数据，开始页面的解析和渲染操作。
  14.由HTML解析器和css解析器解析后生成对应的DOM树和cssOM树，为DOM树的可见元素计算匹配样式
     规则生成渲染树。
  15.得到渲染树，通过回流计算元素在屏幕上的具体位置，最后通过重绘把元素渲染在屏幕上。遇到图片时
     保留占据的区域。并发送获取图片等媒体信息的查询。
  16.请求完成后，通过四次挥手和服务器断开连接，并删除归还套接字。

🚴‍♂️HTTP如何处理大文件的传输？

  文件数据压缩：Accept-Encoding、Content-Encoding，文本压缩效果明显，图片视频等媒体文件压缩无效
  分块传输：Transfer-Encoding:chunked;告诉浏览器采用分块传输。配合connection：keep-Alive使用。传输结束后浏览器会组合复原
  范围请求：发送Head请求查询是否支持范围请求。客户端Raneg：bytes:1-100;指定请求的范围，
           多线程并行下载；服务端返回206，Accepts-Range：bytes;Content-Range:0-100/1000;
  多段数据：

🚴‍♂️HTTP中表单数据的提交方式？

  application/x-www-form-urlencoded:表单数据被编码成以&分割的键值对。
  mutilpart/form-data:数据分为多个部分，各个部分由Content-Type指定的boundary分割。

🚴‍♂️HTTP2.0有哪些改进？

  头部压缩
  多路复用
  二进制分针
  服务器推送

🚴‍♂️怎么避免自己的页面被iframe嵌套？

  A后台控制:响应报文添加X-Frame-Options头部字段：
      DENY：即使相同域名也不能嵌套。
      SAMEORIGIN：相同域名可以嵌套。
      ALLOW-from url:指定来源可以嵌套。

  B前端控制
       if(top.location!==self.location){
      top.location = self.location;
  }

🚴‍♂️GET和POST分别进行几次数据交换？

  POST请求(三次)：
    浏览器请求TCP连接;
    服务器应答TCP连接;
    浏览器确认并发送POST请求头;
    服务器返回100continue;
    客户端发送数据主体;
    服务器处理返回响应;
  GET请求(两次)：
    浏览器请求TCP连接（第一次握手）;
    服务器应答TCP连接（第二次握手）;
    浏览器确认并发送GET请求头和数据;
    服务器返回响应;

🚴‍♂️HTTPS有几次握手？

HTTPS是建立会话层的TLS协议之上的，TLS协议依赖于TCP协议，TLS握手之前需要通过三次握手建立和服务器的连接，TLS协议自身握手的过程根据TSL加密套件会有两次和三次握手的不同情况．所以HTTPS会有５次握手(ECDHE密码套件)和６次握手(RSA密码套件)两种情况．

🚴‍♂️基于ECDHE密码套件的TLS握手？

参数解释:

CLient Random: 客户端随机数

Server Random: 服务端随机数

Client Params: 椭圆曲线算法的公钥

Server Params: 椭圆曲线算法的公钥

Pre-master: 前置主密钥

master-secret: 加密主密钥

第一次握手:

客户端发送CLient Hello报文,告诉服务器客户端TLS版本，支持密码套件，随机数C

第二次握手：

服务器选择合适的密码套件，返回Server Hello报文.告诉客户端TLS版本，密码套件，随机数S

数字证书 Server Params并用服务器私钥做签名认证.

客户端收到服务器的报文后,验证数字证书,确认服务器的真实性,得到服务器的公钥,利用公钥验证服务器的签名,得到密码套件算法的其中一个参数.

第三次握手:

客户端验证服务器身份后, 生成Client Params发给服务器, 并根据变更密码规范发送报文告诉服务器之后使用会话密钥加密通讯, 最后发送所有握手数据的摘要给服务器验证.

服务器和客户端都拿到密钥交换算法的两个参数Client Params和Server Params, 运行ECDHE算法得到Pre-Master-secret.

Pre-master = ECDHE(Server-Params, Client-Params);

服务器和客户端运行RFC算法得到加密通讯的master-secret.

master-secret = RFC(pre-master-secret, "master-secret", client-params, server-params);

客户端发送HTTP请求报文, 报文使用master-secret对称加密.

第四次握手:

服务端验证客户端的摘要成功后, 同样返回变更密码规范报文和所有握手数据的摘要

🚴‍♂️基于RSA密码套件的TLS握手?

第一次握手：

客户端通过发送Client Hello报文开始SSL通讯。告诉服务器SSL版本和加密组件列表;

第二次握手：

服务端回复server Hello报文。告诉客户服务器的SSL版本和挑选的加密组件;

服务端把公开密钥和证书发给客户端;

最后服务器发送Server Hello Done报文;

第三次握手：

客户端发送client key exchange报文，把客户端生成的公钥用服务端公钥加密发给服务器;

继续发送change cipher Spec报文，通知服务器之后的通讯都用公钥加密;

客户端发送FINISH报文，报文包含客户端握手的所有报文数据包的校验和;

第四次握手:

服务端同样发送change cipher spec报文;

服务器发送FINIS报文。

SSL握手结束。

🚴‍♂️TCP和UDP的区别？

是否面向连接：
TCP在发送数据之前要通过三次握手和目标主机建立连接，UDP接到上层的报文后添加UDP头部之间发送

是否可靠：
TCP可以利用流量控制和拥塞控制实现可靠传输，UDP不保证传输的可靠性

连接对象个数：
TCP可以只支持一对一通讯，UDP支持一对一，多对一，多对多通讯

首部开销：
UDP的首部开销小，只需要８个字节，TCP头部至少需要２０个字节

1.TCP面向字节流，TCP会根据接收方的窗口大小和网络的拥塞情况，把应用层的大报文拆分或者是连接小报文
2.UDP面向报文，不拆分不合并报文，报文大小有本地应用程序指定。

🚴‍♂️DNS查询的过程？

DNS查询是客户端向域名服务器发送域名请求解析IP地址的一个过程。

域名服务器为了运行和查询的效率，采用分布式分层次的形式，从高到低分别是根域名服务器、顶级域名服务器、权限域名服务器、本地域名服务器，高层的域名服务存储的是下层域名服务器的域名IP映射地址。

在发送请求给本地域名服务器之前, 客户端首先查找本地DNS缓存和本地HOST文件．

客户端的DNS请求首先发送给最近的本地域名服务器，本地域名服务器的IP存在本地内存中

本地域名服务器接到请求后首先会在本地映射表中查询，有匹配的记录则直接返回，否则向根域名服务器迭代发送这个DNS请求，根域名服务器的IP地址内置在每个服务器的配置文件中。

根域名服务器接收请求后，返回响应告诉本地服务器应该向下一层那个顶级服务器发请求，以此类推。

🚴‍♀️你所知道的3XX状态码

**300 multiple choices**

客户端请求一个实际指向多个资源的URL时会返回这个状态码

使用场景：一个网站有中文和英文两个版本，期望的效果是为英文用户提供英文版本，为中文用户提供中文版本。

HTTP提供了内容协商方法，允许客户端和服务端处理这样的过程，包括以下三种方式：

客户端驱动的协商、服务端驱动的协商、透明协商

300 multiple choices属于客户端协商，服务端返回状态码为 300 的响应报文，客户端浏览器收到这类型响应后，可能会弹窗，让用户选择。

**301 Moved Permanently**

请求的URL已被移除，请求资源所在的新地址会由响应报文的响应头location指定

使用场景：域名过期更换域名、服务器永久移动

301永久重定向是网站更改网址后对搜索引擎最友好的方法，通过301重定向，搜索引擎可以肯定旧的网址已被永久更改，把新的URL替代旧的URL，并把旧的网页权重传给新的网页。另外，浏览器也会用新的地址更新用户在浏览器收藏的标签。

**302 Move Temporarily**

和301类似，浏览器临时使用location返回的URL请求资源，将来的请求仍使用老的URL。

使用场景: 上传文件成功后重定向到成功页面, 固定更新URL指向最新的版本URL

HTTP规范：

当一开始的请求是GET请求时，浏览器会向返回的location发起新的GET请求。如果不是GET或者HEAD请求，浏览器应该禁止自动重定向，除非得到用户的确认。本质上，就是禁止改变原有请求方法和请求参数，重新发送请求。

事实规范:

使用HTTP1.0的客户端发起一个POST请求,并在响应中收到302重定向状态码时,会向location指定的URL发送GET请求.违反了302状态码的规范描述.

所以引入了303和307状态码细化302状态码的用途.

🚴‍♂️外部重定向和内部重定向的区别

外部重定向是浏览器的行为，比如常见的301永久重定向和302临时重定向，服务端会在响应头的location字段告诉浏览器重定向的地址，浏览器接收到后会发起新的请求。

内部重定向是服务器的行为，比如在nginx配置多个不同的域名指向同一个站点，浏览器通过不同的域名发起请求时，服务器会重定向到同一个站点并返回请求资源。

外部重定向，浏览器会发起两次请求，URL地址会发生变化，过度重定向会有性能开销问题。

内部重定向，浏览器时会发起一次请求，URL地址保持不变。

🚴‍♂️通用首部字段Cache-Control的使用场景

作为响应头

控制服务器返回的资源在浏览器的缓存行为。

作为请求头

点击刷新按钮或者CTRL+F5强制刷新页面时，浏览器会发起新的请求，并在请求头中添加 Cache-Control：no-cache；或者Cache-Control：max-age = 0；告诉服务器需要获取最新的资源。

Cache-Control，作为通用首部字段，在请求头和响应头的含义有差别。

🚴‍♂️代理协议出现的背景和解决痛点

[参考链接](www.cnblogs.com/amyzhu/p/10…)

remote_addr：指的是当前直接请求的客户端IP地址，它存在于tcp请求体中，是http协议传输的时候自动添加，不受请求头header的控制。因此，当客户端与服务器之间不存在任何代理的时候，通过remote_addr获取客户端IP地址是最准确，也是最安全的。

代理分类

透明代理、匿名代理、正向代理、反向代理

反向代理使用场景

负载均衡

健康检查

安全防御

数据过滤

为了实现某些特定的功能，比如数据过滤，原服务器需要知道客户端的身份或者IP地址。此时通过remote_addr获取的就是代理服务器的IP地址，而不是真实客户端地址。

所以为了传第真实的客户端IP，需要在代理服务器配置相关规则，首先通过remote_addr 获取客户端IP，转化给源服务器时，通过下列两种方式把客户端IP 添加到请求报文中。

事实上的标准： X-Forwarded-for、X-Forwarded-Host、X-Forwarded-Proto、X-Real-IP请求头部字段

通过上面四个头部字段，服务器可以获取客户端的IP等信息，但代理服务器需要解析修改请求头，遇到HTTPS协议的请求，代理服务器无法解析请求头，这种方式就失效了。

事实上的标准：代理协议，在请求报文前面添加一行ASCII文本

PROXY TCP4 1.1.1.1 2.2.2.2 55555 80\r\n

proxy 域名版本 客户端IP 服务端IP 客户端端口 服务端端口

🚴‍♂️HTTPS中的摘要算法 — 验证数据完整性

前提：

HTTPS利用SSL/TSL协议为原有的HTTP协议添加了机密特性、数据完整性、身份认证、不可否认四个重要的特性。缺少其中的一个都不能保证通讯的安全。

对称加密：

加密和解密都使用同一份密钥，密钥的长度主要有128位、192位、256位，流行的对称加密算法有DES和AES算法

非对称加密：

和对称加密相反，非对称加密算法加密和解密使用的是有数学关联且不同的密钥，分别称为公钥和私钥。非对称加密大多数基于复杂的数学难题，密钥的长度主要有1024位、2056位，流行的非对称加密算法有DSA、RSA,ECC

优缺点：

对称加密的密钥长度位数比较短，优点是加密解密速度快，缺点是公钥和私钥相同，无法安全的传递公钥。

非对称加密，在同等安全强度要求下，密钥长度是对称加密密钥的几倍，加密解密运算比较消耗性能。优点是公钥私钥分离，解决了对称加密的缺点。

局限性：

单纯依赖加密算法，还不足以保证通讯的安全。一方面，中间人攻击通过收集足够多的通讯信息，重组修改后发给服务器，通过服务器的响应有几率反向解析出明文。另一方面，客户端获取到的公钥是攻击者恶意发布的，用户在不知情的情况下，个人信息可能会泄露。

摘要算法：

类似于浏览器缓存的Etag头部字段，可以把任意长度的数字转化为固定长度、独一无二的摘要字符串，且无法反向解析出原文。流行的摘要算法有SHA-1、SHA-2。

客户端或服务端，接收报文后，解密并计算出摘要算法，和发送过来的摘要对比，保证数据的完整性。

哈希消息认证码：摘要算法不具备加密性，为了避免摘要被修改，会捆绑报文和摘要一起加密打包。

🚴‍♂️HTTPS中的数字签名 — 签名、验签

签名：发送报文前，利用自己的私钥加密摘要算法生成的摘要字符串。

验签：接收报文后，利用对方的公钥解密摘要字符串密文，得到正确的摘要字符串

目标：避免客户端伪造，哈希信息认证码使用的加密密钥是服务器的公钥，攻击者如果获取到服务器
公钥，可以伪造客户端发送加密信息。服务端无法验证信息真实来源。

🚴‍♂️HTTPS中的数字证书 — CA

证书链的解析过程：

服务器返回的是证书链（不包括根证书，根证书预置在浏览器中），

然后浏览器就可以使用信任的根证书（根公钥）解析证书链的根证书得到一级证书的公钥+摘要验签，

然后拿一级证书的公钥解密一级证书拿到二级证书的公钥和摘要验签，

再然后拿二级证书的公钥解密二级证书得到服务器的公钥和摘要验签，验证过程就结束了。