HTTP是应用层的协议，基于请求与响应、无状态的传输协议，基于TCP的连接方式。
主要特点：
（1）支持客户/服务器模式
（2）简单快速
客户端向服务器请求服务时，只需传输请求方法和路径。
请求方法常用的有：GET/HEAD/POST
每种方法规定了客户与服务器联系的类型不同，由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
（3）灵活
HTTP允许传输任意类型的数据对象，正在传输的类型由Content-Type加以标记
（4）无连接
无连接的含义是限制每次连接只处理一个请求，服务器处理完客户的请求，并收到客户的应答之后，即断开连接。
采用这种方式，可以节省传输时间。
从HTTP1.1起，默认使用长连接，即服务器需要等待一定时间后，才断开连接，以保证连接特性。
虽然现在的一些技术，如keep-alive ，使用了长连接，但是都是HTTP请求之外的，
也就是说在每个独立的HTTP请求中，你是无法知道当前的HTTP是否处于长连接的状态，
你始终都要认为HTTP请求在结束后，连接就会关闭。
至于下层实现，是否在结束后关闭连接，都不会改变这个特性，长连接可以理解为下层实现，对上层透明。
（5）无状态
是指协议对事务处理没有记忆能力，缺少状态意味着如果后续处理需要前面的信息，则必须被重传。
这样，可能导致每次连接传送的数据量增大，
另一方面在服务器不需要先前信息时，则服务器的应答较快.
HTTP协议目前正处于多个版本共存的情况，
包括仍被广泛采用的1.0，主流最广泛的1.1，还有应用较少的2.0。
1.1相对于1.0最明显的区别是应用了keep-alive这项长连接技术
2.0更合理，更先进。但是推广不开的原因是1.1完全能够满足目前的应用。
并且升级上2.0的成本太大导致的。
客户端请求消息
客户端发送一个HTTP请求到服务器的请求消息包括以下格式：请求行（request line）、请求头部（header）、空行和请求数据四个部分组成，下图给出了请求报文的一般格式。
请求头部信息提供了如下信息:
Host: 主机名
User-Agent: 浏览器基本资料
Accept: 浏览器能够识别的响应类型
Accept-Language: 浏览器默认语言
Accept-Encoding: 浏览器能够识别的压缩方式
Referer: 来路页面
Connecton：是否保持连接
服务器响应消息
HTTP响应也由四个部分组成，分别是：状态行、消息报头、空行和响应正文。
消息报头中提供如下信息：
Content-Length: 表示长度
Content-Type: 内容格式
Date: 日期
Server: 服务器类型
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
请求/响应的步骤
一、客户端连接到web服务器
一个HTTP客户端通常是浏览器，web服务器的HTTP端口，默认端口号是80，建立一个TCP套接字连接。
二、发送HTTP请求
通过TCP套接字连接客户端向web服务器发送一个文本的请求报文。
三、服务器接收请求并返回HTTP响应
web服务器解析该请求，定位请求资源，服务器将资源副本写到TCP套接字，由客户端读取。
四、释放TCP连接
若连接模式为close，则服务器主动关闭TCP连接，客户端被动关闭连接。释放TCP连接。
若连接模式为keep-alive，则该连接会保持一段时间，在该时间内，可以继续接收请求。
五、客户端浏览器解析HTML内容
客户端浏览器首先解析状态行，查看是否表明成功的状态代码。
解析每一个响应头，响应头告知以下为若干字节的HTML文档和文档的字符集。
客户端浏览器读取响应数据HTML，根据HTML语法，对其进行格式化，并在浏览器窗口显示。
---------------------------------------------------------------------------------------------------------------------------------------
在浏览器地址栏键入URL，按下回车之后经历的流程。
答：
一、DNS解析
首先，浏览器会依据URL逐层查询DNS，服务器缓存，解析URL中的域名所对应的IP地址，
DNS缓存从近到远，依次是浏览器缓存，系统缓存，路由器缓存，IPS服务器缓存，域名服务器缓存，顶级域名服务器缓存。
从哪个缓存找到对应的IP，则直接返回，不再查询后面的缓存。
二、TCP连接
紧接着呢，找了IP地址之后，会根据IP地址和对应端口，默认是80端口，和服务器建立TCP连接（三次握手）。
三、发送HTTP请求
之后浏览器发出读取文件的HTTP请求，该请求将发送给服务器。
四、服务器处理请求并返回HTTP报文
服务器对浏览器请求作出响应，并对应地把带有HTML文本的HTTP响应报文发送给浏览器。
五、浏览器解析渲染页面
浏览器收到HTML，并在显示窗口渲染
六、连接结束
浏览器释放TCP连接（四次挥手）。
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
HTTP状态码
l 200 - 请求成功
l 301 - 资源（网页等）被永久转移到其它URL
l 404 - 请求的资源（网页等）不存在
l 500 - 内部服务器错误
GET请求和POST请求的区别
一、HTTP报文层面：GET将请求信息放在URL,POST放在报文体中
请求信息以URL之间以问号隔开，请求信息的格式为键值对。
POST将请求信息放在报文体中，想获取请求信息必须解析报文，因此安全性相对较高。
事实上，要获取报文体中的请求信息，也是很容易的，因此安全性上两者没有太大的区别。
具体解决传输过程的安全问题，要靠HTTPS
GET的请求正文是没有数据的，GET将请求参数放在URL上，
而POST会将一些参数放在请求正文上。如下图
二、数据库层面
GET符合幂等性和安全性，POST不符合。
幂等性：对数据库的一次操作和多次操作获得的结果是一致的，则认为符合幂等性
安全性：对数据库的操作没有改变数据库中的数据，则认为符合安全性。
GET请求是对数据库进行查询操作，因此不会改变数据库原有的数据，大致地认为是符合安全性。
POST是既不幂等，又不安全的。
POST会往数据库提交数据，因此会改变数据库中的数据。
其次，POST请求每次获得的结果都有可能不一样，因为POST请求是作用在上一级的URL上，则每一次请求都会添加一份新资源。
三、其他层面上
GET可以被缓存、存储，而POST不能。
GET请求被CDN缓存。
POST交由WEB服务器处理。
CDN的全称是Content Delivery Network，即内容分发网络。CDN是构建在现有网络基础之上的智能虚拟网络，依靠部署在各地的边缘服务器，通过中心平台的负载均衡、内容分发、调度等功能模块，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。CDN的关键技术主要有内容存储和分发技术。
GET
“读取“一个资源。比如Get到一个html文件。反复读取不应该对访问的数据有副作用。
比如”GET一下，用户就下单了，返回订单已受理“，这是不可接受的。没有副作用被称为“幂等“（Idempotent)。
因为GET因为是读取，就可以对GET请求的数据做缓存。这个缓存可以做到浏览器本身上（彻底避免浏览器发请求），也可以做到代理上（如nginx），或者做到server端（用Etag，至少可以减少带宽消耗）
POST
在页面里<form> 标签会定义一个表单。点击其中的submit元素会发出一个POST请求让服务器做一件事。
这件事往往是有副作用的，不幂等的。
不幂等也就意味着不能随意多次执行。因此也就不能缓存。比如通过POST下一个单，服务器创建了新的订单，然后返回订单成功的界面。
这个页面不能被缓存。试想一下，如果POST请求被浏览器缓存了，那么下单请求就可以不向服务器发请求，而直接返回本地缓存的“下单成功界面”，却又没有真的在服务器下单。那是一件多么滑稽的事情。
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Cookie和Session的区别
因为HTTP是无状态的，每次访问有登录需求的页面的时候，都要输入账号密码。
采用了某些机制，使用了HTTP变成了有状态。其中就有Cookie和Session
Cookie简介
一、是客户端的解决方案，有服务器发送给客户端的特殊信息 ，以文本的形式存放在客户端。
客户端每次向客户端请求的时候，都会带上这些特殊的信息。
当用户使用浏览器，访问一个支持Cookie的网站之后，会提供包括用户名在内的个人信息，并且提交至服务器。
紧接着， 服务器再向客户端回传相应的超文本的同时，也会发回个人信息，
个人信息并不是存储在HTTP响应体即responsebody中的，而是存放在HTTP响应头，即(response headers)。
当用户端浏览器接收到来自服务器的响应之后，浏览器会将这些信息存放在一个统一的位置
二、客户端再向服务器发送请求的时候，都会把响应的Cookie再次发回至服务器中
而这一次，Cookie信息存放在HTTP请求头里
三、服务器接收到后，会解析Cookie生成与客户端相对应的内容。
服务器接收到来自客户端浏览器的请求之后，就能够通过分析存放于请求头的Cookie得到客户端特有的信息
从而动态生成于该客户端相对应的内容。
通常，我们可以从很多网站的登录界面中， 看到请记住我这样的选项，如果你勾选了它，之后再登录，
那么在下一次访问该网站的时候，就不需要进行重复和繁琐的登录动作了。
这一个功能就是通过Cookie来实现的。
Cookie的设置以及发送过程
一、 客户端发送一个HTTP请求到服务端
二、服务端发送一个HTTP响应到客户端，其中包括了Set-Cookie头部
三、客户端再发送一个HTTP请求到服务端，包括了Cookie头部
四、服务器端发送一个HTTP响应到客户端，
Session简介
一、服务器的机制，在服务器上保存的信息。
服务器使用了类似散列表的结构来保存信息
二、当程序需要为某个客户端的请求创建一个Session的时候，服务器首先检查这个客户端的请求里，
是否包含了一个Session标识，称为Session id，如果已包含一个Session id，则说明以前已为此客户端
创建过Session，服务器就按照Session id 把这个Session检索出来使用。
那如果检索不到呢，就可能会新建一个。如果客户端请求，不包含Session id，则为此客户端创建一个Session，
并创建一个与此Session相关的Session id
Session id是一个既不会重复，又不能易被找到规律以防捏造的字符串，
这个Session id将会在本次响应中，会回发给客户端，进行保存。
Session的实现方式
一、使Cookie来实现
服务器给每个Session分配一个唯一的，JSession id 并通过Cookie发送给客户端，当客户端发起新的请求，将在
Cookie头中，携带这个JSession id，这样服务器能够找到客户端对应的Session
二、使用URL回写来实现
URL会写是指服务器在发送给浏览器页面的所有链接中，都携带JSession id的参数，这样客户端点击任何一个链接
都会把JSession id带回服务器。如果直接在浏览器输入服务端资源的URL来请求该资源呢么session，是匹配不到的。
Tomcat对Session的实现，是一开始同时使用Cookie和URL回写机制，如果发现客户端支持Cookie，就继续使用Cookie
停止使用URL回写，如果发现Cookie被禁用，就一直使用URL回写。
Cookie和Session的区别
一、Cookie数据存放在客户的浏览器上，Session数据存放在服务器上
二、Session相对应Cookie安全
可以分析存放在本地的Cookie，并进行Cookie欺骗
三、若考虑减轻服务器负担，应当使用Cookie
Session会一段时间存放在服务器上，当访问增多，会比较占用服务器的性能。
欢迎大家关注我的微信公众号，获取你不知道的宝藏。
