HTTP 火锅【高级前端必备】

1、网络基础 TCP | IP

一般使用的网络是在 TCP | IP 协议族的基础上运做的,而 HTTP 属于其中的一个子集html

  • 协议:通讯,双方必须基于相同的方法,好比如何探测到通讯目标、由哪一边先发起通讯、使用哪一种语言进行通讯、怎样结束通讯等规则都须要事先肯定。不一样的硬件、操做系统之间的通讯等。
  • TCP | IP:是在IP协议的通讯过程当中,使用到的协议族的统称
  • TCP | IP 分层:
    • 应用层:FTP | DNS | HTTP | websocket
    • 传输层:提供可靠的字节流服务,如TCP | UDP
    • 网络层:在众多的选项中选择一条传输路线,如 IP
    • 数据链路层:网络硬件部分,包括控制操做系统、硬件的设备驱动、网卡、光纤

一、IP协议

负责把各类数据包传送给对方java

  • IP地址:指明了节点被分配到的地址
  • MAC地址:指网卡所属的固定地址
    • ARP:是一种用以解析地址的协议,根据通讯方的IP地址就能够反查出对应的MAC地址

二、TCP

采用三次握手准确无误地将数据送达目标处node

  • SYN(synchronize)
  • ACK(acknowledgement)

三、UDP

  • UDP是无链接的
  • TCP保证数据正确性,UDP可能丢包
  • TCP保证数据顺序,UDP不保证
  • TCP链接只能是点到点的,UDP支持一对一,一对多,多对一和多对多的交互通讯

四、DNS

提供域名到IP地址之间的解析服务,或逆向从IP地址反查域名的服务web

五、URI 和 URL

URI:Uniform Resource Identifier, 统一资源标识符,用字符串标识某一互联网资源面试

URL:Uniform Resource Locator,统一资源定位符,表示资源的地点(互联网上所处的位置)浏览器

URL 是 URI 的子集缓存

http://user:pass@www.example.com:80/dir/index.html?uid=1#ch1安全

协议方案名 + 登陆信息(认证)+ 服务器地址 + 服务器端口号 + 带层次的文件路径 + 查询字符串 + 片断标识符bash

2、HTTP协议格式

一、HTTP请求协议格式

<request line>          // http请求行,用来讲明请求类型(method)、要访问的资源(request-URI)以及使用的HTTP版本
<headers>               // http请求消息报头,说明服务器要使用的附加信息
<blank line>            // 回车换行
[<request-body>]        // http请求正文
复制代码
POST /index.html HTTP/1.1 # 请求报文
Host: hackr.jp  # 请求首部字段
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 16
If-Modified_Since:Thu, 12Jul 2012 07:30:00 GMT # 仅返回2012年7月12日7点30分之后更新过的index.html页面资源,若是未有内容更新,则以304 Not Modified做为响应返回

name=ueno&age=37 # 内容实体
复制代码

二、HTTP响应协议格式

<status line>          // http响应状态行,经过提供一个状态码(status code)来讲明所请求的资源状况。及缘由短语(reason-phrase)
<headers>              // http响应消息报头
<blank line>           // 回车换行
[<response-body>]      // http响应正文
复制代码
HTTP/1.1 200 OK		# 协议版本 + 状态码 + 用以解释状态码的缘由短语 
Date: Tue, 10 Jul 2012 06:50:15 GMT # 可选的响应首部字段
Content-Length: 362
Content-Type: text/html

<html> # 资源实体的主体(entity-body)

复制代码

3、HTTP 方法

一、GET

获取资源。GET提交的数据会在地址栏中显示出来。特定浏览器和服务器对URL长度有限制,例如 IE对URL长度的限制是2083字节(2K+35)。对于其余浏览器,如Netscape、FireFox等,理论上没有长度限制,其限制取决于操做系统的支持。所以对于GET提交时,传输数据就会受到URL长度的限制。服务器

二、POST

传输实体主体。因为不是经过URL传值,理论上数据不受限。但实际各个WEB服务器会规定对post提交数据大小进行限制,Apache、IIS6都有各自的配置。

三、PUT

用于传输文件,因为不带验证机制,存在安全性问题。若配合Web应用程序的验证机制,或架构设计采用REST(REpresentational State Transfer, 表征状态转移)标准的同类Web网站,可能会开放使用PUT方法。

