计算机基础问题

最近看了一些微信文章，将文章内容大体总结如下，持续更新。

1.计算机网络

1. 一台计算机是如何把数据发送给另外一台计算机的？

参考来源

基于网络通信的五层模型来回答：

1. 物理层： 物理层负责把两台计算机连起来，在计算机之间通过高低电频来传送0,1电信号

2. 数据链路层： 制定规则来进行0，1的传送，以便让计算机识别0,1电信号代表的实际含义

   • 以太网协议： 一组电信号构成的数据包称为一个帧，由表头和数据构成。表头的长度固定为18字节，数据部分长度不一定，所以一个帧的大小一般为64-1518字节，太大的就分为多个帧传输。计算机与计算机之前如何区分呢？引入下一个概念，唯一标识MAC

   • MAC地址： 每个网卡都有一个唯一的地址，称为MAC地址。由48字节构成，唯一标识

   • 广播与ARP协议：

     • ARP：Address Revolution Protocol，地址解析协议
     • 广播只在同一个子网中，数据包里面含有接收者的MAC地址，收到广播消息的子网内的主机，将数据包中的MAC地址拿出来和自己的MAC对比，如果一样，说明发送方找的就是我，那么就接收这个数据包，否则丢弃。

3. 网络层： 如果在一个子网内，通过广播的形式传送数据，如果不在一个子网内，那么就将数据发给网关，让网关进行转发

   1. IP 协议：
   2. 0.0.0.0 ~ 255.255.255.255
      2. 网络部分和主机部分
      3. 判断两个 IP 地址是否是一个子网，还需要知道子网掩码，子网掩码主机位全是1
   3. ARP 协议：
      1. 通过 ARP 协议能够获得其他主机的 MAC 地址
      2. ARP 协议通过广播的形式向一个子网内的其他所有主机发送一个数据包，包含想要获得的MAC地址对应的IP地址。对方收到这个数据包后，将IP地址拿出来和自己的IP地址进行比较，如果相同，就把自己的IP地址回复给想要获取的那一方，否则丢弃。
   4. DNS 服务器：
      1. 通常我们想要访问一个网站，输入的是网站的域名，而不是直接输入网站的 IP 地址。
      2. DNS 服务器能够将我们访问的网站域名解析为对应的 IP 地址
   5. 网络层的功能：让我们能够在网络中找到一台计算机在哪里，判断我们是否属于同一个子网。

4. 传输层： 建立端口到端口的连接。以供特定的程序来接收处理。

   1. 常见 TCP 与 UDP 协议

5. 应用层：

   1. 指定数据的格式、规则，收到好才好解读渲染。

2. 电脑的 ip 是怎么来的？

参考来源

1. DHCP （Dynamic Host Configuration Protocol）动态主机配置协议
2. 客户端请求 IP
   1. 客户端发送一个广播，广播的目的 IP 是 255.255.255.255，目的端口是 67，为了让别人知道他是来请求一个 IP 地址的，将客户端的源 IP 设置为 0.0.0.0，源端口是 68。 将这个 IP 请求报文称为 discover 报文（UDP）
3. DHCP 响应
   1. DHCP 收到源 IP 为0.0.0.0 的报文，就会给他提供一个 IP，包括 IP地址，子网掩码、网关、IP有效期，通过发起请求的客户端的 MAC 地址，DHCP服务器将这些信息送过去。也是通过广播的形式，此时广播报文的源 IP 为DHCP服务器的 IP，目的IP为255.255.255.255
   2. DHCP 提供 IP 的报文称为 offer 报文。
4. 客户端挑选 IP 地址
   1. 可能不止一台 DHCP 服务器收到了 IP 请求，对于 客户端而言，一般选择最先收到的 offer 报文，然后给对应的 DHCP 服务器发送一个 request 报文，表明已经收到了他提供的 IP。
5. 如果 DHCP 服务器不在所在的局域网，那么就需要网关进行传递，中间涉及到 NAT 地址转换协议

3.谈谈NAT

参考来源

