传输层(三)：传输控制协议

1、TCP协议的主要特点

1.1、支持面向连接的传输服务

　　UPD协议是一种可满足最低传输要求的传输层协议，而TCP协议则是一种功能完善的传输层协议。

　　面向连接对提高系统数据传输的可靠性很重要。应用程序在使用TCP协议传送数据之前，必须在源进程端口与目的进程端口之间建立一条TCP传输连接。

　　每个TCP传输连接用双方端口号来标识，每个TCP连接为通信双方的一次进程通信提供服务。TCP建立在不可靠的网络层IP协议之上，IP协议不能提供任何可靠保障机制，因此TCP协议的可靠性需要自己来解决。

1.2、支持字节流的传输

　　TCP协议支持字节流传输的过程，如下：

　　

　　流(stream)相当于一个管道，从一端放入什么内容，从另一段照原样取出什么内容。描述了一个不出现丢失、重复和乱序的数据传输过程。

　　若用户是通过键盘输入数据，应用程序将逐个的将字符提交给发送端。若数据是从文件得到，那么数据可能是逐行或逐块交付给发送端。应用程序和TCP协议每次交互的数据长度可能都不相同，但TCP协议是将应用程序提交的数据看成是一连串的、无结构的字节流。

　　为了能够支持字节流传输，发送端和接收端都需要使用缓存。发送端使用发送缓存存储从应用程序送来的数据，发送端不可能为发送的每个写操作创建一个报文段，然后交给IP协议，由IP协议封装成IP分组之后传输到接收端。接收端IP协议将接收的IP分组拆封之后，将数据字段提交给接收端TCP协议。接收端TCP协议将接收字节存储在接收缓存中，应用程序使用读操作将接收数据从接收缓存中读出。

　　TCP协议在传输过程中将应用程序提交的数据看成是一连串的、无结构的字节流，因此接收端应用程序数据字节的起始与终结位置必须由应用程序自己确定。

1.3、支持全双工通信

　　TCP协议允许通信双方的应用程序在任何时候都可以发送数据。由于通信双方都设置有发送和接收缓冲区，应用程序将要发送的数据字节提交给发送缓冲区，数据字节的实际发送过程由TCP协议来控制；而接收端在正确接收到数据字节后，将它存放到接收缓冲区，高层应用程序从缓冲区中读取数据。

1.4、支持同时建立多个并发的TCP连接

　　TCP协议需要支持同时建立多个连接，一个Web服务必须同时处理多个客户端的访问。

　　TCP协议支持一个服务器与多个客户端同时建立多个TCP连接，也支持一个客户端与多个服务器同时建立多个TCP连接。TCP协议软件将分别管理多个TCP连接。

1.5、支持可靠的传输服务

　　TCP协议是一种可靠的传输服务协议，它使用确认机制检查数据是否安全和完整的到达，并且提供拥塞控制功能。TCP协议支持可靠数据传输的关键是对发送和接收的数据进行跟踪、确认与重传。

　　TCP协议建立在不可靠的网络层IP协议之上，一旦IP协议及以下层出现传输错误，TCP协议只能不断的进行重传，视图弥补传输中出现的问题。因此，传输层传输的可靠性是建立在网络层基础上，同时也就会收到它们的限制。

　　TCP协议的特点：面向连接、面向字节流、支持全双工、支持并发连接、提供确认/重传与拥塞控制功能。

2、TCP协议报文格式

　　TCP报文也称为报文段(segment)。TCP报文格式如下:

　　

2.1、TCP报头格式

　　TCP报头长度为20~60B，其中固定部分长度为20B；选项部分长度可变，最多为40B。TCP报头主要包括以下字段：

2.1.1、端口号

　　端口号字段包括源端口号与目的端口号，每个端口号字段长度为16位(2B),分别表示发送该报文段的应用进程的源端口号与接收进程的目的端口号。

2.1.2、序号

　　序号字段长度为32位，序号范围在0~(2^32 - 1)。

　　1、TCP是面向字节流的，它要为发送字节流中的每个字节都按顺序编号；

　　2、在TCP连接建立时，每方需要使用随机数产生器产生一个初始序号(initial sequence number，ISN)。

　　3、由于是连接双方各自随机产生初始序号，因此一个TCP连接的通信双方的序号是不同的。

　　如，一个TCP连接需要发送4500B的文件，初始序号ISN为10010，分为5个报文段发送。前4个报文段长度为1000B，第5个报文段长度为500B。根据TCP报文段序号分配规则，第1个报文段的第一个字节的序号区初始序号ISN为10010，第1000个字节的序号为110009，以此类推，得出如下结论：

　　第1个报文段序号范围: 10010 ~ 11009

　　第2个报文段序号范围: 11010 ~ 12009

　　第3个报文段序号范围: 12010 ~ 13009

　　第4个报文段序号范围: 13010 ~ 14009

