TCP/IP模型五层协议

TCP/IP模型五层协议

认识协议

约定双方进行的一种约定

协议分层

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

四/五层协议

  • 五层协议的作用
    TCP/IP模型五层协议_第1张图片

应用层

应用层常见协议

  • 应用层常见协议概览
    TCP/IP模型五层协议_第2张图片

  • 基于TCP的协议

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

    • RTP(实时传输协议)

    • DNS(域名管理系统)

      • 用于解决域名和IP地址的映射问题
        TCP/IP模型五层协议_第3张图片

      • 为什么域名解析用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报头
      TCP/IP模型五层协议_第4张图片

      • 源端口

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

      • UDP长度

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

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

        • 常见算法

          • CRC

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

            • 特点

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

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

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

    • UDP载荷(payload)

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

TCP协议

  • TCP的特点

    • 有连接

    • 可靠传输

      • TCP最核心的部分

      • 保证整体TCP的可靠性

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

    • 全双工

  • TCP报文

    • TCP报头
      TCP/IP模型五层协议_第5张图片

      • 源端口号(16位)

      • 目的端口号(16位)

      • 序列号(32位)

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

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

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

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

        • URG

        • ACK

          • 应答报文
        • PSH

        • RST

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

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

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

      • 选项(长度可变)

      • 数据

    • TCP载荷

  • TCP内部的工作机制

    • 确认应答

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

      • 应答报文

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

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

      • 丢包

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

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

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

    • 连接管理

      • 建立连接:三次握手
        TCP/IP模型五层协议_第6张图片

        • 三次握手的意义

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

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

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

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

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

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

        • 为什么要四次挥手?

          • 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
            TCP/IP模型五层协议_第8张图片

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

      • 滑动窗口

        • 为什么引入

          • 引入可靠性,其实付出了代价:传输效率降低了。所以TCP在保证可靠性的前提下,尽可能地提高传输效率
        • 本质就是降低了确认应答,等待ACK消耗的时间
          TCP/IP模型五层协议_第9张图片

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

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

          • ACK丢了
            TCP/IP模型五层协议_第10张图片

            • 不需要作任何处理,此时要理解确认序号的含义:该序号往前的所有数据都确认到达了。比如2001这个ACK其实包含了1001这个ACK的信息
          • 数据丢了
            TCP/IP模型五层协议_第11张图片

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

              • 如果当前传输数据密集,按照滑动窗口的方式传输,此时按照快速重传处理丢包
              • 如果当前传输数据稀疏,不按照滑动窗口的方式传输,此时按照超时重传处理丢包
            • TCP/IP模型五层协议_第12张图片

      • 流量控制

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

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

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

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

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

              • 窗口探测报文不携带任何具体的业务数据,只是为了触发ACK查询窗口大小
                TCP/IP模型五层协议_第13张图片

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

              • 窗口大小只有在报文是ACK时才会生效。并且窗口大小不只是64kb,在选项中有个扩展因子可以让窗口更大
                TCP/IP模型五层协议_第14张图片

      • 拥塞控制

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

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

          • TCP/IP模型五层协议_第15张图片

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

    • 延时应答

      • 也是提升效率的机制
      • 收到数据后,不是立即返回ACK,而是等会再返回。等待时间里,接收方的应用程序就能把接收缓冲区的数据消费一波,此时剩余空间就更大了
      • 比如这里就是两条返回一个ACK
        TCP/IP模型五层协议_第16张图片
    • 捎带应答

      • 也是提高传输效率的机制(在延时应答的基础上,引入了捎带应答)
      • 本来是不同时机,在延时应答下,可能成为相同时机,就合并发送了
      • TCP/IP模型五层协议_第17张图片
    • 面向字节流

      • 可能出现“粘包现象”

        • 由于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支持一对一、一对多、多对一、多对多

网络层

网络层常见协议概览

TCP/IP模型五层协议_第18张图片

  • 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地址协议TCP/IP模型五层协议_第19张图片

    • ARP数据传输
      TCP/IP模型五层协议_第20张图片

      • 网络层实现的是主机之间的通信,而链路层实现的是链路之间的通信,所以从下图可以看出,在数据传输过程中,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(边际网关协议)

网络接口层

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

TCP/IP模型五层协议_第21张图片

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

数据链路层

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

物理层

  • 实现相邻计算机节点之间比特流的透明传送,尽可能屏蔽掉具体传输介质和物理设备的差异

你可能感兴趣的:(计算机网络,秋招复习,tcp/ip,网络协议,网络)