想了解Http与Https协议规范的新动态吗？本文将为您提供详细的信息，我们还将为您解答关于http和https协议的相关问题，此外，我们还将为您介绍关于delphiidhttp访问http与http

想了解Http与Https协议规范的新动态吗？本文将为您提供详细的信息，我们还将为您解答关于http和https协议的相关问题，此外，我们还将为您介绍关于delphi idhttp访问http与https不同点、HTTP&HTTPS协议详解之HTTP篇、HTTP/HTTPS/HTTP2/HTTP3/QUIC/WebSocket协议详解、HTTPS与HTTP区别，HTTPS和HTTP它们有什么不同？的新知识。

• Http与Https协议规范（http和https协议）
• delphi idhttp访问http与https不同点
• HTTP&HTTPS协议详解之HTTP篇
• HTTP/HTTPS/HTTP2/HTTP3/QUIC/WebSocket协议详解
• HTTPS与HTTP区别，HTTPS和HTTP它们有什么不同？

Http与Https协议规范（http和https协议）

HTTP是一个属于应用层的面向对象的协议，由于其简捷、快速的方式，适用于分布式超媒体信息系统。它于1990年提出，经过几年的使用与发展，得到不断地完善和扩展。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的规范化工作正在进行之中，而且HTTP-NG(Next Generation of HTTP)的建议已经提出。

HTTP协议的主要特点可概括如下：

1.支持客户/服务器模式。

2.简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。

3.灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。

4.无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。

5.无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。

一、HTTP协议详解之URL篇

http（超文本传输协议）是一个基于请求与响应模式的、无状态的、应用层的协议，常基于TCP的连接方式，HTTP1.1版本中给出一种持续连接的机制，绝大多数的Web开发，都是构建在HTTP协议之上的Web应用。

HTTP URL (URL是一种特殊类型的URI，包含了用于查找某个资源的足够的信息)的格式如下：

http://host[":"port][abs_path]

http表示要通过HTTP协议来定位网络资源；host表示合法的Internet主机域名或者IP地址；port指定一个端口号，为空则使用缺省端口80；abs_path指定请求资源的URI；如果URL中没有给出abs_path，那么当它作为请求URI时，必须以“/”的形式给出，通常这个工作浏览器自动帮我们完成。

eg:

1、输入：www.guet.edu.cn

浏览器自动转换成：http://www.guet.edu.cn/

2、http:192.168.0.116:8080/index.jsp

二、HTTP协议详解之请求篇

http请求由三部分组成，分别是：请求行、消息报头、请求正文

1、请求行以一个方法符号开头，以空格分开，后面跟着请求的URI和协议的版本，格式如下：Method Request-URI HTTP-Version CRLF

其中 Method表示请求方法；Request-URI是一个统一资源标识符；HTTP-Version表示请求的HTTP协议版本；CRLF表示回车和换行（除了作为结尾的CRLF外，不允许出现单独的CR或LF字符）。

请求方法（所有方法全为大写）有多种，各个方法的解释如下：

GET 请求获取Request-URI所标识的资源

POST 在Request-URI所标识的资源后附加新的数据

HEAD 请求获取由Request-URI所标识的资源的响应消息报头

PUT 请求服务器存储一个资源，并用Request-URI作为其标识

DELETE 请求服务器删除Request-URI所标识的资源

TRACE 请求服务器回送收到的请求信息，主要用于测试或诊断

CONNECT 保留将来使用

OPTIONS 请求查询服务器的性能，或者查询与资源相关的选项和需求

应用举例：

GET方法：在浏览器的地址栏中输入网址的方式访问网页时，浏览器采用GET方法向服务器获取资源，eg:GET /form.html HTTP/1.1 (CRLF)

POST方法要求被请求服务器接受附在请求后面的数据，常用于提交表单。

eg：POST /reg.jsp HTTP/ (CRLF)

Accept:image/gif,image/x-xbit,... (CRLF)

...

HOST:www.guet.edu.cn (CRLF)

Content-Length:22 (CRLF)

Connection:Keep-Alive (CRLF)

Cache-Control:no-cache (CRLF)

(CRLF) //该CRLF表示消息报头已经结束，在此之前为消息报头

user=jeffrey&pwd=1234 //此行以下为提交的数据

HEAD方法与GET方法几乎是一样的，对于HEAD请求的回应部分来说，它的HTTP头部中包含的信息与通过GET请求所得到的信息是相同的。利用这个方法，不必传输整个资源内容，就可以得到Request-URI所标识的资源的信息。该方法常用于测试超链接的有效性，是否可以访问，以及最近是否更新。

2、请求报头后述

3、请求正文(略)

三、HTTP协议详解之响应篇

在接收和解释请求消息后，服务器返回一个HTTP响应消息。

HTTP响应也是由三个部分组成，分别是：状态行、消息报头、响应正文

1、状态行格式如下：

HTTP-Version Status-Code Reason-Phrase CRLF

其中，HTTP-Version表示服务器HTTP协议的版本；Status-Code表示服务器发回的响应状态代码；Reason-Phrase表示状态代码的文本描述。

状态代码有三位数字组成，第一个数字定义了响应的类别，且有五种可能取值：

1xx：指示信息--表示请求已接收，继续处理

2xx：成功--表示请求已被成功接收、理解、接受

3xx：重定向--要完成请求必须进行更进一步的操作

4xx：客户端错误--请求有语法错误或请求无法实现

5xx：服务器端错误--服务器未能实现合法的请求

常见状态代码、状态描述、说明：

200 OK //客户端请求成功

400 Bad Request //客户端请求有语法错误，不能被服务器所理解

401 Unauthorized //请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用

403 Forbidden //服务器收到请求，但是拒绝提供服务

404 Not Found //请求资源不存在，eg：输入了错误的URL

500 Internal Server Error //服务器发生不可预期的错误

503 Server Unavailable //服务器当前不能处理客户端的请求，一段时间后可能恢复正常

eg：HTTP/1.1 200 OK （CRLF）

2、响应报头后述

3、响应正文就是服务器返回的资源的内容

四、HTTP协议详解之消息报头篇

HTTP消息由客户端到服务器的请求和服务器到客户端的响应组成。请求消息和响应消息都是由开始行（对于请求消息，开始行就是请求行，对于响应消息，开始行就是状态行），消息报头（可选），空行（只有CRLF的行），消息正文（可选）组成。

HTTP消息报头包括普通报头、请求报头、响应报头、实体报头。

每一个报头域都是由名字+“：”+空格+值 组成，消息报头域的名字是大小写无关的。

1、普通报头

在普通报头中，有少数报头域用于所有的请求和响应消息，但并不用于被传输的实体，只用于传输的消息。

eg：

Cache-Control 用于指定缓存指令，缓存指令是单向的（响应中出现的缓存指令在请求中未必会出现），且是独立的（一个消息的缓存指令不会影响另一个消息处理的缓存机制），HTTP1.0使用的类似的报头域为Pragma。

请求时的缓存指令包括：no-cache（用于指示请求或响应消息不能缓存）、no-store、max-age、max-stale、min-fresh、only-if-cached;

响应时的缓存指令包括：public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age、s-maxage.

eg：为了指示IE浏览器（客户端）不要缓存页面，服务器端的JSP程序可以编写如下：response.sehHeader("Cache-Control","no-cache");

//response.setHeader("Pragma","no-cache");作用相当于上述代码，通常两者//合用

这句代码将在发送的响应消息中设置普通报头域：Cache-Control:no-cache

Date普通报头域表示消息产生的日期和时间

Connection普通报头域允许发送指定连接的选项。例如指定连接是连续，或者指定“close”选项，通知服务器，在响应完成后，关闭连接

2、请求报头

请求报头允许客户端向服务器端传递请求的附加信息以及客户端自身的信息。

常用的请求报头

Accept

Accept请求报头域用于指定客户端接受哪些类型的信息。eg：Accept：image/gif，表明客户端希望接受GIF图象格式的资源；Accept：text/html，表明客户端希望接受html文本。

Accept-Charset

Accept-Charset请求报头域用于指定客户端接受的字符集。eg：Accept-Charset:iso-8859-1,gb2312.如果在请求消息中没有设置这个域，缺省是任何字符集都可以接受。

