计算机网络通信协议常见问题

左手的ㄟ右手 2022-11-27 15:51 998阅读 0赞

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70_pic_center]

### 文章目录 ###

*  一. 问题背景
 *  二. 网络协议常见问题
 *   *  2.1 谈谈你对五层网络协议体系结构的理解？
     *   *  2.1.1 应用层
         *  2.1.2 传输层
         *  2.1.3 网络层
         *  2.1.4 数据链路层
         *  2.1.5 物理层
     *  2.2 简单说下每一层对应的协议有哪些？
     *  2.3 ARP协议的工作原理？
     *  2.4 谈谈你对IP地址分类的理解
     *  2.5 TCP的主要特点是什么？
     *  2.6 UDP的主要特点是什么？
     *  2.7 TCP和UDP的区别
     *  2.8 TCP和UDP分别对应应用层的哪些协议
     *   *  2.8.1 TCP对应的应用层协议
         *  2.8.2 UDP对应的应用层协议
     *  2.9 详细说一下TCP三次握手的过程
     *   *  2.9.1 三次握手
         *  2.9.2 为什么两次握手不可以？
         *  2.9.3 为什么不需要四次握手？
         *  2.9.4 Server端接收到Client端的SYN后，为什么还要传回SYN?
         *  2.9.5 为什么发送了SYN，还要发送ACK？
     *  2.10 详细说下TCP四次挥手的过程？
     *   *  2.10.1 四次挥手
         *  2.10.2 为什么TIME-WAIT状态必须等待2MSL的时间呢？
         *  2.10.3 为什么第二次不能和第三次合并，第二次和第三次之间的等待是什么？
         *  2.10.4 保活计时器的作用
     *  2.11 TCP协议如何保证可靠传输的？
     *  2.12 谈谈你对停止等待协议的理解？
     *  2.13 谈谈你对ARQ协议的理解？
     *   *  2.13.1 自动重传请求ARQ协议 （超时重传）
         *  2.13.2 连续ARQ协议
         *  2.13.3 优缺点
     *  2.14 谈谈你对滑动窗口的了解？
     *  2.15 谈谈你对流量控制的理解？
     *  2.16 谈下你对TCP拥塞控制的理解？使用了哪些算法？
     *   *  2.16.1 慢开始
         *  2.16.2 拥塞避免
         *  2.16.3 快重传
         *  2.16.4 快恢复
         *  2.16.4 总结
     *  2.17 粘包
     *   *  2.17.1 什么是粘包？
         *  2.17.2 TCP粘包是怎么产生的？
         *  2.17.3 怎么解决粘包和拆包？
         *  2.17.4 UDP会不会产生粘包问题呢？
     *  2.18 你对Http状态码有了解吗？
     *   *  2.18.1 1XX 信息
         *  2.18.2 2XX 成功
         *  2.18.3 3XX 重定向
         *  2.18.4 4XX 客户端错误
         *  2.18.5 5XX 服务器错误
     *  2.19 forward和redirect的区别？
     *  2.20 Http方法有哪些？
     *  2.21 说下GET和POST的区别？
     *  2.22 在浏览器输入url地址到显示主页的过程？
     *  2.23 DNS的解析过程？
     *  2.24 谈谈你对域名缓存的了解？
     *  2.25 谈谈你对HTTP长连接和短连接的理解？分别应用于哪些场景？
     *  2.26 谈下HTTP1.0、1.1、1.2的主要变化？
     *   *  2.26.1 HTTP1.1的主要变化
         *  2.26.2 HTTP2.0的主要变化
     *  2.27 HTTPS的工作过程？
     *   *  2.27.1 HTTPS的原理
         *  2.27.2 工作过程
     *  2.28 HTTP 和 HTTPS 的区别？
     *  2.29 HTTPS的优缺点？
     *   *  2.29.1 优点
         *  2.29.2 缺点
     *  2.30 什么是数字签名？
     *  2.30 什么是数字证书？
     *  2.31 什么是对称加密和非对称加密？
     *   *  2.31.1 对称加密
         *  2.31.2 非对称加密

# 一. 问题背景 #

为实习面试做准备，笔者真的很菜，肥肠慌

参考自：[2019秋招：460道Java后端面试高频题答案版【模块五：计算机网络】][2019_460_Java]

# 二. 网络协议常见问题 #

