计算机网络3 | 青训营笔记

这是我参与「第四届青训营 」笔记创作活动的第15天

11、Cookie与Session

cookie、session 都是用来保存用户状态信息的一种方法或手段

主要区别是：

1.保存位置：cookie保存在客户端，session 保存在服务端

2.安 全 性：cookie 安全性差，session 安全性高

3.生命周期：在不设置条件的情况下两者都是在浏览器关闭后消失

（可在客户端设置cookie的存活时间，也可在服务端设置session的存活时间）

Cookie是什么？

Cookie是客户端保存用户信息的一种机制，用来记录用户的一些信息。如何识别特定的客户呢？cookie就可以做到。每次HTTP请求时，客户端都会发送相应的Cookie信息到服务端。它的过期时间可以任意设置，如果你不主动清除它，在很长一段时间里面都可以保留着，即便这之间你把电脑关机了。

Session是什么？

Session是在无状态的HTTP协议下，服务端记录用户状态时用于标识具体用户的机制。它是在服务端保存的用来跟踪用户的状态的数据结构，可以保存在文件、数据库或者集群中。在浏览器关闭后这次的Session就消失了，下次打开就不再拥有这个Session。其实并不是Session消失了，而是Session ID变了，服务器端可能还是存着你上次的Session ID及其Session 信息，只是他们是无主状态，也许一段时间后会被删除。

由于http的无状态性，为了使某个域名下的所有网页能够共享某些数据，session和cookie出现了。客户端访问服务器的流程如下

• 首先，客户端会发送一个http请求到服务器端。
• 服务器端接受客户端请求后，建立一个session，并发送一个http响应到客户端，这个响应头，其中就包含Set-Cookie头部。该头部包含了sessionID，sessionID会被存储在cookie中。
• 在客户端发起的第二次请求，假如服务器给了set-Cookie，浏览器会自动在请求头中添加cookie
• 服务器接收请求，分解cookie，验证信息，核对成功后返回response给客户端

实际上Cookie与Session都是会话的一种方式。它们的典型使用场景比如“购物车”，当你点击下单按钮时，服务端并不清楚具体用户的具体操作，为了标识并跟踪该用户，了解购物车中有几样物品，服务端通过为该用户创建Cookie/Session来获取这些信息。

如果你的站点是多节点部署，使用Nginx做负载均衡，那么有可能会出现Session丢失的情况（比如，忽然就处于未登录状态）。这时可以使用IP负载均衡（IP绑定ip_hash，每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决Session的问题），或者将Session信息存储在集群中。在大型的网站中，一般会有专门的Session服务器集群，用来保存用户会话，这时可以使用缓存服务比如Memcached或者Redis之类的来存放Session。

注意

• cookie只是实现session的其中一种方案。虽然是最常用的，但并不是唯一的方法。禁用cookie后还有其他方法存储，比如放在url中
• 现在大多都是Session + Cookie，但是只用session不用cookie，或是只用cookie，不用session在理论上都可以保持会话状态。可是实际中因为多种原因，一般不会单独使用
• 用session只需要在客户端保存一个id，实际上大量数据都是保存在服务端。如果全部用cookie，数据量大的时候客户端是没有那么多空间的。
• 如果只用cookie不用session，那么账户信息全部保存在客户端，一旦被劫持，全部信息都会泄露。并且客户端数据量变大，网络传输的数据量也会变大

目前大多数的应用都是用Cookie 实现Session跟踪的。第一次创建Session时，服务端会通过在HTTP协议中反馈到客户端，需要在 Cookie 中记录一个Session ID，以便今后每次请求时都可分辨你是谁。有人问，如果客户端的浏览器禁用了 Cookie 怎么办？建议使用URL重写技术进行会话跟踪，即每次HTTP交互，URL后面都被附加上诸如 sid=xxxxx 的参数，以便服务端依此识别用户。

客户端和服务端之间的通信交流，可以这样简单理解：

比如当你在个推技术分享沙龙上觉得某位讲师讲得很好，在会后问了他几个问题，他对你这些问题进行了回答，这就是一个会话。但这个讲师太受欢迎，于是工作人员收集问题，并给每个提问者一个号码牌，讲师按照号码牌依次给出相应解答并告诉相应的人。这就是Session。一段时间后，当你再次遇见这位讲师，他发现你身上有上次回复你的答案，知晓你是那个好学的程序猿。于是你欣喜若狂，哇塞，讲师居然认出我了，这就是Cookie，你的小甜点。客户端好比听课的技术爱好者，服务端就是这位讲师。

Cookie还可以在一些方便用户的场景下使用。比如你某次登陆过一个网站，下次登录的时候不想再次输入账号了，怎么办？这个信息可以被写到Cookie里面，当访问网站时，网站页面的脚本可以读取这个信息，自动填写用户名，方便用户使用，给用户一点甜头。

总结：

1、Cookie 在客户端（浏览器），Session 在服务器端。

2、Cookie的安全性一般，他人可通过分析存放在本地的Cookie并进行Cookie欺骗。在安全性第一的前提下，选择Session更优。重要交互信息比如权限等就要放在Session中，一般的信息记录放Cookie就好了。

3、单个Cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个Cookie。

4、Session 可以放在 文件、数据库或内存中，比如在使用Node时将Session保存在redis中。由于一定时间内它是保存在服务器上的，当访问增多时，会较大地占用服务器的性能。考虑到减轻服务器性能方面，应当适时使用Cookie。

5、Session 的运行依赖Session ID，而 Session ID 是存在 Cookie 中的，也就是说，如果浏览器禁用了 Cookie，Session 也会失效（但是可以通过其它方式实现，比如在 url 中传递 Session ID）。

6、用户验证这种场合一般会用 Session。因此，维持一个会话的核心就是客户端的唯一标识，即Session ID。

Cookie和Session如何选择

12、常见的服务端认证机制

13、Http状态码

200 – 请求成功

301 – 资源(网页等)被永久转移到其它URL

404 – 请求的资源(网页等)不存在

500 – 内部服务器错误

分类分类描述

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

状态代码由服务器发出，以响应客户端对服务器的请求。

• 1xx（信息）：收到请求，继续处理

  100	服务器通知浏览器之前一切正常，请客户端继续请求
  101	针对请求头的Upgrade返回的信息。

