HTTP简介

HTTP协议是Hyper Text Transfer Protocol（超文本传输协议）的缩写,是用于从万维网（WWW:World Wide Web ）服务器传输超文本到本地浏览器的传送协议。

HTTP协议定义Web客户端如何从Web服务器请求Web页面，以及服务器如何把Web页面传送给客户端。HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求报文，请求报文包含请求的方法、URL、协议版本、请求头部和请求数据。服务器以一个状态行作为响应，响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据。

HTTP协议工作于客户端-服务端架构为上。浏览器作为HTTP客户端通过URL向HTTP服务端即WEB服务器发送所有请求。Web服务器根据接收到的请求后，向客户端发送响应信息。

一次 HTTP 请求的通信流程

我们先来思考一个问题，我们在浏览器上输入一个网址后，浏览器是如何展示目标网址的内容的？内容是从哪里来的呢？通过图形把这个过程画一下

DNS:（Domain Name System）服务是和 HTTP 协议一样位于应用层的协议。它提供域名到 IP 地址之间的解析服务, 用户通常使用主机名或域名来访问对方的计算机，而不是直接通过 IP 地址访问。因为与 IP 地址的一组纯数字相比，用字母配合数字的表示形式来指定计算机名更符合人类的记忆习惯，但要让计算机去理解名称，相对而言就变得困难了。因为计算机更擅长处理一长串数字。为了解决上述的问题，DNS 服务应运而生。DNS 协议提供通过域名查找 IP 地址，或逆向从IP 地址反查域名的服务

HTTP 通信协议的组成

刚刚我们已经得知了 HTTP 协议的工作过程，同时我们也应该知道 HTTP 协议是基于应用层的协议，并且在传输层使用的 TCP 的可靠性通信协议。既然是协议，那么就应该符合协议的定义：协议是两个需要通过网络通信的程序达成的一种约定，它规定了报文的交换方式和包含的意义，所以，接下来我们来深入去剖析 HTTP 协议的原理和组成

请求 I URI 定位资源

我们在浏览器中输入一个地址，浏览器是如何根据地址去找到服务器对应的资源并做返回的？以及这个地址包含了哪些有价值的信息呢？这就需要我们了解 URL (Uniform Resource Locator)，统一资源定位符 ，用于描述一个网络上的资源，具体格式是

（Uniform Resource Identifiers, URI） 统一资源标识符，URL：全称是UniformResourceLocator, 中文叫统一资源定位符,是互联网上用来标识某一处资源的地址。

? URI 用字符串标识某一互联网资源，而 URL 表示资源的地点（互联网上所处的位置）。可见 URL 是 URI 的子集。

以下面这个URL为例，介绍下普通URL的各部分组成：

http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name->scheme://host:port/path/?query-string=xxxx#anchor

scheme:代表的是访问的协议,一般为http 或者https 以及ftp 等

host: 主机名,域名 比如www.baidu.com

port: 端口名.当你访问一个网站的时候,浏览器默认使用http使用80 端口 https 443 端口

paht: 查找路径 比如www.jianshu.com/trending/now,后面的trending/now就是path

query-string:查询字符串,比如:www.baidu,com/s?wd=Python,后面的wd=python 就是查询字符串

anchor:锚点,后台一般不用管,前端来做页面定位的

注意: url 中的所有字符串都是ASCII字符集,如果出现非ASCII字符,比如中文,浏览器会进行编码进行传输

MIME Type

服务器根据用户请求的资源找到对应的文件以后，会返回一个资源给到客户端浏览器，浏览器会对这个资源解析并且渲染。但是服务器上的资源类型有很多，比如图片类型、视频类型、Js、Css、文本等。浏览器如何识别当前类型做不同的渲染呢？

MIME Type：是描述消息内容类型的因特网标准，常见的几种类型

文本文件：text/html,text/plain,text/css,application/xhtml+xml,application/xml

图片文件：image/jpeg,image/gif,image/png.

视频文件：video/mpeg,video/quicktime

我们可以通过两种方式来设置文件的渲染类型，第一种是 Accept，第二种是 Content-Type ,Accept: 表示客户端希望接受的数据类型，即告诉服务器我需要什么媒体类型的数据，此时服务器应该根据 Accept 请求头生产指定媒体类型的数据Content-Type: 表 示 发 送 端 发 送 的 实 体 数 据 类 型 ， 比 如 我 们 应 该 写 过 类 似 的 ：resposne.setContentType(“application/json;charset=utf-8”)的代码，表示服务端返回的数据格式是 json。如果 Accept 和 Content-Type 不一致，假如说 Accept 要接收的类型是 image/gif，但是服务端返回的数据是 text/html，那么浏览器将会无法解析。

状态码

状态码的职责是当客户端向服务端发送请求时，描述服务端返回的请求处理结果，通过状态码，浏览器可以知道服务器是正常处理请求还是出现了错误

大家见得比较多的错误码：

200：一切正常

301：永久重定向

404：请求资源不存在

500：服务端内部错误

