网络

OSI 七层模型

应用层：网络服务与用户的一个接口，实现用户的各种应用或功能.
表示层：数据的表示、安全、压缩.
会话层：建立、管理、终止会话.
传输层：实现可靠或不可靠的传输.
网络层：添加 ip 地址，实现不同网络的路径选择.
数据链路层：添加物理地址，实现链路通信.
物理层：建立、维护、断开物理连接.

交换机

交换机中将不同的接口划入不同的 vlan 等

路由器

1 请解释 TCP 和 UDP 之间的区别？

答：TCP 和 UDP 是两种不同的传输协议。TCP 是一种有连接的、可靠的协议，通常用于承载传输控制和应用程序数据。UDP 是一种无连接的、不可靠的协议，通常用于传输实时数据，如音频和视频。TCP 通过三次握手建立连接，而 UDP 不需要建立连接。TCP 提供了拥塞控制、流量控制和差错纠正机制，UDP 则没有这些机制。

2 请解释 HTTP 和 HTTPS 之间的区别？

答：HTTP 是一种超文本传输协议，用于在 Web 浏览器和 Web 服务器之间交换信息。HTTPS 是一种安全的 HTTP 协议，使用了安全套接层(SSL)协议来加密数据，保护用户的隐私和网站的安全。HTTPS 使用 HTTPS 加密证书来验证 Web 服务器的身份。HTTP 和 HTTPS 使用的端口不同，HTTP 默认端口是 80，HTTPS 默认端口是 443。

3 解释 OSI 模型的七层？

答：OSI 模型的七层是物理层、数据链路层、网络层、传输层、会话层、表示层和应用层。物理层负责将数据从一个设备传输到另一个设备，数据链路层负责将数据分成帧，并将帧发送到网络层。网络层负责路由和转发数据，传输层负责可靠传输，会话层负责建立、管理和终止会话，表示层负责数据格式转换，应用层负责为应用程序提供服务和数据。

4 请解释 TCP/IP 模型的四层？

答：TCP/IP 模型的四层是网络接口层、网络层、传输层和应用层。网络接口层负责将数据从一个设备传输到另一设备，网络层负责路由和转发数据，传输层负责可靠传输，并提供了 TCP 和 UDP 两种协议。应用层负责为应用程序提供服务和数据，包括 HTTP、SMTP 和 FTP 等协议。

5 请解释 HTTP 请求和响应的常用内容？

答：HTTP 请求分为方法、URL 和 HTTP 版本；响应分为状态码、原因短语和 HTTP 版本。常见的 HTTP 方法包括 GET、POST、PUT、DELETE 等，URL 指定请求的资源的位置，HTTP 版本通常是 HTTP/1.1 或 HTTP/2.0。状态码指示服务器是否成功处理请求，常见的状态码包括 200、404、500。原因短语指定状态码的详细描述，例如“Not Found”、“Internal Server Error”。

6 请解释负载均衡？

答：负载均衡是一种将流量分发到多个服务中的技术，以实现高可用性、可伸缩性和性能。负载均衡可以将请求分发到多个服务器上，从而避免单个服务器过载或故障的情况。常见的负载均衡算法包括轮询、最少连接、IP 哈希和加权轮询等。

7 什么是 UDP 风暴？

答：UDP 风暴是一种网络攻击，攻击者向目标主机发送大量的 UDP 数据包，导致目标主机因处理大量的无用数据包而变得不可用。UDP 风暴通常的威胁来自于使用默认端口的 UDP 服务，例如 DNS 和 NTP 等，这些服务容易受到攻击。

8 解释 ARP 协议？

答：ARP（地址解析协议）是一种用于解析 MAC 地址和 IP 地址之间映射的协议。当主机 A 需要向主机 B 发送数据时，主机 A 会首先向本地网络中广播 ARP 请求，请求目标主机的 MAC 地址。目标主机收到请求后，将其 MAC 地址返回给主机 A，主机 A 就可以使用这个 MAC 地址向主机 B 发送数据。

9 解释 SSL 协议？

答：SSL（安全套接层）是一种加密协议，用于在客户端和服务器之间安全地传输数据。SSL 使用公钥和私钥加密和解密数据，以保护数据的隐私和完整性。SSL 使用数字证书来认证服务器的身份，以保护数据传输的安全。

10 解释 HTTP 代理？

答：HTTP 代理是一种中间服务器，用于转发客户端和服务器之间的 HTTP 请求和响应。HTTP 代理可以用于访问受限资源或绕过访问控制，也可以用于缓存静态资源以减少网络流量和提高响应速度。常见的 HTTP 代理包括正向代理和反向代理，正向代理用于代理客户端，反向代理用于代理服务器。

https://www.xjx100.cn/news/744285.html?action=onClick

1、谈下你对五层网络协议体系结构的理解？

学习计算机网络时我们一般采用折中的办法，也就是中和 OSI 和 TCP/IP 的优点，采用一种只有五层协议的体系结构，这样既简洁又能将概念阐述清楚。

image.png

1. 应用层
   应用层（application-layer）的任务是通过应用进程间的交互来完成特定网络应用。应用层协议定义的是应用进程（进程：主机中正在运行的程序）间的通信和交互的规则。对于不同的网络应用需要不同的应用层协议。在互联网中应用层协议很多，如域名系统 DNS，支持万维网应用的 HTTP 协议，支持电子邮件的 SMTP 协议等等。我们把应用层交互的数据单元称为报文。

2. 运输层
   运输层（transport layer）的主要任务就是负责向两台主机进程之间的通信提供通用的数据传输服务。应用进程利用该服务传送应用层报文。“通用的”是指并不针对某一个特定的网络应用，而是多种应用可以使用同一个运输层服务。

由于一台主机可同时运行多个线程，因此运输层有复用和分用的功能。所谓复用就是指多个应用层进程可同时使用下面运输层的服务，分用和复用相反，是运输层把收到的信息分别交付上面应用层中的相应进程。

3. 网络层
   在计算机网络中进行通信的两个计算机之间可能会经过很多个数据链路，也可能还要经过很多通信子网。网络层的任务就是选择合适的网间路由和交换结点， 确保数据及时传送。在发送数据时，网络层把运输层产生的报文段或用户数据报封装成分组和包进行传送。在 TCP / IP 体系结构中，由于网络层使用 IP 协议，因此分组也叫 IP 数据报，简称数据报。

4. 数据链路层
   数据链路层（data link layer）通常简称为链路层。两台主机之间的数据传输，总是在一段一段的链路上传送的，这就需要使用专门的链路层的协议。在两个相邻节点之间传送数据时，数据链路层将网络层交下来的 IP 数据报组装成帧，在两个相邻节点间的链路上传送帧。每一帧包括数据和必要的控制信息（如：同步信息，地址信息，差错控制等）。

在接收数据时，控制信息使接收端能够知道一个帧从哪个比特开始和到哪个比特结束。这样，数据链路层在收到一个帧后，就可从中提出数据部分，上交给网络层。控制信息还使接收端能够检测到所收到的帧中有无差错。如果发现差错，数据链路层就简单地丢弃这个出了差错的帧，以避免继续在网络中传送下去白白浪费网络资源。如果需要改正数据在链路层传输时出现差错（这就是说，数据链路层不仅要检错，而且还要纠错），那么就要采用可靠性传输协议来纠正出现的差错。这种方法会使链路层的协议复杂些。

5. 物理层
   在物理层上所传送的数据单位是比特。物理层（physical layer）的作用是实现相邻计算机节点之间比特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异。使其上面的数据链路层不必考虑网络的具体传输介质是什么。“透明传送比特流”表示经实际电路传送后的比特流没有发生变化，对传送的比特流来说，这个电路好像是看不见的。

2、简单说下每一层对应的网络协议有哪些？

计算机五层网络体系中涉及的协议非常多，下面就常用的做了列举：

image.png

3、ARP 协议的工作原理？

网络层的 ARP 协议完成了 IP 地址与物理地址的映射。首先，每台主机都会在自己的 ARP 缓冲区中建立一个 ARP 列表，以表示 IP 地址和 MAC 地址的对应关系。当源主机需要将一个数据包要发送到目的主机时，会首先检查自己 ARP 列表中是否存在该 IP 地址对应的 MAC 地址：如果有，就直接将数据包发送到这个 MAC 地址；如果没有，就向本地网段发起一个 ARP 请求的广播包，查询此目的主机对应的 MAC 地址。

此 ARP 请求数据包里包括源主机的 IP 地址、硬件地址、以及目的主机的 IP 地址。网络中所有的主机收到这个 ARP 请求后，会检查数据包中的目的 IP 是否和自己的 IP 地址一致。如果不相同就忽略此数据包；如果相同，该主机首先将发送端的 MAC 地址和 IP 地址添加到自己的 ARP 列表中，如果 ARP 表中已经存在该 IP 的信息，则将其覆盖，然后给源主机发送一个 ARP 响应数据包，告诉对方自己是它需要查找的 MAC 地址；源主机收到这个 ARP 响应数据包后，将得到的目的主机的 IP 地址和 MAC 地址添加到自己的 ARP 列表中，并利用此信息开始数据的传输。如果源主机一直没有收到 ARP 响应数据包，表示 ARP 查询失败。

4、谈下你对 IP 地址分类的理解？

IP 地址是指互联网协议地址，是 IP 协议提供的一种统一的地址格式，它为互联网上的每一个网络和每一台主机分配一个逻辑地址，以此来屏蔽物理地址的差异。IP 地址编址方案将 IP 地址空间划分为 A、B、C、D、E 五类，其中 A、B、C 是基本类，D、E 类作为多播和保留使用，为特殊地址。

每个 IP 地址包括两个标识码（ID），即网络 ID 和主机 ID。同一个物理网络上的所有主机都使用同一个网络 ID，网络上的一个主机（包括网络上工作站，服务器和路由器等）有一个主机 ID 与其对应。A~E 类地址的特点如下：

A 类地址：以 0 开头，第一个字节范围：0~127；

B 类地址：以 10 开头，第一个字节范围：128~191；

C 类地址：以 110 开头，第一个字节范围：192~223；

D 类地址：以 1110 开头，第一个字节范围为 224~239；

E 类地址：以 1111 开头，保留地址

5、TCP 的主要特点是什么？

1. TCP 是面向连接的。（就好像打电话一样，通话前需要先拨号建立连接，通话结束后要挂机释放连接）；

2. 每一条 TCP 连接只能有两个端点，每一条 TCP 连接只能是点对点的（一对一）；

3. TCP 提供可靠交付的服务。通过 TCP 连接传送的数据，无差错、不丢失、不重复、并且按序到达；

4. TCP 提供全双工通信。TCP 允许通信双方的应用进程在任何时候都能发送数据。TCP 连接的两端都设有发送缓存和接收缓存，用来临时存放双方通信的数据；

