HTTP
介绍HTTP协议(特征)
- 可参考
- HTTP 基于TCP/IP通信协议来传递数据(HTML 文件, 图片文件, 查询结果等)
- HTTP是一个属于应用层的面向对象的协议,由于其简捷、快速的方式,适用于分布式超媒体信息系统。
- 它于1990年提出,经过几年的使用与发展,得到不断地完善和扩展。目前在WWW中使用的是HTTP/1.0的第六版,HTTP/1.1的规范化工作正在进行之中,而且HTTP-NG(Next Generation of HTTP)的建议已经提出。
- 无连接:无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求并收到客户的应答后,即断开连接,采用这种方式可以节省传输时间。
- 后来的改进:随着时间的推移,网页变得越来越复杂,里面可能嵌入了很多图片,这时候每次访问图片都需要建立一次 TCP 连接就显得很低效。后来,请求头中Connection:Keep-Alive 被提出用来解决这效率低的问题。Keep-Alive 功能使客户端到服务器端的连接持续有效,当出现对服务器的后继请求时,Keep-Alive 功能避免了建立或者重新建立连接
- 无状态:HTTP协议是无状态协议,无状态是指协议对于事务处理没有记忆能力,意味着每个请求都是独立的,Keep-Alive 没能改变这个结果。缺少状态,意味着如果后续处理需要前面的信息,则他必须重传,这样可能导致每次传输的数据量增大。另一方面,在服务器不需要先前信息时他的应答就很快。
- 后来的改进:两种用于保持 HTTP 连接状态的技术就应运而生了——Cookie和Session。
- Cookie可以保持登录信息到用户下次与服务器的会话,换句话说,下次访问同一网站时,用户会发现不必输入用户名和密码就已经登录了(但不安全)
- 而Session是通过服务器来保持状态的。
- 后来的改进:两种用于保持 HTTP 连接状态的技术就应运而生了——Cookie和Session。
- 简单快速:客户向服务器请求服务时,只需要传送请求方式和路径,请求方法常用的有GET、POST、PUT、DELETE。每种方法规定了客户与服务器联系的类型的类型不同。由于HTTP协议简单,使得HTTP服务器的程序规模小,因而通信速度很快。
- 灵活:HTTP协议允许传输任意类型的数据对象,不同的传输类型由content-Type加以标记。
- HTTP协议工作于客户端-服务端架构:浏览器作为HTTP客户端通过URL向HTTP服务端即WEB服务器发送所有请求。Web服务器根据接收到的请求后,向客户端发送响应信息。
说一下http和https
【HTTPS = HTTP + SSL/TSL(安全层)】
http和https的基本概念
- http: 超文本传输协议,是互联网上应用最为广泛的一种网络协议,是一个客户端和服务器端请求和应答的标准(TCP),用于从WWW服务器传输超文本到本地浏览器的传输协议,它可以使浏览器更加高效,使网络传输减少。
- https: 是以安全为目标的HTTP通道,简单讲是HTTP的安全版,即HTTP下加入SSL层(https的SSL加密是在传输层实现的),HTTPS的安全基础是SSL,因此加密的详细内容就需要SSL。
- https协议的主要作用是:建立一个信息安全通道,来确保数组的传输,确保网站的真实性。
http和https的区别【看第四点】
- http传输的数据都是未加密的,也就是明文的,网景公司设置了SSL协议来对http协议传输的数据进行加密处理,简单来说https协议是由http和ssl协议构建的可进行加密传输和身份认证的网络协议,比http协议的安全性更高。
- 主要的区别如下:
- Https协议需要ca证书,费用较高。
- http是超文本传输协议,信息是明文传输,https则是具有安全性的ssl加密传输协议。
- 使用端口不同,一般而言,http协议的端口为80,https的端口为443
- http的连接很简单,是无状态的;HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议,比http协议安全。
补充HTTP、HTTPS、TCP、UDP的区别
HTTP、HTTPS是应用层协议,为应用系统服务,他们都用TCP传输方式来传输
UDP TCP 是传输层协议,为应用层协议提供服务。
IP是网络层协议,为传输层提供服务。
上层利用下层的服务,下层为上层服务,每层解决不同的网络问题
https协议的工作原理
客户使用https url访问服务器,则要求web 服务器建立ssl链接。
web服务器接收到客户端的请求之后,会将网站的证书(证书中包含了公钥),返回或者说传输给客户端。
客户端和web服务器端开始协商SSL链接的安全等级,也就是加密等级。
客户端浏览器通过双方协商一致的安全等级,建立会话密钥,然后通过网站的公钥来加密会话密钥,并传送给网站。
web服务器通过自己的私钥解密出会话密钥。
web服务器通过会话密钥加密与客户端之间的通信。
(关于“公钥和私钥”可参考知乎文章)
https协议的优点
- 使用HTTPS协议可认证用户和服务器,确保数据发送到正确的客户机和服务器;
- HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议,要比http协议安全,可防止数据在传输过程中不被窃取、改变,确保数据的完整性。
- HTTPS是现行架构下最安全的解决方案,虽然不是绝对安全,但它大幅增加了中间人攻击的成本。
- 谷歌曾在2014年8月份调整搜索引擎算法,并称“比起同等HTTP网站,采用HTTPS加密的网站在搜索结果中的排名将会更高”。
https协议的缺点
- https 握手阶段比较费时耗电(校验证书,交换密钥),会使页面加载时间延长50%,增加10%~20%的耗电。
- https 缓存不如http高效,会增加数据开销。
- SSL证书也需要钱,功能越强大的证书费用越高。
- SSL证书需要绑定IP,不能再同一个ip上绑定多个域名,ipv4资源支持不了这种消耗
说一下http2.0
简要概括:http2.0是基于1999年发布的http1.0之后的首次更新。
- 提升访问速度(相比http1.0,请求资源所需时间更少,访问速度更快,)
- 允许多路复用:就是说 HTTP/2 可以重复使用同一个 TCP 连接,并且连接是多路的,多个请求或响应可以同时传输。
对比之下,HTTP/1.1 的长连接也能复用 TCP 连接,但是只能串行,不能“多路”。 - 二进制分帧:HTTP2.0会将所有的传输信息分割为更小的信息或者帧,并对他们进行二进制编码。
- HTTP/2 允许取消某个正在传输的数据流(通过发送 RST_STREAM 帧),而不关闭 TCP 连接。
这正是二进制协议的好处之一,可以定义多种功能的数据帧。 - 首部压缩
- 服务器端推送:服务端能够直接把资源推送给客户端,当客户端需要这些文件的时候,它已经在客户端了。(该推送对 Web App 是隐藏的,由浏览器处理)
HTTP与WebSocket
- HTTP协议和WebSocket协议都是应用层的网络通信协议,两者应用场景不一样。(而Socket 是传输控制层协议)
- HTTP 协议有一个缺陷:通信只能由客户端发起。 HTTP主要用来一问一答的方式交付信息,而WebSocket让通信双方都可以主动去交换信息,服务器可以主动向客户端推送信息,客户端也可以主动向服务器发送信息(实时传输消息)。
- WebSocket是基于HTTP1.1的协议,可以简单理解为创建了一条TCP连接,在JS中用
new WebSocket("ws://hostname/chattingrom/")
来创建,具有双向传输二进制等特性。 - 在 WebSocket API 中,浏览器和服务器只需要完成一次握手,两者之间就直接可以创建持久性的连接,并可以直接进行双向数据传输。
- 而HTTP2.0则是对HTML、CSS等JS资源的传输方式进行了优化,允许服务端直接把资源推送给客户端,但并没有提供新的JS API,也不能用于实时传输消息。
- 比起传统的ajax请求轮询,HTML5 定义的 WebSocket 协议,能更好的节省服务器资源和带宽,并且能够更实时地进行通讯。
- 轮询是在特定的的时间间隔(如每1秒),由浏览器对服务器发出HTTP请求,然后由服务器返回最新的数据给客户端的浏览器。这种传统的模式带来很明显的缺点,即浏览器需要不断的向服务器发出请求,然而HTTP请求可能包含较长的头部,其中真正有效的数据可能只是很小的一部分,显然这样会浪费很多的带宽等资源。
- 轮询是在特定的的时间间隔(如每1秒),由浏览器对服务器发出HTTP请求,然后由服务器返回最新的数据给客户端的浏览器。这种传统的模式带来很明显的缺点,即浏览器需要不断的向服务器发出请求,然而HTTP请求可能包含较长的头部,其中真正有效的数据可能只是很小的一部分,显然这样会浪费很多的带宽等资源。
WebSocket其他特点
(1)建立在 TCP 协议之上,服务器端的实现比较容易。
(2)与 HTTP 协议有着良好的兼容性。默认端口也是80和443,并且在握手阶段采用 HTTP/1.1 协议(暂时不支持 HTTP/2),因此握手时不容易屏蔽,能通过各种 HTTP 代理服务器。
(3)数据格式比较轻量,性能开销小,通信高效。
(4)可以发送文本,也可以发送二进制数据。
(5)没有同源限制,客户端可以与任意服务器通信。
(6)协议标识符是ws(如果加密,则为wss),服务器网址就是 URL。
1 | ws://example.com:80/some/path |
常见的HTTP的头部
详细可看http 面试题、参考、HTTP报头中Accept与Content-Type的区别
可以将http首部分为请求首部/响应首部,通用首部,实体首部
- 请求首部就是请求报文中独有的
- cookie:非跨域的情况下每次浏览器都会自动把cookie带上
- 和缓存相关的如If-Modified-Since、If-None-Match
- Accept系列: 定义请求结果的要求,如:
- Accept 浏览器可接收的数据格式
- Accept-Encoding 浏览器可接收的压缩算法,如gzip
- Accept-Languange 浏览器可接收的语言,如zh-CN
- Host: 目标服务器的域和端口号,如
Host:www.demo.com
。 - Referer: 发起请求的页面URI,即
Referer:${window.location.href}
- User-Agent: 客户端信息,如
1
User-Agent:Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36
- 响应首部就是响应报文中独有的,如set-cookie,和重定向相关的location
- Set-Cookie 服务端修改cookie
- ETag: 某一个固定的URI资源发生变化时,ETag会更新,如
ETag:W/"92d8a6509d07d749ee661d8af47d2fbd"
(和请求头中If-None-Match是一对) - Server: HTTP服务器的应用程序信息,如
Server:Apache/2.2.6 (Unix) PHP/5.2.5
- Location: 表示客户应当到哪里去提取文档,用于将接收端定位到资源的位置(URL)上,一般配合状态码3xx使用,重定向请求,如
Location:http://www.demo2.com/index.html
。(Location通常不是直接设置的,而是通过HttpServletResponse的sendRedirect方法,该方法同时设置状态代码为302。) - WWW-Authenticate: 告诉客户端认证方案,一般配合状态码401 Unauthorized使用,如
WWW-Authenticate:Basic realm="Usagidesign Auth"
- 通用首部表示一些通用信息,比如date表示报文创建时间
- Cache-Control: 对于缓存服务器下达缓存控制的相关指令,具体指令有
no-cache, no-store, max-age = ${秒} , public, private
等。 - Connection: 控制代理不再转发的字段,管理持久连接。
如Connection:Upgrade
,那么在经过代理后,Upgrade首部字段将不会被发送至服务器。如Connection:Keep-Alive
。 - Date: 表示HTTP报文创建时间,如
Date:Fri, 19 Oct 2018 09:45:13 GMT
。 - Pragma: 兼容HTTP1.1以前的版本,控制缓存,如
Pragma:no-cache
。 - Transfer-Encoding: 报文传输时的编码方式,HTTP1.1仅对分块传输的编码形式有效,如
Transfer-Encoding:chunked
。
- Cache-Control: 对于缓存服务器下达缓存控制的相关指令,具体指令有
- 实体首部用来描述实体部分
- Allow: 资源允许的请求方法,如
Allow:GET, HEAD
。 - Expires: 资源过期时间(绝对时间),如
Expires:Fri, 20 Oct 2018 09:45:13 GMT
。 - Last-Modified: 资源最后一次修改的时间,如
Last-Modified:Fri, 15 Oct 2018 09:45:13 GMT
。**(和请求头中的if-Modified-Since是一对)** - 还有一些表示资源具体信息的,如Content-Encoding描述主体的编码方式, Content-Type代表发送端(客户端/服务器)发送的实体数据的数据类型, Content-Language, Content-Range等。
- Allow: 资源允许的请求方法,如
http常用请求头
介绍知道的http返回的状态码
- 1xx (临时响应)表示临时响应并需要请求者继续执行操作的状态代码。
- 2xx (成功)表示成功处理了请求的状态代码。
- 3xx (重定向) 表示要完成请求,需要进一步操作。 通常,这些状态代码用来重定向。
- 4xx (请求错误) 这些状态代码表示请求可能出错,妨碍了服务器的处理。
- 5xx (服务器错误)这些状态代码表示服务器在尝试处理请求时发生内部错误。这些错误可能是服务器本身的错误,而不是请求出错。
100 Continue 继续。客户端应继续其请求
101 Switching Protocols 切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议,例如,切换到HTTP的新版本协议
200 OK 请求成功。一般用于GET与POST请求
201 Created 已创建。成功请求并创建了新的资源
202 Accepted 已接受。已经接受请求,但未处理完成
203 Non-Authoritative Information 非授权信息。请求成功。但返回的meta信息不在原始的服务器,而是一个副本
204 No Content 无内容。服务器成功处理,但未返回内容。在未更新网页的情况下,可确保浏览器继续显示当前文档
205 Reset Content 重置内容。服务器处理成功,用户终端(例如:浏览器)应重置文档视图。可通过此返回码清除浏览器的表单域
206 Partial Content 部分内容。服务器成功处理了部分GET请求
300 Multiple Choices 多种选择。请求的资源可包括多个位置,相应可返回一个资源特征与地址的列表用于用户终端(例如:浏览器)选择
301 Moved Permanently 永久移动。请求的资源已被永久的移动到新URI,返回信息会包括新的URI,浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替
302 Found 临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI
303 See Other 查看其它地址。与301类似。使用GET和POST请求查看
304 Not Modified 未修改。所请求的资源未修改,服务器返回此状态码时,不会返回任何资源。客户端通常会缓存访问过的资源,通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源
305 Use Proxy 使用代理。所请求的资源必须通过代理访问
306 Unused 已经被废弃的HTTP状态码
307 Temporary Redirect 临时重定向。与302类似。使用GET请求重定向
400 Bad Request 客户端请求的语法错误,服务器无法理解
401 Unauthorized 请求要求用户的身份认证
402 Payment Required 保留,将来使用
403 Forbidden 服务器理解请求客户端的请求,但是拒绝执行此请求
404 Not Found 服务器无法根据客户端的请求找到资源(网页)。通过此代码,网站设计人员可设置”您所请求的资源无法找到”的个性页面
405 Method Not Allowed 客户端请求中的方法被禁止
406 Not Acceptable 服务器无法根据客户端请求的内容特性完成请求
407 Proxy Authentication Required 请求要求代理的身份认证,与401类似,但请求者应当使用代理进行授权
408 Request Time-out 服务器等待客户端发送的请求时间过长,超时
409 Conflict 服务器完成客户端的PUT请求是可能返回此代码,服务器处理请求时发生了冲突
410 Gone 客户端请求的资源已经不存在。410不同于404,如果资源以前有现在被永久删除了可使用410代码,网站设计人员可通过301代码指定资源的新位置
411 Length Required 服务器无法处理客户端发送的不带Content-Length的请求信息
412 Precondition Failed 客户端请求信息的先决条件错误
413 Request Entity Too Large 由于请求的实体过大,服务器无法处理,因此拒绝请求。为防止客户端的连续请求,服务器可能会关闭连接。如果只是服务器暂时无法处理,则会包含一个Retry-After的响应信息
414 Request-URI Too Large 请求的URI过长(URI通常为网址),服务器无法处理
415 Unsupported Media Type 服务器无法处理请求附带的媒体格式
416 Requested range not satisfiable 客户端请求的范围无效
417 Expectation Failed 服务器无法满足Expect的请求头信息
500 Internal Server Error 服务器内部错误,无法完成请求
501 Not Implemented 服务器不支持请求的功能,无法完成请求
502 Bad Gateway 作为网关或者代理工作的服务器尝试执行请求时,从远程服务器接收到了一个无效的响应
503 Service Unavailable 由于超载或系统维护,服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中
504 Gateway Time-out 充当网关或代理的服务器,未及时从远端服务器获取请求
505 HTTP Version not supported 服务器不支持请求的HTTP协议的版本,无法完成处理
301和302的区别
301 Moved Permanently
: 永久移动。请求的资源已被永久的移动到新URI,返回信息会包括新的URI,浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替。除非额外指定,否则这个响应也是可缓存的。(统一资源标志符URI 和 统一资源定位符URL)302 Found
: 临时移动。与301类似。但资源只是临时被移动。由于这样的重定向是临时的,客户端应继续使用原有URI。只有在Cache-Control或Expires中进行了指定的情况下,这个响应才是可缓存的。- 字面上的区别就是301是永久重定向,而302是临时重定向。
- 301比较常用的场景是使用域名跳转。302用来做临时跳转,比如未登陆的用户访问用户中心重定向到登录页面。
状态码304和 200
- 状态码200:请求已成功,请求所希望的响应头或数据体将随此响应返回。即返回的数据为全量的数据,如果文件不通过GZIP压缩的话,文件是多大,则要有多大传输量。
- 状态码304:如果客户端发送了一个带条件的GET 请求且该请求已被允许,而文档的内容(自上次访问以来或者根据请求的条件)并没有改变,则服务器应当返回这个304状态码。即客户端和服务器端只需要传输很少的数据量来做文件的校验,如果文件没有修改过,则不需要返回全量的数据。
400和401、403状态码
- 400状态码(错误请求)服务器不理解请求的语法
- 产生原因:前端提交数据的字段名称和字段类型与后台的实体没有保持一致。前端提交到后台的数据应该是json字符串类型,但是前端没有将对象JSON.stringify转化成字符串。
- 解决方法:对照字段的名称,保持一致性。将obj对象通过JSON.stringify实现序列化
- 401状态码(未授权的请求):当前请求需要用户验证进行授权
- 403状态码(拒绝请求):服务器已经得到请求,但是拒绝执行
HTTP支持的方法
- HTTP1.0 定义了三种请求方法: GET, POST 和 HEAD方法。
- HTTP1.1 新增了六种请求方法:OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。
- 对于除GET请求以外的HTTP请求,如果存在跨域请求,浏览器必须首先使用OPTIONS方法询问服务端是否允许跨域请求,然后才发起真正的请求,OPTIONS请求称为预检请求。(这也就是为什么ajax/fetch请求存在2次HTTP请求的原因)
- 详细参考
GET和POST的区别
- GET和POST的底层都是TCP/IP,GET/POST都是TCP链接。但是由于HTTP的规定和浏览器/服务器的限制,导致他们在应用过程中体现出一些不同。
- get参数通过url传递,post放在request body中。
- GET从指定的资源请求数据,POST向指定的资源提交要被处理的数据。
- get请求在url中传递的参数是有长度限制的,而post没有。
- get比post更不安全,因为参数直接暴露在url中,所以不能用来传递敏感信息。
- get请求只能进行url编码,而post支持多种编码方式
- get请求会浏览器主动cache,而post不会,除非手动设置。
- get请求参数会被完整保留在浏览历史记录里,而post中的参数不会被保留。
- GET产生一个TCP数据包;POST产生两个TCP数据包。
- GET请求,浏览器会把http header和data一并发送出去,服务器响应200(返回数据);而POST,浏览器先发送header,服务器响应100 continue,浏览器再发送data,服务器响应200 ok(返回数据)。
一句话概括RESTFUL
用URL定位资源,用HTTP描述操作
RESTful是目前最流行的API架构风格,用于Web数据接口的设计。
RESTful的核心思想:
请求方式 + URL
的方式对资源发起命令。- 比如:
GET /user
GET 查询动作,user是被查询的对象。 - 比如:
POST /user
POST 新增动作,user是被新增的对象。
- 比如: