网络分层模型

OSI七层模型
- 应用层：为计算机用户提供服务
- 表示层：数据处理(编解码、加密解密、压缩解压缩)
- 会话层：管理(建立、维护、重连)应用程序之间的会话
- 传输层：为两台主机进程之间的通信提供通用的数据传输服务
- 网络层：路由和寻址
- 数据链路层：帧编码和误差纠正控制
- 物理层：透明地传送比特流
TCP/IP四层模型
- 应用层
- 传输层
- 网络层
- 网络接口层

从输入URL到页面展示到底发生了什么

浏览器查找域名的IP地址
浏览器向Web服务器发送HTTP请求
Web服务器处理请求
服务器发回一个HTML响应
浏览器显示HTML
具体一些：
- 使用DNS协议获取域名对应的IP
- 使用TCP协议建立与服务器的连接
- 使用OSPF在路由之间寻址
- 使用ARP协议将IP地址转换成MAC地址
- TCP连接建立后，使用HTTP协议访问网页

常用的HTTP状态码

1xx：传递信息，表明请求正在处理
2xx：成功状态码，请求正常处理
- 200
- 201
- 202
- 204
3xx：重定向状态码
- 301
- 302
4xx：客户端错误，服务器无法处理请求
- 400
- 401
- 403
- 404
- 409
5xx：服务器错误，服务器处理请求出错
- 500
- 502

HTTPS与HTTP的区别？

SSL/TLS：
- SSL/TLS 的工作原理
内容对称加密，加密的密钥为非对称加密

HTTP/1.0 vs HTTP/1.1

连接方式：长短
状态响应码：206 409 410
缓存机制
带宽：允许部分请求
Host头：允许在同一HTTP上托管多个域名

HTTP/1.1 vs HTTP/2.0

多路复用：不同请求共用一个连接
二进制帧
头部压缩：HPACK
服务器推送：在服务器请求一个资源的时候，将其他资源一并推送

HTTP/2.0 vs HTTP/3.0

传输协议：QUIC(基于UDP实现SSL/TLS相似的安全性)

HTTP无状态，如何保存用户的状态？

使用Session，第一次请求会返回SessionID，接下来的请求都需要带有SessionID（附带在Cookie中）
Cookie被禁用：将SessionID直接附加于URL路径后

GET和POST区别：

WebSocket：持久性连接，基于SSL/TLS TCP

建立过程：
- HTTP升级
- …

全双工？半双工？

TCP vs UDP

建立连接？
传输可靠性？
传输状态？
效率？
传输数据形式？
头部开销，空间占用？
广播或多播？
用途？

TCP三次握手和四次挥手？

Client:
- SYN_SENT、FIN_WAIT1、FIN_WAIT2、TIME_WAIT
Server:
- SYN_RECV、CLOSE_WAIT、CLOSED

TCP如何保持传输可靠性？

基于数据块
给数据包编号，排序，去重
检验和
重传机制
- 超时
- 立即
- SACK-Server发送，获取收到的报文段
- D-SACK
流量控制
- 滑动窗口，避免发送方发的太快，接收方接受不过来导致的数据丢弃
拥塞控制
- 拥塞窗口
- 慢开始、拥塞避免、快重传、快恢复

AQS自动重传协议：

停止等待
- 无差错情况：一收一确认
- 存在差错：超时重传
  - 确认丢失
  - 确认迟到
连续ARQ

RTT、RTO、MSL

HTTP

HTTP常见的状态码：

1xx 协议处理中间状态，还需后续操作
2xx 成功，报文收到，并正确处理
- 200 OK ，一切正常，如果是非HEAD请求，服务器返回的响应头都会有body数据
- 204 NO CONTENT 一切正常，响应头无Body数据
- 206 Partial Content 用于HTTP分块下载或断点续传，表示响应返回的body数据不是资源的全部，而是一部分
3xx 重定向，资源位置发生变动，需要客户端重新请求
- 301 Moved permanently 永久重定向，请求的资源不在，需要用新的URL再次访问
- 302 Found 临时重定向，请求的资源还在，暂时需要另一个URL访问
  - 301 302 在响应头中的Location字段，指明了后续要跳转的URL
- 304 Not Modified 不跳转，表示资源未修改，重定向缓存文件
4xx 客户端错误，请求报文有误，服务器无法处理
- 400 Bad Request 客户端请求报文有误
- 403 Forbidden 服务器禁止访问资源
- 404 Not Found 请求的资源在服务器上找不到
5xx 服务器错误，服务器在处理请求时内部发生了错误
- 500 Internal Server Error 笼统的错误码，表示服务器出错
- 501 Not Implemented 客户端请求的功能还不支持
- 502 Bad Gateway 服务器作为网关或者代理时返回的错误码，服务器工作正常，访问后端时发生错误
- 503 Service Unavailable 服务器当前忙，无法响应客户端

HTTP常见字段

