计算机网络基础

呵呵彡

已于 2022-03-11 17:17:18 修改

阅读量633

点赞数 1

分类专栏：网络文章标签：网络基础 https TCP/IP 网络模型网络发展历程

于 2021-12-19 14:00:55 首次发布

本文链接：https://blog.youkuaiyun.com/f4112cd/article/details/122022789

版权

网络专栏收录该内容

1 篇文章

订阅专栏

网络基础概述

计算机网络还是很有必要了解的，毕竟我们无时无刻不在使用。这里先简单介绍一下网络的发展历程吧，先对网络的构成有个大概的了解。虽然有点多并且不是非常重要不过可以简单看看

早期的网络就是通过一根网线然后将多个主机连接在一起实现通信的。不过这样就会出现一台主机和另外一台主机通信的时候，其他主机之间就不能进行通信，如果通信就会出现信号的冲突，因为两台主机通信时信道中就充满了信号，此时如果其他主机还要通信就会导致信号的冲突。为了解决这个问题就出现了CSMA/CD（载波监听，多路访问，冲突检测）的方案来解决这个问题。简单的说就是在发送消息的时候先看一下是否有主机在通信，有就等待，没有就进行发送，并且边发信号边监听如果发现有冲突就停止发送过一段时间在重新发送。但由于主机越来越多这个就不适用了。

对于上述问题我们的解决方案是把一个大的网络拆分为一个个小网络。在每个小网络中主机之间的冲突的几率就会变得很小。但是又出现了一个新的问题那就是小网络和小网络之间如何通信。为了解决小网络之间的通信问题就出现了网桥。通过网桥可以实现小网络和小网络之间的通信。也就是当一个小网络中的主机需要与另一个小网络中的主机进行通信时就可以通过网桥将信号发送到另一个小网络中从而被对应的主机接收。网桥其实就是在内存中维护了一个小网络中的主机标识（mac地址）和网桥接口的对应关系也就是一个mac表。如果发现一台主机请求是另外一个网络的主机，那么就通过网桥将请求发送到另外一个网络。当然网桥可以有多个接口从而实现多个网络之间的连通，并且网桥接口之间可以同时通信，因为他可以将网桥接口中的信号存储起来并进行调度转发，这种网桥其实就是交换机。并由于交换机的成本越来越低。所以现在的做法是，一个交换机接口只连接一台主机，相当于一个小网络中只有一台主机，这样小网络中就不会产生冲突了。同时也实现了主机之间的同时通信，每台主机还可以实现同时收发信号，因为交换机是支持多个接口之间同时通信以及一个接口同时收发信号的。

通过交换机解决了网络中通信的冲突以及主机之间的同时通信，但又出现了一个问题，那就是交换机中的mac表如何生成。如果我们手动维护那就太不灵活了。所以通常使用的是动态生成。动态生成的方法是：交换机刚刚搭建的时候mac表中是没有数据的，当一台主机向交换机中发送信号，交换机会先检查mac表，如果mac表中没有当前主机的mac（称为源mac）那么就在mac表中新增对应的记录（交换机接口和主机mac的对应关系）。然后再根据信号的目标地址到mac表中进行查找。如果没有找到对应的记录，那么就会将当前信号对交换机的所有接口进行广播。非目标主机接收到信号会直接丢弃，目标主机接收信号会进行处理并通过交换机进行响应，在响应的时候mac表中就可以添加目标主机对应的mac记录了，慢慢的mac表中的记录就完善了。

不过如果交换机中连接的主机很多很多，那么刚开始时mac表还是没有完全生成那么就会出现大量的广播，从而影响主机之间的通信。这被称为广播风暴。这时就需要将广播域进行分割，从而减少广播。分割广播域就需要用到路由器。不同的广播域之间通信通过路由器进行连接。其实可以看成每个交换机就是一个广播域或子网。交换机之间通过路由器进行连接。路由器跟交换机类似他也存储了一张表，只不过表中的数据为ip地址和广播域（子网）的对应关系。

