计算机网络校招知识点总结

---

1. 绪论

1.1 OSI模型七层模型是什么？各自的功能是什么？

• 物理层：确定与传输媒体接口有关的一些特性，实现底层比特流的透明传输（A/D，D/A），设备包括双绞线、光缆等
• 数据链路层：定义数据的基本格式帧，功能还包括差错控制、流量控制和传输管理等
• 网络层：网络层的传输单位是数据报，主要任务是路由选择和分组转发
• 传输层：传输单位是报文段（TCP）或用户数据报（UDP），实现端到端之间的通信
• 会话层：建立、管理和维护会话
• 表示层：数据格式转化、数据加密
• 应用层：为用户程序提供服务

1.2 TCP/IP参考模型

OSI七层模型非常复杂，且部分功能冗余，因此完全实现OSI参考模型的系统不多。而TCP/IP直接面向市场需求，实现容易，他们分别是：1. 应用层；2. 传输层；3. 网际层；4. 网络接口层

1.3 计算机网络各层协议

各层	协议
应用层	DNS（域名系统）、FTP（文件传输）、HTTP（超文本）、SMTP（电子邮件）、RIP（路由信息协议）、DHCP（动态主机配置）
传输层	TCP、UDP
网络层	IP、ARP（地址解析）、RARP、ICMP（网际控制报文协议）、NAT（网络地址转换）

1.4 计算机网络为什么要分层？优点？

1. 各层间独立，可以降低大系统的复杂度
2. 灵活性好
3. 易于实现和维护
4. 能促进标准化工作

当然分层也有一些缺点，例如，有些功能会在不同的层次中重复出现，因而产生了额外开销。

2. 物理层

2.1 电路交换、报文交换和分组交换的区别？

• 电路交换：整个报文的比特流从源点连续地直达终点，像在一个管道中传输。典型例子是传统电话网络。
• 报文交换：将整个报文转发到相邻结点，全部存储下来，查找转发表，转发道下一个节点。是存储-转发类型的网络。
• 分组交换：将报文分组转发到相邻结点，查找转发表，转发到下一个节点，是报文交换的改进版。

2.2 虚电路和数据报的区别？

• 连接的建立：数据报无连接，虚电路面向连接
• 可靠性：数据报不保证数据的可靠交付，虚电路可靠性由网络保证
• 分组顺序：数据报不保证分组的有序到达，虚电路保证分组的有序到达
• 路由选择：数据报的分组都是通过独立的路由选择和转发，而同属于一条虚电路的分组按照同一路由转发
• 目的地址：数据报服务中每个分组都有完整的目的地址，但虚电路中每个分组仅存放长度较短的虚电路号

2.3 通信方式有哪些？

• 单工通信：单向传输
• 半双工通信：双向交替传输
• 全双工通信：双向同时传输

3. 数据链路层

3.1 PPP协议的组成？

• 链路控制协议（LCP)
• 网路控制协议（NCP)
• 一个将IP数据报封装到串行链路的方法

3.2 局域网的概念和特点？

局域网是指在一个较小的地理范围内，将各种设备通过双绞线等介质互相连接起来，组成信息共享的计算机互联网络。它是一种典型的广播信道，主要特点是网络为一个单位所拥有，且地理范围和站点数目均有限。

3.3 以太网

以太网是一种星型拓扑结构局域网，信息以广播形式发送。

3.4 数据链路层的功能有哪些？

• 封装成帧：将网络层传下来的分组添加首部和尾部，用于标记帧的开始和结束。
• 透明传输：将部分数据（帧定界符）进行转义，不管传输的数据是什么，都应当能够再链路上传送。
• 差错检测：使用CRC循环冗余检验来检查比特差错，保证同一物理链路上的数据传输进行没问题。

3.5 信道分类有哪些？

• 广播信道：一对多，需要专门的控制方法进行协调，避免冲突发生，主要有两种方法：1. 信道复用技术；2. CSMA/CD协议。
• 点对点信道：一对一通信，使用PPP协议进行控制。

3.6 CSMA/CD协议

CSMA/CD表示载波监听多点接入/碰撞检测，适用于总线形网络或半双工网络环境。工作流程可简单概况为：“先听先发，边听边发，冲突停发，随即重发”。

3.7 交换机

交换机具有自学习能力，学习的是交换表的内容，交换表中存储着MAC地址到接口的映射。

3.8 虚拟局域网

虚拟局域网可以建立与物理位置无关的逻辑组，只有在同一个虚拟局域网中的成员才会收到链路层广播信息。

4. 网络层

4.1 概述

网络层向上只提供简单灵活的、无连接的、尽最大努力交互的数据报服务。

4.2 IP协议的定义和作用？

IP协议又称互联网协议，是支持网间互联的数据包协议。IP协议是不可靠、尽力交付的数据包传输服务，作用有如下：

1. 路由选择：IP协议根据路由选择协议提供的路由信息对IP数据进行转发，直至抵达目的主机。
2. 分组转发：不同网络的数据包最大长度限制不同，IP协议将数据包分组进行转发，在到达目的主机后，再回复原来的IP数据包。

4.3 什么是RARP？工作原理

RARP是反向地址转换协议，是网络层协议，RARP与ARP工作方式相反。ARP是IP地址->MAC地址，RARP是MAC->IP。

