HTTP协议（HyperText Transfer Protocol，超文本传输协议）是用于从WWW服务器传输超文本到本地浏览器的传输协议。
它可以使浏览器更加高效，使网络传输减少。它不仅保证计算机正确快速地传输超文本文档，还确定传输文档中的哪一部分，以及哪部分内容首先显示(如文本先于图形)等。
HTTP协议功能
HTTP是客户端浏览器或其他程序与Web服务器之间的应用层通信协议。在Internet上的Web服务器上存放的都是超文本信息，客户机需要通过HTTP协议传输所要访问的超文本信息
HTTP包含命令和传输信息，不仅可用于Web访问，也可以用于其他因特网/内联网应用系统之间的通信，从而实现各类应用资源超媒体访问的集成。
我们在浏览器的地址栏里输入的网站地址叫做URL (Uniform Resource Locator，统一资源定位符)。就像每家每户都有一个门牌地址一样，每个网页也都有一个Internet地址。
当你在浏览器的地址框中输入一个URL或是单击一个超级链接时，URL就确定了要浏览的地址。浏览器通过超文本传输协议(HTTP)，将Web服务器上站点的网页代码提取出来，并翻译成漂亮的网页。
Request For Comments (RFC），是一系列以编号排定的文件。文件收集了有关因特网相关资讯，以及UNIX和因特网社群的软件文件。目前RFC文件是由Internet Society（ISOC）所赞助发行。
基本的因特网通讯协定都有在RFC文件内详细说明。RFC文件还在标准内额外加入了许多的论题，例如对于因特网新开发的协定及发展中所有的记录。因此几乎所有的因特网标准都收录在RFC文件之中
下面是一些重要的RFC文档：
1 ) 赋值RFC（Assigned Numbers RFC）列出了所有Internet协议中使用的数字和常数。至
本书出版时为止，最新 RFC的编号是 1340 [Reynolds 和Postel 1992] 。所有著名的
Internet端口号都列在这里。
当这个RFC被更新时(通常每年至少更新一次），索引清单会列出RFC 1340被替换的时间。
2) Internet正式协议标准，目前是RFC 1600[Postel 1994]。这个RFC描述了各种Internet协
议的标准化现状。每种协议都处于下面几种标准化状态之一：标准、草案标准、提议
标准、实验标准、信息标准和历史标准。另外，对每种协议都有一个要求的层次、必
需的、建议的、可选择的、限制使用的或者不推荐的。
与赋值RFC一样，这个RFC也定期更新。请随时查看最新版本。
3 ) 主机需求RFC，1122和1123[Braden 1989a, 1989b]。RFC 11 2 2针对链路层、网络层和运
输层；RFC 1123针对应用层。这两个RFC对早期重要的RFC文档作了大量的纠正和解
释。如果要查看有关协议更详细的细节内容，它们通常是一个入口点。它们列出了协
议中关于“必须”、“应该”、“可以”、“不应该”或者“不能”等特性及其实现细节。
文献[Borman 1993b]提供了有关这两个RFC的实用内容。RFC 1127[Braden 1989c]对工
作小组开发主机需求RFC过程中的讨论内容和结论进行了非正式的总结。
4) 路由器需求RFC，目前正式版是RFC 1009[Braden and Postel 1987]，但一个新版已接近
完成[Almquist 1993]。它与主机需求RFC类似，但是只单独描述了路由器的需求
HTTP协议描述的是发送方与接收方的通信协议，通过两方的自觉遵守而存在，当然有不少的浏览器并没有百分百遵守这份协议。HTTP是运行于应用层的协议，基于TCP协议而运作。基本上是客户/服务器对答模式，其中也包括在传输过程中的代理，网关，通道，缓存等都需要遵守这份协议。
阅读完RFC之后，较为难以理解的部分是关于连接机制与缓存机制，其他都基本上是字段与头部格式的定义
HTTP所表达的控制以及描述性相关的信息都包含在了HTTP的起始行和首部之中。BNF的使用使得自己能够清晰的梳理出起始行和首部中所有类别的元信息。对于每一类的元信息具体包含哪些内容也能够有所了解。这一抽象的方法不仅HTTP协议定义的时候比较严谨之外，在实现HTTP解析器（浏览器）的时候参照BNF写代码是非常容易实现的。这也提醒了我们在编写相关的系统设计方案的时候是可以借鉴类似的方法的。毕竟使用文字表述的设计方案存在这问题遗漏，表述不够清晰，不同人理解有所差异等方面的问题。（我们会看到在FTP之中也有类似的方法，状态图）。HTTP被设计成为一种非常容易扩展的协议，因此协议时松散的。头域可以加入需要的头部名和指定的值，尽管有的头部没有加入RFC标准，但是可能成为约定成俗的标准(虽然这会给HTTP的安全性带来了挑战)，由此可以看出良好的设计方案在一开始的时候就考虑到其以扩展性，这也是HTTP能够长期存在，不断发展的原因
HTTP所表达的控制以及描述性相关的信息都包含在了HTTP的起始行和首部之中。BNF的使用使得自己能够清晰的梳理出起始行和首部中所有类别的元信息。对于每一类的元信息具体包含哪些内容也能够有所了解。这一抽象的方法不仅HTTP协议定义的时候比较严谨之外，在实现HTTP解析器（浏览器）的时候参照BNF写代码是非常容易实现的。这也提醒了我们在编写相关的系统设计方案的时候是可以借鉴类似的方法的。毕竟使用文字表述的设计方案存在这问题遗漏，表述不够清晰，不同人理解有所差异等方面的问题。（我们会看到在FTP之中也有类似的方法，状态图）。HTTP被设计成为一种非常容易扩展的协议，因此协议时松散的。头域可以加入需要的头部名和指定的值，尽管有的头部没有加入RFC标准，但是可能成为约定成俗的标准(虽然这会给HTTP的安全性带来了挑战)，由此可以看出良好的设计方案在一开始的时候就考虑到其以扩展性，这也是HTTP能够长期存在，不断发展的原因
HTTP概述
超文本传输协议-HTTP(HTTP，HyperText Transfer Protocol)是因特网上应用最为广泛的一种网络协议。所有的WWW文件都必须遵守这个标准。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。
HTTP的发展是万维网协会（World Wide Web Consortium）和Internet工作小组（Internet Engineering Task Force）合作的结果，（他们）最终发布了一系列的RFC，其中最著名的就是RFC 2616。RFC 2616定义了HTTP协议的我们今天普遍使用的一个版本——HTTP 1.1。
HTTP是一个客户端和服务器端请求和应答的标准（TCP）。客户端是终端用户，服务器端是网站。通过使用Web浏览器、网络爬虫或者其它的工具，客户端发起一个到服务器上指定端口（默认端口为80）的HTTP请求。（我们称这个客户端）叫用户代理（user agent）。应答的服务器上存储着（一些）资源，比如HTML文件和图像。（我们称）这个应答服务器为源服务器（origin server）。在用户代理和源服务器中间可能存在多个中间层，比如代理，网关，或者隧道（tunnels）。尽管TCP/IP协议是互联网上最流行的应用，HTTP协议并没有规定必须使用它和（基于）它支持的层。 事实上，HTTP可以在任何其他互联网协议上，或者在其他网络上实现。HTTP只假定（其下层协议提供）可靠的传输，任何能够提供这种保证的协议都可以被其使用。
通常，由HTTP客户端发起一个请求，建立一个到服务器指定端口（默认是80端口）的TCP连接。HTTP服务器则在那个端口监听客户端发送过来的请求。一旦收到请求，服务器（向客户端）发回一个状态行，比如"HTTP/1.1 200 OK"，和（响应的）消息，消息的消息体可能是请求的文件、错误消息、或者其它一些信息。
HTTP使用TCP而不是UDP的原因在于（打开一个）一个网页必须传送很多数据，而TCP协议提供传输控制，按顺序组织数据，和错误纠正。具体细节请参考‘TCP和UDP的不同’通过HTTP或者HTTPS协议请求的资源由统一资源定位器（Uniform Resource Identifiers）（或者，更准确一些，URLs）来标识。
HTTP请求信息（Request Message）
发出的请求信息包括以下几个 ：
HTTP请求行，例如GET /images/logo.gif HTTP/1.1，表示从/images 目录下请求logo.gif 这个文件。
（请求）头，例如Accept-Language: en
空行
可选的消息体
请求行和标题必须以<CR><LF> 作为结尾（也就是，回车然后换行）。空行内必须只有<CR><LF>而无其他空格。在HTTP/1.1 协议中，所有的请求头，除Host外，都是可选的。
HTTP请求方法（Request Methods）
HTTP协议中定义了八种方法（有时也叫“动作”）来表示对指定数据的操作。
HEAD
（Head方法）要求响应与相应的GET请求的响应一样，但是没有的响应体（response body）。这用来获得响应头（response header）中的
元数据信息（meta-infomation）有（很）帮助，（因为）它不需要传输所有的内容。
GET
（Get方法用来）请求指定的资源。它是目前网上最常用的方法。它不应该用于一些会造成副作用的操作中
（在网络应用中用它来提交动作是一种常见的错误用法）。（细节请）参考后面的“安全方法”（这一节）。
POST
（POST方法用来）向指定的资源提交需要处理的数据。这些数据写在请求的内容里。（POST请求）可以导致新资源的产生和已有资源的更新。
PUT
上传指定资源
DELETE
删除指定资源
TRACE
（Trace方法告诉服务器端）返回收到的请求。客户端可以（通过此方法）察看在请求过程中中间服务器添加或者改变哪些内容。
OPTIONS
返回服务器（在指定URL上）支持的HTTP方法。通过请求“*”而不是指定的资源，这个方法可以用来检查网络服务器的功能。
CONNECT
将请求的连接转换成透明的TCP/IP通道，通常用来简化通过非加密的HTTP代理的SSL-加密通讯（HTTPS）。
HTTP服务器至少应该实现Get和Head方法，可能的话，也实现OPTIONS方法。
HTTP安全方法
有些方法（比如HEAD, GET, OPTIONS, and TRACE) 被定义为安全方法，这些方法针对的只是信息的返回，并不会改变服务器的状态（换句话说就是这些方法不会产生副作用）。不安全的方法（例如POST, PUT and DELETE) 应该用特殊的方式向用户展示，通常是按钮而不是链接，这样就可以使用户意识到可能要负的责任（例如一个按钮带来的资金交易。）
HTTP协议版本号
超文本传输协议已经演化出了很多版本，它们中的大部分都是向下兼容的。客户端在请求的开始告诉服务器它采用的协议版本号，而后者则在响应中采用相同或者更早的协议版本。
HTTP/0.9
已过时。只接受 GET 一种请求方法，没有在通讯中指定版本号，且不支持请求头。由于该版本不支持 POST 方法，所以客户端无法向服务器传递太多信息。
HTTP/1.0
这是第一个在通讯中指定版本号的 HTTP 协议版本，至今仍被广泛采用，特别是在代理服务器中。
HTTP/1.1
当前版本。持久连接被默认采用，并能很好地配合代理服务器工作。还支持以管道方式在同时发送多个请求，以便降低线路负载，提高传输速度。
此版相较于 HTTP/1.0 协议的区别主要体现在：
HTTP缓存处理
带宽及网络连接的管理
安全性及完整性
HTTP状态行
参见：HTTP状态码
所有 HTTP 响应的第一行都是状态行, 依次是当前 HTTP 版本号，3位数字组成的状态代码，以及描述状态的短语，彼此由空格分隔。
状态代码的第一个数字代表当前响应的类型：
1xx 消息——请求已被服务器接收，继续处理
2xx 成功——请求已成功被服务器接收、理解、并接受
3xx 重定向——需要后续操作才能完成这一请求
4xx 请求错误——请求含有词法错误或者无法被执行
5xx 服务器错误——服务器在处理某个正确请求时发生错误
虽然 RFC 2616 中已经推荐了描述状态的短语，例如"200 OK"，"404 Not Found"，但是 WEB 开发者仍然能够自行决定采用何种短语，用以显示本地化的状态描述或者自定义信息。
HTTP 请求/响应的步骤
1、客户端连接到Web服务器
一个HTTP客户端，通常是浏览器，与Web服务器的HTTP端口（默认为80）建立一个TCP套接字连接。例如，http://www.oakcms.cn。
2、发送HTTP请求
通过TCP套接字，客户端向Web服务器发送一个文本的请求报文，一个请求报文由请求行、请求头部、空行和请求数据4部分组成。
3、服务器接受请求并返回HTTP响应
Web服务器解析请求，定位请求资源。服务器将资源复本写到TCP套接字，由客户端读取。一个响应由状态行、响应头部、空行和响应数据4部分组成。
4、释放连接TCP连接
若connection 模式为close，则服务器主动关闭TCP连接，客户端被动关闭连接，释放TCP连接;若connection 模式为keepalive，则该连接会保持一段时间，在该时间内可以继续接收请求;
5、客户端浏览器解析HTML内容
客户端浏览器首先解析状态行，查看表明请求是否成功的状态代码。然后解析每一个响应头，响应头告知以下为若干字节的HTML文档和文档的字符集。客户端浏览器读取响应数据HTML，根据HTML的语法对其进行格式化，并在浏览器窗口中显示。
web（World Wide Web）即全球广域网，也称为万维网，它是一种基于超文本和HTTP的、全球性的、动态交互的、跨平台的分布式图形信息系统。是建立在Internet上的一种网络服务，为浏览者在Internet上查找和浏览信息提供了图形化的、易于访问的直观界面，其中的文档及超级链接将Internet上的信息节点组织成一个互为关联的网状结构。
一般的web是只互联网相关的东西，web页面就是指我们的普通的网页，web开发是只基于物联网的开发，你所看到的东西都是存在互联网的服务器上面，当你用的时候开始下载或者上传相关的信息。相对应的就是客户端开发，我们平时用的一下软件是需要你下载安装的才能正常使用。比如web游戏就是网页游戏，用个浏览器就可以玩。大型的游戏则需要你下载相应的客户端。
原文地址：https://www.cnblogs.com/wdyaoyao/p/10442960.html