admin管理员组

文章数量:1026989

计算机网络——运输层（来看看，你不会后悔的）

文章目录

• 一、运输层简介
• • 1.复用和分用
  • 2.因特网的运输层协议
• 二、UDP
• • 2.1 用户数据报协议（UDP）
• 三、TCP
• • 3.1 传输控制协议（TCP）简介
  • 3.2 TCP连接管理
  • • 3.2.1 建立连接
    • • 3.2.1.1 连接过程（三次握手）
      • 3.2.1.2 SYN、seq、ACK、ack、FIN
    • 3.2.2 连接释放
  • 3.3 TCP可靠传输
  • • 3.3.1 数据编号与确认
    • 3.3.2 以字节为单位的滑动窗口
    • 3.3.3 超时重传时间的选择
    • 3.3.4 快速重传
    • 3.3.5 选择确认
  • 3.4 流量控制
  • 3.5 拥塞控制
  • • 3.5.1 慢启动和拥塞控制
    • 3.5.2 快重传和快恢复
  • 3.6 流量控制和拥塞控制区别

一、运输层简介

  一句话概括：怎么将消息从一个主机中的进程传输到另一主机中的进程,传输的方式有哪些。

  前面的内容介绍了将主机通过异构网络互联起来，实现主机到主机的通信。从IP层来说，通信的两端是两个主机。

IP数据报的首部明确地标志了这两个主机的IP地址，IP协议虽然能把分组送到目的主机，但是这个分组还停留在主机的网络层而没有交付给主机中的应用进程。但实际上在计算机网络中进行通信的真正实体是通信两端主机中的进程。

进程就是正在运行的程序（QQ、微信、迅雷等等都是程序）。

传输层负责的就是主机中两个进程的通信，即端到端的通信。每个进程都会用一个编号来标识，这个编号就是端口号，所以叫做端到端通信。

  就比如说，当我用微信（微信就是主机中的一个应用进程）与富婆聊天，我这端的微信和富婆那边的微信才是真正的通信主体。进行通信时，如果消息只是停留在富婆那边的主机的网络层，还没有送往微信这个进程，通信就没有完成，需要将消息传到富婆的微信才能算完成。

1.复用和分用

  在两端的主机正在通信的进程是很多的,比如说我在QQ聊了一个A富婆,在微信聊了一个B富婆，在探探聊了一个C富婆。
、

当他们同时给我发信息时，或者说我给这三个富婆发信息。我的计算机怎么知道哪个富婆对应的是哪个应用软件的呢？也就是说当我给A富婆发了一句“明天去吃饭么”，为什么不会发到探探的C富婆那里呢？

  这就是传输层的一个重要的功能——复用和分用。“复用”是指在发送方不同的应用进程都可以使用同一个运输层协议传输数据（当然需要加上适当的首部）。

“分用”是指接收方的运输层在剥去报文的首部后能够把这些数据正确交付到目的应用程序。


  其实这里用快递的例子更加合适，运快递可以多个快递放在同一辆大卡车里面，但是能够准确地送到每个用户的手里。

2.因特网的运输层协议

  我们知道通信的真正主体是计算机中的进程，计算机中有多种应用程序。比如说电子邮件、文件传输、万维网、电子银行等等，这类应用如果数据丢失就会造成灾难性的后果。

  但是因特网的网络层为主机之间提供的是一种尽最大努力交付的数据报服务，IP报文在传送过程中有可能会丢失、出错或者失序。

  但对于实时的多媒体应用，如实时音频/视频，它们能承受一定程度的数据丢失。丢失少量的数据会对播放的质量产生一些小的影响，但不会造成致命的损伤。

  所以运输层协议要增加一些机制来满足不同的需求，因特（更一般来说是TCP/IP网络）为上层应用提供了两个不同的运输层协议，即：
   （1）用户数据报协议（User Datagram Protocol，UDP）
   （2）传输控制协议（Transmission Control ProtocolTCP）

二、UDP

2.1 用户数据报协议（UDP）

  用户数据报协议UDP只在IP数据报服务之上增加了有限的功能，这就是;端口的功能（有了端口，运输层就能进行复用和分用）和差错检测的功能。

  虽然UDP用户数据报只能提供不可靠的交付，但它在某些方面有其特殊的优点。

  （1）UDP是无连接的，即发送数据之前不需要建立连接，减少了开销和发送数据之前的时延。

  （2）UDP使用尽最大努力交付，即不保证可靠交付，同时也不使用流量控制和拥塞控制。


  （3）由于UDP没有拥塞控制，因此网络出现的拥塞不会使源主机的发送速率降低。

这对某些实时应用是很重要的。很多的实时应用(如IP电话、实时视频会议等)要求源主机以恒定的速率发送数据，并且允许在网络发生拥塞时丢失些数据， 但却不允许数据有太大的时延。UDP正好适合这种要求。

  (4)UDP是面向报文的。这就是说，UDP对应用程序交下来的报文不再划分为若千个分组来发送，也不把收到的若干个报文合并后再交付给应用程序。（一口闷，不切块）