原理

1. 网络上每个设备都有一个独立的MAC地址，主机从网卡上读取MAC地址，然后在网络上发送一个RARP请求的广播数据包，请求RARP服务器回复该主机的IP地址。
2. RARP服务器收到了RARP请求数据包，为其分配IP地址，并将RARP回应发送给主机。
3. PC机收到RARP回应后，就使用得到的IP地址通讯。

4.4 域名和IP的关系，一个IP可以对应多个域名吗？

IP在一个网络中是唯一的，一个域名只能对应一个IP，而一个IP可以对应多个域名。

4.5 IPv4地址不够如何解决？

• DHCP：动态主机配置协议。将连入互联网的设备分配一个临时IP地址，每次得到的IP地址不一定是一样的，这样能保证IP地址充分利用。
• CIDR：无类别域间路由。消除了传统的ABC类网络以及子网划分，能更充分地利用IPv4的所有地址。
• NAT：网络地址转换协议。不同局域网的主机可以使用相同的IP地址，当局域网主机想要与公网进行通信时，NAT方法将该主机转换为全球IP地址。这样使得一个IP地址就可以与因特网连通，大大节省了IP地址的消耗。
• IPv6：可以实现2¹²⁸次方个地址（16B*8），这个数量级可以给地球上每一颗沙子都分配一个IP地址。

4.6 路由器的分组转发流程？

从数据报的首部提取目的主机的 IP 地址 D，得到目的网络地址 N。

1. 若 N 就是与此路由器直接相连的某个网络地址，则进行直接交付；
2. 若路由表中有目的地址为 D 的特定主机路由，则把数据报传送给表中所指明的下一跳路由器；
3. 若路由表中有到达网络 N 的路由，则把数据报传送给路由表中所指明的下一跳路由器；
4. 若路由表中有一个默认路由，则把数据报传送给路由表中所指明的默认路由器；
5. 报告转发分组出错

4.7 ICMP协议概念/作用

ICMP是网际控制报文协议，主要是实现IP协议中为实现的部分功能，用来传输控制信息来辅助网络层通信。其主要功能是验证网络是否畅通（确认接收方是否受到IP数据包）以及辅助IP协议实现可靠传输（若发生IP丢包，ICMP会通知发送方IP数据包被丢弃的原因）

4.8 两台电脑连起来后ping不通，问题有哪些？

• 网络连接是否正常，检查网卡驱动是否正确安装；
• 局域网设置问题，检查IP地址是否设置正确；
• 检查是否被防火墙阻拦（对ICMP报文过滤），如果是的话，关闭防火墙；
• 是否被第三方软件拦截；
• 两台设备之间网络延迟是否过大（路由设置不合理），导致ICMP报文无法在规定时间内收到。

4.9 ARP地址解析过程的原理和地址解析过程？

ARP是地址解析协议的缩写，该协议将IP地址转换为物理地址，工作在数据链路层。

1. 首先，每个主机都会建立自己的ARP列表，以表示IP地址和MAC地址之间的对应关系；
2. 当源主机要发送数据时，首先检查ARP列表是否有IP对应的目的主机的MAC地址，若有，则直接发送数据，否则向同一子网所有主机发送ARP数据包（广播），该数据包包括源主机的IP和MAC，以及目的主机的IP；
3. 所有的主机都自己检查自己的，如果目的IP不是自己的IP则忽略，检查到有对应IP的主机将自己主机中的目的IP和MAC写到这个ARP响应包中，告诉源主机自己就是目的MAC地址；
4. 源主机收到ARP响应包后，将目的主机的IP和MAC写入ARP列表。若一直没收到，则表示ARP查询失败。

4.10 网络地址转换NAT

NAT是网络地址转换，他是将内部私有网络翻译成共有网络IP地址的技术。该协议可以将IP地址不足的问题，而且能隐藏和保护网络内部主机，从而避免来自外部网络的攻击。

4.11 运输层协议和网络层协议区别？

网络层协议负责提供网络主机间（点对点）的逻辑通信；运输层协议负责提供进程间（端到端）的逻辑通信。

5. 运输层

5.1 三次握手和四次挥手机制

三次握手
三次握手是TCP连接的建立过程。在握手前，客户端处于CLOSED阶段，服务器处于监听LISTEN阶段。然后进行三次握手：

1. 客户端向服务器发送一个SYN包，等待服务器确认，此时客户端处于SYN-SENT状态；
   • SYN表示表示请求连接
   • 序号seq = x是初始序号
2. 服务器接收到后，返回TCP报文，其中
   • 标志位为SYN（请求连接）和ACK（表示确认客户端的报文seq有效），服务器能正常接收客户端发送的数据，并统一创建新连接；
   • 序号seq = y
   • 确认好ack = x+1，表示客户端的序号seq并将其加一作为自己的确认号，表示希望下次收到的是x+1
3. 客户端收到发送的SYN+ACK后，明确了从客户端到服务器的数据传输是正常的
   • 标志位为 ACK，表示确认收到服务器端同意连接的信号
   • 序号seq = x+1，确认号ack = y+1，同上
   • 随后客户端进入 ESTABLISHED

四次挥手

