334-传输控制协议TCP概述

传输控制协议TCP概述

TCP最主要的特点

TCP是TCP/IP体系中非常复杂的一个协议。
1、TCP是面向连接的运输层协议。这就是说，应用程序在使用TCP协议之前，必须先建立TCP连接。在传送数据完毕后，必须释放已经建立的TCP连接。也就是说，应用进程之间的通信好像在“打电话”：通话前要先拨号建立连接，通话结束后要挂机释放连接。
2、每一条TCP连接只能有2个端点，每一条TCP连接只能是点对点的（一对一）。
3、TCP提供可靠支付的服务。通过TCP连接传送的数据，无差错、不丢失、不重复，并且按序到达。
4、TCP提供全双工通信。TCP允许通信双方的应用进程在任何时候都能发送数据。TCP连接的两端都设有发送缓存和接收缓存，用来临时存放双向通信的数据。在发送时，应用程序在把数据传送给TCP的缓存后，就可以做自己的事，而TCP在合适的时候把数据发送出去。在接收时，TCP把收到的数据放入缓存，上层的应用进程在合适的时候读取缓存中的数据。
5、面向字节流。TCP中的“流”指的是流入到进程或从进程流出的字节序列。“面向字节流”的含义是：虽然应用程序和TCP的交互是一次一个数据块（大小不等），但TCP把应用程序交下来的数据仅仅看成是一连串的无结构的字节流。TCP并不知道所传送的字节流的含义。TCP不保证接收方应用程序所收到的数据块和发送方应用程序所发出的数据块具有对应大小的关系（例如，发送方应用程序交给发送方的TCP共10个数据块，但接收方的TCP可能只用了4个数据块就把收到的字节流交付上层的应用程序）。但接收方应用程序收到的字节流必须和发送方应用程序发出的字节流完全一样。当然，接收方的应用程序必须有能力识别收到的字节流，把它还原成有意义的应用层数据。下图5-8是上述概念的示意图。

为了突出示意图的要点，我们只画出了一个方向的数据流。但请注意，在实际的网络中，一个TCP报文段包含上千个字节是很常见的，而图中的各部分都只画出了几个字节，这仅仅是为了更方便地说明“面向字节流”的概念。另一点很重要的是：上图5-8中的TCP连接是一条虚连接（也就是逻辑连接），而不是一条真正的物理连接。TCP报文段先要传送到IP层，加上IP首部后，再传送到数据链路层。再加上数据链路层的首部和尾部后，才离开主机发送到物理链路。
图5-8指出，TCP和UDP在发送报文时所采用的方式完全不同。TCP并不关心应用进程一次把多长的报文发送到TCP的缓存中，而是根据对方给出的窗口值和当前网络拥塞的程度来决定一个报文段应包含多少个字节（UDP发送的报文长度是应用进程给出的）。如果应用进程传送到TCP缓存的数据块太长，TCP就可以把它划分短一些再传送。如果应用进程一次只发来一个字节，TCP也可以等待积累有足够多的字节后再构成报文段发送出去。

TCP的连接

TCP把连接作为最基本的抽象。TCP的很多特性都与TCP是面向连接的这个基本特性有关。
每一条TCP连接有2个端点。那么，TCP连接的端点是什么呢？
不是主机，不是主机的IP地址，不是应用进程，也不是运输层的协议端口。TCP连接的端点叫做套接字（socket）或插口。端口号拼接到IP地址即构成了套接字。因此，套接字的表示方法是在点分十进制的IP地址后面写上端口号，中间用冒号或逗号隔开。例如，若IP地址是192.3.4.5而端口号是80，那么得到的套接字就是（192.3.4.5:80）。总之，我们有
套接字socket=（IP地址：端口号） (5-1)
每一条TCP连接唯一地被通信两端的两个端点（即两个套接字）所确定。即：
TCP连接：：={socket1,socket2}={（IP1:port1）,（IP2:port2）} (5-2)

这里IP1和IP2分别是两个端点主机的IP地址，而port1和port2分别是两个端点主机中的端口号。TCP连接的两个套接字就是socket1和socket2。可见套接字socket是个很抽象的概念。
总之，TCP连接就是由协议软件所提供的一种抽象。虽然有时为了方便，我们也可以说，在一个应用进程和另一个应用进程之间建立一条TCP连接，但一定要记住：TCP连接的端点是个很抽象的套接字，即（IP地址：端口号）。也还应记住：同一个IP地址可以有多个不同的TCP连接，而同一个端口号也可以出现在多个不同的TCP连接中。
请注意，socket这个名词有时容易使人把一些概念弄混淆，因为随着互联网的不断发展以及网络技术的进步，同一个名词socket却可表示多种不同的意思。例如：
1、允许应用程序访问连网写一点应用编程接口API，即运输层和应用层之间的一种接口，称为socket API，并简称为socket。
2、在socket API中使用的一个函数名也叫做socket。
3、调用socket函数的端点称为socket，如“创建一个数据报socket”。
4、调用socket函数时，其返回值称为socket描述符，可简称为socket。
5、在操作系统内核中连网协议的Berkeley实现，称为socket实现。
上面的这些socket的意思都和本章节所引用的socket（指端口号拼接到IP地址）不同。

