收藏网络编程魔法今日看点

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

2016-12-11  本文已影响619人  Jensen95

序言

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

Http

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

连接类型

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

比较：

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

Http报文格式

Http请求报文
Http请求报文格式

首部行
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的区别

Http2和Http1.1的区别

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

FTP区别

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

参考文章

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

上一篇下一篇

猜你喜欢

热点阅读