　　第5个报文段序号范围: 14010 ~ 15009

2.1.3、确认号

　　确认好字段长度为32位(4B)。确认好表示一个进程已经正确接收序号为 N + 1 字节的报文段。

2.1.4、报头长度

　　报文头长度字段的长度为4位，TCP报头长度是以4B为一个单元来计算的，实际报头长度是在20~60B，因此这个字段的值是在 5 (5 × 4B = 20B) ~ 15(15 × 4B = 60B) 之间。

2.1.5、保留

　　保留字段长度为6位。

2.1.6、控制

　　控制字段定义了6种不同的控制位或标志，使用时在统一而时间可设置1位或多位。

　　控制字段用于TCP的连接和终止、流量控制，以及数据传送过程。

6.1、紧急(URGent，URG)位

　　发送进程将紧急位URG置1，表示该报文报文段的优先级高，需要插到报文段的最前面，尽快发送。URG位要与紧急指针字段一起使用。

6.2、确认(ACK)位

　　按照TCP的规定，在TCP连接建立之后发送的所有报文段的ACK位都要置1。

6.3、推送(PSH)位

　　当两个进程进行交互式通信时，一端应用进程希望在输入一个命令之后，能够立即得到对方的响应时，就将PSH置1，并立即创建一个报文段发送到对方；对方接收到PSH置1的报文段之后，就进尽快交给应用进程，请求尽快应答。

6.4、复位(RST)位

　　复位RST位置1，有两种含义：一是因主机崩溃等原因造成TCP连接出错，需要立即释放连接，然后再重建连接；而是拒绝一个非法TCP报文或拒绝释放一个连接。

6.5、同步(SYN)位

　　同步位SYN在连接建立时用来同步序号。如，当SYN=1、ACK=0时，表示这是一个连接建立请求报文；同时建立连接的响应报文的SYN=1、ACK=1。

6.6、终止(FIN)位

　　终止位用来释放一个TCP连接。FIN=1表示发送端的报文段发送完毕，请求释放TCP连接。

6.7、窗口

　　窗口字段长度为16位，表示以字节(B)为单位的窗口大小。

　　由于接收端的接收缓冲区是收到限制的，因此需要设置一个窗口字段表示下一次传输接收端还有多大的接收容量。窗口字段值是准备接收下一个TCP报文段的接收端，通知即将发送报文段的发送端，下一次最多可以发送报文段的字节数。

　　发送端将根据接收端通知的窗口值来调整自己的发送窗口值大小。

　　窗口字段值是动态变化的。

6.8、紧急指针

　　紧急指针字段的长度为16位，只有当紧急标志URG=1时，这个位字段才有效，这时的报文段中包括紧急数据。TCP协议软件要在优先处理完紧急数据之后才能够恢复正常操作。

6.9、选项

　　TCP报头可以有多达40B的选项字段。选项包括以下两类：单字节选项和多字节选项。

　　单字节选项有两个：选项结束和无操作。

　　多字节选项有是三个：最大报文段长度、窗口扩大因子以及时间戳。

6.10、校验和

　　计算校验和与UDP校验和的过程相同。UDP校验和是可选的，而TCP校验和是必须有的。

　　TCP校验和同样需要伪报头，不同的是协议字段的值为6。

2.2、TCP最大段长度

　　TCP对报文数据部分最大长度有一个规定能够，这个值称为最大段长度(maximum segment size，MSS)。

　　1、TCP报文段的最大长度与窗口长度的概念不同。串口长度是TCP为保证字节流传输的可靠性，接收通知发送端下一次可以连续传输的字节数。最大段长度MSS是在构成一个TCP报文段时，最多可以再报文的数据字段中防止的数据字节数量。

　　2、MSS是TCP报文中数据部分的最大字节数限定值，不包括报头长度。若确定MSS值为100B，考虑到报头部分，整个TCP报文的长度可能是120~160B。具体值取决于报头的实际长度；

　　3、MSS值的选择需考虑的因素；

·协议开销

　　TCP报文的长度等于报头部分加上数据部分。若MSS值太小会增加协议开销。

　　如报头值数值为40B，若MSS值也为40B，则每个报文段只有50%是用来传输数据的，增加了协议开销。

·IP分片

　　TCP报文是通过IP分组传输的，若MSS值选择较大，受到IP分组长度的限制，较长的报文段在IP层会被分片传输。

　　分片的结果同样会增加网络层的开销和传输出错的概率。

·发送和接收缓冲区的限制

　　为保证TCP面向字节流传输，建立TCP连接的发送端与接收端都必须设置发送和接收缓冲区。MSS值的大小直接影响到发送和接收缓冲区设置的大小与使用效率。

　　4、默认的MSS值为536B。

3、TCP的连接与释放

TCP协议工作原理示意图：

　　

