🐅计算机网络

计网知识体系

• HTTP协议
  • 报文头部字段
  • （响应报文头部的）状态码
  • 缓存问题
    • 强缓存
    • 协商缓存
• HTTPS协议
  • 对称加密、非对称加密的概念
  • 数字证书的用途
  • SSH密钥在非对称加密中的作用、
  • 中间人攻击
• TCP协议
  • 三次握手
  • 四次挥手
• IP协议
• 跨域问题
  • 相关报文头部字段

计网学习资源

推荐的一些超棒的资源！

• 进阶必备的网络基础 (opens new window)

• 小林Coding的《图解网络》 (opens new window)

• 前端面试精粹 (opens new window)

• 前端硬核面试专题 (opens new window) HTTP篇 (opens new window)（作者这里笔误写成HTTPS了 其实讲的都是HTTP中的内容）

• 《图解HTTP》

• 《网络是如何连接的》

• HTTP - 指南：基础 | Guides: Basics - Basics of HTTP - 开发者手册 - 云+社区 - 腾讯云（有RFC文档翻版本） (opens new window)

• 超高频面试题（简短易懂） (opens new window)

计网应知应会

• 7层网络协议

• HTTP协议是重点

  • DNS解析

• 传输层相关（TCP、UDP）

• 网络层相关（IP地址、IPV4、IPV6、子网掩码）

网络模型一览

工欲善其事，必先利其器。学习计算机网络之前，让我们先对其有个大致的了解

《图解网络》

主要掌握的内容为TCP/IP网络模型

OSI参考模型做一个了解即可~

为了使得多种设备可以通过网络相互通信

为了解决各种设备在网络互联中的兼容性问题

国际标准化组织制定了 开放式系统互联通信参考模型 也就是OSI网络模型

这七层的OSI模型 每层负责的职能不同~

• 应用层 负责给应用程序提供统一的接口
• 表示层 负责把数据转换成兼容另一个系统能识别的格式
• 会话层 负责建立、管理、终止 表示层实体之间的通信对话
• 传输层 负责端到端的数据传输
• 网络层 负责数据的路由、转发、分片
• 数据链路层 负责数据的封帧和差错检测 以及MAC寻址
• 物理层 负责在物理网络中传输数据帧

由于 OSI 模型实在太复杂，提出的也只是概念理论上的分层，并没有提供具体的实现⽅案。

事实上，我们⽐较常⻅，也⽐较实⽤的是四层模型，即 TCP/IP 网络模型，Linux 系统正是按照这套网络模型来实现网络协议栈的。

这个经典的TCP/IP模型共有4层 我们需要熟练掌握——

• 应用层

  • HTTP HTTPS——推荐小林Coding的这篇文章~硬核！30 张图解 HTTP 常见的面试题 (opens new window)

• 传输层

  • TCP
  • UDP

• 网络层

  • IPV4
  • 简单了解IPV6

我们只需要简单了解——

• 网络接口层（数据链路层和物理层）

下面对于网络模型总览的内容来自小林Coding的《图解网络》（个人进行了一些细节上的理解+重点的标注）

对于同⼀台设备上的进程间通信，有很多种⽅式，⽐如有管道、消息队列、共享内存、信号等⽅式，⽽对于不同设备上的进程间通信，就需要网络通信，⽽设备是多样性的，所以要兼容多种多样的设备，就协商出了⼀套通用的网络协议（《趣谈网络协议》作者形象地称其为“打破世界的通天塔（阻碍各国进行交流的一个桎梏）的网络协议”）

这个网络协议是分层的，每⼀层都有各自的作用和职责，接下来就分别对每⼀层进⾏介绍。

【1】应用层（Application Layer）

• 是最上层的，也是我们能直接接触到那层

• 我们电脑或⼿机使⽤的应⽤软件都是在应⽤层实现的

• 当两个不同设备的应⽤需要通信的时候，应用就把应用数据传给下⼀层，也就是传输层

• 所以，应⽤层只需要专注于为用户提供应用功能，不用去关心数据是如何传输的，就类似于，我们寄快递的时候， 只需要把包裹交给快递员，由他负责运输快递，我们不需要关心快递是如何被运输的

• ⽽且应⽤层是⼯作在操作系统中的用户态，传输层及以下的⼯作在内核态

【2】传输层（Transport Layer）

• 应用层的数据包会传给传输层

• 传输层是为应用层提供网络支持的

• 传输层会有两个传输协议 分别是——
  • TCP
  • UDP

那么TCP UDP有什么区别呢😏😏😏

最主要的区别就是——TCP更可靠！但也同时损失了实时性，传输效率低了一些~

• TCP的全称叫传输层控制协议（Transmission Control Protocol），⼤部分应⽤使⽤的正是 TCP 传输层协议

  • 比如 HTTP 应⽤层协议使用的就是TCP传输层协议
  • TCP 相⽐ UDP 多了很多特性，⽐如流量控制、超时重传、拥塞控制等 这些都是为了保证数据包能可靠地传输给对方