• 2xx（成功）：请求已成功接收，理解和接受

  200	请求成功
  201	常用于POST，PUT 请求，表明请求已经成功，并新建了一个资源
  202	请求已经接收到，但没有响应，稍后也不会返回一个异步请求结果
  203	表明响应返回的元信息（meta-infomation）和最初的服务器不同，而是从本地或者第三方获取的。
  204	请求没有数据返回，但是头信息有用
  205	告诉用户代理（浏览器）重置发送该请求的文档。
  206	当客户端使用Range请求头时，返回该状态码。

• 3xx（重定向）：需要采取进一步措施才能完成请求

  300	返回多个响应，需要浏览器或者用户选择
  301	请求资源的URL被永久的改变，新的URL会在响应的Location中给出。
  302	请求资源的URL被暂时修改到Location提供的URL。
  303	服务通过返回的响应数据指导客户端通过GET方法去另一个URL获取资源。
  304	资源未变更。服务器根据请求头判断，需要资源未修改，只返回响应头；

• 4xx（客户端错误）：请求包含错误的语法或无法满足

  400	请求语法有问题，服务器无法识别。
  401	客户端未授权该请求。
  403	服务器拒绝响应。权限不足。
  404	URL无效或者URL有效但是没有资源。
  405	请求方式Method不允许。

• 5xx（服务器错误）：服务器无法满足明显有效的请求

  500	服务器内部错误，未捕获。
  502	服务器作为网关使用时，收到上游服务器返回的无效响应。
  503	无法服务。一般发生在因维护而停机或者服务过载。
  504	网关超时。服务器作为网关或者代理，不能及时从上游服务器获取响应返回给客户端。
  505	发出的请求http版本服务器不支持。如果请求通过http2发送，服务器不支持http2.0，就会返回该状态码。

14、ping用的是什么协议

使用的是ICMP协议（Internet Control Message Protocal）的缩写，是TCP/IP协议族的一个子协议，用于在IP主机、路由器之间传递控制消息

ICMP详解

ICMP协议是一个网络层协议。

用来测试网络层是不是有故障，若有故障，该协议还能报告故障

一个新搭建好的网络，往往需要先进行一个简单的测试，来验证网络是否畅通；但是IP协议并不提供可靠传输。如果丢包了，IP协议并不能通知传输层是否丢包以及丢包的原因。

所以我们就需要一种协议来完成这样的功能–ICMP协议。

ICMP协议的功能

0. 确认IP包是否成功到达目标地址
1. 通知在发送过程中IP包被丢弃的原因

我们需要注意几点：

0. ICMP是基于IP协议工作的，但是它并不是传输层的功能，因此仍然把它归结为网络层协议
1. ICMP只能搭配IPv4使用，如果是IPv6的情况下, 需要是用ICMPv6

常见的ICMP报文

响应请求

我们用的ping操作中就包括了相应请求（类型字段值为8）和应答（类型字段值为0）ICMP报文。

过程：

一台主机向一个节点发送一个类型字段值为8的ICMP报文，如果途中没有异常（如果没有被路由丢弃，目标不回应ICMP或者传输失败），则目标返回类型字段值为0的ICMP报文，说明这台主机存在。

目标不可达，源抑制和超时报文

这三种报文的格式是一样的。

（1）目标不可到达报文（类型值为3）在路由器或者主机不能传递数据时使用。

例如：我们要连接对方一个不存在的系统端口（端口号小于1024）时，将返回类型字段值3、代码字段值为3的ICMP报文。

常见的不可到达类型还有网络不可到达（代码字段值为0）、主机不可达到（代码字段值为1）、协议不可到达（代码字段值为2）等等。

（2）源抑制报文（类型字段值为4，代码字段值为0）则充当一个控制流量的角色，通知主机减少数据报流量。由于ICMP没有回复传输的报文，所以只要停止该报文，主机就会逐渐恢复传输速率。

（3）无连接方式网络的问题就是数据报会丢失，或者长时间在网络游荡而找不到目标，或者拥塞导致主机在规定的时间内无法重组数据报分段，这时就要触发ICMP超时报文的产生。

超时报文（类型字段值为11）的代码域有两种取值：代码字段值为0表示传输超时，代码字段值为1表示分段重组超时。

时间戳请求

时间戳请求报文（类型值字段13）和时间戳应答报文（类型值字段14）用于测试两台主机之间数据报来回一次的传输时间。

传输时，主机填充原始时间戳，接受方收到请求后填充接受时间戳后以类型值字段14的报文格式返回，发送方计算这个时间差。

(有些系统不响应这种报文)

15、ARP协议

1. ARP出现原因

ARP协议是“Address Resolution Protocol”（地址解析协议）的缩写。其作用是在以太网环境中，数据的传输所依懒的是MAC地址而非IP地址，而将已知IP地址转换为MAC地址的工作是由ARP协议来完成的。

在局域网中，网络中实际传输的是“帧”，帧里面是有目标主机的MAC地址的。在以太网中，一个主机和另一个主机进行直接通信，必须要知道目标主机的MAC地址。但这个目标MAC地址是如何获得的呢？它就是通过地址解析协议获得的。所谓“地址解析”就是主机在发送帧前将目标IP地址转换成目标MAC地址的过程。ARP协议的基本功能就是通过目标设备的IP地址，查询目标设备的MAC地址，以保证通信的顺利进行。

2. ARP映射方式

2.1. 静态映射

静态映射的意思是要手动创建一张ARP表，把逻辑（IP）地址和物理地址关联起来。这个ARP表储存在网络中的每一台机器上。例如，知道其机器的IP地址但不知道其物理地址的机器就可以通过查ARP表找出对应的物理地址。这样做有一定的局限性，因为物理地址可能发生变化：

（1）机器可能更换NIC（网络适配器），结果变成一个新的物理地址。

（2）在某些局域网中，每当计算机加电时，他的物理地址都要改变一次。

（3）移动电脑可以从一个物理网络转移到另一个物理网络，这样会时物理地址改变。

要避免这些问题出现，必须定期维护更新ARP表，此类比较麻烦而且会影响网络性能。

2.2. 动态映射

动态映射时，每次只要机器知道另一台机器的逻辑（IP）地址，就可以使用协议找出相对应的物理地址。已经设计出的实现了动态映射协议的有ARP和RARP两种。ARP把逻辑（IP）地址映射为物理地址。RARP把物理地址映射为逻辑（IP）地址。

3. ARP原理及流程

在任何时候，一台主机有IP数据报文发送给另一台主机，它都要知道接收方的逻辑（IP）地址。但是IP地址必须封装成帧才能通过物理网络。这就意味着发送方必须有接收方的物理（MAC）地址，因此需要完成逻辑地址到物理地址的映射。而ARP协议可以接收来自IP协议的逻辑地址，将其映射为相应的物理地址，然后把物理地址递交给数据链路层。