## 2.1 谈谈你对五层网络协议体系结构的理解？ ##

学习计网时，我们折中采取OSI和TCP/IP的优点，采用一种只有五层协议的体系结构，这样既简介又能将概念讲清楚。

如下图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70_pic_center 1]

### 2.1.1 应用层 ###

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

### 2.1.2 传输层 ###

运输层（transport layer）的主要任务就是 **负责向两台主机进程之间的通信提供通用的数据传输服务**。应用进程利用该服务传送应用层报文。“通用的”是指并不针对某一个特定的网络应用，而是多种应用可以使用同一个运输层服务。  
由于一台主机可同时运行多个线程，因此运输层有**复用**和**分用**的功能。所谓**复用就是指多个应用层进程可同时使用下面运输层的服务，分用和复用相反，是运输层把收到的信息分别交付上面应用层中的相应进程。**

### 2.1.3 网络层 ###

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

### 2.1.4 数据链路层 ###

数据链路层（data link layer）通常简称为链路层。**两台主机之间的数据传输，总是在一段一段的链路上传送的，这就需要使用专门的链路层的协议。** 在两个相邻节点之间传送数据时，数据链路层将网络层交下来的 IP 数据报组装成 **帧**，在两个相邻节点间的链路上传送帧。**每一帧包括数据和必要的控制信息（如：同步信息，地址信息，差错控制等）。**  
在接收数据时，控制信息使接收端能够知道一个帧从哪个比特开始和到哪个比特结束。这样，数据链路层在收到一个帧后，就可从中提出数据部分，上交给网络层。控制信息还使接收端能够检测到所收到的帧中有无差错。如果发现差错，数据链路层就简单地丢弃这个出了差错的帧，以避免继续在网络中传送下去白白浪费网络资源。如果需要改正数据在链路层传输时出现差错（这就是说，数据链路层不仅要检错，而且还要纠错），那么就要采用可靠性传输协议来纠正出现的差错。这种方法会使链路层的协议复杂些。

### 2.1.5 物理层 ###

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

## 2.2 简单说下每一层对应的协议有哪些？ ##

涉及到非常多，对常用的作以下列举：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70_pic_center 2]

## 2.3 ARP协议的工作原理？ ##

ARP，address resolution protocol，地址转换协议，属于网络层。

网络层的ARP地址转换协议 **完成了IP地址与物理地址的映射**。首先，每台主机在自己的 **ARP缓冲区中建立一个ARP列表**，记录了其他各个主机的IP地址与MAC地址的对应关系。当源主机要将一个数据包发送给目的主机时，首先查找自己的ARP列表看看是否有目的主机的MAC地址，如果有，直接将数据包发送到这个MAC地址；否则，就向本地网络发起一个ARP请求的广播包，查询此目的主机对应的MAC地址。

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

## 2.4 谈谈你对IP地址分类的理解 ##

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

每个IP地址有32位，即4个字节（IPv4是32位；IPv6是128位，16个字节）。**IP地址包括网络ID和主机ID**。同一个物理网络上的所有主机都使用同一个网络ID，网络上的主机（包括网络上工作站，服务器和路由器等）有一个主机ID与其对应。A~E类地址的特点如下：

<table> 
 <thead> 
  <tr> 
   <th>类别</th> 
   <th>特点</th> 
   <th>第一个字节的范围</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>A类地址</td> 
   <td>以0开头</td> 
   <td>0~127</td> 
  </tr> 
  <tr> 
   <td>B类地址</td> 
   <td>以10开头</td> 
   <td>128~191</td> 
  </tr> 
  <tr> 
   <td>C类地址</td> 
   <td>以110开头</td> 
   <td>192~223</td> 
  </tr> 
  <tr> 
   <td>D类地址</td> 
   <td>以1110开头</td> 
   <td>224~239</td> 
  </tr> 
  <tr> 
   <td>E类地址</td> 
   <td>以1111开头</td> 
   <td>保留地址</td> 
  </tr> 
 </tbody> 
</table>

## 2.5 TCP的主要特点是什么？ ##