四、HEAD

和GET方法同样,只是不返回报文主体部分,用于确认URI的有效性及资源更新的日期时间等

五、DELETE

用于删除文件,和PUT同样不带验证机制

六、OPTIONS

用来查询针对请求URI指定的资源支持的方法:Allow: GET, POST, HEAD, OPTIONS

若是不是访问特定资源而是对服务器自己发起请求,能够用一个*来代替请求URL

OPTIONS * HTTP/1.1

七、TRACE

让服务器将以前的请求通讯环回给客户端的方法,客户端经过该方法能够查询发送出去的请求是怎样被加工/篡改的。容易引起XST(Cross-Site Tracing)攻击

八、CONNECT

要求用隧道协议链接代理,主要使用SSL|TLS把通讯内容加密后经网络隧道传输

  • SSL: 安全套接层 Secure Sockets Layer
  • TLS:传输层安全 Transport Layer Security
CONNECT 代理服务器名:端口号 HTTP版本
复制代码

4、HTTP 状态码

1. 状态码类别

  • 1XX: 信息性状体码 接收的请求正在处理
  • 2XX: 成功状态码 请求正常处理完毕
  • 3XX: 重定向状态码 须要进行附加操做以完成请求
  • 4XX: 客户端错误状态码 服务器没法处理请求
  • 5XX: 服务器错误状态码 服务器处理请求出错

2. 14种常见状态码

当返回30一、30二、303,几乎全部的浏览器都会把POST改成GET,并删除请求报文内的主体,以后请求会自动从新发送

  • 200 OK: 请求被正常处理
  • 204 NO Content: 请求处理成功,但无资源可返回;在只须要从客户端往服务器发送信息,而对客户端不须要发送新信息内容的状况下使用
  • 206 Partial Content: 成功处理范围请求
  • 301 Moved Permanently: 永久性重定向,表示请求的资源已被分配了新的URI。当指定资源路径的最后忘记添加‘/’,就会返回该状态码
  • 302 Found:临时性重定向,表示请求的资源存在另外一个URI;当替代303使用时,表示客户端应当采用GET方法获取资源
  • 304 NOT Modified: 容许请求访问资源,但未知足条件(指请求首部包含If-Match,If-Modified-Since,If-None-Match, If-Range,If-Unmodified-Since),响应不包含任何响应的主体部分。和重定向没有关系
  • 400 Bad Request: 请求报文中存在语法错误,需修改请求内容后再次发送请求
  • 401 Unauthorized: 表示发送的请求须要有经过HTTP认证(BASIC认证、DIGEST认证)的认证信息。响应必须包含一个适用于被请求资源的WWW-Authenticate首部用以质询(challenge)用户信息
  • 403 Forbidden: 不容许访问那个资源
  • 404 Not Found: 服务器上没有请求的资源。也能够在服务器端拒绝请求且不想说明理由时使用
  • 500 Internal Server Error: 服务器端在执行请求时发生了错误
  • 503 Service Unavailable: 代表服务器暂时处于超负载或正在进行停机维护,没法处理请求。最好写入Retry-After首部字段再返回给客户端

5、HTTP 首部

若首部字段重复了,根据浏览器内部处理逻辑的不一样,结果可能不一致。有些会优先处理第一次出现的首部字段,有些则会优先处理最后出现的首部字段。

HTTP 要确保它的报文被正确传送、识别、提取以及适当处理:

  • 能够被正确地识别(经过Content-Type首部说明媒体格式,Content-Language首部说明语言),以便浏览器和其余客户端能正确处理内容
  • 能够被正确的解包(经过Content-Length首部和Content-Encoding首部)
  • 是最新的(经过实体验证码和缓存过时控制)
  • 符合用户的须要(基于Accept系列的内容协商首部)
  • 在网络上能够快速有效地传输(经过范围请求、差别编码以及其余数据压缩方法)
  • 完整到达、未被篡改(经过传输编码首部和Content-MD5校验和首部)

报文是箱子,实体是货物

1. 通用首部字段

  • Cache-Control: 控制缓存的行为
  • Connection:逐跳首部、链接的管理
  • Date:建立报文的日期时间
  • Pragma:报文指令
  • Trailer:报文末端的首部一览
  • Transfer-Encoding:指定报文主体的传输编码方式
  • Upgrade:升级为其余协议
  • Via:代理服务器的相关信息
  • Warning:错误通知

