计算机网络核心面试题

OSI开放式互联参考模型

第1层:物理层 两台物理机之间的通信需求。一台机器给另一台机器传输Bit流,另一台机器也能收到Bit流。物理层主要定义了物理设备的标准,如网线的类型,光纤的接口类型,各种传输介质的传输速率等。网卡就是工作在这一层。

第2层:数据链路层 在传输Bit流的过程当中,会出现错传,数据传输丢失等情况,数据链路层定义了如何格式化数据,以进行传输,以及如何控制对物理介质的访问。这一层通常还提供错误检测和纠正,以确保数据传输的可靠性。这一层将Bit流转组成帧,交换机就工作在这一层。

第3层:网络层 将网络地址翻译成对应的物理地址,并决定如何将数据从发送方路由到接收方。网络层通过综合考虑发送优先权,网络拥塞程度,服务质量以及可选路由的花费来决定从一个网络中节点A到另一个网络中节点B的最佳路径。由于网络层处理并智能指导数据传送,路由器属于网络层。这一层的数据单位为数据包,这一层的主要协议是TCP/IP协议当中的IP协议,

第4层:传输层解决了主机间的数据传输,数据间传输可以是不同网络的,传输层解决了传输质量的问题。传输协议同时进行流量控制,或是基于接收方可接受数据的快慢程度,规定适当的发送速率。除此之外,传输层按照网络能处理的最大尺寸,将较长的数据包进行强制分割,例如以太网无法接受大于1500字节的数据包,发送方节点的传输层将数据分割成较小的数据片,同时每一个数据片安排一个序列号,以便数据到达接收方节点的传输层时能以正确的顺序重组,该过程即成为排序,传输层中需要我们关注的协议有TCP协议和UDP协议。此时,已经可以保证给正确的计算机发送正确的数据。

第5层:会话层 建立和管理应用程序之间的通信。

第6层:在表示层数据将按照网络能理解的方式进行格式化,这种格式化也因所使用的网络类型的不同而不同。

第7层:应用层  经过之前各层的处理,虽然发送方知道自己发送的是什么东西,转换成字节数据有多长,但是接收方不知道。所以应用层网络协议就是规定发送方和接受方必须使用一个固定长度的消息头消息头必须使用某种固定的组成,而且消息头里必须记录消息体的长度等信息。以便接收方能够正确的解析发送发送的数据,这一层的主要协议就是HTTP协议。

OSI并不是一个标准,而是在自定义标准时所使用的的概念性框架。事实的标准时OSI的实现“TCP/IP”四层架构参考模型。

三次握手四次挥手

传输控制协议TCP简介

  • 面向连接的,可靠的,基于字节流的传输层通信协议
  • 将应用层的字节流分割成报文段并发送给目标节点的TCP层
  • 数据包都有序号,对方收到则发送ACK确认,未收到则认为发送失败,就需要重传。
  • 使用校验函数和来校验数据在传输过程中是否有误,在发送和接受时都要校验。

TCP报文头

TCP和UDP的数据包都是不包含IP地址信息的,因为那是IP层的事,但是TCP和UDP都是有源端口和目的端口,端口是属于传输层的范畴的。两个进程在计算机中进行数据通信, 可以用管道,内存共享,信号量,消息队列等方式,两个进程能进行通信最基本的要求就是能够唯一标识一个进程,本地可以使用PID即进程标识符老唯一表示一个进程,但是PID只在本地唯一,如果是在两台机多台计算机之间PID就不可以了,所以多态计算机之间的实现进程间的通信的时候,在传输层使用协议端口来唯一标识一个进程的。ip层的IP可以唯一标识一个主机,而TCP协议和端口号可以唯一标识主机中的进程,这样就可以使用ip地址,协议,端口来标识网络中的一个进程,这就是套接字。