Host：发送请求，指定服务器的域名
Content-Length：本次回复的数据长度，作为HTTP body的边界，搭配回车符、换行符作为HTTP header的边界，用于解决粘包问题
Connection：客户端要求服务器使用 HTTP长连接，指定值为 Keep-Alive
Content-Type：用于服务器回应，告诉客户端，本次数据是什么格式
Accept：用于请求，表示自己接受哪些数据格式
Content-Encoding：表明服务器返回的数据使用了什么压缩格式
Accept-Encoding：说明自己可以接收哪些压缩方法

安全和幂等

在 HTTP 协议里，所谓的「安全」是指请求方法不会「破坏」服务器上的资源
所谓的「幂等」，意思是多次执行相同的操作，结果都是「相同」的

HTTP缓存实现方式：

强制缓存
- 只要缓存未过期，就直接使用浏览器本地缓存，浏览器主动决定
- 实现方式：
  - Cache-Control：相对过期时间（优先级高）
  - Expires：绝对过期时间
协商缓存
- 客户端与服务器协商后，通过协商结果判断是否使用本地缓存
- 实现方式：
  - 第一种
    - 请求头 if-Modified-Since，资源过期后，带上Last-Modified的值，用于服务器判断资源是否被修改
    - 响应头 Last-Modified，资源最后修改时间
  - 第二种
    - 请求头 if-None-Match：资源过期，该头带上Etag值，用于服务器判断资源是否过期
    - 响应头 Etag：唯一标识响应资源
  - Etag优先级高于Last-Modified
    - 即便没有修改文件，文件的最后修改日期也可能变
    - 有些文件是以秒为单位修改的，if-Modified-Since只能检测秒为单位的修改，Etag可以检测一秒内的多次修改
    - 有些服务器不能精确获取修改时间
- 协商缓存需要配合Cache-Control来使用，只有未命中强制缓存，才使用协商缓存

HTTP特点

简单
易于拓展
跨平台
缺点
- 无状态
- 明文传输
- 不安全
HTTP 1.1
- 长连接
- 管道网络传输
  - 解决了请求的队头阻塞，但没有解决响应的队头阻塞
- 队头阻塞
  - 服务端响应一个请求被阻塞，后端排队的所有请求也一同被阻塞

HTTP和HTTPS区别

TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议，使得报文能够加密传输
**还需进行 **SSL/TLS 的握手过程，才可进入加密报文传输
HTTP 默认端口号是 80，HTTPS 默认端口号是 443
HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的

HTTP问题

窃听风险
- 信息加密
  - 混合加密的方式实现信息的机密性
篡改风险
- 检验机制
  - 摘要算法的方式来实现完整性，它能够为数据生成独一无二的「指纹」，指纹用于校验数据的完整性，解决了篡改的风险
冒充风险
- 身份证书
  - 将服务器公钥放入到数字证书中，解决了冒充的风险

混合加密

在通信建立前使用非对称加密的方式交换会话密钥，后续不再使用非对称加密
- 公钥和私钥，公钥可以任意分发，私钥保密，解决了密钥交换问题但速度慢
通信过程中使用对称加密的会话密钥，加密明文数据
- 运算速度快，无法做到安全的密钥交换

摘要算法和数字签名

使用摘要算法(哈希函数)计算出内容的哈希值，哈希值是唯一的，且无法通过哈希值推导出内容
- 只能保证内容不会被篡改，但是不能保证内容不能被替换
非对称加密
- 公钥和私钥，这两个密钥可以双向加解密
  - 公钥加密，私钥解密，保证传输内容的安全
  - 私钥加密，公钥解密，保证消息不会被冒充，如果公钥能正常解密出私钥加密的内容，就可以证明这个消息是持有私钥身份的人发送的
    - 私钥加密不是对内容加密，而是对内容的哈希值加密

数字证书

数字证书认证机构(CA)，用自己的私钥，对服务器公钥做数字签名，将 个人信息 + 公钥 + 数字签名 打包为数字证书
拿到服务器的数字证书后，会根据CA的公钥解密证书的签名，得到公钥，和数字证书的公钥对比，来判断数字证书是否合法

SSL/TLS协议基本流程

客户端要服务器索要并验证服务器的公钥
双方协商产生会话密钥
- 前两部就是TLS/SSL的握手阶段，常用的密钥交换算法有RSA算法和ECODE算法
双方采用会话密钥进行加密通讯

TLS/SSL的握手阶段

ClientHello
ServerHello
客户端回应
服务器最后回应

数字证书

公钥
持有者信息
CA信息
CA对这份文件的数字签名以及使用的算法
证书有效期
额外信息
证书签发过程
- CA将持有者的公钥、用途、颁发者、有效时间打包、对这些信息进行Hash计算，得到一个Hash值
- CA用自己的私钥将该Hash加密，生成Certificate Signature，也就是签名
- 将Certificate Signature添加到文件证书上，形成数字证书
证书检验过程
- 使用同样的Hash算法获取该证书的Hash值H1
- 用系统或者浏览器集成的CA公钥解密Certificate Signature的内容，得到Hash值H2
- 比较H1和H2如果值相同，则为可信赖证书，否则认为证书不可信