双方都处于ESTABLISHED阶段，假设客户端先主动释放连接。

1. 客户端向服务器发送报文，表明想要释放TCP连接，其中：
   • 标记位为FIN，表示请求释放连接
   • 序号seq = u
   • 随后客户端进入FIN-WAIT-1阶段，即半关闭阶段，并停止向服务器发送数据
2. 服务器收到该报文后，结束ESTABLISHED阶段，进入CLOSE-WAIT阶段，并回复一段报文
   • 标志位ACK = 1
   • 序号seq = v
   • 确认好ack = u+1
   • 客户端收到后，确认服务器已经接收到自己的请求，随后结束FIN-WAIT-1阶段，进入FIN-WAIT-2阶段
3. 服务器再次向客户端发送一段报文
   • 标记位为FIN和ACK，表示已经准备好释放连接了
   • 序列号seq = w
   • 确认号ack = u+1（同上）
   • 随后服务器结束CLOSE-WAIT阶段，进入LAST-ACK阶段，并停止向客户端发送数据
4. 客户端收到第二次的报文后，确认服务器已经做好释放连接的准备，结束FIN-WAIT俺，进入TIME-WAIT阶段，并发送报文
   • 标记位为ACK
   • 序列号seq = u+1，ack = w+1
   • 随后客户端等待2MSL后，再关闭进入CLOSED阶段。

5.2 如果三次握手的时候每次握手信息对方没收到会怎样？

