HTTP相关总结

总结于《HTTP权威指南》

URI：Uniform Resource Identifier，统一资源标识符

    URI就像因特网上的邮政地址一样，在世界范围内唯一标识并定位信息资源。

URL：统一资源定位符，是资源标识符最常见的形式。URL描述了一台特定服务器上某资源的特定位置。它们可以明确说明如何从一个精确、固定的位置获取资源。

大部分URL都遵循一种标准格式，这种格式包含三个部分：

• URL的第一部分被称为方案（scheme），说明了访问资源所使用的协议类型。这部分通常就是HTTP协议（http://）。

• 第二部分给出了服务器的因特网地址（比如，www.hao123.com）。

• 其余部分指定了web服务器上的某个资源（比如，/specials/abc.gif）。

URN：URI的第二种形式就是统一资源名（URN）。URN是作为特定内容的唯一名称使用的，与目前的资源所在地无关。使用这些与位置无关的URN，就可以将资源四处搬移。通过URN，还可以用同一个名字通过多种网络协议来访问资源。

---

TCP：传输控制协议。

TCP提供了：

• 无差错的传输；

• 按序传输（数据总是会按照发送的顺序到达）；

• 未分段的数据流（可以在任意时刻以任意尺寸将数据发送出去）。

只要建立了TCP连接，客户端和服务器之间的报文交换就不会丢失、不会被破坏，也不会在接收时出现错序了。

 

---

HTTP报文流

    HTTP报文是在HTTP应用程序之间发送的数据块。这些数据块以一些文本形式的元信息（meta-information）开头，这些信息描述了报文的内容及含义，后面跟着可选的数据部分。这些报文在客户端、服务器和代理之间流动。

    HTTP使用术语流入（inbound）和流出（outbound）来描述事务处理（transaction）的方向。报文流入源端服务器，工作完成之后，会流回用户的Agent代理中。

 

报文的组成部分

HTTP报文是简单的格式化数据。每条报文都包含一条来自客户端的请求，或者一条来自服务器的响应。它们由三个部分组成：对报文进行描述的起始行（start line）、包含属性的首部（header）块、以及可选的、包含数据的主体（body）部分。

 

所有的HTTP报文都可以分为两类：请求报文（request message）和响应报文（response message）。请求报文会向Web服务器请求一个动作。响应报文会将请求的结果返回给客户端。请求和响应报文的基本报文结构相同。

请求报文格式：

    <method> <request-URL> <version>

    <headers>

 

    <entity-body>

响应报文格式：

    <version> <status> <reason-phrase>

    <headers>

 

    <entity-body>

---

下面是对各部分的简要描述：

• 方法（method）

客户端希望服务器对资源执行的动作。是一个单独的词，比如GET、HEAD或POST。

• 请求URL（request-URL）

命名了所请求资源，或者URL路径组件的完整URL。如果直接与服务器进行对话，只要URL的路径是资源的绝对路径，通常就不会有什么问题——服务器可以假定自己是URL的主机/端口。

• 版本（version）

报文使用的HTTP版本，其格式看起来是这样的：

HTTP/<major>.<minor>

其中主要版本号（major）和次要版本号（minor）都是整数。

• 状态码（state-code）

这三位数字描述了请求过程中所发生的的情况。每个状态码的第一位数字都用于描述状态得到一般类别（“成功”、“出错”等）。

• 原因短语（reason-phrase）

数字状态码的可读版本，包含行终止序列之前的所有文本。

• 首部（header）

可以有零个或多个首部，每个首部都包含一个名字，后面跟着一个冒号，然后是一个可选的空格，接着是一个值，最后是一个CRLF。

• 实体的主体部分（entity-body）

实体的主体部分包含一个由任意数据组成的数据块。

---

状态码

100~199——信息性状态码

100：Continue/说明收到了请求的初始部分，请客户端继续。发送了这个状态码之后，服务器在收到请求之后必须进行相应。

101：Switching Protocols/说明服务器正在根据客户端的指定，将协议切换成Update首部所列的协议。

 

200~299——成功状态码

200：OK/请求没问题，实体的主体部分包含了所请求的资源。