RSA握手过程

Client Hello 第一次握手
- 客户端向服务器发送TLS版本号、支持的密码套件列表、生成的随机数**(Client Random)
Server Hello 第二次握手
- 确认TLS版本号是否支持，从密码套件中选择一个，生成一个随机数**(Server Random)
  - 密码套件的组成：密钥交换算法+签名算法+对称加密算法+摘要算法
- 发送Server Certificate 给客户端，该消息包含数字证书
- 发送Server Hello Done，告知本次打招呼完毕
第三次握手
- 客户端生成一个随机数(pre-master)，用服务器RSA*公钥加密该随机数，通过*Client Key Exchange消息传给服务器
- 用Client Random、Server Random、pre-master生成会话密钥（master secret）后，客户端发送一个Change Cipher Spec 告诉服务端开始使用加密方式发送消息
- 客户端在发送一个Encrypted Handshake Message（Finished****）把之前发送的数据做个摘要，使用会话密钥master secret加密，让服务器做验证，验证加密通信是否可以，之前的握手信息是否被篡改过
第四次握手
- 服务器发送 Change Cipher Spec 和 Encrypted HandShake Message消息，如果双方都验证加密和解密没问题，握手正式完成
缺陷：
- 不支持前向加密
  - 一旦服务端的私钥泄漏了，过去被第三方截获的所有 TLS 通信密文都会被破解。

Linux 接收和发送网络包的流程

Linux接收网络包

当网卡接收到一个网络包后，会通过 DMA 技术，将网络包写入到指定的内存地址，也就是写入到 Ring Buffer ，这个是一个环形缓冲区，接着就会告诉操作系统这个网络包已经到达

那应该怎么告诉操作系统这个网络包已经到达了呢？

最简单的一种方式就是触发中断，也就是每当网卡收到一个网络包，就触发一个中断告诉操作系统
- 这存在一个问题，在高性能网络场景下，网络包的数量会非常多，那么就会触发非常多的中断
- 解决方式：
  - NAPI 机制：
    - 核心概念就是不采用中断的方式读取数据，而是首先采用中断唤醒数据接收的服务程序，然后 poll 的方法来轮询数据
当有网络包到达时，会通过 DMA 技术，将网络包写入到指定的内存地址
接着网卡向 CPU 发起硬件中断，当 CPU 收到硬件中断请求后，根据中断表，调用已经注册的中断处理函数
硬件中断处理函数：
- 需要先「暂时屏蔽中断」，表示已经知道内存中有数据了，告诉网卡下次再收到数据包直接写内存就可以了，不要再通知 CPU了，这样可以提高效率，避免 CPU 不停的被中断
- 接着，发起「软中断」，然后恢复刚才屏蔽的中断
软中断
- 内核中的 ksoftirqd 线程专门负责软中断的处理，当 ksoftirqd 内核线程收到软中断后，就会来轮询处理数据。
- ksoftirqd 线程会从 Ring Buffer 中获取一个数据帧，用 sk_buff 表示，从而可以作为一个网络包交给网络协议栈进行逐层处理
网络协议栈
- 首先，会进入到网络接口层，在这一层会检查报文的合法性，如果不合法则丢弃，合法则会找出该网络包的上层协议的类型，比如是 IPv4，还是 IPv6，接着再去掉帧头和帧尾，然后交给网络层
- 到了网络层，则取出 IP 包，判断网络包下一步的走向，比如是交给上层处理还是转发出去。当确认这个网络包要发送给本机后，就会从 IP 头里看看上一层协议的类型是 TCP 还是 UDP，接着去掉 IP 头，然后交给传输层
- 传输层取出 TCP 头或 UDP 头，根据四元组「源 IP、源端口、目的 IP、目的端口」作为标识，找出对应的 Socket，并把数据放到 Socket 的接收缓冲区
- 最后，应用层程序调用 Socket 接口，将内核的 Socket 接收缓冲区的数据「拷贝」到应用层的缓冲区，然后唤醒用户进程

Linux 发送网络包的流程

发送网络包的流程正好和接收流程相反

首先，应用程序会调用 Socket 发送数据包的接口，由于这个是系统调用，所以会从用户态陷入到内核态中的 Socket 层
- 内核会申请一个内核态的 sk_buff 内存，将用户待发送的数据拷贝到 sk_buff 内存，并将其加入到发送缓冲区
接下来，网络协议栈从 Socket 发送缓冲区中取出 sk_buff，并按照 TCP/IP 协议栈从上到下逐层处理
- TCP 传输协议
  - 先拷贝一个新的 sk_buff 副本，这是因为 sk_buff 后续在调用网络层，最后到达网卡发送完成的时候，这个 sk_buff 会被释放掉。而 TCP 协议是支持丢失重传的
    - 在收到对方的 ACK 之前，这个 sk_buff 不能被删除。所以内核的做法就是每次调用网卡发送的时候，实际上传递出去的是 sk_buff 的一个拷贝，等收到 ACK 再真正删除
