计算机网络-面试题

• TCP 粘包是指：发送方发送的若干个包数据到接收方接收时，粘成一个包数据。

• TCP 是基于字节流的，虽然应用层和 TCP 传输层之间的数据交互是大小不等的数据块，但是 TCP 把这些数据块仅仅看成一连串无结构的字节流，没有边界，这就可能导致字节流合并（粘包）。

TCP 粘包产生的原因：

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

• 接收方采用 TCP 协议接收数据时的过程是这样的：数据到接收方，从网络模型的下方传递至传输层，传输层的 TCP 协议处理是将其放置接收缓冲区，然后由应用层来主动获取（例如C 语言用函数等）；这时会出现一个问题，就是我们在程序中调用的读取数据函数不能及时的把缓冲区中的数据拿出来，而下一个数据又到来并有一部分放入的缓冲区末尾，等我们读取数据时就是一个粘包。（放数据的速度 > 应用层拿数据速度）。
• 总结：接收数据端的应用层没有及时读取缓冲区中的数据，导致缓冲区数据堆积，将发生粘包。

避免粘包有以下两种方式：

• 在每个包的末尾加上特殊字符，用以区分连续的两个包。（例如加\r\n标记）
• 在报文首部添加包的长度。

• 为了准确无误地把数据送达目标处，TCP 协议采用了三次握手策略。
• 建立一个 TCP 连接需要"三次握手"。

如下图所示，下面的两个机器人通过 3 次握手确定了对方能正确接收和发送消息：

上图流程为：

• 一次握手：客户端发送带有 SYN 标志的数据包给服务端。
• 二次握手：服务端发送带有 SYN/ACK 标志的数据包给客户端。
• 三次握手：客户端发送带有带有 ACK 标志的数据包给服务端。

三次握手的目的是建立可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。

• 第一次握手：是为了服务端确认对方 (客户端) 发送数据正常，自己接收数据正常。
• 第二次握手：是为了客户端确认自己发送、接收数据正常，同时客户端也知道了对方 (服务端) 发送、接收数据都正常。
• 第三次握手：是为了让服务端确认自己发送、接收数据正常，同时服务端也知道了对方 (客户端) 发送、接收数据正常。

所以三次握手为了让客户端和服务端双方，互相都知道自己和对方发送、接收功能都正常，缺一不可。

如图所示：

断开一个 TCP 连接则需要“四次挥手”：

• 第一次挥手：客户端发送一个 FIN 数据包给服务端，用来告诉服务端，我要关闭与你的 TCP 连接。(客户端主动关闭到服务器的数据传输，但此时客户端还能接收服务端传来的数据)
• 服务端收到这个 FIN 数据包后，它返回一 个 ACK 数据包给客户端，确认序号为收到的序号加 1 （和 SYN 一样，一个 FIN 将占用一个序号），目的是告诉客户端，我收到了你的关闭连接请求。
• 服务端主动关闭到客户端的连接，并发送一个FIN 数据包给客户端，告诉客户端我也关闭了和你的 TCP 连接。(服务端不会再给客户端发送数据了)
• 客户端收到服务端返回的 FIN 数据包后，再发送一个 ACK 数据包给服务端确认，并将确认序号设置为收到序号加 1。

• TCP 设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户请求后都会重新复位这个计时器，时间通常是设置为 2 小时，若两小时还没收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔 75 秒发送一次。若一连发送 10 个探测报文仍然没有反应，服务器就认为客户端出了故障，接着就关闭连接。

• 所经历的过程：DNS 域名解析、TCP 连接、发送 HTTP 请求、服务器处理请求并返回 HTTP 报文、浏览器渲染、结束。

下面来逐步分析一下：

当我们在浏览器中输入一个域名然后回车时，首先检查本机的‪C:\Windows\System32\drivers\etc\hosts配置文件下有没有对应的域名映射，如下所示：

# 前台本机域名映射
127.0.0.1:80 web.csp1999.com
    
# 后端接口本机域名映射
127.0.0.1:8080 api.csp1999.com   

如果有，则返回对应的 IP 地址。

如果没有，浏览器会发出一个 DNS 请求到本地DNS服务器找对应的 IP 地址，本地 DNS 服务器一般都是你的网络接入服务器商提供，比如中国电信，中国移动：（图片来源：Tomcat启动与配置----一个Servlet可以指定多个映射路径-----高难度面试题:谈谈网站是如何进行访问的—JSP–Maven阿里云镜像–MVC三层架构–Filter—JDBC_帆浆的博客-CSDN博客）

