https http2.0 http1.1 http1.0 tcp udp

一、HTTPS

大家可能都听说过 HTTPS 协议之所以是安全的是因为 HTTPS 协议会对传输的数据进行加密,而加密过程是使用了非对称加密实现。但其实,HTTPS 在内容传输的加密上使用的是对称加密,非对称加密只作用在证书验证阶段。

HTTPS的整体过程分为证书验证和数据传输阶段,具体的交互过程如下:

https http2.0 http1.1 http1.0 tcp udp_第1张图片

① 证书验证阶段

  1. 浏览器发起 HTTPS 请求
  2. 服务端返回 HTTPS 证书
  3. 客户端验证证书是否合法,如果不合法则提示告警

② 数据传输阶段

    1.当证书验证合法后,在本地生成随机数

    2.通过公钥加密随机数,并把加密后的随机数传输到服务端

    3.服务端通过私钥对随机数进行解密

    4.服务端通过客户端传入的随机数构造对称加密算法,对返回结果内容进行加密后传输

 

# 为什么数据传输是用对称加密?

首先,非对称加密的加解密效率是非常低的,而 http 的应用场景中通常端与端之间存在大量的交互,非对称加密的效率是无法接受的;

另外,在 HTTPS 的场景中只有服务端保存了私钥,一对公私钥只能实现单向的加解密,所以 HTTPS 中内容传输加密采取的是对称加密,而不是非对称加密。

 

# 为什么需要 CA 认证机构颁发证书?

HTTP 协议被认为不安全是因为传输过程容易被监听者勾线监听、伪造服务器,而 HTTPS 协议主要解决的便是网络传输的安全性问题。

首先我们假设不存在认证机构,任何人都可以制作证书,这带来的安全风险便是经典的“中间人攻击”问题。


“中间人攻击”的具体过程如下:https http2.0 http1.1 http1.0 tcp udp_第2张图片

过程原理:

1.本地请求被劫持(如DNS劫持等),所有请求均发送到中间人的服务器

2.中间人服务器返回中间人自己的证书

3.客户端创建随机数,通过中间人证书公钥对随机数加密后传送给中间人,然后凭随机数构造对称加密对传输内容进行加密传输

4.中间人因为拥有客户端的随机数,可以通过对称加密算法进行内容解密

5.中间人以客户端的请求内容再向正规网站发起请求

6.因为中间人与服务器的通信过程是合法的,正规网站通过建立的安全通道返回加密后的数据

7.中间人凭借与正规网站建立的对称加密算法对内容进行解密

8.中间人通过与客户端建立的对称加密算法对正规内容返回的数据进行加密传输

9.客户端通过与中间人建立的对称加密算法对返回结果数据进行解密

由于缺少对证书的验证,所以客户端虽然发起的是 HTTPS 请求,但客户端完全不知道自己的网络已被拦截,传输内容被中间人全部窃取。

 

二、HTTP1.0 HTTP 1.1主要区别

      1.1 长链接

            HTTP 1.0需要使用keep-alive参数来告知服务器端要建立一个长连接,而HTTP1.1默认支持长连接。

            HTTP是基于TCP/IP协议的,创建一个TCP连接是需要经过三次握手的,有一定的开销,如果每次通讯都要重新建立连接的话,对性能有影响。因此最好能维持一个长连接,可以用个长连接来发多个请求。


      1.2 节约带宽

          HTTP 1.1支持只发送header信息(不带任何body信息),如果服务器认为客户端有权限请求服务器,则返回100,否则返回401。客户端如果接收到100,才开始把请求body发送到服务器。

            这样当服务器返回401的时候,客户端就可以不用发送请求body了,节约了带宽。

           另外HTTP还支持传送内容的一部分。这样当客户端已经有一部分的资源后,只需要跟服务器请求另外的部分资源即可。这是支持文件断点续传的基础
       

     1.3HOST域

        现在可以web server例如tomat,设置虚拟站点是非常常见的,也即是说,web server上的多个虚拟站点可以共享同一个ip和端口。

        HTTP1.0是没有host域的,HTTP1.1才支持这个参数。

 