2. 请求首部字段

  • Accept: 用户代理可处理的媒体类型
  • Accept-Charset: 优先的字符集
  • Accept-Encoding: 优先的内容编码
  • Accept-Language: 优先的语言(天然语言)
  • Authorization: Web认证信息
  • Expect: 期待服务器的特定行为
  • From: 用户的电子邮箱地址
  • Host: 请求资源所在服务器
  • If-Match: 比较实体标记(ETag)
  • If-None-Match: 比较实体标记
  • If-Modified-Since(IMS请求): 比较资源的更新时间
  • If-Unmodified-Since: 比较资源的更新时间
  • If-Range: 资源未更新时发送实体Byte的范围请求
  • Max-Forwards: 最大传输逐跳数
  • Proxy-Authorization: 代理服务器要求客户端的认证信息
  • Range: 实体的字节范围请求
  • Referer: 对请求中URI的原始获取方
  • TE: 传输编码的优先级
  • User-Agent: HTTP客户端程序的信息

3. 响应首部字段

  • Accept-Ranges: 是否接受字节范围请求
  • Age: 推算资源建立通过时间
  • ETag: 资源的匹配信息
  • Location: 令客户端重定向至指定URI
  • Proxy-Authenticate: 代理服务器对客户端的认证信息
  • Retry-After: 对再次发起请求的时机要求
  • Server: HTTP服务器的安装信息
  • Vary: 代理服务器缓存的管理信息
  • WWW-Authenticate: 服务器对客户端的认证信息
  • Last-Modified: 最后修改日期

四、实体首部字段

  • Allow: 资源可支持的HTTP方法
  • Content-Encoding: 实体主体适用的编码方式
  • Content-Language: 实体主体的天然语言
  • Content-Length: 实体主体的大小
    • 对缓存代理服务器尤为重要,若是缓存服务器收到被截尾的报文却没有识别出截尾的话,它可能会存储不完整的内容并屡次使用它来提供服务。缓存代理服务器一般不会为没有显式Content-Length首部的HTTP主体作缓存,以此来减少缓存已截尾报文的风险。
    • 持久链接:由于链接是持久的,客户端没法依赖链接关闭来判断报文的结束。经过该首部就能够知道报文从何处开始,从何处结束。
    • 若是编码了,则显示的是编码后的主体字节长度。
  • Content-Location: 替代对应资源的URI
  • Content-MD5: 实体主体的报文摘要
    • 发送方能够在生成初始的主体时,生成一个数据的校验和,这样接收方就能够经过检查这个校验和来捕获全部意外的实体修改
    • 看成散列表的关键字,用来快速定位文档并消除没必要要的重复内容存储
    • 若是编码了,针对编码后的文档
  • Content-Range: 实体主体的位置范围
  • Content-Type: 实体主体的媒体类型(MIME类型)
    • 主媒体类型/子类型
    • 编码以前的实体主体类型
    • 支持可选的参数进一步说明内容的类型
  • Expires: 实体主体过时的日期时间
  • Last-Modified: 资源的最后修改日期时间
  • ETag: 这份文档特定实例的惟一验证码
  • Cache-Control: 应该如何缓存该文档

五、RFC4229 HTTP Header Field Registrations

  • Cookie: 请求首部字段,服务器接收到的Cookie信息
  • Set-Cookie: 响应首部字段,开始状态管理所使用的Cookie信息
    • NAME=VALUE:赋予Cookie的名称和值
    • expires=DATE: Cookie的有效期
    • path=PATH: 将服务器上的文件目录做为Cookie的适用对象(若不指定则默认为建立Cookie的服务器的域名)
    • domain=域名: 做为Cookie适用对象的域名(若不指定则默认为建立Cookie的服务器的域名)
    • Secure: 仅在HTTPS安全通讯时才会发送Cookie
    • HttpOnly: 加以限制,使Cookie不能被JavaScript脚本访问
      • 使用JS的document.cookie没法读取附加该属性后的
  • Content-Disposition

六、逐跳首部(Hop-by-hop Header)

  • Connection
  • Keep-Alive
  • Proxy-Authenticate
  • Proxy-Authorization
  • Trailer
  • TE
  • Transfer-Encoding
  • Upgrade