接着，对 sk_buff 填充 TCP 头。这里提一下，sk_buff 可以表示各个层的数据包，在应用层数据包叫 data，在 TCP 层我们称为 segment，在 IP 层我们叫 packet，在数据链路层称为 frame
- 为了在层级之间传递数据时，不发生拷贝，只用 sk_buff 一个结构体来描述所有的网络包
- 通过调整 sk_buff 中 data 的指针
  - 当接收报文时，从网卡驱动开始，通过协议栈层层往上传送数据报，通过增加 skb->data 的值，来逐步剥离协议首部
  - 当要发送报文时，创建 sk_buff 结构体，数据缓存区的头部预留足够的空间，用来填充各层首部，在经过各下层协议时，通过减少 skb->data 的值来增加协议首部
然后交给网络层，在网络层里会做这些工作：选取路由（确认下一跳的 IP）、填充 IP 头、netfilter 过滤、对超过 MTU 大小的数据包进行分片
- 网络接口层会通过 ARP 协议获得下一跳的 MAC 地址，然后对 sk_buff 填充帧头和帧尾，接着将 sk_buff 放到网卡的发送队列中
这些工作准备好后，会触发「软中断」告诉网卡驱动程序，这里有新的网络包需要发送，驱动程序会从发送队列中读取 sk_buff，将这个 sk_buff 挂到 RingBuffer 中，接着将 sk_buff 数据映射到网卡可访问的内存 DMA 区域，最后触发真实的发送
当发送完成的时候，网卡设备会触发一个硬中断来释放内存，主要是释放 sk_buff 内存和清理 RingBuffer 内存
最后，当收到这个 TCP 报文的 ACK 应答时，传输层就会释放原始的 sk_buff

发送网络数据的时候，涉及几次内存拷贝操作？

第一次，调用发送数据的系统调用的时候，内核会申请一个内核态的 sk_buff 内存，将用户待发送的数据拷贝到 sk_buff 内存，并将其加入到发送缓冲区
第二次，在使用 TCP 传输协议的情况下，从传输层进入网络层的时候，每一个 sk_buff 都会被克隆一个新的副本出来。副本 sk_buff 会被送往网络层，等它发送完的时候就会释放掉，然后原始的 sk_buff 还保留在传输层，目的是为了实现 TCP 的可靠传输，等收到这个数据包的 ACK 时，才会释放原始的 sk_buff
当 IP 层发现 sk_buff 大于 MTU 时才需要进行。会再申请额外的 sk_buff，并将原来的 sk_buff 拷贝为多个小的 sk_buff

HTTP 常见面试题

HTTP 基本概念

HTTP常见的状态码：

1xx 协议处理中间状态，还需后续操作
2xx 成功，报文收到，并正确处理
- 200 OK ，一切正常，如果是非HEAD请求，服务器返回的响应头都会有body数据
- 204 NO CONTENT 一切正常，响应头无Body数据
- 206 Partial Content 用于HTTP分块下载或断点续传，表示响应返回的body数据不是资源的全部，而是一部分
3xx 重定向，资源位置发生变动，需要客户端重新请求
- 301 Moved permanently 永久重定向，请求的资源不在，需要用新的URL再次访问呢
- 302 Found 临时重定向，请求的资源还在，暂时需要另一个URL访问
  - 301 302 在响应头中的Location字段，指明了后续要跳转的URL
- 304 Not Modified 不跳转，表示资源未修改，重定向缓存文件
4xx 客户端错误，请求报文有误，服务器无法处理
- 400 Bad Request 客户端请求报文有误
- 403 Forbidden 服务器禁止访问资源
- 404 Not Found 请求的资源在服务器上找不到
5xx 服务器错误，服务器在处理请求时内部发生了错误
- 500 Internal Server Error 笼统的错误码，表示服务器出错
- 501 Not Implemented 客户端请求的功能还不支持
- 502 Bad Gateway 服务器作为网关或者代理时返回的错误码，服务器工作正常，访问后端时发生错误
- 503 Service Unavailable 服务器当前忙，无法响应客户端

HTTP常见字段

Host：发送请求，指定服务器的域名
Content-Length: 本次回复的数据长度，作为HTTP body的边界，搭配回车符、换行符作为HTTP header的边界，用于解决粘包问题
Connection: 客户端要求服务器使用 HTTP长连接，指定值为 Keep-Alive
Content-Type: 用于服务器回应，告诉客户端，本次数据是什么格式
Accept: 用于请求，表示自己接受哪些数据格式
Content-Encoding: 表明服务器返回的数据使用了什么压缩格式
Accept-Encoding: 说明自己可以接收哪些压缩方法