• UDP 就相对很简单，简单到只负责发送数据包，不保证数据包是否能抵达对⽅

  • 但它实时性相对TCP更好，传输效率 也⾼
  • 当然，UDP 也可以实现可靠传输，把 TCP 的特性在应⽤层上实现就可以
  • 不过要实现⼀个商⽤的可靠 UDP 传输协议，也不是⼀件简单的事情

• 应⽤需要传输的数据可能会⾮常⼤，如果直接传输就不好控制，因此当传输层的数据包大小超过 MSS（TCP 最⼤报⽂段⻓度） ，就要将数据包分块（传输层蛮重要的一个特性~），这样即使中途有⼀个分块丢失或损坏了，只需要᯿新这⼀个分块，⽽不⽤重新发送整个数据包。

• 在 TCP 协议中，我们把每个分块称为⼀个 TCP 段（TCP Segment）

• 当设备作为接收方时，传输层则要负责把数据包传给应用，但是⼀台设备上可能会有很多应⽤在接收或者传输数据，因此需要⽤⼀个编号将应用区分开来，这个编号就是端口

  • 比如 80 端⼝通常是 Web 服务器⽤的
  • 22 端⼝通常是远程登录服务器⽤的

• ⽽对于浏览器（客户端）中的每个标签栏都是⼀个独⽴的进程，操作系统会为这些进程分配临时的端⼝号

• 由于传输层的报⽂中会携带端⼝号，因此接收⽅可以识别出该报⽂是发送给哪个应⽤

【3】网络层（Internet Layer）

寻址 与 路由

IP 协议的寻址作⽤是告诉我们去往下⼀个⽬的地该朝哪个⽅向⾛，路由则是根据「下⼀个⽬的地」选择路径

• 寻址更像在导航，路由更像在操作方向盘

• 可能⼤家刚接触传输层的时候，会认为它负责将数据从⼀个设备传输到另⼀个设备，事实上它并不负责
  • 这是网络层的活儿！！

实际场景中的网络环节是错综复杂的，中间有各种各样的线路和分叉路⼝，如果⼀个设备的数据要传输给另⼀个设备，就需要在各种各样的路径和节点进⾏选择，⽽传输层的设计理念是简单、⾼效、专注，如果传输层还负责这⼀块功能就有点违背设计原则了

• 也就是说，我们不希望传输层协议处理太多的事情，只需要服务好应⽤即可，让其作为应⽤间数据传输的媒介，帮助实现应⽤到应⽤的通信，⽽实际的传输功能就交给下⼀层，也就是网络层（Internet Layer）

• 网络层最常使⽤的是 IP 协议（Internet Protocol），IP 协议会将传输层的报⽂作为数据部分，再加上 IP 包头组装 成 IP 报⽂
• 如果 IP 报⽂大小超过 MTU（以太网中⼀般为 1500 字节）就会==再次进⾏分⽚==，得到⼀个即将发送到网络的 IP 报⽂

• 网络层负责将数据从⼀个设备传输到另⼀个设备，世界上那么多设备，⼜该如何找到对⽅呢？因此，网络层需要有 区分设备的编号

• 我们⼀般⽤ IP 地址给设备进⾏编号，对于 IPv4 协议， IP 地址共 32 位，分成了四段，每段是 8 位。只有⼀个单纯 的 IP 地址虽然做到了区分设备，但是寻址起来就特别麻烦，全世界那么多台设备，难道⼀个⼀个去匹配？这显然不科学。 因此，需要将 IP 地址分成两种意义

  • ⼀个是==网络号==，负责标识该 IP 地址是属于哪个⼦网的
  • ⼀个是==主机号==，负责标识同⼀⼦网下的不同主机

• 怎么分的呢？这需要配合子网掩码才能算出 IP 地址 的网络号和主机号。那么在寻址的过程中，先匹配到相同的网络号，才会去找对应的主机

• 除了寻址能力， IP 协议还有另⼀个重要的能力就是路由

  实际场景中，两台设备并不是⽤⼀条网线连接起来的， ⽽是通过很多网关、路由器、交换机等众多网络设备连接起来的

  那么就会形成很多条网络的路径，因此当数据包 到达⼀个网络节点，就需要通过算法决定下⼀步⾛哪条路径

• 所以，IP 协议的==寻址作⽤是告诉我们去往下⼀个⽬的地该朝哪个⽅向⾛==，==路由则是根据「下⼀个⽬的地」选择路径==

  • 寻址更像在导航，路由更像在操作方向盘

【4】数据链路层

• 实际场景中，网络并不是⼀个整体，⽐如你家和我家就不属于⼀个网络，所以数据不仅可以在同⼀个网络中设备间进行传输，也可以跨网络进⾏传输

