这是组内分享小明同学的分享课题，觉得不错，就拿过来放在资金的简书里面吧.

计算机网络

• 计算机网络，是指将地理位置不同的具有独立功能的多台计算机及其外部设备，通过通信线路连接起来，在网络操作系统，网络管理软件及网络通信协议的管理和协调下，实现资源共享和信息传递的计算机系统。
• 简单说就是用通信链路链接起来进行==资源共享==的计算机系统。
• 而制定了网络数据交换规则的计算机网络协议才是最重要的。要理解计算网络必须先知道这些协议。

网络架构-网络分层

- 两种分层结构(自顶向下)

1. 五层因特网协议栈分层利用的是网络协议来进行的分层。协议分层具有概念化和结构化的优点。
2. 七层OSI(著名的OSI/RM模型:Open System Interconnection/Reference Model)参考模型是国际标准化组织ISO(International Organization for
Standardization)在1978年提出了“开放系统互联参考模型”。

- 协议分层

1. 应用层

应用层是网络应用程序及它们的应用层协议存留的地方。

应用层协议包括HTTP(超文本传输协议：Web文档的请求和传送协议)、SMTP、POP3、IMAP(电子邮件报文的传送协议)、FTP(文件传送协议)、SIP(因特网电话协议)、DNS(域名系统协议)等。

image

简单介绍一些应用层的知识点：
1、为了规定如何在各种端系统上组织应用程序，应用程序开发者设计了两种主流的应用程序体系结构(application architecture),分别是：客户-服务器体系结构
(client-server architecture)和对等体系结构(P2P：Peer To Peer)。
1.1、CS体系结构有两大特征：一、有一个总是打开的主机，称为服务器，它为许多其他称为客户的主机的请求提供服务。二、服务器具有固定的、周知的IP地址。
1.2、P2P体系机构对位于数据中心的专用服务器有最小的或者没有的依赖，应用程序可以在间断连接的主机对之间使用直接通信。特点：极大对自扩展性，
     例如：分享文件应用，每个主机都可以是一个服务器。
2、应用程序之间的通信实际上是进程(process)间的通信。一个进程可以被认为是运行在端系统中的一个程序。
2.1、进程通过套接字（socket）向网络发送报文和接收报文。

2. 传输层

• 传输层在应用程序端点之间传送应用程序发出的报文(message)。使用TCP/UDP两个传输协议将报文重新组装成报文段(segment)再发送。
• 有两个不同的传输协议：TCP（传输控制协议）和UDP（用户数据报协议）。
• TCP为两台主机提供了可靠的数据通信。还提供了拥塞控制服务。拥塞控制防止了任何一条TCP连接用过多流量来淹没通信主机之间多链路和交换设备。
• UDP为应用层提供一种非常简单的服务。它只是把称作数据报的分组从一台主机发送到另一台主机，但并不保证该数据报能到达另一端。一个数据报是指从发送方传输到接收方的一个信息单元（例如，发送方指定的一定字节数的信息）。UDP协议任何必需的可靠性必须由应用层来提供。

3. 网络层

• 也称作互联网层，处理分组在网络中的活动，例如分组的选路。
• 在TCP/IP协议族中，网络层协议包括IP协议（网际协议），ICMP协议（Internet互联网控制报文协议），以及IGMP协议（Internet组管理协议）。
• IP是一种网络层协议，提供的是一种不可靠的服务，它只是尽可能快地把分组从源结点送到目的结点，但是并不提供任何可靠性保证。同时被TCP和UDP使用。TCP和UDP的每组数据都通过端系统和每个中间路由器中的IP层在互联网中进行传输。
• ICMP是IP协议的附属协议。IP层用它来与其他主机或路由器交换错误报文和其他重要信息。
• IGMP是Internet组管理协议。它用来把一个UDP数据报多播到多个主机。

4. 链路层

• 也称作数据链路层或网络接口层，通常包括操作系统中的设备驱动程序和计算机中对应的网络接口。它们一起处理与电缆（或其他任何传输媒介）的物理接口细节。ARP（地址解析协议）和RARP（逆地址解析协议）是某些网络接口（如以太网和令牌环网）使用的特殊协议，用来转换IP层和网络接口层使用的地址。

5. 物理层

• 电缆、光纤
• 交换机
• 路由器
• ……

- OSI模型其余分层

1.会话层

• 会话层(Session)是建立在传输层之上，利用传输层提供的服务，使应用建立和维持会话，并能使会话获得同步。会话层使用校验点可使通信会话在通信失效时从校验点继续恢复通信。
• 会话层的主要功能是在两个节点间建立、维护和释放面向用户的连接，并对会话进行管理和控制，保证会话数据可靠传送。
• 常见的会话层协议有：结构化查询语言（SQL）；远程进程呼叫（RPC）；X-windows 系统；AppleTalk 会话协议；数字网络结构会话控制协议（DNA SCP）等

2.表示层

• 表示层如同应用程序和网络之间的翻译官，主要解决用户信息的语法表示问题，即提供格式化的表示和转换数据服务。数据的压缩、解压、加密、解密都在该层完成。
• 表示层负责在不同的数据格式之间进行转换操作，以实现不同计算机系统间的信息交换。 两台计算机之间的信息交换除了编码外，还包括数组、浮点数、记录、图像、声音等多种数据结构，表示层用抽象的方式来定义交换中使用的数据结构，并且在计算机内部表示法和网络的标准表示法之间进行转换。
• 表示层还负责数据的加密，以在数据的传输过程对其进行保护。数据在发送端被加密，在接收端解密。使用加密密钥来对数据进行加密和解密。表示层还负责文件的压缩，通过算法来压缩文件的大小，降低传输费用。

具体协议的介绍

1、IP协议（Internet Protocol），网络之间互连的协议

• 为计算机网络相互连接进行通信而设计的协议。
• 是网络层中最重要的协议，是整个Internet的协议基础；负责分配IP地址，提供路由；
• IP协议是==不可靠的传输协议==。
• IP地址分类：

A类:1.0.0.0~126.255.255.255,默认子网掩码/8,即255.0.0.0 (其中127.0.0.0~127.255.255.255为环回地址,用于本地环回测试等用途，
    其中0.0.0.0到0.255.255.255也是保留地址，用做表示所有的IP地址。)；

