第五章传输层

1、传输层的功能？
从通信和信息处理的角度看，传输层向它上面的应用层提供通信服务，它属于面向通信部分的最高层，同时也是用户功能中的最低层。传输层位于网络层之上，它为运行在不同主机上的进程之间提供了逻辑通信，而网络层提供主机之间的逻辑通信。显然，即使网络层协议不可靠，传输层同样能为应用程序提供可靠的服务。
传输层的功能如下：
（1）传输层提供应用进程之间的逻辑通信。与网络层的区别是，网络层提供的是主机之间的逻辑通信。从网络层来说，通信的双方是两台主机，IP数据报的首部给出了这两台主机的IP地址。但“两台主机之间的通信”实际上时两台主机中的应用进程之间的通信，应用进程之间的通信又称端到端的逻辑通信。
（2）复用和分用。复用是指发送方不同的应用进程都可使用一个传输层协议传送数据；分用是指接收方的传输层在剥去报文的首部后能够把这些数据正确交付到目的应用进程。
（3）传输层还要对收到的报文进行差错检测(（首部和数据部分）。而网络层只检查IP数据报的首部，不检验数据部分是否出错。
（4）提供两种不同的传输协议，即面向连接的TCP和无连接的UDP。而网络层无法同时实现两种协议（即在网络层要么只提供面向连接的服务，如虚电路；要么只提供无连接服务，如数据报，而不可能在网络层同时存在着两种方式）。
2、UDP协议？
RFC 768定义的UDP只是做了传输协议能够做的最少工作，它仅在IP的数据报服务之上增加了两个最基本的服务：复用和分用以及差错检测。如果应用程序开发者选择UDP二非TCP，那么应用程序几乎直接与IP打交道。为什么应用开发人员宁愿在UDP之上构建应用，也不选择TCP？既然TCP提供可靠地服务，而UDP不提供，那么TCP总是首选吗？答案是否定的，因为有很多应用更适合用UDP，主要是因为UDP具有如下特点：
1>UDP无须建立连接。因此UDP不会引入建立连接的时延。试想如果DNS运行在TCP而非UDP上，那么DNS的速度会慢很多。HTTP使用TCP而非UDP，是因为对于基于文本数据的Web网页来说可靠性是至关重要的。
2>无连接状态。TCP需要在端系统中维护连接状态。此连接状态包括接收和发送缓存、拥塞控制参数和序号与确认好的参数。而UDP不维护连接状态，也不跟踪这些参数。因此，某些专用应用服务器使用UDP时，一般都能支持更多的活动客户机。
3>分组首部开销小。TCP有20B的首部开销，而UDP仅有8B的升销。
4>应用层能更好地控制要发送的数据和发送时间。UDP没有拥塞控制，因此网络中的拥塞不会影响主机的发送效率。某些实时应用要求以稳定的速度发送，能容忍一些数据的丢失，但不允许有较大的时延，而UDP正好满足这些应用的需求。UDP常用于一次性传输较少数据的网络应用如DNS、SNMP等，因为对此应用，若采用TCP，则将为连接创建、维护和拆除带来不小的开销。UDP也常用于多媒体应用，显然，可靠数据传输对这些应用来说并不是最重要的，但TCP的拥塞控制会导致数据出现较大的延迟，这是它们不可容忍的。
UDP提供尽最大努力的交付，即不保证可靠交付，但这并不意味着应用对数据的要求是不可靠的，因此所有维护传输可靠性的工作需要用户在应用层来完成。应用实体可以根据应用的需求来灵活设计自己的可靠性机制。
3、TCP协议？
TCP是在不可靠的IP层之上实现的可靠的数据传输协议，它主要解决传输的可靠、有序、无丢失和不重复问题。TCP是TCP/IP体系中非常复杂的一个协议，主要特点如下：
1>TCP是面向连接的传输层协议。
2>每条TCP连接只能有两个端点，每条TCP连接只能是点对点的。
3>TCP提供全双工通信，允许通信双方的应用进程在任何时候都能发送数据，为此TCP连接的两端都设有发送数据和接受缓存，用来临时存放双向通信的数据。
发送缓存用来暂时存放以下数据：（1）发送应用程序传送给发送方TCP准备发送的数据；（2）TCP已发送但尚未收到确认的数据。
接收缓存用来暂时存放以下数据：（1）按序到达但尚未被接收应用程序收取的数据；（2）不按序到达的数据。
TCP连接的建立：
在TCP连接建立的过程中，要解决以下三个问题：
（1）要使每一方都能够确知对方的存在。
（2）要允许双方协商一些参数。
（3）能够对运输实体资源进行分配。
三次握手建立连接：
第一步：客户机的TCP首先向服务器的TCP发送一个连接请求报文段。这个特殊的报文段中不含应用层数据，其首部中的SYN标志位被置为1.另外，客户机会随机选择一个起始序号seq=x。
第二步：服务器的TCP收到连接请求报文段后，如同意建立连接，就向客户机发回确认，并为该TCP连接分配TCP缓存和变量。在确认报文段中，SYN和ACK位都被置为1，确认号字段的值为x+1，并且服务器随机产生起始序号seq=y。确认报文段同样不包含应用层数据。
第三步：当客户机收到确认报文段后，还要向服务器给出确认，并且也要给该连接分配缓存和变量。这个报文段的ACK标志位被置1，序号段为x+1，确认号字段ack=y+1。该报文段可以携带数据，若不携带数据则不消耗序号。
成功进行以上三步后，就建立了TCP连接，接下来就可以传送应用层数据。TCP提供的是全双工通信，因此通信双方的应用进程在任何时候都能发送数据。另外，值得注意的是，服务器端的资源是在完成第二次握手时分配的，而客户端的资源是在完成第三次握手时分配的，这就使得服务器易于受到SYN洪泛攻击。
四次握手释放连接：
4、拥塞控制的四种算法？
所谓拥塞控制，是指防止过多的数据注入网络，保证网络中的路由器或链路小致过载。出现拥塞时，端点并不了解到拥塞发生的细节，对通信连接的端点来说，拥塞往往表现为通信时延的增加。当然，拥塞控制和流量控制也有相似的地方，即它们都通过控制发送方发送数据的速率来达到控制效果。
拥塞控制与流量控制的区别：拥塞控制是让网络能够承受现有的网络负荷，是一个全局性的过程，涉及所有的主机、所有的路由器，以及与降低网络传输性能有关的所有因素。相反，流量控制往往是指点对点的通信量的控制，即接收端控制发送端，它所要做的是抑制发送端发送数据的速率，以便使接收端来得及接收。
（1）慢开始算法（接收窗口rwnd，拥塞窗口cwnd）
在TCP刚刚连接好并开始发送TCP报文段时，先令拥塞窗口cwnd=1，即一个最大报文段长度MSS。每收到一个对新报文段的确认后，将cwnd加1，即增大一个MSS。用这样的方法逐步增大发送方的拥塞窗口cwnd，可使分组注入网络的速率更加合理。使用慢开始算法后，每经过一个传输轮次，拥塞窗口cwnd就会加倍，即cwnd的大小指数式增长。这样，慢开始一直把拥塞窗口cwnd增大到一个规定的慢开始门限ssthresh，然后改用拥塞避免算法。
（2）拥塞避免算法
拥塞避免算法的做法如下：发送端的拥塞窗口cwnd每经过一个往返时延RTT就增加一个MSS的大小，而不是加倍，使cwnd按线性规律缓慢增长，而当出现一次超时时，令慢开始门限ssthresh等于当前cwnd的一半。
（3）快重传
快重传技术使用了冗余ACK来检测丢包的发生。同样，冗余ACK也用于网络拥塞的检测。快重传并非取消重传计时器，而是在某些情况下可更早地重传丢失的报文段。当发送方连续收到三个重复的ACK报文时，直接重传对方尚未收到的报文段，而不必等待那个报文段设置的重传计时器超时。
（4）快恢复
快恢复算法的原理如下：发送端收到连续三个冗余ACK时，执行“乘法减小”算法，把慢开始门限ssthresh设置为出现拥塞时发送方cwnd的一半。与慢开始的不同之处是，它把cwnd的值设置为慢开始门限ssthresh改变后的数值，然后开始执行拥塞避免算法使用拥塞窗口缓慢地线性增大。由于跳过了cwnd从1起始的慢开始过程，所以被称为快恢复。
5、为何不采用“三次握手”释放连接，且发送最后一次握手报文后要等待2MSL的时间呢？
原因有两个：
（1）保证A发送的最后一个确认报文段能够到达B。如果A不等待2MSL，若A返回的最后确认报文段丢失，则B不能进入正常关闭状态，而A此时已经关闭，也不可能再重传。
（2）防止出现“已失效的连接请求报文段”。A在发送最后一个确认报文段后，在经过2MSL可保证本次连接持续的时间内所产生的所有报文段从网络中消失。
服务器结束TCP连接的时间要比客户机早一些，因为客户机最后要等待2MSL后可进入CLOSED状态。
6、为什么不采用“两次握手”建立连接呢？
这主要是为了防止两次握手情况下已失效的连接请求报文段突然又传送到服务器而产生错误。考虑下面这种情况。客户A向服务器B发出TCP连接请求，第一个连接请求报文在网络的某个结点长时间滞留，A超时后认为报文丢失，于是再重传一次连接请求，B收到后建立连接。数据传输完毕后双方断开连接。而此时，前一个滞留在网络中的连接请求到达服务器B，而B认为A又发来连接请求，此时若使用“三次握手”，则B向A返回确认报文段，由于是一个失效的请求，因此A不予理睬，建立连接失败。若采用的是“两次握手”，则这种情况下B认为传输连接已经建立，并一直等待A传输数据，而A此时并无连接请求，因此不予理睬，这样就造成了B的资源白白浪费。