01 HTTP协议相关

01 HTTP协议相关

应用层常见协议

  • 超文本传输:HTTP、HTTPS
  • 文件传输:FTP
  • 电子邮件:SMTP、POP3、IMAP
  • 动态主机配置:DHCP
  • 域名系统:DNS

1.1 DNS

根据等级不同,域名可以分为

  • 顶级域名(Top-level Domain,简称TLD)
  • 二级域名
  • 三级域名
  • … …

1.1.1 顶级域名分类

  • 通用顶级域名(General Top-level Doman,简称gTLD)

.com 公司, .net 网络机构, .org 组织机构, .edu 教育

.gov 政府部门, int 国际组织,等。

  • 国家及地区顶级域名(Country Code Top-level Domain,简称ccTLD)

.cn 中国, .jp 日本, .uk 英国

  • 新通用顶级域名(New gTLD)

.vip.xyz.top.club.shop 等。

二级域名:

  • 在通用顶级域名之下,一般指域名注册人的名称。如Google和Baidu等。
  • 在国家及地区顶级域名下,一般指注册类别,例如com、edu、gov、net等。

1.1.2 DNS协议

DNS全称是:Domain Name System,译为:域名系统。利用DNS协议,可以将域名解析称对应的IP地址。

DNS可以基于UDP,也可以基于TCP,服务器占用53端口

1.2.3 DNS服务器

  • 客户端首先回访问最近的一台DNS服务器(也就是客户端自己配置的DNS服务器)。
  • 所有的DNS服务器都记录了DNS根域名服务器的IP地址。
  • 上级DNS服务器记录了下一级DNS服务器的IP地址。
  • 全球一共13台IPv4的DNS根域名服务器,25台IPv6的DNS根域名服务器。

1.2 DHCP

IP地址的分配方式:

  • 静态IP地址:手动设置。适用于不怎么挪动的台式机、服务器。
  • 动态IP地址:从DHCP服务器自动获取IP地址,适用于移动设备、无线设备。

DHCP(Dynamic Host Configuration Protocol),译为:动态主机配置协议。

DHCP协议基于UDP,客户端时68端口,服务器时67端口。

DHCP服务器会从IP地址池中,挑选一个IP地址”出租“给客户端一段事件,时间到期就回收它们。

1.2.1 DHCP分配IP地址的4个阶段

  • DISCOVER:发现服务器

发广播包(源IP是0.0.0.0,目标IP是255.255.255.255,目标MAC是FF:FF:FF:FF)。

  • OFFER:提供租约

服务器返回可以租用的IP地址,以及租用期限、子网掩码、王国、DNS等信息。

注意:这里有可能会有多个服务器提供租约。

  • REQUEST:选择IP地址

客户端先择一个OFFER,发送广播包进行回应

  • ACKNOWLEDGE:确认

被选中的服务器发送ACK数据包给客户端。

DHCP服务器是可以跨网段分配IP地址的,可以借助DHCP中继代理(DHCP Relay Agent)实现跨网段分配IP地址。

自动续约:客户端会在租期不足的时候,自动像DHCP服务器发送REQUEST信息申请续约。

1.3 HTTP

HTTP(Hyper Text Transfer Protocol),超文本传输协议。

是互联网中应用最广发的应用层协议之一,涉及HTTP最初的目的是提供一种发布和接收HTML页面的方法,由URI来标识具体的资源。

后面用HTTP来传递的数据格式不仅仅是HTML,应用非常广泛。

HTML(Hyper Text Markup Language),超文本标记语言。用于编写网页。

1.3.1 HTTP版本

  • 1991年,HTTP/0.9

只支持GET请求方法获取文本数据(比如HTML文档),且不支持请求头、响应头等,无法向服务器传递太多信息。

  • 1996年,HTTP/1.0

支持POST、HEAD等请求方法,支持请求头、响应头等,支持更多种数据类型。浏览器每次请求都需要与服务器建立一个TCP连接,请求处理完成后立即断开TCP连接。

  • 1997年,HTTP/1.1

支持PUT、DELETE等请求方法,采用持久连接,多个请求可以共用一个TCP连接。

  • 2015年,HTTP/2.0。
  • 2018年,HTTP/3.0。