• 解析出 IP 地址后，浏览器根据 IP 地址和默认端口 443 向网站的服务器发起请求，三次握手，建立 TCP 连接。

• 建立好 TCP 连接后，浏览器 (客户端) 通过 HTTP 协议发送请求，请求从服务器端获取数据。
• 服务器处理客户端的 HTTP 请求后，就将请求的数据返回给浏览器。

• 浏览器与服务器数据传送完毕后，四次握手，释放 TCP 连接。

• 浏览器对数据进行解析并渲染显示。

HTTP的概念：

• HTTP 是超文本传输协议，用于客户端和服务器端之间的通信，即在「两点」之间「传输」文字、图片、音频、视频等「超文本」数据的「约定和规范」。

HTTP 的特性(优点)：

• HTTP 最凸出的优点是「简单、灵活和易于扩展、应用广泛和跨平台」。

HTTP的常见字段：

• 客户端发送请求时，用来指定服务器的域名。

Host: www.A.com

有了 Host 字段，就可以将请求发往「同一台」服务器上的不同网站。

• 服务器在返回数据时，会有 Content-Length 字段，表明本次响应的数据长度。

Content-Length: 1000

如上面则是告诉浏览器，本次服务器回应的数据长度是 1000 个字节，后面的字节就属于下一个回应了。

• Connection 字段最常用于客户端要求服务器使用 TCP 持久连接，以便其他请求复用。

HTTP/1.1 版本的默认连接都是持久连接，但为了兼容老版本的 HTTP，需要指定 Connection 首部字段的值为 Keep-Alive。

Connection: keep-alive

一个可以复用的 TCP 连接就建立了，直到客户端或服务器主动关闭连接。但是，这不是标准字段。

• Content-Type 字段用于服务器回应时，告诉客户端，本次数据是什么格式。

Content-Type: text/html; charset=utf-8

上面的类型表明，发送的是网页，而且编码是UTF-8。

客户端请求的时候，可以使用 Accept 字段声明自己可以接受哪些数据格式。

