计算机网络中的运输层TCP、UDP

应用层
任务是通过应用进程间的交互来完成特定网络应用，应用层协议动议的是应用进程间通信和交互规则。如DNS、HTTP协议等；

运输层
负责向两台主机中进程之间的通信提供通用的数据传输服务，TCP协议；

网络层
把运输层产生的报文段或用户数据报封装成分组或包进行传送；另一个任务是选择合适的路由，使源主机运输层所传下来的分组能够通过网络中的路由器找到目的主机。

运输层协议

概述

运输层向它上面的应用层提供通信服务。从IP层来说是主机之间的通信，其实真正进行通信的实体是主机中的进程，是进程与进程之间的通信。
网络层为主机之间提供逻辑通信，而运输层为应用进程之间提供端到端的逻辑通信。

两个重要协议

用户数据报协议UDP(User Datagram Protocol)
传送数据之前不需要建立连接。远程主机在运输层收到UDP报文之后，不需要给出任何确认。虽然不太可靠，但是减少了连接和确认的开销，在某些追求低时延的网络情况是很有效的。

传输控制协议TCP(Transmission Control Protocol)
面向连接的服务，在传送数据之前必须先建立连接，数据传送结束后要释放连接。由于TCP提供可靠的、面向连接的运输服务，因此不可避免地增加了许多开销。这不仅使协议数据单元的首部增大很多，而且还占用许多的处理机资源。

运输层的端口

复用： 应用层所有应用进程都可以通过运输层再传送到Ip层，这是复用；
分用： 运输层从IP层收到发送给各个应用进程的数据后，必须分别交付指明的个应用进程，这时分用。

为了给一个特定机器上运行的特定进程一个标识，我们使用协议端口号来作为应用层的各种协议进程与运输实体进程层间交互的一种地址。虽然通信的终点是应用进程，但是要把所传送的报文交到目的主机的某个合适的目的端口，剩下的工作就由TCP或UDP来完成。

因此两个计算机中的进程要同心，不仅必须直到对方的IP地址(为了找到对方的主机)，而且要知道对象的端口号(为了找到对方计算机中的应用进程)。

用户数据报协议UDP

概述

• 无连接：发送之前不需要建立连接；
• 尽最大努力交付：不保证可靠交付，因此不需要维持复杂的连接状态表；
• 面向报文：就是对于复用和分用只是对报文添加头部和解封头部；
• 没有拥塞控制；
• 支持一对一、一对多、多对一、多对多的交互通信；
• 首部开销小、只有8个字节；

首部格式

伪首部

在计算检验和时，要在首部添加一个12字节的伪首部，检验和是把首部和数据部分一起检验的。

传输协议控制协议TCP概述

特点

• 面向连接，在使用之前必须先建立TCP连接，发送完之后释放连接；
• 每一条TCP连接只能有两个端点，每一条TCP连接只能是点对点的；
• 提供可靠交付的服务，无差错、不丢失、不重复并且按序到达。
• 全双工通信：TCP允许通信双方的应用进程在任何时候都能发送数据。TCP连接的两端都设有发送缓存和接收缓存，用来临时存放双向通信的数据。在发送的时候应用程序在把数据传送给TCP的缓存后，就可以做自己的事，而TCP在合适的时候把数据发送出去。在接收时TCP把收到的数据放入缓存，上层的应用进程在合适的时候读取缓存中的数据。
• 面向字节流：流是指流入到进程或从进程流出的字节序列。虽然应用程序和TCP的交互是一次一个数据块，但TCP把应用程序叫下来的数据仅仅看成一连串的无结构字节流。不保证接收方应用程序所收到的数据块和发送方应用程序所发出的数据块具有对应的关系。

TCP和UDP发送报文时采用的方式完全不同：TCP并不关心应用进程一次把多长的报文发送到TCP缓存中，而是根据对方给出的窗口值和当前网络拥塞的程度来决定一个报文段应包含多少个字节。如果应用进程传送到TCP缓存的数据块太长，就把它划分短一些在传送。如果应用进程只发来一个字节，TCP也可以等待积累有足够多的字节再构成报文段发送出去。而UDP是应用进程给它多长的报文，它就要完整的发出去。