Accept-Encoding

Accept-Encoding请求报头域类似于Accept，但是它是用于指定可接受的内容编码。eg：Accept-Encoding:gzip.deflate.如果请求消息中没有设置这个域服务器假定客户端对各种内容编码都可以接受。

Accept-Language

Accept-Language请求报头域类似于Accept，但是它是用于指定一种自然语言。eg：Accept-Language:zh-cn.如果请求消息中没有设置这个报头域，服务器假定客户端对各种语言都可以接受。

Authorization

Authorization请求报头域主要用于证明客户端有权查看某个资源。当浏览器访问一个页面时，如果收到服务器的响应代码为401（未授权），可以发送一个包含Authorization请求报头域的请求，要求服务器对其进行验证。

Host（发送请求时，该报头域是必需的）

Host请求报头域主要用于指定被请求资源的Internet主机和端口号，它通常从HTTP URL中提取出来的，eg：

我们在浏览器中输入：http://www.guet.edu.cn/index.html

浏览器发送的请求消息中，就会包含Host请求报头域，如下：

Host：www.guet.edu.cn

此处使用缺省端口号80，若指定了端口号，则变成：Host：www.guet.edu.cn:指定端口号

User-Agent

我们上网登陆论坛的时候，往往会看到一些欢迎信息，其中列出了你的操作系统的名称和版本，你所使用的浏览器的名称和版本，这往往让很多人感到很神奇，实际上，服务器应用程序就是从User-Agent这个请求报头域中获取到这些信息。User-Agent请求报头域允许客户端将它的操作系统、浏览器和其它属性告诉服务器。不过，这个报头域不是必需的，如果我们自己编写一个浏览器，不使用User-Agent请求报头域，那么服务器端就无法得知我们的信息了。

请求报头举例：

GET /form.html HTTP/1.1 (CRLF)

Accept:image/gif,image/x-xbitmap,image/jpeg,application/x-shockwave-flash,application/vnd.ms-excel,application/vnd.ms-powerpoint,application/msword,*/* (CRLF)

Accept-Language:zh-cn (CRLF)

Accept-Encoding:gzip,deflate (CRLF)

If-Modified-Since:Wed,05 Jan 2007 11:21:25 GMT (CRLF)

If-None-Match:W/"80b1a4c018f3c41:8317" (CRLF)

User-Agent:Mozilla/4.0(compatible;MSIE6.0;Windows NT 5.0) (CRLF)

Host:www.guet.edu.cn (CRLF)

Connection:Keep-Alive (CRLF)

(CRLF)

3、响应报头

响应报头允许服务器传递不能放在状态行中的附加响应信息，以及关于服务器的信息和对Request-URI所标识的资源进行下一步访问的信息。

常用的响应报头

Location

Location响应报头域用于重定向接受者到一个新的位置。Location响应报头域常用在更换域名的时候。

Server

Server响应报头域包含了服务器用来处理请求的软件信息。与User-Agent请求报头域是相对应的。下面是

Server响应报头域的一个例子：

Server：Apache-Coyote/1.1

WWW-Authenticate

WWW-Authenticate响应报头域必须被包含在401（未授权的）响应消息中，客户端收到401响应消息时候，并发送Authorization报头域请求服务器对其进行验证时，服务端响应报头就包含该报头域。

eg：WWW-Authenticate:Basic realm="Basic Auth Test!" //可以看出服务器对请求资源采用的是基本验证机制。

4、实体报头

请求和响应消息都可以传送一个实体。一个实体由实体报头域和实体正文组成，但并不是说实体报头域和实体正文要在一起发送，可以只发送实体报头域。实体报头定义了关于实体正文（eg：有无实体正文）和请求所标识的资源的元信息。

常用的实体报头

Content-Encoding

Content-Encoding实体报头域被用作媒体类型的修饰符，它的值指示了已经被应用到实体正文的附加内容的编码，因而要获得Content-Type报头域中所引用的媒体类型，必须采用相应的解码机制。Content-Encoding这样用于记录文档的压缩方法，eg：Content-Encoding：gzip

Content-Language

Content-Language实体报头域描述了资源所用的自然语言。没有设置该域则认为实体内容将提供给所有的语言阅读

者。eg：Content-Language:da

Content-Length

Content-Length实体报头域用于指明实体正文的长度，以字节方式存储的十进制数字来表示。

Content-Type

Content-Type实体报头域用语指明发送给接收者的实体正文的媒体类型。eg：

Content-Type:text/html;charset=ISO-8859-1

Content-Type:text/html;charset=GB2312

Last-Modified

Last-Modified实体报头域用于指示资源的最后修改日期和时间。

Expires

Expires实体报头域给出响应过期的日期和时间。为了让代理服务器或浏览器在一段时间以后更新缓存中(再次访问曾访问过的页面时，直接从缓存中加载，缩短响应时间和降低服务器负载)的页面，我们可以使用Expires实体报头域指定页面过期的时间。eg：Expires：Thu，15 Sep 2006 16:23:12 GMT

HTTP1.1的客户端和缓存必须将其他非法的日期格式（包括0）看作已经过期。eg：为了让浏览器不要缓存页面，我们也可以利用Expires实体报头域，设置为0，jsp中程序如下：response.setDateHeader("Expires","0");

五、利用telnet观察http协议的通讯过程

实验目的及原理：

利用MS的telnet工具，通过手动输入http请求信息的方式，向服务器发出请求，服务器接收、解释和接受请求后，会返回一个响应，该响应会在telnet窗口上显示出来，从而从感性上加深对http协议的通讯过程的认识。

实验步骤：

1、打开telnet

1.1 打开telnet

运行-->cmd-->telnet

1.2 打开telnet回显功能

set localecho

2、连接服务器并发送请求

2.1 open www.guet.edu.cn 80 //注意端口号不能省略

HEAD /index.asp HTTP/1.0

Host:www.guet.edu.cn

/*我们可以变换请求方法,请求桂林电子主页内容,输入消息如下*/

open www.guet.edu.cn 80

GET /index.asp HTTP/1.0 //请求资源的内容

Host:www.guet.edu.cn

2.2 open www.sina.com.cn 80 //在命令提示符号下直接输入telnet www.sina.com.cn 80

HEAD /index.asp HTTP/1.0

Host:www.sina.com.cn

3 实验结果：

3.1 请求信息2.1得到的响应是:

HTTP/1.1 200 OK //请求成功

Server: Microsoft-IIS/5.0 //web服务器

Date: Thu,08 Mar 200707:17:51 GMT

Connection: Keep-Alive

Content-Length: 23330

Content-Type: text/html

Expries: Thu,08 Mar 2007 07:16:51 GMT

Set-Cookie: ASPSESSIONIDQAQBQQQB=BEJCDGKADEDJKLKKAJEOIMMH; path=/

Cache-control: private

//资源内容省略

3.2 请求信息2.2得到的响应是:

HTTP/1.0 404 Not Found //请求失败

Date: Thu, 08 Mar 2007 07:50:50 GMT

Server: Apache/2.0.54 <Unix>

Last-Modified: Thu, 30 Nov 2006 11:35:41 GMT

ETag: "6277a-415-e7c76980"

Accept-Ranges: bytes

X-Powered-By: mod_xlayout_jh/0.0.1vhs.markII.remix

Vary: Accept-Encoding

Content-Type: text/html

X-Cache: MISS from zjm152-78.sina.com.cn

Via: 1.0 zjm152-78.sina.com.cn:80<squid/2.6.STABLES-20061207>

X-Cache: MISS from th-143.sina.com.cn

Connection: close

失去了跟主机的连接

按任意键继续...

4 .注意事项：1、出现输入错误，则请求不会成功。

2、报头域不分大小写。

3、更深一步了解HTTP协议，可以查看RFC2616，在http://www.letf.org/rfc上找到该文件。

4、开发后台程序必须掌握http协议

HTTPS

