计算机网络实验tcp和udp

‘壹’ TCP和UDP的区别

首先TCP是面向连接的，UDP是无需连接的，TCP有着三握四挥，并且三次握手和四次挥手是对TCP建立的连接有着重要意义的两步，并且TCP是对IP无可靠性提供可靠性的源头，UDP继承了IP的特性，不保证不丢失包，不保证按顺序到达

TCP面向字节流，发送的时候是一个流，没有头尾，IP包不是一个流，而是一个个的IP包，UDP也是如此

TCP是有拥塞控制的，但是UDP没有

MAC层去掉之后，IP层首部会有一个8位的协议，这里会存放着数据里到底是TCP还是UDP，当然这里是UDP，如果我们知道UDP格式就可以解析出来了

下一步就通过UDP包中的目标端口号，将这个包交给应用程序处理

源端口和目标端口不可少，包的序号是为了解决乱序问题，为了解决包的先后顺序，还有就是确认序号，发出去的包要有确认，不然无法知道是否收到，若没有收到就要重新发送，直到送达，这就是TCP的不丢包的实质

对于TCP来说，IP层丢不丢包管不着，但是在TCP层，会努力保证可靠性

一开始，客户端和服务端都处于CLOSED状态，先是服务端主动监听某个端口，处于LISTEN状态，然后客户端主动发起连接SYN，之后处于SYN-SENT状态，服务端收到发起的连接，返回SYN，并且ACK客户端的SYN，之后处于SYN-RCVD状态。客户端收到服务端发送的SYN和ACK之后，发送ACK的ACK，之后处于ESTABLISHED状态，因为它一发一收成功了，服务端收到ACK的ACK之后，处于ESTABLISHED，因为它也一发一收了

所以三次握手就能确认双发收发功能都正常，缺一不可。

最后客户端A的TIME-WAIT状态时间要足够长，长到如果B没有收到ACK的话，B会再次发送FIN关闭连接，A会重新发送一个ACK并且时间足够长到这个包到B

A如果直接跑路的话，它的端口就空出来了，但是B不知道，原来发的包如果在路上，但是这时突然另一个应用开启在了这个端口上，那不就混乱了，所以A也需要等待足够时间，等到B发送的包在网络中挂掉之后再空出端口来

等待时间设置为2MSL，报文最大的生存时间，协议规定MSL为2分钟，实际应用中常用的是30s，1分钟和2分钟等

为了记录所有发送的包和接收的包，TCP也需要发送端和接收端分别都有缓存来保存这些记录，发送端的缓存里是按照包的ID一个个排列，根据处理情况分为下面四个部分

在TCP里，接收端会给发送端报一个窗口的大小，叫做Advertised window，这个 窗口大小 应该等于上面说的第二部分加上第三部分也就是 已经发送了但是没有得到确认的加上还没有发送，并且正在准备发送的 ，超过这个窗口的，接收端忙不过来，就不能发送了

第二部分的窗口有多大？

NextByteExpected 和 LastByteRead的差其实是还没有被应用层读取的部分占用调MaxRcvBuffer的量，定义为A， 窗口大小其实是MaxRcvBuffer减去A

其中第二部分里面，由于收到的包可能不是顺序的，会出现空档， 只有和第一部分连续的，可以马上进行回复 ，中间空着的部分需要等待，哪怕后面的已经来了(可以看到接收端的窗口出现了虚线和实线的区别)

发送端

接收端

在 发送端 看来，1、2、3都已经发送并且确认的；4、5、6、7、8、9都是发送了还没有确认；10、11、12是还没有发出的；13、14、15是接收方没有空间不准备发送的

在 接收端 看来，1、2、3、4、5都是已经完成ACK的，但是是没有被应用层读取的；6、7是等待接收的；8、9是已经接收，但是还没有ACK的

当前的状态

假设4的ACK到了，不幸的是5的ACK丢了，6、7的数据包丢失了，这应该怎么做？

对每一个发送了，但是没有ACK的包，都设有一个定时器，超过了一定的时间就重新尝试，但是这个超时的时间如何进行评估呢，这个时间不宜过短，时间必须大于往返时间RTT，否则将会引起不必要的重传，也不宜过长，这样的超时时间变长，访问就变慢了

RTT(Round-Trip Time): 往返时延。在计算机网络中它是一个重要的性能指标，表示从发送端发送数据开始，到发送端收到来自接收端的确认（接收端收到数据后便立即发送确认），总共经历的时延。

