LittleStone BLOG

未来已来 始于现在

0%

计算机网络|高频考点

发表于 更新于 分类于
本文字数： 3.2k 阅读时长 ≈ 3 分钟

计算机网络|高频考点

摘录于Leetcode -计算机网络高频面试考点，仅供个人学习使用，请勿商业转载！未完待续……

0. 协议栈

1. 参考模型

2. OSI 模型和 TCP/IP 模型异同比较

​ 相同点

  1. OSI参考模型与TCP-IP参考模型都采用了层次结构。
  2. 都能够提供面向连接和无连接两种通信服务机制。
    不同点
  3. OSI参考模型采用的七层模型；TCP-IP是四层结构。
  4. TCP-IP参考模型没有对网络接口层进行细分，只是一些概念性的描述；OSI参考模型对服务和协议做了明确的区分
  5. OSI先有模型，后有协议规范，适合于描述各种网络；TCP-IP是先有协议集然后建立模型，不适用于非TCP-IP网络
  6. TCP-IP一开始就提出面向连接和无连接服务，而OSI开始只强调面向连接服务，直到很晚才开始制定无连接的服务标准
  7. OSI参考模型虽然被看好，但将网络划分为七层，实现起来较困难；相反，TCP-IP参考模型虽然有许多不尽人意的地方，但作为一种简化的分层结构还是比较成
3. OSI 和 TCP/IP 协议之间的对应关系

image-20210313094726526

4. 数据在各层之间的传输过程
  1. 在发送主机端，一个应用层报文被传送到运输层。在最简单的情况下，运输层收取到报文并附上附加信息，该首部将被接收端的运输层使用。应用层报文和运输层首部信息一道构成了运输层报文段。附加的信息可能包括：允许接收端运输层向上向适当的应用程序交付报文的信息以及差错检测位信息。该信息让接收端能够判断报文中的比特是否在途中已被改变。
  2. 运输层则向网络层传递该报文段，网络层增加了如源和目的端系统地址等网络层首部信息，生成了网络层数据报。
  3. 该数据报接下来被传递给链路层，在数据链路层数据包添加发送端 MAC 地址和接收端 MAC 地址后被封装成数据帧，
  4. 在物理层数据帧被封装成比特流，之后通过传输介质传送到对端。

1. 应用层

1. Keep-Alive 和非 Keep-Alive 区别，对服务器性能有影响吗？

​ 在早期的 HTTP/1.0 中，浏览器每次 发起 HTTP 请求都要与服务器创建一个新的 TCP 连接，服务器完成请求处理后立即断开 TCP 连接，服务器不跟踪每个客户也不记录过去的请求。然而创建和关闭连接的过程需要消耗资源和时间，为了减少资源消耗，缩短响应时间，就需要重用连接。

​ 在 HTTP/1.1 版本中默认使用持久连接，在此之前的 HTTP 版本的默认连接都是使用非持久连接，如果想要在旧版本的 HTTP 协议上维持持久连接，则需要指定 connection 的首部字段的值为 Keep-Alive 来告诉对方这个请求响应完成后不要关闭，下一次咱们还用这个请求继续交流，我们用一个示意图来更加生动的表示两者的区别：

image-20210313101022587

​ 对于非 Keep=Alive 来说，必须为每一个请求的对象建立和维护一个全新的连接。对于每一个这样的连接，客户机和服务器都要分配 TCP 的缓冲区和变量，这给服务器带来的严重的负担，因为一台 Web 服务器可能同时服务于数以百计的客户机请求。

​ 在 Keep-Alive 方式下，服务器在响应后保持该 TCP 连接打开，在同一个客户机与服务器之间的后续请求和响应报文可通过相同的连接进行传送。甚至位于同一台服务器的多个 Web 页面在从该服务器发送给同一个客户机时，可以在单个持久 TCP 连接上进行。

​ 然而，Keep-Alive并不是没有缺点的，当长时间的保持TCP连接时容易导致系统资源被无效占用，若对Keep Alive模式配置不当，将有可能比非Keep-Alive模式带来的损失更大。因此，我们需要正确地设置Keep-Alive timeout参数，当TCP连接在传送完最后一个HTTP响应，该连接会保持keep alive timeout秒，之后就开始关闭这个链接。