B类:128.0.0.0~191.255.255.255,默认子网掩码/16,即255.255.0.0；

C类:192.0.0.0~223.255.255.255,默认子网掩码/24,即255.255.255.0；

D类:224.0.0.0~239.255.255.255,一般于用组播，多点播送信息；

E类:240.0.0.0~255.255.255.255(其中255.255.255.255为全网广播地址),E类地址一般用于研究用途

• 子网掩码

- 用来指明一个IP地址所标示的主机处于哪个子网中。
例子：192.168.10.2➡172.16.10.2发送数据。
    IP地址为：192.168.10.2，子网掩码是255.255.255.0，IP地址为：172.16.10.2，子网掩码是255.255.0.0。
    按位与运算后分别是：192.168.10.0、172.16.0.0。
    不同表示不在同一个网段内。数据需要往外网发送。
    路由器转发数据报的时候用172.16.10.2和子网掩码做位与运算，得到172.16.0.0。
    然后在表中进行查询，如果与本地IP相同，则已经到达目的端，由当前路由解析数据；
    如果表中查询到有下一跳的路由IP，继续进行路由转发；
    在当前路由器中查询不到下一跳地址，即转向默认的下一跳IP(缺省路由)。

• 查询本地路由表：netstat -r

2、ARP协议（Address Resolution Protocal) ，地址解析协议

• 作用是根据IP地址获取物理MAC地址。==交换机是处理MAC地址来进行数据存储转发的==。
• 主机发送信息时将包含目标IP地址的ARP请求广播到网络上的所有主机（==全网广播==），并接受对应IP地址的主机返回的物理地址。
• 接收的返回消息后将该IP地址和物理地址存入本机并保留一段时间（采用==缓存老化机制==），下次请求时直接查询ARP缓存以节约时间。(即本地在有效时间段内缓存一张IP-MAC地址映射表)
• ARP代理（ARP Proxy）：发送主机和目的主机不在同一局域网内，即使发送主机知道了目的主机的真实MAC地址，也是不能直接通信的，需要经过路由转发出去才可以。所以发送主机由全网广播得到的MAC地址其实不是目的主机的真实MAC地址，而是一台可以通往目的主机的路由器的MAC地址。所以发送主机发送给目的主机的所有数据包都会发往这台路由器，通过它向外发送。
• 查询本地ARP表：arp -a****

3、RARP协议（Reverse Address Resolution Protocol），反向地址转换协议

• 作用与ARP相反，负责将物理层地址转换为IP地址。
• 允许局域网物理机器从网关服务器的ARP表或缓存上请求主机的IP地址。
• RARP 可以使用于以太网、光纤分布式数据接口及令牌环 LAN。。。

4、ICMP（Internet Control Message Protocol），Internet控制报文协议

• 用于在IP主机、路由器之间传递控制消息。它就是一个“错误侦测与回报机制”，其目的就是让我们能够检测网路的连线状况﹐也能确保连线的准确性。
• 主要功能有：

1、侦测远端主机是否存在。
2、建立及维护路由资料。
3、重导资料传送路径（ICMP重定向）。
4、资料流量控制。

• 使用：

1、ping (目的IP/DNS域名)
2、tracert(win)/traceroute(mac) (目的IP) 可以显示中间经过的路由器
control+Z结束发送ICMP报文。

5、UDP协议（User Data Protocol，用户数据报协议）

• UDP协议在IP的数据报服务之上添加了复用、分用和差错检验。
• UDP协议特征：

1.无连接，即发送数据之前不需要建立连接。无连接的好处就是快，省内存空间。因为维护连接需要创建大量的数据结构，在这里都不需要。
2.UDP尽最大努力交付数据，即不保证可靠交付。没有TCP的确认机制、重传机制。如果因为网络原因没有传送到对端，UDP也不会给应用层返回错误信息。
3.面向数据报文。对于应用层交付下来的报文在添加了首部就直接交付于ip层，不会进行合并，也不会进行拆分。这就说明UDP一次交付一个完整的报文。
  正是因为这样，UDP显得不够灵活，不能控制读写数据的次数和数量。
  比如我们要发送100个字节的报文，我们调用一次sendto函数就会发送100字节，
  对端也需要用recvfrom函数一次性接收100字节，不能使用循环每次获取10个字节，获取十次这样的做法。
4.没有拥塞控制，所以当网络出现的拥塞不会导致主机发送数据的速率降低。这个在对实时应用来说很重要，比如：视频通话、直播等应用。
5.UDP支持一对一、一对多、多对一、多对多的交互通信。
6.UDP的首部只有8个字节，开销小。

• UDP报文段格式

[图片上传失败...(image-1473e5-1551839300985)]

1.UDP报文段头部总共8字节。
2.检验和提供了差错检测功能。即用于确定当UDP报文段从源到达目的地移动时，其中的比特是否发生了变化。

• 检验和运算（生成校验和及UDP报文的错误校验机制&计算过程）

计算方法：
1.按每16位求和，校验和初始值为0；
2.如果求和时遇到了任何的溢出，则需要做"回卷"（溢出位加到新值末尾）；
3.加完所有报文段中的数据，最后使用"反码"运算得出校验和，组装发送给接收方。
4.接收方接收到报文段后，重复1、2步骤。最后 再和校验和值求和。
5.结果：如果报文段没有引入差错，最后求和结果应该为1111111111111111。
       如果引入了差错，最后16位求和结果肯定包含0。

image

• 基于UDP的应用层协议

NFS：网络文件系统
TFTP：简单文件传输协议
DNS：域名解析协议
DHCP：动态主机配置协议
SNMP：简单网络管理协议

6、DNS域名解析协议

• 概念

DNS协议也可以叫做因特网的目录服务协议。因为它就是为了便于大家记忆主机地址而设计出来的，它的作用就是将便于人记忆的主机名解析为便于电子设备解析的IP地址。

比较直观的例子就是：百度

• 工作原理概述

DNS协议层级从上到下划分

1. 根DNS服务器
2. 顶级域DNS服务器
3. 权威DNS服务器
4. 本地DNS服务器
5. 操作系统本地DNS缓存
6. 浏览器本地DNS缓存

模拟一个http请求过程中的域名解析过程

