udp连接的工作方式(简述UDP连接的工作方式)

概述 UDP 是User Datagram Protocol的简称， 中文名是用户数据包协议，是 OSI 参考模型中一种无连接的传输层协议，提供面向事务的简单不可靠信息传送服务。它是IETF RFC 768是UDP的正式规范。UDP的报头UDP报头由4个域组成，其中每个域各占用2个字节，具体如下：源端口号目标端口号数据报长度校验值UDP协议使用端口号为不同的应用保留其各自的数据传输通道。UDP和TCP协议正是采用这一机制实现对同一时刻内多项应用同时发送和接收数据的支持。数据发送一方（可以是客户端或服务器端）将UDP数据报通过源端口发送出去，而数据接收一方则通过目标端口接收数据。有的网络应用只能使用预先为其预留或注册的静态端口；而另外一些网络应用则可以使用未被注册的动态端口。因为UDP报头使用两个字节存放端口号，所以端口号的有效范围是从0到65535。一般来说，大于49151的端口号都代表动态端口。数据报的长度是指包括报头和数据部分在内的总字节数。因为报头的长度是固定的，所以该域主要被用来计算可变长度的数据部分（又称为数据负载）。数据报的最大长度根据操作环境的不同而各异。从理论上说，包含报头在内的数据报的最大长度为65535字节。不过，一些实际应用往往会限制数据报的大小，有时会降低到8192字节。UDP协议使用报头中的校验值来保证数据的安全。校验值首先在数据发送方通过特殊的算法计算得出，在传递到接收方之后，还需要再重新计算。如果某个数据报在传输过程中被第三方篡改或者由于线路噪音等原因受到损坏，发送和接收方的校验计算值将不会相符，由此UDP协议可以检测是否出错。这与TCP协议是不同的，后者要求必须具有校验值。许多链路层协议都提供错误检查，包括流行的以太网协议，也许想知道为什么UDP也要提供检查和。其原因是链路层以下的协议在源端和终端之间的某些通道可能不提供错误检测。虽然UDP提供有错误检测，但检测到错误时，UDP不做错误校正，只是简单地把损坏的消息段扔掉，或者给应用程序提供警告信息。UDP协议的几个特性（1） UDP是一个无连接协议，传输数据之前源端和终端不建立连接，当它想传送时就简单地去抓取来自应用程序的数据，并尽可能快地把它扔到网络上。在发送端，UDP传送数据的速度仅仅是受应用程序生成数据的速度、计算机的能力和传输带宽的限制；在接收端，UDP把每个消息段放在队列中，应用程序每次从队列中读一个消息段。（2） 由于传输数据不建立连接，因此也就不需要维护连接状态，包括收发状态等，因此一台服务机可同时向多个客户机传输相同的消息。（3） UDP信息包的标题很短，只有8个字节，相对于TCP的20个字节信息包的额外开销很小。（4） 吞吐量不受拥挤控制算法的调节，只受应用软件生成数据的速率、传输带宽、源端和终端主机性能的限制。（5）UDP使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的链接状态表（这里面有许多参数）。（6）UDP是面向报文的。发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付给IP层。既不拆分，也不合并，而是保留这些报文的边界，因此，应用程序需要选择合适的报文大小。虽然UDP是一个不可靠的协议，但它是分发信息的一个理想协议。例如，在屏幕上报告股票市场、在屏幕上显示航空信息等等。UDP也用在路由信息协议RIP（Routing Information Protocol）中修改路由表。在这些应用场合下，如果有一个消息丢失，在几秒之后另一个新的消息就会替换它。UDP广泛用在多媒体应用中，例如，Progressive Networks公司开发的RealAudio软件，它是在因特网上把预先录制的或者现场音乐实时传送给客户机的一种软件，该软件使用的RealAudio audio-on-demand protocol协议就是运行在UDP之上的协议，大多数因特网电话软件产品也都运行在UDP之上。 UDP = uridine diphosphate，尿苷二磷酸，一种嘧啶核苷酸，由碱基、尿嘧啶与核糖组成，主要用途是RNA合成（转录）时的原料。 另外UDP也是DTP能量消耗后产物，功能类似ADP，但较ADP少见。参与微生物肽聚糖等的合成。