1.  TCP是面向连接的。就像打电话，向拨号建立连接，才能通信；
2.  每条连接只有两个端点。只能是一对一（点对点）；
3.  TCP提供可靠交付的服务。通过TCP连接传送的数据，无差错，无丢失，不重复，并且按序到达；
4.  TCP提供全双工通信。TCP允许通信双方的应用程序在任何时候都能发送数据；
5.  面向字节流。TCP中的“流”（stream）指的是流入进程或从进程流出的字节序列。“面向字节流”指的是： **虽然应用程序与TCP的交互是一次一个数据块（大小不等），但是TCP把应用程序交下来的数据仅仅看成是一连串无结构的字节流；**

## 2.6 UDP的主要特点是什么？ ##

1.  UDP是无连接的
2.  UDP支持一对一、一对多、多对一、多对多的交互通信
3.  UDP使用尽最大努力交付的服务，即不保证可靠交付，因此主机不需要维持复杂的连接状态（这里面有很多参数）
4.  UDP是面向报文的
5.  UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如直播，实时视频会议等）
6.  UDP的首部开销很小，只有8个字节，比TCP的20个字节的首部要短。

## 2.7 TCP和UDP的区别 ##

<table> 
 <thead> 
  <tr> 
   <th></th> 
   <th>TCP</th> 
   <th>UDP</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>是否面向连接</td> 
   <td>面向连接</td> 
   <td>无连接</td> 
  </tr> 
  <tr> 
   <td>传输可靠性</td> 
   <td>可靠</td> 
   <td>不可靠</td> 
  </tr> 
  <tr> 
   <td>传输形式</td> 
   <td>字节流</td> 
   <td>数据报文段</td> 
  </tr> 
  <tr> 
   <td>传输效率</td> 
   <td>慢</td> 
   <td>快</td> 
  </tr> 
  <tr> 
   <td>所需资源</td> 
   <td>多</td> 
   <td>少</td> 
  </tr> 
  <tr> 
   <td>应用场景</td> 
   <td>要求通信数据可靠（如：文件传输、邮件传输）</td> 
   <td>要求通信速度高（如：域名转换、直播）</td> 
  </tr> 
  <tr> 
   <td>首部字节</td> 
   <td>20-60</td> 
   <td>8</td> 
  </tr> 
 </tbody> 
</table>

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

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

## 2.8 TCP和UDP分别对应应用层的哪些协议 ##

### 2.8.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.8.2 UDP对应的应用层协议 ###

DNS：用于域名解析服务，将域名地址转换为 IP 地址。DNS 用的是 53 号端口。  
SNMP：简单网络管理协议，使用 161 号端口，是用来管理网络设备的。由于网络设备很多，无连接的服务就体现出其优势。  
TFTP(Trival File Transfer Protocal)：简单文件传输协议，该协议在熟知端口 69 上使用 UDP 服务。

## 2.9 详细说一下TCP三次握手的过程 ##

### 2.9.1 三次握手 ###

TCP连接建立的过程叫做握手，握手需要在客户与服务器之间交换3个TCP报文

握手过程如下图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70_pic_center 3]

最初客户端与服务器处于CLOSED（关闭）状态。A（客户端）主动打开连接，B（服务器）被动打开连接。一开始B的TCB服务器进程会创建传输控制块TCB，准备接受客户端进程的连接请求，然后进入LISTEN（监听）状态，等待客户端的连接请求。如有立即作出响应。

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

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

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

### 2.9.2 为什么两次握手不可以？ ###

为了防止已经失效的连接请求报文段突然又传送到了B，因而产生错误。

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

对上面这种情况，如果不进行第三次握手，B发出确认报文后就认为新的传输连接已经建立，并一直等待A发来数据。B的许多资源就这样白白浪费了。如果采用了三次握手，由于A实际上并没有发出建立连接的请求，所以不会理睬B的确认，也不会向B发送数据。B由于收不到确认，就知道A并没有要求建立连接。

### 2.9.3 为什么不需要四次握手？ ###

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

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

### 2.9.4 Server端接收到Client端的SYN后，为什么还要传回SYN? ###

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

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

### 2.9.5 为什么发送了SYN，还要发送ACK？ ###

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

## 2.10 详细说下TCP四次挥手的过程？ ##

### 2.10.1 四次挥手 ###

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

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

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

第三次挥手：若B已经没有要向A发送的数据，其应用进程就通知TCP释放连接。此时B发出的连接释放报文段必须使FIN=1，ACK=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：Maximum Segment Lifetime，最大报文段寿命）后，A才能进入CLOSED状态，然后撤销传输控制块，结束这次的TCP连接。当然如果B一收到A的确认后，就会进入CLOSED状态，然后撤销传输控制块。所以在释放连接时，B结束TCP连接的时间要早于A。

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

