简述HTTP协议

时间 2019-11-06

标签简述 http 协议栏目 HTTP/TCP 繁體版

原文原文链接

身为开发人员除了应该对咱们所写的项目需求要了解，以及基本的语言知识，对于HTTP协议也是应该了解一下的，由于这些东西与咱们是密不可分的，天天都在和HTTP打交道然而殊不知道它究竟是什么？这样说出去是否是很可悲？简直可歌可泣有没有...php

http协议:HTTP是一个简单的请求-响应协议，它一般运行在TCP之上。它指定了客户端可能发送给服务器什么样的消息以及获得什么样的响应。请求和响应消息的头以ASCII码形式给出；而消息内容则具备一个相似MIME的格式。这个简单模型是早期Web成功的有功之臣，由于它使得开发和部署是那么的直截了当。超文本传输协议（HTTP）是用于传输诸如HTML的超媒体文档的应用层协议。它被设计用于Web浏览器和Web服务器之间的通讯，但它也能够用于其余目的。HTTP遵循经典的客户端-服务端模型，客户端打开一个链接以发出请求，而后等待它收到服务器端响应。 -- 百度百科html

HTTP是无状态协议，意味着服务器不会在两个请求之间保留任何数据（状态）。在同一个链接中，两个执行成功的请求之间是没有关系的。这就带来了一个问题，用户没有办法在同一个网站中进行连续的交互，好比在一个电商网站里，用户把某个商品加入到购物车，切换一个页面后再次添加了商品，这两次添加商品的请求之间没有关联，浏览器没法知道用户最终选择了哪些商品。而使用HTTP的头部扩展，HTTP Cookies就能够解决这个问题。把Cookies添加到头部中，建立一个会话让每次请求都能共享相同的上下文信息，达成相同的状态。经过上述得出结论，http特色是：无状态，无链接，简单快速。web

HTTP交互流程

一个链接是由传输层来控制的，这从根本上不属于HTTP的范围。HTTP并不须要其底层的传输层协议是面向链接的，只须要它是可靠的，或不丢失消息的（至少返回错误）。在互联网中，有两个最经常使用的传输层协议：TCP是可靠的，而UDP不是。所以，HTTP依赖于面向链接的TCP进行消息传递，但链接并非必须的。express

TCP：面向链接（如打电话要先拨号创建链接）
UDP：是无链接的，即发送数据以前不须要创建链接

关于TCP和UDP这里不作多余赘述，若是想要深刻了解二者之间的优缺点以及区别的话，有时间再详细的介绍一下。segmentfault

其实HTTP交互流程就是基于TCP链接进行消息传递的，然而这个链接无关紧要，具体交互流程以下图：浏览器

结合上图详细说明经历的过程：缓存

打开一个TCP链接：TCP链接被用来发送一条或多条请求，以及接受响应消息。客户端可能打开一条新的链接，或重用一个已经存在的链接，或者也可能开几个新的TCP链接连向服务端
发送一个HTTP报文：HTTP报文（在HTTP/2以前）是语义可读的。在HTTP/2中，这些简单的消息被封装在了帧中，这使得报文不能被直接读取，可是原理还是相同的
读取服务端返回的报文信息,服务器端接收到请求后，进行处理，而后将处理结果响应客户端(HTTP协议)
关闭链接或者为后续请求重用链接，关闭客户端和服务器端的链接(HTTP1.1后不会当即关闭)

当HTTP流水线启动时，后续请求均可以不用等待第一个请求的成功响应就被发送。然而HTTP流水线已被证实很难在现有的网络中实现，由于现有网络中有不少老旧的软件与现代版本的软件共存。所以，HTTP流水线已被在有多请求下表现得更稳健的HTTP/2的帧所取代。安全

HTTP报文

在Linux系统下有一个curl指令能够经过这个命令来观测一下HTTP的请求过程。服务器

curl -v https://segmentfault.com/

输入完以后回车就会看到下面这些信息:cookie

图中>开始的是客服端发送给服务端的信息，以<开始的为服务端返回给客户端的一些信息。当客户端发起一个Ajax请求时，浏览器会携带一些信息发送给服务端，HTTP请求头提供了关于请求，响应或者其余的发送实体的信息。请求报文分为如下几个部分：

