计算机网络经典20问

原文链接：https://mp.weixin.qq.com/s/L5deD51x47w3O2SMiRyLzQ

本文目录：

  • 网络分层结构
  • 三次握手
  • 两次握手可以吗？
  • 四次挥手
  • 第四次挥手为什么要等待 2MSL？
  • 为什么是四次挥手？
  • TCP 有哪些特点？
  • TCP 和 UDP 的区别？
  • HTTP 协议的特点？
  • HTTP 报文格式
  • HTTP 状态码有哪些？
  • HTTP1.0 和 HTTP1.1 的区别？
  • HTTP1.1 和 HTTP2.0 的区别？
  • HTTPS 与 HTTP 的区别？
  • 什么是数字证书？
  • HTTPS 原理
  • DNS 的解析过程？
  • 浏览器中输入 URL 返回页面过程？
  • Cookie 和 Session 的区别？
  • 什么是对称加密和非对称加密？

网络分层结构

计算机网络体系大致分为三种，OSI 七层模型、TCP/IP 四层模型和五层模型。一般面试的时候考察比较多的是五层模型。

 

 

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

  • 应用层：为应用程序提供交互服务。在互联网中的应用层协议很多，如域名系统 DNS、HTTP 协议、SMTP 协议等。
  • 传输层：负责向两台主机进程之间的通信提供数据传输服务。传输层的协议主要有传输控制协议 TCP 和用户数据协议 UDP。
  • 网络层：选择合适的路由和交换结点，确保数据及时传送。主要包括 IP 协议。
  • 数据链路层：在两个相邻节点之间传送数据时，数据链路层将网络层交下来的 IP 数据报组装成帧，在两个相邻节点间的链路上传送帧。
  • 物理层：实现相邻节点间比特流的透明传输，尽可能屏蔽传输介质和物理设备的差异。

三次握手

假设发送端为客户端，接收端为服务端。开始时客户端和服务端的状态都是CLOSED。

 

 

  1. 第一次握手：客户端向服务端发起建立连接请求，客户端会随机生成一个起始序列号 x，客户端向服务端发送的字段中包含标志位SYN=1，序列号seq=x。第一次握手前客户端的状态为CLOSE，第一次握手后客户端的状态为SYN-SENT。此时服务端的状态为LISTEN。
  2. 第二次握手：服务端在收到客户端发来的报文后，会随机生成一个服务端的起始序列号 y，然后给客户端回复一段报文，其中包括标志位SYN=1，ACK=1，序列号seq=y，确认号ack=x+1。第二次握手前服务端的状态为LISTEN，第二次握手后服务端的状态为SYN-RCVD，此时客户端的状态为SYN-SENT。（其中SYN=1表示要和客户端建立一个连接，ACK=1表示确认序号有效。）
  3. 第三次握手：客户端收到服务端发来的报文后，会再向服务端发送报文，其中包含标志位ACK=1，序列号seq=x+1，确认号ack=y+1。第三次握手前客户端的状态为SYN-SENT，第三次握手后客户端和服务端的状态都为ESTABLISHED。此时连接建立完成。

两次握手可以吗？

第三次握手主要为了防止已失效的连接请求报文段突然又传输到了服务端，导致产生问题。

  • 比如客户端 A 发出连接请求，可能因为网络阻塞原因，A 没有收到确认报文，于是 A 再重传一次连接请求。
  • 连接成功，等待数据传输完毕后，就释放了连接。
  • 然后 A 发出的第一个连接请求等到连接释放以后的某个时间才到达服务端 B，此时 B 误认为 A 又发出一次新的连接请求，于是就向 A 发出确认报文段。
  • 如果不采用三次握手，只要 B 发出确认，就建立新的连接了，此时 A 不会响应 B 的确认且不发送数据，则 B 一直等待 A 发送数据，浪费资源。

原因二、失效的连接请求占用资源问题
两次握手带来的另一个问题是失效连接会占用资源。

假定Client向Server发送了一个请求，但是该请求因为网络原因，在网路中逗留了一会儿，未及时送达。此时Client将再次向Server发送请求，Server接收到请求，发送确认包，完成连接并开始进行数据传输。数据传输完成后，断开连接。

但是断开连接后，Client的第一个请求兜兜转转，终于又找到server，此时Server将发送确认包，连接建立完成，但是Client已经完成了数据业务，并不会做任何事情，而Server还在等待进一步的数据交互——Server端的资源被白白浪费了。