1.  **保证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状态不等待一段时间，而是发送完确认报文后立即释放连接，那么就无法收到B重传的FIN+ACK报文段，因而也不会再发送一次确认，B就无法正常进入CLOSED状态。
2.  **防止已经失效的连接请求报文段出现在本地连接中。** A在发送完最后一个ACK报文段后，再经过时间2MSL，就可以使本地连接的持续时间内所产生的所有报文都从网络消失。这样就可以在下一个连接中不会出现旧的连接请求报文段。

### 2.10.3 为什么第二次不能和第三次合并，第二次和第三次之间的等待是什么？ ###

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

### 2.10.4 保活计时器的作用 ###

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

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

## 2.11 TCP协议如何保证可靠传输的？ ##

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

## 2.12 谈谈你对停止等待协议的理解？ ##

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

## 2.13 谈谈你对ARQ协议的理解？ ##

**Automatic Repeat rQuest，ARQ，自动重传请求。其实本质就是发送数据、接收数据、发送确认、接收确认**

正常无误的情况如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70_pic_center 5]  
出现差错、确认丢失、确认迟到的情况分别如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70_pic_center 6]

### 2.13.1 自动重传请求ARQ协议 （超时重传） ###

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

这样的超时重传信道利用率极低，因此有如下的连续ARQ协议

### 2.13.2 连续ARQ协议 ###

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

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70_pic_center 7]

### 2.13.3 优缺点 ###

<table> 
 <thead> 
  <tr> 
   <th></th> 
   <th>优点</th> 
   <th>缺点</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>自动重传ARQ</td> 
   <td>简单</td> 
   <td>信道利用率低</td> 
  </tr> 
  <tr> 
   <td>连续ARQ</td> 
   <td>信道利用率高，实现简单，即使确认丢失了，也不重传（因为采用累计确认，对按序到达的最后一个消息发送确认）</td> 
   <td>不能向发送方反映出接收方已经正确收到的所有分组的信息。<br> 例子：发送方发送了5条消息，中间第三条丢失（3号），这时接收方只能对前两个发送确认。发送方无法知道后三个分组的下落，而只好把后三个全部重传一次。这也叫<strong>Go-Back-N（回退N）</strong>，表示需要退回来重传已经发送过的N个消息。</td> 
  </tr> 
 </tbody> 
</table>

## 2.14 谈谈你对滑动窗口的了解？ ##

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

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

## 2.15 谈谈你对流量控制的理解？ ##

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

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

拥塞控制和流量控制不同，前者是一个全局性的过程，而后者是端到端的控制。

流量控制是端到端的控制，例如A通过网络给B发数据，A发送得太快导致B没法接收（B缓冲窗口过小或者处理太慢），这时候的控制就是流量控制。原理是通过改变滑动窗口的大小来实现的。流量控制所要做的就是抑制发送端发送数据的速率，以便使接收端来得及接收。

拥塞控制是A与B之间的网络发生堵塞导致传输过慢或者丢包，来不及传输。防止过多的数据注入到网络中，这样可以使网络中的路由器或者链路不至于过载。拥塞控制是一个全局性的过程。涉及到所有的主机、路由器以及与降低网络性能有关的所有因素。

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

TCP的拥塞控制采用四种算法，即慢开始、拥塞避免、快重传、快恢复。在网络层可以使路由器采用适当的丢失分组策略（如主动队列管理AQM），以减少网络拥塞的发生。

### 2.16.1 慢开始 ###

慢开始的思路是当主机开始发送数据时，如果立即把大量数据字节注入到网络中，那么可能会引起网络阻塞。因为现在还不知道网络负荷的情况，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是逐渐增大拥塞窗口数值。cwnd初始值为1，每经过一个传播轮次，cwnd加倍（即按2^n指数增长）。cwnd也不会无限地加倍增大，还会有一个慢开始门限变量（ssthread），当`cwnd == ssthread`时，那么就开始拥塞避免算法，cwnd按线性规律增长。

如下图所示：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70_pic_center 8]

### 2.16.2 拥塞避免 ###

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

### 2.16.3 快重传 ###

一条TCP连接有时会等待重传计时器超时而空闲一段时间，慢开始和拥塞避免无法很好地解决这类问题，因此提出了快重传和快恢复的拥塞控制方法。

