TCP与UDP必考题

问题及解答：
1.端口(port)和套接字(socket)的区别是什么？
2.是否TCP和UDP都需要计算往返时间RTT？
3.在TCP传送数据时，有没有规定一个最大重传次数？
4.为什么TCP在建立连接时不能每次都选择相同的、固定的初始序号？
5.TCP连接很像一条连接发送端和接收端的双向管道。

当TCP在连续发送报文段时，若要管道得到充分的利用，则发送窗口的大小应怎样选择？
6.TCP发送方和接收方都需要滑动窗口吗？各有什么作用？
7.滑动窗口的窗口大小可以动态调整吗？调整窗口大小可以起到什么作用？
8.在UDP协议中需要滑动窗口协议吗？为什么？这样有什么好处有什么坏处？
1.端口(port)和套接字(socket)的区别是什么？
答：套接字包含了端口，因为套接字= (IP地址，端口号)。

套接字是TCP连接的端点。

套接字又称为“插口”。

但我们已经讲过，套接字(socket)有多种意思。

当使用API时，套接字往往被看成是操作系统的一种抽象，这时，套接字和一个文件描述符是很相似的，并且是应用编程接口API 的一部分。

套接字由应用程序产生，并指明它将由客户还是服务器来使用。

当应用进程创建一个套接字时，要指明该套接字使用的端口号。

端口则是应用层服务的的一种代号，它用来标志应用层的进程。

端口是一个16 bit的整数。

各种服务器使用的端口号都是保留端口号，以便使客户能够找到服务器。

例如万维网服务器使用的端口号是80。

在发送数据时，应用层的数据通过端口向下交付到运输层。

在接收数据时，运输层的数据通过适当的端口向上交付到应用层的某个应用程序
2.是否TCP和UDP都需要计算往返时间RTT？
答：TCP有的，UDP没有的，UDP发出去其实就不管了，它是需要在应用软件（应用层）来做一个数据传送保障的机制的。

重发也是通过软件端实现。

TCP本身协议就具有保障数据的功能。

3.在TCP传送数据时，有没有规定一个最大重传次数？
答：我们知道以太网规定重传16次就认为传输失败，然后报告上层。

但TCP没有规定最大重传次数，而是通过设置一些计时器来解决有关传输失败的问题
4.为什么TCP在建立连接时不能每次都选择相同的、固定的初始序号？
答：从理论上讲是可能会出现这种状况的。

但概率太小了。

序列号的范围在0-2的32次方之间。

建立tcp的双方是独立随机在其中选取的。

所以基本上认为双方不会选择到相同的序列号。

5.TCP连接很像一条连接发送端和接收端的双向管道。

当TCP在连续发送报文段时，若要管道得到充分的利用，则发送窗口的大小应怎样选择？
答：我们可以用下面的图来说明这一问题。

图中在发送端和接收端之间的两个白色长条表示TCP全双工通信的发送管道和接收管道。

管道是对信道的一种抽象，便于讨论问题（可以不涉及下层互连网络的细节）。

假定在t = 0时发送端使用慢开始算法来发送报文段，因此在t = 0时只能发送一个报文段（图中标有1的绿色长方条就代表报文段1）。

图中的时间都是按离散的时间单位表示。

为简化分析，我们还假定，发送窗口仅由发送端的拥塞窗口来确定，接收端不对发送窗口加以限制。

1
1
1
2
2
2 3
3
3
3
1
t= 1
t= 2
t= 3
t= 4
1 t= 6
t= 7
t= 8 t= 9
1
1
1
发送端接收端
2
2
2
2
2
发送端接收端
t= 11
t= 12
t= 13
t= 14
t= 15
t= 17
t= 18
t= 19
3
3
3
1
t= 5
2
t= 16
3
假定在t = 1时，报文段1的第一个比特正好走完四分之一的管道，同时该报文段的最后一个比特正好发送完毕。

t = 4，报文段1的前沿到达接收端。

t = 5时，接收端将报文段1接收完毕。

假定接收端立即发送确认报文段。

我们所用的标记是：对报文段n的确认报文段我们用具有标记n的红色小长方条表示。

t = 9，对报文段1的确认的前沿到达发送端。

t = 10，发送端将发送窗口加1变为2（可以发送报文段2和3），并开始发送报文段2（这一步图中省略了，没有画出）。

t = 11，报文段2走完发送管道的四分之一，发送端开始发送报文段3。