TCP的连接

每一条TCP连接有两个端点，TCP连接的端点叫套接字或插口，端口号拼接到IP地址即构成套接字，套接字 socket=(IP:端口号)，每一条TCP连接唯一的被通信两端的两个端点所确定。

可靠传输的工作原理

TCP发送的报文是交给IP层传送的，但IP层只能尽最大努力服务，也就是说TCP下面的网络所提供的是不可靠的传输。因此TCP必须采用合适的措施才能使通信变得可靠。

停止等待协议

每发送完一个分组就停止发送，等待对方确认，在收到确认后在发送下一个分组。

无差错情况

出现差错

B接收M1是检测出了错，就丢弃M1，也不通知A或者B根本没收到数据，也不会发送任何回执给A。可靠传输协议是这样设计的：A只要超过一段时间仍然没有收到确认，就认为刚才发送的分组丢失了，因而重新发送前面的分组，这就是超时重传，每发送一个分组就要设置一个超时计时器，如果在超时计时器到期之前就收到了对方的确认，就撤销已设置的超时计时器。

应注意以下三点：

• 发送方必须暂时保留已发送的分组的副本，直到收到确认后才能清除，否则需要重传；
• 分组和确认分组都必须进行编号，这样才能没明确是哪一个发送出去的分组受到了确认，哪一个分组还么没有收到确认。
• 超时计时器设置的重传时间应当比数据在分组传输的平均往返时间更长一些。

确认丢失和确认迟到

B发送的对M1的确认丢失了，A在设定的超时重传时间内没有收到确认，并无法知道自己发送的分组出错、丢失，或是B返回的确认丢失了。因此A就要在超时到时的时候重传M1，假设又B收到了重传的分组，他需要做两件事：

• 丢弃这个重复的分组M1，不想上层交付；
• 向A再发送确认；

这种协议称为自动重传请求ARQ，意思是重传请求是自动进行的，接受方不需要请求发送方重传某个出错的分组。

信道利用率

如果使用停止等待协议发送一个等待确认消息，再发送下一个。A发送数据时间为TD，中间往返传输时间RTT，B发送确认时间TA，那么信道利用率U=TD/(TD+TD+RTT+TA),信道在大多数时间是空闲的，为了提高传输效率。发送方可以不适用低效率的停止等待协议，而是采用流水线传输，流水线传输就是发送方可以连续发送多个分组，不必发完一个分组就停止等待确认。

连续ARQ协议

位于发送窗口的5个分组都可连续发送出去，而不需要等待对象的确认。

发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。接收方一般都是采用累计确认的方式，就是说接收方不必对收到的分组逐个发送确认，而是在收到几个分组后，对顺序到达的最后一个分组发送确认，这就表示，到这个分组为止的所有分组都正确收到了。
累计确认的优点：容易实现、即使确认丢失也不必重传，但缺点是不能向发送方反映出接收方已经正确收到的所有分组的信息。如果发送方发送了前5个分组，而中间第3个分组丢失了，这时接受方只能对前两个分组发出确认，发送方无法知道后面三个分组的下落，而只好把后面三个分组都再重传一次。这就叫Go-back-N，表示需要再退回来重传已发送的N个分组。

TCP报文段的首部格式

一个TCP报文段分为首部和数据两部分，而TCP的全部功能都体现在它受不得各个字段的作用。