• ⼀旦数据需要跨网络传输，就需要有⼀个设备同时在两个网络当中，这个设备⼀般是路由器，路由器可以通过路由表计算出下⼀个要去的 IP 地址

• 那问题来了，路由器怎么知道这个 IP 地址是哪个设备的呢？

  • 于是，就需要有⼀个专⻔的层来标识网络中的设备，让数据在⼀个链路中传输，这就是数据链路层（Data Link Layer），它主要为网络层提供链路级别传输的服务

  

• 每⼀台设备的网卡都会有⼀个 MAC 地址，它就是⽤来唯⼀标识设备的。路由器计算出了下⼀个⽬的地 IP 地址，再通过 ARP 协议找到该⽬的地的 MAC 地址，这样就知道这个 IP 地址是哪个设备的了

【5】物理层

当数据准备要从设备发送到网络时，需要把数据包转换成电信号，让其可以在物理介质中传输，这⼀层就是物理层 （Physical Layer），它主要是为数据链路层提供⼆进制传输的服务

【6】TCP/IP网络模型小结

综上所述，网络协议通常是由上到下，分成 5 层没，分别是应⽤层，传输层，网络层，数据链路层和物理层

一句话概括下这几个层

• 应用层 专注于为⽤户提供应⽤功能，不⽤去关⼼数据是如何传输的。

• 传输层 应用层的数据包会传给传输层 也就是说 传输层是为应用层提供网络支持的。

• 网络层 负责将数据从⼀个设备传输到另⼀个设备

  

• 数据链路层 为网络层提供链路级别传输的服务

• 物理层 把数据包转换成电信号，让其可以在物理介质中传输

完整的关系如下

这里没有听懂也木有关系啦~

经典面试题“输入网址到网页显示 期间发生了什么？”会从一个网络包的心路历程开始说起，带我们了解这几个层是如何分工协作将数据包从客户端/服务端送到服务端/客户端的！

这部分内容我们在下面的“计算机网络宏观概念”中会提到！

HTTP相关

4G切换为WIFI的过程中发生了什么？

来自 小林Coding 的图解网络

• 4G切wifi
  • 基于TCP传输协议的HTTP1 HTTP2
    • TCP协议通过四元组确定一条TCP连接 切wifi时 源ip地址会变化 需要先断开TCP连接——卡！
      • 源IP 源端口 目的IP 目的端口
  • 基于QUIC+UDP传输协议的HTTP3.0
    • QUIC协议通过连接ID来标记通信的两个端点（客户端、服务端） 即使切wifi 也不会发生TCP重连（发生了 连接迁移）
  • 

HTTP报文首部

更多具体细节可以读一下《图解HTTP》！讲得可详细了~

通用首部字段

通用首部字段是指，请求报文和响应报文双方都会使用的首部。

请求首部字段

请求首部字段是从客户端往服务器端发送请求报文中所使用的字段， 用于补充请求的附加信息、客户端信息、对响应内容相关的优先级等内容。

响应首部字段

响应首部字段是由服务器端向客户端返回响应报文中所使用的字段， 用于补充响应的附加信息、服务器信息，以及对客户端的附加要求等信息。

实体首部字段

实体首部字段是包含在请求报文和响应报文中的实体部分所使用的首部，用于补充内容的更新时间等与实体相关的信息。

为Cookie服务的首部字段

两个很重要的首部字段！！

简单解析

• 服务器发给客户端的报文中携带的Set-Cookie字段

• 客户端发给服务端的报文中携带的Cookie字段

http1优化——强缓存&协商缓存

《图解网络》

前端性能优化原理与实践 - 修言 - 掘金课程 (opens new window)

强缓存策略和协商缓存策略

字节二面原题orz 当时听都没听说过

”啊？强缓存 对应的是弱缓存么？😫“ ”对应的是协商缓存😑😑“

• 在缓存命中时都会直接使用本地的缓存副本；

• 它们缓存不命中时，都会向服务器发送请求来获取资源。在实际的缓存机制中，强缓存策略和协商缓存策略是一起合作使用的。

  • 浏览器首先会根据请求的信息判断强缓存是否命中，【1】如果命中则直接使用本地资源的副本。如果不命中则【2】根据头信息向服务器发起请求，使用协商缓存——
  • 【3】如果协商缓存命中的话（资源没有过期，服务器响应报文状态码为304 临时重定向），则服务器不返回资源，浏览器直接使用本地资源的副本，如果协商缓存不命中，则服务器返回最新的资源给浏览器。

缓存技术实现

对于一些具有重复性的HTTP请求 比如每次请求得到的数据都是一样的 我们就可以把这对请求-响应的数据都缓存在本地 那么下次就直接读取本地的数据 不必再通过网络获取服务器的响应了~