2. Get请求与POST请求

  1. get 提交的数据会放在 URL 之后，并且请求参数会被完整的保留在浏览器的记录里，由于参数直接暴露在 URL 中，可能会存在安全问题，因此往往用于获取资源信息。而 post 参数放在请求主体中，并且参数不会被保留，相比 get 方法，post 方法更安全，主要用于修改服务器上的资源

  2. get 提交的数据大小有限制（这里所说的限制是针对浏览器而言的），而 post 方法提交的数据没限制

  3. get 方法产生一个 TCP 数据包，post 方法产生两个（并不是所有的浏览器中都产生两个）

    原因： 对于GET方式的请求，浏览器会把http header和data一并发送出去，服务端响应200，请求成功。

    对于POST方式的请求，浏览器会先发送http header给服务端，告诉服务端等一下会有数据过来，服务端响应100 continue，告诉浏览器我已经准备接收数据，浏览器再post发送一个data给服务端，服务端响应200，请求成功。

    3. HTTP 与 HTTPS 建立连接的过程

  • HTTP

    1. TCP三次握手

    2. HTTP请求报文

    3. HTTP响应报文

    4. TCP四次挥手

      明文传输

  • HTTPS

    1. 客户端向服务器端 发送 自己支持的加密算法，以及 随机数A

    2. 服务器端收到随机数A，向客户端发送数字证书 以及随机数B

    3. 客户端 收到随机数B，验证数字证书是否有效，并产生随机数C 并且利用数字证书中的公钥对随机数C加密，发送给服务器端

    4. 服务器端利用自身的私钥对加密数字C解密 得到数字C，向客户端发送finish报文 包含了解密以后的数字，告诉客户端自己能够解密

4. HTTP 与 HTTPS的区别

  1. HTTP采用明文传输，HTTPS采用密文传输（对称加密技术）

  2. HTTP采用80端口号 HTTPS采用443端口号

  3. HTTPS 协议需要到数字认证机构（Certificate Authority, CA）申请证书，一般需要一定的费用。

  4. HTTP 页面响应比 HTTPS 快，主要因为 HTTP 使用 3 次握手建立连接，客户端和服务器需要握手 3 次，而 HTTPS 除了 TCP 的 3 次握手，还需要经历一个 SSL 协商过程。

5. HTTP如何保存用户状态

  1. 基于Session实现的会话保持

    • 是什么

      客户端在第一次向服务器发送了请求以后，服务器端会创建一个Session对象 通过键值对的形式存储到服务器端，并在响应报文中为客户端分配一个SessionID 存储在客户端的Cookie中

      客户端之后的请求会把SessionID 带上，服务器根据SessionID 会之前的会话建立联系

    • 优点

      安全，用户数据存储在了服务器端

    • 缺点

      大型网站往往采用分布式服务器，且采用负载均衡的技术，客户端连续两次的请求 可能分布到了两台不同的服务器，基于Session的方法就不能实现会话保持

  2. 基于Cookie实现的会话保持

    • 是什么

    • 优点

    • 缺点

      6. HTTP状态码
7. DNS 域名解析的过程
8. 用户输入网址到显示对应页面的全过程

2. 传输层

1. TCP三次握手与四次挥手机制
2.为什么需要三次握手 而不是 两次
3.为什么需要四次挥手 而不是三次
4. 为什么TCP连接释放时，客户端要等待两个传播时延，再断开连接
5.如果TCP三次握手每次报文都丢失了，客户端与服务器端会怎样处理

  1. 第一次握手 客户端向服务器端 发送连接请求报文段 SYN=1,ACK=0,seq=x，

    如果请求报文丢失了，客户端会启动超时重传机制，直到达到了最高重传次数，发送ICMP差错报文

    ​ 服务端没有任何动作

  2. 第二次握手 服务器端接收到 连接请求报文段，同意建立连接向客户端返回确认

    如果确认报文丢失了，客户端会启动超时重传机制，直到达到了最高重传次数，发送ICMP差错报文

    ​ 服务端阻塞到 acept()等待客户端返回确认

  3. 若第三次握手服务器未接收到客户端发送过来的 ACK 报文，

    服务器会采取类似于客户端的超时重传机制，若重传次数超过限制后仍然没有回应，则 accep() 系统调用返回 -1，服务器端连接建立失败

    客户端认为连接已经建立，开始传输数据，当服务器收到客户端发送来的数据 会发送RST报文给客户端，消除客户端建立的单方面连接

6.

3. 网络层

4. 数据链路层

5. 物理层

参考链接

1. Leetcode计算机网络突击面试