HTTP协议解析

简述http，主要特点，1.0, 1.1, 2.0 和 3.0区别

HTTP（HyperText Transfer Protocol）超文本传输协议，是TCP/IP协议集中的一个应用层协议，用于定义浏览器和Web服务器之间交换数据的过程以及数据本身的格式。

HTTP工作模式

HTTP1.0,1.1, 2.0 区别（发展）

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

• HTTP 2.0

  • 头部压缩，双方各自维护一个header的索引表，使得不需要直接发送值，通过发送key缩减头部大小
  • 多路复用，使用多个stream，每个stream又分帧传输，使得一个tcp连接能够处理多个http请求
  • 可以使用服务端推送

HTTP/1.x 缺陷：HTTP/1.x 实现简单、以牺牲性能为代价的

• 客户端需要使用多个连接才能实现并发和缩短延迟；
• 不会压缩请求和响应首部，从而导致不必要的网络流量；
• 不支持有效的资源优先级，致使底层 TCP 连接的利用率低下。

二者区别：http1.1 -> http2.0

• HTTP2使用的是二进制传送，HTTP1.X是文本（字符串）传送。二进制传送的单位是帧和流。帧组成了流，同时流还有流ID标识。
• HTTP2支持多路复用。因为有流ID，所以通过同一个http请求实现多个http请求传输变成了可能，可以通过流ID来标识究竟是哪个流从而定位到是哪个http请求。
• HTTP2头部压缩。HTTP2通过gzip和compress压缩头部然后再发送，同时客户端和服务器端同时维护一张头信息表，所有字段都记录在这张表中，这样后面每次传输只需要传输表里面的索引ID就行，通过索引ID查询表头的值。
• HTTP2支持服务器推送。HTTP2支持在未经客户端许可的情况下，主动向客户端推送内容。

拓展： HTTP长连接/短连接?

• 在HTTP/1.0中默认使用短连接。也就是说，客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源（如JavaScript文件、图像文件、CSS文件等），每遇到这样一个Web资源，浏览器就会重新建立一个HTTP会话。

• 从HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头加入这行代码：Connection:keep-alive。在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接需要客户端和服务端都支持长连接。

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

拓展：Host 是 HTTP 1.1 协议中新增的一个请求头，主要用来实现虚拟主机技术。

• 虚拟主机（virtual hosting）即共享主机（shared web hosting），可以利用虚拟技术（网络空间技术，空分复用）把一台完整的服务器分成若干网络空间，每一台网络空间都拥有独立域名和IP地址，具备完整的Internet服务器的功能。因此可以在单一主机上运行多个网站或服务。

• 举个栗子，有一台 ip 地址为 61.135.169.125 的服务器，在这台服务器上部署着谷歌、百度、淘宝的网站。为什么我们访问 https://www.google.com 时，看到的是 Google 的首页而不是百度或者淘宝的首页？原因就是Host 请求头决定着访问哪个虚拟主机。

补充与总结：

HTTP 1.0
无状态，无连接；
短连接：每次发送请求都要重新建立tcp请求，即三次握手，非常浪费性能；
无host头域，也就是http请求头里的host；
不允许断点续传，而且不能只传输对象的一部分，要求传输整个对象。
HTTP 1.1
长连接，流水线，使用connection:keep-alive使用长连接；
请求管道化；
增加缓存处理(新的字段如cache-control)；
增加Host字段，支持断点传输等；
由于长连接会给服务器造成压力。
HTTP 2.0
二进制分帧；
多路复用(或连接共享)，使用多个stream，每个stream又分帧传输，使得一个tcp连接能够处理多个http请求；
头部压缩，双方各自维护一个header的索引表，使得不需要直接发送值，通过发送key缩减头部大小；
服务器推送(Sever push)。
HTTP 3.0
基于google的QUIC协议，而quic协议是使用udp实现的；
减少了tcp三次握手时间，以及tls握手时间；
解决了http 2.0中前一个stream丢包导致后一个stream被阻塞的问题；
优化了重传策略，重传包和原包的编号不同，降低后续重传计算的消耗；
连接迁移，不再用tcp四元组确定一个连接，而是用一个64位随机数来确定这个连接；
更合适的流量控制。

HTTP和TCP是有状态还是无状态？两者之间的联系与区别？