• 若第一次握手服务器没有收到客户端的数据包，服务器不会有任何动作，客户端在过一段时间后没收到服务器的确认报文，会重发SYN报文，若超过最大重传次数后，建立连接的系统返回-1。
• 若第二次握手客户端没收到服务器的ACK报文，客户端会采取第一次握手失败时的操作。
• 若第三次握手服务器未收到客户端的ACK报文，服务器会重传，若超过限制次数，accept()返回-1。但此时客户端以为已经连接成功，向服务器发数据，此时服务器会给他发送RST报文(TCP首部标志位之一，表示复位，用于非正常关闭连接）给客户端，消除客户端单方面建立连接的状态。

5.3 为什么要进行三次握手？两次握手可以吗？

三次握手是为了保证双方的发送和接收都正常。若采用两次握手，服务器不知道自己的发送是否正常。

两次握手会发生这样的情况：若客户端发起连接请求，这个请求长时间滞留，于是客户端重新发起新的请求，这一次双方建立连接了；当双方断开连接后，这个滞留的请求来了，服务器向该客户端发送报文建立连接（两次握手），但客户端不发送数据，服务器一直等待，造成了资源的浪费。反之若采用三次握手，服务器没收到第三次握手，就会建立连接失败。

5.4 第二次握手传回了ACK，为什么还要传回SYN？

ACK 是为了告诉客户端发来的数据已经接收无误，传回SYN是表示服务器要连接客户端。

5.5 为什么要四次挥手？

因为FIN释放连接报文和ACK确认报文分别在两次握手中传输的。被动方可能还有数据要处理，所以会先返回ACK，过后再发送FIN。

举个例子：A 和 B 打电话，通话即将结束后，A 说“我没啥要说的了”，B回答“我知道了”，但是 B 可能还会有要说的话，A 不能要求 B 跟着自己的节奏结束通话，于是 B 可能又巴拉巴拉说了一通，最后 B 说“我说完了”，A 回答“知道了”，这样通话才算结束。

5.6 CLOSE-WAIT和TIME-WAIT的区别？

CLOSE-WAIT发生在第二次挥手后，服务器进入CLOSE-WAIT，处理一些未完成传输的数据。

TIME-WAIT发生在第三次挥手后，客户端会等待2MSL，以确保这个ACK包已经顺利被服务器接收到并处理完毕；如不等待，客户端返回的最后确认报文丢失，服务器不能进入正常关闭状态。

总之，等待2MSL时间可以保证数据传输的可靠性和安全性。同时，在日常网络应用环境中，由于整个过程较长，通常不会对网络性能产生影响。

5.7 TIME_WAIT状态会导致什么问题，怎么解决？

在高并发的场景中，会有大量连接处于TIME_WAIT状态，而文件描述符的使用有上限，若持续高并发，会导致一些正常的连接失败。

5.8 TIME_WAIT为很么是2MSL？

当客户端发出最后的 ACK 确认报文时，并不能确定服务器端能够收到该段报文。所以客户端在发送完 ACK 确认报文之后，会设置一个时长为 2 MSL 的计时器。

若服务器在 1 MSL 内没有收到客户端发出的 ACK 确认报文，再次向客户端发出 FIN 报文。如果客户端在 2 MSL 内收到了服务器再次发来的 FIN 报文，说明服务器由于一些原因并没有收到客户端发出的 ACK 确认报文。客户端将再次向服务器发出 ACK 确认报文，并重新开始 2 MSL 的计时。若2MSL没收到服务器的FIN，则说明服务器确认收到了，则进入CLOSED。

5.9 有很多TIME-WAIT状态怎么解决？

• 设置SO_REUSEADDR套接字通知内核，若端口被占用，但TCP处于TIME_WAIT可以重用端口。（特别好用，WebServer项目中就用到了）

• 可以采用长连接减少TCP的连接和断开，但并发量会降低。

5.10 有很多CLOSE-WAIT怎么解决？

首先检查是不是自己的代码问题（看是否服务端程序忘记关闭连接），如果是，则修改代码。
调整系统参数，包括句柄相关参数和 TCP/IP 的参数，一般一个 CLOSE_WAIT 会维持至少 2 个小时的时间，我们可以通过调整参数来缩短这个时间。

5.11 TCP和UDP的区别？

类型	是否面向连接	传输可靠性	传输形式	所需资源	传输效率	应用场景	首部字节
TCP	是	可靠	字节流	多	慢	文件传输、邮件传输	20~60
UDP	否	不可靠	数据报	少	快	即使传输、域名转换	8个字节

5.12 TCP是如何保证可靠性的？

• 序号确认重传：TCP给每一个包编号，在传输的过程中，每次接收方都会对传输方确认应答，这个应答包括了确认序号；同时TCP没发送一个报文段，就会对这个报文段设置计时器，等待目的端确认收到这个报文段。若超过某个时间还没有收到确认，将重发这个报文段。
• 流量控制：当接收方来不及处理发送方的数据时，会让发送方降低发送速率，防止丢包。TCP通过滑动窗口协议来支持流量控制机制。
• 拥塞控制：当网络某个节点发生拥塞时，减少数据的发送。
• 校验和： TCP 将保持它首部和数据部分的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到报文段的检验和有差错，TCP 将丢弃这个报文段并且不确认收到此报文段。

5.13 TCP 流量控制与拥塞控制

• 流量控制

为了让发送方的发送速率不要太快，让接收方来得及接收。如果接收方来不及接收，会有分组丢失。在TCP利用滑动窗口机制实现。主要是的方式是接收方返回的包中会包含自己的接收窗口大小，以及控制发送方的发送窗口大小。

• 拥塞控制

在实际的网络通信系统中，除了发送方和接收方外，还有路由器，交换机等复杂的网络传输线路，此时就需要拥塞控制。拥塞控制是作用于网络的，它是防止过多的数据注入到网络中，避免出现网络负载过大的情况。常用的解决方法有：慢开始和拥塞避免、快重传和快恢复。

• 流量控制和拥塞控制的区别

拥塞控制是全局的，防止过多数据注入网络；流量控制往往针对点对点通信量的控制，是端到端的问题。

5.14 UDP为什么不是可靠的？bind和connect对于UDP的作用是什么？

UDP只有接收缓冲区，只要有数据就发送，尽最大能力交付。且UDP没有流量控制和拥塞避免机制，因此UDP的传输是不可靠的。

bind： UDP 的发送端调用 bind 函数时，就会将这个套接字指定一个端口，若不调用 bind 函数，系统内核会随机分配一个端口给该套接字。当手动绑定时，能够避免内核来执行这一操作，从而在一定程度上提高性能。

connect：UDP 中调用 connect 只是把对端的 IP 和 端口号记录下来没有三次握手过程。

5.15 TCP超时重传的原理？

发送方在发送一次数据后开启一个定时器，在一定时间内如果没收到数据报的ACK报文，就重发数据，若达到一定次数后还没有成功的话，就放弃重传并发送一个复位信号。定时时间的确定需要权衡，过长会使网络利用率不高，过短会造成多次重传，使得网络阻塞。

5.16 TCP的停止等待协议是什么？

停止等待协议是为了实现 TCP 可靠传输而提出的一种相对简单的协议，该协议指的是发送方每发完一组数据后，直到收到接收方的确认信号才继续发送下一组数据。

5.17 TCP滑动窗口

• 滑动窗口：每个TCP/IP主机支持全双工数据传输，因此TCP有两个滑动窗口：一个用于接收数据，另一个用于发送数据。

• 作用

  • 流量控制：发送的字节不能超过窗口的大小
  • 保证TCP可靠：发送窗口只有收到对端对于本段发送窗口内字节的ACK确认，才会移动发送窗口的左边界；接收窗口只有在前面所有的段都确认的情况下才会移动左边界。当在前面还有字节未接收但收到后面字节的情况下，窗口不会移动，并不对后续字节确认。以此确保对端会对这些数据重传。

5.18 TCP拥塞控制采用的四种算法？

• 慢开始：指数增长，由于一开始增长很慢，所以叫慢开始
• 拥塞避免：慢开始达到门限阈值后，改为拥塞避免算法，即每一次加一。
• 快重传：当发送方连续收到三个重复的ACK报文时，直接重传对方尚未收到的报文段，而不必等待那个报文段设置的重传计时器超时。
• 快恢复：当发送发连续收到三个冗余ACK（重复确认）时，把门限值设置为拥塞窗口的一半。然后执行拥塞避免算法。

5.19 若接收方滑动窗口满了，发送方会怎么做？

接收方会返回给发送方的ACK包中的接收窗口大小为0，此时发送方会等待接收方的发送窗口大小直到变为非0为止。

5.20 TCP粘包问题

• 为什么会发生TCP粘包和拆包？

1. 发送方写入的数据大于套接字缓冲区的大小，此时发生拆包。
2. 发送方写入的数据小于套接字缓冲区大小，只有当收到确认包，才将分组发送给对端，当发送方收集了多个较小的分组，就会一起发送给对端，这将发生粘包。
3. 进行MSS（最大报文长度）大小的TCP分断，当TCP报文的数据部分大于MSS的时候将发生拆包。
4. 发送方发送的数据过快，接收方处理数据的速度赶不上发送方的速度，将将发生粘包。

• 常见解决办法

1. 在消息头部添加消息长度字段，服务器获取消息头的时候解析消息长度，然后向后读取响应长度的内容。
2. 固定消息数据的长度，当消息不够长时，空位补上。（但是会浪费网络资源）
3. 设置消息边界，也可以理解成为分隔符。

5.21 SYN Flood是什么？

SYN Flood是典型的DoS（拒绝服务）攻击，其目的是通过消耗服务器所有可用资源使服务器无法用于处理合法请求。通过重复发送初始链接请求（SYN)数据报，攻击者能够压倒目标服务器上所有可用端口，导致目标设备不响应合法请求。