HTTPS（全称：Hyper Text Transfer Protocol over Secure Socket Layer 或 Hypertext Transfer Protocol Secure，超文本传输安全协议），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。 它是一个URI scheme（抽象标识符体系），句法类同http:体系。用于安全的HTTP数据传输。https:URL表明它使用了HTTP，但HTTPS存在不同于HTTP的默认端口及一个加密/身份验证层（在HTTP与TCP之间）。这个系统的最初研发由网景公司(Netscape)进行，并内置于其浏览器Netscape Navigator中，提供了身份验证与加密通讯方法。现在它被广泛用于万维网上安全敏感的通讯，例如交易支付方面。

HTTPS和HTTP的区别

超文本传输协议HTTP协议被用于在Web浏览器和网站服务器之间传递信息。HTTP协议以明文方式发送内容，不提供任何方式的数据加密，如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息，因此HTTP协议不适合传输一些敏感信息，比如信用卡号、密码等。

为了解决HTTP协议的这一缺陷，需要使用另一种协议：安全套接字层超文本传输协议HTTPS。为了数据传输的安全，HTTPS在HTTP的基础上加入了SSL协议，SSL依靠证书来验证服务器的身份，并为浏览器和服务器之间的通信加密。

HTTPS和HTTP的区别主要为以下四点：

一、https协议需要到ca申请证书，一般免费证书很少，需要交费。

二、http是超文本传输协议，信息是明文传输，https 则是具有安全性的ssl加密传输协议。

三、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。

四、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

注意：在微信小程序里面都限制只能有https协议、搜索引擎排名都对https优先收录

HTTPS信任主机的问题

采用https的服务器必须从CA （Certificate Authority）申请一个用于证明服务器用途类型的证书。该证书只有用于对应的服务器的时候，客户端才信任此主机。所以所有的银行系统网站，关键部分应用都是https 的。客户通过信任该证书，从而信任了该主机。其实这样做效率很低，但是银行更侧重安全。这一点对局域网对内提供服务处的服务器没有任何意义。局域网中的服务器，采用的证书不管是自己发布的还是从公众的地方发布的，其客户端都是自己人，所以该局域网中的客户端也就肯定信任该服务器。

HTTPS通讯过程中的数据的泄密和被篡改

1． 一般意义上的https，就是服务器有一个证书。

a) 主要目的是保证服务器就是他声称的服务器，这个跟第一点一样。

b)服务端和客户端之间的所有通讯，都是加密的。

i. 具体讲，是客户端产生一个对称的密钥，通过服务器的证书来交换密钥，即一般意义上的握手过程。

ii. 接下来所有的信息往来就都是加密的。第三方即使截获，也没有任何意义，因为他没有密钥，当然篡改也就没有什么意义了。

2． 少许对客户端有要求的情况下，会要求客户端也必须有一个证书。

a) 这里客户端证书，其实就类似表示个人信息的时候，除了用户名/密码，还有一个CA 认证过的身份。因为个人证书一般来说是别人无法模拟的，所有这样能够更深的确认自己的身份。

b) 目前大多数个人银行的专业版是这种做法，具体证书可能是拿U盘（即U盾）作为一个备份的载体。

HTTPS-ssl

SSL(Secure Sockets Layer 安全套接层),及其继任者传输层安全(Transport Layer Security，TLS)是为网络通信提供安全及数据完整性的一种安全协议。TLS与SSL在传输层对网络连接进行加密。

SSL (Secure Socket Layer)为Netscape所研发，用以保障在Internet上数据传输之安全，利用数据加密(Encryption)技术，可确保数据在网络上之传输过程中不会被截取及窃听。目前一般通用之规格为40 bit之安全标准，美国则已推出128 bit之更高安全标准，但限制出境。只要3.0版本以上之I.E.或Netscape浏览器即可支持SSL。

当前版本为3.0。它已被广泛地用于Web浏览器与服务器之间的身份认证和加密数据传输。

SSL协议位于TCP/IP协议与各种应用层协议之间，为数据通讯提供安全支持。SSL协议可分为两层：SSL记录协议（SSL Record Protocol）：它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。SSL握手协议（SSL Handshake Protocol）：它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。

HTTPS-SSL协议提供的服务主要有哪些

1）认证用户和服务器，确保数据发送到正确的客户机和服务器

2）加密数据以防止数据中途被窃取

3）维护数据的完整性，确保数据在传输过程中不被改变。

SSL协议的工作流程

服务器认证阶段：

1）客户端向服务器发送一个开始信息“Hello”以便开始一个新的会话连接；

2）服务器根据客户的信息确定是否需要生成新的主密钥，如需要则服务器在响应客户的“Hello”信息时将包含生成主密钥所需的信息；

3）客户根据收到的服务器响应信息，产生一个主密钥，并用服务器的公开密钥加密后传给服务器；

4）服务器恢复该主密钥，并返回给客户一个用主密钥认证的信息，以此让客户认证服务器。

HTTPS用户认证阶段

在此之前，服务器已经通过了客户认证，这一阶段主要完成对客户的认证。经认证的服务器发送一个提问给客户，客户则返回（数字）签名后的提问和其公开密钥，从而向服务器提供认证。

从SSL 协议所提供的服务及其工作流程可以看出，SSL协议运行的基础是商家对消费者信息保密的承诺，这就有利于商家而不利于消费者。在电子商务初级阶段，由于运作电子商务的企业大多是信誉较高的大公司，因此这问题还没有充分暴露出来。但随着电子商务的发展，各中小型公司也参与进来，这样在电子支付过程中的单一认证问题就越来越突出。虽然在SSL3.0中通过数字签名和数字证书可实现浏览器和Web服务器双方的身份验证，但是SSL协议仍存在一些问题，比如，只能提供交易中客户与服务器间的双方认证，在涉及多方的电子交易中，SSL协议并不能协调各方间的安全传输和信任关系。在这种情况下，Visa和MasterCard两大信用卡公组织制定了SET协议，为网上信用卡支付提供了全球性的标准。

delphi idhttp访问http与https不同点

HTTP&HTTPS协议详解之HTTP篇

一、HTTP简介

01.什么是HTTP

HTTP(HyperText Transfer Protocol ,超文本传输协议),是一个基于请求与响应的，无状态的，应用层的协议，常基于TCP/IP协议传输数据，互联网上应用最广泛的一种协议，所有的WWW文件必须遵守这个标准。

HTTP协议的设计初衷是为了提供一种发送和接受HTML页面的方法

02.HTTP发展史

• HTTP/0.9版本（1991年）

特点：

• • 不涉及数据包传输，服务器只能回应HTML格式的字符串，不能回应别的格式
  • 只能以GET方式请求
  • 每次请求都需要重新建立TCP连接，服务器发送完毕就关闭TCP连接
  • 没有成为正式的标准

请求示例：

GET /index.html

响应示例：

<html>
  <body>Hello World</body>
</html>

• HTTP/1.0版本（1996年）

特点：

• • 传输内容格式没有限制
  • 增加POST、HEAD命令
  • 请求和响应的格式变了，除了数据部分，每次通讯都必须包含头信息（HTTP Header）来描述一些元数据
  • 新增功能还包括状态码（status code）、多字符集支持、多部分发送（multi-part type）、权限（authorization）、缓存（cache）、内容编码（content encoding）等
  • 每次请求都需要重新建立TCP连接，服务器发送完毕就关闭TCP连接
  • 正式作为标准

请求示例：