5. 面向字节流。TCP 中的“流”（Stream）指的是流入进程或从进程流出的字节序列。“面向字节流”的含义是：虽然应用程序和 TCP 的交互是一次一个数据块（大小不等），但 TCP 把应用程序交下来的数据仅仅看成是一连串的无结构的字节流。

6、UDP 的主要特点是什么？

1. UDP 是无连接的；

2. UDP 使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的链接状态（这里面有许多参数）；

3. UDP 是面向报文的；

4. UDP 没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如 直播，实时视频会议等）；

5. UDP 支持一对一、一对多、多对一和多对多的交互通信；

6. UDP 的首部开销小，只有 8 个字节，比 TCP 的 20 个字节的首部要短。

7、TCP 和 UDP 的区别？

image.png

TCP 提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。TCP 不提供广播或多播服务。由于 TCP 要提供可靠的，面向连接的运输服务（TCP 的可靠体现在 TCP 在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，在数据传完后，还会断开连接用来节约系统资源），这难以避免增加了许多开销，如确认，流量控制，计时器以及连接管理等。这不仅使协议数据单元的首部增大很多，还要占用许多处理机资源。

UDP 在传送数据之前不需要先建立连接，远地主机在收到 UDP 报文后，不需要给出任何确认。虽然 UDP 不提供可靠交付，但在某些情况下 UDP 确是一种最有效的工作方式（一般用于即时通信），比如：QQ 语音、 QQ 视频 、直播等等。

8、TCP 和 UDP 分别对应的常见应用层协议有哪些？

1. TCP 对应的应用层协议
   FTP：定义了文件传输协议，使用 21 端口。常说某某计算机开了 FTP 服务便是启动了文件传输服务。下载文件，上传主页，都要用到 FTP 服务。

Telnet：它是一种用于远程登陆的端口，用户可以以自己的身份远程连接到计算机上，通过这种端口可以提供一种基于 DOS 模式下的通信服务。如以前的 BBS 是-纯字符界面的，支持 BBS 的服务器将 23 端口打开，对外提供服务。

SMTP：定义了简单邮件传送协议，现在很多邮件服务器都用的是这个协议，用于发送邮件。如常见的免费邮件服务中用的就是这个邮件服务端口，所以在电子邮件设置-中常看到有这么 SMTP 端口设置这个栏，服务器开放的是 25 号端口。

POP3：它是和 SMTP 对应，POP3 用于接收邮件。通常情况下，POP3 协议所用的是 110 端口。也是说，只要你有相应的使用 POP3 协议的程序（例如 Fo-xmail 或 Outlook），就可以不以 Web 方式登陆进邮箱界面，直接用邮件程序就可以收到邮件（如是 163 邮箱就没有必要先进入网易网站，再进入自己的邮-箱来收信）。

HTTP：从 Web 服务器传输超文本到本地浏览器的传送协议。

2. UDP 对应的应用层协议
   DNS：用于域名解析服务，将域名地址转换为 IP 地址。DNS 用的是 53 号端口。

SNMP：简单网络管理协议，使用 161 号端口，是用来管理网络设备的。由于网络设备很多，无连接的服务就体现出其优势。

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

9、详细说下 TCP 三次握手的过程？

1. 三次握手
   TCP 建立连接的过程叫做握手，握手需要在客户和服务器之间交换三个 TCP 报文段。

image.png

最初客户端和服务端都处于 CLOSED(关闭) 状态。本例中 A（Client） 主动打开连接，B（Server） 被动打开连接。

一开始，B 的 TCP 服务器进程首先创建传输控制块 TCB，准备接受客户端进程的连接请求。然后服务端进程就处于 LISTEN(监听) 状态，等待客户端的连接请求。如有，立即作出响应。

第一次握手：A 的 TCP 客户端进程也是首先创建传输控制块 TCB。然后，在打算建立 TCP 连接时，向 B 发出连接请求报文段，这时首部中的同步位 SYN=1，同时选择一个初始序号 seq = x。TCP 规定，SYN 报文段（即 SYN = 1 的报文段）不能携带数据，但要消耗掉一个序号。这时，TCP 客户进程进入 SYN-SENT（同步已发送）状态。

第二次握手：B 收到连接请求报文后，如果同意建立连接，则向 A 发送确认。在确认报文段中应把 SYN 位和 ACK 位都置 1，确认号是 ack = x + 1，同时也为自己选择一个初始序号 seq = y。请注意，这个报文段也不能携带数据，但同样要消耗掉一个序号。这时 TCP 服务端进程进入 SYN-RCVD（同步收到）状态。

第三次握手：TCP 客户进程收到 B 的确认后，还要向 B 给出确认。确认报文段的 ACK 置 1，确认号 ack = y + 1，而自己的序号 seq = x + 1。这时 ACK 报文段可以携带数据。但如果不携带数据则不消耗序号，这种情况下，下一个数据报文段的序号仍是 seq = x + 1。这时，TCP 连接已经建立，A 进入 ESTABLISHED（已建立连接）状态。

10、为什么两次握手不可以呢？

为了防止已经失效的连接请求报文段突然又传送到了 B，因而产生错误。比如下面这种情况：A 发出的第一个连接请求报文段并没有丢失，而是在网路结点长时间滞留了，以致于延误到连接释放以后的某个时间段才到达 B。本来这是一个早已失效的报文段。但是 B 收到此失效的链接请求报文段后，就误认为 A 又发出一次新的连接请求。于是就向 A 发出确认报文段，同意建立连接。

对于上面这种情况，如果不进行第三次握手，B 发出确认后就认为新的运输连接已经建立了，并一直等待 A 发来数据。B 的许多资源就这样白白浪费了。

如果采用了三次握手，由于 A 实际上并没有发出建立连接请求，所以不会理睬 B 的确认，也不会向 B 发送数据。B 由于收不到确认，就知道 A 并没有要求建立连接。

11、为什么不需要四次握手？

有人可能会说 A 发出第三次握手的信息后在没有接收到 B 的请求就已经进入了连接状态，那如果 A 的这个确认包丢失或者滞留了怎么办？

我们需要明白一点，完全可靠的通信协议是不存在的。在经过三次握手之后，客户端和服务端已经可以确认之前的通信状况，都收到了确认信息。所以即便再增加握手次数也不能保证后面的通信完全可靠，所以是没有必要的。

12、Server 端收到 Client 端的 SYN 后，为什么还要传回 SYN？

接收端传回发送端所发送的 SYN 是为了告诉发送端，我接收到的信息确实就是你所发送的信号了。