可靠传输的工作原理

我们知道，TCP发送的报文段是交给IP层传送。但IP层只能提供尽最大努力服务，也就是说，TCP下面的网络所提供的是不可靠的传输。因此，TCP必须采用适当的措施才能使得两个运输层之间的通信变得可靠。
理想的传输条件有以下两个特点：
1、传输信道不产生差错
2、不管发送方以多快的速度发送数据，接收方总是来得及处理收到的数据。
在这样的理想传输条件下，不需要采取任何措施就能够实现可靠传输。
然而实际的网络都不具备以上两个理想条件。但我们可以使用一些可靠传输协议，当出现差错时让发送方重传出现差错的数据，同时在接收方来不及处理收到的数据时，及时告诉发送方适当降低发送数据的速度。这样一来，本来不可靠的传输信道就能够实现可靠传输了。

停止等待协议

全双工通信的双方既是发送方也是接收方。下面为了讨论问题的方便，我们仅考虑A发送数据而B接收数据并发送确认。因此A叫做发送方，而B叫做接收方。因为这里是讨论可靠传输的原理，因此把传送的数据单元都称为分组，而不考虑数据是在哪一个层次上传送的。“停止等待”就是每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。

1、无差错情况
停止等待协议可用下图5-9来说明。图5-9（a）是最简单的无差错情况。A发送分组M1，发完就暂停发送，等待B的确认。B收到了M1就向A发送确认。A在收到了对M1的确认后，就再发送下一个分组M2。同样，在收到B对M2的确认后，再发送M3。

2、出现差错
图5-9（b）是分组在传输过程中出现差错的情况。B接收了M1时检测出了差错，就丢弃M1，其他什么也不做（不通知A收到有差错的分组）。也可能是M1在传输过程中丢失了，这时B当然什么都不知道。在这两种情况下，B都不会发送任何消息。可靠传输协议是这样设计的：A只要超过了一段时间仍然没有收到确认，就认为刚才发送的分组丢失了，因而重传前面发送过的分组。这就叫做超时重传。要实现超时重传，就要在每发送完一个分组时设置一个超时计时器。如果在超时计时器到期之前收到了对方的确认，就撤销已设置的超时计时器。其实在图5-9（a）,A为每一个已发送的分组都设置了一个超时计时器。但A只要在超时计时器到期之前收到了相应的确认，就撤销该超时计时器。为简单起见，这些细节在图5-9（a）中都省略了。
这里应注意以下三点。
第一，A在发送完一个分组后，必须暂时保留已发送的分组的副本（在发生超时重传时使用）。只有在收到相应的确认后才能清除暂时保留的分组副本。
第二，分组和确认分组都必须进行编号（分组编号使用的位数总是有限的，同一个号码会重复使用。例如10位的编号范围是0-1023，当编号增加到1023时，再增加一个号就又回到0，然后重复使用这些号码。因此，在所发送的分组中，必须能够区分开哪些是新发送的哪些是重传的。对于简单链路上传送的帧，如采用停止等待协议，只要用1位编号即可，也就是发送完0号帧，收到确认后，再发送1号帧，收到确认后，再发送0号帧。但是在运输层，这种编号方法有时并不能保证可靠传输），这样才能明确是哪一个发送出去的分组收到了确认，而哪一个分组还没有收到确认。
第三，超时计时器设置的重传时间应当比数据在分组传输的平均往返时间更长一些。图5-9（b）中的一段虚线表示如果M1正确到达B同时A也正确收到确认的过程。可见重传时间应设定为比平均往返时间更长一些。显然，如果重传时间设定得很长，那么通信的效率就会很低。但如果重传时间设定得太短，以致产生不必要的重传，就浪费了网络资源。然而，在运输层重传时间的准确设定是非常复杂的，这是因为已发送出的分组到底会经过哪些网络，以及这些网络将会产生多大的时延（这取决于这些网络当时的拥塞情况），这些都是不确定因素。图5-9中把往返时间当作固定的（这并不符合网络的实际情况），只是为了讲述原理的方便。