但三次握手时，上述情况将不会发生，因为Client在第二次收到确认包时，不会做任何响应，连接将不会建立，某种程度上减少了资源的消耗。

四次挥手

 

 

  1. A 的应用进程先向其 TCP 发出连接释放报文段（FIN=1，seq=u），并停止再发送数据，主动关闭 TCP 连接，进入FIN-WAIT-1（终止等待 1）状态，等待 B 的确认。
  2. B 收到连接释放报文段后即发出确认报文段（ACK=1，ack=u+1，seq=v），B 进入CLOSE-WAIT（关闭等待）状态，此时的 TCP 处于半关闭状态，A 到 B 的连接释放。
  3. A 收到 B 的确认后，进入FIN-WAIT-2（终止等待 2）状态，等待 B 发出的连接释放报文段。
  4. B 发送完数据，就会发出连接释放报文段（FIN=1，ACK=1，seq=w，ack=u+1），B 进入LAST-ACK（最后确认）状态，等待 A 的确认。
  5. A 收到 B 的连接释放报文段后，对此发出确认报文段（ACK=1，seq=u+1，ack=w+1），A 进入TIME-WAIT（时间等待）状态。此时 TCP 未释放掉，需要经过时间等待计时器设置的时间2MSL（最大报文段生存时间）后，A 才进入CLOSED状态。B 收到 A 发出的确认报文段后关闭连接，若没收到 A 发出的确认报文段，B 就会重传连接释放报文段。

第四次挥手为什么要等待 2MSL？

  • 保证 A 发送的最后一个 ACK 报文段能够到达 B。这个ACK报文段有可能丢失，B 收不到这个确认报文，就会超时重传连接释放报文段，然后 A 可以在2MSL时间内收到这个重传的连接释放报文段，接着 A 重传一次确认，重新启动 2MSL 计时器，最后 A 和 B 都进入到CLOSED状态，若 A 在TIME-WAIT状态不等待一段时间，而是发送完 ACK 报文段后立即释放连接，则无法收到 B 重传的连接释放报文段，所以不会再发送一次确认报文段，B 就无法正常进入到CLOSED状态。
  • 防止已失效的连接请求报文段出现在本连接中。A 在发送完最后一个ACK报文段后，再经过 2MSL，就可以使这个连接所产生的所有报文段都从网络中消失，使下一个新的连接中不会出现旧的连接请求报文段。

为什么是四次挥手？

因为当 Server 端收到 Client 端的SYN连接请求报文后，可以直接发送SYN+ACK报文。但是在关闭连接时，当 Server 端收到 Client 端发出的连接释放报文时，很可能并不会立即关闭 SOCKET，所以 Server 端先回复一个ACK报文，告诉 Client 端我收到你的连接释放报文了。只有等到 Server 端所有的报文都发送完了，这时 Server 端才能发送连接释放报文，之后两边才会真正地断开连接。故需要四次挥手。

TCP 有哪些特点？

  • TCP 是面向连接的运输层协议。
  • 点对点，每一条 TCP 连接只能有两个端点。
  • TCP 提供可靠交付的服务。
  • TCP 提供全双工通信。
  • 面向字节流。

TCP 和 UDP 的区别？

  1. TCP 面向连接；UDP 是无连接的，即发送数据之前不需要建立连接。
  2. TCP 提供可靠的服务；UDP 不保证可靠交付。
  3. TCP 面向字节流，把数据看成一连串无结构的字节流；UDP 是面向报文的。
  4. TCP 有拥塞控制；UDP 没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如实时视频会议等）。
  5. 每一条 TCP 连接只能是点到点的；UDP 支持一对一、一对多、多对一和多对多的通信方式。
  6. TCP 首部开销 20 字节；UDP 的首部开销小，只有 8 个字节。

HTTP 协议的特点？

  1. HTTP 允许传输任意类型的数据。传输的类型由 Content-Type 加以标记。
  2. 无状态。对于客户端每次发送的请求，服务器都认为是一个新的请求，上一次会话和下一次会话之间没有联系。
  3. 支持客户端/服务器模式。

HTTP 报文格式

