计算机网络基础

KingGue

已于 2022-03-12 23:01:16 修改

阅读量375

点赞数

分类专栏：计算机网络基础文章标签：网络 http 网络协议 tcp/ip

于 2022-03-11 12:18:36 首次发布

本文链接：https://blog.csdn.net/KingGue/article/details/123413941

版权

计算机网络基础专栏收录该内容

1 篇文章 0 订阅

订阅专栏

1 网络协议是什么

在计算机网络要做到有条不紊地交换数据，就必须遵守一些事先约定好的规则，比如交换数据的格式、是否需要发送一个应答信息。这些规则被称为网络协议。

2 为什么要对网络协议分层

简化问题难度和复杂度。由于各层之间独立，我们可以分割大问题为小问题。
灵活性好。当其中一层的技术变化时，只要层间接口关系保持不变，其他层不受影响。
易于实现和维护。
促进标准化工作。分开后，每层功能可以相对简单地被描述。

3 四层协议五层协议和七层协议的关系

TCP/IP是一个四层的体系结构，主要包括：应用层、运输层、网际层和网络接口层。
五层协议的体系结构主要包括：应用层、运输层、网络层，数据链路层和物理层。
OSI七层协议模型主要包括是：应用层（Application）、表示层 （Presentation）、会话层（Session）、运输层（Transport）、网络层 （Network）、数据链路层 （Data Link）、物理层（Physical）。

4 物理层有什么作用

主要解决两台物理机之间的通信，通过二进制比特流的传输来实现，二进制数据表现为电流电压上的强弱，到达目的地再转化为二进制机器码。网卡、集线器工作在这一层。

5 数据链路层有什么作用

在不可靠的物理介质上提供可靠的传输，接收来自物理层的位流形式的数据，并封装成帧，传送到上一层；同样，也将来自上层的数据帧，拆装为位流形式的数据转发到物理层。这一层在物理层提供的比特流的基础上，通过差错控制、流量控制方法，使有差错的物理线路变为无差错的数据链路。提供物理地址寻址功能。交换机工作在这一层。

6 网络层有什么作用

将网络地址翻译成对应的物理地址，并决定如何将数据从发送方路由到接收方，通过路由选择算法为分组通过通信子网选择最佳路径。路由器工作在这一层。

7 传输层有什么作用

传输层提供了进程间的逻辑通信，传输层向高层用户屏蔽了下面网络层的核心细节，使应用程序看起来像是在两个传输层实体之间有一条端到端的逻辑通信信道。

8 会话层有什么作用

建立会话：身份验证，权限鉴定等；
保持会话：对该会话进行维护，在会话维持期间两者可以随时使用这条会话传输局；
断开会话：当应用程序或应用层规定的超时时间到期后，OSI会话层才会释放这条会话。

9 表示层有什么作用

对数据格式进行编译，对收到或发出的数据根据应用层的特征进行处理，如处理为文字、图片、音频、视频、文档等，还可以对压缩文件进行解压缩、对加密文件进行解密等。

10 应用层有什么作用

提供应用层协议，如 HTTP 协议， FTP 协议等等，方便应用程序之间进行通信。

11 传输层协议TCP与UDP区别

UDP TCP

12 运行在TCP协议上的协议：

HTTP（Hypertext Transfer Protocol，超文本传输协议），主要用于普通浏览。
HTTPS（HTTP over SSL，安全超文本传输协议）,HTTP协议的安全版本。
FTP（File Transfer Protocol，文件传输协议），用于文件传输。
POP3（Post Office Protocol, version 3，邮局协议），收邮件用。
SMTP（Simple Mail Transfer Protocol，简单邮件传输协议），用来发送电子邮件。
TELNET（Teletype over the Network，网络电传），通过一个终端（terminal）登陆到网络。
SSH（Secure Shell，用于替代安全性差的TELNET），用于加密安全登陆用。运行在UDP协议上的协议：
BOOTP（Boot Protocol，启动协议），应用于无盘设备。
NTP（Network Time Protocol，网络时间协议），用于网络同步。
DHCP（Dynamic Host Configuration Protocol，动态主机配置协议），动态配置IP地址。运行在TCP和UDP协议上：
DNS（Domain Name Service，域名服务），用于完成地址查找，邮件转发等工作。