General(请求行)
Request Headers(请求头)
Response Headers(响应头)

这三个部分分别承载了服务端以及客户端所须要的信息，在浏览器中种NetWork中能够查看到其信息内容，接下来就一一介绍一下：

General

这部分主要提供的是一些公用的请求头信息：

Request URL: https://segmentfault.com/search?q=search
Request Method: GET
Status Code: 200 
Remote Address: 112.126.83.219:443
Referrer Policy: no-referrer-when-downgrade

Request URL：请求地址
Request Method：请求方式
Status Code：状态码
Remote Address：请求的远程地址
Referrer Policy: 过滤 Referrer 报头内容

上述信息代表，客户端向服务器发送一个http请求，其请求地址为https://segmentfault.com/search?q=search，使用GET方式发起这个请求，请求返回状态为200，链接的远程地址为112.126.83.219:443，过滤报头采用的是不传递Referrer。

向前面几个应该都比较熟悉也通俗易懂，当看到的这的时候内心有一些些的小疑惑Remote Address是什么？Referrer Policy过滤报头的规则有哪些？

Remote Address

关于Remote Address远程链接地址，Remote Address表明客户端的IP，但它的值不是由客户端提供的，而是服务端根据客户端的IP指定的，当你的浏览器访问某个网站时，假设中间没有任何代理，那么网站的web服务器（Nginx，Apache等）就会把Remote Address设为你的机器IP，若是你用了某个代理，那么你的浏览器会先访问这个代理，而后再由这个代理转发到网站，这样web服务器就会把Remote Address设为这台代理机器的IP。以致于后面的443端口，也简单的看了一下，443端口即网页浏览端口，主要是用于HTTPS服务，是提供加密和经过安全端口传输的另外一种HTTP。在一些对安全性要求较高的网站，好比银行、证券、购物等，都采用HTTPS服务，这样在这些网站上的交换信息，其余人抓包获取到的是加密数据，保证了交易的安全性。我也没有作深刻的了解，大概就是这个样子吧。

Referrer Policy

Referrer-Policy的做用就是为了控制请求头中referrer的内容，目前是一个候选标准，不过已经有部分浏览器支持该标准。目前Referrer-Policy只包含如下几种值：

值	解释
no-referrer	不显示referrer的任何信息在请求头中。
no-referrer-when-downgrade	这是默认值。当从https网站跳转到http网站或者请求其资源时（安全降级HTTPS→HTTP），不显示referrer的信息，其余状况（安全同级HTTPS→HTTPS，或者HTTP→HTTP）则在referrer中显示完整的源网站的URL信息。
same-origin	表示浏览器只会显示referrer信息给同源网站，而且是完整的URL信息。所谓同源网站，是协议、域名、端口都相同的网站。
origin	表示浏览器在referrer字段中只显示源网站的源地址（即协议、域名、端口），而不包括完整的路径。
strict-origin	该策略更为安全些，和origin策略类似，只是不容许referrer信息显示在从https网站到http网站的请求中（安全降级）。
origin-when-cross-origin	当发请求给同源网站时，浏览器会在referrer中显示完整的URL信息，发个非同源网站时，则只显示源地址（协议、域名、端口）
strict-origin-when-cross-origin	和origin-when-cross-origin类似，只是不容许referrer信息显示在从https网站到http网站的请求中（安全降级）。
unsaft-url	浏览器老是会将完整的URL信息显示在referrer字段中，不管请求发给任何网站。

Referrer-Policy值不是固定不变的，而是但是经过程序手动设置，通常都会不会去手动更改除非网页中不存在一些敏感信息，那就默认使用no-referrer-when-downgrade。这里就多说了，若是有兴趣的能够调研一下。

Response Headers

这部分存储的是响应头信息，当服务端接受到请求，并处理完成以后须要向客户端作出应答。

cache-control: no-store, no-cache, must-revalidate
content-encoding: gzip
content-type: text/html; charset=UTF-8
date: Fri, 28 Jun 2019 09:32:09 GMT
expires: Thu, 19 Nov 1981 08:52:00 GMT
pragma: no-cache
status: 200
strict-transport-security: max-age=15768000; preload
x-hit: web1

