HTTP整理

1. HTTP简介

Web 使用一种名为 HTTP（超文本传输协议）的协议作为规范，完成从客户端到服务器端等一系列运作流程。Web是建立在HTTP上通信的。

所以说，HTTP协议用于客户端和服务器端之间的通信。请求访问文本或图像等资源的一端成为客户端，而提供资源响应的一端称为服务器端。HTTP 通信过程包括从客户端发往服务器端的请求及从服务器端返回客户端的响应。

 1.1 使用 HTTP 协议访问 Web

根据Web浏览器地址栏中指定的URL，Web浏览器从Web服务器端获取文件资源（resource）等信息，从而显示出Web页面。

像这种通过发送请求获取服务器资源的Web浏览器等，都可称为客户端（client）。

Web使用一种名为HTTP（HyperText Transfer Protocol，超文本传输协议）的协议作为规范，完成从客户端到服务器端等一系列运作流程。而协议是指规则的约定。可以说，Web是建立在HTTP协议上通信的。

1.2 网络基础 TCP / IP

通常使用的网络（包括互联网）是在TCP/IP协议族的基础上运作的。而HTTP属于它内部的一个子集。

1.2.1 TCP/IP协议族 

计算机与网络设备要相互通信，双方就必须基于相同的方法。比如，如何探测到通信目标、由哪一边先发起通信、使用哪种语言进行通信、怎样结束通信等规则都需要事先确定。不同的硬件、操作系统之间的通信，所有的这一切都需要一种规则。而我们就把这种规则称为协议（protocol）。

 1.2.2 TCP/IP的分层管理

TCP/IP 协议族按层次分别分为以下 4 层：应用层、传输层、网络层和数据链路层。

1）应用层：应用层决定了向用户提供应用服务时通信的活动。 TCP/IP协议族内预存了各类通用的应用服务。比如，FTP（File Transfer Protocol，文件传输协议）和 DNS（Domain Name System，域名系统）服务就是其中两类。 HTTP协议也处于该层。

2）传输层：提供处于网络连接中的两台计算机之间的数据传输。 在传输层有两个性质不同的协议：TCP（Transmission Control Protocol，传输控制协议）和UDP（User Data Protocol，用户数据报协议）。

3）网络层：网络层用来处理在网络上流动的数据包。数据包是网络传输的最小数据单位。该层规定了通过怎样的路径（所谓的传输路线）到达对方计算机，并把数据包传送给对方。 与对方计算机之间通过多台计算机或网络设备进行传输时，网络层所起的作用就是在众多的选项内选择一条传输路线。 

4）链路层：用来处理连接网络的硬件部分。包括控制操作系统、硬件的设备驱动、NIC（Network Interface Card，网络适配器，即网卡），及光纤等物理可见部分（还包括连接器等一切传输媒介）。硬件上的范畴均在链路层的作用范围之内。 

1.2.3 TCP/IP 通信传输流

---

2. HTTP是不保存状态的协议

HTTP 是一种无状态协议。HTTP 协议自身不对请求和响应之间的通信状态进行保存。使用 HTTP 协议，每当有新的请求发送时，就会有对应的新响应产生。协议本身并不保留之前一切的请求或响应报文的信息。

HTTP/1.1 虽然是无状态协议，但为了实现保持状态功能，引入了 Cookie 技术。

Cookie 技术通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。Cookie 会根据从服务器端发送的响应报文内的一个叫做 Set-Cookie 的首部字段信息，通知客户端保存 Cookie。当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入 Cookie 值后发送出去。服务器端发现客户端发送过来的 Cookie 后，会去检查究竟是从哪一个客户端发来的连接请求，然后对比服务器上的记录，最后得到之前的状态信息。

第一次访问时，请求头当中没有 Cookie，响应当中会看到 Set-Cookie，再一次访问时，请求头中就能够看到 Cookie 信息，访问服务器任何资源，一般情况下都会把 Cookie 带过去。

Cookie 默认存储空间：

默认 Cookie 的会话级别：打开浏览器、关闭浏览器为一次会话。如果不设置持久化时间，Cookie 会存储在浏览器的内存中，浏览器关闭，Cookie 信息销毁。

设置 Cookie 在客户端的存储时间：Cookie.setMaxAge(); 如果设置持久化时间，Cookie信息就会被持久化到浏览器的磁盘文件里。

Session

简介：Session 技术是将数据存储在服务器端的技术，会为每个客户端都创建一块内存空间存储客户的数据。客户端需要每次都携带一个标识 ID 去服务器中寻找属于自己的内存空间。Session 需要借助 Cookie 存储客户的唯一标识 SessionID。

原理：Session 如何办到在一个 Servlet 当中存数据，在别的 Servlet 当中取出当初存的数据：每一个用户访问服务器时，会给该用户分配他自己对应的存储空间，并且创建的存储空间有一个编号我们称为 SessionID。第一次访问时，会把对应的 SessionID 以 Cookie 的形式写给浏览器，下次再访问时，会携带 SessionID，找到当初创建的那个存储空间，在对应的存储空间当中取出数据。

