计算机网络-传输层学习笔记

传输层:

  提供可靠的,高效的数据传输。网络层通过将数据传输到某一目的主机,传输层的目的就是将数据运送到具体的某一个具体的进程(端到端的通信)。如送达一个浏览器数据到浏览器而不是去视频播放器或其他的进程。传输层将通过端口号来定位到具体的应用进程中。传输层的服务包含两种,一种是面向连接的服务,另一种是无连接的服务。传输层有两个协议分别是TCP协议和UDP协议

  


  1.端口:

    端口是传输层寻址的重要部分,可以将端口看作一个门,门后就是不同的进程,数据需要通过门端口来标识哪个是对应的进程,进程也需要通过端口来向下发送数据。

    端口号就是用来标识应用进程的数字标识。长度为16比特,范围是0~65535。

    

    常见应用层协议对应的TCP端口号

    这个端口与交换机上的端口是不同的。

    


    2.协议:

      TCP与UDP简介:

        用户数据报协议(UDP)是无连接的不可靠传输,无连接指的是发送方发出数据之后就不再管了,让网络尽可能的去发送这个数据包,不保证数据一定能到达目的端,所以是不可靠的。

        传输控制协议(TCP)是面向连接的可靠传输,指的是发送之初,双方会先建立连接,在发送数据的时候会一直监控着这个连接,保证传输的可靠性

        

      2.1.UDP:

        ①UDP数据报:UDP数据报有两个部分组成,分为UDP首部和用户数据部分。首部部分有8个字节UDP多用于视频传输和音频传输。,格式如下

      

       因为UDP不需要应答,所以来源端口是可选的,如果来源端口不用,那么置为零

       校验和也是可选字段,选用校验和可以更好的传输。这个校验和包含了头部和数据部分

       

      UDP数据包格实例:

      

       我们首先看网络层的上层协议是UDP。

      UDP的源端口为62507,目的端口为8000,数据总长度194。还有校验和。

      UDP数据头非常简单而且非常短小。UDP传输速度快,消耗资源小,适合一对一,一对多,多对多等通信,适合于可以允许丢一定量的包的应用。所以通常音频、视频和普通数据在传送时使用UDP较多。

      


      2.2.TCP

        TCP协议要解决传输的可靠、有序、无丢失和不重复的问题。TCP传输的数据一般都很大,需要多次发送,那么TCP就提供了可靠有序的传输。每一个TCP只能有2个端点,TCP是一对一的通信,TCP提供的是全双工的,面向字节流的通信。

        2.2.1.TCP数据格式:

            TCP数据段的大小必须在65515的字节大小以内(即IP数据报最大大小减去IP数据报头部的20字节大小)并且TCP数据段要符合下层MTU最大传输数据单元的大小

          

           第一行:源端口和目的端口。

           第二行:当前数据的一个序号,随机产生

              第三行:期望接收的字节编号

           第四行:显示TCP头部长度,接下来四位是未使用位(置为0),后面跟着8个1字节的字段分别是

               CWR和ECE为拥塞控制信号

               URG置为1表示紧急指针字段有效,需要有限处理这个数据。

               ACK置为1表示确认号字段有效 ,反之为0为无效。

               PSH置为1表示是带有 PUSH标志的数据,接收方应该尽快将数据交给上层而不用等待缓冲区装慢。

               RST 置为1表示出现严重差错。可能需要重现创建TCP连接。也可以用于拒绝非法的报文段和拒绝连接请求

               SYN 置为1表示这是连接请求或是连接接受请求,当SYN为1时,若ACK为0则为请求连接,若ACK为1则为连接接受。

               FIN置为1表示发送方没有数据要传输了,要求释放连接。

               最后16个字节为窗口大小,即源端可以接收的字节数,源方接收窗口大小。用于流量控制。

           第五行:校验和字段对整个数据报(头部和数据部分)进行校验,

               紧急指针字段和URG控制位配合使用指明了紧急数据

           第六行和之后:可选的选项以及数据段。


           2.2.2.TCP的(三次握手)建立连接:

              将建立TCP两端分为服务端和客户端。一般来说服务端会监听连接请求,而客户端会主动发送连接请求,服务端监听到之后会给客户端发送确认应答。最后客户端发送确认,并建立链接。由于TCP是全双工的,没有规定数据的流向,建立了TCP的双方都可以收发数据。

  第三次握手可以让服务器确认第二次发送的SYN的有效性

                

CLOSED->LISTEN.