13 为何TCP可靠

TCP有三次握手建立连接，四次挥手关闭连接的机制。
除此之外还有滑动窗口和拥塞控制算法。最最关键的是还保留超时重传的机制。
对于每份报文也存在校验，保证每份报文可靠性。

14 为何UDP不可靠

UDP面向数据报无连接的，数据报发出去，就不保留数据备份了。

仅仅在IP数据报头部加入校验和复用。
UDP没有服务器和客户端的概念。
UDP报文过长的话是交给IP切成小段，如果某段报废报文就废了。

15 简述TCP分包、粘包现象

1. 正常情况：如果Socket Client 发送的数据包，在Socket Server端也是一个一个完整接收的，那个就不会出现粘包和分包情况，数据正常读取。
2. 粘包情况：Socket Client发送的数据包，在客户端发送和服务器接收的情况下都有可能发送，因为客户端发送的数据都是发送的一个缓冲buffer，然后由缓冲buffer最后刷到数据链路层的，那么就有可能把数据包2的一部分数据结合数据包1的全部被一起发送出去了，这样在服务器端就有可能出现这样的情况，导致读取的数据包包含了数据包2的一部分数据，这就产生粘包，当然也有可能把数据包1和数据包2全部读取出来。
3. 分包情况：意思就是把数据包2或者数据包1都有可能被分开一部分发送出去，接着发另外的部分，在服务器端有可能一次读取操作只读到一个完整数据包的一部分。
4. 在数据包发送的情况下，有可能后面的数据包分开成2个或者多个，但是最前面的部分包，黏住在前面的一个完整或者部分包的后面，也就是粘包和分包同时产生了。

16 TCP分包、粘包现象处理方法

1. 消息定长，比如定一个100，那么读取端每次读取数据就截取100个长度的数据，然后交给业务成去做解析。
2. 在消息的尾部加一些特殊字符，那么在读取数据的时候，只要读到这个特殊字符，就认为已经可以截取一个完整的数据包了，这种情况在一定的业务情况下实用。
3. 读取缓存的数据是不定长的，所以我们把读取到的数据添加到我们自己的一个byte[ ]数组中，然后根据我们的业务逻辑来找到指定的特殊协议头部，协议长度，协议尾部，然后从我们的byte[ ]中获取一个完整的数据包，然后再对数据包进行业务解析就可以得到正确结果。

17 简述TCP协议的滑动窗口

滑动窗口是传输层进行流量控制的一种措施，接收方通过通告发送方自己的窗口大小，从而控制发送方的发送速度，防止发送方发送速度过快而导致自己被淹没。

18 简述TCP协议的拥塞控制

拥塞是指一个或者多个交换点的数据报超载， TCP 又会有重传机制，导致过载。

为了防止拥塞窗口 cwnd 增长过大引起网络拥塞，还需要设置一个慢开始门限 ssthresh 状态变量。

当cwnd < ssthresh 时，使用慢开始算法。
当cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法。
当cwnd = ssthresh 时，即可使用慢开始算法，也可使用拥塞避免算法。
- 慢开始：由小到大逐渐增加拥塞窗口的大小，每接一次报文，cwnd指数增加。
- 拥塞避免：cwnd缓慢地增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1。
- 快恢复之前的策略：发送方判断网络出现拥塞，就把ssthresh设置为出现拥塞时发送方窗口值的一半，继续执行慢开始，之后进行拥塞避免。
- 快恢复：发送方判断网络出现拥塞，就把ssthresh设置为出现拥塞时发送方窗口值的一半，并把cwnd设置为ssthresh的一半，之后进行拥塞避免。

19 简述快重传

如果在超时重传定时器溢出之前，接收到连续的三个重复冗余 ACK ，发送端便知晓哪个报文段在传输过程中丢失了，于是重发该报文段，不需要等待超时重传定时器溢出再发送该报文。

20 TCP三次握手过程