如何获取 Session 对象：

HttpSession session = request.getSession();//取出session
session.setAttribute("goods","Scoat");//session存数据
session.getAttribute("goods");//session取数据

如果服务器端没有该会话的 Session 对象，会创建一个新的 Session 返回，如果已经有了属于该会话的 Session，直接将该 Session 返回。

本质：根据 SessionID 判断该客户端是否在服务器上已经存在 Session 了。

Session 的生命周期：

创建：第一次执行 request.getSession() 创建。

销毁：①服务器关闭时；②Session 过期/失效（默认30分钟），是从最后一次操作时计时；③手动销毁：session.invalidate();

并不是浏览器一关闭，Session 就销毁。

推荐阅读：Session的工作原理_刘伦斯的博客-CSDN博客_session的工作原理

 Cookie 和 Session 有什么区别？

Cookie 和 Session都是用来跟踪浏览器用户身份的会话方式。

1）Cookie 数据保存在客户端(浏览器端)，Session 数据保存在服务器端。

2）Cookie 不是很安全，别人可以分析存放在本地的Cookie 并进行Cookie 欺骗；相对来说 Session 安全性更高。如果使用 Cookie 的一些敏感信息不要写入 Cookie 中，最好能将 Cookie 信息加密然后使用到的时候再去服务器端解密。

3）使用场景不一样。Cookie 一般用来保存用户信息：比如①我们在 Cookie 中保存已经登录过得用户信息，下次访问网站的时候页面可以自动帮你登录的一些基本信息给填了；②一般的网站都会有保持登录也就是说下次你再访问网站的时候就不需要重新登录了，这是因为用户登录的时候我们可以存放了一个 Token 在 Cookie 中，下次登录的时候只需要根据 Token 值来查找用户即可(为了安全考虑，重新登录一般要将 Token 重写)；③登录一次网站后访问网站其他页面不需要重新登录。

Session 的主要作用就是通过服务端记录用户的状态。 典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了。

---

3. HTTP 请求报文与响应报文 

用于 HTTP 协议交互的信息被称为 HTTP 报文。请求端（客户端）的 HTTP 报文叫做请求报文，响应端（服务器端）的叫做响应报文。 HTTP 报文本身是由多行数据构成的字符串文本。

①请求报文是由请求方法、请求 URI、协议版本、可选的请求首部字段和内容实体构成的。

②响应报文由协议版本、状态码、用以解释状态码的原因短语、可选的响应首部字段以及实体主体构成。

3.1 HTTP方法

1）GET ：获取资源
        GET 方法用来请求访问已被 URI 识别的资源。指定的资源经服务器端解析后返回响应内容。也就是说，如果请求的资源是文本，那就保持原样返回；如果是像 CGI 那样的程序，则返回经过执行后的输出结果。

2）POST：传输实体主体 

3）PUT：传输文件 
        PUT 方法用来传输文件。就像 FTP 协议的文件上传一样，要求在请求报文的主体中包含文件内容，然后保存到请求 URI 指定的位置。（不常用）

4）HEAD：获得报文首部
        HEAD 方法和 GET 方法一样，只是不返回报文主体部分。用于确认 URI 的有效性及资源更新的日期时间等。

5）DELETE：删除文件 
        DELETE 方法用来删除文件，是与 PUT 相反的方法。DELETE 方法按请求 URI 删除指定的资源。 （不常用）

6）OPTIONS：询问支持的方法
        OPTIONS 方法用来查询针对请求 URI 指定的资源支持的方法。

7）TRACE：追踪路径 

8）CONNECT：要求用隧道协议连接代理 
        CONNECT 方法要求在与代理服务器通信时建立隧道，实现用隧道协议进行 TCP 通信。主要使用 SSL 和 TLS 协议把通信内容加密后经网络隧道传输。

get和post区别

1）GET参数通过URL传递，POST放在 Request body中。

2）GET请求只能进行 URL编码，而 POST支持多种编码方式。

3）GET请求在URL中传送的参数有长度限制（1024个字符），而POST没有。

4）GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。

5）GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。

6）GET请求会被浏览器主动cache，而POST不会，除非手动设置。

7）GET在浏览器回退时是无害的，而POST会再次提交请求。

8）GET产生的URL地址可以被Bookmark（书签），而POST不可以。

9）对参数的数据类型，GET只接受ASCII字符，而POST没有限制。

10）GET主要为了从服务器端获取数据，POST主要为了将数据传到服务器端。

3.2 HTTP 常用状态码

1）2XX 成功
        2XX 的响应结果表明请求被正常处理了。 

• 200 OK：表示从客户端发来的请求在服务器端被正常处理了。在响应报文内，随状态码一起返回的信息会因方法的不同而发生改变。比如，使用 GET 方法时，对应请求资源的实体会作为响应返回；而使用 HEAD 方法时，在响应中只返回首部，不会返回实体的主体部分。
• 204 No Content：该状态码代表服务器接收的请求已成功处理，但在返回的响应报文中不含实体的主体部分。另外，也不允许返回任何实体的主体。
• 206 Partial Content：该状态码表示客户端进行了范围请求，而服务器成功执行了这部分的 GET 请求。响应报文中包含由 Content-Range 指定范围的实体内容。 

                
2）3XX 重定向
        3XX 响应结果表明浏览器需要执行某些特殊的处理以正确处理请求。

