HTTP，即超文本传输协议，属于应用层的协议，它是一个基于请求与响应模式的无状态的应用层的协议，常基于TCP的连接方式，HTTP1.1版本中，给出了一种持续的连接机制-keep-alive，绝大多数的web开发都是构建在HTTP协议之上的web应用。
HTTP协议的主要特点可以概括如下：
（1）支持客户/服务器模式。
HTTP协议工作于客户端/服务端架构之上，浏览器作为HTTP客户端，通过url向HTTP服务端，即web服务器发送所有请求，web服务器根据接收到的请求，向客户端发送响应信息。
（2）简单快速
客户端向服务器请求服务的时候，只需传送请求方法和路径。请求方法常用的有GET，HEAD，POST，每种方法规定客户端与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
（3）灵活
HTTP允许传输任意类型的数据对象。正在传输的类型由content-type加以标记。
（4）无连接
无连接的含义是限制每次连接只处理一个请求，服务器处理完客户端的请求，并收到客户的应答之后，即断开连接，采用这种方式可以节省传输时间，从HTTP1.1起，默认使用长连接，即服务器需要等待一定时间才断开连接，以保证连接特性。虽然目前的一些技术，如keep alive，使用的长连接优化效率，但这些都是属于HTTP请求之外的，也就是说，在每个独立的HTTP请求中，你是无法知道当前的HTTP是否处于长连接的状态，你始终都要认为HTTP请求在结束后，连接就会关闭，这是HTTP的特性，至于下层实现是否在结束请求后关闭连接，都不会改变这个特性。长连接可以理解为下层实现对上层透明。
（5）无状态
HTTP协议是无状态协议，无状态是指协议对于事务处理没有记忆能力，缺少状态意味着，如果后续处理需要前面的信息，则必须被重传，这样可能导致每次连接传送的数据量增大，另一方面，在服务器不需要先前的信息时，它的应答就较快。
HTTP协议目前正处于多个版本共存的情况，包括仍被广泛采用的1.0，主流最为广泛的1.1，还有应用最少，牛逼吹的最大的2.0。1.1相较1.0，最明显的区别是引入了keep alive这项长连接技术。2.0虽然更合理，更先进，但其推广不开来是由于1.1完全能够满足目前的应用，并且升级到2.0的成本太大导致的。
HTTP请求结构
通过wireshark抓包得到如下信息：
HTTP响应结构
然后wireshark抓包得到如下信息
请求/响应的步骤：
（1）客户端连接到web服务器。
一个HTTP客户端，通常是浏览器与web服务器的HTTP端口（默认端口号是80）建立一个TCP套接字连接。
（2）发送HTTP请求。
即通过TCP套接字，客户端向web服务器发送一个文本的请求报文。
（3）服务器接受请求并返回HTTP响应。
web服务器解析该请求，定位请求资源，服务器将资源副本写入TCP套接字，由客户端读取。
（4）释放TCP连接
若我们的连接模式为close，则服务器主动关闭TCP连接，客户端被动关闭连接，释放TCP连接。若我们的连接模式为keep alive，则该连接会保持一段时间，在该时间内可以继续接收请求。
（5）客户端浏览器解析HTML内容
客户端浏览器首先去解析状态行，查看表明请求是否成功的状态代码，然后解析每一个响应头，响应头告知以下为若干字节的HTML文档和文档的字符集，客户端浏览器读取响应数据HTML，根据HTML的语法，对其进行格式化，并在浏览器窗口进行显示。
在浏览器地址键入URL，按下回车之后经历的流程：
（1）DNS解析
首先浏览器会依据URL逐层查询DNS服务器缓存，解析URL中的域名对应的IP地址，DNS缓存从近到远依次是浏览器缓存，系统缓存，路由器缓存，IPS服务器缓存，根域名服务器缓存，顶级域名服务器缓存，从哪个缓存找到对应的IP，则直接返回，不再查询后面的缓存。
（2）TCP连接
找到IP地址之后，会根据IP地址及对应端口（默认80端口）和服务器建立TCP连接（三次握手）。
（3）发送HTTP请求
接着浏览器会发出读取文件的HTTP请求，该请求将发送给服务器。
（4）服务器处理请求并返回HTTP报文
服务器对浏览器请求做出响应，并把对应的带有HTML文本的HTTP响应报文发送给浏览器。
（5）浏览器解析渲染页面
之后，浏览器收到HTML，并在显示窗口去渲染它。
（6）连接结束
最后浏览器释放TCP连接（四次挥手）
HTTP状态码
五种可能的取值
（1）1xx：指示信息------表示请求已接收，继续处理
（2）2xx：成功-----------表示请求已被成功接收，理解，接收
（3）3xx：重定向---------要完成请求必须进行更进一步的操作
（4）4xx：客户端错误----请求有语法错误或请求无法实现
（5）5xx：服务器端错误–服务器未能实现合法的请求
GET请求和POST请求的区别：
从三个层面来解答
（1）HTTP报文层面：GET将请求信息放在URL，POST放在报文体中。
GET将请求信息放在URL后面，请求信息与URL以问号隔开，请求信息的格式为键值对。而POST请求方式将请求信息放在报文体中，想获得请求信息，必须解析报文，因此安全方式较GET方式要更高一些。事实上要获得报文体中的请求信息也是很容易的，因此安全性上两者并没有太大的区别。具体解决传输过程中的安全问题，还要靠HTTPS。
（2）数据库层面：GET符合幂等性和安全性，POST不符合。
幂等性就是对数据库的一次操作和多次操作的结果是一样的，安全性就是对数据库的操作没有改变数据库中的数据。GET请求做查询操作，因此不会改变数据库中原有的数据，大致可以认为是符合安全性和幂等性的。而POST请求是既不幂等又不安全的，首先POST请求会往数据库中提交数据，因此会改变数据库中的数据，其次，POST请求方式每次获得的结果都有可能不一样，因为POST请求是作用在上一级URL上的，则每一次请求都会添加一份新资源。
（3）其他层面：GET可以被缓存，被存储，而POST不行。
GET请求会被保存在浏览器的浏览记录中，因为GET请求的url能够保存为浏览器书签，而POST方式不具备上述功能。缓存也是GET请求被广泛应用的根本。
在现代网络上，每天产生的请求数目是巨大的，其中绝大部分请求为只读请求，如果所有这些请求都要交由web服务器直接处理，这无疑是巨大的资源浪费，从第二部分知道，GET表达的是一种幂等的安全的，因此绝大部分GET请求（通常超过90%）都直接被CDN缓存了，这能大大减少web服务器的负担，而post是非幂等的，有副作用的操作，所以必须交由web服务器处理。
Cookie和Session的区别：
因为HTTP是无状态的，也就意味着，我们每次访问某个有登录需求的页面的时候，都要不厌其烦地输入账号密码，现实生活中并没有出现这样的情况，这是因为咱们引入了某些机制，让HTTP具备了状态，其中的两个便是Cookie和Session。
Cookie简介
Cookie技术是客户端的解决方案。
（1）是由服务器发送给客户端的特殊信息，以文本的形式存放在客户端。
然后客户端每次向服务器发送请求的时候，都会带上这些特殊的信息。
具体点讲，当用户使用浏览器访问一个支持Cookie的网站的时候，用户会提供包括用户名在内的个人信息，并且提交至服务器，紧接着服务器在向客户端回传相应的超文本的同时，也会发回这些个人信息，当然这些信息并不是存放在HTTP响应体中，而是存放在HTTP响应头中，当用户端浏览器接收到来自服务器的响应之后，浏览器会将这些信息存放在一个统一的位置。
（2）客户端再次请求的时候，会把Cookie回发。
至此，客户端再向服务器发送请求的时候，都会把相应的cookie再次发回到服务器中，而这次cookie信息则存放在HTTP请求头里面了。
（3）服务器接收到后，会解析cookie生成与客户端相对应的内容。
有了cookie这样的技术实现，服务器在接收到来自客户端浏览器的请求之后，就能够通过分析存放于请求头的cookie，得到客户端特有的信息，从而动态生成与该客户端相对应得内容，通常我们可以从很多网站得登录界面看到“请记住我”这样得选项，如果你勾选了它，之后再登录，那么再下一次访问该网站得时候，就不用进行重复繁琐得登录动作了。
Cookie的设置以及发送过程：
Session简介
（1）服务器端的机制，在服务器上保存的信息。
Session机制是一种服务器端的机制，服务器使用了一种类似于散列表的结构来保存信息。
（2）解析客户端请求并操作session id，按需保存状态信息。
当程序需要为某个客户端的请求创建一个session的时候，服务器首先检查这个客户端的请求里是否已包含了一个session标志，称为session id，如果已包含session id，则说明，以前已经为此客户端创建过session，服务器就按照session id，把这个session检索出来使用，如果检索不到，就可能会新建一个。如果客户端请求不包含session id，则为此客户端创建一个session，并生成一个与此session相关的session id。session id的值应该是一个既不会重复，又不容易被找到规律的以防捏造的字符串，这个session id将会在本次响应中会回发给客户端进行保存。
Session的实现方式有两种
（1）使用cookie来实现
服务器给每个session分配一个JSESSIONID，并通过cookie发送给客户端，当客户端发起新的请求的时候，将在cookie头中携带这个JSESSIONID，这样服务器能够找到客户端对应的session。
（2）使用URL回写来实现
URL回写是指服务器在发送给浏览器页面的所有链接中，都携带JSESSIONID的参数，这样客户端点击任何一个链接，都会把JSESSIONID带回服务器。如果直接在浏览器输入服务端资源的URL来请求该资源，那么session是匹配不到的，tomcat对session的实现是一开始同时使用cookie和url回写机制，如果发现客户端支持cookie，就继续使用cookie，停止使用URL回写，如果发现cookie被禁用，就一直使用url回写。
不管是使用session还是url回写，它们都和一个叫JSESSIONID的参数息息相关，这个JSESSIONID就维护了服务器跟客户端请求和响应之间的映射关系。
Cookie和Session的区别是什么？
（1）Cookie数据存放在客户的浏览器上，Session数据存放在服务器上，
（2）Session相对于Cookie更安全。
（3）若考虑减轻服务器负担，应当使用Cookie。session会在一定时间内保存在服务器上，当访问增多，会比较占用服务器的性能，考虑到减轻服务器性能方面的开销，应当使用cookie。