HTTP 请求由请求行、请求头部、空行和请求体四个部分组成。

  • 请求行：包括请求方法，访问的资源 URL，使用的 HTTP 版本。GET和POST是最常见的 HTTP 方法，除此以外还包括DELETE、HEAD、OPTIONS、PUT、TRACE。
  • 请求头：格式为“属性名:属性值”，服务端根据请求头获取客户端的信息，主要有cookie、host、connection、accept-language、accept-encoding、user-agent。
  • 请求体：用户的请求数据如用户名、密码等。

请求报文示例：

POST /xxx HTTP/1.1 请求行
Accept:image/gif.image/jpeg, 请求头部
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)
Accept-Encoding:gzip,deflate

username=dabin 请求体

HTTP 响应也由四个部分组成，分别是：状态行、响应头、空行和响应体。

  • 状态行：协议版本，状态码及状态描述。
  • 响应头：响应头字段主要有connection、content-type、content-encoding、content-length、set-cookie、Last-Modified、Cache-Control、Expires。
  • 响应体：服务器返回给客户端的内容。

响应报文示例：

HTTP/1.1 200 OK
Server:Apache Tomcat/5.0.12
Date:Mon,6Oct2003 13:23:42 GMT
Content-Length:112

<html>
    <body>响应体</body>
</html>

HTTP 状态码有哪些？

 

 

HTTP1.0 和 HTTP1.1 的区别?

  • 长连接：HTTP1.0 默认使用短连接，每次请求都需要建立新的 TCP 连接，连接不能复用。HTTP1.1 支持长连接，复用 TCP 连接，允许客户端通过同一连接发送多个请求。不过，这个优化策略也存在问题，当一个队头的请求不能收到响应的资源时，它将会阻塞后面的请求。这就是“队头阻塞”问题。

  • 断点续传：HTTP1.0 不支持断点续传。HTTP1.1 新增了 range 字段，用来指定数据字节位置，支持断点续传。

  • 错误状态响应码：在 HTTP1.1 中新增了 24 个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突、410（Gone）表示服务器上的某个资源被永久性的地删除。

  • Host 头处理：在 HTTP1.0 中认为每台服务器都绑定一个唯一的 IP 地址，因此，请求消息中的 URL 并没有传递主机名。到了 HTTP1.1 时代，虚拟主机技术发展迅速，在一台物理服务器上可以存在多个虚拟主机，并且它们共享一个 IP 地址，故 HTTP1.1 增加了 HOST 信息。

HTTP1.1 和 HTTP2.0 的区别？

HTTP2.0 相比 HTTP1.1 支持的特性：

  • 新的二进制格式：HTTP1.1 基于文本格式传输数据；HTTP2.0 采用二进制格式传输数据，解析更高效。

  • 多路复用：在一个连接里，允许同时发送多个请求或响应，并且这些请求或响应能够并行地传输而不被阻塞，避免 HTTP1.1 出现的“队头堵塞”问题。

  • 头部压缩，HTTP1.1 的 header 带有大量信息，而且每次都要重复发送；HTTP2.0 把 header 从数据中分离，并封装成头帧和数据帧，使用特定算法压缩头帧，有效减少头信息大小。并且 HTTP2.0 在客户端和服务器端记录了之前发送的键值对，对于相同的数据，不会重复发送。比如请求 a 发送了所有的头信息字段，请求 b 则只需要发送差异数据，这样可以减少冗余数据，降低开销。

  • 服务端推送：HTTP2.0 允许服务器向客户端推送资源，无需客户端发送请求到服务器获取。

HTTPS 与 HTTP 的区别？

  1. HTTP 是超文本传输协议，信息是明文传输；HTTPS 则是具有安全性的 ssl 加密传输协议。
  2. HTTP 和 HTTPS 用的端口不一样，HTTP 端口是 80，HTTPS 是 443。
  3. HTTPS 协议需要到 CA 机构申请证书，一般需要一定的费用。
  4. HTTP 运行在 TCP 协议之上；HTTPS 运行在 SSL 协议之上，SSL 运行在 TCP 协议之上。

什么是数字证书？

服务端可以向证书颁发机构 CA 申请证书，以避免中间人攻击（防止证书被篡改）。证书包含三部分内容：证书内容、证书签名算法和签名，签名是为了验证身份。

 

 

服务端把证书传输给浏览器，浏览器从证书里取公钥。证书可以证明该公钥对应本网站。