1.3.2 HTTP报文格式

  • 请求报文

方法【空格】URL【空格】版本【回车换行】 //请求行

首部字段:【空格】值【回车换行】 //首部行

… …

首部字段:【空格】值【回车换行】

【回车换行】

实体主体

  • 响应报文

版本【空格】状态码【空格】短语【回车换行】 //状态行

首部字段:【空格】值【回车换行】 //首部行

… …

首部字段:【空格】值【回车换行】

【回车换行】

实体主体

ABNF(Augmented BNF)

  • 是BNF(Backus-Naur Form,译为巴科斯-瑙尔范式)的修改、增强版;
  • 在RFC 5234文档中表明:ABNF左右Internet中通信协议的定义语言;
  • ABNF是最严谨的HTTP报文格式描述形式,脱离ABNF谈论HTTP报文格式,往往都是片面的、不严谨的。
HTTP-message = start-line
			   *(header-field CRLF)
			   CRLF
			   [message-body]
			   
------------------------------------------
header-field = field-name":" OWS field-value OWS
field-name = token
field-value = *(field-content/obs-fold)
------------------------------------------
message-body = *OCTET  (OCTET指一个字节)
########################################
/	任选一个;
*	0个或多个,2*表示至少2个;
()	组成一个整体;
[]	可有可无的选项。
OWS = *(SP/HTAB)

start-line:开始行,start-line = request-line/status-line;

start-line是内置的CRLF。

请求行:

# SP = 空格    DIGIT = 数字
# %x48.54.54.50 = HTTP
request-line = method SP request-target SP HTTP-version CRLF
HTTP-version = HTTP-name"/"DIGIT"."DIGIT
HTTP-name = %x48.54.54.50

状态行:

# HTAB = Tab   VCHAR = 字符串
status-line = HTTP-version SP status-code SP reason-phrase CRLF
status-code = 3DIGIT
reason-phrase = *(HTAB/SP/VCHAR/obs-text)

1.3.3 请求方法

8种请求方法:GETHEADPOSTPUTDELETECONNECTOPTIONSTRACE;

额外的1种:PATCH

  • GET:常用于读取操作,请求参数直接拼接再URL后面(浏览器对URL长度是有限制的)。
  • POST:常用于添加、修改、删除的操作,请求阐述剋放到请求体中(没有长度限制)。
  • HEAD:请求得到与GET相同的响应,但是没有响应体。(使用场景,在下载文件前先获取其大小,再决定是否要下载)。
  • OPTIONS:用于获取目的资源所支持的通信选项,比如服务器支持的请求方法
  • PUT:用于已存在的资源进行整体覆盖(不安全,已经不怎么用了)。
  • PATCH:用于对资源进行部分修改(资源不存在,会创建新的资源)。
  • DELETE:用于删除指定的资源。
  • TRACE:请求服务器回显其收到的请求信息,主要用于HTTP请求的测试或诊断。
  • CONNECT:可以开启一个客户端与所请求资源之间的双向沟通的通道,它可以用来创建隧道(tunnel)可以用来访问采用了SSL(HTTPS)协议的站点。

1.3.4 头部字段

头部字段可以分为4种类型:

  • 请求头字段(Request Header Fields):有关要获取资源或客户端本身的消息头。
  • 响应头字段(Response Header Fields):有关响应的补充信息,比如服务器本身(名称和版本等)的消息头。
  • 实体头字段(Entity Header Fields):有关实体主题的更多信息,比如主题长度(Content-Length)或其MIME类型。
  • 通用头字段(General Header Fields):同时适用于请求和响应消息,但与消息主体无关的消息头。
  • 请求头字段(Request Header Fields)
头字段 说明
User-Agent 浏览器的身份标识字符串
Host 服务器的域名、端口号
Date 发送该消息的日期和时间
Referer 表示浏览器所访问的前一个页面。(防盗链)
Content-Type 请求体的类型
Content-Length 请求体的长度(字节为单位)
Accept 能过接受的响应内容类型(Content-Types)
Accept-Charset 能够接受的字符集
Accept-Encoding 能够接受的编码方式列表
Accept-Language 能够接受的响应内容的自然语言列表
Range 仅请求某一个实体的一部分。字节偏移以0开始(多线程断点下载)
Origin 发起一个针对跨域资源共享的请求
Cookie 之前由服务器通过Set-Cookie发送过来的Cookie
Connection 该浏览器想要优先使用的连接类型
Cache-Control 用来指定这次请求/响应中的缓存机制指令
  • 响应头字段(Response Header Fields)