这样的话HTTP/1.1的性能肯定可以获得肉眼可见的提升！

总结一下上面所说的 避免发送HTTP请求的方法 就是通过==缓存技术==来实现 HTTP设计者早在之前就考虑到了这点 因此HTTP协议的头部有不少是针对缓存的字段

缓存技术实现细节

再来刨根问底一下 缓存是如何做到的呢？

【1】客户端会把第一次请求以及相应的数据保存在本地磁盘上

其中将请求的URL作为key 而响应作为value 两者形成映射关系 URL->响应

这样 当后续发起相同的请求时 就可以先在本地磁盘上通过key查到对应的value 也就是响应 （前提：资源没有过期）

更新缓存的资源

看到这里 新的问题又会出现了——

万一缓存的响应不是最新的，而客户端并不知情 那么该怎么办呢？

这个问题HTTP的设计者也早已考虑到了~

服务器在发送HTTP响应时 会估算一个过期的时间 并把这个信息放到响应头部中——

这样客户端在查看响应头部的信息时，【2】一旦发现缓存的响应是过期的，则就会重新发送网络请求。（强缓存命中则直接使用本地资源的副本。如果不命中则根据头信息向服务器发起请求，使用协商缓存，也就是接下来的【3】）

HTTP关于缓存说明的头部字段很多~这部分内容之后再仔细研究下 暂时不再拓展了

更新缓存资源细节

最后再来思考一个问题——

如果客户端从第⼀次请求得到的响应头部中发现该响应过期了，客户端重新发送请求，假设服务器上的资源并没有 变更，还是⽼样⼦，那么你觉得还要在服务器的响应带上这个资源吗？

很显然不带的话，可以提⾼ HTTP 协议的性能，那具体如何做到呢？

是啊 如果在重新发送请求的时候发现资源并没有变更 那么服务器在响应的时候应该返回什么资源呢？

【3】这个就需要我们在客户端重新发送请求时 在请求的 Etag 头部带上第一次请求的响应头部中的摘要，这个摘要是唯一标识响应的资源，当服务器收到请求后 会将本地资源的摘要（也就是最新的摘要） 与 请求中的摘要（缓存中的摘要）做个比较——

• 如果不同 说明客户端的缓存（URL->响应）已经没有价值 服务器将在响应中带上最新的资源。

• 如果相同 说明客户端的缓存还是可以继续使用的 那么服务器仅返回不含有包体的 304 Not Modified 响应 来告诉客户端“缓存的资源仍然有效哦！” 这样可以减少响应资源在网络中传输的延时！
  • ==协商缓存==

通过本个问题 - “如何避免发送HTTP请求” 对4个小点的研究

我们发现每一个点都包含了“缓存”

可以看出来 缓存真的是性能优化的一把万能钥匙！

小到 CPU Cache、Page Cache、Redis Cache

大到HTTP协议的缓存~

队头阻塞问题-HTTP1.1/2/3

【1】HTTP1.1的问题在于管道化 http请求都是在pipeline里进行传输 虽然可以将多条请求放入请求队列 但是服务器响应时只会响应一个请求

【2】HTTP2的问题主要是因为TCP重传这个机制

【3】所以想改善HTTP2的TCP队头阻塞问题，只能换网络协议——换成UDP 就ok了——HTTP3的内容

• 【1】HTTP 1.1的队头阻塞问题 —— ==HTTP队头阻塞==
  • 存在问题——HTTP管道化

HTTP管道化（在响应到达之前，可以将多条请求放入队列，当第一条请求发往服务器的时候，第二第三条请求也可以开始发送了 要求FIFO）要求服务端必须按照请求发送的顺序返回响应，那如果一个响应返回延迟了，那么其后续的响应都会被延迟（如下图）

HTTP/1.1 中的管道（ pipeline）传输中如果有⼀个请求阻塞了，那么队列后请求也统统被阻塞住了 —— 《图解网络》

• HTTP2通过多路复用解决1.1中的队头阻塞问题 —— ==TCP队头阻塞==
  • 存在问题——如果丢包会触发TCP重传机制，所有http请求都要等着那个丢包被重传回来

移除了 HTTP/1.1 中的请求，服务端不需要按照FIFO的顺序返回响应，而是可以并发地返回响应！

但是这种情况可能产生TCP队头阻塞

HTTP/2 多个HTTP请求复⽤⼀个TCP连接，⼀旦==发⽣丢包==，就会触发TCP的重传机制，阻塞住所有的 HTTP 请求。这样在⼀个 TCP 连接中的所有的 HTTP 请求都必须等待这个丢了的包被重传回来。 ——《图解网络》

• HTTP3把 HTTP 下层的 TCP 协议改成了 UDP

UDP 发⽣是不管顺序，也不管丢包的，所以不会出现 HTTP/1.1 的==队头阻塞== 和 HTTP/2 的==⼀个丢包全部重传问题==