GET / HTTP/1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)
Accept: */*

响应示例：

HTTP/1.0 200 OK 
Content-Type: text/plain
Content-Length: 137582
Expires: Thu, 05 Dec 1997 16:00:00 GMT
Last-Modified: Wed, 5 August 1996 15:55:28 GMT
Server: Apache 0.84

<html>
  <body>Hello World</body>
</html>

• HTTP/1.1版本（1997年）

特点：

• • 增加持久连接（persistent connection），即TCP连接默认不关闭，可以被多个请求复用
  • 引入管道机制（pipelining），即在同一个TCP连接里面，客户端可以同时发送多个请求。这样就进一步改进了HTTP协议的效率
  • 引入分块传输编码 （Chunked transfer encoding）机制，允许HTTP由網頁伺服器发送给客户端应用（ 通常是网页浏览器）的数据可以分成多个部分
  • 引入了许多动词方法：PUT、PATCH、OPTIONS、DELETE
  • 客户端请求的头信息新增了Host字段，用来指定服务器的域名

缺点：

虽然1.1版允许复用TCP连接，但是同一个TCP连接里面，所有的数据通信是按次序进行的。服务器只有处理完一个回应，才会进行下一个回应。要是前面的回应特别慢，后面就会有许多请求排队等着。这称为"队头堵塞"（Head-of-line blocking）。

 为了避免这个问题，只有两种方法：一是减少请求数，二是同时多开持久连接。这导致了很多的网页优化技巧，比如合并脚本和样式表、将图片嵌入CSS代码、域名分片（domain sharding）等等。如果HTTP协议设计得更好一些，这些额外的工作是可以避免的。

请求示例：

GET /?mkt=zh-CN HTTP/1.1
Host: cn.bing.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Connection: close
Cookie: SRCHD=AF=NOFORM; SRCHUID=V=2&GUID=8004E55B8C8B4137BACF748D4213FE40&dmnchg=1; SRCHUSR=DOB=20191024&T=1580718980000; _EDGE_V=1; MUID=19ADA0EFC0FC60B715E2AD10C1D26108; MUIDB=19ADA0EFC0FC60B715E2AD10C1D26108; SRCHHPGUSR=CW=1536&CH=728&DPR=1.25&UTC=480&WTS=63717770478&HV=1582173694; ABDEF=MRB=1580624806993&MRNB=0; SNRHOP=I=&TS=; _EDGE_S=mkt=zh-cn&SID=32482CF6BD916165130F2280BCBF60A9; _SS=SID=32482CF6BD916165130F2280BCBF60A9&bIm=376; ipv6=hit=1582177279658&t=4
Upgrade-Insecure-Requests: 1
Pragma: no-cache
Cache-Control: no-cache

响应示例：

HTTP/1.1 200 OK
Cache-Control: private, max-age=0
Content-Length: 112682
Content-Type: text/html; charset=utf-8
Vary: Accept-Encoding
P3P: CP="NON UNI COM NAV STA LOC CURa DEVa PSAa PSDa OUR IND"
Set-Cookie: SNRHOP=I=&TS=; domain=.bing.com; path=/
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
X-MSEdge-Ref: Ref A: A5F96665F8534BC1858A0E1C7D198764 Ref B: BJ1EDGE0106 Ref C: 2020-02-20T04:43:04Z
Set-Cookie: _EDGE_S=mkt=zh-cn&SID=32482CF6BD916165130F2280BCBF60A9; path=/; httponly; domain=bing.com
Date: Thu, 20 Feb 2020 04:43:03 GMT
Connection: close

• HTTP/2版本（2015年）

特点：

• • 彻底的二进制协议，头信息和数据体都是二进制，并且统称为"帧"（frame）：头信息帧和数据帧。
  • 多工（Multiplexing），复用TCP连接，在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，而且不用按照顺序一一对应，这样就避免了"队头堵塞"。
  • 引入数据流机制
  • 引入了头信息压缩机制（header compression）。
  • 允许服务器未经请求，主动向客户端发送资源，这叫做服务器推送（server push）。

04.什么是C/S架构?什么是B/S架构?

• C/S(Client/Sever)客户机和服务器架构
• B/S(Bower/Sever)浏览器和服务器架构

二、HTTP消息结构

01.统一资源定位符(URL)

URL,全称是UniformResourceLocator, 中文叫统一资源定位符,是互联网上用来标识某一处资源的地址。

协议方案名：http、ftp、mailto、file

登录信息：如果需要网页认证时，需要填写该参数，所以是可选项

服务器地址：可以是IP地址形式，也可以是能被DNS服务器解析成IP地址的域名形式

端口号：指定服务器连接的端口号，选填，不填则默认为本协议的端口号（HTTP：80，HTTPS：443）

带层次的文件路径：获取资源在服务器中的具体地址

查询字符串：针对以指定路径的资源，可使用查询字符串来获取想要的参数，此项也是可选项

片段标识符：又名hash,来标记以获取资源中的子资源（在文档中的某个位置）

02.统一资源标识符 (URI)

统一资源标识符（Uniform Resource Identifier）一个用于标识某一互联网资源名称的字符串。

该种标识允许用户对网络中（一般指万维网）的资源通过特定的协议进行交互操作。URI的最常见的形式是统一资源定位符（URL），经常指定为非正式的网址。更罕见的用法是统一资源名称（URN），其目的是通过提供一种途径。用于在特定的命名空间资源的标识，以补充网址。

03.HTTP之请求消息Request

 1.HTTP报文格式（HTTP请求）

HTTP请求由请求行（request line）、请求头部（header）、空行和请求数据四个部分组成。

2.HTTP请求方法

HTTP/1.1协议中共定义了八种方法（有时也叫“动作”）来表明Request-URI指定的资源的不同操作方式：

OPTIONS - 返回服务器针对特定资源所支持的HTTP请求方法。也可以利用向Web服务器发送''*''的请求来测试服务器的功能性。
HEAD- 向服务器索要与GET请求相一致的响应，只不过响应体将不会被返回。这一方法可以在不必传输整个响应内容的情况下，就可以获取包含在响应消息头中的元信息。该方法常用于测试超链接的有效性，是否可以访问，以及最近是否更新。
GET - 向特定的资源发出请求。注意：GET方法不应当被用于产生“副作用”的操作中，例如在web app.中。其中一个原因是GET可能会被网络蜘蛛等随意访问。
POST - 向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。
PUT - 向指定资源位置上传其最新内容。
DELETE - 请求服务器删除Request-URI所标识的资源。
TRACE- 回显服务器收到的请求，主要用于测试或诊断。
CONNECT - HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
PATCH - 用来将局部修改应用于某一资源，添加于规范RFC5789。

 3.HTTP常见的请求头部字段名（在HTTP/1.1 协议中，所有的请求头，除Host外，都是可选的）

• X-Forwarded-For：用来表示HTTP请求端的真实IP，被各大HTTP代理、负载均衡等转发服务广泛使用

• Cache-Control：指定请求和响应遵循的缓存机制。缓存指令是单向的（响应中出现的缓存指令在请求中未必会出现），且是独立的（在请求消息或响应消息中设置Cache-Control并不会修改另一个消息处理过程中的缓存处理过程）。请求时的缓存指令包括no-cache、no-store、max-age、max-stale、min-fresh、only-if-cached，响应消息中的指令包括public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age、s-maxage。

Cache-Control:Public 可以被任何缓存所缓存
Cache-Control:Private 内容只缓存到私有缓存中
Cache-Control:no-cache 所有内容都不会被缓存
Cache-Control:no-store 用于防止重要的信息被无意的发布。在请求消息中发送将使得请求和响应消息都不使用缓存。
Cache-Control:max-age 指示客户机可以接收生存期不大于指定时间（以秒为单位）的响应。
Cache-Control:min-fresh 指示客户机可以接收响应时间小于当前时间加上指定时间的响应。
Cache-Control:max-stale 指示客户机可以接收超出超时期间的响应消息。如果指定max-stale消息的值，那么客户机可以接收超出超时期指定值之内的响应消息。

• Accept：浏览器端可以接受的MIME类型。例如：Accept: text/html 代表浏览器可以接受服务器回发的类型为 text/html 也就是我们常说的html文档，如果服务器无法返回text/html类型的数据，服务器应该返回一个406错误(non acceptable)。通配符 * 代表任意类型，例如 Accept: */* 代表浏览器可以处理所有类型，(一般浏览器发给服务器都是发这个)。

• Accept-Encoding：浏览器申明自己可接收的编码方法，通常指定压缩方法，是否支持压缩，支持什么压缩方法（gzip，deflate）;Servlet能够向支持gzip的浏览器返回经gzip编码的HTML页面。许多情形下这可以减少5到10倍的下载时间。例如： Accept-Encoding: gzip, deflate。如果请求消息中没有设置这个域，服务器假定客户端对各种内容编码都可以接受。

• Accept-Language：浏览器申明自己接收的语言。语言跟字符集的区别：中文是语言，中文有多种字符集，比如big5，gb2312，gbk等等；例如：Accept-Language: en-us。如果请求消息中没有设置这个报头域，服务器假定客户端对各种语言都可以接受。