1. 浏览器开始请求，先检查浏览器本地DNS缓存中是否存在域名对应的IP地址，如果有，解析结束，更新缓存时间。如果没有，继续走。
2. 浏览器接着检查操作系统中的本地DNS缓存中是否存在域名对应的IP地址，如果有，解析结束，更新缓存时间。如果没有，继续走。
3. 开始请求本地DNS服务器来解析域名，如果命中，解析结束，更新缓存时间。如果没有，继续走。（这台服务器相当于一台代理解析服务器，距离主机相对较近，并且具有较好的性能，大约80%的域名解析都在这一层级的服务器中完成）
4. 本地DNS服务器将请求域名发送给根DNS服务器解析。
5. 根DNS服务器返回给本地DNS服务器一个请求域名所在的顶级域DNS服务器地址。
6. 本地DNS服务器拿到顶级域DNS服务器的地址，并向它发送请求域名进行解析。
7. 顶级域DNS服务器返回给本地DNS服务器一个请求域名所在的权威DNS服务器地址。（权威DNS服务器即请求域名注册时所使用的服务器）
8. 权威DNS服务器根据域名-IP映射关系表查询到对应IP地址，返回给本地DNS服务器。
9. 本地DNS服务器收到IP地址，返回给浏览器，并向向表中缓存一条新的映射关系。
10. 浏览器收到解析结果IP，缓存到本地。域名解析过程结束，继续HTTP请求。

• 图解

image

7、TCP协议（Transmission Control Protocol 传输控制协议）

• TCP协议是一种面向连接的、可靠的、基于字节流的传输层通信协议
• 熟悉一遍TCP字节流头部

image

1、16位源端口号：16位的源端口中包含初始化通信的端口。源端口的作用是标识报文的返回地址。
2、16位目的端口号：16位的目的端口域定义传输的目的。
3、32位序号：表明了发送的数据报的顺序。
4、32位确认序号：希望收到的下一个数据报的序号。
5、4位首部长度：记录着TCP首部长度，指明何处数据开始。
6、保留（6位）：6位值域，这些位必须是0。为了将来定义新的用途而保留。
7、标志：6位标志域。表示为：紧急标志、有意义的应答标志、推、重置连接标志、同步序列号标志、完成发送数据标志。按照顺序排列是：URG、ACK、PSH、RST、SYN、FIN。
   这6位详细信息在下面介绍。
8、16位窗口大小：用来表示想收到的每个TCP数据报的大小。TCP的流量控制由连接的每一端通过声明的窗口大小来提供。
9、16位校验和：发送端基于数据内容计算校验头部、数据和伪TCP头部之和，接收端要与发送端数值结果完全一样，从而证明数据的有效性。
10、16位紧急指针：在标志URG=1时才有效。加快处理标示为紧急的数据段。
11、选项：可选设置项。长度不定，最长40个字节。（时间戳计算往返时间）
12、数据：该TCP数据报负载的数据。

• 6个标志域

URG：紧急标志。紧急标志为"1"表明该位有效。
ACK：确认标志。为1表明32位确认序号有效。为0表明数据报不包含确认序号信息。
PSH：推标志。该标志为1时，接收端不将该数据进行队列处理，而是尽可能快地将数据转由应用处理。
RST：复位标志。用于复位相应的TCP连接。
SYN：同步标志。表明建立连接
FIN：四次挥手结束标志。表明四次挥手断开TCP连接。

• TCP三次握手

[图片上传失败...(image-93899f-1551839300985)]

所谓三次握手（Three-Way Handshake）即建立TCP连接，就是指建立一个TCP连接时，需要客户端和服务端总共发送3个包以确认连接的建立。

1、第一次握手：Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Client进入SYN_SENT状态，等待Server确认。
2、第二次握手：Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，
   并将该数据包发送给Client以确认连接请求，Server进入SYN_RCVD状态。
3、第三次握手：Client收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，
   并将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入ESTABLISHED状态，完成三次握手，
   随后Client与Server之间可以开始传输数据了。

• TCP四次挥手

[图片上传失败...(image-2ad7c1-1551839300985)]

四次挥手（Four-Way Wavehand）即终止TCP连接，就是指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开

1、第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。
2、第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。
3、第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。
4、第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。

• 问题

为什么TCP握手是三次???

答：TCP是可靠的传输控制协议，三次握手能保证数据可靠传输又能提高传输效率。

如果TCP的握手是两次： 即server端发送ACK确认报文就成功建立连接
并且假设TCP发送ACK确认的报文丢失，但是此时server端已经是Established状态。
client端因为没有收到ACK确认报文，开始重新发送SYN请求建立连接报文，
但是server端此时却已经是Established状态，认为已经建立好了连接。逻辑冲突。

如果TCP的握手是三次就可以避免上面这种情况：
因为即使TCP发送ACK确认的报文丢失，但是server端也还是SYN_receive状态，
client端因为没有收到ACK确认报文，开始重新发送SYN请求建立连接报文，
server端收到SYN请求建立连接报文，会重新发送一个ACK确认报文。

如果TCP的握手是四次： 
1.client给server发送SYN同步报文； 
2.server收到SYN后，给client回复ACK确认报文； 
3.server给client发送SYN同步报文； 
4.client给server发送ACK确认报文。 
第2.3步之间，server和client没有任何的数据交互，分开发送相当于多发了一次TCP报文段，
SYN和ACK标识只是TCP报头的一个标识位。很明显，这两步可以合并，从而提高连接的速度和效率。

为什么TCP挥手是四次???

答：原因是client和server两端都需要一个FIN和ACK报文，
但是假设client端发送了一个FIN报文后，server端回复一个ACK确认报文，
这仅仅表示client端不会再发送数据了，却还能接收数据，
server端也未必把数据发送给了client端。
所以要真正关闭连接需要server端发送完剩余数据后，再发送给client端一个FIN报文。
得到client端的ACK报文后，才说明TCP已经断开连接。

假设：如果挥手的第2、3步合起来，和握手的第2步类似，有可行性吗？
答：不可能。如果server端还有大量数据需要几个MSL的时间才能发送完，回复给client端的ACK确认报文就会延时几个MSL的时间，
导致client重试而发送多个FIN报文，直到得到ACK确认报文。