头字段 说明
Data 发送该消息的日期和时间
Last-Modified 所请求对象的最后修改日期
Server 服务器的名字
Expires 指定一个时间,超过改时间则认为此响应已经过期
Content-Type 响应体类型
Content-Encoding 内容使用的编码类型
Content-Length 响应体的长度
Content-Disposition 一个可以让客户端下载文件并建议文件名的头部
Accept-Range 服务器支持那些种类的部分内容范围
Content-Range 这部分消息是属于完整消息的那部分
Access-Control-Allow-Origin 指定那些网站可参与带跨域支援共享过程中
Location 用来重定向,或者在建立某个新资源时使用
Set-Cookie 返回一个Cookie让客户端去保存
Connection 针对改连接所预期的选项
Cache-Control 缓存机制告知是否可以缓存该对象,时间单位秒

1.3.5 状态码

状态码指示HTTP请求是否已经成功完成,状态码可以分为5类:

  • 信息响应:100-199
  • 成功响应:200-299
  • 重定向:300-399
  • 客户端错误:400-499
  • 服务器错误:500-599

常见状态码:

  • 100:continue (请求的初始部分已经被服务器收到,并且没有被服务器拒绝。客户端应该继续发送剩余的请求,如果请求已经完成,就忽略这个响应)。
  • 200:OK (请求成功)。
  • 302:Found (重定向,请求的资源暂时被移动到了由Location头部指定的URL上)。
  • 304:Not Modified (说明无需再次传输请求的内容,也就是说可以使用缓存的内容)。
  • 400:Bad Request (由于语法无效(由开发人员设置主动发400),服务器无法理解该请求)。
  • 401:Unauthorized (由于缺乏目标资源要求的身份验证凭证)。
  • 403:Forbidden (服务器端由能力处理该请求,但是拒绝授权访问)。
  • 404:Not Found (服务器端无法找到所请求的资源)。
  • 405:Method Not Allowed (服务器禁止了使用当前HTTP方法的请求)。
  • 406:Not Acceptable (服务器端无法提供与Accept-Charset以及Accept-Language指定的值相匹配的响应)。
  • 408:Req Timeout (服务器想要将没有在使用的连接关闭)。
  • 500:Internal Server Error (所请求的服务器遇到意外的情况并阻止其执行请求)。
  • 501:Not Implemented (请求的方法不被服务器支持,因此无法被处理,服务器必须支持的方法GET和HEAD不会返回这个状态码)。
  • 502:Bad Gateway (作为网关或代理角色的服务器,从上游服务器中收到的响应是无效的)。
  • 503:Service Unavailable (服务器尚未处于可以接收请求的状态,通常造成这种情况的原因市由于服务器停机维护或者已超载)。

1.3.6 表单提交 Form

常用属性

  • action:请求的URI。

  • method:请求的方法(GET、POST)。

  • enctype:POST请求时,请求体的编码方式(默认值:application/x-www-urlencoded:用&分隔参数,用=分隔键和值,字符用URL编码方式进行编码)。

    (multipart/form-data:适用于复杂的内容提交,请求头会多一个boundary,请求体会被boundary包围,然后分块,文件上传必须使用这种方式。)

1.4 跨域 CORS

前后端分离:从形式上来说,就是前端和后端的内容分离出来,作为两个项目分别开发。跨域受同源策略影响,规定默认情况下,AJAX请求只能发送给同源的URL(同源是指三个相同:协议、域名(IP),端口)。

跨域资源共享

  • 解决AJAX跨域请求的常用方法

CORS (Cross-Origin Resoure Sharing),跨域资源共享。

  • CORS的实现需要客户端和服务端同时支持
  • 客户端

    所有的浏览器都支持(IE至少IE10版本)。

  • 服务端

    需要返回响应的响应头(比如Access-Control-Allow-Origin)。

    告知浏览器这是一个允许跨域访问的请求。