• 301 Moved Permanently：永久性重定向。该状态码表示请求的资源已被分配了新的 URI，以后应使用资源现在所指的 URI
• 302 Found：临时性重定向。该状态码表示请求的资源已被分配了新的 URI，希望用户（本次）能使用新的 URI 访问。 
• 303 See Other：该状态码表示由于请求对应的资源存在着另一个 URI，应使用 GET 方法定向获取请求的资源。
• 304 Not Modified：该状态码表示客户端发送附带条件的请求时，服务器端允许请求访问资源，但未满足条件的情况。
• 307 Temporary Redirect ：临时重定向。该状态码与 302 Found 有着相同的含义。尽管 302 标准禁止 POST 变换成 GET，但实际使用时大家并不遵守。 307 会遵照浏览器标准，不会从 POST 变成 GET。但是，对于处理响应时的行为，每种浏览器有可能出现不同的情况。 

3）4XX 客户端错误
        4XX 的响应结果表明客户端是发生错误的原因所在。 

• 400 Bad Request：该状态码表示请求报文中存在语法错误。
• 401 Unauthorized：该状态码表示发送的请求需要有通过 HTTP 认证（BASIC 认证、 DIGEST 认证）的认证信息。
• 403 Forbidden：该状态码表明对请求资源的访问被服务器拒绝了。
• 404 Not Found：该状态码表明服务器上无法找到请求的资源。
   

4）5XX 服务器错误
        5XX 的响应结果表明服务器本身发生错误。 

• 500 Internal Server Error：该状态码表明服务器端在执行请求时发生了错误。
• 503 Service Unavailable：该状态码表明服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。如果事先得知解除以上状况需要的时间，最好写入 RetryAfter 首部字段再返回给客户端。

推荐阅读：又是404！搞笑漫画助你理解HTTP状态码！_手机搜狐网

3.3 HTTP首部字段

HTTP 首部字段是构成 HTTP 报文的要素之一。在客户端与服务器之间以 HTTP 协议进行通信的过程中，无论是请求还是响应都会使用首部字段，它能起到传递额外重要信息的作用。使用首部字段是为了给浏览器和服务器提供报文主体大小、所使用的语言、认证信息等内容。

HTTP 首部字段根据 实际用途 被分为4 种类型：通用首部字段、请求首部字段、响应首部字段、实体首部字段。

1）通用首部字段：请求报文和响应报文两方都会使用的首部。

 Cache-Control 

通过指定首部字段 Cache-Control 的指令，就能操作缓存的工作机制。

Cache-Control 指令：

• 缓存请求指令

max-age：

当客户端发送的请求中包含 max-age 指令时，如果判定缓存资源的缓存时间数值比指定时间的数值更小，那么客户端就接收缓存的资源。 另外，当指定 max-age 值为 0，那么缓存服务器通常需要将请求转发给源服务器。

当服务器返回的响应中包含 max-age 指令时，缓存服务器将不对资源的有效性再作确认，而 max-age 数值代表资源保存为缓存的最长时间。

应用 HTTP/1.1 版本的缓存服务器遇到同时存在 Expires 首部字段的情况时，会优先处理 max-age 指令，而忽略掉 Expires 首部字段。而 HTTP/1.0 版本的缓存服务器的情况却相反，max-age 指令会被忽略掉。

• 缓存响应指令

2）请求首部字段：从客户端向服务器端发送请求报文时使用的首部。补充了请求的附加内容、客户端信息、响应内容相关优先级等信息。

3）响应首部字段：从服务器端向客户端返回响应报文时使用的首部。补充了响应的附加内容，也会要求客户端附加额外的内容信息。

ETag：

    
首部字段 ETag 能告知客户端实体标识。它是一种可将资源以字符串形式做唯一性标识的方式。服务器会为每份资源分配对应的 ETag 值。另外，当资源更新时，ETag 值也需要更新。生成 ETag 值时，并没有统一的算法规则，而仅仅是由服务器来分配。
    
资源被缓存时，就会被分配唯一性标识。例如，当使用中文版的浏览器访问 http://www.google.com/ 时，就会返回中文版对应的资源，而使用英文版的浏览器访问时，则会返回英文版对应的资源。两者的 URI 是相同的，所以仅凭 URI 指定缓存的资源是相当困难的。若在下载过程中出现连接中断、再连接的情况，都会依照 ETag 值来指定资源。

ETag 中有强 ETag 值和弱 ETag 值之分：强 ETag 值，不论实体发生多么细微的变化都会改变其值；弱 ETag 值只用于提示资源是否相同。只有资源发生了根本改变，产 生差异时才会改变 ETag 值。这时，会在字段值最开始处附加 W/。

etag的工作原理                

4）实体首部字段：针对请求报文和响应报文的实体部分使用的首部。补充了资源内容更新时间等与实体有关的信息。