HTTP-超文本传输协-基础概念

《图解网络》

“聊聊HTTP
	HTTP是啥嘞
    详细解释下“超文本传输协议呗”
    HTTP是只用于服务器传客户端嘛？
    HTTP常见的状态码 说几个
    HTTP常见的字段 说几个”

1.HTTP是啥？

超文本传输协议

HyperText Transfer Protocol

• HTTP基于TCP/IP 是关于数据如何在万维网中通信的协议

• HTTP的底层是TCP/IP

• 用于传送 WWW 方式的数据

2.详细解释“超文本传输协议”

分三部分来看——

（很基础了！）

• 协议

协 要求由两个以上的参与者

议 产生对参与者的一种行为约定和规范

对于用在计算机世界中的HTTP协议

它使用计算机能够理解的语言确立了一种

【1】计算机之间交流通信的规范（”协“）

【2】交流通信相关的各种 控制&错误处理 方式（”议“）

• 传输

注意 HTTP协议是一个 双向协议

双向协议：客户端可以发送请求到服务端 服务端也可以把请求数据发送到客户端

同时 也要注意 —— 数据在我们看来是在两点之间传递 但是允许中间由中转/接力

举个例子 第一排的同学传递小纸条到后排同学时 需要经过好多同学

在HTTP中 中间人只要遵循 HTTP协议 并在不打扰基本数据传输的前提下 就可以添加额外的内容

到这里 可以给HTTP协议下一个更加贴切的定义了（加上”两点之间双向传输“这个概念）

HTTP协议是一个在计算机世界中专门用来在==两点之间传输数据==的约定和规范

• 超文本

超越了普通文本的文本 文字、图片、视频、超链接的混合体

HTML就是常见的超文本 可以通过超链接实现跳转 另外 是一个有文字、有画面视频的丰富的网页

• 小结 超文本传输协议 确切一些的定义

记住几个点——”协议——约定和规范“ ”传输——在两点之间“ ”超文本——传输的内容（文字、图片、音视频“

超文本传输协议是

一个在计算机世界里==专门在**「两点」之间「传输」文字、图片、音视频等「超文本」数据的「约定和规范」**==

3.HTTP只能用于 服务端与客户端之间 传输超文本？正确嘛？

• 不正确
• 还可以用于 从服务器传输超文本数据到服务器

所以 HTTP协议 的描述 要这么说——”采用==两点之间==传输超文本“

4.HTTP常见的状态码

这里就顺着说就行了——（举一些常见的例子）

• 成功的报文
• 重定向的报文
  • 请求资源没了 301
  • 请求资源还有 但是要换个URL 302
• 客户端错误
  • 服务器禁止访问 403 Forbidden
  • 服务器上不存在 / 没找到 404 Not Found
• 服务器错误
  • 访问后端服务器发生错误 502 Bad Gateway
  • 服务器正忙 暂时无法响应 503 Service Unavailable

先说说总览

• 1xx 提示信息

协议处理中的一种中间状态 很少用

• 2xx 成功处理请求
  • 「200 OK」 最常见的成功状态码 一切正常！
  • 「204 No Content」 也是很常见的成功状态码 （区别：响应头没有body数据）
  • 「206 Partial Content」是应用于 HTTP 分块下载或断电续传。

表示**==服务器==成功处理了客户端的请求**

• 3xx 重定向请求
  • 「301 Moved Permanently」表示永久重定向，说明请求的资源已经不存在了
  • 「302 Moved Temporarily」表示临时重定向，说明请求的资源还在，但暂时需要用另一个 URL 来访问。
  • 「304 Not Modified」不具有跳转的含义，表示资源未修改，重定向已存在的缓冲文件，也称缓存重定向，用于缓存控制。

表示客户端请求的==资源==发生了==变动==，需要客户端用新的 URL 重新发送请求获取资源，也就是重定向。

• 4xx 客户端错误
  • 「400 Bad Request」表示客户端请求的报文有错误，但只是个笼统的错误。
    • 「403 Forbidden」表示服务器禁止访问资源，并不是客户端的请求出错。
    • 「404 Not Found」表示请求的资源在服务器上不存在或未找到，所以无法提供给客户端。

表示==客户端==发送的报文有误，服务器无法处理，也就是错误码的含义。

• 5xx 服务器错误
  • 「500 Internal Server Error」与 400 类型，是个笼统通用的错误码，服务器发生了什么错误，我们并不知道。
    • 「501 Not Implemented」表示客户端请求的功能还不支持，类似“即将开业，敬请期待”的意思。
    • 「502 Bad Gateway」通常是服务器作为网关或代理时返回的错误码，表示服务器自身工作正常，访问后端服务器发生了错误。
    • 「503 Service Unavailable」表示服务器当前很忙，暂时无法响应服务器，类似“网络服务正忙，请稍后重试”的意思。