数字签名的制作过程：

  1. CA 使用证书签名算法对证书内容进行 hash 运算。
  2. 对 hash 后的值用 CA 的私钥加密，得到数字签名。

浏览器验证过程：

  1. 获取证书，得到证书内容、证书签名算法和数字签名。
  2. 用 CA 机构的公钥对数字签名解密（由于是浏览器信任的机构，所以浏览器会保存它的公钥）。
  3. 用证书里的签名算法对证书内容进行 hash 运算。
  4. 比较解密后的数字签名和对证书内容做 hash 运算后得到的哈希值，相等则表明证书可信。

HTTPS 原理

首先是 TCP 三次握手，然后客户端发起一个 HTTPS 连接建立请求，客户端先发一个Client Hello的包，然后服务端响应Server Hello，接着再给客户端发送它的证书，然后双方经过密钥交换，最后使用交换的密钥加解密数据。

  1. 协商加密算法 。在Client Hello里面客户端会告知服务端自己当前的一些信息，包括客户端要使用的 TLS 版本，支持的加密算法，要访问的域名，给服务端生成的一个随机数（Nonce）等。需要提前告知服务器想要访问的域名以便服务器发送相应的域名的证书过来。

     

     

  2. 服务端响应Server Hello，告诉客户端服务端选中的加密算法。

     

     

  3. 接着服务端给客户端发来了 2 个证书。第二个证书是第一个证书的签发机构（CA）的证书。

     

     

  4. 客户端使用证书的认证机构 CA 公开发布的 RSA 公钥对该证书进行验证，下图表明证书认证成功。

     

     

  5. 验证通过之后，浏览器和服务器通过密钥交换算法产生共享的对称密钥。

     

     

  6. 开始传输数据，使用同一个对称密钥来加解密。

     

     

DNS 的解析过程？

  1. 浏览器搜索自己的 DNS 缓存。
  2. 若没有，则搜索操作系统中的 DNS 缓存和 hosts 文件。
  3. 若没有，则操作系统将域名发送至本地域名服务器，本地域名服务器查询自己的 DNS 缓存，查找成功则返回结果，否则依次向根域名服务器、顶级域名服务器、权限域名服务器发起查询请求，最终返回 IP 地址给本地域名服务器。
  4. 本地域名服务器将得到的 IP 址返回给操作系统，同时自己也将 IP 地址缓存起来。
  5. 操作系统将 IP 地址返回给浏览器，同时自己也将 IP 地址缓存起来。
  6. 浏览器得到域名对应的 IP 地址。

浏览器中输入 URL 返回页面过程？

  1. 解析域名，找到主机 IP。
  2. 浏览器利用 IP 直接与网站主机通信，三次握手，建立 TCP 连接。浏览器会以一个随机端口向服务端的 web 程序 80 端口发起 TCP 的连接。
  3. 建立 TCP 连接后，浏览器向主机发起一个 HTTP 请求。
  4. 服务器响应请求，返回响应数据。
  5. 浏览器解析响应内容，进行渲染，呈现给用户。

 

 

Cookie 和 Session 的区别？

  • 作用范围不同，Cookie 保存在客户端，Session 保存在服务器端。
  • 有效期不同，Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session 一般失效时间较短，客户端关闭或者 Session 超时都会失效。
  • 隐私策略不同，Cookie 存储在客户端，容易被窃取；Session 存储在服务端，安全性相对 Cookie 要好一些。
  • 存储大小不同， 单个 Cookie 保存的数据不能超过 4K；对于 Session 来说存储没有上限，但出于对服务器的性能考虑，Session 内不要存放过多的数据，并且需要设置 Session 删除机制。

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

对称加密：通信双方使用相同的密钥进行加密。特点是加密速度快，但是缺点是密钥泄露会导致密文数据被破解。常见的对称加密有AES和DES算法。

非对称加密：它需要生成两个密钥，公钥和私钥。公钥是公开的，任何人都可以获得，而私钥是私人保管的。公钥负责加密，私钥负责解密；或者私钥负责加密，公钥负责解密。这种加密算法安全性更高，但是计算量相比对称加密大很多，加密和解密都很慢。常见的非对称算法有RSA和DSA。

posted @ 2022-03-04 18:24  你的雷哥  阅读(106)  评论(0)  编辑  收藏  举报