　　它包括TCP连接建立、报文传输与TCP连接释放三个阶段。

3.1、TCP连接建立

　　TCP连接建立需要经过"三次握手"(there-way handshake)。

　　1、最初的客户端TCP进程是处于CLOSE(关闭)状态。当客户端准备发起一次TCP连接，进入SYN-SEND(准备发送)状态时，它首先向处于LISTEN(收听)状态的服务器端TCP进程发送第一个控制位SYN=1的"连接建立请求报文"。"连接建立请求报文"不携带数据字段，但是需要给报文一个序号，图中标为"SYN=1,seq=x"。

　　"连接建立请求报文"的序号seq值x是随机产生的，但不能为0。随机数x不能为0的理由是：避免因TCP连接非正常断开而可能引起混乱。若在连接突然中断时，可能有一个或两个进程同时等待对方的确认应答，这个时候有一个新连接的序号也是从0开始，那么接收进程就有可能认为是对方重传的报文，这样就有可能造成连接过程的错误。为避免可能引起的问题，协议规定SYN报文序号seq值x必须随机产生，并且不能为0。

　　2、服务器端在接收到"连接建立请求报文"后，若同意建立连接，则向客户端发送第二个控制位SYN=1、ACK=1的"连接建立请求确认报文"。确认号ack = x + 1，表示是对第一个"连接建立请求报文"(序号seq=x)的确认。同样，"连接建立请求确认报文"不携带数据字段。但是需要给报文一个序号(seq=y)。图中标为"SYN=1，ACK=1，seq=y，ack=x+1"。这是服务器进入 SYN-RCVD(准备接收)状态。

　　3、在接收到"连接建立请求确认报文"之后，客户端发送给第三个控制为ACK=1"连接建立请求确认报文"。由于该报文是对"连接建立请求确认报文"(序号seq=y)的确认，因此确认序号ack = y + 1。同样，"连接建立请求确认报文"不携带数据字段。但需要给报文一个序号。按照TCP协议规定，这个"连接建立请求确认报文"的序号仍然为 x + 1。图中标为"ACK = 1，seq = x + 1， ack = y + 1 "。这是客户端进入ESTABLISSHED(已建立连接)状态。服务器端在接收到ACK报文之后也进入ESTABLISHED(已建立连接)状态。

　　经过"三次握手"之后，客户进程与服务器进程之间建立了TCP连接。

　　

　　浏览器访问Web服务首先要通过DNS查找Web服务器的IP地址，图中No.1~No.4完成域名解析的过程。需要注意No.5 ~ No.7所示TCP连接建立的"三次握手"过程序号的改变。IP地址为202.1.64.166、端口号S=1298的浏览器要和IP地址为211.80.20.200、端口号D=80的Web服务器建立TCP连接。

　　1、第一个"连接尽力请求报文"(No.5)中，控制位SYN=1，序号SEQ=60029。这个报文表示：客户端用序号SEQ=60029的SYN报文，向服务器请求建立TCP连接。

　　2、第二个"连接建立请求确认报文"(No.6)中，可控制为SYN=1、ACK=1，序号SEQ=35601，确认序号ack=60029+1 = 60030。这个报文表示：服务端用序号SEQ=35601的确认报文表示接受客户端的连接建立请求，同时用序号ack=60030来对上一个序号为60029的SYN报文的确认。

　　3、第三个"连接建立请求报文"(No.7)中，控制位ACK=1，序号SEQ值仍然为60030，确认序号ack=35601+1-35602。这个报文表示：客户端用序号ack=35602对上一个确认报文进行确认。

当服务器端接收到No.7的"连接请求确认报文"之后，双方的TCP连接建立，进入HTTP交互状态。

3.2、报文传输

　　当客户端进程与服务器进程之间TCP传输连接建立之后，客户端的应用进程与服务器端的应用进程就可以使用这个链接，进行全双工的字节流传输。

　　为保证TCP工作正常、有序地进行，TCP设置了保持计时器(keep timer)，用来防止TCP连接处以长时期空闲。若客户端建立到服务器端的连接，传输一些数据，然后停止传输，可能是这个客户端出故障。在这种情况下，这个连接将永远处于打开状态。

　　为解决这种问题，一般在服务器端设置保持计时器。当服务器端收到客户端的报文时，就将保持计时器复位。若服务器端过了设定的时间没有收到客户端的信息，它就发送探测报文。如果发送10个探测报文(每一个间隔75s)还没哟偶响应，就假设客户端出现故障，进行终止该连接。

3.3、TCP连接释放

　　TCP传输连接的释放过程较复杂，客户与服务器都可以主动提出连接释放请求。下面是客户端主动提出请求的连接释放的"四次挥手"的过程。