• 源端口和目的端口：各占2个字节；
• 序号：占4个字节，在一个TCP连接中传送的字节流中的每一个字节都按顺序编号。范围是[0,2^32-1],如果增加到了最大上限，就又从0开始。
• 确认号：占4个字节，是期望收到对方下一个报文段的第一个数据字节的序号，B正确收到了A发过来的从501开始的200个字节(501-700)，然后B期望收到A下一个数据序号是701，于是在发送给A的确认报文段把确认号置为701；
• 数据偏移：占4个字节，这个字段表示TCP报文段的数据起始处距离TCP报文段的起始处有多远；
• 保留：占6位，保留今后使用；
• 紧急URG：当URG=1时，表明紧急指针字段有效，它告诉系统此报文段中有紧急数据，应尽快传送，而不要按原来的排队顺序来传送。于是发送方TCP就把紧急数据插入到本报文数据段的最前面，而在紧急数据后面的数据仍是普通数据，这时要与首部中的紧急指针字段配合使用。
• 确认ACK：仅当ACK=1时确认号字段才有效，TCP规定，在连接建立后的所有传送的报文段都必须把ACK置1；
• 推送PSH：当两个应用进程进行交互式的通信时，有时在一端的应用进程希望在键入一个命令后立即就能够收到对方的响应。接收方收到PSH=1的报文段，就尽快交付接收应用进程，而不再等到整个缓存都填满了在向上交付。
• 复位RST：当RST=1时，表明TCP连接中出现严重差错，必须释放连接，然后再重新建立运输链接。RST置1还用来拒绝一个非法的报文段或拒绝打开一个连接。
• 同步SYN：在连接建立时用来同步信号，当SYN=1而ACK=0时，表明这是一个连接请求报文段。对方若同意建立连接，则应在响应的报文段中使SYN=1和ACK=1。
• 终止FIN：用来释放一个连接，当FIN=1时，表明此报文段的发送方的数据已经发送完毕了，并要求释放运输连接。
• 窗口：占2个字节，窗口值是[0,2^16-1]之间的整数，窗口指的是发送本报文段的一方的接收窗口，窗口值告诉对方：从本报文段首部中的确认号算起，接收方目前允许对方发送的数据量。因为接收方的数据存储空间是有限的，窗口作为接收方让发送方设置其发送窗口的依据。 告诉对方我的缓存现在还能多少个字节的数据；
• 校验和：占2个字节。检验和字节检验的范围包括首部和数据这两部分；
• 紧急指针：只有URG=1时才有效，指出本报文段中的紧急数据的字节数，紧急数据都在报文数据部分的前面放着，所以指针指在紧急数据的末尾，当所有紧急数据处理完了，TCP就告诉应用程序恢复到正常操作处理普通字节。
• 选项：长度可变最长达40字节；

TCP的流量控制

流量控制就是让发送方的发送速率不要太快，要让接收方来得及接收。

利用滑动窗口实现流量控制
发送方的发送窗口不能超过接收方给出的接收窗口的数值。

TCP的传输效率

• 等缓存中存放的数据达到MSS字节时就组成一个TCP报文发送出去；
• 由发送方的应用进程指明要求发送报文段；
• 发送方的一个计时器期限到了，就把已有的缓存装入报文段发送出去；

Nagle算法

应用进程把发送的数据逐字节送到TCP缓存，则发送方把第一个数据字节发送出去，继续往TCP缓存中写入数据，当收到第一个字节的确认后，就把此时缓存中的数据组装成一个报文发送出去，同时继续对随后到达的数据进行缓存，等待上一个报文的确认。当缓存中的数据达到发送窗口的一半或已达到报文段的最大长度是，就立即发送一个报文。

糊涂窗口综合征
如果应用进程处理的很慢，一次只从接收方缓存中拿一个字节进行处理，而接收方会发送一个窗口为1个字节的确认给发送方，发送方就发送一个字节数据。这样来回效率很低。可以让接收方等待一段时间，让缓存中有足够的空间容纳一个最长的报文段，或者等到接收缓存已有一般空闲的空间，在发送确认，并发送当前的窗口大小。

TCP的拥塞控制

所谓拥塞控制就是防止过多的数据注入到网络，这样可使网络中的路由器或链路不致过载，拥塞控制是一个全局性的过程，在传输过程中的任何一个结点出现拥塞，就会导致整个传输过程拥塞。而TCP连接端点很难知道是哪个结点拥塞了。而流量控制则是点到点通信量的控制

拥塞控制是一个动态的问题，从大的方面分为开环控制和闭环控制；

开环就是在设计网络时事先将有关发生拥塞的因素考虑周到，力求不拥塞，但一旦系统运行起来，中途就不再改正了。

