计算机网络必备基础知识

1 计算网络的体系结构

常用的是五层协议的体系结构,清晰方便实现。
在这里插入图片描述

2 HTTP和HTTPS的区别

Http协议运行在TCP之上,明文传输,客户端与服务器端都无法验证对方的身份;Https是身披SSL(Secure Socket Layer)外壳的Http,运行于SSL上,SSL运行于TCP之上,是添加了加密和认证机制的HTTP。二者之间存在如下不同:

端口不同:Http与Http使用不同的连接方式,用的端口也不一样,前者是80,后者是443;

资源消耗:和HTTP通信相比,Https通信会由于加减密处理消耗更多的CPU和内存资源;

开销:Https通信需要证书,而证书一般需要向认证机构购买;
 
Https的加密机制是一种对称加密和和公开密钥加密并用的混合加密机制。
在这里插入图片描述

3 对称加密和非对称加密

对称密钥加密是指加密和解密使用同一个密钥的方式,这种方式存在的最大问题就是密钥发送问题,即如何安全地将密钥发给对方;
非对称加密是指使用一对非对称密钥,即公钥和私钥,公钥可以随意发布,但私钥只有自己知道。发送密文的一方使用对方的公钥进行加密处理,对方接收到加密信息后,使用自己的私钥进行解密。
由于非对称加密的方式不需要发送用来解密的私钥,所以可以保证安全性;但是和对称加密比起来,它非常的慢,所以我们还是要用对称加密来传送消息,但对称加密所使用的密钥我们可以通过非对称加密的方式发送出去。

4 TCP三次握手和四次挥手

(1). 三次握手(我要和你建立链接,你真的要和我建立链接么,我真的要和你建立链接,成功):

第一次握手:Client将标志位SYN置为1,随机产生一个值seq=J,并将该数据包发送给Server,Client进入SYN_SENT状态,等待Server确认。

第二次握手:Server收到数据包后由标志位SYN=1知道Client请求建立连接,Server将标志位SYN和ACK都置为1,ack=J+1,随机产生一个值seq=K,并将该数据包发送给Client以确认连接请求,Server进入SYN_RCVD状态。

第三次握手:Client收到确认后,检查ack是否为J+1,ACK是否为1,如果正确则将标志位ACK置为1,ack=K+1,并将该数据包发送给Server,Server检查ack是否为K+1,ACK是否为1,如果正确则连接建立成功,Client和Server进入ESTABLISHED状态,完成三次握手,随后Client与Server之间可以开始传输数据了。
      在这里插入图片描述

(2). 四次挥手(我要和你断开链接;好的,断吧。我也要和你断开链接;好的,断吧):

第一次挥手:Client发送一个FIN,用来关闭Client到Server的数据传送,Client进入FIN_WAIT_1状态。

第二次挥手:Server收到FIN后,发送一个ACK给Client,确认序号为收到序号+1(与SYN相同,一个FIN占用一个序号),Server进入CLOSE_WAIT状态。此时TCP链接处于半关闭状态,即客户端已经没有要发送的数据了,但服务端若发送数据,则客户端仍要接收。

第三次挥手:Server发送一个FIN,用来关闭Server到Client的数据传送,Server进入LAST_ACK状态。

第四次挥手:Client收到FIN后,Client进入TIME_WAIT状态,接着发送一个ACK给Server,确认序号为收到序号+1,Server进入CLOSED状态,完成四次挥手。
注意:计算机收到服务器的确认之后,启动2MSL定时器,在time_wait状态还需再等2MSL,才会close。防止第四步的确认数据包丢失,万一确认服务器没有收到,服务器再发送FIN时,客户端还能给服务器确认。
在这里插入图片描述
状态迁移过程:
客户端:CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED
服务端:CLOSED -> LISTEN->SYN_RECEIVED->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSE            
在这里插入图片描述

5 为什么TCP链接需要三次握手,两次不可以么,为什么?