• Accept-Charset：浏览器可接受的字符集。如果在请求消息中没有设置这个域，缺省表示任何字符集都可以接受。

• User-Agent：告诉HTTP服务器，客户端使用的操作系统和浏览器的名称和版本。例如： User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; CIBA; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; InfoPath.2; .NET4.0E)。

• Content-Type：例如：Content-Type: application/x-www-form-urlencoded。

• Referer：包含一个URL，用户从该URL代表的页面出发访问当前请求的页面。提供了Request的上下文信息的服务器，告诉服务器我是从哪个链接过来的，比如从我主页上链接到一个朋友那里，他的服务器就能够从HTTP Referer中统计出每天有多少用户点击我主页上的链接访问他的网站。例如: Referer:http://translate.google.cn/?hl=zh-cn&tab=wT

• Connection：例如：Connection: keep-alive 当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接。HTTP 1.1默认进行持久连接。利用持久连接的优点，当页面包含多个元素时（例如Applet，图片），显著地减少下载所需要的时间。要实现这一点，Servlet需要在应答中发送一个Content-Length头，最简单的实现方法是：先把内容写入ByteArrayOutputStream，然后在正式写出内容之前计算它的大小。Connection: close 代表一个Request完成后，客户端和服务器之间用于传输HTTP数据的TCP连接会关闭，当客户端再次发送Request，需要重新建立TCP连接。

• Host：（发送请求时，该头域是必需的）主要用于指定被请求资源的Internet主机和端口号，它通常从HTTP URL中提取出来的。HTTP/1.1请求必须包含主机头域，否则系统会以400状态码返回。例如: 我们在浏览器中输入：http://www.guet.edu.cn/index.html，浏览器发送的请求消息中，就会包含Host请求头域：Host：http://www.guet.edu.cn，此处使用缺省端口号80，若指定了端口号，则变成：Host：指定端口号。

• Cookie：最重要的请求头之一, 将cookie的值发送给HTTP服务器。

• Content-Length：表示请求消息正文的长度。例如：Content-Length: 38。

• Authorization：授权信息，通常出现在对服务器发送的WWW-Authenticate头的应答中。主要用于证明客户端有权查看某个资源。当浏览器访问一个页面时，如果收到服务器的响应代码为401（未授权），可以发送一个包含Authorization请求报头域的请求，要求服务器对其进行验证。

• From：请求发送者的email地址，由一些特殊的Web客户程序使用，浏览器不会用到它。

• Range：可以请求实体的一个或者多个子范围。例如，

04.HTTP之响应消息Response

1.HTTP报文格式（HTTP响应）

• 状态行由三部分组成，分别为：协议版本、状态码、状态码描述，之间由空格间隔
• 响应头部与请求头部类似，也包含了很多有用信息
• 空行，这一行非常重要，表示响应头的结束
• 响应正文，服务器返回的文档，最常见的为HTML网页

2.HTTP常见的状态码

200 OK                        //客户端请求成功
400 Bad Request               //客户端请求有语法错误，不能被服务器所理解
401 Unauthorized              //请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用 
403 Forbidden                 //服务器收到请求，但是拒绝提供服务
404 Not Found                 //请求资源不存在，eg：输入了错误的URL
500 Internal Server Error     //服务器发生不可预期的错误
503 Server Unavailable        //服务器当前不能处理客户端的请求，一段时间后可能恢复正常

原文出处：https://www.cnblogs.com/0pen1/p/12316682.html

HTTP/HTTPS/HTTP2/HTTP3/QUIC/WebSocket协议详解

名词解释

URI结构如下，URL是URI中Web Resource的子集，例如http/ftp协议。

HTTP

HTTP全称Hypertext Transfer Protocol超文本传输协议，主要基于TCP实现的应用层协议，特点有：

• 支持客户端向服务器请求URL资源。
• HTTP是无状态协议。服务器不需要强制保存HTTP session任何信息。
• HTTP authentication特性支持账号密码的传输。

版本变化：

• HTTP/1.0最初实现了可用性。对每个请求都需要TCP三次握手建立单独链路。
• HTTP/1.1优化了传输效率。新增keep-alive特性使多个请求可以复用同一条TCP链路(TCP keep-alive是传输层特性，防止NAT路由断开连接)；新增chunked transfer encoding允许流式传输而不是一次性buffered传输；新增HTTP pipelining可并行请求-响应，避免串行请求-响应的阻塞耗时；新增byte serving只请求部分资源。

TCP握手流程：

三次握手原因。为了避免因传输异常导致包时序问题，一端在发消息时必须要接收到对方的回包确认。例如客户端因网络延迟发了两个SYN，如果没有第三次握手ACK，则服务端会二次建立连接。

四次挥手原因。一端发送FIN是表示自己不发数据，但是还可以接收另一端发送的数据。所以要结束TCP连接，需要双方都FIN+ACK两次RTT。根据wiki也有可以通过三次挥手结束连接，但是需要同时关闭双端。
结束TIME_WAIT需要等待2MSL(最大报文段生存时间)才能到CLOSED状态。一是避免最后的ACK丢白需要重发，二是要确保此次连接的数据包在网络中消失，避免跟下次连接混淆。

请求与响应包：

响应状态码分为1xx临时响应、2xx成功、3xx重定向、4xx请求错误、5xx服务器错误。常见状态码见附录。

WebSocket

WebSocket是基于TCP的全双工通信协议。背景是web app网络通信是基于HTTP协议，每次服务端跟客户端通信都需要建立一次HTTP连接，WebSocket在应用层重新设计，提供机制可以让web网络通信在一个TCP连接中实现多次数据传输。
WebSocket与HTTP的联系
为了兼容HTTP服务，WebSocket握手协议是在HTTP基础上进行扩展。但是WebSocket其他部分与HTTP无关，完全是在TCP之上封装的应用与web的协议，其中包括以下内容：
o 为浏览器添加基于Web Origin标准的安全模型
o 添加了一种寻址和协议命名机制，以支持一个端口上的多种服务和一个IP地址上的多个主机名
o 在TCP之上分层成帧机制，以回到建立TCP的IP数据包机制，但没有长度限制
o 在代理和其他中间人的情况下额外设计一套关闭握手协议

WebSocket URI格式：
ws-URI = "ws:" "//" host [ ":" port ] path [ "?" query ]
wss-URI = "wss:" "//" host [ ":" port ] path [ "?" query ]

WebSocket握手头部：

RFC: https://tools.ietf.org/html/rfc6455

HTTPS

HTTPS全称Hypertext Transfer Protocol Secure，是在HTTP协议中添加TLS/SSL扩展，支持加密数据传输。
为了确保数据在传输过程中不被读取(加密算法)、篡改(数字签名)、调包(数字证书)，以下对相关术语进行解释。
加密算法
1.对称加密
对称加密算法的特点是算法公开、计算量小、加密速度快、加密效率高。对称加密有很多种算法，由于它效率很高，所以被广泛使用在很多加密协议的核心当中。不足之处是，交易双方都使用同样钥匙，安全性得不到保证。常见的对称加密有 DES、AES 等。
2.非对称加密
非对称加密使用一对“私钥-公钥”，用私钥加密的内容只有对应公钥才能解开，反之亦然。非对称加密有以下特性：

• 对于一个公钥，有且只有一个对应的私钥。
• 公钥是公开的，并且不能通过公钥反推出私钥。
• 通过私钥加密的密文只能通过公钥能解密，通过公钥加密的密文也只能通过私钥能解密。

非对称加密不需要共享同一份秘钥，安全性要比对称加密高，但由于算法强度比对称加密复杂，加解密的速度比对称加解密的速度要慢。常见的非对称加密有 RSA、ESA、ECC 等。

数字签名
数字签名就是用摘要算法提取出源文件的摘要并用私钥进行加密后的内容。摘要一致则说明文件没有被篡改过，即使摘要被解密也无法还原数据内容。
摘要算法有以下特性：

• 只要源文本不同，计算得到的结果，必然不同（或者说机会很少）。
• 无法从结果反推出源数据。

一般使用摘要算法来校验原始内容是否被篡改。常见的摘要算法有 MD5、SHA 等。