估计往返时间需要TCP通过 采样RTT的时间，然后进行加权平均 ，计算出来一个值，并且这个值还是随着网络的状况 不断变化 的，我们成为 自适应重传算法

如果过一段时间，5、6、7都超时了，就会重新发送，接收方发现5原来接受过，于是丢弃5；6收到了，发送ACK，要求下一个是7,7不幸又丢了，当7再次超时的时候，有需要重传的时候， TCP的策略是超时间隔加倍，每当遇到一次超时重传的时候，都会将下一次超时时间间隔设为先前的两倍，两次超时就说明网络环境差，不适合频繁反复发送

超时触发重传存在的问题是，超时周期可能相对较长

有一个 快速重传的机制 ，当接收方收到一个序号大于下一个所期望的报文段时，就检测到了数据流中的一个间隔，于是发送三个冗余的ACK，客户端收到后，在定时器过期之前，重传丢失的报文段

例如，接收方发现6、8、9都已经接收了，7还没来，那肯定是丢了，于是发送三个6的ACK要求下一个是7，客户端收到3个ACK就会发现7的包确实又丢了，不再等待超时，马上重发

SACK ，这种方式需要在TCP头加一个SACK的东西，可以将缓存的地图发送给发送方，例如有了ACK6、ACK8、ACK9就会知道7丢了

在对于包的确认中，同时会携带一个窗口的大小

假设窗口不变，始终为9,4的确认来的时候，会右移一个，这个时候第13个包也可以发送了

这个时候，假设发送端发送过猛，会将第三部分的10、11、12、13全部发送完毕，之后就停止发送了，未发送可发送部分为0

当对于包5的确认到达的时候，在客户端相当于窗口滑动了一格，这个时候才可以有更多的包可以发送了，接下来14可以被发送

如果接收方实在处理太慢，导致缓存中没有了空间，可以通过确认信息修改窗口的大小，甚至可以设置为0，让发送端暂时停止发送

假设接收端应用一直不读取缓存中的数据，当数据包6被确认后，窗口大小就会减小一个变为8

这个时候可以看到，接收端的窗口并没有向右移动，只是简单地将左边的标记右移一格，窗口大小变为8

如果接收端一直不处理数据，则随着确认包越来越多，窗口越来越小直到为0

如果情况变成这样， 发送方会定时发送窗口探测数据包，看看是否有机会调整窗口的大小 ，当接收方比较慢的时候，要防止低能窗口综合征， 不要空出一个字节就告诉发送方 ，然后立马被填满，可以当窗口太小的时候，不更新窗口，直到达到一定大小，或者缓冲区一般为空的时候再更新窗口

拥塞控制同样通过窗口的大小来控制，滑动窗口是为了防止发送方把接收方缓存塞满，而拥塞窗口是为了不把网络填满

LastByteSent - LastByteAcked <= min{滑动窗口， 拥塞窗口}

TCP协议是不知道真个网络路径都是什么，TCP包常被比喻为往一个谁管理灌水TCP拥塞控制就是在不堵塞，不丢包的情况下，尽量发挥带宽

网路通道的容量 = 带宽 x 往返延迟

假设往返时间为8s，发送的过程4s，返回的时间4s，每个包1024byte，过了8s，8个包都发出去了，其中4个已经到达了接收端，但是ACK还在路上，不能算是发送成功了，5-8后四个包还在路上没被接收，这个时候，整个管道刚好被撑满

如果我们在这个基础上再将窗口调大一点，会出现什么现象？

如果从发送端到接收端会经过四个设备，每个设备处理包的时间需要1s，所以4个包的话，总共的处理时间为4s，如果窗口调大，也就有可能增加发送速度，单位时间内，会有更多的包到达这些中间设备，那么处理中的设备会丢弃到多余的包，这是我们不想看到的

这个时候，我们可以为这四台设备增加缓存，处理不过来的包在队列里等待，这样就不会丢失了，但是缺点是会增加时间，在之前我们分析过只需要4s一个包即可到达发送端，但是进入缓存中多余的包肯定到达的时间是要超过4s的，如果这个时候发送方还是没有收到ACK那么就会触发超时重传， TCP的拥塞控制就是为了处理包的丢失和超时重传