3.1.ARP请求

任何时候，当主机需要找出这个网络中的另一个主机的物理地址时，它就可以发送一个ARP请求报文，这个报文包好了发送方的MAC地址和IP地址以及接收方的IP地址。因为发送方不知道接收方的物理地址，所以这个查询分组会在网络层中进行广播。（见图1）

3.2.ARP响应

局域网中的每一台主机都会接受并处理这个ARP请求报文，然后进行验证，查看接收方的IP地址是不是自己的地址，只有验证成功的主机才会返回一个ARP响应报文，这个响应报文包含接收方的IP地址和物理地址。这个报文利用收到的ARP请求报文中的请求方物理地址以单播的方式直接发送给ARP请求报文的请求方。（见图2）

16、ICMP协议

为了更有效地转发IP数据报和提高交付成功的机会，在网际层使用ICMP（Internet Control Message）因特网控制报文协议。

它是ipv4协议族中的一个子协议，用于IP主机、路由器之间很惨地控制消息。控制消息在网络通不通、主机是否可达、路由是否可用等网络本身的消息。这些控制消息对染不传输用户数据，但是对于用户数据的传递起着重要的作用。

ICMP与ARP不同。ICMP靠IP协议来完成任务，所以ICMP报文中要封装IP头部。他与传输层协议（例如TCP与UDP）的目的不同，一般不用来在端系统之间传送数据，不被用户网络程序直接使用。

ICMP报文的种类有两种：ICP差错报告报文和ICMP询问报文

差错报文有4种：终点不可达、时间超过、参数问题、改变路由（重定向）

询问报文有2种：回送请求和回答、时间戳请求和回答

17、计算机网络各层都包含哪些协议

五层模型概念	对应网络协议
应用层	HTTP、HTTPS、FTP、DNS
传输层	TCP、UDP
网络层	IP、ICMP、ARP、RARP
数据链路层
物理层

18、keep-alive参数

HTTP协议的Keep-Alive意图在于短时间内连接复用，希望可以短时间内在同一个连接上进行多次请求/响应。

TCP的KeepAlive机制意图在于保活、心跳，检测连接错误。当一个TCP连接两端长时间没有数据传输时(通常默认配置是2小时)，发送keepalive探针，探测链接是否存活。

19、servlet中请求转发与请求重定向的区别

请求转发：

请求转发，即request.getRequestDispatcher().forward()，是一种服务器的行为，客户端只有一次请求，服务器端转发后会将请求对象保存，地址栏中的URL地址不会改变，得到响应后服务器端再将响应发给客户端；

请求重定向：

请求重定向，即response.sendRedirect()，是一种客户端行文，从本质上讲等同于两次请求，前一次请求对象不会保存，地址栏的URL地址会改变。

20、Socket编程

网络编程中两个主要的问题

一个是如何准确的定位网络上一台或多台主机，另一个就是找到主机后如何可靠高效的进行数据传输。

在TCP/IP协议中IP层主要负责网络主机的定位，数据传输的路由，由IP地址可以唯一地确定Internet上的一台主机。而TCP层则提供面向应用的可靠（tcp）的或非可靠（UDP）的数据传输机制，这是网络编程的主要对象，一般不需要关心IP层是如何处理数据的。

目前较为流行的网络编程模型是客户机/服务器（C/S）结构。即通信双方一方作为服务器等待客户提出请求并予以响应。客户则在需要服务时向服务器提出申请。服务器一般作为守护进程始终运行，监听网络端口，一旦有客户请求，就会启动一个服务进程来响应该客户，同时自己继续监听服务端口，使后来的客户也能及时得到服务。

基于Socket的java网络编程

1，什么是Socket

　　网络上的两个程序通过一个双向的通讯连接实现数据的交换，这个双向链路的一端称为一个Socket。Socket通常用来实现客户方和服务方的连接。Socket是TCP/IP协议的一个十分流行的编程界面，一个Socket由一个IP地址和一个端口号唯一确定。但是，Socket所支持的协议种类也不光TCP/IP一种，因此两者之间是没有必然联系的。在Java环境下，Socket编程主要是指基于TCP/IP协议的网络编程。

2，Socket通讯的过程

Server端Listen(监听)某个端口是否有连接请求，Client端向Server 端发出Connect(连接)请求，Server端向Client端发回Accept（接受）消息。一个连接就建立起来了。Server端和Client 端都可以通过Send，Write等方法与对方通信。

对于一个功能齐全的Socket，都要包含以下基本结构，其工作过程包含以下四个基本的步骤：

（1）创建Socket；

（2）打开连接到Socket的输入/出流；

（3）按照一定的协议对Socket进行读/写操作；

（4）关闭Socket.（在实际应用中，并未使用到显示的close，虽然很多文章都推荐如此，不过在我的程序中，可能因为程序本身比较简单，要求不高，所以并未造成什么影响。）

3，创建Socket

创建Socket

java在包java.net中提供了两个类Socket和ServerSocket，分别用来表示双向连接的客户端和服务端。这是两个封装得非常好的类，使用很方便。其构造方法如下：

Socket(InetAddress address, int port);
​
Socket(InetAddress address, int port, boolean stream);
​
Socket(String host, int prot);
​
Socket(String host, int prot, boolean stream);
​
Socket(SocketImpl impl)
​
Socket(String host, int port, InetAddress localAddr, int localPort)
​
Socket(InetAddress address, int port, InetAddress localAddr, int localPort)
​
ServerSocket(int port);
​
ServerSocket(int port, int backlog);
​
ServerSocket(int port, int backlog, InetAddress bindAddr)

其中address、host和port分别是双向连接中另一方的IP地址、主机名和端口号，stream指明socket是流socket还是数据报socket，localPort表示本地主机的端口号，localAddr和 bindAddr是本地机器的地址（ServerSocket的主机地址），impl是socket的父类，既可以用来创建serverSocket又可以用来创建Socket。count则表示服务端所能支持的最大连接数。

Socket client = new Socket("127.0.01.", 80);
​
ServerSocket server = new ServerSocket(80);

注意，在选择端口时，必须小心。每一个端口提供一种特定的服务，只有给出正确的端口，才能获得相应的服务。0~1023的端口号为系统所保留，例如http服务的端口号为80,telnet服务的端口号为21,ftp服务的端口号为23, 所以我们在选择端口号时，最好选择一个大于1023的数以防止发生冲突。