安全和幂等

在 HTTP 协议里，所谓的「安全」是指请求方法不会「破坏」服务器上的资源
所谓的「幂等」，意思是多次执行相同的操作，结果都是「相同」的

HTTP缓存实现方式：

强制缓存
- 只要缓存未过期，就直接使用浏览器本地缓存，浏览器主动决定
- 实现方式：
  - Cache-Control：相对过期时间(优先级高)
  - Expires：绝对过期时间
协商缓存
- 客户端与服务器协商后，通过协商结果判断是否使用本地缓存
- 实现方式：
  - 第一种
    - 请求头 if-Modified-Since，资源过期后，带上Last-Modified的值，用于服务器判断资源是否被修改
    - 响应头 Last-Modified，资源最后修改时间
  - 第二种
    - 请求头 if-None-Match：资源过去，该头带上Etag值，用于服务器判断资源是否过期
    - 响应头 Etag：唯一标识响应资源
  - Etag优先级高于Last-Modified
    - 即便没有修改文件，文件的最后修改日期也可能变
    - 有些文件是以秒为单位修改的，if-Modified-Since只能检测s为单位的修改，Etag可以检测一秒内的多次修改
    - 有些服务器不能精确获取修改时间
- 协商缓存需要配合Cache-Control来使用，只有未命中强制缓存，才使用协商缓存

HTTP特点

简单
易于拓展
跨平台
缺点
- 无状态
- 明文传输
- 不安全
HTTP 1.1
- 长连接
- 管道网络传输
  - 客户端可以发起多个请求，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间(长连接实现)
- 解决了请求的队头阻塞，但没有解决响应的队头阻塞

HTTP1.0和HTTP1.1的区别

默认连接方式改为长连接
增加了更多了响应状态码
增加了更多的缓存策略，类似Etag
在请求头加入了range，允许只请求资源的某个部分
引入了Host字段，允许在同一IP地址上托管多个域名

HTTP1.1和HTTP2.0的区别

实现了连接的多路复用，解决了队头阻塞的问题
- 针对不同的 HTTP 请求用独一无二的 Stream ID 来区分，接收端可以通过 Stream ID 有序组装成 HTTP 消息，不同 Stream 的帧是可以乱序发送的，因此可以并发不同的 Stream，也就是HTTP/2可以并行交错地发送请求和响应
使用二进制帧进行数据传输，而HTTP1.1之前采用文本传输
支持头部压缩，使用HPACK算法
支持服务器推送，可以在客户端请求的时候，将相关资源一并推送
- 客户端和服务器双方都可以建立 Stream，Stream ID 也是有区别的，客户端建立的 Stream 必须是奇数号，而服务器建立的 Stream 必须是偶数号

HTTP2.0和HTTP3.0的区别

使用QUIC传输协议来实现
连接建立更快，只需要0/1个RTT
- HTTP/3的QUIC协议并不是与TLS分层，而是QUIC内部包含了TLS，它在自己的帧会携带TLS里的“记录”，再加上QUIC使用的是TLS/1.3，因此仅需1个RTT就可以「同时」完成建立连接与密钥协商
使用QUIC，解决了TCP导致的队头阻塞
- QUIC有自己的一套机制可以保证传输的可靠性的。当某个流发生丢包时，只会阻塞这个流，其他流不会受到影响，因此不存在队头阻塞问题
可以不依赖TCP的错误恢复机制，更快的进行恢复和重传
使用QUIC进行加密，提供更强的安全性
连接迁移
- 通过连接 ID 来标记通信的两个端点，客户端和服务器可以各自选择一组ID来标记自己，因此即使移动设备的网络变化后，导致IP地址变化了，只要仍保有上下文信息（比如连接 ID、TLS密钥等），就可以“无缝”地复用原连接，消除重连的成本，没有丝毫卡顿感，达到了连接迁移的功能

HTTP和HTTPS区别

TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议，使得报文能够加密传输
还需进行 SSL/TLS 的握手过程，才可进入加密报文传输
HTTP 默认端口号是 80，HTTPS 默认端口号是 443
HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的

HTTP问题

窃听风险
- 信息加密
  - 混合加密的方式实现信息的机密性
篡改风险
- 检验机制
  - 摘要算法的方式来实现完整性，它能够为数据生成独一无二的「指纹」，指纹用于校验数据的完整性，解决了篡改的风险
冒充风险
- 身份证书
  - 将服务器公钥放入到数字证书中，解决了冒充的风险

混合加密

在通信建立前使用非对称加密的方式交换会话密钥，后续不再使用非对称加密
- 公钥和私钥，公钥可以任意分发，私钥保密，解决了密钥交换问题但速度慢
通信过程中使用对称加密的会话密钥，加密明文数据
- 运算速度快，无法做到安全的密钥交换

摘要算法和数字签名