应用程序交给UDP 一个报文，UDP就发送这个报文;而UDP收到一个报文，就把它交付给应用程序。因此，应用程序必须选择合适大小的报文。若报文太长，UDP把它交给IP层后，IP层在传送时可能要进行分片，这会降低IP层的效率。反之，若报文太短，UDP把它交给IP层后，会使IP数据报的首部相对太大，这也降低了IP层的效率。

  (5)UDP支持一对一、一对多、多对一和多对多的交互通信。

  (6)用户数据报只有8个字节的首部开销，比TCP的20个字节的首部要短得多。

三、TCP

3.1 传输控制协议（TCP）简介

  TCP是TCP/IP体系中面向连接的运输协议，它提供全双工的可靠交付的服务。TCP和UDP最大的区别就是：TCP是面向连接的，而UDP是无连接。

  TCP除了具有面向连接、面向字节流以及可靠传输的特性外，还使用了流量控制和拥塞控制机制。

3.2 TCP连接管理

  TCP是面向连接的，那么过程是怎么样的。TCP连接传输的三个阶段：
  连接建立——>数据传送——>连接释放

  这个过程就像是打电话，先拨号给女神接通了，就开始聊骚，最后聊完了就挂电话。

  其实TCP连接的建立采用的是客户服务方式，主动发起连接建立的应用进程叫做客户，而被动等待连接建立的应用进程叫服务器。

3.2.1 建立连接

3.2.1.1 连接过程（三次握手）

  假设运行在一台主机（客户)上的一个进程想与另一台主机（服务器）上的一个进程建立一条连接，客户应用进程首先通知客户TCP，他想建立一个与服务器上某个进程之间的连接，客户中的TCP会用以下步骤与服务器中的TCP建立一条TCP连接:

  其实这个过程可以用一句话来概括“窈窕淑女君子好逑”，这就是一个求爱的过程。客户端就是男的，服务端就是窈窕淑女。

ROUND 1:
客户端发送连接请求报文段，无应用层数据。
SYN=1，seq=x(随机)

  男的看见了一个很漂亮的女生，就起了色心，然后就想和女生建立联系。他就向女生求爱：“我希望以后的生活能够与有你相伴，我们携手共进，共同进步（简称同步SYN），现在我还是单身一个人（单身就相当于1）”——这就相当于客户端发送连接请求 SYN=1 。求爱还应该带点礼物吧，玫瑰花啥的带一点吧——这相当于选择了一个序号 seq=x 的报文段。

ROUND 2:
服务器端为该TCP连接分配缓存和变量，并向客户端返回确认报文段，允许连接，无应用层数据。
SYN=1，ACK=1，seq=y(随机) ，ack=x+1

  女生收到了请求，就回应：“哎呀好巧呀，我也是单身那咱们在一起吧（SYN=1），我已经收到了你给我的礼物了（ ACK=1 ，ack=x+1）”。中国人讲究有来有往，为了表示心意，所以女方就回礼（seq=y）

ROUND 3:
客户端为该TCP连接分配缓存和变量，并向服务器端返回确认的确认，可以携带数据。
ACK=1，seq=x+1，ack=y+1

  男生收到了女方的回复以及礼物，兴奋不已，就回复了女生：“我收到你的礼物了（ACK=1，ack=y+1）”。男生想了想，不能亏待了女生，就又送了一件礼物（seq=x+1）。他们就正式建立了起了关系

ROUND 4:
客户端和服务端就开始通信。
  建立了关系，男生和女生就互相来往了。