每台主机都有一个唯一表示称为mac地址（他有48bits，前24位由地址分配机构提供，后24位由生产厂商随意变化不重复即可）。所以不同主机之间通信查找目标主机的时候是可以通过mac地址在相同广播域或不同广播域之间进行查找的。不过由于mac地址在网卡生产时就确定了，不可变动且没有规律，所以对于查找是很不方便的，如果查找的基数太大那么查找的速度就会变得很慢。为了解决这个问题就引入了ip地址。通过ip地址可以标识网络号（子网）以及网络号中的主机。可以理解为ip地址可以标识广播域（子网）以及广播域中的主机，通过ip地址可以实现基于层级的方式进行查找。

所以有了ip地址后当一个广播域A中的主机a需要访问另一个广播域B中的主机b时，他首先会通过自己ip与目标的ip进行对比（通过自己ip以及目标ip与子网掩码计算然后进行对比）看是否在同一个网络中（子网中），如果在同一网络中，那么就在当前广播域中进行广播，注意这里是通过ip进行广播。目标主机接收到信息后就会响应他的mac地址（通过ip广播获取mac地址称为ARP地址解析），之后他们在通过mac地址进行交互，因为拿到mac地址才能实现硬件的交互，ip只是逻辑层的概念。如果发现自己的ip与目标的ip不在同一个网络中，则将请求发送给默认网关也就是当前子网的路由器。由于路由器中记录了ip和网络（子网）的对应关系，所以他可以通过ip将请求发送到对应的网络(子网)中。然后再目标网络中在通过ip进行广播，从而获取到目标主机的mac地址，最后根据mac地址将请求发给对应的主机

全世界网络（子网）有很多，所以只有一个路由是远远不够的。因此就需要很多的路由。并且路由之间按照层级划分，例如每个国家级别、省级、每个城市有城域网、然后每个公司。当我们将请求发给路由的时候他会先判断目标ip是否在当前路由管理的网络下，如果不在就将请求转发给其他路由，整个路由结构类似于树结构，他会先向上级转发然后再转发到下级，例如深圳主机要访问上海主机，需要从公司的路由转发到深圳市路由然后再转发到华南然后再到中国，之后在转发到华北、上海、公司最后到达公司子网络，之后进行广播获取目标主机的mac最后基于mac地址将信息发送给对应的主机。所以全球的网络就是通过很多个路由以及子网络组成的。当然路由转发的路径有很多条具体抉择由路由器决定

通过ip的机制可以实现不同网络中不同主机之间的通信。但是还有一个问题就是ip仅仅只是可以找到对应的主机，但是通信其实是主机中的进程之间的通信。因此这个时候就需要用到端口号通过端口号就可以标识主机中的每一个进程了。因此通过主机+端口就实现了一个套接字（套接字就是ip+端口）的通信

网络模型

网络模型用于对不同子网的不同主机之间如何通信进行规范，并制定了很多协议。所以了解网络基础可以直接从网络模型入手。网络模型有两种：

OSI七层参考模型
TCP/IP五层模型或四层模型