使用摘要算法(哈希函数)计算出内容的哈希值，哈希值是唯一的，且无法通过哈希值推导出内容
- 只能保证内容不会被篡改，但是不能保证内容不能被替换
非对称加密
- 公钥和私钥，这两个密钥可以双向加解密
  - 公钥加密，私钥解密，保证传输内容的安全
  - 私钥加密，公钥解密，保证消息不会被冒充，如果公钥能正常解密出私钥加密的内容，就可以证明这个消息是持有私钥身份的人发送的
    - 私钥加密不是对内容加密，而是对内容的哈希值加密

数字证书

CA 签发证书的过程

数字证书认证机构(CA)，首先 CA 会把持有者的公钥、用途、颁发者、有效时间等信息打成一个包，然后对这些信息进行Hash 计算，得到一个 Hash 值，CA 会使用自己的私钥将该 Hash 值加密，生成 Certificate Signature，也就是 CA 对证书做了签名。最后将 Certificate Signature 添加在文件证书上，形成数字证书

客户端校验服务端的数字证书的过程

首先客户端会使用同样的 Hash 算法获取该证书的 Hash 值 H1；
通常浏览器和操作系统中集成了 CA 的公钥信息，浏览器收到证书后可以使用 CA 的公钥解密

Certificate Signature 内容，得到一个 Hash 值 H2

最后比较 H1 和 H2，如果值相同，则为可信赖的证书，否则则认为证书不可信

SSL/TLS协议基本流程

客户端要服务器索要并验证服务器的公钥
双方协商产生会话密钥
- 前两部就是TLS/SSL的握手阶段，常用的密钥交换算法有RSA算法和ECODE算法
双方采用会话密钥进行加密通讯

TLS/SSL的握手阶段

ClientHello
ServerHello
客户端回应
服务器最后回应

数字证书

公钥
持有者信息
CA信息
CA对这份文件的数字签名以及使用的算法
证书有效期
额外信息
证书签发过程
- CA将持有者的公钥、用途、颁发者、有效时间打包、对这些信息进行Hash计算，得到一个Hash值
- CA用自己的私钥将该Hash加密，生成Certificate Signature，也就是签名
- 将Certificate Signature添加到文件证书上，形成数字证书
证书检验过程
- 使用同样的Hash算法获取该证书的Hash值H1
- 用系统或者浏览器集成的CA公钥解密Certificate Signature的内容，得到Hash值H2
- 比较H1和H2如果值相同，则为可信赖证书，否则认为证书不可信

RSA握手过程

Client Hello 第一次握手
- 客户端向服务器发送TLS版本号、支持的密码套件列表、生成的随机数(Client Random)
Server Hello 第二次握手
- 确认TLS版本号是否支持，从密码套件中选择一个，生成一个随机数(Server Random)
  - 密码套件的组成：密钥交换算法+签名算法+对称加密算法+摘要算法
- 发送Server Certificate 给客户端，该消息包含数字证书
- 发送Server Hello Done，告知本次打招呼完毕
第三次握手
- 客户端生成一个随机数**(pre-master)，用服务器RSA公钥加密该随机数，通过Client Key Exchange**消息传给服务器
- 用Client Random、Server Random、pre-master生成会话密钥（master secret）后，客户端发送一个Change Cipher Spec 告诉服务端开始使用加密方式发送消息
- 客户端在发送一个Encrypted Handshake Message（Finished****）把之前发送的数据做个摘要，使用会话密钥master secret加密，让服务器做验证，验证加密通信是否可以，之前的握手信息是否被篡改过
第四次握手
- 服务器发送 Change Cipher Spec 和 Encrypted HandShake Message消息，如果双方都验证加密和解密没问题，握手正式完成
缺陷：
- 不支持前向加密
  - 一旦服务端的私钥泄漏了，过去被第三方截获的所有 TLS 通信密文都会被破解。

HTTPS 的应用数据是如何保证完整性的

握手协议
- TLS 握手协议就是我们前面说的 TLS 四次握手的过程，负责协商加密算法和生成对称密钥，后续用此密钥来保护应用程序数据
记录协议
- TLS 记录协议负责保护应用程序数据并验证其完整性和来源，所以对 HTTP 数据加密是使用记录协议
- 具体过程如下：
  - 首先，消息被分割成多个较短的片段,然后分别对每个片段进行压缩
  - 接下来，经过压缩的片段会被加上消息认证码（MAC 值，这个是通过哈希算法生成的这是为了保证完整性，并进行数据的认证
  - 再接下来，经过压缩的片段再加上消息认证码会一起通过对称密码进行加密
  - 最后，上述经过加密的数据再加上由数据类型、版本号、压缩后的长度组成的报头就是最终的报文数据。记录协议完成后，最终的报文数据将传递到传输控制协议 (TCP) 层进行传输

TCP

TCP的头部