5.22 为什么服务器易受到SYN攻击？

SYN泛洪攻击，其实这个攻击主要利用的就是TCP三次握手机制的缺陷。

A（攻击者）发送TCP SYN，SYN是TCP三次握手中的第一个数据包，而当这个服务器返回ACK以后，A不再进行确认，那这个连接就处在了一个挂起的状态，也就是半连接的意思，那么服务器收不到再确认的一个消息，还会重复发送ACK给A。这样就造成了服务器的大量资源浪费，导致服务器崩溃。

优化方式：

• 缩短SYN Timeout时间 ,使得主机尽快释放半连接的占用或者采用SYN cookie设置
• 记录IP，若连续受到某个IP的重复SYN报文，从这个IP地址来的包会被一概丢弃。

5.23 TCP如何实现长连接？

• 应用层的心跳机制：服务器给每一个连接设置一个Timer，一定时间内给客户端发送一个心跳数据包，若没收到客户端的回应，就判定与客户端掉线。
• TCP的keep-alive机制：其实跟心跳机制大同小异，无论是客户端还是服务器端，只要有一方开启Keepalive功能后，就会在特定的时间段内发送心跳包，对端在收到心跳包后进行回复，表示自己在线。

5.24 你了解流量控制原理吗？

• 目的是接收方通过TCP头窗口字段告知发送方本方可接收的最大数据量，用以解决发送速率过快导致接收方不能接收的问题。所以流量控制是点对点控制。
• TCP是双工协议，双方可以同时通信，所以发送方接收方各自维护一个发送窗和接收窗。
• 发送窗内数据只有当接收到接收端某段发送数据的ACK响应时才移动发送窗，左边缘紧贴刚被确认的数据。接收窗也只有接收到数据且最左侧连续时才移动接收窗口。

6. 应用层

6.1 HTTP头部包含哪些信息？

HTTP头部本质上是一个传递额外重要信息的键值对。主要分为：通用头部，请求头部，响应头部和实体头部。

6.2 说一下一次完整的HTTP请求包括哪些内容？

• 域名解析
• 建立客户端与服务器的连接，这个阶段包括TCP三次握手
• 建立链接后，客户端向服务器发送HTTP请求报文
• 服务器收到后，进行解析，并发送HTTP响应报文
• 浏览器得到html代码、js、css、图片等资源，进行解析，对界面进行渲染并呈现给用户

6.3 你知道DNS是什么吗？

DNS是域名系统，因特网上作为域名和IP地址相互映射的一个分布式数据库，能够使用户更方便地访问互联网，而不用去记很复杂的IP数字串。

通过主机名，最终得到该主机名对应的IP地址的过程叫做域名解析。

6.4 DNS的工作原理？

将主机域名转换为IP地址，属于应用层协议，使用UDP传输。

域名解析有两种方式：递归查询和递归与迭代相结合的查询。

一、主机向本地域名服务器的查询一般都采用递归查询。

二、本地域名服务器向根域名服务器、顶级域名服务器、权限域名服务器的查询为迭代查询。

具体解析过程

• 请求一旦发起，若是chrome浏览器，先在浏览器找之前有没有缓存过的域名所对应的ip地址，有的话，直接跳过dns解析了，若是没有，就会找硬盘的hosts文件，看看有没有，有的话，直接找到hosts文件里面的ip
• 如果本地的hosts文件没有能得到对应的ip地址，浏览器会发出一个dns请求到本地dns服务器，本地dns服务器一般都是你的网络接入服务器商提供，比如中国电信，中国移动等。
• 查询你输入的网址的DNS请求到达本地DNS服务器之后，本地DNS服务器会首先查询它的缓存记录，如果缓存中有此条记录，就可以直接返回结果，此过程是递归的方式进行查询。如果没有，本地DNS服务器还要向DNS根服务器进行查询。
• 本地DNS服务器继续向域服务器发出请求，在这个例子中，请求的对象是.com域服务器。.com域服务器收到请求之后，也不会直接返回域名和IP地址的对应关系，而是告诉本地DNS服务器，你的域名的解析服务器的地址。
• 最后，本地DNS服务器向域名的解析服务器发出请求，这时就能收到一个域名和IP地址对应关系，本地DNS服务器不仅要把IP地址返回给用户电脑，还要把这个对应关系保存在缓存中，以备下次别的用户查询时，可以直接返回结果，加快网络访问。