在创建socket时如果发生错误，将产生IOException，在程序中必须对之作出处理。所以在创建Socket或ServerSocket是必须捕获或抛出例外。

一个简单的案例

Client端

客户端的请求过程稍微有点不一样：

0. 构建Socket实例，通过指定的远程服务器地址和端口来建立连接。
1. 通过Socket实例包含的InputStream和OutputStream来进行数据的读写。
2. 操作结束后调用socket实例的close方法，关闭。

public class TalkClient {
    public static void main(String args[]) {
        try {
            Socket socket = new Socket("127.0.0.1", 4700);
            //向本机的4700端口发出客户请求
            BufferedReader sin = new BufferedReader(new InputStreamReader(System.in));
            //由系统标准输入设备构造BufferedReader对象
            PrintWriter os = new PrintWriter(socket.getOutputStream());
            //由Socket对象得到输出流，并构造PrintWriter对象
            BufferedReader is = new BufferedReader(new InputStreamReader(socket.getInputStream()));
            //由Socket对象得到输入流，并构造相应的BufferedReader对象
            String readline;
            readline = sin.readLine(); //从系统标准输入读入一字符串
            while (!readline.equals("bye")) {
                //若从标准输入读入的字符串为 "bye"则停止循环
                os.println(readline);
                //将从系统标准输入读入的字符串输出到Server
                os.flush();
                //刷新输出流，使Server马上收到该字符串
                System.out.println("Client:" + readline);
                //在系统标准输出上打印读入的字符串
                System.out.println("Server:" + is.readLine());
                //从Server读入一字符串，并打印到标准输出上
                readline = sin.readLine(); //从系统标准输入读入一字符串
            } //继续循环
            os.close(); //关闭Socket输出流
            is.close(); //关闭Socket输入流
            socket.close(); //关闭Socket
        } catch (Exception e) {
            System.out.println("Error" + e); //出错，则打印出错信息
        }
    }
}

Server端

Server端所要做的事情主要是建立一个通信的端点，然后等待客户端发送的请求。典型的处理步骤如下：

0. 构建一个ServerSocket实例，指定本地的端口。这个socket就是用来监听指定端口的连接请求的。

1. 重复如下几个步骤：

   a. 调用socket的accept()方法来获得下面客户端的连接请求。通过accept()方法返回的socket实例，建立了一个和客户端的新连接。

   b.通过这个返回的socket实例获取InputStream和OutputStream,可以通过这两个stream来分别读和写数据。

   c.结束的时候调用socket实例的close()方法关闭socket连接。

public class TalkServer {
    public static void main(String[] args) {
        try {
            ServerSocket server = null;
            try {
                //创建一个ServerSocket在端口4700监听客户请求
                server = new ServerSocket(4700);
            } catch (Exception e) {
                //出错，打印出错信息
                System.out.println("can not listen to:" + e);
            }
            Socket socket = null;
            try {
                //使用accept()阻塞等待客户请求，有客户
                //请求到来则产生一个Socket对象，并继续执行
                socket = server.accept();
            } catch (Exception e) {
                //出错，打印出错信息
                System.out.println("Error." + e);
            }
            String line;
            //由Socket对象得到输入流，并构造相应的BufferedReader对象
            BufferedReader is = new BufferedReader(new InputStreamReader(socket.getInputStream()));
            //由Socket对象得到输出流，并构造PrintWriter对象
            PrintWriter os = new PrintWriter(socket.getOutputStream());
            //由系统标准输入设备构造BufferedReader对象
            BufferedReader sin = new BufferedReader(new InputStreamReader(System.in));
            //在标准输出上打印从客户端读入的字符串
            System.out.println("Client:" + is.readLine());
            //从标准输入读入一字符串
            line = sin.readLine();
            //如果该字符串为 "bye"，则停止循环
            while (!line.equals("bye")) {
                //向客户端输出该字符串
                os.println(line);
                //刷新输出流，使Client马上收到该字符串
                os.flush();
                //在系统标准输出上打印读入的字符串
                System.out.println("Server:" + line);
                //从Client读入一字符串，并打印到标准输出上
                System.out.println("Client:" + is.readLine());
                //从系统标准输入读入一字符串
                line = sin.readLine();
            } //继续循环
            os.close(); //关闭Socket输出流
            is.close(); //关闭Socket输入流
            socket.close(); //关闭Socket
            server.close(); //关闭ServerSocket
        } catch (Exception e) {
            //出错，打印出错信息
            System.out.println("Error:" + e);
        }
    }
}

21、数字签名和数字证书

www.ruanyifeng.com/blog/2011/0…

22、跨域问题

什么是跨域

前端调用的后端接口不属于同一个域（域名或端口不同），就会产生跨域问题，也就是说你的应用访问了该应用域名或端口之外的域名或端口。

为什么会发生跨域问题

要同时满足三个条件才会产生跨域问题，这也就是为什么会产生跨域的原因。

• 1、浏览器限制，而不是服务端限制，可以查看Network，请求能够正确响应，response返回的值也是正确的
• 2、请求地址的域名或端口和当前访问的域名或端口不一样
• 3、发送的是XHR（XMLHttpRequest）请求，可以使用 a 标签（模拟xhr请求）和 img 标签（模拟json请求）做对比（控制台只报了一个跨域异常）

例子：

同源策略

同源策略是浏览器的一个安全功能，不同源的客户端脚本在没有明确授权的情况下，不能读写对方资源。所以xyz.com下的js脚本采用ajax读取abc.com里面的文件数据是会被拒绝的。

同源策略限制了从同一个源加载的文档或脚本如何与来自另一个源的资源进行交互。这是一个用于隔离潜在恶意文件的重要安全机制。

跨域的方法

segmentfault.com/a/119000001…

1、JSONP

只要说到跨域，就必须聊到 JSONP，JSONP全称为：JSON with Padding，可用于解决主流浏览器的跨域数据访问的问题。

原理：Web 页面上调用 js 文件不受浏览器同源策略的影响，比如script或者img等，所以通过 Script 便签可以进行跨域的请求：

0. 首先前端先设置好回调函数，并将其作为 url 的参数。
1. 服务端接收到请求后，通过该参数获得回调函数名，并将数据放在参数中将其返回
2. 收到结果后因为是 script 标签，所以浏览器会当做是脚本进行运行，从而达到跨域获取数据的目的。

优点：