快重传算法并非取消了重传机制，只是在某些情况下更早地重传丢失的报文段。如果 **当发送端连续接收到三个重复的ACK确认（如果接收方接收到一个不按顺序的数据段，它会立即给发送机发送一个重复确认），那么发送方断定分组丢失**，立即重传丢失的报文段，而不必等待重传计时器超时。慢开始算法只是在TCP建立时才使用。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70_pic_center 9]

### 2.16.4 快恢复 ###

当发送方连续收到三个重复的确认ACK，说明网络也不那么糟糕，不需要重新慢开始（重新慢开始会降低效率），只需`cwnd = cwnd / 2`，`ssthread = cwnd`。就执行“乘法减小”算法，把慢开始门限（ssthread）减半，这是为了预防网络发生拥塞。

由于发送方认为网络很可能没有发生拥塞，因此现在不执行慢开始算法，而是把cwnd设置为慢开始门限减半后的值，然后开始执行拥塞避免算法，使拥塞窗口线性增大。

快速恢复算法实现：

1.  当收到第3个重复的A C K时，将s s t h re s h设置为当前拥塞窗口 c w n d的一半。重传丢失的报文段。然后`cwnd = ssthread + ACK个数 * MSS`（一般是3个重复的ACK）。

> **为什么要加上`ACK个数 * MSS`？**  
> **答：** 我们在开始的时候将发送窗口的值设为ssthresh的值，但是因为我们接收到n个ACK，这说明在网络中已经有n个报文已经到达接收端了，所以我们设置的窗口中还可以再添加n个报文发送，这样其实才是真正的将发送窗口的值设为ssthresh的值。

1.  每次收到另一个重复的 A C K时， c w n d增加1个报文段大小并发送 1个分组（如果新的c w n d允许发送） 。

> **为什么在接收到重复ACK的时候还要让cwnd加1？**  
> **答：** 每当我们接收到重复的ACK的时候就能说明两点：  
> 1）我们要发送的报文还是没有到达接收端，所以发送窗口的左端是不能动的；  
> 2）在网络中又有一个报文成功到达接收端，所以网络中又可以添加一个报文。

1.  当下一个确认新数据的 A C K到达时，设置c w n d为s s t h re s h（在第1步中设置的值）。这个A C K应该是在进行重传后的一个往返时间内对步骤 1中重传的确认。另外，这个 A C K也应该是对丢失的分组和收到的第 1个重复的A C K之间的所有中间报文段的确认。这一步采用的是拥塞避免，因为当分组丢失时我们将当前的速率减半。

> **为什么在最后接收到非重复的ACK要重置cwnd的值？**  
> **答：** 其实看过前两个问题的答案，这个问题的答案也就显而易见了。我们虽然一直在加cwnd的值，但是其中可同时发送的报文数量还是ssthresh的值，而当我们接收到非重复的ACK的时候，说明我们之前要发送的报文也顺利到达接收端，这个时候，我们将发送窗口移动到这个新的ACK的位置，这个时候窗口里边已经没有那些空的“小窗口”，所以要把发送窗口大小重置为ssthresh的值。

### 2.16.4 总结 ###

没有发生拥塞之前使用慢开始以及拥塞避免算法，发生拥塞后（即三次重复确认）使用快重传以及快恢复算法。

## 2.17 粘包 ##

### 2.17.1 什么是粘包？ ###

在学习Java NIO时，可能会发现：如果客户端连续不断向服务端发送数据包时，服务端接收的数据会出现若干个数据包站在一起

> 储备知识：
> 
> 1.  TCP是基于字节流的，因此TCP把数据块仅仅看成一连串无结构的字节流，没有边界。TCP并不知道它是一个TCP报文格式的数据包
> 2.  TCP的首部也没有表示数据长度的字段
> 
> 总结：基于以上两点，在使用TCP传输数据时才会有，才会有粘包或者拆包现象发生的可能。

**TCP粘包就是指发送方发送的若干个数据包到达接收方时粘成了一个包，从接收方的缓冲区来看，后一包数据的头紧接着前一包数据的尾，出现粘包的原因可能来自发送方，也可能来自接收方。**

### 2.17.2 TCP粘包是怎么产生的？ ###

*  发送方产生的

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

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

### 2.17.3 怎么解决粘包和拆包？ ###