　　1、当客户准备结束一次数据传输，主动提出释放TCP连接时，进入FIN-WAIT-1(释放等待-1)状。它向服务器发送第一个控制位FIN=1的"连接释放请求报文"，提出连接释放请求，停止发送数据。"连接释放请求报文"不携带数据字段。但需要给报文一个序号，图中标为"FIN-1，seq=u"。u等于客户端发送的最后一个字节的序号加1。

　　2、服务器在接收到"连接释放请求报文"之后，需要向客户发回"连接释放请求确认报文"，表示对接第一个连接释放请求报文的确认，因此ack=u+1。这个"连接释放请求报文"的序号为v等于服务器发送的最后一个字节序号加1。图中标为"ACK=1，seq=v，ack=u+1"。

　　TCP服务器进程向高层应用进程通知客户请求释放TCP连接，客户到服务器的TCP连接断开。但是，服务器到客户的TCP连接还没有断开，若服务器还有数据报文需要发送时，它还可以继续发送直至完毕。这种状态称为半关闭（half-close）状态。这个状态需要持续一段时间。客户在接收到服务器发送的ACK报文之后进入FIN-WAIT-2状态；服务器进入CLOSE-WAIT状态。

　　3、服务器的高层应用程序已经没有数据需要发送时，它会通知TCP可以释放连接，这时服务器向客户发送"连接释放请求报文"。这个"连接释放请求报文"的序号取决于在半关闭状态时。服务器端是否发送过数据报文。因此序号假定为w。图中标为"FIN=1，ACK=1，seq=w，ack=u+1"。服务端经过LAST-ACK状态之后转回到LISTEN(收听)状态。

　　4、客户在接收到FIN报文之后，向服务器发送"连接释放确认报文"，表示对服务器"连接释放请求报文"的确认。图中ACK报文标记为"ACK=1，seq=u+1，ack=w+1"。

连接释放"四次握手"的过程示意图如下：

　　

　　No.23与No.24分别是浏览器进程向Web服务器进程、Web服务器进程向浏览器进程发送的数据报文。No.25~No.28是连接释放过程"四次握手"的报文。

　　1、这个TCP链接释放过程由浏览器进程发起，No.25是浏览器进程向Web进程发出"连接释放请求报文"。TCP连接释放请求的TCP报头中控制位FIN=1，表示浏览器将停止发送数据。请求报文不携带数据字段。但需要给报文一个序号。在此例中seq=16752。ack是对服务器已经发送报文的确认，其值ack=69836。连接释放请求报文可以表示为"FIN=1，ACK=1，seq=16752，ack=69836"。连接释放请求报文可以表示为"FIN=1、ACK=1、seq=16752、ack=69836"。

　　2、No.26是服务器进程向浏览器进程发出"连接释放请求确认报文"。确认报文是用TCP报头中控制位ACK=1标识，表示服务器进程已正确接收浏览器的释放TCP连接请求报文，确认报文为"ACK=1，seq=69836，ack=16753"。

　　需要注意的是：服务器进程发出对浏览器进程请求释放TCP连接请求的确认报文，表示目前TCP处于半关闭状态，浏览器与服务器的连接已经断开，但是服务器到浏览器的连接仍然存在，服务器还可以向浏览器发送报文。假设服务器进程没有要发送的数据，直接进入释放服务器与浏览器连接的过程。

　　3、No.27是服务器进程向浏览器进程发出"连接释放请求报文"。服务器的请求报文用TCP报头控制为FIN=1，ACK=1表示，需注意的是：这个报文的seq与ack值与上一个报文一致。请求报文为"FIN=1、ACK=1，seq=69386，ack=16753"。

　　4、No28是浏览器进程向服务器进程发出"连接释放确认报文"。服务器的确认报文是用TCP报头中控制位ACK=1标识。确认报文为"ACK=1，seq=16753，ack=69837"。

当浏览器进程接收到服务器的"连接释放请求确认报文"之后，服务器与浏览器之间的双向TCP连接释放过程就完成了。

3.4、时间等待计时器的作用

　　为保证TCP连接释放过程正常的进行，TCP设置了时间等待计时器(TIME-WAIT-Timer)。当TCP关闭一个连接时，它并不认为这个链接马上就真正的关闭。这是，客户端进入TIME-WAIT状态，需要再等待两个最大报文寿命(maximum segment lifetime，MSL)时间之后，才真正进入CLOSED(关闭)状态。

　　客户端与服务器端经过"四次握手"之后，确认双方已经同时释放连接，客户端仍然需要采取延迟2MSL时间，确保服务器在最后阶段发送给客户端的数据，以及客户端发送给服务器的最后一个ACK报文都能正确的被接收，防止因个别报文传输错误导致连接释放失败。

4、TCP协议滑动窗口与确认、重传机制

4.1、TCP协议的差错控制

　　TCP协议通过滑动窗口机制来跟踪和记录发送字节的状态，实现差错控制功能。