0. 它不像XMLHttpRequest 对象实现 Ajax 请求那样受到同源策略的限制
1. 兼容性很好，在古老的浏览器也能很好的运行
2. 不需要 XMLHttpRequest 或 ActiveX 的支持；并且在请求完毕后可以通过调用 callback 的方式回传结果。

缺点：

0. 它支持 GET 请求而不支持 POST 等其它类行的 HTTP 请求（因为script加载资源就是get）。
1. 它只支持跨域 HTTP 请求这种情况，不能解决不同域的两个页面或 iframe 之间进行数据通信的问题

2、CORS

CORS 是一个 W3C 标准，全称是"跨域资源共享"（Cross-origin resource sharing）它允许浏览器向跨源服务器，发出 XMLHttpRequest 请求，从而克服了 ajax 只能同源使用的限制。

CORS 需要浏览器和服务器同时支持才可以生效，对于开发者来说，CORS 通信与同源的 ajax 通信没有差别，代码完全一样。浏览器一旦发现 ajax 请求跨源，就会自动添加一些附加的头信息，有时还会多出一次附加的请求，但用户不会有感觉。

因此，实现 CORS 通信的关键是服务器。只要服务器实现了 CORS 接口，就可以跨源通信。

CORS 的优缺点：

0. 使用简单方便，更为安全
1. 支持 POST 请求方式
2. CORS 是一种新型的跨域问题的解决方案，存在兼容问题，仅支持 IE 10 以上

3、Server Proxy

服务器代理，顾名思义，当你需要有跨域的请求操作时发送请求给后端，让后端帮你代为请求，然后最后将获取的结果发送给你。

假设有这样的一个场景，你的页面需要获取 CNode：Node.js专业中文社区 论坛上一些数据，如通过 cnodejs.org/api/v1/topi…，当时因为不同域，所以你可以将请求后端，让其对该请求代为转发。

23、子网掩码的作用

作用

在设置电脑IP时，会碰到两个重要的参数，一个是IP地址，一个是子网掩码。IP地址是互联网上每个子网或每个主机在网络上的唯一身份标签，那子网掩码是干什么用的呢？

随着互联网的发展，越来越多的网络产生，有的网络多则几百台主机，少则区区几台，这样就浪费了大量的IP地址，所以要划分子网。为了有序地区分和管理不同的子网，就需要使用子网掩码。

子网掩码是一种用来指明一个IP地址所标示的主机处于哪个子网中。子网掩码不能单独存在，它必须结合IP地址一起使用。子网掩码只有一个作用，就是将某个IP地址划分成网络地址和主机地址两部分。

子网掩码的用法

子网掩码是一个32位地址，对于A类地址来说，默认的子网掩码是255.0.0.0；对于B类地址来说默认的子网掩码是255.255.0.0；对于C类地址来说默认的子网掩码是255.255.255.0。

子网掩码通常有十进制和二级制两种表现形式，255.255.0.0用二进制表示则为1111111.11111111.00000000.00000000，其中，前面2个字节的16位“1”表示网络号，后面2个字节的16位“0”表示主机号。

当配合IP地址172.20.0.4使用时，则表示该IP地址是B类地址，172.20是网络标识，0.4是主机标识。也即子网掩码AND IP地址的部分是网络标识，子网掩码取反后AND IP地址的部分即为主机标识。

子网掩码有两个特殊地址，当子网掩码的主机地址全为0时，表示该网络地址，当子网掩码的主机地址全为1时，表示该网络的广播地址。

举例

例1、不同子网下的主机能否直接通信

假设两个IP地址分别是172.20.0.18和172.20.1.16，子网掩码都是255.255.255.0。

我们可以知道两者的网络标识分别是172.20.0和172.20.1，无法直接通信，也就无法PING通。要想能相互通信，需要将子网掩码改成255.255.0.0。

例2、如何确定子网掩码

1）将主机数目转化为二进制来表示，总位数是N；

2）将掩码地址全部置1，然后从后向前的将N位全部置为 0，即为子网掩码值。

如欲将B类IP地址168.195.0.0划分成若干子网，每个子网内有主机700台：

1)700=1010111100，该二进制为十位数，N = 10

2)将子网掩码255.255.255.255从后向前的10位全部置0,即为： 11111111.11111111.11111100.00000000，也即255.255.252.0。

255.255.252.0就是168.195.0.0的700台主机的子网掩码了。

例3、如何理解172.20.1.0/26

上文中的26代表主机ID的掩码地址长度，从前往后有26位，即子网掩码的地址是255.255.255.192。

24、Socket

TCP/IP UDP是什么？

TCP/IP（Transmission Control Protocol/Internet Protocol）即传输控制协议/网间协议，是一个工业标准的协议集，它是为广域网（WANs）设计的。UDP（User Data Protocol，用户数据报协议）是与TCP相对应的协议。它是属于TCP/IP协议族中的一种。下面是他们三者的关系：

可以看出TCP/IP协议族包括运输层、网络层、链路层。socket是一个接口，在用户进程与TCP/IP协议之间充当中间人，完成TCP/IP协议的书写，用户只需理解接口即可。

socket与TCP/IP的对应关系

Socket是应用层与TCP/IP协议族通信的中间软件抽象层，它是一组接口。在设计模式中，Socket其实就是一个门面模式，它把复杂的TCP/IP协议族隐藏在Socket接口后面，对用户来说，一组简单的接口就是全部，让Socket去组织数据，以符合指定的协议。

原作者将socket通信类比为打电话这一生活场景。这里我把TCP服务器比作政府某一服务部门能，TCP客户端比作企业中某一部门电话，描述这一过程，恰好就像是socket通信，服务部门提供服务，企业部门申请服务。

要实现通信，首先政府部门都必须申请一个电话（socket_fd），并向有关部门注册（我们的系统），提供地址（sockadrr）以及属于哪个部门的（port），录入系统后，就算是合约生效了（bind），于是乎，政府广而告之，这个服务热线就算开通了，在部门里面的人员所需要做的事情，就是等待企业家拨打热线（listen）。

企业家拨打电话对地点和部门没有这么多的要求了，他并不需要绑定地址和部门，在任何一个可以拨打电话的地方(可能是同个部门，也可以同公司不同部门，甚至可能是竞争对手)，他只需要拿起一个已经注册的电话（socket_fd），拨打电话（connect） 政府部门接通电话（accept）后，桥梁就打通了（服务者client_fd、顾客server_fd），可以进行听说了（read write）。企业家咨询完成（close）,政府到点下班关闭服务（close）

25、正向代理和反向代理

blog.csdn.net/liuhenghui5…