当然我们实际使用的为TCP/IP模型，通常习惯将TCP/IP模型分为5层，这里也主要根据5层模型进行说明：
物理层
- 物理层简单说就是通过硬件将两台计算机连起来，使他们之间可以发送0，1电信号
数据链路层
- 制定了0，1电信号的传送规则，通过以太网协议将一组电信号构成一个数据包称之为帧。每一个桢由标头(Head)和数据(Data)两部分组成。然后再通过mac地址来识别计算机。这样就能够让计算机可以正确的识别并发送信号了。所以通过物理层和数据链路层就是实现本地通信了，例如我们可以直接通过交换机来实现计算机的本地通信
网络层
- 实际上世界上的网络由无数个子网以及路由构成，当不同子网的主机需要通信需要借助于路由进行层层转发。网络层用于定义不同子网主机之间的通信规则。虽然mac地址可以标识唯一主机但mac地址在网卡生产是就确定了无法变更并且没有什么规律，所以如果通过mac地址在整个网络中查找效率是很差的。为了解决这个问题于是就出现了IP协议
- IP协议有两种版本，一种是 IPv4,另一种是 IPv6。不过我们目前大多数用的还是 IPv4，一个 IP 地址由 32 位的二进制数组成，我们一般把它分成4段的十进制表示，地址范围为0.0.0.0~255.255.255.255。要联网的主机都会有一个IP地址。这个IP地址被分为两部分，前面一部分代表网络部分用于标识子网，后面一部分代表主机部分用于标识子网中的主机。并且网络部分和主机部分所占用的二进制位数是不固定的。所以需要通过子网掩码对ip地址进行与运算从而得到网络部分，子网掩码和IP地址一样也是 32 位二进制数，不过它的网络部分全部为 1，主机部分全部为 0。
- 根据IP的网络部分就可以通过路由找到对应的网络了。不过ip只是逻辑概念，要实现主机间的通信最终还是得转换为硬件的交互。所以通过ip找到对应的子网后还得找到对应子网中主机的mac地址。因为拿到mac地址才能实现硬件的交互。而通过ip获取mac地址需要通过ARP协议。所谓ARP协议其实就是他会在子网中以广播的形式向子网中的所有主机发送一个数据包，当然这个数据包会包含接收方的IP地址，子网中的主机接收到数据包后就会取出数据包中的ip地址跟自己的ip进行对比，如果不一样就丢弃，如果一样就将自己的mac地址响应给对方。这样拿到mac地址后在基于mac地址进行本地通信
- CDN加速的原理其实就是减少路由的转发次数，从而能够更快的找到对应的子网进行请求。CDN服务器中会缓存主服务器的资源，当然通常是静态资源。用户请求的时候直接请求距离用户最近的CDN服务器就可以了
- DNS服务器，这个其实就是用于进行域名解析的，因为ip不容易记住，所以我们通常使用域名进行访问，不过最终需要转为基于ip的访问所以需要dns服务器将域名解析为ip
传输层
- 通过物理层、数据链路层以及网络层已经可以实现不同子网主机之间的通信了。不过主机中会运行很多的程序，要确定将信息发给主机中的哪个程序还需要借助于端口实现。也就是说，传输层的功能就是建立端口到端口的通信。而网络层的功能是建立主机到主机的通信。传输层最常见的两大协议是 TCP 协议和 UDP 协议，其中 TCP 协议与 UDP 最大的不同就是 TCP 提供可靠的传输，而 UDP 提供的是不可靠传输。
- UDP
  - UDP数据包结构
  - UPD的包中数据很简单只有源端口、目标端口和数据等等。所以他处理速度快，无论是否丢包，它该怎么发就怎么发，不会管接收方的情况，不需要一对一建立连接。他只会监听着，谁都可以传给它数据，它也可以传给任何人数据，甚至可以同时传给多个人数据。所以他适合于一些对丢包不敏感，要求处理速度快的情况，例如游戏和直播等等