201：Created/用于创建服务器对象的请求。服务器必须在发送这个状态码之前创建好对象。

202：Accepted/请求已被接收，但服务器还未对其执行任何动作。

203：Non-Authoritative Information/实体首部包含的信息不是来自于源端服务器，而是来自资源的一份副本。

204：No Content/响应报文中包含若干首部和一个状态行，但没有实体的主体部分。

205：Reset Content/另一个主要用于浏览器的代码。

206：Partial Content/成功执行了一个部分或Range（范围）请求。

 

300~399——重定向状态码

300：Multiple Choices/客户端请求一个实际指向多个资源的URL时会返回这个状态码。

301：Moved Permanently/在请求的URL已被移除时使用。

302：Found/与301状态码类似。但是，客户端应该使用Location首部给出的URL来临时定位资源。将来的请求仍应使用老的URL。

303：See Other/告知客户端应该用另一个URL来获取资源。

304：Not Modified/客户端可以通过包含的请求首部，使其请求变成有条件的。

305：Use Proxy/客户端可以通过一个代理来访问资源，代理的位置由Location首部给出。

306：（未使用）

307：Temporary Redirect/与301类似。

 

400~499——客户端错误状态码

400：Bad Request/用于告知客户端它发送了一个错误的请求。

401：Unauthorized/与适当的首部一同返回，在这些首部中请求客户端在获取对资源的访问权之前，对自己进行认证。

402：Payment Required/未使用

403：Forbidden/用于说明请求被服务器拒绝了。如果服务器向说明为什么拒绝请求，可以包含实体的主体部分对原因进行描述。但这个状态码通常是在服务器不想说明拒绝原因的时候使用的。

404：Not Found/用于说明服务器无法找到所请求的URL。通常会包含一个实体，以便客户端应用程序显示给用户看。

 

500~599——服务器错误状态码

500：Internal Server Error/服务器遇到一个妨碍它为请求提供服务的错误时，使用此状态码。

501：Not Implemented/客户端发起的请求超出服务器的能力范围（比如，使用了服务器不支持的请求方法）时。

502：Bad Gateway/作为代理或网关使用的服务器从请求响应链的下一链路上收到了一条伪响应。

503：Service Unavailable/用来说明服务器现在无法为请求提供服务，但将来可以。

---

TCP连接

世界上几乎所有的HTTP通信都是由TCP/IP承载的，TCP/IP是全球计算机及网络设备都在使用的一种常用的分组交换网络分层协议集。客户端应用程序可以打开一条TCP/IP连接，连接到可能运行在世界任何地方的服务器应用程序。一旦连接建立起来了，在客户端和服务器的计算机之间交换的报文就永远不会丢失、受损或失序。

HTTP连接实际上就是TCP连接及其使用规则。TCP连接是因特网上的可靠连接。TCP为HTTP提供了一条可靠的比特传输管道。从TCP连接一端填入的字节会从另一端以原有的顺序、正确地传输出来。

 

 

TCP的数据是通过名为IP分组（或IP数据报）的小数据块来发送的。这样的话，如下图所示，HTTP就是“HTTP over TCP over IP”这个“协议栈”中的最顶层了。其安全版本HTTPs就是在HTTP和TCP之间插入了一个（成为TLS或SSL的）密码加密层。

保持TCP连接持续不断地运行

在任意时刻计算机都可以有几条TCP连接处于打开状态。TCP是通过端口号来保持所有这些连接不断地运行。

TCP连接的三次握手

建立一条新的TCP连接时，甚至是在发送任意数据之前，TCP软件之间会交换一系列的IP分组，对连接的有关参数进行沟通。如果连接只用来传送少量数据，这些交换过程就会严重降低HTTP的性能。

 

TCP连接握手需要经过以下几个步骤：

（a）请求新的TCP连接时，客户端要向服务器发送一个小的TCP分组（通常是40~60个字节）。这个分组中设置了一个特殊的SYN标记，说明这是一个连接请求。

（b）如果服务器接受了连接，就会对一些连接参数进行计算，并向客户端回送一个TCP分组，这个分组中的SYN和ACK标记都被置位，说明连接请求已经接受。