TCP首部结构先是16位的源端口号和目标端口号、接着是32位的序列号和确认号。再下面就是4bit的头部长度和6个bit的保留位及6bit的标志位
- 序列号：它是TCP报文段的一数字编号，为保证TCP可靠连接，每一个发送的数据段都要加上序列号。建立连接时，两端都会随机生成一个初始序列号。而确认号而是和序列号配合使用的，应答某次请求时，则返回一个确认号，它的值等于对方请求序列号加1
- 6个标志位
  - URG：这是条紧急信息
  - ACK:应答消息
  - PSH:缓冲区尚未填满
  - RST:重置连接
  - SYN:建立连接消息标志
  - FIN：连接关闭通知信息
16位的属性则有窗口大小（控制发送窗口），检验和（校验数据段是否未被修改）及紧急指针。最后是选项，其长度由头部长度决定
- 窗口大小是接收端用来控制发送端的滑动窗口大小

TCP和UDP有什么区别

连接方面：TCP面向连接。UDP是无连接的，发送数据之前不需要建立连接
安全方面：
- TCP提供可靠的服务，保证传送的数据，无差错，不丢失，不重复，且按序到达
- UDP则是尽最大努力交付，不保证可靠交付
传输效率：TCP传输效率相对较低，UDP传输效率高

TCP是可靠的连接，它是怎么实现的

TCP的连接是基于三次握手，而断开则是四次挥手
为了保障数据不丢失及错误（可靠性）
- 报文校验
- ACK应答
- 超时重传(发送方)
- 失序数据重传（接收方）
- 丢弃重复数据
- 流量控制（滑动窗口）和拥塞控制等机制

三次握手和四次挥手机制

关闭连接时需要四次挥手，比建立时多一次，是因为被动关闭端或许还有数据没被送出去，不能像握手时一样，第二次握手既是发起握手也是响应握手

如果没有三次握手会有什么问题呢

只有两次握手，client发连接请求后不会再ACK服务端的SYN
此时若客户端因为自身原因判断建立连接失败，可能会重复建立TCP连接，而服务端却会认为那些被client丢弃的TCP还是有效，会白白浪费资源

TIME_WAIT和CLOSE_WAIT的区别在哪

CLOSE_WAIT是被动关闭形成的；当对方close socket而发送FIN报文过来时，回应ACK之后进入CLOSE_WAIT状态。随后检查是否存在未传输数据，如果没有则发起第三次挥手，发送FIN报文给对方，进入LAST_ACK状态并等待对方ACK报文到来
TIME_WAIT是主动关闭连接方式形成的；处于FIN_WAIT_2状态时，收到对方FIN报文后进入TIME_WAIT状态；之后再等待两个MSL(Maximum Segment Lifetime:报文最大生存时间)

TIME_WAIT的作用呢，还有为啥状态时间要保持两个MSL

TIME_WAIT的作用是为了保证最后一次挥手的ACK报文能送达给对方，如果ACK丢失，对方会超时重传FIN，主动关闭端会再次响应ACK过去；如果没有TIME_WAIT状态，直接关闭，对方重传的FIN报文则被响应一个RST报文，此RST会被动关闭端被解析成错误
存在两个连接，第一个连接正常关闭，第二相同的连接紧接着建立；如果第一个连接的迷路报文到来，则会干扰第二连接，等待两个MSL则可以让上次连接的报文数据消逝在网络后，防止之后建立的相同的连接收到之前旧连接的响应报文

拥塞控制，TCP协议用什么方式去解决拥塞的

第一方式是慢启动和拥塞避免
- 慢启动，TCP发送端会维护一个拥塞窗口（congestionwindow）,简称为cwnd。拥塞窗口初始为1个报文段，每经过一次RTT（数据完全发送完到确认的时间），窗口大小翻倍（指数增长，只是前期慢）
- 拥塞避免，它思路是让拥塞窗口cwnd缓慢增大，发送方的cwnd达到阀值ssthresh(初始值由系统决定的)之后，每经过一个RTT就把拥塞窗口加一，而不是加倍（收到两个或四个确认，都是cwnd+1），cwnd呈线性增加（加法增大）
- 如果遇到网络拥塞，拥塞窗口阀值ssthresh为cwnd减半，cwnd设置为1，重新进入慢启动阶段

拥塞控制还有其他什么方式呢

快重传和快恢复
- 快重传是当接收方收到了一个失序的报文，则立马报告给发送方，赶紧重传
  - 假如接收方M1收到了，M2没有收到，之后的M3、M4、M5又发送了，此时接收方一共连续给发送方反馈了3个M1确认报文。那么快重传规定，发送方只要连续收到3个重复确认，立即重传对方发来的M2（重复确认报文的后一个报文）
- 快恢复
  - 当发送方连续收到三个重复确认，ssthresh减半；由于发送方可能认为网络现在没有拥塞，因此与慢启动不同，把cwnd值设置为ssthresh减半之后的值，然后执行拥塞避免算法，cwnd线性增大

客户端和服务端控制滑动窗口的过程是怎样的

