计算机网络面试真题

HTTP 哪些常用的状态码及使用场景？

状态码分类

• 1xx：表示目前是协议的中间状态，还需要后续请求

• 2xx：表示请求成功

• 3xx：表示重定向状态，需要重新请求

• 4xx：表示请求报文错误

• 5xx：服务器端错误

常用状态码

• 101：切换请求协议，从 HTTP 切换到 WebSocket
• 200：请求成功，有响应体
• 301：永久重定向：会缓存
• 302：临时重定向：不会缓存
• 304：协商缓存命中
• 403：服务器禁止访问
• 404：资源未找到
• 400：请求错误
• 500：服务器端错误
• 503：服务器繁忙

HTTP状态码301和302的区别

301重定向（301 Move Permanently），指页面永久性转移，表示为资源或页面永久性地转移到了另一个位置。

301是HTTP协议中的一种状态码，当用户或搜索引擎向服务器发出浏览请求时

• 服务器返回的HTTP数据流中头信息（header）中包含状态码 301 ，表示该资源已经永久改变了位置。

301与302的区别

• 301重定向是页面永久性转移

  • 搜索引擎在抓取新内容的同时也将旧的网址替换成重定向之后的网址

• 302重定向是页面暂时性转移

  • 搜索引擎会抓取新的内容而保存旧的网址并认为新的网址只是暂时的。

说一说三次握手

第一次握手：

• 客户端给服务器发送一个 SYN 报文。

第二次握手：

• 服务器收到 SYN 报文之后，会应答一个 SYN+ACK 报文。

第三次握手：

• 客户端收到 SYN+ACK 报文之后，会回应一个 ACK 报文。

服务器收到 ACK 报文之后，三次握手建立完成。

作用是为了确认双方的接收与发送能力是否正常。

三次握手的作用

• 确认双方的接受能力、发送能力是否正常。

• 指定自己的初始化序列号，为后面的可靠传送做准备。

什么是半连接队列

• 服务器第一次收到客户端的 SYN 之后，就会处于 SYN_RCVD 状态，此时双方还没有完全建立其连接
• 服务器会把此种状态下请求连接放在一个队列里，我们把这种队列称之为半连接队列。
  • 当然还有一个全连接队列，就是已经完成三次握手，建立起连接的就会放在全连接队列中。
    • 如果队列满了就有可能会出现丢包现象。

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

第三次握手的时候，是可以携带数据的。

• 也就是说，第一次、第二次握手不可以携带数据，而第三次握手是可以携带数据的。

假如第一次握手可以携带数据的话，如果有人要恶意攻击服务器

• 那他每次都在第一次握手中的 SYN 报文中放入大量的数据

• 因为攻击者根本就不理服务器的接收、发送能力是否正常，然后疯狂着重复发 SYN 报文的话

  • 这会让服务器花费很多时间、内存空间来接收这些报文。
  • 也就是说，第一次握手可以放数据的话，其中一个简单的原因就是会让服务器更加容易受到攻击了。

而对于第三次的话，此时客户端已经处于 established 状态

• 也就是说，对于客户端来说，他已经建立起连接了，并且也已经知道服务器的接收、发送能力是正常的了
  • 所以能携带数据页没啥毛病。

说一说四次挥手

第一次挥手：

• 客户端发送一个 FIN 报文，报文中会指定一个序列号。
  • 此时客户端处于FIN_WAIT1状态。
    • （相当于客户端告诉服务端，我想断开链接了）

第二次挥手：

• 服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 + 1 作为 ACK 报文的序列号值
  • 表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT状态。
    • （相当于，服务端告诉客户端，好的，我收到你的断开请求了）

第三次挥手：

• 如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。
  • 此时服务端处于 LAST_ACK 的状态。

第四次挥手：

• 客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 + 1 作为自己 ACK 报文的序列号值
  • 此时客户端处于 TIME_WAIT 状态。
  • 需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态

服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。

为什么客户端发送 ACK 之后不直接关闭，而是要等一阵子才关闭。

• 要确保服务器是否已经收到了我们的 ACK 报文，如果没有收到的话，服务器会重新发 FIN 报文给客户端
• 客户端再次收到 FIN 报文之后，就知道之前的 ACK 报文丢失了，然后再次发送 ACK 报文。

至于 TIME_WAIT 持续的时间至少是一个报文的来回时间。

• 一般会设置一个计时，如果过了这个计时没有再次收到 FIN 报文
  • 则代表对方成功就是 ACK 报文，此时处于 CLOSED 状态。

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

为了保证 A 发送的最后一个 ACK 报文段能够到达 B。

• A 发送的 ACK 报文段有可能丢失，因而使处在 LAST-ACK 状态的 B 收不到对方已发送的 FIN + ACK 报文段的确认。
  • 这时 B 会超时重传这个 FIN+ACK 报文段
    • 而 A 就能在 2MSL 时间内（超时 + 1MSL 传输）收到这个重传的 FIN+ACK 报文段。
    • 接着 A 重传一次 ACK 报文确认，并且重新启动 2MSL 计时器。

最后，A 和 B 都正常进入到 CLOSED 状态。如果 A 在 TIME-WAIT 状态不等待一段时间

• 而是在发送完 ACK 报文段后立即释放连接，那么就无法收到 B 重传的 FIN + ACK 报文段
• 因而也不会再发送一次确认报文段，这样，B 就无法按照正常步骤进入 CLOSED 状态。

防止已失效的连接请求报文段出现在本连接中。

• A 在发送完最后一个 ACK 报文段后，再经过时间 2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。
  • 这样就可以使下一个连接中不会出现这种旧的连接请求报文段。

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

URL解析：

• 浏览器首先会解析你输入的URL，确定你要访问的是哪个网站
  • 这个网站的地址（IP地址）是什么，以及你请求访问该网站的具体页面路径。

DNS查询：

• 如果浏览器缓存或系统缓存中没有该域名的IP地址
  • 那么浏览器将发送一个请求到DNS（域名系统）服务器，来查找对应的IP地址。

建立连接：

