搜索
问题5-1：TCP协议是面向连接的，但TCP使用的IP协议却是无连接的。这两种协议都有哪些主要的区别？答：这个问题很重要，一定要弄清楚。TCP是面向连接的，但TCP所使用的网络则可以是面向连接的（如X.25网络），但也可以是无连接的（如现在大量使用的IP网络）。选择无连接网络就使得整个的系统非常灵活，当然也带来了一些问题。下面是TCP和IP向上提供的功能和服务的比较。TCP提供的IP提供的面向连接服务无连接服务字节流接口IP数据报接口有流量控制无流量控制有拥塞控制无拥塞控制保证可靠性：不保证可靠性无丢失可能丢失无重复可能重复按序交付可能失序显然，TCP提供的功能和服务要比IP所能提供的多得多。这是因为TCP使用了诸如确认、窗口通知、计时器等机制，因而可以检测出有差错的报文、重复的报文和失序的报文。问题5-2：从通信的起点和终点来比较，TCP和IP的不同点是什么？答：用下面的图就可说明。进程A和进程B的通信是使用面向连接的TCP提供的可靠的传输。主机X和主机Y的通信是使用无连接的IP提供的不可靠的传输。请注意：对TCP来说，通信的起点和终点是运输层上面的两个套接字(socket)，而应用层的应用进程正是通过应用层和运输层之间的套接字来使用TCP提供的服务。TCP协议根据报文段首部中的端口号找到目的端口，将报文段交付给目的进程。请注意：套接字是由IP地址和端口号决定的，套接字也可称为“插口”。对IP来说，通信的起点和终点是连接在网络上的两个主机。IP协议根据数据报首部中的目的IP地址找到目的主机，将数据报交付给目的主机。请注意可靠传输的范围和不可靠传输的范围是不同的。我们还应当注意的是：虽然在两个套接字之间的通信是面向连接的，但IP数据报在下面的网络中传输时是独立地选择路由，而不是沿着某一条固定的路径传输。然而在上面的端口看来，TCP报文段好像都是从一个虚拟的、可靠的通信管道中传输到对方的端口。问题5-3：端口(port)和套接字(socket)的区别是什么？答：从本书经常使用的套接字定义来看，套接字包含了端口，因为套接字=(IP地址，端口号)。套接字是TCP连接的端点。套接字又称为“插口”。但我们已经讲过，套接字(socket)有多种意思。当使用API时，套接字往往被看成是操作系统的一种抽象，这时，套接字和一个文件描述符是很相似的，并且是应用编程接口API的一部分。套接字由应用程序产生，并指明它将由客户还是服务器来使用。当应用进程创建一个套接字时，要指明该套接字使用的端口号。端口则是应用层服务的的一种代号，它用来标志应用层的进程。端口是一个16bit的整数。各种服务器使用的端口号都是保留端口号，以便使客户能够找到服务器。例如万维网服务器使用的端口号是80。在发送数据时，应用层的数据通过端口向下交付到运输层。在接收数据时，运输层的数据通过适当的端口向上交付到应用层的某个应用程序。问题5-4：一个套接字能否同时与远地的两个套接字相连？答：不行。一个套接字只能和另一个远地套接字相连。如果许多个客户同时访问同一个服务器，那么对于这种情况，请参考教材的第6章的图6-30及相应的文字解释。问题5-5：数据链路层的HDLC协议和运输层的TCP协议都使用滑动窗口技术。从这方面来进行比较，数据链路层协议和运输层协议的主要区别是什么？答：运输层的TCP协议是端到端（进程到进程）的协议，而数据链路层的HDLC协议则是仅在一段链路上的结点到结点的协议。此外，TCP的窗口机制和HDLC的也有许多区别。如TCP是按数据部分的字节数进行确认，而HDLC则是以帧为确认的单位。需要注意的是，现在使用得最多的PPP链路层协议并不使用确认机制和窗口机制。因此像PPP协议这样的链路层协议就和运输层协议有相当大的区别。问题5-6：TCP协议能够实现可靠的端到端传输。在数据链路层和网络层的传输还有没有必要来保证可靠传输呢？答：在旧的OSI体系中，在数据链路层使用HDLC协议而在网络层使用X.25协议，这些协议都有确认机制和窗口机制，因而能够保证可靠传输。但是技术的进步使得链路的传输已经相当可靠了，因此在数据链路层和网络层重复地保证可靠传输就显得多余了。现在因特网在链路层使用的PPP协议和在网络层使用的IP协议都没有确认机制和窗口机制。如果出现差错就由运输层的TCP来处理（若使用UDP协议则运输层也不处理出错的问题）。问题5-7：在TCP报文段的首部中只有端口号而没有IP地址。当TCP将其报文段交给IP层时，IP协议怎样知道目的IP地址呢？答：显然，仅从TCP报文段的首部是无法得知目的IP地址。因此，TCP必须告诉IP层此报文段要发送给哪一个目的主机（给出其IP地址）。此目的IP地址填写在IP数据报的首部中。问题5-8：在TCP传送数据时，有没有规定一个最大重传次数？答：我们知道以太网规定重传16次就认为传输失败，然后报告上层。但TCP没有规定最大重传次数，而是通过设置一些计时器来解决有关传输失败的问题。问题5-9：TCP都使用哪些计时器？答：TCP共使用以下四种计时器，即重传计时器、持续计时器、保活计时器和时间等待计时器。这几个计时器的主要特点如下：重传计时器当TCP发送报文段时，就创建该特定报文段的重传计时器。可能发生两种情况：1.若在计时器截止时间到之前收到了对此特定报文段的确认，则撤销此计时器。2.若在收到了对此特定报文段的确认之前计时器截止期到，则重传此报文段，并将计时器复位。持续计时器为了对付零窗口大小通知，TCP需要另一个计时器。假定接收TCP宣布了窗口大小为零。发送TCP就停止传送报文段，直到接收TCP发送确认并宣布一个非零的窗口大小。但这个确认可能会丢失。我们知道在TCP中，对确认是不需要发送确认的。若确认丢失了，接收TCP并不知道，而是会认为它已经完成任务了，并等待着发送TCP接着会发送更多的报文段。但发送TCP由于没有收到确认，就等待对方发送确认来通知窗口的大小。双方的TCP都在永远地等待着对方。要打开这种死锁，TCP为每一个连接使用一个持续计时器。当发送TCP收到一个窗口大小为零的确认时，就启动持续计时器。当持续计时器期限到时，发送TCP就发送一个特殊的报文段，叫做探测报文段。这个报文段只有一个字节的数据。它有一个序号，但它的序号永远不需要确认；甚至在计算对其他部分的数据的确认时该序号也被忽略。探测报文段提醒接收TCP：确认已丢失，必须重传。持续计时器的值设置为重传时间的数值。但是，若没有收到从接收端来的响应，则需发送另一个探测报文段，并将持续计时器的值加倍和复位。发送端继续发送探测报文段，将持续计时器设定的值加倍和复位，直到这个值增大到门限值（通常是60秒）为止。在这以后，发送端每隔60秒就发送一个探测报文段，直到窗口重新打开。保活计时器保活计时器使用在某些实现中，用来防止在两个TCP之间的连接出现长时期的空闲。假定客户打开了到服务器的连接，传送了一些数据，然后就保持静默了。也许这个客户出故障了。在这种情况下，这个连接将永远地处理打开状态。要解决这种问题，在大多数的实现中都是使服务器设置保活计时器。每当服务器收到客户的信息，就将计时器复位。超时通常设置为2小时。若服务器过了2小时还没有收到客户的信息，它就发送探测报文段。若发送了10个探测报文段（每一个相隔75秒）还没有响应，就假定客户出了故障，因而就终止该连接。时间等待计时器时间等待计时器是在连接终止期间使用的。当TCP关闭一个连接时，它并不认为这个连接马上就真正地关闭了。在时间等待期间中，连接还处于一种中间过渡状态。这就可以使重复的FIN报文段（如果有的话）可以到达目的站因而可将其丢弃。这个计时器的值通常设置为一个报文段的寿命期待值的两倍。问题5-10：是否TCP和UDP都需要计算往返时间RTT？答：往返时间RTT只是对运输层的TCP协议才很重要，因为TCP要根据平均往返时间RTT的值来设置超时计时器的超时时间。UDP没有确认和重传机制，因此RTT对UDP没有什么意义。因此，不要笼统地说“往返时间RTT对运输层来说很重要”，因为只有TCP才需要计算RTT，而UDP不需要计算RTT。问题5-11：假定TCP开始进行连接建立。当TCP发送第一个SYN报文段时，显然无法利用教材中5.6.3节所介绍的方法计算往返时间RTT。那么这时TCP又怎样设置重传计时器呢？答：这时TCP显然无法利用已有的公式算出往返时间RTT。实际上TCP是选择（也就是猜测）一个比较长的时间作为初始的往返时间RTT。等到收到至少一个确认报文段时才能利用公式计算出比较合理的往返时间RTT。问题5-12：糊涂窗口综合症产生的条件是什么？是否只有在接收方才产生这种症状？答：糊涂窗口综合症产生的条件是：当发送应用程序产生数据很慢，或者接收应用程序吸收数据很慢，或者两者都有。因此发送方和接收方都可能产生这种症状。不管是上述情况中的哪一种，都使得发送数据的报文段很小，这就引起操作效率的降低。例如，若TCP发送的报文段只包括一个字节的数据，则意味着我们发送41字节的数据报（20字节的TCP首部和20字节的IP首部）才传送1字节的数据。数据的传送效率是1/41，它表示我们非常低效率地使用网络的容量。问题5-13：能否更详细些讨论一下糊涂窗口综合症及其解决方法？答：发送端产生的症状如果发送端为产生数据很慢的应用程序服务，例如，一次产生一个字节。这个应用程序一次将一个字节的数据写入发送端的TCP的缓存。如果发送端的TCP没有特定的指令，它就产生只包括一个字节数据的报文段。结果有很多41字节的IP数据报就在互连网中传来传去。解决的方法是防止发送端的TCP逐个字节地发送数据。必须强迫发送端的TCP收集数据，然后用一个更大的数据块来发送。发送端的TCP要等待多长时间呢？如果它等待过长，它就会使整个的过程产生较长的时延。如果它的等待时间不够长，它就可能发送较小的报文段。Nagle找到了一个很好的解决方法。Nagle算法Nagle算法非常简单，但它能解决问题。这个算法是为发送端的TCP用的：1.发送端的TCP将它从发送应用程序收到的第一块数据发送出去，哪怕只有一个字节。2.在发送第一个报文段（即报文段1）以后，发送端的TCP就在输出缓存中积累数据，并等待：或者接收端的TCP发送出一个确认，或者数据已积累到可以装成一个最大的报文段。在这个时候，发送端的TCP就可以发送这个报文段。3.对剩下的传输，重复步骤2。这就是：如果收到了对报文段x的确认，或者数据已积累到可以装成一个最大的报文段，那么就发送下一个报文段(x+1)。Nagle算法的优点就是简单，并且它考虑到应用程序产生数据的速率，以及网络运输数据的速率。若应用程序比网络更快，则报文段就更大（最大报文段）。若应用程序比网络慢，则报文段就较小（小于最大报文段）。接收端产生的症状接收端的TCP可能产生糊涂窗口综合症，如果它为消耗数据很慢的应用程序服务，例如，一次消耗一个字节。假定发送应用程序产生了1000字节的数据块，但接收应用程序每次只吸收1字节的数据。再假定接收端的TCP的输入缓存为4000字节。发送端先发送第一个4000字节的数据。接收端将它存储在其缓存中。现在缓存满了。它通知窗口大小为零，这表示发送端必须停止发送数据。接收应用程序从接收端的TCP的输入缓存中读取第一个字节的数据。在入缓存中现在有了1字节的空间。接收端的TCP宣布其窗口大小为1字节，这表示正渴望等待发送数据的发送端的TCP会把这个宣布当作一个好消息，并发送只包括一个字节数据的报文段。这样的过程一直继续下去。一个字节的数据被消耗掉，然后发送只包含一个字节数据的报文段。这又是一个效率问题和糊涂窗口综合症（见下图）。发送端缓存被填满40003999接收端seq=1001,DATA=4000Back=5001,win=0缓存ack=5001,win=1seq=5001,DATA=1B4000应用程序读取1字节tt缓存又被填满赶快告诉发送端：我现在有1字节的空闲库存空间！对于这种糊涂窗口综合症，即应