　　1、TCP协议设计思想是让应用进程将数据作为一个字节流传送给它，而不是限制应用层数据的长度。应用进程不需要考虑发送数据的长度，由TCP协议来负责将这些字节分段打包；

　　2、发送端利用已经建立的TCP连接，将字节流传送到接收端的应用进程，并且是顺序的，没有差错的、丢失与重复的；

　　3、TCP协议发送的报文是交给IP协议传输的，IP协议只能提供尽力而为的服务，IP分组在传输过程中的出错是不可避免的，TCP协议必须提供差错控制、确认与重传功能，以保证接收的字节流是正确的。

4.2、字节流状态分类与窗口的概念

4.2.1、滑动窗口的基本概念

　　TCP协议使用以字节为单位的滑动窗口协议(Sliding-Windows Protocol)，来控制字节流的发送、接收、确认与重传过程。

　　1、TCP使用两个缓存和一个窗口来控制字节流的传输过程。发送端的TCP有一个缓存，用来存储应用进程准备发送的数据。发送端对整个缓存设置一个发送窗口，只要这个窗口值不为0就可以发送报文段。TCP接收端也有一个缓存。接收端将正确接收到字节流写入缓存，等待应用进程读取。接收端设置一个接收窗口，窗口值等于接收缓存可以继续接收多少字节流的大小。

　　2、接收端通过TCP报头通知发送端：已经正确接收的字节号，以及发送端还能够连续发送的字节数。3

　　3、接收窗口的大小由接收端根据接收缓存剩余空间的大小，以及应用进程读取数据的速度决定的。发送窗口的大小取决于接收窗口的大小。

　　4、虽然TCP协议是面向字节流的，但它不可能是每传送一个字节，就对这个字节进行确认。它是将字节流分成段，一个段的多个字节打包成一个TCP报文段一起传送、一起确认。TCP协议通过报头的"序号"来标识发送的字节，用"确认号"来表示哪些字节已经被正确的接收。

4.2.2、传输的字节流状态分类

　　为达到滑动窗口协议控制差错的目的，TCP协议引入了"字节流传输状态"的概念。

　　字节流传输状态分类示意图如下：

　　

为了对正确传输的字节流进行群人，必须对字节流的传输状态进行跟踪。发送的字节可以分为4中类型

　　·第1类：已经发送，且已得到确认的字节。序号1~19的字节属于第1类。

　　·已发送，但未收到确认的字节。序号20~28的字节属于已发送，但目前尚未得到接收端的确认，字节数为9。

　　·尚未发送，但是接收端表示接收缓冲区已准备好，发送端可以发送序号为 29 ~ 34 的 6个字节。若发送端准备好就可以立即发送这些字节。

　　·尚未发送，且接收端也未做好接收准备的字节。

4.2.3、发送窗口与可用窗口

　　发送端在每一次发送过程中能够连续发送字节数取决于发送窗口的大小。

　　

3.1、发送窗口

　　发送窗口的长度等于第2类与第3类字节数之和。在上图中，第2类"已发送，但未收到确认"的字节数为9，第3类字节数"尚未发送，但接收端已经做好接收准备"的字节数为6，发送窗口长度应该为 9 + 6 = 15。

3.2、可用窗口

　　可用窗口长度表示第3类字节数，即"尚未发送，但接收端已经做好接收准备的字节"，表示发送端随时可以发送的字节数。本例汇总可以发送的第一个字节的序号为29，可用窗口长度为6。

4.2.4、发送可用窗口字节之后字节的分类与窗口的变化

　　如果没有任何问题出现，发送端可以立即发送可用窗口的6B，那么第3类字节就变成第2类字节，等待接收端确认。

　　窗口发送与字节类型的变化如下：

　　

　　第1类：已经发送，并且已得到确认的字节序号为1 ~ 19。

　　第2类：已发送，但没有被确认的字节序号为20 ~ 34。

　　第3类：可以随时发送的字节数为0。

　　第4类：尚未发送，并且接收端也未做好接收准备的字节序号为35 ~ 84。

4.2.5、处理确认并滑动发送窗口

　　经过一段时间后，接收端向发送端发送1个报文，确认序号为20 ~ 25的字节，保持发送窗口值仍然为15，那么将窗口向左滑动。

　　窗口滑动与字节类型的变化：

　　

　　第1类：已发送，并且已得到确认的字节序号为 1 - 25；

　　第2类：已发送，但没有被确认的字节序号为26 - 34；

　　第3类：可以随时发送的序号为35 - 40；

　　第4类：尚未发送，并且接收端也未做好接收准备的字节序号为41 - 84。

TCP滑动窗口协议主要特点：

　　1、TCP使用发送与接收缓冲区，以及滑动窗口机制来控制TCP连接上的字节流传输。

　　2、TCP滑动窗口是面向字节的，可以起到差错控制的作用；

　　3、接收端可以在任何时候发送确认，窗口大小可以由接收端来根据需要增大或减小；