为了防止 已失效的链接请求报文突然又传送到了服务端,因而产生错误。
客户端发出的连接请求报文并未丢失,而是在某个网络节点长时间滞留了,以致延误到链接释放以后的某个时间才到达Server。这是,Server误以为这是Client发出的一个新的链接请求,于是就向客户端发送确认数据包,同意建立链接。若不采用“三次握手”,那么只要Server发出确认数据包,新的链接就建立了。由于client此时并未发出建立链接的请求,所以其不会理睬Server的确认,也不与Server通信;而这时Server一直在等待Client的请求,这样Server就白白浪费了一定的资源。若采用“三次握手”,在这种情况下,由于Server端没有收到来自客户端的确认,则就会知道Client并没有要求建立请求,就不会建立链接。
上面是一位博主的答案,但是我觉得上面的解释好像不太合理吧,握手时的通信包有syn标志位,这个延迟的数据包没有syn标志位的话,服务端就是到不是在建立连接。
我觉得应该这样来解释:
三次握手是保证,服务端知道客户端能收到它的消息,客户端知道服务端能收到它的消息的最少的通信次数。

6 为什么需要四次挥手

因为TCP连接是全双工的,所以要分别终止。
1、当主机A确认发送完数据且知道B已经接受完了,想要关闭发送数据口(当然确认信号还是可以发),就会发FIN给主机B。
2、主机B收到A发送的FIN,表示收到了,就会发送ACK回复。
3、但这是B可能还在发送数据,没有想要关闭数据口的意思,所以FIN与ACK不是同时发送的,而是等到B数据发送完了,才会发送FIN给主机A。
4、A收到B发来的FIN,知道B的数据也发送完了,回复ACK, A等待2MSL以后,没有收到B传来的任何消息,知道B已经收到自己的ACK了,A就关闭链接,B也关闭链接了。

7 TCP协议如何来保证传输的可靠性

TCP提供一种面向连接的、可靠的字节流服务。其中,面向连接意味着两个使用TCP的应用(通常是一个客户和一个服务器)在彼此交换数据之前必须先建立一个TCP连接。在一个TCP连接中,仅有两方进行彼此通信;而字节流服务意味着两个应用程序通过TCP链接交换8bit字节构成的字节流,TCP不在字节流中插入记录标识符。

对于可靠性,TCP通过以下方式进行保证:

数据包校验: 目的是检测数据在传输过程中的任何变化,若校验出包有错,则丢弃报文段并且不给出响应,这时TCP发送数据端超时后会重发数据;
对失序数据包重排序: 既然TCP报文段作为IP数据报来传输,而IP数据报的到达可能会失序,因此TCP报文段的到达也可能会失序。TCP将对失序数据进行重新排序,然后才交给应用层;
丢弃重复数据: 对于重复数据,能够丢弃重复数据;
应答机制: 当TCP收到发自TCP连接另一端的数据,它将发送一个确认。这个确认不是立即发送,通常将推迟几分之一秒;
超时重发: 当TCP发出一个段后,它启动一个定时器,等待目的端确认收到这个报文段。如果不能及时收到一个确认,将重发这个报文段;
流量控制: TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据,这可以防止较快主机致使较慢主机的缓冲区溢出,这就是流量控制。TCP使用的流量控制协议是可变大小的滑动窗口协议。

8 客户端不断进行请求链接会怎样?DDos(Distributed Denial of Service)攻击?

服务器端会为每个请求创建一个链接,并向其发送确认报文,然后等待客户端进行确认
1)、DDos 攻击
客户端向服务端发送请求链接数据包
服务端向客户端发送确认数据包
客户端不向服务端发送确认数据包,服务器一直等待来自客户端的确认
2)、DDos 预防 ( 没有彻底根治的办法,除非不使用TCP )
限制同时打开SYN半链接的数目
缩短SYN半链接的Time out 时间
关闭不必要的服务

9 TCP与UDP的区别

TCP (Transmission Control Protocol)和UDP(User Datagram Protocol)协议属于传输层协议,它们之间的区别包括:

  • TCP是面向连接的,UDP是无连接的;
  • TCP是可靠的,UDP是不可靠的;
  • TCP只支持点对点通信,UDP支持一对一、一对多、多对一、多对多的通信模式;
  • TCP是面向字节流的,UDP是面向报文的;
  • TCP有拥塞控制机制;UDP没有拥塞控制,适合媒体通信;
  • TCP首部开销(20个字节)比UDP的首部开销(8个字节)要大;

10 从输入网址到获得页面的过程

