zoukankan      html  css  js  c++  java
  • 第5章 运输层

    5.1 运输层协议概述

    5.1.1 进程之间的通信

      主要讲了一个问题:为什么在网络层已经提供数据通信服务(IP数据报)的前提下还需要运输层?

      运输层的地位:运输层直接向应用层提供服务,而路由器在进行路由转发的时候不具有运输层和应用层。

      运输层的作用:1、为进程提供服务。网络层提供的数据报传输服务只能把数据报从一个主机传送到另一个主机的网络层上,但通信的本质并不是面向主机而是面向进程,只有把信息送到目标主机上一次通信才算完成,这正是运输层需要做的工作:向应用层提供进程和进程之间的通信,屏蔽底层通信细节使整个通信的过程透明化。这种进程之间透明的通信被称为逻辑通信,所谓逻辑通信是指在应用进程看来只需要把信息交给运输层就可以传递到目标进程上。运输层提供的是进程和进程间的逻辑通信,而网络层提供的是主机要主机的逻辑通信

      

      2、提供差错检测。运输层对收到的报文进行差错检测。

    5.1.2 运输层的两个主要协议

    • 面向连接的TCP。传输数据前建立连接,数据传输结束后释放连接。可靠但代价大。
    • 不面向连接的UDP。传输数据前不建立连接,目的主机接收到报文后不做确认。不可靠但效率高。

      

    5.1.3 运输层的端口

      运输层的复用:进程->运输层->应用层。不同的进程都要通过运输层,这就是运输层的复用。

      运输层的分用:网络层->运输层->进程。运输层从网络层收到数据然后交付给指定进程,由于所有进程的通信都必须经由运输层,所以运输层必须能够有一种方式来定位一个进程。这正是端口的作用:为进程赋予一个标志位

      为什么不用PID?:通信在各种不同的OS之间进行不能通过OS默认的区别进程的方法用在通信中;PID是一个动态的,可能通信过程中PID无效了

      那怎么办?:端口号(port)。运输层只要把送给某一个进程的消息交付给指定端口,剩下的事情交给TCP完成。

    端口:

    • 意义:标识在当前计算机中各个进程在于运输层交互时的层间接口
    • 长度:16位 65536个
    • 位置:发送一个报文的时候既要有目的地址的端口号也要有发送端地址的端口号
    • 分类:服务器使用的端口号 客户端使用的端口号
    • 服务端使用的端口号:在服务器上使用的端口号,里面有很多老朋友

    • 客户端使用的端口号:客户进程运行时候动态的选择,是朝生夕死的端口号,通信结束后端口号就被回收然后交给别的进程使用

    5.2 用户数据报协议UDP

    5.2.1 UDP概述

      仅仅在IP数据报上增加了很少的功能:分用复用 差错检测

    • 无连接。发送前不建立连接,发送完毕后不释放连接,所以开销小。
    • 尽最大努力。就是不可靠。
    • 面向报文。当应用程序把内容交给UDP的时候,UDP只是加上头部和尾部然后交给下一层;当UDP收到网络层传过来的IP数据报的时候只去除首位然后传上去。所谓面向报文就是不管报文内容、不对报文切割仅仅添加首位部。所以如果报文如果太大网络层就要切割,报文如果太小IP数据报的头部就会太大,两种情况都会让效率遍地。
    • 没有拥塞控制。即使网络出现了拥塞也会发送UDP数据报,虽然可能会损失数据但不会降低发送效率,在IP电话或者实时视频会议领域很适合。
    • 支持一对一 一对多 多多 多以
    • 首部小,开销低

      总而言之UDP就是一种效率至上,不考虑可靠性的协议。它简单、高效、但准确性差。很像国产的协议。

    5.2.2 UDP的首部格式

      

    5.3 传输控制协议TCP

    5.3.1 TCP最主要的特点

    • 面向连接。又出现了一次面向XX,上次是在UDP中所谓的UDP面向报文,但这两个面向的语义似乎有点不同,这里面向连接仅仅指TCP工作前必须建立连接,传输完毕后必须释放连接
    • 点对点。同样对比UDP,UDP支持点点 点多 多多 多点
    • 可靠。对比UDP,UDP不可靠,TCP无差错、不丢失、不重复
    • 全双工通信。通信双方都可以发送信息,发送和接收面对的都是TCP缓存,发送的时候把信息放到缓存里,接收的时候从缓存里读取数据
    • 面向字节流。虽然TCP协议每次交付的是一个数据块,但是TCP把应用数据块仅仅看成无结构的字节流,字节流的还原不属于TCP的工作
    • 面向字节流和面向缓存,给了TCP流量控制和拥塞控制的能力,TCP协议会根据网络的状态选择从TCP缓存里取出多少数据用于发送,同时也会根据数据块的大小对每次发送的数据进行大小修改,如果数据块太大TCP会把它分割小一些再传送,如果数据库太小TCP会等手机到很多数据块再发送。这也是TCP和UDP的区别,UDP是一个不分责任的协议,无论应用层给他什么协议它都直接加上头传过去

    5.3.2 TCP的连接

      TCP连接是什么:一条虚拟的信道,把通信双方的进程连接起来

      由什么组成:TCP连接由两个套接字(socket)组成,分别代表通信双方进程。

      socket:(IP1,port1),(IP2,socket2),就是IP加端口

    5.4 可靠传输的工作原理

      可靠性传输:在网络层是否需要保证传输的可靠性的讨论中,我们知道TCP协议在网络层并没有保证传输的可靠性,IP协议只是尽最大努力的传输数据报。所以TCP面对的是一个不可靠的协议,因而TCP要保证传输的可靠性

      怎么保证:1、传输信道不产生差错 2、有速度控制,即接收方要能够来得及处理发送方传来的数据,如果处理不过来必须让发送方慢点来

    5.4.1 停止等待协议

      发送方A向接收方B发送一个分组后就停下来等待确认后再发送下一个分组。

      理想情况:在AB通信没有发生错误的时候,A发一个B收到后确认一个,AB之间很有节奏感的在通信

      发送分组出现差错:A在发送M后会开启定时器,如果定时器结束后没有收到B的确认报文,A会重发M。因为需要重发M所以A在发送端保存每个发送的分组的副本且要对副本编号,这样才能在重传的时候确定需要重传哪个分组。无论是A发送的分组B没有收到,还是B在接收M后检验发生了差错,B都不会向A发送确认消息,此时A在超时没有收到确认协议后就会重发报文。 

      确认分组出现差错:B对收到的分组发出的确认没有成功传到A,A在超时没有收到应答后再次发送分组M,B收到分组后:1、丢弃 2、再次发送确认

      确认分组迟到:B收到了分组,B也发送了确认,只不过在确认到达前A等待超时,A会再次发送分组M,这样以来A收到了两次确认,对于重复的内容物理是分组还是分组的确认都是直接丢弃

      自动重传ARQ:向上面这种根据是否超时决定是否重复发送分组的协议称为自动重传请求,能够在不可靠的网络上实现可靠的通信

    5.4.2 滑动窗口协议

      每发送一个分组就停下来会使信道的利用率降低,改进的策略是每次发送一些分组。与滑动窗口协议配合的重传协议称为连续ARQ

    5.5 TCP报文段的首部格式

      记住常用的首部字段的意义便于后面理解协议

    • 源端口和目的端口
    • 序号。TCP是面向字节流的所以每个字节都有自己的编号。在建立TCP连接的时候需要约定第一个传送字节的字节号。TCP报文首部中的序号指的是该报文锁携带的字节流的第一个字节的序号。
    • 确认号。期望收到的下一个字节的编号
    • 确认。和上面的确认号区分开来,确认是大写的ACK,确认号是小写的ack。确认的值域是0或者1。TCP规定连接建立后所有的报文段中ACK都必须为1。
    • 同步SYN。在建立连接的时候同步序号,SYN=1代表该报文是用来建立连接,发送端SYN=1 ACK=0 确认端SYN=1 ACK=1
    • 窗口。告诉接收方自己的缓冲区还能存放多少内容 

    5.6 TCP可靠传输的实现

      发送端的窗口:滑动窗口里面的内容表示发送端可以发送的数据,后沿代表发送且确认的数据,前沿代表不可发送的数据。

      接收端的窗口:接收端的窗口可能会暂存着没有按照顺序到达的数据,但接收端发送的接收确认只能是按顺序的,下面这个情况需要发送31确认号。

       发送端窗口和缓存的关系:发送方的进程把想要发送的内容写入TCP缓存中,然后发送端根据接收端窗口的大小确定发送端窗口大小。所以发送端缓存大于发送端窗口,窗口是缓存的一部分。缓存和窗口的后沿是重合的,发送端每收到一个确认信息就把对应的消息从缓存中删除,后沿相应的向前挪动。整个缓存是环形的,内存复用。

      接收端缓存:接收端缓存存放着已经收到但是未被进程读走的内容,未被读走的内容包括两部分:1、按顺序发来但是没有读 2、非按顺序发来

    5.6.2 超时重传时间的选择

    5.6.3 选择却SACK

    5.7 TCP的流量控制

    5.7.1 利用滑动窗口实现流量控制

    窗口的移动:发送端每发送一个数据,P2后移,每收到一个确认消息P1后移,P3相应的后移,P3后移的距离根据发送端窗口大小来确定。

    为什么需要流量控制:如果发的太快,接收端缓冲区满了会带数据丢失。

    流量控制:

    建立连接时确认窗口大小:TCP协议工作前需要建立连接,在建立连接时B会把自己能够接受的窗口以字节为单位传给A,A相应的建立自己的发送端窗口大小

    发送过程中修改窗口大小:接收端在发送ACK的时候回根据自己的情况修改窗口大小

    死锁打破:如果接收端无法收报文会发送一个0窗口报文通知A不要发送数据,此时A会启动一个计时器如果计时器结束后B仍然没有重新发送修改窗口大小报文,A会发送一个探测报文

    5.8 拥塞控制

    5.8.1 拥塞控制

    什么是拥塞:拥塞是针对整个网络而言的,如果网络能提供资源大于对网络资源的需求就会发生拥塞

    拥塞控制:拥塞控制也是针对整个网络而言的,防止过多的数据同时注入到网络中,是一个全局的过程

    拥塞控制和流量控制的区别:发送端迟迟没有收到接收端的确认消息会猜测是不是发生了拥塞,流量控制是发送端收到了接收端的流量控制的要求从而减缓发送的速率

    相同点:都会使发送端降低发送的速率

    5.8.2 拥塞控制算法

    5.9 TCP连接的建立和释放

      TCP是面向连接的所有TCP通信前需要建立连接,在建立的过程中需要解决的问题

    • 通信双方彼此知道对方存在
    • 协商参数如窗口大小
    • 协商实体资源如缓存

    5.9.1 TCP连接的建立

      虽然TCP是双工通信协议单一般把发起连接请求的称为客户端,接收连接的称为服务端。

      臭名昭著的三次握手:

      所谓三次握手指的是建立TCP通信是双方需要发送三次报文

    • A向B发送请求报文段,报文中SYN=1 seq=x(A选择一个初始序号)。SYN=1的报文不能携带数据。A发送完后进入同步已发送状态。
    • B收到报文如果同一建立连接,需要向A发送一个确认报文。SYN=1 ACK=1 ack=x+1 同时选择seq=y,因为SYN=1所以不能携带数据。B进入同步收到状态
    • A收到B的报文后还要再发一次报文,ack=y+1 seq=x+1 SYN=1 ACK=1

      为什么需要三次握手:防止已经失效的连接请求报文传到B。加入A发送了一次请求建立报文但是在网络中某个节点滞留,由于长时间没收到确认信息所以A再次发送请求建立报文,然后一次TCP握手完成,通信完成后释放TCP。此时滞留的请求建立报文传到了B,B以为A又要建立连接,B向A发送确认报文,如果没有三次握手那么AB会错误的建立连接,而在三次握手的情况下,A知道自己没有建立连接的意愿会忽略B的请求确认报文。

    5.9.2 TCP连接释放

      四次挥手

    • A向B发送释放报文,FIN置为1,seq=u等于前面的seq+1
    • B收到报文后向A发送确认报文。ack=u+1 seq=v等于前面序号+1。此时AB处于半关闭状态,B仍然可以向A发数据
    • B再次向A发送报文。FIN=1 ack=u+1 seq=wB可能又发了一些报文
    • A收到报文后再次向B确认。ACK=1 ack=w+1 seq=u+1。等待MSL时间后TCP释放

        

     

      

  • 相关阅读:
    KVM镜像管理利器-guestfish使用详解
    两台linux机器时间同步
    git配合tortoiseGit的基础使用
    使用yum来下载RPM包而不进行安装
    Linux解压缩总结
    Linux下使用git命令及github项目
    linux shell常用快捷键
    调用 sphinx-build生成HTML文件
    复制virtualenv环境到其他服务器环境配置的方法
    CentOS 6.5 PYPI本地源制作
  • 原文地址:https://www.cnblogs.com/AshOfTime/p/10713938.html
Copyright © 2011-2022 走看看