当我们谈网络时，我们谈些什么(1)Http

序言

最近在做博客的迁移，从Segmentfault迁移到简书，很早之前在Segmentfault出了一个系列的《当我们谈网络，谈些什么》专题，得到了比较好多反响和认可。准备更仔细深入的再来做一起，更深入，更全面的来讲解网络知识。涉及Http，DNS,TCP，UDP，网络层，链路层，无线网络，移动网络，网络安全加密等。之前的一系列侧重点在于对于整体体系的学习和把握，结合之前的文章，将对网络有更深层次的理解。本系列会更偏向于其中的知识，覆盖的知识面会更广。对于整体体系的学习可以参考之前系列文章。作为第一篇，首先要讲的是Http，将从

• Http连接方式
• 请求报文
• 响应报文
• 请求响应体类型
• Cookie
• 缓存体系
• 版本差异
  这几个点来讲解Http，不当之处，欢迎各位同学评论指正，共同进步。

Http

Http超文本传输协议（英文：HyperText Transfer Protocol，缩写：HTTP）是互联网上应用最为广泛的一种网络协议。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。通过HTTP或者HTTPS协议请求的资源由统一资源标识符（Uniform Resource Identifiers，URI）来标识。

连接类型

Http传输层采用的TCP协议，其具备两种两节方式。

• 持久连接
  在一个TCP连接上进行数据的传输
• 非持久连接
  每一次请求，都建立一个TCP连接

比较：

• 持久连接：
  • 优点：无需每次请求重新建立TCP连接，节省访问时间，同时减轻流量消耗，降低网络负载。
  • 缺点：持久连接需要服务器对每一个连接的用户维护一段内存来进行相应的读写操作，因此当用户量较大的时候，服务器的开销也比较大。
• 非持久连接：
  • 优点：服务器无需保存维护大量Client连接的状态和内存，服务器开销较小。
  • 缺点: 每次数据请求，发送，都需要建立TCP连接，相比持久连接增加了两个RTT，同时增加了网络的负载。

对于该采取何种请求类型，并没有统一的标准，需要根据我们自身的实际业务需求和场景，动态灵活的调整，选择。

Http报文格式

Http请求报文

Http请求报文格式

• 请求行
  • 请求方法字段（Get,Post,Head,Put,Delete）
  • URL
  • Http版本号
• 首部行
• 请求数据
  各类请求方法
• Get：用来获取服务器上指定内容
• Post：向服务器提交数据
• Head：类似于Get方法，类似于get方法，但是服务器没有实体响应，用来给开发者进行调试跟踪
• Put：上传数据至服务器
• Delete：用户用来删除服务器中数据

首部行
Http头部列表具体可见此列表内容。此处列举几个常见类型。
当我们的请求方法为Get时，我们的请求主体内是为空的，但是当我们为Post的时候，需要我们提供部分数据.

协议头字段名	说明	示例
Accept-Charset	能够接受的字符集	Accept-Charset: utf-8
Accept	能够接受的回应内容类型（Content-Types）	Accept: text/plain
Connection	该浏览器想要优先使用的连接类型	Connection: keep-alive Connection: Upgrade
Content-Length	以 八位字节数组 （8位的字节）表示的请求体的长度	Content-Length: 348
Content-Type	请求体的 多媒体类型	Content-Type: application/x-www-form-urlencoded
Cookie	在之前与服务器的交互中下发得到的Cookie	Cookie: $Version=1; Skin=new;
Host	服务器的域名(用于 虚拟 主机 )，以及服务器所监听的 传输控制协议端口 号。如果所请求的端口是对应的服务的标准端口，则 端口 号可被省略。	Host: en.wikipedia.org:80
Range	仅请求某个实体的一部分。字节偏移以0开始。参考 字节服务 。	Range: bytes=500-999
Upgrade	要求服务器升级到另一个协议。	Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
Max-Forwards	限制该消息可被代理及网关转发的次数。	Max-Forwards: 10
If-Modified-Since	允许在对应的内容未被修改的情况下返回304未修改	If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
If-None-Match	允许在对应的内容未被修改的情况下返回304未修改	If-None-Match: "737060cd8c284d8af7ad3082f209582d"

请求体

