HTTP是一种无状态（stateless）协定。协定本身不对申请和响应之间的通信状态进行保留。每当有新的申请发送时，就会有对应的新的响应产生。协定自身并不保留之前所有的申请或响应报文信息。
起因：为了更快的解决大量事物，确保协定的可伸缩性，而特意将HTTP协定设计成如此简略。
长处：因为不保留状态，天然能够缩小服务器的CPU以及内存资源的耗费。
然而有时候须要保留状态，比方用户的登录状态，这时候引入cookie技术，就能够治理状态了。
申请报文
申请报文由报文首部（申请办法、申请URI、协定版本、可选的申请首部字段）和报文主体（内容实体）形成，两者由空行宰割，报文的主体内容个别为空。
响应报文
响应报文基本上是由报文首部（协定版本、状态码（status code）、用以解释状态码的起因短语、可选的响应首部字段）以及报文主体（实体主体）形成，二者空格隔开。
HTTP办法
GET办法：获取资源
用来申请拜访已被URI辨认的资源。指定的资源经服务器端解析后返回响应内容。如果申请的是文本，则放弃原样返回；如果是CGI（Common Gateway Interface，通用网关接口）那样的程序，则返回通过执行后的输入后果。
POST办法：传输实体主体
PUT办法：传输文件
PUT办法用来出传输文件，要求申请报文的主体中蕴含文件内容，而后保留到申请URI指定的地位。
然而，鉴于HTTP/1.1的PUT办法本身不带验证机制，任何人都能够上传文件，存在安全性问题，因而个别的web网站不应用此办法。若配合web应用程序的验证机制，或架构设计采纳REST(REpresentational State Transfer, 表征状态转移)规范的同类web网站，就可能会凋谢应用PUT办法。
这个响应的意思是申请执行胜利了，但无数据返回。
HEAD办法：取得报文首部
HEAD办法和GET办法一样，只是不返回报文主体局部。用于确认URI的有效性及资源更新的日期工夫等。
DELETE办法：删除文件
DELETE办法是与PUT重复相同的办法。按申请URI删除指定的资源。然而HTTP/1.1的DELETE自身也不带验证机制，所以个别也不实用。当配合web应用程序的验证机制或恪守REST规范时还是有可能凋谢应用的。
OPTIONS办法：询问反对的办法
用来查问针对申请URI指定的资源反对的办法。
TRACE办法：追踪门路
TRACE办法是让web服务器将之前的申请通信环回客户端的办法。
发送申请时，在Max-Forwards首部字段填入数值，每通过一个服务器端就将该数字减1，当数值刚好为0时，就进行持续传输，最初接管到申请的服务器端则返回状态码200 OK的响应。
客户端通过TRACE办法能够查问收回去的申请时怎么样被加工/篡改的。这是因为，申请想要连贯到源指标服务器可能会通过代理直达，TRACE办法就是用来确认连贯过程中产生的一系列操作。自身不罕用，再加上容易引发XST（Cross-Site Tracing，跨站攻打）攻打，就更不会用到了。
CONNECT办法：要求用隧道协定连贯代理
CONNECT办法要求在与代理服务器通信时建设隧道，实现用隧道协定进行TCP通信。次要应用SSL（Secure Sockets Layer，安全套接层）和TLS（Transport Layer Security， 传输层平安）协定把通信内容加密后经网络隧道传输。
格局：
CONNECT 代理服务器名：端口号 HTTP版本
长久连贯节俭通信
HTTP协定初始版本中，每进行一次HTTP通信就要端口一次TCP连贯。以前都是容量很小的文本传输，所以没什么问题。当初一个网页中有大量图片，每次申请会造成无畏的TCP连贯建设和断开，减少通信的开销。
为解决这个问题，HTTP/1.1和一部分HTTP/1.0想出了长久连贯（HTTP Persistent Connections， 也称为HTTP keep-alive 或HTTP connection reuse）的办法。特点是，只有任意一端没有明确提出断开连接，则放弃TCP连贯状态。
益处：缩小了TCP连贯和断开造成的额定开销，加重了服务器端的负载。另外，缩小开销的那局部工夫，使HTTP申请和响应可能更早地完结，这样web页面的显示速度也就相应进步了。
管线化
前提是须要长久连贯。从前发送申请后须要期待并收到响应能力发送下一个申请，管线化技术呈现后，不必期待响应亦可间接发送下一个申请。并行发送多个申请。管线化技术比长久连贯还要快，申请数越多，时间差越显著。
应用Cookie的状态治理
Cookie会依据从服务器端发送的响应报文内的一个叫做Set-Cookie的首部字段信息，告诉客户端保留cookie。当下次客户端再往服务器端发送申请时，客户端会主动在申请报文中退出cookie值后发送进来。
服务器端发现客户端发送过去的cookie之后，会去查看到底是从哪个客户端发送过去的申请，而后比照服务器上的记录，最初失去之前的状态信息。