有了状态码，在用户访问某个网站出现非正常状态时，浏览器就可以很友好的提示用户

告诉服务器端当前请求的意图

有了 url，mimetype、状态码， 能够基本满足用户的需求，但是，很多时候一个网站不单纯只是不断从服务端获取资源并做渲染，可能还需要做一些数据的提交、删除等功能。所以浏览器定义了 8 种方法来表示对于不同请求的操作方式。

GET：一般是用于客户端发送一个 URI 地址去获取服务端的资源（一般用于查询操作），Get不支持的传输数据有限制，具体限制由浏览器决定

POST：一般用户客户端传输一个实体给到服务端，让服务端去保存（一般用于创建操作）

PUT：向服务器发送数据，一般用于更新数据的操作

DELETE：客户端发起一个 Delete 请求要求服务端把某个数据删除（一般用于删除操作）

HEAD:获得报文首部

OPTIONS：询问支持的方法

TRACE：追踪路径

CONNECT：用隧道协议连接代理

http 协议的完整组成

请求报文

请求报文格式包含三个部分，（起始行、首部字段、主体）

响应报文

响应的报文格式也是一样，分为三部分

每次请求都要建立连接吗？

在最早的 http 协议中，每进行一次 http 通信，就需要做一次 tcp 的连接。而一次连接需要进行 3 次握手，这种通信方式会增加通信量的开销。

所以在 HTTP/1.1 中改用了持久连接，就是在一次连接建立之后，只要客户端或者服务端没有明确提出断开连接，那么这个 tcp 连接会一直保持连接状态,持久连接的一个最大的好处是：大大减少了连接的建立以及关闭时延。

HTTP1.1 中有一个 Transport 段。会携带一个 Connection:Keep-Alive，表示希望将此条连接作为持久连接。HTTP/1.1 持久连接在默认情况下是激活的，除非特别指明，否则 HTTP/1.1 假定所有的连接都是持久的，要在事务处理结束之后将连接关闭，HTTP/1.1 应用程序必须向报文中显示地添加一个 Connection：close 首部。HTTP1.1 客户端加载在收到响应后，除非响应中包含了 Connection：close 首部，不然 HTTP/1.1连接就仍然维持在打开状态。但是，客户端和服务器仍然可以随时关闭空闲的连接。不发送Connection：close 并不意味这服务器承诺永远将连接保持在打开状态。

管道化连接: http/1.1 允许在持久连接上使用请求管道。在http/1.1之前发送请求后需等待并收到响应，才能发送下一个请求。管道化技术出现后，不用等待响应亦可直接发送下一个请求。这样就能够做到同时并行发送多个请求，而不需要一个接一个地等待响应了。

Http 协议的特点

HTTP 协议是无状态的，什么是无状态呢？就是说 HTTP 协议本身不会对请求和响应之间的通信状态做保存。但是现在的应用都是有状态的，如果是无状态，那这些应用基本没人用，你想想，访问一个

电商网站，先登录，然后去选购商品，当点击一个商品加入购物车以后又提示你登录。这种用户体验根本不会有人去使用。那我们是如何实现带状态的协议呢？

客户端支持的 cookie

Http 协议中引入了 cookie 技术，用来解决 http 协议无状态的问题。通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态；Cookie 会根据从服务器端发送的响应报文内的一个叫做 Set-Cookie 的首部字段信息，通知客户端保存 Cookie。当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入 Cookie 值后发送出去。

服务端支持的 session

服务端是通过什么方式来保存状态的呢？ 在基于 tomcat 这类的 jsp/servlet 容器中，会提供session 这样的机制来保存服务端的对象状态，服务器使用一种类似于散列表的结构来保存信息，当程序需要为某个客户端的请求创建一个 session 的时候，服务器首先检查这个客户端的请求是否包含了一个 session 标识- session id；如果已包含一个 session id 则说明以前已经为客户端创建过 session，服务器就按照 session-id 把这个 session 检索出来使用（如果检索不到，会新建一个）；如果客户端请求不包含 sessionid，则为此客户端创建一个 session 并且生成一个与此 session相关联的 session id，session id 的值是一个既不会重复，又不容易被找到规律的仿造字符串，这个 session id 将会返回给客户端保存。

Tomcat 实现 session 的代码逻辑分析

我们以 HttpServletRequest#getSession() 作为切入点，对 Session 的创建过程进行分析我 们 的 应 用 程 序 拿 到 的 HttpServletRequest 是org.apache.catalina.connector.RequestFacade(除非某些 Filter 进行了特殊处理)，它是org.apache.catalina.connector.Request 的门面模式。首先，会判断 Request 对象中是否存在 Session，如果存在并且未失效则直接返回 ，如果不存在 Session，则尝试根据 requestedSessionId 查找 Session，如果存在 Session 的话则直接返回，如果不存在的话，则创建新的 Session，并且把 sessionId 添加到 Cookie 中，后续的请求便会携带该 Cookie，这样便可以根据 Cookie 中的 sessionId 找到原来创建的Session 了。