闭环是基于反馈环路的理念：检测网络系统以便检测到拥塞在何时、在何处；把拥塞发生的信息传送到可采取行动的地方；调整网络系统的运行以解决出现的问题。

TCP的拥塞控制方法

慢开始、拥塞避免、快重传和快恢复

慢开始和拥塞避免

发送方维持一个叫拥塞窗口的状态变量，拥塞窗口的大小取决于网络的拥塞程度，并且在动态变化，发送方让自己发送窗口等于拥塞窗口。只要网络没有出现阻塞，拥塞窗口就增大，只要网络出现拥塞或有可能拥塞，就把拥塞窗口减小。

发送方如何知道是否发生拥塞？
当网络发生拥塞时，路由去就要丢弃分组，因此只要发送方没有按时收到确认报文，就可以判断发生了拥塞，所以判断网络拥塞的依据就是出现了超时。

慢开始
当主机开始发送数据时，由于不清楚网络的负荷情况，所以如果立即把大量数据字节注入到网络，那么就有可能引发网络拥塞，所以由小到大逐渐增大发送窗口，也就是，由小到大逐渐增加拥塞窗口数值。

拥塞避免

也是让拥塞窗口缓慢增大，每经过一个往返时间RTT就把发送方的拥塞窗口大小+1，而不像慢开始那样加倍增长。

可以设置一个慢开始门限，当达到这个门限时，就采用拥塞避免方法，让拥塞窗口线性规律增长，使网络比较不容易出现拥塞。

当拥塞避免阶段出现超时重传时，慢开始门限降低为当前大小的一半24/2=12;拥塞窗口就又从初始值开始，进入慢开始阶段。

在图中4点又出现了发送发一连收到三个对同一报文的确认，有时个别报文段会在网络中丢失，但实际上网络未发生阻塞，如果发送方迟迟收不到确认，就会超时，认为网络拥塞，有开启慢开始，降低了传输效率。

快重传算法

可以让发送方尽早知道个别报文段的丢失，首先要求接收方发送不要捎带确认，而是立即发送确认，即使收到失序的报文段也要立即发出对已收到报文段的重复确认。

加入M3在传输过程中丢失，接收方没有收到M3却收到了M4就认为M3丢失了，它在接下来收到报文后，立即发送对M2的重复确认。发送方只要一连收到3个确认，就知道接受方没有收到报文M3，就会立即进行重传，发送方也不会认为是网络拥塞了。

由于发送方现在知道只是丢失了个别的报文段，于是不启动慢开始，而是执行快恢复算法，将发送方门限值调整为16/2=8,并开始执行拥塞避免算法。

主动队列管理AQM

如果在传输过程中，某个路由器对某些分组的处理时间特别长，数据到达接收方的时间会变成，会导致发送方超时，触发TCP慢开始，而通常网络中的很多TCP连接复用在网络IP数据报中，这种情况如果发生路由器队列满了丢弃分组，会导致多条TCP连接触发慢启动，整个网络传输速率大大降低，而如果网络恢复后其通信量又突然增大很多，这称为全局同步。为了避免这种情况，设定路由器队列长度最小门限和最大门限。

• 平均队列长度小于最小门限，把新到达的分组放入队列进行排队；
• 若超过最大门限，则把新到达的分组丢弃；
• 若介于两者中间，则按照某一丢弃概率丢弃。

TCP的运输连接管理

TCP建立连接

主动发起连接建立的应用进程叫做客户端，而被动等待连接建立的应用进程叫做服务器。

B的TCP服务器进程先创建传输控制块TCB，准备接受客户进程的连接请求，然后服务器进程就处于LISTEN监听状态，等待客户的连接请求；

A的TCP客户进程也是首先创建传输控制模块TCB，在打算建立TCP连接时：

