计算机网络基础| 青训营笔记

94 阅读19分钟

计算机网络模型

OSI七层模型

  • 物理层: 实现计算机节点之间比特流的传输,规定传输媒体接口的标准,屏蔽掉具体传输介质和物理设备的差异,使数据链路层不必关心网络的具体传输介质,按照物理层规定的标准传输数据就行。【比特流

    IEEE802.2、IEEE802

  • 数据链路层: 在两个主机上建立数据链路连接,向物理层传输数据信号,并对信号进行处理使之无差错并合理的传输。【

    PPP

  • 网络层: 主要负责路由、转发,选择合适的路径,确保数据即是否到达。【

    IP、ICMP、ARP

  • 传输层: 传输层的主要作用是负责向两台主机进程之间的通信提供数据传输服务。【

    TCP、UDP

  • 会话层: 是用户应用程序和网络之间的接口,负责在网络中的两节点之间建立、维持、终止通信。

    SQL

  • 表示层: 处理用户数据的表示问题,如数据的编码、格式转换、加密和解密、压缩和解压缩。

    ASCII、GIF、JPEG

  • 应用层: 为用户的应用进程提供网络通信服务,完成和实现用户请求的各种服务。

    HTTP、FTP

五层模型

  • 物理层、数据链路层、网络层、传输层、应用层。

TCP/IP四层模型

  • 网络接口层、网络层、传输层、应用层。

网络层

IP地址: IPv4(32bit)、IPv6(128bit,内置安全性)【网络部分 + 主机部分】,逻辑地址,基于网络的拓扑结构来分配,属于网络层。

MAC地址: MAC地址基于设备的制造商来分配,长度为48bit(十六进制),属于数据链路层。

子网掩码: 用来区分网络号与机器号。【子网的网段和遮掩的部分IP(二进制的与运算)】

网关: 一个网络通向另一个网络的IP地址。网关既可以用于广域网互连,也可以用于局域网互连。 【网关在传输层上以实现网络互连】

ARP

ARP地址解析协议: 【IP --> MAC】

  • IP地址: IP地址是指互联网协议地址,IP地址是IP协议提供的一种统一的地址格式,它为互联网上的每一个网络和每一台主机分配一个逻辑地址,以此来屏蔽物理地址的差异。
  • MAC地址: MAC地址又称物理地址,由网络设备制造商生产时写在硬件内部,不可更改,并且每个以太网设备的MAC地址都是唯一的。
  • 每个主机都在自己的ARP缓冲区中建立一个ARP列表,以表示 IP 地址和 MAC 地址之间的对应关系。
  • 当源主机要发送数据时,先检查ARP列表中是否有该 IP 地址对应的 MAC 地址,如果有,则直接发送数据;如果没有,就向本网段的所有主机发送ARP数据包,用于查询目的主机的MAC地址,该数据包包括的内容有:源主机IP地址,源主机MAC地址,目的主机的IP。
  • 当本网络的所有主机收到该ARP数据包时,首先检查数据包中的IP地址是否是自己的IP地址,如果不是,则忽略该数据包,如果是,则首先从数据包中取出源主机的IP和MAC地址写入到ARP列表中,如果已经存在,则覆盖,然后将自己的MAC地址写入ARP响应包中,告诉源主机自己是它想要找的MAC地址。
  • 源主机收到 ARP 响应包后,将目的主机的 IP 和 MAC 地址写入ARP列表,并利用此信息发送数据。如果源主机一直没有收到ARP响应数据包,表示ARP查询失败

由于A和B不在同一个局域网,所以A只能通过网关将包转发给B了。

  • A要发送数据包给B,由于不在同一个局域网,所以A得将数据包先发到网关,A和网关是在同一局域网,所以A会先查看自己的 ARP 表是否有网关的 MAC 地址?如果没有网关的 MAC 地址,那就通过广播的方式发送一个 ARP 请求,网关对比 IP ,发现 A 找自己,便缓存 A 的 MAC 地址 和 IP 地址到自己的 ARP 表,并将自己的 MAC 地址放进 ARP 回应报文,A 收到来自网关的 ARP 回应报文之后,便把网关的 IP 和 MAC 缓存进自己的 ARP 表中。
  • 当 A 确定了网关的 MAC 地址之后,便将数据包封装成帧(源IP为A的IP,源MAC地址为A的MAC地址,目的IP为B的IP,目的MAC地址为网关的MAC地址),发给网关。
  • 网关接收到数据包后,便查看自己的 ARP表,如果没有 B的 IP 所对应的 MAC地址,则广播 ARP请求报文 ,得到 B 的MAC 地址后,将数据包封装成帧发送给 B ;如果该网关(路由器)和B不在一个局域网,那么网关将数据包封装成帧【源IP为A的IP,源MAC地址为A的MAC地址,目的IP为B的IP,目的MAC地址为下一跳网关的MAC地址】后发给下一个网关,直到数据包传输到 B。