• HTTP无状态协议，是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传。这样缺点是导致每次连接传送的数据量增大（每次请求会传输大量重复信息）。优点是，在服务器不需要先前信息时它的应答就较快（点到为止，解放了服务器）。

  客户端与服务器进行动态交互的 Web 应用程序出现之后，HTTP 无状态的特性严重阻碍了这些应用程序的实现，毕竟交互是需要承前启后的，简单的购物车程序也要知道用户到底在之前选择了什么商品。于是保持HTTP连接状态的技术应运而生：

  • 通过cookie：cookie可以保持登录信息到用户下次与服务器的会话，即下次访问同一网站时，用户会发现不必输入用户名和密码就已经登录了（当然，不排除用户手工删除Cookie）。而还有一些Cookie在用户退出会话的时候就被删除了，这样可以有效保护个人隐私。

    Cookies 最典型的应用是判定注册用户是否已经登录网站，用户可能会得到提示，是否在下一次进入此网站时保留用户信息以便简化登录手续，这些都是 Cookies 的功用。另一个重要应用场合是“购物车”之类处理。用户可能会在一段时间内在同一家网站的不同页面中选择不同的商品，这些信息都会写入 Cookies，以便在最后付款时提取信息。

  • 通过session会话保存：与cookie相对的解决方案，session是通过服务器来保持状态的。当客户端访问服务器时，服务器根据需求设置 Session，将会话信息保存在服务器上，同时将标示 Session 的 SessionId 传递给客户端浏览器，浏览器将这个 SessionId 保存在内存中，我们称之为无过期时间的 Cookie。浏览器关闭后，这个 Cookie 就会被清掉，它不会存在于用户的 Cookie 临时文件。

    以后浏览器每次请求都会额外加上这个参数值，服务器会根据这个 SessionId，就能取得客户端的数据信息。

    如果客户端浏览器意外关闭，服务器保存的 Session 数据不是立即释放，此时数据还会存在，只要我们知道那个 SessionId，就可以继续通过请求获得此 Session 的信息，因为此时后台的 Session 还存在，当然我们可以设置一个 Session 超时时间，一旦超过规定时间没有客户端请求时，服务器就会清除对应 SessionId 的 Session 信息。

• TCP协议是一种有状态协议。具体见tcp/ip详解。

联系与区别：

Http协议是建立在TCP协议基础之上的，当浏览器需要从服务器获取网页数据的时候，会发出一次Http请求。Http会通过TCP建立起一个到服务器的连接通道，当本次请求需要的数据完毕后，Http会立即将TCP连接断开，这个过程是很短的。所以Http连接是一种短连接，是一种无状态的连接。

• TCP是传输层协议：负责数据的传输（定义传输数据内容的规范），包括定义端口、流量控制与数据校验等。
• HTTP是应用层协议：负责请求和响应数据的封装（定义的是数据传输与连接方式的规范），请求报文包括请求行（请求方法、url与http版本信息）、请求头与请求体；响应报文包括状态行（http版本、状态码与对应的状态信息）、响应头与响应体。

常用的HTTP方法有哪些？

一共有八种，HTTP1.0三种：

• GET： 用于请求访问已经被URI（统一资源标识符）识别的资源，可以通过URL传参给服务器
• POST：用于传输信息给服务器，主要功能与GET方法类似，但一般推荐使用POST方式。
• HEAD： 获得报文首部，与GET方法类似，只是不返回报文主体，一般用于验证URI是否有效。

HTTP1.1增加了5种：

• PUT： 传输文件，报文主体中包含文件内容，保存到对应URI位置。
• DELETE：删除文件，与PUT方法相反，删除对应URI位置的文件。
• OPTIONS：查询相应URI支持的HTTP方法。
• TRACE 和 CONNECT方法

ps: GET方法与POST方法的区别？

• GET和POST在本质上没有区别，都是HTTP协议中的两种发送请求的方法。而HTTP呢，是基于TCP/IP的关于数据如何在万维网中如何通信的协议。GET/POST都是TCP链接。

• 功能上（应用场景）：get重点在从服务器上获取资源，post重点在向服务器发送数据（更新服务器资源）；
• REST服务角度上：GET是幂等的，即读取同一个资源，总是得到相同的数据，而POST不是幂等的，因为每次请求对资源的改变并不是相同的；进一步地，GET不会改变服务器上的资源，而POST会对服务器资源进行改变；
• http传参类型：GET 请求由 url 触发，想携带参数就只能在 url 后附加（GET只接受ASCII字符，POST没有限制）。POST 请求来自表单提交，表单数据被浏览器编码到 HTTP 请求报文的请求体中。
• 大小限制：GET 长度受限于 url，而 url 的长度由浏览器和服务器决定。POST 没有大小限制，起限制作用的是服务器的处理能力。
• 安全的角度：POST的安全性要比GET的安全性高，因为GET请求提交的数据将明文出现在URL上，而且POST请求参数则被包装到请求体中，相对更安全。但无论 GET 还是 POST 都不安全，因为 HTTP 是明文协议。
• GET请求会被浏览器主动缓存，而POST不会，除非手动设置。
• GET在浏览器回退时是无害的，而POST会再次提交请求。

