网络
目录
1.15 HTTP协议如何实现像websocket那样实现双向通信?
2.3 TCP为什么连接的时候是三次握手,关闭的时候却是四次握手?【重要】
2.4 TCP挥手时为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态?
2.5 TCP如果已经建立了连接,但是客户端突然出现故障了怎么办?
4.1 在地址栏里输入一个URL,到这个页面呈现出来,中间会发生什么?【重要】
-
1 HTTP和HTTPS
-
1.1 HTTP和HTTPS
- (1)HTTP和HTTPS的基本概念
- HTTP: 超文本传输协议,是互联网上应用最为广泛的一种网络协议,是一个客户端和服务器端请求和应答的标准(TCP),用于从WWW服务器传输超文本到本地浏览器的传输协议,它可以使浏览器更加高效,使网络传输减少。
- HTTPS: 是以安全为目标的HTTP通道,简单讲是HTTP的安全版,即HTTP下加入SSL层,HTTPS的安全基础是SSL,因此加密的详细内容就需要SSL。———可进行加密传输和身份认证—
- HTTPS的SSL加密是在传输层实现的。
- HTTPS采用混合加密机制,将非对称和对称加密两种加密算法组合使用,充分利用各自的优点,博采众长。在交换公钥阶段采用非对称加密,在传输报文阶段使用对称加密。
- (2)HTTPS协议的工作原理——SSL建立的过程
- 如图
- 如图
- (1)HTTP和HTTPS的基本概念
-
-
-
-
- 1、客户端-->服务器:SSL的指定版本、加密组件(Cipher Suite)列表
- 客户端通过发送Client Hello报文开始SSL通信。报文中包含客户端支持的SSL的指定版本、加密组件(Cipher Suite)列表(所使用的加密算法及密钥长度等)。注意:客户端还会附加一个随机数,这里记为A。
- 2、服务器-->客户端:SSL版本以及选中的加密组件
- 服务器可进行SSL通信时,会以Server Hello报文作为应答。和客户端一样,在报文中包含SSL版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。注意:这里服务器同样会附加一个随机数,发给客户端,这里记为B。
- 3、服务器-->客户端:发公钥
- 之后服务器发送Certificate报文。报文中包含公开密钥证书。(具体的数字签名请看证书一节)
- 4、服务器-->客户端:Server Hello Done
- 最后服务器发送Server Hello Done报文通知客户端,最初阶段的SSL握手协商部分结束。
- 5、客户端:验证服务器证书
- SSL第一次握手结束后,客户端会对服务器发过来的证书进行验证,如果验证成功,解密取出证书中的公钥。(具体查看证书一节)
- 6、客户端-->服务器:公钥加密后面用到的对称密钥
- 接着,客户端以Client Key Exchange报文作为回应。报文中包含通信加密中使用的一种被称为Pre-master secret的随机密码串(后面用到的对称密钥)。该报文使用从证书中解密获得的公钥进行加密(其实就是服务器的公钥)。
- 7、客户端-->服务器:Change Cipher Spec报文,可以改为对称加密传输
- 客户端继续发送Change Cipher Spec报文。用于告知服务端,客户端已经切换到之前协商好的加密套件(Cipher Suite)的状态,准备使用之前协商好的加密套件加密数据并传输了。
- 8、客户端-->服务器:Finished报文,校验值。
- 客户端发送Finished报文。该报文包含连接至今全部报文的整体校验值(也就是HASH值),用来供服务器校验。
- 9、服务器-->客户端:私钥解密取出对称密钥,Change Cipher Spec报文
- 服务器接收到客户端的请求之后,使用私钥解密报文,把Pre-master secret(对称密钥)取出来。接着,服务器同样发送Change Cipher Spec报文。
- 10、服务器-->客户端:Finished报文,校验值。
- 服务器同样发送Finished报文,用来供客户端校验。
- 11、服务器<-->客户端:对称加密
- 服务器和客户端的Finished报文交换完毕之后,SSL连接就算建立完成。当然,通信会受到SSL的保护。从此处开始进行应用层协议的通信,即发送HTTP请求。应用层协议通信,即发送HTTP响应。
- 12、最后由客户端断开连接。断开连接时,发送close_notify报文。上图做了一些省略,这步之后再发送TCP FIN报文来关闭与TCP的通信。
- 1、客户端-->服务器:SSL的指定版本、加密组件(Cipher Suite)列表
- (3)HTTP和HTTPS的区别
- HTTPS协议需要CA证书,费用较高。
- HTTP是超文本传输协议,信息是明文传输,HTTPS则是具有安全性的SSL加密传输协议。
- 使用不同的链接方式,端口也不同,一般而言,HTTP协议的端口为80,HTTPS的端口为443
- HTTP的连接很简单,是无状态的;HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议,比HTTP协议安全。
- (4)HTTPS的缺点
- 1)消耗资源
- 通信两端都需要进行加密和解密,会消耗大量的CPU、内存等资源,增加了服务器的负载
- 2)访问速度慢
- 加密运算和多次握手降低了访问速度
- 3)页面调试难度加大
- 在开发阶段,加大了页面调试难度。由于信息都被加密了,所以用代理工具的话,需要先解密然后才能看到真实信息。
- 4)SSL证书需要花钱购买,功能越强大的证书费用越高。
- 5)SSL证书需要绑定IP,不能再同一个ip上绑定多个域名,ipv4资源支持不了这种消耗。
- 1)消耗资源
-
-
-
-
1.2说一下HTTP2.0
- HTTP2.0是基于1999年发布的HTTP1.0之后的首次更新。
- 特点:
- (1)二进制格式:HTTP2.0中所有加强性能的核心是二进制传输。
- 在应用层(HTTP2.0)和传输层(TCP or UDP)之间增加一个二进制分帧层。
- 在二进制分帧层上,HTTP2.0会将所有传输的信息分为更小的消息和帧,并采用二进制格式编码,其中HTTP1.x的首部信息会被封装到Headers帧,而Request Body则封装到Data帧。
- 在HTTP1.x中,我们是通过文本的方式传输数据。基于文本的方式传输数据存在很多缺陷,文本的表现形式有多样性,因此要做到健壮性考虑的场景必然有很多,
- (2)允许多路复用:
- 多路复用允许同时通过单一的HTTP/2连接发送多重请求-响应信息。改善了:在HTTP1.1中,浏览器客户端在同一时间,针对同一域名下的请求有一定数量限制(连接数量),超过限制会被阻塞。
- 这个功能相当于是长连接的增强,每个request请求可以随机的混杂在一起,接收方可以根据request的id将request再归属到各自不同的服务端请求里面,
- (3)服务器端推送
- (4)Header首部压缩
- (5)提升访问速度
- 相比HTTP1.0,请求资源所需时间更少,访问速度更快
- (6)更安全
- (1)二进制格式:HTTP2.0中所有加强性能的核心是二进制传输。
- HTTP1.x的主要缺点 / 推进HTTP2的原因
- (1)队列阻塞
- HTTP/1.0一次只允许在一个TCP连接上发起一个请求,HTTP/1.1使用的流水线技术也只能部分处理请求并发,仍然会存在队列头阻塞问题,因此客户端在需要发起多次请求时,通常会采用建立多连接来减少延迟。
- (2)单向请求,只能由客户端发起。
- (3)请求报文与响应报文首部信息冗余量大。
- (4)数据未压缩,导致数据的传输量大。
- (1)队列阻塞
-
-
-
1.3 HTTP1.0/1.1/2.0/3区别
- HTTP1.0:
- (1)无法长连接。
- 每次请求和响应都需要建立一个单独的TCP连接,每次连接只是传输一个文档和图像,上一次和下一次请求完全分离。服务器不跟踪每个客户也不记录过去的请求。
- (2)不支持只发送header信息(不能不带任何body信息),
- (3)HTTP1.0是没有host域的,HTTP1.1才支持这个参数。
- 在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址,因此,请求消息中的URL并没有传递主机名(hostname)。但随着虚拟主机技术的发展,在一台物理服务器上可以存在多个虚拟主机(Multi-homed Web Servers),并且它们共享一个IP地址。
- (1)无法长连接。
- HTTP 1.1
- (1)默认使用长连接,可有效减少TCP的三次握手开销。
- 增加新的请求头来帮助实现,例如,Connection请求头的值为Keep-Alive时,客户端通知服务器返回本次请求结果后保持连接;Connection请求头的值为close时,客户端通知服务器返回本次请求结果后关闭连接。
- (2)支持只发送header信息(可以不带任何body信息)。
- (3) HTTP1.1在Request消息头里头多了一个Host域
- 在HTTP 1.1中增加Host请求头字段后,WEB浏览器可以使用主机头名来明确表示要访问服务器上的哪个WEB站点,这才实现了在一台WEB服务器上可以在同一个IP地址和端口号上使用不同的主机名来创建多个虚拟WEB站点。
- (1)默认使用长连接,可有效减少TCP的三次握手开销。
- HTTP2.0
- (1)使用多路复用技术(Multiplexing),多路复用允许同时通过单一的 HTTP/2 连接发起多重的请求-响应消息。
- (2)HTTP/2新增首部压缩(Header Compression)
- (3)HTTP/2新增服务端推送(Header Compression)
- HTTP3【极少问到,但如果了解,是加分项】
- 采用基于UDP的QUIC(Quick UDP Internet Connection)协议
- HTTP1.0:
-
-
-
1.4 HTTP3.0【极少问到,但如果了解,是加分项】
- HTTP/3采用了QUIC协议。
- QUIC(Quick UDP Internet Connection)是谷歌制定的一种基于UDP的低时延的互联网传输层协议。
- QUIC融合了包括TCP,TLS,HTTP/2等协议的特性,但基于UDP传输。
- 为什么要推进HTTP3/QUIC协议
- HTTP/2仍然存在一些缺陷,这些缺陷并不是来自于HTTP/2协议本身,而是来源于底层的TCP协议,我们知道TCP链接是可靠的连接,如果出现了丢包,那么整个连接都要等待重传,HTTP/1.1可以同时使用6个TCP连接,一个阻塞另外五个还能工作,但HTTP/2只有一个TCP连接,阻塞的问题便被放大了。
- QUIC的一个主要目标就是减少连接延迟,当客户端第一次连接服务器时,QUIC只需要1RTT(Round-Trip Time)的延迟就可以建立可靠安全的连接,相对于TCP+TLS的1-3次RTT要更加快捷。之后客户端可以在本地缓存加密的认证信息,在再次与服务器建立连接时可以实现0-RTT的连接建立延迟。
- QUIC同时复用了HTTP/2协议的多路复用功能(Multiplexing),但由于QUIC基于UDP所以避免了HTTP/2的线头阻塞(Head-of-Line Blocking)问题。因为QUIC基于UDP,运行在用户域而不是系统内核,使得QUIC协议可以快速的更新和部署,从而很好地解决了TCP协议部署及更新的困难 。
- QUIC协议的机制:从TCP切换到UDP【了解】
- 机制一:自定义连接机制
- 一条tcp连接是由四元组标识的,分别是源ip、源端口、目的端口,一旦一个元素发生变化时,就会断开重连,重新连接。再次进行三次握手,导致一定的延时
- 在TCP是没有办法的,但是基于UDP,就可以在QUIC自己的逻辑里面维护连接的机制,不再以四元组标识,而是以一个64位的随机数作为ID来标识,而且UDP是无连接的,所以当ip或者端口变化的时候,只要ID不变,就不需要重新建立连接
- 机制二:自定义重传机制
- tcp为了保证可靠性,通过使用序号和应答机制,来解决顺序问题和丢包问题任何一个序号的包发过去,都要在一定的时间内得到应答,否则一旦超时,就会重发这个序号的包,通过自适应重传算法(通过采样往返时间RTT不断调整)
- 但是,在TCP里面超时的采样存在不准确的问题。例如发送一个包,序号100,发现没有返回,于是在发送一个100,过一阵返回ACK101.客户端收到了,但是往返的时间是多少,没法计算。是ACK到达的时候减去第一还是第二。
- QUIC也有个序列号,是递增的,任何宇哥序列号的包只发送一次,下次就要加1,那样就计算可以准确了
- 但是有一个问题,就是怎么知道包100和包101发送的是同样的内容呢?QUIC定义了一个offset概念。QUIC既然是面向连接的,也就像TCP一样,是一个数据流,发送的数据在这个数据流里面有个偏移量offset,可以通过offset查看数据发送到了那里,这样只有这个offset的包没有来,就要重发。如果来了,按照offset拼接,还是能够拼成一个流。
- 机制三: 无阻塞的多路复用
- 有了自定义的连接和重传机制,就可以解决上面HTTP2.0的多路复用问题
- 同HTTP2.0一样,同一条 QUIC连接上可以创建多个stream,来发送多个HTTP请求,但是,QUIC是基于UDP的,一个连接上的多个stream之间没有依赖。这样,假如stream2丢了一个UDP包,后面跟着stream3的一个UDP包,虽然stream2的那个包需要重新传,但是stream3的包无需等待,就可以发给用户。
- 机制四:自定义流量控制
- TCP的流量控制是通过滑动窗口协议。QUIC的流量控制也是通过window_update,来告诉对端它可以接受的字节数。但是QUIC的窗口是适应自己的多路复用机制的,不但在一个连接上控制窗口,还在一个连接中的每个steam控制窗口。
- 在TCP协议中,接收端的窗口的起始点是下一个要接收并且ACK的包,即便后来的包都到了,放在缓存里面,窗口也不能右移,因为TCP的ACK机制是基于序列号的累计应答,一旦ACK了一个序列号,就说明前面的都到了,所以是要前面的没到,后面的到了也不能ACK,就会导致后面的到了,也有可能超时重传,浪费带宽
- QUIC的ACK是基于offset的,每个offset的包来了,进了缓存,就可以应答,应答后就不会重发,中间的空档会等待到来或者重发,而窗口的起始位置为当前收到的最大offset,从这个offset到当前的stream所能容纳的最大缓存,是真正的窗口的大小,显然,那样更加准确。
- 机制一:自定义连接机制
-
-
-
1.5 HTTP请求和响应报文的组成部分(各有3个)
- 请求报文:请求方法URI协议/版本 + 请求头(Request Header) + 请求正文
- 请求报文:请求方法URI协议/版本 + 请求头(Request Header) + 请求正文
-
-
-
- 响应报文:状态行 + 响应头 + 响应正文
- 响应报文:状态行 + 响应头 + 响应正文
-
-
-
1.6 常见的HTTP的头部
- 可以将http首部分为通用首部,请求首部,响应首部,实体首部
- (1)通用首部表示一些通用信息,比如date表示报文创建时间,
- (2)请求首部就是请求报文中独有的,如cookie,和缓存相关的如if-Modified-Since
- (3)响应首部就是响应报文中独有的,如set-cookie,和重定向相关的location,
- (4)实体首部用来描述实体部分,如allow用来描述可执行的请求方法,content-type描述主题类型,content-Encoding描述主体的编码方式
- 可以将http首部分为通用首部,请求首部,响应首部,实体首部
-
-
-
1.7 常用的HTTP请求头(客户端发的)
- 协议头 | 说明
- Accept 可接受的响应内容类型(Content-Types)。
- eg: Accept: text/plain
- Accept-Charset 可接受的字符集
- Accept-Encoding 可接受的响应内容的编码方式。
- Accept-Language 可接受的响应内容语言列表。
- Accept-Datetime 可接受的按照时间来表示的响应内容版本
- Authorization 用于表示HTTP协议中需要认证资源的认证信息
- Cache-Control 用来指定当前的请求/回复中的,是否使用缓存机制。
-