深入理解网络通信基本原理和tcp/ip协议

时间：2024-03-03 21:51:43

深入理解网络通信基本原理和tcp/ip协议

  • 一、计算机网络体系
    • 1，计算机网络体系结构
    • 2，网络中数据传输
      • 2.1，浏览器中输入一个url的执行流程
      • 2.2，数据在网络中是的传输流程
    • 3，三次握手和四次挥手
      • 3.1，三次握手
        • 3.1.1，洪范攻击
        • 3.1.2，为什么需要三次握手
      • 3.2，四次挥手
        • 3.2.1，为什么需要time-wait
        • 3.2.2，time-wait举例
    • 4，UDP协议

一、计算机网络体系

1，计算机网络体系结构

在最初的网络中，是借鉴于这个OSI七层网络模型，而在实际开发应用中，更多的还是使用这个TCP/IP模型，分别是 物理层、数据链路层、网络层、传输层、应用层 ，相较于OSI模型，TCP/IP模型是将会话层和表示层都结合到了应用层里面

TCP的缩写是 Transmission Controller Protocol ，看到第一个单词传输，因此得知这个TCP是在这个传输层的；IP的缩写是 Internet Protocol ，该协议是位于网络层的，中文将这两个名字称为是 传输控制协议/英特网互联协议 。如下图，应用层中有HTTP，Telnet、DNS等协议；传输层中包含TCP、UDP协议；网络层中包含 IP、ICMP等协议；链路层中包含PDN、PPP等协议

在这里插入图片描述

在应用中，还是TCP、UDP和IP这三者使用的范围最广。

  • ip用于确定是哪台主机，有点类似于电话号码，确定能打到那个人身上

  • TCP是一个可靠连接的一个协议，需要通过三次握手建立连接，有点类似于两台电话，必须接通才能通话。绝大多数场景下还是通过tcp协议完成的，因为该协议相对稳定可靠，需要等建立连接之后才能传输数据，并且在传输数据时可以通过一定的限流方式进行流量控制，从而保证数据传输的可靠性。

  • UDP是一个面向无连接的协议，类似于商家和快递，商家不关心用户能不能接收到，不需要和用户建立直接关系。如在实际开发中，视频语言等都是通过UDP实现的，允许部分数据丢失。如虎牙斗鱼这些，有对应的清晰度，通过不同的清晰度，决定每次传输数据的大小，清晰度越小，即使丢包也是允许的

2，网络中数据传输

2.1，浏览器中输入一个url的执行流程

url：被称为统一资源定位符，一个完整的url，都会包含这四部分，分别是协议、域名、路径和资源。当在浏览器中输入一个url时，如在浏览器中输入www.baidu.com，其内部会执行的流程如下：

  • 首先是域名解析，就是将网址解析成具体的ip。如果不是第一次访问这个网址，那么正常会在host文件中保存对应的ip，那么就可以直接通过本地的host文件解析；如果是第一次访问这个网址，那么本地host文件中不存在，就需要去本地的DNS服务器查找，没有再去root根DNS服务器中获取
  • 再获取到这个具体的ip之后，通过三次握手的方式，与对方建立TCP的可靠连接
  • 建立连接成功之后，再向服务器发送一个http的请求
  • 服务器接收到请求之后，服务器会处理相关请求
  • 随后服务器会将响应结果返回给客户端
  • 随后通过四次挥手断开连接
  • 浏览器接收到响应之后，对响应的内容进行解析
  • 浏览器将解析的内容渲染，如css，js等，最后进行布局展示

2.2，数据在网络中是的传输流程

在网络通信中，客户端A需要向客户端B发送数据，也是需要通过tcp/ip 五层协议的，如下图，如主机A向主机B中发送一条数据

主机A发送数据的流程

  • 首先数据会先经过应用层，然后携带一个应用层的头部，此时为数据包
  • 随后继续经过传输层，由于是TCP协议，因此继续携带一个TCP的头部，此时为数据段
  • 随后继续经过ip层，因此继续携带一个IP层的头部，此时为数据报
  • 随后到达链路层，最后将数据封装成以太网数据帧，随后通过以太网电缆传输到目标ip

主机B接收数据的流程

  • 在通过电缆接收到数据之后，会先经过数据链路层层层解析，从下往上依次解析，先经过链路层，随后网络层，随后传输层，再到应用层，全部解析完成之后，再返回给客户端

在这里插入图片描述

3，三次握手和四次挥手

3.1，三次握手