数字证书
数字证书是一个经证书授权中心数字签名的包含公开密钥拥有者信息以及公开密钥的文件，用于认证密匙的有效性。一般会包含公钥、公钥拥有者名称、CA 的数字签名、有效期、授权中心名称、证书序列号等信息。

数字证书如何确保列出的用户就是公钥的拥有者呢？关键点是 CA 的数字签名，CA会用自己的私钥将证书内容的摘要进行加密。因为 CA 的公钥是公开的，任何人都可以用公钥解密出 CA 的数字签名的摘要，再用同样的摘要算法提取出证书的摘要和解密 CA 数字签名后的摘要比对，一致则说明这个证书没有被篡改过，可以信任。

参考：https://www.jianshu.com/p/ffe8c203a471

TLS握手过程：
TLS握手协议分为基础握手协议(Basic TLS handshake)与双向认证协议(Client-authenticated TLS handshake)。双向认证协议是在Basic基础上增加了客户端发送证书的步骤。

1. 客户端发送「_ClientHello_」，内容包括：支持的协议版本，比如TLS1.0版，一个客户端生成的随机数Random1（稍后用于生成“会话密钥”），支持的加密算法（如RSA公钥加密）和支持的压缩算法。
2. 服务端发送「_ServerHello_」，内容包括：客户端与服务端支持的最高协议版本，一个服务器生成的随机数Random2，CipherSuite与压缩算法（如RSA）。如果是复用session，还会带上session ID。
3. 服务端发送「_ServerCertificate_」证书。服务器会将自己的证书下发给客户端，其中Certificates即是证书（除了网站的CA证书外，还一并把该CA证书的中级证书下发，所以是一个证书链），证书内包含公钥。
4. (双向认证)服务端发送CertificateRequest。请求客户端证书。
5. 服务端发送「_ServerHelloDone_」。完成协商。
6. (双向认证)客户端发送Certificate。包含客户端证书以及公钥。
7. 客户端发送「_ClientKeyExchange_」。生成随机数Random3，用证书的公钥加密生成PreMasterSecret。服务端用私钥解密PreMasterSecret得到Random3。
8. (双向认证)客户端发送CertificateVerify。用客户端证书私钥根据上一个消息生成签名，服务端用客户端公钥解密，确认客户端证书有效。
9. 双端根据Random1、Random2、Random3用协商的加密算法生成密钥。
10. 客户端发送「_ChangeCipherSpec_」。表示之后数据均以加密方式传输。
11. 客户端发送「_Finished_」。发送加密的Finished消息，内容是基于前一次消息生成的hash以及Message Authentication Code (MAC)。服务端验证Finished消息是否有效，无效则关闭连接。
12. 服务端发送「_ChangeCipherSpec_」以及「_Finished_」。同上。
13. 开始加密数据传输。

基础流程：

公私钥交换流程：

TLS 1.3改进
冷启动握手从2-RTT到1-RTT。

1. 客户端将预测的协议版本和key share发给服务端。
2. 服务端选择协议并返回key share跟证书(用key share加密)以及Finished。
3. 客户端用key share验证证书获取公钥，发送Finished。

Resumption热启动
tls 1.2热启动实现方式是发送ClientHello时带上session ID(缺点是需要每个连接服务器保存session状态)或者session Ticket(序列化的session)，服务端确认后直接返回Finished，然后双端复用Pre-master secret，这样只需要1-RTT即可完成握手。但是存在风险是如果Pre-master secret被破解，则session数据就会泄露。
tls 1.3改进了热启动方式，达到0-RTT。具体实现是在初次握手后通过加密通道传输Pre-Shared Key(用于确认使用者身份，而不是密钥)，客户端热启动时同时传加密数据以及Pre-Shared Key，服务端如果验证Pre-Shared Key有效则直接解密数据。

tls 1.3冷热启动握手图见spec，搜索figure即可。
https://tools.ietf.org/html/rfc8446#section-4.2.11

常见攻击
Downgrade attack。man-in-the-middle攻击的一种，篡改客户端请求向服务端协商旧版本的加密方式，然后通过已知的旧版本漏洞破解加密请求。通常服务端去掉向后兼容性就可以解决问题，但是会牺牲部分可用性。另外tls 1.3标准定义在双端Finished消息中校验之前所有握手消息的MAC，如果存在篡改则关闭连接。
Replay attack。攻击者sniff并录制正常客户端请求，然后向服务端请求同样的内容，从而欺骗服务端获取敏感数据。例如0-RTT的首次数据场景，因为服务端无法验证数据来源，所以最好的方式是首次请求避免敏感信息、状态改变等。

HTTP/2

相比HTTP1.x，2.0在以下方面做了改进：
Streams, messages, and frames
HTTP2在应用层引入Binary framing机制将传输数据从单一请求-响应包细分成更小的部分进行数据传输，从而可以更灵活地控制数据，引入多路复用、优先级、数据流控制等传输策略。
Binary framing引入Stream、message和frame概念。一个TCP连接传输多个bidirectional streams（包含stream id跟priority）；stream由多个messages构成，message是HTTP消息例如一次request或response，包含一个或多个frames；frame包含不同类型的数据，是数据传输最小单位，例如header，body为不同的frame，可以通过stream id进行组装。

multiplexing单TCP连接多路复用
一次TCP连接在HTTP1只能一次请求响应，HTTP2将多次请求响应划分为frames，交替(interleave)传输，最终在对端根据stream id进行组装。

Stream prioritization
客户端给每个stream分配1-256优先级附在header frame中，再根据stream依赖树请求服务器。RFC没有规定服务端的行为，不同的服务提供商可能实现不同的处理策略，例如cloudflare根据客户端优先级将stream划分为多个池，每个池分配一定的带宽传输数据。

cloudflare solution:https://blog.cloudflare.com/better-http-2-prioritization-for-a-faster-web/
RFC:https://tools.ietf.org/html/rfc7540#page-24

HTTP headers压缩
基本思路是对标准header键值用固定字典编码，自定义键值用动态字典编码，无法用字典情况下用Huffman编码。固定字典是基于RFC标准定义的固定键值字符串排列；动态字典是在一次connection过程中动态更新自定义键值字符串；Huffman编码是用于第一次传输自定义键值，双端解码后在动态字典中更新，第二次传输即可用字典方式编码，Huffman表是RFC基于大量现实header统计的概率表。对自定义头部用预定义字典或动态字典(随一次connection更新)编码。

例子：https://blog.cloudflare.com/hpack-the-silent-killer-feature-of-http-2/
ref:https://tools.ietf.org/html/rfc7541

HTTP/2 Server Push
用于服务端控制资源下发。服务端基于客户端已有的connection，发送PUSH_PROMISE header frame带上资源url以及预留的stream id给客户端，然后传输data frame将资源下发给客户端，期间客户端也可以控制Push参数。与一般客户端请求响应不一样的是，Push需要遵守same-origin policy以及服务端必须是authoritative。

RFC: https://tools.ietf.org/html/rfc7540#page-60

HTTP3

HTTP3是将传输层的TCP替换为基于UDP的QUIC协议，应用层对齐实现HTTP1/2的语法，从而解决TCP建立连接慢、队头拥塞等问题。目前HTTP3与QUIC标准处于Internet-Draft状态，还要经过Proposed Standard、Internet Standard两个阶段才能正式成为标准。客户端Chrome和Firefox仅在主线版本支持，另外也有三方库支持服务端/客户端HTTP3，具体见wiki资料。

wiki: https://en.wikipedia.org/wiki/HTTP/3

QUIC

QUIC最初被提案时是"Quick UDP Internet Connections"的缩写，是基于UDP的多路复用和安全的通用传输层协议。目前客户端有Chrome、Firefox、Opera、Curl支持，服务端有LiteSpeed、Nginx、Cloudflare支持，截至2019年8月，有3.2%的网站使用QUIC。区别于IETF(Internet Engineering Task Force)的标准QUIC，Google QUIC(gQUIC)本意是设计为通用协议在Chromium中支持HTTP(S)，同时也在跟进支持最新的QUIC标准。QUIC具有以下特性：
o Stream multiplexing
o Stream and connection-level flow control
o Low-latency connection establishment
o Connection migration and resilience to NAT rebinding
o Authenticated and encrypted header and payload