(1). 浏览器查询 DNS,获取域名对应的IP地址:具体过程包括浏览器搜索自身的DNS缓存、搜索操作系统的DNS缓存、读取本地的Host文件和向本地DNS服务器进行查询等。对于向本地DNS服务器进行查询,如果要查询的域名包含在本地配置区域资源中,则返回解析结果给客户机,完成域名解析(此解析具有权威性);如果要查询的域名不由本地DNS服务器区域解析,但该服务器已缓存了此网址映射关系,则调用这个IP地址映射,完成域名解析(此解析不具有权威性)。如果本地域名服务器并未缓存该网址映射关系,那么将根据其设置发起递归查询或者迭代查询;
(2). 浏览器获得域名对应的IP地址以后,浏览器向服务器请求建立链接,发起三次握手;
(3). TCP/IP链接建立起来后,浏览器向服务器发送HTTP请求;
(4). 服务器接收到这个请求,并根据路径参数映射到特定的请求处理器进行处理,并将处理结果及相应的视图返回给浏览器;
(5). 浏览器解析并渲染视图,若遇到对js文件、css文件及图片等静态资源的引用,则重复上述步骤并向服务器请求这些资源;
(6). 浏览器根据其请求到的资源、数据渲染页面,最终向用户呈现一个完整的页面。
在这里插入图片描述

11 网络层的ARP协议工作原理

网络层的ARP协议完成了IP地址与物理地址的映射。首先,每台主机都会在自己的ARP缓冲区中建立一个ARP列表,以表示IP地址和MAC地址的对应关系。当源主机需要将一个数据包要发送到目的主机时,会首先检查自己ARP列表中是否存在该IP地址对应的MAC地址:如果有,就直接将数据包发送到这个MAC地址;如果没有,就向本地网段发起一个ARP请求的广播包,查询此目的主机对应的MAC地址。此ARP请求数据包里包括源主机的IP地址、硬件地址、以及目的主机的IP地址。网络中所有的主机收到这个ARP请求后,会检查数据包中的目的IP是否和自己的IP地址一致。如果不相同就忽略此数据包;如果相同,该主机首先将发送端的MAC地址和IP地址添加到自己的ARP列表中,如果ARP表中已经存在该IP的信息,则将其覆盖,然后给源主机发送一个ARP响应数据包,告诉对方自己是它需要查找的MAC地址;源主机收到这个ARP响应数据包后,将得到的目的主机的IP地址和MAC地址添加到自己的ARP列表中,并利用此信息开始数据的传输。如果源主机一直没有收到ARP响应数据包,表示ARP查询失败。

12 IP地址

A:前8位网络号,后24位主机号,以0开头
B:前16位网络号,后16位主机号,以10开头
C:前24位网络号,后8位主机号,以110开头
D:多播地址,1110开头
E:保留地址,1111开头

全是0的主机号代表网络本身
全是1的主机号代表广播,用于向该网络中所有主机发送消息;
以十进制127开头的地址是环回地址,目的地址是环回地址的
在这里插入图片描述

13 子网掩码

32位地址,1表示网络位,0表示主机位;指明一个IP地址的哪些位标识的是主机所在的子网以及哪些位标识是主机的位掩码,必须和IP地址结合使用;
作用:将某个Ip地址分成网络地址和主机地址;

14 IP地址与物理地址

物理地址是数据链路层和物理层使用的地址,IP地址是网络层和以上各层使用的地址,是一种逻辑地址,其中ARP协议用于IP地址与物理地址的对应。

15 常见状态码及原因短语

HTTP请求结构: 请求方式 + 请求URI + 协议及其版本
HTTP响应结构: 状态码 + 原因短语 + 协议及其版本

1×× : 请求处理中,请求已被接受,正在处理
2×× : 请求成功,请求被成功处理
200 OK
3×× : 重定向,要完成请求必须进行进一步处理
301 : 永久性转移
302 :暂时性转移
304 : 已缓存
4×× : 客户端错误,请求不合法
400:Bad Request,请求有语法问题
403:拒绝请求
404:客户端所访问的页面不存在
5×× : 服务器端错误,服务器不能处理合法请求
500 :服务器内部错误
503 : 服务不可用,稍等

16 Cookie和Session和Application