表示客户端请求报文正确，但是**==服务器处理时==内部==发生了错误==**，属于服务器端的错误码。

5.HTTP常见字段

==常见字段这里还需要多看些文章学习下！==

HTTP包从应用层被发出（自带HTTP头部） 经过传输层、网络层、链路层之后会加上

TCP头部 IP头部 MAC头部

这些头部中的字段帮助数据包抵达服务端~

HTTP协议的头域包括 通用头，请求头，响应头和实体头 四个部分。

• 每个头域由一个域名，冒号（:）和域值三部分组成。

【1】Host

客户端发送请求时 用来指定服务器的域名

通过Host字段 将请求发往同一台服务器上的不同网站

【2】Content-Length

服务器在返回数据时，会有 Content-Length 字段，表明本次回应的数据长度。

【3】Connection

最常用于客户端要求服务器使用 TCP 持久连接，以便其他请求复用。

HTTP/1.1 版本的默认连接都是持久连接，但为了兼容老版本的 HTTP，需要指定 Connection 首部字段的值为 Keep-Alive。

一个==可以复用的 TCP 连接就这样建立了，直到客户端或服务器主动关闭连接==。

但是，这不是标准字段（是因为用于兼顾老版本么？这里说得不很清楚）。

【4】Content-Type

用于服务器回应时，告诉客户端，本次数据是什么格式。

上面的类型表明，发送的是网页，而且编码是UTF-8。

这里在html后缀文件中经常看到~

【5】Content-Encoding

说明数据的压缩方法。表示服务器返回的数据使用了什么压缩格式

上面表示服务器返回的数据采用了 gzip 方式压缩，告知客户端需要用此方式解压。

同时 客户端在请求时，用 Accept-Encoding 字段说明自己可以接受哪些压缩方法。

Accept-Encoding: gzip, deflate

来聊聊GET POST

图解网络

“来聊聊GET POST
	GET POST 的区别
    这俩方法都是安全和幂等的嘛？”

1.GET POST的区别-edition1

《图解网络》

简单来说

• 一个是发请求给服务器来要资源（GET）

• 一个是发请求给服务器来给服务器提交数据（POST）

与POST恰好相反 一个是索取 一个是给予~

具体来说一下

• Get ⽅法的含义是请求从服务器获取资源。这个资源可以是静态的⽂本、⻚⾯、图⽚视频等。

⽐如，你打开浏览器上的一篇文章，浏览器就会发送 GET 请求给服务器，服务器就会返回⽂章的所有⽂字及资源

• ⽽ POST ⽅法则是相反操作，它向 URI 指定的资源提交数据，数据就放在报⽂的 body ⾥。

  URI，统一资源标志符(Uniform Resource Identifier， URI)

  URL一般指统一资源定位系统（uniform resource locator;URL）

  表示的是web上每一种可用的资源，如 HTML文档、图像、视频片段、程序等都由一个URI进行标识的

  ⽐如，你在小林的公众号中的⽂章底部敲⼊了留⾔后点击「提交」，浏览器就会执⾏⼀次 POST 请求，把你的 留⾔⽂字放进了报⽂ body ⾥，然后拼接好 POST 请求头，通过 TCP 协议发送给服务器

1.GET POST的区别-edition2

更详尽的内容

Post 和 Get 是 HTTP 请求的两种方法，其区别如下：

• 应用场景：GET 请求是一个幂等的请求，一般 Get 请求用于对服务器资源不会产生影响的场景，比如说请求一个网页的资源。而 Post 不是一个幂等的请求，一般用于对服务器资源会产生影响的情景，比如注册用户，提交信息这一类的操作。
• **是否缓存：**因为两者应用场景不同，浏览器一般会对 Get 请求缓存，但很少对 Post 请求缓存。
• **发送的报文格式：**Get 请求的报文中实体部分为空，Post 请求的报文中实体部分一般为向服务器发送的数据。
• **安全性：**Get 请求可以将请求的参数放入 url 中向服务器发送，这样的做法相对于 Post 请求来说是不太安全的，因为请求的 url 会被保留在历史记录中。
• **请求长度：**浏览器由于对 url 长度的限制，所以会影响 get 请求发送数据时的长度。这个限制是浏览器规定的，并不是 RFC 规定的。
• **参数类型：**post 的参数传递支持更多的数据类型。

2.这俩方法都是安全和幂等的嘛？

先说明下安全和幂等的概念：

• 在 HTTP 协议⾥，所谓的「安全」是指请求⽅法不会「破坏」服务器上的资源。
• 所谓的「幂等」，意思是多次执行相同的操作，结果都是「相同」的。（和执行一次一样）

根据上面对两个方法的了解——

• 很明显 GET ⽅法就是安全且==幂等==的，因为它是「只读」操作，⽆论操作多少次，服务器上的数据都是==安全==的，且每次的结果都是相同的