1. NAT（Network Address Translation）
2. 为减少 IP 地址的消耗，可以一个公司拥有一个属于自己的内网（局域网），该局域网分配有一个 IP 地址，可以作为整个局域网的网关，与外界网络进行通信；
3. 局域网内的主机想要和外部的网络进行通信，需要经过这个网关，为了识别局域外内部是哪一台主机想要和外界通信，网关维护有一个地址转换表，存储的是内部主机的 IP：端口号 与映射后的 IP：端口号 对照表；
4. 通过这个地址转换表，即 NAT 协议，局域网内部的主机就能够和外界通信了
5. 局域网内的 IP 称为 内网IP
6. 网关 IP，百度等这样的 IP 称为 全球IP

4. 三次握手

参考来源

1. 作用：

   1. 确认双方的接收与发送能力是否正常
   2. 防止错误连接到达服务器，让 Server 错误打开连接
   3. 指定自己的初始化序列号，为后面的可靠传送做准备
   4. 如果是 HTTPS 协议的话，三次握手这个过程，还会进行数字证书的验证以及加密秘钥的生成

2. 三次握手的过程

   刚开始，客户端处于 closed 状态，服务器端处于 listen 状态

   1. 第一次握手： 客户端给服务器端发送一个 SYN 报文，并指明客户端的初始化序列号 ISN（c）。此时客户端处于 SYN_SENT 阶段
   2. 第二次握手： 服务器端收到来自客户端的 SYN 报文之后，会以自己的 SYN 报文作为回答，并且也指定了自己的初始化序列号 ISN（s）。同时把 客户端的 ISN（c）+ 1 作为 ACK 的值，表明自己已经收到了客户端的 SYN，此时服务器处于 SYN_REVD 状态
   3. 第三次握手： 客户端收到 SYN 报文后，会发送一个 ACK 报文，当然，也是把服务器的 ISN（s）+ 1 作为 ACK 的值，表示已经收到了服务端的 SYN，此时客户端处于 ESTABLISHED 状态
   4. 服务器收到 ACK 报文后，也就处于 ESTABLISHED 状态，双方建立起来连接。

3. 示意图

4. 常见问题

   1. ISN（Initial Sequence Number） 是固定的吗?

   通信双方交换 ISN 以便让对方知道接下来接受数据的时候如何按照序列号来重新组装数据。如果是固定的，攻击者很容易猜出后续的确认号，因此，ISN 是动态生成的。

   2. 什么是半连接队列？

   服务器端第一次收到 SYN 后，就处于 SYN_RECD 状态，此状态下的请求连接放在一个队列里面，该队列就是半连接队列。完成三次握手后，建立起来的连接会放在一个全连接队列中。如果队列满，可能出现丢包现象。

   3. SYN-ACK 重传机制

   服务器发送完 SYN - ACK 包，如果未收到客户端的确认报文，服务器进行首次重传，等待一段时间后仍未收到确认包，进行第二次重传，如果重传次数超过系统规定的最大重传次数，那么这个连接信息就从半连接队列中删除。等待时间呈指数增长：1 2 4 8.。。

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

   第一二次握手不能携带，第三次握手，其实客户端已经处于 建立连接 状态了，所以第三次握手可以携带数据。

   第一次握手不能携带数据是避免服务器收到恶意的客户端在第一次握手信息中携带大量数据，且反复重发 SYN 报文，造成服务器时间，空间的浪费。

   5. 为什么两次握手不行？

   客户端发送的请求如果在网络中滞留，则会隔很长时间才能收到服务器发回的连接确认。客户端等待一个超时重传时间之后，就会重新请求连接，但滞留的连接请求最后还是会到达服务器。如不进行第三次握手，那 Server 就打开两个连接。若有第3次握手，客户端会忽略 Server 之后发送的滞留请求的连接确认。

5. 四次挥手

刚开始，双方都处于 ESTABLISHED 状态，假如是客户端首先发起关闭请求：

