web5-HTTP/HTTPS

一：http 

1、http报文认识

Remote Address ：访问目标 URL 解析出来的 IP 地址， 443 ：表示当前 https 协议。

Referrer Policy : Referrer 用户指明当前请求的来源页面，对于同源的请求，会发送完整的url 作为引用地址，防盗链。

accept ：请求可以支持的响应格式列表信息

accept-encoding ：告知服务器本地浏览器支持是压缩方式

sec-fetch-dest ：期望获得什么类型的资源

sec-fetch-mode ： navigate ，表示这是一个浏览器的页面切换请求

sec-fetch-site ：表示一个请求发起的来源和目标资源来源之间的关系， cross-site：跨域请求， same-origin：同源请求。 none： 不是同源也不是跨域，请求与任意上下文无关。比如浏览器窗口中拖放一个文件

sec-fetch-user： 表示一个导航请求是否由用户激活触发（如用户主动点击鼠标、键盘）。

Sec-Fetch-User: ?0   否                Sec-Fetch-User: ?1   是

upgrade-insecure-requests :1,       浏览器告诉服务器，浏览器是可以处理https 请求的，即使访问的 https 请求中又包含了其他的 http 请求。

user-agent ：描述浏览器的信息

 

response中的属性，基本都是和request中对应上 ，在request支持的里面选择一个使用。

介绍两个：

server ：部署web应用 的容器。  openresty ：封装了 Nginx 以及第三方的类库，Lua 语言， redis 等。

vary ：accept-Encoding。指的是参考request中的accept-Encoding属性，支持的是什么格式，然后，告诉代理服务器缓存对应格式的资源（压缩、不压缩）。   代理服务器指的是，各地区的边缘服务器，如cdn，不可能所有请求都去请求主服务器。

2、http链接管理-TCP

http通信是基于tpc/ip承载的，https多了一个安全层，所以https是安全的。

 TCP就是为了建立链接，传输数据的一种管道。 一个设备可以同时有多个管道，所以TCP使用一个信封一样的东西：TCB数据结构，把每个管道的数据包起来隔离开。

TCP建立连接需要三次握手，释放连接需要四次挥手：

1、三次握手：

（ 0 ）准备工作

最开始的时候客户端和服务器都是处于 CLOSED 状态。主动打开连接的为客户端，被动打开连接的是服务器。

TCP 服务器进程先创建传输控制块 TCB ，时刻准备接受客户进程的连接请求， 此时服务器就进入了LISTEN （监听）状态。

（ 1 ）一次握手：

TCP 客户端创建传输控制块 TCB ，然后向服务器发出连接请求报文， 报文首部中的同步位SYN=1表示我要发起同步，建立连接 ，同时选择一个初始序列号 seq=x ，就是一个标识，后续需要累加 。

此时，TCP 客户端进程进入了 SYN-SENT （同步已发送状态）状态。

TCP 规定，SYN 报文段（ SYN=1 的报文段）不能携带数据，但需要消耗掉一个序号。

（ 2 ）二次握手：

TCP服务器收到请求报文后，如果同意连接，则发出确认报文：

ACK=1，表示同意并确认要建立连接（0则表示不包含确认信息）。

ack=x+1，确认号，确认的是上一条客户端发起的那个请求。

SYN=1，表示服务端也要发起同步

seq=y ，向客户端发起同步，也需要一个自己的序列号。

此时TCP 服务器进程进入了 SYN-RCVD（同步收到）状态。

（ 3 ）三次握手：

TCP 客户端收到确认后，还要向服务器给出确认。确认报文的 ACK=1 ，

ack=y+1确认的是服务端发过来的序列号 ，自己的序列号 seq=x+1 ，此时， TCP连接建立，客户端进入ESTABLISHED （已建立连接）状态。

TCP 规定， ACK 报文段可以携带数据，但是如果不携带数据则不消耗序号。

当服务器收到客户端的确认后也进入 established 状态，此后双方就可以开始 通信了。

表面上看，两次握手后即可建立连接，但是并不严谨，比如：客户端发了同步请求，由于网络或其他原因，服务端暂时没有收到，于是客户端重试又发送了一条一模一样的请求。  经过两次握手后建立了连接并传输了数据，第一次的请求恢复正常到达了服务端，于是，服务端给出了回应。 这样又会再次建立连接传输数据，造成资源开销和浪费。 

有了第三次握手后，，客户端就算收到了重试那一条的确认，但是它知道已经建立过相同的链接，就不会再进行第三次握手了。

也从另一个角度看：

第一次握手： 客户端只确认了自己的发送能力OK，，服务端只确认了自己的接受能力OK。

第二次握手：客户端确认了自己和服务端的发送能力OK、接受能力OK；  但是服务端只知道自己的接受和发送能力OK，客户端发送能力OK（服务端并不知道客户端是否接受到自己的回应）。

第三次握手：服务端和客户端，都确认了自己和对方的发送和接受能力。