正向代理

所谓正向代理就是顺着请求的方向进行的代理，即代理服务器他是由你配置为你服务，去请求目标服务器地址。

比如我们要去访问谷歌网站，我们直接访问不通，那么我们就可以找一个代理服务器为我们服务，我们通过代理服务器请求到谷歌网站。对于谷歌而言他只知道有一个服务器访问了自己，并不知道这件事你是访问不了他,找了一个代理服务器访问自己。

在举一个通俗的例子。你需要钱，C正好有钱，但是你C不直接借给你。你和B关系比较好，B可以找C借到钱。你和B沟通后，由B来找C借到钱后在给你。

上面的两个例子中的共同特点是 代理服务器和B都是你找到的，为你而服务的，代表你的利益。我们还可以让代理服务器给你代理到推特、Facebook等，他是代理的你。

反向代理

所谓反向代理正好与正向代理相反，代理服务器是为目标服务器服务的，虽然整体的请求返回路线都是一样的都是Client到Proxy到Server。

比如 我们访问百度网站，百度的代理服务器对外的域名为 www.baidu.com 。具体内部的服务器节点我们不知道。现实中我们通过访问百度的代理服务器后，代理服务器给我们转发请求到他们N多的服务器节点中的一个给我们进行搜索后将结果返回。

再举例：我们同样需要钱，但是我们又不知道谁有钱，所以我们找了一家网贷平台，你提交资料后，网贷平台直接将钱打给你。但是你不知道，也不用关注网贷平台的钱从哪里来。网贷平台内部他们可能从哪一个财主哪里融的钱。对你而言网贷平台和他们的金主是一起的。

同样通过上面我们例子可以看到，此时的代理服务器和后面的目标主机是一个系统的（百度公司、网贷平台）。他们是对外提供服务的，所以称为反向代理，代理的是后的人。

26、URL的组成

举例如下：

http://www.example.com:80/path/to/myfile.html?key1=value1&key2=value2#SomewhereInTheDocument

协议(Protocol)

http://为协议名,标明了请求需要使用的协议,通常使用的是HTTP协议或者安全协议 HTTPS.其他协议还有mailto:用户打开邮箱的客户端,和ftp:用来做文件的转换, file用来获取文件,data获取外部资源等

域名(Domain)

www.example.com为域名,标明了需要请求的服务器的地址.

端口(Port)

:80是端口号,标明了获取服务器资源的入口 端口号用于区分服务的端口,一台拥有IP地址的服务器可以提供许多服务，比如Web服务、FTP服务、SMTP服务等.那么，服务器的资源通过“IP地址+端口号”来区分不同的服务. 如果把服务器比作房子,端口号可以看做是通向不同服务的门,

文件路径

/path/to/myfile.html表示服务器上资源的路径,过去这样的路径标记的是服务器上文件的物理路径,但是现在,路径表示的只是一个抽象地址,并不指代任何物理地址.

参数(query)

?key1=value1&key2=value2是请求里提供的额外参数.这些参数是以键值对的形式,通过&符号分隔开来,服务器可以通过这些参数进行相应的个性化处理

片段(fragment)/锚

#SomewhereInTheDocument是对资源的部分补充.fragment可以理解为资源内部的书签.用来想服务器指明展示的内容所在的书签的点.例如对于HTML文件来说,浏览器会滚动到特定的或者上次浏览过的位置.对于音频或者视频资源来说,浏览器又会跳转到对应的时间节点.

补充 : 相对路径和绝对路径

我们上面所说的都是绝对路径,但是URL也有相对路径的表现形式. URL所请求的资源依赖于请求所在的上下文,也就是当前环境,在浏览器的输入框内URL没有上下文,所以必须提供绝对路径. 但是当URL用于文件中时,例如HTML的页面,情况就大有不同了,因为浏览器已经拥有了文件的URL,所以可以自动填补文件内使用的URL丢失的部分,例如协议,域名,端口等,所以我们可以较为直观的区分相对路径和绝对路径. 如果URL以/开头,浏览器会从根服务器去获取资源,而不是从给定的文件夹中获取. 我们用一些例子来直观的理解下 完整的URL:

https://developer.mozilla.org/en-US/docs/Learn

隐藏协议 //developer.mozilla.org/en-US/docs/Learn 浏览器会使用文件主机的相同协议

隐藏域名

/en-US/docs/Learn

浏览器会使用文件主机的相同协议和同样的域名,注意,不能在未隐藏协议的前提下只隐藏域名

27、NAT

NAT的产生背景

2011年2月3日中国农历新年， IANA对外宣布：IPv4地址空间最后5个地址块已经被分配给下属的5个地区委员会。2011年4月15日，亚太区委员会APNIC对外宣布，除了个别保留地址外，本区域所有的IPv4地址基本耗尽。一时之间，IPv4地址作为一种濒危资源身价陡增，各大网络公司出巨资收购剩余的空闲地址。其实，IPv4地址不足问题已不是新问题，早在20年以前，IPv4地址即将耗尽的问题就已经摆在Internet先驱们面前。这不禁让我们想去了解，是什么技术使这一危机延缓了尽20年。

要找到问题的答案，让我们先来简略回顾一下IPv4协议。

IPv4即网际网协议第4版——Internet Protocol Version 4的缩写。IPv4定义一个跨越异种网络互连的超级网，它为每个网际网的节点分配全球唯一IP地址。如果我们把Internet比作一个邮政系统，那么IP地址的作用就等同于包含城市、街区、门牌编号在内的完整地址。IPv4使用32bits整数表达一个地址，地址最大范围就是232 约为43亿。以IP创始时期可被联网的设备来看，这样的一个空间已经很大，很难被短时间用完。然而，事实远远超出人们的设想，计算机网络在此后的几十年里迅速壮大，网络终端数量呈爆炸性增长。

更为糟糕的是，为了路由和管理方便，43亿的地址空间被按照不同前缀长度划分为A,B,C,D类地址网络和保留地址。其中，A类网络地址127段，每段包括主机地址约1678万个。B类网络地址16384段，每段包括65536个主机地址。 ANA向超大型企业/组织分配A类网络地址，一次一段。向中型企业或教育机构分配B类网络地址，一次一段。这样一种分配策略使得IP地址浪费很严重，很多被分配出去的地址没有真实被利用，地址消耗很快。以至于二十世纪90年代初，网络专家们意识到，这样大手大脚下去，IPv4地址很快就要耗光了。于是，人们开始考虑IPv4的替代方案，同时采取一系列的措施来减缓IPv4地址的消耗。正是在这样一个背景之下，本期的主角闪亮登场，它就是网络地址转换——NAT。