• 找到IP地址后，浏览器会向该地址发送一个TCP连接请求，这个过程通常被称为TCP的三次握手。

发送HTTP请求：

• 一旦TCP连接被建立，浏览器就可以通过这个连接向服务器发送HTTP请求了。
  • 这个请求里会包含你要获取的资源类型，所使用的HTTP版本，以及可能的一些其他信息。

服务器处理请求并返回HTTP响应：

• 服务器接收到HTTP请求后，进行处理，然后返回一个HTTP响应
  • 响应中包含了要访问的网页的内容，以及一些描述信息，如状态码、内容类型等。

浏览器解析HTML：

• 浏览器接收到服务器的响应数据后，开始解析HTML，构建DOM树。

资源加载：

• 在解析HTML的过程中，如果遇到CSS、JavaScript文件或者图片等资源，浏览器会再次发送HTTP请求去获取。

浏览器渲染页面：

• 在获取到所有的资源文件后，浏览器开始渲染页面，将资源文件转化为网页上的可视、可交互的内容。

关闭连接：

• 如果HTTP头部中的Connection字段的属性被设置为close，那么浏览器和服务器的TCP连接在传输完成后将会被关闭。
  • 如果设置为keep-alive，那么TCP连接会被保持一段时间，以便传输更多的请求。

以上就是在浏览器中输入URL地址到显示主页的过程

• 这个过程可能会涉及到网络协议（如DNS、HTTP、TCP/IP等）的一系列操作

什么是 Session?

Session（会话）是指在客户端和服务器之间建立的一种会话状态。

• 通过会话，服务器可以在不同请求之间识别和跟踪特定的客户端，并保持与客户端的交互状态。

在Web应用中，Session通常使用一种名为Session ID的机制来实现。

当客户端首次访问服务器时，服务器会为此客户端生成一个唯一的Session ID

• 并将其存储在服务器端的存储介质（如内存、数据库、文件）中，同时将该Session ID发送给客户端保存在Cookie中。

客户端在后续的请求中，会将存储在Cookie中的Session ID自动带上，供服务器在接收到请求时进行识别。

• 然后，服务器根据Session ID找到相应的会话数据，使得服务器能够识别特定的客户端并维持会话状态。

会话通常用于以下目的：

跟踪用户：

• 通过Session ID，服务器可以记录和存储与特定用户相关的信息，如登录状态、权限、购物车内容等。
  • 这样，在用户在同一网站上的不同页面之间，服务器能够保持用户的状态和数据的一致性。

用户验证和安全：

• Session可以用于验证用户身份，确保只有经过身份验证的用户才能访问特定资源。
  • 服务器可以在会话中存储一些敏感信息，如用户ID、角色等，以验证用户的权限和身份。

数据共享：

• Session使得服务器能够在不同请求之间共享和传递数据。
  • 服务器可以将一些重要的数据存储在会话中，以便在后续请求中使用，而不需要每次都重新获取或计算。

需要注意的是，会话数据通常存储在服务器端，可以在一段时间后过期或被销毁。

• 同时，会话的安全性也是重要的，敏感数据应该进行加密和保护，防止被恶意窃取。

总的来说，Session是一种在客户端和服务器之间建立的会话状态

• 通过Session ID进行识别和跟踪客户端，实现用户的会话管理、身份验证和数据共享。

什么是 Cookie?

Cookie是一种在客户端（浏览器）和服务器之间交换的小型数据文件。

它由服务器生成并发送给客户端，然后客户端保存在本地的浏览器中。

• 每次浏览器向同一服务器发送请求时，会将相应的Cookie信息附加在请求头中一起发送给服务器。

Cookie主要用于记录和追踪与用户相关的信息，以实现以下功能：

会话管理：

• 通过使用会话Cookie，服务器可以在用户的多个请求之间维持会话状态。
  • 它使服务器能够识别特定用户，并保持用户登录状态，而不需要用户在每个请求中重新验证身份。

用户个性化：

• Cookie可以用于存储用户的个人喜好、偏好或设置等信息。
  • 例如，在某个电子商务网站上，可以使用Cookie来记录用户的购物车内容和偏好选项
    • 以便在用户下次访问时进行个性化推荐或还原购物车。

随机广告：

• Cookie可以用于进行广告跟踪和定向投放。
  • 广告商可以在用户访问某个网站时，通过Cookie记录用户的兴趣、浏览行为等信息
    • 然后根据这些信息显示与用户兴趣相关的广告。

记住用户：

• 通过在Cookie中存储持久性数据，网站可以实现 记住我 的功能，使用户在下次访问时不需要重新输入用户名和密码。

• 需要注意的是，Cookie是存储在用户本地的浏览器中，它可能包含敏感信息，因此在使用Cookie时需要注意安全性。

  • 同时，用户也可以通过浏览器的设置来管理和删除存储的Cookie。

总的来说，Cookie是一种用于在客户端和服务器之间传递数据的机制

• 主要用于会话管理、用户个性化、广告跟踪等功能，以提供更好的用户体验和个性化服务。

Cookie和Session有什么区别？

Cookie和Session主要有以下几点区别：

存储位置：

• Cookie数据存储在客户端（浏览器），而Session数据存储在服务器端。
  • 因此，从保护用户数据的角度来看，Session比Cookie更安全。

生命周期：

• 通常情况下，Cookie有固定的过期时间，除非用户手动清理否则不会消失，即使关闭浏览器或重启计算机也依然存在。
  • 而Session的生命周期通常是在用户关闭浏览器或者超出了设定的时间段后，服务器就会自动将其销毁。

大小限制：

• 由于Cookie数据存储在客户端，所以它有大小限制，一般为4KB左右。
  • 而Session是存储在服务器端，理论上其数据大小没有限制，但是如果存储过多的数据会增加服务器的负担。

数据类型限制：

• Cookie只能保存字符串类型的数据，对于复杂的数据结构需要进行序列化。
  • 而Session可以存储任何类型的数据，比如对象和数组等。

跨域问题：