3、确认丢失和确认迟到
下图5-10（a）说明的是另一种情况。B所发送的对M1的确认丢失了。A在设定的超时重传时间内没有收到确认，并无法知道是自己发送的分组出错、丢失，或者是B发送的确认丢失了。因此A在超时计时器到期后就要重传M1。现在应注意B的动作。假定B又收到了重传的分组M1。这时应采取两个行动。
第一，丢弃这个重复的分组M1，不向上层交付。
第二，向A发送确认。不能认为已经发送过确认就不再发送，因为A之所以重传M1就表示A没有收到对M1的确认。

上图5-10（b）也是一种可能出现的情况。传输过程中没有出现差错，但B对分组M1的确认迟到了。A会收到重复的确认。对重复的确认的处理很简单：收下后就丢弃。B仍然会收到重复的M1，并且同样要丢弃重复的M1，并重传确认分组。
通常A最终总是可以收到对所有发出的分组的确认。如果A不断重传分组但总是收不到确认，就说明通信线路太差，不能进行通信。
使用上述的确认和重传机制，我们就可以在不可靠的传输网络上实现可靠的通信。
像上述的这种可靠传输协议通常称为自动重传请求ARQ。意思是重传的请求是自动进行的。接收方不需要请求发送方重传某个出错的分组。

4、信道利用率
停止等待协议的优点是简单，但缺点是信道利用率太低。我们可以用图5-11来说明这个问题。为简单起见，假定在A和B之间有一条直通的信道来传送分组。

假定A发送分组需要的时间是TD。显然，TD等于分组长度除以数据率。再假定分组正确到达B后，B处理分组的时间可以忽略不计，同时立即发回确认。假定B发送确认分组需要时间TA。如果A处理确认分组的时间也可以忽略不计，那么A在经过时间（TD+RTT+TA）后就可以再发送下一个分组，这里的RTT是往返时间。因为仅仅是在时间TD内才用来传送有用的数据（包括分组的首部），因此信道的利用率U可用下式计算：

请注意，更细致的计算还可以在上式分子的时间TD内扣除传送控制信息（如首部）所花费的时间。但在进行粗略计算时，用近似的式（5-3）就可以了。
我们知道，式（5-3）中的往返时间RTT取决于所使用的信道。例如，假定1200km的信道的往返时间RTT=20ms。分组长度是1200bit，发送速率是1Mbit/s。若忽略处理时间和TA（TA一般都远小于TD），则可以算出信道的利用率U=5.66%。但若把发送速率提高到10Mbit/s，则U=5.96*10的-4,。信道在绝大多数时间内都是空闲的。
从图5-11还可以看出，往返时间RTT远大于分组发送时间TD时，信道的利用率就会非常低。还应注意的是，图5-11并没有考虑出现差错后的分组重传。若出现重传，则对传送有用的数据信息来说，信道的利用率就还要降低。
为了提高传输效率，发送方可以不适用低效率的停止等待协议，而是采用流水线传输（如下图5-12所示）。流水线传输就是发送方可连续发送多个分组，不必每发完一个分组就停顿下来等待对方的确认。这样可使信道上一直有数据不间断地在传送。显然，这种传输方式可以获得很高的信道利用率。

当使用流水线传输时，就要使用下面介绍的连续ARQ协议和滑动窗口协议。

连续ARQ协议

下图5-13（a）表示发送方维持的发送窗口，它的意义是：位于发送窗口内的5个分组都可连续发送出去，而不需要等待对方的确认。这样，信道利用率就提高 了。
在讨论滑动窗口时，我们应当注意到，图中还有一个时间坐标（但以后往往省略这样的时间坐标）。按照习惯，“向前”是指“向着时间增大的方向”，而“向后”则是“向着时间减少的方向”。分组发送是按照分组序号从小到大发送的。

连续ARQ协议规定，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。图5-13（b）表示发送方收到了对第1个分组的确认，于是把发送窗口向前移动一个分组的位置。如果原来已经发送了前5个分组，那么现在就可以发送窗口内的第6个分组了。
接收方一般都是采用累积确认的方式。这就是说，接收方不必对收到的分组逐个发送确认，而是在收到几个分组后，对按序到达的最后一个分组发送确认，这就表示：到这个分组为止的所有分组都已正确收到了。
累积确认有优点也有缺点。优点是：容易实现，即使确认丢失也不必重传。但缺点是不能向发送方反映出接收方已经正确收到的所有分组的信息。
例如，如果发送方发送了前5个分组，而中间的第3个分组丢失了。这时接收方只能对前两个分组发出确认。发送方无法知道后面三个分组的下落，而只好把后面的三个分组都再重传一次。这就叫做Go-back-N（回退N），表示需要再退回来重传已发送过的N个分组。可见当通信线路质量不好时，连续ARQ协议会带来负面的影响。

标签：收到,重传,334,确认,TCP,发送,分组,传输控制协议
来源： https://blog.csdn.net/LINZEYU666/article/details/117902503