NAT是一项神奇的技术，说它神奇在于它的出现几乎使IPv4起死回生。在IPv4已经被认为行将结束历史使命之后近20年时间里，人们几乎忘了IPv4的地址空间即将耗尽这样一个事实——在新技术日新月异的时代，20年可算一段漫长的历史。更不用说，在NAT产生以后，网络终端的数量呈加速上升趋势，对IP地址的需求剧烈增加。此足见NAT技术之成功，影响之深远。

IP地址基础知识

同学你现在做两个操作

• 打开你的命令行输入ipconfig查询你的Ip地址
• 打开百度，输入Ip查询，查询你的ip地址

你是不是发现了一件很神奇的事情，这两个地址是不一样的。但是我们又经常说每个主机只有一个ip,这个ip是他的身份标识。这完全矛盾啊。这就引出了我们今天要讲的NAT技术 其实并不矛盾。这里我们要引入公网ip和私网ip这两个概念，关于这个问题的解读。大家可以参看我的博文。为什么百度查到的ip和ipconfig查到的不一样

NAT技术的工作原理和特点

NAT名字很准确，网络地址转换，就是替换IP报文头部的地址信息。NAT通常部署在一个组织的网络出口位置，通过将内部网络IP地址替换为出口的IP地址提供公网可达性和上层协议的连接能力。那么，什么是内部网络IP地址？

RFC1918规定了三个保留地址段落：10.0.0.0-10.255.255.255；172.16.0.0-172.31.255.255；192.168.0.0-192.168.255.255。这三个范围分别处于A,B,C类的地址段，不向特定的用户分配，被IANA作为私有地址保留。这些地址可以在任何组织或企业内部使用，和其他Internet地址的区别就是，仅能在内部使用，不能作为全球路由地址。这就是说，出了组织的管理范围这些地址就不再有意义，无论是作为源地址，还是目的地址。对于一个封闭的组织，如果其网络不连接到Internet，就可以使用这些地址而不用向IANA提出申请，而在内部的路由管理和报文传递方式与其他网络没有差异。

对于有Internet访问需求而内部又使用私有地址的网络，就要在组织的出口位置部署NAT网关，在报文离开私网进入Internet时，将源IP替换为公网地址，通常是出口设备的接口地址。一个对外的访问请求在到达目标以后，表现为由本组织出口设备发起，因此被请求的服务端可将响应由Internet发回出口网关。出口网关再将目的地址替换为私网的源主机地址，发回内部。这样一次由私网主机向公网服务端的请求和响应就在通信两端均无感知的情况下完成了。依据这种模型，数量庞大的内网主机就不再需要公有IP地址了。

NAT的转换示意图如下所示 我们一般使用私网ip作为局域网内部的主机标识，使用公网ip作为互联网上通信的标识

在整个NAT的转换中，最关键的流程有以下几点

• 网络被分为私网和公网两个部分，NAT网关设置在私网到公网的路由出口位置，双向流量必须都要经过NAT网关
• 网络访问只能先由私网侧发起，公网无法主动访问私网主机；
• NAT网关在两个访问方向上完成两次地址的转换或翻译，出方向做源信息替换，入方向做目的信息替换；
• NAT网关的存在对通信双方是保持透明的；
• NAT网关为了实现双向翻译的功能，需要维护一张关联表，把会话的信息保存下来。

静态NAT

如果一个内部主机唯一占用一个公网IP，这种方式被称为一对一模型。此种方式下，转换上层协议就是不必要的，因为一个公网IP就能唯一对应一个内部主机。显然，这种方式对节约公网IP没有太大意义，主要是为了实现一些特殊的组网需求。比如用户希望隐藏内部主机的真实IP，或者实现两个IP地址重叠网络的通信。

动态NAT

它能够将未注册的IP地址映射到注册IP地址池中的一个地址。不像使用静态NAT那样，你无需静态地配置路由器，使其将每个内部地址映射到一个外部地址，但必须有足够的公有因特网IP地址，让连接到因特网的主机都能够同时发送和接收分组

NAT重载（经常应用到实际中）

这是最常用的NAT类型。NAT重载也是动态NAT，它利用源端口将多个私网ip地址映射到一个公网ip地址(多对一)。那么，它的独特之处何在呢?它也被称为端口地址特换(PAT)。通过使用PAT(NAT重载)，只需使用一个公网ip地址，就可将数千名用户连接到因特网。其核心之处就在于利用端口号实现公网和私网的转换。

面对私网内部数量庞大的主机，如果NAT只进行IP地址的简单替换，就会产生一个问题：当有多个内部主机去访问同一个服务器时，从返回的信息不足以区分响应应该转发到哪个内部主机。此时，需要NAT设备根据传输层信息或其他上层协议去区分不同的会话，并且可能要对上层协议的标识进行转换，比如TCP或UDP端口号。这样NAT网关就可以将不同的内部连接访问映射到同一公网IP的不同传输层端口，通过这种方式实现公网IP的复用和解复用。这种方式也被称为端口转换PAT、NAPT或IP伪装，但更多时候直接被称为NAT，因为它是最典型的一种应用模式。

举个例子，客户端172.18.250.6和百度服务器202.108.22.5通信，172.18.250.6发送数据时，先转换为219.155.6.240:1723（任意>1024的随机端口），然后再利用这个身份发送数据给百度服务器，然后百度服务器回应数据并发送给219.155.6.240:1723，NAT网关检查自己的关联表，意识到这是自己地私网中172.18.250.6的数据包，然后把这个数据发送给客户端

也就是说，我们利用端口号的唯一性实现了公网ip转换为私网ip的这一步。PAT（NAT重载）能够使用传输层端口号来标识主机，因此，从理论上说，最多可让大约65000台主机共用一个公有IP地址

NAT技术的优缺点

优点

• 节省合法的公有ip地址

• 地址重叠时，提供 解决办法

• 网络发生变化时，避免重新编址（这个问题具有亲身体会，原本所在的实习单位搬迁，我们搬到了新的住处，网络环境发生了一些变化，但是由于nat技术的特点，我们局域网的地址并没有发生改变，我们依然使用着最初的编址方案）

  NAT对我们来说最大的贡献就是帮助我们节省了大量的ip资源

缺点

在介绍NAT的诸多缺点之前，我们先简单介绍下什么是IP的端到端通信：