1. 第一次握手:客户端将标志位SYN置为1，随机产生一个值序列号seq=x，并将该数据包发送给服务端，客户端进入syn_sent状态，等待服务端确认。
2. 第二次握手:服务端收到数据包后由标志位SYN=1知道客户端请求建立连接，服务端将标志位SYN 和 ACK都置为1，ack=x+1,随机产生一个值seq=y，并将该数据包发送给客户端以确认连接请求，服务端进入syn_rcvd状态。
3. 第三次握手:客户端收到确认后检查,如果正确则将标志位ACK为1，ack=y+1，并将该数据包发送给服务端，服务端进行检查如果正确则连接建立成功，客户端和服务端进入established状态，完成三次握手，随后客户端和服务端之间可以开始传输数据了

21 为什么TCP握手需要三次，两次行不行？

因为需要考虑连接时丢包的问题，如果只握手2次，第二次握手时如果服务端发给客户端的确认报文段丢失，此时服务端已经准备好了收发数(可以理解服务端已经连接成功)据，而客户端一直没收到服务端的确认报文，所以客户端就不知道服务端是否已经准备好了(可以理解为客户端未连接成功)，这种情况下客户端不会给服务端发数据，也会忽略服务端发过来的数据。
如果是三次握手，即便发生丢包也不会有问题，比如如果第三次握手客户端发的确认 ack 报文丢失，服务端在一段时间内没有收到确认 ack 报文的话就会重新进行第二次握手，也就是服务端会重发SYN 报文段，客户端收到重发的报文段后会再次给服务端发送确认 ack 报文。

22 简述半连接队列

TCP 握手中，当服务器处于 SYN_RCVD 状态，服务器会把此种状态下请求连接放在一个队列里，该队列称为半连接队列。

23 简述SYN攻击

SYN 攻击即利用 TCP 协议缺陷，通过发送大量的半连接请求，占用半连接队列，耗费 CPU 和内存资源。

优化方式：

1. 缩短SYN Timeout时间
2. 记录IP，若连续受到某个IP的重复SYN报文，从这个IP地址来的包会被一概丢弃。

24 TCP四次挥手过程

1. 第一次挥手：客户端发送一个FIN，用来关闭客户端到服务端的数据传送，客户端进入fin_wait_1状态。
2. 第二次挥手：服务端收到FIN后，发送一个ACK给客户端，确认序号为收到序号+1，服务端进入Close_wait状态。此时TCP连接处于半关闭状态，即客户端已经没有要发送的数据了，但服务端若发送数据，则客户端仍要接收。
3. 第三次挥手：服务端发送一个FIN，用来关闭服务端到客户端的数据传送，服务端进入Last_ack状态。
4. 第四次挥手：客户端收到FIN后，客户端进入Time_wait状态，接着发送一个ACK给服务端，确认后，服务端进入Closed状态，完成四次挥手。

25 为什么TCP挥手需要4次

主要原因是当服务端收到客户端的 FIN 数据包后，服务端可能还有数据没发完，不会立即close。
所以服务端会先将 ACK 发过去告诉客户端我收到你的断开请求了，但请再给我一点时间，这段时间用来发送剩下的数据报文，发完之后再将 FIN 包发给客户端表示现在可以断了。之后客户端需要收到 FIN 包后发送 ACK 确认断开信息给服务端。

26 为什么四次挥手释放连接时需要等待2MSL

MSL即报文最大生存时间。设置2MSL（ Maximum Segment Life，报文最大生存时间）可以保证上一次连接的报文已经在网络中消失，不会出现与新TCP连接报文冲突的情况。
这里同样是要考虑丢包的问题，如果第四次挥手的报文丢失，服务端没收到确认ack报文就会重发第三次挥手的报文，这样报文一去一回最长时间就是2MSL，所以需要等这么长时间来确认服务端确实已经收到了。

27 如果已经建立了连接，但是客户端突然出现故障了怎么办

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

28 简述HTTP协议

http 协议是超文本传输协议。它是基于 TCP 协议的应用层传输协议，即客户端和服务端进行数据传输的一种规则。该协议本身HTTP 是一种无状态的协议。