在这里插入图片描述
Application:
Application用于保存所有用户的公共的数据信息,如果使用Application对象,一个需要考虑的问题是任何写操作都要在 Application_OnStart事件(global.asax)中完成.尽管使用Application.Lock和 Applicaiton.Unlock方法来避免写操作的同步,但是它串行化了对Application对象的请求,当网站访问量大的时候会产生严重的性 能瓶颈.因此最好不要用此对象保存大的数据集合
Cookie和Session的区别:

  1. 由于HTTP协议是无状态的协议,所以服务端需要记录用户的状态时,就需要用某种机制来识具体的用户,这个机制就是Session.典型的场景比如购物车,当你点击下单按钮时,由于HTTP协议无状态,所以并不知道是哪个用户操作的,所以服务端要为特定的用户创建了特定的Session,用用于标识这个用户,并且跟踪用户,这样才知道购物车里面有几本书。这个Session是保存在服务端的,有一个唯一标识。在服务端保存Session的方法很多,内存、数据库、文件都有。集群的时候也要考虑Session的转移,在大型的网站,一般会有专门的Session服务器集群,用来保存用户会话,这个时候 Session 信息都是放在内存的,使用一些缓存服务比如Memcached之类的来放 Session。
  2. 思考一下服务端如何识别特定的客户?这个时候Cookie就登场了。每次HTTP请求的时候,客户端都会发送相应的Cookie信息到服务端。实际上大多数的应用都是用 Cookie 来实现Session跟踪的,第一次创建Session的时候,服务端会在HTTP协议中告诉客户端,需要在 Cookie 里面记录一个Session ID,以后每次请求把这个会话ID发送到服务器,我就知道你是谁了。有人问,如果客户端的浏览器禁用了 Cookie 怎么办?一般这种情况下,会使用一种叫做URL重写的技术来进行会话跟踪,即每次HTTP交互,URL后面都会被附加上一个诸如 sid=xxxxx 这样的参数,服务端据此来识别用户。
  3. Cookie其实还可以用在一些方便用户的场景下,设想你某次登陆过一个网站,下次登录的时候不想再次输入账号了,怎么办?这个信息可以写到Cookie里面,访问网站的时候,网站页面的脚本可以读取这个信息,就自动帮你把用户名给填了,能够方便一下用户。这也是Cookie名称的由来,给用户的一点甜头。
    所以,总结一下:
    Session是在服务端保存的一个数据结构,用来跟踪用户的状态,这个数据可以保存在集群、数据库、文件中;
    Cookie是客户端保存用户信息的一种机制,用来记录用户的一些信息,也是实现Session的一种方式。

17 常见的路由选择协议,以及它们的区别

常见的路由选择协议有:RIP协议、OSPF协议。
RIP协议: 底层是贝尔曼福特算法,它选择路由的度量标准(metric)是跳数,最大跳数是15跳,如果大于15跳,它就会丢弃数据包。
OSPF协议: 底层是迪杰斯特拉算法,是链路状态路由选择协议,它选择路由的度量标准是带宽,延迟。

18 TCP拥塞处理机制

计算机网络中的带宽、交换结点中的缓存及处理机等都是网络的资源。在某段时间,若对网络中某一资源的需求超过了该资源所能提供的可用部分,网络的性能就会变坏,这种情况就叫做拥塞。拥塞控制就是 防止过多的数据注入网络中,这样可以使网络中的路由器或链路不致过载。注意,拥塞控制和流量控制不同,前者是一个全局性的过程,而后者指点对点通信量的控制。拥塞控制的方法主要有以下四种:

1). 慢启动:不要一开始就发送大量的数据,先探测一下网络的拥塞程度,也就是说由小到大逐渐增加拥塞窗口的大小;

2). 拥塞避免:拥塞避免算法让拥塞窗口缓慢增长,即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1,而不是加倍,这样拥塞窗口按线性规律缓慢增长。
在这里插入图片描述
3). 快重传:快重传要求接收方在收到一个 失序的报文段 后就立即发出 重复确认(为的是使发送方及早知道有报文段没有到达对方)而不要等到自己发送数据时捎带确认。快重传算法规定,发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段,而不必继续等待设置的重传计时器时间到期。
在这里插入图片描述
4). 快恢复:快重传配合使用的还有快恢复算法,当发送方连续收到三个重复确认时,就执行“乘法减小”算法,把ssthresh门限减半,但是接下去并不执行慢开始算法:因为如果网络出现拥塞的话就不会收到好几个重复的确认,所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法,而是将cwnd设置为ssthresh的大小,然后执行拥塞避免算法。
在这里插入图片描述

参考文献:

  1. 面试/笔试第一弹 —— 计算机网络面试问题集锦
  2. TCP拥塞控制的问题? - 车小胖的回答 - 知乎
  3. COOKIE和SESSION有什么区别? - 轩辕志远的回答 - 知乎
已标记关键词 清除标记
©️2020 CSDN 皮肤主题: 设计师:Lavi_qq_2910138025 返回首页