为什么建立连接需要三次握手，而断开连接需要四次握手???

答：这是因为server端在Listen状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。
而关闭连接时，当收到client端的FIN报文时，仅仅表示client端不再发送数据了但是还能接收数据，server端也未必全部数据都发送给client端了，
所以server端可以立即close，也可以发送一些数据给client端后，再发送FIN报文给client端来表示同意现在关闭连接，
因此，server端ACK和FIN一般都会分开发送。

为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？？？

1、保证TCP协议的全双工连接能够可靠关闭
2、保证这次连接的重复数据段从网络中消失

第一点，如果client直接CLOSED了，那么由于IP协议的不可靠性或者是其它网络原因，导致server没有收到client最后回复的ACK。
那么server就会在超时之后继续发送FIN，此时由于client已经CLOSED了，就找不到与重发的FIN对应的连接，
最后server就会收到RST而不是ACK，server就会以为是连接错误把问题报告给高层。
这样的情况虽然不会造成数据丢失，但是却导致TCP协议不符合可靠连接的要求。
所以，client不是直接进入CLOSED，而是要保持TIME_WAIT，当再次收到FIN的时候，能够保证对方收到ACK，最后正确的关闭连接。

第二点，如果Client直接CLOSED，然后又再向Server发起一个新连接，我们不能保证这个新连接与刚关闭的连接的端口号是不同的。
也就是说有可能新连接和老连接的端口号是相同的。一般来说不会发生什么问题，但是还是有特殊情况出现：
假设新连接和已经关闭的老连接端口号是一样的，如果前一次连接的某些数据仍然滞留在网络中，这些延迟数据在建立新连接之后才到达Server，
由于新连接和老连接的端口号是一样的，又因为TCP协议判断不同连接的依据是socket pair，
于是，TCP协议就认为那个延迟的数据是属于新连接的，这样就和真正的新连接的数据包发生混淆了。
所以TCP连接还要在TIME_WAIT状态等待2倍MSL，这样可以保证本次连接的所有数据都从网络中消失。
" MSL是Maximum Segment Lifetime的英文缩写，可译为“最长报文段寿命”，它是任何报文在网络上存在的最长的最长时间，超过这个时间报文将被丢弃。"

8.HTTP协议(Hyper Text Transfer Protocol(超文本传输协议))

• 超文本是用超链接的方法，将各种不同空间的文字信息组织在一起的网状文本。
• HTTP协议是用于从万维网（WWW:World Wide Web ）服务器传输超文本到本地浏览器的传送协议。

https://lrh1993.gitbooks.io/android_interview_guide/content/computer-networks/http.html

• HTTP是一个基于TCP/IP通信协议来传递数据（HTML 文件, 图片文件, 查询结果等）的应用层协议。
• 特征：无状态

服务器向客户发送被请求的文件，但是不会存储任何关于客户的状态信息。
假如一个客户在短时间内多次请求了同一个链接地址，服务器并不会因为刚刚为客户提供了响应就不再作出反应，
而是会多次重新发送同一个超文本内容给客户，就像是服务器已经完全忘记了不久之前所做过的事。
因为HTTP协议不会保存客户的信息，所以说HTTP是一个"无状态协议"。

• HTTP 请求报文格式

image

//请求行
GET /Service/IndexSvr.svc/GetIndexPage?modilarId=115554&pageNo=1&styleId=460&appId=136&appKey=d0779&projectId=1 HTTP/1.1
//请求头部/首部行 start
random: 999
token: a54e970b848cd3624ce2cba0408d4bb413ece1f5c57194a14ba17b6afe61fcbd2b8182ebf929d0c22db7a3962cad62ed7549e346566be05f15d7064ffa5cd5bd1541742453270
Host: testparty.api.xinhuaapp.com
Accept-Encoding: gzip
User-Agent: okhttp/3.10.0
Connection: keep-alive
//请求头部/首部行 end
//空行<CR><LF>
--------------------------分割线-------------------------------
//请求行
POST /Service/UserSvr.svc/GetPushList HTTP/1.1
//请求头部/首部行 start
random: 999
token: c1686787683cce8334f3396f3a2198df0194e4a8786c4ebb902379ae7cac5d10b5dd2457bf890ba79e21c7cc376b528c6985065e31857bfeb758c287df9cfa6a1542013083957
Content-Type: application/json; charset=UTF-8
Content-Length: 89
Host: testcloudapi.xinhuaapp.com
Accept-Encoding: gzip
User-Agent: okhttp/3.11.0
Connection: keep-alive
//请求头部/首部行 end
//空行<CR><LF>
//实体体
{"messageType":0,"pageNo":1,"adminId":9633,"appId":110083,"appKey":"xy001","projectId":4}

• 常见请求方法

HTTP/1.0定义了3种请求方法：GET, POST, HEAD。
HTTP/1.1新增了5种请求方法：OPTIONS, PUT, DELETE, TRACE, CONNECT。

GET      请求指定的资源。
HEAD     类似于get请求，用于获取报头，没有资源内容。
POST     传输实体对象数据，向指定资源请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。
PUT      用于传输文件。
DELETE   请求服务器删除指定的资源。
CONNECT  HTTP/1.1协议中的请求方法。客户端与代理服务器通信时建立隧道，实现用隧道协议进行 TCP 通信。
         主要使用 SSL（Secure Sockets Layer，安全套接层）和 TLS（Transport Layer Security，传输层安全）协议把通信内容加 密后经网络隧道传输。
OPTIONS  允许客户端查看服务器的性能。例如：查询后台支持的请求方法。
TRACE    回显服务器收到的请求，主要用于测试或诊断。

• HTTP响应报文

image