在防火墙上钻孔【UDP Hole Puching】：穿透防火墙建立UDP连接 知道现在流行的P2P软件和IM软件是如何让两台分处在不同防火墙后面的电脑直接对话的吗？SIP当然是一种，还有一种被广泛应用的就是本文介绍的UDP Hole Puching技术。为了便于讲述，我们假设有这样一个网络拓扑结构：IP=A.A.A.A IP=1.1.1.1HostA----------FirewallA---------||Server IP=S.S.S.S|HostB----------FirewallB---------|IP=B.B.B.B IP=2.2.2.2运用这个技术，必须满足下面的条件:1) HostA和HostB分别通过FirewallA和FirewallB经过NAT用UDP连接到了Server2) FirewallA和FirewallB都满足这样的特性，即来自相同IP相同Port的数据包，不管目的地IP是多少， 都会NAT成相同的IP+Port，举个例子吧:HostA通过UDP Port 1234访问主机S1时，防火墙会把数据包NAT成1.1.1.1:5668(举例),那么HostA通过UDP Port 1234访问主机S2时，防火墙仍然会把数据包NAT成1.1.1.1:5668。好在现在的NAT基本上都具备这个特性。现在，HostA用UDP端口1111连接到Server的5555端口，HostB用端口2222连接到Server的5555端口,在Server看来，HostA来自1.1.1.1:9676(FirewallA NAT过了嘛)，HostB则来自2.2.2.2:6573。当HostA想直接连接HostB时，它这样做：1)用UDP端口1111发一个数据包给2.2.2.2:6573，注意一定要用端口1111哦，这个数据包一定会被FirewallA NAT成 1.1.1.1:9676 -> 2.2.2.2:5668(不要问为什么，看看前面对防火墙的要求先); 千万别期望HostB会收到这个数据包，因为当包到达FirewallB时，FirewallB被弄糊涂了，它根本不知道 1.1.1.1:9676 -> 2.2.2.2:6573的数据包应该转给谁，当然这个包就会被丢弃并回一个ICMP包说Port不存在。但是，我们还是得到了我们想要的一些东西，那就是我们成功地告诉了FirewallA "如果有2.2.2.2:6573 -> 1.1.1.1:9676的数据包，请转发到A.A.A.A:1111"，这就是一个洞洞!!2)接下来，和你想象的一样，HostA通过Server中转，告诉HostB，用端口2222发一个数据包到1.1.1.1:9676，HostB照办了，而且这个包一定会被FirewallB NAT成 2.2.2.2:6573 -> 1.1.1.1:9676。这个回复的数据包同样在FirewallB上钻了个孔，凡是1.1.1.1:9676 -> 2.2.2.2:6573的包都会被转发到B.B.B.B:2222，当数据包到达FirewallA时，FirewallA很高兴地把2.2.2.2:6573 -> 1.1.1.1:9676的数据包转发给A.A.A.A:1111。3)大功告成了，HostA和HostB开始愉快的交谈起来。很简单吧?不过实施起来还要注意几点，否则你都不知道为什么总连不上：1) 步骤1中那个Port不存在的ICMP是个杀手，至少对Linux上用iptables做的NAT来讲是这样，因为FirewallA收到这个ICMP会关闭刚钻上的洞洞，想办法不让FirewallB发这个ICMP或者让FirewallA丢掉这个ICMP吧;2) 时间问题，步骤1在FirewallA上开的洞洞是有时间限制的，通常为30－60秒吧，如果超时了都没收到2.2.2.2:6573 -> 1.1.1.1:9676的包，洞洞会自动关闭，同样步骤2以后，HostA也应该及时在发个数据包给B，以保证FirewallB上的洞洞不会因为超时而关闭。值得提一下的是多数NAT防火墙会在看见进出双向的数据包后延长关闭洞洞的时间，Linux默认设置时会延长到3分钟。3) HostA不能连到HostB，并不表示HostB一定连不到HostA，反一下方向试试也许会有意外惊喜。 好了，就写这些吧，祝大家钻孔愉快
在防火墙上钻孔【UDP Hole Puching】：穿透防火墙建立UDP连接 知道现在流行的P2P软件和IM软件是如何让两台分处在不同防火墙后面的电脑直接对话的吗？SIP当然是一种，还有一种被广泛应用的就是本文介绍的UDP Hole Puching技术。为了便于讲述，我们假设有这样一个网络拓扑结构：IP=A.A.A.A IP=1.1.1.1HostA----------FirewallA---------||Server IP=S.S.S.S|HostB----------FirewallB---------|IP=B.B.B.B IP=2.2.2.2运用这个技术，必须满足下面的条件:1) HostA和HostB分别通过FirewallA和FirewallB经过NAT用UDP连接到了Server2) FirewallA和FirewallB都满足这样的特性，即来自相同IP相同Port的数据包，不管目的地IP是多少， 都会NAT成相同的IP+Port，举个例子吧:HostA通过UDP Port 1234访问主机S1时，防火墙会把数据包NAT成1.1.1.1:5668(举例),那么HostA通过UDP Port 1234访问主机S2时，防火墙仍然会把数据包NAT成1.1.1.1:5668。好在现在的NAT基本上都具备这个特性。现在，HostA用UDP端口1111连接到Server的5555端口，HostB用端口2222连接到Server的5555端口,在Server看来，HostA来自1.1.1.1:9676(FirewallA NAT过了嘛)，HostB则来自2.2.2.2:6573。当HostA想直接连接HostB时，它这样做：1)用UDP端口1111发一个数据包给2.2.2.2:6573，注意一定要用端口1111哦，这个数据包一定会被FirewallA NAT成 1.1.1.1:9676 -> 2.2.2.2:5668(不要问为什么，看看前面对防火墙的要求先); 千万别期望HostB会收到这个数据包，因为当包到达FirewallB时，FirewallB被弄糊涂了，它根本不知道 1.1.1.1:9676 -> 2.2.2.2:6573的数据包应该转给谁，当然这个包就会被丢弃并回一个ICMP包说Port不存在。但是，我们还是得到了我们想要的一些东西，那就是我们成功地告诉了FirewallA "如果有2.2.2.2:6573 -> 1.1.1.1:9676的数据包，请转发到A.A.A.A:1111"，这就是一个洞洞!!2)接下来，和你想象的一样，HostA通过Server中转，告诉HostB，用端口2222发一个数据包到1.1.1.1:9676，HostB照办了，而且这个包一定会被FirewallB NAT成 2.2.2.2:6573 -> 1.1.1.1:9676。这个回复的数据包同样在FirewallB上钻了个孔，凡是1.1.1.1:9676 -> 2.2.2.2:6573的包都会被转发到B.B.B.B:2222，当数据包到达FirewallA时，FirewallA很高兴地把2.2.2.2:6573 -> 1.1.1.1:9676的数据包转发给A.A.A.A:1111。3)大功告成了，HostA和HostB开始愉快的交谈起来。很简单吧?不过实施起来还要注意几点，否则你都不知道为什么总连不上：1) 步骤1中那个Port不存在的ICMP是个杀手，至少对Linux上用iptables做的NAT来讲是这样，因为FirewallA收到这个ICMP会关闭刚钻上的洞洞，想办法不让FirewallB发这个ICMP或者让FirewallA丢掉这个ICMP吧;2) 时间问题，步骤1在FirewallA上开的洞洞是有时间限制的，通常为30－60秒吧，如果超时了都没收到2.2.2.2:6573 -> 1.1.1.1:9676的包，洞洞会自动关闭，同样步骤2以后，HostA也应该及时在发个数据包给B，以保证FirewallB上的洞洞不会因为超时而关闭。值得提一下的是多数NAT防火墙会在看见进出双向的数据包后延长关闭洞洞的时间，Linux默认设置时会延长到3分钟。 3) HostA不能连到HostB，并不表示HostB一定连不到HostA，反一下方向试试也许会有意外惊喜。
telnet IP UDP端口