1.  **格式化数据：** 每条数据有固定的格式（开始符，结束符），这种方法简单易行，但是选择开始符和结束符时一定要确保每条数据的内部不包含开始符和结束符。
2.  **发送长度：** 发送每条数据时，将数据的长度一并发送，例如规定数据的前4位是数据的长度，应用层在处理时可以根据长度来判断每个分组的开始和结束位置。

### 2.17.4 UDP会不会产生粘包问题呢？ ###

TCP为了保证可靠传输并减少额外的开销（每次发包都要验证），采用了基于流的传输，基于流的传输不认为消息是一条一条的，是无保护消息边界的（保护消息边界：指传输协议把数据当做一条独立的消息在网上传输，接收端一次只能接受一条独立的消息）。

UDP则是面向消息传输的，是有保护消息边界的，接收方一次只接受一条独立的信息，所以不存在粘包问题。

举个例子：有三个数据包，大小分别为2k、4k、6k，如果采用UDP发送的话，不管接受方的接收缓存有多大，我们必须要进行至少三次以上的发送才能把数据包发送完，但是使用TCP协议发送的话，我们只需要接受方的接收缓存有12k的大小，就可以一次把这3个数据包全部发送完毕。

## 2.18 你对Http状态码有了解吗？ ##

<table> 
 <thead> 
  <tr> 
   <th></th> 
   <th>类别</th> 
   <th>原因</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>1XX</td> 
   <td>Information（信息性状态码）</td> 
   <td>接收的请求正在处理</td> 
  </tr> 
  <tr> 
   <td>2XX</td> 
   <td>Success（成功状态码）</td> 
   <td>请求正常处理完毕</td> 
  </tr> 
  <tr> 
   <td>3XX</td> 
   <td>Redirection（重定向状态码）</td> 
   <td>需要进行附加操作已完成请求</td> 
  </tr> 
  <tr> 
   <td>4XX</td> 
   <td>Client Error（客户端错误状态码）</td> 
   <td>服务器无法处理请求</td> 
  </tr> 
  <tr> 
   <td>5XX</td> 
   <td>Server Error（服务器错误状态码）</td> 
   <td>服务器处理请求出错</td> 
  </tr> 
 </tbody> 
</table>

### 2.18.1 1XX 信息 ###

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

### 2.18.2 2XX 成功 ###

1.  200 OK
2.  204 No Content ：请求已经成功处理，但是返回的响应报文不包含实体的主体部分。一般在只需要从客户端往服务器发送信息，而不需要返回数据时使用。
3.  206 Partial Content ：表示客户端进行了范围请求，响应报文包含由 Content-Range 指定范围的实体内容。

### 2.18.3 3XX 重定向 ###

1.  301 Moved Permanently ：永久性重定向；
2.  302 Found ：临时性重定向；
3.  303 See Other ：和 302 有着相同的功能，但是 303 明确要求客户端应该采用 GET 方法获取资源。
4.  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 方法。

### 2.18.4 4XX 客户端错误 ###

1.  400 Bad Request ：请求报文中存在语法错误。
2.  401 Unauthorized ：该状态码表示发送的请求需要有认证信息（BASIC 认证、DIGEST 认证）。如果之前已进行过一次请求，则表示用户认证失败。
3.  403 Forbidden ：请求被拒绝。
4.  404 Not Found

### 2.18.5 5XX 服务器错误 ###

1.  500 Internal Server Error ：服务器正在执行请求时发生错误；
2.  503 Service Unavailable ：服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。

## 2.19 forward和redirect的区别？ ##

forward：是转发，服务端发出请求进行转发。速度比redirect快  
redirect：是重定向，客户端从服务端获取到地址，再次发出新的请求。

## 2.20 Http方法有哪些？ ##