//状态行
HTTP/1.1 200 OK
/* 首部行 start */
Server: openresty
Date: Mon, 19 Nov 2018 12:56:48 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 79788
Cache-Control: private
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Connection: keep-alive
/* 首部行 end */
//空行
//实体体
{"Data":{"AdvertBoxData":{"PopupBox":null,"SuspendBox":null},"Focus":[{"DisplayMode":"DNWS002","Template":"TNWS004","ActionColor":"","AuditPolicy":0,"BackGroundUrl":"","CanComment":0,"CompanyIcon":"","CompanyName":"","ContentType":0,"Fixed":0,"Id":98,"ImgUrl":"http:\/\/xinhuaapp-img.img.aliyuncs.com\/Party\/1\/136\/modilar\/2018\/03\/21\/2018032116054916584459.jpg?x-oss-process=image\/crop,x_0,y_0,w_978,h_679\/quality,q_80\/format,jpg","ImgUrlAction":"","IsDefault":0,"IsInLink":0,"IsIndex":0,"IsShare":0,"IssueTime":"\/Date(1533623226840+0800)\/","IssueTimeText":"2018-08-07","LastContentImg":"","LastContentTitle":"","LinkUrl":"http:\/\/www.baidu.com","Meno":"","ModilarSub":[],"ModliarTitle":"","ShareUrl":"http:\/\/www.baidu.com","Sorts":0,"SoundUrl":"","Source":"","SubModilars":0,"Tags":null,"TagsColor":null,"Title":"【推广】打一行整的咔","UpdateTimeStamp":0,"VodUrl":""}]}}
---------------------------分割线-------------------------
HTTP/1.1 200 OK
Server: openresty
Date: Mon, 19 Nov 2018 12:58:27 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 783
Cache-Control: private
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Connection: keep-alive

{"Data":[{"ContentTitle":"","CreateUser":9653,"DeadLine":"2018-11-19Monday20:58","MessageType":16,"ObjId":676,"PushContent":"[wwww]已通过您的选题","PushId":19966,"PushTime":"2018-11-14 17:21","ReleaseName":"","Template":"","Title":"选题消息"},{"ContentTitle":"","CreateUser":9633,"DeadLine":"2018-11-19Monday20:58","MessageType":8,"ObjId":1811395,"PushContent":"[陈明军]已退回您的稿件","PushId":9926,"PushTime":"2018-10-24 15:02","ReleaseName":"","Template":"","Title":"稿件消息"},{"ContentTitle":"","CreateUser":9624,"DeadLine":"2018-11-19Monday20:58","MessageType":4,"ObjId":611,"PushContent":"[测试]已完成任务","PushId":19999,"PushTime":"2018-11-19 16:15","ReleaseName":"","Template":"","Title":"任务消息"}],"Message":"操作成功","Status":1}

• 常见响应状态码

1** 信息，服务器收到请求，需要请求者继续执行操作
2** 成功，操作被成功接收并处理
3** 重定向，需要进一步的操作以完成请求，比如说存取缓存操作
4** 客户端错误，请求包含语法错误或无法完成请求
5** 服务器错误，服务器在处理请求的过程中发生了错误

• 常见header

1. 内容编码

Accept-Encoding:gzip,compress,deflate,identity 代表请求方通知接收方，可以用的内容压缩编码格式。

Content-Encoding:gzip/compress/deflate/identity 代表报文内容压缩的编码格式，接收方通过指定的编码格式进行解压。

2. 传输编码

Transfer-Encoding:chunked(分块传输)/gzip/compress/deflate/identity

规定了传输报文主体时采用的编码方式。

当传输大量数据而无法获得报文主体长度(Content-Length)时，分块传输方式就起到了非常重要的作用，因为它可以逐块表明长度。

chunked

数据以一系列分块的形式进行发送。 Content-Length 首部在这种情况下不被发送。。
在每一个分块的开头需要添加当前分块的长度，以十六进制的形式表示，后面紧跟着 '\r\n' ，之后是分块本身，后面也是'\r\n' 。
终止块是一个常规的分块，不同之处在于其长度为0。终止块后面是一个挂载（trailer），由一系列（或者为空）的实体消息首部构成。

3. Connection

Connection:keep-alive/close 代表HTTP使用持久连接/关闭连接。

Connection:控制代理不再转发的首部字段

image

4. Trailer

事先说明在报文内容主体后记录了哪些字段首部字段

示例：

headers...
Transfer-Encoding: chunked
Trailer:Expires
body...
0//分块长度
Expires:Tue,23 Sep 2019 23:23:22 GMT
body...
7
Expires:Tue,23 Sep 2019 23:23:22 GMT
body...
9
Expires:Tue,23 Sep 2019 23:23:22 GMT
}

- cookie技术

image

1.背景
  因为HTTP是无状态的连接，所以服务器并未保存客户端的信息。
  但是一些Web服务器因为功能需求的原因，恰恰需要能够识别用户。
  例如最典型的记录用户访问次数、购物网站中的购物车功能。
  所以HTTP使用了cookie。
2.cookie的4个组成部分
  Ⅰ.在HTTP响应报文中的cookie首部行：Set-Cookie:myCookie=123;domain=www.baidu.com;path=/one/;expires=Mon,22-Jan-07 07:10:24 GMT;Secure;HttpOnly
  Ⅱ.在HTTP请求报文中的cookie首部行：Cookie: $Version=1; Skin=new;
  Ⅲ.在客户端系统浏览器中保存了一个cookie文件。
  Ⅳ.在Web服务器的一个数据库表中。
3.cookie的属性
  String name：该Cookie的名称。Cookie一旦创建，名称便不可更改。 
  int maxAge：该Cookie失效的时间，单位秒。如果为正数，则该Cookie在>maxAge秒之后失效。如果为负数，该Cookie为临时Cookie，关闭浏览器即失效，浏览器也不会以任何形式保存该Cookie。如果为0，表示删除该Cookie。默认为–1。 
  Boolean secure：该Cookie是否仅被使用安全协议传输。安全协议。安全协议有HTTPS，在网络上传输数据之前先将数据加密。默认为false。 
  String path：该Cookie的使用路径。如果设置为“/sessionWeb/”，则只有contextPath为“/sessionWeb”的程序可以访问该Cookie。如果设置为“/”，则本域名下contextPath都可以访问该Cookie。注意最后一个字符必须为“/”。
  String domain：可以访问该Cookie的域名。如果设置为“.google.com”，则所有以“google.com”结尾的域名都可以访问该Cookie。注意第一个字符必须为“.”。 
  String comment：该Cookie的用处说明。浏览器显示Cookie信息的时候显示该说明。 
  int version：该Cookie使用的版本号。0表示遵循Netscape的Cookie规范，1表示遵循W3C的RFC 2109规范。
  Object value：该Cookie的值。如果值为Unicode字符，需要使用字符编码。如果值为二进制数据，则需要使用BASE64编码。 