- TCP
  - TCP数据包结构
  - TCP包中包含了很多的数据项例如：目标和源端口、序号，确认序号、状态位等等。他发送数据前都要先建立一对一的连接，并且建立连接需要经过三次握手。建立连接之后在进行数据的发送，并且每次发送后接收方都要返回应答。最后断开连接的时候还要经过四次挥手。所以他可以避免丢包以及保证数据的完整性，所以他的传输是可靠的。
  - 三次握手
    - 首先TCP的包中有个状态位，状态位中包含了很多状态用于表示不同情况例如经常看到的有：
      - SYN：为1时表示发起一个新连接
      - ACK：为表示一个响应，为1表示正常响应
      - FIN：为1时表示释放一个连接
    - TCP的三次握手的流程是：
    - 第一次握手：建立连接时，客户端发送一个状态为SYN=1的包到服务器，并进入SYN_SENT状态，等待服务器确认；并且包中还会携带一个随机产生一个序号
    - 第二次握手：服务端的监听收到数据包后，由数据包中的状态位SYN=1知道客户端在请求建立连接。因此服务端会响应一个数据包，其中数据包的状态位SYN和ACK都等于1，并携带一个随机产生的序号以及将确认序号改为客户端发过来的序号+1。然后服务器进入SYN_RECV状态
    - 第三次握手：客户端收到服务端的数据包后，会检查ACK状态位是否为1，以及确认序号是否为之前发过去的序号+1，如果正确，则再次先服务端发送一个数据包，并将状态位ACK置为1，确认序号改为服务端发过来的序号+1，服务端收到数据包后会检查状态位ACK是否为1以及确认序号是否为之前发过去的序号+1，如果正确则连接建立成功，客户端和服务端将进入ESTABLISHED状态，完成三次握手，随后客户端和服务端之间就可以开始传输数据了。
  - 四次挥手
    - 由于TCP是全双工通信，所以关闭连接可以由客户端或服务端任一方执行close来触发。首先进行关闭的一方将执行主动关闭，而另一方则执行被动关闭。假设客户端向服务端发起关闭，四次挥手的流程是
    - 第一次挥手：客户端先服务器发送一个数据包，其中数据包中状态位FIN等于1，序号为上一次传输数据服务器响应的确认序号。之后客户端进入FIN_WAIT_1状态
    - 第二次挥手：服务端收到状态位FIN等于1的数据包后，会响应一个数据包，其中状态位ACK=1，确认序号为客户端发过来的序号+1，序号为上一次传输数据客户端响应的确认序号。然后服务端进入CLOSE_WAIT状态，这个时候客户端到服务端的连接已经结束了。但是TCP是全双工通信，所以在服务端这边可能还存在着数据没有完全发送给客户端，服务端到客户端的连接还没有结束。此时服务端依旧可以向客户端发送数据同时客户端也依旧可以接收数据。当客户端收到服务器的确认请求后，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送释放连接的数据包
    - 第三次挥手：服务端将需要发送的数据发送完成后就会向客户端发送一个数据包，其中状态位FIN和ACK等于1。确认序号为之前客户端发过来的序号+1，序号为上一次传输数据客户端响应的确认序号，之后服务端进入LAST-ACK状态，等待客户端的确认
    - 第四次挥手：客户端收到状态位FIN等于1的数据包后，会响应一个数据包，其中状态位ACK=1，确认序号为客户端发过来的序号+1，序号为上一次传输数据服务端响应的确认序号，之后客户端进入TIME-WAIT状态，过一段时间后自动进入CLOSED状态，而服务端接收到响应后就进入CLOSED状态，完成四次挥手，并断开TCP连接
  - 常见面试题：
    - 为什么连接的时候是三次握手，关闭的时候却是四次握手
      - 因为当服务端收到客户端的SYN连接请求报文后，可以直接发送SYN+ACK报文，其中ACK报文用来应答，SYN报文用来同步协商序号。而关闭连接时，当收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而且此时己方可能还有数据没有完全发送给对方。所以需要等己方将数据完全发给对方后在发送一个FIN报文给对方来表示同意关闭连接。因此，己方ACK和FIN需要分开发送，所以握手可以三次当挥手需要四次
    - 为什么不能用两次握手进行连接
      - 因为必须要三次握手才能确认同步双方的初始序号以及确认双方都做好了发送数据的准备工作。
      - 如果是两次握手，客户端可以知道发给服务端的初始序号是否被收到，因为服务端会响应确认序号。但服务端无法确认他发给客户端的初始序号是否被收到。因为只有两次握手客户端并不会响应。如果此时服务端发给客户端的同步信号丢失了，服务端的初始序列号双方将无法达成一致
      - 还有两次握手无法确认双方都是正常都做好了发送数据的准备工作。例如有这么一种情况，如果客户端发送的连接报文没有丢失，而是在某个网络结点长时间的滞留了，以致于延误到连接释放以后的某个时间才到达服务端。如果只有两次握手，服务端收到连接请求就会响应同意建立连接并等着客户端发来数据。但由于此时客户端并没有发出建立连接的请求，因此不会理睬服务端的确认，也不会向服务端发送数据。这样服务端的很多资源就白白浪费掉了
    - 为什么断开连接的时候TIME_WAIT状态需要经过一段时间后才能到达CLOSED状态
      - 这是为了保证最后一个确认包能被对方接收。因为可能有这么一种情况，如果最后一个ACK响应报文丢失了，对方没有接收到，那么对方就会不断重复发送FIN报文。所以发送最后一个ACK报文后不能直接进入CLOSED状态而是要等待一段时间，如果这段时间对方又发送了FIN报文那么就需要再次发送一个ACK报文然后重新进入等待。如果等待时间结束并且没有再次收到FIN报文，那么就可以推断ACK报文已经被成功接收了，然后再结束TCP连接。