• POST 因为是「新增或提交数据」的操作，会修改服务器上的资源，所以是==不安全的==，且多次提交数据就会创建多个资源，所以==不是幂等的==

HTTPS相关

《图解HTTP》

浏览器灵魂之问 第9篇:HTTPS为什么让数据传输更安全？ (opens new window)

对称加密 & 非对称加密

• 对称加密（也叫共享密钥加密）
  • 不安全！
  • 处理速度较快

• 非对称加密（也叫公开密钥加密）

  • 更加安全（缺点是公开密钥可能被替换，所以使用下面提到的数字证书）
  • 处理速度较慢

  非对称加密~（下面那里写错了哈哈）

HTTPS的混合加密机制

对称加密+非对称加密

可以证明公开密钥正确性的证书-数字证书

HTTPS的通信机制

有点长啊这个！图解HTTP中一共是给出了12步~

下面的内容当作一个了解吧~实际应用中/题目中遇到了再来看看

SSH在git中的作用

SSH是一种协议标准,其目的是实现安全远程登录以及其它安全网络服务.

SSH(Secure Shell)仅仅是一个协议标准 ,其具体的实现有很多,既有开源实现的OpenSSH,也有商业实现方案.使用范围最广泛的当然是开源实现OpenSSH.

如何实现数据的安全呢？首先想到的实现方案肯定是对数据进行加密.加密的方式主要有两种:

1. 对称加密（也称为秘钥加密）
2. 非对称加密（也称公钥加密）

非对称加密

1.远程Server收到Client端用户TopGun的登录请求，Server把自己的公钥发给用户.

2.Client使用这个公钥,将密码进行加密.

3.Client将加密的密码发送给Server端.

4.远程Server用自己的私钥,解密登录密码,然后验证其合法性.

5.若验证结果正确,给Client相应的响应.

可能出现的安全问题，中间人攻击——

Client端不能保证接受到的公钥就是目标Server端的,如果一个攻击者中途拦截Client的登录请求,向其发送自己的公钥,Client端用攻击者的公钥进行数据加密.攻击者接收到加密信息后再用自己的私钥进行解密,不就窃取了Client的登录信息了吗？这就是所谓的中间人攻击

SSH的作用 在非对称加密中 （帮助客户端）对服务端的公钥进行认证

• 在https中可以通过CA来进行公证,可是SSH的publish key和private key都是自己生成的,没法公证.只能通过Client端自己对公钥进行确认

SSH基于公钥进行认证的方式——

作者：shuaiutopia 链接：https://www.jianshu.com/p/cab7e436a7aa 来源：简书 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

下面是面试过程中遇到比较典型的一个问题~

【面试】HTTPS的一个传输过程

21年十一月字节一面时问到的内容

• 非对称加密建立HTTPS连接
• 然后使用对称加密进行报文的收发

追问-说一下非对称加密是如何利用公钥私钥解决安全问题的（之前第一问里有挖坑）

当时答得有点乱，下来整理了一下，感觉清晰不少~

另外搜索非对称算法时，网上好多文章没说的一点就是这个非对称算法是用来干啥的，根据图解HTTP的内容，我的理解是以下几个步骤：

• 【1】客户端有私钥A + 公钥A； 服务器有私钥B + 公钥B
• 【2】规则——私钥A+公钥A = 密钥对A（公钥A加密的内容只有私钥A可以解密！）
• 【3】为了建立安全的通信道路（不被坏人篡改、冒名顶替（窃听就木有办法辣，不过也不怕！我们这个是非对称加密！被窃听了也不会被破解的）），客户端把手里的公钥发送给服务器
• 【4】服务器使用拿到的公钥A进行重要报文（也就是图解HTTP提到的 “稍后的共享密钥加密中要使用的密钥”）的加密，之后再发给客户端
• 【5】客户端手里有私钥A，直接解密这个重要报文，安全地获得共享密钥！妙啊！

这样互联网上的不法分子就没辙辣！

另外还可以使用数字证书解决公开密钥的传输问题 - 图解HTTP很香啊！

我们访问一个网页的大致过程 前后端交互过程

这个问题是从cookie 的 domain字段的内容引起的！

很奇怪这个domain中的“域名”到底是前端服务器的域名还是后端服务器的域名呢？

为啥前端服务器还要个域名呢？

搜素了资料，进行学习

• 前后端交互的过程——
  • cookie生成的时间点

• 拓展下跨域的问题

输入网址到网页显示 期间发生了什么？

这个超级全面的考察问题，能挖多深就挖多深！

浏览器灵魂之问 第3篇: 说一说从输入URL到页面呈现发生了什么？ (opens new window)

浏览器灵魂之问 第4篇: 说一说从输入URL到页面呈现发生了什么？——解析算法篇 (opens new window)