4.cookie的争议
  Ⅰ.被讨论最多的就是隐私问题
  Ⅱ.Cookie引入的各种安全问题
  Ⅲ.与REST软件架构相背离。Web 应用程序最重要的 RESTful 原则是，客户端和服务器之间的交互在请求之间是无状态的。
  Ⅳ.过多使用浪费HTTP请求流量。

An <a href="http://tools.ietf.org/html/rfc6265">RFC 6265</a> Cookie.

image

• expiresAt:If a cookie has both the Max-Age and the Expires attribute, the Max-Age attribute has precedence and controls the expiration date of the cookie. If a cookie has neither the Max-Age nor the Expires attribute, the user agent will retain the cookie until "the current session is over" (as defined by the user agent).
• 有效时间：如果cookie同时具有Max-Age和Expires属性，那么Max-Age属性==优先控制==cookie的过期日期。如果cookie既没有Max-Age属性，也没有Expires属性，则用户代理将保留cookie，直到“==当前会话结束==”(由用户代理定义)。
• httpOnly:The HttpOnly attribute limits the scope of the cookie to HTTP requests. In particular, the attribute instructs the user agent to omit the cookie when providing access to cookies via "non-HTTP" APIs (such as a web browser API that exposes cookies to scripts). Note that the HttpOnly attribute is independent of the Secure attribute: a cookie can have both the HttpOnly and the Secure attribute.
• httpOnly：HttpOnly属性将cookie的范围限制为HTTP请求。该属性指用户通过“==非http==”API(例如向脚本(例如：JavaScript)公开cookie的web浏览器API)时将==没有权限访问cookie==。注意，HttpOnly属性独立于Secure属性:cookie可以同时拥有HttpOnly和Secure属性。

HTTPS（HTTP Secure，超文本传输安全协议）

1、HTTP协议的主要不足

Ⅰ.通信使用明文（不加密），内容可能会被窃听
Ⅱ.不验证通信方的身份，因此有可能遭遇伪装
Ⅲ.无法证明报文的完整性，所以有可能已遭篡改

2、解决办法

1.加密处理防止被窃听
  Ⅰ.内容加密
    将参与通信的内容本身加密的方式。由于 HTTP 协议中没有加密机制，那么就对 HTTP 协议传输的内容本身加密。
    即把 HTTP 报文里所含的内容进行加密处理。
    有一点必须引起注意，由于该方式不同于 SSL 或 TLS 将整个通信线路加密处理，所以内容仍有被篡改的风险。
  Ⅱ.通信加密
    通过和SSL（Secure Socket Layer，安全套接层协议）或TLS（Transport LayerSecurity，安全层传输协议）的组合使用，加密 HTTP 的通信内容。
    用 SSL 建立安全通信线路之后，就可以在这条线路上进行 HTTP 通信了。
    与 SSL 组合使用的 HTTP 被称为 HTTPS（HTTP Secure，超文本传输安全协议）或 HTTP over SSL。
2.检测数字证书防止遭遇伪装
  HTTP 协议（无状态协议）无法确定通信方，但使用 SSL 则可以。
  SSL 不仅提供加密处理，而且还使用了一种被称为证书的手段，可用于确定通信方。
  证书由值得信任的第三方机构颁发，用以证明服务器和客户端是实际存在的。
  有名的三方证书机构：威瑞信（VeriSign）
  通过使用证书，以证明通信方就是对的服务器。这对客户端个人来讲，也减少了个人信息泄露的危险性。
3.利用SSL协议的数字摘要和数字签名功能保证数据完整性
  Ⅰ.数字摘要是采用单向Hash函数将需要加密的明文“摘要”成一串固定长度（128位）的密文，这一串密文又称为数字指纹，
    它有固定的长度，而且不同的明文摘要成密文，其结果总是不同的，而同样的明文其摘要必定一致。
    “数字摘要”是https能确保数据完整性和防篡改的根本原因。
  Ⅱ.数字签名技术就是对“非对称密钥加解密”和“数字摘要”两项技术的应用，它将摘要信息用发送者的私钥加密，与原文一起传送给接收者。
    接收者只有用发送者的公钥才能解密被加密的摘要信息，然后用Hash函数对收到的原文产生一个摘要信息，与解密的摘要信息对比。
    如果相同，则说明收到的信息是完整的，在传输过程中没有被修改，否则说明信息被修改过，因此数字签名能够验证信息的完整性。

3、了解SSL/TLS协议&版本

1. SSL（Secure Socket Layer，安全套接字层）
  SSL为Netscape所研发，用以保障在Internet上数据传输之安全，利用数据加密技术，可确保数据在网络上传输过程中不会被截取，当前为3.0版本。
  SSL协议可分为两层：
  SSL记录协议（SSL Recore Protocol）：它建立在可靠地传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。
  SSL握手协议（SSL Handshake Protocol）：它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份证、协商加密算法、交换加密密钥等。

2. TLS（Transport Layer Security，传输层安全协议）
  用于两个应用程序之间提供保密性和数据完整性。
  TLS 1.0是IETF（Internet Engineering Task Force，Internet工程任务组）制定的一种新的协议，它建立在SSL 3.0协议规范之上，
  是SSL 3.0的后续版本，可以理解为SSL 3.1。
  该协议由两层组成：TLS记录协议（TLS Recore）和TLS握手协议（TLS Handshake）。

3. SSL/TLS协议作用
  Ⅰ.认证用户和服务器，确保数据发送到正确的客户机和服务器；（意思是HTTP的可能会发送到不正确的客户机和服务器）
  Ⅱ.加密数据以防止数据中途被窃取。
  Ⅲ.维护数据的完整性，确保数据在传输过程中不被改变。