1. 第一次挥手： 客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端会处于 FIN_WAIT1 状态；
2. 第二次挥手： 服务器端收到一个 FIN 报文后，会发送 ACK 报文，且把客户端的序列号+1作为 ACK 报文的序列号值，表明已经收到客户端的 FIN 报文了，此时服务器端处于 CLOSE_WAIT 状态。
3. 第三次挥手： 如果服务器端也想断开连接了，一样发送一个 FIN 报文给客户端，且指定一个序列号。此时服务器端处于 LAST_ACK 状态
4. 第四次挥手： 客户端收到 FIN 后，发送一个 ACK 作为应答，此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务器端收到自己的 ACK 报文之后就进入 CLOSED 状态。
5. 服务器端收到 ACK 报文之后，也就处于关闭状态了。
6. 示意图（为服务器端首先断开连接）

1.注意要点：

1. 每一次报文交换后，客户端与服务器端的状态是什么样的。
2. Client 发送了 FIN 报文后，Server 一收到这个报文就进入 Close-Wait 状态，这个状态是为了让 Server 发送还未发送完成的数据，传送完后，Server 也发送 FIN 来结束连接。
3. Client 接收到 Server 的 FIN 后，需要进入一个 Time-Wait 状态，时间为 2MSL（最大报文存活时间），再进入 Closed 状态，原因？
   1. 确保最后一个确认报文能够到达，若 Server 没有收到 Client 的 ACK，就会重新发送 FIN 报文，Client 等待一段时间就是为此；
   2. 等待一段时间是为了让本地连接持续时间内产生的所有报文从网络中消失，使得下一个新的连接不会出现旧的连接请求报文。

6. TCP流量控制机制

参考来源

1. 为什么要进行流量控制？

接收方缓存满后，再接受数据包会出现丢包的问题，为了避免丢包问题，控制发送方发送速率,让接收方、发送方处于动态平衡的策略叫做流量控制。

2. 如何控制

接收方每次接收到数据后，在发送确认报文的时候可以将自己**缓冲区还剩下多少空间（接收窗口 win）**告诉发送方。

发送方收到这个接收窗口的信息后，便调整自己的发送速率，即调整发送窗口的大小，当发送窗口变为0，则停止发送数据，避免出现丢包的情况。

3. 发送方什么时候再继续发送数据？
   1. 当发送方收到 win = 0 的消息后，就停止发送报文，同时打开一个定时器，每隔一段时间就发送一个测试报文去询问接收方，“你准备好了吗？”，如果接收方回复可以继续发送，则继续发送；若 win 还是等于 0 ，则刷新启动定时器，准备下一次询问。

4.注意事项

1. TCP/IP 全双工传输，因此通信双方都有两个滑动窗口，一个用于接受数据，接收窗口；一个用于发送数据，发送窗口（拥塞窗口）。指出窗口大小的通知称为 “窗口通告”。
2. 接收窗口的大小固定吗？
   1. 现在的TCP协议中，大小是动态调整的
3. 接收窗口越大越好吗？
   1. 太小，丢包率上升；太大，消耗内存。
   2. 根据网络环境以及发送方的拥塞窗口来进行动态调整。
4. 一般情况下：接收窗口 >= 发送窗口

7. 拥塞控制机制

参考来源

1.为什么要进行拥塞控制？

​ 假设主机A和主机B通信

​ 当主机A给主机B发送报文后，由于某些原因，迟迟没有收到主机B的ACK确认报文，那么主机A会认为报文被丢失了，那么主机A将继续给主机B发送报文。但是现实情况可能是因为网络中有太多主机占用信道资源，导致网络拥塞，主机A第一次给主机B发送的报文还是可以到达主机B的，但是A再次给主机B发送了一个报文，不仅造成网络进一步拥塞，还浪费了信道资源。所以我们需要进行拥塞控制。

2.如何知道网络的拥塞情况？

​ 将A一次性连续发送的数据包个数称之为“拥塞窗口”，用N表示吧。那么A怎么知道网络的拥塞情况呢？

开始阶段，发送数据包试探，其中 N 指数增长，到达一个阈值 ssthresh 后，再线性增长。

3.到了瓶颈值后怎么办？

1. 将达到瓶颈值的 N 称为 Max；
2. 到达 Max 后，我们就回到最原始的状态，1 2 4 8 。。。这样开始，同时， 设置阈值 ssthresh​ = Max / 2

4.超时事件一定是网络拥塞吗？

​ 还有可能是某个数据包出现了丢失或者损害，导致这个数据包超时时间发生。