HTTP请求报文与响应报文格式

请求报文包含三部分：请求行、请求头部、空行和请求数据。

• 请求行：包含请求方法、URL、HTTP版本信息
  

  ps：空格不能缺省。
  • 请求方法（见上）：当然并不是所有的服务器都实现了所有的方法，部分方法即便支持，处于安全性的考虑也是不可用的
  • 请求路径：主机域名、资源路径
  • 版本号格式：HTTP/主版本号.次版本号，如HTTP/1.0和HTTP/1.1

• 请求头部：为请求报文添加了一些附加信息，由“名/值”对组成，每行一对，名和值之间使用冒号分隔，常见请求头如下：

请求头（名）	说明
Host	接受请求的服务器地址，可以是IP:端口号，也可以是域名
User-Agent	发送请求的应用程序名称
Connection	指定与连接相关的属性，如Connection:Keep-Alive（使用长连接）
Accept-Charset	通知服务端可以发送的编码格式
Accept-Encoding	通知服务端可以发送的数据压缩格式，如gzip，deflate
Accept-Language	通知服务端可以发送的语言，如zh-CN（简体中文）

• 请求正文（可选）：比如GET请求就没有请求正文

请求报文总结：

示例：

---

响应报文包含三部分：响应行（状态行），响应头，和响应体

• 状态行：包含HTTP版本、状态码、对应的状态信息，空格不能缺省。

• 响应头部：

  与请求头部类似，为响应报文添加了一些附加信息

响应头（名）
Server	服务器应用程序软件的名称和版本
Content-Type	响应正文的类型（是图片image还是二进制字符串）
Content-Length	响应正文长度
Content-Charset	响应正文使用的编码
Content-Encoding	响应正文使用的数据压缩格式
Content-Language	响应正文使用的语言

• 响应正文（存放返回客户端的信息），作用方式类似请求体。

响应报文总结

ps: URI、URN和URL的区别

• URI全名为Uniform Resource Indentifier（统一资源标识），用来唯一的标识一个资源，是一个通用的概念，URI由两个主要的子集URL和URN组成

• URL全名为Uniform Resource Locator（统一资源定位），通过描述资源的位置来标识资源

• URN全名为Uniform Resource Name（统一资源命名），通过资源的名字来标识资源，与其所处的位置无关，这样即使资源的位置发生变动，其URN也不会变化

HTTP规范将更通用的概念URI作为其资源标识符，但是实际上，HTTP应用程序处理的只是URI的URL子集

在Java的URI中，一个URI实例可以代表绝对的，也可以是相对的，只要它符合URI的语法规则。而URL类则不仅符合语义，还包含了定位该资源的信息，因此它不能是相对的。

• 在Java类库中，URI类不包含任何访问资源的方法，URI唯一的作用就是解析。
• 相反的是，URL类可以打开一个到达资源的流。

HTTP常见的状态码？

（1）1XX 提示信息，表示目前是协议处理的中间状态，还需要后续的操作。

• 100 Continue ：表明到目前为止都很正常，客户端可以继续发送请求或者忽略这个响应。

（2）#2XX 成功，报文已被收到并正确处理

• 200 OK，响应成功
• 201 Created 该请求已成功，并因此创建了一个新的资源。这通常是在POST请求，或是某些PUT请求之后返回的响应。
• 204 No Content ：请求已经成功处理，但是返回的响应报文不包含实体的主体部分。一般在只需要从客户端往服务器发送信息，而不需要返回数据时使用。
• 206 Partial Content ：表示客户端进行了范围请求，响应报文包含由 Content-Range 指定范围的实体内容。

（3）#3XX 重定向，资源位置发生变动，需要客户端重新发送请求。