29 HTTP 与 HTTPS 的区别

30 简述http状态码和对应的信息

1XX：接收的信息正在处理
2XX：请求正常处理完毕
3XX：重定向，需要进行附加操作以完成请求
4XX：客户端错误，服务器无法处理请求
5XX：服务端错误，服务器处理请求出错

常见错误码：

301：永久重定向，表示资源已被分配了新的 URL
302：临时重定向，表示资源临时被分配了新的 URL
304：资源没修改，用之前缓存就行
400：客户端请求的报文有错误
401：表示发送的请求需要有通过 HTTP 认证的认证信息
403：表示服务器禁止访问资源
404：表示请求的资源在服务器上不存在或未找到
500：表示服务器端在执行请求时发生了错误

31 简述http1.0

规定了请求头和请求尾，响应头和响应尾（ get post），每一个请求都是一个单独的连接，做不到连接的复用。

32 简述http1.1的改进

HTTP1.1默认开启长连接，在一个TCP连接上可以传送多个HTTP请求和响应。使用 TCP 长连接的方式改善了 HTTP/1.0 短连接造成的性能开销。
支持管道（pipeline）网络传输，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。
服务端无法主动push。

33 简述HTTP短连接与长连接区别

HTTP 中的长连接短连接指 HTTP 底层 TCP 的连接。

短连接：客户端与服务器进行一次HTTP连接操作，就进行一次TCP连接，连接结束TCP关闭连接。
长连接：如果HTTP头部带有参数keep-alive，即开启长连接网页完成打开后，底层用于传输数据的TCP连接不会直接关闭，会根据服务器设置的保持时间保持连接，保持时间过后连接关闭。

34 简述http2.0的改进

提出多路复用。多路复用前，文件时串行传输的，请求a文件，b文件只能等待，并且连接数过多。引入多路复用，a文件b文件可以同时传输。
引入了二进制数据帧。其中帧对数据进行顺序标识，有了序列id，服务器就可以进行并行传输数据。

35 简述TLS/SSL, HTTP, HTTPS的关系

SSL全称为Secure Sockets Layer即安全套接层，其继任为TLS（Transport Layer Security）传输层安全协议，均用于在传输层为数据通讯提供安全支持。
可以将HTTPS协议简单理解为HTTP协议＋TLS/SSL。

36 https的连接过程

1. 浏览器将支持的加密算法信息发给服务器。
2. 服务器选择一套浏览器支持的加密算法，以证书的形式回发给浏览器。
3. 客户端(SSL/TLS)解析证书验证证书合法性，生成对称加密的密钥，我们将该密钥称之为client。
key，即客户端密钥，用服务器的公钥对客户端密钥进行非对称加密。
4. 客户端会发起HTTPS中的第二个HTTP请求，将加密之后的客户端对称密钥发送给服务器。
5. 服务器接收到客户端发来的密文之后，会用自己的私钥对其进行非对称解密，解密之后的明文就是客户端密钥，然后用客户端密钥对数据进行对称加密，这样数据就变成了密文。
6. 服务器将加密后的密文发送给客户端。
7. 客户端收到服务器发送来的密文，用客户端密钥对其进行对称解密，得到服务器发送的数据。这样HTTPS中的第二个HTTP请求结束，整个HTTPS传输完成。

37 什么是对称加密与非对称加密

对称密钥加密是指加密和解密使用同一个密钥的方式，这种方式存在的最大问题就是密钥发送问题，即如何安全地将密钥发给对方。
而非对称加密是指使用一对非对称密钥，即公钥和私钥，公钥可以随意发布，但私钥只有自己知道。发送密文的一方使用对方的公钥进行加密处理，对方接收到加密信息后，使用自己的私钥进行解密。

38 简述DNS协议

DNS 协议是基于 UDP 的应用层协议，它的功能是根据用户输入的域名，解析出该域名对应的 IP 地址，从而给客户端进行访问。

39 简述DNS解析过程