QUIC协议内容：
Connection
与服务端的连接。包括握手流程定义，传输协议、加密协议协商。connection ID用于定义endpoints之间的QUIC路由，即使某一端ip或端口改变了，也可以将数据传输中的connection迁移到新的地址，而不需要重新传输已送达的数据。类似IP报头的source/destination address，QUIC数据包Packet的header也包含Source Connection ID(非必须)和Destination Connection ID，这两个ID在双端定义了Packet归属于哪个connection，用于重组数据。ID在QUIC握手时初始化，连接过程中可能被改变。

Stream
用于传输有序字节流数据。分为单向unidirectional和双向bidirectional stream。可以在流程控制(flow control)和限制(stream limits)条件下同时创建任意多个stream传输任意大小的数据，但是不能保证不同stream中传输字节的顺序。发送数据是通过STREAM frames带上stream ID、Offset fields以及data，对端再根据ID和Offset进行重组。

Packet and Frame

• Packet和Frame是QUIC传输的基础单元，有规定的头部和payload。Packet是从功能角度将QUIC协议划分为不同类型的报文，例如Initial Packet是客户端跟服务端握手过程中的第一个初始化包，Retry Packet是服务端通知客户端重试的包。Frame是从数据类型角度将QUIC协议划分为不同类型的数据帧。例如Initial Packet的Payload字段填充的是CRYPTO frame，CRYPTO frame包含cryptographic handshake message, ACK frames, or both。
• QUIC将Stream分为Packet以及Frame传输是为了解决队头拥塞(head-of-line blocking)问题。Stream某个Packet丢失只需要重传这个Packet就可以，其他Packet不会因此阻塞。
• 一个UDP包可以装载多个Packet，一个Packet可以装载多个Frame。

关于Packet：

• Packet分为Long Header Packets和Short Header Packets，LHP用于控制类例如Version Negotiation/Initial/Handshake Packet等固定header较多的Packet。SHP用于建立连接后，用最少的overhead传输数据。
• 除了Version Negotiation和Retry类型，其他所有packet都用AEAD(authenticated encryption with additional data)方式加密保证数据的保密和完整性。
• 应用层可以在Packet中打包尽可能多的frames以减少带宽浪费和CPU消耗，但是等待新的frame可能导致Packet迟迟不发。

握手流程
下图是1-RTT握手流程，每行格式是"{packet_type}[{packet_num}]: {frame_type}[{frame_payload}] {frame_type1}[{frame_payload1}] ..."
1.客户端发送Initial包。包含客户端Source Connection ID(从0开始递增)以及TLS握手帧CRYPTO Frame(Client Hello bytes)。
2.服务端发送UDP包。UDP中包括三类Packet。Initial包，包含CRYPTO Frame(Server Hello bytes)以及ACK(请求的packet_num)；QUIC握手帧HandShake包，包含CRYPTO Frame(证书)；1-RTT encrypted包，包含数据帧STREAM Frame(Stream ID,帧Offset,数据长度以及字节数据)。
3.客户端发送UDP包。UDP中包括三类Packet。Initial包，包含ACK；HandShake包，包含结束的CRYPTO Frame以及ACK；1-RTT encrypted包，包含返回数据帧STREAM Frame以及ACK。
4.服务端发送UDP包。UDP中包括两类Packet。数据包1-RTT encrypted以及握手包HandShake。

下图是QUIC 0-RTT握手流程。与TLS Resumption热启动优化思路类似。具体流程见RFC。

流量控制(Flow Control)
流量控制是对接收方的数据缓冲大小限制，从而避免快速发送方碾压慢速接收方及恶意发送者大量消耗接收方内存的情况。同样，为了限制连接内的并发，QUIC终端控制其对端可以发起的最大累计stream。具体有以下几项：

• 数据流控制(Data Flow Control)。限制单个stream或单个connection接收的字节数。
• 流余额增量(Flow Credit Increments)。RFC未强制规定，只是提供了一些建议。例如服务端通过发送MAX_STREAM_DATA或MAX_DATA帧给客户端动态放水，控制流量。
• Stream取消机制(Handling Stream Cancellation)。当双端对流量控制策略不一致时，需要有取消机制结束或者重置Stream。RESET_STREAM或CONNECTION_CLOSE帧可以重置或关闭Stream。
• Stream总大小(Stream Final Size)。当RESET_STREAM或者有新的STREAM帧到达，如果实际的size跟预定的final size不一致，则发送FINAL_SIZE_ERROR帧。
• 并发控制(Controlling Concurrency)。只有stream ID小于(max_stream * 4 + initial_stream_id_for_type)才能被open。

连接迁移(Connection Migration)
当连接一方的地址发生改变，将旧连接迁移到新的地址上，避免重传已接收的数据。
必要条件：
因为QUIC在握手过程中地址必须不变，所以需要在握手完成之后才能发起连接迁移。
除了服务端使用Preferred Address情况下，迁移只能由客户端发起。
迁移步骤：
1.探测地址是否可达。客户端发送PATH_CHALLENGE帧(包含自定义Data)，服务端响应PATH_RESPONSE(包含请求的自定义Data)。如果发生超时，则地址不可达。同时为了确保服务端有可用的connection ID，客户端可以发送NEW_CONNECTION_ID帧创建新的connection。
2.(可选)初始化新的connection。重置拥塞控制congestion controller以及拥塞通知ECN capability。
3.发起迁移。客户端用新地址发送non-probing帧(除了PATH_CHALLENGE, PATH_RESPONSE, NEW_CONNECTION_ID, PADDING以外的帧类型)，服务端回包并且验证客户端地址，即可完成连接迁移。

常见网络攻击以及防御方案
Handshake Denial of Service
攻击方法：其目的在於使目標電腦的網路或系統資源耗盡，使服务暂时中斷或停止，导致其正常用户无法访问。例如针对TCP常见的SYN flood attack，不断发送SYN包要求服务器建立连接，导致所有端口被异常占用。
QUIC防御方案：加密握手完成后，所有包都是加密并且身份验证过，不符合的包会被丢弃。

Amplification Attack
攻击方法：思路是攻击者伪造目标IP向第三方发起请求，第三方返回更多数据给目标导致资源耗尽。针对QUIC攻击的具体实现是攻击者首先连接第三方获得address validation token，然后用此token以及目标IP发起0-RTT请求，伪造目标IP热启动，第三方验证热启动token合法，则发送0-RTT响应给目标IP。
防御方案：限制address validation tokens的使用和生命周期，例如短时间内不接收多个相同token。

Optimistic ACK Attack
攻击方法：增加ACK参数中收到数据长度，欺骗服务端传输比实际带宽要多得多的数据。
防御方案：QUIC在发送Packet时会累加packet numbers，所以服务端通过刻意跳过某些packet numbers刻意检测出客户端是否恶意发包。

Slowloris Attacks
Stream Commitment Attack
攻击方法：客户端创建尽可能多的connection或者stream，持续发送少量心跳数据，导致服务端资源被占用。
防御方案：通过接入层防御，部署QUIC时限制每个IP的连接数、限制长连接等。

Stream Fragmentation and Reassembly Attacks
攻击方法：发送方故意只发送stream部分数据，导致接收方需要创建整个stream大小的buffer或数据结构。或者接收方故意不发送ACK包，导致发送方一直持有并重传发送数据。
防御方案：根据可用内存限制flow control的window大小，防止内存占用超过资源。

Stateless Reset Oracle
攻击方法：思路是攻击者伪造RESET包使服务端正常连接被重置，类似的攻击有TCP reset injection，最常见的例子是访问google出现"The connection was reset"。QUIC的RESET包的stateless reset token是由static key以及connection ID计算得出，攻击者将正常Packet转发到其他共享static key并且没有connection的endpoint，则服务端会误以为connection不存在继而发送RESET包并且重置连接。
防御方案：服务端管理共享static key的endpoint，确保Packet能发送到有connection的endpoint。

Version Downgrade
攻击方法：通过版本协商使用低版本不安全的QUIC。
防御方案：QUIC标准暂无多版本的协商行为。

QUIC RFC: https://tools.ietf.org/html/draft-ietf-quic-transport-24
QUIC with TLS RFC: https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#name-introduction
中文QUIC RFC: http://docs.wxclimb.top/draft-ietf-quic-transport-zh.html#fc-credit