3.2.1.2 SYN、seq、ACK、ack、FIN

  因为连接过程涉及SYN、seq、ACK、ack、FIN，所以TCP的报文段放在这里，以便介绍SYN、seq、ACK、ack、FIN是什么。

  （1）确认ACK：ACK (Acknowledge character）即是确认字符，表示发来的数据已确认接收无误。

在TCP/IP协议中，如果接收方成功的接收到数据，那么会回复一个ACK数据。只有当ACK=1时确认号字段才有效；当ACK=0，确认号无效。

  （2）SYN：同步序列编号（Synchronize Sequence Numbers）。是TCP/IP建立连接时使用的握手信号，用来建立一个连接。

当 SYN=1 而 ACK=0 时，表明这是连接请求报文段。对方若同意建立连接，则应在响应报文段中使 SYN=1 和 ACK=1 。因此，SYN=1 就表示这是一个连接请求或接受连接报文。

  （3）seq：发送的TCP报文的序号

  （4）ack：确认号，ack表示的是确认收到对方发过来的报文段，并且要在对方的seq值+1。也就是要在收到的数据的最高序号加1。
还有一种解释 ack确认号表示接收方期望下次收到的数据中的第一个数据字节序号。

比如说：
客户端：SYN=1，seq=x

服务端：SYN=1，ACK=1，ack=x+1（表示收到了客户端发过来的序号为x的报文段，并且要 +1，注意：想要ack是有效的，就要将 ACK=1 写上 ，这是证明，同队出现）

  （5）FIN：FINal，用来释放连接。当 FIN=1 时，表明此报文段的发送方的数据已发送完毕，并要求释放运输连接。

3.2.2 连接释放

  参与一条TCP连接的两个进程中的任何一个都能终止该连接，连接结束后，主机中的“资源”(缓存和变量）将被释放。

  释放连接就是一个分手的过程。

ROUND 1:
客户端发送连接释放报文段，停止发送数据，主动关闭TCP连接。
FIN=1，seq=u
  在一起一段时间后，深入交流后，男生还是提出了分手（fen和FIN有点像吧，哈哈哈哈），“我觉得我们不合适，咱们分手吧，我还是习惯一个人（1——FIN=1）。这是你送给我的礼物，退还给你（seq=u）”

ROUND 2:
服务器端回送一个确认报文段，客户到服务器这个方向的连接就释放了――半关闭状态。
ACK=1，seq=v，ack=u+1
  女生收到了分手信息，犹如晴天霹雳。迷迷糊糊地回复了：“我知道了（ACK=1，ack=u+1），收到了你退回的礼物了。”

分手退礼物，简直杀人诛心。女生一气之下也把男生送的礼物退回了。（seq=v）

ROUND 3:
服务器端发完数据，就发出连接释放报文段，主动关闭TCP连接。
FIN=1，ACK=1，seq=w，ack=u+1
  女生的情绪稳定下来了，正式回应了分手：“分手一开始我以为是开玩笑的，没想到你把礼物也退回了，我收到了，我才确认这是真的（ACK=1，ack=u+1），那我们分手吧（FIN=1）。那你把我的衣服也退回来了吧，我把你的所有东西都退回去了（seq=w），分手就分得彻底一些。”

ROUND 4:
客户端回送一个确认报文段，再等到时间等待计时器设置的2MSL（最长报文段寿命）后、连接彻底关闭。
  男生回复：“好的，我知道了”。（ACK=1,ack=w+1）我也把你所有的东西都退回去了（seq=u+1）。”两人断了联系，成为了陌生人。

3.3 TCP可靠传输

  当客户端和服务端建立了连接之后，就可以进行数据的传输了。TCP在IP层提供的不可靠的尽最大努力服务的基础上实现了一种可靠的数据传输服务，保证数据无差错、无丢失、按序和无重复的交付。下面就来介绍一下可靠传输。

  可靠传输：保证接收方进程从缓存区读出的字节流与发送方发出的字节流是完全一样的。也就是我发送什么（1234），你就能接收到什么（1234）。

  那怎么实现可靠传输，采用这5个机制：
      （1）数据编号与确认
      （2）以字节为单位的滑动窗口
      （3）超时重传时间的选择
      （4）快速重传
      （5）选择确认

3.3.1 数据编号与确认

  TCP协议是面向字节的，TCP把应用层交下来的长报文（这可能要划分为多个比较短的报文段）看成是一个个字节组成数据流，并给每一个字节编号。

  在连接建立时，双方TCP要各自确定初始序号。TCP每次发送的报文段的首部中的序号字段数值表示该报文段紧接着首部的第一个数据字节的序号。

  TCP使用的是累积确认,即确认是对所有按序收到的数据的确认。但要注意，接接收方返回的确认号是已按序收到的数据的最高序号加 1 。
也就是说确认号表示接收方期望下次收到的数据中的第一个数据字节序号。例如，已经收到了 1-700 号、801-1000 号和 1201-1500 号，而 701-800号的数据还没有收到，那么这次发送的确认序号（ack）应该填入 701 也就是ack=701。

  所以要对数据进行编号，能查出那些数据没有到。

3.3.2 以字节为单位的滑动窗口

  为了提高报文段的传输速率，TCP采用滑动窗口协议，发送窗口大小的单位是字节。TCP发送方已发送的未被确认的字节数不能超过发送窗口的大小。

3.3.3 超时重传时间的选择

  TCP的发送方在规定的时间内没有收到确认就要重传已发送的报文段。重传的概念很简单，但如何选择重传的时间是很复杂的。现在不展开写了，TCP采用自适应的算法，动态改变重传时间RTTS（加权平均往返时间）。

3.3.4 快速重传

  当一个报文段丢失时，发送方需要等待很长的时间才能重传丢失的报文段，因而增加了端到端时延。

幸运的是，有时一个报文段的丢失会引发发送方连续收到多个确认，通过收到多个重复的确认可以快速地判断报文段有可能已经丢失而不必等待重传计时器超时。

3.3.5 选择确认

  根据前面的讨论，我们知道TCP报文段的确认字段是一种累积确认， 就是说， 它只通告收到的最后一个按序到达的字节，而没有通告所有收到的失序到达的那些字节，虽然这些字节已经被接收方接收并暂存在接收缓存中。

  但这些没有被确认的字节很可能因为超时而被发送方重传。为避免这些无意义的重传，一个可选的功能选择 确认( Seletive ACK, SACK ) 可以用来解决这个问题。

  选择确认允许接收方通知发送方所有正确接收了的但是失序的字节块，发送方可以根据这些信息只重传那些没有收到的字节块。

3.4 流量控制

  流量控制就是让发送方慢点，让接收方来得及接收。在通信过

程中，接收方根据自己接收缓存的大小，动态地调整发送方的发送窗口大小，

即接收窗口rwnd(receiver window 接收方设置确认报文段的窗口字段来将rwnd通知给发送方），

发送方的发送窗口取接收窗口rwnd和拥塞窗口cwnd的最小值。

3.5 拥塞控制

  当网络中出现太多的分组时，网络的性能开始下降。这种情况称为拥塞( Congestion)。

  拥塞是分组交换网中一个非常重要的问题。如果网络中的负载( Load )，即发送到网络中的数据量超过了网络的容量，即网络中能处理的数据量，那么在网络中就可能发生拥塞。

  所谓拥塞控制( Congestion Control)就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。

  拥塞控制的四种算法：（慢开始、拥塞避免）、（快重传、快恢复）。

  TCP的流量控制利用接收方通必发送方的接收窗口rwnd (Receiver Window)大小来限制发送窗口的大小。
这个窗口大小就是接方发给发送方的TCP报文段首部中的窗口字段的值。

  实际上TCP的发送方还维持一个叫作拥塞 窗口cwnd（Congestion Window )的状态变量。
拥塞窗口的大小取决于网络的拥塞程度，并且是动态变化的。

  TCP发送方在确定发送报文段的速率时，既要根据接收方的接收能力，又要从全局考虑不要使网络发生塞。因此TCP发送方的发送窗口大小取接收方接收窗口和拥塞窗口的最小值，即应按以下公式确定:

发送窗口的上限值= Min ( rwnd, cwnd )

  上式告诉我们:当rwnd < cwnd时，是接收方的接收能力限制发送窗口的最大值。但当cwnd< rwnd时，则是网络的传输能力限制发送窗口的最大值。

3.5.1 慢启动和拥塞控制

  慢启动就是由小到大逐渐增大发送方的拥塞窗口数值，直到发生拥塞。

  为了防止cwnd增加过快而导致网络拥塞，所以需要设置一个慢开始门限ssthresh状态变量（我也不知道这个到底是什么，就认为他是一个拥塞控制的标识）,它的用法：

当cwnd < ssthresh,使用慢启动算法，
当cwnd > ssthresh,使用拥塞控制算法，停用慢启动算法。
当cwnd = ssthresh，这两个算法都可以。
拥塞避免的思路：是让cwnd缓慢的增加而不是加倍的增长，每经历过一次往返时间就使cwnd增加1，而不是加倍，这样使cwnd缓慢的增长，比慢启动要慢的多。

无论是慢启动算法还是拥塞避免算法，只要判断网络出现拥塞，就要把慢启动开始门限(ssthresh)设置为设置为发送窗口的一半（>=2），cwnd(拥塞窗口)设置为1，然后在使用慢启动算法，这样做的目的能迅速的减少主机向网络中传输数据，使发生拥塞的路由器能够把队列中堆积的分组处理完毕。拥塞窗口是按照线性的规律增长，比慢启动算法拥塞窗口增长块的多。

实例：
1.TCP连接进行初始化的时候，cwnd=1,ssthresh=16。
2.在慢启动算法开始时，cwnd的初始值是1，每次发送方收到一个ACK拥塞窗口就增加1，当ssthresh =cwnd时，就启动拥塞控制算法，拥塞窗口按照规律增长，
3.当cwnd=24时，网络出现超时，发送方收不到确认ACK，此时设置ssthresh=12,(二分之一cwnd),设置cwnd=1,然后开始慢启动算法，当cwnd=ssthresh=12,慢启动算法变为拥塞控制算法，cwnd按照线性的速度进行增长。

3.5.2 快重传和快恢复

步骤如下：

(1)当发送方收到连续三个重复的ACK时，就重新设置慢启动门限stresh,将其设置为当前发送窗口的一半。这一点和慢启动算法是一样的。

(2 )与慢启动不同之处是拥塞窗口cwnd不是设置为1,而是设置为新设置的慢启动门限ssthresh，然后开始执行拥寒避免算法，使拥塞窗口缓慢地线性增长。

3.6 流量控制和拥塞控制区别

  拥塞控制的任务是确保子网能够承载所到达的流量。这是一个全局性问题，涉及到各方面的行为，包括所有的主机、所有的路由器、路由器内部的存储转发处理过程，以及所有可能会削弱子网承载容量的其它因素。

  与此相反，流量控制只与特定的发送方和特定的接收方之间的点到点流量有关。它的 任务是，确保一个快速的发送方不会持续地以超过接收方吸收能力的速率传输数据。流控制通常涉及到的做法是，接收方向发送方提供某种直接的反馈，以便告诉发送方别人一端的情形到底怎么样。

  一个是容量问题，一个是速率问题。容量问题会导致发送方的数据迟迟未到接收方（车太多导致堵车，迟迟不能到达目的地）。速率问题导致，接收方来不及接收（太快了，接不住）

计算机网络——运输层（来看看，你不会后悔的）

文章目录

• 一、运输层简介
• • 1.复用和分用
  • 2.因特网的运输层协议
• 二、UDP
• • 2.1 用户数据报协议（UDP）
• 三、TCP
• • 3.1 传输控制协议（TCP）简介
  • 3.2 TCP连接管理
  • • 3.2.1 建立连接
    • • 3.2.1.1 连接过程（三次握手）
      • 3.2.1.2 SYN、seq、ACK、ack、FIN
    • 3.2.2 连接释放
  • 3.3 TCP可靠传输
  • • 3.3.1 数据编号与确认
    • 3.3.2 以字节为单位的滑动窗口
    • 3.3.3 超时重传时间的选择
    • 3.3.4 快速重传
    • 3.3.5 选择确认
  • 3.4 流量控制
  • 3.5 拥塞控制
  • • 3.5.1 慢启动和拥塞控制
    • 3.5.2 快重传和快恢复
  • 3.6 流量控制和拥塞控制区别

一、运输层简介

  一句话概括：怎么将消息从一个主机中的进程传输到另一主机中的进程,传输的方式有哪些。

  前面的内容介绍了将主机通过异构网络互联起来，实现主机到主机的通信。从IP层来说，通信的两端是两个主机。

IP数据报的首部明确地标志了这两个主机的IP地址，IP协议虽然能把分组送到目的主机，但是这个分组还停留在主机的网络层而没有交付给主机中的应用进程。但实际上在计算机网络中进行通信的真正实体是通信两端主机中的进程。

进程就是正在运行的程序（QQ、微信、迅雷等等都是程序）。

传输层负责的就是主机中两个进程的通信，即端到端的通信。每个进程都会用一个编号来标识，这个编号就是端口号，所以叫做端到端通信。

  就比如说，当我用微信（微信就是主机中的一个应用进程）与富婆聊天，我这端的微信和富婆那边的微信才是真正的通信主体。进行通信时，如果消息只是停留在富婆那边的主机的网络层，还没有送往微信这个进程，通信就没有完成，需要将消息传到富婆的微信才能算完成。

1.复用和分用

  在两端的主机正在通信的进程是很多的,比如说我在QQ聊了一个A富婆,在微信聊了一个B富婆，在探探聊了一个C富婆。
、

当他们同时给我发信息时，或者说我给这三个富婆发信息。我的计算机怎么知道哪个富婆对应的是哪个应用软件的呢？也就是说当我给A富婆发了一句“明天去吃饭么”，为什么不会发到探探的C富婆那里呢？

  这就是传输层的一个重要的功能——复用和分用。“复用”是指在发送方不同的应用进程都可以使用同一个运输层协议传输数据（当然需要加上适当的首部）。

“分用”是指接收方的运输层在剥去报文的首部后能够把这些数据正确交付到目的应用程序。


  其实这里用快递的例子更加合适，运快递可以多个快递放在同一辆大卡车里面，但是能够准确地送到每个用户的手里。

2.因特网的运输层协议

  我们知道通信的真正主体是计算机中的进程，计算机中有多种应用程序。比如说电子邮件、文件传输、万维网、电子银行等等，这类应用如果数据丢失就会造成灾难性的后果。

  但是因特网的网络层为主机之间提供的是一种尽最大努力交付的数据报服务，IP报文在传送过程中有可能会丢失、出错或者失序。

  但对于实时的多媒体应用，如实时音频/视频，它们能承受一定程度的数据丢失。丢失少量的数据会对播放的质量产生一些小的影响，但不会造成致命的损伤。

  所以运输层协议要增加一些机制来满足不同的需求，因特（更一般来说是TCP/IP网络）为上层应用提供了两个不同的运输层协议，即：
   （1）用户数据报协议（User Datagram Protocol，UDP）
   （2）传输控制协议（Transmission Control ProtocolTCP）

二、UDP

2.1 用户数据报协议（UDP）

  用户数据报协议UDP只在IP数据报服务之上增加了有限的功能，这就是;端口的功能（有了端口，运输层就能进行复用和分用）和差错检测的功能。

  虽然UDP用户数据报只能提供不可靠的交付，但它在某些方面有其特殊的优点。

  （1）UDP是无连接的，即发送数据之前不需要建立连接，减少了开销和发送数据之前的时延。

  （2）UDP使用尽最大努力交付，即不保证可靠交付，同时也不使用流量控制和拥塞控制。


  （3）由于UDP没有拥塞控制，因此网络出现的拥塞不会使源主机的发送速率降低。

这对某些实时应用是很重要的。很多的实时应用(如IP电话、实时视频会议等)要求源主机以恒定的速率发送数据，并且允许在网络发生拥塞时丢失些数据， 但却不允许数据有太大的时延。UDP正好适合这种要求。

  (4)UDP是面向报文的。这就是说，UDP对应用程序交下来的报文不再划分为若千个分组来发送，也不把收到的若干个报文合并后再交付给应用程序。（一口闷，不切块）

应用程序交给UDP 一个报文，UDP就发送这个报文;而UDP收到一个报文，就把它交付给应用程序。因此，应用程序必须选择合适大小的报文。若报文太长，UDP把它交给IP层后，IP层在传送时可能要进行分片，这会降低IP层的效率。反之，若报文太短，UDP把它交给IP层后，会使IP数据报的首部相对太大，这也降低了IP层的效率。

  (5)UDP支持一对一、一对多、多对一和多对多的交互通信。

  (6)用户数据报只有8个字节的首部开销，比TCP的20个字节的首部要短得多。

三、TCP

3.1 传输控制协议（TCP）简介

  TCP是TCP/IP体系中面向连接的运输协议，它提供全双工的可靠交付的服务。TCP和UDP最大的区别就是：TCP是面向连接的，而UDP是无连接。

  TCP除了具有面向连接、面向字节流以及可靠传输的特性外，还使用了流量控制和拥塞控制机制。

3.2 TCP连接管理

  TCP是面向连接的，那么过程是怎么样的。TCP连接传输的三个阶段：
  连接建立——>数据传送——>连接释放

  这个过程就像是打电话，先拨号给女神接通了，就开始聊骚，最后聊完了就挂电话。

  其实TCP连接的建立采用的是客户服务方式，主动发起连接建立的应用进程叫做客户，而被动等待连接建立的应用进程叫服务器。

3.2.1 建立连接

3.2.1.1 连接过程（三次握手）

  假设运行在一台主机（客户)上的一个进程想与另一台主机（服务器）上的一个进程建立一条连接，客户应用进程首先通知客户TCP，他想建立一个与服务器上某个进程之间的连接，客户中的TCP会用以下步骤与服务器中的TCP建立一条TCP连接:

  其实这个过程可以用一句话来概括“窈窕淑女君子好逑”，这就是一个求爱的过程。客户端就是男的，服务端就是窈窕淑女。

ROUND 1:
客户端发送连接请求报文段，无应用层数据。
SYN=1，seq=x(随机)

  男的看见了一个很漂亮的女生，就起了色心，然后就想和女生建立联系。他就向女生求爱：“我希望以后的生活能够与有你相伴，我们携手共进，共同进步（简称同步SYN），现在我还是单身一个人（单身就相当于1）”——这就相当于客户端发送连接请求 SYN=1 。求爱还应该带点礼物吧，玫瑰花啥的带一点吧——这相当于选择了一个序号 seq=x 的报文段。

ROUND 2:
服务器端为该TCP连接分配缓存和变量，并向客户端返回确认报文段，允许连接，无应用层数据。
SYN=1，ACK=1，seq=y(随机) ，ack=x+1

  女生收到了请求，就回应：“哎呀好巧呀，我也是单身那咱们在一起吧（SYN=1），我已经收到了你给我的礼物了（ ACK=1 ，ack=x+1）”。中国人讲究有来有往，为了表示心意，所以女方就回礼（seq=y）

ROUND 3:
客户端为该TCP连接分配缓存和变量，并向服务器端返回确认的确认，可以携带数据。
ACK=1，seq=x+1，ack=y+1

  男生收到了女方的回复以及礼物，兴奋不已，就回复了女生：“我收到你的礼物了（ACK=1，ack=y+1）”。男生想了想，不能亏待了女生，就又送了一件礼物（seq=x+1）。他们就正式建立了起了关系

ROUND 4:
客户端和服务端就开始通信。
  建立了关系，男生和女生就互相来往了。

3.2.1.2 SYN、seq、ACK、ack、FIN

  因为连接过程涉及SYN、seq、ACK、ack、FIN，所以TCP的报文段放在这里，以便介绍SYN、seq、ACK、ack、FIN是什么。

  （1）确认ACK：ACK (Acknowledge character）即是确认字符，表示发来的数据已确认接收无误。

在TCP/IP协议中，如果接收方成功的接收到数据，那么会回复一个ACK数据。只有当ACK=1时确认号字段才有效；当ACK=0，确认号无效。

  （2）SYN：同步序列编号（Synchronize Sequence Numbers）。是TCP/IP建立连接时使用的握手信号，用来建立一个连接。

当 SYN=1 而 ACK=0 时，表明这是连接请求报文段。对方若同意建立连接，则应在响应报文段中使 SYN=1 和 ACK=1 。因此，SYN=1 就表示这是一个连接请求或接受连接报文。

  （3）seq：发送的TCP报文的序号

  （4）ack：确认号，ack表示的是确认收到对方发过来的报文段，并且要在对方的seq值+1。也就是要在收到的数据的最高序号加1。
还有一种解释 ack确认号表示接收方期望下次收到的数据中的第一个数据字节序号。

比如说：
客户端：SYN=1，seq=x

服务端：SYN=1，ACK=1，ack=x+1（表示收到了客户端发过来的序号为x的报文段，并且要 +1，注意：想要ack是有效的，就要将 ACK=1 写上 ，这是证明，同队出现）

  （5）FIN：FINal，用来释放连接。当 FIN=1 时，表明此报文段的发送方的数据已发送完毕，并要求释放运输连接。

3.2.2 连接释放

  参与一条TCP连接的两个进程中的任何一个都能终止该连接，连接结束后，主机中的“资源”(缓存和变量）将被释放。

  释放连接就是一个分手的过程。

ROUND 1:
客户端发送连接释放报文段，停止发送数据，主动关闭TCP连接。
FIN=1，seq=u
  在一起一段时间后，深入交流后，男生还是提出了分手（fen和FIN有点像吧，哈哈哈哈），“我觉得我们不合适，咱们分手吧，我还是习惯一个人（1——FIN=1）。这是你送给我的礼物，退还给你（seq=u）”

ROUND 2:
服务器端回送一个确认报文段，客户到服务器这个方向的连接就释放了――半关闭状态。
ACK=1，seq=v，ack=u+1
  女生收到了分手信息，犹如晴天霹雳。迷迷糊糊地回复了：“我知道了（ACK=1，ack=u+1），收到了你退回的礼物了。”

分手退礼物，简直杀人诛心。女生一气之下也把男生送的礼物退回了。（seq=v）

ROUND 3:
服务器端发完数据，就发出连接释放报文段，主动关闭TCP连接。
FIN=1，ACK=1，seq=w，ack=u+1
  女生的情绪稳定下来了，正式回应了分手：“分手一开始我以为是开玩笑的，没想到你把礼物也退回了，我收到了，我才确认这是真的（ACK=1，ack=u+1），那我们分手吧（FIN=1）。那你把我的衣服也退回来了吧，我把你的所有东西都退回去了（seq=w），分手就分得彻底一些。”

ROUND 4:
客户端回送一个确认报文段，再等到时间等待计时器设置的2MSL（最长报文段寿命）后、连接彻底关闭。
  男生回复：“好的，我知道了”。（ACK=1,ack=w+1）我也把你所有的东西都退回去了（seq=u+1）。”两人断了联系，成为了陌生人。

3.3 TCP可靠传输

  当客户端和服务端建立了连接之后，就可以进行数据的传输了。TCP在IP层提供的不可靠的尽最大努力服务的基础上实现了一种可靠的数据传输服务，保证数据无差错、无丢失、按序和无重复的交付。下面就来介绍一下可靠传输。

  可靠传输：保证接收方进程从缓存区读出的字节流与发送方发出的字节流是完全一样的。也就是我发送什么（1234），你就能接收到什么（1234）。

  那怎么实现可靠传输，采用这5个机制：
      （1）数据编号与确认
      （2）以字节为单位的滑动窗口
      （3）超时重传时间的选择
      （4）快速重传
      （5）选择确认

3.3.1 数据编号与确认

  TCP协议是面向字节的，TCP把应用层交下来的长报文（这可能要划分为多个比较短的报文段）看成是一个个字节组成数据流，并给每一个字节编号。

  在连接建立时，双方TCP要各自确定初始序号。TCP每次发送的报文段的首部中的序号字段数值表示该报文段紧接着首部的第一个数据字节的序号。

  TCP使用的是累积确认,即确认是对所有按序收到的数据的确认。但要注意，接接收方返回的确认号是已按序收到的数据的最高序号加 1 。
也就是说确认号表示接收方期望下次收到的数据中的第一个数据字节序号。例如，已经收到了 1-700 号、801-1000 号和 1201-1500 号，而 701-800号的数据还没有收到，那么这次发送的确认序号（ack）应该填入 701 也就是ack=701。

  所以要对数据进行编号，能查出那些数据没有到。

3.3.2 以字节为单位的滑动窗口

  为了提高报文段的传输速率，TCP采用滑动窗口协议，发送窗口大小的单位是字节。TCP发送方已发送的未被确认的字节数不能超过发送窗口的大小。

3.3.3 超时重传时间的选择

  TCP的发送方在规定的时间内没有收到确认就要重传已发送的报文段。重传的概念很简单，但如何选择重传的时间是很复杂的。现在不展开写了，TCP采用自适应的算法，动态改变重传时间RTTS（加权平均往返时间）。

3.3.4 快速重传

  当一个报文段丢失时，发送方需要等待很长的时间才能重传丢失的报文段，因而增加了端到端时延。

幸运的是，有时一个报文段的丢失会引发发送方连续收到多个确认，通过收到多个重复的确认可以快速地判断报文段有可能已经丢失而不必等待重传计时器超时。

3.3.5 选择确认

  根据前面的讨论，我们知道TCP报文段的确认字段是一种累积确认， 就是说， 它只通告收到的最后一个按序到达的字节，而没有通告所有收到的失序到达的那些字节，虽然这些字节已经被接收方接收并暂存在接收缓存中。

  但这些没有被确认的字节很可能因为超时而被发送方重传。为避免这些无意义的重传，一个可选的功能选择 确认( Seletive ACK, SACK ) 可以用来解决这个问题。

  选择确认允许接收方通知发送方所有正确接收了的但是失序的字节块，发送方可以根据这些信息只重传那些没有收到的字节块。

3.4 流量控制

  流量控制就是让发送方慢点，让接收方来得及接收。在通信过

程中，接收方根据自己接收缓存的大小，动态地调整发送方的发送窗口大小，

即接收窗口rwnd(receiver window 接收方设置确认报文段的窗口字段来将rwnd通知给发送方），

发送方的发送窗口取接收窗口rwnd和拥塞窗口cwnd的最小值。

3.5 拥塞控制

  当网络中出现太多的分组时，网络的性能开始下降。这种情况称为拥塞( Congestion)。

  拥塞是分组交换网中一个非常重要的问题。如果网络中的负载( Load )，即发送到网络中的数据量超过了网络的容量，即网络中能处理的数据量，那么在网络中就可能发生拥塞。

  所谓拥塞控制( Congestion Control)就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。

  拥塞控制的四种算法：（慢开始、拥塞避免）、（快重传、快恢复）。

  TCP的流量控制利用接收方通必发送方的接收窗口rwnd (Receiver Window)大小来限制发送窗口的大小。
这个窗口大小就是接方发给发送方的TCP报文段首部中的窗口字段的值。

  实际上TCP的发送方还维持一个叫作拥塞 窗口cwnd（Congestion Window )的状态变量。
拥塞窗口的大小取决于网络的拥塞程度，并且是动态变化的。

  TCP发送方在确定发送报文段的速率时，既要根据接收方的接收能力，又要从全局考虑不要使网络发生塞。因此TCP发送方的发送窗口大小取接收方接收窗口和拥塞窗口的最小值，即应按以下公式确定:

发送窗口的上限值= Min ( rwnd, cwnd )

  上式告诉我们:当rwnd < cwnd时，是接收方的接收能力限制发送窗口的最大值。但当cwnd< rwnd时，则是网络的传输能力限制发送窗口的最大值。

3.5.1 慢启动和拥塞控制

  慢启动就是由小到大逐渐增大发送方的拥塞窗口数值，直到发生拥塞。

  为了防止cwnd增加过快而导致网络拥塞，所以需要设置一个慢开始门限ssthresh状态变量（我也不知道这个到底是什么，就认为他是一个拥塞控制的标识）,它的用法：

当cwnd < ssthresh,使用慢启动算法，
当cwnd > ssthresh,使用拥塞控制算法，停用慢启动算法。
当cwnd = ssthresh，这两个算法都可以。
拥塞避免的思路：是让cwnd缓慢的增加而不是加倍的增长，每经历过一次往返时间就使cwnd增加1，而不是加倍，这样使cwnd缓慢的增长，比慢启动要慢的多。

无论是慢启动算法还是拥塞避免算法，只要判断网络出现拥塞，就要把慢启动开始门限(ssthresh)设置为设置为发送窗口的一半（>=2），cwnd(拥塞窗口)设置为1，然后在使用慢启动算法，这样做的目的能迅速的减少主机向网络中传输数据，使发生拥塞的路由器能够把队列中堆积的分组处理完毕。拥塞窗口是按照线性的规律增长，比慢启动算法拥塞窗口增长块的多。

实例：
1.TCP连接进行初始化的时候，cwnd=1,ssthresh=16。
2.在慢启动算法开始时，cwnd的初始值是1，每次发送方收到一个ACK拥塞窗口就增加1，当ssthresh =cwnd时，就启动拥塞控制算法，拥塞窗口按照规律增长，
3.当cwnd=24时，网络出现超时，发送方收不到确认ACK，此时设置ssthresh=12,(二分之一cwnd),设置cwnd=1,然后开始慢启动算法，当cwnd=ssthresh=12,慢启动算法变为拥塞控制算法，cwnd按照线性的速度进行增长。

3.5.2 快重传和快恢复

步骤如下：

(1)当发送方收到连续三个重复的ACK时，就重新设置慢启动门限stresh,将其设置为当前发送窗口的一半。这一点和慢启动算法是一样的。

(2 )与慢启动不同之处是拥塞窗口cwnd不是设置为1,而是设置为新设置的慢启动门限ssthresh，然后开始执行拥寒避免算法，使拥塞窗口缓慢地线性增长。

3.6 流量控制和拥塞控制区别

  拥塞控制的任务是确保子网能够承载所到达的流量。这是一个全局性问题，涉及到各方面的行为，包括所有的主机、所有的路由器、路由器内部的存储转发处理过程，以及所有可能会削弱子网承载容量的其它因素。

  与此相反，流量控制只与特定的发送方和特定的接收方之间的点到点流量有关。它的 任务是，确保一个快速的发送方不会持续地以超过接收方吸收能力的速率传输数据。流控制通常涉及到的做法是，接收方向发送方提供某种直接的反馈，以便告诉发送方别人一端的情形到底怎么样。

  一个是容量问题，一个是速率问题。容量问题会导致发送方的数据迟迟未到接收方（车太多导致堵车，迟迟不能到达目的地）。速率问题导致，接收方来不及接收（太快了，接不住）

本文标签： 计算机网络运输层（来看看，你不会后悔的）