POST 提交数据方案，包含了 Content-Type 和消息主体编码方式两部分。常见的Content-type有如下几种类型。

application/x-www-form-urlencoded

这应该是最常见的 POST 提交数据的方式了。浏览器的原生 <form> 表单，如果不设置 enctype 属性，那么最终就会以 application/x-www-form-urlencoded 方式提交数据。请求类似于下面这样（无关的请求头在本文中都省略掉了）：

POST http://www.example.com HTTP/1.1
Content-Type: application/x-www-form-urlencoded;charset=utf-8
title=test&sub%5B%5D=1&sub%5B%5D=2&sub%5B%5D=3

首先，Content-Type 被指定为 application/x-www-form-urlencoded；其次，提交的数据按照 key1=val1&key2=val2 的方式进行编码，key 和 val 都进行了 URL 转码。大部分服务端语言都对这种方式有很好的支持。例如 PHP 中，$_POST['title'] 可以获取到 title 的值，$_POST['sub'] 可以得到 sub 数组。
很多时候，我们用 Ajax 提交数据时，也是使用这种方式。例如 JQuery 和 QWrap 的 Ajax，Content-Type 默认值都是「application/x-www-form-urlencoded;charset=utf-8」。

multipart/form-data

这又是一个常见的 POST 数据提交的方式。我们使用表单上传文件时，必须让 <form> 表单的 enctype 等于 multipart/form-data。直接来看一个请求示例：

POST http://www.example.com HTTP/1.1
Content-Type:multipart/form-data; boundary=----WebKitFormBoundaryrGKCBY7qhFd3TrwA

------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content-Disposition: form-data; name="text"

title
------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content-Disposition: form-data; name="file"; filename="chrome.png"
Content-Type: image/png

PNG ... content of chrome.png ...
------WebKitFormBoundaryrGKCBY7qhFd3TrwA--

这个例子稍微复杂点。首先生成了一个 boundary 用于分割不同的字段，为了避免与正文内容重复，boundary 很长很复杂。然后 Content-Type 里指明了数据是以 multipart/form-data 来编码，本次请求的 boundary 是什么内容。消息主体里按照字段个数又分为多个结构类似的部分，每部分都是以 --boundary 开始，紧接着是内容描述信息，然后是回车，最后是字段具体内容（文本或二进制）。如果传输的是文件，还要包含文件名和文件类型信息。消息主体最后以 --boundary-- 标示结束。关于 multipart/form-data 的详细定义，请前往 rfc1867 查看。
这种方式一般用来上传文件，各大服务端语言对它也有着良好的支持。
上面提到的这两种 POST 数据的方式，都是浏览器原生支持的，而且现阶段标准中原生 <form> 表单也只支持这两种方式（通过 <form> 元素的 enctype 属性指定，默认为 application/x-www-form-urlencoded。其实 enctype 还支持 text/plain，不过用得非常少）。
随着越来越多的 Web 站点，尤其是 WebApp，全部使用 Ajax 进行数据交互之后，我们完全可以定义新的数据提交方式，给开发带来更多便利。

application/json

application/json 这个 Content-Type 作为响应头大家肯定不陌生。实际上，现在越来越多的人把它作为请求头，用来告诉服务端消息主体是序列化后的 JSON 字符串。由于 JSON 规范的流行，除了低版本 IE 之外的各大浏览器都原生支持 JSON.stringify，服务端语言也都有处理 JSON 的函数，使用 JSON 不会遇上什么麻烦。
JSON 格式支持比键值对复杂得多的结构化数据，这一点也很有用。记得我几年前做一个项目时，需要提交的数据层次非常深，我就是把数据 JSON 序列化之后来提交的。不过当时我是把 JSON 字符串作为 val，仍然放在键值对里，以 x-www-form-urlencoded 方式提交。
Google 的 AngularJS 中的 Ajax 功能，默认就是提交 JSON 字符串。例如下面这段代码：

var data = {'title':'test', 'sub' : [1,2,3]};
$http.post(url, data).success(function(result) {
    ...
});

最终发送的请求是：

POST http://www.example.com HTTP/1.1 
Content-Type: application/json;charset=utf-8
{"title":"test","sub":[1,2,3]}