接收端将自己可以接收的缓冲区大小放入TCP首部中的“窗口大小”字段，通过ACK报文来通知发送端，滑动窗口是接收端用来控制发送端发送数据的大小，从而达到流量控制
其实发送方的窗口上限，是取值拥塞窗口和滑动窗口两者的最小值

滑动窗口和拥塞窗口有什么区别不

相同点：控制丢包现象，实现机制都是让发送方发得慢一点
不同点在于控制的对象不同
- 流量控制的对象是接收方，怕发送方发的太快，使得接收方来不及处理
- 拥塞控制的对象是网络，怕发送方发的太快，造成网络拥塞，使得网络来不及处理

TCP的粘包和拆包问题

程序需要发送的数据大小和TCP报文段能发送MSS（Maximum Segment Size，最大报文长度）是不一样的
大于MSS时，而需要把程序数据拆分为多个TCP报文段，称之为拆包；小于时，则会考虑合并多个程序数据为一个TCP报文段，则是粘包；其中MSS = TCP报文段长度-TCP首部长度
在IP协议层或者链路层、物理层，都存在拆包、粘包现象

解决粘包和拆包的方法都有哪些

在数据尾部增加特殊字符进行分割
将数据定为固定大小
将数据分为两部分，一部分是头部，一部分是内容体；其中头部结构大小固定，且有一个字段声明内容体的大小

SYN Flood了解吗

SYN Flood 伪造 SYN 报文向服务器发起连接，服务器在收到报文后用 SYN_ACK 应答，此应答发出去后，不会收到 ACK 报文，造成一个半连接
若攻击者发送大量这样的报文，会在被攻击主机上出现大量的半连接，耗尽其资源，使正常的用户无法访问，直到半连接超时

一次HTTP请求，程序一般经历了哪几个步骤？

解析域名
发起TCP三次握手，建立连接
基于TCP发起HTTP请求
服务器响应HTTP请求，并返回数据
客户端解析返回数据

HTTP有哪几种响应状态码，列举几个你熟悉的

200：表示成功正常请求
400：语义有误，一般是请求格式不对
401：需求用户验证权限，一般是证书token没通过认证
403：拒绝提供服务
404：资源不存在
500：服务器错误
503：服务器临时维护，过载；可恢复

session和cookie有什么区别

存储位置不同，cookie是保存在客户端的数据；session的数据存放在服务器上
存储容量不同，单个cookie保存的数据小，一个站点最多保存20个Cookie；对于session来说并没有上限
存储方式不同，cookie中只能保管ASCII字符串；session中能够存储任何类型的数据
隐私策略不同，cookie对客户端是可见的；session存储在服务器上，对客户端是透明的
有效期上不同，cookie可以长期有效存在；session依赖于名为JSESSIONID的cookie，过期时间默认为-1，只需关闭窗口该session就会失效
跨域支持上不同，cookie支持跨域名访问；session不支持跨域名访问

了解什么是HTTP分块传送吗

分块传送是HTTP的一种传输机制，允许服务端发送给客户端的数据分成多个部分，该协议在HTTP/1.1提供

什么好处

HTTP分块传输编码允许服务器为动态生成的内容维持HTTP持久连接
分块传输编码允许服务器在最后发送消息头字段。对于那些头字段值在内容被生成之前无法知道的情形非常重要，例如消息的内容要使用散列进行签名
HTTP服务器有时使用压缩（gzip或deflate）以缩短传输花费的时间。分块传输编码可以用来分隔压缩对象的多个部分。在这种情况下，块不是分别压缩的，而是整个负载进行压缩。分块编码有利于一边进行压缩一边发送数据

HTTP的长连接你怎么理解

长连接是指客户端和服务建立TCP连接后，它们之间的连接会持续存在，不会因为一次HTTP请求后关闭，后续的请求也是用这个连接
长连接可以省去TCP的建立和关闭操作，对于频繁请求的客户端适合使用长连接，但是注意恶意的长连接导致服务受损

HTTP是安全的吗？怎么做到安全的HTTP协议传输

并非安全，HTTP传输的数据都是明文的，容易被第三方截取；要做安全传输数据，可以使用HTTP的升级版HTTPS协议

HTTPS和HTTP的区别，你是怎么理解的

http协议的连接是无状态的，明文传输
HTTPS则是由SSL/TLS＋HTTP协议构建的有加密传输、身份认证的网络协议

SSL/TLS是什么，HTTPS的安全性是怎样实现的？

SSL(Secure Socket Layer 安全套接层)是基于HTTPS下的一个协议加密层，保障数据私密性。TLS(Transport Layer Security)则是升级版的SSL
https在http基础加了一层安全认证及加密层TLS或者SSL，它首先会通过安全层进行ca证书认证，正确获取服务端的公钥
客户端会通过公钥和服务端确认一种加密算法，后面的数据则可以使用该加密算法对数据进行加密

MTU