（c）最后，客户端向服务器回送一条确认信息，通知它连接成功建立。现代的TCP栈都允许客户端在这个确认分组中发送数据。

 

cookie

cookie是当前识别用户，实现持久化会话的最好方式。前面各种技术中存在的很多问题对它们都没什么影响，但是通常会将它们与那些技术共用，以实现额外的价值。cookie最初是由网景公司开发的，但现在所有主要的浏览器都支持它。

 

cookie的类型

可以笼统地将cookie分为两类：会话cookie和持久cookie。会话cookie是一种临时cookie，它记录了用户访问站点时的设置和偏好。用户退出浏览器时，会话cookie就被删除了。持久cookie的生存时间更长一些；它们存储在硬盘上，浏览器退出，计算机重启时它们仍然存在。通常会用持久cookie维护某个用户会周期性访问的站点的配置文件或登录名。

 

会话cookie和持久cookie之间唯一的区别就是它们的过期时间。

 

 

cookie就像服务器给用户贴的“嗨，我叫”的贴纸一样。用户访问一个Web站点时，这个Web站点就可以读取那个服务器贴在用户身上的所有贴纸。

用户首次访问Web站点时，Web服务器对用户一无所知。Web服务器希望这个用户会再次回来，所有想给这个用户“拍上”一个独有的cookie，这样以后它就可以识别出这个用户了。cookie中包含了一个由名字=值（name=value）这样的信息构成的任意列表，并通过Set-Cookie或Set-Cookie2HTTP响应（扩展）首部将其贴到用户身上去。

cookie中可以包含任意信息，但它们通常都只包含一个服务器为了进行跟踪而产生的独特的识别码。

浏览器会记住从服务器返回的Set-Cookie或Set-Cookie2首部中的cookie内容，并将cookie集存储在浏览器的cookie数据库中（把它当作一个贴有不同国家贴纸的旅行箱）。将来用户返回同一站点时，浏览器会挑中那个服务器贴到用户上的那些cookie，并在一个cookie请求首部中将其传回去。

---

保护HTTP的安全

HTTPs是最流行的HTTP安全协议。它是由网景公司首创的，所有主要的浏览器和服务器都支持此协议。

HTTPs方案的URL以https://，而不是http://开头，据此就可以分辨某个Web页面是通过HTTPs而不是HTTP访问的。

使用HTTPs时，所有的HTTP请求和响应数据在发送到网络之前，都要进行加密。HTTPs在HTTP下面提供了一个传输级别的密码安全层（Transport Layer Security,TLS）。由于SSL和TLS非常类似。大部分困难的编码及解码工作都是在SSL库中完成的，所以Web客户端和服务器在使用安全HTTP时无需过多地修改其协议处理逻辑。在大多数情况下，只需要用SSL的输入/输出调用取代TCP的调用，再增加其他几个调用来配置和管理安全信息就行了。

HTTPs就是在安全的传输层上发送的HTTP。HTTPs没有将未加密的HTTP报文发送给TCP，并通过世界范围内的因特网进行传输，它在将HTTP报文发送给TCP之前，先将其发送给了一个安全层，对其进行加密。

HTTPs方案

现在，安全HTTP是可选的。因此，对Web服务器发起请求时，我们需要有一种方式来改制Web服务器去执行HTTP的安全协议版本。

请求一个客户端（比如Web浏览器）对某Web资源执行某事务时，它会去检查URL的方案。

• 如果URL的方案为HTTP，客户端就会打开一条到服务器端口80（默认情况下）的连接，并向其发送老的HTTP命令。

• 如果URL的方案为HTTPs，客户端就会打开一条到服务器端口443（默认情况下）的连接，然后与服务器“握手”，以二进制格式与服务器交换一些SSL安全参数，附上加密的HTTP命令。

 

SSL握手

在发送已加密的HTTP报文之前，客户端和服务器要进行一次SSL握手，在这个握手过程中，它们要完成以下工作：

• 交换协议版本号

• 选择一个两端都了解的密码

• 对两端的身份进行认证

• 生成临时的会话密钥，以便加密信道