Expires：

首部字段 Expires 会将资源失效的日期告知客户端。缓存服务器在接收到含有首部字段 Expires 的响应后，会以缓存来应答请求，在 Expires 字段值指定的时间之前，响应的副本会一直被保存。当超过 指定的时间后，缓存服务器在请求发送过来时，会转向源服务器请求资源。
源服务器不希望缓存服务器对资源缓存时，最好在 Expires 字段内写 入与首部字段 Date 相同的时间值。 
但是，当首部字段 Cache-Control 有指定 max-age 指令时，比起首部字段 Expires，会优先处理 max-age 指令。 

---

4. 长连接与短连接

在 HTTP/1.0 中默认使用短连接。也就是说，客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。

而从HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头加入这行代码：

Connection:keep-alive

在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接需要客户端和服务端都支持长连接。

HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。

持久连接使得多数请求以管线化（pipelining）方式发送成为可能。从前发送请求后需等待并收到响应，才能发送下一个请求。管线化技术出现后，不用等待响应亦可直接发送下一个请求。这样就能够做到同时并行发送多个请求，而不需要一个接一个地等待 响应了。

长连接和短连接的优点和缺点：

1）长连接可以省去较多的TCP建立和关闭的操作，减少浪费，节约时间。对于频繁请求资源的客户来说，较适用长连接。

2）短连接对于服务器来说管理较为简单，存在的连接都是有用的连接，不需要额外的控制手段。但如果客户请求频繁，将在TCP的建立和关闭操作上浪费时间和带宽。

推荐阅读：长连接、短连接

---

5. URI和URL的区别

URI，是uniform resource identifier，统一资源标识符，用来唯一的标识一个资源。

Web上可用的每种资源如HTML文档、图像、视频片段、程序等都是一个来URI来定位的。

URI一般由三部组成：

• 访问资源的命名机制
• 存放资源的主机名
• 资源自身的名称，由路径表示，着重强调于资源。

URL，是uniform resource locator，统一资源定位器，它是一种具体的URI，即URL可以用来标识一个资源，而且还指明了如何locate这个资源。

URL是Internet上用来描述信息资源的字符串，主要用在各种WWW客户程序和服务器程序上，特别是著名的Mosaic。

采用URL可以用一种统一的格式来描述各种信息资源，包括文件、服务器的地址和目录等。URL一般由三部组成：

• 协议(或称为服务方式)
• 存有该资源的主机IP地址(有时也包括端口号)
• 主机资源的具体地址。如目录和文件名等

---

6. HTTP 存在的安全性问题，以及 HTTPS 的加密、认证和完整性保护作用。

6.1 HTTP存在的问题

1）通信使用明文（不加密），内容可能会被窃听。

加密处理防止被窃听：

①通信的加密

HTTP 协议中没有加密机制，但可以通过和 SSL或 TLS的组合使用， 加密 HTTP 的通信内容。 用 SSL 建立安全通信线路之后，就可以在这条线路上进行 HTTP 通信了。与 SSL 组合使用的 HTTP 被称为 HTTPS 或 HTTP over SSL。

②内容的加密

由于 HTTP 协议中没有加密机制，那么就对 HTTP 协议传输的内容本身加密。即把 HTTP 报文里所含的内容进行加密处理。

2）不验证通信方的身份，因此有可能遭遇伪装。

在 HTTP 协议通信时，由于不存在确认通信方的处理步骤，任何人都可以发起请求。另外，服务器只要接收到请求，不管对方是谁都会返回一个响应（但也仅限于发送端的 IP 地址和端口号没有被 Web 服务器设定限制访问的前提下）。
        
因此不确认通信方，会存在以下各种隐患。

• 无法确定请求发送至目标的 Web 服务器是否是目标服务器。有可能是已伪装的 Web 服务器。
• 无法确定响应返回到的客户端是否是目标客户端。有可能是已伪装的客户端。
• 无法确定正在通信的对方是否具备访问权限。因为某些 Web 服务器上保存着重要的信息，只想发给特定用户通信的权限。
• 无法判定请求是来自何方、出自谁手。
• 即使是无意义的请求也会照单全收。无法阻止海量请求下的 DoS 攻击（拒绝服务攻击）。

虽然使用 HTTP 协议无法确定通信方，但如果使用 SSL 则可以。 SSL 不仅提供加密处理，而且还使用了一种被称为证书的手段， 可用于确定通信方。证书由值得信任的第三方机构颁发，用以证明服务器和客户端是实际存在的。另外，伪造证书从技术角度来说是异常困难的一件事。所以只要能够确认通信方（服务器或客户端）持有的证书， 即可判断通信方的真实意图。

3）无法证明报文的完整性，所以有可能已遭篡改。

由于 HTTP 协议无法证明通信的报文完整性，因此，在请求或响应送出之后直到对方接收之前的这段时间内，即使请求或响应的内容遭到篡改，也没有办法获悉。

像这样，请求或响应在传输途中，遭攻击者拦截并篡改内容的攻 击称为中间人攻击（Man-in-the-Middle attack，MITM）。