SYN 是 TCP / IP 建立连接时使用的握手信号。在客户机和服务器之间建立正常的 TCP 网络连接时，客户机首先发出一个 SYN 消息，服务器使用 SYN-ACK 应答表示接收到了这个消息，最后客户机再以 ACK(Acknowledgement[汉译：确认字符，在数据通信传输中，接收站发给发送站的一种传输控制字符。它表示确认发来的数据已经接受无误]）消息响应。这样在客户机和服务器之间才能建立起可靠的 TCP 连接，数据才可以在客户机和服务器之间传递。

13、传了 SYN，为什么还要传 ACK？

双方通信无误必须是两者互相发送信息都无误。传了 SYN，证明发送方到接收方的通道没有问题，但是接收方到发送方的通道还需要 ACK 信号来进行验证。

14、详细说下 TCP 四次挥手的过程？

据传输结束后，通信的双方都可以释放连接。现在 A 和 B 都处于 ESTABLISHED 状态。

image.png

第一次挥手：A 的应用进程先向其 TCP 发出连接释放报文段，并停止再发送数据，主动关闭 TCP 连接。A 把连接释放报文段首部的终止控制位 FIN 置 1，其序号 seq = u（等于前面已传送过的数据的最后一个字节的序号加 1），这时 A 进入 FIN-WAIT-1（终止等待 1）状态，等待 B 的确认。请注意：TCP 规定，FIN 报文段即使不携带数据，也将消耗掉一个序号。

第二次挥手：B 收到连接释放报文段后立即发出确认，确认号是 ack = u + 1，而这个报文段自己的序号是 v（等于 B 前面已经传送过的数据的最后一个字节的序号加 1），然后 B 就进入 CLOSE-WAIT（关闭等待）状态。TCP 服务端进程这时应通知高层应用进程，因而从 A 到 B 这个方向的连接就释放了，这时的 TCP 连接处于半关闭（half-close）状态，即 A 已经没有数据要发送了，但 B 若发送数据，A 仍要接收。也就是说，从 B 到 A 这个方向的连接并未关闭，这个状态可能会持续一段时间。A 收到来自 B 的确认后，就进入 FIN-WAIT-2(终止等待 2)状态，等待 B 发出的连接释放报文段。

第三次挥手：若 B 已经没有要向 A 发送的数据，其应用进程就通知 TCP 释放连接。这时 B 发出的连接释放报文段必须使 FIN = 1。假定 B 的序号为 w（在半关闭状态，B 可能又发送了一些数据）。B 还必须重复上次已发送过的确认号 ack = u + 1。这时 B 就进入 LAST-ACK(最后确认)状态，等待 A 的确认。

第四次挥手：A 在收到 B 的连接释放报文后，必须对此发出确认。在确认报文段中把 ACK 置 1，确认号 ack = w + 1，而自己的序号 seq = u + 1（前面发送的 FIN 报文段要消耗一个序号）。然后进入 TIME-WAIT(时间等待) 状态。请注意，现在 TCP 连接还没有释放掉。必须经过时间等待计时器设置的时间 2MSL（MSL：最长报文段寿命）后，A 才能进入到 CLOSED 状态，然后撤销传输控制块，结束这次 TCP 连接。当然如果 B 一收到 A 的确认就进入 CLOSED 状态，然后撤销传输控制块。所以在释放连接时，B 结束 TCP 连接的时间要早于 A。

15、为什么 TIME-WAIT 状态必须等待 2MSL 的时间呢？

为了保证 A 发送的最后一个 ACK 报文段能够到达 B。这个 ACK 报文段有可能丢失，因而使处在 LAST-ACK 状态的 B 收不到对已发送的 FIN + ACK 报文段的确认。B 会超时重传这个 FIN+ACK 报文段，而 A 就能在 2MSL 时间内（超时 + 1MSL 传输）收到这个重传的 FIN+ACK 报文段。接着 A 重传一次确认，重新启动 2MSL 计时器。最后，A 和 B 都正常进入到 CLOSED 状态。如果 A 在 TIME-WAIT 状态不等待一段时间，而是在发送完 ACK 报文段后立即释放连接，那么就无法收到 B 重传的 FIN + ACK 报文段，因而也不会再发送一次确认报文段，这样，B 就无法按照正常步骤进入 CLOSED 状态。 2. 防止已失效的连接请求报文段出现在本连接中。A 在发送完最后一个 ACK 报文段后，再经过时间 2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样就可以使下一个连接中不会出现这种旧的连接请求报文段。

16、为什么第二次跟第三次不能合并, 第二次和第三次之间的等待是什么?

当服务器执行第二次挥手之后, 此时证明客户端不会再向服务端请求任何数据, 但是服务端可能还正在给客户端发送数据（可能是客户端上一次请求的资源还没有发送完毕），所以此时服务端会等待把之前未传输完的数据传输完毕之后再发送关闭请求。

17、保活计时器的作用？

除时间等待计时器外，TCP 还有一个保活计时器（keepalive timer）。设想这样的场景：客户已主动与服务器建立了 TCP 连接。但后来客户端的主机突然发生故障。显然，服务器以后就不能再收到客户端发来的数据。因此，应当有措施使服务器不要再白白等待下去。这就需要使用保活计时器了。

服务器每收到一次客户的数据，就重新设置保活计时器，时间的设置通常是两个小时。若两个小时都没有收到客户端的数据，服务端就发送一个探测报文段，以后则每隔 75 秒钟发送一次。若连续发送 10 个 探测报文段后仍然无客户端的响应，服务端就认为客户端出了故障，接着就关闭这个连接。

18、TCP 协议是如何保证可靠传输的？

1. 数据包校验：目的是检测数据在传输过程中的任何变化，若校验出包有错，则丢弃报文段并且不给出响应，这时 TCP 发送数据端超时后会重发数据；

2. 对失序数据包重排序：既然 TCP 报文段作为 IP 数据报来传输，而 IP 数据报的到达可能会失序，因此 TCP 报文段的到达也可能会失序。TCP 将对失序数据进行重新排序，然后才交给应用层；

3. 丢弃重复数据：对于重复数据，能够丢弃重复数据；

4. 应答机制：当 TCP 收到发自 TCP 连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒；

5. 超时重发：当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段；

6. 流量控制：TCP 连接的每一方都有固定大小的缓冲空间。TCP 的接收端只允许另一端发送接收端缓冲区所能接纳的数据，这可以防止较快主机致使较慢主机的缓冲区溢出，这就是流量控制。TCP 使用的流量控制协议是可变大小的滑动窗口协议。

19、谈谈你对停止等待协议的理解？

停止等待协议是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组；在停止等待协议中，若接收方收到重复分组，就丢弃该分组，但同时还要发送确认。主要包括以下几种情况：无差错情况、出现差错情况（超时重传）、确认丢失和确认迟到、确认丢失和确认迟到。

20、谈谈你对 ARQ 协议的理解？

自动重传请求 ARQ 协议
停止等待协议中超时重传是指只要超过一段时间仍然没有收到确认，就重传前面发送过的分组（认为刚才发送过的分组丢失了）。因此每发送完一个分组需要设置一个超时计时器，其重传时间应比数据在分组传输的平均往返时间更长一些。这种自动重传方式常称为自动重传请求 ARQ。

连续 ARQ 协议
连续 ARQ 协议可提高信道利用率。发送方维持一个发送窗口，凡位于发送窗口内的分组可以连续发送出去，而不需要等待对方确认。接收方一般采用累计确认，对按序到达的最后一个分组发送确认，表明到这个分组为止的所有分组都已经正确收到了。

21、谈谈你对滑动窗口的了解？

TCP 利用滑动窗口实现流量控制的机制。滑动窗口（Sliding window）是一种流量控制技术。早期的网络通信中，通信双方不会考虑网络的拥挤情况直接发送数据。由于大家不知道网络拥塞状况，同时发送数据，导致中间节点阻塞掉包，谁也发不了数据，所以就有了滑动窗口机制来解决此问题。

TCP 中采用滑动窗口来进行传输控制，滑动窗口的大小意味着接收方还有多大的缓冲区可以用于接收数据。发送方可以通过滑动窗口的大小来确定应该发送多少字节的数据。当滑动窗口为 0 时，发送方一般不能再发送数据报，但有两种情况除外，一种情况是可以发送紧急数据，例如，允许用户终止在远端机上的运行进程。另一种情况是发送方可以发送一个 1 字节的数据报来通知接收方重新声明它希望接收的下一字节及发送方的滑动窗口大小。

22、谈下你对流量控制的理解？

TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率，保证接收方来得及接收。接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。

23、谈下你对 TCP 拥塞控制的理解？使用了哪些算法？

拥塞控制和流量控制不同，前者是一个全局性的过程，而后者指点对点通信量的控制。在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫拥塞。

拥塞控制就是为了防止过多的数据注入到网络中，这样就可以使网络中的路由器或链路不致于过载。拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有的主机，所有的路由器，以及与降低网络传输性能有关的所有因素。相反，流量控制往往是点对点通信量的控制，是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率，以便使接收端来得及接收。

为了进行拥塞控制，TCP 发送方要维持一个拥塞窗口(cwnd) 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。

TCP 的拥塞控制采用了四种算法，即：慢开始、拥塞避免、快重传和快恢复。在网络层也可以使路由器采用适当的分组丢弃策略（如：主动队列管理 AQM），以减少网络拥塞的发生。在此我向大家推荐一个架构学习交流圈。交流学习指导伪鑫：1253431195（里面有大量的面试题及答案）里面会分享一些资深架构师录制的视频录像：有 Spring，MyBatis，Netty 源码分析，高并发、高性能、分布式、微服务架构的原理，JVM 性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多

慢开始：
慢开始算法的思路是当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么可能会引起网络阻塞，因为现在还不知道网络的符合情况。经验表明，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是由小到大逐渐增大拥塞窗口数值。cwnd 初始值为 1，每经过一个传播轮次，cwnd 加倍。

拥塞避免：
拥塞避免算法的思路是让拥塞窗口 cwnd 缓慢增大，即每经过一个往返时间 RTT 就把发送方的 cwnd 加 1。

快重传与快恢复：
在 TCP/IP 中，快速重传和快恢复（fast retransmit and recovery，FRR）是一种拥塞控制算法，它能快速恢复丢失的数据包。

没有 FRR，如果数据包丢失了，TCP 将会使用定时器来要求传输暂停。在暂停的这段时间内，没有新的或复制的数据包被发送。有了 FRR，如果接收机接收到一个不按顺序的数据段，它会立即给发送机发送一个重复确认。如果发送机接收到三个重复确认，它会假定确认件指出的数据段丢失了，并立即重传这些丢失的数据段。

有了 FRR，就不会因为重传时要求的暂停被耽误。当有单独的数据包丢失时，快速重传和快恢复（FRR）能最有效地工作。当有多个数据信息包在某一段很短的时间内丢失时，它则不能很有效地工作。

24、什么是粘包？

在进行 Java NIO 学习时，可能会发现：如果客户端连续不断的向服务端发送数据包时，服务端接收的数据会出现两个数据包粘在一起的情况。

1. TCP 是基于字节流的，虽然应用层和 TCP 传输层之间的数据交互是大小不等的数据块，但是 TCP 把这些数据块仅仅看成一连串无结构的字节流，没有边界；

2. 从 TCP 的帧结构也可以看出，在 TCP 的首部没有表示数据长度的字段。

基于上面两点，在使用 TCP 传输数据时，才有粘包或者拆包现象发生的可能。一个数据包中包含了发送端发送的两个数据包的信息，这种现象即为粘包。

接收端收到了两个数据包，但是这两个数据包要么是不完整的，要么就是多出来一块，这种情况即发生了拆包和粘包。拆包和粘包的问题导致接收端在处理的时候会非常困难，因为无法区分一个完整的数据包。

25、TCP 黏包是怎么产生的？

发送方产生粘包
采用 TCP 协议传输数据的客户端与服务器经常是保持一个长连接的状态（一次连接发一次数据不存在粘包），双方在连接不断开的情况下，可以一直传输数据。但当发送的数据包过于的小时，那么 TCP 协议默认的会启用 Nagle 算法，将这些较小的数据包进行合并发送（缓冲区数据发送是一个堆压的过程）；这个合并过程就是在发送缓冲区中进行的，也就是说数据发送出来它已经是粘包的状态了。

接收方产生粘包
接收方采用 TCP 协议接收数据时的过程是这样的：数据到接收方，从网络模型的下方传递至传输层，传输层的 TCP 协议处理是将其放置接收缓冲区，然后由应用层来主动获取（C 语言用 recv、read 等函数）；这时会出现一个问题，就是我们在程序中调用的读取数据函数不能及时的把缓冲区中的数据拿出来，而下一个数据又到来并有一部分放入的缓冲区末尾，等我们读取数据时就是一个粘包。（放数据的速度 > 应用层拿数据速度）

26、怎么解决拆包和粘包？

分包机制一般有两个通用的解决方法：

1. 特殊字符控制；

2. 在包头首都添加数据包的长度。

如果使用 netty 的话，就有专门的编码器和解码器解决拆包和粘包问题了。

tips：UDP 没有粘包问题，但是有丢包和乱序。不完整的包是不会有的，收到的都是完全正确的包。传送的数据单位协议是 UDP 报文或用户数据报，发送的时候既不合并，也不拆分。

27、你对 HTTP 状态码有了解吗？

image.png

1XX 信息

1. 100 Continue ：表明到目前为止都很正常，客户端可以继续发送请求或者忽略这个响应。

2XX 成功

1. 200 OK

2. 204 No Content ：请求已经成功处理，但是返回的响应报文不包含实体的主体部分。一般在只需要从客户端往服务器发送信息，而不需要返回数据时使用。

3. 206 Partial Content ：表示客户端进行了范围请求，响应报文包含由 Content-Range 指定范围的实体内容。

3XX 重定向

1. 301 Moved Permanently ：永久性重定向；

2. 302 Found ：临时性重定向；

3. 303 See Other ：和 302 有着相同的功能，但是 303 明确要求客户端应该采用 GET 方法获取资源。

304 Not Modified ：如果请求报文首部包含一些条件，例如：If-Match，If-Modified-Since，If-None-Match，If-Range，If-Unmodified-Since，如果不满足条件，则服务器会返回 304 状态码。 5. 307 Temporary Redirect ：临时重定向，与 302 的含义类似，但是 307 要求浏览器不会把重定向请求的 POST 方法改成 GET 方法。

4XX 客户端错误

1. 400 Bad Request ：请求报文中存在语法错误。

2. 401 Unauthorized ：该状态码表示发送的请求需要有认证信息（BASIC 认证、DIGEST 认证）。如果之前已进行过一次请求，则表示用户认证失败。

3. 403 Forbidden ：请求被拒绝。

4. 404 Not Found

5XX 服务器错误

1. 500 Internal Server Error ：服务器正在执行请求时发生错误；

2. 503 Service Unavailable ：服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。

28、HTTP 状态码 301 和 302 代表的是什么？有什么区别？

301，302 都是 HTTP 状态的编码，都代表着某个 URL 发生了转移。

区别：
301 redirect: 301 代表永久性转移（Permanently Moved）

302 redirect: 302 代表暂时性转移（Temporarily Moved）

29、forward 和 redirect 的区别？

Forward 和 Redirect 代表了两种请求转发方式：直接转发和间接转发。

直接转发方式（Forward）：客户端和浏览器只发出一次请求，Servlet、HTML、JSP 或其它信息资源，由第二个信息资源响应该请求，在请求对象 request 中，保存的对象对于每个信息资源是共享的。

间接转发方式（Redirect）：实际是两次 HTTP 请求，服务器端在响应第一次请求的时候，让浏览器再向另外一个 URL 发出请求，从而达到转发的目的。

举个通俗的例子：
直接转发就相当于：“A 找 B 借钱，B 说没有，B 去找 C 借，借到借不到都会把消息传递给 A”；

间接转发就相当于：“A 找 B 借钱，B 说没有，让 A 去找 C 借”。

30、HTTP 方法有哪些？

客户端发送的 请求报文 第一行为请求行，包含了方法字段。

1. GET：获取资源，当前网络中绝大部分使用的都是 GET；

2. HEAD：获取报文首部，和 GET 方法类似，但是不返回报文实体主体部分；

3. POST：传输实体主体

4. PUT：上传文件，由于自身不带验证机制，任何人都可以上传文件，因此存在安全性问题，一般不使用该方法。

5. PATCH：对资源进行部分修改。PUT 也可以用于修改资源，但是只能完全替代原始资源，PATCH 允许部分修改。

6. OPTIONS：查询指定的 URL 支持的方法；

7. CONNECT：要求在与代理服务器通信时建立隧道。使用 SSL（Secure Sockets Layer，安全套接层）和 TLS（Transport Layer Security，传输层安全）协议把通信内容加密后经网络隧道传输。

TRACE：追踪路径。服务器会将通信路径返回给客户端。发送请求时，在 Max-Forwards 首部字段中填入数值，每经过一个服务器就会减 1，当数值为 0 时就停止传输。通常不会使用 TRACE，并且它容易受到 XST 攻击（Cross-Site Tracing，跨站追踪）。
31、说下 GET 和 POST 的区别？

GET 和 POST 本质都是 HTTP 请求，只不过对它们的作用做了界定和适配，并且让他们适应各自的场景。

本质区别：GET 只是一次 HTTP 请求，POST 先发请求头再发请求体，实际上是两次请求。

1. 从功能上讲，GET 一般用来从服务器上获取资源，POST 一般用来更新服务器上的资源；

2. 从 REST 服务角度上说，GET 是幂等的，即读取同一个资源，总是得到相同的数据，而 POST 不是幂等的，因为每次请求对资源的改变并不是相同的；进一步地，GET 不会改变服务器上的资源，而 POST 会对服务器资源进行改变；

从请求参数形式上看，GET 请求的数据会附在 URL 之后，即将请求数据放置在 HTTP 报文的 请求头 中，以 ? 分割 URL 和传输数据，参数之间以 & 相连。特别地，如果数据是英文字母/数字，原样发送；否则，会将其编码为 application/x-www-form-urlencoded MIME 字符串(如果是空格，转换为+，如果是中文/其他字符，则直接把字符串用 BASE64 加密，得出如：%E4%BD%A0%E5%A5%BD，其中 ％XX 中的 XX 为该符号以 16 进制表示的 ASCII)；而 POST 请求会把提交的数据则放置在是 HTTP 请求报文的 请求体 中； 4. 就安全性而言，POST 的安全性要比 GET 的安全性高，因为 GET 请求提交的数据将明文出现在 URL 上，而且 POST 请求参数则被包装到请求体中，相对更安全；

5. 从请求的大小看，GET 请求的长度受限于浏览器或服务器对 URL 长度的限制，允许发送的数据量比较小，而 POST 请求则是没有大小限制的。

32、在浏览器中输入 URL 地址到显示主页的过程？

DNS 解析：浏览器查询 DNS，获取域名对应的 IP 地址：具体过程包括浏览器搜索自身的 DNS 缓存、搜索操作系统的 DNS 缓存、读取本地的 Host 文件和向本地 DNS 服务器进行查询等。对于向本地 DNS 服务器进行查询，如果要查询的域名包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析(此解析具有权威性)；如果要查询的域名不由本地 DNS 服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个 IP 地址映射，完成域名解析（此解析不具有权威性）。如果本地域名服务器并未缓存该网址映射关系，那么将根据其设置发起递归查询或者迭代查询； 2. TCP 连接：浏览器获得域名对应的 IP 地址以后，浏览器向服务器请求建立链接，发起三次握手；

3. 发送 HTTP 请求：TCP 连接建立起来后，浏览器向服务器发送 HTTP 请求；

4. 服务器处理请求并返回 HTTP 报文：服务器接收到这个请求，并根据路径参数映射到特定的请求处理器进行处理，并将处理结果及相应的视图返回给浏览器；

5. 浏览器解析渲染页面：浏览器解析并渲染视图，若遇到对 js 文件、css 文件及图片等静态资源的引用，则重复上述步骤并向服务器请求这些资源；浏览器根据其请求到的资源、数据渲染页面，最终向用户呈现一个完整的页面。

6. 连接结束。

33、DNS 的解析过程？

主机向本地域名服务器的查询一般都是采用递归查询。所谓递归查询就是：如果主机所询问的本地域名服务器不知道被查询的域名的 IP 地址，那么本地域名服务器就以 DNS 客户的身份，向根域名服务器继续发出查询请求报文(即替主机继续查询)，而不是让主机自己进行下一步查询。因此，递归查询返回的查询结果或者是所要查询的 IP 地址，或者是报错，表示无法查询到所需的 IP 地址。

本地域名服务器向根域名服务器的查询的迭代查询。迭代查询的特点：当根域名服务器收到本地域名服务器发出的迭代查询请求报文时，要么给出所要查询的 IP 地址，要么告诉本地服务器：“你下一步应当向哪一个域名服务器进行查询”。然后让本地服务器进行后续的查询。根域名服务器通常是把自己知道的顶级域名服务器的 IP 地址告诉本地域名服务器，让本地域名服务器再向顶级域名服务器查询。顶级域名服务器在收到本地域名服务器的查询请求后，要么给出所要查询的 IP 地址，要么告诉本地服务器下一步应当向哪一个权限域名服务器进行查询。最后，本地域名服务器得到了所要解析的 IP 地址或报错，然后把这个结果返回给发起查询的主机。

34、谈谈你对域名缓存的了解？

为了提高 DNS 查询效率，并减轻服务器的负荷和减少因特网上的 DNS 查询报文数量，在域名服务器中广泛使用了高速缓存，用来存放最近查询过的域名以及从何处获得域名映射信息的记录。

由于名字到地址的绑定并不经常改变，为保持高速缓存中的内容正确，域名服务器应为每项内容设置计时器并处理超过合理时间的项（例如：每个项目两天）。当域名服务器已从缓存中删去某项信息后又被请求查询该项信息，就必须重新到授权管理该项的域名服务器绑定信息。当权限服务器回答一个查询请求时，在响应中都指明绑定有效存在的时间值。增加此时间值可减少网络开销，而减少此时间值可提高域名解析的正确性。

不仅在本地域名服务器中需要高速缓存，在主机中也需要。许多主机在启动时从本地服务器下载名字和地址的全部数据库，维护存放自己最近使用的域名的高速缓存，并且只在从缓存中找不到名字时才使用域名服务器。维护本地域名服务器数据库的主机应当定期地检查域名服务器以获取新的映射信息，而且主机必须从缓存中删除无效的项。由于域名改动并不频繁，大多数网点不需花精力就能维护数据库的一致性。

35、谈下你对 HTTP 长连接和短连接的理解？分别应用于哪些场景？

在 HTTP/1.0 中默认使用短连接。也就是说，客户端和服务器每进行一次 HTTP 操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个 HTML 或其他类型的 Web 页中包含有其他的 Web 资源（如：JavaScript 文件、图像文件、CSS 文件等），每遇到这样一个 Web 资源，浏览器就会重新建立一个 HTTP 会话。

而从 HTTP/1.1 起，默认使用长连接，用以保持连接特性。使用长连接的 HTTP 协议，会在响应头加入这行代码：

Connection:keep-alive
在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输 HTTP 数据的 TCP 连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。

Keep-Alive 不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如：Apache）中设定这个时间。实现长连接需要客户端和服务端都支持长连接。

36、谈下 HTTP 1.0 和 1.1、1.2 的主要变化？

HTTP1.1 的主要变化：

1. HTTP1.0 经过多年发展，在 1.1 提出了改进。首先是提出了长连接，HTTP 可以在一次 TCP 连接中不断发送请求。

2. 然后 HTTP1.1 支持只发送 header 而不发送 body。原因是先用 header 判断能否成功，再发数据，节约带宽，事实上，post 请求默认就是这样做的。

3. HTTP1.1 的 host 字段。由于虚拟主机可以支持多个域名，所以一般将域名解析后得到 host。

HTTP2.0 的主要变化：

1. HTTP2.0 支持多路复用，同一个连接可以并发处理多个请求，方法是把 HTTP 数据包拆为多个帧，并发有序的发送，根据序号在另一端进行重组，而不需要一个个 HTTP 请求顺序到达；

2. HTTP2.0 支持服务端推送，就是服务端在 HTTP 请求到达后，除了返回数据之外，还推送了额外的内容给客户端；

3. HTTP2.0 压缩了请求头，同时基本单位是二进制帧流，这样的数据占用空间更少；

4. HTTP2.0 适用于 HTTPS 场景，因为其在 HTTP 和 TCP 中间加了一层 SSL 层。

37、HTTPS 的工作过程？

1. 客户端发送自己支持的加密规则给服务器，代表告诉服务器要进行连接了；

2. 服务器从中选出一套加密算法和 hash 算法以及自己的身份信息（地址等）以证书的形式发送给浏览器，证书中包含服务器信息，加密公钥，证书的办法机构；

3. 客户端收到网站的证书之后要做下面的事情：

3.1 验证证书的合法性；
3.2 果验证通过证书，浏览器会生成一串随机数，并用证书中的公钥进行加密；
3.3 用约定好的 hash 算法计算握手消息，然后用生成的密钥进行加密，然后一起发送给服务器。 4. 服务器接收到客户端传送来的信息，要做下面的事情：

4.1 用私钥解析出密码，用密码解析握手消息，验证 hash 值是否和浏览器发来的一致；
4.2 使用密钥加密消息； 5. 如果计算法 hash 值一致，握手成功。

38、HTTP 和 HTTPS 的区别？

1. 开销：HTTPS 协议需要到 CA 申请证书，一般免费证书很少，需要交费；

2. 资源消耗：HTTP 是超文本传输协议，信息是明文传输，HTTPS 则是具有安全性的 ssl 加密传输协议，需要消耗更多的 CPU 和内存资源；

3. 端口不同：HTTP 和 HTTPS 使用的是完全不同的连接方式，用的端口也不一样，前者是 80，后者是 443；

4. 安全性：HTTP 的连接很简单，是无状态的；HTTPS 协议是由 TSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 HTTP 协议安全。在此我向大家推荐一个架构学习交流圈。交流学习指导伪鑫：1253431195（里面有大量的面试题及答案）里面会分享一些资深架构师录制的视频录像：有 Spring，MyBatis，Netty 源码分析，高并发、高性能、分布式、微服务架构的原理，JVM 性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多

39、HTTPS 的优缺点？

优点：

1. 使用 HTTPS 协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；

2. HTTPS 协议是由 SSL + HTTP 协议构建的可进行加密传输、身份认证的网络协议，要比 HTTP 协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性；

3. HTTPS 是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。

缺点：

1. HTTPS 协议握手阶段比较费时，会使页面的加载时间延长近 50%，增加 10% 到 20% 的耗电；

2. HTTPS 连接缓存不如 HTTP 高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响；

3. SSL 证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用；

4. SSL 证书通常需要绑定 IP，不能在同一 IP 上绑定多个域名，IPv4 资源不可能支撑这个消耗；

5. HTTPS 协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的，SSL 证书的信用链体系并不安全，特别是在某些国家可以控制 CA 根证书的情况下，中间人攻击一样可行。

40、什么是数字签名？

为了避免数据在传输过程中被替换，比如黑客修改了你的报文内容，但是你并不知道，所以我们让发送端做一个数字签名，把数据的摘要消息进行一个加密，比如 MD5，得到一个签名，和数据一起发送。然后接收端把数据摘要进行 MD5 加密，如果和签名一样，则说明数据确实是真的。

41、什么是数字证书？

对称加密中，双方使用公钥进行解密。虽然数字签名可以保证数据不被替换，但是数据是由公钥加密的，如果公钥也被替换，则仍然可以伪造数据，因为用户不知道对方提供的公钥其实是假的。所以为了保证发送方的公钥是真的，CA 证书机构会负责颁发一个证书，里面的公钥保证是真的，用户请求服务器时，服务器将证书发给用户，这个证书是经由系统内置证书的备案的。

42、什么是对称加密和非对称加密？

对称密钥加密是指加密和解密使用同一个密钥的方式，这种方式存在的最大问题就是密钥发送问题，即如何安全地将密钥发给对方。

非对称加密指使用一对非对称密钥，即： 公钥和私钥，公钥可以随意发布，但私钥只有自己知道。 发送密文的一方使用对方的公钥进行加密处理，对方接收到加密信息后，使用自己的私钥进行解密。

https://www.zhihu.com/tardis/bd/art/609930973?source_id=1001

1. OSI与TCP/IP 模型

OSI七层：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层

TCP/IP五层：物理层、数据链路层、网络层、传输层、应用层

img

七层网络体系结构各层的主要功能：

• 应用层：为应用程序提供交互服务。在互联网中的应用层协议很多，如域名系统DNS， 支持万维网应用的HTTP协议，支持电子邮件的SMTP协议等。

• 表示层：主要负责数据格式的转换，如加密解密、转换翻译、压缩解压缩等。

• 会话层：负责在网络中的两节点之间建立、维持和终止通信，如服务器验证用户登录便是由会话层完成的。

• 运输层：有时也译为传输层，向主机进程提供通用的数据传输服务。该层主要有以下两种协议:

• • TCP：提供面向连接的、可靠的数据传输服务;
  • UDP：提供无连接的、尽最大努力的数据传输服务，但不保证数据传输的可靠性。

• 网络层：选择合适的路由和交换结点，确保数据及时传送。主要包括IP协议。

• 数据链路层：数据链路层通常简称为链路层。将网络层传下来的IP数据包组装成帧，并再相邻节点的链路上传送帧。

• 物理层：实现相邻节点间比特流的透明传输，尽可能屏蔽传输介质和通信手段的差异。

2. 常见网络服务分层

应用层：HTTP、DNS、FTP、SMTP

传输层：TCP、UDP

网络层：IP、ICMP、路由器、防火墙

数据链路层：网卡、网桥、交换机

物理层：中继器、集线器

3. TCP三次握手

img

三次握手过程：

1. 客户端——发送带有SYN标志的数据包——服务端 一次握手 客户端进入syn_sent状态
2. 服务端——发送带有SYN/ACK标志的数据包——客户端 二次握手 服务端进入syn_rcvd
3. 客户端——发送带有ACK标志的数据包——服务端 三次握手 连接就进入Established状态

为什么三次： 主要是为了建立可靠的通信信道，保证客户端与服务端同时具备发送、接收数据的能力。

为什么两次不行？

1. 防止已失效的请求报文又传送到了服务端，建立了多余的链接，浪费资源。
2. 两次握手只能保证单向连接是畅通的。（为了实现可靠数据传输， TCP协议的通信双方， 都必须维护一个序列号， 以标识发送出去的数据包中， 哪些是已经被对方收到的。三次握手的过程即是通信双方 相互告知序列号起始值， 并确认对方已经收到了序列号起始值的必经步骤；如果只是两次握手， 至多只有连接发起方的起始序列号能被确认， 另一方选择的序列号则得不到确认）。

4. 四次挥手过程：

1. 客户端——发送带有FIN标志的数据包——服务端，关闭与服务端的连接 ，客户端进入FIN-WAIT-1状态
2. 服务端收到这个 FIN，它发回⼀ 个 ACK，确认序号为收到的序号加1，服务端就进入了CLOSE-WAIT状态
3. 服务端——发送⼀个FIN数据包——客户端，关闭与客户端的连接，客户端就进入FIN-WAIT-2状态
4. 客户端收到这个 FIN，发回 ACK报⽂确认，并将确认序号设置为收到序号加1，客户端进入TIME-WAIT状态

img

**为什么四次：**因为需要确保客户端与服务端的数据能够完成传输。

CLOSE-WAIT： 这种状态的含义其实是表示在等待关闭。

TIME-WAIT： 为了解决网络的丢包和网络不稳定所带来的其他问题，确保连接方能在时间范围内，关闭自己的连接。

5. 为什么连接的时候是三次握手，关闭的时候却是四次握手?

服务器在收到客户端的FIN报文段后，可能还有一些数据要传输，所以不能马上关闭连接，但是会做出应答，返回ACK报文段。

接下来可能会继续发送数据，在数据发送完后，服务器会向客户端发送FIN报文，表示数据已经发送完毕，请求关闭连接。服务器的ACK和FIN一般都会分开发送，从而导致多了一次，因此一共需要四次挥手。

6. 如何查看TIME-WAIT状态的链接数量？

netstat -an | grep TIME_WAIT | wc -l  //查看连接数等待time_wait状态连接数

7. 为什么会TIME-WAIT过多？解决方法是怎样的？

**可能原因：**高并发短连接的TCP服务器上，当服务器处理完请求后立刻按照主动正常关闭连接

**解决：**负载均衡服务器；Web服务器首先关闭来自负载均衡服务器的连接

8. 半连接，洪泛攻击问题以及如何解决（syn_cookie）

在三次握手的过程中，服务器为了响应一个受到的SYN报文段，会分配并初始化连接变量和缓存，然后服务器发送一个SYN/ACK报文段进行响应，并等待客户端的ACK报文段。**如果客户不发送ACK来完成该三次握手的第三步，最终(通常在一分多钟之后)服务器将终止该半开连接并回收资源。这种TCP连接管理协议的特性就会有这样一个漏洞，攻击者发送大量的TCP SYN报文段，而不完成第三次握手的步骤。**随着这种SYN报文段的不断到来，服务器不断为这些半开连接分配资源，从而导致服务器连接资源被消耗殆尽。这种攻击就是SYN泛供攻击。

为了应对这种攻击，现在有一种有效的防御系统，称为SYN cookie。SYN cookie的工作方式如下：

1. 当服务器接收到一个SYN报文段时，它并不知道该报文段是来自一个合法的用户，还是这种SYN洪泛攻击的一部分。因为服务器不会为该报文段生成一个半开的连接。相反，服务器生成一个初始TCP序列号，该序列号是SYN报文段的源IP地址和目的IP地址，源端口号和目的端口号以及仅有服务器知道的秘密数的复杂函数(散列函数)。这种精心制作的初始序列号称为为“cookie”。服务器则发送具有这种特殊初始序号的SYN/ACK报文分组。服务器并不记忆该cookie或任何对应于SYN的其他状态信息。
2. 如果该客户是合法的，则它将返回一个ACK报文段。当服务器收到该ACK报文段，需要验证该ACK是与前面发送的某个SYN相对应。由于服务器并不维护有关SYN报文段的记忆，所以服务器通过使用SYN/ACK报文段中的源和目的IP地址与端口号以及秘密数运行相同的散列函数。如果这个函数的结果(cookie值)加1和在客户的ACK报文段中的确认值相同的话，那么服务器就会认为该ACK对应于较早的SYN报文段，因此它是合法的。服务器则会生成一个套接字的全开连接。
3. 另一方面，如果客户没有返回一个ACK报文段，说明之前的SYN报文段是洪泛攻击的一部分，但是它并没有对服务器产生危害，因为服务器没有为它分配任何资源。

9. 为什么客户端的TIME-WAIT状态必须等待2MSL ?

主要有两个原因:

1. **为了保证客户端发送的最后一个ACK报文段能够达到服务器。**这个ACK报文段可能丢失，因而使处在LAST-ACK状态的服务器收不到确认。服务器会超时重传FIN+ACK报文段，客户端就能在2MSL时间内收到这个重传的FIN+ACK报文段，接着客户端重传一次确认，重启计时器。最好，客户端和服务器都正常进入到CLOSED状态。如果客户端在TIME-WAIT状态不等待一段时间，而是再发送完ACK报文后立即释放连接，那么就无法收到服务器重传的FIN+ACK报文段，因而也不会再发送一次确认报文。这样，服务器就无法按照正常步骤进入CLOSED状态。
2. **防止已失效的连接请求报文段出现在本连接中。**客户端在发送完最后一个ACK确认报文段后，再经过时间2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。

10. 4g切换wifi会发生什么

当移动设备的网络从4G切换到WiFi时，意味着IP地址变化了，那么必须要断开连接，然后重新连接，而建立连接的过程包含TCP三次握手和TLS四次挥手的时延，以及TCP慢启动的减速过程，给用户的感觉就是突然网络卡顿了一下，所以说，迁移的成本是很高的。

http3是怎么解决连接迁移

HTTP3中QUIC协议没有用四元组的方式来"绑定”连接，而是通过连接ID来标记通信的两个端点，客户端和服务器可以各自选择一组ID来标记自己，因此即使移动设备的网络变化后，导致IP地址变化了，只要仍保有上下文信息(比如连接ID、TLS 密钥等)，就可以"无缝"地复用原连接，消除重连的成本，没有丝毫卡顿感，达到了连接迁移的功能。

11. TCP与UDP区别及场景

类型	特点	性能	应用过场景	首部字节
TCP	面向连接、可靠、字节流	传输效率慢、所需资源多	文件、邮件传输	20-60
UDP	无连接、不可靠、数据报文段	传输效率快、所需资源少	语音、视频、直播	8个字节

基于TCP的协议：HTTP、FTP、SMTP

基于UDP的协议： RIP、DNS、SNMP

12. TCP滑动窗口，拥塞控制

**TCP通过：**应用数据分割、对数据包进行编号、校验和、流量控制、拥塞控制、超时重传等措施保证数据的可靠传输。

**拥塞控制目的：**为了防止过多的数据注入到网络中，避免网络中的路由器、链路过载。

**拥塞控制过程：**TCP维护一个拥塞窗口，该窗口随着网络拥塞程度动态变化，通过慢开始、拥塞避免等算法减少网络拥塞的发生。

13. TCP粘包原因和解决方法

TCP粘包是指：发送方发送的若干包数据到接收方接收时粘成一包

发送方原因：

TCP默认使用Nagle算法（主要作用：减少网络中报文段的数量）：

收集多个小分组，在一个确认到来时一起发送、导致发送方可能会出现粘包问题

接收方原因：

TCP将接收到的数据包保存在接收缓存里，如果TCP接收数据包到缓存的速度大于应用程序从缓存中读取数据包的速度，多个包就会被缓存，应用程序就有可能读取到多个首尾相接粘到一起的包。

• 传输层的UDP协议不会发生粘包或者拆包问题
  UDP是基于报文发送的，在UDP首部采用了16bit来指示UDP数据报文的长度，因此在应用层能很好的将不同的数据报文区分开，从而避免粘包和拆包的问题。
• 传输层的TCP协议会发生粘包或者拆包问题
  原因有以下两点：

1. TCP是基于字节流的，虽然应用层和传输层之间的数据交互是大小不等的数据块，但是TCP把这些数据块仅仅看成一连串无结构的字节流，没有边界；
2. 在TCP的首部没有表示数据长度的字段，基于上面两点，在使用TCP传输数据时，才有粘包或者拆包现象发生的可能。

**解决粘包问题：**解决问题的关键在于如何给每个数据包添加边界信息

最本质原因在与接收对等方无法分辨消息与消息之间的边界在哪，通过使用某种方案给出边界，例如：

• 发送定长包。每个消息的大小都是一样的，接收方只要累计接收数据，直到数据等于一个定长的数值就将它作为一个消息。
• 包尾加上\r\n标记。FTP协议正是这么做的。但问题在于如果数据正文中也含有\r\n，则会误判为消息的边界。
• 包头加上包体长度。包头是定长的4个字节，说明了包体的长度。接收对等方先接收包体长度，依据包体长度来接收包体。

14. TCP、UDP报文格式

TCP报文格式：

img

源端口号和目的端口号：

用于寻找发端和收端应用进程。这两个值加上IP首部源端IP地址和目的端IP地址唯一确定一个TCP连接。

序号字段：

序号用来标识从TCP发端向TCP收端发送的数据字节流，它表示在这个报文段中的的第一个数据字节。如果将字节流看作在两个应用程序间的单向流动，则 TCP用序号对每个字节进行计数。序号是32 bit的无符号数，序号到达 2^32-1后又从0开始。

当建立一个新的连接时，SYN标志变1。序号字段包含由这个主机选择的该连接的初始序号ISN（Initial Sequence Number）。该主机要发送数据的第一个字节序号为这个ISN加1，因为SYN标志消耗了一个序号

确认序号：

既然每个传输的字节都被计数，确认序号包含发送确认的一端所期望收到的下一个序号。因此，确认序号应当是上次已成功收到数据字节序号加 1。只有ACK标志为 1时确认序号字段才有效。发送ACK无需任何代价，因为 32 bit的确认序号字段和A C K标志一样，总是TCP首部的一部分。因此，我们看到一旦一个连接建立起来，这个字段总是被设置， ACK标志也总是被设置为1。TCP为应用层提供全双工服务。这意味数据能在两个方向上独立地进行传输。因此，连接的每一端必须保持每个方向上的传输数据序号。

首都长度：

首部长度给出首部中 32 bit字的数目。需要这个值是因为任选字段的长度是可变的。这个字段占4 bit，因此TCP最多有6 0字节的首部。然而，没有任选字段，正常的长度是 20字节。

标志字段：在TCP首部中有 6个标志比特，它们中的多个可同时被设置为1。

• URG紧急指针（u rgent pointer）有效
• ACK确认序号有效。
• PSH接收方应该尽快将这个报文段交给应用层。
• RST重建连接。
• SYN同步序号用来发起一个连接。这个标志和下一个标志将在第 1 8章介绍。
• FIN发端完成发送任务。

窗口大小：

TCP的流量控制由连接的每一端通过声明的窗口大小来提供。窗口大小为字节数，起始于确认序号字段指明的值，这个值是接收端期望接收的字节。窗口大小是一个 16 bit字段，因而窗口大小最大为 65535字节。

检验和：

检验和覆盖了整个的 TCP报文段：TCP首部和TCP数据。这是一个强制性的字段，一定是由发端计算和存储，并由收端进行验证。

紧急指针：

只有当URG标志置1时紧急指针才有效。紧急指针是一个正的偏移量，和序号字段中的值相加表示紧急数据最后一个字节的序号。TCP的紧急方式是发送端向另一端发送紧急数据的一种方式。

选项：

最常见的可选字段是最长报文大小，又称为 MSS(Maximum Segment Size)。每个连接方通常都在通信的第一个报文段（为建立连接而设置 SYN标志的那个段）中指明这个选项。它指明本端所能接收的最大长度的报文段。

UDP报文格式：

img

端口号：

用来表示发送和接受进程。由于 IP层已经把I P数据报分配给TCP或 UDP（根据I P首部中协议字段值），因此TCP端口号由TCP来查看，而 UDP端口号由 UDP来查看。TCP端口号与 UDP端口号是相互独立的。

长度：

UDP长度字段指的是 UDP首部和 UDP数据的字节长度。该字段的最小值为 8字节（发送一份0字节的 UDP数据报是 O K）。

检验和：

UDP检验和是一个端到端的检验和。它由发送端计算，然后由接收端验证。其目的是为了发现 UDP首部和数据在发送端到接收端之间发生的任何改动。

**IP报文格式：**普通的IP首部长为20个字节，除非含有可选项字段。

img

4位版本：目前协议版本号是4，因此IP有时也称作IPV4.

4位首部长度：

首部长度指的是首部占32bit字的数目，包括任何选项。由于它是一个4比特字段，因此首部长度最长为60个字节。

服务类型（TOS）：

服务类型字段包括一个3bit的优先权字段（现在已经被忽略），4bit的TOS子字段和1bit未用位必须置0。4bit的TOS分别代表：最小时延，最大吞吐量，最高可靠性和最小费用。4bit中只能置其中1比特。如果所有4bit均为0，那么就意味着是一般服务。

总长度：

总长度字段是指整个IP数据报的长度，以字节为单位。利用首部长度和总长度字段，就可以知道IP数据报中数据内容的起始位置和长度。由于该字段长16bit，所以IP数据报最长可达65535字节。当数据报被分片时，该字段的值也随着变化。

标识字段：

标识字段唯一地标识主机发送的每一份数据报。通常每发送一份报文它的值就会加1。

生存时间：

TTL（time-to-live）生存时间字段设置了数据报可以经过的最多路由器数。它指定了数据报的生存时间。TTL的初始值由源主机设置（通常为 3 2或6 4），一旦经过一个处理它的路由器，它的值就减去 1。当该字段的值为 0时，数据报就被丢弃，并发送 ICMP报文通知源主机。

首部检验和：

首部检验和字段是根据 I P首部计算的检验和码。它不对首部后面的数据进行计算。ICMP、IGMP、UDP和TCP在它们各自的首部中均含有同时覆盖首部和数据检验和码。

以太网报文格式：

img

目的地址和源地址： 是指网卡的硬件地址（也叫MAC 地址），长度是48 位，是在网卡出厂时固化的。

数据：

以太网帧中的数据长度规定最小46 字节，最大1500 字节，ARP和RARP数据包的长度不够46 字节，要在后面补填充位。最大值1500 称为以太网的最大传输单元（MTU），不同的网络类型有不同的MTU，如果一个数据包从以太网路由到拨号链路上，数据包度大于拨号链路的MTU了，则需要对数据包进行分片fragmentation）。ifconfig命令的输出中也有“MTU:1500”。注意，MTU个概念指数据帧中有效载荷的最大长度，不包括帧首部的长度。

15. TCP协议如何保证可靠传输机制？

TCP主要提供了检验和、序列号/确认应答、超时重传、滑动窗口、拥塞控制和流量控制等方法实现了可靠性传输。

• **检验和：**通过检验和的方式，接收端可以检测出来数据是否有差错和异常，假如有差错就会直接丢弃TCP段，重新发送。
• **序列号/确认应答：**序列号的作用不仅仅是应答的作用，有了序列号能够将接收到的数据根据序列号排序，并且去掉重复序列号的数据。TCP传输的过程中，每次接收方收到数据后，都会对传输方进行确认应答。也就是发送ACK报文,这个ACK报文当中带有对应的确认序列号，告诉发送方，接收到了哪些数据，下一次的数据从哪里发。
• 超时重传： 超时重传是指发送出去的数据包到接收到确认包之间的时间，如果超过了这个时间会被认为是丢包了，需要重传。最大超时时间是动态计算的。
• 滑动窗口： 滑动窗口既提高了报文传输的效率，也避免了发送方发送过多的数据而导致接收方无法正常处理的异常。
• 拥塞控制： 在数据传输过程中，可能由于网络状态的问题，造成网络拥堵，此时引入拥塞控制机制，在保证TCP可靠性的同时，提高性能。
• 流量控制： 如果主机A一直向主机B发送数据，不考虑主机B的接受能力，则可能导致主机B的接受缓冲区满了而无法再接受数据，从而会导致大量的数据丢包，引发重传机制。而在重传的过程中，若主机B的接收缓冲区情况仍未好转，则会将大量的时间浪费在重传数据上，降低传送数据的效率。所以引入流量控制机制，主机B通过告诉主机A自己接收缓冲区的大小，来使主机A控制发送的数据量。流量控制与TCP协议报头中的窗口大小有关。

16. TCP的滑动窗口?

在进行数据传输时，如果传输的数据比较大，就需要拆分为多个数据包进行发送。TCP协议需要对数据进行确认后，才可以发送下一个数据包。这样一来，就会在等待确认应答包环节浪费时间。为了避免这种情况，TCP引入了窗口概念。窗口大小指的是不需要等待确认应答包而可以继续发送数据包的最大值。

img

从上面的图可以看到滑动窗口左边的是已发送并且被确认的分组，滑动窗口右边是还没有轮到的分组。

滑动窗口里面也分为两块，一块是已经发送但是未被确认的分组，另一块是窗口内等待发送的分组。随着已发送的分组不断被确认，窗口内等待发送的分组也会不断被发送。整个窗口就会往右移动，让还没轮到的分组进入窗口内。

可以看到滑动窗口起到了一个限流的作用，也就是说当前滑动窗口的大小决定了当前TCP发送包的速率，而滑动窗口的大小取决于拥塞控制窗口和流量控制窗口的两者间的最小值。

17. 详细讲一下拥塞控制? 为何要进行拥塞控制？

A在给B传输数据, A却没有收到B反馈的TCP,A就认为B发送的数据包丢失了..进而会重新传输这个丢失的数据包。然而实际情况有可能此时有太多主机正在使用信道资源，导致网络拥塞了。重传数据浪费了资源，所以要进行拥塞控制。发送发不知道一次发多少数据合适，所以设置一个拥塞窗口。

TCP拥塞控制原理是通过：慢启动、拥塞避免、快重传、快启动

发送方维持一个叫做拥塞窗口cwnd (congestion window)的状态变量。当cwndssthresh时， 改用拥塞避免算法。

• 慢开始: 不要一开始就发送大量的数据，由小到大逐渐增加拥塞窗口的大小。
• 拥塞避免: 拥塞避免算法让拥塞窗口缓慢增长，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1而不是加倍。这样拥塞窗口按线性规律缓慢增长。
• 快重传: 我们可以剔除一些不必要的拥塞报文，提高网络吞吐量。比如接收方在收到一个失序的报文段后就立即发出重复确认，而不要等到自己发送数据时捎带确认。快重传规定:发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。
• 快恢复: 主要是配合快重传。当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh门限减半(为了预防网络发生拥塞)，但接下来并不执行慢开始算法，因为如果网络出现拥塞的话就不会收到好几个重复的确认，收到三个重复确认说明网络状况还可以。

18. TCP拥塞控制4种算法

• 基于丢包的拥塞控制：将丢包视为出现拥塞，采取缓慢探测的方式，逐渐增大拥塞窗口，当出现丢包时，将拥塞窗口减小，如Reno、Cubic等。
• 基于时延的拥塞控制：将时延增加视为出现拥塞，延时增加时增大拥塞窗口，延时减小时减小拥塞窗口，如Vegas、FastTCP等。
• 基于链路容量的拥塞控制：实时测量网络带宽和时延，认为网络上报文总量大于带宽时延乘积时出现了拥塞，如BBR。
• 基于学习的拥塞控制：没有特定的拥塞信号，而是借助评价函数，基于训练数据，使用机器学习的方法形成一个控制策略，如Remy。

HTTP协议

1. HTTP协议1.0 1.1 2.0

**HTTP1.0：**服务器处理完成后立即断开TCP连接（无连接），服务器不跟踪每个客户端也不记录过去的请求（无状态）

HTTP1.1： KeepAlived 长连接避免了连接建立和释放的开销；通过Content-Length来判断当前请求数据是否已经全部接受（有状态）

HTTP2.0：引入二进制数据帧和流的概念，其中帧对数据进行顺序标识；因为有了序列，服务器可以并行的传输数据。

无状态的好坏

• 无状态的好处，因为服务器不会去记忆 HTTP的状态，所以不需要额外的资源来记录状态信息，这能减 轻服务器的负担，能够把更多的 CPU和内存用来对外提供服务。
• 无状态的坏处，既然服务器没有记忆能力，这样每操作一次，都要验证信息。例如登录->添加购物车->下单->结算->支付，这系列操作都要知道用户的身份才行。但服务器不知道这些请求是有关联的，每次都要问一遍身份信息。

解决无状态的问题，解法方案有很多种，其中比较简单的方式用 Cookie和Session技术。

2. HTTP1.0和HTTP1.1的主要区别如下：

1. 缓存处理：1.1添加更多的缓存控制策略（如：Entity tag，If-Match）
2. 网络连接的优化：1.1支持断点续传
3. 错误状态码的增多：1.1新增了24个错误状态响应码，丰富的错误码更加明确各个状态
4. Host头处理：支持Host头域，不在以IP为请求方标志
5. 长连接：减少了建立和关闭连接的消耗和延迟。

3. HTTP1.1和HTTP2.0的主要区别：

1. 新的传输格式：2.0使用二进制格式，1.0依然使用基于文本格式
2. 多路复用：连接共享，不同的request可以使用同一个连接传输（最后根据每个request上的id号组合成正常的请求）
3. header压缩：由于1.X中header带有大量的信息，并且得重复传输，2.0使用encoder来减少需要传输的hearder大小
4. 服务端推送：同google的SPDUY（1.0的一种升级）一样

4. HTTP和 HTTPS的区别：

1. 最重要的区别就是安全性，HTTP明文传输，不对数据进行加密安全性较差。HTTPS(HTTP + SSL / TLS)的数据传输过程是加密的，安全性较好。
2. 证书：使用 HTTPS协议需要申请 CA证书，一般免费证书较少，因而需要一定费用。证书颁发机构如：Symantec、Comodo、DigiCert和 GlobalSign等。
3. 响应速度：HTTP页面响应速度比 HTTPS快，这个很好理解，由于加了一层安全层，建立连接的过程更复杂，也要交换更多的数据，难免影响速度。
4. 加密：HTTP协议运行在TCP（三次握手）之上，所有传输的内容都是明文，HTTPS运行在SSL/TLS之上，SSL/TLS运行在TCP之上，所有传输的内容都经过加密的。
5. 端口不同：HTTPS和 HTTP使用的是完全不同的连接方式，用的端口也不一样，前者是 443，后者是 80。

HTTP	HTTPS
默认端口80	默认端口443
明文传输、数据未加密、安全性较差	传输协议ssl加密、安全性较好
响应速度快，消耗资源少	响应速度慢、消耗资源多，需要用到CA证书

5. HTTPS 的缺点：

1. 在相同网络环境中，HTTPS相比 HTTP无论是响应时间还是耗电量都有大幅度上升。
2. HTTPS的安全是有范围的，在黑客攻击、服务器劫持等情况下几乎起不到作用。
3. 在现有的证书机制下，中间人攻击依然有可能发生。
4. HTTPS需要更多的服务器资源，也会导致成本的升高。

6. HTTPS链接建立的过程：

1. 首先客户端先给服务器发送一个请求
2. 服务器发送一个SSL证书给客户端，内容包括：证书的发布机构、有效期、所有者、签名以及公钥
3. 客户端对发来的公钥进行真伪校验，校验为真则使用公钥对对称加密算法以及对称密钥进行加密
4. 服务器端使用私钥进行解密并使用对称密钥加密确认信息发送给客户端
5. 随后客户端和服务端就使用对称密钥进行信息传输

img

加密流程按图中的序号分为:

1. 客户端请求HTTPS网址，然后连接到server的443端口(HTTPS默认端口，类似于HTTP的80端口)。
2. 采用HTTPS协议的服务器必须要有一套数字CA(Certification Authority)证书。颁发证书的同时会产生一个私钥和公钥。私钥由服务端自己保存，不可泄漏。公钥则是附带在证书的信息中，可以公开的。证书本身也附带-一个证书电子签名，这个签名用来验证证书的完整性和真实性，可以防止证书被篡改。
3. 服务器响应客户端请求，将证书传递给客户端，证书包含公钥和大量其他信息，比如证书颁发机构信息，公司信息和证书有效期等。
4. 客户端解析证书并对其进行验证。如果证书不是可信机构颁布，或者证书中的域名与实际域名不一致，或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。如果证书没有问题，客户端就会从服务器证书中取出服务器的公钥A。然后客户端还会生成一一个随机码KEY,并使用公钥A将其加密。
5. 客户端把加密后的随机码KEY发送给服务器，作为后面对称加密的密钥。
6. 服务器在收到随机码KEY之后会使用私钥B将其解密。经过以上这些步骤，客户端和服务器终于建立了安全连接，完美解决了对称加密的密钥泄露问题，接下来就可以用对称加密愉快地进行通信了。
7. 服务器使用密钥(随机码KEY)对数据进行对称加密并发送给客户端，客户端使用相同的密钥(随机码KEY)解密数据。
8. 双方使用对称加密愉快地传输所有数据。

7. HTTP常见响应状态码

100：Continue 一一 继续。客户端应继续其请求。

200：OK 一一 请求成功。一 般用于GET与POST请求。

301：Moved Permanently 一一 永久重定向。

302：Found 一一 暂时重定向。

400：Bad Request 一一 客户端请求的语法错误，服务器无法理解。请求没有包含host头

403：Forbideen 一一 服务器理解请求客户端的请求，但是拒绝执行此请求。禁止客户访问该资源

404：Not Found 一一 服务器无法根据客户端的请求找到资源（网页）。资源未找到

500：Internal Server Error 一一 服务器内部错误，无法完成请求。

502：Bad Gateway 一一 作为网关或者代理服务器尝试执行请求时，从远程服务器接收到了无效的响应。

8. 状态码301和302的区别是什么?

301为永久重定向，302为临时重定向

共同点: 301和302状态码都表示重定向，就是说浏览器在拿到服务器返回的这个状态码后会自动跳转到一个新的URL地址，这个地址可以从响应的Location首部中获取(用户看到的效果就是他输入的地址A瞬间变成了另一个地址B)。

不同点: 301表示旧地址A的资源已经被永久地移除了(这个资源不可访问了)，搜索引擎在抓取新内容的同时也将旧的网址交换为重定向之后的网址;302表示旧地址A的资源还在(仍然可以访问)，这个重定向只是临时地从旧地址A跳转到地址B，搜索引擎会抓取新的内容而保存旧的网址。SEO中302好于301。

补充，重定向原因:

1. 网站调整(如改变网页目录结构);
2. 网页被移到一个新地址;
3. 网页扩展名改变(如应用需要把.php改成.Html或.shtml)。

9. 对称加密算法与非对称加密算法的区别

对称加密算法：

双方持有相同的密钥，且加密速度快，典型对称加密算法：DES、AES

非对称加密算法：

密钥成对出现（私钥、公钥），私钥只有自己知道，不在网络中传输；而公钥可以公开。相比对称加密速度较慢，典型的非对称加密算法有：AES、DSA

10. HTTP请求方法：

方法	描述
GET	像特定资源发送请求，查询数据，并返回实体
POST	向指定资源提交数据进行处理，可能会导致新的资源建立、已有的资源修改
PUT	向服务器上传新的内容
HEAD	类似GET请求，返回的响应式中没有具体内容，用于获取报头
DELETE	请求服务器删除指定标识的资源
OPTIONS	可以原来向服务器发送请求来测试服务器的功能性
TRACE	回显服务器收到的请求，用于测试和诊断
CONNECT	HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器

11. Get和Post请求区别

	GET	POST
HTTP规范	GET用于信息获取	修改服务器上的资源的请求
可见性	数据在URL中对所有人可见	数据不会显示在URL中
安全性	与post相比，get的安全性较差，因为所发送的数据是URL的一部分	安全，因为参数不会被保存在浏览器历史或web服务器日志中
数据长度	受限制，最长2kb	无限制
编码类型	application/x-www-form-urlencoded	multipart/form-data
缓存	能被缓存	不能被缓存

12. GET 和 POST 方法都是安全和幂等的吗？

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

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

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

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

13. 重定向和转发区别

转发是服务器行为,重定向是客户端行为

重定向：redirect：

地址栏发生变化

重定向可以访问其他站点（服务器）的资源

重定向是两次请求。不能使用request对象来共享数据

转发：forward：

转发地址栏路径不变

转发只能访问当前服务器下的资源

转发是一次请求，可以使用request对象共享数据

14. Cookie和Session区别

Cookie 和 Session都是用来跟踪浏览器用户身份的会话方式，但两者有所区别：

Cookie数据保存在客户端(浏览器端)，Session数据保存在服务器端。

cookie不是很安全，别人可以分析存放在本地的Cookie并进行欺骗,考虑到安全应当使用session。

Cookie⼀般⽤来保存⽤户信息，Session的主要作⽤就是通过服务端记录⽤户的状态

15. 浏览器输入URL过程

过程：DNS解析、TCP连接、发送HTTP请求、服务器处理请求并返回HTTP报文、浏览器渲染、结束

1. 域名解析(域名www.baidu.com变为IP地址)。浏览器搜索自己的DNS缓存(维护一张域名与IP的对应表);

2. 1. 若没有，则搜索操作系统的DNS缓存(维护一张域名与IP的对应表) ;
   2. 若没有，则搜索操作系统的hosts文件(维护一张域名与IP的对应表)。
   3. 若都没有，则找TCP/IP参数中设置的首选dns服务器，即本地DNS服务器(递归查询)，本地域名服务器查询自己的DNS缓存，如果没有，则进行迭代查询。将本地dns服务器将IP返回给操作系统，同时缓存IP。

3. 发起TCP的三次握手，建立TCP连接。浏览器会以一个随机端口(1024-65535) 向服务端的web程序80端口发起TCP的连接。

4. 建立TCP连接后发起HTTP请求。

5. 服务器响应HTTP请求，客户端得到html代码。服务器web应用程序收到HTTP请求后，就开始处理请求，处理之后就返回给浏览器html文件。

6. 浏览器解析html代码，并请求html中的资源。

7. 浏览器对页面进行渲染，并呈现给用户。

---

如何查看 TCP 的连接状态？TCP 的连接状态查看，在 Linux 可以通过 netstat -napt 命令查看。

img

16. DNS协议是TCP还是UDP?

img

• DNS占用53号端口，同时使用TCP和UDP协议。那么DNS在什么情况下使用这两种协议？
  DNS在区域传输的时候使用TCP协议，其他时候使用UDP协议。

• • 客户端向DNS服务器查询域名，一般返回的内容都不超过512字节，用UDP传输即可。不用经过TCP三次握手，这样DNS服务器负载更低，响应更快。虽然从理论上说，客户端也可以指定向DNS服务器查询的时候使用TCP，但事实上，很多DNS服务器进行配置的时候，仅支持UDP查询包。
  • 辅域名服务器会定时（一般3小时）向主域名服务器进行查询以便了解数据是否有变动。如有变动，会执行一次区域传送，进行数据同步。区域传送使用TCP而不是UDP，因为数据同步传送的数据量比一个请求应答的数据量要多得多。
  • TCP是一种可靠连接，保证了数据的准确性。
  • DNS区域传输的时候使用TCP协议：
  • 域名解析时使用UDP协议：

img

img

17. ARP协议如何找到对应IP地址和mac的映射的

简单地说，ARP 是借助 ARP 请求与 ARP 响应两种类型的包确定 MAC 地址的。

• 主机会通过广播发送 ARP 请求，这个包中包含了想要知道的 MAC 地址的主机 IP 地址。
• 当同个链路中的所有设备收到 ARP 请求时，会去拆开 ARP 请求包里的内容，如果 ARP 请求包中 的目标 IP 地址与自己的 IP 地址一致，那么这个设备就将自己的 MAC 地址塞入 ARP 响应包返回 给主机。

操作系统通常会把第一次通过 ARP 获取的 MAC 地址缓存起来，以便下次直接从缓存中找到对应 IP 地 址的 MAC 地址。不过， MAC 地址的缓存是有一定期限的，超过这个期限，缓存的内容将被清除

img

18. RARP 协议你知道是什么吗？

ARP 协议是已知 IP 地址求 MAC 地址，那 RARP 协议正好相反，它是已知 MAC地址求 IP 地址。例如 将打印机服务器等小型嵌入式设备接入到网络时就经常会用得到。

通常这需要架设一台 RARP 服务器，在这个服务器上注册设备的 MAC 地址及其 IP 地址。然后再将 这个设备接入到网络，接着：

• 该设备会发送一条「我的 MAC 地址是XXXX，请告诉我，我的IP地址应该是什么」的请求信息。
• RARP 服务器接到这个消息后返回「 MAC地址为 XXXX 的设备，IP地址为 XXXX」的信息给这个 设备。

最后，设备就根据从 RARP 服务器所收到的应答信息设置自己的 IP 地址

img

19. 什么是DDos攻击?

DDos全称Distributed Denial of Service，分布式拒绝服务攻击。最基本的DOS攻击过程如下:

1. 客户端向服务端发送请求链接数据包。
2. 服务端向客户端发送确认数据包。
3. 客户端不向服务端发送确认数据包，服务器一直等待来自客户端的确认

DDos则是采用分布式的方法，通过在网络上占领多台“肉鸡”，用多台计算机发起攻击。

DDos攻击现在基本没啥作用了，因为服务器的性能都很好，而且是多台服务器共同作用，1V1的模式黑客无法占上风。对于DDos攻击，预防方法有:

• 减少SYN timeout时间。在握手的第三步，服务器会等待30秒-120秒的时间，减少这个等待时间就能释放更多的资源。
• 限制同时打开的SYN半连接数目。

20. 什么是XSS攻击?

XSS也称cross-sitescripting,跨站脚本。这种攻击是由于服务器将攻击者存储的数据原原本本地显示给其他用户所致的。比如一个存在XSS漏洞的论坛，用户发帖时就可以引入带有< script>标签的代码，导致恶意代码的执行。

预防措施有:

• 前端：过滤。
• 后端：转义，比如go自带的处理器就具有转义功能。

21. SQL注入是什么，如何避免SQL注入?

SQL注入就是在用户输入的字符串中加入SQL语句，如果在设计不良的程序中忽略了检查，那么这些注入进去的SQL语句就会被数据库服务器误认为是正常的SQL语句而运行，攻击者就可以执行计划外的命令或访问未被授权的数据。

SQL注入的原理主要有以下4点：

1. 恶意拼接查询
2. 利用注释执行非法命令
3. 传入非法参数
4. 添加额外条件

避免SQL注入的一些方法：

1. 参数校验：在一些不该有特殊字符的参数中提前进行特殊字符校验即可。
2. 限制数据库权限，给用户提供仅仅能够满足其工作的最低权限。
3. 提供参数化查询接口，不要直接使用原生SQL。
4. SQL预编译

在知道了SQL注入的原理之后，我们同样也了解到MySQL有预编译的功能，指的是在服务器启动时，MySQL Client把SQL语句的模板（变量采用占位符进行占位）发送给MySQL服务器，MySQL服务器对SQL语句的模板进行编译，编译之后根据语句的优化分析对相应的索引进行优化，在最终绑定参数时把相应的参数传送给MySQL服务器，直接进行执行，节省了SQL查询时间，以及MySQL服务器的资源，达到一次编译、多次执行的目的，除此之外，还可以防止SQL注入。

具体是怎样防止SQL注入的呢？实际上当将绑定的参数传到MySQL服务器，MySQL服务器对参数进行编译，即填充到相应的占位符的过程中，做了转义操作。我们常用的JDBC就有预编译功能，不仅提升性能，而且防止SQL注入。

22. 网络编程socket，客户端和服务端通信过程，分别调用了哪些函数，作用是什么

• 服务器端程序：

1. 创建一个socket，用函数socket()
2. 绑定IP地址、端口等信息到socket上，用函数bind()
3. 设置允许的最大连接数，用函数listen()
4. 接收客户端上来的连接，用函数accept()
5. 收发数据，用函数send()和recv()，或者read()和write()
6. 关闭网络连接

• 客户端程序：

1. 创建一个socket，用函数socket()
2. 设置要连接的对方的IP地址和端口等属性
3. 连接服务器，用函数connect()
4. 收发数据，用函数send()和recv()，或read()和write()
5. 关闭网络连接

23. 负载均衡算法有哪些?

nginx负载均衡的三种方式主要是轮询模式、weight权重模式、ip_hash。

当一台服务器的单位时间内的访问量越大时，服务器压力就越大，大到超过自身承受能力时，服务器就会崩溃。为了避免服务器崩溃，让用户有更好的体验，我们通过负载均衡的方式来分担服务器压力。

1. **轮询模式（默认）**每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。适合服务器配置相当，无状态且短平快的服务使用。也适用于图片服务器集群和纯静态页面服务器集群。
2. weight权重模式这种方式比较灵活，当后端服务器性能存在差异的时候，通过配置权重，可以让服务器的性能得到充分发挥，有效利用资源。weight和访问比率成正比，用于后端服务器性能不均的情况。权重越高，在被访问的概率越大
3. ip_hash上述weight权重模式方式存在一个问题，在负载均衡系统中，假如用户在某台服务器上登录了，那么该用户第二次请求的时候，因为我们是负载均衡系统，每次请求都会重新定位到服务器集群中的某一个，那么已经登录某一个服务器的用户再重新定位到另一个服务器，其登录信息将会丢失，这样显然是不妥的。
   可以采用ip_hash指令解决这个问题，如果客户已经访问了某个服务器，当用户再次访问时，会将该请求通过哈希算法，自动定位到该服务器。每个请求按访问IP的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session不能跨服务器的问题。