nginx(六十九)nginx配置websocket

1) 默认 proxy_http_version 1.0,而'websocket'是建立在'1.1'的基础

2) nginx默认'不会'为客户端'转发'Upgrade、Connection标头

   proxy_set_header Upgrade $http_upgrade;
   proxy_set_header Connection "upgrade";

1) 这一机制允许将一个'已建立的连接'升级成'新的、不相容'的协议

2) 通常来说这一机制总是由'客户端'发起的,'服务端'可以选择'是否'要升级到新协议 -->'支持与否'

   例外：也可以'由服务端发起'升级到传输层安全协议'TLS'

3) 借助这一技术,连接可以以'常用的协议启动(如HTTP/1.1)',随后再升级到HTTP2甚至是WebSocket

注意：HTTP/2 '明确禁止'使用此机制，这个机制'只属于HTTP/1.1'

1) 当客户端'试图升级'到一个'新的协议'时,可以先发送一个'普通http1.1 GET'请求

备注： '新协议'可以为'http2、websocket'

2) 不过这个请求需要进行'特殊配置[添加两项额外的header]'以包含升级请求

  Connection: Upgrade #设置 Connection 头的值为 "Upgrade" 来指示这是一个'升级'请求

  Upgrade: protocols  #Upgrade 头指定'一项或多项'协议名,按'优先级'排序,以'逗号'分隔

3) 如果'服务器决定升级'这次连接

  [1]、就会返回一个 '101 Switching Protocols' 响应状态码

  [2]、和一个'要切换到'的协议的头部字段Upgrade

4) 如果服务器'没有或者不能升级'这次连接

  [1]、它会'忽略'客户端发送的 "Upgrade" 头部字段

  [2]、返回一个'常规'的HTTP响应

5) 服务在发送 101 状态码之后,就可以'使用新'的协议，并可以根据需要执行任何其他协议指定的握手

备注：实际上,一旦'升级完成'了,连接就变成了'双向'管道,并且可以通过新协议完成启动升级的请求

6) 由HTTP/1.1请求建立的连接可以'升级为HTTP/2协议'的连接,但是反过来'不'可以

备注1： 事实上'HTTP/2'已经'不再支持101状态码'了,也'不再支持'任何连接升级机制

备注2： websocket是'HTTP1.1'独有的

1) Connection: Upgrade: 这个头部是'给 proxy(nginx)' 看的,指示这是一个'升级'请求

2) Upgrade: websocket : 浏览器想要升级到WebSocket协议,这个头是给最终'处理请求'程序看的

备注：也会升级为 'http2'协议

细节：

  [1]、如果只有 Upgrade: websocket,而'没有' Connection: Upgrade

  [2]、则 proxy '不知道'要升级为 websocket,会默认视为'普通HTTP'请求

1) 在'HTTP/1.1'中,正式'标准化'了Connection头部：

2) Connection头部一般表示'哪些头部'是属于逐跳头部的,'不应'当被代理原样'传递'给upstream

例外：close表示会话'不持久化[HTTP1.0默认]',keep-alive表示会话支持'持久化[HTTP1.1默认]'

3) '逐跳头部'（hop-by-hop header）

 [1]、用来描述'当前浏览器(client)与直连服务器',比如nginx反向代理的'连接'信息

 [2]、比如Keep-Alive头部,仅仅表示'浏览器尝试和nginx'之间连接持久化

 [3]、而'不管'nginx和后端服务器之间的连接

 [4]、proxy要处理这些头部,并'按照自己的需要'来'修改'这些头部​

重点: 如果要'使用Hop-by-hop'首部，需提供'Connection'首部字段,值为对应的'hop-by-hop'头

4) 解答: 为什么客户端'原始请求'有 Upgrade和Connection? nginx还会设置proxy_set_header

 [1]、因为'Connection和Upgrade'是'hop-by-hop header',无法传递给'upstream'

 [2]、proxy和upstream也必须通过'Connection和Upgrade'进行协议升级转换才能完成整个链路

+++++++++ '默认'的逐条头部如下 +++++++++ 

代理'处理'原则： 

  1) 当在请求中遇到这些指定'标头'

  2) proxy会处理这些特定的'表头',并且是'不会自动'将其转发到后端节点 --> '路由的下一条'

1) '其他的头部'都是端到'端头部 end-to-end header'

 [1]、用来描述这个'浏览器和最终处理请求的服务器(上游服务器)'之间的信息

 [2]、比如A***ept头部,表示客户端'想从后端服务器'得到的数据类型,而和中间的proxy'nginx'无关

 [3]、proxy默认'不能修改'这些头部

2) 再回到HTTP 1.1的Connection头部，这儿有一个'兼容性'问题,以'Upgrade'头部为例

 [1]、某个proxy'[nginx]默认'实现了'HTTP 1.0'协议,将Upgrade'原样转发'给后端

 [2]、后端和proxy'升级'协议,但是这个情况下,'proxy不认识'升级后的协议

 [3]、所以'RFC'有增加了一条规定：

 如果'只有Upgrade: xxx',而没有Connection: Upgrade,那么就'当作普通HTTP请求'来处理