应用层

网络

网络7层协议

• 应用层
• 表示层
• 会话层
• 运输层
• 网络层
• 数据链路层
• 物理层

其中应用层 = 应用层+表示层+会话层

应用层（HTPPS/HTTP）

应用层的任务是通过应用进程间的交互来完成特定的网络应用。应用层协议定义的是应用进程(进程:主机中正在运行的程序)间的通信和交互的规则。对于不同的网络应用需要不同的应用层协议。在互联网中引用层协议很多，入域名系统DNS，支持万维网应用的HTTP协议，支持电子邮件的SMTP协议等等。我们把应用层交互的数据单元称为报文。

应用层协议都是为了解决某一类应用问题，而问题的解决又必须通过位于不同主机中的多个应用进程之间的通信和协同工作来完成的。应用进程之间的这种通信必须遵守严格的规则，应用层的具体内容就是精确定义这些通信规则，应用层协议应当定义:

• 应用进程交换的报文类型，如请求报文和响应报文
• 各种报文类型的语法，如报文中的各个字段及其详细描述
• 字段的语义，即包含在字段中的信息的含义。
• 进程何时、如何发送报文，以及对报文进行响应的规则。

运输层（TCP,UDP）

• 运输层为相互通信的应用进程提供逻辑通信。
• 端口和套接字的意义。
• 无连接的UDP的特点。
• 面向连接的TCP的特点。
• 在不可靠的网络上实现可靠传输的工作原理，停止等待协议和ARQ协议。
• TCP的滑动窗口、流量控制、拥塞控制和连接管理。

进程之间的通信

从通信和信息处理的角度看，运输层向上面的应用层提供通信服务，它属于面向通信部分的最高层，同时也是用户功能中的最低层。当网络的边缘部分的两个主机使用网络的核心部分的功能进行端到端的通信时，只有主机的协议栈才有运输层，而网络核心部分中的路由器在转发分组时都只用下三层的功能。

运输层的两个主要协议

• 用户数据报协议UDP UDP在传输数据之前不需要先建立连接。
  远地主机的运输层在收到UDP报文后，不需要给出任何确认。虽然UDP不提供可靠交付，但在某些情况下UDP却是一种最有效的工作方式。
• 传输控制协议TCP 则提供面向连接的服务。
  在传送数据之前必须先建立连接，数据传送借宿后要释放连接.TCP 不提供广播或多播服务。由于TCP要提供可靠的、面向连接的运输服务，因此不可避免的增加了许多的开销。

网络层（IP）

• TCP/IP 体系中的网络层向上只提供简单灵活的，无连接的，尽最大努力交付的数据报服务。网络层不提供服务质量的承诺，不保证分组交付的时限，所传达的分组可能出粗、丢失、重复和失序。进程之间的通信的可靠性由运输层负责。

数据链路层

数据链路层使用的信道主要有下面两种类型:

• 点对点信道
  这种信道使用一对一的点对点通信方式
• 广播信道
  这种信道使用一对多的广播通信方式。

物理层

物理层考虑的是怎样才能在连接各种计算机的传输媒体上传输数据比特流，而不是指具体的传输媒体。物理层的作用是尽可能的屏蔽掉这些传输媒体和通信手段的差异，使物理层上面的数据链路层感觉不到这些差异，这样就可使数据链路层只需要考虑如何完成本层的协议和服务，而不必考虑网络具体的传输媒体和通信手段是什么。
可以将物理层的主要任务描述为确定与传输媒体的接口有关的一些特性，即:

• 机械特性
• 电器特性
• 功能特性
• 过程特性

UDP

• UDP是无连接的 即发送数据之前不需要建立连接，因此减少了开销和发送数据之前的时延。
• UDP使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的连接状态表。
• UDP是面向报文的。
• UDP没有拥塞控制的。
• UDP支持一对一、一对多、多对一和多对多的交互通信。
• UDP的首部开销小。

TCP

TCP特点

• TCP 是面向连接的运输层协议，应用程序在使用TCP协议之前，必须先建立TCP连接。在传送数据完毕后，必须释放已经建立的TCP连接。
• 每一条TCP连接只能有两个端点，每一条TCP连接只能是点对点的
• TCP提供可靠交付的服务，TCP链接传送的数据，无差错、不丢失、不重复、并且按序到达。
• TCP提供全双通信。TCP允许通信双方的应用进程在任何时候都能发送数据。TCP连接的两端都设有发送缓存和接受缓存，用来临时存放双向通信的数据。在发送时，应用程序在把数据传送给TCP的缓存后，就可以做自己的事，而TCP在合适的时候把数据发送出去，在接收时，TCP把收到的数据放入缓存，上层的应用进程在合适的时候读取缓存中的数据。
• 面向字节流。
  流指的是流入到进程或从进程流出的字节序列，
  TCP和UDP在发送报文时所采用的方式完全不同。TCP并不关心应用进程一次把多长的报文发送到TCP的缓存中，而是根据对方给出的窗口值和当前网络拥挤的程度来决定一个报文段应包含多少个字节(UDP发送的报文长度是应用进程给出的)。如果应用进程传送到TCP缓存的数据块太长，TCP就可以把它划分短一些在传送，如果应用进程一次只发来一个字节，TCP也可以等待积累有足够多的字节后在构成报文段发送出去，

