20210711计网传输层

20210711计网传输层

编辑时间:2021/07/11

读完本节:大概花费20分钟,共4797词

1.传输层
  1. 网络层与传输层的区别:网络层是为主机之间提供逻辑通信,而传输层是为应用进程之间提供端到端的逻辑通信
  2. 传输层向它上面的应用层提供通信服务,它属于面向通信部分的最高层,同时也是用户功能的最低层。
  3. 传输层的两个主要协议:
    1. 用户数据报协议 UDP(User Datagram Protocol)
    2. 传输控制协议 TCP(Transmission Control Protocol)
  4. 按照OSI模型,两个对等运输运输实体在通信时传送的数据单位叫做运输协议数据单元 TPDU(Transport Protocol Data Unit)。但在TCP/IP体系中,则根据所使用的协议时TCP或UDP,分别称之为TCP报文段(segment)或UDP用户数据报。
2.一些应用和应用层主要使用的传输层协议(TCP或UDP)
  1. 使用UDP和TCP协议的各种应用和应用层协议

    应用应用层协议传输层协议
    域名解析DNS 域名系统UDP
    文件传送TFTP 简单文件传输协议UDP
    路由选择协议RIP 路由信息协议UDP
    IP地址配置DHCP 动态主机配置协议UDP
    网络管理SNMP 简单网络管理协议UDP
    远程文件服务器NFS 网络文件系统UDP
    IP电话专用协议UDP
    流式多媒体通信专用协议UDP
    多播IGMP 网际组管理协议UDP
    电子邮件SMTP 简单邮件传输协议TCP
    远程终端接入TELNET 远程终端协议TCP
    万维网HTTP 超文本传输协议TCP
    文件传送FTP 文件传输协议TCP
3.传输层的端口
  1. 传输层的端口分为两大类:服务器使用的端口号、客户端使用的端口号

    1. 服务器使用的端口号分为两类:熟知端口号(well-know port number)或称系统端口号,数值范围0~1023;登记端口号,数值范围1024~49151,使用这类端口号必须在IANA按照规定的手续登记,以防止重复。

    2. 客户使用的端口号,数值范围49151~65535。由于这类端口号尽在仅在客户进程运行时才动态选择,因此又叫做短暂端口号。

    3. 常用的熟知端口号

      应用程序FTPTELNETSMTPDNSTFTPHTTPSNMPSNMP(trap)
      熟知端口号212325536980161162

      常见的短暂端口号

      客户应用进程OraclemysqlSQL ServerQQ
      短暂端口号1158808014334000
4.用户数据报协议UDP
  1. UDP特点:
    1. UDP是无连接的,即发送数据之前不需要链接,因此减少了开销和发送数据之前的时延。
    2. UDP使用尽最大努力交付,即不保证可靠交付,因此主机不需要维持复杂的链接状态表。
    3. UDP是面向报文的。发送方的UDP对应用程序交下来的报文,在添加首部后就向下交付IP层。
    4. UDP没有拥塞控制,因此网络出现的拥塞不会使原主机的发送速率降低。
    5. UDP支持一对一、一对多、多对一、多对多的通信交互。
    6. UDP的首部开销小,只有8字节,TCP的首部需要20字节。
5.传输控制协议TCP
  1. TCP特点:

    1. TCP是面向链接的传输层协议
    2. 每一条TCP链接只能有两个端点(endpoint),每条TCP链接只能是点对点的
    3. TCP提供可靠交付的服务,通过TCP连接传输的数据无差错、不丢失、不重复、按序到达。
    4. TCP提供全双工通信
    5. TCP协议面向字节流
  2. TCP的连接

    1. TCP把连接作为最基本的抽象

    2. TCP连接的端点称为套接字(socket)或插口

      套接字socket = IP地址:端口号

      每一条TCP连接唯一地被通信两端的端点(即两个套接字)所确定

    3. 同一个IP地址可以有多个不同的TCP连接,而同一个端口号也可以出现在多个不同的TCP连接中。