1、首先是查找浏览器缓存，浏览器会保存一段时间你之前访问过的一些网址的DNS信息，不同浏览器保存的时常不等。
2、如果没有找到对应的记录，这个时候浏览器会尝试调用系统缓存来继续查找这个网址的对应 DNS 信息。
3、如果还是没找到对应的 IP ，那么接着会发送一个请求到路由器上，然后路由器在自己的路由器缓存上查找记录，路由器一般也存有 DNS 信息。
4、如果还是没有，这个请求就会被发送到 ISP（注：Internet Service Provider，互联网服务提供商，就是那些拉网线到你家里的运营商，中国电信中国移动什么的），ISP也会有相应的ISP DNS服务器。
如果还是没有的话，你的 ISP 的 DNS 服务器会将请求发向根域名服务器进行搜索。

根域名服务器就是面向全球的顶级 DNS服务器，如果到了这里还是找不到域名的对应信息，那只能说明一个问题：这个域名本来就不存在，它没有在网上正式注册过。或者卖域名的把它回收掉了（通常是因为欠费）。

40 简述DNS劫持

DNS 是指将网页域名翻译为对应的 IP 的一种方法。 DNS 劫持指攻击者篡改结果，使用户对域名的解析 IP变成了另一个IP 。

41 ARP：地址解析协议

1. 本地主机在局域网中广播ARP请求，ARP请求数据帧中包含目的主机的IP地址。意思是“如果你是这个IP地址的拥有者，请回答你的硬件地址”。
2 . 目的主机的ARP层解析这份广播报文，识别出是询问其硬件地址。于是发送ARP应答包，里面包含IP地址及其对应的硬件地址。
3 . 本地主机收到ARP应答后，知道了目的地址的硬件地址，之后的数据报就可以传送了。

42 RARP：逆地址解析协议

1. 主机发送一个本地的RARP广播，在此广播包中，声明自己的MAC地址并且请求任何收到此请求的RARP服务器分配一个IP地址。
2. 本地网段上的RARP服务器收到此请求后，检查其RARP列表，查找该MAC地址对应的IP地址。
3. 如果存在，RARP服务器就给源主机发送一个响应数据包并将此IP地址提供给对方主机使用。
4. 如果不存在，RARP服务器对此不做任何的响应。
5. 源主机收到从RARP服务器的响应信息，就利用得到的IP地址进行通讯；如果一直没有收到RARP服务器的响应信息，表示初始化失败。

43 浏览器中输入一个网址后，具体发生了什么

1. 进行DNS解析操作，根据DNS解析的结果查到服务器IP地址
2. 通过ip寻址和arp，找到服务器，并利用三次握手建立TCP连接
3. 浏览器生成HTTP报文，发送HTTP请求，等待服务器响应
4. 服务器处理请求，并返回给浏览器
5. 根据HTTP是否开启长连接，进行TCP的挥手过程
6. 浏览器根据收到的静态资源进行页面渲染

44 简述cookie

HTTP 协议本身是无状态的，为了使其能处理更加复杂的逻辑， HTTP/1.1 引入 Cookie 来保存状态信息。Cookie是由服务端产生的，再发送给客户端保存，当客户端再次访问的时候，服务器可根据 cookie 辨识客户端是哪个，以此可以做个性化推送，免账号密码登录等等。

45 简述session

session 用于标记特定客户端信息，存在在服务器的一个文件里。一般客户端带Cookie 对服务器进行访问，可通过 cookie 中的 session id 从整个 session 中查询到服务器记录的关于客户端的信息。

46 简述Token

Token 是服务端生成的一串字符串，以作客户端进行请求的一个令牌，当第一次登录后，服务器生成一个 Token 便将此 Token 返回给客户端，以后客户端只需带上这个Token 前来请求数据即可，无需再次带上用户名和密码。

47 转发和重定向的区别

转发是服务器行为。服务器直接向目标地址访问URL,将相应内容读取之后发给浏览器，用户浏览器地址栏URL不变，转发页面和转发到的页面可以共享request里面的数据。
重定向是利用服务器返回的状态码来实现的，如果服务器返回301或者302，浏览器收到新的消息后自动跳转到新的网址重新请求资源。用户的地址栏url会发生改变，而且不能共享数据。