TCP：Transmission Control Protocol 传输控制协议TCP是一种面向连接（连接导向）的、可靠的、基于字节流的运输层（Transport layer）通信协议，在 OSI模型中，它完成第四层传输层所指定的功能。 UDP：是User Datagram Protocol的简称，用户数据包协议，是 OSI 参考模型中一种无连接的传输层协议，提供面向事务的简单不可靠信息传送服务。TCP和UDP传输就类似于我们的手机通电话和手机发短信，一种必需连通了，才能够通话，相对来说比较可靠，传输速度比较快，另一种可以在关机状态（无连接）发送信息，相对来说，可靠性比较差，传输速度较慢。具体的差别如下：TCP协议面向连接，UDP协议面向非连接TCP协议传输速度慢，UDP协议传输速度快TCP协议保证数据顺序，UDP协议不保证TCP协议保证数据正确性，UDP协议可能丢包TCP协议对系统资源要求多，UDP协议要求少不管是基于TCP还是基于UDP的网络通讯编程，都要区分服务器端和客户端，下面以TCP为例，实现客户端和服务器端通讯的实现步骤：TCP服务器端的编写步骤：1. 首先，你需要创建一个用于通讯的套接口，一般使用socket调用来实现。这等于你有了一个用于通讯的电话：）2. 然后，你需要给你的套接口设定端口，相当于，你有了电话号码。这一步 一般通过设置网络套接口地址和调用bind函数来实现。3. 调用listen函数使你的套接口成为一个监听套接字。 以上三个步骤是TCP服务器的常用步骤。4. 调用accept函数来启动你的套接字，这时你的程序就可以等待客户端的连接了。5. 处理客户端的连接请求。6. 终止连接。TCP编程的客户端一般步骤是：1、创建一个socket，用函数socket()；2、设置socket属性，用函数setsockopt();* 可选3、绑定IP地址、端口等信息到socket上，用函数bind();* 可选4、设置要连接的对方的IP地址和端口等属性；5、连接服务器，用函数connect()（相当于拨号）； 6、收发数据，用函数send()和recv()，或者read()和write()（相当于通话）;
udp是断点续传，tcp是直接连接。
tcp和udp都是传输协议，只是两者是有区别的，TCP是一种在不可靠的网络环境中进行可靠的传输，一个文件被分成许多数据包从一台主机传输到另外一台主机，每接受一个数据包，两台主机之间都需要验证的，如果另外一台主机没有接收到该数据包，该主机会要求数据包发起的主机重发，一直到接收到为止（当然重发次数也是有次数限制的），这就是TCP协议的传输特点。 而udp则是在安全的网络下进行的不可靠传输，传输之前，双方主机之间建立起一条专用的传输通道，数据包一旦从发起电脑传输，之后就不再管对方收没收到的问题，一直把数据全部传输为止，传输完了发起主机会自动关闭数据传输通道。