可靠传输的工作原理

• 停止等待协议

1. 无差错情况
   A发送分组M1，发完就暂停发送，等待B确认。B收到了M1就向A发送确认。A在收到了对M1的确认后，就在发送下一个分组M2。
   [图片上传失败...(image-3ee932-1534433220881)]
2. 出现差错
   如上图所示。B收到M1时检测出了差错，就丢弃M1，其他什么也不做(不通知A收到有差错的分组)。也可能是M1在传输过程中丢失了，这时B当然不知道。在这两种情况下，B都不会发送任何消息。可靠传输协议就是这样设计的:A只要超过一段时间仍然没有收到确认，就认为刚才发送的分组丢失了，因为重传前面发送过的分组。这就叫做超时重传。要实现超时重传，就要在每发送完一个分组设置一个超时计时器。如果在超时计时期到期之前收到了对方的确认，就撤销已设置的超时计时器。

3. 确认丢失和确认丢失
   B所发送的对M1的确认丢失了。A在设定的超时重传时间内没有收到确认，但并无法知道是自己发送的分组错误、丢失，或者是B发送的去人丢失了。因此A在超时计时器到期后就要重传M1。现在应注意B的动作，假定B又收到了重传的分组M1，这时应采取两个行动。
   第一、丢弃这个重复的分组M1
   第二、向A发送确认，不能认为已经发送过确认就不再发送，因为A之所以重传M1就表示A没有收到对M1的确认。

   
   
   确认丢失和确认迟到.jpg

• 连续ARQ协议

TCP可靠传输的实现

为了讲述可靠传输原理的方便，我们假定数据传输只在一个方向进行，即A发送数据，B给出确认。这样的好处是讨论限于两个窗口，即发送方A的发送窗口和接收方B的接收窗口。

• 以字节为单位的滑动窗口
• 超时重传时间的选择

1. TCP的发送方在规定的时间内没有收到确认就要重传已发送的报文端。重传时间的选择确是TCP最复杂的问题
   TCP采用了一种自适应的算法，它记录了一个报文段发出的时间，以及收到相应的确认的时间。这两个时间只差就是报文段的往返时间RTT。TCP保留了RTT的一个加权平均往返时间RTTS
2. 如何判定此报文段是对先发送的报文段的确认，还是对后来重传的报文段的确认？
   方法:报文段每重传一次，就把超时重传时间RTO增大一些。典型的做法是取新的重传时间为2倍的的旧的重传时间。
   Karn算法能够使运输层区分开有效和无效的往返时间样本，从而改进了往返时间的估测。

• 选择确认SACK
  接收方收到了报文段无差错，只是未按序号，中间还缺少一些序号的数据，那么能否设法只传缺少的数据而不重传已经确认到达接收方的数据？答案是可以的，选择确认就是一种可行的处理方法。

TCP的流量控制

一般说来，我们总是希望数据传输得更快一些。但如果发送发把数据发送的过快，接收方就可能来不及接收，这就会造成数据的丢失。所谓流量控制就是让发送方的发送速率不要太快，要让接收方来得及接收。

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

利用滑动窗口机制可以很方便的在TCP连接上实现对发送方的流量控制。
设A向B发送数据。在建立连接时，B告诉A 我的接收窗口 rwnd = 400 (这里rwnd表示receiver window)。因此，发送方的发送窗口不能超过接收方给出的接收窗口的数值。

必须考虑传输效率###

接收方等待一段时间，使的或者接收缓存已有足够空间容纳一个最长的报文段，或者等待接收缓存已有一半空闲的空间。只要出现这两种情况之一，接收方就发出确认报文，并向发送发通知当前的窗口大小。此外，发送放也不要发送太小的报文段，而是把数据积累成足够大的报文段，或达到接收方缓存的空间的一半大小。上述两种方式可配合使用。使的在发送方不发送很小的报文段的同时，接收方也不要在缓存刚刚有一点小的空间就急忙把这个很小的窗口大小信息通知给发送方。

TCP的拥塞控制