浏览器灵魂之问 第5篇: 说一说从输入URL到页面呈现发生了什么？——渲染过程篇 (opens new window)

跨域CORS问题 (opens new window)？

浏览器并不是拒绝所有的跨域请求，实际上拒绝的是跨域的读操作

严格的说，浏览器并不是拒绝所有的跨域请求，实际上拒绝的是跨域的读操作。浏览器的同源限制策略是这样执行的： 通常浏览器允许进行跨域写操作（Cross-origin writes），如链接，重定向； 通常浏览器允许跨域资源嵌入（Cross-origin embedding），如 img、script 标签； 通常浏览器不允许跨域读操作（Cross-origin reads）。

有个学弟问这块儿来着 找来阮大的文章读读学习一下

另外 MDN对跨域资源共享CORS的解释 (opens new window)

CORS是一个W3C标准，全称是**"跨域资源共享"（Cross-origin resource sharing）**。

它允许浏览器向跨源服务器，发出XMLHttpRequest (opens new window)请求，从而克服了AJAX只能同源 (opens new window)使用的限制。

本文详细介绍CORS的内部机制。

CORS需要浏览器和服务器同时支持。目前，所有浏览器都支持该功能，IE浏览器不能低于IE10。

浏览器一旦发现AJAX请求跨源，就会自动添加一些附加的头信息，有时还会多出一次附加的请求（确定是否同源的请求），但用户不会有感觉。

因此，实现CORS通信的关键是服务器。只要服务器实现了CORS接口，就可以跨源通信。

简单请求、非简单请求

浏览器将CORS请求分成两类：简单请求（simple request）和非简单请求（not-so-simple request）。

只要同时满足以下两大条件，就属于简单请求。

（1) 请求方法是以下三种方法之一：

• HEAD
• GET
• POST

（2）HTTP的头信息不超出以下几种字段：

• Accept
• Accept-Language
• Content-Language
• Last-Event-ID
• Content-Type：只限于三个值application/x-www-form-urlencoded、multipart/form-data、text/plain

凡是不同时满足上面两个条件，就属于非简单请求。

简单请求的流程

对于简单请求，浏览器直接发出CORS请求。具体来说，就是在头信息之中，增加一个Origin字段。

下面是一个例子，浏览器发现这次跨源AJAX请求是简单请求，就自动在头信息之中，添加一个Origin字段。

GET /cors HTTP/1.1
Origin: http://api.bob.com
Host: api.alice.com
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0...

上面的头信息中，Origin字段用来说明，本次请求来自哪个源（协议 + 域名 + 端口）。服务器根据这个值，决定是否同意这次请求。

如果Origin指定的源，不在许可范围内，服务器会返回一个正常的HTTP回应。浏览器发现，这个回应的头信息没有包含Access-Control-Allow-Origin字段（详见下文），就知道出错了，从而抛出一个错误，被XMLHttpRequest的onerror回调函数捕获。注意，这种错误无法通过状态码识别，因为HTTP回应的状态码有可能是200。

如果Origin指定的域名在许可范围内，服务器返回的响应，会多出几个头信息字段，如下的123行

Access-Control-Allow-Origin: 'http://api.bob.com' 
// 该字段是必须的。它的值要么是请求时Origin字段的值，要么是一个*，表示接受任意域名的请求。
Access-Control-Allow-Credentials: true 
// 该字段可选。它的值是一个布尔值，表示是否允许发送Cookie 设为true，即表示服务器明确许可，Cookie可以包含在请求中，一起发给服务器。
Access-Control-Expose-Headers: FooBar  如果想拿到其他字段，就必须在这里面指定
// 上面的例子指定，getResponseHeader('FooBar')可以返回FooBar字段的值。
Content-Type: text/html; 
charset=utf-8;

上面的头信息之中，有三个与CORS请求相关的字段，都以Access-Control-开头。

解决跨域的几种方式

• JSONP 使用script标签向后台请求数据，只适用于get请求

• CORS是让服务器端设置Access-Control-Allow-Origin（头部字段），这样浏览器就不会报跨域错误

• 反向代理，搭建一个自己的服务器，让自己的服务器请求数据，拿到数据之后再返回给我自己

Cookie&Session

COOKIE和SESSION有什么区别？ - 知乎 (opens new window)

• Session是在服务端保存的一个数据结构，用来跟踪用户的状态，这个数据可以保存在集群、数据库、文件中；

  • 用户验证这种场合一般会用 session

• Cookie是客户端保存用户信息的一种机制，用来记录用户的一些信息，也是实现Session的一种方式。

  • session id 是存在 cookie 中

操作系统

简单的操作系统学习资料

前端er也要掌握的操作系统知识！https://zhuanlan.zhihu.com/p/268219780?msclkid=23e52f55ab7111ec98d5b55925f4d474