6.5 为什么DNS采用UDP协议？

因为UDP快，UDP的DNS协议只要一个请求、一个应答就好了。

而如果使用TCP，需要三次握手、发送数据以及应答、四次挥手，很耗时，且DNS只发送IP地址，数据较短，一半都不超过512字节（UDP的限制），所以用UDP传输即可。

6.6 为什么区域传送用TCP协议？

因为TCP可靠性好，若用UDP容易丢失。而且传输的内容较多，UDP有512字节的限制，所以用TCP比较好。

6.7 HTTP长连接和短连接的区别？

在HTTP/1.0中默认使用短连接。也就是说，客户端和服务器没进行一个HTTP操作，就建立一次连接，任务结束就断开连接。

而从HTTP/1.1开始，默认使用长连接，用以保持连接特性。

6.8 为什么服务器会有缓存这一项功能？怎么实现的？

• 原因
  • 缓解服务器压力
  • 降低客户端获取资源的延迟：缓存通常位于内存中，读取缓存的速度更快。并且缓存服务器在地理位置上也有可能比源服务器来得近，例如浏览器缓存。
• 实现方法
  • 让代理服务器进行缓存
  • 让客户端浏览器进行缓存

6.9 GET和POST的区别，你知道哪些？

• get把请求的数据放在url上，用?分割url和传输数据，参数之间用&连接，所以get不太安全，而post把数据放在HTTP实体主体里面，相对安全一点。

• get提交的数据最大是2K（限制实际上取决于服务器），post理论上没有限制。

• GET产生一个TCP数据报，浏览器会把http header和data一起发出去，服务器响应200；POST产生两个TCP数据报，浏览器先发送header实体头，服务器响应100 continue，浏览器再发送data实体主体，服务器响应200 OK

• GET请求会被浏览器主动缓存，而POST不会，因为每一次POST请求都不同

• 本质区别：GET是幂等的，而POST不是幂等的（幂等性是指一次和多次请求某一个资源应该具有同样的副作用。简单来说意味着对同一URL的多个请求应该返回同样的结果。）

  正因为它们有这样的区别，所以不应该且不能用get请求做数据的增删改这些有副作用的操作。因为get请求是幂等的，在网络不好的隧道中会尝试重试。如果用get请求增数据，会有重复操作的风险，而这种重复操作可能会导致副作用（浏览器和操作系统并不知道你会用get请求去做增操作）。

6.10 一个TCP连接可以对应几个HTTP请求？

如果采用长连接，一个TCP连接可以发送多个HTTP请求。

6.11 再浏览器地址栏输入一个URL后回车，背后会进行哪些技术步骤？

就是DNS步骤+浏览器渲染，具体可以看上面。

大致就是查浏览器->查本地->用ARP查同一个子网->查本地DNS服务器…获取到IP后，进行TCP连接，开始通信，之后浏览器渲染。

如果不是http协议，服务器会返回一个5开头的的重定向消息，告诉我们用的是https，那就是说IP没变，但是端口号从80变成443了，好了，再四次挥手，完事；再来一遍，这次除了上述的端口号从80变成443之外，还会采用SSL的加密技术来保证传输数据的安全性，保证数据传输过程中不被修改或者替换之类的，这次依然是三次握手，沟通好双方使用的认证算法，加密和检验算法，在此过程中也会检验对方的CA安全证书。

6.12 HTTPS和HTTP的区别？

1. HTTP协议传输的数据都是未加密的，也是明文，因此使用HTTP传输隐私信息非常不安全，HTTPS是由SSL+HTTP协议构成得到可进行加密传输、身份认证的网络协议，要比HTTP安全。
2. HTTPS需要到ca申请证书，一般免费证书很少，因而需要一定的费用。
3. HTTP和HTTPS使用的是完全不用的连接方式，用的端口也不一样，前者是80，后者是443。

6.13 什么是SSL/TLS？

SSL代表安全套接字层。它是一种用于加密和验证应用程序（如浏览器）和Web服务器之间发送的数据的协议。 身份验证 ， 加密Https的加密机制是一种共享密钥加密和公开密钥加密并用的混合加密机制。

SSL/TLS协议作用：认证用户和服务，加密数据，维护数据的完整性的应用层协议加密和解密需要两个不同的密钥，故被称为非对称加密；加密和解密都使用同一个密钥的

对称加密：优点在于加密、解密效率通常比较高 ，HTTPS 是基于非对称加密的， 公钥是公开的

6.14 HTTPS是如何保证数据传输的安全，整体流程是怎样的？(SSL是怎么工作保证安全的)

（1）客户端向服务器端发起SSL连接请求；（2） 服务器把公钥发送给客户端，并且服务器端保存着唯一的私钥 （3）客户端用公钥对双方通信的对称秘钥进行加密，并发送给服务器端 （4）服务器利用自己唯一的私钥对客户端发来的对称秘钥进行解密， （5）进行数据传输，服务器和客户端双方用公有的相同的对称秘钥对数据进行加密解密，可以保证在数据收发过程中的安全，即是第三方获得数据包，也无法对其进行加密，解密和篡改。