1.5 Cookie 和 Session

  • Cookie:在客户端(浏览器)存储一些数据,服务器可以返回Cookie交给客户端去存储,存储到本地磁盘中。
  • Session:在服务器存储一些数据,一般存在内存中。

Cookie身份验证过程:

  • 登录成功后,服务器,创建一个Session,存储一个id和用户信息,并通过响应头Set-Cookie:JSEESIONID=xxx发送给客户端;

  • 客户端收到响应头的内容后会将Cookie:JSEESIONID=xxx的信息存储起来,Cookie中一般会带有两个字段(domain和path,一般由服务器设置),作用是将来请求那些路径时会携带cookie。

  • 客户端下次直接请求内容页面时,发现Cookie中的domain和path与请求的相同,就会在请求头中携带cookie。

  • 服务器收到请求头后检查cookie,发现携带有会话id,然后去Session匹配,匹配成功后,即通过身份验证。

这种技术常常用于会话跟踪。

1.6 代理 (Proxy)和 CDN

代理服务器(Proxy Server)

  • 本身不产生内容;
  • 处于中间位置转发上下游的请求和响应;
  • 面向下游的客户端:它是服务器;
  • 面向上有的服务器;它是客户端。

1.6.1 正向代理和反向代理

  • 正向代理:代理的对象是客户端;
  • 反向代理:代理的对象是服务器。

正向代理:

  • 隐藏客户端身份;
  • 绕过防火墙(突破访问限制);
  • Internet访问控制;
  • 数据过滤。

反向代理:

  • 隐藏服务器身份;
  • 安全防护;
  • 负载均衡。

1.6.2 代理服务器相关头部字段

略。

1.6.3 CDN 内容分发网络

CDN(Content Delivery Network 或 Content Distributed Network),译为:内容分发网络。

CDN:利用最靠近每位用户的服务器,更快更可靠地将音乐、图片、视频等资源文件(一般是静态资源)传递给用户。

1.7 网络通信中面临地4中安全威胁

被动攻击:

截获:被窃听通信内容。

主动攻击:

中断:中断网络通信。

篡改:篡改通信内容。

伪造:伪造通信内容。

1.7.1 网络层-ARP欺骗

ARP欺骗(ARP spoofing),又称ARP毒化(ARP poisoning)、ARP病毒、ARP攻击。

  • ARP欺骗可以造成地效果:
    • 可以让攻击者获取局域网上地数据包甚至可篡改数据包;
    • 可让网络上特定电脑之间无法正常通信(例如网络执法官这样地软件);
    • 让送至特定IP地址地流量被错误送到攻击者所取代地地方

ARP欺骗的核心步骤:

  • 假设主机C是攻击者,主机A、B是被攻击者;
  • C只要收到过A、B发送的ARP请求,就会拥有A、B的IP、MAC地址,就可以进行欺骗活动;
  • C发送一个ARP响应给B,把相应包里的源IP设置为A的IP地址,源MAC设为C的MAC地址;
  • B收到ARP响应后,更新它的ARP表,把A的MAC地址(IP_A,MAC_A)改为(IP_A,MAC_C);
  • 当B要发送数据包给A时,根据此包的目标MAC地址MAC_C,就会把数据包发送给C;
  • C收到数据包后,可以把它存起来后在发送给A,达到窃听效果。C也可以篡改数据后在发送给A。

ARP欺骗的防护:

  • 静态ARP;
  • DHCP Snooping:
    • 网络设备可由DHCP保留网络上各个电脑的MAC地址,在伪造的ARP数据包发出时即可侦测到。
  • 利用一些软件监听ARP的不正常变动

1.7.2 DoS、DDoS

  • DoS攻击(拒绝服务攻击,Denial-of-Service attack)

使目标电脑的网络或系统资源耗尽,使服务中断或停止,导致器正常用户无法访问。

  • DDoS攻击(分布式拒绝服务攻击,Distributed Denial-of-Service attack)

黑客使用网络上两个或以上被贡献的电脑作为“僵尸”向特定的目标发动DoS攻击。