<table> 
 <thead> 
  <tr> 
   <th></th> 
   <th>作用</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>GET</td> 
   <td>获取资源，当前网络中绝大部分都是使用GET</td> 
  </tr> 
  <tr> 
   <td>HEAD</td> 
   <td>获取报文首部，和GET方法类似，但是不返回报文实体主体部分</td> 
  </tr> 
  <tr> 
   <td>POST</td> 
   <td>传输实体主体</td> 
  </tr> 
  <tr> 
   <td>PUT</td> 
   <td>上传文件，由于自身不带验证机制，任何人都可以上传文件，存在安全问题，一般不适用该方法</td> 
  </tr> 
  <tr> 
   <td>PATCH</td> 
   <td>对资源进行部分修改。PUT也可用于修改资源，但是只能完全代替原始资源，PATCH允许部分修改</td> 
  </tr> 
  <tr> 
   <td>OPTIONS</td> 
   <td>查询指定的URL支持的方法；在cors问题中，作用是预检，即客户端先发OPTIONS请求给服务器，看看服务器支持什么方法</td> 
  </tr> 
  <tr> 
   <td>CONNECT</td> 
   <td>要求在与代理服务器通信时建立隧道。使用 SSL（Secure Sockets Layer，安全套接层）和 TLS（Transport Layer Security，传输层安全）协议把通信内容加密后经网络隧道传输。</td> 
  </tr> 
  <tr> 
   <td>TRACE</td> 
   <td>追踪路径。服务器会将通信路径返回给客户端。发送请求时，在 Max-Forwards 首部字段中填入数值，每经过一个服务器就会减 1，当数值为 0 时就停止传输。通常不会使用 TRACE，并且它容易受到 XST 攻击（Cross-Site Tracing，跨站追踪）。</td> 
  </tr> 
 </tbody> 
</table>

## 2.21 说下GET和POST的区别？ ##

他们本质都是HTTP请求。

*  **功能上的区别：** GET是从服务器上获取资源，而POST是更新服务器上的资源
 *  **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报文的
 *  **安全性上的区别：** POST的安全性比GET高。因为GET请求提交的数据会明文地出现在url上，而POST请求参数则被包装到请求体中，相对安全
 *  **请求大小的区别：** GET请求的长度受限于浏览器或服务器对url长度的限制，允许发送的数据量比较小，而POST请求则是没有限制大小的。

## 2.22 在浏览器输入url地址到显示主页的过程？ ##

1.  **DNS解析：** 浏览器查询DNS，获取对应的ip地址。具体过程包括：浏览器搜索自身的DNS缓存、搜索操作系统的DNS缓存，读取本地的Host文件和向本地DNS服务器进行查询等。如果要查询的域名包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析。如果要查询的域名不由本地DNS服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个IP地址映射，完成域名解析。如果本地域名服务器并未缓存该网址映射关系，那么将根据其设置发起递归查询或者迭代查询。
2.  **TCP连接：** 浏览器获得域名对应的IP地址后，浏览器向服务器请求建立连接，发起三次握手。
3.  **发送HTTP请求：** TCP连接建立后，浏览器向服务器发送HTTP请求
4.  **服务器处理请求并返回HTTP报文：** 服务器接收到这个请求，并根据路径参数映射到特定的请求处理器进行处理，并将结果及相应的视图返回给浏览器。
5.  **浏览器解析渲染页面** 浏览器解析并渲染视图。若遇到对css、js、图片等静态资源的引用，则重复上述步骤对服务器请求这些资源。浏览器根据请求到的资源、数据渲染页面、最终向用户呈现一个完整的页面。
6.  **连接结束：** 结束TCP连接

## 2.23 DNS的解析过程？ ##

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

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

## 2.24 谈谈你对域名缓存的了解？ ##

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

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

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

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

在HTTP/1.0中默认短连接。即客户端与服务端的每一次HTTP操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问某个html页面或者web页中包含其他web资源（css、js、图片），每遇到这样一个web资源，浏览器就会重新建立一个HTTP会话。

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

Connecetion: keep-alive

在使用长连接的情况下，当一个页面加载完毕，客户端与服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这条已建立的连接。

## 2.26 谈下HTTP1.0、1.1、1.2的主要变化？ ##

### 2.26.1 HTTP1.1的主要变化 ###

1.  经过多年的HTTP1.0发展，在1.1中采用长连接，HTTP可以在一次TCP连接中不断发送请求。
2.  HTTP1.1支持只发送header，不发送body。原因是先发送header，判断是否成功，再发送数据，节约带宽。POST请求默认就是这样做的。
3.  HTTP1.1的host字段。由于虚拟主机主持多个域名，所以一般将域名解析后得到host。

### 2.26.2 HTTP2.0的主要变化 ###