三、 HTTP 1.1、HTTP2.0主要区别

    2.1  多路复用

         HTTP2.0使用了多路复用的技术,做到同一个连接并发处理多个请求,而且并发请求的数量比HTTP1.1大了好几个数量级。

         当然HTTP1.1也可以多建立几个TCP连接,来支持处理更多并发的请求,但是创建TCP连接本身也是有开销的。

          TCP连接有一个预热和保护的过程,先检查数据是否传送成功,一旦成功过,则慢慢加大传输速度。因此对应瞬时并发的连接,服务器的响应就会变慢。所以最好能使用一个建立好的连接,并且这个连接可以支持瞬时并发的请求。
 

     2.2  数据压缩

       HTTP1.1不支持header数据的压缩,HTTP2.0使用HPACK算法对header的数据进行压缩,这样数据体积小了,在网络上传输就会更快。

    2.3  服务器推送

         当我们对支持HTTP2.0的web server请求数据的时候,服务器会顺便把一些客户端需要的资源一起推送到客户端,免得客户端再次创建连接发送请求到服务器端获取。这种方式非常合适加载静态资源。

       服务器端推送的这些资源其实存在客户端的某处地方,客户端直接从本地加载这些资源就可以了,不用走网络,速度自然是快很多的。
 

       https http2.0 http1.1 http1.0 tcp udp_第3张图片

           服务端推送过来的资源,会统一放在一个网络与http缓存之间的一个地方,在这里可以理解为“本地”。当客户端把index.html解析完以后,会向本地请求这个资源。由于资源已经本地化,所以这个请求的速度非常快,这也是服务端推送性能优势的体现之一。

四、TCP与UDP

1.TCP三次握手


【1】TCP三次握手:为了对每次发送的数据量进行跟踪与协商,确保数据段的发送和接收同步,根据所接收到的数据量而确认数据发送、接收完毕后何时撤消联系,并建立虚连接。
  第一次握手:建立连接时,客户端发送 syn(Synchronize Sequence Numbers:同步序列编号)包(seq=j)到服务器,并进入SYN_SEND(请求连接)状态,等待服务器确认。


  第二次握手:服务器接收到 syn包,必须确认客户的 SYN(ack=j+1)(ack:确认字符,表示发来的数据已确认接收无误),同时自己也发送一个 syn包(seq=k),既 SYN+ACK 包,此时服务器进入SYN_RECV(发送了ACK)状态。


  第三次握手:客户端收到服务端发送的 SYN+ACK 包,向服务端发送确认包 ACK(ack=k+1),包发送完毕,客户端与服务器进入 ESTABLISHED(TCP连接成功)状态,完成三次握手。


        https http2.0 http1.1 http1.0 tcp udp_第4张图片
                        图1: TCP三次握手图

2.TCP四次挥手(连接终止协议,性质为终止协议):


  第一次挥手:TCP客户端发送一个FIN+ACK+SEQ,用来传输关闭客户端到服务端的数据。进入FIN_WAIT1状态。


  第二次挥手:服务端收到FIN,被动发送一个ACK(SEQ+1),进入CLOSE_WAIT状态,客户端收到服务端发送的ACK,进入FIN_WAIT2状态。


  第三次挥手:服务器关闭客户端连接,发送一个 FIN+ACK+SEQ 给客户端。进入 LAST_ACK 状态。


  第四次挥手:客户端发送 ACK(ACK=SQE序号+1)报文确认,客户端进入 TIME_WAIT 状态,服务端收到 ACK 进入 CLOSE状态。


                 https http2.0 http1.1 http1.0 tcp udp_第5张图片
                            图2: TCP四次挥手