通过冗余 ACK 防止这种情况。当 A 连续收到三个确认 M2 的 ACK 且M3超时事件还没发生。A就知道 M3 可能丢失了，这个时候A就不必等待 M3 设置的计时器到期了，而是快速重传M3 。 并且把 ssthresh 设置为 Max 的一半，即 ssthresh = Max / 2 , 但是这个时候并非把控制窗口 N 设置为1，而是让N = ssthresh，N 在一个一个增长。 这种情况也叫做 快速恢复。

8.在浏览器地址栏输入一个URL后回车，背后会进行哪些技术步骤？

参考来源

1.格式验证与协议选择

1. 浏览器对用户输入的网址做初步的格式化检查，只有通过格式化检查，才会进入下一步
2. 浏览器使用 http 还是 https 访问服务器？
   1. 没有明确告知浏览器用哪个协议，浏览器采用默认的 http 协议

2.DNS 查询

1. 拥有想要访问的网站的域名还是不够的，TCP/IP 协议传送消息需要知道对方的 IP 地址
2. 于是，浏览器使用 DNS（域名系统）查询域名对应的 IP 地址
3. DNS 先查询自己内存里面的 DNS Cache，没有 -》接着再看本地硬盘里面的 host 文件，还是没有
4. 于是，DNS 请求 DNS 服务器，请求过程使用 UDP 协议，请求报文中还携带有网关的 MAC 地址，通过 ARP（地址解析协议）获取；
5. 请求报文到达 DNS 服务器后，DNS 服务器先看自己的缓存里面有没有请求的域名对应的 IP 地址，如果有就返回，否则，DNS 服务器跑去请求 DNS 根服务器 “.”。“.” 就是根服务器，全球一共13台根域名服务器，每一台 DNS 服务器都知道这13台根服务器的 IP 地址
6. 根服务器收到 “zhihu.com.”（请求的域名），知道是自己的孙子服务器，但不知道他的 IP，但知道“com” 的 IP 地址，于是 DNS 服务器就去找这个 “com”，从他那里获取到了 “zhihu.com.” 的 IP 地址，马上将这个 IP 地址转达给等待的浏览器。

3.三次握手

​ 使用 TCP 协议。

1. 三次握手成功后，建立了可靠的虚拟通道。浏览器准备将 http 请求消息发给刚刚获取到的 IP 地址（zhihu.com 域名），此时获取到一个重定向的消息，因为 zhihu.com 使用 https 协议，所以重新去请求；
2. 大体和 http 请求类似。但是不同的是 https 协议是加密的、安全的、需要经过证书验证等步骤，默认端口 443。
3. 经过一系列加密、解密，证书验证的操作，浏览器发起的请求终于得到了回应，https 将 zhihu.com 主页返回并最终到达了浏览器。

9.GET请求和POST请求的区别

从三个层面来回答

1.HTTP 报文层面：GET请求将请求信息放在URL，POST放到报文体中

2.数据库层面：GET 符合幂等性和安全性，POST不符合

3.其他层面：GET可以被缓存、存储，而POST不行

10.Cookie 和 Session 的区别

1.Cookie

1. 是由服务器发给客户端的特殊信息，以文本的形式存放在客户端
2. 客户端再次请求的时候，会把Cookie回发
3. 服务器接收到后，会解析Cookie生成与客户端相对应的内容

2.Cookie 的设置以及发送过程

3.Session

1. 服务器端的机制，在服务器上保存的信息
2. 解析客户端请求并操作session id，按需保存状态信息

4.Session的实现方式

1. 使用Cookie来实现

2. 使用URL回写来实现

是指服务器在发送给浏览器的所有URL中都携带这个唯一标识JSESSIONID的参数，这样浏览器端点击任意一个URL都会将这个唯一标识带回服务器。

5.区别

1. Cookie 数据存放在客户的浏览器上，Session数据放在服务器上
2. Session相对于Cookie更安全，别人可以分析存放在本地的Cookie，进行Cookie欺骗
3. 若考虑减轻服务器负担，应当使用Cookie

如有问题，敬请指正！

最后

以上就是失眠月饼为你收集整理的计算机基础问题的全部内容，希望文章能够帮你解决计算机基础问题所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。