应用层
- 有了传输层虽然可以将数据传递到程序中了，不过传递过来的数据是各种各样的，所以我们还需要定义数据的格式及规则，这样在程序中才可以对请求进行具体的解析及处理。所以应用层主要用于制定程序之间如何实现具体的交互。应用层的协议有很多不同类型的程序会使用不同的协议，例如常用协议有：http协议、ftp协议、telnet协议等等
- http协议
  - http全称为超文本传输协议，他是一种无状态协议，也就是他不会保存请求和响应的状态每次请求都是独立的。HTTP 可以分为两个部分，即请求和响应。
    - HTTP 请求
      - HTTP请求由 3 个部分构成，分别是：状态行，请求头和请求体
      - 状态行：由请求方式，路径、协议等构成，各元素之间以空格分隔，例如：GET /test/?sex=man&name=names HTTP/1.1。其中路径URL，对应着一个服务器上的资源，而请求方式定义了在与服务器交互的不同方式，请求方式有多种，例如常用的有GET、POST、PUT、DELETE，分别对应着查增改删的操作。
      - 请求头：请求头用于存放请求时的额外的信息比如：Content-Type（请求体的数据格式）、Accept（可以接收的数据格式）、Host（请求的服务器地址）等等，当然也可以存放用户自定义的请求头信息
      - 请求体：用于存放当前请求需要传递的数据，通常POST请求的数据会放在请求体中，而GET的会直接拼接在url路径中
    - HTTP响应
      - HTTP 响应是服务器在客户端发送 HTTP 请求后经过一些处理而做出的响应，他也是由三个部分构成。分别是：状态行，响应头，响应体。
      - 状态行：由协议、状态码、描述构成，例如HTTP/1.1 200 OK。其中状态码用于表示服务端响应的状态，例如常用的有：200 请求成功、404 请求资源不存在、500服务器发生错误、401 请求未授权等等
        状态码的分类
        1**：信息，服务器收到请求，需要请求者继续执行操作
        2**：成功，操作被成功接收并处理
        3**：重定向，需要进一步的操作以完成请求
        4**：客户端错误，请求包含语法错误或无法完成请求
        5**：服务器错误，服务器在处理请求的过程中发生了错误
      - 响应头：跟请求头类似用于存放响应时的额外信息，例如Content-Type（响应体的数据格式）、Server（服务器软件名称）等等
      - 响应体：具体响应的数据，可以是html也可以是json
  - 会话追踪
    - 因为http协议是无状态的协议，每次请求都是独立的。而通常我们的应用需要在用户登录后记住用户，当登录后的用户进行请求时我们的应用必须能够识别当前请求。为了解决这个问题我们需要进行会话追踪，会话追踪的实现最常用的有两种一种是基于cookie+session的方式，而另一种是基于token令牌的方式
    - 使用cookie和session的方式：首先cookie存储在客户端而session存储在服务端。当服务端第一次创建session的时候，服务端就在HTTP协议中告诉客户端需要在cookie中记录一个session id。当客户端再次请求时服务端就可以从cookie中获取到session id从而找到对应的session，所以session是需要依赖于cookie的。
    - 使用token的方式：当客户端认证通过后服务端就会签发一个token给客户端。客户端可以将token存储在cookie或localStorage中，当客户端请求时就可以将token从cookie或localStorage中取出来然后放在请求头中，服务端接收到请求之后在从请求头中获取token然后验证token的合法性并且还可以从token中获取用户数据。而token的实现有很多种，例如常用的jwt
  - HTTPS
    - 因为http的请求信息为明文传输，未校验数据的完整性以及不会验证对方的身份，所以http请求并不是安全的，容易被容易被窃听截取以及被篡改。为了解决http不安全的问题所以就出现了https
    - https可以理解为http+ssl，ssl协议位于 TCP/IP 协议与各种应用层协议之间，为数据通讯提供安全支持。所以可以通过ssl为http通信进行加密以及身份验证，从而让http变为安全通信
    - https的原理为：
      - 首先因为http是明文的所以我们需要做的肯定是对http中传递的信息进行加密。而https加密采用的是对称加密和非对称加密结合的方式。其中对称加密就是加密和解密使用同一秘钥，加解密的速度都很快。而非对称加密有两个秘钥分别是公钥和私钥，使用公钥加密的数据只有用私钥才能解密，反过来使用私钥加密的数据也只有用公钥才能解密，不过非对称加密要慢很多。
      - 其实https中使用非对称加密是为了解决对称加密存在的问题。因为如果单独使用对称加密有一个很大的问题，那就是客户端和服务端要如何协商并获取相同的秘钥。如果要拿到相同的秘钥那么就必须要将秘钥进行明文传输，这样秘钥就可能会被截取，哪加密就没有意义了。为了解决这个问题就需要使用非对称加密对对称加密的秘钥进行加密然后进行传输。
      - 所以结合非对称加密我们可以这样操作：首先由于非对称加密的公钥是可以公开的，所以服务端可以将对应的公钥传给客户端，而服务端这边保存私钥。之后客户端创建一个对称加密的密钥并用公钥对这个秘钥进行加密，然后将加密后的秘钥传给服务端。由于服务端有私钥所以可以对加密后的秘钥进行解析。这样客户端和服务端就可以拿到了相同的秘钥了，之后双方在通过对称加密的秘钥对数据进行加密然后进行传输。当然这里你可能会想我直接用非对称加密对数据进行加密然后进行传输，不用对称加密不行吗。答案肯定不行因为非对称加解密的效率太低了，而且双方传递的数据可能很大那样效率会更低。所以为了提高效率需要使用速度更快的对称加密，而非对称加密只用于加密对称加密的秘钥，并且秘钥不会很大所以解析起来也很快
      - 上面看似已经完善了，但还有一个问题没有解决，那就是公钥在传递的时候可能会被拦截并篡改。也就是A发给B公钥，如果传输过程中被C拦截了，那么C可以将A传给B的公钥改为C自己的公钥。这样B加密的秘钥C就能够解密，然后C在将解密后的数据通过之前获取到的A的公钥进行加密在传给A。这样A和B之间传递的加密数据C就能够解析，因为C也有对应的秘钥。所以直接传递公钥是不可取的依旧有很大的问题，那么公钥要怎么传递给对方呢？这好像又陷入了死胡同
      - 为了解决这个问题所以出现了CA机构，CA机构专门用于给各个网站签发数字证书也就是SSL证书，从而保证浏览器可以安全地获得各个网站的公钥。有了CA机构后我们可以这样操作，首先网站的管理员也就是服务端需要将自己的公钥交给CA机构，然后CA机构会使用我们提交的公钥以及一些其他的信息例如网站域名、有效时长等来制作证书。然后CA机构在通过他们自己的私钥对证书进行加密之后在将加密后的证书给我们。我们在将获得的加密证书配置到网站服务器上。每当有浏览器请求我们的网站时，首先会将加密证书返回给浏览器，此时浏览器会用CA机构的公钥来对这段证书进行解密。解密后浏览器也就是客户端就能够拿到我们服务端的公钥了，拿到公钥就可以使用上面说的流程进行加密通信了。
      - 当然这里你可能会问浏览器怎么能拿到CA机构的公钥呢？其实这个问题很好解决，因为世界上的网站是无限多的，而CA机构总共就那么几家。任何正版操作系统都会将所有主流CA机构的公钥内置到操作系统当中，所以我们不用额外获取，解密时只需遍历系统中所有内置的CA机构的公钥，只要有任何一个公钥能够正常解密出数据，就说明它是合法的。
      - 那么，上述的工作机制已经非常完善了吗？其实并没有，因为还有一个问题，那就是攻击者也可以申请CA证书，如果他在服务器向客户端发送CA证书的时候进行拦截，然后将加密的CA证书进行替换。那么客户端拿到的就是攻击者的CA证书并且他的也是CA证书也是合法的。这样客户端发送的加密秘钥攻击者同样可以获取并解析。为了解决这个问题所以证书中需要包含一些其他信息，例如网站的域名，加上网站域名后客户端解析证书后只需要对比一下证书中的域名和实际访问的域名是否一致就可以了。这样https就可以实现加密通信了