DoS分类:

  • 带宽消耗型:UDP洪水攻击、ICMP洪水攻击。
  • 资源消耗型:SYN洪水攻击、LAND(局域网拒绝服务攻击)攻击。
    • LAND攻击:通过持续发送相同源地址和目标地址的欺骗数据包,使目标试图与自己建立连接,消耗系统资源直至崩溃。

1.7.3 DNS劫持

  • DNS劫持:又称域名劫持
  • 攻击者篡改了某个域名的解析结果,是的指向改域名的IP变成了另一个IP。
  • 导致相对应万只的访问被劫持到另一个不可达的或者假冒的网址。
  • 从而实现非法窃取用户信息或者破坏正常网络服务的目的。
  • HTTP劫持:对HTTP数据包进行拦截处理,比如插入JS代码。

1.8 HTTP协议的安全问题

  • HTTP协议默认是采用明文传输的,因此会有很大的安全隐患。
  • 常见加密方式:

不可逆:单向散列函数:(MD5、SHA等)。

可逆:对称加密(DES、3DES、AES等)、非对称加密(RSA等)。

其他:混合密码系统、数字签名、证书。

  • 网络上的密码通信所用的SSL/TLS都运用了混合密码系统。

1.8.1 混合密码

混合密码的加密过程:

  • 会话密钥:为本次通信随机生成的临时密钥,作为对称加密的密钥,用于加密消息,提高速度。

  • 加密步骤:

(1)伪随机数生成器,生成会话密钥;

(2)用会话密钥对称加密明文;

(3)用接收者的公钥加密会话密钥;

(4)将密文和加密的密钥组合发送给接收者;

混合密码的解密过程:

  • 加密过程的逆过程,先用私钥解出会话密钥,在对密文进行解密。

1.8.2 数字签名

为了确定消息的真实性,识别篡改、伪装、否认。

要求:内容无所谓被窃听,但是要求来源可信。

数字签名的行为:

  • 生成签名:由消息的发送者完成,通过**“签名密钥”**生成;
  • 验证签名:由消息的接收者完成,通过**“验证密钥”**验证。

消息构成:消息+签名;

  • 签名用消息发送者的私钥进行 签名 (保证不会被伪造);
  • 接收者用发送者的公钥解密签名与消息内容比对即可。
  • 由于消息可能很大,所以一般使用消息的单向散列值进行签名验签时同样与消息的单向散列值比对。

1.8.3 证书

公钥的合法性:如果遭遇了中间人攻击,那么公钥将可能时伪造的。

如何验证公钥的合法性?——证书。

密码学中的证书,全称叫公钥证书(Pub-key Certificate,PKC)

  • 证书里有姓名、邮箱等个人信息,以及此人的公钥,还有CA的数字签名;
  • 由认证机构(Certificate Authority,CA)施加数字签名;
  • CA就是能够认定**“公钥确实属于此人”**并能够生成数字签名的个人或组织。

1.9 HTTPS

HTTPS(HyperText Transfer Protocol Secure),译为,超文本传输安全协议。

常称为 HTTP over TLS、 HTTP over SSL、 HTTP Secure。

HTTPS默认端口是443(HTTP是80)。

1.9.1 SSL/TLS

  • HTTPS是在HTTP的基础上使用SSL/TLS来加密报文,对窃听和中间人攻击提供合理的防护。
  • SSL/TLS也可以使用在其他协议上,如:FTP----FTPS、SMTP----SMTPS。
  • TSL(Transport Layer Security),译为:传输层安全性协议;
  • 前身是SSL(Secure Sockets Layer),译为:安全套接层。

SSL/TLS——工作在那一层?

SSL/TLS工作在应用层和传输层之间,SSL/TLS本身又分为HandShake Layer和Record Layer:

  • HandShake Layer:包含HandShake、Change CipherSpec、Alert靠近应用层;
  • Record Layer:包含一个Record靠近传输层。

OpenSSL:是SSL/TLS协议的开源实现。

HTTPS的通信过程:

  • TCP的三次握手;
  • TLS的连接;
  • HTTP请求和响应。

1.9.2 TLS 1.2的连接