• 基于安全性，Cookie不可以进行跨域名存储，每个域名下的Cookie数据是分开存储的。
  • 而Session技术没有这项限制。

总体来说，选择使用Cookie还是Session主要取决于具体的需求和应用场景。

IP 地址和 Mac 地址区别？

IP地址是逻辑地址，而MAC地址是物理地址。

IP地址是在网络层使用的地址：

• 用于标识网络上的主机或路由器
• IP地址是可变的，可以在网络上动态分配或更改
• IP地址是全球唯一的，由互联网号码分配机构（IANA）管理分配

MAC地址则是在数据链路层使用的地址：

• 用于标识网络上的网卡或其他物理设备。
• MAC地址是固定的，通常是出厂时设定的。
• MAC地址是由设备厂商分配，通常在设备生产时就已经固定。

IP地址和MAC地址都是用来标识设备的地址，但其用途和管理方式不同。

• 在实际应用中，IP地址通常用于网络间通信，而MAC地址用于局域网内部通信

说一说TCP与UDP的区别

TCP协议的主要特点

TCP是面向连接的传输层协议，所谓面向连接就是双方传输数据之前，必须先建立一条通道

• 例如三次握手就是建议通道的一个过程，而四次挥手则是结束销毁通道的一个其中过程
  • 而 UDP 则是无连接的传输协议。
• TCP 可以提供可靠的传输，比如数据丢失，超时，TCP 都会重传，并且数据包也能够按序到达
  • 而 UDP 是不可靠的，数据丢失了也不会重传等等。

从效率的角度讲，UDP 的效率更快，因为 UDP 不需要做诸如三次握手/四次挥手/重传等额外的消耗。

从应用场景角度讲，对信息的正确率要求比较高的可以采用 TCP 协议

• 比如我们平时常见的文字聊天
• 而允许出现小部分数据丢失的，则可以采用 UDP，比如视频聊天等。

像HTTP、HTTPS、FTP、TELNET、SMTP(简单邮件传输协议)协议基于可靠的TCP协议。

TFTP、DNS、DHCP、TFTP、SNMP(简单网络管理协议)、RIP基于不可靠的UDP协议。

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

TCP 对应的应用层协议

FTP：

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

Telnet：

• 它是一种用于远程登陆的端口，用户可以以自己的身份远程连接到计算机上

SMTP：

• 定义了简单邮件传送协议，现在很多邮件服务器都用的是这个协议，用于发送邮件。

POP3：

• 它是和 SMTP 对应，POP3 用于接收邮件。

HTTP：

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

UDP 对应的应用层协议

DNS：

• 用于域名解析服务，将域名地址转换为 IP 地址。DNS 用的是 53 号端口。

SNMP：

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

TFTP(Trival File Transfer Protocal)：

• 简单文件传输协议，该协议在熟知端口 69 上使用 UDP 服务。

什么是ICMP协议？

ICMP（Internet Control Message Protocol）是一种网络协议

• 它用于在 IP 网络中传递错误信息和控制消息。
  • ICMP 是在 IP 协议的基础上构建的协议，它是在网络层进行通信的。

ICMP 主要有两个作用：

提供网络的错误报告机制：

• 当在网络通信中发生错误或故障时，ICMP 可以生成错误报告，并将报告发送给源主机。
  • 比如，在路由选择失败、目标主机不可达或传输超时等情况下，会发送 ICMP 错误报告给源主机，通知发生了问题。

支持网络的控制消息：

• ICMP 还支持网络中的控制消息传递。
  • 例如，ICMP 可以用于执行网络探测和诊断，如发起 Ping 命令（Echo 请求和 Echo 响应）进行网络连通性测试。

常见的 ICMP 消息类型包括：

• Echo 请求和 Echo 响应：用于网络探测和连接测试。
• 目标不可达：当一个数据包无法到达目标时，发送此消息通知源主机。
• 超时：当数据包经过一定时间后未能到达目标，发送此消息通知源主机。
• 重定向：用于告知主机优化数据包的传输路径。
• 时间戳请求和时间戳响应：用于进行时间同步。

ICMP 是一种非常重要的网络协议，在 IP 网络中起着诊断和通信的作用。

• 它协助网络管理员调试和定位问题，在网络通信中起到检测和响应错误的作用，提高网络的可靠性和效率。

谈谈你对 ARQ 协议的理解？

ARQ 全称 Automatic Repeat reQuest，中文意思是 自动重传请求，然后这个其实有好几种

• 比如你可能听说过停等ARO，连续ARQ，回退N步ARO，容易混淆，所以下面先说一下他们的一个概念。

自动重传请求分成为三种：