这种方案，可以方便的提交复杂的结构化数据，特别适合 RESTful 的接口。各大抓包工具如 Chrome 自带的开发者工具、Firebug、Fiddler，都会以树形结构展示 JSON 数据，非常友好。但也有些服务端语言还没有支持这种方式，例如 php 就无法通过 $_POST 对象从上面的请求中获得内容。这时候，需要自己动手处理下：在请求头中 Content-Type 为 application/json 时，从 php://input 里获得原始输入流，再 json_decode 成对象。一些 php 框架已经开始这么做了。

text/xml

XML-RPC（XML Remote Procedure Call）。它是一种使用 HTTP 作为传输协议，XML 作为编码方式的远程调用规范。典型的 XML-RPC 请求是这样的：

POST http://www.example.com HTTP/1.1 
Content-Type: text/xml

<?xml version="1.0"?>
<methodCall>
    <methodName>examples.getStateName</methodName>
    <params>
        <param>
            <value><i4>41</i4></value>
        </param>
    </params>
</methodCall>

Http响应报文

Http响应报文

Http响应报文格式

• 状态行
  • 版本
  • 状态码
  • 状态信息
• 首部行
• 响应实体

状态码

状态码	说明
1XX	这一类型的状态码，代表请求已被接受，需要继续处理。这类响应是临时响应，只包含状态行和某些可选的响应头信息，并以空行结束。由于HTTP/1.0协议中没有定义任何1xx状态码，所以除非在某些试验条件下，服务器禁止向此类客户端发送1xx响应。
2XX	代表请求已成功被服务器接收、理解、并接受
3XX	这类状态码代表需要客户端采取进一步的操作才能完成请求。通常，这些状态码用来重定向
4XX	这类的状态码代表了客户端看起来可能发生了错误，妨碍了服务器的处理。除非响应的是一个HEAD请求，否则服务器就应该返回一个解释当前错误状况的实体，以及这是临时的还是永久性的状况。常见错误如语法错误，资源不存在，权限不足等
5XX	这类状态码代表了服务器在处理请求的过程中有错误或者异常状态发生，也有可能是服务器意识到以当前的软硬件资源无法完成对请求的处理。除非这是一个HEAD请求，否则服务器应当包含一个解释当前错误状态以及这个状况是临时的还是永久的解释信息实体。

响应报文的首部行，见上文

协议头字段名	说明	示例
ETag	对于某个资源的某个特定版本的一个标识符，通常是一个消息散列	ETag: "737060cd8c284d8af7ad3082f209582d"
Expires	指定一个日期/时间，超过该时间则认为此回应已经过期	Expires: Thu, 01 Dec 1994 16:00:00 GMT
Last-Modified	所请求的对象的最后修改日期	Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
Age	这个对象在代理缓存中存在的时间，以秒为单位	Age: 12
Content-Range	这条部分消息是属于某条完整消息的哪个部分	Content-Range: bytes 21010-47021/47022
Date	此条消息被发送时的日期和时间	Date: Tue, 15 Nov 1994 08:12:31 GMT

Cookie

由于Http是无状态协议，因此为了提升客户端和服务器的交互效率，采用了Cookie来进行记录客户端和服务器之间的交互。具体的实施策略就是在首次访问服务器时，在相应报文字段中set_cookie中返回服务器针对该客户端生成的cookie，然后将该值记录在服务器数据库中，之后，客户端收到响应之后，将该值记录在本地文件中，之后，客户端再次访问网络的时候，就会将该字段携带，发送到服务器。

Http缓存

通过HTTP缓存，可以有效减轻服务器压力，同时可以提升访问速率，减少对于宽带的浪费。
http缓存是基于HTTP的浏览器文件级缓存机制。即针对文件的重复请求情况下，浏览器可以根据协议头判断从服务器端请求文件还是从本地读取文件，chrome控制台下的Frames即展示的是浏览器的http文件级缓存。以下是浏览器缓存的整个机制流程。主要是针对重复的http请求，在有缓 存的情况下判断过程主要分3步：