由于TCP连接是双向的,因此每个方向都需要单独进行关闭。原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个FIN只意味着这一个方向上没有数据流动,一个 TCP连接到一个 FIN后仍能发送数据。首次执行FIN的一方主动关闭,另一方则执行被动关闭。当只握手两次时,就只会关闭主动发起的一端,另一个仍能发送数据。

3.TIME_WAIT 和 CLOSE_WAIT的区别


CLOSE_WAIT:等待关闭,是被动关闭连接形成的,也就是第二次挥手时产生的状态。也就是当对方 Close 一个 SOCKET 后发送 FIN 报文给自己,系统会回应一个 ACK 报文给对方,此时进入CLOSE_WAIT状态。接着,我们需要考虑的事情是查看是否还有数据发送给对方,如果没有就可以 Close 这个链接,发送 FIN 给对方,也既关闭连接。所以在 CLOSE_WAIT 状态时,需要查看自己是否需要关闭连接。
TIME_WAIT:是主动关闭连接方形成的,表示收到了对方的 FIN 报文,并发送 ACK 报文,等待 2MSL(Maximum Segment Lifetime:报文最大生存时间)约4分钟时间后进入 CLOSE 状态。主要是防止最后一个 ACK 丢失,由于 TIME_WAIT 等待时间较长,因此 server 端尽量减少关闭。

4.为什么需要 TIME_WAIT 状态


假设最终的 ACK 丢失,服务器将重新发送 FIN,客户端必须维护 TCP 状态信息以便可以重发最终的 ACK,否则发送 RST结果Server 认为发生错误。TCP 实现必须可靠的终止两端的连接(双工关闭),Client 必须进入TIME_WAIT 状态,因为最总的ACK可能发送失败。

5.为什么 TIME_WAIT 状态要保持 2MSL 这么长时间
如果 TIME_WAIT 状态保持时间不足2MSL,第一个连接可以正常关闭,但如果有相同的第二个连接出现,第一个连接的重复报文到达,就会干扰第二个连接。TCP 必须防止某个连接的重复报文在连接终止后出现,所以让 TIME_WAIT 状态等待时间大于2MSL,连接响应方向上的 TCP 报文要么完全响应完毕,要么被丢弃。建立二次连接时,就不会混淆。

6.说说你知道的几种 HTTP 响应码


【1】200 OK:表示客户端请求成功。
【2】400 Bad Request 语义有误:不能被当前服务器理解。
【3】401 Unauthorized: 当前请求需要用户验证。
【4】403 Forbidden: 服务器收到消息,但是拒绝提供服务。
【5】404 Not Found :请求资源不存在。
【6】408 Request Timeout: 请求超时,客户端没有在服务器预备等待的时间内完成发送。
【7】500 Internal Server Error: 服务器发生不可预期的错误。
【8】503 Server Unavailable :由于临时的服务器维护或过载,服务器当前不能处理请求,此状况知识临时的,可恢复。
【9】301 Moved Permanently:永久性重定向,表示请求的资源被分配了新的URL,之后应使用更改的URL;
【10】302 Found:临时性重定向,表示请求的资源被分配了新的URL,希望本次访问使用新的URL;

 

7.当你用浏览器打开一个链接的时候,计算机做了哪些工作步骤


1)、解析域名。
2)、发起 TCP 的 3 次握手。
3)、建立 TCP 请求后发起 HTTP 请求。
4)、服务器相应 HTTP 请求。
5)、浏览器得到 HTML 代码,进行解析和处理 JSON 数据,并请求 HTML 代码中的静态资源(JS、CSS、图片等)。
6)、浏览器对页面进行渲染。

8.TCP与UDP:

 1、基于连接与无连接;

 2、对系统资源的要求(TCP较多,UDP少);

 3、UDP程序结构较简单;

 4、流模式与数据报模式 ;

 5、TCP保证数据正确性,UDP可能丢包;

 6、TCP保证数据顺序,UDP不保证。

 

 

你可能感兴趣的:(https http2.0 http1.1 http1.0 tcp udp)