Sequence Number : TCP连接中传送的字节流中的每个字节都按顺序去编号。我已经发送了前100字节的数据,那么我下一个发送的包(如果发送窗口还有空间)的SEQ就是101,比如要发送10字节的数据,那么下一个包中的数据的字节编号就是 101 - 110. 之后如果继续发送的话,序号就是从111开始。

如果接收端接到了这个10字节的包的话,便会返回一个 ACK 为 111 的包,表示前面110个字节已经成功接收。

为什么需要三次握手才能建立起连接,为了初始化Sequence Number,通信双方都要通知对方自己初始化的Sequence Number的值,这个值是要作为以后数据通信的序号。以保证应用层接受到的数据不会应为网络上的传输而乱序。即TCP会用这个序号拼接数据。

首次握手的隐患----SYN超时

Server收到Client发送的SYN,然后Client就掉线了,回复了SYN-ACK的时候没有收到ACK的确认,此时的链接处于一个中间状态。一段时间后,Server会重发SYN-ACK确认,Linux的重试次数为5次数,重试间隔为第一次1秒,第二次2秒,第三次4秒,8秒,16秒,这是31秒,在这会后还要等待32秒之后,还是没有确认应答,此时就判定连接超时。一共等待是63秒。

这样的链接超时问题就有可能受到SYN Flood的攻击。恶意程序会给服务器发送一个SYN报文,然后就下线,服务器就会等待63秒的时间,这样的多次操作就会把服务器的SYN连接的队列耗尽,使得正常的连接请求不能处理。Linux下就给出了个tcp_syncookie参数来应对这个问题。当SYN队列满后,TCP会通过原地址端口,目标地址端口和时间戳打造出一个特别的Sequence Number发回去,这个Sequence Number简称SYN Cookie,如果是攻击者是不会有反应的,但是如果是正常连接就会再次的把SYN Cookie 发回到服务器,服务器就会根据这个Cookie继续建立连接,即使是SYN队列满了,也是可以继续建立连接的。

建立链接后,Client出现故障怎么办?

TCP设有保活机制,在一段时间(保活时间)内,连接处于非活动状态,开启保活功能的一端会向另一端发送一个保活探测报文,如果发送端没有收到响应报文,那么经过一个已经提前配置好的保活时间间隔将继续发送保活探测报文,直到发送探测报文的次数达到保活探测数,这时对方主机将被确认位不可达,连接也将被中断。

四次挥手

为什么会有TIME-WAIT状态

原因:

  • 确保有足够的时间让对端受到ACK包。如果被动关闭的那一端没有受到ACK,就会触发被动端重发FIN包,这样的一来一去就正好是2个MSL时间。
  • 避免新旧连接混淆。有足够的时间不会和后面的链接混淆到一起,因为有些路由器会缓存IP数据包,如果连接别重用了,这些延迟受到的包就有可能跟新连接混在一起。

为什么需要四次挥手才能断开连接

因为TCP是全双工的,发送发和接收方都需要FIN报文和ACK报文,也就是发送方和接收方各只需要两次挥手,只不过有一方是被动的,所以看上去就是四次。

服务器出现大量CLOSE_WAIT状态的原因

在linux服务器Socket通信时频繁出现大量CLOSE_WAIT的原因,问题的其中一个表现是客户端 一直在请求,但是返回给客户端的信息是异常的,服务端压根也没有收到请求。在图中看到,服务器出现大量的CLOSE_WAIT是在服务器接收到FIN报文后,服务器没有进一步发送ACK,或者IFN报文确认。也即是说在对方关闭Socket连接后,程序里没有检测到,或者是本身这个时候需要关闭连接,于是这个资源就一直被程序占用着,遇到这个问题多数是程序有BUG,可能是程序里有一些资源没有被释放或者是线程池当中的线程配置不合理。

UDP简介

