计算机网络知识点梳理
网络层协议
七层:物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。
五层:物理层、数据链路层、网络层、运输层、应用层。
七层网络体系结构 | 任务 | 功能 | 传输单位 | 实现硬件 | 协议 |
---|---|---|---|---|---|
物理层 | 传比特流传比特流 | 为数据段设备提供传送数据通路为数据段设备 | 比特 | 集线器、中继器 | |
数据链路层 | 将IP报文封装成帧 | 链路连接的建立、拆除和分离;帧定界和帧同步;差错检测 | 帧 | 交换机、网桥 | PPP、STP、ARQ |
网络层 | 将传输层的报文封装成分组;选择路由,将报文交付到目的主机。 | 为传输层提供服务;组包和拆包;路由选择;拥塞控制 | 数据段 | 路由器 | ICMP、ARP、IP、IGMP、OSPF |
传输层 | 负责主机中两个进程的通信 | 为端到端连接提供可靠的服务;为端到端连接提供流量控制、差错控制、服务质量管理等 | 报文段(TCP)、用户数据报(UDP) | TCP、UDP | |
会话层 | 不同主机各进程间的对话 | 管理主机间的会话进程,端到端服务。 | |||
表示层 | 负责处理两个内部数据表示结构不同的通信系统间交换信息的表示格式。 | 为数据加密和解密;为提高传输效率提供必需的数据压缩和解压。 | |||
应用层 | 提供系统与用户的接口 | 文件传输;访问和管理;电子邮件服务 | FTP、SMTP、POP3、HTTP、DNS |
应用层
DNS
DNS的定义
DNS的全称是domain name system,即域名系统。DNS是因特网上作为域名和IP地址相互映射的一个分布式数据库,能够使用户更方便的去访问互联网而不用去记住能够被机器直接读取的IP地址。
DNS要做的就是将域名解析成IP。
DNS解析域名的过程
- 在浏览器中输入 www.baidu.com 域名,操作系统会先检查自己本地的hosts文件是否有这个域名的映射关系,如果有,就先调用这个IP地址映射,完成域名解析;
- 如果hosts文件中没有,则查询本地DNS解析器缓存,如果有,则完成地址解析;
- 如果本地DNS解析器缓存中没有,则去查找本地DNS服务器,如果查到,完成解析。
- 如果没有,则本地服务器会向根域名服务器发起查询请求。根域名服务器会告诉本地域名服务器去查询哪个顶级域名服务器;
- 本地域名服务器向顶级域名服务器发起查询请求,顶级域名服务器会告诉本地域名服务器去查找哪个权限域名服务器;
- 本地域名服务器向权限域名服务器发起查询请求,权限域名服务器告诉本地域名服务器www.baidu.com 所对应的IP地址;
- 本地域名服务器告诉主机www.baidu.com 所对应的IP地址。
主机向本地域名服务器的查询一般是采用递归查询,而本地域名服务器向根域名的查询一般是采用迭代查询。
递归查询:主机向本地域名发送查询请求报文,而本地域名服务器不知道该域名对应的IP地址时,本地域名会继续向根域名发送查询请求报文,不是通知主机自己向根域名发送查询请求报文。
迭代查询:本地域名服务器向根域名发出查询请求报文后,根域名不会继续向顶级域名服务器发送查询请求报文,而是通知本地域名服务器向顶级域名发送查询请求报文。
URI和URL的区别
URI(Uniform Resource Identifier) :中文全称为统一资源标志符,主要作用是唯一标识一个资源。
URL(Uniform Resource Location) :中文全称为统一资源定位符,主要作用是提供资源的路径。
有个经典的比喻是URI像是身份证,可以唯一标识一个人,而URL更像一个住址,可以通过URL找到这个人。
HTTP
HTTP请求方法
方法 | 作用 |
---|---|
GET | 获取资源 |
POST | 传输实体主体 |
PUT | 上传文件 |
DELETE | 删除文件 |
HEAD | 和GET方法类似,但只返回报文首部,不返回报文实体主体部分 |
PATCH | 对资源进行部分修改 |
OPTIONS | 查询指定的URL支持的方法 |
CONNECT | 要求用隧道协议连接代理 |
TRACE | 服务器会将通信路径返回给客户端 |
GET和POST的差别
作用
GET用于获取资源,POST用于传输实体主体。GET相当于SELECT,POST相当于CREATE。
参数位置
GET的参数放在URL中,POST的参数存储在实体主体中,并且GET方法提交的请求的URL中的数据做多是2048字节,POST请求没有大小限制。
安全性
GET方法因为参数放在URL中,安全性相对于POST较差一些。
幂等性
GET方法是具有幂等性的,而POST方法不具有幂等性。这里幂等性指客户端连续发出多次请求,收到的结果都是一样的。
POST和PUT的区别
POST相当于CREATE,PUT相当于UPDATE。
二者都用于请求数据的更新和创建。
但二者最本质的区别在于POST不是幂等的,而PUT是幂等的。即PUT多次返回结果是一样的,但POST多次会返回不同的对象。POST由服务器来指定地址,而PUT是用户指定的。
比如一个用户要对一个账号反复修改密码,就要用PUT,而一个用户想要创建多个账号,就要用POST。
HTTP状态码
1XX:信息性状态码,表示接受的请求正在处理
100 Continue:表示正常,客户端可以继续发送请求
101 Switching Protocols:切换协议,服务器根据客户端的请求切换协议。2XX:成功状态码,表示请求正常处理完毕
200 OK:请求成功
201 Created:已创建,表示成功请求并创建了新的资源
202 Accepted:已接受,已接受请求,但未处理完成。
204 No Content:无内容,服务器成功处理,但未返回内容。
205 Reset Content:重置内容,服务器处理成功,客户端应重置文档视图。
206 Partial Content:表示客户端进行了范围请求,响应报文应包含Content-Range指定范围的实体内容3XX:重定向状态码,表示需要进行附加操作以完成请求
301 Moved Permanently:永久性重定向
302 Found:临时重定向
303 See Other:和301功能类似,但要求客户端采用get方法获取资源
304 Not Modified:所请求的资源未修改,服务器返回此状态码时,不会返回任何资源。
305 Use Proxy:所请求的资源必须通过代理访问
307 Temporary Redirect: 临时重定向,与302类似,要求使用get请求重定向。4XX:客户端错误码,服务器无法处理请求
400 Bad Request:客户端请求的语法错误,服务器无法理解。
401 Unauthorized:表示发送的请求需要有认证信息。
403 Forbidden:服务器理解用户的请求,但是拒绝执行该请求。
404 Not Found:服务器无法根据客户端的请求找到资源。
405 Method Not Allowed:客户端请求中的方法被禁止
406 Not Acceptable:服务器无法根据客户端请求的内容特性完成请求
408 Request Time-out:服务器等待客户端发送的请求时间过长,超时5XX:服务器错误码,服务器处理请求出错
500 Internal Server Error:服务器内部错误,无法完成请求
501 Not Implemented:请求方法不被服务器支持,或无法处理。
502 Bad Gateway:服务器作为网关需要得到一个处理这个请求的响应,但是得到一个错误的响应。
503 Service Unavailable:服务器没有准备好处理请求。 常见原因是服务器因维护或重载而停机。
504 Gateway Timeout:当服务器作为网关,不能及时得到响应时返回此错误代码。
HTTP 与 HTTPS 的区别
HTTP | HTTPS | |
---|---|---|
端口 | 80 | 443 |
安全性 | 无加密,安全性较差 | 有加密机制,安全性较高 |
资源消耗 | 较少 | 由于加密处理,资源消耗更多 |
是否需要证书 | 不需要 | 需要 |
协议 | 运行在TCP协议之上 | 运行在SSL协议之上,SSL运行在TCP协议之上 |
HTTPS
加密过程
HTTPS使用混合加密方式,使用非对称加密来传输对称密钥来保证安全性,使用对称加密来保证通信的效率。
- 客户端向服务端发起第一次握手请求,告诉服务端客户端所支持的SSL的指定版本、加密算法及密钥长度等信息。
- 服务端将自己的公钥发给数字证书认证机构,数字证书认证机构利用自己的私钥对服务器的公钥进行数字签名,并给服务器颁发公钥证书。
- 服务端将证书发给客服端。
- 客服端利用数字认证机构的公钥,向数字证书认证机构验证公钥证书上的数字签名,确认服务器公开密钥的真实性。
- 客服端使用服务端的公开密钥加密自己生成的对称密钥,发给服务端。
- 服务端收到后利用私钥解密信息,获得客户端发来的对称密钥。
- 通信双方可用对称密钥来加密解密信息。
各版本区别
HTTP 1.0和HTTP 1.1
长连接
HTTP 1.1支持长连接和请求的流水线操作。
长连接是指不在需要每次请求都重新建立一次连接,HTTP 1.0默认使用短连接,每次请求都要重新建立一次TCP连接,资源消耗较大。
请求的流水线操作是指客户端在收到HTTP的响应报文之前可以先发送新的请求报文,不支持请求的流水线操作需要等到收到HTTP的响应报文后才能继续发送新的请求报文。
管道化(假并行传输)
当网络请求包含多个文本、图像、视频等资源时,HTTP1.1 支持并行发送。
但对处理器而言,必须按照客户端请求的先后顺序依次回送相应的结果,以保证客户端能够区分出每次请求的响应内容。
HTTP管道化可以把先进先出队列从客户端(请求队列)迁移到服务端(响应队列),但其并没有解决队头阻塞的问题。
支持响应请求的某部分资源
服务端可以只响应客户端请求对象的一部分。在HTTP 1.1中请求头引入了range头域,它支持只请求资源的某个部分,返回的状态码为206。
而在HTTP 1.0中会存在浪费带宽的现象,主要是因为不支持断点续传功能,客户端只是需要某个对象的一部分,服务端却将整个对象都传了过来。
如此可以优化网络带宽。
增加缓存处理,支持断点续传
HTTP1.1还加入了缓存处理(强缓存和协商缓存),新的字段如cache-control,支持断点传输,以及增加了Host字段(使得一个服务器能够用来创建多个Web站点)
HTTP2.0 新特性
二进制分帧
HTTP2.0通过在应用层和传输层之间增加一个二进制分层帧,突破了HTTP1.1解析是基于文本的性能限制,改进传输性能。
多路复用
一条TCP连接可以承载任意流量的双向数据流,数据流会被拆分成帧,乱序发送,然后再根据每个帧头部的流标识符(stream_id)重新封装。
现阶段浏览器的优化策略是,同时建立多个TCP的会话,实现真并行。
对并行性能的分析:
1. 并行连接可能会因为充分利用客户端的带宽从而提高加载速度; 2. 在客户端带宽不充足的情况下,并不会提高加载速度,而且并行连接会产生额外的开销; 3. 浏览器做的渐进式并行加载会让用户感觉加载速度快了。
header压缩
在HTTP 1.x中,header携带大量信息,并且每次都需要重新发送,HTTP 2.0采用编码的方式减小了header的大小,同时通信双方各自缓存一份header fields表,避免了header的重复传输。
服务端推送
客户端在请求一个资源时,会把相关资源一起发给客户端,这样客户端就不需要再次发起请求。
HTTP3.0 新特性
HTTP3.0是基于google的QUIC协议,而QUIC协议是使用UDP实现的。
QUIC协议特性:
0-RTT :传输层和加密层在0-RTT就能建立连接。
缓存当前会话的上下文,下次恢复会话的时候,只需要将之前的缓存传递给服务器,验证通过,就可以进行传输了。
多路复用
QUIC基于UDP,一个连接上的多个stream之间没有依赖,即使丢包,只需要重发丢失的包即可,不需要重传整个连接。
移动端表现更好
QUIC在移动端的表现比TCP好,因为TCP是基于IP识别连接,而QUIC是通过ID识别链接。 无论网络环境如何变化,只要ID不便,就能迅速重新连上。
报文加密认证
QUIC几乎所有报文头部都是经过认证的,报文Body都是经过加密的。
TCP协议头没有经过任何加密和认证,在传输过程中很容易被中间网络设备篡改、注入和窃听。
向前纠错机制
每个数据包除了它本身的内容之外还包括了其他数据包的数据,因此少量的丢包可以通过其他包的冗余数据直接组装而无需重传。
向前纠错牺牲了每个数据包可以发送数据的上限,但是优化了数据重传的时间消耗,提升了传输性能。
FTP
FTP协议就是用来传输文件的,而且仅仅用来传输文件。FTP的惟一工作就是确保文件正确的传输,除了校验发送和接收的文件是否一致以外,它不会像HTTP那样停下来翻译文件的内容。
FTP 使用两个并行的 TCP 连接来传输文件:
(1)控制连接(持久):传输控制信息,如用户标识、口令、改变远程目录命令、文件获取上传 的命令;
(2)数据连接(非持久):传输实际文件。 FTP 客户机发起向 FTP 服务器的控制连接,然后在该连接上发送用户标识和口令、改变远程目 录的命令。FTP服务器收到命令后,发起一个到客户机的数据连接,在该连接上准确地传送一个文件并关闭连接。
有状态的协议:FTP服务器在整个会话期间保留用户的状态信息。服务器必须把特定的用户账号和控制连接联系起来。
其他常见问题
在浏览器中输⼊url地址到显示主⻚的过程
- 对输入到浏览器的url进行DNS解析,将域名转换为IP地址。
- 和目的服务器建立TCP连接
- 向目的服务器发送HTTP请求
- 服务器处理请求并返回HTTP报文
- 浏览器解析并渲染页面
cookie 和 session
HTTP协议是无状态的,即服务器无法判断用户身份。Session和Cookie可以用来进行身份辨认。
Cookie
Cookie是保存在客户端一个小数据块,其中包含了用户信息。当客户端向服务端发起请求,服务端会像客户端浏览器发送一个Cookie,客户端会把Cookie存起来,当下次客户端再次请求服务端时,会携带上这个Cookie,服务端会通过这个Cookie来确定身份。
Session
Session是通过Cookie实现的,和Cookie不同的是,Session是存在服务端的。当客户端浏览器第一次访问服务器时,服务器会为浏览器创建一个sessionid,将sessionid放到Cookie中,存在客户端浏览器。
Token
客户端在浏览器第一次访问服务端时,服务端生成的一串字符串作为Token发给客户端浏览器,下次浏览器在访问服务端时携带token即可无需验证用户名和密码,省下来大量的资源开销。
存放位置 | 占用空间 | 安全性 | 应用场景 | |
---|---|---|---|---|
Cookie | 客户端浏览器 | 小 | 较低 | 一般存放配置信息 |
Session | 服务端 | 多 | 较高 | 存放较为重要的信息 |
传输层
TCP
TCP报文
TCP都有哪几种状态,分别都代表什么含义?
- SYN:同步位,SYN = 1 表示连接请求;
- FIN:终止位,FIN = 1 表示释放连接;
- ACK:确认位,ACK = 1 表示确认号有效;
- RST:复位位,RST = 1 表示TCP连接出现严重错误(主机崩溃等),需要重新建立连接;
- PSH:推送位,PSH = 1 表示接收端要尽快交付任务,不要等到缓存满了再提交;
- URG:紧急位,URG = 1 表示告诉系统该报文段为高优,需要加急传送。
连接管理
三次握手
握手 | 发送端 | 标志位 | 序号(seq) | 确认号(ack) | 状态 |
---|---|---|---|---|---|
1 | client | SYN=1 | x | - | CLOSE -> SYN_SENT |
2 | server | SYN=1 ACK=1 | x+1 | CLOSE -> SYN_RCVD | |
3 | client | ACK=1 | x+1 | y+1 | SYN_RCVD -> ESTABLISHED |
为什么是三次握手,不是两次?
- server给client发送的ack丢失了,client认为没有建立连接,但server认为已经建立连接,server发送数据会浪费网络资源;
- server接受到了一个失效的client发送的连接请求,会发送给client一个ack,但client不会发送数据,TCP连接也没有意义。
四次挥手
- 当客户端没有待发送的数据时,它会向服务端发送 FIN 消息,发送消息后会进入 FIN_WAIT_1 状态;
- 服务端接收到客户端的 FIN 消息后,会进入 CLOSE_WAIT 状态并向客户端发送 ACK 消息,客户端接收到 ACK 消息时会进入 FIN_WAIT_2 状态;
- 当服务端没有待发送的数据时,服务端会向客户端发送 FIN 消息;
- 客户端接收到 FIN 消息后,会进入 TIME_WAIT 状态并向服务端发送 ACK 消息,服务端收到后会进入 CLOSED 状态;
- 客户端等待两个最大数据段生命周期(Maximum segment lifetime,MSL)2的时间后也会进入 CLOSED 状态;
挥手 | 发送端 | 标志位 | 序号(seq) | 确认号(ack) | 状态 |
---|---|---|---|---|---|
1 | client | FIN=1 | u | ESTABLISHED -> FIN-WAIT-1 | |
2 | server | ACK=1 | v | u+1 | ESTABLISHED -> CLOSE-WAIT FIN-WAIT-1 - > FIN-WAIT-2 |
3 | server | FIN=1 ACK=1 | w | u+1 | CLOSE-WAIT -> LAST-ACK |
4 | client | ACK=1 | u+1 | w+1 | FIN-WAIT-2 -> TIME-WAIT |
为什么是四次挥手?
- c->s->c->s :TCP是全双工通信,第一次挥手是c不发数据了,第二次挥手是s对c不发数据的确认,第三次挥手是c收到s对c关闭连接的确认。但s还是可以单通道给c发数据的,并没有主动的释放连接。(而s对c的ack和s的FIN不能同时进行,因为如果s不主动FIN,c就会不停的给s发送FIN。)
- c->s, s->c, s->c:s需要一个c对其FIN的确认,否则会超时重传。
TIME_WAIT持续两个MSL的作用
- 首先,可靠安全地关闭TCP连接。比如网络拥塞,如果主动关闭方最后一个ACK没有被被动关闭 方接收到,这时被动关闭方会对FIN进行超时重传,在这时尚未关闭的TIME_WAIT就会把这些尾巴 问题处理掉,不至于对新连接及其他服务产生影响。
- 其次,防止由于没有持续TIME_WAIT时间导致的新的TCP连接建立起来,延迟的FIN重传包会干扰新的连接。
为什么要TIME-WAIT?
TIME_WAIT状态之所以存在,是为了保证网络的可靠性。由于TCP连接是双向的,所以在关闭连接的时候,两个方向各自都需要关闭。先发FIN包的一方执行的是主动关闭,后发送FIN包的一方 执行的是被动关闭。主动关闭的一方会进入TIME_WAIT状态,并且在此状态停留2MSL时长。如果 Server端一直没有向client端发送FIN消息(调用close() API),那么这个CLOSE_WAIT会一直存在下去。
TIME_WAIT占用的资源
少量内存(大概4K)和一个文件描述符fd。
有大量的TIME_WAIT状态怎么办?
tcp是面向连接的,大量的timewait会导致连接数达到tcp端口上限,从而导致新建tcp失败,connect异常。
解决办法:1、客户端:http请求头,connection设置为keep-alive,保持存活一段时间(不需要再多建立tcp连接);2、服务端:允许timewait的socket被重用,缩减timewait的时间。
MSL、TTL及RTT的区别
MSL(Maximum Segment Lifetime) :报文最大生存时间,超过这个时间,报文就将在网络中被丢弃。在TCP第四次挥手进入TIME_WAIT后,要等待2MSL的时间。
TTL(time to live):ip数据报可以经过的最大路由数,由源主机设置初始值时给定。每经过一个处理他的路由器此值就减1,当此值为0则数据报将被丢弃,同时发送ICMP报文通知源主机。
RTT(round-trip time):C/S往返所花时间。由TCP自适应算法计算动态给出,随着网络拥塞状态的变化而变化。
可靠传输
TCP是如何保证可靠传输的?
主要有校验和、序列号、超时重传、流量控制及拥塞避免等几种方法。
校验和
具体步骤:
发送方将校验和报文段置0,加上12位的伪首部(伪首部 + 首部 + 数据),将拼接后的报文视为若干个16位的数据,按二进制反码计算这些16位数据的和,然后将结果的反码写到校验和报文段里。接收方拿到报文段,加上伪首部,做同样的操作,如果得到的为全1,则说明无差错。
IP、UDP、TCP校验和计算方式相似,都是二进制反码运算求和再取反。区别在于IP只校验IP报文的首部,UDP和TCP校验首部和数据部分。
序列号
TCP会对每一个发送的字节进行编号,接收方接到数据后,会对发送方发送确认应答(ACK报文),并且这个ACK报文中带有相应的确认编号,告诉发送方,下一次发送的数据从编号多少开始发。如果发送方发送相同的数据,接收端也可以通过序列号判断出,直接将数据丢弃。
重传
超时重传 :RTT超过RTO要进行重传。
RTT(Round-Trip Time) :TCP发送报文和收到确认的时间差。
RTO(Retransmission Time-Out) :超时计时器设置的超时时间。
冗余确认 :利用序列号对缺失报文段进行计数,缩短超时周期,提高重传效率。
停止等待协议
每发完一个分组就停止发送,等待对方确认,在收到确认后再发下一个分组。
TCP默认使用累计确认,只确认第一个丢失包的序号位置。
确认号(ack):期望收到对方下一个报文段的数据的第一个字节的序号。
流量控制
流量控制是匹配发送方的发送速率与接收方的读取速率。
TCP提供的是一种基于滑动窗口的控制机制。
接收方根据自己接收缓存的大小,动态调整接收窗口的大小通知发送方(通过调整TCP首部的“窗口”字段);发送方根据当前网络拥塞程度确定拥塞窗口,取接受窗口和拥塞窗口的最小值作为发送窗口大小。
接收窗口 = 接收端缓存大小
发送窗口 = min{接收窗口, 拥塞窗口}
拥塞窗口:由发送方根据网络拥塞状态决定。
拥塞控制
拥塞控制的过程由四部分:慢开始、拥塞避免、快重传、快恢复。
慢开始:拥塞窗口初始值为1,然后指数增长,直到慢开始设定的门限。
拥塞避免:拥塞窗口达到慢开始门限后开始线性增长,直到网络阻塞,调整慢开始门限为网络拥塞时窗口的一半,重新从再慢开始。
快重传:当冗余确认超过预设值的时候,直接认为网络拥塞,相对拥塞避免,这是另一种认为网络拥塞的判决条件。
快恢复:快重传之后,将此时的发送窗口调整为拥塞窗口的一半,进行线性增长的发送数据。
流量控制和拥塞控制的区别:流量控制是点对点的,是发生在TCP连接的两个socket之间,而拥塞控制是发生在全局网络的,在主机和路由器之间。
UDP
是否面向连接 | 可靠性 | 传输形式 | 传输效率 | 消耗资源 | 应用场景 | 首部字节 | |
---|---|---|---|---|---|---|---|
TCP | 面向连接 | 可靠 | 字节流 | 慢 | 多 | 文件/邮件传输 | 20~60 |
UDP | 无连接 | 不可靠 | 数据报文段 | 快 | 少 | 视频/语音传输 | 8 |
如何利用UDP进行可靠传输
在弱网环境下,使用TCP连接的延迟很高,因此需要使用UDP保证数据传输能像TCP一样可靠。
传输层无法保证数据的可靠传输,只能通过应用层来实现。
可以从两个角度来实现:1)提供超时重传,避免数据丢失(保证不丢失);2)提供确认序列号,可以对数据进行确认(保证不重复)和排序(保证有序)。
本端:首先在UDP数据报定义一个首部,首部包含确认序列号和时间戳,时间戳是用来计算RTT(数据报传输的往返时间),计算出合适的RTO(重传的超时时间)。然后以等-停的方式发送数据报,即收到对端的确认之后才发送下一个的数据报。当时间超时,本端重传数据报,同时RTO扩大为原来的两倍,重新开始计时。
对端:接受到一个数据报之后取下该数据报首部的时间戳和确认序列号,并添加本端的确认数据报首部之后发送给对端。根据此序列号对已收到的数据报进行排序并丢弃重复的数据报。
网络层
IP报文
ARP协议
ARP协议的主要作用是实现在同一局域网内主机或路由器从IP地址到MAC地址的转换。是一个网络层的协议。
ARP的工作流程
- 在局域网内,主机A要向主机B发送IP数据报时,首先会在主机A的ARP缓存表中查找是否有IP地址及其对应的MAC地址,如果有,则将MAC地址写入到MAC帧的首部,并通过局域网将该MAC帧发送到MAC地址所在的主机B。
- 如果主机A的ARP缓存表中没有主机B的IP地址及所对应的MAC地址,主机A会在局域网内广播发送一个ARP请求分组。局域网内的所有主机都会收到这个ARP请求分组。
- 主机B在看到主机A发送的ARP请求分组中有自己的IP地址,会向主机A以单播的方式发送一个带有自己MAC地址的响应分组。
- 主机A收到主机B的ARP响应分组后,会在ARP缓存表中写入主机B的IP地址及其IP地址对应的MAC地址。
- 如果主机A和主机B不在同一个局域网内,必须通过路由器转发到主机B的局域网才可以通过主机B的MAC地址找到主机B。(主机A和主机B已经可以通信的情况下,主机A的ARP缓存表中存的并不是主机B的IP地址及主机B的MAC地址,而是主机B的IP地址及该通信链路上的下一跳路由器的MAC地址。这就是上图中的源IP地址和目的IP地址一直不变,而MAC地址却随着链路的不同而改变。)
ARP解析的时候可能会涉及到路由的选择和转发算法。
IP地址 & MAC地址
网络层实现的是主机之间的通信,而链路层实现的是链路之间的通信,所以从下图可以看出,在数据传输过程中,IP数据报的源地址(IP1)和目的地址(IP2)是一直不变的,而MAC地址(硬件地址)却一直随着链路的改变而改变。
ICMP协议
ICMP(Intent Control Message Protocol)互联网控制报文协议:用于TCP/IP网络中发送控制消息,提供IP包废弃的各种问题反馈。
ICMP 报文是封装在 IP 包里面,是 IP 协议的助手,是网络层协议。
ICMP有两种报文格式:查询报文、差错报文。
查询报文
发送端主动发起请求,并且获取到应答。
典型的应用就是PING。
PING
ping是ICMP(网际控制报文协议)中的一个重要应用,ping是应用层的协议(直接使用网络层的icmp,未走传输层)。ping的作用是测试两个主机的连通性。
ping的工作过程
- 向目的主机发送多个ICMP回送请求报文
- 根据目的主机返回的回送报文的时间和成功响应的次数估算出数据包往返时间及丢包率。
ping执行后都发生了什么?
- ping 命令执行的时候,源主机首先会构建一个 ICMP 回送请求消息数据包。
- ICMP 数据包内包含多个字段,最重要的是两个:第一个是类型,对于回送请求消息而言该字段为 8;另外一个是序号,主要用于区分连续 ping 的时候发出的多个数据包,每发出一个请求数据包,序号会自动加 1。
- ICMP报文段作为IP报文的一部分,加上源ip地址和目的ip地址,拼接成ip数据包;
- ip数据包通过ARP协议添加MAC头部,并转发到目的主机(中间可能涉及路由跳转);
- 目的主机按MAC地址、IP数据包逐层解析;
- 响应阶段,目的主机会构建一个 ICMP 回送响应消息数据包,回送响应数据包的类型字段为 0,序号为接收到的请求数据包中的序号,然后再发送出去给源主机。
差错报文
终点不可达
A、网络不可达 — 代码为 0,
B、主机不可达 — 代码为 1.
C、协议不可达 — 代码为 2.
D、端口不可达 — 代码为 3.
E、需要分段 - 代码为 4.( 必须把数据分段才能去到终点源站抑制
发送端发送大量数据时,可能会导致网络( 路由器 )过载,此时过载处可以向发送端发送源抑制的消息,让他降低发送速度。
时间超时
网络包超过设置的在网络中的生存时间,还没有达到。
参数问题
当目的主机或路由器收到的数据包的首部中有的字段的值不正确时,就丢弃该数据报,并向源点发送参数问题报文。
路由重定向
定义数据包的路由规则。因为大部分的时候,路由规则是通过相关协议算法生成的,有些时候重新定义过之后,会让这个数据包绕的更远。
DHCP协议
DHCP(Dynamic Host Configuration Protocol) 动态主机配置协议,用于给主机动态分配ip地址。
DHCP是应用层协议,基于UDP。
应用层协议有两种工作方式:C/S方式和P2P方式,其他网络层的协议都没有这两种方式。
DHCP为什么是基于UDP的,不能是基于TCP的吗?
由于DHCP客户机和服务器之间并没有彼此的ip,所以不能通过tcp协议进行socket连接。
DHCP客户机和服务器是如何交互报文的?
- 客户机广播索要ip的消息;
- 服务器收到消息后,发出一个提供ip的消息;
- 客户机收到消息后,如果接受消息中的参数,再向服务器请求ip;
- 服务器收到请求消息后为客户机提供ip。
DHCP客户机和服务器之间为什么是广播不是单播?
因为双方没有彼此的ip,必须通过广播传送参数和消息。
NAT协议
NAT(Network Address Translation)网络地址转换,是内网(局域网)和外网(广域网)ip转换的协议。它的作用在于:1、整个内网只需要一个全球IP就可以全球互连,而内网IP是可重用的,因此可以节省IP资源的消耗;2、内网只用于LAN,不用于WAN,可以隐藏内部网络结构,提高网络安全性。
NAT协议通过NAT路由器实现的,NAT要通过NAT转换表,实现源ip地址或目的ip地址的转换。NAT转换表存放着{本地IP地址 : 端口}到{全球IP地址 : 端口}的映射。
内网ip网段:
- A类:10.0.0.0~10.255.255.255
- B类:172.16.0.0~172.31.255.255
- C类:192.168.0.0~192.168.255.255
CIDR协议
https://www.cnblogs.com/yezhi/articles/2689817.html
路由协议
内部网关协议有rip,ospf等;外部网关协议有BGP等。
RIP
rip是一种分布式的基于距离向量的路由选择协议。属于应用层协议,基于UDP传输(端口号520)。
rip规定
- 每个路由器都要维护从它自身到目的网路的距离记录(距离向量);
- 经过一个路由,跳数就加1;
- rip认为路由数最少的路径就是最短路径;
- rip允许的最大路径长度时16,到了16就认为网络不可达(可见rip适合小型互联网);
- 两个路由器之间要定期广播一次rip路由更新信息,以便动态维护;
- 早起rip只支持相同子网掩码的路由,但最新的rip支持变长子网掩码和CIDR。
rip特点
- 仅和邻近路由交换信息
- 按固定时间间隔(30s)交换的信息是当前路由的全部信息,即自己的路由表
优点:简单、开销小、收敛过程快
缺点:限制了网络规模;网络规模大了之后,开销也大,因为每次交换彼此整个路由表;网络出现故障后,会出现慢收敛的情况。
慢收敛:需要较长时间才能将此信息传达所有路由器。
rip工作原理
算法:距离向量算法
算法要点:设 X 是结点 A 到 B 的最短路径上的一个结点。若把路径 A到B 拆成两段路径 A到X 和 X到B,则每段路径 A到X 和 X到B 也都分别是结点 A到X 和结点 X到B 的最短路径。
OSPF
OSPF的特点
- OSPF是网络层协议,直接用IP传数据;
- OSPF使用泛洪法向所有路由器发送消息(与本路由器相邻的所有路由器的路由状态);
- 只有当链路状态发生改变的时候才会发送消息;
- 不会出现慢收敛的情况。
- 可以实现负载均衡,当到同一目的网络的路径很多时,可以根据通信代价择优选择;
ospf工作原理
每个路由器简历一个链路状态数据库。然后使用Dijkstra最短露尽该算法计算从自己到目的网络的最优路径,构造自己的路由表。当状态链路发生改变的时候,再更新路由表。
BGP
BGP是应用层协议,基于TCP。
只需要找到一条可用的路由路径就返回。
工作原理:每个自治系统的管理员要选择至少一个路由器作为BGP发言人,然后各发言人之间建立tcp连接,交换路由信息,然后对于当前发言人,来选择一个较好的路由。