TCP的运输连接管理

1. 连接建立

三次握手.jpg

（SYN 是报文段 seq 是 序号 ACK 是确认号）

2. 为什么要三次握手，两次或者四次。
   为什么A还要发送一次确认呢? 这主要是为了防止已失效的连接请求报文段突然有传送到了B

案例
A发送连接请求，但是没有收到B的确认，于是A再重传一次连接请求。后来收到了确认，建立连接，数据传输完毕后，就释放了连接，A共发送了两个连接请求报文段，其中第一个丢失，第二个到达了B。
现在假定出现一种异常情况，即A发出的第一个连接请求报文段并没有丢失，而是在某网络结点长时间滞留，以致于延误到连接释放以后的某个时间才到达B。本以为这是一个早已失效的报文段，但B收到此失效的链接请求报文段后，就误以为A又发送一次新的链接请求，于是就向A发出确认报文段，同意建立连接。假定不采用三次握手，那么只要B发出确认，新的连接就建立。
由于A并且没有发出建立连接的请求，因此不会理睬B的确认，也不会向B发送数据。但B确认已新的运输连接已经建立了，并一直等待A发来数据。B的许多资源就这样白白浪费了。

3. TCP 链接释放

   
   
   TCP连接释放.jpg

现在A和B都在ESTABLISHED状态。A的应用进程先向其TCP发出连接释放报文段，并停止在发送数据，主动关闭TCP连接。A把连接释放报文段首部的终止控制位FIN置1，其序号seq = u;它等于前面已传送过的数据的最后一个字节序号加1。这时A进入FIN-WAIT-1（终止等待1）状态，等待B的确认。B收到连接释放报文段后即发出确认，确认号是ack = u + 1，而这个报文段自己的序号是v，等于B前面已传送过来的数据的最后一个字节的序号加1。然后B就进入CLOSE-WAIT(关闭等待)状态。TCP服务器进程这时应通知高层应用进程，因而从A到B这个方向的连接就释放了，这时的TCP连接处于半关闭的状态，即A已经没有数据要发送，但B若发送数据，A 仍要接收。也就是说，从B到A这个方向的连接并未关闭，这个状态可能会持续一些时间。
A收到来自B的确认后，就进入FIN-WAIT-2(终止等待2)状态，等待B发出的连接释放报文段。
若B已经没有要向A发送的数据，其应用进程就通知TCP释放链接，这时B发出的连接释放报文段必须使FIN = 1。现假定B的序号（seq）为w（在半关闭状态B可能又发出了一些数据），B还必须重复上次已发送过的确认号 ack = u + 1。这时B就进入LAST-ACK(最后确认)状态，等待A的确认。
A在收到B的连接释放报文段后，必须对此发出确认。在确认报文段中把ACK 置1，确认号 ack = w + 1,而自己的序号 seq = u+1,然后进入到TIME-WAIT（时间等待）状态。请注意，现在TCP还没有释放掉。必须经过时间等待计时器设置的2MSL后，A才进入到CLOSED状态。时间MSL叫做最长报文段寿命，对于现在的网络，MSL = 2 分钟可能太长了一些。因此TCP允许不同的实现可根据具体情况使用最小的MSL值。因此，从A进入到TIME-WAIT状态后，要经过4分钟才能进入到CLOSED状态，才能开始建立下一个新的连接。当A撤销相应的传输控制块TCB后，就结束了这次的TCP连接。
为什么A在TIME-WAIT状态必须等待2MSL的时间呢?这有两个理由。
第一，为了保证A发送的最后一个ACK报文段能够到达B。这个ACK报文段有可能丢失，因而使处在LAST-ACK状态的B收不到对方已发送已发送的FIN+ACK报文段的确认。B会超时重传这个FIN+ACK报文段，而A就能在2MSL时间内收到这个重传的FIN+ACK报文段。接着A重传一次确认，重新启动2MSL（4分钟）时间内收到这个重传的FIN+ACK报文段。接着A重传一次确认，重新启动2MSL计时器。最后，A和B都正常进入到CLOSED状态。如果A在TIME-WAIT状态下不等待一段时间，而是发送完ACK报文段后立即释放连接，那么就无法收到B重传的FIN+ACK报文段，因而也不会在发送一次确认报文段，这样，B就无法按照正常步骤进入CLOSED状态。
第二，A在发送完最后一个ACK报文段后，在经过时间2MSL，就可以使本连接持续的时间内所产生的所有报文段从网络消失，这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。
B只要收到了A发出的确认，就进入CLOSED状态。同样，B在撤销响应的传输控制块TCB后，就结束了这次的TCP连接。我们注意到，B结束TCP连接的时间要比A早一些。