连接过程:(其中省略了大量的ACK确认)

(0)Client Client Hello >> Server

(1)Client << Server Hello Server

(2)Client << Certificate Server

(3)Client << Server Key Exchange Server

(4)Client << Server Hello Done Server

(5)Client Client Key Exchange >> Server

(6)Client Change Cipher Spec >> Server

(7)Client Finished >> Server

(8)Client << Change Cipher Spec Server

(9)Client << Finished Server

(0)Client Client Hello >> Server:

TLS版本号;

支持的加密组件(Cipher Suite)列表(加密组件是指所使用的加密算法及密钥长度等);

一个随机数(Client Random)。

(1)Client << Server Hello Server:

TLS版本号;

选择的加密套件(从列表里选一个);

一个随机数(Server Random);

(2)Client << Certificate Server:

服务器的公钥证书(被CA签名过的)

(3)Client << Server Key Exchange Server:

用以实现ECDHE算法的其中一个参数(Server Params),ECDHE是一种密钥交换算法;

为了防止伪造Server Params是被签名过的。

(4)Client << Server Hello Done Server: (以上全部为明文发送)

告知客户端:协商部分结束。

(5)Client Client Key Exchange >> Server:

用以实现ECDHE算法的另一个参数(Client Params)。

客户端和服务端根据Server Params和Client Params利用ECDHE算法计算出一个新的随机密钥串:Pre-master secret。

然后结合Client Random和Server Random以及Pre-master secret生成用以加密会话的会话密钥。

(6)Client Change Cipher Spec >> Server:

告知服务器:之后的通信会采用计算出来的会话密钥进行加密。

(7)Client Finished >> Server:

包含连接至今的全部报文的整体校验值(摘要),加密之后发送给服务器。

这次握手协商是否能成功,要以服务器是否能够正确解密该报文作为判断标准。

(8)Client << Change Cipher Spec Server:

(9)Client << Finished Server:

到此为止,客户端和服务器都验证加密解密没问题,握手正式结束;

后面开始传输加密的HTTP请求和响应。(与前边的对称)。

1.9.3 HTTP改进

HTTP协议的不足(HTTP/1.1)

  • 同一个时间,一个连接自能对应一个请求;
  • 针对同一个域名,大多数浏览器只允许同时最多6个并发连接;
  • 只允许客户端主动发起请求;
  • 一个请求只能对应一个响应;
  • 同一个会话的多次请求中,头信息会被重复传输。

SPDY

SPDY(speedy的缩写),是基于TCP的应用层协议,它强制要求使用SSL/TLS;

SPDY与HTTP的关系:

SPDY并不是用于取代HTTP,它只是修改了HTTP请求与响应的传输方式;

			            HTTP         SPDY
			       +------------+------------+
			       |            |    HTTP    |
			       |            +------------+
			       |    HTTP    |    SPDY    |
			       |            +------------|
Application Layer  |            |     TLS    |
-------------------+------------+------------+
Transport Layer    |     TCP    |     TCP    |
-------------------+------------+------------+
Internet Layer     |     IP     |     IP     |
			       +------------+------------+

只需要增加一个SPDY层,现有的所有服务均不用修改。

SPDY是HTTP/2的前身,现在已经停止对SPDY的支持了,采用HTTP/2.

HTTP/2

  • HTTP/2在底层传输做了很多改进和优化,但是在语义上完全与HTTP/1.1兼容;
  • 比如请求方法(如GET、POST)、Status Code、各种Headers等都没有改变;
  • 因此升级到HTTP/2,只需要升级服务器和浏览器的配置即可,无需修改代码。
  • HTTP/2不强制要求使用SSL/TLS。

HTTP/2的特性——二进制格式

  • HTTP/2采用二进制格式传输数据,而非HTTP/1.1的文本格式;

  • 头部信息转成头部帧,数据部分转换成数据帧。

HTTP/2的特性——基本概念

  • 数据流:已经建立的连接内的双向字节流可以承载一条或多条消息:
    • 所有通信都在一个TCP连接上完成,此连接可以承载任意数量的双向数据流。
  • 消息:与逻辑HTTP请求或响应消息对应,有一系列帧组成。
  • 帧:HTTP/2通信的最小单位,每个帧都包含帧头(会标识出当前帧所属的数据流):
    • 来自不同数据流的帧可以交错发送,然后再根据每个枕头的数据流标识符重新组装。