cache-control：响应输出到客户端后，服务端经过该报文头告诉客户端如何控制响应内容的缓存
content-encoding：文档编码（Encode）方法。只有在解码以后才能够获得Content-Type头指定的内容类型
content-type：文档类型
date：当前的GMT时间，能够用setDateHeader来设置
expires：文档过时时间，文档到期后则再也不缓存
pragma：设置消息头，(no-cache)强制清除缓存
status：服务器响应状态码
strict-transport-security：安全功能，它告诉浏览器只能经过HTTPS访问当前资源，而不是HTTP

Request Headers

这部分承载的是请求头的信息，当客户端向服务端发送请求时，须要传递给服务端的信息内容。

:authority: segmentfault.com
:method: GET
:path: /search?q=1
:scheme: https
accept: text/html,application/xhtml+xml,application/xml;
accept-encoding: gzip, deflate, br
accept-language: zh-CN,zh;q=0.9
cookie: e23800c454aa573c0ccb16b52665ac26=1561712973
referer: https://segmentfault.com/
user-agent: Chrome/75.0.3770.100 Safari/537.

:authority：请求权限（HTTP2.0）
:method：请求方式（HTTP2.0）
:path：请求地址（HTTP2.0）
:scheme：请求协议（HTTP2.0）
accept：指定客户端能够接受的内容类型，好比文本，图片，应用等等，内容的前后排序表示客户端接收的前后次序，每种类型之间用逗号隔开。
accept-encoding：客户端接收编码类型，一些网络压缩格式：Accept-Encoding: gzip, deflate, sdch。相对来讲，deflate是一种过期的压缩格式，如今经常使用的是gzip
accept-language：客户端能够接受的语⾔言类型，参数值规范和 accept的很像。通常就接收中文和英文，有其余语言需求自行添加。
cookie：一样是一个比较关键的字段，Cookie是 client 请求服务器时，服务器会返回一个键值对样的数据给浏览器，下一次浏览器再访问这个域名下的网页时，就须要携带这些键值对数据在 Cookie中，用来跟踪浏览器用户的访问先后路径。
referer：浏览器上次访问的网页url，uri。因为http协议的无记忆性，服务器可从这里了解到客户端访问的先后路径，并作一些判断，若是⼀次访问的 url 不能从前一次访问的页面上跳转得到，在必定程度上说明了请求头有可能伪造。
user-agent：中文名用户代理，服务器今后处知道客户端的操做系统类型和版本，电脑CPU类型，浏览器种类版本，浏览器渲染引擎，等等。

accept-language共分为下列几种：

zh-CN：中文简体大陆
zh：其余中文
en-US：英语美语
en：其余英语

Cookie就是存储在客户端的一小段文本，由于cookie是存储在客户端浏览器中的，Cookie不能做为代码执行，也不会传送病毒，且为你所专有，并只能由提供它的服务器来读取。保存的信息片段以名/值对(name-value)的形式储存，一个名/值对仅仅是一条命名的数据。一个网站只能取得它放在你的电脑中的信息，它没法从其它的cookie文件中取得信息，也没法获得你的电脑上的其它任何东西。

const express = require('express');
const cookieParser = require('cookie-parser');
var app = express();
app.use(cookieParser('sign'));
app.get('/set', function(req, res) {
    res.cookie('name', 'TracyYu', {maxAge: 9999999, httpOnly: true, signed: true});
    res.send('cookie设置成功');
})
app.get('/get', function(req, res) {
    console.log(req.signedCookies);
    res.send('success')
})
app.listen('3000', function() {
    console.log('3000成功');
})

经过上面代码中对cookie进行设置以后，用户访问/set路由的是时候已经把cookie设置到了浏览器的头部，当用户访问/get路由的时候，因为在浏览器中已经设置好cookie，在同属于一个服务的状况下是能够直接获取到cookie的。固然除了上述所说，经过document也是能够手动设置cookie的，在客户端设置的cookie在服务端一样是也能够获取到的。

document.cookie="userId=929";