虽然有使用 HTTP 协议确定报文完整性的方法，但事实上并不便捷、可靠。其中常用的是 MD5 和 SHA-1 等散列值校验的方法， 以及用来确认文件的数字签名方法。

提供文件下载服务的 Web 网站也会提供相应的以 PGP（Pretty Good Privacy，完美隐私）创建的数字签名及 MD5 算法生成的散列值。PGP 是用来证明创建文件的数字签名，MD5 是由单向函数生成的散列值。不论使用哪一种方法，都需要操纵客户端的用户本人亲自检查验证下载的文件是否就是原来服务器上的文件。 浏览器无法自动帮用户检查。
 

6.2 HTTP 加上加密处理和认证以及完整性保护后即是 HTTPS 

HTTPS 并非是应用层的一种新协议。只是 HTTP 通信接口部分用 SSL和 TLS协议代替而已。通常，HTTP 直接和 TCP 通信。当使用 SSL 时，则演变成先和 SSL 通信，再由 SSL 和 TCP 通信了。简言之，HTTPS 是身披 SSL 外壳的 HTTP。在采用 SSL 后，HTTP 就拥有了 HTTPS 的加密、证书和完整性保护这些功能。

SSL 是独立于 HTTP 的协议，所以不光是 HTTP 协议，其他运行在应用层的 SMTP 和 Telnet 等协议均可配合 SSL 协议使用。可以说 SSL 是 当今世界上应用最为广泛的网络安全技术。

6.2.1 HTTPS 的加密：

1）共享密钥加密：

加密和解密同用一个密钥的方式称为共享密钥加密，也被叫做对称密钥加密。以共享密钥方式加密时必须将密钥也发给对方。

局限性：以共享密钥方式加密时必须将密钥也发给对方。可究竟怎样才能安全地转交？在互联网上转发密钥时，如果通信被监听那么密钥就可会落入攻击者之手，同时也就失去了加密的意义。另外还得设法安全地保管接收到的密钥。

2）公开密钥加密

公开密钥加密使用一对非对称的密钥。一把叫做私有密钥 ，另一把叫做公开密钥。顾名思义，私有密钥不能让其他任何人知道，而公开密钥则可以随意发布，任何人都可以获得。使用公开密钥加密方式，发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密。利用这种方式，不需要发送用来解密的私有密钥，也不必担心密钥被攻击者窃听而盗走。

 

6.2.2  证明公开密钥正确性的证书

遗憾的是，公开密钥加密方式还是存在一些问题的。那就是无法证明公开密钥本身就是货真价实的公开密钥。比如，正准备和某台服务器建立公开密钥加密方式下的通信时，如何证明收到的公开密钥就是原本预想的那台服务器发行的公开密钥。或许在公开密钥传输途中，真正的公开密钥已经被攻击者替换掉了。为了解决上述问题，可以使用由数字证书认证机构（CA，Certificate Authority）和其相关机关颁发的公开密钥证书。

数字证书认证机构的业务流程：
        首先，服务器的运营人员向数字证书认证机构提出公开密钥的申请。数字证书认证机构在判明提出申请者的身份之后，会对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥，并将该公开密钥放入公钥证书后绑定在一起。服务器会将这份由数字证书认证机构颁发的公钥证书发送给客户端，以进行公开密钥加密方式通信。（公钥证书也可叫做数字证书或直接称为证书。）接到证书的客户端可使用数字证书认证机构的公开密钥，对那张证书上的数字签名进行验证，一旦验证通过，客户端便可明确两件事： 一，认证服务器的公开密钥的是真实有效的数字证书认证机构。二， 服务器的公开密钥是值得信赖的。

此处认证机关的公开密钥必须安全地转交给客户端。使用通信方式时，如何安全转交是一件很困难的事，因此，多数浏览器开发商发布版本时，会事先在内部植入常用认证机关的公开密钥。

证书的一个作用是用来证明作为通信一方的服务器是否规范，另外一个作用是可确认对方服务器背后运营的企业是否真实存在。 拥有该特性的证书就是 EV SSL 证书。 

HTTPS 中还可以使用客户端证书。以客户端证书进行客户端认证，证明服务器正在通信的对方始终是预料之内的客户端，其作用跟服务器证书如出一辙。

但客户端证书仍存在几处问题点：
①证书的获取及发布
           想获取证书时，用户得自行安装客户端证书。但由于客户端证书是要付费购买的，且每张证书对应到每位用户也就意味着需支付和用户数对等的费用。另外，要让知识层次不同的用户们自行安装证书，这件事本身也充满了各种挑战。
②客户端证书毕竟只能用来证明客户端实际存在，而不能用来证明用户本人的真实有效性。

6.2.3 HTTPS 的安全通信机制 

HTTPS 的通信步骤：