HTTP/2的特性——多路复用(Multiplexing)

  • 客户端和服务器可以将HTTP消息分解为互不依赖的帧,然后交错发送,最后再在另一端把它们重新组装起来;
  • 并行交错地发送多个请求,请求之间互不影响;
  • 并行交错地发送多个响应,响应之间互不影响;
  • 使用同一个连接并行发送多个请求和响应;
  • 不必再为绕过HTTP/1.1限制而做很多工作:
  • 比如image sprites合并CSS/JS、内嵌CSS/JS/Base64图片、域名分片等。

HTTP/2的特性——优先级

  • HTTP/2标准允许每一个数据流都有一个关联地权重和依赖搞关系:
    • 可以向每一个数据流分配一个介于1-256之间地整数;
    • 每个数据流与其他数据流之间可以存在显示依赖关系。
  • 客户端可以构建和传输”优先级树“,表明它倾向于如何接收响应。
  • 服务器可以使用此信息给控制CPU、内存和其他资源地分配设定数据流处理地优先级。
    • 在资源数据可用之后,确保将高优先级响应以最有方式传输至客户端;
  • 尽可能先给父数据流分配资源;
  • 同级数据流(共享相同父项)应按其权重比例分配资源配置。

HTTP/2的特性——头部压缩

  • HTTP/2使用HPACK压缩请求头和响应头,可以极大减少头部开销,进而提高性能;

HTTP/2的特性——服务推送(Server Push)

  • 服务器可以对一个客户端请求发送多个响应:
    • 除了最初的响应外,服务器还可与i向客户端推送额外资源。

HTTP/2的问题——队头阻塞(head of line blocking)

  • 由于TCP有序接收的问题,一旦中间出现数据包丢包会导致整个数据流阻塞,直到丢包的数据重传成功。这个问题是TCP导致的。

解决方案:QUIC协议(底层UDP)。

HTTP/2的问题——握手延迟

  • 这个问题还是TCP导致的,由于TCP建立连接需要1.5个RTT。

HTTP/3

  • HTTP/3 弃用了TCP协议,改为使用基于UDP协议的QUIC协议实现;
  • QUIC(Quic UDP Internet Connections),译为快速UDP网络连接;
  • HTTP over QUIC 改名为 HTTP/3。
    HTTP/1        HTTPS         HTTP/2           HTTP/3
+------------+------------+----------------+----------------+
|            |            |      HTTP      |      HTTP      |
|            |    HTTP    +----------------+----------------+
|    HTTP    |            | HPack + Stream | QPack + Stream |
|            +------------+----------------+----------------+
|            |  SSL/TLS   |    TLS 1.2+    | QUIC + TLS1.3+ |
+------------+------------+----------------+----------------+
|     TCP    |     TCP    |       TCP      |       UDP      |
+------------+------------+----------------+----------------+
|     IP     |     IP     |       IP       |       IP       |
+------------+------------+----------------+----------------+

Q:HTTP/3如何保证可靠传输?

A:由QUIC来保证。

HTTP/3的特性——连接迁移

  • TCP基于4要素(源IP、源端口、目标IP、目标端口)
    • 切换网络时至少会有一个要素发生变化,导致连接发生变化;
    • 当连接发生变化时,如果还是用原来的TCP连接,则会导致连接失败;
    • 所以千幻网络时会出现超时重传,等待新连接建立。
  • QUIC的连接不受4要素的影响,当4要素发生变化时,原连接依然维持:
    • QUUIC连接使用一组Connection ID来标识一个连接。

HTTP/3的特性——操作系统内核、CPU负载

与基于TLS的HTTP/2相比,HTTP/3大规模部署的QUIC需要仅2倍的CPU使用量:

Linux内核的UDP部分没有得到像TCP那样的优化;

TCP和TLS有硬件加速,而这对UDP很罕见,对于QUIC则根本不存在。

你可能感兴趣的:(网络协议笔记,网络,服务器,tcp/ip)