一条TCP连接的开始，cwnd设置为一个报文段，一次只能发送一个，当收到这个确认的时候，cwnd +1，于是一次能够发送2个，当这两个的确认到来的时候，每个确认的cwnd + 1 ，两个确认的cwnd就可以 +2，现在可以发送4个， 这是指数级别的增长，但是有一个值sshthresh为65535字节，当超过这个值的时候不要增长得这么快了，可能快满了，再慢下来

于是，每收到一个确认后，cwnd增长1/cwnd，一共发送8个的话，当8个确认到来的时候，每个确认增加1/8，八个确认一共cwnd + 1，于是一次能够发送9个，变成了 线性增长 ，但是肯定有一天会满，这个时候就会出现拥堵，就需要慢慢等待包的处理

拥塞的一种形式是丢包，需要超时重传 ，这个时候

重新开始慢启动，这样的话，只要超时重传就感觉会回到解放前

快速重传 ，当接收端发现丢了一个中间包的时候，发送三次前一个包的ACK，于是发送端就会快速重传，不必等待超时再重传，TCP认为这种情况不严重，因为大部分没丢，只丢了一小部分

正是这种知道该快还是慢的情况下，使得时延很重要的情况下，反而降低了速度，但是 拥塞控制还是存在问题

为了优化这两个问题，有了TCP BBR拥塞算法，它企图找到一个平衡点，通过不断的加快发送速度，将管道填满，但是不会填满中间设备的缓存，因为这样时延会增加，这个平衡的时点可以很好的达到高带宽和低时延的平衡

‘贰’ 计算机网络基础：TCP、UDP协议的简单介绍及区别

TCP（Transmission Control Protocol，传输控制协议），属于TCP/IP协议模型中的 传输层 ，是 基于连接 的协议。
TCP协议通过序列化应答和必要时重发数据包，为应用程序提供了可靠的传输流和虚拟连接服务。

面向连接 指的是在发送数据之前，必须与对方建立可靠的连接，就像打电话一样，你得先拨号，然后保证线路通畅，对方接听了电话，这时才能互相通话。这个建立连接的过程被称作“三次握手”。

妹子：在吗？
（你没有回应……）
GG，你将永远失去她。

妹子：在吗？
（一个小时过去了）
你：在
这时候妹子的问题已经解决了，而你却激动地等待着她的回复。
（她什么时候才能回我啊.jpg）
当然这不是我们想看到的结果

妹子：在吗？（第一次握手）
你：在（第二次握手）
妹子：问你一个问题（第三次握手）
这时，她确定你在，所以会准备问问题，你也确定她在，所以激动紧张的等待没有白费
接下来你们开始愉快地聊天（数据传输）

终止连接的过程称之为“四次挥手”或者“四次分手”（感觉后者不太吉利，以下就用挥手）
继续用刚才的微信发消息来举例：

你：我讲完了， 你懂了吗？（第一次挥手）
妹子：懂了，我也问完了（第二次挥手）
妹子：谢谢谢，那我下了（第三次挥手）
你：好，我也下了（第四次挥手）

如果只有一、二、三次挥手的话，结果很容易自己想到。

建立连接的三次握手，和终止连接的四次挥手，都是为了保证双方应答有效，避免让某一方持续等待接受数据而造成的资源浪费。在例子中体现为，开始聊天时不会咕咕咕，结束时不会突然去世。

UDP（User Datagram Protocol，用户数据报协议），属于TCP/IP模型中的传输层，它是一种 无连接 的传输层协议，提供面向事务的 简单不可靠 信息传送服务。

注：传输可靠指的是，通过拥塞控制、流量控制、超时重发、丢弃重复数据等等可靠性检测手段，保证数据无差错、不丢失、不重复且按序到达。

‘叁’ UDP和TCP有什么区别

1、TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接

2、TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付

Tcp通过校验和，重传控制，序号标识，滑动窗口、确认应答实现可靠传输。如丢包时的重发控制，还可以对次序乱掉的分包进行顺序控制。

3、UDP具有较好的实时性，工作效率比TCP高，适用于对高速传输和实时性有较高的通信或广播通信。

4.每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信

5、TCP对系统资源要求较多，UDP对系统资源要求较少。

‘肆’ 计算机网络——TCP/UDP协议

计算机网络七层模型中，传输层有两个重要的协议：
（1）用户数据报协议UDP (User Datagram Protocol)
（2）传输控制协议TCP (Transmission Control Protocol)

UDP 在传送数据之前不需要先建立连接。远地主机的运输层在收到UDP 报文后，不需要给出任何确认。虽然UDP 不提供可靠交付，但在某些情况下UDP 却是一种最有效的工作方式。