Challenges remaining for QUIC

网络基础设施已经基于TCP存在广泛的优化，但是对UDP是限速甚至是禁止。Google在早期实验中就存在少量连接被拒绝的问题。

Does QUIC make the world faster ?

对于网络耗时，论文[1]对比了HTTP2跟QUIC+SPDY，在不同网络环境下测试网页加载时间/资源请求耗时。结论是：

1. QUIC在少量小资源/大资源/弱网情况下占优：QUIC is faster (1.2-4.5X) when pages consist of few small-sized objects. QUIC also performs better when the page consists of large-sized objects. QUIC can achieve faster page loads in poor network conditions of lower bandwidth, high delay and lossy network.
2. QUIC在大量小资源情况下不如HTTP2：However, Page load with QUIC is slower (1.1-3.2X) when page consists of many small-sized objects. One possible reason for this is that the QUIC toy server is not optimized to be used efficiently with Chromium browser.

2019年论文[2]对TCP做业界通用的优化，对齐QUIC传输层参数，测试不同网络环境下页面加载/显示时间。结论是QUIC均优于TCP(HTTP2)，弱网环境下优势更明显。
还有资料[3]从实际应用角度提出对QUIC质疑。例如端对端加密限制网络链路的优化，CPU以及内存占用高，拥塞控制(congestion control)可能抢占其他类型的连接带宽等。

[1]P. Biswal, O. Gnawali, "Does QUIC make the Web faster?", Proc. IEEE GLOBECOM, pp. 1-6, Dec. 2016. http://www2.cs.uh.edu/~gnawali/papers/quic-globecom2016.pdf
[2]"A Performance Perspective on Web Optimized Protocol Stacks: TCP+TLS+HTTP/2 vs. QUIC" arXiv:1906.07415v1 [cs.NI] 18 Jun 2019. https://arxiv.org/pdf/1906.07415.pdf
[3]"QUIC and HTTP/3 : Too big to fail?!" https://calendar.perfplanet.com/2018/quic-and-http-3-too-big-to-fail/
https://en.wikipedia.org/wiki/QUIC#cite_note-QUIC_Design_Doc-3
https://blog.cloudflare.com/the-road-to-quic/
https://yucianga.info/?p=819

附录

常用请求码：
1xx（临时响应）
表示临时响应并需要请求者继续执行操作的状态代码。

代码 说明
100 Continue（继续） 请求者应当继续提出请求。 服务器返回此代码表示已收到请求的第一部分，正在等待其余部分。
101 Switching Protocols（切换协议） 请求者已要求服务器切换协议，服务器已确认并准备切换。

2xx （成功）
表示成功处理了请求的状态代码。

代码 说明
200 OK（成功） 服务器已成功处理了请求。 通常，这表示服务器提供了请求的网页。
201 Created（已创建） 请求成功并且服务器创建了新的资源。
202 Accepted（已接受） 服务器已接受请求，但尚未处理。
203 Non-Authoritative Information（非授权信息） 服务器已成功处理了请求，但返回的信息可能来自另一来源。
204 No Content（无内容） 服务器成功处理了请求，但没有返回任何内容。
205 Reset Content（重置内容） 服务器成功处理了请求，但没有返回任何内容。
206 Partial Content（部分内容） 服务器成功处理了部分 GET 请求。

3xx （重定向）
表示要完成请求，需要进一步操作。 通常，这些状态代码用来重定向。

代码 说明
300 Multiple Choices（多种选择） 针对请求，服务器可执行多种操作。 服务器可根据请求者 (user agent) 选择一项操作，或提供操作列表供请求者选择。
301 Moved Permanently（永久移动） 请求的网页已永久移动到新位置。 服务器返回此响应（对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置。
302 Found（临时移动） 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。
303 See Other（查看其他位置） 请求者应当对不同的位置使用单独的 GET 请求来检索响应时，服务器返回此代码。
304 Not Modified（未修改） 自从上次请求后，请求的网页未修改过。 服务器返回此响应时，不会返回网页内容。
305 Use Proxy（使用代理） 请求者只能使用代理访问请求的网页。 如果服务器返回此响应，还表示请求者应使用代理。
307 Temporary Redirect（临时重定向） 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。

4xx（请求错误）
这些状态代码表示请求可能出错，妨碍了服务器的处理。

代码 说明
400 Bad Request（错误请求） 服务器不理解请求的语法。
401 Unauthorized（未授权） 请求要求身份验证。 对于需要登录的网页，服务器可能返回此响应。
403 Forbidden（禁止） 服务器拒绝请求。
404 Not Found（未找到） 服务器找不到请求的网页。
405 Method Not Allowed（方法禁用） 禁用请求中指定的方法。
406 Not Acceptable（不接受） 无法使用请求的内容特性响应请求的网页。
407 Proxy Authentication Required（需要代理授权） 此状态代码与 401（未授权）类似，但指定请求者应当授权使用代理。
408 Request Timeout（请求超时） 服务器等候请求时发生超时。
409 Conflict（冲突） 服务器在完成请求时发生冲突。 服务器必须在响应中包含有关冲突的信息。
410 Gone（已删除） 如果请求的资源已永久删除，服务器就会返回此响应。
411 Length Required（需要有效长度） 服务器不接受不含有效内容长度标头字段的请求。
412 Precondition Failed（未满足前提条件） 服务器未满足请求者在请求中设置的其中一个前提条件。
413 Request Entity Too Large（请求实体过大） 服务器无法处理请求，因为请求实体过大，超出服务器的处理能力。
414 Request-URI Too Long（请求的 URI 过长） 请求的 URI（通常为网址）过长，服务器无法处理。
415 Unsupported Media Type（不支持的媒体类型） 请求的格式不受请求页面的支持。
416 Requested Range Not Satisfiable（请求范围不符合要求） 如果页面无法提供请求的范围，则服务器会返回此状态代码。
417 Expectation Failed（未满足期望值） 服务器未满足"期望"请求标头字段的要求。

5xx（服务器错误）
这些状态代码表示服务器在尝试处理请求时发生内部错误。 这些错误可能是服务器本身的错误，而不是请求出错。

代码 说明
500 Internal Server Error（服务器内部错误） 服务器遇到错误，无法完成请求。
501 Not Implemented（尚未实施） 服务器不具备完成请求的功能。 例如，服务器无法识别请求方法时可能会返回此代码。
502 Bad Gateway（错误网关） 服务器作为网关或代理，从上游服务器收到无效响应。
503 Service Unavailable（服务不可用） 服务器目前无法使用（由于超载或停机维护）。 通常，这只是暂时状态。
504 Gateway Timeout（网关超时） 服务器作为网关或代理，但是没有及时从上游服务器收到请求。
505 HTTP Version Not Supported（HTTP 版本不受支持） 服务器不支持请求中所用的 HTTP 协议版本。

HTTPS与HTTP区别，HTTPS和HTTP它们有什么不同？

HTTP 是过去很长一段时间我们经常用到的一种传输协议。HTTP 协议传输的数据都是 未加密的,这就意味着用户填写的密码、帐号、交易记录等机密信息都是明文,随时可能 被泄露、窃取、篡改,被黑客加以利用,因此使 HTTP 协议传输隐私信息非常不安全。

HTTPS 是一种基于 SSL 协议的网站加密传输协议,网站安装 SSL 证书后,使用 HTTPS 加密协议访问,可激活客户端浏览器到网站服务器之间的SSL 加密通道(SSL 协议),实现 高强度双向加密传输,防止传输数据被泄露或篡改。简单讲 HTTPS=HTTP+SSL,是 HTTP 的 安全版。

前期教程中我们分享了<<   >> <<>> 供大家参考学习!

今天关于Http与Https协议规范和http和https协议的讲解已经结束，谢谢您的阅读，如果想了解更多关于delphi idhttp访问http与https不同点、HTTP&HTTPS协议详解之HTTP篇、HTTP/HTTPS/HTTP2/HTTP3/QUIC/WebSocket协议详解、HTTPS与HTTP区别，HTTPS和HTTP它们有什么不同？的相关知识，请在本站搜索。