在tcp建立连接时，需要通过三次握手来实现连接，从而实现这种稳定可靠性，其流程如下

  • 首先客户端会向服务端发送一个SYN=1的一个报文标志，并且设置一个seq_no的字段值为10000，此时客户端进入一个 SYN_SENT 的状态
  • 服务端在接收到这个请求之后，会对客户端进行一个响应，也会发送一个SYN=1的报文，并且设置一个ACK=1的标志位，同时会返回一个ack_no回应客户端的seq_no，值为客户端seq_no的值+1，最后还会设置一个seq_no的值，其值为30000。此时服务端进入一个SYN_REVD的状态
  • 客户端在接收到服务端的响应之后，客户端需要给服务端一个响应，告诉服务端客户端接收到这个响应了。会继续返回一个SYN=1的报文，并且只需要返回一个ack_no，其值为服务端seq_no的值+1，最后服务端和客户端的状态都变为 ESTABLEISHED 连接建立的状态

在这里插入图片描述

三次握手主要的原因是为了建立可靠连接，在连接过程中，客户端的seq序列号需要服务端的ack序列号应答，服务端的seq序列号也需要客户端的ack序列号应答保证可靠性，如出现丢包重传的的话，那么可以直接根据具体的seq序列号进行重传即可。主要是通过超时重传机制 和 应答确认机制 来保证可靠传。

最后一次握手是为了告知服务端，客户端确实收到了服务端的响应，对于响应syn_no的seq_no的值，至于要加多少，取决于接收了多个包，即取决于SYN的值的大小，如果接收了3个包，且seq_no的值为10000，那么响应的ack_no的值则为10003

3.1.1，洪范攻击

SYN洪范攻击的定义如下：就是通过网络所在的端口发送大量伪造原地址的攻击报文发送到服务端，造成服务端上面的半开连接队列被占满，从而阻止其他用户进行访问。

在三次握手中，也存在一定的缺陷，有可能会出现这个SYN洪范攻击 ，就是利用伪造的ip地址向服务端发出第一次握手，而tcp连接为了维护三次握手，就会响应这个伪造ip的请求，然而服务端这边一直在等客户端的响应，即第三次握手，如果伪造服务端一直不响应，随着伪造ip请求的增多，那么服务端的资源会被耗尽。该方式属于一种ddos的攻击，可以通过加防火墙等避免，设置定时任务去移除无法响应的请求。

在三次握手中，会存在大量的客户端去连接服务端，服务端会将不能及时响应的客户端的请求，先存放在一个队列中。那么洪范攻击就会利用这个特性，从客户端发送一个伪造的数据报文到服务端，服务器会为了保证三次握手，就会对这个伪造数据的服务器做出响应，由于攻击者的ip是伪造的，那么服务器这边的响应就一直到达不了伪造者客户端的ip，并且接收不到客户端的第三次响应，导致该次连接一直不被释放。那么伪造多个ip去请求服务端的话，那么会造成大量的连接处于不被释放状态，从而让这个队列占满，导致整个服务器处于瘫痪的状态。

解决这个洪泛攻击的方案如下：

  • 无效连接监控释放：就是给一个监听事件，对队列中要响应的请求进行监听，如果在一定的时间内还没有成功的建立三次握手，那么就可以直接将该次请求释放清理掉
  • 延缓TCP分配方法： 就是在分配tcp的时候，在三次握手建立成功之后，再来分配tcp
  • 开启防火墙： 通过防火墙来确认这个客户端ip地址的有效性，只有这个ip地址是有效的才与客户端建立连接
3.1.2，为什么需要三次握手

上面讲解了三次握手的过程以及三次握手的缺陷，然而在tcp协议中，为什么建立连接需要三次握手呢，其主要原因如下：在建立连接过程中双方都会发送一个序列号，这样就可以知道发送报文的起始的序列号和最终的序列号，从而通过序列号的值知道有哪些报文，通过差值确认报文的个数，当服务端接收的报文的个数小于差值时，就通过序列号确定哪个报文被丢失，就会进行重传的操作，从而来保证该协议的可靠性

如在服务端给客户端发送建立连接时，seq_no的值设置成10000，SYN的值设置成3，但是服务端这边返回ack_no的值为10002，此时差值为2表示只收到两个数据包，但是SYN的值为3表示发送了3个数据包，故而得知少了一个服务端少接收了一个数据包，那么服务端这边就会进行重发的操作。服务端响应客户端也会发一个seq_no的序列号给客户端，然后客户端回应服务端一个ack_no，其本质也是一样，通过差值和SYN的值进行比较，查看是否出现丢包的情况。

3.2，四次挥手

