计算机网络
文章目录
- 一、基础
-
- 1. 什么是网络协议?为什么要对协议分层
- 2. OSI七层模型
- 3.TCP/IP四层模型
- 4. 5层模型
- 5. 端口
- 6. 每一层的数据封装
- 三、TCP 与 UDP （运输层）
-
- 1. TCP 与 UDP区别
- 2. 什么时候用TCP?什么时候用UDP?
- 3. 建立连接-TCP三次握手
-
- 3.0 概述
- 3.1 为什么要三次握手?
- 3.2 第2次握手传回了ACK，为什么还要传回SYN？
- 3.3 什么是半连接队列
- 3.4 三次握手过程中可以携带数据吗
- 3.5 为什么不能进行两次握手？
- 4. 断开连接-TCP四次挥手
-
- 4.0 概述
- 4.1 为什么要四次挥手
- 4.2 为什么不能把服务器发送的 ACK 和 FIN 合并起来，变成三次挥手？
- 4.3 如果第二次挥手时服务器的 ACK 没有送达客户端，会怎样？
- 4.4 为什么第四次挥手客户端需要等待 2*MSL（报文段最长寿命）时间后才进入 CLOSED 状态？
- 4.5 TIME_WAIT和CLOSE_WAIT的区别
- 5. TCP如何保证数据传输可靠性
- 6. 粘包或者拆包？以及如何解决？
- 7. TCP首部有哪些标志位?TCP首部报文格式
- 8. 如果已经建立了连接，但是客户端突然出现故障了怎么办？
- 9. TCP的套接字
- 10. 知道ip和port就可以生成tcp连接吗？
- 11. TCP的Socket编程
- 四、应用层(DNS、Http)
-
- 1. DNS工作流程
- 2. 从输入URL 到页面展示到底发生了什么？
- 3. Http状态码
- 4. Http与Https的区别
- 5. Http1.0与Http1.1区别
- 6. HTTP 是不保存状态的协议, 如何保存用户状态?
- 7. URL和URI的区别
- 8. Session,cookie,token,jwt
- 9. 对称加密和非对称加密
- 10. https加密过程
- 11. Http报文结构,头部有哪些信息？
- 12. HTTP从1到2到3都有哪些改进？
- 13. GET和POST对比
- 14. Keep-Alive
- 15. 保活计时器
- 16. Http常见方法
- 17. Http缓存技术
- 18. Http常见字段？
- 19. RPC
- 20. Http与Https建立连接的过程
- 五、网络层(ARP,IP协议)
-
- 1. 什么是MAC地址？
- 2. 了解ARP协议吗
- 3. ping的工作原理
- 4. 断网了，还能 ping 通 127.0.0.1 吗？
- 5. 路由器和交换机的区别
- 6. 正向代理和反向代理
微课堂详细笔记
一、基础
1. 什么是网络协议?为什么要对协议分层
- 协议：
计算机在通信过程中要遵循的一些约定好的规则 - 分层原因:
- 各层之间相互独立，各层之间相互独立，各层之间不需要关心其他层是如何实现的，只需要知道自己如何调用下层提供好的功能就可以了（可以简单理解为接口调用）。
- 提高了整体灵活性 ：每一层都可以使用最适合的技术来实现，你只需要保证你提供的功能以及暴露的接口的规则没有改变就行了。这个和我们平时开发系统的时候要求的高内聚、低耦合的原则也是可以对应上的。
- 大问题化小 ： 分层可以将复杂的网络问题分解为许多比较小的、界线比较清晰简单的小问题来处理和解决。这样使得复杂的计算机网络系统变得易于设计，实现和标准化。 这个和我们平时开发的时候，一般会将系统功能分解，然后将复杂的问题分解为容易理解的更小的问题是相对应的，这些较小的问题具有更好的边界（目标和接口）定义。
2. OSI七层模型
应用层协议 :HTTP 协议（超文本传输协议，网页浏览常用的协议）DHCP 协议（动态主机配置）DNS 系统原理（域名系统）FTP 协议（文件传输协议）Telnet协议（远程登陆协议）电子邮件协议等（SMTP、POP3、IMAP）…
传输层协议 :TCP 协议 报文段结构可靠数据传输流量控制拥塞控制UDP 协议 报文段结构RDT（可靠数据传输协议）
网络层协议 :IP 协议（TCP/IP 协议的基础，分为 IPv4 和 IPv6）ARP 协议（地址解析协议，用于解析 IP 地址和 MAC 地址之间的映射）ICMP 协议（控制报文协议，用于发送控制消息）NAT 协议（网络地址转换协议）RIP 协议、OSPF 协议、BGP 协议（路由选择协议）…
网络接口层 :差错检测技术多路访问协议（信道复用技术）CSMA/CD 协议MAC 协议以太网技术…
物理层：底层数据传输，如网线；网卡标准。
数据链路层：定义数据的基本格式，如何传输，如何标识；如网卡MAC地址。
网络层：定义IP编址，定义路由功能；如不同设备的数据转发。
传输层：端到端传输数据的基本功能；如 TCP、UDP。
会话层：控制应用程序之间会话能力；如不同软件数据分发给不同软件。
表示层：数据格式标识，基本压缩加密功能。
应用层：各种应用软件，包括 Web 应用。
3.TCP/IP四层模型
- 应用层
主要提供两个终端设备上的应用程序之间信息交换的服务，它定义了信息交换的格式，消息会交给下一层传输层来传输。 我们把应用层交互的数据单元称为报文。 - 传输层
传输层的主要任务就是负责向两台终端设备进程之间的通信提供通用的数据传输服务。TCP UDP - 网络层
选择合适的网间路由和交换结点。在发送数据时，网络层把运输层产生的报文段或用户数据报封装成分组和包进行传送。在 TCP/IP 体系结构中，由于网络层使用 IP 协议，因此分组也叫 IP 数据报，简称数据报。
网络层的主要作用是：实现主机与主机之间的通信，也叫点对点（end to end）通信。 - 网络接口层
我们可以把网络接口层看作是数据链路层和物理层的合体。
数据链路层(data link layer)通常简称为链路层（ 两台主机之间的数据传输，总是在一段一段的链路上传送的）。数据链路层的作用是将网络层交下来的 IP 数据报组装成帧，在两个相邻节点间的链路上传送帧。每一帧包括数据和必要的控制信息（如同步信息，地址信息，差错控制等）。
物理层的作用是实现相邻计算机节点之间比特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异
4. 5层模型
5. 端口
当设备作为接收方时，传输层则要负责把数据包传给应用，但是一台设备上可能会有很多应用在接收或者传输数据，因此需要用一个编号将应用区分开来，这个编号就是端口。
比如 80 端口通常是 Web 服务器用的，22 端口通常是远程登录服务器用的。而对于浏览器（客户端）中的每个标签栏都是一个独立的进程，操作系统会为这些进程分配临时的端口号。
由于传输层的报文中会携带端口号，因此接收方可以识别出该报文是发送给哪个应用。
6. 每一层的数据封装
报文/段/包/帧
三、TCP 与 UDP （运输层）
1. TCP 与 UDP区别
答题公式：3(面向连接，可靠，基于字节流) + 3（首部开销，服务对象，拥塞控制）+ 1应用(什么时候用哪种)
面向连接：传送数据之前是否需要建立连接
可靠传输： TCP有三次握手四次挥手
有状态：这个有状态说的是 TCP 会去记录自己发送消息的状态比如消息是否发送了、是否被接收了等等
2. 什么时候用TCP?什么时候用UDP?
UDP 一般用于即时通信，比如： 语音、 视频 、直播等等。这些场景对传输数据的准确性要求不是特别高，比如你看视频即使少个一两帧，实际给人的感觉区别也不大。
TCP 用于对传输准确性要求特别高的场景，比如文件传输、发送和接收邮件、远程登录等等。
3. 建立连接-TCP三次握手
3.0 概述
- 一次握手
客户端发送带有 SYN（SEQ=x） 标志的数据包 -> 服务端，然后客户端进入 SYN_SEND 状态，等待服务器的确认； - 二次握手
服务端发送带有 SYN+ACK(SEQ=y,ACK=x+1) 标志的数据包 –> 客户端,然后服务端进入 SYN_RECV 状态 - 三次握手
客户端发送带有 ACK(ACK=y+1) 标志的数据包 –> 服务端，然后客户端和服务器端都进入ESTABLISHED 状态，完成TCP三次握手。当建立了 3 次握手之后，客户端和服务端就可以传输数据啦
3.1 为什么要三次握手?
三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。
- 第一次握手
客户端什么都不能确定；服务端确定对方发送正常，自己接收正常 - 第二次握手
客户端确定自己发送、接收正常，对方发送、接收正常；服务端确认了，对方发送正常，自己接收正常 - 第三次握手
客户端确定自己发送、接收正常，对方发送、接收正常；服务端确认了，对方发送、接收正常，自己发送、接收正常
作用：
1、确认双方的接受能力、发送能力是否正常。
2、指定自己的初始化序列号ISN，为后面的可靠传送做准备。
3.2 第2次握手传回了ACK，为什么还要传回SYN？
服务端传回发送端所发送的 ACK 是为了告诉客户端：“我接收到的信息确实就是你所发送的信号了”，这表明从客户端到服务端的通信是正常的。(响应对方)
回传 SYN 则是为了建立并确认从服务端到客户端的通信。(想建立通信)
SYN 同步序列编号(Synchronize Sequence Numbers) 是 TCP/IP 建立连接时使用的握手信号
ACK(Acknowledgement）消息响应
3.3 什么是半连接队列
服务器第一次收到客户端的 SYN 之后，就会处于 SYN_RCVD 状态，此时双方还没有完全建立其连接，服务器会把此种状态下请求连接放在一个队列里，我们把这种队列称之为半连接队列。（只进行了一次握手）
当然还有一个全连接队列，就是已经完成三次握手，建立起连接的就会放在全连接队列中。如果队列满了就有可能会出现丢包现象。
3.4 三次握手过程中可以携带数据吗
很多人可能会认为三次握手都不能携带数据，其实第三次握手的时候，是可以携带数据的。也就是说**，第一次、第二次握手不可以携带数据，而第三次握手是可以携带数据的。**
为什么这样呢？大家可以想一个问题，假如第一次握手可以携带数据的话，如果有人要恶意攻击服务器，那他每次都在第一次握手中的 SYN 报文中放入大量的数据，因为攻击者根本就不理服务器的接收、发送能力是否正常，然后疯狂着重复发 SYN 报文的话，这会让服务器花费很多时间、内存空间来接收这些报文。也就是说，第一次握手可以放数据的话，其中一个简单的原因就是会让服务器更加容易受到攻击了。
而对于第三次的话，此时客户端已经处于 established 状态，也就是说，对于客户端来说，他已经建立起连接了，并且也已经知道服务器的接收、发送能力是正常的了，所以能携带数据页没啥毛病。
3.5 为什么不能进行两次握手？
3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。
现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分 组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。
4. 断开连接-TCP四次挥手
4.0 概述
第一次挥手 ：客户端发送一个 FIN（SEQ=X） 标志的数据包->服务端，用来关闭客户端到服务器的数据传送。然后，客户端进入 FIN-WAIT-1 状态。
第二次挥手 ：服务器收到这个 FIN（SEQ=X） 标志的数据包，它发送一个 ACK （SEQ=X+1）标志的数据包->客户端 。然后，此时服务端进入CLOSE-WAIT状态，客户端进入FIN-WAIT-2状态。
第三次挥手 ：服务端关闭与客户端的连接并发送一个 FIN (SEQ=y)标志的数据包->客户端请求关闭连接，然后，服务端进入LAST-ACK状态
第四次挥手 ：客户端发送 ACK (SEQ=y+1)标志的数据包->服务端并且进入TIME-WAIT状态，服务端在收到 ACK (SEQ=y+1)标志的数据包后进入 CLOSE 状态。此时，如果客户端等待 2MSL 后依然没有收到回复，就证明服务端已正常关闭，随后，客户端也可以关闭连接了。
(个人理解，FIN就是断开连接的,A发给B就是断A到B；ACK就是响应对方，告诉对方我知道了)
4.1 为什么要四次挥手
TCP是全双工通信，可以双向传输数据。任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了 TCP 连接。
4.2 为什么不能把服务器发送的 ACK 和 FIN 合并起来，变成三次挥手？
因为服务器收到客户端断开连接的请求时，可能还有一些数据没有发完，这时先回复 ACK，表示接收到了断开连接的请求。
等到数据发完之后再发 FIN，断开服务器到客户端的数据传送。
4.3 如果第二次挥手时服务器的 ACK 没有送达客户端，会怎样？
客户端没有收到 ACK 确认，会重新发送 FIN 请求。
4.4 为什么第四次挥手客户端需要等待 2*MSL（报文段最长寿命）时间后才进入 CLOSED 状态？
第四次挥手时，客户端发送给服务器的 ACK 有可能丢失，如果服务端因为某些原因而没有收到 ACK 的话，服务端就会重发 FIN，如果客户端在 2*MSL 的时间内收到了 FIN，就会重新发送 ACK 并再次等待 2MSL，防止 Server 没有收到 ACK 而不断重发 FIN。
(因为第四次挥手客户端发送的ACK会丢失，如果丢失的话，服务端他就会重发FIN，假如客户端已经关闭了，那这个服务端就会不断地发送FIN。)
MSL(Maximum Segment Lifetime) : 一个片段在网络中最大的存活时间，2MSL 就是一个发送和一个回复所需的最大时间。如果直到 2MSL，Client 都没有再次收到 FIN，那么 Client 推断 ACK 已经被成功接收，则结束 TCP 连接。
4.5 TIME_WAIT和CLOSE_WAIT的区别
close_wait是被动关闭形成(二次挥手，服务器响应ACK)
time_wait是主动形成(四次挥手，客户端发送FIN)
5. TCP如何保证数据传输可靠性
- 可靠体现在：有状态、可控制
有状态是指 TCP 会确认发送了哪些报文，接收方收到了哪些报文，哪些没有收到，保证数据包按序到达，不允许有差错
可控制的是指，如果出现丢包或者网络状况不佳，则会跳转自己的行为，减少发送的速度或者重发
- 具体包括:
校验和、序列号、超时重传、流量控制、拥塞避免 - 校验和
在发送端和接收端分别计算数据的校验和，如果两者不一致，则说明数据在传输过程中出现了差错，TCP将丢弃和不确认此报文段。 - 序列号
TCP会对每一个发送的字节进行编号，接收方接到数据后，会对发送方发送确认应答(ACK报文)，并且这个ACK报文中带有相应的确认编号，告诉发送方，下一次发送的数据从编号多少开始发。
- 超时重传
如果发送方在发送数据后一段时间内没有收到确认序号ACK，那么ACK会重新发送数据。 - 流量控制
如果发送端发送数据太快，接收端来不及接收就会出现丢包问题。为了解决这个问题，TCP协议利用了滑动窗口进行了流量控制。在TCP首部有一个16位字段大小的窗口，窗口的大小就是接收端接收数据缓冲区的剩余大小。接收端会在收到数据包后发送ACK报文时，将自己的窗口大小填入ACK中，发送方会根据ACK报文中的窗口大小进而控制发送速度。如果窗口大小为零，发送方将停止发送数据。 - 拥塞避免
如果网络出现拥塞，则会产生丢包问题，这时发送方会将丢失的数据包继续重传，网络拥塞会更加严重，所以在网络出现拥塞时，应注意控制发送方的发送数据，降低整个网络的拥塞程度。
拥塞控制包括：慢开始，拥塞避免，快重传，快恢复。
拥塞窗口： 根据网络的拥塞情况动态确定的，一般来说发送方真实的发送窗口为滑动窗口和拥塞窗口中的最小值。
慢开始： 为了避免一开始发送大量的数据而产生网络阻塞，会先初始化cwnd为1，当收到ACK后到达下一个传输轮次，cwnd为2，以此类推以指数形式增长。
拥塞避免： 当拥塞窗口大小到达门限值ssthresh，进入到拥塞避免阶段，每个轮次cwnd增加1。如果网络出现超时，会将门限值ssthresh变为出现超时cwnd数值的一半,cwnd重新设置为1。
快重传： 在网络中如果出现超时或阻塞，则按慢开始和拥塞避免算法进行调整，但如果只是丢失某一个报文段，则使用快重传算法。
在发送方收到三个M2的确认报文后，无需等待重传计时器所设置的时间，可以直接进行M3的重传。
快恢复： 将门限值设置为发生快重传时的拥塞窗口cwnd数量的一半，而cwnd不是设置为1而是设置为门限值，并开始拥塞避免阶段。
6. 粘包或者拆包？以及如何解决？
- 定义
-因为TCP是面向流，没有边界，而操作系统在发送TCP数据时，会通过缓冲区来进行优化，例如缓冲区为1024个字节大小。
如果一次请求发送的数据量比较小，没达到缓冲区大小，TCP则会将多个请求合并为同一个请求进行发送，这就形成了粘包问题。
如果一次请求发送的数据量比较大，超过了缓冲区大小，TCP就会将其拆分为多次发送，这就是拆包。 - 解决方案
- 发送端将每个包都封装成固定的长度，比如100字节大小。如果不足100字节可通过补0或空等进行填充到指定长度；
- 发送端在每个包的末尾使用固定的分隔符，例如\r\n。如果发生拆包需等待多个包发送过来之后再找到其中的\r\n进行合并；例如，FTP协议；
- 将消息分为头部和消息体，头部中保存整个消息的长度，只有读取到足够长度的消息之后才算是读到了一个完整的消息；
- 通过自定义协议进行粘包和拆包的处理。
7. TCP首部有哪些标志位?TCP首部报文格式
-
标志位
ACK：确认序号有效。
FIN：释放一个连接。
PSH：接收方应该尽快将这个报文交给应用层。
RST：重置连接。
SYN：发起一个新连接。
URG：紧急指针（urgent pointer）有效。此标志用于将输入数据标识为“紧急”。这样的进入段不必等待直到先前段被接收端消耗，而是直接发送并立即处理。 -
首部报文格式
序号：Seq序号，占32位。用于说明当前数据第一个字节在所有数据(整个文件)中的位置
确认号：Ack序号，占32位。用于告诉发送者接下来需要发送的数据序号。
数据偏移：用于说明首部长度。(比如1111说明首部长为15*4字节)
标志位：tcp标志位有6种
8. 如果已经建立了连接，但是客户端突然出现故障了怎么办？
TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。
9. TCP的套接字
TCP把连接作为最基本的抽象单元，每条TCP连接有两个端点，TCP连接的端点即套接字。
套接字socket = （IP地址+端口号）
TCP连接={socket1，socket2}={（IP1:port1），（IP2,port2）}
TCP提供全双工通信。
10. 知道ip和port就可以生成tcp连接吗？
读者回答：客户端有对方的ip和端口，然后调用connect()，服务器端也要选择所有ip都能访问。(不确定答案正确与否)
11. TCP的Socket编程
四、应用层(DNS、Http)
1. DNS工作流程
- 定义
domain name system域名系统，是因特网上域名和ip地址相互映射的一个分布式数据库 - 是集群工作还是单点工作
集群工作，单点工作容易导致因特网崩了 - 递归查询和迭代查询
递归查询：主机向本地域名发送查询请求报文，而本地域名服务器不知道域名对应的Ip地址时，本地域名会继续向根域名发送查询请求报文。 A—B-----C
迭代查询：本地域名服务器向根域名发出查询请求报文后，根域名不会继续向顶级域名服务器发送查询，而是通知本地域名服务器向顶级域名发送查询请求报文。 A-----B A------C（B让A问C）
主机向本地域名服务器查询一般是递归查询，而本地域名服务器向根域名服务器查询一般是迭代查询 - 工作流程
输入域名，检查本地host文件
本地DNS解析器缓存
本地DNS服务器
根域名服务器
顶级域名服务器
权限域名服务器
本地域名服务器告诉主机的ip地址
2. 从输入URL 到页面展示到底发生了什么？
- DNS 解析：
浏览器查询 DNS，获取域名对应的 IP 地址：具体过程包括浏览器搜索自身的 DNS 缓存、搜索操作系统的 DNS 缓存、读取本地的 Host 文件和向本地 DNS 服务器进行查询等。 - TCP 连接：
浏览器获得域名对应的 IP 地址以后，浏览器向服务器请求建立链接，发起三次握手； - 发送 HTTP 请求：
TCP 连接建立起来后，浏览器向服务器发送 HTTP 请求； - 服务器处理请求并返回 HTTP 报文：
服务器接收到这个请求，并根据路径参数映射到特定的请求处理器进行处理，并将处理结果及相应的视图返回给浏览器； - 浏览器解析渲染页面：
浏览器解析并渲染视图，若遇到对 js 文件、css 文件及图片等静态资源的引用，则重复上述步骤并向服务器请求这些资源；浏览器根据其请求到的资源、数据渲染页面，最终向用户呈现一个完整的页面。 - 连接结束
3. Http状态码
- 「200 OK」是最常见的成功状态码，表示一切正常。如果是非 HEAD 请求，服务器返回的响应头都会有 body 数据。
- 「204 No Content」也是常见的成功状态码，与 200 OK 基本相同，但响应头没有 body 数据。
- 「206 Partial Content」是应用于 HTTP 分块下载或断点续传，表示响应返回的 body 数据并不是资源的全部，而是其中的一部分，也是服务器处理成功的状态。
- 「301 Moved Permanently」表示永久重定向，说明请求的资源已经不存在了，需改用新的 URL 再次访问。
- 「302 Found」表示临时重定向，说明请求的资源还在，但暂时需要用另一个 URL 来访问。
- 「304 Not Modified」不具有跳转的含义，表示资源未修改，重定向已存在的缓冲文件，也称缓存重定向，也就是告诉客户端可以继续使用缓存资源，用于缓存控制。
- 「400 Bad Request」表示客户端请求的报文有错误，但只是个笼统的错误。
- 「403 Forbidden」表示服务器禁止访问资源，并不是客户端的请求出错。
- 「404 Not Found」表示请求的资源在服务器上不存在或未找到，所以无法提供给客户端。
- 「500 Internal Server Error」与 400 类型，是个笼统通用的错误码，服务器发生了什么错误，我们并不知道。
- 「501 Not Implemented」表示客户端请求的功能还不支持，类似“即将开业，敬请期待”的意思。
- 「502 Bad Gateway」通常是服务器作为网关或代理时返回的错误码，表示服务器自身工作正常，访问后端服务器发生了错误。
- 「503 Service Unavailable」表示服务器当前很忙，暂时无法响应客户端，类似“网络服务正忙，请稍后重试”的意思
4. Http与Https的区别
- 端口号
Http:80 Https:443 - URL前缀
http:// https:// - 安全性和资源消耗
Http协议运行在TCP之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份
HTTPS 是运行在 SSL/TLS 之上的 HTTP 协议，SSL/TLS 运行在 TCP 之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密
https安全性高，但耗费更多资源
5. Http1.0与Http1.1区别
连接方式
1.0短连接，1.1长连接
短连接指每次请求都要重新建立一次TCP连接，资源消耗大
状态响应码
http1.1新增了一些状态响应码
缓存处理
在 HTTP1.0 中主要使用 header 里的 If-Modified-Since,Expires 来做为缓存判断的标准，
HTTP1.1 则引入了更多的缓存控制策略例如 Entity tag，If-Unmodified-Since, If-Match, If-None-Match 等更多可供选择的缓存头来控制缓存策略。
带宽优化及网络连接的使用
HTTP1.0 中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1 则在请求头引入了 range 头域，它允许只请求资源的某个部分，即返回码是 206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
Host头处理
HTTP/1.1在请求头中加入了Host字段。
6. HTTP 是不保存状态的协议, 如何保存用户状态?
(超文本传输协议)
Session 机制的存在就是为了解决这个问题，Session 的主要作用就是通过服务端记录用户的状态
- 如何实现 Session 跟踪？
通过在 Cookie 中附加一个 Session ID 来方式来跟踪。 - Cookie被禁用怎么办?
最常用的就是利用 URL 重写把 Session ID 直接附加在 URL 路径的后面。
7. URL和URI的区别
URI(Uniform Resource Identifier) 是统一资源标志符，可以唯一标识一个资源。
URL(Uniform Resource Locator) 是统一资源定位符，可以提供该资源的路径。它是一种具体的 URI，即 URL 可以用来标识一个资源，而且还指明了如何 locate 这个资源。URL是URI的子集
URI 的作用像身份证号一样，URL 的作用更像家庭住址一样。URL 是一种具体的 URI，它不仅唯一标识资源，而且还提供了定位该资源的信息
只要能唯一标识资源的就是 URI，在 URI 的基础上给出其资源的访问方式的就是 URL。
8. Session,cookie,token,jwt
JWT （JSON Web Token）通常可以称为 Json 令牌,本质上就是一段签名的 JSON 格式的数据
- 补充
资料1
资料2
思考：这四者区别，应用场景
cookie：保存在客户端浏览器种，有大小限制，大小不能超过4K，且受到浏览器本身对cookie个数限制，大约不超过50个，有时效和状态限制。
session：保存在服务端中，可以存储在内存或者数据，分布式、跨系统不好实现。
Token：Token保存在客户端任何地方，适用于分布式部署。
- TOKEN和JWT对比
Token：服务端验证客户端发送过来的 Token 时，还需要查询数据库获取用户信息，然后验证 Token 是否有效。
JWT：将 Token 和 Payload 加密后存储于客户端，服务端只需要使用密钥解密进行校验（校验也是 JWT 自己实现的）即可，不需要查询或者减少查询数据库，因为 JWT 自包含了用户信息和加密的数据。
9. 对称加密和非对称加密
发送方用对方公钥加密，接收方用自己私钥解密
10. https加密过程
结合对称加密和非对称加密，使用非对称加密来传输对称密来保证安全性，使用对称加密来保证通信的效率。
- 数字签名
为了避免数据在传输过程中被替换，比如黑客修改了你的报文内容，但是你并不知道，所以我们让发送端做一个数字签名，把数据的摘要消息进行一个加密，比如 MD5得到一个签名，和数据一起发送。然后接收端把数据摘要进行 MD5 加密，如果和签名一样，则说明数据确实是真的。 - 数字证书
虽然数字签名可以保证数据不被替换，但是数据是由公钥加密的，如果公钥也被替换，则仍然可以伪造数据，因为用户不知道对方提供的公钥其实是假的。所以为了保证发送方的公钥是真的，CA 证书机构会负责颁发一个证书，里面的公钥保证是真的，用户请求服务器时，服务器将证书发给用户，这个证书是经由系统内置证书的备案的
11. Http报文结构,头部有哪些信息？
请求报文
响应报文
12. HTTP从1到2到3都有哪些改进？
- HTTP2.0相比HTTP1.1支持的特性：
新的二进制格式：HTTP1.1 基于文本格式传输数据；HTTP2.0采用二进制格式传输数据，解析更高效。
多路复用(并发传输)：在一个连接里，允许同时发送多个请求或响应，并且这些请求或响应能够并行的传输而不被阻塞，避免 HTTP1.1 出现的”队头堵塞”问题。(通过Stream来实现)
头部压缩，HTTP/2 会压缩头（Header）如果你同时发出多个请求，他们的头是一样的或是相似的，那么，协议会帮你消除重复的部分。
这就是所谓的HPACK算法：在客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就提高速度了。
服务端推送：HTTP2.0允许服务器向客户端推送资源，无需客户端发送请求到服务器获取。 - HTTP3
- 队头阻塞问题
HTTP/2 是基于 TCP 协议来传输数据的，TCP 是字节流协议，TCP 层必须保证收到的字节数据是完整且连续的，这样内核才会将缓冲区里的数据返回给 HTTP 应用，那么当「前 1 个字节数据」没有到达时，后收到的字节数据只能存放在内核缓冲区里，只有等到这 1 个字节数据到达时，HTTP/2 应用层才能从内核中拿到数据，这就是 HTTP/2 队头阻塞问题。
图中发送方发送了很多个 packet，每个 packet 都有自己的序号，你可以认为是 TCP 的序列号，其中 packet 3 在网络中丢失了，即使 packet 4-6 被接收方收到后，由于内核中的 TCP 数据不是连续的，于是接收方的应用层就无法从内核中读取到，只有等到 packet 3 重传后，接收方的应用层才可以从内核中读取到数据，这就是 HTTP/2 的队头阻塞问题，是在 TCP 层面发生的。
所以，一旦发生了丢包现象，就会触发 TCP 的重传机制，这样在一个 TCP 连接中的所有的 HTTP 请求都必须等待这个丢了的包被重传回来。
HTTP/2 队头阻塞的问题是因为 TCP，所以HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP！但基于 UDP 的QUIC 协议可以实现类似 TCP 的可靠性传输
13. GET和POST对比
上述的安全性是针对实际开发，幂等性是针对RFC规范而言的，如果从RFC规范和定义来看，GET方法安全且幂等，POST不安全不幂等
14. Keep-Alive
在此之前的 HTTP 版本的默认连接都是使用非持久连接，如果想要在旧版本的 HTTP 协议上维持持久连接，则需要指定 connection 的首部字段的值为 Keep-Alive 来告诉对方这个请求响应完成后不要关闭，下一次咱们还用这个请求继续交流
15. 保活计时器
除时间等待计时器外，TCP 还有一个保活计时器（keepalive timer）。设想这样的场景：客户已主动与服务器建立了 TCP 连接。但后来客户端的主机突然发生故障。显然，服务器以后就不能再收到客户端发来的数据。因此，应当有措施使服务器不要再白白等待下去。这就需要使用保活计时器了。
服务器每收到一次客户的数据，就重新设置保活计时器，时间的设置通常是两个小时。若两个小时都没有收到客户端的数据，服务端就发送一个探测报文段，以后则每隔 75 秒钟发送一次。若连续发送 10个 探测报文段后仍然无客户端的响应，服务端就认为客户端出了故障，接着就关闭这个连接。
16. Http常见方法
GET：获取资源，当前网络中绝大部分使用的都是 GET；
HEAD：获取报文首部，和 GET 方法类似，但是不返回报文实体主体部分；
POST：传输实体主体
PUT：上传文件，由于自身不带验证机制，任何人都可以上传文件，因此存在安全性问题，一般不使用该方法。
PATCH：对资源进行部分修改。PUT 也可以用于修改资源，但是只能完全替代原始资源，PATCH 允许部分修改。
OPTIONS：查询指定的 URL 支持的方法；
CONNECT：要求在与代理服务器通信时建立隧道。使用 SSL（Secure Sockets Layer，安全套接层）和 TLS（Transport Layer Security，传输层安全）协议把通信内容加密后经网络隧道传输。
TRACE：追踪路径。服务器会将通信路径返回给客户端。发送请求时，在 Max-Forwards 首部字段中填入数值，每经过一个服务器就会减 1，当数值为 0 时就停止传输。通常不会使用 TRACE，并且它容易受到 XST 攻击（Cross-Site Tracing，跨站追踪）。
Delete：删除文件,与 PUT 功能相反，并且同样不带验证机制。
17. Http缓存技术
对于一些具有重复性的 HTTP 请求，比如每次请求得到的数据都一样的，我们可以把这对「请求-响应」的数据都缓存在本地，那么下次就直接读取本地的数据，不必在通过网络获取服务器的响应了。http缓存主要有强制缓存和协商缓存。
- 强制缓存
强缓存指的是只要浏览器判断缓存没有过期，则直接使用浏览器的本地缓存，决定是否使用缓存的主动性在于浏览器这边。
强制缓存是利用下面这两个 HTTP 响应头部（Response Header）字段实现的，它们都用来表示资源在客户端缓存的有效期：
Cache-Control， 是一个相对时间；
Expires，是一个绝对时间； - 协商缓存
当我们在浏览器使用开发者工具的时候，你可能会看到过某些请求的响应码是 304，这个是告诉浏览器可以使用本地缓存的资源，通常这种通过服务端告知客户端是否可以使用缓存的方式被称为协商缓存
协商缓存这两个字段都需要配合强制缓存中 Cache-Control 字段来使用，只有在未能命中强制缓存的时候，才能发起带有协商缓存字段的请求。
18. Http常见字段？
- Host
客户端发送请求时，用来指定服务器的域名。
- Connection 字段
Connection 字段最常用于客户端要求服务器使用「HTTP 长连接」机制，以便其他请求复用。
- Content-Length 字段
服务器在返回数据时，会有 Content-Length 字段，表明本次回应的数据长度。 - Content-Type 字段
Content-Type 字段用于服务器回应时，告诉客户端，本次数据是什么格式。 - Content-Encoding 字段
Content-Encoding 字段说明数据的压缩方法。表示服务器返回的数据使用了什么压缩格式
19. RPC
RPC 本质上不算是协议，而是一种调用方式，而像 gRPC 和 Thrift 这样的具体实现，才是协议，它们是实现了 RPC 调用的协议。目的是希望程序员能像调用本地方法那样去调用远端的服务方法。同时 RPC 有很多种实现方式，不一定非得基于 TCP 协议。
HTTP 主要用于 B/S 架构，而 RPC 更多用于 C/S 架构。但现在其实已经没分那么清了，B/S 和 C/S 在慢慢融合。
纯裸 TCP 是能收发数据，但它是个无边界的数据流，上层需要定义消息格式用于定义消息边界。于是就有了各种协议，HTTP 和各类 RPC 协议就是在 TCP 之上定义的应用层协议。
20. Http与Https建立连接的过程
http:发送请求-三次握手-解析
https：加密过程–http过程
添加链接描述
五、网络层(ARP,IP协议)
1. 什么是MAC地址？
MAC地址： 媒体访问控制地址（Media Access Control Address），又称物理地址，由网络设备制造商生产时写在硬件内部，不可更改，并且每个以太网设备的MAC地址都是唯一的。
IP地址：指互联网协议地址，IP地址是IP协议提供的一种统一的地址格式，它为互联网上的每一个网络和每一台主机分配一个逻辑地址，以此来屏蔽物理地址的差异。
TCP报文在网络层被封装成IP数据报，在数据链路层会被封装成MAC帧，然后在通信链路中传输
- MAC地址与IP地址区别
MAC 的作用则是实现**「直连」的两个设备之间通信，而 IP 则负责在「没有直连」**的两个网络之间进行通信传输。
2. 了解ARP协议吗
- 定义及作用
全称 地址解析协议（Address Resolution Protocol），它解决的是网络层地址和链路层地址之间的转换问题。因为一个 IP 数据报在物理上传输的过程中，总是需要知道下一跳（物理上的下一个目的地）该去往何处，但 IP 地址属于逻辑地址，而 MAC 地址才是物理地址，ARP 协议解决了 IP 地址转 MAC 地址的一些问题。 - 工作流程
3. ping的工作原理
ping，Packet Internet Groper，是一种因特网包探索器，用于测试网络连接量的程序。Ping是工作在TCP/IP网络体系结构中应用层的一个服务命令， 主要是向特定的目的主机发送ICMP（Internet Control Message Protocol 因特网报文控制协议） 请求报文，测试目的站是否可达及了解其有关状态。
一般来说，ping可以用来检测网络通不通。它是基于ICMP协议工作的。假设机器A ping机器B，工作过程如下：
- ping通知系统，新建一个固定格式的ICMP请求数据包
- ICMP协议，将该数据包和目标机器B的IP地址打包，一起转交给IP协议层
- IP层协议将本机IP地址为源地址，机器B的IP地址为目标地址，加上一些其他的控制信息，构建一个IP数据包
- 先获取目标机器B的MAC地址。
- 数据链路层构建一个数据帧，目的地址是IP层传过来的 MAC地址，源地址是本机的 MAC地址
- 机器B收到后，对比目标地址，和自己本机的MAC地址是否一致，符合就处理返回，不符合就丢弃。
- 根据目的主机返回的ICMP回送回答报文中的时间戳，从而计算出往返时间
- 最终显示结果有这几项：发送到目的主机的IP地址、发送 & 收到 & 丢失的分组数、往返时间的最小、最大& 平均值
4. 断网了，还能 ping 通 127.0.0.1 吗？
可以。
- 什么是127.0.0.1？
这是一个ipv4地址，ipv4地址有32位，一个字节8位，共4个字节。其中127 开头的都属于回环地址(人为规定的)
ipv6的诞生：
IPv4 的地址是 32 位的，2的32次方，大概是40+亿。地球光人口就76亿了，40亿IP这点量，塞牙缝都不够，实际上IP也确实用完了。
所以就有了IPV6， IPv6 的地址是 128 位的，大概是2的128次方≈10的38次方。据说地球的沙子数量大概是 10的23次方，所以IPV6的IP可以认为用不完。
多说一句：在IPV4下用的是 ping 127.0.0.1 命令。在IPV6下用的是 ping6 ::1 命令。
- 原因
有网的情况下，ping 最后是通过网卡将数据发送出去的。
从应用层到传输层再到网络层。这段路径跟ping外网的时候是几乎是一样的。到了网络层，系统会根据目的IP，在路由表中获取对应的路由信息，而这其中就包含选择哪个网卡把消息发出。当发现目标IP是外网IP时，会从"真网卡"发出。当发现目标IP是回环地址时，就会选择本地网卡
5. 路由器和交换机的区别
6. 正向代理和反向代理
- 正向代理
正向代理的主动方是用户，主要用来解决跨域问题，还有隐藏用户访问记录的作用。
客户端向代理服务器发送请求，代理服务器代表客户端向目标服务器请求资源。
客户端需要明确指定代理服务器，请求的目标服务器对客户端是不可见的。
代理服务器可以缓存请求的资源，提高访问速度。
常见的应用场景是绕过网络限制，访问被封锁的网站，保护客户端的隐私等。 - 反向代理
反向代理的主动方是服务器，主要是提供负载均衡、安全防护等作用。
反向代理：
客户端向反向代理服务器发送请求，反向代理服务器根据请求的内容和规则，将请求转发给后端的目标服务器。
客户端不需要明确指定代理服务器，请求的目标服务器对客户端是透明的。
反向代理服务器可以根据负载均衡算法将请求分发给多个后端服务器，提高系统的性能和可靠性。
常见的应用场景是负载均衡、高可用性、安全过滤、SSL加密等。