• 301 Moved Permanently ：永久性重定向
• 302 Found ：临时性重定向，服务器返回的头部信息中会包含一个 Location 字段，内容是重定向到的url。
• 303 See Other ：和 302 有着相同的功能，但是 303 明确要求客户端应该采用 GET 方法获取资源。
• 注：虽然 HTTP 协议规定 301、302 状态下重定向时不允许把 POST 方法改成 GET 方法，但是大多数浏览器都会在 301、302 和 303 状态下的重定向把 POST 方法改成 GET 方法。
• 304 Not Modified ：如果请求报文首部包含一些条件，例如：If-Match，If-Modified-Since，If-None-Match，If-Range，If-Unmodified-Since，如果不满足条件，则服务器会返回 304 状态码。
• 307 Temporary Redirect ：临时重定向，与 302 的含义类似，但是 307 要求浏览器不会把重定向请求的 POST 方法改成 GET 方法。

（4）#4XX 客户端错误，请求报文有误，服务器无法处理。

• 400 Bad Request ：请求报文中存在语法错误。
• 401 Unauthorized ：表示发送的请求需要有认证信息（BASIC 认证、DIGEST 认证）。如果之前已进行过一次请求，则表示用户认证失败。
• 403 Forbidden ：请求被拒绝。与401响应不同的是，身份验证并不能提供任何帮助，而且这个请求也不应该被重复提交
• 404 Not Found： 请求失败，请求所希望得到的资源未被在服务器上发现

（5）#5XX 服务器错误，服务器在处理请求时内部发生错误。

• 500 Internal Server Error ：服务器正在执行请求时发生错误。
• 501 服务器不支持当前请求所需要的某个功能。当服务器无法识别请求的方法，并且无法支持其对任何资源的请求。
• 503 Service Unavailable ：服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。

HTTP长连接

数字签名与报文鉴别

数字签名：证明数据或身份的真实性，为什么进行数字签名（的功能）？

• 报文鉴别：接受者可以确认报文发送方的身份，即证明来源。
• 报文完整性：接受者可以确定报文没有被篡改过，防止伪造或篡改。
• 不可否认：发送者事后不能抵赖对报文的签名，防止发送者否认签名。

ps：报文鉴别：鉴别收到的报文确实是期望的发送方发送的，而不是别人伪造的。数字签名可以实现，但缺点是对较长报文进行签名时需要长时间的运算。有一种相对简单的报文鉴别方式，即密码散列函数，要找到两个不同的报文，它们具有相同的密码散列函数输出，在计算上是不可行的。

使用散列函数进行报文鉴别：通信双方共享一个密钥 k ，发送方生成报文 m，用 k 级联 m 生成 m+k，并使用 SHA-1 或 MD5 这样的散列函数计算 m+k 的散列值 h，这个散列值就被称为报文鉴别码 MAC。发送方会利用 MAC 生成扩展报文并发送给接收方。接收方收到后，由于知道共享密钥 k，因此可以计算出 MAC，如果和 h 相等就可以得出一切正常的结论。

数字签名实现方式 : 数字签名算法很多 , 公钥算法 是最简单的算法 , 即 发送者 使用 私钥加密数据 , 接收者 使用 对应的公钥 解密数据 ;

HTTP优化方案？

• TCP复用：TCP连接复用是将多个客户端的HTTP请求复用到一个服务器端TCP连接上，而HTTP复用则是一个客户端的多个HTTP请求通过一个TCP连接进行处理。前者是负载均衡设备的独特功能；而后者是HTTP 1.1协议所支持的新功能，目前被大多数浏览器所支持。
• 内容缓存：将经常用到的内容进行缓存起来，那么客户端就可以直接在内存中获取相应的数据了。
• 压缩：将文本数据进行压缩，减少带宽
• SSL加速（SSL Acceleration）：使用SSL协议对HTTP协议进行加密，在通道内加密并加速
• TCP缓冲：通过采用TCP缓冲技术，可以提高服务器端响应时间和处理效率，减少由于通信链路问题给服务器造成的连接负担。

HTTPS基本知识？

HTTPS是一种应用层协议，本质上来说它是HTTP协议的一种变种。HTTPS比HTTP协议安全，因为HTTP是明文传输，而HTTPS是加密传输，加密过程中使用了三种加密手段，分别是证书，对称加密和非对称加密。HTTPS相比于HTTP多了一层SSL/TSL，其构造如下：

