计算机网络面试准备

最新推荐文章于 2022-04-04 20:54:48 发布

冰羽天秤

最新推荐文章于 2022-04-04 20:54:48 发布

阅读量941

点赞数 1

分类专栏：计算机网络文章标签：网络面试

本文链接：https://blog.csdn.net/qq_44689862/article/details/123934169

版权

计算机网络专栏收录该内容

1 篇文章 0 订阅

订阅专栏

文章目录

1.计算机网络模型
- 1. OSI七层模型
- 2.TCP/IP模型
2.网络层
3.传输层
4.应用层
5.各层的网络设备，对应的协议
- 一、各层设备
- 二、各层协议
杂记

1.计算机网络模型

TCP/IP 与 OSI 都是为了使网络中的两台计算机能够互相连接并实现通信与回应，但他们最大的不同在于，OSI 是一个理论上的网络通信模型，而 TCP/IP 则是实际上的网络通信标准。

1. OSI七层模型

物理层：实现计算机节点之间比特流的透明传输，规定传输媒体接口的标准，屏蔽掉具体传输介质和物理设备的差异，使数据链路层不必关心网络的具体传输介质，按照物理层规定的标准传输数据就行。
数据链路层：通过差错控制、流量控制等方法，使有差错的物理线路变为无差错的数据链路。

数据链路层的几个基本方法：数据封装成桢、透明传输、差错控制、流量控制。

封装成桢：把网络层数据报加头和尾，封装成帧，帧头中包括源MAC地址和目的MAC地址。
透明传输：是指不管所传数据是什么样的比特组合，都应当能够在链路上传送。因此，链路层就“看不见”有什么妨碍数据传输的东西。常见方法：零比特填充、转义字符、字节填充。
差错控制：接收者检测错误,如果发现差错，丢弃该帧，差错控制方法有 CRC 循环冗余码、奇偶校验码、海明码。
流量控制：控制发送的传输速度，使得接收方来得及接收。传输层TCP也有流量控制功能，但TCP是端到端的流量控制，链路层是点到点（比如一个路由器到下一个路由器）
网络层：实现网络地址与物理地址的转换，并通过路由选择算法为分组通过通信子网选择最适当的路径

网络层最重要的一个功能就是：路由选择。路由一般包括路由表和路由算法两个方面。每个路由器都必须建立和维护自身的路由表，一种是静态维护，也就是人工设置，适用于小型网络；另一种就是动态维护，是在运行过程中根据网络情况自动地动态维护路由表。
传输层：提供源端与目的端之间提供可靠的透明数据传输，传输层协议为不同主机上运行的进程提供逻辑通信。负责向两台主机进程之间的通信提供通用的数据传输服务(TCP、UDP)，（网关）。
- 网络层协议负责的是提供主机间的逻辑通信；
- 传输层协议负责的是提供进程间的逻辑通信。
会话层：管理主机之间的会话进程，负责在网络中的两节点之间建立、维持、终止通信。
表示层：处理用户数据的表示问题，如数据的编码、格式转换、加密和解密、压缩和解压缩。
应用层：为用户的应用进程提供网络通信服务，完成和实现用户请求的各种服务。

2.TCP/IP模型

TCP/IP协议模型（Transmission Control Protocol/Internet Protocol），包含了一系列构成互联网基础的网络协议，是Internet的核心协议。TCP/IP协议族按照层次由上到下，层层包装。

上图表示了TCP/IP协议中每个层的作用，而TCP/IP协议通信的过程其实就对应着数据入栈与出栈的过程。入栈的过程，数据发送方每层不断地封装首部与尾部，添加一些传输的信息，确保能传输到目的地。出栈的过程，数据接收方每层不断地拆除首部与尾部，得到最终传输的数据。

2.网络层

实现网络地址与物理地址的转换，并通过路由选择算法为分组通过通信子网选择最适当的路径

1.IP地址与物理地址

物理地址是数据链路层和物理层使用的地址，IP地址是网络层和以上各层使用的地址，是一种逻辑地址，其中ARP协议将IP地址转换成物理地址。

2.ARP地址解析协议的工作原理

ARP 是根据 IP 地址获取 MAC 地址的一种协议，核心原理就是广播发送ARP请求，单播发送ARP响应

（1）每个主机都在自己的ARP缓冲区中建立一个ARP列表，以表示 IP 地址和 MAC 地址之间的对应关系。
（2）当源主机要发送数据时，先检查ARP列表中是否有该 IP 地址对应的 MAC 地址，如果有，则直接发送数据；如果没有，就向本网段的所有主机发送ARP数据包，用于查询目的主机的MAC地址，该数据包包括的内容有：源主机IP地址，源主机MAC地址，目的主机的IP。
（3）当本网络的所有主机收到该ARP数据包时，首先检查数据包中的IP地址是否是自己的IP地址，如果不是，则忽略该数据包，如果是，则首先从数据包中取出源主机的IP和MAC地址写入到ARP列表中，如果已经存在，则覆盖，然后将自己的MAC地址写入ARP响应包中，告诉源主机自己是它想要找的MAC地址。
（4）源主机收到 ARP 响应包后，将目的主机的 IP 和 MAC 地址写入ARP列表，并利用此信息发送数据。如果源主机一直没有收到ARP响应数据包，表示ARP查询失败

3.RARP逆地址解析协议：

RARP是逆地址解析协议，作用是完成硬件地址到IP地址的映射，主要用于无盘工作站，因为给无盘工作站配置的IP地址不能保存。工作流程：在网络中配置一台RARP服务器，里面保存着 MAC 地址和 IP 地址的映射关系，当无盘工作站启动后，就封装一个RARP数据包，里面有其MAC地址，然后广播到网络上去，当服务器收到请求包后，就查找对应的MAC地址的IP地址装入响应报文中发回给请求者。因为需要广播请求报文，因此RARP只能用于具有广播能力的网络。

4.DHCP协议

动态主机配置协议，对 IP地址进行集中管理和分配，提升地址的使用率，通过DHCP协议，可以使客户机自动获得服务器分配的lP地址和子网掩码。DHCP通常被用于局域网环境，主要作用是集中的管理、分配IP地址，使client动态的获得IP地址、Gateway地址、DNS服务器地址等信息，并能够提升地址的使用率。

其地址分配方式有如下三种

人工配置：由管理员对每台具体的计算机指定一个地址
自动配置：服务器为第一次连接网络的计算机分配一个永久地址，DHCP客户端第一次成功地从DHCP服务器端分配到一个IP地址之后，就永远使用这个地址
动态配置：在一定的期限内将地址租给计算机，客户端第一次从DHCP服务器分配到IP地址后，并非永久地使用该地址，每次使用完后，DHCP客户端就得释放这个IP地址，并且租期结束后客户必须续租或者停用该地址，而对于路由器，经常使用的地址分配方式是动态配置。

5.ICMP协议，因特网控制报文协议

因特网控制报文协议，用于在IP主机、路由器之间传递控制消息（控制消息是指网络通不通、主机是否可达、路由器是否可用等网络本身的消息），确认 IP 包是否成功到达目标地址。因为 IP 协议并不是一个可靠的协议，它不保证数据被送达，当传送IP数据包发生错误，比如主机不可达、路由不可达等等，ICMP协议将会把错误信息封包，然后传送回给主机，给主机一个处理错误的机会。

ICMP报文有两种：差错报告报文和询问报文。以下是4种常见的ICMP差错报告报文

6.交换机与路由器的区别

（1）工作所处的OSI层次不一样，交换机工作在OSI第二层数据链路层，路由器工作在OSI第三层网络层；
（2）寻址方式不同：交换机根据MAC地址寻址，路由器根据IP地址寻址；
（3）转发速不同：交换机的转发速度快，路由器转发速度相对较慢。

7.路由选择协议

（1）内部网关协议IGP：