1、A向B发出连接请求报文段，首部中的同部位SYN=1；SYN置为1就表示这是一个连接请求或连接接收报文，同时选择一个初始序号seq=x，TCP客户进程进入同步已发送状态。
2、B收到请求报文段后，如果同意建立连接就向A发送确认，在确认报文段中应把SYN和ACK都置为1，确认号是ack=x+1表示期望客户端下一次发送过来的序号为x+1，同时也为自己选择一个初始序号seq=y。这时TCP服务器进程进入到同步收到状态。
3、TCP客户进程收到B的确认后，还要向B给出确认，确认报文段ACK=1，确认号ack=y+1表示希望对方下一次发送的确认序号为y+1，而自己的序号为上一次服务端希望的x+1;当B收到A的确认后，也就如已建立连接状态。

为什么握手是三次？
B发送给A的确认报文可以拆分为一个确认报文段和一个同步报文段，如果分开发送就变成了四次报文握手，不过效果是一样的，所以放在一个报文中发送过去。

为什么A最后还要发送一次确认？
主要是为了防止已失效的连接请求报文段突然后传送到了B，因而产生错误。如果A发送的第一个连接请求因为某种原因滞留在网络节点中的时间很长，而触发A的重发，发送了第二个连接，然后在第二个连接的基础上交互数据，断开连接。而这时第一个连接请求才到达B，B以为A又要建立新的连接，于是发送一个确认，假设A没有最后一次确认，那么新的连接就建立成功了，B就一直等待A发送数据，白白浪费了资源等待，而如果有了最后一次确认，A收到新的确认后，因为这是个已经失效的连接请求，不予处理(不会发送最后一次确认)，连接建立不起来，B再发送了几次之后就不再发送。

TCP的连接释放

1、A应用进程先向其TCP发送释放连接报文段，并停止再发送数据，主动关闭TCP连接，A把连接释放报文段首部的终止控制位FIN置为1，其序号为seq=u，它等于前面已传送过的数据的最后一个字节序号+1，这时A进入终止等待1状态，等待B的确认。
2、B收到连接释放报文段后发出确认，确认号ack=u+1;这个报文段自己的序号seq=v;然后B进入关闭等待状态。TCP服务器进程这时应通知高层应用进程，因而从A到B这个方向的连接就释放了，这时TCP处于半关闭状态，表示A已经没有数据要放了，但是B若要发送数据，A仍要接收，所以从B到A这个方向连接并未关闭，这个状态可能会持续一段时间。A收到来自B的确认之后就进入了终止等待2状态，等待B发出连接释放报文段。
3、若B已经没有要向A发送的数据，其应用进程就通知TCP释放连接，这时B发出的连接释放报文段必须使FIN=1，现在假定B的序号为w(在半关闭状态B可能又发送了一些数据)，B还必须重复上次已发送过得确认号ack=u+1;这时B就进入了最后确认状态，等待A的确认。
4、A在收到B的释放连接报文段后，必须对此发出确认，在确认报文段中把ACK置1；确认号为ack=w+1，而自己的序号是seq=u+1；然后进入TIME-WAIT 时间等待状态，需要等待2MSL后，A才进入到CLOSES状态。

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

1、为了保证A发送的最后一个ACK报文能够达到B，有可能这个ACK报文会丢失，如果不等待直接关闭closed，B没有收到确认就会重发，然而此时A已经关闭了，B就无法按照正常步骤进入CLOSED状态。而如果等待了2MSL(报文一来一回的时间)，ACK报文丢失了，B重发，A此时没有关闭可以受到就再重发一次确认，再把时间重置为2MSL。直到2MSL时间内内有收到B的重发，就说明B成功接收并且关闭了，此时A也就关闭。

2、防止前面提到的已失效的连接请求报文段出现在本连接中，第一个原因是保证B必须受到最后一个ACK并且在A之前CLOSED，如果B收不到就一直处于最后确认阶段，如果此时失效的连接请求报文段到达了B，B就会以为A又要建立新的连接，又会建立连接等待。

TCP保活机制

如果客户端出现故障，不能发送数据，这时B不能白白等着，服务器每收到一次客户端的数据，就重置保活计时器，时间的设置通常是两小时，如果两小时之内没有收到客户的数据，服务器就发送一个探测报文段，以后每隔75秒就发送一次，如果连这发送10个探测报文后客户仍无响应，服务器就认为客户端出了故障，接着就关闭这个连接。