t = 12，报文段2和3填满发送管道的一半。

t = 14，报文段2的前沿到达接收端。

t = 15，接收端收完报文段2，并发送对报文段2的确认。

t = 16，接收端收完报文段3，并发送对报文段3的确认。

t = 19，对报文段2的确认前沿传播到发送端。

t = 20，发送端收到对报文段2的确认，将发送窗口加1变为3（可以发送报文段4, 5和6），并开始发送报文段4（这一步图中省略了，没有画出）。

对报文段3的确认的前沿也在这个时间传播到发送端。

再以后的过程我们用下面的另一张图来说明。

t = 21，发送端收到对报文段3的确认，将发送窗口再加1变为4（可以发送报文段4, 5, 6和7），并开始发送报文段5。

此时，报文段4已完全进入发送管道，前沿到了管道的四分之一处。

15
8
88
9
99
1010
10
1111
11121212
121313
13
1414
8
910114
4
4
4
5
5
5
6
6
6
7
7
7
5
67t = 21
t = 22
t = 23
t = 24
4
t = 25
t = 27
t = 28
t = 29
4
4
4
发送端接收端
发送端
接收端
t = 30
t = 31
t = 32
t = 33
t = 34
t = 36
t = 37
t = 38
8
8
8
5
5
5
66
7
5
6
7
6
77
9
9
10
4
56
7
t = 26
8
9
10t = 35
11
以后的过程读者自己都可以看懂。

这里只再提几点。

发送端每收到一个对没有确认过的报文段的确认，就将发送窗口加1。

因此在陆续收到确认4 ~ 7后，将发送窗口加4，即增大到8，可以连续发送报文段8 ~ 15。

管道空间是有限的。

从图中表示的例子可以看出，这样的管道至多可容纳4个报文段。

当发送窗口很小时，管道在大部分时间内是比较空的（见前面的第一张图）。

这说明在TCP 连接中传输数据的效率比较低。

当发送窗口增大时，管道逐渐被填满。

可以看出，在t = 34 ~ 38时，发送管道一直是被填满的，这说明发送管道被利用得很充分。

因为报文段的传输需要时间，因此对报文段的确认总是会滞后一段时间。

上面的例子表明，在单方向发送报文段（另一个方向发送确认）的情况下，发送管道和接收管道往往不能同时被充分利用（除非发送窗口的数值较大）。

但如果双向都能发送数据报文段，那么发送管道和接收管道就都能够被利用得较充分。

我们还可看出，接收管道（即接收端发送确认报文段的管道）在任何情况下都没有填满。

这是因为确认报文段很短，只需很短的时间就可发送出去。

但接收一个数据报文段需要较多的时间，这就造成确认报文段不可能连续地从接收端发送出去。

6.TCP 发送方和接收方都需要滑动窗口吗？各有什么作用？
答：发送方和接受方都维持了一个窗口，窗口内部包含了那些可以接受的序列号。

发送方的窗口大小从0开始，以后可以增大到某一个预设的最大值。

由于发送方可能在将
来的某个时刻重传未被确认的帧，所以它必须把已经送出去的帧保留一段时间，直到他知道接受方已经接受了这些帧。

当第n帧的确认到来时，第n-1,第n-2等也都被自动地确认了。

接受方的窗口总是固定大小的。

接受方为其窗口内的每一个序列号保留了一个缓冲区。

与每个缓冲区相连关联的还有一位，用来指明该缓冲区是满的还是空的。

任何时候当一帧到达时，接受方通过between函数检查它的序列号，看是否落在窗口内。

如果确实落在窗口内，并且以前还没有收到这一帧，则接受该帧，并且保存起来
7.滑动窗口的窗口大小可以动态调整吗？调整窗口大小可以起到什么作用？
答：理论上是可以动态调整的，但具体要要看设备。

一般稍微好点的设备都会支持的。

作用：调节收发双方的速度问题。

如：发端快一点10MP/S但收端接受速度慢，那么如果发端一直都不去调整，那么后面的帧就会把前面发的帧给淹没。

8.在UDP协议中需要滑动窗口协议吗？为什么？这样有什么好处有什么坏处？
答：UDP不需要，UDP不是基于连接的，接受方无法控制发送方，只要知道接受方的地址就尽力地给它发数据。

好处是发送速度效率高，缺点是不保证传输的可靠性。