48 Get与Post区别

1. Get 是不安全的，因为在传输过程，数据被放在请求的 URL 中； Post 的所有操作对用户来说都是不可见的。但是这种做法也不时绝对的，大部分人的做法也是按照上面的说法来的，但是也可以在get 请求加上 request body ，给 post 请求带上 URL 参数。
2. Get请求提交的 url中的数据多只能是2048 字节，这个限制是浏览器或者服务器给添加的， http 协议并没有对 url 长度进行限制，目的是为了保证服务器和浏览器能够正常运行，防止有人恶意发送请求。Post 请求则没有大小限制。
3. Get限制 Form 表单的数据集的值必须为 ASCII 字符；而 Post 支持整个。
4. Get执行效率却比 Post 方法好。 Get 是 form 提交的默认方法。
5. Get产生一个 TCP数据包；Post产生两个TCP 数据包。对于 Get 方式的请求，浏览器会把 http header 和 data 一并发送出去，服务器响应 200 （返回数据）；而对于 Post ，浏览器先发送header ，服务器响应 100 continue ，浏览器再发送 data ，服务器响应 200 ok （返回数据）。
6. get：从服务器上获取数据，也就是所谓的查，仅仅是获取服务器资源，不进行修改。post：向服务器提交数据，这就涉及到了数据的更新，也就是更改服务器的数据。

49 了解REST API吗

REST API 全称为表述性状态转移（ Representational State Transfer ， REST ）即利用 HTTP 中 get 、post、 put 、 delete 以及其他的 HTTP 方法构成 REST 中数据资源的增删改查操作：

Create ： POST
Read ： GET
Update ： PUT/PATCH
Delete： DELETE

50 http请求包含了什么

包含：请求方法字段、 URL 字段、 HTTP 协议版本、产生请求的浏览器类型，请求数据，主机地址。

51 Put与Delete区别

Put 规定默认为更新某一资源，和 Post 一样，一般该操作会对服务器资源进行改变

Delete 规定默认为删除某一资源，和 Post 一样，一般该操作会对服务器资源进行改变

52 什么是RPC

RPC （ Remote Procedure Call Protocol ）远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。简言之， RPC 使得程序能够像访问本地系统资源一样，去访问远端系统资源。比较关键的一些方面包括：通讯协议、序列化、资源（接口）描述、服务框架、性能、语言支持等。

RPC框架采用长链接，不必每次通信都要像http一样去3次握手什么的，减少了网络开销；
其次就是RPC框架一般都有注册中心，有丰富的监控管理；发布、下线接口、动态扩展等，对调用方来说是无感知、统一化的操作。
第三个来说就是安全性。

1、客户端（Client）：服务调用方（服务消费者）。
2、客户端存根（Client Stub）：存放服务端地址信息，将客户端的请求参数数据信息打包成网络消息，再通过网络传输发送给服务端。
3、服务端存根（Server Stub）：接收客户端发送过来的请求消息并进行解包，然后再调用本地服务进行处理。
4、服务端（Server）：服务的真正提供者。

53 RPC具体调用过程

1、服务消费者（client客户端）通过调用本地服务的方式调用需要消费的服务；
2、客户端存根（client stub）接收到调用请求后负责将方法、入参等信息序列化（组装）成能够进行网络传输的消息体；
3、客户端存根（client stub）找到远程的服务地址，并且将消息通过网络发送给服务端；
4、服务端存根（server stub）收到消息后进行解码（反序列化操作）；
5、服务端存根（server stub）根据解码结果调用本地的服务进行相关处理；
6、本地服务执行具体业务逻辑并将处理结果返回给服务端存根（server stub）；
7、服务端存根（server stub）将返回结果重新打包成消息（序列化）并通过网络发送至消费方；
8、客户端存根（client stub）接收到消息，并进行解码（反序列化）；
9、服务消费方得到终结果；而RPC框架的实现目标则是将上面的第2-10步完好地封装起来，也就是把调用、编码/解码的过程给封装起来，让用户感觉上像调用本地服务一样的调用远程服务。