• 步骤 1： 客户端通过发送 Client Hello 报文开始 SSL 通信。报文中包含客户端支持的 SSL 的指定版本、加密组件列表（所使用的加密算法及密钥长度等）。
• 步骤 2： 服务器可进行 SSL 通信时，会以 Server Hello 报文作为应答。和客户端一样，在报文中包含 SSL 版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。
• 步骤 3： 之后服务器发送 Certificate 报文。报文中包含公开密钥证书。
• 步骤 4： 最后服务器发送 Server Hello Done 报文通知客户端，最初阶段的 SSL 握手协商部分结束。 
• 步骤 5： SSL 第一次握手结束之后，客户端以 Client Key Exchange 报文作为回应。报文中包含通信加密中使用的一种被称为 Pre-master secret 的随机密码串。该报文已用步骤 3 中的公开密钥进行加密。
•  步骤 6： 接着客户端继续发送 Change Cipher Spec 报文。该报文会提示服务器，在此报文之后的通信会采用 Pre-master secret 密钥加密。
•  步骤 7： 客户端发送 Finished 报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准。
• 步骤 8： 服务器同样发送 Change Cipher Spec 报文。 
• 步骤 9： 服务器同样发送 Finished 报文。
• 步骤 10： 服务器和客户端的 Finished 报文交换完毕之后，SSL 连接就算建立完成。当然，通信会受到 SSL 的保护。从此处开始进行应用层协议的通信，即发送 HTTP 请求。
• 步骤 11： 应用层协议通信，即发送 HTTP 响应。
• 步骤 12： 最后由客户端断开连接。断开连接时，发送 close_notify 报文。上图做了一些省略，这步之后再发送 TCP FIN 报文来关闭与 TCP 的通信。

在以上流程中，应用层发送数据时会附加一种叫做 MAC（Message Authentication Code）的报文摘要。MAC 能够查知报文是否遭到篡改，从而保护报文的完整性。

HTTPS 也存在一些问题，那就是当使用 SSL 时，它的处理速度会变慢。SSL 的慢分两种：一种是指通信慢。另一种是指由于大量消耗 CPU 及内存等资源，导致处理速度变慢。
        

---

7. HTTP/1.x 的缺陷，以及 HTTP/2 的特点。

7.1 HTTP的瓶颈

在 Facebook 和 Twitter 等 SNS 网站上，几乎能够实时观察到海量用户公开发布的内容，这也是一种乐趣。当几百、几千万的用户发布内容时，Web 网站为了保存这些新增内容，在很短的时间内就会发生大量的内容更新。为了尽可能实时地显示这些更新的内容，服务器上一有内容更新，就需要直接把那些内容反馈到客户端的界面上。虽然看起来挺简单的， 但 HTTP 却无法妥善地处理好这项任务。 使用 HTTP 协议探知服务器上是否有内容更新，就必须频繁地从客户端到服务器端进行确认。如果服务器上没有内容更新，那么就会产生徒劳的通信。

若想在现有 Web 实现所需的功能，以下这些 HTTP 标准就会成为瓶颈：

• 一条连接上只可发送一个请求。
• 请求只能从客户端开始。客户端不可以接收除响应以外的指 令。
• 请求 / 响应首部未经压缩就发送。首部信息越多延迟越大。
• 发送冗长的首部。每次互相发送相同的首部造成的浪费较多。
• 可任意选择数据压缩格式。非强制压缩发送。

 

7.1.1 Ajax 的解决方法 
    Ajax是一种有效利用 JavaScript 和 DOM的操作，以达到局部 Web 页面替换加载的异步通信手段。和以前的同步通信相比，由于它只更新一部分页面，响应中传输的数据量会因此而减少，这一优点显而易见。
    而利用 Ajax 实时地从服务器获取内容，有可能会导致大量请求产生。另外，Ajax 仍未解决 HTTP 协议本身存在的问题。
        
7.2.2 Comet 的解决方法 
    一旦服务器端有内容更新了，Comet 不会让请求等待，而是直接给客户端返回响应。这是一种通过延迟应答，模拟实现服务器端向客户端推送（Server Push）的功能。
    通常，服务器端接收到请求，在处理完毕后就会立即返回响应，但为了实现推送功能，Comet 会先将响应置于挂起状态，当服务器端有内容更新时，再返回该响应。因此，服务器端一旦有更新，就可以立即反馈给客户端。
    内容上虽然可以做到实时更新，但为了保留响应，一次连接的持续时间也变长了。期间，为了维持连接会消耗更多的资源。另外，Comet 也仍未解决 HTTP 协议本身存在的问题。

7.2.3 消除 HTTP 瓶颈的 SPDY

SPDY 没有完全改写 HTTP 协议，而是在 TCP/IP 的应用层与运输层之间通过新加会话层的形式运作。同时，考虑到安全性问题，SPDY 规定通信中使用 SSL。SPDY 以会话层的形式加入，控制对数据的流动，但还是采用 HTTP 建立通信连接。因此，可照常使用 HTTP 的 GET 和 POST 等方法、 Cookie 以及 HTTP 报文等。

使用 SPDY 后，HTTP 协议额外获得以下功能：

