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 是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(User Datagram Protocol） 用户数据报协议 （RFC 768） 用户数据报协议（UDP）是 OSI 参考模型中一种无连接的传输层协议，提供面向事务的简单不可靠信息传送服务。 UDP 协议基本上是 IP 协议与上层协议的接口。 UDP 协议适用端口分辨运行在同一台设备上的多个应用程序。由于大多数网络应用程序都在同一台机器上运行，计算机上必须能够确保目的地机器上的软件程序能从源地址机器处获得数据包，以及源计算机能收到正确的回复。这是通过使用 UDP 的“端口号”完成的。例如，如果一个工作站希望在工作站 128.1.123.1 上使用域名服务系统，它就会给数据包一个目的地址 128.1.123.1 ，并在 UDP 头插入目标端口号 53 。源端口号标识了请求域名服务的本地机的应用程序，同时需要将所有由目的站生成的响应包都指定到源主机的这个端口上。与 TCP 不同， UDP 并不提供对 IP 协议的可靠机制、流控制以及错误恢复功能等。由于 UDP 比较简单， UDP 头包含很少的字节，比 TCP 负载消耗少。UDP 适用于不需要 TCP 可靠机制的情形，比如，当高层协议或应用程序提供错误和流控制功能的时候。 UDP 是传输层协议，服务于很多知名应用层协议，包括网络文件系统（NFS）、简单网络管理协议（SNMP）、域名系统（DNS）以及简单文件传输系统（TFTP）。协议结构Source Port — 16位。源端口是可选字段。当使用时，它表示发送程序的端口，同时它还被认为是没有其它信息的情况下需要被寻址的答复端口。如果不使用，设置值为0。Destination Port — 16位。目标端口在特殊因特网目标地址的情况下具有意义。Length — 16位。该用户数据报的八位长度，包括协议头和数据。长度最小值为8。Checksum — 16位。IP 协议头、UDP 协议头和数据位，最后用0填补的信息假协议头总和。如果必要的话，可以由两个八位复合而成。Data — 包含上层数据信息。UDP的特点：UDP协议使用IP层提供的服务把从应用层得到的数据从一台主机的某个应用程序传给网络上另一台主机上的某一个应用程序。UDP协议有如下的特点：1、UDP传送数据前并不与对方建立连接，即UDP是无连接的，在传输数据前，发送方和接收方相互交换信息使双方同步。2、UDP不对收到的数据进行排序，在UDP报文的首部中并没有关于数据顺序的信息（如TCP所采用的序号），而且报文不一定按顺序到达的，所以接收端无从排起。3、UDP对接收到的数据报不发送确认信号，发送端不知道数据是否被正确接收，也不会重发数据。4、UDP传送数据较TCP快速，系统开销也少。 从以上特点可知，UDP提供的是无连接的、不可靠的数据传送方式，是一种尽力而为的数据交付服务。

其实这里是一种逻辑上的连接。UDP通讯与TCP通讯的一个重要区别就是，TCP连接的结果是实现了一个通讯管道，所谓管道，包含一个含义，就是先进先出，先发出的信息必然先到达，因此对发送的数据可以保持“序”，有序的数据流。而UDP则没有这个条件，如果网络环境比较复杂，根本不能指望先发出的信息会先到达。因而，要实现例如语音和视频交换，就必须解决数据包顺序问题。在很多情况下，使用TCP而不使用UDP往往也是这个原因。 回答：2006-06-17 18:53提问者对答案的评价：谢谢

B并不用确定A的端口号，因为UDP本身就是不面向连接的数据传送，所以不存在连接问题。 参考如下：UDP是一个无连接协议，传输数据之前源端和终端不建立连接，当它想传送时就简单地去抓取来自应用程序的数据，并尽可能快地把它扔到网络上。在发送端，UDP传送数据的速度仅仅是受应用程序生成数据的速度、计算机的能力和传输带宽的限制；在接收端，UDP把每个消息段放在队列中，应用程序每次从队列中读一个消息段。 由于传输数据不建立连接，因此也就不需要维护连接状态，包括收发状态等，因此一台服务机可同时向多个客户机传输相同的消息。
UDP协议不需要显式的连接，需要在两个Winsock控件中间发送数据，关键需要完成以下的三步： 1．将RemoteHost属性设置为另一台计算机的名称。2．将RemotePort属性设置为第二个控件的LocalPort属性。 3．调用Bind方法，指定使用的LocalPort。

在防火墙上钻孔【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端口