　　4、发送窗口值可以小于接收窗口的值。发送端可以根据自身的需要来决定。

4.3、选择重传策略

　　在Internet中，报文段丢失是不可避免的。如果5个报文段在传输过程中丢失两个报文段，就会造成接收的字节流序号不连续的现象。

　　

　　接收字节流序号不连续的处理方法有两种：拉回方式与选择重传方式。

4.3.1、拉回方式

　　采取拉回方式处理接收的字节流序号不连续，需要在丢失第2个报文段时，不管之后的报文段是否正确，都要从第2个报文段开始，重传所有的后4个报文段。显然，拉回方式的效率很低。

4.3.2、选择重传方式

　　选择重传(selective ACK，SACK)方式允许接收端在收到字节流序号不连续时，若这些字节的序号都在接收端窗口之内，则首先完成接收窗口内字节的接收，然后将丢失的字节序号通知发送端，发送端只需要重传丢失的报文段，而不需要重传已接收的报文段。

4.4、重传计时器

4.4.1、重传计时器的作用

　　TCP使用重传计时器(retransmission timer)来在控制报文确认与等待重传的事件。当发送端TCP发送一个报文时，首先将它的一个报文的副本放入重传队列，同时启动一个重传计时器。重传计时器设定一个值，如400ms，然后开始倒计时。在重传计时器倒计时到0之前收到确认，表示该报文传输失败，准备重传该报文。

　　

4.4.2、影响超时重传的因素

　　超时时间设定值过低，可能出现已被接收端正确接收的报文被重传，造成报文重复的现象；超时时间设定值过高，造成一个报文已经丢失，而发送端长时间的等待，造成效率降低的现象。

　　1、若一个主机同时与其他两个主机建立两条TCP连接，则它需要分为每个TCP连接启动一个重传计时器。

　　2、相同的两个主机在不同时间建立的TCP连接，并完成同样的Web访问的操作，客户端与服务器端之前的报文传输延迟也不会相同。

　　3、传输层的重发纠错机制与数据链路层的区别：数据链路层讨论的是点-点链路之间的帧往返时间，一般情况下在一条链路上的帧1往饭时间波动不会太大，在设定帧的往返时间内，若接收不到对发送帧的确认消息，可判断该帧传出错被丢弃。而传输层要面对复杂的互联网络结构，要在只能够提供"尽力而为"服务的IP之上处理端-端报文传输问题，报文往返时间在数值上离散较大。

　　TCP采用动态的自适应方法，根据端-端报文往返时间的连续测量，不断调整和设定重传定时器的超时重传时间。

5、TCP协议滑动窗口与流量控制、拥塞控制

5.1、TCP窗口与流量控制

　　流量控制(flow control)算法的目的是控制发送端发送速率，使之不超过接收端的接收速率，防止由于接收端来不及接收送达的字节流，而出现报文段丢失的现象。滑动窗口协议可利用TCP报头总窗口字段，方便的实现流量控制。

5.1.1、利用滑动窗口进行流量控制的过程

　　在流量控制过程中，接收窗口又称为通知窗口(advertised windows)。接收端根据接收能力选择一个合适的接收窗口值，将它写到TCP的报文中，将当前接收端的接收状态通知发送端。发送端的发送窗口不能够超过接收窗口的值。

TCP报头的窗口数值的单位是字节，而不是报文段。

　　·当接收端应用程序从缓存中读取字节的速度大于或等于字节到达的速度时，接收端需要在每个确认中发送一个"非零的窗口"通知。

　　·当发送端发送的速度比接收端要快时，缓冲区将被全部占用，之后到达的字节将因缓冲区溢出而丢弃。这是接收端必须发出一个"零窗口"的通知。发送端接收到一个"零窗口"通知时，停止发送，直到下一此接收端重新发送一个"零窗口"通知为止。

5.1.2、利用滑动窗口进行流量控制的例子

TCP协议利用窗口进行流量控制的过程示意图：

　　

　　1、接收端通告发送端rwnd=2400，表示接收端已经做好连续接收2400字节的准备；

　　2、发送端接收到rwnd=2400的通知后，准备发送2400字节的数据。假设报文段长度为1000字节，需要分为三个报文段来传输，其中两个报文段的数据时1000字节，而第三个报文段的数据是400字节；

　　3、接收端在分别接收序号为1~1000、1001~2000与2001~2400的三个报文段之后，存放在输出队列中，等待应用进程读取。应用进程忙而不能够及时读取。TCP输出缓冲区被占满，不能接收到新的报文段。因此，接收端在向发送端发出对序号1~2400的字节正确接收确认的同时，发出一个"零窗口"(rwnd=0)的通知；

　　4、发送端接收到接收端对序号1~2400的字节确认，知道三个报文段都已经被正确接收。同时根据rwnd=0的通知，将发送窗口也置为0，停止发送，直到接收到接收端重新发送的一个"非零窗口"通知为止；