UDP特点

  • 面向非连接的:传输数据之前,源端和中断没有建立连接,当他要传送数据时,就简单的抓取来自应用程序的数据,并尽可能快的把它扔到楼上,在发送端,UDP传送数据的速度仅仅受程序生成数据的速度,计算机的能力和传输带宽的限制,在接收端,UDP把每个消息放在队列中,应用程序从队列中读取消息即可。
  • 由于传输数据不建立连接,因此也就不维护连接状态,收发状态等,由此一台服务器可以同时向多台客户端传输相同的数据。
  • 数据包报头短,只有8个字节,额外开销小。
  • 吞吐量只受限于程序的数据生成速率,传输速率以及机器性能。
  • 尽最大努力交付,不保证可靠交付,不需要维持复杂的链接状态表。
  • 面向报文,不对应用程序提交的报文信息进行拆分或者合并,只是保留数据的边界,因此应用程序需要选择合适的报文大小。

TCP和UDP的区别

TCP

DUP

面向连接

无连接

保证可靠性

不保证可靠性

有序

无序

速度慢

速度快

重量级

轻量级

TCP滑动窗口

RTT:发送一个数据包到接受到对应的ACK,所花费的时间

RTO:重传时间间隔:TCP在发送一个数据包后,会启动一个重传定时器,而RTO就是这定时器的重传时间。也就是发送数据包后,如果收到了ACK ,那么这个重传定时器就失效,不需要重传,如果是没有收到ACK包,重传定时期限也到了,就需要重传。RTO是通过RTT计算出来的。

TCP使用滑动窗口做流量控制与乱序重排。

  • 保证TCP的可靠性
  • 保证TCP的流控特性

可以看到在LastByteRcvd到NextByteExtected之间有一些Sequence还没有到达,对应的是空白的区域,此时可以根据上面的数值计算出接收方的AdvertisedWindow的大小,之后会发给发送端让其算出返送方的剩余可发送的数据的大小,即EffectiveWindow的大小。

AdvertisedWindow = MaxRcvBuffer – (LastByteRcvd - LastByteRead) =得出还能够接受的数据量

MaxRcvBuffer:接收端缓冲池的大小

(LastByteRcvd - LastByteRead) :为已经占据的缓存

EffectiveWindow = AdvertisedWindow – (LastByteSent – LastByteAcked) = 还能够继续发送的数据量

TCP滑动窗口的基本原理

TCP发送方

滑动窗口的组成是已经发送但还没有被确认的数据段和还没有发送但是他的大小是接受缓冲区-已发送未确认数据段大小的差的大小,也就是没有发送但是允许发送的数据段的差值组成,图中为32到51,。假设,32到38是未确认字节,如果32到35之间的所有的字节连续的都被确认,窗口才会向右滑动,只要是32到35之间的任意给一个没有被确认,窗口都不会滑动,当前面的数据被确认,窗口滑动确认数据长度的长度,这一部分数据才会被发送。

TCP接收方

TCP最基本的传输可靠性来源于确认重传机制,TCP的滑动窗口机制也是建立在这一基础之上。

滑动窗口的大小可以依据一定的策略动态调整,应用自身处理能力的变化,通过本端TCP接受窗的大小的控制,来实现对端的发送窗口进行流量限制。

HTTP简介

HTTP超文本传输协议是属于应用层的协议,他是基于请求与响应的无状态的应用层的协议,常基于TCP的连接方式。

特点:

  • 支持客户/服务器模式
  • 简单快速
  • 灵活
  • 无连接:限制每次连接只处理一个请求,服务器收到客户的请求并响应客户端后就断开连接。  1.1 以后是使用了一些手段保持HTTP连接保持一段时间,但那是HTTP之外的一些,你不知道HTTP现在是否处于连接状态还是发送请求后重新建立的链接。
  • 无状态:是指对事务处理没有记忆能力,缺少状态意味着后续处理需要之前的信息,则需要重传,这样导致每次连接传送的数据量增大。另一方面服务器不需要先前信息的时候应答速度较快。

HTTP请求结构

HTTP的响应结构

HTTP请求定义了web客户端如何从web服务器请求web页面以及服务器怎样把web页面传送给客户端。