1.  HTTP2.0支持多路复用，同一连接可以并发处理多个请求，方法是把HTTP数据包拆分为多个帧，并发有序地发送。根据序号在另一端进行重组，而不需要一个个HTTP请求顺序到达。
2.  HTTP2.0支持服务端推送。就是服务端在HTTP请求到达后，除了返回数据外，还推送了额外的内容给客户端。
3.  HTTP2.0 压缩了请求头，同时基本单位是二进制帧流，这样的数据占用空间更少。
4.  HTTP2.0适用于HTTPS场景。因为其在HTTP和TCP中间加了一层SSL层。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70_pic_center 10]

## 2.27 HTTPS的工作过程？ ##

### 2.27.1 HTTPS的原理 ###

详情参考[HTTPS相关原理][HTTPS]

### 2.27.2 工作过程 ###

下图中看不懂的地方可参考[HTTPS相关原理][HTTPS]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70_pic_center 11]

## 2.28 HTTP 和 HTTPS 的区别？ ##

1.  **开销：** HTTPS需要到CA申请证书，一般免费的证书很少，需要交费
2.  **资源消耗：** HTTP是超文本传输协议，信息是明文传输，HTTPS则是具有安全性的SSL加密传输协议，需要消耗更多的CPU和内存资源
3.  **端口不同：** HTTP用80，HTTPS用443
4.  **安全性:** HTTP的连接很简单，是无状态的；HTTPS协议是由TSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比HTTP安全

## 2.29 HTTPS的优缺点？ ##

### 2.29.1 优点 ###

1.  HTTPS可认证用户和服务器，确保数据发送到正确的客户和服务器上
2.  HTTPS 协议是由 SSL + HTTP 协议构建的可进行加密传输、身份认证的网络协议，要比 HTTP 协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性
3.  HTTPS 是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本

### 2.29.2 缺点 ###

1.  HTTPS 协议握手阶段比较费时，会使页面的加载时间延长近 50%，增加 10% 到 20% 的耗电；
2.  HTTPS 连接缓存不如 HTTP 高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响
3.  SSL 证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用
4.  SSL 证书通常需要绑定 IP，不能在同一 IP 上绑定多个域名，IPv4 资源不可能支撑这个消耗
5.  HTTPS 协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的，SSL 证书的信用链体系并不安全，特别是在某些国家可以控制 CA 根证书的情况下，中间人攻击一样可行。

## 2.30 什么是数字签名？ ##

> **储备知识：[HTTPS相关原理][HTTPS]**

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

## 2.30 什么是数字证书？ ##

> **储备知识：[HTTPS相关原理][HTTPS]**

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

## 2.31 什么是对称加密和非对称加密？ ##

### 2.31.1 对称加密 ###

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

### 2.31.2 非对称加密 ###

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

**总结：由于非对称加密的方式不需要发送用来解密的私钥，所以可以保证安全性。但是和对称加密比起来，非对称加密非常的慢，所以我们还是要用对称加密来加密真正的数据（如下图），但对称加密所使用的密钥我们可以通过非对称加密的方式发送出去。**

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70_pic_center 12]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70_pic_center]: /images/20221124/26dadee5feed4a4195dcae9f07c71337.png
[2019_460_Java]: https://blog.csdn.net/WantFlyDaCheng/article/details/101444390?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-2.channel_param&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-2.channel_param
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221124/32c505f854054f6f9636132416a86f87.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221124/6538a1e1a36848d6be4837dc9e407c1d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20221124/8036fc7ef0cd4a3f9582665aea3a25f6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70_pic_center 4]: /images/20221124/708859afa5d849b3bbb0b3ef1fecdc2f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70_pic_center 5]: /images/20221124/d19acf1738af482a8ed180d7bf77e041.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70_pic_center 6]: /images/20221124/678090fe7d1041009e72885aa60caadb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70_pic_center 7]: /images/20221124/6d0efeaffead4f1a822699d287b597b8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70_pic_center 8]: /images/20221124/f686f91ecf75441aa7e0eb1253c26a86.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70_pic_center 9]: /images/20221124/30c7990853aa4e9d9e1b0ed604dc4ef9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70_pic_center 10]: /images/20221124/d5b8c08e6c364949a1e5a46fabf5f96e.png
[HTTPS]: https://blog.csdn.net/qq_40634846/article/details/113091962
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70_pic_center 11]: /images/20221124/06d9e86d6e934fe986e54c9c5f64d478.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70_pic_center 12]: /images/20221124/f7610fb343d4433fa59d31d78399b25a.png