Interview_计网_day20
\(TCP\) 粘包问题
粘包问题的本质在于接收方无法区分消息与消息之间的边界在哪里，可能把两个消息读成了一个消息。
解决方案有三种：
- 定长发送：在数据发送的时候，无论数据多大或者多小，都拆分成固定长度 \(LEN\) 来发送，随后一个包不足 \(LEN\) 时通过空白字节来填充。但会造成带宽浪费。
- 尾部标记法：在每个要发送的数据报尾部设置一个特殊的字节序列，用来表示数据报的结束。但这种序列的确定本身就是一个问题，什么样的序列可以做成标识序列，很难有确定的答案。
- 头部标记法：在报文头部注明发送的数据报大小，接收方接收的时候通过报头表明的数据大小进行读取，就必然只能读到一个数据。但不可以忽略每一个报头的累加值，对于内存的开销需要更大。
\(HTTP\) 协议
\(HTTP\) 是基于 \(TCP/IP\) 通信协议来传递数据。
\(HTTP\) 采用请求响应模型。客户端发起一个 \(HTTP\) 请求到服务器的 \(80\) 端口。服务器则在 \(80\) 端口监听客户端的请求，一旦收到请求，服务器就会向客户端返回一个状态以及返回了内容。
\(HTTP\) 报文格式
\(HTTP\) 报文由请求行、请求头部、请求数据组成。
- 请求行由请求方法、\(URL\)、版本协议组成，比如 GET /index.html HTTP/1.1，常见的请求方法有 \(GET、POST、HEAD\)。
- 请求头部由 关键字:值 组成，通知服务器有关客户端请求的信息
- 请求头部结束后空出一行空行
- 请求数据部分一般用于 \(POST\) 请求
\(HTTP\) 特点
- 支持 请求-响应 模式
- \(HTTP\) 协议规定，请求从客户端发出，最后服务器端响应并返回。
- 简单快速
- 客户向服务器请求的时候，只需传送请求方法 \((GET、POST)\) 和路径。由于 \(HTTP\) 协议简单，使得 \(HTTP\) 服务器的程序规模小，通信速度快。
- 灵活
- \(HTTP\) 允许传输任意类型的数据对象。
- 无连接
- 限制每次连接只处理一个请求。服务器端完成客户的请求并收到客户的应答后，就断开连接，尽快的释放资源给其他客户使用。
- 早期的 \(HTTP\) 协议完成后立即断开，而 \(HTTP1.1\) 中会等待几秒后在断开，原因在于如果用户几秒内又有新的请求，那么还是通过之前的通道来收发消息，显然这样可以减少短时间内的建立耗时，提高效率。
- 无状态
- \(HTTP\) 不保存状态，每当有新的请求发送时，就会有新的响应产生，协议本身不保留之前处理过的响应报文的信息。
- 利用 \(Cookie\) 可以记录 \(HTTP\) 协议的请求信息。浏览器登录时直接从 \(Cookie\) 读取数据并发给服务器，服务器验证后响应给客户端。
\(HTTP\) 的返回码
| 类别 | 原因 | |
|---|---|---|
| 1XX | \(Information\)(信息性状态码) | 接收的请求正在处理 |
| 2XX | \(Success\)(成功状态码) | 请求正常处理完毕 |
| 3XX | \(Redirection\)(重定向状态码) | 需要进行附加的操作以完成请求 |
| 4XX | \(Client Error\)(客户端错误状态码) | 请求有语法错误或请求无法实现 |
| 5XX | \(Server Error\)(服务器错误状态码) | 服务器未能实现合法的请求 |
- \(200：\) 客户端请求成功
- \(202：\) 服务器已接受请求，但尚未处理
- \(301：\) 代表永久性转移，资源已经永久的移动到了新位置
- \(302：\) 代表暂时性转移，资源暂时的移动到了新位置
- \(403：\) 服务器已经理解请求，但拒绝执行
- \(404：\) 请求的资源没有发现
- \(502：\) 错误网关
在浏览器中输入 \(URL\) 后执行的全部过程，每层和协议
- 浏览器中输入 \(URL\)，解析域名需要用到 \(DNS\) 协议。主机会询问本地域名服务器，如果没有就向 \(DNS\) 服务器查询该 \(URL\) 的 \(IP\) 地址。查询方法分为递归查询和迭代查询。这里的传输过程中使用到了 \(UDP\) 协议。
- 递归查询过程：主机 -> 根域名服务器 -> 顶级域名服务器 -> 权限域名服务器 -> 顶级域名服务器 -> 根域名服务器 -> 主机
- 迭代查询过程：主机 -> 根域名服务器 -> 主机 -> 顶级域名服务器 -> 主机 -> 权限域名服务器 -> 主机
- 得到 \(IP\) 地址后，浏览器与服务器建立 \(HTTP\) 连接，发出读取文件的请求报文。这里用到了应用层的 \(HTTP\) 协议。
- 在传输层中，数据报通过 \(TCP\) 连接传输，用到了 \(TCP\) 协议。
- 传输报文过程中，会把报文发送给网络层，这里用到了 \(IP\) 协议、\(ARP\) 协议。\(ARP\) 协议获得下一跳应该跳往的 \(MAC\) 地址，一跳一跳的发送给目标地址。
- 信息传输完成以后，释放 \(TCP\) 连接，浏览器显示获得的 \(html\) 文本内容。
\(HTTPS\) 协议以及和 \(HTTP\) 的区别
\(HTTPS = HTTP + SSL\)，是更加安全的 \(HTTP\) 协议，\(SSL\) 提供了鉴别和保密两个基本安全服务。
- \(HTTP\) 是明文传输，\(HTTPS\) 是密文传输，所以更加安全。
- \(HTTP\) 通信：直接把报文交给 \(TCP\) 传输到目的主机。
- \(HTTPS\) 通信：把报文交给 \(SSL\) 加密，然后 \(SSL\) 交给 \(TCP\) 传输到目的主机，目的主机获取报文后在交给 \(SSL\) 解密。
- \(HTTP\) 默认端口 \(80\)，\(HTTPS\) 默认端口 \(443\)。
- \(HTTPS\) 的服务器需要申请 \(CA\) 证书。
\(HTTPS\) 加密方式
通过非对称加密和对称加密共同完成。
- 客户端向服务器端发出请求。
- 服务器端将公匙通过明文发送给客户端。
- 客户端受到公匙后，随机生成一个用于对称加密的密匙，并用公匙进行加密后发送给服务器端。
- 服务器端收到后，通过私匙进行解密，然后获得密匙。
- 这样双方都有了用于对称加密的密匙，之后的数据通过密匙加密解密。
为了保证公匙正确发送到客户端，服务器端会讲证书内容 \(F1\) 通过散列算法 \(hash\) 成 \(F2\)，然后用公匙进行加密得到 \(F3\)。客户端收到信息后，用公匙对 \(F3\) 进行解密得到 \(F2\)，然后用同样的散列算法对 \(F1\) 进行处理得到 \(F4\)，然后判断 \(F2\) 和 \(F4\) 是否相同。
\(HTTPS\) 的优缺点
优点:
- 传输过程中使用了密匙进行加密，安全性更高。
- 可以认证用户和服务器，确保数据发送到正确的服务器和用户
缺点：
- 握手阶段时延较高，因为需要完成 \(SSL\) 握手。
- 部署成本高，需要使用证书来验证自身的安全性，购买 \(CA\) 证书。需要进行解密过程，占用 \(CPU\) 资源多，需要更好的服务器配置。
\(session\)、\(cookie\)、\(token\)
因为 \(HTTP\) 是无状态的，所以服务器端会给用户发送一个会话标识 (\(session\) \(id\))，用户保存这个 \(id\)，然后通过 \(cookie\) 发送给服务器端，以此来标识每个用户。
那么对于用户而言，只需要存储一个 \(id\)，而对于服务器而言，他需要存储每个用户的 \(id\)，这对于服务器而言是一个巨大的开销，所以有了 \(token\)。
\(token\) 想要解决的就是服务器也需要保存 \(id\) 的局限，不保存用户的 \(id\)，而是去验证用户的 \(id\)。服务器向用户发送一个 \(token\)，让用户带过来即可。然而这和 \(session\) 没有本质的区别，还是会被第三者伪造。所以 \(token\) 附上了加密操作。
服务器对数据进行 \(hash\) 处理，然后把得到的结果用自己的密匙加密，最后和数据本身一块作为 \(token\) 发送给用户。当用户把 \(token\) 给我的时候，我用密匙解密得到 \(hash\) 后的结果，然后再对数据进行 \(hash\)，判断两次得到的结果是否相同，如果相同，则说明改用户之前已经访问过我，否则就说明是个非法用户。