主机1请求连接:控制位SYN字段置为1,seq字段(序号)置为x 是一个随机值,控制位ACK置为0。(状态:SYN_SENT

主机2发送应答:其中seq字段(序号)置为y是主机2随机产生的一个随机值,确认号字段ack为x+1(发送过来的序号+1),控制位SYN字段为1,控制位ACK字段为1。(状态:SYN_RECEIVED

主机1发送确认:seq字段(序号)为x+1,确认号字段ack为y+1,其中控制位SYN为0,控制位ACK为1。(状态:ESTABLISHED,发送数据持续ESTABLISHED状态

  状态总结:

  • CLOSED:初始状态,表示没有任何连接。
  • LISTEN:Server端的某个Socket正在监听来自远方的TCP端口的连接请求。
  • SYN_SENT:发送连接请求后等待确认信息。当客户端Socket进行Connect连接时,会首先发送SYN包,随即进入SYN_SENT状态,然后等待Server端发送三次握手中的第2个包。
  • SYN_RECEIVED:收到一个连接请求后回送确认信息和对等的连接请求,然后等待确认信息。通常是建立TCP连接的三次握手过程中的一个中间状态,表示Server端的Socket接收到来自Client的SYN包,并作出回应。
  • ESTABLISHED:表示连接已经建立,可以进行数据传输。

 ,  


            2.2.3.TCP(四次挥手)连接释放

                当一方(主机A)没有数据要发送的时候就可以发送一个断开连接请求,如果这个断开连接请求被确认,那么这一方的连接将会被断开(主机A向主机B的链接被关闭,即A无法向B发送数据,但B还可以向A发送数据)如果两方连接都断开了连接,那么TCP链接将被释放

                    

                    

                   主机A没有信息要发送了:

                    主机A(主动一方)主动请求断开连接:控制位FIN为1序号字段seq置为u(随机值)(主机A进入FIN_WAIT_1状态)  

                    主机B发送应答确认:控制位ACK为1序号字段seq置为v(随机值)确认号字段(ack)=u+1(主机A进入FIN_WAIT_2状态)

                    主机A->B的连接断开。(但是B可能还在给A发送数据,所以B->A的连接并没有关闭)(主机A在FIN_WAIT_2状态中)(主机B进入CLOSE_WAIT状态)

                    主机A等待主机B发送断开连接请求(主机A在FIN_WAIT_2状态中)

                    主机B没有信息要发送了:

                    主机B(被动一方)发送断开连接请求:控制位FIN为1ACK为1序号字段seq置为w(随机值),确认号字段ack为u+1主机B进入LAST_ACK状态)

                    主机A发送应答确认:控制位ACK为1,序号字段seq置为u+1(随机值)确认号字段(ack)=w+1(主机A进入TIME_WAIT状态)

                    主机B->A的连接断开。

                    连接释放成功。           

 

                   在主机A,B发哦那个断开连接请求的时候都会启动定时器,一旦定时器超时(即长时间没有接受到确认应答)也会断开连接

 

  状态总结:

  • FIN_WAIT_1:主动关闭连接的一方等待对方返回ACK包。若Socket在ESTABLISHED状态下主动关闭连接并向对方发送FIN包(表示己方不再有数据需要发送),则进入FIN_WAIT_1状态,等待对方返回ACK包,此后还能读取数据,但不能发送数据。在正常情况下,无论对方处于何种状态,都应该马上返回ACK包,所以FIN_WAIT_1状态一般很难见到。
  • FIN_WAIT_2:主动关闭连接的一方收到对方返回的ACK包后,等待对方发送FIN包。处于FIN_WAIT_1状态下的Socket收到了对方返回的ACK包后,便进入FIN_WAIT_2状态。由于FIN_WAIT_2状态下的Socket需要等待对方发送的FIN包,所有常常可以看到。若在FIN_WAIT_1状态下收到对方发送的同时带有FIN和ACK的包时,则直接进入TIME_WAIT状态,无须经过FIN_WAIT_2状态。
  • TIME_WAIT:主动关闭连接的一方收到对方发送的FIN包后返回ACK包(表示对方也不再有数据需要发送,此后不能再读取或发送数据),然后等待足够长的时间(2MSL)以确保对方接收到ACK包(考虑到丢失ACK包的可能和迷路重复数据包的影响),最后回到CLOSED状态,释放网络资源。
  • CLOSE_WAIT:表示被动关闭连接的一方在等待关闭连接。当收到对方发送的FIN包后(表示对方不再有数据需要发送),相应的返回ACK包,然后进入CLOSE_WAIT状态。在该状态下,若己方还有数据未发送,则可以继续向对方进行发送,但不能再读取数据,直到数据发送完毕。
  • LAST_ACK:被动关闭连接的一方在CLOSE_WAIT状态下完成数据的发送后便可向对方发送FIN包(表示己方不再有数据需要发送),然后等待对方返回ACK包。收到ACK包后便回到CLOSED状态,释放网络资源。
  • CLOSING:比较罕见的例外状态。正常情况下,发送FIN包后应该先收到(或同时收到)对方的ACK包,再收到对方的FIN包,而CLOSING状态表示发送FIN包后并没有收到对方的ACK包,却已收到了对方的FIN包。有两种情况可能导致这种状态:其一,如果双方几乎在同时关闭连接,那么就可能出现双方同时发送FIN包的情况;其二,如果ACK包丢失而对方的FIN包很快发出,也会出现FIN先于ACK到达。

 

   

    TCP抓包实例:

           

 


              2.2.4.TCP如何实现可靠传输:

              ①自动重传请求(ARQ):

                是一种可靠传输协议,即发送方发送一个数据报之后就开始等待接收方发送的应答。收到应答之后才发下一段数据报。若一段时间没收到应答,那么发送方就认为接收方没有接收到数据,就重新传输刚才的数据。比如接收方接受并确认了1,2,3号数据,那么发送确认号为4,代表发送方下一个发送数据标号为4。

                但由于上述方法的信道利用率太低,于是引入了连续ARQ,其中利用了滑动窗口。也就是每次定义一个窗口,在发送时,将窗口内的数据顺序发送,每当接收到窗口中的第一个数据的应答那么就,从缓存区清除这个数据,之后往后滑动窗口,并发送新进入窗口的数据。若取得一个良好的窗口数,可以在发送完窗口中最后一个数据时,刚好接收到窗口中第一个数据的应答。

            

                ②累计确认机制:接收方一般都是采用累积确认的方式。也就是说接收方不必对收到的分组逐个发送确认。而是在收到几个分组后,对按序到达的最后一个分组发送确认。如果收到了这个分组确认信息,则表示到这个分组为止的所有分组都已经正确接收到了。累计确认的缺点:对于缺失分组后收到的分组不能正确反映,即发送端发送了1,2,3,4,5,五个数据包,其中接收方收到了数据包1, 2 , 4 ,5。那么接收方只会发送第二个包的应答,那么发送方会从第3个包开始重新发送,即发送包3,4,5。实际上4,5以已经被接收方正确接收了。(和数据链路层的回退N帧协议是一样的)

            在TCP的发送方A和接收方B,分别都有个接收,发送缓存。之后AB建立连接,建立连接后,发送方根据接收方的窗口大小来设置发送窗口大小。在设置好之后就开始发送数据,发送方A顺序发送窗口里面的数据包,发送完的数据仍存在缓存中,待接收到数据,发送方清楚缓存中的数据并,移动窗口,发送新数据。接收方接收到数据会采用选择确认机制累计确认机制,在接收到几个分组之后,会检查分组是否连续,并发送确认帧,确认了的帧将从接收方B的窗口中移除,并且接收方的应用程序可以读取这些数据,若出现数据包丢失,将会发送一个SACK(选择确认),包含丢失包的信息,那么发送端就只发送丢失的包,解决了单纯累积确认的重复发送问题

                ③重传计时器:

                  TCP中重传计时器由于网络的不同环境,其所对应的最优值也是在变化,定时器太长会影响效率,太短会导致频繁的重传,TCP采用了动态算法,随着时间不断调整计算机时间。

                  对于每一个连接维护一个RTTS(平均往返时间)表示往返的一个最佳估计时间,超时重传时间已经略大于RTTS。

                  计算公式为:

               

                   其中a为一个系数,一般为1/8。(权衡于依赖旧值和依赖更新值的系数)

                   新RTT(最新的往返时间)为最近一次接受到数据包所测得的往返时间。

                  


            2.2.5.TCP流量控制:

              流量控制决解了收发两端,处理速度不一致的问题。发送速度若远大于接收速度,会导致接收方缓存区溢出,导致崩溃。此时需要接收方发送数据告诉发送方,让发送速度慢点。 

              解决过程:

                   1.在发送确认帧的时候调整发送方窗口的大小,将发送方的窗口调小或调大来控制传输的速率。

                   2.接收端将自己可以接收的窗口大小放入 TCP 首部中的 “窗口大小” 字段, 通知发送端;窗口大小字段越大, 说明网络的吞吐量越高。
                   3.接收端一旦发现自己的窗口快满了, 就会将窗口大小设置成一个更小的值通知给发送端;发送端接受到这个窗口之后, 就会减慢自己的发送速度。

                   4.如果接收端窗口满了, 就会将窗口置为0; 这时发送方不再发送数据,待缓冲区清空在发送窗口值来告知,发送端可以发送数据了。发送方当接受到窗口为0的更新消息后会启动一个定时器,若定时器超时,则发送一个探测数据段引发对面来发更新窗口,避免了死锁,即接收方收不到发送方的窗口更新消息情况(数据丢失)。

            2.2.6.TCP拥塞控制:

             网络上有很多计算机,许多计算机发送消息时很可能会造成网络拥堵,而且网络拥塞状况不容易获取,所以TCP需要有一个拥塞控制机制,来获取拥塞窗口保证在窗口大小内的数据可以顺利传输。由于有了流量控制的机制,每次发送数据的时候取接收端窗口和拥塞窗口的最小值来作为发送窗口。

         1.慢启动算法:首先发送一个最大数据段,并设定一个阈值,启动定时器。

          若在定时器超时之前接受到来自接收方的应答,那么可以认为这个1个最大数据段是可以通过的,拥塞窗口设为其大小(即1个最大数据段的大小),下一次就发送2个数据段(即翻倍)

          阈值:当前发送的数据段大于等于阈值,那么将发送数据段的增长变为线性,即保证一次增加一个数据段的增长。

          若出现了在定时超时了还未接受到确认帧,那么将阈值减半,将发送数据段重新置为1个最大数据段,重复以上步骤。每次都可以获得最新的网络状况,来更新拥塞窗口。

                    

猜你喜欢

转载自www.cnblogs.com/CaoRuiChen/p/12757761.html