Accept: */* 

上面代码中，客户端声明自己可以接受任何格式的数据。

• Content-Encoding 字段说明数据的压缩方法。表示服务器返回的数据使用了什么压缩格式。

Content-Encoding: gzip

上面表示服务器返回的数据采用了 gzip 方式压缩，告知客户端需要用此方式解压。

客户端在请求时，用 Accept-Encoding 字段说明自己可以接受哪些压缩方法。

Accept-Encoding: gzip, deflate

• URL 中参数可见性：GET 参数可见（通过拼接 URL 进行传递参数），POST 参数不可见。
• 是否可缓存：GET 请求是可以缓存的，POST 请求不可以缓存。
• 传输数据的大小：GET 一般传输数据大小不超过 2k-4k（根据浏览器不同，限制不一样，但相差不大），POST 请求传输数据的大小根据 php.ini 配置文件设定，也可以无限大。
• 安全性：GET 不安全，POST 安全。
• 数据包个数：GET 产生一个 TCP 数据包；POST 产生两个 TCP 数据包。

• HTTP 协议的特性「无状态、明文传输」既是优点也是缺点，同时还有一大缺点「不安全」。

• 无状态的好处：服务器不用去记忆 HTTP 的状态，不需要额外的资源来记录状态信息，这能减轻服务器的负担，能够把更多的 CPU 和内存资源用在对外提供服务上。

• 无状态的**坏处：**服务器没有记忆能力，它在完成有关联性的操作时会非常麻烦。

  • 例如登录 -> 添加购物车 -> 下单 -> 结算 -> 支付，这系列操作都要知道用户的身份才行。但服务器不知道这些请求是有关联的，每次都要确认一遍用户身份信息。

对于无状态的问题，解法方案有很多种，其中比较简单的方式用 Cookie 技术。

Cookie 通过在请求和响应中写入 Cookie 信息来控制客户端的状态。相当于，在客户端第一次请求后，服务器会下发一个带有客户身份信息的「小贴纸」，后续客户端请求服务器的时候，带上「小贴纸」，服务器就能试别了：

• 明文意味着在传输过程中的信息，是可方便阅读的，通过浏览器的 F12 控制台或 Wireshark 抓包都可以直接肉眼查看，为我们调试工作带了极大的便利性。
• 但是这正是这样，HTTP 的所有信息都暴露在了光天化日下，相当于信息裸奔。在传输的漫长的过程中，信息的内容都毫无隐私可言，很容易就能被窃取，如果里面有你的账号密码信息，那==你号没了(盗号的🐎没了 )。==

• ① 安全性区别：HTTP 是超文本传输协议，信息是明文传输，存在安全风险的问题。HTTPS 可以保证信息传输安全，在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议，使得报文能够加密传输。
• ② 建里连接流程区别：HTTP 连接建立相对简单， TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。
• ③ 端口区别：HTTP 的端口号是 80，HTTPS 的端口号是 443。
• ④ 是否需要申请数字证书：HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。而 HTTP 协议不需要。

混合加密：

HTTPS 采用对称加密和非对称加密结合的「混合加密」方式，将服务器公钥放到数字证书中，来解决窃听风险。

• 在通信建立前采用非对称加密的方式交换「会话秘钥」，后续就不再使用非对称加密。
• 在通信过程中全部使用对称加密的「会话秘钥」的方式加密明文数据。

摘要算法：

• HTTPS 采用摘要算法来确保数据的完整性，解决了数据被篡改的风险。
• 摘要算法能够为数据生成独一无二的「标识」，用于校验数据的完整性，从而解决了篡改的风险。

HTTPS 在 HTTP 与 TCP 层之间加入了 SSL/TLS 协议，如图：

Cookie 和 Session 的作用：

Cookie 和 Session都是用来跟踪浏览器用户身份的会话方式，但两者有所区别：

• Cookie 一般用来保存用户信息。比如我们在 Cookie 中保存已经登录过得用户信息，下次访问网站的时候页面可以自动帮你登录的一些基本信息给填了；
• **Session 的主要作用就是通过服务端记录用户的状态。**典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了。

Cookie 和 Session 的区别如下：

• Cookie 数据保存在客户端，Session 数据保存在服务器端。
• Cookie 存储在客户端中，而Session存储在服务器上，相对来说 Session 安全性更高。如果要在 Cookie 中存储一些敏感信息，不要直接写入 Cookie 中，最好能将 Cookie 信息加密然后使用到的时候再去服务器端解密。
• Cookie ⼀般⽤来保存⽤户信息，Session 的主要作用就是通过服务端记录用户的状态。

参考文章：

• https://blog.csdn.net/sinat_38719275/article/details/102607458
• https://blog.csdn.net/qq_32595453/article/details/80563142

• URI：是统一资源标志符，可以唯一标识一个资源。
• URL：是统一资源定位符，可以提供该资源的路径。URL 是 URI 的一个子集，它不仅唯一标识资源，而且还提供了定位该资源的信息。

URI 的作用像身份证号一样，URL 的作用更像家庭住址一样。

• HTTP 1.0：默认使用 短连接，浏览器每次请求都需要与服务器建立一次 TCP 连接，服务器处理完成后立即断开 TCP 连接（无连接），服务端不记录客户端的请求状态（无状态）。

• HTTP 1.1：默认使用长连接，用以保持连接特性。使用长连接的 HTTP 协议，会在响应头加入这行代码：

  // Keep-Alive不会永久保持连接，它有一个持续时间，可以在不同的服务器软件中设定这个时间。
  // 实现长连接需要客户端和服务端都支持长连接。
  Connection:keep-alive
  

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

• HTTP 2.0：引入二进制数据帧和流的概念，支持多路复用、服务器推送，支持使用二进制格式传输数据，而 HTTP 1.0 依然使用文本格式传输。

• 对称加密算法：双方持有相同的密钥，进行加密速度快，典型对称加密算法：DES、AES。
• 非对称加密算法：密钥成对出现（私钥、公钥），私钥只有自己知道，不在网络中传输；而公钥可以公开。相比对称加密速度较慢，典型的非对称加密算法有：RSA、DSA。

HTTPS 是在 HTTP 与 TCP 之间加了一层 SSL/TLS 协议 ，所以建里连接流程如下：

① 首先建立 TCP 连接：三次握手。

② 然后建里 SSL/TLS 加密：

SSL/TLS 协议基本流程：

• 客户端向服务器索要并验证服务器的公钥。
• 双方协商生产「会话秘钥」。
• 双方采用「会话秘钥」进行加密通信。

前两步也就是 SSL/TLS 的建立过程，也就是握手阶段。

③ 发送HTTP 请求。