ICMP协议

ICMP因特网控制报文协议: 用于在IP主机、路由器之间传递控制消息(控制消息是指网络通不通、主机是否可达、路由器是否可用等网络本身的消息),确认 IP 包是否成功到达目标地址。 因为 IP 协议并不是一个可靠的协议,它不保证数据被送达,当传送IP数据包发生错误,比如主机不可达、路由不可达等等,ICMP协议将会把错误信息封包,然后传送回给主机,给主机一个处理错误的机会。

Ping的过程:

  • 向目的主机发送多个ICMP回送请求报文 ;
  • 根据目的主机返回的回送报文的时间和成功响应的次数估算出数据包往返时间及丢包率。

交换机与路由器的区别

  • 工作所处的OSI层次不一样: 交换机工作在OSI第二层数据链路层,路由器工作在OSI第三层网络层;
  • 寻址方式不同: 交换机根据MAC地址寻址,路由器根据IP地址寻址;
  • 转发速不同: 交换机的转发速度快,路由器转发速度相对较慢。

列举并简述路由协议

  1. 内部网关协议IGP:

    • RIP(Routing Information Protocol): 是一种动态路由选择协议,基于距离矢量算法,使用“跳数”来衡量到达目标地址的路由距离,并且只与自己相邻的路由器交换信息,范围限制在15跳之内。
    • OSPF: 开放最短路径优先协议,使用Dijskra算法计算出到达每一网络的最短路径,并在检测到 链路的情况发生变化时(如链路失效),就执行该算法快速收敛到新的无环路拓扑。
  2. 外部网关协议:

    • BGP: 边界网关协议,BGP 是力求寻找一条能够到达目的网络 且 较好的路由,而并非要寻找一条最佳路由。BGP采用路径向量路由选择协议。

传输层

TCP与UDP的区别