• 多路复用流：通过单一的 TCP 连接，可以无限制处理多个 HTTP 请求。所有请求的处理都在一条 TCP 连接上完成，因此 TCP 的处理效率得到提高。
• 赋予请求优先级：SPDY 不仅可以无限制地并发处理请求，还可以给请求逐个分配优先级顺序。这样主要是为了在发送多个请求时，解决因带宽低而导致响应变慢的问题。
• 压缩 HTTP 首部 ：压缩 HTTP 请求和响应的首部。这样一来，通信产生的数据包数量和发送的字节数就更少了。
• 推送功能：支持服务器主动向客户端推送数据的功能。这样，服务器可直接发送数据，而不必等待客户端的请求。
• 服务器提示功能：服务器可以主动提示客户端请求所需的资源。由于在客户端发现资源之前就可以获知资源的存在，因此在资源已缓存等情况下，可以避免发送不必要的请求。

因为 SPDY 基本上只是将单个域名（ IP 地址）的通信多路复用，所以当一个 Web 网站上使用多个域名下的资源，改善效果就会受到限制。

7.2.4  使用浏览器进行全双工通信的 WebSocket

WebSocket，即 Web 浏览器与 Web 服务器之间全双工通信标准。其中，WebSocket 协议由 IETF 定为标准，WebSocket API 由 W3C 定为标准。仍在开发中的 WebSocket 技术主要是为了解决 Ajax 和 Comet 里 XMLHttpRequest 附带的缺陷所引起的问题。 

一旦 Web 服务器与客户端之间建立起 WebSocket 协议的通信连接，之后所有的通信都依靠这个专用协议进行。通信过程中可互相发送 JSON、XML、HTML 或图片等任意格式的数据。由于是建立在 HTTP 基础上的协议，因此连接的发起方仍是客户端， 而一旦确立 WebSocket 通信连接，不论服务器还是客户端，任意一方都可直接向对方发送报文。

WebSocket 协议的主要特点

• 推送功能：支持由服务器向客户端推送数据的推送功能。这样，服务器可直接发送数据，而不必等待客户端的请求。
• 减少通信量：只要建立起 WebSocket 连接，就希望一直保持连接状态。和 HTTP 相比，不但每次连接时的总开销减少，而且由于 WebSocket 的首部信息很小，通信量也相应减少了。

为了实现 WebSocket 通信，在 HTTP 连接建立之后，需要完成一次“握手”（Handshaking）的步骤。 
①握手·请求 
            为了实现 WebSocket 通信，需要用到 HTTP 的 Upgrade 首部字段，告知服务器通信协议发生改变，以达到握手的目的。Sec-WebSocket-Key 字段内记录着握手过程中必不可少的键值。 Sec-WebSocket-Protocol 字段内记录使用的子协议。子协议按 WebSocket 协议标准在连接分开使用时，定义那些连接的名称。
②握手·响应 
            对于之前的请求，返回状态码 101 Switching Protocols 的响应。成功握手确立 WebSocket 连接之后，通信时不再使用 HTTP 的数据帧，而采用 WebSocket 独立的数据帧。
               

7.2 HTTP/2

HTTP/2 是 HTTP 协议自 1999 年 HTTP 1.1 发布后的首个更新，主要基于 SPDY 协议。

HTTP/2.0 的目标是改善用户在使用 Web 时的速度体验。由于基本上都会先通过 HTTP/1.1 与 TCP 连接，现在我们以下面的这些协议为基础，探讨一下它们的实现方法。

• SPDY
• HTTP Speed ＋ Mobility：由微软公司起草，是用于改善并提高移动端通信时的通信速度和性能的标准。它建立在 Google 公司提出的 SPDY 与 WebSocket 的基础之上。
• Network-Friendly HTTP Upgrade ：主要是在移动端通信时改善 HTTP 性能的标准。

HTTP/2.0 围绕着主要的 7 项技术进行讨论，现阶段（2012 年 8 月 13 日），大都倾向于采用以下协议的技术。
    

推荐阅读：HTTP/2核心特性

HTTP/2特性详解 - 云+社区 - 腾讯云

---

8. HTTP/1.1 的特性以及 HTTP/1.0 和 HTTP/1.1 的区别

HTTP1.0最早在网页中使用是在1996年，那个时候只是使用一些较为简单的网页上和网络请求上，而HTTP1.1则在1999年才开始广泛应用于现在的各大浏览器网络请求中，同时HTTP1.1也是当前使用最为广泛的HTTP协议。 

主要区别主要体现在：

1）长连接：在HTTP/1.0中，默认使用的是短连接，也就是说每次请求都要重新建立一次连接。HTTP 是基于TCP/IP协议的,每一次建立或者断开连接都需要三次握手四次挥手的开销，如果每次请求都要这样的话，开销会比较大。因此最好能维持一个长连接，可以用个长连接来发多个请求。HTTP 1.1起，默认使用长连接 ,默认开启Connection： keep-alive。 HTTP/1.1的持续连接有非流水线方式和流水线方式 。流水线方式是客户在收到HTTP的响应报文之前就能接着发送新的请求报文。与之相对应的非流水线方式是客户在收到前一个响应后才能发送下一个请求。

2）错误状态响应码：在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。

3）缓存处理：在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。

4）带宽优化及网络连接的使用：HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。

推荐阅读：HTTP1.0、HTTP1.1 和 HTTP2.0 的区别