1. 判断expires，如果未过期，直接读取http缓存文件，不发http请求，否则进入下一步。
2. 判断是否含有etag，有则带上if-none-match发送请求，未修改返回304，修改返回200，否则进入下一步。
3. 判断是否含有last-modified，有则带上if-modified-since发送请求，无效返回200，有效返回304，否则直接向服务器请求。

Http缓存结构

如果通过etag和last-modified判断，即使返回304有至少有一次http请求，只不过返回的是304的返回内容，而不是文件内容。所以合理设计实现expires参数可以减少较多的浏览器请求。

Http版本差异

Http1.1和Http1.0的区别

• 可扩展性增加了几个头部字段，HTTP/1.1增加了OPTIONS方法，它允许客户端获取一个服务器支持的方法列表。为了与未来的协议规范兼容，HTTP/1.1在请求消息中包含了Upgrade头域，通过该头域，客户端可以让服务器知道它能够支持的其它备用通信协议，服务器可以据此进行协议切换，使用备用协议与客户端进行通信。

• 缓存，增加Etag等字段提升使得Cach机制更加的灵活。

• 带宽优化，增加Content-rang字段，实现断点续传。

• 长连接，HTTP 1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。

• 消息传递 HTTP消息中可以包含任意长度的实体，通常它们使用Content-Length来给出消息结束标志。但是，对于很多动态产生的响应，只能通过缓冲完整的消息来判断消息的大小，但这样做会加大延迟。如果不使用长连接，还可以通过连接关闭的信号来判定一个消息的结束。HTTP/1.1中发送方将消息分割成若干个任意大小的数据块，每个数据块在发送时都会附上块的长度，最后用一个零长度的块作为消息结束的标志。这种方法允许发送方只缓冲消息的一个片段，避免缓冲整个消息带来的过载。

• Host头域，在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。

• 错误提示 HTTP/1.0中只定义了16个状态响应码，对错误或警告的提示不够具体。HTTP/1.1引入了一个Warning头域，增加对错误或警告信息的描述。

• 更友好精细化的内容协商。HTTP引入了一个品质因子（quality values）的概念来表示不同版本的可用性，它的取值从0.0到1.0。例如一个母语是英语的人也能讲法语、甚至还学了点丹麦语，那么他的浏览器可用作如下配置：Accept-Language: en, fr;q=0.5, da;q=0.1。这时，服务器会优先选取品质因子高的值对应的资源版本作为响应。

Http2和Http1.1的区别

Http2是基于SPDY协议制定的协议，大幅度的提升了 web 性能，在与 HTTP/1.1 完全语义兼容的基础上，进一步减少了网络延迟。SPDY 是 Google 开发的基于传输控制协议 (TCP) 的应用层协议 ，开发组正在推动 SPDY 成为正式标准（现为互联网草案）。SPDY 协议旨在通过压缩、多路复用和优先级来缩短网页的加载时间和提高安全性。
相比于Http1.1，Http2有了以下几点改进和提升。

• HTTP/2采用二进制格式而非文本格式，头部和内容实体封装成帧。

• HTTP/2是完全多路复用的，而非有序并阻塞的——只需一个连接即可实现并行（指一个连接(connection)一次只提交一个请求的效率比较高, 多了就会变慢。 HTTP/1.1 试过用流水线(pipelining)来解决这个问题, 但是效果并不理想(数据量较大或者速度较慢的响应, 会阻碍排在他后面的请求)，而Http2通过在头部添加了StreamID字段可有效的解决这个问题。

• 使用报头压缩，HTTP/2降低了开销HEAD 在传输的时候，通过Haffman演算法压缩 HEAD来增加传输速度。

• HTTP/2让服务器可以将响应主动“推送”到客户端缓存中。

FTP区别

FTP和HTTP都是一种文件传输协议，而且运输层使用的都是TCP协议，不同的是，FTP的文件传输是带外传输，FTP在传送文件或者获取文件的时候，首先需要在创建一个TCP连接用来进行控制信息的传输，当有文件需要传输的时候，会再建立起一条TCP连接，进行数据的传输。数据传输完毕，连接将会断掉，再次有数据传输的请求，将会再次有TCP的连接建立起来。FTP占用的端口号是21号。

参考文章

九种浏览器缓存方法知多少
Http状态码
HTTP/1.1与HTTP/1.0的区别
HTTP/2 新特性浅析