1.混合加密机制
  Ⅰ.对称加密
    对称加密（也叫私钥加密）指加密和解密使用相同密钥的加密算法。
    有时又叫传统密码算法，就是加密密钥能够从解密密钥中推算出来，同时解密密钥也可以从加密密钥中推算出来。
    而在大多数的对称算法中，加密秘钥和解密密钥是相同的，所以也称这种加密算法为秘密密钥算法或者单密钥算法。
    常见的对称加密有：DES（Data Encryption Standard）、AES（Advanced Encryption Standard）、RC4、IDEA等。
    缺陷：容易被解密。
  Ⅱ.非对称加密
    与对称加密算法不同，非对称加密算法需要两个密钥：公开密钥（publickey）和私有密钥（privatekey）。
    公开密钥与私有密钥是一对，如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。
    因为加密和解密使用的是两个不同的密钥，所以这种算法叫作非对称加密算法。
    常见的非对称加密算法有：RSA、Elgamal、背包算法、Rabin、D-H、ECC（椭圆曲线加密算法）等。
    缺陷：加解密处理时间相对较长。
  Ⅲ.HTTPS采用混合加密
    充分利用以上两个加解密机制的优点。
    "在交换密钥阶段使用非对称加密"。
    "在交换报文阶段则使用对称加密"。
    总结起来就是使用非对称加密交换之后的密钥，拿来作为之后交换报文段的对称加密所使用的密钥。

[图片上传失败...(image-7470b1-1551839300985)]

公钥是如何获取的？如何安全地获取？
难道又是由非对称加密传输完成？这样只会陷入鸡生蛋蛋生鸡，永无止境的困局。
这里我们引入了数字证书的概念。

2.简单介绍证书验证原理
  Ⅰ.服务端首先把自己的公钥发给证书颁发机构，向证书颁发机构申请证书。
  Ⅱ.证书颁发机构自己也有一对公钥私钥。机构利用自己的私钥来加密服务端的公钥，并且通过服务端网址等信息生成一个证书签名，证书签名同样经过机构的私钥加密。证书制作完成后，机构把证书发送给服务端。
  Ⅲ.服务端把自己申请的证书返回给客户端。
  Ⅳ.客户端收到证书以后，要做的第一件事情是验证证书的真伪。需要说明的是，"各大浏览器和操作系统已经维护了所有权威证书机构的名称和公钥"。
  所以客户端只需要知道是哪个机构颁布的证书，就可以从本地找到对应的机构公钥，解密出证书签名。
  客户端按照同样的签名规则，自己也生成一个证书签名，如果“两个签名一致”，说明证书是有效的。
  验证成功后，客户端就可以放心地再次利用机构公钥，解密出服务端的公钥Key1。
  Ⅴ.客户端生成自己的对称加密密钥Key2，并且用服务端公钥Key1加密Key2，发送给服务端。
  Ⅵ.服务端用自己的私钥解开加密，得到对称加密密钥Key2。于是两人开始用Key2进行对称加密的通信。

image

• HTTP和HTTPS的区别

1.HTTPS协议需要到CA申请证书，一般免费证书很少，需要交费。
2.HTTP协议运行在TCP之上，所有传输的内容都是明文，HTTPS运行在SSL/TLS之上，SSL/TLS运行在TCP之上，所有传输的内容都经过加密的。
3.HTTP和HTTPS使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
4.HTTPS可以有效的防止运营商劫持，解决了防劫持的一个大问题。

image

• HTTP/1.1和HTTP/1.0的区别

1.缓存处理。
  在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，
  HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
2.带宽优化及网络连接的使用。
  HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，
  HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
3.错误通知的管理。
  在HTTP1.1中新增了24个错误状态响应码，如：
  409（Conflict）表示请求的资源与资源的当前状态发生冲突；
  410（Gone）表示服务器上的某个资源被永久性的删除。
4.Host头处理。
  在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。
  但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。
  HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。
5.长连接。
  HTTP1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，
  在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。
  在HTTP1.1中默认开启Connection： keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。  

• HTTP缓存处理

1、缓存规则

image

HTTP缓存有很多种规则，根据是否需要重新向服务器发起请求来分类，可以将其分为两大类："强制缓存"，"对比缓存"。
通常使用两种缓存结合的方式进行缓存资源。优先级："强制缓存 > 对比缓存"

2、强制缓存缓存规则

image

3、对比缓存缓存规则

image

4、强制缓存原理

1. 在没有缓存数据的时候，浏览器向服务器请求数据时，服务器会将==数据==和==缓存规则Expires/Cache-Control==一并返回，缓存规则信息包含在响应header中。
2. HTTP1.0:Expires的值为服务端返回的到期时间，即下一次请求时，请求时间小于服务端返回的到期时间，直接使用缓存数据。
3. HTTP1.1:Cache-Control

常见的取值：
private:      只对特定用户提供此缓存数据。
public:       客户端和代理服务器都可缓存，且所有用户都可以使用此缓存数据
max-age=xxx:  缓存的内容将在 xxx 秒后失效("强制缓存规则使用")
no-cache:     强制向源服务器再次验证,即需要使用"对比缓存"来验证缓存数据
no-store:     所有内容都不会缓存，强制缓存，对比缓存都不会触发。完全从服务器获取最新数据

5、对比缓存原理

1. 对比缓存，顾名思义，==需要进行比较判断是否可以使用缓存==。
2. 浏览器第一次请求数据时，服务器会将==缓存标识与数据==一起返回给客户端，客户端将二者备份至缓存数据库中。
3. 再次请求数据时，客户端将备份的==缓存标识==发送给服务器，服务器根据缓存标识进行判断，判断成功后，返回304状态码，通知客户端==比较成功==，可以使用缓存数据。
4. 缓存标识

4-1. 记录缓存：Last-Modified  请求数据：If-Modified-Since
Last-Modified：服务器返回资源的最后修改时间。客户端做保存。
If-Modified-Since：客户端重新请求时，将上面"保存的最后修改时间"使用If-Modified-Since传给服务器。
                   服务器拿到后，将它与本地资源的最后修改时间"做对比"。
                   若资源的最后修改时间"大于"If-Modified-Since，说明资源有被改动过，则"响应整片资源内容"，返回状态码"200"；
                   若资源的最后修改时间"小于或等于"If-Modified-Since，说明资源无新修改，则响应HTTP "304"，告知浏览器继续"使用所保存的cache"。