因为数字签名、摘要是证书防伪非常关键的武器。 “摘要”就是对传输的内容，通过hash算法计算出一段固定长度的串。然后，通过发送方的私钥对这段摘要进行加密，加密后得到的结果就是“数字签名”

SSL/TLS协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。

补充：SSL/TLS的四次握手，目前网上的主流答案都在重复阮一峰老师的博客，属于TLS 1.0版本的答案，使用RSA密钥交换算法。但是现在TLS 1.2已经成为主流，使用ECDHE算法，如果面试可以说出这个版本的答案，应该会更好。

6.15 HTTP请求和响应报文有哪些字段？

请求报文

• 请求行：Request Line
• 请求头：Request Headers
• 请求体：Request Body

响应报文

• 状态行：Status Line
• 响应头：Response Headers
• 响应体：Response Body

6.16 Cookie是什么？

HTTP是无状态的，主要是为了让HTTP协议尽可能简单，使得它能够处理大量事务，HTTP/1.1引入Cookie来保存状态信息。

Cookie 是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器之后向同一服务器再次发起请求时被携带上，用于告知服务端两个请求是否来自同一浏览器。由于之后每次请求都会需要携带 Cookie 数据，因此会带来额外的性能开销（尤其是在移动环境下）。

cookie 的出现是因为 HTTP 是无状态的一种协议，换句话说，服务器记不住你，可能你每刷新一次网页，就要重新输入一次账号密码进行登录。这显然是让人无法接受的，cookie 的作用就好比服务器给你贴个标签，然后你每次向服务器再发请求时，服务器就能够 cookie 认出你。

抽象地概括一下：一个 cookie 可以认为是一个「变量」，形如 name=value，存储在浏览器；一个 session 可以理解为一种数据结构，多数情况是「映射」（键值对），存储在服务器上。

6.17 Cookie有什么用途？

• 会话状态管理（如用户登录状态、购物车、游戏分数或其它需要记录的信息）
• 个性化设置（如用户自定义设置、主题等）
• 浏览器行为跟踪（如跟踪分析用户行为等）

6.18 Session的工作原理是什么？

客户端登陆完成之后，服务器会创建对应的session，session创建完毕后，会把session的id发送给客户端，存储到浏览器。这也客户端每次访问服务器，都会带着sessionid，服务器拿到sessionid后，在内存找到与之对应的session这样就可以正常工作了。

6.19 Cookie和Session的对比

• Session

Session是服务器保持状态的方法。

Session保存在服务器上。我们可以理解为每个用户有一个独一无二的Session，用户在客户端上记录用户的操作。 ID作为Session文件的Hash键，通过这个值可以锁定具体的Session结构的数据，这个Session结构中存储了用户操作行为。

• Cookie

Cookie是客户端保持状态的方法。Cookie简单的理解就是存储由服务器发至客户端并由客户端保存的一段字符串。为了保持会话，服务器可以在响应客户端请求时将Cookie字符串放在Set-Cookie下，客户机收到Cookie之后保存这段字符串，之后再请求时候带上Cookie就可以被识别。

当服务器需要识别客户端时就需要结合Cookie了。第一次创建Session的时候，服务端会在HTTP协议中告诉客户端，需要在Cookie里面记录一个Session ID，以后每次请求把这个会话ID发送给服务器，这样我就知道你是什么。

6.20 SQL注入攻击了解吗？

攻击者在HTTP请求中注入恶意的SQL代码，例如在最后加入1 = 1，就会出现 select * from user where name = ‘lianggzone’ and password = ‘’ or ‘1’=‘1’ 不管用户名和密码是什么内容，使查询出来的用户列表不为空。

防治措施：

Web端

1）有效性检验。 2）限制字符串输入的长度。

服务端

1. 不用拼接SQL字符串。

2. 使用预编译的PrepareStatement。

3. 有效性检验。(为什么服务端还要做有效性检验？第一准则，外部都是不可信的，防止攻击者绕过Web端请求)

4. 过滤SQL需要的参数中的特殊字符。比如单引号、双引号。

6.21 session 和 cookie 有什么区别？

1. 存储位置不同：session 存储在服务器端；cookie 存储在浏览器端。
2. 安全性不同：cookie 安全性一般，在浏览器存储，可以被伪造和修 改。
3. 容量和个数限制：cookie 有容量限制，每个站点下的 cookie 也有 个数限制。
4. 存储的多样性：session 可以存储在 Redis 中、数据库中、应用程 序中；而 cookie 只能存储在浏览器中。

6.22 使用Session的过程是怎样的？

• 用户进行登录时，用户提交包含用户名和密码的表单，放入 HTTP 请求报文中；
• 服务器验证该用户名和密码，如果正确则把用户信息存储到 Redis 中，它在 Redis 中的 Key 称为 Session ID；
• 服务器返回的响应报文的 Set-Cookie 首部字段包含了这个 Session ID，客户端收到响应报文之后将该 Cookie 值存入浏览器中；
• 客户端之后对同一个服务器进行请求时会包含该 Cookie 值，服务器收到之后提取出 Session ID，从 Redis 中取出用户信息，继续之前的业务操作。

6.23 Session和Cookie应该如何去选择（适用场景）？