TCP三次握手与四次挥手

  • 第一次握手: 客户端向服务端发送一个 SYN 报文(SYN = 1),并指明客户端初始化序列号 ISN,即seq = x,表示本报文所发送的第一个字节的序号。此时客户端处于 SYN_SENT状态,等待服务端确认。
  • 第二次握手: 服务端收到数据包后,由 SYN = 1 知道客户端请求建立连接,那么就会对这个TCP 连接分配缓存和变量(缓存指的是一个字节流队列),接着返回一个确认报文:设置 SYN = 1,ACK = 1,同时指定自己的初始化序列号 ISN,即图中的 seq = y,并把客户端的 序列号x + 1 作为确认号 ack 的值,表示已经收到了客户端发来的的 SYN 报文,希望收到的下一个数据的第一个字节的序号是 x + 1,此时服务端进入SYN_REVD状态
  • 第三次握手: 客户端收到确认后,检查ACK是否为1,ack是否为 x +1,如果正确,则给服务端发送一个 ACK 报文:设置 ACK = 1,把服务端的序列号y + 1 作为 ack 的值,表示已经收到了服务端发来的 SYN 报文,希望收到的下一个数据的第一个字节的序号是 y + 1,并指明此时客户端的序列号 seq = x + 1,此时客户端和服务器端都进入 ESTABLISHED 状态。完成三次握手,随后Client与Server之间可以开始传输数据了。
  • 第一次挥手: 客户端发送一个 FIN 报文,设置 FIN = 1 并指定序列号 seq = u(u 是之前传送过来的最后一个字节的序号 + 1),主动关闭 TCP 连接,此时客户端进入FIN_WAIT_1状态
  • 第二次挥手: 服务端收到 FIN 报文后,由FIN=1 知道客户端请求关闭连接,则返回确认报文:设置ACK = 1,ack = u + 1,seq = v(v 的值取决于服务器发送给客户端之前的一个包确认号是多少)服务端进入CLOSE_WAIT状态,此时TCP连接处于半关闭状态,即客户端不能向服务端发送报文,只能接收,但服务端仍然可以向客户端发送数据。客户端收到服务端的确认后,进入 FIN_WAIT2 状态,等待服务端发出的连接释放报文段。
  • 第三次挥手: 当服务端没有要向客户端发送的数据时,就向客户端发送一个 FIN 报文,设置 FIN = 1 并指定序列号 seq = w(w 的值取决于服务器发送给客户端之前的一个包确认号是多少),用于关闭服务端到客户端的数据传送。此时服务器处于 LAST_ACK 状态
  • 第四次挥手: 客户端收到 FIN 报文后,发送给服务端一个 ACK 报文作为应答:设置 ACK=1 和 ack = w +1。发送之后,客户端处于 TIME_WAIT状态,如果服务端接收到这个数据包,则进入CLOSED状态,完成四次挥手。
  1. TCP为什么是三次握手?二次和四次行不行?

    • 三次握手主要防止已失效的连接请求报文段突然又传送到了服务端,导致服务器错误地建立连接,浪费服务端的连接资源。

    客户端发出的第一个连接请求报文段并没有丢失,而是在某个网络结点长时间的滞留了,以致延误到连接释放以后的某个时间才到达Server。本来这是一个早已失效的报文段,但Server收到此失效的连接请求报文段后:

    ① 假设不采用“三次握手”,那么只要Sever发出确认,新的连接就建立了。但由于现在Client并没有发出建立连接的请求,因此不会理睬Server的确认,也不会向Server发送数据。而Server却以为新的连接已经建立,并一直等待Client发来数据,这样,Server的很多资源就白白浪费掉了。

    ② 而采用“三次握手”

    协议,只要Server收不到来自Client的确认,就知道Client并没有要求建立请求,就不会建立连接了。

    • 三次握手就可以确定双方的接收和发送能力,无需再需要第四次握手,浪费资源。
  2. TCP释放连接为什么需要TIME_WAIT状态?

    • 保证客户端发送的最后一个ACK报文能够到达服务器,因为这个ACK报文可能丢失,站在服务器的角度看来,我已经发送了FIN+ACK报文请求断开了,客户端还没有给我回应,应该是我发送的请求断开报文它没有收到,于是服务器又会重新发送一次,而客户端就能在这个2MSL(报文最大生成时间) 时间段内收到这个重传的报文,接着给出回应报文,并且会重启2MSL计时器。
    • 防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后,在这个2MSL时间中,就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。
    • 如果出现大量的TIME_WAIT,可以通过调整参数减少time_wait的时间。
  3. TCP中CLOSE_WAIT的作用?

    CLOSE_WAIT表示被动关闭连接 ,是被动关闭连接是形成的。

    一般的情况下, CLOSE_WAIT 状态应该会停留的时间非常短,如果我们发现了某台服务器上出现了大量的 CLOSE_WAIT 状态的连接, 并且持续的时间比较长,那么一定是一种非正常的状态(上层应用程序异常)。

  4. TCP为什么需要4次挥手?

    建立连接的时候,不需要发送数据,可以把ACK和SYN放在一个报文里发送给客户端 。TCP全双工的,而关闭连接时,服务器收到对方的FIN报文时,仅仅表示对方不再发送数据了但是还能接收数据,而自己也未必全部数据都发送给对方了,所以己方可以立即关闭,也可以发送一些数据给对方后,再发送FIN报文给对方来表示同意现在关闭连接,因此, 己方ACK和FIN一般都会分开发送,从而导致多了一次。

  5. 如果已经建立了连接,但是客户端突然出现故障了怎么办?

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

  6. SYN泛洪?

    • TCP规定,SYN、FIN报文段不能携带数据,但需要消耗掉一个序号;ACK报文段可以携带数据,但是如果不携带数据则不消耗序号。

    • SYN 洪泛是指利用 TCP 需要三次握手的特性,攻击者伪造 SYN 报文向服务器发起连接,服务器在收到报文后用 ACK 应答,但之后攻击者不再对该响应进行应答,造成一个半连接。假设攻击者发送大量这样的报文,那么被攻击主机就会造成大量的半连接,耗尽其资源,导致正常的 SYN 请求因为队列满而被丢弃,使得正常用户无法访问。

    • 解决方法:

      1. 限制半连接流量和缩短SYN Timeout时间。
      2. 设置SYN Cookie。 与传统TCP连接不同,服务器再接收到TCP SYN包并返回TCP SYN + ACK包时,并不需要对接下来可能收到的数据包进行资源的预留而是根据这个SYN包计算出一个cookie值。这个cookie作为将要返回的SYN ACK包的初始序列号。当客户端返回一个ACK包时,根据包头信息计算cookie,与返回的确认序列号进行对比,如果相同,则是一个正常连接,然后,分配资源,建立连接。
  7. TCP为什么粘包?如何处理?

    TCP是个“流”协议,所谓流,就是没有界限的一串数据。TCP底层并不了解上层业务数据的具体含义,它会根据TCP缓冲区的实际情况进行包的划分,所以在业务上认为,一个完整的包可能会被TCP拆分成多个包进行发送,也有可能把多个小的包封装成一个大的数据包发送,这就是所谓的TCP粘包和拆包问题。

    由于UDP有消息保护边界,不会发生粘包拆包问题

    解决策略:

    • 在数据尾部增加一个特殊字符进行分割,例如 FTP 协议;
    • 将数据大小设置为固定的,如果数据长度不够,则使用空位补全;
    • 将数据分为两部分,消息头和消息体;其中消息头大小固定,且包含一个字段声明内容体的大小。
  8. TCP为什么拆包?

    1. 要发送的数据大于TCP发送缓冲区剩余空间大小,将会发生拆包。

    2. 待发送数据大于MSS(最大报文长度),TCP在传输前将进行拆包。

    • 稳定性: 一次发送的数据越多,出错的概率就越大;
    • 效率: 网络中有时存着并行的路径,拆分数据包能好的利用这些并行的路径;
    • 缓冲区: 缓冲区是在内存中开辟的一块区域,目的是缓冲。如果每个应用都随意发送很大的数据,可能导致其他应用实时性遭到破坏。

