共计 2030 个字符，预计需要花费 6 分钟才能阅读完成。
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 之后，会去查看到底是从哪个客户端发送过去的申请，而后比照服务器上的记录，最初失去之前的状态信息。