TCP 则提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。TCP 不提供广播或多播服务。由于TCP 要提供可靠的、面向连接的运输服务，因此不可避免地增加了许多的开销，如确认、流量控制、计时器以及连接管理等。

UDP 的主要特点是：

首部手段很简单，只有8 个字节，由四个字段组成，每个字段的长度都是两个字节。

前面已经讲过，每条TCP 连接有两个端点，TCP 连接的端点叫做套接字（socket）或插口。套接字格式如下：

套接宁socket= (IP 地址：端口号’）

每一条TCP 连接唯一地被通信两端的两个端点（即两个套接宇）所确定。即：
TCP 连接＝ {socket1, socket2} = {(IP1: port1), (IP2: port2)}

3次握手链接

4次握手释放链接

断开连接请求可以由客户端发出，也可以由服务器端发出，在这里我们称A端向B端请求断开连接。

各个状态节点解释如下：

下面为了讨论问题的万便，我们仅考虑A发送数据而B 接收数据并发送确认。因此A 叫做发送方，而B 叫做接收方。

“停止等待”就是每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。

使用上述的确认和重传机制，我们就可以在不可靠的传输网络上实现可靠的通信。像上述的这种可靠传输协议常称为自动重传请求ARQ (Automatic Repeat reQuest）。意思是重传的请求是自动进行的。接收方不需要请求发送方重传某个出错的分组。

滑动窗口协议比较复杂，是TCP 协议的精髓所在。这里先给出连续ARQ 协议最基本的概念，但不涉提到许多细节问题。详细的滑动窗口协议将在后面讨论。

下图表示发送方维持的发送窗口，它的意义是：位于发送窗口内的5 个分组都可连续发送出去，而不需要等待对方的确认。这样，信道利用率就提高了。

连续ARQ 协议规定，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。

接收方一般都是采用 累积确认 的方式。这就是说，接收方不必对收到的分组逐个发送确认，而是可以在收到几个分组后，对按序到达的最后一个分组发送确认，这样就表示：到这个分组为止的所有分组都己正确收到了。

累积确认 的优点是容易实现，即使确认丢失也不必重传。但缺点是不能向发送方反映出接收方己经正确收到的所有分组的信息。

例如，如果发送方发送了前5 个分组，而中间的第3 个分组丢失了。这时接收方只能对前两个分组发出确认。发送方无法知道后面三个分组的下落，而只好把后面的三个分组都再重传一次。这就叫做Go-back-N （回退N ），表示需要再退回来重传己发送过的N 个分组。可见当通信线路质量不好时，连续ARQ 协议会带来负面的影响。

TCP 的滑动窗口是以字节为单位的。现假定A 收到了B 发来的确认报文段，其中窗口是20 （字节），而确认号是31 （这表明B 期望收到的下一个序号是31 ，而序号30 为止的数据己经收到了）。根据这两个数据， A 就构造出自己的发送窗口，其位置如图所示。

发送窗口表示：在没有收到B 的确认的情况下， A可以连续把窗口内的数据都发送出去。凡是己经发送过的数据，在未收到确认之前都必须暂时保留，以便在超时重传时使用。

发送窗口后沿的后面部分表示己发送且己收到了确认。这些数据显然不需要再保留了。而发送窗口前沿的前面部分表示不允许发送的，因为接收方都没有为这部分数据保留临时存放的缓存空间。

现在假定A 发送了序号为31 ～ 41 的数据。这时发送窗口位置并未改变，但发送窗口内靠后面有11个字节（灰色小方框表示）表示己发送但未收到确认。而发送窗口内靠前面的9 个字节（ 42 ～ 50 ）是允许发送但尚未发送的。】

再看一下B 的接收窗口。B 的接收窗口大小是20，在接收窗口外面，到30 号为止的数据是已经发送过确认，并且己经交付给主机了。因此在B 可以不再保留这些数据。接收窗口内的序号（31～50）足允许接收的。B 收到了序号为32 和33 的数据，这些数据没有按序到达，因为序号为31 的数据没有收到（也许丢失了，也许滞留在网络中的某处）。 请注意， B 只能对按序收到的数据中的最高序号给出确认，因此B 发送的确认报文段中的确认号仍然是31 （即期望收到的序号）。

现在假定B 收到了序号为31 的数据，并把序号为31～33的数据交付给主机，然后B删除这些数据。接着把接收窗口向前移动3个序号，同时给A 发送确认，其中窗口值仍为20，但确认号是34，这表明B 已经收到了到序号33 为止的数据。我们注意到，B还收到了序号为37, 38 和40 的数据，但这些都没有按序到达，只能先存在接收窗口。A收到B的确认后，就可以把发送窗口向前滑动3个序号，指针P2 不动。可以看出，现在A 的可用窗口增大了，可发送的序号范围是42～53。整个过程如下图：

A 在继续发送完序号42-53的数据后，指针P2向前移动和P3重合。发送窗口内的序号都已用完，但还没有再收到确认。由于A 的发送窗口己满，可用窗口己减小到0，因此必须停止发送。

上面已经讲到， TCP 的发送方在规定的时间内没有收到确认就要重传已发送的报文段。这种重传的概念是很简单的，但重传时间的选择却是TCP 最复杂的问题之一。

TCP采用了一种自适应算法 ，它记录一个报文段发出的时间，以及收到相应的确认的时间。这两个时间之差就是报文段的往返时间RTT，TCP 保留了RTT的一个加权平均往返时间RTTs （这又称为平滑的往返时间， S 表示Smoothed 。因为进行的是加权平均，因此得出的结果更加平滑）。每当第一次测量到RTT样本时， RTTs值就取为所测量到的RTT样本值。但以后每测量到一个新的RTT样本，就按下式重新计算一次RTTs:

新的RTTs = (1 － α）×（旧的RTTs) ＋ α ×（新的RTT样本）

α 越大表示新的RTTs受新的RTT样本的影响越大。推荐的α 值为0.125，用这种方法得出的加权平均往返时间RTTs 就比测量出的RTT值更加平滑。

显然，超时计时器设置的超时重传时间RTO (RetransmissionTime-Out）应略大于上面得出的加权平均往返时间RTTs。RFC 2988 建议使用下式计算RTO:

RTO = RTTs + 4 × RTTd

RTTd是RTT 的偏差的加权平均值，它与RTTs和新的RTT样本之差有关。计算公式如下：

新的RTTd= (1- β）×（旧的RTTd) + β × |RTTs－新的RTT样本|

发现问题： 如图所示，发送出一个报文段。设定的重传时间到了，还没有收到确认。于是重
传报文段。经过了一段时间后，收到了确认报文段。现在的问题是：如何判定此确认报文段是对先发送的报文段的确认，还是对后来重传的报文段的确认？

若收到的确认是对重传报文段的确认，但却被源主机当成是对原来的报文段的确认，则这样计算出的RTTs 和超时重传时间RTO 就会偏大。若后面再发送的报文段又是经过重传后才收到确认报文段，则按此方法得出的超时重传时间RTO 就越来越长。

若收到的确认是对原来的报文段的确认，但被当成是对重传报文段的确认，则由此计算出的RTTs 和RTO 都会偏小。这就必然导致报文段过多地重传。这样就有可能使RTO 越来越短。

Kam 提出了一个算法：在计算加权平均RTTs 时，只要报文段重传了就不采用其往返时间样本。这样得出的加权平均RTTs 和RTO 就较准确。

新问题： 设想出现这样的情况：报文段的时延突然增大了很多。因此在原来得出的重传时间内，不会收到确认报文段。于是就重传报文段。但根据Kam 算法，不考虑重传的报文段的往返时间样本。这样，超时重传时间就无法更新。

解决方案： 对Kam 算法进行修正，方法是z报文段每重传一次，就把超时重传时间RTO 增大一些。典型的做法是取新的重传时间为2 倍的旧的重传时间。当不再发生报文段的重传时，才根据上面给出的公式计算超时重传时间。

流量控制（flow control）就是让发送方的发送速率不要太快，要让接收方来得及接收。

利用滑动窗口机制可以很方便地在TCP 连接上实现对发送方的流量控制。

接收方的主机B 进行了三次流量控制。第一次把窗口减小到rwnd =300，第二次又减到rwnd = 100 ，最后减到rwnd = 0 ，即不允许发送方再发送数据了。这种使发送方暂停发送的状态将持续到主机B 重新发出一个新的窗口值为止。我们还应注意到，B 向A 发送的三个报文段都设置了ACK=1，只有在ACK=1 时确认号字段才有意义。

发生死锁： 现在我们考虑一种情况。上图中， B 向A 发送了零窗口的报文段后不久， B 的接收缓存又有了一些存储空间。于是B 向A 发送了rwnd = 400 的报文段。然而这个报文段在传送过程中丢失了。A 一直等待收到B 发送的非零窗口的通知，而B 也一直等待A 发送的数据。如果没有其他措施，这种互相等待的死锁局面将一直延续下去。

解决方案： TCP 为每一个连接设有一个 持续计时器（persistence timer） 。只要TCP 连接的一方收到对方的零窗口通知，就启动持续计时器。若持续计时器设置的时间到期，就发送一个 零窗口探测报文段 （仅携带1 宇节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。

1 TCP连接时是三次握手，那么两次握手可行吗？

在《计算机网络》中是这样解释的：已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送ACK包。这样就会白白浪费资源。而经过三次握手，客户端和服务器都有应有答，这样可以确保TCP正确连接。

2 为什么TCP连接是三次，挥手确是四次？

在TCP连接中，服务器端的SYN和ACK向客户端发送是一次性发送的，而在断开连接的过程中，B端向A端发送的ACK和FIN是是分两次发送的。因为在B端接收到A端的FIN后，B端可能还有数据要传输，所以先发送ACK，等B端处理完自己的事情后就可以发送FIN断开连接了。

3 为什么在第四次挥手后会有2个MSL的延时？

MSL是Maximum Segment Lifetime，最大报文段生存时间，2个MSL是报文段发送和接收的最长时间。假定网络不可靠，那么第四次发送的ACK可能丢失，即B端无法收到这个ACK，如果B端收不到这个确认ACK，B端会定时向A端重复发送FIN，直到B端收到A的确认ACK。所以这个2MSL就是用来处理这个可能丢失的ACK的。

1 文件传送协议

文件传送协议FTP (File Transfer Protocol) [RFC 959］是因特网上使用得最广泛的文件传送协议，底层采用TCP协议。

盯P 使用客户服务器方式。一个FTP 服务器进程可同时为多个客户进程提供服务。FTP的服务器进程由两大部分组成：一个主进程，负责接受新的请求：另外有若干个从属进程，负责处理单个请求。

在进行文件传输时，客户和服务器之间要建立两个并行的TCP 连接：“控制连接”（21端口）和“数据连接”（22端口）。控制连接在整个会话期间一直保持打开， FTP 客户所发出的传送请求，通过控制连接发送给服务器端的控制进程，但控制连接并不用来传送文件。实际用于传输文件的是“数据连接”。服务器端的控制进程在接收到FTP 客户发送来的文件传输请求后就创建“数据传送进程”和“数据连接”，用来连接客户端和服务器端的数据传送进程。

2 简单文件传送协议TFTP

TCP/IP 协议族中还有一个简单文件传送协议TFfP (Trivial File Transfer Protocol），它是一个很小且易于实现的文件传送协议，端口号69。

TFfP 也使用客户服务器方式，但它使用UDP 数据报，因此TFfP 需要有自己的差错改正措施。TFfP 只支持文件传输而不支持交耳。

3 TELNET

TELNET 是一个简单的远程终端协议，底层采用TCP协议。TELNET 也使用客户服务器方式。在本地系统运行TELNET 客户进程，而在远地主机则运行TELNET 服务器进程，占用端口23。

4 邮件传输协议

一个电子邮件系统应具如图所示的三个主要组成构件，这就是用户代理、邮件服务器，以及邮件发送协议（如SMTP ）和邮件读取协议（如POP3)， POP3 是邮局协议（Post Office Protocol）的版本3 。

SMTP 和POP3 （或IMAP ）都是在TCP 连接的上面传送邮件，使用TCP 的目的是为了使邮件的传送成为可靠的。

‘伍’ tcp和udp区别是什么

如下：

TCP向上层提供面向连接的可靠服务 ，UDP向上层提供无连接不可靠服务。

TCP简介：

传输控制协议（TCP，Transmission Control Protocol）是一种面向连接的、可靠的、基于字节流的传输层通信协议，由IETF的RFC 793定义。

TCP旨在适应支持多网络应用的分层协议层次结构。 连接到不同但互连的计算机通信网络的主计算机中的成对进程之间依靠TCP提供可靠的通信服务。TCP假设它可以从较低级别的协议获得简单的，可能不可靠的数据报服务。 原则上，TCP应该能够在从硬线连接到分组交换或电路交换网络的各种通信系统之上操作。