• TCP/IP模型五层协议


    TCP/IP模型五层协议

    认识协议

    约定双方进行的一种约定

    协议分层

    • 降低了学习和维护的成本(封装)
    • 灵活的针对这里的某一层协议进行替换

    四/五层协议

    • 五层协议的作用
      在这里插入图片描述

    应用层

    应用层常见协议

    • 应用层常见协议概览
      在这里插入图片描述

    • 基于TCP的协议

      • HTTP(超文本传输协议)
      • SMTP(简单邮件发送协议)
      • POP3/IMAP(邮件接收协议)
      • FTP(文件传输协议)
      • Telnet(远程登录协议)
      • SSH(安全的网络传输协议)
    • 基于UDP的协议

      • RTP(实时传输协议)

      • DNS(域名管理系统

        • 用于解决域名和IP地址的映射问题
          在这里插入图片描述

        • 为什么域名解析用UDP协议

          • 因为UDP快。UDP的DNS协议只需要一个请求,一个应答就好了
          • 但是UDP协议传输内容不能超过512字节。不过客户端向DNS服务器查询域名,一般返回的内容都不超过512字节,用UDP传输即可
        • DNS的工作原理

          • 查询方式

            • 递归查询:主机向本地域名服务器的查询一般都是采用递归查询

              • 主机向本地域名发送查询请求报文,而本地域名服务器不知道该域名对应的IP地址时,本地域名会继续向根域名发送查询请求报文,不是通知主机自己向根域名发送查询请求报文。
            • 迭代查询:本地域名服务器向根域名服务器的查询

              • 本地域名服务器向根域名发出查询请求报文后,根域名不会继续向顶级域名服务器发送查询请求报文,而是通知本地域名服务器向顶级域名发送查询请求报文。
              • DNS的缓存位于本地DNS服务器,由于全球的根服务器很少(400+台,13组),且顶级域的数量也在一个可数的范围内,因此本地DNS通常已经缓存了很多TLD DNS服务器,所以在实际查找过程中,无需访问根服务器
          • 工作流程

            • 浏览器输入域名,操作系统会先检查本地的hosts文件是否有这个域名的映射关系,如果有,就先调用这个IP地址映射,完成域名解析
            • 如果hosts文件没有,就去查询本地DNS解析器缓存,如果有缓存记录且缓存记录未过期,就完成地址解析
            • 如果本地DNS解析器缓存中没有,就去查找本地DNS服务器,如果查到,完成解析
            • 如果没有,本地服务器会向根域名服务器发起查询请求,根域名服务器会告诉本地域名服务器去查询哪个顶级域名服务器
            • 本地域名服务器向顶级域名服务器发起查询请求,顶级域名服务器会告诉本地域名服务器去查找哪个权限域名服务器
            • 本地域名服务器向权限域名服务器发起查询请求,权限域名服务器告诉本地域名服务器 该域名所对应的IP地址
            • 本地域名服务器告诉主机 该域名所对应的IP地址

    自定义应用层协议

    • 原因:业务错综复杂,很难有一个通用的协议来满足所有业务需求

    • 怎么自定义

      • 结合需求,分析清楚响应要传递哪些信息

      • 明确传递的信息以什么样的格式来组织

        • 典型的组织数据的格式

          • 按照文本方式组织

            • json
            • XML
            • 优点:可读性高
            • 缺点:效率低,占用较多的网络带宽
          • 二进制的表示数据的方式

            • protobuffer

    传输层

    UDP协议

    • UDP的特点

      • 无连接
      • 不可靠传输
      • 面向数据报
      • 全双工
    • UDP报文

      • UDP报头
        在这里插入图片描述

        • 源端口

          • 端口号使用2个字节,16bit,取值范围是0->65535
        • 目的端口

        • UDP长度

          • 最大只能传输64kb的数据
        • UDP校验和

          • 验证传输的数据是否正确

          • 常见算法

            • CRC

              • 简单粗暴,把数据的每个字节循环网上累加,如果溢出,则舍弃高位
              • 优点是好算,缺点是校验效果不是特别理想
            • MD5

              • 特点

                • 定长
                • 冲突概率小
                • 不可逆
              • 基于这些特点,更多的用处

                • 校验和
                • 作为计算hash值的方式
                • 加密
            • SHA1

        • 8个字节,总共有4个部分,每个部分两个字节

      • UDP载荷(payload)

        • 放的完整的应用层数据报

    TCP协议

    • TCP的特点

      • 有连接

      • 可靠传输

        • TCP最核心的部分

        • 保证整体TCP的可靠性

          • 确认应答:传输顺利的情况
          • 超时重传:传输出现问题的情况
          • 三次握手一定程度上也保证了TCP的可靠传输,但是不是起关键作用,是起辅助作用
      • 面向字节流

      • 全双工

    • TCP报文

      • TCP报头
        在这里插入图片描述

        • 源端口号(16位)

        • 目的端口号(16位)

        • 序列号(32位)

          • 解决网络包乱序问题
        • 确认应答号(32位)

          • 解决丢包问题
        • 首部长度(4位)

          • 首部长度的单位是4字节
        • 保留(6位)

          • 保证了TCP报文的可扩展性
        • 控制位

          • URG

          • ACK

            • 应答报文
          • PSH

          • RST

            • 用于重置TCP连接,复位报文段
          • SYN

            • 同步报文段,用于发送连接请求
          • FIN

            • 用于发送断开连接请求
        • 窗口大小(12位)

        • 选项(长度可变)

        • 数据

      • TCP载荷

    • TCP内部的工作机制

      • 确认应答

        • 实现可靠传输最核心的机制

        • 应答报文

          • ACK=1 说明是 应答报文
          • 通过应答报文,可以让发送方清楚的知道是否发送成功
        • 解决网络先发后至问题

          • 序号:任何一条数据都有的
          • 确认序号:只有应答报文才有,收到数据的最后一个字节+1
      • 超时重传

        • 丢包

          • 发送的数据丢了
          • 返回的ACK丢了
        • 超时重传

          • 丢包是概率性事件,重新发送一下数据报,还是有很大概率能成功传输的
          • 超过一定时间,还没有响应的话,就重新传输
        • 如果出现传输的数据重复的情况怎么办?

          • 去重:TCP存在“接受缓存区”,根据序列排序,如果序列重复,则把后面的数据直接丢弃掉
        • 小结:去重和重新排序机制

      • 连接管理

        • 建立连接:三次握手
          在这里插入图片描述

          • 三次握手的意义

            • 1、让通信双方各自建立对对方的“认同”(记录对方的信息)

            • 2、验证通信双方的发送能力和接受能力是否正常

              • 第一次握手:客户端发送网络包,服务端收到了。 这样服务端就能得出结论:客户端的发送能力、服务端的接收能力是正常的
              • 第二次握手:服务端发包,客户端收到了。 这样客户端就能得出结论:服务端的接收、发送能力,客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。
              • 第三次握手:客户端发包,服务端收到了。 这样服务端就能得出结论:客户端的接收、发送能力正常,服务器自己的发送、接收能力也正常。
            • 3、在握手的过程中,双方协商一些重要的参数(主要是前两个)

              • TCP通信过程中,有些数据通信双方要互相同步,此时就需要有这样的交互过程,恰好三次握手可以完成数据的同步
          • 为什么不是四次握手?中间两次交互不合并可以吗?

            • 数据的发送和接受是要封装和分用的,封装分用两次一定比封装分用一次的成本更高,没必要多交互一次
          • 为什么不是两次握手?

            • 三次握手的意义不仅仅要通信双方建立对对方的认同,还要验证双方的发送能力和接受能力是否正常,如果少一次握手,无法确认双方能力都正常
            • 如客户端发出连接请求,但因连接请求报文丢失而未收到确认,于是客户端再重传一次连接请求。后来收到了确认,建立了连接。数据传输完毕后,就释放了连接,客户端共发出了两个连接请求报文段,其中第一个丢失,第二个到达了服务端,但是第一个丢失的报文段只是在某些网络结点长时间滞留了,延误到连接释放以后的某个时间才到达服务端,此时服务端误认为客户端又发出一次新的连接请求,于是就向客户端发出确认报文段,同意建立连接,不采用三次握手,只要服务端发出确认,就建立新的连接了,此时客户端忽略服务端发来的确认,也不发送数据,则服务端一致等待客户端发送数据,浪费资源
        • 断开连接:四次挥手
          在这里插入图片描述

          • 为什么要四次挥手?

            • TCP是全双工通信,可以双向传输数据。任何一方都可以在数据传送结束后发出连接释放的通知,待对方确认后进入半关闭状态。当另一方也没有数据再传送的时候,则发出连接释放通知,对方确认后就可以完全关闭了TCP链接
          • 中间的两次交互为什么不能像三次挥手那样合并在一起呢?

            • 三次握手的交互是在纯内核中完成的(应用程序干预不了),服务器收到SYN后,就会立即发送ACK,同时立即发送SYN
            • 而服务器FIN的发起,是由应用程序控制调用socket的close方法(或者进程退出),而ACK是由内核控制的,收到客户端发送的FIN立即返回ACK
            • 这两者中间就会有一个时间差(是长是短取决于代码),因此不能合并
          • 如果第二次挥手时服务器的ACK没有到达客户端,会怎样?

            • 客户端没有收到ACK确认,会重新发送FIN请求
          • 为什么这里的TIME_WAIT要保持当前的TCP连接状态,不能立即释放呢?

            • 最后一个ACK发出,还没有到达,可能会存在丢包情况

            • 而四次挥手也存在超时重传,站在服务器的角度,无论是ACK丢包还是自己发出的FIN丢包,都视为是FIN丢包,会进行FIN重传。如果立即释放,那将无法对重传的FIN进行ACK响应

              • TIEM_WAIT等待一段时间后没收到重传的FIN的话,就会视为最后一个ACK没丢,此时就会彻底释放连接
              • 极端情况下,最后一个ACK丢了,重传的FIN也丢了,此时服务器等待很久也没有收到重传的FIN,最终会释放连接,这种情况无法解决
          • TIME_WAIT具体保持多少时间释放连接呢?

            • 约定一个时间,叫做2MSL
              在这里插入图片描述

              • MSL:互联网两个节点之间,数据传输消耗的最大时间
      • 发送量控制

        • 滑动窗口

          • 为什么引入

            • 引入可靠性,其实付出了代价:传输效率降低了。所以TCP在保证可靠性的前提下,尽可能地提高传输效率
          • 本质就是降低了确认应答,等待ACK消耗的时间
            在这里插入图片描述

            • 不等待地批量发送一组数据,然后使用一份时间来等待一组数据的多个ACK
            • 不需要等待就能直接发送的数据的最大量,就叫做“窗口大小”
          • 批量发送了一批数据之后,就开始等待ACK,那什么时候继续往下发送呢?等待什么时候结束呢?

            • 并不是要等所有ACK到了才能发送下一组数据,而是到了一个ACK,就继续往下发送一条
          • 如果出现丢包怎么办

            • ACK丢了
              在这里插入图片描述

              • 不需要作任何处理,此时要理解确认序号的含义:该序号往前的所有数据都确认到达了。比如2001这个ACK其实包含了1001这个ACK的信息
            • 数据丢了
              在这里插入图片描述

              • 快速重传:只重传丢失了的数据

                • 如果当前传输数据密集,按照滑动窗口的方式传输,此时按照快速重传处理丢包
                • 如果当前传输数据稀疏,不按照滑动窗口的方式传输,此时按照超时重传处理丢包
              • 在这里插入图片描述

        • 流量控制

          • 一种干预发送的窗口大小的机制

            • 滑动窗口越大,传输效率越高。但是滑动窗口不能无限大

              • 不等ACK,能否保证可靠性
              • 窗口太大,会消耗大量资源
              • 发送速度太快,接收方处理不过来,发了也白发
          • 如何衡量接收方的处理能力

            • 看接收方 接收缓冲区的剩余大小

              • 每次主机A向主机B发送数据,B就计算一下剩余空间,然后将这个值通过ACK返回给A。A就根据这个值决定接下来的发送速率(窗口大小)

                • 窗口探测报文不携带任何具体的业务数据,只是为了触发ACK查询窗口大小
                  在这里插入图片描述

                • 窗口大小是随着传输过程,动态变化的

                • 窗口大小只有在报文是ACK时才会生效。并且窗口大小不只是64kb,在选项中有个扩展因子可以让窗口更大
                  在这里插入图片描述

        • 拥塞控制

          • 流量控制和拥塞控制共同决定发送方的窗口是多大(取决于二者较小的一个)

            • 流量控制考虑的是接收方的处理能力
            • 拥塞控制描述的是传输过程中,中间节点的处理能力
          • 本质上,是通过实验的方式来逐渐找到一个合适的窗口大小(合适的发送速率)

            • 在这里插入图片描述

            • 拥塞窗口不是固定数值,而是一直动态变化的,随着时间推移,逐渐达到一个动态平衡的状态。这样既能解决问题,同时也能随着网络的动态变化而动态变化

      • 延时应答

        • 也是提升效率的机制
        • 收到数据后,不是立即返回ACK,而是等会再返回。等待时间里,接收方的应用程序就能把接收缓冲区的数据消费一波,此时剩余空间就更大了
        • 比如这里就是两条返回一个ACK
          在这里插入图片描述
      • 捎带应答

        • 也是提高传输效率的机制(在延时应答的基础上,引入了捎带应答)
        • 本来是不同时机,在延时应答下,可能成为相同时机,就合并发送了
        • 在这里插入图片描述
      • 面向字节流

        • 可能出现“粘包现象”

          • 由于TCP是面向字节流,所以一次可能读不完一个数据报或者读多个
        • 在应用层约定好应用层协议即可,尤其是明确应用层数据报和应用层数据报之间的边界就好了

          • 约定好分隔符
          • 约定每个报的长度
      • 异常情况

        • 进程崩溃

          • 进程没了,对应的PCB就没了,对应的文件描述符表也释放了,相当于socket.close(),此时内核会继续完成四次挥手,仍然是正常断开的流程
        • 主机关机

          • 主机要杀死进程,然后才正式关机,和进程崩溃一样会触发四次握手
        • 主机掉电/网线断开

          • 接收方掉电

            • 等不到ACK会进行超时重传,重传几次还是收不到会尝试重置TCP连接(复位报文段RST),失败后单方面放弃连接
          • 发送方掉电

            • 有保活机制:通过心跳包来确认双方是否处在正常的通信状态

              • 周期性地给发送方发送一条消息,确认下双方是否还在正常工作

    TCP和UDP的对比

    • 是否面向连接

      • TCP提供面向连接的服务,在传送数据前必须先建立连接,数据传输后要释放连接
      • UDP在发送数据之前不需要先建立连接
    • 是否可靠传输

      • TCP提供可靠的传输服务,TCP在传递数据之前,会有三次握手来建立连接,而且在数据传递时,有确认、窗口、重传、拥塞控制机制。通过TCP传递的数据,无差错、不丢失、不重复、并且按顺序到达
      • 主机收到UDP报文后,不需要给出任何确认,并且不保证数据不丢失/按顺序到达
    • 是否有状态

      • TCP传输是有状态的,这个有状态是指TCP会记录自己发送消息的状态,比如消息是否发送了,是否被接收了等等。因此,TCP需要维持复杂的链接状态表
      • 和是否可靠传输对应,UDP是无状态服务,简单来说就是不管发出去之后的事情了
    • 传输效率

      • TCP进行传输的时候多了连接、确认、重传等机制,所以TCP的传输效率比UDP低很多
    • 传输形式

      • TCP是面向字节流的
      • UDP是面向数据报的
    • 首部开销

      • TCP首部开销(20~60字节)
      • UDP首部开销(8字节)
    • 是否提供广播/多播服务

      • TCP只支持点对点通信
      • UDP支持一对一、一对多、多对一、多对多

    网络层

    网络层常见协议概览

    在这里插入图片描述

    • IP(网际协议)

    • ARP(地址解析协议)

      • 主要作用: 实现从IP地址转换为MAC地址。在每个主机或者路由器中都建有一个ARP缓存表,表中有IP地址及IP地址对应的MAC地址

        • IP地址:互联网协议地址,是IP协议提供的一种统一的地址格式,为互联网的每一个网络和每一台主机分配一个逻辑地址。互联网的每一个资源都有IP地址唯一标识
        • MAC地址:又称物理地址,由网络设备制造商生产时写在硬件内部,不可更改,并且每个以太网设备的MAC地址都是唯一的。特殊地址:FF-FF-FF-FF-FF-FF,该地址表示广播地址
        • ARP表记录了某些其他网络设备的IP地址-MAC地址映射关系,该映射关系以三元组的形式存储。其中,TTL为该映射关系的生存周期,典型值为20mins,超过该时间,该条目将被丢弃
      • ARP地址协议在这里插入图片描述

      • ARP数据传输
        在这里插入图片描述

        • 网络层实现的是主机之间的通信,而链路层实现的是链路之间的通信,所以从下图可以看出,在数据传输过程中,IP数据报的源地址(IP1)和目的地址(IP2)是一直不变的,而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的MAC地址也是不能直接通信的,必须通过路由器转发到主机B的局域网才可以通过主机B的MAC地址找到主机B。并且主机A和主机B已经可以通信的情况下,主机A的ARP缓存表中存的并不是主机B的IP地址及主机B的MAC地址,而是主机B的IP地址及该通信链路上的下一跳路由器的MAC地址。这就是上图中的源IP地址和目的IP地址一直不变,而MAC地址却随着链路的不同而改变
        • 如果主机A和主机B不在同一个局域网,参考上图中的主机H1和主机H2,这时主机H1需要先广播找到路由器R1的MAC地址,再由R1广播找到路由器R2的MAC地址,最后R2广播找到主机H2的MAC地址,建立起通信链路
    • ICMP(互联网控制协议)

    • NAT(网络地址转换协议)

    • OSPF(开放式最短路径优先)

    • RIP(路由信息协议)

    • BGP(边际网关协议)

    网络接口层

    网络接口层重要协议和功能

    在这里插入图片描述

    • 差错检测技术
    • 多路访问协议
    • CSMA/CD协议
    • MAC协议
    • 以太网技术

    数据链路层

    • 将网络层交下来的IP数据报组装成帧,在两个相邻节点间的链路上传送帧。每一帧包括数据和必要的控制信息(如同步信息,地址信息,差错控制等)

    物理层

    • 实现相邻计算机节点之间比特流的透明传送,尽可能屏蔽掉具体传输介质和物理设备的差异
  • 相关阅读:
    大数据ClickHouse(十九):Flink 写入 ClickHouse API
    深入理解Linux网络技术内 幕(六)——PCI层和网络接口卡
    git只提交部分修改的文件(提交指定文件)
    西米支付:游戏支付的概念,发展,什么是游戏支付接口?
    2022-10-20 解决vue项目中不能使用scss的问题:sass-loader的安装
    在kubernetes中对pod使用tcpdump+wireShark进行抓包
    常回家看看之house_of_cat
    【ROS2原理15】ROS2与DDS-安全集成
    《Java核心知识点》+《Java面试宝典》+《1000道互联网面试专题》+《350道Java面试》,总共1045页
    简单的学生网页作业源码 基于html css javascript jquery bootstarp响应式网页设计——大理我的家乡旅游景点
  • 原文地址:https://blog.csdn.net/weixin_55752048/article/details/133933967