---

9. HTTP 与 FTP 的比较。

 同： 

• 都是应用层协议； 
• 都运行在TCP上，即都使用TCP（而不是UDP）作为其支撑的运输层协议。 

异： 

• HTTP是超文本传输协议，是面向网页的；FTP是文件传输协议，是面向文件的。 
• HTTP协议默认端口：80号端口。FTP协议默认端口：21号端口。 
• FTP的控制信息是带外（out-of-band）传送的，而HTTP的控制信息是带内（in-band）传送的。 
• FTP服务器必须在整个会话期间保留用户的状态（state）信息，而HTTP是无状态的。 
• FTP的控制连接是持久连接，数据连接是非持久连接；而HTTP既可以使用非持久连接，也可以使用持久连接，默认方式下，HTTP使用持久连接。 

推荐阅读：

ftp和http区别_only_musm的博客-CSDN博客_http和ftp的区别

HTTP和FTP的区别_苹果园-CSDN博客_http和ftp

---

10. 在浏览器中输入url地址 ->> 显示主页的过程

首先发给DNS服务器，进行域名解析，得到IP地址后生成针对目标Web服务器的HTTP请求报文，然后报文由TCP协议负责传输，为了方便通信，HTTP请求报文被分为报文段，然后每个报文可靠地传输给对方，报文段由IP层负责一边中转一边传送，服务器收到报文段后重组报文段，然后由应用层的HTTP协议处理请求的内容，请求的结果以同样的方式进行。

例如：在浏览器地址栏键入URL，按下回车之后会经历以下流程：

1、浏览器向 DNS 服务器请求解析该 URL 中的域名所对应的 IP 地址;

2、解析出 IP 地址后，根据该 IP 地址和默认端口 80，和服务器建立TCP连接;

3、浏览器发出读取文件(URL 中域名后面部分对应的文件)的HTTP 请求，该请求报文作为 TCP 三次握手的第三个报文的数据发送给服务器;

4、服务器对浏览器请求作出响应，并把对应的 html 文本发送给浏览器;

5、释放 TCP连接;

6、浏览器将该 html 文本并显示内容; 

HTTP 服务器工作原理

1. 用户通过浏览器进行了一个操作，比如输入网址并回车，或者是点击链接，接着浏览器获取了这个事件。
2. 浏览器向服务端发出 TCP 连接请求。
3. 服务程序接受浏览器的连接请求，并经过 TCP 三次握手建立连接。
4. 浏览器将请求数据打包成一个 HTTP 协议格式的数据包。
5. 浏览器将该数据包推入网络，数据包经过网络传输，最终达到端服务程序。
6. 服务端程序拿到这个数据包后，同样以 HTTP 协议格式解包，获取到客户端的意图。
7. 得知客户端意图后进行处理，比如提供静态文件或者调用服务端程序获得动态结果。
8. 服务器将响应结果（可能是 HTML 或者图片等）按照 HTTP 协议格式打包。
9. 服务器将响应数据包推入网络，数据包经过网络传输最终达到到浏览器。
10. 浏览器拿到数据包后，以 HTTP 协议的格式解包，然后解析数据，假设这里的数据是 HTML。
11. 浏览器将 HTML 文件展示在页面上。

---

11. Servlet和CGI的区别

CGI（Common Gateway Interface，通用网关接口）是指 Web 服务器在接收到客户端发送过来的请求后转发给程序的一组机制。在 CGI 的作用下，程序会对请求内容做出相应的动作，比如创建 HTML 等动态内容。使用 CGI 的程序叫做 CGI 程序，通常是用 Perl、PHP、Ruby 和 C 等 编程语言编写而成。

Servlet 是一种能在服务器上创建动态内容的程序。Servlet 是用 Java 语言实现的一个接口，属于面向JavaEE的一部分。

CGI 由于每次接到请求，程序都要跟着启动一次。因此一旦访问量过大，Web 服务器要承担相当大的负载。而 Servlet 运行在与 Web 服务器相同的进程中，因此受到的负载较小 。

CGI的不足之处:
1，需要为每个请求启动一个操作CGI程序的系统进程。如果请求频繁，这将会带来很大的开销。
2，需要为每个请求加载和运行一个CGI程序，这将带来很大的开销
3，需要重复编写处理网络协议的代码以及编码，这些工作都是非常耗时的。

Servlet的优点:
1，只需要启动一个操作系统进程以及加载一个JVM，大大降低了系统的开销
2，如果多个请求需要做同样处理的时候，这时候只需要加载一个类，这也大大降低了开销
3，所有动态加载的类可以实现对网络协议以及请求解码的共享，大大降低了工作量。
4，Servlet能直接和Web服务器交互，而普通的CGI程序不能。Servlet还能在各个程序之间共享数据，使数据库连接池之类的功能很容易实现。

---

推荐阅读：

https://segmentfault.com/a/1190000009013579

HTTP面试题都在这里 - 知乎

Nginx详解二十：Nginx深度学习篇之HTTPS的原理和作用、配置及优化 - 向前走。 - 博客园