• 证书加密：服务器在使用证书加密之前需要去证书颁发机构申请该服务器的证书，在HTTPS的请求过程服务器端将会把本服务器的证书发送给客户端，客户端进行证书验证，以此来验证服务器的身份（验证交互双方的正确性）。
• 对称加密：HTTPS的请求中，客户端和服务器之间的通信的数据是通过对称加密算法进行加密的。对称加密，即在加密和解密的过程使用同一个私钥进行加密以及解密，而且对称加密算法是公开的，所以该私钥是不能够泄漏的，一旦泄漏，对称加密形同虚设。例如：A第一次加密传输给B是安全的，后边A使用相同的私钥进行加密，就可能存在私钥泄露。适用于大量数据传输，速度快。
• 非对称加密：HTTPS的请求中也使用了非对称加密算法。非对称加密，加密和解密过程使用不同的密钥，一个公钥，对外公开，一个私钥，仅是解密端拥有。由于公钥和私钥是分开的，非对称加密算法安全级别高，加密密文长度有限制，适用于对少量数据进行加密，速度较慢。

HTTPS请求执行的流程

• HTTPS作为一种安全的应用层协议，它使用了以上三种加密手段，我们现在尝试分析其加密的思想。
• 首先，数据正文一般数据量较大，适用于对称加密，因为对称加密速度快，适应于大量数据加密，但是安全级别低，其中对称加密的私钥需要在网络中传输，容易被盗取；
• 其次，正因为非对称机密私钥易被盗取，所以我们需要对这个私钥进行加密，而且安全级别要求高，所以这个可以用非对称加密进行加密，原因是对称加密的私钥数据量小，非对称加密可以提供高安全级别和高响应速度。
• 最后，由于非对称加密的公钥可以在网络中传输，如何保证公钥传送到给正确的一方，这个时候使用了证书来验证。证书不是保证公钥的安全性，而是验证正确的交互方。可以使用下图进行说明：

上述过程就是两次HTTP请求，其详细过程如下：

• 客户端想服务器发起HTTPS的请求，连接到服务器的443端口（在此之前，服务器要去证书颁发机构申请证书）；
• 服务器将非对称加密的公钥传递给客户端，以证书的形式回传到客户端；
• 客户端接受到该公钥进行验证，就是验证2中证书，如果有问题，则HTTPS请求无法继续；如果没有问题，则上述公钥是合格的。（第一次HTTP请求）客户端随机生成client key（客户端私钥），使用前面的公钥对client key进行非对称加密；

---

• 进行二次HTTP请求，将加密之后的client key传递给服务器；
• 服务器使用私钥进行解密（注意私钥是存储在服务器），得到client key，使用client key对数据进行对称加密；
• 将对称加密的数据传递给客户端，客户端使用对称解密得到服务器发送的数据，完成第二次HTTP请求。

拓展：SSL加密过程（大致分三步）

1. 客户端向服务器端索要并验证证书合法性；
2. 双方协商生成“会话密钥”；对称密钥
3. 双方采用“会话密钥”进行加密通信；

浏览器（客户端）如何验证证书的合法性？

1. 验证域名、有效期等信息是否正确：证书上都有包含这些信息，比较容易完成验证；
2. 判断证书来源是否合法：每份签发证书都可以根据验证链查找到对应的根证书，操作系统、浏览器会在本地存储权威机构的根证书，利用本地根证书可以对对应机构签发证书完成来源验证
3. 判断证书是否被篡改：需要与 CA 服务器进行校验；
4. 判断证书是否已吊销：通过CRL（Certificate Revocation List 证书注销列表）和 OCSP（Online Certificate Status Protocol 在线证书状态协议）实现，其中 OCSP 可用于第3步中以减少与 CA 服务器的交互，提高验证效率。

ps: HTTP缺点，与HTTPS的区别？

HTTP的缺点：

• 被窃听：通信使用明文不加密，内容可能被窃听
• 被伪装：不验证通信方身份，可能遭到伪装
• 被篡改：无法验证报文完整性，可能被篡改

两者之间的区别：

• 传输信息的安全性不同：HTTP协议运行在TCP之上，所有传输的内容都是明文；HTTPS运行在SSL/TLS之上的加密传输协议，所有传输的内容都经过加密的。
• 使用端口不同：HTTP默认使用80端口，HTTPS默认使用443端口。
• CA证书：HTTPS请求的过程需要CA证书要验证身份以保证客户端请求到服务器端之后，传回的响应是来自于服务器端，而HTTP则不需要CA证书；
• HTTPS = HTTP + 加密 + 认证 + 完整性保护

Tomcat底层原理（了解）

Tomcat通过监听端口，获取数据，然后解析数据，根据请求url找到对应的Servlet实现类，然后通过反射执行Servlet实现类中的方法。

参考鸣谢：

https://blog.csdn.net/a19881029/article/details/14002273
https://blog.51cto.com/linpeisong/1746151
https://www.jianshu.com/p/a6d086a3997d
https://blog.csdn.net/seujava_er/article/details/90018326