HTTP协议采用了请求响应模型,客户端向服务器发送一个请求报文,请求报文包含请求的方法,URL,协议版本,请求头部,和请求数据,服务器以一个状态行作为响应,响应的内容的包括协议的版本, 成功或者错误的代码,服务器信息,响应头部和响应数据。

HTTP请求/响应的步骤:

  • 客户端连接到web服务器,建立一个套接字连接
  • 发送HTTP 请求,即通过TCP套接字客户端向服务器发送一个文本的套接字请求
  • 服务器接收到请求并返回HTTP响应
  • 释放TCP连接
  • 客户端浏览器解析HTML内容

Get请求和Post请求的区别

  • HTTP报文层面:Get将请求信息放在URL当中,Post放在报文体中。
  • 数据库层面:Get符合幂等性和安全性,Post不符合。幂等性是对数据库的一次操作和多次操作获得的结果是一致的。安全性的操作是对数据库的操作没有改变数据库中的数据。
  • 其他层面,Get可以被缓存,被存储,而post不行

Cookie和Session的区别

Cookie ,客户端的解决方案

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

Session简介

  • 服务器端的机制,在服务器上 保存信息
  • 解析客户端请求并操作session id,按需要保存状态信息。首先看客户端的请求当中有没有携带Sessionid,如果有根据sessionid去服务器上查找相应的session,如果没有,就创建一个session,然后生成一个唯一的,且不容易被找到规律的字符串,这个id将会在会发给客户端。

区别

  • Cookie数据存放在客户端浏览器,Session数据存放在服务器
  • Session相对于Cookie更安全
  • 若考虑减轻服务器负担,应当使用Cookie

Http和HTTPS的区别

HTTPS:超文本安全传输协议,是一种以计算机网络安全通信为目的的传输协议。在HTTPS当中有一个SSL层,从而具有了保护交换数据隐私以及完整性,提供对网站身份验证的功能。

SSL(Security Sockets Layer,安全套接层)

  • 为网络通信提供安全及数据完整性的一种安全协议。
  • 是操作系统对外的API,SSL3.0之后更名为TLS
  • 采用身份认证和数据加密保证网络通信的安全和数据的完整性

HTTPS数据的传输流程

HTTPS在进行数据传输之前,会与网站浏览器和web服务器进行一次握手,在握手时确定双方的加密密码信息:

  • 浏览器将支持的加密算法信息发送给服务器
  • 服务器选择一套浏览器支持的加密算法,以证书的形式回发给浏览器,证书的信息包含证书发布的机构,证书的有效期,公钥证书所有者,还有签名等。
  • 浏览器收到证书后首先需要验证证书的合法性,证书受到浏览器的信任后,web浏览器会随机生成一串密码,并使用证书中的公钥加密,之后就是使用约定好的hash算法握手消息,并生成随机数对消息加密,在将之前生成的消息发送个服务器。
  • 服务器使用私钥解密信息,验证哈希,加密响应消息发挥给浏览器。
  • 客户端浏览器解密并计算经过哈希算法加密的握手消息,如果与服务器发送过来的哈希值一致,则次握手过程结束后,服务器与浏览器会使用之前浏览器生成的随机密码和对称加密算法进行加密,然后交换数据。

区别

  • HTTPS需要CA申请证书,HTTP不需要
  • HTTPS密文传输,HTTP明文传输
  • 连接方式不同,HTTPS默认使用443端口,HTTP使用80端口
  • HTTPS=HTTP+加密+认证+完整性保护,较HTTP安全

HTTPS也未必就一定安全,浏览器默认填充的是http://,这样一些用户在访问网站的时候直接就从www。开始,所以很多就直接从HTTP开始了。在网站中使用302,304跳转的时候,是从HTTP跳转到HTTPS,这个过程中会使用到HTTP,就有被劫持的风险。这事就要使用HSTS(HTTP Strict Transport Security)优化。

 

  • 1
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值