IP协议的一个重要贡献是把世界变得平等。在理论上，具有IP地址的每个站点在协议层面有相当的获取服务和提供服务的能力，不同的IP地址之间没有差异。人们熟知的服务器和客户机实际是在应用协议层上的角色区分，而在网络层和传输层没有差异。一个具有IP地址的主机既可以是客户机，也可以是服务器，大部分情况下，既是客户机，也是服务器。端到端对等看起来是很平常的事情，而意义并不寻常。但在以往的技术中，很多协议体系下的网络限定了终端的能力。正是IP的这个开放性，使得TCP/IP协议族可以提供丰富的功能，为应用实现提供了广阔平台。因为所有的IP主机都可以服务器的形式出现，所以通讯设计可以更加灵活。使用UNIX/LINUX的系统充分利用了这个特性，使得任何一个主机都可以建立自己的HTTP、SMTP、POP3、DNS、DHCP等服务。与此同时，很多应用也是把客户端和服务器的角色组合起来完成功能。例如在VoIP应用中，用户端向注册服务器登录自己的IP地址和端口信息过程中，主机是客户端；而在呼叫到达时，呼叫处理服务器向用户端发送呼叫请求时，用户端实际工作在服务器模式下。在语音媒体流信道建立过程后，通讯双向发送语音数据，发送端是客户模式，接收端是服务器模式。而在P2P的应用中，一个用户的主机既为下载的客户，同时也向其他客户提供数据，是一种C/S混合的模型。上层应用之所以能这样设计，是因为IP协议栈定义了这样的能力。试想一下，如果IP提供的能力不对等，那么每个通信会话都只能是单方向发起的，这会极大限制通信的能力。细心的读者会发现，前面介绍NAT的一个特性正是这样一种限制。没错，NAT最大的弊端正在于此——破坏了IP端到端通信的能力。

NAT的弊端

首先，NAT使IP会话的保持时效变短。因为一个会话建立后会在NAT设备上建立一个关联表，在会话静默的这段时间，NAT网关会进行老化操作。这是任何一个NAT网关必须做的事情，因为IP和端口资源有限，通信的需求无限，所以必须在会话结束后回收资源。通常TCP会话通过协商的方式主动关闭连接，NAT网关可以跟踪这些报文，但总是存在例外的情况，要依赖自己的定时器去回收资源。而基于UDP的通信协议很难确定何时通信结束，所以NAT网关主要依赖超时机制回收外部端口。通过定时器老化回收会带来一个问题，如果应用需要维持连接的时间大于NAT网关的设置，通信就会意外中断。因为网关回收相关转换表资源以后，新的数据到达时就找不到相关的转换信息，必须建立新的连接。当这个新数据是由公网侧向私网侧发送时，就会发生无法触发新连接建立，也不能通知到私网侧的主机去重建连接的情况。这时候通信就会中断，不能自动恢复。即使新数据是从私网侧发向公网侧，因为重建的会话表往往使用不同于之前的公网IP和端口地址，公网侧主机也无法对应到之前的通信上，导致用户可感知的连接中断。NAT网关要把回收空闲连接的时间设置到不发生持续的资源流失，又维持大部分连接不被意外中断，是一件比较有难度的事情。在NAT已经普及化的时代，很多应用协议的设计者已经考虑到了这种情况，所以一般会设置一个连接保活的机制，即在一段时间没有数据需要发送时，主动发送一个NAT能感知到而又没有实际数据的保活消息，这么做的主要目的就是重置NAT的会话定时器。

其次，NAT在实现上将多个内部主机发出的连接复用到一个IP上，这就使依赖IP进行主机跟踪的机制都失效了。如网络管理中需要的基于网络流量分析的应用无法跟踪到终端用户与流量的具体行为的关系。基于用户行为的日志分析也变得困难，因为一个IP被很多用户共享，如果存在恶意的用户行为，很难定位到发起连接的那个主机。即便有一些机制提供了在NAT网关上进行连接跟踪的方法，但是把这种变换关系接续起来也困难重重。基于IP的用户授权不再可靠，因为拥有一个IP的不等于一个用户或主机。一个服务器也不能简单把同一IP的访问视作同一主机发起的，不能进行关联。有些服务器设置有连接限制，同一时刻只接纳来自一个IP的有限访问(有时是仅一个访问)，这会造成不同用户之间的服务抢占和排队。有时服务器端这样做是出于DOS攻击防护的考虑，因为一个用户正常情况下不应该建立大量的连接请求，过度使用服务资源被理解为攻击行为。但是这在NAT存在时不能简单按照连接数判断。 总之，缺点大概如下：

• 无法进行端到端的ip跟踪（破坏了端对端通信的平等性）
• 很多应用层协议无法识别（比如ftp协议 ）

28、HTTP 2.0 头部压缩算法

segmentfault.com/a/119000001…

问题背景

HTTP1.x的header中的字段很多时候都是重复的，例如method:get、status:200等等，随着网页增长到需要数十到数百个请求，这些请求中的冗余标头字段不必要地消耗带宽，从而显著增加了延迟，因此，Hpack技术应时而生。

Hpack思想简介

首先介绍下压缩的概念（比较简单，熟悉的可以跳过）：

0. 通信的双方各拥有一本字典，记录着某些字符对应的文本内容，例如x代表危险，y代表撤退，z代表进攻等；
1. 消息发送方根据字典生成消息文本比如'x，y'
2. 接收方接收到消息后，根据字典还原内容：“危险，撤退”

这个例子已经简单介绍了压缩的好处：可以在传输的过程，简化消息内容，从而降低消息的大小

官方文档里的对Hpack的主要思想说明：

0. 将header里的字段列表视为可包括重复对的name-value键值对的有序集合，分别使用8位字节表示name和value
1. 当字段被编码/解码时，对应的字典会不断扩充
2. 在编码形式中，header字段可以直接表示，也可以使用header field tables 中对应的引用。因此，可以使用引用和文字值的混合来header字段列表。
3. 文字值要么直接编码，要么使用静态huffman代码
4. 编码器负责决定在标题字段表中插入哪些标题字段作为新条目。解码器执行对编码器规定的报头字段表的修改，重建处理中的报头字段列表

过程简述

简单描述一下Hpack算法的过程：

• 消息发送端和消息接受端共同维护一份静态表和一份动态表（这两个合起来充当字典的角色），
• 每次请求时，发送方根据字典的内容以及一些特定指定，编码压缩消息头部，
• 接收方根据字典进行解码，并且根据指令来判断是否需要更新动态表