关于java:计算机网络经典20问

36次阅读

共计 6151 个字符，预计需要花费 16 分钟才能阅读完成。

本文目录：

  • 网络分层构造
  • 三次握手
  • 两次握手能够吗？
  • 四次挥手
  • 第四次挥手为什么要期待 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 发送数据，浪费资源。

四次挥手

  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。

码字不易，如果感觉对你有帮忙，能够 点个赞 激励一下！
我是程序员大彬，专一 Java 后端硬核常识分享，欢送大家关注~

正文完
java
发表至： java
2021-10-04
 0
Flink-源码解析-源码编译运行
关于java:Java代码性能测试实战之ContiPerf
企业网站建设的必要性体现在什么地方甲由科技
关于java:Hadoop-框架学习笔记之整体认知