① RIP(Routing Information Protocol）：是一种动态路由选择协议，基于距离矢量算法，使用“跳数”来衡量到达目标地址的路由距离，并且只与自己相邻的路由器交换信息，范围限制在15跳之内。
② OSPF：开放最短路径优先协议，使用Dijskra算法计算出到达每一网络的最短路径，并在检测到链路的情况发生变化时（如链路失效），就执行该算法快速收敛到新的无环路拓扑。

（2）外部网关协议：

BGP：边界网关协议，BGP 是力求寻找一条能够到达目的网络且较好的路由，而并非要寻找一条最佳路由。BGP采用路径向量路由选择协议。

3.传输层

传输层主要提供**不同主机上进程间逻辑通信 + 可靠传输或者不可靠传输的功能。**端到端通信

一、TCP和UDP

、

1. 传输控制协议TCP和用户数据报协议UDP的区别

（1）TCP是面向字节流的，基本传输单位是TCP报文段；UDP是面向报文的，基本传输单位是是用户数据报；

面向字节流：应用程序和TCP的交互是一次一个数据块（大小不等），但TCP把应用程序看成是一连串的无结构的字节流。TCP有一个缓冲，当应用程序传送的数据块太长，TCP就可以把它划分短一些再传送。
面向报文：面向报文的传输方式是应用层交给UDP多长的报文，UDP就照样发送。因此，应用程序必须选择合适大小的报文。

（2）TCP 注重安全可靠性，连接双方在进行通信前，需进行三次握手建立连接。UDP 是无连接的，使用最大努力交付，即不保证可靠交付。

（3）UDP 不需要连接等待，所以数据传输快，而 TCP 传输效率相对较低

（4）TCP首部开销是20个字节；UDP的首部开销是8个字节，这也是减少网络传输开销的一方面

（5）TCP有拥塞控制和流量控制，而UDP没有拥塞控制和流量控制

（6）TCP支持点对点通信，提供全双工通信，不提供广播或多播服务；UDP支持一对一、一对多、多对一、多对多的通信模式。

2.TCP和UDP的适用场景

（1）当对网络通讯质量要求不高时，并且要求网络通讯速度能尽量的快，这时就可以使用UDP。比如即使通信：语音、视频、直播等

（2）当对网络通讯质量有要求时，要求整个数据准确无误可靠的传递给对方，这时就适用使用 TCP 协议，一般用于文件传输、发送和接收邮件等场景。比如HTTP、HTTPS、FTP等传输文件的协议，POP、SMTP等邮件传输的协议都是使用 TCP 协议

① TCP对应的协议：

FTP：文件传输协议，使用21端口
Telnet：远程终端接入，使用23端口，用户可以以自己的身份远程连接到计算机上，可提供基于DOS模式下的通信服务。
SMTP：邮件传送协议，用于发送邮件，使用25端口
POP3：邮件传送协议，P用于接收邮件。使用110端口
HTTP：万维网超文本传输协议，是从Web服务器传输超文本到本地浏览器的传送协议
SSH协议：安全外壳协议，用于加密安全登录，替代安全性差的Telent协议

② UDP对应的协议：

DNS：域名解析服务，将域名地址转换为IP地址，使用53号端口；
SNMP：网络管理协议，用来管理网络设备，使用161号端口；
TFTP：简单文件传输协议，提供不复杂、开销不大的文件传输服务，使用 69 端口；
NFS：远程文件服务器
RIP：路由信息协议
DHCP：动态主机配置协议
IGMP：网际组管理协议

3.TCP的首部字段

（1）源端口和目的端口：分别占16位，指发送方应用程序的端口和目的方应用程序的端口号，通过 IP 地址 + 端口号就可以确定一个进程地址

（2）序号（Sequense Number，SN）：在一个TCP连接中传送的字节流中的每一个字节都按顺序编号，该字段表示本报文段所发送数据的第一个字节的序号。（初始序号称为 Init Sequense Number, ISN）

例如，一报文段的序号是 101，共有 100 字节的数据。这就表明：本报文段的数据的第一个字节的序号是 101，最后一个字节的序号是 200。显然，下一个报文段的数据序号应当从 201 开始，即下一个报文段的序号字段值应为 201。

（3）确认号 ack：期望收到对方下一个报文段的第一个数据字节的序号。若确认号为 N，则表明：到序号 N-1 为止的所有数据都已正确收到。

（4）头部长度：指出 TCP报文段的数据起始处距离 TCP报文段的起始处有多远。这个字段实际上是指出TCP报文段的首部长度。

（5）保留位：占6位，应置为 0，保留为今后使用。

（6）6个控制位：用于说明该报文段的性质：

① 紧急位URG：当 URG = 1 时，表明此报文段中有紧急数据，是高优先级的数据，应尽快发送，不用在缓存中排队。
② 确认ACK：仅当 ACK = 1 时确认号字段才有效，当 ACK = 0 时确认号无效。TCP 规定，在连接建立后所有传送的报文段都必须把 ACK 置为 1。
③ 推送PSH：接收方收到 PSH = 1 的报文段时，就直接发送给应用进程，而不用等到整个缓冲区都填满了后再向上传送。
④ 复位RST：当 RST = 1 时，表明 TCP 连接中出现了严重错误（如由于主机崩溃或其他原因），必须释放连接，然后再重新建立传输连接。
⑤ 同步SYN：SYN = 1 表示这是一个连接请求或连接接受报文。当 SYN = 1 而 ACK = 0 时，表明这是一个连接请求报文段。对方若同意建立连接，则应在响应的报文段中使 SYN = 1 且 ACK = 1。
⑥ 终止FIN：用来释放一个连接。当 FIN = 1时，表明此报文段的发送发的数据已发送完毕，并要求释放运输连接。

（7）窗口大小：16位，用于控制发送端的滑动窗口大小

（8）校检和：16位，校验数据段是否未被修改

（9）紧急指针：16位。

二、TCP连接的建立与断开

1、建立连接的三次握手

（1）第一次握手：客户端向服务端发送一个 SYN 报文（SYN = 1），并指明客户端初始化序列号 ISN，即seq = x，表示本报文所发送的第一个字节的序号。此时客户端处于 SYN_Sent 状态，等待服务端确认。

三次握手的一个重要功能是客户端和服务端交换 ISN，以便让对方知道接下来接收数据时如何按序列号组装数据。

ISN 是动态生成的，并非固定，因此每个连接都将具有不同的 ISN。如果 ISN 是固定的，攻击者很容易猜出后续的确认号。

（2）第二次握手：服务端收到数据包后，由 SYN = 1 知道客户端请求建立连接，那么就会对这个TCP 连接分配缓存和变量（缓存指的是一个字节流队列），接着返回一个确认报文：设置 SYN = 1，ACK = 1，同时指定自己的初始化序列号 ISN，即图中的 seq = y，并把客户端的 ISN + 1 作为确认号 ack 的值，表示已经收到了客户端发来的的 SYN 报文，希望收到的下一个数据的第一个字节的序号是 x + 1，此时服务端进入SYN_REVD状态。

（3）第三次握手：客户端收到确认后，检查ACK是否为1，ack是否为 x +1，如果正确，则给服务端发送一个 ACK 报文：设置 ACK = 1，把服务端的 ISN + 1 作为 ack 的值，表示已经收到了服务端发来的 SYN 报文，希望收到的下一个数据的第一个字节的序号是 y + 1，并指明此时客户端的序列号 seq = x + 1，此时客户端和服务器端都进入 ESTABLISHED 状态。完成三次握手，随后Client与Server之间可以开始传输数据了。

此时 SYN 控制位变为 0，表示这不是建立连接的请求了，要正式发数据了。

第三次握手可以携带发送的数据

三次握手出现错误时的应对措施
第一次握手A发送SYN传输失败，A,B都不会申请资源，连接失败。如果一段时间内发出多个SYN连接请求，那么A只会接受它最后发送的那个SYN的SYN+ACK回应，忽略其他回应全部回应，B中多申请的资源也会释放

第二次握手B发送SYN+ACK传输失败，A不会申请资源，B申请了资源，但收不到A的ACK，过一段时间释放资源。如果是收到了多个A的SYN请求，B都会回复SYN+ACK，但A只会承认其中它最早发送的那个SYN的回应，并回复最后一次握手的ACK

第三次握手ACK传输失败，B没有收到ACK，释放资源，对于后序的A的传输数据返回RST。实际上B会因为没有收到A的ACK会多次发送SYN+ACK，次数是可以设置的，如果最后还是没有收到A的ACK，则释放资源，对A的数据传输返回RST

2.为什么不能用两次握手进行建立连接

3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。

（1）**三次握手目的是确认双方的接收与发送能力是否正常，同步连接双方的初始化序列号 ISN，为后面的可靠性传输做准备。**而两次握手只有服务端对客户端的起始序列号做了确认，但客户端却没有对服务端的初始序列号做确认，不能保证传输的可靠性。

（2）三次握手可以防止已失效的连接请求报文段突然又传送到了服务端，导致服务器错误地建立连接，浪费服务端的连接资源。

客户端发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达Server。本来这是一个早已失效的报文段，但Server收到此失效的连接请求报文段后：

① 假设不采用“三次握手”，那么只要Sever发出确认，新的连接就建立了。但由于现在Client并没有发出建立连接的请求，因此不会理睬Server的确认，也不会向Server发送数据。而Server却以为新的连接已经建立，并一直等待Client发来数据，这样，Server的很多资源就白白浪费掉了

② 而采用“三次握手”协议，只要Server收不到来自Client的确认，就知道Client并没有要求建立请求，就不会建立连接了。

为什么是三次握手

这个问题的本质是, 信道不可靠, 但是通信双发需要就某个问题达成一致. 而要解决这个问题, 无论你在消息中包含什么信息, 三次通信是理论上的最小值. 所以三次握手不是TCP本身的要求, 而是为了满足"在不可靠信道上可靠地传输信息"这一需求所导致的. 请注意这里的本质需求,信道不可靠, 数据传输要可靠. 三次达到了, 那后面你想接着握手也好, 发数据也好, 跟进行可靠信息传输的需求就没关系了. 因此,如果信道是可靠的, 即无论什么时候发出消息, 对方一定能收到, 或者你不关心是否要保证对方收到你的消息, 那就能像UDP那样直接发送消息就可以了

超过三次浪费资源

3.断开连接的四次挥手

（1）第一次挥手：客户端发送一个 FIN 报文，设置 FIN = 1 并指定序列号 seq = u（u 是之前传送过来的最后一个字节的序号 + 1），主动关闭 TCP 连接，此时客户端进入FIN_WAIT_1状态；

（2）第二次挥手：服务端收到 FIN 报文后，由FIN=1 知道客户端请求关闭连接，则返回确认报文：设置ACK = 1，ack = u + 1，seq = v（v 的值取决于服务器发送给客户端之前的一个包确认号是多少）

服务端进入CLOSE_WAIT状态，此时TCP连接处于半关闭状态，即客户端不能向服务端发送报文，只能接收，但服务端仍然可以向客户端发送数据。
客户端收到服务端的确认后，进入 FIN_WAIT2 状态，等待服务端发出的连接释放报文段。

（3）第三次挥手：当服务端没有要向客户端发送的数据时，就向客户端发送一个 FIN 报文，设置 FIN = 1 并指定序列号 seq = w（w 的值取决于服务器发送给客户端之前的一个包确认号是多少），用于关闭服务端到客户端的数据传送。此时服务器处于 LAST_ACK 状态

4）第四次挥手：客户端收到 FIN 报文后，发送给服务端一个 ACK 报文作为应答：设置 ACK=1 和 ack = w +1。发送之后，客户端处于 TIME_WAIT状态，如果服务端接收到这个数据包，则进入CLOSED状态，完成四次挥手。

4.为什么需要TIME_WAIT状态（为什么还要等待2MSL）

TIME_WAIT 状态持续 2MSL（最大报文存活时间），约4分钟才转换成CLOSE状态。由于TIME_WAIT 的时间会非常长，因此服务端应尽量减少主动关闭连接，TIME_WAIT 的主要作用有：

（1）重发丢失的 ACK 报文，保证连接可靠的关闭：

由于网络等原因，无法保证最后一次挥手的 ACK 报文一定能传送给对方，如果 ACK 丢失，对方会超时重传 FIN，主动关闭端会再次响应ACK过去；如果没有 TIME_WAIT 状态，直接关闭，对方重传的FIN报文则被响应一个RST报文，此RST会被动关闭端被解析成错误。同时，服务器就因为接收不到客户端的信息而无法正常关闭。

（2）保证本次连接的重复数据段从网络中消失：

如果存在两个连接，第一个连接正常关闭，第二个相同的连接紧接着建立；如果第一个连接的某些数据仍然滞留在网络中，这些延迟数据在建立新连接之后才到达，则会干扰第二连接，等待 2MSL 可以让上次连接的报文数据消逝在网络中。

5.为什么需要四次挥手

TCP 是全双工模式，并且支持半关闭特性，提供了连接的一端在结束发送后还能接收来自另一端数据的能力。任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了 TCP 连接。

通俗的来说，两次握手就可以释放一端到另一端的 TCP 连接，完全释放连接一共需要四次握手。

6.如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

7.什么是SYN洪泛

SYN 洪泛是指利用 TCP 需要三次握手的特性，攻击者伪造 SYN 报文向服务器发起连接，服务器在收到报文后用 ACK 应答，但之后攻击者不再对该响应进行应答，造成一个半连接。假设攻击者发送大量这样的报文，那么被攻击主机就会造成大量的半连接，耗尽其资源，导致正常的 SYN 请求因为队列满而被丢弃，使得正常用户无法访问。

半连接队列：服务器第一次收到客户端的 SYN 之后，就会处于 SYN_RCVD 状态，此时双方还没有完全建立其连接，服务器会把这种状态下的请求连接放在一个队列里，我们把这种队列称之为半连接队列。当然还有一个全连接队列，完成三次握手后建立起的连接就会放在全连接队列中。

这里在补充一点关于SYN-ACK 重传次数的问题：　服务器发送完SYN－ACK包，如果未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户确认包，进行第二次重传，如果重传次数超过系统规定的最大重传次数，系统将该连接信息从半连接队列中删除。注意，每次重传等待的时间不一定相同，一般会是指数增长，例如间隔时间为 1s, 2s, 4s, 8s, …

**SYN攻击:**SYN攻击即是利用TCP协议的缺陷，通过发送大量的半连接请求，占用半连接队列，耗费CPU和内存资源。优化方式：（1）缩短SYN Timeout时间；（2）记录IP，若连续受到某个IP的重复SYN报文，从这个IP地址来的包会被一概丢弃。

8.三次握手过程中对否可以携带数据

第三次握手时是可以携带数据的，但第一二次握手时不可以携带数据。

（1）假如第一次握手可以携带数据的话，那么会放大 SYN 洪泛。如果有人要恶意攻击服务器，每次都在第一次握手中的 SYN 报文中放入大量的数据，然后疯狂重复发送 SYN 报文的话，就会让服务器开辟大量的缓存来接收这些报文，内存会很容易耗尽，从而拒绝服务。

（2）第三次握手时客户端已经处于 ESTABLISHED 状态，对于客户端来说，他已经建立起连接了，并且已经知道服务器的接收和发送能力是正常的，所以也就可以携带数据了。

TCP规定：SYN报文段（SYN=1）不能携带数据，但需要消耗一个序列号。ACK报文段可以携带数据，但是如果不携带数据则不消耗序列号。

9.TCP的粘包和拆包

9.1什么是粘包拆包

拆包粘包在数据链路层、网络层以及传输层都可能存在。而在传输层中，由于UDP有消息保护边界，不会发生粘包拆包问题，因此粘包拆包问题只发生在TCP协议中。TCP是个“流”协议，所谓流，就是没有界限的一串数据。TCP底层并不了解上层业务数据的具体含义，它会根据TCP缓冲区的实际情况进行包的划分，所以在业务上认为，一个完整的包可能会被TCP拆分成多个包进行发送，也有可能把多个小的包封装成一个大的数据包发送，这就是所谓的TCP粘包和拆包问题。

9.2什么情况会发生拆包粘包

（1）应用程序 write 写入的数据字节大于套接口发送缓冲区大小，将会发生拆包现象；

（2）应用程序 write 写入的数据字节小于套接字缓冲区大小，网卡将应用多次写入的数据发送到网络上，这将会发生粘包。

（3）进行MSS大小的TCP分段：程序需要发送的数据大小和TCP报文段能发送MSS（Maximum Segment Size，最大报文长度）是不一样的。大于MSS时，就需要把程序数据拆分为多个TCP报文段，称之为拆包；小于时，则要考虑合并多个程序数据为一个TCP报文段，则是粘包；其中 MSS = TCP报文段长度-TCP首部长度。

（4）接收方法不及时读取套接字缓冲区数据，这将发生粘包。

9.3拆包粘包问题的解决策略

（1）在数据尾部增加一个特殊字符进行分割，例如 FTP 协议；

（2）将数据大小设置为固定的，如果数据长度不够，则使用空位补全；

（3）将数据分为两部分，消息头和消息体；其中消息头大小固定，且包含一个字段声明内容体的大小

9.4网络层-IP数据报分片

**MTU 是数据链路层**中的网络对数据帧的一个限制（以太网中 MTU 为1500个字节），一个 IP 数据报在以太网中传输，如果它的长度大于 MTU 值，就要进行分片传输，使得每片数据报的长度小于 MTU。而分片传输的 IP 数据报不一定按序到达，但 IP 首部中的信息能让这些数据报片按序组装，IP数据报的分片与重组是在网络层进完成的。

前面提到，**MSS 是 TCP 数据包每次能够传输的最大数据分段**，TCP 报文段的长度大于 MSS 时，要进行分段传输。TCP 在建立连接时通常会协商双方的 MSS 值（**MSS 选项只出现在 SYN 报文段中，即 TCP 三次握手的前两次**）。**MSS 的值一般为 MTU 值减去两个首部大小（IP 数据包包头的大小 20 Bytes 和 TCP 数据段的包头 20 Bytes）**，**TCP报文段的分段与重组是在传输层完成的。**

如果用链路层以太网，MSS的值往往为1460。而 Internet 上标准的 MTU（最小的 MTU，链路层网络为x2.5时）为576，那么如果不设置，则MSS的默认值就为536个字节。很多时候，MSS的值最好取512的倍数。

到这里我们就能看出，TCP 分段的原因是 MSS，IP 分片的原因是 MTU，由于一直有 MSS <= MTU，分段后的每一段TCP报文段再加上IP首部后的长度不可能超过MTU，因此也就不需要在网络层进行IP分片了，因此TCP报文段很少会发生IP分片的情况。

而由于 UDP 数据报不会自己进行分段，因此当长度超过了 MTU 时，会在网络层进行 IP 分片。同样，ICMP（在网络层中）同样会出现IP分片情况。

所以，总的来说，UDP 不会分段，就由 IP 来分，TCP会分段，当然就不用 IP 来分了！

10.TCP的长连接和短连接

10.1. TCP短连接
模拟一下TCP短连接的情况：client向server发起连接请求，server接到请求，然后双方建立连接。client向server发送消息，server回应client，然后一次请求就完成了。这时候双方任意都可以发起close操作，不过一般都是client先发起close操作。上述可知，短连接一般只会在 client/server间传递一次请求操作。
短连接的优点是：管理起来比较简单，存在的连接都是有用的连接，不需要额外的控制手段。
10.2. TCP长连接
我们再模拟一下长连接的情况：client向server发起连接，server接受client连接，双方建立连接，client与server完成一次请求后，它们之间的连接并不会主动关闭，后续的读写操作会继续使用这个连接。

10.3. 长连接和短连接的优点和缺点
由上可以看出，长连接可以省去较多的TCP建立和关闭的操作，减少浪费，节约时间。对于频繁请求资源的客户来说，较适用长连接。不过这里存在一个问题，存活功能的探测周期太长，还有就是它只是探测TCP连接的存活，属于比较斯文的做法，遇到恶意的连接时，保活功能就不够使了。在长连接的应用场景下，client端一般不会主动关闭它们之间的连接，Client与server之间的连接如果一直不关闭的话，会存在一个问题，随着客户端连接越来越多，server早晚有扛不住的时候，这时候server端需要采取一些策略，如关闭一些长时间没有读写事件发生的连接，这样可以避免一些恶意连接导致server端服务受损；如果条件再允许就可以以客户端机器为颗粒度，限制每个客户端的最大长连接数，这样可以完全避免某个蛋疼的客户端连累后端服务。
短连接对于服务器来说管理较为简单，存在的连接都是有用的连接，不需要额外的控制手段。但如果客户请求频繁，将在TCP的建立和关闭操作上浪费时间和带宽。
长连接和短连接的产生在于client和server采取的关闭策略，具体的应用场景采用具体的策略，没有十全十美的选择，只有合适的选择。

10.4. 长连接短连接操作过程
短连接的操作步骤是：
建立连接——数据传输——关闭连接...建立连接——数据传输——关闭连接
长连接的操作步骤是：
建立连接——数据传输...（保持连接）...数据传输——关闭连接
10.5. 什么时候用长连接，短连接？
长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况。每个TCP连接都需要三步握手，这需要时间，如果每个操作都是先连接，再操作的话那么处理速度会降低很多，所以每个操作完后都不断开，次处理时直接发送数据包就OK了，不用建立TCP连接。例如：数据库的连接用长连接，如果用短连接频繁的通信会造成socket错误，而且频繁的socket 创建也是对资源的浪费。
而像WEB网站的http服务一般都用短链接，因为长连接对于服务端来说会耗费一定的资源，而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源，如果用长连接，而且同时有成千上万的用户，如果每个用户都占用一个连接的话，那可想而知吧。所以并发量大，但每个用户无需频繁操作情况下需用短连好。

11. seq初始序列号是固定的吗

三次握手的一个重要功能是客户端和服务端交换初始序列号，以便让对方知道接下来接受数据的时候如何按序列号组装数据。

如果初始序列号是固定的，攻击者很容易猜出后续的确认号，所以初始序列号是动态生成的。

12.为什么建立连接是三次握手，关闭连接却是四次挥手

建立连接的时候，服务端在 LISTEN 状态，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。

而关闭连接是，服务端收到客户端的FIN报文时，仅仅表示客户端不再发送数据了但是还能接收数据，并且自己也未必将全部数据都发送给对方了，所以自己可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，自己的ACK和FIN一般会分开发送，从而导致多了一次。

三、TCP可靠性传输

1.TCP如何保证可靠性传输

（1）三次握手
（2）应答机制与超时重传：TCP接收端收到发送端的数据时，它将发送一个确认。当TCP发送端发出一个报文段后，它会启动一个定时器，等待接收端的确认报文段，如果不能及时收到一个确认，将重发这个报文段。
（3）数据包校验与丢弃重复数据：TCP会检测数据在传输过程中的任何变化，若校验出包有错，则丢弃报文段并且不给出响应，这时TCP会超时重发数据；对于重复数据，则进行丢弃；
（4）对失序数据包进行重排序：既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。TCP将对失序数据进行重新排序，然后才交给应用层；
（5）流量控制：TCP 连接的每一方都有固定大小的缓冲空间。TCP 的接收端只允许另一端发送接收端缓冲区所能接纳的数据，防止较快主机致使较慢主机的缓冲区溢出。TCP使用的流量控制协议是可变大小的滑动窗口协议。
（6）拥塞控制：网络拥塞时，减少数据的发送。

2.TCP的流量控制

所谓流量控制就是让发送方的发送速率不要太快，让接收方来得及接收。因为如果发送方把数据发送得过快，接收方可能会来不及接收，这就会造成数据的丢失。TCP的流量控制是通过大小可变的滑动窗口来实现的。接收端将自己可以接收的缓冲区大小放入TCP首部中的“窗口大小”字段，通过ACK报文来通知发送端，滑动窗口是接收端用来控制发送端发送数据的大小，从而达到流量控制

其实发送方的窗口上限，是取值拥塞窗口和滑动窗口两者的最小值。当滑动窗口为 0 时，发送方一般不能再发送数据包，但有两种情况除外，一种情况是可以发送紧急数据，例如，允许用户终止在远端机上的运行进程。另一种情况是发送方可以发送一个 1 字节的数据报来通知接收方重新声明它希望接收的下一字节及发送方的滑动窗口大小。

设A向B发送数据。在连接建立时，B告诉了A：“我的接收窗口是 rwnd = 400 ”(这里的 rwnd 表示 receiver window) 。因此，发送方的发送窗口不能超过接收方给出的接收窗口的数值。假设每一个报文段为100字节长，而数据报文段序号的初始值设为1。

从图中可以看出，B进行了三次流量控制。第一次把窗口减少到 rwnd = 300 ，第二次又减到了 rwnd = 100 ，最后减到 rwnd = 0 ，即不允许发送方再发送数据了。这种使发送方暂停发送的状态将持续到主机B重新发出一个新的窗口值为止。B向A发送的三个报文段都设置了 ACK = 1 ，只有在 ACK=1 时确认号字段才有意义。

3.TCP的拥塞控制

拥塞控制就是防止过多的数据注入网络中，使网络中的路由器或链路不致过载。发送方维持一个拥塞窗口cwnd 的状态变量。拥塞窗口的大小动态变化，取决于网络的拥塞程度，发送方让自己的发送窗口等于拥塞窗口。只要网络没有出现拥塞，拥塞窗口就再增大一些，以便把更多的分组发送出去。但只要网络出现拥塞，拥塞窗口就减小一些，以减少注入到网络中的分组数。拥塞控制的方法主要有以下几种：慢启动、拥塞避免、快重传和快恢复。

（1）慢开始算法：当发送主机开始发送数据时，不要一开始就发送大量的数据，因为不清楚网络的拥塞情况，而是试探一下网络的拥塞情况，由小到大逐渐增大发送窗口。在开始发送报文段时先设置cwnd=1，使得发送方在开始时只发送一个报文段，然后每经过一个传输轮次RTT，拥塞窗口 cwnd 就加倍。另外，为了防止拥塞窗口cwnd增长过大引起网络拥塞，还需要设置一个慢开始门限 ssthresh 状态变量。

当 cwnd < ssthresh 时，使用上述的慢开始算法。

当 cwnd = ssthresh 时，既可使用慢开始算法，也可使用拥塞控制避免算法。

当 cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法。

（2）拥塞避免算法：让拥塞窗口cwnd缓慢地增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1。这样拥塞窗口cwnd按线性规律缓慢增长，比慢开始算法的拥塞窗口增长速率缓慢得多。

无论在慢开始阶段还是在拥塞避免阶段，只要网络出现拥塞（其根据就是没有收到确认），就要把慢开始门限ssthresh设置为出现拥塞时的拥塞窗口值的一半（但不能小于2）。然后把拥塞窗口cwnd 设置为1，执行慢开始算法。这样做的目的就是要迅速减少主机发送到网络中的数据量，使得发生拥塞的路由器有足够时间把队列中积压的数据处理完毕。过程图如下：

**（3）快重传：**快重传要求接收方在收到一个失序的报文段后就立即发出重复确认（使发送方及早知道有报文段没有到达对方）而不必等到自己发送数据时捎带确认。发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。

接收方收到了M1和M2后都分别发出了确认。现在假定接收方没有收到M3但接着收到了M4。显然，接收方不能确认M4，因为M4是收到的失序报文段。根据可靠传输原理，接收方可以什么都不做，也可以在适当时机发送一次对M2的确认。但按照快重传算法的规定，接收方应及时发送对M2的重复确认，这样做可以让发送方及早知道报文段M3没有到达接收方。发送方接着发送了M5和M6。接收方收到这两个报文后，也还要再次发出对M2的重复确认。这样，发送方共收到了接收方的四个对M2的确认，其中后三个都是重复确认。

（4）快恢复：与快重传配合使用的还有快恢复算法，当发送方连续收到三个重复确认时，就执行“乘法减少”算法，把ssthresh门限设置为拥塞窗口cwnd的一半，但是接下去并不执行慢开始算法，而是将cwnd设置为ssthresh的大小，然后执行拥塞避免算法：因为如果网络出现拥塞的话，就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞，所以此时并不执行慢开始算法，而是执行拥塞避免算法。

4.拥塞控制和流量控制的差别

（1）相同点：拥塞控制和流量控制的相同点都是控制丢包现象，实现机制都是让发送方发得慢一点。

（2）不同点：

① 拥塞控制是一个全局性的过程，防止过多的数据注入到网络中，造成网络拥塞

② 流量控制指点对点通信量的控制，要做的就是控制发送端发送数据的速率，以便使接收端来得及接受。

四、UDP如何保证可靠传输

UDP是传输层应用，本身是不可靠的，只能在应用层下功夫，模仿TCP的可靠传输，应答确认（Seq/Ack应答机制），超时重传（定时器），有序传输（将数据包进行编号，按照包的顺序接收并存储）,并且还要实现拥塞控制和可靠传输。
开源程序利用udp实现了可靠的数据传输，分别为RUDP、RTP、UDT。

五、停止等待协议、连续ARQ协议、滑动窗口协议、流量控制（慢开始、拥塞避免、快重传、快恢复）

4.应用层

应用层主要提供应用进程间的网络通信服务，完成用户请求的各种服务。

一、http协议

HTTP协议定义Web客户端如何从Web服务器请求Web页面，以及服务器如何把Web页面传送给客户端。HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求报文，请求报文包含请求的方法、URL、协议版本、请求头部和请求数据。服务器以一个状态行作为响应，响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据。超文本传输协议HTTP协议被用于在Web浏览器和网站服务器之间传递信息。

http协议即超文本传输协议，基于TCP协议，用于从Web服务器传输超文本到本地浏览器的传送协议。http协议是无状态协议，自身不对请求和响应直接的通信状态进行保存，但有些场景下我们需要保存用户的登陆信息，所以引入了cookie 和 session 来管理状态。

1.cookie和session的区别

HTTP协议本身是无状态的，为了使其处理更加复杂的逻辑，在HTTP1.1中引入了Cookie来保存状态信息。Cookie是由服务器端产生的，再发送给客户端保存，当客服端再次访问的时候，服务器根据cookie辨识客户端是那个，以此可以做个性化推送，免账号密码登录等。

Session用于标记特定客户端信息，存在服务器的一个文件里。一般客户端带Cookie对服务器进行访问，可以通过cookie中的session id 从整个session中查询服务器记录的关于客户端的信息

1）保存位置与安全性：cookie保存在客户端，session保存在服务端，所以在安全性上面，cookie存在安全隐患，可以通过拦截或本地文件找到cookie后进行攻击，而session相对更加安全。因此，可以将登陆信息等重要信息存放为session中；其他信息如果需要保留，可以放在cookie中。

（2）存储容量：单个cookie最大只允许4KB，一个站点最多保存20个Cookie；session没有大小限制，个数只跟服务器的内存大小有关。

（3）有效期与实现机制：cookie可长期有效存在；session依赖于cookie，过期时间默认为-1，只需关闭窗口该 session 就会失效。每个客户端对应一个session ，客户端之间的 session 相互独立；

cookie：cookie是一小段的文本信息，当客户端请求服务器时，如果服务器需要记录该用户状态，就在响应头中向客户端浏览器颁发一个Cookie，而客户端浏览器会把cookie保存起来。当再次请求该网站时，浏览器把请求的网站连同该cookie一起提交给服务器，服务器会检查该cookie，以此来辨认用户状态。
session：当客户端请求服务器时，都会带上cookie，cookie里面一般都会有一个JSESSIONID，服务器就按照 JSESSIONID 来找到对应的 session；如果客户端请求不包含 JSESSIONID，则为此客户端创建session并生成相关联的JSESSIONID，并将这个JSESSIONID在本次响应中返回给客户端保存。客户端保存这个 JSESSIONID 的方式可以使用cookie机制。若浏览器禁用Cookie的话，可以通过 URL重写机制将JSESSIONID传回服务器。

由于HTTP协议是无状态的协议，所以服务端需要记录用户的状态时，就需要用某种机制来识具体的用户，这个机制就是Session.典型的场景比如购物车，当你点击下单按钮时，由于HTTP协议无状态，所以并不知道是哪个用户操作的，所以服务端要为特定的用户创建了特定的Session，用用于标识这个用户，并且跟踪用户，这样才知道购物车里面有几本书。这个Session是保存在服务端的，有一个唯一标识。在服务端保存Session的方法很多，内存、数据库、文件都有。集群的时候也要考虑Session的转移，在大型的网站，一般会有专门的Session服务器集群，用来保存用户会话，这个时候 Session 信息都是放在内存的，使用一些缓存服务比如Memcached之类的来放 Session。
思考一下服务端如何识别特定的客户？这个时候Cookie就登场了。每次HTTP请求的时候，客户端都会发送相应的Cookie信息到服务端。实际上大多数的应用都是用 Cookie 来实现Session跟踪的，第一次创建Session的时候，服务端会在HTTP协议中告诉客户端，需要在 Cookie 里面记录一个Session ID，以后每次请求把这个会话ID发送到服务器，我就知道你是谁了。有人问，如果客户端的浏览器禁用了 Cookie 怎么办？一般这种情况下，会使用一种叫做URL重写的技术来进行会话跟踪，即每次HTTP交互，URL后面都会被附加上一个诸如 sid=xxxxx 这样的参数，服务端据此来识别用户。
Cookie其实还可以用在一些方便用户的场景下，设想你某次登陆过一个网站，下次登录的时候不想再次输入账号了，怎么办？这个信息可以写到Cookie里面，访问网站的时候，网站页面的脚本可以读取这个信息，就自动帮你把用户名给填了，能够方便一下用户。这也是Cookie名称的由来，给用户的一点甜头。所以，总结一下：Session是在服务端保存的一个数据结构，用来跟踪用户的状态，这个数据可以保存在集群、数据库、文件中；Cookie是客户端保存用户信息的一种机制，用来记录用户的一些信息，也是实现Session的一种方式。

总体来说Cookie和Session的区别：
cookie数据存放在客户的浏览器上，session数据放在服务器上；
cookie不是很安全，别人可以分析存放在本地的cookie并进行cookie欺骗，考虑到安全应当使用session；
session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能。考虑到减轻服务器性能方面，应当使用cookie；
单个cookie在客户端的限制是3K，就是说一个站点在客户端存放的COOKIE不能超过3K；

2.一个完整的http请求是怎么样？即从输入网址到获得页面的过程

（1）解析url，获取 url 中包含的域名；

（2）通过DNS系统查询域名对应的IP；

DNS服务器大致分为三种类型：根DNS服务器、顶级域DNS服务器和权威DNS服务器，其中：顶级域DNS服务器主要负责诸如com、org、net、edu、gov 等顶级域名。

根DNS服务器存储了所有顶级域DNS服务器的 IP 地址，可以通过根服务器找到顶级域服务器（例如：www.baidu.com，根服务器会返回所有维护 com 这个顶级域服务器的 IP 地址）。然后你任选其中一个顶级域服务器发送请求，该顶级域服务器拿到域名后能够给出负责当前域的权威服务器地址（以 baidu为例的话，顶级域服务器将返回所有负责 baidu 这个域的权威服务器地址）。接着任选其中一个权威服务器地址查询「www.baidu.com」的具体 IP 地址，最终权威服务器会返回给你具体的 IP 地址。此外，本地 DNS 服务器是具有缓存功能的，通常两天内的记录都会被缓存。

所以，通过DNS系统查询域名对应的 IP 的具体步骤可以总结为：

① 操作系统先查本地 hosts文件中是否有记录，如果有，则直接返回相对应映射的IP地址。
② 如果本地hosts文件中没有配置，则主机向自己的本地 DNS 服务器发送查询报文，如果本地DNS服务器缓存中有，将直接返回结果
③ 如果本地服务器缓存中没有，则从内置在内部的根服务器列表（全球13台，固定的IP地址）中选一个发送查询报文
④ 根服务器解析域名中的后缀名，告诉本地服务器负责该后缀名的所有顶级服务器列表
⑤ 本地服务器选择其中一个顶级域服务器发送查询请求，顶级域服务器拿到域名后继续解析，返回对应域的所有权威服务器列表
⑥ 本地服务器再向返回的权威服务器发送查询报文，最终会从某一个权威服务器上得到具体的 IP 地址
⑦ 主机返回结果IP

（3）浏览器得到域名对应的IP地址之后，向服务器发起三次握手请求建立TCP链接；

（4）TCP链接链接建立起来后，浏览器向服务器发送http请求，如果 html文件在缓存里，浏览器则直接返回，如果没有，则去后台拿；

① 浏览器首次加载资源成功时，服务器返回200，此时浏览器不仅将资源下载下来，而且把response的header(里面的date属性非常重要，用来计算第二次相同资源时当前时间和date的时间差)一并缓存;

② 下一次加载资源时，首先要经过强缓存的处理，cache-control的优先级最高，比如cache-control：no-cache,就直接进入到协商缓存的步骤了，如果cache-control：max-age=xxx,就会先比较当前时间和上一次返回200时的时间差，如果没有超过max-age，命中强缓存，不发请求直接从本地缓存读取该文件（这里需要注意，如果没有cache-control，会取expires的值，来对比是否过期），过期的话会进入下一个阶段，协商缓存

③ 协商缓存阶段，则向服务器发送header带有If-None-Match和If-Modified-Since的请求，服务器会比较Etag，如果相同，命中协商缓存，返回304；如果不一致则有改动，直接返回新的资源文件带上新的Etag值并返回200;

④ 协商缓存第二个重要的字段是，If-Modified-Since，如果客户端发送的If-Modified-Since的值跟服务器端获取的文件最近改动的时间,一致则命中协商缓存，返回304；不一致则返回新的last-modified和文件并返回200;

（5）服务器接收到请求后，根据路径参数映射到特定的处理器进行处理，并将处理结果以及相应的视图返回给浏览器。

（6）浏览器解析视图，并根据请求到的资源、数据进行渲染页面，最终向用户呈现一个完整的页面。

构建DOM树(DOM tree)：从上到下解析HTML文档生成DOM节点树（DOM tree），也叫内容树（content tree）；
构建CSSOM(CSS Object Model)树：加载解析样式生成CSSOM树；\
执行JavaScript：加载并执行JavaScript代码（包括内联代码或外联JavaScript文件）；
构建渲染树(render tree)：根据DOM树和CSSOM树,生成渲染树(render tree)；
渲染树：按顺序展示在屏幕上的一系列矩形，这些矩形带有字体，颜色和尺寸等视觉属性。
布局（layout）：根据渲染树将节点树的每一个节点布局在屏幕上的正确位置；
绘制（painting）：遍历渲染树绘制所有节点，为每一个节点适用对应的样式，这一过程是通过UI后端模块完成；

3.http的长连接和短连接

http的长连接和短连接本质上是TCP长连接和短连接。从http1.1开始就默认使用长连接。

短链接是指客户端与服务端每进行一次请求操作，就建立一次TCP连接，收到服务器响应后，就断开连接。

长连接是指客户端和服务建立TCP连接后，它们之间的连接会持续存在，不会因为一次HTTP请求后关闭，后续的请求也是用这个连接进行通信，使用长连接的HTTP协议，会在响应头有加入：Connection:keep-alive。长连接可以省去每次TCP建立和关闭的握手和挥手操作，节约时间提高效率。但在长连接下，客户端一般不会主动关闭连接，如果客户端和服务端之间的连接一直不关闭的话，随着连接数越来越多，会对服务端造成压力。

所以长连接多用于频繁请求资源，而且连接数不能太多的情况，例如数据库的连接用长连接。而像Web网站这种并发量大，但是每个用户无需频繁操作的场景，一般都使用短连接，因为长连接对服务端来说会耗费一定的资源。

4.http的断点续传是如何实现的？

HTTP请求头有个Range字段；我们下载文件的时候如果遇到网络中断，如果重头开始下载会浪费时间，所以我们可以从上一次中断处继续开始下载；具体的操作：

Range: bytes=5001-10000

或者指定5001以后的所有数据

Range: bytes=5001-

5.http存在的问题

通信使用明文不加密，通信内容可能被窃听；
无法验证报文的完整性，数据内容可能被篡改
不验证通信方身份、可能遭到伪装，无法保证数据发送到正确的机器上；

为了解决上述几个问题，那么就引入了https协议。

6.URL

HTTP使用统一资源标识符（Uniform Resource Identifiers, URI）来传输数据和建立连接。URL是一种特殊类型的URI，包含了用于查找某个资源的足够的信息URL。以下面这个URL为例，介绍下普通URL的各部分组成：
http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name
从上面的URL可以看出，一个完整的URL包括以下几部分：

1.协议部分：该URL的协议部分为“http：”，这代表网页使用的是HTTP协议。在Internet中可以使用多种协议，如HTTP，FTP等等本例中使用的是HTTP协议。在”HTTP”后面的“//”为分隔符

2.域名部分：该URL的域名部分为“www.aspxfans.com”。一个URL中，也可以使用IP地址作为域名使用

3.端口部分：跟在域名后面的是端口，域名和端口之间使用“:”作为分隔符。端口不是一个URL必须的部分，如果省略端口部分，将采用默认端口

4.虚拟目录部分：从域名后的第一个“/”开始到最后一个“/”为止，是虚拟目录部分。虚拟目录也不是一个URL必须的部分。本例中的虚拟目录是“/news/”

5.文件名部分：从域名后的最后一个“/”开始到“？”为止，是文件名部分，如果没有“?”,则是从域名后的最后一个“/”开始到“#”为止，是文件部分，如果没有“？”和“#”，那么从域名后的最后一个“/”开始到结束，都是文件名部分。本例中的文件名是“index.asp”。文件名部分也不是一个URL必须的部分，如果省略该部分，则使用默认的文件名

6.锚部分：从“#”开始到最后，都是锚部分。本例中的锚部分是“name”。锚部分也不是一个URL必须的部分

7.参数部分：从“？”开始到“#”为止之间的部分为参数部分，又称搜索部分、查询部分。本例中的参数部分为“boardID=5&ID=24618&page=1”。参数可以允许有多个参数，参数与参数之间用“&”作为分隔符。

7.URI和URL的区别是什么

URI(Uniform Resource Identifier) 是统⼀资源标志符，可以唯⼀标识⼀个资源。

Web上可用的每种资源如HTML文档、图像、视频片段、程序等都是一个来URI来定位的
URI一般由三部组成：
①访问资源的命名机制
②存放资源的主机名
③资源自身的名称，由路径表示，着重强调于资源。
URL(Uniform Resource Location) 是统⼀资源定位符，可以提供该资源的路径。它是⼀种具体的 URI，即 URL 可以⽤来标识⼀个资源，⽽且还指明了如何 locate 这个资源。

采用URL可以用一种统一的格式来描述各种信息资源，包括文件、服务器的地址和目录等。URL一般由三部组成：
①协议(或称为服务方式)
②存有该资源的主机IP地址(有时也包括端口号)
③主机资源的具体地址。如目录和文件名等
URI的作⽤像身份证号⼀样，URL的作⽤更像家庭住址⼀样。URL是⼀种具体的URI，它不仅唯⼀标识资源，⽽且还提供了定位该资源的信息。

8.http1.0、http1.1、http2.0主要特点

http1.0的主要特点:
简单快速：当客户端向服务器端发送请求时，只是简单的填写请求路径和请求方法即可，然后就可以通过浏览器或其他方式将该请求发送就行了。

灵活：HTTP协议允许客户端和服务器端传输任意类型任意格式的数据对象

**无连接：**无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接，采用这种方式可以节省传输时间。(当今多数服务器支持Keep-Alive功能，使用服务器支持长连接，解决无连接的问题)

**无状态：**无状态是指协议对于事务处理没有记忆能力，服务器不知道客户端是什么状态。即客户端发送HTTP请求后，服务器根据请求，会给我们发送数据，发送完后，不会记录信息。(使用 cookie 机制可以保持 session，解决无状态的问题)

http1.1的特点
a、默认持久连接节省通信量，只要客户端服务端任意一端没有明确提出断开TCP连接，就一直保持连接，可以发送多次HTTP请求。
b、管线化，客户端可以同时发出多个HTTP请求，而不用一个个等待响应。
c、断点续传，就是可以将一个大数据，分段传输，客户端可以慢慢显示。

http2.0的特点
a、HTTP/2采用二进制格式而非文本格式
b、HTTP/2是完全多路复用的，而非有序并阻塞的——只需一个HTTP连接就可以实现多个请求响应
c、使用报头压缩，HTTP/2降低了开销
d、HTTP/2让服务器可以将响应主动“推送”到客户端缓存中

9.http2.0的多路复用和http1.x中的长连接复用有什么区别

HTTP/1.* 一次请求-响应，建立一个连接，用完关闭；每一个请求都要建立一个连接
HTTP/1.1 Pipeling解决方式为，若干个请求排队串行化单线程处理，后面的请求等待前面请求的返回才能获得执行机会，因为传输格式是文本的，一旦有某请求超时等，后续请求只能被阻塞，毫无办法，也就是人们常说的线头阻塞
HTTP/2多个请求可同时在一个连接上并行执行（由于支持二进制的格式，可以无序）某个请求任务耗时严重，不会影响到其它连接的正常执行

HTTP/1.1 最大的变化就是引入了持久连接（persistent connection），在HTTP/1.1中默认开启 Connection: keep-alive，即TCP连接默认不关闭，可以被多个请求复用。那么管道机制就是在同一个TCP连接中可以同时发送多个HTTP请求而不用等待上一个请求返回数据后，再发送下一个请求。虽然可以同时发送多个HTTP请求，但是服务器响应是按照请求的顺序进行响应的。

HTTP 2.0的多路复用是在同一个TCP连接中，可以发送多个HTTP请求，而且请求的响应不依赖于前一个请求。每个请求单独处理，不会出现HTTP1.1中上一个请求没有回应便一直等待的情况。

图中第一种请求方式，就是单次发送request请求，收到response后再进行下一次请求，显示是很低效的。
于是http1.1提出了管线化(pipelining)技术，就是如图中第二中请求方式，一次性发送多个request请求。
然而pipelining在接收response返回时，也必须依顺序接收，如果前一个请求遇到了阻塞，后面的请求即使已经处理完毕了，仍然需要等待阻塞的请求处理完毕。这种情况就如图中第三种，第一个请求阻塞后，后面的请求都需要等待，这也就是队头阻塞(Head of line blocking)。
为了解决上述阻塞问题，http2中提出了多路复用(Multiplexing)技术，Multiplexing是通信和计算机网络领域的专业名词。http2中将多个请求复用同一个tcp链接中，将一个TCP连接分为若干个流（Stream），每个流中可以传输若干消息（Message），每个消息由若干最小的二进制帧（Frame）组成。也就是将每个request-response拆分为了细小的二进制帧Frame，这样即使一个请求被阻塞了，也不会影响其他请求，如图中第四种情况所示。

二、https协议

https 是基于tcp协议，在http的基础上加入了SSL/TLS，可看成是添加了加密和认证机制的http，使用对称加密、非对称加密、证书等技术进行进行客户端与服务端的数据加密传输，最终达到保证整个通信的安全性。简单来说，HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全。

HTTPS协议的主要作用可以分为两种：一种是建立一个信息安全通道，来保证数据传输的安全；另一种就是确认网站的真实性。

对称加密指加密和解密都使用同一个密钥的方式，这种方式存在如何安全地将密钥发送对方的问题；非对称加密使用两个密钥，公钥加密则需要私钥解密，私钥加密则需要公钥解密。不能私钥加密，私钥解密。非对称加密不需要发送用来解密的私钥，所以可以保证安全性，但是和对称加密比起来，速度非常的慢，所以我们还是要用对称加密来传送消息，但对称加密所使用的密钥我们可以通过非对称加密的方式发送出去。

1、https的认证加密过程？如何保证内容不会被篡改的？

（1）https是基于tcp协议的，首先客户端会和服务端发起链接建立
（2）服务端返回它的证书给客户端，证书中包含了服务端公钥S.pub、颁发机构和有效期等信息
（3）客户端通过浏览器内置的根证书（内部包含CA机构的公钥C.pub）验证证书的合法性
（4）客户端生成随机的对称加密密钥Z，然后通过服务端的公钥S.pub加密发送给服务端
（5）客户端和服务端之后就通过对称加密密钥Z加密数据来进行http通信

2、根证书如何保证签发的证书是安全有效的？

（1）服务器会预先生成非对称加密密钥，私钥S.pri自己保留，而公钥S.pub则发送给CA进行签名认证
（2）CA机构也会预先生成非对称加密密钥，其私钥C.pri用来对服务器的公钥S.pub进行签名，生成CA证书
（3）CA机构将签名生成的CA证书返回给服务器，也就是前面服务端给客户端那个证书
（4）因为CA机构比较权威，所以很多浏览器会内置包含它公钥C.pub的证书，称之为根证书，然后可以使用根证书来验证其颁发证书的合法性了

在整个过程中，一共涉及2对公私密钥对，一对由服务器产生，主要用于加密，一对由CA产生，主要用于签名。

3、为什么需要CA证书认证机构呢？

CA证书是为了确保服务端的公钥是准确无误、没有被修改过的。虽然https是加密的，但是请求还是可以被拦截的，假设没有CA证书，如果服务器返回的包含公钥的包被攻击者截取，然后攻击者也生成一对公私钥，他将自己的公钥发给客户端。攻击者得到客户端数据后进行解密，然后再通过服务器的公钥加密发给服务器，这样数据就被攻击者获取到了。

有了CA证书后，客户端根据内置的CA根证书，很容易识别出攻击者的公钥不合法，或者说攻击者的证书不合法。

证书通常包含这些内容：(1) 服务端的公钥；(2) 证书发行者(CA)对证书的数字签名；(3) 证书所用的签名算法；(4) 证书发布机构、有效期、所有者的信息等其他信息

4、SSL/TLS

https比http安全的原因就是它在TCP协议之上加入了SSL(Secure Sockets Layer 安全套接字协议)

众所周知，http(s)协议是工作在应用层，而其下就是传输层，而http(s)协议是基于传输层中的TCP协议之上的，就是说http(s)的数据传输是要在TCP三次握手后，也就是建立连接的基础上才能进行http(s)通信

原本的http协议直接就是TCP握手完，就用明文传输数据

而https协议则是在TCP协议之上加入了SSL加密协议，在传输数据之前先进行加密

SSL是一个不依赖于平台和运用程序的协议，位于TCP/IP协议与各种应用层协议之间，为数据通信提高安全支持。

SSL协议提供的安全通道有以下三个特性：

**机密性：**SSL协议使用密钥加密通信数据。
**可靠性：**服务器和客户都会被认证，客户的认证是可选的。
**完整性：**SSL协议会对传送的数据进行完整性检查。

SSL提供服务

认证用户和服务器，确保数据发送到正确的客户机和服务器
加密数据以防止数据中途被窃取
维护数据的完整性，确保数据在传输过程中不被改变。

SSL原理详解

SSL的体系结构中包含两个协议子层，其中高层是SSL握手协议层（SSL HandShake Protocol Layer）；底层是SSL记录协议层（SSL Record Protocol Layer）。

SSL协议主要分为两层：

SSL握手协议层包括SSL握手协议（SSL HandShake Protocol）、SSL密码参数修改协议（SSL Change Cipher Spec Protocol）和SSL告警协议（SSL Alert Protocol）。握手层的这些协议用于SSL管理信息的交换，允许应用协议传送数据之间相互验证，协商加密算法和生成密钥等。
SSL记录协议层的作用是为高层协议提供基本的安全服务。SSL纪录协议针对HTTP协议进行了特别的设计，使得超文本的传输协议HTTP能够在SSL运行。纪录封装各种高层协议，具体实施压缩解压缩、加密解密、计算和校验MAC等与安全有关的操作。

SSL握手协议的作用是协调客户和服务器的状态，使双方能够达到状态的同步。

其中最重要的是握手协议和记录协议：

SSL握手协议：它建立在SSL记录协议之上，用于在实际的数据传输开始之前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。
SSL记录协议：它建立在可靠的传输（如TCP）之上，为高层协议提供数据分块、数据封装、压缩、解压缩、加密、解密等基本功能。

什么是TLS？

简单点说，TLS就是规范化的SSL

早期TCP上的https传输用的加密协议是SSL，等到SSL发展到3.0之后，有一个国际机构将其标准化，标准化之后的SSL就叫做TLS，不过人们还是习惯叫SSL，现在大部分用的就是TLS，不过大家喜欢叫做SSL而已，就一回事.

对称加密和非对称加密

数字签名和数字证书

数字签名

回到刚才实名举报的例子，举报信的传输是安全了（因为只有检举机构的私钥能解密），那如果检举机构想对举报人回信，在举报人的角度怎么能证实收到的回信是检举机构发的呢？

在现实中很简单，不就盖个章嘛（不考虑被伪造的情况）

这个章在密码学里叫数字签名，既表明自己身份唯一的标识

那这个签名怎么签呢？

假如我是检举机构，我的回信叫letter

1.letter内容+Hash函数——>摘要

2.摘要+私钥——>数字签名

3.将数字签名放在letter内容的下面发送给举报人

注意：在数字签名的过程中，只有私钥是具有唯一性的，hash函数是公开的，letter内容可能被截获修改！

对于举报人，关心的只有两点：1.信是不是检举机构寄的？ 2.信的内容有没有被黑客修改？

如果上诉两点一旦确认为 1.是 2.没有那这封信就无误了。

那怎么求证呢？我们看举报人收到了什么内容，有信的内容和数字签名

对于第一点：1.信是不是检举机构寄的？

因为私钥是检举机构的唯一标识，只能通过验证数字签名来求证

数字签名+公钥，如果能成功得到摘要就确定数字签名没有被伪造，既信是检举机构寄的

对于第二点： 2.信的内容有没有被黑客修改？

前文说过，hash是公开的，如果上面验证了数字签名的正确性，那摘要就是可以反应原文的，所以

letter内容+hash 得到摘要，再与上面解密数字签名的摘要对比，一样的话就是没有修改
数字证书

有朋友说，有数字签名，双方不就可以安全通信了吗，那数字证书是什么？

上面一切可靠通信的前提是，举报人手持的公钥和检举单位的私钥是一对

当举报人手上的公钥被恶意替换成某诈骗公司的公钥之后，诈骗公司就可以伪装成检举机构和举报人通信而不被发现，因为诈骗公司本身就拥有自己的私钥，而且把举报人的公钥替换成了自己的公钥，而举报人根本发现不了，还以为自己跟检举机构安全保密的通信呢。

这时候就要数字证书登场了！

证书中心（certificate authority，简称CA）用自己的私钥，检举机构的公钥和一些相关信息一起加密，生成"数字证书"（Digital Certificate）。

数字证书保证了检举机构和对应公钥的匹配性

就是说，检举机构下次寄信时带上这个数字证书，举报人用CA的公钥解密的到检举机构的公钥，和客户端（浏览器）的"证书管理器"，有"受信任的根证书颁发机构"列表对比，如果在上面就可以，不在上面就是假的公钥。

扩展：有的朋友就说了，那如果CA的公钥被替换了怎么办？

有兴趣的朋友可以去了解一下这种情况，称为中间人攻击，既黑客组织同时冒充服务端和客户端进行双向伪装通信

三、http的请求与响应

1、http的常见请求方式：

（1）get：向服务端获取资源，所以查询操作一般用get
（2）post：向服务端提交请求字段，创建操作使用 post，该操作不是幂等的，多次执行会导致多条数据被创建
（3）put：修改指定URL的资源，如果资源不存在，则进行创建，修改操作一般使用 put，在http中，put 被定义成幂等的，多次操作会导致前面的数据被覆盖
（4）patch：局部修改URL所在资源的数据，是对put的补充
（5）delete：删除指定URL的资源。
（6）head：获取响应报文的首部，即获得URL资源的头部
（7）options：询问服务器支持哪些方法，响应头中返回 Allow: GET、POST、HEAD
（8）trace：追踪路径，主要用于测试或诊断；在请求头中在Max-Forwards字段设置数字，每经过一个服务器该数字就减一，当到0的时候就直接返回，一般通过该方法检查请求发送出去是否被篡改

2、get和 post 请求的区别：

（1）功能：get一般用来从服务器上面获取资源，post一般用来更新服务器上面的资源。
（2）幂等性：get 是幂等的，post 为非幂等的
（3）安全性：get 请求的参数会明文附加在URL之后，而 post 请求提交的数据则被封装到请求体中，相对更安全。
（4）传输数据量的大小：get请求允许发送的数据量比较小，大多数浏览器都会限制请求的url长度在2048个字节，而大多数服务器最多处理64K大小的url；而post请求提交的数据量则是没有大小限制的。
（5）参数的数据类型：GET只接受ASCII字符，而POST没有限制。
（6）GET在浏览器回退时是无害的，而POST会再次提交请求。
（7）get请求可以被缓存，可以被保留在浏览器的历史记录中；post请求不会被缓存，不会被保留在浏览器的历史记录中。

GET和POST本质上就是TCP连接。一般在使用的时候，get方法将参数放在url中，post将参数放在request body当中。但是他们本质的区别（？并不是这样）：GET产生一个TCP数据包；POST产生两个TCP数据包。
Get方法：把http header和data放在一起发送，服务器返回200.
Post方法：浏览器先发http header，服务器返回100 continue，浏览器再发送data，服务器返回200

3、http报文头分析：

（1）报文类型：报文类型分为请求报文和响应报文

① 请求报文包含三部分：

请求行：包含请求方法、URI、HTTP版本信息
请求首部字段
请求内容实体

② 响应报文包含三部分：

状态行：包含HTTP版本、状态码、状态码的原因短语
响应首部字段
响应内容实体

（2）报文中各部分的简要描述：

方法(method)：客户端希望服务器对资源执行的动作，是一个单独的词，比如：get 或者 post
请求URL(request-URL)：请求URL是资源的绝对路径，服务器可以假定自己是URL的主机/端口
版本(version)：报文所使用的Http版本，其格式：HTTP/<主要版本号>.<次要版本号>
状态码(status-code)：标识请求过程中所发生的情况
原因短语(reason-phrase)：数字状态码的可读版本，包含行终止序列之前的所有文本。
请求头部(header)：可以有零个或多个头部，每个首部都包含一个名字，后面跟着一个冒号(😃，然后是一个可选的空格，接着是一个值，最后是一个CRLF首部是由一个空行(CRLF)结束的，表示了头部列表的结束和实体主体部分的开始
实体的主体部分(entity-body)：实体的主体部分包含一个由任意数据组成的数据块，并不是所有的报文都包含实体的主体部分，有时，报文只是以一个CRLF结束。

（3）通用头部：既可以出现在请求报文中，也可以出现在响应报文中，它提供了与报文相关的最基本的信息：

Connection：允许客户端和服务器指定与请求/响应连接有关的选项，http1.1之后默认是 keep-alive
Date：日期和时间标志，说明报文是什么时间创建的
Transfer-Encoding：告知接收端为了保证报文的可靠传输，对报文采用了什么编码方式
Cache-Control：用于随报文传送缓存指示

（4）请求头部：请求头部是只在请求报文中有意义的头部。用于说明是谁或什么在发送请求、请求源自何处，或者客户端的喜好及能力

Host：给出了接收请求的服务器的主机名和端口号
Referer：提供了包含当前请求URI的文档的URL
User-Agent：将发起请求的应用程序名称告知服务器
Accept：告诉服务器能够发送哪些媒体类型
Accept-Encoding：告诉服务器能够发送哪些编码方式
Accept-Language：告诉服务器能够发送哪些语言
Range：如果服务器支持范围请求，就请求资源的指定范围
If-Range：允许对文档的某个范围进行条件请求
Authorization：包含了客户端提供给服务器，以便对其自身进行认证的数据
Cookie：客户端用它向服务器传送数据

（5）响应头部：响应头部为客户端提供了一些额外信息，比如谁在发送响应、响应者的功能，甚至与响应相关的一些特殊指令

Age：(从最初创建开始)响应持续时间
Server：服务器应用程序软件的名称和版本
Accept-Ranges：对此资源来说，服务器可接受的范围类型
Set-Cookie：在客户端设置数据，以便服务器对客户端进行标识

（6）实体首部：描述主体的长度和内容，或者资源自身

Allow：列出了可以对此实体执行的请求方法
Location：告知客户端实体实际上位于何处，用于将接收端定向到资源的位置(URL)上去
Content-Base：解析主体中的相对URL时使用的基础URL
Content-Encoding：对主体执行的任意编码方式
Content-Language：理解主体时最适宜使用的自然语言
Content-Length：主体的长度
Content-Type：这个主体的对象类型
ETag：与此实体相关的实体标记
Last-Modified：这个实体最后一次被修改的日期和时间

（7）实体的主体部分：该部分其实就是HTTP要传输的内容，是可选的。HTTP报文可以承载很多类型的数字数据，比如，图片、视频、HTML文档电子邮件、软件应用程序等等。

4、Http 常见的状态码：

所有HTTP响应的第一行都是状态行，依次是当前HTTP版本号，3位数字组成的状态代码，以及描述状态的短语，彼此由空格分隔。

（1）1xx：请求处理中，请求已被接受，正在处理。

（2）2xx：请求成功，请求被成功处理。

200 ：OK，客户端请求成功；
204（请求处理成功，但是没有资源返回）

（3）3xx：重定向，要完成请求必须进一步处理。

301：永久性转移，请求的资源已经被分配到了新的地址
302：暂时重定向
304：已缓存。

（4）4xx：客户端错误，请求不合法。

400：客户端请求报文出现错误，通常是参数错误
401：客户端未认证授权
403：没有权限访问该资源
404：未找到请求的资源
405：不支持该请求方法，如果服务器支持GET，客户端用POST请求就会出现这个错误码

（5）5xx：服务端错误，服务端不能处理合法请求。

500：服务器内部错误。
503：服务不可用，一段时间后可能恢复正常。

5、http1.0和http1.1的主要区别是什么

⻓连接 : 在HTTP/1.0中，默认使⽤的是短连接，也就是说每次请求都要重新建⽴⼀次连接。HTTP 是基于TCP/IP协议的,每⼀次建⽴或者断开连接都需要三次握⼿四次挥⼿的开销，如果每次请求都要这样的话，开销会⽐较⼤。因此最好能维持⼀个⻓连接，可以⽤个⻓连接来发多个请求。HTTP 1.1起，默认使⽤⻓连接 ,默认开启Connection： keep-alive。 HTTP/1.1的持续连接有⾮流⽔线⽅式和流⽔线⽅式 。流⽔线⽅式是客户在收到HTTP的响应报⽂之前就能接着发送新的请求报⽂。与之相对应的⾮流⽔线⽅式是客户在收到前⼀个响应后才能发送下⼀个请求。
错误状态响应码 :在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发⽣冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
缓存处理 :在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（PartialContent），这样就⽅便了开发者⾃由的选择以便于充分利⽤带宽和连接。

6、http/1.x和http/2.0的区别：

（1）多路复用，做到同一个连接并发处理多个请求：HTTP2.0 使用了多路复用的技术，做到同一个连接并发处理多个请求，并发请求的数量比HTTP1.1大了好几个数量级。http 2.0 通信都在一个连接上完成，这个连接可以承载任意数量的双向数据流。相应地，每个数据流以消息的形式发送，而消息由一或多个帧组成，这些帧可以乱序发送，然后再根据每个帧首部的流标识符重新组装。一个request对应一个id，这样一个连接上可以有多个request，每个连接的request可以随机的混杂在一起，接收方可以根据request的 id将request再归属到各自不同的服务端请求里面。

（2）支持首部压缩：HTTP2.0使用HPACK算法对header的数据进行压缩，这样数据体积小了，在网络上传输就会更快。

（3）服务器推送：当向支持HTTP2.0的web服务器请求时，服务器会顺便把客户端需要的资源一起推送到客户端，避免客户端再次创建连接发送请求到服务器端获取，这种方式非常合适加载静态资源。

（4）http2.0采用二进制而不是文本格式。http 2.0会将所有传输的信息分割为更小的消息和帧，并对它们采用二进制格式的编码，其中http.x的首部信息会被封装到Headers帧，而我们的request body则封装到Data帧里面。

**为什么需要头部压缩？**假定一个页面有100个资源需要加载（这个数量对于今天的Web而言还是挺保守的）, 而每一次请求都有1kb的消息头（这同样也并不少见，因为Cookie和引用等东西的存在）, 则至少需要多消耗100kb来获取这些消息头。HTTP2.0可以维护一个字典，差量更新HTTP头部，大大降低因头部传输产生的流量。具体参考：HTTP/2 头部压缩技术介绍

**HTTP2.0多路复用有多好？**HTTP 性能优化的关键并不在于高带宽，而是低延迟。TCP 连接会随着时间进行自我「调谐」，起初会限制连接的最大速度，如果数据成功传输，会随着时间的推移提高传输的速度。这种调谐则被称为 TCP 慢启动。由于这种原因，让原本就具有突发性和短时性的 HTTP 连接变的十分低效。HTTP/2 通过让所有数据流共用同一个连接，可以更有效地使用 TCP 连接，让高带宽也能真正的服务于 HTTP 的性能提升。

7、http 和 https 的区别、https的实现过程

（1）http 和 https 都是基于 TCP 协议，但是 http 是使用明文传输，通讯内容可能被窃听和篡改，客户端也无法验证通讯方的身份，无法保证数据发送到正确的机器上；https 是在 http 的基础上加入了 SSL/TLS，可看成是添加了加密和认证机制的http，使用对称加密、非对称加密、证书等技术进行进行客户端与服务端的数据加密传输，最终达到保证整个通信的安全性。

（2）端口不同：http 使用的是80端口，https 使用的443端口

（3）资源消耗：和 http 通信相比，https通信会由于加解密处理消耗更多的CPU和内存资源

https实现过程（SSL/TLS握手过程）

浏览器将支持的加密算法信息发给服务器
服务器选择一套浏览器支持的加密算法，以证书的形式回发给浏览器
客户端(SSL/TLS)解析证书验证证书合法性，生成对称加密的密钥，我们将该密钥称之为client key，即客户端密钥，用服务器的公钥对客户端密钥进行非对称加密。
客户端会发起HTTPS中的第二个HTTP请求，将加密之后的客户端对称密钥发送给服务器
服务器接收到客户端发来的密文之后，会用自己的私钥对其进行非对称解密，解密之后的明文就是客户端密钥，然后用客户端密钥对数据进行对称加密，这样数据就变成了密文。
服务器将加密后的密文发送给客户端
客户端收到服务器发送来的密文，用客户端密钥对其进行对称解密，得到服务器发送的数据。这样HTTPS中的第二个HTTP请求结束，整个HTTPS传输完成

四、应用层其他相关的协议：

（1）DNS域名系统：用于域名解析服务，将域名地址转换为IP地址，基于UDP服务，使用53端口。

DNS底层既使用TCP又使用UDP协议：

① 域名解析时使用UDP协议：客户端向DNS服务器查询域名，一般返回的内容都不超过512字节，用UDP传输即可，不用经过TCP三次握手，这样DNS服务器负载更低，响应更快。当DNS查询超过512字节时，协议的TC标志出现删除标志，这时则使用TCP发送。通常传统的UDP报文一般不会大于512字节。虽然从理论上说，客户端也可以指定向DNS服务器查询的时候使用TCP，但事实上，很多DNS服务器进行配置的时候，仅支持UDP查询包。

② 区域传送时使用TCP，主要有一下两点考虑：

辅域名服务器会定时（一般时3小时）向主域名服务器进行查询以便了解数据是否有变动。如有变动，则会执行一次区域传送，进行数据同步。区域传送将使用TCP而不是UDP，因为数据同步传送的数据量比一个请求和应答的数据量要多得多。
TCP是一种可靠的连接，保证了数据的准确性。

补充：

DNS的规范规定了2种类型的DNS服务器，一个叫主DNS服务器，一个叫辅助DNS服务器。在一个区中主DNS服务器从自己本机的数据文件中读取该区的DNS数据信息，而辅助DNS服务器则从区的主DNS服务器中读取该区的DNS数据信息。当一个辅助DNS服务器启动时，它需要与主DNS服务器通信，并加载数据信息，这就叫做区传送（zone transfer）。

当主域名服务器出现故障、关闭或负载过重时，辅助域名服务器作为主域名服务器的备份提供域名解析服务。辅助域名服务器中的区域文件中的数据是从另外的一台主域名服务器中复制过来的，是不可以修改的。

迭代查询：
① 请求发起后，游览器首先会解析这个域名，首先它会查看本地硬盘的 hosts 文件，看看其中有没有和这个域名对应的规则，如果有的话就直接使用 hosts 文件里面的 ip 地址。
② 如果在本地的 hosts 文件没有能够找到对应的 ip 地址，浏览器会发出一个 DNS请求到本地DNS(域名分布系统)服务器 。本地DNS服务器一般都是你的网络接入服务器商提供，比如中国电信，中国移动。
③ 查询你输入的网址的DNS请求到达本地DNS服务器之后，本地DNS服务器会首先查询它的缓存记录，如果缓存中有此条记录，就可以直接返回结果，此过程是递归的方式进行查询。如果没有，本地DNS服务器还要向DNS根服务器进行查询
④ 根DNS服务器没有记录具体的域名和IP地址的对应关系，而是告诉本地DNS服务器，你可以到那个顶级域服务器上去继续查询，并给出顶级域服务器的地址。这种过程是迭代的过程
⑤ 本地DNS服务器继续向顶级域服务器发出请求，顶级域服务器收到请求之后，也不会直接返回域名和IP地址的对应关系，而是告诉本地DNS服务器，你应该去找那个权限域名服务器
⑥ 最后，本地DNS服务器向权限域名服务器发出请求，这时就能收到一个域名和IP地址对应关系，本地DNS服务器不仅要把IP地址返回给用户电脑，还要把这个对应关系保存在缓存中，以备下次别的用户查询时，可以直接返回结果，加快网络访问。

（2）FTP：定义了文件传输协议，使用21端口。上传下载文件，都要用到FTP服务。

（3）Telnet：远程终端协议，它是一种用于远程登陆的端口，用户可以以自己的身份远程连接到计算机上，提供一种基于DOS模式下的通信服务。

（4）SMTP：定义了简单邮件传送协议，用于发送邮件，使用25号端口。

（5）POP3：与SMTP对应，POP3用于接收邮件。使用110端口。

（6）SNMP：简单网络管理协议，使用161号端口，是用来管理网络设备的。

（7）TFTP(Trival File Transfer Protocal)：简单文件传输协议，该协议在69端口上使用UDP服务。

https://blog.csdn.net/a745233700/article/details/114824602

https://www.cnblogs.com/sinlearn/p/15100446.html

https://blog.csdn.net/qq_36452584/article/details/115270305

https://blog.csdn.net/m0_37907797/article/details/103252306

https://www.zhihu.com/question/31965904/answer/316810167

https://blog.csdn.net/mw_myever/article/details/109163961

https://zhuanlan.zhihu.com/p/359935850

https://zhuanlan.zhihu.com/p/60305452

5.各层的网络设备，对应的协议

一、各层设备

https://blog.csdn.net/m0_62591999/article/details/121174253

https://www.jianshu.com/p/dfb08cb87773

二、各层协议

杂记

9.HTTP

https://blog.csdn.net/u014294681/article/details/86585326

https://zhuanlan.zhihu.com/p/281910644

10.SSL/TSL

https://www.jianshu.com/p/d2c21c7bf38d

https://blog.csdn.net/cy973071263/article/details/105309476

https://www.cnblogs.com/plorde/p/12304965.html

https://www.jianshu.com/p/a7292b4db7bd

SSL协议的工作流程_weixin_34194087的博客-CSDN博客

SDN博客_计算机网络tcp](https://blog.csdn.net/m0_46365614/article/details/114769176)

计算机网络：这是一份全面 & 详细的TCP协议攻略 - 简书 (jianshu.com)

TCP/IP 常用协议 - 疯狂的小牛仔 - 博客园 (cnblogs.com)

8.Session和Cookie的详解和区别使用

cookie和session的详解与区别 - 测试开发喵 - 博客园 (cnblogs.com)

session和cookie区别详解 - 幽篁晓筑 - 博客园 (cnblogs.com)

(1条消息) Cookie和Session的区别（面试必备）_chen13333336677的博客-CSDN博客_session和cookie的区别面试题

面试常考之cookie和session的区别 - 可樂_Thompson - 博客园 (cnblogs.com)

(1条消息) java面试题：session和cookie的区别_我是方小磊的博客-CSDN博客_面试题session和cookie的区别