• 即停等式(stop-and-wait）ARQ，回退n帧（go-back-n）ARQ，以及选择性重传（selective repeat）ARQ。

后两种协议是滑动窗口技术与请求重发技术的结合

• 由于窗口尺寸开到足够大时，帧在线路上可以连续地流动，因此又称其为连续ARQ协议。

所以我们又可以简单分成两种：

• 停止等待协议和连续 ARQ 协议，

停止等待协议是一种简单的 ARQ 协议，每当发送方发送一个数据包后，就会停止发送并等待接收方的确认信号。

• 只有收到确认信号后，发送方才会继续发送下一个数据包。
• 该协议的缺点是会浪费大量的时间在等待确认信号上。

连续 ARQ 协议是一种改进的 ARQ 协议，它可以在等待确认信号的同时，继续发送其他的数据包，可提高信道利用率。

大概就是：发送方维持一个发送窗口，凡位于发送窗口内的分组可以连续发送出去，而不需要等待对方确认。

• 接收方一般采用累计确认，对按序到达的最后一个分组发送确认，表明到这个分组为止的所有分组都已经正确收到了。

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

应答机制：

• TCP协议采用应答机制，即发送端每发送一个数据包就会等待接收端的确认应答。
• 如果发送端在规定时间内没有收到确认应答，就会重新发送数据包，直到接收到确认应答为止。

超时重传：

• 当发送端发送数据包后，在规定时间内没有收到确认应答，就会进行超时重传，重新发送该数据包。

数据校验：

• TCP协议使用校验和机制对数据包进行校验，以保证传输的数据包没有被篡改。
• 接收端在接收到数据包后，会对其进行校验，如果发现校验和错误，则会丢弃该数据包，并通知发送端进行重传。

滑动窗口：

• TCP协议采用滑动窗口机制来控制发送端的发送速度，以避免发送过快导致接收端处理不过来。
• 发送端根据接收端的反馈，动态调整发送窗口的大小，以达到最优的传输速率。

流量控制：

• TCP协议通过流量控制机制来限制发送端的发送速度，以避免网络拥塞。
• 接收端可以通过发送窗口的大小来告诉发送端自己的接收能力，从而控制发送端的发送速度。

拥塞控制：

• TCP协议通过拥塞控制机制来避免网络拥塞。发送端根据网络的拥塞程度来调整发送速度
  • 以避免过多的数据包在网络中造成拥塞。
• 同时，TCP协议还支持快速恢复和快速重传机制，以更快地适应网络拥塞的变化。

什么是流量控制？

TCP流量控制是一种内置于TCP协议的机制，用于防止发送方把接收方的缓冲区塞满，以避免数据丢失。

• 简单地说，就是保证发送者不会将数据发送得过快，导致接收者无法接收。

TCP流量控制的工作方式是每个TCP段都有一个窗口大小字段，这个字段告诉发送者接收端的可用缓冲区大小。

• 接收方通过更改这个窗口大小值来告诉发送方他还能接收多少数据。
• 如果接收方的缓冲区被填满了，它就会将窗口大小设置为0，这时发送方就会停止发送数据，直到接收方再次更新其窗口大小。

TCP 是如何实现流量控制的？

TCP实现流量控制主要依赖于滑动窗口机制。

滑动窗口不仅是一种流量控制手段，也是一种可靠传输的手段。

• 它的基本思想是：
  • 每个TCP连接都有两个窗口，一个是发送窗口，另一个是接收窗口。
    • 窗口大小是动态变化的。

发送窗口的大小由自己和接收方协商得出，不能超过接收窗口的大小。

• 当发送方发送数据时，会根据窗口的大小来确定可以发送的数据量。
• 当数据发送出去后，发送窗口就会向右滑动。

接收方在接收到数据后，会向发送方发送确认，确认号表示的是接收方期望接收的下一个数据字节的序号

• 同时还会告诉发送方自己的接收窗口大小。

如果接收方处理数据的速度慢，那么接收窗口的大小就会减小，甚至变为0

• 此时发送方就不能再发送数据，这样就实现了流量控制。

举个例子，假设你正在下载一个大文件，当你的硬盘写入速度跟不上网络下载速度时

• 你的计算机会告诉发送方减小发送窗口的大小，减慢发送数据的速度，这样你的硬盘就有足够的时间来处理这些数据。

什么是滑动窗口

TCP滑动窗口是TCP协议中实现流量控制和可靠传输的关键机制。

滑动窗口不仅可以防止发送端数据传输过快，以至于接收端处理不过来

• 还可以对丢失的数据包进行重传，以确保数据的可靠传输。

工作原理

在TCP连接中，每个方向上都有一个发送窗口和一个接收窗口。

• 窗口的大小是动态变化的，表示接收端目前还能接收的字节数。

当发送端发送数据时，发送的数据不能超过发送窗口的大小。

• 发送的数据被编号，放入发送窗口，并逐个发送出去。
• 每发送一个数据包，发送窗口就向右滑动一个数据包的距离。

接收端在接收到数据包后，会向发送端确认已接收到的数据包序号，并告诉发送端自己的接收窗口大小。

• 接收端的确认可以是累积的，也就是说，如果一次确认了多个数据包，那么需要通知的是最后一个接收到的数据包的序号。

发送端在收到确认后，会把确认的数据从发送窗口中移除

• 同时根据接收端告知的接收窗口的大小，调整自己的发送窗口大小。

• 然后发送窗口向右滑动，继续发送后面的数据包。

如果发送端没有收到接收端的确认，那么发送端就会重发该数据包。

• 这就是TCP协议如何保证数据的可靠传输的。

举例说明

假设你正在给一个朋友发送一封邮件。你的朋友告诉你他的邮箱只能接收5MB的数据。

• 所以你把邮件分成5个1MB的部分，每次只能发送1MB的数据。
• 你发完一部分后，你的朋友就会确认一下已经收到的部分，并告诉你他的邮箱还能接收多少数据。
• 你每次都根据他告诉你的可以接收的数据的大小，来发送下一部分的数据。这就是滑动窗口的工作原理。

讲一讲什么是TCP粘包和拆包？

TCP粘包和拆包是网络编程中常见的问题，主要是由于TCP的特性和网络环境的影响。

TCP粘包：

就是发送方发送的若干包数据到达接收方时被粘在一起，接收方看到的可能是一个大的数据包。

这主要是因为TCP是一个基于字节流的协议，没有边界。

• 另一个原因是为了提高网络的有效利用率，TCP会尽可能地将小的数据包合并到大的数据包中发送出去。

TCP拆包：

与TCP粘包相反，拆包是指发送方发送的一个大的数据包到达接收方时被拆成多个小的数据包。

这主要是因为TCP在传输数据时，如果数据包过大

• 会被分割成合适大小的小包进行发送，以适应网络的最大传输单元（MTU）。

举个例子

假设你正在发送一个大文件，比如一个1GB的电影。

由于网络的MTU限制，你不能一次性发送整个文件，所以你需要将文件拆分成多个小的数据包进行发送，这就是TCP拆包。

• 而在接收方，可能由于网络环境等因素，接收到的数据包可能会被粘在一起，形成一个大的数据包，这就是TCP粘包。

解决这个问题的常见方法是在应用层添加消息边界

• 比如使用特殊的分隔符，或者在消息头部添加长度字段，来标识每个消息的边界。

保活计时器的作用？

TCP 有一个保活计时器（keepalive timer）。

客户已主动与服务器建立了 TCP 连接。

• 但后来客户端的主机突然发生故障。
• 显然，服务器以后就不能再收到客户端发来的数据。
  • 因此，应当有措施使服务器不要再白白等待下去。这就需要使用保活计时器了。

服务器每收到一次客户的数据，就重新设置保活计时器，时间的设置通常是两个小时。

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

UDP 如何实现可靠传输？

UDP不属于连接协议，具有资源消耗少，处理速度快的优点，所以通常音频，视频和普通数据在传送时，使用UDP较多

• 因为即使丢失少量的包，也不会对接受结果产生较大的影响。

传输层无法保证数据的可靠传输，只能通过应用层来实现了。

• 实现的方式可以参照tcp可靠性传输的方式，只是实现不在传输层，实现转移到了应用层。

最简单的方式是在应用层模仿传输层TCP的可靠性传输。

下面不考虑拥塞处理，可靠UDP的简单设计。

• 添加seq/ack机制，确保数据发送到对端
• 添加发送和接收缓冲区，主要是用户超时重传。
• 添加超时重传机制。

送端发送数据时，生成一个随机seq=x，然后每一片按照数据大小分配seq。

数据到达接收端后接收端放入缓存，并发送一个ack=x的包，表示对方已经收到了数据。

发送端收到了ack包后，删除缓冲区对应的数据。

• 时间到后，定时任务检查是否需要重传数据。

目前有如下开源程序利用udp实现了可靠的数据传输。

• 分别为RUDP、RTP、UDT。

什么是 HTTP 长连接？

HTTP长连接（HTTP persistent connection）是指在一次HTTP请求和响应完成后，保持TCP连接不关闭

• 以便后续的HTTP请求可以继续在同一个连接上发送和接收数据。

在传统的HTTP/1.0版本中，每次请求完成后，TCP连接都会被关闭，下次请求需要重新建立连接，这种方式称为短连接。

• 而在HTTP/1.1版本中，引入了持久连接的概念，也就是HTTP长连接。

HTTP长连接的主要优势在于减少了TCP连接建立和关闭的开销，提高了性能和效率。

• 相比于短连接，HTTP长连接可以避免频繁地进行握手和挥手操作，节省了网络资源和服务器端的负担。

通过HTTP长连接，客户端和服务器之间可以在同一个TCP连接上发送多个HTTP请求和接收多个HTTP响应

• 而不需要每次都重新建立连接。

• 这样可以减少延迟，提高响应速度，特别适用于同时请求多个资源，或在一个页面中含有多个嵌入资源的情况。

需要注意的是，HTTP长连接并不会一直保持不断开，它有一个超时时间。

如果在一段时间内没有新的请求发送，服务器可能会主动关闭连接，或者客户端也可以选择关闭连接。

• 同时，服务器端和客户端都可以通过Connection头字段中的选项来控制是否启用长连接。

HTTP长连接是一种通过保持TCP连接的方式，在一次连接上进行多次请求和响应的机制，以提高性能和效率。

HTTP 常见方法有哪些？

HTTP（超文本传输协议）常见的请求方法有以下几种：

• GET：用于请求服务器返回指定资源的数据。

  • 通常用于获取或查看资源，GET请求不应该对服务器的状态产生任何影响。

• POST：用于向服务器提交数据，请求服务器处理请求中的数据。

  • 通常用于提交表单数据、上传文件或者执行某些会修改服务器状态的操作。

• PUT：用于向服务器上传或更新资源，请求服务器存储请求中的数据。

  • 通常用于更新或上传文件等操作。

• DELETE：用于请求服务器删除指定的资源。

  • 通常用于删除服务器上的文件或者数据。

• HEAD：类似于GET请求，但不返回具体的资源数据，而只返回资源的元信息（例如响应头部）

  • 用于获取资源的元信息而不获取实际的资源内容。

• OPTIONS：查询服务器支持的HTTP方法。

  • 客户端可以使用OPTIONS方法来获取服务器所支持的HTTP方法列表。

• TRACE：用于向服务器发送一个请求，服务器将此请求返回给客户端，用于追踪请求的路径。

这些HTTP请求方法在实际的应用中常常被用于不同的操作场景和业务需求中

• 比如GET用于获取数据，POST用于提交数据等。

开发者可以根据实际需求选择合适的HTTP请求方法来进行数据交互

说一说HTTP1.0，1.1，2.0 的区别

HTTP/1.0

HTTP/1.0规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接

• 服务器完成请求处理后立即断开TCP连接，服务器不跟踪每个客户也不记录过去的请求。

这种方式就好像我们打电话的时候，只能说一件事儿一样

• 说完之后就要挂断，想要说另外一件事儿的时候就要重新拨打电话。

HTTP/1.0中浏览器与服务器只保持短暂的连接，连接无法复用。

也就是说每个TCP连接只能发送一个请求。

• 发送数据完毕，连接就关闭，如果还要请求其他资源，就必须再新建一个连接。

我们知道TCP连接的建立需要三次握手，是很耗费时间的一个过程。

• 所以，HTTP/1.0版本的性能比较差。

HTTP/1.1

相比较于HTTP/1.0来说，最主要的改进就是引入了持久连接。

• 所谓的持久连接即TCP连接默认不关闭，可以被多个请求复用。

由于之前打一次电话只能说一件事儿，效率很低。

• 后来人们提出一种想法，就是电话打完之后，先不直接挂断，而是持续一小段时间
  • 这一小段时间内，如果还有事情沟通可以再次进行沟通。

客户端和服务器发现对方一段时间没有活动，就可以主动关闭连接。

• 或者客户端在最后一个请求时，主动告诉服务端要关闭连接。

HTTP/1.1版还引入了管道机制（pipelining），即在同一个TCP连接里面，客户端可以同时发送多个请求。

• 这样就进一步改进了HTTP协议的效率。

有了持久连接和管道，大大的提升了HTTP的效率。

• 但是服务端还是顺序执行的，效率还有提升的空间。

HTTP/2

HTTP/2 为了解决HTTP/1.1中仍然存在的效率问题，HTTP/2 采用了多路复用。

• 即在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，而且不用按照顺序一一对应。
• 能这样做有一个前提，就是HTTP/2进行了二进制分帧
  • 即 HTTP/2 会将所有传输的信息分割为更小的消息和帧（frame），并对它们采用二进制格式的编码。

也就是说，老板可以同时下达多个命令，员工也可以收到了A请求和B请求，于是先回应A请求，结果发现处理过程非常耗时

• 于是就发送A请求已经处理好的部分， 接着回应B请求，完成后，再发送A请求剩下的部分。
• A请求的两部分响应在组合到一起发给老板。

而这个负责拆分、组装请求和二进制帧的一层就叫做二进制分帧层。

• 除此之外，还有一些其他的优化，比如做Header压缩、服务端推送等。

Header压缩就是压缩老板和员工之间的对话。

服务端推送就是员工事先把一些老板可能询问的事情提现发送到老板的手机（缓存）上。

• 这样老板想要知道的时候就可以直接读取短信（缓存）了。

目前，主流的HTTP协议还是HTTP/1.1 和 HTTP/2。

• 并且各大网站的HTTP/2的使用率也在逐年增加。

DNS 解析 优化手段？

DNS缓存：

• DNS缓存是本地DNS服务器和浏览器中的一种机制，用于缓存已解析的域名和对应的IP地址。
  • 当再次访问相同域名时，可以直接从缓存中获取IP地址，避免重复查询和延迟。

域名预取：

• 浏览器可以在用户点击链接之前提前解析网页中的链接中的域名，将这些域名解析为IP地址并缓存起来。
  • 这样当用户点击链接时，可以立即建立连接，减少等待时间

HTTP 和 HTTPS 的区别？

HTTP和HTTPS用于在客户端和服务器之间传输数据的方式。

它们之间的主要区别在于以下几个方面：

安全性：

• HTTP是明文传输的协议，数据并没有经过加密，容易被窃听、篡改或其他安全风险。
• HTTPS通过使用SSL（安全套接层）或TLS（传输层安全）协议对HTTP进行加密
  • 确保数据在传输过程中的安全性和完整性。
  • 这样，即使被截获的数据也无法被解读和篡改。

端口号：

• HTTP默认使用端口号80进行通信。
• HTTPS默认使用端口号443进行通信。

证书：

• HTTPS使用数字证书对网站的身份进行认证。
  • 证书由可信的第三方机构颁发，用于证明服务器是可信的，并且可以用来加密和解密通信过程中的数据。
• HTTP不需要证书，任何人都可以发送HTTP请求和接收HTTP响应。

性能开销：

• 由于HTTPS需要进行加密和解密操作
  • 因此相对于HTTP来说，会有更多的计算和处理开销，会轻微地增加通信的延迟和资源消耗。

总的来说，HTTPS是对HTTP的增强和加密升级，提供了更高的安全性。

在处理敏感信息、进行用户登录/注册、在线支付等场景中，使用HTTPS更为安全可靠。

• 而在一些不涉及敏感信息的场景，使用HTTP可以提高性能和简化配置。

HTTPS 大概过程流程讲一下？

HTTPS 的工作流程可以简单描述为以下几个步骤：

客户端发起连接：

• 客户端通过浏览器等应用向服务器发送HTTPS请求。
  • 请求的URL以https://开头，表明是要使用HTTPS协议进行通信。

服务器证书：

• 服务器接收到来自客户端的HTTPS请求后，会将自己的数字证书发送给客户端。
  • 证书中包含了服务器的公钥，同时由可信的权威机构（证书颁发机构，CA）对服务器的身份进行认证。

客户端验证证书：

• 客户端收到服务器的证书后，会对证书进行验证。

• 主要包括以下几个步骤：

  • 验证证书的合法性：客户端会检查证书的有效期、签发机构和相关属性，确保证书的合法性。

  • 验证证书的可信性：客户端会检查证书的颁发机构是否被信任，以确保证书是由可信的第三方机构颁发的。

  • 密钥交换：

    • 在证书验证通过后，客户端会生成一个随机的对称加密密钥（session key），并使用服务器的公钥进行加密。
    • 然后将加密后的密钥发送给服务器。

  • 会话加密：

    • 服务器收到客户端发送的加密密钥后，使用自己的私钥进行解密，得到对称加密密钥（session key）。

  • 客户端和服务器都会使用这个对称密钥来加密和解密后续的通信数据。

安全通信：

• 客户端和服务器之间的所有通信都会使用对称密钥进行加密和解密。
  • 这样，即使有人拦截到通信数据，也无法解密和获取其中的内容。

总的来说，HTTPS的工作流程通过使用数字证书对服务器进行身份验证

• 采用对称加密密钥来加密通信数据，确保了数据传输的安全性和私密性。

这样，即使在公共网络上传输敏感信息，也能够保护用户的隐私和数据安全。

HTTPS 是如何保证通信安全的？

HTTPS保证通信安全主要依赖于两种技术：SSL/TLS协议和HTTP协议。

• 具体来说，HTTPS使用标准的HTTP在应用层进行信息传输
  • 但在HTTP下面添加了SSL/TLS协议层对数据进行加密，以此来确保数据安全。

为了避免数据在传输过程中被替换，比如黑客修改了你的报文内容，但是你并不知道，所以我们让发送端做一个数字签名

把数据的摘要消息进行一个加密，比如 MD5，得到一个签名，和数据一起发送。

• 然后接收端把数据摘要进行 MD5 加密，如果和签名一样，则说明数据确实是真的。

网络五层模型分别负责什么？

物理层：

• 负责把两台计算机连起来，然后在计算机之间通过高低电频来传送0,1这样的电信号
  • 比如通过一些电缆线传输比特流。

链路层：

• 链路层涉及到的协议比较多，比如 Mac 地址啊，ARP 等
• 这一层主要就是负责数据的通信，使各节点之间可以通信
  • 比如通过 MAC 地址唯一识别不同的节点，通过以太网协议定义数据包等。

网络层：

• 网络层负责把一个数据从一个网络传递到另外一个网络，最大的功能就是进行路由决策
  • 比如通过 IP，子网等概念，使数据更好着在不同的局域网中传递。

传输层：

• 传输层的功能就是建立端口到端口的通信，刚才说的网络层的功能则是建立主机到主机的通信
  • 比如通过网络层我们可以把信息从 A 主机传递到 B 主机，但是 B 主机有多个程序
  • 我们具体要发给哪个程序，则是靠传输层的协议来识别，常见协议有 UDP 和 TCP。

应用层：

• 虽然收到了传输层传来的数据，可是这些传过来的数据五花八门，有html格式的，有mp4格式的，

• 需要指定这些数据的格式规则，收到后才好解读渲染。

  • 例如我们最常见的 Http 数据包中，就会指定该数据包是 什么格式的文件了。

DNS 的解析过程？

DNS用于将域名解析为IP地址的系统。

DNS解析过程主要包括以下步骤：

• 用户在浏览器中输入一个域名

• 浏览器首先会在本地缓存中查找是否有该域名对应的IP地址

  • 如果有则直接返回IP地址，否则进入下一步。

• 浏览器会向本地DNS服务器发送一个查询请求。

• 本地DNS服务器如果缓存中有该域名对应的IP地址

  • 则直接返回IP地址给浏览器，否则进入下一步。

• 本地DNS服务器会向根域名服务器发送一个查询请求

  • 询问该域名的顶级域名服务器（比如.com）的IP地址。

• 根域名服务器会返回顶级域名服务器的IP地址给本地DNS服务器。

• 本地DNS服务器再次向顶级域名服务器发送查询请求

  • 询问该域名的权威域名服务器（比如example.com）的IP地址。

• 权威域名服务器返回该域名的IP地址给本地DNS服务器。

• 本地DNS服务器最后将IP地址返回给浏览器。

• 浏览器得到IP地址后，就可以向该IP地址对应的服务器发送HTTP请求，建立起与服务器的连接，开始浏览网页。

这个过程涉及到多个级别的DNS服务器：

• 从根域名服务器到顶级域名服务器再到权威域名服务器，最终找到域名对应的IP地址。

这个过程是递归查询的过程，每一级的DNS服务器负责下一级DNS服务器的查询，直到找到IP地址。

• 这样就实现了将域名解析为IP地址的功能。

什么是DDOS攻击？

DDoS 攻击是指 利用多个不同的计算机或网络设备，协同发起大规模的拒绝服务攻击。

攻击者通过控制大量的僵尸计算机或利用其他合法的网络设备，向目标服务器或网络发起大量的请求

• 使其无法正常响应合法用户的请求。

DDoS攻击的目标是使目标服务器或网络过载，耗尽其计算资源、网络带宽、处理能力等

• 导致正常用户无法访问目标服务。

攻击方式多种多样，常见的类型包括：

• ICMP Flood：

  • 发送大量的ICMP（Internet Control Message Protocol）数据包，消耗目标服务器的网络带宽和处理能力。

• SYN Flood：

  • 发送大量的TCP连接请求的半连接（SYN），使服务器处于半连接打开状态，无法接受新的连接请求。

• UDP Flood：

  • 发送大量的UDP（User Datagram Protocol）数据包，使服务器的目标端口过载，无法处理其他合法的请求。

• HTTP Flood：

  • 发送大量的HTTP请求，以耗尽目标服务器的处理能力，例如发起大量的查询或下载请求。

• DNS Amplification：

  • 利用存在放大效应的DNS协议，向开放式DNS服务器发送小型请求，从而获得大量响应数据
    • 使目标服务器的网络带宽被占用。

DDoS攻击可以导致服务不可用、网络延迟、数据泄漏以及经济损失，对于网站、在线服务和网络基础设施造成严重影响。

为了应对DDoS攻击，可以采取一系列的防御措施，如使用入侵检测和防火墙技术、流量过滤、负载均衡等

• 以提高网络的安全性和抗DDoS攻击能力。

什么是SQL 注入？举个例子？

SQL 注入就是通过把 SQL 命令插入到 Web表单提交或输入域名或页面请求的查询字符串

• 最终达到欺骗服务器执行恶意的SQL命令的。

SQL注入攻击的总体思路：

• 寻找到SQL注入的位置
• 判断服务器类型和后台数据库类型
• 针对不通的服务器和数据库特点进行SQL注入攻击

SQL注入攻击实例：

• 比如，在一个登录界面，要求输入用户名和密码
  • 但是我们可以通过SQL注入来实现免帐号登录，比如我们可以这样输入：

用户名： ‘or 1 = 1 --
密 码：

用户一旦点击登录，如若没有做特殊处理，那么这个非法用户就很得意的登陆进去了。

这是为什么呢?

下面我们分析一下：从理论上说，后台认证程序中会通过如下的SQL语句来判断用户的账户密码是否正确：

String sql = “select * from user_table where username=’ “+userName+” ’ and password=’ “+password+” ‘”;

因此，当输入了上面的用户名和密码，上面的SQL语句变成：

SELECT * FROM user_table WHERE username=’’or 1 = 1 –- and password=’’

分析上述SQL语句我们知道，username='' or 1=1 这个语句一定会成功；然后后面加两个 -

谈一谈 XSS 攻击，举个例子？

XSS是一种经常出现在web应用中的计算机安全漏洞，与SQL注入一起成为web中最主流的攻击方式。

XSS是指恶意攻击者利用网站没有对用户提交数据进行转义处理或者过滤不足的缺点

• 进而添加一些脚本代码嵌入到web页面中去

• 使别的用户访问都会执行相应的嵌入代码，从而盗取用户资料

  • 利用用户身份进行某种动作或者对访问者进行病毒侵害的一种攻击方式。

XSS攻击的危害

• 盗取各类用户帐号，如机器登录帐号、用户网银帐号、各类管理员帐号

• 控制企业数据，包括读取、篡改、添加、删除企业敏感数据的能力

• 盗窃企业重要的具有商业价值的资料

• 非法转账

• 强制发送电子邮件

• 网站挂马

• 控制受害者机器向其它网站发起攻击

原因解析

主要原因：

• 过于信任客户端提交的数据！

解决办法：

• 不信任任何客户端提交的数据，只要是客户端提交的数据就应该先进行相应的过滤处理然后方可进行下一步的操作。

进一步分析细节：

• 客户端提交的数据本来就是应用所需要的，但是恶意攻击者利用网站对客户端提交数据的信任
  • 在数据中插入一些符号以及javascript代码
  • 那么这些数据将会成为应用代码中的一部分了，那么攻击者就可以肆无忌惮地展开攻击啦
    • 因此我们绝不可以信任任何客户端提交的数据！！！

XSS 攻击分类

反射性XSS攻击 (非持久性XSS攻击):

• 漏洞产生的原因是攻击者注入的数据反映在响应中。
• 一个典型的非持久性XSS攻击包含一个带XSS攻击向量的链接(即每次攻击需要用户的点击)，例如，正常发送消息：

http://www.test.com/message.php?send=Hello,World！

接收者将会接收信息并显示Hello,World；但是，非正常发送消息：

http://www.test.com/message.php?send=<script>alert(‘foolish!’)</script>！

接收者接收消息显示的时候将会弹出警告窗口！

持久性XSS攻击 (留言板场景):

• XSS攻击向量(一般指XSS攻击代码)存储在网站数据库，当一个页面被用户打开的时候执行。
• 也就是说，每当用户使用浏览器打开指定页面时，脚本便执行。

与非持久性XSS攻击相比，持久性XSS攻击危害性更大。

从名字就可以了解到，持久性XSS攻击就是将攻击代码存入数据库中，然后客户端打开时就执行这些攻击代码。

例如，留言板表单中的表单域：

<input type="text" name="content" value="这里是用户填写的数据">

正常操作流程是：用户是提交相应留言信息 —— 将数据存储到数据库 —— 其他用户访问留言板，应用去数据并显示

而非正常操作流程是攻击者在value填写:

<script>alert(‘foolish!’)；</script> <!--或者html其他标签（破坏样式。。。）、一段攻击型代码-->

并将数据提交、存储到数据库中；当其他用户取出数据显示的时候，将会执行这些攻击性代码。

修复漏洞方针:

• 漏洞产生的根本原因是 太相信用户提交的数据，对用户所提交的数据过滤不足所导致的
  • 因此解决方案也应该从这个方面入手，具体方案包括：

将重要的cookie标记为http only, 这样的话Javascript 中的document.cookie语句就不能获取到cookie了

• 如果在cookie中设置了HttpOnly属性，那么通过js脚本将无法读取到cookie信息，这样能有效的防止XSS攻击

表单数据规定值的类型，例如：年龄应为只能为int、name只能为字母数字组合

对数据进行Html Encode 处理

过滤或移除特殊的Html标签，例如:

<script>, <iframe> , < for <, > for>, &quot for

过滤JavaScript 事件的标签，例如 οnclick=, onfocus 等等。

需要注意的是，在有些应用中是允许html标签出现的，甚至是javascript代码出现。

因此，我们在过滤数据的时候需要仔细分析哪些数据是有特殊要求

• 例如输出需要html代码、javascript代码拼接、或者此表单直接允许使用等等，然后区别处理

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

对称加密是一种常用的加密方式，它有一个特点：

• 就是加密和解密使用同一把密钥。

也就是说，用这个密钥加密的信息，只有用同样的密钥才能解密。

• 对称加密的速度相对较快，但是密钥的传输和保管比较困难
  • 因为只要这个密钥被泄漏，任何人都可以解密信息。

举个实际的例子来理解，如果你给朋友发送了一条用特定密码（这里的密码指的是对称加密的密钥）加密后的信息

• 那么你的朋友也需要知道这个密码才能将信息解密。

在这个过程中，你们都使用的是同一个密钥，称为对称密钥。

• 但如果你过后再想发送一条新的消息，必须要更改密码，否则如果之前的密码被其他人获取
  • 那么他们就能轻易地解密你的信息。

为了解决这个问题，就需要使用到非对称加密技术，其中涉及到两个密钥：公钥和私钥。

• 公钥是公开的，任何人都可以见到，并且可以用来加密信息或者验证签名。
• 而私钥则是保密的，只有密钥的主人才能看到，用来解密信息或者生成签名。

什么是数字证书？

一个数字证书是一个文件，经过由信任的证书颁发机构（CA）数字签名，用以验证持有者的身份以及公钥的真实性。

• 简短来说，就是一个电子文档，用来证明持有者的身份和公钥所有权。

数字证书中通常包含以下几项信息：

主题公钥：

• 这个公钥是证书的主要功能，用于公钥加密和数字签名验证。

主题：

• 承载证书的实体或个人的名称。

颁发者：

• 签署和发行这个证书的信任机构的名称。

有效期：

• 证书有效的时间范围。

序列号：

• 证书颁发者为每个证书分配的唯一的序列号。

数字签名：

• 证书颁发机构对上述信息进行hash计算后，再用其私钥进行加密得到的一串数据，证明证书的合法性和有效性。

在实际应用中，比如在进行HTTPS通信时，服务器会把它的数字证书发送给客户端。

• 客户端对此进行验证，确认服务器的身份后，才开始正式通信。
• 这个过程确保了数据在传输过程中的安全性。

ICMP 有哪些实际应用，举几个例子？

ICMP 主要有两个应用，一个是 Ping，一个是 Traceroute。

Ping

主要用来测试两台主机之间的连通性。

• Ping 的原理是通过向目的主机发送 ICMP Echo 请求报文，目的主机收到之后会发送 Echo 回答报文。

• Ping 会根据时间和成功响应的次数估算出数据包往返时间以及丢包率。

Traceroute

• Traceroute 是 ICMP 的另一个应用，用来跟踪一个分组从源点到终点的路径。

• Traceroute 发送的 IP 数据报封装的是无法交付的 UDP 用户数据报，并由目的主机发送终点不可达差错报告报文。