TCP：Transmission Control Protocol 传输控制协议TCP是一种面向连接（连接导向）的、可靠的、基于字节流的运输层（Transport layer）通信协议，在 OSI模型中，它完成第四层传输层所指定的功能。 UDP：是User Datagram Protocol的简称，用户数据包协议，是 OSI 参考模型中一种无连接的传输层协议，提供面向事务的简单不可靠信息传送服务。TCP和UDP传输就类似于我们的手机通电话和手机发短信，一种必需连通了，才能够通话，相对来说比较可靠，传输速度比较快，另一种可以在关机状态（无连接）发送信息，相对来说，可靠性比较差，传输速度较慢。具体的差别如下：TCP协议面向连接，UDP协议面向非连接TCP协议传输速度慢，UDP协议传输速度快TCP协议保证数据顺序，UDP协议不保证TCP协议保证数据正确性，UDP协议可能丢包TCP协议对系统资源要求多，UDP协议要求少不管是基于TCP还是基于UDP的网络通讯编程，都要区分服务器端和客户端，下面以TCP为例，实现客户端和服务器端通讯的实现步骤：TCP服务器端的编写步骤：1. 首先，你需要创建一个用于通讯的套接口，一般使用socket调用来实现。这等于你有了一个用于通讯的电话：）2. 然后，你需要给你的套接口设定端口，相当于，你有了电话号码。这一步 一般通过设置网络套接口地址和调用bind函数来实现。3. 调用listen函数使你的套接口成为一个监听套接字。 以上三个步骤是TCP服务器的常用步骤。4. 调用accept函数来启动你的套接字，这时你的程序就可以等待客户端的连接了。5. 处理客户端的连接请求。6. 终止连接。TCP编程的客户端一般步骤是：1、创建一个socket，用函数socket()；2、设置socket属性，用函数setsockopt();* 可选3、绑定IP地址、端口等信息到socket上，用函数bind();* 可选4、设置要连接的对方的IP地址和端口等属性；5、连接服务器，用函数connect()（相当于拨号）； 6、收发数据，用函数send()和recv()，或者read()和write()（相当于通话）;

计算机网络七层模型中，传输层有两个重要的协议：（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 × RTTdRTTd是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 简单文件传送协议TFTPTCP/IP 协议族中还有一个简单文件传送协议TFfP (Trivial File Transfer Protocol），它是一个很小且易于实现的文件传送协议，端口号69。TFfP 也使用客户服务器方式，但它使用UDP 数据报，因此TFfP 需要有自己的差错改正措施。TFfP 只支持文件传输而不支持交耳。3 TELNETTELNET 是一个简单的远程终端协议，底层采用TCP协议。TELNET 也使用客户服务器方式。在本地系统运行TELNET 客户进程，而在远地主机则运行TELNET 服务器进程，占用端口23。4 邮件传输协议一个电子邮件系统应具如图所示的三个主要组成构件，这就是用户代理、邮件服务器，以及邮件发送协议（如SMTP ）和邮件读取协议（如POP3)， POP3 是邮局协议（Post Office Protocol）的版本3 。SMTP 和POP3 （或IMAP ）都是在TCP 连接的上面传送邮件，使用TCP 的目的是为了使邮件的传送成为可靠的。