这样就将名为userId的cookie值设置为了929，如今访问/get一样就能拿到在客户端设置的cookie值了。

请求方式

http中常常用的到的就是get和post两种，在开发过程当中会遵循RESTful接口风格，这是一种如今比较流行的接口风格，使用这种接口风格须要用到一些其余的请求方式，http请求方式一共有8种。

请求方式	描述
OPTIONS	容许客户端查看服务器的性能，服务器针对特定资源所支持的HTTP请求方法，也能够利用向web服务器发送‘*’的请求来测试服务器的功能性
HEAD	向服务器索与GET请求相一致的响应，只不过响应体将不会被返回。这一方法能够再没必要传输整个响应内容的状况下，就能够获取包含在响应小消息头中的元信息。
GET	向特定的资源发出请求。它本质就是发送一个请求来取得服务器上的某一资源。资源经过一组HTTP头和呈现数据（如HTML文本，或者图片或者视频等）返回给客户端。GET请求中，永远不会包含呈现数据。
POST	向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会致使新的资源的创建和/或已有资源的修改。
PUT	向指定资源位置上传其最新内容
DELETE	请求服务器删除Request-URL所标识的资源
TRACE	回显服务器收到的请求，主要用于测试或诊断
CONNECT	HTTP/1.1协议中预留给可以将链接改成管道方式的代理服务器。

HTTP定义了与服务器交互的不一样方法，最基本的方法是GET和POST（开发关心的只有GET请求和POST请求）。

GET和POST长度的限制问题

GET	POST
GET是经过URL提交数据，所以GET可提交的数据量就跟URL所能达到的最大长度有直接关系	HTTP协议没有对POST进行任何限制，通常是受服务器配置限制或者内存大小
HTTP协议对URL长度是没有限制的；限制URL长度大多数是浏览器或者服务器的配置参数	PHP下能够修改php.conf的postmaxsize来设置POST的大小

其实这里有一个很大的误区，http协议并未规定GET和POST的长度限制，GET的最大长度限制是由于浏览器和web服务器限制了URL的长度，不一样的浏览器和web服务器，限制的最大长度不同，要支持IE，则最大长度为2083byte，若支持Chrome，则最大长度8182byte，首先即便GET有长度限制，也是限制的整个URL的长度，而不只仅是参数值数据长度。

GET和POST的安全性

GET是经过URL方式请求，能够直接看到，明文传输
POST是经过请求header请求，能够开发者工具或者抓包能够看到，一样也是明文的
GET请求会保存在浏览器历史纪录中，还可能会保存在Web的日志中

GET请求指定资源的表示形式。注意，GET不该该用于产生反作用的操做，好比在web应用程序中使用它执行操做。缘由之一是GET可能被机器人或爬行器任意使用，它们不须要考虑请求应该引发的反作用。POST将要处理的数据(例如，从HTML表单)提交给标识的资源。数据包含在请求体中。这可能会致使建立新资源或更新现有资源，或者二者兼而有之。使用HTTP协议的服务不该该使用基于GET的表单来提交敏感数据，由于这会致使这些数据在Request-URI中编码。许多现有服务器，代理和用户代理会将请求URI记录在第三方可能看到的某个位置。服务器可使用基于POST的表单提交。

GET与POST请求过程

POST请求的过程：

浏览器请求tcp链接（第一次握手）
服务器答应进行tcp链接（第二次握手）
浏览器确认，并发送post请求头（第三次握手，这个报文比较小，因此http会在此时进行第一次数据发送）
服务器返回100 Continue响应
浏览器发送数据
服务器返回200 OK响应

GET请求的过程：

浏览器请求tcp链接（第一次握手）
服务器答应进行tcp链接（第二次握手）
浏览器确认，并发送get请求头和数据（第三次握手，这个报文比较小，因此http会在此时进行第一次数据发送）
服务器返回200OK响应

总结

本来想说一些状态码相关的东西，可是简单的看了一下，好像又没有什么好说的，百度百科说的也很清楚，就不在文章里面赘述了。

简单的对http协议作了一些小的介绍与总结，若是文章中有哪些地方有问题，请在下方留言指正，我会尽快作出改正。