HTTPS协议
由于 HTTP 天生“明文”的特点，整个传输过程完全透明，任何人都能 够在链路中截获、修改或者伪造请求 / 响应报文，数据不具有可信性。因此诞生了为安全而生的HTTPS协议
使用HTTPS时，所有的HTTP请求和响应在发送到网络之前，都要进行 加密。
SSL/TLS
主流的三个 版本
006 年的 1.1、2008 年的 1.2 ，2018的 1.3，
都紧跟密码学的发展和互联网的现状，持续强化安全和性能
摘要算法
加密算法
对称密钥加密算法
编、解码使用相同密钥的算法，如（AES， RC4,ChaCha20 ）
非对称密钥加密算法
如 （DH、DSA、RSA、ECC ）
身份验证
数字证书
CA信息
公钥用户信息
公钥
权威机构的签名
有效期
作用
1.通过数字证书向浏览器证明身份
2.数字证书里面包含了公钥
知名的 CA
如 DigiCert、VeriSign、Entrust、 Let’s Encrypt 等
一个HTTP请求的分层解析流程
应用层
首先我们应用层的浏览器决定向 DNS 服务器请求解析域名「www.baidu.com」，那么就要遵循 DNS 协议
浏览器将 DNS 请求报文封装好推入套接字，开始我们的 DNS 解析过程
拿到 DNS 服务器的响应报文，运输层拆开数据报，得到该报文的目的 IP 地址和目的端口号，于是对应着去找套接字交付报文即可。
浏览器封装 HTTP 请求报文，然后创建一个 TCP 套接字，采用四元组标识，具体为「源 IP 地址：192.168.43.138」+「源端口号：随机的，这里假设为 1234」+「目的 IP 地址：172.194.72.105」+「目的端口号：80」
紧接着，这个报文会被推进 TCP 套接字中，等待运输层来收取
运输层
运输层收取了报文，并判断与目的主机是否建立了 TCP 连接，这里假设没有
运输层将不急着发送应用层数据，得先判断与目的主机之间能够正常通讯，也就是需要『握手』打招呼
一切准备就绪之后，运输层将应用层发过来的数据报又一层封装，添加进『源端口号』和『目的端口号』以及相关差错检验字段。
最后将 TCP 数据报向下传递到网络层
网络层
网络层其实很简单，拿到数据报并封装成 IP 数据报，即在原 TCP 报文的前提之上添加『源 IP 地址』和『目的 IP 地址』等字段信息。
然后交由数据链路层。
链路层<br>
数据链路层拿到 IP 数据报，它需要封装成以太网帧才能在网络中传输，也就是它需要目的主机的 Mac 地址，然而我们只知道目的主机的 IP 地址。
链路层有一个 ARP 协议，直接或间接的能够根据目的 IP 地址获得使用该 IP 地址的主机 Mac 地址。
网关路由由于具有转发表和路由选择算法，所以它知道目的网络该怎么到达，所以一路转发，最终会发送到目的网络的网关路由上。
最后，目的网络的网关路由同样会经由 ARP 协议，取得目的主机的 Mac 地址，然后广播发送，最后被目的主机接受。
这样服务器就接受到一个 HTTP 请求，于是它解析这个请求，确定该请求的动作是什么，也就是它需要什么东西，并构建响应报文，以同样的方式从网络到达源主机。
HTTP协议
超文本传输协议
无状态的
以请求/应答方式运行的协议
HTTP报文格式
起始行（start line）:消息正文（entity）
头部字段集合（header）:使用 key-value 形式更详细地说明报文
消息正文（entity）:实际传输的数据，它不一定是纯文本，可以是图片、视频 等二进制数据
请求行报文格式
请求方法：如 GET/HEAD/PUT/POST，表示对资源的操作
请求目标：通常是一个 URI，标记了请求方法要操作的资源
版本号：表示报文使用的 HTTP 协议版本
响应行报文格式
版本号：表示报文使用的 HTTP 协议版本
状态码：一个三位数，用代码的形式表示处理的结果，比如 200 是成功，500 是服务器错误
原因：作为数字状态码补充，是更详细的解释文字，帮助人理解原因
HTTP 头字段
头部字段是 key-value 的形式，key 和 value 之间用“:”分隔；例如“Content-type: application/json”
可添加自定义头
注意事项
字段名不区分大小写
字段名里不允许出现空格
可以使用连字符“-”，但不 能使用下划线“_”
字段名后面必须紧接 着“:”，不能有空格，而“:”后的字段值前可以有多个空格
字段的顺序是没有意义的，可以任意排列不影响语义
字段原则上不能重复，除非这个字段本身的语义允许，例如 Set-Cookie
常用头字段
请求字段
从客户端向服务器发送请求报文时使用的首部，补充了请求的附加内容、客户端信息、响应内容相关优先级等信息。
响应字段
从服务器端向客户端返回响应报文时使用的首部，补充了响应时的附加内容，也会要求客户端附加额外的内容信息。
实体字段
针对请求报文和响应报文的实体部分使用到的首部，补充了资源内容更新时间等与实体有关的信息。
TCP协议
定义：面向连接的，可靠的，基于字节流的传输层通信协议
特点
基于连接的：数据传输之前需要建立连接
全双工的：双向传输
字节流：不限制数据大小，打包成报文段，保证有序接收，重复报文自动丢弃
流量缓冲：解决双方处理能力的不匹配
可靠的传输服务：保证可达，丢包时通过重发机制实现可靠性
拥塞控制：防止网络出现恶性拥塞
连接管理
四元组
源地址， 源端口， 目的地址， 目的端口
报文格式
TCP三次握手
TCP 的三次握手就是为了确保通讯双方能够稳定的建立连接并完成数据报文的请求与响应动作
步骤
第一步：<br>客户端向服务端发送一份特殊的 TCP 报文，该报文并不包含应用层的数据，是一份特殊的报文，它的 TCP 首部中 SYN 字段值为1。<br>除此之外，客户端还会随机生成一个初始序号，填在报文的「序号」字段，代表当前报文的序号是这个，并且我后续的分组会基于这个序号递增。<br>然后该报文将会经网络层、链路层、物理层发送到服务端<br>
第二步：<br>如果分组丢失了，那么客户端会经过某个时间间隔再次尝试发送。<br>而如果分组准确的到达服务端了，服务端拆开 TCP 首部会看到，这是一个特殊的 SYN 握手报文，于是为此次连接分配缓存等资源。<br>接着服务端开始构建响应报文，SYN 是一个用于同步需要的字段，响应报文中依然会被置为 1，并且服务端也将随机生成一个初始序号放置的响应报文的序号字段中。<br>最后，服务端还会为响应报文中的确认字段赋值，这个值就是客户端发过来的那个序号值加一。<br>整体上的意思就是说，「我同意你的连接请求，我的初始序号为 xxx，你的初始序号我收到了，我等着你的下一个分组到来」<br>
第三步：<br>客户端收到服务端的响应报文，于是分配客户端 TCP 连接所必须的缓存等资源，于是连接已经建立。<br>实际上从第三步开始，客户端就可以携带应用层数据向服务端交换报文了，以后的每份报文中，SYN 都为 0，因为它只是用于同步初始序号的，这一点需要明确。
TCP四次挥手
因为一条 TCP 连接会消耗大量的主机资源
因为 TCP 是『全双工通信』
服务端需要分配各种缓存资源
户端也同样需要分配相应资源
数据可靠性传输
滑动窗口（回退N步）
发送方的窗口，灰色表示已经被确认的报文，黄色表示已发送但未被确认的报文，绿色表示下一个待发送的报文，白色表示不可用的报文。
这是我们假设服务端已经收到 6、7 两份报文，但是它上一次向上交付给应用层的是 4 号报文，也就是说它在等 5 号报文，所以它暂时会将 6、7 两个报文缓存起来，等到 5 号报文来了一并交付给应用层。
现在 5 号报文由于超时被重传了，终于到达目的地了，如愿以偿，服务端向上交付 5、6、7 三份报文，并返回一份确认报文，ACK = 8，表示序号 8 以前的所有报文都收到了。
当发送端收到这份确认报文后，5、6、7 变成灰色，窗口向前移动三个单位长度。
TCP 是没有否定确认的，所以如果服务端连续响应的多份报文是对同一序号的确认，那很有可能该序号以后的某个报文丢失。<br>如果服务端发送多个对分组 5 的 ACK 确认，那说明什么？说明目前我服务端完整的向上交付的序号是 5 号，后续的报文我没收到，你最好重新发一下别等待超时了。<br>
控制发送流量
丢包即拥塞，需要降低发送效率，而每一次收到确认数据报即认为网络通畅，会增加发送效率
算法<br>
慢启动
刚开始缓慢的发送，比如某个时间段内只发送一次数据报，当收到确认报文后，下一次同样的时间间隔内，将发送两倍速率的两份数据报，并以此类推
短时间内，一个 TCP 连接的发送方将以指数级增长，但一旦出现丢包，即收到冗余的 ACK 确认，或者对于一个包的确认 ACK 始终没收到而不得不启动一次超时重传，那么发送方认为「网络是拥塞的」
那么一旦出现发送端超时丢包，注意这里是超时，将发送速率置为一并重新进入慢启动状态，阈值就是当前发送效率的一半。
之后的发送方的发送效率一样会以指数级增长，但是不同于第一次，这次一旦达到这个阈值，TCP 将进入『拥塞避免』模式，该模式下的发送效率将不再指数级增长，会谨慎的增长。
拥塞避免
每个往返时间段发送的所有数据报全部得到确认后，下一次就增加一个分组的发送，这样缓慢的增长效率是谨慎的。
而如果是服务端返回多个冗余 ACK 以明确你丢包，TCP 认为这不是严重的，对于这种情况，TCP 减半当前发送效率并进入快速恢复阶段。
快速恢复
收到几个冗余的 ACK 就增加几个分组的发送效率，就是说，你服务端不是没收到我的几个报文吗，这两次发送我提升速率迅速发给你。
当这期间出现了由发送端超时导致的丢包，同样的处理方式，初始化发送速率为一并减半当前发送效率作为阈值，进入慢启动阶段。
当然，如果这期间收到了对丢失报文的确认，那么将适当降低发送效率并进入拥塞避免状态。