TCP如何保证可靠传输

  • 应答机制与超时重传: TCP接收端收到发送端的数据时,它将发送一个确认。当TCP发送端发出一个报文段后,它会启动一个定时器,等待接收端的确认报文段,如果不能及时收到一个确认,将重发这个报文段。
  • 数据包校验与丢弃重复数据: TCP会检测数据在传输过程中的任何变化,若校验出包有错,则丢弃报文段并且不给出响应,这时TCP会超时重发数据;对于重复数据,则进行丢弃;
  • 对失序数据包进行重排序: 既然TCP报文段作为IP数据报来传输,而IP数据报的到达可能会失序,因此TCP报文段的到达也可能会失序。TCP将对失序数据进行重新排序,然后才交给应用层;
  • 流量控制: TCP 连接的每一方都有固定大小的缓冲空间。TCP 的接收端只允许另一端发送接收端缓冲区所能接纳的数据,防止较快主机致使较慢主机的缓冲区溢出。TCP使用的流量控制协议是可变大小的滑动窗口协议。
  • 拥塞控制: 网络拥塞时,减少数据的发送。拥塞控制就是为了防止过多的数据注入到网络中,这样就可以使网络中的路由器或链路不至于过载。拥塞控制是一个全局性的过程,涉及到所有的主机、所有的路由器以及与降低网络传输性能有关的所有因素。

TCP流量控制:

所谓流量控制就是让发送方的发送速率不要太快,让接收方来得及接收。因为如果发送方把数据发送得过快,接收方可能会来不及接收,这就会造成数据的丢失。TCP的流量控制是通过大小可变的滑动窗口来实现的。接收端将自己可以接收的缓冲区大小放入TCP首部中的“窗口大小”字段,通过ACK报文来通知发送端,滑动窗口是接收端用来控制发送端发送数据的大小,从而达到流量控制。

TCP拥塞控制:

  • 慢开始: 【指数增长】

    发送数据时,不要一开始就发送大量的数据,因为不清楚网络的拥塞情况,而是试探一下网络的拥塞情况,由小到大逐渐增大发送窗口。在开始发送报文段时先设置拥塞窗口cwnd=1,使得发送方在开始时只发送一个报文段,然后每经过一个传输轮次RTT,拥塞窗口 cwnd 就加倍。另外,为了防止拥塞窗口cwnd增长过大引起网络拥塞,还需要设置一个慢开始门限 ssthresh 状态变量。

    当 cwnd < ssthresh 时,使用上述的慢开始算法。

    当 cwnd = ssthresh 时,既可使用慢开始算法,也可使用拥塞控制避免算法。

    当 cwnd > ssthresh 时,停止使用慢开始算法而改用拥塞避免算法。

  • 拥塞避免: 【加法增大】

    让拥塞窗口cwnd缓慢地增大,即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1。这样拥塞窗口cwnd按线性规律缓慢增长,比慢开始算法的拥塞窗口增长速率缓慢得多。

  • 快重传:

    快重传要求接收方在收到一个失序的报文段后就立即发出重复确认(使发送方及早知道有报文段没有到达对方)而不必等到自己发送数据时捎带确认。发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段,而不必继续等待设置的重传计时器时间到期。

  • 快恢复:

    与快重传配合使用的还有快恢复算法,当发送方连续收到三个重复确认时,就执行 “乘法减少” 算法,把ssthresh门限设置为拥塞窗口cwnd的一半,但是接下去并不执行慢开始算法,而是将cwnd设置为ssthresh的大小,然后执行拥塞避免算法:因为如果网络出现拥塞的话,就不会收到好几个重复的确认,所以发送方现在认为网络可能没有出现拥塞,所以此时并不执行慢开始算法,而是执行拥塞避免算法。

UDP怎么保证可靠的设计

传输层无法保证数据的可靠传输,只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式,只是实现不在传输层,实现转移到了应用层。

最简单的方式是在应用层模仿传输层TCP的可靠性传输。下面不考虑拥塞处理,可靠UDP的简单设计。

  • 添加seq/ack机制,确保数据发送到对端
  • 添加发送和接收缓冲区,主要是用户超时重传。
  • 添加超时重传机制。