七、端到端首部(End-to-end Header)

除了8个逐跳首部外,其余全部字段都属于端到端首部

八、其余首部字段:HTTP首部字段是能够自行拓展的

  • X-Frame-Options:防止点击劫持攻击
    • DENY: 拒绝
    • SAMEORIGIN:仅同源域名下的页面匹配时许可
  • X-XSS-Protection:防止跨站脚本攻击,用于控制浏览器XSS防御机制的开关
    • 0: 将XSS过滤设置成无效状态
    • 1: 将XSS过滤设置成有效状态
  • DNT:拒绝我的信息被收集

6、HTTP 的缺点

  • 通讯使用明文(不加密),内容可能会被窃听
  • 不验证通讯方的身份,所以有可能遭遇假装
  • 没法证实报文的完整性,因此有可能已遭篡改

7、HTTPS

HTTPS = 数据加密 + 网站认证 + 完整性验证 + HTTP

  • 经过证书等信息确认网站的真实性
  • 创建加密的信息通道
  • 数据内容的完整性

CA中心发布的数字证书经过对称加密和非对称加密对咱们网上传输的信息进行加密。端口号:443

  • 对称加密:加密和解密使用同一个密钥
  • 非对称加密:
    • 公钥加密:发给查看网站的全部人
    • 私钥解密:只有网站服务器本身拥有

8、HTTP 2.0 的优点

  • 采用二进制格式传输数据,而非 HTTP1.1 的文本格式,二进制格式在协议的解析和优化拓展上带来更多的优点和可能;

  • 对消息头采用 HPACK 进行压缩传输,可以节省消息头占用的网络流量,而 HTTP1.1 每次都会携带大量冗余头信息,浪费带宽,头压缩可以很好的解决该问题;

  • 多路复用,就是多个请求都经过一个 TCP 链接并发完成,HTTP1.1 虽然经过 pipeline 也能并发请求,可是多个请求之间的响应会被阻塞的,因此 pipeline 至今也没有被普及应用,而 HTTP2.0 作到了真正的并发请求,同时,流还支持优先级和流量控制;

  • Server Push, 服务端可以更快的把资源推送给客户端,例如服务端能够主动把 JS 和 CSS 文件推送给客户端,而不须要客户端解析 HTML; 再发送这些请求,当客户端须要的时候,它已经在客户端了。

9、WebSocket

websocket 是 HTML5 提出的一套补缺 HTTP 连接中不能持久连接的协议。

HTTP协议创建的“长链接”是“伪长链接”,只是靠服务器不断循环实现了所谓的长链接效果。在链接后的过程当中,服务器都会不停的连接与断开,数据头信息不停重复的发送,浪费宽带,信息交换的效率低下。

websocket服务器主动推送,只要有数据就推送到请求方。

  • WS使用HTTP来创建链接,可是定义了一系列新的header域,这些域在HTTP中并不会使用。

  • WS的链接不能经过中间人来转发,它必须是一个直接链接。

  • WS链接创建以后,通讯双方均可以在任什么时候刻向另外一方发送数据。

  • WS链接创建以后,数据的传输使用帧来传递,再也不须要Request消息。

  • WS的数据帧有序

基于 Node.js 编写的一个 Socket.IO 是一个开源实现WebSocket的库,它经过node.js实现服务端的同时,也提供了客户端js库,socket.io支持事件触发为基础进行的双向数据通讯

10、面试题

Etag 的值是服务端对文件的索引节、大小和最后修改时间进行 Hash 后获得的

有了 Last-Modified, 为何还要用 Etag?

  • 若是在1S以内对一个文件进行两次更改,Last-Modified 就会不正确
  • 某些服务器不能精确的获得文件的最后修改时间
  • 一些文件也许会周期性的更改,可是内容并无改变(仅仅改变的是修改时间),这个时候咱们并不但愿客户端认为这个文件被修改了,而从新GET
  • 即有时候 Etag 能够弥补 Last-Modified 的判断缺陷

有了 Etag, 为何还要用 Last-Modified?

  • 有时候 Last-Modified 能够弥补 ETag 判断的缺陷,好比一些图片等静态文件的修改,若是每次扫描内容都生成 ETag 来比较,显然要比直接比较修改时间慢不少。
相关文章
相关标签/搜索