• Cookie 只能存储 ASCII 码字符串，而 Session 则可以存储任何类型的数据，因此在考虑数据复杂性时首选 Session；
• Cookie 存储在浏览器中，容易被恶意查看。如果非要将一些隐私数据存在 Cookie 中，可以将 Cookie 值进行加密，然后在服务器进行解密；
• 对于大型网站，如果用户所有的信息都存储在 Session 中，那么开销是非常大的，因此不建议将所有的用户信息都存储到 Session 中。

6.24 DDos攻击了解吗？

客户端向服务器发送请求连接数据报，服务端回复确认数据包，但客户端不向服务器发送确认数据包，服务器一直等待客户端的确认，耗费资源，使服务器崩溃。

预防：

1. 限制同时打开SYN半连接的数目
2. 缩短SYN半连接的Time out时间
3. 关闭不必要的服务

6.25 MTU和MSS分别是什么？

MTU：最大传输单元，由硬件决定，如以太网的MTU为1500字节。

MSS：最大分节大小，为TCP数据包每次传输的最大数据分段大小，一般由发送端向对端TCP通知对端在每个分节中能发送的最大TCP数据。MSS值为MTU值减去IPv4 Header(20 Byte)和TCP header(20 Byte)得到。

6.26 HTTP中有个缓存机制，如何保证缓存是最新的呢？

max-age 指令出现在请求报文，并且缓存资源的缓存时间小于该指令指定的时间，那么就能接受该缓存。

max-age 指令出现在响应报文，表示缓存资源在缓存服务器中保存的时间。

Cache-Control: max-age=31536000

6.27 常见的TCP连接状态有哪些？

• CLOSED：初始状态。
• LISTEN：服务器处于监听状态。
• SYN_SEND：客户端socket执行CONNECT连接，发送SYN包，进入此状态。
• SYN_RECV：服务端收到SYN包并发送服务端SYN包，进入此状态。
• ESTABLISHED：表示连接建立。客户端发送了最后一个ACK包后进入此状态，服务端接收到ACK包后进入此状态。
• FIN_WAIT_1：终止连接的一方（通常是客户机）发送了FIN报文后进入。等待对方FIN。
• CLOSE_WAIT：（假设服务器）接收到客户机FIN包之后等待关闭的阶段。在接收到对方的FIN包之后，自然是需要立即回复ACK包的，表示已经知道断开请求。但是本方是否立即断开连接（发送FIN包）取决于是否还有数据需要发送给客户端，若有，则在发送FIN包之前均为此状态。
• FIN_WAIT_2：此时是半连接状态，即有一方要求关闭连接，等待另一方关闭。客户端接收到服务器的ACK包，但并没有立即接收到服务端的FIN包，进入FIN_WAIT_2状态。
• LAST_ACK：服务端发动最后的FIN包，等待最后的客户端ACK响应，进入此状态。
• TIME_WAIT（2MSL)：客户端收到服务端的FIN包，并立即发出ACK包做最后的确认，在此之后的2MSL时间称为TIME_WAIT状态。

6.28 TCP头部字段有哪些？

• ACK：确认字段
• SYN：建立TCP连接标志位
• FIN：断开连接标识

6.29 什么是半连接队列？

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

当然还有一个全连接队列，就是已经完成三次握手，建立起连接的就会放在全连接队列中。如果队列满了就有可能会出现丢包现象。

6.30 三次握手过程中可以携带数据吗？

只有第三次可以携带数据。

如果第一次握手可以携带数据，那么攻击者在第一次握手中的SYN报文放入大量数据，会让服务器花费很多时间、内存空间来接收这些报文。而对于第三次的话，此时客户端已经处于 ESTABLISHED 状态。对于客户端来说，他已经建立起连接了，并且也已经知道服务器的接收、发送能力是正常的了，所以能携带数据也没啥毛病。

6.31 SYN攻击是什么？

服务器端的资源分配是在二次握手时分配的，而客户端的资源是在完成三次握手时分配的，所以服务器容易受到SYN洪泛攻击。SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server则回复确认包，并等待Client确认，由于源地址不存在，因此Server需要不断重发直至超时，这些伪造的SYN包将长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络拥塞甚至系统瘫痪。SYN 攻击是一种典型的 DoS/DDoS 攻击。

如果一个服务器上有大量的半连接状态，那么就说明该服务器遭到了SYN攻击。

防御方法

• 缩短超时时间
• 增加最大半连接数
• 过滤网关保护
• SYN cookies技术

6.32 TCP粘包拆包问题是什么？你会如何解决它？

TCP粘包：是指发送方发送的若干包数据到接收方接收时粘成一包，从接收缓冲区看，后一包数据的头紧接着前一包数据的尾。

TCP拆包：假如发送方发送了2个TCP报文段，接收方也接收到了2个报文段，但是收到的第一个TCP报文段中粘上了发送方发送的第2个报文段的一部分，这其实就是对第2个TCP报文段的拆包，同样接收方应用程序也无法处理和区分

粘包和拆包问题的解决方法

1. 消息定长，通过固定每次发送的数据长度，然后接收方同样就以这个长度作为分界来区分前后两个不同的包
2. 加包头，为每一个要数据添加一个2字节或4字节的长度标识，接收方程序每次先读取该长度，然后再读取相应数目的数据
3. 尾部添加标记序列，比如'\n' '\t'等