6.TCP三次握手和TCP四次挥手
  1. TCP首部的相关定义:

    1. TCP首部占20个字节。

    2. 源端口和目的端口:各占2个字节,分别用于表示客户机和服务机的某一进程端口。

    3. 序号:占4个字节。序号范围是0~2^32 - 1。TCP是面向字节流的,因此每一个字节都会按顺序进行编号。首部中的序号字段值指的是报文本段所发送的数据的第一个字节的序号。

    4. 确认号:占4字节,是是期望收到对方下一个报文段的第一个数据字节的序号

      若确认号 = N,则表明:到序号N - 1 为止的所有数据都以正确收到

    5. 数据偏移:占4位,它指出TCP报文的数据起始处距离TCP报文段的起始处有多远。

    6. 保留:占6位,保留以后使用,目前全部置为0.

    7. 紧急URGent:

      当URG = 1时,表明紧急指针字段有效。它告诉系统此报文段中有紧急数据,应当尽快传送,而不要按原来的排队顺序来传送。

      当把URG置为1时,发送应用进程就告诉发送方的TCP有紧急数据要传送。于是发送方TCP就把紧急数据插入到本报文段数据的最前面,而在紧急数据后面的数据仍是普通数据。这时要与首部中紧急指针(Urgent Pointer)字段配合使用

    8. 确认ACKnowledge:仅当ACK = 1时,确认号字段才有效。当ACK = 0时,确认号无效。TCP规定,在连接建立以后所有传输的的报文段都必须将ACK置为1.

    9. 推送PuSH:

      当两个应用进程进行交互式通信时,有事在一端的应用进程希望在键入一个命令以后立即能够收到对方的响应。在这种情况下,TCP就可以使用推送(push)操作。

      这时,发送方TCP把PSH置为1,并立即创建一个报文段发送出去。接收方TCP接收到PSH = 1的报文段,就尽快地交付接收应用进程,而不再等到整个缓存都填满了后再向上交付。

    10. 复位ReSeT:当RST = 1时,表明TCP连接中出现严重错误,必须释放连接,然后在重新建立传输连接。RST置为1还用来拒绝一个非法的报文段或拒绝打开一个连接。RST也可以称为重建位或重置位。

    11. 同步SYNchronization:在建立连接时用来同步序号。当SYN = 1而ACK = 0时,表明这是一个请求连接报文段。若对方同意建立连接,则应在响应的报文段中使用SYN = 1和ACK = 1。因此,SYN置为1就表示这是一个建立连接或连接接受报文。

    12. 终止FINish:用来释放一个连接。当FIN = 1时,表示此报文段的发送方的数据已经发送完毕,并要求释放传输连接。

    13. 窗口:占2字节,窗口的取值范围是0~2^16 - 1之间的整数。窗口是指发送本报文段的一方的接收窗口,而不是自己的发送窗口。窗口值告诉对方:从本报文段的首部中的确认号算起,接收方目前与许对方发送的数据量。存在该限制的原因是:接收方的数据缓存空间是有限的。总之,窗口值作为接收方让发送发送方设置器发送窗口的依据窗口字段明确指出了现在允许对方发送的数据量。窗口值是经常在动态变化着的

    14. 检验和:占2字节,检验和字段检验的范围包括首部和数据这两个部分。

    15. 紧急指针:占2字节,紧急指针在URG = 1时才有意义,它指出本报文段中的紧急数据的字节数(紧急数据后紧接着的是普通数据),因此,紧急指针指出了紧急数据末尾在报文段中的位置。当所有紧急数据都处理完时,TCP就告诉应用程序恢复到正常操作。就算窗口为零时也可以发送紧急数据

    16. 选项:长度可变,最长可达40字节,当没有使用选项时,TCP首部长度是20字节。

  2. TCP连接建立:三次握手

    1. TCP建立连接的过程:

      假定主机A运行的是TCP客户程序,而B运行TCP服务程序,最初两端的TCP进程都处于CLOSED(关闭)状态。

      A主动打开链接,而B被动打开链接。

      B的TCP服务器进程先创建传输控制块TCB(Transmission Control Block存储了每一个连接中的一些重要信息,如:TCP连接表,到发送和接收缓存的指针,到重传队列的指针,当前的发送和接收序号,等等)准备接受客户进程的连接请求。然后服务器进程就处于LISTEN(收听)状态,等待客户的连接请求。如有,即作出响应。

      A的TCP客户进程也是首先创建传输控制模块TCB,然后向B发出连接请求报文段,这时首部中的同步位SYN = 1,同时选择一个初始序号seq = X。 TCP规定,SYN报文段(即SYN = 1的报文段)不能携带数据,但要消耗掉一个序号。这时,TCP客户进程进入SYN-SENT(同步已发送)状态。

      B收到连接请求报文段后,如同意建立连接,则向A发送确认。在确认报文段中应把SYN位和ACK位都置为1,确认号是ack = x + 1,同时也为自己选择一个初始序号seq = y。请注意,这个报文段也不能携带数据,但同样要消耗掉一个序号,这时TCP服务器进程进入SYN-RCVD(同步收到)状态。

      TCP客户进程收到B的确认后,还要向B给出确认。确认报文段的ACK置为1,确认号ack = y +1,而自己的序号seq = x + 1。TCP的标准规定,ACK报文段可以携带数据。但如果不携带数据则不消耗序号,在这种情况下,下一个数据报文段的序号仍是seq = x + 1。 这时,TCP连接已经建立,A进入ESTABLISHED已经建立状态。

      当B收到A的确认后也进入ESTABLISHED状态。

      091245CE-2D09-4537-8649-6D31D9B052F9_1_201_a

    2. 为什么有第三次握手,或者说为什么A要再发送一次确认?

      主要是为了防止已失效的链接请求报文段突然又传送到了B,因而产生错误。

      所谓“已失效的连接请求报文段”是这样产生的。考虑一种正常情况。A发出连接请求,但因连接请求报文段丢失而未收到确认。于是A在重传一次连接请求,后来收到了确认, 建立了连接。数据传输完毕后,就释放了连接。A共发送了两个连接请求报文段,其中第一个丢失,第二个到达了B。没有“已失效的连接请求报文段”。

      现假定出现一种异常情况,即A发出的第一个连接请求报文段并没有丢失,而是在某些网络节点长时间滞留了,以致延误到连接释放以后的某个时间才到达B。本来这是一个早已失效的报文段,但B收到了此失效的链接请求报文段后,就误认为是A又发出一次新的连接请求。于是就向A发出确认报文段,同意建立连接,假定不采用三次握手,那么只要B发出确认,新的连接就建立了。

      由于现在A并没有发出建立连接的请求,因此不会理睬B的确认,也不会向B发送数据。但B却以为新的传输链接已经建立了,并一直等待A发来数据。B的许多资源就这样被浪费了。采用三次握手的办法可以防止上述现象的发生。

  3. TCP连接释放:四次挥手

    1. TCP连接释放过程:

      数据传输结束后,通信的双方都可以释放链接,现在A和B都处于ESTABLISHED状态。A的应用进程先向其TCP发出连接释放报文段,并停止再发送数据,主动关闭TCP连接。A把连接释放报文段首部的终止控制位FIN置为1,其序号seq = u,它等于前面已传送过的数据的最后一个字节的序号加1。这时A进入FIN-WAIT-1(终止等待1)状态,等待B确认。注意,TCP规定,FIN报文段即使不携带数据,它也要消耗掉一个序号。

      B收到连接释放报文段后即发出确认,确认号是ack = u +1,而这个报文段自己的序号是v,等于B前面已传送过的数据的最后一个字节的序号加1。然后B就进入CLOSED-WAIT(关闭等待)状态。 TCP服务器进程这时应通知高层应用进程,因而从A到B这个方向的连接就释放了,这时的TCP连接处于半关闭(half-close)状态,即A已经没有数据要发送了,但B若发送数据,A仍要接收。也就是说,从B到A这个方向的链接并未关闭,这个状态可能会持续一些时间。

      A收到来自B的确认后,就进入FIN-WAIT-2(终止等待2)状态,等待B发出的链接释放报文段。

      若B已经没有要向A发送的数据,其应用进程就通知TCP释放连接,这时B发出的连接释放报文段必须使FIN = 1。现假定B的序号为W在(半关闭状态B可能又发送了一些数据)。B还必须重复上次已发送过的确认号ack = u + 1。这时B就进入LAST-ACK(最后确认)状态,等待A的确认。

      A在收到B的连接释放报文段后,必须对此发出确认。在确认报文段中把ACK置为1,确认号ack = w + 1,而自己的序号是seq = u + 1(根据TCP标准,前面发送过的FIN报文段要消耗一个序号)。然后进入到TIME-WAIT(时间等待)状态。请注意,现在TCP连接还没有释放掉。 必须经过时间等待计时器(TIME-WAIT timer)设置的时间2MSL后,A才进入到CLOSED状态。时间MSL叫做最长报文段寿命(Maximum Segment Lifetime),RFC建议设置为2分钟。因此,从A进入到TIME-WAIT状态后,要经过4分钟才能进入CLOSED状态,才能开始建立下一个新的连接。当A撤销相应的传输控制块TCB后,就结束了这次的TCP连接。

      B只要要收到了A发出的确认,就进入CLOSED状态。同样,B在撤销相应的传输控制块TCB后,就结束了这次的TCP连接。可以注意到B结束TCP连接的时间要比A早一些。

      DBF365E9-19F1-4E42-AD4E-DF0DF8AE6591_1_201_a

    2. 为什么A在TIME-WAIT状态必须等待2MSL的时间?

      1. 为了保证A发送的最后一个ACK报文段能够到达B。这个ACK报文段有可能丢失,因而使处在LAST-ACK状态的B不能收到对方已发送的FIN + ACK报文段确认。B会超时重传这个FIN + ACK报文段,而A就能在2MSL时间内收到这个重传的FIN + ACK报文段。接着A重传一次确认,重新启动2MSL计时器。最后A和B都正常进入到CLOSED状态。如果A在TIME-WAIT状态不等待一段时间,而是发送完ACK报文段后立即释放连接,那么就无法收到B重传的FIN + ACK报文段,因而也不会再发送一次确认报文段。这样,B就无法按照正常步骤进入CLOSED状态。
      2. 防止“已失效的连接请求报文段”出现在本连接中。A在发送完最后一个ACK报文段后,再经过时间2MSL,就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。
    3. 保活计时器

      1. 除了时间等待计时器外,TCP还设有一个保活计时器(keepalive timer)。

      2. 设置保活计时器的原因在如下情景下适用:

        客户已主动与服务器建立了TCP连接。但后来客户端的主机出现故障。显然,之后的服务器就不能再次收到来自客户端主机发来的数据。

      3. 保活计时器工作过程:

        服务器每收到一次客户的数据,就重新设置保活计时器,时间的设置通常是2个小时。若两个小时没有收到客户的数据,服务器就发送一个探测报文段,以后每件个75分钟发送一次。若连续发送10个探测报文段后仍无客户的响应,服务器就认为客户端出现了故障,接着就关闭连接。

  4. TCP的有限状态机

    有限状态机清晰的能够表示TCP各种状态之间的关系,方框内的英文表示TCP标准所使用的TCP连接状态名。箭头旁的辅助文字表示引起状态发生变迁的原因,或表明发生状态变迁后又出现什么动作。其中,粗实线箭头表示对客户进程的正常变迁;粗虚线箭头表示对服务器进程的正常变迁;细箭头表示异常变迁。

    51AB6FB3-5513-4C6F-BBAA-D1BD31A2373E_1_105_c

无限进步
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值