当tcp连接断开时，其底层也是通过四次挥手的方式来断开连接。与建立连接的三次握手不一样，三次握手是固定的从客户端发起握手的请求，但是四次挥手不一样，挥手是客户端和服务端都可以发起断开连接的请求。四次挥手的流程如下(以客户端发起断开请求为例)

  • 首先客户端发起断开连接的请求，此时会向服务端发送一个FIN的标志，并且会设置序列号seq_no，假设此时FIN的值为，seq_no的值为8888，此时客户端处于FIN_WAIT_1的状态
  • 服务端接收到请求之后，服务端会先响应一个接收到该请求的响应，会往服务端发送一个ACK确认的标志，同时返回一个ack_no的值，改值为接收到的序列号+FIN传过来的包的数量，如此时为8889，此时服务端处于close_wait的状态
  • 一段时间之后，服务端会向客户端再次发送一次报文，也会设置一个FIN的值和一个seq_no的值，如设置一个FIN=1，seq_no = 8890，此时服务器端会处于LAST_WAIT的状态，
  • 客户端在收到服务端发送的第二次报文之后，会再向服务端发送一个报文，设置ACK=1的确认标志，并且设置一个ack_no=8891的值，此时客户端处于TIME_WAITING的状态，最后服务端接收到响应报文之后，服务端会处于一个CLOSED的状态

在这里插入图片描述

3.2.1，为什么需要time-wait

在上图中可知，在客户端第二次向服务端发送报文的时候，会有一个TIME-WAIT的时间设置，规定需要等待2MSL，一般的操作系统都是设置成2分钟，当然会有部分的操作系统设置的值不一样，如在linux操作系统设置的值为1分钟，那么接下来需要了解，为什么这段第四次挥手需要等待两分钟

  • 首先还是为了保证系统的可靠性，如服务端第二次给客户端报文时设置的seq是2000，FIN=4，此时是有4个包，但是客户端接收到的seq的值为2002，正常是2004，少了两个包，此时就需要服务端重传
  • 第二个原因是如果不设置那么长时间，往服务端发送完数据之后直接closed，那么就会出现一个问题，如果此时服务端发现客户端seq的值少了两个，需要服务端这边重传，然后客户端这边已经关闭连接，如果此时是还是刚刚关闭的客户端发起的一个新的程序，并且此时的客户端的操作系统又给这个新的应用程序分配的就是上一个端口号，那么此时新的应用程序就会拿到一个上一个服务端第三次挥手重传的数据，此时新的应用程序就会处于一个懵圈状态，此时就会出现一个报文混乱的状态。为了保证tcp传输的可靠性，因此需要在这里做一个时间等待

确认一个连接就是源ip，源端口号，目标ip，目标端口号，上面第二点的第三次握手的报文还是发送在同一个ip的同一个端口号，因此还是同一个连接，那么新的应用程序就会接收到上一个关闭程序的报文

3.2.2，time-wait举例

上面讲了为什么需要time-wait，这里举一个在实际开发中，可能出现time-wait的案例。

以mysql为例，假设在实际开发中，用完mysql之后没有主动的去closed，如果客户端长时间的没有向服务端发送数据报文，发么mysql服务端可能就会认为该客户端已经下线，那么服务端就发起断开连接的操作，此时由服务端发起第一次挥手，服务端第四次挥手响应客户端之后，会有一个TIME_WAIT的等待时间，假设该操作系统的time-wait是2分钟，那么需要再2分钟之后，服务端才会closed，才能真正的去释放一个连接

如果每次用完mysql都不主动的去closed，那么每次都会由服务端去发起断开连接的请求，就会产生大量的time-wait，服务器会随着客户端的不断增加，在某一个时间点会出现资源耗尽的情况，如果是一台繁忙的服务器，那么就很有可能因为这个time-wait出现宕机的情况。

在这里插入图片描述

因此在实际开发中，如果是手动的通过JDBC驱动实现mysql的连接，那么一定要记得手动的close，让客户端去发起断开连接的请求，让time-wait这个时间结点出现在客户端这边，减少服务端这边的资源损耗。

4，UDP协议

udp和tcp都是处于传输层，但是udp和tcp底层实现不一样，udp属于不可靠连接，面向的是无连接的协议，就是说客户端发送数据之后，不需要去关心服务端是否收到数据，udp的特性如下

  • 因为udp在一端发送数据之后不需要关心另一端是否收到数据，因此udp会出现丢包的情况

  • 也因为不需要对端接收数据的确认，因此udp的速度快于tcp

  • udp双端属于点对点连接，因此可以通过udp实现udp单播

  • udp也可以不设置另一端的端口号，那么可以通过udp实现广播，可以让多个端口号接收到数据

  • 由于允许丢包这种，那么视频音频这些都可以通过udp的方式实现通信

相关文章