4-2. 记录缓存：Etag  请求数据：If-None-Match（优先级高于Last-Modified  /  If-Modified-Since）
Etag:服务器返回当前资源在服务器中的唯一标识（UUID）。客户端做保存。
If-None-Match：客户端重新请求时，将上面"保存的唯一标识"使用If-None-Match传给服务器。
               服务器拿到后，将它与本地资源的唯一标识"做对比"。
               "不同"，说明资源有被改动过，则"响应整片资源内容"，返回状态码"200"；
               "相同"，说明资源无新修改，则响应HTTP "304"，告知浏览器继续"使用所保存的cache"。

6.缓存机制总结

对于强制缓存，服务器通知浏览器一个缓存时间，在缓存时间内，下次请求，直接用缓存，不在时间内，执行比较缓存策略。
对于比较缓存，将缓存信息中的Etag和Last-Modified通过请求发送给服务器，由服务器校验，返回304状态码时，浏览器直接使用缓存。

image

• HTTP1.1尚存在的缺陷

1.请求延迟。（长连接复用（keep-alive）的缺点是：HOL blocking/Head-of-line blocking 排头阻塞（HTTP报文串行传输）（请求-响应-请求））
2.安全性问题。（在不使用HTTPS的前提下）

• SPDY：HTTP1.x的优化

1.SPDY

SPDY（读作“SPeeDY”）是Google开发的基于TCP的应用层协议，用以最小化网络延迟，提升网络速度，优化用户的网络使用体验。
SPDY并不是一种用于替代HTTP的协议，而是对HTTP协议的增强。

2.SPDY增强功能

1.多路复用功能降低延迟。
  针对HTTP高延迟的问题，SPDY优雅的采取了多路复用（multiplexing）。
  多路复用通过多个请求stream共享一个tcp连接的方式，解决了HOL blocking的问题，降低了延迟同时提高了带宽的利用率。
2.请求优先级（request prioritization）。
  多路复用带来一个新的问题是，在连接共享的基础之上有可能会导致关键请求被阻塞。
  SPDY允许给每个request设置优先级，这样重要的请求就会优先得到响应。
  比如浏览器加载首页，首页的html内容应该优先展示，之后才是各种静态资源文件，脚本文件等加载，这样可以保证用户能第一时间看到网页内容。
3.header压缩。
  前面提到HTTP1.x的header很多时候都是重复多余的。选择合适的压缩算法可以减小包的大小和数量。
4.强制使用SSL协议。
  基于HTTPS的加密协议传输，大大提高了传输数据的可靠性。
5.服务端推送（server push）。
  采用了SPDY的网页，例如我的网页有一个sytle.css的请求，在客户端收到sytle.css数据的同时，服务端会将sytle.js的文件推送给客户端，
  当客户端再次尝试获取sytle.js时就可以直接从缓存中获取到，不用再发请求了。

[图片上传失败...(image-5c917b-1551839300985)]

• HTTP/2

1. HTTP/2（超文本传输协议第2版，最初命名为HTTP 2.0），是HTTP协议的的第二个主要版本，使用于万维网。HTTP/2是HTTP协议自1999年HTTP 1.1发布后的首个更新，主要基于SPDY协议。

Akamai 公司建立的一个官方的演示，同时请求 379 张图片。

image

• HTTP/2和SPDY的区别

  1. HTTP2.0 支持明文 HTTP 传输，而 SPDY 强制使用 HTTPS。
  2. HTTP2.0 消息头的压缩算法采用 HPACK ，而非 SPDY 采用的 DEFLATE。
  3. HTTP2.0 报文解析采用二进制协议。

• HTTP/2新增功能说明：

  Ⅰ. 二进制协议解析

    1.HTTP2在它和传输层(TCP or UDP)之间增加了一个二进制分帧层。
    2.在二进制分帧层中， HTTP/2 会将所有传输的信息分割为更小的消息和帧（frame）,并对它们采用二进制格式的编码。
    3.对应的首部信息会被封装到 HEADER frame里，而相应的 Request Body 则封装到 DATA frame 里面。

image

Ⅱ. HTTP2.0的多路复用和HTTP1.1中的长连接复用区别

1.HTTP/1.1 Pipeling解决方式为，若干个请求排队串行化单线程处理，后面的请求等待前面请求的返回才能获得执行机会，
  一旦有某请求超时等，后续请求只能被阻塞，毫无办法，也就是人们常说的线头阻塞(head-of-line blocking)；
2.HTTP/2多个请求可同时在一个连接上并行执行。某个请求任务耗时严重，不会影响到其它连接的正常执行；

image

• RESTful（Representational State Transfer）

REST 指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。

• QUIC（Quick UDP Internet Connection）/HTTP/3.0

  Ⅰ. Google 一直在对协议标准上做努力，2012年提出的 SPDY 协议，被 IETF 标准化之后推出了类似于 SPDY 的 HTTP/2.0 协议标准，Google 立即宣布放弃对 SPDY 的支持，转而支持 HTTP/2。而 QUIC 则是 Google 在2013年提出的一种基于 UDP 的传输协议（HTTP/2-encrypted-over-UDP）。

  Ⅱ. QUIC 是基于 UDP 协议，它在两个端点之间创建连接，且支持==多路复用==。在设计之初 QUIC 希望能够提供等同于 SSL/TLS 层级的==安全保障==的同时，==减少==数据传输及创建==连接==时的延迟==时间==，双向控制带宽，从而达到更快速的体验。

  Ⅲ. QUIC 相比现在广泛应用的 HTTP2 + TCP + TLS 协议有如下的优势：

1.减少 TCP 三次握手及 TLS 握手时间。
2.改进的拥塞控制。
3.避免队头阻塞的多路复用。
4.连接迁移。
5.前向冗余纠错。

Ⅳ. 2015 年 QUIC 被提议作为 IETF 的标准草案，2016 年 7 月，IETF 正式提出了 HTTP-over-QUIC。2018 年 11 月 IETF HTTP 和 QUIC 工作组主席 Mark Nottingham 正式提出将 HTPP-over-QUIC 重命名为 HTTP/3.0。随后的几天讨论中，此项提议被 IETF 成员接受，并给出了官方认可。

• 相关资料

  1. 计算机网络自顶向下方法
  2. 图解HTTP
  3. 各种数据大全
  4. HTTP版本之间的区别

• 后续知识点扩展

  1. https时间验证，时间对不上会导致请求失败。
  2. zip压缩及其它关联压缩算法之间的配合逻辑。