　　5、当接收端的应用进程从接收缓冲区读取了1000个字节的数据，腾空了1000个字节的存储空间，接收端发出rwnd=1000的"非零窗口"通知；

　　6、发送端接收到rwnd=1000的通知后，发送序号2401~3400的字节；

　　7、当接收端正确接收序号2401~3400的字节后，同时接收缓冲区中已经有了2000个字节的存储空间，接收端发出对序号2401~3400字节的去人与rwnd=2000的窗口通知；

　　8、发送端接收到接收端对序号2401~3400字节的确认，与RWND=2000的通知之后，将发送序号为3401~4400、4401~5400的两个报文段。这个过程一直持续下去，直到数据全部传输完为止；

　　TCP采取了滑动窗口机制，使得发送端的发送报文段的速度与接收端的接收能力相协调，从而实现流量控制的作用。

2.1、坚持计时器

　　在执行滑动窗口控制的过程中，要求发送端在接收到零窗口通知之后就停止发送，这个过程直到接收端的TCP再发出一个非零窗口通知为止。若下一个非零窗口通告丢失造成"死锁"现象出现，TCP设置了一个"坚持计时器"(persistence timer)。

　　当发送端的TCP收到一个零窗口通知时，就启动坚持计时器。当坚持计时器时间到，发送端的TCP就发送一个零窗口探测报文。该报文只有一个字节的数据，它有一个序号，这个序号不需要确认。

　　零窗口探测报文的作用是提示接收端：非零窗口通知丢失，必须重传。

　　坚持计时器的值设置为重传时间的数值，最大为60s。若发出的第一个零窗口探测报文没有收到应答，则需发送第二个零窗口探测报文，直到收到非零窗口为止。

2.2、传输效率问题

　　针对如何提高传输效率的问题，提出了Nagle算法。

　　1、当数据时以每次1字节的方式进入发送端时，发送端第一个只发送1字节，其他的字节存入缓存区。当第一个报文段确认符合时，再把缓存中的数据放在第2个报文段中发送出去，这样按照一边发送、等待应答，以便缓存待发送数据的处理方法，可以有效提高传输效率；

　　2、当缓存的数据字节数达到发送窗口1/2或接近最大报文长度MSS时，立即将它们作为1个报文段发送。

5.1.3、TCP窗口与拥塞控制

3.1、拥塞控制的概念

　　拥塞控制用于防止由于过多的报文进入网络，而造成路由器与链路过载。

　　流量控制的重点是放在点-点链路的通信量的局部控制上，而拥塞控制重点是放在进入网络报文总量的全局控制上。

　　网络出现拥塞的条件：对网络资源的需求 > 网络可用资源。若在某段时间内，用户对网络某类资源过高，就可能造成拥塞。

　　流量控制可以很好的解决发送端与接收端之间的端-端报文发送和处理速度的协调，但无法控制进入网络的总体流量。

　　网络拥塞控制的作用示意图：

　　

　　横坐标是进入网络的负载(load)，纵坐标是吞吐量(throughput)。负载表示单位进入网络的字节数，吞吐量表示单位时间内通过网络输出的字节数。

　　1、在未采取拥塞控制方法时，在开始阶段网络吞吐量随网络负载的增加呈线性增长的关系。当出现轻度拥塞时，网络吞吐量的增长小于网络负载的增加量。当网络负载继续而吞吐量不变时，达到饱和状态。在饱和状态之后，网络吞吐量随着网络负载的增加呈减小的趋势。当网络负载继续增加到一定程度，网络吞吐量为0，系统出现死锁(deadlock)。

　　2、理想的拥塞控制在网路负载到达饱和点之前，网络吞吐量一直保持线性增长的关系，达到饱和点之后的网络吞吐量维持不变。

　　3、实际的拥塞控制在网络负载开始增长的处器，由于要在拥塞控制过程中消耗一定的资源，因此它的吞吐量将小于拥塞控制状态。但是，它可以再负载继续增加的过程中，通过限制进入网络的报文或丢弃部分报文的方法，使得系统的吞吐量逐渐增长而不出现下降和死锁的现象。

3.2、拥塞窗口的概念

　　TCP协议滑动窗口是实现拥塞控制最基本的手段。假设报文是单方向传输，并且接收由足够的缓存空间，发送窗口的大小只由网络拥塞程度来确定。

　　拥塞窗口(congestion window)是发送端根据网络拥塞情况确定的窗口值。发送端在真正确定发送窗口时，应该取"通知窗口"与"拥塞窗口"中的较小值，在没有发生拥塞的稳定工作状态下，接收端的通知窗口与拥塞窗口应该一致。

　　发送端在确定拥塞窗口大小时，可以采用慢开始与拥塞避免算法。

5.1.4、慢开始与拥塞避免算法

4.1、慢开始(slow-start)与拥塞避免(congestion avoidance)算法的基本设计思想

　　在一个TCP连接中，发送端需要维持一个拥塞窗口(congestion windows，cwnd)的状态参数。拥塞窗口的大小根据网络拥塞的情况来动态调整。网络没有出现拥塞，发送端就逐步增大拥塞窗口；当出现拥塞，拥塞窗口就立即减小。

4.2、慢开始的过程

　　当主机开始发送数据时，可以试探着采取由小到大逐步增加拥塞窗口的方法。

　　若将第一个从发送端发送报文(最大报文段长度MSS到接收端)，接收端在规定的时间内返回了确认报文为一个往返的话，那么主机建立一个TCP连接的初始化时，将慢开始的初始值定为1。第一个往返首先将拥塞窗口(cwnd)设置为2，然后向接收端发送两个最大报文段。若接收端在定时器允许的往返时间内返回确认，表示网络没有出现拥塞，拥塞窗口按二进制指数方式增长；则第二个往返将拥塞窗口值增大一倍为4。若报文正常传输，那么第三个往返发送端将拥塞窗口增加为8。若报文正确传输，在第4个往返拥塞窗口只增大一倍为16。但是，在规定的往返时间内未收到确认报文，就表明网络开始出现拥塞。

需注意以下问题：

　　1、每次发送的往返时间RTT是不相同的；

　　2、慢开始的"慢"是指以一种试探试探着逐步增大，比突然将很多报文发送网络上的情况要"慢"，意味着发送报文段的多少存在着逐步加快的过程；

　　3、为变拥塞窗口(cnwd)增长过快引起网络拥塞，需定义一个参数 ---- 慢开始阈值(slow-start threshold, ssthresh)。在慢开始与拥塞避免算法中，对于拥塞窗口(cwnd)与慢开始阈值(ssthresh)之间可做如下规定：

　　·当 cwnd < ssthresh 时，使用慢开始算法；

　　·当 cwnd > ssthresh 时，停止慢开始算法，使用拥塞控制算法；

　　·当cwnd == ssthresh时，即可使用慢开始算法，也可使用拥塞控制算法。

　　

　　慢开始、拥塞避免的AIMD算法处理拥塞的思路是：若发送端发现超时，就判断为网络出现拥塞，并将苏红色窗口cwnd置1，执行慢开始策略；同时将ssthresh减小到一半，以延缓拥塞的出现。

　　当发送端连续发送报文M1~M7，只有M3在传输过程中丢失，而M4~M7都能正确接收，这时不能根据一个M3超时而简单的判断网络出现拥塞。这种情况下采用快重传与恢复拥塞控制算法。

5.1.5、快重传与快恢复

连续收到三个重复确认拥塞控制过程：

　　

　　若在接收端正确接收M1、M2报文，没有接收到M3报文时，接收端在返回对M1、M2的确认之后，接收到M4，没有接收到M3，这是接收端不能对M4进行确认，这是由于M4属于乱序的报文。

　　根据"快重传"算法的规定，接收端应该及时向发送端连续三次发出对M2的"重复确认"，要求发送端尽早重传未被确认的报文。

　　与快重传算法配合的是快恢复算法，快恢复算法规定：

　　

　　1、当接收端收到第1个对M2的"重传确认"时，发送端立即将拥塞窗口(cwnd)设置为最大拥塞窗口值1/2。执行"拥塞避免"算法，拥塞窗口(cwnd)按线性方式增长。

　　2、当接收端收到第2个对M2的"重复确认"时，发送端立即减小拥塞窗口(cwnd)值。执行"拥塞避免"算法，拥塞窗口(cwnd)按线性方式增长。

　　3、当接收端收到第3个对M2的"重复确认"时，发送端立即见效拥塞窗口(cwnd)值。执行"拥塞避免"算法，拥塞窗口(cwnd)按线性方式增长。

6、总结

　　1、计算机网络的本质活动是实现分布在不同地理位置的联网主机之间的进程通信，传输层的主要作用是要实现分布式进程通信。

　　2、传输层协议屏蔽了网络层以及各层实现技术的差异性，弥补了网络层所能提供服务的不足，使得应用层协议在设计时只需使用传输层提供的端-端进程通信服务。

　　3、实现网络环境中分布式进程通信首先要解决进程标识的问题。IANA定义了熟知端口号、注册端口号和临时端口号三种类型的端口号。TCP与UDP协议规定用不同的端口号来表示不同的应用程序

　　4、UDP协议是一种无临界的、不可靠的传输层协议，适用于对性能要求高于数据完整性的要求、需要"简短快捷"的数据交换、需要多播和广播的应用环境。

　　5、TCP协议的特点是：面向连接、面向字节流、支持全双工、支持并发连接、提供确认/重传与拥塞控制。